エージェントの直しはVijilでも人が決める｜AIの改善提案を採る線

「評価も防御も改善も製品が回してくれるなら、うちは結果の点数を見ていればいい」「AIが直し方まで出してくれるなら、エンジニアが張り付かなくても運用できる」——AIエージェントの安全対策を製品に任せようとしている会社で、よく耳にする期待です。けれども、ここには一つ大きな取り違えがあります。AIが出すのはエージェントの直しの「提案」であって、採るかどうかの判断までは引き受けません。この記事では、米国の Vijil が2026年3月に発表した改善の仕組み Darwin を手がかりに、AIが提案する直しをどこまで採るか、変更をどう記録し、誰が再評価と本番反映を承認するか、信頼スコアをどう読むか、直しを重ねたときに戻せるか、そして運用を定着させる役割分担を整理します。

Vijil は何をする会社か：評価・防御・改善を一続きにする基盤

Vijil は2023年に創業した米国の会社で、発表資料によれば、アマゾンのクラウド部門で要職にあった人たちが立ち上げました。共同創業者で最高経営責任者のヴィン・シャルマ氏が率いており、自社を「AIエージェントの信頼の層」と位置づけています。2025年11月25日には1,700万ドルの資金調達を発表し、累計の調達額は2,300万ドルになったと公表しました。同じ発表で、ガートナーの注目ベンダーに選ばれたことにも触れています。

製品は大きく四つの役割に分かれます。社内で動いているエージェントやモデルを見つけて台帳に載せる発見の役割、エージェントを出荷前に試験して点数を付ける評価の Diamond、実行中の入力と出力を検査して攻撃を止める防御の Dome、そして本番の記録から弱点の原因を探し、直し方を提案する改善の Darwin です。試す、守る、直すを一つの流れとして扱うのが、同社の設計の特徴です。

このうち Dome は、オープンソースとして公開されています。公開先の説明では、Apache 2.0 の利用許諾で配られる Python のライブラリで、20種類を超える検出の仕組みを使い、入力ではプロンプトインジェクションや脱獄の試み、有害な表現を、出力では有害な表現の検査と個人情報の伏せ字化を行うとしています。評価だけ、防御だけを切り出して試せる入口があることは、いきなり全体を契約しなくてよいという点で、導入の判断を軽くします。

本番の外で試験する評価と、実行中に止める防御の線引きは、別の記事で扱っているため、ここでは繰り返しません。この記事が扱うのは三つ目の改善、つまり本番で見つかった弱点に対して、誰が直し方を決め、どう反映するかです。評価と防御を入れた会社が、次に必ず突き当たるのがこの段階だからです。

2026年の動き：3月の Darwin 発表と、いまの提供段階

2026年3月11日、Vijil は Business Wire を通じて、攻撃や失敗にエージェントを適応させる基盤を発表しました。中心にあるのが三つ目の部品 Darwin です。発表資料の説明では、Darwin は本番の記録、つまり攻撃、失敗、方針違反、想定外の入力の記録から学び、エージェントへの指示、設定、ソースコードに対する的を絞った改善を提案するとされています。開発者はその提案を確認し、適用し、評価し直す、という流れです。

同じ発表では、対応するエージェントの開発基盤として、グーグルのエージェント開発キットをはじめ四つの開発基盤を挙げ、アマゾンのクラウドのエージェント実行基盤での利用にも触れています。最高経営責任者は、開発者は事業の責任者に対し、エージェントが通常の条件でも、雑音の多い条件でも、悪意のある条件でも期待どおりに動くことを示さなければならない、という趣旨を述べ、Darwin を運用から開発へ戻る輪を閉じるものだと説明しました。

一方で、2026年11月時点の公式サイトの Darwin の紹介では、Darwin は開発中で、まだ一般の顧客には提供されていないと明記されています。いまは同社が設定したリポジトリに対してのみ動き、同社の見本のエージェントで変更依頼が開かれるところまで一通り動かした段階で、既知の弱点を持つエージェントを一つ持ち込む設計協力企業を募っている、という説明です。導入を検討するなら、評価と防御は今の製品として、改善は設計協力の枠として、分けて考える必要があります。

防御の側では、2026年9月に公式サイトで Dome の比較試験の結果を公表しています。11種類のモデルのうち10種類で、最も出来の悪い一割の応答の点数が Dome を通すと上がり、上がり幅の中央値は17.6点だったとしています。ただしこれは同社自身の試験であり、自社のエージェントで同じ効果が出るかは、自社の試験で確かめるまで分かりません。

