Gemini CLI の Conductor 入門ガイド

Gemini CLI を起動し、実装したい機能について指示するだけで、エージェントは即座にコードの記述を開始します。質問も確認もなく、計画も立てません。10 分後には 4 つのファイルにまたがる 100 行以上のコードが完成しますが、それは実際のアーキテクチャとは合致していません。なぜなら、エージェントはあなたのアーキテクチャを知らないからです。ありそうな推測に基づいて生成しただけで、当たったのは一部だけです。

今やあなたは AI が生成したコードの整理に追われながら、「自分で書いたほうが速かったのではないか」とため息をついているはずです。

これは Gemini 自体の問題ではありません。文脈（コンテキスト）の問題です。エージェントはあなたが何を作っているのか、どのライブラリを選んだのか、コーディング規約はどうなっているのか、そしてその機能が実際に何をすべきなのかを知らないのです。すべてのセッションがゼロから始まります。

Conductor は 2025 年 12 月 17 日にプレビュー版としてリリースされた Gemini CLI の拡張機能で、この課題を解決するために作られました。ここで導入されるのが「Context-Driven Development（CDD：文脈駆動型開発）」というワークフローです。これは、プロジェクトのコンテキスト、仕様、実装計画を、一時的なチャットウィンドウではなく、リポジトリ内の Markdown ファイルに記述する構造化されたアプローチです。

エージェントがあなたのプロジェクトに触れるたびに、これらのファイルを読み込みます。スタイルガイド、技術スタックの決定、プロダクトの目標など、すべてがコードと共に永続化され、引き継がれていきます。

Conductor の GitHub リポジトリは公開以来、スター数 3,600 以上、フォーク数 284 を突破しました。また、2026 年 4 月には、ゼロから Conductor を使ったプロジェクト構築を解説する Google Codelab が公開されています。

この記事では、Conductor の導入から最初の運用トラックの実行まで、必要なステップをすべて解説します。

Conductor は実際になにをするのか

コマンドの詳細に入る前に、Conductor がどのようなモデルに基づいているか理解しておくと、AI を活用した開発の考え方が変わります。

従来の AI によるコーディングワークフローはステートレス（状態を保持しない）です。セッションを開いて要望を伝え、エージェントが作業し、セッションを終了します。次に同じセッションを開いても、エージェントはあなたが何を作ったのか、なぜ作ったのか、そして次は何をするべきかを記憶していません。ある Google Cloud の開発者が表現したように、このモデルは「一時的で、忘れっぽく、かつ無謀なカウボーイ」のようなものです。

Conductor はこれを解決し、コンテキストを管理可能なアーティファクトとして扱います。毎回プロジェクトの状況を説明する必要はなく、Markdown ファイルのセットを維持することで、その役割を永続的に果たさせます。エージェントは実行するたびにこれらのファイルを読み込みます。コーディング基準は常に読み込まれ、製品目標は常に視野に入れられ、機能計画も常に表示されます。

Google の公式発表記事では、ベンジャミン・フランクリンの「計画を怠ることは失敗するための計画である」という言葉を引き合いに出し、Conductor の哲学を説明しています。この枠組みは的確です。

Conductor のワークフローは、「まず文脈を整え、次に機能の仕様を決め、実装方法を計画し、最後にコードを書く」という順序で進みます。これは毎回同じ手順です。

アーキテクチャ上、Conductor は以下の 3 つのレイヤーが連携して動作します。

• コマンド層：Gemini CLI 内で使用する 6 つのスラッシュコマンドを通じてユーザーと対話する部分
• アーティファクト層：プロジェクトの状態を保持する Markdown ファイルや JSON ファイルを含む、リポジトリ内の conductor/ ディレクトリ
• バージョン管理層：Git。Conductor はこれを利用してタスクごとのコミットを作成し、ロールバック機能をサポートします

このツールは、ゼロから始める新規プロジェクト（グリーンフィールド）だけでなく、既存のコードベースを持つプロジェクト（ブラウンフィールド）でも問題なく動作します。多くのチュートリアルがクリーンな状態からのプロジェクトしか紹介していない中で、既存リポジトリへの対応は特筆すべき点です。/conductor:setup を実行すると、Conductor はコードベースを解析し、.gitignore や .geminiignore の設定を尊重しながら、技術スタックやアーキテクチャを自動的に推測します。そのため、Conductor が自身で把握できる情報を手動で入力する必要はありません。

