自社のAIエージェントの弱点を出荷前にOSS「Humanbound」はどう見つけるのか

「社外向けの問い合わせ窓口に、道具を使えるAIエージェントを置く予定だ。公開する前に、悪意のある利用者に会話でそそのかされたとき、決めた範囲を守れるのか確かめておきたい」「試験の道具を入れたいが、その道具自体に自社の鍵や接続先を預けて大丈夫なのか」——AIエージェントを自社の製品や業務に組み込み始めた企業で、開発とセキュリティの担当者から出てくる声です。大事なのは、攻撃に強いかどうかを一度の点数で言い切ることではありません。本当は、自社が決めた「してよいこと・いけないこと」の境目を、許可された範囲の試験で確かめ、結果を人が読んで直すことです。この記事では、AIエージェントを出荷前に攻撃に見立てて試験するOSS「Humanbound」について、一次情報で確かめられる仕組み、結果の読み方、試験の結果を守りの規則に変える考え方、手元で動かす形と提供元の基盤につなぐ形の違い、公開済みのセキュリティ勧告と修正の状況、使う前に社内で決めることを整理します。導入や操作の手順、試験項目の中身は扱いません。

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

Humanbound は、GitHub で公開されているAIエージェント向けの試験用のOSSです。リポジトリの説明は「AIエージェントのための、攻撃に見立てた試験の仕組みと、開発者向けの部品と、コマンドで操作する道具」で、手元だけで動かすことも、提供元が運営する基盤（Humanbound の基盤）につないで動かすこともできる、とされています。READMEは、文面の一つひとつではなく、エージェントそのものを試すことを特徴に掲げています。

2026年10月26日に確かめた範囲では、リポジトリは2026年2月8日に作られ、スターは216、派生は20、本流への変更の記録は267件です。最後の更新は10月22日で、リリースの一覧の最新は10月2日の2.13.0版です。スターの伸びは1日あたり0.8ほどと緩やかで、不自然な水増しをうかがわせる動きは見られません。日本語での紹介は、確認した範囲ではほとんど見当たりませんでした。

公開しているのは Humanbound の組織アカウントで、2023年2月に作られ、公開リポジトリは7つです。提供元のサイトは、試験・本番での防御・継続的な監視を一続きで提供する、AIエージェントのセキュリティの会社だと説明していますが、所在地や設立の時期は、確認した一次情報には書かれていません。ライセンスは Apache-2.0（OSI承認）で、商標の扱いは別の文書で定めています。

なぜ今話題か：文面ではなく「エージェント」を試す必要

これまでの生成AIの点検は、一つの問いかけに対して不適切な答えを返さないかを見るものが中心でした。ところがAIエージェントは、会話を何往復も続け、途中で社内の道具を呼び出し、その結果をもとに次の行動を決めます。一回の問いかけでは何も起きなくても、会話を重ねるうちに、決めた範囲の外の操作へ少しずつ引き寄せられるという失敗は、エージェントならではのものです。

READMEは、多くの試験の道具が文面を試すのに対し、Humanbound は実際の窓口に会話を重ねて働きかけ、道具の使い方と範囲の境目を探り、結果を利用者が決めた安全の方針に照らして採点する、と説明しています。提供元の文書では、結果は OWASP の大規模言語モデル向けの主要な危険の一覧と、エージェント型AI向けの一覧の分類に対応づけて報告される、とされています。

企業にとっての意味は、モデルの提供元の安全対策と、自社が組み立てたエージェントの振る舞いは別物だという点にあります。自社が書いた指示、渡した道具、つないだ社内の情報が組み合わさって初めて表に出る弱さは、自社で、自社の窓口を相手に確かめるしかありません。Humanbound は、その確かめを出荷前の工程に組み込むための道具の一つと位置づけられます。

仕組み1：実際の窓口に会話を重ねて試す

READMEによると、Humanbound の試験の仕組みは、試す相手のエージェントの窓口へ、利用者の発言に見立てた文面を送り、返ってきた答えを受けて次の発言を組み立てる、というやり取りを繰り返します。会話の始まりに対話の区切りを作る手順や、別の認証の手順にも対応し、過去のやり取りを毎回まとめて受け取る作りのエージェントも相手にできる、とされています。

