Open Knowledge Format v0.2 におけるエージェントの信頼性担保の取り組み

※この投稿は米国時間 2026 年 7 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

2026 年 6 月に Open Knowledge Format（OKF）を導入した際、Google は「エージェントに必要なコンテキスト（テーブル スキーマ、指標の定義、ランブック）は特定のサービスや非構造化テキストに散在させるのではなく、単一の標準形式として定義されるべきだ」と提言しました。こうした方針のもと、OKF v0.1 はマークダウン、YAML フロントマター、そしていくつかの規則のみで構成されるシンプルな形でスタートしました。

デベロッパー コミュニティからの多大な反響と貢献は、次期バージョンの重点事項を決める指針となりました。リリース以来、コントリビューターによって拡張機能の提案（型付き関係エッジ、エージェント ルーティング ヒント フィールド、オプションの消去適合性プロファイル、.okfignore 規則など）が作成され、新しいサンプル バンドルが提供されたほか、Google 以外で構築された OKF エコシステム ツールのカタログ化も始まりました。こうした貢献やフィードバックの多くは、OKF に関するある大きな懸念を示していました。それは「エージェントによるコーパスへの書き込みは本当に信頼できるのか」という点です。

最も価値のある OKF バンドルは、一度手作業で作成して、その後は読み取られるだけというものではありません。エージェントによって継続的に書き込まれ、また別の一連のエージェントによって使用されるものです。人間が作成した Wiki ページには、暗黙の保証が伴います。それは、人間が書いたものであり、誤りがあった場合は執筆者に責任を問えるという点です。エージェントが一晩で 1 万個のコンセプトを生成する場合、その保証はありません。説明責任を確保するため、コンシューマ（多くの場合、別のエージェント）は、人間に頼る代わりに明示的なシグナルに基づいて各コンセプトを判断し、次の 5 つの質問に答える必要があります。

1. 何をもとに作成されたのか？（来歴）

2. どの程度信頼できるか？（信頼）

3. この内容は今でも有効か？（鮮度）

4. 最新のバージョンか？（ライフサイクル）

5. この数値は指定した方法で生成されたものか？（証明）

OKF v0.2 では、形式は v0.1 と同様に設計上の制約は最小限に抑えながら、フロントマターの情報だけで上の 5 つの質問すべてに回答できるようになりました。追加されるのはルールではなく語彙です。type が唯一の必須フィールドである点は変わらず、新しく追加されたフィールドはすべて任意となります。カスタムキーも拒否されず保持されるため、新しいフィールドを一切使わないバンドルも v0.1 のときと同様に有効なものとして扱われます。新機能のフィールドはすべて任意ですが、フィールドが存在しないこと自体も意味（未検証であること）を持つようになります。これにより、未検証と検証済みのコンセプトを識別できるようになりますが、未検証だからといってエラーとして扱われることはありません。                    

説明から意思決定まで

v0.1 では、type、title、description、resource、tags といったメタデータがすでにフロントマターに含まれていました。従来のフィールドがコンセプト（それが何であるか、何を指しているか）を説明するものであるのに対し、v0.2 では、コンセプトを読む前にそのコンセプトの妥当性を判断するための新たなフロントマター フィールドが追加されました。たとえば、誰が作成したか、検証済みか、まだ最新か、報告する値をどのように計算すべきかなどの情報がここに含まれます。

これらのフィールドがフロントマターに含まれているのは、コンセプトとのやり取りのほとんどが本文の情報を読み込む手前の段階で終わるためです。コンシューマ（人間、決定論的コード、検索や探索の過程でスキャンを行うエージェントなど）は、まずそのコンセプトにそもそも関連性があるかどうかを判断しなければなりません。コンセプトのあらゆる要素は簡潔であるべきですが、フロントマターの役割はさらに限定的で、関連性と信頼性を判断するために必要なシグナルのみを的確に抽出することに絞り込まれています。そのため、説明文にトークンを費やすことなく、安価かつ頻繁に判断を下すことができます。全文を読み込む必要があるコンテンツは本文に格納され、コンセプトが選択された場合にのみアクセスされます。信頼性は、実際に読み込む前にフィルタリングできるものになります。

以降のセクションの内容を具体的にイメージしていただけるよう、ここからはこの投稿の補足として用意した acme_retail という小規模な OKF v0.2 バンドルから引用した例を使って説明していきます。acme_retail は、BigQuery で AI を活用して分析を行っている架空の米国小売企業の共有ナレッジです。

