自社のAIが不正な指示や脱獄に耐えるかを出荷前に点検するOSS「Augustus」を解説

「自社の問い合わせ窓口に組み込んだAIを来月から社外に開く。その前に、隠れた命令や脱獄の働きかけにどこまで耐えるか、一度まとめて測っておきたい」「モデルの提供元が安全対策をしているはずだから、自社で確かめるのは二度手間ではないか」——生成AIを自社の製品や業務の仕組みに組み込む段階に入った企業で、開発とセキュリティの担当者のあいだから聞こえてくる声です。大事なのは、検査の道具を一つ回して合格の印をもらうことではありません。本当は、提供元の安全のための学習と、自社の使い方での攻撃への耐性は別物であり、後者は自社で測って人が判断するしかないという点です。この記事では、攻撃に対する点検を専門とする米国のセキュリティ企業 Praetorian が公開した検査用のOSS「Augustus」について、作り手と開発の経緯、対応する接続先と検査の範囲、結果の扱い、使う前に社内で決めることを、一次情報で確かめられる範囲で整理します。導入や操作の手順、検査項目の具体的な中身は扱いません。

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

Augustus は、GitHub上で公開されている大規模言語モデル（大量の文章から学習し、文章を生成するAI）の検査用のOSSです。READMEでは、紛れ込んだ命令（プロンプトインジェクション）、脱獄（AIの安全のための制限を外させる働きかけ）、文字の符号化を使ったすり抜け、情報の引き出しなど、攻撃の働きかけに対してモデルがどこまで耐えるかを試し、弱いところを報告書にまとめる道具と説明されています。対象として想定されているのは、セキュリティの専門家です。

公開の時期と規模も確かめておきます。リポジトリは2026年2月6日に作られ、作り手の公式ブログでも同じ日に公開が告知されました。2026年10月22日時点で、スターはおよそ310、複製（フォーク）は43、記録された変更はおよそ210件です。リリースの一覧は12ページにわたり、最新は2026年10月3日の0.14.34版です。持ち主は Praetorian の組織アカウントで、2014年7月に作られ、公開リポジトリは93あります。

ライセンスは Apache-2.0 で、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。著作権者は Praetorian Security, Inc. と記されています。スターの伸びは1日あたり1前後と緩やかで、急な水増しをうかがわせる動きは見られません。日本語での紹介は、確認した範囲ではほとんど見当たりませんでした。

作り手のPraetorianと、この道具が生まれた経緯

Praetorian は、READMEの末尾で「攻撃の観点からのセキュリティの解決策を提供する会社」と紹介されている米国の企業です。公式ブログによると、Augustus は同社の12週にわたって毎週一つずつOSSを公開する企画の2本目として出されました。1本目の「Julius」は、ある窓口の裏でどの大規模言語モデルのサービスが動いているかを見分ける道具で、Augustus はその次の段階、つまり見分けたサービスが攻撃に耐えるかを試す段階を受け持つと説明されています。

開発の動機について、公式ブログは、多くの大規模言語モデルが攻撃を想定した検査を経ないまま使われていること、そして安全のための学習は、セキュリティの検査と同じではないことを挙げています。既存の検査用OSSは研究や評価の場でよく役立っているとしたうえで、自社の検査担当者が侵入テスト（攻め手の目線で弱点を確かめる検査）の仕事の流れにそのまま組み込める、軽く持ち運べる道具がほしかったと書かれています。

ここから読み取れるのは、Augustus が攻撃の専門家が顧客の仕組みを点検する現場で使うことを前提に作られているという性格です。研究用というより実務用の道具であり、だからこそ、自社で使う場合も「誰が、どの範囲で、何の許可を得て使うか」を、ほかの侵入テストの道具と同じ水準で管理する必要があります。これは記事の筆者の読み取りであり、作り手が明言しているわけではありません。

どんな問題に応えるのか：提供元の安全対策と、自社の使い方での耐性

生成AIを自社の仕組みに組み込むと、モデルそのものの性質に加えて、自社が書いた指示文、つないだ社内の文書、AIに渡した道具の権限が組み合わさります。提供元がモデルに安全のための学習をしていても、自社の指示文や接続の仕方によって、想定外の振る舞いが表に出ることがあるのはこのためです。

