Partner articleAI開発会社ガイド2026/7/8

AI開発要件定義ワークショップRFPの書き方

AI開発を発注する前に、業務課題、データ、評価、責任分界、PoC範囲を固める要件定義ワークショップRFPの書き方を整理します。

結論

AI開発の要件定義ワークショップRFPでは、「AIで何かできないか相談したい」ではなく、発注前に決めたい論点を明記します。業務課題、利用者、対象データ、成功条件、禁止事項、レビュー責任、PoC範囲、見積前提を整理するワークショップとして依頼すると、後続の開発見積が比較しやすくなります。

AI開発は、画面や機能だけで要件を決めると失敗しやすい領域です。データの状態、評価方法、回答できない場合の扱い、権限、運用更新、人間レビューが品質を左右します。要件定義ワークショップは、これらを早い段階で確認し、開発に進むべきか、SaaSで足りるか、業務整理を先にすべきかを判断する場です。

RFPの冒頭では、ワークショップの目的を明確にします。たとえば「営業提案書作成の下書き自動化」「社内ナレッジ検索の精度確認」「問い合わせ分類の運用設計」のように、対象業務を絞ります。目的が広すぎると、ベンダーは一般的なAI活用案を出しやすく、実務に落ちない提案になります。

目的には、判断したいことも書きます。PoCへ進むか、既存SaaSを使うか、データ整備を先に行うか、予算化するか、社内承認を取るかなどです。ワークショップ後の意思決定が決まっていると、成果物の粒度が揃います。

ワークショップでは、ベンダーに解決策を急がせるより、前提を確認させます。AIで解くべき課題なのか、業務ルールが未整理なのか、データ品質が足りないのかを切り分けることが大切です。

成果物は、議事録だけでは不十分です。業務フロー、課題一覧、対象データ一覧、リスク整理、PoC案、概算見積レンジ、次に準備するもの、RFPへ入れるべき要件を指定します。これにより、ワークショップ後に別ベンダーへ相談する場合も比較しやすくなります。

成果物には、決まったことだけでなく、未確定事項も入れます。データ提供可否、権限同期、評価データ、社外提出可否、レビュー責任など、未確定事項が見積差につながります。未確定を隠したまま見積を取ると、後から追加費用やスコープ変更が発生します。

提案を比較するときは、ワークショップの進行力を見ます。AI技術の説明だけでなく、業務ヒアリング、データ確認、リスク整理、評価設計、意思決定支援をどこまで行うかを確認します。最初から開発前提にする提案より、SaaS利用、業務整理、PoC中止も選択肢に入れる提案の方が、発注者にとって安全です。

また、ワークショップの参加者も確認します。業務担当、情報システム、セキュリティ、法務、現場責任者が参加しないと、後から要件が変わります。RFPでは、参加が必要な社内ロールと、ベンダー側のファシリテーター、AI技術者、業務コンサルの役割を明記します。

この記事の画像は、業務課題、対象データ、評価設計、責任分界、PoC範囲、次の発注判断の流れを示す図解です。画像内にタイトルや売り文句を入れず、要件定義ワークショップで確認すべき論点を把握できるようにしています。

標準SaaSで解ける可能性がある場合はAI/SaaS比較で候補を確認します。独自業務や複雑な連携がある場合はAI開発会社一覧で要件定義ワークショップに対応できる会社を探し、この記事の項目をRFPへ入れます。

Q. 要件定義ワークショップはPoCの前に必要ですか? A. 必須ではありませんが、業務課題やデータ状態が曖昧な場合は先に実施した方が、PoC範囲と見積が安定します。

Q. ワークショップの成果物は何を受け取るべきですか? A. 業務フロー、対象データ、リスク、評価方法、PoC案、概算見積、未確定事項、次アクションです。

Q. どの部署を参加させるべきですか? A. 業務担当、現場責任者、情報システム、セキュリティ、法務、予算責任者を必要に応じて参加させます。

出典: