Intuit、Amazon Bedrock で災害復旧エージェントを構築

大規模なディザスタリカバリ（DR）は容易ではありません。数千ものマイクロサービスが複数の AWS リージョンにまたがる場合、信頼性の高いフェイルオーバーを調整することは重大な運用課題となります。Intuit ではまさにこの規模で事業を展開しています。私たちが支える製品には、数百万人がビジネス運営や家計管理のために依存している TurboTax、QuickBooks、Mailchimp、そして Credit Karma などが含まれます。この課題を解決するため、私たちは Amazon Bedrock を活用したエージェント型ディザスタリカバリアシスタントを開発しました。これは、既存の中央集権的な社内ディザスタリカバリシステム「Ecosystem Wide Orchestrator Kit (EWOK)」の上に構築されたものです。EWOK は、コンピューティング、データベース、ネットワーク、キャッシュ、非同期ワークロードにわたるフェイルオーバー実行を標準化しています。サービスオーナーは YAML でリカバリの意図を宣言し、EWOK システムが基盤となるインフラストラクチャのアクションを調整します。これにより、対応可能なワークロードのリカバリ時間が数時間から約 20 分に短縮されています。

EWOK は実行プロセスは解決しましたが、意思決定の部分は残したままです。どの復旧ワークフローを適用すべきかを選択し、資産が準備完了していることを確認する作業は、依然として経験豊富なオンコールエンジニアに依存する「暗黙知」に頼っていました。同様に、復旧中に発生する例外処理もその範疇に含まれます。

典型的な例として、変更凍結期間（change-freeze window）中のケースが挙げられます。これは税務シーズンなど重要な業務時期にサービス可用性を保護するため、デプロイや変更を厳しく制限する期間です。この期間中にフェイルオーバーの要求が来ると、システムは自動的に却下されます。その場合、エンジニアは詳細な緊急時の手動介入手順を知っていなければ、処理を進めることができません。

このギャップを埋めるために、私たちは Amazon Bedrock を活用した AI エージェント「EWOK Agent」を開発しました。過去 8 ヶ月間にわたり、Intuit の各チームが EWOK Agent を利用してフェイルオーバーを実行しています。

Amazon Bedrock は、主要な AI プロバイダーが提供する数百ものファウンデーションモデルに、単一の API でアクセスできるプラットフォームです。これにより、フェイルオーバーの推論に適したモデルを評価・選択でき、要件の変化に応じてモデルを切り替えることも可能です。エージェントの再設計は不要です。

また、Amazon Bedrock Guardrails（Amazon Bedrock Guardrails）やセキュリティ、プライバシー保護機能も標準で備わっています。データはモデル学習に使用されず、転送中および保存時も暗号化されます。これは、エージェントが生産環境の金融システムを扱う際に特に重要です。

Amazon Bedrock はフルマネージドサービスのため、EWOK Agent の推論層を追加する際も、私たちはインフラのプロビジョニングや管理を行う必要はありませんでした。

EWOK Agent はプラグインとして提供されています。エンジニアはこれをインストールし、Intuit のエンジニアリングポータルまたはお好みの統合開発環境（IDE）integrated development environment (IDE) から直接フェイルオーバーを実行できます。

本記事では、EWOK エージェントのアーキテクチャと設計思想について解説します。フェイルオーバーの知識を「スキル」としてエンコードする際の設計原則や、ファウンデーションモデルとこれらのスキルを繋ぐ薄層の Amazon Bedrock 層の役割、そして「プロダクション環境の支払いゲートウェイをフェイルオーバーしてください」といった自然言語の要求を検証済みかつポリシーに準拠した復旧実行へと変換するエージェントループの仕組みについて説明します。ここでは具体的な実装手順よりも、設計パターンに焦点を当てています。

一貫して強調したいのは、以下の一点です。「モデルが何をすべきかを決定し、EWOK エージェントがその方法を確定的に実行する」という原則です。後述する各設計上の選択は、この境界線を明確に保つために存在しています。

始める前に

本記事で説明するのは、具体的なデプロイ手順ではなく、アーキテクチャと再利用可能なパターンです。提示されているコードサンプルは実装例の一部であり、そのまま実行可能な完全な実装ではありません。設計思想を理解し、このパターンを自社の環境に適応させるためには、以下の知識があると役立ちます。

