生成AI要件定義ガイド【発注者向け】テンプレート・チェックリスト付き

「生成AIを使ったプロジェクトの要件定義書を作ってください」——上司や事業部からそう言われて、何から手をつければよいのか分からず固まってしまった経験はないでしょうか。

Webシステムの発注経験があっても、生成AI（ChatGPT・Claude などのLLMを活用したプロジェクト）の要件定義となると話は別です。「ハルシネーションはどう対策すればいいのか」「精度指標はAccuracyでいいのか」「社内の機密情報をプロンプトに入れて大丈夫なのか」——通常のシステム開発では問われなかった項目、しかも従来型のAI（画像認識・需要予測などの機械学習）とも異なる論点が次々と出てきて、途方に暮れてしまうのは当然です。

実は、生成AIプロジェクトの要件定義は、通常のシステム開発とはもちろん、従来型のAI開発とも異なる点があります。同じフォーマットで進めると、開発会社との認識のズレが生じたり、PoC（概念実証）で「思っていたような回答が返ってこない」「著作権や機密情報の扱いを後から慌てて検討する」といった事態に陥ったりするリスクがあります。

本記事では、生成AIプロジェクトの発注経験がない方でも理解できるよう、AI特有の要件定義ポイントを土台にしつつ、生成AI固有の要件定義ポイントを重点的に解説します。記事後半にはそのまま使えるテンプレートと発注者向けチェックリストも用意しましたので、ぜひご活用ください。

秋霜堂株式会社は、システム開発の構想段階から発注者に伴走する経験を積んできました。その経験から「要件定義の段階で詰めておくべきだった」という失敗パターンを多く目の当たりにしてきました。本記事の内容を参考に、生成AI開発を成功に導く要件定義を進めていただければと思います。

—Free Download / 資料ダウンロード

【サンプル】システム開発 提案依頼書（RFP）

この資料でわかること

システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。

こんな方におすすめです

• 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
• 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
• 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

生成AI開発の要件定義が通常のシステム開発と異なる理由

通常のシステム開発との本質的な違い

通常のシステム開発では、「このボタンを押したらこの画面に遷移する」「この条件を満たしたらこの処理を実行する」というように、入力と出力の関係を明確に定義できます。要件を満たしているかどうかは、テストで確認できます。

しかし、AIシステム(画像認識のような従来型AIも、ChatGPT・Claude などを活用する生成AIも含む)はこれとは根本的に異なります。AIは「確率的に動作する」——つまり、同じ入力を与えても必ずしも同じ出力が返ってくるわけではありません。また、「100%の精度を保証する」こと自体が原理的に困難です。生成AIの場合はこの傾向がさらに強く、同じ質問文(プロンプト)を投げても、毎回微妙に異なる文章が生成されます。

この違いを理解しておかないと、要件定義の段階で「精度は99%以上で」「誤った回答は絶対に出ないように」と書いてしまい、開発会社から「それは実現できません」と言われる事態が起きます。

AIと通常のシステム開発の違いを整理すると、以下のようになります。

従来型AI開発と生成AIプロジェクトの違い

ここまでの比較は「通常のシステム開発 vs AI開発」という軸でしたが、AI開発の中にも「従来型AI開発(画像認識・需要予測などの教師あり学習)」と「生成AIプロジェクト(ChatGPT・Claude などのLLMを活用したプロジェクト)」という、もう一段掘り下げた違いがあります。生成AI固有の要件定義に取り組む前に、この違いを押さえておくことが重要です。

特に注意したいのは、精度の評価方法とリスクの違いです。従来型AIの要件定義で使われてきた「Accuracy 95%以上」のような定量指標は、生成AIの出力評価にはそのまま使えないケースが多く、後述する「出力評価を定性的な基準に落とし込む」という新しい観点が必要になります。

AI開発が失敗しやすい4つの理由

AI開発プロジェクトが要件定義の段階で躓きやすい理由は主に4つあります。

理由1: 「精度」の定義があいまいなまま開発が始まる

