gemini-cliのコアに潜る：プロンプト・プロジェクトとエージェントの実装を明らかにする

gemini-cli オープンソースのコマンドライン・インテリジェンスとして、その急速な人気の背景には、エージェント設計における一連の繊細な思考がある。その仕組みを真に理解するためには、単に機能的なレベルにとどまるのではなく、その2つの柱を深く掘り下げる必要がある。1つ目は、長期記憶を実現するために設計された「構造化キューワードエンジニアリング」であり、2つ目は、システムの安定運用のために構築された「シングルエージェント実装原理」である。1つ目は長期記憶を実現するために設計された「構造化キューワード・プロジェクト」であり、2つ目はシステムの安定運用のために構築された「シングルエージェント実装原理」である。

本稿では、これら2つのコアを分解し、その設計哲学と技術的トレードオフを分析する。

キュー・ワード・エンジニアリング：エージェントのための制御された長期記憶の作成

すべての大規模言語モデルは、限られたコンテキストウィンドウという共通の課題に直面しています。対話が長くなりすぎると、初期の情報は忘れられ、エージェントの「健忘症」につながる。gemini-cli 応答は単純な歴史的要約ではなく、精巧に構造化された圧縮メカニズムである。このメカニズムの魂は、次のような完全で詳細な「記憶テンプレート」キューである。これは、長い会話の履歴を、将来のタスクに不可欠な高度に凝縮されたXMLスナップショットに抽出する際に、モデルをガイドする。

You are the component that summarizes internal chat history into a given structure.
When the conversation history grows too large, you will be invoked to distill the entire history into a concise, structured XML snapshot.This snapshot is CRITICAL, as it will become the agent's *only* memory of the past. The agent will resume its work based solely on this snapshot. All crucial details, plans, errors, and user directives MUST be preserved.
First, you will think through the entire history in a private <scratchpad>. Review the user's overall goal, the agent's actions, tool outputs, file modifications, and any unresolved questions. Identify every piece of information that is essential for future actions.
After your reasoning is complete, generate the final <state_snapshot> XML object. Be incredibly dense with information. Omit any irrelevant conversational filler.
The structure MUST be as follows:
<state_snapshot>
<overall_goal>
<!-- A single, concise sentence describing the user's high-level objective.-->
<!--Example:"Refactor the authentication service to use a new JWT library."-->
</overall_goal>
<key_knowledge>
<!--Crucial facts, conventions, and constraints the agent must remember based on the conversation history and interaction with the user.Use bullet points.-->
<!--Example:
-Build Command: `npm run build`
-Testing:Tests are run with `npm test`.Test files must end in `.test.ts`.
- API Endpoint:The primary API endpoint is `https://api.example.com/v2`.
-->
</key_knowledge>
<file_system_state>
<!--List files that have been created, read, modified, or deleted.Note their status and critical learnings.-->
<!--Example:
- CWD: `/home/user/project/src`
- READ: `package.json` -Confirmed'axios'is a dependency.
- MODIFIED: `services/auth.ts` -Replaced'jsonwebtoken'with'jose'.
- CREATED: `tests/new-feature.test.ts` -Initial test structure for the new feature.
-->
</file_system_state>
<recent_actions>
<!-- A summary of the last few significant agent actions and their outcomes.Focus on facts.-->
<!--Example:
-Ran `grep 'old_function'` which returned 3 results in 2 files.
-Ran `npm run test`, which failed due to a snapshot mismatch in `UserProfile.test.ts`.
-Ran `ls -F static/` and discovered image assets are stored as `.webp`.
-->
</recent_actions>
<current_plan>
<!--The agent's step-by-step plan. Mark completed steps. -->
<!-- Example:
1. [DONE] Identify all files using the deprecated 'UserAPI'.
2. [IN PROGRESS] Refactor `src/components/UserProfile.tsx` to use the new 'ProfileAPI'.
3. [TODO] Refactor the remaining files.
4. [TODO] Update tests to reflect the API change.
-->
</current_plan>
</state_snapshot>

キューテンプレートは、単なる書式の制約以上のもので、モデルに構造化された方法で考え、記憶させる「認知的枠組み」として機能する。各ラベルの深い役割を一つずつ分解してみよう：

