AI時代の開発者の法則

 (bvp.com)
28 ポイント 投稿者 GN⁺ 2025-10-27 | 1件のコメント | WhatsAppで共有
  • AIエージェントと人間の開発者が同時にユーザーであり協働者でもある新しいソフトウェア環境を踏まえ、12年前に発表された開発者プラットフォームの法則をAIパラダイムに合わせて再定義
  • 2025年現在、**エージェンティック開発（agentic development）**というパラダイムが登場し、AIエージェントが開発者と協業してソフトウェアを設計・構築・デプロイ・保守する環境へ移行
  • Anthropic、Cursor、Port など主要な開発者プラットフォームのリーダーたちによる直接的な知見をもとに、8つの中核法則を導出
  • エージェント体験（AX）と開発者体験（DX）のバランス、モデルフレンドリーなドキュメント化、新たな価格戦略、プラットフォームエンジニアの役割変化など、開発ツール市場の構造的変化を扱う
  • AI主導のソフトウェア革新の波の中で、開発者プラットフォームが新たなインフラの先頭を走り、継続的な進化とプラットフォーム支配力が防御力の中核として浮上

背景: 開発者の法則の進化

  • Bessemer Venture Partnersが2013年に発表した最初の「開発者プラットフォームの8大法則」と2019年改訂版は、DevOps、オープンソース、クラウドネイティブアーキテクチャ、APIファーストのエコシステムの台頭を追跡
  • 2025年現在、エージェンティック開発という新たなパラダイムが登場
    • AIエージェントが開発者と協業し、ソフトウェアを大規模に設計・構築・デプロイ・保守
  • Anthropic、Cursor、Port、Fal AI、Fern、Render、Appwrite、Netlify、Recall、Vapi、Resolve AI、Graphite、Marimo、Resend など、業界リーダーたちの直接的な知見を反映

AI開発プラットフォームの8大法則

法則 #1: エージェント体験（AX）は開発者体験（DX）と同じくらい重要

  • エージェント体験（AX）と開発者体験（DX）の両方に等しく注力する必要がある
    • DXがAXを直接補完し、向上させる
    • ドキュメントの網羅性、APIの表面積、理解しやすいスキーマなどは、人間とエージェントの双方に有用
    • 過去5〜10年にわたる OpenAPI 仕様、REST API、SDK への投資の成果が、両者にとって役立っている
  • Resend CEOの証言: DX改善のためにオンボーディングフローを最適化したことが、エージェントによる Resend 利用にも大きな違いを生んだ

  • 人間とエージェントのための差別化された機能

    • 人間の開発者は、曖昧なドキュメントを解釈し、一貫性のない API に適応できる
    • エージェントには、構造化され予測可能なインターフェースが必要
      • 包括的なエラー処理を含む OpenAPI スキーマ
      • 多段階ワークフローのためのセッション永続性
      • WebSocket ストリームのようなリアルタイムフィードバック機構
      • Netlify のデプロイエージェントは、CI/CD パイプライン全体で状態を維持しながら、即時のビルドフィードバックを提供

  • Model Context Protocol（MCP）の登場

    • MCP は、開発者ツールがユーザーにサービスを提供する方法の根本的な変化を表している
    • 多くの企業が、Prefect の FastMCP のようなソリューションで独自の MCP サーバーをホスト
      • 開発者が Cursor や Claude Code で作業しているため
      • IDE 内で開発者がエージェントを強化し、プラットフォームのライブデータへ直接アクセスして作業を実行

  • ダッシュボードと API の統合

    • 現在、人間は情報収集のための中央ウィンドウとしてダッシュボードに直接ログインしている
    • Recall のようなチームは、ダッシュボードのあらゆる機能を API 経由で利用可能にすることで、エージェントも問題解決に貢献できるようにしている
    • エージェントのコンテキストスイッチ（バージョン管理、統合、API 使用、本番デプロイ）を減らす、あるいは取り除くことに関する未解決の問い
      • MCP サーバーにより、エージェントはダッシュボードや CLI にコンテキストスイッチせずにリアルタイム情報を取得し、コマンドを実行できる

