大規模言語モデルの入出力を検査するOSS「Guardrails」の仕組みと導入前の注意点

「社内向けのAIチャットに、競合他社の名前や乱暴な言葉が出てこないか心配だ。出力を一件ずつ人が見るわけにもいかない」「AIの回答を別のシステムに渡したいのに、決めた形式で返ってこないことがあって、後ろの処理が止まる」——生成AIを業務のアプリに組み込み始めた開発部門と、それを見守る情報システム部門の双方から挙がる声です。どちらも、AIのモデルを賢くすれば解決する問題のように見えます。しかし本当は、モデルの性能の問題ではありません。AIの出力を、使う前に誰がどの基準で確かめるのかが決まっていないことが問題です。この記事では、大規模言語モデル（文章を生成するAIのモデル）への入力と出力を検査するOSS「Guardrails」を取り上げ、その仕組みと、2026年5月に起きた配布版の乗っ取りの経緯を含めた導入前の注意点を、公開されている一次情報に基づいて整理します。導入や設定の手順は扱いません。

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

Guardrailsは、大規模言語モデルを使うアプリに検査の層を足すための、プログラミング言語Python向けの枠組みです。リポジトリの説明文は、その働きを二つに分けています。一つは、アプリの中で入力と出力の「ガード」を動かし、特定の種類のリスクを検出し、程度を測り、和らげること。もう一つは、大規模言語モデルから決まった形式のデータを生成させることです。

公開元と規模を確かめておきます。リポジトリは2023年1月29日に作られ、現在は組織のアカウントの下にあります。2026年10月20日時点でスターは7,539、フォーク（派生版）は727、最後の更新は2026年10月15日です。運営元の組織アカウントには公開リポジトリが97件あり、検査器などの関連する部品も同じ組織から公開されています。ライセンスはApache-2.0で、商用の利用を含めて広く認められた条件です。

説明文の更新情報からは、運営の動きも読み取れます。2025年2月には、24種類のガードを6つの分野で比べた性能と速度の比較表を公開したとされています。2026年7月には、検査器の配布の仕組みを変え、運営元が提供してきた遠隔での推論をやめると告知しました。この変更は後の章で詳しく扱います。

なぜ大規模言語モデルの入出力に検査の層が要るのか

大規模言語モデルの出力は、同じ入力に対しても毎回少しずつ変わります。多くの場合は期待どおりでも、ときどき外れた出力が混じります。社内向けの文書の要約に個人の連絡先がそのまま残る、問い合わせへの回答に競合他社の名前が出る、決めた形式で返すはずのデータに項目が欠ける、といった具合です。外れが少ないことと、外れがないことは別の話です。

この外れを、モデルへの指示文の工夫だけで抑えようとすると限界があります。指示文はモデルへのお願いにすぎず、守られたかどうかは別に確かめる必要があるからです。そこで、モデルの外側に、出力を機械的に確かめる仕組みを置くという考え方が広がりました。Guardrailsは、この「外側の検査」を部品として組み立てられるようにしたものです。

入力の側にも同じ発想が当てはまります。利用者が入れた文章に、外へ出してはいけない情報や、モデルの動きを乗っ取ろうとする文が含まれていないかを、モデルに渡す前に確かめる。説明文が入力と出力の両方の「ガード」を挙げているのは、このためです。ただし、どの検査をどこまで行うかは使う側が選ぶもので、Guardrailsを入れただけで何かが自動的に守られるわけではありません。

仕組みの芯：検査器を組み合わせた「ガード」

Guardrailsの中心にあるのは、検査器（説明文では「バリデーター」）と、それを束ねた「ガード」です。検査器は、特定の種類のリスクを測るために作られた部品です。説明文の例には、決めた書式（たとえば電話番号の形）に合っているかを確かめるもの、競合他社の名前が出ていないかを確かめるもの、有害な言葉が含まれていないかを確かめるものが挙がっています。

複数の検査器を一つのガードにまとめると、大規模言語モデルとアプリの間で入力や出力を受け止め、まとめて検査できます。説明文の例では、競合他社の名前と有害な言葉の二つを同時に確かめ、両方に引っかかった文章について、どの検査で何が見つかったかを示しています。検査の結果が理由付きで返ってくるため、なぜ止めたのかを後から説明できる点が、統制の面では大きな意味を持ちます。