「精度は高ければ高いほどいい」という認識で発注し、開発会社も具体的な数値目標を設定しないまま開発を進めてしまうケースです。PoC終了後に「思ったより精度が出なかった」という結果になり、そもそも「何%なら合格なのか」という基準を決めていなかったため、プロジェクトの継続・中止の判断ができなくなります。

理由2: 学習データの準備が後手に回る

AIの品質はデータで決まります。要件定義の段階でデータ取得の方針を決めていなかったため、開発開始後に「社内にデータがない」「外部データを購入する必要があるが予算がない」という事態が発生します。

理由3: PoC前提の開発フローを知らない

通常のシステム開発は「要件定義→設計→実装→テスト→リリース」という直線的なフローで進みます。しかし、AI開発では「PoC(概念実証)→精度検証→本格開発」という段階的なフローが一般的です。この違いを知らずに通常のシステム開発と同じスケジュールや予算感で発注してしまうと、後になって計画の大幅な見直しが必要になります。

理由4: 生成AI特有のリスク(ハルシネーション・機密情報漏えい)を要件に落とし込めていない

生成AIプロジェクトに特有の失敗パターンとして、ハルシネーション対策やプロンプトに入力する社内情報の取り扱いを要件定義の段階で詰めずに開発を始めてしまうケースがあります。「ChatGPTだから何でもできる」という期待値のまま要件定義を進めると、本番運用後に「誤った情報を回答してクレームになった」「社外秘の情報が外部APIに送信されていた」といった問題が表面化します。これらは従来型AIの要件定義知識だけでは見落としやすいため、後述の「生成AIプロジェクトならではの要件定義ポイント」で詳しく解説します。

AI要件定義で押さえるべき5つのポイント

ポイント1: 精度要件は「許容誤差率」とビジネス指標で定義する

最もよくある失敗が、精度要件を「99%以上」「限りなく100%に近いこと」のように書いてしまうことです。AIの精度は用途によって評価指標が異なりますし、100%に近づけようとすると開発コストが指数関数的に増大します。

発注者に求められるのは、「この用途で、どの程度の誤りまでなら業務が成立するか」を定義することです。

NGな書き方の例

「画像認識の精度は99%以上であること」

OKな書き方の例

「商品の傷検知において、見逃し率(実際に傷があるのに見逃す確率)が1%以下、誤検知率(傷がないのに傷と判定する確率)が5%以下であること。この条件を満たした場合、現在の人手による検品工数が30%削減できると想定する」

ポイントは「ビジネス目標とセットで定義する」ことです。精度の数値だけでなく、その精度が達成されたときにどのような業務改善が実現するかを記載することで、開発会社も何を最優先で最適化すべきかが明確になります。

精度指標の主な種類(参考)

どの指標を使うかは開発会社と相談のうえ決定してください。要件定義書には「どの指標で何%以上を達成すること」と明記します。

なお、この「精度要件」の考え方は画像認識・需要予測などの従来型AIには有効ですが、生成AIの出力は「正解」が一意に定まらないため、Accuracy・Precision・Recallのような定量指標だけでは評価できません。生成AIプロジェクトにおける評価方法は、後述の「生成AIプロジェクトならではの要件定義ポイント」で解説します。

ポイント2: 学習データの品質・量・取得方法を合意する

「データはAIの燃料」と言われるほど、学習データの品質と量は成果を左右します。しかし、要件定義の段階でデータについて詳細を詰めておかないと、開発フェーズに入ってから「実は使えるデータがない」という致命的な問題が発覚します。

要件定義書に記載すべきデータ関連の項目は以下の通りです。

データの種類と量

• 学習に使用するデータの種類(画像・テキスト・数値データなど)
• 必要なデータ件数の見込み(開発会社と相談して決定)
• データのラベル(正解データ)付けは誰が、どのような基準で行うか

データの入手方法

• 社内に既存データがあるか(量・品質・形式)
• 社外からデータを調達する場合、購入元・コスト・利用規約
• データ収集を新たに開始する場合のスケジュールと担当者

データの品質基準

• 欠損値・ノイズ・重複データの許容範囲
• データの鮮度(いつ収集したデータまで使用可能か)
• 個人情報が含まれる場合の匿名化・仮名化の方針

