MLOpsエンジニアのtomoppiです。

データエンジニアリング部データサイエンスグループ（以下、DSG）に所属し、ML／LLM基盤の構築・改善に取り組んでいます。

AI Security Conferenceに参加してきたので、そのレポート記事となります。

余談ですが、当日はまい泉のお弁当をご用意いただきました。大好きなまい泉のカツサンドが出てきて、個人的に最もテンションが上がったポイントでした。

Findy Toolsさんとスポンサーの企業様には、感謝してもしきれません。

以降、真面目にレポートしていきます。

参加動機

MLOpsエンジニアとして本カンファレンスに参加した理由は、3ラインモデルの「第1線」を担う立場として、LLM特有のリスク管理をMLOpsのサイクルに組み込む重要性を感じているからです。

現在、タイミーのMLOpsチームでは、LLM API／LLMOps基盤の開発・運用を通じ、「安心・安全な利用」を最優先事項の一つとして取り組んでいます。

これまでも、LLMアプリケーション向けProduction Readiness Checklistの策定を通じて、セキュリティ観点の整理を進めてきました。

また社内勉強会では、OWASP Top 10 for LLMやAI-IRSといったフレームワークを紹介するなど、社内共有も行ってきました。

今回は、これまでの知見をさらに一歩進めるべく、他社の実務に即したセキュリティ運用の事例を収集し、自社基盤へフィードバックするヒントを得る目的で参加してきました。

全体を通して

大きく分けると、テーマは次の3本立てでした。

各社の前提が違うぶん「唯一の正解」があるわけではなく、それぞれの現実的な落とし所が共有されていたのが良かったです。

共通していたメッセージは、次の3点だと理解しました。

このセッションは、「信頼できるAI」について、方針→基準→運用→技術の流れで一本の線として説明されており、全体像がつかみやすかったです。

ポイント

セーフティとセキュリティをまず切り分けて考える
- セーフティ: AIが誤答や偏りで「害を出さない」ようにする（品質・倫理・説明責任）
- セキュリティ: 攻撃や漏洩から「守る」（プロンプトインジェクション、機密情報、権限など）
- そして両方を、場当たり対応ではなくガバナンス（方針・役割・プロセス・監査）として運用する
ガバナンスを基本方針／実施基準／実施要領の3層に分け、外向けと運用を切り分ける
AIリスクの議論はまずリスクの地図を作ってから話す（論点の漏れ・重複を防ぐ）
- 例: 意図しない損害、バイアス、説明責任、情報漏洩、モデル脆弱性などを上位カテゴリとして押さえる
モデル検証（開発時）とガードレール（実行時）を分けて考える
独自流ではなく、可能な限りグローバル標準の枠組みに寄せる（例: MITRE ATLAS）
ツールは黎明期なので、ツールありきではなくアーキテクチャとプロセスで統制できる型を先に作る

感想

セーフティ／セキュリティを分けて“運用”に落とす考えは、タイミーで進めているLLM基盤設計でも活用したいと思いました。

また、グローバル企業として関連会社が多いことから、全体を束ねるAI CoE（Center of Excellence） / AI Hubの構想も語られていました。組織の大きさや、そこでガバナンスをスケールさせる難しさについて、ヒントを得られる内容でした。

freee社のセッションは、「AIを全社で使う」前提に立ったときに、セキュリティをブレーキではなく「前に進める仕組み」として設計していたのが印象的でした。

ポイント

主要リスクは漏洩・ハルシネーション・コスト（扱うデータが機微なので）
展開は実験場 → 交通ルール → 安全装置 → 本格展開の段階設計
「安全装置」をプロキシ（LiteLLMなど）で型化し、ログ・機微情報遮断・出力制御を必須ライン化
市場が追いつかない領域は小さく内製（セキュリティレビュー／脆弱性診断の自動化など）
役割分担も、従来のCSIRT（コーポレート）／PSIRT（プロダクト）の分担を前提にしつつ、
- ブルー／レッド／ホワイト／パープルの「色」で責務を切り直す
- 背景: プロダクト特性の変化により守る範囲が広がり、従来の分業だけだと壁ができやすい
- ねらい: 特にパープルでレッドとブルーの連携を促進し、スピードを落とさない

感想

freee社の発表は、セキュリティ担当部門として“何をどう守るか”が具体的で、解像度が上がりました。要素技術面に関しても、タイミーでLiteLLMを利用した基盤開発を進めていることもあり、実際的に参考になる内容が多かったです。

今回一番のキーメッセージだと思ったのは、「AIセキュリティはツールを揃える前に、ガバナンスとアーキテクチャで回る型を先に作るのが大事」という点でした。

東京海上のセッションでは、セーフティ / セキュリティを切り分けたうえで、方針→基準→運用→技術へ落としていくことで、場当たり対応を防げるという点が整理されていました。

freeeのセッションでも、段階的に展開しつつ、プロキシを「安全装置」として型化してスピードを落とさない設計が重要と語られていました。

完璧主義で全部揃えてから進むのではなく、リスクベースで段階的に進めながら、使うだけで守られる状態（Secure by Default）に近づけていくことが、当面の目標になりそうだと思いました。

AI CoEやカラーコードのような組織設計は、いますぐ真似できるものではないですが、「活用を止めないために、どう責務とプロセスを設計するか」という観点は持っておきたいです。

タイミーでも現在、LLM基盤の構築と並行して、LLM機能の検証をいろいろ進めています。今回の学びをヒントに、取り組みを安全に加速させていきます。