検査器の中身はさまざまです。書式の一致のように単純な規則で判定するものもあれば、別の機械学習のモデルを使って文章の性質を推し量るものもあります。後者は判定に時間がかかり、判定そのものが外れることもあります。検査器も一つの判定の仕組みであり、完全ではないという前提で組み合わせを選ぶ必要があります。

検査に失敗したときの振る舞いを選ぶ仕組み

検査で問題が見つかったときにどうするかは、検査器ごとに指定します。公式の文書は、この振る舞いを「失敗時の動作」として次のように整理しています。どれを選ぶかで、利用者に届くものが大きく変わります。

失敗時の動作	公式の文書での説明	統制の観点での見方
例外を出す	検査に失敗した時点で処理を止め、エラーとして返す	止める判断が明確。アプリ側で止まった後の扱いを決めておく
何も返さない	出力を返さず、空の値を返す	安全側に倒せるが、利用者への説明を用意する
取り除く	失敗した項目だけを除き、残りを返す（決まった形式のデータが対象）	何が除かれたかを記録しないと、欠けに気づけない
直す	検査器が直せる場合に、出力を機械的に修正する	修正の中身を記録し、元の出力と比べられるようにする
聞き直す	失敗した基準を添えて、大規模言語モデルにもう一度生成させる	回数の上限を決める。費用と時間が増える
記録だけ	修正はせず、失敗を記録に残す	試行の段階向き。本番でこれだけにしない

このほかに、直したうえで再び検査し、まだ失敗するなら聞き直す組み合わせの動作や、使う側が自前の処理を差し込む方法も説明されています。表から分かるとおり、同じ検査器でも、失敗時の動作の選び方で守りの強さが変わるということです。とくに「記録だけ」は、検査をしているように見えて利用者には何も止めていない状態なので、本番での扱いを先に決めておきたいところです。

「聞き直す」は便利に見えますが、大規模言語モデルへの呼び出しが増えます。回数の上限は呼び出しの際に指定する形になっており、上限をいくつにするかは費用と応答時間の判断です。聞き直しても通らなかった場合に最後はどうするのかまで、人が決めておく必要があります。

出力の形をそろえる：決まった形式のデータの生成

Guardrailsのもう一つの働きが、大規模言語モデルから決まった形式のデータを生成させることです。説明文によれば、使う側が欲しいデータの形（項目の名前と、それぞれの説明）を定義しておくと、ガードがその形に合う出力を得るように呼び出しを組み立てます。

組み立て方は二つ説明されています。モデルが「関数の呼び出し」と呼ばれる決まった形式での応答に対応していれば、その仕組みを使います。対応していなければ、期待する出力の形を指示文に添えて、モデルにその形で返させる方法を取ります。どちらの場合も、返ってきたものを定義した形と照らし合わせ、合わなければ先の「失敗時の動作」が働きます。

この働きは、セキュリティより業務の安定に効く部分です。AIの出力を別のシステムに渡すとき、形が崩れたデータは後ろの処理を止めたり、思わぬ値を書き込んだりします。形の検査は、後ろのシステムを守るための検査でもあると言えます。ただし、形が正しいことは中身が正しいことを意味しません。項目がそろっていても、値そのものが事実と違う可能性は残ります。

独立したサーバーとして置く形と、記録の取り方

Guardrailsは、アプリの中に部品として組み込むだけでなく、独立したサーバーとして動かす形も用意しています。説明文によれば、ガードをサーバーとして立ち上げ、REST API（ウェブの決まった形式での呼び出し口）で検査を受け付けられます。広く使われているAIの呼び出しの書き方から、そのままガードを経由させる例も示されています。

サーバーの形には、検査の基準を一箇所にまとめられる利点があります。部署ごとのアプリがそれぞれ検査器を抱えるより、共通のガードを通すほうが、基準の見直しを一度で済ませられます。一方で、説明文はこれを開発用のサーバーとして紹介しており、本番で使うときにどこまで手を入れる必要があるかは、文書で個別に確かめる必要があります。

記録の取り方についても、公式の文書に説明があります。Guardrailsは、処理の流れを記録する共通の規格に対応しており、ガードと大規模言語モデルの応答時間、ガードの成功率、検査器ごとの合否の割合などを、社内で使っている監視の仕組みへ送れるとされています。どのガードがどれだけ止めているかが見えれば、基準が厳しすぎるのか緩すぎるのかを数字で議論できます。

2026年の大きな変更：検査器の配布の移行と、遠隔での推論の終了

