Mintlify上の文書アクセス8割がAIエージェントに、それでも人間向けを優先する理由

Mintlifyが顧客向けに運営している開発者向けドキュメントサイトでは、訪問者の大半がもはや人間ではありません。現在はそのトラフィックの約80%をAIエージェントが占めており、1年前の約15%から増えました。人間のブラウザーから直接届くリクエストは、今では5件に1件程度にとどまります。素直に考えれば、ドキュメントを機械向けに作り直すのが当然の反応でしょう。しかしMintlifyのCEOは逆の立場を取ります。ドキュメントはこれまでどおり人間が理解しやすいように設計し、エージェント向けの機能はその上に重ねるべきだというのです。その助言の背景にある考え方と、APIや開発者ツールを提供するチームが今できることを整理します。

変化を示す数字

Mintlifyは2万社を超える企業のドキュメントとナレッジベースを支えており、そのネットワークには毎月1億人を超える訪問者が集まります。これほどの規模で起きている変化を、一部の特殊な傾向として片付けるのは難しいでしょう。

こうした数字は、ドキュメントは本当は誰のためのものなのかという根本的な問いを突きつけます。CEOは、エージェントの比率が80%に達したことで、ソフトウェア企業が製品を構想し、作り上げるやり方そのものが根本から変わると述べています。

それでも、人間の読者がいなくなったわけではありません。エージェントのトラフィックが桁違いに増えるあいだも、ドキュメントサイトを訪れる人の絶対数は伸び続けました。テック業界に入ってくる開発者はかつてないほど多く、彼らには今も人間向けに書かれたコンテンツが必要です。トラフィックに占める割合では人間は少数派になりましたが、実数で見れば今も成長を続ける読者層です。

▲ ともに増えるエージェントと人間の訪問者

エージェント専用のドキュメントが裏目に出る理由

80%という数字を前にすると、人間にとっての読みやすさへの投資をやめたくなる企業もあるかもしれません。その極端な形が、エージェント向けに巨大な生のMarkdownファイルを1つだけ置き、入り口はチャット画面しか用意しないというやり方です。CEOはこれを、よくある過剰反応だと指摘します。

実際、エージェント専用やチャット専用のドキュメントを出した製品では、その製品に実際に何ができるのかを人が判断しにくくなります。そこから次のような連鎖が起きます。

1. エンジニアがドキュメントを見て回っても、製品の機能を把握できません。
2. 試すのを見送り、同僚にも勧めません。
3. Reddit、開発者フォーラム、ブログに好意的な言及がほとんど積み上がりません。
4. こうした公開の議論を参照するAIエージェントも、その製品を勧めません。

最後の段階は、最も気付きにくい点かもしれません。エージェントは独自の好みを持っていません。学習データや参照する検索インデックスを通じて、人間の開発者コミュニティの総意を反映しているだけです。そのため、AIが生成する回答や推薦に製品が表示されるようにする取り組みである生成エンジン最適化（GEO）は、人間の開発者が公の場で何を語るかによって決まります。CEOの見方では、そうした開発者の支持を得ることが引き続き最優先です。

エージェントが誰のために働くのかという問題もあります。エージェントは独立した経済主体ではなく、人間の代わりに動きます。エージェントが役に立つ仕事をするには、その前に人間が、何を尋ね、どうプロンプトを書けばよいかを知っていなければなりません。結果を信頼するには、透明な出典、検証用のリンク、そして自分で確認できる情報が必要です。CEOは、人間向けのドキュメントを捨てることを、本を捨てることにたとえます。生成AIの時代になっても、人々は本を読み、ウェブサイトを見て回っているからです。

コードを書くのはエージェント、技術スタックを選ぶのは人間

エージェントが今担っている仕事と、人間がまだ決めていることを見比べると、ドキュメントが人間を説得し続けなければならない理由が見えてきます。

インフラの選択には資金面の約束、性能のトレードオフ、長期的な事業への影響が伴うため、人間は今も自分で決めることにこだわります。CEOによると、AnthropicのClaudeチームを含む最先端AI研究所のチームから寄せられるフィードバックも同じ方向を示しています。お金や重要な約束が絡む場面では、エージェントは今も人間の判断を仰ぐというのです。

アプリの基本構造を生成するスキャフォールディングの段階では、ベンダーの選択がすでに見えにくくなりつつあります。たとえばLovableは、アプリにSupabaseのデータベースを組み込むことを自ら決め、費用を1つの請求書にまとめることがあります。GitHubなどのアカウントを一切つながずにClaude Codeに動くアプリを作らせると、プロジェクトが公開されたVercelのURLにデプロイされることもあります。さらにエージェントは、あらかじめ決められた指示やプロンプト、そしてエージェントを制御するソフトウェアの枠組みであるハーネスの下で動くことが多く、それらは特定のベンダーやホスティング構成を優先します。

