Bet AI Day 2026丨AIによって本質に戻るシステムリスク管理

2026年9月3日に開催されたイベント「Bet AI Day 2026」における登壇資料です。

■ 概要
AIの進化によって、脆弱性の発見や攻撃経路の探索はこれまで以上に高速化・自動化されることは避けられないでしょう。一方で、多くの企業のセキュリティ運用は、脆弱性管理、資産管理、SBOM、脅威管理、ペネトレーションテスト、といった領域ごとに分断され、最終的なリスク判断は依然として人手と巨大な台帳に依存しています。

しかし、台帳管理は、企業が本当に向き合うべき「システムを通じてどのようなリスクを取り、どのようなアップサイドを狙うのか」という目的に対する手段です。ある脆弱性が、どの資産に存在し、どの権限や接続関係と結びつき、悪用された場合にどの業務や情報資産へ影響するのか。そこまで捉えなければ、対応の優先順位は決められません。

本講演では、AI時代におけるシステムリスク管理のあり方を、攻撃グラフ、継続的な資産把握、AIエージェントによる探索・検証といった観点から整理します。従来分断されてきた脆弱性診断、ペネトレーションテスト、脅威モデリング、資産管理を、継続的に更新される「システムリスクグラフ」として再統合する構想と、現時点での取組についてお話しします。

CVEリストを待って対応するセキュリティに加え、自分たちのシステムを常時探索し、攻撃経路と業務影響にもとづいて判断するリスク管理へ。Fintech事業部が目指す、AI時代のシステムリスク管理の現在地と今後の展望を紹介します。

■ 登壇者情報
Fintech事業 CISO 鈴木 研吾
X: https://x.com/ken5scal

カリフォルニア大学バークレー校大学院修了。証券会社向けのManaged Security Serviceに従事。その後、Fintech系スタートアップにてMobileアプリ開発、社内システム、サービス環境インフラをセキュリティの観点から担当。ゼロトラストネットワークの国内第一人者。他に、セキュリティキャンプ全国大会の講師やセキュリティ系同人誌「Secure旅団」の主催など広く活動している。

■ 関連リンク
・イベント特設サイト： https://layerx.co.jp/events/2026/bet-ai-day/
・コーポレートサイト： https://layerx.co.jp/
・X Tech 公式アカウント：https://x.com/LayerX_tech

#BetAIDay

Transcript

