エージェント向けに Markdown を増やしていると、途中から「どれを読めばよいか」「どこまで信じてよいか」が分からなくなることがあります。拡張子が .md であること自体が問題というより、運用契約・手順・ドメイン事実・未整理の原料が同じ層に混ざることが、コンテキスト肥大と信頼境界のぼやけを生みます。
📑目次
Google Cloud が公開した Open Knowledge Format（OKF） は、そのうち「整理済みの静的知識」を、ベンダー非依存の Markdown + YAML ディレクトリ束（Knowledge Bundle）として運ぶための最小契約です。
OKF ではないもの:
- Wiki 製品
- ライブツール基盤
- リポジトリの振る舞い契約
この記事では、公式の v0.1 / v0.2 と独立したハンズオン・分析を突き合わせ、採用する／様子見する／別レイヤで解く、を今日から切れる形に整理します。
この記事で学べること
Open Knowledge Format（OKF）v0.1 の最小契約
結論と問題設定
結論から言うと、OKF v0.1 は「just markdown / just files / just YAML」の静的知識フォーマットです。必須 SDK・専用ランタイム・独自圧縮は要求されません。
Google Cloud Blog（Sam McVeety & Amir Hormati、2026-06-12）では、カタログ API・Wiki・共有ドライブ・コメント・暗黙知をエージェントが毎回組み立て直す分断コンテキストを、フォーマット側で薄く契約する、と位置づけています。
形式の釘打ち
形式の釘打ちはシンプルです。
- 1 concept = 1 ファイル
- パスが Concept ID になる
- 通常の Markdown リンクでグラフを作る
- frontmatter で常時必須なのは
typeのみ（中央レジストリなし） - 推奨の任意フィールド例: title, description, resource, tags, timestamp
- 予約ファイル:
index.md（progressive disclosure の入口）、log.md（履歴）
設計原則と参考実装
設計原則は次の3つです。
- minimally opinionated（過剰に型を決めない）
- producer–consumer independence（生産者と消費者が独立して進化できる）
- format not platform（製品ロックインしない）
参考実装としては、次が GitHub GoogleCloudPlatform/knowledge-catalog 配下の OKF ツリーに同梱されています。
- BigQuery enrichment agent
- static HTML visualizer
- GA4 / Stack Overflow / Bitcoin などの sample bundle
Knowledge Catalog が bundle を ingest して agents に serve する流れも公式文脈にあります。ただし PoC 色が強く、フォーマット自体は GCP 非依存です。
独立確認と読者への含意
独立ソースも同じ骨格を別角度で確認しています。
- MarkTechPost は vendor-neutral な Markdown 仕様としての導入を整理
- Qiita の @zumax は SPEC 用語（Knowledge Bundle / Concept / Concept ID）と permissive consumer（未知 type・壊れたリンクを拒否しない）を整理
既存 Markdown に type を足すだけで適合に近づける、という段階導入が現実的です。
読者への含意は明確です。
- OKF は「全部を置き換える基盤」ではなく、再利用したい定義・メトリクス・テーブル説明など、整理済みドメイン事実の運び方を標準化する層
- v0.1 は starting point であり、信頼と鮮度は v0.2 側で足される
OKF v0.2 の trust 信号 — エージェントが書くコーパスをどう信じるか
なぜ trust が主課題になるか
v0.1 の後に残る主課題は、エージェントが大量の concept を書き込んだとき「どれを信じてよいか」です。
人間が書いたページには暗黙の説明責任がありますが、生成が 1 万件規模になると、その前提は崩れます。Google Cloud Blog（2026-07-24）の OKF v0.2 は、この問いに frontmatter の opt-in 信号で答える更新です。
v0.2 が整理する5つの問い
v0.2 が整理する5つの問いは次のとおりです。
- provenance（出所） —
sourcesなど、何から作られたか。author / usage_count / last_modified のような credibility signal は持てますが、単一の信用スコア自体は持ちません。 - trust（信頼の段階） —
generated（by/at）とverified（by/at のリスト）を分離。ティア例は unverified / machine-confirmed / human-reviewed。 - freshness（鮮度） —
stale_afterを絶対日付で持つ。 - lifecycle（ライフサイクル） —
status: draft → stable → deprecated（省略時は stable）。 - attestation（計算の証跡） — Attested Computation type。executor receipt と deterministic attester。ランタイムで判定し、結果を bundle に保存しない設計です。
互換性と実務での切り分け
互換性は実用上重要です。
- 常時必須は引き続き
typeのみ - v0.1 bundle はそのまま有効
- rename 例: timestamp → generated.at、本文の Citations リスト → sources（フォールバック可）
- companion sample の acme_retail、visualizer の trust tier / status / staleness 表示も公式更新に含まれる
実務での使い方は単純です。
- 検証済みの定義と、未検証の生成物を frontmatter フィルタで切り分ける
- attestation と verified を混同しない
前者は「その数値が承認された計算経路で出たか」、後者は「定義・記述としての検証」に近い別物です。
ハンズオンで分かった導入の現実（適合率と visualizer の落とし穴）
DevelopersIO の適合率と visualizer
仕様を読むだけでは、導入コストは見えません。Classmethod DevelopersIO（せーの、2026-06-16）の独立ハンズオンは、最小 bundle の手書き、visualizer、既存 Obsidian vault の適合率まで具体数を出しています。
主な観測
- 最小 bundle を手書きすると Concept 3/3 で準拠できる
- GA4 sample の visualizer では 11 concepts / 9 edges / 約 50KB HTML
- 落とし穴: SPEC 上で推奨されがちな absolute path（例:
/tables/customers.md）は、enrichment_agent のviewer/generator.pyで edge としてスキップされる（://または/始まりを continue） - 相対パスに直すと 3 concepts / 5 edges としてグラフがつながる
- 812 件の Obsidian
.mdでは OKF 準拠 206 件（25.4%）、frontmatter なし 487 件（60%）、type なし 119 件（14.7%）。type 追加だけで寄せられる候補は 606 件
参照エージェントと手書き運用の切り分け
enrichment agent 自体は BigQuery + Gemini 前提です。AWS 中心の現場では、手書き bundle + visualizer だけでも検証価値がある、という切り分けが現実的です。
Marie Haynes の concept 抽出
Marie Haynes（2026-06-16）は、ページ単位の丸写しではなく concept 抽出（1ページから複数 concept）を強調します。
- YAML を index card、本文を free-form の知見として分ける
- progressive disclosure で全文を context に詰め込まない
- 自作の OKF “brain” を Gemini でクエリする early prototype（3 docs）も示す
m2lab の役割混線と小さな実験
Zenn の m2lab は、負債の本体を「役割混線」と定義します。
- 手順と事実の同居
- リポ運用契約とドメイン知識の同層化
- 原料とコンパイル済み知識の未分離
全部を OKF に吸い込むと別の肥大化が起き、腐るライブ状態をファイルに書くとすぐに腐ります。
今日からの小さな実験は次の3つです。
- 代表 vault / docs で
type付き frontmatter の割合を数える - visualizer を試すならリンクを相対パスに統一する
- concept 境界（1ファイル1概念）を3件だけ切ってみる
Vault とエージェントメモリ層を分ける論点は、関連記事の 人間向けVaultとAI向けメモリ層を分ける｜エージェント長期記憶の設計判断 も併せて読むと判断が速くなります。
比較表｜OKF・MCP・AGENTS.md・RAG の役割分担
stack としての結論
結論は「競合ではなく stack」です。静的知識・ライブツール・リポ運用契約・未整理原料を同じファイル群に混ぜないことが、導入判断の本体になります。
| 層 | 主に答える問い | 置き場の例 | OKFとの関係 |
|---|---|---|---|
| OKF | 整理済みのドメイン事実は何か | Markdown+YAML Knowledge Bundle | 本記事の焦点。type 必須の静的契約 |
| MCP | 今この瞬間に何ができるか | ライブツール／サーバ | 腐るライブ状態は OKF に書かない |
| AGENTS.md / Skills | どう振る舞うか・手順は何か | リポ運用契約・手順 | 運用契約を OKF に吸わない |
| RAG / 生コーパス | 未整理原料から何を拾うか | 検索インデックス・原文 | concept 化前の原料層 |
| llms.md など道しるべ | 入口の地図は何か | ルート向け短い索引 | OKF の index.md progressive disclosure と補完し得る |
比較の出典
出典（2026年6–7月時点）:
判断基準と隣接トピック
判断基準を一文に落とすと次のようになります。
- 腐る・権限付きのライブ操作 → MCP 側
- チームの振る舞い・禁止事項 → AGENTS.md / skills
- 再利用したい定義・メトリクス・テーブル説明 → OKF candidate
- concept 境界がまだ曖昧 → RAG / 原料のまま棚卸し
エージェントのループとガードの設計は、次の論点が隣接します。
OKF は「何を静的知識として渡すか」を決め、ハーネスは「どう回し、どこで止めるか」を決めます。
HTML 取得・抽出のような実行系ツール選定は、コーディングエージェント向けCLI「ax」 のように「いつ採用するか」を別軸で切るのが安全です。知識フォーマットの問題と、ツール CLI の問題を同じチェックリストに混ぜないでください。
導入判断チェックリストと次のアクション
ここでの目的は、流行シグナルではなく運用条件で分岐することです。
採用向き
- エージェントに渡すドメイン事実が、複数ツール間で翻訳レイヤになっている
- Obsidian 等に type / frontmatter 文化が既にある（約 25% 適合の事例あり）
- progressive disclosure（index + 必要 concept のみ）で context を削りたい
- v0.2 の provenance / trust / freshness で、生成物と人レビュー済みを分けたい
様子見／非採用寄り
- 問題の本体がライブ操作・権限・リアルタイム状態なら、主戦場は MCP
- 問題の本体がリポの振る舞い契約なら、先に AGENTS.md / skills を整理する
- 参照実装の GCP 前提（enrichment agent）にロックインしたく、手書き運用も嫌な場合
今日からのチェックリスト
- 「最初に読むファイル」を10個書き出し、役割（契約／手順／事実／原料）をラベル付けする
- ドメイン事実だけを仮の
knowledge/へ切出し、各 file にtype:を付ける -
index.mdを1つ作り、progressive disclosure の入口にする - リンクは相対パスに統一し、visualizer で edge を確認する（absolute path 罠を避ける）
- 生成エージェントが書く場合は、generated / verified / stale_after 方針を1枚に決める
- 腐るライブ情報はファイルに書かず MCP 側へ逃がす
やらないこと
- 話題性のブクマ数や「流行っているから」だけで全 vault を OKF 化しない
- 二次解説の再話だけで導入を決めない
- 公式 SPEC と、少なくとも1つの独立ハンズオン／分析で数値と落とし穴を確認する
筆者の観点
判断の焦点は、フォーマットの新しさより「どの層の痛みを解くか」です。
- ドメイン事実の翻訳コストが高いなら OKF 候補
- 権限付きライブ操作がボトルネックなら MCP
- チームの振る舞いが揺れているなら AGENTS.md / skills が先
type を足す段階的な切出しと、相対リンクでの可視化確認は、ロックインを抑えつつ失敗コストを下げる現実的な入口になります。逆に、未整理の raw コーパスをそのまま bundle 化すると、別の肥大化が始まります。
よくある質問（FAQ）
Q1. OKF は Google Cloud 専用ですか？
フォーマット自体は vendor-neutral で、just files です。リファレンス実装や Knowledge Catalog 連携は GCP 文脈が強い一方、手書き bundle + visualizer でも検証できます。
Q2. 必須メタデータは何ですか？
v0.1 / v0.2 とも、常時必須は type のみです。trust 系フィールドは v0.2 の opt-in です。
Q3. AGENTS.md や skills を全部 OKF に移すべきですか？
いいえ。振る舞い・手順はリポ契約側、ドメイン事実は OKF、という分離が実務整理です。全部吸うと別の肥大化が起きます。
Q4. Obsidian vault はそのまま使えますか？
type frontmatter があるノートは適合に近いです。DevelopersIO 例では 812 ファイル中約 25.4% が既に準拠し、type 追加で寄せられる候補が多数あります。
Q5. absolute path のリンクは使えますか？
SPEC 上の推奨があっても、公式 visualizer 実装は / 始まりを edge としてスキップします。相対パスでグラフを確認するのが安全です。
Q6. 話題になった二次記事だけで判断してよいですか？
発見のきっかけとしては有用です。仕様・数値・手順の根拠は Google Cloud 公式と独立ハンズオン／分析を使ってください。
関連記事:
まとめ
OKF は、エージェント向けの静的知識を Markdown + YAML で運ぶ最小契約であり、プラットフォームや MCP の代替ではありません。v0.1 で形を、v0.2 で信頼・鮮度・ライフサイクルの信号を足し、既存 bundle は後方互換です。
次の一手は次の順が扱いやすいです。
- 役割ラベルの棚卸し
- type 付き concept を少数切る
- 相対リンクで visualizer 確認
- 生成物には trust / freshness 方針を1枚決める
事実根拠は公式ブログと独立ソースに置き、話題性のシグナルだけで全量移行しないことが、失敗コストを抑える分岐になります。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す