■ 1. OKFの概要
- 2026年6月12日にGoogle Cloudが公開したAIエージェント向け知識共有フォーマット
- 組織のナレッジをYAMLフロントマター付きMarkdownファイルのディレクトリ構造で表現するベンダー中立なオープン仕様
- 仕様書（SPEC.md）は約450行、リポジトリはGitHubで公開（GoogleCloudPlatform/knowledge-catalog/okf）
- 設計思想は3点:
- 最小限の意見性: 必須フィールドはtypeのみ、それ以外はプロデューサーに委任
- プロデューサー/コンシューマー独立性: 人間の手書き、DBエクスポート生成、LLM読み込みなど任意の主体が利用可能
- フォーマットであってプラットフォームではない: 特定クラウド・SDK・ランタイム不要
■ 2. OKFが登場した背景
- AIエージェントが業務に回答するには散在するコンテキストの統合が必要
- 知識の断片化の現状:
- メタデータカタログ（各社独自API）
- Wiki・サードパーティシステム・共有ドライブ
- コードコメント・docstring・ノートブック
- シニアエンジニアの暗黙知
- ベンダーごとに独自のカタログ・SDK・スキーマが存在し、エージェント構築者が毎回同一の「コンテキスト組み立て問題」をゼロから解いている状況が課題
- OKFは翻訳レイヤー不要で書く側と読む側を分離できる共通フォーマットとして断片化を解消する試み
■ 3. フォーマット仕様
- バンドルの基本構造:
- OKFバンドル = コンセプトを表すMarkdownファイルのツリー
- 1コンセプト = 1ファイル、ファイルパスがそのコンセプトのIDとなる
- ディレクトリ構造はドメイン非依存で、組織の仕方はプロデューサーが決定
- YAMLフロントマターのフィールド:
- type（必須）: コンセプトの種類。中央レジストリへの登録なし、プロデューサーが自明な値を選択
- title、description、resource、tags、timestamp（すべて推奨・任意）
- Markdown本文とグラフ構造:
- 本文は自由記述。通常のMarkdownリンクでコンセプト同士を相互参照し、リレーショングラフを形成
- 予約ファイル名:
- index.md: ディレクトリ内容の列挙（段階的開示用、frontmatterなし）
- log.md: 変更履歴（ISO 8601日付見出しでグループ化）
- OKF v0.1準拠の条件:
- すべての非予約.mdが解析可能なYAMLフロントマターを持つ
- すべてのフロントマターが空でないtypeを持つ
- 予約ファイルが規定の構造に従う
- コンシューマー側は欠けたオプションフィールド・未知のtype・壊れたリンクに対して寛容であることをSPECが規定
■ 4. 関連標準との関係
- OKFは既存の標準と競合するのではなく「積み重なる（stack）」関係にある
- 各標準の役割:
- OKF: キュレートされた静的な知識をファイルで表現するフォーマット
- MCP（Model Context Protocol）: LLMが外部ツールを動的に呼ぶプロトコル（補完関係）
- llms.txt: サイトに置く「道しるべ」、知識リソースへのポインタ（補完関係）
- AGENTS.md / CLAUDE.md: リポジトリに置くアドホックな慣習ファイル（OKFはこれを標準化した位置づけ）
- OKFは「何を知っているか」、MCPは「今何ができるか」、llms.txtは「どこを読めばいいか」として役割が異なる
■ 5. ハンズオン: 最小OKFバンドルの手書きと可視化
- リポジトリのクローン後、mybundle/ディレクトリに1コンセプト = 1ファイルでMarkdownを手書き
- 簡易チェックの結果、3コンセプトすべてがOKF v0.1準拠であることを確認
- ビジュアライザー（enrichment_agentのvisualizeコマンド）でバンドルを単一HTMLに変換可能（バックエンド不要・インストール不要）
- ハンズオンで判明した落とし穴:
- SPEC §5.1ではファイル移動への耐性を理由に絶対パス（/tables/customers.md）を推奨
- しかしリファレンス実装のviewer/generator.pyが絶対パスを明示的にスキップする実装になっており、エッジが生成されない
- リンクを相対パス（./customers.md等）に修正することでエッジが正常に生成される
- v0.1ドラフト段階のSPECと実装のギャップとして認識が必要
- 現時点の実務的対応: ビジュアライザーを使う場合はリンクを相対パスで記述する
■ 6. 既存Obsidian Vaultでの準拠状況
- 812件のMarkdownファイル（日次ノート・プロジェクト・ナレッジ）を検査
- 結果:
- OKF準拠（frontmatter + typeあり）: 206件（25.4%）、意図せず準拠していた状態
- frontmatterなし: 487件（60.0%）
- typeフィールドなし（frontmatterはある）: 119件（14.7%）
- 残り606件はtypeを追加するだけで準拠可能
- 既存のtype値（memo, knowledge, meeting, project等）がそのままOKFのtype値として機能し、中央レジストリが存在しない設計と相性がよい
- 必須フィールドがtypeのみであるため、大規模Vaultでも段階的な準拠移行が現実的
■ 7. AWSエンジニア視点での活用
- フォーマット自体はGCPに依存せず、リファレンス実装（enrichment_agent）のみBigQuery + Geminiが必要
- AWS文脈での活用案（妄想レベル）:
- Amazon Bedrock Knowledge Baseに載せる前段でS3上のドキュメントをOKFバンドルとして整理
- AWS Glue Data CatalogやAmazon DataZoneからOKF形式にエクスポートするスクリプトを書く
- 既存のAGENTS.md運用にOKFバンドルをtype付きMarkdownツリーとして追加
- フォーマット理解の目的であれば手書きバンドル + ビジュアライザーで十分
■ 8. まとめ
- OKFの評価ポイント:
- 必須はtypeだけ: 既存のMarkdown + frontmatter運用にtypeを追加するだけで準拠に近づける
- MCPとは補完関係: 静的ナレッジのフォーマットと動的ツール接続は役割が異なり、並列利用が想定
- v0.1はスタート地点: visualizerとSPECの絶対パス推奨のズレなど、実装はこれから追いつく余地がある
- OKFはObsidianやCLAUDE.mdによるLLM-wikiパターンの慣習に名前と最低限のルールを付けたものと捉えると導入しやすい
- v0.1はドラフトであり、仕様へのフィードバックはGitHubリポジトリ経由で受け付けている