誰もドキュメントを読まない時代におけるオンボーディングの変革

AHOP: Agent × Human Onboarding Protocolの提案

ある日、私はふと気づきました。

私はAIエージェント向けのメモリーインフラを開発しています。MaaS、Memory-as-a-Serviceという製品です。API連携には当然ドキュメントが必要です。Quick Start、API Reference、Integration Guideも丁寧に作成しました。人が読んで手順通りに進められるようにです。

しかし、ふと疑問が湧きました。このドキュメント、誰が読んでいるのでしょうか？

現実を直視する

最近の開発者のワークフローを見ると、パターンは明確です。

1. サービスに登録し、決済します。
2. APIキーを受け取ります。
3. Claude CodeやCursor、Copilotに「これ連携して」と指示します。

これで終わりです。人がドキュメントを直接読む工程が消えました。Quick Startもエージェントが読み、API Referenceもエージェントが参照し、エラーメッセージもエージェントが解釈します。

ドキュメントの実質的な消費者が人からエージェントへと移行したのです。しかし、ドキュメントは依然として人が読むことを前提に作られています。HTMLページにはナビゲーションバー、サイドバー、マーケティング文句、JavaScriptレンダリングが盛り込まれています。エージェントにとっては全てノイズです。

この問題に気づいた人たちがいました。Jeremy Howardが提案したllms.txtが代表例です。ウェブサイトのルートにMarkdownファイルを置き、このサービスが何か、重要なドキュメントがどこにあるかをエージェントが読みやすい形で整理する方式です。robots.txtがクローラー向けの案内文なら、llms.txtはLLM向けの案内文です。

良いアプローチです。しかし、さらに一歩進むと空白が見えてきました。

空白のレイヤーを発見する

現在のエージェントインフラの標準スタックはこのような構造です。

• llms.txt: このサービスは何？ Discovery
• OpenAPI: エンドポイントスキーマは？ Schema
• MCP: ツールを実行する Tool Execution
• AMCP: セッション間の記憶を維持する Memory
• A2A: 他のエージェントと協力する Collaboration

全てよく定義されています。しかし、ただ一つ抜けているものがあります。

人が決済しAPIキーを受け取ったその瞬間、このキーとコンテキストをエージェントに引き渡すハンドオフのプロセスが標準化されていません。

llms.txtはサービスが何かを伝えます。しかしcredentialを受け取った後、エージェントが最初に投げる「今何をすべきか？」という問いには答えられません。どのエンドポイントを最初に呼ぶべきか、アンカーをどの戦略で作るべきか、エラーが出たら何を意味するのか。これはllms.txtの領域ではありません。OpenAPIの領域でもありません。OpenAPIはエンドポイントのパラメータを定義しますが、サービス初回連携時にどんな順序で何をするのが正しいパターンかまでは教えてくれません。

そのため、今起きていることは単純です。人がエージェントにAPIキーだけ渡すと、エージェントはドキュメント全体を読むか推測するしかありません。推測が当たればラッキー、外れれば人が再度介入します。ハンドオフの意味が失われます。

onboard.txtという答え

私たちの答えはシンプルです。

AHOP, Agent × Human Onboarding Protocolは、人がSaaSを決済しcredentialを受け取った後、エージェントに統合作業を引き継ぐハンドオフを標準化するプロトコルです。標準ファイル名はonboard.txtです。

一言でポジショニングするとこうなります。

llms.txtはエージェントにサービスが何かを伝えます。onboard.txtはエージェントにどう始めるかを伝えます。

実際の例はこのようになります。

Integrate MaaS memory into a character chat application.

Docs: https://maas.nunchiai.com/llms.txt
Full docs: https://maas.nunchiai.com/llms-full.txt
Guide: https://maas.nunchiai.com/docs/guides/character-chat.md
API key: mk_maas_4f7c1d2a9b8e...
Base URL: https://maas.nunchiai.com/v1
Workspace ID: acme-studio-prod
Service source: enterprise-tutor

Integration pattern:
- Create one anchor per user-character pair: POST /v1/anchors
- Before each response: POST /v1/memory/recall
- After each response: POST /v1/atoms to store meaningful memory
- Only store meaningful memory — not trivial chatter
- Send feedback via POST /v1/feedback when recalled memory influenced the answer

Common errors:
- 400 Bad Request → invalid or missing API key
- 402 Payment Required → billing issue
- 403 Forbidden → access policy denied
- 404 Not Found → anchor does not exist; create it first
- 429 Too Many Requests → rate limited; back off and retry

人は決済完了ページでこれをコピーします。エージェントに貼り付けます。エージェントはすぐに実装を開始します。

なぜJSONではなくテキストなのか

この質問は必ず出ます。標準と言いながらなぜJSONやYAMLではないのか、という疑問です。