# 前提条件とインストール

Conductor をインストールする前に、以下の 3 つの準備が必要です。

まず、Gemini CLI がインストールされ、正常に動作していることを確認してください。npm を使ってグローバルにインストールします：

# Install Gemini CLI globally
npm install -g @google/gemini-cli

# Verify installation
gemini --version

もし権限エラーが発生した場合は、root として実行するのではなく、nvm などの Node バージョンマネージャーを使用してください。インストール後はターミナルを再起動し、gemini コマンドが PATH に追加されていることを確認しましょう。

Gemini CLI を使用するには、Google API キーまたは Vertex AI の設定が必要です。gemini コマンドを初めて実行すると認証を求められるため、Vertex AI を選択して GOOGLE_API_KEY 環境変数の設定ガイドに従うか、個人利用の場合はブラウザベースの OAuth フローを完了してください。

Gitはプロジェクトディレクトリ内で初期化されている必要があります。Conductor はタスクごとにコミットを作成し、その元に戻す機能には Git に依存しています。新規プロジェクトから始める場合は以下の手順を実行してください。

# Initialize a new git repository if you haven't already
mkdir my-project && cd my-project
git init
git commit --allow-empty -m "Initial commit"

準備ができたら、Conductor をインストールします。

# Install the Conductor extension
gemini extensions install https://github.com/gemini-cli-extensions/conductor

# The --auto-update flag keeps Conductor updated to new releases automatically.
# Recommended for most users.
gemini extensions install https://github.com/gemini-cli-extensions/conductor --auto-update

このインストールでは、GitHub リポジトリから拡張機能をダウンロードし、6 つの Conductor コマンドを登録します。また、エントリポイントとして GEMINI.md コンテキストファイルを構成し、プランディレクトリに /conductor を設定します。これらの処理には数秒しかかかりません。

Gemini CLI を起動して /conductor と入力することで、インストールが成功したか確認できます。

gemini

その後、Gemini CLI セッション内では以下のようになります。

/conductor

setup、newTrack、implement、status、revert、そして review というサブコマンドの完全なリストが表示されるはずです。これらが見えれば、準備は完了です。

Conductor を使用してプロジェクトをセットアップする

/conductor:setup コマンドを実行します。

**

このコマンドはプロジェクトごとに一度だけ実行してください。他のすべての機能の基盤となるものです。Gemini CLI のセッション内で、プロジェクトディレクトリから以下を実行します。

/conductor:setup

Conductor はプロジェクトの分析を即座に開始します。既存プロジェクトの場合、コードベースをスキャンして対象となる環境を推測し、.gitignore の設定に従って node_modules や __pycache__ といったトークン消費量の多いディレクトリは除外します。新規プロジェクトの場合は、構築中の内容について説明を求めるようになります。

いずれにせよ、その後、ガイド付きの質問応答形式で進み、新しい conductor/ ディレクトリ内に作成される 6 つのアートファクトを埋めるための手順が示されます。

conductor/
├── product.md                 # Product vision, users, goals, key features, success criteria
├── product-guidelines.md      # UI standards, voice and tone, error handling behavior
├── tech-stack.md              # Languages, frameworks, databases, infrastructure
├── workflow.md                # TDD preferences, commit strategy, verification protocol
├── code_styleguides/          # Language-specific style guides (auto-generated per language found)
│   ├── python.md
│   ├── typescript.md
│   └── ...
└── tracks.md                  # Master registry of all tracks (starts empty)

各アーティファクトには特定の役割があります。product.md は「何を開発し、誰のために作るのか」という問いに答え、tech-stack.md はエージェントがあなたのスタック外のライブラリやパターンを提案しないように保証します。また、workflow.md では、テスト駆動開発（TDD）を採用するかどうか、コミット戦略はどのようなものか、各フェーズを進める前に必要な手動検証ステップは何かなどを定義します。

code_styleguides/ ディレクトリには、Conductor が事前に用意したテンプレートが言語別に含まれており、これらを必要に応じてカスタマイズできます。

