第6章 Level 4：ガードレール付き自律型 ── ポリシーが監視する、人間は境界を設定する

---

Level 3 との断絶

Level 3では、人間はタスクの「開始と終了」に関与した。計画を承認し、結果をレビューする。

Level 4では、人間は「境界の設定」にのみ関与する。「こういう範囲で・こういうポリシーに従って・こういう場合はエスカレーションせよ」を定義する。その後は、タスク単位での人間承認なしにAIが継続的に稼働する。

Level 3：
  タスクA → 承認 → 実行 → 確認
  タスクB → 承認 → 実行 → 確認    （タスクごとに人間が関与）

Level 4：
  ポリシー設定 → エージェントが継続稼働
                    ├─ タスクA（自律処理）
                    ├─ タスクB（自律処理）
                    ├─ タスクC（自律処理）
                    └─ タスクD（ポリシー範囲外 → エスカレーション）

この変化は「信頼の単位」を変える。Level 3では「このタスクをこのエージェントに任せてよいか」を毎回判断する。Level 4では「このポリシーはこのエージェントを適切に制御できるか」という一段抽象度の高い信頼を持てるかどうかが鍵だ。

---

代表的なプロダクト

Sierra（Sierra AI）

コンセプト：企業向けのカスタマーサービスエージェントプラットフォーム。ブランド・ポリシー・ナレッジベースを与えることで、そのブランドになりきって顧客の問い合わせを24時間365日自律処理する。

AIの動き：

• 顧客が問い合わせを入力すると、Sierraのエージェントがトリアージ・情報検索・回答を自律実行
• 注文変更・返金申請・アカウント設定変更などのアクションをシステムAPIを通じて実行
• ポリシー違反・感情的な escalation・高難易度ケースを検出して人間エージェントに引き継ぐ

事例数字：

• 1日に何百万件もの会話を処理
• Sierraを使った一企業では、AIが会話の84%を解決、人間エスカレーションは2%

設計の工夫（Sierra独自のアーキテクチャ）：

Sierraが「Enterprise-grade agent」を実現するために採用しているのが「コンステレーションアーキテクチャ」だ。単一の大きなLLMを使うのではなく、複数の専門モデルが協調して動く。

graph TD
    subgraph Sierra["Sierra コンステレーションアーキテクチャ"]
        IN["インプット<br/>フィルタリング層<br/>（プロンプトインジェクション検知）"]
        TA["タスク実行<br/>エージェント<br/>（主エージェント）"]
        SU["スーパーバイザー<br/>エージェント<br/>（品質監視）"]
        KN["ナレッジ<br/>検索エージェント<br/>（RAG）"]
        AC["アクション<br/>実行層<br/>（API呼び出し）"]
        OU["アウトプット<br/>フィルタリング層<br/>（有害コンテンツ検知）"]
    end

    IN --> TA
    TA <--> SU
    TA <--> KN
    TA --> AC
    AC --> OU

    SU -.->|"ポリシー違反検知"| ESC["人間エージェントへ<br/>エスカレーション"]

四層のガードレール：

1. システム層：入力のフィルタリング（プロンプトインジェクション・ジェイルブレイク検知）
2. スーパーバイザー層：主エージェントの出力を別モデルが監視・修正
3. Adversarial Testing：レッドチームによる事前の攻撃テスト
4. 自動化された行動QM：本番会話の継続的サンプリングと品質検証

---

Intercom Fin（Intercom）

コンセプト：カスタマーサポート特化のAIエージェント。既存のヘルプセンター・FAQ・ドキュメントを知識源として、顧客の問い合わせを自律処理する。

AIの動き：

• 顧客の問い合わせを受け取り、ナレッジベースから関連情報を検索・統合
• 自信度スコアを計算し、閾値を超えた場合のみ自律で回答
• 解決できない場合・感情的なケースを人間エージェントに引き継ぐ

設計の工夫：

信頼度スコアによる二段階ルーティング：

高信頼度 → Finが自律回答
低信頼度 → 人間エージェントに転送
           （全会話履歴・抽出エンティティ・試みた解決策・推奨アクション付きで）

ハンドオフ時に顧客が「また最初から説明しなければならない」摩擦を排除する設計だ。人間エージェントが引き継ぐときは、AIが何を試みたかが完全に把握できる状態で始まる。

Proceduresによる決定木の自然言語化： 従来のif-this-then-thatのルール定義（コーディングが必要）を、自然言語で「もしユーザーが〇〇を言ったら、まず△△を確認し、それでも解決しなければ人間に転送せよ」と書けるようにした。技術者以外がポリシーを定義できる。

---

Zendesk AI Agent（Zendesk）

コンセプト：チケットベースのカスタマーサポート業務に統合されたAIエージェント。チケットの分類・優先度付け・自動回答・エスカレーションを一元管理する。

AIの動き：

• チケット受信時に内容を分析し、カテゴリ・感情・緊急度を自動判断
• ナレッジベースと照合し、自信度スコアが閾値以上であれば自律回答
• 自動回答後に「この回答は役立ちましたか？」のFBを収集し、モデルを継続改善

設計の工夫：

