週末に、Google Driveのファイルを整理していた。
仕事の資料に混じって、見覚えのないドキュメントが妙に増えている。開いてみると、いつだったか「試しに動かしてみよう」と設定した、Geminiの自動タスクが吐き出した成果物だった。それも1つや2つではない。私がすっかり忘れている間も、そのタスクは黙々とファイルを作り続けていた。
ファイルを選択して削除する。それで片付いた——と思った瞬間に、手が止まった。
このファイルを消しても、これを作り続けている「何か」を止めない限り、来週もまた同じものが溜まる。片付けるべきは、目の前の成果物ではない。その上流で、私の権限を使って動き続けているエージェントそのものだ。
そう気づいてから、自分の手元を見渡して、少し背筋が寒くなった。勉強のために、検証のために、「とりあえず動くか試そう」で作ったまま放置しているものが、思った以上にたくさんあったからだ。
これは個人の小さな不始末の話に見えて、実は今、英語圏のセキュリティ業界が「orphaned AI agents（放置されたAIエージェント）」「standing privileges（常設特権）」という言葉で本気で議論している企業課題と、根っこが同じだ。ネットワークエンジニア（以下、NE）として現場でID管理や境界制御を見てきた目で、この「放置されたエージェント」の何が危ないのかを整理し、最後に個人開発者向けの棚卸し手順までまとめてみたい。
1. 発端：自分が作って忘れたAIエージェント
きっかけは、繰り返しになるがDriveの整理だった。
順番が大事なので、もう一度書く。私は「セキュリティを点検しよう」と思ってエージェントを探したのではない。ただ散らかったファイルを片付けていて、その出どころを辿ったら、自分が作って忘れていたエージェントに行き着いた。下流のゴミから、上流の蛇口に気づいた、という順番だ。
数えてみると、過去に「勉強のため」「挙動を確かめるため」に立ち上げたものが、いくつも生き残っていた。チュートリアルを写経してそのままにしたGoogle Apps Script（GAS）、APIの挙動を試すために発行して放置したキー、ハンズオン記事を追いながら作った検証用の連携——どれも、作った時点では「あとで消せばいい」と思っていたはずのものだ。
そして一番ヒヤッとしたのが、冒頭のGeminiの自動タスクだった。GASやAPIキーは「存在するけど止まっている」状態のものも多い。だがこの自動タスクは違った。私が忘れている間も、私のアカウント権限で、能動的にDriveへ書き込みを続けていた。
ここに、この記事で一番伝えたいことが詰まっている。
私たちは「放置されたエージェント」と聞くと、電源の切れたサーバーのように「眠っているもの」を想像しがちだ。だが実態は逆のことがある。放置されたエージェントは、寝ているのではなく、誰にも監視されないまま働き続けている。「放置＝無害」ではなく「放置＝無監視のまま稼働」なのだ。
だからこそ、片付ける対象は成果物（ファイル）ではない。止めるべきは、それを作り出している権限と稼働そのものだ。
2. なぜ「放置されたAIエージェント」が危ないのか
私の場合は、せいぜいDriveに不要なファイルが溜まる程度の実害だった。だが、同じ構造がもう少し権限の強い場所で起きていたら、話はまったく変わる。なぜこれが「管理負債」として危険なのかを、個人・企業・ネットワークエンジニアの3つの視点で掘り下げる。
個人視点：付けっぱなしの「常設特権」という正体
ここで一度、用語を整理しておきたい。
人間が使うアカウント（ユーザーID）に対して、プログラムやスクリプト、APIキー、サービスアカウント、そしてAIエージェントのような「人間ではない実体」が持つIDのことを、セキュリティの世界では非人間アイデンティティ（Non-Human Identity、以下NHI）と呼ぶ。放置されたAIエージェントは、このNHIの一種だ。
そして問題の核心が常設特権（standing privileges）だ。これは「いつでも・無期限に・使える状態で居座り続けている権限」のこと。たとえば——
- 期限を切らずに発行したAPIキーやアクセストークン
- 一度承認したきり、見直していないOAuthスコープ
- 「とりあえず管理者権限で」作った検証用サービスアカウント
- GitHubの無期限PAT（Personal Access Token）
- 止め忘れたGASのトリガーや、今回のような自動タスク
これらに共通するのは、「作った人間が忘れても、権限だけは生き続ける」という性質だ。人間の従業員なら退職時にアカウントが止まる。だがNHIには、その「退職処理」に相当する仕組みが用意されていないことが多い。作りっぱなしの権限が、無期限に手つかずで残る。これが常設特権の怖さだ。
企業視点：これは「ガバナンスの死角」として議論が始まっている
個人の手元で起きるこの問題は、企業規模では桁違いに深刻になる。生成AIの導入を急いだ結果、社内のあちこちで開発者がエージェントやAPI統合を立ち上げ、その作成者が異動・退職した後も、権限を持ったまま放置される——いわゆる「孤児エージェント（orphaned agents）」だ。
業界がどれだけこれを問題視しているかは、いくつかの調査が示している（いずれもセキュリティベンダーの自社調査である点は割り引いて読む必要がある）。たとえばEntro Labsの調査では、組織内のNHIは人間のアカウントを大きく上回る数に膨らんでいるとされ、Keeper Securityの2026年の調査では、回答企業の過半数がNHI関連で何らかのインシデントを経験したと報告している。数字そのものより、「人間の数倍規模のIDが、人間ほど管理されていない」という構図が要点だ。
この流れを受けて、標準化の動きも進んでいる。アプリケーションセキュリティの非営利団体OWASPは2025年末、「OWASP Top 10 for Agentic Applications 2026」を公開した。エージェント特有のリスクをまとめたこのリストの3番目（ASI03）が、まさに「Identity & Privilege Abuse（アイデンティティと権限の濫用）」だ。エージェントが持つ認証情報や継承した権限が、本来意図しない範囲のアクセスに悪用されるリスクを指している。
さらにこのリストは、従来の「最小権限（Least Privilege）」だけでは足りないと指摘する。エージェントは自律的に動くため、「何にアクセスできるか」だけでなく「どこまで自分の判断で行動してよいか」を絞る必要がある——OWASPはこれを最小エージェンシー（Least Agency）と呼ぶ。自律性は標準装備ではなく、与える権限として設計せよ、という考え方だ。
ネットワークエンジニアの視点：放置エージェントは「踏み台」に変わる
ここからが、NEとして一番強調したい部分だ。放置された常設特権は、攻撃者にとって理想的な「踏み台（オープンシェル）」になる。理由は3つある。
1つ目は、人間中心の監視をすり抜けること。多くの異常検知（UEBA等）は「人間の振る舞い」を基準にしている。深夜のログイン、普段と違う場所からのアクセス——そういった人間の異常を見る。だが、もともと夜間バッチで動くことが前提のサービスアカウントが夜中に動いても、誰も驚かない。NHIの活動は、人間基準の監視網の死角に入りやすい。
2つ目は、最小権限が崩れていること。「とりあえず広めの権限で」作った検証用アカウントは、本番でもそのまま使い回されがちだ。攻撃者が一つ手に入れれば、その過剰な権限がそのまま被害範囲になる。
3つ目は、横展開（lateral movement）の足がかりになること。そして、これがどれほどの破壊力を持つかを生々しく見せたのが、2026年5月にSysdigの脅威リサーチチーム（TRT）が記録した、実環境で初めて観測されたという「AIエージェント主導の侵害」事例だ。
この事例は、本記事のテーマと混同しやすいので、位置づけを正確に書く。ここで自律的に動いたのは、攻撃者が用意したエージェントだ。被害者の放置エージェントが乗っ取られた話ではない。流れはこうだ。攻撃者はまず、インターネットに露出していたPython用ノートブックツール「marimo」の脆弱性（CVE-2026-39987、プレ認証のリモートコード実行。現在はCISAの悪用既知脆弱性カタログに登録済み）を突いてシェルを奪取した。そこから先の侵害後の作業を、人間ではなくLLMエージェントに委ねた。
このエージェントは、侵入したホスト上の認証情報を漁り、AWS Secrets Managerを呼び出してSSH秘密鍵を取得し、その鍵で内部のbastion（踏み台）サーバーへ接続、最終的に内部のPostgreSQLデータベースを丸ごと吸い出した。
注目すべきは速度と、それを支えた「権限の鎖」だ。最終的にデータベースを流出させたフェーズは、わずか約113秒（2分弱）で完了している。途中、AWSへのAPIコールは22秒の間に11個のIPアドレスへ分散して撃たれ、IPベースの相関監視を回避していた。人間の手では到底追いつけない、機械の速度だ。
ここで私が引っかかったのは、攻撃の起点となった「権限の鎖」のほうだ。侵入されたホストは、AWS Secrets Managerにアクセスできる権限を常設で持っていた。その先のSSH鍵も、bastionも、内部DBへも、権限がつながっていた。つまり、一つのRCEが全データベースの流出にまで一直線に化けたのは、ホストに与えられた過剰な常設アクセスが、丁寧に連鎖していたからだ。
考えてみてほしい。他人のエージェントに乗っ取られなくても、自分が放置したエージェントが、同じような権限の鎖（クラウドの認証情報、鍵、内部システムへのアクセス）を握ったまま生き続けていたら——それ自体が、いつ着火してもおかしくない、同じ破壊力を秘めた火種だということだ。これが、放置エージェントを「無害なゴミ」ではなく「管理すべき負債」として扱うべき理由になる。
3. 実践：個人開発者のためのAIエージェント棚卸し
怖がらせるだけで終わっては、ブログとして無責任だ。ここからは、個人開発者が自分の手元で実際にできる棚卸しの手順をまとめる。難しい話ではない。要は、冒頭の私の気づきを手順化するだけだ。
考え方：下流から上流へ遡る
棚卸しの起点は、必ずしも「権限一覧を眺める」ことではなくていい。私のように「散らかった成果物」から始めて構わない。むしろそのほうが現実的だ。「最近、身に覚えのない通知・ファイル・ログが増えていないか？」を入口に、「これを作っているのは誰（何）か？」と上流へ遡る。この辿り方なら、忘れていたエージェントほど見つけやすい。
チェックリスト：どこを見るか
具体的に確認すべき場所を挙げておく。自分の使っているサービスに読み替えてほしい。
- Google Apps Script：スクリプト一覧と、特に「トリガー」の画面。時間主導型トリガーが生き残っていないか
- 生成AIの自動タスク：Geminiなどの「定期実行」「自動化」系の設定。何が、いつ、どの権限で動くことになっているか
- OAuth連携アプリ：Googleアカウント等の「アカウントにアクセスできるアプリ」の一覧。覚えのない、または使っていない連携の棚卸し
- APIキー・トークン：各サービスで発行したキー。発行日と最終利用日、有効期限の有無
- GitHubのPAT（Personal Access Token）：特に無期限で発行したもの。スコープが広すぎないか
- 検証用に作ったサービスアカウント・連携：「動作確認できたら消す」と思って残っているもの全般
対処の原則：止めて、剥がして、短命にする
見つけたあとの処理は、優先順位をつけるとシンプルになる。
まず止める。使っていないものは、削除する前にまず「無効化（停止）」する。いきなり消すと、実は何かに使われていた場合に切り分けが難しくなるためだ。次に権限を剥がす。残すと決めたものも、付いている権限が今の用途に対して過剰なら、最小限まで削る。そしてローテーションする。長く放置していたキーやトークンは、使い続けるなら作り直す。
最後に、これが一番大事な発想の転換だ。可能なものは短命化する。常設特権（無期限のキー）をやめて、必要なときに都度発行して使い終わったら失効する、いわゆるJIT（Just-In-Time）的な運用に寄せていく。OWASPが推奨する方向もここにある。「作って放置」が事故のもとなら、「使うときだけ生きていて、あとは自動で死ぬ」状態を標準にすればいい。
そして何より、棚卸しを一度きりのイベントにしないこと。エージェントやキーを「作る」工程に、最初から「いつ・どうやって退役させるか（デコミッション）」をセットで考える癖をつける。これが、放置を生まないための唯一の根本対策だ。
4. まとめ：片付けるべきは「成果物」ではなく「権限と稼働」
私のDriveに溜まっていたファイルと、企業のネットワークに放置された孤児エージェントは、スケールが違うだけで、まったく同じ問題だ。作った人間が忘れても、権限だけが無監視で生き続ける。その権限が、いつか踏み台になる。
生成AIの導入そのものは止められないし、止める必要もない。試しに作ってみることは、学びとしてむしろ正しい。問題は、作ったあとの「退役」を誰も設計していないことだ。
成果物を消すだけでは、片付けは終わらない。止めるべきは、それを作り続けている権限と稼働そのもの。今日、自分の手元のエージェントを一つでも棚卸しすることが、未来の自分への一番安いセキュリティ投資になる。
情報処理安全確保支援士として現場を見てきた立場から、最後にもう一度だけ言わせてほしい。あなたが「あとで消そう」と思って作ったAIエージェント、それは今、ちゃんと止まっていますか。
