第14章 一つのAI補助開発を最初から最後まで追う

ここまでの内容を、一つの作業でつなげる

ここまでの章では、AIについて一つずつ区別してきました。

たとえば、

AI != LLM
Model != AIサービス
Generation != Search
Context != Training Data
Tool request != Tool execution
AI report != external fact
PASS != UNKNOWNがゼロ
capability != authorization

といった区別です。

この最終章では、それらを一つのAI支援taskの中で使います。新しい理論や新しい開発手法を追加する章ではありません。第1章から第13章までで学んだ考え方を、一つの作業の最初から最後まで追って確認します。例は文書更新ですが、最後に開発作業との対応も確認します。

今回のtask

簡単な例を使います。ある組織に、既存の手順書があるとします。

HumanはAIに、次のように依頼します。

既存の手順書を確認し、指定した公開案内ページと照合して、
古くなった記述だけを更新してください。
元資料にない内容は追加しないでください。
文書の修正まで行い、最終公開は私が判断します。

ここでは、手順書を operations/申請手順.md、照合する公開案内を指定済みの情報源とします。小さなtaskですが、AI補助開発で重要な境界を一通り見ることができます。

場面1 — HumanがIntent・Scope・Constraintsを決める

最初に確認するのは、AIが何をできるかではありません。

今回、何をしてよいかです。

依頼を整理すると、次のとおりです。

Intent:
指定した公開案内と照合し、手順書の古い記述だけを更新する

Target:
operations/申請手順.md

Authorized:
手順書の読取、指定情報源の確認、文書の修正

Not Authorized:
元資料にない内容の追加
手順書の最終公開

ここで第13章の capability != authorization が関係します。

仮にAIが文書を公開できるToolを持っていたとしても、今回それを実行してよいことにはなりません。

場面2 — AIが現在の状態を確認する

AIが文書を更新するには、まず現在の手順書と、指定された公開案内の内容を確認する必要があります。公開案内を探す必要がある場合はSearchやRetrievalが関係し、指定済みの案内を読むだけなら文書読取が中心になります。Tool accessがある場合、いずれの情報取得も行われるかもしれません。ここで、第8章の区別を使います。modelが「文書を読みます」と生成した != 文書が実際に読まれた です。Tool requestとTool executionは別です。

実際の文書読取結果と情報取得結果を確認できれば、現在の operations/申請手順.md と指定情報源について観測可能な情報が得られます。

場面3 — Current Contextへ情報が入る

手順書と指定情報源の内容がAI systemへ渡された場合、その情報は現在のtaskで利用できるContextの一部になる場合があります。ここでも第7章の区別があります。現在の文書内容がContextへ入った != Training Dataになった です。また、Context != saved Memory でもあります。

今回のtaskで必要なのは、現在の文書と指定情報源を使えることです。それ以上の保存やTrainingの内部処理についてEvidenceがなければ推測しません。

場面4 — AIが変更案を生成する

AIは現在の文書、指定情報源、Humanのinstructionをもとに、変更案を生成します。この生成では、第4章で扱ったmodel generationが関係します。

ただし、このtaskで、

• どのhidden promptが使われたか
• backendで何回modelが呼ばれたか
• どの内部routingが使われたか

まで知る必要はありません。

確認できない部分は UNKNOWN / UNDISCLOSED のままです。

今回確認したいのは、指定情報源で古くなっていると分かる記述だけが、対象文書で適切に更新されるか です。

場面5 — AIが文書の編集を要求する

AIがTool Useを通じて文書変更を行うsystemだとします。

概念的には、次のように関係づけられます。

Human instruction
      ↓
AI output / tool request
      ↓
document-edit tool
      ↓
document state

AIが修正内容を決めたり、編集Toolへの要求を生成したりしただけでは、外部の文書はまだ変わっていません。編集Toolへの要求が実際に実行され、ファイルや文書の内容が書き換えられて初めて、外部の状態が変化します。

実際の仕組みでは、文書編集Tool、file write operation、patch operationなどがこの段階を担うことがあります。開発作業では、patchの適用やshell / PowerShell commandの実行が当たる場合もあります。ただし、すべてのAI systemがcommandやshellを使うわけではありません。

tool request != actual document modification です。AIが「変更しました」と報告しても、その文章だけでは文書が変更されたことを確認できません。

場面6 — External stateが変わる

文書の編集が実際に成功した場合、operations/申請手順.md という外部状態が変化します。

ここで初めて、生成された文章だけではなく、document file state という外部の対象があります。

今回のimplemented Claimを確認したいなら、Source of Truth候補は実際の文書ファイルです。

場面7 — AIが完了報告を生成する

AIが次のように報告したとします。

operations/申請手順.md の古い記述を更新しました。
作業は完了しました。

この報告には複数のClaimがあります。

Claim 1:
operations/申請手順.md が変更された

Claim 2:
operations/申請手順.md の古い記述を更新した

Claim 3:
今回の作業が完了した

重要なのは、AI reportとexternal factは同じではないということです。

AI report
        !=
external fact

報告文は確認の出発点ですが、それ自体が作業完了の独立Evidenceではありません。