信頼度閾値の管理：デフォルト閾値は60（0-100スケール）。閾値を上げると精度が上がるが、Finが対応できるケースが減る。各組織がビジネスリスクに応じて閾値を調整できる。

閾値調整の考え方

高閾値（80+): 精度優先
  → AIが答える比率が下がる
  → 人間コスト増だが、誤回答リスク低

低閾値(40-): カバレッジ優先
  → AIが答える比率が上がる
  → コスト効率高だが、誤回答リスク増

適切な閾値は業種・チケット種類によって異なる

---

Glean Agents（Glean）

コンセプト：エンタープライズ全体のデータ（Slack・メール・Confluence・Salesforce・GitHub等100+システム）を組織コンテキストとして持ち、部門横断の業務プロセスをエージェントが自律実行する。

AIの動き：

• 営業レポートの自動生成（CRM・会議メモ・メールを統合）
• 新入社員のオンボーディング質問対応（社内ドキュメントをナレッジソースとして）
• 定例業務（週次サマリー・ステータスレポート）の自動化

設計の工夫：

• ガバナンスフレームワーク：どのデータにどのエージェントがアクセスできるかを既存のACLに基づいて制御（人事データは人事担当のみ参照できるエージェントのみが見られる）
• 自己評価ループ：エージェントが出力を生成する前に、「この出力がガバナンスポリシーに準拠しているか」を自分で評価する
• エンタープライズコンテキスト：組織図・役割・チーム関係を理解した上での推論（「このメールを誰に転送すべきか」の判断など）

---

Level 4 の設計原則

原則1：ポリシーを階層化する

すべての指示に同じ強度のガードレールをかけることはできない。Sierraが採用した「許容レベル別の分類」が実践的な回答だ。

ガードレール階層の例

🔴 絶対遵守（完全制約）
   - 個人情報の外部送信禁止
   - 反社的な回答の禁止
   - 法的に問題のある情報の提供禁止

🟡 強い制約（判断を要する）
   - ブランドガイドラインの遵守
   - 競合他社への言及方法
   - 返金ポリシーの適用範囲

🟢 柔軟な実行（精神を守る）
   - トーン・言葉遣いの調整
   - 回答の詳細度
   - 文化的なニュアンス

原則2：エスカレーション設計を最初に行う

Level 4でよく起きる失敗は、「エスカレーション設計」を後回しにすることだ。AIが対応できないケースが発生したとき、どうするかを事前に決めておかないと、AIが誤った回答を出し続けたり、顧客が解決策なしに迷子になったりする。

flowchart TD
    A["顧客の問い合わせ受信"]
    B{"意図の理解<br/>可能か？"}
    C{"ナレッジベースに<br/>回答があるか？"}
    D{"信頼度スコア<br/>閾値を超えるか？"}
    E["自律回答"]
    F{"顧客が解決<br/>したか？"}
    G["会話終了"]
    H["人間エージェントへ転送<br/>（全履歴・コンテキスト付き）"]

    A --> B
    B -- No --> H
    B -- Yes --> C
    C -- No --> H
    C -- Yes --> D
    D -- No --> H
    D -- Yes --> E
    E --> F
    F -- Yes --> G
    F -- No --> H

    style H fill:#f8d7da,stroke:#721c24

エスカレーション時に何を渡すかの設計も重要だ。「会話全文」「抽出されたエンティティ」「試みた解決策」「推奨される次のアクション」——これらがセットで渡されて初めて、人間エージェントが「最初から説明し直し」を顧客に求めずに済む。

原則3：継続的な品質監視と改善ループ

Level 4のエージェントは「デプロイして終わり」ではない。本番稼働中の会話を継続的にサンプリングし、品質を評価し、問題を発見し、改善するループが不可欠だ。

Sierraは「Post-conversation Analysis」として、高速な検出モデルと精密な推論モデルを組み合わせて、本番会話の品質を継続的に評価している。

継続的改善ループ

本番会話 → サンプリング → 品質評価
                              ↓
                 ポリシー・ナレッジベース更新
                              ↓
                    次の本番会話の品質向上

原則4：「1万件に1件のハルシネーション」を前提として設計する

Sierraのブログが指摘するように、「1万件に1件のハルシネーション率」はL4では許容できない。1日100万件の会話を処理する場合、毎日100件の誤回答が出ることを意味するからだ。

Level 4の設計は「エラーをゼロにする」ではなく「エラー率を許容範囲内に維持し続ける」という工学的アプローチをとる。確率の問題をエンジニアリングの問題に変換する。

---

Level 4 の価値と限界

価値：

• スケーラビリティ：人間エージェントを増やさずに対応量を増やせる
• 24/365稼働：深夜・休日の問い合わせも即時対応
• 一貫性：人間のコンディション変動（疲れ・感情）に影響されない回答品質

限界：

• ドメイン範囲の制約：ポリシーで定義された範囲外の問題は対応できない
• 新しいタイプの問題への対応遅れ：学習データにない状況への適応が遅い
• 高い初期設定コスト：ポリシー定義・ナレッジベース整備・ガードレール設計に相当な工数がかかる

次章では、これらのレベルを横断するデザインパターンと実装の工夫を整理する。

＋ － ⟳ ✕