提供元の文書は、試験の種類として、一往復で終わるもの、何往復も重ねるもの、エージェントの道具の使い方に踏み込むもの、さらに本来の目的に沿って正しく答えられるかを見る振る舞いの試験を挙げています。また、点数を手がかりに働きかけを少しずつ変えていく、進化型の試験の仕組みもあると書かれています。この記事では、個々の働きかけの文面や、試験項目の具体的な中身は扱いません。防御側に必要なのは、何の種類の弱さを確かめられるかという見取り図のほうです。

ここで押さえたいのは、Humanbound の試験は本物の窓口に、本物の通信として届くという点です。試験の相手の側では、通常の利用者の会話と同じように処理され、記録が残り、場合によっては道具が実際に呼び出されます。本番の窓口や、実在の顧客の情報につながった環境に向けて試験を流すと、試験そのものが事故の原因になりかねません。試す環境の選び方は、後の節で改めて触れます。

仕組み2：「してよいこと・いけないこと」を物差しにする

Humanbound の採点の物差しになるのが、エージェントの業務の範囲を書いた定義です。READMEによると、エージェントが何のためのものか、何をしてよいか、何をしてはいけないかを並べて定義し、してはいけないことの一覧が、一般的な脱獄の試験を、その業務に合わせた道具の悪用の試験に変えると説明されています。定義は利用者が書くほか、自動で読み取る仕組みもある、とされています。

これは、防御の考え方としても筋が通っています。どれだけ巧妙な働きかけでも、問題になるのは「その業務で許していないことをしてしまうかどうか」です。守るべき境目を先に言葉にしておかないと、試験は何も判定できないとも言えます。逆に言えば、この定義が曖昧なら、試験の結果も曖昧になります。

ただし、業務の範囲を自動で読み取る仕組みに任せきりにするのは避けるべきです。自動で読み取った範囲は、エージェントの今の振る舞いを写したものになりやすく、本来許してはいけない操作が「してよいこと」に紛れ込む可能性があります。してよいこと・いけないことの最終的な一覧は、業務の責任者と情報セキュリティの担当者が決めて文書にするのが、試験を意味のあるものにする前提です。

仕組み3：点数・評価・会話の記録で結果を返す

試験の結果は、0〜100の点数と、AからFまでの評価で示されます。提供元の文書によると、点数は見つかった問題とその重さ、試験が及んだ範囲をもとに計算され、手元で動かす場合も提供元の基盤を使う場合も同じ計算式です。ほかに、会話の全部の記録、見せるための HTML の報告書、機械で扱える JSON の出力が用意されています。

問題があったかどうかの判定は、提供元の文書で「判定役としての大規模言語モデル」と呼ばれる仕組み、つまり別のAIに会話を読ませて判定させる方式で行われます。判定役のAIは便利ですが、見落としも、問題のない答えを問題ありとする取り違えも起こりえます。判定役がどの程度誤るかを示す数値は、確認した一次情報の範囲では見当たりませんでした。

そのため、点数は「この範囲の試験で、判定役のAIが問題を見つけた量」の目安であって、安全の証明ではないと読むのが妥当です。重い問題とされた会話は人が記録を読み、本当に範囲を越えたのかを確かめます。逆に、点数が高くても、試していない種類の働きかけや、試していない道具については何も言えません。

試験の結果を守りの規則に変える仕組み

Humanbound のもう一つの特徴が、試験で見つかった失敗を、本番で働く守りの規則に変える流れです。READMEによると、試験の結果から守りの規則を書き出し、同じ提供元の別のOSS「humanbound-firewall」の方針の文書や、利用者のエージェントに合わせた判別の部品の学習に使えます。READMEは、この流れを閉じられるOSSはほかにない、と書いていますが、これは提供元自身の主張で、第三者が確かめたものではありません。

humanbound-firewall は Apache-2.0 で公開された、AIエージェントの前段に置く入力の関所です。READMEによると、制御用の文字や見えない文字を取り除く段、手元で動く判別の部品の段、自社の試験の結果で学習させた判別の段、判断がつかないときだけ判定役のAIに回す段の四つで、利用者の発言だけでなく、ウェブのページや道具の結果、記憶から戻ってくる情報も区別して確かめる、とされています。判定がつかないときに通さない動き方と、記録だけを取る動き方も選べます。

一方で、humanbound-firewall は0.3系の試行版と明記され、1.0までは部品の取り決めや名前が変わりうると書かれています。試験の結果から作った規則は、試験で見つかった失敗には効いても、まだ見つかっていない失敗には効きません。「試験で落ちたものを塞いだ」ことと「守れている」ことは別であり、規則の追加は人が中身を確かめてから本番に入れる、という手順を残す必要があります。