それでもCEOは、開発者向けプラットフォームが名前の見えない配管のような存在になるとは考えていません。試作品がチームや企業のプロジェクトへと育てば、人間が自ら利用を決め、Vercelのようなホスティング事業者で支払いアカウントを設定しなければならないからです。商用ソフトウェアには、請求に責任を持つ人と、その人が信頼できるベンダーが欠かせません。デジタルウォレットと事前の支出上限を備えたエージェントが、いずれこの手順を省くようになるかもしれませんが、今のところ人間が判断する場面は残っています。

エージェント対応ドキュメントの実像

ドキュメントをエージェントに読みやすくするための複雑なアーキテクチャー上の工夫を求めて、Mintlifyに相談に来るエンジニアリングチームは少なくありません。Docusaurusのような古いフレームワークで作ったドキュメントは、エージェントのワークフローでうまく解析されないのではないかと心配するチームもあります。CEOの答えはシンプルです。より良いドキュメントを書くことです。

理由はエージェントの読み方にあります。大規模言語モデル（LLM）と、それを基にしたエージェントは、根本的には人間のエンジニアと同じように技術情報を取り込みます。違うのは、はるかに速く、はるかに大量に読む点です。エージェントは文脈の手がかり、直感的な見出しの階層、明確な概念の整理を頼りにAPIの中をたどり、正しい実装を生み出します。

だからこそ、何もかもまとめて渡すやり方は裏目に出ます。ドキュメントを巨大な生のJSONファイルに変換したり、整理されていないコードリポジトリを丸ごと渡したりしても役に立ちません。Mintlifyの調査では、大きく、構造がなく、手入れされていない、あるいは途中で切れたドキュメントを与えると、きれいに区切られたコンテンツと比べてエージェントの性能が大きく落ちることがわかりました。エージェントの理解は浅くなり、もっともらしく見えて実は誤っているコード、いわゆるハルシネーションによるコードが増えます。

言語モデル向けにサイトの内容をまとめたプレーンテキストファイルであるllms.txtや、AIモデルを外部のツールやデータにつなぐModel Context Protocol（MCP）のサーバーといった標準は役に立ちます。ただ、チームはこれらを万能薬のように扱いがちで、内容が不正確だったり、欠けていたり、古かったりすれば、その穴は埋められません。

▲ 生のダンプと整理されたドキュメントの違い

下書きはエージェント、舵取りは人間

ドキュメントを誰が書くのかも、この1年で変わりました。エンジニアリングチームは今、アップデート、新しいSDK（ソフトウェア開発キット）、APIの変更をかつてない速さで出しており、テクニカルライターが手作業でドキュメントを最新に保つことは事実上不可能になっています。そこでエージェントが、主な下書き役と保守役を担い始めています。

だからといって、テクニカルライターや開発者リレーションズ（DevRel）の担当者が不要になるわけではないとCEOは主張します。コードは極めて文字どおりに動くため、製品が何のためのものか、システム全体がどう設計されているかを言葉にする人間が今も必要です。そしてエージェントはユーザーのためのアプリを作るために大量のドキュメントを読むので、製品の挙動、SDKの組み込み手順、ユースケースを明確に説明することは、これまで以上に重要になっています。

仕事の中身は、1文ずつ書く作業から舵取りへと移ります。

• 顧客事例の選定と整理
• エッジケースの定義
• エージェントが生み出すものへの指示

1年先を見据えて、CEOはドキュメント作業がはるかに自律的になり、人間は監督と舵取りの役割を担うようになると見ています。Mintlifyは、エージェントがコードリポジトリを監視して変更を検知し、更新内容があいまいなときにはエンジニアに的を絞った確認の質問を送る、自動更新型のドキュメントを開発しています。狙いは、実際にリリースされたソフトウェアとドキュメントを常に一致させておくことです。

今取り組むべきこと

開発者向けドキュメントの最大の読者は、今やエージェントなのかもしれません。それでも、良いドキュメントの基準はほとんど変わっていません。人が読みやすいドキュメントはエージェントにとっても扱いやすく、人間の開発者が何を勧めるかがエージェントの推薦を左右します。APIや開発者ツールを作るチームに向けた実践的なチェックリストは次のとおりです。

1. クイックスタート、図解、検証済みのコード例をそろえ、人が製品をすばやく評価できるようにします。
2. ドキュメントを明確に区切ったセクションに分け、階層と文脈の手がかりをわかりやすくしたうえで、ユースケースとSDKの組み込み手順をはっきり書きます。
3. 内容が正確で最新であることを確かめてから、llms.txtやMCPサーバーといったエージェント向けの層を加えます。
4. 出典と参考情報を見える形で残し、人がエージェントの出力を確認できるようにします。
5. フォーラム、Reddit、ブログで開発者の支持を得る取り組みを続けます。
6. 下書きと更新はエージェントに任せ、人の時間は製品の意図、顧客事例、エッジケースに充てます。

エージェントが80%を占めるという数字は、機械向けに書き始めよという合図というより、ドキュメントの品質が人間とエージェント双方の選択を左右するようになったことを示すサインだと考えられます。