AIエージェントのUXはチャットの先にある——Ambient Agentという考え方

はじめに

こんにちは！
株式会社エクスプラザのhyodoです！

AIエージェントを開発していて、こんな声を聞いたことはありませんか？

「便利なのは分かるんだけど、毎回チャットで指示するのが面倒」
「経費精算をお願いしたいけど、何て言えばいいのか分からない」
「前にお願いした件の続きやってほしいんだけど、また最初から説明するの？」

AIエージェントを作ったのに使ってもらえない。使ってもらっても定着しない。この問題、技術の出来が悪いのではなく、UIの選択が間違っているケースが多いです。

AIエージェントといえばチャットUI——この思い込みを一度疑ってみると、まったく違う設計が見えてきます。今回は、**Ambient Agent（アンビエントエージェント）**という考え方を紹介します。

Chat Agentの何が限界なのか

チャットベースのAIエージェント（Chat Agent）は直感的で、導入のハードルも低いです。ただ、業務で日常的に使うものとして見ると、いくつか限界があります。

毎回「話しかける」必要がある

Chat Agentはユーザーの指示を起点に動きます。何かをやってほしいたびに、チャット画面を開いてプロンプトを入力しなければなりません。

1回や2回なら問題ないですが、請求書の処理やレポート作成のような定型業務を毎回チャットで依頼するのはかなり面倒です。結局「自分でやったほうが早い」になりがちです。

同時に1つの会話しか扱えない

チャットのインターフェースは、基本的に1つの会話スレッドを順番に進めていく構造です。複数のタスクを並行して進めたい場合、ウィンドウを切り替えながら会話を管理する必要があります。

「AIで仕事をスケールさせる」という話をよく聞きますが、チャットUIだとその恩恵が出にくいです。

ユーザーが「何ができるか」を想像しにくい

Chat Agentは見た目がただのテキスト入力欄なので、裏側にどんな機能があるのかユーザーには見えません。「この請求書を処理しておいて」と言えば動くのか、「先週頼んだ請求書処理の続きをお願い」で文脈を理解してくれるのか、試してみるまで分かりません。

「何でもできそうに見えるが、実際には何ができるか分からない」という状態は、ユーザーにとってかなりストレスです。

Ambient Agentという発想

Ambient Agentとは

Ambient Agentは、チャットでの指示を起点にするのではなく、業務上のイベントをトリガーにして自律的にタスクを実行するAIエージェントです。

「Ambient」は英語で「環境の」「周囲の」という意味です。空気のようにそこにいて、ユーザーが意識しなくても仕事が進んでいる。そんなAIエージェントの在り方を指しています。

ポイントは2つあります。

イベント駆動で起動する。 ユーザーが話しかけるのを待つのではなく、ファイルのアップロード、メールの受信、カード決済、カレンダーの登録といった業務上のイベントを検知して、エージェントが自分から動き出します。

特定の業務に特化したエージェントが無数に存在する。 1つの万能なエージェントが全部やるのではなく、請求書処理エージェント、採用オンボーディングエージェント、契約書チェックエージェントといった具合に、業務ごとに専門のエージェントがいます。それぞれが自分の担当範囲のイベントを拾って処理する形です。

Chat AgentとAmbient Agentの違い

この2つの違いを、請求書の処理を例に比べてみます。

Chat Agentではユーザーが3回操作していた（指示入力、PDF添付、確認応答）のが、Ambient Agentでは承認ボタンを1回押すだけです。しかもユーザーが自分から動く必要がありません。請求書メールが届いた時点でエージェントが勝手に処理を始め、結果だけが通知されます。

ユーザーが本当に欲しいのは「何もしなくていい」体験

請求書の処理にワクワクする人はそういないと思います。PDFを開いて金額を確認して、勘定科目を選んで仕訳を切って——やらなければならないけどやりたくない業務です。

この種の業務における理想の体験は「処理ツールが便利になること」ではなく、**「何もしないまま処理が終わっていること」**です。車に例えれば、カーナビが高性能になることではなく、目的地を設定したら自動で到着していること。いわば業務の自動運転です。

Ambient Agentはこの「何もしなくていい」体験と相性が良いです。業務上のイベントが発生した時点で必要な情報（誰から、いつ、いくら、何の取引か）が揃っていれば、チャットを介さないほうがむしろシンプルです。

「大きなエージェント」は幻想——小さく分割する

1つの万能エージェントにやらせたくなる誘惑

