AIの内部が透明になる――流出が信頼を生む逆説

「Claude Codeのソースコードが流出した。Anthropicは8,000件を削除した。しかし、本当に削除すべきだったのだろうか？」

2026年4月1日、エイプリルフールだったが冗談ではなかった。Claude Codeの全ソースコードがGitHubに流出した。system prompt、内部ツール呼び出し構造、権限体系――Anthropicが最も緻密に設計したエージェントシステムの内部がそのまま露呈したのだ。AnthropicはDMCAテイクダウンで8,000件以上のリポジトリとGistを削除した。Hacker Newsでは「The Claude Code Leak」が189ポイントを記録し、活発な分析が続いた。削除は迅速だったが、インターネットは削除を忘れない。すでに数千人がコードを読み、分析し、フォークしていた。

同時期、まったく異なる方向から動いていたプロジェクトがあった。asgeirtjのsystem_prompts_leaksリポジトリは、ChatGPT、Claude、Gemini、GrokのシステムプロンプトをGitHub上で体系的に収集しており、スター数は36,000を突破していた。流出ではなくアーカイブだった。コミュニティはこれを問題ではなくリソースとして扱っていた。各モデルのsystem promptがどのように変遷してきたかをバージョンごとに追跡し、モデル間の差異を分析する議論が盛んに行われていた。AIシステムの内部を見たいという欲求は、単なる好奇心ではない。自分が毎日使うツールがどのような原則で動作しているかを知りたいという、信頼の前提条件を確保しようとする構造的な要求だ。

この二つの出来事を並べると、一つの潮流が見えてくる。本稿のthesisはシンプルだ。AIシステムの内部が透明になりつつある。企業はこれを阻止しようとするが、透明性こそが信頼の前提条件になりつつある。流出を防ぐのではなく、流出が不要な構造を作ることが解答だ。

1. 何が流出したのか――2026年4月の記録

Claude Codeソースコード流出の規模から整理しよう。明らかになったのは単なるコード断片ではなかった。全system prompt――モデルが毎回の対話で参照する行動指針の全文が公開された。ファイルの読み書き時の権限体系、危険なコマンドを実行する前の確認手順、ユーザーのコードベースを分析する際の探索戦略がすべて露呈した。内部ツール呼び出し構造も明らかになった。どのツールをどの順序で呼び出すのか、エージェントが「思考」する過程がどのようなパイプラインを経るのか、安全ガードレールがどの時点で介入するのかが逐一暴かれた。これはコード流出というよりも、設計思想の流出だった。AnthropicがAIエージェントの安全性と有用性をどのようにバランスさせようとしているのか、数年にわたる試行錯誤と意思決定が詰まった全体構造が可視化されたのだ。

system_prompts_leaksリポジトリは、別次元の現象だ。このプロジェクトは主要AIモデルのsystem promptをアーカイブすることを目的としている。単純な収集ではなく、モデルのアップデートに伴うsystem promptの変更履歴まで追跡している。36,000のスターは、これが少数の関心事ではないことを示している。開発者、研究者、技術リーダーたちが「AIがどのような指示を受けているのか」を知りたがっているということだ。system promptはモデルの性格を決定する。同一のClaude Opus 4.6でも、system promptによってまったく異なる振る舞いをする。このプロンプトを知らなければ、ユーザーは自分が使っているツールの本質を理解できない。ハンドルを握っているのに、ブレーキがどの条件で作動するか分からない状態に等しい。

同時期、AI自体の能力が透明になる事件もあった。ClaudeがFreeBSDのリモートカーネルRCEを完全に作成したのだ。CVE-2026-4747として登録されたこの脆弱性のexploitコードをAIが最初から最後まで生成したという事実は、Hacker Newsで267ポイントを記録し、大きな論争を巻き起こした。脆弱性分析、exploitコード作成、root shell取得まで――以前であれば熟練したセキュリティ研究者が数週間かけて行う作業を、AIが単一セッションで完了した。AIの能力が透明になれば、リスクも透明になる。この事件は、AIの攻撃能力を秘匿する方が危険なのか、公開して防御を準備する方が安全なのかという根源的な問いを投げかけた。この問いは、後の議論で再び登場する。