• Amazon Bedrock の概要と、AWS リージョン内でファウンデーションモデル (FM) へのアクセス権限が付与される仕組みに関する理解。Amazon Bedrock で提供されているファウンデーションモデルの利用可否は AWS リージョンによって異なりますので、このパターンを採用する前に、ご自身のリージョンで選択したモデルが利用可能か必ずご確認ください。

スキルからツールへのコンパイルには、Amazon Bedrock Converse API およびそのツール使用（関数呼び出し）機能の理解が必要です。

• Amazon Bedrock Guardrails の仕組みと、Bedrock ワークロードが通常呼び出す IAM アクション（例：bedrock:Converse）の理解が必要です。

bedrock:ConverseStream、bedrock:InvokeModel、および bedrock:ApplyGuardrail のような権限を付与するだけで済むため、セキュリティと実行境界に関する判断は非常にシンプルになります。

本記事で使用するコードサンプルでは、Python と AWS SDK for Python (Boto3)、langchain-aws ライブラリの基本的な知識を前提としています。

リカバリー実行レイヤー（EWOK）は Intuit 内部のシステムです。ただし、このパターン自体（型付きスキル、簡易的な Amazon Bedrock レイヤー、決定論的エグゼキューターに対する制限されたエージェントループ）が EWOK に限定されるものではなく、認証済みで監査可能な API を提供する他のシステムにも適用可能です。

Ecosystem Wide Orchestrator Kit (EWOK) の概要

序章では EWOK エージェントの基盤となるサービスとして EWOK について紹介しました。本記事全体を通じて頻出する用語がいくつかあるため、実際の解説に入る前にここで定義しておきます。

アセット: アセットとは、EWOK がトラフィックを管理する登録済みかつ復元可能な単位であり、サービスまたはサーバーレスアプリケーションです。復元可能な単位には通常、以下の要素が含まれます。

• 計算層（例：Kubernetes の名前空間やクラスター、Amazon Elastic Compute Cloud (Amazon EC2) の ターゲットグループ）

• トラフィックのエンドポイント（例：Amazon API Gateway のルートや、サービスメッシュ のホスト名）

• 関連するデータベース（例：Amazon Aurora グローバルデータベース）

• 関連するキャッシュ（例：Amazon ElastiCache）

• 非同期またはステートフルな依存関係（例：メッセージキューやパイプライン）

復元ワークフロー: 復元ワークフローとは、EWOK が劣化したプライマリリージョンから健全なセカンダリリージョンへアセットを移行するために実行する一連の自動化された手順です。つまり、フェイルオーバーのことです。ユーザーは YAML 設定ファイルを通じて復元の意図を宣言します。このファイルでワークフローの各ステージを定義し、それぞれのステージが特定のアクションにマッピングされます。YAML はインフラの詳細な仕組みを抽象化するため、オーナーは「何を」「どの順序で」復元するかという本質的な部分に集中でき、低レベルなインフラ構成の詳細には立ち入らなくて済みます。

Asset: payments-gateway
primary: region-a
secondary: region-b
stages:
  - compute # scale up capacity in the secondary region
  - database # promote the secondary replica to primary
  - cache # warm and cut over the cache tier
  - traffic # shift routing from primary to secondary

準備度チェック: 準備度チェックは、フェイルオーバーワークフローの実行を許可する前に資産に対して実行される事前検証です。これにより、資産が EWOK によるトラフィック移行の安全なオーケストレーションに必要な要件を満たしているかを確認します。

ポリシーゲート: ポリシーゲートとは、EWOK がワークフローの実行前または実行中に評価するガードレールや制限事項のことです。これらは、技術的な資産の準備度を超えた組織的・運用上・コンプライアンスレベルの統制を表しており、ワークフローが継続して進められるかどうかを決定します。

実行 ID: 実行 ID は、EWOK ワークフローの単一の実行に対して割り当てられる一意の値です。ワークフローのトリガー発生から完了または失敗に至るまでの全段階を通じて、その特定の執行インスタンスをエンドツーエンドで識別するものです。

変更記録: 変更管理システムにおける正式なエントリであり、本番環境への変更を承認し文書化するものです。EWOK は本番ワークフローが開始されるとこれを開き、実行終了時に閉じます。これにより、すべてのフェイルオーバーが承認され、人間のオペレーターが従うのと同じプロセスを通じて監査可能になります。変更記録なしに本番ワークフローが実行されることはありません。

チームはどのようにフェイルオーバーを実行するか

アーキテクチャの詳細に入る前に、EWOK Agent を使用して EWOK でフェイルオーバーを実行するエンジニアの体験を以下に示します。

