「ブレない参照先」の体系

AIの判断にブレない参照先を与えることが、AI駆動開発の信頼性の基盤となる。

このドキュメントの位置づけ

本ドキュメントは、Vision（01-vision）が示す「なぜAI駆動開発にブレない参照先が必要か」という問いに対し、その世界観を成立させる唯一の物理的根拠を提供する。このアーキテクチャはゼロから発明されたものではなく、RFC・W3C・法令といった人類が積み上げてきた標準体系を、AI時代の設計基盤として再構築するものである。

メタ情報

この章で固定するもの	参照先の4つの特性（権威性・構造性・版管理・機械可読性）と MCP 化の設計原則
扱わないこと	MCP サーバーの実装方法（→実装ガイド）、チーム内ドメイン知識（→Skills）
依存	01-vision（AIの制約の定義）
誤用ポイント	RAG で十分な場面に MCP を適用すること。構造的アクセスが必要な場面を見極めることが重要

このドキュメントについて

AI駆動開発において、AIの出力品質は「何を参照するか」で決まる。このドキュメントでは、AIが判断の根拠とすべき「ブレない参照先」を体系的に整理し、なぜそれが必要なのか、どのような特性を持つべきか、そしてどのように接続すべきかを明確にする。

RFC、W3C、法令といった権威ある情報源をMCP化することで、AIの出力に検証可能な根拠を持たせることができる。これにより、「AIが言っていることは本当か？」という疑問に対して、常に原典を示せる開発体制が構築できる。

注: このドキュメントは主に「外部の権威ある情報源」について扱う。チーム内のドメイン知識・ベストプラクティスについては Skills を参照。MCPとSkillsの使い分けは vs-mcp.md を参照。

なぜAIは「ブレる」のか

1.1 確率的生成の本質

大規模言語モデル（LLM）は、本質的に確率的なテキスト生成システムである。以下のフローチャートは、LLMがテキストを生成する基本的なプロセスを示している。

LLMの確率的生成が持つ主要な特性と、それがAI出力に与える影響を以下の表で整理する。

特性	説明	AIへの影響
統計的パターン学習	学習データ中の共起パターンから「次に来やすいトークン」を予測	「正しい」ではなく「もっともらしい」を出力
サンプリングの非決定性	同じ入力でも異なる出力が生成されうる	一貫性の保証が困難
コンテキスト依存性	プロンプトの微細な違いで出力が変化	再現性の問題

1.2 AIの4つの根本的限界

AIには以下の4つの根本的な限界があり、これらが「ブレ」の原因となる。以下のマインドマップで全体像を示す。

1.2.1 正確性の限界（Hallucination問題）

AIは「知っている」のではなく「生成している」。

ユーザー: RFC 6455のセクション5.5.1で定義されているClose frameの
         ステータスコード1006の意味は？

AIの可能性A: 「1006は予期しない切断を示します」（正しい）
AIの可能性B: 「1006はプロトコルエラーを示します」（誤り - それは1002）
AIの可能性C: 「セクション5.5.1には1006の定義があります」（誤り - 7.4.1が正しい）

ハルシネーションの発生メカニズム

ハルシネーションが発生する主な原因を以下の表で分類する。

原因	説明	例
学習データの希薄性	稀な情報は学習不足	マイナーなRFCの詳細
類似パターンとの混同	似た概念を混同	Close code 1002と1006
自信過剰な補完	不明な部分を「もっともらしく」埋める	存在しないセクション番号の生成
コンテキスト汚染	会話中の誤情報を真実として扱う	ユーザーの誤解を増幅

1.2.2 最新性の限界

AIの知識は学習データの時点で固定されるため、現実世界の変化に追従できない。以下のタイムラインは、学習カットオフと現実世界の進展のギャップを示している。

具体的な影響

最新性の限界が実務に与える具体的な影響を、カテゴリ別に以下の表で整理する。

