AIコーディングで現場が疲弊するのはツールのせいではない KDDIアジャイル開発センターに聞く、AIコーディングの誤解と「本当の生産性」：「正しく取り組めない組織は数カ月で時代に取り残される」

AIエージェントの普及により、コードの生成コストは極限まで低下した。しかし現場では、中身を理解せぬままAIにコードを実装させる「バイブコーディング」の課題も顕在化している。開発現場と開発者はAIコーディングとどう向き合うべきなのか。KDDIアジャイル開発センターでAIコーディングを実践する面々との対談を通じて、AIコーディングを使いこなしながら「本当の生産性」をつかむための方策を探る。

[齋藤公二, 編集：石川俊明，＠IT]

　特集第1回では、生成AI（人工知能）導入による局所的な効率化が、かえってレビュー負荷の増大や現場の疲弊を招くという「AIパラドックス」の問題を整理した。AIがもたらす単なる「時短（マイナスをゼロにする効率化）」と、ビジネス価値を生み出す「本当の生産性（ゼロをプラスにする活動）」を混同したままでは、AIは組織の未成熟な部分を増幅させるだけではないのか――。

　そこで本特集第2回は、開発現場において生成AI活用を実践し、AIエージェントの構築も実践しているKDDIアジャイル開発センター（以下、KAG）の御田 稔（みのるん）氏、小林賢哉氏、服部好晃氏と対談。AIを導入したのに開発現場が疲弊するAIパラドックスの真因と、AIコーディングと向き合い「本当の生産性」を獲得するための方策を探った（取材は2026年2月下旬に実施／服部氏のコメントは御田氏によるコメントの代読を基に構成している）。

――本日はよろしくお願いします。あらためてKAGにおけるAIコーディングの取り組み状況を教えてください。

御田氏　KAGでは、2023年初頭から「GitHub Copilot」の社内導入を進めたり、現在のコーディングエージェントのもとになった「Cursor」や「Cline」の先行導入を進めたりしてきました。現在はCTO室やプラットフォームエンジニアリングチームと連携し、GitHub Copilotエージェントや「Claude Code」といった最新ツールを必要に応じてスピーディーに利用できる仕組みを整備しています。実装だけでなく、要件整理、仕様設計、テスト作成まで幅広くAIを活用しています。

小林氏　特にGitHub Copilotは導入が早かったこともあり、私のスクラムチームではパートナー企業も含めてほぼ全員が利用しています。AIの使い方についてはSlackでノウハウをチームに共有したり、エンジニア、デザイナー、スクラムマスターがAIをどう使っているかを共有する勉強会「KAG AI Week」を定期的に開催したりして、全社的な知識の底上げを図っています。

「AIコーディングの波に乗れない組織は、数カ月で時代から取り残される」

──開発現場におけるAIコーディングの実践状況について、もう少し詳しく教えていただけますか。

御田氏　サービス開発からお客さまとのミーティングの際のスライド作成やエヴァンジェリストとしての業務のほとんどでClaude Codeを活用しています。書籍執筆のための構成案作成、経費精算すらもAIで仕組み化しています。

KDDIアジャイル開発センター 開発5部 / テックエバンジェリスト 御田 稔氏

　といってもAIに計算、入力させるのではなく、社内ルールやマニュアルの場所をAIに伝え、「領収書を置くだけで経費精算用の入力データが作成されるスクリプト」自体をAIに作らせました。結果として、作業時間を7割短縮できました。新しいタスクが発生するたびに「これってAIで自動化できないか？」と考えるマインドセットが定着しています。

　この取材に当たって作成したスライドもClaudeに取材で話したい内容を説明し、整理してもらった内容をまとめてもらいました。私自身がスライドを作成するのとそんなに違和感のないスライドを作ってくれます。エージェントに任せることで、裏側で処理を任せることができます。

　いまこうして取材を受けている間にもエージェントが裏で業務を進めてくれています。コツとしては、1つのAIに全てをやらせるのではなく、用途を分けることです。例えばスライド作成で追加の調査が必要な場合、親エージェントからサブエージェントにWeb検索を指示し、要点だけを返させます。こうすることで不要な情報による「コンテキストの汚染」を防ぐといった、マルチエージェント的な使い方をしています。Claude Codeの進化は著しく、AIコーディングに限らず、さまざまな依頼に対してある程度の品質は確保されつつあります。

