長期稼働するAIエージェント導入で最初に決めるべきこと｜承認ポイントの設計

長期稼働するAIエージェント導入で最初に決めるべきこと｜承認ポイントの設計

AIエージェントのPoCで「このタスクなら正しくこなせる」ことを確認できたとして、次に「では業務の一部を任せよう」という段階に進むとき、何を新たに評価すればよいのでしょうか。単発タスクの精度確認と同じ物差しを使い続けると、見落とす論点が出てきます。

2026年9月11日、Salesforceは職務別のAIエージェント7種を発表し、あわせて「long-horizon runtime」——数日から数週間にわたってゴールを追い続けるための実行基盤——を新設したと明らかにしました(Salesforce公式発表)。この記事では、この発表の中にある一つの設計判断——「どこで人が承認するか」という点をどう位置づけるか——を手がかりに、長期実行するAIエージェントを評価するときの視点を整理します。

30秒で要点

• Salesforceは2026年9月11日、数日〜数週間ゴールを追い続けるAIエージェントの実行基盤「long-horizon runtime」を発表した
• 営業支援エージェント「Hunter」の説明では、タスクやツールの設定だけでなく「いつ自律的に動き、いつ人の承認が必要か」というガードレールの位置そのものが、事前に設計される前提になっている
• 単発タスクの精度評価と、長期実行を任せてよいかどうかの評価は、別の軸で考える必要がある
• 顧客事例の数値(解決率・パイプライン構築率など)は分母の定義がまちまちで、そのままでは比較材料にならない

long-horizon runtimeが変えようとしていること

Salesforceの発表文は、long-horizon runtimeを「エージェントがタスクや一度のやり取りを完了するだけでなく、数日から数週間にわたってゴールを追い続けられるようにする」ための基盤だとしています。これを支える機能として、セッションをまたいで文脈と進捗を保持する「Memory」、状況の変化に応じて再開・軌道修正する「Durable execution」、利用者個人のフィードバックで振る舞いを変える「Dynamic steering」の3つが挙げられています。

この基盤の上で動く最初のエージェントとして紹介されているのが、営業支援を担う「Hunter」です。発表時点では現時点で唯一long-horizon runtime上で動くエージェントであり、パイロット段階(一般提供は2026年11月を予定)にあるとされています。Hunterの動作説明には、タスクの内容・使うツール・参照する文脈を決めるだけでなく、「いつ自律的に動いてよく、いつ営業担当者の承認が必要かを定義するガードレール」を決めることが含まれる、と明記されています。

なぜ「精度が上がれば任せられる」と考えてしまうのか

PoCの段階では、評価の物差しは基本的に一つです。「このタスクを、どれくらいの精度でこなせるか」。この物差しに慣れていると、「業務に任せる」段階に進む判断も、同じ物差しの延長——つまり精度がさらに上がれば任せてよい——として捉えてしまいやすくなります。

しかし、単発の応答と、数週間にわたって走り続けるエージェントとでは、間違えたときに起きることの性質が変わります。単発の応答であれば、間違いに気づいた時点で人が訂正すればよいことが多いですが、長期実行するエージェントは、その間違いに気づかれないまま次の判断の前提として積み上がっていく可能性があります。Hunterの説明で承認ガードレールが「タスクの設定」と並んで明示されているのは、この違いを踏まえた設計だと読めます。精度の評価軸と、どこまで自律的に進めてよいかの評価軸は、もともと別のものだったのではないか——この発表を読んで、そう捉え直す必要を感じました。

承認ポイントをどこに置くかという判断

では、承認ポイントはどのような基準で決めればよいのでしょうか。Salesforceが2026年4月に発表した別の仕組み「Agent Fabric」には、手がかりになる考え方が2つ含まれています。一つは「guided determinism」——受け渡しの規則(いつ・どこで人に戻すか)は固定し、その間の推論だけをLLMに任せる設計です。もう一つは「Trusted Agent Identity」——送金や法務レビューのような高リスクの行為に対して、個別にモバイル承認を求める仕組みです。

（なお、この発表は検索結果や一部の二次報道では9月の発表として扱われがちですが、Salesforce公式ページの記載を確認すると公開日は2026年4月15日です。9月に発表されたlong-horizon runtimeとは別の時点の情報として扱う必要があります。）

この2つの考え方に共通しているのは、「承認が必要かどうか」を精度で判断するのではなく、その行為が間違っていた場合に、どこまで取り返しがつくかで判断している点です。取り返しがつく行為(社内向けの下書き作成など)は自律範囲を広く取り、取り返しがつきにくい行為(対外発信・送金・契約に関わる判断など)は、精度に関わらず承認を残す。この線引きを、導入前にどこまで具体的に言語化できているかが、long-horizon型のエージェントを評価するときの最初の論点になります。

顧客事例の数値をそのまま比較材料にしない

Salesforceの発表では、過去2年間でAgentforceとSlackを合わせて累計70億のAgentic Work Unit(AWU)を提供し、うちQ2だけで32億という数値も示されています。大きな数字ではありますが、AWUという単位自体の定義は、この発表ページ上には記載されていません。「何を1件と数えているか」が分からない状態で、自社の業務規模や成果と比較することはできません。

同様に、個別の顧客事例として紹介される解決率やパイプライン構築率などの数値も、算出の分母(「エージェントが対応した会話のうち」なのか「全問い合わせのうち」なのか)や測定期間がページ上に明記されていないことが多くあります。数値の大きさに気を取られる前に、その数値が何を分母にしているかを確認する——このワンクッションを挟むだけで、期待値のズレをかなり防げます。

確かなことと、まだ確かではないこと

確かなこと: Salesforceが2026年9月11日にlong-horizon runtimeと職務別AIエージェント7種を発表したこと。Hunterの説明において、承認ガードレールの設計がタスク設定と並ぶ要素として明記されていること。Agent Fabricのguided determinism・Trusted Agent Identityが2026年4月時点で発表されていたこと。

まだ確かではないこと: long-horizon runtime上で実際にHunter以外のエージェントがどう動くかは、パイロット段階のため一般提供(2026年11月予定)後にならないと分かりません。AWUや顧客事例の数値についても、算出方法の詳細が公開情報だけでは確認できていません。

自分でも試せる、最小の検証

自社で検討しているAIエージェントの業務について、「このタスクのうち、間違えたときに取り返しがつかない部分はどこか」を一つだけ書き出してみてください。それが特定できれば、そこにだけ承認ポイントを置き、それ以外は自律的に進めてよい範囲として切り分けられます。精度の議論から入るのではなく、この線引きから始めると、導入判断に必要な論点が一段整理された状態で議論に入れます。

判断軸の提示

長期実行するAIエージェントを評価するときは、「精度がどれだけ高いか」ではなく、「間違えたときにどこまで取り返しがつくか」を基準に、承認ポイントをどこに置くかを先に決めること。 この線引きが曖昧なまま精度の議論だけを進めると、任せてよい範囲についての合意がないまま運用が始まってしまいます。

この記事で扱ったような判断を、自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。