AI時代の開発フローの考察 — Stripe・Spotify・Ramp・Airbnbの事例から読む「コードを書かなくなった後」の5つの変化

「AIで開発が速くなった」の中身を、事例で確かめる

「AIでコーディングが速くなった」という話は、もう聞き飽きたかもしれない。 ただ、開発フロー（仕事の流れそのもの）がどう組み替わったのかを具体的に語れる人はまだ少ない。 エディタの補完が賢くなった話と、チケットを投げたらPRが返ってくる話では、変わっている場所がまるで違うからだ。

そこで本記事では、エンジニアリングブログで仕組みまで公開している企業の事例を並べ、「何がどう変わったのか」を共通点から抜き出す。 取り上げるのは Stripe・Spotify・Ramp・Airbnb・Anthropic の5社と、 楽観論に水を差す調査データ2本（METR・Qodo）だ。前半で事例を読み、後半で考察する。

事例編：5社は開発フローをどう組み替えたか

事例1 Stripe「Minions」— Slackから投げて、戻るとPRができている

Stripe の Minions は、1回の依頼で最後まで走り切る（one-shot, end-to-end）社内コーディングエージェントだ。 2026年2月の Part 1 では 「人間が書いたコードを1行も含まないPRが毎週1,000件以上マージされている」とされ、 10日後の Part 2 では1,300件以上に増えた。 ただしすべてのPRは人間がレビューしている。

起動するのは主に Slack だ。変更について議論しているスレッドから、そのままエージェントを走らせる。 ほかにもCLI・Web、社内のドキュメント基盤・フィーチャーフラグ・チケット画面から呼び出せる。 仕組みで目を引くのは次の3点だ。

• 人間と同じ開発環境：エンジニアが使う devbox（開発用の隔離マシン）と同じものを約10秒で立ち上げる。本番環境とインターネットからは隔離されている
• 決定論とエージェントの混在：「Blueprint」と呼ぶワークフローをコードで定義し、決定論的に実行するノードとエージェントが考えるノードを組み合わせる。たとえばリンターはエージェント任せにせず、push前に決定論のノードとして回す
• CIは最大2回：300万件超のテストから関連分を選んで実行し、自動修正できるものは適用する。残った失敗はエージェントに1回だけ直させ、それでもだめなら人間に渡す

社内ツール群は「Toolshed」というMCPサーバーに約500個（Part 2時点）がまとまっている。 ルールファイルは Cursor の形式に統一し、Minions・Cursor・Claude Code で共有しているという。 Stripe の設計思想は、Part 1 の一文にまとまっている——「人間にとって良いものは、LLMにとっても良い」。

事例2 Spotify「Honk」— 移行スクリプトをプロンプトに置き換えた

Spotify には以前から、数千のリポジトリに一括で変更を配る Fleet Management（Fleetshift）という基盤があった。 対象リポジトリの選定、PRの作成、レビュー、マージまでを人間が管理する仕組みで、その中で実際にコードを書き換えていたのは決定論的な移行スクリプトだった。

Honk Part 1（2025年11月）によれば、 Spotify はこの「移行スクリプト」の部分だけをエージェントに置き換え、周りの基盤はそのまま残した。 言語のモダナイズ、破壊的変更を含む依存関係の更新、UIコンポーネントの移行などで1,500件超のPRをマージし、 手で書く場合と比べて60〜90%の時間を削減したという。 差分はLLM-as-a-Judge（LLMによる採点）で評価し、フォーマットとリントはMCP経由で回す。

2026年6月の 「Coding Is No Longer the Constraint」 ではさらに数字が大きくなった。 エンジニアの99%が毎週AIツールを使い、PRの頻度は76%増えた。Fleetshift経由でマージされた自動メンテナンスPRは累計250万件を超え、 直近のJava移行は3日で終わった（以前は数週間〜数か月）。 そして記事は、「コーディングの速度が上がるほど、制約は人間の意思決定の側へ移る」と結論づけている。

事例3 Ramp「Inspect」— マージ済みPRの75%をエージェントが書く

Ramp の Inspect は、リモートのサンドボックスで動く社内のバックグラウンドコーディングエージェントだ。The Pragmatic Engineer の取材記事によると、 Ramp でマージされるPRの75%がInspectのセッションから生まれている。 2026年1月の公表時点では約30%だったので、半年あまりで倍以上に伸びたことになる。

