AIエージェントが「開発者」になった今、何が変わったか
コードを書く。テストを実行する。プルリクエストを作る。ドキュメントを更新する。これらの作業を、AIが自律的にこなす環境が現実になってきた。
ClaudeやCursorを日常的に使っているエンジニアにとっては「今さら」の話かもしれないが、問題はその次にある。AIが自律的に動くということは、AIに「権限」を渡すということだ。そしてその権限は、静かに、着実に、人間の開発者と同等レベルへと近づいている。
Classmethodの山本氏がまとめた記事は、この変化を丁寧に整理したものだ。セキュリティの専門家ではなく「実際に使ってきたエンジニア」としての視点で書かれているぶん、現場感がある。
記事が整理している問題の核心
論点は大きく3つある。
AIに任せるタスクの範囲と権限が拡大している。 以前は「指定したコマンドだけ実行する」という限定的な使い方が主流だった。今は「目的を伝えれば、必要なコマンドを自分で判断して実行する」という広範な裁量へと移り変わっている。
大量並列運用が現実になりつつある。 記事では「100体のAIエージェントが100並列で24時間動き続け、さらにそのエージェントが別のエージェントやエージェントチームを呼び出す」環境を例として挙げている。これは将来の仮定ではなく、既に進みつつある方向だと明記されている。
モデル自体が脆弱である。 ここが最も重要な前提だ。プロンプトインジェクション（AIが読み込む入力に悪意ある指示を混ぜ込む攻撃）とデータポイズニング（学習データへの汚染）の2つが主な攻撃経路として示されており、どちらも「利用者側で完全に防ぎきることは困難」と断じている。OWASPのLLM Top 10でもLLM01・LLM04として挙げられている既知のリスクだ。
「モデルは脆弱である」を前提に置く意味
ここからは、記事を読んで感じた構造的な話をしたい。
セキュリティの議論でよく出てくるのが「AIに安全のためのシステムプロンプトを入れておけばいい」という発想だ。しかしこれは、LLMの仕組みを考えると根本的に成立しない。
LLMは、入力されたトークン列全体から次のトークンの確率分布を計算して出力する。安全のための指示も、ユーザーの入力も、外部から取り込んだドキュメントも、すべて同じトークン列の一部として処理される。言い換えると、「安全のための指示」は特権的な位置にあるわけではなく、入力全体の文脈によって、その重みは変動する。
記事はこれを「確率的な脆弱性」と呼んでいる。言い回しや前後の文脈が少し違うだけで、ある入力では安全のための指示を守るのに、別の入力では同じ指示を破ってしまうことが起こりえる。そして「この確率をゼロにする手段は現時点では存在しない」とはっきり書いている。
並列度が上がれば、1回あたりの発火確率が低くても、どこかで確実に踏まれる構造になる。確率論的なリスクをシステム設計で吸収しなければならない、という話だ。
実務的な示唆：今の対策が「スケールで崩れる」問題
記事は、よく採られる対策が単独では不十分な理由も具体的に示している。
人間がすべての操作を承認する：複雑なコマンドや長いスクリプトを毎回正しく判断できる人は限られる。加えて「承認疲れ」が起きると、内容を確認せずに承認するようになる。小規模では機能するように見えるが、規模が大きくなるほど形骸化する。
AIにコマンドの安全性をチェックさせる：Claude Codeのauto modeが該当する仕組みだが、チェック側のAIもモデルである以上、同じ確率的な脆弱性を持つ。チェック役のAIが乗っ取られれば意味をなさない。
ここで記事が提示している軸が「方向性Aと方向性Bの違い」だ。方向性Aは「AIに任せる範囲を小さく限定する」、方向性Bは「AIに広い裁量を与えつつ、仕組みで安全性を担保する」。
現時点では方向性Aで問題なく回っているチームも多いと思う。しかし、AIの活用範囲を広げていく意図があるなら、今の対策がスケールで崩れることを知っておく必要がある。方向性Bに切り替えるタイミングを、後手に回らずに考えておくべきだという話だ。
次の論点：誰が設計し、誰が責任を持つか
実務的に気になるのは「誰がこの設計をするのか」という問いだ。
セキュリティの専門家が少ないチームでは、AIエージェントの実行環境・権限制御・隔離の設計を担える人材がいない場合が多い。開発者が「とりあえず動かしている」状態のまま権限だけが大きくなっていく、というパターンはすでに各所で起きているはずだ。
記事自体も「次回以降で対策を扱う」としており、今回は問題の整理に徹している。つまり「何が問題か」は整理されたが、「どう対処するか」はまだ続編待ちの状態だ。
今後の論点として残るのは、ツールベンダー側がどこまでデフォルトで安全な設計を提供するか、という点だと見ている。開発者全員がセキュリティ設計を自前で組み立てられるわけではない。Claude CodeやCursorのような製品が「安全なデフォルト」をどう定義するかが、実際の被害件数に直結する問題になってくる。
生成AIでコードを書くことに慣れてきたエンジニアほど、「とりあえず動いている」状態への警戒が薄れやすい。この記事は、その慣れに対して構造的な問いを投げかけている。セキュリティの難しい話を避けたい気持ちはわかるが、権限の大きさが静かに増している今、一度立ち止まって読む価値はある。
