第13章 AI補助開発で適切に使う

「終わりました」を分解する

AI補助開発では、

終わりました

という報告を受け取ることがあります。

しかし、「終わった」は一つの状態ではありません。

この本では、開発作業に関係する完了状態を次の六つに分けます。

implemented
tested
PASS
committed
pushed
deployed

これは、AI補助開発で完了報告を混同しないための、本書のVerification用の整理です。

implemented

implementedは、実装としての変更が存在する状態です。AIが「修正しました」と報告しただけではimplementedを確認したことにはなりません。実際のcodeやrepository changeなどを確認します。また、implemented が確認できても、tested、PASS、committed、pushed、deployedまで確認されたことにはなりません。

tested

testedは、testが実行された という状態です。重要なのは、tested != PASS という区別です。たとえば、testを実行した ↓ failureが出た なら、tested = YES、PASS = NO です。これは矛盾ではありません。

PASS

PASSは、定められた範囲について成功という結果が観測された状態です。第11章で見たように、

• 対象（target）
• バージョン（version）
• テスト対象の範囲（test set）
• 条件（conditions）
• 観測時点（observation point）

と一緒に解釈します。

したがって、PASS != 全要件を満たした です。

committed

committedは、変更がlocal Git repositoryのcommitとして記録された状態です。しかし、committed != pushed です。commitが存在するからといって、remote repositoryへ反映されたとは限りません。

pushed

pushedは、意図したcommitが意図したremote repositoryへ反映された状態です。ここではfreshnessが重要です。localの情報だけで、現在remoteにもあるはず と推測するのではなく、必要ならfresh remote stateを確認します。

deployed

deployedは、作成した変更が実際のexecution environmentへ反映された状態に関係します。AIが「deployしました」と書いただけでは確認できません。

必要な場合はruntimeやservice stateなどを観測します。

ただし、一度runtimeで動いたことは、将来ずっと正常であることを意味しません。

一度runtimeで動いた
        !=
将来ずっと正常

また、

deployed
        !=
すべての要件が満たされた

でもありません。

confirmedは第7の状態ではない

この本では、

confirmed

を第7の完了状態とは扱いません。

confirmedは、

implementedはconfirmedか
testedはconfirmedか
pushedはconfirmedか

のように、

ある状態がEvidenceによって確認されているか

を表す言葉として使います。

六つを一度にまとめない

たとえば、

実装してtestしてcommitしてpushしました。

というAI reportがあったとします。

これを一つの「完了」にまとめず、

implemented ?
tested ?
PASS ?
committed ?
pushed ?
deployed ?

と分けて確認します。

すべてを毎回確認しなければならない、という意味ではありません。

今回のscopeで必要な状態を確認します。

Verificationは「AIを疑う作業」ではない

Verificationという言葉から、「AIは信用できないから全部疑う」という意味に感じるかもしれません。しかし、この本ではそう考えません。

Verificationは、AIの説明、外部の状態、Humanの判断を混同しないための作業です。

AIが正しかった場合も、独立した確認を行えば、

正しかったことをEvidenceで確認できた

状態になります。

最初に意図・Scope・制約を決める

Verificationは最後に突然始めるものではありません。

作業を依頼するときに、

• 何をしてほしいのか
• どこまでしてよいのか
• してはいけないことは何か
• 何が見えれば成功なのか

をできるだけ明確にします。

たとえば、

Webを直して

だけでは、

file編集まで？
commitまで？
pushまで？
deployまで？

が分かりません。

Scopeを明示すれば、AIが勝手に次の段階へ進むのを防ぎやすくなります。

Authority Boundary

AIが技術的に実行できることと、実行してよいこと は同じではありません。

たとえばAIがdeployできるToolを持っていたとしても、deploy権限がHumanから与えられている とは限りません。

capability != authorization

これはToolやAgentを使うAI補助開発で重要になります。

Seven-step Verification Loop

この本では、AI補助開発の最小Verification Loopを七段階で整理します。

Step 1 — 依頼・意図・Scope・制約を決める

まず、

何をするのか
どこまでなのか
何をしてはいけないのか

を決めます。

そして、どの状態になれば今回の目的を満たすのかを考えます。

Step 2 — AI outputを受け取る

AIが、

• code
• configuration
• explanation
• investigation result
• completion report

などを生成します。

この時点では、

output received

