AIエージェントを使う企業が知っておきたい危険操作を止めるOSS「HOL Guard」の使いどころ

「開発者がAIエージェントに端末の操作を任せ始めたが、何を実行しているのか追いきれない」「AIが勝手に入れたパッケージや、つないだMCPサーバーが安全かどうか、誰も確かめていない」——AIエージェントの社内利用を見守る立場になった情報システム部門やセキュリティの担当者から、よく聞かれるようになった声です。こうした不安に、ウイルス対策のような見張り役を一つ入れれば応えられるように見えます。しかし、足りていないのは見張り役そのものではありません。本当は、AIに何をさせてよく、何は人の承認を通すのかを、会社として決めていないことが問題の中心です。この記事では、AIエージェントの操作を実行前に確かめて止めるOSS「HOL Guard」を取り上げ、確かめられる事実、判定に使う情報が社外へ出るかどうか、企業が導入前に決めておくべき点を整理します。導入や設定の手順は扱いません。

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

HOL Guardは、GitHubで公開されているOSSです。リポジトリの説明では、自らを「AIエージェントのためのオープンソースのウイルス対策」と呼び、危険な道具、秘密情報へのアクセス、プロンプトインジェクション（外部の文章に紛れ込ませた命令でAIを操る攻撃）、悪意のあるパッケージ、MCPサーバー、プラグイン、スキルを実行時に止めるとしています。READMEでは、AIエージェントの操作を、実行される前に確かめる層と説明され、端末の中で動くことを優先した作り（ローカルファースト）だとされています。

配布の形を確かめます。リポジトリは hashgraph-online という組織のアカウントで2026年3月28日に作られ、ライセンスはApache-2.0です。2026年10月18日時点でスターは926、派生は166、最後の更新は10月17日でした。組織のアカウントは2024年2月18日に作られ、公開しているリポジトリは66件、フォロワーは1,622です。一日あたりのスターの伸びは約4.5件で、作ったばかりのアカウントが急に注目を集めている形ではないと分かります。

更新の速さも特徴です。リリースの一覧では、10月17日の一日だけで3.48.0版と3.49.0版が続けて公開され、拡張の定義を配る先行版も同じ日に複数出ていました。動作には Python の3.10以降が必要で、判定の中心部分には Rust で書かれた処理が使われているとREADMEにあります。版が短い間隔で上がる道具だという前提で、更新の受け入れ方を考える必要があります。

なぜ今「AIエージェント向けのウイルス対策」が求められるのか

AIエージェントは、文章を返すだけでは終わりません。開発者の端末で、ファイルを読み書きし、コマンドを走らせ、足りない部品があれば自ら入れ、外部の道具をMCPでつないで呼び出します。問題になりやすいのは、AIの答えが間違っていることより、正しく指示どおりに動いた結果として、触れてはいけない場所に手が届くことです。

たとえば、作業の途中で読んだ外部の文章に命令が紛れ込んでいれば、AIは鍵の入ったファイルを読み、外へ送るコマンドを組み立てるかもしれません。名前のよく似た悪意のあるパッケージを、正規のものと取り違えて入れるかもしれません。従来のウイルス対策は、ファイルや通信の中に既知の悪いものがあるかを見ます。しかしAIエージェントの操作は、一つひとつは普通のコマンドやファイルの読み取りに見えるため、従来の見方だけでは拾いにくいのです。

HOL Guardが「AIエージェント向けのウイルス対策」を名乗るのは、この隙間を埋めるためと読めます。AIエージェントが道具を呼ぶ直前に割り込み、中身を見て、通すか止めるかを決める。ただし、ウイルス対策という呼び名は、すべてを防いでくれるという印象を与えやすい点には注意が要ります。後の章で見るとおり、守れる範囲には条件があります。

実行前に止める対象：コマンドとファイルの読み書き

READMEは、守る対象を六つの面に分けて示しています。最初の面が、コマンドの実行とファイルへのアクセスです。ここでは、取り返しのつかない操作、機密性の高いファイルへのアクセス、認証情報の露出、外への不審な送信を含むコマンドを確かめるとされています。判定の結果は、許可する、止める、承認を求める、のいずれかで、どれにするかは利用者の決めたポリシー（判断の決まり）に従うと説明されています。

