FiddlerでAIの回答を見張る方法｜止めた後に誰が動くか

「問い合わせ対応のAIを公開したが、変な答えを返していないかを毎日見る人がいない」「AIの監視の製品を入れれば安心だと言われたが、止まったあとに誰が何をするのかが決まっていない」——生成AIを社外向けに出した企業の情シスやカスタマー部門から、最近よく相談される二つの声です。米国の Fiddler は、こうした本番のAIを見張り、危ない入出力をその場で止める製品を作ってきた会社です。ただ、見張る道具を入れることと、見張る体制ができていることは別の話です。この記事では、Fiddler を社内に入れるかを判断する立場から、基盤に任せること、人が決めること、止めたときの責任者、記録の残し方、費用の増え方を整理します。

Fiddler は、本番で動くAIの答えと振る舞いを見張る米国の基盤

Fiddler は、機械学習のモデルの監視と、予測の理由を説明する機能から始まった米国の会社です。現在の公式サイトでは、自らを予測型のAI、生成AI、AIエージェントのすべてを対象にした見える化と安全の基盤と説明しています。モデルの精度が落ちていないか、入力の傾向が変わっていないか、生成AIが根拠のない答えを返していないか、エージェントがどの道具をどの順に呼んだかを、本番の通信から集めて見せるのが中心の機能です。

もう一つの柱が、Fiddler Guardrails と呼ぶ、入出力をその場で検査して止める仕組みです。公式の製品ページでは、検査の対象として、攻撃的・違法・性的・暴力的な内容などの安全性、AIの指示を書き換えようとする攻撃、35種類を超える個人情報、与えた資料に沿った答えかどうか（根拠への忠実さ）を挙げています。検査にかかる時間は80ミリ秒未満と説明しており、利用者が待たされない速さで止められることを売りにしています。

検査に使うのは、同社が自前で作った判定専用の小型のモデルです。以前は信頼モデルと呼ばれていたもので、公式の説明では、顧客のクラウドの中で動き、検査のために外部の生成AIへデータを送らない構成をとれるとしています。外部の大きな生成AIに「この答えは安全か」を毎回聞く方式に比べて、費用と情報の持ち出しを抑えられるというのが同社の主張です。どこまでが自社の環境に収まるかは契約の形で変わるため、後の節で確かめ方を書きます。

2026年の動き：調達、コーディングエージェント向けの統制、判定の格上げ

2026年1月27日、Fiddler はシリーズCで3,000万ドルを調達したと発表しました。報道によれば、主導したのは RPS の投資部門で、既存の投資家には電通の投資部門も名を連ねています。同社は調達額の累計をおよそ1億ドルと説明していますが、調査会社の集計では9,380万ドルとされており、数字は資料によって違います。発表の見出しは「AIエージェントの統制の基盤」で、見張るだけでなく、決まりを実行時に強制し、監査に耐える記録を残すところまでを一つの製品として扱う方向を打ち出しました。

6月23日には、コーディングエージェント向けの統制の仕組みを公表しています。公式ブログによれば、すでに社内にある生成AIや MCP の中継の仕組みに後付けし、エージェントの要求と応答を社外に出る前に検査します。判定は「通す」「止める」「機密の部分だけ伏せて通す」の三つで、どれを選んでも記録は残ります。Claude Code と Gemini の開発者向けの道具から記録を取れるとし、チーム、保管庫、モデル、開発者ごとの費用まで集計できると説明しています。

10月13日には、判定の格上げと名付けた仕組みを公式ブログで公表しました。安全性を判定する小型のモデルが、学習した範囲から外れた珍しい入力に出会ったとき、その入力だけを同社が用意した汎用の大きなモデルに回して判定し直すというものです。ある顧客での試験では、入力の3.1%を回すだけで、攻撃と誤って判定する率が93.5%下がったと書いています。ただし同社自身が、これは一つの参考の結果であり、どの会社でも同じになる保証ではないと断っています。

• 調達額、検査の速さ、誤判定の削減幅は、いずれも提供元または報道の数字で、第三者が検証した値ではありません
• 公式ブログの更新は2026年10月下旬まで週に数本のペースで続いており、提供終了や新規受付の停止の告知は見当たりません（2026年10月28日時点）

誤解：見張りの道具を入れれば、本番のAIは安全になる