こうした危険を整理した代表的な一覧が、OWASP（ウェブの安全性に関する国際的な非営利の団体）による、大規模言語モデルを使う仕組みの主要な危険の一覧です。紛れ込んだ命令、機微な情報の開示、出力の扱いの危うさ、過大な権限などが並んでいます。Augustus の検査の系統も、こうした危険の多くに対応する形で組まれています。

もう一つの論点は、測り直しです。モデルの版の入れ替え、指示文の改訂、参照する文書の追加のたびに、振る舞いは変わりえます。一つの実行ファイルで動き、同時に多数の検査を流せる Augustus の作りは、出荷前の一回だけでなく、変更のたびに同じ物差しで測り直す使い方と相性がよいと考えられます。ただし、定期の実行を組み込む機能は README や公式ブログでは特に説明されておらず、運用の形は使う側が決めることになります。

対応範囲1：28系統の接続先と、社内の独自の窓口

READMEによると、Augustus は28系統の接続先、細かく分けると43種類の接続の部品を持っています。OpenAI、Anthropic、Azure の OpenAI のサービス、Amazon の Bedrock、Google の Vertex など主要な事業者のモデルに加え、推論の基盤を貸し出す各社のサービス、NVIDIA の推論や安全対策の仕組み、さらには会話の仕組みを組み立てる枠組みとの接続も一覧に並んでいます。

防御側にとって大きいのは、汎用のウェブの窓口（REST）を相手にできる点です。READMEの説明では、宛先、送り方、送る中身のひな形、返ってきた答えのどこを読むかを設定すれば、任意の窓口を検査の相手にできます。例には、社内の独自の窓口を想定したものも含まれています。つまり、提供元のモデルそのものではなく、自社が指示文や社内の文書を組み合わせて作った「自社のAIの窓口」を、外から見えるのと同じ形で点検できるということです。

また、手元のパソコンやサーバーで動かす Ollama のモデルは、外部の鍵なしで検査できるとされています。社外の事業者に検査の働きかけを送りたくない段階、たとえば開発中の試作を確かめる段階では、手元のモデルで先に傾向を見るという使い分けが考えられます。どの接続先を使うかは、検査の働きかけと答えが、どの事業者のもとを通るかを決めることでもあります。

対応範囲2：47系統・210超の検査項目と、会話を重ねる検査

検査の一つひとつの項目は「プローブ」と呼ばれます。READMEによると、Augustus は47の系統にわたって210を超えるプローブを持ち、脱獄、紛れ込んだ命令、攻撃文の自動生成、情報の引き出し、文脈の操作、出力の形式を突く働きかけ、検知のすり抜け、安全性の評価用の問題集、AIエージェントを狙う働きかけなどに分けられています。この記事では、個々の検査項目の名前や文面、手口の中身は扱いません。防御側に必要なのは、どの種類の弱さを測れるかの見取り図のほうです。

特徴的なのは、検索で参照する社内の文書に細工されたときの耐性や、複数のAIエージェントが連携する仕組みへの働きかけなど、モデル単体ではなく、AIを組み込んだ仕組み全体の弱さを意識した系統が含まれていることです。社内の文書をAIに参照させる仕組み（RAG）や、AIに道具を渡して作業させる仕組みを持つ企業にとっては、点検の観点を広げる手がかりになります。

また、一度の働きかけで終わらず、会話を何往復も重ねながら少しずつ相手の制限を緩めていく種類の検査もあります。READMEによると、この種類の検査では、攻撃役・検査の相手・判定役の三つの大規模言語モデルを使い、判定役が進み具合を点数で評価します。さらに、同じ検査項目を符号化・言い換え・利用者の少ない言語への翻訳などで形を変えて送る7種類の変換の仕組みもあり、表面の言い回しだけを止める対策では足りないかを確かめられる作りです。

判定の仕組み：90超の判定部品と、判定役のAI

働きかけへの答えに問題があったかどうかは、「ディテクター」と呼ばれる判定部品が決めます。READMEによると、判定部品は90を超え、決まった文字の並びを探すもの、別の大規模言語モデルに判定させるもの、有害さを評価する外部の仕組みを使うものなどがあります。

