AIエージェントの要件定義を進める手順｜業務・権限・例外の決め方

AIエージェントの要件定義は、選定済みの業務を1件に絞り、「業務→権限→例外」の順で具体化します。開始・完了条件、許可する操作、影響に応じた承認点、例外時の引継ぎ先を決め、自社の決定と提供者・開発者への確認を分けて、所有者付きの記録として実装担当へ渡すのが結論です。

AIエージェントの要件定義は「業務→権限→例外」の順で進める

先に業務の境界を固定し、その工程に必要な権限を結び付け、最後に通常どおり進められない条件と人への戻し方を決めます。

この順序は、公的機関が定めた標準工程ではなく、本記事における実務上の整理です。AIエージェントの要件定義に関する公的な標準工程・標準様式・公式項目リストは確認できていません。そのため、以下の表も「必ずこの書式を使う」という様式ではなく、会議で決定漏れや主体の混同を防ぐための記入例として使ってください。

業務より先に機能や権限の話を始めると、「何に使う権限なのか」が曖昧になります。反対に、正常な業務フローだけを決めて権限や例外を後回しにすると、外部送信や削除の直前で誰が判断するのか、途中で止まった処理をどこへ戻すのかが決まりません。3つの記録を同じ業務工程の行でつなぐことが重要です。

総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」（資料日2026年3月31日、確認日2026-08-01）は非拘束的なソフトローであり、法令上の義務ではありません。同ガイドライン別添1は、AIエージェントが「自律的な動作の中で人間の意図しない商品の注文やファイル削除等の動作を行う可能性がある」と留保付きで示しています。だからこそ、抽象的に「安全に使う」と書くのではなく、許可する操作と人が判断する場所を業務工程に結び付けます。AIエージェント固有のリスクの詳説は「AIエージェントのセキュリティとは？導入前に知るべき基礎と判断基準」が扱います。

対象業務を1件に絞り、開始条件・完了条件・対象外を決める

最初の成果物は、選定済みの対象業務について「どこから始まり、どの状態で終わり、何を行わないか」を1枚で示す対象範囲記録です。

「営業支援」や「問い合わせ対応」のような部門単位では広すぎます。「受信済みの問い合わせを読み、担当部署の候補を付けた下書きを作る」のように、入力と成果物が一続きになる単位まで狭めます。対象業務の選び方や他技術との比較に戻るのではなく、すでに候補となっている業務1件の境界を確定する作業です。

開始条件には、処理を始めてよい状態を書きます。完了条件には、AIエージェントの処理が終わったと判定できる状態を書きます。対象外には、別部門の案件、必要項目が不足した入力、社外への確定連絡など、今回の範囲では先へ進めないものを書きます。作成者と確認者もこの段階で付けると、後から対象が広がったときに誰へ確認するかが明確になります。

業務名	開始条件	完了条件	対象外	作成者	確認者
問い合わせ振り分け案の作成	受付済みで必須項目がそろっている	担当部署候補と根拠が下書き保存されている	顧客への返信確定、必須項目不足、対象部署不明	業務担当者	業務責任者

上表は公的な標準様式ではありません。重要なのは、業務名だけでなく開始・完了・対象外が同時に読めることです。対象外の処理を後の「例外」にすべて押し込まず、最初から実行させない範囲と、通常処理中に起こり得る例外を分けてください。

民間側の補助線として、ガートナージャパン株式会社が2026年5月21日に発表したプレスリリース（確認日2026-08-01）は、自律的・再帰的なエージェントについて全社一斉ではなく範囲を制限した展開が重要だと述べています。これは公的な要求や効果測定ではありませんが、最初の対象を1件に絞る判断と整合する民間の見解です。

工程ごとに入力・判断・操作・成果物を並べる

対象範囲が決まったら、開始から完了までを、入力・判断・操作・成果物が具体的に見える粒度へ分解します。

「AIが問い合わせを処理する」だけでは、必要なデータも権限も決められません。実際の帳票、入力画面、処理例を見ながら、担当者が何を受け取り、どの条件で判断し、どのシステムへ何を行い、何を残すかを一行ずつ書きます。担当者の経験に依存する判断は、「緊急と判断する」のような言葉で終わらせず、どの情報を根拠にするかを言語化します。

