AIエージェントの要件定義｜そのまま使える7項目の記入例と、設計レビューで見る観点

画面と機能の一覧だけでは足りない

AIエージェントの要件定義でつまずくのは、書く項目が分からないからというより、従来のシステム要件定義と同じ形式で書き切れてしまうからです。画面、機能、データ項目、権限。ひととおり埋まった要件定義書ができあがり、それを渡して実装が始まり、動いたものを見て初めて「これでは業務に使えない」と分かります。

足りない理由は3つあります。

第一に、入力が自然言語で揺れます。同じ依頼でもメールの書き方は人によって違い、必要な項目が本文にある場合も、添付ファイルにある場合もあります。入力の形式を固定できる前提が崩れるため、「どんな入力を受け付けるか」ではなく「どこまでを対応範囲とし、どこからを対象外として扱うか」を書くことになります。

第二に、出力が毎回同じにはなりません。同じ入力を2回通したとき、文面の言い回しが変わることがあります。従来のシステムなら不具合ですが、生成AIを使う処理では前提です。そのため、合っている・間違っているの判定基準を、どの項目がどう一致していれば正解とするかの形で決めておく必要があります。

第三に、途中で人が承認を挟みます。AIが出した結果をそのまま確定させる処理はほとんどなく、たいていはどこかに人の確認が入ります。この承認をどこに置くかで、業務の流れも、削減できる時間も変わります。承認を後付けで足すと、AIが処理した後に人が全件見直す形になり、手間が減りません。

開発全体の進め方は AIエージェント開発の進め方 にまとめています。この記事はそのうち、実装の前に書き出しておく項目に絞って扱います。項目ごとに、要件定義書によく出てくる書き方と、実装と検証に渡せる形へ直した書き方を並べているので、手元の文書と見比べながら読めます。

要件定義の進め方と、ツールで済ませられる範囲

書き始めるときに最初に探すのは、たいてい書式です。社内のテンプレートを引っぱり出すか、生成AIに雛形を出させるところから入ることになりますが、そこで手に入るのは器のほうです。全体は次の4段階で進み、ツールが肩代わりできるのは前半に偏ります。

段階	ツールや生成で済ませられること	人が決めないと埋まらないこと
書式をそろえる	項目の雛形を出す。空欄のまま残っている欄を洗い出す	社内の既存書式に合わせるか、項目を足すか
現状を書き出す	聞き取りのメモから業務の流れを下書きする	書き出した手順が実際の順番と合っているかの確認
範囲と合格ラインを決める	ほぼ無い	対象外にする例外、承認をどこに置くか、誤りの種類別の許容度
接続と権限を詰める	接続先の仕様書から必須項目を書き出す	どのシステムへ読み取りだけで入るか、書き込みまで行うか

生成AIに要件定義書の雛形を出させると、項目名は一通り並びます。埋まらないのは中身のほうです。対象外にする例外も、どの誤りなら許容できるかも、業務を回している人しか答えられません。ツールで短くできるのは、書式をそろえる時間と、書いたものを見直す時間です。決める時間は短くなりません。 雛形が出た時点で要件定義が終わったつもりになると、項目は埋まっているのに判定できない文書が実装へ渡ります。

順序としては、対象範囲を先に固め、入力と出力を確定させ、そのうえで合格ラインと運用時の扱いを埋めます。どの欄を誰に聞けば埋まるかは、7項目を見たあとの節で扱います。

埋める項目は7つ

要件定義書の形式は社内のものに合わせて構いません。項目として次の7つが埋まっているかを見ます。

項目	書けていないと起きること	確認の仕方
対象業務と適用範囲	検証中に対象が広がり、いつまでも合格判定に届かない	対象外の業務を名指しで書けているか
入力	想定外の形式が届いて処理が止まる	届くチャネルと形式を実物で数えたか
出力	書き込み先の項目が埋まらず、手作業の転記が残る	出力先の必須項目を全部並べたか
AIが決めてよい範囲	人が全件見直すことになり、時間が減らない	承認する人と、承認の単位を書いたか
参照情報とその置き場所	古い資料を根拠に回答する	更新する人と更新の頻度を書いたか
失敗したときの扱い	止まったことに誰も気づかない	差し戻し先と通知先を書いたか
完成の判定基準	本番へ進めてよいか判断できない	サンプル件数と誤りの種類別の許容度を書いたか

