Slide 1
Slide 1 text
1
メルカリのAI活⽤を⽀えるAIセキュリティ
AI Security Conference
株式会社メルカリ Choi Chun Ming
Slide 2
Slide 2 text
2
⾃⼰紹介
Choi Chun Ming @s3h_____
株式会社メルカリ
Platform Security Team所属
社内のGitHubおよびCI/CDの
セキュリティ改善を⾏っている
Slide 3
Slide 3 text
3
スマホアプリ「メルカリ」を中⼼に消費者向けサービスを展開
フリマアプリ
「メルカリ」
事業者向けEコマース
プラットフォーム
「メルカリShops」
暗号資産取引サービス
「メルコイン」
決済サービス
「メルペイ」
Fintech
Marketplace
Slide 4
Slide 4 text
4
2025年8⽉公開の決算資料にて全社の「AI-Native」化を宣⾔
Slide 5
Slide 5 text
5
メルカリでのAI活⽤の実態
Slide 6
Slide 6 text
6
アウトライン
I. よくあるAIセキュリティ対策の問題
II. メルカリでのAIプラットフォームの取り組み
1. n8nワークフローの⾃動セキュリティ検査
2. 短期間のLLM API認証情報を提供するLiteLLM基盤
3. Policy BotによるAI Agent時代のソースコード基盤強化
III. セキュアなAIプラットフォームの構築⽅法
Slide 7
Slide 7 text
7
よくあるAIセキュリティ対策例
● AI利⽤のセキュリティガイドライン
● AIソリューションの許可リスト
● 利⽤可能なAI機能の制限
● 端末のソフトウェア監視
● CSPMでAIサービス監視
Slide 8
Slide 8 text
8
AI セキュリティガイドラインの制定
https://careers.mercari.com/mercan/articles/55843/
Slide 9
Slide 9 text
9
AI セキュリティの従業員教育
https://careers.mercari.com/mercan/articles/55854/
Slide 10
Slide 10 text
10
AI セキュリティの従業員教育
https://careers.mercari.com/mercan/articles/55854/
Slide 11
Slide 11 text
11
よくあるAIセキュリティ対策例
● AI利⽤のセキュリティガイドライン
● AIソリューションの許可リスト
● 利⽤可能なAI機能の制限
● 端末のソフトウェア監視
● CSPMでAIサービス監視
→ “制限”ベースのアプローチだけではAI活⽤が遅れる
Slide 12
Slide 12 text
12
よくあるAIセキュリティ対策例
● AI利⽤のセキュリティガイドライン
● AIソリューションの許可リスト
● 利⽤可能なAI機能の制限
● 端末のソフトウェア監視
● CSPMでAIサービス監視
→ “制限”ベースのアプローチだけではAI活⽤が遅れる
AI活⽤に全⼒を出しながら安全さを保つには?
Slide 13
Slide 13 text
13
AI活⽤の⽀え⽅
AIセキュリティ対策の罠
● ガイドラインを策定 → 遵守状況の検査⼯数の不⾜
● AI Agentごとにレビュー体制 → ⼤量のレビューで疲弊
⼤規模環境に対する対策の困難さ
Slide 14
Slide 14 text
14
AI活⽤の⽀え⽅
“⼤規模環境”で
開発に全⼒を出しながら安全さを保つには?
→ Secure by Defaultな開発者プラットフォーム
Slide 15
Slide 15 text
15
AI活⽤の⽀え⽅
“⼤規模環境”で
AI活⽤に全⼒を出しながら安全さを保つには?
→ Secure by DefaultなAIプラットフォーム
Slide 16
Slide 16 text
16
AI活⽤を⽀えるプラットフォーム
社内全体での安全なAI活⽤を⽀えるプラットフォーム
→ メルカリの⼤規模なAI活⽤を⽀える「⾯」のセキュリティ対策事例
※ 例であり、そのままの導⼊を推奨するものではありません。
1. n8nワークフローの⾃動セキュリティ検査
2. 短期間のLLM API認証情報を提供するLiteLLM基盤
3. Policy BotによるAI Agent時代のソースコード基盤強化
Slide 17
Slide 17 text
17
1. n8nとは
様々なSaaS連携が可能な⾃由度の⾼いAIワークフロー
Slide 18
Slide 18 text
18
1. n8nのセキュリティ課題
様々なSaaS連携が可能な⾃由度の⾼いワークフロー
(1) 様々なSaaS連携 = Confused Deputy Problem 権限混同
Slide 19
Slide 19 text
19
アクセス権なし
アクセス権なし
1. Confused Deputy Problem 権限混同
DATA
SYSTEM
“この変更を行って
ください。”
“かしこまりま
した。”
アクセス権
アクセス権
AI Agent
(またはワークフロー )
Slide 20
Slide 20 text
20
1. Confused Deputy Problem 権限混同
(例) HRチームが⼈事管理AI Botを展開する場合
AI Botを実⾏できる⼈を制御しない
→ 別部署から⼈事情報を操作可能に
AI Botの返答を誰もが閲覧できるチャットチャンネルに出⼒
→ 別部署から⼈事情報を閲覧可能に
連携されるデータを元々扱うことができる範囲でAI Botを展開する必要
Slide 21
Slide 21 text
21
1. n8nのセキュリティ課題
様々なSaaS連携が可能な⾃由度の⾼いワークフロー
(1) 様々なSaaS連携 = Confused Deputy Problem 権限混同
(2) ⾃由度の⾼いワークフロー = Secure by Defaultではない
Slide 22
Slide 22 text
22
1. Secure by Defaultではないワークフロー
誰でも実⾏できる
誰でも出⼒を閲覧で
きる
Slide 23
Slide 23 text
23
1. n8nのセキュリティ課題
様々なSaaS連携が可能な⾃由度の⾼いワークフロー
(1) 様々なSaaS連携 = Confused Deputy Problem 権限混同
(2) ⾃由度の⾼いワークフロー = Secure by Defaultではない
Confused Deputy Problemを軽減 + Secure by Defaultな設定を強制
Slide 24
Slide 24 text
24
1. n8nのセキュリティ課題
⼀般のアプリケーション開発では...
開発者
リポジトリ・
デプロイ
SAST
SCA
Linter
シークレット
スキャン
セキュアな開発を開発者に任せるのではなく
⾃動チェックによるセキュリティのシフトレフト
Slide 25
Slide 25 text
25
1. n8nのセキュリティ対策
https://engineering.mercari.com/blog/entry/20251211-580dc508a7/
n8nワークフローの⾃動チェッカー開発
Slide 26
Slide 26 text
26
1. n8nのセキュリティ対策
Slide 27
Slide 27 text
27
1. n8nのセキュリティ対策
「安全性」を担保する仕組みを事前に実装
→ 新しいサービスでもセキュリティの基礎を担保できる
Slide 28
Slide 28 text
28
2. 短期間の認証情報を提供するLiteLLM基盤
LLMを利⽤する様々なアプリケーション
● Claude Code
● Codex
● Gemini CLI
● OpenCode
● OpenCommit
● GitHub Actions Workflow
● Google Apps Script
● 独⾃ツール
→ LLMモデルへのアクセス権限付与は?
Slide 29
Slide 29 text
29
2. LLMモデルへのアクセス権限付与
platform.openai.com や platform.claude.com のAPIキー
ありがちな管理
1. 管理チーム主導で各ワークスペースを作成
2. ワークスペースの中で予算リミットを付与してAPIキー発⾏
→ 退職者の対応は?
→ 発⾏されたAPIキーはどう使われている?
→ アクセス権限とAPIキーの棚卸しは?
→ 予算の粒度が⼤きく使いすぎを防⽌できていない?
参考: [地獄] OpenAI APIが不正使⽤された件 - Qiita
Slide 30
Slide 30 text
30
2. LLMモデルへのアクセス権限付与
platform.openai.com や platform.claude.com のAPIキー
● プラットフォームごとの管理‧棚卸しコスト
● 流出APIキーによるEDoSリスク
● 発⾏リードタイムの⻑期化によるUX低下
→ 短期間の有効期限で棚卸しを実質⾃動化?
→ 個⼈単位の細かな予算制限?
→ いつでもすぐに発⾏できるAPIキー?
Slide 31
Slide 31 text
31
アクセス
キー
2. LLMモデルへのアクセス権限付与
クラウドでは...
ワークロード
サーバー
OIDC
Workload
Identity
⻑期的な認証情報は管理が困難
短期トークンでリスク最⼩化
Slide 32
Slide 32 text
32
2. 短期間の認証情報を提供するLiteLLM基盤
https://engineering.mercari.com/blog/entry/20251202-llm-key-server/
Slide 33
Slide 33 text
33
2. LiteLLM
https://github.com/BerriAI/litellm
Slide 34
Slide 34 text
34
2. LiteLLM
OpenAI‧Claude‧Gemini等LLM APIのOSSプロキシ
1. OpenAI互換APIを提供
2. 1つのAPIキーで複数モデルを切り替え利⽤可
3. チームや個⼈単位の予算‧APIキー有効期限管理
そのまま利⽤すると
● チーム管理の複雑さが継続
● 予算の遵守が困難
● APIキー発⾏はマニュアルが必要な⼿作業
→ チーム管理とAPIキー発⾏をシステム化
Slide 35
Slide 35 text
35
2. LiteLLM Key Server
社内メンバー判定 + LiteLLMの管理API操作する管理コンポーネント
Slide 36
Slide 36 text
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
Slide 37
Slide 37 text
37
2. LiteLLMによるLLM APIの中央集権化
LiteLLM
● メルカリ社内でのAI活⽤基盤として定着
● アクセス管理とAPIキー管理の⾃動化
○ LiteLLMダッシュボードに触れることなく利⽤中
● 多くのエンジニアがLiteLLM経由でClaude Codeを利⽤中
● 独⾃開発ツールもLiteLLMをベースに開発
○ OpenAI等の公式SDKがそのまま使える
→ APIキー‧利⽤可モデル‧予算の管理、棚卸しの中央化が⼀気に実現
Slide 38
Slide 38 text
38
3. AI Agent時代のソースコード基盤強化
AI Coding Agentは開発者の依頼を受けて、
ソースコードを編集し、Pull Requestを作成
"ここの実装を
変えてください"
AI Coding
Agent
開発者
ここに
注⽬？
変更された内容
でPRを作成する
ソースコード
リポジトリ
Slide 39
Slide 39 text
39
3. AI Agent時代のソースコード基盤強化
● AIが⽣成するコードの脆弱性：⼊⼒検証不⾜など
○ SAST/DASTの導⼊
● プロンプトインジェクションに起因する機密情報の流出
○ DLPまたは送信範囲の制限の実装
● 過剰権限を持つエージェントによる不正操作
○ エージェントの権限を最⼩化
● 名前が似てるマルウェアを含む依存ライブラリ
○ パッケージスキャナーや許可リストの導⼊
AI Coding Agentの導⼊によって⽣じるソースコード関連のリスク
（及びその対策）：
Slide 40
Slide 40 text
40
3. AI Agent時代のソースコード基盤強化
● SAST/DASTの導⼊
● DLPまたは送信範囲の制限の実装
● エージェントの権限を最⼩化
● パッケージスキャナーや許可リストの導⼊
既存のソースコードセキュリティ‧
サプライチェーン攻撃対策の強化
Slide 41
Slide 41 text
41
違うアイデンティティ
3. AI Agent時代のソースコード基盤強化
しかし、内容だけではなく、アイデンティティにも注⽬
AI Coding Agent
1. "ここの実装を
変えてください"
2. 変更された内容
でPRを作成する
開発者
ソースコード
リポジトリ
3. 変更を承認する
Slide 42
Slide 42 text
42
3. AI Agent時代のソースコード基盤強化
AI Coding Agentの導⼊によって
● 今まで想定しなかったパターン
● ⾃⼰承認問題が起こり
● 既存のコントロールでは簡単に対策できない
Slide 43
Slide 43 text
43
3. AI Agent時代のソースコード基盤強化
クラウドでは...
クラウド
開発者
サービス
アカウント
権限借⽤ 操作
権限借⽤というコンテキストがある
Slide 44
Slide 44 text
44
3. AI Agent時代のソースコード基盤強化
AI Coding Agentの導⼊によって
● 今まで想定しなかったパターン
● ⾃⼰承認問題が起こり
● 既存のコントロールでは簡単に対策できない
ソースコードリポジトリよりも
コンテキストを持つコントロールの導⼊
Slide 45
Slide 45 text
45
3. Policy Botとは
柔軟なポリシーエンジンによって、PRの承認ポリシーを適⽤する
GitHubアプリ
Slide 46
Slide 46 text
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
Slide 47
Slide 47 text
47
3. Policy Botの考え⽅
AI Coding Agentに依頼した変更を他の開発者のレビュー必須にしたい
（セグリゲーション segregation of duties）
→ そういったPRのみに、2つのレビューを必須にする
→ Policy Botの柔軟なポリシーエンジンによって実現
脆弱性の対策だけではなく
AI Agentを前提にしたセキュリティ設計
Slide 48
Slide 48 text
48
メルカリでのAIプラットフォーム整備
AI活⽤に全⼒を出しながら安全さを保つ
1. 安全な⾃動化を保つn8nワークフローチェッカー
2. APIキー管理から解放されるLiteLLM基盤
3. 危ない操作を防ぐPolicy Botによるソースコード基盤強化
→ 安全を確保しつつUXを維持するためのプラットフォーム
AIセキュリティ対策はAI Agent⾃体に⽬が⾏きがち
Slide 49
Slide 49 text
49
AIプラットフォーム整備
“プラットフォーム”をAI時代に対応させる
Slide 50
Slide 50 text
50
AIプラットフォーム整備
1. LLM APIへのアクセス
2. プロンプト
3. LLMアプリケーション実装
4. ホスト環境
5. 認証と認可
6. Context管理サービス(RAG等)
7. Prompt Guardrailの標準化
Slide 51
Slide 51 text
51
AIプラットフォーム整備
1. LLM APIへのアクセス - LLM Proxyによる統⼀化
2. プロンプト
3. LLMアプリケーション実装
4. ホスト環境
5. 認証と認可
6. Context管理サービス(RAG等)
7. Prompt Guardrailの標準化
Slide 52
Slide 52 text
52
AIプラットフォーム整備
1. LLM APIへのアクセス - LLM Proxyによる統⼀化
2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測
3. LLMアプリケーション実装
4. ホスト環境
5. 認証と認可
6. Context管理サービス(RAG等)
7. Prompt Guardrailの標準化
Slide 53
Slide 53 text
53
AIプラットフォーム整備
1. LLM APIへのアクセス - LLM Proxyによる統⼀化
2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測
3. LLMアプリケーション実装 - 実装‧ライブラリ共通化
4. ホスト環境
5. 認証と認可
6. Context管理サービス(RAG等)
7. Prompt Guardrailの標準化
Slide 54
Slide 54 text
54
AIプラットフォーム整備
1. LLM APIへのアクセス - LLM Proxyによる統⼀化
2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測
3. LLMアプリケーション実装 - 実装‧ライブラリ共通化
4. ホスト環境 - ID検証プロキシ
5. 認証と認可
6. Context管理サービス(RAG等)
7. Prompt Guardrailの標準化
Slide 55
Slide 55 text
55
AIプラットフォーム整備
1. LLM APIへのアクセス - LLM Proxyによる統⼀化
2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測
3. LLMアプリケーション実装 - 実装‧ライブラリ共通化
4. ホスト環境 - ID検証プロキシ
5. 認証と認可 - OAuthによるConfused Deputy Problem防⽌
6. Context管理サービス(RAG等)
7. Prompt Guardrailの標準化
Slide 56
Slide 56 text
56
AIプラットフォーム整備
1. LLM APIへのアクセス - LLM Proxyによる統⼀化
2. プロンプト - プロンプト管理プロダクトによる管理‧精度計測
3. LLMアプリケーション実装 - 実装‧ライブラリ共通化
4. ホスト環境 - ID検証プロキシ
5. 認証と認可 - OAuthによるConfused Deputy Problem防⽌
6. Context管理サービス(RAG等) - 不審なContextの監視
7. Prompt Guardrailの標準化
Slide 57
Slide 57 text
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の検出
Slide 58
Slide 58 text
58
AIプラットフォーム整備
AI Agent
LLM Proxyによる統⼀化
プロンプト管理プロダクトによる管理‧精度計測
ID検証プロキシ
OAuthによるConfused Deputy Problem防⽌
不審なContextの監視
Prompt Injectionの検出
Slide 59
Slide 59 text
59
AIプラットフォーム整備
⼤規模な環境でのAI活⽤のスピードとセキュリティ両⽴
● 確認せずとも安全である安⼼感による⾼速化
● セキュリティチームの問い合わせ対応⼯数減
● プラットフォーム投資の下地で新たな脅威にすぐ対応可
安全なAIプラットフォーム整備は喫緊の課題
従来からのセキュリティ対策をBy Default適⽤