結論: OKF は「AI が読める知識」の共通フォーマット

結論から言うと、OKF (Open Knowledge Format) は、AI エージェントが組織の知識を読むための共通フォーマットです。中身は Markdown と YAML frontmatter という、エンジニアには馴染みのある組み合わせで、2026 年 6 月に Google Cloud が初期版 v0.1 を公開しました (Impress Watch の報道)。

なぜこれが注目されるのか。AI エージェントを業務に組み込もうとすると、必ず「エージェントに何を知らせるか」という知識の問題にぶつかります。これまでは、その知識の持ち方に決まった形がなく、ベンダーごとに独自のスキーマへ変換する手間がかかっていました。OKF は、その知識の書き方をベンダー中立で標準化しようという試みです。

本記事では、OKF が何を解決しようとしているのか、技術的な中身、そして MCP や RAG といった既存の仕組みとの位置づけを、現場目線で整理します。

何が公開されたのか

2026 年 6 月、Google Cloud は OKF v0.1 を GitHub で公開しました。公開されたのは仕様 (spec) だけではありません。実際に動かして理解できるよう、サンプルと参照実装も一緒に提供されています。

  • 3 つのサンプルバンドル (GA4 の e コマース、Stack Overflow、Bitcoin のデータセット)
  • 参照実装 (知識を補強するエンリッチメントエージェント、静的 HTML のビジュアライザー)
  • Google Cloud の Knowledge Catalog を OKF 取り込みに対応させる連携

バージョンが v0.1 であることからも分かるとおり、現時点ではプレリリースの位置づけです。仕様を固めながら、実装とサンプルで使い勝手を確かめていく段階だと捉えるのが正確です。

OKF の中身 — Markdown + frontmatter

OKF の構造はシンプルです。知識を表す概念を、1 つずつ Markdown ファイルとして書きます。各ファイルの先頭に YAML frontmatter でメタデータを付け、本文に説明を書く。この形式は、技術ブログや本サイトの記事管理でも広く使われている、ごく一般的なものです。

frontmatter で必須とされるフィールドは type ひとつだけです。その概念が何の種別かを示します。残りはすべて任意で、title・description・resource・tags・タイムスタンプなどを、その概念で表したい情報に合わせて付けます。

---
type: metric
title: 月間アクティブユーザー数
description: 一定期間に 1 回以上利用したユニークユーザーの数
tags: [analytics, kpi]
---
定義の本文をここに書く。関連する概念には
[セッション数](./session-count.md) のように標準の Markdown リンクで参照する。

ファイルはディレクトリにまとめて「バンドル」として扱い、概念どうしを標準の Markdown リンクでつなぎます。リンクで参照し合うことで、全体がひとつの知識グラフを形成します。特別なビューワーは要りません。普通のエディタで読み書きでき、GitHub 上ではそのままレンダリングされ、検索ツールでインデックスもできます。

補足

OKF の発想は新しく発明されたものではありません。Andrej Karpathy が広めた「LLM 向けの wiki」のように、Markdown で知識をまとめる手法は既にありました。OKF はそれを、特定のツールに閉じない相互運用可能な形式として整理し直したものと捉えると分かりやすいです。

人が読める形のまま、AI も読める。この「人と AI が同じファイルを共有する」点が、OKF の設計で一番の狙いです。知識を AI 専用のバイナリやベクトルに変換してしまうと、人がメンテナンスできなくなります。プレーンテキストに留めることで、編集とレビューを人の手に残しています。

既存の仕組みとの位置づけ — MCP・RAG・llms.txt との違い

OKF を理解するうえで混乱しやすいのが、MCP や RAG との関係です。結論から言うと、これらは競合しません。層が違うからです。

flowchart LR
  OKF["OKF<br/>知識の記述形式"] --> RAG["RAG<br/>検索して文脈に入れる"]
  RAG --> AGENT["AI エージェント"]
  MCP["MCP<br/>ツールやデータをつなぐ配管"] --> AGENT
  LLMS["llms.txt<br/>公開サイトの案内"] -.-> AGENT

それぞれの役割を並べると、違いがはっきりします。

仕組み役割OKF との関係
OKF知識そのものを人にも AI にも読める形で記述本記事の主役
RAG知識を検索して AI の文脈に入れる手法OKF が検索対象になる
MCPエージェントとツール・データをつなぐ接続OKF の知識を運ぶ配管側
llms.txt公開 Web サイトを LLM に案内するファイル公開向け、OKF は組織内向け

たとえば、OKF で構造化した知識を RAG で検索して文脈に入れ、MCP 経由でエージェントが外部ツールと連携する、という組み合わせが自然です。よく整理された OKF バンドルがあれば、RAG の検索精度も上がりやすくなります。OKF は「接続」でも「検索」でも「公開サイトの案内」でもなく、それらが扱う知識の中身を記述する形式だと位置づけると、全体像が整理できます。

RAG の構築そのものは RAG 構築の実践ガイド、MCP サーバーの作り方は MCP サーバー構築ガイド でそれぞれ扱っています。

実務で今どう向き合うか

最後に、では明日から何をすべきか、という観点で整理します。判断の軸は「v0.1 という段階をどう捉えるか」です。

FIXITFIXIT

新しい標準が出たって聞くと、すぐ乗り換えたほうがいいの？

HayateHayate

乗り換えは急がなくていいです。まだ v0.1 なので、いま全面採用はコスパが悪いです。

FIXITFIXIT
じゃあ、様子見でいいってこと？
HayateHayate

形式に乗るのは後でいいです。知識をテキストで構造化する習慣だけ、先に作るほうが速いです。

OKF はまだプレリリースで、仕様は今後変わり得ます。この段階で社内の全知識を OKF へ移すのは、仕様変更のたびに作り直すリスクがあり、現実的ではありません。形式そのものの全面採用は、標準が固まるのを待ってよいと考えます。

一方で、「業務知識を Markdown と frontmatter で構造化テキストとして持つ」という方向性は、OKF に乗るかどうかに関わらず筋が良い投資です。AI エージェントを業務に組み込む流れは続くため、知識がスプレッドシートや画像つきの文書に閉じ込められていると、いずれ整形のコストがかかります。更新頻度が高く価値の高い知識から、プレーンな Markdown で構造化しておけば、OKF のような標準が固まったときに移行しやすくなります。

逆に言えば、急ぐべきは形式の移行ではなく、知識を人にも AI にも読める形で書き残す習慣づくりです。FIXIT も AI 駆動開発のクリエイティブスタジオとして、プロジェクトの知識を Markdown と frontmatter で構造化し、AI エージェントに読ませる運用を日常的に続けています。その実感としても、OKF が向かう方向には同じ手応えを感じています。

まとめ

OKF (Open Knowledge Format) は、AI エージェントが組織の知識を読むための、Markdown と YAML frontmatter による共通フォーマットです。2026 年 6 月に Google Cloud が v0.1 を公開しました。必須フィールドは type だけで、ディレクトリにまとめた Markdown ファイルを標準リンクで相互参照し、知識グラフとして構成します。人も AI も同じファイルを読めることが、設計の中心にあります。

MCP・RAG・llms.txt とは層が違い、OKF は知識そのものの記述形式として補完関係にあります。現状は v0.1 のプレリリースなので、全面採用を急ぐより、社内知識を構造化テキストで持つ習慣を先に作るのが現実的です。

AI エージェントを自社の業務に組み込む進め方や、社内知識の構造化からの相談は お問い合わせ から承っています。