この記事は、SASE・ゼロトラストの実装を担当するエンジニアや情報システム担当者が、AIエージェント・SaaS利用増加に対応したログ設計と可観測性の構成を具体的に進めるための手順を扱います。「なぜSASEを先に見直すべきか」という方針と判断の整理は、姉妹記事のAI導入前にSASE・ゼロトラストを見直す理由を先に読むことをお勧めします。
AIエージェント環境で可観測性が壊れる理由
従来のネットワーク監視は「人間のユーザーが何をしたか」を追うことを前提にしていました。しかしAIエージェントは、承認されたIDを使いながら、人間より速く・広く・自動で複数システムにアクセスします。
NIST SP 800-207A（クラウドネイティブ環境のゼロトラストアーキテクチャ、2023年）は、クラウド・マルチSaaS環境では「サービス間トラフィックの可観測性」を別途設計しなければ、アクセスポリシーの有効性を検証できないと指摘しています。つまり、SASEを入れただけではエージェントの動作を追えない環境が生まれます。
具体的には次のケースで可観測性が壊れます。
- AIエージェントのIDがユーザーIDと区別されていない（誰の操作か判別できない）
- SaaS側のログとIDPのログが別の場所に散らばっている（突合できない）
- ネットワークログにはURLが残るが、操作の結果（何を参照・変更したか）が残らない
- アラートは出るが、対応担当者が決まっておらず誰も確認しない
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
情シス部門の稟議書作成をサポートする無料の30分壁打ち。ROI 試算シート・失敗要因チェックリストをその場で共有します。
設計の前に決める3つの「ログ要件」
ツールを選ぶ前に、ログに関する要件を以下の形式で文書化します。
| ログ要件項目 | 決める内容 | 例 |
|---|---|---|
| 何を記録するか | 操作種別（参照・変更・削除・送信）、対象リソース、AIエージェントのID | 「顧客データへの参照・変更はすべて記録」 |
| 誰が見られるか | ログ閲覧権限の付与基準（情シス・監査・外部委託先） | 「情シスと内部監査のみ閲覧可能。委託先は除外」 |
| 何か月保存するか | 保存期間と削除手順（法令要件・契約要件を確認） | 「個人情報を含むログは1年保存、削除は承認制」 |
この3点が決まらないまま製品選定に入ると、導入後に設定変更が必要になり、証跡の連続性が失われます。
SASEとIDプロバイダーをログでつなぐ構成
一般的な構成では、SASE（SWG/CASB）・IDプロバイダー（IDP）・SIEMを別々に入れながら、ログを連携させずに運用するケースが多くあります。これでは「誰が・どの端末から・どのSaaSへ・何をしたか」が1箇所で見えません。
推奨する統合の考え方を以下の表で示します。
| ログソース | 取れる情報 | 連携先 | 連携する理由 |
|---|---|---|---|
| IDプロバイダー（IDP）ログ | 認証・認可・MFA失敗・権限変更 | SIEM | 「誰が」の軸になる |
| SASE（SWG/CASB）ログ | アクセス先URL・通信量・ブロック記録 | SIEM | 「どこへ」「何を通じて」の軸 |
| SaaSアクティビティログ | ファイル操作・共有・ダウンロード | SIEM | 「何をしたか」の結果の軸 |
| エンドポイント（MDM）ログ | 端末状態・OS更新・アプリ起動 | SIEM | 「どの端末から」の軸 |
| AIエージェント実行ログ | エージェントID・呼び出したAPI・実行結果 | SIEM | 「AIが何をしたか」の軸（追加必須） |
SIEMにすべてを集約することが必須ではありませんが、少なくともIDP＋SASE＋主要SaaSのログを相関検索できる状態を作ることが目標です。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
AIエージェント用IDの設計原則
AIエージェントに対してユーザーと同じIDを使うことは避けます。エージェントが起こした操作とユーザーが起こした操作を区別できなくなるためです。
推奨する設計原則：
- サービスアカウントを個別に発行する：エージェントごとに専用のサービスアカウントを作成し、最小限の権限のみを付与します。
- 人間のIDとは別グループに分類する：IDPでエージェント用グループを作り、監査ポリシーを分けます。
- 有効期間付きのトークンを使う：無期限の認証情報を避け、短期間で失効するトークン（例：OAuth 2.0のクライアントクレデンシャルズフロー）を採用します。
- エージェントの操作範囲をAPIレベルで制限する：広いスコープを与えず、エージェントが呼び出す必要のあるAPIのみに絞ります。
- エージェントIDのログを人間IDのログと別のダッシュボードで監視する：意図しない動作を素早く検知するためです。
ログ設計でよくある4つの失敗
1. 「ログを取る」と「ログを見る」が分離している
ログは残っているが、誰も定期的に確認しない。アラートが出ても担当者が決まっていない。これはログがないことと実質同じです。週次または月次でのログレビュー担当者と確認項目を設計段階で決めます。
2. SaaSのアクティビティログを有効化していない
Microsoft 365の監査ログ、Google WorkspaceのAlert Center、Salesforceのイベント監視など、SaaS側のアクティビティログは初期設定で無効になっていることがあります。AIに接続するSaaSは優先して有効化します。
3. ログの保存先がSaaS側のみで、退会・解約時に消える
ログの保存場所が各SaaSのダッシュボードだけの場合、契約終了時にアクセス不能になります。重要なログは自社管理のストレージまたはSIEMへエクスポートする設定を入れます。
4. 例外承認の記録がない
特定のIPやユーザーをポリシーの例外にする場合、その承認記録が残っていないと、後の監査で説明できません。変更管理台帳に例外の理由・承認者・有効期限を記録します。
SASE統合後の運用設計チェックリスト
SASE製品を導入した後、以下の設計が完了しているかを確認します。
| 項目 | 確認内容 | 合格の状態 |
|---|---|---|
| ポリシー台帳 | アクセスポリシーとその変更履歴が文書化されている | 変更のたびに承認者と理由が記録されている |
| 例外管理 | 例外ルールの件数・理由・有効期限が管理されている | 半年以内に見直しが行われている |
| ログレビュー | 誰が何の頻度でログを確認するか決まっている | 月次レポートと四半期の傾向分析が実施されている |
| インシデント対応 | 異常検知時の対応フローと連絡先が文書化されている | 連絡先が現在の担当者名で更新されている |
| 教育 | 利用者向けの禁止事項と相談先の案内がある | 入社時研修と年次更新研修が実施されている |
| コスト管理 | 部門別・ユーザー別の利用量と費用が可視化されている | 月次で上限超過アラートが設定されている |
GXOはどう支援するか
GXOでは、SASE製品の設定支援だけでなく、IDプロバイダー・SaaS・エンドポイントのログを統合して「何が起きているか見える状態」にする設計から支援します。AIエージェントのID設計、ログ保存要件の整理、SIEMへの統合設計、運用フローの文書化まで、実装と運用が両立する形で進めます。OTセキュリティや工場環境でのログ設計が必要な場合も、専門チームが対応します。
よくある質問
Q1. SIEMは小規模組織でも必要ですか
SIEMのフル導入は不要ですが、IDPとSASEのログを一箇所で検索できる環境は最低限必要です。Microsoft SentinelやSplunk Cloudのライトプランから始める選択肢もあります。
Q2. AIエージェントのログはどこに残りますか
エージェントが呼び出すAPIのアクセスログはAPIゲートウェイまたは各SaaSのアクティビティログに残ります。エージェント実行基盤（LangChain, Vertex AI等）にも独自の実行ログがあります。これらを統合する設計が必要です。
Q3. ログ設計の前に何から始めればよいですか
まず「今、社内のどこにどんなログが存在するか」を棚卸しします。次に、インシデント発生時に必要になる情報（誰が・何を・いつ・どこで）を洗い出し、そのために不足しているログを特定します。
参考情報
- NIST SP 800-207「Zero Trust Architecture」（2020年8月）：https://csrc.nist.gov/pubs/sp/800/207/final
- NIST SP 800-207A「ZTAモデル（クラウドネイティブ）」（2023年）：https://csrc.nist.gov/pubs/sp/800/207/a/final
- IPA「情報セキュリティ10大脅威 2026」：https://www.ipa.go.jp/security/10threats/10threats2026.html
AIエージェント対応のログ設計・SASE統合を進めませんか
GXOでは、ID・SASE・SaaS・エンドポイントのログを統合した可観測性の設計から、SIEM連携・運用フロー文書化まで実装を支援します。