社内にデータがない場合は、PoC前にデータ収集フェーズを設けることも検討してください。「データを集めながら開発する」という方針は現実的ではなく、PoCの精度に直接影響します。

なお、生成AIプロジェクトでは既存のLLM APIをそのまま利用したり、社内文書を検索対象にするRAG(検索拡張生成)方式を採用したりするケースが多く、必ずしも大量の学習データ・ラベル付けが必要になるとは限りません。ただし、RAGで参照する社内文書の整備状況(最新性・アクセス権限の整理)は別途要件として詰めておく必要があります。

ポイント3: PoC→本番の段階的開発フローを前提にする

AI開発のプロジェクト計画は、通常のシステム開発のような「要件定義→実装→テスト→リリース」という一直線のフローでは進みません。経済産業省の「AI・データの利用に関する契約ガイドライン」でも、AI開発は①アセスメント、②PoC、③開発、④追加学習の段階的なフローを推奨しています。

PoCとは何か

PoC(Proof of Concept:概念実証)とは、AI開発を本格的に始める前に「本当にAIが機能するか」を小規模で検証するフェーズです。実際のデータを使って精度目標に到達できるかを検証し、プロジェクトの実現可能性を判断します。

PoCに入る前に、以下の事項を要件定義書に明記することが重要です。

• PoCの成功/失敗を判定する基準(精度が何%以上なら本格開発に進む、など)
• PoCの期間と予算上限
• PoCが失敗した場合の撤退条件と対応方針

「PoCは成功して当然」と考えてしまいがちですが、実際のデータを試した結果「想定した精度が出ない」という場合はあります。事前に撤退条件を決めておくことで、投資の拡大を防ぐことができます。

本番移行フェーズの要件

PoCが成功した後の本格開発フェーズでは、PoC版の「動くか確認する」から「ビジネスで実際に使える」レベルへの作り直しが必要になります。要件定義書には本番システムの要件として以下を記載します。

• 処理速度・スループットの要件(何件を何秒以内に処理するか)
• 同時アクセス数・可用性要件
• エラー時のフォールバック処理(AIが判断できない場合の業務フロー)
• 段階的な本番移行計画(1部門から試験運用し全社展開へ)

ポイント4: 倫理的配慮(バイアス・公平性・プライバシー)を明文化する

AI開発において倫理的配慮は、単なる建前ではなく実務上のリスク管理です。2024年4月に公開された日本政府の「AI事業者ガイドライン(第1.0版)」でも、公平性・透明性・説明責任がAI開発の基本原則として明記されています(経済産業省)。

要件定義書に記載すべき倫理関連の項目は以下の3つです。

バイアスへの対応

AIは学習データに含まれる偏りをそのまま学習します。たとえば、採用選考AIを過去の採用データで学習させると、過去の採用パターン(特定の学校・性別が多い、など)を引き継いでしまう可能性があります。

要件定義書では「AIの判断に特定属性(性別・年齢・国籍など)が影響を与えないように設計すること」と明記し、バイアス検証のテスト項目を含めることを検討してください。

プライバシー保護

AIの学習に個人情報を使用する場合、個人情報保護法への対応が必要です。要件定義書には以下を記載します。

• 学習データに含まれる個人情報の種類と匿名化方針
• 本番運用で処理する個人情報の保存・削除方針
• 第三者へのデータ提供の有無とその条件

判断の説明可能性

AIがどのような根拠で判断したかを説明できるか(説明可能AI・XAI)は、利用者や規制当局への説明責任に関わります。特に金融・医療・採用など高リスク領域では、「なぜそのような判断をしたか」を説明できることを要件として明記することを推奨します。

ポイント5: 運用後の継続学習・モデル更新の要件を定義する

通常のシステム開発はリリースで完成しますが、AIシステムは「リリースしてから育てる」という継続的な運用が前提です。この点を要件定義の段階で合意しておかないと、本番運用が始まった後に「精度が落ちてきた」「世の中の変化に対応できていない」という問題が発生しても、誰が何をする責任があるのかが曖昧になります。

要件定義書に記載すべき運用関連の項目は以下の通りです。

モデルのモニタリング

• 精度の監視指標と監視頻度(月次・週次など)
• 精度が閾値を下回った場合のアラート基準と対応フロー

再学習・モデル更新の方針

• 再学習のトリガー条件(精度低下・データ変化・一定期間経過など)
• 再学習に使うデータの収集フロー(本番データのフィードバック方法)
• モデルバージョン管理と更新時の承認プロセス

運用体制

• AIシステムのモニタリング担当者(社内担当者 or 開発会社に委託)
• 問題発生時のエスカレーションフロー
• 年次での精度レビューと改善計画の策定サイクル

継続的な改善コストも初期費用と合わせて計画に含めてください。「初期開発費用だけ払えばあとは自動で動く」という認識は、AI開発では通用しません。

生成AIプロジェクトならではの要件定義ポイント

ここまでの5つのポイントは従来型AIにも共通する土台です。ここからは、ChatGPT・Claude などのLLMを活用する生成AIプロジェクト全体を発注する際に、プロジェクトの立ち上げ段階(発注前の要件定義)で押さえておくべきポイントを5つ解説します。

なお、プロジェクト全体ではなく、既存システムに追加する特定のAI機能(チャットボット機能・レコメンド機能など)単位で要件定義書に落とし込む場合は、機能・非機能・プロンプトの整理方法を扱った「AI機能を含む要件定義書の書き方｜機能・非機能・プロンプトを整理する5観点」で実装段階に即した観点を解説していますので、あわせてご参照ください。

ハルシネーション対策を要件として定義する

ハルシネーションとは、生成AIがもっともらしい誤った情報を生成する現象です。「精度が高い」と評判のモデルであっても、ハルシネーションを完全にゼロにすることはできません。要件定義書には、以下のような対策方針を明記することを推奨します。

• 回答の根拠となる情報源を明示させるか(出典提示・引用元リンクの表示など)
• 回答の確信度が低い場合に「分かりません」と回答させる設計にするか
• 誤情報が生成された場合の業務影響度(例: 社外向け回答か、社内向け参考情報か)
• 人間によるレビュー・承認フローを挟む工程の有無

NGな書き方の例

「AIの回答は常に正確であること」

OKな書き方の例

「回答には参照した社内文書のタイトルとリンクを必ず併記すること。確信度が一定基準を下回る場合は『情報が見つかりませんでした』と回答し、断定的な回答をしないこと」

出力評価を定性的な基準に落とし込む

従来型AIの精度評価は、正解ラベルとの一致率で機械的に測定できました。しかし生成AIの出力(文章・要約・回答)には「唯一の正解」が存在しないため、Accuracy のような単一指標では評価できません。

要件定義書には、以下のような定性評価の仕組みを記載することを検討してください。

• 評価基準(正確性・分かりやすさ・トーン・簡潔さなど)を項目化したスコアシート
• 評価を行う担当者(業務担当者・開発会社どちらが一次評価するか)と評価頻度
• 合格ラインの決め方(例: 評価項目の80%以上で「合格」とみなすサンプル数と割合)

「回答の質が良い/悪い」という感覚的な合意にとどめず、評価シートのような形式で言語化しておくことで、開発会社との認識ズレを防げます。

プロンプトに含める社内機密情報の取り扱いを定める

生成AIプロジェクトでは、社内文書や顧客情報をプロンプトに含めて回答を生成させる場面が多くあります。この際、入力した情報が外部のAIベンダーの学習に利用されないか、第三者に開示されないかを事前に確認し、要件定義書に明記する必要があります。

• 利用するLLM APIが入力データを学習に利用しない設定になっているか(オプトアウト設定の要否)
• 個人情報・機密情報をプロンプトに含めてよい範囲(マスキング・匿名化が必要な項目)
• 社内文書をRAGの参照元にする場合のアクセス権限管理(部門外秘の文書を誤って参照させない仕組み)

「社外のAIサービスに何を入力してよいか」は情報システム部門・法務部門との事前確認が不可欠です。要件定義の段階で確認が漏れると、PoC開始後に利用停止を迫られるリスクがあります。

生成物の著作権・利用範囲を確認する

