「AI駆動開発」と「AIでコードを書く」は別物です

要約: AI駆動開発とは工程の設計です。各工程について、どこでAIが下書きを作り、氏名の分かる誰が承認するのかを事前に定めます。「AIでコードを書く」のは、エンジニア個人が選ぶ道具の話です。この二つは同じ名前で売られていますが、納期を動かすのは前者だけです。検証のしかたに手を入れるのが前者だけだからです。

目次

• 「AIを使っています」だけでは、納期について何も分からない理由
• AI駆動開発とは何か
• 承認ポイント5点のフレームワーク
• 導入の6ステップ
• 進歩に見えてしまう5つの誤り
• 導入すべきでない場合
• よくある質問

「AIを使っています」だけでは、納期について何も分からない理由

開発会社を5社選び、AI駆動開発とは何を指すのかを尋ねてみてください。同じ名札を付けた、互いに無関係な二種類の答えが返ってきます。一方は自社のエンジニアが使っている道具の説明で、もう一方は自社の工程の組み方の説明です。両者の差が表に出るのは契約後、提示された開発スケジュールが、AI導入前のスケジュールとほとんど変わらないと分かったときです。

道具の答えでは足りない理由には、いまや実測された根拠があります。

METRは、経験豊富なオープンソース開発者16名を対象に、彼らが何年も関わってきたリポジトリでの実タスク246件を使い、ランダム化比較試験を行いました。開始前、開発者はAIによって24%速くなると予測していました。終了後の自己評価でも、20%速くなったと答えています。しかし実測では、AIツールを使えた場合のほうが19%遅いという結果でした（METR、2025年7月）。METR自身が、これは熟知したコードベースで作業する熟練開発者という特定の条件下の結果であり、AIが開発者一般の役に立たないことを示すものではないと明言しています。

その但し書きを額面どおり受け取ってもなお、残る発見が一つあります。認識のずれの向きです。「自分たちは速くなっている」という感覚は測定ではありません。この試験では、その感覚が約39ポイント逆方向を指していました。

業界規模の統計は、同じ緊張関係を反対側から映しています。DORAの2025年レポートでは、技術職の90%が業務でAIを使っていること、そしてAI活用度が高いほど、ソフトウェアデリバリのスループットと不安定性の両方が増加することが示されました。ボトルネックとして名指しされているのはコードレビューの所要時間です。AIが生成した変更を精査するレビュアーの認知負荷が、明確に重くなるためです（DORA、2025年）。

二つの結果を並べて読むと、発注側のチェックリストではまず捕まえられないことが見えてきます。生成する能力と、検証する能力は別物だということです。前者だけを買って後者を動かさなければ、日程は縮みません。コストが結合工程へ移り、そこで「手戻り」という名前で現れるだけです。

本記事では、AIをどの工程に置くのか、誰が承認するのか、そしてどの工程では効かないのかを整理します。これは日本企業向けのシステム開発サービスで当社が実際に運用している考え方です。

AI駆動開発とは何か

AI駆動開発とは、すべての工程について、どこでAIが下書きを作り、氏名の分かるどの担当者が結果を承認するのかを事前に宣言しておく工程設計を指します。「AIでコードを書く」のは、エンジニア個人が自分の書き方について選ぶ道具の話です。

この違いは程度の差ではありません。変えている対象が違い、決める人が違い、失敗する理由も違います。

市販の補完ツールをすべて導入しながら、工程は一切変えないことは可能です。実際そうなっている現場は珍しくありません。それ自体は正当な選択です。ただ、それは日程を動かす類のものではないので、そのように値付けされるべきでもありません。

承認ポイント5点のフレームワーク

プロジェクト開始前に、当社が埋める表です。各行が、AIが何を下書きし、誰が判断し、後に何が証跡として残るのかを示します。3列目が空の行は、工程ではなく意向です。

5行すべてを貫く規則が一つあります。どの情報をどのAIサービスに渡してよいかは、お客様のデータに関する文書化された決定であり、各エンジニアが自席で単独に下す判断ではありません。

導入の6ステップ

ステップ1. 何かを買う前に、現在の制約を測る。 レビューで既に作業が滞留しているなら、生成を速くすれば待ち行列が伸びます。DORAはレビューの所要時間を一般的なボトルネックとして挙げているので、まずそれが自社の制約かどうかを確認します。

ステップ2. 承認の線を、工程ごとに書き出す。 各工程について一文です。AIがXを下書きし、役割Yの担当者が承認する。ここを飛ばしたチームは、障害が起きたときに、誰もそれを合意していなかったことに気づきます。

ステップ3. データの規則を決める。 どの区分のお客様データが、どのサービスに渡ってよいか。誰が承認し、記録はどこにあるか。最初のエンジニアが必要とする前に決めます。後からではありません。

ステップ4. 検証できる工程から始める。 テストの生成、慣れないコードベースの調査、移行作業の下ごしらえ、ドキュメントを最新に保つこと。目標が定まっていて結果を機械的に確認できるため、下書きが誤っていても安く捕まえられます。

ステップ5. 生成能力より先に、検証能力を上げる。 レビュアーを増やす、プルリクエストを小さくする、全コミットでテストを走らせる。地味な工程ですが、1から4が短い日程に結実するのか、大きな結合費用に化けるのかは、ここで決まります。

ステップ6. 自己申告ではなく、デリバリの実績で測る。 サイクルタイム、変更失敗率、手戻り量。理由はMETRの試験です。体感速度と実測速度が、正反対を向くことがあります。

実際の案件で分かったこと

実写のラベル画像から識別番号を読む、CPU専用の多言語OCRサービスを作りました。主エンジンがベトナム語の声調記号を丸ごと落とすことが分かりました。Sản phẩm Việt Nam が Sn phm Vit Nam として返ってくる状態です。劣化ではなく、消失でした。

