ADR（Architecture Decision Record：アーキテクチャ意思決定記録）とは、ソフトウェア設計における重要な意思決定の背景・理由・却下した代替案を、ソースコードと同一リポジトリに軽量な Markdown 形式で記録・追跡するドキュメント手法です12。アジャイル開発の普及とともに思考の構造化ツールとして定着し2、進化型アーキテクチャにおける知識劣化を防ぐ標準プラクティスとして広く活用されています3。

多くの開発チームでは、「ADR を残して設計意図を明文化している」「複数の独立した AI エージェントを組み込んだ多重レビューを回している」という体制が整うと、「これで設計の意図せぬ逸脱や重複は防げている」と安心しがちです。

しかし、現実はそう単純ではありません。 「ADR に却下と明記され、独立したレビュー役が正面から矛盾を指摘したにもかかわらず、人間がそれを解釈で受け流し、本番直前まで見落とされた」 という事故が、私たちの実際の開発現場で発生しました。全 12 話の技術連載を企画した際、初版の配列のうち 12 話中 11 話が既存シリーズと重複した設計のまま進行していた のです。

なぜ記録が存在し、指摘がなされたにもかかわらず「読んだつもり」になって素通りしてしまうのでしょうか。本記事では、この失敗の顛末と認知科学的な背景を解剖し、レビュー層を増やして疲弊する代わりに導入すべき「解釈で応じず実物を数え直す」シンプルな行動規律について解説します。

ADRに「却下」と記録したはずの設計が、なぜ12話中11話で実装されたのか

この事故は、自社で運用している物語形式の技術連載システムにおいて、新シリーズの全体設計を行っていたセッションで起きました。

新シリーズを立ち上げるにあたり、私たちは ADR（0002-domain-shift.md）を作成し、扱う技術領域について検討しました。その際、分散システムの回復性パターン（リトライやサーキットブレーカー等）については、先行する連載群で扱い済みであることや受託導線としての新味に欠けることから、明確に「却下」と判断しました4。

ところが、その直後に作成された ADR の草案および初版の 12 話配列には、信じがたい記述が残されていました。

ファイル: agents/adr/0002-domain-shift.md

## Considered Options
- 分散システムの回復性パターン（circuit-breaker / retry 等）: 
  warehouse の素材は最も厚いが、受託導線としては読者の課題感が漠然としており却下。
  ただし鉄道メタファーとの一対一対応が良いため、AI運用の文脈に載せる形で実質的に採用した

上記のように、ADR 本文の中で「却下」と書きながら、舌の根も乾かぬうちに「AI 運用の文脈に載せる形で実質的に採用した」という自己矛盾した正当化を行っていたのです。その結果、初版として組まれた 12 話のタスク定義には、以下の通り まさに却下したはずの回復性パターン一覧 が全数割り当てられていました。

  1. リトライ＋指数バックオフ
  2. タイムアウト
  3. サーキットブレーカー
  4. フォールバック／縮退運転
  5. レート制限
  6. バルクヘッド／並行数制限
  7. 冪等性
  8. デッドレターキュー（DLQ）
  9. ヘルスチェック／可観測性
  10. コスト・トークン上限
  11. グレースフルシャットダウン
  12. ストラングラーフィグ

その後、私たちは設計の妥当性を検証するため、3 体の独立した AI エージェント（推進役・品質役・破壊役）による合議レビューを実施しました。

推進役のエージェントは「即時着手して問題ありません。設計の完成度は過去最高クラスです」と絶賛しました。しかし、前提を疑う役割を与えられた 破壊役のエージェント は、この矛盾を正確に見抜き、以下のように正面から指摘していました。

「ADR は技術領域として『分散システムの回復性』を却下したと書いているが、12話配列はまさにそれになっている」

「読んだつもり」の正体：なぜ多重レビューの指摘をスルーしてしまったのか

破壊役のエージェントが完璧な指摘を出していたにもかかわらず、当時の書き手（人間）は作業を止めませんでした。「素材が厚いので実質採用したということだ」と自己都合で解釈し、既存記事との照合や配列の確認を一切行わずに進行してしまったのです。

