従来の顧客対応ボットは、条件分岐を手作業で積み上げる決定木で作られていた。担当者が想定するシナリオを列挙し、それぞれに分岐を用意する方式だが、実際の問い合わせは想定した分岐の間をすり抜ける。かといって手順を一切固定せずLLMの自由な会話に任せると、返金や解約のように取り消せない操作まで確認なしで実行してしまうリスクが残る。Decagonが「Agent Operating Procedures（AOP）」と呼ぶ設計は、この両端を避ける。業務担当者は手順を自然言語で書き、それが構造化されたロジックとして実行される一方、返金処理や本人確認のような機微な操作にだけ、エンジニアがコード側の検証を追加する。
この二層構造が広がっているのは、権限を「誰が手順を書くか」で分けると、業務の変更速度と安全性を両立できるからだ。業務側が自然言語で書き換えられる範囲はイテレーションを止めず、コードでしか変更できない範囲は監査対象を絞り込める。Decagonは導入から本番稼働まで3〜6週間という具体的な期間も公表しており、抽象的な設計思想ではなく運用のフェーズとして定着していることがうかがえる。
", "examples": [ { "product": "Decagon（Agent Operating Procedures）", "approach": "自然言語の手順を構造化ロジックにし、機微操作だけコードで検証", "detail": "NG.CASHの事例で解決率(deflection rate)が70%まで向上したと公式ブログが報告。導入は3〜6週間で本番稼働に至るとしている", "source_url": "https://decagon.ai/blog/from-sops-to-agent-operating-procedures" } ], "takeaway": "自社で顧客対応エージェントを作るなら、最初に『誰が何を書けるか』の境界を決める。業務側が自然言語で編集できる範囲と、後戻りできない操作だけエンジニアのコードを通す範囲を分けると、決定木の保守負担も自由入力のリスクも避けられる。" }, { "heading": "会話の外側に監督エージェントを置く多層防御", "body_html": "Sierraは顧客対応エージェントの安全性を、1つのプロンプトの精度ではなく4層のチェックの積み重ねとして設計している。まずナレッジベースの内容に応答を根拠づける層、次に「競合製品と比較しない」のような自然言語のルール層、そのうえで会話をリアルタイムに監視し逸脱があれば書き換えやブロックを行う「監督エージェント」層、最後にモデルの判断を介さない決定的なガード層が続く。決定的ガードの具体例は、本人確認が済むまで口座変更ツール自体をエージェントに渡さないというもので、確認ダイアログではなくツールの可視性そのものを制御する。
1件のメッセージに対して、この中の複数のチェックが同時に走る設計になっているのは、生成モデル単体の指示追従性を信頼しないという前提があるからだ。プロンプトでルールを守らせる層と、モデルの判断を経由しない層を分けておけば、片方が突破されてももう片方が残る。会話型の顧客対応エージェントで『監督役のエージェントが主エージェントを常時監査する』構成を採る例は、開発ツール向けのサンドボックス設計とは異なる形で同じ『事前に構造で縛る』発想の応用と言える。
", "examples": [ { "product": "Sierra（Defense in Depth）", "approach": "コンテンツ・ポリシー・監督エージェント・決定的ガードの4層で1メッセージを検証", "detail": "口座変更などのツールは本人確認前にはエージェントへ渡されないよう、モデルの判断を介さず制御される", "source_url": "https://sierra.ai/blog/defense-in-depth-in-the-age-of-agents" } ], "takeaway": "確認プロンプトや指示文だけに頼る防御は1点突破に弱い。会話内容を監査する層と、モデルの判断を経由しないツール可視性の制御を両方持たせると、どちらかが破られても被害を限定できる。" }, { "heading": "1つのモデルではなく、タスクごとにモデルを使い分ける", "body_html": "Sierraは顧客対応エージェントを単一のLLMで動かさず、15以上のモデルを役割ごとに割り当てる「constellation」構成を採る。推論に強いモデルは応答が遅くなりがちで、応答が速いモデルは複雑な方針の理解に弱いというトレードオフがあるため、注文管理のような低遅延のツール呼び出し、不審な挙動を見分ける高精度の分類、長い規約文書を読む長文脈の推論、ブランドに合った文面調整をそれぞれ別モデルに担わせ、オーケストレーションと経路選択は会話設計者の目に触れないところで自動化されている。
同じ発想はAdaのPlaybooksにも見られ、公式ブログは課題を「推論の深さか応答速度かの二択ではなく、どのステップにどのモデルを、どの範囲で使うかだ」と説明している。1回のリクエスト単位でモデルを選ぶ従来型のルーティングと異なり、これは1つの会話ターンの中でサブタスクごとにモデルを切り替える粒度の設計で、顧客対応エージェントが分類・検索・生成・トーン調整のように性質の異なる仕事を1ターンでこなすようになったことの帰結だ。
", "examples": [ { "product": "Sierra（Constellation of Models）", "approach": "ツール呼び出し・分類・長文推論・トーン調整を別モデルに分担", "detail": "推論が得意なモデルは低遅延なツール呼び出しに弱く、その逆も真であることが使い分けの理由と公式ブログが説明", "source_url": "https://sierra.ai/blog/constellation-of-models" }, { "product": "Ada（Playbooks）", "approach": "ステップごとに適したモデルと範囲を割り当てる設計を公式に明言", "detail": "「推論の深さか実行速度かではなく、どのステップにどのモデルをどの範囲で使うか」が課題だとブログで述べている", "source_url": "https://www.ada.cx/blog/agentic-ai-customer-experience-playbooks/" } ], "takeaway": "会話の中の仕事を分類・検索・生成・トーン調整のように切り分けられるなら、1モデルに全部を担わせる前提を疑う価値がある。粒度はリクエスト単位ではなくサブタスク単位まで下げられる。" } ] }, "editorial": "3社の発表に共通するのは、『AIに任せる範囲を広げる』話ではなく『どこを構造で固定し、どこを自然言語の柔軟性に残すか』という線引きの話だという点だ。決定木の全廃でも自由な会話への全面移行でもなく、書く人と検証する仕組みを分けるという地味な設計判断が、結果的に安全性とイテレーション速度の両方を支えている。", "quick_picks": [ { "title": "Decagon「AOPが描くCXの未来」", "summary": "AOPが自然言語とコードの精度をどう両立させるかを公式にまとめた記事。本号のDecagon事例の背景を補足する。", "url": "https://decagon.ai/blog/aop-the-future-of-cx" }, { "title": "Sierra「コンテキストエンジニアリングが優れたエージェントの鍵」", "summary": "エージェントが各瞬間にどの情報へアクセスできるかの設計が性能を左右するという、Sierraのアーキテクチャ思想の別の柱を解説する記事。本号の多層防御・モデル分担と同じ設計哲学の延長にある。", "url": "https://sierra.ai/blog/context-engineering-the-key-to-great-agents" }, { "title": "Ada Playbooksのドキュメント", "summary": "Playbooksがガイドライン・トーン・エッジケース処理をどう構造化するかを示す公式ドキュメント。本号で触れたステップ単位のモデル割り当てを支える設計の詳細。", "url": "https://docs.ada.cx/docs/automation/playbooks" } ] }