ADR-0115: AI エージェント向け指示・知識レイヤの責務定義と書き分け規約

• Status: Accepted (accepted-with-residual-risks — 末尾の HITL 残余リスク節参照。PR #1423 merge = 受理の規約により 2026-06-04 受理)
• Mode: Standard
• Kruchten Type: Executive/Property
• Scope: platform
• Implementation Status: In Progress (2026-06-04 main 領分着手 — docs-lint Skill staleness 検出ルール実装。§実装時の記録 参照。sub 領分の知識レイヤページ / drp-ops Skill 新設は未着手)
• 起案者: t_saitoh
• 起案日時 (JST): 2026-06-04 19:26
• 承認日時 (JST): 2026-06-04 (PR #1423 merge = HITL 受理)
• Deciders: t_saitoh (単独)

コンテキスト

§1.1 背景

AI エージェント (Claude Code) への指示・知識は現在 6 つの層に分散している: ①hooks + permissions.deny (技術強制) ②CLAUDE.md (毎セッション全文ロード) ③CLAUDE.local.md (クローン固有・gitignore) ④auto-memory (索引常時 + 本文オンデマンド) ⑤.claude/skills/ (description 常時 + 本文呼び出し時ロード) ⑥docs/_internal/ (参照時のみロード)。2026-06-04 のセッション監査で、層の責務が未定義であることに起因する実害を確認した。

§1.2 現状 (As-Is)

• 記載済みルールを拾えず異なる実行をした事例 4 件 (SSoT でなく転写プロンプトを引用して誤説明 / タスク開始時の changelog・BUG_tracking 読込スキップ / 外部書込の承認拡大解釈 / 新規 .md の nav 登録失念)。なお 4 件の原因は一様ではない可能性がある (例: 承認拡大解釈は層①hooks の対象外である外部 API 書込の行動規範問題)。本 ADR では 4 件それぞれの「どの層のどの記述がどう参照されなかったか」の層別トレース表を参照資料として添付し、層定義欠如以外 (既存層の実装不備等) が原因と判明した件は別 issue で追跡して本 ADR のスコープ外と明示する。
• 既知情報の再導出に 8〜10 ツールコール/セッション (認証手順・API スキーマ・検証コマンド・SSoT パスを毎回調べ直し)。承認前の直近 5 セッションの再導出コール数・誤実行件数をベースラインとして記録し、効果測定の基準にする。
• 構造的原因: 「事実形 vs 禁止形」「概念 vs 手順」「常時ロード vs オンデマンド」の書き分け基準が存在しない。

さらに層自体の drift も発見した:

• DRP README が参照する .claude/skills/adr-kit/ はリポに git 履歴が一切ない (未コミット。実体はユーザースコープ ~/.claude/skills/ と推定)。リポ内文書がユーザースコープ資産を参照しており、環境再構築時・将来の参画者には無言で壊れる構造。
• .claude/skills/prompt_*.md 3 件は flat ファイルで <name>/SKILL.md 形式でないため、Skill として自動発見されない (名前空間だけ skills を借りたプロンプト置き場)。
• scripts/deep_research_meta_prompt.md の保存先記述 (tmp/deep-research/) が実慣行 (research_prompts/ 直置き + nav 登録) と乖離。

§1.3 課題

層の責務未定義と drift により、(a) 記載済みルールが拾われず誤実行が発生、(b) 既知情報の再導出に 8〜10 ツールコール/セッションを消費、(c) ユーザースコープ資産依存により環境再構築・参画者拡大時に無言で壊れる構造になっている。

§1.4 制約・要件

• 関連 ADR との整合:
  • ADR-0045 (docs/_internal 文書管理ポリシー): 層⑥内部の配置規約。本起案は⑥の内部構造を変えず、①〜⑤との責務分担を新たに定義する (Refine。Supersede しない)。
  • ADR-0039 (arc42 + feature-folder 文書構造): 層⑥の骨格。整合 (変更なし)。
  • ADR-0105 (用語 Tier 規約) / writing-guide 系: 層⑥の記述規約。本起案は「どの層に置くか」のメタ規約で直交 (Conflict なし)。
  • ADR-0104 (GAS/clasp 認証 Internal 化) 等の hooks 強制系: 層①の既存実装 (scripts/hooks/pre_bash_guard.sh + .claude/settings.json)。整合 (変更なし)。
  • Supersede する既存決定はない。本領域 (エージェント向け知識の層構造) を扱った ADR は未存在。
• 編集対象は sub ワークスペースの編集可能範囲内 (CLAUDE.md は main/sub 両方可ファイルのため、編集直前に git pull origin main を行う既存運用に従う)。
• docs-lint への Skill staleness 検出ルール追加は scripts/** のため main 領分 (実装依頼または [cross-workspace] PR)。
• コード・データモデル・業務フロー・外部 I/F への変更なし。GAS 実装に影響なし (根拠は §5.3 で再検証)。

§1.5 目標 (To-Be)

6 層モデルと責務定義を明文化し、書き分け決定表によって新規知識の層判定を再現可能にする。Skill 形式の手順知識 (drp-ops) をリポ共有化し、再導出コストと drift を継続的に減少させる。

決定

AI エージェント向け指示・知識の 6 層モデルと責務定義を docs/_internal/05_how-to/ の新ページとして v1.0 明文化し、書き分け決定表 (スコープ責務分担基準・tie-breaker・緊急例外パス・層追加ガバナンス含む) を同ページに置く。あわせて .claude/skills/drp-ops/ を新設して DRP 操作手順をリポ共有化し、CLAUDE.md の最小修正・drift 3 件修正・auto-memory 棚卸し・docs-lint の Skill staleness 検出ルール追加 (main 領分) を実施する。

主要決定事項:

1. 6 層モデルと責務定義を docs/_internal/05_how-to/ の新ページとして v1.0 定義として明文化する (「lock」ではなく v1.0 — Claude Code は仕様変更が続く成長中プロダクトであり、Claude Code の major update を強制改訂トリガーとする。下記撤退条件)。責務表の骨子:
   • 層① hooks: 不可逆操作の禁止 (読まれなくても効く)
   • 層② CLAUDE.md: 常時効くべき少数の禁止則 + 役割境界のみ。肥大抑制のため目安上限 200 行
   • 層③ CLAUDE.local.md: クローン役割・個人パス・MCP
   • 層④ auto-memory: セッション横断の状態 (案件進捗・次アクション) と個人の行動補正。feedback は禁止形 or 手順形で書く・reference は安定インターフェースのみ (行番号禁止)
   • 層⑤ .claude/skills: 呼び出して使う手順知識 (<name>/SKILL.md + reference の段階ロード形式必須)
   • 層⑥ docs/_internal: 背景・設計・共有ポリシーの正典
   • 規約ページ冒頭に「本規約は AI エージェントへの指示品質を高めるためのものであり、人間の判断を拘束しない」と 1 文明記する (緊急対応の萎縮防止)。冒頭免責はコールアウト形式とし、人間が緊急操作を行う場合の hooks バイパス手順を別セクションに明記する (§5.3 盲点 #10 反映)。
2. 書き分け決定表を同ページに置く: 「手順は Skill / 状態は memory / 常時禁止則は CLAUDE.md / 背景・共有ポリシーは docs / 不可逆禁止は hook」。新しい知識を書く際はこの表で層を決めてから書く。決定表には次の補助ルールを含める:
   • スコープ責務分担基準: リポ固有の手順・知識はリポスコープ (.claude/skills/ 等のコミット対象)、リポに依存しない汎用個人ツールはユーザースコープ (~/.claude/)。リポ内文書 (docs/・README 等) からユーザースコープ資産への参照は禁止 (環境再構築・将来の参画者に無言で壊れるため)。ユーザースコープ依存で運用している資産はインベントリ (何が・なぜユーザースコープか・欠落時の代替手順) を知識レイヤページに記載する。
   • tie-breaker: 手順と状態の中間など分類に迷う知識は層⑥に置き、Skill description または memory 索引から参照する (main/sub の独立書込で同一知識が複数層に重複登録される事態を防ぐ)。tie-breaker 適用には「1 ヶ月以内に Skill 化を再検討する暫定扱い」のラベルを義務付ける。tie-breaker 累積件数が月 3 件を超えた場合は「分類基準自体が不明確」として書き分け決定表の改訂トリガーとする (§5.3 盲点 #3, #13 反映)。Skill description / memory 索引の更新責務者を明示する。
   • 緊急例外パス: 緊急時は層⑥の暫定メモとして即時記録し、72 時間以内に正規の層へ移動してよい。
   • 層追加ガバナンス: 新しい層の追加は ADR を要する。層数上限は 8。半年毎見直しでは層追加提案の棄却理由も記録する。
3. drp-ops Skill を新設 (.claude/skills/drp-ops/SKILL.md): DRP 操作手順 (Keychain 認証・triageOnly 単体テスト・KV draft 投入と overwrite・checkTriageGate ローカル検証・deep research ランナーと claude 出力抽出の罠) をリポ共有化。陳腐化対策を組み込む:
   • SKILL.md の front matter に「最終検証日 / 検証者 / 対象 DRP バージョン (コミット or デプロイ日)」を必須化する。
   • docs-lint に Skill staleness 検出ルールを追加する: 最終検証日が 6 ヶ月以上前の SKILL.md に CI 警告 + DRP デプロイ成功時の CI が対象バージョンフィールドと現デプロイのコミット SHA を突合する「バージョン一致確認」を lint 判定条件に加える (日付による形骸化防止、§5.3 盲点 #7 反映)。
   • DRP の API ルート・認証フロー・KV 仕様を変更する PR では drp-ops SKILL.md の同期確認をチェック項目とする。
   • main 領分 staleness ルール実装完了までは drp-ops Skill を draft フラグ付きで公開し、cross-workspace 依頼のトラッキング issue を ADR マージ時に生成する (§5.3 盲点 #8 反映)。
   • main 作業の期限とエスカレーション (HITL 追補・残余 critical ① の緩和): (i) 受理後 1 週間以内に sub が cross-workspace 依頼 issue + handover プロンプト (tasks/prompts/ 運用) を起票する (sub 単独で実行可能)。(ii) main の実装期限は受理後 4 週間。(iii) 期限超過時の補償統制: drp-ops SKILL.md の人手検認 (front matter の最終検証日と DRP 実装の目視突合) を月次セルフチェックの必須項目へ昇格し、draft フラグを維持したまま運用を継続する。自動検知の不在は知識レイヤページに既知制約として明記する。(iv) CLAUDE.md の同時編集競合は「後から push する側が解消する」(標準 git 運用) と知識レイヤページに明記する。
4. drift 修正: (a) DRP README の DRP 操作参照は adr-kit でなく新設 drp-ops Skill (リポスコープ) へ付け替える。adr-kit はユーザースコープ個人ツールと位置づけ、上記「リポ内文書からユーザースコープ参照禁止」ルールの適用第 1 号とする (adr-kit のうちリポ固有部分があれば drp-ops へ収載し、リポスコープ移行の要否は実装時に内容を確認して判定・結果を知識レイヤページに記録)、移行判定完了前の暫定状態における参画者向け案内文を drp-ops SKILL.md 冒頭に置く (§5.3 盲点 #4 反映)、(b) .claude/skills/prompt_*.md 3 件は Skill 形式へ移行するか「プロンプトテンプレート置き場」として位置づけを README 注記で明確化、(c) deep_research_meta_prompt.md の保存先記述を実慣行に同期。
5. CLAUDE.md の最小修正: (a) Progress tracking 節に「sub 役割も対象 (読み飛ばし可の対象外)」を 1 行明記、(b) 書き分け決定表の 5 行以内要約を追記し「詳細は知識レイヤページ参照」とリンクする (規約発見の起点を常時ロード層に置く。200 行目安上限との整合を確認の上で追記)。
6. 既存 auto-memory の棚卸し: 「行番号禁止」は新規書込だけでなく既存エントリにも遡及する。規約マージ後 2 週間以内に既存 auto-memory エントリの行番号参照・陳腐化済み記述を全件棚卸しし、非準拠を削除または修正する (棚卸しログを記録)。main / sub の auto-memory はユーザー個人スコープのため独立しており、棚卸しは main / sub それぞれが自スコープを実施する (§5.3 盲点 #1 反映)。さらに auto-memory エントリ数の上限 (50 件) と TTL (90 日未参照で自動アーカイブ候補) を規約に明記する (§5.3 盲点 #6 反映)。上限の執行は「書込み時エンフォース」とする (HITL 追補・残余 critical ② の緩和): 新規エントリを追加する前に索引 (MEMORY.md) の行数を確認し、50 件を超える場合は既存エントリの統合・アーカイブを先に行ってから追加する。検知を月次チェックに依存させず書込み時点で防止することで「検知遅れ→索引爆発」の経路を構造的に塞ぐ。月次チェックの索引行数カウントは backstop (執行漏れの検出) に位置づける。

判断基準 (Decision Drivers)

3.1 評価軸

K.O. criterion: Must 軸 (#maintainable / #operable) の score < 3 は不採用。

3.2 評価軸 × 案スコア表

各案 0-5 で評価。加重和 = (Σ score × 係数) / (満点 × Σ 係数) で正規化。

検討した代替案 (Alternatives Considered)

• 案 a: 全てを CLAUDE.md に集約 — 却下。常時ロード層の肥大はコンテキスト消費を増やし、「量が多くて拾えない」という今回の根本問題をむしろ悪化させる (#maintainable / #efficient 低スコア)。
• 案 b: 個人 auto-memory のみで運用 (現状の延長) — 却下。ユーザースコープのため main/sub 間・将来の参画者に共有されず、同じ再導出コストを各員が払い続ける (#operable K.O.)。
• 案 c: docs/_internal に手順書を増やすのみ (Skill を使わない) — 却下。層⑥は参照時のみロードで、作業の瞬間に存在を想起させる仕組み (Skill の description 常時可視) がなく、「記載はあるのに拾えない」問題が解決しない (#operable K.O.)。

影響 (Consequences)

§5.1 正の影響 (Good)

• 6 層責務と書き分け決定表により、新規知識の層判定が再現可能になる。main / sub / 将来の参画者が同じ判定基準を共有できる。
• drp-ops Skill によって DRP 操作手順がリポ共有化され、main/sub 間・将来の参画者の再導出コスト (現状 8〜10 ツールコール/セッション) が低減する。
• docs-lint の Skill staleness 検出 + バージョン SHA 突合により、Skill 陳腐化の検知が人手依存から外れる。
• 主対象: docs/_internal/05_how-to/ 新ページ 1 件 (nav 登録含む) + CLAUDE.md 数行 + .claude/skills/drp-ops/ 新設 + DRP README の参照付け替え + deep_research_meta_prompt.md 1 行同期 + auto-memory 棚卸し。

§5.2 負の影響 (Bad)

• 初期導入 1.25 人日 + 5 年 TCO 5.00 人日のコスト発生 (内訳は §コスト試算)。
• 本 ADR の Confirmation 達成が main 領分 (docs-lint staleness ルール) に依存しており、sub 単独では Confirmation を半分しか達成できない。main の作業完了が遅延すると規約が「片肺運用」になる (§5.3 盲点 #1, #8 反映)。緩和 (HITL 追補): §決定 3 の期限 (issue 起票 1 週間・main 実装 4 週間)・エスカレーション・補償統制 (人手検認の月次必須化 + draft フラグ維持) で、遅延時も検知が無防備にならない。
• auto-memory の索引常時ロード方式により、エントリ数の線形増加がコンテキスト圧迫を招く可能性 (盲点 #6)。緩和 (HITL 追補): 50 件上限を書込み時エンフォースに変更 (§決定 6)。月次計測は backstop であり一次防衛線ではないため、計測遅れが索引爆発に直結しない。
• tie-breaker が層⑥肥大化と Skill 空洞化を招く構造的リスク。月 3 件超過で改訂トリガーとするが、累積件数の監視運用が必要 (盲点 #3, #13)。
• 規約整備の達成感による確証バイアスで、1 ヶ月後測定が未達でも「浸透不足」と解釈し撤退条件発動を先送りする心理的圧力が想定される (盲点 #12)。

§5.3 中立・トレードオフ (Neutral / Trade-offs)

• main/sub 役割分担への影響 (盲点 #1): CLAUDE.md は main/sub 両方可ファイルだが、編集直前の git pull origin main で競合回避する既存運用に従う。Confirmation 項目を「sub 単独達成可能」と「main 作業要」に分けて記載 (Confirmation 節で実施)。auto-memory はユーザー個人スコープのため main/sub 独立。棚卸しは両者がそれぞれ実施。
• GAS 実装への影響根拠 (盲点 #2): 「GAS 実装に影響なし」の根拠として、(a) adr-lint 現状の平均実行時間と staleness スキャン追加後の推定実行時間を main 領分の実装時に計測・記録する。(b) drp-ops Skill の KV 操作手順が PropertiesService 対象か外部 KV 対象かを SKILL.md 冒頭に明記し、PropertiesService の場合は容量上限 (1 プロパティ 9KB・全体 500KB) チェック手順を Skill に含める。(c) 認証手順陳腐化時の「誤実行の最大影響範囲」を drp-ops SKILL.md の front matter 直下に注記する。
• 将来の参画者向けオンボーディング導線 (盲点 #4): README または CONTRIBUTING からの知識レイヤページへのリンク追加を Confirmation に含める。adr-kit リポ固有部分の移行判定完了前は drp-ops SKILL.md 冒頭の暫定案内文で代替手順を提示。
• 実害 4 件の原因分析 (盲点 #5): 層別トレース表完成前は本 ADR を条件付き承認とし、「層定義欠如起因が 2 件以上であることが確認できた場合に正式発効」とする。コスト試算には「4 件全て層定義欠如の場合」と「2 件のみの場合」の ROI シナリオを層別トレース表完成時に併記する。
• Claude Code major update の定義 (盲点 #9): 「メモリ・Skill のロード挙動・コンテキストウィンドウ仕様・hooks 実行モデルのいずれかに変更を含むリリース」と定義。Claude Code のリリースノートを月次チェック項目に追加。改訂判定期限を「検知後 2 週間以内に判定・4 週間以内に規約更新 or 据え置き決定」と明記。
• 規約の人間誤解防止 (盲点 #10): 冒頭免責文を太字コールアウト + hooks バイパス正規手順を別セクションで明示。onboarding ドキュメントに「このページは AI への指示規約であり人間の行動規範ではない」を追記。
• コード・データモデル・業務フロー・外部 I/F への変更なし。

撤退条件 (Rollback Plan)

• ベースライン: 承認前の直近 5 セッションの再導出ツールコール数と誤実行件数を記録し、判定の基準値とする。
• 導入後 3 ヶ月 (2026-09 月末) 時点で、(a) セッション監査で再導出が 3 ツールコール/セッションを超過する状態が 2 ヶ月連続 (Confirmation の測定指標と同一指標で判定)、または (b) 半年毎見直しで層責務表と実態の乖離が 5 項目以上見つかった場合、規約を「参考情報」に降格し書き分け決定表の強制をやめる。
• 強制改訂トリガー: Claude Code の major update (メモリ・Skill 仕様の変更を含むもの) が発生した場合、定期見直しを待たず層責務表の改訂判定を行う (検知後 2 週間以内に判定・4 週間以内に規約更新 or 据え置き決定)。
• 確証バイアス対策 (盲点 #12): 1 ヶ月後測定前に「再導出が減らなかった場合の原因仮説リスト (層定義の設計ミス・CLAUDE.md 要約の不備・Skill description の問題)」を事前に書き出す pre-mortem 形式の判定基準を設ける。
• revert 手順: 新ページ削除 + CLAUDE.md 追記行の revert + Skill ディレクトリ削除 + lint ルール無効化で 0.25 人日以内に完全復元可能。

コスト試算

初期導入 (合計 1.25 人日):

維持コスト (年間 0.75 人日 / 5 年で 3.75 人日):

5 年 TCO = 初期 1.25 + 維持 3.75 = 5.00 人日 (盲点反映後の改訂値)。LLM コスト: 本 ADR の Pipeline 審査 約 $0.5/run × 3 run (v1 / v2 / escalate 確定) = 約 $1.5。導入後の運用に追加 LLM コストなし (再導出 8〜10 コール/セッションの削減でトークン消費はむしろ減る方向)。

Confirmation

検証手段 / 実行頻度 / 違反時対応 を組み合わせた fitness function:

[sub 単独で達成可能な項目] — 規約マージ後 2 週間以内に手動 QA + nav 自動 lint で確認:

1. 知識レイヤページが 6 層責務表 + 書き分け決定表 (スコープ責務分担基準・tie-breaker・緊急例外パス・層追加ガバナンス含む) + ユーザースコープ依存インベントリを含み nav 登録済みで公開されている (1 ページ)。
2. .claude/skills/drp-ops/SKILL.md が front matter (最終検証日 / 検証者 / 対象 DRP バージョン) 付きで存在し、新規セッションの skill 一覧に表示される (1 件)。main 領分の staleness ルール実装完了までは draft フラグ付き公開。
3. drift 3 件 (adr-kit 参照の drp-ops 付け替え・prompt_*.md 位置づけ・meta prompt 保存先) が修正済み (3 件)。
4. 既存 auto-memory エントリの行番号参照の全件棚卸しが完了し棚卸しログが記録されている (main / sub 各自のユーザースコープを独立に実施)。
5. 実害 4 件の層別トレース表が参照資料として添付され、層定義欠如以外が原因の件は別 issue 化 + クローズ期限明記されている。
6. README または CONTRIBUTING から知識レイヤページへのリンクが追加されている (盲点 #4)。

[main 作業完了を要する項目] — cross-workspace PR トラッキング issue で進捗管理:

7. docs-lint の Skill staleness 検出 (最終検証日 6 ヶ月超で警告 + DRP デプロイ時のバージョン SHA 突合) が CI で毎回実行される。実装完了をもって drp-ops Skill の draft フラグを外す。期限 (HITL 追補): cross-workspace 依頼 issue + handover プロンプト起票は受理後 1 週間以内 (sub 単独達成項目)、main 実装は受理後 4 週間以内。超過時は §決定 3 の補償統制 (人手検認の月次必須化) へ自動移行し、移行した事実を月次チェックログに記録する。

[継続測定項目] — セッション監査 + 月次セルフチェック:

8. 導入後 1 ヶ月のセッション監査 (1 回) で、既知情報の再導出が 3 ツールコール/セッション以下 (ベースライン 8〜10 から半減以上) であることを確認。未達なら pre-mortem リストに照らして原因仮説を検証し、Skill の description 文言と CLAUDE.md 要約のリンク導線を改善して翌月再測定。2 ヶ月連続未達で撤退条件 (a) 発動。
9. 月次の軽量セルフチェック (5 分) で複数層への重複登録・staleness 警告の放置・auto-memory 索引行数 (50 件上限の backstop。一次防衛線は §決定 6 の書込み時エンフォース) ・tie-breaker 累積件数 (月 3 件超で改訂トリガー) を検出する。

違反時対応: Confirmation 項目 1〜6 が 2 週間以内に未達なら起案者責任で延長 PR を発行、項目 7 が 1 ヶ月以内未達なら drp-ops Skill を draft のまま運用継続、項目 8 が 2 ヶ月連続未達で撤退条件発動。

実装時の記録 (main 領分・2026-06-04)

Confirmation 項目 7 (docs-lint の Skill staleness 検出) の main 領分実装で確定した事項:

• 実装: scripts/skill-staleness-lint.mjs 新設。S1 (last_verified 6 ヶ月超 = WARN) / S2 (必須 front matter 欠落 = WARN) / S3 (--deployed-sha 指定時の target_drp_version SHA 突合 = WARN)。CI 配線は docs-nav-lint.yml (毎 PR・S1/S2) + deploy-worker.yml (DRP デプロイ成功時・S3)。
• front matter 契約 (日本語名 → YAML キー): 最終検証日 → last_verified: YYYY-MM-DD / 検証者 → verified_by / 対象 DRP バージョン → target_drp_version: <commit SHA | デプロイ日 YYYY-MM-DD> / draft: true|false。SHA 突合は commit SHA 形式のみ可能なため commit SHA を推奨 (デプロイ日形式は S3 skip + info 表示)。
• 実装時に発見した前提ギャップ: .gitignore が .claude/ 全体を ignore しており、決定 3 の「drp-ops Skill リポ共有化」が commit 不能だった。.claude/skills/drp-ops/ のみ tracked 許可する負規則へ再構成 (adr-kit 等のユーザースコープ資産は ignore 維持 — 決定 2 のスコープ責務分担基準と整合)。
• 実行時間計測 (§5.3 盲点 #2(a)): docs-nav-lint 単体 0.31s (685 md) / skill-staleness-lint 0.22s (0 Skill・fail-open)。Skill 数 ~10 でも file read 数件のため増分は無視できる規模 (<0.1s 推定)。CI 全体への影響なし。
• fail-open: <name>/SKILL.md が 0 件の場合は pass (sub の drp-ops 新設前に lint を先行配備するため)。

参照 (References)

• 関連 ADR: ADR-0045 (docs/_internal 文書管理ポリシー、Refine), ADR-0039 (arc42 + feature-folder 文書構造), ADR-0105 (用語 Tier 規約), ADR-0104 (GAS/clasp 認証 Internal 化)
• 関連 PR/Issue: 層別トレース表は Confirmation 項目 5 として規約マージ後 2 週間以内に作成し本 ADR の参照資料へ追補する。main 領分 docs-lint staleness ルールの cross-workspace 依頼 issue は ADR マージ時に生成する。DRP-380 (escalate PR 自動起票バグ。本 ADR の PR が手動起票である理由)
• 外部資料: 2026-06-04 セッション監査 (実害 4 件・再導出 8〜10 コール/セッションの観測元)

Known Limitations / Escalated Residual Risks (HITL ratification required)

本 ADR は Cross-Validation で goalpost ループ検知 (2 連続却下・却下盲点が毎回移動) のため、自動審査を打ち切り「残余リスク付き Accept」として起票された (ADR-0109 Part4)。以下の未解決 critical 盲点は、人間レビュー (この PR の merge = 受理 / close = 却下) で最終判断すること。LLM critic による反復審査では収束しないと判定されたものであり、PR レビューが外部検証器となる。

escalate 時点の未解決 critical 盲点と HITL 対応 (本 PR 内で人間レビュアー = 起案者が追補):

• 「main / sub の役割分担」ステークホルダーへの影響が過小評価されている → 緩和済: §決定 3 に main 作業の期限 (issue 起票 1 週間 / 実装 4 週間)・エスカレーション・補償統制 (人手検認の月次必須化 + draft フラグ維持)・CLAUDE.md 競合解消責任を追補。
• auto-memory の索引爆発による常時ロードコスト増大 → 緩和済: §決定 6 の 50 件上限を「書込み時エンフォース」(追加前に索引行数確認 → 超過なら統合・アーカイブ先行) に変更し、月次カウントを backstop に降格。検知遅れの経路を構造的に遮断。

上記の緩和は LLM 審査の再収束を待たず人間レビューで確定させたものであり、merge をもって受理 (緩和込みの採択) とする。