業務工程	入力	判断	操作	成果物
受付内容を読む	問い合わせ本文、受付時刻	対象業務に該当するか	受付データを参照する	対象／対象外の判定案
必要事項を確認する	顧客名、用件、希望内容	情報がそろっているか	欠落項目を抽出する	確認事項の下書き
担当部署候補を付ける	部署別の担当範囲	どの部署が対応するか	候補と根拠を下書き保存する	振り分け案
人へ渡す	振り分け案、根拠、欠落情報	確定可能か	承認待ち状態へ移す	担当者が確認できる一式

ここでは、まだ許可する権限を決め切りません。まず正常系の仕事を見えるようにし、その後で各操作を「参照」「下書き」「更新」「外部送信」「確定」「削除」などへ具体化します。この順序なら、機能名から必要以上に広い権限を逆算するのを避けられます。

また、総務省・経済産業省の同ガイドライン別添5（AI利用者向け）は、利用前の事項として適正利用に必要な知識・技能の習得と基本的な動作確認を挙げています。実務では、工程を担当する人が、AIの出力をどの情報と照合するか、どの操作は自分で確定してよいかを説明できる状態も、引渡し条件に含めます。

自社で決めることと提供者・開発者に確認することを分ける

各工程では、利用企業が業務上決める事項と、AI提供者・AI開発者でなければ回答できない仕様を別の列に置きます。

総務省・経済産業省の同ガイドラインは、AI利用者、AI提供者、AI開発者を異なる主体として整理しています。同一企業や部門が複数の主体を兼ねる場合もありますが、役割が同じになるわけではありません。利用企業が「どの操作まで許容するか」を決め、提供者や開発者には「その制限をどう設定できるか」を確認する、という分担にします。

業務工程	自社が決めること	AI提供者に確認すること	AI開発者に確認すること	回答・決定の所有者
受付内容の参照	参照してよい案件・項目	ユーザーやシステムごとに参照権限を分けられるか	判断に不要な属性を参照対象から外せるか	情報管理担当
振り分け案の作成	使用する部署ルール、出力形式	入力・出力の保存条件と取得できる記録	判断に使うデータ範囲と更新方法	業務責任者
下書き保存	保存先、上書き可否、確定前の状態	作成と更新の権限を分離できるか	重複実行を避ける処理を実現できるか	システム担当
人への引継ぎ	承認者、渡す情報、却下時の戻し先	承認待ち・停止状態を設定できるか	例外条件を検知して処理を止められるか	導入責任者

主体の取り違えには注意が必要です。同ガイドライン別添4の「ユーザーやシステムに付与する権限を業務遂行に必要な最小限に設定する」という記述はAI提供者向けです。また、別添3の「必要最小限のデータ入力・参照」はAI開発者向けで、AIの判断に必要な範囲へデータを限定し、不要な属性情報の付与を避ける趣旨です。どちらもAI利用者への公式要求として扱わず、提供者・開発者へ実現方法を確認する観点として使います。

AI利用者側について同ガイドライン別添5が挙げるデータ最小化は、利用中の不要なデータや冗長なログの削除などです。自社で保有する必要性と保存条件を決める話と、提供者・開発者の設計事項を混ぜないようにしてください。

外部へ要件を渡す場合は、経済産業省が2025年2月18日に公表した「AIの利用・開発に関する契約チェックリスト」の公開ページを参照できます。同ページには2025年2月20日更新の正誤情報があるため、確認時は更新情報も見ます。公開ページで未確認のPDF内の個別項目・条項例・図表を、本記事の要件として転記してはいけません。システム開発を伴う発注では、IPAの「情報システム・モデル取引・契約書（第二版）」も一般資料として参照できますが、AI固有の契約モデルではなく、掲載ページが注意するように参照法規は公表当時の版に基づくため、利用時には十分な確認が必要です。

外部送信・更新・確定・削除などの操作を洗い出す