カテゴリ	問題	例
新規RFC	存在を知らない	RFC 9562（UUIDv7）を知らない
法改正	旧法に基づく回答	改正前の個人情報保護法で回答
廃止・更新	古い仕様を現行として扱う	RFC 2616をHTTP/1.1の標準として参照
セキュリティ	既知の脆弱性を知らない	発見後のCVEを知らない

1.2.3 権威性の限界

AIの出力は「一つの解釈」であり、公式な見解ではない。

問題の構造:

RFC 6455 原文
    ↓
    複数の解釈可能性
    ├── 解釈A（厳格）
    ├── 解釈B（寛容）
    └── 解釈C（文脈依存）

AIの出力
    ↓
    どれかの解釈を「もっともらしく」出力
    ↓
    それが正しい解釈である保証はない

権威性の欠如が問題となる場面

権威性が欠如することで、以下のような場面でリスクが発生する。

場面	リスク	必要な対応
仕様の実装	非準拠な実装	RFC原文の確認
法的判断	コンプライアンス違反	法令原文の確認
セキュリティ	脆弱性の見落とし	公式アドバイザリの確認
契約・SLA	誤った解釈による紛争	契約原文の確認

1.2.4 責任性の限界

AIの出力には説明責任（Accountability）の主体がない。以下の図は、従来の情報源とAI出力における責任の所在の違いを示している。

責任性の限界がもたらす具体的な問題点を以下の表で整理する。

問題	説明	結果
出典の不透明性	何を根拠に生成したか不明	検証不能
改訂の追跡不能	いつの情報に基づくか不明	監査不能
誤りの帰責	誰が責任を負うか曖昧	リスク管理困難

「ブレない参照先」とは何か

2.1 定義

ブレない参照先（Authoritative Reference Source） とは、以下の特性を満たす情報源である。

2.2 5つの特性

「ブレない参照先」を構成する5つの特性を、以下のサブセクションで詳しく解説する。

2.2.1 権威性（Authoritativeness）

情報の発信元が、その領域において正式な決定権または専門性を持つこと。

権威の種類とその特徴を以下の表で分類する。

権威の種類	説明	例
制度的権威	法律や条約で定められた正式な機関	IETF、W3C、ISO、各国政府
デファクト権威	業界で事実上の標準として認められた主体	OWASP、Ecma International
学術的権威	査読プロセスを経た学術コミュニティ	IEEE、ACM
技術的権威	技術の開発元・管理者	各OSSプロジェクト、ベンダー

さらに、権威性には階層があり、上位ほど強い信頼性を持つ。以下の図でその階層構造を示す。

2.2.2 不変性・版管理（Immutability & Versioning）

一度公開された内容は変更されないか、変更される場合は明確な版管理が行われること。

不変性のパターンを以下の表で分類する。

パターン	説明	例
完全不変	一度発行されたら変更されない	RFC（Errataを除く）
版管理付き変更	新版発行で旧版を置き換え	ISO規格、W3C勧告
明示的廃止	古い版を明示的に廃止	RFC obsoletes/updates

RFCにおける不変性モデルの具体例を以下に示す。

RFC の不変性モデル:

RFC 2616 (HTTP/1.1, 1999)
    ↓ obsoleted by
RFC 7230-7235 (2014)
    ↓ obsoleted by
RFC 9110-9114 (2022)

→ 各RFCは発行後変更されない
→ 新しいRFCが古いRFCを「置き換え」る
→ どの時点の仕様かが明確

2.2.3 構造化（Structuredness）

情報が体系的に組織化され、特定の情報を正確に参照できること。

構造化された参照と曖昧な参照の違いを以下の図で対比する。

構造化の具体的な要素とAIにとっての恩恵を以下の表で整理する。

構造化の要素	説明	AIへの恩恵
階層構造	章・節・項の明確な階層	特定箇所の正確な参照
識別子	一意なセクション番号・条項番号	曖昧さのない引用
相互参照	他の文書・セクションへの明示的リンク	関連情報の追跡
インデックス	用語索引、要件一覧	効率的な検索

2.2.4 検証可能性（Verifiability）

AIの出力が原典と照合して正しいか確認できること。

