社内で使うAIエージェントの危険な動きをOSS「ADR」はどう見つけるのか

「社員がコーディング用のAIエージェントを使い始めたが、何を読み、何を実行しているのか誰も把握していない」「端末の監視製品は入れているのに、AIが何を考えてその操作をしたのかまでは分からない」——AIエージェントの社内利用が広がった企業の、情報システムやセキュリティの担当者が口にする二つの悩みです。どちらも、新しい監視製品を一つ足せば解決するように聞こえます。しかし本当の課題は製品の有無ではありません。AIエージェントが社内で何をしたのかを、意図と操作の両方から後でたどれる状態になっていないことです。この記事では、配車大手のUberが公開したOSS「ADR」を取り上げ、一次情報で確かめられる仕組みと論文の数値、記録の扱いで気をつける点、企業が導入前に決めておくべきことを整理します。導入や設定の手順は扱いません。

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

ADRは、GitHubで公開されているOSSです。READMEは、ADRを「AIエージェントのための企業向けセキュリティの仕組み」と説明しています。対象は二種類です。一つは、コーディング用のエージェントなど社員が手元で使うもの。もう一つは、顧客対応の窓口として動くエージェントのように、社外の人と接するものです。READMEには、Cursor、Claude Code、Codex、GitHub Copilotのコマンド版などが名指しで挙がっています。

配布の形を確かめます。リポジトリはUberの公式組織のアカウントで2026年4月19日に作られ、ライセンスはApache-2.0です。2026年10月18日時点でスターは2,062、派生は232、最後の更新は10月16日でした。組織のアカウント自体は2010年12月に作られ、公開しているリポジトリは176件あります。一日あたりのスターの伸びは約11.3件で、新しく作られたアカウントが急に注目を集めている形ではないと分かります。正式な版（リリース）はまだ出ておらず、変更の積み重ねは168件でした。

READMEは、ADRの守りを五つの働きに分けています。下の表は、それぞれの働きと、今回のOSSに含まれているかどうかをまとめたものです。五つのうち、実際に公開されているのは三つと評価用の試験一式で、残りは含まれていません。

働き	READMEの説明	今回の公開
発見	端末にあるAIのアプリ・エージェント・拡張機能・MCPサーバーを洗い出し、正体の分からないものを確認に回す	含まれる
観測	エージェントの意図・道具の使用・実行の流れを集めて、共通の形にそろえる	含まれる
評価	企業の環境に近い条件でエージェントの守りを試す試験一式	含まれる
検知	広く拾う一次の選別と、怪しい作業だけを深く調べる二段構えの判定	含まれる（研究用）
予防	危険な操作を実害の前に止める	含まれない（今後の公開と告知）

「ADR」という名前は何の略か

READMEの見出しによると、ADRは「Agentic AI Detection and Response」の略です。日本語にすると「自律的に動くAIのための検知と対応」となります。端末の不審な動きを見つけて対処する製品群は、一般に「端末の検知と対応」と呼ばれます。ADRはその考え方を、端末ではなくAIエージェントに当てはめたものと読むと分かりやすい名前です。

論文の題名は「企業の自律型AIのセキュリティのための、自律的な検知の仕組み」で、こちらでも検知と対応が中心に置かれています。なお、ソフトウェア開発の現場では、同じ三文字が設計上の判断を書き残す文書の略として使われることがあります。社内で話題にするときは、Uberが公開したAIエージェントの検知の仕組みのことだと補って伝えると混同を避けられます。

なぜ今、AIエージェントの観測が課題になるのか

論文は、企業がAIエージェントを守るうえでの課題を三つ挙げています。一つ目は見えにくさです。従来の端末の監視製品はファイルの書き込みは見えても、その前にあった指示文、エージェントの推論、操作に至るまでの因果の流れは見えない、と論文は指摘します。

