AI 駆動開発とは：企業が導入するときの進め方と失敗しない体制

「AI でシステムを作れるようになったらしい。うちでも使えないか」。経営者からこう言われて、開発の担当者がツールを調べ始める。最近、そんな相談がよく届きます。

Claude Code、GitHub Copilot、Cursor、Codex など、AI にコードを書かせるツールは急速に広がりました。けれども、ツールを契約して社員に配っただけで、開発が速くなったり、社内でシステムを作れるようになったりするわけではありません。

この記事では、次のことを順に書きます。

• AI 駆動開発とは何か
• よくある場面：ツールは配ったのに、開発が進まない
• 調査の数字で見る、AI 駆動開発の今
• ツールだけでは成果が出ない理由
• 導入の進め方（5つの段階）
• 失敗しないための体制（4つの役割）
• 導入前に確かめる10項目

AI 駆動開発とは：人は「決めて、確かめる」側に回る

「AI 駆動開発」は、日本でよく使われる言葉です。調べた範囲では、国や IPA（情報処理推進機構）による公的な定義は見つかりませんでした。業界の解説では、たとえば GitLab が「AI駆動開発とは」（2026年7月）で、生成 AI などを使い、要件定義から設計、実装、テスト、運用までの開発の流れを効率化する開発手法、と説明しています。

英語では、Google の DORA（ソフトウェア開発の調査チーム）が「AI-assisted software development」、Anthropic が Claude Code を「agentic coding」（AI が自分で作業を進める開発）の環境と呼ぶなど、言い方はさまざまです。AWS は「AI-Driven Development Life Cycle」（2025年7月）という進め方を公開しています。そこでは、AI が計画を立て、分からない点を人に質問し、人が承認してから作業に入る、大事な判断は人がする、という原則が示されています。

言葉は違っても、中身は共通しています。コードを書く作業の多くを AI に任せ、人は「何を作るか」「どんなルールで作るか」を決め、出来上がったものが正しいかを確かめる。人の仕事が、書くことから、決めることと確かめることへ移る開発です。

ツールの2つの型

AI の開発ツールは、大きく2つに分けると分かりやすくなります。

AI 駆動開発と言うとき、いま中心になっているのは後者です。エージェントは、ファイルを読み、コードを書き、コマンドを動かし、テストまで自分で進めます。任せられる範囲が広いぶん、何をさせてよいか、結果をどう確かめるかを、人が先に決めておく必要があります。

よくある場面：ツールは配ったのに、開発が進まない

導入の相談でよく聞くのは、次のような流れです。

社内でシステムを作れるようにしたいと考え、開発の担当者や詳しい社員に AI のツールを契約して配りました。最初の数週間は「画面がすぐできた」と盛り上がります。ところが、しばらくすると、次のような声が出てきます。

• 作ったものが、現場で使う人の業務と合っていない
• 直すたびに、別の所が壊れる
• 誰が何をどこまで AI に任せたのか、分からない
• 動いてはいるが、安全かどうかを判断できる人がいない
• 結局、速くなったのかどうか分からない

ツールの性能が足りないわけではありません。何を作るのか、どんなルールで作るのか、誰が確かめるのかが決まっていないまま、AI に任せていることが原因です。

調査の数字で見る、AI 駆動開発の今

使う人は、すでに多数派

開発者の調査では、AI の利用はすでに当たり前になっています。

• Stack Overflow の「Developer Survey 2025」（約4万9千人が回答）では、開発で AI のツールを使っている、または使う予定の人は84％で、前年の76％から増えました。
• Google の DORA の「2025 State of AI-assisted Software Development」（約5,000人の技術者が回答）では、回答者の90％が仕事で AI を使っていました。

国内の企業も同じ方向です。IPA の「DX動向2026」（2026年7月、国内1,799社）では、生成 AI を「導入している」企業が、2024年度の22.6％から2025年度は44.0％に増えました。生成 AI の使い道のうち「プログラムコードやシステム開発支援」は、情報通信業では76.3％にのぼります。

