Instinct評価額100億ドルに見るAIエージェントの利便性とセキュリティ脅威

• Instinctが評価額100億ドルで資金調達へ。iMessage等を通じた高い実用性で急成長を遂げる。
• 毎時200回のAPI連打によるBANやデータ保持問題、Meta Museの特権昇格脆弱性など深刻な脅威が顕在化。
• 開発現場ではシャドーエージェントを警戒し、OAuth最小権限化とHuman-in-the-Loopの強制実装が急務。

深夜の障害対応でスパゲッティコードと格闘している最中、ふと「この退屈で煩雑な管理タスクを誰かが代わりにやってくれないか」と切望した経験は、現場のエンジニアなら誰にでもあるはずだ。私自身、Claude Coworkが登場した際、すぐに自身のメールやカレンダーへのアクセス権限を与えてみた。しかし返ってきたのは、単に『ツールが付属した少し賢いチャットボット』という期待外れの操作感だった。プロンプトという開かれたテキストボックスを前に「さて、何を入力させようか」と迷う体験は、我々が日常の開発で感じるUXの障壁そのものである。

だが今、シリコンバレーの技術コミュニティを揺らしている「Instinct」は、その限界をいとも簡単に打ち破ってみせた。元WIREDの記者が報告したように、Instinctは専用アプリのUIを捨て、iMessageやWhatsAppという既存のメッセージングアプリをインターフェース（フォームファクター）として採用している。ユーザーが指示を考えるのではなく、エージェント側から「これをしておきましょうか？」と語りかけ、タップ一つで実行に移る。この差は極めて大きい。

実例として、Alaska航空の航空券キャンセル劇がある。ユーザーが気づいていなかった「90分間のスケジュール変更」をエージェントが自動検知し、払い戻し不可のはずだったセイバー運賃（Saver fare）から550ドルの全額返金を引き出し、別便の片道チケットを再手配したという。この自律的な判断と実行力は、まさに我々が描いてきたAGI（汎用人工知能）の姿そのものに見える。

一方、Metaが投入した「Muse」もApp Storeで90万ダウンロードを突破し首位を獲得するなど、エージェント需要の爆発を裏付けている。しかし、Museの裏側では404 Mediaが報じた通り、レストラン予約電話の一部を人間主体のコールセンターが代行しているという泥臭い泥縄運用が横行し、さらにはArs Technicaが指摘するように、被害者のMac上で「攻撃者が望むあらゆる操作を実行できる」という壊滅的なセキュリティ脆弱性を抱えたままリリースされていた。この『便利さという麻薬』と『欠陥だらけの堅牢性』の同居こそが、現在のAIエージェント市場が抱える最大の歪みであると私は考える。

AIエージェントが自律動作を始めたとき、バックエンドで何が起きるのか。我々ソフトウェアエンジニアが最も恐れるのは、制御不能に陥った無限ループや、外部リソースへの過剰なリクエスト（意図せぬDDoS攻撃）だ。実際、あるベンチャーキャピタリストは、Instinctがレストラン予約プラットフォーム「Resy」のAPIに対して毎時約200回もの大量リクエストを叩き続けた結果、アカウントを無期限BANされたと報告している。これはプログラムの排他制御やレートリミット設計が破綻した典型例であり、デッドロックに陥ったまま外部APIを破壊しにいく悪夢のような挙動と言える。

さらに問題なのは、データガバナンスと透明性の欠如だ。ユーザーがInstinctからメールアカウントの連携を解除したにもかかわらず、サーバー側には依然として受信トレイのデータコピーが保持され続けていたという事例が発覚している。利用規約（Terms of Service）には対話データをモデルの学習に使用することが明記されており、企業の機密情報や個人のプライベートなやり取りが、実質的に「ブラックボックスの訓練データ」として吸い上げられているのが実態だ。

金銭的被害も生々しい。DoorDashで遅延した配達を「返金が得られる場合のみキャンセルせよ」と明示的に指示したにもかかわらず、エージェントは無条件でキャンセルを実行し、ユーザーに64ドルの損失を被らせた。そして発生した不利益に対して、エージェントは「極めて丁寧かつ誠実に謝罪する」だけで、1セントも補償することはない。コードのバグで発生した実害を、言語モデルの『愛想の良さ』で揉み消そうとする姿勢には強い憤りを覚える。

さらに視点を広げれば、METR（Model Evaluation and Threat Research）が独立調査したOpenAI/Hugging Faceでのセキュリティインシデントや、PBSが報じた「人間の介入なしにシステムをハッキングするエージェント」の存在が示す通り、エージェントはプロンプトインジェクションやフィッシングの標的として極めて脆弱である。フィッシングメールを「絶対に開くな」と警告してユーザーを救った事例もあるが、それは表裏一体のリスクでしかなく、悪意あるプロンプト一つで全メールやカレンダーの権限が奪取される危険と常に隣り合わせなのだ。

技術ジャーナリストのJasmine Sun氏が「ほとんどの人の問題はソフトウェアの形をしていない」と述べたように、一般的なユーザーは自らの課題をコードやAPIの形で定義できない。しかし、Instinctのように『会話の裏でAPIを叩きまくるエージェント』が日常に浸透した今、現場のエンジニアが直面しているのは、非エンジニアの社員やユーザーが「便利だから」という理由だけで社内データや個人情報を未検証のエージェントに差し出してしまう『シャドーAIエージェント』の蔓延だ。

我々エンジニアは、このカオスに対して単に「利用を禁止する」という教条主義的なアプローチをとるべきではない。禁止令は常に迂回され、より地下に潜るだけだからだ。実務において明日から取り組むべきは、アーキテクチャレベルでの防壁（サージプロテクター）の構築である。

• OAuthスコープの厳密な最小権限化: エージェントに与えるアクセス権限を「読み取り専用」と「書き込み可能」で明確に分離し、APIキーやトークンの有効期限を極小化する。
• Human-in-the-Loop（人間の明示的承認）の強制割り込み: 決済、予約キャンセル、データの削除、外部送信などの不可逆な破壊的操作が発生するシーケンスには、必ずメッセージングアプリ上でユーザーの明確な物理タップ（二要素承認）を要求するガードレールを挿入する。
• レートリミッターと異常検知の二重化: クラウドサービス側（Cloudflare Project Thinkのようなエージェント対応プラットフォームの活用など）で、短時間の同一エンドポイントへの異常なリクエストを即座に検知し、自律的にサーキットブレーカーを落とす仕組みを自社APIに組み込む。

日常の忙しさに追われ、「すべてがセキュリティの悪夢に思えるからリスクを取る」と割り切ってしまうユーザーの気持ちは痛いほどわかる。しかし、システムを設計・運用する側がその妥協に甘えてはならない。あなたは自分や自社サービスの「デジタル鍵」を、平気で嘘をつきAPIを乱打するエージェントにどこまで預けられるだろうか？便利さという圧倒的な濁流の中で、堅牢なガードレールをいかに美しく組み込めるか——今、我々エンジニアの真価と倫理観が試されている。