二つ目は、あらかじめ決めた規則で守る方式のもろさです。攻撃の形や企業ごとの事情が多様なため、固定の規則は広く当てはまらないとされます。三つ目は費用です。大規模言語モデルですべての作業を判定すれば精度は上がりますが、規模が大きくなるほど費用が重くなります。見えにくさ・規則のもろさ・判定の費用の三つに同時に答えようとした設計が、ADRの特徴です。

背景には、エージェントが外部の道具をつなぐ共通の取り決めであるMCP（モデルと道具をつなぐ取り決め）の広がりがあります。エージェントが道具を呼べるほど、読み込んだ文書に紛れた命令に従ってしまう、いわゆるプロンプトインジェクション（指示の乗っ取り）の影響も大きくなります。正しく動いているように見える作業の中に、乗っ取られた操作が紛れるという問題は、ファイルの変化だけを見ていては捕まえにくいものです。

端末にあるAIの道具を洗い出す働き

発見の部品の説明書によると、この部品は一台の端末にあるAI関連の道具を棚卸しします。対象は、AIのアプリ、コマンドで動くエージェント、開発環境の拡張機能、手元で動かすモデルの実行環境、MCPサーバー、エージェントに足す技能や追加機能などです。それぞれの検出には、そう判断した根拠が記録されるとされています。

運用の面で目を引くのは、調べきれなかった範囲を報告する点です。説明書は、調べきれなかった端末を、何も無い端末と取り違えないようにするために、読み取れなかった場所や途中で打ち切った場所を結果に含めると説明しています。棚卸しで最も怖いのは「見えていないだけ」を「無い」と扱うことなので、この考え方は社内の他の棚卸しにも通じます。

社内の方針として、道具ごとに「承認」「禁止」「未承認」「不明」を割り当てる仕組みもあるとされます。また、見つけた道具そのものは実行せず、既定では外への通信も行わないと書かれています。社員が勝手に入れたAIの道具、いわゆるシャドーAIを見つける入り口として位置づけられる部品です。

エージェントの行動を記録する働き

観測の部品の説明書によると、この部品はAIエージェントが手元に残す記録を読み取り、共通の形にそろえます。対応先として、Claude Code、Cursor、Codexのコマンド版、GitHub Copilotのコマンド版など、十種類ほどのエージェントが挙がっています。作業ごとに、会話の履歴、使ったモデル、作業したフォルダ、端末名、利用者名などが一つのまとまりとして残る形です。

会話の履歴には、利用者の指示文、エージェントの応答、道具の呼び出しとその引数・結果が含まれます。説明書は、道具の引数や結果にソースコードや認証情報が含まれうると明記し、記録を機密として扱い、共有の前に中身を確かめるよう求めています。一部のエージェントでは長い結果を途中で切る処理がありますが、切らないものもあるとされます。

記録の置き場所は、既定では端末の中のファイルです。ログを集める外部の監視基盤へ送る機能もありますが、既定では無効と書かれています。注意したいのは、送る機能を有効にした場合、指示文や道具の結果、利用者名などが伏せられないまま送られると説明書が明記している点です。送り先の守りが、そのまま記録の守りになります。

二段構えで危険な動きを見つける働き

検知の部品は、READMEで「二段構え」と説明されています。一段目では、大規模言語モデルがすべての会話をざっと見て、問題なしとして終えるか、深く調べる側へ回すかを決めます。二段目では、回された作業だけを、推論を重ねる別のエージェントが詳しく調べます。説明書によると、二段目はMCPサーバーのソースコードまで確かめられる作りです。

この分け方の狙いは費用と精度の両立です。論文の評価では、一件あたりの費用は平均で約0.024ドル、判定にかかる時間は平均18.5秒と報告されています。一段目だけで終わる作業と、二段目まで進む作業とで、費用と時間が大きく違うとされます。全件を深く調べず、怪しいものだけに手間をかけるという考え方は、人の監視体制を組むときとも共通します。

