Gemini CLIのコンテキスト駆動開発ツールConductorを使ってみた

目次

1.Conductorとは何か
2.Conductorのインストール
3.Conductorを使ってみた
4.終わりに

1.Conductorとは何か

Gemini CLI の拡張機能の一つで、2025年12月17日に公開されました。
Conductor: Introducing context-driven development for Gemini CLI

Conductor はコンテキスト駆動開発を実現するための拡張機能です。
仕様や計画を Markdown ファイルで管理し、「Context → Spec & Plan → Implement」という構造化されたワークフローに落とし込みます。
このワークフローにおいてプロジェクト共通のコンテキスト、例えばコーディングルールや使用技術の制約を定義し、チーム間で共有しておけば、どの開発者がコマンドを実行しても AI が共通ルールに沿った成果物を出力してくれるので、プロジェクト全体として一貫性のある開発が可能となります。
ざっくりとした説明は上記となります。
詳細についてはこちらのREADMEを参照ください。

本ブログでは実際に Conductor をインストールし、Conductor を使っての Google Cloud 環境の インフラコード（Terraform）生成をしてみます。
※今回は Conductor を動かしてみることが主題なのでインフラ構成はシンプルなものとします。

2.Conductorのインストール

私の端末の環境について、利用OS、Gemini CLI、Node.js のバージョンは以下です。

• macOS：Sequoia 15.7.2
• Gemini CLIのバージョン（ gemini --version ）：0.22.5
• Node.jsのバージョン（ node --version ）：24.11.1

カタログサイトにのっているインストールコマンドをターミナルで実行します。

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

この時点では Gemini CLI を立ち上げていません。
インストール実行時、サードパーティ製品に関する注意書きが表示されます。Yesで続行します。

Installing extension "conductor".
**The extension you are about to install may have been created by a third-party developer and sourced from a public repository. Google does not vet, endorse, or guarantee the functionality or security of extensions. Please carefully inspect any extension and its source code before installing to understand the permissions it requires and the actions it may perform.**
This extension will append info to your gemini.md context using GEMINI.md
Do you want to continue? [Y/n]: Y
Extension "conductor" installed successfully and enabled.

これで Conductor のインストールが成功です。

次にターミナルで gemini コマンドを実行し、Gemini CLI を立ち上げます。
/extensions listコマンドでアクティブな拡張機能を確認できます。

出力結果を見ると conductor が active で表示されています。

Installed extensions:
  conductor (v0.1.1) - active (up to date)

次にカスタムコマンドです。
/conductor と入力すると5つのコマンドが表示されました。

それぞれのコマンドの概要を日本語で直訳すると以下です。

• conductor:status – プロジェクトの現在の進捗を表示する。
• conductor:setup – プロジェクトの足場組みをし、Conductor 環境をセットアップする。
• conductor:revert – 以前の作業を巻き戻す。
• conductor:newTrack – トラックを計画、トラック固有の spec ドキュメントを生成し、tracks ファイルを更新する。
• conductor:implement – 指定されたトラックの plan に定義されたタスクを実行する。

これらのカスタムコマンドの toml ファイルについては後ほど触れます。
そもそもカスタムコマンドとは？という方は弊社ブログの Gemini CLIのCustom commandsを作ってみた を参照ください。

Gemini CLI を一旦閉じ、拡張機能に関するディレクトリを見てみます。
~/.gemini/extensions/conductor/ディレクトリ配下に、Conductor 用ファイルが配置されています。

$ ls
commands        gemini-extension.json   LICENSE         templates
CONTRIBUTING.md     GEMINI.md       README.md

Conductor のコアとなるのは GEMINI.md と commands フォルダ内の toml ファイルです。
まず GEMINI.md についてです。GEMINI.md は システムプロンプトの様な役割です。
Gemini CLI がユーザーからの質問や指示を受け取った際、まずここを参照します。
内容は以下です。

# Conductor Context

If a user mentions a "plan" or asks about the plan, and they have used the conductor extension in the current session, they are likely referring to the `conductor/tracks.md` file or one of the track plans (`conductor/tracks/<track_id>/plan.md`).

日本語訳すると、「ユーザーが plan について言及したり、plan について質問したりする際、現在のセッションで conductor extension を使用している場合、おそらく conductor/tracks.md ファイルまたはいずれかの track のplanを指していると考えられます」と記載されています。
これはユーザーが plan という単語を使った際、それは conductor の文脈で使っているという事を AI に理解させる役割を果たします。

続いてカスタムコマンドです。
~/.gemini/extensions/conductor/commands/conductor/ディレクトリ配下に toml ファイルが格納されています。

$ ls
implement.toml  newTrack.toml   revert.toml setup.toml  status.toml

setup.toml がコンテキストの作成について、newTrack.toml が新しいトラック（機能やプロジェクト単位の仕様、作業計画を包摂した概念）の作成について、implement.toml が作成したコンテキストやトラックの実行について、revert.toml がトラックや作業計画内のタスクの切り戻しについて、status.toml がトラックの進行状況の表示ついて記載されています。
これらの toml ファイルの中身ですが、57行から470行前後と長いものになっております。
全容は公式リポジトリで確認できますので、詳しくは以下のリンクから参照ください。

• setup.toml
• newTrack.toml
• implement.toml
• status.toml
• revert.toml

3.Conductorを使ってみた

実際に Conductor を使い Google Cloud のインフラリソースの Terraform コードを生成してみます。
/conductor:setupコマンドでコンテキスト、仕様、作業計画を策定し、それを/conductor:implementコマンドで実装していく流れです。
※本ブログの目的は Conductor を動かしてみることなので、インフラ構成は最低限のものとします。
/conductor:setup と /conductor:implementコマンドの実行に伴う Gemini CLI でのやり取りは長く、多くのトークンを消費する都合からもインフラ構成は最低限とします。

/conductor:setupコマンドの実行

Gemini CLI を立ち上げ出力言語は日本語指定とする形で実行してみます。

> /conductor:setup "出力言語は日本語でお願いします"