以降の各セクションは、対応するファイルの内容を示します。以下は新しいシグナルを伝えるコンセプトである tables/orders.md です。

各ファミリーは 5 つの質問の 1 つに回答します。

来歴: スコアではなくソースを記録

新しい sources フィールドは、コンセプトの派生元となる資料を記録します。外部ドキュメント、バンドル相対パスのほか、「プロジェクト X のすべてのクエリ」といった範囲も指定できます。同時に、各エントリは客観的な信頼性シグナル（author、usage_count、last_modified）を保持できます。

ここで意図的に行ったのは、あえて追加しないという選択です。OKF は信頼性スコアではなく、シグナルを記録します。スコアは主観的なものであり、コンシューマ間での汎用性に欠け、書き込まれた瞬間に古くなってしまいます。その代わりとなる信頼性は、コンシューマがシグナルから推測します（必要に応じて、コンシューマが動的にスコアを付けることもできます）。これは、「匿名ソースよりも、利用頻度が高く最近更新された信頼できるソースを優先する」という人間側の判断基準と同様の考え方です。本文で特定のソースを引用する際は、ソースの id（[^export-schema]）をキーとする通常の Markdown 脚注を使用します。このため、出典情報を最後にまとめてリスト化するのではなく、個々の主張に直接紐付けることができます。

信頼性: generated、verified

信頼性の確立には、意図的に区別された 2 つのフィールドを使用します。これは、作成者と確認者は別人であってもよいという考えに基づいています。

• generated: { by, at }: 現在のコンテンツがどのように生成されたか、および最後に実質的な変更が加えられたのはいつかを示します。

• verified: [ { by, at } ]: ソースまたは基盤となるリソースに対する独立した確認のリスト。人間の承認、夜間の財務プロセス、またはその両方を指します。

verified から、コンシューマは信頼性ティアを導き出します。verified キーがない場合は未確認、マシンアクターによる確認のみの場合はマシン確認済み、人間:<id> アクターによる確認の場合は人間によるレビュー済みとなります。ティアはアクセス制御ではなく、参考情報です。これにより、コンシューマは「経営幹部向けダッシュボードには人間によるレビュー済みの指標のみを表示する」といったフィルタリングをフロントマターで指定できるようになります。

acme_retail の例: metrics/revenue.md はリファレンス エージェントによって作成され、財務担当バイス プレジデントによって検証されるため、人間によるレビュー済みティアに分類されます。信頼性ティア フィルタが構成されたエグゼクティブ ダッシュボードのコンシューマは、その条件を満たすデータのみを抽出して表示します。一方、破棄前提のテスト環境では、下位ティアのコンセプトを取り込むことも可能です。

鮮度とライフサイクル: stale_after, status

OKF v0.2 では、stale_after フィールドと status フィールドを使用して鮮度とライフサイクルを定義します。status は、コンセプトを draft → stable → deprecated の順に遷移させます（指定がない場合は stable とみなされます）。stale_after は単一の絶対日付を指定します。相対的な TTL ではなくあえて絶対日付を採用したのは、コンセプトがいつ読み取られたかの情報に関係なく、単純な日付の比較だけで鮮度を判定できるようにするためです。こうした決定論的な動作は、LLM 以外のコンシューマにとってまさに必要とされるものです。

acme_retail の例: metrics/revenue.md と metrics/gross-margin.md の両方に stale_after: 2026-12-31 が指定されています。これは、Acme の財務チームが毎年 1 月に基本ポリシーを再承認することを踏まえた日付です。2027 年 1 月 1 日以降、これら 2 つのコンセプトをサービングするには、2027 年度のポリシーに照らした再検証が必要になります。

また、metrics/gross-margin-legacy.md は  status: deprecated とされています。Acme は 2026 年 2 月に費用配賦基準を変更しました（以前の計算式では、売上原価に配送費とフルフィルメント費が含まれていませんでした）。以前の定義は、過去のクエリの再現性を確保するために保持されますが、新しい作業で利用されることはありません。

証明: この数値は正規の手法で計算されたものか？

来歴は、その主張の出所を明らかにするものです。証明は、エージェントが金額を報告する際に重要となる、より踏み込んだ質問（この数字は指示された方法に沿って生成されたものなのか、それともエージェントが独自の SQL を即興で作成したのか）に答えるものです。