監視の基盤の導入を検討する会社でよく見かけるのが、「入れれば安全になる」という期待です。たしかに Fiddler のような基盤を入れると、危ない答えの多くはその場で止まり、何が起きたかの記録もたまります。しかし、何を危ないとみなすかの閾値を決めるのも、止まった答えが本当に危なかったのかを確かめるのも、止まったせいで困った顧客への対応を決めるのも、すべて人の仕事として残ります。

ガードレールそのものの組み方や、入口・出口・道具の呼び出しといった層の考え方は、別の記事で扱っています。また、本番に出す前にAIの答えを採点する基準の決め方も、評価の基盤を題材にした記事があります。この記事が扱うのはその先、本番に出したあとの毎日の運用です。見張りの道具が出す警告や記録を、誰がどの頻度で読み、何をきっかけに動くのか。ここが決まっていない会社では、どれほど高性能な基盤を入れても、止めた記録が積み上がるだけになります。

もう一つの誤解は、判定するAIは正しいという思い込みです。Fiddler 自身が10月の公式ブログで、学習した範囲から外れた入力では小型のモデルの判定が揺らぐことを前提に、格上げの仕組みを作ったと説明しています。つまり提供元も、判定の誤りは起きるものとして設計しているということです。使う側も同じ前提に立つ必要があります。

課題1：問い合わせ応答のAIは、間違っても「それらしく」答え続ける

社外に出したAIで最初に困るのは、間違いが目立たないことです。問い合わせ応答のAIは、資料に書いていない料金や納期を、もっともらしい文章で答えてしまうことがあります。利用者はそれを正しい案内だと受け取り、あとで営業や窓口に「AIがこう言った」と問い合わせが来て、初めて誤りが発覚します。Fiddler の根拠への忠実さの検査は、AIに渡した資料と答えを突き合わせて、資料に無いことを言っていないかを点数にするものです。点数が低い答えを止めたり、人の確認に回したりできます。

ただし、この検査が見ているのは「渡した資料に沿っているか」であって、「資料そのものが正しいか」ではありません。料金表が古いまま資料に入っていれば、AIは古い料金を忠実に答え、検査も通ります。資料の鮮度を保つ仕事は、監視の基盤の外にあるので、資料の持ち主と更新の頻度を別に決めておく必要があります。

エージェントになると、問題はさらに見えにくくなります。答えの文章は正しくても、途中で呼んだ道具が想定外だったり、同じ処理を何度も繰り返して費用を膨らませていたりします。Fiddler はエージェントの一連の処理を追いかけて見せる機能を持っていますが、どの道具の呼び出しが想定外かを定義するのは、エージェントを作った部門です。

課題2：止めた記録はたまるのに、誰も見ていない

監視の基盤を入れた会社で次に起きるのが、警告と記録の放置です。最初の数週間は担当者が画面を見ていても、本業が忙しくなると確認が週に一度になり、やがて月に一度になります。その間に、止められた答えが積み上がり、本当に危なかったものと、判定の誤りで止まっただけのものが混ざったまま残ります。

10月の公式ブログで Fiddler が格上げの仕組みの効果として挙げたのも、まさにこの点でした。攻撃と誤って判定される件数が減ったことで、セキュリティの担当が仕分ける件数が大きく減ったと説明しています。裏を返せば、誤判定が多いままでは、確認の列が人の手に負えなくなるということです。

記録を誰も見ない状態は、事故が起きたときにいちばん困ります。顧客から苦情が来て調べると、問題の答えは三週間前から何度も警告を出していた、ということが分かる。警告が出ていたのに対応しなかった記録は、監視しなかった場合よりも説明が難しくなります。見る人と見る頻度を決めずに記録だけ残すのは、避けるべき状態です。

原因1：止める基準を決める人と、止めた後に動く人が分かれていない

見張りが空回りする一つ目の原因は、役割の切り分けがないことです。Fiddler の画面で閾値を設定するのは、多くの場合、AIを作った開発の担当か情シスです。しかし、止まった答えが顧客に何を意味するのかを判断できるのは、問い合わせ窓口やマーケの担当です。閾値を厳しくすれば安全側に倒れますが、答えられない問い合わせが増えて顧客の不満が出ます。緩めれば逆のことが起きます。

