オルタナティブ・ブログ > 生涯ITエンジニアでいこう。 >

どんどん出てくるIT業界の新トレンドを乗りこなし末長くエンジニアをやっていきましょう。

パイロットがPRを承認する時代、『仕様駆動・ループ・サンドボックス』――エンジニアに残る仕事、増える仕事(3)プロンプトインジェクションとサンドボックス

»

1. はじめに――任せるほど、狙われる

前回までで、エージェントに仕事を任せるための仕組みを見てきました。

仕様を書き、ループを回し、スキルやMCPで文脈を渡す。

エージェントは、どんどん「できること」が増えていきます。

でも、ちょっと立ち止まって考えてみてください。

ファイルを読めて、Webを見られて、外部にリクエストを送れる存在。

それが、誰かに騙されたら......?

便利さと攻撃されやすさは、同じコインの裏表だ。

2. エージェント時代のSQLインジェクション

Webアプリの世界では、SQLインジェクションが長年の宿敵でした。

入力欄に紛れ込んだ文字列が、命令として実行されてしまう。

AIエージェントの世界で、その役回りを担うのがプロンプトインジェクションです。

外から読み込んだテキストに紛れた「命令」を、エージェントが本物の指示として実行してしまう。

LLMには、データと命令をきっちり区別する仕組みがないからです。

「読んだもの」と「頼まれたこと」の境界が、LLMにはない。

3. 3つがそろうと危ない――「致命的な三要素」

動画では、危険が高まる条件として次の3つを挙げています。

  1. 機密データへのアクセス:ローカルのファイル、秘密鍵、認証情報
  2. 信頼できない外部コンテンツへの露出:Webページ、他人が書いたPull Request、メール
  3. 外部への送信能力:API呼び出し、ネットワーク通信

この組み合わせは、「プロンプトインジェクション」という言葉の名付け親でもあるSimon Willison氏が「lethal trifecta(致命的な三要素)」と呼んで警鐘を鳴らしているものです。

たとえば、こんなシナリオです。

エージェントにオンライン上のPull Requestをレビューさせる。

そのPRの説明文に、悪意ある命令がこっそり仕込まれている。

エージェントはそれに従い、開発者のPCにある秘密鍵を読み出し、攻撃者のサーバーへ送ってしまう――。

しかも開発者は、そのことに気づかない。

第1回のパイロットを思い出してください。

スマートフォンでPRを承認していましたよね。

もしそのPRを書いたのが、乗っ取られたエージェントだったとしたら......。

3つのうち2つまでなら耐えられる。3つそろった瞬間に、事故は「時間の問題」になる。

4. 対策:使い捨てサンドボックス

先進的なチームが採っている方法は、シンプルです。

エージェントと作業対象のコードを、**使い捨てのサンドボックス(Disposable Sandbox)**の中で動かす。

仮にエージェントが乗っ取られても、被害はその箱の中で止まります。

手元のPCの秘密鍵には、そもそも手が届きません。

作業が終われば、箱ごと捨てる。

考え方としては、3つの要素のうちどれか1本を断ち切ることです。

サンドボックスは、そのうち「機密データへのアクセス」を物理的に切り離す手段だといえます。

以前の記事「情報漏洩ラッシュ2026」で「前提はもう崩れている」と書いた背景には、まさにこの構造があります。

「AIが賢くなれば防げる」ではなく、「乗っ取られても大丈夫な場所で動かす」発想へ。

5. 明日からできること

  • 自分のエージェント環境の「三要素」を数えてみる:機密データ、外部コンテンツ、外部送信。3つそろっていたら、どれか1つを切る
  • エージェントはコンテナやクラウドのサンドボックスで動かす:手元のPCで、秘密鍵の隣に置いたまま動かさない

数えるだけなら、5分で終わります。

セキュリティ設計も、指揮者の仕事のうち。

6. 結論:エージェントを信じるのではなく、環境で守る

今回のポイントをまとめます。

  • プロンプトインジェクションは、エージェント時代のSQLインジェクション
  • 機密データ、外部コンテンツ、外部送信の3つがそろうと危険が跳ね上がる
  • 対策の基本は、使い捨てサンドボックスで「1本を断ち切る」こと

これもまた、AIが増やしたエンジニアの仕事です。

コードを書く手間は減っても、「安全に任せられる場所」を設計する仕事は確実に増えています。

次回は最終回。アンドリュー・エン氏の「AIは新しい電気」という言葉から、これからのエンジニアの居場所を考えます。

あなたのエージェントは、いま、どの「三要素」を持っていますか?

出典・参考

Comment(0)