であって、

task verified complete

ではありません。

Step 3 — 重要なClaimを見つける

すべての文章を同じ重さで検証する必要はありません。

結果を左右するClaimを抽出します。

たとえば、

「3 files modified」
「tests PASS」
「remote pushed」

などです。

Step 4 — Source of Truthと期待結果を決める

Claimごとに、

何を見れば確認できるか

を決めます。

たとえば、

file変更 → repository
test結果 → test artifact
remote反映 → remote repository
runtime → runtime observation

のようにします。

同時に、

何が見えれば成功なのか

も決めます。

Step 5 — Independent Evidenceを確認する

AI reportそのものだけではなく、必要なindependent Evidenceを確認します。

ここで重要なのは、

必要な範囲

を確認することです。

無関係なものまで全部調べる必要はありません。

Step 6 — Evidenceを分類する

確認結果を、

VERIFIED / OBSERVED
INFERENCE
UNKNOWN / UNDISCLOSED

として整理します。

task resultを判断する場合には、必要に応じて、

PASS
FAIL
UNKNOWN

も区別します。

Evidenceが足りなければ、無理にPASSやFAILへ変換せずUNKNOWNを残します。

Step 7 — Humanが判断する

最後にHumanが、

accept
correct
stop
escalate

などの次の判断を行います。

その判断を記録し、次の限定された反復が正当化される場合にのみ、Step 1へ戻ります。

ここで重要なのは、

technical PASS
        !=
次のactionが自動承認された

ということです。

testがPASSしたからといって、

deployしてよい

とは限りません。

次のauthority boundaryを越える場合には、別のHuman decisionが必要になることがあります。

この本では、Human approvalを確認結果を受け入れる判断、Human authorizationを特定の範囲や操作を実行してよいと決める判断として説明します。両者は関係しますが、AIのcapabilityから自動的に生まれるものではありません。

Loopは「PASSするまで回し続ける」ではない

Verification Loopという名前から、

PASSするまでAIが永遠に修正を繰り返す

ように見えるかもしれません。

しかし、この本のLoopはその意味ではありません。

FAILやUNKNOWNが出たときには、

• 原因を確認する
• 範囲を限定した修正を行う
• stopする
• Humanへ戻す
• escalateする

などの選択肢があります。

新しい試行を行う場合も、

なぜ次の一回を行うのか

が分かる範囲で行います。

過剰なVerificationも避ける

Verificationは多ければ多いほど良いわけではありません。

小さなdocs-only変更に、production deploymentと同じ確認を全部要求すれば、作業costが大きくなります。

一方で、runtimeやsecurity、public deploymentなど大きな影響を持つ作業では、より強い確認が必要になります。

つまり、

riskに応じたVerification

が必要です。

この本では、すべてのtaskへ最大レベルのprocessをかけることを推奨しません。

AIの能力とHumanの役割を分ける

AIは、

• 候補を作る
• codeを書く
• fileを読む
• Searchする
• Toolを実行する
• Evidenceを整理する

といった多くの支援ができます。

しかし、

何を許可するか
何をSource of Truthとするか
どこで止めるか
何を受け入れるか

はHuman authorityに関係します。

AI-assisted developmentは、

AIが全部自律実行する開発

だけを意味するものではありません。

AIのcapabilityとHuman authorityを組み合わせて使うことが重要です。

この章のまとめ

この本では、完了を次の六つに分けます。

implemented
tested
PASS
committed
pushed
deployed

そして、

confirmed

は、それぞれがEvidenceで確認されたかを見る概念です。

AI補助開発では、

1. Intent / Scope / Constraints
2. AI Output
3. Important Claims
4. Source of Truth / Expected Result
5. Independent Evidence
6. Evidence Classification
7. Human Decision

という七段階のVerification Loopを使います。

重要なのは、

• completion statesを一つにまとめない
• AI reportとexternal stateを分ける
• capabilityとauthorizationを分ける
• PASSの範囲を超えて一般化しない
• UNKNOWNを無理に埋めない
• technical resultとHuman authorizationを分ける
• LoopをPASSするまでの無制限再試行にしない
• task riskに応じたVerificationを行う

ことです。

次の第14章では、ここまで学んだ概念を使い、一つのAI補助開発taskを、依頼から生成・Tool Use・Evidence確認・Human decisionまで最初から最後まで追います。