業務実行AIエージェント基盤構築の要件定義｜失敗しない進め方と設計ガイド

基盤は作れそうですが、誰が何を実行してよいかがまだ決まっていません

ある製造業の会議室で、情報システム部門の佐藤さんがそう言った瞬間、筆者は少しだけ沈黙しました。画面には、AIエージェントの構成図が映っていました。モデル、API、社内データベース、ワークフロー管理、監査ログ。技術的には、かなりよく考えられた図でした。しかし、営業部門は見積作成を任せたいと言い、管理部門は申請処理を自動化したいと言い、開発部門はデータ連携の安全性を気にしていました。セキュリティ担当は、静かに「実行権限は誰の責任になるのですか」と問いかけました。

半年前、この会社では技術チーム主導でAI実行環境の検証を進めていました。ところが、業務側のユースケースや運用要件が固まらず、PoC期間3か月で作成した試作フロー12件のうち、実運用に進めたのは3件にとどまりました。現在は、実行させる業務、権限、監査ログ、例外時の人による承認を先に整理し、業務AIアーキテクチャと段階的な自律AI基盤構築の見取り図ができています。

この記事では、業務実行型AIエージェントを本格構築する前に、何を要件として決めるべきかを整理します。目指すのは、AIが勝手に動く状態ではなく、人が管理できる範囲で業務を安全に前へ進める状態です。ただし、基盤を作るだけで全業務が自動化されるわけではありません。自社の業務スコープに迷っている方は、自分たちの現場に置き換えながら読み進めてください。

業務実行AIエージェント基盤は、技術より先に要件を決める必要があります

業務実行AIエージェント基盤とは、AIが単に質問へ回答するだけでなく、社内システムや業務データと連携し、一定の条件に沿って業務を補助・実行するための環境です。

たとえば、次のような業務が対象になります。

• 顧客情報を参照して、提案書の下書きを作成する
• 社内規程を確認し、申請内容に不備がないかを判定する
• 問い合わせ内容を分類し、担当部署に振り分ける
• 商談メモからCRM登録用の情報を整理する
• 承認済みの条件に沿って、通知やレポート作成を自動化する

こうした話をすると、「どのAIモデルを使うべきですか」「どのツールと連携できますか」という質問が先に出ることがあります。もちろん、技術選定は重要です。筆者自身もエンジニア出身なので、アーキテクチャを考え始めると、API設計やデータ構造から詰めたくなる気持ちはよく分かります。

しかし、業務実行AIエージェントで最初に決めるべきことは、「AIに何ができるか」ではありません。「AIに何を任せてよいか」です。

AIエージェントは、チャットAIよりも業務への影響範囲が広くなります。回答を間違えるだけでなく、誤ったデータを登録する、不要な通知を送る、承認前の処理を進めてしまうといったリスクが生まれます。そのため、自律AI 基盤構築では、モデル選定やツール連携より前に、業務要件、権限、監査、セキュリティ、運用ルールを定義する必要があります。AIの利活用とリスク管理を表裏一体で進める考え方は、経済産業省のAI事業者ガイドライン関連資料や、デジタル庁の生成AI利活用に関する資料でも重視されています。

チャットAIと業務実行AIエージェントは何が違うのか

チャットAIは、主に人の入力に対して文章で回答します。人が質問し、人が回答を読み、人が判断して次の行動を決めます。

一方、業務実行AIエージェントは、回答の先に「操作」があります。外部システムを参照する、データを更新する、ワークフローを開始する、関係者に通知するなど、業務プロセスの一部を担います。

この違いにより、要件定義で見るべき観点も変わります。

チャットAIでは、主に回答精度や使いやすさが論点になります。業務実行AIエージェントでは、それに加えて、実行権限、操作範囲、ログ、承認、例外処理、停止条件が論点になります。

筆者が支援する現場でも、最初は「AIに社内データを読ませたい」という相談から始まることが多くあります。しかし、話を深掘りすると、本当にやりたいことは「読ませる」だけではありません。「問い合わせに回答したい」「申請を振り分けたい」「営業担当に次のアクションを提示したい」「CRMへの入力負荷を減らしたい」といった、業務実行に近いテーマが見えてきます。

つまり、業務実行AIエージェント 基盤を作るとは、「AIが使える環境」を作ることではありません。AIが業務に関わる範囲を明確にし、人が管理できる実行環境を作ることです。

最初に決めるべきはユースケースです

AIエージェント 要件定義の出発点は、ユースケースです。

ただし、「営業を効率化したい」「バックオフィスを自動化したい」といった大きな単位では不十分です。業務実行AIエージェントに任せるには、業務をもう一段具体化する必要があります。

たとえば、営業領域であれば、次のように分解します。

• 商談メモを要約する
• 顧客課題を分類する
• 提案書の構成案を作る
• CRM入力項目を抽出する
• 次回アクションを営業担当に通知する

