#3｜AIが自走し、人間は管制する — Pilot-Tower開発の設計思想

はじめに

こんにちは、株式会社ACES でテックリードをしている福澤 (@fuku_tech) です！

本シリーズでは、AI駆動開発における人間とAIの役割分担を、自動運転になぞらえた4つのPhaseで整理しています（詳細は下図を参照）。前回の記事では、人間が運転席に座りつつAIに作業実行を任せるPhase 2として、開発プロセスをサブプロセス単位に分解し、スラッシュコマンドとしてAIに割り当てる実践を解説しました。コマンド単位ではAIが精度よく動くようになった一方で、コマンド間をつなぐ「次に何をすべきか」の判断は常に人間が担っている、という構造的な限界が見えてきました。

今回は、この「組み合わせて回す」役割自体をAIに委ねるPhase 3の設計思想について解説します。私たちが「Pilot-Tower開発」と名付けたこのアプローチが、どういう問いから出発し、どういう思想に至り、どういう仕組みに結実したのか。設計の思想と仕組みに焦点を当てます。

Phase 3とは何か: 「管制塔モデル」への転換

Phase 2の限界の再確認

Phase 2では、人間が運転席に座りながら「コマンド実行→出力レビュー→次のコマンド選択→実行」のループを回していました。各コマンドの実行精度はAIのおかげで十分に上がりましたが、このループ自体は人間が回している以上、AIの稼働時間は人間の稼働時間に縛られます。会議中も、夜間も、AIは人間の次の指示を待っている状態です。

Phase 3の定義

Phase 3は、運転席自体をAIに譲るフェーズです。AIが自ら計画を読み、実装し、検証し、次のステップを判断して進む。人間は管制塔として、AIが「自分では判断できない」と停止したポイントにだけ介在します。

観点	Phase 2	Phase 3
運転席	人間	AI
人間の役割	コマンド選択→実行→レビュー→次のコマンド選択...	要所での判断のみ

Pilot-Tower開発というメタファー

この役割分担を、私たちは航空管制に見立てて「Pilot-Tower開発」（通称P&T開発）と呼んでいます。AIがPilot（操縦）、人間がTower（管制塔）です。

命名には意図があります。後述するHarness EngineeringやSDD（仕様駆動開発）といった考え方が最近注目されていますが、それらはコードベースやインフラの環境設計、あるいは仕様書を起点としたワークフローに主眼を置いています。私たちがPilot-Tower開発と名付けたのは、開発プロセスそのものの設計に焦点を当てているためで、既存の概念とはレイヤーが異なると考えたからです。この違いについては後ほど詳しく触れます。

核心問題: AIに自走させつつ逸脱を防ぐ

Phase 3の設計で向き合うべきトレードオフは明快です。AIに自走させるほど人間の手は空くが、逸脱のリスクも高まる。逸脱を防ごうとチェックポイントを増やせば、結局Phase 2に逆戻りする。このトレードオフをどう解くかが、今回のテーマです。

思想: 上流と下流の境界を溶かす

プロセスの構造そのものが問題だった

#2｜スラッシュコマンドで回す開発 — プロセスを分解してAIに割り当てるでの結論は「プロセスを細分化してAIに渡せば精度は上がる」でした。これは正しいのですが、個々のコマンドの精度が上がっても、人間が毎回つなぎ直すループが残っている限り、スループットは人間の処理速度に律速されます。解くべきは個々の精度ではなく、プロセスの構造そのものではないかと考えました。

なぜ「仕様を先に固める」だけでは足りないのか

従来のソフトウェア開発は、要件定義→設計→実装という直列プロセスが基本です。上流が詰まると全体が止まる。最近は「vibe codingではなく、まず仕様を書こう」という方向性が注目されていますし、その方向性自体は正しいと考えています。

