Open Knowledge Format 調査レポート

2026年07月25日

開発元: Google Cloud

カテゴリ: 📚 ナレッジベース/Wiki

公式サイト Docs GitHub DeepWiki Markdown

AIエージェントと人間が共に理解し活用できる知識表現のためのオープンな標準フォーマット

総合評価

85点

基準点70点からの評価

オープンソース

OSS

無料プラン

あり

最低価格

無料

対象ユーザー

AIエージェント開発者データエンジニア

更新頻度

中

🆕 最新情報: v0.2で信頼性シグナルや検証可能な計算のサポートを強化

📋 評価の詳細

👍 加点項目

+5 MarkdownとYAMLのみのシンプルな構成でポータビリティが極めて高い
+5 エージェントが利用しやすい信頼性シグナルやライフサイクル管理が仕様に組み込まれている
+5 特定のベンダーやプラットフォームに依存しないオープンな設計

👎 減点項目

0 特になし

総評: 既存のMarkdownによる構成を標準化し、AI時代のナレッジ共有において強力な相互運用性を提供する

Open Knowledge Format 調査レポート

1. 基本情報

ツール名: Open Knowledge Format (OKF)
ツールの読み方: オープン・ナレッジ・フォーマット
開発元: Google Cloud
公式サイト: https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf
関連リンク:
- GitHub: https://github.com/GoogleCloudPlatform/knowledge-catalog
- ドキュメント: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
カテゴリ: データフォーマット
概要: AIエージェントと人間が共通して利用できる知識表現のためのベンダーニュートラルなフォーマット。MarkdownとYAMLフロントマターを用いたシンプルなファイル構成により、ツールの枠を超えた知識の共有と活用を実現する。

2. 目的と主な利用シーン

解決する課題: 組織内の情報（データスキーマ、メトリクスの定義、API仕様、ランブックなど）が様々なシステムに分散し、AIエージェントがそれらを集約・解釈して利用するのが困難な「知識のサイロ化」という課題。
想定利用者: AIエージェント開発者、データエンジニア、プラットフォームエンジニア。
利用シーン:
- AIエージェントが、組織固有のコンテキスト（データベースの構成やビジネスロジック等）を理解して正確にタスクを遂行するための知識リポジトリ構築。
- エージェント自身が情報を読み書き・維持管理する「LLM Wiki」としての活用。
- 異なるツールやエージェントフレームワーク間で、知識を共有・移行するための中間ポータブルフォーマットとしての利用。

3. 主要機能

シンプルなファイルツリー構成: index.md や log.md などの限られた予約ファイル名と、自由なディレクトリ階層により知識を構造化。
YAMLフロントマターによるメタデータ: type、title、description などのキーを用い、文書の属性を構造化してエージェントからの検索を容易にする。
Markdownによる相互リンク: ファイル間の相対パスまたは絶対パスリンクを利用し、文書同士の関係性をナレッジグラフとして形成。
Provenance（来歴）と信頼性の管理: v0.2で導入された機能。情報源（ソース）、作成者、使用回数、最終更新日などのシグナルを記録でき、エージェントが情報の「確からしさ」を判断する助けとなる。
Lifecycle（ライフサイクル）管理: status (draft, stable, deprecated) や stale_after (有効期限) を指定し、ドキュメントの鮮度と状態を管理する。
Attested Computations（検証可能な計算）: 単なる説明だけでなく、SQLやdbtなどの具体的な計算ロジック（実行方法と検証方法）を分離・定義し、エージェントが正確なロジックを利用したかを検証可能にする。

4. 動作原理・システム構成

アーキテクチャ: 特定のランタイムやSDK、サーバーに依存しない「ファイルベース」のアーキテクチャ。
主要コンポーネントとデータフロー:
- 知識はファイルシステム上のディレクトリとファイル（.md）として記述され、OKFバンドル（Knowledge Bundle）と呼ばれる。
- プロデューサー（人間、エージェント、自動エクスポートパイプライン等）がOKFバンドルを作成・出力し、Gitリポジトリ等で保存・配布する。
- コンシューマー（AIエージェント、検索インデックス、静的サイトジェネレーター等）は、標準的なファイルIOとYAML/Markdownパーサーのみを用いてデータを読み込み、タスクに活用する。
特筆すべき要素技術:
- YAMLフロントマター: マシンリーダブルなメタデータ定義領域。
- Markdown: リンクによるグラフ構造の表現と、人間向けの読みやすさを両立させる。

5. 開始手順・セットアップ

前提条件:
- 任意のテキストエディタ。
- 依存ツールやSDKのインストールは不要（フォーマット仕様のため）。
インストール/導入:
- 仕様に従ってディレクトリとファイルを作成するのみ。
初期設定:
- プロジェクト内にディレクトリを作成し、各MarkdownファイルにYAMLフロントマター（少なくとも type を定義）を追加する。

クイックスタート:

最小構成のファイル例：