ただし、検知の部品の説明書には、これが評価のための研究用の仕組みで、本番での利用を想定していないこと、切り離した環境で動かすべきことが書かれています。また、判定には外部の二つのAIサービスを使う作りで、それぞれの利用の鍵が必要とされます。説明書には、判定のために会話の中身がどこまで外部へ送られ、どう保持されるかは明記されていません。公開された検知の部品は、そのまま社内の本番の監視に入れる道具ではないと理解しておくのが正確です。

評価用の試験一式と論文の数値

ADRには、エージェントの守りを試すための試験一式が付いています。論文によると、攻撃の手口は五つの戦術、十七の技法に整理されています。整理にあたっては、MITRE ATLASやOWASPといった公開の枠組み、公表された事故や調査報告、Uberの運用の記録と攻撃役の専門家への聞き取りを参考にしたとされます。READMEでは試験の課題が304件、MCPサーバーが134個とされ、論文の評価では課題が302件、MCPサーバーが133個と書かれています。READMEと論文で数がわずかに違う点は、引用するときに注意が要ります。

評価の場	論文が報告する結果	読み方の注意
自前の試験（攻撃42件を含む302件）	誤検知0件、攻撃の検出は42件中28件（67%）	見逃しは14件。権限の悪用は5件中1件の検出にとどまる
比べた既存の三手法	誤検知は30〜40件、総合の評価でADRが2〜4倍上回る	三手法のうち二つは論文の数値の引用で、このリポジトリでは再実行できない
公開の指示乗っ取りの試験（93件）	すべての攻撃を検出、誤検知は3件	作者自身による評価で、第三者の検証は確認できない

表のとおり、ADRの数値は「誤検知を出さない」方向に強く寄っています。現場の担当者が大量の誤報に追われないことは大きな利点です。一方で、自前の試験では攻撃の三分の一を見逃していることも論文に書かれています。数値は作者が作った試験の結果であり、自社の環境で同じ結果になる保証はありません。

Uberでの運用について、出典から言えること

READMEは、ADRが「Uberで本番運用されている」と書いています。運用の中身について具体的に述べているのは論文です。論文によると、ADRは10か月以上本番で動き、7,200台を超える端末を対象に、1日あたり1万件を超えるエージェントの作業を処理してきたとされます。対象は社用のノートパソコンで、記録を読み取ったのはCursor、Cline、Claude Codeの三つとされています。

運用の成果として論文が挙げているのは、認証情報の漏れです。26の種類にわたる数百件の深刻な漏れが見つかり、それらが社外へ渡っていたこと、該当する認証情報は切り替えられたことが報告されています。さらに、指示文を送る前に正規表現と文字列の乱雑さで認証情報らしいものを止める仕組みを足し、212件の検出のうち206件が正しく、精度は97.2%だったとされます。

ここで押さえておきたいのは、これらがUberの論文による自己申告だという点です。第三者が運用の規模や成果を確かめた資料は、確認した範囲では見つかりませんでした。報道ではより大きな規模に触れたものもありましたが、一次情報で確かめられないため、この記事では論文の数値だけを扱います。また、論文自身が、漏れを見つけた時点ですでに社外に出ていた例があったと認めています。

公開されていない部分と、その意味

ADRのすべてが公開されているわけではありません。READMEによると、危険な操作を実害の前に止める予防の部品は、現在の公開に含まれておらず、今後の公開が告知されています。また、論文で検知を強くする役割を担う、導入前の攻撃役の試験を自動で行う部品も含まれていないと明記されています。

論文によると、この攻撃役の部品は、攻撃の手口を組み替えて新しい変種を作る役、切り離した環境で試して成否と見逃しを測る役、価値の高い結果を脅威の知見として蓄える役の三つのエージェントからなるとされます。検知の二段目は、この蓄えた知見を参照して強くなるという設計です。

