生成AI受託開発 ／ ブログ ／ 生成AI開発を外注する前に社内で決める7項目｜見積前チェックリスト
生成AI導入受託開発要件定義

生成AI開発を外注する前に社内で決める7項目｜見積前チェックリスト

生成AIの受託開発を依頼しても見積が出ない、途中で手戻りする——原因は社内側の未決事項です。業務範囲、合格ライン、データ持ち出し可否など依頼前に決めるべき7項目を実務目線で整理します。

「生成AIで何かできないか検討している。とりあえず開発会社に相談してみよう」——この段階でご相談をいただくことは珍しくありません。むしろ歓迎です。ただ、そのまま話を進めると、見積が出るまでに何往復もやりとりが必要になり、着手後に「そもざも解きたかった課題が違った」という手戻りが起きやすくなります。

この記事は、生成AIの受託開発をこれから外注しようとしている企業の担当者・経営者に向けて、依頼前に社内で決めておくと、見積の精度が上がり、プロジェクトの途中の揉め事が減る事項を整理したものです。技術的な仕様を決める必要はありません。決めるべきは「業務」と「判断」の側です。

なぜ「相談前の社内合意」が効くのか

生成AIを使った開発は、従来のシステム開発と比べて、要件が曖昧なまま始まりやすい構造があります。理由は3つあります。

第一に、生成AIは「入力すれば何かしら出力が返ってくる」ため、動くものを作るハードルが低い一方、それが業務で使える品質かどうかの判断基準が曖昧になりがちです。第二に、扱う対象が社内文書・顧客とのやりとり・図面など、部署ごとに管理が分散した非構造データであることが多く、データがどこにあり誰の許可で使えるのかを開発会社側からは確認できません。第三に、出力が確率的に変動するため、「100%正しい回答」を前提にした設計はそもそも成立せず、どこまでを人が確認するかという業務設計の判断が必要になります。

いずれも、開発会社が代わりに決められない領域です。ここが未決のまま進むと、要件定義フェーズが長引き、費用も膨らみます。

依頼前に決めておくべき7項目

1. 解きたいのは「どの業務の、どの工程か」

「業務効率化」ではスコープが決まりません。組織図と業務フローのレベルまで降ろします。

悪い例：営業部門の生産性を上げたい。 良い例：営業事務3名が行っている、引き合いメールから見積依頼票を起票する作業（1日あたり20〜30件、1件あたり10分程度）を短縮したい。

後者まで具体化されていれば、開発会社は対象データの形式、想定処理件数、失敗したときの影響範囲を推定できます。ここを詰めるだけで、見積の幅が大きく縮まります。

2. 「使える」と判断する基準と合格ライン

生成AIの出力は誤りをゼロにできません。したがって「精度100%」は要件になり得ません。決めるべきは、どういう間違いなら許容し、どういう間違いは絶対に避けたいかです。

この優先順位が決まると、設計が変わります。前者ならドラフト生成に振り切れますし、後者なら数値部分は生成AIに書かせず既存システムから転記する設計にする、といった判断ができます。

あわせて、評価用のサンプルを社内で20〜50件用意できるかも確認しておいてください。過去の実際の入力と、それに対する「正解」の組み合わせです。これがあるかないかで、検証の質は大きく変わります。

3. データの所在・持ち出し可否・権利関係

次の点を、情報システム部門や法務担当と事前に確認しておくと進行が速くなります。

特に、顧客から預かった資料を含むケースは要注意です。「社内文書だと思っていたが、契約上は目的外利用ができなかった」という事情が後から判明すると、設計をやり直すことになります。

4. 誰が使い、どの画面・どの手順で使うのか

同じ機能でも、使う人と使う場所で作るものが変わります。既存の業務システムに組み込むのか、チャットツールから呼び出すのか、専用画面を用意するのか。現場が普段開いていないツールを新設すると、精度以前の理由で使われなくなります。

また、出力を人が確認する工程を業務フローのどこに置くかも決めておきます。「AIが下書き→担当者が修正→上長承認」という流れなら、修正のしやすさが要件になります。

5. 予算の上限と、スコープの優先順位

予算を伝えたくないという心情は理解しますが、金額のレンジを開示していただけると、提案の方向性を絞れます。加えて有効なのが、やりたいことの優先順位付けです。

A：必須。これがなければ導入する意味がない B：あると効果が上がるが、後回し可 C：将来的な構想

この3分類があるだけで、第1フェーズの範囲を合理的に切れます。全部Aだと、検証と本番構築を分けられず、リスクを抱えたまま大きく発注することになります。

6. セキュリティ・ガバナンス上の社内ルール