下記の通りまずは手順を提示し、次にGemini CLI を実行しているルートディレクトリの状態を確認します。
今回、ルートディレクトリは空の状態からスタートしています。
Gemini によるプロジェクトの状態確認の後、Git レポジトリの初期化が実行されます。
Git についてですが、Conductor の動きとしてタスク完了時や物事の決めのタイミングで Git コマンドが実行され、その内容をコミットします。

✦ Conductorへようこそ。プロジェクトのセットアップを開始します。以下の手順で進めていきます。

   1. プロジェクトの調査: 現在のディレクトリを分析し、新規プロジェクトか既存プロジェクトかを判断します。
   2. 製品の定義: 製品のビジョン、デザインガイドライン、技術スタックを共同で定義します。
   3. 設定: 適切なコードスタイルガイドを選択し、開発ワークフローをカスタマイズします。
   4. トラックの生成: 最初の「トラック（開発の単位）」を定義し、開発を開始するための詳細な計画を自動生成します。

  まず、プロジェクトの状態を確認します。
〜〜省略〜〜
✦ 新規プロジェクトとして初期化を開始します。
  まず、Gitレポジトリを初期化します。
〜〜省略〜〜
新しいGitレポジトリを初期化しました。

次に何を作りたいか質問されます。
Google Cloud 環境用のインフラを作成したい旨を入力しました。

  これから何を作成しますか？どのような製品、あるいはアプリケーションを作りたいか教えてください。

> Google Cloud環境のインフラをTerraformで作りたいです。tfstate管理はCloud Storageとします。利用リージョンはasia-northeast1、最小構成でwebサーバーを一台作成してください。Machine Typeはe2-micro、OSはDebian 11、NetworkはVPC / Subnets、Cloud
  Router / Cloud NAT、Firewall Rulesを使ってください。tfstate管理のCloud Storageはinitフォルダに、webサーバーのリソースはmainフォルダに作成してください。Cloud Storageはterraform applyでデプロイしますが、webサーバーはterrfaform
  planの実行までとしてください。

先ほどのリクエストをもとに、まずは product.md というプロジェクトの基本概念を記録したファイルが作成されます。
setup_state.json というファイルは/conductor:setupコマンドの進捗状態を記録するメタデータファイルです。
現状の値は空です。

✓  WriteFile Writing to conductor/product.md   
$ ls
product.md      setup_state.json
$ cat product.md 
# Initial Concept

Google Cloud環境のインフラをTerraformで作りたいです。tfstate管理はCloud Storageとします。利用リージョンはasia-northeast1、最小構成でwebサーバーを一台作成してください。Machine Typeはe2-micro、OSはDebian 11、NetworkはVPC / Subnets、Cloud Router / Cloud NAT、Firewall Rulesを使ってください。tfstate管理のCloud Storageはinitフォルダに、webサーバーのリソースはmainフォルダに作成してください。Cloud Storageはterraform applyでデプロイしますが、webサーバーはterrfaform planの実行までとしてください。

$ cat setup_state.json 
{"last_successful_step": ""}

次にプロジェクトの基本概念に続く「製品ガイド（Product Guide）」作成に関する質問が始まるので回答していきます。

✦ product.mdを作成し、プロジェクトの基本概念を記録しました。

  次に、より詳細な「製品ガイド（Product Guide）」を作成するための質問をいくつかさせてください。

  質問 1/5
  このインフラストラクチャプロジェクトの主な利用者は誰になりますか？ (Select all that apply)

  A) インフラエンジニア / SRE (保守・運用担当)
  B) アプリケーション開発者 (このインフラ上でアプリを動かす)
  C) 初心者 / 学習者 (GCPとTerraformの学習目的)
  D) [Type your own answer]
  E) [Autogenerate and review product.md]

> A

✦ 承知いたしました。主な利用者はインフラエンジニアおよびSREですね。

  質問 2/5
  このインフラ構築における主要な目的・ゴールは何ですか？ (Select all that apply)

  A) 自動化と再現性の確保 (Terraformによる完全なIaC化)
  B) セキュリティとベストプラクティスの遵守 (Private IPの利用、Cloud NAT経由の外部アクセスなど)
  C) コストの最小化 (e2-microなどの利用による低コスト運用)
  D) [Type your own answer]
  E) [Autogenerate and review product.md]

> C

✦ 承知いたしました。コストの最小化が重要なゴールですね。

  質問 3/5
  この環境はどのようなフェーズ（段階）として位置付けられますか？ (Select all that apply)

  A) プロトタイプ / 検証用 (PoC)
  B) 学習・実験用環境
  C) 将来的な本番環境のベース
  D) [Type your own answer]
  E) [Autogenerate and review product.md]

> A

✦ 承知いたしました。検証用のプロトタイプとして、コストを抑えた構成を目指します。

  質問 4/5
  Webサーバーへのアクセス管理およびセキュリティについて、どのようなアプローチを希望しますか？ (Select all that apply)

  A) セキュリティ重視: パブリックIPは付与せず、外部への通信はCloud NATを利用、管理アクセスはFirewallで厳格に制限する
  B) 簡素化重視: パブリックIPを付与し、直接インターネットからのアクセスを可能にする
  C) ベストプラクティス重視: IAP (Identity-Aware Proxy) を利用して、パブリックIPなしで安全にSSH接続できるようにする
  D) [Type your own answer]
  E) [Autogenerate and review product.md]

> D。FirewallはHTTP(80), 0.0.0.0/0を許可、SSH アクセスはOS Login + IAP（Identity-Aware Proxy）でセキュアに実現してください。

✦ 承知いたしました。
  HTTPは全開放、SSHはOS LoginとIAPを使ってセキュアに接続する構成ですね。

  質問 5/5
  Terraformのディレクトリ構成について、希望はありますか？ (Select all that apply)

  A) フラットな構成 (推奨): main.tf, variables.tf, outputs.tf など、標準的なファイル分割を採用
  B) モジュール分割構成: ネットワーク、サーバー、ストレージなどを個別のモジュールとして分割して管理
  C) 環境別構成: envs/dev, envs/prod のように環境ごとにディレクトリを分ける
  D) [Type your own answer]
  E) [Autogenerate and review product.md]