つまり、公開されたものだけで論文と同じ守りが再現できるとは限りません。見つける・記録する部品は手に入るが、止める部品と鍛える部品は手元にないという前提で、自社で何を補う必要があるかを考える必要があります。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSを公開されている事実だけを基に精査しています。OSSを入手したり動かしたりはしていません。ADRの判定は「紹介可」です。

根拠にした事実は次のとおりです。運営はUberの公式組織のアカウントで、2010年に作られ、公開しているリポジトリは176件あります。ライセンスはApache-2.0で、商用も含めて使えます。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、リポジトリの直下に、取り込みのときに自動で動く処理を含む設定は見当たりませんでした。加えて、仕組みを説明する論文が公開され、国際会議に採択されています。

ただし、勧告がないことや自動実行がないことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。セキュリティの報告窓口を定めた文書もまだ置かれていませんでした。判定は「紹介してよいか」の目安であって、「そのまま使ってよいか」の答えではない点も添えておきます。

導入前に知っておきたい注意点

第一に、記録そのものが機密の塊になる点です。観測の部品は、指示文、道具の結果、作業したフォルダ、利用者名を残します。開発の現場では、そこにソースコードや認証情報が入ることを前提にすべきです。守るための記録が、狙われる資産の一覧になることを、導入の前提に置いてください。

第二に、試験一式の扱いです。公開前の見直しの文書によると、試験には架空の認証情報、指示の乗っ取りの文例、わざと弱点を持たせたMCPサーバーが含まれます。いずれも防御の評価のための架空のものとされていますが、本番の網や実データに触れさせてはいけないと明記されています。同じ文書は、再現性のために古い版に固定した依存部品があり、既知の脆弱性を含むこと、本番に組み込むなら更新し直す必要があることも書いています。

第三に、社員の行動を記録する仕組みであることです。会話の履歴と利用者名が結びつく以上、社員から見れば業務の監視です。労務や個人情報の観点から、何の目的で、どこまでを、どれだけの期間残すのかを、就業規則や社内規程と合わせて整理する必要があります。第四に、正式な版がまだ出ていない点です。変更が続いているため、検証した時点の状態を記録しておく運用が要ります。

悪用されうるリスク

ADRは守りのための仕組みで、攻撃のための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、集めた記録が漏れれば、社内の開発の中身と認証情報がまとめて流出することです。記録を外部の監視基盤へ送る場合、その経路と送り先も守りの対象になります。

次に挙げるのは推測ですが、検討の材料として無視できません。試験一式に含まれる指示の乗っ取りの文例や、弱点を持たせたサーバーの作りは、防御の評価のためのものです。ただ、手口の整理そのものは、攻撃側が守りの隙を探す参考にもなりうると考えられます。検出が弱いと論文自身が認めている手口、たとえば権限の悪用は、狙われやすい領域として意識しておく価値があります。

もう一つは、検知があることへの過信です。論文では攻撃の三分の一を見逃しています。また、判定にAIを使う仕組みは、指示文の揺れやモデルの変化、検知を避ける工夫に弱いと論文も認めています。なお、ADRが実際に悪用された事例は、2026年10月18日時点で確認した一次情報からは見つけられませんでした。

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

実際に検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、動かす前に「何を残し、どこへ送り、誰が見るか」を決めておくことです。観測の仕組みは、入れた瞬間から大量の機密を集め始めます。その扱いが決まらないまま動かすと、守りのための仕組みが新しい漏れの経路になります。

企業が取るべき対策

一つ目は、社内で使われているAIの道具の棚卸しです。ADRを使うかどうかにかかわらず、どの端末にどのエージェントや拡張機能、MCPサーバーが入っているかを把握し、承認・禁止・未承認を決めます。調べきれなかった端末を「問題なし」と扱わない、という発見の部品の考え方は、そのまま社内の棚卸しの規則に取り入れられます。