このうち、どこまでをAIに任せるのかを決めます。

筆者が現場でよく確認するのは、「その業務は、AIが最後まで実行してよいものですか」という問いです。多くの場合、最初から最後まで任せる必要はありません。AIが候補を出し、人が確認するだけでも、業務負荷を下げられる可能性があります。

最初から「提案から顧客連絡まで全自動化する」と考えると、要件が膨らみすぎます。初期段階では、判断基準が明確で、影響範囲が限定され、人が確認しやすい業務から始めるのが現実的です。

おすすめは、ユースケースごとに以下を整理することです。

• 対象業務は何か
• AIが参照する情報は何か
• AIが作成・更新・通知するものは何か
• 人の確認が必要なタイミングはどこか
• 失敗した場合の影響範囲はどこまでか
• 成功した状態を何で判断するか

ここまで整理して初めて、AI実行環境に必要な機能が見えてきます。

次に決めるべきは権限です

業務実行AIエージェントで最も曖昧になりやすいのが権限です。

人間のユーザー権限と、AIエージェントの実行権限は分けて考える必要があります。人が閲覧できる情報を、AIも同じように参照してよいのか。人が更新できる項目を、AIも更新してよいのか。ここを曖昧にしたまま実装すると、後からセキュリティや監査の問題が起きやすくなります。

あるプロジェクトで、筆者は業務部門の担当者から「AIには自分と同じ権限を持たせればよいのでは」と言われたことがあります。その場で筆者は、「人間には違和感に気づいて手を止める力がありますが、AIにはそれを期待しすぎない方がよいです」と返しました。

権限設計では、少なくとも次の4つを決めます。

閲覧権限

AIがどのデータにアクセスできるかを決めます。顧客情報、契約情報、社内規程、商談履歴、問い合わせ履歴など、データの種類ごとに扱いを分けます。

実行権限

AIがどの操作まで行えるかを決めます。下書き作成までなのか、システム登録までなのか、通知送信までなのかを明確にします。

承認権限

AIが作った内容を人が確認する必要があるか、一定条件なら自動で進めてよいかを決めます。

停止権限

異常が起きたとき、誰がAIエージェントを止めるのかを決めます。

業務実行AIエージェントでは、「できることを増やす」よりも「してはいけないことを明確にする」方が重要です。最初は最小権限で始め、運用実績を見ながら段階的に広げる方が安全です。

データ連携は、読み取りと書き込みを分けて設計します

業務AI アーキテクチャを考えるうえで、データ連携は避けて通れません。AIエージェントが業務を実行するには、社内システムや外部ツールとの接続が必要になります。

ただし、データ連携を一括りに考えると危険です。まずは「読み取り」と「書き込み」を分けて整理します。

読み取り連携

AIが情報を参照することです。社内マニュアル、ナレッジ、顧客情報、商品情報、FAQ、過去の商談履歴などが対象になります。

書き込み連携

AIが何らかの情報を登録・更新・送信することです。CRMへの入力、チケット起票、メール送信、承認依頼、レポート保存などが該当します。

初期段階では、読み取り連携から始める方が安全です。AIが情報を参照し、人が最終的に確認・操作する形であれば、リスクを抑えながら有効性を検証できます。

書き込み連携に進む場合は、以下の要件を必ず決めます。

• どのシステムに書き込むのか
• どの項目を更新するのか
• 更新前に人の確認を挟むのか
• 誤登録が起きた場合に修正できるのか
• どのログを残すのか
• 連携失敗時に誰へ通知するのか

筆者は、AIエージェントの導入初期に「書き込み連携」を急がないように伝えることが多いです。なぜなら、書き込みができるようになった瞬間、AIは単なる支援ツールではなく、業務システムの一部になるからです。

AIエージェントが便利になるほど、システムに与える影響も大きくなります。だからこそ、データ連携は段階的に広げる前提で設計することが重要です。

監査ログは後付けではなく最初から設計します

業務実行AIエージェントを本番運用する場合、監査ログは重要な設計要素です。

AIが何を判断し、どのデータを参照し、どの操作を行い、誰が承認したのかを追跡できなければ、トラブル時に原因を特定しにくくなります。

監査要件では、次の情報を残せるようにします。

• 実行日時
• 実行したユーザーまたはAIエージェント
• 入力された指示
• 参照したデータ
• 生成された出力
• 実行された操作
• 承認者
• エラー内容
• 操作結果

特に重要なのは、AIの判断結果だけでなく、その判断に使われた情報も追えることです。

たとえば、AIが「この問い合わせは法務部門に振り分けるべき」と判断した場合、なぜそう判断したのか、どの分類ルールや過去データを参照したのかが分からなければ、改善も監査もできません。

