AI時代の新しい開発者パターン

• AIを単なるツールではなく基盤技術として扱う開発文化が形成されつつある
• 既存のバージョン管理、ダッシュボード、テンプレート、ドキュメント化、シークレット管理の方法などが、AI時代に合わせて変化している
  • Gitはもはやコードの行単位の変更よりも、プロンプトとテスト結果を中心とした状態管理方式として再解釈されつつある
  • エージェントはコードの作成者であり消費者にもなり、ツール自体を再設計する必要性が高まっている
  • ダッシュボードとUIは自然言語ベースのインターフェースへと移行し、人間とAIエージェントが共に使う形へ発展している
  • ドキュメントは人間とAIの両方のためのナレッジベースへと変化し、エージェントが理解できる形式へ再構成されている

1. AI-Native Git: AIエージェントのためのバージョン管理の再定義

• Gitはもともと、人間が直接書いたコードの行単位の変更履歴を追跡するために設計された
  • しかし、AIがコードの多くの部分を自動生成・修正する状況では、このような細かな追跡の重要性は低くなる
  • 開発者はもはや変更内容そのものより、結果としての挙動が適切かどうか（テスト通過、正常動作など）に注目するようになる
  • SHAは変更があったことは示せても、なぜ変更されたのか、あるいはその変更が有効なのかという情報までは含んでいない
  • とりわけ大規模変更や自動生成コードでは、開発者がdiffを一つひとつ確認しない
• AI-firstワークフローでは、次の要素の組み合わせがより有用な単位になる
  • プロンプト(prompt): コード生成を導いた入力
  • テスト(test): 期待する動作を検証するためのテスト
  • 仕様(spec) および 制約条件(constraints) などの設計上の要件
  • これらを1つのバージョン可能なバンドル(bundle) と見なして管理・追跡する
• これをさらに一歩進めると、Agent-Drivenワークフローでは、Source of Truthがプロンプト、データスキーマ、APIコントラクト、そしてアーキテクチャ上の意図(intent)へと、より上流側へ移動しうる
  • 結果としてコードはコンパイル済み成果物のようなものと見なされ、ソースではなく、これら入力の結果物(byproduct)として扱われる
  • Gitはコードのワークスペースではなく、アーティファクトログ(artifact log) として機能する
    • 誰がどのモデルでどのプロンプトを使ってコードを作ったのか
    • どのテストが通ったのか
    • どの部分を人間がレビューすべきかといったメタデータを一緒に保存する
• 変更履歴にはプロンプトと目的、関連テスト、生成に使ったモデル情報などを含める
  • DiamondのようなAIレビューアツールとの連携により、自動化されたレビューフローも可能になる
  • エージェントが生成したコードと、人間が管理する保護領域を区別して扱える構造など、より豊かなメタデータを階層化できる
• AI-Native Gitワークフローを想定すると
  • プロンプトとそれに基づく変更の流れ、テスト結果、動作したエージェント情報、バンドル情報が一緒に見える、新しいGitダッシュボードの形が現れるかもしれない

2. Dashboards → Synthesis: 動的なAIベースインターフェースへの進化

• 長年にわたり、ダッシュボードは監視システム、分析ツール、クラウドコンソール（AWSなど）のような複雑なシステムと相互作用するための主要インターフェースの役割を果たしてきた
  • しかし、操作要素やチャート、タブが過剰に増えたことでUXの過負荷が発生し、情報探索とアクションの間でユーザーが迷いやすくなっていた
  • とくに非専門家や複数チームが協業する状況では、こうしたダッシュボードは威圧的で非効率なツールと認識されうる
  • ユーザーは自分が達成したい目的は分かっていても、どこを探せばいいのか、どのフィルターを適用すべきか分からないことが多い
• 最新世代のAIモデルは、こうした問題を解決できる可能性を示している
  • ダッシュボードを固定されたキャンバスではなく、探索と相互作用が可能な空間として再解釈できる
• LLMは次のような形でユーザーを支援できる:
  • 「このAPIのレート制限設定はどこで変更できますか？」のような制御箇所の探索
  • 「過去24時間にstaging環境の全サービスで発生したエラートレンドを要約して」のようなデータ統合サマリー
  • 「私のビジネス状況を踏まえて、今四半期に注目すべき指標を推薦して」のような隠れたインサイトの提案
