OKF(Open Knowledge Format) ― AIに渡す知識をMarkdownで整理する新しい方法
はじめに
最近、AIに社内文書や業務知識を読ませて活用する場面が増えてきました。
ところが、実際にやってみると、次のような問題が起こります。
- 情報がPDF、Wiki、Excel、ソースコードなどに分散している
- AIが、どの文書を根拠に回答したのか分かりにくい
- 古い手順書を、最新情報として使ってしまう
- AIが作った説明と、人が確認した説明を区別できない
- AIツールを変更すると、知識を登録し直す必要がある
こうした問題への一つのアプローチとして登場したのが、OKF(Open Knowledge Format) です。
この記事では、OKFとは何か、なぜAIと相性がよいのか、RAGやMCPとは何が違うのかを、できるだけ難しい言葉を使わずに説明します。
最後に、大量のPDFをOKFで整理する方法と、その作業をAIに依頼するときの指示文も紹介します。
この記事は、2026年9月時点で公開されているOKF v0.2の仕様をもとにしています。OKFは新しい仕様なので、今後変更される可能性があります。
OKFとは
OKFは、Open Knowledge Format(オープン・ナレッジ・フォーマット) の略です。
ひと言で表すと、次のようになります。
人やAIが利用する知識を、Markdownファイルとして整理するための共通ルール
Google Cloudのチームが2026年6月に公開したオープンな仕様で、特定のAI製品やクラウドに依存しないことを目指しています。
ただし、OKFはAIモデルでも、検索エンジンでも、データベースでもありません。あくまで、知識をどのような形で保存するかを決めるフォーマットです。
中身はMarkdownとYAML
OKFの仕組みは、とてもシンプルです。
基本的には、次の2つを組み合わせます。
- 本文:Markdown
- 文書の種類や出典などの情報:YAML frontmatter
例えば、ある用語の説明をOKFで表すと、次のようになります。
---
type: Concept
title: リグレッションテスト
description: 変更によって既存機能が壊れていないことを確認するテスト
tags: [software-testing, regression]
status: stable
generated:
by: human:mame-kun
at: 2026-09-23T00:00:00Z
sources:
- id: testing-guide
resource: ../references/testing-guide.pdf
title: ソフトウェアテストガイド
---
# リグレッションテストとは
ソフトウェアを変更したときに、これまで正常に動作していた機能が
壊れていないことを確認するテストです。
---で囲まれた部分がYAML frontmatterです。
その下は、普通のMarkdownとして書けます。そのため、特別な編集ソフトがなくても読んだり修正したりできます。
OKF v0.2では、通常の知識ファイルで必須なのは基本的にtypeだけです。ほかの項目は必要に応じて追加します。
OKFのフォルダ構成
OKFでは、複数のMarkdownファイルをフォルダにまとめたものをKnowledge Bundle(ナレッジバンドル) と呼びます。
例えば、ソフトウェア開発の知識を次のように整理できます。
software-knowledge/
├── index.md
├── concepts/
│ ├── regression-test.md
│ └── boundary-value-analysis.md
├── howto/
│ └── review-pull-request.md
├── decisions/
│ └── select-test-framework.md
└── references/
└── testing-guide.pdf
index.mdは目次の役割を持ちます。OKF v0.2では必須ではありませんが、AIが最初に全体像を把握できるため、実際の運用では作成しておくと便利です。
AIは最初にindex.mdを読み、必要なファイルだけを追加で読み込めます。すべての文書を最初から読み込ませる必要がなくなるので、扱う知識が多い場合にも役立ちます。
なぜAIと相性がよいのか
1. AIが文書の役割を判断しやすい
すべての文書にtypeが付いているため、AIはその文書が何を表しているのかを判断しやすくなります。
例えば、次のような種類を付けられます。
-
Concept:用語や考え方 -
How-to:作業手順 -
Reference:参照情報 -
Decision:設計や運用上の決定 -
Metric:指標の定義 -
API Endpoint:APIの説明
種類の名前は固定されていません。利用する組織やプロジェクトに合わせて決められます。
2. 出典を記録できる
sourcesには、その知識がどこから作られたのかを記録できます。
sources:
- id: user-manual
resource: ../references/user-manual.pdf
title: 製品ユーザーマニュアル
AIが回答するときに出典を確認できるため、「この説明は何を根拠にしているのか」を追跡しやすくなります。
ただし、出典を記録しただけで内容が正しいと保証されるわけではありません。元の文書と内容が一致しているかを確認する仕組みは別途必要です。
3. AI生成と人による確認を分けられる
OKF v0.2では、generatedとverifiedを分けて記録できます。
generated:
by: document-agent/model-name
at: 2026-09-23T00:00:00Z
verified:
by: human:mame-kun
at: 2026-09-24T03:00:00Z
-
generated:誰または何が内容を作ったか -
verified:誰または何が内容を確認したか
この区別は大切です。
AIが作成した文書に、最初から「人が確認済み」と記録してはいけません。人が確認していない文書にはverifiedを付けず、未検証の知識として扱います。
4. 古くなった知識を見つけやすい
stale_afterを使うと、その知識をいつ再確認すべきか記録できます。
stale_after: 2027-03-31T00:00:00Z
期限を過ぎた情報をAIが使う場合に、警告を出すといった運用ができます。
5. Gitで変更を管理できる
OKFの実体はテキストファイルなので、Gitとの相性がよい形式です。
- 誰が変更したか
- どこが変更されたか
- いつ変更されたか
- レビューで承認されたか
といった履歴を、ソースコードと同じように管理できます。
6. AI製品を変更しても再利用しやすい
OKFはMarkdownとYAMLで構成されています。そのため、Claude、ChatGPT、Codex、Gemini、GitHub Copilotなど、Markdownを読めるさまざまなAIで利用できます。
特定製品の専用形式だけで知識を保存する場合と比べて、別のAIへ移行しやすい点が利点です。
RAG、MCP、Agent Skillsとの違い
OKFの話では、RAGやMCPなどの言葉も一緒に出てくることがあります。それぞれの役割は異なります。
| 技術 | 主な役割 |
|---|---|
| OKF | 知識をどの形式で保存するかを決める |
| RAG | 質問に関係する情報を検索してAIへ渡す |
| MCP | AIと外部のデータやツールを接続する |
| Agent Skills | AIに作業手順や専門的な進め方を教える |
たとえるなら、次のように考えられます。
- OKFは、図書館に置く本の書き方と整理方法
- RAGは、質問に合う本やページを探す司書
- MCPは、外部の図書館へ接続する窓口
- Agent Skillsは、司書に渡す作業マニュアル
OKFとRAGは競合するものではなく、組み合わせて利用できます。
OKFを使えばAIの回答は正しくなるのか
残念ながら、OKFを導入しただけでAIの回答が正しくなるわけではありません。
OKFによって改善できるのは、主に次の点です。
- 知識の置き場所
- 文書の種類
- 出典
- 作成者と確認者
- 情報の有効期限
- 文書同士のリンク
一方、次の問題は別途対策が必要です。
- PDFから情報を抜き出すときの読み取り間違い
- AIによる要約の誤り
- 元文書自体の誤り
- 機密情報に対するアクセス制御
- 大量文書を検索する仕組み
- 組織内で使う用語や
typeの統一
OKFは「正しさを自動的に保証する仕組み」ではなく、知識を確認・更新・追跡しやすくするための土台と考えるのがよさそうです。
また、OKFは公開されたばかりの新しい仕様です。2026年9月時点の公式GitHub仕様はv0.2であり、今後も変更される可能性があります。最初から全社で導入するより、小さな範囲で試して効果を確認するのが安全です。
大量のPDFをOKFで整理するには
ここからは、数百ページあるマニュアルや、多数のPDFをOKFとして整理する場合を考えます。
大切なのは、PDFを丸ごと1つの巨大なMarkdownへ変換しないことです。
AIが扱いやすいように、内容を「一つの意味を持つ知識」に分けます。
例えば、製品マニュアルなら次の単位が考えられます。
- 概念や用語
- 機能の説明
- 操作手順
- 設定項目
- 制約事項
- エラーと対処方法
- FAQ
- 設計上の決定
おすすめの整理手順
1. 原本PDFをそのまま保存する
OKFへ変換した後も、原本PDFは削除しません。MarkdownはAIが利用しやすい整理済み知識、PDFは正しさを確認するための原本として扱います。
product-knowledge/
├── index.md
├── concepts/
├── howto/
├── troubleshooting/
└── references/
├── user-manual.pdf
└── administrator-guide.pdf
2. PDFごとに目次と構造を抽出する
最初から本文をすべて変換せず、まず章、節、見出し、ページ番号を一覧にします。
この一覧を使って、どこを一つの知識ファイルにするか決めます。
3. 章ではなく、知識の単位で分割する
一つの章に「概要」「設定方法」「注意事項」「エラー対応」が含まれている場合は、それぞれを別ファイルにします。
反対に、数ページにまたがって一つの操作を説明している場合は、一つのHow-toとしてまとめます。
4. すべての知識に出典を付ける
最低でも、次の情報を記録します。
- 原本PDFのファイル名
- 対象ページ
- 見出しまたは節番号
- 抽出日時
- 抽出したAIまたはツール
ページ番号や節番号はOKFの必須項目ではないため、独自項目として追加できます。
sources:
- id: admin-guide
resource: ../references/administrator-guide.pdf
title: 管理者ガイド
page: 42
section: 3.2.1
5. AIが作った文書は未検証として保存する
AIが作成した時点ではverifiedを付けません。内容を人または検証プログラムが確認した後に、確認者と日時を追加します。
6. 最後にindex.mdを作る
すべての知識ファイルへのリンクと短い説明をindex.mdへまとめます。
AIはindex.mdから必要な情報だけを探せるようになります。
PDFの整理をAIに依頼する指示文
大量のPDFを一度の指示ですべて変換させると、内容の抜け、出典ページのずれ、ファイル間の重複が起こりやすくなります。
そのため、実際には次の順番で実行するのがおすすめです。
- PDFの一覧と目次を抽出する
- 分割案を作る
- 人が分割案を確認する
- OKFファイルを生成する
- 原文との一致を検証する
-
index.mdを生成する
以下は、AIに渡せる指示文の例です。利用するAIがファイルの読み書きに対応していることを前提としています。
添付または指定されたPDF文書を読み取り、Open Knowledge Format(OKF)v0.2に沿った
Knowledge Bundleとして整理してください。
## 目的
PDFの内容を、人とAIの両方が検索・確認・再利用しやすいMarkdownファイルへ整理します。
原文にない情報は追加せず、すべての知識から出典を追跡できるようにしてください。
## 作業手順
次の手順を順番に実行してください。
1. 対象PDFのファイル名、総ページ数、目次、章、節、見出しを一覧化する。
2. 内容を次のような知識単位へ分割する案を作る。
- Concept:用語、概念、機能の説明
- How-to:操作手順、設定手順
- Reference:設定値、仕様、一覧表
- Troubleshooting:エラー、原因、対処方法
- Decision:文書に明記された方針や決定
3. 分割案を先に提示する。この段階ではOKFファイルを生成しない。
4. 分割案の承認後、知識単位ごとに1つのMarkdownファイルを生成する。
5. 生成内容を原文と照合し、不一致、判断不能、文字認識が不鮮明な箇所を報告する。
6. 最後に、全ファイルへのリンクと説明を持つindex.mdを生成する。
## 出力規則
- OKFの対象バージョンは0.2とする。
- 通常の知識ファイルには、必ずYAML frontmatterと空でないtypeを付ける。
- title、description、status、generated、sources、tagsを可能な範囲で付ける。
- AIが生成した文書のstatusは、原則としてdraftにする。
- generated.byには、実際に使用したAIまたはツール名を記録する。
- generated.atには、実際の生成日時をISO 8601形式で記録する。
- 人が確認していない文書にはverifiedを付けない。
- sourcesには、原本PDFのファイル名、ページ番号、節番号または見出しを記録する。
- 原文に書かれていない説明、数値、手順、判断を追加しない。
- 内容を推測した場合は本文へ混ぜず、「確認が必要な事項」として別に報告する。
- 表は、意味を壊さない範囲でMarkdown表へ変換する。
- 図だけで説明されている内容は推測せず、図のページと確認が必要な点を記録する。
- 同じ内容を複数ファイルへ重複して書かず、Markdownリンクで関連付ける。
- ファイル名は英小文字とハイフンを使い、内容が分かる名前にする。
- 原本PDFはreferencesフォルダに残し、生成したMarkdownから参照する。
## 推奨フォルダ構成
knowledge-bundle/
├── index.md
├── concepts/
├── howto/
├── reference/
├── troubleshooting/
├── decisions/
└── references/
## 検証結果
生成後、次の項目を確認して結果を報告してください。
- すべての知識ファイルにtypeがあるか
- すべての知識に出典PDFとページ番号があるか
- 存在しない出典やリンクがないか
- 原文にない情報を追加していないか
- 同じ知識が重複していないか
- 未確認の文書にverifiedを付けていないか
- 読み取れなかったページや表、図がないか
まずはPDF全体の構造と、OKFファイルへの分割案だけを提示してください。
私が承認するまで、ファイル生成へ進まないでください。
ポイントは、いきなり全部作らせず、最初に分割案だけを出させることです。
また、「原文にない情報を追加しない」「出典ページを必ず付ける」「AI生成時点ではverifiedを付けない」という条件を明記すると、後で確認しやすくなります。
まとめ
OKFは、AIが利用する知識をMarkdownとYAMLで整理するための、シンプルなオープン仕様です。
主な特徴は次のとおりです。
- 人にもAIにも読みやすい
- 特定のAI製品に依存しにくい
- 出典、生成者、確認者、鮮度を記録できる
- Gitで差分や履歴を管理できる
- RAGやAIエージェントの知識源として利用できる
一方で、OKFは情報の正しさを自動的に保証するものではありません。AIによる抽出結果の検証、アクセス制御、検索の仕組み、組織内の命名規則などは別途必要です。
まだ新しい仕様なので、まずは少数の文書を使って試し、どの単位で知識を分割すると使いやすいかを確認するのがよいでしょう。