法則 #2: ドキュメントはモデルと人間の両方に奉仕しなければならない

  • エンジニアリングチーム内のドキュメントは、善意で書かれていても適切に保守されないことが多い
    • リアルタイムの変更を反映できず、古いガイドを提供してしまう
    • 開発者は、不完全または不十分なドキュメントに対してある程度の寛容さを示す
    広告

  • LLM向けドキュメント化の特殊性

    • LLM にとって、ナビゲーション、広告、JavaScript を含む複雑な HTML ページをLLMフレンドリーなプレーンテキストに変換することは難しく、不正確
    • エージェントは、単一でアクセスしやすい場所に集約された簡潔で専門性の高い情報から大きな利益を得る
      • 開発環境のようなユースケースで特に重要（LLM がプログラミング文書や API に素早くアクセスする必要があるため）
    • LLM には、最新で構造化された API リファレンスと、人間およびエージェントの作業を追跡する監査ログが必要
      • 情報アーキテクチャの根本的な再考を要求

  • Generative Engine Optimization（GEO）

    • SEO が検索エンジンでの発見可能性を保証するように、GEO は、モデルがドキュメント内の正確な回答を素早くパースして表示できることを保証する
    • 開発者がコンテキストスイッチを伴う検索で中断されず、フローを維持できるよう支援

  • 二重目的の技術文書

    • コーディングエージェントの普及により、技術文書は二重目的のプロダクト資産になっている
    • エージェントと人間の開発者という、両方の読者に効果的に対応
      • エージェント向けの適切なバージョン管理、変更管理、検索性
      • 人間の開発者にとっても有用な状態を維持
    • Fern共同創業者の観察: 「開発者は洗練されたドキュメントサイトを求め、エージェントはパースしやすいクリーンな Markdown を必要とする。チームはまず Markdown でドキュメントを書き、その後、開発者向けの使いやすいウェブサイトや llms.txt のような機械可読ファイルとして公開する docs-as-code アプローチへ移行しつつある」

法則 #3: 価格戦略はオンボーディング摩擦の低減に集中

  • 価格設定では、コスト構造と価値提供の両方を考慮しなければならない
  • AIネイティブアプリケーションでは特に重要
    • 従来の SaaS では追加ユーザーのサービスコストがほぼゼロだったのに対し、推論コストによって意味のある費目へと変化

  • 開発者向け企業が実験している3つの価格設定パス

    • 1. 従量課金と大規模な顧客アカウント拡張
      • プロダクトの驚くべき有用性による拡張
      • あらゆるプラットフォームが AI と再統合されており、これまでのあらゆる波と同様に、開発者が先頭を走ってインフラとツールへの支出を主導
      • 利用量と収益化が顧客とともに成長（現在もっとも一般的な価格パターン）
    • 2. 企業は支出の予測可能性を好む
      • ベンダーが AI を追加機能ではなく、中核となるシートベース製品体験の一部として統合
      • 多くの場合、従量課金の超過料金を伴う
    • 3. 成果ベース課金またはアクティビティのバンドル化
      • アクティビティを意味のあるビジネスプロセスとして束ね、完了したワークフローに基づいて請求

  • アップセルのトリガーの違い

    • 初期データは、従来型の開発者と vibe coder の間でアップセルのトリガーが異なる可能性を示唆
    • 構築と出荷における制約要因が、ソフトウェア制作者の支払い意思に影響
      • 例: vibe coder と従来型開発者向けの CI/CD 機能
      広告

  • オンボーディング摩擦の低減は依然として最優先

    • どの道を選んでも、すべてのプラットフォームは依然としてオンボーディング摩擦の低減にもっとも集中している
      • 魅力的な無料ティアの維持
      • 優れたドキュメント
      • 強力な開発者コミュニティ（スケーラブルにオンボーディング摩擦を低減）
    • Resolve CEOの見解: 「古い SaaS モデルを新しい製品に無理やり当てはめることはしない。価値は成果に対応づけられるべきだ……エージェントが実際のエンジニアリング作業を行い、システムがダウンタイムの削減、システム安定性の維持、出荷の加速といった測定可能な価値を提供するとき、その価格設定は妥当になる」