• 現在すでにAssistant UIのような技術は、エージェントがReactコンポーネントをツールのように活用できるよう支援している
  • コンテンツが動的かつパーソナライズされるのと同様に、UI自体もユーザーの意図に応じて再構成され、対話型へと進化している
  • 静的なダッシュボードは、まもなく時代遅れのものと見なされるかもしれない
  • 例:
    • ユーザーが「先週末にヨーロッパで発生した異常を見せて」と言えば、フィルターを手動操作しなくても要約ログとトレンドが自動で提供される
    • 「なぜ先週NPSスコアが下がったの？」という質問に対して、AIがアンケート感情分析、製品リリース履歴との相関分析、診断サマリーまで提示する
• より広い観点では、エージェントがソフトウェアの消費者になるなら、『ダッシュボード』という概念自体も再設計が必要になる
  • たとえば、ダッシュボードはAgent Experienceに最適化されたビューをレンダリングできる
    • システム状態を認識し、意思決定し、行動できるよう、構造化されプログラム的にアクセス可能なインターフェースを提供する
  • 結果として人間ユーザー向けUIとエージェント向けUIが共存する二重インターフェース構造が生まれる可能性がある
    • 2つのUIは同じ状態を共有するが、消費のされ方に応じて構成方法が異なる
• エージェントは既存のアラート、cronジョブ、条件ベース自動化の役割を置き換えつつ、はるかに多くのコンテキストと柔軟性を備えた実行者になる
• 例:
  • 従来: if error rate > threshold then send alert
  • エージェントベース: 「エラー率が上昇しています。原因はこのサービスで、影響を受けたコンポーネントと推奨アクションは以下のとおりです」
• このように、ダッシュボードは単に観測する場所ではなく、人間とAIが協業し、統合し、行動を実行する空間として再定義される

3. ドキュメントはツール、インデックス、インタラクティブなナレッジベースの結合体へと進化中

• 開発者によるドキュメント活用の仕方が変わっている
  • 以前は目次に沿って読んだり、上から仕様を読んだりする形だったが、今では**「まず質問を投げるやり方」**が一般化している
  • 「この仕様を勉強しよう」よりも、**「自分の望む形で情報を再構成してほしい」**という発想への転換が起きている
  • この変化はドキュメントの形態にも影響し、静的なHTMLやMarkdownではなく、インデックス、埋め込み、ツール認識エージェントに支えられたインタラクティブな知識システムへと進化している
• それに伴い、Mintlifyのようなツールが登場している
  • Mintlifyはドキュメントを意味ベースで検索可能なデータベースとして構成するだけでなく、さまざまなプラットフォームでエージェントのコンテキストソースとして活用される
    • 例: AI IDE、VS Code拡張、ターミナルエージェントなどで、Mintlifyのドキュメントがリアルタイムの参考資料として使われる
  • その理由は、コード生成エージェントが最新ドキュメントを学習ベースのコンテキストとして活用するためだ
• これにより、ドキュメントの目的そのものが変化している
  • ドキュメントは単に人間の読者に情報を伝えるものではなく、今やエージェントという消費者のための構造として設計されるべきだ
  • 新しいダイナミクスの中で、ドキュメントはAIエージェントのための利用ガイドの役割を担うようになる
  • これは単なるコンテンツ露出ではなく、システムをどう正しく活用できるかを説明する形式である

4. テンプレートから生成へ: create-react-appを置き換えるバイブコーディング

• 以前はプロジェクトを始めるには、create-react-app、next init、rails new のような静的テンプレートを選ぶのが一般的だった
  • こうしたテンプレートは一貫したアプリ構造を提供する一方で、開発者の意図やスタックに合わせたカスタマイズが難しく、フレームワークのデフォルトに従う必要があった
  • その結果、初期設定から外れようとすると多くの手作業によるリファクタリングが必要だった
• いま、この流れは Replit、Same.dev、Loveable、Chef by Convex、Bolt のようなtext-to-appプラットフォームや、CursorのようなAI IDE の登場によって変わりつつある
  • たとえば開発者が「Supabase、Clerk、Stripeを含むTypeScript APIサーバー」と説明すれば、AIが数秒でカスタムプロジェクトを自動構成する
  • 生成されたスターターは汎用テンプレートではなく、開発者の意図とスタックに最適化された構造で作られる