生成AIが作成した文章・画像などの生成物について、著作権の扱いや二次利用の可否を要件定義書に明記しておくことも重要です。利用するLLMサービスの利用規約によって、生成物の商用利用可否や、学習データに既存の著作物が含まれるリスクの扱いが異なります。

• 生成物を自社の商用コンテンツ(記事・広告・製品説明など)にそのまま利用してよいか
• 既存の著作物と類似した生成物が出力された場合の確認・修正フロー
• 利用するLLMサービスの利用規約における著作権関連条項の確認結果

特に対外的に公開するコンテンツに生成物を利用する場合は、公開前に人間がレビューする工程を要件として組み込むことを推奨します。

従量課金によるコスト設計の不確実性を織り込む

従来型AIの多くは、開発時に一定の学習コストを支払えば、本番運用時の追加コストは限定的でした。一方、生成AIプロジェクトの多くはLLM APIの従量課金(トークン数に応じた課金)が前提となるため、利用量が増えるほど運用コストが変動します。

• 想定利用量(月間の想定リクエスト数・平均トークン数)からの月額コスト試算
• 利用量が急増した場合のコスト上限・アラート設定の要否
• プロンプトの設計(長さ・呼び出し回数)によるコスト最適化の余地

要件定義の段階でコストシミュレーションを開発会社に依頼し、想定外の請求額に驚かないよう予算計画に織り込んでおくことをおすすめします。

要件定義書の作成を支援するAIツールの活用

ここまでは「生成AIプロジェクトの要件定義に何を書くか」を解説してきましたが、近年は要件定義書の作成そのものを支援するAIツールも登場しています。要件定義を効率化するツールを探している方向けに、活用の考え方を整理します。

要件定義支援AIツールでできること

要件定義支援AIツールの多くは、対話形式のヒアリングを通じて要件を言語化する機能を持っています。担当者が箇条書きで断片的に入力した情報をもとに、AIが不足している論点(本記事で挙げたような精度要件・データ要件など)を質問形式で洗い出し、要件定義書のドラフトを自動生成する、といった使い方が一般的です。

• 要件のヒアリング項目の抜け漏れをAIが指摘してくれる
• 過去の要件定義書のフォーマットを学習させ、ドラフト作成を効率化できる
• 非エンジニアの担当者でも、専門用語を平易に言い換えながら要件を整理できる

活用する際の注意点

要件定義支援AIツールはあくまで「発注者自身の思考整理・ドラフト作成の補助」であり、本記事で解説したような生成AI固有のリスク判断(機密情報の取り扱い方針・コスト上限の設定など)を代わりに決めてくれるわけではありません。特に以下の点には注意してください。

• ツールに入力した自社の業務情報が外部に送信されるため、機密情報の入力範囲を事前に確認する
• AIが生成したドラフトをそのまま提出するのではなく、業務担当者・情報システム部門でのレビューを必須とする
• 小規模なプロジェクトであれば、ツールを使わずテンプレート(次章)をベースに手動作成する方が早いケースもある

要件定義そのものに慣れていない、あるいは複数プロジェクトを並行して進める必要がある場合は、支援ツールの導入を検討する価値があります。一方、今回が初めての生成AIプロジェクトで要件の全体像をまず自分の頭で理解したい場合は、次章のテンプレートから手を動かしてみることをおすすめします。

AI要件定義書のテンプレートと記載例

テンプレートの全体構成

以下の7章構成を基本とした要件定義書テンプレートを紹介します。プロジェクトの性質に応じて項目を追加・削除してください。生成AIプロジェクトの場合は、第7章として生成AI固有の要件をまとめることを推奨します。

第1章：ビジネス要件
第2章：精度要件(生成AIの場合は出力評価基準を含む)
第3章：データ要件
第4章：開発フェーズ計画
第5章：倫理要件
第6章：運用要件
第7章：生成AI固有要件(該当する場合)

各章の記載例

第1章：ビジネス要件(記載例)

1-1. 導入目的
現在、製品の外観検査を人手で行っており、1日に検査員3名が8時間従事している。
AIを導入し、検査工数を50%削減することを目的とする。

