結論：技術の説明より、5つの質問への答え方で選ぶ
生成AIを使ったサービスの開発を外注するとき、候補の会社を「どの技術に詳しいか」で比べようとすると、発注側には優劣が判断できないまま話が進みがちです。比べやすいのは、次の5つの項目に対して、その会社が自社の案件に即して具体的に答えられるかどうかです。
- 業務理解：生成AIを入れる業務の流れと、利用者が困っている場面を自分の言葉で説明し直せるか
- 評価方法：出力の良し悪しを、誰が、どの基準で、どのデータを使って確かめるかを提案できるか
- 誤り時の設計：誤った出力が出た前提で、画面・業務・連絡の流れを設計しているか
- データの扱い：入力したデータがどこに送られ、どこに残り、誰が見られるかを説明できるか
- 運用：公開後の監視、改善、費用の変動、モデルの更新への対応を見積もりに含めているか
生成AIは、同じ入力でも出力が変わることがあり、もっともらしい誤りを含むことがあります。この性質は、どの会社に依頼しても変わりません。だからこそ、性質を前提にした設計と検証の進め方を持っているかが、会社選びの中心になります。
依頼の前に、発注側が言葉にしておくこと
会社を比べる前に、発注側の条件がそろっていないと、各社の提案は前提がばらばらになり比較できません。最低限、次の内容を短い文書にしておくと、面談の質が上がります。
- 誰の、どの作業を、生成AIで変えたいのか。たとえば、問い合わせ対応の担当者が回答文の下書きを作る作業、のように人と作業を特定します。
- いまその作業はどう行われているか。使っている資料、判断の手順、確認する人を書き出します。
- 出力が誤っていた場合に何が起きるか。社内で直せば済むのか、顧客に届いてしまうのかで、必要な設計は大きく変わります。
- 今回確かめたいことは何か。技術的に実現できるかを知りたいのか、利用者が使い続けるかを知りたいのかを分けます。
- 使ってよいデータと、使ってはいけないデータ。個人情報や取引先の情報が含まれるかどうかを先に確認します。
検証の目的によって、作るものの大きさも変わります。PoC・試作画面・MVPを問いから選ぶ考え方を先に整理しておくと、「まず何を作るか」の議論が短くなります。見積もりを複数社から取る場合は、発注条件をそろえてから見積もりを比べる手順も参考になります。
業務理解と評価方法を、面談でどう確かめるか
業務理解は、会社の説明を聞くだけでは分かりません。面談では、こちらの業務を説明したあとに「この業務のどこに生成AIを入れ、どこには入れないほうがよいと考えますか」と聞いてみてください。すべての工程に入れる提案より、入れない工程とその理由を言えるかどうかが、業務を見ているかの手がかりになります。
評価方法については、次の点を聞くと差が出ます。
- 良い出力と悪い出力の基準を、誰と一緒に決めるか。業務を知る担当者が基準づくりに参加する前提になっているかを確認します。
- 評価に使う入力例を、どう集めるか。実際の業務で起きる入力、めったに起きないが起きると困る入力、意図的に誤らせようとする入力を分けて用意する考えがあるかを見ます。
- 指示文やモデルを変えたとき、以前は正しく答えられていた入力で品質が落ちていないかをどう確かめるか。変更のたびに同じ入力例で確かめ直す仕組みがあるかを聞きます。
- 評価の結果を、発注側が読める形で報告するか。
「精度は高いです」という答えしか返ってこない場合は、何をもって高いとするのかを重ねて聞いてください。基準と確認の手順が出てこなければ、公開後に品質の議論ができなくなります。検証の終わりに判断できる状態をつくる考え方は、PoCの評価設計で扱っています。
誤ったときの設計と、データの扱いを確かめる
生成AIを使うサービスでは、誤りをなくすことより、誤りが起きても業務が止まらず、被害が広がらないことを設計の目標に置くほうが現実的です。提案の中に次の要素が含まれているかを確認します。
- 出力をそのまま外部に出すのか、人が確認してから出すのか。確認する場合、その人の作業量が現実的か。
- 利用者が誤りに気づいたとき、報告や修正をどこから行えるか。
- 答えられない質問に対して、無理に答えず、人へ引き継ぐ流れがあるか。
- 根拠となる資料を出力と一緒に示すなど、利用者が自分で確かめられる手がかりがあるか。
- 問題が起きたときに、機能を一時的に止める手段があるか。
この考え方は、生成AIのMVPで失敗時の仕事まで設計するでも詳しく扱っています。
データの扱いでは、入力した内容が外部のモデル提供元に送られるのか、学習に使われる設定になっていないか、記録がどこにどれだけの期間残るのか、開発会社の担当者がどの範囲まで閲覧できるのかを、図や文書で説明してもらいます。個人情報や機密情報を含む場合の法的な扱いは個別の判断になるため、専門家に確認してください。ここで確かめたいのは、開発会社がこの問いを面倒がらず、構成を示して答えるかどうかです。
運用まで見積もりに入っているか
生成AIを使うサービスは、公開して終わりになりません。見積もりと提案に、次の内容が含まれているかを確認します。
- 利用量に応じて変動する費用を、誰がどう監視するか。上限や通知の仕組みがあるか。
- モデルの提供元が仕様を変えたり、提供を終了したりした場合に、誰が確認し、どう切り替えるか。
- 利用者の入力と出力の記録を、改善にどう使うか。記録を見る人と範囲が決まっているか。
- 指示文、評価用の入力例、設定の一式が、成果物として発注側に引き渡されるか。
- 開発会社との契約が終わったあと、自社または別の会社が引き継げる文書が残るか。
特に、指示文と評価用の入力例は、ソースコードと同じくらい重要な資産です。これが開発会社の手元にしか残らない契約だと、あとから品質を検証し直すことも、別の体制に移ることも難しくなります。成果物の範囲は契約の前に文書で確認してください。
よくある質問
Q. 発注側に生成AIに詳しい人がいなくても依頼できますか。
依頼はできます。ただし、業務の流れと「良い出力とは何か」を判断できる担当者は、発注側に必要です。技術は開発会社が補えますが、業務上の正しさの基準は外部の会社には決められません。週に一定の時間を評価に使える担当者を、開始前に決めておくことをおすすめします。
Q. 最初から本番向けに作るべきか、小さく試すべきか迷っています。
出力の品質が業務に耐えるかどうかが分かっていない段階なら、範囲を絞った検証から始めるほうが、判断の材料を早く得られます。対象の業務、利用者、入力の種類を限定し、評価の基準と期間を先に決めてください。すでに品質の見通しがあり、既存の業務システムとの連携が主な課題であれば、通常のシステム開発に近い進め方が合います。
Q. 提案を比べるとき、金額以外にどこを見ればよいですか。
評価と運用に割かれている工数を見てください。画面と機能の開発だけで構成され、評価の設計、誤り時の流れ、引き継ぎが含まれていない見積もりは、あとから追加の費用と期間が発生しやすくなります。含まれていない場合は、その理由と、誰がその作業を担う想定なのかを質問します。
Otsumuに相談できること
Otsumuは、新規事業のMVPシステム開発をAIを活用して行っており、戦略と開発を分断せず、構想から運用までひとつのチームで支援しています。生成AIを使うサービスの検証では、PoC / MVP Sprintとして、検証目的・機能範囲の合意、主要画面と利用シナリオ、検証用PoC / MVPシステム、効果測定の項目・計測設計、公開・運用に向けた引き継ぎ、検証結果と次フェーズの改善方針までを扱います。参考価格は300万円〜（税別）、6週間を目安に設計し、300〜800万円程度を検討の目安として、機能数・外部連携・セキュリティ要件で変動します。クラウド利用料等は別途で、正式な見積もりは相談後にお出しします。秘密保持、成果物の取り扱い、契約・検収の条件は、相談時に確認のうえ合意します。
すでに社内に評価できる担当者と開発体制があり、この記事の確認項目を自社で進められる場合は、外部への相談は必要ありません。何から決めればよいかが定まらない場合は、30分の無料診断で状況を伺います。依頼内容を文書にまとめる際は、MVP見積依頼書テンプレートも使えます。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。記載の価格はOtsumuの税別・参考価格で、正式なお見積もりはご相談後にご案内します。法務・税務・会計・補助金などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.21