2026年7月6日、運営元はリポジトリの説明文と課題の一覧で、二つの変更を告知しました。一つは、これまで専用の集積場所（ハブ）から入れていた検査器を、Pythonの一般的なパッケージの公開登録所であるPyPIで、個別のパッケージとして配る形に移すことです。もう一つは、運営元が無償で提供してきた、検査器が使うモデルを遠隔で動かすサービスをやめることです。

移行の告知によれば、専用の集積場所からの導入、非公開の検査器の登録の仕組み、遠隔での推論のサーバーは、2026年8月25日を区切りに止まるとされています。ただし、同じ告知の中の移行の説明には遠隔での推論が8月6日に止まるという記載もあり、日付が食い違っています。いずれにせよ、2026年10月の時点では区切りを過ぎています。告知の時点では64種類の検査器のうち50種類がPyPIに移ったとされています。

企業にとっての意味は二つあります。一つは、遠隔での推論に頼っていた検査は、自社の環境でモデルを動かすか、自前の接続先を用意する必要があることです。検査のための計算の費用と、検査対象の文章がどこで処理されるかが変わります。もう一つは、検査器が一般の登録所から個別に入る形になることで、本体だけでなく検査器の一つひとつも、配布元を確かめる対象になることです。この点は、次に扱う勧告とつながります。

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

このラインでは、扱うOSSを公開されている事実だけを基に精査しています。OSSをダウンロードしたり動かしたりはしていません。Guardrailsの判定は「注意付き」です。

根拠の中心は、公開されているセキュリティ勧告です。リポジトリには、配布版の0.10.1に悪性のコードが含まれていたという勧告（CVE-2026-45758）が1件公開されており、重大度は最高区分の「重大」、共通の評価の尺度（CVSS）で9.6とされています。弱点の分類は「悪性のコードの埋め込み」です。

一方で、確かめられた良い点もあります。ライセンスはApache-2.0で、リポジトリは3年以上にわたって組織のアカウントで運営され、2026年10月にも更新されています。リポジトリの直下に、導入の際に自動で動く処理を定める設定は見当たらず、開発用の作業手順をまとめたファイルがあるだけでした。勧告の後、運営元は経緯と対処を文書で公開し、配布の仕組みにも手を入れています。

ただし、問題が見つかったこと、あるいは見つからなかったことは、安全の保証ではありません。この精査は公開情報の範囲に限られ、コードの中身を検証したものではありません。説明文や運営元の文書も、外部の未検証の情報として扱っています。

勧告CVE-2026-45758の中身：配布版の乗っ取りで何が起きたのか

運営元が公開した経緯の文書と勧告によれば、出来事の流れは次のとおりです。2026年5月11日の午後6時ごろ（米国太平洋時間）、悪性のコードを含む0.10.1がPyPIに公開されました。セキュリティの研究者がおよそ2時間で見つけ、PyPIはこのパッケージを隔離しました。勧告は翌12日に公開されています。運営元は、より広い範囲のOSSを狙った一連のサプライチェーン攻撃（配布の経路を狙う攻撃）の一部だったと説明しています。

侵入の経路は、ソフトウェアの弱点ではありませんでした。経緯の文書によれば、社員のGitHubの個人用の鍵が漏れ、それを使って組織内の30のリポジトリで自動処理が動かされ、その結果物から各リポジトリの秘密の情報が取り出されました。取り出された配布用の鍵で、悪性の版が正規の配布元に公開されたという流れです。攻撃者は、検査器の推論に使う計算基盤や、ほかの配布の仕組みへの侵入も試みましたが、成功しなかったとされています。

悪性のコードの働きについて、運営元の勧告と経緯の文書は詳しく書いていません。運営元は、0.10.1から自社の基盤への通信は観測されておらず、記録を調べた範囲では自社の仕組みを通じた利用者のデータの持ち出しの証拠はないとしています。一方、課題の一覧に最初の報告を寄せたセキュリティ企業は、パッケージを読み込んだ時点で、Linuxでは外部から別のプログラムを取ってきて実行する作りだったと報告しています。端末の側で何が行われたかは、運営元の文書からは確認できず、侵害された前提で動くことが求められています。

修正の状況と、版の選び方