• この変化はエコシステムの流通構造も変えつつある
  • 以前のように少数のフレームワークがエコシステムの中心を占めるのではなく、さまざまなツールとアーキテクチャを組み合わせたカスタム生成フローが広がっている
  • 核心は、フレームワークを選ぶことよりも「何を作りたいのか」を説明することへと移っている
  • ある開発者は Next.js と tRPC の組み合わせを、別の開発者は Vite と React を選んでも、それぞれすぐに実行可能なプロジェクトとして生成できる
• もちろん、標準スタックには利点もある:
  • チーム生産性の向上、オンボーディング効率、デバッグのしやすさなど
  • ただし、フレームワーク間のリファクタリングは単なる技術的問題ではなく、製品・インフラ・組織能力と絡み合っている
• 変曲点はまさにフレームワーク移行コストが下がったことにある
  • AIエージェントがプロジェクトの意図を理解し、大規模なリファクタリングを半自動で実行できるようになった
  • その結果、実験がしやすくなり、初期段階でさまざまなスタックを試したり、元に戻したりできる余地が生まれている
• 結果として、フレームワークの選択は可逆的なもの (decision reversible) になりつつある
  • 例: Next.js で始めてから Remix + Vite に変更し、エージェントが全体のリファクタリングを処理
• フレームワークのロックイン(lock-in)が弱まり、意見の強い(opinionated)スタックも気軽に試せるようになっている

5. .env を越えて: エージェント中心環境におけるシークレット管理

• 数十年にわたり、.env ファイルは開発者が API キー、データベース URL、サービストークンなどのシークレットをローカルで簡単に管理するための基本的な方式だった
  • この方式はシンプルで持ち運びやすく、開発者フレンドリーだが、AI IDE やエージェントがコードを書き、サービスをデプロイし、環境を調整する状況では問題が生じる
  • つまり、.env ファイルの所有主体が誰なのかが不明確になる
• この問題を解決するための流れが現れている
  • たとえば最新の MCP 仕様には、OAuth 2.1 ベースの認証フレームワークが含まれている
  • この構造は、AIエージェントに生のシークレットではなく、スコープ制限されたトークン(scope-based, revocable tokens) を与える方向性を示している
  • 例: エージェントが AWS 全体のキーを受け取る代わりに、「S3にファイルをアップロードする」といった限定されたアクションだけを許可する短期認証クレデンシャル(credential) を受け取る構造
• もうひとつの流れは、ローカルシークレットブローカー(secret broker)の登場である
  • これはローカル、またはアプリのそばで動作し、エージェントと機密シークレットの間を仲介するサービスの役割を果たす
  • エージェントは .env に直接アクセスしたりハードコードしたりせず、特定の作業を要求した際に、ブローカーがそれをリアルタイムで判断して権限を付与する
    • 例: 「Stagingにデプロイする」または「Sentryにログを送信する」という要求
    • ブローカーはこれをJust-in-time方式で処理し、すべてのアクセスは監査追跡可能となる
• この方式は、シークレットへのアクセスをファイルシステムではなくAPIベースの権限モデルへと転換する
  • 結果として、シークレット管理は .env 構成からOAuthベースの権限制御構造へと発展していく

6. アクセシビリティを普遍的インターフェースへ: LLMの視点から見たアプリ

• 最近の Granola や Highlight のようなアプリは macOS のアクセシビリティ設定を要求するが、これは従来の障害者支援目的ではなく、AIエージェントがUIを観察し相互作用するための用途である
  • これは一時的なハックではなく、より根本的なインターフェース転換の予兆と見なせる
• アクセシビリティ API はもともと、視覚・運動障害のあるユーザーのためにデジタルアクセシビリティを向上させる目的で作られた
  • しかしこの API を拡張すれば、AIエージェント向けの普遍的なインターフェース層として機能しうる
  • ピクセル位置のクリックや DOM スクレイピングの代わりに、支援技術が UI を解釈するように、意味ベース(semantic) でアプリを観察し操作できる
  • アクセシビリティツリーはすでに、ボタン、見出し、入力フィールドなどの構造化されたUI要素を公開している
  • ここに意図(intent)、役割(role)、操作可能性(affordance) などのメタデータを追加すれば、エージェントが目的と文脈に応じて精密に操作できるようになる
