AIエージェントに、あなたの業務システムのどこまで触らせますか?
この問いに「全部」と答える人も、「ゼロ」と答える人も、たぶん両方間違っています。
私はカラクリのR&Dチームで、CUA(Computer-Using Agent:画面を見てマウスとキーボードを操作するAI)を含む業務自動化の研究開発をしています。本稿では、その現場から見えてきた「AIの関与度をどう配分するか」という設計論を書きます。
「答えるだけ」では、顧客のやりたいことが終わらない
従来型ボットの限界は、ナレッジを「答える」ところで止まることです。「返品をご希望の場合は、マイページからお手続きをお願いいたします」。案内はできています。でも、お客様のやりたいことはまだ終わっていない。
では「実行」まで自動化しようとすると何が起きるか。
実行とは、問い合わせ管理システムで内容を確認し、受注・在庫管理システムで注文情報を照会し、申請画面で返品を登録するという、複数の業務システムを跨いだPC作業です。人手が大変なら、ルールベースの仕組み、いわゆるRPAで自動化すればOKでは?と考えたくなります。
ルールベースが折れるのは「例外」
現実の業務には「いつもと違う」が必ず混ざります。本文に注文番号がない。返品期限が切れている。画面がエラーを出す、あるいは昨夜の仕様変更でボタンの位置が変わっている。
従来のルールベース処理は、この例外に対応できません。
より深刻なのは、対応できないことではなく、例外に気づかず誤ったまま進んでしまうことです。必要なのは、例外に対して「気づく・止まる・人に確認する」こと。トヨタ生産方式でいえば、異常で止まれるラインこそ本物の「自働化」だという話です。
一方で、CUAやBrowser Useのようなエージェント的操作は自律的で柔軟ですが、危険な操作も「できてしまう」上に、時間とAI利用コストがかかる。柔軟と安全のトレードオフです。
AIエージェントを「現場監督」にする

私たちの構想は、この2つを役割分担させることです。
責任者は「人間」で、例外の確認と最終判断を担う。現場監督は「AIエージェント」で、状況を見てツールを選び、異常なら止めて相談する。そして定型ラインはルールベースの処理で、決まった作業を確実・高速に実行する道具に徹する。
自働化の本質は「異常検知」と「安全停止」であって、全部AIに任せることではありません。
関与度は、4段階から選べる
現場監督(AIエージェント)と定型ライン(ルールベース)の担当範囲は、実は連続的に調整できます。AIの関与が大きい順に並べると、
①全操作をAIが行うフルCUA
②オーケストレータ+ルールベース
③実行は固定で判断のみAIが担うAgenticワークフロー
④AIの関与なしの完全RPA
JTB様との共同PoC(GENIAC-PRIZE応募)では、災害時に急増する旅行の振替・キャンセル問い合わせの返信対応を、③のAgenticワークフローで組みました。
エージェントの柔軟さは実行時ではなく「構築時」に使う。現場の業務をヒアリングし、手順だけでなく「どういう場合に取消料を免除するか」という判断基準まで言語化しきって、実行前にワークフローを組み切りました。実行時に、その場判断はさせません。
結果、2024年台風10号の実データ2,648件での検証で、1人あたり処理件数は24件/日から101件/日へ約4倍、返信テンプレート選定の正解率98.5%、具体情報のハルシネーションは1,946件中0件でした。
柔軟なAIをあえて安全側に倒す。この配分を選んだから出た数字です。
結論。業務自動化の設計とは、AIの賢さを競うことではなく、AIの関与度を業務ごとに調整しきることです。正解は業務・要件ごとに違う。2027年あたりから、この「泥臭い調整力」がベンダーの実力差として表面化していく、と私は見ています。
当社カラクリとしては、CUAモデルの開発を含め、この4段階を業務に合わせて選び・調整できる状態を目指して研究開発を続けています。正直に言うと、CUA自体はまだPoC段階でサービス提供には至っていません。
それでも構想を先に公開するのは、「どこまで任せたいか」を一緒に考えるところから始めたいからです。
このブログを書いた人
change_historyKARAKURI R&D team