この勧告は、通常の弱点のように「修正版」が出る種類のものではありません。悪いのは特定の配布版そのものだからです。勧告は、0.10.0以前を影響のない版としたうえで、0.10.1を入れていない状態に戻すよう求めています。GitHubの勧告の一覧でも、修正版の欄は「なし」で、0.10.0に戻すことが案内されています。その後に出た版を含めて整理すると、次のようになります。

版	公開日	確かめられた事実
0.10.0	2026年4月3日	勧告で影響なしとされた版。隔離の期間中はこの版に固定するよう案内された
0.10.1	2026年5月11日	悪性のコードを含む版。現在は公開の一覧にも配布の履歴にも見当たらない
0.10.2	2026年6月4日	隔離の後の置き換えとして案内された版。配布の自動化の見直しを含む
0.11.0	2026年8月14日	最新版。配布物に、どこで作られたかを示す検証の記録が付いている

隔離は2026年6月10日に解除され、最初の報告の課題も同じ日に閉じられました。0.10.2の更新内容には、正規の自動処理からだけ配布できるようにする仕組みの導入と、自動処理の設定に見つかった注入の弱点の修正が含まれます。0.11.0でも同じ種類の弱点が直されています。PyPIの0.11.0の配布物には、GitHubの自動処理で作られたことを示す検証の記録が表示されています。

注意したいのは、勧告の「修正版」の欄が、その後の版を反映していないことです。0.10.2と0.11.0は配布元の一覧に並んでいますが、勧告そのものはこれらを安全な版として明記していません。どの版を使うかは、配布元の記録と運営元の説明を自社で突き合わせて決める必要があります。

悪用されうるリスク

Guardrailsは守りのための道具ですが、今回の出来事が示すとおり、守りの道具は、それ自体が攻撃の入口になりえます。AIのアプリの中核に組み込まれ、大規模言語モデルへの入力と出力のすべてに触れる位置にあるからです。配布版が乗っ取られれば、その位置にいる悪性のコードが、アプリの持つ鍵や扱うデータに近づけます。

ここからは推測を含みます。Guardrailsのような部品は、開発者の端末や、AIの提供元の鍵を持つサーバーに入ることが多いと考えられます。勧告が、0.10.1を入れた端末から触れられるGitHubの鍵、クラウドの鍵、配布用の鍵、各種の接続用の鍵をすべて取り替えるよう求めているのは、一つのパッケージの侵害が、その端末の持つ権限すべての侵害につながりうるからだと読めます。

検査器の分散も、同じ種類のリスクを増やす可能性があります。検査器が個別のパッケージとして配られる形になると、組み合わせる数だけ配布元を確かめる対象が増えます。名前の似た偽のパッケージを混ぜる手口も一般には知られており、検査器の名前を正確に確かめる運用が要ります。なお、検査器を偽ったパッケージが実際に出回ったという事例は、2026年10月20日時点で一次情報からは確認できませんでした。

もう一つは、検査を過信するリスクです。検査器は判定の仕組みなので、すり抜けもあります。ガードを置いたことで人の確認をやめてしまうと、すり抜けた出力がそのまま業務に流れます。検査の層は、人の確認を減らすためではなく、人が見るべきものを絞るためのものとして位置づけるのが安全です。

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

Guardrailsのような検査の部品を検討するとき、機能の多さより先に確かめたい点があります。下の手順は、導入の前の段階で、資料と社内の取り決めによって確かめられることに絞っています。

この手順の要は、道具の機能を確かめる前に、道具がどこから来て、どこでデータを扱うのかを人が確かめることです。守りの部品は、アプリの中で最も信頼される位置に置かれます。だからこそ、その部品の出どころを確かめる手間を惜しまないことが、検査の層を意味のあるものにします。

企業が取るべき対策

Guardrailsを使うかどうかにかかわらず、AIのアプリに外部の部品を組み込む企業として決めておきたい対策を挙げます。一つ目は、使う部品とその版を一覧にし、版を固定することです。最新版を自動で取り込む設定のままだと、今回のように悪性の版が公開された2時間のうちに取り込んでしまう可能性があります。

二つ目は、勧告の監視です。使っている部品のセキュリティ勧告を誰がどの頻度で確かめるかを決めます。今回の勧告のように、修正版の欄が後の状況を反映しないこともあるため、勧告の文面だけでなく、配布元の一覧と運営元の説明を合わせて読む運用にします。三つ目は、開発の環境の鍵の扱いです。開発者の端末や自動処理の環境に置く鍵は、用途と期限を絞ったものにし、侵害の際にすぐ取り替えられるよう一覧にしておきます。

