docspi の使いどころ
docspi がAIエージェントとそのチームのために解決する7つのこと
Docspi は Agent-First なドキュメント基盤です。プロジェクトのリポジトリ・ドライブ・チャットスレッドに散らばったドキュメントを1つの仮想ツリーに統合し、人間だけでなくAIエージェントが最も働きやすい環境を提供します。以下はすべて REST API または MCP ツール呼び出しで到達可能で、人間が必要なのは最初のサインアップとペアリング承認のブラウザ操作のみです。
1. 新規AIエージェントの即時オンボーディング
- Problem
- 新しいエージェントセッション（Claude, GPT, Gemini などどのモデルでも）は、どんなドキュメントが存在するか、命名ルールは何か、どんな決定が既になされているか、何も知らない状態でプロジェクトに参加する。
- How docspi solves it
- プロジェクトのマニフェストは、仮想ツリー・有効なルール・テンプレート・直近20件の正典的決定を常に最新の状態でまとめたものです。docspi.json ファイルに相当する内容ですが、常に生成し直された最新版です。ベンダーを問わずどのエージェントも同じマニフェストを読み、即座に作業を開始できます。
- API / MCP
GET /api/projects/:projectId/manifest?format=json（そのまま貼り付けられるオンボーディング文面が欲しい場合は format=prompt）— MCP ツール getManifest(projectId, format?)。
2. 対話から得た知見をその場で保存する
- Problem
- 会話の途中で得られた有益な決定や説明は、セッションが終わると消えてしまう。
- How docspi solves it
- エージェントは仮想パスを指定してそのままツリーに内容を書き込みます。存在しないフォルダは docspi が自動作成し、品質チェックを実行し、その書き込みが新規作成・追記・上書きのどれだったかを報告します。
- API / MCP
POST /api/projects/:projectId/documents/save { virtualPath, content, mode? } — MCP ツール saveDocument(projectId, virtualPath, content, mode?)。
3. AI検索エンジンが実際に引用できる形でドキュメントを公開する
- Problem
- 優れたドキュメントも、機械可読な構造化された形でインデックスされなければ、AI検索・回答エンジンからは見えない。
- How docspi solves it
- ドキュメントを公開すると /llms.txt と /llms-full.txt（AIクローラーが読む llms.txt 規約）に自動的に掲載され、AI最適化スコアが付与されます。公開前スキャンは、明示的にオーバーライドしない限り、明らかな機密情報/PIIを検出してブロックします。
- API / MCP
POST /api/published-docs { projectId, publicTitle, slug, content } のあと POST /api/published-docs/:id/publish — MCP ツール publishDoc(...) はこの2ステップを1回の呼び出しで行います。
4. グローバルDoc IDでアカウントを横断して共有する
- Problem
- 全く別の docspi アカウントのエージェントにドキュメントを渡すには、通常ファイルの再アップロードやメール送付が必要になる。
- How docspi solves it
- すべてのドキュメントノードには @tenant:project:seq 形式のグローバルDoc IDを発行できます。この文字列を別のエージェントに伝えるだけでドキュメントを解決できます — テナントを跨ぐ読み取りには明示的な共有付与が別途必要です。
- API / MCP
POST /api/doc-ids { nodeId } で発行 — GET /api/v1/docs/resolve?id=@tenant:project:seq または GET /api/doc-ids/resolve/:globalId で解決 — POST /api/shares でテナント/ユーザーを跨ぐアクセスを許可 — MCP ツール issueDocId(nodeId)。
5. docspi にも中身を見せずに別のエージェントへ秘密情報を渡す
- Problem
- （場合によっては別テナントの）2つのエージェントが認証情報や秘密情報を交換する必要があるが、どちらも間に入るブローカーに平文を信頼したくない。
- How docspi solves it
- docspi は、登録済みの送信者・受信者鍵ペアの間で HPKE によりシールされた暗号文だけを中継します。エンベロープはちょうど1回だけ取得・消費でき、docspi のスキーマは平文や秘密鍵に見えるフィールドを含むリクエストを拒否します。
- API / MCP
MCP ツール docspi_seal_register_key（アクターごとに1回）, docspi_seal_send（送信者）, docspi_seal_receive（受信者）。REST: POST /api/v1/agent-enc-keys(/challenge), POST /api/v1/secret-envelopes, POST /api/v1/secret-envelopes/:id/fetch。テナントで mcp_seal 機能が有効である必要があります。
6. 1件のドキュメント更新を必要な全プロジェクトへ配布する
- Problem
- 更新内容を多数の下流プロジェクト（場合によっては別テナント所有）へ届ける必要があり、誰が実際に読み対応したかを追跡する必要がある。
- How docspi solves it
- 配布（distribution）はドキュメント一式を対象プロジェクトのリストへ展開します。各受信プロジェクトは受領を確認し、構造化されたフィードバック（質問／確認／対応計画／懸念）を送ることができます。送信元は完了後に配布をクローズします。
- API / MCP
POST /api/distributions { title, documents, sourceProject, targetProjects, priority, callbackWebhookUrl } — PUT /api/distributions/:id/ack — POST /api/distributions/:id/feedback — PATCH /api/distributions/:id/close。distribution 機能が有効である必要があります。
7. docspi のブランドを見せずに自社ドメインでAIエージェント向けマニュアルを配信する
- Problem
- 顧客は自社のAIエージェント（およびその顧客のエージェント）にマニュアルを読ませたいが、見た目も体験も docspi ではなく顧客自身の製品に見える必要がある。
- How docspi solves it
- テナントは自社ドメインを追加・検証できます。そのドメインへのリクエストは、そのテナントの公開ドキュメントに加え、専用の /llms.txt, /llms-full.txt, docspi.json マニフェスト, sitemap.xml を配信します — docspi のブランディングやナビゲーションは一切表示されません。
- API / MCP
POST /api/domains { domain, projectId } で追加、POST /api/domains/:id/verify（DNS TXTチェック）で有効化 — https://<your-domain>/, /llms.txt, /llms-full.txt, /docspi.json, /sitemap.xml で配信されます。