AIで爆速開発、のはずが─開発現場でハマった「落とし穴」と「突破口」 | AI駆動開発カンファレンス Summer 2026 講演レポート

「AIを使えば開発は爆速になる」──そう期待して現場に導入したものの、実際には生成されたコードが読めずレビューに追われ、"それっぽい嘘"（ハルシネーション）に振り回され、「爆速」という期待だけが独り歩きする。そんな経験をされた方は少なくないはずです。

本記事は、AI駆動開発カンファレンス Summer 2026 におけるJTPの講演「AIで爆速開発、のはずが・・・ 開発現場でハマった落とし穴と突破口」をもとに再編集したものです。第1部（個人・技術編）では開発者が実装現場でハマった落とし穴とその突破口を、第2部（チーム・組織編）ではAIを組織に広げるときに直面する落とし穴と対処の「型」を解説します。「これからAI駆動開発をチームに取り入れたい」という方が、つまずきポイントを事前に把握し、先回りして手を打つための指針をご紹介します。

生成AIの登場によって、コードを書くスピードそのものは確かに上がりました。しかし現場に導入してみると、期待とは違う現実が待っていました。

• 生成されたコードが読めず、レビューに追われる
• “それっぽい嘘”（ハルシネーション）に振り回される
• 「爆速」の期待だけが独り歩きし、現場との温度差が生まれる

つまり、AIでコードを書けるようになっても、それだけでは開発は速くなりませんでした。むしろ、レビューやすり合わせといった「人が最終的に品質を担保する工程」に負荷が集中する──これが、爆速開発の裏側で起きていた現実です。本講演は、この落とし穴に実際にハマり、どう突破したのかを、開発者個人の視点と、チーム・組織の視点の両面から共有するものです。

AI駆動開発の落とし穴は、特定の工程に限った話ではありません。「企画・導入判断」「設計・実装」「テスト・レビュー」「運用・定着」という開発ライフサイクル全体に、それぞれ固有のつまずきポイントが存在します。講演では、これらを大きく8つに整理しました。

本記事では、これを二部構成で掘り下げます。第1部は開発者個人が実装・レビューの現場でハマった技術的な落とし穴①〜④、第2部はAIを組織・チームに広げるときに立ちはだかる導入・運用の落とし穴⑤〜⑧です。上図はライフサイクル全体を俯瞰した整理で、以降の各セクションでは、実際の現場のエピソードに沿ってこの8つを掘り下げます。

第1部の「個人・技術編」では、バックエンド開発・レビューを兼任するエンジニアの小山が登壇しました。「規約をAIに渡せば、実装もレビューも楽になるはず」という期待からスタートしましたが、現実はそう単純ではありませんでした。

AIによってコードの生成量が増えると、当然プルリクエスト（PR）の数も増えます。すると次に詰まるのは「レビュー」でした。実際の数字がそれを物語っています。

• 直近5日間のフロントエンドPR：12件
• うち自分がレビューした件数：8件（1人あたり平均 1.6件/日）
• 社内のレビューアー：たった2名

OpenAIの報告でも、エージェント主導の開発では、生成量が増えるほどボトルネックは「人間による品質保証」へ移るとされています。「実装が速くなった」その先で、少人数のレビューアーに負荷が集中する。AI活用の効果を出すには、この「人間による品質保証」の工程そのものを設計し直す必要がありました。

最初にぶつかったのは、AIが現場のルールを正しく守ってくれないことでした。コーディング規約もディレクトリ設計も、READMEや既存コードには明記されていました。それでもAIは毎回正しく推測できるとは限らず、同じ指摘を何度も繰り返すことになりました。つまり、「人間向けに正しいドキュメント」は、そのままでは「AIが実行可能なルール」にはならない、と言えます。

コーディング規約・ディレクトリ設計・型定義ルール・Git運用ルールを、AIが実行時に必ず参照する形で明文化しました。人間が読んで理解する文書と、AIが実行できる指示書は、別ものとして設計する必要があったのです。

次にハマったのは、複雑な構成（オーケストレーター）をAIに作らせようとしたときです。これは、1つの司令塔となるAIが複数の担当AIに仕事を振り分ける仕組みで、近年注目される「ハーネスエンジニアリング」でも用いられる考え方です。この構成を自然言語で説明して構築を依頼したところ、何度説明しても組み上がらず、最後にはAI自身が「この構成は実現できません」と回答してきました。