検証可能性は、Visionで定義した「知識変換の第3軸：検証化（Spec-to-Test）」と直結する。仕様を参照するだけでなく、仕様を検証可能なテストに変換することで、AIの出力に対する品質の閉ループが形成される。

以下のシーケンス図は、MCPを介した検証可能な問い合わせフローを示している。

検証可能性を確保する要素

検証可能性を実現するために必要な要素を以下の表で整理する。

要素	説明	実装
永続的URI	参照先が消えない	DOI、RFC番号、法令番号
版指定	どの版を参照したか明示	RFC 9110、ISO 27001:2022
セクション指定	どの箇所を参照したか明示	Section 7.4.1
原文引用	参照元の文言を示す	MUST/SHOULD/MAYの原文

2.2.5 アクセス可能性（Accessibility）

AIがプログラムで参照できる形式で提供されていること。

アクセス可能性のレベルを以下の表で分類する。

レベル	説明	例
構造化API	機械可読な形式でアクセス可能	RFC XML、e-Gov API
HTML/PDF	Webで公開されているがパース必要	W3C仕様、多くのISO
有料・制限付き	アクセスに制約がある	一部のISO規格

理想的なアクセス環境と現実の課題を以下の図で対比する。

2.3 「ブレない参照先」の判定基準

情報源が「ブレない参照先」として適格かどうかを判定するためのフローチャートを以下に示す。

参照先の階層構造

3.1 4層モデル

参照先は信頼性と拘束力に基づいて4つのレベルに分類される。各レベルの遵守義務は RFC 2119 の用語に準じる。

レベル	遵守義務	逸脱した場合のリスク
Level 1 国際標準・法規制	MUST（必須）	相互運用性の欠如、法的問題
Level 2 業界標準・デファクト	SHOULD（推奨）	業界内での互換性問題
Level 3 組織・プロジェクト規約	LOCAL（組織内必須）	チーム内の一貫性欠如
Level 4 ベストプラクティス	MAY（任意）	品質改善機会の逸失

以下の図で階層構造を示す。

3.2 レベル別詳細

各レベルの特徴、代表的な参照先、MCP化状況を以下で詳しく解説する。

レベル1: 国際標準・法規制（MUST遵守）

最高権威の参照先。違反すると相互運用性の欠如や法的問題を引き起こす。

カテゴリ	参照先	5特性評価	MCP化状況
通信プロトコル	IETF RFC	◎◎◎◎◎	✅ rfcxml-mcp
Web標準	W3C / WHATWG	◎◎◎◎○	✅ w3c-mcp
国際規格	ISO	◎◎◎○△	⚡ 一部実装（pdf-spec-mcp）
日本法令	e-Gov	◎◎◎◎◎	✅ hourei-mcp
EU規制	EUR-Lex	◎◎◎◎○	📋 構想

IETF RFCの特性

IETF RFCが5つの特性をどのように満たしているかを以下に整理する。

権威性:     ◎ IETFによる公式発行、WGでのコンセンサス
不変性:     ◎ 発行後変更なし、obsoletes/updatesで管理
構造化:     ◎ セクション番号、MUST/SHOULD/MAYの明確な定義
検証可能性: ◎ RFC番号、セクション番号で一意特定
アクセス性: ◎ RFC XML形式で公開、無料アクセス

レベル2: 業界標準・デファクト（SHOULD遵守）

広く採用されている標準。準拠しないと業界内での互換性に問題。

カテゴリ	参照先	特徴	提供手段	MCP化価値
API設計	OpenAPI Spec	REST APIの事実上の標準	MCP	高
セキュリティ	OWASP	Webセキュリティのベストプラクティス	MCP	高
認証	OAuth 2.0 / OIDC	認可の事実上の標準	MCP	高
メッセージング	AsyncAPI	非同期API仕様	MCP	中

レベル3: 組織・プロジェクト規約（ローカル遵守）

チーム・プロジェクト内で統一すべきルール。外部API経由のアクセスは不要なため、Skills による体系化が主な提供手段となる。

