付録出典

本書が外部の資料に依拠して書いた箇所の出典を、章ごとにまとめたものである。読者が自分で一次情報に当たれるようにするために置いている。

読むときに、ひとつ断っておきたいことがある。

ここに並んでいるのは、本書の外に根拠がある事柄だけである。成熟度モデルの段階名、先行する制度が採ってきた運用、他社が公表した品質指標、製品や標準の仕様——こうした「本書が引いてきたもの」には出典がある。

一方で、本書の設計判断そのものには外部の出典がない。制約節で決定の当たる先を決めること、影響範囲で当たるADRを引くこと、【広げる】の4つのレンズという括り方、歯止めを問いと必ず一組にすること——これらは本書が決めたことであり、根拠は本文にある。外部の権威を借りて正当化できる性質のものではないし、そう見せかけてもいけない。この付録に載っていない規範は、本書が自分で立てたものだと読んでよい。

URLは執筆時点（2026年9月）に実在を確認したものだけを載せている。確認できなかったものは、そう書いてある。

なぜ今このメソッドか

• ADR（Architecture Decision Record）という記録形式
  出典：Michael Nygard「Documenting Architecture Decisions」（2011年11月15日）／https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  本書での使い方：決定の理由（WHY）を残す実践が、一般にこの名前で呼ばれていることを示すために引いた。本書のADRがアーキテクチャに限らず、業務ルールに関する決定を必ず残すこと（6章）は、原典との差分である。

• AIは曖昧さを認識しても、問い返さずに埋めることが多い
  出典：Su & Cardie "Knowing but Not Showing: LLMs Recognize Ambiguity but Rarely Ask Clarifying Questions"（arXiv:2605.25284, 2026）／ClarifyCodeBench（arXiv:2607.00711）／単一ターンの選好学習が問い返しを抑えるという説明は ICLR 2025 "Modeling Future Conversation Turns"。
  本書での使い方：「人なら手が止まる。AIも問い返すことはあるが、問い返さずに埋めてしまう場合がある」という本書の出発点は、一次研究で実証されている。本文には研究名を出していない。

• 人の判断を鈍らせる3つのバイアス
  出典：automation bias（医療の臨床意思決定支援研究、JAMA 2023）／confirmation bias（CHI 2025 の病理診断実験）。
  本書での使い方：本書は権威・確証・自動化の3つを挙げたが、研究界の定番は automation／confirmation／anchoring である。本書の「権威バイアス」は automation bias と重なる部分が大きい。anchoring（最初に出た案に引きずられる）も同系の論点だが、本文では扱っていない。

• 開発全体を準委任で進めるモデル契約
  出典：IPA「情報システム・モデル取引・契約書〈アジャイル開発版〉」（2020年3月31日公開）／https://www.ipa.go.jp/digital/model/agile20200331.html 。あわせて IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開）／https://www.ipa.go.jp/digital/model/model20201222.html
  本書での使い方：「この前提は永久ではない」の裏づけ。要件定義を準委任で行う多段階契約はモデル契約が以前から示しており、いまでは一般的である。ただし要件定義の後の開発が、固定価格・納期固定で進む従来型のプロジェクトなら、要件定義書が完成の定義になるという本書の前提は変わらない。前提の有効範囲を狭めるのは、開発全体を準委任で進める形のほうであり、アジャイル開発版はそれを「準委任契約を前提としています」と明記している。

• SDDの主流は、新しい成果物体系を導入する
  出典：GitHub Spec Kit／AWS Kiro／OpenSpec／BMAD の設計思想。over-specification への批判は "Spec-Driven Development: From Code to Contract"（arXiv:2602.00180）。
  本書での使い方：1章で「SDDの解説の多くは、反復のたびに調整していく前提で書かれている」と書いた箇所の出典。本書も、AIが一貫して参照できる構造を求める点では主流と同じである。違いは、主流が成果物の組を用意するのに対し、本書は文書の組を決めず、文書が満たすべき状態を決めることにある。既存の要件定義・外部設計の文書のまま、決定・理由・辿れる網を添え、同じ文書で業務部門とAIの両方に応える。軽量・既存資産志向という点では OpenSpec が近い。over-specification 批判は、本書が「すべての要件には問わない。業務ルールに触れるものに限る」と歯止めを置いていることと同じ線にある。

