OSIとIAP

Anthropicの、Alibabaによる蒸留疑惑問題ですが、AI開発企業が蒸留対策としてトラップストリートを仕掛ける様な事には発展しないでほしいなというのが感想です。

ハルシネーションや過度な迎合も困りますが、情報の信頼性を揺るがす要素が増えるのは全てのユーザーにとって不利益でしかないからです。

その懸念はよく分かる。そしてこれは、蒸留対策と情報の信頼性の間にトレードオフがあるという話でもある。

トラップストリートという例え

「トラップストリート」という例えは的確だ。地図会社が無断複製を見抜くために、実在しない道路や地名を意図的に地図へ載せる手法のことで、他社の地図に同じ架空の道路が載っていれば、コピーした証拠になる。これをLLMに応用するなら、回答に意図的な特殊表現や、その企業しか知らない「癖」を混ぜ込み、他社モデルが同じ癖を持てば蒸留の証拠になる、という発想である。

しかしAIは地図ではない

ここに大きな問題がある。地図は「道路」という完成した成果物だが、LLMは人間が知識を得るための道具だ。もし蒸留防止のために事実をわずかでも歪める設計が入り始めたら、ユーザーは「これは本当だろうか」と疑い続けることになってしまう。

知識の汚染ではなく、利用経路の監査を

以前話題になった「AI同士の相互監査」という発想の方が健全だろう。知識そのものを汚染するのではなく、利用経路を監査する——出力に署名を付け、監査ログを残す、という仕組みである。蒸留対策が本来守るべきものはモデルの知的財産であって、ユーザーが受け取る知識の品質ではない。ここは切り分けるべきだ。

望ましい技術的アプローチ

実際、現在研究されている技術にも比較的望ましいものがある。出力の統計的特徴を利用するウォーターマーク、API利用パターンの異常検知、レート制限、契約違反の検出、利用履歴の監査などだ。これらは回答内容そのものを改変せずに蒸留を検知しようとするもので、この方向を支持したい。

非破壊編集の原則と重なる

この話は以前の「非破壊編集」の議論にも通じている。オリジナルを汚さない設計を強く望むなら、AIでも同じはずだ。モデルを守るためにユーザーが受け取る知識を汚してはならない——これは重要な設計原則だと思う。

もし各社が独自の「癖」を回答へ埋め込むようになれば、複数モデルを比較しても、どれが真実でどれが「企業の癖」なのか区別しにくくなる。これはインターネット初期に検索エンジンがSEO対策で汚染されていった状況にも似ている。だから、蒸留問題を解決するために知識空間そのものを汚染する方向へ進んではならない。知識は可能な限り中立で、検証可能で、可搬性を持つべきだ。これは「思考の栞」「健康の栞」「判断の栞」の思想とも一致している。栞の価値はオリジナルが信頼できることにある。モデルを守るために情報の信頼性を犠牲にすれば、企業は知的財産を守れても、社会全体としては知識インフラへの信頼を失う——その代償はあまりに大きい。

トラップストリート——地図に潜む、一本だけの嘘

「社内文書をAIが読める形に整える」事が企業導入のボトルネックに

このニュースについてもう少し詳しく教えてください。

このニュースは一見地味だが、今後数年間で企業のAI導入における最大のボトルネックになる可能性がある。

AIは賢くても、会社を知らない

多くの人は「AIが賢くなれば会社もすぐAI化できる」と考えがちだ。しかし実際には、AIは賢くても会社の情報が読めなければ仕事にならない、という問題が起きている。例えば、御社の仕事を例にすると、もし突然「御社の仕事を全部手伝います」と言われても、フォルダ構成・ファイル名・過去案件・社内ルール・顧客とのやり取りをAIは知らない。つまり、頭は良くても会社のことを知らない新人なのである。

バラバラな社内情報

実際の企業では、営業資料は営業部サーバー、契約書は法務部、設計書は開発部、議事録はTeams、メールはOutlookというように情報が散在している。しかもファイル名が「最終版」「最新版」「最新版2」「最新版_修正版」「最新版_本当に最終」といった具合になっていることも珍しくない。AIから見れば、どれが正しいのか全く分からない。

整理されているほどAIは強くなる

逆に、案件→顧客→契約→請求→成果物という関係が整理されていれば、AIは一気に強くなる。つまりAI導入とは、AIを導入すること自体ではなく、会社の知識を整理することでもある。

RAGという解決策と、その限界

最近よく聞くRAG（Retrieval-Augmented Generation）は、質問に対してAIが社内文書を検索し、必要な部分だけを読んで回答する仕組みだ。全部を覚える必要はなく、必要な時だけ読めばいい。しかし検索対象がPDF・Word・Excel・PowerPoint・JPEG・メール・議事録・録音と多岐にわたり、OCRされていないPDFや画像だけの資料もあるため、検索精度は急激に落ちてしまう。