種別	特性	管理方法	提供手段	MCP化価値
コーディング規約	プロジェクト固有のスタイル	Markdown / Linter設定	Skills	低
ADR	アーキテクチャ決定の記録	Git管理されたMarkdown	Skills	低
CLAUDE.md	Claude固有の指示	プロジェクトルート配置	直接参照	—

レベル3の知識は組織内で完結するため、MCP化（外部APIへの動的アクセス）よりも、Skills（Markdown形式のドメイン知識体系化）で管理する方が適切である。Linter設定等のツール強制はガードレール（不可侵制約）として機能する。

レベル4: ベストプラクティス（推奨）

経験則に基づく推奨事項。状況に応じて適用を判断。チームの合意に基づいて Skills として形式知化することで、AIが一貫して参照できるようになる。

種別	出典	適用判断	提供手段	MCP化価値
設計原則	SOLID, DRY, KISS	状況に応じて	Skills	低
デザインパターン	GoF, POSA	問題に適合する場合	Skills	低
クリーンコード	Robert C. Martin	チームで合意した範囲	Skills	低

レベル4は「正解が一つに定まらない」性質を持つため、MCP化には不向きである。チームが採用する原則を Skills として明文化し、AIの判断基準として提供することが効果的である。

AIの判断フロー

4.1 参照先に基づく判断アルゴリズム

AIが実装要求を受けたとき、どのレベルの参照先を優先すべきかを以下のフローチャートで示す。

4.2 出力テンプレート

参照先が見つかった場合:

## 回答

WebSocketのClose frameのステータスコード1006は「異常クロージャ」を示します。

### 根拠

- **出典**: RFC 6455, Section 7.4.1
- **原文**: "1006 is a reserved value and MUST NOT be set as a status code
  in a Close control frame by an endpoint. It is designated for use in
  applications expecting a status code to indicate that the connection
  was closed abnormally"
- **要件レベル**: MUST NOT（実装で設定してはならない）

### 補足

このコードはアプリケーションが異常終了を検知するためのもので、
実際のClose frameに含めて送信することはできません。

参照先が見つからなかった場合:

## 回答

この件について、権威ある参照先を特定できませんでした。

### 確認した情報源

- RFC 6455: 該当する記述なし
- W3C WebSocket API: 該当する記述なし

### 推測

一般的な実装慣行としては〜という傾向がありますが、
これは標準で定められたものではありません。

### 推奨

正確な仕様が必要な場合は、〜を確認することをお勧めします。

参照先MCPの設計要件

5.0 MCPとSkillsの棲み分け

「ブレない参照先」を実現する手段として、MCPとSkillsがある。

観点	MCP	Skills
対象	外部の権威ある情報源	ドメイン知識・ベストプラクティス
例	RFC、法令、W3C標準	設計原則、コーディング規約
特性	動的アクセス、API経由	静的参照、Markdown形式
更新	外部システムに依存	チーム主導で更新

詳細は skills/vs-mcp.md を参照。

5.1 必須機能

参照先MCPが提供すべき必須機能を以下の表で整理する。

機能	説明	例
検索	仕様内のキーワード検索	「WebSocket close frame」
構造取得	章立て・セクション階層	RFC 6455の目次
要件抽出	MUST/SHOULD/MAY抽出	規範性要件の一覧
用語定義	専門用語の定義取得	「Origin」の定義
参照関係	依存する他の仕様	RFC 6455 → RFC 2616
チェックリスト生成	実装確認項目の生成	クライアント実装チェック
検証	実装が仕様に準拠しているか	主張の検証

5.2 RFC MCP のツール設計

RFC MCPのツールインターフェースの設計例を以下に示す。

interface RfcMcpTools {
	// 検索・取得
	searchRfc(keyword: string): RfcSummary[];
	getRfcStructure(rfcNumber: number): Section[];
	getRfcSection(rfcNumber: number, section: string): Content;

	// 要件抽出
	getRequirements(rfcNumber: number, level?: RequirementLevel): Requirement[];
	getDefinitions(rfcNumber: number, term?: string): Definition[];

	// 関係性
	getDependencies(rfcNumber: number): Dependency[];
	getRelatedSections(rfcNumber: number, section: string): RelatedSection[];

