Splunk MCPサーバの利活用事例 ーKINTOテクノロジーズの取り組み

Transcript

1. Splunk MCPサーバの利活用事例 ー KINTOテクノロジーズの取り組み KINTOテクノロジーズ株式会社 プラットフォーム開発部 クラウドセキュリティグループ 桑原大輔
2. 自己紹介 • 氏名 ： 桑原 大輔（くわはら だいすけ） • 所属 ： KINTOテクノロジーズ株式会社 (KTC) プラットフォーム開発部 クラウドセキュリティグループ セキュリティ・プライバシー部 サイバーセキュリティグループ • 業務 ： 主に AWS や Google Cloud などの クラウドレイヤのセキュリティと SOC (Security Operation Center) 担当
3. KINTOテクノロジーズ (KTC) の概要
4. クルマのサブスク by TOYOTA
5. KINTOテクノロジーズ(KTC) について 設立 2021年4月
6. KINTO テクノロジーズが手掛けたプロダクト
7. Tech Blog
8. Speaker Deck KintoTech_Dev KINTOテクノロジーズ Osaka Tech Lab
9. Agenda 1. SOC 日次監視の半自動化 2. AWS環境での脅威検知後における 詳細分析の効率化 3. 取り込みログフィルタリングの実践
10. Agenda 1. SOC 日次監視の半自動化 2. AWS環境での脅威検知後における 詳細分析の効率化 3. 取り込みログフィルタリングの実践 セキュリティ：定常運用 セキュリティ：アドホック運用 Splunk 汎用：運用改善
11. SOC 日次監視の半自動化
12. 0. KTC の環境と Splunk 活用
13. SIEM としての Splunk Cloud • KTC では、Splunk Cloud を SIEM（Security Information and Event Management）として 活用し、マルチクラウド環境のセキュリティログを一元管理。 活用シーン 説明 セキュリティログの集約基盤 複数のクラウドプラットフォーム（AWS、Azure、Google Cloud）や各種 SaaS サービス から出力される膨大なセキュリティログを一元的に集約 高度なログ解析 SPL（Search Processing Language）を用いた柔軟かつ強力なログ解析により、 セキュリティインシデントの詳細分析を実施 可視化とトレンド分析 カスタマイズ可能なダッシュボードにより、セキュリティ状況の傾向把握 脅威の相関分析 複数のログソースを相関分析し、潜在的な脅威パターンを特定 アラート通報と対応フロー 検知した脅威を即座にセキュリティチームへ通知し、迅速なインシデント対応を 可能に 未使用：Splunk Enterprise Security
14. 1. SOC 日次監視の課題
15. SOC 日次監視の課題 これらの課題を解決するため、Splunk Cloud MCP サーバの活用を開始 ◼ 監視業務の流れ ◼ 監視業務の課題 • 作業時間：1日あたり 2〜3時間 の手動作業 • 属人化：SPL 知識・ログ解析スキルが特定担当者に集中 • 標準化不足：判断基準が暗黙知となり、新メンバー参画の障壁に ①一次調査と レポート作成 ②深掘り調査の 要否判断 ③深掘り調査 ④対応要否判断 ⑤事案対応
16. 2. Splunk Cloud MCP サーバで どう解決したか
17. 解決策： Splunk Cloud MCP サーバを 活用した半自動化 ◼ 使用したツール • MCP クライアント • OpenAI Codex（Visual Studio Code 版） • モデル：GPT-5.1-Codex-Max、推論：高 • MCP サーバ • Splunk Cloud MCP：ログ検索を実行 • その他 • Splunk Cloud：システムのログ集約・分析基盤 • Github：監視用プロンプト共有基盤 MCP クライアント & 監視用プロンプト Splunk Cloud MCP Search Head Splunk Cloud
18. 具体的な運用の流れ ◼ 手順１. 監視用プロンプトを準備 GitHub リポジトリから最新の監視用プロンプト（md ファイル）を取得
19. 具体的な運用の流れ ◼ 手順２. Codex で一次調査（深掘り調査含む）を実行 Codex のチャット画面で、プロンプト md ファイルを指定して Codex に処理を実行 • 指示例：xxxxx/prompts/yyyyy.md のタスクを実行してください • 処理時間：1プロンプトあたり10〜20分程度
20. 具体的な運用の流れ ◼ 手順３.レポートの品質チェック・深掘り要否を判断 Codex が作成したレポートを確認し、深掘り調査の必要性を「人間が判断」 • ログ件数や日時、調査内容の妥当性をチェック • 品質チェック用ダッシュボードを作成し、チェック作業を効率化
21. 具体的な運用の流れ ◼ 手順４.深掘り調査を実施 レポート内容を基に、必要に応じて追加調査を行い、セキュリティインシデントか否かを判断 • Splunk Cloud で手動検索 • Codex + Splunk Cloud MCP を活用した追加調査 ◼ 手順５.セキュリティインシデント対応 インシデントと判断した場合、関係者と連携して対応を実施
22. 監視業務フロー比較（Before / After） 3時間 ①一次調査と レポート作成 ②深掘り調査の 要否判断 After Before 特定の担当者に依存 ①一次調査と レポート作成 ②深掘り調査の 一次要否判断 ④深掘り調査 ⑤対応要否判断 ⑥事案対応 ③品質チェック ③深掘り調査 ④対応要否判断 ⑤事案対応 AI エージェントが担当 人間の役割が変化 作業時間 1.5時間
23. 3. やってみてわかったこと
24. 学び①：手順書駆動プロンプト開発 ◼ 失敗したアプローチ：バイブコーディング的アプローチ • AI とチャットしながらプロンプトを作成 • 判断基準が文書化されておらず曖昧 → AIの出力がブレる • 1〜2週間かけても納得のいくプロンプトが作れなかった ◼ 成功したアプローチ：手順書駆動プロンプト開発 1. まず 、人間が迷わず実行できるレベルで明文化した「手順書」を作成 • 監視目的、SPL クエリ、判断基準、出力要件をセットで定義 2. 次に、手順書を生成 AI に渡して プロンプトを作成してもらう • 結果的に、手順書作成含め 約2日で期待通りのプロンプトが完成 • 同じ要領で他システムへ横展開も容易 • 仕様駆動開発に似たアプローチ
25. 学び① 手順書駆動プロンプト開発 ◼ プロンプト構成のポイント • サーチマクロの活用 → 複雑な SPL をマクロ化することで、 →プロンプトのトークン節約 ＆ AI出力のブレ軽減 • 監視項目ごとに、 「SPL」「判断基準」「出力要件」をセットで定義 → AI出力品質の安定化
26. 学び② 「できること」と「やるべきこと」は違う ◼ 陥った罠 • Splunk Cloud MCP × AIエージェントは「過度に複雑な調査」が気軽にできてしまう • 「せっかくだからこの観点も…」→ 監視対象を広げすぎる • AIが大量にレポートを生成 → 「やっている感」 は出るが、レビューが追いつかない ◼ 大切な考え方 • 「半自動化」 を目指し、最終判断は人間（ヒューマン・イン・ザ・ループを意識） • 人間がレビューできる範囲で、注力すべき観点に絞る • 「監視の意図」に立ち返る 完全自動化ではなく「人間の判断を支援するツール」 として位置づけることが成功の鍵
27. 学び③ 想定以上だった業務の標準化効果 Splunk Cloud MCPにより、 Splunkの活用を「個人のスキル」から「チームの仕組み」へ変えることができた 観点 Before After SPL 知識 特定担当者に依存 プロンプトがあれば誰でも実行可能 判断基準 暗黙知 手順書・プロンプトに明文化 運用体制 1名に集中 3名ローテーション体制を実現
28. 学び④プログラマティックな前処理と 生成 AI の役割分担 ◼ 陥った罠 • Codex のトークンが大量消費されるようになった • 主な原因は、セキュリティログ分析を進めるにつれ、調査対象や分析要素が自然と増え、 投げる SPL の数も種類も増加し、トークン消費が加速的に膨らんでいった ◼ 大切な考え方 • MCP にすべてを依存せず、処理全体を通して最適化を図ること • MCP は生成 AI と外部ツールをつなぐ便利な接続手段だが、全工程を MCP 経由で生成 AI に丸投げすると、 トークン消費などが制御不能になる SPL クエリ処理の定型化 定型化可能な SPL については、調査観点などと合わせて YAML ファイルで管理 プログラマティックな 前処理 定型化された SPL は、Splunk API 経由でクエリを実行 Updated
29. 4. 本章のまとめ
30. 本章のまとめ Splunk Cloud MCP の活用により、SOC 日次監視業務を改善 • 監視業務の効率化：作業時間 2〜3時間/日 → 1〜1.5時間/日（約50%削減） • 手順書駆動プロンプト開発：業務を明文化してから Splunk Cloud MCP 活用へ • 属人化の解消 ：SPL 知識不要で誰でも監視可能、3名ローテーション実現 • MCP の適材適所での活用：探索的な調査や柔軟な分析が必要な場面に限定して使用する Splunk Cloud MCP は、Splunkの活用を 「個人のスキル」から「チームの仕組み」へ変える力を持っている
31. AWS 環境での脅威検知後に おける詳細分析の効率化
32. クラウド環境でのセキュリティ対策 • KTC では、オンプレミス環境を一切保有せず、完全なフルクラウド環境。 • フルクラウド環境においては、境界型セキュリティに加えて、ID・アクセス管理、データ保護、継続的 な監視など、多層的な防御が必要。 • KTC では特に、各クラウドプラットフォームの監査ログを統合的に分析することで、継続的な監視と セキュリティ担保を実現。 取り組み 内容 監査ログの統合管理 AWS CloudTrail、Azure Activity Log、Google Cloud Audit Logs などの監査ログを集約 ID 管理ログの一元化 Microsoft Entra ID（旧Azure AD）のサインインログ、認証ログを統合 横断的なログ分析 複数のクラウドプラットフォームにまたがるユーザー行動を追跡し、異常なアクセス パターンや権限昇格の試みを検知 脅威の総合的判断 単一のログソースでは判断できない高度な脅威を、複数のログソースを 相関分析することで特定 詳細なフォレンジック分析 インシデント発生時には、時系列に沿った詳細な行動履歴を再構築し、根本原因の 特定と影響範囲の調査を実施
33. 1. AWS 環境の脅威検知
34. AWS 環境内のセキュリティ脅威を検知する サービス：Amazon GuardDuty Amazon GuardDuty AWS 環境のログを継続的にモニタリング、分析を行い、 機械学習（ML）を利用して、疑わしいアクティビティ や潜在的な脅威を検出する。 AWS CloudTrail Amazon VPC Flow logs Amazon Route 53 Resolver query logging Amazon GuardDuty Region 基本データソース Amazon EventBridge Amazon SNS Amazon SNS Email Slack Administrator AWS 環境における脅威検知サービス 脅威の判定は、 1. AWS CloudTrail の管理イベント 2. Amazon VPC Flow logs 3. Amazon Route 53 Resolver クエリログ を自動で収集して使用している。
35. KTC における GuardDuty 検知状況 Discovery:IAMUser/AnomalousBehavior Policy:S3/BucketBlockPublicAccessDisabled InitialAccess:IAMUser/AnomalousBehavior Impact:IAMUser/AnomalousBehavior Exfiltration:S3/AnomalousBehavior Discovery:S3/AnomalousBehavior CredentialAccess:IAMUser/AnomalousBehavior Impact:S3/AnomalousBehavior.Write Stealth:IAMUser/CloudTrailLoggingDisabled Policy:IAMUser/RootCredentialUsage Recon:EC2/Portscan Behavior:EC2/NetworkPortUnusual
36. AnomalousBehavior（異常な振る舞い） AnomalousBehavior の特性： • 「通常とは異なる行動パターン」を機械学習により検知 •普段使用しないリージョンからの API 呼び出し •通常と異なる時間帯の大量操作 •初めて使用する API の実行など • 必ずしも悪意のある行動とは限らない • 業務上の正当な作業である可能性も高い
37. ログ分析の必要性 AnomalousBehavior が検知された場合、以下を確認する必要がある。 1. 操作主体の真正性 正規ユーザー本人による操作か（アカウント乗っ取り・不正アクセスの可能性） 2. 操作の正当性と適切性 業務上必要な作業を、適切な権限と承認された手順で実行したか 3. 意図性の確認 意図的な操作か、誤操作や設定ミスによるものか AWS CloudTrail（監査ログ）の詳細な分析が不可欠
38. 2. CloudTrail 分析における課題と、 生成 AI ＋ Splunk の連携による分析の高度化
39. 分析に必要な調査項目（一例） 調査項目 確認内容 操作主体の識別 人間による操作か、プログラム（サービスロール、Lambda、SageMaker 等の AWS サービス）による自動操作か 操作者の特定 IAM ユーザー名の確認 AssumeRole を使用している場合は、sessionContext や assumedRoleId、PrincipalId から実際の操作者を特定 フェデレーション認証の場合は、元の ID プロバイダーのユーザーを特定 アクセス経路の追跡 AWS Management Console、AWS CLI、SDK、どの経路からアクセスしたか SSO 経由か、直接認証か アクセス元の分析 ソースIPアドレスの特定 IPアドレスから国・地域を特定（GeoIP） 組織が管理するIPアドレス範囲からか、外部からか クライアント環境の把握 userAgent フィールドの分析 Management Console 経由の場合：ブラウザの種類とバージョン CLI/SDK 経由の場合：使用ツールとバージョン（例：aws-cli/2.x.x） 行動パターンの比較 過去の操作履歴と比較し、普段と異なる操作がないか GuardDuty で指摘されている点以外にも不審な操作がないか 操作の時系列を追い、一連の行動として不自然な点がないか
40. 現状の分析作業における課題 GuardDuty の検知をトリガーに、アナリストが手動で SPL クエリを作成・実行して CloudTrail ログを調査 作業の煩雑性 • 都度 SPL を書いてクエリを実行する必要がある • 調査項目を絞り込むたびに新たなクエリを作成 • 試行錯誤を繰り返すため、時間がかかる アナリストの 力量依存 • 分析観点の網羅性：どのような視点で調査すべきか • ログ構造の理解：CloudTrail の JSON 構造やフィー ルドの意味を正確に把握 • SPL 記述能力：複雑な条件や集計を適切に表現でき るか • 結果の解釈力：Splunk が返す結果から正しい判断を 下せるか 属人化のリスク • 経験豊富なアナリストに依存 • ナレッジの共有が困難 • 人材育成に時間がかかる 課題点： 現状の作業フロー：
41. 解決策の第一候補：生成 AI との連携 生成 AI と Splunk を連携させた詳細な脅威分析を試行 期待される効果 分析の標準化 • AI が一定の観点で網羅的に分析を実施 • アナリストのスキルレベルによる品質のばらつきを軽減 作業時間の短縮 • SPL の自動生成により、クエリ作成時間を削減 • 複数の調査項目を並行して実行 分析観点の拡充 • 人間が見落としがちな観点も AI が提示 • 過去の類似ケースとの比較分析 ナレッジの蓄積 • AI が生成した SPL や分析ロジックを組織のナレッジとして蓄積 • 人材教育の教材としても活用可能 優先度 高 高 中 低
42. 3. 具体的な構成とアーキテクチャ
43. Splunk Cloud アーキテクチャ AWS Cloud アナリスト アウトプット 出力先 MCP サーバ Splunk Search Head , Indexer Local PC Script Amazon GuardDuty AWS CloudTrail Kiro Claude Opus 4.5 0. CloudTrailのログをSplunk で保管 1. 脅威検知 (Finding ID) は Slack に通知 2. Finding ID を引数にスクリプト実行 3. 詳細脅威情報の取得 4. 生成 AI で分析、 SPL の作成 5. CloudTrail 分析部分のみ Splunk MCP 連携 6. MCP 経由でクエリ実行 7. 分析結果を出力 8. 分析結果をベース に脅威を判断 Kiro CLIエージェント MCP（Model Context Protocol） Amazon Q Developer CLI は 2025 年 11 月 17 日に Kiro CLI にリブランドされました
44. アーキテクチャ コンポーネント 詳細 Kiro CLI （CLI エージェント機能） サブスクリプション: Pro プラン（Amazon Q Developer サブスクリプションを継続利用） 基盤モデル: Claude Opus 4.5 役割: ユーザーの自然言語による指示を理解し、適切なツールを呼び出して分析を実行 Splunk Cloud サブスクリプション: 標準サブスクリプション 役割: セキュリティログの集約・保管・検索基盤 Splunk Cloud MCP サーバ プロトコル: Model Context Protocol (MCP) 役割: Kiro CLI と Splunk Search Head の橋渡し 機能: SPL クエリの実行、結果の取得、Splunk 環境の情報取得 設定方法: 公式ドキュメントを参照 統合制御スクリプト GuardDuty Findings ID を入力として受け取る Kiro CLI を呼び出し、分析を指示 分析結果を整形して出力 $19/月・ユーザー ( 2026 年 5 月時点) Amazon Q Developer CLI は 2025 年 11 月 17 日に Kiro CLI にリブランドされました
45. スクリプトでの実装 • 統合制御スクリプトは、GuardDuty Findings ID を起点に、Kiro を介して Splunk へのクエリ実行と 結果分析を自動化。 • 各コンポーネント間の連携により、人手を介さずに包括的な脅威分析レポートを生成。 アウトプット（一部）： GuardDuty Findings の詳細情報（JSON 形式） • Finding Type、Severity、リソース情報、検知時刻など 詳細分析レポート（Markdown 形式） • エグゼクティブサマリー（重要な発見、緊急対応の要否判断、推奨アクション） • 脅威の概要と詳細（攻撃手法、時系列分析、影響範囲） • プリンシパル情報（操作者特定、AssumeRole の逆引き、権限情報） • 異常性分析（時間帯・地理的・操作パターン・認証チェーンの異常性） • リスク評価（総合リスクレベル、誤検知の可能性） • 詳細調査結果（ユーザー特定、追加調査項目、フォレンジック手順） • 推奨対応策（緊急度別の対応、具体的な確認コマンド） など 実行された SPL クエリ一覧 • AI が生成・実行した SPL を記録 • クエリ結果は含まない（機密性の観点から） • 後から手動で再実行可能
46. 技術的なポイント Splunk Cloud MCP （Model Context Protocol）サーバの重要性： • 2025 年 7 月頃にリリースされたことで、生成 AI と Splunk の連携が飛躍的に容易になった • これが本ソリューションの実現における最大の技術的ブレークスルー • MCP により、様々な AI クライアント（Kiro CLI 、Claude Desktop など）が 標準化された方法で Splunk と対話可能に 適用可能な環境： • Splunk Cloud または Splunk Enterprise にログを保管している環境であれば適用可能 • 特に CloudTrail のような構造化ログを大量に保管している環境で効果を発揮 • 既存の Splunk 投資を活かしながら、AI 活用を推進できる
47. 4. 実践事例と効果測定
48. 現在の運用状況 • 実運用環境で使用中 • 完全な自動化ではなく、アナリストの判断を支援する ツールとして位置づけ
49. KTC での実運用例 シナリオ：GuardDuty が AnomalousBehavior を検知 従来の方法（手動分析） • 所要時間：30 分〜 1 時間 • アナリストが SPL を複数回作成・実行 • 調査観点の漏れが発生する可能性れが 発生する可能性 AI 連携後（半自動分析） • 所要時間：10 分〜 15 分 • Findings ID を入力するだけで包括的な分析レポートを取得 • 標準化された観点で網羅的に調査 • アナリストは結果の評価と最終判断に集中 評価項目 効果 初期分析時間 約 70% 削減 分析観点の網羅性 向上 分析品質 経験の浅いアナリストでも一定品質の分析が可能に
50. 実際の分析レポート例（一部）1/5
51. 実際の分析レポート例（一部）2/5
52. 実際の分析レポート例（一部）3/5
53. 実際の分析レポート例（一部）4/5
54. 実際の分析レポート例（一部）5/5
55. 5. 2026 年 3 月までの課題 Updated
56. 2026 年 3 月までの課題 ① 生成 AI への権限委譲とアクセス制御 ② 生成 AI による分析の精度と信頼性 ③ Splunk MCP サーバが短期認証に未対応
57. ①生成 AI への権限委譲とアクセス制御 生成 AI が自律的に SPL を生成・実行する仕組み上、以下の課題が存在： • AI の動作を信頼せざるを得ない構造となっている • プロンプトや制約条件である程度の制限は可能だが、実行されるクエリの詳細を事前に完全にコントロール することは困難 • 意図しない範囲のデータへのアクセスや、想定外のクエリ実行のリスクが存在 Splunk 側の権限 管理における 注意点 • MCP 接続用の Splunk ユーザーには最小限の権限のみを付与する必要があるが、 分析の柔軟性確保とのバランスが難しい • インデックスレベル、ロールベースでのアクセス制御を適切に設計し、機密性の 高いログへの不要なアクセスを防ぐ必要がある • 定期的な権限の見直しと、実行されたクエリの監査ログ確認が重要 • 現在、Kiro 側で SPL クエリのログを保存し、事後的に監査可能な体制を構築済み
58. ②生成 AI による分析の精度と信頼性 生成 AI を活用した分析には、以下の制約がある： 1. SPL 生成の不確実性: 意図しない SPL を生成するケースがあり、生成された SPL の妥当性を人間が確認する必要がある 2. ハルシネーションのリスク: 生成 AI にはハルシネーション（幻覚）やミスインフォメーション（誤情報）が存在する 3. 利用範囲の制限: 生成されたレポートは参考情報として扱い、法的証拠やコンプライアンス監査の エビデンスとしては使用できない 4. 人間の判断が必須: 最終的な判断は必ず人間のアナリストが実施し、AI はあくまで作業効率化ツールとしての位置づけ
59. 誤情報の例 1/2 操作者の特定を誤ったケース • 同じ時間帯 • 同じIPアドレス • 同じ権限に昇格 プロンプトを修正し、再度分析した結果 A B A B
60. 誤情報の例 2/2 操作者の特定を誤ったケース • 同じ時間帯 • 同じIPアドレス • 同じ権限に昇格 プロンプトを修正し、再度分析した結果 A B
61. ②生成 AI による分析の精度と信頼性 生成 AI を活用した分析には、以下の制約がある： 1. SPL 生成の不確実性: 意図しない SPL を生成するケースがあり、生成された SPL の妥当性を人間が確認する必要がある 2. ハルシネーションのリスク: 生成 AI にはハルシネーション（幻覚）やミスインフォメーション（誤情報）が存在する 3. 利用範囲の制限: 生成されたレポートは参考情報として扱い、法的証拠やコンプライアンス監査の エビデンスとしては使用できない 4. 人間の判断が必須: 最終的な判断は必ず人間のアナリストが実施し、AI はあくまで作業効率化ツールとしての位置づけ AI エージェント化！ ※後述 New
62. ③Splunk MCP サーバが短期認証に未対応 • 2026 年 3 月時点では、Splunk MCP サーバは、短期認証（SAML/OIDC） に対応しておらず、静的トークンによる長期認証のみとなっている • MCP 接続用に個別のユーザーを作成してトークンを払い出す必要があり、 トークンの漏洩リスクやローテーション運用など、セキュリティポリシー 上の懸念がある • 今後の Splunk MCP サーバのアップデートにおける SAML/OIDC 認証対応 に期待したい
63. ③Splunk MCP サーバが短期認証に未対応 • 2025 年 10 月時点では、Splunk MCP サーバは、短期認証 （SAML/OIDC）に対応しておらず、静的トークンによる長期認証のみと なっている • MCP 接続用に個別のユーザーを作成してトークンを払い出す必要があり、 トークンの漏洩リスクやローテーション運用など、セキュリティポリシー 上の懸念がある • 今後の Splunk MCP サーバのアップデートにおけるSAML/OIDC認証対応 に期待したい Splunk MCP が OIDC に対応！ ※後述 New
64. 6. 2026 年 5 月時点での取り組み New
65. AI エージェント化 (アーキテクチャ) • 統合制御スクリプトは、詳細分析のために残す • Slack へのアラート通知をトリガーに、AI エージェントでログ分析 Splunk Cloud AWS Cloud アナリスト MCP サーバ Splunk Search Head , Indexer Amazon GuardDuty AWS CloudTrail 1. 脅威検知 (Finding ID) は Slack に通知 4. 生成 AI で分析、 SPL の作成 5. Splunk MCP 連携 6. MCP 経由でクエリ実行 MCP（Model Context Protocol） Slack 通知 チャン ネル Amazon Bedrock AgentCore フロントエンド 処理 0. CloudTrailのログをSplunk で保管 AWS CloudWatch Logs 2. トリガー 3. 詳細情報の取得 7. 分析結果を通知 8. 判断 概略図 New
66. AI エージェント化 (利用イメージ) New
67. AI エージェント化 (利用イメージ) New
68. AI エージェント化 (Google Cloud にも対応) New
69. Splunk MCP が OIDC に対応 4 月 1 日にリリースされた MCP Server for Splunk platform (v1.1) にて、 Beta preview: OAuth for MCP Server（クローズドプレビュー）が実装 前提条件 • Splunk Cloud Platform • MCP Server version 1.1.0 以上 • Splunk Cloud Platform バージョン 10.3 ポイント • Splunk Cloud Platformバージョン 10.3.2512.11 以上が必要 • 10.3.2512.11 以前のバージョンでは、OAuth を有効化可能で あるが、不具合の影響で MCP クライアントとの通信不可 （Issue Number : SPL-302006） New
70. Splunk MCP が OIDC に対応 Beta 免責事項 • SLA・サポート・メンテナンスなし • Splunk の裁量でいつでも廃止される可能性あり • 利用は Splunk Pre-Release Agreement for Hosted Services に準拠 クローズド プレビュー 参加手順 • Splunk サポートへ依頼 • Splunk Cloud Platform バージョン 10.3 へのアップグレード • OAuth for MCP Server (Beta preview) の有効化 New
71. KTC における OIDC 対応のタイムライン Date アクション 状況 4月8日 MCP Server App を v1.1.0 にアップデート 完了 4月8日 Splunk サポートチケット作成 完了 4月13日 Splunk Cloud Platform 10.3 アップグレード（10.3.2512.9） 完了 4月17日 10.3.2512.9 での問題をサポートから連絡をもらう （5月上旬パッチリリース見込み） 完了 5月14日 サポートから 10.3.2512.11 へのパッチ適用メンテナンス 連絡をもらう（5 月 26 日適用） 完了 5月26日 10.3.2512.11 のパッチ適用予定 待機中 5月XX日 OAuth 有効化 待機中 5月XX日 OAuth 設定およびテスト開始 待機中 New
72. 7. 本章のまとめ
73. 本章のまとめ 1. Splunk Cloud MCP サーバの登場 2025 年 7 月のリリースにより、生成 AI と Splunk の連携が現実的に 2. 既存資産の活用 Splunk にログを保管している環境であれば、追加投資を最小限に導入可能 3. 段階的な適用 完全自動化ではなく、人間の判断を支援するツールとして位置づけ 4. 実運用での検証 実際のセキュリティオペレーションで効果を確認しながら改善
74. 取り込みログフィルタリング の実践
75. 1. 取り込みログ量の課題
76. 取り込みログ量の課題 大規模 AWS アカウントの CloudTrail ログによる Splunk Cloud ライセンス容量 ひっ迫 特定の AWS アカウントの CloudTrail ログが大きく取り込みログの容量を占めている。 12.4GB 11.1GB 12.5GB 12.7GB 12.5GB 12.2GB 10.9GB
77. 2. 対応
78. 対応方針と実施ステップ 【対応方針】 • 劇的な削減効果を目指す • セキュリティインシデント検知能力は維持する 【実施ステップ】 1. ログ分析: CloudTrail イベントの発生頻度とアクション内容を調査 2. 除外条件の決定: セキュリティリスクを評価し、フィルタリング対象を選定 3. 正規表現ルール作成: Ingest Actions 用のフィルタリングルールを作成・テスト 4. ルール適用: Splunk Cloud コンソールから Ingest Actions に設定を実装 5. 効果測定: フィルタリング前後のログ量とコスト削減効果を検証
79. 対策と手法 • 対策: Ingest Actions によるログフィルタリング（セキュリティレベル維持） • 手法: 生成 AI × Splunk MCP サーバによる高速な分析・実装 既存のアプローチ 内容 手作業でのログ分析 数百万件のログを手動で分析 複雑な SPL クエリ作成 Splunk 専門知識が必要 正規表現の試行錯誤 フィルタリングルール作成に時間 効果測定の手間 施策前後の比較分析が煩雑 生成AIの活用 内容 自然言語でのログ分析 「どのイベントが多いか調査して」 自動 SPL クエリ生成 AI が Splunk クエリを自動生成・実行 正規表現の高速試行錯誤 エラーを即座にフィードバックし 改善を繰り返す リアルタイム効果測定 施策前後の比較を自動化
80. 対応結果 16時に Ingest Actions 設定 12.4GB 11.1GB 11.1GB 12.4GB 10.2GB 4.7GB 5.3GB 【効果測定】 施策前: 6,610,000 イベント/日 施策後: 2,733,699 イベント/日 削減率: 58.6 % 金 土 日 月 水（祝） 火 木 CloudTrail ログの Splunk 取り込み量推移（対象アカウント）
81. 3. 本章のまとめ
82. 本章のまとめ 生成 AI × Splunk MCP の組み合わせにより、従来は専門家しかできなかった 高度な分析・最適化作業が、対話しながら・短時間で・多くの試行を通じて 実施可能 • 生成 AI は「全自動」ではなく「高速な試行錯誤のパートナー」 • エラーが発生しても、即座にフィードバックし改善できる • 短時間で多くのパターンを試せることが最大の価値 • 専門知識は軽減されるが、ゴールへの方向性は人間が示す必要がある