Gemini CLI 用 Conductor 拡張機能

Conductorは、コンテキスト駆動開発 (Context-Driven Development) を可能にするGemini CLI拡張機能です。これはGemini CLIを、ソフトウェアの機能開発やバグ修正において、仕様策定、計画、実装という厳格なプロトコルに従う、主体的なプロジェクトマネージャーへと変革します。

単にコードを書くだけでなく、Conductorはすべてのタスクにおいて「コンテキスト -> 仕様 & 計画 -> 実装」という一貫した高品質なライフサイクルを保証します。

Conductorの背景にある哲学はシンプルです。「コードを支配せよ」ということです。コンテキストをコードと並ぶ管理された成果物として扱うことで、リポジトリを「信頼できる唯一の情報源（Single Source of Truth）」に変え、エージェントとのあらゆる対話において、プロジェクトに対する深く永続的な認識を持たせることができます。

主な機能

構築前の計画: 新規および既存のコードベースに対して、エージェントを導くための仕様書と計画書を作成します。
コンテキストの維持: AIがスタイルガイド、技術スタックの選択、プロダクトの目標を確実に遵守するようにします。
安全な反復: コードが書かれる前に計画をレビューすることで、開発者が常に状況を把握できるようにします。
チームとしての作業: プロダクト、技術スタック、ワークフローの好みに応じたプロジェクトレベルのコンテキストを設定し、チームの共有基盤とします。
既存プロジェクトへの適用: 新規プロジェクト（グリーンフィールド）と既存プロジェクト（ブラウンフィールド）の両方に対応した、インテリジェントな初期化機能を提供します。
スマートなリバート: 単なるコミットハッシュだけでなく、作業の論理的な単位（トラック、フェーズ、タスク）を理解する、Git対応のリバートコマンドを提供します。

インストール

ターミナルで以下のコマンドを実行して、Conductor拡張機能をインストールしてください。

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

--auto-update はオプションです。指定すると、新しいバージョンがリリースされた際に自動的に更新されます。

使用方法

Conductorは、開発タスクのライフサイクル全体を管理するように設計されています。