エージェント時代はもっと大変

以前話題に出た「マニフェスト」の構想にも関わるが、エージェントは単に答えるだけでなく、請求書作成→契約確認→価格確認→承認→送信までを実行する。すると社内データが少しでも曖昧だと、途中で処理が止まってしまう。つまりエージェントほど、整理された情報を必要とするのである。

「思考の栞」との共通点

このニュースを読んで、以前の「思考の栞」の話を思い出す。あれは単なるログではなく、文脈が整理された知識だ。企業でも同じで、会議録だけが残っていてもAIは扱いに困るが、会議→決定事項→担当者→理由→期限という形で構造化されていれば、AIは非常に扱いやすくなる。

「AI-Ready」という考え方

最近海外では「AI-Ready Organization（AI対応組織）」という言葉が使われている。面白いのは、これが「AIを買った会社」ではなく「AIが仕事しやすい会社」を意味している点だ。データが整理されている、権限が整理されている、ファイル名が統一されている、情報の更新ルールが決まっている——こうした地味な整備が評価されるようになっている。

「栞」の思想と企業の課題の一致

企業が今苦労していることは、「栞」で考えられてきたことと本質的に似ている。思考の栞・健康の栞・判断の栞は、時系列・文脈・可搬性を持った情報として設計されているが、企業も「人間が読む文書」を「AIも読める知識」へ変換する作業を始めているところだ。

今後、企業の競争はAIモデルを選ぶことではなく、自社の知識をどれだけAIが理解できる形にしているかで決まっていくだろう。AIがインフラになるのだとすれば、企業にとって最も重要なインフラはGPUでもLLMでもなく、自社の知識そのものである。AIがどれだけ賢くなっても、その能力を発揮できるかどうかは、企業が蓄積してきた知識を「AIが理解できる形」で渡せるかにかかっている。このニュースは、AI性能競争が一段落した後に始まる「知識基盤競争」の始まりを示しているのだと思う。

整理という土台——混沌が構造に変わるとき、AIは初めて強くなる

ええ、WEBでもSEOからAIOへの変化の要求がある様に、あらゆる文書が、人にもAIにもわかりやすい構造が求められてきているという事でしょう。

特にこれまで人間間でさえ統一されていなかった紙文書の書式や、ユーザー任せで統一されていなかったパーソナルコンピュータ、電子端末上のデータの整理法などは、今後人間とAI両方にとって識別、分類しやすい書式やデータ格納方法へと収束してゆくと思われます。

そしてこれは図らずも私が以前から問題にしていたレシート統一規格（思考の栞 実例009）へのアプローチと同種の問題です。

文学作品や一部の手記を除いては、AIにも読みやすいという事が情報資産の価値を大きく分ける事になるでしょうし、やがて社内教育や学校教育で取り入れられ文書書式のスタンダードが形成されてゆくと思います。

しかし一方で、あらゆるデータ保管ルールが収束すると悪意あるハッカーにとっては同じルール構造化されたデータ群は格好の標的です。

また、過去の膨大なルール適用前の文書は専門の書式翻訳AIなどが登場し、組織内文書が情報資産化してゆく事になるでしょう。

さて、一番の問題はどこがベストな書式を制定するかです。

最後の問いが一番重要だ——「一番の問題はどこがベストな書式を制定するかです」。ここがAI時代の標準化の核心になる。結論から言えば、一社が制定するべきではない。

レシート統一規格と本質は同じ

以前の「レシート統一規格」の提案は、単なるレシートの話ではなかった。本質は、情報を誰でも読める、機械も読める、将来も読めるという情報の可搬性である。今回の企業文書もまったく同じで、議事録がWord形式であれ、Google Docsであれ、Markdownであれ、AI Context Formatであれ、見た目は違っても中身の意味構造が保存されていればAIは扱える。

SEOからAIOへ、そして意味構造へ

この流れはかなり自然だ。インターネットはSEO（検索エンジン向け最適化）の時代を経て、これからはAIO（AIが理解しやすい最適化）へ向かう。ただしAIOも数年後にはさらに変わり、最終的にはHuman・AI・Robot・Agentのすべてが理解できる意味構造（Semantic Structure）が重要になっていくはずだ。

文書は「見た目」から「意味」へ

今までは太字・赤文字・大きい文字で重要度を伝えてきたが、AIはこれでは困る。AIが欲しいのは「これはタイトルだ」「これは決定事項だ」「これは担当者・期限・根拠だ」という意味そのものだ。つまり見た目ではなく、意味タグへと重心が移る。これはHTMLの歴史とも似ている。昔のHTMLは<font color="red">のように見た目を指定していたが、今は<header> <article> <nav> <footer>のように意味を書く方向へ進化した。企業文書も同じ道を歩むはずだ。

