Google「Conductor」登場：Gemini CLIで始める”コンテキスト駆動開発”が、AI活用を現場仕様にする

Google Conductor の狙いと、仕様・計画をリポジトリ内Markdownで共有するコンテキスト駆動開発の型を編集部が整理して解説します。

AIにコードを書かせることは、もはや特別なことではない。差が出るのは「どのモデルを使うか」よりも、AIに渡す前提（コンテキスト）をどう整備し、チームで共有し、更新し続けるかにある。

GoogleがGemini CLI向けにプレビュー公開した拡張「Conductor」は、この”前提管理”を開発フローに組み込むツールだ。ポイントは、チャットの流れに頼らず、仕様や計画をリポジトリ内のMarkdownとして残し、Gitで管理できる成果物にすること。いわば「コンテキスト駆動開発（Context-driven development）」を現場で回すための型である。

最終更新日: 2026年5月21日

なぜ今「コンテキスト」なのか：AI開発が陥る典型パターン

AI開発がやり直しになる原因は「AIが賢くない」からではなく、前提が揃っていないことにある。よくある落とし穴は次の3つだ。

前提の不足：誰のための機能か、守るべき制約は何か

品質基準の曖昧さ：テスト方針、レビュー観点、セキュリティ要件

暗黙知の欠落：既存設計の意図、運用ルール、過去の意思決定

AIが参照すべき”正しい前提”がなければ、出力は「それっぽいけど違う」になりやすい。Conductorは、この前提をチャット窓ではなく、チームで管理できる場所（リポジトリ）へ移す発想に基づいている。

Conductorとは：Gemini CLI向け”コンテキスト駆動開発”拡張

ConductorはGemini CLIのオープンソース拡張（Apache License 2.0）で、AIを使った開発を「いきなり実装」から「計画してから実装」へ引き戻す。Googleは次のように説明している。

Rather than depending on impermanent chat logs, Conductor helps you create formal specs and plans that live alongside your code in persistent Markdown files. （揮発しやすいチャットログに頼るのではなく、Conductorは永続的なMarkdownファイルとしてコードと共存する正式な仕様と計画の作成を支援する）

意図は明快だ。チャットログは揮発しやすい。一方、Markdownでリポジトリに残せば、差分が追える、レビューできる、引き継げる。ビジネス観点で見ると、Conductorの価値は次の3点に集約される。

再現性：同じ前提で、同じ品質を狙える

説明可能性：仕様と計画が残り、レビューや引き継ぎがしやすい

ガバナンス：人間が承認してからAIに実装させる流れを作れる

既存プロジェクト（Brownfield）で効きやすい理由

新規開発よりも難しいのが、既存コード（Brownfield）だ。AIがここで迷いやすいのは、コードの外側にある情報——運用上のルール、過去の例外対応の経緯、「触ると危ない」領域の暗黙知——が読み取れないからである。

Conductorは、既存プロジェクトに導入したときに対話的に基礎ドキュメントを整備し、作業を進めながら共通コンテキストを更新して育てていく方向性を示している。単なる”プロンプト集”ではなく、プロジェクト運用の型として機能する点が特徴だ。

Conductorの進め方（3ステップ）：セットアップ → 仕様と計画 → 実装

Conductorは「作業をTrackとして回す」ワークフローである。大枠は3ステップで構成される。

1）/conductor:setup：プロジェクトの前提を固める

プロダクトの目的、ユーザー、技術スタック、開発ワークフローなど、チームの当たり前を定義する。ここがあると、AIが毎回”前提確認”から始めなくて済む。

生成されるファイル：conductor/product.md、conductor/tech-stack.md、conductor/workflow.mdなど

2）/conductor:newTrack：仕様（Specs）と計画（Plan）を作る

いきなりコードを書かせず、まずは成果物としてSpecs（仕様）とPlan（計画）を用意する。Specsは「何を、なぜ作るのか」、Planは「フェーズ／タスク／サブタスクへの分解」を定義する。ここで人間がレビューできるのが重要だ。

生成されるファイル：conductor/tracks//spec.md、conductor/tracks//plan.md

3）/conductor:implement：計画に沿って実装し、進捗を残す

承認した計画に沿ってAIが実装を進め、完了タスクをチェックしていく。状態がファイルに残るため、途中で止めて再開する、別の端末・別メンバーが続きから作業する、計画の途中修正を行う、といったことがやりやすくなる。

補助コマンドとして、進捗確認の/conductor:statusや、作業の巻き戻しを行う/conductor:revertも用意されている。

チームにとっての実務メリット：AI活用を”個人芸”から”仕組み”へ

Conductorが効くのは、AI活用を個人のプロンプト力に依存させず、チーム運用に落とせるからだ。

オンボーディングの加速：新人も「前提」に乗れる

品質の安定：テスト方針や制約が共有され、ブレにくい

レビューの効率化：仕様・計画があるので論点が整理される

説明責任の確保：なぜその実装になったかを追える

AI導入の投資対効果は、結局「再現性」と「管理可能性」で決まる。Conductorは、そこにまっすぐ効くアプローチだ。

使い始め方（公式）

GoogleはConductorをGemini CLI拡張としてインストールする手順を案内している。–auto-updateオプションを付けると、新バージョンのリリース時に自動更新される。

gemini extensions install https://github.com/gemini-cli-extensions/conductor –auto-update

まとめ：コンテキストを資産化できるかが、AI開発の分かれ道

Conductorが示すメッセージはシンプルだ。AI開発の成否は、モデル選びだけではなく、コンテキストを”管理された資産”として持てるかにかかっている。

チャット依存を減らし、リポジトリを単一の正（Single Source of Truth）にする 仕様・計画を先に作り、人間が承認してから実装へ進む 既存プロダクトでも、コンテキストを育てていく運用にする

「コンテキストが重要」はもはやスローガンではなく、これからの開発プロセスそのものになっていきそうだ。

出典

• Google Developers Blog「Conductor: Introducing context-driven development for Gemini CLI」（2025年12月17日公開） https://developers.googleblog.com/conductor-introducing-context-driven-development-for-gemini-cli/
• GitHub – gemini-cli-extensions/conductor（Apache License 2.0） https://github.com/gemini-cli-extensions/conductor

編集部のひとこと

AIは優秀でも、前提が共有されていないと「それっぽいけど違う」を量産しがち。Conductorは、仕様と計画をリポジトリに残すことで、AI活用を”個人のプロンプト力”から”チームで再現できる仕組み”へ引き上げるツールになりそうだ。

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。

編集部の見方

総評: 評価軸を3つ挙げる。 1. チャット依存からの脱却: コンテキストをリポジトリに置く設計は、Cursor の .cursorrules や Claude Code の CLAUDE.md などと同じ系譜にあり、業界の流れに沿う。差別化要素は Track ごとの spec/plan の二層構造。 2. Brownfield 適合性: 新規開発より既存コードの方が AI 活用の難所だ。対話で基礎ドキュメントを育てる思想は、レガシー保守の現場で意味が大きい。 3. チーム展開: Git 管理できる Markdown は、レビュー・オンボーディング・引き継ぎの全フェーズで効く。AI 活用を個人のプロンプト力から運用の仕組みに移す設計だ。 向くのは、複数メンバーで AI 支援開発を進めたいチームと、既存コードベースに AI を後付けしたい組織。向かないのは、ひとりで小規模な実験を回したい用途で、ドキュメント整備のオーバーヘッドが効きにくい。