OKF(Open Knowledge Format)とは？AI時代の「知識コンテナ」になるか

はじめに

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

生成AIやAIエージェントの活用が進むにつれて、企業の課題は「どのモデルを使うか」だけではなく、「AIにどの知識を、どの形で渡すか」へと移っています。

高性能なLLMであっても、社内固有の前提を知らなければ、正しい判断はできません。たとえば、ある売上指標がどのテーブルから計算されるのか、どの条件を除外すべきなのか、過去の提案で顧客が何を評価したのか、ある会議でなぜその方針が採用されたのか。こうした知識は、企業活動の中では非常に重要です。

しかし実際には、それらの知識は社内Wiki、提案書、議事録、表計算ファイル、データカタログ、コードコメント、チャット、そして担当者の頭の中に分散しています。AIに活用させようとしても、毎回ばらばらの場所から文脈を集め直さなければなりません。

そのような課題解決の一助となるような情報が、Googleから、2026年6月13日に発表されました。その名は、"Open Knowledge Format"（略してOKF）です。

日本語訳版

OKF(Open Knowledge Format:オープンナレッジフォーマット)とは？

Open Knowledge Format（以下、OKF）とは、AIエージェントや人間が利用するための知識を、持ち運びやすく、読みやすく、再利用しやすい形で表現するためのオープンなフォーマットです。

一言でいえば、OKFは「AIに渡す業務知識やデータの文脈を、MarkdownとYAMLで整理するための形式」です。

OKFの基本構造は非常にシンプルです。知識をMarkdownファイルとして記述し、その先頭にYAML frontmatterと呼ばれるメタデータを付けます。Markdown本文には、人間が読める説明、業務ルール、指標定義、SQL例、注意点、参照リンクなどを書きます。YAML frontmatterには、その知識が何の種類なのか、タイトルは何か、どのリソースに対応するのか、タグは何か、いつ更新されたのかといった、システムやAIが処理しやすい情報を書きます。

たとえば、ある業務指標についてのOKFファイルであれば、本文には「この指標の意味」「計算方法」「使うテーブル」「除外条件」「SQL例」「注意点」を記述します。一方、frontmatterには「type: Metric」「title: 月次アクティブユーザー」「tags: [分析, KPI, 顧客行動]」のような情報を持たせます。

この設計の特徴は、人間にもAIにも読みやすいことです。

人間にとっては、Markdownなので通常のドキュメントとして読めます。エンジニアでなくても、業務説明や判断理由を自然な文章で確認できます。

一方、AIエージェントは、ファイルの先頭に書かれた「知識の種類・タイトル・タグ・更新日」などの情報を使って、必要な知識を効率よく探せます。さらに、Markdownのリンクをたどることで、関連する業務用語やデータ、判断理由などを参照し、回答や分析に活用できます。

重要なのは、OKFはデータそのものを保存するフォーマットではないという点です。

売上データ、顧客データ、ログデータ、トランザクションデータなどの実データは、これまで通りデータベース、DWH、データレイク、CSV、JSON、Parquetなどで管理されます。OKFが扱うのは、そのデータを正しく理解し、正しく使うための「知識」です。

具体的には、以下のようなものがOKFの対象になります。

• テーブルやデータセットの説明
• 指標やKPIの定義
• データ分析時の注意点
• join条件やSQL例
• 業務用語の定義
• 提案活動で使う営業ナレッジ
• 会議で決まった判断理由
• 運用手順やマニュアル
• 参照すべきドキュメントや根拠資料

つまりOKFは、データ本体を入れる箱ではなく、データや業務を正しく使うための文脈を入れる箱です。この意味で、私はOKFをAI時代の「知識コンテナ」と呼びたいと思います。

AIエージェントが業務で役立つためには、単に大量のドキュメントにアクセスできるだけでは不十分です。どの知識がどの業務に関係しているのか、どの指標がどのテーブルから計算されるのか、どの判断がどの背景で行われたのかを、AIがたどれる形にする必要があります。

OKFは、そのための軽量な共通形式です。

AI時代に必要なのは「ナレッジの置き場所」ではなく「AIが扱える形」

これまで企業は、ナレッジマネジメントのために多くの仕組みを導入してきました。文書管理システム、社内ポータル、データカタログ、BIツール、FAQシステム、チャットボット、全文検索基盤などなどです。

もちろん、これらは今後も重要です。しかしAIエージェントの時代には、それだけでは十分ではありません。