セットアップが完了すると、プロジェクト内に conductor/ ディレクトリが表示されます。これをコミットしてください：

# Commit the conductor context to your repo
git add conductor/
git commit -m "chore: initialize Conductor context-driven development"

これ以降、リポジトリをクローンして Gemini CLI を起動するチームメンバーは、オンボーディング会話なしですぐにプロジェクトの全体コンテキストを利用できるようになります。

# /conductor:newTrack で機能開発を開始する

Conductor における「トラック」は、作業の単位を表す概念です。機能追加 1 つ、バグ修正 1 つ、アーキテクチャ変更 1 つ——それぞれが 1 つのトラックになります。これによりエージェントに明確な作業範囲が与えられ、それが迷走を防ぐための核心的な仕組みとなります。

構築したい内容を記述することでトラックを開始できます：

/conductor:newTrack "Add a dark mode toggle to the settings page, persisting the preference to localStorage"

引数なしで /conductor:newTrack を呼び出し、Conductor のプロンプトに応じて対話形式で機能を説明することも可能です。

Conductor はあなたの記述を受け取り、conductor/ ディレクトリからプロジェクト全体の文脈を読み込みます。そして、新しい conductor/tracks/<track_id>/ ディレクトリ内に 3 つのファイルを生成します：

conductor/tracks/
└── dark_mode_20260614/
    ├── spec.md           # The "what and why" -- requirements, goals, technical constraints, out of scope
    ├── plan.md           # The phased, task-level implementation checklist
    └── metadata.json     # Track ID, creation date, current status

トラック ID の形式は shortname_YYYYMMDD です。例えば、2026 年 6 月 14 日に作成されたダークモード用トラックなら dark_mode_20260614 とします。この形式にすることで、ファイルシステム上でトラックを時系列順に並べることができます。

spec.md** には仕様書が記載されています。ここでは「どのような課題を解決するのか」「目標は何か」「技術要件は何か」、そして「何の範囲外とするか」が明確に記されます。特に「範囲外」のセクションは、一見地味に見えますが非常に重要です。これがあれば、実装すべき機能を過剰に作り込む（ゴールド・プラッティングする）という失敗を防ぐことができます。

plan.md は、フェーズごとに整理された実装チェックリストです。ダークモード機能の実装例としては、以下のような構成になります。

# Implementation Plan - Dark Mode Toggle

## Phase 1: Foundation
- [ ] Task: Add `theme` key to the localStorage schema and document it in the project README
- [ ] Task: Create a `useTheme` hook that reads/writes the `theme` value and defaults to system preference
- [ ] Task: Write unit tests for `useTheme` -- verify default behavior, localStorage read, localStorage write
- [ ] Task: Conductor - User Manual Verification 'Foundation' (Protocol in workflow.md)

## Phase 2: UI Component
- [ ] Task: Build `ThemeToggle` component with accessible toggle button (aria-label, keyboard support)
- [ ] Task: Apply conditional CSS classes based on the current theme value from `useTheme`
- [ ] Task: Write component tests for `ThemeToggle` -- renders correctly, fires toggle on click
- [ ] Task: Conductor - User Manual Verification 'UI Component' (Protocol in workflow.md)

## Phase 3: Settings Page Integration
- [ ] Task: Import `ThemeToggle` into the Settings page component
- [ ] Task: Verify that preference persists across page refreshes and new browser tabs
- [ ] Task: Write integration test for the full settings page with dark mode enabled
- [ ] Task: Conductor - User Manual Verification 'Settings Page Integration' (Protocol in workflow.md)

「/conductor:implement」を実行する前に、この計画を確認してください。これは Conductor が設計された「人間が関与するループ（ヒューマン・イン・ザ・ループ）」の重要な瞬間です。

もしフェーズの内容に誤りがある場合、タスクが抜け落ちている場合、あるいは範囲が意図したよりも広すぎる場合は、今すぐ plan.md を編集してください。一度「implement」を実行すると、Conductor はこの計画に基づいてコードをコミットします。実装の途中で方針を変更することも可能ですが、ここで修正するよりもコストがかかります。

/conductor:implement による実装

**

計画に満足したら：

/conductor:implement