法則 #4: AI開発者ツール支出が従来の予算枠を外れつつある

  • 専用のAI予算を設ける企業が増え、新たな支出カテゴリーが生まれている
    • 当初はCIOを通じて組織のあらゆる部門へ広がる
  • 多くの企業がすでにAIツール支出と追加のエンジニア採用の間でトレードオフを進めている
    • 人員を増やす代わりに、エージェントで目標を達成できるかを継続的に問い直している

  • ジュニアエンジニアの補完と代替

    • 歴史的にサービス中心の業界へ販売してきた他の業種特化型ソフトウェア企業で見られたように
    • コーディングエージェントへの委任とワークフローが、ジュニアエンジニアを補完し、代替し始めている
    • 生産性向上とコスト削減だけでなく、技能の最大化にも焦点が当てられている
    • 個人がまったく新しい能力を身につけ、他者への依存度を下げている

  • 多数の利害関係者がいる購買環境

    • 予算の出どころがより複雑な、多数の利害関係者による購買環境が明らかになっている
    • 開発者主導のGTMは、騒がしい競争環境でも依然として王者
    • 企業内では、CIO、エンジニアリングリーダー、プロダクトチーム、個々の開発者の全員が、非決定論的なシステム統合に必要なガードレールの水準のため、前世代の開発者ツールとは異なる形で購買判断に影響を与えている

  • 成功指標の変化

    • 即時の価値と魔法のような体験に対する消費者レベルの期待へと移行している
    • 従来の開発者ツールの生産性指標は、成果ベースの測定で補完されている
      • アイデアから動くプロトタイプまでの時間
      • 開発サイクル全体の短縮
      • ビジネスユーザーの生産性向上
    • Cursorの分析は詳細な指標の追跡を行っている
      • 表示された提案数、受け入れられた提案数、AI支援で生成されたコード行数、AI生成提案の受け入れ率
広告

法則 #5: 開発者の定義が劇的に拡大している

  • AIがより多くの人にソフトウェア作成へのアクセスをもたらし、「開発者」の定義を根本から拡張している
    • 10年前のZapierへのシード投資以来、このトレンドが見えていた
  • バイブコーディングとAI支援開発の広範な普及によって、コードを自分で書いたり意識したりせずにカスタムソフトウェアを作る新しいビルダー層が生まれている

  • 新しいユーザーコホートの特徴

    • Lovable、Bolt、Create、v0のようなプラットフォームが、従来は技術ユーザーだけを対象にしていた開発者プラットフォームへユーザーを呼び込んでいる
    • このコホートは質問の種類で容易に識別できる
      • 問題解決力、エラーコードの読解、データベースサーバーとWebサーバーの分離、ロードバランサーなどの意味の理解が、まだ十分ではない
    • こうしたユーザーは、プロトタイピングと本番運用の間の段階で行き詰まることが多い
      • 企業はこの利用を質の高い収益というより効率的なマーケティングとして分類している
      • 開発者がより高い抽象化レベルで作業し始めるにつれて、時間とともに変わると見られている

  • 非技術系メンバーの役割拡大

    • 非技術系メンバーが、コーディングや企業の主要製品外のエンジニアリング作業において、貴重な開発者の時間を確保する助けになっている
    • 適切なツールが与えられれば:
      • AEが技術製品向けのカスタムデモを作成
      • マーケターがXで共有するサンプルアプリを作成
      • コンテンツマーケターが技術ブログ記事を作成

  • 価値あるスキルの再定義

    • ドメイン専門性と顧客とのコミュニケーションが、あらゆる役割でコーディング能力より重要になっている
    • システム思考は、作業が低レベル実装からオーケストレーションや戦略へ進化するにつれて、さらに重要になっている
    • 複雑な要素同士がどうつながるかを理解し、どこで自動化を信頼すべきかを知り、人の介入が不可欠な時点を見極められる個人やチームが成功する
    • ソフトウェアの提供はかつてないほど速く容易になったが、開発者の定義の変化は、持続可能なビジネスの基本原則の重要性を回復させている
    • Netlify CEO: 「現在、JavaScript開発者は1,700万人おり、彼らは従来型の開発者です。しかし今後10年で、その数は1億人に達すると予想しています」

