■1. きっかけ
「OKF（Open Knowledge Format）」というルールを知った。散らかった業務ドキュメントをAIが自力で辿れる形式に整える話で、エンジニア的に言えば Docs-as-Code + 軽量ナレッジグラフ。実体はただのMarkdownファイル群で、構成要素は5つだけ。
要素 中身 札 ファイル冒頭のメタデータ（ type: 議事録等）1件1ファイル 同じことを2箇所に書かない（DRY / Single Source of Truth） リンク ファイル同士を繋ぎ、山を地図にする。未作成先へのリンクもOK 受付（index） フォルダ入口の案内役1枚。AIはまずここを見る 更新記録 CHANGELOG。新しい順 面白いのは、この整理作業自体もAIにやらせろと言っている点。人間はコードレビュー的に味見するだけでいい、と。
ここに引っかかった。整理をAIに丸投げしていいなら、その境界はどこにあるのか。掘っていったら、OKFの話を離れても使える結論に着地したので書いておく。
■2. 生ドキュメントを丸投げすると答えが浅くなる理由は2つある
- まず自分が最初に思ったのは「ゴールを与えないとAIは平均値を取りに行く」ということ。次トークン予測なので、目的が曖昧なら最も無難な続きに収束する。だから素人には「それっぽい」、その業務に精通している人ほど「知ってるわ」になる。評価者の解像度が高いほど平均値の粗が見えるという非対称性がある。
- ただしこれは**プロンプト側（何を求めるか）の話で、OKFが問題にしているのは入力側（何を渡せるか）**だった。この2つは別の軸で、両方効く。
- 試しに、完璧なゴールを与えたと仮定してみる。「A社案件の見積もりが当初比で30%膨らんだ原因を、意思決定の時系列で特定して」——十分に具体的だ。それでもPDF10枚をベタ投げすると答えは浅くなる。AI側からは、
- どのファイルが議事録でどれが見積書か（種別が見えない）
- v1とv2、どちらが生きているのか（鮮度が見えない）
- 「この決定はあの見積もりを受けたもの」という因果の線（関係性が見えない）
- 探しに行く先が地図のない山なら、結局手近なところを拾って平均に戻る。整理すると、ゴール不在＝出力側の平均化、構造不在＝入力側の平均化。
■3. コンテキスト長が伸びても解決しない
- 「構造なんか整えなくても、コンテキスト長が伸びれば全部読ませればいいのでは」という反論はあり得る。実際そこそこ有力に聞こえる。
- だが長文脈が解決するのは「全部入るか」だけで、「どれが正か」は入力が全部入ったところで解けない。むしろ全部入れた分だけ矛盾する記述が同時に見えて、平均を取りに行く。長文脈は問題を消すのではなく、可視化するだけ。
- これは人がやるときと同じで、それっぽい資料がたくさんあってどれを参照すればいいか分からない状態では、意図したアウトプットにならない。
- ただし人間には逃げ道が2つある。「これ最新どれですか」と聞けることと、更新日時やファイル名の
_final_v2_修正版みたいな周辺情報を勝手に読むこと。AIはどちらも封じられている。そもそも聞き返さないし、渡されたPDFの中身しか見ていない。 - つまりこれはキャパシティの問題ではなく判断の問題で、別のレイヤーにある。
■4. 「とりあえず貼って後で直す」は正しい。ただし条件付き
- では札付けをどうするか。自分の答えは「とりあえず貼っておく」でいい、というもの。間違っていたら後からルールを加えればいい。0→1でルールを設計するより、なんとなく整理されたものをちょっと変えるほうが効率がいい。
- 理由は修正コスト < 設計コストという非対称性。白紙から正しいルールを演繹しようとすると、実物を見ていないぶん抜けだらけの完璧主義になる。逆に、ズレた叩き台があれば「ここが違う」は一瞬で分かる。判断は生成より安い。
- これはOKFが言う「未作成ファイルへのリンクがエラーにならない＝スタブ先行で走りながら育てる」と同じ思想でもある。構造もルールも、走りながら育てればいい。
- ただしこの戦略には前提が1つある。「後で直す」が成立するのは、間違いに気づけるときだけ。
- AIが貼る札の怖さは、間違っていてももっともらしいこと。
type: 議事録をtype: 提案書と貼られたらたぶん気づく。しかしstatus: 最新を古いファイルに貼られたら、気づく契機がない。そのまま参照されて、間違った答えが自信満々で返ってくる。しかも一度貼られた札は「整理済み」に見えるので、二度と疑われない。AI生成コードのレビューと同じ罠で、動くコードのバグは見つけにくい。
■5. 解決は札の設計。「解釈」を貼らず「事実」を貼る
ここでの結論は、タグ付けルールが悪い、ということ。
status: 最新ではなくdate: 20260726と日付を入れれば解決する。AIも人間も差を見つけやすいルールにすればいい。一般化するとこうなる。
札には「解釈」ではなく「観測可能な事実」を書く。
status: 最新は解釈。新しいものが来た瞬間に嘘になるので腐るし、何と突き合わせれば間違いと分かるのかが無いので反証できないdate: 20260726は事実。腐らないし、間違っていれば中身と突き合わせて一発でバレる
DB設計で言えば「導出可能なカラムを持たない」＝正規化。最新かどうかは日付から毎回計算すればいい。持つから不整合が起きる。
そしてこれは■4の「間違いに気づけない」問題も同時に解いている。検証可能な札しか貼らせなければ、AIに丸投げしても安全になる。人間とAIで分業するのではなく、札の設計で解ける。
■6. 結論
- AIに丸投げしていいのは、出力が検証可能な作業。
- 逆に、検証不能な判断を出力させると、間違いが発見されないまま下流を汚染していく。危ないのは「AIが間違えること」ではなく「間違えたことに気づけない形で出力させていること」のほう。
- だから任せるかどうかを迷ったときに問うべきは「AIにできるか」ではなく、「その出力が間違っていたとき、自分はどうやって気づくのか」になる。ここに答えがあれば任せていいし、無いなら任せる前に出力の形式を変えたほうがいい。
- 札付けの話から始まったが、そのままAI活用全般の線引きとして使えそうなので、しばらくこの基準で判断してみる。
■7. LINK
※ 動画内では「OKFは2026年6月にGoogle Cloudが発表した新フォーマット」とされているが、一次情報は未確認。導入検討時は公式情報にあたること。またOKF形式のファイル群は誰でも書けるため、出所不明のものを読ませるとプロンプトインジェクションのリスクがある点にも注意。