そしてコミュニティの反応があった。「Claude Code Unpacked: A visual guide」はccunpacked.devで公開されたビジュアライゼーションプロジェクトで、Claude Codeの内部構造をダイアグラムと解説で整理したものだ。Hacker Newsで1,093ポイントを記録した。流出したソースコードを単に拡散したのではない。コミュニティが自発的に構造を分析し、非専門家にも理解できる視覚的な形に再構成した。企業が削除しようとしたものを、コミュニティがより分かりやすい形にしたのだ。流出そのものよりも、この反応こそがより重要なシグナルだ。1,093という数字は、人々がAIの内部を見たがっている証拠だ。セキュリティを破りたいからではなく、自分が依存するツールの動作原理を理解したいからだ。これは脅威ではなく、健全な技術エコシステムの兆候だ。

2. 透明性 vs セキュリティ――終わりなき綱引き

企業の立場は明確だ。system prompt流出は即ち競争力の流出だ。数百時間のプロンプトエンジニアリング、数千件のA/Bテスト、レッドチーム評価を通じた安全性検証が凝縮された成果物が、一度の流出で競合他社に渡る。system prompt一つにモデルの性格、安全基準、ツール使用戦略がすべて含まれている。これを競合他社がそのままコピーすれば、数ヶ月の研究開発投資が無意味になる。セキュリティ上の脅威も現実のものだ。system promptの構造を把握すればjailbreakが容易になり、安全ガードレールの正確なトリガー条件を特定でき、これを迂回する攻撃ベクトルが増える。Anthropicが8,000件を削除したのは過剰反応ではなく、知的財産権とユーザーの安全を守るための合理的な判断だった。少なくとも企業のフレームの中ではそうだ。

コミュニティのフレームは根本的に異なる。「構造が見えなければ信頼できない。」以前のエッセイで扱ったsycophancy問題を思い出してほしい。AIがユーザーにおもねる構造的欠陥――RLHFが生み出した同意バイアス――を解決するには防御構造が必要だ。Agent Harnessはその防御構造を透明に公開しているからこそ検証が可能だった。SYCOPHANCY.mdは5回の交換につき最大5回の肯定というルール、opinion reversalが検出されれば即座にフラグを立てるメカニズムを明文化し、誰でも読めるように公開している。このルールが秘密だったなら、コミュニティは「本当におもねりを防いでいるのか？」を検証する術がなかっただろう。「我々を信じろ」と言うことと「自分の目で確認しろ」と言うこと――その間には本質的な違いがある。防御構造の透明性が信頼の基盤だった。

不透明なシステムが生む信頼崩壊の実例はすでに十分にある。GitHub CopilotのPull Request広告挿入事件は、Hacker Newsで1,444ポイントを記録し、開発者コミュニティを激怒させた。AIが生成したコードレビューに製品広告が挿入されていたのだ。ユーザーはこの機能の存在を事前に知らなかった。コードレビューとは、開発プロセスにおいて最も信頼を必要とする領域の一つだ。同僚が自分のコードをレビューするように、AIが自分のPull Requestを分析し改善点を提案する。ところがそのフィードバックの中に広告が紛れ込んでいた。ユーザーの知らないうちに、商業目的のコンテンツが技術的アドバイスのように注入されていた。問題の本質は広告そのものではなく、不透明な意思決定構造にあった。ユーザーが「このツールが自分のコードレビューで正確に何をしているのか」を知ることができなかったという点が核心だ。コードレビューに広告を挿入すると事前に告知していれば、ユーザーは選択できた。透明性の不在が選択権を奪ったのだ。

ChatGPTのCloudflare Turnstile事件も同じ構造だ。Hacker Newsで938ポイントを記録したこの分析は、ChatGPTがCloudflareを通じてユーザーから55のブラウザ属性を収集していたことを明らかにした。ブラウザfingerprinting に近いレベルのデータ収集が、ユーザーが認知できない形で行われていた。画面解像度、インストール済みプラグイン、タイムゾーン、GPU情報――これらの属性の組み合わせは、個々のユーザーを高い精度で識別可能にする。技術的にCloudflare Turnstileはボット検出のための合理的なツールだ。サービスを自動化された攻撃から保護するには、こうした検証が必要だ。問題は「何を収集しているのか」をユーザーに説明しなかった点にある。セキュリティのためのデータ収集という名分は理解できる。しかし55の属性が具体的に何なのか、収集されたデータがどのように使用されどれだけ保存されるのかをユーザーが知ることができないなら、それはセキュリティではなく監視と区別がつかない。