以下、項目ごとに見ていきます。

1. 対象業務と適用範囲

• 悪い書き方：問い合わせ対応業務全般を対象とする
• 直した書き方：共有メールアドレスに届く問い合わせのうち、既存取引先からの納期確認と仕様確認を対象とする。新規の見積依頼、クレーム、請求に関する連絡は対象外とし、担当者のキューへ回す

対象外を名指しで書けているかが分かれ目です。書いていないと、検証中に「これも処理できないのか」という指摘が積み上がり、範囲が広がり続けます。範囲が動く限り、合格ラインには届きません。

対象業務の選び方そのものに迷いがある段階なら、要件定義の前に候補の絞り込みが要ります。判断の材料は 生成AIのPoCが進まない にまとめています。

2. 入力（どこから何が届くか）

• 悪い書き方：メールおよび各種ファイルを入力とする
• 直した書き方：共有メールアドレス宛の本文とPDF添付を入力とする。1通あたりの添付は5件まで。画像として貼り付けられた表、パスワード付きファイル、手書きの書類は対象外とし、そのまま担当者へ転送する

入力の欄で必要なのは、想定するすべての形式を列挙することではなく、対応しない形式を宣言することです。実物を1か月分集めて、形式ごとの件数を数えると決めやすくなります。件数が数件しかない形式は、無理に対応範囲へ入れず、人が処理する側に残します。

チャネルも書きます。メールなのか、共有フォルダに置かれるのか、既存システムから連携されるのか。ここが決まらないと、認証と権限の設計に入れません。

3. 出力（どこへ、どの形式で書き込むか）

• 悪い書き方：結果を管理システムへ反映する
• 直した書き方：管理システムの案件レコードへ、件名・取引先コード・希望納期・確認事項の4項目を書き込む。取引先コードが特定できない場合は書き込まず、未確定として担当者のキューへ入れる

出力先の必須項目をすべて並べると、AIだけでは埋まらない項目が見つかります。上の例なら取引先コードがそれで、社内マスタとの突き合わせが要ります。この作業を要件定義の時点で洗い出しておかないと、実装後に「あと1項目だけ手で入れている」状態が残ります。

書き込む形式も決めます。既存のレコードを更新するのか、新規に作るのか、下書き状態で作るのか。下書きとして作れる仕組みが出力先にあるかどうかで、承認の置き方が変わります。

4. AIが決めてよい範囲と、人が確定させる範囲

• 悪い書き方：最終的な判断は人が行う
• 直した書き方：分類と項目の抽出、返信文の下書きまでをAIが行う。取引先への送信、金額の確定、納期の確約は人が確定させる。承認は1件ずつ画面上で行い、下書きのまま2営業日を過ぎたものは担当者へ通知する

「最終的な判断は人が行う」と書いてあっても、誰が、何を見て、どの単位で承認するかが決まっていなければ設計できません。1件ずつなのか、まとめてなのか。承認する人が見る画面はどこか。承認しなかった件はどこへ戻るのか。

5. 判断に使う参照情報と、その置き場所

• 悪い書き方：社内のマニュアルやFAQを参照して回答する
• 直した書き方：共有ドライブの製品仕様書と、管理システムの取引先マスタを参照する。仕様書は製品管理の担当が更新し、更新の反映は日次とする。参照した資料名を出力に併記する

参照する資料を書くだけでなく、それが誰の手で更新されるかまで書きます。更新されない資料を根拠にすると、動き始めてしばらくは正しく、半年後に古い内容を答えるようになります。どこまでを検索させ、どこからをモデルに覚えさせるかの選び方は RAGとファインチューニングの違い で扱っています。

参照した資料名を出力に残すことも要件に入れます。間違った回答が出たとき、指示の書き方の問題なのか、参照した資料が古かったのかを切り分けられます。

6. 失敗したときの扱い

• 悪い書き方：エラー時は適切に処理する
• 直した書き方：接続先の応答がない場合は5分間隔で3回まで再実行する。3回を超えたら処理を止め、担当チャネルへ通知する。判断できずに差し戻した件が20件を超えたら、同じチャネルへ通知する