ここがConductorの真価が発揮される場所です。plan.mdを読み込み、チェックされていない最初のタスクを見つけると、その作業に取り掛かります。タスクを開始すると、チェックボックスを [ ] から [~]（進行中）に更新し、完了すると [x] に変更してGitコミットを作成します。これは1フェーズごとや1セッションごとのコミットではなく、完了したタスクごとに1つずつ作成されます。

Conductorが作業を進めるにつれて、コミットが蓄積していく様子が確認できます：

git log --oneline

出力例は以下の通りです：

a3f9c12 feat(theme): write integration test for settings page dark mode
b7e2d45 feat(theme): import ThemeToggle into Settings page
c1a8f90 feat(theme): add accessible toggle button with aria-label
d4b3e21 feat(theme): create ThemeToggle component with conditional CSS
e5c6d78 test(theme): write unit tests for useTheme hook
f7d9a34 feat(theme): create useTheme hook with localStorage persistence

各フェーズの終了時に、Conductor は手動検証のために一時停止します。現在のフェーズが正常に動作していることを確認するまで、次のフェーズには進みません。これはワークフローにおける「約束よりも実証を優先」という原則です。エージェントは単に「動作します」と言うのではなく、計画を進める前に実際に動作することを確認する必要があります。

TDD ワークフロー（workflow.mdで設定済み）を利用している場合、Conductor は自動的に以下のサイクルを繰り返します。まずテストを書き、その失敗を確認し、コードを実装してテストが通ることを確認したら、次のタスクへ移ります。これを手動で指示する必要はありません。この処理はワークフローファイルが自動で行います。

Conductor の状態はタスク間でディスクに保存されるため、いつでも中断できます。ラップトップを閉じたり、マシンを切り替えたり、翌日まで休んでも問題ありません。/conductor:implement を再度実行すれば、未チェックの最初のタスクから再開されます。実装内容はチャット履歴ではなく、plan.md に格納されています。

実装の途中で方針を変更する必要がある場合は、plan.md を直接編集してください。タスクを追加したり削除したり、フェーズの順序を入れ替えたりできます。Conductor は実行ごとにこのファイルを再読み込みするため、変更は即座に反映されます。

すべてのフェーズが検証され、タスクが完了すると、Conductor はトラックのアーカイブを提案します。具体的には conductor/tracks/dark_mode_20260614/ を conductor/tracks/archive/dark_mode_20260614/ へ移動し、tracks.md を更新して完了としてマークします。Git の履歴には、実装の全記録が保持されます。

# サポートコマンド

**

3 つのコアコマンドである setup、newTrack、implement がメインのワークフローを担います。残りの 4 つは、それを取り巻く処理を担当します。

// /conductor:status

プロジェクトが現在どの状態にあるかを確認するには、いつでもこのコマンドを実行してください。すべてのアクティブなトラックの状態が表示されます:

/conductor:status

Conductor は、conductor/tracks.md と各アクティブなトラックの plan.md を読み込み、その要約を返します。

Current Date/Time: Saturday, June 14, 2026

Project Status: 🟡 Active

Active Tracks:

• dark_mode_20260614 -- Phase 2 of 3 | 7/12 tasks complete (58%)
• api_auth_20260610 -- Phase 1 of 4 | 3/5 tasks complete (60%)

Next Action Needed:

• Run /conductor:implement to continue dark_mode_20260614 (current track)

休憩後、どこまで進んだか思い出したいときに使うコマンドです。

// /conductor:revert

何か問題が起きたときや、作業を元に戻す必要がある場合に使用します：

/conductor:revert

Conductor は、通常の git revert にはない Git の仕組みを理解しています。単なるコミットハッシュではなく、「トラック」「フェーズ」「個々のタスク」といった論理的な作業単位を認識するのです。

例えば、あるトラックの最後のフェーズを元に戻したい場合、Conductor はそのフェーズに属するコミット（タスクごとのコミット構造に基づいて）を特定し、きれいに巻き戻します。また、影響を受けたタスクをチェックボックスから外すように plan.md を更新するため、/conductor:implement を再実行して作業をやり直すことができます。