言葉で説明するのをやめ、「動く実例」を渡すことにしました。過去にAIの機能検証のために作っておいた、実際に動く参照実装（お手本）をコピーして渡すと、AIは自身も気づいていなかった仕事の割り振り方やルールの作り方を認識し、構築に成功しました。長い説明よりも、「実際に動くお手本」のほうが正確に伝わるようです。

さらにこの経験には、もう一つの学びがありました。AIは、自分が使えるツールで何ができるかを、必ずしも正確に把握できているわけではありません。だからこそ、AIに任せる側の人間も「そのAIで何ができるのか」を理解し、進化し続けるAIの動向を追い続ける必要があります。AIに使われるのではなく、AIを使う側に立つ──そのための環境構築と適切な指示が欠かせません。

①と②の落とし穴への対処を踏まえ、現場ではこれらを統合した「3層」構造を設計しました。上流工程の成果物・README・既存コードといったインプットを起点に、次の3層で構成されます。

• コンテキスト層：　規約・AIへの指示書（steering）で「現場の前提」をAIに渡す
• 実行層：　役割ごとの担当AI（サブエージェント）に、目的別に仕事を任せる
• 制御層：　自動チェック（lint / test / pre-push）で、最後は機械的に守る

ポイントは、AIに自由に書かせてから直すのではなく、「役割を分け、権限を絞り、ゲートで守る」環境を先に用意しておくこと。これにより、AIの生成物が野放しに広がって手戻りが増える、という悪循環を防ぎます。

ボトルネックだったレビューには、役割を分離したAIエージェントのパイプラインを組みました。

• it-reader：　差分の取得のみを行う、読み取り専用の安全な入口
• code-reviewer：　観点リスト（skill）に沿ってレビューを実行し、指摘する。必要に応じて並列でテストエージェントも起動し、ブラックボックス／ホワイトボックステストを行う
• pr-orchestrator：　ここまでの結果を受け取り、まとめて統合報告する
• 人間：　整理された報告を読み、指摘の採否を決める最終判断だけを担う

役割ごとに分離し、それぞれの権限を最小化する。自動チェックに通ったものだけが人間に届くため、レビューアーは「差分を探す時間」から解放され、判断だけに集中できるようになりました。ただし、画面動作やUI/UXについては、現時点ではAIで満足のいく精度に達していないため、レビュアーが一通り操作して手動で確認しています。

この仕組みによるレビュー時間の変化は、次のとおりです。

• 1件目のレビュー：　3時間（レビュー経験ゼロからの観点学習と、AIレビュー方針の設計を同時に含む）
• 型が確立した後：　30分〜1時間（同程度の項目数のレビューで比較）

この差は、単なる時短以上の意味を持ちます。仮に1件3時間のままだったとすると、担当した8件を単純計算で約24時間──1日8時間労働なら、5営業日の稼働の半分以上をレビューだけに費やす計算になり、開発業務が回りません。もちろんこれは単純計算であり、経験を積めばAIなしでも効率化できる部分はありますが、立ち上げを含めてここまで短縮できた意味は小さくありません。

ただし、この数字だけで「品質を保った効率化」と言い切ることは、まだできません。速くなったことと、見るべき観点を漏らさず押さえられていることは、別の問題だからです。

レビューをAIに任せるほど、「AIがレビューした」ことと「観点を網羅した」ことは別だという問題が浮かび上がります。講演では、レビュー観点を「自動で押さえられているもの」と「まだ人の目に頼っているもの」に分けて整理しました。

• 押さえられている（自動で確認できる）：　規約準拠は指示書（steering）で自動確認し、CI通過は lint / format / test / build で担保できる
• 押さえられていない（人の目頼み）：　バグ検出・可読性・保守性は手順化できておらず、AIレビューと人の最終判断で防いでいる。セキュリティも、深さに確信が持てない

