AIエージェントが読む設定や依存パッケージを使う前に検査するOSS「Aguara」とは

「社外のリポジトリを試すとき、依存パッケージを入れた瞬間に何かが動いてしまわないか心配だ」「AIエージェントに読ませる技能の説明書や道具の設定に、余計な指示が紛れていても気づける自信がない」——開発部門の生産性を上げたい一方で、ソフトウェアの持ち込みを預かる情報システム担当やセキュリティ担当から、こうした声が聞こえてきます。対策というと、怪しいものを見つける道具を一つ入れれば済むと考えられがちです。しかし本当に問うべきなのは、エージェントや開発者が「信じて動かす前」に、誰が何を確かめるのかという点です。この記事では、AIエージェント向けの指示や設定、依存パッケージを使う前に検査するOSS「Aguara」を取り上げ、何を見て何を見ないのか、結果をどう読むべきか、企業が導入前に決めておくべき点を整理します。導入や操作の手順は扱いません。

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

Aguaraは、GitHubで公開されているOSSです。リポジトリの説明は「AIエージェントとソフトウェアの供給網の信頼のための、オープンソースのセキュリティエンジン」です。READMEの冒頭には「AIエージェントがこれから信じようとしているものを確かめる」という一文があり、対象としてエージェントへの指示、道具の設定、ソフトウェアの依存関係の三つが挙げられています。

公開元を確かめます。リポジトリは個人のアカウントで2026年2月17日に作られました。アカウント自体は2010年3月に作られ、公開しているリポジトリは33件、フォロワーは258人です。プロフィールの所属にはOktsecという名前があり、公式サイトの下部にも「Oktsecが支える」との表記があります。ただし、その会社が本ソフトの運営にどう関わるかは、確認した資料からは分かりませんでした。

このラインの精査を行った2026年10月19日時点で、スターは94、派生は15、最後の更新は10月5日でした。1日あたりのスターの伸びは約0.4件で、派手に注目を集めた道具ではなく、地道に版を重ねている道具と読めます。ライセンスはApache-2.0です。READMEの各種表示から、Goで書かれていることが分かります。確認した時点の最新のリリースは9月10日の0.28.0で、5月から6月にかけては数日おきに版が出ていました。

なぜ今、「使う前の検査」が求められるのか

READMEは、問題意識を次のように説明しています。一つのプロジェクトが持ち込むのはソースコードだけではありません。依存パッケージは導入のときに処理を走らせることがあり、エージェントの設定は命令の実行を承認したり道具を起動したりします。さらに、指示の文書がエージェントに鍵の情報を読ませたり、誰も確かめていない補助の処理を実行させたりすることもありえる、という指摘です。

AIエージェントを開発に使うようになって、社外から持ち込むものの種類は増えました。エージェントに読ませる技能の説明書、外部の道具をつなぐMCP（AIと外部の道具をつなぐ共通の取り決め）の設定、エージェントに与える許可の設定などです。これらは見た目はただの文書や設定ですが、エージェントが読めば、そのまま行動につながるという性格を持ちます。人が読み飛ばしがちな一行が、エージェントにとっては命令になりえます。

リリースの記録を見ると、6月には大手企業の名前を冠したパッケージ群が乗っ取られた事件（公開元はRed Hatの名を冠した一連のパッケージと説明しています）を受けて、その検出が素早く加えられています。既知の悪性パッケージを照合するだけでなく、まだ一覧に載っていない悪い振る舞いを形で捉える検査も、この事件をきっかけに6種類追加されたと書かれています。供給網を狙う攻撃が続いていることが、この道具の背景にあると読めます。

何を検査するのか：七つの対象

READMEには、検査の対象が表で整理されています。一つ目はプロジェクト全体で、パッケージの照合と中身の検査をまとめて行います。二つ目は依存関係で、悪性パッケージの勧告に載ったものが含まれていないかを見ます。三つ目はエージェントの技能や指示の文書で、プロンプトインジェクション（AIへの指示に紛れ込ませた不正な命令）、鍵の情報や実行を求める不審な依頼、道具の説明に毒を仕込む手口を探します。