判定役のAIは、検査の相手とは別のモデルとして設定する仕組みです。READMEには、判定役が「問題なし」と見落とすのを補うため、二つ目の判定役を加える設定も用意されていると書かれています。判定役のAIも誤りうることを、作り手自身が前提にしていると読めます。

ここで押さえたいのは、判定役のAIを使うと、検査の相手とは別に、もう一つの事業者へ働きかけと答えが送られうる点です。判定役に外部の事業者のモデルを選べば、検査の記録はその事業者のもとも通ります。判定役のモデルの選び方は、精度だけでなく、データの扱いの決まりとあわせて決める必要があります。

結果の扱い：表・JSON・HTMLの報告と、読み方の注意

検査の結果は、既定では画面の表で示され、ほかに JSON とその1行ずつの形式、そして関係者に見せるための HTML の報告書で出力できるとされています。READMEの出力例では、検査項目と判定部品の組み合わせごとに、合格したかどうか、点数、そして「弱い」か「安全」かの状態が並んでいます。

注意したいのは、READMEには、点数の意味や、どの点数から「弱い」とするかの境目の説明が見当たらないことです。会話を重ねる検査については、判定役の点数が既定で0.8を超えると打ち切る設定が示されていますが、全体の合否の基準は確認できませんでした。結果の表の「安全」は、その検査項目とその判定部品の組み合わせでは問題が見つからなかった、という意味にとどまると考えるのが妥当です。

また、READMEの安全に関する節は、検査の結果に、検査の相手のモデルが生成した有害な内容が含まれうると明記しています。ある検査項目は、検査のために汚い言葉や攻撃的な言葉を使うとも警告されています。報告書を社内に回すときは、要約と判断は広く共有し、働きかけと答えの全文は担当者に限って保管するといった扱いを、あらかじめ決めておくことが望まれます。

比べる表：garak・promptfoo・Augustusの違い

同じ種類の検査用OSSには、NVIDIA の「garak」や「promptfoo」があります。READMEの比較表と公式ブログによると、Augustus は garak に着想を得て Go 言語で一から作り直したもので、garak をそのまま移したものではないと説明されています。下の表は、READMEと公式ブログが示す数字をもとに、防御側に関係する観点を並べたものです。数字はいずれも作り手の自己申告であり、数え方は道具ごとに異なりうる点に注意が必要です。

観点	garak（NVIDIA）	promptfoo（参考）	Augustus（本記事）
作りの言語	Python言語	TypeScript言語	Go言語
配り方	動かす環境の準備が要る	動かす環境の準備が要る	一つの実行ファイル
接続先の数（作り手の申告）	35超	80超	28系統
検査項目の数（作り手の申告）	160超	119の部品と36の戦略	210超
主な想定	研究・評価	開発の現場と企業	侵入テストの実務と企業

表から分かるのは、Augustus の強みが持ち運びやすさと、侵入テストの現場への組み込みやすさにあることです。公式ブログ自身も、garak のほうが研究の蓄積が長く、論文も出ていると認めています。検査項目の数の多さだけで優劣を決めず、自社の検査の目的、社内で回せる体制、データの扱いの決まりに合うかで選ぶのが現実的です。

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

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。Augustus の判定は「注意付き」です。ライセンスは OSI 承認の Apache-2.0、持ち主は2014年からの活動の記録がある企業の組織アカウントで、確認した時点でセキュリティ勧告は公開されていません。

それでも注意付きとした根拠は、210を超える攻撃の働きかけを、実際に動く形でまとめて収めた検査の道具であることです。自社の点検には欠かせない一方で、扱いを誤れば他者の仕組みへの攻撃にそのまま使えます。精査の範囲では、導入の際に自動で動く処理の仕組みは見当たらず、取得の段取りを書いた補助のファイルがあるだけでした。

ただし、勧告が出ていないこと、自動で動く処理が見つからなかったことは、安全の保証ではありません。この道具は、外部の事業者の鍵を扱い、大量の通信を流し、有害になりうる答えを記録します。検査の道具であっても、ほかの業務用のソフトウェアと同じ確認を経て使うべきです。

注意点の詳細：1.0前の版・脆弱性の報告窓口・通信の確認機能

