AIにどこまで自律させるか — Spec・Plan・Human Reviewで組む開発ハーネス

この記事で扱う問題#

Claude Code のような AI コーディングツールは、指示すれば数分で動くコードを書きます。ただ、任せ方を間違えると次のことが起きます。

• 仕様があいまいなまま実装が進み、あとで大きく作り直す
• 既存の設計方針と違う書き方が、少しずつ混ざっていく
• テストは通るが、要件を満たしていない変更がマージされる

AI の出力の質は、プロンプトの書き方だけでは決まりません。どこまで AI に任せ、どこで人が判断するかという流れの設計で決まります。

判断#

私は個人開発で、次の流れで AI を使っています（チームの標準として導入した実績は、まだありません）。

Spec（何を作るか・何を作らないか）
  ↓
Plan（どのファイルをどう変えるか。AI が作る）
  ↓
Human Review（計画の段階で方針を確かめる）
  ↓
AI Implementation
  ↓
lint / 静的解析 / テスト（機械で確かめられることは機械で）
  ↓
Human Review（要件と設計の判断を人が確かめる）

このサイト自体も、この流れで作っています。変更は必ずブランチと Pull Request を通し、CI でコーディング規約・静的解析（Psalm・PHPStan・PHPMD）・テストを実行します。さらに AI のコードレビューを受け、指摘を確認してから人がマージを判断します。

なぜそう判断したか#

一番重要なのは、AI に続けさせてよい条件と、人に戻す条件をはっきり決めることです。

AI に自律して進めさせてよいのは、次のような変更です。

• 影響範囲が限られ、テストで正しさを確かめられる
• 既存のパターンをなぞるだけで、設計判断を含まない
• 失敗しても簡単に戻せる

逆に、次のような変更は必ず人に戻します。

• 仕様があいまいで、解釈の選択が必要
• アーキテクチャや責務の配置に関わる判断
• データの移行、公開 API の変更、セキュリティなど、失敗したときに戻しにくい

計画（Plan）の段階で一度人が確かめるのは、実装後に方針のずれに気づくより、はるかに安く済むからです。そして、機械で確かめられること（型、規約、テスト）は機械に任せ、人のレビューは「要件を満たしているか」「この設計でよいか」に集中させます。

どこから設計過剰になるか#

• 1行の修正や typo の修正に、Spec と Plan を書く必要はありません。変更の大きさとリスクで、流れを省略します
• テストや静的解析が整っていないプロジェクトでは、AI の自律範囲を広げる前に、まず機械で確かめる仕組みを整えるほうが先です。確かめる手段がないまま任せる範囲を広げると、レビューの負担が人に集中します
• AI のコードレビューは見落としを減らしますが、指摘がすべて妥当とは限りません。採用するかどうかを判断するのは人です

まとめ#

• AI 活用の質は、プロンプトより「どこまで自律させるか」の設計で決まる
• Spec → Plan → 人のレビュー → AI の実装 → 機械の検証 → 人のレビュー、という流れで進める
• 低リスクで検証できる変更は AI に続けさせ、あいまい・設計判断・戻しにくい変更は人に戻す