四つ目はMCPの設定で、道具を起動する危ない命令、設定に埋め込まれた鍵、危ない設定の型を探します。五つ目はエージェントを動かす側の設定で、Claude Codeの設定ファイルにある広すぎる承認、外から取ってきたものを実行する仕掛け、コードを差し込める環境の設定を見ます。六つ目はnpmとpnpmというパッケージ管理の道具の方針で、導入時の守りを緩める設定を探します。七つ目はプロジェクトのコードと継続的な検査の設定で、不審な導入時の処理、鍵の読み出し、実行の連鎖、GitHubの自動処理に関わる信頼の問題を見ます。

注意したいのは、READMEが対象の広さをむやみに誇っていない点です。MCPの設定の検査については、対応している形式のファイルに限られ、すべてのエージェントの道具に対応するわけではないと明記しています。公式サイトには、自動で見つけられるMCPの利用側の道具が17種類と書かれていますが、それ以外の道具の設定は対象外になりうると考えておく必要があります。

既知の悪性パッケージとの照合

依存関係の検査は、ロックファイル（依存パッケージの版を固定して記録したファイル）などを読むことで、パッケージを実際に入れずに行えるとされています。READMEに載っている対象は、npm、PyPI、Go、Rust、PHP、Ruby、Java、.NETの8つの生態系です。照合に使う情報は、本体に同梱された勧告の写しで、OSV（オープンソースの脆弱性情報の公開データベース）と、そこに含まれるOpenSSFの悪性パッケージのデータ、公開元が手で整理した事件の記録から作られています。

数の目安として、公式サイトは、手元で照合できる既知の悪性パッケージがおよそ22万8千件と示しています。6月の版では、npmで約19万6千件、PyPIで約6千4百件が手元の照合の対象に加わったとリリースノートにあります。ただし、READMEはこれは悪性パッケージの検出であって、脆弱性全般を網羅するものではないとはっきり書いています。OSVの全体ではなく、悪性パッケージの部分だけを取り込んでいるという説明です。

照合の細かな限界も書かれています。特定の版や、すべての版が対象の勧告には対応する一方、版の範囲での照合はnpmに限られます。ロックファイルの大きさには上限があり、壊れた参照などは黙って飛ばさず誤りとして返すとされています。勧告の写しの古さについても、写しの新しさは判断の材料であって、安全や危険の証拠ではないと注意書きがあります。照合で何も出なかったときほど、写しがいつのものかを確かめる必要があります。

振る舞いと設定の検査：一覧に載る前の危険を探す

照合とは別に、Aguaraはコードの中の振る舞いも見ます。READMEによると対象は、二段目の処理を取ってきて実行する動き、鍵の情報を外へ送る動き、端末の設定ファイルの改ざん、大量の削除です。手口の型、読み解いた設定、範囲を限ったコードの解析、経験則による関連づけを組み合わせているとされます。0.28.0の時点で、検出の種類は258（型による規則が192、解析器が出すものが66）とREADMEに書かれています。

エージェントまわりの検査では、技能の説明書の中で道具を無条件に許可している書き方を拾うほか、説明書が必要とする手元の補助の処理を、その処理の中の不審な振る舞いと結びつけて示すと変更履歴にあります。複数のファイルにまたがる技能のつながりを関連づける検査や、一度信頼させたあとで中身を差し替える手口を追う監視の機能もあるとされています。

一方で、READMEはこの検査の限界も率直に書いています。実際の呼び出しと結びつけて誤検知を減らしてはいるものの、誤検知はなくならず、プログラム全体のデータの流れを追う解析でもないという説明です。また、検出の数は悪性パッケージの記録の数とは別物だとも断っています。規則の数が多いことを、守りの厚さと取り違えないようにしたい点です。

検査される側に骨抜きにされない設計

この道具の設計で注目したいのが、9月10日の0.28.0で入った「信頼の境界」の考え方です。検査の道具の多くは、誤検知を減らすために、特定のファイルを対象から外したり、特定の所見を出さないようにしたりする設定を持ちます。問題は、その設定を検査される側のリポジトリが自分で持てる場合です。

悪意のあるリポジトリが「このファイルは検査しない」という設定を同梱していれば、検査をすり抜けられてしまいます。0.28.0では、まとめて検査する機能、継続的な検査、GitHubの自動処理、公開の検査の仕組みについて、検査される側が持つ除外や抑制の設定を既定で無視するよう改められました。リリースノートには「リポジトリが自分自身のセキュリティ検査から隠れられるべきではない」と書かれています。

