Well-Architected Framework:安定性の柱

根拠

単一のモデルサービスは、利用不能になったり性能が劣化したりする可能性があります。プライマリモデル、バックアップモデル、キャッシュからなる3層のフォールバック戦略を構成することで、プライマリサービスで障害や性能劣化が発生した場合でも、業務継続性を確保できます。

実装

3 層のフォールバックチェーンを設計します：プライマリモデル → バックアップモデル → キャッシュ/ルールベースシステム。通常時はプライマリモデルがトラフィックの 100% を処理します。プライマリモデルでタイムアウト、しきい値を超えるエラー率、品質スコアの低下などの問題が発生した場合、トラフィックは自動的にバックアップモデルに切り替わります。バックアップモデルは通常、低コストのモデルであり、大規模パラメータモデルから中規模パラメータモデルにダウングレードするなど、基本的な業務機能を維持できます。バックアップモデルも利用不能になった場合は、よくある質問に対する事前計算済みの回答を返すキャッシュや、テンプレートから定型応答を生成するルールベースシステムにデグレードします。

モデルの切り替え管理には、サーキットブレーカーパターンを使用します。サーキットブレーカーは、Closed (プライマリモデルを使用) 、Open (バックアップモデルに切り替え) 、Half-Open (プライマリモデルの回復をプローブ) の 3 つの状態を維持します。N 回連続のリクエスト失敗、スライディングウィンドウ内でのエラー率がしきい値を超過、平均レイテンシが SLO 上限を超過などの条件を満たすと、サーキットブレーカーは Open 状態に遷移します。一定時間経過後、サーキットブレーカーは Half-Open 状態に入り、少数のリクエストを通してプライマリモデルが回復したかどうかを検証します。

プライマリモデルとバックアップモデルの出力形式の互換性を確保します。プライマリモデルが GPT-4 クラスで、バックアップが GPT-3.5 クラスである場合でも、出力スキーマは一貫している必要があります。切り替え時に出力の解析のために業務ロジックを調整する必要がないようにしてください。

アンチパターン：フォールバック構成なしで単一のモデルサービスに依存し、サービス障害時に全面的な業務停止に至ること。あるいは、互換性テストなしにフォールバックを構成し、切り替え時にスキーマ不一致で下流のパースエラーを引き起こすことです。

Alibaba Cloud での実践：AI Gateway では、複数のモデルエンドポイントを設定し、カスタムルーティングロジックでプライマリ/バックアップの切り替えを実装できます。PAI-EAS は複数のモデルサービスインスタンスをデプロイでき、Application Load Balancer (ALB) のヘルスチェック機構により、不健全なバックエンドインスタンスを自動的に除外できます。

根拠

API クォータとレート制限は、クラウド AI サービスに固有の制約です。トラフィックパターンの管理が不十分だと、クォータ枯渇により重要なリクエストが拒否される一方で、重要でないリクエストが貴重なクォータを消費してしまいます。上流のレート制限に対して適切にデグレードできるよう、クライアント側のクォータ管理とトラフィック監視の仕組みを構築してください。

実装

トークンバケットアルゴリズムを用いて、クライアント側でレート制限を実装します。既知の API クォータ (例：1 分あたり 100K tokens) に基づいて、クライアント側でトークンバケットを維持します。各リクエストは推定消費量に基づいてトークンを取得します。バケットが空の場合、リクエストは即時失敗させるのではなく待機キューに入れます。これにより、API のハードなレート制限 (拒否) を、クライアント側のソフトな制限 (キューイング) に変換でき、ユーザー体験をより滑らかにできます。

バックプレッシャーの仕組みを使用します。リクエストキューの滞留がしきい値を超えた場合、エンドユーザーや別サービスなどの上流呼び出し元に「system busy」シグナルを送信します。呼び出し元は、待機、リトライ、またはフォールバック使用のいずれかを判断できます。バックプレッシャーシグナルには推定待機時間を含め、呼び出し元が判断しやすいようにしてください。

リクエスト種別ごとに優先度を設定します。リアルタイムのカスタマーサポートチャットなどの重要な業務リクエストには、クォータへの優先的なアクセスを許可します。バッチ処理やレポート生成などの非リアルタイムリクエストは、オフピーク時間帯に実行できます。優先度付きキューにより、クォータが逼迫しているときでも重要リクエストが非重要リクエストに押し出されないようにできます。