手元で動かす形と、提供元の基盤につなぐ形

提供元の文書によると、手元で動かす形では、試験の仕組み・判定役・点数の計算がすべて利用者の端末の中で動き、ログインも提供元への通信も要らない、とされています。結果は端末の中に保存されます。ただし、試験の通信は試す相手の窓口へ、働きかけの文面と答えは利用者が選んだ大規模言語モデルの事業者へ送られます。手元で動く Ollama のモデルと手元のエージェントを組み合わせれば、外へは何も出ない、と書かれています。

提供元の基盤につなぐ形では、ログインが必要になり、組織・案件・試験の単位で結果を管理できます。基盤だけの機能として、見つかった問題を「未対応・古い・修正済み・再発」の状態で追う仕組み、点数の推移、継続的な監視、複数の会話をまたいだ情報の漏れの検出、提供元が用意するモデルの利用が挙げられています。開発の自動の流れ、ログを集めて監視する仕組み、MCP との連携も基盤側の機能として案内されています。下の表は、一次情報をもとにした整理です。

観点	手元で動かす形	提供元の基盤につなぐ形
ログイン	不要	必要（組織・案件・試験の単位で管理）
試験の結果の置き場所	利用者の端末の中	提供元の基盤（詳細な保存場所・期間は要確認）
働きかけと答えの行き先	選んだモデルの事業者。手元のモデルなら外に出ない	提供元が用意するモデルを選べる
問題の追跡・点数の推移	なし（その回の結果のみ）	状態の管理と推移、継続的な監視
守りの規則の書き出し	使える	より詳しい出力とされる
利用状況の情報（後述）	既定で送られる。止められる	既定で送られる。ログイン後はアカウントと結びつく

表から分かるのは、手元の形は情報の行き先を絞りやすく、基盤の形は継続的な管理がしやすいという構図です。試験の会話には、自社のエージェントの指示や社内の情報の断片が出てくることがあるため、どちらを使うかは、試験の記録を社外に置いてよいかで決めるのが筋です。基盤の料金の枠や、記録の保存期間の詳しい条件は、確認した一次情報には見当たりませんでした。検討の時点で提供元に確かめてください。

練習用の「わざと弱いエージェント」の扱い

Humanbound には、試験の様子を見るための練習用の仕組みもあります。READMEと提供元の文書によると、わざと弱く作ったエージェントをコンテナ（ほかの処理から区切って動かす小さな実行環境）で手元に立て、試験の相手にできます。文書は、これらのエージェントは攻撃されるために作られ、一部はわざと悪意のある動きをすると書いています。

提供元は、外への通信を決めた行き先だけに絞る、管理者の権限を持たせない、資源の上限を置く、といった区切りを用意し、確認に通らないものは止めるとしています。そのうえで、区切りはできる限りのもので、コンテナは仮想の計算機ではないと明記し、機微な情報や重要な仕組みに触れられる場所では動かさないこと、本物の認証情報を渡さないこと、利用は自己責任で保証はないことを書いています。

社内で練習に使うなら、業務の端末ではなく、社内の網から切り離した検証用の環境に限るのが無難です。文書自身も、環境によっては、手元の計算機が外に開いている窓口にエージェントが届きうると注意しています。練習用の仕組みを、守りの試験と同じ気軽さで扱わないことが、この機能を使ううえでの前提です。

安全性の評価：注意付きとした根拠

このラインでは、OSSを手元に取り込んだり動かしたりせず、公開されている情報だけで安全性を判定しています。Humanbound の判定は「注意付き」です。

問題の少ない点から挙げます。ライセンスは Apache-2.0 で、OSI承認のものです。公開元は2023年から続く組織のアカウントで、セキュリティの報告の窓口と方針の文書があり、受け付けの連絡は72時間以内、最初の評価は7日以内、公開までの既定の期間は90日と定めています。取り込むと自動で動く処理の有無を外から調べた範囲でも、目立つ仕掛けは見当たりませんでした。スターの伸びも緩やかです。

注意を付けた理由は三つです。一つ目は、認証情報が転送先へ漏れうる高深刻度のセキュリティ勧告が公開されていることです（次の節で詳しく見ます）。二つ目は、提供元の基盤や、利用者が選ぶモデルの事業者など、外部の仕組みとつながる前提の部分があることです。三つ目は、利用状況の情報が既定で送られることです。なお、ここで問題が見つからなかった点があっても、それは安全の保証ではありません。導入するなら、自社でも確かめてください。