この釣り合いは技術の問題ではなく、事業の判断です。ところが多くの会社では、閾値の変更が開発の担当の一存で行われ、窓口の担当は「最近AIが答えてくれない」と顧客から言われて初めて変更を知る、という順番になっています。閾値を変える権限を持つ人と、その影響を受ける部門が事前に合意する仕組みが欠けているのです。

• 閾値の変更を開発の担当が一人で決め、窓口やマーケに知らせていない
• 止まった答えを確かめる担当が決まっておらず、警告が数週間読まれないまま残っている
• 「止める」を選んだときに顧客に何を表示するかが決まっておらず、利用者が行き止まりになる
• 判定の結果をそのまま正解として扱い、誤判定の率を誰も測っていない

原因2：判定する側のAIにも誤りがある

二つ目の原因は、判定の結果を正解として扱ってしまうことです。Fiddler の判定に使う小型のモデルは、特定の検査のために学習させたもので、速く安く動く反面、学習していない種類の入力には弱いことがあります。業界の専門用語が多い問い合わせや、日本語の言い回しの癖が強い入力で、攻撃でもないのに攻撃と判定されることは起こりえます。

Fiddler の判定の格上げは、この弱点を埋めるための仕組みです。小型のモデルが判定のために作る数値の表現を使って、入力が学習の範囲から外れているかを見分け、外れていればより汎用のモデルに判定し直させます。追加のモデルを動かさずに見分けられるため、普段の速さを落とさず、珍しい入力にだけ手間をかける考え方です。10月時点では、安全性の判定のモデルで使えると公表されています。

それでも、格上げされた判定もAIの判定です。同社の説明でも、汎用のモデルは「よりよいモデル」ではなく「より広く知っているモデル」であり、学習した範囲の中では小型のモデルのほうが速く正確だとしています。どちらの判定も、最後は人が抜き取りで確かめる前提で運用を組むべきです。日本語の入力でどの程度の精度が出るかは、公式資料では確認できないため、試験導入で自社の問い合わせを流して測るのが確実です。

原因3：費用が、見張る量に比例して膨らむ設計になっている

三つ目の原因は費用です。生成AIの答えを別の生成AIで採点する方式をとると、本番の通信が増えるほど採点の費用も同じだけ増えます。Fiddler が自前の小型のモデルを売りにしているのは、この構造を変えるためで、公式の製品ページでは、外部の生成AIに判定を頼む方式の費用は利用している生成AIの提供元から直接請求されると指摘しています。

判定の格上げについても、費用の説明があります。Fiddler が運用するクラウド版では格上げによる判定ごとの追加費用はかからず、遅くなるのは格上げされた一部の通信だけとしています。一方、自社の環境に置く形で使う場合は、汎用のモデルを動かす計算資源の費用を自社で持つことになります。どちらの形をとるかで、費用の増え方が変わるということです。

料金そのものは公式サイトに載っておらず、問い合わせで見積をとる形です。見積の段階で、何を単位に課金されるのか（通信の件数か、見張るモデルやエージェントの数か、利用者の数か）を必ず確かめてください。問い合わせ応答の利用が伸びたときに、監視の費用がどう増えるのかを、利用の伸びの見込みと並べて試算しておくと、半年後に予算が足りなくなる事態を避けられます。

費用を部門に割り振れるかも、運用を続けられるかを左右します。6月のコーディングエージェント向けの仕組みでは、生成AIの利用の費用、件数、応答の速さ、発動した判定を、チーム、保管庫、モデル、開発者ごとに集計し、契約している席の数と実際に使っている開発者の数を並べて見せると公式ブログで説明しています。監視の基盤が、見張る費用だけでなく、見張られる側のAIの費用を部門に割り振る材料にもなるということです。どの部門のAIが費用を押し上げているかが見えれば、監視の費用をどの予算から出すかの議論もしやすくなります。

対策1：基盤に任せることと、人が決めることを表にする

最初の対策は、役割の切り分けを一枚の表にすることです。監視の基盤が得意なのは、大量の通信を休まず検査し、決まった基準で止め、記録を残すことです。人が担うのは、基準を決めること、止まったものを確かめること、顧客への影響を判断することです。この線を表にして、関係する部門で合意しておきます。

