みずほ FG が自律型 AI エージェント基盤「みずほCowork」を開発し PoC 開始｜Claude Agent SDK と Skills、AWS 上の統制設計【AI活用事例】

要約

株式会社みずほフィナンシャルグループ（以下〈みずほ〉）は、自律型 AI エージェント基盤「みずほCowork」を開発し、専門的な知識や手順を伴う業務への適用に向けた PoC を開始すると発表しました（公式リリース 2026-10-05）。開発には AWS プロフェッショナルサービスの支援を受けています。

この事例から学べるのは、AI エージェントの性能ではなく、金融機関が AI に「業務を任せる」ための統制をどう設計するかです。公式発表から読み取れるポイントは次の 3 つです。

• 業務ノウハウを AI 基盤から切り分ける: Claude Agent SDK を使う汎用レイヤーと、ガードレール・業務手順（Skills）を載せる〈みずほ〉独自レイヤーの二層
• 実行環境を人ごとに分ける: 社員一人ひとりに AWS 上の専用作業環境を割り当て、端末やローカルデータに直接触れさせない
• まだ PoC 段階: 検証するのは適用可能性。定量効果・参加人数・期間は公表されていない

本記事は 公式プレスリリース（2026-10-05、PR TIMES 掲載）を一次ソースに、事実の整理と Links-Create の分析・研修用の演習を分けて解説します。演習の例は研修用の提案であり、〈みずほ〉が実施した事実ではありません。

何が発表されたか（公式情報ベース）

発表主体は〈みずほ〉自身です。PoC の開始を告げる発表であり、成果の発表ではない点を前提に読んでください。

みずほCowork の概要

項目	内容（公式リリースの記載を要約）
位置づけ	金融機関での利用に必要なセキュリティと統制を確保した自律型 AI エージェント基盤。〈みずほ〉独自のプロダクト
使う技術	Anthropic の Claude Agent SDK
実行環境	AWS 上に、社員一人ひとりの専用作業環境を割り当てる
できること	社員が目的と必要な資料を渡すと、AI が与えられた権限の範囲内で作業手順を組み立て、多数の資料を横断した調査・分析・情報整理、画面操作、レポートやプレゼンテーション資料の作成など、複数の工程からなるデスクワークを進める
これまでの基盤との関係	全社共通の AI エージェント基盤「みずほWiz Base」と、AI エージェントの量産を支える「エージェントファクトリー」の取り組みを発展させたもの。業務ごとに個別開発する AI エージェントとも使い分ける
段階	専門業務への適用に向けた PoC を開始

二層の「ハーネス」

公式リリースは、AI エージェントの動作を支える共通制御の仕組みを「ハーネス」と呼び、その構成を次のように説明しています。

「「みずほCowork」では、AIエージェントの動作を支える共通制御の仕組みである「ハーネス」を、Claude Agent SDKを活用する汎用的なエージェントレイヤーと、〈みずほ〉固有の業務要件を反映する独自レイヤーの二層で構成しています。」 — 出典: 株式会社みずほフィナンシャルグループ プレスリリース（2026-10-05）

レイヤー	公式リリースの記載（要約）
汎用的なエージェントレイヤー	Claude Agent SDK のツール実行やコンテキスト管理等の機能を使い、ファイル操作・情報収集・分析・成果物作成など、デスクワークを進めるための一般的な動作を制御する
〈みずほ〉独自のレイヤー	社内ルールに準拠したガードレールを組み込み、各部門の業務手順・判断基準・専門知識を「Skills」として追加できる構成

公式リリースは、この分け方によって、最新の AI モデルや AI エージェント技術を取り込み続けながら、〈みずほ〉固有の業務ノウハウを基盤技術と切り分けて蓄積・高度化できると説明しています。

PoC で検証する業務

公式リリースは、PoC で次のような業務への適用可能性を検証するとしています（「など」とされており、全件ではありません）。

• 案件資料の分析・整理
• 資料作成
• 調査データの分析
• 業務監査に関するチェック
• 専門レポートの海外向け要約・翻訳

統制の仕組み（AWS 上の構成）

