9月5日、AWSが「How Intuit built an agentic disaster recovery assistant with Amazon Bedrock」と題した記事を公開した。この記事では、IntuitがAmazon Bedrockを活用して障害復旧（DR）作業をAIエージェント化した実装事例について詳しく紹介されている。
「数時間かかっていた障害復旧」を20分に短縮したEWOK
TurboTax、QuickBooks、Mailchimp、Credit Karmaを擁するIntuitは、数千のマイクロサービスを複数のAWSリージョンにわたって運用している。障害復旧（DR）の場面では、どのフェイルオーバー手順を選ぶか、アセットが準備完了かどうかの判断が、熟練したオンコールエンジニアの「暗黙知」に依存していた。
その状況を変えるために構築したのが、EWOK（Ecosystem Wide Orchestrator Kit）だ。EWOKはコンピュート、データベース、ネットワーク、キャッシュ、非同期ワークロードにまたがるフェイルオーバー実行を標準化したシステムで、サービスオーナーがYAMLでリカバリ手順を宣言すると、インフラ操作を自動オーケストレーションする。これにより復旧時間を数時間から約20分に短縮した。
ただし、EWOKが解決したのは「実行」であって「意思決定」ではなかった。どのワークフローを選ぶか、ポリシー上の例外（例：チェンジフリーズウィンドウ中のフェイルオーバー要求）をどう処理するか、といった判断は依然としてエンジニアの経験値に委ねられていた。
この判断ギャップを埋めるために構築されたのがEWOK Agentだ。Amazon Bedrockを基盤とするAIエージェントで、過去8ヶ月にわたってIntuit全社のチームが本番フェイルオーバーに使用してきた。
エンジニアの体験：「フェイルオーバーして」の一言で完結
オンコールエンジニアは、社内エンジニアリングポータルまたはIDE上で次のように入力するだけでよい：
"Failover payments-gateway in production"
EWOK Agentはこの自然言語リクエストを受け取り、以下を自律的に実行する：
- アセットを特定し、利用可能なリカバリワークフローを発見
- 適切なフェイルオーバーワークフローを選択（複数ある場合はエンジニアに確認）
- 準備状態を検証し、ポリシーゲート（チェンジフリーズウィンドウ等）を確認
- EWOKシステム経由で実行をトリガーし、実行IDとチェンジレコードを返却
- ステージごとのステータスを監視・報告しながらフェイルオーバー完了まで追跡
「以前はランブックを調べ、コンソールを渡り歩き、エンジニア自身がAPIコールを調整していた。今はエンジニアが会話を監督する」と記事は説明している。
アーキテクチャの核心：「スキル」という設計思想
EWOK Agentの設計で最も特徴的なのが、フェイルオーバー手順をスキルとして定義するアプローチだ。スキルは人間が読めるMarkdownファイルで、次の2つで構成される：
- YAMLフロントマター：型付きI/Oスキーマ（AIモデルへのツール定義に直接コンパイルされる）
- プロンプト本文：モデルが従うべき手順、ルール、判断ロジック
name: failover-manager
description: >
Manages failover workflows for assets: list workflows, invoke
failover, and check execution status.
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
このスキーマはドキュメントとして機能するだけでなく、Amazon Bedrock Converse APIのツール定義に直接コンパイルされ、モデルが推論に使用する。
ポリシーゲートを「例外」ではなく「分岐」として定義
プロンプト本文の設計で重要なのが、ポリシー違反をエラーではなく明示的な分岐として記述する点だ。チェンジフリーズウィンドウ中のフェイルオーバーは拒否されるが、その対応手順をスキル本文に直接埋め込む：
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.
以前は熟練エンジニアの記憶に依存していた「緊急オーバーライド手順」が、スキル定義に明文化されている。
4層アーキテクチャと「モデルは何をするか、EWOKはどうやるか」の分離
EWOK Agentは以下の4層で構成される：
- コンシューマー層：エンジニアリングポータルとIDE（MCP：Model Context Protocol経由で接続）
- エージェント層：Amazon Bedrockが担当。モデル選択、Amazon Bedrock Guardrailsの適用、スキルのディスパッチ
- スキル層：型付き・バージョン管理されたスキル群（YAMLスキーマ＋プロンプト本文）
- 実行層：EWOKのAPIが決定論的に処理（アセット解決、ワークフロー検索、準備確認、ポリシーゲート、チェンジレコード作成、フェイルオーバー本体）
記事が一貫して強調するのが次の原則だ：「モデルは何をするかを決め、EWOK Agentはどうやるかを決定論的に実行する」。AIに曖昧な推論をさせず、実行は既存の信頼できる自動化システムに委ねる設計だ。
Amazon Bedrockを選択した理由として記事は以下を挙げている：
- 複数のファウンデーションモデルを単一APIで切り替えられるため、エージェントを作り直さずにモデルを評価・変更できる
- Guardrailsによるセキュリティ制御が組み込まれている
- 本番金融システムを扱うため、データがモデル学習に使用されず、転送中・保存中ともに暗号化される点が特に重要
- フルマネージドのため、モデルインフラの管理が不要
実装パターンの汎用性
記事はEWOKがIntuit内部システムであることを認めつつ、「型付きスキル＋薄いAmazon Bedrock層＋決定論的エグゼキューター上の有界エージェントループ」というパターン自体は、認証済みで監査可能なAPIを持つ他のシステムにも適用できると説明している。
コードサンプルはBoto3とlangchain-awsを使用した例示的なものだ。Boto3はPython向けのAWS公式SDKであり、Amazon BedrockのConverse APIを呼び出す際の標準的な選択肢となっている。langchain-awsはLangChainのAWSインテグレーションパッケージで、エージェントループの実装を簡素化する役割を担う。
このパターンの本質は、AIモデルの担当範囲を「何をするかの判断」に限定し、「どうやるか」は既存の決定論的システムに委ねるという責任分離にある。これにより、AIの不確実性が実行レイヤーに波及することを防ぎつつ、自然言語インターフェースと既存自動化インフラの両立を実現している。スキルのバージョン管理と型付きスキーマの組み合わせは、変更の監査証跡を残す観点でも重要だ。
EWOK AgentはIDEプラグインとして提供されており、エンジニアはIntuitのエンジニアリングポータルまたは任意のIDEから直接フェイルオーバーを実行できる。
詳細はHow Intuit built an agentic disaster recovery assistant with Amazon Bedrockを参照していただきたい。
