第12章 Source of Truthは誰が・どう決めるのか

Source of Truthとは何か

第11章では、AIがそう言った ことと、外部の事実として確認できた ことを分けました。

では、外部の事実を確認するとき、何を見ればよいのでしょうか。

そのときに重要になるのがSource of Truthです。

この本ではSource of Truthを、

ある問いについて、確認先として扱う情報源

として考えます。

一つの万能なSource of Truthはない

Source of Truthという言葉から、「すべてについて絶対に正しい一つのdatabase」のようなものを想像するかもしれません。しかし、この本ではそのようには扱いません。何を知りたいのかによって、適切な確認先は変わります。

何がcommitされたか
何を作る予定だったか
testしたか
今動いているか
設定は何か
過去に何が起きたか

では、それぞれ別のsourceが必要になる場合があります。

Gitで確認できること

「何がcommitされたか」を知りたいなら、Git historyやdiffが確認材料になります。たとえば、AIが「このfileを変更してcommitしました」と報告した場合、Git historyやcommit内容を確認すれば、そのcommitが存在するか、何が変更されているか をAIの説明とは別に確認できます。

ただし、Gitに記録されている = 内容が絶対に正しい という意味ではありません。

GitはGitで確認できる問いに対するsourceです。

Specification

「何を作るつもりだったか」「どの要件を満たすべきだったか」を確認するときには、specificationやrequirements documentが重要になります。

たとえば、codeが動いていたとしても、要求された動作 と違っていれば、単に「動いた」だけでは完了とは言えません。その場合、

implementation
        ↕
specification

を比較する必要があります。

Test Evidence

「testが実行されたか」を知りたいなら、test execution artifactやlogが確認材料になります。ここでも、AIの「testしました」という文章と、実際のtest execution recordは別です。

このprojectでは、test Evidenceを見るとき、

• target
• version
• scope

など、その観測が何についてのものなのかも一緒に確認します。

CI / Build Artifact

CIやbuildの記録も、条件によって確認材料になります。

たとえば、

• target
• version
• time

などが分かれば、

「何についてのbuild/test eventだったのか」

を追いやすくなります。

ただし、CI artifactが存在するだけで、あらゆる意味で完全な再現性や正しさが保証されるわけではありません。

Configuration

「設定として何を意図しているか」を確認したい場合、configuration fileが手がかりになります。しかし、configuration = 現在のruntime state とは限りません。

設定fileにAと書かれていても、実際に動いているsystemがAになっていることは別に確認が必要な場合があります。

Runtime

「今どうなっているか」を確認したい場合には、runtime observationが重要になります。たとえば、

serviceがrunningか
requestにどう応答するか
現在どのversionが動いているか

などです。

ただしruntime observationも、ある対象を、ある時点に、ある方法で観測した結果 です。その結果から、この先永久に同じ状態 までは証明できません。

Log

「過去に何が起きたか」を調べるときにはlogが使われる場合があります。しかし、logも必要な情報を常にすべて含んでいるとは限りません。時刻、対象、eventなどが十分に分からなければ、過去の出来事を確定できないことがあります。

その場合は無理に結論を作らず、UNKNOWN として残します。

問いとSourceを対応させる

簡単に整理すると、

これは万能表ではありません。

対象によって適切なSourceは変わります。

Source of TruthはAIが勝手に決めない

AIに、

何を確認すればいい？

と相談することはできます。

しかし、AIが自分に都合のよいsourceを自由に選び、

これがSource of Truthです

と宣言しただけで、そのsourceが正式な確認先になるわけではありません。

どのsourceをauthorityとして扱うかは、projectやHumanが決める問題です。

Human Authority

この本では、重要な採否やauthority boundaryについて、Humanを最終判断者として扱います。Human authorityは最終判断を行う側を指し、Human authorizationは特定の範囲や操作を実行してよいと決める判断を指します。技術的なPASSやAIのrecommendationだけで、この判断を置き換えることはできません。

複数のAIが「このsourceでよい」と一致したとしても、その一致がHuman authorityの代わりにはなりません。AI recommendationとHuman authorizationは別です。

AI recommendation
        !=
Human authorization

Source同士が食い違ったら

たとえば、

configuration: A
runtime: B

という状態があったとします。

この場合、

どちらが本当か

と単純に一方を消すのではなく、

configurationは何を示すか
runtimeは何を示すか

を考えます。

configurationは「意図された設定」を示し、

runtimeは「その時点で観測された実際の状態」を示しているかもしれません。

二つはそもそも異なる問いに答えている可能性があります。

Freshnessも重要

Source of Truthは、sourceの種類だけでなく、いつ取得した情報かも重要です。

たとえば、

local Git state

を確認したとしても、その後remoteが変更されていれば、

現在のremote state

を確認したことにはなりません。

現在状態についてのClaimでは、freshnessを意識する必要があります。

Source of Truthを決めるときの問い

AI補助開発では、次のように考えると整理しやすくなります。

何を確認したいのか
        ↓
その問いを直接確認できるsourceは何か
        ↓
そのsourceはどのtarget/version/timeについてのものか
        ↓
そのsourceをauthorityとして扱う権限は誰が決めるか

この章のまとめ

• Source of Truthは一つの万能sourceではない
• 確認したい問いによって適切なSourceが変わる
• Git・specification・test artifact・CI/build・configuration・runtime・logは、それぞれ異なる問いに使われる
• configurationとruntimeを自動的に同じ状態とみなさない
• runtime observationにはtimeとobservation methodの境界がある
• 古い情報を現在状態のEvidenceとして使わない
• AIがSource of Truthを勝手に決めるものではない
• authorityを最終的に決めるのはHuman/projectである
• Source同士が食い違ったら、それぞれが何を示しているかを分けて考える

次の章では、これらをAI補助開発の実務へつなげ、完了状態とVerification LoopVerification Loopは、この本で使う最小限の確認の流れです。これは普遍的なSDLCや業界標準ではなく、AIの出力と対象の状態を分けて考えるための本書のモデルです。を使って、AIをどう適切に使うかを整理します。