何が起きたのか
まず押さえたいのは、2026年3月31日に起きたClaude Codeのソースコード流出です。報道によると、Claude Codeの更新に開発用の補助ファイルが誤って含まれ、公開パッケージから内部コードが見える状態になっていました。Anthropicは、これは外部から侵入された攻撃ではなく、人為的なリリース梱包ミスであり、顧客データや認証情報の流出を伴う侵害ではないと説明しています。
そのうえで、2026年にかけて公開されたClaude Codeの脆弱性情報を見ると、別の問題の中心は「まだユーザーがその作業フォルダを信頼すると決めていない段階」で、フォルダ内の設定が先に効いてしまった点にあります。少し平たく言えば、本来は「このフォルダを開いて大丈夫ですか」と確認してから動くべきなのに、その前に危険な設定が読み込まれてしまった、という話です。
- 2026年3月31日には、Claude Codeの更新へ誤って内部ソースコードが含まれ、公開パッケージから再構成できる状態になっていたことが報じられました。これは外部攻撃というより、公開前チェックの失敗です。
- 2026年1月20日に公開された GHSA-jh7p-qr78-84p7 では、作業フォルダ内の設定で通信先を書き換えられると、信頼確認の前に外部通信が発生し、APIキーが漏れる可能性があるとされました。
- 2026年3月18日に公開された GHSA-mmgp-wc2j-qcv7 では、作業フォルダ内の設定次第で、最初の安全確認画面そのものを飛ばせる問題が報告されました。
- それ以前にも、2025年後半にはGit設定の扱いが起点となって、確認前の任意コード実行につながる問題が公開されていました。単発ではなく、信頼確認より前の処理そのものが難所だったと分かります。
つまり、3月31日の流出は「内部コードを外へ出してしまった運用事故」で、1月20日や3月18日の件は「安全確認より前に危険な設定が効いてしまった設計上の弱点」です。性質は違いますが、どちらもAIエージェントを安全に提供する難しさを示しています。
なぜこういうことが起きたのか
防御より先に未信頼入力を読んでしまうと、保護機構そのものが弱くなる
今回の事案に共通していたのは、安全判断の材料に、作業フォルダ側が自由に書ける設定が混ざっていたことです。本来であれば「このフォルダを信頼するか」が先に来るべきですが、その前にフォルダ内設定を読み込み、動き方や権限を変えられる余地がありました。これはAIが賢すぎたから起きたのではなく、確認前に危険な設定が読めてしまった設計上の問題です。
AIエージェントの難しさは、単なるチャット画面ではなく、実際に仕事を進める主体として動く点にあります。作業フォルダにはコードだけでなく、設定、説明文、追加機能の定義まで入っています。そのため、知らないフォルダを開く行為は、知らない文章を読むだけではなく、知らないルールで動き始めることに近いのです。
最初の確認画面や承認ボタンがあるだけで安全だと考えるのは危険です。重要なのは、その確認より前に何を読み込んでいるかです。作業フォルダ側の設定が先に解釈されると、見えている防御がそのまま迂回されます。
クラウド型生成AIで注意が増える理由
ローカルで動くクライアントでも、モデルがクラウドなら信頼境界は外へ伸びる
Claude Codeの公式ドキュメントでは、ローカル版は手元で動作しつつ、入力内容やAIの返答はネットワーク経由でAnthropicのAPIへ送られると説明されています。つまり、自分のPCで画面を開いていることと、社内だけで完結するAIを使っていることは同じではありません。見た目がローカルでも、実際には会社の外へデータが出入りしている可能性があります。
2026年1月の脆弱性が示したのは、外部へ通信する道があるなら、そこが漏えいの出口にもなり得るということです。クラウド型生成AIの利点は、最新モデルをすぐ使えること、運用負荷を持ち込まなくてよいこと、利用を広げやすいことにあります。一方で、機密データ、外部通信、監査要件をまとめて設計しないと、事故時の影響範囲が一気に広がります。
悪意あるリポジトリが危険な操作を誘発するリスクは、ローカルLLMでも残ります。違いは、外部への通信経路、保存場所、認証情報の置き方を自社で絞りやすいことです。特に機密ソースコードや個人情報を扱う業務では、この差が大きく効きます。
特に大企業では、この種の事故は単なる開発トラブルで済みません。顧客情報、未公開の事業計画、設計資料、ソースコードが絡む場合、漏えいそのものよりも、その後の監査対応、顧客説明、再発防止、経営報告まで含めた影響が大きくなります。会社の規模が大きいほど、関係者も説明先も増えるため、AI利用基盤の選定ミスは十分に命取りになり得ます。
クラウド型生成AIが向く業務は確かにあります。一方で、機密性が高い業務、社外持ち出しが許されないデータ、閉域監査が厳しい部門では、最初からローカルLLMやオンプレミス構成を検討する方が合理的です。通信先、保存場所、認証情報、監査ログを自社統制の中で設計できるためです。
言い換えると、クラウド型生成AIを避けるべきという話ではありません。クラウド型は十分に実用的です。ただし、情報区分が高い業務や、repo外への持ち出しが許されない業務、閉域監査が厳しい業界では、最初からローカルLLMやオンプレミス構成を比較対象に入れておくべきです。
実務で見直したい対策
AIエージェントの導入は、プロンプト設計より先に権限設計を決める
今回の事例から逆算すると、現場で効く対策はかなり明確です。とくに重要なのは、未知のrepoを開く時点で「開発効率化ツール」としてではなく、「未信頼コードを扱う実行環境」として扱うことです。
- 外部から取得したrepoは、最初から未信頼として扱い、隔離されたVMやdevcontainerで開く
- 長寿命のAPIキーを常時環境変数へ入れっぱなしにしない
- 権限設定で
bypassPermissionsのような全面許可モードを組織標準にしない - 読み取り専用、編集可能、外部通信可能を同じセッションへ安易に同居させない
- 利用ログ、設定変更、外部接続先を追える監査設計を用意する
さらに、組織としては「どの業務までクラウド型生成AIを許可するか」を曖昧にしないことが重要です。たとえば、議事録要約や一般的な調査はクラウド型を許容し、顧客データ、ソースコード、契約文書、社内手順書はローカルLLMまたは閉域環境へ寄せるといった線引きです。技術的に全部可能だからといって、同じ実行環境に全部載せるのは設計として雑です。
まとめ
Claude Codeで公開された脆弱性は、AIエージェントの便利さと危うさが裏表であることをよく示しています。問題は「AIが危ない」ことではなく、未信頼な作業フォルダ、秘密情報、外部通信、実行権限を同じ場所に集めたときに、どこで安全確認をするのかが曖昧になりやすいことです。
もし自社がクラウド型生成AIを使うなら、使うツールの名前だけで判断するのではなく、どんな情報を扱うのか、会社の外へ何が出るのか、事故時に追跡できるのかで決めるべきです。特に大企業では、事故後の影響範囲が広く、あとからの是正も重くなります。だからこそ、機密性が高い業務では、ローカルLLMやオンプレミス構成を早い段階から比較対象に入れるのが現実的です。