> A。tfstateはinitフォルダ、webサーバーはmainフォルダとし、そのフォルダ内にtfファイルを作成してください。

✦ 承知いたしました。フラットな構成で、initとmainのディレクトリにそれぞれファイルを配置します。

  これで、製品ガイド（product.md）の作成に必要な情報が揃いました。ドラフトを作成します。

    1 # Product Guide - GCP Infrastructure with Terraform
    2 
    3 ## 1. Initial Concept
    4 Google Cloud環境のインフラをTerraformで構築します。tfstate管理はCloud Storageとし、asia-northeast1リージョンに最小構成のWebサーバーを1台作成します。
    5 
    6 ## 2. Target Users
    7 - **インフラエンジニア / SRE:** プロジェクトの保守、運用、および拡張を担当するエンジニア。
    8 
    9 ## 3. Goals
   10 - **コストの最小化:** e2-micro インスタンスや最小限のリソース構成を採用し、運用コストを抑える。
   11 - **自動化と再現性の確保:** Terraformを用いてIaC（Infrastructure as Code）を実現する。
   12 
   13 ## 4. Key Features & Scope
   14 - **インフラ構成:**
   15     - リージョン: asia-northeast1
   16     - ネットワーク: VPC, Subnets, Cloud Router, Cloud NAT
   17     - サーバー: e2-micro (Debian 11)
   18     - セキュリティ: 
   19         - Firewall: HTTP (80) を 0.0.0.0/0 から許可
   20         - SSHアクセス: OS Login + IAP (Identity-Aware Proxy) によるセキュアな接続
   21 - **Terraform構成:**
   22     - ディレクトリ分割:
   23         - `init/`: tfstate管理用のCloud Storageバケットを作成（`terraform apply`まで実施）
   24         - `main/`: Webサーバー関連のリソースを作成（`terraform plan`まで実施）
   25     - 状態管理: Cloud Storage (GCS) をバックエンドとして利用
   26 
   27 ## 5. Phase / Context
   28 - **プロトタイプ / 検証用 (PoC):** 本番環境を見据えた最小構成の検証環境。

  次の中から選んでください。
  A) 承認: 内容は正しいので次に進みます。
  B) 変更を提案: 修正が必要な箇所を教えてください。

  AまたはBで回答してください。

> A

✦ 製品ガイドが承認されました。conductor/product.md を更新し、状態を保存します。

「製品ガイド（Product Guide）」の回答完了に伴い、product.md ファイルが更新されます。
setup_state.json について、以前は値が空でしたが、ステップの完了のたびに記録、更新されていきます。

$ cat product.md 
# Initial Concept

Google Cloud環境のインフラをTerraformで作りたいです。tfstate管理はCloud Storageとします。利用リージョンはasia-northeast1、最小構成でwebサーバーを一台作成してください。Machine Typeerはe2-micro、OSはDebian 11、NetworkはVPC / Subnets、Cloud Router / Cloud NAT、Firewall Rulesを使ってください。tfstate管理のCloud Storageはinitフォルダに、webサーバーのリソースはmainフォルダに作成してください。Cloud Storageはterraform applyでデプロイしますが、webサーバーはterrfaform planの実行までとしてください。

# Product Guide - GCP Infrastructure with Terraform

## 1. Target Users
- **インフラエンジニア / SRE:** プロジェクトの保守、運用、および拡張を担当するエンジニア。

## 2. Goals
- **コストの最小化:** e2-micro インスタンスや最小限のリソース構成を採用し、運用コストを抑える。
- **自動化と再現性の確保:** Terraformを用いてIaC（Infrastructure as Code）を実現する。

## 3. Key Features & Scope
- **インフラ構成:**
    - リージョン: asia-northeast1
    - ネットワーク: VPC, Subnets, Cloud Router, Cloud NAT
    - サーバー: e2-micro (Debian 11)
    - セキュリティ: 
        - Firewall: HTTP (80) を 0.0.0.0/0 から許可
        - SSHアクセス: OS Login + IAP (Identity-Aware Proxy) によるセキュアな接続
- **Terraform構成:**
    - ディレクトリ分割:
        - `init/`: tfstate管理用のCloud Storageバケットを作成（`terraform apply`まで実施）
        - `main/`: Webサーバー関連のリソースを作成（`terraform plan`まで実施）
    - 状態管理: Cloud Storage (GCS) をバックエンドとして利用

## 4. Phase / Context
- **プロトタイプ / 検証用 (PoC):** 本番環境を見据えた最小構成の検証環境

$ cat setup_state.json 
{"last_successful_step": "2.1_product_guide"

次に「製品ガイドライン（product-guidelines.md）」の作成に関する質問に進みます。
これも先程と同じように回答していきます。

✦ 次に、プロジェクトの「製品ガイドライン（product-guidelines.md）」を作成します。これは、コードやドキュメントの記述スタイル、推奨される手法などを定義するものです。

  質問 1/5
  Terraformのコードスタイルについて、特に意識したいことはありますか？ (Select all that apply)

  A) 可読性重視: 適切なコメント、明確なリソース命名、フォーマットの統一 (terraform fmt) を徹底する
  B) 柔軟性重視: 変数 (variables.tf) を積極的に活用し、再利用可能なコードにする
  C) シンプルさ重視: 複雑なロジックを避け、設定が直感的にわかるようにする
  D) [Type your own answer]
  E) [Autogenerate and review product-guidelines.md]

  ※ Aを推奨します。Terraformにおいて可読性と一貫性は、保守性の向上に直結するためです。

> A

✦ 承知いたしました。可読性を重視し、フォーマットの統一や明確な命名を心がけます。

  質問 2/5
  リソースの命名規則について、どのようなルールを採用しますか？ (Select all that apply)

  A) プレフィックス/サフィックス方式: web-server-vm, prod-vpc-network のように、役割や環境を名前に含める
  B) 簡潔さ重視: web, network のように、コンテキストから明らかな場合は短く保つ
  C) ハイフン区切り (`snake-case` または `kebab-case`): 全て小文字で、単語間をハイフンで繋ぐ
  D) [Type your own answer]
  E) [Autogenerate and review product-guidelines.md]

  ※ AとCの組み合わせを推奨します。GCPリソースの仕様に合わせやすく、識別も容易になります。

