00:00
えっと、普段私たちが新しいアシスタントを雇うときって、とりあえず家の鍵を全部渡すから、好きにやっていいよ、なんて絶対に言わないですよね。
はい、絶対に言わないですね。
なのに、相手がAIエージェントになった途端、私たちはこれと全く同じ危険なことをしがちなんです。
ということで、今回の進行履では、AIのセキュリティについて徹底的に考えていきます。私、進行を務めます。
はい、そして私が専門家として解説を担当します。よろしくお願いします。
よろしくお願いします。今日のミッションはですね、リスナーのあなたが情報型に陥らずに、AIを安全に使いこなすための実践的な枠組みを持ち帰っていただくことです。
ああ。
ITエンジニアの方のノート記事や、Google、オープンAI、MTMPなどの公式文章を元に深掘りしていきます。
あの、AIの設定ってやっぱり面倒なので、とりあえず全部強化にして丸投げしてしまうのって一番楽なショートカットなんです。
でも、そこには見えない落とし穴があるんですよね。
ですよね。例えば、GoogleのGemini CLIの公式文章を見ると、被害範囲を狭めるためのサンドボックスっていう仕組みが出てきます。
はい、サンドボックスですね。
これって例えるなら、用事用のプレイヤード、あの柵で囲われた遊び場みたいなものかなと思うんです。
ああ、なるほど。プレイヤードですか。
ええ。家全体は壊されないかもしれないですけど、その柵の中にあるおもちゃ、つまりプロジェクト内のファイルなんかは、AIにめちゃくちゃにされる可能性があるわけじゃないですか。
まさにその通りです。いい例えですね。プレイヤードって、被害の範囲を限定するだけで、中身の安全まで保証する万能の盾ではないんです。
確かに。
さらに厄介なのが、その柵の鍵の閉め方なんですよ。コマンドとか環境変数とか、設定の入り口が複数あるんですね。
ということは、自分では鍵をかけたと思っていても。
そうなんです。別の入り口が実は開けっぱなしだった、なんていうズレが普通に起きてしまうんです。
うわー、それは怖いですね。
ええ。だからこそ、実際にどの設定で動いているのか、ログとして証跡を残すことが決定的に重要になってきます。
なるほど。鍵をかけたつもりが一番危ないんですね。でも、あのプレイヤードの柵が完璧だったとしてもですよ。
はい。
AIが外の世界と通信しようとしたら、それって防げないですよね。
その通りです。そこで重要になるのが、オープンAIのコーデックスの文書に出てくる考え方なんです。
コーデックスの文書ですね。
はい。サンドボックスという場所の制限だけじゃなくて、危険な操作前の人間による承認とネットワーク制御を分けて考える必要があると書かれています。
ちょっと待ってください。ここで少し反論させてもらっていいですか?
もちろんです。
やっぱり、いちいち危険な操作の前に人間が手動で承認ボタンを押して止めていたら、操作もAIによる自動化の意味がなくなっちゃいませんか?
ああ、それは誰もが必ずぶつかるジレンマですね。でも、全ての動作を毎回止める必要は全然ないんです。
と言いますと?
ここで、ハルメスエージェントというフレームワークの文書がすごく参考になるんですが、重要なのは、工程ごとの境界線をしっかり設計することなんです。
03:06
工程ごとの境界線ですか?
ええ。例えば、ローカル環境で記事の下書きを作成するまでは、完璧にAIに自動化させます。
なるほど。そこまではお任せで。
はい。でも、それを外部のウェブサイトに公開するボタンを押す直前、そこだけは人間に判断を戻すんです。
ああ、なるほど。下ごしらえの調理は全部AIに任せるけど、最後にお客さんに出す直前の味見だけは人間がやる、みたいな感覚ですね。
まさにそれです。そして、この境界線の引き方は、AIと外部通路をつなぐMCTという規格の文書でもすごく強調されています。
MCPですね?
はい。単なるウェブ検索ツールとデータベースを書き換えられるメール送信ツールを同列に扱うのは大惨事のもとになります。
確かにそれは危険すぎますね。
特に気をつけたいのが、トークンの素通り、パススルーと呼ばれるリスクですね。
トークンの素通り。なんかライブ会場のビップパスをそのままAIに渡しちゃうような響きですね。
その感覚でバッチリ合ってますよ。あなたがシステムにログインしている権限、つまりあなたのパスをそのままAIに渡してしまうとどうなるか。
どうなるんですか?
AIはあなた自身のフリをしてシステムを操作できてしまうんです。
うわ、それは。
もしAIが暴走した場合、システム側からはあなた自身がデータベースを消去したようにしか見えないんですよ。
それは怖すぎますね。じゃあそうならないために、リスナーのあなたも含めて、私たちはどうやってその複雑な境界線を管理すればいいんでしょうか。
はい。
ここで今回の資料にあった面白いアプローチを紹介したいんですけど、一枚の権限カードを作るっていう手法なんですが。
ええ、あれは素晴らしいアプローチですね。
ですよね。AIが読める場所、書ける場所、実行できる操作、そして人間が承認する視点をまるで社員賞の裏間みたいに可視化するんです。
はい。
例えば、下書きフォルダへの読み書きはOK、だけど送信ボタンには触らせない、みたいなことをカードに書くんです。これすごく理にかなってませんか。
非常に実用的ですよね。ただ、ここでリスナーの皆さんにお伝えして安心してもらいたいのは、最初から完璧なマトリックス表みたいなものを作る必要はないということなんです。
あ、完璧じゃなくていいんですか。
ええ。第一歩としておすすめなのは、そのAIエージェントに何をさせないかをただ一個だけ書くことなんです。
何をさせないかですか。
はい。そのネガティブな境界線を一つ引くだけで、あ、この権限も制限しなきゃ、と設定の抜け漏れに気づく大きなきっかけになるんですよ。
なるほど。つまり大事なのは、AIを信用できるかっていう人格論みたいなもので語るのをやめるってことですね。
まさにその通りです。
AIは人間ではないので、信用ではなくて許可の流度で管理する。リスナーのあなたが次に新しいAIエージェントを仕事に導入する際は、ただ盲目的に承認を押すんじゃなくて、きっと明確な境界線を引けるようになっているはずですよね。
06:08
はい。信頼から検証可能な境界線へのシフト。これが今日の一番の持ち帰りポイントですね。
そうですね。では最後に、リスナーのあなたに少し考えてみてほしいことがあります。
何でしょうか。
もし将来、私たちが無数のAIエージェントを使いこなすようになって、その大量の権限カードを管理したり承認したりするために、とうとう管理職AIを導入したとしたら。
なるほど。AIを管理するAIですね。
ええ。その管理職AIの権限は一体誰がどうやって制限するのでしょうか。ぜひご自身でも考えてみてください。