AIエージェントサンドボックスの監査ログは、コマンドおよびプロセス実行、ファイルの読み取りと書き込み、外部ネットワーク呼び出しと出力先、パッケージインストールイベント、ツール呼び出し、セッションレベルのモデル入出力サマリー、リソース制限超過、セッションライフサイクルイベントをキャプチャする必要があります。このカバレッジがなければ、セキュリティチームはエージェントの行動を再構築したり、侵害を追跡したり、インシデント後のレビューに対応したりすることはできません。これらのカテゴリのいずれかにギャップがあると、事後的に埋めることが困難または不可能なブラインドスポットが生じます。
AIエージェントサンドボックスに異なる監査ログが必要な理由
従来のサーバー監査ログは、人間または決定論的なアプリケーションプロセスが各アクションをトリガーしたことを前提としています。AIエージェントはその前提を覆します。単一のプロンプトが、パッケージのインストール、ファイルの書き込み、シェルコマンドの実行、外部APIの呼び出し、サブプロセスの起動をすべて数秒以内に、個々のステップに対する人間の承認なしに引き起こす可能性があります。
これにより、監査ログが答えるべき質問が変わります。従来のサーバーでは、通常「承認されたユーザーがこのファイルを変更したか？」という質問になります。エージェントサンドボックスでは、質問は次のようになります。
- モデルは何を実行することを決定し、その順序は？
- どのシェルコマンドが実行され、どのプロセスとして実行されたか？
- エージェントは想定外のファイルにアクセスしたか？
- ネットワーク経由でサンドボックスから何が送信され、どこに送信されたか？
- パッケージのインストールによって予期しないコードが導入されたか？
- リソース制限に達したとき、または終了されたとき、エージェントは何をしていたか？
これらの質問に答えられるログシステムがあれば、セキュリティチームは必要な再構築能力を得られます。答えられないログシステムでは、インシデント対応は推測に頼ることになります。
コマンドおよびプロセス実行ログ
プロセス実行は最も優先度の高いカテゴリです。エージェントが実行するすべてのコマンド（シェルサブプロセスを介して直接的または間接的に）は、次の情報を含むログエントリを生成する必要があります：プロセス名と完全な引数リスト、親プロセスとPID、ユーザーと実効UID、作業ディレクトリ、サブ秒精度のタイムスタンプ、終了コード。
引数リストがないと、python、curl、bashなどのコマンドはインシデント後のトレースでほぼ意味をなしません。UIDがなければ、エージェントが昇格した権限で実行されたかどうかを判断できません。親PIDのチェーンがなければ、ネストされたサブプロセスを再構築したり、コマンドがどのように呼び出されたかを理解したりできません。
auditdなどのLinux監査サブシステムは、適切なシステムコールルール（execve、execveat）を使用して、マイクロVMゲスト内のカーネルレベルでこれをキャプチャできます。コンテナベースのサンドボックスは、代替手段としてeBPFベースのトレーシングやseccompログを使用できますが、各アプローチには異なるカバレッジとパフォーマンスのトレードオフがあります。セキュリティチームの観点から重要な要件は、ログがアプリケーション層より下で生成されることです。自分のログを制御するエージェントプロセスは、自身の動作を正確に報告するとは信頼できません。
ファイルシステムアクセスイベント
ファイルシステムの監査カバレッジは、読み取り、書き込み、削除、名前変更、マウント操作をログに記録する必要があります。各イベントについて、ログには次の情報を含める必要があります：操作タイプ、完全なパス、責任のあるプロセスとPID、UID、タイムスタンプ。
実際には、ビジーなサンドボックスでファイルの読み取りをすべてログに記録すると、大量のデータが生成される可能性があります。セキュリティチームは、多くの場合、これを重要なパスに絞り込みます。例えば、/etc、/root、エージェントのワークスペースディレクトリ、認証情報ファイルの場所、マウントされたシークレット以下の任意のパスです。書き込みと削除は、ほとんどの脅威モデルにおいて読み取りよりも優先度が高くなりますが、認証情報ファイルや設定ファイルの読み取りは、状況に関わらずキャプチャする価値があります。
ファイルシステムイベントは、データ流出の試み（大規模な読み取りの後に外部ネットワーク呼び出しが続く）、予期しない設定変更（エージェントが触れるべきでないファイルへの書き込み）、およびクリーンアップ動作（セッション終了時に実行される削除。アクティビティを隠そうとする試みを示す可能性がある）を特定するのに特に役立ちます。
外部ネットワーク呼び出しと出力ログ
出力ログは、エージェントサンドボックス展開において最も一般的に仕様が不十分な領域の1つです。多くのサンドボックスはネットワーク接続が試みられたことをログに記録しますが、どこに接続したか、どのプロトコルが使用されたか、成功したかどうかをログに記録するものははるかに少ないです。
完全な出力ログエントリには、次の情報を含める必要があります：宛先IPアドレスとポート、解決されたドメイン名（DNSクエリと応答）、プロトコル（TCP、UDP、HTTPなど）、各方向に転送されたバイト数、接続を開いたプロセス、UID、タイムスタンプ。
DNSクエリのログは特に重要です。予期しないドメインをクエリするエージェントは、後で接続がブロックされたとしても、キャプチャする価値のあるシグナルです。DNS over HTTPSは、サンドボックスがそれをインターセプトするレベルでネットワークポリシーを適用しない限り、クエリのログをバイパスする可能性があります。
許可リストベースの出力制御を提供するサンドボックスは、許可された接続試行とブロックされた接続試行の両方をログに記録する必要があります。予期しない宛先へのブロックされた接続試行が多数発生することは、それ自体が意味のあるセキュリティシグナルです。
パッケージインストールイベント
パッケージのインストールは、ランタイム環境をセッションの期間中持続する方法で変更し、後続の操作に影響を与える可能性があるため、高価値の監査ターゲットです。各インストールイベントは、次の情報をキャプチャする必要があります：呼び出されたパッケージマネージャー（pip、npm、apt、cargoなど）、パッケージ名、要求されたバージョン、解決されたバージョン、ソースURLまたはレジストリ、パッケージのハッシュまたはチェックサム、プロセスとUID、タイムスタンプ。
ソースURLは重要です。プライベートレジストリ、直接URL、または通常とは異なるミラーからインストールされたパッケージは、デフォルトのパブリックレジストリからインストールされたものとは異なるリスクプロファイルを持ちます。ハッシュはインシデント後の検証に重要です。後でパッケージが悪意のあるものと判明した場合、その特定のバージョンが特定のセッションでインストールされたかどうかを知る必要があります。
パッケージのインストールを完全にブロックするサンドボックスは、このリスクカテゴリを排除しますが、エージェントが実行できることも大幅に制限します。ほとんどの本番環境では、中間の道が必要です。すべてをログに記録し、承認されたソースリストからのインストールを許可し、未知のソースからのインストールにフラグを立てるかブロックします。
ツール呼び出しと結果
AIエージェントは通常、モデルが名前付きアクション（コードの実行、ファイルの読み取り、APIの呼び出し、ウェブ検索など）を要求し、オーケストレーション層がそれを実行するツール呼び出しメカニズムを通じて動作します。これらのツール呼び出しはOSレベルより上に位置し、アプリケーション層のイベントですが、システムレベルの結果だけでなくモデルの意図を表すため、ログに記録することが重要です。
ツール呼び出しログは、次の情報をキャプチャする必要があります：ツール名、入力パラメータの概要（シークレットやユーザーのPIIが含まれる場合は完全な内容ではない）、結果ステータスの概要（成功、エラー、タイムアウト）、セッションID、タイムスタンプ。
すべてのツール呼び出しの完全な入力と出力をログに記録することはデバッグに役立ちますが、プライバシーと秘密漏洩のリスクを生み出します。実用的なアプローチは、ツール名とステータスを無条件にログに記録し、入出力の概要を設定可能な詳細レベルでログに記録し、適切なアクセス制御の下で調査中に特定のセッションの詳細情報を取得する方法を提供することです。
目標は、ログストア自体が高価値のターゲットになることなく、エージェントのアクションシーケンスを再構築するのに十分なシグナルを提供することです。
セッションライフサイクルイベント
セッションライフサイクルイベントは、他のすべてのログエントリのアンカーとなります。すべてのイベントタイプに現れるセッションIDにより、ログをカテゴリ間で結合し、「この特定の実行で何が起こったか？」という質問に答えることが可能になります。
ログに記録するライフサイクルイベント：
| イベント | キーフィールド |
|---|---|
| セッション作成 | セッションID、ユーザー/テナントID、テンプレートまたはイメージ名、リソース設定、タイムスタンプ |
| セッション開始 | セッションID、ホスト識別子、割り当てられたリソース制限、タイムスタンプ |
| セッション一時停止 | セッションID、理由（API呼び出し、タイムアウト、自動一時停止）、タイムスタンプ |
| セッション再開 | セッションID、再開した主体、タイムスタンプ |
| セッション終了 | セッションID、終了理由（正常、タイムアウト、OOM、API呼び出し、ポリシー違反）、終了ステータス、タイムスタンプ |
| セッションクリーンアップ | セッションID、クリーンアップ時のファイルシステム状態（保持、削除、スナップショット保存）、タイムスタンプ |
終了理由は、インシデント後の調査で特に役立ちます。ポリシー違反、OOMキル、またはクリーンな終了以外の予期しないシグナルによって終了したセッションは、より詳細に調査する価値があります。一時停止され再開されたセッションは、状態の継続性について調査する価値があります。一時停止と再開の間に環境に何か変更があったかどうか。
リソース制限イベント
リソース制限イベントは、セッションが設定された上限に達し、システムがアクションを実行した瞬間をキャプチャします。これらのイベントは、通常の高負荷動作またはより懸念すべき状況（暴走プロセス、予期しない計算バースト、リソースを枯渇させようとする意図的な試み）のいずれかを示します。
リソース制限イベントのログエントリには、次の情報を含める必要があります：制限タイプ（CPUスロットル、メモリOOM、ディスククォータ、ネットワークレート制限、タイムアウト）、イベント発生時の測定値、設定された制限、実行されたアクション（スロットル、キル、警告）、影響を受けたプロセスまたはセッション、タイムスタンプ。
OOMキルは特に調査する価値があります。これは、エージェントが想定外の大規模な計算を試みたこと、予期しない大きなデータをロードしたパッケージ、またはメモリリークを示している可能性があります。軽量なLLM呼び出しのみを行うはずのセッションでのCPUスロットルイベントは、サンドボックス内で他の何かが実行されていることを示している可能性があります。
構造化ログと非構造化ログの形式
非構造化ログ（例：2026-06-29 10:04:00 INFO: process python startedのような自由形式のテキスト行）は読みやすいですが、クエリ、集約、SIEMやアラートパイプラインとの統合が困難です。監査目的では、ログ形式が変更されると解析が壊れる解析が必要になります。
構造化ログ（通常はJSON、またはCEF、OCSFなどの共通スキーマ形式）では、すべてのフィールドを直接インデックス化、クエリ、アラート設定できます。{"ts": "2026-06-29T10:04:00.123Z", "event": "process.exec", "session_id": "...", "pid": 1234, "ppid": 1, "uid": 0, "cmd": "curl", "args": ["-s", "https://..."], "exit_code": 0}のような構造化execveイベントは、その任意のフィールドで即座にクエリ可能です。
サンドボックスプロバイダーを評価するセキュリティチームにとって、重要な質問は次のとおりです。
- ログは構造化されていますか、それとも非構造化ですか？
- 使用されているスキーマまたは形式は何か、文書化されていますか？
- ログを外部のSIEMまたはログ集約システムにリアルタイムでストリーミングできますか？
- イベント発生からログストリームでの利用可能までのレイテンシはどのくらいですか？
リアルタイムまたは準リアルタイムのストリーミングは、検出ユースケースにとって重要です。セッション終了から数時間後にしか利用できないログは、インシデント再構築には役立ちますが、ライブアラートには役立ちません。
ログの整合性と改ざん防止
エージェントが変更できる監査ログは、監査ログではありません。これが改ざん防止要件です。ログは、エージェントプロセスが自身のエントリを変更、削除、または抑制できない方法で生成および保存される必要があります。
実装レベルでは、これは通常以下を意味します。
- サンドボックス内のアプリケーションレベルのログ記録ではなく、カーネルレベルのログ生成（監査サブシステム、eBPF）
- サンドボックスプロセスが到達できない外部宛先へのログの出荷
- サンドボックスネットワークからアクセス可能な削除APIのない、追記専用または1回書き込みのログストレージ
- 生成時に署名またはチェックサムされたログエントリ。これにより、事後的に改ざんや切り捨てが検出可能
管理されたサンドボックスプロバイダーの場合、関連する質問は、エージェントのプロセスがログ配信を変更するパスを持っているかどうかです。ログがサンドボックス内のファイルに書き込まれてから配信される場合、十分に特権を持つエージェントプロセスが配信に干渉する可能性があります。ログがハイパーバイザーまたはホストレベルで生成され、帯域外で配信される場合、エージェントはアクセスできません。
ログデータの保管チェーン（コンプライアンスや法的レビューにとって特に重要）には、ログ収集パス、ストレージアクセス制御、および生のイベントに適用される変換が文書化され、それ自体が監査可能である必要があります。
AIエージェントサンドボックス向け監査ログ保持ポリシー
AIエージェントサンドボックスの監査ログの保持要件は、規制環境、ワークロードのリスクプロファイル、およびセキュリティチームがサポートする必要があるインシデント対応のタイムラインに依存します。
セキュリティチームが評価するための実用的な出発点：
| ユースケース | 推奨される最低保持期間 |
|---|---|
| アクティブなインシデント調査 | ホット/クエリ可能で少なくとも90日間 |
| インシデント後のフォレンジック | コールドストレージで12～24ヶ月 |
| コンプライアンスレビュー（SOC 2、ISO 27001） | 該当するフレームワークの要件に従う |
| リーガルホールド | 明示的に解除されるまで |
AIエージェントワークロードの場合、90日間のホットストレージは意味のあるベースラインです。自律エージェントにおける侵害パターンはすぐには発見されない可能性があるためです。3週間前にセッション中にデータを流出させたエージェントが、後続の異常が気付かれるまで特定されない可能性があります。
容量は実際のコスト要因です。1日あたり数千のセッションを実行し、完全なexecveおよびネットワークログを記録するサンドボックスは、大量のデータを生成する可能性があります。階層型ストレージ（最近のデータはホット、中期はウォーム、アーカイブはコールド）は一般的なアプローチです。圧縮とフィールドレベルのフィルタリング（高優先度のイベントタイプのみを完全な忠実度でログに記録する）も検討に値しますが、フィルタリングされたログは予期しないイベントタイプを見逃す可能性があるというトレードオフがあります。
インシデント対応のためのログの活用
ログを収集することは必要ですが、十分ではありません。誰もクエリしないバケットに眠っているログは保護を提供しません。セキュリティチームにとって、運用上の要件は、特定の質問に迅速に答えられることです。
- セッションXは時間T1からT2の間に何をしたか？
- どのセッションがパスPにアクセスしたか？
- どのセッションがドメインDへの外部接続を行ったか？
- どのセッションがパッケージVをインストールしたか？
- どのセッションが理由Rで終了したか？
これには、セッションID、イベントタイプ、タイムスタンプ範囲、パス、ドメイン、その他のキーフィールドがインデックス化され検索可能なクエリインターフェース（SIEM統合、ログ分析プラットフォーム、またはプロバイダー提供のAPI）が必要です。
特定のパターンに関するアラート設定は第2のレイヤーです。AIエージェントサンドボックスにおける高優先度シグナルには、次のものがあります：既知の危険なコマンドの実行（curl | bash、wget -O - | sh、base64 -d | sh）、予期しないまたは新しく登録されたドメインへの外部接続、非レジストリURLからのパッケージインストール、認証情報ファイルパスへの書き込みイベント、ポリシー違反またはOOMキルで終了したセッション、エージェントがrootとして実行されるべきでない場合のUID 0でのイベント。
エージェントサンドボックスの動作パターンに合わせて調整された事前構築された検出ルールは、新しいアクティビティに対する初回アラートまでの時間を短縮します。サンドボックスプロバイダーを評価するセキュリティチームは、プロバイダーが検出ルール、ログスキーマのドキュメント、およびサンプルSIEM統合を提供しているかどうか、またはそのレイヤーの構築がすべて顧客に任されているかどうかを尋ねる必要があります。
サンドボックスプロバイダーに確認すべきこと
監査ログのカバレッジについてAIエージェントサンドボックスを評価する場合、プロバイダーに問い合わせる具体的な質問は次のとおりです。
- デフォルトでログに記録されるイベントカテゴリはどれか、また設定が必要なものはどれか？
- ログはカーネル/ハイパーバイザーレベルで生成されるか、それともサンドボックスプロセス内で生成されるか？
- 使用されている構造化ログ形式は何か、スキーマは公開文書化されているか？
- ログを外部の宛先にリアルタイムでストリーミングできるか？
- データ保持ポリシーはどのようになっているか、拡張は可能か？
- サンドボックスプロセスは自身のログエントリを変更または抑制するパスを持っているか？
- ログエントリは署名されているか、または何らかの形で改ざん防止が施されているか？
- クエリAPIまたはSIEM統合は利用可能か？
- 一般的なサンドボックス脅威パターンに対する事前構築された検出ルールまたはアラートテンプレートはあるか？
デフォルトでログ記録が完全なサンドボックス展開はありません。プロバイダーが収集するものと、セキュリティチームがインシデントを再構築するために必要なものとの間のギャップは一般的です。インシデント後ではなく、展開前にこれらのギャップを特定することが、この種の評価から得られる実用的なメリットです。
Novita Agent Sandboxは、APIを通じてアクセス可能なセッションライフサイクルイベント、実行ログ、リソースメトリクスを提供します。Novita Agent Sandboxを評価しているセキュリティチームは、アーキテクチャ上の決定を下す前に、製品ドキュメントで現在のログカバレッジ、エクスポートオプション、保持設定を確認する必要があります。
結論
AIエージェントサンドボックス向け監査ログは、インシデント後に後付けできる機能ではありません。重要なイベントカテゴリ（プロセス実行、ファイルシステムアクセス、出力トラフィック、パッケージインストール、ツール呼び出し、セッションライフサイクル、リソース制限）は、ワークロードが本番環境に投入される前に対象範囲に含まれている必要があり、ログ収集パスはエージェントの到達範囲外にある必要があります。
セキュリティチーム向けの実用的なチェックリストは簡単です。サンドボックスプロバイダーがデフォルトでキャプチャするイベントカテゴリを特定し、ログがエージェントプロセス内ではなくカーネルまたはハイパーバイザーレベルで生成されていることを確認し、SIEM統合用の構造化出力が利用可能であることを確認し、調査に必要になる前に保持ポリシーを確立します。
これらの領域のいずれかにギャップがあることは、「このエージェントは何をしたか？」という質問に答えられないギャップを意味します。そして、大規模に自律的に動作するエージェントにとって、その質問は最終的に答えを必要とするでしょう。
FAQ
AIエージェントサンドボックスの監査ログはどのようなイベントをキャプチャすべきですか？
最低限：コマンドおよびプロセス実行（完全な引数リスト付き）、ファイルシステムの読み取り/書き込み/削除、外部ネットワーク接続とDNSクエリ、パッケージインストールイベント（ソースURLとハッシュ付き）、ツール呼び出しと結果ステータス、セッションライフサイクルイベント（作成、一時停止、再開、終了、クリーンアップ）、およびリソース制限イベント（CPUスロットル、OOMキル、タイムアウト）。これらのカテゴリのいずれかが欠けていると、事後的に再構築できないブラインドスポットが生じます。
サンドボックス内のアプリケーションレベルのログ記録に依存できない理由は？
自身のログ記録を制御するエージェントプロセスは、意図的またはバグによって、自身の動作に関するエントリを抑制または変更できます。カーネルレベルの収集（auditd、eBPF、またはハイパーバイザーのインストルメンテーションを介して）は、エージェントが書き込みアクセスできないアプリケーション層より下でログエントリを生成します。これが改ざん防止要件です。ログはエージェントが到達できない場所で生成される必要があります。
AIエージェントサンドボックスの監査ログはどのくらいの期間保持すべきですか？
実用的なベースライン：アクティブな調査用にホットクエリ可能なストレージで90日間、インシデント後のフォレンジック用にコールドストレージで12〜24ヶ月。SOC 2やISO 27001などのコンプライアンスフレームワークには、これらのベースラインに優先する独自の要件がある場合があります。リーガルホールドの場合、法的な担当者によって明示的に解除されるまで保持を継続する必要があります。
構造化ログと非構造化ログの違いは何ですか？
非構造化ログは、クエリするために解析が必要な自由形式のテキスト行です。構造化ログは一貫したスキーマ（JSON、CEF、OCSF）を使用し、すべてのフィールドが直接インデックス化されクエリ可能です。セキュリティ運用では、構造化ログはSIEMプラットフォームとの統合、検出ルールの作成、インシデント対応時のクエリがはるかに容易です。
AIエージェントは自身の監査ログを改ざんできますか？
ログがどこで生成され、保存されるかに依存します。ログがサンドボックス内のファイルに書き込まれ、外部に出荷される場合、特権を持つエージェントプロセスが出荷パイプラインに干渉する可能性があります。ログがハイパーバイザーまたはホストレベルで生成され、サンドボックスネットワークが到達できない外部宛先に直接書き込まれる場合、エージェントにはログを変更するパスがありません。ログ形式だけでなく、ログ収集アーキテクチャを常に確認してください。
サンドボックスプロバイダーの監査ログドキュメントで何を確認すべきですか？
次の点を確認してください：デフォルトでログに記録されるイベントカテゴリと設定が必要なもの、ログがカーネル/ハイパーバイザーレベルかサンドボックスプロセス内か、使用されている構造化形式とスキーマ、外部システムへのリアルタイムストリーミングがサポートされているか、デフォルトの保持ポリシーと拡張の可否、事前構築された検出ルールやSIEM統合が利用可能かどうか。