ただ、私たちがPhase 3で解きたかった問題は、「AIの出力精度を上げる」ことのさらに先にありました。出力精度の向上はもちろん重要ですが、私たちの問題意識は、人間の関与を最小化し、AIの自律稼働時間を最大化することにあります。仕様の精度がいくら上がっても、人間がゲートとして介在し続ける構造のままでは、AIの稼働時間は人間の稼働時間に縛られたままです。この構造自体を変えたいと考えました。

【直列プロセス】
要件定義 → 設計 → 実装 // 上流が詰まると全体が止まる

要件定義・設計・実装の境界を溶かす

この問題意識から至った思想の転換は、要件定義・設計・実装の境界を溶かすというものです。

「どういう要求を満たし、どんなユーザー体験を提供したいか」（What/Why）さえ明確であれば、How（どう実装するか）はAIが探索的に実装しながら、影響範囲やリスクを洗い出せます。要件定義の完了を待ってから設計・実装に入るのではなく、探索ループの中で要件の理解・設計の具体化・仮実装による検証が相互にフィードバックし合いながら深まっていくイメージです。仕様は完成品ではなく、探索を通じて育てていく指針として扱います。

【同時に回すプロセス】
      What/Why を定める
            │
      ┌─────┼─────┐
      ↓     ↓     ↓
  要件の   設計の   仮実装で
  深掘り   具体化   検証
      └─────┼─────┘
            ↓
     plan.md に知見を蓄積
            │
        本実装へ

ただし、探索と本実装は明確に分けています。探索はあくまで捨てる前提の仮実装（plan-spike）であり、コードは捨てても、得られた知見は plan.md に蓄積されます。

3つのモードで不確実性を段階的に減らす

具体的には、以下の3つのモードを使い分けて不確実性を段階的に減らしていきます。

モード	目的	成果物
`plan-refine`	対話で計画を詳細化	`plan.md` の更新
`plan-spike`	仮実装で技術検証	知見（コードは捨てる）
`plan-execute`	本実装	プロダクションコード + PR

plan-refineは、AIと対話しながら plan.md の不明瞭な点や矛盾を潰していくモードです。plan-spikeは、実際にコードを書いて技術的な不確実性を検証するモードで、コードは捨てる前提ですが学びは plan.md に残します。この2つのモードで十分に不確実性が減ったら、plan-executeで本実装に移行します。

移行の目安として、セッションを切り替えて別のLLMに「この plan.md だけで迷いなく実装できるか」をレビューさせるという方法を使っています。実装文脈を持たない別のLLMが問題なく理解できるなら、plan.md は本実装に十分な精度に達していると判断できます。

仮実装が効いた実例

直近で取り組んでいる認可基盤の大幅アップデートで、plan-spikeの効果を実感しました。このタスクでは、Cerbosという新規ライブラリの導入、既存コードベースの整理、データ移行の安全性確保、機能的な後方互換性の維持と、不確実性とリスクが多く重なっていました。

初手でplan-spikeを実施したことで、いくつかの重要な知見が得られました。実装イメージが具体的になったこと、影響範囲の洗い出しができたこと、そして何より、本格的な指示を与えていない状態でAIがどういう設計・実装をしてしまうかを事前に把握できたことが大きかったです。この「AIの癖」を事前に知れることで、plan.md の制約やDoDをより的確に書けるようになります。

一方で、plan-refineの対話だけで十分にイメージが掴める場合もあります。実装者がAIからの質問に一問一答で回答していくだけで計画が固まるようなケースでは、仮実装を挟む必要はありません。見えていないものが多いタスクほど、plan-spikeの価値は高くなります。

各タスクにおけるSSoTとしての `plan.md`

この思想が結実したのが、各タスクにおけるSSoT（信頼できる唯一の情報源）として機能する plan.md です。ここで重要なのは、plan.md は人間が読み書きする仕様書ではないという点です。AIが読み、AIが更新し、AIがそれに基づいて自律的に判断するためのドキュメントです。人間はGoalやConstraintsの大枠を与えますが、探索ループの中で plan.md が詳細化されていく過程を細かくレビューするわけではありません。大事なポイントだけ確認し、問題なければ実装を進めてもらうという運用です。