LLMの能力が上がるにつれて、「1つの賢いエージェントに全業務を任せればいいのでは」という発想が出てきます。MCPやCUA（Computer Use Agent: PC画面を認識して操作するエージェント）で外部システムとの接続が容易になったことも、この考えを後押ししています。

ただ、実際にAIエージェントを開発してみると、この「大きなエージェント」はうまくいかないケースが多いです。

なぜ大きなエージェントはうまくいかないのか

「コンテキスト汚染」が起きる。 エージェントに与える情報（ツールの説明、過去の履歴、ナレッジなど）が増えすぎると、本来注目すべき情報が埋もれてしまいます。100個のツールを与えられたエージェントは、どのツールを使うべきか判断するだけで精度が落ちます。

ドリフトが起きやすい。 長く複雑なタスクを1つのエージェントに丸投げすると、途中で目的から逸れていく現象（ドリフト）が起きやすくなります。翻訳→レビュー→修正案作成のような複数工程を一気にやらせると、最初の翻訳の方針がレビュー段階で変わってしまったりします。

デバッグが困難になる。 何か問題が起きたとき、「どの工程で判断を間違えたのか」を特定するのが大きなエージェントだと難しいです。

小さく分割して並べる

Ambient Agentの世界観では、大きなエージェントの代わりに業務領域ごとに特化した小さなエージェントが無数に存在します。請求書処理エージェント、顧客管理エージェント、法務チェックエージェント——それぞれが自分の領域のイベントだけを拾って処理します。

1つのエージェントの責務を小さく保つことで、コンテキスト汚染もドリフトも起きにくくなります。複数工程があるタスクは、工程ごとにエージェントを分けて連携させます。翻訳エージェント、レビューエージェント、統合エージェントといった具合です。

チャットUIだと「1つのチャットから全部やらせる」設計に引きずられやすいですが、イベント駆動なら自然と小さなエージェント単位に分割できます。

Ambient Agentに不可欠なHITL

なぜ完全自律にしないのか

ここまでの話だと「全部AIに任せればいい」ように聞こえるかもしれませんが、現時点ではそうはいきません。

LLMの判断にはまだブレがあります。あいまいな状況、例外的なケース、リスクの高い意思決定——こういう場面でAIが間違った行動を取ると、特にミスの許容度が低い業務では深刻な影響が出ます。

ここで必要になるのが**HITL（Human in the Loop）**です。AIの処理フローの中に、人間の判断・確認ポイントを組み込む設計思想です。

HITLのポイントは、これを「AIの限界を補う苦肉の策」ではなく**「AIを本番で使うための前提条件」**として捉えることです。適切なタイミングで人間の確認を挟むことで、ユーザーはAIに業務を任せる安心感を持てます。Claude CodeやCursorなどのコーディングエージェントも、適切なタイミングで人間のレビューを挟むことで本番利用が成り立っています。

リスクレベルで介入タイミングを決める

HITLの設計で最初に考えるべきは「どこで人間を挟むか」です。これは業務のリスクレベルで判断します。

事後報告型（低リスク）: エージェントが自律的に処理を完了し、結果だけをユーザーに報告するパターンです。やり直しがきく業務や、判断基準が明確な業務に向いています。たとえば、受信メールを内容に応じて自動でラベル分類する、社内チャットの内容から議事録のドラフトを作成して共有する、といった処理です。

途中確認型（中リスク）: エージェントが処理を進める中で、判断に迷う箇所が出てきたら人間に確認するパターンです。推測で埋めずに素直に聞いてくる設計です。たとえば、受注データの入力で「この商品コードは新規ですが、既存の○○と同じカテゴリでよいですか？」と確認する、といった処理です。

事前承認型（高リスク）: エージェントが処理内容を準備し、人間の承認を得てから実行するパターンです。取り消しが難しい操作や、金銭・法務が絡む処理に対して使います。たとえば、エージェントが作成した発注書の内容を購買担当が最終確認してから送信する、本番環境へのデプロイ内容をエージェントがまとめ、エンジニアが承認してから実行する、といった処理です。

実際のプロダクトでは、この3つを業務の性質に応じて組み合わせます。同じ業務でも金額やケースによってリスクレベルが変わるので、条件分岐で切り替える設計にしておくと柔軟に対応できます。

HITLはエージェントを賢くする仕組みでもある

HITLは安全装置としてだけでなく、AIの継続的な改善の仕組みとしても機能します。

人間が「ここは違う」「こう直して」とフィードバックするたびに、エージェントにとっての学習データが蓄積されます。事後報告を見て「この分類は間違い」と指摘されたら分類ルールを改善する、途中確認の回答パターンが蓄積されたら次からは自動判断できるようになる——こうしてHITLの介入頻度が徐々に減り、業務の自動運転に近づいていきます。

