知識はゲートで区切られるべきではない

ここ数年、AIシステムに知識を与えるということは、インフラを構築することを意味していました。ビジネスやデータ、意思決定に関する知識をエージェントに持たせたい場合、標準的な手法が取られてきました。ドキュメントをチャンク化し、埋め込みモデルを選択し、ベクトルデータベースを立ち上げ、検索をチューニングし、SDKでラップします。野心的であれば、その上にグラフを構築することさえありました。そうこうしているうちに、企業の知識はもはや読めるものではなくなり、クエリを通じてパイプラインの背後にあるサービスを通じて問い合わせるものとなり、選んだフレームワークに所有されるようになりました。 私は、しばらくの間静かに真実であり、今や明白になりつつあることを主張したいと思います。そのアプローチ全体が、ゲートで区切られる必要のない知識をゲートで区切っていたのです。そして、その修正はほとんど恥ずかしいほど単純です。それはMarkdownです。 ツールにロックされた知識の時代 RAGは良いアイデアでした。それを貶すためにここにいるのではありません。コンテキストウィンドウが小さく、モデルが高価だった頃、Retrieval-Augmented Generationは実際の問題を解決しました。プロンプト全体に知識ベースを収めることはできなかったため、関連するスライスを取得してそれを供給しました。Graph RAGは、エンティティと関係の構造化されたグラフを構築することで、それをさらに推し進め、モデルが孤立したチャンクではなく接続を横断して推論できるようにしました。 これらの技術は機能します。しかし、そのコストを見てください。知識をRAGシステムに入れるには、システムだけが理解できる形に変換する必要があります。ドキュメントは埋め込みになります。関係はデータベースの辺になります。知識はパイプラインに入った瞬間に人間が読めなくなります。エージェントが実際に「知っている」ことを確認したい場合、ファイルを開くだけではできません。それをロックしたのと同じ機械に対してクエリを実行する必要があります。 そして、すべてのチームがこれをゼロから再構築しています。すべてのエージェントビルダーが同じコンテキストアセンブリ問題を解決しています。すべてのカタログベンダーが同じデータモデルを再発明しています。知識自体は、それを生成したサーフェスの背後に、次のツールが翻訳なしでは読めない形式で閉じ込められてしまいます。それがゲートなのです。厳密にはペイウォールではありません。フォーマットウォールです。あなた自身の知識が、それを有用にするためのツールによって読めなくなっています。 私たちが再発見し続けたもの そのインフラがすべて構築されている間、人々が実際にエージェントを日常的に扱っていた方法では、もっと静かなことが起こっていました。彼らはMarkdownを書き始めました。Claude CodeやCodexを使ったことがあるなら、意識せずにCLAUDE.mdやAGENTS.mdを書いたことがあるでしょう。プロジェクトがどのように機能するか、どのような規約に従うべきか、何に触れてはいけないかなどを書き留め、エージェントは改善されました。埋め込みなし。ベクトルストアなし。ただ、セッションの最初にモデルが読むファイルです。 このパターンは、さまざまな名前で現れ続けました。リンクされたノートでいっぱいのObsidianボルト。デザインがどうあるべきかを示すDESIGN.md。エージェントが実行間で記憶すべきことのためのMEMORY.md。「メタデータ・アズ・コード」リポジトリ。これらすべては同じ本能です。知識をプレーンテキストとして書き留め、ピースをリンクし、モデルに直接読ませます。 LLMが本当に、確実に得意とするフォーマットは、標準化するには原始的すぎると考えていたものだったことが判明しました。Markdownは、儀式のない構造を持っています。見出し、リスト、リンク、少量のフロントマター。モデルがナビゲートするのに十分な足場であり、人間が同じファイルを読んで即座に理解するのに十分少ないのです。 私たちは何年もかけて、知識を機械がクエリできるものに圧縮しようとしてきました。機械は、結局のところ、ただ読みたいと思っていました。 Karpathyが静かな部分を言った Andrej Karpathyは、彼のLLM Wikiパターンでこれに名前を付け、それが私にとってすべてを明確にしました。そのアイデアは3層のセットアップで、すべてプレーンファイルで行われます。モデルが不変として扱い、決して編集しない生の素材のsources/ディレクトリ。モデルが生成し所有するMarkdownページのwiki/：要約、概念ページ、エンティティページ、それらを結びつける統合。そして、エージェントが全体を維持する方法を指示するスキーマファイル、CLAUDE.mdまたはAGENTS.md：ページがどのように構造化されているか、新しいソースがどのように取り込まれるか、クロスリファレンスがどのように最新に保たれるか。 その根底にある洞察は、RAG全体を再定義するものです。Karpathyの言葉は引用する価値があります。「LLMは飽きないし、クロスリファレンスを更新し忘れることもないし、一度に15個のファイルを触ることができる。」人間が個人用Wikiを放棄する原因となる事務作業は、まさにLLMが得意とすることなのです。 個人用Wikiは常に同じ理由で死んでいました。それらを最新の状態に保つのは面倒で、人間は面倒を嫌います。しかし、その面倒さは言語モデルが免疫を持っている唯一のものです。それらは、文句を言わずに100個のファイルにわたるリンクの再作成、要約の再作成、矛盾の調整を喜んで行います。 したがって、トレードオフが反転します。RAGは、クエリごとにゼロから知識を再発見し、毎回コンテキストを再取得・再構築します。Wikiは、知識を一度コンパイルし、それを最新の状態に保ちます。クロスリファレンスはすでに存在しています。矛盾はすでにフラグが立てられています。統合はすでにあなたがそれを入力したすべてを反映しています。あなたはすべての質問で検索税を支払っていません。すでに整理されていたものを読んでいます。 そして、それはすべてファイルです。開くことができます。編集できます。Gitに入れることができます。知識は何もゲートで区切られていません。 Googleが実際にリリースしたもの ここでOpen Knowledge Formatが登場し、なぜ私がそれが控えめな発表が示唆するよりも重要だと考えるのかがわかります。6月、Google CloudはOKF（現在はバージョン0.1）を発表しました。その1行の説明は、「LLM-wikiパターンをポータブルで相互運用可能な形式に正規化するオープン仕様」であるということです。より平易な言葉で言えば、誰もがすでに実行していたMarkdown-wikiのインテリジェンスを取り込み、それをベンダーニュートラルな標準に変えることで、あるツールが生成したファイルが別のツールで翻訳なしで読み取れるようにするということです。 その全体像は次のとおりです。OKFバンドルはMarkdownファイルのディレクトリです。各ファイルは1つの概念です：データセット、テーブル、メトリック、ランブック、API、キャプチャしたいものなら何でも。それらは意味のある階層に配置されます。 sales/ ├── index.md ├── datasets/ │ └── orders_db.md ├── tables/ │ ├── orders.md │ └── customers.md └── metrics/ └── weekly_active_users.md 各ファイルには、構造化され、クエリ可能なフィールドのための小さなYAMLフロントマターが含まれています。 --- type: BigQuery Table title: Orders description: One row per completed customer order. resource: https://console.cloud.google.com/bigquery?... tags: [sales, revenue] timestamp: 2026-05-28T14:30:00Z --- # Markdown本文が続きます そして、仕様では少なくとも1つのフィールド、typeが必須です。それ以外は、従うことも無視することもできる規約です。標準的なクエリ可能なフィールドは、type、title、description、resource、tags、timestampであり、それが儀式の範囲です。概念は通常のMarkdownリンクで互いにリンクします。注文テーブルの外部キーは、単に[customers](/tables/customers.md)を指します。これらのリンクは、ディレクトリを関係のグラフに変え、フォルダの親子ネストよりもリッチになります。グラフデータベースを立ち上げることなく、Graph RAGの利点、接続の構造化されたウェブを得ることができます。リンクがグラフなのです。 エージェントが階層を歩く際の段階的な開示のためのオプションのindex.md、および変更履歴のためのオプションのlog.mdがあります。それが全体のモデルです。 私が繰り返し言及するのは、Googleがそれを何でないかと説明している点です。 それだけです。複雑な圧縮スキーム、新しいランタイム、必須のSDKはありません。それは「単なるMarkdown」であり、どのエディタでも読み取り可能で、GitHubでレンダリング可能です。それは「単なるファイル」であり、tarballとして出荷可能で、gitリポジトリでホスト可能で、ファイルシステムにマウント可能です。それは「単なるYAMLフロントマター」であり、少数の構造化フィールドのためです。 仕様は、知識を書く人と消費する人を明確に分離します。人間がバンドルを手作業で作成することも、パイプラインが生成することもでき、エージェント、検索ツール、またはプレーンなMarkdownビューアがそれを読み取ることができます。ロックインなし。SDKによるゲートなし。