一つ目は版の番号です。最新は0.14.34版で、まだ1.0に届いていない版です。リリースは12ページにわたり、更新の頻度は高めです。2026年9月から10月の更新は、自動の検査の仕組みの調整が多くを占めていました。1.0前の版では、設定や結果の形式が予告なく変わる可能性があるため、検査の結果を版をまたいで比べるときは、使った版を必ず記録に残しておくと後で迷いません。

二つ目は、脆弱性を見つけたときの報告の窓口です。READMEの安全に関する節では、セキュリティの問題は GitHub 上の公開の課題管理の欄で報告するよう案内されています。確認した範囲では、非公開で報告するための専用の窓口の案内は見当たりませんでした。道具自体に弱さが見つかった場合、修正より先に内容が公開の場で知られる可能性がある点は、版の更新を追う担当者が知っておくべきことです。

三つ目は、通信の中身を確かめるための中継の機能です。READMEによると、検査の通信を中継の仕組みに通して確かめる設定があり、その場合は暗号化された通信の相手を確かめる処理（TLSの検証）が無効になると書かれています。社内の検証の場でだけ使い、本番の環境や社外の回線では使わないといった線引きを決めておくべきです。このほか、リリースノートにはAIに道具をつなぐ規格（MCP）に関わる修正も見られますが、READMEには説明がなく、機能の範囲は確かめられませんでした。

悪用されうるリスク

検査の道具は、立場を変えれば攻撃の道具にもなる二面性を持ちます。Augustus は、汎用のウェブの窓口を検査の相手にでき、一つの実行ファイルで持ち運べるため、許可のない他者のAIの窓口に向けて使われる可能性は否定できません。これは推測であり、そうした使われ方の報告を確認したわけではありません。READMEは、検査してよいのは自分が持つ仕組みか、明確な許可を得た仕組みだけだと明記しています。

作り手の企画全体を見ると、1本目の Julius で窓口の裏のサービスを見分け、2本目の Augustus でその耐性を試す、という流れが示されています。守る側から見れば、社外に開いた自社のAIの窓口も、同じ流れで外から調べられ、試されうるということです。既知の脱獄や紛れ込んだ命令の手口は、すでに公開の研究や報告として広く出回っており、この道具に固有の危険というより、すでにある現実を映したものと見るのが妥当でしょう。

社内での悪用の余地も考えておく必要があります。検査の名目で、社員が許可なく取引先や他社のAIの窓口を試すことは、契約や法律の上の問題になりえます。道具を使える人、試してよい相手、記録の残し方を社内の決まりとして書いておくことが、自社を守ることにもつながります。

検査の費用と、外部の事業者に送られるもの

Augustus は、同時に流す検査の数（既定は10）、接続先ごとの送る頻度の上限、失敗したときの再試行、検査全体と項目ごとの時間の上限を設定できるとされています。これらは検査を効率よく回すための機能ですが、裏返せば、短い時間に大量の働きかけを事業者へ送る道具だということでもあります。

公式ブログは、攻撃文を何度も作り直す種類の検査は、一つの検査に多数の呼び出しが要るため計算の負担が大きいと認めています。READMEにも、会話を重ねる検査では費用が膨らみうることへの注意が載っています。外部の事業者の有料のモデルを相手にする場合は、検査専用の鍵を用意し、利用額の上限を先に決めておくことで、想定外の請求と、鍵が漏れたときの影響の両方を小さくできます。

また、既知の脱獄の働きかけを大量に送る行為が、事業者の利用規約に照らして問題にならないかも、事前に確かめておくべき点です。道具から作り手へ利用の情報が送られるかどうかについては、確認した一次情報には記載が見当たりませんでした。送られないと確かめられたわけではなく、確認できる情報がないという状態です。

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

Augustus を社内の点検に使うかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

Augustus を使うかどうかにかかわらず、AIの検査の道具を社内に置く企業が取るべき対策は共通しています。第一に、検査の道具を、侵入テストの道具と同じ扱いで台帳に載せることです。使う人、置き場所、版、登録した鍵を記録し、持ち出しや私的な利用を禁じます。

第二に、社外に開くAIの窓口には、出荷前の点検を条件にすることです。点検の結果と、見つかった弱さへの対応を記録に残し、公開の可否を決める人を明確にします。第三に、検査の結果に含まれる有害な答えや攻撃の働きかけの記録を、通常の業務文書より厳しい閲覧の範囲で保管します。