Ambient Agentを支えるアーキテクチャの勘所

Ambient Agentを実現するには、チャットボットとは異なるアーキテクチャが必要です。開発者が考えるべきことを、4つの問いで整理します。

① エージェントに何を考えさせるか

エージェントの「頭脳」にあたる部分です。中核はシステムプロンプトで規定する推論ロジックですが、それだけでは足りません。業務手順書や社内規定といった参照知識を持たせることで、ドメインに特化した判断ができるようになります。

加えて、過去の処理履歴やユーザーの傾向を記憶する仕組みがあると、「前回この勘定科目を選んだ」「このユーザーは毎月この取引先と取引がある」といったパーソナライズされた振る舞いが可能になります。

② エージェントに何をさせるか

エージェントが外部に対して実行するアクションの設計です。ここで大事なのが、業務タスク単位でAPIを切ることです。

従来のAPIはリソース単位（RESTful）で設計されていますが、エージェントにとっては「請求書を処理する」のような1回の呼び出しで複数リソースの操作が完結するAPIのほうが扱いやすいです。エージェントが何回もAPIを叩いてリソースを組み合わせる設計だと、途中でエラーが起きたときのリカバリが複雑になります。

実現手段としては、MCP（Model Context Protocol）サーバーとして業務ロジックを公開する方法があります。MCPサーバーの中に「請求書を処理する」「発注書を作成する」といった業務タスク単位のツールを定義し、エージェントはそれを呼び出すだけにすると、エージェント側の実装がシンプルになります。

③ 複数のエージェントをどう束ねるか

Ambient Agentは小さなエージェントが無数に存在する世界です。イベントが発生したとき、どのエージェントに処理を振るのか。複数のエージェントが関連するタスクをどの順番で実行するのか。人間の承認待ちでタスクが一時停止したとき、その状態をどう保持するのか。

こうしたオーケストレーションの仕組みが必要になります。特に状態の永続化は見落としがちですが、Ambient Agentは人間の承認を待つ場面が多いので、「数時間後に承認されても処理が再開できる」設計が求められます。

④ どう安全に運用するか

業務で使う以上、「エージェントがいつ、何を、なぜやったのか」を追跡できなければなりません。

入出力の検証（いわゆるガードレール）でエージェントの暴走を防ぎつつ、実行ログを蓄積してトレーサビリティを確保します。問題が起きたときの原因特定だけでなく、ログを使ったエージェントの精度モニタリングと評価の仕組みを回すことで、継続的にエージェントを改善していきます。

また、エージェントは人間から権限を委譲されて動作するので、「どのユーザーの代理として動いているか」「どのデータにアクセスしてよいか」を制御する認証・認可の仕組みも必要です。組織図や権限マスタと連動させて、エージェントの行動範囲を適切に制限します。

まとめ

AIエージェントのUXは、チャットだけがゴールではありません。

Chat Agentの限界: 毎回指示が必要、並列処理できない、何ができるか見えない。定型業務の自動化にはチャットUIは向いていない。

Ambient Agentの発想: イベント駆動で起動し、特化した小さなエージェントが無数に存在する。ユーザーが意識しなくても仕事が進む「業務の自動運転」を目指す。

小さなエージェントに分割する: 大きな万能エージェントはコンテキスト汚染やドリフトで精度が落ちる。業務領域ごとに分割し、それぞれの責務を小さく保つ。

HITLで本番運用を成立させる: リスクレベルに応じて事後報告・途中確認・事前承認を使い分ける。HITLはAIの学習データにもなり、介入頻度は徐々に減っていく。

アーキテクチャの転換: 「何を考えさせるか」「何をさせるか」「どう束ねるか」「どう安全に運用するか」——チャットボットとは異なる4つの問いでアーキテクチャを設計する。

「AIエージェント＝チャットUI」という前提を外すと、設計の選択肢が広がります。

最後までお読みいただきありがとうございました！

参考リンク

• Model Context Protocol 公式サイト — エージェントと外部システムの接続を標準化するプロトコル
• Anthropic - Building effective agents — エージェントの設計パターン（ワークフロー型 / 自律型）とツール呼び出しの実装指針
• Human-in-the-Loop for AI Agents: Best Practices — Permit.io — HITLの設計パターンと主要フレームワーク（LangGraph, HumanLayerなど）の比較
• How to Build Human-in-the-Loop Oversight for AI Agents — Galileo — 信頼度スコアに基づくエスカレーション設計と、同期/非同期の介入パターン