目次を作るだけで、AIが的確に選ぶ？ Googleが提唱する「OKF」をObsidianで試してみた

先月、2026年6月にGoogleがOKFという規格を公開した。

Open Knowledge Formatの略で、AIエージェントに読ませるための知識の書き方を、共通の形式として決めましょう、というもの。

その時は、また新しいのが出たな、程度。

その程度だったんだが、@ITのOKFの記事を見かけて、ちょっとObsidianに入れてみるとどんな感じだろう、と。

要は、目次を作ってリンクを貼るだけ

Googleが提唱するオープンフォーマット、なんて聞くと、身構えてしまうかもだけど、OKFがやっていることは、拍子抜けするくらい単純。

要は、目次を作ってリンクを貼って分かりやすくする、ってこと。

新しいファイル形式が増える訳でも、専用アプリが必要な訳でもない。

普通のMarkdownと、フォルダと、リンク。

既にあるものを、どう書いて、どう組み合わせるか。

その、工夫の仕方の違い、だけ。

Obsidianを使っている人であれば、普段やっていることと、ほとんど変わらない。

「OKFの導入方法」をOKFで書く

で、試すにあたって、vault内にひとつ、新たなフォルダを作った。

中身は「ObsidianにOKFをどう導入するか」という検討メモ。

OKFについてのメモを、OKFの形式で書いたってこと。

okf/
├── index.md
├── 01_OKFとは何か.md
├── 02_ObsidianでOKFを使うメリット.md
├── 03_導入方針.md
├── 04_まず最初にやること.md
│   （中略）
└── 10_BasesとOKF_自分に合う情報構造.md

全部で11ファイル。

フォルダの入口になるのが `index.md`。

この `index.md`を例にすると、中身は上下2つの部分に分かれている。

まず、一番上。

---
type: index
title: Obsidian × OKF 導入ガイド
description: ObsidianをAIエージェント経由で使う環境に、OKF的な構造を段階的に導入するための案内
---

`---` で挟んだこの部分は、フロントマターと呼ばれるもので、Obsidianで言えばプロパティにあたる。

本文とは別の、そのファイルについての情報を書いておく場所、って認識で良い。

書いているのは、たった3つ。

• `type` ：ファイルの種類

• `title` ：タイトル

• `description` ：何が書いてあるかの一行説明

OKFで必須なのは、このうち `type` の一行だけ。

あと、推奨として、`resource`（元になったURL）、`tags`、`timestamp`（更新日時）が挙げられている。

必要なものだけ選べば良い、ということ。

仕様書はGitHubで公開されているので、詳しいことは、以下から確認出来る。

要するに、`type` と `description` 、2つの記述があることで、種類と中身が分かるという仕組み。

人間が見ても分かるし、AIが読んでも分かる。

たったこれだけのことではあるが、効果がある。

そして、この `---` から下が本文。

`index.md` の場合は、フォルダ内にどのファイルがあるかの一覧になる。

## 読む順番

1. [[01_OKFとは何か]]
   - OKFの基本的な考え方
   - Obsidian、RAG、MCP、AGENTS.mdとの違い

2. [[02_ObsidianでOKFを使うメリット]]
   - AI経由でメモを探す場合に何が改善するか
   - トークン削減との関係

（中略）

10. [[10_BasesとOKF_自分に合う情報構造]]
   - Basesによる横断的な一覧・管理と、OKFによる階層的な情報設計の使い分け

リンクの下に、一行ずつ説明が付いているだけ。

たったこれだけ。

他のファイルも同じで、一番上にフロントマター、その下に本文、という形式は一緒。

違うのは `type` の中身と、本文が目次ではなく普通の文章になる程度。

注意点として、リンクにObsidianのリンク形式である `[[ ]]` を使っているのは、公式のやり方とは違う。

本来は、一般的なMarkdownのリンク記述。

目次ファイルの書き方も、厳密には記述方法が違っているが、同じMarkdownなのでオッケー。

Obsidian用の、vault内で普段使っている書き方を優先して、OKFの考え方を流用したということ。

規格に合わせて自分の環境を変えるのは、本末転倒なので。

vault全体をOKFにした訳ではなく、この一つのフォルダのみ。

Obsidianの良さは、何も考えずにすぐ書けるところなので、日々の走り書きにまで `type` だの `description` だのを要求し始めたら、それが台無しになってしまう。

よく参照する分野だけ、`index.md` と最小限のメタデータを足すという使い方を前提に、まずひとつ作ってみた感じ。

web制作ではお馴染みな構造

お試しとして、実際にひとつ作ってみて気付いた。

webサイトのディレクトリ構造そのものではないか、と。

本業でweb制作をやっているので、目的ごとにフォルダを作り、その階層にトップページを置き、個別ページをぶら下げて、内部リンクで繋ぐ、というのは日常的にやっている。

どのディレクトリへ置くか、その階層のトップページには何を書くか、子ページをどう分類するか、URLだけで中身を推測できるか、閲覧者が迷わず目的の情報へ辿り着けるか。

サイトを作る時に考えているのは、大体こんな感じ。

OKFで言っていることを、web側の言葉に置き換えてみると、こうなる。

フォルダがディレクトリで、`index.md` がその階層のトップページ。

個別のMarkdownファイルが各ページで、リンクで繋がっているのはサイト内リンク。

名前が違うだけで、やっていることは同じ。

