AIエージェント4役割で4人チームの仕事を1人で回した論文『One Developer Is All You Need』

ブラジルの大手銀行Itaú Unibancoで、1人のエンジニアが4つのAIエージェントを使って、4人チーム18週間分の開発を9週間で終えたというケース研究がarXivに出た（「One Developer Is All You Need」arXiv:2605.18461v2）。

数字だけ見ると「AI使えば4倍速い」みたいに読めるが、中身は全然違う。
速くなった最大の理由はAIのコーディング速度ではなく、4人チームで必ず発生する「人と人の間の待ち時間」がなくなったこと。
そしてこの構成が成り立つにはコードベースを知り尽くしたベテランが必要で、普通のチームがそのまま真似できる話ではなかった。

何を作ったのか

対象はデジタル署名のプラットフォーム。
すでに本番で動いている4つのマイクロサービスと1つのフロントエンドがある環境に、5つの新機能を追加する仕事だった。
ゼロから作るのではなく、既存システムの中に手を入れる開発で、外部の署名プロバイダ連携、銀行内部のCI/CD、WCAG 2.1 AAのアクセシビリティ基準、金融規制への準拠が求められている。

担当したのは経験8年のスタッフエンジニアで、同じ銀行で4年働いている。
コードベースの構造も業務のルールも頭に入っている人物だった。

速くなった理由はコーディングじゃなくて待ち時間

5機能、25ユーザーストーリーを3スプリント（9週間）で完了した。
当初の見積もりは4人チームで6スプリント（18週間）だった。

ただし、1つのユーザーストーリーが要求から本番に届くまでのリードタイムは15〜20日のままで、処理量（スループット）が上がっても短くならなかった。
論文はこれを、リードタイムがコーディング速度ではなく本番前の最終検証（homologation）の枠、アクセシビリティのサインオフ、下流工程の引き継ぎに縛られているためだと説明している。
短縮されたのはコーディングの速度ではなく、チームメンバー間の引き継ぎと待ち時間だ。

普通の4人チームでは、要求整理をする人、設計レビューをする人、実装する人、セキュリティ確認する人、QAする人がそれぞれ別にいる。
工程が変わるたびに会議が入り、カレンダーの空きを待ち、レビューの順番待ちが発生する。
週2日しか稼働しない人がいれば、そこで数日止まる。
この待ち時間が積もって18週間になる。

1人のエンジニアが仕様を握ってAIエージェントに作業を振ると、この工程間の待ちが日単位から分単位に縮む。
質問があればその場で答え、修正もその場でかける。
カレンダー調整が不要になったことが、キーボードを速く叩くことよりも大きかった。

コードが速く書けても、QA承認やアクセシビリティ確認、本番前の検証環境での最終確認といった下流の工程は残る。
実際、本番前の最終検証は人間が担当し、アクセシビリティは専任の担当者が機能ごとにサインオフしている。「1人」というのは実装を主導する人間が1人という意味で、リリース前の最終チェックまで1人で片付けたわけではない。

スプリントの進み方にも差がある。
スプリント1はリポジトリ作成やインフラ初期化が多く、完了した機能は0だった。
スプリント2で2機能、スプリント3で3機能と後半に加速している。
初期に書いた仕様やプロンプトを後半で再利用できたのと、コアと非コアの作業の切り分けが安定してきたためだ。

AIエージェント4役割の使い分け

1つの巨大エージェントに全部投げるのではなく、4つの役割に分けている。実体のツールは3つで、Devinが仕様作成と非コア実装の2役を兼ねている。

flowchart TD
    A[人間] --> B[StackSpot<br/>要求整理]
    A --> C[Devin<br/>仕様作成]
    A --> D[GitHub Copilot<br/>コア実装]
    A --> E[Devin<br/>非コア実装]
    B --> F[仕様書]
    C --> F
    F --> D
    F --> E
    D --> G[CI/CD+人間レビュー]
    E --> G

StackSpotがユーザーストーリーを整理し、Devinが仕様書を書く。
業務ロジックやユーザー向けの画面まわりはGitHub Copilotのエージェントモードで人間が横について進め、インフラ設定やAPI連携、メッセージキューのような定型作業はDevinに自律実行で渡す。