	// 実装支援
	generateChecklist(rfcNumber: number, role: 'client' | 'server'): Checklist;
	validateStatement(rfcNumber: number, statement: string): ValidationResult;
}

具体例 — 電子署名法 × RFC 3161

6.1 法的要件と技術仕様の対応

電子署名法第2条の法的要件と、RFC 3161のタイムスタンプ技術仕様がどのように対応するかを以下の図で示す。

6.2 MCP連携による検証ワークフロー

複数のMCPを連携させて、法的準拠性を検証するワークフローを以下のシーケンス図で示す。

参照先の競合解決

7.1 競合時のルール

参照先が互いに矛盾する場合は、以下のルールに従って解決する。

1. 上位レベルが優先 - 法令 > 業界標準 > 組織規約
2. 新しい版が優先 - RFC 9110 > RFC 7230（obsolete）
3. より具体的な仕様が優先 - WebSocket RFC > 一般的なTCP仕様
4. 矛盾がある場合は人間に判断を委ねる

7.2 例：HTTP仕様の参照

HTTP仕様の参照において、正しい参照先と古い参照先の違いを以下に示す。

❌ RFC 2616 (HTTP/1.1 - obsolete)
✅ RFC 9110 (HTTP Semantics - current)
✅ RFC 9111 (HTTP Caching - current)

構築済み参照先MCP一覧

現時点で構築済みの参照先MCPを以下の表にまとめる。

MCP	対象	主要機能	ステータス	リポジトリ
rfcxml-mcp	IETF RFC	構造取得、要件抽出、チェックリスト生成	✅ 運用中	GitHub
w3c-mcp	W3C/WHATWG/IETF Web標準	WebIDL、CSS、HTML要素	✅ 運用中	GitHub
hourei-mcp	日本法令（e-Gov）	法令検索、条文取得	✅ 運用中	GitHub
pdf-spec-mcp	PDF仕様（ISO 32000）	構造取得、要件抽出、バージョン比較	✅ 運用中	GitHub

今後の拡張候補

高優先度

今後、優先的に構築すべきMCP候補を以下の表に整理する。

候補	対象	価値	ステータス
OpenAPI MCP	OpenAPI Spec	API設計の標準準拠確認	📋 構想
OWASP MCP	OWASP Top 10等	セキュリティ要件チェック	📋 構想
OAuth MCP	OAuth 2.0 / OIDC	認証フロー実装支援	📋 構想

中優先度

中優先度として検討しているMCP候補は以下の通りである。

候補	対象	価値	ステータス
ISO MCP	ISO規格	国際標準参照	📋 構想
BIM/IFC MCP	buildingSMART IFC	建築情報モデル	📋 構想
HL7 FHIR MCP	HL7 FHIR	医療情報交換	📋 構想

まとめ

核心メッセージ

このドキュメントで伝える核心的なメッセージを以下にまとめる。

1. AIは「ブレる」 - 確率的生成、学習データの制約、権威性の欠如
2. 「ブレない参照先」が必要 - 権威性、不変性、構造化、検証可能性、アクセス可能性
3. 階層的に整理する - 国際標準 > 業界標準 > 組織規約 > ベストプラクティス
4. MCPで外部情報源に接続する - RFC、法令、W3C標準をAIが参照できる形式で提供
5. Skillsでドメイン知識を体系化する - チームのノウハウを再利用可能な形式で共有
6. 常に根拠を明示する - 出典、セクション、原文を示す

「ブレない参照先」の価値

MCPを導入することで、AIの出力に対する検証可能性がどのように変わるかを以下の図で示す。

AIの判断にブレない参照先を与えることで、出力の信頼性と検証可能性が確保される。

本ドキュメントが示す「ブレない参照先」は、Visionが掲げる「検証可能な設計思想」の物理的基盤である。Visionで定義した責任シフトモデル（設計時・実行時・構造的制約）と二層検証構造（ガードレール・評価パイプライン）は、ここで体系化した参照先の特性と階層構造の上に成立する。