OKF v0.2 では、新しいコンセプト タイプである証明付きコンピューティングが導入されています。値の意味だけでなく、その値を計算する正規の計算手法と、その手法が実際に実行されたことを確認する手段が含まれています。acme_retail/computations/revenue-ytd.md の記述例を以下に示します。

エージェントは、宣言されたparameters を入力することはできますが、計算方法の作成や編集はできません。コンシューマは executor を介して計算を実行すると、receipt（ここでは BigQuery の job_id、実際に実行された SQL、結果）が返されます。次に、LLM を使用しない決定論的な attester がそのレシートを検査し、判定を返します。具体的には、実行されたクエリが指定のパラメータにバインドされた正規の計算方法と等しいか、そして表示された値はレシートの信頼できるソースと一致するか、という判定です。比較は機械的に行われるため、クエリの書き換え、計算ファイルの入れ替え、依存関係の変更があると、チェックは失敗します。

acme_retail の例: attesters/sql_equality.py の attester は、両方の SQL を正規化（コメントの削除、空白の集約、既知のキーワードの大文字化）し、正規化された形式が異なる場合は ok を返さないようにします。テーブル名の差し替え、フィルタの追加、JOIN の削除が行われると、いずれも証明に失敗します。判定結果が false の場合、コンシューマはその値を表示しません。

この例では BigQuery（および SQL）を使用しましたが、この抽象化の仕組みには意図的に柔軟性を持たせてあります。証明済みの計算方法は、セマンティック モデル（Looker、AtScale、その他のシステム）の呼び出し、構造化されたナレッジグラフへのクエリ、さらには任意の API 呼び出しなど、さまざまな処理に適用できます。

重要なのは、OKF は計算方法とその確認方法を記録するだけで、それ自体は何も実行しないということです。また、証明は検証とは異なります。verified は、定義がポリシーと一致していることを確認します（低速、ドキュメント レベル、バンドルに保存）。証明では、1 回の実行で値が正しく生成されたことを確認します（呼び出しごと、ランタイム、バンドルに保存されない）。定義が古くなっていても、証明自体は問題なく行われることがありますが、たとえ検証されたばかりの定義であっても、実行のたびに証明を行う必要があります。そのため、証明と検証の両方があります。

v0.2 の主な更新内容

v0.1 と同様、リファレンス実装は意図的に概念実証として提供されています。OKF を利用するうえで、これらの実装は必須要件ではありません。GitHub リポジトリの変更点は次のとおりです。

• reference_agent は、生成時に来歴と信頼ファミリーを出力するようになりました。これにより、新たに作成されたバンドルも生成ソースと引用が組み込まれた状態で提供されます。

• 静的ビジュアライザーには、コンセプト グラフとともに信頼性ティア、ステータス、鮮度が表示されるため、これらのシグナルを解析できるだけでなく、視覚的に把握できるようになります。

• アップデートされたサンプル バンドル（GA4 e コマース、Stack Overflow、Bitcoin、このブログ投稿で使用されている Acme Retail の例）には、v0.2 のフィールドが実装されています。

• Knowledge Catalog のデモでは、Google Cloud の Knowledge Catalog（旧称 Dataplex）を介したバンドルのラウンドトリップを紹介しています。ディスク上のクリーンな OKF が、カタログを経由して戻ってくる際も、信頼と来歴のシグナルがそのまま保持される様子を確認できます。

互換性

v0.2 は後方互換性を維持したマイナーアップデートですが、2 つのフィールド名が変更されています。timestamp は generated.at に置き換えられ、本文の # Citations リストは sources に置き換えられていますが、いずれも v0.2 のコンシューマは引き続き v0.1 の形式を利用できます。v0.1 のバンドルも、そのまま利用可能です。

次のステップ

仕様書は短くまとめられていますので、ぜひご一読ください。ソースシステムのトラスト シグナルを出力するプロデューサーを記述しましょう。さらに、それらをフィルタリングするコンシューマを記述します。ご自身の財務定義を使って、証明付きコンピューティングをお試しください。問題の報告、PR の送信、拡張機能のご提案をお待ちしております。共通言語の価値は、それを利用するコミュニティの広がりによって高まります。v0.2 では、その言語を通じて互いの情報を検証し合うこともできるようになりました。

OKF v0.2 の仕様、サンプル、リファレンス実装: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf

- データクラウド、エンジニアリング、データ分析担当テクニカル リーダー、Sam McVeety

- データクラウド、エンジニアリング、BigQuery 担当テクニカル リーダー、Amir Hormati