男（監査）はつらいよ - Policy as CodeからAIエージェントへ

Transcript

1. 商号等 三井物産デジタル‧アセットマネジメント株式会社 ⾦融商品取引業者 関東財務局⻑（⾦商）第3277号 加⼊協会 ⽇本証券業協会、⼀般社団法⼈ ⽇本投資顧問業協会、⼀般社団法⼈ 第⼆種⾦融商品取引業協会 ©Mitsui & Co. Digital Asset Management, Ltd. 男（監査）はつらいよ Policy as Codeからエージェントを優先させた話 @ken5scal ʢླ໦ݚޗʣ
2. ⽬次 INDEX 01 背景 02 疑問：Policy as Code、本当に必要？ 03 試したこと：ローカルで数カ⽉、地道に監査 04 気づき：これ、エージェントでいいじゃん 05 作っているもの：Google Drive 監視エージェント on AWS 06 まとめ：Policy as Code ＋ Agent の形
4. 01 背景 4
6. 6 これらに対する統制・モニタリングを横断的にやってます
7. 監査って⼤事？⾯倒くさい？ 背景 7 ‧大事 ‧内部・外部 監査問わず、あるべき論から自組織を見直す機会 ‧法令や規程の遵守状況 <- ガバナンス状態の形骸化を防ぐ ‧健康診断みたいなもん ‧とはいえ面倒くさい ‧対象のデータを収集するのが面倒くさい ‧集計が面倒くさい ‧集計結果の分析が面倒くさい ‧分析結果の結論や追加調査が面倒くさい ‧証跡管理が面倒くさい ‧実施する際は強制的にコンテクストスイッチが発生するので面倒くさい ‧そもそもルール作成が面倒くさい
8. 背景 羅針盤とは？ 8 ‧「羅針盤」は、迷ったときに⽴ち返る“⽅針‧優先順 位の基準（北極星）”をまとめた資料‧考え⽅‧⾏動⽅ 針 ‧当部の羅針盤その中で定義された将来像が２つ 1. データ主導の説明可能な意思決定⽂化 2. アジャイルかつRobustなガバナンスモニタリング
9. 背景 羅針盤に基づいた実⾏計画 2025年度 実⾏計画 ‧ベースラインのPolicy as Codeの定義 ‧AIエージェントを活⽤した監査⾃動化のPoC ⽅針指針 ‧SRE‧DevOps‧セキュリティのベースライ ン要求を統合し、運⽤ルール（Policy as Code など）化 ‧AI/機械学習エージェントを活⽤し、ログ監 査や違反検知を⾃動化 9
10. 背景 Policy as Code、本当に正しいアプローチか？ ▪OPA（Open Policy Agent）などのツールで、ルールをコードに落とし込みバージョン管理する ネックは実現性と持続可能性 ‧ルールが変わるたびにコードを書き直すのか？ ‧例外や曖昧な判断をどうコードに落とすのか？ ‧グレーゾーンをどう扱う？ ⽩か黒かで割り切れないケースが多い ‧上記もコードで書くのか？ ‧正しくコードをメンテできるのか？ ‧AIの賢さを信じてもいいんじゃね？ ‧AI使ったOPAでログ解析させるなら、AIに作成させたクエリで集計して、解析しても同じじゃない? （暴論 →「AIでまずは試すことにした」 10
11. 試したこと ファースト‧ステップ：ローカルで数カ⽉、地道に監査 やったこと ‧正規化したログ（左図）のローカルを対象に 以下の並列実⾏ 1. ⾃作DuckDBクエリによる⾃前監査 2. AI監査 ‧Claude Skillsでの集計 ‧SkillsではMotherDuck MCPでクエリと集計を Tools call ‧Rulesで分析 と 報告内容を指定 ‧集計のクエリ、集計結果はしっかり保存し、報 告時にはどのそれらのパスを指定 11
12. 試したこと ファースト‧ステップ：ローカルで数カ⽉、地道に監査 気づいたこと ‧思ったより結論が同じになる ‧複数システムに対する複数観点での監査で、 チューニングしなくても同じ結果になるので悪 くない ‧⼀部は⼈間より「Helpfulness」の⾼い報告 もしてくれる ‧過去の膨⼤なログもインサイトにいれてくれ る 12
13. 気づき これ、エージェントでいけるやん LLMベースのエージェントなら... ✓グレーな判断も「⾼リスク‧中リスク‧低リスク」でサジェストできる ✓過去のHITLでの判断も反映‧バージョン管理 ✓前⽉との差分を⾃動で拾い、⽂脈ごと説明⽂にまとめられる ✓ルール変更はプロンプト修正で対応できる（コード改修より速い） ✓証跡（集計結果‧判断根拠）をS3に⾃動保存できる Policy as Codeで「判断をコードに閉じ込める」より、エージェントに「スキーマと⽬的をもとにし たクエリ整形と⾃然⾔語による判断をもって、⼀次ドラフトを作成させて⼈間が最終確認する」して も問題ない事に気づいた 13
14. 02 作っている例：Google Drive アクセス監視 エージェント on AWS 14
15. 作っているもの アクセス監視エージェント 何をするか ‧Google Drive の外部ドメイン‧ユーザーア クセスを週次で⾃動分析 ‧新規ドメインの出現‧消失を差分検知 ‧機密性の⾼いフォルダへのアクセスチェッ ク ‧SlackにLLM⽣成のサマリーレポートを通知 ‧分析結果と証跡（JSON/Markdown）をS3 に保存 15
16. 作っているもの 技術構成：2つのRuntimeがMCPで連携 Runtime 1 — Go Agent ‧AgentCore Runtimeで実⾏ ‧GitHub Actionsによってキック ‧MCPの呼び出し ‧LLMによる分析‧レポート⽣成 ‧Amazon Bedrock / Claude ‧Slack通知、S3へのレポート保存 Runtime 2 — DuckDB MCP サーバーServer ‧AgentCore Runtimeで実⾏ ‧DuckDBでS3 Tables上のログをSQL集計 ‧集計結果のS3保存 ‧差分検出（NEW / REMOVED / EXISTING） 16
17. 作っているもの 技術構成：2つのRuntimeがMCPで連携 Runtime 1 — Go Agent ‧AgentCore Runtimeで実⾏ ‧GitHub Actionsによってキック ‧MCPの呼び出し ‧LLMによる分析‧レポート⽣成 ‧Amazon Bedrock / Claude ‧Slack通知、S3へのレポート保存 Runtime 2 — DuckDB MCP サーバーServer ‧AgentCore Runtimeで実⾏ ‧DuckDBでS3 Tables上のログをSQL集計 ‧集計結果のS3保存 ‧差分検出（NEW / REMOVED / EXISTING） 17 Context Engineeringは現時点では ガン無視。今後の課題
18. 作っているもの 今後の課題 ‧依頼チケットとの紐づけ ‧変更内容承認フローとの紐づけ ‧⽣成されたクエリのバージョン管理 ‧コンテクストエンジニアリング ‧パフォーマンス‧チューニング ‧承認フローなどのルールの作成 （⼀番だるい） ‧当⾯、職に困らなささそう ‧当⾯、めんどくさいは解消されなさそう 18
19. 03 まとめ：ポリシーの運⽤の変え⽅ 19
20. まとめ Policy as Code ＋ Agent = より現実的なガバナンスの形 従来のアプローチ vs エージェントを使ったアプローチ ‧ルールをコードで厳密に定義 → ルールの意図をプロンプトで伝え、LLMが補助判断 ‧例外は⼈間が⼿動対応 → グレーゾーンも Severity 付きでサジェスト ‧監査は⼿動‧属⼈化 → 週次で⾃動実⾏、証跡はS3に残る ‧変更コスト：コード修正＋テスト → プロンプト修正（＋必要に応じてコード） Policy as Codeは廃⽌したわけではない ‧コードで決定論的に制御すべき部分（IAM権限‧Terraform構成管理など）は引き続き有効 ‧エージェントは「判断が複雑でグレーな領域」をカバーする補完的な役割 ‧ただし,OPAを使うかは微妙。 ‧⽣成されたDuckDBクエリをどうバージョン管理化するかが課題 じゃないか、と思っている → Policy as Code ＋ Agent = より現実的なガバナンスの形 20
21. 21 最後に 他にもこんな活動してます
22. コーポレートサイト https://corp.mitsui-x.com/ サービスサイト（ALTERNA） https://alterna-z.com/