AIネイティブな
ドキュメントサーバーがない問題

01 — THE MISSING LAYER

AI機能は増えた。しかし、人が書く前提は残っている

最近、AIの記憶や参照先として、Obsidian、Notion、GitHub、Google Drive、SharePointなど、さまざまなサービスが使われている。どれも便利である。人が文書を書き、人が編集し、必要なときにAIが検索したり要約したりするなら、かなりのことができる。

ただ、ここには一つ古い前提が残っている。文書の一次著者は人間であるという前提だ。

これからは、会議録、設計書、顧客別の引き継ぎ、FAQ、業務マニュアル、調査メモまで、AIが最初から書く文書が増える。新しく書くだけではない。別のデータや会話が変わるたびに、関連する文書をAIが継続的に更新するようになる。

そうなると、AIが文書を書けることだけでは足りない。誰の権限で何を読んだのか。どの情報からこの一文が生まれたのか。更新前後で矛盾がないか。誰が承認したのか。機密情報を含む段落だけ共有から外せるか。文書を作る速度より、文書の変更を安全に流す仕組みが重要になる。

AIネイティブなドキュメントサービスとは、AIに入力欄を足したノートではない。AIが一次著者になることを前提に、変更を統治する基盤である。

02 — TODAY'S TOOLS

既存サービスは、どこまで近いのか

既存のサービスに機能がないわけではない。むしろ、必要な部品はすでにかなり揃っている。ただし、それぞれ別の主語を中心に設計されている。

Notionは「プログラムから触れない」のではない。Google DriveやSharePointも「AIからアクセスできない」のではない。問題は、アクセスできるかどうかではなく、AIによる大量で継続的な変更が中心動線になっているかである。

GitHubはこの意味でかなり近い。AIはテキストを編集し、Pull Requestを作り、差分を見せ、自動チェックを通せる。一方でGitHubはコード共有のための場所であり、ある顧客にはこの章だけ、別の部署には承認済みの版だけ見せる、といった文書特有の配布には向いていない。

03 — DEFINITION

ノートアプリではなく、ドキュメントサーバー

ここで「ドキュメントサーバー」と呼びたいのは、単にファイルを保存するサーバーではない。

プログラムにとってデータベースが、保存場所であると同時に、権限、検索、更新、整合性を引き受けるように、AIにとってのドキュメントサーバーも、文書のライフサイクルを引き受ける。雑にいうと、文書のデータベースとGitHub Actionsを一つにしたものである。

人間にも読みやすく、AIにも読みやすい。この両立は、リッチな画面とプレーンテキストのどちらかを選ぶ話ではない。同じ文書に、人間向けのViewとAI向けの表現を持たせる話なのだと思う。

04 — DOCUMENT AS PROGRAM

文書も「書く」から「定義して生成する」へ

ドキュメントをプログラミング可能にするとは、APIから文章を保存できることだけではない。文書の意味、部品、制約、出力先をコードのように定義し、そこから必要な文書を生成できることだと思う。

人間は同じ説明をコピーし、少しずつ書き換えてきた。AIはコピーと書き換えを非常に速くできる。一方で、その速さは、同じ意味の文章が大量に複製され、どれが正しいかわからなくなる速さでもある。だからAIが得意な生成を使うほど、原本と再利用の仕組みが必要になる。

document ProductGuide {
  source  product://catalog
  reuse   block://security-definition

  locale  reader.locale
  view    reader.role
  figure  architecture as svg

  test price == catalog.current_price
  test consistent("support-hours")
  test citations.required
}

もちろん、この文法そのものは仮のものである。重要なのは、自然言語をすべて形式言語にすることではない。文章は自然言語のまま、再利用、制約、生成、表示のルールを機械が扱えるようにすることである。

05 — SOURCE AND VIEW

HTMLは原本か、読者のためのViewか

Claude Codeチームの「The unreasonable effectiveness of HTML ↗」という記事では、AIの出力形式としてMarkdownよりHTMLを使う理由が紹介されている。表、CSS、SVG、インタラクションを一つの成果物に含められ、レスポンシブに表示でき、共有もしやすいという主張である。

AIがHTMLを生成し、読者に合わせて情報の密度や操作方法を変えるという方向にはかなり納得できる。特に、人間が原稿を一行ずつ編集するのではなく、AIへ修正を依頼するなら、「人が直接編集しやすい」というMarkdownの利点は相対的に小さくなる。

一方で、すべての原本をHTMLにすればよい、とはまだ思わない。HTMLは表現力が高いぶん、内容、見た目、操作が一つのファイルに混ざりやすい。同じ事実を使ったHTMLが読者ごとに生成されるなら、完成したHTMLを原本にするのではなく、その手前に共通の文書モデルが必要になる。