Inspect の特徴は検証の厚さにある。エージェント自身がバックエンドのテストを回し、テレメトリーとフィーチャーフラグを確認する。 フロントエンドはスクリーンショットとライブプレビューで見た目まで確かめる。 つまり「ビルドが通ったので終わり」ではなく、Rampのエンジニアが普段使う確認手段をひととおり使わせている。 完全に準備されたリモート開発環境は5秒以内に立ち上がり、依頼は Web・Slack（「@inspect fix this」）・Chrome拡張から出せる。

自社で作った理由として挙がっているのは、ローカルマシンで並列に走らせられるエージェント数には限りがあることと、 システムをまたぐ調査にリモート環境が必要だったことだ。 作っているのはわずか5.5人のチームだが、Inspect のコードベースには社内150人以上が貢献している。

事例4 Airbnb — 3,500ファイルの移行を「状態機械 × リトライ」で

Airbnb は、React コンポーネントのテスト約3,500ファイルを Enzyme から React Testing Library へ移行した （Airbnb Tech Blog）。 2つのライブラリはテストの考え方が根本的に違うため、機械的な置換では移行できない。テストの意図を読み取って書き直す必要がある。 手作業なら1.5年と見積もられていたこの移行を、6週間で終えた。

パイプラインは4段階の状態機械だ（Enzymeのリファクタ → Jestの修正 → Lint・TypeScript → 完了）。 各ファイルが段階を順に進み、チェックに落ちたところでLLMを呼んで直させる。 プロンプトには関連ファイル最大50個を詰め込み、4万〜10万トークンに達した。 最初の4時間で対象の75%が移行でき、4日間の調整で97%に到達した。残り3%は、LLMが生成したコードを土台に人が1週間で仕上げた。

事例5 Anthropic — 「先にテスト」と「スロットマシン」

Anthropic は2025年7月に、社内チームの Claude Code の使い方を公開した。 開発フローの観点で面白いのは、チームによって正反対の使い方をしている点だ。

• セキュリティエンジニアリング：以前は「設計書 → 雑なコード → リファクタ → テストは諦める」という流れだった。これを、Claudeに疑似コードを書かせ、テスト駆動開発（TDD）で導き、定期的に様子を見る流れに変えた
• 自律ループで回すチーム：抽象的な課題を渡して自律ループで走らせ、出てきた解を見て採用するか、やり直すかを決める。当たるまで回す、いわばスロットマシン型

前者は「人がテストで仕様を先に固める」やり方、後者は「エージェントに試行させて人が選ぶ」やり方だ。 向いているタスクがそもそも違う。

5事例の比較

考察編：事例から見える5つの変化

ここからは事例を横に並べて、共通して起きている変化を5つ抜き出す。 いずれも「AIが賢くなった」という話ではなく、フローの形が変わったという話だ。

変化1 開発の起点が「エディタ」から「依頼」に移った

Stripe・Spotify・Ramp の3社はいずれも、Slackやチケットから依頼を投げ、PRで受け取る形になっている。 エンジニアがエディタの前に座っている時間とエージェントが働く時間が切り離され、非同期・並列になった。 Ramp が自社でInspectを作った理由の筆頭が「ローカルでは並列数に限界がある」だったのは象徴的だ。 開発の単位が「1人が1つのブランチで作業する時間」から、「同時に何本のエージェントを走らせ、何本のPRを受け取れるか」に変わりつつある。

その結果、依頼を書く力がそのまま開発の品質を決めるようになった。 Slackのスレッドから直接起動できるという設計は、議論の文脈そのものが仕様書になることを意味する。 ただ裏を返せば、雑な議論からは雑なPRが出てくる。

変化2 AIの生産性は「開発基盤への過去の投資」で決まる

成功事例に共通するのは、エージェント専用の仕組みを新しく作るより、人間用に作ってきた基盤をそのまま使わせていることだ。 Stripe は devbox と300万件のテスト、Spotify は Fleet Management、Ramp は数秒で立ち上がるリモート開発環境。 いずれもAIブーム以前から、人間の開発者のために作られてきたものだ。 Spotify は2026年6月の記事で、長年の開発者基盤への投資こそがAIを活かせる理由だと書いている。

