「見えない」AIインフラを可視化する：AIシステムのアーキテクチャと偵察（Reconnaissance）入門

Posted at 2026-04-23

はじめに

近年、企業のAI導入が急速に進んでいますが、その裏で「AI特有のインフラ」がセキュリティレビューをすり抜け、野良化しているケースが散見されます。

従来のWebアプリケーションのセキュリティスキャンは、80/443ポートや標準的なHTTPサービスを対象としていますが、AIインフラはこれらとは全く異なるポートやプロトコルを使用します。

本記事では、AIシステムを構成する主要なコンポーネントと、それらがどのように連携しているか（データフロー）、そしてそれらをどのように「偵察（監査）」すべきかを解説します。

AIシステムは単一のサーバーではなく、複数の専門サービスが連携する集合体です。まずは、偵察対象となる主要コンポーネントを整理しましょう。

コンポーネント	主な役割	よく使われるポート
Model Serving	モデルの推論API提供 (Triton, TorchServe)	8000, 8001, 8080
ML Orchestration	実験管理・モデルライフサイクル (MLflow)	5000
Vector DB	RAG用の知識検索 (Qdrant, Weaviate)	6333, 8080
Supporting Infra	ノートブック環境, オブジェクトストレージ	8888 (Jupyter), 9000 (MinIO)

これらがネットワーク上に分散して存在しており、標準的なスキャナからは「未知のサービス」として無視されることがよくあります。

AIシステムにおいて、各コンポーネントは高度に自動化されたパイプラインで繋がっています。この繋がりを知ることは、「どこか一箇所が侵害されると、どこまで被害が広がるか」　を評価するために不可欠です。

このフローの各ステップで、認証情報やモデルのアーキテクチャ情報がやり取りされています。

認証情報の伝搬: Jupyter のコード内に記述された S3 アクセスキーが MLflow に渡り、それがモデルのダウンロードに使われる、といった「憑依（Credential Reuse）」が頻発しています。
内部信頼: 多くのAIサービスは「内部ネットワークにあるから安全」という前提で設計されており、コンポーネント間の通信に mTLS 認証を設定していないケースが非常に多いです。

セキュリティエンジニアや開発者が、自身の管理するAIインフラを監査する場合、以下の手順を考慮すべきです。

標準的なスキャンではなく、AIインフラ固有のポートリスト（上記表参照）をターゲットにします。Nmapなどでポートが開いているか確認するだけでなく、返ってくるサービスバナーを観察します。

AIサービスは、意図的に詳細な情報を返すよう設計されていることが多いです。

もし以下のような状況があれば、直ちに修正が必要です。

AIインフラストラクチャの偵察は、攻撃者の手法を知ることから始まります。自分たちのシステムを「外から見たらどう見えるか」をシミュレートすることは、最も効果的な防御策です。

次にとるべきアクション:

AIの進化は速いですが、インフラの基本原則は変わりません。「どこに何があるか」を把握すること。これがAIセキュリティの第一歩です。