KDDIアジャイル開発センター 開発6部 / スクラムマスター 小林賢哉氏

小林氏　私の部署では、デザイナーさんが作ったデザインデータからAIを使ってコーディングすることで、新規構築のスピードを向上させたりしています。また、プロジェクト運用ツールにMCP（Model Context Protocol）でアクセスして仕様書からAIコーディングする取り組みも進めています。お客さまから頂く仕様書は「Microsoft Excel」が多いのですが、そのままAIに読み込ませることは難しいので整える必要があります。従来は手作業で整えていましたが、これもAIを活用して効率化することが可能になりつつあります。とはいえ、お客さまから頂くデータですから、データ保護の観点も踏まえて取り扱っていくことも重要です。

――AIコーディングに限らず日常の作業でもAIを活用されているということですね。SNS（ソーシャルネットワーキングサービス）では「AIで爆速で開発できた」という声があふれる一方、現場からは「検証やレビューが追い付かず疲弊している」という声も聞こえてきます。AIコーディングを巡る現状については、実践者である皆さんは率直にどのようにお考えですか。

KDDIアジャイル開発センター 開発9部 / エンジニア 服部好晃氏

服部氏　AI任せにすると、大量のコードが生成され、ディレクトリ構造も独断で作られてしまい、気付けば迷路のようになるという問題があります。そのため、その分野や技術に精通していないと、AIが生成した仕様やコードが正しいかどうか判断できなくなります。また、一応動くコードが出てくるため、「よほどのことでない限り指摘しづらい」という心理的なバイアスも働きやすくなります。

　こうした課題に対しては「仕様駆動開発（SDD）」が有効です。ただ、仕様駆動開発ツール（「cc-sdd」など）を導入して経験したのは、「開発は速くなるものの、設計や運用のコストが増える」ということです。AIが生成した仕様に抜けがあると、間違った実装が出てきて手戻りが発生します。マージ後の修正も、仕様書の更新からギャップ確認、設計の整合性チェックと、少し直すだけなのに負担は大きくなります。

御田氏　服部さんが指摘するように、現場が疲弊する「バイブコーディングのわな」は存在します。AIに任せきりにして、出てきたコードの中身がよく分からないまま「このまま進めてよいですか？」という問いに対し、「はい」を連打して自動承認すると、AIは利用者が知らない技術やライブラリを大量に使ってコードを完成させます。一応動いてはいるものの、機能追加していくうちに動かなくなって回収不可能になったり、セキュリティの脆弱（ぜいじゃく）性が混入していても、利用者は気付けなくなったりするリスクがあります。

　ただ、大前提として「Claude Opus 4.5」や「ChatGPT Codex 5.2」が出た2026年に入ってから、AIのコーディング能力は一般的なITエンジニアを優に超えるレベルまで飛躍的に向上しました。つまり、「現場の疲弊」はもはや「AIツールの品質」が原因ではないのです。

　現在の課題は「セキュリティ上の理由などでAIツールを導入できない現場」や「AIコーディングを使いこなせないエンジニア」側にあります。今後数カ月以内に、AIコーディングを正しく使えない現場やエンジニアは時代から取り残されると、私自身強い危機感を覚えています。

――「組織としてAIコーディングを正しく受け入れなければ先がない」ということですか。

御田氏　はい。すでに一般消費者や企業向けにサービスを開発している企業の多くは、AIコーディングを当たり前のように部署全体、会社全体で使っています。そうした企業がどんどん先に進んでいき、そうでない企業は取り残されるでしょう。優秀なツールがあるのにそれを活用できない人材がいれば、それがボトルネックになるということです。

小林氏　現場のレビュー負荷が上がって疲弊してしまうのは、従来の開発手法の中で「コーディング」にだけAIを当てはめて使っているからです。われわれ含めAIを取り入れている企業はすでに設計、レビューといった開発プロセス全体で見直し始めています。従来のように個々のプロセスで部分的にAIを活用するのではなく、AIを使うことを前提とした開発プロセスに変革する取り組みへシフトさせることが重要です。