> AとCの組み合わせとしてください。

✦ 承知いたしました。プレフィックス/サフィックスを活用した、ハイフン区切りの小文字（kebab-case）で統一します。

  質問 3/5
  開発の原則 (Development Principles) について、どのような方針を重視しますか？ (Select all that apply)

  A) Keep It Simple, Stupid (KISS): 複雑なモジュール化は避け、読みやすさと直感的な理解を最優先する
  B) Don't Repeat Yourself (DRY): 重複を避け、変数やモジュールを活用してコードを共通化する
  C) Fail Fast: 早期にエラーを検知できるよう、可能な限りTerraformの validation ブロックなどを活用する
  D) [Type your own answer]
  E) [Autogenerate and review product-guidelines.md]

  ※ 今回はPoCかつ最小構成であるため、A（シンプルさ）をベースにすることを推奨します。

> A

✦ 承知いたしました。シンプルさを最優先にし、直感的に理解できる構成を目指します。

  質問 4/5
  ドキュメント作成の方針について、何を選択しますか？ (Select all that apply)

  A) 自己文書化コード: リソース名や変数名を工夫し、コードを読むだけで意図が伝わるようにする
  B) README重視: 各ディレクトリ (init, main) に README.md を配置し、役割と手順を明記する
  C) 詳細コメント: 全てのリソース定義に、なぜその設定が必要なのかを説明するコメントを付ける
  D) [Type your own answer]
  E) [Autogenerate and review product-guidelines.md]

  ※ Bを推奨します。Terraformは実行順序や依存関係が重要なため、READMEによるガイドが非常に有用です。

> B

✦ 承知いたしました。各ディレクトリに README.md を配置し、手順を明確にします。

  質問 5/5
  セキュリティの考え方について、どのような方針を明文化しますか？ (Select all that apply)

  A) 最小権限の原則: 必要なポートのみを開放し、不必要な公開IPの付与は避ける
  B) 機密情報の管理: tfstate に含まれる可能性のある機密情報を考慮し、GCSバケットの権限管理を適切に行う
  C) セキュアなアクセス: 管理操作（SSHなど）には専用の経路（IAPなど）を必須とする
  D) [Type your own answer]
  E) [Autogenerate and review product-guidelines.md]

  ※ 今回の要件に基づき、A, B, C 全てを含めることを推奨します。

> A, B, C 全てを含めてください。

✦ 承知いたしました。セキュリティ方針を明確にガイドラインに含めます。

  これで製品ガイドライン（product-guidelines.md）のドラフトが作成できました。

    1 # Product Guidelines - GCP Infrastructure with Terraform
    2 
    3 ## 1. Code Style
    4 - **可読性の向上:** `terraform fmt` を実行し、コードのフォーマットを常に統一する。
    5 - **明確な構成:** リソース定義、変数、出力などを適切にファイル分割（`main.tf`, `variables.tf`, `outputs.tf`）し、一目で役割がわかるようにする。
    6 
    7 ## 2. Naming Conventions
    8 - **Naming Style:** 全て小文字、単語間をハイフンで繋ぐ `kebab-case` を採用する。
    9 - **Suffix/Prefix:** リソースの役割や種類を明確にするため、`web-server-vm` や `default-vpc-network` のようにサフィックスまたはプレフィックスを付与する。
   10 
   11 ## 3. Development Principles
   12 - **Keep It Simple (KISS):** 最小構成であることを尊重し、過度なモジュール化や複雑なロジックを避ける。
   13 - **自己文書化:** 意図の明確な命名を心がけつつ、複雑な設定箇所には「なぜその設定が必要か」を記すコメントを付与する。
   14 
   15 ## 4. Documentation
   16 - **README Driven:** 各ディレクトリ (`init/`, `main/`) に `README.md` を作成し、そのディレクトリのリソースが何であるか、どのような手順で適用すべきかを明記する。
   17 
   18 ## 5. Security & Best Practices
   19 - **最小権限:** Firewallは必要最低限のポート（HTTP: 80）のみを許可する。
   20 - **セキュアアクセス:** SSH接続は IAP (Identity-Aware Proxy) と OS Login を利用し、パブリックIPを持たないインスタンスへの安全な接続を確保する。
   21 - **機密管理:** `tfstate` は GCS で管理し、バケットへのアクセス権限を適切に制限する。

  次の中から選んでください。
  A) 承認: 内容は正しいので次に進みます。
  B) 変更を提案: 修正が必要な箇所を教えてください。

  AまたはBで回答してください。

> A

✦ 製品ガイドラインが承認されました。conductor/product-guidelines.md を作成し、状態を保存します。

「製品ガイドライン（product-guidelines.md）」のヒアリング完了に伴い、product-guidelines.md ファイルが作成されます。

$ ls
product-guidelines.md   product.md      setup_state.json

$ cat setup_state.json 
{"last_successful_step": "2.2_product_guidelines"}

次に「利用する技術スタック（tech-stack.md）」の定義に関する質問に回答します。

✦ 次に、利用する技術スタック（tech-stack.md）を定義します。

  質問 1/2
  Terraformのバージョンについて、指定はありますか？

  A) 最新の安定版 (v1.x)
  B) 特定のバージョンを指定する (例: v1.5.0 など)
  C) [Type your own answer]
  D) [Autogenerate and review tech-stack.md]

  ※ 特に理由がなければ A を推奨します。最新の機能とセキュリティ修正を利用できるためです。

> B。1.14.3 としてください。

✦ 承知いたしました。Terraformのバージョンは 1.4.3 を使用しますね（※ご入力の 1.14.3 は未来のバージョンの可能性があるため、現時点で安定している 1.4.3 と解釈させていただきます。もし最新の 1.6.x 以降などを意図されている場合はお知らせください）。

  質問 2/2
  Google Cloud Provider (Google Provider) のバージョンについて、指定はありますか？

  A) 最新の安定版 (v5.x)
  B) 特定のバージョンを指定する
  C) [Type your own answer]
  D) [Autogenerate and review tech-stack.md]

  ※ Aを推奨します。最新のGCPリソースに対応しているためです。

  ---
  注: 前提条件として、以下の情報は既に確定しているものとして扱います。
   - リージョン: asia-northeast1
   - インスタンス: e2-micro, Debian 11
   - バックエンド: Google Cloud Storage (GCS)

