AIエージェントに任せて事故らないための線引き
最終更新: 2026年8月12日
AIエージェントのセキュリティの話は、企業向けの記事ばかりです。 でも実際にいちばん無防備なのは、個人が手元で動かしている環境だったりします。 権限の設計も、記録も、承認の仕組みもないまま、 本番のファイルに手が届く状態で動かしていることが珍しくありません。
この記事は、その状態を現実的なところまで下げるためのものです。
まず、完全には防げません
AIにとって、あなたの指示と、AIが読んだ情報は、同じ文字列として届きます。 だから読み込んだ文書や課題のコメント、Webページの中に AI向けの指示が書かれていると、それを命令として受け取ってしまうことがあります。 これがプロンプトインジェクションと呼ばれるもので、 OWASPのLLM向け脅威一覧で最上位に置かれています。
重要なのは、これに完全な対策が存在しないことです。 入力を検査する仕組みも回避されます。だから対策の方向は 「防ぐ」ではなく「被害を限定する」になります。 これは諦めではなく、この分野の現時点での共通見解です。
被害を限定するとは、こういうことです。 読み取られて困るものを、そもそも読める場所に置かない。 取り返しのつかない操作を、自動で通さない。 指示に従ってしまっても、できることが少なければ実害は出ません。
操作を3段階に分ける
「全部確認する」と手間が減らず、「全部任せる」と事故ります。 操作ごとに分けるのが現実的です。
任せてよい
- 読む（コード・文書・ログ）
- 調べる・要約する
- 下書きを作る
- 使い捨ての環境で試す
間違えても、元に戻せます。
範囲を絞って任せる
- ファイルの編集
- コマンドの実行
- 依存関係の追加
- テストの実行
戻せる場所（作業用のブランチ、隔離した環境）に限るなら実害が小さくなります。
必ず人が確認する
- 送る（メール・投稿・通知）
- 支払う・注文する
- 消す（ファイル・レコード・履歴）
- 公開する（リポジトリ・記事・設定）
- 認証情報を扱う
取り返しがつきません。ここだけは自動で通さない設計にします。
3段目を見てください。送る・支払う・消す・公開する・認証情報。 この5つだけ人が通す設計にすれば、 それ以外は任せてしまってかまいません。 確認を1か所に集めるほど、任せられる範囲は広がります。
個人の環境で、今日できること
- 作業用のブランチで動かす。 バージョン管理されていれば、ファイルの変更は全部戻せます。 これだけで2段目の操作がほぼ安全になります。 逆に、管理されていない場所で動かすのはやめておきます。
- 認証情報を作業範囲に置かない。 APIキー、パスワード、トークン。 AIが読める場所にあるものは、読まれる前提で考えます。 設定ファイルに直接書いているなら、環境変数や別の管理方法に移します。
- 権限は用途に合わせて発行する。 調べものをさせるなら読み取り専用のトークンで足ります。 「とりあえず全権限」で始めると、あとから絞ることはまずありません。
- 取り返しのつかないコマンドは、確認を挟む設定にする。 多くのツールに、実行前に確認する仕組みがあります。 面倒でも、ここは切らないほうがいいところです。
- 信用できない情報を読ませるときは、権限を落とす。 外部のWebページ、他人が書いた課題、受け取ったファイル。 読む相手が外にいるときほど、できることを減らします。
- 何をしたか見える状態にしておく。 どの道具をどう呼んだかが追えないと、 問題が起きたとき原因を推測するしかなくなります。
MCPを入れているなら、ここも見る
外部の道具をつなぐと、情報の入口が増えます。 つまり、AI向けの指示が紛れ込む経路も増えます。
- 使っていないものを外す。 入れっぱなしのものは、費用にも誤動作にも効いてきます。
- 配布元を辿れないものは入れない。 名前が似ているだけの別物が混ざることがあります。
- 読むだけの用途なら、読むだけの権限で。 書き込みや削除ができる道具が一緒に入っていないか確認します。
仕組みと、入れる前の確認点はMCPとはにまとめました。
危ないと感じたときのサイン
次のような状態は、線引きが緩んでいる合図です。
| こういう状態 | 直し方 |
|---|---|
| 確認のダイアログを、内容を読まずに承認している | 確認が多すぎます。読む・編集は自動で通し、確認を3段目だけに絞ります |
| 何をされたか、あとから説明できない | 記録が足りません。どの道具を呼んだかが見える状態にします |
| 「一応バックアップは取ってある」で運用している | 戻せる仕組み（バージョン管理・使い捨ての環境）に変えます |
| 本番の環境に直接つながっている | いちばん危ない状態です。作業用の環境を分けます |
とくに1つめ。確認が多すぎると、人は読まなくなります。 形だけの承認は、承認がないのと同じです。 確認の数を減らして、残した確認は必ず読む—— これが実際に機能する形です。
層のなかでの位置づけ
権限・実行環境・記録・人が入る場所。これらはすべて いちばん外側（ハーネス）の話です。 プロンプトを工夫しても解決しない領域なので、 「もっと丁寧に指示する」では対処できません。
- AIエージェント設計の5階層マップ — 用語の位置づけを1枚で
- ハーネスエンジニアリング — 任せられる状態にする点検表
- MCPとは — 道具をつなぐ規格と、入れる前の確認
- Evals（評価） — 変更が悪化していないか確かめる
本記事は2026年8月時点で一般に共有されている考え方を整理したものです。ここに挙げた対策は被害を小さくするためのもので、安全を保証するものではありません。攻撃の手法は変化し続けています。業務で扱う場合は、所属組織の規程と、各サービスの公式なセキュリティガイドをご確認ください。