原本は再利用と検査に向いた構造で持ち、HTMLは読者に合わせて生成する。AIネイティブなのはファイル形式ではなく、SourceからViewを作る流れのほうである。

MarkdownかHTMLか、という二択ではない。AIが読み書きするSource、人間が判断するView、その間にあるテストとレンダリング。この三つを分けることが、ドキュメントサーバーの役割なのだと思う。

06 — REQUIREMENTS

AIネイティブに必要な7つの機能

1. AIを主体として扱う権限管理

   人のAPIキーを使い回すのではなく、エージェントごとにID、役割、有効期限、読める情報、書ける範囲を持つ。検索結果にも権限を適用する。

2. AIエディタから直接つながる接続性

   REST API、SDK、CLI、MCPなどから、文書の取得、検索、変更案の作成、レビュー依頼まで完結する。画面操作の自動化を前提にしない。

3. 変更案を中心にしたレビュー

   完成したページを見比べるのではなく、どの節を、なぜ、何から変更したかを差分として見る。重要度に応じて人または別のAIが承認する。

4. 公開前の自動チェック

   リンク切れ、表記、個人情報、機密情報、根拠のない数値、古い参照、文書間の矛盾を検査する。コードにおけるテストやLintに近い。

5. 一文まで戻れるリネージ

   どの会話、データ、モデル、指示から生成され、誰が承認したかを残す。誤りを見つけたとき、影響する文書を逆引きできる。

6. 権限を守る検索

   キーワード、意味、メタデータを合わせて検索する。検索インデックスを作る段階から権限を保ち、見えてはいけない情報の存在も漏らさない。

7. 文書の一部を安全に共有する機能

   原本を複製せず、承認済みの版、特定の章、顧客向けViewだけを公開する。原本の更新と配布物の関係も追跡する。

人間にも同じ機能が必要だった。しかし、人間が自分の手で限られた数のページを編集する世界では、多少の手作業で吸収できた。AIが多数の文書を横断して更新するなら、手作業で吸収していた曖昧さが一気にシステムの欠陥になる。

07 — CHANGESET

ページではなく、変更セットを管理する

既存の文書管理は「このページを開いて編集する」が基本である。AIネイティブな世界では、「この事実が変わったので、影響する12文書に変更案を作る」が基本になる。

ここで管理すべき主役はページではなく、変更セットである。例えば価格が変わったとき、料金表、営業資料、FAQ、契約時の説明、社内マニュアルを別々に編集するのではない。一つの変更理由から複数文書の差分が生まれ、まとめて検査され、公開される。

reason: "料金体系が変更された"
source: decision://pricing/2026-08-11
agent: docs-updater

targets:
  - docs/pricing.md
  - docs/sales/overview.md
  - docs/support/faq.md

checks:
  - no_stale_price
  - evidence_required
  - customer_view_safe

approval: pricing-owner

これはドキュメントをプログラミング言語にするというより、ドキュメントの変更手続きをプログラミング可能にするということだと思う。本文は自然言語のままでよい。一方で、構造、権限、検査、配布はコードから扱える必要がある。

08 — MINIMUM PRODUCT

最初に作るなら、何が必要か

全部入りの新しいNotionを作る必要はない。編集画面は質素でもよい。一方で、構造化された原本から、変更、検査、承認を経て、読者向けのViewを生成する一周は、最初から必要になる。

既存のGit、オブジェクトストレージ、検索エンジン、ID基盤を組み合わせても作れるかもしれない。重要なのは新しいエディタを作ることではない。一つの構造化された原本から、安全で検査可能な変更を経て、読者に合った文書を生成する共通基盤を作ることである。

09 — CONCLUSION

人は編集者から、統治者へ

AIがすべての文書を書く、と言うと、人間が文書からいなくなるように聞こえる。実際には逆かもしれない。

人間は、一文ずつ書き換える作業から離れ、何を正しいとするか、誰に何を見せるか、どの変更に承認が必要かを決める。文章の編集者から、文書システムの統治者へ役割が移る。

NotionにAIを足す。SharePointをAIに読ませる。GitHubでMarkdownを管理する。しばらくは、これらの組み合わせで十分な場面も多い。

一方で、AIが組織の文書を継続的に書き換えるところまで進むと、どこかで限界が来る。そこで必要になるのは、もっと賢い文章生成ではない。権限、再利用、差分、テスト、リネージ、検索、読者別Viewを、AIの速度で扱える文書基盤である。

AI時代の文書管理で足りないのは、エディタのAI機能ではない。AIが書き続けても、組織が壊れないためのサーバーなのだと思う。

それが既存サービスの進化として生まれるのか、新しいカテゴリとして生まれるのかは、まだよくわからない。ただ、自分なら新しいノートアプリを考える前に、「AIによる変更をどう統治するか」から考えたい。