AIに直接「コード書いて」と投げるのではなく、先に仕様書を作っている。
設計判断、APIの契約、受け入れ条件、規制上の制約を自然言語の仕様書に落としてから、それをエージェントの入力にする流れだ。
論文はこのやり方をSpec-Driven Development（SDD、仕様駆動開発）と呼んでいる。コードではなく自然言語の仕様を主たる成果物として扱い、その品質がそのままAI出力の品質を決めるという考え方で、テストを先に書くTDDをさらに上流へ広げたものに近い。
Claude Codeのマルチエージェントレビューでのサブエージェント分割と発想は近いが、PRレビューではなくプロダクト開発のロール自体を分けている。

仕様が曖昧だとAIの出力も壊れる

AI生成コードの90%が初回レビューで受け入れられたという数字が出ている。
ただしこれは「仕様が十分に具体的だったとき」の数字だ。

仕様が曖昧だったり、既存システム間の暗黙のルールが仕様書に書かれていなかったりすると、どのツールを使っても使えないコードが出たと論文に書いてある。

たとえば、マイクロサービスAからBにリクエストを投げるとき、Bがエラーを返したらAはどうするか。
リトライするのか、フォールバックするのか、そのまま落とすのか。
こういう判断は過去のトラブル対応で決まっていることが多く、ドキュメントには書いていない。
チームの記憶の中か、コードの中にしかない。
AIはこの種の暗黙知を持っていないので、仕様書に書いていないことは推測で埋めて間違える。
LLMのTool-use APIの記事と同じ構造だ。

テストは統合テスト113件、E2Eテスト65件がすべて通過し、カバレッジも90%超だった。
本番リリース後に見つかった欠陥はゼロで、プロジェクト全体で唯一の欠陥は本番前の検証段階で見つかったアクセシビリティのバグ1件だった。
自動テストで拾えないUI上の判断は人間に残る。

なぜそのまま真似できないか

この構成が成り立った条件を裏返すと、多くの現場で再現できない理由が見える。

担当者はコードベースと業務を知り尽くしていた。
8年の開発経験、同じ銀行で4年。
AIが出してきたコードを見て「この例外処理は社内パターンと違う」「このAPIの呼び方は本番で壊れる」と即座に気づける。
経験の浅い人には、仕様の穴を見抜くことも、AIの「一見動くけど本番で壊れるコード」を弾くこともできない。
4人チームのレビュー機能を1人に集約できたのは、4人分の判断力がその1人にあったからで、AIがレビューを代行したからではない。

作業の大半が既存のアーキテクチャパターンに乗っていた。
CI/CD、非機能要件、アクセシビリティ基準がすでに確立されていて、新しく決めることが少なかった。
「このパターンに従って書いて」とAIに指示できる環境だったから90%の受け入れ率が出た。
プロダクトの方針がまだ固まっていない、ドメイン知識が蓄積されていない、高リスクな規制判断を含む、といった場合はAIに投げる前に人間同士で議論しないと進めない。
そういう場面ではチームの人数を減らすこと自体がリスクになる。

1人に集約するリスクもそのまま残る。
プロジェクトの全知識が1人の頭にあるので、その人が休んだり辞めたりすると全部止まる。
論文では対策として仕様書、意思決定記録、エージェント設定を初日から残すことが挙げられている。
著者らは「2人の技術ペア＋部分参加のプロダクト担当」を現実的な構成として挙げているが、これは提案であって実験結果ではない。

単一ケース研究の限界

1つのプロジェクト、1つの銀行、同じチームの過去実績との比較で、並行した対照群はない。
研究者と実践者が同一人物なので確認バイアスも入る。
エージェント設定の準備コスト、社内の手続きコスト、長期の保守コストは計測されていない。
ソースコード、内部仕様、エージェント設定、計測データは銀行の機密で公開されないため、追試もできない。

参考

• One Developer Is All You Need: A Case Study of an AI-Augmented One-Person Squad in a Brownfield Enterprise
• PDF版 arXiv:2605.18461v2