公開：2026年9月5日, 最終更新：2026年9月5日
30秒サマリー
- 米Intuitが数千規模のマイクロサービス環境向けAI駆動型ディザスタリカバリエージェント「EWOK Agent」の構築手法をAWS公式ブログで公開
- 既存の自動化基盤EWOKにAmazon Bedrockを薄く重ねる設計で、エンジニアが自然言語でフェイルオーバーを指示できる仕組みを実現
- 「モデルが何をすべきか判断し、EWOKが確定的に実行する」という役割分離が設計の核心で、過去8カ月にわたり社内で実運用中
何が起きたか
米Intuit（TurboTax・QuickBooks・Mailchimp・Credit Karmaを運営）は、数千規模のマイクロサービスが複数AWSリージョンにまたがる環境でのディザスタリカバリ（DR）自動化の取り組みについて、AWS Machine Learning Blogで詳細なアーキテクチャ解説を公開した。
Intuitはもともと、フェイルオーバー実行を標準化する内部システム「EWOK（Ecosystem Wide Orchestrator Kit）」を保有しており、コンピュート・データベース・ネットワーク・キャッシュ等のインフラ操作をYAML宣言で統一。対象ワークロードのリカバリ時間を数時間から約20分に短縮していた。ただし「どのワークロードにどのリカバリ手順を適用するか」「チェンジフリーズ期間中の例外処理をどうするか」といった意思決定は、依然として熟練エンジニアの暗黙知に依存していたという。
このギャップを埋めるためにAmazon Bedrockを用いて構築したのが「EWOK Agent」だ。エンジニアはIntuit社内のエンジニアリングポータルまたはIDEから「failover payments-gateway in production」のような自然言語で指示を入力するだけで、エージェントがアセットの特定・リカバリワークフローの選択・ポリシーゲート（チェンジフリーズ等）の確認・実行IDと変更記録の発行・ステージ別進捗報告を自律的に行う。同エージェントは過去8カ月にわたり社内で実運用されているとブログは述べている。
アーキテクチャは「コンシューマー層（ポータル／IDE）」「エージェント層（Amazon Bedrock＋Guardrails）」「スキル層（YAML定義の型付きスキル群）」「実行層（EWOK API）」の4層構造。スキルはMarkdownファイルとして定義され、YAMLのI/Oスキーマとモデルへの指示プロンプトで構成される。基盤モデルの選択・切り替えはアーキテクチャを変更せずに可能で、データはモデルの学習に使用されず転送中・保存時ともに暗号化されると説明されている。
原典ハイライト
「モデルが何をすべきかを決定し、EWOK Agentが確定的にどのように実行するかを担う」という役割の明確な分離がEWOK Agent設計の根幹。スキルをYAMLスキーマ＋プロンプト本文のMarkdownファイルとして定義することで、人間が読めるドキュメントと機械が消費できるツール仕様を一体化している点も特徴として強調されている。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
本事例が示すのは、既存の自動化基盤（API・ランブック）を「そのまま」残しつつ、その上にLLMによる意思決定層を薄く重ねることで、属人的な暗黙知に依存していた判断プロセスを自動化できるという設計パターンだ。フルスクラッチでAIシステムを作るのではなく、既存の確定的実行基盤をLLMエージェントから呼び出す構成は、信頼性・監査可能性・移行コストの観点から現実的な選択肢として注目される。
日本企業への示唆
日本の大規模システムを抱える企業にとって、本事例は「AIエージェント×既存運用基盤」の現実的な統合モデルとして参照価値が高い。特に①自然言語指示による運用負荷の軽減、②チェンジフリーズやコンプライアンスポリシーをエージェントに組み込む設計、③スキル定義による暗黙知の形式化、の3点は、金融・製造・通信など複雑な変更管理規程を持つ業種での応用が検討できる。まず自社の既存APIや自動化スクリプトをスキルとして定義できるか棚卸しすることが第一歩となるだろう。
背景・経緯
Intuitは税務・会計・マーケティング等の金融関連SaaSを全米規模で提供しており、特にTurboTaxが稼働する確定申告シーズンはシステム可用性への要求が極めて高い。EWOKはその信頼性要件に応えるために構築された内部DR基盤。EWOK Agentはその意思決定ギャップを埋める目的でAmazon Bedrockを採用して開発され、8カ月以上の実運用実績があると原文は述べている。