コマンドの種類ごとの判定の決まりは「拡張」として定義され、どのコマンドをどう分類するかの一覧が公開されています。外部の人が作った拡張は既定で無効になっており、端末の管理者が明示的に有効にしない限り働かないとREADMEにあります。一方で、必須の中核の保護は常に有効のままだとされています。外から持ち込んだ判定の決まりが、勝手に効き始めない作りになっている点は、企業の利用では確かめておきたいところです。

もう一つ注目したいのは、符号化されたコマンドやプロンプトをほどいて確かめる機能です。設計の文書では、ほどいた中身を実行することはないと書かれています。見た目では分からない形に包んだ命令でも、中身を確かめてから判断する考え方です。ただし、どこまでの包み方に対応しているかは、確認した資料からは十分には分かりませんでした。

パッケージの導入とサプライチェーンの確認

二つ目の面は、パッケージの導入です。READMEによると、対応する導入の道具での操作を、導入する前にサプライチェーン（ソフトウェアの部品の供給の流れ）に関する情報と照らし合わせて評価します。判定には、手に入る範囲の勧告の根拠が添えられるとされています。AIが自分の判断で部品を入れる場面に、確認の関門を一つ置く考え方です。

照らし合わせに使う情報の出どころについて、運営元のサイトは「選び抜いた勧告」や、運営元が公開しているプラグインの安全性に関するデータセットへの参照を示しています。ただし、どこから集め、どの頻度で更新しているのかは、確認した一次情報からは明確に読み取れなかったため、導入の判断では運営元への確認が要ります。

このほか、作業場所の依存関係をまとめて調べる機能や、AIに関わる部品の一覧（AIの部品表）を書き出す機能もREADMEに挙げられています。どの部品が入っているかを一覧にできることは、後から勧告が出たときに影響を調べる助けになります。部品の一覧づくりを、人の手作業だけに頼らずに済む点は、運用の負担を考えるうえで見逃せません。

MCPサーバー・プラグイン・スキルの棚卸しと変更の検知

三つ目と四つ目の面が、プラグインやスキル、AIエージェントの設定、そしてMCPサーバーと道具の呼び出しです。READMEでは、端末にあるこれらの部品を一覧にし、新しく加わったものや中身が変わったものを、起動する前に確かめるとしています。設計の文書によると、起動のたびに部品の状態を写し取り、前回と比べ、ポリシーに照らして判定し、記録を残してから起動します。判定が「止める」なら、AIエージェントは起動しないという順序です。

MCPについては、サーバーの設定を確かめるほか、対応する割り込みの仕組みや、HOL Guardが管理する中継を通して、道具の呼び出しを確かめるとされています。MCPサーバーは、いったんつなぐと、AIに新しい道具を渡す入口になります。いつの間にか増えた接続先や、中身が書き換わった道具を、起動前に拾えることは、棚卸しの観点で意味があります。

五つ目の面は、プロンプトと道具の返す結果です。対応する出来事について、プロンプトインジェクションや機密性の高い内容が含まれていないかを確かめるとされています。ただし、後の章で触れるとおり、AIエージェントによっては、利用者が入力した文章そのものは確かめの対象に入っていない組み合わせもあります。

承認の流れと、判断の記録

六つ目の面が、承認と証跡です。止めるか通すかを人に尋ねる判定になったとき、その問い合わせは、AIエージェント自身の確認画面か、HOL Guardの承認の窓口に回されます。そして、判断の結果は端末の中に受領記録として残されます。READMEによると、手元の画面で、保護の状態、承認待ちの一覧、判断の履歴を確かめられます。

記録の中身については、別の文書に細かな決まりがあります。コマンドの評価ごとに一行の記録を作りますが、そこには生のコマンド、ファイルの場所、パッケージ名、環境変数の値、認証情報を保存してはならないとされています。代わりに、照合用の値を鍵付きの計算で作って残す形で、文書自身が「匿名ではなく、仮名である」と明記しています。

画面には、秘密情報やトークン、私的なファイルの場所、URL、メールアドレスなどを落とした形の、コマンドの見本だけを端末の中に限って表示できるとされています。後から何が起きたかをたどりたい担当者にとっては、記録が残ることと、記録から元の操作をどこまで復元できるかは別という点を、導入前に確かめておく必要があります。

