開発会社から「弊社では生成AIを活用して開発しています」と言われた。速くて安くなるなら歓迎だけれど、本当にそうなのか、何か気をつけることはないのか。そんな疑問を持った方に向けた記事です。
結論から書きます。AIで作業が速くなるのは事実ですが、その分が値引きとして返ってくるとは限りません。そして品質と権利については、発注側が確認しておかないと後で困る箇所があります。この記事では、システム開発のAI活用で実際に何が変わるのかを整理したうえで、見積もりと契約の段階で確認しておく点を説明します。
この記事のポイント
- 速くなるのは実装が中心で、要件定義とテストはあまり減らない
- 削減分が値引きになるかは会社の方針次第。聞かないと分からない
- AIが書いたコードの著作権は、まだ判例が積み上がっていない領域
- 確認するのは道具ではなく、レビュー体制と契約の書き方
目次
システム開発のAI活用で実際に変わること
まず、AIを使うと開発のどこが変わるのかを整理します。ここを把握しておかないと、提案の良し悪しを判断できません。
効果が出るのは実装工程が中心
生成AIが効くのは、書き方の決まっている作業です。コードを書く、テストコードを作る、設計書のたたき台を作る。この種の作業は明確に速くなります。
一方で、あまり変わらない工程もあります。工程ごとの傾向は次のとおりです。
| 工程 | AIの効き方 | 理由 |
|---|---|---|
| 要件定義 | ほとんど変わらない | 決めるのは発注側。業務の事情はAIが知らない |
| 設計 | 少し速くなる | たたき台は作れるが、判断は人がする |
| 実装 | 大きく速くなる | 書き方が決まっている作業が多い |
| テスト | 作業は減るが期間は縮みにくい | テストコードは作れても、確認と修正は人の作業 |
| 受入テスト | 変わらない | 実施するのは発注側の現場担当者 |
この表で見てほしいのは、上下の両端です。要件定義と受入テストは発注側が主役の工程なので、開発会社がAIを使っても短くなりません。プロジェクト全体で見ると、AIが効く範囲は思ったより狭いということです。
逆に言えば、発注側の準備が遅いプロジェクトでは、AIを使っても結果は変わりません。要件が決まらずに待っている時間は、AIでは埋められないからです。効果を出したいなら、開発会社の道具より自社の意思決定の速さを気にするほうが効きます。
期間は全体では思ったほど縮まない
実装が半分の期間で終わったとしても、プロジェクト全体が半分になるわけではありません。実装が占める割合はもともと3〜4割程度で、しかも実装が終わったあとにはテストと受入テストが残ります。
加えて、実装が速く終わると、次の工程の準備が間に合わないという事態が起きます。受入テストのシナリオを作るのも、現場の担当者を確保するのも、発注側の仕事だからです。開発会社が前倒しで仕上げてきても、こちらの準備ができていなければ意味がありません。
AI活用を掲げる会社に発注するなら、自社側の準備を前倒しする覚悟が要ります。むしろここが追いつかず、結局は当初の予定どおりになるケースのほうが多いというのが実感です。
削減分が値引きになるとは限らない
ここが発注側にとって一番の関心事だと思います。開発会社の作業が減ったとして、その分が請求額から引かれるのか。
答えは会社によって違います。人月ベースで見積もる会社なら、工数が減れば金額も下がります。一方で、成果物の規模や機能数で見積もる会社なら、内部で何を使おうと金額は変わりません。後者の場合、AIによる削減は開発会社の利益になります。
これは不当なことではありません。効率化した会社が利益を得るのは当然です。ただ、発注側としては「AIを使っているから安いはず」と思い込まないほうがいい、というだけです。金額の妥当性は、AIの有無ではなく見積書の内訳で判断してください。見積書の読み方はシステム開発の見積もりの見方の記事で扱っています。
値引き交渉の材料に使いたい場合は、「AIを使っているなら安くなりますよね」ではなく、「この機能の実装工数が他社より多いのはなぜですか」と聞くほうが話が進みます。前者は感情的な話になりがちですが、後者は根拠の説明を求める質問なので、答えが返ってきます。
品質は上がることも下がることもある
AIを使うと品質が上がる、という説明を受けることがあります。半分は正しく、半分は条件つきです。
上がる側面は、書き方のばらつきが減ることです。人によって書き方が違うと、あとで直すときに読みにくくなります。AIを使うと一定の型に揃いやすくなります。
下がる側面もあります。AIは、それらしく動くけれど意図とは違うものを作ることがあります。しかも見た目には自然なので、レビューが甘いと素通りします。人が一行ずつ書いていたころなら「なぜこうしたのか」を説明できましたが、生成されたものは説明できる人がいない状態になりがちです。
つまり、品質を決めるのはAIの有無ではなく、生成されたものを誰がどう確認しているかです。ここが次の話につながります。
もうひとつ気にしておきたいのが、稼働後の保守です。作った本人が説明できないコードは、数年後にもっと分からなくなります。長く使うシステムほど、この点の重みが増します。
システム開発のAI活用を発注側が確認する方法
ここからは実務です。確認すべきなのはツールの名前ではありません。
工程別にどれだけ減るのかを聞く
「AIを活用して効率化します」と言われたら、次の1問を返してください。
「どの工程が、どれくらい短くなる見込みですか」
この質問に工程名と割合で答えられる会社は、実際に使って効果を測っています。答えが「全体的に効率化されます」で終わる場合は、掲げているだけの可能性があります。責める必要はありませんが、その前提で見積もりを読んでください。
あわせて、短くなった分がスケジュールのどこに反映されているかも見てください。実装が短いのにテスト期間まで一緒に短くなっている計画は危険です。生成されたコードを確認する時間は、むしろ増えることもあります。
AIを使っているかは提案書に書かれない
前提として知っておきたいのが、開発会社にはAIの利用を申告する義務がないという点です。提案書にも見積書にも書かれていないのが普通で、書いていないから使っていない、とは言えません。
実際のところ、コードを書く道具として使うのはもはや珍しくありません。エディタに組み込まれた補完機能まで含めれば、意識せずに使っている開発者も多いはずです。「使っていますか」という聞き方だと、どこまでを指すのかで答えがぶれます。
聞くなら範囲を区切ってください。「納品されるコードのうち、AIが生成したものが含まれますか」「その場合、社内でどう確認していますか」。この2つなら、答えが具体的になります。使っていること自体を問題視する姿勢で聞くと構えられるので、確認したいのは体制のほうだと最初に伝えると話が早いです。
生成されたコードの権利関係を確認する
AIが書いたコードの権利は、まだ固まりきっていない領域です。文化庁のAIと著作権についてのページでも、令和6年3月に取りまとめられた「AIと著作権に関する考え方について」は、生成AIと著作権に関する判例および裁判例の蓄積がないという現状を踏まえて整理されたものだと説明されています。同年7月には、立場ごとの対応をまとめたチェックリスト＆ガイダンスも公開されています。
判例が積み上がっていないということは、揉めたときに何が正解かを誰も断言できないということです。だからこそ、契約で決めておく意味があります。発注側が確認しておきたいのは次の3点です。
- 納品されるコードの著作権を、自社に譲渡してもらえるか
- AIが生成したコードを含むことについて、開発会社が説明する義務を負うか
- 第三者の権利を侵害していた場合、どちらがどこまで責任を負うか
3つ目は、AIに限らず既存の契約書にも書かれていることが多い項目です。AIを使う場合はここの意味が重くなるので、条文を読み直しておいてください。著作権の扱い全般はシステム開発の著作権の記事で整理しています。なお、個別の契約の解釈は弁護士に相談してください。
レビュー体制を聞く
品質の話でも触れたとおり、AIを使うかどうかより、生成されたものをどう確認しているかが効きます。次の2点を聞いてください。
1つ目は、生成されたコードを人がレビューしているかどうか。当たり前に聞こえますが、量が増えると全部は見きれなくなります。どの範囲を人が見て、どこは自動チェックに任せているのかを確認します。
2つ目は、レビューする人が内容を説明できるかどうかです。稼働後に不具合が出たとき、「なぜこの作りになっているのか」を答えられる人がいないと、修正に時間がかかります。開発中に質問を投げてみて、答えが返ってくるかを見るのが早い確認方法です。
質問の仕方は難しくありません。設計書を見ながら「この処理はなぜこの順番なんですか」と聞くだけです。理由が返ってくれば理解されています。「そういう仕様です」で止まる場合は、掘り下げて聞いてみてください。
テスト工程で何を受け取るかはシステム開発テストの種類の記事にまとめています。AIを使っていても、受け取る証跡の種類は変わりません。
契約と要件定義に何を書いておくか
確認した内容は、口頭で終わらせず書面に残します。書いておく価値が高いのは次の3つです。
| 書く場所 | 書く内容 |
|---|---|
| 契約書 | 著作権の帰属、第三者の権利を侵害した場合の責任範囲 |
| 要件定義書 | 社外に出せないデータをAIツールに入力しない旨 |
| 議事録 | 工程別の短縮見込みとして説明を受けた内容 |
2つ目は見落とされがちです。開発の過程で、自社の業務データや設計内容が外部のAIサービスに送られる可能性があります。何を入れてよくて何を入れてはいけないかは、発注側から先に伝えておくほうが確実です。要件の抜けを点検したい場合は、要件定義書レビューシートの非機能要件やセキュリティの項目が目安になります。
システム開発のAI活用についてよくある質問
- Q. AIを使っている会社を選んだほうがいいですか。
- 使っているかどうかで選ぶ必要はありません。判断材料になるのは、工程別の効果を数字で説明できるか、レビュー体制を答えられるかの2点です。使っていない会社が劣るわけでもありません。
- Q. AIを使っているかどうかは見積書で分かりますか。
- 分かりません。見積書に書く義務もありません。気になる場合は提案の段階で聞いてください。答えを契約や議事録に残しておくと、あとで確認したいときに困りません。
- Q. AIに任せてはいけない工程はありますか。
- 要件定義と受入テストは、発注側にしか判断できない情報を扱うので、AIに任せる話ではありません。開発会社側の工程については、任せる範囲を発注側が指定するより、確認の仕組みを聞くほうが実務的です。
- Q. 自社の情報がAIの学習に使われませんか。
- 利用するサービスの契約内容によります。開発会社がどのサービスを業務利用しているか、入力した内容が学習に使われない設定になっているかを確認してください。社外に出せないデータの範囲は、こちらから先に伝えておくのが確実です。
