本稿に記載した内容は、個人的な見解を示したものであり、筆者の所属する企業・団体の公式見解ではありません。
背景とねらい
セキュリティ運用では、必要なログを素早く探せるかどうかが初動対応のスピードを左右します。
そこで今回は、Palo Alto Networks の PAN-OS API を活用し、MCP（Model Context Protocol）サーバーとしてログ検索機能を作成してみました。
仕組みはシンプルで、PAN-OS の XML API（ジョブ方式） を使い、traffic や threat などのログを直接取得します。
MCPクライアント（ChatGPTやGemini CLIなど）とつなぐことで、自然言語で「このユーザーの接続ログを見たい」と投げると、そのまま結果が返る環境になります。
アーキテクチャ
本プロジェクトは、PAN-OS / Panorama のログを API 経由で取得・検索する MCP（Model Context Protocol）ツールサーバー です。
ちょっと使ってみた
まずはログを検索して、Gemini CLIが不審だと判断したIPアドレスを教えてもらいます。
返答としてIPアドレス3つを教えてくれました。PaloAltoのローカルに保存されているThreatログを抽出してきているようです。推奨事項まで教えてくれてて親切ですね。
インシデント時の調査手順に倣ってGemini CLIが教えてくれた一番上の「172.x.x.x」の通信アプリケーションの傾向をサマリーしてもらいました。500件のログを見てくださいと指示をしました。表形式で非常に見やすく整理してくれています。
このように、インシデントの際に「自然言語で」調査を進められることは非常に有益だと感じました。
ちょっと使ってみた感想
実際に触ってみると、会話でログを取りに行ける体験は想像以上に便利でした。
例えば「172.x.x.xの直近500件のアプリケーションの利用傾向を見せて」と投げると、表形式などにまとめて返してくれます。普段なら PaloAlto の管理コンソールで条件を指定するところが、1ステップで済むのは大きいです。
ただし、現状では動作確認にとどまっているため、本格的な調査の際に有用化は評価していません。Gemini 2.5 ProなどのThinkingによって計画されたインシデント調査計画がどれほど有用なものになるか、今後検証してみたいと思います。
注意点と制約
実際に試して気づいたポイントは次の通りです。
- セキュリティの懸念点：現状ではAPIキーをgemini CLIに埋め込んでいるので、ロール管理や管理方法の抜本的な是正が必要。
- 自己署名証明書の許容は検証環境だけ：現在は証明書認証をオフにして運用しているため、管理が必要。
- ログスキーマは装置やバージョンで差異があるため、返却フィールドが毎回同じとは限らない。
- 大量リクエストは避ける：負荷やレート制限の観点から、一度に大規模な取得は推奨されない。
PoCには十分活用できますが、実運用では制約を踏まえた設計が必要だと感じました。
今後の課題と展望
今回のMCPサーバーは「とりあえずログを引ける」レベルにはなりましたが、まだ課題もあります。
- 可視化の不足：グラフ化や要約がないため、JSONを直接読む必要がある
- 検索の自然言語対応：クエリ式をAIが裏で変換してくれるとさらに便利
- 運用連携：SlackやTeamsにそのまま出力できるとSOC運用が加速
- フィルタのテンプレート化：よく使う検索式をプリセット登録できると楽
- インシデント調査計画の立案：インシデント調査全てを丸投げしたい
- SIEMとの連携：PaloAlto Firewallだけではなく、SIEMなどと連携して統合ログ調査がしたい
まとめ
- PAN-OS APIをMCPサーバー化してAIからログを検索してみた
- 「聞けばそのまま返ってくる」体験は運用効率を高める可能性がある
今後は可視化や通知連携を追加し、“現場で本当に使える”ツールに進化させていければと思います。いずれScriptなども公開していこうと考えています。
- 本記事は権限のある検証環境で、公開仕様（Published Specifications）に基づき確認した内容です。スクリーンショットやログはダミー化・マスキングしています。
- 性能ベンチマークや比較評価の公表は行っていません。数値は必要に応じて公式資料を参照ください。
- 製品名・サービス名は各社の商標です。ロゴ等の転載は行っていません。本記事は提携・後援を意味しません。
- 本検証は評価ライセンスで実施しました。評価条件・期間はベンダー規約に従います。