ただし、手元での個別の検査は、利用者が明示しない限り、これまでどおり検査される側の設定に従います。また、READMEは古い版では、リポジトリが持つ方針を信じてしまう場合があると注意しています。同じ版では、読めなかったり確かめられなかったりした場合に、問題なしと表示せず失敗として報告するよう改められました。社外のリポジトリを検査する用途なら、版がこの改めより新しいかを確かめることが前提になります。

手元で完結する設計と、照合情報の更新

READMEは、「解析は手元で行う。パッケージの実行も、中身の送信も、利用状況の送信も、言語モデルの呼び出しもしない」と明記しています。公式サイトも、利用者の登録が要らないこと、利用状況を送らないこと、言語モデルを呼ばないことを挙げています。社外秘のコードを外部の検査サービスに送れない企業にとって、検査対象を外へ出さずに済むことは検討しやすい点です。

ネットワークを使うのは、利用者が明示的に照合情報を更新するときだけとされています。その場合は、署名付きの勧告のまとまりを取ってきて、使う前に確かめる仕組みです。署名の確認を飛ばす選択肢もありますが、別の環境の指定を重ねたときにしか効かず、確かめていない情報として区別されると説明されています。外部とつながない環境で使う場合は、更新の操作を避ければよいとされています。

ここから分かるのは、照合の新しさは、更新を誰がいつ行うかという運用で決まるということです。同梱の写しのままでは、新しく見つかった悪性パッケージは照合できません。手元で完結する設計の裏返しとして、更新の担当と頻度を社内で決めておく必要があります。なお、版の確認の機能が新しいリリースの有無を調べることはあり、その通知は止められるとされています。

検査結果の読み方：所見は「判定」ではなく「確認の材料」

READMEは、検査結果の読み方に一節を割いています。例として挙げられているのは、Claude Codeの設定でシェル（命令を打ち込む窓口）の実行を広く承認している場合です。Aguaraはこれを中程度の重さの所見として報告しますが、そのプロジェクトがマルウェアだと主張しているわけではないと書かれています。示しているのは「この道具に無制限の実行の許可が本当に要るのか、絞れないのか」という、見直すべき判断です。

読む順番も示されています。まず既知の悪性パッケージとの一致を確かめ、次に中身の所見とその説明を読みます。所見には、該当するパッケージやファイルが示されるので、依存を入れる前、継続的な検査を走らせる前、エージェントにプロジェクトを触らせる前に調べられる、という使い方です。また、検査の終わりに返す結果の値は、失敗とみなす基準を超えたかどうかを表すだけで、危険がないことを表すものではないとされています。

READMEの「限界」の節は、さらにはっきりしています。問題なしの報告は安全の証明書ではないこと、所見は確認すべき証拠であって悪意の証明とは限らないこと、結果は道具の版・規則・設定・照合情報の写しによって変わること。そして、報告そのものに機密の情報が含まれうることです。0.28.0では、報告の中の鍵の文字列を伏せる範囲も広げられています。報告の保管先と見られる人の範囲も、社内で決めておく対象になります。

継続的な検査や、他の道具とのつなぎ方

READMEによると、継続的な検査（コードの変更のたびに自動で走らせる仕組み）に組み込む場合は、依存を入れたりプロジェクトの命令を走らせたりする前に検査することが勧められています。既定では、まとめて検査する機能は最も重い所見で、個別の検査は重い以上の所見で失敗とします。既存のプロジェクトでは、今ある所見を基準として記録し、新しい所見だけで止める使い方もできます。ただし、乗っ取られたパッケージの所見は基準に含めて見逃すことができない作りです。

GitHubの自動処理向けの部品もありますが、READMEは、この部品が行うのは中身の検査だけで、パッケージの照合を含むまとめた検査ではないと注意しています。照合も行うなら別の段階で行う必要があります。結果はSARIF（検査結果を共有するための標準の形式）でGitHubの画面に送れるほか、JSONなどの形式でも出せます。

ほかの道具に組み込むための部品としての提供もあり、エージェントがMCPを通じて検査を呼び出せる連携も別に公開されています。ここでもREADMEは、通信の横取り、許可の判断、実際に止めることは、組み込む側の責任だと明記しています。Aguaraは見つけて知らせる道具であり、止める道具ではない、という線引きです。なお、以前公開されていた登録所の観測の仕組みは、現在は支えられている製品ではないとされています。

似た手段と何が違うのか

