AIコーディングブームはもう終わった——米MS現場が示す「次のフェーズ」とエンジニアの生き方
米マイクロソフト Azure Functions プロダクトチームのシニアソフトウェアエンジニア、牛尾剛さんがこんな言葉を残している。
「マイクロソフト本社では、コーディングエージェントブームは数カ月前に去っていて、いまは違うことに興味がある感じですね」
この一言だけを切り取ると「やっぱりAIコーディングは失敗だったのか」と読めてしまうが、それは真逆の解釈だ。続く言葉がすべてを語っている。
「使ってないという意味じゃなくて、別にそこまで興味持ってないというか当たり前になってる。定着したので。言うたらね、WordやExcelと同じように当然使うものになった感じです」
「ブームが終わった」と「日常に溶け込んだ」は、まったく違う話だ。この区別を最初に押さえておかないと、この記事全体の意味が変わってしまう。
AIコーディングブームは「終わった」のではなく「定着した」
何かがブームになるということは、それがまだ特別だということだ。誰もがChatGPTを試した2022〜2023年ごろ、コーディングエージェントも「魔法のツール」として語られた。ところが道具というものは、使い倒されるうちに「当たり前」になる。
牛尾さんはコーディングエージェントをWordやExcelに例えた。これは地味に重要な比喩だ。Excelを使いこなせないエンジニアが今どう見られるか、それを想像すれば、AIコーディングツールが「使えない」ということが数年後に何を意味するかも自ずと見えてくる。
ただし、「定着した」というのはゴールではなく、次のフェーズへの入口だ。現場で使い続けることで、ローカルで動くコーディングエージェントの限界も鮮明になってきた。
現場で何が起きているか：インシデント対応のフル自動化
牛尾さんが語る現在の最前線は、もはやコーディング支援の話ではない。
「コーディングエージェントってもともと、プログラマーがコードを書くのをAIが支援してくれるために誕生したじゃないですか。それで何でもやるという方向性は、十徳ナイフで何でもこなそうとしている感じに思います。だから実際に使い倒していくと、いろいろ面倒くさいことが出てくるんですよね」
具体的な「面倒くさいこと」として挙げられるのが、自動化との相性の悪さだ。ユーザートークンは途中で失効する。ブラウザにログイン画面が出てきて手動でクリックしなければならない。ローカルPCを使わなければならないので「勝手にやっておいて」が成立しない。これらは設計上の問題であり、「開発者が使う前提」で作られたツールを「完全自動化の歯車」として使おうとすることの無理が出ている。
では最前線では何が起きているか。牛尾さんのチームが取り組むインシデント対応の話が具体的だ。
「インシデントがプスっと来ると、インシデントを受けてクラウドのエージェントが勝手に動いて、いろんなクエリをアドホックにうまいこと投げてくれて、僕らの内部のドキュメントを呼んだりしながらバッサーっと動いて分析して、RCA（Root Cause Analysis：根本原因分析）を提供してくれるんですよね」
さらにこう続く。
「ミティゲートって言えるコンフィデンス（確証）があれば自動でミティゲートしますし、分析の途中でここは間違ったチームにルーティングされたからこっちに渡してあげないけませんっていうのが分かったら、自動で他のチームに転送されます。インシデントがリゾルブの状態になったときは別のエバリュエーションエージェント（評価用AIエージェント）が勝手に走って、これを評価しますし、問題があれば定義を改善してプルリクエストを作ります」
障害検知 → 原因分析 → 応急処置 → チーム転送 → 解決評価 → プルリクエスト作成。これらすべてをAIエージェントの連鎖が担い、人間はその上流の設計と、結果の最終判断に集中する。これが「ヘッドレス（全自動化）」への移行だ。
「十徳ナイフ」の比喩が示す構造的問題
牛尾さんが「十徳ナイフ」と表現したのは、コーディングエージェントが本来「開発者支援」という文脈で設計されたツールだということだ。これ自体は批判ではない。設計思想の話だ。
開発者支援ツールは、人間が途中で確認しながら使うことを前提にしている。だからこそ、トークンが失効してもブラウザで再ログインできるし、手動操作の余地が残っている。ところが「エンジニアがいない夜中に障害が起きて、自動で対処してほしい」というユースケースには根本的に向いていない。
この構造的問題を解決するのが、クラウドネイティブなAIシステムだ。ユーザーの代わりにシステムが動く。サービスアカウントで動く。ローカルPCを使わない。そしてAI同士が連携して一連の処理を担う。
ここが「コーディングエージェントのブームが去った」本当の理由だと思う。ブームが去ったのではなく、その役割が限定的なものとして位置付けられ、より広いアーキテクチャの中の一部品になったということだ。
ここからは見方だが：この流れが示す業界の方向性
米マイクロソフトの最前線が先行指標だとすると、この話には業界全体への示唆がある。
一つ目は、「AIが道具」から「AIがシステムの一部」へのシフトだ。Copilotのように人間が呼び出す形から、エージェントが自律的に動いてAI同士が連携する形へ。これは単なるUIの変化ではなく、開発プロセスそのものの再設計を意味する。
二つ目は、エンジニアの役割の変化だ。「コードを書く人」から「AIが正しく動ける仕組みを設計する人」「AIの判断を評価する人」へ。牛尾さんのチームの例で言えば、エバリュエーションエージェントが自動で動くとはいっても、「何をもってインシデントが正しく解決されたと判断するか」の定義は人間がする。その定義の質がシステム全体の品質を左右する。
三つ目は、「AIを使えるか」という問いが陳腐化しつつあるということだ。Wordが使えるかどうかを聞かれる人はもはやいない。同じように、AIコーディングツールを使えるかどうかは、近い将来「使えて当然」になる。問われるのはその先だ。
実務的な示唆：日本のエンジニアは何を考えるべきか
日本の開発現場がマイクロソフト本社と同じフェーズにいるかというと、正直そうではない企業の方が多いだろう。多くの現場ではまだ「AIツールを試している」段階だし、ヘッドレス化などはまだ先の話に見えるかもしれない。
ただ、だからこそ今が考えどきだ。
「使い方」の習熟で差がつく時代は、思ったより短い。 ツールが普及し、UIが整備され、「普通に使えるもの」になるにつれて、差別化の軸はツールの使い方から離れ、ツールの上で何を設計するか、何を判断するかに移っていく。
具体的に言うと、次の3点が問われるようになると見ている。
1. システム全体を設計する力。 AIエージェントをどこに組み込み、どのトリガーで動かし、どのデータソースにアクセスさせ、どの判断は人間に残すか。これはアーキテクチャ設計の問題であり、コードを書く速さとは別の能力だ。
2. AIの出力を評価する力。 RCAが正しいかどうか、ミティゲーションが適切かどうかを判断する。牛尾さんのチームではこれをAIがやっているが、「評価の定義」は人間がする。評価基準を設計できる人間が必要になる。
3. 思考を手放さない姿勢。 牛尾さんが「思考を手放さないAI活用術」という言葉を使っているのは意味深だ。AIに任せた結果を「なんとなく正しそう」で受け取り続けると、自分の判断能力が鈍る。AIを使いながら、自分の思考を維持し続けることが「本体の強さ」の核心なのだと思う。
まとめ：本体の強さとは何か
牛尾さんが語る「本体の強さ」という言葉が印象的だ。AIがあらゆる作業を支援してくれる時代に、それでも残る「人間側の強さ」とは何か。
この記事から読み取れる答えは、コードを速く書く力でも、最新ツールをいち早く使いこなす力でもない。「AIが正しく動けるシステムを設計する力」「AIの出力を適切に評価する力」「自分の思考を維持し続ける力」だ。
コーディングエージェントがWordと同じ扱いになった世界では、それを使えることはスタート地点にすぎない。その上で何ができるかが、エンジニアとしての本体になる。
日本の現場がそのフェーズに達するのが1年後か3年後かはわからない。ただ、最前線の動向を見ていれば、方向性だけは今から見えている。
