この記事は、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分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
設計の前に決める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セキュリティや工場環境でのログ設計が必要な場合も、専門チームが対応します。
GXOの見解
AI導入はツール追加ではなく、業務フロー、権限、ログ、停止条件、責任分界を同時に設計する経営課題として扱う。
GXOはPoC単体ではなく、現場業務に残る承認、例外処理、監査証跡まで見て本番運用に落とすべきだと見る。
GXOは、AI活用の構想整理から要件定義、社内ルール、システム連携、運用改善まで一気通貫で支援します。
実務判断のポイント
この記事を読むべきなのは、経営者、DX責任者、情シス、開発責任者です。単に情報を把握するだけでなく、AI導入前の業務棚卸し、権限設計、PoC、本番運用、AI利用規程の相談に進めるべきかを判断するための材料として整理する必要があります。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。SASE・ID・ログをつなぐ可観測性の設計｜AIエージェント時代の実装手順に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの実務補足
AI導入はツール追加ではなく、業務フロー、権限、ログ、停止条件、責任分界を同時に設計する経営課題として扱う。
GXOはPoC単体ではなく、現場業務に残る承認、例外処理、監査証跡まで見て本番運用に落とすべきだと見る。
GXOは、AI活用の構想整理から要件定義、社内ルール、システム連携、運用改善まで一気通貫で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、AIアセスメント、PoC、業務システム連携、AIエージェント運用設計へ接続。さらに、診断テンプレートと標準設計を使い、短期診断から継続伴走へ展開。
相談につながる進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問
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連携・運用フロー文書化まで実装を支援します。
