メルカリのAI活用を支えるAIセキュリティ

AIセキュリティではAIに特有の対策だけでなく、従来からのセキュリティ対策が依然として有効であり、自律型エージェントの時代にむしろ重要性が増しています。適切なアイデンティティ管理とアクセス制御、最小権限の原則や変更管理が欠ければ、AIのスケールの速さによって脆弱性がすぐに顕在化します。 本講演では、代表的な課題と対処法、そして既存のセキュリティ原則から得られる示唆を議論します。最後に、MercariにおけるAIセキュリティへの取り組みから生産性向上とセキュリティ確保の両立について紹介します。

Transcript

1. 1 メルカリのAI活⽤を⽀えるAIセキュリティ AI Security Conference 株式会社メルカリ Choi Chun Ming
2. 2 ⾃⼰紹介 Choi Chun Ming @s3h_____ 株式会社メルカリ Platform Security Team所属 社内のGitHubおよびCI/CDの セキュリティ改善を⾏っている
3. 3 スマホアプリ「メルカリ」を中⼼に消費者向けサービスを展開 フリマアプリ 「メルカリ」 事業者向けEコマース プラットフォーム 「メルカリShops」 暗号資産取引サービス 「メルコイン」 決済サービス 「メルペイ」 Fintech Marketplace
4. 4 2025年8⽉公開の決算資料にて全社の「AI-Native」化を宣⾔
5. 5 メルカリでのAI活⽤の実態
6. 6 アウトライン I. よくあるAIセキュリティ対策の問題 II. メルカリでのAIプラットフォームの取り組み 1. n8nワークフローの⾃動セキュリティ検査 2. 短期間のLLM API認証情報を提供するLiteLLM基盤 3. Policy BotによるAI Agent時代のソースコード基盤強化 III. セキュアなAIプラットフォームの構築⽅法
7. 7 よくあるAIセキュリティ対策例 • AI利⽤のセキュリティガイドライン • AIソリューションの許可リスト • 利⽤可能なAI機能の制限 • 端末のソフトウェア監視 • CSPMでAIサービス監視
8. 8 AI セキュリティガイドラインの制定 https://careers.mercari.com/mercan/articles/55843/
9. 9 AI セキュリティの従業員教育 https://careers.mercari.com/mercan/articles/55854/
10. 10 AI セキュリティの従業員教育 https://careers.mercari.com/mercan/articles/55854/
11. 11 よくあるAIセキュリティ対策例 • AI利⽤のセキュリティガイドライン • AIソリューションの許可リスト • 利⽤可能なAI機能の制限 • 端末のソフトウェア監視 • CSPMでAIサービス監視 → “制限”ベースのアプローチだけではAI活⽤が遅れる
12. 12 よくあるAIセキュリティ対策例 • AI利⽤のセキュリティガイドライン • AIソリューションの許可リスト • 利⽤可能なAI機能の制限 • 端末のソフトウェア監視 • CSPMでAIサービス監視 → “制限”ベースのアプローチだけではAI活⽤が遅れる AI活⽤に全⼒を出しながら安全さを保つには?
13. 13 AI活⽤の⽀え⽅ AIセキュリティ対策の罠 • ガイドラインを策定 → 遵守状況の検査⼯数の不⾜ • AI Agentごとにレビュー体制 → ⼤量のレビューで疲弊 ⼤規模環境に対する対策の困難さ
14. 14 AI活⽤の⽀え⽅ “⼤規模環境”で 開発に全⼒を出しながら安全さを保つには? → Secure by Defaultな開発者プラットフォーム
15. 15 AI活⽤の⽀え⽅ “⼤規模環境”で AI活⽤に全⼒を出しながら安全さを保つには? → Secure by DefaultなAIプラットフォーム
16. 16 AI活⽤を⽀えるプラットフォーム 社内全体での安全なAI活⽤を⽀えるプラットフォーム → メルカリの⼤規模なAI活⽤を⽀える「⾯」のセキュリティ対策事例 ※ 例であり、そのままの導⼊を推奨するものではありません。 1. n8nワークフローの⾃動セキュリティ検査 2. 短期間のLLM API認証情報を提供するLiteLLM基盤 3. Policy BotによるAI Agent時代のソースコード基盤強化
17. 17 1. n8nとは 様々なSaaS連携が可能な⾃由度の⾼いAIワークフロー
18. 18 1. n8nのセキュリティ課題 様々なSaaS連携が可能な⾃由度の⾼いワークフロー (1) 様々なSaaS連携 = Confused Deputy Problem 権限混同
19. 19 アクセス権なし 
 アクセス権なし 
 1. Confused Deputy Problem 権限混同 DATA
 SYSTEM
 “この変更を行って
 ください。”
 “かしこまりま した。”
 アクセス権 
 アクセス権
 AI Agent
 (またはワークフロー )