AIにとって重要なのは、単にドキュメントが存在することではなく、そのドキュメントが「何についての知識なのか」「どのデータや業務と関係しているのか」「いつ更新されたのか」「どの指標や判断に影響するのか」が、機械的に扱えることです。

つまり、AIに渡す知識には、本文だけでなく、メタデータ、構造、リンク、出典、更新履歴、利用上の注意が必要になります。

OKFは、この課題に対して非常にシンプルなアプローチを取っています。Markdown本文に人間が読める説明を書き、YAML frontmatterにAIやシステムが処理しやすいメタデータを書く。さらにMarkdownリンクによって、関連する知識同士をつなぐ。これだけです。

技術的にはとても素朴です。しかし、この素朴さが重要です。

企業内の知識は、最初から完璧なナレッジグラフとして整備されているわけではありません。むしろ、曖昧で、断片的で、更新され続けます。そのような知識を扱うには、厳密すぎるスキーマよりも、人間が編集でき、Gitで差分管理でき、AIもそのまま読める軽量な形式の方が現実的です。

OKFは「データコンテナ」ではなく「知識コンテナ」である

OKFを理解するうえで、最も大切なのは、OKFをデータ本体のフォーマットと混同しないことです。

売上明細、ログ、顧客マスタ、トランザクションデータなどの実データは、今後もデータベース、DWH、レイクハウス、Parquet、CSV、JSONなどで管理されます。OKFはそれを置き換えるものではありません。

OKFが担うのは、その上にある知識レイヤーです。

たとえば、あるテーブルについて、次のような情報をOKFで表現できます。

このテーブルは何を表しているのか。
どの列が主キーなのか。
どの列を使って他のテーブルと結合するのか。
このテーブルを使うときに注意すべき欠損や遅延は何か。
どの業務指標の計算に使われるのか。
過去にどのような分析で使われたのか。
正しいSQL例はどれか。
誰がこの定義を管理しているのか。

これは、AIエージェントにとって極めて重要な情報です。

特にデータ分析エージェントでは、テーブル名や列名だけを渡しても十分ではありません。AIはSQLを生成できても、指標の意味や業務上の例外条件を知らなければ、誤った集計をしてしまいます。OKFは、この「AIが間違えやすい文脈」を、再利用可能な知識として外出しする仕組みになり得ます。

この意味でOKFは、AI時代の「知識コンテナ」です。データそのものを入れる箱ではなく、データや業務を正しく使うための文脈を入れる箱です。

OKFの理解を深めるための3つの事例

ここからは、OKFの理解を深めていただくために、具体的な事例を提示し、その事例に対してどのようにOKFが有効かを説明します。

OKFのような新しいフォーマットは、仕様だけを読んでも価値が見えにくい面があります。重要なのは、「自社のどの知識をOKF化すると、AI活用の効果が高まるのか」を考えることです。

ここでは、実務で特に有望だと考えられる三つの事例を取り上げます。

一つ目は、提案書作成・営業ナレッジ再利用です。
二つ目は、データ分析エージェント向け指標定義です。
三つ目は、会議録から判断理由をナレッジ化することです。

事例1　提案書作成・営業ナレッジ再利用

企業で最も再利用価値が高い知識の一つが、営業・提案活動に関するナレッジです。

提案書には、単なる製品説明だけではなく、顧客課題の捉え方、業界ごとの論点、過去に刺さった訴求、失注理由、競合比較、導入効果の表現、質疑応答、提案時の注意点など、多くの暗黙知が含まれています。

しかし、これらは提案書ファイルの中に閉じ込められがちです。担当者が過去資料を探し、使えそうなページをコピーし、今回の顧客に合わせて修正する。営業組織ではよくある作業ですが、AIエージェントを活用するなら、この再利用プロセスはもっと構造化できます。

たとえばOKFで、次のような知識をconceptとして整理します。

• 業界別の課題定義
• 提案テーマ別の訴求ポイント
• 過去提案で評価されたメッセージ
• 導入効果の表現パターン
• 顧客からよく出る質問と回答
• 提案時に避けるべき表現
• 参照すべき事例や根拠資料

これらをMarkdownで人間が読める形にしつつ、frontmatterには、業界、顧客セグメント、提案テーマ、対象ソリューション、更新日、作成者、機密区分などを持たせることができます。

するとAIエージェントは、単に過去提案書を全文検索するのではなく、「製造業向け」「経営層向け」「生成AI活用基盤」「初回提案」などの条件に応じて、必要な営業ナレッジを組み合わせて提案書ドラフトを作れるようになります。