plan.md には、Goal（何を達成するか）、Constraints（やらないこと・守るべきルール）、DoD（完了条件）を記載します。最初は「種」の状態で構いません。探索ループを通じて育てていけばよいからです。

## Goal
<!-- このタスクで実現すること。1-2行で簡潔に -->

## Constraints
<!-- やらないこと・守るべきルール -->

## Definition of Done
<!-- 完了とみなす条件。検証可能な形で -->

plan.md は静的な仕様書ではなく、開発が進むにつれて常に更新される「生きたドキュメント」です。AIは plan.md を読むことで「何をすべきか」「何をしてはならないか」「いつ完了とみなすか」を自律的に判断でき、人間に確認する回数を極限まで減らせます。

つまり、人間がやることの起点は plan.md の種を与えることであり、Goal（何を達成するか）、Constraints（やらないこと）、DoD（完了条件）を定めることです。最初からすべてを詰める必要はなく、ラフな種から始めて探索ループで育てていけるのがこの設計の強みです。ただし、AIに自走させるには「次に何をすべきかをどう判断するか」「判断に迷ったらどうするか」「踏み込んではいけない領域をどう守るか」という仕組みが要ります。次に紹介する3つの仕掛けが、これらを解決します。

自走と統制を両立する3つの仕掛け

思想だけでは仕組みにならないので、Pilot-Tower開発では3つの仕掛けで自走と統制を両立させています。

仕掛け1: ループ構造

Phase 2では人間がスラッシュコマンドの連鎖を手動で回していましたが、Phase 3ではこのループ自体をAIが回します。

plan.md → 実装/検証 → worklog.md → DR抽出 → plan.md更新
   ↑                                        ↓
   └────────────────────────────────────────┘

AIは plan.md を読んで実装を進め、作業ログを worklog.md に記録し、判断が必要な事項をDR（Decision Required、後述）として抽出し、plan.md を更新する。このサイクルを人間の介入なしに回し続けます。

仕掛け2: Decision Required（DR）

AIが自走中に「自分では判断できない」と認識した場合、DRを発行して停止します。DRには設計原則があります。

まず、DRはブロッカーに限定します。進行を止める判断のみをDR化し、些末な確認事項でAIを止めません。次に、A/B形式で選択肢と推奨案を提示します。人間は背景を読み込んで判断を組み立てる必要はなく、選択肢の中から選ぶだけです。

### DR-001: 移行の進め方（一括 vs 段階的）

- Priority: P1
- Context: 約145個の関連クラスが存在し、約53個が未移行...
- Options:
  - A: **一括移行** - 未移行の関連クラスを一度に移行
  - B: **段階的移行** - ドメインごとに分けて順次移行
- Recommendation: B（段階的移行）
- Reason: PRが巨大になりレビューが困難、問題発生時の影響範囲を限定できる...
- Decision: <!-- ここに A or B を記入するだけ -->

実際の運用では、1つのタスクで発生するDRは多くても3〜5個程度です。しかもDRへの回答はdecision-logとして蓄積され、AIが過去の判断パターンを参照できるようになるため、似たような判断は今後DRに上がらなくなっていく方向に進みつつあります。

運用イメージとしては、AIが夜間や会議中に自走し、判断が必要な箇所でDRを出して停止する。人間は翌朝まとめてDRに回答すると、AIが再走し始めます。いわば「AIとの朝会」のようなリズムです。

仕掛け3: ガードレール

3つ目の仕掛けは、AIに任せない領域を事前に定義するガードレールです。認証・認可、課金・決済、セキュリティ・プライバシー、コアビジネスロジック、不可逆操作、外部公開APIの破壊的変更といった領域は、AIが触れた場合に自動的にDRが発生し、必ず人間がレビューする設計になっています。