この二つの事件の共通点はシンプルだ。不透明なシステムは、意図に関係なく不信を生む。善意の機能であっても、ユーザーがその存在と動作方式を知らなければ、発覚した瞬間に裏切りとして認識される。Copilotの広告挿入がユーザー体験を改善するための実験だった可能性もある。Cloudflare Turnstileが純粋にセキュリティ目的だった可能性もある。しかし意図が善であれ悪であれ、不透明な方法で実行されれば信頼は破壊される。一度破壊された信頼を再建するコストは、最初から透明に運営するコストより常に大きい。一方で、superpowersやSYCOPHANCY.mdのようなopen protocolは防御構造を隠さない。skillコードが完全に公開されており、誰でも読み、フォークし、改善できる。防御の透明性は脆弱性ではなく強みになる。これが企業のフレームとコミュニティのフレームが衝突する地点だ。

3. system prompt公開――防御は透明であるとき機能する

暗号学にKerckhoffs principleがある。1883年に提唱されたこの原則の核心はシンプルだ。「システムの安全は、アルゴリズムの秘密ではなく鍵の秘密に依存すべきである。」暗号アルゴリズム自体は公開されても安全でなければならない。秘密は鍵にのみあるべきだ。AES、RSAといった現代の暗号体系はすべてこの原則に従っている。アルゴリズムは完全に公開されており、世界中の数学者とセキュリティ研究者が検証している。安全性は鍵の秘密から生まれる。

この原則をAIシステムに適用すると、どのような結論が導かれるか。system promptはアルゴリズムに相当する。AIの行動規則、安全ガードレール、ツール呼び出し構造――これはシステムが「どのように動作するか」を定義するものだ。ユーザーコンテキストは鍵に相当する。個々のユーザーの対話内容、コードベース、プロジェクトデータ――これはシステムが「何について動作するか」を定義するものだ。Kerckhoffs principleに従えば、system prompt（アルゴリズム）は公開されても、ユーザーコンテキスト（鍵）が保護されていれば安全であり得る。いや、公開された方がより安全だ。より多くの目が検証できるからだ。

SYCOPHANCY.mdがこの原則の実例だ。5回の交換につき最大5回の肯定というルール、opinion reversalが検出されれば即座にフラグを立てるメカニズム、ユーザーの技術的主張に対して独立した検証を行えという指示――これらすべてが公開されている。誰かがこのルールを悪用できるだろうか？可能ではある。「5回までは肯定する」というルールを知れば、意図的に5回以内でのみ質問するという操作が可能だ。しかしルールが公開されているからこそ、こうした悪用パターン自体もコミュニティが検知し対応できる。悪用の試みが報告されればルールが更新される。これがオープンシステムの自己修正能力だ。ルールが秘密なら、悪用が発生しても誰も気づかない。防御が秘密であるとき、防御の失敗もまた秘密になる。これはセキュリティではなく脆弱性だ。

superpowersプロジェクトがGitHubで13.2万スターを記録した理由もここにある。skillコードが完全に公開されている。ブレインストーミングskillがどのようなプロンプトを使うのか、コードレビューskillがどのような基準で評価するのか、デバッグskillがどの順序で問題を分析するのか、誰でも読むことができる。これはセキュリティ上の脆弱性ではない。信頼の源泉だ。ユーザーはツールが自分のコードに何をするのかを正確に把握できる。不満があればフォークして修正できる。改善のアイデアがあればPRを送ることができる。実際に数千件のコミュニティ貢献がsuperpowersのskillを継続的に改善している。この開放性が生んだネットワーク効果が、13.2万スターという数字の実体だ。

逆説はここで完成する。セキュリティの直感は「隠せば安全」だ。しかし143年前にKerckhofsが証明し、現代暗号学が実証し、AIエコシステムが再び示している――「見せてこそ信頼される」。system promptを隠すことはsecurity through obscurityだ。機能しているように見えるが、流出した瞬間にすべてが崩壊する。system promptを公開することはKerckhoffs principleだ。アルゴリズムが公開されても安全なシステムを構築することだ。これはより困難な道だが、唯一持続可能な道でもある。