graph TB subgraph PreDev ["準備 & 計画"] direction LR subgraph Setup ["1. プロジェクトのセットアップ
(初回のみ)"] direction TB S1["/conductor:setup"] --> S2["コンテキスト定義
Product, Tech Stack, Workflow"] S2 --> S3["成果物生成
product.md, tracks.md等"] end subgraph Track ["2. 新しいトラックの開始
(機能追加・バグ修正)"] direction TB T1["/conductor:newTrack"] --> T2["仕様と計画の策定"] T2 --> T3["成果物生成
spec.md, plan.md"] end S3 --> T1 end subgraph Implement ["3. トラックの実装"] direction TB I1["/conductor:implement"] --> I2["計画に基づくコーディング"] I2 --> I3["自動テスト & 検証"] I3 --> I4["ステータス更新"] I4 --> I5{"完了後の選択"} I5 -->|A. Archive| I6["アーカイブ
(推奨)"] I5 -->|B. Delete| I7["削除"] I5 -->|C. Skip| I8["維持"] %% Status check I2 -.-o U1["/conductor:status
(進捗確認)"] %% Revert flow I3 --"問題発生時"--> U2["/conductor:revert
(作業の巻き戻し)"] end T3 --> I1 style Setup fill:#e1f5fe,stroke:#01579b,stroke-width:2px style Track fill:#f3e5f5,stroke:#4a148c,stroke-width:2px style Implement fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px style PreDev fill:none,stroke:none style U2 fill:#ffebee,stroke:#c62828,stroke-width:2px,stroke-dasharray: 5 5 style U1 fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,stroke-dasharray: 5 5

トークン消費に関する注意: Conductorのコンテキスト駆動アプローチでは、プロジェクトのコンテキスト、仕様、計画を読み込んで分析します。そのため、特に大規模なプロジェクトや、広範な計画・実装フェーズにおいては、トークン消費量が増加する可能性があります。現在のセッションでのトークン消費量は /stats model を実行することで確認できます。

1. プロジェクトのセットアップ（初回のみ）

/conductor:setup を実行すると、Conductorはプロジェクトコンテキストの中核となるコンポーネントの定義を支援します。このコンテキストは、あなたやチームメンバーが新しいコンポーネントや機能を構築する際に使用されます。

Product (プロダクト): プロジェクトのコンテキスト（例：ユーザー、プロダクトの目標、高レベルな機能）を定義します。
Product guidelines (プロダクトガイドライン): 基準（例：文章のスタイル、ブランドメッセージ、ビジュアルアイデンティティ）を定義します。
Tech stack (技術スタック): 技術的な設定（例：言語、データベース、フレームワーク）を構成します。
Workflow (ワークフロー): チームの好み（例：TDD、コミット戦略）を設定します。カスタマイズ可能なテンプレートとして workflow.md を使用します。

生成される成果物:

conductor/product.md
conductor/product-guidelines.md
conductor/tech-stack.md
conductor/workflow.md
conductor/code_styleguides/
conductor/tracks.md

/conductor:setup

2. 新しいトラックの開始（機能追加またはバグ修正）

新しい機能開発やバグ修正に取り掛かる準備ができたら、/conductor:newTrack を実行します。これにより、作業の大きな単位である トラック (track) が初期化されます。Conductorは以下の2つの重要な成果物の生成を支援します。

Specs (仕様書): その仕事に関する詳細な要件。何を、なぜ作るのか？
Plan (計画書): フェーズ、タスク、サブタスクを含む、実行可能なToDoリスト。

生成される成果物:

conductor/tracks/<track_id>/spec.md
conductor/tracks/<track_id>/plan.md
conductor/tracks/<track_id>/metadata.json

/conductor:newTrack
# または説明付きで実行
/conductor:newTrack "設定ページにダークモードの切り替えを追加する"

3. トラックの実装

計画を承認したら、/conductor:implement を実行します。コーディングエージェントは plan.md ファイルに従って作業を進め、完了したタスクにチェックを入れていきます。

更新される成果物:

conductor/tracks.md (ステータス更新)
conductor/tracks/<track_id>/plan.md (ステータス更新)
プロジェクトコンテキストファイル（完了時に同期）

/conductor:implement

Conductorは以下の手順を実行します：

次の保留中のタスクを選択します。
定義されたワークフローに従います（例：TDDなら、テスト作成 -> 失敗 -> 実装 -> 合格）。
進行に合わせて計画内のステータスを更新します。
進捗の検証: 各フェーズの終了時に手動検証ステップを案内し、すべてが期待通りに動作することを確認します。

実装中は以下も可能です：

ステータスの確認: プロジェクトの進捗状況の概要を取得します。
/conductor:status
作業のリバート: 必要に応じて機能や特定のタスクを元に戻します。
/conductor:revert

コマンドリファレンス

コマンド	説明	成果物
`/conductor:setup`	プロジェクトの骨組みを作り、Conductor環境をセットアップします。プロジェクトごとに1回実行します。	`conductor/product.md` `conductor/product-guidelines.md` `conductor/tech-stack.md` `conductor/workflow.md` `conductor/tracks.md`
`/conductor:newTrack`	新しい機能またはバグのトラックを開始します。`spec.md` と `plan.md` を生成します。	`conductor/tracks/<id>/spec.md` `conductor/tracks/<id>/plan.md` `conductor/tracks.md`
`/conductor:implement`	現在のトラックの計画で定義されたタスクを実行します。	`conductor/tracks.md` `conductor/tracks/<id>/plan.md`
`/conductor:status`	tracksファイルとアクティブなトラックの現在の進捗を表示します。	`conductor/tracks.md` を読み取ります
`/conductor:revert`	Git履歴を分析して、トラック、フェーズ、またはタスクをリバート（巻き戻し）します。	Git履歴をリバートします

（おまけ）Conductorで実装が完了した後の選択肢

実装完了時のサジェスションは、完了した作業（トラック）の「ドキュメントと履歴」をどのように整理するかを確認するものです。Gemini ConductorはコンテキストをMarkdownファイルとしてリポジトリ内で管理するため、この選択は今後のAIとの対話の効率に影響します。

それぞれの選択肢を選んだ場合の挙動は以下の通りです。

A. Archive（推奨）

挙動: その機能開発で使用した spec.md（仕様書）や plan.md（計画書）を含むトラックフォルダが、 conductor/archive/ ディレクトリへ移動されます。また、プロジェクト全体の履歴を管理する tracks.md からも、アクティブな作業リストとしては取り除かれます。
プロジェクトへの影響: 過去の設計判断や実装の経緯がリポジトリ内に「ログ」として残ります。これにより、数ヶ月後にAIが「以前の共有機能の基盤はどう設計した？」と問われた際、アーカイブを読み取って正確な回答ができるようになります。
適したケース: 通常の機能開発が完了した際。ワークスペースを清潔に保ちつつ、AIの「長期記憶」に情報を残したい場合に最適です。

B. Delete

挙動: トラックフォルダとその中身（計画・仕様・実行履歴）が物理的に削除され、 tracks.md からも完全に消去されます。
プロジェクトへの影響: 実装された「コード」は残りますが、そのコードが「なぜ、どのようなステップで書かれたか」というコンテキストが消失します。AIが過去の経緯を遡ることができなくなるため、CDD（コンテキスト駆動型開発）のメリットが一部失われます。
適したケース: 間違えて作成したトラックや、記録に残す必要のない一時的な試行錯誤、または完全に不要になったタスクの場合。

C. Skip

挙動: 何も行わず、トラックフォルダは元の場所に残り、 tracks.md にも「完了」状態でリストされ続けます。
プロジェクトへの影響: ファイルがそのまま残るため、AIが常にそのトラックを「直近のコンテキスト」として参照しやすい状態が維持されます。ただし、完了したトラックが増えてくると conductor/ フォルダ内が煩雑になり、AIが読み込むファイル量が増えてトークン消費が増大する可能性があります。
適したケース: 完了したばかりだが、すぐに関連する別の作業（次のトラック）を開始する予定があり、前回の計画書などをAIに頻繁に参照させたい場合。

結論としてのアドバイス：

基本的には A. Archive を選択することをお勧めします。これにより、リポジトリの整理整頓と、AIのための「永続的なプロジェクト記憶」の蓄積を両立させることができます。