• この方向性は次のような機能へ拡張できる:
  • Context extraction: アクセシビリティ／セマンティック API を通じて、画面上に見えている要素、相互作用可能な項目、ユーザーの現在の操作を問い合わせる方式
  • Intentful execution: 複数の API 呼び出しを手動でつなぐ代わりに、「カートに商品を追加して最速配送を選ぶ」のように高レベルの目標を宣言し、バックエンドが実行手順を構成する
  • Fallback UI for LLMs: アクセシビリティ機能は、公開 API のないアプリでもエージェントが利用できるようにするバックアップインターフェースを提供する
    • 開発者は視覚的UIや DOM に加えて、エージェントが認識可能なレンダーサーフェス(render surface) を structured annotation やアクセシビリティ中心のコンポーネントとして定義できる
• 要するに、アクセシビリティ API はもはや人間だけのための機能ではなく、AIとシステムが相互作用するための中核的インターフェース層へと発展している

7. 非同期エージェント作業の台頭

• 開発者がコード作成エージェントと自然に協業するようになるにつれて、非同期ワークフローへの移行が加速している
  • エージェントはバックグラウンドで並列作業を進め、一定の段階まで進んだ時点で結果を報告する形で動作する
  • こうした相互作用は、次第にペアプログラミングというよりタスクオーケストレーション(task orchestration) に近づいている
  • つまり、開発者は目標を伝え、エージェントは実行したうえで後から確認する形になる
• 重要なのは、単に作業を肩代わりすることではなく、協業そのものを圧縮する点にある
  • たとえば、別チームに設定ファイルの更新依頼やエラートリアージ、コンポーネントのリファクタリングを依頼する代わりに、
    開発者がエージェントに直接意図を伝え、バックグラウンドで処理するよう指示できる
  • 従来は同期的な会議、部門間ハンドオフ、長期的なレビューサイクルが必要だったが、
    今ではリクエスト → 生成 → 検証(request → generate → validate) のループが自然に回る
• エージェントとの相互作用の方法も拡張している
  • 単にIDEやCLIでプロンプトを入力する方法以外にも、次のような形が可能である:
    • Slackメッセージで作業を依頼
    • Figmaモックアップにコメントを記入
    • コードdiffやPRにインラインコメントを付ける（例: Graphiteレビューアシスタント）
    • デプロイ済みアプリのプレビューにフィードバックを追加
    • 音声または通話ベースのインターフェースを通じて変更点を口頭で説明
• こうした変化によって、エージェントは開発ライフサイクル全体に存在するようになる
  • コード作成にとどまらず、デザインの解釈、フィードバックの反映、プラットフォーム全体のバグトリアージまで担う
  • 開発者は、どの作業スレッドを進めるか・除外するか・統合するかを決めるオーケストレーター(orchestrator) の役割を担う
• この流れは最終的に、エージェントベースの作業スレッドが新たな「Gitブランチ」という概念として定着する可能性を示唆している
  • もはや静的なコードフォークではなく、目的中心の動的スレッドが非同期で実行され、完成時に統合される形である

8. MCP: 汎用標準にさらに一歩近づいた Model Context Protocol

• 最近、MCPに関する詳細分析記事が公開されて以降、MCPの採用スピードが加速している
• OpenAIが正式にMCPを採用し、複数の新機能が仕様にマージされ、
  ますます多くのツール開発者がMCPをエージェントと現実世界の間の基本インターフェースとして受け入れつつある
• MCPは本質的に、次の2つの重要な問題を解決する:
  • LLMが初めて接する作業でも実行できるように必要なコンテキストを提供する
  • N×M方式のカスタム統合をなくし、ツールが標準インターフェース（サーバー）を公開し、すべてのエージェント（クライアント）が利用できる構造へと単純化する
• 今後、MCPの採用はさらに拡大すると見られ、
  リモートMCPと事実上のMCPレジストリ(de-facto registry) が登場すれば、
  多くのアプリが標準でMCPインターフェースを備えた状態でリリースされる可能性がある
• かつてAPIがSaaSツール同士を接続し、ワークフローを構築できるようにしたのと同様に、
  MCPはAIエージェント向けの相互運用可能な構成要素のエコシステムを生み出しうる
• MCPクライアントを内蔵したプラットフォームは、単に「AI対応」というレベルにとどまらず、
  エージェントがアクセス可能な機能ネットワークへ直接接続できるエコシステムの一部となる
