AI開発の提案が比較できない。見積依頼書に書く業務と完成条件

AI開発の提案を公平に比較したいときは、見積依頼書（RFP）に業務内容と完成条件を具体的に記載することが第一歩です。まずは自社で実現したい業務フローと求める出力を一覧化し、評価項目を整理しましょう。

AI開発で比較できない原因は何か

要件定義が曖昧になる理由

要件定義が曖昧になるのは、業務側が「AIで何ができるか」だけを語り、具体的な入力データや期待結果を示さないことが多いためです。たとえば「顧客問い合わせを自動で回答させたい」とだけ記載すると、ベンダーは自社の得意分野に合わせて幅広い解釈を提示し、比較が困難になります。

業務担当者は、どの画面やデータベースから情報を取得し、どのような形式で回答を返すかを明示する必要があります。

さらに、要件に含めるべきは「例外ケース」や「エラーハンドリング」の方針です。入力が不正確だった場合やシステム障害時にどのようにユーザーへ通知するかを記載しないと、ベンダーはリスクを過小評価した提案を出すことがあります。

社内の業務担当者に「入力エラーが起きたときの対応はどうしたいか」や「データ欠損時のフォールバックは必要か」など具体的な質問を投げかけ、要件を細分化しましょう。

ベンダー側の提案書の書き方の違い

ベンダーは自社の技術スタックや実績を前面に出す傾向があり、提案書の構成が企業ごとに大きく異なります。ある社は機能一覧を箇条書きで示す一方、別の社はフロー図やロードマップで説明します。この違いは比較の際に情報が揃わない原因となります。

提案書のフォーマットを統一させるために、見積依頼書で「提案書の構成項目」「ページ数上限」などを明示すると、ベンダーは同じテンプレートで回答でき、比較が容易になります。

また、価格の提示方法もバラバラです。ライセンス料・開発費・保守費を一括で示すケースと、項目別に細分化して示すケースがあります。自社の予算管理の観点からは、どの費用が変動しやすいか、どの費用が固定かを見極めることが重要です。

社内の財務担当者に「総費用の内訳をどこまで細かく把握したいか」や「支払いスケジュールの希望は？」と確認し、見積依頼書に具体的な指示を書き込みましょう。

評価基準が統一されていない背景

評価基準が統一されていないと、ベンダーの提案は「見た目の良さ」や「実績の多さ」で評価されがちです。実際には、AIシステムの性能はデータ品質や運用体制に大きく依存しますが、これらは見積依頼書に明記されていないと評価に入れられません。

評価項目として「精度」「応答速度」「スケーラビリティ」「保守体制」などを明示し、各項目に点数や重みを設定すると、客観的な比較が可能になります。

さらに、評価基準は自社のリスク許容度に合わせてカスタマイズすべきです。たとえばデータプライバシーが重要な業界では「情報漏洩防止策」の評価比重を高く設定し、逆に処理速度が鍵になる場合は「レイテンシ」の比重を上げます。

社内のリスク管理担当者に「どのリスクが最も懸念されるか」をヒアリングし、評価シートに反映させることで、提案比較が自社の実情に合致したものになります。

見積依頼書に必ず入れるべき業務項目

業務フローと入力データの具体例

業務フローは、AIシステムがどのタイミングで介在するかを時系列で示すことが重要です。たとえば「顧客からのメール受信 → テキスト抽出 → 意図判定 → 自動返信生成 → 送信履歴保存」のように、各ステップで使用するデータ形式や保存先を明記します。

入力データの例としては、メール本文（テキスト）、添付ファイル（PDF）や過去のやり取り（CSV）など、実際にシステムが受け取る情報を具体的に列挙しましょう。

この情報は、ベンダーが必要な前処理やインターフェース設計を見積もる基礎となります。社内の業務担当者に「実際に扱うデータは何か」「データはどこに保管されているか」「取得頻度はどれくらいか」などを確認し、見積依頼書に添付資料としてサンプルを添えると、提案の精度が上がります。

期待する出力と品質指標

期待する出力は、単なるテキストだけでなく、形式や評価指標も含めて記載します。例として「自動返信文（最大200文字）」「返信の信頼度スコア（0〜1）」「生成時間（秒単位）」といった項目を列挙し、各項目の目標値や許容範囲を設定します。品質指標としては、正答率（Accuracy）や再現率（Recall）など、業務に直結する数値を明示することが重要です。

さらに、出力のレビュー体制やフィードバックループも記載すると、ベンダーは運用後の改善プロセスを提案に組み込みやすくなります。社内の品質管理担当者に「どの指標が業務成功に直結するか」「許容できるエラー率はどれくらいか」などをヒアリングし、数値目標として見積依頼書に記載しましょう。

例外処理とエラーハンドリングの要件