1-2. 解決する業務課題
・検査員の熟練度による判定ばらつき(個人差)をなくす
・繁忙期の人員確保コストを削減する
・見逃しによる不良品流出リスクを低減する

1-3. 成功の定義
以下の両条件を満たした場合、プロジェクトを成功とみなす。
・見逃し率(実際の不良を正常と判定する確率)：1%以下
・人手による検査工数：現在比50%削減

第2章：精度要件(記載例)

2-1. 評価指標
主要指標：再現率(実際の不良品をAIが正しく検知できる割合)
補助指標：適合率(AIが不良と判定したもののうち実際に不良である割合)

2-2. 目標値
PoC合格基準：再現率97%以上かつ適合率90%以上
本番合格基準：再現率99%以上かつ適合率92%以上

2-3. 測定方法
月次で過去1ヶ月分の検査データを抽出し、AIの判定結果と人手の判定結果を照合する。

2-4. 精度低下時の対応
本番運用開始後、再現率が97%を下回った場合、翌営業日中に開発会社に報告し、
2週間以内に原因分析・対応策の報告を受ける。

第3章：データ要件(記載例)

3-1. 学習データの種類
製品外観画像(JPEG形式)、正常品・不良品のラベル付き

3-2. データ件数の見込み
現在保有：正常品2,000枚、不良品300枚
PoC期間中に追加収集：不良品500枚(3ヶ月間の新規生産ラインから収集)

3-3. ラベル付けの基準
現場の品質管理担当者2名が独立して判定し、意見が一致したものを正解データとする。
意見が割れた場合は品質管理部長が最終判定を行う。

3-4. データの前処理
画像サイズの統一化・明るさの正規化は開発会社が担当する。
個人情報は含まれないため、匿名化処理は不要。

第4章：開発フェーズ計画(記載例)

4-1. フェーズ構成
Phase 1：PoC(期間：3ヶ月、予算上限：◯◯万円)
Phase 2：本格開発(PoCの成功を条件として実施)
Phase 3：段階的本番移行(1ライン → 全ライン)

4-2. PoCの成功基準
第2章の「PoC合格基準」を達成した場合、Phase 2への移行を承認する。

4-3. 撤退条件
PoC期間終了時に合格基準に到達しておらず、開発会社からの改善見通しが
「さらに3ヶ月と◯◯万円の追加投資が必要」となった場合、プロジェクトの継続を
取締役会に諮ることとする。

第5章：倫理要件(記載例)

5-1. バイアスへの対応
学習データは複数の生産ラインから収集し、特定ラインや特定時間帯のデータに
偏らないよう配慮する。開発会社はPoC完了時にデータバイアスの分析結果を報告すること。

5-2. プライバシー
本システムの学習データ・本番データに個人情報は含まれない。
(将来的に作業者の行動データを活用する場合は別途プライバシー影響評価を実施する)

5-3. 判断の説明可能性
AIが「不良品」と判定した場合、その根拠(どの部位に異常があるか)を
画像上でハイライト表示する機能を要件とする。

第6章：運用要件(記載例)

6-1. モニタリング
月次で再現率・適合率を計測し、開発会社が翌月5営業日以内に報告書を提出する。

6-2. 再学習の方針
以下のいずれかを満たした場合、再学習を実施する。
・再現率が本番合格基準(99%)を下回った場合
・製品の仕様変更・材料変更が生じた場合
・年1回の定期再学習(新規蓄積データを使用)

6-3. 運用体制
・社内担当：生産技術部◯◯氏(AIシステムの日次モニタリングと報告受領)
・開発会社：◯◯社(モデルの保守・再学習・バージョン管理)
・エスカレーション：精度低下アラート発生 → 社内担当が開発会社に連絡
  → 48時間以内に一次回答 → 2週間以内に対応完了

第7章：生成AI固有要件(記載例)

7-1. ハルシネーション対策
回答生成時は必ず参照した社内文書のタイトルとリンクを提示すること。
確信度が一定基準を下回る場合は「回答できません」と表示し、断定的な回答をしないこと。

7-2. 出力評価基準
正確性・分かりやすさ・トーンの3項目を5段階で評価するスコアシートを用い、
月次で社内担当者20件をサンプル評価し、平均スコア4.0以上を合格ラインとする。