判定に使う情報は社外へ送られるのか

企業が最も気にするのは、この点でしょう。運営元のサイトは、判定は端末の中で行い、アカウントなしで、通信が途切れても動き続けると説明しています。サイトには「あなたのファイルは端末から出ない」という趣旨の記載もあります。コマンドの記録の文書では、社外への送信の既定は「端末の中だけ」とされ、記録を作ること自体は通信を伴わないと書かれています。

送信が起きるのは、利用者が明示的に選んだときです。コマンドの記録については、日ごとの集計値だけを送る設定を選べ、その場合も識別子、正確な時刻、自由記述、コマンドごとの行は含めないとされています。一方、クラウド版に端末をつなぐと、端末の構成の要約が送られます。その中身は、HOL Guardの版、OSの種類、保護しているAIの道具、スキルとプラグインの一覧、適用しているポリシーです。範囲を版と保護の状態とポリシーの状態に絞ることはできますが、管理者が配った導入では送信を止められないと書かれています。

通信先の一覧も公開されています。運営元の hol.org は、クラウド版のポリシー、本人確認、署名付きの脅威情報、証跡の同期に使われます。パッケージの登録先への問い合わせは任意の読み取りで、公開されているパッケージの情報を取りにいく用途とされています。問い合わせの中にどのパッケージ名が含まれるかは明記されていませんが、確かめる対象の名前は問い合わせ先に伝わると考えるのが自然です。このほか、管理者が設定した場合に限り、外部のチャットサービスへ承認の通知を送る経路があります。

運営元とクラウド版との関係

HOL Guardを公開している hashgraph-online の組織は、運営元のサイト上で「HOL」と名乗っています。サイトの記載では、HOLはHashgraph Online DAO LLC が運営しているとされ、AIエージェント同士が互いを見つけ、信頼の手がかりを確かめるための共通の仕組みや標準を作っていると説明されています。HOL Guardは、その製品の一つとして紹介されています。

名前からは分散型台帳の技術との関わりがうかがえますが、確認した運営元のページには、その関係の説明も、トークンへの言及もありませんでした。HOL Guardの判定の仕組みが、そうした技術に依存していると読める記載も見当たりませんでした。この点は、現時点で確認できる情報は限られると書いておきます。

クラウド版は、任意の有料のサービスです。サイトでは、無料の段階のほか、4.99ドル、15ドル、30ドルの有料の段階と、法人向けの個別見積もりが示されていました。ただし、料金の期間の表記は確認できませんでした。クラウド版が加えるのは、端末をまたいだ判断の履歴、チームでのポリシーの共有、端末群の把握です。運営元は「クラウドへの接続は把握と調整のためで、止める判断のためではない」と説明しており、無料のまま端末の中だけで使い続けられる設計だとしています。

対応するAIエージェントと、守れる範囲の差

READMEには、Codex、Claude Code、Cursor、Cline、Devin などを含む十数種類のAIエージェントが対応先として並んでいます。ただし、対応の中身は一様ではありません。対応表の文書によると、道具を実行する直前に割り込んで止められるものと、起動の時点や承認の窓口での確認にとどまるものがあります。たとえば Claude Code では、道具の実行前の確認はできる一方、利用者が入力した文章そのものは確かめの対象になっていないとされています。

見張りの処理が落ちたときの振る舞いも、組み合わせごとに違います。Cline などでは、HOL Guardが使えないときに止める側へ倒れる（フェイルクローズ）とされる一方、Kimi、Grok、ZCode では、見張りの処理が落ちたり時間切れになったりすると、止めずに通す（フェイルオープン）と明記されています。Devin でも、確認が時間切れになったときは許可として先へ進むとされています。

ほかにも、道具を実行した後の確認は違反を報告するだけで、実行してしまった操作を取り消せないこと、一部の開発環境の拡張機能の中までは割り込めないことが、対応表に書かれています。つまり、HOL Guardを入れたかどうかではなく、どのAIエージェントと組み合わせ、どの範囲が守られているかを一覧にして初めて、守りの実態が分かります。

似た手段と何が違うのか

AIエージェントの操作を抑える方法は、HOL Guard以外にもあります。一次情報で確認できた範囲をもとに、代表的なやり方と比べます。優劣ではなく、何を守りたいかと、割ける運用の手間で選ぶ話です。