クォータをウォームアップします。EC のプロモーションやマーケティングイベントなど、予測可能なトラフィックピークの前に、クラウドプロバイダーと調整してクォータを引き上げるか、追加の推論インスタンスを事前にデプロイします。過去のトラフィックパターンを用いて需要を予測し、ピーク到来前にリソースを準備してください。

アンチパターン：上流のクォータ制限を意識せずに、制御されないレートでリクエストを送信することです。これにより拒否が多発し、その後のリトライが混雑をさらに悪化させ、リトライストームを引き起こす可能性があります。

Alibaba Cloud での実践：AI Gateway は、大規模モデルサービスと高同時実行シナリオ向けに設計された API レート制限ポリシーをサポートします。トークン消費量、リクエスト数、同時実行数など複数の次元に基づき、動的に制御します。コンシューマー ID、リクエストヘッダー、クエリパラメータ、cookie、クライアント IP、モデル名などに基づいてレート制限ルールを設定できます。さらに、API 全体に対するグローバルなレート制限も提供します。この多次元アプローチは、大規模モデルのリソース消費特性に正確に適合し、複雑なシナリオにおいても、システム過負荷、API 悪用、悪意ある呼び出しを効果的に防止しつつ、コア業務の安定性を確保します。

根拠

単一のアベイラビリティーゾーンにデプロイすると、データセンターレベルの障害リスクに晒されます。この種の障害は稀ですが、影響範囲が大きく、復旧に時間がかかる場合があります。AI 推論サービスをマルチ AZ でデプロイすることで、1 つのアベイラビリティーゾーンが障害になっても業務継続性を確保できます。

実装

同一リージョン内の少なくとも 2 つのアベイラビリティーゾーンに推論サービスをデプロイします。各アベイラビリティーゾーンには、単純なアクティブ/スタンバイ構成ではなく、モデルロードと GPU リソースを含む推論サービスの完全かつ独立したデプロイを用意してください。通常時は両方の AZ がトラフィックを処理し、片方が障害になった場合はもう片方が全負荷を引き受けます。

ロードバランサーを用いてヘルスチェックとトラフィックルーティングを行います。ヘルスチェックは、プロセスの生存確認 (TCP/HTTP プローブ) だけでは不十分です。モデルが正しくロードされ、応答できることを確認するために、軽量な推論リクエストを定期的に送信するなど、モデルの可用性の検証も含めてください。従来の TCP ヘルスチェックでは、プロセスは動作しているが GPU ドライバーの問題などでモデルのロードに失敗している、といった状態を検知できません。

冗長性を前提にマルチ AZ 容量を計画します。各アベイラビリティーゾーンは、単独で全トラフィック負荷を支えられる必要があります (N+1 の容量モデル) 。すべての AZ が常に利用可能であると前提にしないでください。そうしないと、1 つの AZ が障害になった際に残りの AZ が過負荷となり、カスケード障害につながります。

アンチパターン：すべての推論インスタンスを単一のアベイラビリティーゾーンにデプロイすること。あるいは、マルチ AZ でデプロイしていても、いずれの AZ も単独で全負荷を処理できる十分な容量を持たないことです。

Alibaba Cloud での実践：PAI-EAS は推論サービスのマルチ AZ デプロイをサポートしており、少なくとも 2 つのアベイラビリティーゾーンへのデプロイを推奨します。Model Studio は PrivateLink をサポートしており、マルチ AZ のネットワークアクセスにより AZ 間の災害復旧を確保できます。これを ALB のトラフィック分散とヘルスチェックベースのルーティングと組み合わせてください。ALB はカスタムヘルスチェックパスをサポートしており、モデルサービスの推論プローブエンドポイントを対象に設定できます。

根拠

AI の出力を、JSON 形式の API 応答や構造化された意思決定結果など、下流システムがプログラムで処理する必要がある場合、出力形式の信頼性はシステム安定性に直結します。大規模言語モデルは、構造化コンテンツを生成できる一方で、不完全であったり、フィールドが欠落していたり、データ型が誤っていたりして、下流のパースに失敗することがあります。

