# Claude Code ソース流出: BANリスク、現行モデル、アカウント構造を整理する (2026) > Claude Code では 2026 年 3 月に内部ソースコードの露出が実際に起きました。Anthropic は、これは外部侵害ではなくリリースのパッケージングミスであり、顧客データや認証情報は露出していないと説明しています。重要なのは、この事実を BAN の噂、古いモデル情報、Claude と Console の混同から切り分けることです。 - URL: https://blog.laozhang.ai/ja/posts/claude-code-source-leak-ban-policy - Published: 2026-04-01 - Updated: 2026-04-01 - Author: AI Free API Team (https://blog.laozhang.ai/ja/about) - Category: Claude Code - Tags: Claude Code, Anthropic, ソース流出, BANポリシー, Claudeモデル, 開発者ツール --- Claude Code では 2026 年 3 月に内部ソースコードの露出が実際に起きました。Anthropic の説明では、これは外部からの breach ではなく release packaging mistake であり、顧客データや credentials は露出していません。いま本当に重要なのは、ミラーにどんな hidden strings があったかではありません。Anthropic の公開ドキュメントが、BAN、現行モデル、認証と課金の経路をいまどう定義しているかです。2026 年 4 月 1 日時点で Anthropic の公開情報が示しているのは次の 3 点です。BAN は policy / terms の問題として扱われること、Claude Code の公開最上位モデルは Sonnet 4.6 と Opus 4.6 であること、そして Claude subscription、Console account、API key billing は別々の契約だということです。 > エビデンス注記: この記事は 2026 年 4 月 1 日に確認した Anthropic の help center、release notes、policy、product ページに加え、[Axios の 3 月 31 日記事](https://www.axios.com/2026/03/31/anthropic-leaked-source-code-ai)、[Fortune の 3 月 26 日記事](https://fortune.com/2026/03/26/anthropic-leaked-unreleased-model-exclusive-event-security-issues-cybersecurity-unsecured-data-store/)、そして現在公開されている `@anthropic-ai/claude-code` `2.1.89` npm パッケージの直接確認に基づいています。 ## TL;DR - はい、Claude Code のソース露出は実際に起きました。Axios は Anthropic のコメントとして、ある Claude Code リリースに内部ソースが含まれていたと報じています。 - Anthropic は同時に、敏感な顧客データや認証情報は露出していないと述べています。 - Anthropic の公開 help-center にある `Safeguards Warnings and Appeals` では、アカウント停止理由として Usage Policy 違反の反復、非対応地域からのアカウント作成、Terms 違反が挙げられています。`流出を見たから停止` とは書かれていません。 - 同じページには、Anthropic が Opus 4.6 向けに real-time cyber safeguards を展開していることも書かれています。明確に悪意あるサイバー依頼や一部の dual-use vulnerability work が block される可能性がありますが、これはアカウント停止そのものとは別です。 - 3 月 26 日の Fortune 記事と 3 月 31 日の Axios 記事は同じ話ではありません。前者は公開アクセス可能なデータストア、後者は Claude Code のリリースパッケージングミスです。 - 現在の Claude Code の公開最上位モデルは Sonnet 4.6 と Opus 4.6 です。4.5 系の一部はまだ選択できますが、Opus 4 と 4.1 は 2026 年 1 月 16 日に Claude / Claude Code から削除されました。 - Claude account と Console account は同じメールアドレスで共存できますが、別システムとして動きます。Claude Code では `ANTHROPIC_API_KEY` が subscription login より billing 上優先されます。 ## 3 月 31 日に何が漏れ、何が漏れていないのか このテーマで最も危険なのは、別々の incident をひとつの「全部漏れた話」にまとめてしまうことです。 3 月 26 日の [Fortune の記事](https://fortune.com/2026/03/26/anthropic-leaked-unreleased-model-exclusive-event-security-issues-cybersecurity-unsecured-data-store/) は、Anthropic の内部資料が公開アクセス可能なデータストアに置かれていたように見える、という話でした。未公開モデル関連の資料や社内イベント関連の情報などが含まれており、Anthropic はその記事の中で、より強力なモデルを early-access customers とテストしていることを認めています。ここでの中心は「広い意味での内部資料露出」です。 一方で、3 月 31 日の [Axios の記事](https://www.axios.com/2026/03/31/anthropic-leaked-source-code-ai) は、開発者にとってもっと直接的です。Anthropic は Axios に対し、以前の Claude Code リリースに内部ソースコードが含まれてしまったと説明しました。このコメントの意味は 2 つあります。ひとつは、ソース露出そのものは事実だったということ。もうひとつは、スコープを `packaging issue` に限定し、customer data や credentials の露出はなかったと明言していることです。 つまり、`内部ソースコードが露出した` ことと、`顧客データ漏えい`、`モデル重み流出`、`ユーザー鍵の流出` は同じではありません。ここを一緒くたにすると、読者は現実のリスクを判断できなくなります。 さらに重要なのは、現在の npm パッケージが、その最初の壊れた publish と同じ状態とは限らないことです。私は 2026 年 4 月 1 日時点の `@anthropic-ai/claude-code` `2.1.89` を直接確認しました。現在の tarball は単一の `cli.js` を含む形で、パッケージ一覧に独立した `.map` ファイルはなく、`cli.js` の末尾にも `sourceMappingURL=` footer はありません。この事実は「過去の exposure がなかった」ことを意味しません。ただし、「いま取得する live package がそのまま同じ露出面を持っている」とは言えない、という実務的な違いを示します。 ![公式確認、報道、未確定事項の境界を分ける図](https://blog.laozhang.ai/posts/ja/claude-code-source-leak-ban-policy/img/evidence-boundary.jpg) 実務的には、次の 3 層に分けて考えるのが安全です。 - 公式に確認されたこと: Anthropic は内部ソース露出を認め、customer data や credentials の露出は否定している - 現在のパッケージ確認で言えること: 現行 npm パッケージは最も単純な `source map がそのまま付いている` 形ではない - まだ公開契約ではないこと: ミラーや leak strings から引いた roadmap、feature、entitlement の断定 ## Anthropic が公開している BAN ルールは何か `BAN されるのか` という問いに対して最初に見るべきなのは、SNS のまとめではなく Anthropic の [Safeguards Warnings and Appeals](https://support.claude.com/en/articles/8241253-safeguards-warnings-and-appeals) です。このページでは、アカウント停止の理由として repeated Usage Policy violations、unsupported location からのアカウント作成、Terms of Service violations が挙げられています。また、warning の存在と、誤停止だと考える場合の appeal path も示されています。 2026 年 4 月 1 日時点の更新版では、同じページにもう一つ重要な層が追加されています。Anthropic は Claude Opus 4.6 向けに real-time cyber safeguards を展開しており、mass data exfiltration や ransomware development のような明確に悪意あるサイバー依頼を block し、一部の dual-use cybersecurity work や vulnerability discovery も block される可能性があると説明しています。これは account suspension とは別レイヤーですが、外部の rumor では request-level blocking と account-level ban が同じもののように語られがちなので重要です。 このページの重要さは、「何が書かれているか」と「何が書かれていないか」の両方にあります。ここには公開された enforcement surface がありますが、`流出記事を見た`、`ミラーを見た`、`SNS で話題を追った` といった行為が独立した BAN 理由だとは書かれていません。したがって、2026 年 4 月 1 日時点で最も defensible な答えはこうです。Anthropic は policy / terms ベースの停止理由と一部の request-level cyber blocking を公開しているが、`流出を見たこと` 自体を単独の BAN トリガーとしては公開していない。 もちろん、流出資料まわりのあらゆる行動が無害だと言っているわけではありません。Anthropic の [Responsible Disclosure Policy](https://www.anthropic.com/responsible-disclosure-policy) では、good-faith research を行う場合でも、データを exfiltrate / download / retain しないこと、公開前に調整すること、最小限以上の exploit をしないことが求められています。これは security research 向けの文書ですが、Anthropic が exposed internal material をどう捉えているかの手がかりにはなります。 ここからの**推論**としては、Anthropic の公開文書は `記事を読んだだけで BAN` という噂を裏づけていません。Opus 4.6 で cyber request が 1 回 block されたことも、そのまま account suspension と同義ではありません。しかし、行動が `ニュースを読んだ` ではなく `露出した内部資産を保存、利用、再配布した` に近づくほど、policy や terms の境界に近づいていくのは自然です。 この中間の答えが最も実用的です。`何をしても安全` も言い過ぎですし、`見ただけで停止` も裏づけがありません。公開情報が支えているのは、policy-based enforcement、warning と appeal の存在、そして `読むだけで自動停止` という単純ルールは見当たらない、というところまでです。 ## 現在の Claude Code モデル契約はどうなっているか 流出話の周辺では、古いモデル名や噂ベースの名前が混ざりやすくなります。ここは current public docs に戻るのが一番早いです。 Anthropic の [Claude Code model configuration](https://support.claude.com/en/articles/11940350-claude-code-model-configuration) には、現在サポートされているモデルとして次が載っています。 - Sonnet 4.6: `claude-sonnet-4-6` - Opus 4.6: `claude-opus-4-6` - Opus 4.5: `claude-opus-4-5-20251101` - Haiku 4.5: `claude-haiku-4-5-20251001` - Sonnet 4.5: `claude-sonnet-4-5-20250929` この一覧が意味するのは明確です。現在の Claude Code の公開トップエンドは Sonnet 4.6 と Opus 4.6 です。一方で、4.5 系の一部はまだ構成可能であり、`最新` と `まだ使える` は同義ではありません。 [Release notes](https://support.claude.com/en/articles/12138966-release-notes) の日付も重要です。 - 2026 年 1 月 16 日: Opus 4 と 4.1 は Claude / Claude Code から削除 - 2026 年 2 月 5 日: Opus 4.6 launch - 2026 年 2 月 17 日: Sonnet 4.6 launch つまり、まだ `Opus 4` や `4.1` を current flagship のように語っている記事は、少なくともいまの help-center reality とは合っていません。 ![現在の Claude Code モデル時系列と deprecation 図](https://blog.laozhang.ai/posts/ja/claude-code-source-leak-ban-policy/img/model-timeline.webp) さらに 2 つ、実務上見落としやすい点があります。 ひとつは access。Anthropic は model configuration ページで、Pro plan で Claude Code を使う場合、Opus を使うには extra usage の有効化と購入が必要だと書いています。これは roadmap の噂よりもはるかに重要です。実際にいま自分が使えるかどうかを決めるからです。プラン選びの詳細は [Claude Code Pro vs Max ガイド](https://blog.laozhang.ai/ja/posts/claude-code-pro-vs-max) で掘り下げています。 もうひとつは long context です。[Claude Code FAQ](https://support.claude.com/en/articles/12386420-claude-code-faq) では、Max / Team / Enterprise ユーザーの Opus 4.6 に 1M context が含まれると説明されています。ここでも、行動に効くのは leak hype ではなく current docs の契約です。 短くまとめると、現時点の正しいモデル認識はこうです。 - 現在の主力公開モデルは Sonnet 4.6 - 公開トップエンドが必要なら Opus 4.6 - 4.5 系は旧世代だがまだ一部利用可能 - leak-derived name は docs に載るまで public contract ではない ## Claude account、Console account、API key billing はどう分かれるのか 実際には、この部分がもっともトラブルを生みます。人は `同じメールアドレス` を `同じ billing bucket` と誤解しやすいからです。 Anthropic の [Can I have a Claude account and a Console account?](https://support.claude.com/en/articles/8987223-can-i-have-a-claude-account-and-a-console-account) は極めて短いですが、とても重要です。答えは `Yes`。同じ email で両方を持てるが、独立して動く、です。この 1 行だけで account logic のかなりの部分が説明できます。 Claude account は consumer / work product surface 側です。Free、Pro、Max、Team、Enterprise のような契約はこちらに属します。Console account は API 側です。API billing、keys、rate limits、org-level developer controls はこちらです。同じ人が両方を持てても、同じ予算系統にはなりません。 Anthropic の [Using Claude Code with your Pro or Max plan](https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan) は、subscription 側の contract をはっきり書いています。Claude の資格情報で Claude Code にログインすれば、Claude と Claude Code は同じ plan usage pool を共有します。 最大の落とし穴は [Managing API key environment variables in Claude Code](https://support.claude.com/en/articles/12304248-managing-api-key-environment-variables-in-claude-code) にあります。Anthropic は、`ANTHROPIC_API_KEY` が environment variables にある場合、Claude Code は subscription auth よりそちらを優先して billing を行うと説明しています。つまり、Claude subscription でログインしていても、shell に API key があるだけで API billing に切り替わり得ます。 ![Claude subscription、Console、API key override の関係図](https://blog.laozhang.ai/posts/ja/claude-code-source-leak-ban-policy/img/account-split.webp) 実務的な見取り図はこうです。 | 経路 | 何か | Claude Code 内の billing | よくある誤解 | | --- | --- | --- | --- | | Claude subscription login | Free / Pro / Max / Team / Enterprise | plan allocation と extra usage path を使う | これが API key より常に強いと思う | | Console account | pay-as-you-go API organization | API credits と org settings を使う | 同じ email だから同じ予算だと思う | | `ANTHROPIC_API_KEY` | 明示的な API auth override | subscription auth より billing 上優先 | 環境変数の存在を忘れる | 加えて 2 つ覚えておくと便利です。 ひとつは `/login` です。Anthropic は Pro/Max 向け help article で、Console PAYG から subscription plan へ切り替える方法として `/login` を案内しています。 もうひとつは org-level setup です。[Claude Code FAQ](https://support.claude.com/en/articles/12386420-claude-code-faq) では、Console org に `Claude Code User` や `Developer` role で人を追加し、Claude Code 側から `/login` で正しい Console account を選ぶ流れが説明されています。また、本来 Team / Enterprise access があるはずなのに `Max or Pro is required` のようなエラーが出る場合、login method を間違えている可能性が高いとも書かれています。 要するに、公開されている account logic はすでに十分です。 - 同じメールで Claude と Console は共存できる - subscription usage と API billing は別 - `ANTHROPIC_API_KEY` は Claude Code の billing path を変える - `/status` と `/login` を見ればかなりの混乱は防げる もし必要なのが安定した API contract なら、subscription workflow を無理やり API 的に使うのではなく、最初から API 問題として扱う方が正しいです。 ## leak-derived internals のうち、まだ意思決定に使うべきでないもの ここでは `面白い` と `いま使える` を分ける必要があります。 bundle inspection や leak coverage から、実在する strings や feature hints が見えるのは事実です。現在の bundle にも `--console`、`--claudeai`、`/login`、`setup-token`、`--enable-auto-mode` といった文字列が見つかります。ですが、それは public entitlement を意味しません。 実装の中に名前があることと、いまその機能があなたの plan で公開されていることは違います。Auto mode がまさにその例です。コードや changelog で関連名が見えても、実際に使えるかどうかは、Anthropic の docs に書かれた plan、model、admin enablement、surface support によって決まります。詳しくは [Claude Code Auto mode ガイド](https://blog.laozhang.ai/ja/posts/claude-code-auto-mode) を参照してください。 このルールは他の leak-derived feature にもそのまま当てはまります。 - docs / release notes / pricing に載ったものだけを current contract として扱う - mirror や feature flag name しか根拠がないものは roadmap signal として扱う - leak の示唆が current help center と衝突したら help center を優先する そうしないと、間違った plan を買ったり、違う login path を選んだり、まだ公開されていないものをチームに約束したりしやすくなります。 ## いま何をすべきか 普通の Claude Code ユーザーなら、次にやることは leak lore を集めることではありません。自分の current setup を確認することです。 1. Claude Code を更新し、いまの npm package が当時の壊れた publish と同じだと思い込まない 2. `/status` を実行して、現在どの auth path が使われているか確認する 3. plan usage を使いたいなら、`ANTHROPIC_API_KEY` が billing を乗っ取っていないか見る 4. モデル選択は current supported-model list に従う BAN リスクが気になるなら、Anthropic の public policy pages を出発点にしてください。そこから読めるのは policy-based enforcement であって、`見たら自動停止` という単純ルールではありません。もし停止が誤りだと思うなら、Anthropic は public appeal path を出しています。 チーム管理者なら、この incident から学ぶべきなのは hidden roadmap ではなく、ユーザーが login methods、モデル可用性、billing precedence をどれだけ混同しているかです。そこを先に正す方が、将来の leak gossip より価値があります。 そして security researcher や power user なら、カテゴリを混ぜないことです。exposure を理解すること、公開契約どおりにサービスを使うこと、露出した内部資産を公認 surface のように扱うことは、それぞれ別の行為です。最後のものだけが、不要なリスクに近づきやすい。 一番役に立つ結論は、実は一番地味です。leak は本物でした。しかし、Claude Code の current public contract は噂の流れよりずっと狭く、ずっと明確です。Anthropic は、現行モデル、account split、billing precedence、そして公開された停止理由をすでに help center に書いています。まずそこを起点に考えるべきです。