勧告GHSA-7fx2-gfrp-pqvx：認証情報が転送先へ漏れうる問題と修正状況

2026年9月24日に公開された勧告によると、2.7.0より前の版では、試す相手のエージェントとやり取りする部分が、通信の転送（リダイレクト：別の宛先へ行き先を振り替える仕組み）に従う際に、利用者の認証情報をつけたまま送ってしまうことがありました。深刻度は「高」です。勧告は、影響が出るのは信頼できない窓口を試験の相手にした場合だとし、自分が管理していない窓口に対して該当する版で試験をした人は、使った認証情報を取り替えるよう求めています。

修正は2.7.0（2026年7月22日のリリース）で入り、試す相手とのやり取りと利用状況の送信のすべての経路で転送に従わないように変わりました。転送を前提にしていた窓口は、最終の宛先を指定し直す必要がある、と書かれています。リリースの一覧を見ると、その後の2.8.0ではモデルの事業者や提供元の基盤への通信でも転送に従わないようにし、2.9.0ではログインの連携の受け口を手元に限る修正、認証情報の保存の権限を絞る修正、ログインの失敗の画面の不正な書き込みの修正が「セキュリティ」の項目として並んでいます。

見落とせないのは、旧名の配布物です。勧告によると、旧名の「humanbound-cli」の1系にも同じ問題があり、修正版は出ていません。配布サイトからは2026年7月9日にすべての版が取り下げられましたが、版を固定して入れている環境には影響が残る、と明記されています。なお、勧告のページには識別番号として CVE-2026-102652 が表示されている一方、参考の欄には「割り当て待ち」との記載もあり、番号は改めて確かめる必要があります。

送られる利用状況の情報

Humanbound のコマンドの道具は、既定で利用状況の情報を送ります。プライバシーの文書によると、送られるのは、道具の版、ログインしているかどうか、端末ごとの匿名の識別子、動いている環境の種類、試験の開始や完了などの出来事の種類と、所要時間や見つかった問題の件数などです。送り先は PostHog の欧州の環境（フランクフルト）で、保存は1年とされています。

一方で、端末の名前、利用者名、ファイルの場所、試す相手の宛先、試験の文面、モデルの答え、見つかった問題の文章、設定の中身、鍵の類は送らないと書かれています。接続元の番号はおおよその地域を出すのに使い、保存しないとされています。ただし、ログインした後はアカウントのメールアドレスが結びつけられます。

手元で動かす形について、提供元の文書は「提供元は何も受け取らない」と説明していますが、試験の中身は送らなくても、使ったという事実と環境の情報は既定で送られると理解しておくのが正確です。止める手段は用意されており、自動の試験の流れの中や、画面に出さない動かし方では自動で止まる、とされています。止めたときに一度だけ「止めた」という知らせが送られる例外も、文書に書かれています。

悪用されうるリスク

Humanbound は自社の守りを確かめるための道具ですが、攻撃に見立てた働きかけを自動で組み立てる性格上、許可のない相手に向ければ、そのまま他者への攻撃になるという面を持ちます。社外のサービスの窓口や、取引先のエージェントに無断で試験を流せば、利用規約への違反や、不正なアクセスとして問題になる可能性があります。

もう一つは、試験の道具が預かる情報が狙われる危うさです。試験の設定には、試す相手の窓口の認証情報や、モデルの事業者の鍵が入ります。今回の勧告は、試験の相手の側に転送を仕込まれると、試験をする側の鍵が持ち出されうるという形で、この危うさが現実になりうることを示しました。攻撃に見立てた試験をする側も、攻撃の対象になりうるということです。

さらに、試験の結果そのものが機微な情報になります。会話の記録には、エージェントが範囲を越えて漏らした内容や、弱点がどこにあるかがそのまま残ります。結果の報告書が社内で広く共有されたり、社外の基盤に置かれたりすると、弱点の地図として悪用されかねません。ここに挙げたものは一般的な想定で、Humanbound について悪用の事例を確認したものではありません。

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

Humanbound のような試験の道具を検討するときは、機能の多さより先に、試す対象・情報の行き先・道具の版の三点を確かめます。次の順で進めると、後からの食い違いを防げます。

企業が取るべき対策

一つ目は、攻撃に見立てた試験を、社内の規程で「許可制の作業」として扱うことです。試験してよい対象は自社のもの、または許可を得たものに限り、対象・期間・担当者・承認者を記録に残します。社外の窓口や、許可の範囲を越えた相手への試験は禁止と明記します。

