- IntuitがAmazon Bedrock上にAI災害復旧アシスタント「EWOK Agent」を構築し8カ月運用中
- 基盤となるEWOKは復旧時間を数時間から約20分に短縮済みで、今回は判断支援を強化
- モデルは「何をするか」、EWOKは「どう実行するか」を担当する境界設計が特徴
背景と発表内容
米Intuitは2026年9月4日、自社の災害復旧(DR)プロセスをAIで支援する「EWOK Agent」のアーキテクチャを解説する記事を公開しました。IntuitはTurboTax、QuickBooks、Mailchimp、Credit Karmaなど、多くのユーザーが利用する製品を手がけており、数千規模のマイクロサービスが複数のAWSリージョンに展開されています。
EWOK Agentは、同社が既に運用している内部の災害復旧システム「Ecosystem Wide Orchestrator Kit(EWOK)」を拡張したものです。EWOKはコンピューティング、データベース、ネットワーク、キャッシュ、非同期ワークロードにわたるフェイルオーバー実行を標準化し、サポート対象のワークロードでは復旧時間を数時間から約20分に短縮しています。
EWOKが残した課題
EWOKは「実行」の問題は解決しましたが、「判断」の部分は属人化したままでした。どの復旧ワークフローを適用すべきか、アセットが復旧可能かどうかを確認し、復旧途中で発生する例外を処理するのは、経験豊富なオンコールエンジニアの暗黙知に依存していました。
具体例として、変更凍結期間が挙げられます。税務申告シーズンなど重要業務期間中は、サービスの可用性を守るためにデプロイや変更が厳しく制限されます。その期間中にフェイルオーバー要求が届くと拒否されますが、緊急時には詳細なオーバーライド手順を知っていなければ回避できません。このような判断をAIに委ねるために構築されたのがEWOK Agentです。
技術的な新しい点
EWOK AgentはAmazon Bedrockを利用して構築されています。Amazon Bedrockは単一のAPIで多数の基盤モデル(FM)にアクセスできるため、フェイルオーバーの推論に適したモデルを評価・選択でき、アーキテクチャを変更せずにモデルを切り替えることができます。また、Amazon Bedrock Guardrailsによる安全機能や、送受信中の暗号化なども内包されています。
アーキテクチャは上から順に、エンジニアがアクセスする「コンシューマーレイヤー」(Intuitの社内ポータルやIDE、MCP経由)、Amazon Bedrock上でモデル選択とガードレールを担う「エージェントレイヤー」、復旧ノウハウを定義した「スキルレイヤー」、実際の復旧処理を実行する「実行レイヤー(EWOK API)」の4層で構成されます。
設計の中心となる境界
EWOK Agentの設計で一貫しているのは、「モデルは何をするかを決定し、EWOK Agentはどのように実行するかを決定的(デターミニスティック)に実行する」という境界です。モデルは自然言語の要求から適切なスキルを選択し、構造化されたツール要求を返しますが、実際のインフラ操作はすべてEWOKのAPIが実行します。
スキルはMarkdownで記述され、型付きの入出力スキーマを宣言するYAMLフロントマターと、モデルが従うプロンプト本文で構成されます。現場の知識を「人間が読める手順書」から「機械も扱える定義」に変換し、フェイルオーバー実行の際は変更記録(チェンジレコード)が自動的に作成されるため、運用の監査可能性も維持されます。
The model decides what to do, and the EWOK Agent deterministically executes how.
モデルは何をするかを決定し、EWOK Agentはどのように実行するかを決定的に実行する。
今後の見通し
EWOK AgentはIntuit社内で8カ月利用されており、Amazon Bedrockを介してモデルを交換できるため、将来より優れた推論モデルが登場した際には、エージェント全体を再設計せずに移行できる可能性があります。ただし、AIによる判断の正確性や、エッジケースでの対応品質についての定量的な評価は公表されていません。今後このようなエージェント型運用の実例が増え、どの程度属人的判断を削減できたかが明らかになれば、日本企業でも同様のパターンを適用するか判断できる余地が広がるとみられます。
日本の開発者・IT企業にとっての意味
日本の大規模ITシステムでも、災害復旧手順は属人的な知識に依存しており、担当者が変わると復旧に時間がかかるという課題があります。Intuitの事例は、AIに「判断」を任せる部分と、従来からある「実行」システムの境界を明確に分離するという設計を示しており、そのまま参考にできる点は多いでしょう。特に、YAMLで復旧意図を宣言し、ポリシーゲートや変更記録を自動化する仕組みは、日本企業の監査要件とも親和性が高いとみられます。また、Amazon Bedrockを使うことでモデルを特定のベンダーに固定せずに済むのは、選定リスクを軽減したい企業にとって実務上の利点になります。一方で、AIエージェントを本番に組み込むには、既存システムがAPI化されていて監査可能であることが前提になるため、まずはそこから整備する必要があります。
気になる点
- EWOK Agentはどの基盤モデルを使っているのか？
- 原文には特定のモデル名は記載されていません。Amazon Bedrockを通じて多数の基盤モデルから選択し、フェイルオーバーの推論に適したモデルを評価できると説明されています。具体的なモデル名を知るには、Intuitの追加発表を待つ必要があります。
- この設計は日本企業でも応用できるか？
- 原文では、このパターンはEWOKに固有ではなく、認証と監査が可能なAPIを持つ他のシステムにも適用可能だと述べています。ただし、内部システムをAIエージェントに接続する前提として、Amazon Bedrockで利用したい基盤モデルが自社のAWSリージョンで使えるかを確認する必要があります。
- AIが直接フェイルオーバーを実行するのか？
- いいえ。AIモデルは要求から適切なスキルを選択し、実行判断を下すにとどまります。実際のインフラ操作はEWOKという既存の決定論的実行システムが行い、変更記録の作成やポリシーゲートのチェックもこの実行レイヤーが担うため、誤操作のリスクは想定よりも低く抑えられていると考えられます。
用語解説
- フェイルオーバー
- システム障害などで稼働中のサーバーが使えなくなった際に、待機系へ自動的に切り替えること。災害復旧の中心となる仕組み。
- Amazon Bedrock
- AWSが提供する基盤モデル向けのマネージドサービス。単一のAPIで複数のAIモデルを利用できる。
- MCP
- Model Context Protocolの略。AIモデルと外部ツールやデータソースを連携させるための標準プロトコル。
- 変更凍結期間
- サービス提供の安定性を保つために、システムへの変更やデプロイを制限する期間。多くの企業で繁忙期などに設定される。
- YAML
- データを人間が読みやすい形式で記述するための設定言語。システム構成やワークフロー定義によく使われる。
出典
How Intuit built an agentic disaster recovery assistant with Amazon Bedrock
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する