ここから言えるのは、AIへの投資が効くかどうかは、テスト・CI・開発環境の再現性という「地味な基盤」で先に決まっているということだ。 テストが薄く環境構築に半日かかる組織では、エージェントは検証の手段を持てず、人間のレビューに全部のしわ寄せが行く。

変化3 フローは「決定論の骨格 ＋ エージェントのノード」になった

もっとも実務的な共通点がこれだ。どの事例も、エージェントに全工程を丸投げしていない。 Stripe は Blueprint で決定論のノードとエージェントのノードを組み合わせ、Airbnb は状態機械の中でLLMを呼び、 Spotify は Fleet Management の中で移行スクリプトの位置だけを差し替えた。

flowchart LR
    A["依頼<br/>Slack・チケット"] --> B["環境の用意<br/>devbox・サンドボックス"]
    B --> C(["エージェント<br/>変更を書く"])
    C --> D["決定論チェック<br/>Lint・型・テスト"]
    D -->|失敗| E(["エージェント<br/>失敗を直す"])
    E --> F{"回数の上限?"}
    F -->|まだ| D
    F -->|超えた| H["人間に渡す"]
    D -->|成功| G["PR作成"]
    G --> I["人間のレビュー<br/>マージ判断"]
    H --> I

この形には2つの利点がある。1つはコストと暴走の上限が決まること。Stripe の「CIは最大2回」がその例だ。 もう1つは、機械で判定できることは機械に判定させるので、エージェントの推論は本当に判断が要る箇所にだけ使われることだ。 フォーマッタにトークンを払わない、という Stripe の説明はこの考え方をよく表している。

変化4 「終わりました」の自己申告ではなく、環境で検証する

4つ目の共通点は、エージェント自身の「完了しました」を信用しないことだ。 Ramp はテスト・テレメトリー・スクリーンショットで確かめ、Spotify はLLM-as-a-Judgeで差分を採点し、Airbnb は段階ごとのテストで判定する。 Anthropic のセキュリティチームがTDDに切り替えたのも同じ発想で、合否の基準を先に人が固めておけば、エージェントの出力を機械的に判定できる。

裏返すと、AIに任せやすいのは「成否を機械で判定できるタスク」ということになる。 Airbnb と Spotify の大きな成果がどちらも「移行」だったのは偶然ではない。 移行は「元の挙動を保ったまま書き換える」タスクなので、既存のテストがそのまま合否の基準になる。 一方で「どんな機能を作るべきか」のように正解がテストに書けないタスクは、今も人間の判断が中心だ。

変化5 ボトルネックは「書く」から「信じる・決める」へ

5つの事例のどれを見ても、人間のレビューは消えていない。Stripe の「人手のコードゼロ」のPRも全件レビューされている。 コードの生成量が増えた分、人間の側で詰まる場所が変わっただけだ。

これは調査データにも出ている。Qodo が2026年9月に公開した2026 State of AI Code Quality Report（米国の開発者500人・エンジニアリングリーダー300人）では、 開発者・リーダーとも26%が「AIが生成したコードのレビューと検証」を最大の制約に挙げた。 36%の開発者は、レビューにかかる時間は同じでも、微妙な欠陥を見つけるための認知負荷がかなり増えたと答えている。 既存のプロセスで品質とガバナンスを保てていると考えるリーダーは、わずか3.7%だった。

Spotify の言う「制約は人間の意思決定に移る」は、レビューだけの話ではない。 プロトタイプが数分でできるようになれば、「何を作るか」「どれを捨てるか」を決める速さがそのままチームの速さになる。 開発フローのなかで人間が担う仕事は、入口でのタスク定義と、出口での受け入れ判断の2つにますます集中していく。

実務への示唆：自分のチームで何から始めるか

5つの変化を踏まえると、AI時代の開発フローづくりは「どのエージェントを入れるか」より前に、次の順で考えると失敗しにくい。

最後に、この記事の考察にも限界がある。取り上げたのはエンジニアリングブログで成果を公開した企業であり、 うまくいかなかった事例は表に出にくい。また Stripe・Spotify・Ramp はいずれも、もともと開発基盤への投資が厚い組織だ。 「開発基盤への投資がAIの効果を決める」という考察自体が、この偏りから導かれている可能性はある。 それでも、AI時代の開発フローの競争力が、AI以前からの地道な基盤づくりで決まるという見立ては、 自分のチームを振り返るうえで十分に使える物差しだと思う。