1. 導入
確認項目の多さだけでは、その検証が適切だったかを評価できない。小さな文言修正の前に広い監査を行えば実装までの距離は伸びる。一方、公開直前には、候補が承認範囲内かを広く見る意味がある。
同じWebサイト運用の2事例を対照する。CASE Aは限定的な編集の前で検証範囲が広がり、編集せず停止した事例、CASE Bは配備前に実行対象を限定した事例である。Evidence強度は異なる。一般法則ではなく、検証の配置を考える枠組みを示す。
2. 「タスクと検証範囲の不均衡」とは何か
「タスクと検証範囲の不均衡」とは、操作段階、可逆性、影響範囲、失敗コストに対して、確認対象や停止点の広さが釣り合わない状態を指す。確認が多いこと自体を問題にする言葉ではない。一方、失敗コストの高い境界で必要な確認が不足している場合も、不均衡と評価できる。
評価したいのは「慎重だったか」や確認数ではなく、失敗が起こり得る地点の手前に、その失敗を見つけられる検証があったかである。
3. CASE A――小さな変更の前で監査範囲が拡張した
依頼は、日本語・英語トップページのHero copyだけを変更するものだった。既存HTML構造を保ち、CSS、metadata、navigation、href、無関係な状態は変更しない境界も明示されていた。
先行する監査では、サイト構造、Library、Projects、Tools、About、sitemap、HeroのHTML/CSSに加え、live HTTP、canonicalとhreflang、remote/live byte parity、配備経路、別機能のruntime boundaryまで対象が広がった。回収済みの完全チャット出力ではCHANGED_FILES: Noneで、Hero実装は行われず、Do not editで停止している。
UIにはWorked for 17m 28sと表示された。これはUI elapsed表示としてのみ扱う。監査処理そのものの正味時間とは断定できず、各確認項目に費やした時間の内訳も分からない。
記事上の評価としては、可逆性の高いtext-only変更の実装前として、検証範囲が相対的に大きくなったと解釈できる。ただし、各確認が不要または無駄だったとは判断できず、範囲拡張の原因も未検証である。
Evidence: Hero変更の指示、サイト現況監査の完全チャット出力、評価境界を記録した保存資料を参照する。
4. CASE B――配備境界で対象を限定した
CASE Bで使用できるのは保存された判断記録である。それによれば、full-tree dry-runに関する記録を受け、deploy-allは実行されず、scope外候補としてRansomware V2の日本語・英語関連ファイルが記録された。その後、配備対象をpublic/index.htmlとpublic/en/index.htmlへ限定し、限定配備後はLIVE_VALIDATEDと記録されている。
一方、full-tree dry-runとscoped dry-runの生ログはいずれも未回収である。本稿は出力全体を直接検証しておらず、候補の完全な一覧や、そのまま実行した場合の結果を確定できない。
安全に述べられるのは、「dry-runに関する保存記録を受け、deploy-allは実行されず、配備対象を2ファイルへ限定する判断が行われた」ところまでである。これは配備境界でscopeを見直した記録だが、事故防止や、scope外ファイルが確実に公開されるところだったことの証明ではない。
Evidence: scope限定の判断と配備結果、Ransomware V2関連候補、raw logが未回収であることを示す保存記録を参照する。
5. 2事例を同じ「確認量」で評価しない
次の表は観測事実の一覧ではなく、CASE A/Bを材料にした記事側の評価である。とくにCASE Bは保存された判断記録による限定的な支持であり、raw logを直接確認したCASEではない。
| 評価軸 | CASE A | CASE B |
|---|---|---|
| Task stage | 編集前 | deploy前 |
| Reversibility | ローカル編集前で高い | 配備実行前なら戻しやすいが、実行後は公開状態へ影響する |
| Blast radius | 承認済みのJA/EN Hero copy | public treeへ広がり得る配備対象 |
| Failure cost | 誤った文言の反映や既存Hero構造の破損。承認範囲はJA/ENの局所変更 | 未承認対象を公開範囲へ含める可能性 |
| 観測された進行結果 | 編集せず停止 | deploy-allを実行せず、2ファイル限定へ変更したとの記録 |
| Evidence strength | 完全チャット出力により直接支持 | 保存された判断記録による支持。raw dry-runログなし |
| 適切と考えられる検証範囲 | 対象HTML、構造維持、exact diffを中心にする | 配備候補全体を確認し、承認済みpathへ実行対象を限定する |
前者はまだ変更していない段階、後者は公開範囲へ作用する直前である。同じ確認でも、検出できる失敗と回避できる損失は異なる。
6. リスクに応じて検証を配置する
以下はEvidenceから直接証明された結果ではなく、2事例を材料にした一般的な設計提案（GENERAL DISCUSSION）である。
- 編集前: 対象を誤読し得る。可逆性は高く影響はローカルである。対象path、禁止事項、既存差分を確認する。
- commit前: 無関係な変更を履歴化し得る。まだローカルで修正できるが、commit候補全体へ影響する。exact diff、changed paths、最小限のテストを確認する。
- push前: 誤った履歴を共有し得る。revertは可能でもremote利用者へ影響する。親commit、remote drift、commit内容、push先を確認する。
- deploy前: 未承認対象を公開し得る。実行前なら停止できるが影響範囲はpublic treeである。配備候補、write set、dry-run、復旧手段を確認する。
- deploy後: sourceと公開結果がずれ得る。復旧可能でも公開影響は始まっている。対象URL、内容一致、必要な非回帰項目を確認する。
高コストな検証を全gateへ複製するのではなく、編集前はscope、commit前は差分、deploy前は公開候補と復旧可能性、deploy後は最終状態を重く見る。検証の実務上の価値は、そのgateで起こり得る失敗を判別できるかによって大きく左右される。
7. この事例から分からないこと
- CASE Bのfull-tree dry-runとscoped dry-runのraw logは未回収である。
17m28sには作業別の時間内訳がない。- CASE Aで監査範囲が拡張した原因は検証されていない。
- CASE Bで事故防止の因果は証明されていない。
- 対象は単一プロジェクトの2事例である。
- 他のAI agentやプロジェクトでの再現性は検証されていない。
- 最適な確認量を、このEvidenceから決定することはできない。
そのため、context、prompt、モデル更新、サービス内部の変更、server latencyなどを原因として結論づけることもできない。本稿が扱うのは、残された記録から区別できる作業段階と検証範囲である。
8. 結論
限定的で可逆性の高い編集と、公開範囲へ影響する配備操作では、適切な検証範囲が異なる。確認を一律に増やすことも、一律に減らすことも、この違いには答えてくれない。
実務で問うべきなのは、現在の操作段階、戻せる範囲、影響先、失敗時の損失である。その答えに応じ、対象、差分、配備候補、最終状態の確認を各境界へ置く。今回の2事例は一般法則を証明しないが、「確認量」ではなく「検証の配置」を設計する出発点にはなる。