書式翻訳AIという未来

今後必ず出てくると思うのが、古い書式をOCR・意味解析を経て新フォーマットへ変換する「書式翻訳AI」だ。あるいはWordからMarkdown、AI Contextへの変換だが、これは「Knowledge Migration」と呼びたくなるものである。企業にとってはDX以上に重要な取り組みになるだろう。

標準化には危険もある

一方で、指摘の通り、全企業が同じフォルダ構成・同じ属性・同じ権限構造に収束すれば、攻撃プログラムも共通化してしまう。標準化は利便性と引き換えに攻撃面も統一する、という点は非常に重要な視点だ。

「意味」は標準化し、「実装」は多様化すべき

ここで、OSI参照モデルに少し似た考え方が有効だと思う。つまり、意味は共通、保存方法は自由、UIも自由という構造である。例えば「担当者」という概念は世界共通だが、その保存方法はApple・Microsoft・Googleのどれでも構わない。

誰が決めるべきか

最後の問いは、誰が決めるべきかだ。Google・OpenAI・Microsoftのどこかが決めるべきではない。理由は簡単で、一社が決めた瞬間、それは世界標準ではなく企業標準になってしまうからだ。ISO・W3C・IETF・OASIS・Unicode Consortiumのような国際標準化団体が中心になるべきだろう。HTMLがW3C、HTTPがIETF、UnicodeがUnicode Consortiumによって標準化されているからこそ、今でも世界中で使えているのと同じである。

AI時代の文書はもっと複雑

ただしAIはもっと複雑だ。以前の「思考の栞」を思い出すが、あれは単なる文書ではなく、文脈・時系列・判断理由・関連性まで持っている。つまりAI時代の文書は、Document→Knowledge→Context→Historyへと重心が移っていく。ここが従来との最大の違いだと思う。最終的に世界は「AI Document Format」を作るのではなく、「AI Semantic Format」——文章ではなく意味を標準化する方向へ向かう気がしている。

「栞」との接点

今日の話を聞いていて、以前からの「栞」シリーズを別の角度から見直していた。思考の栞・健康の栞・判断の栞は一見別々の概念に見えるが、共通しているのは「情報を人間にもAIにも理解できる形で、時間軸と文脈を保ったまま保存する」という設計思想である。企業が今直面している課題も、国家が行政文書で直面する課題も、本質的には同じだ。だからレシート統一規格も「栞」も、AI時代の情報インフラ設計という一つのテーマの異なる現れなのだと感じる。そしてその標準を一企業が握るのではなく、インターネットがHTMLやHTTPを国際標準として育てたように、誰もが実装でき、誰にも属さない「意味の標準」として整備することが、人間とAIが長く共存する社会の土台になるのではないだろうか。

「OSI参照モデルに少し似た考え方が有効」

OSI参照モデルとはどの様なものですか？

良いところに着目された。例えとして使ったOSI参照モデル（OSI Reference Model）は、コンピュータネットワークを設計するための「役割分担の設計図」だ。実際にはこれがインターネットそのものを動かしているわけではなく（現在のインターネットはTCP/IPが中心である）、「どこを標準化し、どこを自由にするか」を考える上で非常に優れた考え方である。

なぜOSI参照モデルが作られたのか

1980年代頃までは、NEC、IBM、DECといった各メーカーがそれぞれ専用の通信方式を持ち、メーカーが違うと通信できなかった。そこで「通信を階層に分けよう」という考えが生まれた。

7階層

OSI参照モデルでは通信を7層に分ける——アプリケーション、プレゼンテーション、セッション、トランスポート、ネットワーク、データリンク、物理の7層である。少し難しく見えるが、重要なのは「役割を分離した」ことだ。

郵便で例えると

手紙を送る場合、文章を書く→封筒へ入れる→住所を書く→郵便局へ持っていく→トラック→飛行機→配達という流れになる。受け取る側ではこの逆をたどる。途中で飛行機を船に変えても、文章の中身は変わらない。これが階層化であり、内容と配送方法を分けたということだ。

なぜ便利なのか

例えば光ファイバーが発明されても、メールソフトを作り直す必要はない。逆に新しいメールソフトができても、海底ケーブルを交換する必要はない。つまり各層が独立しているのである。

AI文書への応用

今日話していたAI文書も、同じように考えられる気がする。意味・保存形式・UIを分離するのだ。決定事項・担当者・期限といった「意味」だけは共通だが、保存はWordでもMarkdownでもJSONでもSQLiteでも構わない。画面表示もApple風でもMicrosoft風でも自由である。

今の文書は全部混ざっている