例外処理は、AIが期待通りに動作しないケースを想定して事前に定義しておく必要があります。たとえば「入力が空白の場合はデフォルトメッセージを返す」「外部APIがタイムアウトした場合は再試行回数を3回に限定する」など、具体的なシナリオと対策を列挙します。

これにより、ベンダーは例外ロジックの実装コストを概算しやすくなりますが、実際の実装範囲やコストはベンダーとの協議で確認してください。

また、エラーハンドリングの結果をどのようにログに残すか、誰が確認するかといった運用面の要件も忘れずに記載します。社内のシステム管理者に「エラー情報はどこに保存したいか」「アラートはどの担当者に送るか」などを確認し、見積依頼書に具体的な要件として盛り込みましょう。

完成条件と検収項目の設定方法

機能要件と非機能要件の分け方

機能要件は、システムが「何をするか」を示す具体的な機能一覧です。たとえば「テキスト抽出」「意図判定」「自動返信生成」など、業務フローに沿った項目を列挙します。一方、非機能要件は「どのように提供するか」を示し、性能（応答時間）、可用性（稼働率）、セキュリティ（データ暗号化）などを含みます。

これらを別々の表にまとめ、項目ごとに受入基準を設定すると、検収時にチェックしやすくなります。

社内の技術担当者に「どの性能指標が必須か」「セキュリティ要件はどのレベルが必要か」などを確認し、要件定義書に具体的な数値や条件として記載します。非機能要件は、ベンダーがインフラ設計や運用体制を提案する際の重要な判断材料となります。

テストシナリオと受入基準の作り方

テストシナリオは、完成条件を検証するための具体的な手順です。代表的なシナリオとして「正常系：正しい入力で期待通りの返信が生成されるか」「異常系：不正な入力でエラーメッセージが返るか」などを作成し、期待結果と合格基準を明示します。受入基準は、各シナリオの合格率や許容エラー率を数値化して示すと、ベンダーと合意しやすくなります。

テスト実施担当者に「テストは社内で行うか外部で委託するか」「テストデータはどの程度用意できるか」を確認し、必要なリソースやスケジュールを見積依頼書に添付します。これにより、ベンダーはテスト工数を正確に見積もり、納期の提示が可能になります。

保守・運用の境界と引き渡し条件

保守・運用の範囲は、開発完了後にベンダーがどこまで責任を持つかを明確に定義します。たとえば「バグ修正はリリース後3か月間」「機能追加は別途契約」など、期間や対象範囲を具体的に記載します。

また、引き渡し条件として「ソースコードの完全納品」「運用マニュアルとAPI仕様書の提供」「担当者へのトレーニング実施」などを列挙し、完了判定の基準を設定します。なお、保守期間や対応範囲、SLA（サービスレベル合意）等の詳細は、ベンダーと個別に協議し、契約書に明記することが重要です。

運用担当者に「保守期間中に必要なサポートレベルは何か」「障害時の対応フローはどうしたいか」をヒアリングし、見積依頼書に具体的なSLA（サービスレベル）項目として記載します。これにより、ベンダーは保守コストを正しく見積もり、契約後のトラブルを防げます。

ベンダー選定と提案比較の実務

評価シートの作成とスコアリング

評価シートは、提案を数値化して比較するためのツールです。まずは「機能適合度」「価格」「実績」「リスク対応」などの評価項目を列挙し、各項目に重み（％）を付けます。ベンダーからの提案は、このシートに点数を入力し、総合スコアを算出することで客観的に順位付けできます。

社内の意思決定者に「どの項目を最重要視するか」「重み付けはどの程度にするか」を確認し、評価シートのテンプレートを事前に共有します。シートはExcelやGoogleスプレッドシートで作成し、全員がリアルタイムで確認できるようにすると、合意形成がスムーズになります。

質問事項と追加情報の取得方法

提案書だけでは不明点が残ることが多いため、質問事項を事前にリスト化してベンダーに問い合わせます。質問例として「データ前処理はどのように実装するか」「学習モデルの更新頻度は？」など、技術的・運用的なポイントを網羅します。ベンダーからの回答は、評価シートの補足情報として活用します。

質問担当者に「回答期限はいつまでか」「回答は書面で残すか」を指示し、取得した情報は全員で共有できるフォルダに保存します。これにより、後からの比較や議論が一貫した情報基盤の上で行えるようになります。

最終判断と社内合意の進め方

最終判断は、評価シートのスコアと質問回答を総合して行います。スコアが高く、リスクが低いベンダーを一次候補とし、経営層や財務部門と最終的な予算・契約条件を確認します。合意形成のために、提案比較の結果をプレゼン資料にまとめ、メリット・デメリットを明示します。

合意プロセスでは、関係部門に「最終決定までに必要な追加情報はあるか」「契約締結のタイミングはいつか」を確認し、合意書や覚書のドラフトを作成します。最終的に社内承認が得られたら、ベンダーへ正式な発注書を送付し、プロジェクトを開始します。