ただし、使い方の中身を見ると、まだ個人の範囲にとどまっています。同じ調査で、生成 AI の組織での使われ方は「個人で業務利用している」が63.3％と最も多く、「部署の業務プロセスに組み込まれている」は11.9％、「全社的なサービスに組み込まれている」は18.6％でした。IPA は、組織的・戦略的に活用している企業はまだ少ない、とまとめています。AI 駆動開発も同じで、個人が便利に使う段階から、会社として開発の流れに組み込む段階へ進めるかどうかが、これからの分かれ目です。

速くなる実験と、遅くなる実験

では、AI を使うと開発は速くなるのでしょうか。実験の結果は分かれています。

METR の実験で興味深いのは、本人たちの感覚です。開発者は始める前に「AI で24％速くなる」と予想し、終わったあとも「20％速くなった」と感じていました。実際の時間とは逆です。

METR は2026年2月に、続きの実験の途中経過を公表しています。新しい AI では速くなった兆しがあるとしつつ、「AI なしでは作業したくない」という人が参加しなくなるなど、測り方そのものに問題が出たため、この数字は信頼できる指標ではない、と結論づけています。

どの実験も、条件が限られています。課題が単純なら速くなりやすく、よく知っている大きなシステムなら、AI の出力を確かめて直す手間が上回ることもある。分かるのは、速くなるかどうかは状況しだいで、体感ではなく測らないと分からないということです。

「ほぼ正しい」が、いちばん手間になる

AI が書くものの質についても、注意が必要です。

• Stack Overflow の調査では、AI の出力の正確さを信頼していない人（46％）が、信頼している人（33％）を上回りました。不満の1位は「ほぼ正しいが、完全ではない AI の答え」で、66％が挙げています。
• DORA の2025年の調査では、AI の採用は開発の速さ（スループット）を高めた一方で、リリースの不安定さ（失敗や手戻り）は今も増やしている、とされています。
• ソフトウェアのセキュリティ企業 Veracode の調査（2025年7月）では、100以上の AI のモデルに80の課題を解かせたところ、45％でセキュリティ上の弱点を含むコードを書きました。

AI のコードは、一見すると整っていて、動きます。だからこそ、どこが間違っているかを見つけるのに手間がかかります。AI で作ったものを公開する前に確かめることは、バイブコーディングのデメリットとセキュリティで詳しく書いています。

ツールだけでは成果が出ない理由

AI は「増幅器」

DORA の2025年の報告書は、AI の役割を「増幅器」と表現しています。強い組織では強みを大きくし、うまくいっていない組織では、その機能不全も大きくする、という意味です。報告書は経営者に向けて、AI の導入はツールの問題ではなく、組織の仕組みの問題だ、とも書いています。

同じ報告書は、AI の効果を強める7つの能力を挙げています。候補の15項目の中から、AI と組み合わせたときに効果が大きくなることが確かめられたものです。

右の列は、報告書の内容を中小企業の場面に合わせて言い換えたものです。どれもツールを入れるだけでは手に入りません。

国内でも、課題は「人」と「ルール」

IPA の「DX動向2026」で、生成 AI を導入・活用するうえでの課題を見ると、1位は「専門人材が不足している」（50.1％）でした。「活用するためのルールや基準の作成が難しい」も39.7％あります。ツールはあっても、使いこなす人と、使い方のルールが足りていないのが、国内の企業の現状です。

伴走の現場で見る、2つのつまずき

クリーヴァが AI での開発を伴走する中でも、つまずきの多くは次の2つです。

1つ目は、指示があいまいなまま任せて、欲しいものと違うものができることです。「在庫を管理できる画面を作って」と頼むと、AI は足りない部分を自分で補って、それらしいものを作ります。動くので一見うまくいったように見えますが、現場の業務の流れや必要な項目と合わず、作り直しが続きます。

2つ目は、何を作るか（要件）や作り方のルール（設計）を決めないまま任せて、中身がつぎはぎになることです。画面は動いていても、権限のチェックが抜けていたり、同じ処理があちこちに散らばったりして、あとから直すのが難しくなります。

