AIが「成功しました」と言った。でも、本当に成功したのか？

「成功報告」は「成功の証拠」ではない

作業を実行したAIが「完了」と報告しても、それだけで利用者が目的のページを開けるとは限りません。重要なのは、作業者の説明と食い違う可能性のある証拠を、別の経路から確かめることです。

公開できたのに、ページが404だった

2026年10月5日のFORESIGHT公開作業に関する当時の報告では、トップページ更新後に一部の下層ページが404と判明したと記録されています。対象URLを /index.html 付きで再確認し、生成パスを修正して再公開したという経緯が残っています。

これは当時の作業報告に基づく事例です。初回のHTTP応答ログや元の実行Receiptを今回独立に回収できたわけではありません。

別のAIに見せても、独立検証とは限らない

二つのAIが同じ書き換え可能なログを読んでいたら、両方とも同じ誤りを信じるかもしれません。別アカウントや別モデルというだけでは、証拠の独立性は成立しません。

問うべきは「誰が実行したか」「誰が元の証拠を保持するか」「誰が結果を評価するか」「誰が公開や停止を許可できるか」です。

検証を支える4つの役割

実行者：変更を実行し、対象・時刻・結果を記録する。

証拠保管者：元のログや取得結果を保全し、後から差し替えられないようにする。

検証者：作業者の自己申告とは別に、公開URLや動作を確認する。

承認者：失敗時の停止、再実行、公開許可の境界を管理する。

小規模な運用では兼任しても構いません。ただし、兼任している部分を「独立している」とは呼ばないことが大切です。

今日から使える5つの手順

① 作業前に成功条件を決める。例：対象URLがHTTP 200を返し、本文が表示される。

② 変更対象と実行内容を記録する。

③ 実行者の報告とは別の経路で結果を取得する。

④ 結果が違えば成功判定を止め、原因を調べる。

⑤ 修正後に同じ条件で再検証し、承認を分ける。

独立検証の8つのチェックポイント

□ 実行者以外が結果を読めるか。

□ 元の証拠が後から追える形で残るか。

□ 実際の公開URLを開いて確かめたか。

□ 404や失敗も記録されるか。

□ 検証者は実行者の説明だけに依存していないか。

□ 誰が公開権限を持つか明確か。

□ 不一致のとき自動的に止まるか。

□ 修理後の再検証結果を残せるか。

よくある疑問

Q. AIを二体に増やせば十分？　A. いいえ。共通の可変ログや権限があれば、同じ誤りを見逃します。

Q. 人間が毎回確認する必要がある？　A. いいえ。低リスクの検証は自動化できます。ただし、停止と承認の権限設計は必要です。

Q. スクリーンショットがあれば十分？　A. いいえ。HTTP応答、URL、機能動作など、目的に応じた証拠を組み合わせます。

Q. 同じAIが再確認してはだめ？　A. 補助的な自己点検としては有用ですが、それだけで独立検証とは言えません。

Q. すべての証拠を完全に改ざん不能にする必要がある？　A. リスクに応じて保管方法を選び、変更権限と監査可能性を明示します。

Q. Causal Custodyは完成済みの製品？　A. 現段階では検証設計の原則と研究テーマであり、全運用で効果が実証されたとは主張しません。

証明できることと、まだ証明できないこと

当時の報告には、公開後の404発見と修理の経緯が記されています。一方、初回のHTTPログと元の実行Receiptを独立照合できていないため、完全な因果証明は未完了です。

このページは、すべてのAI運用が独立しているという宣言ではなく、独立性をどう確かめるかを示す研究ノートです。

次の研究課題

どの種類の変更なら、どこまで役割と証拠を分離すれば十分なのか。低影響のWeb変更から、検証のコストと効果を実測していきます。