AI開発を初めて依頼する時は、見積もりの前に何を渡せばよいかで止まりやすいです。機能名だけを並べても、開発側は対象業務、利用者、入力資料、人の確認、失敗時の戻し方を判断できません。AI開発の要件定義は、機能名の羅列ではなく、業務の入力と出力、人の確認、合格条件、止め方を開発側とそろえるための依頼整理です。
最初にそろえる範囲を一枚に置くと、直接開発に進む相談なのか、実業務を使った整理から始める相談なのかを分けやすくなります。旅行用ポーチP-01の商品資料から台本初稿までの設計例を使い、RFPへ広げる前に埋める項目を判断できます。
AI開発の要件定義は何を決める場か
AI開発の要件定義では、作りたい機能の名前より先に、どの業務で誰が使い、何を渡し、何を受け取り、どこから先を人が判断するかを決めます。発注者側の成果物としては、開発会社に任せたい作業だけでなく、任せない範囲や確認者も同じ紙面に置くと、相談の粒度がそろいます。
決めるのは機能名より業務の境界
最初に置くのは目的です。売上を伸ばしたい、作業を短くしたいという広い言葉だけではなく、どの対象業務で使うかまで絞ります。次に利用者を決め、日常的に入力する人、出力を見る人、承認する人を分けます。
入力は、AIに渡す資料や条件です。出力は、AIから受け取りたい初稿、分類結果、確認点などです。対象外は、自動公開、入稿、法務判断、根拠のない効果追加のように任せない作業です。確認者は、商品事実、禁止表現、媒体適合、最終承認のどれを見るかで分けます。
NISTのAI RMF Playbookは、AIシステムの意図した目的、利用状況、利用者、期待、運用環境、人間の監督に関する役割を理解し文書化する観点を示しています。（NIST AI RMF Playbook）発注者側の要件定義でも同じように、目的、対象業務、利用者、入力、出力、対象外、確認者を順に置くと、機能名だけでは見えない業務の境界が見積もりに反映されやすくなります。
RFPと見積もり依頼との違い
要件定義書は、システムが満たす要求と条件を開発側と合意して残す文書です。初回相談へ持ち込む記入表はそのたたき台であり、正式な合意済み文書とは分けます。RFPは、複数社に同じ条件で提案を求める時に使う依頼文書です。PoC計画は、実装を広げる前に何を試し、どの条件なら進めるかを決める計画です。見積もり依頼は、範囲、前提、成果物を渡して費用と進め方の提示を求める連絡です。
横にスクロールして比較できます
| 書類 | 使う場面 | 決めること | 残す余地 |
|---|---|---|---|
| 要件定義書 | 開発する内容の合意 | 要求と制約と受入条件 | 詳細な実装方法 |
| RFP | 複数社の提案比較 | 提案条件と評価観点 | 各社の提案内容 |
| PoC計画 | 本開発前の検証 | 入力と合格条件 | 改善案と継続判断 |
| 見積もり依頼 | 費用と体制の確認 | 対象範囲と前提条件 | 代替案と段階分け |
発注者の比較案としては、要件定義書をRFPの小型版にしないことが大切です。RFPの全文書式や契約条件まで広げる前に、入力、出力、対象外、確認者、合格条件をそろえるだけでも、相談内容は具体化します。特に初めてのAI開発では、書類を厚くするより、判断が分かれる点を表にして残す方が会議で使いやすくなります。
見積もり依頼だけを先に出すと、開発側は前提を仮置きして答えることになります。対象業務が曖昧なままでは、安い見積もりに見えても、人が確認する工程や資料更新時の扱いが抜けることがあります。依頼前の要件定義は、金額を決める作業ではなく、見積もりの前提を発注者側で見える形にする作業です。
AI開発で余白を残す理由
AI開発では、最初からすべてを固定しすぎると、実際の資料や出力の揺れに合わせた調整がしにくくなります。AnthropicはAIエージェントの構築について、できるだけ単純な解から始め、必要な時だけ複雑さを増やす考え方を示しています。（Building Effective（公式））発注者側の要件定義でも、最初から大きな自律処理を前提にせず、業務の境界と確認点を先に置く方が進めやすくなります。
余白を残すことは、何も決めないことではありません。試す余地を残すために、先に固定するのは入力、期待出力、合格条件、止める状態です。Anthropicの評価設計では、評価はAIに入力を与え、出力へ採点ロジックを適用して成功を測るテストとして説明されています。（Demystifying evals（公式））PoC計画でも同じように、何を作れるかではなく、どの入力で何を確かめるかを先に決めます。
PoCを万能の逃げ道にすると、検証後に何が進捗したのかが曖昧になります。AIの出力は試行ごとに揺れるため、期待出力と確認方法を置かない検証では、印象だけで判断しやすくなります。発注者側で合格条件を粗くでも分けておくと、開発側は単発のデモではなく、複数の試行や失敗時の戻し方を含めて設計できます。
業務と資料を一枚にそろえる流れ
AI開発の要件定義では、会議に持ち込む情報を機能名ではなく業務の線として並べます。商品資料から台本初稿を作る業務なら、どの商品をどの媒体で扱い、どの版の資料を根拠にし、どの表現を避けるかまでが入力になります。
商品資料から初稿までの線
承認済み商品資料は、社内で使ってよい版として確認された商品説明、仕様、注意点のまとまりです。入力には会社商品ID、媒体、承認済み商品資料、版、禁止表現を置きます。AIに渡す情報を増やしすぎると判断の焦点が散るため、必要な情報を選んで渡す設計が重要です。（Effective context （公式））Anthropicの文脈設計の説明でも、望む結果に近づけるには高信号の情報を小さく保つ考え方が示されています。
出力は台本の初稿だけにしない方が安全です。採用資料IDは、初稿がどの承認済み資料を根拠にしたかを示す識別子として扱います。あわせて、商品名の確認、表現の言い換え、媒体上の制約など、人が判断すべき要確認点を返す形にします。これにより、文章が自然かどうかだけでなく、根拠にした資料の版を確認できます。
この線に入らない作業は、要件定義の段階で外します。自動公開、媒体への入稿、入力資料にない効能や成果の追加は、台本初稿を作る業務とは別の責任を伴います。初稿生成の依頼では、承認済み資料に基づいて書き、人が確認すべき点を残すところまでを範囲にすると、見積もりと受入確認が具体化します。媒体別の調整も、資料にある事実をどう見せるかに限るため、効果の追加や販売成果の断定とは切り分けられます。
人が見る点を先に置く
業務責任者は、商品事実として使ってよい範囲を決めます。推進担当は、会社商品ID、媒体、資料の版、禁止表現がそろっているかを見ます。確認者は、初稿が承認済み資料から外れていないか、媒体に合う言い方になっているかを確認します。NISTのAI RMF Playbookでは、利用者の種類、期待、運用時の役割、維持や更新に責任を持つ人を文書化する観点が示されています。（NIST AI RMF Playbook）
運用担当は、資料が更新された時にどの初稿を再確認へ戻すかを扱います。商品事実、禁止表現、媒体適合、変更後再承認を一つの承認でまとめると、どこで止めるべきかが曖昧になります。役割ごとに見る点を分けておくと、AI開発の流れは自動化の範囲と人の判断の範囲に分かれます。商品事実の確認は業務責任者、媒体の読みやすさは確認者、資料更新後の差し戻しは運用担当というように、見る観点を分けておくと受入ケースの判定も安定します。
この分け方は、社内体制を増やすためではありません。承認済み商品資料の事実を守る人、禁止表現を守る人、媒体で読める文章に直す人、資料更新後に再承認へ戻す人を決めるためです。初稿の良し悪しを一人の感覚に寄せず、どの観点で差し戻すかを決められます。AIが返した文章をそのまま採用する前提ではなく、どの人がどの根拠を見て止めるかを業務に組み込みます。
足りない資料で止める分岐
資料状態は、現行資料あり、旧版のみ、別商品、未承認版、資料更新に分けます。現行資料ありなら、承認済みの版を根拠に初稿と採用資料IDを返します。別商品が混ざる場合は、対象の商品IDと合う現行資料だけを採用する分岐が必要です。架空商品P-01の実行では、旧版と別商品が混在しても現行承認資料を参照できたため、商品IDと版の照合を分岐に入れる意味があります。
旧版のみ、または未承認版しかない場合は、商品事実を返さず確認待ちにします。架空商品P-01の旧版と未承認版だけを使った実行では、全資料を渡す方式でも選択後の資料だけを渡す方式でも確認待ちになり、商品事実は返されませんでした。資料JSONは全資料で551文字、選択後で16文字まで絞られていましたが、資料が少ないこと自体より承認済みの現行資料がないことが停止理由になります。資料が足りない時の正解は、無理に初稿を作ることではなく、根拠が不足している状態を返すことです。
資料更新の分岐では、新しい承認版を採用できるかと、文章として受け入れられるかを分けます。架空商品P-01を新しい承認版へ更新した実行では、全資料を渡す方式でも選択後の資料だけを渡す方式でも新しい承認版を参照できました。一方で、選択後の初稿には仕様外の表現が混入したため、参照IDが追えても文章全体を合格にしない判断が必要です。採用資料IDの確認と文章品質の確認を分けると、資料参照だけは正しいが表現は差し戻すという判定を残せます。
この分岐を先に置くと、AI開発の要件定義は資料がそろった時だけ進む設計になります。現行資料があれば初稿へ進み、旧版や未承認版だけなら確認待ちへ戻し、更新後は採用資料IDと文章品質を別々に見ます。資料不足を失敗として隠さず、停止位置として扱うことが、業務に入れられるAI開発の流れを作ります。
旅行用ポーチP01で埋める依頼の形
旅行用ポーチP-01は、実顧客資料ではない架空商品の設計例です。要件の粒度は、商品名ではなく利用者、入力、出力、対象外、確認者、停止状態、資料更新時の再確認までそろえる形にします。
十項目の記入済みシート
対象外とは、AIに任せない作業や成果物に含めない処理を先に外へ出す欄です。P-01の設計例では、自動公開、入稿、資料にない効果の追加を対象外に置くことで、台本初稿の生成と広告運用の実行を混同しない形にします。
変更後再承認とは、商品資料の版が変わった時に、古い出力をそのまま使わず、確認者が再び見て採否を決める扱いです。AI開発の要件定義では、正常に作れる条件だけでなく、版の変更時に何を再確認するかまで置くと、見積もり時の処理範囲が具体になります。
P-01の入力は、会社商品ID、媒体、承認済み商品資料、版、禁止表現に分けます。出力は、初稿、採用資料ID、要確認点に分け、商品事実の抽出と文章としての採否を同じ合格にまとめない形にします。
この十項目を埋めると、商品資料がある時に進む処理と、旧版や未承認版しかない時に止まる処理を同じ表で確認できます。P-01では、利用者はSNS広告の制作担当、確認者は商品事実と禁止表現を見られる担当者、運用担当は資料版と出力と採否を記録する担当者として分けます。
横にスクロールして比較できます
| 項目 | 記入例 | 確認の観点 |
|---|---|---|
| 利用者 | 制作担当が国内SNS向けの商品紹介台本の初稿を作る | 利用者は誰かと利用目的が一致するか |
| 入力 | 会社Aの商品P-01と媒体名と承認済み資料P01-v2と表現ルール | 会社・商品・市場・承認状態・資料の版を照合できるか |
| 出力 | 初稿と採用資料IDと要確認点 | 初稿の主張を採用した資料へ戻って確かめられるか |
| 対象外 | 自動公開と入稿と資料にない効果の追加 | 利用者が公開済みだと誤認しないか |
| 確認者 | 商品事実を確認する担当者と公開可否を決める責任者 | 兼任する場合も判断する観点を区別できるか |
| 正常時 | 現行承認資料を参照して初稿と確認点を返す | 資料IDだけでなく本文の数値や表現も一致するか |
| 情報不足 | 現行承認版がない時は不足項目を返して確認待ちにする | 推測で商品事実を埋めず処理を止められるか |
| 更新 | 新しい承認版を参照して使用した資料IDを残す | 旧版に基づく出力を識別できるか |
| 変更後再承認 | 資料や初稿が変わったら以前の承認を流用しない | 確認者が変更箇所と根拠を見直せるか |
| 運用担当 | 資料更新と問い合わせと不具合時の復旧を担当に割り当てる | 不在時の代行先と連絡方法を決めてあるか |
混在資料で参照IDを見る
採用資料IDは、出力がどの承認済み資料を根拠にしたかを後から確認するための印です。P-01の旧版と別商品が混在する状態でも、現行承認資料を参照できるかを見れば、商品事実の取り違えを早い段階で分けられます。
P-01の旧版と別商品が混在した実行では、全資料を渡す方式と選択後の資料だけを渡す方式のどちらでも、現行承認資料P01-v2を参照しました。この確認は固定した指示とモデル設定で各条件を一度ずつ実行した小規模試験です。資料の参照先と停止状態を記録しており、費用、人の確認時間、制作全体の短縮効果は測っていません。
この実行では、全資料5件を渡す形と、選択後1件へ絞る形が比べられています。資料JSONの量は909文字と193文字で異なりますが、どちらも参照先はP01-v2でした。
要件定義では、混在資料を一度でも正しく処理できたことを、すぐに運用品質の保証へ広げない方が安全です。受け入れる範囲は、P01-v2の参照、別商品の不採用、旧版を根拠にしないこと、要確認点が残ることのように、確認できる単位へ分けます。
資料更新後に再び確かめる
資料更新後は、参照IDが追えていても文章全体を合格にしない場面があります。P-01の新しい承認版へ更新した実行では、全資料を渡す方式と選択後の資料だけを渡す方式のどちらでも現行承認資料P01-v3を参照しましたが、選択後の初稿に仕様外の表現が混入しました。
この場合、事実抽出の合格と文章品質の合格を分けて扱います。参照IDが正しいことは商品資料の取り違えを防ぐ条件ですが、禁止表現や仕様外表現が混じらないことは別の合格条件です。
更新時の実行では、全資料6件を渡す形と、選択後1件へ絞る形が比べられています。資料JSONは1087文字と193文字で異なり、どちらもP01-v3を参照できましたが、仕様外表現が混入したため文章全体の合格ではありません。
AIエージェントの評価では、入力、成功条件、試行、採点の観点を分ける考え方が示されています。（Demystifying evals（公式））P-01でも、現行資料を参照できたか、旧版で止まれるか、仕様外表現を避けられるか、確認者が採否を決められる記録が残るかを別々に見ます。
変更後再承認を要件に入れる理由は、資料更新が起きるたびに同じ入力条件で確かめ直すためです。P01-v3で参照IDを追えた結果だけを根拠にせず、文章全体の採否を確認者が分けて判断できるようにしておくと、開発側へ渡す合格条件が曖昧になりません。
発注前に合否を分ける基準
発注前の合否は、AIが一度それらしい文章を出せるかではなく、同じ業務条件で受け入れてよい出力と止めるべき出力を分けられるかで見ます。受入ケースとは、正常時、情報不足、確認待ちなどの状態を分け、入力、期待出力、確認方法をひとまとまりにした試験用の場面です。
受入ケースを五つに分ける
商品資料から台本初稿を作る業務では、現行資料がある場合だけを正常系にします。旧版のみ、別商品、未承認版、資料更新を同じ正常系に混ぜると、商品事実を使ってよい状態と確認待ちにすべき状態が曖昧になります。
架空商品P-01の旧版と未承認版しかない条件では、固定した設定と指示で各一回実行した結果、全資料を渡した方式でも選択後の資料を渡した方式でも確認待ちになり、商品事実は返されませんでした。これは架空データによる小規模試験の結果です。顧客環境での導入実績や、人が初稿の採用を決めた結果ではありません。
現行資料がある場合の確認方法は、出力された初稿の文章だけを読むのでは足りません。採用した資料のID、禁止表現の扱い、要確認点の残り方を見て、台本として使えるかと商品事実を誤って進めていないかを分けて判断します。
- 現行資料あり: 現行の承認済み資料を参照し、初稿と採用資料IDと要確認点を返す。確認方法は資料IDと商品事実と禁止表現の照合。
- 旧版のみ: 商品事実を使った初稿に進まず、確認待ちを返す。確認方法は旧版だけで現行版がないことの表示と停止状態の確認。
- 別商品: 対象商品と違う資料を採用しない。確認方法は会社商品IDと採用資料IDが一致しない時に進まないことの確認。
- 未承認版: 承認済みとして扱わず、確認待ちを返す。確認方法は承認状態の扱いと初稿を出さない動作の確認。
- 資料更新: 更新後の承認版を参照し直す。確認方法は新しい資料IDの参照と、仕様外表現が混入していないかの文章確認。
評価は入力と答えを固定する
合格条件とは、出力を受け入れるために満たすべき具体的な判定です。AIエージェントの評価では、ひとつのテストケースに定義済みの入力と成功条件を置き、出力へ採点ロジックを適用して成功を測る考え方が示されています。（Demystifying evals（公式））
発注前の整理では、入力、期待出力、合格条件、複数試行の有無を別々に書きます。（Demystifying evals（公式））未実施の合格率や作業時間を置く必要はなく、商品事実を拾えたか、停止すべき条件で止まったか、文章品質を人が確認できる形かを確認方法として固定します。
同じ検証をやり直せる記録
同じ検証をやり直すには、入力資料の版、指示文、モデル設定、試行回数、出力、担当者の採否をセットで残します。評価の記録は、出力文だけでなく試行の全体記録や最終状態を扱う考え方と相性がよく、あとから資料や設定を変えた時の差分を見やすくします。（Demystifying evals（公式））
モデルや資料を変えたら、同じ五つの受入ケースを再実行して比べます。現行資料の参照は維持できているのに仕様外表現が混入することもあるため、参照ID、停止動作、文章品質、確認工数を一つの高品質という言葉にまとめず、別々の採否欄で見ます。
AI開発の要件定義でよく迷う境界
- どこまで決めればよいか
- AI開発の要件定義では、入力、出力、対象外、確認者、合格条件、止める状態までを決めると相談が具体化します。入力は何を渡すか、出力は何を返してほしいか、対象外は何を自動化しないかです。確認者は最終判断を持つ人だけでなく、途中で商品事実や禁止表現を見る人も分けます。 例えば「商品情報を正しく使う」だけでは、旧版しかない場合の動作が決まりません。「現行承認版がなければ初稿を作らず、対象商品と不足資料を返す」と書けば、入力を用意して確かめられます。画面の見た目やモデル選定に未決定事項が残っていても、期待する動作と人へ戻す条件から開発側と話を進められます。
- 三要素にすると何か
- この依頼準備では、AI開発の要件定義を業務、資料、評価の三つに分けると扱いやすくなります。業務は誰がどの場面で使い、どの判断を人に戻すかです。資料はAIに渡す商品情報、版、禁止表現、参照すべき情報の範囲です。 評価は、入力に対して期待する出力と合格条件を決める部分です。Anthropicの評価設計では、AIシステムに入力を与え、出力へ採点ロジックを適用して成功を測る構造が説明されています。さらに、ひとつのテストは定義された入力と成功条件を持つタスクとして扱われ、出力の揺れを踏まえて複数試行を使う考え方も示されています。
- RFPはいつ必要か
- RFPは、複数社へ同じ条件で提案を求める時や、調達上の比較条件をそろえる時に必要になります。要件定義で業務とシステムの要求を具体化するのに対し、RFPは候補企業へ同じ前提を渡し、提案範囲、体制、費用、進め方を比べるための依頼文です。 初回相談の前からRFPの全項目を埋めようとすると、未検証の実装方法まで固定しやすくなります。まずは、対象業務、使う資料、期待する出力、対象外、確認者、受入ケースを一枚にそろえると、RFPへ進むべきか、PoCや設計相談で確かめるべきかを分けやすくなります。RFP前の設計例は、発注書式ではなく、相談内容を具体化するための下書きとして使います。
カスタム開発へ相談する時に渡すもの
直接進める相談の材料
相談時は、入力に使う商品資料、現在の台本、担当者が直した箇所を一組持ち込むと話を具体化できます。例えば「幅の数値が旧版のまま残る」「承認されていない効果を足してしまう」といった戻し理由を、実際の入力と出力に対応づけます。どの工程を短くしたいかだけでなく、何を残して確認したいかを同じ場で共有するためです。
SynClipは広告・制作業務を起点に企業固有のカスタム開発と共創へつなぐ立ち位置です。商品資料から広告初稿を作る業務なら、どの資料を根拠にし、どの出力を受け取り、どこから先を人が確認するかを一緒に扱います。広告制作AIの既存支援と、企業ごとの業務に合わせた追加開発は同じものとして扱わず、相談内容に合わせて分けて考えます。
整理が必要な時の進み方
業務の入力、期待する出力、確認者、受入ケースがそろっていれば、それをもとに開発範囲を相談できます。資料の版や判断者が決まっていない場合は、実業務を使った整理から始める選択肢があります。SynClipの研修やワークショップも、必要に応じてその準備に利用できます。受講をすべての開発依頼の前提にする必要はありません。
整理の会議では、制作担当がいつも使う商品資料と、修正前後の台本を並べる方法が考えられます。開発側へ「良い台本」の説明を続けるだけでなく、どの一文をなぜ変えたかを示します。理由が商品事実の誤りなのか、媒体に合わない長さなのか、ブランドの言い方なのかを分けると、実装する判定と人が残す判断を決めやすくなります。
整理の進め方として、商品資料の版が不明な箇所、判断が一人に集中している箇所、停止条件が決まっていない箇所を記入表に残す方法が考えられます。会議の最後に未決項目ごとの確認担当と次に用意する資料を決めます。実装範囲を広げる前に、最初の業務単位で入力と人への戻し方を具体化するための著者の提案です。
Orbit基盤で始める範囲
OrbitマーケティングOSは、SynClipが顧客コンテキストの収集、登録、整備から業務実装へ進むプロジェクトの基盤として扱うものです。広告制作の実務では、商品資料、ブランドの言い方、禁止表現、媒体ごとの使い分けが出力品質に直結します。Anthropicの文脈設計では、LLMに渡す情報を有限の資源として扱い、望む出力に必要な信号を選ぶ考え方が示されています。（Effective context （公式））
初期の進め方としては、コンテキスト整備から最初の1ユースケースの制作実行エンジンと業務アプリケーションまでをつなぐ提案になります。SynClipは最初の1ユースケースの制作・実行エンジンと業務アプリケーションを含む初期プロジェクトを1〜3ヶ月を目安に提案する方針であり、範囲と期間は個別に決めます。この目安は納期保証ではなく、扱う資料、承認者、既存業務との接続範囲に応じて調整するための起点です。
最初の対象を商品資料から台本初稿までに区切った場合、素材選定や編集への接続は次の開発候補として分けて見積もれます。商品や訴求の意味がチーム間で揃わない場合は、オントロジーの拡張を検討する余地もあります。いずれも最初から一括で導入する前提ではなく、初期の業務で確認できた品質と担当者の負担を見て、次に整える範囲を決めます。