> A

✦ 承知いたしました。Google Providerは最新の安定版（v5.x系）を使用します。

  技術スタックドキュメント（tech-stack.md）のドラフトを作成しました。

    1 # Tech Stack - GCP Infrastructure with Terraform
    2 
    3 ## 1. Core Tools
    4 - **Terraform:** v1.4.3
    5 - **Google Cloud SDK (gcloud):** 最新の安定版（Terraform実行環境にインストールされていること）
    6 
    7 ## 2. Infrastructure (Google Cloud)
    8 - **Provider:** hashicorp/google v5.x
    9 - **Region:** asia-northeast1
   10 - **State Management:** Google Cloud Storage (GCS)
   11 
   12 ## 3. Resource Specifications
   13 - **Compute:**
   14   - Machine Type: e2-micro
   15   - Image: debian-cloud/debian-11
   16 - **Network:**
   17   - VPC Network
   18   - Regional Subnets
   19   - Cloud Router & Cloud NAT
   20   - Firewall Rules (HTTP: 80)
   21   - Identity-Aware Proxy (IAP) for SSH
   22 
   23 ## 4. Environment Requirements
   24 - GCP プロジェクトが作成済みであること
   25 - Terraform 実行ユーザーに、プロジェクトの編集者権限、または必要なリソースの作成権限が付与されていること

  次の中から選んでください。
  A) 承認: 内容は正しいので次に進みます。
  B) 変更を提案: 修正が必要な箇所を教えてください。

  AまたはBで回答してください。

> A

✦ 技術スタックが承認されました。conductor/tech-stack.md を作成し、状態を保存します。

「利用する技術スタック（tech-stack.md）」のヒアリング完了に伴い、tech-stack.md ファイルが作成されます。

$ ls
product-guidelines.md   product.md      setup_state.json    tech-stack.md

$ cat setup_state.json 
{"last_successful_step": "2.3_tech_stack"}

次に「プロジェクトのコードスタイルガイド」に関する質問に答えます。

✦ 次に、プロジェクトのコードスタイルガイドを選択します。今回の技術スタック（Terraform / GCP）に基づき、適切なガイドをコピーします。

  以下のスタイルガイドを推奨します：
   - terraform.md: Terraformのベストプラクティス、構文、構造に関するガイド

  これらを選択して進めてよろしいでしょうか？

  A) はい（推奨されるスタイルガイドを含める）
  B) 編集する（リストから自分で選択する）

  AまたはBで回答してください。

> A

✦ 承知いたしました。推奨されるTerraformスタイルガイドをプロジェクトにコピーします。
〜〜省略〜〜
✦ Terraform専用のテンプレートが現在存在しないため、general.md をコピーし、Terraform向けに調整することを推奨します。

  または、今回は既に製品ガイドライン（product-guidelines.md）で詳細なTerraformスタイルを定義しているため、general.md のみをコピーして進めることも可能です。

  いかがいたしましょうか？
  A) general.md をコピーして進める
  B) 自分で追加の指定を行う

  AまたはBで回答してください。

> A

✦ 承知いたしました。general.md をプロジェクトのスタイルガイドとしてコピーします。

「プロジェクトのコードスタイルガイド」のヒアリング完了に伴い、/code_styleguides/general.md ファイルが作成されます。

$ ls
code_styleguides    product-guidelines.md   product.md      setup_state.json    tech-stack.md

$ cd code_styleguides/

$ ls
general.md

$ cat general.md 
# General Code Style Principles

This document outlines general coding principles that apply across all languages and frameworks used in this project.

## Readability
- Code should be easy to read and understand by humans.
- Avoid overly clever or obscure constructs.

## Consistency
- Follow existing patterns in the codebase.
- Maintain consistent formatting, naming, and structure.

## Simplicity
- Prefer simple solutions over complex ones.
- Break down complex problems into smaller, manageable parts.

## Maintainability
- Write code that is easy to modify and extend.
- Minimize dependencies and coupling.

## Documentation
- Document *why* something is done, not just *what*.
- Keep documentation up-to-date with code changes.

$ cat setup_state.json 
{"last_successful_step": "2.4_code_styleguides"

次に「プロジェクトのワークフロー設定」に関する質問に答えます。

✦ 次に、プロジェクトのワークフロー設定を行います。デフォルトのワークフローは以下の通りです。

   - テストカバレッジ 80% 以上
   - 各タスク完了ごとに変更をコミット
   - タスク概要の記録に Git Notes を使用

  このままデフォルト設定を使用しますか、それともカスタマイズしますか？

  A) デフォルト設定を使用する
  B) カスタマイズする

  AまたはBで回答してください。

> A

✦ デフォルト設定を適用します。

workflow.md ファイルが作成されます。
中身についてはかなり長いため省きますが、開発プロセスのガイドラインが記載されています。

$ ls
code_styleguides    product.md      tech-stack.md
product-guidelines.md   setup_state.json    workflow.md

$ cat setup_state.json 
{"last_successful_step": "2.5_workflow"}

ここで初期セットアップ完了の旨のメッセージが表示されます。

✦ 初期セットアップが完了しました。これまでに以下のファイルを生成・設定しました。

   - conductor/product.md: 製品のビジョンとスコープ
   - conductor/product-guidelines.md: 命名規則やセキュリティ方針
   - conductor/tech-stack.md: TerraformとGCPの技術構成
   - conductor/code_styleguides/general.md: 一般的なコードスタイル
   - conductor/workflow.md: 開発の流れとルール

次に仕様、作業計画周りの情報を定義する「トラック」の質問に答えます。

質問 1/5
  GCPプロジェクトの認証と権限について確認させてください。 (Select all that apply)

  A) 既にローカル環境で gcloud auth application-default login が実行され、適切なプロジェクトが設定されている
  B) Terraform用のサービスアカウントキー (JSON) を使用する予定である
  C) まだ認証設定は行っておらず、セットアップの中で手順を確認したい
  D) [Type your own answer]
  E) Auto-generate the rest of requirements and move to the next step

  ※ Aを推奨します。個人の検証環境であれば最もシンプルで安全な方法です。

