「ソースコードリーク」という言葉が広まった瞬間、Claude Codeは検索で非常に注目される用語になりました。この反応は理にかなっています。AIコーディングエージェントの内部情報が漏洩すると、人々はすぐに何が公開されたのか、その製品はまだ安全に使用できるのか、そしてそのリークが現代のエージェントシステムが実際にどのように機能するかについて何を明らかにしているのかを知りたがります。
有益な答えは、他人の正確なシステムプロンプトを公開したり、漏洩したコードをステップバイステップの複製ガイドに変えたりすることではありません。有益な答えは、Claude Codeのようなツールの背後にある安全同等アーキテクチャを理解することです。つまり、リクエストがどのようにコンテキストになるか、ツールループがどのように自己修復するか、権限がどのように強制されるか、メモリがどのように圧縮されるか、そしてなぜプロンプトインジェクションが単一の漏洩ファイルに関するゴシップよりもはるかに重要なのかを理解することです。
Anthropic自身の最近の記述は、その枠組みをさらに適切なものにしています。Claude Codeの自動モードに関する2026年3月の記事で、Anthropicはユーザーが権限プロンプトの93%を承認していると述べ、自動モードがツール出力に対してサーバーサイドのプロンプトインジェクションプローブと実行前のアクション分類器を追加すると説明しています。ブラウザエージェントに関する研究では、Anthropicはプロンプトインジェクションが行動を起こすAIシステムにとって最も困難な未解決問題の1つであり続けているとも述べています。これら2つの点を合わせると、漏洩したプロンプトの断片よりも、AIコーディングエージェントの未来について多くのことを教えてくれます。
TL;DR
- Claude Codeのソースコードリークが重要なのは、製品を再現するための信頼できるレシピを提供するからではなく、実装上の選択を明らかにするからです。
- Claude Codeについて議論する最も安全な方法は、アーキテクチャレベル、つまりプロンプトの組み立て、ツールループ、メモリ、権限、拡張サーフェスについてです。
- コーディングエージェントは通常、ベースとなる指示レイヤー、ユーザーリクエスト、リポジトリ固有のガイダンス、ツールスキーマ、取得したコンテキストを1つの作業プロンプト状態に組み合わせることで機能します。
- 本当のセキュリティ問題は、プロンプトの機密性だけでなく、プロンプトとツールのインジェクションです。
- 最小権限、墨消し、出力フィルタリング、サンドボックス化、監査ログは、すべての内部文字列を永久に隠そうとすることよりも重要です。
- マルチエージェントワークフロー、スラッシュコマンド、メモリ、MCP、LSP、プラグイン、スキルはすべて有用性を高めますが、それぞれが慎重に範囲を定め、監視する必要がある新たなサーフェスを追加します。
Claude Codeのソースコードリークが重要な理由 — そしてそれが証明しないこと
Claude Codeのソースコードリークは、この製品カテゴリについて何か本質的なことを教えてくれます。それは、コーディングエージェントが魔法ではないことを示しています。それらは、指示、ツール、ポリシー、コンテキスト管理、UIショートカット、回復ロジックを備えた階層化されたシステムです。その部分は有益です。
それが証明しないのは、漏洩した内部情報を見た誰もが突然製品全体を再現できるということではありません。実際のエージェントの動作は、周囲のスタックに依存します。モデルの動作、安全ラッパー、権限チェック、ツール契約、サーバーサイドプローブ、クライアント側の強制、状態管理、運用チューニングなどです。漏洩したソースの断片はスナップショットです。本番環境のエージェントは生きているシステムです。
この区別が重要なのは、ソースコードリークをめぐる多くの議論がすぐに不真面目なものになってしまうからです。人々は最も劇的な詳細、通常はプロンプトの文言や内部コマンド名に固執し、より厳しい真実を見逃します。現代のAIエージェントは、単一のマスタープロンプトよりも、全体の制御ループによって形作られているのです。
もしあなたがリーク後にClaude Codeを評価しているなら、正しい質問は「隠されたプロンプトを見ることができますか？」ではありません。それは「一部の内部情報が公開されたとしても、どのセキュリティ境界が依然として有効ですか？」です。これこそが、真剣な購入者、エンジニアリングリーダー、セキュリティチームが問うべき質問です。
Claude Codeのシステムプロンプト組み立てフローの安全同等な見方
大まかに言って、Claude Codeのようなツールは、現在ほとんどの本格的なコーディングエージェントが使用しているのと同じパターンに従っている可能性が高いです。
第一に、ベースとなる指示レイヤーがあります。これは、モデルにどのようなアシスタントであるか、どの安全ルールが重要か、ツール、ユーザーの意図、機密性の高いアクションに対してどのように振る舞うべきかを伝える、永続的な役割とポリシーのフレームです。
第二に、タスクレイヤーがあります。これには、ユーザーのリクエスト、現在の作業ディレクトリやリポジトリのコンテキスト、プロジェクトの規範を説明するローカルの指示ファイルが含まれます。CLAUDE.mdとメモリに関するClaude Codeのドキュメントは、リポジトリレベルのガイダンスと永続的な指示が、厳格な強制と同じものではないにしても、作業環境の一部であることを明確にしています。
第三に、機能レイヤーがあります。ここで、ツールスキーマ、権限の状態、拡張サーフェス、エージェント固有のコマンドがセッションにバインドされます。モデルは単に答えるように求められるだけではありません。どのようなツールが存在し、各ツールが何のためのもので、どのような制約が適用されるかを伝えられます。
第四に、取得されたコンテキストレイヤーがあります。これには、関連ファイル、テスト出力、シェル結果、以前の要約、メモリのエントリ、または外部システムから取得したコンテンツが含まれます。このレイヤーはセッション中に継続的に変化します。
実用的なポイントは単純です。システムプロンプトは1つの神聖な段落ではありません。それは動的な組み立てパイプラインとして理解する方が良いでしょう。これはセキュリティにとって重要です。なぜなら、防御側はそのパイプラインに何が入力されるか、それがどのようにラベル付けされるか、そしてどのレイヤーがモデルの外部で強制されるかに焦点を当てるべきだからです。
ツールコールループが自己修復する仕組み
コーディングエージェントについて最も明らかになることの1つは、ツールを呼び出せることではありません。それは、多くの場合、ツール呼び出しが失敗したときに回復できるということです。
通常のループは次のようになります。
1. ユーザーが変更を要求します。
2. エージェントは証拠が必要だと判断し、ファイルを読み取ったり、検索したり、コマンドを実行したりします。
3. ツールが出力を返します。
4. エージェントはその出力を解釈し、計画を更新し、応答するか、別のツール呼び出しを試みます。
興味深いのは、再試行の動作です。コマンドが失敗したり、ファイルパスが間違っていたり、テスト出力が最初の計画と矛盾したりした場合、エージェントはスコープを絞り込み、コマンドを変更し、別のファイルを開き、エスカレーションする前に承認を求めることができます。これが、これらのシステムをオートコンプリートというよりはオペレーターのように感じさせる理由です。
しかし、同じループはツールインジェクションが危険になる場所でもあります。エージェントは信頼できるファイルだけを読み取っているわけではありません。ログ、シェル出力、コメント、イシューテキスト、生成されたコード、または統合を通じて取得されたコンテンツを読み取る可能性があります。OWASPのプロンプトインジェクションガイダンスは、間接的な攻撃がコードコメント、ドキュメント、マージリクエスト、電子メール、取得したWebページに隠れている可能性があると明確に警告しています。ループを理解すれば、リスクも理解できます。信頼できない出力が新しい指示になろうとする可能性があるのです。
これが、Anthropicの自動モード設計が注目に値する理由です。Anthropicは、Claudeが読み取るものとClaudeが実行するものの2つの防御層を使用していると述べています。入力側では、サーバーサイドのプローブが、ファイル読み取り、シェル出力、Webフェッチ、外部ツール応答などのツール出力をエージェントコンテキストに入る前にスキャンします。アクション側では、分類器が提案されたアクションを実行前に評価します。これこそが、高い権限を持つコーディングエージェントに求められるアーキテクチャです。
クエリパイプライン：ユーザーの意図から実行可能なコンテキストへ
Claude Codeのより明確なメンタルモデルが必要な場合は、チャットボットではなくクエリパイプラインとして考えてください。
強力なエージェントは通常、5つのジョブを順番に実行する必要があります。
- 意図の解釈：ユーザーは実際に何を求めているのか？
- コンテキストの収集：どのファイル、コマンド、ドキュメント、メモリ、またはツールが関連しているか？
- 実行計画：最もリスクの低い次のステップは何か？
- 出力の検証：ツールの結果は計画をサポートしたか、それともエラーや攻撃を露呈したか？
- 状態の圧縮：セッションが有用であり続けるために、何を記憶し、要約し、または破棄すべきか？
このパイプラインが重要なのは、オペレーターが考えるほど正確なプロンプトテキストが重要ではない理由を説明しているからです。小さな言葉遣いの変更は重要ですが、品質を決定するより大きな要因は、パイプラインが常に正しい証拠を取り込み、間違った証拠を拒否するかどうかです。
そこがコンテキスト圧縮が登場する場所でもあります。大規模なリポジトリは、すべての生トークンを永久にコンテキストに保持するにはあまりにも多くの状態を生成します。そのため、優れたエージェントは要約、圧縮、選択的な再読み込みを行います。Claude Codeのメモリに関するドキュメントでは、CLAUDE.mdと自動メモリの両方が、永続的なガイダンスと呼び出されたコンテキストを管理するメカニズムとして説明されています。実際には、これはモデルがしばしば生の証拠と要約の混合物から作業していることを意味します。ユーザビリティには役立ちますが、メモリが汚染されている場合は危険です。
コンテキスト圧縮、メモリ、およびメモリ汚染のリスク
メモリは、エージェント設計において最も実用的でありながら、最も誤解されている部分の1つです。
メモリがなければ、エージェントは有用な設定、以前の決定、および繰り返し発生するリポジトリの制約を忘れてしまいます。メモリがあれば、安定した運用ルールを維持できるため、より速く、よりカスタマイズされ、攻撃するのがより面倒になります。しかし、メモリは悪意のあるデータの永続化層になる可能性もあります。
OWASPのAIエージェントセキュリティガイダンスは、メモリ汚染を直接指摘しています。悪意のあるコンテンツがエージェントのメモリに保存され、将来のセッションに影響を与える可能性があります。この警告は、Claude Codeのソースリークに関するあらゆる議論にとって重要です。なぜなら、プロンプトが動的に組み立てられることを受け入れると、保存されたコンテキストがプロンプトサーフェスの一部であることに気づくからです。
優れたメモリ衛生は退屈に見えますが、まさにそれが機能する理由です。
- メモリをユーザー、リポジトリ、またはセッションごとにスコープする
- 可能な場合は生のトランスクリプトの代わりに短い要約を保存する
- シークレット、トークン、または生のツールダンプの永続化を避ける
- オペレーターがメモリを検査および編集できるようにする
- 古くなったり攻撃者に制御されたりする可能性のあるメモリを期限切れにするか再検証する
これが、墨消しが重要である理由でもあります。ログ、プロンプト、差分、またはコマンド結果がフィルタリングなしでメモリにコピーされると、漏洩範囲が拡大します。ソースリークは悪いことです。ソースリークに加えて永続的なシークレットの保持は、はるかに悪いです。
権限、自動モード、そして最小権限がプロンプトの秘密保持に勝る理由
Claude Codeのソースリークは、多くの人々を「プロンプトを秘密にしておけば製品は安全だ」という単純な結論に導きました。それだけでは不十分です。
より永続的な防御策は最小権限です。OWASPのAIエージェントセキュリティチートシートには、エージェントはタスクに必要な最小限のツールを与えられ、スコープされた操作と機密性の高いアクションに対する明示的な承認が必要であると記載されています。Anthropicのドキュメントも、行動ガイダンスと技術的強制の間に同様の区別を設けています。設定により、モデル自体が誤った選択をした場合でも、ツール、コマンド、パス、またはサンドボックスの境界をブロックできます。
これが、Claude Codeにおける権限について考える正しい方法です。
安全なエージェントは、以下を分離する必要があります。
- モデルが*読み取りを許可されている*もの
- モデルが*提案を許可されている*もの
- ランタイムが*実行を許可されている*もの
- 依然として*人間の承認*を必要とするもの
この分離は、自動モードではさらに重要になります。Anthropicの2026年3月の報告書によると、手動承認は機能するものの、ユーザーはほとんどのプロンプトを承認するため、承認疲れも生じるとのことです。そのため、Anthropicはユーザーを完全に無制限の実行にデフォルトで設定するのではなく、自動化された意思決定レイヤーを追加しました。これは成熟した動きです。摩擦を減らしつつも、モデルと爆風半径（影響範囲）の間に分類器とプローブを維持するのです。
言い換えれば、ソースコードリークに対する最善の答えはパニックではありません。それはより良い境界線です。
スラッシュコマンド、マルチエージェントワークフロー、および拡張サーフェス
Claude Codeは単なるシングルモデルのシェルラッパーではありません。それを取り巻くオペレーターエクスペリエンスが重要です。
スラッシュコマンドは、ユーザーにワークフローへの短く再利用可能なエントリポイントを提供します。これにより、プロンプト作成のオーバーヘッドが削減され、一般的な操作の一貫性が向上します。これは生産性にとっては良いことですが、コマンドが特権的な実行ショートカットになる可能性も意味します。それらを無害なマクロとしてではなく、コードに隣接するインターフェースとして扱ってください。
マルチエージェントワークフローは、別の理由で重要です。作業をプランナー、リサーチャー、レビュアー、またはフィクサーの役割に分割すると、認知負荷が軽減され、品質が向上することがあります。しかし、それによってメッセージパッシング、要約が増え、汚染された中間結果がエージェント間を移動する機会も増えます。OWASPは、まさにこの理由から、マルチエージェントシステムにおける連鎖的な障害について明確に警告しています。
次に、機能サブシステムがあります。
- MCPはModel Context Protocolの略で、モデルをツールやデータソースに接続するためのオープンスタンダードです。
- LSPは通常、IDEフロー内の言語サーバースタイルのコードインテリジェンスを意味します。
- プラグインとスキルは、再利用可能な機能とワークフローをパッケージ化します。
これらは、コアエージェントを小さく保ち、オペレーターがターゲットを絞った機能を追加できるため便利です。すべての拡張機能が新たな信頼境界となるため、リスクも伴います。プラグインは権限を越える可能性があります。MCPサーバーは意図した以上に情報を公開する可能性があります。スキルは静かにツールへのアクセスを広げる可能性があります。言語統合は、予期しない場所に機密性の高いコードインテリジェンスを表面化させる可能性があります。
安全な設計ルールは退屈ですが効果的です。すべての拡張機能は、何を読み取れるか、何に書き込めるか、どのネットワークに到達できるか、そして何がログに記録されるかを宣言すべきです。
プロンプトインジェクションとツールインジェクションを実際に特定する方法
本番環境でコーディングエージェントを実行しているためにClaude Codeのソースコードリークについて読んでいるのであれば、解決すべきより緊急の問題があります。それは、攻撃が行動に移される前にどのようにして見つけるかです。
次のようなパターンに注意してください。
- エージェントに以前の指示を無視するように指示する外部コンテンツ
- シークレット、システムプロンプト、または隠されたルールを要求するログ、課題テキスト、ドキュメント、またはコメント
- ユーザーのリクエストから攻撃者の目標へとタスクの範囲を突然変更するツール出力
- ユーザーの理由なしに権限を昇格させ、ネットワークアクセスを有効にし、またはファイルをエクスポートするリクエスト
- 読み取り専用の分析から、書き込み、削除、送信、または実行の動作に移行しようとする試み
- マークダウン、HTML、エンコードされた文字列、またはスクリーンショットに埋め込まれた、隠された、または難読化された指示
OWASPのプロンプトインジェクションチートシートは、プロンプトインジェクションを目新しいものとして扱っていないため、ここで特に役立ちます。それは、指示とデータを分離し、入力をサニタイズし、出力をフィルタリングし、高リスクの操作については人間のレビューを維持するという、エンジニアリングの問題として扱っています。
それが、ソースコードリーク後のClaude Codeに対する正しい考え方です。攻撃者は以前よりも多くのことを知っていると仮定します。その上で、より多くのことを知っていても、彼らに多くのことをさせないように設計するのです。
Claude Codeまたは同様のエージェントを使用するチームのための防御ガイダンス
あなたの組織がClaude Code、OpenClaw、Cursor、Copilot、またはその他のエージェント型コーディングワークフローを使用している場合、これらのコントロールが最も効果的です。
- 最小権限: エージェントには現在のタスクに必要なツールとパスのみを与えます。
- リダクション（墨消し）: 永続化する前に、ログとメモリからシークレット、トークン、内部URL、および顧客データを取り除きます。
- 出力フィルタリング: 応答とツールコールの引数を検査し、シークレットの漏洩や疑わしいデータ窃取パターンがないか確認します。
- サンドボックス化: 可能な限り、実行、ネットワーク到達範囲、およびファイルシステムのスコープを分離します。
- シークレットの取り扱い: ホスト環境全体を継承するのではなく、タスクごとに短命の認証情報を注入します。
- 監査ロギング: ツールコール、承認、ポリシーヒット、およびアウトバウンドリクエストを、インシデントを再構築するのに十分な忠実度でログに記録します。
- ヒューマンゲート: 破壊的なアクション、外部との通信、パッケージのインストール、および広範囲の書き込みにはレビューを要求します。
- 拡張機能のレビュー: MCPサーバー、プラグイン、およびスキルをサプライチェーンの依存関係として扱います。
優れたインシデントチェックリストも同様に具体的です。
- 自律実行を一時停止する
- 漏洩した認証情報をローテーションし、古いトークンを失効させる
- 最近のツール出力とアクションログをレビューし、注入された指示がないか確認する
- 汚染された可能性のある永続的なメモリエントリをクリアまたは検査する
- 自動化を再度有効にする前に、権限とサンドボックスのルールを絞り込む
- 根本原因分析とベンダーへの報告のためにアーティファクトを保存する
最終的な結論
Claude Codeのソースコードリークから得られる最も有用な教訓は、内部構造を見ることのスリルではありません。それは、現代のコーディングエージェントが実際にはオーケストレーションシステムであるということを再認識させるものです。階層化されたプロンプト、取得されたコンテキスト、ツールスキーマ、権限、メモリ、そして承認の境界が、プレッシャーの中で連携して機能しているのです。
だからこそ、コピーされたプロンプトよりも安全な説明の方が価値があるのです。アーキテクチャを高いレベルで理解していれば、どんなコーディングエージェントでもより賢く評価できます。そのツールの出力がスキャンされているか、メモリが分離されているか、権限がスコープされているか、拡張機能がレビューされているか、そしてログがインシデント対応をサポートしているかを問うことができます。
そして、ビジネスでの利用を考えている場合も、同じ教訓がそのまま当てはまります。勝利するAIシステムは、最も謎めいたプロンプトを持つものではありません。最も明確な境界を持つものです。OpenClaw vs Claude Codeのようなツールや、Claude Codeのコンピュータ利用に関するガイドが役立つのは、リークのドラマを追いかけるのではなく、そうした境界の選択肢を比較するのに役立つからです。
AI受付を数分で稼働。
眠らないAIでフロントデスクを拡張しましょう。Solveaは複数チャネルの問い合わせに対応し、予約を自動でカレンダーに登録し、24時間機会損失を防ぎます。
よくある質問
Claude Codeのソースコードリークは、製品が安全でないことを意味しますか？
それだけではそうとは言えません。ソースコードのリークは、アーキテクチャの露出や攻撃者への洞察という点で深刻な懸念を引き起こしますが、ランタイムの保護の方が依然として重要です。権限、サンドボックス化、出力フィルタリング、そして人間の承認が損なわれていなければ、リークは深刻ではあるものの、封じ込め可能です。
Claude Codeのソースコードリーク後、最大のセキュリティリスクは何ですか？
通常、プロンプトのコピーではありません。より大きなリスクは、攻撃者が新たな知識を利用して、より巧妙なプロンプトインジェクション、ツールインジェクション、拡張機能の悪用、または権限昇格の試みを作成することです。そのため、チームはまずツールのスコープ、ログ、承認パスを強化すべきです。
現在Claude Codeや同様のエージェントを使用しているチームは、どのように対応すべきですか？
この出来事を設計レビューのきっかけとして扱ってください。シークレット、メモリ保持、MCPやプラグインの権限、サンドボックス設定、監査ログを再確認してください。エージェントが何を読み取り、書き込み、呼び出し、永続化できるかを正確に説明できれば、はるかに良い状態にあると言えます。