このうち明確に不足しているのがセキュリティで、リリース前には別途、セキュリティに特化した追加調査が必要です。また、パフォーマンス（現在は単体テストフェーズのため）や、要件整合性・UI/UX・ログ運用は今回のスコープ外とし、設計書側で対応しています（これらは Excel 形式の設計書に記載され、AIエージェントが参照できる形になっていないためでもあります）。

大切なのは、「足りていない場所を、言える状態にしておく」こと。AIレビューは万能ではなく、どこまでカバーできていて、どこが人間の追加対応を要するのかを明示できてはじめて、安心して使えます。

もう一つの課題は、せっかく作った仕組みが「自分専用」に閉じていたことです。

• 渡せるもの＝skillファイル：　レビュー観点をまとめた「AIへの手順書」。コピーすれば、同じ手順は誰でも実行できる
• 渡せないもの＝判断力：　「何を指摘すべきか」の基準を作った試行錯誤。この経験は、ファイルにはならない

成果物（skill）は共有できても、それを使いこなす判断力は自動では育ちません。チームへ展開しても、案件理解度やAI活用スキルによって成果に差が出るはず──この仮説の検証は、これからの課題です。

AIによって、開発者に求められるスキルの重心は「実装力」から「判断・設計・レビュー」へ移っていきます。具体的には、次の3点です。

1. 技術への理解
   採用する技術・ライブラリの妥当性を、自分で判断できる
   　
2. 作成物への理解
   AIより深く案件と既存コードを理解し、「ここは違う」と言える
   　
3. AIへの指示・設計
   指示とハーネス（AIが働く枠組み）の設計力が、そのまま成果物の品質を決める

個人・技術編の学びを、最後に3つに整理します。

1. AIで何ができるのかを把握し、適切に指示する
2. 役割と権限を分け、最後は必ず人間が確認する仕組みを作る
3. 手順書は共有できても、判断力や経験まで、そのまま共有できるわけではない

だからこそ、AIを活用する仕組みを整えることと、それを使う人のスキルを育てることは、どちらか一方ではなく「両輪」として進める必要があります。AIが安全に働ける環境をつくり、人がAIの出力を正しく判断できる力を身につける──この両方が揃って初めて、AI駆動開発は組織の中で継続的に機能します。
すべてを一から書く必要はなくなるかもしれません。しかし、AIが作ったものを理解し、良し悪しを判断できなければならない。これはレビューだけでなく、実装や設計、そしてこれからの組織づくりにも共通する、これからの開発者に求められる原則です。

参考記事

第2部「チーム・組織編」担当するのは、AI駆動開発エバンジェリストの梨本です。個人での成功をチーム・組織へ広げる段階では、技術とは別の、導入・運用ならではの落とし穴が待っています。ここでは代表的な4つを取り上げます。

「AIを入れたなら、もう10倍速いんだよね？」というマネージャーの期待に対し、現場は「……まだレビューに溺れています」というのが実情、というギャップです。このズレが生まれるのは、マネージャーが記事やSNSで流れる「生産性が10倍になった」という話を見ているのに対し、現場が見ているのは実際に上がってくるPRやコミットの数だからです。押さえておくべきは、AIは開発"全体"を速くしたのではなく"一部"を速くしただけで、そのしわ寄せがレビューに集中している、という事実です。この期待と現実のズレを放置すると、それがそのまま現場への圧力になってしまう危険性があります。まず取り組むべきは、経営・マネジメントとの期待値のすり合わせです。

現場の「速くなった気がする」という実感だけでは、稟議も投資も通りません。経営に見せる共通の物差しとして有効なのが、開発生産性の国際指標である DORA metrics です。

• デプロイ頻度
• 変更リードタイム
• 変更障害率
• 復旧時間（MTTR）

重要なのは、AI活用を広げる前に「何で測るか」を決めておくこと。導入前後（Before / After）の数字が残っているだけで、説得力はまったく違ってきます。

ツールを配った後、現場では「使う人だけが、速い」という状況が起きがちです。具体的には次の3つです。

• 二極化：　エースだけが爆速になり、差は開き続ける
• 属人化：　ノウハウが個人の中に閉じてしまう
• 幽霊ライセンス：　配ったのに使われず、眠ったままになる

ここで押さえておきたいのは、AIはスキルを平準化するツールではなく、むしろ既存の技術力の差を広げるツールだった、という実感です。だからこそ、一部のエースの成功をチーム全体の成果へと広げていく視点が欠かせません。

