今、どこかで、あなたのAPIを統合している人がいます。彼らはあなたのドキュメントサイトにはいません。あなたのスタートガイドを開いていません。彼らはあなたのインタラクティブな遊び場や、入念にデザインされたサイドバーナビゲーションを見たことがありません。
彼らはClaudeに座っています。あるいはCopilot。あるいはカーソル。彼らは、「アプリルーターを使って、Stripeの課金APIをNext.jsアプリに統合する」_ などと入力し、動作するコードが戻ってくるのを待ちます。AIが代わりにドキュメントを読んでくれます。関連するエンドポイントを見つけ、認証フローを理解し、適切なSDKメソッドを選び、実装を生成します。
2週間前、ザンクトガレンで開催されたStart Summit Hackathonで、私はこれがリアルタイムで起こるのを見ました。私はCSの学生グループと、初期段階のスタートアップの創業者たちと、新しいAPIにどのようにアプローチしているかについて話していました。問題をAIに貼り付け、コードを返してもらい、それを繰り返すというものです。ドキュメントを読んだのかと私が尋ねると、学生の一人が笑いました。「なぜ私が？クロードが読んでくれるから」。
その人はあなたのサイトを見たことがありません。その人はあなたのサイトを見たことがありません。そして、このようにソフトウェアが構築されることが多くなってきています。
誰も計画しなかった旅
長い間、開発者関係はよく理解された道をたどってきました。あなたは包括的なドキュメントを書きました。クイックスタートガイドを発行。カンファレンスでの講演。Stack Overflowで存在感を示しました。APIリファレンスを検索できるようにし、SDKをイディオムにし、エラーメッセージを親切にしました。
その道は、開発者があなたのコンテンツを読むことを前提としていました。あなたの構造をナビゲートしてください。手順を追って。
GitHubの2024年開発者調査によると、エンタープライズ開発者の97%がAIコーディングツールを使ったことがあることがわかりました。Stack Overflowの年次調査によると、全開発者の76%がAIツールを使用しているか、使用する予定があり、62%のプロフェッショナルが毎日積極的に使用しています。この数字はすでに高く、その後も上昇の一途をたどっています。
新たな旅の形は異なります。誰かが自然言語で欲しいものを説明します。AIアシスタントがドキュメントを読み、関連するセクションを見つけ、統合を生成します。ビルダーは出力を確認し、プロンプトを洗練させ、フォローアップを求めるかもしれません。数時間ではなく、数分。
DevRelチームが何年もかけて完成させた、スタートアップファネル？それは迂回されています。悪いからではありません。
2つのコンシューマー、1セットのドキュメント
ドキュメントは現在、2つの根本的に異なる読者を抱えています。
1つ目は人間の読者です。この人はまだ存在します。彼らは、アーキテクチャの決定、エッジケースのデバッグ、コンプライアンスレビュー、コンセプトの理解のために現れます。彼らが求めるのは、物語的な説明、よく整理された参考資料、トレードオフに関する明確な理由付けです。
2つ目は、AIの仲介者です。AIは構築者に代わってドキュメントを読みます。サイドバーなど気にしません。視覚的なデザインも評価しません。きれいなマークダウン、一貫した書式、曖昧さなく推論できる明確な仕様などです。
今日、ほとんどすべてのドキュメントサイトは、第一の読者だけに最適化されています。第二の読者は、すでに支配的な消費者です。
ジェレミー・ハワードは、2024年に/llms.txt標準を提案したときに、この緊張を特定しました。彼の観察は的確でした：大規模な言語モデルはますますウェブサイトの情報に依存するようになっていますが、決定的な限界に直面しています。CODEBLOCK_0__のマークダウンファイルは、AIモデルに製品の構造化された概要と最も重要なリソースへのリンクを提供します。FastHTML、Anthropic自身のドキュメント、そしてプロジェクトの成長ディレクトリは、現在その1つを配布しています。
これは便利な慣習です。しかし、それはまた、より深い問題の徴候でもあります。本当の問題は形式ではありません。ほとんどのドキュメントは、機械による消費を念頭に置いて設計されていないということです。
ビルダーは手を抜いていません
ドキュメントを読まずにクロードを促す人を見て、彼らが手抜きをしていると結論づけたくなる誘惑があります。彼らはコードの中で何が起こっているのかを本当に理解していないのだと。彼らは開発者としては劣っていると。
私はこの会話を何度もしてきたので、それはたいてい間違いだとわかっています。
このような開発者の多くは、意図的に効率的な選択をしている上級エンジニアです。彼らはコードを理解しており、実際に必要な3行を見つけるために4ページのドキュメントをナビゲートしたくないだけなのです。彼らは、AIアシスタントがそれらの行をスキャンするよりも速く抽出できることを学んだので、読み取りを委任するのです。(正直なところ、私自身もそうしています。正直なところ、私自身もそうしています)。
AnthropicはModel Context Protocolを構築したとき、このパターンを認識しました。MCPは現在、Claude、ChatGPT、VS Code、Cursorなどでサポートされています。MCPは、AIアシスタントが外部システムにアクセスし、コンテキストを引き出し、それに基づいて行動できるように明確に設計されています。仕様書では、「機能を強化し、エンドユーザー体験を向上させるデータソース、ツール、アプリのエコシステムへのアクセス」を提供すると説明されています。
これはインフラストラクチャー言語であり、利便性言語ではありません。これらのツールを使用するビルダーは、仕事を避けているわけではありません。彼らは新しいレイヤーを通して作業しているのであり、あなたがそれを設計したかどうかに関わらず、あなたのドキュメントはそのレイヤーの一部なのです。
##開発者関係は異なる時代のために作られました
もしあなたのDevRel戦略が2023年以前に設計されたものであれば、それは開発者がドキュメントを直接読む世界を想定して設計されたものです。その世界は消滅したわけではありませんが、増えつつある開発者にとって、それはもはや支配的なインタラクションパターンではありません。
このことは、いくつかの長年のDevRel活動の計算を変えることになります。
**開発者会議での45分のプレゼンテーションは、数百人の聴衆に届きます。よく構造化された/llms.txtファイルときれいな機械可読ドキュメントは、あなたの製品についてAIアシスタントに質問するすべてのビルダーに、いつでも継続的に届きます。講演は1回限りのイベントです。機械可読のドキュメントは複合的なものです。私は、カンファレンスが無価値だと言っているわけではありません。
スタートガイド. 古典的な5ステップのクイックスタートチュートリアルは、ますます形式的になってきています。ビルダーはステップに従いません。彼らは欲しいものを説明し、AIが統合を生成することを期待します。もしAPIがマシンフレンドリーなフォーマットできちんと文書化されていれば、AIはチュートリアルよりも効率的に使い始めを処理します。チュートリアルが代わりにすべきことは、概念的な資料、つまり、なぜアプローチBではなくアプローチAを選ぶのかを説明することです。AIは実装を生成することができますが、トレードオフを説明することはできません。
**Stack Overflow.**彼ら自身の調査データによると、開発者の84%が技術文書を直接利用しており、そのうちの90%はAPIやSDKパッケージ内の文書に頼っています。しかし、それらのドキュメントにアクセスする方法は、ブラウザのタブではなく、AIレイヤーを介することが多くなっています。今でもStack Overflowに寄せられる質問は、エッジケース、プロダクションデバッグ、ニュアンスを必要とするものなど、難しいものになりがちです。確かに貴重です。しかし、もはやボリュームはありません。
AIがあなたのドキュメントを読むとき、鮮度が重要になります。
ここが、ほとんどのチームが考えていない部分です。
人間がドキュメントのページを読むとき、彼らは判断を下すことができます。スクリーンショットが古そうだとか、一番下のコメントにプロセスが変わったと書いてあるとか。目を細めて、"これは時代遅れだ "と思うかもしれません。
AIアシスタントにはそれができません。テキストを読み、それを事実として処理し、完全な自信をもって答えを生成します。ドキュメントに非推奨のエンドポイントが記載されていれば、AIは喜んでそのエンドポイントとの統合を勧めます。ドキュメントが6ヶ月前に置き換えられたインフラを参照している場合、AIは古いセットアップを最新のものとして説明します。迷いはありません。
ビルダーはAIを信頼します。AIはドキュメントを信頼します。もしドキュメントが古ければ、その信頼の連鎖は自信を持って間違った答えを返します。
これは常に問題でした。陳腐なコンテンツは常に人々を混乱させてきました。しかし、人間の読者がそれを発見できることがあったため、被害は抑えられました。AIの仲介者にはそれができません。AIは、疑う理由もない人々に、権威あるコンテンツを大規模に提供することで、陳腐なコンテンツを増幅させるのです。
鮮度はもはやコンテンツの質の問題ではありません。ドキュメントに触れるすべてのAIワークフローの信頼性の問題なのです。
「開発者」という言葉は狭すぎる
2026年にソフトウェアを作っている人たちは、全員が開発者だと認識しているわけではありません。動くプロトタイプを作るためにクロードを促すデザイナーもいます。Cursorを使って社内ツールを出荷するプロダクトマネージャーもいます。データパイプラインを自然言語で記述し、エージェントに組み立てさせるデータアナリストもいます。Start Summitでは、ハッカソンチームの半数がプログラミングの素養が全くないメンバーで構成され、週末が終わる頃には実用的なソフトウェアを出荷していました。
Rampは有用な例です。このフィンテック企業は、2023年の評価額58億ドルから2025年後半には320億ドルになり、その過程で年換算収益が10億ドルを超えました。史上最も急成長した新興企業のひとつ。彼らのアプローチの一部として広く議論されているのは、プロダクトマネージャーがエンジニアリングバックログで待つのではなく、AIツールを使って直接機能を構築することです。RampのPMは仕様を書くだけではありません。彼らはコードを出荷します。実装はAIが行います。PMは意図を処理します。
近道ではありません。新しいオペレーティング・モデルであり、実験と見なすのが難しい規模で機能しています。
Anthropicは、これを意図的に "ビルダー "ペルソナと呼んでいます。彼らのツールは、プロのソフトウェアエンジニアだけでなく、作りたいものを説明できるすべての人のために設計されています。クロードが、MCPを介して、Figmaの設計からフルスタックのアプリケーションを足場組みすることができれば、「開発者」と「非開発者」の間の伝統的な境界線はなくなります。
このことは、ドキュメントを管理したり、開発者の体験を気にかけたりする人にとって、大きな意味を持ちます。読者は、もはや REST エンドポイントが何であるかを知っている人に限定されません。AIアシスタントがあなたの製品とやりとりする可能性のあるすべての人が含まれます。あなたのAPIを使って機能を出荷するRampのPM？おそらくあなたのドキュメントを直接読むことはないでしょう。彼らのAIエージェントは絶対に読むでしょう。
ドキュメンテーションの意味
もしドキュメントが人間の読者とAIの仲介者という2つの読者を対象にしているのであれば、両方の読者に対応する必要があります。当たり前のことのように聞こえます。実際には、ほとんど誰もやっていません。
私が実際に重要だと思うことは以下の通りです：
**もしあなたのAPIドキュメントが美しくレンダリングされたHTMLページで、それをLLMがスクレイピングして解析しなければならないのであれば、AIは必要以上に働いていることになります。レンダリングされたバージョンと一緒に生のOpenAPI仕様を出荷してください。きれいなマークダウンを出荷してください。AIにページレイアウトを解釈させることなく、仕様にアクセスできるようにしましょう。
**ページレベルの説明の代わりにブロックレベルの構造。彼らは関連するセクションを抽出します。明確な見出し、自己完結した段落、明示的なブロックレベルのセマンティクスを持つ文書は、文脈のためにページ全体を読む必要がある流れるような物語よりも、AIにとって劇的に有用です。
**この文書が最後に見直されたのはいつですか？これはまだ最新ですか？コンテンツにフラグはついていますか？これらのシグナルは、ウェブページ上の視覚的な手がかりとしてだけでなく、AIがアクセスできる形で存在する必要があります。鮮度スコア、有効期限切れステータス、レビュー日付、これらはAIがドキュメントをソースとして使用しても安全かどうかを判断するためのメタデータです。
**AIアシスタントが、非推奨のエンドポイントに基づいた自信に満ちた回答をビルダーに提供する場合、その損害は404よりも深刻です。ビルダーはそれを基に構築します。それを出荷します。そして、本番で壊れ、誰かが数ヶ月前に更新されたはずのドキュメントにたどり着くまで、誰もその理由を知りません。AIが参照する可能性のあるすべての文書には、それがまだ最新であることを証明するメカニズムが必要です。(これは正真正銘、私たちがRasepiで解決しようとしている問題です。古いコンテンツが隠れないように、ドキュメントブロックに強制的な有効期限を設けるのです)。
製品の表現方法の静かな変化
直接的に述べる価値のある、より広範な結果があります。
あなたのドキュメントは、もはや開発者のための参考マニュアルではありません。それは、AIアシスタントがあなたの製品を世界に表現するために使用する資料なのです。ビルダーがあなたの製品の使い方をクロードに尋ねるとき、クロードの答えは、あなたのドキュメントから見つけて解析できるものによって形作られます。
良いドキュメント、良い答え。時代遅れで、あいまいで、モデルが解析しにくいHTMLの中に閉じこめられていれば、より悪い答え、あるいは間違った答えになります。単純なことです。
製品に関するAIの回答の質は、今や開発者のエクスペリエンスの直接的な代用品なのです。ほとんどの企業はまだそのように扱っていません。
先行しているチーム（Stripe、Vercel、Cloudflare、Anthropic自身）は、AIの読みやすさを第一級の関心事として扱っています。ドキュメントの書き方、構造化、メンテナンス方法を形作る基本的な要件です。来期のバックログではありません。
今クロードに座っているビルダーは、作りたいものを説明し、数分で動くコードを期待しています。しかし、彼らにサービスを提供するAIはそうします。常に。
そのAIが今、あなたの最も頻繁な読者なのです。問題は、あなたのドキュメントがそれに対応しているかどうかです。
2026年における最高の開発者エクスペリエンス戦略は、カンファレンスでの講演やクイックスタートガイドではありません。AIが正しく理解できるようにすることです。
*この投稿は、一般に公開されている調査結果や製品ドキュメントを参照しています。統計は、GitHub's 2024 developer survey と Stack Overflow 2024 Developer Survey から引用しています。/llms.txt仕様はllmstxt.orgで管理されています。モデルコンテキストプロトコルは modelcontextprotocol.io で文書化されています。