Slide 1

Slide 1 text

  1 AI Coding Agent 全社導入とセキュリティ対策 セキュリティをボトルネックにしないための実践的アプローチ

Slide 2

Slide 2 text

  2 社会⼈3年⽬のGitHubオタク 最近の流⾏りはAI向けベンチマークを解くこと hackeroneで上位のAI Agent、XBOWが独⾃に作成した ベンチマーク⽤やられアプリ集 xbow-engineering/validation-benchmarks セキュリティ若⼿の会というイベントやってます X: @0xhikae hikae 江頭 輝 / PSIRT レッドチーム

Slide 3

Slide 3 text

  3 freee開発組織での AIツール利用状況 チャットAI GitHub Copilot、Gemini、社内基盤(Difyに近いもの)が主に利用可能。 AIコーディングエージェント 2024年末から検証利用開始。 2025年4月から全開発者に開放。 ● Cline ● Roo Code ● goose ● Devin ● Claude Code

Slide 4

Slide 4 text

  4 freee開発組織での AIツール利用状況 MCP 2025年4月から継続的に追加中 ● Confluence ● GitHub ● Slack ● Playwright ● Terraform ● 社内ライブラリ系 ○ UIライブラリ(vibes) ○ 脆弱性診断 ○ ……

Slide 5

Slide 5 text

  5 よく似た特性を持つ自動車の社会実装になぞって解説していきます freeeにおけるAIガバナンスの整備プロセス 実証実験場
 をつくる
 歩道と車道を
 分ける
 交通ルールと安全装置
 を整備する
 高速道路の設置と
 規制緩和
 01
 02
 03
 04


Slide 6

Slide 6 text

1. 実証実験場をつくる

Slide 7

Slide 7 text

7 AIツールの効果検証、コストパフォーマンス検証、セキュリティリスク検証、全 社展開のための課題の洗い出しを高速で行う ✓ 一定のAIリテラシがあるメンバーがチームとして立候補 ✓ ワーキングアグリーメントをベースに認定 ✓ ツール/サービス導入に関わる全チームと協力した高速な申請フロー 1. 実証実験場をつくる

Slide 8

Slide 8 text

  8 AIの急速な技術進歩に対応した安全性確保と技術革新の両立 AI特区制度 / AI駆動開発チームの発足 AI特区での
 AIツールの評価 
 ガイドライン 
 策定と基盤構築 
 専門チームによる 
 全社展開&運用
 安全な環境、限られたメン バーによるスピーディーな検 証サイクル
 特区で得られた知見を形式 知&基盤化。全社展開のた めのセキュリティ対策
 AI駆動開発チームによるス ピーディーな展開と
 継続的な評価


Slide 9

Slide 9 text

2. ⾞道と歩道を分ける

Slide 10

Slide 10 text

10 ✓ AI Agentのリスクは実行する環境と扱える権限によって大きく異なる ✓ もしも何もしなければ、人間と同じ行動が可能 2. 車道と歩道を分ける

Slide 11

Slide 11 text

11 Coding Agentはシェル権限の委譲が不可欠 任意のコマンドが実行できると ✓ 環境変数へアクセスできる ✓ その環境変数で別のサービスにアクセスできる ✓ 社内の情報を社外に送信してしまう MCPにおけるセキュリティ考慮事項と実装における観点 https://blog.flatt.tech/entry/mcp_security_first リスク: 危険なコマンドを実行する

Slide 12

Slide 12 text

12 GitHub Copilot時代から存在するリスクだが、vibe codingを始めとして 非エンジニアでもコーディングできてしまう時代にも、従来通りの適切な開 発サイクルを守る重要性が高まっています ✓ コードレビューを行う ✓ SASTによる検知 / ホワイトボックスな脆弱性診断 参考:「それは、本当に安全なんですか?」セキュリティ専門家が 「GitHub Copilot」の全社一斉導入時に考えたあれこれ https://logmi.jp/main/technology/329510 リスク: 脆弱なコードが埋め込まれる GitHub Copilot導入時のスライド 
 logmiみてね


Slide 13

Slide 13 text

13 AIという仕組み上 事故は発生してしまう。事故が発生しても人間に被害が及ばな いような仕組みづくりを意識しています ファイル権限を渡すと平文で書いたシークレットを勝手に読まれる ✓ シークレットを暗号化、clineignoreの設置、DLP 危険なコマンドが実行された場合のインシデント体制 ✓ XDR(プロセス監視)でどのように見えるか検証 ✓ LLMログから実行コマンドを抽出して分析 ✓ 危険なアクションをリアルタイムでブロックする仕組みを導入 新たにAIに与える権限が増えた場合のプロセス整備(AI Policy) 2. 車道と歩道を分ける

Slide 14

Slide 14 text