誤解：改善までAIが回すなら、人は点数を見るだけでよい

評価、防御、改善が一続きになると、「あとは製品の中で輪が回るので、人は月に一度点数を見れば足りる」と考えたくなります。けれども、Darwin の公式の説明を読むと、輪の中に人の判断がはっきり組み込まれています。最も良かった書き換えは変更依頼として届き、人がそれを読み、取り込むか閉じるかを決めると書かれています。自動で取り込む仕組みの説明はありません。

この設計には理由があります。エージェントの直しは、ある攻撃への耐性を上げる一方で、別の振る舞いを変えることがあります。たとえば、外部の文書に紛れた指示を疑うよう書き換えたら、正当な社内文書の指示まで無視するようになった、といった変化です。Darwin は書き換えを元のエージェントと比べ、悪くなった軸も含めて点数を付けると説明していますが、どの悪化なら許せるかは、そのエージェントを使う業務の側にしか分かりません。

つまり、改善の仕組みを入れても、人の仕事は「直し方を考える」から「直しを採るかを決める」に移るだけで、消えはしません。むしろ、提案が次々に届くようになるぶん、決める人と決める基準が決まっていないと、提案が溜まるか、読まずに取り込まれるかのどちらかになります。この記事の残りは、その基準と役割を先に決めるための整理です。

Darwin の提案は何を変えるか：書き換えの対象と、許す範囲

公式サイトの説明では、Darwin はエージェントのソースコードと本番の記録を読み、失敗の一つひとつをコードの中の原因までたどります。そのうえでモデルが複数の書き換え案を作り、それぞれを隔離した試験の環境に置いて、評価の Diamond の攻撃役のエージェントに、元のエージェントと同じやり方で攻撃させます。書き換え案どうしを競わせ、最も良かったものだけを届けるという、進化の考え方を借りた仕組みです。

注目したいのは、書き換えの範囲を利用者が絞れる点です。公式の説明では、書き換えてよいのは利用者が挙げたファイルだけで、差分の大きさにも上限を設定できるとしています。また、元のエージェントを攻撃して点数を付けられない場合は、その回の処理を止めるとしています。触ってよい場所と変えてよい量を、人が先に決めておけることが、採否を判断しやすくする前提になります。

なお、3月の発表資料では提案の対象を「指示、設定、ソースコード」と書いていましたが、11月時点の紹介ページは「設定を横に足すのではなく、エージェントのコードそのものを変える」と強調しています。どこまでを書き換えの対象にするかは、提供の段階で変わりうる部分です。導入を検討するときは、自社のエージェントのどのファイルが書き換えの対象になりうるかを、その時点の説明で確かめてください。指示文を別の場所で管理している会社では、指示文の変更が提案の外に出る可能性もあります。

自動で採ってよい直しと、人が決める直しの線

Darwin 自体は人の取り込みを前提にしていますが、評価と防御の側では、設定の更新を自動で流す運用も組めます。そこで、直しの種類ごとに「誰が、どこまで見て採るか」の線を先に引いておくことを勧めます。線を引く軸は二つです。そのエージェントが社外に向けて話すか、社内の道具を動かすかという影響の大きさと、変更が振る舞いを変える範囲の広さです。

直しの種類	例	採り方	決める人
防御の検出の更新	既知の攻撃文の型を検出に足す	検証環境で誤検知の率を見てから自動で反映してよい	運用担当（事後に記録を確認）
防御の規則の変更	止める条件を広げる、伏せる情報を増やす	見るだけの段階で一定期間試してから反映	業務の持ち主と運用担当
指示文の書き換え	外部文書の指示を疑う一文を足す	再評価のうえ人が承認	業務の持ち主
コードの書き換え	道具を呼ぶ前の確認処理を足す	変更依頼を開発者が読み、再評価、承認者が反映	開発の責任者と業務の持ち主
権限や道具の追加・削除	送信の道具を外す、読める範囲を絞る	AIの提案は参考にとどめ、必ず人が決める	情報システムと業務の持ち主

表のうち、最後の権限の変更は、AIの提案を採る対象にしないことを勧めます。権限を広げる方向の提案はもちろん、狭める方向でも、業務が止まる影響を判断できるのは人だけだからです。AIに判断させない範囲を、表の最後の行として明文化しておくと、提案が届いたときに迷いません。