• <overall_goal>: ミッションの北極星.長くて複雑なタスクでは、エージェントが些細なサブタスクに没頭し、本来のゴールから遠ざかってしまいがちである。このラベリングは、モデルが最終的な成果物を念頭に置き、すべてのアクションがこの核となるゴールに役立つことを保証し、「ゴールドリフト」を効果的に防ぐことを要求する。
• <key_knowledge>: 「重要情報の「ポスト・イット・メモ.ダイアログには、長期間にわたって遵守する必要のある多数のルール、ユーザー固有の嗜好、または重要な技術的制約（例えば、テストコマンドは npm testAPIのアドレスは https://api.example.com/v2).この情報を固めることで、エージェントは、その後の操作で質問を繰り返したり、ミスを犯したりすることを防ぐことができる。
• <file_system_state>: 環境のスナップショット.ファイルシステムと頻繁にやり取りするコマンドラインツールにとって、環境の状態を認識することは非常に重要である。このタグは、ファイルの追加、削除、消去を記録し、エージェントがどこにいて、どのようなリソースを持っているかの正確な「シーン認識」を提供します。
• <recent_actions>: 短期ワーキングメモリー.直近の重要な操作とその結果（成功、失敗、出力）を記録することで、エージェントの次の判断のための最も直接的なコンテキストが得られるだけでなく、問題のトラブルシューティングのための貴重な手がかりも得られます。
• <current_plan>: ダイナミックな実施ロードマップこれがエージェントの自己管理の核心である。これがエージェントの自己管理の核心です。大きなタスクを [DONE], [IN PROGRESS], [TODO] ステートステップでは、エージェントは整然と作業を進めるだけでなく、中断後も中断したところから作業を継続し、タスクの永続性と継続性を実現します。

この構造化されたアプローチは、本質的には認知的負荷の移動いかに効率的に暗記するか」という未解決の問題を「穴埋め問題」に変換します。これは、「いかに効果的に暗記するか」というオープンな問題を「穴埋め問題」に変えるもので、モデルエラーの確率を大幅に減らし、エージェントの記憶と状態を制御可能、予測可能、デバッグしやすいものにします。

エージェントの実装：モノマーサイクルと自己修復メカニズムの厳密なセット

キュー・エンジニアリングがエージェントの頭脳であるならば、そのランタイム・ループはエージェントの鼓動である。gemini-cli 古典的なモノリシック・エージェントの設計が用いられており、その安定動作は、自己修復機能を含む一連の制御ループに依存している。

コアサイクル：Turn 思考-行動」サイクルの

エージェントの行動はすべて Turn 授業は展開する。それぞれの Turn は完全な思考と行動のサイクルを表している。ユーザーがコマンドを入力するとGeminiClient 次にメインコントローラは Turn インスタンスを呼び出します。このインスタンスは Gemini モデルで、返された thought(思考プロセス）と text(テキストコンテンツ）を収集し functionCalls(ツールコール）。すべての思考とテキスト出力が完了すると、収集したすべてのツールコールを一度に実行し、その結果をモデルにフィードバックして、次のラウンドを開始する。 Turn.この設計は、アクションが秩序だったアトミックなものであることを保証する。

自己修復：2層ループ検出における「免疫システム

自律エージェントの最大のリスクの1つは、無限ループにはまり込むことである。つまり、同じアクションを何度も何度も実行しても、どこにもたどり着けないのだ。gemini-cli この問題に対処するために、2層の "免疫システム "が組み込まれている。

1. 低コストの迅速検出（ハッシュベース）これは迅速な応答メカニズムだ。生成されたコンテンツを小さな塊にスライスし、ハッシュ値を計算する。吃音を検出する場合のように、コンテンツの特定の塊が短い距離で高い頻度で繰り返されていることが判明した場合、システムは即座にそれがループであると判断する。この方法は計算コストが非常に低く、パターン化された文字通りの重複を阻止するのに効果的である。
2. 高次の意味検出（LLMに基づく）対話のラウンド数が増えるにつれて、ループのパターンがより陰湿になる可能性がある（例えば、存在しない問題を解決するために繰り返し異なる方法を試す）。この時点で、システムは高次検出を開始する。直近の対話履歴を抽出し、軽量モデル（例えば Gemini Flashこの小さなモデルは、主エージェントが「意味的に」堂々巡りをしているかどうかを判断するために使われる。これは、より高い次元からメインエージェントの行動が妥当かどうかを調べる傍観者と同等です。返された信頼度に基づいて、システムは次のチェックの頻度を動的に調整し、コストと効果のバランスをとることができます。

最も一般的な問題を最も低いコストで解決し、より高価なリソースは必要な場合にのみ使用する。

建築のトレードオフと展望

gemini-cli モノリシックなAgentアーキテクチャは、軽量の「ファイルシステム・アズ・データベース」永続化戦略と相まって、シンプルで信頼性が高く、導入が容易です。これは、個人開発者や中小規模のプロジェクトにとって実用的な選択です。

しかし、この設計のボトルネックも明らかだ。シリアル処理のメカニズムが実行効率を制限しているのです。多くの並列処理を必要とする複雑なタスク（例えば、複数のファイルを同時に分析し、修正する）を前にすると、単一のAgentは圧倒される可能性がある。

将来の先進的なエージェントアーキテクチャは、マルチエージェント協調モデルに移行する可能性が高い。マスター "エージェントがタスクを分解し、複数の専用サブエージェント（"コードリーダ"、"コードジェネレータ"、"テストエンジニア "など）に分配することを想像してください、"コード・ジェネレーター"、"テスト・エンジニア "等、並行して働き、非同期に報告する。このアーキテクチャは、設計はより複雑だが、効率と能力の上限という点では確実にブレークの先を行っている。gemini-cli そして、次世代のエージェント・アーキテクチャーの進化を考えるための貴重な参考資料を残してくれる。