仕事	Fiddler に任せる	人が決める・確かめる	持ち主の例
危ない入出力の検査	全件をその場で検査し点数を付ける	検査の項目と閾値	情シス・開発
止める・伏せる・通す	閾値に沿って自動で実行	止めたときに顧客に出す案内	窓口・マーケ
判定の誤りの確認	格上げで珍しい入力を判定し直す	止まった答えの抜き取り確認	窓口の責任者
資料の正しさ	資料に沿っているかの点数	資料そのものの鮮度と正しさ	資料の持ち主の部門
費用の監視	部門・モデルごとの集計	上限と超えたときの判断	情シス・経理
事故の判断	記録と時系列の提示	公表・謝罪・停止の判断	責任者（事前に指名）

表で大事なのは、右の二列です。人の欄に名前が入らない仕事は、誰もやらない仕事になるので、部門名だけでなく担当者の名前まで入れるのが理想です。表を作る過程で、問い合わせ窓口とマーケのどちらが顧客への案内を持つのか、といった、これまで曖昧だった持ち分が見えてきます。

すでにほかの止める仕組みを使っている場合の扱いも、この表で決めておきます。Fiddler Guardrails は NVIDIA の NeMo Guardrails とそのまま組み合わせられると公式に説明しており、既存の仕組みに検査の項目を足す形でも使えます。ただし、二つの仕組みが同じ入力を別々に止めると、どちらの判定で止まったのかが分かりにくくなります。止めた理由の記録をどちらの仕組みに寄せるかを決めておくと、抜き取りの確認や事故の調査で迷わずに済みます。

対策2：止めたときの責任者と、戻し方を先に書く

二つ目の対策は、止めたときの手順を事前に書いておくことです。Fiddler のような基盤では、止める判断そのものは自動で行われます。問題は、止まったあとです。顧客の画面に何を表示するのか、人の窓口へどうつなぐのか、止まった答えを誰がいつまでに確かめるのか、誤判定だったときに閾値を戻すのは誰の権限か。この四つを書いておきます。

特に大事なのが、止まったときに顧客を行き止まりにしないことです。「お答えできません」だけを返すと、利用者は別の言い方で何度も聞き直し、それがまた止まるという悪循環になります。人の窓口の連絡先や、よくある質問のページへの案内を返すように設計しておくと、止めることの副作用を小さくできます。

責任者は、閾値を変える人とは別に、事故の判断をする人を一人指名しておきます。たとえば、個人情報が答えに含まれて外に出た疑いがあるときに、サービスを止めるか、公表するかを決める人です。この人は監視の画面を毎日見る必要はありませんが、警告が上がったときに連絡がつく人でなければなりません。夜間や休日の連絡の順番も、ここで決めておきます。

対策3：記録は「何を残し、何を残さないか」から決める

三つ目の対策は、記録の設計です。監視の基盤は、放っておけば入力と答えのすべてを記録します。しかし、問い合わせ応答の入力には、顧客の氏名や連絡先、契約の内容が含まれることがあります。全部を長く残すと、それ自体が漏えいの危険になり、個人情報の保存期間の規程とも衝突します。

Fiddler のコーディングエージェント向けの仕組みでは、機密の部分だけを伏せて記録に残す判定が用意されています。問い合わせ応答でも同じ考え方で、判定の結果と理由は残し、個人情報の中身は伏せるのが基本の形です。どの項目を伏せるか、記録を何日残すか、誰が記録を閲覧できるかを、個人情報の担当と一緒に決めておきます。

記録が監査の証跡として使えるかどうかも、確かめておくべき点です。Fiddler は、監査に耐える記録を統制の基盤の柱の一つに挙げています。社内の監査や取引先の審査で「本番のAIをどう見張っているか」を問われたときに、記録の画面をそのまま見せるのではなく、決まりと実際の運用の対応を説明できる形にしておくと、説明が通りやすくなります。

対策4：判定の誤りを、抜き取りで人が確かめる

四つ目の対策は、判定の質を人が測り続けることです。止まった答えから毎週一定の件数を抜き出し、本当に危なかったのか、誤判定だったのかを窓口の責任者が仕分けます。同時に、通った答えからも同じように抜き出し、止めるべきだったのに通ったものがないかを見ます。この二つの率を記録しておくと、閾値を変えるべきかの判断に根拠ができます。

抜き取りは、件数より続けることが大事です。最初は週に二十件でも、毎週同じ手順で続ければ、季節の問い合わせの変化や、新しい商品の発売による入力の変化が見えてきます。判定の誤りの率が上がったら、学習の範囲から外れた入力が増えたサインで、格上げの仕組みを有効にするか、閾値を見直すかを検討するきっかけになります。