見る点	AIエージェント自身の確認画面	隔離した実行環境	HOL Guard
止める時点	AIエージェントの仕様しだい	外への影響を環境の外で抑える	道具の実行や導入の直前
判断の決まり	AIエージェントごとに別々	環境の設定で決める	共通のポリシーで決める
パッケージの確認	通常は行わない	通常は行わない	導入前に勧告の情報と照らす
MCPやスキルの変化	人が気づくしかない	環境に入れたものに限られる	起動前に一覧と差分を確かめる
判断の記録	残らないことが多い	環境の記録の範囲	端末の中に受領記録を残す
守れない場面	利用者が確認を省く設定	環境の中に置いた情報	対応の薄い組み合わせ、処理が落ちたとき

表のとおり、HOL Guardの特徴は、AIエージェントの種類をまたいで共通の決まりを当てはめ、パッケージやMCPの変化まで起動前に確かめる点にあります。一方で、隔離した実行環境の代わりになるものではありません。実行前に止める仕組みと、事故の影響を閉じ込める仕組みは、役割が違うと捉え、重ねて使うかどうかを検討するのが妥当でしょう。

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

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

根拠にした事実は次のとおりです。運営は組織のアカウントで、2024年2月に作られ、フォロワーは1,622、公開しているリポジトリは66件あります。スターの伸びは1日あたり約4.5件で、不自然な水増しの兆候は見られませんでした。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、ライセンスはApache-2.0で商用も含めて使えます。リポジトリの直下にはコンテナを作るための定義がありますが、取り込みのときに自動で動く処理を含む設定は見当たりませんでした。

ただし、勧告がないことや自動実行がないことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。加えて、この道具はAIエージェントの操作に深く割り込み、端末の設定に手を入れる性格を持ちます。守りの道具そのものが、端末の中で強い立場に立つ点は押さえておいてください。

導入前に知っておきたい注意点

第一に、弱点の報告の方針と現行の版の関係です。セキュリティ方針の文書では、支援の対象は2系の版で、1系は対象外とされています。報告は専用の窓口へ非公開で送り、48時間以内に受け付けの返事、14日以内に初回の評価を返すとしています。一方、確認した時点の最新版は3系でした。方針の記載が現行の版に追いついていない可能性があるため、どの版が支援の対象かは運営元に確かめる必要があります。

第二に、更新の速さです。一日に二つの版が出ることもあり、判定の決まりを配る先行版も頻繁に出ています。止める範囲が変われば、昨日まで通っていた作業が止まることも、その逆もありえます。版を固定して検証し、更新を受け入れる手順を先に決めておく必要があります。

第三に、守る範囲がAIエージェントの種類と版に左右される点です。対応表の文書は、版ごとの対応状況の表示は参考で、判定の動きを変えるものではないとしています。社内で使われているAIエージェントの一覧と、その組み合わせでの守りの範囲を照らし合わせない限り、入れたのに守られていない端末が残る可能性があります。

第四に、日本語での紹介がまだほとんど見当たらない点です。確認した範囲では、日本語で仕組みや注意点を整理した資料は見つけられませんでした。社内で検討するときは、英語の一次情報を読む担当者を決め、確かめた内容を記録に残す進め方が現実的です。

悪用されうるリスク

HOL Guardは守りのための道具で、攻撃に使うためのものではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「見張り役を入れたから安心」という思い込みが、確認の手を緩めさせることです。前の章で見たとおり、処理が落ちたときに止めずに通す組み合わせがあり、実行後の確認は取り消しになりません。

次に挙げるのは推測ですが、検討の材料として無視できません。この種の道具は、AIエージェントの設定に割り込み、判断の決まりを持ち、承認の窓口を担います。そのため、もし道具そのものや判定の決まりの配布の経路に弱点があれば、守りの層が、かえって攻撃者にとって魅力的な足場になる可能性が考えられます。外部の人が作った拡張が既定で無効になっている設計は、この危険を意識したものと読めます。

