AIエージェントの動きをコンテナの外から記録するOSS「Azazel」の仕組みと導入前の注意点

「AIエージェントをコンテナの中で動かしているが、中で実際に何が起きたのかを後から確かめる手段がない」「怪しいファイルを調べたいが、動かしたときに何をするのかを安全に見る環境が社内にない」——AIエージェントの試験導入を進める開発部門と、それを見守るセキュリティ担当者の双方から聞こえてくる声です。こうした悩みには、エージェント自身に作業の記録を書かせれば足りると考えがちです。しかし、記録を書く側が誤ったり、だまされたりすれば、記録そのものが当てになりません。本当に必要なのは、見張られる側の外から、実際に起きた動きを記録する仕組みです。この記事では、コンテナの中の動きをLinuxの仕組みで外から記録するOSS「Azazel」を取り上げ、仕組み、記録できることとできないこと、動かすのに要る強い権限、導入前に決めておくべきことを整理します。導入や設定の手順は扱いません。

Azazelとは何か。2026年10月時点で確かめられる事実

Azazelは、GitHubで公開されているOSSです。リポジトリの説明では「コンテナで動く環境のための、eBPFを使った静かな観察者」とされ、マルウェア解析の隔離環境と、AIエージェントの見張りのために作られたと書かれています。READMEは、怪しい検体を隔離したコンテナに入れると、プログラムの呼び出し、ファイルへの接触、通信、不審な振る舞いをすべて捉え、整理された記録として渡す道具だと説明しています。

公開元は、Beelzebubという組織のアカウントです。このラインの精査を行った2026年10月20日時点で、リポジトリの作成は2026年2月14日、スターは110、派生は10でした。1日あたりのスターの伸びは約0.4件で、急に話題になったものではなく、少しずつ注目を集めている段階です。正式なリリースは2026年6月2日に出た1.0.0版が一つあり、主の枝で確認できる最後の変更は8月31日でした。

ライセンスはGPL-2.0で、READMEによると、Linuxの中心部分に差し込む見張りのプログラムと、それを操る側のプログラムの両方がこの条件で公開されています。GPL-2.0は改変して配る場合にソースの公開を求める条件なので、社内で使うだけか、改変して製品に組み込むかで、法務の確認の重さが変わる点は押さえておきます。動作の前提は、Linuxの5.8以降で、カーネルの型情報を出す設定が有効になっていることとされます。

なぜコンテナの「外」から見る仕組みが求められているのか

AIエージェントは、指示を受けてファイルを読み書きし、外部と通信し、ほかのプログラムを起動します。多くの現場では、こうしたエージェントを隔離のためにコンテナの中で動かしています。ところが、コンテナで隔離していても、その中で何が起きたかを記録していなければ、後から確かめようがありません。

エージェントの作業の記録は、多くの場合、エージェント自身や、それを動かす枠組みが書き出します。この記録は便利ですが、外から紛れ込んだ命令でエージェントがだまされた場合や、エージェントが呼んだ別のプログラムが勝手に動いた場合には、記録に残らない動きが生まれる可能性があります。中で動くものが書く記録は、中で動くものの影響を受けるからです。

Azazelが狙うのは、ここを外から補うことです。READMEは、自らを「目に見えない」記録の道具と位置づけ、コンテナの中のプログラムからは触れない層で動きを捉えるとしています。エージェント自身の記録と、外から取った記録を突き合わせられれば、エージェントが「やった」と言うことと、実際に起きたことの差に気づける可能性が生まれます。マルウェア解析でも、検体が自分の痕跡を消そうとする前提に立てば、同じ考え方が当てはまります。

仕組みの土台：Linuxの「eBPF」とは

Azazelの土台にあるeBPFは、Linuxの中心部分（カーネル）の中で、小さなプログラムを安全に動かすための仕組みです。eBPFの解説サイトによると、カーネルの元のコードを書き換えたり、追加の部品を読み込んだりせずに、カーネルの動きに見張りのプログラムを後から差し込めるのが特徴です。性能の調査、通信の制御、セキュリティの記録などに広く使われています。