実装

JSON Schema を使用して期待する出力形式を定義します。必須フィールド、データ型、enum 値、ネスト構造などを含めてください。モデル呼び出し時には、関数呼び出しまたはレスポンス形式パラメータを使用して出力スキーマを指定し、モデルがスキーマに準拠した出力を生成するよう制約します。

下流に送信する前に、モデル出力に対してスキーマ検証を実行します。検証に失敗した場合は、リトライフローを開始します。検証エラーを、より明確な形式要件とともにモデルに返し、出力を再生成させます。リトライ回数の上限は通常 2～3 回に設定します。リトライしても失敗する場合は、デフォルト値を返す、またはユーザーに処理できない旨を通知するなどのフォールバックロジックを実行します。

ストリーミング出力は慎重に扱ってください。ストリーミング生成は、トークン制限やネットワーク問題により途中で中断され、不完全な JSON 出力になることがあります。ストリーミング出力を全量受信した後に完全性を検証してください。不完全な出力は失敗として扱い、リトライをトリガーします。

重要な業務シナリオでは、制約付きデコーディング手法の使用も検討してください。これにより、JSON 構文や特定の enum 値など、指定した文法へ厳密に準拠した出力を生成でき、形式エラーを根本から排除できます。

アンチパターン：形式検証を行わず、文字列連結や正規表現でモデル出力を直接パースすることです。余分なスペースやフィールド順序の違いなど、出力形式のわずかな変更でもパーサーがクラッシュする可能性があります。

Alibaba Cloud での実践：Model Studio の関数呼び出し機能では、スキーマで戻り形式を定義できます。DashScope API はresponse_format パラメータで JSON 出力を指定できます。アプリケーションコードでは、JSON Schema 検証ライブラリを用いて、検証とリトライのループを実装できます。

根拠

リスクスコアリング、コンプライアンス判定、医療支援の推奨など、出力が影響の大きい意思決定に直結するシナリオでは、単一回のモデル推論では信頼性が十分ではありません。複数回の推論を実行して結果の整合性を比較することで、モデルの不確実性が高いケースを特定し、単一の不安定な出力に基づく重要判断を回避できます。

実装

自己整合性投票を使用します。同一入力に対して N 回推論を実行し (N は通常 3～5) 、結果を比較します。多数の結果が一致している場合は多数決の結果を採用します。明確な多数派がなく結果が分散している場合は、出力を「model uncertain」としてフラグ付けし、人手による判断に回すか、ユーザーに追加情報を要求します。

クロスモデル検証を使用します。同一入力に対して 2 つの異なるモデルで推論を実行し、結果を比較します。モデルごとに学習データやバイアスの傾向が異なるため、両方で一致した結果はより信頼できます。結果が一致しない場合は、手動レビューをトリガーするか、第 3 のモデルをタイブレーカーとして使用します。

整合性スコアを作成します。整合性をスコアとして定量化します (例：5 回中 4 回一致なら 0.8) 。業務シナリオごとに異なる整合性しきい値を設定します。しきい値未満の結果は自動実行せず、不確実性の免責文を付与するか、エスカレーションしてください。

コストを制御します。複数回推論はコストを増加させます。自己整合性チェックは、重要な意思決定シナリオにのみ有効化してください。情報照会や雑談など低リスクのユースケースでは、単一回の推論で十分です。検証戦略は業務レベルのティアリングで制御してください。

アンチパターン：すべてのリクエストに無差別に複数回推論チェックを有効化し、コストが制御不能になること。あるいは、重要判断で単一回推論のみを用い、そのまま実行してしまい、許容できないリスクを生むことです。

Alibaba Cloud での実践：AI Gateway では複数のモデルエンドポイントを設定できます。Log Service (SLS) を使用して各推論の生の結果を記録し、事後の整合性分析やモデル品質評価に活用できます。

根拠

モデルはプロンプトの文言に敏感です。同じ意味であっても言い回しが異なると、出力品質が大きく変わる場合があります。推論が失敗した場合 (品質不良や形式不正など) 、プロンプトを調整してリトライすると、より良い結果が得られることがよくあります。このアプローチは、モデルのプロンプト感度を活用します。

実装

