この記事で分かること
- AIシステムとAIエージェントの定義、両者の関係
- 一問一答チャットや分類器が、必ずしもエージェントではない理由
- 自社業務がエージェント向きかを整理する質問と判断表
- 小さく試す導入手順、人の承認、ツール権限、ログの考え方
AIシステムは、AIモデルを含む業務の仕組み全体
AIシステムという言葉は、モデルだけを指すとは限りません。業務の目的、入力データ、AIモデル、前後のプログラム、画面やAPI、データベース、利用者の確認、運用ルールなどを含めて、AIの出力が実際に使われるところまでをひとまとまりとして考えます。たとえば、問い合わせ文を分類するモデルがあっても、受信画面、分類結果の表示、担当者への振り分け、誤分類の修正方法がなければ、業務で使える仕組みにはなりません。
OECDのAIシステム定義は、入力から出力の生成方法を推論し、その出力が現実または仮想の環境に影響する機械ベースのシステムという広い捉え方です。出力には予測、コンテンツ、推奨、意思決定などがあります。この定義の射程では、結果を提案するだけの仕組みも、外部システムの状態を変える仕組みもAIシステムに含まれ得ます。人が途中で確認するか、どの程度自動で動くかによって、AIシステム全体の自律性は変わります。
このため「AIシステムを入れる」という話では、モデルの性能だけでなく、業務のどこに組み込むか、元データは適切か、誤りを誰が見つけるか、結果をどう戻すかも検討します。導入の範囲を整理したい場合は、AIシステムが必要かを確認する5つの質問を使い、既存の手順や業務システムを含めて課題を具体化すると、AIを使わない選択肢も比較しやすくなります。
AIエージェントは目標に向けて手順を進める実行パターン
AIエージェントは、利用者や業務から与えられた目標を受け取り、必要な情報を見て、作業を分け、次に行う処理を選び、ツールを使い、結果を確かめるような実行パターンです。ツールは、社内文書の検索、在庫や顧客情報の照会、記録の下書き、チケットの更新などを行う機能を指します。エージェントがすべてを自由に決める必要はありません。どの情報と操作を使えるか、どの条件なら人へ戻すかは、システム側で明示しておく必要があります。
日本のAI事業者ガイドライン第1.2版は、AIエージェントを環境を知覚し、目標達成のために自律的に行動するAIシステムとして扱っています。一方、実装の議論では使われ方に幅があります。OpenAIの実務ガイドは、LLMがワークフローの実行を制御し、状況に合わせてツールを選ぶシステムをエージェントとして説明し、一問一答の単純なチャットや単発の分類器はエージェントに含めない実務的な線引きをしています。これは実装を考えるための一つの見方であり、あらゆる場面に当てはまる唯一の定義として扱うものではありません。
共通する見どころは「AIを使っているか」だけではなく、「AIが次の業務処理を選び、複数の段階を自ら進めるのか」です。あらかじめ人が決めた順番で処理するワークフローにAIモデルを一箇所だけ組み込む形もあれば、AIが状況に応じて検索先や次の処理を選ぶ形もあります。どちらもAIシステムとして設計できますが、後者はエージェント的な制御が強くなります。
両者を単純な二択にしない
「AIシステムか、AIエージェントか」と二つの製品カテゴリーのように並べると、設計上の判断を誤りやすくなります。AIシステムは全体の境界や運用を説明する言葉、AIエージェントはその全体の中に取り入れられる行動の仕方や構成を説明する言葉として使われることがあります。あるサービスがAIエージェントと呼ばれていても、単独のモデルだけで成り立つとは限りません。認証、接続する業務ツール、データ管理、承認の仕組み、監査ログを含むシステムの一部として動きます。
逆に、AIを搭載しているというだけで、その機能をすべてエージェントと呼ぶ必要もありません。利用者の質問に一度回答して終了するチャット、入力文を決まったカテゴリへ振り分ける分類器、定型の値を抽出して固定順序のプログラムへ渡す機能は、AIシステムの一部にはなりますが、AIが作業の手順を選び直しながら進めないのであれば、通常はエージェント的な実行とは区別できます。
| 例 | AIの役割 | エージェント性の見方 |
|---|---|---|
| FAQの一問一答チャット | 質問に対して一度回答する | 会話の返答で完了するなら、エージェントとは限らない |
| 問い合わせ分類器 | 入力を定義済みのカテゴリへ分ける | 分類結果だけを返す構成なら、単発のAI機能として扱える |
| 固定順序の申請ワークフロー | 一部の欄を読み取って、決まった手順へ渡す | 次の手順が固定なら、AIを含む通常の業務システムとして設計できる |
| 例外を含む問い合わせ対応補助 | 内容を読み、社内規定を検索し、回答案を用意する | 文脈に応じて次の検索や処理を選ぶ場合、エージェント構成の候補になる |
| 注文内容の調査と記録案の作成 | 注文情報を照会し、差異をまとめる | 段階を進み、結果を検証し、人へ確認を求める構成ならエージェントとして説明できる |
同じ業務でも、設計によって位置付けは変わります。例えば、問い合わせ分類の結果を固定ルールで担当部署へ送るだけなら、分類器とワークフローで十分かもしれません。分類後に注文履歴を探し、社内規定を確認し、情報不足を尋ね、回答案を作り、必要な場合だけ人に引き継ぐようにすると、エージェント的な処理が加わります。機能名から決めず、実際に誰が次の一手を選ぶかを確認してください。
業務にエージェントが向くかを診断する
診断では、業務名ではなく「開始条件から完了までの仕事の流れ」を書き出します。例えば「受注を処理する」では広すぎます。「注文メールを受ける。注文番号を見つける。販売管理の履歴と照合する。差分があれば担当者へ確認を頼む。確認後、変更案を作る」といった形にすると、AIに任せる候補と、人が残る判断を分けられます。
| 確認する質問 | 「はい」のときに見える特徴 | 次に確かめること |
|---|---|---|
| 一つの依頼を終えるために複数の手順があるか | 単なる回答や分類でなく、検索・照合・記録などをまたぐ | 各手順の順序を固定できるか、状況で選び分ける必要があるか |
| 入力に文章、画像、メールなどのばらつきがあるか | 規則だけでは読み取りにくい表現や例外がある | AIの読み違いを後工程で発見できるか |
| 毎回、次に必要な情報や確認先が変わるか | 担当者が文脈を読んで調査順や質問を変えている | 判断材料と、判断できない場合の引継ぎ先を決められるか |
| 使うデータや操作を限定して接続できるか | 対象業務のシステムに検索・下書き用の安全な接続口がある | 閲覧権限と更新権限を分けられるか |
| 間違いが起きても、人が気付き修正できるか | 確認画面、差戻し、取消し、復旧の手順を作れる | 取り返しのつかない操作を先に除外できるか |
| 品質を例題や記録で測れるか | 処理時間だけでなく、誤りや手戻りを確認できる | 運用開始前と開始後を同じ基準で比較できるか |
| 担当者が例外時に判断する根拠を説明できるか | 手順書、規程、過去記録など参照元がある | 情報が矛盾したとき、どの人へ戻すか定められるか |
「はい」が多いことは、エージェントを試す候補を見つける手がかりであり、そのまま自動化の承認を意味しません。特に、データへの接続や操作権限を適切に限定できない、誤りを発見する方法がない、根拠となる規程が曖昧という場合は、まず業務整理や既存の手順改善に戻ります。複雑さが高くても、安全に実験できなければ自律実行を広げる段階ではありません。
AIシステム自体を導入する必要があるかをまだ判断できない場合は、AIシステム導入前の確認ポイントから業務課題と既存手段を整理できます。活用領域の候補を探している場合は、業務別のAIシステム活用事例も参考にし、自社の工程やデータに置き換えて検討してください。
診断結果を四つの方向に分ける
| 業務の状態 | 向いている構成の候補 | 理由 |
|---|---|---|
| 件数が多く、条件と順序が安定している | ルールベースの自動化や既存システム改修 | 毎回同じ手順なら、動作を固定した方が検証しやすい |
| 文書の読み取りや分類が必要だが、後続処理は決まっている | AI機能を組み込んだ通常の業務システム | AIを使う箇所を限定でき、処理全体は決定的な手順で管理できる |
| ばらついた依頼を調査し、複数の情報を見て手順を選ぶ | 人の確認を含むエージェントの小規模試行 | 文脈に応じる余地はあるが、まず確認付きで品質を把握する |
| 法的、金銭的、安全上の影響が大きく、誤りを容易に戻せない | 人が判断する支援システム。自動実行は限定または保留 | AIが調査や下書きを補助しても、責任ある判断者を明確に保てる |
表の分類は、業務設計を始めるための目安です。実際には、同じ企業でも工程ごとに適した構成は違います。例えば、請求書処理なら、書類から項目を読み取る部分にはAIを使い、金額照合や承認経路は決められたロジックで実行し、差額があるときだけ担当者へ回す設計が考えられます。初めから全体を一つのエージェントへ任せる必要はありません。
エージェントを試しやすい業務と慎重に扱う業務
小さな範囲で試しやすい業務
比較的試しやすいのは、複数の情報源を確認する必要があり、成果物を人が見てから使え、誤りを後で修正できる業務です。問い合わせの調査と返信案、社内規程に基づく申請内容の確認案、複数の社内資料を集めた定例レポートの草案などが候補になります。いずれも「自動で顧客へ送信する」「承認を確定する」までを最初の対象に含めず、検索や下書きの範囲から始められます。
候補を選ぶときは、作業頻度だけでなく、例外処理の量と確認コストを見ます。数秒で終わる定型作業は、エージェントを作るより既存機能や小さな連携で解決した方が簡単なことがあります。担当者が毎回まったく違う判断をし、正解を確認する材料もない仕事では、モデルの出力を採点すること自体が難しくなります。処理時間が長いという理由だけで、適性を決めないようにします。
人の判断を中心に残したい業務
最終的な責任や影響が大きい操作では、AIの提案と確定操作を分けます。返金、支払、契約条件の確定、採用や評価に関する判断、個人情報の開示、設備や安全に関わる指示などは、業務ごとに適用ルールを確認し、権限ある人が決める工程を残すべきです。AIに資料を集めさせ、必要情報や根拠を並べさせる支援は考えられますが、確認者、承認基準、記録の残し方まで整えてから利用します。
また、規程が頻繁に変わる、参照元が複数あり相互に矛盾する、データが欠落している、といった業務は、エージェントを作っても根本の問題は解決しません。まず情報の所有者や最新版、優先されるルール、例外時の相談先を決めます。AIが不確かな入力に対してもっともらしい続きを作ることを防ぐには、処理を止めて人へ確認する条件を具体化する必要があります。
段階的に導入し、実行範囲を少しずつ決める
エージェントは、試作品の段階から本番データを自由に更新できるようにする必要はありません。最初は仕事の流れを観察し、AIが何を読み、どこで迷い、何を提案したかを人が確認します。出力がよく見える例だけでなく、情報不足、例外、誤った参照先などが含まれる例で評価します。人の確認を挟んでも、調査や転記の手間が減るかを測ることが最初の判断材料です。
| 段階 | AIが行うこと | 人が行うこと | 進む前の確認 |
|---|---|---|---|
| 業務整理 | なし、または手順の整理補助 | 対象範囲、例外、判断責任を定義する | 業務の開始・終了条件と記録場所が分かる |
| 閲覧と提案 | 許可された資料を検索し、要約や案を出す | すべての提案を確認し、利用可否を決める | 参照元と誤りの種類を記録できる |
| 下書きと限定操作 | 記録案や更新案を作り、限定された操作を準備する | 確定前に内容・対象・影響を承認する | 権限、取消し手順、失敗時の連絡先が整う |
| 条件付き実行 | 範囲を限定した低リスク処理だけを実行する | 例外と高リスク操作を承認し、結果を点検する | 実績に基づく品質基準、停止条件、監視担当がある |
次の段階に移る条件は、「慣れてきたから」ではなく、対象業務の記録を使って決めます。人の確認を経た後の修正数、誤った対象へ行いかけた操作、根拠のない回答、処理の中断、例外時の引継ぎなどを記録します。達成率だけを見ると、少数の重大な誤りや、担当者が修正に費やした時間を見落とすことがあります。期待した改善が確認できなければ、権限を広げず、指示や手順、データの問題を直します。
業務によっては、読み取りと草案作成だけで十分な成果があります。すべてを自動で完了させることを導入の成功条件に置かず、人の確認を残したままで何が減るかを測ると、安全性と業務効果の両方を検討できます。
ツール権限、人の承認、ログを実装に含める
AIエージェントが社内システムを操作する場合、入力を読む機能と、記録を書き換える機能を別々に管理します。最初の試行では、参照だけ、検索だけ、または下書きだけに限定し、必要になった操作を一つずつ追加します。共有の管理者アカウントや個人のログイン情報を使い回さず、担当業務と環境に対応した専用のアクセス権を設定します。利用者の権限をそのまま無制限に引き継ぐと、誤操作の影響もその範囲まで広がりかねません。
更新操作を認めるときは、対象レコードや項目、金額や件数の上限、実行できる時間、操作可能な状態などをプログラム側で制約します。AIの指示だけに「上限を守る」と書いても、技術的な制限の代わりにはなりません。やり直しが難しい処理や、顧客・取引先へ外部送信する処理は、内容と宛先を人が承認してから実行する設計にします。停止ボタン、更新の取消しや復旧手順、エラー時に担当者へ引き継ぐ経路も準備します。
エージェントが検索する文書や受信メールには、業務上の情報だけでなく、無関係な命令文や不正な誘導が含まれる可能性があります。取得した文章をそのままシステムの指示として扱わず、利用可能な情報源、実行できる操作、外部送信の条件を別の制御として設けます。接続先を許可リストで限定し、秘密情報や個人情報の扱い、画面やプロンプトに含めない値も、利用するサービスの仕様と社内ルールに照らして決めます。
ログには、誰の依頼で動いたか、業務の識別子、参照した情報、呼び出したツール、実行前後の状態、承認者、エラーや引継ぎ先などを、調査に必要な範囲で残します。記録には個人情報や機密情報が混ざる場合があるので、閲覧者、保存期間、マスキング方法も決めます。ログの量だけを増やすのではなく、後から「何を根拠にどの操作を試み、誰が承認し、結果がどうなったか」を追えることが重要です。
2026年2月にNISTの国立サイバーセキュリティ卓越センター（NCCoE）が公表した資料は、ソフトウェアエージェントの識別・認可や監査などを検討する潜在的プロジェクトに向けたコンセプトペーパーで、公開意見を募るものでした。これは各社に適用される確定済みの義務的標準を発表したものではありません。一方で、誰の権限を受けて動いたか、どの操作を許されたか、後から追跡できるかが、実務上の設計論点になることは参考になります。自社の環境に合わせた事前確認には、AIシステムの導入前リスクチェックリストも活用してください。
運用後に見直す指標と担当
運用を始めたら、モデルの回答精度だけでなく、システム全体の結果を見ます。確認候補としては、処理の完了・中断・人への引継ぎ、回答や更新案の修正、誤った対象を選んだ操作、処理にかかった時間、確認者の作業量、利用コストなどがあります。業務ごとに何を改善したいのかを先に決め、同じ条件で導入前後を比べます。失敗例の種類が変わったときは、評価用の記録を更新し、改善後も同じ問題が起きないかを確かめます。
担当者は、AIを作る技術チームだけでは足りません。業務手順を説明できる担当者、接続先データの管理者、アクセス権を管理する人、出力と操作を監視する人、問題発生時に停止を決める責任者が必要です。小規模な試行でも、誰が「AIの提案を採用するか」「不具合を報告するか」「接続を止めるか」を曖昧にしないようにします。モデルや接続先が変わった場合に、影響範囲と再確認の要否を判断する手順も用意します。
まとめ：業務の判断範囲から方式を選ぶ
AIシステムはAIを業務に組み込む全体の仕組みであり、AIエージェントはその中で目標に向かって複数の処理を選びながら進める構成になり得ます。二つを対立する選択肢と考えず、業務のどこをAIに任せ、どの操作を人が決めるかに分解すると設計しやすくなります。
毎回の条件と処理順が決まっているなら、ルールや通常のワークフローで足りる可能性があります。文章の読解や判断の補助が必要でも、後続処理が固定なら、AI機能を含む業務システムとして設計できます。複数の情報を調べ、状況に応じて手順を選ぶ仕事はエージェントの試行候補ですが、まず閲覧、検索、下書きなど限定した範囲から始めます。人の承認、権限、ログ、停止方法をあわせて設計し、業務記録に基づいて実行範囲を見直してください。
よくある質問
AIエージェントは、AIシステムより高度な製品ですか？
必ずしもそうではありません。AIシステムはモデル、業務データ、画面、接続、運用を含む広い仕組みを指します。AIエージェントは、その中でAIが目標に向けて手順を選び、ツールを使いながら仕事を進める構成として導入できます。名称や価格帯ではなく、実際にどこまで判断し、何を操作するかで比べてください。
社内向けの一問一答チャットもAIエージェントですか？
質問に答えて終了するだけのチャットは、AIを使うシステムではありますが、実務上のエージェントとは区別されることがあります。例えば、質問の内容に応じて社内規程を検索し、追加情報を尋ね、回答案を作り、所定の窓口へ引き継ぐような多段階の動きを設計すると、エージェント的な構成に近づきます。
AIエージェントに承認なしで業務を完了させてもよいですか？
最初から広い自動実行権限を与えるのは避けます。閲覧や案の作成から始め、失敗時の影響が小さく、結果を検証でき、元に戻す方法がある操作に限って自動化を検討します。顧客への送信、金銭の移動、契約や権利に関わる確定などは、業務責任者による承認を残す設計が適切です。
導入の最初にどの業務を選べばよいですか？
頻度があり、複数の情報を確認する必要がある一方、誤りを人が見つけて修正できる業務から検討します。業務の開始条件、使えるデータ、例外、最終承認者を紙や表に書き出し、AIの下書きや検索だけで効果を測れる範囲を決めると、小さく試しやすくなります。
AIエージェントと通常の業務自動化は併用できますか？
併用できます。文章の理解や例外候補の抽出をAIに任せ、金額チェック、承認条件、登録順、アクセス制御などは決定的なプログラムで管理する構成も考えられます。AIが判断する部分を必要最小限に分けると、結果を検証しやすくなります。