ここで避けたいのは、AIに「この判定は正しいか」をさらに判断させることです。判定の判定をAIに任せても、誤りの連鎖を確かめる人がいなければ同じことの繰り返しになります。抜き取りの仕分けは、問い合わせの中身を知る人が行うのが原則です。AIには、仕分けの材料として、止まった理由や関連する資料の位置を示させるところまでに留めます。

社内に入れてよいか：データの流れ・置き場所・権限

導入の判断で最初に確かめるのは、データの流れです。Fiddler の判定用のモデルは、顧客のクラウドの中で動かして外にデータを出さない構成がとれると公式に説明されています。一方で、見える化の画面や記録の保存を同社のクラウドで行う形もあります。どの形で契約すると、入力と答えのどこまでが社外に出るのかを、構成図で示してもらうのが確実です。

コーディングエージェント向けの仕組みについては、公式ブログで、一社専用のクラウド版か、AWS・GCP・Azure 上に自社で置く形の二つを挙げ、SOC2 の報告書を持つと説明しています。判定の格上げで使う汎用のモデルは、同社の説明では顧客の環境の中で同社が用意したものが動き、外部の生成AIへは送らないとしています。ここも契約の形によって変わりうるので、格上げされた入力がどこで処理されるかを見積の段階で書面で確かめてください。

権限については、閾値や検査の項目を変えられる人を最小にします。監視の画面を見る人と、設定を変える人を分け、設定の変更には記録が残るようにします。止める仕組みの設定を変えられる人が多いほど、誰かが不便を嫌って検査を緩めるリスクが上がるためです。エージェントを作る部門が自分で検査を外せる状態は避けるべきです。

費用の増え方と、小さく始める手順

費用は、見張る対象の数と通信の量で増えていくと考えておくのが安全です。最初から全社のAIを載せるのではなく、社外に出ていて事故の影響が大きいものから一つずつ載せます。多くの会社にとって最初の候補は、顧客が直接使う問い合わせ応答のAIです。

四つ目の「止めずに記録だけ取る」期間が、費用の見積を確かめる期間にもなります。実際の通信量で費用がどう出るかを見てから、二つ目の対象を載せるかを判断すると、想定外の請求を避けられます。

入れる前に確かめる項目一覧

最後に、見積や試験導入の前に提供元に確かめておく項目をまとめます。公式サイトの説明だけでは分からないことが多いため、書面での回答をもらうのが望ましい項目です。

• 判定用のモデルと記録の保存が、契約の形ごとにどこで動くか（同社のクラウドか、自社のクラウドか）
• 判定の格上げを使うと、格上げされた入力がどこで処理され、費用がどう変わるか
• 日本語の問い合わせで、根拠への忠実さや安全性の判定がどの程度の精度で動くか（試験で測れるか）
• 課金の単位が通信の件数か、対象の数か、利用者の数か。利用が倍になったときの見積
• 記録の中で個人情報を伏せる設定ができるか、保存期間を自社で決められるか
• 閾値や検査の項目の変更に、誰が変えたかの記録が残るか
• 契約を終えるときに、記録と設定を取り出せる形式と期間
• 国内での導入実績、日本語の窓口、障害時の連絡の時間帯

これらの答えがそろえば、Fiddler を入れるかどうかの判断は、技術の比較ではなく自社の運用体制で回せるかどうかの判断になります。体制が回らないと分かったら、まずは役割の表と抜き取りの確認だけを先に始め、道具は後から選ぶという順番でも構いません。

まとめ

Fiddler は、本番で動くAIの答えとエージェントの振る舞いを見張り、危ない入出力をその場で止める米国の基盤で、2026年に入ってからは統制の基盤としての機能を広げ、10月には判定の誤りを減らす仕組みも公表しました。ただ、見張る道具が止めてくれても、何を危ないとみなすか、止めたあとに誰が動くか、判定の誤りを誰が確かめるかは会社の側に残ります。導入の前に、基盤に任せることと人が決めることを表にし、止めたときの責任者と戻し方を書き、記録の残し方を個人情報の担当と決め、抜き取りで判定の質を測り続ける体制を作ってください。判定の結果は材料であり、最後の判断をAIにさせないことが、本番のAIを安全に動かし続ける前提です。

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