AI OKF活用入門　具体例を元にOKFを学びAI Ready Knowledge化を実現しよう

2026年7月6日 最終更新日時 : 2026年7月6日 fukayayuji

はじめに

AITCセンター長の深谷です。

前回のコラムでは、Googleが2026年6月13日に提唱したOpen Knowledge Format、略してOKFについて取り上げました。

AITC | AI TRANSFORMATION CENTER
OKF(Open Knowledge Format)とは？AI時代の「知識コンテナ」になるか
🕒️2026年6月22日

OKFは、AI時代において企業の知識をどのような形で整理し、AIや人が再利用できるようにするかを考えるうえで、非常に興味深いフォーマットです。Google Cloudの発表では、OKFは、現代のAIシステムが必要とするメタデータ、文脈、形式知化された知識を表現するための、ベンダーニュートラルで、人にもAIエージェントにも扱いやすいオープン仕様として説明されています。

以前の「AI Ready Data　生成AI活用のボトルネックはファイル形式にある」では、生成AIの回答品質はモデル性能だけでなく、AIに渡すデータの状態に大きく左右される、という話をしました。

AITC | AI TRANSFORMATION CENTER
AI Ready Data　生成AI活用のボトルネックはファイル形式にある
🕒️2026年2月12日

さらに「AI Markdown入門から基礎編」では、製造業のSOP、つまり標準作業手順書を題材に、Markdownを使ってAIが読み取りやすい文書を作る考え方を紹介しました。

AITC | AI TRANSFORMATION CENTER
AI Markdown入門から基礎編　基本文法を実務で使ってみよう
🕒️2026年2月24日

今回のコラムでは、その一歩先として、単なるMarkdown文書ではなく、知識を「AIが探索し、理解し、再利用できる単位」に整理するOKFの活用を、具体例を元に見ていきます。

題材にするのは、電通総研の生成AI活用プラットフォームであるKnow Narratorの情報を、OKF形式の知識コンテナとして整理した know_narrator_okf_strict_bundle です。

今回は、このKnow Narratorの情報をOKF化した例を通じて、OKFの文法、設計方針、そして実務での使いどころをご紹介していきたいと思います。

前回の振り返り：OKF(Open Knowledge Format)とは何か

OKFは、簡単に言えば、AI時代の「知識コンテナ」です。

Google Cloudの発表では、OKF v0.1は、MarkdownファイルのディレクトリとYAML frontmatterによって知識を表現する形式だと説明されています。複雑なSDKや専用ランタイムを前提にするのではなく、「ただのMarkdown」「ただのファイル」「必要最小限のYAML frontmatter」という設計になっている点が特徴です。

OKFの公式仕様でも、OKFは、人が書き、エージェントが生成し、組織間で交換し、人とAIの双方が消費できる、オープンで人間にもエージェントにも優しい知識表現フォーマットとして定義されています。仕様上は、MarkdownファイルとYAML frontmatterで構成され、特定のスキーマレジストリ、中央機関、必須ツールを必要としない設計です。

GitHub
knowledge-catalog/okf at main · GoogleCloudPlatform/knowledge-catalog
https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf

この考え方が重要なのは、AI活用における課題が「情報があるかどうか」ではなく、「AIがその情報を迷わず使えるかどうか」に移っているからです。

社内には、製品資料、提案書、FAQ、導入事例、議事録、設計書、マニュアル、規程、過去の判断理由など、膨大な知識があります。しかし、それらがPowerPoint、PDF、Excel、Word、社内Wiki、共有フォルダ、個人のローカルPCに散在していると、AIはそれらをうまく扱えません。

OKFは、この問題に対して、知識を「小さな概念単位」に分解し、それぞれにメタデータ、本文、関連リンク、出典を持たせることで、人にもAIにも扱いやすい形にするアプローチです。

今回の題材：Know Narratorの情報をOKF化する

今回の例では、Know Narratorの紹介ページの情報

AITC | AI TRANSFORMATION CENTER
電通総研の生成AI活用プラットフォーム： Know Narrator
🕒️2025年1月17日

を、「Know Narratorの提案書作成・営業ナレッジ再利用」を目的として、以下のようなOKFバンドルとして整理したものを元に説明します。