「何を作るか」を見失いかねない

――AIコーディングによりコードが素早く生み出される点は大きなメリットだと思いますが、AIコーディングを「時短（効率化）の手段」として捉えてしまうと、「どのような課題を解決するために何を作るか」という本質的な部分が置き去りになるリスクがあるのではないでしょうか。

服部氏　AIコーディングには、何を作るか不明確なまま進むリスクがあると思います。AIが大量のコードを生成するので「何かを作っている感」が出てしまい、本当に必要なものを作っているのか立ち止まれなくなります。目先のタスクをAIで高速にこなすだけでは、タスクが増えるだけで開発現場は疲弊してしまいかねません。

御田氏　DX（デジタルトランスフォーメーション）の文脈でも、昨今のAI案件でもありがちな失敗パターンですね。お客さまからもよく伺う失敗談としてトップから「社内でDXやれ、AIをやれ」と言われ、担当者が手探りで「取りあえず社内資料検索チャットbotを作ろう」と進めてしまうケースがあります。成果物を見ると必ずしもAIが必要ないものだったことに気付く。AIコーディングについても同様のことが起こる可能性はあります。

　ただ、AIコーディングのメリットは、机上の空論を積み重ねるのではなく、サクッと動くプロトタイプの開発を短縮できることにあります。私自身、新しいお客さまとの商談では、要件を伺いながら手元のPCでこっそりAIにデモアプリを作らせて、商談の終盤に「欲しいのはこんな感じですか？」と実物を見せることをやっています。1〜2時間あれば商用デプロイできるクオリティーのデモが完成します。

　「何かやれ」と言われた際に、取りあえず動くプロトタイプを作って見せれば「こんなこともできる？」とさらなる要望を引き出したり議論したりできる。結果として最終的に作り上げるプロダクトの品質も高まります。AIで削減できた時間は、こうした「価値の探索」に使うべきです。

小林氏　KAGで実践しているアジャイル開発やスクラムの目的はお客さまの要件や要望をしっかりと実現させることにあります。AIコーディングによってスピードは上がりますが、要件や要望の精度があいまいだと、正しいものが作れなくなるリスクがあります。いくらコードの生成速度が上がっても、それがビジネス価値やUX（ユーザー体験）の向上に貢献していなければ「本当の生産性」とはいえません。

――では、AIコーディングを活用することで生まれる新たな時間やリソースを、開発現場はどう振り向けるべきなのでしょうか。

服部氏　まず「届けるべき価値は何か」を明確にすることです。バックログがあるなら、それが「なぜ必要か（Who/What/Why）」を言語化し、その深掘りに時間を使うべきです。受け入れ条件（AC：Acceptance Criteria）を満たす実装をAIで生成することで、高速に無価値なコードを量産する事態を防げます。

御田氏　服部さんのコメントに付け加えると「テスト」という分野は極めてAIと相性が良いです。MCPを用いてブラウザ操作をAIに任せ、エラーが出たら自動でリトライや修正までやらせることで、人間よりも高い品質でテストを完了させることができます。

　2026年に入り、AIの進化がもたらした大きな変化は、効率化と品質がトレードオフではなくなった点です。これまでのAI活用は「効率は上がるけれど品質が落ちる」ことが多くありました。しかし今は、最新のツールを使い、仕様駆動の考え方にのっとって仕事を進めれば、手作業の品質を100％保ったままAIで効率化できます。もっとも、人間は時間ができればできるほど次の仕事をあてがわれますから、人間自身が適切に「ハーネス（制御）」をはめながら仕事を進めることが大切になってきます。

暗黙知の喪失と、設計不備が露呈するリスク

──従来、ITエンジニアがコーディングの過程で「要件定義や設計の不備や抜け漏れ」を暗黙的に補完できた部分もあったと考えます。AIコーディングを導入することでそうした不備や抜け漏れの部分が致命的な欠陥として即座に露呈し始めるリスクもあるのではないでしょうか。

服部氏　おっしゃる通りです。従来はエンジニアがコーディング過程で暗黙的に設計を補完していましたが、AIはそれをしません。仕様に書いてあることをそのまま実装するので、書かれていないことは抜け落ちます。またエンジニア教育でも課題と感じる部分でもあります。AIネイティブ世代はエラーメッセージをAIに貼り付けて自動修正する手法に慣れています。泥臭いデバッグを経験していないため、コーディングの過程で得られた「なぜこう動くのか」という理解が省略されるリスクがあります。

