先に結論
IntuitがAmazon Bedrockを用いて構築したEWOK Agentは、人は監督、モデルは判断という分業を明確にした設計で、復旧実行を既存の自動化レイヤーへ委任することで実務的に運用できる形にしています。同社によると、サポート対象ワークロードでは復旧時間を「数時間」から約20分へ短縮したと報告されています（同社によると）。
GLOBAL AI BRIEF ・ PROCESS
復旧の判断と実行はどう分かれる？
- 1要求を伝えるポータル・IDE・MCP
- 2使う手順を選ぶBedrockがスキルを判断
- 3実行方法を定義入出力を実行契約にする
- 4変更を実行・記録EWOKが監査ログを残す
この記事で扱う問い
本稿は、Intuitが公表したAWSブログ記事（How Intuit built an agentic disaster recovery assistant with Amazon Bedrock）を一次情報として、何を実装し、どの判断でモデルと従来コードを切り分けたかを読み解きます。日本企業の導入担当者が社内で判断できるよう、設計の核心、導入時の条件、適用しないケース、実務チェックリストを示します。
一次情報の要点（短くまとめ）
同社によると、EWOK AgentはIntuitの既存の復旧オーケストレーター（EWOK）の上にAmazon Bedrockを組み、スキル（typed skills）をモデルが選び、実際の変更はEWOKの確定的APIが実行する仕組みを取っています。
同社によると、導入の結果、サポート対象のワークロードで復旧時間が「数時間」から約20分へ短縮されたとしています（同社によると）。
同社によると、EWOK Agentは過去8か月間に現場で利用されており、技能（スキル）はバージョン管理され、Amazon Bedrock Guardrailsを各呼び出しに適用していると説明しています（同社によると）。
EWOKとEWOK Agentが担う役割
EWOK（Ecosystem Wide Orchestrator Kit）はIntuit内の復旧ワークフローを定義する既存システムで、資産（Asset）ごとにYAMLで復旧手順を宣言し、実行をDeterministicに行う仕組みです。
EWOK AgentはこのEWOKの上で、自然言語の要求を技能へ変換し、技能の選択と判断をモデルへ委ねつつ、実行そのものはEWOKのAPI（変更記録・実行IDの生成を含む）に委任する役割を果たします。
設計の核心：スキル（skills）と実行の境界
同社はスキルをMarkdown＋YAML前文で定義し、入出力スキーマを型で宣言することで、モデルが選べる「ツール仕様（tool spec）」へコンパイルします。スキルは人も読めるドキュメントであり、同時に機械消費可能な契約です（同社によると）。
重要な設計判断は二点です。第一に、モデルは「何をするか」を決める（スキル選択とパラメータ生成）に留め、第二に、「どう実行するか」は既存の確定的な実行層（EWOK）へ任せる点です。これにより実行は監査可能で再現性のあるコード経路になります。
Amazon Bedrockの位置づけとガードレール
同社によると、Amazon Bedrockは複数の基盤モデルへ透過的にアクセスできる層として使われ、Converse APIのツール利用機能を介してスキルをモデルに提示しています（同社によると）。
さらに、同社はすべてのモデル呼び出しにAmazon Bedrock Guardrailsを適用しており、プロンプト注入や危険な出力をインフラ側で遮断する運用を取っています（同社によると）。
エージェントループの実装方針
エージェントは短い反復ループを回し、モデルがスキル呼び出しを返すたびに実行層へツール要求を投げ、その結果をモデルへ返して次の判断へ進めます。ループは最大反復数の上限を設け、ガードレール介入や終了理由に応じて明確に停止します（同社によると）。
同社はlangchain-awsやBedrock Converseを例に、ループ制御を明示的なコードで実装したことを挙げています。これは汎用のハーネスに頼らず、停止条件や回路遮断（circuit breaker）をアプリ固有に制御するためです。
運用での役割分担とガバナンス
人は監督（Human-in-the-loop）として、破壊的・不可逆的な操作やポリシー越え（例：変更凍結時の上書き）は必ず承認させるフローを残しています。これは誤操作・誤判断の被害を限定するためです（同社によると）。
実行はEWOKが変更記録（change record）と実行IDでオーソライズし、監査ログを残すため、事後のフォレンジックが可能です。モデルは認証情報を持たず、認証は実行コンテキスト側で注入されます（同社によると）。
比較表：従来運用とEWOK Agentの違い
| 観点 | 従来（人＋手動orスクリプト） | EWOK Agent（Intuit） |
|---|---|---|
| 意思決定 | オンコール担当者の経験・Runbook | モデルが候補を選び、提示（人が最終判断） |
| 実行の確定性 | 人の操作やスクリプト。ばらつきあり | EWOKが確定実行し、監査ログと実行IDを生成 |
| ポリシー適用 | 人の記憶頼り・手動チェック | ガードレールとポリシーベースの分岐で自動評価 |
導入時に日本企業が確認すべき実務チェックリスト
以下は本件の一次情報から直接導ける実務上の確認項目です。導入検討時に必ず社内で答えを得てください。
- 対象資産の選定：経営会議資料や顧客影響の大きいサービスから開始する。
- 実行層の既存化：復旧を担う確定的API（EWOK相当）が社内にあるか。
- 承認フロー：破壊的操作へ人の明示的承認を必須にすること。
- 監査ログと変更記録：実行IDと変更記録を残す運用が可能か。
- プロンプト注入対策：ガードレール等の入力検査をインフラでかけられるか。
導入で期待できる効果（一次情報に基づく）
同社によると、サポート対象ワークロードでは復旧時間が数時間→約20分へ短縮したとの報告があり、運用の一貫性と迅速性の向上が期待できます（同社によると）。
ただし、この効果は「サポート対象ワークロード」に限定され、すべてのサービスへそのまま適用できる保証は一次情報からは読み取れません。
適用しない条件・未検証範囲（重要）
一次情報が示す未検証項目は次の通りです。
- 総費用（導入・運用コスト）の公開値はない。
- 外部の第三者環境での再現性や同等効果の検証はされていない（同社によると）。
- 誤警報の絶対数や、復旧にかかる総人的工数の変化詳細は公開されていない。
したがって、同社の報告値は社内条件・自動化度合いに依存することを前提に判断すべきです。
日本企業が導入前に行うべきPoC設計（簡易案）
推奨PoCの流れ（3か月想定、外部監査は任意）:
- 対象サービスを1〜3件選定（経営影響が大きいもの）
- EWOK相当の実行APIを用意し、変更記録と実行ID発行を実装
- スキルを1つ書く（例：failover-invoke）、Bedrockのツール仕様へ変換
- 限定ユーザーで実稼働同等のドライラン（承認フローは人）を複数回繰り返す
- 誤警報率、発見から実行までの時間、人の確認数を計測する
FAQ（一次情報からのQ/A）
Q：モデルが誤った資産を選んだ場合は？
A：同社はスキルの入出力を型で定義し、実行前に人の承認を入れる運用を推奨しています（同社によると）。
Q：モデルが直接実行するような権限はありますか？
A：いいえ。モデルはツール引数（資産名など）を返すのみで、認証情報は実行コンテキスト側で注入されます（同社によると）。
編集部の実務的助言（導入判断の分岐）
スキルで判断、実行は既存コードへ戻すという設計は、監査・可視化・最小権限の確保という実務要件に合致します。日本企業が導入を検討するなら、まずは実行層の確立と承認フローの自動化をPoCで検証してください。
逆に、実行のための確定的APIが存在しない組織や、変更記録・監査要件が整っていない組織では、先に運用基盤を整備することが前提になります。
出典・検証範囲
主要出典：AWS Machine Learning Blog「How Intuit built an agentic disaster recovery assistant with Amazon Bedrock」（2026-09-04）。本文は同記事の公開内容（構成、設計、運用報告）を基に作成しています。
検証範囲：同記事の公開情報（設計、運用方針、数値報告の帰属）。未検証：第三者での再現性、導入コストの総額、長期の誤警報率の恒常値。
問い合わせ先（参考）
一次情報（AWSブログ）へのリンクを必ず参照し、社内セキュリティ・法務と協議のうえPoC計画を作成してください。