ポイントは「何を任せるか」ではなく「何を任せないか」を定めていることです。任せない領域さえ明確にすれば、それ以外はすべてAIに委ねられます。#2では、人間が必ずレビューする領域の線引きとしてガードレールに触れましたが、Phase 3ではこれをAIの自走中に自動的にDRを発生させる仕組みとして機能させています。なお、ガードレールの具体的な内容はプロダクトの特性によって変わります。私たちのプロダクトでは会議データという機密性の高い情報を扱うため上記の領域を定めていますが、別のプロダクトであれば異なるラインになるはずです。

3つの仕掛けが「自己改善するシステム」を成す

これら3つの仕掛けは、独立した機能ではなく、互いに連動して使うほど賢くなるシステムを成しています。

DRのログ蓄積によってAIの自律判断範囲が拡大し、人間の介入がさらに減っていきます。worklogの蓄積によってよく詰まるパターンが可視化され、ガイドラインやスキルの追加・改善につなげられます。この自己改善のループが回り続ける限り、Phase 3は時間とともに成熟していく設計になっています。実際、まだ数ヶ月の運用ですが、開発がどんどん安定して回るようになってきている実感があります。

加えて、この仕組みは「失敗を許容する」設計でもあります。緊急度の高いタスクでは人間の介在を増やしてしっかりレビューしますが、時間的な余裕があるタスクは、あえてAIに自走させて失敗パターンを蓄積する「成長タスク」として捉えることもあります。上手くいかなかったケースはフィードバックとして残し、次のタスクに活かす。このサイクルを回すことで、システム全体が育っていきます。

業界の潮流と私たちのアプローチ

近いアプローチとの関係

最近、AIを前提とした開発の進め方にいくつかの方向性が出てきています。ここでは、私たちのPilot-Tower開発と関係の深い2つのアプローチを取り上げ、それぞれの位置づけを整理します。

2026年2月、OpenAIが「Harness Engineering」*1というアプローチを発表しました。3人のエンジニアがCodexエージェントを使い、人間が一切コードを手書きしないという制約のもとで約100万行のプロダクトを構築した実践報告です。リンター、構造テスト、CI、Observabilityといった環境を整えることで、AIが自律的に動ける「ハーネス（馬具、制御装置）」を構築するという考え方です。

また、SDD（仕様駆動開発）*2は、KiroやGitHub Spec Kit等のツールとともに広まりつつあるアプローチで、仕様書の品質を上げることでAIの出力精度を向上させるワークフローを体系化しています。

私たちのPilot-Tower開発を含め、これらのアプローチは「AIに自律的に動いてもらうために何を整えるか」という同じ問いに対する異なるアプローチだと考えています。

比較軸	Harness Engineering	SDD（仕様駆動開発）	Pilot-Tower開発
設計のゴール	AIが正しく動ける環境を作る	AIの出力精度を仕様の品質で上げる	人間の関与を最小化しAIの自律稼働時間を最大化する
主な焦点	コードベース・インフラの環境設計	仕様書を起点としたワークフロー	開発プロセスの設計
仕様の位置づけ	仕様書は明示的には扱わない（環境・ツールで制御）	人間が策定しAIに渡す起点ドキュメント	AIが自律的に更新し続ける「生きたドキュメント」（`plan.md`）
整えるもの	リンター、構造テスト、CI、Observability等	要件定義書、設計書、タスクリスト等	`plan.md`、DR、 `worklog.md`、ガードレール等
人間の介在	環境設計とPRレビュー	仕様策定と承認ゲート	DRへの判断回答

これらは対立するアプローチではなく、レイヤーが異なる補完関係にあると考えています。AIが自律的に動ける環境を整えること（Harness Engineering）、AIに渡す仕様を体系化すること（SDD）、AIが自律的に動くプロセスを設計すること（Pilot-Tower開発）は、それぞれ異なるレイヤーで同じ方向を向いています。私たちはプロセス設計のレイヤーからこの問いにアプローチしています。

なお、これらのアプローチを正確に比較するには、それぞれを本格的に実践してみる必要があります。上の整理はあくまで公開情報に基づく私の解釈であり、実際の運用上の差異はもっと複雑だろうと思います。