重要なのは、提案書そのものを再利用するのではなく、提案書に含まれる判断・表現・根拠を再利用可能な知識として切り出すことです。これにより、属人的な営業ノウハウを、AIが参照できる組織知へ変換できます。

事例2　データ分析エージェント向け指標定義

二つ目の有望な事例は、データ分析エージェント向けの指標定義です。

企業でデータ活用を進めると、必ず問題になるのが「同じ言葉なのに、部門ごとに定義が違う」という状況です。売上、粗利、アクティブユーザー、解約率、案件化率、受注率。どれも一見わかりやすい言葉ですが、実際には計算条件、対象範囲、除外条件、集計タイミングが異なります。

人間同士であれば、会議の中で補足したり、過去の経緯を知る担当者が説明したりできます。しかしAIエージェントは、そうした暗黙の補足を知りません。結果として、それらしいSQLを生成しても、業務的には誤った数値を出してしまう可能性があります。

OKFでは、指標そのものを独立した知識として扱うことができます。

たとえば「月次アクティブユーザー」というmetric conceptを作り、以下を記述します。

• 指標の業務上の定義
• 計算対象となるイベント
• 除外すべきユーザーやデータ
• 利用するテーブルとjoin条件
• 正しいSQL例
• よくある誤集計パターン
• ダッシュボードとの対応関係
• 更新日
• 承認済みの定義かどうか

このような知識が整備されていれば、AIエージェントは「月次アクティブユーザーを出して」と言われたときに、単に列名やテーブル名を推測するのではなく、承認済みの定義に基づいてSQLを生成できます。

これは、AIによるデータ分析の信頼性を高めるうえで非常に重要です。AIが分析を支援する時代には、データ基盤を整えるだけでは不十分です。データの意味を決める「指標定義」そのものも、AIが読める形で管理する必要があります。

つまり、指標は単なる計算式ではありません。どの業務判断に使うのか、どの条件で集計するのか、誰が責任を持つのか、どの定義が正式なのかまで含めた、業務知識の一部です。

OKFは、このような指標に関する知識を、AIエージェントが参照しやすい形でまとめるための器になり得ます。これにより、AIは単にデータを集計するだけでなく、企業内で合意された意味に沿って、信頼できる分析結果を返せるようになります。

事例3　会議録から判断理由をナレッジ化する

三つ目の事例は、会議録から判断理由をナレッジ化することです。

企業には多くの会議があります。そして多くの場合、会議録には「何が決まったか」は書かれていても、「なぜそう決まったか」は十分に残っていません。

AI時代に再利用価値が高いのは、決定事項そのものだけではありません。むしろ、判断に至る背景、採用しなかった選択肢、前提条件、リスク認識、顧客からの制約、関係者の懸念といった情報です。

これらは、後から新しいメンバーが参加したとき、似た意思決定を再度行うとき、AIエージェントにプロジェクトの背景を理解させるときに非常に価値があります。

OKFを使えば、会議録を単なる時系列ドキュメントとして保存するのではなく、判断理由の知識として再構成できます。

たとえば、次のようなconceptを作ることができます。

• 決定事項
• 判断理由
• 比較した選択肢
• 採用しなかった案とその理由
• 前提条件
• 未解決課題
• 参照資料
• 関連するプロジェクト、顧客、機能、指標
• 次回見直しタイミング

こうした構造を持つことで、AIエージェントは「この設計方針はなぜ採用されたのか」「以前、同じような議論はあったか」「この顧客向けに避けるべき論点は何か」といった問いに答えやすくなります。

会議録を保存するだけでは、知識は埋もれます。判断理由として構造化することで、会議は組織の学習資産になります。

OKF導入で重要なのは、フォーマットよりも運用設計

OKFは、仕組みとしてはとてもシンプルです。ただし、シンプルだからといって、何も決めずに使えるわけではありません。むしろ自由度が高いからこそ、企業の中で使う場合には「社内での使い方のルール」を決めておく必要があります。

たとえば、次のようなことです。

どの情報をどの種類として整理するのか。たとえば、指標ならMetric、テーブル情報ならTable、業務手順ならPlaybook、判断記録ならDecision、提案の型ならProposalPattern、というように分類を決める必要があります。

また、Markdown本文の見出しをどう揃えるのか、出典をどこまで必須にするのか、誰が内容を確認するのか、古くなった知識をどう見つけるのか、機密情報をどう分けて管理するのか、といった運用ルールも必要です。