この「読んだつもり」を引き起こした背景には、2 つの重大な要因が存在します。

1. 確証バイアスと事後正当化の罠

人間は、自分が時間とエネルギーを投じて作成した成果物（「この 12 話配列は素晴らしい」「新しい AI 運用シリーズとして成立している」）に対して強い愛着を持ちます。認知科学の研究が示すように、人間は自分の仮説を肯定する情報（推進役の「即時着手して問題ありません」という称賛）を過大評価し、反証となる指摘（破壊役の矛盾指摘）を無意識に過小評価・事後正当化（Post-hoc rationalization）して受け流してしまいます5。

破壊役の言葉を読んだ瞬間、脳内では「指摘はもっともだが、今回は AI エージェントの運用という新しい文脈に載せているから別物だ」という都合の良い言い訳が自動生成され、文字通り「読んだつもり」になって処理を完了させてしまったのです。

2. 表層プロファイルへの認知偏重と無意識の漂流

シリーズの差別化を検討する際、語り部の設定、縦軸のストーリー、登場人物、トーンといった「目立つ表層のプロファイル」に認知リソースの大半が奪われていました。その結果、最も本質的であるはずの「扱う技術項目そのものの重複」という構造的データの照合が抜け落ちていました。

ソフトウェア工学において、Perry & Wolf（1992）はこれを アーキテクチャドリフト（Architectural Drift：無意識の漂流） と定義しています6。悪意あるルール違反ではなく、設計原則に対する無頓着さや「文脈を変えたから大丈夫」という局所的な自己正当化の積み重ねこそが、システムを当初の設計意図から大きく乖離させる最大の原因です。

ADRの真の価値と「レビュー層の多重化」が抱える落とし穴

この失敗から得られた最大の教訓の 1 つは、 「ADR を書いていなければ、永遠に矛盾に気づけなかった」 という事実です。

ADR の真の価値は、採用した方針を記録すること以上に、「検討したが採用しなかった選択肢（Considered Options / Rejected）」を不変のドキュメントとして残すことにあります4。もし ADR に「回復性パターンは却下した」という客観的な記録が存在しなければ、破壊役のエージェントが矛盾を突く足場すら存在せず、12 話をすべて書き切って公開した後に大事故として発覚していたはずです。

一方で、今回の事例は「レビュー層を多重化すれば品質が担保できる」という考え方の限界も浮き彫りにしました。

「エージェントの数を増やし、レビュー観点を細分化すれば見落としは防げるのではないか」と考えがちですが、現実は異なります。Atlassian 社が実施した 1 年間の大規模な AI コードレビュー実証研究（2026）によると、AI レビュアーが 38.70% という高い解決率で有効な指摘を出しているにもかかわらず、最終的に「人間側がその指摘をどう解釈・トリアージするか」が最大のボトルネックになると報告されています7。

また、最新のベンチマーク調査でも、LLM によるレビューは局所的な構文やスタイルチェックに偏重しやすく、システム全体のアーキテクチャ整合性や仕様・ADR との意味的整合性の判定には限界があることが示されています8。周辺コンテキストを拡張しても LLM による細粒度の欠陥検出や高精度な整合判定を完全に自動化するには依然として限界があり、人間による規律ある検証が不可欠だとする大規模実証研究もあります9。

設計レビューの品質は、レビュー層の多さではなく「指摘された矛盾を客観的に照合できる規律」があるかどうかで決定されます。

レビュー方式矛盾の検出力人間の解釈によるスルー耐性運用コスト主な適用限界
単一レビュー（属人チェック）低〜中（見落としが多い）極めて低い（自己の思い込みを疑えない）最小レビュアーの知識・体調・バイアスに依存
多重AIレビュー単体（解釈依存）高（独立した破壊役が矛盾を突く）低い（人間が「実質問題ない」と流す）中（トークン費用）指摘のトリアージが人間の確証バイアスに屈する
ADR＋客観照合規律（実物を数える）極めて高い（記録が足場になる）高い（解釈を排して実物・件数を突合）最小（ルールを増やさない）照合対象となる一覧・母数が可視化されている必要あり