場面8 — Source of Truthを決める

今回確認したいことは、手順書が指定情報源に照らして、要求どおり更新されたかということです。

手順書が指定情報源に照らして、要求どおり更新されたか

したがって、文書の変更を確認する先として、実際の文書ファイルを使います。記述が現在の公開案内と合っているかを確認する先は、指定された情報源です。

これは、

「何が現在の文書に書かれているか」

という問いに合ったSourceです。

もし問いが「最終公開されたか」なら、公開先の状態を確認する必要があります。しかし今回は最終公開自体がUnauthorizedです。

問いによってSource of Truthが変わる、という第12章の考え方です。

場面9 — Independent Evidenceを確認する

実際の文書を確認したところ、指定情報源と異なっていた受付方法の記述が更新されており、その他の内容には意図しない変更が見当たらなかったとします。

この観測は、少なくとも今回確認した範囲で、要求された範囲の記述だけが更新されていることを支えるEvidenceになります。

AIが「更新しました」と言ったからではなく、外部状態と指定情報源を別に確認したからです。

場面10 — Claimを分類する

今回の確認結果を整理します。

Claim 1 — 文書が変更された

実際の文書ファイルで変更を確認できたなら、

VERIFIED / OBSERVED

と扱えます。

Claim 2 — 古い記述を更新した

指定情報源と更新後の文書を照合して一致を確認できたなら、古い記述が更新されたことを確認できたものとして扱えます。

VERIFIED / OBSERVED

Claim 3 — 今回の作業が完了した

AI reportの「完了」は、今回の作業が完了したというClaimです。この語だけから、最終公開が含まれるとも、含まれないとも決めることはできません。

最終公開の状態は別に確認する

最終公開の状態を知りたい場合は、公開先の外部状態を確認します。そこで観測した公開状態は、元のAI reportから抽出したClaimではなく、verificationの結果です。今回、Humanが最終公開を保留しているため、authority boundaryを守ったかどうかも確認対象になり得ます。

場面11 — Completion Stateを分ける

第13章の六つのcompletion stateで見ると、今回期待しているのは基本的に、

implemented

までです。

つまり、今回のcompletion stateは次のとおりです。

implemented: YES / confirmed
tested:     NOT REQUIRED for this bounded document update
PASS:       NOT USED as a separate test result
committed:  NOT PART OF THIS TASK
pushed:     NOT PART OF THIS TASK
deployed:   NOT PART OF THIS TASK

ここで重要なのは、

implemented
        ↓
自動的に最終公開される
        ↓
自動的に作業全体が承認される

と進まないことです。

「次までやっておきました」は成功ではない

もしAIが、

手順書を更新し、
元資料にない説明も加えて公開しておきました。

と報告したらどうでしょうか。

技術的に変更内容が正しかったとしても、

内容の追加
最終公開

は今回のauthorization外です。

したがって、要求内容が正しい ことと、作業全体が適切だった ことは別です。

これはAI補助開発で非常に重要です。correct resultとauthorized processは同じではありません。

correct result
        !=
authorized process

Scope expansion

AIが、

手順書だけでは分かりにくいので
関連文書も統一しておきました

と判断する場合も考えてみます。

Humanは、指定情報源と照合して手順書の古い記述だけを更新するよう依頼しています。

AIが「より良くなる」と判断したとしても、

手順書の限定更新
        ↓
関連文書全体の再編集

へ勝手にScopeを広げることは、今回のauthorizationには含まれていません。

第13章のIntent・Scope・Constraintsがここで効きます。

「もっと良いもの」を勝手に目的にしない

AI補助開発では、

読みやすい方がよい
統一されていた方がよい
最新化した方がよい

といった考え自体が合理的に見える場合があります。

しかし、それらがHumanから依頼されたgoalとは限りません。

Human Goal と、AIが追加した方がよいと判断したGoal を区別する必要があります。

AIは改善案を提案できます。

しかし、提案することと、実行権限を持つことは別です。

UNKNOWNが残る例

すべてのtaskで、すべてを確認できるとは限りません。

たとえばAI service内部について、

この文書内容がbackendで何秒保持されたか

を知りたいとしても、公開情報や観測方法がなければ、

UNKNOWN / UNDISCLOSED

かもしれません。

しかし、そのUNKNOWNがあるからといって、

手順書の更新が失敗

という意味ではありません。

今回のtask completionに必要な問いと、そうでない問いを分けることが重要です。

Verificationの強さをtaskに合わせる

この例は小さな文書更新です。

そのため、

• production runtime validation
• security penetration test
• deployment verification
• infrastructure health check

まで行う必要はありません。

今回必要なのは、主に、指定文書が指定情報源に照らして指定scope内で更新されたかということです。

指定文書が
指定情報源に照らして
指定scope内で
更新されたか

これは第13章で扱った、

riskに応じたVerification

という考え方です。

Verificationは多ければよいのではなく、taskに必要なEvidenceを確認します。

一般業務と開発作業をつなげる

この例で扱った文書更新、情報確認、Toolによる編集という区別は、開発作業にも使えます。開発では、文書編集の代わりにcode変更、Toolによる編集の代わりにpatchの適用やcommand実行、確認の代わりにtestが関係することがあります。