know_narrator_okf_strict_bundle/
├── index.md
├── log.md
├── usage.md
├── product/
│   ├── overview.md
│   ├── features.md
│   ├── strengths.md
│   ├── security.md
│   ├── rag-accuracy.md
│   └── ...
├── offerings/
│   ├── chat-with-vision.md
│   ├── search.md
│   ├── insight.md
│   └── agentsourcing.md
├── sales/
│   ├── proposal-playbook.md
│   ├── proposal-template.md
│   ├── customer-painpoints.md
│   ├── discovery-questions.md
│   ├── objection-handling.md
│   └── faq.md
├── cases/
│   ├── sysmex.md
│   └── suruga-bank.md
└── sources/
    ├── extracted-text.md
    ├── links.md
    └── source-summary.md

この構成を見ていただくと、OKFの考え方がよく分かるかと思います。

元々は1つのWebページだった情報を、そのまま1つの巨大なMarkdownに変換するのではなく、製品概要、特徴、強み、セキュリティ、RAG精度、各オファリング、営業プレイブック、FAQ、導入事例、出典情報というように、再利用しやすい知識単位に分解しています。

人間にとっては、読みたい情報にすぐたどり着けます。営業担当者であれば、まず sales/proposal-playbook.md を読み、セキュリティの質問が来たら product/security.md や sales/objection-handling.md を参照できます。

AIにとっても同じです。すべての情報を一度に読み込ませるのではなく、質問やタスクに応じて、関係の深いファイルから順に読み進めることができます。

OKFの基本文法：Markdown本文とYAML frontmatter

OKFの基本は、とてもシンプルです。

1つの知識単位、つまりConceptを、1つのMarkdownファイルとして表現します。そして、そのファイルの先頭にYAML frontmatterを置きます。

たとえば、今回のOKFバンドルでは、Know Narratorの製品概要を表す product/overview.mdファイルは次のような内容です。