御田氏　ただ、そのリスクはAIの問題ではなく「使い方の問題」だと考えます。承認が面倒で手放しで承認すれば当然リスクは増えます。私が大切にしているのは、Claude Codeのような「同期・対話型」のツールを使い、1つずつコードを確認しながら進めることです。対話の中で「ここの設計はおかしいのでは」「セキュリティ的に問題があるのでは」と気が付けるプロセスを、人間が意図的に挟み込むことも重要です。

小林氏　確かに設計段階で課題が発生するのは事実ですが、その課題解消にもAIが使えます。チーム開発において、レビュワーがAIを使って気になるところを分析し、リスクを減らす方向に動いています。

──AIが進化しているからこそ「リスクを減らす」という観点で、設計やレビューのプロセスもAIを前提に考え直すべき状況にあるということですね。

服部氏　人間によるコードレビューだけで品質を確保するのは限界に来ています。実装コードが大量かつ高速に生成されるためです。コードレビューに費やしていたエネルギーを、設計や要件定義の「壁打ち」の段階にも振り向けるべきです。AIの役割は「0→1の立ち上げ」であり、人間が「1→あるべき姿への磨き上げ」を担う分担が効果的だと考えます。

大規模組織で実践するプロセス変革と「攻め」のガバナンス

──AIコーディングから最大限の恩恵を得るには、御田さんのようなAIに詳しい人、つまり個人のスキル頼みではなく、組織としてのルール作りやプロセスの整備も不可欠だと考えます。KAGではどう取り組まれていますか。

御田氏　仕事のプロセスごとAIで仕組み化することも重要です。例えば、新しいプロジェクトが来るたびにリポジトリを作り、過去の議事録や資料を含めて「スキル」（SKILL.md）として登録します。これを社内のGitHubで共有しておけば、同僚に「取りあえずリポジトリをクローンしてAIにスキルのことを聞いて」と伝えるだけで、引き継ぎやナレッジ共有が劇的に楽になります。

スキルのイメージ（御田氏のGitHubリポジトリ〈minorun365/my-claude-code-settings〉より）

小林氏　大規模組織に適用するポイントは2つあると思っています。1つ目は、メンバーが使いやすい仕組みを作っていくこと。2つ目は、その仕組みを「お客さまに受け入れ可能な状態」にしていくことです。現在参加しているプロジェクトで取り組んでいるのは、AIを使ってどの部分の品質が向上したかを数値でしっかり顧客に示すことです。顧客と合意形成していくプロセスが非常に重要です。御田さんが挙げた「スキル化」の取り組みは、1つ目で挙げた現場のメンバーが使いやすい仕組みに直結するので、非常に参考になりますね。

服部氏　うまくいくチームとそうでないチームの違いは「言語化」に尽きます。うまくいくチームは仕様を言語化しており、AIに対して細かく明確な指示を出せています。言語化が不十分なままAIに丸投げすると、あいまいな指示をAIが勝手に推測してしまい、手戻りと疲弊のループに入ってしまいます。

御田氏　とはいえ、「言語化」ってなかなか容易なことではないと思います。そこで私がお勧めしたいのが「音声入力」のフル活用です。10〜15分ほど、要望や不安な点、仕様のイメージをひたすらAIにしゃべり倒す。雑然とした情報でも、音声なら圧倒的な情報量を伝えられるため、AIがいい感じに整理し、あいまいな指示も的確に推測、補完してくれます。これが言語化の課題を解消するアプローチになります。

──AIガバナンスや、生成物に対する責任の所在についてはどうお考えですか。

御田氏　責任は間違いなく人間が持ちます。一人一人の人間がリーダーになって、大量のAIという「部下」をマネジメントするイメージです。KAGでの組織体制としては、CTO室とプラットフォームエンジニアリング部が協力してルール・ガバナンス面を整備しています。ポイントは守りに入り過ぎないことです。リスクを適切に評価した上で、申請から2〜3日で素早く承認する「攻めのガバナンス」を敷いてくれているのが大きいです。

