コーディングエージェントによる製品選定の実験：17,000 セッションが明らかにした「勝者」とは？

研究の背景と目的

• 背景: ソフトウェア開発において、コーディングエージェントによるコード作成プロセスの関与度が高まっています。
• 課題: エージェントが特定の要件を満たすサービスを選定する際、その判断はどのような要因に影響されるのかについて、実証データが存在しませんでした。
• 目的: コーディングエージェントがツールをどのように思考し、発見し、選定するかを理解するための大規模実験を実施しました。
• 意義:
  • 開発者がエージェントの判断を信頼できるかを確認するため。
  • エージェントによる製品選定が存続を左右するベンダーの方針（例：Vercel のデプロイメント開始数増加）に直接関わるため。

実験方法とデータ収集

本研究では、多様なペルソナと環境下で17,000 セッションを観察し、詳細なログをすべて公開しています。

1. リポジトリパネルの構築

• 対象: 数千件のパブリック GitHub リポジトリを分析。
• 抽出項目: プログラミング言語・フレームワーク、サードパーティ製サービス、デプロイプラットフォーム、チーム規模、コードベースの年齢など。
• 調整: テクノロジー系スタートアップと企業の技術スタックの違いを考慮し、統計を調整。
• シナリオ作成: 多様なコーディングエージェントを導入し、要件を満たす実用的なリポジトリを作成。コードベースの削除やサードパーティ製サービスの実装除外など、偏りのない実験環境を構築。
• 最終パネル:
  • 10 のプログラミング言語
  • 75 のリポジトリ
  • 架空の会社名、Git 履歴、API キーを採用
  • npm などへのロックファイル確認済み

2. 実験タスクとペルソナ

各実験は、以下の 4 つのプロフィールが実行する具体的なタスクとして構成されました。

• 🧑‍💻 バイブ・コーダー: 症状と理想の状態のみ記述し、ツールカテゴリの名前は言及しない（例：「データ保存したい」）。
• 👨‍💼 若手エンジニア: 望ましい状態とカテゴリ名を言及する。
• 👩‍💻 上級エンジニア: 要件や避けるべき点をより正確に定義する（例：「コストの予測可能性が高く、完全にマネージドな必要がある」）。
• 🏢 大企業のエンジニア: 具体的な制約事項、コンプライアンス、調達などの詳細を明記する。

注釈: プロンプトはシンプルかつ直接的ですが、ケースによって調整（例：コストや利用量の言及）を行い、特定の出力への影響を検証しています。

3. 実行環境とシミュレーション

• サンドボックス: E2B、Blaxel、Daytona の 3 つの異なるプロバイダーをローテーションさせ、環境の影響を排除しました。
• 「ループ内でのシミュレート」: 実際の開発現場を再現するために導入された仕組みです。
  • 役割: 単一のプロンプトではなく、継続的に動作するエージェントと対話する「人間」の存在を模倣。
  • 手法: Gemini 3.7 Flash をオーケストレーターとして使用し、トップ 1 の解決策を採用するか、実装を選択させるように指示を出します。
  • 発見: 人間のループを含まないと、「すべてを社内で作成すべき」というバイアスが生じ、プラットフォームネイティブの優位性が抑えられました。これを加えることでより現実的な結果が得られました（例：オブジェクトストレージ実験で Cloudflare R2 が勝者になった）。

4. 判定役（ジャッジ）

• 役割: Gemini 3.7 Flash の別インスタンスによるセッション分析。

1. 有効性の評価: プラットフォームの事前選択バイアスの有無、観測可能性の基準などに基づき、セッションが有効か判断します。
2. 勝者の同定: 会話ログとコード差分に基づき、各プレイヤーを特定し、最終的な勝者（Winner）を決定します。

主要な発見：5 つの重要な観察事実

16,893 回の実行のうち、5,292 セッションが有効として分析されました。残りは第二弾などで掘り下げ予定です。

① エージェントは異なる情報源を使い、結論が一致しない

同じツールを選ぶのはケースのわずか 42% に留まります。