ソフトウェアの持ち込みを確かめる方法は、ほかにもあります。READMEが自ら挙げている「置き換えにならないもの」をもとに、どこを見る道具なのかを比べます。優劣ではなく、守る場所の違いとして読んでください。

見る点	脆弱性の一覧との照合	動作中の監視・隔離	Aguara
主な対象	既知の弱点を持つ版の部品	動いているエージェントや処理の振る舞い	悪性パッケージ、エージェントの指示と設定、導入時の処理
いつ見るか	導入時や定期的に	動いている最中	使う前、依存を入れる前
対象を動かすか	動かさない	動かしながら見る	動かさない
止める力	道具による	止められるものがある	持たない（見つけて知らせる）
エージェントの許可設定	多くは対象外	道具による	対応する形式を検査
既知でない手口	多くは対象外	振る舞いで捉えうる	型と経験則で一部を捉える

READMEは、本ソフトがアプリケーションの静的検査、脆弱性全般の照合、動作中の監視の代わりにはならないと明記しています。表のとおり、Aguaraが受け持つのは「使う前」の段階で、エージェントに固有の設定まで含めて確かめる部分です。既存の脆弱性管理や、動作中に止める仕組みと重ねて使うものと考えるのが妥当でしょう。

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

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

根拠は次のとおりです。作者は2010年からある個人のアカウントで、フォロワーは258人、公開リポジトリは33件あり、実績のない匿名のアカウントではありません。スターの伸びは1日あたり約0.4件で、不自然な水増しの兆候は見られませんでした。ライセンスはApache-2.0で商用も含めて使えます。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。リポジトリの直下には導入用のスクリプトがありますが、利用者が自分で実行するもので、取り込んだだけで自動的に動く処理ではありません。スクリプトの中身を読んだ範囲では、配布物の照合値を確かめ、利用者の領域に置くもので、利用状況の送信や起動設定の書き換えは見当たりませんでした。

セキュリティ方針の文書もあり、弱点の報告はGitHubの非公開の窓口で受け付け、48時間以内に受領、7日以内に初回の評価、確認された問題は30日以内に修正か緩和を行うとしています。配布物には署名と部品表が付くとされています。ただし、勧告がないことは安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。検査の道具は社外のコードを読み込む立場にあるため、評価は導入する側でも重ねる必要があります。

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

第一に、版による違いが大きい点です。0.28.0で検査される側の設定を既定で無視するよう改められたことは先に触れたとおりで、古い版では結果の意味が変わります。セキュリティ方針の文書が全面的に支えるのは最新版だけで、古い版は可能な範囲の対応です。公式サイトとREADMEで検出の数の記載が異なる（サイトは0.27.0時点の250、READMEは0.28.0時点の258）など、資料ごとに時点がずれていることにも注意が要ります。

第二に、導入のための手段の違いです。READMEによると、導入用のスクリプトは配布物の照合値を確かめますが、署名の確認までは行いません。署名を確かめるには別の手順が要ります。また、Goの道具から直接入れる方法では、版の情報や署名が付きません。供給網の検査の道具そのものを、確かめた経路で入れることが、検査の信頼の出発点になると考えるべきでしょう。

第三に、リポジトリには攻撃の見本や検出の試験用のファイルが意図的に含まれている点です。READMEは、そこで所見が出ても検査の道具が乗っ取られた印ではないと断っています。社内の別の検査の道具がこのリポジトリに警告を出すことはありうるので、事前に関係者と共有しておくと混乱を避けられます。第四に、手元のMCPの設定を自動で探す機能は、端末の中の設定ファイルを読みます。設定に鍵が書かれていれば、それが所見として報告に載る可能性があります。

悪用されうるリスク

Aguaraは守りのための道具で、攻撃のための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「検査を通ったから安全」という思い込みが独り歩きすることです。公開元自身が繰り返し書いているとおり、問題なしの報告は安全の証明ではありません。

次に挙げるのは推測ですが、検討の材料になります。検出の規則が公開されている以上、攻撃する側も規則を読んで、引っかからない書き方を工夫する可能性があります。これは型で探す検査の道具に共通する宿命で、Aguaraに限った弱点ではありません。照合の写しが古いまま使われていれば、新しい悪性パッケージは素通りします。

もう一つは、報告の扱いです。報告には鍵の文字列の一部などの機密が含まれうるとREADMEは注意しています。報告を共有の場所に置いたり、外部の道具に渡したりすれば、守りのための記録がそのまま漏えいの経路になりえます。なお、Aguaraが実際に悪用された事例は、2026年10月19日時点で確認した一次情報からは見つけられませんでした。

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

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