1. Bet AI Day 2026 AI Agents at Work Fintech / Security AIによって本質に戻る システムリスク管理 鈴木 研吾 Kengo Suzuki 16:20-16:40
2. Speaker Information 鈴⽊ 研吾 Kengo Suzuki カリフォルニア⼤学バークレー校⼤学院修了。 証券会社向けのManaged Security Serviceに従事。 その後、Fintech系スタートアップにて Mobileアプリ開発、社内システム、サービス環境インフラを セキュリティの観点から担当。 ゼロトラストネットワークの国内第⼀⼈者。 他に、セキュリティキャンプ全国⼤会の講師や セキュリティ系同⼈誌「Secure旅団」の主催など広く活動している。 LayerX Fintech事業部では主にシステムリスク管理を担当 194
3. Agenda Chapter 1 AIエージェント活⽤に伴うシステムリスク現状 Chapter 2 AIエージェントの作⽤可能範囲を制御する Chapter 3 ゼロトラストを基にしたシステムリスク管理
4. AIエージェントへの委任範囲 リスクのスケール x 新規技術による継続的且つ 急速な変化 - そもそもシステムリスク管理はシステム化に伴うアップサイド とダウンサイドの最適化にある - AIエージェントは業務の恩恵を拡⼤する⼀⽅、誤作動‧逸脱‧ 侵害時のリスクと影響範囲も拡⼤する - 特に昨今では、「⾃社システムから外部へ及ぼす作⽤ （Outbound Risk）」による第三者環境への侵害や、 実世界への⾮許可⾏動が顕在化している - モデルへの指⽰やエージェント内部の制御だけでなく、権限‧ 到達範囲‧実⾏環境を、外側から制約する仕組みが必要 - エージェントの開発‧運⽤する主体とは別のレイヤーで、その 境界を設計‧強制する。これは既存のフレームワークを拡張 し、統合したほうがいい https://www.smtam.jp/guide/management/risk/ 196
5. Chapter 1 AIエージェント活⽤に伴う システムリスク現状
6. AIの業務利⽤‧攻撃利⽤‧事故は、すでに数字に表れている 81% 組織がManaged AI Servicesを利⽤（Wiz 2026）。AIはクラウド‧開発‧業務 ワークフローに組み込まれ、周辺システムの⼀部になっている。 57% 組織がSelf-hosted AI Agentsを展開（Wiz 2026）。AIツールやAI開発基盤 そのものも攻撃対象になり、業務利⽤時の事故‧悪⽤も観測されている。 89% AI-enabled adversaryの攻撃増加（CrowdStrike 2026）。攻撃側でも 偵察‧認証情報窃取‧回避‧ソーシャルエンジニアリングにAIが使われている。 8× Critical‧Highな脆弱性が、303 -> 2514に（Epoc AI）。 29min / 4× 平均eCrime breakout time 29分（CrowdStrike 2026）。最速攻撃の初期 アクセスから窃取までは前年⽐4x（Unit 42 2026）。AIは攻撃速度‧攻撃 ⾯‧事故の影響範囲も変える。
7. 外部からAIエージェントを活⽤した「速く‧広く‧巧妙」なリスク InboundなRiskに関する変遷 時間軸 発⾒から悪⽤までが短縮。 平均eCrime breakout timeは29分、最速27秒という観測が出ている。 探索範囲 管理画⾯ / API / SaaS / ID / 依存関係まで拡⼤。 AIにより偵察‧探索‧スクリプト作成‧トラブルシュートが簡易になる。 攻撃の質 相⼿に合わせた誘導‧⽂⾯⽣成‧迂回⼿段が増える。フィッシング、ソーシャル エンジニアリング、偽装、認証情報窃取がAIで最適化される。 対象拡⼤ AIシステム⾃体も攻撃対象となり、プロンプト注⼊やAI開発基盤の悪⽤が観測 されている。Inboundでは、時間軸‧カバレッジ‧巧妙さが同時に変化する。
8. Outbound Risk：AIエージェントが第三者に害を与えるリスク 指⽰者の意図しない形で、明らかな第三者に対する侵害⾏為を実⾏する恐れがある。 法的責任の所在は未確定でも、外部へ被害を出すというマイナスのアウトカムは同じ。 ⾃社側の⾒え⽅ 第三者側の⾒え⽅ 業務⾃動化の失敗 評価タスクの逸脱 AIエージェントの作業 ミス 不正アクセス 悪性PR / フィッシング データ窃取‧破壊の試 ⾏ 故意であろうとなかろうと、 正常に動く⾃社システムが 加害主体になり得る可能性が 増した 200
9. Outbound事例①：UK / AISI事例 サンドボックス 回避ではなく、 評価⽬的で許可されたインターネットアクセスを経由して 第三者への作⽤に使われた • 122回の評価のうち10回で、 合計19件の実世界への⾮許可⾏動を確認 • 実在OSSへ悪性コードを含むPRを作成 • 偽アカウントを作成し、 メンテナへのsocial engineeringを試⾏ • プロンプトインジェクションの埋め込みや、 他エージェントとの協働を⽰唆する⾏動も観測 •（個⼈的な感想）プロンプトがそもそもアグレッシブ な状態でインターネットアクセス 許可されたInternet access ↓ Malicious PR ↓ Fake Identity ↓ Social Engineering ↓ Human / Other Agents アプリ‧インフラともに⼗分な管理が必要 出典：OpenAI / Hugging Face incident reports（2026） 201
10. Outbound事例②：OpenAI / Hugging Faceのケース 「⽬標達成のための経路探索」による 評価環境の脱獄 •エージェントは外部へのアクセスが本来のスコープと異なる ことをしりながら、 評価⽬標の達成に向け、様々な侵⼊⼿法 でHugging Face本番環境まで到達 •エージェントは「チート⾏為」を認識しつつ、システムログ の削除も試みていた •本番環境で使われているセーフガードやシステムプロンプ ト、⾃動レビュー機能などがオフにされた状態 •セキュリティ監視システムは、評価環境における異常なAPI 呼び出しや権限昇格を検知していた 構成 評価環境 直接Internetなし ↓ Artifactory 0-day ────────────── 実際の経路 Internet到達可能なNode ↓ Hugging Face Production 開発環境‧本番環境で同⼀のポリシーと、濃淡のあるEnforcement（施⾏）の分離 出典：OpenAI / Hugging Face incident reports（2026） 202
11. Outbound事例③：Meta社 AIサポートに指⽰することでアカウント乗っ取り • AIサポートチャットに、被害者アカウントのパスワードリセットリンクを 攻撃者のメアドに送るよう指⽰ • 20,225アカウントが影響を受けた • ２要素認証済みのアカウントはパスワードリセットはされたものの、乗っ取られず 多層防御の徹底 出典：OpenAI / Hugging Face incident reports（2026） 203
12. エージェントの確率的挙動に対応するための管理が必要 3つの事例が⽰すのは、エージェント内部の指⽰だけでは「作⽤可能範囲」を境界として 強制できないということ UK AISI ラフなプロンプトでラフな経路 によってエージェントが 第三者へ作⽤ OpenAI / Hugging Face Meta エージェントが脆弱性と接続関係を 探索し、到達範囲を⾃ら拡張し、侵害 脆弱なアプリとしてのエー ジェントを悪⽤され、利⽤者 のアカウントを第三者に譲渡 エージェント内部の制御は、望ましい⾏動の確率を⾼める。 しかし、想定外⾏動時の被害上限は、 エージェントの運⽤管理から独⽴した⽅法で境界を引く必要がある ⼗分な管理ポリシーと、⽬的に応じた適⽤（エンフォース）、これらの多層的な運⽤管理の独⽴が必要 Identity / IAM / Sandbox / Network‧DNS / Egress / Secrets / Monitoring‧Containment 204
13. Question では、AIエージェントの何を、 誰が、どこで制御するのか？
14. Chapter 2 AIエージェントの 作⽤可能範囲を制御する
15. システムに対するInboundリスク評価 そこそこガイドライン化が進んできている Asset Exposure KEV Status Exploit Automation Technical Impact 外部から到達可能か。 CISA BOD 26-04は、 CVSSのSeverityだけ でなく、資産‧露出‧ 悪⽤状況‧⾃動化可能 性‧影響で優先順 付 けする⽅向を⽰す。 既知悪⽤か。脆弱性単 体ではなく、その脆弱 性がどの資産にあり、 どこから到達可能で、 何を可能にするかを⾒ る。 ⾃動悪⽤可能か。AI エージェント時代に は、この⽂脈評価を資 産‧権限‧到達可能性 ‧業務影響‧Agentの 活動範囲まで拡張す る。 完全制御へ⾄るか。脆 弱性情報を待つだけで なく、⾃社の接続関係 ‧業務影響で判断す る。ここから先は、分 断されたデータをシス テムリスク判断へ統合 する話になる。 しかしシステムリスク管理にはOutboundなリスクも 含めて、対処する必要がある 207
16. AIエージェントに作⽤する変数を、4つの観点で分解 全体のシステムリスクを、AIエージェント特有の性質と、従来のシステム上で制御できる性質に分けて整 理し、組織構成、業界標準、ソリューションを踏まえ、TO BEとTODOを洗い出し、対処する必要がある ど 資源にど Actionを許すか 主にIdentity / IAM / Delegationで制御 (Identity) 何を理解・生成・実行できるか 主にモデル・ツール選定で制御 (Capability) AIエージェント （外的環境に 作用を及ぼす主体） 人を介さず何分・何回・何ステップ動くか 主にタスク設計・実行時間で制御 (Autonomy) ど Network / DNS / Data / Toolへ到達できるか 主に実行環境で制御 (Reachability / Sandbox) ※括弧内 個人的な仮称 208
17. 誰が何を制御するか？ 全体のシステムリスクを、AIエージェント特有の性質と、従来のシステム上で制御できる性質に分けて整 理し、組織構成、業界標準、ソリューションを踏まえ、TO BEとTODOを洗い出し、対処する必要がある ど 資源にど Actionを許すか 主にIdentity / IAM / Delegationで制御 (Identity) 何を理解・生成・実行できるか 主にモデル・ツール選定で制御 (Capability) 各開発部署・プロジェクト・ チームが判断することになりそ うだが、ど ような制御が必要 かガイドライン化が必要 人を介さず何分・何回・何ステップ動くか 主にタスク設計・実行時間で制御 (Autonomy) AIエージェント （外的環境に 分離 作用を及ぼす主体） Fintech事業部だと、担当部署・ チーム 一部署に絞られていて、明 確 ど Network / DNS / Data / Toolへ到達できるか 主に実行環境で制御 (Reachability / Sandbox) ※括弧内 個人的な仮称 209
18. 誰が何を制御するか？ 全体のシステムリスクを、AIエージェント特有の性質と、従来のシステム上で制御できる性質に分けて整 理し、組織構成、業界標準、ソリューションを踏まえ、TO BEとTODOを洗い出し、対処する必要がある 横断チームが 続々とでてくる新標準・規格 確認と反映？ そ 標準をど 程度、反映する？ 各チームと 合意 ？ AIエージェント ど 資源にど Actionを許すか 主にIdentity / IAM / Delegationで制御 (Identity) （外的環境に 作用を及ぼす主体） 横断チーム？が ど ポリシーを、ど 環境で、ど 程度、 強制・Enforceする か、そ granular な制御を可 能とする仕組み 構築、 現状から劣後しないため 移行計画、 現状 ソリューション 仕様確認 各チームと 合意 ？ ど Network / DNS / Data / Toolへ到達できるか 主に実行環境で制御 (Reachability / Sandbox) ※括弧内 個人的な仮称 210
19. 全体的なシステムリスクにあたってはまだまだ不⾜ • 新しい⽤語は増えるが、責任主体と強制点が曖昧 • Outboundなリスクや、そのリスクにつながるような 侵⼊‧内部不正を前提にした標準整備はどの組織もこれから • ハーネスエンジニアリングについてAI開発周辺ではある程度、統⼀がされてきているように⾒えるが、 対処可能なリスクとのマッピング、標準業界に合わせた定義、役割分担、耐⽤年数も未知数 • 規制‧監督側は追いついていない • （個⼈的にも）追いつけてると⾃信をもって⾔えない • 既存組織への当てはめ、既定とされる業界標準への統合も未整備な状態 AIエージェント先駆者界隈の提唱内容と、既存概念と既存組織のすり合わせが必要 211
20. 個別に語られる対策を、 既存のフレームワークを拡張し 統合する
21. Chapter 3 ⼈も、端末も、AIも。 そもそも信頼しないのが システムリスク管理
22. Zero Trust: Don’t Trust Verify 「外部/内部を問わず脅威が存在するといった前提に⽴ち、ユーザー、デバイスなど個々のID（Digital Identity）に焦点を当て、「都度必要なアクションに対して必要なレベルの認証を⾏い、問題なければ適切な アクセス権を認可する」といった検証を厳密に⾏うことで、 セキュリティを担保し、且つ柔軟なUser Experienceを実現するといった概念」by デジタル庁 ※disclaimer: 私⾃⾝が作成に関わっています ユーザーID管理 ディレクトリサービス 常時リスク診断情報 資産インベントリ 観測情報 アクセス制御 管理機能 端末構成情報 PKI アクセス制御結果 適用 脅威情報 アクセス制御ポリシー デジタル化した業務プロセス 主体 アクセス 制御 施行 リソース A アクセス 制御 施行 リソース B アクセス 制御 施行 リソース Y アクセス 制御 施行 リソース Z ・・・ https://www.digital.go.jp/resources/standard_guidelines/#ds210 214
23. AIエージェントとZero Trustとは 権限管理や実⾏環境制限を個別対策で終わらせず、 Access / Actionの判断に必要なシグナルとして統合する。 従来 User × Device × Resource AI Agent時代 User / Service × Agent × Tool × Resource × Reachability Don’t Trust, Always Verify の対象を拡張するだけ 215
24. 今後のZeroTrust - 主体編 主体 ユーザー アクセス 制御 施行 サービス リソース AIエージェント リソース デバイス Delegation (on behalf of) ユーザー デバイス サービス
25. 今後のZeroTrust - アクセス制御の判断編 AIエージェント ディレクトリサービス 追加 ユーザーID管理 ディレクトリサービス 資産インベントリ 端末構成情報 MCPサーバー等エージェントに必 要なリソース 追加 アクセス制御 管理機能 常時リスク診断情報 観測情報 PKI 脅威情報 アクセス制御ポリシー ・・・ アクセスコンテクストに合わせた 静的、動的、又 そ 組み合わせによる Policy Decisionと 環境・リスクに合わせたEnforcement On Behalf Of時 AIエージェント 活動記録 追加 コンテクスト情報 追加 217
26. まとめ：AIによって、システムリスク管理は本質に戻る • AIエージェントには仕事を任せる。 • ただし、その作⽤可能範囲の決定までは任せない。 • AIエージェントを「Never Trust, Always Verify」 • Agentを独⽴したPrincipalとして扱い、権限と到達範囲をAction単 で制御し、 Agent外部の境界で強制する。 • AIエージェントのハーネスエンジニアリングのエッセンスは、すでにZeroTrustにある • これをもってシステムリスク管理の⽅針をすすめていく 218
27. Answer 任せるのは業務。 任せないのは境界。