Gemini CLIで「ノーコード」複数エージェントシステム!? AIエージェント活用の新潮流に迫る

この記事の途中に、以下の記事の引用を含んでいます。
Turning Gemini CLI into a Multi-Agent System with Just Prompts

独自のAIチームを“質問だけ”で構築？この記事が示す新たな可能性

今回ご紹介するのは、Gemini CLIのカスタムコマンド機能だけを用いて、まるでチームのようにAI「エージェント」を動かす——それもプログラミング不要で！——という驚きのチャレンジを綴った記事です。

Gemini CLIの「エージェント」とは何か？
記事の筆者は「プロジェクトごとに特化したツールを作り、業務フローを効率化したい」という目的でGemini CLIのカスタムコマンドを探究しました。
そして、「複数の役割をもつAIペルソナ同士をコラボさせる」というアイデアに到達します。

この“複数エージェントによる協調作業”は、ChatGPTやClaudeといった大規模言語モデルの文脈でも盛んに議論されています。
しかし通常はコードを書いたり、複雑な設定が必要となります。
ところが、本記事では「ゼロコーディング」でこれを実現したというのです。

“The surprising part? I didn’t have to write a single line of code.
The entire system described below is built by composing native Gemini CLI features— it’s an exercise in prompt engineering/instruction tuning.”

（驚くべきことに、一行もコードを書かずに、ネイティブなGemini CLI機能の組み合わせだけでこのシステムは構築できた。これはプロンプトエンジニアリング・命令の工夫によるものだ。）

と筆者は強調しています。

“ファイルシステムがステート”!? 堅牢で透明な設計思想

多くのAIワークフローでは、状態管理（どのタスクが進行中か・どのエージェントが何をしたか、等）をバックグラウンドプロセスや専用DBなどで複雑に管理しがちです。

本記事では、Anthropicが発表した「ファイルシステムをステートとして使う」手法から着想を得ています。
タスクのキュー・計画・ログ等、全てをGeminiプロジェクトの .gemini/ ディレクトリ配下の構造化されたフォルダで管理し、状態遷移もファイル操作のみで完結させるシンプルな方式です。

“I decided to adopt the filesystem-as-state pattern from the Anthropic post. Instead of managing complex background processes, the entire state of the system—its task queue, plans, and logs—would live in a structured directory. This approach makes the system transparent and easily debuggable.”

（Anthropicの投稿から、“ファイルシステム＝状態”というパターンを採用した。複雑なバックグラウンドプロセスを使う代わりに、システムのタスクキュー・計画・ログといった全状態を構造化ディレクトリに保存する。この手法はシステムを透明かつデバッグしやすくする。）

この構成は、多人数協調や非同期処理が求められるシステム設計において非常に有効です。
状態遷移の可視性・管理性が高いだけでなく、一度に複数のエージェントインスタンスを安全に走らせる際にも予期しない競合が生じにくくなります。

自己主張できるAIは誕生するか？ペルソナ・エージェント論争

記事最大のハイライトは、AIエージェント（たとえば“Coder-Agent”や“Reviewer-Agent”）という役割を与えたAIたちを、命令ベースで組織的に動かすという点です。

各エージェントは .toml ファイル内のプロンプトがその「設計書」となり、
/agents:run コマンドでタスクJSONファイル（“やってほしい作業”）を渡されることで“命を吹き込まれる”——そんな仕組みです。

“When the /agents:run command is executed, its prompt instructs the core AI to construct and run a shell command that launches a new, independent instance of gemini-cli … There’s no complex process manager. The entire system is coordinated by the task files on disk, making each agent a stateless worker that gets its instructions, performs its job, and exits.”

（/agents:runコマンドが実行されると、そのプロンプトはコアAIに命じ、シェルコマンドを作り独立したgemini-cliインスタンスを起動させる… 複雑なプロセスマネージャは不要。全てはディスク上のタスクファイルで調整され、各エージェントはステートレスなワーカーとして指示を受けて実行、終了する。）

興味深いのは、AI自身が“自分の役割を明確に意識できる”かどうか——ここにも工夫があります。
当初はタスクの説明を渡すだけでしたが、AIエージェントが自分のアイデンティティを混同し「再帰的な呼出しループ」に陥った、というバグが語られます。

“The fix was to change how the orchestrator invokes the agent. … to the much more explicit: gemini -e coder-agent -p “You are the coder-agent. Your Task ID is . Your task is to: Do stuff…” . This solved the identity crisis, ensuring the agent understood its role and executed its persona correctly.”