これを解いた判断は4つあり、そのいずれもコードを書く判断ではありませんでした。

主エンジンをファインチューニングしませんでした。 全言語が同じ認識用の重みを共有するため、ベトナム語のために再学習すると、英語と日本語で既に検証済みの精度が危険にさらされます。代わりにベトナム語専用のエンジンを別に足し、動いている経路には触れていません。

副エンジンは既定で無効にしました。 主エンジンのおよそ5倍の容量を要するため、ベトナム語のリクエストが実際に来たときにのみ読み込みます。

実写入力に対しては、使用可能と認めませんでした。 精度を測ったのはレンダリングされた文字であり、カメラ出力ではありません。実写で検証できるまで、実写に対しては無効のままにしています。良いほうの数字を引用するのではなく、その事実を書きます。

識別番号の抽出は、学習済みモデルではなくルールベースを選びました。 誤検出を調べる必要が出たとき、抽出された値がどの規則から出たのかを常に遡れるようにするためです。

この作業ではAIを全工程で使っています。しかし上の4つの判断は、どれ一つとしてAIが下したものではありません。生成速度をどれだけ上げても、代わりにはなりませんでした。測定方法の全体はOCRのケーススタディにまとめています。

進歩に見えてしまう5つの誤り

1. レビュー能力を据え置いたまま、生成能力だけを買う。 結果: スループットと不安定性が同時に上がります。DORAが観測したとおりの形です。回避策: 最初に動かすべき予算項目はレビュアーの時間だと考えることです。

2. AIの出力を誰が承認するのかを、一度も書かない。 結果: 最初の障害が起きるまでは責任が明確で、その後は不明確になります。回避策: 工程ごとに一文、チームが実際に見る場所に置きます。

3. 固まっていない要件にAIを当てる。 結果: 間違ったものをより早く作り、手戻りが早く、大きく現れます。回避策: 仕様が動かなくなるまで、AIは調査と下書きに留めます。

4. データの規則を各エンジニアの判断に委ねる。 結果: 誰も承認していないサービスにお客様のデータが渡り、それがセキュリティ点検の場で発覚します。事前ではありません。回避策: 一度だけ決めた、文書化された一覧を持つことです。

5. 導入の効果を、チームの体感速度で測る。 結果: 上に報告される数字が、まさにMETRの試験で逆転しうると示された種類の数字になります。回避策: サイクルタイムと変更失敗率で報告します。

導入すべきでない場合

変えたい工程で、仕様がまだ動いている。 調査工程はいつ始めても構いません。ただし、固まっていない要件の下流にあるものは待つべきです。誤った標的に速度を足しても、出てくるのは成果物ではなく手戻りです。

レビューに人を割けない。 レビューが既に飽和しているなら、この取り組みは、いま壊れている場所に圧力を足すだけです。先に制約を外してください。

データが環境の外に出せず、自社環境で動かす選択肢が承認されていない。 APPIやGDPRの適用を受ける組織では、規則が道具に先行します。ローカルで動くモデルが答えになる場合もあります。それは構成の問題であり、その一例をCPU専用OCRの記事にまとめています。

エンジニア1名、短期のプロトタイプ。 工程を回す手間が利点を上回ります。補完ツールだけ使い、フレームワークは省いてください。

よくある質問

AI駆動開発とは、AIコード補完に別の名前を付けただけのものですか。 違います。補完ツールが変えるのは、個人がコードを書く速度です。AI駆動開発が変えるのは、どの工程が自動で下書きを出し、どこで人の承認が必要かという設計です。補完ツールを入れても工程を変えない例は多く、その場合ほとんど何も変わりません。

導入すれば納期は短くなりますか。 検証側の能力が一緒に動く場合に限ります。DORAは、AI活用度の高さがスループットと不安定性を同時に押し上げ、レビューの所要時間が制約になることを示しています。先に変えるのは検証できる工程、つまりテスト、ドキュメント、コードベースの調査です。

自社のエンジニアはAIで明らかに速くなったと言っています。それは根拠になりませんか。 兆候ではありますが、測定ではありません。METRの試験では、開発者が20%速くなったと自己評価した一方、実測は19%遅いという結果でした。導入前後のサイクルタイムと変更失敗率を確認してください。

AIを入れる前に、要件を固めておく必要がありますか。 要件に依存する工程についてはその通りです。既存システムの調査のように依存しない工程は、時期を問わず始められます。

AIが生成したコードが不具合を起こした場合、責任は誰にありますか。 従来と同じ人にあります。AIの出力を下書きとして扱い、氏名の分かる担当者が承認する形にしておけば、責任の線は動きません。ある変更を誰が承認したのか答えられないのであれば、それはAIが作った問題ではなく、AIが可視化した工程の穴です。

発注先が工程を持っているのか、道具しか持っていないのかは、どう見分けますか。 3つの質問です。AIの出力を誰がどの基準で承認しているか。あえてAIを使わない工程はどこか。どのお客様データがどのサービスに渡ってよく、それを誰が決めたか。工程を持つ会社は役割とチェックポイントで答え、道具しかない会社はエンジニアが確認していますと答えます。

まとめ

• 生成の能力と検証の能力は、別々の予算です。前者だけを動かすと、コストは結合工程へ移ります。
• 着手前に工程ごとに書き出した承認の線が、工程と道具一式を分ける境目になります。
• 自己申告の速度は測定ではありません。サイクルタイム、変更失敗率、手戻り量で報告してください。

開発工程のどこにAIを入れ、どこには入れないかを検討されている場合は、無料相談をお申し込みください。現在の進め方に対して上記5つの承認ポイントを照らし合わせ、結果をお返しします。