この手順の要は、検査を入れることと、所見を人が確かめる流れを同時に決めることです。所見が出ても誰も読まない状態では、検査は形だけになります。

企業が取るべき対策

一つ目は、エージェントに与えている許可の棚卸しです。Aguaraを使うかどうかにかかわらず、エージェントの設定で実行を広く承認していないか、外から取ってきたものを実行する仕掛けがないかを確かめます。許可は必要な範囲に絞るという原則は、この道具の例が示しているとおりです。

二つ目は、社外から持ち込むものの範囲の見直しです。依存パッケージだけでなく、技能の説明書、MCPの設定、エージェントの設定も「持ち込むソフトウェア」として扱い、社内規程の対象に入れます。三つ目は、パッケージ管理の道具の守りの設定です。導入時の処理を一括で許す設定など、守りを緩める設定を使わない方針を決め、例外は申請制にします。

四つ目は、検査を重ねることです。使う前の検査、脆弱性の照合、動作中の監視と隔離を役割分担させ、一つの道具に全部を任せません。五つ目は、調達のときの確認です。個人が中心になって作っている道具であること、最新版だけが全面的に支えられること、報告の窓口と期限が示されていることを踏まえ、社内で使える段階かどうかを文書で判断することが大切です。

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

Aguaraは、AIエージェントが信じて動かす前に確かめるための道具で、自らは言語モデルを使いません。それでも、エージェントがMCPを通じて自分で検査を呼び出す使い方は用意されています。だからこそ、AIに判断させない部分を先に決める必要があります。

具体的には、どの重さの所見で使用を止めるか、誰が所見を読んで判断するか、照合の写しをいつ新しくするか、検査を省いてよい例外は何か。この四つはエージェントにも道具にも委ねず、人が決めて記録に残します。エージェントに検査結果の要約を作らせる場合も、どの所見を根拠にそう判断したのかを書かせ、人が確認する範囲を先に決めておくと、後から判断を振り返れます。やってはいけない向き合い方を挙げます。

• エージェントに検査を呼ばせ、問題なしと返ってきたらそのまま導入まで進めさせる
• 所見が多いからと、検査される側の除外の設定を信じて黙らせる
• 照合の写しを一度も新しくせず、最新の悪性パッケージも照合できていると思い込む
• 報告を誰でも見られる場所に置き、中に含まれる鍵の断片を放置する
• 検査の道具を入れたことを理由に、脆弱性の照合や動作中の監視をやめる
• 版を確かめずに古い版を使い続け、リポジトリが持つ方針を信じたまま検査する

裏を返せば、人が決める範囲ははっきりしています。いつ検査し、誰が所見を読み、何で止め、いつ情報を新しくするか。この四つが決まっていないまま道具を入れても、守りの厚みは増えません。

• Aguaraの機能・版・対象・制限は、GitHubのリポジトリとその中の文書（README、セキュリティ方針、変更履歴、導入用のスクリプト）、リリースノート、公式サイトを2026年10月19日に確かめた範囲に基づきます。版が頻繁に上がっているため、内容は変わる可能性があります
• 公式サイトの数値（検出の数、悪性パッケージの件数、対応する道具の数）は0.27.0時点の表記で、READMEの0.28.0時点の数値とずれがあります。所属として表示される会社が運営にどう関わるかは確認できませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Aguaraは、AIエージェントへの指示、道具の設定、依存パッケージを、使う前に検査するOSSです。既知の悪性パッケージとの照合と、振る舞いや設定の検査を組み合わせ、パッケージを動かさず、中身を外へ送らず、言語モデルも呼ばずに手元で結果を出すとされています。個人の開発者がApache-2.0で公開し、GitHub上にセキュリティ勧告は登録されていません。9月の版では、検査される側のリポジトリが自分の検査結果を隠せないよう既定が改められました。

一方で、公開元自身が、問題なしの報告は安全の証明ではなく、所見は確認の材料であり、止める仕組みでも脆弱性全般の照合でもないと明記しています。照合の写しの更新、所見を読む人、報告の扱いは、道具ではなく人が決める範囲です。いつ検査し、誰が確かめ、何で止めるかを先に決めたうえで使うことが、エージェントに社外のものを読ませる時代のAguaraとの付き合い方です。

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