Trusted Spec の定義

• AI-Native開発の成熟度モデル（ベースライン＝AI-Assisted → Level 1: AI-Generated → Level 2: AI-Verified → Level 3: AI-Explainable。Level 1 の鍵が ContextAwareness）
  出典：NTTデータグループ「アカウンタビリティを軸としたAI-Native開発のデザイン戦略」（2026年3月26日公開、全36ページ）／https://www.nttdata.com/jp/ja/-/media/nttdatajapan/files/services/adm/ai-native.pdf
  （公開の告知：https://www.nttdata.com/global/ja/news/topics/2026/032603/ ／ 解説記事「AI時代のシステム開発に必要な説明責任」2026年4月23日：https://www.nttdata.com/jp/ja/trends/data-insight/2026/0423/ ）
  本書での使い方：射程を Level 1 に宣言する根拠として用いた。段階の名称・番号・ContextAwareness の語は、この資料の用語体系をそのまま採っている（本書が作った語ではない）。13章の実装への接続も、この段階のうち Level 1 の話として書いている。図3（10ページ）をもとに、Trusted Spec の定義の章の図を作成した。抜き出したのは中核要素の4行と移行の鍵で、組織構造・環境の行は省いた。

• 設計根拠（Design Rationale）研究の半世紀
  出典：Kunz & Rittel の IBIS（1970）／MacLean et al. の QOC／Lee の DRL／Buckingham Shum & Hammond "Argumentation-based design rationale: what use at what cost?"（1994）。
  本書での使い方：ADRは設計根拠の軽量な実装である。この分野の最大の教訓は「書くコストが読む便益を上回ると続かない」であり、本書が運用の重さに章を割いているのは、独自の慎重さではなくこの教訓の帰結である。

広げる ── シナリオを歩かせる

• intra-mart の業務フロー（BPM）機能とそのエクスポート
  出典：intra-mart 公式サイト（株式会社NTTデータ イントラマート）／https://www.intra-mart.jp/
  本書での使い方：シミュレーションを「大がかりな準備なしに試せる」と言うときの具体例として挙げた。特定製品を前提にする趣旨ではなく、手元にBPMの機械が読める出力があるなら今日から試せることを示す例示である。

• シナリオベースの要件検証
  出典：Sutcliffe "Scenario-Based Requirement Analysis"（CREWS-98-07）／Sutcliffe et al. "A co-operative scenario based approach to acquisition and validation of system requirements: How exceptions can help!"（1998）。
  本書での使い方：シナリオを歩かせて要件の穴を探す技法は、要件工学で確立されている。非正常系の探索も例外の分類も先行研究にある。本書が変えたのは、シナリオの創作と歩行をAIが担う点だけである。

ADRの扱い

• Nygard形式（ステータス／背景／決定／結果）——本書はADRの記述形式の一案として推奨し、規範にするのは必須の要素まで
  出典：Michael Nygard「Documenting Architecture Decisions」（2011年11月15日）／https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  本書での使い方：ADRの記述形式の一案として推奨した（プラクティス）。記述形式としては「この決定から生じる制約」節を足した。必須の要素には確定者も含む。原典が「決定を覆しても古い記録は残し、superseded と印を付ける」「番号は再利用しない」と書いている点も、本書の置換の規律と同じ向きである。

• 台帳係という役割（採番・形式・つながり・索引だけに責任を持ち、内容に判断を下さない編集者）
  出典：PEP 1「PEP Purpose and Guidelines」（Python Enhancement Proposal の制度定義）／https://peps.python.org/pep-0001/
  本書での使い方：15章で、台帳係の仕事（採番・形式・つながり・索引）をAIに寄せられる量の重さとして挙げた、その先行事例として引いた。原典には "PEP editors don't pass judgment on PEPs. They merely do the administrative and editorial part" と明記されている。