20. 20 1. Confused Deputy Problem 権限混同 (例) HRチームが⼈事管理AI Botを展開する場合 AI Botを実⾏できる⼈を制御しない → 別部署から⼈事情報を操作可能に AI Botの返答を誰もが閲覧できるチャットチャンネルに出⼒ → 別部署から⼈事情報を閲覧可能に 連携されるデータを元々扱うことができる範囲でAI Botを展開する必要
21. 21 1. n8nのセキュリティ課題 様々なSaaS連携が可能な⾃由度の⾼いワークフロー (1) 様々なSaaS連携 = Confused Deputy Problem 権限混同 (2) ⾃由度の⾼いワークフロー = Secure by Defaultではない
22. 22 1. Secure by Defaultではないワークフロー 誰でも実⾏できる 誰でも出⼒を閲覧で きる
23. 23 1. n8nのセキュリティ課題 様々なSaaS連携が可能な⾃由度の⾼いワークフロー (1) 様々なSaaS連携 = Confused Deputy Problem 権限混同 (2) ⾃由度の⾼いワークフロー = Secure by Defaultではない Confused Deputy Problemを軽減 + Secure by Defaultな設定を強制
24. 24 1. n8nのセキュリティ課題 ⼀般のアプリケーション開発では... 開発者
 リポジトリ・ 
 デプロイ
 SAST SCA Linter シークレット スキャン セキュアな開発を開発者に任せるのではなく ⾃動チェックによるセキュリティのシフトレフト
25. 25 1. n8nのセキュリティ対策 https://engineering.mercari.com/blog/entry/20251211-580dc508a7/ n8nワークフローの⾃動チェッカー開発
26. 26 1. n8nのセキュリティ対策
27. 27 1. n8nのセキュリティ対策 「安全性」を担保する仕組みを事前に実装 → 新しいサービスでもセキュリティの基礎を担保できる
28. 28 2. 短期間の認証情報を提供するLiteLLM基盤 LLMを利⽤する様々なアプリケーション • Claude Code • Codex • Gemini CLI • OpenCode • OpenCommit • GitHub Actions Workflow • Google Apps Script • 独⾃ツール → LLMモデルへのアクセス権限付与は?
29. 29 2. LLMモデルへのアクセス権限付与 platform.openai.com や platform.claude.com のAPIキー ありがちな管理 1. 管理チーム主導で各ワークスペースを作成 2. ワークスペースの中で予算リミットを付与してAPIキー発⾏ → 退職者の対応は? → 発⾏されたAPIキーはどう使われている? → アクセス権限とAPIキーの棚卸しは? → 予算の粒度が⼤きく使いすぎを防⽌できていない? 参考: [地獄] OpenAI APIが不正使⽤された件 - Qiita
30. 30 2. LLMモデルへのアクセス権限付与 platform.openai.com や platform.claude.com のAPIキー • プラットフォームごとの管理‧棚卸しコスト • 流出APIキーによるEDoSリスク • 発⾏リードタイムの⻑期化によるUX低下 → 短期間の有効期限で棚卸しを実質⾃動化? → 個⼈単位の細かな予算制限? → いつでもすぐに発⾏できるAPIキー?
31. 31 アクセス キー 2. LLMモデルへのアクセス権限付与 クラウドでは... ワークロード 
 サーバー
 OIDC Workload Identity ⻑期的な認証情報は管理が困難 短期トークンでリスク最⼩化