これは実務上非常に重要です。エージェントが 3 つのフェーズにわたって 14 コミットで 11 ファイルに手を加えた後に、コミットハッシュを手動で指定して巻き戻すのは、まさに地獄のような作業です。Conductor はその考古学的な調査を代行してくれます。

// /conductor:review

実装が完了し、プルリクエストを開く前の段階で使用します：

/conductor:review

Conductor は、完了した plan.md と conductor/product-guidelines.md を読み込み、品質チェックを行います。計画で指定された内容と実際に実装された内容の乖離（ドリフト）や、プロダクトガイドラインへの違反がないかを確認します。具体的には、エラーハンドリングの一貫性がない、アクセシビリティ属性が欠落している、スタイルガイドに反しているといった問題です。

これは、製品仕様書をすべて読み込み、機能が本来何をするべきかを正確に理解した AI コードレビュアーのようなものです。コードがマージされる前に、このレビューレポートを基に対処することができます。

// チェックトークン使用量

Conductor のコンテキスト駆動型アプローチでは、すべてのコマンド実行時にプロジェクトファイルが読み込まれるため、特に大規模プロジェクトのセットアップや計画フェーズにおいてトークンの消費が増加します。現在のセッションでの使用量は以下で確認できます。

/stats model

# チームにおける Conductor の仕組み

**

Conductor ワークフローの中で最も見落とされがちなのが、conductor/ ディレクトリをコミットした際に何が起こるかという点です。

Conductor が生成するすべてのファイル — product.md、tech-stack.md、workflow.md、スタイルガイド、各トラックの仕様書や計画書 — は、他のファイルと同様にリポジトリ内に保存されます。チームメンバーがリポジトリをプルすると、プロジェクト全体の文脈を即座に把握できます。Gemini CLI を起動して /conductor:status を実行すれば、現在進行中のすべてのトラックと、それぞれの進捗状況を実装計画のどこまで到達しているかを一目で確認できるのです。

これにより、オンボーディングの形が変わります。プロジェクトに新しく加わる開発者は、技術スタックの選択やコーディング規約、進行中の機能について2時間にわたる説明を受ける必要はありません。conductor/product.md と conductor/tech-stack.md を読み、 /conductor:status コマンドを実行するだけで、システム全体の運用状況が把握できます。

一貫性の維持という点でも、大きなメリットがあります。AI 支援によるプロジェクトへの貢献はすべて同じ基準に従うことになります。なぜなら、すべてのエージェント・セッションが共通のコンテキストファイルを読み込むからです。ある開発者の Conductor セッションで書かれたコードも、別の開発者のセッションと同じスタイルになります。両方のセッションが同じ code_styleguides/ ディレクトリを基盤としているためです。

これはプロジェクトがスケールするほど維持が難しくなる「チームの調和」という性質ですが、Conductor はこれを構造的にワークフローに組み込んでおり、開発者が手動で強制することに依存していません。

# ダークモード切り替え機能の実装：完全なウォークスルー

**

具体的な機能を実装する際の、最初から最後までの一連の Conductor ワークフローを紹介します。これが、実際のプロジェクトで最初のトラックを作成する際の参照資料となります。

// ステップ 1: プロジェクトディレクトリから Gemini CLI を開く

cd your-project
gemini

// ステップ 2: このプロジェクト用にまだ Conductor をセットアップしていない場合は、まずセットアップを実行

/conductor:setup

ガイド付きの質問に答えてください。完了したら conductor/ ディレクトリをコミットします。

// ステップ 3: トラックを作成する

/conductor:newTrack "Add a dark mode toggle to the settings page, persisting the user preference to localStorage and defaulting to system preference on first visit"

Conductor は、conductor/tracks/dark_mode_20260614/ ディレクトリ内に spec.md と plan.md を生成します。

// ステップ 4: 実行前に計画書（plan.md）を確認する

エディタで plan.md を開き、すべてのタスクを読み込んでください。各フェーズが妥当か確認します。もし何か問題がある場合——欠落しているタスク、存在不应该するフェーズ、範囲が広すぎるなど——その場でファイルを編集して保存してください。Conductor は毎回このファイルを読み直すため、編集内容は即座に反映されます。

// ステップ 5: 実装を実行する

/conductor:implement

