今、どこかで、あなたのAPIを統合している人がいます。彼らはあなたのドキュメントサイトにはいません。あなたのスタートガイドを開いていません。彼らはあなたのインタラクティブな遊び場や、入念にデザインされたサイドバーナビゲーションを見たことがありません。
彼らはClaudeに座っています。あるいはCopilot。あるいはカーソル。彼らは、「アプリルーターを使って、Stripeの課金APIをNext.jsアプリに統合する」_ などと入力し、動作するコードが戻ってくるのを待ちます。AIが代わりにドキュメントを読みます。関連するエンドポイントを見つけ、認証フローを理解し、適切なSDKメソッドを選び、実装を生成します。
2週間前、ザンクトガレンで開催されたStart Summit Hackathonで、私はこれがリアルタイムで起こるのを見ました。私はCSの学生グループと、初期段階のスタートアップの創業者たちと、新しいAPIにどのようにアプローチしているかについて話していました。問題をAIに貼り付け、コードを返してもらい、それを繰り返すというものです。ドキュメントを読んだのかと私が尋ねると、学生の一人が笑いました。「なぜ私が？クロードが読んでくれるから」。
その人はあなたのサイトを見たことがありません。その人はあなたのサイトを見たことがありません。そして、このようにソフトウェアが構築されることが多くなってきています。
コアシフト
ドキュメントを読む人間と、構築者に代わってドキュメントを読むAIアシスタントです。ほとんどのドキュメントは人間専用に最適化されています。AIはすでに支配的な読者です。
これは、下流のすべてを変えます：
- AIが古くなったコンテンツを提供した場合、構築者はその問題を検知する手段がありません。ダメージは静かに拡大します。
- プロダクトマネージャー、デザイナー、アナリストは、AIアシスタントを通じてソフトウェアを出荷しています。
- きれいなマークダウン、自己完結型のブロック、明示的なメタデータは、AIがあなたの製品を正確に表現することを可能にします。
- 人間の読者は物語を必要とします。AIの仲介者は、構造化され、解析可能な仕様を必要とします。あなたは両方に対応する必要があります。
この記事の残りの部分では、私たちがどのようにしてここまで来たのか、このことがDevRelにとって何を意味するのか、そしてあなたが今すぐにできることについて説明します。
誰も計画しなかった旅
長い間、開発者関係はよく理解された道をたどってきました。包括的なドキュメントを書きました。クイックスタートガイドを発行。カンファレンスでの講演。Stack Overflowで存在感を示しました。APIリファレンスを検索できるようにし、SDKをイディオムにし、エラーメッセージを親切にしました。
その道は、開発者があなたのコンテンツを読むことを前提としていました。あなたの構造をナビゲートしてください。手順を追って。
GitHubの2024年開発者調査によると、エンタープライズ開発者の97%がAIコーディングツールを使ったことがあることがわかりました。Stack Overflowの年次調査によると、全開発者の76%がAIツールを使用しているか、使用する予定であり、62%のプロフェッショナルが毎日積極的に使用しています。2026年までに、この数字は84%に上昇し、現在では全コードの41%がAIによって生成され、プロの開発者の51%が毎日AIツールを使用しています。この数字は減速していません。
新しい旅の形は異なります。誰かが自然言語で欲しいものを説明します。AIアシスタントがドキュメントを読み、関連するセクションを見つけ、統合を生成します。ビルダーは出力を確認し、プロンプトを改良し、フォローアップを求めるかもしれません。数時間ではなく、数分。
DevRelチームが何年もかけて完成させた、スタートアップファネル？それは回避されつつあります。それが悪いからではありません。エントリーポイントが移動しただけです。
2人のコンシューマー、1セットのドキュメント
ドキュメントは現在、2つの根本的に異なる読者を抱えています。
1つ目は人間の読者です。この人はまだ存在します。彼らは、アーキテクチャの決定、エッジケースのデバッグ、コンプライアンスレビュー、コンセプトの理解のために現れます。彼らが求めるのは、物語的な説明、よく整理された参考資料、トレードオフに関する明確な理由付けです。
2つ目は、AIの仲介者です。AIは構築者に代わってドキュメントを読みます。サイドバーなど気にしません。視覚的なデザインも評価しません。きれいなマークダウン、一貫した書式、曖昧さなく推論できる明確な仕様などです。
今日、ほとんどすべてのドキュメントサイトは、第一の読者だけに最適化されています。第二の読者は、すでに支配的な消費者です。
Jeremy Howardは、2024年に/llms.txt標準を提案したときに、この緊張を特定しました。彼の観察は的確でした：大規模な言語モデルはますますウェブサイトの情報に依存するようになっていますが、決定的な限界に直面しています。CODEBLOCK_0__のマークダウンファイルは、AIモデルに製品の構造化された概要と最も重要なリソースへのリンクを提供します。FastHTML、Anthropic自身のドキュメント、そしてプロジェクトの成長ディレクトリは、現在その1つを配布しています。
これは便利な慣習です。しかし、それはまた、より深い問題の徴候でもあります。本当の問題は形式ではありません。ほとんどのドキュメントは、機械による消費を念頭に置いて設計されていないということです。
ビルダーは手を抜いていません
ドキュメントを読まずにクロードを促す人を見て、彼らが手抜きをしていると結論づけたくなる誘惑があります。彼らはコードの中で何が起こっているのかを本当に理解していないのだと。彼らは開発者としては劣っていると。
私はこの会話を何度もしてきたので、それはたいてい間違いだとわかっています。
このような開発者の多くは、意図的に効率的な選択をしている上級エンジニアです。彼らはコードを理解し、実際に必要な3行を見つけるために4ページのドキュメントをナビゲートしたくないだけなのです。彼らは、AIアシスタントがそれらの行をスキャンするよりも速く抽出できることを学んだので、読み取りを委任するのです。(正直なところ、私自身もそうしています。正直なところ、私自身もそうしています)。
AnthropicはModel Context Protocolを構築したとき、このパターンを認識しました。MCPは現在、Claude、ChatGPT、VS Code、Cursorなどでサポートされています。MCPは、AIアシスタントが外部システムにアクセスし、コンテキストを引き出し、それに基づいて行動できるように明確に設計されています。仕様書では、「機能を強化し、エンドユーザー体験を向上させるデータソース、ツール、アプリのエコシステムへのアクセス」を提供すると説明されています。
よく読んでください。これはインフラストラクチャー言語であり、利便性言語ではありません。これらのツールを使用するビルダーは、仕事を避けているわけではありません。彼らは新しいレイヤーを通して作業しているのであり、あなたがそれを設計したかどうかにかかわらず、あなたのドキュメントはそのレイヤーの一部なのです。
これは数字が裏付けています。Claudeだけで、現在月間250億のAPIコールを処理し、159カ国に3000万人の月間アクティブユーザーを抱えています。フォーチュン100社の70%がクロードを使用しています。Menlo Venturesの調査によると、Anthropicはモデル使用率でエンタープライズAI市場シェアの32%を占め、OpenAIの25%を上回っています。HSBCの調査レポートでは、さらに高く、AIの総支出額の40%を占めています。これらは実験的なツールではありません。主要なインフラなのです。
開発者関係は異なる時代のために構築されました
もしあなたの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は古いセットアップを最新のものとして説明します。迷いはありません。
そして、これが想像以上に悪いことなのです：開発者の66%はすでに、AIツールの最大の問題は、"ほぼ正しいが、まったく正しくない "結果を出すことだと言っています。陳腐なドキュメントは、この問題に直接影響します。AIは幻覚を見ているのではありません。古いコンテンツを忠実に再現しているのであり、その違いをビルダーが見分ける方法はありません。
建設者はAIを信頼します。AIはドキュメントを信頼します。もし文書が古ければ、その信頼の連鎖は確信を持って間違った答えを出します。
これは常に問題でした。陳腐なコンテンツは常に人々を混乱させてきました。しかし、人間の読者がそれを発見できることがあったため、被害は抑えられました。AIの仲介者にはそれができません。AIは、疑う理由のない人々に、権威をもって、大規模にコンテンツを提供することによって、陳腐なコンテンツを増幅させるのです。
鮮度はもはやコンテンツの質の問題ではありません。ドキュメントに触れるすべてのAIワークフローの信頼性の問題なのです。
「開発者」という言葉は狭すぎる
2026年にソフトウェアを作っている人たちは、全員が開発者だと認識しているわけではありません。動くプロトタイプを作るためにクロードを促すデザイナーもいます。Cursorを使って社内ツールを出荷するプロダクトマネージャーもいます。データパイプラインを自然言語で記述し、エージェントに組み立てさせるデータアナリストもいます。Start Summitでは、ハッカソンチームの半数がプログラミングの素養が全くないメンバーで構成され、週末が終わる頃には実用的なソフトウェアを出荷していました。
Rampは有用な例です。このフィンテック企業は、2023年の評価額58億ドルから2025年後半には320億ドルになり、その過程で年換算収益が10億ドルを超えました。史上最も急成長した新興企業のひとつ。彼らのアプローチの一部として広く議論されているのは、プロダクトマネージャーがエンジニアリングバックログで待つのではなく、AIツールを使って直接機能を構築することです。RampのPMは仕様を書くだけではありません。彼らはコードを出荷します。実装はAIが行います。PMは意図を処理します。
近道ではありません。新しいオペレーティング・モデルであり、実験と見なすのが難しい規模で機能しています。
Anthropic自身の内部調査は、ここで明らかにしています。自社のエンジニア132人を対象に、Claudeをどのように使っているかを調査したところ(https://fortune.com/2025/12/02/how-anthropics-safety-first-approach-won-over-big-business-and-how-its-own-engineers-are-using-its-claude-ai/)、エンジニアは仕事の約60%にClaudeを使っていると答えました。最も一般的な用途は？既存のコードのデバッグ、コードベースの一部が何をしているかの理解、新しい機能の実装。エンジニアは、「複雑でなく、反復的で、コード品質が重要でない」作業をクロードに任せる傾向があると述べています。また、現在Claudeで行っている作業の27%は、以前は全く行っていなかったものだそうです。
Anthropicのチームです。モデルを構築した人々は、ドキュメントリーダー、コードベースナビゲーター、初稿作成ツールとして使用しています。他のみんなも同じことをしています。
Anthropicは、このペルソナを "ビルダー "と呼んでいます。彼らのツールは、プロのソフトウェアエンジニアだけでなく、作りたいものを説明できるすべての人のために設計されています。クロードが、MCPを介して、Figmaの設計からフルスタックのアプリケーションを足場組みすることができれば、「開発者」と「非開発者」の間の伝統的な境界線はなくなります。
このことは、ドキュメントを管理したり、開発者の体験を気にかけたりする人にとって、大きな意味を持ちます。読者は、もはや REST エンドポイントが何であるかを知っている人に限定されません。AIアシスタントがあなたの製品とやりとりする可能性のあるすべての人が含まれます。あなたのAPIを使って機能を出荷するRampのPM？おそらくあなたのドキュメントを直接読むことはないでしょう。彼らのAIエージェントは絶対に読むでしょう。
ドキュメンテーションの意味
もしドキュメントが人間の読者とAIの仲介者という2つの読者を対象にしているのであれば、その両方に対応する必要があります。当たり前のことです。実際には、ほとんど誰もやっていません。
私が実際に重要だと思うことは以下の通りです：
**もしあなたのAPIドキュメントが美しくレンダリングされたHTMLページで、それをLLMがスクレイピングして解析しなければならないのであれば、AIは必要以上に働いていることになります。レンダリングされたバージョンと一緒に生のOpenAPI仕様を出荷してください。きれいなマークダウンを出荷してください。AIにページレイアウトを解釈させることなく、仕様にアクセスできるようにしましょう。
**ページレベルの説明の代わりにブロックレベルの構造。彼らは関連するセクションを抽出します。明確な見出し、自己完結した段落、明示的なブロックレベルのセマンティクスを持つ文書は、文脈のためにページ全体を読む必要がある流れるような物語よりも、AIにとって劇的に有用です。
**この文書が最後に見直されたのはいつですか？これはまだ最新ですか？コンテンツにフラグはついていますか？これらのシグナルは、ウェブページ上の視覚的な手がかりとしてだけでなく、AIがアクセスできる形で存在する必要があります。鮮度スコア、有効期限切れステータス、レビュー日付、これらはAIがドキュメントをソースとして使用しても安全かどうかを判断するためのメタデータです。
**AIアシスタントが非推奨のエンドポイントに基づいた確信に満ちた回答をビルダーに提供する場合、その損害は404よりも深刻です。ビルダーはそれを基に構築します。それを出荷します。そして、本番で壊れ、誰かが数ヶ月前に更新されたはずのドキュメントにたどり着くまで、誰もその理由を知りません。AIが参照する可能性のあるすべての文書には、それがまだ最新であることを証明するメカニズムが必要です。(これは完全な開示ですが、まさに私たちがRasepiを構築して解決しようとしている問題です。ドキュメントブロックに強制的な有効期限を設定することで、古くなったコンテンツが隠れないようにします)。
はじめに: 現在のドキュメントを監査しましょう
ここまで読んで、「よし、でも実際に月曜日に何をすればいいんだろう」と思った方、今週チェックできる具体的なことを4つ紹介します。
1.AIを使ってドキュメントをテストする ClaudeやChatGPTを開き、現実的なシナリオであなたの製品を統合するよう依頼してください。社内の知識は使わないでください。AIが生成するものを見てください。それは正しいですか？最新ですか？正しいエンドポイント、正しいSDKバージョン、正しい認証フローを使用していますか？もしAIがそれを間違えているなら、それは今ビルダーが得ているものです。
2.2.コンテンツが古くなっていないかチェックしましょう。 最もアクセス数の多いドキュメントページを5つ選び、こう尋ねてください。それはまだ製品の現在の状態を説明していますか？あなたが自信を持って答えられないなら、AIも答えられません。これは、ほとんどのチームにとって、最も活用度の高い修正方法です。
**3.もし/llms.txtファイルを持っていないなら、作ってください。もしAPIリファレンスがレンダリングされたHTMLとしてしか利用できないのであれば、生のOpenAPI仕様をエクスポートしてアクセスできるようにしてください。もしあなたのドキュメントがきれいなマークダウンを出力しないCMSにあるのなら、それは今すぐ解決する価値のある問題です。
**4.コンテンツ管理システムのlast-reviewedフィールドのような単純なものでも、トラフィックの多いページには必須のレビューサイクルを設定します。これは、人間とAIの両方に、コンテンツが信頼できるかどうかのシグナルを与えます。ラセピのようなツールはブロックレベルで強制的に期限切れにすることでこれを自動化することができますが、手作業でも何もしないよりはマシです。
商品の表現方法の静かな変化
直接的に述べる価値のある、より広範な結果があります。
あなたのドキュメントは、もはや開発者のための参考マニュアルではありません。それは、AIアシスタントがあなたの製品を世界に表現するために使用する資料なのです。ビルダーがあなたの製品の使い方をクロードに尋ねるとき、クロードの答えは、あなたのドキュメントから見つけて解析できるものによって形作られます。
良いドキュメント、良い答え。時代遅れで、あいまいで、モデルが解析するのが難しいHTMLの中に閉じこめられている場合は？より悪い答えか、正しくない答えです。簡単なことです。
あなたの製品に関するAIの回答の質は、今やあなたの開発者エクスペリエンスの直接の代理人です。ほとんどの企業はまだそのように扱っていません。
先行しているStripe、Vercel、Cloudflare、Anthropicなどのチームは、AIの可読性を第一級の問題として扱っています。ドキュメントの書き方、構造化、メンテナンスの方法を形作る基本的な要件です。来期のバックログ項目にはなりません。
今クロードに座っているビルダーは、何を作りたいかを説明し、数分で動くコードを期待しています。彼らは二度とドキュメントサイトを訪れることはないかもしれません。しかし、彼らにサービスを提供するAIはそうします。常に。
そのAIが今、あなたの最も頻繁な読者なのです。問題は、あなたのドキュメントがそれに対応しているかどうかです。
2026年における最高の開発者エクスペリエンス戦略は、カンファレンスでの講演やクイックスタートガイドではありません。AIが正しく理解できるようにすることです。
*この記事は、一般に公開されている調査結果や製品ドキュメントを参照しています。統計は、GitHub's 2024 developer survey, Stack Overflow 2024 Developer Survey, Index.dev's 2026 developer productivity report, Incremys Claude statistics, Fortune's reporting on Anthropic から引用しています。/llms.txt仕様はllmstxt.orgで管理されています。モデルコンテキストプロトコルは modelcontextprotocol.io で文書化されています。