😸
「AI駆動開発」が効く業務、効かない業務——生成AIを開発に組み込むための前提とは？
生成AIの活用が開発現場でも広がりを見せています。
「AI駆動開発」「Copilotによる生産性向上」など、さまざまなキーワードが話題になりますが、ツールを導入しただけで開発が変わるわけではありません。
本記事では、そもそも「AI駆動開発」とは何かを定義した上で、AIが“効く業務”と“効かない業務”の違い、そして現場で直面する導入の壁や乗り越えるための視点についてまとめていきます。
AI駆動開発とは何か？——ただの自動補助とは違う
「AI駆動開発」とは、単にGitHub CopilotやChatGPTを使ってコードを書くことを指すものではありません。 本稿では、以下の3点を満たす状態を「AI駆動開発」と定義します。
再現性のある開発プロセスにAIが組み込まれている 例：設計レビュー、テスト生成、コード補完などにAIが定常的に関与している状態
AIの出力が、そのまま開発フローや業務ツールに連携されている 例：AIによる要約やコードがNotionやJira、GitHub Issueにシームレスに流れる仕組みがある
活用が属人化せず、チーム・組織のナレッジとして蓄積・共有されている 例：プロンプトテンプレートの整備や社内RAGの活用環境が用意されている
このように、AIを単なる便利な補助ツールとしてではなく、業務プロセスの中に再現性を持って組み込むことで、初めて「駆動」の状態に近づいていきます。
AIが効く開発業務とは？
生成AIが効果を発揮しやすい開発業務には、いくつかの共通点があります。
構造が明確でルール化されている作業
テストコードの自動生成
API仕様書の作成補助
コードフォーマットやスニペットのテンプレ生成
こうした業務は判断基準が明確であり、AIにとっても扱いやすい領域です。
情報整理や要約が求められる場面
ミーティング議事録の要約とタスク抽出
プルリクエストのレビュー補助
開発ログからの障害パターン抽出
非構造化された情報を咀嚼する役割として、AIが力を発揮します。
ワークフローとの接続が前提の設計
ChatGPTの出力をSlackやNotionに共有し、そのままJiraに連携
GitHub上で生成AIが提案した変更が直接ブランチに反映される
こうした設計があると、AIの出力がそのまま次のアクションになるため、業務との統合がスムーズになります。
AIが“効かない”開発業務とは？
AIは万能ではありません。次のような業務では、導入しても効果が出にくい、もしくは定着しにくいケースがあります。
まず、アウトプットの正解があいまいな業務です。 たとえばゼロからの要件定義や、プロダクト戦略の検討といった領域は、組織の文脈や思想によって正解が変わります。 こうした抽象度の高い判断は、現時点の生成AIにとっては不得手な領域です。
また、開発フローが明文化されておらず属人化しているチームでは、そもそもAIに“何を渡せばよいのか”が分かりません。 ドキュメントが残っていなかったり、情報が個人の頭の中にあるような場合は、AI活用のスタートラインに立てないのです。
さらに、普段からレビューや指示が曖昧で、空気や行間を読む文化が強いチームも要注意です。 AIとのやり取りは基本的に明示的なプロンプトベースになるため、日常的に言語化・構造化する習慣がない場合、活用は進みません。
このような“AIが効かない”業務やチーム文化においては、 まず業務フローの整理やナレッジの形式知化から始めることが、AI導入の第一歩になると言えるでしょう。
現場で起こる「形骸化」の壁
AIツールを導入しても「実際には使われていない」というケースは多く見られます。
弊社の支援先企業でも、AI活用がイノベーター層（最初の2.5%）やアーリーアダプター層（13.5%）に限られ、全体の16%程度で利用が止まっているという事例がいくつかあります。 これはイノベーター理論で語られる“普及の壁”とも一致しますが、この16%を超えていかなければ、AIは現場に根付いたとは言えません。
この壁を乗り越えるには、以下のような設計と支援が求められます。
ジュニア層エンジニアに向けたオンボーディング設計 （AIへの指示が苦手な人も多いため、プロンプト設計の教育機会が必要です）
活用状況の可視化と目標の明確化 （どれくらい使っているのか、どんな改善ができるかを見える化する）
組織的な使い方のガイドライン整備 （個人ではなくチームで使う前提の運用設計）
ある組織では、ジュニア層のエンジニアから「Devinが勝手にデプロイするから怖くて使えない」という声がありました。 これは、AIに適切な指示を出す経験が不足しているために起きている問題です。 逆に、普段からオフショア開発などで「1から10まで指示を出す」ことに慣れているプロジェクトマネージャーは、AI活用の適応もスムーズです。
また、シニア層のエンジニアは「自分で書いたほうが早い」と感じてしまいがちですが、怠惰こそ美徳というエンジニアの本質に正しくアプローチできれば、彼らの活用も進むはずです。
導入を拒む声と変革への意識
一部の事業会社では、AIの導入に対して強い抵抗感を示す例も見られます。 特にセキュリティリスクを理由に、AIを頭ごなしに拒否する姿勢は根強くあります。
しかし、こうした企業においては、自らの雇用を守るために変化を拒んでいるのではないかと周囲から指摘されることもあります。 現代のように先行きが読めない環境において、守り一辺倒では生き残ることは難しいのではないでしょうか。
将来的に優秀なエンジニアがさらに不足することが確実視されている今、AIを使わない選択肢はもはや存在しないとも言えます。
おわりに：開発組織に求められるのは設計力
AI駆動開発を実現するうえで必要なのは、ツールの選定ではなく、組織設計です。
業務フローの言語化と明文化
ツール・データの接続性を前提としたアーキテクチャ設計
属人知のナレッジ化と共有体制づくり
これらの基盤を整えることができる開発組織は、AIの進化に依存せず、自らその力を引き出すことができます。
生成AIは、あくまでも道具です。
ですが、その道具をうまく使えるかどうかは、組織の成熟度と変化を受け入れる力にかかっているのではないでしょうか。
久松 剛
IT開発組織づくりの水先案内人、採用・定着・活躍・評価・再構築を伴走型支援／博士（慶應SFC、IT）／合同会社エンジニアリングマネージメント社長兼レンタルEM／サポーターズ エバンジェリスト／アカリク顧問／STARMINE顧問／ウィルオブテック顧問／R.N.宇宙思考士／ Amazonアソシエイト参加／香川出身
Read next
Loading recommendations...