32. 32 2. 短期間の認証情報を提供するLiteLLM基盤 https://engineering.mercari.com/blog/entry/20251202-llm-key-server/
33. 33 2. LiteLLM https://github.com/BerriAI/litellm
34. 34 2. LiteLLM OpenAI‧Claude‧Gemini等LLM APIのOSSプロキシ 1. OpenAI互換APIを提供 2. 1つのAPIキーで複数モデルを切り替え利⽤可 3. チームや個⼈単位の予算‧APIキー有効期限管理 そのまま利⽤すると • チーム管理の複雑さが継続 • 予算の遵守が困難 • APIキー発⾏はマニュアルが必要な⼿作業 → チーム管理とAPIキー発⾏をシステム化
35. 35 2. LiteLLM Key Server 社内メンバー判定 + LiteLLMの管理API操作する管理コンポーネント
36. 36 2. LiteLLM Key Server 社内メンバー判定 + LiteLLMの管理API操作する管理コンポーネント 社内共通CLIツール起動 + Googleアカウント認証でAPIキー取得 → ⾃動的にチームに配属 → 個⼈の予算を固定 → APIキー発⾏はコマンド1つのみ Claude Code‧Codex‧Gemini CLI‧OpenCommit‧GitHub Actions Workflow‧Google Apps Scriptで利⽤可なOpenAI互換API
37. 37 2. LiteLLMによるLLM APIの中央集権化 LiteLLM • メルカリ社内でのAI活⽤基盤として定着 • アクセス管理とAPIキー管理の⾃動化 ◦ LiteLLMダッシュボードに触れることなく利⽤中 • 多くのエンジニアがLiteLLM経由でClaude Codeを利⽤中 • 独⾃開発ツールもLiteLLMをベースに開発 ◦ OpenAI等の公式SDKがそのまま使える → APIキー‧利⽤可モデル‧予算の管理、棚卸しの中央化が⼀気に実現
38. 38 3. AI Agent時代のソースコード基盤強化 AI Coding Agentは開発者の依頼を受けて、 ソースコードを編集し、Pull Requestを作成 "ここの実装を 変えてください" AI Coding Agent
 開発者
 ここに 注⽬？ 変更された内容 でPRを作成する ソースコード 
 リポジトリ 

39. 39 3. AI Agent時代のソースコード基盤強化 • AIが⽣成するコードの脆弱性：⼊⼒検証不⾜など ◦ SAST/DASTの導⼊ • プロンプトインジェクションに起因する機密情報の流出 ◦ DLPまたは送信範囲の制限の実装 • 過剰権限を持つエージェントによる不正操作 ◦ エージェントの権限を最⼩化 • 名前が似てるマルウェアを含む依存ライブラリ ◦ パッケージスキャナーや許可リストの導⼊ AI Coding Agentの導⼊によって⽣じるソースコード関連のリスク （及びその対策）：
40. 40 3. AI Agent時代のソースコード基盤強化 • SAST/DASTの導⼊ • DLPまたは送信範囲の制限の実装 • エージェントの権限を最⼩化 • パッケージスキャナーや許可リストの導⼊ 既存のソースコードセキュリティ‧ サプライチェーン攻撃対策の強化
41. 41 違うアイデンティティ 3. AI Agent時代のソースコード基盤強化 しかし、内容だけではなく、アイデンティティにも注⽬ AI Coding Agent
 1. "ここの実装を 変えてください" 2. 変更された内容 でPRを作成する 開発者
 ソースコード 
 リポジトリ 
 3. 変更を承認する
42. 42 3. AI Agent時代のソースコード基盤強化 AI Coding Agentの導⼊によって • 今まで想定しなかったパターン • ⾃⼰承認問題が起こり • 既存のコントロールでは簡単に対策できない
43. 43 3. AI Agent時代のソースコード基盤強化 クラウドでは... クラウド
 開発者
 サービス
 アカウント 
 権限借⽤ 操作 権限借⽤というコンテキストがある
