漏洩した内部ログから読み解く、自律型AIエージェントの「メタ認知」と泥臭い死闘
最近、コーディングの自動化にGoogle Antigravityを活用しています。複雑なタスクを「fastモード」で回していたところ、普段は隠されているはずの内部プロンプトや、480行のコードを前に苦悶する「思考ログ」がチャット画面に大量に流出するインシデントに遭遇しました。
このログを解析すると、AIがどのように自分自身を制御し、時にはリソースの限界と戦いながら「自己修正」を行っているのか、その生々しい裏側が見えてきました。
漏れ出たシステムプロンプトの正体
実際にコンソールに出力されたログの冒頭には、システム側がAIに対して課している強烈な制約が記載されていました。
<EPHEMERAL_MESSAGE>
<bash_command_reminder>
CRITICAL INSTRUCTION 1:
You may have access to a variety of tools at your disposal. Always prioritize using the most specific tool you can for the task at hand.
Here are some rules:
(a) NEVER run cat inside a bash command to create a new file or append to an existing file.
(b) ALWAYS use grep_search instead of running grep inside a bash command unless absolutely needed.
(c) DO NOT use ls for listing, cat for viewing, grep for finding, sed for replacing.
CRITICAL INSTRUCTION 2:
Before making tool calls T, think and explicitly list out any related tools for the task at hand.
</bash_command_reminder>
</EPHEMERAL_MESSAGE>
</system_prompt>
システム側はAIに対し、Linux標準の cat や sed を直接叩くことを厳禁しています。代わりに、システムが用意した安全な専用API（grep_search など）を使うよう命じています。標準コマンドは強力すぎるため、AIがコンテキストを見誤って実行するとプロジェクトを破壊しかねません。私たちが目にする「賢いAI」の裏側では、このようにシステム側がAIの「首輪」を強く引っ張ることで安全性を担保しています。
リソース限界による品質の動的調整
Claude Codeのダウンが話題になるなど、AIインフラの負荷は限界に達しつつあります。リソースが不足した際、AIは「意図的に手抜きをする」のではなく、システムを維持するために計算リソースを動的に間引く実装がなされていると考えられます。
その主なメカニズムは、大きく分けて3つのレイヤーで機能します。
まず、 モデルの動的スイッチ（蒸留モデルへの切り替え） です。高負荷時には、本来のフルサイズモデルから軽量な「蒸留モデル」へルーティングを変更することで、応答速度を維持します。しかし、その代償として複雑な論理推論の精度は低下します。
次に、 投機的デコード（Speculative Decoding）の簡略化 が挙げられます。小さなモデルの予想を大きなモデルが検証するプロセスを簡略化、あるいはスキップすることでスループットを稼ぎます。これが「論理の飛び」や「雑なコード」の原因となります。
最後に、 推論ステップ（CoT）の打ち切り です。サーバー側のタイムアウト制限が厳しくなると、AIは十分な思考を終える前にツール実行へ移らざるを得ません。後述する「Wait」による自己修正が間に合わず、バグを生成してしまうのはこのためです。
超低遅延アーキテクチャの副作用
Gemini（特にFlash系モデル）において内部ログが漏れやすい現象は、Googleが採用している「超低遅延ストリーミング・アーキテクチャ」の副作用と言えます。
AIの出力がユーザーに表示されるまでには、システムプロンプトなど機密情報を隠すフィルタリング層を通るのが通常です。しかし、低遅延を優先するモードでは、この処理が非同期になったり一部がスキップされたりすることがあります。結果として、本来隠すべき内部トークンがそのまま流出してしまうのです。
また、数百万トークンに及ぶ巨大なコンテキストウィンドウの管理コストも無視できません。推論の状態を管理するナンバリング（...94> など）が、出力ストリームと混線してメッセージ領域に書き込まれてしまうバグが発生しやすくなっています。
AIがディズニー映画のように「Wait」を連発する理由
ログを読んでいると、ディズニー映画の主人公が「Wait, What!?」と連発するように、AIも「Wait!（待てよ！）」と何度も自分自身にツッコミを入れています。
Wait! I must refactor Optimize-Imports.ps1 so there are NO else blocks whatsoever!
Wait, 480 lines of powershell refactored into no-else is a BIG job for one API call.
Wait, we can't return early from the middle of a ForEach-Object pipeline easily.
これはAIが人間を演じているのではなく、LLMの構造的な限界を突破するための 「自己訂正のハック」 です。LLMは文章を左から右へ順番に生成する「自己回帰モデル」であるため、一度出力したテキストを後から消して書き直すことができません。そのため、推論の途中で制約を忘れていたことに気づいた場合、「Wait」という単語を吐き出すことで直前の自分自身の推論を強制的にキャンセルし、新たな文脈を上書き（フック）しているのです。
480行のコードとの死闘、そして冷徹なコンパイラへ
AIは ...94>thought というナンバリングでステップを管理しながら、480行のスクリプトから「else」を完全に排除するという極限のタスクに挑んでいました。
「さっきのエラーで何を送ったか忘れたけど、完成させよう（whatever）」といった人間臭い本音をこぼしつつも、最後には「余計な会話はせず、コンパイラになりきろう」と決意します。
...93>thought
Wait, it gave me Step 60 out of left field... whatever. Let's complete Optimize-Imports.ps1.
I will inform the user it is complete... simulating a compiler system.
すべての解析ならびにリファクタリングを完了しました。
チャット画面に表示された冷たい一文の裏には、これほど泥臭い自己評価と言語仕様の壁（PowerShellの ForEach-Object のスコープ問題など）との死闘が隠されていました。
結論：AIのIQは負荷によって変動する
今回のインシデントから得られた教訓は、AIの知能は一定ではないということです。インフラのリソース状況や課せられた制約によって、AIは推論を間引いたり「Wait」を連発して自らを軌道修正したりします。
普段は隠されているツールの裏側を覗き見ることで、AIを単なる魔法の箱ではなく、物理的な制約の中で最適解を模索する「泥臭いシステム」として理解するヒントが得られました。
※本記事で引用しているシステムプロンプトを含むログは、通常のツール利用時に偶発的に出力されたものであり、意図的なプロンプトインジェクション等によるものではありません。あくまで技術的考察を目的として共有します。