お客様対応の AI エージェントにフォールバックモデルが必要な理由

お客様対応の AI エージェントにはフォールバックモデルが必要です。どのモデルも、いずれは最悪のタイミングで失敗するからです。プロバイダーの障害、アカウントのレート制限への到達、リクエストのタイムアウト、あるいは 1 つの通常と異なる会話が想定を超えるトークンを消費するといったことが起こります。フォールバックがなければ、エージェントは沈黙し、お客様は待たされます。あれば、2 つ目のモデルが引き継ぎ、会話は続きます。MonoChat の Agent Harness では、すべての AI エージェントノードに、メインモデル、フォールバックモデル、高速モデルと、実行ごとの予算上限があります。

この記事では、モデルの障害がお客様とのメッセージングで特に重大な理由、フォールバックの仕組み、フォールバックモデルの選び方、そして高速モデル、予算、有人対応への引き継ぎとの組み合わせ方を説明します。

モデルの障害がお客様との会話でより深刻な理由

社内ツールであれば、AI リクエストの失敗は些細な不便です。再試行をクリックすれば済みます。しかし WhatsApp でのお客様との会話では、約束を破ることになります。お客様は質問を送り、既読の青いチェックマークを確認して、回答を待っています。

お客様とのメッセージングが特に影響を受けやすい理由はいくつかあります。

• お客様は再試行しません。 より苛立った状態で再度書き込むか、離脱します。
• トラフィックは急増します。 キャンペーン、配送遅延、セールによって、数分で会話数が何倍にもなることがあり、そのときにまさにレート制限が影響します。
• エージェントは何度も呼び出します。 エージェントハーネスはモデルをループで実行し、お客様のメッセージ 1 件につき何度も呼び出すことがよくあります。1 回の呼び出しの失敗が、実行全体を止めてしまうことがあります。
• WhatsApp ではタイミングが重要です。 自由形式の返信は、お客様の最後のメッセージから 24 時間以内にのみ許可されます。長く止まると、返信がこのウィンドウの外に出てしまい、承認済みのテンプレートが必要になります。

これは、特定のプロバイダーが信頼できないという話ではありません。どのプロバイダーにも、インシデント、メンテナンス、容量の制限があります。問題は、お客様のエージェントにそれらへの備えがあるかどうかだけです。

起こりうる問題

プロバイダーの障害。 部分的でも全面的でも、短時間でも長時間でも起こります。月間稼働率が 99.9% であっても、40 分以上のダウンタイムは許容されます。

レート制限。 アカウントでは、1 分あたりのリクエスト数やトークン数に上限がある場合があります。プロバイダー自体に問題がなくても、混雑した時間帯にはその上限に達することがあります。

タイムアウトと応答の遅延。 通常は 2 秒で答えるモデルが、負荷がかかると 20 秒かかることがあります。スマートフォンのお客様には、何も起きていないように感じられます。

暴走した実行。 分かりにくいリクエストでループするエージェントや、延々と長くなる会話は、通常の実行をはるかに上回る量を消費することがあります。

モデルの変更。 プロバイダーはモデルを更新したり廃止したりします。頼りにしていた動作が、ほとんど予告なく変わることがあります。

エージェントでのフォールバックの仕組み

考え方はシンプルで、メインモデルが処理を完了できないとき、2 つ目のモデルが引き継ぎます。MonoChat では、ソフトリミットの後、またはメインモデルが失敗したときに、フォールバックモデルが引き継ぎます。会話、ツール、指示は変わらず、処理を行うモデルだけが変わります。

各 AI エージェントノードでは、3 つの役割が連携します。

役割	内容
メインモデル	推論、判断、返信の作成を行う
フォールバックモデル	ソフトリミットや障害の後に引き継ぐ
高速モデル	バックグラウンド処理を担当する

これらの役割に加えて、実行ごとの予算上限により、1 つの会話で使える費用に上限を設けられます。

フォールバックモデルの選び方

別のプロバイダーを選ぶ

同じプロバイダーのフォールバックは、1 つのモデルの不具合には備えられますが、プロバイダー全体のインシデントや、そのプロバイダーでのアカウントのレート制限には備えられません。別のプロバイダーのモデルであれば、どちらにも対応できます。MonoChat では カスタム LLM を通じて複数のプロバイダーを接続できるため、大がかりなプロジェクトではなく、設定の選択で済みます。

同一ではなく、十分なものを選ぶ

