Conductor
Conductor
解決する課題
プロンプトからいきなり実装に飛びがちで、何を作るのか明確にしないまま開発が進む チームメンバー間でAIへの指示が統一されず、成果物の一貫性が失われる コンセプト: コンテキスト駆動開発
「作る前に計画し、コードを書く前に計画をレビューし、人間の開発者がハンドルを握り続ける」という思想である プロジェクトコンテキスト
conductor/ディレクトリ配下に以下のMarkdownファイルを生成・管理する product.md — プロダクトのゴール・ユーザー・要件
product-guidelines.md — プロダクト固有のガイドライン tech-stack.md — 技術スタック・採用技術
コードスタイルガイド
これらはGitで管理されるため、レビュー・変更追跡が可能である 一度設定すれば、チーム全体の共有基盤として機能する
Track（トラック）
/conductor:newTrackで新しいトラックを作成する
各トラックは2つの成果物を持つ
spec.md — 何を作るのか、なぜ作るのかの詳細要件
plan.md — フェーズ・タスク・サブタスクに分解された実行計画
開発ライフサイクル
コンテキスト作成 → 仕様策定 → 計画作成 → 実装 → 検証 の流れである /conductor:setup — 対話形式でプロジェクトの基盤コンテキストを構築する /conductor:newTrack — 新しい作業トラックを開始しspec.mdとplan.mdを生成する
/conductor:implement — plan.mdに従いエージェントがタスクを順次実行する /conductor:status — トラックとタスクの進捗を表示する
/conductor:revert — Git履歴を使ったロールバック（トラック・フェーズ・タスク単位） チーム開発への対応
どの開発者が実行しても、同一のガイドラインに従った一貫性のある成果物が得られる アーキテクチャ上の位置づけ
完全自動化のCI/CDパイプラインと手動開発の中間に位置する AIがルーチンの実装タスクを処理し、開発者が重要な判断ポイントで決定権を保持する 2026-02
Conductor Update: Introducing Automated Reviews
Automated Review機能の概要
レビューの4つの柱
新規コードをplan.mdとspec.mdに照合し、ロードマップの全フェーズが対応されているかを自動確認する 基本セキュリティレビュー
すべてのレビューのコアにセキュリティチェックが組み込まれている レポートの出力形式
発見事項はHigh / Medium / Lowの重大度で分類される 開発者に対して明確な改善指示を提供し、アクションに繋がる設計となっている
設計思想
「エージェント的開発」＝「監視なし開発」ではないという考え方である