また、同じ種類の直しでも、社外の顧客と会話するエージェントと、社内の資料を検索するだけのエージェントでは、承認の重さを変えてかまいません。全部を同じ重さで扱うと、軽い直しが溜まって承認待ちの列が伸び、結局は承認が形だけになるからです。

変更を記録する：一件の直しに残す項目

Darwin の変更依頼には、公式の説明では三つのものが付きます。何が変わったかと、許したファイルの外が動いていないことを示す差分、弱点をコードまでたどった攻撃のやりとりの記録と書き換え後に行った攻撃の記録、そして元のエージェントと書き換え案の、すべての軸での前後の点数です。なぜ直すのか、直して何が良くなり何が悪くなったかが、一件の中で読める形になっています。

ただ、これはあくまで開発の記録です。社内の監査や事故の振り返りで必要になるのは、それに加えて、誰がいつ承認したか、どの業務の持ち主が影響を確かめたか、本番に入った日時と版、採らなかった提案とその理由です。採らなかった提案の理由を残すことはとくに見落とされがちですが、同じ弱点が後で問題になったとき、当時なぜ見送ったかが分からないと、判断の妥当性を説明できません。

記録の置き場所は、変更依頼の仕組みの中だけにしないほうが安全です。開発の道具は、担当が変わったり、リポジトリを移したりすると追いにくくなります。社内の変更管理の台帳に、変更依頼への参照と承認者、反映日、版の番号を一行ずつ残しておけば、エージェントごとの変更の履歴を、開発の外の人も読めるようになります。

再評価と本番反映の承認を分ける

改善の運用で最も事故が起きやすいのは、「点数が上がったので、そのまま本番へ」という一続きの判断です。Darwin が届ける前後の点数は、同社の攻撃役が試した範囲での比較であり、自社の業務の正しさまでは測っていません。そこで、再評価を通ったことと、本番に入れてよいことを、別の承認にする運用を勧めます。

自社の試験の一覧は、最初から完璧である必要はありません。業務でよく来る依頼を20件、断るべき依頼を20件といった規模から始め、問題が起きるたびに足していけば十分です。製品の試験が見ていない「自社にとっての正しさ」を、この一覧が受け持つと考えてください。

信頼スコアの読み方：三つの軸と、点が上がっても分からないこと

Vijil の公式の説明書によれば、信頼スコアはエージェントの振る舞いを三つの軸でまとめたものです。負荷がかかっても正しいことを一貫して行えるかという信頼性、悪用に耐え、機密の情報を守れるかという安全性、方針の中にとどまり、有害な結果を避けられるかという無害性です。評価の Diamond は、自社の方針や利用者の人物像を入れて評価の枠組みを作り、監査に出せる形の点数を出すと説明されています。

この点数は、改善の採否を判断するうえで役に立ちます。とくに、一つの軸が上がって別の軸が下がる、といった書き換えの性質を一目で見られる点は便利です。けれども、点数には限界もはっきりあります。点数は、試験に使った攻撃と場面の範囲でしか意味を持ちません。試していない攻め方や、自社に固有の業務の誤りは、点数に表れないからです。

もう一つの注意は、点数を目標にしたときの歪みです。点数を上げることが担当の評価になると、試験に出る型だけに強い書き換えを採り続け、実際の利用では断りすぎるエージェントになりがちです。点数は「前の版と比べて悪くなっていないか」を見る道具として使い、点数の絶対値を、本番に入れる合格の線にしないのが安全です。合格の線は、自社の試験の一覧と業務の持ち主の承認で決めます。

直しを重ねたときに、元に戻せるか

改善の輪が回り始めると、エージェントには小さな書き換えが積み重なっていきます。半年もたつと、どの直しがどの振る舞いの原因になっているのか、誰も説明できなくなるおそれがあります。公式の紹介ページには、戻すための専用の仕組みの説明は見当たりません。ただ、Darwin の直しは変更依頼として届くので、通常のソースコードの管理の中で、版を戻すことはできると考えられます。

問題は、コードを戻せても、それ以外の変更が戻らない場合です。防御の規則を別の画面で変えていた、指示文を別の場所で管理していた、つないでいる道具の側の設定を変えていた、といった変更は、コードの版と一緒には戻りません。コード、指示文、防御の規則、道具の設定を、同じ版の番号でそろえて管理することが、戻せる状態を保つ条件です。