フォールバックは、利用可能な最高のモデルである必要はありません。指示に従い、ツールを正しく呼び出し、まずまずの返信を書けることが条件です。頼りにする前に、メインモデルであるかのように、実際の会話を使って単独でテストしてください。

ツールを扱えるか確認する

エージェントはツール呼び出しに依存しています。注文の照会、空き枠の確認、チケットの作成などです。構造化されたツール呼び出しが他より格段に得意なモデルもあります。文章は美しくてもツールを誤って呼び出すフォールバックは、ないよりも悪い結果になります。

対応する言語に注意する

お客様がトルコ語、アラビア語、スペイン語などで書き込む場合は、フォールバックがメインモデルと同じ水準でそれらの言語を書けることを確認してください。品質や口調が急に変わると、気づかれます。

両方向のコストを考慮する

より安価なフォールバックは、ソフトリミットを超えて続く、長い実行や通常と異なる実行のコストを下げます。まれな障害のときだけ動くのであれば、より高価なフォールバックでも問題ない場合があります。フォールバックにどの役割を担わせたいかを決めてください。

高速モデル：信頼性のもう半分

すべてのステップに最高のモデルが必要なわけではありません。バックグラウンド処理、つまり返信そのものではなく会話の周辺にある作業は、より小さく高速なモデルで実行できます。そうすれば、お客様の目に触れる部分のために、メインモデルの処理能力と予算を温存でき、混雑時にメインモデルでレート制限に達する可能性も下がります。

実際には、最も推論力の高いモデルをメインに、別のプロバイダーの信頼できるモデルをフォールバックに、高速で安価なモデルをバックグラウンド処理に設定します。

予算：安全網の下にある安全網

フォールバックはエージェントを稼働させ続け、予算はそれを手頃に保ちます。実行ごとの予算上限があれば、どんなに奇妙な会話でも、計画以上の費用を使うことはありません。ソフトリミットの後にフォールバックが引き継ぐ仕組みと組み合わせると、予測しやすいパターンになります。通常の会話はメインモデルで実行され、長い会話はフォールバックで継続し、暴走するものはありません。

ご自身のプロバイダーキーを使う場合、MonoChat は AI の料金を上乗せしないため、予算として設定した額がそのままプロバイダーの請求額になります。

フォールバックは引き継ぎではありません

フォールバックモデルをあらゆる問題の答えと考えたくなりますが、そうではありません。フォールバックが解決するのは技術的な障害、つまりモデルのダウン、遅延、予算切れです。引き継ぎが解決するのは判断の問題、つまりクレーム、法的な質問、上限を超える返金、あるいは単に担当者を希望するお客様への対応です。

MonoChat では、エージェントはフロー内で動作するため、全履歴とともに共有チーム受信トレイへ引き継ぐ手段を常に利用できます。また WhatsApp では、自動返信に担当者への明確な経路を用意することが求められます。両方の経路を設計してください。

1. メインモデルが失敗するかソフトリミットに達した場合 → フォールバックモデルが継続します。
2. 案件に担当者が必要な場合 → 会話履歴とともに適切なチームに引き継ぎます。
3. 両方が失敗した場合 → フローがお客様に担当者から返信することを伝え、会話を受信トレイに振り分けます。

簡単なチェックリスト

• 実際の会話での品質を基準にメインモデルを選んでいる。
• 別のプロバイダーのフォールバックモデルを、ツールと言語を使って単独でテストしている。
• バックグラウンド処理に高速モデルを使っている。
• 実行ごとの予算上限が、通常の会話コストに多少の余裕を加えた水準になっている。
• エージェントの指示とフローに、明確な引き継ぎルールがある。
• 最初の 1 週間の後に、フォールバックで実行された会話を含め、会話のサンプルを確認している。

一度設定すれば、すべてのチャネルに適用

AI エージェントノードは MonoChat のフロー内にあるため、同じメイン、フォールバック、高速の各モデルが、WhatsApp、Instagram、Messenger、TikTok、Telegram、Webチャット、SMS、音声のどこでもエージェントを守ります。また Agent Harness ではフレームワークを選べるため、エージェントが MonoChat の内蔵ハーネス、Claude Agent SDK、OpenAI Agents SDK、Pi、独自のフレームワークのいずれで動いていても、同じ方法が使えます。

モデルの役割の組み合わせ方は、Agent Harness のページをご覧ください。