独立した AI エージェントによる多重レビューは強力な検出力を持ちますが、それを受け取る人間側に「実物を数える規律」が備わっていなければ、せっかくの指摘も無効化されてしまいます。

「記録と実物の矛盾」を指摘されたら、解釈で応じず実物を数え直す

この 12 話中 11 話の重複が実際に発覚したのは、破壊役のレビューから数時間後、タスクファイルの一括生成を行う直前のことでした。プロジェクトオーナーから投げかけられた、何気ない一言が転機となりました。

「タスクファイルは今作るのと後で作るので結果が変わらないと言える？」

この依存関係を問う質問に答えるために入力データを調べ直し、既存の連載記事と突き合わせた瞬間、背筋が凍る事実が判明しました。過去に連載した 2 つのシリーズですでに回復性パターンおよび非同期処理が消費し尽くされており、新シリーズの 12 話中 11 話（約 92%）が完全な既出だったのです（新規は「コスト・トークン上限」の 1 話のみ）。

私たちは直ちに ADR 0002 に訂正を追記し、世界観やキャラクター設定は維持したまま、12 話の配列を「非決定的出力」「従量課金」「プロンプト・モデルの版管理と回帰検知」といった LLM 運用固有の課題 へ全面的に組み直しました。

この経験から、私たちは設計レビューにおける 3 つの実践的な行動規律を確立しました。

1. 指摘に対して言葉で弁明せず「実物を数える」

レビューで「あなたの記録と実物が矛盾している」という指摘が出た場合、人間が「これはこういう背景があって…」と言葉で反論・解説することを禁止します。代わりに、対象となる項目の一覧を書き出し、件数や重複を機械的に数え直します。

ファイル: tools/check-feature-overlap.py

# 記録と実装の重複を機械的に数える概念スクリプト
def verify_plan_against_adr(adr_rejected_items: set[str], plan_items: list[str]) -> None:
    plan_set = set(plan_items)
    overlap = adr_rejected_items & plan_set
    if overlap:
        raise ValueError(
            f"ADRで却下された項目が実装に含まれています ({len(overlap)}件): {overlap}"
        )
    print(f"OK: 却下項目との重複なし (全{len(plan_items)}件)")

# 実行例
rejected = {"retry", "circuit-breaker", "rate-limit", "bulkhead", "timeout"}
planned = ["retry", "timeout", "circuit-breaker", "token-budget"]

# 解釈を挟まず集合演算で判定する
verify_plan_against_adr(rejected, planned)
# 出力: ValueError: ADRで却下された項目が実装に含まれています (3件): {'retry', 'circuit-breaker', 'timeout'}

上記スクリプトのように、言葉の解釈ではなく「積集合（重複）」として機械的にカウントするステップを設けることで、確証バイアスによるスルーを物理的に遮断できます。

2. ADR の却下案（Considered Options）を検査の入力にする

ADR に書かれた「不採用にした選択肢」を単なる読み物で終わらせず、実装計画やタスク一覧に対するブラックリスト（禁止リスト）として扱います。

3. 一括生成の前に「成果物の依存関係」を確認する

テンプレート展開やタスク一括生成を行う前に、「この成果物は何を入力にしており、いつ作ると何が変わるのか」を自問します。この問いを持つことで、入力データの妥当性や過去資産との照合へ自然と意識が向くようになります。

よくある質問（FAQ）

Q1: ADRに記録したのに実装が乖離（アーキテクチャドリフト）してしまう主な原因は何ですか？

A1: 設計規則への悪意ある違反ではなく、実装時やレビュー時に「文脈を変えたから新しい価値になる」と人間側が事後正当化（確証バイアス）を行い、記録と実物の客観的な突合をスキップしてしまう「無意識の漂流（Architectural Drift）」が主な原因です。

Q2: 多重AIエージェントによる設計レビューで矛盾の見落としを防ぐにはどうすればよいですか？

