ここがツラいよAI駆動開発

この記事は NTT ドコモソリューションズ AdventCalendar 2025 24 日目 の記事です。

はじめに

初めまして！NTT ドコモソリューションズの山本です
ここ 1~2 ヶ月は、AI に駆動されるマリオネットな日々を送っています。

AI 駆動開発があまりにバズりすぎている昨今、逆張りしたくなるのが人情というもの...
というわけで、AI 駆動開発のむしろ「ここがツラいよ！」なポイントを開発者目線で吐露したポエムになります！

どうぞ〜

ここがツラいよ AI 駆動開発

実際にチームで 1~2 ヶ月 AI 駆動開発を回してみて、色々ツラいところが見えてきました

• レビューの形骸化
• コンテキストマネジメントが予想以上に難しい
• 開発者間での情報共有の難しさ
• ソフトウェアの「時間軸」と AI の相性の悪さ
• 周りの期待値高すぎ問題
• etc...

レビューの形骸化

• レビュー対象物多過ぎてやる気がおきない
• テストもコードも動くし、何より AI が自信満々なので、レビューも問題なさそうに見えてしまう
• 「AI 駆動で早く実装したい」 が「AI 駆動で早く実装しなければいけない」 にすり替わっている

などの理由で 雑なコード・雑なレビューが蔓延しました。

従来の開発でも巨大プルリクは煙たがられがちですが、AIの出力スピードが早すぎるあまり、常に巨大プルリクを見せられている感覚になります。多少レビューが雑になる気持ちもわかります...。

AI のコンテキストマネジメントが予想以上に難しい

コンテキストマネジメント用にドキュメントやルールファイルなどを事前整備したものの、

• 与えるコンテキストが少なく、AI のアドリブ・過学習が頻発し想定外のソースが生まれる
• 与えるコンテキストが余分で、AI が詳細を読み飛ばし想定外のソースが生まれる
• コンテキストが複雑で、AI がソースコード間の依存関係を追跡できない

と、色んなパターンで苦戦することになりました。

そもそも AI の入出力関係がブラックボックスであり、どのような入力が望ましいのかを定量的に評価することが難しいので、コンテキストマネジメントの改善効率が悪くなりがちなのもツラいポイントです。

開発者間での情報共有の難しさ

AI がどんどんソースを修正してくるので、他の開発者との変更共有のコストが高まり、

1. 細かく同期を取ろうとモブプロを試みるも、プログラミング担当は AI であり、従来のモブプロとの違いに困惑
2. 逆に最小限の同期で進めようとするも、その分 PR レビューが肥大化し、先述の形骸化につながる

の 2 パターンで対応に迷走することになりました。

共有方法を模索するよりも、インターフェース契約を重視し、「いかに開発者間の依存を弱め、共有の必要性を減らすか」にフォーカスした方が筋が良かったと感じます。

ソフトウェアの「時間軸」と AI の相性の悪さ

ソフトウェアエンジニアリングとは時間で積分したプログ
ラミングである¹

と言われるように、ソフトウェアにおいて時間の概念は非常に重要です。過去〜現在〜未来という時間軸に対してトレードオフを管理・最適化するのが、ソフトウェアエンジニアリングの最重要責務の一つでしょう。

しかしながら、基盤 AI モデルの多くは時間軸をそこまで意識していないように見えます。例えばソフトウェア系の代表ベンチマークである SWE-bench では、

• 複数ファイルにまたがる依存関係の解析
• バグ原因の発見と修正案の提示
• 提案した修正でテストがパスするか検証

といったタスクを取り扱いますが、見ての通り時間という概念はほぼ絡んできません。この手のベンチマークに最適化されているからといって、「将来に渡って最適な設計」ができるとは限らないのです。

実際我々のチームでも「現要件に過学習しており拡張性皆無」や、逆に「立ち上げ段階なのに過度な汎用化」といった、時間軸に対するトレードオフをガン無視したソースが生成されることになりました。

周りの期待値高すぎ問題

とにかく「AI 駆動開発」という単語/手法が一人歩きしている状態かと思います。「AI がよしなにやってくれるんでしょ？」的な認識の人もまだまだ見かけます。

我々のチームは周囲の期待を気にせずに淡々と進められていますが、期待値コントロールに苦慮しているチームもちらほら見かけます。

余談：直近の取り組み

開発者自身のスキル強化

身も蓋もないですが、やってて一番重要だと思うのはこれです。

DORA レポート でも指摘されているように、所詮AI は増幅器でしかありません。優秀なエンジニアが使えば爆速で進捗を生みますが、基礎体力のないエンジニアが使えば負債蓄積を高速化してしまうだけの諸刃の剣です。

また、先述の通り AI は「時間軸」が苦手です。故にソフトウェアライフサイクル全体に対するトレードオフの管理・最適化という観点でも、我々自身がスキルを磨かねばなりません。

CI の充実

「手動レビューが重いなら自動チェックしとけばいいじゃない」ということで、CI と pre-commit をちゃんと整備するようにしました。

• 静的解析: リント/フォーマット/型チェック等
• テスト: UT/IT
• セキュリティ: SAST/SCA 等

定量的なチェックをできる限り CI や pre-commit に分離することで、狙い通り人間が、設計や実装の本質的なレビューに集中できるようになりました。

AI の特性として、デッドコードやデッドライブラリを放置しがちなので、CI でその辺りを検知するのもいいかもしれません。

おわりに

成功は分からないけど失敗なら分かる、ということでしくじり先生として共有してみました。引き続き解決策を模索しながら、AI駆動開発を進めていければと思います。

ハッピー AI 駆動ライフ！

---

記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。

1. Titus Winters、Tom Manshreck、Hyrum Wright　編、竹辺 靖昭　監訳、久富木 隆一　訳「Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス」オライリー・ジャパン、2021年11月、p.3 ↩