---
type: Playbook
title: "Incident response: data freshness alert"
description: Steps to triage a freshness alert.
tags: [oncall, incident]
---

# Trigger
A freshness alert fires when `orders` lags...

# Steps
1. Check the ingestion job dashboard.

6. 特徴・強み (Pros)

極めて高いポータビリティ: 圧縮方式や独自ランタイムがなく、「ただのファイル」であるため、Gitリポジトリやファイル共有システムで簡単に扱える。
ベンダーニュートラル: 特定のクラウドインフラ、データベース、AIモデルプロバイダーに全く依存しない完全なオープンスタンダード。
人間とAIの双方に優しい: MarkdownとYAMLで構成されており、特別な可視化ツールがなくても人間が読み書きでき、かつLLMも自然にパースできる。
知識の鮮度と信頼性の可視化: バージョン0.2から導入されたメタデータ群により、いつ・誰が（またはどのモデルが）生成・検証した情報なのかを追跡でき、ハルシネーションの軽減に繋がる。

7. 弱み・注意点 (Cons)

ソフトウェアではなく「仕様」である点: OKF単体で動作するものではなく、実際に恩恵を受けるにはエージェントフレームワークやカタログツール側がOKFの読み書き（プロデューサー・コンシューマー）に対応する必要がある。
完全なスキーマ定義はない: type 以外のカスタムフィールドは自由に定義できる柔軟性がある反面、エコシステム全体で完全に互換性を持たせるには、ある程度のベストプラクティスや合意形成が必要になる。
日本語対応の現状: 仕様書は英語で提供されているが、フォーマット自体（MarkdownやYAMLの値）に日本語を利用することに技術的な制約は一切ない。

8. 料金プラン

プラン名	料金	主な特徴
オープン仕様	無料	オープンソースプロジェクトとして仕様が公開されており、無料で誰でも利用可能。

課金体系: なし。
無料トライアル: 該当なし。

9. 導入実績・事例

導入企業: Google Cloud。
導入事例: Google Cloudは、自社の「Knowledge Catalog」においてOpen Knowledge Formatを取り込み、エージェントへ提供する機能を実装している。また公式リポジトリにて、GA4 e-commerce、Stack Overflow、Bitcoinなどのパブリックデータセット向けにOKFバンドルのサンプルを公開している。
対象業界: ソフトウェア開発、データ分析、情報システム部門など、社内でAIエージェントの活用を進めるあらゆる業界。

10. サポート体制

ドキュメント: GitHub上で詳細な仕様（SPEC.md）が公開されている。
コミュニティ: GitHubリポジトリのIssueやPull Requestを通じたオープンなコミュニティが存在する。
公式サポート: なし（オープンソース仕様としての対応）。

11. エコシステムと連携

11.1 API・外部サービス連携

API: ファイルフォーマットの仕様であるため、特定のAPIは持たない。
外部サービス連携: Google Cloud Knowledge Catalogなどが標準でサポートを開始している。任意のLLM（Gemini, Claude, GPT等）をベースとした自作エージェントのコンテキスト参照元として統合しやすい。

11.2 技術スタックとの相性

技術スタック	相性	メリット・推奨理由	懸念点・注意点
各種AIエージェント構築フレームワーク	◎	ファイルを読み込ませるだけで強力なコンテキストとして機能する。	フレームワーク側でYAMLフロントマターの解析ロジックを実装する必要がある。
Git / GitHub	◎	プレーンテキストであるため、差分管理、コードレビュー、バージョン管理がネイティブに行える。	特になし。
静的サイトジェネレーター (Hugo, Docusaurus等)	◯	Markdownベースであるため、HTMLへの変換や社内ポータルとしての公開が容易。	OKF独自のメタデータを表示するにはテンプレートのカスタマイズが必要。

12. セキュリティとコンプライアンス

認証: フォーマット自体の仕様であり、認証機能はない。ファイルをホストするリポジトリやファイルシステムのアクセス制御（IAMやGitの権限など）に依存する。
データ管理: ファイルシステムまたはバージョン管理システム上に保存されるため、データの保存場所や暗号化はプラットフォーム側の設定に依存する。
準拠規格: 仕様であるため特定のセキュリティ認証はないが、閉域網内のGitリポジトリ等で運用することで、エンタープライズの厳格なコンプライアンス要件を満たすことが可能。

13. 操作性 (UI/UX) と学習コスト

UI/UX: 仕様であるためUIは持たないが、GitHub上で提供されているリファレンス実装の静的HTMLビジュアライザー等を用いると、OKFバンドルをインタラクティブなナレッジグラフビューとして直感的に閲覧可能。
学習コスト: MarkdownとYAMLの基本知識があれば誰でも記述可能。追加されたProvenance等のフロントマター仕様を理解するだけで済むため、学習コストは非常に低い。

14. ベストプラクティス