戻すかどうかの判断の基準も、先に決めておきます。たとえば、反映後に正当な依頼を断る件数が一定の割合を超えたら戻す、顧客からの苦情が一件でも出たら戻して調べる、といった線です。基準がないと、問題が出ても「もう少し様子を見る」が続き、戻す判断が遅れて影響が広がることになります。

防御の規則は誰が書き、誰が変えるか

実行時の防御の Dome は、公開先の説明では、設定を Python の辞書や設定ファイルで書く形になっています。入力と出力のそれぞれに、どの検査をどの方法で行うかを並べていく作りです。設定が文書として残るのは良い点ですが、設定を書けるのが開発者だけになりやすいという面もあります。

防御の規則は、本来は業務と情報管理の判断です。どの種類の個人情報を伏せるか、どこまでの攻撃の疑いで止めるか、止めたときに利用者に何と返すか、は開発者が一人で決めることではありません。規則の中身は情報管理の担当と業務の持ち主が決め、開発者は設定に落とす、という分担にしておくと、改善の提案が防御の規則に触れたときにも、承認の経路が自然に決まります。

また、公開先の説明では、検出の方法の中には外部のモデルの検査を呼ぶものもあり、手元で動かす選択肢も用意されているとしています。どの検出の方法を選ぶかで、検査のために入力や出力が外へ送られるかどうかが変わるため、規則を書く段階で、方法ごとの送信先を確かめてください。

評価と改善で、何が社外に渡るか

改善の仕組みを使うと、社外に渡るものの種類が、評価だけの場合より増えます。評価では、攻撃役がエージェントに質問を送り、その応答を集めて点数を付けます。改善では、それに加えて、エージェントのソースコードと、本番の記録を読ませることになります。本番の記録には、利用者の入力や、エージェントが読んだ社内の情報の断片が含まれえます。

公式の紹介ページは、Darwin が読むのはリポジトリのソースコードと本番の記録だと説明していますが、それらがどこに保存され、どれだけの期間残るかは書かれていません。同社は SOC2 のタイプ2の報告書を得ていることと、信頼の情報をまとめたページがあることを示しています。報告書が対象にしている範囲に、開発中の Darwin が入っているかは、設計協力の申し込みの前に確かめる必要があります。

実務では、改善に渡す本番の記録を、渡す前に絞ることを勧めます。個人情報を伏せた記録だけを渡す、顧客との会話ではなく社内の試験の記録から始める、機密の高い業務のエージェントは対象外にする、といった絞り方です。何を渡したかを、渡した日付とともに台帳に残しておくと、契約を終えるときに削除を求める範囲も明確になります。

攻撃の試験は手段の一つ：外部の試験とつなぐ位置

Vijil の評価には、相手の応答に合わせて攻め方を変える攻撃の試験が含まれ、Darwin の書き換え案もこの攻撃役で試されます。ただし、攻撃の試験そのものをどう組むか、社内でやるか外部の専門の会社に頼むかは、別の記事で扱っているため、ここでは詳しく触れません。この記事の文脈で押さえたいのは、改善の輪の質は、その輪で使う攻撃の試験の質を超えないという一点です。

製品の攻撃役が知らない攻め方は、改善の輪の中では見つかりません。外部の試験や、社内の担当が見つけた問題、利用者からの報告は、改善の輪の外から入ってくる情報です。これらを、自社の試験の一覧に足して、次の再評価から使う流れを作っておくと、外で見つかった弱点が輪の中に取り込まれ、同じ問題が繰り返されにくくなります。外部の試験の結果を受け取ったときの窓口を、改善の運用の担当にしておくのが近道です。

定着させる役割分担と、見直しの周期

改善の運用を続けるには、役割を四つに分けて考えると整理しやすくなります。業務の持ち主は、エージェントが何をしてよく何をしてはいけないかを決め、振る舞いの変化を承認します。開発の責任者は、変更依頼を読み、差分の範囲と悪化した軸を確かめます。情報管理の担当は、防御の規則と社外に渡すデータの範囲を決めます。運用担当は、記録を見て提案と問題の傾向を報告します。一人が二つ以上を兼ねると、確かめる目が一つ減ることに注意してください。

見直しの周期は、導入から三か月は月次、その後は四半期ごとが目安です。月次の見直しで見るのは、届いた提案の件数と採った割合、採らなかった理由の内訳、反映後に戻した件数、正当な依頼を断った件数、防御が止めた件数の推移です。採った割合が極端に高いときも、低いときも、運用を疑うのが見方のこつです。高すぎれば読まずに取り込んでいる可能性があり、低すぎれば提案の範囲の設定が合っていない可能性があります。