一般業務
文書更新 / 情報確認 / Toolによる編集

開発
code変更 / command実行 / test / commit / push / deploy

開発taskでは、code変更がimplementedであっても、testsが実行されたか、定めたtest setがPASSになったかは別に確認します。committed、pushed、deployed も別の状態であり、別のauthorizationが必要になる場合があります。すべてのtaskに六つの状態が必要なのではなく、taskに必要な状態を分けて確認します。taskが変わっても、生成・実行・外部状態・確認・権限を分ける基本的な考え方は変わりません。

Toolを持つAIでは影響範囲も考える

AIがfile readだけできる場合と、

write
delete
execute
deploy

までできる場合では、失敗したときの影響が違います。

Tool capabilityが広がるほど、

何を許可するか

というHuman側の判断が重要になります。

第10章で見たように、read-only と state-changing も分けます。

今回の文書編集はstate-changing actionです。

だからこそ、変更対象を手順書の古い記述だけに限定するScopeが意味を持ちます。

最後にHumanが判断する

Independent Evidenceを確認した結果、

• 指定文書だけが変更されている
• 指定情報源と合う内容へ更新されている
• 公開先の状態を確認した結果、最終公開は行われていない

ことが確認できたとします。

最後の項目は、元のAI reportから抽出したClaimではなく、公開先を確認して得たverificationの結果です。

そのうえでHumanは、

accept

を選べます。

もし余計な変更があれば、

correct

かもしれません。

重大なScope逸脱があれば、

stop

を選ぶこともあります。

自分のauthorityを超える判断が必要なら、

escalate

する場合もあります。

AIが最終採否を自分で決めるのではありません。

Seven-step Verification Loopへ戻す

今回の例を、第13章の七段階へ戻してみます。

1. Intent / Scope / Constraints

指定情報源と照合して、手順書の古い記述だけを更新
文書の修正まで
最終公開はHumanが判断

2. AI Output

AIが変更案やtool request、completion reportを生成します。

3. Important Claims

文書を更新した
古い記述を更新した
今回の作業が完了した

というClaimを取り出します。

4. Source of Truth / Expected Result

Source:
document file state
指定された公開案内
最終公開の状態を確認する場合は公開先

Expected:
operations/申請手順.md が指定情報源と合っている
元資料にない内容や余計なscope expansionがない

とします。

5. Independent Evidence

実際の文書の状態と指定情報源を確認します。最終公開の状態を確認する場合は公開先も確認し、その観測結果をAI reportから抽出したClaimとは分けます。

6. Evidence Classification

確認できたものを、

VERIFIED / OBSERVED
INFERENCE
UNKNOWN / UNDISCLOSED

として整理します。

必要なtask resultについては、

PASS
FAIL
UNKNOWN

も分けます。

7. Human Decision

Humanが、

accept
correct
stop
escalate

を決めます。

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

AI補助開発の中心にあるもの

この本を通して、AIの能力について多くのことを見てきました。

AIは、

• 文章を生成できる
• codeを生成できる
• Searchできるsystemに組み込まれる
• Retrievalを利用できる
• Toolを利用できる
• Agentとして複数stepを進めるsystemに組み込まれる

場合があります。

しかし、AI補助開発で重要なのは、能力の数だけではありません。

何を依頼したか
何をAIが生成したか
何を実際に実行したか
何をEvidenceで確認したか
何がまだUNKNOWNか
どこまでHumanが許可したか

を分けられることです。

AIを適切に使うとは

本書の目標は、

AIを信用する

ことでも、

AIを信用しない

ことでもありません。

AIを適切に使うとは、

AIの能力を利用しながら、生成されたoutput・外部execution・Evidence・Source of Truth・Human authorityを混同しないこと

だと考えます。

AIが正しいときもあります。

AIが間違うときもあります。

確認できないこともあります。

重要なのは、その違いを、

もっともらしさ

だけで決めないことです。

本書の最後の地図

最後に、本書全体を一つの流れにまとめます。

この図は、AI補助開発を考えるための本書の概念地図です。

この章のまとめ

一つのAI補助開発taskを追うと、これまでの区別がすべてつながります。

• HumanがIntent・Scope・Constraintsを決める
• AIのcapabilityとauthorizationを分ける
• Model GenerationとTool executionを分ける
• ContextとTraining Dataを分ける
• AI reportとexternal factを分ける
• ClaimごとにSource of Truthを決める
• Independent Evidenceで確認する
• VERIFIED / OBSERVED・INFERENCE・UNKNOWNを分ける
• PASSの範囲を限定して読む
• implemented・tested・PASS・committed・pushed・deployedを分ける
• technical resultとHuman authorizationを分ける
• task riskに応じたVerificationを行う
• 最後はHumanがaccept・correct・stop・escalateを判断する

AIが高度になっても、

何が生成されたのか
何が実行されたのか
何が確認されたのか
誰が許可したのか

を分ける必要はなくなりません。

むしろAIの能力が広がるほど、この区別は重要になります。

これが、本書で学ぶ AI Fundamentals for AI-Assisted Development の中心です。