• 状態語彙を絞る判断（本書は4状態。先行事例には9語を持つ制度がある）
  出典：PEP 1 の Status フィールド（Draft／Active／Accepted／Provisional／Deferred／Rejected／Withdrawn／Final／Superseded の9語）／https://peps.python.org/pep-0001/
  本書での使い方：本書が状態を4つに抑え（7章）、却下・取り下げ・保留をISSUE側へ逃がしたことの比較対象として使った。なお Accepted（決定した）と Final（実装まで完了した）を別ステータスで表す設計は、本書のADR／ISSUEの二層と同じ問題への別解である。

• 決定の台帳（不変）と作業の台帳（可変）を分ける二層構造
  出典：Rust RFC（https://github.com/rust-lang/rfcs ）／PEP 1（https://peps.python.org/pep-0001/ ）／IETF RFC（https://www.rfc-editor.org/series/rfc/ ）
  本書での使い方：決定の台帳と作業の台帳を分ける設計（5章）を、3制度がいずれも同型で数十年運用していることの根拠。Rust は "Every accepted RFC has an associated issue tracking its implementation in the Rust repository" と定め、RFC本文（不変）と追跡用の課題（可変）を分けている。受理は実装を保証しない（"Being 'active' is not a rubber stamp"）という明記も、成果物への反映の完了は反映型ISSUEが担い、【確かめる】で指摘が出なくなったら人が閉じる（11章）という本書の線引きと同じである。

• 索引は人手で二重管理せず、ヘッダと制約節から作る（プラクティス）
  出典：PEP 1（ヘッダのプリアンブルとステータス管理）／https://peps.python.org/pep-0001/ ／IETF RFC のメタデータ（Obsoletes／Updates 等）／https://www.rfc-editor.org/series/rfc/
  本書での使い方：索引をどう作るかのプラクティス（7章）で、「人手で二重管理しない」を推した根拠。

• 書く閾値の選別主義（可逆性が低い・複数チームに波及する決定に限る）
  出典：AWS Prescriptive Guidance「Architectural decision record process」／https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html ——"every architecturally significant decision" を対象とし、構造・非機能要件・依存・インタフェース・構築技術の5類型を挙げている。あわせて ADR コミュニティのハブ／https://adr.github.io/
  本書での使い方：6章で「主流が絞る理由は陳腐化と維持コスト」と書いた、その先行事例。本書は業務ルールに関する決定で線を引き、維持コストは15章で扱う。

• 共通原則（旧決定は削除しない／置換は双方向リンク／番号は再利用しない）
  出典：Nygard（https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions ）／MADR（https://adr.github.io/madr/ ）／PEP 1 の Replaces・Superseded-By ヘッダ（https://peps.python.org/pep-0001/ ）／IETF RFC の Obsoletes・Obsoleted By（https://www.rfc-editor.org/series/rfc/ ）
  本書での使い方：7章の規範（削除しない・置換する・番号を再利用しない）が、先行事例の全流派で一致している点であることの根拠。本書が独自に決めたことではなく、既に収束している慣行をそのまま採った箇所であることを示すために挙げている。

• 主流は "Any" から "Architectural" へ揺り戻している
  出典：Nygard 原典（2011）／MADR 4.0.0 のリリースノート（https://adr.github.io/madr/ 、2024-09-17。3.0-beta で採った "Any" を "Architectural" に戻し、「any decision にも使えるが焦点はアーキテクチャ決定」と明記）／"ADRs are not Any Decision Records"（TechWorld with Milan）／ThoughtWorks Technology Radar "Lightweight ADRs"。
  本書での使い方：本書が「重要か」ではなく「業務ルールに関する決定か」で線を引くことは、主流に対する分岐である。主流が絞る根拠（陳腐化と維持コスト）は本書も同じ重さとして引き受けており、その勘定は 15章 にある。