法則 #6: 強力なネットワーク効果が早期のエコシステムポジショニングを後押しする

  • 従来の開発者企業は、オープンソース、コミュニティ貢献、統合、プラグインを通じてネットワーク効果を育ててきた
  • 今やエージェント型開発の広がりによって、ネットワーク効果が再定義され、再構想されている

  • エージェント間ネットワーク効果

    • AIエージェントが他のエージェントと通信し、構成できるときに、より有用になるというエージェント間ネットワーク効果が現れている
    • 例: 会議を予定できるスケジューリングAIエージェントは、相手の旅行エージェント、経費管理エージェント、カレンダーエージェントと通信できると、さらに強力になる
    • MCPのようなプロトコルによって可能になる

  • データのネットワーク効果の増幅

    • コンテキストによってデータのネットワーク効果が増幅される
    • AIエージェントが持つコンテキストが多いほど、望まれた作業をより多く完了できる
    • そのコンテキストを保有する製品の価値が高まる
    • LinearのProduct Intelligenceの例
      • 何千ものエンジニアリングチームが実際にどう機能しているかについて、長年蓄積されたデータを保有している
      • タスク割り当ての提案、イシュー分類、プロダクト運用の簡素化が可能になる

  • 統合ロックイン効果の弱体化

    • 統合によるロックイン効果は、従来はスイッチングコストを生み出していた場面で弱まっている
    • Recall CEO David Gu: 「今では異なるAPI間の切り替えがこれまでになく簡単です。人間が統合コードを手作業で書く必要がなく、AIエージェントが助けてくれるからです」
    • MCPは、AIエージェントがツールを自動で発見して統合できるようにし、ロックインをさらに減らす
    • LLMは一般に、評価プロセスの中で選択肢を調査し、総合することを誰にとっても容易にしている
    広告

  • AI主導の推薦環境における逆説

    • AIが開発者ツールの推奨判断を主導するエコシステムでは、人間の主観的フィードバックの役割が逆説をもたらす
    • AIエージェントは、使いやすさのような主観的な好みを無視し、性能やレイテンシのような客観的な性能指標だけに集中する可能性がある
    • 一方でAIエージェントは、時間とともに学習するにつれて、主観的な人間のフィードバックにより依存するようになる可能性もある
    • この逆説は、どちらの場合でも最高品質の製品が利益を得ることを意味する
      • 開発者主導の成長、製品ローンチ、ドキュメント、教育コンテンツ、カンファレンス、コミュニティフォーラム、レビューがはるかに重要になる
      • スピードはこれまで以上に重要であり、先行者優位が複利的に作用する

  • リーダーたちの多様な視点

    • これらの法則は依然としてWIPであり、企業リーダーたちは異なる見方を示している
    • Vapi CTO Nikhil Gupta: 「AIは非客観的な基盤のネットワーク効果を弱め、客観的なネットワーク効果を強めます。たとえば、人はStripeのAPIが他より最も使いやすいと思うかもしれませんが、AIエージェントはStripe APIとAyden APIを比較するときに使いやすさを気にしないでしょう。しかしStripeの方が信頼性が高ければ、すべてのAIエージェントがそれを選びます」
    • Resolve CEO Spiros Xanthos: 「エージェントファーストのGTMは誇大宣伝ではなく、実証に関するものです。顧客環境に現れて重要な成果を届ければ、採用は自然に広がります。それが新しい伝道です」

