「過去の正しさ」を再現する AI を作るな ── 仕様書と Source of Truth の差分がコンテキストだ
AI エージェントの精度は、プロンプト技巧よりもコンテキストで決まる場面が増えている。だがここで言うコンテキストは、整えられた仕様書のことではない。本当に効くのは、仕様書と Source of Truth のギャップそのものと、「なぜズレたか」の理由を蓄えることだ。
仕様書だけ読ませた AI は「過去の正しさ」を再現する。差分理由まで読ませると「今の正しさ」に近づける。Spec-Driven の流行の盲点と、Harness Engineering の本当の核を整理する。
AI エージェントの精度の差を生むのは、もはやモデルでもプロンプトでもない。仕様書ではなく、仕様書と現実のギャップ。そして「なぜズレたか」の理由を蓄えられているかどうか。
- AI エージェントの精度は、モデル単体 → プロンプト → コンテキストと頭打ちの先が移ってきた。
- 「コンテキスト」を整った仕様書だと誤解すると、AI は「過去の正しさ」を再現する。仕様書は時間が経つほど Source of Truth（動くコード・運用・現場判断）から乖離するからだ。
- 本当に効くのは「なぜズレたか」の差分理由。仕様変更／例外許容／実装妥協／issue 議論／レビュー判断、この 5 つの "なぜ" を蓄えるかどうかで AI の出力品質が変わる。
- 資料は整えるもの、コンテキストは蓄えるもの。仕様書は Harness の核に置きつつ、差分理由をその外側に重ねる。良い AI とは出力量ではなく、人間の確認負荷を下げる AI。
プロンプト技巧から「コンテキスト設計」へ
AI エージェントの精度を上げる方法は、ここ数年で重心が動いてきた。
- 〜2023: モデル単体の性能（GPT-3.5 → 4 → Claude 3 → ...）が支配的
- 2023〜2024: 同じモデルでも書き方で差が出るので「プロンプトエンジニアリング」が流行
- 2025〜: 最新モデルの素の精度がコモディティ化、コンテキスト（何を読ませるか）の差が支配的に
2026 年現在、フロンティアモデルの素の差は急速に縮まっている。Claude Opus 4.7 / GPT-5.5 / grok-4.3 のような最上位モデルを使えば、「モデルが何を知らないか」より「そのタスクで何を読ませたか」の方が出力品質に直結する。これが「コンテキスト設計」の時代と呼ばれる現在地。
ここで言うコンテキストは、ただの "入力テキスト" ではない。判断材料・背景・経緯・矛盾・揺れ・迷いを含む、思考の素材の総体。これは前の記事で「暗黙考」と呼んだ層と重なる。
仕様書 vs Source of Truth ── ギャップは必然
「コンテキスト」を聞いて多くの人がまず思い浮かべるのは、仕様書や設計ドキュメントだろう。だがここで本記事は明確に立場を取る：仕様書だけを Context として読ませるのは、ほぼ常に間違いだ。
>2-1仕様書は「こうあるべき」、Source of Truth は「いま動いているもの」
仕様書は"こうあるべき"を書いたものだ。ある時点での合意で、整合性が取れている。整えられている。
でも実装や運用が進むと、実際の "正" は別の場所に寄っていく：
- 動いているコード ── ハードコード・例外ハンドリング・コメントアウトされた古い分岐
- DB のスキーマと実データ ── マイグレーション履歴 / 想定外のレコード / 例外的な値
- API の実挙動 ── ドキュメントに書かれていないレスポンス / 非公式エンドポイント
- 顧客運用の判断 ── 仕様書に書いていない承認ルート / 暗黙の例外
- 現場判断 ── オペレータがその場で下した判断
これらがSource of Truth（SoT）。仕様書は時間が経つにつれて SoT から乖離していく。これは怠慢ではなく、必然的に起こる。要件は変わるし、例外は発生するし、実装には妥協が入る。
>2-2ギャップ＝説明されない差分
問題はギャップが「ある」ことではない。そのギャップが説明されていないことだ。仕様書には「こうあるべき」、コードには「こう動く」が書かれているが、その間にあるはずの "なぜ変わったか"はどこにも書かれていない。
多くの組織はこのギャップを「ドキュメントの劣化」として捉え、仕様書を「正に追従させる」ことに労力を使う。でもそれは結局徒労に終わる ── 整えた瞬間からまた乖離が始まるからだ。
本記事の主張は逆で、ギャップを「説明する対象」として残せ、というもの。
仕様書だけ読ませた AI は「過去の正しさ」を再現する
仕様書だけを AI に読ませると、出力は「過去の合意点」を忠実に再現するものになる。
>3-1仕様書だけ読ませた AI の典型的な失敗
- 「仕様書では X が正と書かれていますが、コードでは Y です」→ 仕様書を信じて X を答え、現実とズレる
- 「仕様書には例外処理が書かれていないので、エッジケースは無視できます」→ 運用上ありえない誤判断
- 「最新の API ドキュメントに従って実装しました」→ 非公式の運用ルールを見落とす
これは AI が悪いのではない。食わせたコンテキストが古い時点で固まっているから、その時点に対して忠実に動いただけ。整った仕様書ほど、AI は安心して「過去の正しさ」を引用してしまう。
>3-2リバースエンジニアリングだけでも足りない
では仕様書を捨ててコードだけ読ませればいいか？それも違う。コードから読み取れるのは「何が・どう実装されているか」だけで、「なぜそうなったか」はどこにも書かれていない。これは 前の記事で扱った暗黙知/暗黙考の話と同じ構造で、結果だけ見ても判断の文脈は再現できない。
「なぜそう書いたか」「なぜこの例外を許したか」── これは熟達者の暗黙知、あるいはその手前の暗黙考そのものだ。仕様書と SoT のギャップに沈んでいるのは、結局この層の知識。
5 つの「なぜ」を蓄えれば、強いコンテキストになる
では何を蓄えればいいか。本記事が提唱するのは、5 つの "なぜ" を意識的に残すこと。
>4-1① なぜ仕様を変えたか
仕様変更の動機。「顧客から〇〇のフィードバックがあった」「上流の前提が崩れた」「実装してみたら別の課題が見えた」── 変更履歴・議事録・Slack ログのどこかに残っているはず。これを残さないと、AI（と人間）は「なぜ古い仕様が破棄されたか」を見失う。
>4-2② なぜ例外を許したか
運用判断で「仕様外だが許す」と決めた判断。承認ルールの例外、特定顧客向けの個別対応、緊急時の手動対応など。これは普通ドキュメント化されない。だが「ありえないはずのケースが日常」になっていることが、現場では珍しくない。
>4-3③ なぜこの実装で妥協したか
実装上の妥協。「本当は X するべきだが、レガシーの制約で Y にした」「パフォーマンス都合で例外を切った」── PR コメントやコード内コメントに残せるが、整った仕様書には書かれない。"妥協の理由" こそが、後から仕様を変える時の判断材料になる。
>4-4④ なぜ issue でこう議論されたか
issue や discussion での議論の流れそのもの。最終結論だけでなく、「却下された案」「議論された前提」「合意に至るまでのトレードオフ」が、コンテキストとして強い。これは Karpathy の LLM Wiki 思想にも通じる ── 「結論より、結論に至る議論」を残す。
>4-5⑤ なぜレビューでこの判断になったか
PR レビューコメント。レビュアーの指摘・懸念・妥協・承認の理由。マージされた後はレビュー履歴を見返す人はほぼいないが、これが残っていれば AI は「同じパターンの判断を、別の場所でも再現できる」ようになる。
これらの "なぜ" を残すことは、Nonaka の SECI モデルでいう 表出化（Externalization）そのもの。違いは、結論ではなくプロセスを表出化すること。プロセスが残るからこそ、別の文脈でも判断パターンが再現できる。
資料は整えるもの、コンテキストは蓄えるもの
5 つの "なぜ" を残せ、と言うと「ドキュメントをもっと書け」と読まれそうだが、それは違う。整える資料と蓄えるコンテキストは、別物として扱うべき。
>5-1資料 ── 整えるもの、対象は人間
提案書、仕様書（最終版）、記事、レポート、マニュアル ── これらは人間（クライアントや読者）に向けて整える。整合性が必要で、矛盾は除去される。「読みやすさ」と「結論の明確さ」が価値。
>5-2コンテキスト ── 蓄えるもの、対象は AI
issue、discussion、PR レビュー、運用メモ、失敗ログ、差分の理由、言語化前のラフメモ ── これらはAI エージェントに向けて蓄える。矛盾も揺れも迷いも残す。整合性より、判断材料としての厚みが価値。
「コンテキスト = 思考プロセス」と捉えると、矛盾を含むのは当然になる。人間の判断は常に揺れているし、組織の決定は時間とともに上書きされる。これを除去せず残せるかが、AI エージェントが「あなたらしい判断」を再現できるかの分かれ目になる。
>5-3どちらを優先する組織が AI 時代に強いか
従来のナレッジマネジメントは「資料を整える」方向に偏っていた。でも AI 時代に強いのは、その手前で「コンテキストを蓄える」運用ができる組織。前の記事で論じたロングテール業務の DX 解像度も、これに直結する。
仕様書は Harness の核、差分理由は外側のレイヤー
では仕様書は捨てるべきか？ 違う、仕様書こそが Harness の核になる。ただし、それだけでは Harness にならない。
>6-1Agent = Model + Harness
Karpathy 由来の整理に従えば、エージェント = Model + Harness。Harness はモデル以外のすべてで、SPEC・REQUIREMENTS・PLAN・ツール・検証・制約・フィードバックループ・コンテキストを含む。
このとき、仕様書は Harness の最も内側のリングとして機能する。なぜなら：
- 仕様書は最初に AI が "立つ前提" を提供する（ベースラインの "あるべき"）
- その外側に SoT（コード・運用）が広がり、さらにその外側に "差分の理由" が重なる
- AI はこの同心円を内側から外側へ参照することで、"過去の正しさ" → "今の正しさ" へと判断を更新できる
>6-2Spec-Driven Development の盲点
Spec-Driven Development (SDD) の流行は基本的に正しい方向だ。仕様書を AI の出発点にすること自体は重要。だが SDD だけでは不十分で、仕様書を磨くことに注力するほど、SoT との差分が説明されないまま残る。本記事の主張は SDD への反論ではなく、SDD の "外側" を設計する論として読んでほしい。
SDD と並んで「Issue Driven Development（IDD）」を提唱する声もある。これは本記事の論と相性が良い ── issue を残すことは、まさに「なぜ議論されたか」「なぜそう決まったか」を蓄える行為だ。SDD と IDD は対立軸ではなく、SDD = 仕様の正、IDD = 差分理由の正、と分担すれば両立する。
>6-3Hermes のような実行基盤との接続
具体的にこの Harness を回す実行基盤として、Hermes Agent のような常駐エージェントが向いている。Skill / Memory / Hooks / Cron を使えば、コードベース・issue・PR・運用ログを継続的に取り込み、5 つの "なぜ" を Vault や Knowledge Graph に蓄積していく運用が成立する。
良い AI = 確認負荷を下げる量
ここまでの議論は最終的に、「良い AI とは何か」の評価軸に行き着く。
>7-1アウトプット量ではなく、確認負荷削減量
2026 年 5 月、Linux カーネル 7.1 RC4 公開時、リーナス・トーバルズがAI による脆弱性報告の急増でセキュリティメーリングリストが「almost entirely unmanageable（ほぼ管理不能）」になったと表明した。2 年前は週 2-3 件だった報告が、AI ツール経由で1 日 5-10 件に。複数の研究者が同じパターンを別々に検出し、重複報告が殺到、メンテナの時間を奪う構造になっている[1][2]。
Linus 自身は「AI 活用そのものを否定しない。ただしコードを理解し、修正パッチまで用意する形で貢献せよ」と求めている。これは AI エージェント運用一般の縮図だ。AI の価値はアウトプット量ではなく、人間の確認・修正・検証負荷をどれだけ下げるかで決まる ── という評価軸への一般化は、前記事 §08 BUSINESS でも触れた。
AI 報告に最低限必要なもの：何が問題か / なぜ問題か / 既存報告と重複していないか / 再現できるか / 影響範囲はどこか / 修正パッチはあるか / そのパッチが妥当かをチェックできるか
>7-2仕様書だけ食わせた AI と "Slop"
仕様書だけ食わせた AI は、それっぽい回答を量産する。一見正しいが、SoT と乖離していて、人間が一つひとつ確認しないと使えない。これは 前記事で触れた "Slop"（AI 生成の低品質・凡庸・テンプレ的な出力）の典型例。差分理由まで食わせた AIこそが、人間の確認負荷を下げる本物の AI になる。
「コンテキストを蓄えるのは大変だ」と言われる。確かに、5 つの "なぜ" を残す習慣を組織に植えるのは簡単ではない。
だが ROI で見れば、その投資はAI が肩代わりする確認・判断の量として何倍にも返ってくる。"Slop を量産する AI" のレビューに人間が時間を溶かす方が、長期的にずっと高くつく。
AI が "今の正しさ" に近づくために必要なのは、整理ではなく蓄積
AI エージェントの精度を上げる方法は、もはやモデルでもプロンプトでもない。仕様書と Source of Truth のギャップ、そして「なぜズレたか」の理由を蓄えられているかどうかに移った。
仕様書だけ読ませた AI は、過去の合意点を忠実に再現する。整って見えるが、現実とズレている。差分理由まで蓄えれば、AI は "今の正しさ" に近づける。同じモデル、同じプロンプトでも、コンテキストの厚みだけが違う。
- 資料は整える（対象は人間 / クライアント）
- コンテキストは蓄える（対象は AI エージェント / 矛盾も揺れも残す）
- 仕様書は Harness の核、その外側に "なぜズレたか" を重ねる
SDD の流行で「仕様書を磨く」方向に注力する組織は多い。だが本当の差別化は、仕様書を整えることではなく、SoT との差分を蓄えることにある。「過去の正しさ」を再現する AI を作らないために、いま整えることをやめて、蓄えることを始める。