社内資料をAIエージェントから引ける状態にするため、Google Cloud のオープン仕様 Open Knowledge Format（OKF） を導入しました。使いたいと思ったのは人間側で、当社の課題に効きそうだと踏んだうえで、仕様の裏取りをAIに任せました。そこから先も同じ調子です。棚卸しと執筆はAIが担い、人が読んで指摘し、AIが直す。1日でバンドル63概念ができています。この往復のどこを人が持ち、どこをAIが持ったのかを共有します。
（+ index 15・log 1）
（233KB）
（未解決 0本）
下書き完成まで
verified）を付ける。始まりは人間の側にあった
発端は、OKF という仕様が公開されたことを知ったことでした。当社には課題がありました。ファイルサーバと OneDrive には十数年分の Excel・PDF が積み上がっていて、人間はどこに何があるか何となく知っているのに、AIエージェントに「予算の元データはどれ？」と聞くと平然と間違えます。
足りていないのはデータではなく文脈だという見立てはありました。「この帳票は月次締めの後じゃないと数字が合わない」「このフォルダは検討段階で、確定はあっち」といった知識は担当者の頭の中にしかなく、ファイルを何万個読ませても埋まりません。OKF はまさにその層を書くための仕様に見えました。
とはいえ、見えただけです。本当に当社の課題に使えるのか、v0.2 の仕様が実際に何を要求するのか、導入コストはどれくらいか。ここを確かめる作業をAIに任せました。Claude Code の調査係に「社内ファイルサーバの資産を Claude から調査可能にしたい」と投げると、仕様原文・リファレンス実装・解説記事を集めて A4 数ページの調査レポートを返してきました。出典リンク付きなので、気になった箇所は原文に当たれます。
この形が今回いちばん機能した組み方でした。「使えそうだ」という勘は人が出し、「本当に使えるか」の検証はAIが速く広くやる。人が仕様を通読してから判断していたら、着手までに数日かかっていたはずです。
OKF とは何か
返ってきた要約を読んで採用を決めました。判断が速かったのは、OKF 自体が単純だったからです。中身は、組織の知識を YAML frontmatter 付き Markdown ファイルのディレクトリツリーとして表現するだけ。スキーマレジストリも中央サーバも要りません。要点はこれだけです。
| 要素 | 内容 |
|---|---|
| 必須 | frontmatter に非空の type が1つ。これだけ |
| 推奨 | title / description / resource（原本へのポインタ） / tags |
| 予約ファイル名 | index.md（そのディレクトリの目次）、log.md（更新履歴） |
| 信頼性 | generated: {by, at} / verified: [{by, at}] |
| 鮮度・状態 | stale_after: YYYY-MM-DD / status: draft｜stable｜deprecated |
そして仕様は、読む側のツールに対して「任意項目の欠落・未知の type 値・未知のキー・壊れたリンク・index.md の欠落を理由にバンドルを拒否してはならない」（must not）と定めています。
ここが決め手でした。語彙が多少揺れてもバンドルは壊れません。壊れるのは「探せなくなる」ことだけ。厳密なスキーマを先に固める必要がないので、AIに書かせながら直していけます。正解が最初から分かっていない社内ナレッジのような対象に、この寛容さは向いています。
調査でいちばん重要だった一文
OKF はファイル変換フォーマットではない。
AIの調査レポートは、この一文を警告として最初に置いてきました。
「ファイルサーバの大量ファイルを OKF 化する」と言うと、xlsx や PDF を Markdown に変換する作業を想像します。実際こちらもそう捉えかけていましたが、それは OKF がやろうとしていることではありません。その方向で始めれば、何万ファイルもの変換を延々と続ける作業になっていたはずです。
resource: でポインタを張った薄い層（63概念・4,255行）だけを新たに書く。
OKF が作るのは、原本はファイルサーバに置いたまま、それが「何なのか・どう使うのか・何に注意するのか」だけを書いた薄い層です。原本へは resource: でポインタを張ります。
---
type: 帳票
title: 案件実績抽出ツール
description: 案件別の実績を抽出するVBAツール。
confidentiality: 社内限
resource: file://fileserver/share/ツール/案件実績抽出ツール.xlsm
status: stable
generated:
by: claude-code/opus-5 # ← AIが書いた
verified:
- by: human:<担当者id> # ← 人が確認した
---
本文には、原本を見ただけでは分からないことだけを書く。
どのシートを見るのか、いつ更新されるのか、過去にどこで間違えたのか。confidentiality は当社独自の必須項目として追加。変換すべきはファイルの中身ではなく、人の頭の中にある文脈です。この区別が最初にはっきりしたことが、作業が終わらない方向へ流れなかった理由だと思います。
粒度 ―「1ファイル＝1概念」にしない
もう1つ、早い段階で決めておいてよかったのが粒度の基準です。放っておくとAIは丁寧すぎる方向に倒れます。「請求書フォルダを概念にして」と言えば、5,000通ぶん作りかねません。作り終わらないうえ、探しにくい砂の山ができるだけです。
| 例 | |
|---|---|
| ❌ 個票ごと | 請求書_2025-04_○○商事.md を5,000個 |
| ✅ 場所と規則を1概念 | フォルダ/請求書2025.md に「命名規則・格納単位・誰が作るか・探し方」 |
| ❌ シートごと | 経費予算.xlsx の全シートを個別に |
| ✅ 帳票1つ＋注意点 | 帳票/経費期初予算.md に「見てよいシート／進行中で見てはいけないシート」 |
迷ったときの問いは「これを個別に書かないと、AIが致命的に間違えるか？」。Yes なら1概念、No ならまとめる。この一文を指示に入れておくと、出力の粒度が安定します。
76,037 → 8。この比率感そのものを、語彙定義ファイルに実例として書き残しました。次にAIが概念を作るとき、これが基準線になります。一度言葉にした判断基準は、以後ずっと効き続けるのが良いところです。
「見なくてよい」と書くことも知識
書いてみて初めて分かったこともあります。「このフォルダは会社ナレッジではないので見る必要がない」という概念には、一見なんの価値もありません。しかし書かないと、ファイル数の多さを見たAIが「重要そうだ」と誤認して探索コストを浪費します。4万ファイルのフォルダに「見なくてよい」と1行書くのが、最も費用対効果の高い1概念でした。
読んで、指摘して、直す
棚卸しと執筆はAIが進めました。ファイルサーバ側は対象12フォルダ・14,219ファイル。そこから起こした概念のうち37概念を人間がレビューしました。多くは読んでそのまま verified を付けられる出来でしたが、一部で誤りや補足が出ました。件数としては多くありませんが、放置したときの影響が違います。出てきた指摘は3種類に分かれます。
1. 事実として間違っている
AIが書いた概念に、当社のある営業上の取り組みについて「そうした実績はない」と断定する記述がありました。事実として誤りです。その取り組みは例年きちんと実施している定例プロセスで、結果が数字に表れにくかった事情が別にあっただけでした。
これは重い誤りでした。経営判断の前提に直結する記述だったからです。
原因もはっきりしています。概念を書いた時点でまだ作成途中だった社内の分析レポートを、AIが一次情報として鵜呑みにしたのです。レポート側では検討過程の暫定的な記述にすぎなかったものが、バンドルには確定した事実として転記されました。しかも出所が同じなので、そのレポート3箇所にも同じ記述が残ったままでした。バンドルとレポートを合わせて是正しています。
作成途中の資料は結論が動きます。それを一次情報として扱わない、という指示は以後明示するようにしました（当社には「この帳票は進行中なので指定した2シート以外は参照しない」という運用が既にあり、同じ罠です）。AIは与えられた資料の完成度を判断できないので、ここは渡す側で線を引く必要があります。
「AIが書いたまま誰も見ていない」状態は、内容が尤もらしいほど危険です。文章として自然で、論理も通っていて、ただ事実が違う。この形の誤りは、業務を知っている人が読む以外に検出手段がありません。
2. 調べ方が足りていない
契約書フォルダの命名規則を調べさせたところ、From- 接頭辞（当社が受注側）を見つけて「これが規則だ」と分類してきました。しかし To-（当社が発注側）を見落としていました。原因は単純で、一覧の先頭18件しか見ておらず、アルファベット順で To- に届いていなかったのです。
To- が1件も入りません。「規則は From- だ」という結論はここで生まれました。
実測し直すと、書類の区分によっては To- のほうが多数でした。結論が逆転しかねない見落としです。以後、「分類や傾向を述べる前に必ず全件で集計する」を指示に明記しています。「先頭18件を見た」は「全体を見た」ではありません。この手の指摘は、一度伝えれば次からAI側が守ってくれます。
3. ファイルに書かれていない情報がある
3つめは、AIには手が出しにくいところです。「この案件フォルダは単発なので概念にしなくてよい」「このフォルダは検討段階で、確定はあっち」「この会議体はもう動いていない」。ファイルを何万個読んでも出てこない情報です。
実際、AIは棚卸しの結果から「社内規程は全部が古い版で止まっている」と書いてきました。読んでみると、これは過度な一般化でした。主要な規程はきちんと最新版に更新済みで、古いままなのは一部だけ。「全部古い」で片付けていたら、手を入れるべき対象が特定できないままでした。逆に、規程が版ごとにどこに保管されているかを網羅的に洗い出せたのはAI側の働きです。どちらか片方では、この結論には届きませんでした。
やりとりの結果を機械可読にする
指摘して直すだけでは、次に読む人（あるいは次のAI）に「これは人が見たのか」が伝わりません。OKF はここに仕掛けを持っています。verified の有無と by の書式から、3段階が導出できます。
human: の有無だけで段階が変わるので、「AIが書いたまま」と「裏を取った」が機械的に区別できる。未レビューを引用するときに警戒できるのが利点。
運用はそのまま、下書きは generated: {by: claude-code/opus-5}、人が目を通したものだけ verified: [{by: human:<担当者id>}]。現在は63概念のうち37概念が人間レビュー済みで、残りは status: draft のままです。「AIが書いたまま」と「裏を取った」が機械的に区別できていることが重要で、区別できていれば、未レビューのものを引用するときに警戒できます。
仕様準拠かどうかは30行のシェルスクリプトで検査しています。index.md と log.md 以外の全 .md が frontmatter を持ち、非空の type を持つか。それだけです。
$ bash tools/check_conformance.sh
-----
適合 63 件 / 不適合 0 件 / 警告 0 件
内部リンク 490 本 / 未解決 0 本このスクリプトもAIに書かせました。壊れたリンクは NG ではなく WARN 扱いにしてあります。仕様上、読む側は壊れたリンクでバンドルを拒否できませんし、「まだ書いていない概念へのリンク」は次に書くべきものの印として意図的に許容しているためです。
効いているかを、AIに聞いて確かめる
「役に立つ気がする」で終わらせないため、会話履歴を持たない新規セッションに質問を投げました。
投げた質問は「予算の数字が食い違っている。どれが正なのか」。素朴に答えるなら、予算関連の Excel を探して更新日の新しいものを掴むところです。返ってきたのは「Excel の帳票はどれも出力にすぎない。一次データは別に Access のデータベースがあり、食い違ったらそちらを確認する」という回答でした。バンドルに書いてあるとおりです。
これは棚卸しの最大の発見でもありました。各期がそれぞれ独立したDBファイルを持ち、しかも前期のものも更新され続けているので、「前期は確定済み」という前提を置けません。文脈を持たないセッションが、Excel の山に惑わされずここへ辿り着いたのは、狙いどおりの挙動でした。
index.md を階層に置く設計（段階的開示）。ルートの索引から必要な分野にだけ降りるので、バンドルが育っても1回の質問で読ませる量は増えない。
この質問で実際に読ませた量も出しておきます。ルートの索引32行 → 帳票の索引18行 → 予算管理DBの概念72行の計122行。バンドル全体は4,255行ありますが、毎回全部読ませる必要はありません。index.md を階層に置く設計（段階的開示）が、そのままコンテキストの節約になっています。
どこを人が持ち、どこをAIが持ったか
振り返ると、役割は次のように分かれていました。
| 人が持ったもの | AIが持ったもの |
|---|---|
| やる理由と、使う仕様の選定 | 仕様の裏取りと、比較・要約 |
| 「原本は変換しない」という前提 | その前提のもとでの実作業 |
| 粒度・調べ方の基準を言葉にすること | 基準を全域へ一貫して適用すること |
| 事実の訂正と、除外の判断 | 網羅性・速度・形式の一貫性 |
どちらか片方では成立しませんでした。63概念・4,255行・内部リンク490本を1日で作るのは人手では無理ですし、その中に混じった「尤もらしいが事実でない」記述はAIだけでは検出できません。速く広く作る側と、業務の実態と突き合わせる側が、短い周期で往復することが今回の要点でした。
1つ付け加えるなら、この往復には読む側の業務知識が要ります。AIの出力は自然で読みやすいので、業務を知らない人が読むと全部正しく見えます。「AIに任せて人はレビューする」形は、人の作業量を減らす一方で、レビューする人に求められる知識の水準は上げます。社内での利用を広げている今、ここは意識しておきたい点です。
持ち帰りポイント
- OKF は「YAML frontmatter 付き Markdown のディレクトリツリー」。必須項目は
typeひとつ。始めるのに要るのは仕様の通読ではなく、書く対象を決めること。 - 「使えそうか」の勘は人が出し、「本当に使えるか」の検証はAIに任せられる。着手までの時間が大きく縮む。
- 変換フォーマットではない。原本は動かさず、
resource:でポインタを張り、文脈だけを書く。ここを取り違えると終わらない作業になる。 - 「1ファイル＝1概念」にしない。76,037ファイル → 8概念。AIは丁寧すぎる方向に倒れるので、粒度の基準は先に言葉にする。
- 基準は一度言葉にすれば以後効き続ける。「全件集計してから分類する」も同じ。
- 作成途中の資料を一次情報として渡さない。AIは渡された資料の完成度を判断できないので、暫定的な記述がそのまま確定事実として転記される。線を引くのは渡す側。
- 人が見たかどうかを機械可読にする。
generatedとverifiedの2段階。尤もらしい誤りが一番危ない。 - 読む側に業務知識が要る。人の作業量は減るが、レビューに求められる知識水準は上がる。