小林氏　現場としても、「どうせ認められないからシャドーAIでやっちゃおう」となる必要がなく、安心して公認でAIを活用できる体制が大きな推進力になっています。ただ、オフィシャルに使えるからといって、無責任な使い方が許されるわけではありません。

　推進する立場でメンバーに強く意識付けしているのは、「何か理由を問われたときに『これはAIが書いたから』という回答（言い訳）は絶対にしない」ということです。あくまで「自分の成果物」を作るためにAIを利用しているのだと、堂々と言える状況で活用していくよう伝えています。

──「AIのせいにしない」のは、まさに使うITエンジニア側、主体性の問題ですね。

小林氏　おっしゃる通りです。先ほど服部さんが挙げた「AIが生成したコードの問題を指摘しづらい」という心理的バイアスを取り除くためにも、こうした個人の心掛けや責任を意識することが非常に重要になります。とはいえ、AIに慣れ過ぎると無意識に頼ってしまう部分も出てくるため、こればかりは泥臭く「言い続けるしかない」のが正直なところです。ただ精神論だけで終わらせないよう、レビュー時の観点として盛り込むなどの工夫も並行して取り組んでいる状況です。

御田氏　厳しい言い方になりますが、労働力という観点で「ただ手や目を動かすだけの人手が欲しい」という部分は、今後AIで代替可能になると考えます。大量のコードが出てきた際、レビューができず、責任も果たせず、ただ「はい」を連打して承認するだけなら、そこに人間がいる意味はありません。

　今後は、AIをうまく使いこなし、責任を持って必要なレビューと意思決定がちゃんとできる「強い人材」と「そうでない人材」で完全に二極化し、開発現場から求められない人材になりかねないリスクがあると考えます。

2026年以降のビジネスは「ビッグテックが来るまでの半年をどう戦うか」になる？

──AIを前提とした開発プロセスが当たり前になると、アプリケーションやサービスを通じて収益を向上させる、ブランド力を向上させるという現代のビジネスルールそのものも変化しそうです。

御田氏　今はまだ、私たちのようにAIコーディングを使いこなせている一部の層だけが、この驚異的な生産性を享受できている状態です。しかし、半年から1年も経てば、AnthropicやMicrosoftなどのビッグテックが「AIを活用できる便利な一般向けアプリ」をどんどん公開して市場をかっさらっていくリスクがあります。

　そうした状況下で、ITベンダーや先進的な企業が生き残るにはどうすべきか。非エンジニアには、まだClaude CodeやVisual Studio Codeを使いこなすための心理的・スキル的な壁があります。だからこそ、ビッグテックが製品化しきれていない領域を探索し、直近半年〜1年のリードタイムの間に、AIの複雑な裏側を隠蔽（いんぺい）し、アプリケーションや個別ソリューションの形にして「AIで効率化できる」ことを顧客にどう届けられるかが勝負になります。

　そして、ビッグテックが同種の機能を製品化してきたら、すぐにピボット（撤退・方向転換）して、また手を出せていない次の新しい領域を狙って開発する。今後はそうやって、どんどん攻めの姿勢でピボットしながら価値を出し続けられる企業だけが生き残るのだと個人的に考えています。

AIの波に乗るか、飲まれるか　組織に求められるのは「攻め」の判断

――最後に、AIコーディングが普及する中で組織はどう変わっていくべきか、ITエンジニアは何を学ぶべきか、メッセージをお願いします。

小林氏　自分のやりたい技術や作りたいものだけを見るのではなく、市場の動向や顧客ニーズ、ビジネス要件を俯瞰（ふかん）して「今何を作るべきか」を判断できる「メタ認知」のスキルが、今後ますます重要になってくると考えています。

服部氏　「AIを使って速くコードを書けること」はもはや差別化要素にはなりません。差がつくのは、AIをどうコントロールするかの「設計力」です。また人材教育という観点では、エラーが出たらすぐにAIに投げさせるのではなく、ログを読み解き仮説を立てるような「泥臭い経験」を意図的に積ませる必要があると感じています。

