Works
Blog Recruit Contact AI互換性診断
AIエージェント
calendar_today
[AIエージェント構築、その前に Vol.3] 山下 太郎 山下 太郎

AIエージェント構築、その前に 第3回:フォールバック設計の天秤 — Fable 5に学ぶ能力の段階制御

許可か拒否かの二択は「全部許可」に崩れる。Fable 5が実装した第三の道=降格に学び、通常運転・昇格・降格・エスカレーションの状態遷移でエージェントを設計する方法を解説する連載第3回。

AIエージェント構築、その前に 第3回:フォールバック設計の天秤 — Fable 5に学ぶ能力の段階制御
【追記:2026年6月12日】 本連載の執筆後、2026年6月12日に、米政府の輸出管理指令により、AnthropicはClaude Fable 5およびMythos 5へのアクセスを一時停止しました(同社はこの措置に異議を表明し、復旧を目指すとしています)。本回はFable 5のフォールバック実装を教材にしていますが、そこから学ぶ能力の段階制御という設計の考え方そのものは、特定のモデルの提供状況に左右されず有効です。本文中のFable 5に関する記述は、執筆時点のモデル仕様としてお読みください。状況は流動的であり、最新の状況は一次情報をご確認ください。

前回、権限設計の話をした。エージェントに「させないこと」を決め、低リスクの象限から段階的に開けていく。あれは言わば、壁の建て方の話だった。

だが壁には限界がある。壁は静的だからだ。許可か、拒否か。白か、黒か。実際の業務はその中間で動いている。「この操作は、この条件なら任せたい。この条件なら任せたくない」──現場の感覚はいつもグラデーションなのに、設計が二値しか持っていないと、結局「不便だから全部許可」へ雪崩れていく。セキュリティ設計の失敗は、たいていこの「不便さへの耐えきれなさ」から始まる。

この問題に対して、2026年6月に登場したClaude Fable 5は、ひとつの参考解を実装して見せた。今回はそれを教材に、「拒否」と「全権」のあいだを設計する方法──フォールバック設計を考える。

Fable 5は「断らない」、降りる

おさらいすると、Fable 5はAnthropicの最上位Mythosクラスに属するモデルで、限られたパートナーにのみ提供されてきた水準の能力を、初めて一般に開放したものだ。その開放を可能にしたのが、フォールバックという仕組みだった。

サイバー攻撃、生物・化学分野の危険な利用、モデルの蒸留──こうした高リスク領域に踏み込むリクエストを安全分類器が検知すると、Fable 5は自分では答えない。Claudeアプリ等のクライアントでは、処理はそのまま一段下のClaude Opus 4.8に引き継がれる。利用者から見れば、会話は途切れない(発生はセッション平均で5%未満とされ、切り替えは通知される仕様だ)。ただ、その瞬間だけ「能力の上限」が下がる。

開発者向けに補足すると、API利用ではこの拒否はエラーですらない。HTTP 200の正常レスポンスとして返り、stop_reasonフィールドが"refusal"となり、stop_detailsに該当カテゴリ(cyber、bioなど)が示される。Opus 4.8への自動切り替えはfallbacksパラメータによる任意設定(ベータ)で、対応するのはClaude APIとAWS上のClaude Platformのみ。Amazon Bedrock・Vertex AI・Microsoft Foundryでは自前で再試行を実装する必要がある。出力前に拒否されたリクエストは課金されない。つまりこれは単なる「遮断」ではなく、拒否をエラーではない正常系として定義し、引き継ぎ先と費用の扱いまで事前に設計してある、ということだ。この徹底ぶり自体が、フォールバック設計の教材になっている。

一方で、運用は発展途上だ。分類器は保守的に調整されており、公開直後には、防御目的のペネトレーションテストやコードレビュー、生物情報学のパイプラインといった正当な作業まで誤って切り替わる報告が相次いだ。Anthropicも誤検知の削減を公開後の課題と認めている。段を作る設計は正しくても、段の境界線の調整は終わらない──これは最終回で扱う「運用」の伏線でもある。

ここで注目したいのは、選ばれた選択肢が「拒否」ではないことだ。リスクを検知したら全部断る、という設計も当然ありえた。だがそれでは、防御目的の正当なセキュリティ研究まで巻き添えで止まり、製品として使いものにならない。かといって全権を渡せば、一般公開はできない。Anthropicが選んだのは第三の道──状況に応じて、能力の段数を下げるだった。エレベーターで言えば、怪しい階のボタンを無効にするのではなく、その乗客のときだけ最上階に止まらないエレベーターにする、という発想だ。

さらに引いて見ると、Anthropicはこの段階制御を製品の外側でもやっている。保護を外したMythos 5の提供は、現時点ではサイバー防衛の取り組み(Project Glasswing)の既存パートナーに限られ、政府と連携した信頼アクセスプログラム等への拡大は今後の予定とされる。生命科学の研究者向けには、生物・化学の保護だけを外し、サイバー保護は維持した別枠が予定されている。つまり「誰に・どの保護を・どこまで」を相手との信頼関係に応じて変える、多段の蛇口になっている。モデルの内側ではリクエスト単位の段階制御、外側では組織単位の段階制御。一貫して、白黒ではなくグラデーションで設計されている。

なお誤解のないよう補足すると、Fable 5とMythos 5は同一の基盤モデルで、違いはモデルの外側に付けられた安全分類器の層の有無だけだ。一方、フォールバック先のOpus 4.8は別のモデルである。「能力の本体」と「制御の層」を分離して設計する──この分離こそが、自社エージェントに翻訳するときの重要な学びになる。