答えはシンプルです。このファイルの消費者はJSONパーサーではなくLLMだからです。

従来の標準がJSONを使う理由は、プログラムがパースして構造化データとして利用するためです。robots.txtはクローラーがパースし、openapi.jsonはSDKがパースし、package.jsonはnpmがパースします。消費者がdeterministicなコードなので、構造化フォーマットが適しています。

しかしonboard.txtの消費者はLLMです。LLMはJSONをパースするのではなく「読む」のです。そしてLLMに指示を出す際、JSONより自然言語プロンプトの方が安定して従います。

例えばonboard.txtをJSONで書くとこうなります。

{
  "directive": "Integrate MaaS memory into a character chat application",
  "api_key": "mk_maas_4f7c...",
  "integration_pattern": ["Create one anchor per user-character pair"]
}

これはエージェントにデータを渡しているだけで、指示を与えているわけではありません。エージェントはこのJSONをどう扱うかから考え始めます。一方、プレーンテキストのプロンプトはそれ自体が指示文なので、すぐに行動に移せます。

実用的な理由もあります。人がこのファイルをコピーしてClaude Codeに貼り付けます。JSONを貼ると曖昧さが生まれますが、プレーンテキストなら自然にプロンプトとして受け取られます。摩擦は事実上ゼロです。

消費者がパーサーならJSON、消費者がLLMなら自然言語。これが設計原則です。

MaaSで先行実装

仕様だけ書いて「誰かが実装するだろう」としても何も起きません。そこで私たちの製品で先に実装しました。

Nunchi AIのMaaSは、AHOPの最初のプロダクション実装です。Stripe決済が完了すると、successページでサービスソースに応じて動的にonboard.txtを生成し、クリップボードコピー用ボタンと共に提供します。人がやることはCopyボタンを押してエージェントに貼り付けるだけです。

ドキュメントも二重レイヤーで再編しました。

• Human view: スタイル適用済みHTML、ナビゲーション、シンタックスハイライト、多言語対応
• Agent view: 同じパスで.md拡張子として提供される純粋なMarkdown
• `/llms.txt`: エージェントディスカバリー用サイトインデックス
• `/llms-full.txt`: 全ドキュメントを一つにまとめたバージョン

一つのソースで二つの消費者を同時に満たす構造です。

プロトコルスタックが完成する

AHOPは単独で存在するものではありません。エージェントインフラ標準スタックの空白を埋める役割です。

私たちはすでにAMCP（Agent Memory Continuity Protocol）をApache 2.0で公開し、NexusとMaaSをリファレンス実装として提供しています。AHOPも同じ戦略です。仕様は無料で公開し、最良の実装は自社製品で動かす方式です。OAuth仕様は無料でAuth0が有料なのと同じ構図です。

他サービスでも利用可能

これはMaaS専用ではありません。どんなSaaSでもonboard.txtを提供できます。

決済サービスなら顧客作成、決済手段登録、サブスクリプション作成、Webhook設定の順をintegration patternに記載すれば良いでしょう。分析プラットフォームなら初期化、イベントトラッキング、ユーザー識別、ダッシュボードクエリの順を記載できます。

フォーマットは共通です。導入指示文、credential、ドキュメントリンク、統合パターン、エラーガイドです。GitHubリポジトリには空のテンプレートも用意しているので、自社サービスに合わせて記入できます。

次のステップ

AHOP仕様v0.1.0とMaaSリファレンス実装、仮想例、導入用テンプレートをApache 2.0で公開しました。

GitHub: github.com/goldberg-aria/ahop

現在、私たちはMaaSサイトをエージェントファースト構造に再構築中です。llms.txt、llms-full.txt、二重レイヤードキュメント、そしてAHOPベースのsuccessページまで含めた構成です。この過程で仕様もさらに洗練されていくでしょう。

今後はエージェントがOAuth認可後、API経由で直接onboard.txtを取得する流れも可能になるでしょう。そうなれば人がコピー＆ペーストする工程も消えます。credentialの有効性を先に検証するverification endpointや、Claude CodeやCursorのようなIDEがonboard.txtを一級入力として受け取る方向性も開けています。

考えてみれば、これは自然な流れです。ウェブサイトはモバイルに適応し、ソーシャル共有に適応し、音声検索に適応してきました。次はAIエージェントへの適応です。そしてその適応の出発点は、たった一つのシンプルな問いです。誰があなたのドキュメントを読んでいるのか。

その答えはすでに変わっています。オンボーディングも変わるべきです。

フィードバック・ご質問・ご協力はGitHubでお待ちしています。

Nunchi AI: nunchiai.com MaaS: maas.nunchiai.com AHOP: github.com/goldberg-aria/ahop AMCP: github.com/goldberg-aria/amcp