バリアントリトライのトリガー条件：すべてのリクエストに対して事前に行うのではなく、出力検証に失敗した場合 (形式エラー、不完全な内容、安全性チェックの失敗など) にのみトリガーします。初回はプライマリプロンプトを使用し、リトライ時は事前定義したバリアントに切り替えます。

バリアント戦略の設計：意味的に同等で言い回しが異なるプロンプトバリアントを 2～3 個事前定義します。バリエーションには、指示文の言い換え (「Please generate」と「Please output」) 、形式強調 (形式例の追加、XML タグで期待形式をラップ) 、思考誘導 (「Let's think step by step」の追加) 、制約の並べ替えなどが含まれます。特定モデルで有効だった実証結果に基づいてバリアントを設計してください。

コストバジェットを設定します。リクエストごとに最大リトライ回数と最大トークン消費量のバジェットを設定します。リトライ中に累積トークン消費がバジェットに近づいた場合は停止し、フォールバックロジックを実行します。これにより、無限リトライによるコスト暴走を防止できます。

リトライ間隔：バリアントリトライは、ネットワークリトライとは異なり待機時間は不要です。目的はサービス回復を待つことではなく、別の言い回しを試すことだからです。ただし、失敗原因が上流のレート制限である場合は、バックオフ戦略に従う必要があります。

アンチパターン：まったく同じプロンプトで無限にリトライすることです。同じ失敗結果を繰り返す可能性が高くなります。また、意味が大きく異なるプロンプトバリアントを使用すると、リクエストの目的自体が変質する可能性があります。

Alibaba Cloud での実践：Model Studio アプリケーションで複数のプロンプトテンプレートを設定します。アプリケーションコードで、検証、バリアント切り替え、リトライのロジックを実装します。Application Real-Time Monitoring Service (ARMS) を使用してリトライ率と最終成功率を監視します。リトライ率が高い場合は、プロンプト最適化のアラートをトリガーできます。

根拠

ナレッジベースは、検索拡張生成 (RAG) システムの正確性の基盤です。ナレッジベースのコンテンツの陳腐化は段階的な問題であり、システムが突然クラッシュするわけではありませんが、回答は徐々に不正確になります。鮮度を事前に監視していないと、多数のユーザーが誤った情報を受け取った後になって初めて問題に気付く可能性があります。

実装

各ナレッジベースに対して鮮度のサービスレベル目標 (SLO) を定義します。これは、コンテンツの最大許容経過時間です。コンテンツ種別に応じて SLO を分けてください。たとえば、価格情報の SLO は 24 時間 (毎日更新が必要) 、法務ポリシーの SLO は 48 時間 (新規制の発出から 2 営業日以内に取り込み) 、製品ドキュメントの SLO は 7 日などです。

ナレッジベースのコンテンツ更新を監視します。各ドキュメントの最終更新時刻と、ソースドキュメントの更新時刻を記録します。スケジュールタスクでナレッジベースをスキャンし、SLO を超過したドキュメントがないかをチェックします。期限超過のドキュメントは、更新のために担当オーナーにアラートを送信してください。

ソースドキュメントの変更を検知します。公式 Web サイト、社内 Wiki、ポリシー公開サイトなど、ナレッジベースのコンテンツソースを定期的にクロールするか、webhook を使用して監視します。変更を検知したら、ナレッジベース更新プロセスを自動トリガーするか、少なくとも手動レビューをトリガーしてください。

古いコンテンツをマーキングします。SLO を超過しているが未更新のドキュメントについては、検索結果に「information may be outdated」タグを付与します。これにより、モデルは生成時に不確実性の免責文を含めることができます。潜在的に古い情報を高い確信度で提示してしまうことを防ぎます。

アンチパターン：ナレッジベースを 1 回取り込んだだけで保守しないこと。あるいは、更新が必要かどうかを人の記憶に依存することです。

Alibaba Cloud での実践：DataWorks のデータ品質監視機能を使用して、ナレッジベースコンテンツの鮮度を監視できます。Model Studio のナレッジベースは API 駆動のドキュメント更新をサポートしており、CI/CD パイプラインと統合して自動更新できます。SLS でナレッジベースの変更イベントを記録し、ARMS で鮮度アラートルールを設定できます。

根拠

ベクトルデータベースは、検索拡張生成 (RAG) システムの検索エンジンです。これが利用不能になると、AI システムはナレッジベースに基づいて回答できず、モデル自身の知識に依存せざるを得なくなります。その知識は不正確または古い可能性があります。ベクトルデータベースの高可用性設計では、データ整合性とサービス継続性のバランスを取る必要があります。

実装

マルチレプリカアーキテクチャを使用します。ベクトルデータベースのデータを少なくとも 2 つのレプリカとして維持し、異なるアベイラビリティーゾーンに分散します。読み取りリクエストはレプリカ間でロードバランシングでき、読み取りスケールと AZ レベルの災害復旧を実現できます。書き込みは、整合性要件に応じて、すべてのレプリカに同期または非同期で複製します。

マルチ AZ でデプロイします。同一リージョン内の複数のアベイラビリティーゾーンにベクトルデータベースノードを分散します。1 つのアベイラビリティーゾーンが障害になっても、他のゾーンのレプリカがサービスを継続できます。ヘルスチェック付きロードバランサーを使用して自動フェイルオーバーを実装します。

データバックアップと復旧を実装します。迅速な復旧のために、ベクトルデータベースのフルスナップショットバックアップを定期的に作成します。スナップショット頻度はデータ変更率に基づいて設定してください。頻繁に更新されるナレッジベースは 1 時間ごと、安定したものは日次などです。スナップショット復旧プロセスは検証し、所要時間も測定してください。

インデックス再構築能力を維持します。ベクトルデータベースの元データソース (ベクトル化されていないテキストデータ) を保持してください。これにより、ベクトルデータベースが復旧不能な破損を起こした場合でも、元データからインデックスを完全に再構築できます。再構築プロセスは自動化し、予測可能なタイムラインを持つ必要があります。

アンチパターン：レプリカやバックアップなしで、単一のアベイラビリティーゾーンに単一インスタンスとしてベクトルデータベースをデプロイすること。あるいは、バックアップはあるが復旧プロセスを一度も検証しないことです。

Alibaba Cloud での実践：Alibaba Cloud Vector Search はマルチレプリカおよびマルチ AZ デプロイをサポートします。SLS を使用してベクトルデータベースのクエリレイテンシと可用性メトリクスを監視できます。データバックアップには Object Storage Service (OSS) を保存先として使用し、定期的なスナップショットタスクを実行できます。

根拠

検索拡張生成 (RAG) システムの検索ステップは、複数の形で失敗する可能性があります。ベクトルデータベースがタイムアウトする、ナレッジベースに関連コンテンツがなく検索結果が空になる、あるいは類似度スコアがすべてしきい値を下回り検索結果の品質が低い、といったケースです。これらの状況では、有効な検索結果がないままモデルに「即興」させるのではなく、明確なデグレード戦略を設計する必要があります。

実装

ベクトルデータベースが利用不能な場合にデグレードします。ベクトルデータベースがタイムアウトまたはエラーを返した場合、リクエスト種別に応じてデグレード戦略を選択します。単純で一般的な質問は、事前計算済みの FAQ キャッシュに切り替えて回答を直接返します。複雑な質問は、ユーザーに対して「knowledge base is temporarily unavailable, so the answer may be incomplete」と正直に伝え、モデル自身の知識に基づいて回答を生成しつつ、低確信度の免責文を含めます。

検索結果が空の場合を処理します。ナレッジベース内に関連情報が見つからない場合は、モデルに回答を捏造させるのではなく、たとえば「現在のナレッジベースでは関連情報が見つかりませんでした」と明確に伝えてください。必要に応じて、「これらのキーワードで質問を言い換えてみてください」や「この質問は人手での対応が必要かもしれません」といった提案も提示できます。

低品質な検索結果を処理します。取得した結果の類似度スコアがすべて事前定義したしきい値を下回る場合、結果は信頼できないと判断します。回答生成時には、「The following information is for reference only, as no highly matching knowledge was found」と明示し、高い不確実性としてマークしてください。

デグレードの可観測性を確保してください。すべてのデグレードイベントをログに記録し、監視してください。デグレード率が急増した場合、ナレッジベース (インデックス破損やデータ陳腐化など) の問題、またはベクトルデータベースサービスの問題が疑われ、迅速な調査が必要です。

アンチパターン：検索失敗を黙って無視し、検索コンテキストなしでモデルに回答を生成させることです。ユーザーは、その回答が知識に裏付けられているのか、モデルのハルシネーションなのかを区別できません。

Alibaba Cloud での実践：Model Studio のナレッジベース設定で、検索結果の類似度スコアしきい値を設定できます。デグレードロジックはアプリケーションコードで実装します。類似度スコアや返却件数などの検索品質メトリクスを SLS に記録します。ARMS でデグレード率アラートを設定します。

根拠

エージェントが実行する複雑なタスクは複数ステップに及び、完了までに数分、場合によっては数時間かかることがあります。途中のいずれかのステップで失敗しても、タスク全体を最初からやり直す事態は避けるべきです。特に、メール送信やデータのコミットなど、完了済みステップが外部に副作用を持つ場合はなおさらです。チェックポイントにより、タスクを最後に成功したチェックポイントから再開できます。

実装

タスク状態を永続化します。タスクの実行状態を、データベースやオブジェクトストレージなどの永続ストレージに定期的に保存します。状態には、完了済みステップの一覧、各ステップの出力、現在実行中のステップ、次ステップの入力パラメータを含めてください。各ステップの完了直後に状態を永続化します。

チェックポイントを設計します。タスクのステップ間にチェックポイントを設定します。各チェックポイントには、その時点までの完全な実行状態と中間結果を記録します。障害復旧時は、直近のチェックポイントから状態をロードし、すでに成功したステップはスキップして実行を継続します。

べき等性を確保します。再開時には、失敗したステップが再実行される可能性があります。そのため、各ステップはべき等性を持つように設計する必要があります。つまり、再実行しても追加の副作用が発生しないことです。メール送信のように自然にべき等にならない操作では、実行ログを確認して当該ステップがすでに成功しているかを判断し、重複を防止してください。

手動復旧メカニズムを提供します。オペレーターがタスク復旧を手動でトリガーできる UI または API を提供します。特定のチェックポイントから再開する、あるいは失敗したステップをスキップして後続ステップを継続する、といった選択を可能にしてください。中間結果の修正に人手介入が必要なシナリオなど、自動復旧できない場合に備え、実行再開前に修正済みデータを注入できるようにします。

アンチパターン：長時間実行タスクで状態を永続化せず、障害時にフルリスタートを強いること。あるいは、チェックポイントはあるが復旧ロジックに不具合があり、完了済みステップが再実行されてデータ重複が発生することです。

Alibaba Cloud での実践：Function Compute (FC) または Cloud Workflows を使用してタスクのオーケストレーションと状態を永続化します。Model Studio のワークフローはステップレベルの実行状態記録をサポートします。障害診断と復旧検証のために、タスク実行の軌跡を SLS に記録します。

根拠

エージェントが依存する外部ツール (API、データベース、サードパーティサービスなど) は、利用不能になったり応答が遅くなったりする可能性があります。適切な制御がないと、エージェントは失敗したツール呼び出しを繰り返しリトライし、リソースを浪費しながらユーザーの待ち時間を増加させます。サーキットブレーカーパターンにより、障害中のツールへの呼び出しを迅速に遮断し、リソース浪費を防ぎ、障害からの回復を高速化できます。

実装

外部ツールごとに独立したサーキットブレーカーインスタンスを構成します。サーキットブレーカーは、ツール呼び出しの成功、失敗、タイムアウトを記録し、スライディングウィンドウで失敗率を算出します。

サーキットブレーカーのトリガー条件を設定します。スライディングウィンドウ (例：直近 30 秒) 内で、ツール呼び出しの失敗率がしきい値 (例：50%) を超える、または平均レイテンシが SLO (例：タイムアウト値の 2 倍) を超える場合、サーキットブレーカーを Open 状態に遷移させます。

オープンサーキット時の挙動を定義します。サーキットブレーカーが Open のとき、当該ツールへの後続呼び出しは実行しません。代わりに、事前定義したフォールバック結果を即時に返します。フォールバック結果は、偽の成功を返すのではなく、「ツールが現在利用できない」ことをモデルに伝える情報を含める必要があります。この情報を受け取ったモデルは、ステップをスキップする、代替手段を使用する、またはタスクを完了できない旨をユーザーに伝えるなど、戦略を調整できる必要があります。

回復戦略を実装します。一定時間 (例：30 秒) 後、サーキットブレーカーは Half-Open 状態に入り、少数のリクエストを通してツールが回復したかどうかをテストします。テストが成功すれば Closed に戻して通常呼び出しを再開します。失敗が続く場合は Open のまま維持します。

ツール依存関係を分類します。「必須ツール」と「任意ツール」を区別してください。必須ツールのサーキットブレーカーが Open になった場合、タスク全体は待機またはデグレード状態に移行する必要があります。任意ツールのサーキットブレーカーが Open になった場合、そのステップをスキップして後続ステップを継続できます。

アンチパターン：ツール呼び出しにタイムアウト、リトライ上限、サーキットブレーカーがなく、単一の障害ツールがエージェント全体の応答を引きずること。あるいは、サーキットブレーカーが粗すぎて、ツールの一つのエンドポイントの障害が原因で、そのツールへのすべての呼び出しをブロックしてしまうことです。

Alibaba Cloud での実践：ARMS はサービス呼び出しのヘルス監視を提供します。アプリケーションコードでは、Sentinel などのサーキットブレーカーコンポーネントを使用して、ツール単位のトリップ戦略を実装できます。各ツール呼び出しの結果とレイテンシを SLS に記録し、ARMS で失敗率ベースのアラートルールを設定します。

根拠

エージェントの「サービス品質」は、99.9% 稼働率のような従来の可用性メトリクスだけでは測れません。エージェントは常時オンライン (可用性 100%) でも、タスク完了率が 60% しかなく、平均完了時間がユーザーの期待を大きく上回る可能性があります。エージェントのサービス品質を包括的に測定するために、AI 固有のサービスレベル目標 (SLO) を定義する必要があります。

実装

コアとなるサービスレベルインジケーター (SLI) を定義します。少なくとも次を含めてください：

タスク完了率：受け付けたタスクのうち、エージェントが正常に完了した割合です。「完了」の定義を明確にしてください。モデルが結果を返したことを指すのか、結果が品質検証を通過したことを指すのか。後者を推奨します。

エンドツーエンドレイテンシ：ユーザーがリクエストを開始してから最終結果を受け取るまでの総時間です。複数ステップのタスクでは、個々のステップのレイテンシではなく総レイテンシを記録します。P50、P90、P99 パーセンタイルの目標を設定してください。

最初のトークンまでの時間 (TTFT) ：ストリーミングシナリオでは、ユーザーが応答の開始を見るまでに待つ時間です。体感の応答性に大きく影響します。

出力品質スコア：自動評価 (LLM-as-a-Judge など) またはユーザーフィードバック (thumbs-up/thumbs-down など) により、出力品質を定量化します。正確性、完全性、関連性など複数の次元で評価できます。

SLI に基づいて SLO 目標を設定します。例：タスク完了率 >= 95%、P90 エンドツーエンドレイテンシ <= 30 秒、出力品質スコア >= 4.0/5.0。業務シナリオに応じて SLO 目標を差別化してください。カスタマーサポートアシスタントはレイテンシ要件が厳しく、データ分析タスクは正確性要件が厳しくなります。

エラーバジェットの仕組みを確立します。SLO の余裕が健全なときは、モデル更新やプロンプト最適化などの積極的な変更を行えます。SLO がしきい値に近いときは変更を凍結し、安定性の改善に集中します。

アンチパターン：CPU 使用率、メモリ使用量、プロセス生存など、従来のインフラメトリクスだけで AI システムの健全性を判断することです。これでは「オンラインだが役に立たない」状態を検知できません。

Alibaba Cloud での実践：ARMS は、SLI と SLO ダッシュボードのためのカスタム業務メトリクス定義をサポートします。SLS を使用して、タスク完了率やレイテンシのパーセンタイルなどのメトリクスを収集・算出します。DingTalk と統合してアラートを送信し、SLO が悪化した際にオンコール担当者にリアルタイムで通知します。Prometheus 互換性により、ARMS は AI SLI を統合可観測性システムに取り込めます。