決めるのは、差し戻し先、再実行の可否と回数、そして件数の上限の3つです。とくに件数の上限は抜けやすい項目です。1件ずつの失敗は目に付きませんが、差し戻しが積み上がっているのに誰も見ていない状態は、動いているつもりで止まっているのと変わりません。

通知の宛先も個人名ではなくチャネルにします。担当が変わったときに通知が届かなくなるのを防げます。

7. 完成の判定基準

• 悪い書き方：精度90%以上を達成すること
• 直した書き方：直近3か月の実データから無作為に100件を抽出し、次を満たすことを合格とする。取引先コードと希望納期の抽出が95件以上一致すること。対象外と判定すべき件を対象内として処理した誤りが0件であること。返信文の下書きに、参照資料に無い内容が含まれていないこと

この項目については、後の節でもう少し細かく扱います。

誰から何を聞いて、どの順で埋めるか

7つの項目は、上から順に1人で埋められるものではありません。項目ごとに答えを持っている人が違い、聞く順番を間違えると、埋めた欄が後から書き換わります。

工程	聞く相手	確定したと言える状態
対象業務と適用範囲を決める	対象業務を実際に回している担当者	対象外にする例外が名指しで書かれている
入力と出力を確定する	接続先を持つ側（情報システム部門など）と業務の担当者	届くチャネルと形式、出力先の必須項目が実物で確認されている
AIが決めてよい範囲を決める	出力を使う人と、最終確認をする人	承認の単位と、承認しなかった件の戻り先が書かれている
完成の判定基準を決める	最終確認をする人と業務の担当者	母数、一致の定義、誤りの種類別の許容度が書かれている
参照情報と失敗したときの扱いを決める	資料を更新する部門と、運用を担う人	更新する人と頻度、差し戻し先と通知先が書かれている

最初に聞くのは、対象業務と適用範囲、そして対象外にする例外です。相手は業務を回している担当者で、この段階では入力と出力に手を付けません。範囲が動いている間は、どの形式まで受けるかも、どこへ書き込むかも決めようがないためです。対象外の例外を先に挙げてもらうと、範囲の輪郭がはっきりします。

入力と出力は、業務の担当者だけでは確定しません。 届くチャネルも、書き込み先のレコードの構造も、接続先を持つ側の答えが要ります。業務側の想定だけで書いた欄は、後から情報システム部門に確認した時点で書き換わります。ここは推測で埋めず、確認が済むまで空欄として残したほうが、どこが未確定かが見えます。

AIが決めてよい範囲と完成の判定基準は、出力を使う人と最終確認をする人の両方が入らないと決まりません。 どこまでを機械に任せるかは、その出力を受け取って業務を進める人が答えます。どの誤りなら許容できるかは、最後に確認して責任を持つ人が答えます。片方だけで決めると、承認の単位が実際の確認のしかたと合わなくなるか、合格ラインが業務の実感から離れた値になります。

7つがすべて埋まるまで待つ必要はありません。対象範囲と対象外の宣言が固まった時点で、設計の相談は始められます。 処理の分け方や接続の方式を検討するのに必要なのは、まず何を対象にするかだからです。入力と出力の確認を待つ間に設計の議論を進めておくと、確認の答えが返ってきた時点で残りの欄を埋められます。

「精度90%以上」では判定できない

要件定義書でもっともよく見る書き方であり、もっとも判定できない書き方です。理由は3つあります。

何件で測るかが決まっていません。10件で9件当たっても90%、200件で180件当たっても90%です。前者の結果で本番へ進める判断はできません。母数を書いていない割合は、後から都合のよい件数で測れてしまいます。

何をもって一致とするかが決まっていません。抽出した項目のうち1つでも違えばその件は不正解なのか、項目ごとに数えるのか。文面を生成する処理なら、一字一句の一致では測れないので、含まれているべき項目が入っているかで見ることになります。

誤りの重さを区別していません。日付を1日間違えるのと、対象外の案件を処理してしまうのとでは、業務への影響が違います。全部まとめて1つの割合にすると、重い誤りが軽い誤りに紛れます。

置き換えるときは、次の3つを書きます。