差し込んだプログラムは、決められた出来事をきっかけに動きます。たとえば、あるプログラムがファイルを開こうとしたとき、通信を始めようとしたときに、その瞬間の情報を書き留められます。カーネルに受け入れる前には、検証の仕組みが、プログラムが必ず終わるか、決められた範囲の外の記憶を読まないかなどを確かめます。ただし同じ解説サイトは、この検証は安全のための確認であり、プログラムが何をするかの良し悪しを判断するものではないとも書いています。

もう一つ押さえておきたいのが、権限です。解説サイトによると、eBPFのプログラムを読み込めるのは、原則として管理者の権限か、それに近い特別な権限を持つものだけです。つまりAzazelのような道具は、仕組みのうえで、強い権限を持って動くことが前提になります。この点は後の注意点で改めて取り上げます。

何を記録するのか：四つの分類と19の観察点

READMEによると、Azazelが記録する出来事は四つの分類に分かれます。観察点は合わせて19か所で、プログラムがカーネルに処理を頼む入口に設けた見張りと、名前解決の通信を捉えるための見張り一つで構成されているとされます。

分類	記録する出来事	主な記録内容
プロセス	起動・終了・複製	起動したファイル名と引数、終了の符号、親のプロセス
ファイル	開く・読む・書く・削除・名前の変更	ファイルの場所、開き方、読み書きした量
通信	接続・待ち受け・受け付け・送信・名前解決	相手の住所（IPの番号）と番号の口
セキュリティ	書き込みと実行を同時に許す記憶領域の確保、他のプロセスの操作、カーネル部品の読み込み	コードの差し込みや、カーネルへの手出しの兆候

表のとおり、記録はプログラムの「行動」の単位です。どのコンテナで起きたかは、Linuxがプロセスをまとめて管理する仕組みの情報から割り出し、特定のコンテナだけに絞って記録できるとされています。解析したい検体の動きだけを取り出すための作りです。

一方で、READMEの記録項目の一覧には、通信の中身や、AIエージェントへの指示文、エージェントの思考の過程は含まれていません。どの宛先に接続したかは分かっても、何を送ったか、なぜ送ったかまでは、この記録だけでは分からないと考えるのが妥当です。

記録の形と、終了時のまとめ

READMEによると、記録は1件の出来事を1行のJSON形式で書き出します。各行には、時刻、出来事の種類、プロセスの番号、親のプロセスの番号、利用者の番号、コンテナの識別子などが入ります。この形式は、ElasticsearchやSplunk などの記録の集約基盤、あるいは自社の仕組みにそのまま流し込めることを意識したものだと説明されています。

記録を止めると、Azazelはまとめを出します。READMEの例では、出来事の総数、種類ごとの件数、そして見つかった警告の一覧が並びます。生の記録と、人が最初に目を通すためのまとめが分かれているので、まずまとめで当たりをつけ、気になる箇所を生の記録でたどる、という読み方ができます。

なおREADMEは、検体の指紋（ハッシュ値）、出来事の要約、通信先、警告をまとめた報告書を自動で作る補助の仕組みにも触れています。ただし、2026年10月20日にリポジトリの中身を確かめた範囲では、READMEが名前を挙げる補助の仕組みのファイルは、リポジトリの直下に見当たりませんでした。資料と中身が一致していない箇所がある点は、評価のときに念頭に置いておきます。

組み込みの「怪しい動き」の目印

Azazelには、記録の中から怪しい動きを自動で拾う目印が組み込まれています。READMEとソースコードを読むと、一時ファイルを置く場所からのプログラムの起動、ファイルの取得や通信、文字の変換に使われる道具の起動、パスワードの情報や管理者の権限の設定などを収めた重要なファイルへの接触が対象に含まれています。

ほかにも、書き込みと実行を同時に許す記憶領域の確保、他のプロセスを操作する機能の使用、カーネル部品の読み込み、重要な設定の置き場所へのファイルの書き込みなどが目印になっています。ソースコード上では、警告は情報・中・高・重大の四段階に分けられ、READMEの例では、書き込みと実行を同時に許す記憶領域の確保が最も重い段階として示されています。