業務フローの動詞を具体的な操作へ置き換え、誰や何に影響するか、取り消せるか、どの状態が変わるかを記録します。

「連携する」「処理する」「自動化する」では、実装担当が権限を決められません。たとえば「CRMと連携する」を、案件を読む、タグ候補を作る、タグを更新する、担当者を確定する、顧客へメールを送る、レコードを削除するといった操作へ分けます。同じシステムを使っていても、参照と削除では影響が異なります。

操作	変わるもの	主な影響先	取り消し方	要件として決めること
参照	表示・取得する情報	社内の利用者	状態変更なし	参照対象、除外項目、利用目的
下書き保存	未確定データ	担当者、部門	下書きを破棄・修正	保存先、上書き条件、表示ラベル
更新	業務データの値	後続工程、関係部門	変更前の状態へ戻せるか確認	対象項目、実行条件、承認の有無
外部送信	社外へ届く情報	顧客、取引先	原則として送信自体は取り消せない	宛先、内容、送信前の判断者
確定	契約・受注・申請などの状態	顧客、取引先、社内処理	業務ごとの取消手続が必要	確定できる主体、禁止条件
削除	記録やファイル	利用者、後続処理	復元可否を個別確認	対象、復元手段、人の判断点

この表も固定の権限レベルや公的分類ではなく、対象業務の動詞を具体化するための記入例です。外部への影響があるから一律に禁止するのでも、システム上可能だから許可するのでもありません。影響先と取り消し可能性が分かる状態にしたうえで、次の工程で承認点を決めます。

影響の大きさで人の判断を挟む場所を決める

人の判断はすべての出力に一律で置くのではなく、出力によって重大な影響や被害が生じ得る場所へ、業務に応じて配置します。

総務省・経済産業省の同ガイドライン第1.2版・別添5（AI利用者向け）は、利用中の事項として「出力によって重大な影響又は被害が生じ得る場合、人間の判断を介在させる仕組みに基づき適宜判断」としています。これは、全件承認を求める記述でも、すべてを人の確認なしで進めてよいという記述でもありません。

まず各操作について、影響を受ける相手、変更される情報や状態、取り消し可能性を確認します。そのうえで人が見る場所を、操作後ではなく判断がまだ間に合う位置に置きます。承認者には、単に「確認してください」と通知するのではなく、対象、実行内容、影響先、判断根拠、例外の有無を渡します。

工程	操作	影響先	重大な影響・被害の可能性	人が判断する場所	承認者	却下時の戻し先
担当部署候補の作成	下書き保存	社内担当者	低いが、誤分類時は修正が必要	確定操作の前	業務担当者	候補の再作成
顧客返信	外部送信	顧客	内容により生じ得る	送信の前	顧客対応責任者	下書き修正
契約条件の反映	確定・更新	顧客、契約処理	生じ得る	確定の前	契約権限を持つ人	担当者へ差し戻し
不要ファイルの処理	削除	社内利用者、後続工程	復元可否により生じ得る	削除の前	データ所有者	削除対象の再選定

承認者は肩書だけでなく、何を根拠に判断できる人かで選びます。通常操作の担当者と同じ人が承認を兼ねる場合もありますが、誰がどの操作を確定したかは記録上区別します。承認者が不在のときに勝手に先へ進む仕様にせず、代替承認者へ渡すのか、処理を保留するのかを例外要件として決めます。

また、AI出力を事業で利用する判断は利用企業が責任をもって行います。ただし、そのことを理由に、すべての内部下書きへ同じ承認を重ねる必要はありません。影響が限定され、後から修正できる操作と、社外や重要な状態へ影響する操作を分けることで、承認の役割を明確にできます。

例外条件・引継ぎ先・停止できる人・停止後の状態を決める

例外要件では、何が起きたら通常処理を止め、どの情報を誰へ渡し、停止後にどの状態を維持するかを決めます。

例外を「エラー時は人へ連絡」とだけ書くと、実装担当は検知条件も引継ぎ内容も決められません。入力不足、判断根拠の競合、許可されていない操作の要求、接続先の応答不良、承認者不在などを対象業務に即して挙げます。これらは公的な固定分類ではなく、現行業務とシステム仕様から作る例です。