項目	公式リリースの記載（要約）
実行場所	AI エージェントの実行環境と作業領域を、〈みずほ〉が管理する AWS 上に構築。利用者の業務端末やローカルデータへの直接アクセスを避け、ネットワークやアクセス範囲を〈みずほ〉の統制下で管理
利用者ごとの分離	Amazon ECS on AWS Fargate と Amazon S3 Files で、利用者ごとに実行環境と作業領域を分離し、利用状況に応じて起動・破棄
入出力の統制	Amazon Bedrock Guardrails による入出力の統制、ログ記録、運用監視
長時間の処理	動作が社員の業務端末に依存しないため、社員が端末を操作していない間も処理を続けられる
開発体制	AWS プロフェッショナルサービスの伴走支援で要件を整理し、アーキテクチャと実装方針を共同で策定。〈みずほ〉の AI・デジタル人材がプロダクトを開発

今後の展望（公式リリースの記載）

• 各部門の業務知識や社内ルールを使った Skills の検証・整備を進め、対応できる業務の範囲を広げる
• API の整備が難しい社内のレガシーシステムについては、必要に応じてブラウザ画面を操作する仕組みを作り、複数システムをまたぐ業務を進められる環境をめざす
• AI が必要なタイミングで適切な人に確認や承認を求めながら業務を進める UX の実現に向けて、継続的に更新する

公式リリースで開示されていない情報（推論で書かない）

• 業務時間の削減量・削減率など、PoC の定量的な結果（PoC は開始段階）
• PoC の参加人数・対象部門・期間・評価基準
• 使用する AI モデルの名前・バージョン
• 導入・運用の費用
• 本番導入の時期と対象範囲

これらは公式情報がないため、本記事でも記載しません。候補の発見元となった報道記事に導入人数や個別の業務例が書かれているとされますが、公式リリースで確認できないため採用していません。

設計の読み解き（Links-Create による解説）

ここからは、公開情報から読み取れる設計上のポイントを Links-Create の視点で解説します。以下は独自分析であり、〈みずほ〉・Anthropic・AWS の公式見解ではありません。

1. 「AI 基盤」と「業務ノウハウ」を別の層に置いている

二層のハーネスの要点は、入れ替わるもの（AI モデルやエージェント技術）と、残したいもの（業務手順・判断基準・社内ルール）を分けて置いていることです。AI の技術は短い周期で変わります。業務ノウハウを基盤の中に埋め込んでしまうと、基盤を替えるたびに作り直しが必要になります。Skills として別に書いておけば、基盤を新しくしても業務ノウハウを持ち越しやすい、という設計だと読めます。

2. 「1 つの汎用エージェント＋Skills」と「個別開発のエージェント」を使い分けている

公式リリースは、一つの汎用型 AI エージェントに Skills を追加してさまざまな業務に対応しつつ、ユースケースに応じて個別に開発する AI エージェントとも使い分けるとしています。Links-Create の整理では、次のような使い分けの考え方になります。

方式	向いている業務（Links-Create の整理）
汎用エージェント＋Skills	手順は部門ごとに違うが、作業の型（調べる・まとめる・書く）は共通している業務
個別開発のエージェント	決まった入力・出力で大量に繰り返す業務、特定システムとの連携が深い業務

これは解釈であり、〈みずほ〉がこの基準で使い分けていると公表されたものではありません。

3. 統制を「人ごと・処理ごと」の単位で効かせている

自律型 AI エージェントは、ファイルやツールを自ら操作し、複数の処理を続けて行います。公式リリースの構成を「何を、どの単位で区切っているか」で並べると次のようになります（Links-Create の整理）。

区切り	公式リリースの記載	設計の意味（解釈）
場所	〈みずほ〉が管理する AWS 上で作業を完結	社員の端末やローカルデータに AI を直接触れさせない
人	利用者ごとに実行環境と作業領域を分離	ある社員の作業内容が、別の社員の AI に混ざらない
時間	利用状況に応じて実行環境を起動・破棄	使い終わった環境を残さない
入出力	ガードレールによる統制、ログ記録、運用監視	何を入れ、何を出したかを後から確かめられる

4. 「人への確認・承認」はこれからの課題として明記されている

今後の展望に、AI が必要なタイミングで適切な人に確認や承認を求めながら業務を進める UX をめざすとあります。言い換えると、どの場面で人に確認するかの設計は、PoC の先で詰める課題として位置づけられていると読めます。AI エージェントの導入では、作業を任せる範囲と同じくらい、止まって人に聞く場面の設計が重要です。