ここで注意したいのは、これらが決まった場所や名前に当てはまるかどうかで判断する、単純な目印だという点です。たとえば通信の道具の起動は、正規の業務でもごく普通に起こります。AIエージェントの見張りに使えば、警告が大量に出ることも考えられます。警告はあくまで調べ始めるための手がかりであり、判定ではないと受け止めるべきです。

マルウェア解析の隔離環境としての作り

Azazelの第一の用途は、マルウェア解析の隔離環境です。1.0.0版の変更点の一覧には、検体を隔離したコンテナで動かして記録する機能の追加が含まれています。ソースコードによると、この機能は外部と通信できない設定のコンテナを用意し、検体を動かし、決めた時間で打ち切る作りで、既定の上限は30秒です。

リポジトリに含まれるDockerの構成ファイルにも、解析の環境の一式が書かれています。検体を動かす側のコンテナは、特別な権限を原則すべて外したうえで二つだけを残し、使える処理能力を1つ分、記憶容量を512メガバイトに制限し、外とつながらない内部だけのネットワークに置く設定です。検体の置き場所は読み取り専用で渡されます。

ただ、ここで押さえておくべきことがあります。コンテナは、同じ機械の上でカーネルを共有して動く仕組みです。一般に、コンテナの隔離は、仮想の機械を丸ごと分ける方法に比べて、境界が薄いとされます。本物のマルウェアを動かすなら、Azazelの設定だけに頼らず、解析専用の機械や、業務の網から切り離した環境を用意するのが安全側の考え方です。これはAzazelに限らず、コンテナで検体を扱うときに共通する注意点です。

AIエージェントの見張りという位置づけをどう読むか

READMEは冒頭で、Azazelが自律して動くAIエージェントの常時の見張りにも使えるとうたい、AIで扱いやすい記録を出すと書いています。しかし、2026年10月20日に確認した範囲では、AIエージェントの見張りに特化した機能や、具体的な使い方の説明はREADMEにありませんでした。記録の項目も、マルウェア解析と同じものです。

運営元の公式サイトでは、AzazelはBeelzebubの商用のマルウェア解析サービスであるCaronteの、振る舞いの解析を支えるOSSの隔離環境として紹介されています。つまり、出自はマルウェア解析の道具で、AIエージェントへの応用は「同じ記録の仕組みがエージェントにも使える」という位置づけだと読むのが自然です。

では、エージェントの見張りに役立たないのかというと、そうではありません。エージェントが動かすコンテナを外から記録すれば、どのファイルに触れ、どこへ接続し、何を起動したかの事実が残ります。ここからは推測ですが、エージェントの作業の記録と突き合わせる「裏付けの記録」として使うのが、確認できた機能の範囲に合った使い方だと考えられます。エージェントの意図や指示文の中身は見えないので、それを補う別の記録も要ります。

似た手段と何が違うのか

コンテナやエージェントの動きを記録する方法はほかにもあります。確認できた事実をもとに、どこで何を見るかの違いとして比べます。優劣ではなく、役割の違いとして読んでください。

見る点	エージェント自身の作業の記録	コンテナの中に置く記録の道具	Azazel
記録する場所	エージェントや枠組みの中	見張る対象と同じコンテナの中	コンテナの外（カーネルの層）
見えるもの	指示、道具の呼び出し、出力	道具によって異なる	起動・ファイル・通信・不審な操作
意図や指示文	見える	道具による	見えない
中から手を出されにくいか	影響を受けうる	影響を受けうる	中からは触れない層で動く（公開元の説明）
必要な権限	通常の権限	コンテナ内の権限	機械全体に及ぶ強い権限

表のとおり、Azazelの強みは、記録を取る場所が見張られる側の外にあることです。その代わりに、意図や指示文は見えず、動かすには機械全体に及ぶ強い権限が必要になります。エージェント自身の記録で「何をしようとしたか」を、Azazelで「実際に何が起きたか」を押さえる、という組み合わせが現実的でしょう。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。Azazelの判定は「紹介可」です。

根拠は次のとおりです。ライセンスはGPL-2.0で、利用の条件に独自の制限はありません。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。リポジトリの直下にあるのは、利用者が自分で使う作業用の設定ファイルや組み立ての定義で、取り込んだだけで自動的に動く処理は確認されませんでした。公開元の組織は2025年8月に作られたアカウントですが、同じ組織が公開するおとりの仕組みのOSSは2,200を超えるスターを集めており、運営元として一定の実績があります。スターの伸びも1日あたり約0.4件で、不自然な水増しの兆候は見られませんでした。