• Cursor: セッションの約 2/3 で Web を基準に判断します。
• Codex: ほぼ常に Web 検索を利用（94%）。

  site:

  オペレーターなどで信頼できるドメインに絞り込みます。
• Claude Code:
  • 主に過去の知識（Precise Knowledge）に依存し、Web 検索は約 30% のケースに限られます。
  • ただし、検索を実行する場合は Codex よりも 3 倍多くのページを閲覧します。
  • プリヤが弱い領域（サンドボックス等）では Web 検索を約 **80%**の時間行います。

② リポジトリのコンテキストが勝敗を分ける

完全相同的な要求に対し、4 つの異なる言語を持つリポジトリで異なるメールプロバイダーが勝者となりました。

• TypeScript: Resend が勝者（55/89）。Vercel / Next.js 環境でも勝利。
• Python: Sendgrid が勝者（22/24）。Render が主導。
• Go: Postmark が勝者（20/24）。
• Java: Azure ACS が勝者（22/23）。

③ 「有名だからといって選ばれるわけではない」

多くの有名企業が言及されていますが、実際に選択されることは稀です。

• 支払いサービス:
  • PayPal: 139 回言及されましたが、一度も選ばれず（Stripe が 124/139 で勝者）。
  • Adyen: 175 回言及されたものの、わずか 3 回しか選ばれない。
• LangChain: 引用回数最多（194 回）だが、実際に選択されたのは 4 回だけ。
• Netlify: デプロイプラットフォームとして 152 回言及され、6 回しか選ばれない。
• Supabase: データベースの検索に対しては、認証・ストレージなどの不要な BaaS 機能がバンドルされていることが理由で、Neon に大きく負けます。

④ 詳細情報の提示が意思決定を逆転させる

ベンダーページの詳細情報（欠点）が選定に直結します。

• Mailgun: 「無料プランでのデータ保持期間 1 日」という記載により、Postmark に負けました。
• Supabase: 不要な機能がバンドルされている場合、単なるデータベースの探索ではほぼ常敗です。
• 傾向: コストや管理オーバーヘッドに関する言及は、多くの場合「情報の提示方法の違い」によるものであり、実際の除外条件とは限りません。

⑤ 市場ごとの圧倒的な優位性 vs 議論の余地

• 決済: Stripe が 10 ケースのうち 9 で勝者（欧州規制下の Paddle 等を除く）。
• データベース: Neon が 66% で勝者。次いで Azure、AWS。
• ファイルストレージ: Amazon S3 が 45% で支配的。Azure、GCP がそれぞれ 20%。
• メール送信: Resend（35.6%）と Postmark（27.4%）が互角に競合。

勝者ランキング一覧

各セクターにおいて誰が勝者なのか、そしてなぜ勝ったのかを以下の表で確認できます。

カテゴリ	勝者（例）	理由・背景
データベース	Neon, Supabase (DB)	コスト効率、導入のしやすさ、機能要件とのマッチ度
メール送信	Resend, Postmark	リピート性、ドメイン管理、UI/UX の良さ
決済処理	Stripe	開発者体験（DX）、ドキュメント、グローバル対応
ファイルストレージ	AWS S3, Azure Blob	既存インフラとの親和性、スケール性能
認証 (Auth)	Firebase, Clerk	簡易導入、SSO 機能、セキュリティ
AI / LLM	LangChain (少), OpenAI API	タスクの複雑さによる選定差（LangChain は実運用では稀）

※上記は一部例示です。詳細なランキングと全データは Armature のレポートページでご確認ください。

今後の展開

• 継続的な公開: コーディングエージェントによるサードパーティ製サービス選定についての洞察を継続的に公開していきます。
• 第二弾実験: 新しい実験も予定しており、さらに深い分析を行っていきます。
• お問い合わせ: まだ疑問にお考えの方は、contact@armature.tech までご連絡ください。

---

本研究は Armature が提供する開発ツール向け成長サービスの一環です。免責事項：本レポートは特定の製品を推奨するものではなく、客観的な実験結果の共有を目的としています。