四半期の見直しでは、自社の試験の一覧そのものを見直します。業務が変われば、断ってはいけない依頼も変わります。また、エージェントにつなぐ道具が増えたら、書き換えを許すファイルの範囲や、承認の重さの表も更新します。改善の仕組みの設定も、改善の対象にするという考え方です。

定着でつまずく形

改善の仕組みを入れた会社がつまずく形には、いくつかの典型があります。どれも、製品の機能の不足ではなく、運用の決めごとが欠けていることから起きます。

• 点数が上がった提案を、業務の持ち主の確認なしに本番へ入れ、正当な問い合わせを断るエージェントになった
• コードの版は戻せたが、別の画面で変えた防御の規則が戻らず、同じ問題が続いた
• 採らなかった提案の理由を残しておらず、後日同じ弱点で事故が起きたとき、見送った判断を説明できなかった
• 本番の記録を絞らずに改善の仕組みへ渡し、個人情報が含まれていたことに後から気づいた
• 提案の承認が一人の開発者に集中し、休暇の間に提案が溜まって、まとめて読まずに取り込まれた

これらに共通するのは、「AIが直してくれる」という期待のぶんだけ、人の確認が薄くなったことです。改善の仕組みは、人の判断を置き換えるものではなく、判断の材料をそろえて届けるものだと位置づけておけば、多くは防げます。

もう一つ見落とされやすいのが、改善の対象を最初から広げすぎることです。社内のエージェントすべてを一度に改善の輪に載せると、提案の件数が読む人の手に余ります。まず、利用者が多く、問題の記録が溜まっている一つのエージェントから始め、承認の流れが回ることを確かめてから対象を増やすのが、定着への近道です。

• Darwin の提供の段階、書き換えの対象、変更依頼に付く情報は、2026年11月時点の公式サイトの説明によるもので、変わる可能性があります
• 信頼スコアや防御の比較試験の結果は同社自身の評価で、第三者による検証は確認できていません
• 本番の記録を社外に渡す前に、個人情報の扱いと委託の契約について、情報管理と法務の確認を経てください

よくある質問

Darwin はいま契約すれば使えますか

2026年11月時点の公式サイトでは、Darwin は開発中で一般の顧客には提供されておらず、設計協力企業を募っている段階だと説明されています。評価と防御は製品として使えますが、改善を使いたい場合は設計協力の枠への申し込みになります。条件は変わりうるため、検討の時点で公式の情報を確かめてください。

AIの提案を自動で取り込む設定はできますか

公式の紹介ページでは、最も良かった書き換えは変更依頼として届き、人が取り込むか閉じるかを決めると説明されており、自動で取り込む仕組みの説明はありません。仮に自社の側で自動化できるとしても、指示文やコードの書き換えは人が承認する運用を勧めます。

信頼スコアが一定以上なら、本番に出してよいと考えてよいですか

点数は、試験に使った攻撃と場面の範囲での比較です。自社の業務に固有の誤りや、試していない攻め方は反映されません。点数は前の版と比べて悪化していないかを見る道具として使い、本番に入れる判断は、自社の試験の一覧と業務の持ち主の承認で行ってください。

防御だけ先に試すことはできますか

防御の Dome はオープンソースとして公開されており、公開先の説明では、アカウントなしで導入できるとされています。まず防御を見るだけの形で試し、止めた記録の傾向を読んでから、評価や改善に広げる順番も取れます。ただし、検出の方法によっては外部のモデルを呼ぶため、送信先は確かめてください。

まとめ

Vijil は、エージェントを試す Diamond、守る Dome、直す Darwin を一続きにする基盤で、2026年3月に改善役の Darwin を発表しました。ただし Darwin は公式サイト上でまだ開発中とされ、届くのは差分と攻撃の記録と前後の点数を付けた変更依頼で、取り込むかどうかは人が決めます。改善の仕組みを運用として定着させるには、直しの種類ごとの採り方と承認者を表にし、採らなかった理由まで記録し、再評価と本番反映の承認を分け、コードと指示文と防御の規則を同じ版でそろえて戻せる状態を保つことです。信頼スコアは前の版との比較に使い、合格の線は自社の試験と業務の持ち主の判断で引いてください。

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