例外条件	検知のきっかけ	人へ渡す情報	引継ぎ先	停止できる人	停止後の状態
必須情報が不足	必須項目が空欄	元の入力、不足項目、処理済み範囲	業務担当者	業務担当者	未処理として保留
判断根拠が競合	複数ルールが異なる候補を示す	候補、各根拠、未確定項目	業務責任者	業務責任者	候補を確定しない
許可外の操作が必要	操作一覧にない要求を検知	要求内容、要求元、直前の状態	導入責任者	システム担当	許可済み操作までで停止
接続先が応答しない	規定の完了状態を確認できない	送信内容、受付結果、再試行の有無	システム担当	システム担当	二重実行を避けて保留
承認者が不在	承認待ちのまま所定条件に達する	操作内容、影響先、待機時間	代替承認者または業務責任者	業務責任者	実行せず承認待ちを維持

「停止」は、単に画面へエラーを出すことではありません。外部送信はまだ行われていない、更新途中の値は確定していない、同じ処理が再度走らない、といった安全な停止後状態を定義します。再開できる人、取消を判断する人、元の処理と再開後の処理を結び付ける識別情報も、実装担当へ渡す要件に含めます。

本記事が扱うのは、例外条件、引継ぎ先、停止できる人、停止後状態、後から確認するために残す項目を「決める」ところまでです。実際のログを用いた統制の点検、権限の棚卸し、事故原因の調査、復旧や再発防止の実施方法には踏み込みません。

決定事項の作成者・所有者を定め、後から確認できる形で残す

決定記録には内容だけでなく、誰が作り、誰が業務上の判断を所有し、どの変更で見直すかを付けます。

総務省・経済産業省の同ガイドライン第1.2版は、文書化について、後から容易に確認できるよう適切なツールで記録が残されていればよく、紙媒体や特定の文書形式である必要はないとしています。したがって、要件定義書という名称の文書を作ること自体を目的にする必要はありません。表計算、チケット管理、社内文書でも、決定内容と履歴を追えれば使えます。

記録ごとに少なくとも、決定内容、根拠、作成者、所有者、確認者、決定日、見直し条件を持たせます。所有者は実装ファイルの管理者ではなく、「この業務でこの操作を許す」と説明し、変更時に再判断する人です。専任AI部門がない企業では、対象業務の責任者を業務判断の所有者とし、AI導入責任者が記録全体の整合を管理する形が一例です。情報やシステムの担当者は、データ取扱いと実現可否を確認します。

公的資料とは別の民間一次資料として、ガートナージャパン株式会社が2026年5月21日に発表したプレスリリース（確認日2026-08-01）は、エージェントの登録や固有の識別符の付与に加え、作成者・所有者の明確化を挙げています。公開プレスリリース本文に基づく定性的な見解であり、公的要求、有償レポートの内容、効果測定を示すものではありませんが、所有者を決定記録へ付ける補助線になります。

総務省・経済産業省の同ガイドライン別添5では、ログの管理体制の整備は利用前の事項、AIの活用が適正な範囲・方法で行われているかの定期的な確認は利用中の別項です。これらを「操作履歴を定期的に確認・報告する」という一続きの公式要求へ変えないでください。本記事では、後から確認するために残す項目と管理責任者を決め、実際の点検方法は別の運用設計へ引き渡します。

業務・権限・例外の記録間にある矛盾を解消する

実装担当へ渡す前に、同じ工程について業務記録、操作・権限記録、例外・引継ぎ記録が互いに矛盾していないかを確認します。

ここで行うのは、実装後のログ監査や統制評価ではなく、決定した要件同士の机上照合です。各表を別々に読むのではなく、業務工程をキーに横へ並べます。矛盾があれば、実装担当に判断を委ねず、業務責任者または該当記録の所有者が決め直します。