• Nygard 原典は追記を許す
  出典：Nygard「Documenting Architecture Decisions」の "An ADR can have new information added to it" の箇所。
  本書での使い方：本書が追記を許さず置換のみとするのは、原典より厳格な独自の厳格化である。理由は、【確かめる】が当てる制約節の版を一意にするため。

• 決定をテストとして書き、機械的に守らせる
  出典：Ford, Parsons, Kua "Building Evolutionary Architectures"（fitness functions）／ArchUnit／dependency-cruiser／"The Reason Most ADRs Get Written and Never Read Is Architectural"（2026）。
  本書での使い方：実装で機械的に守れるものは、実行可能なテストにも育てられる（14章）。「ADRは書かれても読まれない、決定は強制力を持つ成果物に結びつけよ」という議論は、本書が先行事例の失敗で言っていることと同じ向きである。

• 手作業で維持するトレースは劣化する
  出典：トレーサビリティ維持の劣化に関する報告（arXiv:2607.17686 ほか）。
  本書での使い方：注記に完全性を要求せず、決定がどこに当たるかは制約節の影響範囲で引くことにした根拠。

確かめる

• AIの判定は揺れる。ただし較正して使う道がある
  出典："Rating Roulette: Self-Inconsistency in LLM-As-A-Judge"（arXiv:2510.27106, EMNLP 2025）／"Reliability without Validity"（arXiv:2606.19544）／Guerdan et al. の rating indeterminacy（NeurIPS）。
  本書での使い方：判断できない項目を決めつけずに人に返す設計と、見落としへの備えの「複数回実行の突き合わせ」の根拠。あわせて、判定の揺れと、同じ結果が出るかを測る枠組みが外部に既にあることの提示でもある——測っていないのは本書であって、測りようがないわけではない。なお研究の主流は「判定を使わない」ではなく「較正して使う」方向であり、本書が判定を手前に留めるのは、検収文書に対する判定の責任を人が負うという契約の前提による。

変更管理

• 記録した帰結が忘れられて障害化した事例
  出典：Michael Keeling・Joe Runde（IBM）「Share the Load: Distribute Design Authority with Architecture Decision Records」（Agile Alliance Experience Report、Agile2018）／https://agilealliance.org/resources/experience-reports/distribute-design-authority-with-architecture-decision-records/
  本書での使い方：11章で「反映の作業を追っていなければ、決定は成果物に届きません」と書き、その先行事例として挙げた事例。原文では、リリース9か月後に学習系のシステムが負荷で傾き（"Nine months after launch, our training systems started to buckle from too much load."）、その性能問題はADRに書かれていたが忘れられていた（"This was in the ADR but we forgot about it."）と述べられている。決定の台帳（不変）と作業の台帳（可変）を分け、後者のクローズ条件を検査に結びつける——という本書の答えは、この失敗への応答である。

テスト工程

• 観点カバレッジとDDPモニタリング
  出典：町田欣史（NTTデータ）「バグ密度・テスト密度に依存しない品質保証への挑戦」DATA INSIGHT（初出2021年2月4日、2024年1月にアジャイル開発への適用例を加筆）／https://www.nttdata.com/jp/ja/trends/data-insight/2021/0204/
  本書での使い方：12章が渡す考え方そのものの出どころである。観点カバレッジ（網羅状況をマトリクスで可視化する）とDDPモニタリング（すり抜けの割合の推移を追う）は、本書が考案したものではなく、この資料の手法を採っている。密度に依存しない品質保証という狙いも同じである。出典の観点カバレッジは試験対象×試験観点のマトリクスだが、本書は結合テスト・総合テストを対象にし、【広げる】のシナリオを試験シナリオの種にするので、対象の代わりにシナリオを置いた（試験観点×試験シナリオ）。
  関連：同じ筋の続編として「生成AIを使って開発したソフトウェアの品質保証」（2025年10月16日）／https://www.nttdata.com/jp/ja/trends/data-insight/2025/1016/ ——コード量ベースの指標が使えない生成AI開発でこそ有効だ、と論じている。本書12章が「コードの規模で割る指標から降りる」と書いている部分と同じ文脈接続である。