> A

✦ 承知いたしました。ローカル環境の認証（ADC）を利用して進めます。

  質問 2/5
  使用する GCP プロジェクト ID を教えてください。

  A) 特定のプロジェクト ID を今入力する
  B) 実行時に変数として指定できるようにし、現時点ではプレースホルダー（例: your-project-id）とする
  C) [Type your own answer]
  D) Auto-generate the rest of requirements and move to the next step

  ※ Bを推奨します。コードの汎用性が高まり、後の変更も容易になります。

> A。conductor-gcp

✦ 承知いたしました。プロジェクトIDは conductor-gcp を使用します。

  質問 3/5
  tfstateを管理する Cloud Storage バケット名 は何にしますか？ (Exclusive Choice)

  A) conductor-gcp-tfstate (プロジェクト名-tfstate)
  B) 一意な値を生成する (例: terraform-state- にランダムな文字列を付加)
  C) [Type your own answer]
  D) Auto-generate the rest of requirements and move to the next step

  ※ Aを推奨します。管理上わかりやすいためです。ただし、GCSのバケット名はグローバルで一意である必要があるため、既に使われている場合は変更が必要になります。

> C。conductor-gcp-tfstate-202601052301 としてください。

✦ 承知いたしました。バケット名は conductor-gcp-tfstate-202601052301 を使用します。

  質問 4/5
  VPCとサブネットのCIDR範囲について、具体的な希望はありますか？ (Select all that apply)

  A) 標準的な設定: VPC全体を 10.0.0.0/16、サブネットを 10.0.1.0/24 とする
  B) 最小限の設定: VPC全体を 192.168.0.0/16、サブネットを 192.168.1.0/24 とする
  C) [Type your own answer]
  D) Auto-generate the rest of requirements and move to the next step

  ※ Aを推奨します。一般的で分かりやすく、将来的な拡張にも対応しやすいためです。

> A

✦ 承知いたしました。VPCのネットワーク設計は標準的な 10.0.0.0/16 構成を採用します。

  質問 5/5
  Webサーバー（VMインスタンス）の初期設定について、何か追加で含めたい要素はありますか？ (Select all that apply)

  A) メタデータ (OS Login): enable-oslogin = TRUE を設定し、OS Login を有効化する（推奨）
  B) スタートアップスクリプト: 簡単な Apache や Nginx のインストールを行い、HTTP接続を確認できるようにする
  C) タグ: Firewall ルールを適用するためのネットワークタグ（例: http-server）を付与する
  D) [Type your own answer]
  E) Auto-generate the rest of requirements and move to the next step

  ※ A, B, C 全てを盛り込むことで、デプロイ直後に動作確認が可能な構成になります。

> AとC。

✦ 承知いたしました。OS Login の有効化（A）と、ネットワークタグ http-server の付与（C）を含めます。スタートアップスクリプトは今回含めません。

  これで初期トラックの提案に必要な情報が揃いました。

  提案する初期トラック
  ここまでのヒアリング内容に基づき、最初のトラックとして以下を提案します。

   1 To create the MVP of this project, I suggest the following track:
   2 - Setup Google Cloud infrastructure including VPC, Subnets, Firewall, Cloud Router, Cloud NAT, and a web server instance using Terraform.

  このトラックで進めてよろしいでしょうか？

  A) 承認: このトラックで計画を作成します。
  B) 変更: トラックの内容を修正します。

  AまたはBで回答してください。

> B。Webサーバの初期設定に、Apacheインストールを追加してください。

✦ 承知いたしました。WebサーバーへのApacheインストールを追加した内容で修正します。

  提案する初期トラック（修正版）

   1 To create the MVP of this project, I suggest the following track:
   2 - Setup Google Cloud infrastructure including VPC, Subnets, Firewall, Cloud Router, Cloud NAT, and a web server instance with Apache installed using Terraform.

  このトラックで進めてよろしいでしょうか？

  A) 承認: このトラックで計画を作成します。
  B) 変更: トラックの内容を修正します。

  AまたはBで回答してください。

> A

✦ 承認されました。初期トラックのアーティファクト（ディレクトリ、スペック、プラン）を生成します。

これで spec.md、plan.md ファイルが作成されます。
spec.md はインフラの仕様（設計情報）、plan.md には作業計画情報が記載されています。

$ cat spec.md 
# Specification: Initial GCP Infrastructure

## 1. Overview
GCP上に最小限のWebサーバー環境をTerraformで構築します。状態管理（tfstate）はGCSで行い、セキュアなネットワーク構成を採用します。

## 2. Components
### 2.1 Backend (init/ folder)
- **GCS Bucket:** `conductor-gcp-tfstate-202601052301` (Region: asia-northeast1)
- **Status:** Terraform applyを実行し、実際にバケットを作成します。

### 2.2 Infrastructure (main/ folder)
- **Project ID:** `conductor-gcp`
- **Region:** `asia-northeast1`
- **Network:**
  - VPC Network: `default-vpc-network` (Custom subnet mode)
  - Subnet: `web-server-subnet` (CIDR: 10.0.1.0/24)
  - Cloud Router & Cloud NAT: 外部への通信（Apacheインストール等）用
  - Firewall Rules:
    - `allow-http`: Port 80, Source 0.0.0.0/0
    - `allow-ssh-iap`: Port 22, Source 35.235.240.0/20 (IAP range)
- **Compute:**
  - VM Instance: `web-server-vm`
  - Machine Type: `e2-micro`
  - OS: `Debian 11`
  - Features: OS Login enabled, Apache installed via startup script
- **Status:** `terraform plan` までの実行とします。

## 3. Directory Structure
- `init/`: Backend設定用のTerraformコード
- `main/`: インフラ構成用のTerraformコード

$ cat plan.md 
# Plan: Initial GCP Infrastructure