44. 44 3. AI Agent時代のソースコード基盤強化 AI Coding Agentの導⼊によって • 今まで想定しなかったパターン • ⾃⼰承認問題が起こり • 既存のコントロールでは簡単に対策できない ソースコードリポジトリよりも コンテキストを持つコントロールの導⼊
45. 45 3. Policy Botとは 柔軟なポリシーエンジンによって、PRの承認ポリシーを適⽤する GitHubアプリ
46. 46 3. Policy Botの考え⽅ AI Coding Agentに依頼した変更を他の開発者のレビュー必須にしたい （セグリゲーション segregation of duties） → そういったPRのみに、2つのレビューを必須にする → Policy Botの柔軟なポリシーエンジンによって実現 policy: approval: - or: - developer - fallback approval_rules: - name: developer if: only_has_contributors_in: teams: ["developers"] requires: count: 1 - name: fallback requires: count: 2
47. 47 3. Policy Botの考え⽅ AI Coding Agentに依頼した変更を他の開発者のレビュー必須にしたい （セグリゲーション segregation of duties） → そういったPRのみに、2つのレビューを必須にする → Policy Botの柔軟なポリシーエンジンによって実現 脆弱性の対策だけではなく AI Agentを前提にしたセキュリティ設計
48. 48 メルカリでのAIプラットフォーム整備 AI活⽤に全⼒を出しながら安全さを保つ 1. 安全な⾃動化を保つn8nワークフローチェッカー 2. APIキー管理から解放されるLiteLLM基盤 3. 危ない操作を防ぐPolicy Botによるソースコード基盤強化 → 安全を確保しつつUXを維持するためのプラットフォーム AIセキュリティ対策はAI Agent⾃体に⽬が⾏きがち
49. 49 AIプラットフォーム整備 “プラットフォーム”をAI時代に対応させる
50. 50 AIプラットフォーム整備 1. LLM APIへのアクセス 2. プロンプト 3. LLMアプリケーション実装 4. ホスト環境 5. 認証と認可 6. Context管理サービス(RAG等) 7. Prompt Guardrailの標準化
51. 51 AIプラットフォーム整備 1. LLM APIへのアクセス - LLM Proxyによる統⼀化 2. プロンプト 3. LLMアプリケーション実装 4. ホスト環境 5. 認証と認可 6. Context管理サービス(RAG等) 7. Prompt Guardrailの標準化
52. 52 AIプラットフォーム整備 1. LLM APIへのアクセス - LLM Proxyによる統⼀化 2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測 3. LLMアプリケーション実装 4. ホスト環境 5. 認証と認可 6. Context管理サービス(RAG等) 7. Prompt Guardrailの標準化
53. 53 AIプラットフォーム整備 1. LLM APIへのアクセス - LLM Proxyによる統⼀化 2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測 3. LLMアプリケーション実装 - 実装‧ライブラリ共通化 4. ホスト環境 5. 認証と認可 6. Context管理サービス(RAG等) 7. Prompt Guardrailの標準化
54. 54 AIプラットフォーム整備 1. LLM APIへのアクセス - LLM Proxyによる統⼀化 2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測 3. LLMアプリケーション実装 - 実装‧ライブラリ共通化 4. ホスト環境 - ID検証プロキシ 5. 認証と認可 6. Context管理サービス(RAG等) 7. Prompt Guardrailの標準化
55. 55 AIプラットフォーム整備 1. LLM APIへのアクセス - LLM Proxyによる統⼀化 2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測 3. LLMアプリケーション実装 - 実装‧ライブラリ共通化 4. ホスト環境 - ID検証プロキシ 5. 認証と認可 - OAuthによるConfused Deputy Problem防⽌ 6. Context管理サービス(RAG等) 7. Prompt Guardrailの標準化
56. 56 AIプラットフォーム整備 1. LLM APIへのアクセス - LLM Proxyによる統⼀化 2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測 3. LLMアプリケーション実装 - 実装‧ライブラリ共通化 4. ホスト環境 - ID検証プロキシ 5. 認証と認可 - OAuthによるConfused Deputy Problem防⽌ 6. Context管理サービス(RAG等) - 不審なContextの監視 7. Prompt Guardrailの標準化
57. 57 AIプラットフォーム整備 1. LLM APIへのアクセス - LLM Proxyによる統⼀化 2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測 3. LLMアプリケーション実装 - 実装‧ライブラリ共通化 4. ホスト環境 - ID検証プロキシ 5. 認証と認可 - OAuthによるConfused Deputy Problem予防 6. Context管理サービス(RAG等) - 不審なContextの監視 7. Prompt Guardrailの標準化 - Prompt Injectionの検出
58. 58 AIプラットフォーム整備 AI Agent LLM Proxyによる統⼀化 プロンプト管理プロダクトによる管理‧精度計測 ID検証プロキシ OAuthによるConfused Deputy Problem防⽌ 不審なContextの監視 Prompt Injectionの検出
59. 59 AIプラットフォーム整備 ⼤規模な環境でのAI活⽤のスピードとセキュリティ両⽴ • 確認せずとも安全である安⼼感による⾼速化 • セキュリティチームの問い合わせ対応⼯数減 • プラットフォーム投資の下地で新たな脅威にすぐ対応可 安全なAIプラットフォーム整備は喫緊の課題 従来からのセキュリティ対策をBy Default適⽤