自社エージェントに翻訳する — 三つの状態と二つの遷移

この設計思想は、そのまま自社のエージェント設計に翻訳できる。エージェントを単一の状態で動かすのではなく、複数の「運転モード」とその間の遷移として設計するのだ。

stateDiagram-v2 [*] --> 通常運転 通常運転: 通常運転(標準モード) 通常運転: 日常タスクを標準権限・標準モデルで処理 昇格: 昇格(高能力モード) 昇格: 条件を満たすタスクのみ上位モデル・追加権限で処理 降格: 降格(制限モード) 降格: 権限を絞り、読み取り専用などに縮退して継続 人間へ: エスカレーション 人間へ: 人間の承認・判断を待って再開 通常運転 --> 昇格: 高難度タスクを検知 昇格 --> 通常運転: タスク完了 通常運転 --> 降格: リスク兆候を検知 昇格 --> 降格: リスク兆候を検知 降格 --> 人間へ: 不可逆操作が必要 降格 --> 通常運転: 安全確認後に復帰

図が示しているのは、エージェントの四つの状態と遷移だ。平常時は標準のモデルと権限で動く「通常運転」。難しいタスクを検知したときだけ上位モデルと追加権限に上がる「昇格」──これは第1回で見たモデルルーティングと同じ仕組みで、コスト最適化と能力制御が実は同じ一枚のコインだとわかる。そしてリスクの兆候を検知したら、停止ではなく権限を絞って続行する「降格」。降格状態で不可逆な操作が必要になったら、止まって人間を呼ぶ「エスカレーション」。

要点は、落ち方を先に設計しておくことだ。ソフトウェア工学で言うgraceful degradation──全体停止ではなく、機能を縮退させながら動き続ける考え方を、エージェントの能力と権限に適用する。

切替条件を言葉にする

では、何を検知したら段を下げるのか。汎用的に使える条件を整理する。

検知する状況具体例遷移先
外部コンテンツの混入Webページ・受信メール・添付ファイルを読み込んだ直後降格(以降の書き込み操作を制限)
機密度の高いデータへの接触人事・財務・顧客個人情報を含む処理降格(出力先を社内に限定)
不可逆操作の要求送信・公開・削除・決済の実行段階エスカレーション(人間の承認)
指示の自己矛盾・異常な要求設定済みの禁止事項に触れる指示、急かす文面降格+ログ記録(インジェクションの疑い)
高難度タスクの検知複雑な推論・設計判断が必要な処理昇格(上位モデルへ、権限は据え置き)

一行目が特に重要だ。前回、「社外×読み取り」がプロンプトインジェクションの入口だと書いた。その対策がここで形になる。外部のコンテンツを読んだ直後のエージェントは、信頼度が一段下がった状態として扱う。 読む前と読んだ後で、同じエージェントに同じ権限を与えない。Fable 5が「危険な領域に触れた瞬間に能力を落とす」のと、構造は同じだ。

もうひとつ、五行目に注目してほしい。昇格の条件で「権限は据え置き」とした。モデルの賢さと、操作の権限は、別々のダイヤルとして設計する。賢いモデルに切り替えたからといって権限まで広げる必然性はないし、むしろ高能力×高権限の同時付与こそ、最も慎重に扱うべき組み合わせになる。

信頼は、段階的に積む

Anthropicが組織単位でやっている信頼アクセスの考え方も、社内展開に翻訳できる。全部署に同じエージェントを一斉配布するのではなく、運用の習熟した部署から順に、開放する状態の範囲を広げていく。最初は通常運転のみ。運用ログが安定したら昇格モードを解禁。エスカレーションの判断が現場に根づいたら、降格からの自動復帰を許す──。

つまりフォールバック設計とは、機械の中の話であると同時に、組織がエージェントとの信頼関係を積む手順の話でもある。一度に全部を信じない。一度の失敗で全部を止めない。段階を作り、行き来できるようにしておく。人間の新入社員にしてきたことと、本質は変わらない。

まとめ — 壁から、ダイヤルへ

  • 「許可か拒否か」の二値設計は、不便さに負けて「全部許可」に崩れる。あいだに段を作る
  • Fable 5のフォールバックは「拒否ではなく降格」「能力と公開範囲の分離」「相手に応じた多段の蛇口」という設計思想の実例
  • 自社エージェントは通常運転・昇格・降格・エスカレーションの状態遷移で設計し、落ち方を先に決めておく
  • 外部コンテンツを読んだ直後は信頼度を一段下げる。モデルの賢さと権限は別ダイヤルで制御する

ここまでで、選定(第1回)・権限(第2回)・段階制御(第3回)と、エージェントの設計図は一通り描けた。だが、冷静な読者ほど気づいているはずだ。状態遷移、切替条件、段階的な開放──これらは全部、動かし続けて、観察し続けて、調整し続けることを前提にしている。

設計図は完成しても、仕事は終わらない。むしろ始まる。最終回は、この「作った後」の話──ログ、コスト監視、モデル更新への追従という、内製判断の最大の盲点を扱う。

参考情報
山下 太郎

山下 太郎

代表取締役 / CEO

2000年、Webデザイナーとしてこの世界に飛び込み、フリーランスを経て2007年に株式会社アンタイプを創業。AI時代の到来とともに、効率だけを追うAI活用に違和感を覚えながら、それでも最前線でツールを使い続ける。企業のWebとコミュニケーションを設計する仕事を通じて、「人間らしさとは何か」を問い直す視点を発信し続けている。

View Profile arrow_outward

Related

あわせて読みたい