プロンプトと適用範囲
複数のエージェントがメトリクス定義、ランブック、テーブルスキーマを継続的に生成しています。ソース、生成者、検証者、有効期限、計算の証拠を記録しつつ、v0.1 のコンシューマーからも読み取り可能な OKF v0.2 ナレッジカタログを設計してください。
Google Cloud は 2026年7月に OKF v0.2 を導入しました。Open Knowledge Format は、人間やエージェントによって維持されるナレッジのために Markdown ファイルと YAML frontmatter を使用します。バージョン 0.2 では、追加的かつ後方互換性を保ちながら、出所、信頼性、ライフサイクル、証明をクエリ可能にします。これはデータフォーマットおよびガバナンスの規約であり、一元化されたランタイムやアクセス制御システムではありません。
面接官が評価するポイント
面接官は、誰がコンテンツを生成し、誰が検証したかの明確な分離、安定したソース ID による主張ごとの帰属（per-claim attribution）、実行可能な鮮度およびライフサイクルのフィルタリング、そして信頼ティア（trust tiers）は認可ではなくコンシューマー側で導出される助言的シグナルであるという理解を求めています。また、v0.1 のフォールバック、冪等な書き込み、移行、敵対的コンテンツ、計算証明の検証境界についても網羅する必要があります。
回答前の明確化のための質問
- どのプロデューサーがバンドルに書き込み、最終的な人間によるレビューは誰が担当しますか？
- コンシューマーは未検証、陳腐化、非推奨のものをフィルタリングする必要がありますか、それとも選択された信頼ティアのみを対象としますか？
sourcesは外部 URL、バンドル相対パス、スコープ記述子をサポートすべきですか？- 証明された計算を支える実行環境、入力バージョン、再計算リソースは何ですか？
- v0.1 のコンシューマーは古いフィールドのみを読み取れればよいですか、それとも移行警告を受け取る必要がありますか？
30秒の回答フレームワーク
「私は OKF ファイルをバージョン管理されたナレッジファクトとして扱い、生成、検証、インデックス作成、消費を分離します。各コンセプトにはソース、生成者と時間、独立した検証記録、ステータス、有効期限を記録し、主張には安定した sources[].id による帰属を用います。コンシューマーは本文を読む前に、ステータス、信頼ティア、鮮度で frontmatter をフィルタリングします。すべての v0.2 の追加機能はオプションであり、リーダーは未知のキーを保持し、timestamp から generated.at へ、また古い引用規則から sources へとフォールバックします。信頼ティアはコンシューマーによって導出され、認可としては使用されません。計算の証拠は入力、コード、再現可能な証明を結びつけます。」
ステップごとの詳細解説
1. 最小構成のコンセプトファイルを設計する
type、タイトル、説明、リソース、タグなどの基本フィールドを持つ、保守可能な1つのコンセプトを1ファイルに保持します。インデックス作成およびフィルタリング可能なメタデータを frontmatter に配置し、説明、スキーマ、サンプルクエリを本文に配置します。Git 内のディレクトリにより、実行時の中央レジストリを必要とせずに変更レビューとロールバックが可能になります。
2. ソースと主張ごとの帰属を確立する
sources は、コンセプトの派生元である外部ドキュメント、バンドル相対パス、またはスコープ記述子を、作成者、使用回数、最終更新日時などの客観的なシグナルとともに記録します。本文の主張には、位置に依存する sources[0] ではなく安定したソース ID に紐づく脚注を使用します。これにより、並べ替えによって主張の帰属がサイレントに誤認されるのを防ぎ、コンシューマーはローカルで信頼性を計算できます。
3. 生成と検証を分離する
generated は誰が現在のコンテンツをいつ生成したかを示し、verified は誰がソースやリソースに対してそれをいつ確認したかを示します。verified が存在しない場合は未検証（unverified）を意味し、機械のみの確認では machine-confirmed、人間の検証者による確認では human-reviewed が得られます。これらのティアはコンシューマーによって導出される助言的シグナルであり、直接的な認可やコンプライアンスの決定ではありません。
4. 鮮度とライフサイクルを管理する
stable、draft、deprecated などのライフサイクル状態には status を使用し、レビュー期限には stale_after または同等の日時を使用します。インデクサーは現在時刻、ソースの更新、ビジネスポリシーを組み合わせて鮮度を計算します。陳腐化（stale）していることは虚偽であることを意味しません。非表示にするか、ランクを下げるか、再検証するかはコンシューマーが決定し、その理由を記録します。
source -> generated -> verified -> trust tier
-> status/stale_after -> consumer filter -> body read5. 証明された計算を処理する
メトリクスや計算された主張については、定義、入力リソースのバージョン、実行者、実行時間、検証結果を記録します。証明（attestation）は、値が宣言された方法によって生成されたことを証明するものであり、入力やビジネス上の解釈が正しいことを証明するものではありません。OKF は実行環境やパッケージングを規定しないため、ガバナンスによって環境、依存関係、再生証拠を固定する必要があります。
6. v0.1 互換性を維持する
バージョン 0.2 は追加的で後方互換性のあるマイナーバージョンです。新しいフィールドを採用しない v0.1 バンドルも引き続き有効です。リーダーはカスタムキーや未知のキーを保持し、generated.at を優先しつつ古い timestamp にフォールバックし、sources が存在しない場合は移行警告を発行しながら古い # Citations 規則を読み取ることができます。ライターは履歴をサイレントに書き換えるのではなく、バージョン管理された移行を提供すべきです。
7. 信頼性の高い消費パイプラインを構築する
プロデューサーがファイルをコミットし、バリデーターが frontmatter、ソース ID、タイムスタンプをチェックし、検証者が独立した確認を書き込み、インデクサーがフィルターフィールドをマテリアライズし、コンシューマーが本文を読み込む前にフィルタリングします。冪等性のためにコンセプト ID とコンテンツハッシュを使用し、反復生成にはレビューキューを使用します。リモートリンク、Markdown、脚注、エージェント生成コンテンツはエスケープおよび許可リスト化し、監査ログを保持します。
高品質な回答例
私は OKF バンドルを Git 内のレビュー可能なナレッジファクトとして扱います。各ファイルには1つのコンセプトが含まれ、frontmatter にフィルタリング可能なメタデータ、本文に説明を記述します。sources には安定した ID があり、本文の脚注が個々の主張に帰属します。generated と verified はプロデューサーと確認者を個別に記録し、コンシューマーはこれらを認可として扱うことなく unverified、machine-confirmed、human-reviewed のティアを導出します。status と stale_after はライフサイクルと鮮度のフィルタリングを推進し、陳腐化したコンセプトはランクを下げたりレビューに送ったりできます。計算された主張には入力バージョン、実行環境、メソッド、証拠が付与されますが、証明は入力の正しさを証明するものではないという明示的な制限が伴います。v0.2 リーダーは未知のキーを保持し、generated.at から timestamp へのフォールバック、および sources から古い引用規則へのフォールバックをサポートし、v0.1 互換性のための移行警告を発行します。冪等なコミット、ハッシュ、レビューキュー、安全なレンダリングにより、生成、検証、インデックス作成、消費が明確に分離されます。
よくある間違い
- 生成者と検証者を統合する → 独立した確認が失われる →
generatedとverifiedを個別に記録する。 - 信頼ティアを権限として使用する → 助言的シグナルがセキュリティ制御になってしまう → 認可は ID、ポリシー、リソースシステム側に保持する。
- 帰属に
sources[0]を使用する → リストの並べ替えにより主張の帰属が誤認される → 安定したソース ID と脚注キーを使用する。 - 陳腐化したものを虚偽として扱う → コンシューマーポリシーが大雑把になりすぎる → コンシューマーに非表示、ランク下げ、再検証を選択させる。
- 証明が真実を証明すると主張する → 入力やセマンティクスが無視される → 入力バージョン、メソッド、検証スコープを紐づける。
- 移行中に古いフィールドをサイレントに削除する → v0.1 コンシューマーが壊れる → フォールバック、警告、バージョン付き書き込みを使用する。
フォローアップの質問と回答
なぜフォーマット内で単一のユニバーサルな信頼スコアを定義しないのですか？
スコアはドメイン、コンシューマー、時間によって異なります。単一のスコアを保存すると陳腐化し、移植性が失われます。フォーマットは検証可能なシグナルを記録し、各コンシューマーが作成者、鮮度、検証、使用状況からローカルポリシーを導出します。
2つの独立した検証者が1つのコンセプトを確認した場合はどうなりますか？
対象と時間を記録した複数の verified レコードを保持します。コンシューマーは、以前の証拠を上書きすることなく、人間、機械、ドメイン、最新性のポリシーを組み合わせることができます。
stale_after の恣意的な延長をどのように防ぎますか？
変更可能な担当者を制限し、ソースまたはビジネスオーナーの承認を要求し、古い値、新しい値、理由、検証証拠を監査します。期限の更新はコンテンツのレビューではありません。
v0.1 のコンシューマーが新しいフィールドを理解できない場合はどうなりますか？
未知のフィールドを無視して基本フィールドの読み取りを継続する必要があります。互換性のある書き込み、古いフィールドへのフォールバック、移行警告を提供し、すべての古いバンドルで v0.2 拡張機能を必須にしないようにします。
エージェント生成メトリクスはどのようにして高信頼ティアに到達しますか？
生成元と計算の証拠を記録し、その後に入力、メソッド、結果を個別に検証します。人間によるレビューまたはビジネスプロセスが成功した後にのみ、コンシューマーはより高い信頼ティアを導出すべきです。