AI コーディングのモデルの使い分けは見積もりにどう効くか、開発会社に確かめたい 4 つの問い

「AI を使うので開発費が下がります」という説明を、見積もりの場で聞く機会が増えています。確かに、設計、実装、テスト、レビュー、修正までを AI コーディングエージェントに任せられる範囲は広がっています。ただ、見積書の金額が下がるかどうかは、AI を使うかどうかではなく、どう使うかで決まります。

キーマンズネットが紹介した、OpenAI Japan の講演（Japan IT Week、出典）は、この点を分かりやすく整理していました。講演では、最上位のモデルを全工程で使うと予算を圧迫し、安価なモデルだけだと手戻りが生じやすい、と説明されています。

これは開発会社の内部の話に見えますが、発注側の見積もりにそのまま響きます。この記事では、業務アプリや SaaS の開発を外部に頼むときに、見積書を受け取った段階で確かめておきたい 4 つの問いを整理します。

1. 工程ごとに、使うモデルを分けているか

講演では、モデルを 3 種類に使い分ける考え方が紹介されています。高度なタスク向けの GPT-6 Astra、品質と速度のバランスがよく設計やレビュー、レビュー結果に基づく修正に使う GPT-6.1 Sol、低コストで時間のかかる実装や大量の定型作業に向く GPT-6 Luna です。同じ講演によると、ベンチマーク DeepSWE での比較で、GPT-6.1 Sol は Astra と同程度の精度を約 5 分の 1 のコストで出せるとされています。業務アプリでの実測ではなく、Sol で難しい場合に Astra へ切り替える、という使い方の説明の一部です。

モデルの名前や性能は、これからも入れ替わります。発注側が見るべきなのは名前ではなく、次の点です。

• 設計やレビューのように判断が重い工程と、定型的な実装の工程で、使うモデルを分けているか
• 分けているなら、その基準を説明できるか
• 全工程を最上位モデルで進める前提の見積もりになっていないか

私たちは、工程ごとの使い分けを説明できない見積もりは、AI の利用料が膨らむ余地を残していると考えています。逆に、安いモデルだけで通す前提の見積もりは、修正の工数が後から出てくる可能性があります。どちらの前提なのかを、先に聞いておくと安心です。

2. 完了条件を決めて、AI に渡しているか

同じ講演では、プロンプトに「目的」「文脈」「制約」「完了条件」の 4 項目を明示することが勧められています。特に完了条件を書くと、ビルドが通るまで自律的に作業が続く、という説明です。

講演では、完了条件を定義しないと、動作確認をせずにタスクを終えてしまう場合がある、とも説明されています。私たちは、完了条件が曖昧なまま任せると、動いてはいても求めていたものではない状態で人に戻り、AI で下げたはずの工数が戻ってくると考えています。

開発会社には、次のように聞いてみてください。

• 1 つの機能を AI に任せるとき、完了条件を誰が、どの形式で書くのか
• 完了条件に、画面の動きだけでなく、既存の業務データとの整合や権限の確認が含まれるか
• 完了条件を満たしたかどうかを、誰が確かめるのか

発注側が受け取るコードの受け入れ条件を決めておくことと、開発会社が AI に渡す完了条件を決めることは、別のものです。前者は発注側の責任で、後者は開発会社の進め方の問題です。両方がそろって、手戻りが見積もりの中で読めるようになります。

3. AI の利用料は、見積書のどこにあるのか

ここで扱うのは、開発会社が開発の工程で AI を使うときの利用料です。完成した業務アプリに載せる AI 機能の実行時の費用は含みません。トークン消費に伴う開発工程の利用料は、開発会社が負担する場合と、実費として発注側に請求する場合があります。どちらが良いという話ではなく、見積書のどこに入っているのかが分からないと、あとで請求の形が変わったときに比べようがありません。

• 開発費に含まれていて、追加の請求は発生しないのか
• 実費精算なら、月ごとの上限や、上限に近づいたときの連絡の取り決めがあるのか
• 開発の途中でモデルを切り替えたとき、見積もりは変わるのか

利用料の単価は、提供元の改定で変わることがあります。単価そのものよりも、変わったときに誰がどう負担するかを決めておく方が、発注側にとっては重要です。

4. 人が確認する工程は、どこに残っているのか

講演で示された例として、OpenAI の社内プロジェクトが約 5 か月間で約 1,500 件のプルリクエストを作成・マージし、1 人あたりの平均は 1 日 3.5 件だったと紹介されています。また、楽天がウェブサービスのモバイルアプリ展開を、従来約 3 か月から数週間に短縮したとも紹介されています。AI の利用で、速度が大きく上がる場面があるのは確かです。

ただし、業務アプリにそのまま当てはまる数字ではありません。業務アプリでは、請求、在庫、権限のように、間違えたときの影響が大きい箇所があります。そこでは、速さよりも、人が確認する工程が残っていることが大切です。

• 設計の判断とレビューを、人がどの段階で行うのか
• テストを AI に書かせる場合、そのテストが本当に業務の例外を拾っているかを誰が確かめるのか
• AI が出した変更のうち、人が必ず読むものの基準があるか

人の確認が見積もりから消えている場合は、安くなっているのではなく、確認が省かれている可能性があります。

見積書を受け取ったときの確認の順番

4 つの問いを、実際の打ち合わせで使う順番にまとめます。

1. 工程ごとのモデルの使い分けと、その基準を聞く
2. 完了条件の書き手と、確かめる人を聞く
3. AI の利用料が見積書のどこにあり、変わったときに誰が負担するかを聞く
4. 人が確認する工程を、設計・レビュー・テストのそれぞれで聞く

この 4 つにどう答えるかは、開発会社の AI を使った開発のやり方が整っているかを判断する材料になります。逆に、「AI を使うので安くなります」という説明だけで、どの工程にどう効くのかを示せない場合は、見積もりの根拠をもう少し聞いてみる価値があります。

まとめ

AI コーディングエージェントによる開発では、モデルの選び方と完了条件の渡し方が、費用と手戻りの両方を左右します。発注側がモデルの中身に詳しくなる必要はありません。工程ごとの使い分け、完了条件、利用料の置き場所、人の確認の 4 点を聞けば、見積もりの根拠が見えてきます。

SaaS・業務アプリ開発では、要件定義から設計・開発・公開後の改善まで一貫して支援しています。AI を使った開発の進め方や見積もりについて確認したいことがあれば、お気軽にご相談ください。