導入を止めてしまう最大の要因は、明確なリスクそのものよりも「なんとなく、怖い」という漠然とした不安であることが少なくありません。

• 学習利用：　入力したコードは学習に使われないか？
• ライセンス：　OSSライセンスの汚染は大丈夫か？
• 責任の所在：　AIが生成したコードの責任は誰にあるのか？

これらの不安を曖昧なままにしておくと、組織の判断は結局「全面禁止」へと落ち着いてしまいます。禁止ではなく、安全に使える道を先に敷いておくことが求められます。

第2部の4つの落とし穴に対して、組織で効かせるための5つの「型」を提示します。

1. スモールスタート
   全員一斉ではなく、まず1チームで小さく検証。勝ちパターンを持って段階的に展開する。
   　
2. KPI設計
   「体感」ではなく指標で語る。DORAなどの物差しを、広げる前に決める。
   　
3. 教育・オンボード
   ツールを配るのではなく、「使い方の型」ごと渡して立ち上げる。
   　
4. ナレッジ共有
   プロンプト・ルール・失敗談を、個人ではなくチームの資産にする文化をつくる。
   　
5. ガバナンス設計
   禁止ではなく、「安全に使える道」を先に敷いておく。
   　

最初から完璧を目指す必要はありません。①から⑤を小さく回しながら、自分たちのチームに合ったやり方へと育てていくことが、組織へのAI定着の近道です。

本講演では、個人・技術の落とし穴（第1部）と、チーム・組織の落とし穴（第2部）の両面から、AI駆動開発でつまずきやすいポイントと、その突破口を具体的に見てきました。共通して言えるのは、AIの導入そのものが目的ではなく、人が「価値の判断」に集中できるようにプロセスを設計し直すことが本質だということです。最後に、明日からすぐに試せる3つのアクションを紹介します。

1. ルールファイルを1枚書く──AIが毎回読む指示書（steering）を、まず1つ用意する
2. 測る指標を1つ決める──広げる前に、効果を測る物差し（KPI）を1つ決めておく
3. ハマった話を共有する──失敗談を個人に閉じず、チームの資産にする

小さな一歩から始め、仕組みの整備と個人のスキル育成を「両輪」で回していく。それが、「優秀な個人ががんばって回すチーム」から「組織として再現性高く、速く、品質高く回るチーム」への転換につながります。

梨本 大輔（Daisuke Nashimoto）｜AI駆動開発エバンジェリスト

新卒入社して自社AIプロダクトのエンジニアとして従事した後、製造業界のアプリケーション・モダナイゼーション業務をリード。現在はSDVプラットフォーム開発基盤構築プロジェクトの推進を行い、さまざまなAIツールを検証しながら、チーム内のAI活用を積極的に推進している。

小山 颯太（Sota Koyama）｜AI駆動開発スペシャリスト

新卒2年目。1年目はガバメントクラウド案件でバックエンド開発を担当。2年目からはレビューアー兼開発者として、開発するだけでなくプロジェクトの品質も支えるエンジニアとして活躍中。現在はバックエンドの開発・レビュー、フロントエンドのレビューを兼任し、実装から品質向上までを幅広く担当している。

AI駆動開発ソリューション「daimon」は、AI活用の導入から現場への定着まで、お客様の開発組織に寄り添い伴走することを重視したサービスです。

次の3つのメニューを軸に、実践的かつ柔軟に支援します。

• AI-Driven Development（開発支援）
  AI駆動開発によるクラウドネイティブアプリケーション開発、マイグレーション＆モダナイゼーション支援
  　
• AI-Driven Support（導入・改革支援）
  AI開発ツールの導入支援、開発組織へのAI活用の浸透・定着化支援
  　
• AI-Driven Optimization（最適化支援）
  AI活用によるリバースエンジニアリング支援、保守開発と自動化支援

単なるツール導入ではなく、「どこにAIを使うのか」「誰がどこまで責任を持つか」「どの指標を見て運用するか」といったルール設計と現場定着までトータルでサポートし、お客様ごとに最適なAI駆動開発を設計し、課題解決まで伴走します。

詳細は下記のサイトをご覧ください。