オンコール担当のエンジニアは、社内エンジニアリングポータルまたは IDE からエージェントに対して次のように指示を出します。

「本番環境の支払いゲートウェイをフェイルオーバーしてください」

EWOK Agent はその後、

資産を特定し、利用可能な復旧ワークフローを検出します。

適切なフェイルオーバー・ワークフローを選択します（複数の選択肢がある場合はエンジニアに選択を依頼します）。

準備状態を確認し、ポリシーのゲート（例：変更凍結期間中かどうか）をチェックします。

EWOK システムを通じて実行を開始し、「実行 ID」と「変更記録」を返却します。

フェイルオーバーが完了するまで、段階ごとのステータスを監視・報告します。

これらのタスクは従来、ランブックの参照とコンソールの操作という一連の手順でした。以前はエンジニアが API 呼び出しを調整していましたが、現在は対話の内容を見守る役割に変わりました。エンジニアは判断や承認が必要な場面で関与し続けますが、もはや調整役（オーケストレーター）である必要はありません。

ソリューションの概要

EWOK エージェントは、高レベルでは 4 つのレイヤーで構成されています。以下の図は、エンジニアからのリクエストから決定論的な復旧アクションに至るまでのエンドツーエンドの流れを示しています。アーキテクチャは上から下へと整理されています。

• コンシューマー層（最上位）: Intuit のエンジニアリングポータルと IDE 統合を保持しており、Model Context Protocol (MCP) を介して接続されています。これは、エンジニアが自然言語でリクエストを入力する 2 つの主要なエントリーポイントです。

• エージェント層: Amazon Bedrock で実行され、基盤モデルの選択と制限された推論ループを組み合わせます。また、各呼び出し時に適用される Amazon Bedrock Guardrails を備えています。このレイヤーでは、モデルの選定、ガードレールの適用、スキルのディスパッチを担当します。

「スキルレイヤー（右側）」には、型付きでバージョン管理されたスキルが保持されています。各スキルは YAML スキーマとプロンプト本文によって定義され、これらがコンパイルされてモデルが選択するツール仕様に変わります。

「実行レイヤー（下部）」は EWOK API レイヤーです。ここでは、アセットの解決、回復ワークフローの検索、準備状況の確認、ポリシーゲートの通過、execution-ID-based による追跡、変更記録の作成、そしてフェイルオーバー自体が、計算リソース、データベース、キャッシュ、トラフィックに特化したエージェントを通じて決定論的に実行されます。

ステータスは、この経路を逆方向に戻り、実行レイヤーからエージェント層を経てエンジニアへと返されます。

図 1: EWOK エージェントのアーキテクチャとリクエストフロー。エンジニアからの要求が Amazon Bedrock を経由し、EWOK 内の決定論的な回復アクションに至るまでの流れです。

• オンコールのエンジニアは、内部エンジニアリングポータルまたは IDE アシスタント（MCP を介して）から、自然言語による要求を発行します。
• エージェント層は、その要求とコンパイル済みのスキルツール仕様をセットにして、Amazon Bedrock Guardrail 各呼び出しに付随させながら、基盤モデルへ Amazon Bedrock Converse API を通じて送信します。
• モデルが適切なスキルを選択し、ターゲットアセットや環境などを指定した構造化されたツール使用要求（例えばフェイルオーバースキルの実行）を返します。
• スキルのエグゼキューターは、EWOK の API に対して選択された操作を実行します。これにはアセットの解決、ポリシーゲートの確認、変更記録の作成、ワークフローの呼び出しが含まれ、その後構造化された結果が返されます。

EWOK は、承認された復旧ワークフローを、計算リソース、データベース、キャッシュ、トラフィックの各階層に配置された負荷固有のエージェントを通じて実行し、その段階ごとのステータスをループ経由でエンジニアへ報告します。

障害フェイルオーバーの知識をスキルとしてエンコードする

EWOK エージェントの設計における根本的な決断は、人間向けのランブック（手順書）を作成するのをやめ、*スキル* の作成に切り替えたことです。スキルとは、同時に人間が読みやすい手順であり、機械が消費可能な機能定義となるものです。

スキルは 2 つの部分からなる Markdown ファイルです。

• YAML フロントマター：型付きの I/O スキーマを宣言し、運用上の契約として機能します。
• プロンプト本文：モデルが従うべき指示、ルール、意思決定ロジックを含みます。

障害フェイルオーバー管理のための簡略化されたスキルの定義は以下の通りです。