7-3. 機密情報の取り扱い
利用するLLM APIは入力データを学習に利用しないオプトアウト設定を必須とする。
顧客の個人情報はプロンプトに含める前にマスキング処理を行う。

7-4. コスト上限
月間API利用料の上限を◯◯万円とし、80%到達時点で担当者にアラート通知する。
上限に達した場合は利用を一時停止し、原因調査後に再開する。

開発会社に伝えるべき情報チェックリスト

最低限伝えるべき10項目のチェックリスト

開発会社への初回相談・RFP送付前に、以下の10項目を用意しておくと、精度の高い提案書と見積もりを受け取りやすくなります。

精度の高い提案を受けるための追加質問

上記10項目を揃えた上で、開発会社への相談時に以下の質問を投げかけると、提案の質が上がります。

精度に関する質問

• 「今回のデータ量と課題内容で、PoC段階でどの程度の精度が期待できますか?」
• 「精度改善に最も重要なのは何でしょうか(データ量・データ品質・モデルアーキテクチャなど)?」

開発フローに関する質問

• 「PoC成功の判断基準を一緒に決めていただけますか?」
• 「PoC期間中、進捗と精度はどのように報告してもらえますか?」

コストに関する質問

• 「初期開発費用のほかに、継続的な保守・再学習費用はどの程度かかりますか?」
• 「データのラベル付けや収集のサポートはしていただけますか?追加費用はかかりますか?」

リスクに関する質問

• 「このプロジェクトで最も失敗リスクが高い要因は何だと思いますか?」
• 「PoCが失敗した場合、どのような対応をしていただけますか?」

生成AI固有の質問

• 「ハルシネーション対策として、どのような仕組みを標準で用意していますか?」
• 「入力したプロンプトのデータは、貴社や利用するLLMベンダーの学習に使われますか?」

まとめ — AI要件定義セルフチェックリスト(発注者向け)

最後に、本記事の内容を自己確認できるチェックリストをまとめます。開発会社への提案依頼前にご活用ください。

精度要件

• 「精度は高ければ高いほどいい」ではなく、ビジネス目標とセットで精度目標を定義している
• 用途に応じた精度指標(適合率・再現率など)を選定している
• PoC合格基準・本番合格基準を数値で定義している

データ要件

• 学習データの種類・量・保有状況を把握している
• データがない場合、収集フェーズの計画と予算を確保している
• ラベル付けの基準と担当者を決定している
• 個人情報が含まれる場合、匿名化方針を決定している

開発フェーズ計画

• PoCフェーズを前提とした計画になっている
• PoCの成功基準・撤退条件を明記している
• Phase 1(PoC)とPhase 2(本格開発)の予算を分けて確保している

倫理要件

• 学習データのバイアスリスクを検討している
• 個人情報の取り扱い方針を決定している
• 判断の説明可能性(どのような根拠で判断したかを説明できるか)を要件として検討している

運用要件

• 精度のモニタリング頻度と担当者を決定している
• 再学習・モデル更新のトリガー条件を定義している
• 継続運用のコストを予算計画に含めている

生成AI固有要件

• ハルシネーション対策(出典提示・確信度が低い場合の挙動)を定義している
• 出力評価の定性的な基準とレビュー体制を定めている
• プロンプトに入力する社内機密情報の取り扱い方針を決定している
• 生成物の著作権・商用利用可否を確認している
• 従量課金コストの上限とアラート方針を定めている

AI要件定義で最も重要なのは「通常のシステム開発とは違う」という前提を持ち、AI特有の項目を意識的に詰めておくことです。特に生成AIプロジェクトの場合は、従来型AI開発の知識だけでは見落としやすいハルシネーション対策・出力評価・機密情報の取り扱い・著作権・コスト設計の5点が、後から修正するコストの大きい要注意ポイントです。発注前の段階でしっかりと議論することをおすすめします。

—Free Download / 資料ダウンロード

【サンプル】システム開発 提案依頼書（RFP）

この資料でわかること

システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。

こんな方におすすめです

• 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
• 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
• 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。