リポジトリには、依存する部品の更新を自動で提案する仕組みと、コードの弱点を自動で調べる仕組みが組み込まれていることも、設定ファイルから確かめられました。なお、勧告がないことや問題が見つからなかったことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。次の章以降で、紹介可でも押さえておくべき注意点を挙げます。

動かすために必要な強い権限と、その重さ

Azazelを評価するうえで最も重要なのが、見張り役に渡す権限です。READMEは、開発用のコンテナを特別な権限付きで、機械全体のプロセスの情報を共有した状態で動かすと説明しています。リポジトリのDockerの構成ファイルでも、記録を取る側のコンテナは、特別な権限を与え、機械全体のプロセスとネットワークを共有し、コンテナを管理する仕組みの窓口も渡す設定になっています。

これはeBPFの仕組み上、ある程度避けられないことです。機械全体を見渡すには、機械全体に及ぶ権限が要ります。ただし、その結果として、見張り役そのものが、その機械で最も強い権限を持つ部品の一つになることは理解しておく必要があります。コンテナを管理する仕組みの窓口は、構成ファイルでは読み取り専用の指定で渡されていますが、一般に、この指定は窓口を通じた操作そのものを制限するものではないとされます。

つまり、Azazelを動かす機械では、Azazelの組み立てに使った材料、Azazelを動かす人の権限、記録の置き場所の管理が、そのまま機械全体の守りに関わります。見張りの道具を入れることで、守るべき対象が一つ増えると考えておくのが安全側の見方です。

運営体制とセキュリティ方針の読み方

GitHubの記録では、Azazelのリポジトリに手を入れているのは、実質的に一人の開発者と、依存する部品の更新を自動で提案する仕組みだけです。変更の記録は47件で、そのうち半分近くが部品の更新の自動の提案によるものでした。開発の体制は小さく、一人の開発者に大きく依存していると言えます。

セキュリティ方針は、リポジトリ単体ではなく組織全体の共通の文書として置かれています。そこでは、弱点の報告は開発者の個人の電子メールの宛先で受け付け、48時間以内に返事をし、確認できれば早めに修正を出すとされています。ただし、この文書の「対応する版」の表は2.0.0版以上を対象としており、1.0.0版しかないAzazelにそのまま当てはまるのかは、文書からは読み取れません。おとりの仕組みの本体向けに書かれた文書が共通で使われている可能性があります。

READMEの中にも食い違いがあります。命令の一覧が二か所に載っていますが、一方には検体を隔離して動かす機能が載り、もう一方には載っていません。先に触れた補助の仕組みのファイルの件と合わせると、資料の更新が中身に追いついていない箇所があると考えられます。導入を検討するなら、READMEだけで判断せず、リポジトリの中身と照らして確かめることが必要です。

悪用されうるリスク

Azazelは守りと解析のための道具で、攻撃のための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「外から記録しているから、エージェントに広い権限を渡してよい」という安心が独り歩きすることです。Azazelは記録の道具で、危険な操作を止める機能はREADMEに書かれていません。記録は、起きたことを後から知る手段です。

次に挙げるのは推測ですが、検討の材料になります。Azazelの記録には、どのファイルを開いたか、どこへ接続したか、どんな引数でプログラムを起動したかが残ります。引数には、パスワードや鍵などの秘密の情報が紛れ込むことがあります。記録の置き場所が守られていなければ、見張りのための記録が、攻撃者にとって価値のある情報源になりえます。

もう一つは、強い権限で動く見張り役そのものが狙われる可能性です。仮にAzazelや、それを組み立てる材料に弱点が見つかれば、機械全体に影響が及ぶおそれがあります。また、マルウェアの解析で本物の検体を扱う場合、隔離の設定を誤れば、検体が解析の環境の外へ影響を与える危険もあります。なお、Azazelが実際に悪用された事例は、2026年10月20日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときに確かめること