• MCPのクライアントとサーバーは論理的な概念にすぎず、物理的に分離されているわけではない
  • これは、どのMCPクライアントもサーバーになれ、逆もまた可能であることを意味する
  • その結果、次のような高度なコンポーザビリティ(composability) が開かれる:
    • 例: あるコーディングエージェントはクライアントとしてGitHub Issueを取得し、同時にサーバーとして別のエージェントにテストカバレッジやコード分析結果を提供できる
• MCPは、ツールとエージェントが有機的に相互作用するエコシステムのための基本インターフェース層として定着しつつある

9. 抽象化されたプリミティブ: すべてのAIエージェントが必要とする認証、決済、ストレージ

• バイブコーディングエージェントがますます強力になるにつれて明らかになってきたのは、
  エージェントは多くのコードを生成できても、そのコードが接続される信頼できる基盤が必要だという点である
• 人間の開発者が決済にはStripe、認証にはClerk、データベースにはSupabaseに依存するように、
  エージェントにも信頼でき、組み合わせ可能なサービスプリミティブが必要である
• これらのサービスは明確なAPI境界、使いやすいSDK、妥当なデフォルト設定を提供し、
  次第にエージェントのランタイムインターフェースの役割を担うようになる
• たとえばSaaSアプリを生成するツールを作る場合、エージェントが認証システムや決済ロジックを直接実装する代わりに、
  ClerkとStripeを使って迅速かつ安全に統合する
• このパターンが成熟すれば、サービスは単なるAPI提供を超えて次のものを公開できるようになる:
  • スキーマ(schema): 構造化データの定義
  • 機能メタデータ(capability metadata): 実行可能な作業の仕様
  • サンプルフロー(example flows): 統合方法に関する事例
    → これにより、エージェントはより安定して統合できる
• 一部のサービスはそもそもMCPサーバーを内蔵した状態でリリースされる可能性がある
  • 例: ClerkがMCPサーバーを通じて、利用可能な商品一覧の照会、新しい料金プランの作成、サブスクリプションの変更などの機能を公開する
  • エージェントはAPI仕様やドキュメントを探す代わりに自然言語で依頼し、
    MCPサーバーは権限範囲と制約条件の中でその依頼を検証・処理する
  • 例:
    > 「月額$49のProプランを作成して、従量課金の追加請求を設定して」
    → ClerkのMCPサーバーがこの依頼を解釈して実行する
• 初期のWeb時代にrails newが高速な開発を可能にしたように、
  エージェント時代には信頼できるプリミティブ(drop-in identity、決済、アクセス制御など) が必要である
  • それらは十分に抽象化されていてエージェントが生成に活用できる一方で、
    アプリの成長に合わせて拡張可能な構造でなければならない

結論

• これら9つのパターンは、単に既存の開発方式にAIを載せるのではなく、エージェント・コンテキスト・意図を中心にソフトウェアの作り方そのものが再定義されつつあることを示している
• それに伴い、従来の開発者の行動様式も変化しており、それを支える新たなツールチェーンやプロトコル（MCPなど） が急速に登場している
• Git、テンプレート、ダッシュボード、ドキュメント化の方法など、既存の中核的なツール層がAIとともに根本から再設計されつつある
• この転換期を迎え、新しい開発エコシステムを構成する次世代ツールとインフラへの構築と投資が活発に進むことが期待される

[aa1567]

1番を本当にやる人がいるのか……？

[hhcrux]

LLMは同じ入力に対して同じ出力を保証しないのに、ああいう形での構成管理が通用するということなんでしょうか……
まだ自分はあまりにも一次元的にしか使えていないのかな

[beoks]

temperature オプションを 0 に設定すると、同じ入力に対して同じ出力が保証されると理解しています

[fanotify]

どうせ数か月もすればまたモデル自体が変わるのだから、意味がないのではないでしょうか。

[beoks]

それはさておき、そもそも人間の介入を考慮していない点があまりにも断定的ですね。
簡単な数値やメッセージの修正であれば、LLMより人間が介入したほうが効率的でしょう。

[nicewook]

深い洞察を感じる文章です。さすが a16z です。

[ruinnel]

https://ja.news.hada.io/topic?id=21091
この記事を読んだあとだと、これで合っているのかなと思ってしまいます。

[ahwjdekf]

1番は本当に悪夢のような、絶対に受け入れたくない変化ですね。ソースコードの履歴追跡が無意味になってしまうということです。