どちらも、AI の性能の問題ではありません。AI に渡す前に、人が決めるべきことが決まっていないことが原因です。何を作るかを決める進め方は、要件定義とは：開発会社に頼む前に、社内でまとめておくことにまとめています。

導入の進め方：5つの段階

ここからは、会社として AI 駆動開発を始めるときの進め方です。

1. 目的と、最初の題材を決める

まず、何のために AI 駆動開発を始めるのかを一文で書きます。「社内の業務システムを、自分たちで直せるようにする」「新しいサービスの試作を速くする」などです。

そのうえで、最初の題材を1つに絞ります。いきなり基幹のシステムを作り直すのではなく、使う人が少なく、止まっても業務が大きく困らない、小さな業務から始めるのが安全です。DORA が挙げる「小さな単位での作業」とも重なります。

2. ツールと契約を決める

会社で使うなら、個人向けではなく法人向けのプランを選びます。Claude Code も GitHub Copilot も、法人向けのプランでは、送ったコードや指示を AI の学習に使わないと公式に案内しています（2026年10月時点）。プランごとの違いや、会社でまとめて設定を配る方法は、Claude Code を会社で安全に使うで詳しく書いています。

3. ルールを決める

AI に任せる前に、次のことを決めて文書にします。

• AI に渡してよい情報と、渡してはいけない情報（顧客の個人情報、本番のパスワードなど）
• AI にさせてよい操作と、人の確認が必要な操作（本番のデータベースに触る、外部に送る、など）
• コードの置き場所と、変更の残し方（GitHub などで履歴を管理する）
• 誰が、何を確かめてから公開するか

Claude Code では、チームのルールを CLAUDE.md というファイルに書いて共有したり、権限の設定で AI ができる操作を決めたりできます。Anthropic のベストプラクティスも、AI が自分で結果を確かめられるようにテストを用意すること、調べる・計画する・実装するを分けて進めることを勧めています。

4. 小さく試して、測る

最初の題材で、実際に作ってみます。このとき、始める前に「何で効果を判断するか」を決めておきます。METR の実験が示したように、体感はあてになりません。

測るものは、難しくなくてかまいません。「依頼から使えるようになるまでの日数」「公開後に見つかった不具合の数」「作り直しになった回数」などです。AI を使う前の同じような作業と比べられると、判断しやすくなります。

数字の選び方に迷ったら、DORA が開発の成果を測るのに使っている5つの指標が参考になります。DORA は、どれだけ速く変更を届けられるか（スループット）と、届けた変更がどれだけうまくいくか（不安定さ）の2つに分けて測っています。

AI で速く作れるようになっても、失敗率や手戻りが増えていれば、全体としては良くなっていません。速さと失敗の両方を並べて見ることが大事です。DORA も、これらの数字は「何が起きているか」は示すが、「なぜ起きているか」までは説明しない、と注意しています。数字が悪くなったら、ルールや確かめ方のどこに原因があるかを、チームで振り返ってください。

5. 広げて、定着させる

最初の題材で、うまくいったことと、つまずいたことを書き出し、ルールを直します。そのうえで、次の題材や、使う人を少しずつ広げます。

人が入れ替わっても続くように、ルールと設計の資料、確かめ方を、個人の頭の中ではなく、文書として残しておくことが大事です。

失敗しない体制：4つの役割

AI 駆動開発で必要になる役割は、大きく4つです。

小さな会社では、1人が複数の役割を兼ねることになるでしょう。それでもかまいません。ただし、「指示を出す人」と「確かめる人」は、できるだけ分けてください。自分で頼んで自分で確かめると、思い込みに気づきにくいからです。

「確かめる人」がいないとき

4つの役割のうち、社内でいちばん用意しにくいのが「確かめる人」です。IPA の調査で「専門人材の不足」が課題の1位だったように、AI のコードを読んで判断できるエンジニアがいない会社は少なくありません。

その場合でも、できることはあります。テストを用意して AI 自身に確かめさせる、別の AI に見直させる、公開前の確認項目を決めておく、などです。ただし、権限の設計が業務に合っているか、あとで直しやすい作りになっているかといった判断は、経験のある人が見たほうが確実です。この部分だけ、外部のエンジニアの力を借りる方法もあります。