Conductor がタスクを処理し、随時コミットを作成していく様子を確認してください。フェーズ 1 の完了地点に達すると、Conductor は一時停止して手動での検証を求めます。作業内容を検証し、問題がないことを確認すれば、Conductor は自動的にフェーズ 2 へ進みます。

// ステップ 6: いつでも進行状況を確認する

/conductor:status

// ステップ 7: 完了した実装をレビューする

/conductor:review

レビューで見つかった課題があれば対応し、クリーンな実装と完全なテストスイート、機能タスクごとに整理された Git の履歴、そして「何を」「なぜ」構築したかを明確に記した仕様書を持ってプルリクエストを作成してください。

セットアップからレビューまでの一連の流れは、その後のすべての機能開発において繰り返し可能です。conductor/ ディレクトリには、何が作られ、各決定に至った理由、プロジェクトが従う基準といった生きた記録が蓄積されていきます。

# 始める前に知っておくべきいくつかのポイント

• トークン消費は現実的な問題です。Conductor はコマンド実行ごとにプロジェクトのコンテキストファイルを読み込みます。小規模なプロジェクトであれば影響はほぼ無視できますが、conductor/ ディレクトリに多くのトラックが存在する大規模な既存プロジェクト（ブラウンフィールド）では、その合計値は無視できません。特にセットアップや計画フェーズで顕著です。/stats model コマンドを使って使用状況を監視し、完了したトラックは定期的にアーカイブして、アクティブな tracks.md を軽量に保つことをお勧めします。

「--auto-update」フラグの使用はおすすめです。Conductor は現在プレビュー段階であり、2025 年 12 月以降頻繁にリリースされています GitHub リリースページ。このフラグを有効にすれば、手動で再インストールする必要なく、自動的に改善が適用されます。

出力の質は、入力されるコンテキストの質によって決まります。これは「文脈駆動型開発」の裏返しでもあります。product.md が曖昧であれば計画も曖昧になり、テストフレームワークを明記していない tech-stack.md では、計画が推測に頼ることになります。セットアップ用のアーティファクトに費やす時間は、その後のすべての作業において大きなリターンをもたらします。

Conductor はコードレビューの代替にはなりません。「/conductor:review」は明らかなズレやスタイルの問題を検出する有用な手段ですが、マージ前の人間によるレビューを完全に置き換えるものではありません。これは最終的なゲートではなく、最初のチェックとして扱うべきです。

# 結論

Conductor がもたらす変化の本質は、速度そのものにあるわけではありません。コーディングの前に仕様書と計画を作成するプロセスは、最初の 1 時間においては即座に実装に取り掛かるよりも遅いものです。しかし、その後のメリットは計り知れません。セッションを跨いで一貫して軌道に乗るエージェント、あなたが中断した場所から引き継ぎ可能なチームメイト、すべての貢献者が同じ文脈に基づいて作業することでコードベース全体が整合性を持つようになること。これこそが真の価値です。 （原文の技術表記: --auto-update）

Google が Conductor を紹介する際の枠組みは、「ドキュメントを真実の源として扱う」「エンジニアチームの真の拡張として Gemini を機能させる」というものです。これは正しい記述ですが、より実践的な捉え方をするなら、Conductor はエージェントの振る舞いを予測可能にするツールだと言えます。実際にコードを書き出してリリースする際、必要なのはまさにこの「予測可能性」です。

セットアップには一度のセッションで十分です。そこで構築されたコンテキストは、その後のすべてのセッションにわたって維持されます。インストールコマンド一つで試せるツールにとって、これは非常に優れたコストパフォーマンスです。

インストールして、次のプロジェクトで /conductor:setup を実行し、最初のコード行を書く前にどのようなプランが描かれるかを確認してください。

// Resources

• Conductor GitHub リポジトリ

• Google Developers Blog — Conductor 発表記事

• Google Codelab — Gemini CLI Conductor で計画とアプリ構築

• Gemini CLI 拡張機能ディレクトリ

Shittu Olumide 氏（LinkedIn）は、最先端の技術を駆使して魅力的な物語を紡ぐことに情熱を注ぐソフトウェアエンジニアであり技術ライターです。細部へのこだわりと複雑な概念をわかりやすく解説する能力に長けています。また、Twitter でも活動しています。