これは、実務ではかなり重要です。AIエージェントの失敗は、単に「AIが間違えた」で終わらせてはいけません。入力が悪かったのか、参照データが古かったのか、権限設計が広すぎたのか、業務ルールが曖昧だったのか。原因を分解できなければ、次の改善につながりません。

監査ログは、問題が起きたときの証跡であると同時に、運用改善の材料でもあります。AIがどの業務で迷っているのか、どの例外パターンが多いのかを把握することで、プロンプト、ルール、データ整備の改善につなげられます。

セキュリティ要件は業務部門も一緒に決めます

AIエージェントのセキュリティは、情報システム部門だけで完結しません。

なぜなら、どの情報が機密なのか、どの業務が高リスクなのか、どの操作に承認が必要なのかは、業務部門でなければ判断できないからです。

セキュリティ要件では、少なくとも次の観点を整理します。

• 個人情報を含むデータを扱うか
• 顧客の機密情報を扱うか
• 契約・法務・財務に関わる情報を扱うか
• 社外送信が発生するか
• 権限を超えた情報参照を防げるか
• 誤操作時に停止・取り消しができるか
• ログの保存期間をどうするか

ここで大切なのは、「AIだから特別に考える」のではなく、既存の業務リスクにAIが加わると何が変わるかを見ることです。

人が手作業で行っていた業務にAIを入れると、処理速度が上がります。一方で、間違いが広がる速度も上がります。そのため、セキュリティ要件は導入後に追加するのではなく、要件定義の段階で組み込む必要があります。

筆者は、AI導入の相談を受けるとき、最初に「何を入れてはいけないか」を決めることを勧めています。どの情報を扱うかを決めるだけでは不十分です。扱わない情報、扱う場合にマスキングする情報、専門部門の確認が必要な情報を分けることで、現場は安心して使いやすくなります。

LLMアプリケーションでは、プロンプトインジェクションや過剰な権限付与など、従来のWebアプリケーションとは異なるリスクも指摘されています。そのため、AIエージェントに外部ツールや業務システムを操作させる場合は、入力制御、権限分離、ログ、承認フローを組み合わせて設計する必要があります。参考として、OWASP Top 10 for LLM Applicationsでは、LLMアプリケーション特有のリスクが整理されています。

AI実行環境には、人が介入できる余地を残します

業務実行AIエージェントという言葉には、「自律的に動く」という印象があります。しかし、すべてを自律化する必要はありません。

むしろ初期段階では、人が途中で確認できる設計にする方が現実的です。

たとえば、次のような設計です。

• AIが下書きを作成し、人が送信する
• AIが分類候補を出し、人が最終決定する
• AIがCRM入力案を作り、人が登録ボタンを押す
• AIが異常を検知し、人に確認依頼を出す
• AIが承認条件を満たす場合のみ次の処理へ進む

このような人間参加型の設計にすることで、業務部門も安心して使い始められます。

筆者の感覚では、AI導入で失敗しやすいプロジェクトほど、「自動化」という言葉が早い段階で強くなりすぎます。逆にうまく進むプロジェクトは、「まず人が確認できる形で業務に入れる」「判断基準が固まったら自動化範囲を広げる」という順番を守っています。

弊社が提供するKanataを活用する場合も、いきなり全自動化を目指すのではなく、AIチャット、AI要約、プロジェクト単位の学習データ管理、プロンプト管理などを組み合わせながら、まずは人が確認できる形で業務に組み込む方法が考えられます。たとえば、社内資料やFAQを学習データとして整理し、AIに回答案や要約案を作らせ、人が確認してから社内共有や顧客対応に使う。こうした段階を踏むことで、現場の不安を抑えながらAI活用を広げやすくなります。

業務実行AIエージェント 基盤は、AIだけで完結する環境ではありません。人、AI、データ、システム、承認フローがつながる操作環境として設計する必要があります。

段階的な構築ロードマップを描きます

自律AIの基盤構築は、一度に完成させるものではありません。段階的に広げる方が、リスクも手戻りも抑えられます。

第1段階：業務整理と読み取り連携

最初の段階では、対象業務を整理し、AIが参照する情報を整えます。社内資料、FAQ、マニュアル、過去の問い合わせ、営業資料などを整理し、AIが回答や下書きを作れる状態にします。

この段階では、AIは業務を実行するというより、人の判断を支援します。

たとえば、問い合わせ対応であれば、AIが社内FAQや過去対応履歴を参照し、回答案を出します。担当者は、その回答案を確認し、必要に応じて修正してから返信します。これだけでも、現場の負担を下げられる場合があります。

第2段階：人が確認する半自動フロー

次に、AIが出力した内容を人が確認し、業務に使う段階へ進みます。

たとえば、議事録案、提案書構成案、問い合わせ分類案、CRM入力案などをAIが作成し、人が修正・承認します。