効果的な活用法 (Modern Practices):
- Knowledge as a living wiki: エージェント自身にファイルの更新や相互リンクの保守を担わせ、人間がそれをレビュー・管理する運用フロー。
- Metadata as code: 知識をソースコードと同じGitリポジトリで管理し、コードの変更と知識の変更を同時にPull Requestで処理する。
陥りやすい罠 (Antipatterns):
- 過度に深いディレクトリ階層化: 階層が深すぎると人間もエージェントも探索コストが増大するため、適度にフラットな構造を保ち、Markdownリンクによるグラフネットワークを重視する。
- 独自の仕様の乱用: 相互運用性を損なわないよう、独自のメタデータ追加は必要最小限に留める。

15. ユーザーの声（レビュー分析）

調査対象: X (Twitter)、技術ブログ、ITニュースメディア。
総合評価: 仕様発表直後のためG2等のレビューサイトにスコアはないが、AI開発者コミュニティで強い関心を集めている。
ポジティブな評価:
- “Just files”（ただのファイル群）であるシンプルさが非常に好評であり、SDKや特定プラットフォームへの依存がない点が評価されている。
- エージェント構築のたびにコンテキスト組み立ての仕組みを一から実装する手間が省けるという期待。
- SEOから「Agentic Accessibility（エージェントに対するアクセシビリティ）」へのパラダイムシフトを促進する標準として注目されている。（技術ブログより引用）
ネガティブな評価 / 改善要望:
- 仕様自体はシンプルで強力だが、実質的な価値を発揮するかどうかは、今後各種ツールやプラットフォームがどれだけOKFに対応するかに依存しているとの指摘。
特徴的なユースケース:
- 企業の複雑なデータをクリーンなナレッジグラフ（OKFブレイン）として整理し、様々なAIエージェントから一元的にアクセスさせる基盤としての活用。

16. 直近半年のアップデート情報

2026-06: OKF v0.2の仕様が公開。「Provenance（来歴）」「Trust（信頼性）」「Lifecycle（ライフサイクル）」「Attested Computations（検証可能な計算）」のフロントマターが追加・整理され、AIエージェント時代により適したトラストモデルが導入された。
2026-06-12: Google CloudからOpen Knowledge Format v0.1が発表され、初期の仕様が公開された。

(出典: Google Cloud Data Analytics Blog / GitHub SPEC.md)

17. 類似ツールとの比較

※ソフトウェア製品ではなくデータフォーマット仕様であるため、類似するアプローチとの比較となる。

17.1 機能比較表 (星取表)

機能カテゴリ	機能項目	Open Knowledge Format	独自のLLM Wiki	OpenAPI / JSON Schema
基本機能	仕様のオープン性・標準化	◎ ベンダーニュートラルなオープン仕様	× プロジェクトごとに独自	◎ 標準化されている
表現力	あらゆるドメイン知識の記述	◎ Markdownにより極めて柔軟	◎ 同様に柔軟	△ API定義やデータ構造に特化
非機能要件	エージェントフレンドリー	◎ メタデータが構造化されている	△ 解析方法が統一されていない	◯ 構造化済みで解析可能
非機能要件	信頼性・ライフサイクル管理	◎ v0.2でネイティブサポート	△ 独自に実装する必要あり	△ 一部サポートに留まる

17.2 詳細比較

ツール名	特徴	強み	弱み	選択肢となるケース
Open Knowledge Format	MarkdownとYAMLを用いたオープンフォーマット	ツール・ベンダーに非依存でポータビリティが極めて高い。	エコシステムの拡充（ツールの対応）を待つ必要がある。	組織全体の知識を複数のエージェントに横断的に活用させたい場合。
独自のLLM Wiki (Obsidian等)	各チームが独自に構築するWikiアプローチ	各チームの用途に合わせて無限にカスタマイズ可能。	組織間での共有や、他のエージェントへの移植が困難（サイロ化）。	個人の知識管理や、特定のツール内に完全に閉じて利用する場合。
OpenAPI / JSON Schema	APIやデータ構造の厳密な定義仕様	コンピュータによる機械的な検証やコード生成が確実。	人間にとって読み書きが難しく、汎用的な業務知識の記述には不向き。	システム間の厳密なAPI連携仕様を定義する場合。

18. 総評

総合的な評価:
- Open Knowledge Formatは、増大する「AIエージェントのためのコンテキスト管理」という課題に対して、「単なるファイル (Markdown + YAML)」という原点回帰でありながら極めて実用的なアプローチで解を提示するフォーマットである。ベンダーロックインがなく、人間とAI双方のアクセシビリティを確保している点で画期的といえる。
推奨されるチームやプロジェクト:
- AIエージェントを業務に導入・開発しているチーム。
- データガバナンスや社内Wikiの管理を行っているプラットフォームエンジニアリングチーム。
選択時のポイント:
- 社内知識のサイロ化に悩み、複数種類のエージェント（Gemini, Claude, GPT等）が同一の知識ベースを参照できるようなオープンなアーキテクチャを目指す場合に、現時点で最も有力なフォーマットの選択肢となる。