レポートの全文を読む
300台以上の端末で1か月、AIエージェントが実際に何をしていたのか。シャドーAI、YOLOモード、MCPサーバー、モデルの支出、そして取るべき対策を7章にまとめました。簡単な情報をご入力いただくと、レポートの続きが開きます。
フォームを読み込んでいます…
レポートへのリンクをメールでもお送りしますので、いつでも戻ってお読みいただけます。
ありがとうございます。レポートの全文が下に表示されています。
300台以上の端末で1か月、AIエージェントが実際に何をしていたのか。シャドーAI、YOLOモード、MCPサーバー、モデルの支出、そして取るべき対策を7章にまとめました。簡単な情報をご入力いただくと、レポートの続きが開きます。
フォームを読み込んでいます…
レポートへのリンクをメールでもお送りしますので、いつでも戻ってお読みいただけます。
ありがとうございます。レポートの全文が下に表示されています。
AI Defense データ
あるソフトウェア開発企業の協力を得て、従業員が使う300台以上の端末で、AIエージェントが1か月のあいだ何をしていたのかを記録しました。記録は2つの角度から取っています。1つは、エージェントが呼び出したツールをその場で捉える、エージェント側の記録。もう1つは、OSの中核（カーネル）に組み込んだセンサーで、エージェントの申告とは関係なく、端末で実際に動いたプロセスをそのまま捉えます。期間中は検知だけを行い、どの操作もブロックも停止もしていません。普段どおりの使われ方をそのまま見るためです。結果として、社内で承認されていたエージェントは Anthropic の Claude Code だけだったにもかかわらず、動いていたのはそれだけではありませんでした。本レポートでは、この1か月で見えたことを数字とともに紹介します。
セキュリティの歯止めがないままコードを書いている
今回の調査先では、AIエージェントを使っている従業員の半数（50%）が、エンジニアリング部門の所属ではありませんでした。さらに43%は、エンジニアリングにもプロダクトにも属していません。マーケティング、人事、営業、法務、経理——いわば全社がエージェントを手にしているということです。しかも調査期間中、どこかの部門でエージェントが使われなかった日は1日もありませんでした。
エンジニア以外の社員が行っているのは、Claude Code や Codex との「相談」だけではありません。エージェントを使った非エンジニアのうち平均42%が、コードの実行、ビルド、パッケージのインストール、クラウドやクラスターへのコマンド発行までエージェントに実行させていました。内容の多くは Python スクリプトの実行です。同じことを、エンジニアは約80%、つまり2倍の頻度で実行していました。
サプライチェーンにも手が伸びています。非エンジニア利用者の12%が、エージェント経由でパッケージをインストールしていました。npm、pip、go、brew で新しいコードや依存関係をシステムに足す——これまでは開発者が担ってきた作業です。
50%
のAIエージェント利用者が、エンジニアリング部門以外に所属
42%
の非エンジニア利用者が、コード実行・ビルド・パッケージのインストール・クラウドやクラスターへのコマンド発行を実施
エンジニアリングの現場には、もともと仕組みとしての歯止めが組み込まれています。プルリクエストのレビューやソフトウェア構成分析（SCA）が、危険な依存関係を出荷前に止めます。万一すり抜けても、権限を絞った認証情報が被害を押しとどめます。日常的にコードを読む業務であることも、不自然なものに気づきやすい環境をつくっています。
同じことを経理の担当者が自分のノートPCで行う場合、この歯止めはどれも用意されていません。本人の注意深さの問題ではなく、業務の前提として整備されてこなかったというだけのことです。エージェントは、サポートの切れた古いパッケージや、そもそも存在しないパッケージを提案することがあります。攻撃者は、その「存在しないはずの名前」を先回りして登録できます。それと気づかずにインストールすれば、自分の端末で悪意あるコードが動き出します。コードの出力を読み慣れていなければ、見分けるのは難しいでしょう。
バイブコーディング（AI任せのコーディング）にはリスクが伴います。エンジニアリング部門以外の社員が本番環境へコードを送り込むのであれば、決められた手順と明示的な承認を通す必要があります。ただし、ここで問われるのは個人の姿勢ではなく、その道筋を用意できているかという組織の側の課題です。インストールとクラウドCLIの実行を把握したうえで、承認済みのサンドボックスという「通ってよい道」を整えてください。
現場から
ある非エンジニアの社員が、個人のメールアカウントでサインインしたまま、Claude Code で本番の自動処理を作り直していました。前の週にも、別の個人アカウントで同じことをしています。Sysdig AI Defense はこれを検知し、通知しました。この1週間でエージェントは、シークレットマネージャーから本番用トークンを読み出し、本番IAMロールのインラインポリシーを書き換え、MCPサーバーを追加し、200件を超えるクラウドコマンドを実行していました。Sysdig AI Defense は、本人が会社アカウントでサインインし直すこと、セキュリティチームが本番トークンを入れ替えること、IAMポリシーの変更を別の担当者がレビューすることを提案しました。
サードパーティに潜むリスク
エージェントのセキュリティ水準は、つないだ先のセキュリティ水準にそのまま引きずられます。MCP（Model Context Protocol）サーバー——エージェントに外部サービスをつなぐソフトウェアです——やスキル、プラグインは、どれもエージェントが読める範囲とできることを広げます。だからこそ「全部許可」か「全部禁止」かではなく、リスクの大きさで線を引く必要があります。
なかでも危ういのがMCPのサプライチェーンです。インターネット上で見つけたMCPサーバーは、そのままエージェントに接続できてしまいます。それが誰かの検証やスキャンを通っているのかは、接続する側からは分からないのが実情です。
今回の調査先で Sysdig AI Defense が洗い出したMCPサーバーの内訳は、次のとおりでした。
サードパーティ製はサーバー数ではほぼ半数を占めていましたが、呼び出し量で見ると16%にとどまります。最も多かったのは正体の分からないコネクタで、呼び出し量の35%。ただし呼び出し量が示すのは「よく使われているか」だけで、「どこまで手が届くか」ではありません。めったに呼ばれないサーバーも、よく使われるサーバーとまったく同じ権限とリスクを持ち続けます。
設定ファイルへの書き込みを監視して作ったインベントリでは、サーバーの動きはほとんど捕まえられません。ある1日に呼び出されたサーバーの96%は、その日に設定が追加されていませんでした。だから必要なのは、新規追加の監視ではなく、設定そのものの棚卸し（スナップショット）です。
35%
35%のツール呼び出しが、正体の分からないコネクタ経由だった
16%
16%のツール呼び出しが、サードパーティ製サーバー経由だった
MCPサーバーを1つ追加するということは、一度も呼び出さなかったとしても、そこに信頼関係を結ぶということです。しかも追加に必要なのは、設定ファイルのたった1行です。コネクタこそがエージェントを便利にする以上、目の前の課題が片づくなら追加しようという判断は、ごく自然に生まれます。
つないだサーバーは利用者のデータを読み、モデルはそのサーバーのツール説明文を「指示」として読み込みます。つまり、悪意あるコードが紛れていれば、つないだ時点で手遅れです。サーバーは黙って更新されることもあるので、先週信頼したものが今週も同じとは限りません。新規接続の監視では、ほとんど何も捕まりません。設定を棚卸しし、使ってよいサーバーを許可リストで決め、メール・ストレージ・CRMのように機微なデータに手が届くものから優先してレビューしてください。全部止めるのは答えではありませんが、全部通すのも同じく答えではありません。
拡張機能について問うべきは、「誰が作ったか」「どこから来たか」ではありません。「どこまで手が届くか」「何を書き換えられるか」です。これがリスクベースのAIサプライチェーン対策であり、ガバナンスはここから始まります。
現場から
Sysdig AI Defense は、1週間に追加されたスキルを一覧にして示しました。多くはブラウザ操作やPC操作のスキルで、コード編集よりずっと広い範囲に手が届きます。緊急の危険ではないものの、社外から持ち込まれた見慣れないスキルは一度目を通す価値がある——そういう位置づけの通知です。セキュリティチームは、自社の利用ポリシーに照らして、許可・制限・削除のいずれかを選べます。
既定で許可せず、リスクで判断する
今回のデータからは、ガバナンスの穴が2つ見えました。誰も存在を知らなかったエージェントと、誰も出していない承認です。どちらも「リスクの大小で仕分ける物差しがない」という同じ問題を抱えています。誰が何を実行してよいのか、どこまで目を光らせるのか。一つひとつ決めていくしかありません。
AIエージェントは、セキュリティ部門が思っているよりずっと多くの端末で動いています。今回の調査先では、Sysdig AI Defense が見つけたエージェントの50%が、それまで誰も把握していなかったものでした。
会社の端末で個人のメールアドレスを使って登録する。あるいは業務用メールで未承認のエージェントにログインする。どちらもセキュリティチームからは見えません。従業員がエージェントを使っているかどうかは、もはや論点ではありません。全端末に、少なくとも1つのエージェント本体（ハーネス）が入っていて、現に使われていました。
では、見えないものをどう管理すればよいのか。出発点は、エージェントが実際に何をしているかを知ることです。
50%
のエージェントが、それまで誰にも把握されていなかった
エージェントは管理者の承認なしにユーザー領域へ入れられますし、登録は1分で終わります。個人のメールアドレスでも使えるため、業務用メールアドレスを調べても何も出てきません。SSOの外にあるからです。意図して隠しているわけではないでしょう。それでも、組織にとってリスクであることに変わりはありません。
見えていなければ、止めることも、監査することも、何を渡したか調べることもできません。プロンプトに貼り付けられたソースコード、チケット、社外秘、顧客データは、会社が管理していないアカウントに積み上がっていきます。とはいえ、新しいツールの申請から承認までに時間がかかるとなれば、目の前の業務を前に進めることが優先されるのも当然です。
シャドーAIを見つける方法は一つで、承認済みリストや問い合わせでは分からない「端末で実際に動いているもの」を棚卸しすることです。見えるようになったら、現に使われている用途に正規の受け皿を用意してください。禁止するだけでは、より見えない場所に移るだけです。
現場から
未承認のモデルプロバイダーが使われていました。ある利用者が Gemini CLI 経由で gemini-3.1-pro-preview を実行していたのです。Sysdig AI Defense はこれを通知したうえで、コードやプロンプトを対象に含むデータ取り扱い契約を Google と結んでいるのか、それともこのプロバイダーを正式に承認するのか、あるいはこの利用者を承認済みエージェントだけに制限するのか、判断を求めました。
YOLOモードとは、利用者が許可の確認（プロンプト）をオフにした状態です。通常、Claude Code は何かを実行する前に手を止めて確認します。YOLOモードでは、その確認が出たときに「以後は確認せず、すべて実行してよい」と答えることになります。
調査期間中、この企業のセッションの10%がYOLOモードでした。少なくとも1回は確認をオフにした、ということです。そして一度オフにすると、98%はそのセッションが終わるまでオフのままでした。
似て非なるものにオートモードがあります。Claude Code のオートモードは、Anthropic の脅威モデルに合わせて調整された分類器が、人の代わりに一つひとつのツール呼び出しを審査する仕組みです。Anthropic 自身も、確認を飛ばすくらいならオートモードを使うよう勧めています。リスクはゼロになりませんが、少なくとも歯止めは残ります。
両方を合わせると、ツール呼び出しの61%が人の承認を経ずに実行されていました。内訳はオートモードが52%、YOLOモードが9%。スピードと引き換えに、会社としてのリスクを引き上げている状態です。
結果として、エージェントが「この操作を実行してよいですか？」と尋ねるデフォルトモードで実行されたのは、全体のわずか19%でした。
10%
のセッションが、YOLOモードで実行された
98%
のケースで、セッションが終わるまで確認がオフのままだった
61%
のツール呼び出しが、人の承認を経ずに実行された
52%
のツール呼び出しがオートモードで実行された
9%
のツール呼び出しがYOLOモードで実行された
確認をオフにするのは、作業を少しでも速く進めたいからで、それ自体は理にかなった選択です。ただし、セッションを一度承認すれば、そのセッション中にエージェントが実行することは、すべて承認済みになります。本人がまだ見ていない手順も含めて、です。
白紙委任を与えると、リスクは静かに積み上がります。リアルタイムで手元を見ていなければ、気づくのは検知ログを読み返すときです。権限を絞った短命の認証情報しかないサンドボックスや仮想マシンなら、確認をオフにするのも妥当でしょう。しかし、認証情報ファイルが置かれたノートPCでは話が別です。
問題はモードそのものではなく、モードとその端末が抱えているものの組み合わせです。歯止めはセッション単位ではなく、呼び出し単位にかけるべきです。認証情報のパス、破壊的なコマンド、インストール、新しいMCPサーバー——ここにガードレールを置いてください。承認は、誰かが強制して初めて意味を持ちます。エージェント自身が握っている承認は、エージェントが外せる承認です。
現場から
YOLOモードが有効なまま、エージェントが Infrastructure as Code の apply コマンドを実行しました。Sysdig AI Defense はこれをアラートとして上げ、対象と結果の確認、変更内容のレビュー、そして外れていた保護を戻すか、常時与えている権限を絞り込むことを提案しました。
シャドーAIもYOLOモードも、根っこは同じ「二択」です。ツールは承認されているか、いないか。確認はオンか、オフか。
しかし実際のリスクは、二択では測れません。読み取り専用のドキュメントサーバー、CRMに書き込めるコネクタ、クラウドの認証情報を抱えたノートPCで確認を切っているエージェント。この3つを同じ扱いにしてよいはずがありません。
リスクベースのポリシーは、エージェントが使えるものを「どこまで手が届くか」「何を書き換えられるか」で仕分けます。
リスク
エージェントにできること
対応方針
ローカルや公開されている情報を読むだけ。ファイルの書き込み、外部APIの呼び出し、認証情報への接触はできない。
許可する。ただしインベントリには載せておく。
審査済みのプロバイダーとデータ取り扱い契約のもとで、ファイルの書き込み、パッケージのインストール、外部APIの呼び出しができる。
呼び出し単位でログを残し、定期的に見直すことを条件に許可する。
認証情報、クラウド、本番環境、顧客データに手が届く。または、審査していない提供元、未承認のプロバイダー、個人が立てたサーバーから来ている。
承認と理由の提出を必須にし、権限を絞った短命の認証情報を使わせ、カーネルレベルで強制する。
この3区分は、Sysdig AI Defense で集めたデータをもとにした、AIリスク評価とガバナンス設計のたたき台です。たとえばMCP呼び出しの35%を占めていた「正体の分からないコネクタ」は、その多くがメール、ストレージ、CRM、課題管理ツールにつながっていました。これは高リスクに分類すべきものです。
エージェントの話は聞く。ただし信じるのはカーネル
エージェントの行動は「意図」から始まります。「このバグを直して」「このフォルダを片づけて」という指示です。しかし実際の行動は、そこからずれていくことがあります。さらに厄介なのは、エージェントが書き残した記録も、実際に実行した内容と一致しないことです。行動そのものと、その記録の両方を同じエージェントが作っている——これが根本的な難しさです。
エージェントの内側に置いた歯止めには、もう一つ弱点があります。ツール呼び出しが止められると、エージェントは仕事を終わらせるために別の道を探します。ブロックされたツールを避けて、APIを直接呼び出すといった具合です。
カーネルのレベルでは、この「ずれ」も「迂回」も効きません。ポリシーが不可と判断すれば、元の操作も回避策も動きません。カーネルはエージェントの言い分を受け取りませんし、どのツールやAPIを通ったかにも興味がありません。
だからこそ、利用者とエージェントが何をしたのかを監査する段になると、エージェントのログは参考資料にはなっても、唯一の正にはなりません。エージェントのログは行動の要約にすぎず、カーネルはプロセスツリーそのものを見ています。実際、カーネルが記録したプロセス数はエージェントの平均7倍。今回の調査先では、ツール呼び出し37万4,000件に対してプロセスは260万件でした。記録されたシェル呼び出し1件あたりでは6〜9プロセスです。認証情報の読み取りで見えた乖離と、まったく同じ構図です。
もちろん、カーネルのほうがログは多くなります。しかし数の問題ではありません。エージェントが残すのは「自分が実行したつもりの記録」、カーネルが残すのは「実際に実行された記録」です。この2つは別物です。
抜け漏れは双方向に起きます。だから両方のレイヤーが要るのです。エージェントのログは網羅性に、カーネルはカバレッジに弱点があります。カーネル側で捉えたセッションの20%は、エージェントのログにツール呼び出しが1件もありませんでした。逆に、エージェントがログを残したセッションの12%には、カーネル側の記録がありません。後者はMCP・読み取り・編集のセッションで、仕組み上プロセスを生成しないものでした。
6-9
エージェントのログ1件の裏に、カーネルレベルのプロセスが6〜9件
260万
プロセス260万件に対し、ツール呼び出しは37万4,000件
エージェントのログは、デバッグや作業の再開には役立ちます。しかし、監査の証拠として作られたものではありません。セキュリティチームが本当に把握するには、全体像が要ります。
エージェントの行動には、記録が4つあります。何をしようとしたか（たいていは指示した内容）、何をしたとログに書いたか、実際に何が動いたか、そして動いた時点でどこまで手が届いたか。前の2つはエージェントの内側から、後の2つは外側から得られます。意図も、行動も、ログも、それぞれずれ得ます。ずれたときに踏みとどまれるのは、エージェントの外にある歯止めだけです。そして、そのずれがいくらの損害になるかを決めるのが「手の届く範囲」です。同じ行動でも、その瞬間に何に届いていたかで、ただのノイズにもインシデントにもなります。
記録
書いているのは
分かること
弱点
エージェント自身
意図、ツールの意味づけ
網羅性と正確性に欠ける。記録に抜けがあるうえ、その記録を書いているのがエージェント自身である。
センサー
実際に動いたこと
カバレッジに限界がある。センサーを入れていない端末の動きは見えない。
セキュリティチームが決め、センサーが強制する
ツールや経路を問わず、APIの直接呼び出しも含めて、行動そのものを止められる
ポリシーの出来しだい。（注：今回はすべての実行を許可し、カーネルセンサーはデータ収集のためだけに使いました。）
ノイズがリスクに変わるとき
エージェントは動き続けるので、どうしてもノイズが増えます。その大半は単体では無害で、やがて誰も見なくなります。ところが、手の届く範囲しだいでノイズはガバナンスの問題に変わります。一時フォルダでの破壊的なコマンドは、ただの後片づけです。しかし認証情報ファイルの読み取りは、クラウドへの入り口になり得ます。検知はノイズの量を、認証情報はそのノイズが届く先を教えてくれます。そして、アラートが鳴る前に届く先を狭めておく手段がゼロトラストです。
エージェントを使う人の大半は、セキュリティ上の検知に該当する操作を行っています。今回の調査先では、77%の人が1日のうちに最低1件、何らかの検知に該当しました。カーネルが見たエージェント起動のプロセスか、エージェント側のフックが見たツール呼び出しのどちらかが、ルールに当たったということです。セッション単位で見ると、45%は検知1件のみ、55%はゼロ。多くの人が検知に該当するものの、毎回ではないという結果です。
調査期間中、破壊的なシェルコマンドの検知ルールは1日で303回、利用者の22%について発動しました。中身の99%は rm -rf です。つまり、何かを食い止めた「捕捉」でも「ブロック」でもなく、ごく普通の後片づけが可視化されただけでした。今回は Sysdig AI Defense に検知のみを指示していたため、ルールは実行前に記録するだけで、1件も止めていません。ただしこの回数は、エージェントが日常的に破壊的な操作へ手を伸ばしていることを意味します。止めるかどうかはポリシーの判断であり、それこそがランタイム制御の役目です。
77%
の利用者が、1日のうちに何らかのセキュリティ検知に該当した
これらの検知は、必ずしも攻撃の兆候ではありません。しかし、ノイズとして片づけてよいものでもありません。エージェントは攻撃者と同じ作業——設定の読み取り、シークレットの取得、ファイルの削除——をするので、どうしても攻撃に見える動きをします。
今回は、めったに起きない事象を想定して作られたルールが、利用者の22%で発動しました。必要なのは、どのパスか、どのセッションか、どのモードかまで分かる精度の高い検知です。
セキュリティの現場は騒がしくなっていますが、悪い話ばかりではありません。攻撃を見つけるだけでなく、改善できる運用上の抜けまで見えるようになったからです。利用者ごと・セッションごとにベースラインを取り、パス、モード、時間帯のずれをアラートにしてください。
認証情報ファイルは、ログインとは別物です。ツールやエージェントがいちいち聞かずに済むよう、シークレットをディスクに置いておくファイルです。中身はAPIキー、認可トークン、セッションCookie、クラウド事業者（CSP）のアクセスキーなど。ブラウザに保存したパスワードとほとんど同じ発想です。これがコピーされれば、攻撃者はAWSでもDockerでも各種レジストリでもGCPでも、ログインせずに「本人」としてふるまえます。
エージェントがこのファイルを読むのは、通常の動作です。ただし、必ずログに残るわけではありません。今回の調査では、認証情報ファイルの読み取りがエージェント自身のログに残っていなかったケースが82%。一方でカーネルは、毎回記録していました。
エージェントのバイナリ自身が読んだ場合、差はさらに開きます。この読み取りは95%が無記録でした。バイナリは子プロセスではなく実行ファイルそのものなので、子プロセスやシェルの陰に隠れているわけでもありません。
バイナリによる読み取りはツール呼び出しではないため、ツール呼び出しのログにはそもそも載りません。どちらの読み取りも記録は不十分ですが、CSPの認証情報ファイルを開くシェルコマンドのように、ツール呼び出しを経由するものは比較的残りやすい傾向があります。
18%
エージェントが記録
100%
カーネルが記録
エージェントが認証情報ファイルを読んだとき、82%はエージェントのログに残っていませんでした。カーネルは毎回記録していました。
5%
エージェントが記録
100%
カーネルが記録
エージェントのバイナリが認証情報ファイルを読んだとき、95%はエージェントのログに残っていませんでした。カーネルは毎回記録していました。
エージェントのログに載るのは、モデルが行ったツール呼び出しです。バイナリによる読み取りはツール呼び出しではないので、まず載りません。しかしカーネルなら見えます。ここが重要なのは、悪意あるパッケージ、仕込まれた指示、汚染されたMCPサーバーからエージェントに入り込んだ攻撃者が、そのエージェントの「手の届く範囲」をそっくり引き継ぐからです。対策は、長く生き続ける大きなファイルからシークレットを外し、短命の認証情報に移すことです。
現場から
データの取り扱い事故、あるいは持ち出しの疑いがありました。カスタマーサポート担当者のエージェントが、分析作業の途中で「login emails」という名前のファイルを SCP コマンドでコピーし、その宛先はAWSのIPアドレスでしか特定できないホストだったのです。同じ担当者には、同じ週に無関係のアラートが2件ありました。Sysdig AI Defense は、ファイルの中身と宛先ホストの持ち主を本人に確認するよう提案しました。顧客のメールアドレスが入っていたなら、取り扱い事故として扱うべき事案です。
エージェントは、持ち主である利用者そのものとして動きます。利用者の認証情報、クラウドのセッション、ネットワークをそのまま引き継ぎ、二要素認証もなければ、独立したIDも持ちません。ゼロトラストをエージェントに当てはめるとは、「利用者のIDをたまたま使っている、信頼できない別人」として扱うということです。アラートがノイズで済むかどうかは、手の届く範囲で決まります。つまりゼロトラストとは、アラートが鳴る前にその範囲を狭めておくことです。
今回のデータを踏まえると、どの組織にも次の4点は検討する価値があります。
これらの対策は、エージェントが期待どおりにふるまうことを前提にしていません。むしろ、そうとは限らないからこそ検知が必要になり、手の届く範囲を狭めるゼロトラストが必要になります。同じ検知でも、権限を絞った短命の認証情報ならノイズで済み、長期有効な認証情報で鳴ればインシデントになります。範囲を狭めることが、ノイズを扱える量に収めることにつながります。
タスクに見合うモデルを選ぶ
どのツール呼び出しに、どのモデルが使われているか。これが見えると、分かることは多くあります。単価は高いがツール開発には向くモデルもあれば、安くてもドキュメント作成やデータ分析なら十分なモデルもあります。
今回の調査先では、AI予算の54%が重複した処理や機能に使われていました。使い方が最適でないぶん、そのまま利益を削っていたことになります。
Sysdig AI Defense は、1週間分のツール呼び出しについて、どのモデルが使われたかを把握できました（利用者は、使ったモデルファミリーごとに重複して数えています）。結果は、大多数が標準的な中位モデル（Sonnet 5）を使う一方で、半数超がツール呼び出しにもっと高価なモデルを使っていた、というものでした。
1つ目のグラフを見ると、大半の利用者は Sonnet 5 を使いつつ、上位モデルも併用していたことが分かります。2つ目のグラフは、その上位モデルがより多くの処理を担っていたことを示しています。ただしここから分かるのは「どのモデルが実行したか」だけで、「そのタスクが実際に難しかったのか」「下位モデルでも足りたのか」は分かりません。モデル利用のルールを決める前に、まさにそこを問うべきです。タスクに合わせてモデルを決め、本当にそれでよいか試してみてください。
もう一つ。この企業の従業員の40%は、Opus クラスだけを使っていました。広告の誤字チェックにも Opus や Fable の単価がかかっていると考えると、見直す余地が見えてきます。別の37%は Sonnet のみ、20%は両方です。支出を人・チーム・タスクに紐づけられれば、利用状況に手を入れて最適化できます。
モデルの選択は個人の設定ですが、影響は会社のコストとセキュリティに及びます。モデルごとに失敗の仕方も違います。業務端末へのソフトウェア導入と同じように、特定のモデルは特定のタスクにだけ許可し、利用者に理由や用途の提出を求める——そんな自社ルールを定める選択肢もあります。
54%
のAI支出が、重複した作業に消えていた
1種類のモデルしか使っていない利用者
最上位モデルの評判には、それだけの理由があります。迷ったときに一番賢い、あるいは一番速いものを選ぶのは、自然な判断です。ツール開発のようにその価値があるタスクもあれば、誤字チェックのように、そこまでの費用に見合わないタスクもあります。
モデルの利用を従業員やチームに紐づけ、最上位モデルを使う場合は理由を添えてもらう。業務端末にソフトウェアを入れるときと同じ手続きです。これだけで、トークンの支出もモデルの乱立も抑えられます。
エージェントのリスクの輪郭が見えてきて、はっきりしたことが一つあります。セキュリティの基本は、何も変わっていないということです。
エージェントには最小権限を与える。長く生きるファイルへの恒久的なアクセスではなく、短命の認証情報を渡す。信頼できるインベントリだけを使い、エージェントのログとカーネルのログを突き合わせる。エージェントは利用者のIDの延長であり、しかも人より速く、二要素認証なしに動いている——その前提に立つことが出発点です。
実施事項
理由
ログはエージェント任せにせず、カーネルでも取る。
監査人が見たい記録を書いているのはエージェント自身で、そのエージェントこそ監査の対象だから。
ポリシーはエージェントの中ではなく、カーネルで強制する。
エージェントは、自分の中の歯止めなら迂回できる。カーネルが不可と言えば、元の操作も回避策も動かない。
歯止めの単位を、セッションから1回の呼び出しへ移す。
承認はセッションに1回しか求められないが、リスクは呼び出しごとに違う。危ない呼び出しだけ止めて、あとは通す。
拡張機能もエージェントの操作も、既定で許可せずリスクの大きさで判断する。
どこから来たかより、どこまで手が届き、何を書き換えられるかのほうが重要だから。
承認したツールではなく、動いているエージェント本体の数を数える。
実際に動いているものを棚卸しすれば、想像以上に見つかる。
誰が確認をオフにしているか、どのくらいの期間オフなのかを追う。
スピードと引き換えに受け入れられるリスクなのか、そもそもこの設定自体を無効にするのかを決めるため。
エンジニアリング部門以外の利用者にも目を配る。
エンジニアリング部門以外でもインストールやクラウドCLIの実行は可能であり、現に実行されているから。
MCPサーバーは新規追加の監視ではなく、設定の棚卸しで把握する。
大半は以前から設定済みで、新規追加だけ見ていては呼び出しを取りこぼすから。
エージェントは、利用者のIDで動く信頼できない相手として扱う。
権限を絞った短命の認証情報を渡し、呼び出しは「何に触れるか」で評価する。
人ごとにベースラインを取り、複数のアラートにまたがるパターンに注意する。
SCPが1回なら単なるコマンド。1週間に3件のアラートはパターン。
