プロの開発者は「バイブ」せず「コントロール」する:2025年のAIエージェント実態調査
「20年以上ソフトウェア開発をやってきたが、もう絶対に手作業のコーディングには戻らない。そんな時代は終わったし、清々している」──これはSNSの誇大広告ではなく、ある熟練エンジニアが研究調査に残した生の言葉です。
では、その熟練者たちは実際にどうAIエージェントを使っているのでしょうか。「プロンプトをコピペするだけで巨大なアプリが完成した」というSNSの幻想を、現場のデータで検証した論文を読み解きます。
どんな研究か(背景と課題)
本記事で取り上げるのは、2025年12月16日にarXivで公開された 「Professional Software Developers Don't Vibe, They Control: AI Agent Use for Coding in 2025」(プロのソフトウェア開発者はバイブしない、彼らはコントロールする)です。
著者はカリフォルニア大学サンディエゴ校(UCSD)のRuanqianqian (Lisa) Huang氏、Brian Hempel氏、Haijun Xia氏、コーネル大学のSorin Lerner氏、そして独立研究者のAvery Reyna氏。UCSDとコーネル大学の研究チームによる、2025年の最新の現場調査です(arXiv:2512.14012v1)。
2025年、ソフトウェア開発者の約半数がAIツールを毎日使うようになりました。一方でSNSでは「コードを読まずにAIのノリと雰囲気に任せる」バイブコーディング(vibe coding) という言葉が流行し、「数十のエージェントを並行稼働させてアプリ全体を自律生成した」といった主張まで飛び交っています。
しかし現実はどうなのか。UCサンディエゴ校とコーネル大学の研究チームは、この問いに答えるため二部構成の調査を行いました。
- 現場観察(N=13):3〜25年の経験を持つ熟練エンジニア13人を、45分間の作業観察+30分の半構造化インタビューで記録
- 大規模調査(N=99):GitHub上のエージェント関連リポジトリから集めた4,141人に調査を送付し、有効回答99件を分析
ここで重要なのは「熟練者だけ」を対象にした点です。素人ではなく、AIの嘘を見抜く専門知識を持つ人々が、本物の業務タスクをどう処理するか──そこに「何がうまくいき、何がうまくいかないのか」の答えがあるはずだからです。
そして論文の最も重要な結論は、はっきりしています。
プロの開発者はバイブコーディングをしない。彼らは計画と監督を通じて、AIを注意深くコントロールしている。
なぜ「コントロール」なのか:保守の悪夢を避けるため
生産性を上げたいなら、AIに任せて放置する時間が長いほど効率的なはず──直感的にはそう思えます。なぜプロはコントロールに固執するのでしょうか。
理由は、実際のソフトウェアが週末の趣味プロジェクトとは根本的に違うからです。数万〜数十万行のコードでモジュールが複雑に絡み合うシステムでは、AIが全体設計を無視したその場しのぎのコードを書いた瞬間、それは「数ヶ月後に誰も理解できないブラックボックス」になります。ある参加者(P4)の言葉を借りれば、それは 保守の悪夢(nightmare) です。
しかも厄介なのは、AIには人間の見習いと決定的な違いがある点です。人間の見習いなら教官の顔色や会話の文脈から空気を察してくれますが、AIは明示的に与えられた情報しか処理しません。調査回答者S75はこう表現します──「AIは、あなたのことや外界について何も知らない賢い子供(smart kid)として扱うべきだ」。教官が「目の前の山を避けろ」と指示し忘れれば、AIは平気で山に突っ込むのです。
実際、データはこれを裏付けます。AIエージェントに何を期待するかという問いで、99人中67人がソフトウェア品質特性(正確さ・可読性・モジュール性など)を挙げ、生産性のような非品質特性を挙げた37人を上回りました。最も多く言及された品質は「正確さ」(20人)と「可読性」(18人)です。プロは速さと引き換えに品質を妥協していませんでした。
プロの戦略:タスクを刻み、文脈を与える
では具体的に、どうやってAIの暴走を防いでいるのか。観察と調査の両方で最も多かった戦略は 「明確な文脈と、具体的な指示を与えること」(観察12回、調査43回の言及)でした。UI要素・技術用語・関連ファイル・ライブラリ名などをガチガチに指定するのです。
そして、もう一つの驚くべき発見が「タスクの細分化」です。観察対象の参加者P1とP2は、新機能の実装にあたり、AIと協働しながら 70ステップ超もの壮大な実装計画をファイルに書き起こしました。ところが、これほど詳細な計画を作っておきながら、彼らはそれをAIに一気に実行させませんでした。同じく細分化を徹底していた参加者P3は、AIへこう指示しています──「今はステップ1だけを実行してください(Please do just step 1 now)」。計画を作ることと、それをAIに丸ごと走らせることは、プロにとって別物なのです。
これは料理に例えると分かりやすいでしょう。「夕食を作って」と丸投げするのではなく、「まず玉ねぎを5ミリ幅に切って」と指示し、それが終わったら次の指示を待つ。一見、自分で包丁を握ったほうが早いように思えます。しかしプログラミングで最も時間を食うのはコードを書くこと自体ではなく、バグを探し出して直す作業です。70ステップを一気に走らせ、ステップ5でAIが致命的な勘違いをしていたら、残り65ステップは全滅。しかもその最初の勘違いを複雑なコードの中から探すのは人間です。スープが完成してから「塩と砂糖を間違えた」と気づくより、調味料を入れる瞬間に手を止めたほうが、修正コストははるかに低いのです。
観察データはこの「刻む」傾向を明確に示しています。
| 参加者 | 計画のステップ数 | 一度に実行させた最大ステップ数 | 平均実行ステップ数 |
|---|---|---|---|
| P1 | 70 | 6 | 2.2 |
| P2 | 71 | 5 | 1.9 |
| P3 | 5 | 3 | 1.5 |
| 全体平均 | 14.8 | 5.1 | 2.1 |
P1とP2は70ステップ超の壮大な計画を立てながら、AIに一度に実行させたのは最大でも5〜6ステップ。観察全体での平均は わずか2.1ステップでした。さらにプロたちは、テストコードによる自動検証やGitによるバージョン管理(いつでも巻き戻せる安全装置)といった既存のベストプラクティスを、AI時代にそのまま適応させていました。
AIの「スイートスポット」と「危険地帯」
では、AIエージェントは何が得意で何が苦手なのか。調査では59種類のタスクが少なくとも5人以上に言及され、「向いている/向いていない」票で分類されました(数値は「向いている票:向いていない票」)。
| タスク | 向いている票 | 向いていない票 | 判定 |
|---|---|---|---|
| 生産性の高速化 | 35 | 2 | 向いている |
| 単純・定型的なタスク | 33 | 1 | 向いている |
| 明確な計画に沿った実装 | 28 | 2 | 向いている |
| 新規コードの生成 | 27 | 2 | 向いている |
| 雛形・ボイラープレート作成 | 25 | 0 | 向いている |
| ドキュメント作成 | 20 | 0 | 向いている |
| テストコードの作成 | 19 | 2 | 向いている |
| 単純なバグ修正 | 12 | 3 | 向いている |
| プロジェクト全体の設計(高レベル計画) | 13 | 23 | 賛否両論 |
| 一般的なデバッグ | 12 | 8 | 賛否両論 |
| ブレインストーミング・構想 | 11 | 5 | 賛否両論 |
| 検証なしのワンショット生成 | 5 | 23 | 向いていない |
| 既存・レガシーコードへの統合 | 3 | 17 | 向いていない |
| 複雑なタスク | 3 | 16 | 向いていない |
| ビジネスロジック・ドメイン知識が必要なタスク | 2 | 15 | 向いていない |
| 人間の専門知識・意思決定の代替 | 0 | 12 | 向いていない |
スイートスポットは、定型的なコードやボイラープレート、ドキュメント、単純なバグ修正──「ちょっと退屈だがやらなければいけない作業」です。一方の危険地帯は、複雑なビジネスロジック、企業特有のドメイン知識が必要なタスク、レガシーコードへの統合。そして「一発で完璧なコードを出力させる(ワンショット)」は、向いていない票23に対し向いている票はわずか5。プロは「必ず人間が手直しする」ことを前提にしています。
特に興味深いのは、賛否が真っ二つに割れた 「プロジェクト全体の設計」(13対23)です。「設計こそ人間がやるべき最重要部分」と避けるプロがいる一方で、AIを 「ラバーダック」(アヒルのおもちゃに話しかけて思考を整理する開発者の習慣)として高く評価する人もいました。自分にはない視点をくれる壁打ち相手、というわけです。ただし共通する大前提は一つ──最終的な意思決定は絶対に人間が手放さないことです。
プロはAIとの仕事を「楽しんで」いる
細かく刻み、危険地帯を避け、常に手綱を握って監視し続ける──これだけ聞くと、ずいぶん疲れる働き方に思えます。プロは本当にこれを楽しんでいるのでしょうか。
データは意外な答えを示しました。
| 指標 | スコア |
|---|---|
| AIエージェントとの開発の「楽しさ」(6点満点、1=非常に不満〜6=非常に満足) | 5.11 |
| タスクへのエージェントの「適性」(6点満点) | 4.73 |
| AI生成コードを修正する頻度(5点満点、1=しない〜5=常に) | 3.0(=約半分の頻度) |
楽しさは6点満点中5.11──非常に高い数値です。回答者S24はこう表現しました──「F1カーを運転しているような気分だ。よく渋滞に巻き込まれたりもするけれど、それでも未来を楽観視している」。AIが面倒な作業を引き受けてくれるおかげで「再びコーディングが楽しくなった」「コンピュータを初めて触ったときの感動を思い出した」という声が相次いでいます。
つまり熟練者たちは、AIを「自分を置き換えるもの」ではなく 「共同者(コラボレーター)」 と見ていました。F1カーのドライバーはあくまで人間で、AIはその強力なエンジン。回答者S83の言葉が象徴的です──「すべてを“支援付き”でやるが、エージェントを完全に自律させることは決してない。私は常に出力を読み、舵を取っている」。
限界と今後の課題
- サンプルの偏り:現場観察は13人と小規模で、観察対象の12/13人、調査回答者の97/99人が男性。ジェンダーの多様性が乏しく、一般化には注意が必要
- 選択バイアス:調査はGitHubで公開メールを持つ開発者に送られたため、AIに前向きな層が回答しやすい傾向がある(特に「感情」の評価に影響しうる)
- 観察時間の短さ:1人あたり45分の単一セッションのみで、開発の全サイクル(長期的な保守など)は観察できていない
- 専門性の自己申告:観察参加者はWeb上の経歴で3年以上の経験を確認したが、調査回答者は手動検証されていない
まとめ
- プロはバイブしない、コントロールする:熟練開発者はAIに丸投げ(vibe)せず、計画と監督でAIを制御していた。生産性は劇的に上がる一方、正確さ・可読性・モジュール性といった品質を妥協しない
- タスクを刻み、文脈を与える:観察された平均実行ステップはわずか2.1。「賢いが何も知らない子供」に厳格なルールと具体的な指示を与え、少しずつ進めることがハルシネーションと「保守の悪夢」を防ぐ
- 意思決定は必ず人間が持つ:AIは雑用係にも壁打ち相手にもなるが、最終的な責任と意思決定を手放した瞬間にコントロールは崩れる。だからこそプロはAIとの仕事を6点満点中5.11の高さで「楽しい」と感じている
この「コントロールの黄金則」は、ソフトウェア開発に限らず、企画書づくりやリサーチなど日常のAI活用にもそのまま当てはまります。最後に、論文が投げかける問いを一つ。もしAIが面倒な基礎作業や反復タスクをすべて肩代わりするなら──失敗や退屈な作業から学ぶ機会を失った未来の新人は、どうやって「AIの嘘を見抜けるプロ」へと育っていくのでしょうか。あなたの業界ではどうなりそうか、ぜひ考えてみてください。
情報ソース: