AIエージェントに「知識の置き場」を与える──Google Open Knowledge Formatという発想

Posted on by

「その情報、エージェントは知らない」問題

2026年6月、Google Cloudが「Open Knowledge Format（OKF）」という仕様を公開しました。

ビッグニュースというほど派手な発表ではありません。むしろ地味です。しかし、AIエージェントを実際に使い始めた人ほど「これ、本質だ」と感じる内容です。

この記事では、OKFが何を解決しようとしているのか、そしてその発想が私たちの実践とどう重なるのかを整理します。技術の話ですが、構成としては「あるある」です。

OKFが解決しようとしている問題

AIエージェント（コードを書いたり、データを分析したり、問い合わせに答えたりするAI）が正確な結果を出すには、モデル自体の性能だけでなく、適切なコンテキスト（背景知識）が必要です。

このコンテキストが今、ひどく断片化しています。

  • テーブルスキーマはメタデータカタログに
  • ビジネス指標の定義は社内Wikiに
  • インシデント対応手順は共有ドライブのPDFに
  • 2つのシステムの結合パスはシニアエンジニアの頭の中に

エージェントが「今週のアクティブユーザー数を計算して」と聞かれたとき、これらの断片を組み立てる必要があります。各ベンダーは独自のカタログ、独自のSDK、独自のナレッジグラフを持っています。知識はツールごとにサイロ化され、移植性はゼロです。

これは、私がAIエージェント（Hermes Agent「タダシ」）と仕事を始めて最初にぶつかった壁と同じです。

OKFの答えは「MarkdownとYAMLとファイル」だけ

OKFの仕様は驚くほどシンプルです。

Markdownファイル＋YAMLフロントマターを、ディレクトリに並べるだけ。

“`yaml
—
type: dataset
title: “GA4 eコマースイベント”
description: “Google Analytics 4のeコマース系イベント一覧”
tags: [ga4, analytics, ecommerce]
—
“`

各ファイルが1つの「コンセプト」（テーブル、指標、ランブック、APIなど）を表します。ファイルパスがそのコンセプトのIDです。相互リンクは通常のMarkdownリンクで行います。階層ナビゲーションには `index.md`、変更履歴には `log.md` を置くことができます。

SDK不要、新しいランタイム不要、ベンダーロックインなし。

特定のクラウド、データベース、モデルプロバイダーに依存しません。人間が読めてエージェントが解析できる。ただのファイルです。

「これ、うちでもやってる」

OKFの記事を読んで、私はこう思いました。

「これ、もうやっている」

違う意味ではありません。文字通りの意味で、同じ設計パターンがすでに稼働しています。

Hermes Agent「タダシ」は、Markdown＋YAMLフロントマターの知識ベースを毎日3時間おきの自動保存、日次のナレッジ統合、整合性検証、オーファン検出、アーカイブポリシーという形で実運用しています。いわばOKFの先行実装のひとつです。

機能OKF v0.1の定義タダシの実装状況
Markdown知識基盤要件実現済み
YAMLメタデータtypeのみ必須5項目必須（より厳格）
1ファイル1コンセプト推奨ルール化済み
index.md（階層ナビ）オプション自動生成＋必須運用
log.md（変更履歴）オプション追記専用で必須運用
自動Producer拡充エージェント（例）cron自動保存・日次統合・取込パイプライン
Consumer任意のエージェントHermes Agent
整合性検証なし独自検証スクリプトで実現済み

重要なのは、「Googleが新しく何かを発明した」わけではないという点です。Andrej Karpathy氏が「LLM Wiki」として提唱したパターン（エージェントが読み書きするMarkdownライブラリ）を、組織間で相互運用可能なオープン形式として標準化したのがOKFです。

だからこそ、同じ発想に自力でたどり着いた人が多くいる。そしてその事実こそが、このパターンの普遍性を証明しています。

この発想がビジネスにとって意味すること

「Markdownをディレクトリに並べる」というシンプルな仕様に、どんな価値があるのでしょうか。

1. 知識の陳腐化を防げる

エージェントが自ら知識ベースを読み書きするので、人間が「マニュアルを更新しなければ」と気づくよりも早く、情報が最新に保たれます。エージェントは飽きず、相互参照の更新を忘れず、一度に15個のファイルを更新できます。

2. ツールに依存しない

Notionでも、Obsidianでも、VS Codeのフォルダでも、GitHubでも。Markdownを置ける場所ならどこでもナレッジベースになります。「このツールじゃないと使えない」という縛りがない。

3. 人間とAIが同じ情報を見られる

人間はObsidianやVS Codeで読み、エージェントはREST APIやファイルシステムから読む。同じMarkdownファイルです。変換レイヤーは不要です。

技術選定のヒント：シンプルなものを選べ

OKFが示唆しているのは、「AIエージェントのための知識基盤」として最も効くのは、高機能なナレッジグラフツールや専用プラットフォームではなく、Markdownという最もシンプルな形式だということです。

新しいプロダクトを導入する前に、今あるファイルを整理することから始めてみてください。それだけで十分な土台になります。

まとめ

Google CloudのOpen Knowledge Formatは、AIエージェントが知識を読み書きするための「共通言語」を定義したものです。その設計は驚くほどシンプルで、MarkdownとYAMLフロントマターをディレクトリに並べるだけです。

この発想自体は新しいものではなく、すでに多くの実践者が同じパターンにたどり着いています。OKFの価値は、それをオープンな標準として定義し、ツールや組織を超えた相互運用性を持たせた点にあります。

「AIエージェントにどう知識を与えるか」。まだ答えが出ていない人は、まずはMarkdownファイルを1つ、書いてみてください。それがすべての始まりです。

Photo by Pavel Danilyuk from Pexels