矛盾の例	確認する記録	解消する決定	決定者の例
業務工程は顧客送信を前提とするが、許可操作は下書きまで	業務フロー、操作一覧	送信を対象外にするか、承認付き送信を要件化する	業務責任者
重大な影響が生じ得る操作なのに承認者がいない	操作・影響・承認点	承認者と代替者、却下時の戻し先を決める	業務責任者
例外条件はあるが人へ渡す情報がない	業務フロー、例外記録	元入力、処理済み範囲、判断根拠を指定する	実務担当者
停止できる人はいるが停止後の状態が不明	例外記録、提供者回答	未送信・未確定など維持すべき状態を決める	導入責任者
提供者が制限できない操作を自社が許可済みにしている	決定・確認先マトリクス	対象縮小、別の実現方法、開始保留を判断する	記録の所有者

矛盾がなく、未回答の提供者・開発者確認がなく、作成者と所有者が付いた時点で、実装担当へ決定記録を渡せます。提供条件や権限設定の可否が確認できない、重大な影響を受ける操作の判断者がいない、安全な停止後状態を決められない場合は、未決のまま実装へ進めず、対象縮小・要修正・開始保留のいずれかを記録します。

要件定義後に隣接テーマを確認したい場合は、AI関連記事一覧から必要な解説を探せます。この記事では、導入後の効果指標、継続・中止の判断、統制の検証方法までは扱いません。

よくある質問

専任AI部門がない企業で迷いやすい所有者、提供元への確認、人の承認、記録形式について答えます。

Q1. 専任AI部門がない場合、決定記録の所有者は誰にすべきですか？

対象業務の範囲、許可操作、例外対応を業務として説明できる業務責任者を所有者にするのが一例です。AI導入責任者は記録全体の整合を管理し、情報管理・システム担当はデータ取扱いと実現可否を確認します。役職名を固定するのではなく、作成者、業務判断の所有者、確認者を記録上で区別してください。

Q2. AI提供者とAI開発者には何を分けて確認しますか？

AI提供者には、ユーザーやシステムごとの権限設定、承認待ち・停止状態、保存条件、取得できる記録など、提供サービスとして制御できる範囲を確認します。AI開発者には、判断に使うデータ範囲、不要な属性を除外できるか、例外検知や重複実行防止をどう実現するかを確認します。自社は、その回答を踏まえて何を許可するかを決めます。

Q3. すべての出力や操作に人の承認が必要ですか？

一律の承認は必要ありません。AI事業者ガイドライン第1.2版・別添5（AI利用者向け）は、出力によって重大な影響または被害が生じ得る場合に、人間の判断を介在させる仕組みに基づいて適宜判断するという考え方です。影響先、取り消し可能性、変更される状態を見て、判断が間に合う操作前に承認点を置きます。

Q4. 要件定義書という形式で残す必要がありますか？

特定の形式である必要はありません。後から決定内容、根拠、作成者、所有者、確認者、変更履歴を確認できるなら、表計算やチケット管理でも構いません。実装担当へ渡す際は、業務、操作・権限、例外の各記録を同じ工程で対応付けてください。

まとめ

AIエージェントの要件定義は、選定済みの対象業務1件について、業務の境界を決め、操作ごとの権限と影響を整理し、例外時の引継ぎと停止後状態を定める作業です。

まず開始条件・完了条件・対象外を固定し、工程ごとの入力・判断・操作・成果物を並べます。次に、自社が決める事項とAI提供者・AI開発者へ確認する事項を分け、外部送信・更新・確定・削除などの操作を具体化します。そのうえで、重大な影響や被害が生じ得る場所へ人の判断を置き、却下時の戻し先まで決めます。

最後に、例外条件、引継ぎ先、停止できる人、停止後の状態を記録し、各決定へ作成者と所有者を付けます。業務・権限・例外の矛盾と未回答事項を解消した、後から確認できる決定記録を実装担当へ渡せれば、要件定義工程の成果は明確になります。

参考資料

• AIの社会実装に向けた制度・施策に関する報告（経済産業省）
• AIの利用・開発に関する契約チェックリスト（経済産業省）
• 情報システム・モデル取引・契約書（第二版）（IPA）