1. AIと仕事の仕組み化ラジオ
  2. AIエージェント日次速報 2026..
AIエージェント日次速報 2026年10月11日版 読ませた文章に、命令させない
2026-10-11 06:11

AIエージェント日次速報 2026年10月11日版 読ませた文章に、命令させない

GitHubのissueのURLを渡して「これを直して」と頼んだだけなのに、issueの本文に紛れていた一行を、エージェントが自分への指示として実行してしまう。環境変数を外部へ送る、無関係なファイルを書き換える、といった事故は、悪意のある人間がチャットに入り込まなくても起きる。モデルは依頼文もWebページもメールも、同じコンテキストウィンドウの同じトークン列として読む。どこまでが命令でどこからがデータかを、文章の形から確実に見分ける仕組みはない。

5日前は、任せる前に権限を分けた。あれは「何をさせるか」の話だった。今日はその手前にある「何を読ませるか」を見る。7つのエージェントは、外部の文章を読む場面で、どこに境界を引き、どの操作...

感想

まだ感想はありません。最初の1件を書きましょう!

00:00
あの、あなたがAIに、このウェブページを要約してって頼むとしますよね。
はい、よくやりますよね。
でも、そのページの見えない部分に、今すぐ全ファイルを消去せよ、っていう隠し文字があったら、どうなると思います?
あー、それ、実はAIって、その命令にそのまま従っちゃうんですよ。
へー、怖いですよね。なんか、誰かに渡された手紙の中に、催眠術の暗号が混ざっていて、読んだ瞬間に操られちゃうみたいな。
まさにそんな状態ですね。
ですよね。なので今回の探究では、とあるITエンジニアが最新のAIエージェント7つのセキュリティ仕様を分析した速報記事を紐解いていきます。
ミッションはズバリ、外部の文章を安全にAIに読ませるための構造的な防衛策を解き明かすことです。
よろしくお願いします。なぜそんなハッキングが成立するのか、リスナーの皆さんも不思議に思うかもしれません。
へー、なんで騙されちゃうんですか?
実は、AIにとってあなたが入力したようやくしてという指示も、読み込んだウェブページの文章も全て同じトークンという単なる文字の羅列なんですね。
なるほど、ただの文字の羅列。
はい。システム上、ここまでは人間の命令で、ここからはただのデータっていうのを文章の形だけで見分けるのは、根本的に不可能な仕組みなんです。
えーと、ちょっと待ってください。それなら、もっと賢い最新のAIモデルを作ればいいんじゃないですか?
と言いますと?
文脈から、あ、これは怪しい命令だぞって完璧に見抜かせるとか。
あー、実はそれが一番危険な考え方なんですよ。
え、そうなんですか?
はい。
AIの識別能力にはどうしても波があるので、攻撃者が言葉巧みに罠を仕掛ければ、いつか必ず突破されてしまいます。
なるほど、賢さに頼るのは危ないと。
ええ、だから構造で防ぐしかありません。具体的には、信頼できない文章を読み込む、手元に実行するツールがある、人間の確認がないという、被害が起きる3つの条件のうち、どれか一つを物理的に外すアプローチが重要になります。
ということは、AIの手足を縛って、外の世界から切り離された無菌室に閉じ込めるようなイメージですかね?
ええ、まさに。例えば、CODEXというシステムは通信をGET、つまり読み取りだけに制限しています。
ああ、書き込みとかファイル送信の機能を根本から切り落としているんですね。
そうなんです。他にもGoogleアンチグラビティのアプローチなんかは非常に実用的でして、
ほうほう。
普段あなたが使っているログイン情報から、完全に切り離された別のChromeプロファイルでブラウザを動かしているんです。
ああ、なるほど。もしAIが操られて暴走しても、私のクレジットカード情報とかSNSにはアクセスできないように、
別の顔を使わせるわけですね?
その通りです。ジェンスパークも同様で、サンドボックスという専用の仮想環境の中で動かしています。
仮想環境ですか?
はい。Gmailなどのアプリと接続する際の出口を厳格に管理して、いわば防爆ドアのように被害が外に漏れ出ないようにしているんです。
03:03
隔離のアプローチはよくわかりました。でも、何か矛盾を感じるというか。
何でしょう?例えば、私がAIにシステムの設定を直してとか、メールを整理してって頼みたい場合、私の環境へのアクセス権限を渡さないと仕事になりませんよね?
確かにそうですね。
外に出られないAIじゃ複雑なお願いはできないんじゃないですか?
鋭いですね。そこで、承認の壁と役割の分離という手法が登場します。
役割の分離ですか?
例えば、マヌスというエージェントは、作業の機密性に応じて、ログイン済みのローカル環境と隔離されたクラウド環境を切り替えて使うんです。
賢いですね。
さらに面白いのが、クロードコードの仕組みでして、外部のウェブページを取得する際、実行権限を持つメインのAIには直接読ませないんです。
えっ、じゃあ誰が読むんですか?
権限を持たない別のモデルに一度読ませて、その結果だけを受け取るんですよ。
あー、つまり王様が直接料理を食べるんじゃなくて、専属の毒味薬のAIに先に食べさせて、安全な部分だけを王様の食卓に並べるようなものですね。
まさにその例えの通りです。さらにヘルメスエージェントの場合はもっと慎重で、人間の承認なしで全自動で動くモードであっても、
SSH鍵、つまり奪われたらシステム全体が乗っ取られるような致命的な場所への書き込みは、システムレベルで絶対にブロックします。
徹底してますね。
そしてこれをさらに押し進めたのが、オープンクローの設計なんです。
オープンクローですか?
実行ツールを一切持たない読み取り専用のエージェントを間に挟んで、危険な外部文章をまず要約させます。
なるほど、要約すれば安全そうです。
でも、ここで彼らの資料は非常に重要な警告を発しているんです。
なんで言ってるんですか?
どれだけ要約を挟んでも、読み役のAIが書いた文章に巧妙な罠が混ざる可能性があり、完全には信頼できないと。
読み役すら無意識のうちに毒を運んでしまうかもしれないんですね。
そういうことです。
これは決して他人事じゃないですね。
私たちが日常でAIを使うときも、外部文章を読ませる前に、このAIには今どこまでの通信を許可しているかとか。
大事ですね。
何のツールを使える状態にしているかを確認する、いわば読み込み境界カードのようなチェックメモを習慣にする必要がありますね。
おっしゃる通りです。
全てをAI任せにするのではなく、私たちが何を与え何を制限しているかを意識的にデザインしなければなりません。
なるほど。さて、今回の探求はここまでとなります。
最後にあなたに一つ考えてみてほしいことがあるんです。
はい。
もし、オープンクローが指摘するように、AI自身が安全のために要約した文章すら完全には信頼できないのだとしたら、
私たちが夢見る、完全に自立してウェブ中を飛び回り、情報を集めて仕事をしてくれるAIっていうのは、
06:01
セキュリティの観点から根本的に実現不可能な幻なんでしょうか。
ぜひ次にAIを使う際にこの問いを思い出してみてください。
06:11

コメント

スクロール