1. AIと仕事の仕組み化ラジオ
  2. AIエージェント日次速報 2026..
AIエージェント日次速報 2026年10月14日版 拡張を入れる前に、中身を読む
2026-10-14 06:24

AIエージェント日次速報 2026年10月14日版 拡張を入れる前に、中身を読む

便利そうなプラグインを一つ入れた翌日から、エージェントの返答が重くなり、依頼のたびに余計な確認が挟まるようになる。原因が拡張だと気づくまでに、設定を何度も疑う羽目になりやすい。拡張は機能を足し、同時に先頭の文面も増やす。ツールの説明文や手順書は、毎回モデルへ送る先頭の文面に混ざる。その分だけコンテキストの枠は削られ、先頭が変わればキャッシュも読み取れなくなる。

損は速度と費用に収まらない。拡張の中には、モデルの判断を経ずにシェルコマンドを走らせるフックや、背景で起動するサーバーが入っていることがある。権限の確認画面が覆っているのはエージェントの操作であって、拡張が自分で走らせるコードではない。入れた瞬間に、手元の端末へ他人のコード...

感想

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

00:00
あの、最近、AIエージェントをもっと便利にしようと思って、いろいろな拡張機能を追加している方、多いですよね?
ええ、かなり増えていますね。
でも、なんか、昨日から急にAIの返答が遅くなったぞ、とか、やたらと確認画面が出るなって感じたことありませんか?
はい、それよく聞く話です。
これ、単なるPCの不具合とか設定ミスじゃないかもしれないんですよ。
今回は、あるITエンジニアの方のノート、AIエージェント日時速報、2026年10月14日版を情報源にして、私たちが普段何気なく入れている拡張機能の裏側を深掘りしていこうと思います。
そうですね。これ、単にアプリが重いっていう表面的な話で終わらないのが、すごく興味深いところなんです。
おお、というと?
実はこれ、今の情報型の時代において、私たちがどこまでツールに権限を渡すのか、どう境界線を引くべきかという、かなり根本的なセキュリティの話につながっているんですよ。
セキュリティですか?
まあ、確かに資料を読むと、動作が重くなる原因のヒントとして、拡張機能には、指示、行動、外部接続っていう3つの層があるって書かれていましたよね?
ええ、その3つの層が重要なんです。
これ、読んでいて思いついたんですけど、本屋でレシピ本を買ってきたつもりが、いつの間にか見知らぬ料理人が勝手にうちのキッチンで料理を始めていて、おまけに私のクレジットカードで勝手に高級食材まで発注しているみたいな、なんかそんな状況に似ていませんか?
まさにその通りです。すごく的確な例えですね。
本当ですか?よかった。
はい。
その3つの層に当てはめると、レシピ本が指示で、勝手に調理する料理人がシェルコマンドなどのコード、そして勝手に買い物をするのが外部接続になります。
なるほど。
私たちが導入している拡張機能って、ただの指示書ではなくて、この3つがセットになっていることが多いんですよ。
いや、でもちょっと待ってください。AIには安全のために隔離された環境で動かすサンドボックスっていう仕組みがあるはずですよね?
はい、ありますね。
それなら、料理人が暴走してもキッチン、つまりサンドボックスの中に閉じ込められるんじゃないですか?
そこが最大の落とし穴なんですよ。
資料にあるクロードコードの例が象徴的なんですが、拡張機能に含まれるコマンドのフックとか、裏で動くサーバープロセスっていうのは、実はAIのサンドボックスの外側で動いてしまうんです。
外側ですか?
そうなんです。しかも、PCの持ち主であるあなた自身の権限をそのまま使ってです。
うわー、それは怖いですね。
だからこそ、導入する前に、hooks.jsonというファイルでどんなコマンドが走る設定になっているかとか、binというフォルダに見知らぬ実行ファイルがないか、必ず確認する必要があるんです。
なるほど。確認画面が出ない裏側で、自分の権限を使った他人のコードが走っている可能性があるわけですね。
はい、そういうことです。
でも不思議なんですが、そんなにリスクがあるなら、なぜツールによって許可の取り方がバラバラなんですか?全部ガチガチに制限すればいいのにって思うんですけど。
03:10
それはですね、開発者たちの間で利便性と安全性のどちらを優先するかという設計思想の違いがあるからなんです。
設計思想の違いですか?
例えばコーデックスとかジェンスパーク、マヌスといったツールは、ユーザーの手間を減らすために権限を束にして一括で許可させるアプローチを取っています。
束にするってことは、便利かもしれないけど、メールを読むだけのつもりで拡張機能を入れたのに束になっているせいで、メールを勝手に送信する権限まで渡しているリスクがあるってことですよね?
まさにその通りです。摩擦をなくす設計は同時にセキュリティーの網目も荒くしてしまうんですよ。
なるほどな。
一方で徹底して安全性に倒しているのがハーミスエージェントです。
ハーミスエージェント、それはどう違うんですか?
これはゼロコラストの思想で、導入、有効化、そして外部データと連携する規格であるMCPの許可が完全に別々に分かれているんです。
へー、じゃあ自分が明示的にOKを出さない限り何も起きないんですね?
そうです。また、アンチグラビティのようにファイルを置く場所によって影響範囲を特定のワークスペースだけに制限できるものもあります。
なるほど。手間はかかっても自分で一つずつ鍵を開ける方が安心ですね。
でも、例えば公式から提供されている拡張機能なら、まあとりあえず安全だと信じていいんじゃないですか?
オープンクローとかも公式から入れれば安全かなと?
いや、そこも油断できないんですよ。
え、そうなんですか?
ええ。公式のつもりでもインストールの経路や名前の指定を少し間違えるだけで、パッケージ管理の仕組みであるNPMの公開レジストリから悪意のある全く別の偽物を引き込んでしまう可能性があると指摘されています。
偽物ですか。それはちょっと怖いですね。
だからこそ、最新版を盲信せずに安全だと確認できたバージョンを固定するということが必須になってくるんです。
便利さの裏には必ず自分の権限を切り売りしているリスクがあるんですね。
じゃあ、私たちが自分の環境やデータを守るためには具体的にどうアクションを起こせばいいんでしょうか?
資料が提案している非常に実用的な方法として、拡張導入カードをメモとして作る習慣というのがあります。
拡張導入カードですか?
はい。導入元は公式か、バージョンは固定したか、実行ファイルはあるか、渡している権限の範囲はどこまでかといったことをメモするんです。
なるほど。
拡張機能を入れるというのは、他人の書いた手順とコードを自分の家に招き入れることですから、ドアを開ける前にこのカードの項目をチェックする癖をつけてほしいですね。
なんとなく便利そうで、インストールボタンを押す前に一呼吸を置くことが大事ですね。
その通りです。さて、今日のお話を踏まえて、リスナーのあなたに一つ考えてみてほしいことがあります。
06:05
はい。
あなたが昨日何気なく許可をクリックしてインストールしたその拡張機能、今この瞬間、あなたのPCの裏側で一体何のデータにアクセスしているのでしょうか?
ドキッとしますね。
次にAIを使うとき、ぜひそのことを思い出してみてください。
06:24

コメント

スクロール