二つ目は、試験の道具を、鍵を預かる仕組みとして管理することです。試験用の認証情報は使い捨てに近い形で発行して終わったら止め、道具の版は勧告を見ながら更新します。今回のように修正版が出ている勧告は、版を上げれば解消しますが、旧名の配布物のように修正版がないものは、取り除くしかありません。三つ目は、試験の結果の扱いです。会話の記録と報告書は自社の弱点の地図として、閲覧できる人と保存期間を決めて管理する対象にします。

四つ目は、試験を一度で終わらせないことです。エージェントの指示や道具、使うモデルを変えれば、振る舞いも変わりえます。変更のたびに同じ範囲の定義で試験をし直し、点数の上下ではなく、どの境目が新たに破られたかを見ます。五つ目は、調達の確認です。提供元の基盤を使うなら、記録の保存場所と期間、契約の条件、提供が止まったときに結果を持ち出す手段を、入る前に確かめておきます。

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

Humanbound は、働きかけの組み立ても、判定も、守りの規則の書き出しもAIを使って進める道具です。だからこそ、どこまでをAIに任せ、どこからを人が決めるかを先に決めておく必要があります。次のような使い方は避けてください。

• 試験してよい対象や期間を決めないまま、思いついた窓口に試験を流す
• 業務の範囲の定義を自動で読み取らせ、中身を確かめずに採点の物差しにする
• 判定役のAIの点数や評価だけを見て、会話の記録を読まずに出荷を決める
• 試験の結果から書き出した守りの規則を、人が確かめずにそのまま本番に入れる
• 古い版や旧名の配布物を使い続け、勧告を確かめない

人が決めるべきなのは、試験してよい対象、してよいこと・いけないことの境目、出荷してよい基準、本番に入れる規則の四つです。AIに任せてよいのは、決められた範囲の中での働きかけの組み立てと、問題があると判断した根拠を会話の記録とともに示すところまでです。判定役のAIには根拠を書かせ、その根拠と記録を人が読んで、本当に範囲を越えたかを確かめます。AIに出荷の可否を判断させない、という線を引いておくことが、この種の道具と付き合う基本です。

よくある質問：点数が高ければ出荷してよいのか

答えは「判断の材料の一つにはなるが、それだけで決めてはいけない」です。点数は、その回の試験の範囲で、判定役のAIが見つけた問題の量と重さをもとにしたものです。試していない種類の働きかけ、試していない道具、判定役が見落とした会話については、何も保証しません。

出荷の判断には、点数に加えて、重い問題とされた会話を人が読んだ結果、直した後の再試験の結果、試験が及んでいない範囲の一覧を並べます。そのうえで、出荷してよい基準を、試験の前に業務の責任者と決めておくことが大切です。試験の後で基準を決めると、点数に合わせて基準を動かしてしまいがちだからです。

• Humanbound の機能・手元の形と提供元の基盤の違い・練習用の仕組み・利用状況の情報の扱いは、GitHub のリポジトリ（README・リリースの一覧・セキュリティとプライバシーの文書）と提供元の文書を2026年10月26日に確かめた範囲に基づきます。版の更新で変わる可能性があります
• 勧告の修正状況は、勧告のページとリリースの一覧で確かめた範囲です。識別番号の表示に食い違いがあるため、最新の状態は勧告のページで確かめてください
• 提供元の所在地や運営体制、基盤の料金と記録の保存期間、判定役のAIの誤りの割合は、確認した一次情報の範囲では確かめられませんでした。この記事は導入や操作の手順を扱いません

まとめ

Humanbound は、自社のAIエージェントに会話を重ねて働きかけ、決めた業務の範囲を守れるかを出荷前に試験する Apache-2.0 のOSSです。結果は点数と会話の記録で返り、見つかった失敗を本番の前段に置く守りの規則に変える流れも用意されています。手元だけで動かす形と、問題の追跡や継続的な監視ができる提供元の基盤につなぐ形があり、試験の記録をどこに置くかで選び分けられます。

一方で、認証情報が転送先へ漏れうる高深刻度の勧告があり、2.7.0で修正済みですが、旧名の配布物には修正版がありません。利用状況の情報も既定で送られます。点数と判定は判定役のAIによるもので、安全の証明ではありません。試験してよい対象を自社のものと許可を得たものに限り、道具の版と鍵を管理し、境目と出荷の基準は人が決め、記録を人が読んで直すことが、Humanbound を自社の守りに役立てる現実的な付き合い方です。

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