Open Knowledge Format の紹介（9 分読了）

基盤モデルの性能向上が続く中、関連する文脈の不足が、特にエージェントシステムを構築する際に、その能力を制限することが多々あります。これらのモデルはコード作成やドキュメントの要約、データセットの分析などを支援できますが、正確で実行可能な結果を生み出すためには適切な情報が必要です。 そこで本日、私たちは Open Knowledge Format（OKF）を発表します。これは [LLM-wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) パターンをポータブルで相互運用可能な形式として定式化したオープン仕様です。これは、現代の AI システムが必要とするメタデータ、文脈、そしてキュレーションされた知識を表すためのベンダー中立かつエージェントおよび人間に優しい標準規格です。 公開版である **OKF v0.1** では、知識を YAML フロントマター付きのマークダウンファイルのディレクトリとして表現し、異なるプロデューサーが作成したウィキを翻訳なしで異なるエージェントが消費できるようになる、少数の合意された規約を含んでいます。 これだけです。複雑な圧縮スキームも、新しいランタイムも、必須の SDK もありません。OKF ドキュメントのバンドルは以下の通りです： - マークダウンのみ — 任意のエディタで読み込み可能、GitHub でレンダリング可能、あらゆる検索ツールでインデックス可能 - ファイルのみ — ターボールとして出荷可能、あらゆる Git リポジトリにホスト可能、あらゆるファイルシステムにマウント可能 - YAML フロントマターのみ — 照会が必要な少数の構造化フィールド（型、タイトル、説明、リソース、タグ、タイムスタンプ）のために使用 Obsidian、Notion、Hugo、あるいは過去1年間に登場したLLM（大規模言語モデル）のウィキパターンを使用された方なら、その形状は馴染み深く感じられるでしょう。OKF は、これらのパターンを相互運用可能にするために必要な少数の規約を形式化します。 OKF が組織にとってどのような課題を解決できるのか、その仕組み、導入方法、そして今後の展望について見ていきましょう。 ## 分断された文脈の風景 ほとんどの組織において、ファウンデーションモデルが利用する情報は圧倒的に内部知識です：テーブルのスキーマ、ビジネスにおける指標の意味、インシデント対応の手順書（runbook）、2 つのシステム間の結合パス、古い API の非推奨通知など。 現在、これらの知識の原子は、非常に分断された様々なシステムに存在しています： - 独自のAPIを持つメタデータカタログ - ウィキ、サードパーティ製システム、または共有ドライブ内 - コードコメント、ドキュストリング（docstrings）、あるいはノートブックセル - 数人のシニアエンジニアの頭脳の中 AI エージェントが「イベントストリームから週次アクティブユーザーをどのように計算するか？」と問われた場合、その答えはこれらの散在し、互いに非互換な表面から組み立てなければなりません。各ベンダーは独自のカタログ、独自のSDK（ソフトウェア開発キット）、独自の知識グラフスキーマを提供しており、どの知識も製品間や組織間で容易に移植できるものではありません。 その結果：すべてのエージェントビルダーが同じ文脈構築問題をゼロから解決し、すべてのカタログベンダーが同じデータモデルを再発明し、知識自体はそれが作成された表面のいずれかにロックされています。 ## 生きたウィキとしての知識 開発チームは、AI エージェントの構築方法を変えつつあります。同じ事実を何度も検索するためにモデルを使用するのではなく、時間とともに有用性が増していく共有された Markdown ライブラリをエージェントに与えることができます。これにより、エージェントが自分たちのファイルを読み込み更新するという退屈な作業を引き受け、チームはコンテンツをキュレーションし、コードのように管理することが可能になります。 著名な AI 研究者かつ教育者であるアンドレイ・カルパティ氏は、この考え方を彼の [LLM Wiki gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) で最も鋭く表現しています。「LLM は飽きることがなく、相互参照の更新を忘れることもなく、一度に 15 ファイルに触れることができます」と彼は記述しています。人間が個人用ウィキを放棄してしまう原因となる事務処理こそが、LLM が得意とするところです。 同様の「知識としてのウィキ」パターンは、異なる名称で繰り返し現れています。コーディングエージェントに接続された [Obsidian vaults](https://obsidian.md/help/vault)、AGENTS.md / CLAUDE.md 形式の規約ファイル群、実際の作業を行う前にエージェントが参照する index.md や log.md のアーティファクトで満たされたリポジトリ、そしてデータチーム内の「メタデータをコードとして扱う」リポジトリです。 このパターンは説得力があり強力ですが、各インスタンスは個別に作られています。Karpathy のウィキ、あなたのチームのウィキ、ベンダーのカタログエクスポートはいずれも似通った外観（マークダウン、フロントマター、相互リンクなど）をしていても、互いに協力することを意図して設計されたものではありません。どのドキュメントがどのフィールドを持つべきか、ファイル名が何を意味するかについて合意された答えはありません。その結果、ウィキにエンコードされた知識は元のチーム内に閉じ込められたままとなり、新しいエージェントを構築するたびに重複した努力が生じます。 ## 欠けているのは別のサービスではなくフォーマット この問題に対する答えは、新たな知識サービスではありません。必要なのは**フォーマット**です。それは以下のような特徴を持つ知識の表現方法であるべきです： - SDK なしで誰でも作成できる - インテグレーションなしで誰でも利用可能 - システム、組織、ツール間を移動しても存続する - 記述対象のコードと共にバージョン管理システムに存在する - 人間が読みやすく、エージェントが解析可能な形式である：翻訳層を介さない同一ファイル 設計上、OKF はまさにそのフォーマットです。 ## OKF の仕組み：1画面で見るデザイン OKF **バンドル**は、**概念**を表すマークダウンファイルのディレクトリです。ここでいう「概念」とは、テーブル、データセット、メトリクス、プレイブック、ランブック、API など、捕捉したいあらゆるものを指します。各概念は 1 つのファイルとして表現されます。そのファイルパスが概念のアイデンティティとなります： 各概念ドキュメントには、構造化フィールド用の YAML フロントマターと、それ以外の内容用のマークダウン本文が含まれています： 概念は通常の Markdown リンクによって互いにリンクされ、ファイルシステムが暗示する親子関係よりも豊かな関係性の**グラフ**としてディレクトリが機能します。バンドルにはオプションで index.md ファイル（エージェントが階層をナビゲートする際の段階的な開示用）や log.md ファイル（変更の経時的履歴用）を含めることができます。 完全な v0.1 仕様（適合基準、クロスリンクルール、および少数の予約済みファイル名を含む）は単一のページに収まります。 ## デザイン背後の3つの原則 **1. 最小限の意見表明。** OKF はすべての概念に対して正確に1つの要件を課します：type フィールドです。それ以外のすべて（どのような型が存在するか、他のフィールドを含めるか、本文にはどのようなセクションがあるかなど）はプロデューサーに委ねられます。仕様は相互運用性の表面を定義するものであり、コンテンツモデルそのものを定義するものではありません。 **2. プロデューサーとコンシューマーの独立性。** OKF は知識を作成する者とそれを消費する者を明確に分離します。人間が手作業で作成したバンドルは AI エージェントによって消費できます。メタデータエクスポートパイプラインによって生成されたバンドルはビジュアライザーで閲覧可能です。ある LLM によって合成されたバンドルを別の LLM が照会することもできます。フォーマットが契約であり、両端のツールリングはそれぞれ独立して交換可能です。 **3. フォーマット、プラットフォームではない。** OKF は特定のクラウド、データベース、モデルプロバイダー、またはエージェントフレームワークに縛られません。読み取り、書き込み、提供を行うために、 proprietary なアカウントや SDK を決して必要としません。私たちはこれをオープン標準として公開しています。なぜなら、知識フォーマットの価値はそれを所有する誰かではなく、それを話す当事者の数によって生み出されるからです。 ## 仕様と共に提供するもの このフォーマットを具体化するために、プロデューサー側とコンシューマー側の両方で**リファレンス実装**を公開します： - BigQuery データセットを走査し、各テーブルとビューに対して OKF の概念ドキュメントを作成した上で、権威あるドキュメンテーションを検索して各概念に引用元、スキーマ、結合パスを追加するエンリッチメントエージェント。 - 任意の OKF バンドルを単一の自己完結型ファイル内でインタラクティブなグラフビューに変換する静的 HTML ビジュアライザー。バックエンドは不要で、閲覧側へのインストールも不要、データがページから流出することもありません。 - GA4 e コマース、Stack Overflow、Bitcoin 公開データセットの 3 つの即座に閲覧可能なサンプルバンドル。これらはリファレンスエージェントによって生成され、準拠した OKF の生きた例としてリポジトリにコミットされています。 これらは意図的に概念実証です。このエージェントは OKF を作成する一つの手段を示すものであり、フォーマット自体が特定のエージェントフレームワークや LLM（大規模言語モデル）を必要とするものではありません。ビジュアライザーはそれを利用する一つの手段を示すものであり、フォーマット自体が HTML やグラフビューを必要とするものではありません。私たちは、プロデューサーとコンシューマーのエコシステムが、私たちが提供するものよりもはるかに大きく成長することを期待しています（そして望んでいます！）。 ## ここから先へ OKF v0.1 は完成された標準規格というよりも、出発点です。このフォーマットは、より多くのプロデューサーとコンシューマーが現れ、実践においてエージェントが実際に必要とする知識表現が何であるかを私たちが集団的に学ぶにつれて進化していくでしょう。 私たちは、知識カタログの構築、エンリッチメントパイプラインの作成、AI エージェント向けに特化したウィキの運営、あるいは AI 知識ドメインにおけるその他のあらゆる活動に関わらず、知識フォーマットがその名にふさわしいものとなる唯一の方法として、初日からオープンな形で公開しています。 ここからは、以下のことをお勧めします: - 仕様書を読む（短いです！） - ソースシステム、データベース、ドキュメントサイト用のプロデューサーを作成する - コンシューマー（ビューア、検索インデックス、バンドル上で推論を行うエージェントなど）を作成する - 参考実装を自身のデータで試す - イシュウを報告し、PR を送信するか、拡張案を提案する：仕様書はバージョン管理されており、後方互換性を保ちながら成長できるよう意図的に設計されています リポジトリ、仕様書、サンプルバンドルは [GitHub](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf) で利用可能です。また、Google Cloud の [Knowledge Catalog](https://cloud.google.com/blog/products/data-analytics/introducing-the-google-cloud-knowledge-catalog) も更新され、Open Knowledge Format を取り込んでエージェントに提供できるようになりました。関連するコードと例は [こちら](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/toolbox/mdcode/demo) でご覧いただけます。 フォーマットそのものが貢献です。私たちが提供したツールは、それを現実のものとし、試すコストを低下させるために存在します。今日の知識がどのような形であれ、OKF は明日交換可能な共通言語として設計されています。 Google Cloud Data Cloud チームによって公開されました。Open Knowledge Format はオープンな仕様であり、貢献、代替実装、および Google 製品以外の採用も明確に歓迎されます。 著者に加え、この取り組みは Google の多くの他者の重要なアイデアによって実現され、その貢献に対して感謝申し上げます。 投稿先: - データ分析 - AI & マシンラーニング - BigQuery

Open Knowledge Format の紹介（9 分読了）

背景や根拠まで確認しますか？

調べる

選ぶ

サイト