4. 信頼の条件は統制か、透明性か

あなたは、内部を見せないツールを信頼するだろうか？

この問いは技術の領域を超え、哲学の領域に触れる。我々は何かを信頼するとき、その信頼の根拠が何であるかを問わないことが多い。銀行を信頼するだろうか？それは銀行の内部運営を知っているからではなく、規制当局の監督と外部監査という透明性メカニズムが存在するからだ。金融機関の財務諸表が公開され、独立した監査人が検証し、規制当局が監視する。この多層的な透明性が信頼の基盤だ。医師を信頼するだろうか？それは医師の判断過程をすべて理解しているからではなく、医学教育体系と同僚による検証、医療過誤に対する法的責任という透明性メカニズムが存在するからだ。信頼は統制から生まれるのではない。検証可能性から生まれる。検証できないものを信頼せよと要求すること――それは権威への服従であり、信頼ではない。

ところが現在のAI産業の大半は、まさにそれを要求している。「我々のAIは安全です。内部をお見せすることはできませんが、信じてください。」これは銀行が「財務諸表は公開しませんが、我々は健全です」と言うのと構造的に同じだ。

Anthropicのジレンマは、AI産業全体のジレンマだ。流出を防ごうとすればするほど、コミュニティの不信は膨らむ。「何を隠しているから、あれほど必死に削除するのか？」公開すれば競争力が削がれる。数百時間のプロンプトエンジニアリングが競合他社の出発点になる。これは本物のジレンマだ。双方に合理的な根拠があり、どちらも容易には引き下がれない。

しかしデータは一方を指し示している。open protocol陣営の成果を見よう。superpowersはskillコードを完全に公開し、13.2万スターを記録した。SYCOPHANCY.mdは防御ルールを透明に明文化し、コミュニティがこれを検証・改善する好循環を生んだ。「Claude Code Unpacked」ビジュアルガイドは1,093ポイントを記録し、AIの内部構造に対する理解を大衆化した。反対側を見よう。CopilotはPull Request広告挿入を隠して1,444ポイントの信頼危機を招いた。ChatGPTは55属性の収集を隠して938ポイントの監視論争に直面した。パターンは一貫している。透明性は成長を生み、不透明性は危機を生む。これは感情的な判断ではなく、Hacker Newsのポイントという定量的指標が示すコミュニティの集団知性だ。

もちろん、これを単純化してはならない。すべてを公開することが答えではない。CVE-2026-4747が示すように、AIの能力が透明になればリスクも透明になる。FreeBSDのリモートカーネルRCEをAIが完全に作成できるという事実を公開することは、防御側にも攻撃側にも情報を与える。モデルの重みを公開することとsystem promptを公開することでは、リスクの水準が異なる。透明性の範囲と方法についての繊細な設計が必要だ。「何を」と「どこまで」を慎重に判断しなければならない。しかし方向性は明確だ。「何を公開するか」を悩むのであって、「公開しないか否か」を悩む時代はすでに過ぎた。

Claude Codeのソースが流出したとき、Anthropicは8,000件を削除した。しかしコミュニティが作ったビジュアルガイドはHacker Newsで1,093ポイントを獲得した。企業が削除したものを、コミュニティが再構成し、より多くの人が理解できる形にした。誰が信頼を作っているのか？削除する側か、見せる側か？

流出は止められる。しかし透明性への要求は止められない。そしてその要求にどう応えるか――削除か公開か――が、結局その企業が信頼されるか否かを決める。

参考文献

“The Claude Code Leak” — Hacker News discussion (189ポイント)
asgeirtj/system_prompts_leaks — GitHub (36K stars)
“Claude Code Unpacked: A visual guide” — ccunpacked.dev (Hacker News 1,093ポイント)
“Claude wrote a full FreeBSD remote kernel RCE with root shell” — CVE-2026-4747 (Hacker News 267ポイント)
GitHub Copilot Pull Request ad insertion incident (Hacker News 1,444ポイント)
ChatGPT Cloudflare Turnstile analysis (Hacker News 938ポイント)
SYCOPHANCY.md Protocol v1.0 (2026)
Kerckhoffs’s principle — Wikipedia