この段階で、出力品質、例外パターン、業務部門の使いやすさを検証します。

筆者は、この第2段階を軽視しない方がよいと考えています。なぜなら、ここで現場がAIの癖を理解し、AIに任せられる業務と任せにくい業務を見極められるからです。AI導入は、技術だけでなく、現場側の学習プロセスでもあります。

第3段階：低リスク業務の自動実行

運用実績がたまったら、影響範囲の小さい業務から自動実行を始めます。

たとえば、社内通知、タスク起票、レポートの定期生成、分類ラベル付与などです。

この段階では、監査ログ、停止条件、エラー通知が重要になります。

自動実行に進むときは、「失敗してもすぐに戻せるか」を必ず確認します。取り消せない操作、社外に影響が出る操作、金額や契約に関わる操作は、慎重に扱うべきです。

第4段階：複数システムをまたぐ業務実行

最後に、複数のシステムをまたいだ業務実行へ広げます。

たとえば、問い合わせ内容をAIが分類し、該当する顧客情報を参照し、過去の対応履歴を確認し、担当者に回答案を提示し、承認後にCRMへ記録する。こうした一連の流れが考えられます。

ただし、この段階では業務影響が大きくなるため、承認フロー、ロールバック、セキュリティレビュー、継続的なモニタリングが欠かせません。

このように段階を分けることで、AIエージェントの価値を確認しながら、無理なく基盤を育てることができます。

要件定義で使えるチェックリスト

業務実行AIエージェント基盤を構築する前に、以下の項目を確認しておくと、検討漏れを減らせます。

業務要件

• 対象業務は明確か
• 初期ユースケースは絞られているか
• 成功条件は定義されているか
• 例外処理は洗い出されているか
• 人が確認するポイントは決まっているか

権限要件

• AIが参照できるデータは決まっているか
• AIが実行できる操作は決まっているか
• ユーザー権限とAI権限の関係は整理されているか
• 承認が必要な操作は明確か
• 停止権限を持つ担当者は決まっているか

データ連携要件

• 連携対象システムは明確か
• 読み取り連携と書き込み連携を分けているか
• データの更新頻度は決まっているか
• 連携失敗時の通知先は決まっているか
• 誤登録時の修正方法はあるか

監査・セキュリティ要件

• 操作ログを残せるか
• 参照データと出力結果を追跡できるか
• 個人情報や機密情報の扱いは定義されているか
• インシデント時の停止手順はあるか
• ログの保存期間と閲覧権限は決まっているか

運用要件

• 業務部門の責任者は決まっているか
• AI出力をレビューする担当者はいるか
• 定期的な見直しの頻度は決まっているか
• プロンプトや学習データの更新ルールはあるか
• 利用者への教育方法は決まっているか

このチェックリストは、完成した要件定義書を採点するためだけのものではありません。むしろ、業務部門、情シス、DX推進、セキュリティ担当が同じテーブルで会話するための共通言語として使うものです。

筆者がプロジェクトに入るときも、最初からきれいな設計書を作ろうとはしません。まずは、このような問いを一つずつ並べ、答えられるもの、答えられないもの、まだ部門間で認識がズレているものを可視化します。AIエージェントの要件定義は、技術文書である前に、関係者の合意形成のプロセスでもあります。

まとめ：業務実行AIエージェント基盤は、業務と責任範囲を定義してから作ります

業務実行AIエージェント 基盤の構築では、技術選定を急ぎたくなります。どのAIモデルを使うか、どのツールと連携するか、どのクラウド環境に置くかは、確かに重要です。

しかし、その前に決めるべきことがあります。

• AIにどの業務を任せるのか
• どのデータを見せるのか
• どの操作を許可するのか
• どこで人が確認するのか
• 何が起きたら止めるのか
• 誰が責任を持つのか

これらが決まっていなければ、どれだけ優れたAI実行環境を用意しても、現場では使いきれません。

筆者は、AI導入を「技術を入れるプロジェクト」ではなく、「業務の責任範囲を再設計するプロジェクト」だと考えています。特に業務実行AIエージェントでは、その性質がより強く表れます。AIが動くほど、人間の役割がなくなるのではありません。むしろ、人間が何を判断し、何に責任を持つのかを、より明確にする必要があります。

業務実行AIエージェントは、万能な自動化装置ではありません。業務を理解し、権限を設計し、監査できる形で運用して初めて、企業の中で安全に価値を発揮します。

最初から大きく作る必要はありません。まずは、業務部門と技術部門が同じ地図を持つことです。小さなユースケースから始め、ログを見ながら改善し、権限と自動化範囲を段階的に広げていく。その積み重ねが、自社に合った業務AIのアーキテクチャにつながります。

Q&A：業務実行AIエージェント基盤の要件定義でよくある質問