法則 #7: プラットフォームエンジニアは自律フローアーキテクトへ進化

  • プラットフォームエンジニアリングの役割は、ソフトウェア管理から自律的なエンジニアリングフローの生成へと拡大
  • プラットフォームエンジニアは、あらゆる技術チームのユーザー体験に責任を持つ
  • 組織内での重要性が、採用の緊急度にもますます反映されている

  • 責任領域の変化

    • プラットフォームエンジニアには、今や次のような技術が必要
      • 明確な人間による監督ステップを備えたエージェント型フローの設計
      • エージェントが誤った作業を行うリスクを管理するための強力なガードレールの実装
      • 稼働時間と信頼性を超えて、システムおよび情報アーキテクチャを所有
    • エージェントが日常的な作業を処理する一方で、最も複雑で戦略的な意思決定のためのAIコントロールセンターを構築

  • ソフトウェアエンジニアの役割転換

    • AIエージェントが実際のコード生成の多くを担うようになるにつれ、ソフトウェアエンジニアは職人的な作り手から、自らのシステムのプロダクトオーナーへと移行
    • この根本的な変化は、エンジニアが実装の詳細よりも成果にますます関心を持つことを意味する

  • 新しいワークフロー要件

    • 強力なテストとモニタリングが重要になる
    • ドキュメントはコード構造だけでなく、システムの挙動も説明しなければならない
    • コードレビューは構文チェックから、ビジネスロジックおよびアーキテクチャ上の意思決定の検証へと移行

  • 組織的な含意

    • 個々の生産性を超えて広がる含意
      • チームには知識伝達のための新しいプロセスが必要
      • 元の実装ロジックを人間が完全に理解できない場合、インシデント対応はより困難になる
      • 生成されたコードを人間が読めない場合、技術的負債は異なる形で蓄積する
    • エンジニアが自分のコードの作者ではなく運用者になるとき、システム信頼性を維持するために可観測性、自動テスト、アーキテクチャガバナンスへ大規模な投資が必要

  • 検証のボトルネック

    • AIが前例のない速度でコードを生成するにつれて、主要なボトルネックはコード作成から正確性の検証へと移行
    • 開発速度を根本的に変化させる
      • チームは数分で数千行のコードを生成できる
      • それが意図どおりに動作し、既存システムと適切に統合され、セキュリティおよび性能要件を満たしているかを検証するには、はるかに長い時間がかかる
    • より優れたテストフレームワーク、リアルタイム検証ツール、視覚的確認システムによって検証速度を最適化する企業は、AI支援開発サイクルにおいて大きな優位性を持つ

  • Render CEOの見解

    • 「プラットフォーム管理における最も重要で継続的な変化は、インフラ管理から開発者ワークフロー最適化への移行だ」
    • エンジニアリングチームは今や、カスタムの社内開発・デプロイプラットフォームの構築と維持管理が、しばしばコアビジネスからリソースを奪う差別化されない作業であることを認識している
    • Renderのようなマネージドプラットフォームを活用して基盤インフラを処理することで、プラットフォームエンジニアはより高い価値の自動化に集中できる
    広告

法則 #8: 防御可能性は継続的進化とプラットフォーム支配に関するもの

  • 本質的に、プラットフォームになるとは、第三者が共同で、そしてその上に構築できる拡張可能なインフラを作ること
    • より多くのユーザーが貢献し、真のコミュニティからの愛着を示すほど価値が高まるエコシステムを活性化する

  • SaaS時代との連続性

    • この概念はSaaS時代から一貫して維持されている
    • AI時代は、防御可能性の特定の柱を引き上げる

  • 主要な防御可能性の要素

    • 1. 入口の支配
      • GitHubのコードリポジトリ所有や、VS Codeのテキストエディタ支配
      • 確立されたユーザー行動の上に機能を拡張するための戦略的権利をプラットフォームに与える
    • 2. データ優位性
      • 独自の製品データセットと、競合が複製できない機能を可能にする企業固有のコンテキストによって現れる

  • 最も根本的な変化: 継続的進化

    • 継続的進化が最も重要
    • 最高のプラットフォームは、複数のAIモデル、データソース、ワークフローを能動的に調整して自律的行動を実行する
      • エコシステムから得られる固有のデータを保有する傾向がある
      • エージェント型および顧客との相互作用からのリアルタイムなフィードバックループのために、データを迅速に活用できる

  • スピードの重要性

    • スピードが核心であり、追加機能の提供と戦略立案の両面で重要
    • 企業は、SaaS時代に必要だったよりもはるかに早い段階で Act 2 と Act 3 のビジョンを考えなければならない
    • これが今後どのように進化し続けるのかを見るのが楽しみだ

  • Port CEOの見解

    • 「仕事の進め方を変える最初の存在になることが重要だ。プロダクトの観点では、継続的に進化していく何かを構築することだ」
    • 「たとえばCRMのようなプラットフォーム。誰かが管理し、統制し、見解を持ち、コアとなるビルディングブロックから反復していく」

追加の推奨読書資料

関連記事

1件のコメント

 
progdesigner 2025-10-28

だから、どうすべきかはまだ誰にもわからない
素早く対応し、変化していくことだけが生存戦略になる
そんな時代のようだ