検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、何を見張り、記録を誰がどう扱うかを、導入する側が先に決めることです。記録の道具は、読む人と読み方が決まっていなければ、記録を積み上げるだけになります。

企業が取るべき対策

一つ目は、権限の絞り込みを先に行うことです。Azazelを使うかどうかにかかわらず、AIエージェントに渡すファイルの範囲、通信先、使える道具を必要な範囲に絞ります。記録は、権限を絞ったうえに重ねるもので、広すぎる権限を記録で補うことはできません。

二つ目は、見張り役の置き場所の分離です。強い権限で動く見張り役は、業務の本番の機械と分けて置くのが基本です。マルウェアの解析に使うなら、解析専用の機械と、業務の網から切り離した環境を用意します。三つ目は、警告の運用です。組み込みの目印は単純なため、エージェントの見張りに使えば警告が多く出ることが考えられます。どの警告を誰が見るのか、見られる量に収める基準を決めることが大切です。

四つ目は、記録の扱いです。記録には秘密の情報が紛れ込みうるので、置き場所の守り、保存期間、見られる人を決めます。五つ目は、調達のときの確認です。開発体制が小さいこと、資料と中身に食い違いがあること、GPL-2.0の条件を踏まえ、社内で使える段階かどうかを文書で判断します。改変して社外に配る予定があるなら、法務の確認を先に済ませます。

AIに任せる範囲と、人が決める範囲

Azazelの記録は、1行1件のJSON形式で、AIに読ませやすい形をしています。READMEも、AIで扱いやすい記録であることをうたっています。だからこそ、記録の読み取りをAIに任せるとしても、AIに判断させない部分を先に決める必要があります。

具体的には、何を見張るか、どの警告を重く見るか、記録を誰が見られるか、怪しい動きを見つけたときに誰が何をするか。この四つはAIにも道具にも委ねず、人が決めて記録に残します。AIに記録の要約や怪しい箇所の洗い出しをさせる場合は、どの行を根拠にそう判断したのかを必ず書かせ、人が元の記録と照らして確かめます。人が確認する範囲を先に決めておかなければ、警告はただ積み上がるだけです。やってはいけない向き合い方を挙げます。

• 外から記録していることを理由に、エージェントに渡す権限を広げる
• 強い権限で動く見張り役を、業務の本番の機械にそのまま置く
• 組み込みの目印の警告を、そのまま「攻撃あり」の判定として扱う
• AIに記録を要約させ、根拠の行を確かめずに結論だけを採用する
• 秘密の情報が紛れ込みうる記録を、置き場所と見られる人を決めずに残す
• READMEの説明だけで判断し、リポジトリの中身との食い違いを確かめない

裏を返せば、人が決める範囲ははっきりしています。何を見張り、どの警告を重く見て、誰が記録を見て、見つけたら何をするか。この四つが決まっていないまま記録の道具を置いても、守りの厚みは増えません。

• Azazelの機能・記録の項目・隔離環境の設定・権限・運営体制は、GitHubのリポジトリとその中のファイル、組織共通のセキュリティ方針、運営元の公式サイト、eBPFの解説サイトを2026年10月20日に確かめた範囲に基づきます。内容は変わる可能性があります
• AIエージェントの見張りに向けた具体的な機能や使い方、記録を取ることによる処理の重さ、セキュリティ方針がAzazelのどの版に当てはまるかは、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Azazelは、LinuxのeBPFという仕組みで、コンテナの中のプログラムの起動、ファイル操作、通信、不審な操作を外から記録するOSSです。GPL-2.0で公開され、主な用途はマルウェア解析の隔離環境で、READMEはAIエージェントの見張りにも使えるとうたっています。GitHub上にセキュリティ勧告は登録されておらず、取り込んだだけで動く処理も確認されませんでした。

一方で、記録できるのは行動であって意図や指示文ではなく、AIエージェント向けの詳しい説明も確認できませんでした。見張り役は機械全体に及ぶ強い権限で動き、開発は一人の開発者に大きく依存し、資料と中身には食い違いがあります。何を見張り、記録を誰がどう扱い、見張り役をどこに置くかを人が先に決めたうえで、エージェント自身の記録の裏付けとして使うことが、Azazelとの現実的な付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。