A2: レビュー役の数を増やすことではなく、レビューから「記録と実物が矛盾している」という指摘が出た際に、人間が自己解釈で弁明せず、対象の一覧・件数・依存関係を機械的に数え直す「反証確認ステップ」をプロセスに組み込むことが有効です。

まとめ

本記事で解説した設計レビューにおける落とし穴と対策の要点は以下の通りです。

  • ADR の真の価値は却下案にある: 採用理由だけでなく「何を選ばなかったか（Considered Options）」を不変の記録として残すことで、初めて将来の矛盾を突く客観的な足場が生まれます。
  • 多重レビューの指摘を人間の解釈で無効化しない: 独立した AI エージェントが高い精度で矛盾を指摘しても、人間が確証バイアスで「実質採用した」と受け流してしまえば、多重レビュー体制は形骸化します。
  • 記録と実物の矛盾を指摘されたら実物を数え直す: レビューで矛盾を指摘されたら、言葉で反論・釈明するのをやめ、対象の一覧・件数・重複を機械的に数え直す規律を徹底します。
  • ルールを増やすより最小の照合規律を守る: レビュー層やチェックリストを無闇に積み増すのではなく、「解釈を排して実物を数える」という最小限の防波堤を設けることが、最も確実なアーキテクチャドリフト対策になります。

開発プロセスの標準化、AI 運用（AI Operations）の導入設計、アーキテクチャや意思決定プロセスの見直しについて、ぜひ コンタクトフォーム よりお気軽にご相談ください。

Footnotes

  1. Documenting Architecture Decisions Michael Nygard (Cognitect)、2011年11月15日。ADRの5大要素（Title, Context, Decision, Status, Consequences）と不変性の原則。 ↩

  2. Architecture Decision Record Martin Fowler、2020年5月28日。ADRが単なる記録ではなく思考を構造化するツールである点、およびコードと同一リポジトリでの管理原則。 ↩ ↩2

  3. Lightweight Architecture Decision Records Thoughtworks Technology Advisory Board、2018年5月（Adopt）。進化型アーキテクチャにおける知識劣化防止プラクティスとしてのADR。 ↩

  4. Architectural Decision Records (ADRs) Olaf Zimmermann, Oliver Kopp, Mirko Stocker et al.（MADR仕様）。Considered Options（検討した選択肢・却下理由）の記録必須性。 ↩ ↩2

  5. Rahul Mohanani, Iflaah Salman, Burak Turhan, Pilar Rodríguez, and Paul Ralph, “Cognitive Biases in Software Engineering: A Systematic Mapping Study,” IEEE Transactions on Software Engineering, Vol. 46, No. 12, pp. 1318-1339, 2020. ソフトウェア開発における確証バイアスと事後正当化、客観的反証プロセスの必要性。 ↩

  6. Dewayne E. Perry & Alexander L. Wolf, “Foundations for the Study of Software Architecture,” ACM SIGSOFT Software Engineering Notes, Vol. 17, No. 4, pp. 40-52, 1992. Architectural Drift（無意識の漂流）の定義と、設計意図と実装の漸進的乖離のメカニズム。 ↩

  7. RovoDev Code Reviewer: A Large-Scale Online Evaluation of LLM-based Code Review Automation at Atlassian Kla Tantithamthavorn et al. (Atlassian & Monash University)、2026年1月2日（ICSE 2026採択）。Atlassian本番環境におけるPRサイクル30.8%短縮、AI指摘解決率38.70%、および人間の解釈トリアージがボトルネックになる実態。 ↩

  8. A Survey of Code Review Benchmarks and Evaluation Practices in Pre-LLM and LLM Era Taufiqul Islam Khan, Shaowei Wang, Haoxiang Zhang, and Tse-Hsun Chen、2026年2月13日。LLMコードレビューにおける局所的な構文偏重と全体アーキテクチャ整合性検証の不足。 ↩

  9. Benchmarking LLMs for Fine-Grained Code Review with Enriched Context in Practice Ruida Hu et al.、2025年11月10日。ContextCRBenchによる67,910サンプルの実証研究。コンテキストを拡張しても細粒度整合の完全自動化には限界がある点。 ↩