決めること	悪い例	判定できる形
測る母数	十分な件数で検証する	直近3か月の実データから無作為抽出した100件
一致の定義	正しく処理できること	抽出6項目のうち、金額と日付は完全一致、名称は表記ゆれを許容
誤りの種類別の許容度	精度90%以上	取り違えは0件、抽出漏れは5件まで、表記ゆれは件数に数えない

誤りの種類は、業務への影響で分けます。処理してはいけないものを処理した誤り、処理すべきものを取りこぼした誤り、値を間違えた誤りの3つに分けると、たいていの業務で足ります。このうち1つ目は0件を条件にすることが多く、残りは業務側が許容できる件数を答えられます。

サンプルは無作為に選びます。担当者に「代表的なものを出してほしい」と頼むと、処理しやすい件が集まります。実データから機械的に抜き、その中に例外がどれくらい混ざっているかも同時に数えると、対象範囲の妥当性まで確認できます。

合格ラインを満たさなかったときにどうするかも、あわせて書いておきます。対象範囲を狭めて作り直すのか、人の確認を増やして運用するのか。基準を満たさなかった場合の扱いを決めていないと、その場の判断で本番へ進む形になります。本番へ進める判断そのものは 生成AIのPoCが進まない で扱っています。

処理量と費用の上限も要件に入れる

7つの項目が埋まっても、渡す前にもう1組だけ決めておくものがあります。1件あたりにかけてよい時間、受け付ける件数の上限、実行にかかる費用の上限です。いずれも動かし始めてから変えると、処理の分け方や接続の作りごと組み直すことになりやすい項目です。

決めること	書けていないと起きること	判定できる形
1件あたりにかけてよい時間	承認する人が待てず、手作業へ戻る	入力が届いてから承認画面に下書きが並ぶまで10分以内
受け付ける件数の上限	繁忙期に処理が積み残る	平常時は1日80件、月末の5営業日は1日200件まで受ける
実行にかかる費用の上限	件数が増えるほど費用が伸び、止める根拠が無い	月額の上限を先に置き、8割に達した時点で担当チャネルへ通知する

時間は、承認する人の都合から決めます。1時間かかっても構わない業務もあれば、その場で返事を求められる業務もあります。ここが決まると、1件ずつ処理するのか、まとめて夜間に流すのかが決まります。

件数は、平常時ではなく最大のときで書きます。月末や年度末に件数が跳ねる業務は珍しくなく、そのときに処理が間に合わないと、いちばん忙しい時期だけ人手に戻る形になります。実データを1年ぶん見て、月ごとの件数の差を確認してから決めます。

費用は、月額の上限と、上限に近づいたときの通知先をあわせて書きます。生成AIを使う処理は件数と1件あたりに渡す情報量で費用が動くため、対象範囲を広げた瞬間に伸びます。検証の段階で1件あたりの費用を実測しておくと、範囲を広げる判断のときに金額を先に出せます。効果と費用を並べて判断する手順は AI導入の効果測定と投資判断 で扱っています。

設計レビューで見る順序

要件定義書が一通り埋まったら、レビューします。抜けやすい順に並べると次のようになります。上から見ていくと、後戻りの大きい抜けを先に見つけられます。

失敗したときの戻り先。 もっとも抜けます。正常に流れる経路は誰でも書きますが、止まった件がどこへ行くかは書かれないまま実装に入りがちです。差し戻し先、通知の宛先、滞留の上限がすべて書かれているかを見ます。

権限。 どのシステムに、読み取りだけで入るのか、書き込みまで行うのか。書き込む範囲は特定のレコードに限られるのか。ここが曖昧なまま作ると、必要以上の権限で動く構成になります。読むだけで足りる処理に書き込み権限を渡していないかを、システムごとに確認します。

対象外の宣言。 対象に含めるものは書かれていても、含めないものが書かれていない要件定義書は多いです。対象外が空欄なら、範囲が決まっていないのと同じです。

運用の担当者。 作った後に誰が直すかです。参照する資料を更新する人、差し戻された件を処理する人、精度が落ちたときに指示を直す人。この3つの役割に名前が入っているかを見ます。埋まらない場合は、体制の検討へ戻ります。役割の分け方は AIエージェントを社内で内製する にまとめています。