name: failover-manager
description: >
  Manages failover workflows for assets: list workflows, invoke
  failover, and check execution status. Use when the user asks to
  "trigger failover" or "check failover status" for an asset.
input_schema:
  operation:
    type: string
    description: "'get-workflows', 'invoke-failover', or 'get-status'"
    required: true
  asset_name:
    type: string
    description: "Name or alias of the asset to act on"
    required: true
  environment:
    type: string
    description: "Target environment, e.g. 'staging' or 'production'"
    required: true
  incident_number:
    type: string
    description: "Only needed to override an active change-freeze window"
    required: false
output_schema:
  status:
    type: string
    description: "'success' or 'error'"
  result:
    type: object
    description: "Operation-specific payload (workflows, execution ID, or status)"

このスキーマは単にスキルを文書化するだけでなく、モデルが推論を行うためのツール定義へと直接コンパイルされます。そして、スキルのアクションは EWOK の API に対して実際のエグゼキューターを通じて実行されます。

スキルプロンプト本文の作成方法

プロンプト本文には運用上の判断が宿ります。ここでは自由な文章ではなく、構造化されたルールベースの形式を厳守しています。

• 明示的な操作手順: 各操作に対して番号付きのステップを設け、それぞれが正確に 1 つのエグゼキューター呼び出しに対応します。
• エラー発生時の即座停止ルール: ステップで失敗が発生した場合、そのスキルは直ちに終了します。モデルはエグゼキューターが一時的な再試行を既に処理しているため、再試行や代替案の自作を明示的に禁止されます。

「ポリシーゲートを第一級ブランチとして扱う」これはエラーではなく、明確な出口を持つ定義済みのフローです。

「構造化されたレスポンス契約」モデルは宣言された出力スキーマに値を埋め込みます。独自の形式を生成することはありません。

このポリシーゲートパターンの効果は具体例で最もよくわかります。Intuit では、変更凍結期間中のフェイルオーバーはインシデントと紐付いている場合に限り許可されます。以前はこの判断基準はエンジニアの記憶に依存していましたが、現在はスキル本体内で明示的な分岐として実装されています。

If the invoke result has status "change_blocked":
    This is NOT an error. Change restrictions are active for this asset.
    Ask the user for ONE of:
    - an incident number (e.g. INC0001234), or
    - an emergency justification (24-100 characters)
    Re-run the invoke exactly once with the value provided.
    If the user declines, stop and report that the failover was not executed.

Amazon Bedrock レイヤー：モデルをスキルに接続する

スキルは意図的に基盤モデルに依存しない設計となっています。これらと基盤モデルを繋ぐのは、Amazon Bedrock の薄いレイヤーだけで、この層には 3 つの役割があります。

1 つ目は、各スキルのスキーマを Amazon Bedrock のツール仕様へ変換することです。Amazon Bedrock の Converse API は、モデルが呼び出せるツールを記述した toolConfig を受け付けます。ローダーは、スキルごとに 1 回ずつ以下の関数を実行します。ロード時には、各スキルが 1 つのツールエントリとして登録されます。

def to_tool_spec(skill) -> dict:
    """Compile a skill's declared schema into a Bedrock toolSpec."""
    properties = {
        name: {"type": field.type, "description": field.description}
        for name, field in skill.input_schema.items()
    }
    required = [n for n, f in skill.input_schema.items() if f.required]
    return {
        "toolSpec": {
            "name": skill.name,
            "description": skill.description,
            "inputSchema": {"json": {
                "type": "object",
                "properties": properties,
                "required": required,
            }},
        }
    }

これにより、モデルは文脈から適切な機能を自動で選択できるようになります。例えば、「本番環境の決済ゲートウェイをフェイルオーバーする」というリクエストを受け取ると、事前定義された決定木を手動で記述することなく、自動的にフェイルオーバー機能が発動します。具体的には、operation=invoke-failover、asset_name=payments-gateway、environment=production というパラメータが設定され、システムが正しく動作します。

2 つ目の課題は、モデルをプラグイン可能に保つことです。Amazon Bedrock の Converse API はすべてのモデルで統一されているため、モデル自体がアーキテクチャ上の固定事項ではなく、設定値として扱われます。新しいファウンデーションモデルの評価や導入も、設定を変更するだけで行えるため、スキル、ループ、エグゼキューターといった他の部分は一切変更する必要がありません。

3 つ目の課題は、ガードレールの実装です。すべてのモデルに Amazon Bedrock Guardrail を接続します。