特に分かりやすいのが、フロントマターの扱い。

`description` に「このファイルには何が書いてあるか」を一行でまとめておく、という作業は、meta descriptionを書くのと丸ごと同じ。

検索エンジンに向けて書くか、AIエージェントに向けて書くかの違いでしかない。

`type` の方も、構造化データで「これは商品ページ」「これは記事」と型を宣言するのと、やっていることは変わらない。

つまりOKFは、新しい知識管理の方式を覚えるというより、いつもやっているサイトの情報設計を、そのままvaultの中に持ち込む感覚。

Claude Codeが「必要になったら読みます」って

フォルダが出来たので、Claude Codeに投げてみた。

「このフォルダに目を通して確認して欲しい」とだけ。

返ってきたのが、コレ ↓

11ファイルあるうち、4つは読まずに保留している。

しかも、読んでいない4つを「補足的な内容」と判断した上で。

本文を開いていないのに、なぜ補足だと分かったのか。

さっきの `index.md` に書いた一行説明と、各ファイルの `description` を見ただけ。

OKFで言うところの「段階的開示」というやつで、上から順に全部読むのではなく、目次で当たりを付けて、必要な分だけ開く、という辿り方。

「まずindexを読んで」と指示した訳でもない。

これまでなら、何か聞くとvault全体を検索して、関係の薄いファイルまでガサッと開いて、その中から答えを組み立てていた。

読まなくて良いものを、読ませずに済む。

正直、こんなイイ感じに動くとは思ってもみなかったので、コレはイケるんじゃね？と。

AI向けのはずが、人間にも読みやすい

もう一つ、作ってみて気付いたことがある。

AIが探しやすいからと試してみたのに、自分で見返すにも分かりやすい。

考えてみれば当たり前で、やったことといえば、主題ごとにファイルを分け、フォルダの役割を決め、入口に目次を置き、各ファイルに概要を書いて、関連するものをリンクで繋ぎ、深すぎない階層にした、というだけ。

全部、webサイトで人間が迷わないようにするためにやってきたこと。

AI向けの最適化のつもりが、蓋を開けてみれば、昔からある情報設計をなぞっていただけ、と。

効かせるなら、スキルにする

ただ、構造を作っただけでは足りない部分もある。

`index.md` から読む、という順番をAI側に伝えておかないと、これまで通りに、vault全体の検索からってなる可能性も高い。

かといって、CLAUDE.mdやAGENTS.mdといった、常時読まれる設定ファイルに書くのは違う気もする。

vault全体をOKF化していない以上、そのルールが効いて欲しいのは、OKF構造で作ったフォルダに対してだけ。

なので、専用のスキルとして切り出して、その分野の話をする時だけ呼び出す形にする。

中身は仕様の説明ではなく、探す順番だけ書いておけば良い。

1. 最初にindex.mdを読む
2. 候補を最大3件選ぶ
3. frontmatterのtype・descriptionを確認する
4. 必要な本文だけ読む
5. 見つからない場合だけVault全体を検索する

常時読み込ませる訳ではないので、余計なトークンも食わない。

部分的にしか導入しないなら、スキルの形が丁度良い。

分野が増えたら、その分だけスキルを分ければ済む。

道筋で見る

こういうものの効果は、返答が正しいかどうかだけでは判断できない。

見るべきなのは、AIがどうやってそこに辿り着いたか。

最初に `index.md` を読んだか？、いきなり全文検索していないか？、関係のないファイルを開いていないか？、追記する時に正しいファイルを選べたか？

冒頭の「残り4つは必要になったら読みます」は、まさにこの観点でみると、合格の反応。

Basesとの違い

Obsidianの機能で言うと、Basesが近いのでは、と思われるかも知れない。

ノートを行、プロパティを列として、表形式で扱えるやつ。

読書リストや買い物リストはBasesで作って使っている。

以前、obsidian-skillsについて書いた時にも触れた。

自分の場合、Basesを使うのは、リストとして扱いたい時。

一覧して、並べ替えて、条件で絞り込む。

読んだ本や欲しいものを管理するには、ピッタリ。

対して、OKFで考えているのは、蓄積した情報を、後から的確に取り出せるようにすること。

しかも、自分が取り出す場合と、AIに探させる場合の両方で。

そういう意味では用途が違うので、併用して何の問題もない。

ただ、Basesもプロパティで構造化されている訳で、そこから情報を引っ張り出すのは、当然ながら理にかなっている。

エクセルやスプレッドシート、Notionのデータベースを日常的に触っている人なら、表として持っておいた方が探しやすい、となるはず。

一覧から目当てのものを見つける方が早い、という感覚は、確かにある。

自分がディレクトリ構造の方に反応したのは、前述の通り、web制作で普段からその形に触れているから。

情報をどういう形で捉えるのが自然か、という違いでしかない。

構造で分かりやすくなるのが面白い

そもそもOKFは、まだバージョン0.1。

公開されてひと月ちょっとで、今後どうなるかも分からない規格なので、vault全体を預ける段階ではない。

それでも、一つのフォルダで試した限りでは、確かな手応えがあった。

今回のやり取りで良さそうだったので、もう少し試してみよう。

目次を作ってリンクを貼る。

たったそれだけで、AIにも人にも読みやすくなる。

規格として定着するかどうかはさておき、この形自体は、web制作をやってきた人間にはすんなり入ってくるはず。