もう一つは、クラウド版につないだ場合の情報の集まり方です。端末ごとのスキルとプラグインの一覧や適用中のポリシーが一か所に集まれば、社内のAI利用の地図になります。その地図を扱う鍵の管理と、誰が見られるかの設定が、新しく守る対象に加わります。なお、HOL Guardが実際に悪用された事例は、2026年10月18日時点で確認した一次情報からは見つけられませんでした。

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

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

この手順の要は、動かす前に「どこが守られていないか」を一覧にしておくことです。見張り役は、入れた瞬間から安心を生みます。その安心がどの範囲にだけ当てはまるのかを先に書き出しておかないと、守られていない組み合わせが確認されないまま残ります。

企業が取るべき対策

一つ目は、AIエージェントの利用を届け出制にすることです。どの端末で、どのAIエージェントを、どの権限で使っているかを把握できなければ、見張り役をどこに入れるかも決められません。HOL Guardのような道具は、その一覧を前提に働くものとして位置づけます。

二つ目は、止める決まりを会社として持つことです。取り返しのつかない操作、鍵の入ったファイルへのアクセス、外への送信、承認されていないパッケージの導入、新しいMCPサーバーの追加について、止めるのか人に聞くのかを決めます。三つ目は、守りが薄い組み合わせへの手当てです。処理が落ちたときに通してしまう組み合わせでは、AIエージェント自身の確認画面を省く設定を禁じ、扱う情報を絞ります。

四つ目は、記録を見る運用です。承認の履歴と止めた操作の記録を、決めた頻度で見直し、止めすぎて業務が回らない決まりや、通しすぎている決まりを直します。五つ目は、調達のときの確認です。運営の体制、更新の頻度、弱点の報告への窓口、クラウド版につないだときに送られる情報を、導入前に文書で確かめます。

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

HOL Guardは、AIエージェントの操作を実行前に確かめる道具です。しかし、確かめるための決まりを作るのは人です。だからこそ、先に決めるのは、AIにも道具にも判断させない部分です。

具体的には、どの操作を止めるか、どの操作を人の承認に回すか、どのAIエージェントの利用を認めるか、クラウド版に何を送ってよいか。この四つは人が決め、決めた根拠を記録に残します。承認の窓口に上がった問い合わせも、AIに理由を書かせたうえで、最後は人が判断します。やってはいけない向き合い方を挙げます。

• 「AI向けのウイルス対策を入れたから」を理由に、AIエージェントの利用の届け出をやめる
• 対応表を確かめず、処理が落ちたときに通してしまう組み合わせをそのまま使う
• 承認の問い合わせを、理由を読まずに通し続ける
• クラウド版につなぐときに、送られる構成の要約の範囲を確かめない
• 外部の人が作った判定の決まりを、中身を見ずに有効にする
• 更新の速い道具を、版を固定せず自動で上げ続ける

裏を返せば、人が決める範囲ははっきりしています。何を止め、誰が承認し、どこが守られておらず、何を社外へ送るか。この四つが決まっていないまま見張り役を入れても、守りの厚みは増えません。

• HOL Guardの機能・対応範囲・通信先・料金は、GitHubのリポジトリとその中の文書、リリースの一覧、運営元のサイトを2026年10月18日に確かめた範囲に基づきます。版の更新が速く、内容は変わる可能性があります
• パッケージの確認に使う脅威情報の出どころと更新の頻度、問い合わせに含まれる情報の詳細、運営元と分散型台帳の技術との関係は、確認した一次情報の範囲では十分に確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

HOL Guardは、AIエージェントが実行しようとするコマンド、ファイルの読み取り、パッケージの導入、MCPの呼び出しを実行前に確かめ、通すか止めるか人に聞くかを決めるOSSです。Apache-2.0で公開され、アカウントなしで端末の中だけで動かせます。社外への送信は既定で抑えられていますが、有料のクラウド版につなぐと、スキルやプラグインの一覧、適用中のポリシーを含む構成の要約が運営元へ送られます。

一方で、守れる範囲はAIエージェントの種類ごとに違い、処理が落ちたときに止めずに通してしまう組み合わせもあります。何を止め、誰が承認し、どこが守られておらず、何を社外へ送るかを先に決め、守られていない範囲を一覧にしたうえで使う。見張り役を入れることではなく、見張りの決まりを会社が持つことが、AIエージェントを社内で動かす企業にとってのHOL Guardの使いどころです。

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