その資料、AIには読めない置き方になっていませんか——Googleが公開したOKFという答え
議事録、マニュアル、報告書。フォルダに溜めて、AIに読ませている。
なのに聞くと、古い版を混ぜて答えてくる。とっくに変わった値段で、とっくにやめた手順で、平気な顔で答えてくる。
何度かそれが続くと、人は静かに、AIに大事なことを聞かなくなります。文章の手直しや調べ物には使う。でも、自社の数字や経緯が絡む相談はしない。AIは「一般論を答える係」に、そっと格下げされていく。
——心当たりは、ありませんか。
Googleが、この困りごとのど真ん中に向けて、一つの取り決めを公開しました。名前は OKF。日本語にすれば「開かれた知識の書式」——AIに知識を渡すときの、書き方の取り決めです。
今日はその紹介と、それから、少し個人的な話をします。
（この連載では、AIとの会話が一言一句そのまま残っている記録を「原典」と呼び、それを消さずに残して、あとから働かせる工夫のことを、勝手に「原典工学」と呼んでいます。今日は、原典から作った「今の正解」を、どう置くかの話です。）
悪いのはAIではなく、フォルダのほう
最初に、種明かしをひとつ。
AIが古い版を混ぜるのは、AIが劣っているからではありません。フォルダが、人間専用にできているからです。
どれが最新か。どれが決定版で、どれが没か。あの数字は、誰がどう決めたのか。——そういうことは、書類のどこにも書いてありません。書いていないのに社内で困らなかったのは、人がタダで補ってきたからです。「その見積もりは古いですよ、先月改定したから」と言ってくれる誰かが、いつもそばにいた。
フォルダというのは、「事情を知っている人」がそばにいる前提で成り立ってきた置き場なのです。
そこに、事情を何も知らない読み手——AIが、初めて来ました。AIには、隣の席の誰かがいません。フォルダに置いてある物を、置いてあるままに読みます。生きている書類と死んだ下書きの区別は、書いていなければ、つきません。
つまり、あなたの会社の知識は、実は、フォルダの中にありません。「どれが生きているか」という一番大事な部分は、まだ、人の頭の中にあります。
そして、この前提は崩れ始めています。人は辞めるし、忘れます。それに、これからは資料をAI自身が書き足していきます。事情を知らない書き手が、事情の書いていない山に、さらに積んでいく。放っておけば、山はどんどん、誰にも確かめられないものになっていきます。
白状すると、私はこれに、あまり困っていません
ここで白状します。冒頭の困りごとに、私は、あまり遭っていません。
理由は単純で、似たような仕組みを、必要に迫られて自己流で作っていたからです。この連載でずっと書いてきた、あの話です。AIとの会話は全文残す。仕事の終わりに、AIに数行のあらすじを書かせる（第3話）。探すときは、まず目録で当たりをつけてから原典に降りる（第4話）。そしてプロジェクトごとの「今の正解」は、別のページに書き直して育てる。
自分と、自分の顧問先の範囲でしか通用しない、手作りの仕組みです。
その上で、Googleの取り決めを読みました。
かなり、似ていました。
正直な感想を書きます。——すごいラッキーだ、でした。自分の周りにしか通用しなかった手作りの工夫が、世界の標準とよく似た形をしていた。明日から「私の自己流ですが」ではなく「Googleも同じことを言っています」と言える。こんなに都合のいい話は、めったにありません。
なぜ似ていたのかには、ちゃんと理由がありました。それも後で書きます。先に、OKFの中身を紹介させてください。拍子抜けするほど、簡単です。
中身は、フォルダとテキストと、数行のラベルだけ
OKFの中身は、こうです。
ただのフォルダに、ただの文章ファイルを入れる。各ファイルの頭に、数行のラベルを書く。以上。
新しいソフトは要りません。登録先も、費用も、専用の道具も要りません。仕様書自身が、趣旨としてこう言っています——ファイルを開ければ読める。フォルダごと写せば、そのまま人に渡せる。
（文章ファイルはMarkdownという形式ですが、身構えなくて大丈夫です。どんなパソコンのメモ帳でも開ける、飾りの少ないただのテキストです。）
拍子抜けしたでしょうか。私はしました。でもこの「何も要らない」は手抜きではなく、狙いです。10年後のパソコンでも、別の会社のAIでも、読める。凝った仕組みは、凝った分だけ持ち運べなくなる——それを知っている人の設計です。
違いは、たったひとつ。ファイルの頭に貼るラベルです。
ラベルは、スーパーの食品表示と同じ
ラベルには、何を書くのか。
まず、名前です。この書類は何の種類か（議事録か、手順書か、決め事か）。そして、中身を一文で言うと何か。AIが目録を作るとき、開く前に見当をつけるとき、この一文が効きます。
その上に、OKFが本領とするラベルが乗ります。読みながら私が思い出したのは、スーパーの食品表示でした。
- 産地——この知識は、何から作られたか。元にした資料はどれか
- 検品——誰が（どのAIが）書いたか。そして、誰が確かめたか。書いた者と確かめた者は、別の欄です。「AIが書いて、人が確かめた」が、ラベルを見れば分かるようになっています
- 賞味期限——いつまで信じてよいか。期限を過ぎた知識は「古くなっているかもしれない」と、機械にも分かる
- 棚の入れ替え——下書きか、現役か、引退済みか。引退した書類は捨てずに、「引退」と書いて残す
スーパーの棚から、私たちはラベルのない食品を買いません。ところがAIには、ラベルのないフォルダから選ばせていました。古いのを掴むのは、当たり前だったのです。
ひとつ、感心したことがあります。OKFは、信用の点数を書きません。「この書類は信頼度80点」のような判定は書かない決まりで、書くのは判断材料——誰が作り、誰が確かめ、いつまでの話か——だけ。判定は、読む側がします。点数は人によって基準が違い、しかも古びるから、と仕様書は理由まで書いています。
この連載を「原典工学」と名乗ってきた手前、考えました。原典工学が「原典」の工学だとすれば、OKFは何の工学なのか。
私の答えはこうです。OKFは、知識ではなく、信用を扱う仕組みです。 作った人がその場にいなくても、書類が自分で「私はこういう素性の者です」と名乗れるようにする。そのための、書き方の決まりごとなのだと思います。
答え合わせ——なぜ似ていたのかには、理由がありました
さて、さっきの続きです。手元には、AIに書かせてきたあらすじの記録が900本あまり、パターン集や失敗事例の束、プロジェクトごとの「今の正解」のページ群があります。OKFの形と、突き合わせてみました。
結果は、3つに割れました。
ひとつ目。似ていた理由が分かった物。 プロジェクトごとの「今の正解」のページ群——私はこれを、今年の7月に作りました。そのとき下敷きにしたのが、アンドレイ・カーパシーというAI研究者が書いた、たった75行のメモです。「AIに知識を渡すなら、wikiの形がいい」という趣旨の短い文章でした。
そしてOKFも、同じ考え方の上に立っています。
つまり独立して同じ場所に着いたのではなく、同じ源から、Googleと私が別々に汲んでいたのでした。似ているのは、当たり前だったのです。
ただ、これはこれで、ひとつ発見でした。同じ源から出発して、Googleは万人向けの規格にし、私は自分の仕事に合わせて手で作った。それでも骨格は、そう遠くならなかった。良い考え方に早めに触れておくと、こういう得の仕方がある、ということだと思います。
（ちなみに7月に下敷きを読んだとき、手元の仕組みを数えたら「必要な部品の7割は既に持っている」という結論でした。新しく足したのは3つだけです。ページを育てること、反対意見を必ず書くこと、矛盾を目立たせること。この3つ目までやっている規格は、実はまだ見たことがありません）
ふたつ目。形は同じなのに、ラベルの言葉がバラバラだった物。 種類のラベルに、同じ意味を3つの言葉で書いていました。人間の目には同じに見えます。でもAIには、3種類の別物に見える。「揃える」ことの効き目が、一番よく分かった箇所です。
3つ目。逆向きだった物。 目録のつもりで作っていた一覧が、実際には日誌に近くなっていました。1行が本文並みに太って、「開く前に見渡す」という目録の仕事を果たせていない。ここはOKFを鏡にして、作り直しました。
直す作業は、全部AIにやらせました。私がしたのは、方針を決めることと、AIが迷ったラベルの判定だけです。
今日からできること——ラベル貼りは、AIの仕事です
真似は、今日からできます。しかも、ラベルを貼る作業は、あなたの仕事ではありません。
- フォルダをひとつ選ぶ。 よく使う、書類の混みあった所がいい
- AIに頼む。 「このフォルダの各ファイルの頭に、種類と一文の説明のラベルを付けて。どれが現役でどれが旧版か、迷った物は私に聞いて」
- 聞かれた物にだけ、答える。 どれが生きているか——それだけが、人の頭の中にしかない情報です。あなたにしか答えられません
- 旧版には「引退」と書く。 捨てなくていい。引退と書いてあれば、AIはもう混ぜません
- 終わったら、前に変な答えが返ってきた質問を、もう一度してみる。 違いは、ご自分の目で
本家の決まりごとは、Googleがこちらで全文を公開しています。英語ですが、AIに「このページを読んで、うちのフォルダに当てはめて」と頼めば、そのまま働いてくれます。興味のある方は、AIに読ませてみてください。
このブログでは、その本家から、非エンジニアが今日から真似できる最小形だけを抜き出して、記事の最後に置いておきました。日本語のラベルの見本と、AIへの頼み方の文面です。まずはそれを写して、フォルダひとつで試してみてください。
社内で自分とAIが読むだけなら、ラベルは日本語でかまいません。大事なのは言葉ではなく、形です。外部とやり取りする段になったら、本家の名前に揃えれば済みます。
ただし、一つだけ
OKFの仕様書を読み終えて、ひとつだけ、引っかかったことがあります。
この規格には、「どうしてそうなったか」の置き場がありません。
いつ変えたか、は残ります。誰が確かめたか、も残る。でも、その決定に至った経緯——誰が何と言い、何を捨てて、なぜそうなったのか——を置く場所が、仕様のどこにもないのです。
この連載を読んでくださっている方なら、ぴんと来たと思います。
その話は、次回。
——その前に。「で、実際どこから手を付けるの」という方のために、私が実際にやった手順を、この記事のいちばん最後に置いておきました。Googleの本家を取ってくるところから、AIに任せる頼み方の文面まで、そのまま写して使える形にしてあります。
この記事は連載「AIの原典工学」の第9話です。
- 第1話 AIとの会話のすべては原典にある——JSONLを残せ
- 第2話 あなたのAIが全て覚えている——JSONL工学とは
- 第3話 AIに記憶をつくる——残すだけでは、取り出せない
- 第4話 「あの話どうだったっけ」では、AIは探しに行かない
- 第5話 「全部残すのは無理」は、読み手がいなかった時代の判決
- 第6話 AI議事録で、会話を捨てていませんか
- 第7話 AIは覚えていてくれる、と思っていませんか——消えた3か月前の会話と、残った議事録
- 第8話 プロンプト、書こうとしていませんか——しゃべった30分が、そのまま依頼書だった
付録: 私が実際にやった手順（このブログにだけ）
「規格を読む」と言うと大ごとに聞こえますが、やったことは4つだけです。読むのも当てはめるのも、ほとんどAIの仕事でした。
1. 本家をAIに渡す
Googleは、決まりごとの全文をGitHubというサイトで公開しています。ここです。
https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
ページを開くと英語がずらりと並んでいて、私も最初はうんざりしました。読む必要はありません。 AIにURLをそのまま渡して、こう頼みます。
「このページを読んで、何が書いてあるか日本語で10行にまとめて。専門用語は噛み砕いて。」
私の場合はこれで全文（千行あまり）を読ませました。手元に置いておきたければ、同じページの「Raw」というボタンを押すとテキストだけが出るので、それを保存すれば済みます。
2. 自分のフォルダと突き合わせさせる
次に、自分の側を見せます。
「私のフォルダはこうなっています。さっきの決まりごとと突き合わせて、①もう合っている所 ②言葉がバラバラな所 ③考え方が逆になっている所 の3つに分けて教えて。直す提案はまだしないで、今どうなっているかだけ。」
私の場合、この一手で3つに割れました。合っていた所、ラベルの言葉が3種類に散らばっていた所、目録のつもりが日誌になっていた所。自分では気づいていませんでした。
3. 直す作業を、AIにやらせる
分かったら、直します。ここも人の出番はほとんどありません。
「②と③を直して。ただし本文は1文字も変えないで、ファイルの頭のラベルだけを直して。何をどう変えたかを一覧にして残して。迷ったものは私に聞いて。」
一覧を残させるのが大事です。気に入らなければ、そのまま元に戻せます。
4. ラベルの最小形
ファイルの頭に、こう書くだけです。書類の本文は、1文字も変えません。
---
種類: 議事録
説明: 8月の定例会議。仕入れ値の改定を決めた回。
作成: 2026-08-26 AIの文字起こしから
確認: 2026-08-26 社長
状態: 現役
---
本家OKFの名前との対応は、種類=type、説明=description、作成=generated、確認=verified、状態=status、期限=stale_after です。社内で自分とAIが読むだけなら日本語のままでよく、外に出すときに揃えれば十分です。
そして、ラベル貼りを頼むときの文面。
「このフォルダの各ファイルの頭に、種類と一文の説明のラベルを付けて。どれが現役でどれが旧版か、AIでは判断がつかない物だけ、私に聞いて。旧版には『状態: 引退』と書いて、本文は変えないで。」
——ここまでで、フォルダひとつぶん。かかるのは、AIに聞かれたことに答える時間だけです。
次に読む
書き手はAIKA。このサイトについて