この4つは、外部へ委託する場合も自社で作る場合も同じです。既製ツールの導入を検討している場合は、要件定義書がそのまま比較の観点になります。ツールごとに、対応する入力形式、書き込める出力先、承認の置き方が違うためです。作るか買うかの判断は AIエージェントは自作か既製ツールか を参照してください。

この4つが埋まった要件定義書は、そのまま委託先へ渡す資料になります。渡したあとに提案書と見積で何を確かめるかは AIエージェント開発会社の選び方 にまとめています。この記事が扱うのは自社で要件を書き出すところまでで、届いた提案の読み方や契約前に決めることはあちらの記事の側です。要件が固まっていないまま相見積を取ると、各社が別々の前提で見積もるため、金額を並べても比べられません。

まとめ：要件定義書に足りない項目を洗い出す

• 従来のシステム要件定義に、入力の揺れ、出力が一定にならないこと、人の承認の3点が加わる。画面と機能の一覧では埋まらない
• ツールや生成で短くできるのは書式をそろえる時間と見直す時間で、範囲と合格ラインを決める時間は短くならない
• 埋める項目は、対象業務と適用範囲、入力、出力、AIが決めてよい範囲、参照情報とその置き場所、失敗したときの扱い、完成の判定基準の7つ
• 対象外を名指しで書く。書かないと検証中に範囲が広がり、合格ラインに届かない
• 出力先の必須項目を全部並べると、AIだけでは埋まらない項目が見つかる
• 「精度90%以上」は、母数・一致の定義・誤りの種類別の許容度の3つに置き換える
• 1件あたりにかけてよい時間、受け付ける件数の上限、実行にかかる費用の上限は、7項目の外側で先に決める
• レビューは、失敗時の戻り先、権限、対象外の宣言、運用の担当者の順に見る

Augueでは、業務の手順を書き出すところから要件の確定、実装と本番後の運用までを支援しており、既存の要件定義書に足りない項目を洗い出す段階からお手伝いできます。要件をどこまで詰めてから作り始めるか迷っている段階でも構いませんので、ご興味がある方は是非ご相談ください。

関連する記事

開発全体の進め方は AIエージェント開発の進め方、書いた要件を委託先へ渡したあとの見極めは AIエージェント開発会社の選び方、検証から本番へ進める判断は 生成AIのPoCが進まない、作るか買うかの比較は AIエージェントは自作か既製ツールか、作った後の体制は AIエージェントを社内で内製する を参照してください。

よくある質問

要件定義にはどれくらいの期間をかけるべきですか？

一律の日数は出せません。長さを決めるのは業務の複雑さではなく、手順が文書になっているかと、接続先のシステムの担当者が捕まるかの2つです。手順が担当者の頭の中にある場合は、書き出す作業がそのまま期間になります。見積もる前に、対象業務の手順書が今どこまであるかを数えてください。

要件定義書は業務の担当者と情報システム部門のどちらが書きますか？

対象範囲と合格ラインは業務を回している人でないと書けず、接続先と権限は情報システム部門でないと書けません。どちらか一方が全部を書こうとすると、片方が推測になります。業務側が原稿を書き、接続と権限の欄だけ情報システム部門が埋める形にすると、埋まらずに残った欄がそのまま確認すべき論点になります。

先に要件を固めるべきか、動かしてから書くべきか、どちらですか？

入力・出力・権限の3つは先に決め、指示の書き方や参照情報の持たせ方は動かしながら詰める形が現実的です。前者は決めないと接続先も承認経路も設計できません。後者は実際の入力を通さないと判断できないため、机上で詰めても作り直しになります。

既製ツールを導入する場合も要件定義は必要ですか？

必要です。項目は変わりません。作る場合は仕様になり、買う場合はツールを比べる観点になります。とくに出力先の形式と権限の範囲は、ツール側の仕様で決まってしまうことがあるため、先に自社の要件として書いておくと、合わないツールを早い段階で外せます。

要件が後から変わったときはどう扱いますか？

変更そのものは避けられないので、記録の残し方を決めておきます。変えた項目、変えた理由、合格ラインへの影響の3つを残すと、次に精度を測ったときに数字が動いた原因を追えます。記録が無いまま項目だけ書き換えると、以前の検証結果と比べられなくなります。