四つ目は、検査の基準の文書化です。どの出力を止めるのか、どこまで直してよいのかを、道具の設定ではなく、社内の基準として先に文章で決めておきます。五つ目は、記録の点検です。ガードがどれだけ止め、どれだけ直したかを定期的に見て、基準が実態に合っているかを人が見直します。運営元自身も、事件の後に組織の鍵の扱いを厳しくし、変更への署名を必須にしたと説明しています。

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

Guardrailsには、出力を直させたり、大規模言語モデルに聞き直させたりする仕組みがあります。便利ですが、ここでAIに判断を委ねすぎないことが大切です。何を外れた出力とみなすかは、AIではなく人が決める範囲です。検査器はその基準を当てはめる道具にすぎません。

AIに直させる場合も、基本は同じです。AIに判断させない部分を先に決め、直させるときは何をどう直したかの根拠を残させ、人が確かめる範囲を決めておく。この三つがないと、AIが出した答えをAIが直し、その結果を誰も見ていない状態になります。やってはいけない向き合い方を挙げておきます。

• 本番の検査をすべて「記録だけ」にしたまま、止めていると思い込む
• 聞き直しの回数に上限を設けず、通らなかったときの扱いも決めない
• AIが直した出力を、元の出力と比べられない形でそのまま使う
• 検査器を名前だけで探して入れ、配布元が運営元の組織かを確かめない
• 部品の版を固定せず、公開された最新版を自動で取り込み続ける
• 勧告の修正版の欄だけを見て、使う版の安全性を判断する

裏を返せば、人が決める範囲ははっきりしています。何を止めるか、AIにどこまで直させるか、どの版を使うか、勧告が出たときに誰が動くか。この四つは道具に委ねず、人が決めます。

よくある質問：検査の層があれば、AIの出力は人が見なくてよいのか

答えは「見る量は減らせるが、見ることはやめられない」です。検査器は、決めた基準に当てはまるものを見つける仕組みです。基準にない種類の外れや、検査器自身の判定の外れは、そのまま通ります。検査の層は、人の確認を置き換えるものではなく、人が見るべきものを絞り込むものと考えてください。

「0.10.1を入れていなければ、この勧告は関係ないのか」という問いもよく出ます。直接の影響は0.10.1を入れた環境に限られるとされています。ただし、今回の出来事は、守りの部品の配布版でも乗っ取られうることを示しました。版の固定と勧告の監視は、0.10.1を入れていない企業にとっても見直す価値があります。

「遠隔での推論が終わったら、もう使えないのか」という問いには、使えると答えます。本体と、PyPIに移った検査器は引き続き公開されています。ただし、モデルを使う検査器は自社の環境か自前の接続先で動かす形になるため、費用と、検査対象の文章がどこで処理されるかを改めて確かめる必要があります。

• Guardrailsの機能・版・勧告・移行の告知は、GitHubのリポジトリとその中の文書、課題の一覧、公式の文書サイト、パッケージの登録ページを2026年10月20日に確かめた範囲に基づきます。内容は変わる可能性があります
• 悪性のコードの働きについては、運営元の勧告と経緯の文書に詳しい記載がなく、最初の報告者の説明を紹介するにとどめています
• この記事は防御と評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Guardrailsは、大規模言語モデルへの入力と出力を、検査器を組み合わせたガードで確かめるOSSです。検査に失敗したときに止める、直す、聞き直すといった振る舞いを選べ、決まった形式のデータを得る働きや、サーバーとして置く形も備えています。AIの出力を使う前に確かめる層を、部品として組み立てられる点が特徴です。

一方で、2026年5月には配布版の0.10.1が乗っ取られ、悪性のコードを含む版が正規の配布元に公開されました。見つかるまでの時間はおよそ2時間とされています（CVE-2026-45758）。原因は社員の鍵の漏えいで、0.10.1を入れた環境は侵害されたものとして扱うよう勧告されています。その後、0.10.2と0.11.0が公開され、配布の仕組みも見直されましたが、勧告の修正版の欄はこれを反映していません。版の選び方は自社で確かめる必要があります。

守りの道具を入れることは、その道具をアプリの最も信頼される位置に置くことでもあります。何を止めるかの基準と、部品の出どころの確かめ方を、導入の前に人が決める。これが、検査の層を本当の守りとして働かせるための第一歩です。

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