二つ目は、認証情報が指示文に入る前に止める仕組みです。Uberの論文で最も具体的な成果は、認証情報の漏れの発見と、送る前に止める仕組みでした。指示文に鍵や合言葉を貼り付けない決まりと、貼り付けを機械で止める仕組みを両方持つことが、すぐに始められる対策です。三つ目は、見つけた漏れへの対応の手順です。漏れた認証情報を誰がどの順で切り替えるかを、事前に決めておきます。

四つ目は、エージェントの記録の保管と閲覧の権限を絞ることです。記録を見られる人を限り、閲覧そのものを記録します。五つ目は、調達や採用のときの確認です。研究用と明記された部品を本番に使わない、依存部品の版を更新し直す、セキュリティの報告窓口の有無を確かめる、といった点を導入前に文書で確かめます。

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

ADRの検知は、AIにAIを見張らせる仕組みです。便利な一方で、判定する側のAIも誤り、だまされる可能性があります。だからこそ、先に決めるのは、AIに判断させない部分です。

具体的には、何を記録してよいか、記録をどこへ送るか、誰が見るか、見つけた後に何をするか。この四つはAIにも道具にも委ねず、人が決めて記録に残します。AIに任せてよいのは、決めた範囲の中で大量の記録をふるい分け、なぜ怪しいと判断したのか根拠を書かせたうえで人に上げる部分です。やってはいけない向き合い方を挙げます。

• 検知の判定が「問題なし」なら、人は記録を一切見ない
• 研究用と書かれた検知の部品を、そのまま本番の監視に組み込む
• 記録を外部の監視基盤へ送るのに、伏せる処理がないことを確かめない
• 社員に説明しないまま、会話の履歴と利用者名を集め続ける
• 論文の誤検知0件という数値を、自社でも同じになる前提で導入を決める
• 漏れた認証情報を見つけても、切り替えの担当と期限を決めていない

裏を返せば、人が決める範囲ははっきりしています。何を残すか、どこへ送るか、誰が見るか、見つけたら誰が動くか。この四つが決まっていないまま観測の仕組みを入れても、守りの厚みは増えません。

よくある質問：入れればAIエージェントの危険は防げるのか

答えは「それだけでは防げない」です。今回公開されたADRは、見つける・記録する・判定するための部品で、危険な操作を止める部品は含まれていません。しかも検知の部品は研究用とされ、自前の試験でも攻撃の三分の一を見逃しています。見えるようになることと、止められることは別です。

では意味がないのかというと、そうではありません。エージェントが何を指示され、どの道具をどう使ったかを後からたどれることは、事故が起きたときの調査を大きく助けます。Uberの論文が示した成果の中心も、高度な攻撃の発見より、認証情報の漏れという身近な問題の発見でした。

もう一つ、「社外の顧客対応のエージェントにも使えるのか」という問いもありそうです。READMEは対象に顧客対応のエージェントを含めていますが、記録を読み取る対応先として具体的に挙がっているのは、主に社員が使うコーディング用のエージェントです。自社のエージェントで使えるかは、確認した一次情報だけでは判断しきれません。

• ADRの機能・構成・数値は、GitHubのリポジトリと各部品の説明書、公開前の見直しの文書、論文を2026年10月18日に確かめた範囲に基づきます。内容は変わる可能性があります
• Uberでの運用の規模や成果は論文による自己申告で、第三者による検証は確認できませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

ADRは、社員が使うコーディング用のエージェントなどを対象に、AIの道具の洗い出し、行動の記録、危険な動きの二段構えの検知を担うOSSです。Uberの公式組織がApache-2.0で公開し、論文では10か月以上の運用と、7,200台を超える端末での利用が報告されています。GitHub上にセキュリティ勧告は登録されておらず、判定は「紹介可」としました。

一方で、止める部品は公開されておらず、検知の部品は研究用です。記録には指示文や認証情報が入りうるため、記録そのものを守る設計が欠かせません。何を残し、どこへ送り、誰が見て、見つけたら誰が動くか。この四つを人が先に決めたうえで使うことが、AIエージェントを社内で動かす時代のADRとの付き合い方です。

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