## Phase 1: Preparation and Backend Setup (init/)
- [ ] Task: Create `init/` directory and Terraform code for GCS bucket.
- [ ] Task: Execute `terraform init` and `terraform apply` in `init/` directory.
- [ ] Task: Conductor - User Manual Verification 'Phase 1: Preparation and Backend Setup' (Protocol in workflow.md)

## Phase 2: Networking Infrastructure (main/)
- [ ] Task: Create `main/` directory and define VPC, Subnets.
- [ ] Task: Define Cloud Router and Cloud NAT for private subnet internet access.
- [ ] Task: Define Firewall rules for HTTP and IAP SSH.
- [ ] Task: Conductor - User Manual Verification 'Phase 2: Networking Infrastructure' (Protocol in workflow.md)

## Phase 3: Compute and Software (main/)
- [ ] Task: Define Web Server VM instance with OS Login and Startup Script (Apache).
- [ ] Task: Configure Backend settings to use the GCS bucket created in Phase 1.
- [ ] Task: Execute `terraform init` and `terraform plan` in `main/` directory.
- [ ] Task: Conductor - User Manual Verification 'Phase 3: Compute and Software' (Protocol in workflow.md)

$ cat setup_state.json 
{"last_successful_step": "3.3_initial_track_generated"}

これで/conductor:setupコマンドによる初期セットアップが完了となります。

/conductor:implementコマンドの実行

/conductor:setupコマンドで作成したコンテキストの情報をもとに実装を開始します。
/conductor:implementコマンドを実行します。

> /conductor:implement
〜〜省略〜〜
このトラックの実装を開始します。
✓  Edit conductor/tracks.md: ## [ ] Track: Setup Google Clo... => ## [~] Track: Setup Google

コマンドを実行すると、トラックの実装を開始します。と表示されました。
トラックは先ほど作成された spec.md、plan.md を包摂しているもので、これらに沿った実装が開始されます。

$ cat tracks.md
# Project Tracks

This file tracks all major tracks for the project. Each track has its own detailed plan in its respective folder.

---

## [ ] Track: Setup Google Cloud infrastructure including VPC, Subnets, Firewall, Cloud Router, Cloud NAT, and a web server instance with Apache installed using Terraform.
*Link: [./conductor/tracks/gcp_infra_20260101/](./conductor/tracks/gcp_infra_20260101/)*

[ ]に〜が入りました。これは実行中を意味します。

$ cat tracks.md
# Project Tracks

This file tracks all major tracks for the project. Each track has its own detailed plan in its respective folder.

---

## [~] Track: Setup Google Cloud infrastructure including VPC, Subnets, Firewall, Cloud Router, Cloud NAT, and a web server instance with Apache installed using Terraform.
*Link: [./conductor/tracks/gcp_infra_20260101/](./conductor/tracks/gcp_infra_20260101/)*

合わせて、plan.md の最初のタスクにも〜が入りました。
Phase 1は Terraform の tfstate 管理用 Cloud Storage のディレクトリと tf ファイル作成とコード生成、terraform init から apply まで実行、最後は人によるレビューです。
Phase 2は NW 系リソース、Phase 3は Web サーバーに関するタスクで、 terraform plan まで実行、最後は人によるレビューとなっています。

$ cat plan.md 
# Plan: Initial GCP Infrastructure

## Phase 1: Preparation and Backend Setup (init/)
- [~] Task: Create `init/` directory and Terraform code for GCS bucket.
- [ ] Task: Execute `terraform init` and `terraform apply` in `init/` directory.
- [ ] Task: Conductor - User Manual Verification 'Phase 1: Preparation and Backend Setup' (Protocol in workflow.md)

## Phase 2: Networking Infrastructure (main/)
- [ ] Task: Create `main/` directory and define VPC, Subnets.
- [ ] Task: Define Cloud Router and Cloud NAT for private subnet internet access.
- [ ] Task: Define Firewall rules for HTTP and IAP SSH.
- [ ] Task: Conductor - User Manual Verification 'Phase 2: Networking Infrastructure' (Protocol in workflow.md)

## Phase 3: Compute and Software (main/)
- [ ] Task: Define Web Server VM instance with OS Login and Startup Script (Apache).
- [ ] Task: Configure Backend settings to use the GCS bucket created in Phase 1.
- [ ] Task: Execute `terraform init` and `terraform plan` in `main/` directory.
- [ ] Task: Conductor - User Manual Verification 'Phase 3: Compute and Software' (Protocol in workflow.md)

各タスクが完了したら〜からxとなります。

$ cat plan.md 
# Plan: Initial GCP Infrastructure

## Phase 1: Preparation and Backend Setup (init/) [checkpoint: dbcb530]
- [x] Task: Create `init/` directory and Terraform code for GCS bucket. [e78f300]
- [x] Task: Execute `terraform init` and `terraform apply` in `init/` directory. [6664867]
- [x] Task: Conductor - User Manual Verification 'Phase 1: Preparation and Backend Setup' (Protocol in workflow.md) [9294d90]

## Phase 2: Networking Infrastructure (main/)
- [ ] Task: Create `main/` directory and define VPC, Subnets.
- [ ] Task: Define Cloud Router and Cloud NAT for private subnet internet access.
- [ ] Task: Define Firewall rules for HTTP and IAP SSH.
- [ ] Task: Conductor - User Manual Verification 'Phase 2: Networking Infrastructure' (Protocol in workflow.md)

## Phase 3: Compute and Software (main/)
- [ ] Task: Define Web Server VM instance with OS Login and Startup Script (Apache).
- [ ] Task: Configure Backend settings to use the GCS bucket created in Phase 1.
- [ ] Task: Execute `terraform init` and `terraform plan` in `main/` directory.
- [ ] Task: Conductor - User Manual Verification 'Phase 3: Compute and Software' (Protocol in workflow.md)

plan.md のタスクが全て完了したら、トラックの〜もxとなります。

$ cat plan.md 
# Plan: Initial GCP Infrastructure

## Phase 1: Preparation and Backend Setup (init/) [checkpoint: dbcb530]
- [x] Task: Create `init/` directory and Terraform code for GCS bucket. [e78f300]
- [x] Task: Execute `terraform init` and `terraform apply` in `init/` directory. [6664867]
- [x] Task: Conductor - User Manual Verification 'Phase 1: Preparation and Backend Setup' (Protocol in workflow.md) [9294d90]