（オーケストレータがエージェントを呼び出す方法を明示的に変更した…「あなたはcoder-agentです。あなたのTask IDはです。あなたの仕事は…」と伝えることで、アイデンティティクライシスが解消し、エージェントは自分の役割を正しく理解し、役割通りに振る舞うようになった。）

言い換えれば、プロンプトの設計次第でAIの“自己同一性”や行動の一貫性までもコントロールできる、という新しい知見です。
まるで「AIの人格形成」に近い体験にも見えます。

なぜ“手動シンプル主義”がAIチーム運用の鍵なのか？

一見、より賢いシステムを目指せば「自動で最適なエージェントを選ぶ」アプローチに心が惹かれがちです。
記事でも“インテリジェントなエージェント選定”の検討が語られていますが、あくまで「明確なユーザー指定方式」を選びました。

“The clarity of a user explicitly assigning a task to a specific agent was more valuable than a “magical” but opaque selection process.”

（ユーザーが明示的にタスクを特定エージェントに割り当てる明確さの方が、“魔法のように”見えても不透明な選択プロセスより価値がある。）

特にエンタープライズの業務用途では、
「なぜそのエージェントを選んだのか」「どんな作業をやらせたのか」をトレースできない”ブラックボックス”化は大きなリスクです。
人間との協調や監査を前提とする運用では、プロンプトやファイル上でタスク割当が見える透明性・管理性が信頼性につながると考えられます。

加えて、Geminiの–yolo等の“自動承認”オプションには慎重な運用が強く推奨されています。
「安全なプロンプト設計」の重要性は身をもって語られており、現状ではまだ完全自動化には課題が残るようです。

“AIエージェント開発＝プロジェクトマネジメント”時代は来るか？

記事は最後に、“Gemini CLIのこのパターンは、ビジネスアプリケーションの入り口として非常に有用”とし、
具体的な活用例も提案しています。

専門家エージェントの創出例

• セキュア コードレビュアー: 独自の静的解析スキャナーツールを呼び出し、出力内容に応じて動作・判定を自動化。ファイル書込権限は無くし安全化する。
• クラウドプロビジョニング エージェント: “Cloud Architect”の拡張で限定gcloudコマンドだけ使用。
  "新しいGCSバケットを作成"…など、許認可を分けて安全運用できる。

“The core idea is to encapsulate expertise and capability into a self-contained extension, and then use this prompt-driven orchestration system to direct it.”

（本質は、専門知識と能力を1つの拡張（エージェント）に封じ込め、プロンプト駆動のオーケストレーションシステムで指揮を執ることにある。）

このモデルの示唆する未来は――
「開発者自身がすべての業務ロジックの細部までコーディングする」のではなく、
「必要な役割・専門職種のAIエージェントを指示・編成する“マネージャー”になる」こと。
人間が“命令系統”や各エージェントの“分業範囲”を定め、
繰り返し業務や専門的審査をAIエージェントに委譲する世界です。

特に企業の大規模プロジェクトや、社内ツールの高度化ニーズにおいて、
この形態は今後きわめて現実味を帯びてきます。

まとめ：ノーコードAIチーム運用の“哲学”を今こそ体験せよ

本記事は、Gemini CLI拡張×プロンプト工夫だけで“複数人格のAIエージェントチーム”を現場に即投入できる…という、未来感溢れる実践知でした。

要点は次の3つに集約できます：

1. ファイルシステムで全状態を“見える化”
   バックグラウンドプロセスやDBを使わず、“すべての動きがディスク上でトレースできる”仕組みは、トラブル時の復元・再現も容易。

2. プロンプト設計こそがエージェント文化の肝
   即席AIエージェントを命令一つで動かすには、「あなたはコーダーだ」「あなたの仕事はレビューだ」と明示的に役割と一意のタスクを伝えることが、行動安定性と透明性の両立カギ。

3. シンプル主義が最大の信頼性
   欠かせないのは「なぜそのAIに何をさせたか」が明示されていること。透明性は、ビジネスフロー運用での可監査性・安全性に直結します。

AI言語モデルは一つの「汎用万能ツール」として使うだけでなく、特定の役割専門家に“分化させて”仕組み化する流れは今後ますます主流化します。

「ゼロコーディングで始めるAIエージェントチーム運用」に興味があれば、
記事中で紹介されていたGitHubリポジトリを覗き、
あなたなりのAIエージェントの可能性を体感してみてください。

最終的には「AIを扱う＝コーディング」ではなく、「AIを“編成・仕切る”マネジメント感覚」へと役割観そのものが進化する。
そんな、AI現場最前線の哲学に一歩足を踏み出すきっかけになるでしょう。

categories:[technology]