14 権限ごとに判断が必要。新たにAIに与える権限を増やし たい特区メンバーのためにAI Policyの仕組みを策定 ✓ AI特区認定チームが AI Agent xxx Policyというポ リシーを記載する ✓ 何ができるようにするのかを明文化する Pickup: AI Policy 権限ごとに判断 


Slide 15

Slide 15 text

3. 交通ルールと安全装置を整備する

Slide 16

Slide 16 text

16 暗黙知のみで安全に使うのは組織規模が拡大するに連れて困難になります 今後生まれる新しいツールを導入する意思決定を素早く行うためにもガイドライ ン策定や、危険な行動の発見する基盤の整備に取り掛かりました ✓ ツール別にガイドラインを制定する ✓ 機微情報や暴走によるリソース枯渇を検知防御するガードレール ✓ リアルタイムで危険なアクションを検知防御するガードレール 3. 交通ルールと安全装置を整備する

Slide 17

Slide 17 text

17 シングルエージェント: 通常のチャットの約4倍 マルチエージェント: 通常のチャットの約15倍 ✓ LLMでのループ検知実装 ✓ 長いメッセージに対して警告 リスク: リソース枯渇 https://www.anthropic.com/engineering/built- multi-agent-research-system

Slide 18

Slide 18 text

18 LiteLLMをベースにしたOpenAI API Compatibleプロキシをセルフホスト ✓ OpenAI CodexでClaudeモデルが利用できる ✓ 誰がどのようなリクエストをしたのかログで後から追える ✓ ツールごとにトークン見積もりするなどが不要に Pickup: LLM向けプロキシサーバー よく使われる Coding Agentや
 週次の推移などを可視化 


Slide 19

Slide 19 text

19 ポリシーに従い、危険と判定された場合 レスポンスがリアルタイムで遮断され、 分析結果をSlack上で観測できるようにしている Pickup: ガードレール 原因をLLMが分析
 カスタム指示への PromptInjectionであることが判明 
 sudoコマンドの実行を 
 エラーで停止 


Slide 20

Slide 20 text

4. ⾼速道路の設置と規制緩和

Slide 21

Slide 21 text

21 利用用途の拡大や誤検知によりガードレールが開発を妨げてしまいます。 ログやヒアリングを元にガードレールが渋滞を引き起こさないような改善を実施し ました ✓ 監査LLMによる誤検知の削減 ✓ モードで挙動が切り替わるMCPサーバー ✓ AWS Bedrockに依存しない 4. 高速道路の設置と規制緩和

Slide 22

Slide 22 text

22 社内における情報レベル定義と AI Policyの関係 レベル 扱う情報 A アラート調査に必要なログ B 統計情報、ソースコード C 公開情報 書き込ませ ない
 読み込ま せない


Slide 23

Slide 23 text

23 ログ調査などそのままでは外部送信リスクが高い サービスとの連携を実現したい Aモード→ issueもアラートも読み取れるが、 B情報を扱うサービスへのwriteはできない Bモード→ GitHub PR, チケットの作成ができるが A情報をreadできない Pickup: モードで挙動が切り替わる MCPサーバー

Slide 24

Slide 24 text

24 Bedrockに頼り切るのではなく、モデルが試せるようモデル、プロバイダごとの 安全性を評価するプロセスも、多くのツールを検証する上では欠かせない要素 である ✓ フロンティアモデルを使えるようにする Bedrock, Vertex AI ✓ モデル提供会社の利用 Claude Code Max Plan), OpenAI Pickup: AWS Bedrockに依存しない

Slide 25

Slide 25 text

25 Coding Agentにシェル権限を渡さない、全てapprove必須にすると、 Shadow AI ITの増加、競争力の低下( Dev EXの低下)を引き起こす AI AgentにとってのDev EXも低下して生産性が上がらないとなると、 「我々の組織ではAIは不向き」という投資判断を引き起こす原因になってしまう 〇〇を禁止するという判断がセキュリティリスクになるからこそ、 AI Agentを効果的に扱うためには何の権限を与える必要があるのかという視点 を起点にガードレールを整備すること が重要である リスク: 我々がAIを使えない環境にしてしまう

Slide 26

Slide 26 text

26 多層防御で交通事故が発生しても人身事故にならないようなガードレールを目指す、 もしもインシデントが発生した時に対応できるガイドライン を提供する 利用者が安心してAIと協業できているかが効果的なセキュリティ対策である指標になる 移り変わりが激しい領域だからこそ、 社内の状況に合わせて成長するガードレールを考えてみてみてはいかがでしょう? Coding Agent の動作原理を解明するために何を学ぶと良いのだろうか? https://developers.freee.co.jp/entry/coding-agent-mechanism まとめ: AI活用におけるセキュリティの役割