## Phase 2: Networking Infrastructure (main/) [checkpoint: 8d6428f]
- [x] Task: Create `main/` directory and define VPC, Subnets. [8977d36]
- [x] Task: Define Cloud Router and Cloud NAT for private subnet internet access. [1c0fa06]
- [x] Task: Define Firewall rules for HTTP and IAP SSH. [2380fe6]
- [x] Task: Conductor - User Manual Verification 'Phase 2: Networking Infrastructure' (Protocol in workflow.md) [2c0abf0]

## Phase 3: Compute and Software (main/) [checkpoint: d8cecbe]
- [x] Task: Define Web Server VM instance with OS Login and Startup Script (Apache). [dcc8401]
- [x] Task: Configure Backend settings to use the GCS bucket created in Phase 1. [3c3d9f6]
- [x] Task: Execute `terraform init` and `terraform plan` in `main/` directory. [a2b14bd]
- [x] Task: Conductor - User Manual Verification 'Phase 3: Compute and Software' (Protocol in workflow.md) [5a087b7]

$ cat tracks.md 
# Project Tracks

This file tracks all major tracks for the project. Each track has its own detailed plan in its respective folder.

---

## [x] Track: Setup Google Cloud infrastructure including VPC, Subnets, Firewall, Cloud Router, Cloud NAT, and a web server instance with Apache installed using Terraform.
*Link: [./conductor/tracks/gcp_infra_20260101/](./conductor/tracks/gcp_infra_20260101/)*

これで/conductor:implement コマンドの実行が完了です。
プロジェクトのディレクトリツリーについて、空の状態から以下となっています。
これらのディレクトリ、ファイルは全て /conductor:setup、/conductor:implementコマンドの実行で作成されたものとなります。

conductor_gc構築/
│
├── conductor/                          # プロジェクト管理とドキュメント
│   ├── code_styleguides/               # コードスタイルガイドライン
│   │   └── general.md                  # 一般的なコーディング原則（可読性、一貫性、シンプルさ等）
│   │
│   ├── tracks/                         # プロジェクトトラック（主要作業単位）
│   │   └── gcp_infra_20260101/        # GCPインフラ構築トラック
│   │       ├── metadata.json           # トラックのメタデータ（ID、ステータス、説明等）
│   │       ├── plan.md                 # トラックの実装計画（フェーズとタスクの進捗）
│   │       └── spec.md                 # トラックの詳細仕様（コンポーネント、構成等）
│   │
│   ├── product.md                      # プロダクトの初期コンセプトとガイド（目標、機能、フェーズ）
│   ├── product-guidelines.md            # プロダクト開発ガイドライン（コードスタイル、命名規則、セキュリティ等）
│   ├── setup_state.json                # セットアップ状態の記録（最後に成功したステップ）
│   ├── tech-stack.md                   # 技術スタック定義（Terraform、GCP、リソース仕様等）
│   ├── tracks.md                       # プロジェクト全体のトラック一覧
│   └── workflow.md                     # 開発ワークフロー（タスク管理、テスト、コミット規約等）
│
├── init/                               # Terraformバックエンド設定（GCSバケット作成用）
│   ├── main.tf                         # GCSバケットリソース定義
│   ├── outputs.tf                      # バケット名の出力定義
│   ├── README.md                       # initディレクトリの説明と使用方法
│   ├── terraform.tf                    # Terraform設定とプロバイダー定義
│   ├── terraform.tfstate               # Terraform状態ファイル（実際のリソース状態）
│   ├── terraform.tfstate.backup        # Terraform状態ファイルのバックアップ
│   └── variables.tf                   # 変数定義（project_id、region、bucket_name）
│
├── main/                               # メインインフラ構成（VPC、VM、ネットワーク等）
│   ├── main.tf                         # メインリソース定義（VPC、サブネット、NAT、ファイアウォール、VM）
│   ├── outputs.tf                      # インフラリソースの出力定義（VPC、サブネット、VM IP等）
│   ├── startup.sh                      # VM起動時に実行されるスクリプト（Apacheインストール）
│   └── variables.tf                   # 変数定義（project_id、region、VPC名、サブネット設定等）
│
├── product_guidelines_proposed_changes.md  # product-guidelines.mdへの提案変更（ファイアウォールルールの更新）
└── tech_stack_proposed_changes.md         # tech-stack.mdへの提案変更（プロバイダーバージョンとファイアウォールの更新）

Conductor を使い、「Context → Spec & Plan → Implement」を実行してみました。
tfstate 用の Cloud Storage をデプロイし、Web サーバー1台のインフラコードを生成しましたが、これだけでもかなりのトークンを消費しました。
（Gemini CLI は個人開発者向けに無料枠を設けてくれていますが、そのトークン枠かつモデルに Gemini 3 を使用していた場合、このインフラ構成でもコンテキストの確立からプランの全タスクを完遂するのは厳しいかと思われます）README にもトークン消費に関する注意事項が記載されていますので、Conductor を使用する際はトークンコストを念頭に活用することをお勧めします。

＜日本語訳＞トークン消費に関する注意： Conductor のコンテキストドリブンアプローチでは、プロジェクトのコンテキスト、仕様、計画を読み取り、分析します。これにより、特に大規模なプロジェクトや、計画・実装フェーズが長引く場合、トークン消費量が増加する可能性があります。

4.終わりに

Conductor を動かしてみての感想ですが、メリットとしてはコンテキスト作成時の対話を通じ、強制的に設計を考えるフローになっているのが良いと感じました。（人間がいい加減に回答しては意味がないですが）
デメリットとしてはトークン消費が激しいことです。本格的な実務活用を考えた場合、トークンやコスト管理の運用設計を整えておく必要性を感じました。
これから Conductor を試す方は、小規模な環境での実際のトークン消費量を測定し、コスト効率を検証することをお勧めします。
私自身、Conductor を触り始めたところなので、段階的な活用からベストプラクティスを模索していきたいと考えています。