導入前に確かめる10項目

会社で AI 駆動開発を始める前に、次の10項目を確かめてください。「いいえ」や「分からない」が付いた項目が、最初に手を付けるべき所です。

公開前に確かめる項目（9）は、バイブコーディングのデメリットとセキュリティの「公開前に確かめる10項目」が使えます。

自分たちでは判断しにくいこと

10項目は、社内でも確かめられるように作りました。ただし、次のことは、項目を埋めるだけでは判断がつきにくい部分です。

• 設計が、あとから直しやすい作りになっているか：画面が動いていても、機能を足すたびに壊れる作りになっていることがあります。
• 権限の設計が、業務に合っているか：誰が何を見られるか、変えられるかは、業務と照らし合わせて決める必要があります。
• AI のコードに、見えにくい弱点がないか：Veracode の調査のように、整って見えるコードにも弱点が入ることがあります。
• 費用が想定を超えない作りか：外部のサービスの使い方によっては、利用が増えたときに請求が大きく膨らみます。

こうした所は、経験のあるエンジニアが一度見ておくと、あとで大きな手戻りになるのを防げます。

次の一手：3つの進め方

AI 駆動開発を始めるときの進め方は、大きく3つです。会社の状況に合わせて選んでください。

どれが正解ということはありません。開発そのものを任せたいなら、開発会社に頼むのも合理的な選択です。社内で作り、直し続けられるようになりたいなら、2つ目の進め方が近道になります。

クリーヴァの「せんせいAI」は、2つ目の進め方を支えるサービスです。自社のシステムを題材に、エンジニアが設計、コードの確認、テスト、公開の準備まで伴走し、契約が終わったあとも社内に人とルールが残るように進めます。

よくある質問

AI 駆動開発は、エンジニアがいない会社でもできますか

小さな業務の道具なら、作ること自体はできます。ただし、AI が作ったものが正しく安全かを確かめる役は必要です。社内に経験のある人がいない場合は、その部分だけ外部の力を借りる方法を考えてください。非エンジニアが業務で使うときの範囲は、Claude Code を非エンジニアが業務で使うで書いています。

どのツールを選べばよいですか

ツールの差より、ルールと確かめる体制の差のほうが、結果に大きく効きます。会社で使うなら、法人向けのプランがあり、管理者がまとめて設定や権限を管理できるかを確かめて選んでください。

AI を使えば、開発の費用は必ず下がりますか

必ず下がるとは言えません。METR の実験のように、条件によってはかえって時間がかかることもあります。費用が下がるかどうかは、最初の題材で測って確かめるのが確実です。

社員の研修では、何を教えればよいですか

ツールの使い方を教えるだけでは足りません。DORA の2025年の報告書は、研修は AI を使うよう勧めることより、AI に正しく指示を出し、AI が作ったものを見極めて確かめる力を育てることに重点を置くべきだ、としています。この記事の4つの役割でいえば、「指示を出す人」と「確かめる人」の力を育てることです。実際の自社の業務を題材にして、AI の出力のどこを確かめるかを、経験のある人と一緒に練習するのが近道です。

社内のデータを AI に渡しても大丈夫ですか

法人向けのプランでは、送ったデータを学習に使わないと案内されています。それでも、何を渡してよいかは会社として決めておく必要があります。具体的な設定は、Claude Code を会社で安全に使うを参考にしてください。

まとめ

AI 駆動開発は、AI にコードを書かせ、人は「何を作るか」を決めて「正しいか」を確かめる開発の進め方です。開発者の多くが AI を使うようになった一方で、速くなるかどうかは状況しだいで、AI のコードには「ほぼ正しい」ゆえの手間や弱点もあります。

DORA の言うとおり、AI は組織の強みも弱みも大きくする増幅器です。成果を分けるのは、ツールではなく、目的と題材を絞ること、ルールを決めること、確かめる人を置くこと、そして効果を測ることです。まずは10項目のうち、「いいえ」が付いた所から手を付けてみてください。