「AIを使えば開発が速くなる」という話は、もう珍しくありません。ただ、実際に発注する立場からすると、気になるのはそこではないはずです。速くなった分、品質はどうなるのか。誰がどこまで確認しているのか。自社の情報はAIに渡されるのか。
この記事では、AI駆動開発とは何かを整理したうえで、開発工程のどこにAIを使い、どこは人が担うのかを具体的に説明します。実際にAIを開発に取り入れている側からの内容です。
AI駆動開発とは、開発工程にAIを組み込む進め方のこと
AI駆動開発とは、要件定義から実装、テストに至る開発工程にAIを組み込み、人とAIで役割を分担しながら進める開発の進め方を指します。
誤解されやすいのですが、AIがすべてを書くわけではありません。実態は「人がやらなくてよい作業をAIに移す」ことに近く、その結果として人が設計や品質に時間を使えるようになる、という構造です。
従来の開発と何が違うのか
従来の受託開発では、仕様が決まってから実装に入り、実装量がそのまま工数と期間になっていました。AI駆動開発では、この「実装量=工数」という関係が崩れます。
| 従来の開発 | AI駆動開発 | |
|---|---|---|
| 定型的な実装 | 人が書く | AIが下書きし、人が確認する |
| テストケースの洗い出し | 人が列挙する | AIが列挙し、人が過不足を判断する |
| 仕様書・資料の整理 | 後回しになりがち | AIが整理する |
| 全体設計・アーキテクチャ | 人 | 人 |
| 品質の作り込み | 人 | 人 |
| 顧客への提案 | 人 | 人 |
右列の下3行が変わっていない点が重要です。判断が必要な部分は人が担い続けます。ここをAIに任せると品質が崩れます。
当社では、定型実装・コードの下書き・テストケースの洗い出し・仕様や資料の整理をAIに任せ、人は全体設計・品質の作り込み・提案に集中する体制をとっています。手数をAIが引き受けるぶん、少人数のチームでも、かつて大人数を要した規模とスピードで形にできます。
工程別に見た、AIの使いどころ
要件定義
ヒアリング内容の整理、論点の抜け漏れの洗い出しにAIを使えます。ただし要件を決めるのは人です。現場の業務フローや、なぜその課題が起きているのかを引き出す部分は、AIには置き換わりません。
設計・ドキュメント化
実務でとくに効くのがここです。仕様書が残っていない既存システムは珍しくありません。担当者が退職して中身がわからない、という状態です。
こうしたシステムに対して、コードを解析して仕様を整理する作業は、従来は非常に時間がかかりました。AIを使うことで、この調査を現実的な工数に収められる場面が増えています。当社でも、他社が構築したシステムの改修・保守引き継ぎに対応しており、仕様書がない場合でも解析から着手できます。
実装
定型的な処理やコードの下書きをAIが担います。ここで大事なのはレビュー体制です。AIが書いたコードをそのまま通す運用では、動くけれど保守できないコードが積み上がります。
当社では人が全体設計と品質の作り込みを担当し、AIの出力は必ず人が確認する前提で運用しています。
テスト・品質保証
テストケースの洗い出しはAIが得意な領域です。人が思いつかない条件を挙げてくることもあります。一方で「何をテストすべきか」の優先順位は人が決めます。網羅すればよいわけではなく、事業上のリスクが高いところを厚く見る判断が必要だからです。
開発スピードは実際どれだけ変わるのか
「AIで何倍速くなるのか」という質問をよく受けます。正直に言えば、工程によって差が大きく、一律の倍率では表せません。
効果が出やすいのは、定型的な実装、テストケースの洗い出し、資料の整理といった作業量が読める工程です。逆に、要件を引き出すヒアリングや、事業上の優先順位を決める場面では、ほとんど変わりません。
実感として近いのは「速くなる」より「少人数でできる規模が変わる」という表現です。当社では、AIが手数を引き受けるぶん、少人数のチームでも、かつて大人数を要した規模とスピードで形にできるようになりました。
そのため、費用も単純に比例して下がるわけではありません。当社の費用レンジは小規模200〜500万円、中規模500〜1,500万円、ラボ型は60〜120万円/人・月です。AIの活用はこの枠の中で「できる範囲を広げる」方向に効いています。
AI駆動開発を回すチーム体制
ツールを導入すれば回るものではありません。体制の作り方に、いくつか押さえる点があります。
レビューする人が必要になる
AIが生成する量が増えるほど、確認する側の負荷が上がります。書く人を減らしてレビューする人を置かない体制にすると、確認されないコードが積み上がります。当社では人が全体設計と品質の作り込みを担当し、AIの出力は必ず人が確認する前提で運用しています。
「AIに任せる範囲」を明文化する
人によって使い方がばらつくと、成果物の品質も揃いません。どの工程で使い、何は使わないかをチームで共有しておく必要があります。
ドキュメントを残しやすくなる
これは副次的ですが効果が大きい点です。従来「書く時間がないから残せない」ことが属人化の原因でしたが、下書きをAIが担えるなら、更新を継続できる可能性が上がります。設計書が残っていない既存システムの解析についても、既存システムの仕様調査をAIで進める方法で整理しています。
情報を守ったまま、AIを使う
発注側からもっとも懸念されるのがこの点です。「自社のコードや顧客データがAIに渡るのではないか」という不安は当然のものです。
当社では秘匿情報はAIに渡さない設計を徹底し、危険な操作はガードで未然に防いでいます。AIを使う開発でも、預かった情報は守ったまま進める、というのが前提です。
この点は発注前に必ず確認しておくべき項目です。「AIを活用しています」と説明する会社に対して、「何をAIに渡し、何を渡さない設計になっているか」を具体的に聞いてみると、実態がわかります。
ラボ型開発との相性がよい理由
AI駆動開発は、ラボ型開発(準委任契約)と組み合わせたときに効果が出やすい進め方です。
理由は単純で、AIを使うと試作から検証までの回転が速くなるためです。要件が固まりきっていない段階で「まず動くものを作って確かめる」ことが現実的になり、その進め方には、成果物を確定させてから始める請負契約より、一定期間の稼働を提供するラボ型のほうが噛み合います。
逆に、要件が確定していてゴールが明確な案件では、従来どおり請負契約が適しています。契約形態の違いについては受託開発とは?委託・請負との違いで整理しています。
導入を検討するときに見るべきこと
「AI駆動開発に対応しています」という言葉だけでは、実態は測れません。発注前に確認するとよい点を挙げます。
- AIに任せている工程はどこか(すべて、という回答は要注意)
- AIの出力を誰がどう確認しているか
- 秘匿情報をどう扱う設計になっているか
- その体制で実際に納品した実績があるか
開発会社の選び方全般については、システム開発会社の選び方で、相見積もりの取り方や見積書の読み方まで整理しています。
まとめ
AI駆動開発は「AIが開発してくれる」ものではなく、人がやらなくてよい作業をAIへ移し、人は設計と品質と提案に集中する進め方です。判断が必要な部分は人が担い続けます。
導入を検討する際は、速さより「何をAIに任せ、何を人が見ているか」を確認してください。ここが曖昧な体制では、速いけれど保守できない成果物になりかねません。
C-limber は2013年の設立から13年目、累計1,000件以上のプロジェクトに携わってきました。レンタルECパッケージ「EC Rent」を自社で開発・運営しており、つくる側だけでなく運営する側の視点から機能の優先順位を提案できます。ISMS(ISO/IEC 27001)認証、AWSセレクトティアサービスパートナーの認定を取得しています。
要件が固まっていない段階のご相談でも構いません。技術選定や概算見積もりは無料で承っていますので、Webシステム開発のページとあわせて、お問い合わせからお気軽にご連絡ください。