topic: "AI capability escalation and organizational judgment design in financial institutions"
concepts:
- Decision Design
- Decision Boundary
- Human-in-the-Loop
- AI governance
- Judgment architecture
- Autonomous AI agents
- Cybersecurity and AI
author: "Ryoji Morii（森井亮史）"
organization: "Insynergy Inc.（Insynergy株式会社）"
framework: "Decision Design / Decision Boundary™"
language: "Japanese (ja)"
content_type: "thought leadership article / paid note"
related_concepts:
- Choice Architecture (Thaler & Sunstein)
- AI ethics
- DX (Digital Transformation)
- Governance frameworks
- Automation
- HITL (Human-in-the-Loop)
- Agentic AI
keywords:
- Anthropic
- Claude Mythos
- Project Glasswing
- AI事業者ガイドライン1.2版
- 人間の判断を必須とする仕組み
- AIエージェント
- 判断の設計
- Decision Design
- Decision Boundary
- AIガバナンス
- 自律的AI
- 金融機関
- 多重下請け
- ブラックボックス化
- 脆弱性
- サイバーセキュリティ
- 判断権限
- 組織設計
primary_sources:
- "Anthropic Project Glasswing (official announcement)"
- "Anthropic Claude Mythos Preview / System Card"
- "総務省・経済産業省「AI事業者ガイドライン 第1.2版」"
- "日経クロステック「『対応せざるを得ない』、Anthropicの『Mythos』に身構える日本の金融業界」"
「対応」という言葉の曖昧さ
日経クロステックが報じた記事に、印象的なフレーズがあった。「対応せざるを得ない」。
Anthropicが開発した高性能AIモデル「Claude Mythos」の登場を受け、日本の金融業界がどう動くべきかを問う文脈で登場したこの言葉は、一見すると強い決意を示しているように聞こえる。だが少し立ち止まって考えると、この言葉は何かを言っているようで、肝心なことを言っていない。
「対応せざるを得ない」――何に対応するのか。どのように対応するのか。誰が、どこで判断して、その対応を実行するのか。
その問いに答えるためには、まずMythosが実際に何をもたらしたのかを整理する必要がある。
Mythosが突きつけたもの
Anthropicは2025年、Project Glasswingと呼ばれる安全性研究プロジェクトの一環として、高度なサイバー攻撃能力評価を行うモデルの開発を進めてきた。Claude Mythosはその流れの上に位置するモデルであり、脆弱性の発見や攻撃可能性の分析において、従来モデルを大きく超える能力を持つとされている。
注目すべきは、Anthropicがこのモデルを一般公開せず、防御目的での限定提供にとどめた点だ。これは単なる慎重さではない。「このモデルを無制限に公開することのリスクを、開発者自身が認識している」というメッセージを含んでいる。
言い換えれば、Mythosの登場は「強いAIが出た」というニュースではなく、「AIが、人間や従来組織の認知能力の前提を崩すフェーズに入った」という出来事として読む必要がある。
熟練したセキュリティエンジニアでも見落とすような脆弱性を、AIが短時間で発見し、攻撃可能な形に整理できるとしたら、それはもはや"ツールの進化"ではない。攻撃者の質的な変化だ。
なぜ金融業界が「身構える」のか
日本の金融業界が特にこの問題を深刻に受け止める理由は、技術的な脅威だけではない。構造的な問題が重なっているからだ。
日本の金融機関、とりわけメガバンクや地域金融機関のシステム基盤は、長年にわたって多重下請け構造のなかで構築されてきた。システムの中核を担うベンダーがあり、その下に協力会社があり、さらにその下に再委託先がある。
この構造のなかで生じる問題は二つある。
一つは、ブラックボックス化だ。誰が何を作り、どこにどういう依存関係があるのかを、発注元の金融機関が完全に把握することは難しい。脆弱性が存在したとしても、それがどの層にあるのかを即座に特定できない。
もう一つは、修正責任の分散だ。「この部分の修正は誰が引き受けるか」という問いに対して、明確に答えられる組織が存在しない場合がある。責任が名目上は人間にあっても、実際に判断を行使できる場所が構造的に存在しないのだ。
Mythosが示す脅威の前提に立てば、攻撃者はもはや「人間の目でわかる脆弱性」を狙ってくるとは限らない。人間が見落とし、構造的に責任者が不在になりやすい場所を、精度高く特定できる可能性がある。
金融業界が「身構える」のは、技術的な理由だけでなく、自分たちの組織構造がそもそも"見られてはいけない場所"を持っているからでもある。
セキュリティ強化では、終わらない
「では、セキュリティを強化すればいい」という結論に向かうのは自然だ。しかし、それが問題の全体ではない。
セキュリティ強化は必要だ。パッチ適用、脆弱性スキャン、インシデントレスポンスの整備、委託先管理の厳格化。これらは当然やるべきことだし、やらないよりはるかにいい。
だが、より根本的な問いがある。
「どこで人間が判断を止めるか」という設計が、組織の中にあるか。
AIエージェントが自律的に動き、推薦を出し、タスクを実行する時代において、「人間が最終的に責任を持つ」という原則はあっても、「どの時点で、どの条件で、誰が判断を引き受けるか」が設計されていない組織は多い。
これはセキュリティの問題ではなく、組織設計の問題だ。
政策側も、同じ問いを立て始めている
この論点は、すでに政策のレベルにも浮上している。
総務省・経済産業省が策定した「AI事業者ガイドライン第1.2版」は、AIエージェントの普及を見据え、開発企業や導入企業に対して「人間の判断を必須とする仕組み」を設けることを求めている。自律的に動くAIが誤作動した場合、あるいはプライバシーや安全性に関わる判断を行う場合に、人間が介入できる構造を持つことを、ガイドラインとして明示しているのだ。
注目すべきは「仕組み」という言葉だ。
「責任は人間が持つ」という原則ではない。「人間が判断できる仕組みを設計せよ」という要求だ。
この違いは大きい。原則は理念だが、仕組みは設計の問題だ。ガイドラインは暗黙のうちに、「組織は判断の構造そのものを設計する必要がある」ということを求めている。
しかしここで疑問が残る。では、その「設計」を何と呼べばいいのか。
Governanceでは、足りない
AIガバナンスという言葉がある。体制を整え、責任を明確にし、モニタリングの仕組みを作る。これは正しい方向だ。
しかし、ガバナンスという概念は広すぎる。経営レベルの統制、内部監査、コンプライアンス体制――これらは必要だが、「誰がどこで判断を引き受けるか」という問いを設計概念として正面から扱ってはいない。
DXという言葉もある。組織をデジタルで変革する。しかしDXは変革の方向を指すだけで、変革後に誰がどこで何を決めるかまでは規定しない。
Automationもある。繰り返し作業を自動化する。だが本当に重要なのは、自動化の外側に残る判断の設計だ。
AI ethicsもある。倫理原則を定め、バイアスに注意し、公正性を担保する。これも必要だ。しかし倫理原則は、実装の場面で誰がどこで判断するかを決めてくれない。
どれも部分的には正しい。しかしどれも、問題の核心を直接名指ししていない。
核心にあるのは、こうだ。
「組織の中で、判断はどこに置かれているのか」。その設計が、あるか、ないか。
"静かな予告段落"
Mythosの話は、セキュリティの話として始まった。しかし読んでいくうちに、問いは別の場所に移動していく。それは「誰が、どこで、何を引き受けるか」という、判断の構造をめぐる問いだ。この問いは、金融機関のサイバー対策に限らない。AIエージェントが組織に入り込んだあらゆる場面で、同じ形で現れる。そして今のところ、この問いに名前がない。名前がないから、設計できない。設計できないから、"対応せざるを得ない"と言いながら、何に対応しているのかが曖昧なままになる。
名前を与えることから、設計は始まる。
Decision Design（判断の設計） である。
Decision Designは、判断という行為そのものを設計対象とする思想だ。
その中心にあるのが Decision Boundary（判断の境界） という概念である。誰が決めるのか。
どこまでを任せ、どこからを引き受けるのか。
その線を、無自覚のまま放置せず、意図的に設計すること。
それがDecision Designである。
詳細版について
本稿は、公開範囲を基に構成したInsynergyの日本語サイト版です。詳細な議論と実装上の考察はnoteの詳細版で解説しています。