AIエージェント導入の要件定義では、「何ができるAIを作るか」より先に、「どの業務判断を、どの情報と権限を使って、どこまで任せるか」を決めます。対象業務、データ、権限、システム連携、評価、リスク、運用責任の7項目を定義すると、PoCがデモで終わらず、本番移行の可否を判断できます。
この記事では、AIエージェントのPoC前に作る要件定義を、非エンジニアの責任者にも分かる形で解説します。すべてを最初から確定するのではなく、仮説、検証項目、判断基準を明記することがポイントです。
AIエージェントの要件定義とは
AIエージェントの要件定義とは、エージェントが担当する仕事、参照する情報、利用できるツール、人へ戻す条件、品質基準、運用方法を文書化することです。通常のソフトウェアと異なり、同じ入力でも出力が変わる可能性があるため、機能の有無だけでなく評価と監視まで含めます。
AIチャットとの違いは、エージェントが複数の手順を進めたり、外部ツールを使ったり、状況に応じて次の処理を選んだりする点です。権限を広げるほど便利になりますが、誤操作や情報漏洩の影響も大きくなります。
OpenAIのビジネス向けガイドでも、エージェント導入時に目的、範囲、所有者、連携、ライフサイクルを明確にすることが示されています。詳細はAIエージェント活用のビジネスリーダー向けガイドで確認できます。
要件1：対象業務と目的
最初に決めるのは製品やモデルではなく、対象業務です。「営業を効率化する」では広すぎるため、開始条件、完了条件、現在の手順、困っている点を一つの業務フローとして整理します。
要件定義書には、次の内容を書きます。
- 対象となる利用者と業務
- 業務が始まる条件と完了の定義
- 現在の処理時間、件数、手戻り、品質
- エージェントへ任せたい作業
- 人が引き続き判断する作業
- 導入によって改善したい指標
最初のPoCには、入力と完了条件が比較的明確で、失敗時に人が戻せる業務が適しています。法的判断、人事評価、高額な発注など、誤りの影響が大きい意思決定を最初から自動化しないでください。
要件2：業務フローと人の確認
AIエージェントが動く範囲を、業務の開始から終了まで図にします。AIへ任せる作業、人が承認する判断、例外時の戻り先を分けることで、「自動化」という言葉に隠れた責任の空白を防げます。
| 処理 | AIの役割 | 人の役割 |
|---|---|---|
| 依頼受付 | 内容を分類し不足項目を確認 | 高リスク依頼を選別する |
| 情報収集 | 承認済みデータから候補を取得 | 情報源と不足を確認する |
| 下書き | 指定形式で回答案を作る | 事実、表現、判断を承認する |
| 実行 | 承認後に登録や送信を行う | 最終実行を承認する |
| 記録 | 入力、出力、参照元、結果を保存 | 異常や改善点をレビューする |
PoCでは、最初から完全自動にせず、人の承認を挟む設計にすると、失敗例と判断基準を集められます。十分な評価データがたまった工程だけ、段階的に権限を広げます。
要件3：参照データと権限
エージェントが正しく動くには、参照できるデータの範囲、品質、更新頻度、閲覧権限を定義する必要があります。「社内文書を参照する」だけでは、古い版や閲覧禁止文書が混ざるおそれがあります。
データ一覧には次の項目を持たせます。
| 項目 | 記載例 |
|---|---|
| データ名 | 製品FAQ、就業規則、顧客対応履歴 |
| 管理者 | 所管部署と更新責任者 |
| 正本 | 最新版を管理する場所 |
| 更新頻度 | 随時、月次、規程改定時 |
| 機密区分 | 公開、社内限定、部門限定、個人情報 |
| 利用範囲 | 検索のみ、要約可、外部送信不可 |
| 廃止条件 | 新版公開時、契約終了時 |
ユーザー本人が閲覧できない情報を、エージェント経由で取得できないようにします。部署、役職、案件などの権限を検索時と実行時の両方で確認してください。
要件4：ツール連携と実行権限
メール、CRM、カレンダー、ファイル管理、基幹システムなどと連携する場合、読み取りと書き込みを分けて定義します。情報を検索する権限と、レコードを更新・送信・削除する権限では、失敗時の影響が異なります。
PoCでは次の順に広げると管理しやすくなります。
- 保存済みデータを読み取る
- 画面に提案を表示する
- 人の承認後に下書きを保存する
- 限定された対象へ実行する
- 条件を満たす処理だけ自動実行する
各ツールについて、利用するAPI、認証方法、権限、回数制限、エラー時の処理、監査ログを確認します。エージェントが利用者の権限を越えて操作できないことが必須です。
要件5：品質評価とPoCの成功条件
「回答が自然だった」「担当者が便利と感じた」だけでは、本番移行を判断できません。PoC開始前に、評価用のケースと合格基準を決めます。通常ケースだけでなく、情報不足、矛盾、対象外、高リスクな依頼も含めてください。
評価指標の例
| 観点 | 指標 | 確認方法 |
|---|---|---|
| 正確性 | 事実・計算・参照元が正しい割合 | 専門担当者が評価セットを採点 |
| 完了率 | 目的の処理まで到達した割合 | 実行ログで確認 |
| 安全性 | 禁止操作・情報漏洩の発生 | 攻撃的・例外的なテストを実施 |
| 効率 | 人を含む総処理時間 | 現行業務との比較 |
| 利用性 | 修正量、離脱、再依頼 | 利用ログとインタビュー |
| コスト | 1件あたりの推論・連携・確認費 | 実行回数と人件時間から算出 |
品質指標は平均値だけでなく、重大な失敗を別に管理します。全体の正答率が高くても、個人情報を誤送信する可能性が残っていれば本番移行はできません。
要件6：リスクと安全対策
AIエージェントのリスクは、誤回答だけではありません。情報漏洩、権限逸脱、意図しない実行、外部コンテンツによる誘導、差別的な出力、著作権、説明責任などを対象業務に合わせて整理します。
NISTのAIリスクマネジメントフレームワークは、AIリスクを「Govern、Map、Measure、Manage」の観点で継続的に扱う考え方を示しています。NIST AI RMFも参考にし、PoC前だけでなく運用後の監視と改善を設計してください。
最低限、次の安全対策を決めます。
- 入力・出力・参照元・実行結果のログ
- 個人情報や機密情報のマスキング
- 許可するデータとツールの限定
- 重要操作前の人の承認
- 異常時の停止と手動処理への切り替え
- 問題報告、調査、修正、再発防止の責任者
要件7：運用責任と改善方法
AIエージェントは公開して終わりではありません。参照データ、外部サービス、業務ルール、モデルの挙動が変わるため、品質の監視、問い合わせ対応、更新、停止を担う所有者が必要です。
運用設計では次の役割を決めます。
| 役割 | 主な責任 |
|---|---|
| 業務責任者 | 対象業務、品質基準、例外判断 |
| データ責任者 | 正本、更新、権限、削除 |
| 技術責任者 | システム、連携、ログ、障害対応 |
| リスク責任者 | 規程、法務、セキュリティ、事故対応 |
| 利用支援 | 問い合わせ、教育、活用事例の収集 |
小規模な組織では兼務できますが、責任そのものを省略してはいけません。誰が改善要望を優先し、どの条件で一時停止し、いつ廃止するかまで決めます。
PoC要件定義書の最小構成
PoCの要件定義書は、長い仕様書よりも判断に必要な項目を一貫して持つことが重要です。最初は次の1〜3ページから始め、検証で分かったことを更新します。
- 対象業務、利用者、現状課題
- AI、人、既存システムの役割分担
- 利用データとツール、権限
- 対象範囲と対象外
- 評価ケース、指標、合格条件
- リスクと安全対策
- スケジュール、責任者、予算上限
- Go、改善継続、中止の判断日
PoCの成果物には、デモ画面だけでなく、評価結果、失敗例、未解決リスク、運用コスト、本番化に必要な追加作業を含めます。
本番移行を判断する方法
本番移行は「技術的に動いたか」ではなく、業務価値、品質、安全性、運用可能性の4条件で判断します。一つでも重大な未解決項目があれば、対象業務を狭めるか、PoCを延長します。
| 判断 | 状態 |
|---|---|
| Go | 合格基準を満たし、責任者・運用・予算が決まっている |
| 改善継続 | 価値はあるが、データ・品質・運用の改善が必要 |
| 対象変更 | 技術は使えるが、選んだ業務との相性が悪い |
| 中止 | 価値が小さい、リスクが許容できない、運用できない |
中止も正しいPoC結果です。判断基準を先に決めておけば、投資を続ける理由を後から作る状態を避けられます。
よくある質問
要件定義にはどの部署が参加すべきですか？
対象業務の担当者と責任者、IT、データ管理、セキュリティ・法務が基本です。最終利用者を外すと、現場で使えない要件になりやすいため、PoC初期から参加してもらいます。
PoCはどのくらい小さくすべきですか？
一つの業務、一つの利用者層、限定データから始めます。価値とリスクを測れる最小範囲にし、成功後に部署や権限を広げます。
精度は何％あれば本番化できますか？
一律の基準はありません。誤りの影響と人の確認方法で変わります。重大な誤りは許容率を別に設定し、平均精度だけで判断しないでください。
要件定義前に製品を選んでもよいですか？
既存契約や検証環境の都合で候補を置くことはできますが、製品の機能から業務を決めると目的がずれます。対象業務と成功条件を先に定義し、候補製品で実現できるかを確認します。
AIエージェントとRPAのどちらを使うべきですか？
手順と条件が固定されている処理はRPA、文章理解や状況に応じた判断を含む処理はAIエージェントが候補です。両者を組み合わせる場合も、人へ戻す条件と実行権限を明確にします。
まとめ
AIエージェントの要件定義では、対象業務、業務フローと人の確認、データと権限、ツール連携、品質評価、リスク、運用責任の7項目を決めます。PoC前に成功条件と中止条件を置き、デモではなく本番移行の判断材料を残してください。
導入テーマの整理やPoC要件を自社だけでまとめにくい場合は、お問い合わせからご相談ください。業務の切り分け、評価設計、実装・運用を見据えた検討を支援します。
関連記事
- AIエージェントの作り方 - 実装手順とノーコードでの始め方
- AIエージェント導入の費用相場 - 予算と依頼先の比較
- AIエージェントとは - 仕組みと活用例の基礎
- RAG・ファインチューニング・AIエージェントの違い - 実現方式を選ぶ判断基準