---
type: "Product Overview"
title: "Know Narrator 製品概要"
description: "Know Narratorは、組織に散在する知を高精度AIで結集・活用する生成AIプラットフォーム。"
resource: "https://aitc.dentsusoken.com/products/knownarrator/"
tags: ["Know Narrator", "営業ナレッジ", "提案書作成", "生成AI", "製品概要", "組織のAI基盤"]
timestamp: "2026-07-06T13:00:00+09:00"
---
# Summary
Know Narrator（ノウナレーター）は、電通総研が提供する生成AIプラットフォームです。
長年のエンタープライズシステム導入実績を結集し、組織に散在する「知」を高精度なAIで結集・活用し、全社レベルのDXを推進する「組織のAI基盤」を構築するソリューションです。
# Key Facts
| 項目 | 内容 |
|---|---|
| 製品名 | Know Narrator |
| 読み | ノウナレーター |
| 提供価値 | 組織に散在する知の結集・活用、全社レベルのDX推進、組織のAI基盤構築 |
| 導入実績 | 130社以上 |
| 導入後継続率 | 91%以上（2026年3月時点、PoCを含む導入企業における継続利用率） |
| 主な機能領域 | 対話型AI、社内ナレッジ活用AI、導入効果の分析、AIエージェント |
<中略>
# Related Concepts
* [特徴・機能](/product/features.md)
* [3つの強み](/product/strengths.md)
* [提案プレイブック](/sales/proposal-playbook.md)
* [営業トークトラック](/sales/talk-track.md)
# Citations
[1] [情報元ページ: Know Narrator](https://aitc.dentsusoken.com/products/knownarrator/)
[2] 情報元ファイル `電通総研の生成AI活用プラットフォーム： Know Narrator.html`

OKF仕様上、各Concept文書に必須なのは type です。

title、description、resource、tags、timestamp は推奨項目として扱われます。

つまり、厳格すぎるスキーマでがんじがらめにするのではなく、最低限の相互運用性を確保しつつ、ドメインごとの拡張を許容する設計になっています。

この設計は、実務にとても向いていると思います。

企業内の知識は、すべてが同じ構造ではありません。製品情報、FAQ、提案書テンプレート、導入事例、設計思想、会議のメモでは、必要な項目が異なります。

もし最初から厳密な固定スキーマを要求すると、現場では入力負荷が高くなり、運用が続かなくなります。一方、自由すぎるMarkdownだけでは、AIがどの文書をどう扱えばよいか分かりにくくなります（勿論、ExcelやPowerPointよりはAIにとって把握しやすいですが）。

OKFは、その中間にあります。

最低限のメタデータでAIが検索・選別・ルーティングしやすくしつつ、本文はMarkdownで自由に書ける。このバランスが非常によいと思っています。

index.mdがあることで、AIが迷わず探索できる

OKFで特に良いと感じるのが、index.md の考え方です。

OKF仕様では、index.md はディレクトリの内容を列挙し、人やエージェントが一段ずつ知識を探索できるようにするためのファイルとして位置づけられています。これは、AIに大量のファイルを一気に読ませるのではなく、必要なところから段階的に読み進める「progressive disclosure(段階的開示)」の考え方です。

今回のバンドルでも、ルートの index.md には、次のような利用順が整理されています。

## 推奨利用順
* [利用ガイド](usage.md) - このOKFバンドルを提案書作成や営業ナレッジ再利用で使う方法。
* [製品概要](product/overview.md) - Know Narratorの全体像、導入実績、主要メッセージ。
* [提案プレイブック](sales/proposal-playbook.md) - 提案書構成、営業プロセス、使い分け。
* [提案書テンプレート](sales/proposal-template.md) - そのまま提案書ドラフトに転用しやすい章立て。
* [顧客課題と訴求軸](sales/customer-painpoints.md) - 課題別の提案ストーリー。
* [ヒアリング項目](sales/discovery-questions.md) - 商談・要件定義前に確認すべき質問。

マークダウンで表示すると

これは、人間にとって目次として理解出来ます。

しかし、AIエージェントにとっては、タスクに応じてどこから読むべきかを判断するためのナビゲーションでもあります。

たとえば、「Know Narratorの特徴を説明して」と聞かれた場合は、product/overview.md、product/features.md、product/strengths.md を優先的に読めばよいと判断できます。

一方、「営業提案書の章立てを作って」と言われた場合は、sales/proposal-playbook.md や sales/proposal-template.md を読めば良いと考えられます。

つまり、OKFの index.md は、単なる目次ではなく、AIの探索行動を助けるガイドになっています。

Markdownリンクで、知識がグラフになる

OKFでは、Concept同士を通常のMarkdownリンクでつなぎます。

たとえば、営業プレイブックの中で、顧客課題と対応機能を整理するときに、次のようなリンクを張ることができます。

| 顧客課題 | 対応するKnow Narrator要素 |
|---|---|
| 過去提案書や営業資料を探せない | [Know Narrator Search](/offerings/search.md) |
| 社外秘資料をAIに入れるのが不安 | [セキュリティ](/product/security.md) |
| 回答品質や根拠が不安 | [RAG精度](/product/rag-accuracy.md) |
| 利用状況やコストを管理したい | [Know Narrator Insight](/offerings/insight.md) |

マークダウンで表示すると

このようにリンクを張ることで、知識は単なるフォルダ階層ではなく、関係性を持ったグラフになります。

OKF仕様でも、Concept間のリンクは標準Markdownリンクで表現され、そのリンクによって、ファイルシステム上の親子関係よりも豊かな関係性を表せると説明されています。

これも、AI活用において非常に重要です。

人間は、文脈を補完しながら読むことができます。しかしAIに業務知識を使わせる場合は、「この概念は何と関係しているのか」「この説明の根拠はどこか」「顧客課題に対してどの機能を参照すべきか」が、できるだけ明示されている方がよいです。

Markdownリンクは、人間にとってはクリックできる参照であり、AIにとっては知識グラフのエッジになります。

log.mdとCitationsが、知識の信頼性を高める

企業でAIを使う場合、知識は一度作って終わりではありません。

製品情報は更新されます。価格や提供条件も変わります。導入事例が増えることもあります。セキュリティ説明やFAQも、顧客からの質問に応じて改善されます。

そのため、OKFでは log.md によって更新履歴を残せるようになっています。仕様上、log.md は任意ですが、知識バンドルの変更履歴を時系列で記録するためのファイルとして定義されています。

また、各Conceptの本文で外部情報に基づく主張をする場合は、# Citations に出典を整理できます。仕様では、Concept本文の主張を支える外部ソースを、# Citations 見出しの下に番号付きで記載することが推奨されています。

今回のKnow Narratorバンドルでも、各ファイルの末尾に、保存元ページや元となるHTMLファイルが出典として整理されています。

これは、AI活用において非常に大切です。

AIが生成した回答に対して、「それはどの情報に基づいているのか」を確認できるからです。特に営業提案、顧客説明、セキュリティ回答、契約前の確認では、根拠のない生成文をそのまま使うことはできません。

OKF化されたナレッジでは、AIが回答を作るだけでなく、人がその根拠を確認しやすくなります。

OKF化されたナレッジは、人にもAIにも優しい

今回のようにOKF化したナレッジは、AIにとっても人にとっても優しい形式です。

人にとって優しい理由は、知識が目的別に整理されているからです。

製品概要を知りたい人は product/overview.md を読めばよい。機能を知りたい人は product/features.md を読めばよい。営業提案に使いたい人は sales/proposal-playbook.md や sales/proposal-template.md を見ればよい。セキュリティ質問に対応したい人は product/security.md や sales/objection-handling.md を参照すればよい。

AIにとって優しい理由は、各ファイルに type、title、description、tags が付いているからです。

AIは、ファイル名だけでなく、メタデータを見て「これは製品概要なのか」「これはFAQなのか」「これは営業トークなのか」「これは導入事例なのか」を判断できます。

さらに、Markdown本文には見出し、表、リスト、リンク、引用元が含まれているため、AIが情報の構造を理解しやすくなります。

これは、AI Ready Dataのさらに先にある、AI Ready Knowledgeと言ってもよいかもしれません。

単にAIが読めるデータではなく、AIが目的に応じて選び、読み、組み合わせ、回答に使える知識です。

CodexやClaude CodeのようなAI開発環境でも活用しやすい

OKFの魅力は、特定のアプリケーションに閉じないことです。

Google Cloudの発表でも、OKFは特定のクラウド、データベース、モデルプロバイダー、エージェントフレームワークに結びつかない形式として説明されています。価値の中心はツールではなく、知識を交換可能にするフォーマットそのものにあります。

そのため、OKFバンドルは、CodexやClaude CodeのようなAI開発支援環境、あるいは社内のRAG基盤、検索インデックス、ドキュメントポータルなど、さまざまな環境で活用できます。

たとえば、今回の know_narrator_okf_strict_bundle フォルダを、CodexのようなAI開発環境に読み込ませて、次のように質問できます。

know_narrator_okf_strict_bundle フォルダの内容を元に、
「Know Narratorの特徴は？」という質問に回答して。
参照したOKFファイルも最後に列挙して。

すると、次のような回答が得られます。

Know Narratorの特徴は、企業向けに安全な生成AI活用を進めるための「組織のAI基盤」である点です。単なるチャットツールではなく、社内ナレッジ活用、利用状況の分析、業務プロセスのAIエージェント化まで段階的に広げられる構成になっています。
主な特徴は4つです。
1. セキュアな対話型AI
ChatGPT、Gemini、Claudeなど複数のLLMを、入力データがAI学習に利用されない安全な環境で使える。全社員向けの生成AI利用基盤として位置づけられています。
2. 高精度RAGによる社内ナレッジ活用
企業独自データをセキュアに連携・統合し、テキストや画像を含む情報から、実務に直結する回答を導く検索システムを構築できます。
3. 導入効果の可視化
利用状況、コスト、精度評価などを分析でき、生成AIを導入して終わりではなく、継続的な改善につなげられます。
4. AIエージェントへの拡張
特定の業務プロセスを自律的に遂行するAIエージェント機能を提供し、複雑な個別業務に合わせた独自エージェントの開発・拡張も可能です。
強みとしては、高いセキュリティ、高精度RAG、標準機能と伴走支援・カスタマイズの両立が整理されています。営業・提案用途では、過去提案書、FAQ、導入事例、製品情報を再利用し、提案品質と作成スピードを高めるAI基盤として訴求できます。
参照したOKFファイル:
know_narrator_okf_strict_bundle/product/overview.md
know_narrator_okf_strict_bundle/product/features.md
know_narrator_okf_strict_bundle/product/strengths.md
know_narrator_okf_strict_bundle/offerings/search.md
know_narrator_okf_strict_bundle/offerings/chat-with-vision.md
know_narrator_okf_strict_bundle/offerings/insight.md
know_narrator_okf_strict_bundle/offerings/agentsourcing.md

この回答の良い点は、単にWebページの文章を要約しているだけではないことです。

AIは、製品概要、機能、強み、各オファリングのファイルを横断しながら、質問に必要な情報を組み合わせています。さらに、参照したファイルも列挙しています。

つまり、回答の根拠を人が後から確認できます。

これは、実務でAIを使ううえで必須事項です。

生成AIの回答は便利ですが、根拠が見えないと、営業資料や顧客向け回答には使いにくいものです。OKF化されたナレッジを使うことで、AIの回答と根拠ファイルを結びつけやすくもなります。

OKFの設計方針が優れている理由

OKFの設計方針で特に素晴らしいと思っているのは、「ちょうどよい制約」にあります。

厳しすぎるフォーマットは、現場で使われません。入力ルールが多すぎると、知識化する前に疲れてしまいます。

一方で、自由すぎるフォーマットも、AI活用には向きません。ファイル名も構造もバラバラ、メタデータもない、リンクもない、出典もない状態では、AIが正しく情報を選択することは不可能です。

OKFは、この中間を狙っています。

  • 本文はMarkdownで自由に書ける
  • 先頭にYAML frontmatterを置く
  • Conceptごとに type を持たせる
  • title、description、tags で探しやすくする
  • index.md で探索しやすくする
  • Markdownリンクで関係性を表す
  • log.md で更新履歴を残せる
  • # Citations で根拠を残せる

この設計は、ソフトウェア開発でいう「コードとして管理する」考え方にも近いです。

OKFのREADMEでも、OKFバンドルはGitで管理でき、Pull Request、差分レビュー、履歴確認など、ソフトウェア開発で使われているワークフローと相性が良いと説明されています。

企業の知識管理も、今後は「ナレッジを置く」だけでなく、「ナレッジを育てる」方向に進むはずです。

「ナレッジを育てる」ためには、OKFのように、ファイルとして管理でき、Gitで差分を確認でき、AIも人も読める形式は、非常に強力です。

OKFバンドルを作るときの実務ポイント

実際にOKFバンドルを作るときは、最初から完璧な知識構造を作ろうとしない方がよいと思います。

重要なのは、まず目的を決めることです。

今回のKnow Narratorバンドルでは、「Know Narratorの提案書作成・営業ナレッジ再利用」という目的を明確にしました。そのため、単なる製品情報の分解ではなく、営業プレイブック、提案書テンプレート、顧客課題、反論対応、FAQといった実務利用に直結する構成になっています。

OKF化では、次のような順番が実務的です。

まず、何のための知識コンテナなのかを決めます。営業提案なのか、問い合わせ対応なのか、社内規程検索なのか、データ分析エージェント向けの指標定義なのかによって、ファイル構成は変わります。

次に、知識をConcept単位に分けます。1ファイルにすべてを詰め込むのではなく、製品概要、機能、FAQ、反論対応、導入事例など、AIが選びやすい粒度に分割します。

そして、それぞれのConceptに type、title、description、tags を付けます。このメタデータが、AIにとっての道しるべになります。

さらに、関連するConcept同士をMarkdownリンクでつなぎます。顧客課題から機能へ、機能から強みへ、強みから導入事例へ、FAQから出典へとつながることで、AIは文脈をたどりやすくなります。

最後に、index.md と # Citations を整備します。人もAIも、どこに何があるのか、どの情報に基づいているのかを確認できるようにするためです。

このように考えると、OKF化とは、単なるファイル変換ではありません。

知識を、業務で使える構造に再設計することです。

まとめ：Markdownの次に考えるべきは、OKFによる知識コンテナ化

Markdownは、AI Ready Dataを作るうえで非常に有効です。

しかし、企業の生成AI活用が進むと、単に1つ1つの文書をMarkdown化するだけでは足りなくなります。

AIに業務を任せるためには、知識を目的別に整理し、概念単位に分け、メタデータを付け、関連性を明示し、出典を残し、更新できる状態にする必要があります。

そのための有力な考え方がOKFです。

今回のKnow Narratorの例で見たように、OKF化されたナレッジは、人間にとって読みやすく、AIにとっても探索しやすい形式になります。

そして、CodexやClaude CodeのようなAI開発支援環境、社内RAG基盤、AIエージェント、検索システム、ドキュメントポータルなど、さまざまな環境で再利用しやすくなります。

AI活用の本質は、単に高性能なモデルを使うことではありません。

AIに、業務に必要な知識を、適切な形で渡せるかどうかです。

これからの企業には、ファイルを保管するだけのナレッジ管理ではなく、AIが活用できる知識コンテナを設計する力が求められます。

OKFは、そのための非常にシンプルで、現実的で、拡張性のあるアプローチです。

AITCでは、生成AI活用、RAG、AIエージェント、AI Ready Data、そしてOKFのような知識コンテナ化の取り組みを通じて、企業のAI活用を実務に根付かせる支援を行っています。

社内に散在するナレッジを、AIが活用できる形に変えていきたい。企業の暗黙知を形式知化し、活用していきたい。

提案書、FAQ、導入事例、業務マニュアル、データ定義、会議録などを、AI Ready Knowledgeとして再構成したい。

そのような取り組みを、AITCと一緒に進めてみませんか。

筆者
AITC センター長
深谷 勇次

コラムカテゴリー
AIエージェント、AI化戦略、生成AI、RAG
前の記事
生成AI活用ガイドラインのあるべき姿とは？
2026年6月22日