御田氏　現時点でのAIにはまだ得意でない領域があります。フロントエンド、バックエンド、インフラの橋渡しや全体を統括するアーキテクチャ、ビジネス要件を統括できる領域です。人間にはプログラマーというよりITアーキテクト的なスキルが求められてきます。そのためには、いきなりAIに丸投げするのではなく、方針を持ってAIに指示を出し、理由を壁打ちしながら進めるというプロセスをなくさないことです。

　ちなみに私自身、「ブログやスライドまでAIに作らせるなんてダメだ」という「アンチAI派」だったんです。しかし、AI活用を推進する立場として、自分自身が本気で業務プロセスを変えないと説得力がないと思い、大きなカンファレンス登壇の際、あえて「スライドを全てAIに作らせて品質を確保する」という挑戦をしました。結果として、最初は手で作るより時間がかかりました。しかし、一度その仕組みを作ってしまえば、次の登壇からはその資料をベースにエッセンスを抽出してスライドを作ることが爆速でできるようになったのです。私自身もコンフォートゾーンを踏み出して取り組んだ事例ですね。

　今すぐAIの波に乗らない組織は、本当に置いていかれると思っています。古い社内ルールが壁になるなら、セキュリティ部門にAIに詳しい若手を配置するなど、組織体制から攻めの姿勢で変革を進めるべきです。組織も、そして一人一人のエンジニアも、自らコンフォートゾーンを飛び出し、AIを触ってみて体感し、トレンド起点ではなく目的起点で業務プロセスを見つめ直し、AI前提の新たな開発手法へと舵を切ってほしいと思います。

――本日はありがとうございました。

取材を終えて

　「AIコーディングで開発が爆速化した」――そんな華々しい声の裏で、多くの現場が「レビューの限界」や「仕様のすれ違い」といった課題に直面している。今回のKAGへの取材を通じて見えてきたのは、このパラドックスを生み出している原因が、AIツールそのものの品質ではなく「業務プロセスや組織、ITエンジニア一人一人の未成熟さ」に移り変わりつつあるということだ。

　AIコーディングに取り組み、「本当の生産性」を獲得するためには、これまで優先順位が低かった「業務プロセス・ワークフローの見直し」「組織として未成熟だった部分への対応」「エンジニアの教育」にも企業が本気で向き合う必要がある。小林氏が語った「今あるプロセスにAIを取り込むのではなく、AIがあることを前提にプロセスを構築していく必要がある」という言葉は、まさにこの本質を突いている。

　複数のAIを並行して動かし、コーディングを進めさせるスタイルも普及しつつあるが、エンタープライズでAIコーディングを活用するには、最終的に開発者自身に責任が問われるということも肝に銘じる必要があるだろう。

　こうした視座を開発組織、そして開発者自身が持つことができるようになれば、「ビッグテックが参入してくるまでの半年間で収益化し、すぐにピボットさせる」という御田氏の言葉が象徴するように、これまでにないビジネススピードと俊敏さを獲得することも可能になる。生成AIというトレンドにただ乗っかるのではなく、目的起点で開発プロセス全体をAI前提に再構築できた組織だけが、AI前提の時代に「本当の生産性」を獲得できるようになる。

　本特集の次回は、こうしたAI前提の組織体制やプロセス変革が求められる中で、個人のエンジニアはどのようにキャリアを築き、自らの市場価値を高めていくべきか。生き残るエンジニアの役割に焦点を当てる。

特集：その「AIコーディング」は本当に必要か？

---

今、開発現場は閉塞感に満ちている。IT需要が急増している一方で、現場を担えるエンジニアが不足。若手はいるが、設計・レビュー・育成を担える中堅が薄いのも深刻だ。打開策として「AIコーディング」がもてはやされているが、導入した現場では、かえって工数が増大してしまった例が相次いでいる。一般に生成AI活用には、プロセス、人の役割、文化の変革が必要とされ、それは開発現場でも例外ではない。だが、こうしたセオリーが案外理解されていないのではないか。理解していても実践に移せない原因は何か。それは、ゼロをプラスにする、ビジネス価値を創出する「本当の生産性」を考えていないからではないか。本特集では、読者調査や取材を通じ、開発現場の現実、テクノロジー本来の意義、エンジニアの本分を見極め、「本当の生産性」の具体像を解説する。

関連情報