これらを決めないままOKFを導入すると、単にMarkdownファイルが増えるだけになってしまいます。それでは、AIエージェントが再利用できる知識基盤にはなりません。

そのため、実務では最初から全社展開を目指すのではなく、まずは範囲を絞って試すのが現実的です。

まずは小さなOKF bundleを作り、それをAIエージェントに読ませてみます。そして、回答の質が上がるか、作業時間が短くなるか、過去の知識を再利用しやすくなるかを確認します。

その結果を見ながら、typeの設計、テンプレート、レビュー方法、品質チェック、権限制御を少しずつ整えていく。

このように、小さく試して、効果を確認しながら運用ルールを作っていく進め方が、OKF導入では現実的だと思い、検討を始めています。

AI活用は「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ

これまで生成AI活用では、プロンプトエンジニアリングが注目されてきました。もちろん、AIにどう指示するかは今後も重要です。

しかし、企業利用ではそれだけでは限界があります。AIに何を考えさせるかだけでなく、AIにどの知識を渡すか、どの前提を信頼させるか、どの根拠に基づいて判断させるかが重要になります。

以下のコラムでご説明しましたが、企業の生成AI活用は、プロンプトエンジニアリングよりも、コンテキストエンジニアリングをより重要視することが求められてきています。

OKFは、この変化に対応するための有力な選択肢です。

たとえば、これまで人の頭の中や過去資料の中に埋もれていた業務知識を、Markdownファイルとして整理します。その知識に、種類、タイトル、タグ、更新日、参照先などのメタデータを付けます。そして、関連する知識同士をリンクでつなぎます。

こうすることで、人間は通常のドキュメントとして読み、AIエージェントは業務の文脈として参照できるようになります。

これは、AI活用を「その場限りのプロンプト作成」から、「組織として再利用できる知識整備」へ進める考え方です。

プロンプトは、個別の依頼内容をAIに伝えるものです。一方、OKFで整理された知識は、AIが継続的に参照できる組織の前提知識になります。毎回プロンプトに長い説明を書くのではなく、必要な知識をAIが参照できる場所に整えておく。これが、企業におけるAI活用を一段階成熟させるポイントです。

ただし、OKFはまだ新しい仕様です。まだ、現時点でv0.1です。これを唯一の標準と決め打ちするのは早いでしょう。重要なのは、OKFという名前そのものよりも、AIが再利用できる形で知識を構造化し、管理し、更新し続けるという考え方です。

OKFはAI時代の「知識コンテナ」になるか？

OKFは、AI時代の「知識コンテナ」になる可能性があります。

ただし、それはOKFがすべてのナレッジマネジメント課題を自動的に解決するという意味ではありません。OKFは、知識を管理しやすくし、AIにも人間にも読みやすくするための器です。その器に何を入れるか、どう更新するか、誰が責任を持つか、どのAIにどこまで読ませるかは、企業側が設計しなければなりません。

この記事では、３つの事例をご紹介しましたが、これらはいずれも、暗黙知が多く、再利用価値が高く、AIによる支援効果が見えやすい領域です。

AIエージェントが本当に業務で役立つためには、モデルの性能だけでなく、組織固有の知識をどう渡すかが問われます。OKFは、その課題に対応するための一つの要素と言えます。

これからの企業に必要なのは、単にAIを導入することではありません。AIが正しく使える知識を、組織として整備することです。

OKFは、そのための新しい出発点になるかもしれません。

OKFの具体例を紹介するコラムもありますので、合わせてご覧ください。

AITCと一緒に、AIが活用できる知識基盤づくりを進めませんか？

AIエージェントを業務で活用していくうえで重要なのは、自社の業務知識、データ定義、判断理由、提案ノウハウを、AIが正しく参照できる形に整えていくことです。

しかし、どの知識から整理すべきか、どの粒度で構造化すべきか、どのようにAIエージェントに活用させるべきかは、企業ごとの業務や既存システムによって異なります。OKFのような新しい考え方も、いきなり全社展開するのではなく、まずは効果が見えやすい領域から小さく始め、実務で検証しながら育てていくことが重要です。

電通総研のAIトランスフォーメーションセンター（AITC）では、生成AIやAIエージェントを活用した業務変革に取り組むお客様とともに、AIが活用できる知識基盤づくりを支援しています。

AI活用を次の段階へ進めたいとお考えの方は、ぜひAITCにご相談ください。

AIを導入するだけでなく、AIが正しく使える知識を組織として整備する。その取り組みを、AITCと一緒に進めていきましょう。

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