• バグが少ない案件では参考程度の活用にとどめた、という適用事例
  出典：岩崎慎司・町田欣史・龍真子（NTTデータ）「システムの特徴に応じた品質保証 ～開発技術を組み合わせたテスト事例と効果～」DATA INSIGHT（2024年1月22日）／https://www.nttdata.com/jp/ja/trends/data-insight/2024/0122/
  本書での使い方：12章の読み違えの②「バグが少ないほど1件で大きく振れる」を、手法の提案者自身が実適用で認めていることの根拠として引いた。原文の表現は「バグが少ないと1件のバグによりDDPが大きく動きすぎるため参考程度の活用にとどめました」である。バグが減るほど母数が小さくなるので、AI-Native開発では、この不安定さは避けられない——だからDDPを単独で合否の指標にしない、という本書の立場につながる。

実装への接続

• intra-mart Accel Platform（本章が逆算の材料にしている実装環境）
  出典：intra-mart 公式サイト（株式会社NTTデータ イントラマート）／https://www.intra-mart.jp/
  本書での使い方：13章は、実装するAIが参照するひとそろい（実装のコンテキスト）の例から、上流の仕様に何が求められるかを逆算する章であり、例にした実装のコンテキストの実装環境がこの製品である。ただし本書は特定製品を前提にしない——逆算して取り出しているのは「推測で書くな、根拠を参照しろ」という規律の形であって、製品固有の作法ではない。

• 意味を渡す器の標準化
  出典：Apache Ossie（旧称 Open Semantic Interchange）／https://ossie.apache.org/ ／Apache Incubator 入りの告知（2026年7月10日）／https://ossie.apache.org/updates/ossie-enters-apache-incubator/ ／Apache Incubator のポッドリング一覧／https://incubator.apache.org/clutch/ossie.html
  本書での使い方：項目や指標の意味も実装のコンテキストに渡す、という本文の話の補足として、実在する標準化の動きとして挙げた。データセット・項目・関連・指標の意味をベンダ中立な形式（JSON／YAML）で交換することを狙う仕様である。本文の筋から外れた補足として、コラムに置いた（規範でもプラクティスでもない）。本書の執筆時点でインキュベーション段階にあり、仕様は動く。

• Apache Ossie の成熟度
  出典：ossie.apache.org／Apache Incubator 入りの告知（2026年）。
  本書での使い方：標準としてまだ未成熟であることの裏づけ。2026年9月時点で、この仕様をそのまま実装して出荷した製品は確認できず、動く経路は変換ツールの参照実装にとどまる。コラムの「仕様をそのまま実装した製品は、まだ見当たりません」の裏づけ。

導入とプロジェクトハーネス

• 業界の agent harness は、モデルを取り巻く実行の仕組みを指す
  出典：Addy Osmani "Agent Harness Engineering"／Mitchell Hashimoto の論考／"Harness Engineering Is Not Context Engineering"（advise と enforce の区別）。
  本書での使い方：本書の「プロジェクトハーネス」は業界用法より広いことの裏づけ。業界の重要な教訓は「助言するもの（文脈ファイル）と強制するもの（hook・CI）を厳密に区別せよ」である。

ADR運用の重さ

この章には外部の出典を持たない記述がある。

• 本書が実際に運用してみて分かったこと。ADRがあると、AIは今の方針で進める——本書の執筆にADRを使う中で、よりよい方針の案が出ても、AIはADRに書かれた方針で進めた（15章）。これは本書の執筆で起きたことの記録であって、外部に出典はない。

本文の例について

本文と付録の例（ADR-0231、送料無料の閾値）は、「なぜ今このメソッドか」の章の例に合わせて創作したものであり、実プロジェクトのADRではない。番号・題材・制約節の文言のいずれも架空である。

この付録に載せていないもの

最後に、確認したうえであえて載せなかったものを挙げておく。読者が「なぜこれが無いのか」と迷わないためである。