社内に生成AIの利用ガイドラインがあるなら、その内容を最初に共有してください。ない場合は「まだない」と伝えていただければ、それも前提として設計します。確認しておきたいのは、外部サービスへのデータ送信の可否、ログの保存期間、アクセス権限の分離、監査の要否あたりです。上場企業や、金融・医療・公共領域の取引がある企業では、ここが実質的な設計制約になります。

7. 意思決定者・窓口・運用担当

最後が地味ですが重要です。

特に3つ目が抜けやすいところです。生成AIを使った仕組みは、参照する社内文書が更新されたり、業務ルールが変わったりすると出力の妥当性が落ちます。運用の受け皿を決めずに作ると、半年後に使われなくなる典型パターンに入ります。

具体例：社内問い合わせ対応を検討したケース

イメージしやすいよう、よくある検討の流れを書きます。

ある管理部門で、経費精算や就業規則に関する社員からの問い合わせが日次で発生しており、担当2名が対応に時間を取られていました。当初の相談は「社内規程を答えてくれるチャットボットを作りたい」というものでした。

ここで上記の項目を当てはめていくと、論点が変わってきます。まず対象文書を洗い出すと、規程集はイントラにあるものの、実務上は「規程には書かれていない運用ルール」がメール履歴に散在していました。つまり参照元の整備が先です。次に合格ラインを議論すると、「誤った金額基準を回答されると精算のやり直しが発生するので、金額に関わる質問は必ず出典の条文を提示させたい」という要件が出ました。さらに利用場所は、社員が普段使っているチャットツールが妥当だと決まりました。

結果として、第1フェーズは「参照文書の棚卸しと、出典提示つきの回答生成の検証」に絞り、規程外の運用ルールの取り込みは第2フェーズへ、という切り方になります。最初の相談内容のまま作り込んでいたら、出典なしで自信ありげに答える仕組みができ、現場が信用しなかった可能性が高いところでした。

決めきれないときは「決めるための発注」をする

ここまで読んで「7項目のうち半分も決まっていない」と感じた方もいると思います。それが普通です。

その場合の現実的な進め方は、要件を決めること自体を短期の別フェーズとして発注することです。数週間程度で、業務ヒアリング、データの実物確認、ごく小規模な試作と評価を行い、そのうえで本開発の判断材料を揃えます。曖昧なまま大きな金額でまとめて発注し、途中で仕様変更を繰り返すより、費用も時間も見通しが立ちます。

私たちも、初回のご相談では機能の話より先に、業務フローと扱うデータの現物を見せていただくことをお願いしています。

外注が向かないケースも正直に書きます

すべてを外注で解くべきではありません。次のような場合は、いったん立ち止まることをおすすめします。

対象業務の件数が少なく、効果が定量化できない場合。 月に数件しか発生しない作業を自動化しても、開発費と運用負荷を回収できません。まずは既存ツールの標準機能や、汎用のAIサービスを担当者が手作業で使う運用で足りることが多いです。

データがまだ存在しない、あるいは紙のままの場合。 参照させたい情報が電子化されていないなら、優先すべきはそこの整備です。開発を先に走らせても、参照元がない仕組みができるだけです。

成果の判定を社内で誰も引き受けられない場合。 出力の良し悪しを判断できる業務知識のある人が関与できないと、検証が成立しません。この場合は担当者の確保が前提条件になります。

現行業務のルールが属人的で言語化されていない場合。 これは外注が不可能というより、順序の問題です。業務の整理と並走させる前提で、期間と費用を見込む必要があります。

依頼前チェックリスト

最後に、開発会社への相談メールに添付できるレベルの確認項目としてまとめます。

  1. 対象業務（部署／担当人数／件数／1件あたりの所要時間）
  2. 現状の手順と、困っている工程
  3. 許容できない誤りと、許容できる誤り
  4. 評価用サンプルの用意可否と件数
  5. 使用するデータの所在・機密区分・外部送信の可否
  6. 利用者と、利用する画面／ツール
  7. 必須要件と後回し可能な要件の区分
  8. 予算レンジと希望時期
  9. 社内の意思決定者・窓口・運用担当

すべて埋まっていなくて構いません。「ここは未確定」と明示されているだけで、初回の打ち合わせの中身が変わります。逆にこれらを整理せずに相談すると、開発会社側は安全側に見積を寄せるほかなく、金額も期間も膨らみます。

生成AIの導入は、モデルやツールの選定よりも、業務のどこを任せてどこを人が持つかという設計で結果が分かれます。その判断の材料は社内にしかありません。依頼前の準備は、外注先のための作業ではなく、自社の投資判断のための作業だと捉えていただければと思います。