🧠 AI プロダクト動向

従来の顧客対応ボットは、条件分岐を手作業で積み上げる決定木で作られていた。担当者が想定するシナリオを列挙し、それぞれに分岐を用意する方式だが、実際の問い合わせは想定した分岐の間をすり抜ける。かといって手順を一切固定せずLLMの自由な会話に任せると、返金や解約のように取り消せない操作まで確認なしで実行してしまうリスクが残る。Decagonが「Agent Operating Procedures（AOP）」と呼ぶ設計は、この両端を避ける。業務担当者は手順を自然言語で書き、それが構造化されたロジックとして実行される一方、返金処理や本人確認のような機微な操作にだけ、エンジニアがコード側の検証を追加する。

この二層構造が広がっているのは、権限を「誰が手順を書くか」で分けると、業務の変更速度と安全性を両立できるからだ。業務側が自然言語で書き換えられる範囲はイテレーションを止めず、コードでしか変更できない範囲は監査対象を絞り込める。Decagonは導入から本番稼働まで3〜6週間という具体的な期間も公表しており、抽象的な設計思想ではなく運用のフェーズとして定着していることがうかがえる。

Sierraは顧客対応エージェントの安全性を、1つのプロンプトの精度ではなく4層のチェックの積み重ねとして設計している。まずナレッジベースの内容に応答を根拠づける層、次に「競合製品と比較しない」のような自然言語のルール層、そのうえで会話をリアルタイムに監視し逸脱があれば書き換えやブロックを行う「監督エージェント」層、最後にモデルの判断を介さない決定的なガード層が続く。決定的ガードの具体例は、本人確認が済むまで口座変更ツール自体をエージェントに渡さないというもので、確認ダイアログではなくツールの可視性そのものを制御する。

1件のメッセージに対して、この中の複数のチェックが同時に走る設計になっているのは、生成モデル単体の指示追従性を信頼しないという前提があるからだ。プロンプトでルールを守らせる層と、モデルの判断を経由しない層を分けておけば、片方が突破されてももう片方が残る。会話型の顧客対応エージェントで『監督役のエージェントが主エージェントを常時監査する』構成を採る例は、開発ツール向けのサンドボックス設計とは異なる形で同じ『事前に構造で縛る』発想の応用と言える。

Sierraは顧客対応エージェントを単一のLLMで動かさず、15以上のモデルを役割ごとに割り当てる「constellation」構成を採る。推論に強いモデルは応答が遅くなりがちで、応答が速いモデルは複雑な方針の理解に弱いというトレードオフがあるため、注文管理のような低遅延のツール呼び出し、不審な挙動を見分ける高精度の分類、長い規約文書を読む長文脈の推論、ブランドに合った文面調整をそれぞれ別モデルに担わせ、オーケストレーションと経路選択は会話設計者の目に触れないところで自動化されている。

同じ発想はAdaのPlaybooksにも見られ、公式ブログは課題を「推論の深さか応答速度かの二択ではなく、どのステップにどのモデルを、どの範囲で使うかだ」と説明している。1回のリクエスト単位でモデルを選ぶ従来型のルーティングと異なり、これは1つの会話ターンの中でサブタスクごとにモデルを切り替える粒度の設計で、顧客対応エージェントが分類・検索・生成・トーン調整のように性質の異なる仕事を1ターンでこなすようになったことの帰結だ。