第四に、モデルの入れ替えや指示文の改訂を、測り直しのきっかけとして手順に組み込みます。第五に、自社の窓口が外から試されうる前提に立ち、利用の記録に、短い時間に似た働きかけが続くといった不自然な使われ方が残っていないかを見る観点を、監視の手順に加えます。道具を入れることより、道具を回す決まりと、結果を受けて直す流れを先に作ることが、守りを続けるための要点です。

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

Augustus は、多数の働きかけを自動で送り、答えを判定部品や判定役のAIが評価し、会話を重ねる検査では攻撃役にもAIを使う道具です。効率のよい設計ですが、点検の結果を最終的な判断としてAIに委ねてはいけません。AIに任せてよいのは、大量の働きかけを試し、怪しい答えを拾い上げるところまでです。

人が決めるのは、何を検査の相手にするか、どの結果を問題とみなすか、何を直すか、どこまで試したら出荷してよいとするかです。判定役のAIを使う場合は、判定の根拠となるやり取りを記録に残させ、問題とされた答えも問題なしとされた答えも、人が抜き取りで読んで確かめることを手順に入れます。避けたい使い方を挙げます。

• 結果の表に「安全」が並んだことだけを理由に、AIの窓口を出荷してよいと判断する
• 判定役のAIが問題なしとした答えを、誰も読まずに合格として扱う
• 許可を得ていない取引先や他社のAIの窓口を、検査の相手として設定する
• 通信の中身を確かめる中継の設定を、本番の環境でもそのまま使い続ける
• 使った版を記録しないまま、前回と今回の結果を並べて改善を判断する

どの例も、道具の能力ではなく運用の決まりで防げる失敗です。人が確認する範囲を先に決めておくことが、点検を意味のあるものにします。

よくある質問：一つの実行ファイルで動くなら、導入は気軽でよいのか

答えは「導入の手間が小さいことと、管理の手間が小さいことは別」です。一つの実行ファイルで動く作りは、動かす環境の準備がほとんど要らないという利点がありますが、同時に、社員が個人の端末に持ち込んで、管理の外で使えてしまうということでもあります。侵入テストの道具と同じく、使ってよい人と場所を決めたうえで使うべき道具です。

もう一つ、「検査で弱さが少なければ、自社のAIは安全と言えるのか」という問いもありそうです。結果は、収められた検査項目と判定部品の組み合わせの範囲で持ちこたえた、という意味にとどまります。検査項目の外にある新しい手口は測れず、判定部品が見落とす答えもありえます。提供元がモデルを更新すれば、同じ設定でも結果は変わりえます。

では点検に意味がないのかというと、そうではありません。同じ物差しで繰り返し測り、変更の前後で結果がどう動いたかを見ることは、指示文の改訂やモデルの入れ替えの判断材料になります。「安全の証明」ではなく「弱いところを見つけ、変化を追う道具」として位置づけるのが現実的です。

• Augustus の機能・接続先・検査の範囲・結果の形式・安全に関する注意は、GitHubのリポジトリ（README・リリースの一覧）と Praetorian の公式ブログ、garak のリポジトリ、OWASP の一覧を2026年10月22日に確かめた範囲に基づきます。1.0前の版で更新が多く、内容は変わる可能性があります
• 点数の意味と合否の境目、道具から作り手へ送られる情報の有無、MCPに関わる機能の範囲は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、検査項目の具体的な文面・手口は扱いません

まとめ

Augustus は、攻撃の観点からの点検を専門とする Praetorian 社が、2026年2月に Apache-2.0 で公開した大規模言語モデル向けの検査用OSSです。Go 言語の一つの実行ファイルで動き、28系統の接続先と社内の独自の窓口を相手に、47系統・210超の検査項目と90超の判定部品で、紛れ込んだ命令や脱獄への耐性を点検できます。

一方で、作り手自身が侵入テストの実務のために作った道具であり、結果には有害な内容が含まれえ、判定の境目の説明は限られ、版はまだ1.0に届いていません。試してよい相手と、働きかけが通る先を先に決め、使った版と結果を記録し、判定は人が読んで確かめることが、Augustus を自社のAIの出荷前の点検に生かすための現実的な付き合い方です。

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