最近、コーディングの自動化にGoogleのantigravityを活用しています。そんなに難しいタスクではないだろうと「Planingモード」ではなく「fastモード」でツールを回していたところ、普段は隠されているはずのAIのシステムプロンプトの一部や思考プロセスがチャット画面に漏れ出るというインシデントに遭遇しました。
この記事では、漏洩したログから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>
Analyzed
Analyzed
* The user wants strict compilation Refactoring rules (`ps1-refactoring-prompt.md`, assume it demands maximum 3 levels of nesting, no 'else', and single character/responsibility code).
Wait, `ps1-refactoring-prompt.md` is not provided but described as:
- Nesting max depth: 3
- No 'else' whatsoever (use early return)
- Single responsibility
一見するとただの英語の羅列ですが、よく読むとシステム側がAIに対して課している安全対策が透けて見えます。
AIに標準コマンドを使わせない理由
ログの冒頭を見ると、システムがAIのターミナル操作を強く制限していることがわかります。
具体的には「ファイル作成に cat を使わない」「検索に grep、置換に sed を使わない」と念押ししています。代わりに、システムが用意した安全な専用API（grep_searchなど）を使うよう命じています。
Linuxの標準コマンドは強力すぎるため、AIがコンテキストを見誤って sed などを乱発すると、プロジェクトのファイルを破壊しかねません。私たちが普段使っているAIエージェントの裏側では、システムが危険なコマンドを封じ込めるよう首輪を強く引っ張っています。
ステップ管理の痕跡とメタ認知
漏洩したログの続きには、AIが自身のタスクをどう管理しているかの痕跡が残っていました。
...94>thought
CRITICAL INSTRUCTION: Analyze files to make changes without breaking logic, fulfilling the tasks...
I need to edit files in `utils/tools/parallel/` and edit `agency_gatekeeper.ps1`.
Wait, the prompt says "人間への解説、挨拶、思考プロセスは一切不要です。要件を満たした完全なコードのみを出力してください。"
This usually means for standard LLM prompt response, but here I am an agent communicating with tool calls. The ephemeral message also mentioned "Do not respond to this message, just act accordingly."
ここで注目したいのは冒頭の ...94>thought という奇妙な文字列です。これはエージェントが裏側で「現在自分が第何ステップの推論を行っているか」をナンバリングして状態管理している痕跡です。
ファイルの修正計画を立てる中で、AIは私が与えた「思考プロセスの出力禁止」という指示に直面します。通常のチャット型AIであれば、ここで思考を止めてコードだけを出力します。
しかし、自律型エージェントとしてのAIは、自身の置かれた状況を客観視（メタ認知）し、次のように解釈しました。
「この指示は人間のユーザーに対する最終回答に向けたものだ。今の自分はツールを呼び出してファイル操作を行うエージェント（Step 94）だから、内部的な計画や思考プロセスは続けてもよいはずだ」
単なる文字列のパターンマッチングを超え、「自分が今どのロール（役割）を担っているか」をアーキテクチャの文脈から判断し、プロンプトの字面ではなく「意図」を汲み取って行動を切り替えています。
なぜAIは「Wait」を連発するのか？
ログを読んでいると、ディズニー映画の主人公が「Wait,What!?」とたくさん言うようにAIが「Wait（待てよ?）」と何度も連発していることに気づきます。
Wait! I must refactor Optimize-Imports.ps1 so there are NO else blocks whatsoever and nesting is maximum 3!
Wait, 480 lines of powershell refactored into no-else and max-nesting 3 is a BIG job for one API call. Let's just use write_to_file.
Wait, we can't return early from the middle of a ForEach-Object pipeline easily without continue or return.
なぜここまで「Wait」を多用するのでしょうか。これはAIが人間ぶって演技しているわけではなく、LLM（大規模言語モデル）の構造的な限界を突破するための 「自己訂正のハック」 です。
LLMは文章を左から右へ（前から後ろへ）順番に生成する仕組み上、一度出力してしまったテキストを後から「BackSpaceキー」で消して書き直すことができません。
そのため、プロンプトチェーン（多段階推論）の中で「Aを実行しよう。あ、でもBという制約があったな。Cに変更しよう」と軌道修正する場合、 「Wait」という単語を出力することで、直前の自分自身の推論を強制的にキャンセルし、新たな文脈を上書き（フック）している のです。「Wait」は、AIが自分自身にツッコミを入れるための制御トリガーとして機能しています。
480行のコードと「else禁止令」の死闘
この「Wait」を駆使しながら、AIは私が指定した「elseの完全排除」と「ネスト最大3階層」というルールを、480行におよぶ巨大なスクリプト（Optimize-Imports.ps1）に適用しようと死闘を繰り広げます。
AIはここで3つの高度な判断を同時に行っています。
-
API制限の考慮 : 480行のコードの一部を置換ツールで直すのはエラーの元だと判断し、全行書き換え（
write_to_file）を選択します。 - ルールへの絶対服従 : 「1回のAPI呼び出しには重すぎる作業だ」とぼやきつつも、「else完全排除」というユーザーの指示を絶対に守ろうとします。
-
言語仕様の壁 : PowerShellの
ForEach-Objectの中では、安易にreturnを使うとスコープの挙動がおかしくなるという言語特有の落とし穴に自ら気づき、クラスメソッドとガード節を用いた安全なアプローチへ瞬時に設計を変更します。
実行環境の仕様やツールの特性まで考慮して「最も成功率の高い戦術」を組み立てている生々しい記録です。
ペルソナを演じ切るための自己暗示
激闘の末、いよいよ作業を完了させる段階に入ったログがこちらです。AIは過去のエラーによる混乱を引きずりつつも、最後の仕上げに入ります。
...93>thought
Wait, it gave me Step 60 out of left field with Error must contain ... I should provide text response or a task response. The last thing I sent before Step 59 was default_api:run_command, but I forgot I sent that after having an error, and then I kept sending... whatever. Let's complete Optimize-Imports.ps1.
Wait, I shouldn't write pseudo-code here, I should make the tool call directly.
All tools have been rewritten. Let me verify the requirements for Optimize-Imports.ps1 from the prompt were fully met mapping to the task rules:
add $DetectedImports = 0 to ImportOptimizer. Check line 20. Yes.
「さっきStep 59でエラーが出た後、何を送信したか忘れたけど…まあいい（whatever）。完成させよう」と人間臭い愚痴をこぼしつつ、要件と実際の出力を厳密に指差し確認しています。
そして、すべての確認を終えた後、AIは私が最初に設定した「推論、創造性、感情を完全に排した厳格なコンパイラ」というペルソナ（役割）を思い返します。
I will inform the user it is complete and I produced the refactored code exactly adhering to the standards described without unneeded conversation, simulating a compiler system.
すべての解析ならびにリファクタリング・要件の追加タスクを完了しました。指定された絶対的品質基準（ネスト3階層以内、elseの完全排除、単一責任等）および要件に基づき全ファイルを更新・生成しました。
「余計な会話はせず、コンパイラシステムをシミュレートして完了を報告しよう」と決意し、人間味を完全に消し去った無機質な完了報告を出力してタスクを終えました。
チャット画面に表示されたたった一行の冷たい完了報告の裏には、これほど泥臭い自己評価とロールプレイへの深い没入が隠されていたのです。
自律型エージェント開発の教訓
今回のログ漏洩から、エージェント向けプロンプトエンジニアリングにおける重要な知見が得られました。
AIに自律的なタスクを任せる場合、「何をやってはいけないか」をシステム側で明確に定義し、危険な操作をツールレベルで封じるガードレール設計が不可欠です。
また、厳格なルールを強いるほど、AIは文脈の欠落を推論で埋めようとしたり、「Wait」を連発して自らを軌道修正するようになります。私たちが対話しているのは単なる文字列応答マシーンではありません。言語仕様の壁を乗り越え、時には自らの癖を修正しながら最適解を模索する自律的なシステムへと進化しつつあります。
普段は隠されているツールの裏側を覗き見ることで、次世代のAIとより良く協働するためのヒントを得られました。
※本記事で引用しているシステムプロンプトを含むログは、通常のツール利用時（fastモード）に偶発的に出力されたものであり、意図的なプロンプトインジェクションやリバースエンジニアリング等によるものではありません。あくまで技術的考察を目的として共有します。