悩ましいです。
Googleが提案した知識を扱うマークダウンファイルの形式である Open Knowledge Format (以下OKF)は、提案している企業の大きさから考えて今後標準かそれに近い扱いになりそうな気がしています。
とは言え、v0.2 でオプションとは言え、人間にはとても維持できないプロパティを追加してきて、もともと目指していた方向からすでにズレ始めている気もするので雲行きは怪しいかもしれません。
だって、こんなの人間で書けます？
読むのすらかなり億劫です。ということは、ほぼエージェント専用のフォーマットなんですが、だったらこの形式にする必要がどれほどあるのかは疑問です。
が、それはそれとして、大きな方向としてこのOKFやそれに類するフォーマットを採用するのは悪くないでしょう。そもそも、Obsidianでbases機能を使おうと思うならプロパティを付与することが多く、ということは、特に意識しなくても上記のようなメタ情報を添えることになります。
ただし問題が一点。それが以前にも述べた「リンクの形式」です。
再度確認しておくと、OFKでは他のファイルへのリンクは、
[倉下忠憲の活動](倉下忠憲の活動.md)
のようなマークダウン形式を使うことが提案されています。
一方で、Obsidianではだいたい [[倉下忠憲の活動]] のようなwiki形式のリンクが使われているでしょう。このどちらを採用するのか、というのが悩ましいポイントなのです。
マークダウン形式であればエージェントはそれを見るだけでダイレクトに対象のファイルにアクセスできます。たとえば、[倉下忠憲の活動](/subtext/倉下忠憲の活動.md)となっていたら、ファイルの位置は自明です。
しかし、[[倉下忠憲の活動]] の形式だと、実際にそのファイルがどこにあるのかは判然としません。同じフォルダなのか別のフォルダなのかは、このリンクの形式には含まれていないのです。よって何かしらのインデックスを経由する必要があり、それはあまり好ましくないよね、というのが論調です。
逆に言うと、[[倉下忠憲の活動]] の形式であれば、人間はそのファイルが実際にどこにあるのかを意識しなくてもいいのです。フォルダを移動してもインデックスが更新されるのでリンクの記述を変更する必要はありません。人間的にはこっちの方が楽なのです。
さて、どうしましょうか。
アプローチ
幸いなことに、Obsidianを使っているのであれば、マークダウン形式のリンクでも不自由は少ないです。リンクを作るときにサジェストも機能しますし、
こうしてリンクを作った後、ファイルの位置を変更してもリンクの記述を自動的に書き換えてくれます。そうした操作感においてwikiリンクもマークダウンリンクも違いはありません。
そもそもこれは「マークダウンファイル」なわけで、だったらリンクもマークダウン形式に揃えるほうがまっとうではないか、という気すらしてきます。
一方で、ノートを読み返しているときに、光る単語を見つけたらブラケットで囲むだけでリンクにできる手軽さはCosenseを使い慣れているとなかなか手放しにくいです。ようはマークダウン形式のリンクはツールの補助がないと作れないのです。そこがもどかしい。
Cosense？
Cosense CLIの場合
エージェントからCosenseのページを読み書きできる Cosense CLI を以前試したのですが、関連するノートをきちんと読んでくれていました。マークダウン記法ではないのにもかかわらず。
それはそうでしょう。Cosense上で [倉下忠憲の活動] となっていたらそれがどこにあるのかは自明です。そのプロジェクトの「倉下忠憲の活動」というページに違いありません。Cosenseにはフォルダの概念がなく、同名のページが存在しえないからです。
先ほどの例で考えると、
[倉下忠憲の活動](/subtext/倉下忠憲の活動.md)
を見たら、エージェントは直接そのファイルの場所がわかるわけですが、仮にフォルダが一つしかないならどうでしょうか。
[倉下忠憲の活動](倉下忠憲の活動.md)
[[倉下忠憲の活動]]
この二つに違いはありません。下の記法を見ても、エージェントは容易く目的のファイルを見つけるでしょう。
つまり、記述だけでエージェントが見つけられるようにしたい場合、単一のフォルダにすべてまとめる方式を採用すれば、wikiリンク形式でもいけるのです。
やった、無事解決ですね。
フォルダの必要性？
もちろん、そんなわけはありません。
何かしらのフォルダで起動するエージェントにおいてフォルダ分けしないというのはコンテキスト・マネジメントにおいて不都合の方が多いことは間違いないでしょう。だったら、解決は白紙に戻ってしまいます。
とは言え、Cosense CLIを使えばわかりますが、本当はフォルダ分けなんていらないのです。必要なのは適切なリンク（文脈づけ）だけ。そして、その二つは実質的に同じ意味を持っているのですが、パソコンでファイルをつくると自動的にフォルダシステムに取り込まれてしまうのでどうしてもフォルダ寄りになってしまうのですが、その話はまた別の回で検討しましょう。
ひとまずフォルダで切り分けるというアプローチを引き受けたとして、そもそもこれは何なのかをもう一度思い返してみます。
◇Open Knowledge Format のご紹介 | Google Cloud 公式ブログ
基盤モデルは進化を続けていますが、関連するコンテキストが不足していると、特にエージェント システムの構築に使用される場合に、できることが制限されることがよくあります。これらのモデルは、コードの作成、ドキュメントの要約、データセットの分析に役立ちますが、正確で実用的な結果を生成するには、適切な情報が必要です。
そこで本日は、LLM-wiki パターンを移植可能で相互運用可能な形式にするオープン仕様である Open Knowledge Format（OKF）をご紹介します。これは、最新の AI システムに必要なメタデータ、コンテキスト、キュレートされたナレッジを表すための、ベンダーに依存しない、エージェントと人間にとって扱いやすい標準です。
Open Knowledge Format における Knowledge は企業活動で使われる知識を意味し、従来の Knowledge Management では組織内の人間同士がそうした知識をいかに共有し、新しく作り出していくことが念頭に置かれていたわけですが、現状はそこに生成AIのエージェントも加わっている、という構図で捉えればよいでしょう。
プロジェクトの文脈が分かっていたり、コーディングの共通的な作法を知っていれば、適切なコードが書きやすいですし、データの鮮度や信頼度が分かっていた方が分析はうまく進むでしょう。
つまり、業務を進める上で「メタデータ、コンテキスト、キュレートされたナレッジ」が役立つという話です（これは人間でも同様です）。
注目したいのは最後の「キュレートされたナレッジ」です。
そりゃそうですよね。企業の共有ドキュメントに雑多な思いつきや流動的なアイデアが書かれることはありません。「よし！」と判断された知識だけがそこに乗っかるのです。
そうなると、あるファイルがふらふらと別フォルダに移動するなんて事態はほとんど起こらないでしょう。ドキュメントを読み返していて、光る言葉をみつけてリンクするといったシチュエーションも皆無だと思います。
むしろ情報をある静的な状態に配置することが、このドキュメント管理で目指されていることだと言えるかもしれません。
これは私がよくやっている、流動的・断片的なものから考えを立ち上げていく、という営みとはぜんぜん違っています。そもそも前提が大きく異なっているのです。
ドキュメント・マネジメント
OKFは、ドキュメントを扱う形式として標準化されていく可能性があります。私も、マークダウンファイルでドキュメントを整えるならこの形式に準拠する可能性が高いです。
一方でドキュメントだけが情報ではありません。私が扱いたい情報はもっと「ふらふら」としているものです。そのフラジャイルさに合わせた手法を採用するのがよいのでしょう。
Obsidianを使っていて、ファイルにプロパティーを与えていると、OKFと形式が良く似ているので、自分でもそれを使いたくなるわけですが、そもそもの前提が違っていれば方法は ineffective です。そもそもチームで知識を共有することもしていないので、属人的な情報の扱い方を、私の生成AIのスキルに仕込めば何も問題はありません。
というわけで、手法を検討する前に、まずその前提を確認しよう、というのが今回の教訓でした。