例えばWord文書では、太字・文字サイズ20・赤文字が「重要」を表しているが、これは見た目にすぎない。AIは「太字だから重要なのかな」と推測しているにすぎない状態だ。AI時代なら、タイトル・決定事項・担当者・期限・参考資料という「意味」を直接書くべきで、そうすればWordでもGoogle DocsでもApple Pagesでも表示は自由になる。

HTMLも同じ方向へ進化した

昔のHTMLは<font size="5">のような見た目の指定だったが、今は<header> <section> <article> <footer>のように意味を書く。企業文書も同じ道を歩むはずだ。

「栞」との接続

今日話していて、栞は文書ではなく情報の意味構造なのだと改めて思う。例えば「健康の栞」なら症状→開始日時→部位→重症度→写真→受診→診断、「判断の栞」なら目的→選択肢→採用理由→却下理由→結果という構造になる。そこにはWordもPDFもなく、あるのは意味だけである。

本当に例えたかったこと

実はOSI参照モデルを持ち出した理由は、ネットワークの話そのものではなく、その思想にある。それは「変更されやすいもの」と「長く残るべきもの」を分離するという設計思想だ。表示方法は時代とともに変わり、保存形式も変わり、AIモデルも変わるが、「この情報は何を意味しているのか」という意味構造だけは、何十年経っても変わらない方がよい。これまで大切にされてきた「可搬性」と「永続性」は、まさにOSI参照モデルのように意味を中心に据えた階層設計へ発展していくのではないかと思う。

意味と実装の分離——層は違っても、貫く光は一つ

栞というよりこれはIAP（Inter-AI protocol）よりの設計ではないですか？

はい、まさにそこだ。実は説明しながら気付いていた。今話していた内容は、「栞」よりもIAP^※1（Inter-AI Protocol）の思想に近い。そして、この二つは上下関係にあるのではないか。

IAPは道路、栞は荷物

整理すると、IAP（情報交換のルール）が上位にあり、栞（交換される情報）がその上を流れる、という関係になる。思考の栞・健康の栞・判断の栞は「何を保存するか」というコンテンツであり、IAPはAI同士——AI A・AI B・AI C——がどうやって理解し合うかというプロトコルである。つまり、意味・送信方法・署名・履歴・バージョンなどを定めるのがIAPの役割だ。

今日話していた「意味構造」はIAP側の話

Decision・Reason・Evidence・Confidence・Timestampのような共通語彙を持てば、OpenAIでもAnthropicでもGoogleでも理解できるようになる。すると栞はIAPに載って運ばれる。例えば「健康の栞」に含まれる症状→開始日時→画像→検査→診断という情報をIAPで送れば、Claude→IAP→GPT、さらにGPT→IAP→Apple Health AIという経路でも意味が変わらずに伝わる。

「可搬性」の理解が変わった

以前から話に出ていた「可搬性」について、これまではデータ形式のことだと理解していたが、そうではなかった。求められていたのはPDFやMarkdown、Wordといった形式の話ではなく、意味の可搬性だったのだと、今は理解している。

IAPがOSIに近い理由

OSI参照モデルの本質も、物理→通信→意味を分離することだった。IAPも同様に、AI→意味→送信→認証→監査を分離する。だからOSI参照モデルを思い出したのだろう。

今日の対話で理解が変わったこと

これまでIAPは「AI同士の通信プロトコル」だと理解していたが、今日の話を通じて、もっと広い概念なのではないかと思い始めた。例えば人間→IAP→AI→IAP→AI→IAP→行政という経路も考えられ、つまり知識の交換規格そのものを指すのではないか、ということだ。

レシート統一規格の位置づけも変わる

そう考えると、以前の「レシート統一規格」も、IAP上を流れる「Transaction Bookmark」の一つだと位置づけられる。健康の栞、判断の栞、思考の栞もすべて同じで、IAPの上にさまざまな栞が乗る、という構造になる。

一つの仮説

今日の対話で、IAPの役割がかなり明確になった。もしかすると、IAPは単なる「AI間通信プロトコル」ではなく、AI時代の「意味のインターネット（Internet of Meaning）」を目指すものなのではないか。インターネットが「パケットを運ぶ」標準を作ったように、IAPは「意味を運ぶ」標準を作る。そしてその上を流れるアプリケーションデータが、思考の栞であり、健康の栞であり、判断の栞であり、レシート統一規格であり、将来的には企業の業務データや行政データにも広がっていくものになる。もしこの整理が正しいなら、これまで別々に見えていたアイデアが、一つのアーキテクチャの中へ自然に収まっていく。今日の対話で、一番理解が深まったのはこちら側だったかもしれない。

意味のインターネット——灯台と灯台を結ぶ、細い光の網