5. 既存の事例との違い

事例	論点	本事例との違い
野村総合研究所の業界特化型 LLM	金融業務に特化したモデルの精度	モデルの精度が論点。本事例は、汎用モデルに業務ノウハウを外付けし、実行環境で統制する設計が論点
ネットワンシステムズ「NetOne Claw」	社員の PC 上で動く社内 AI エージェントの権限を操作ごとに限定	端末側で動かし操作を絞る設計。本事例は、実行環境ごとクラウドに移して人ごとに分ける設計

自社に置き換える演習（Links-Create の研修用の提案）

以下の演習と表の例は、Links-Create が研修用に提案するものです。〈みずほ〉が実施した手順や事実ではありません。 表の「例」は考え方を示す架空の例なので、自社の業務に置き換えて記入してください。

演習 1: 業務手順を「AI 基盤とは別の文書」として書き出す

任せたい業務を 1 つ選び、次の 4 項目を書き出します。

項目	書く内容	例（研修用の例）
目的	何のための作業か	月次の問い合わせ傾向を報告する
手順	作業の順番	集計 → 分類 → 上位 5 件の要約
判断基準	迷ったときの決め方	件数が同じなら新しい分類を優先
やってはいけないこと	禁止事項	個人名を報告書に載せない

この 4 項目が文章になっていれば、AI 基盤を替えても持ち越せる「業務ノウハウ」になります。Skills の書き方は Claude Code Skills とは・使い方・作り方 を参照してください。

演習 2: AI に触れさせる範囲を「場所・人・時間」で区切る

区切り	決めること	例（研修用の例）
場所	AI が作業する場所	共有ドライブの専用フォルダだけ
人	誰の権限で動くか	依頼した本人の権限を超えない
時間	作業環境をいつ消すか	依頼が終わったら作業ファイルを削除

演習 3: 「止まって人に聞く場面」を先に決める

場面	理由	確認する相手（例）
社外に出る文書を作ったとき	誤りがそのまま外に出る	依頼した本人
判断基準に当てはまらないケース	AI が独自に決めてしまう	業務の担当者
削除・送信など取り消しにくい操作	元に戻せない	上長

法人 AI 研修への示唆（Links-Create の視点）

1. 業務手順を書く研修を、AI ツールの操作研修より先に行う — 手順・判断基準・禁止事項が文章になっていないと、AI に任せる範囲を決められない
2. 統制は「禁止」だけでなく「区切り」で考える — 場所・人・時間で区切ると、任せられる範囲を広げやすい
3. PoC の段階を正しく伝える — 社内外への説明では「検証を始めた」と「効果が出た」を混同しない

関連リソース

• 生成 AI（Claude Code）を実務で使う実装演習 — 生成 AI で何ができるかを体験する無料コース
• Claude Agent SDK 入門 — AI エージェントを業務システムに組み込む実装ガイド
• Claude Code Skills とは・使い方・作り方 — SKILL.md で専門手順を覚えさせる方法
• AI エージェント入門ガイド — AI エージェントの仕組みと、チャットボットとの違い
• 野村総合研究所の業界特化型 LLM（AI活用事例） — 国内金融の生成 AI 活用事例
• ネットワンシステムズ「NetOne Claw」（AI活用事例） — 社内 AI エージェントの権限設計の事例

出典・引用ポリシー

本記事の事実情報は、次の公式発表のみを一次ソースとしています。

• 株式会社みずほフィナンシャルグループ プレスリリース『生成AIとの「対話」からAIに「業務を任せる」働き方へ－自律型AIエージェント基盤「みずほCowork」を開発し、業務適用に向けたPoCを開始』（2026-10-05、PR TIMES 掲載）

設計の読み解き・演習・研修への示唆は Links-Create の独自分析・研修用の提案であり、〈みずほ〉・Anthropic・AWS の公式見解ではなく、〈みずほ〉が実施した事実でもありません。

本事例は PoC の開始段階であり、定量的な効果は公表されていません。報道で紹介された導入人数や個別の業務例のうち、公式リリースで確認できないものは記載していません。社内提案で引用する際は、段階（PoC）を必ず併記してください。

公式情報の更新があれば、本記事も追従して更新します。