第333号

エージェントごとに1台のコンピューター、今や問題は鍵です

メタ・OpenAI・Grok Bot・Googleが同じ絵を描きました。残る問いはログインとパスキーです

ビジネス

アン・グァンソプ（Oswarld）· INLEVEL9 著者・編集者

Google の優先ソースに追加
エージェントごとに1台のコンピューター、今や問題は鍵です

2か月前の比喩が製品説明書になりました

今年8月、「エージェントはGPUで考え、CPUで働きます」という記事でこんな一文を書きました。エージェントを1つ雇うのは、そのエージェントが使うコンピューターを1台与えるようなものだと。当時はあくまで比喩でした。

この2か月の間に、その一文が製品説明書へと移っていきました。8月11日にGrok Botがベータ版として登場し、9月8日にメタがMuse（ミューズ）を、9月29日にOpenAIがDevDayでdots（ドッツ）を発表しました。この3つの製品はいずれも、紹介文の冒頭に同じ言葉を記しています。エージェントが自分専用のコンピューターと自分専用のブラウザを持ち、ユーザーがアプリを閉じても、そのコンピューターの中で仕事を続けるというものです。10月22日には、Google Cloudがこうしたエージェントを支えてきた内部インフラ、Agent Compute Engine（エージェント・コンピュート・エンジン）の設計を、読むのに18分かかる記事として公開しました。Cloudflareは「エージェントにコンピューターを与えよ」という紹介文を掲げたオープンソースのリポジトリを運営しています。

私は、これがいまや標準になりつつあると見ています。それぞれSecure VM、クラウドコンピューター、マイクロVMなどと呼び方は違いますが、エージェントにコンピューターを与え、そこで仕事をさせるという骨格は同じです。そのため、問いが1段階先へと移っていきます。そのコンピューターの中のブラウザから、人間が使っていたウェブサイトにアクセスするにはログインが必要になりますが、パスワードや各種認証、特にパスキーをどこに置くのかという問題です。

名前は違っても骨格は一つです

まず5社が出したものを一つの表に並べてみます。公式発表文と文書で確認した内容だけを記載しています。

製品公開時期コンピュータを与える単位ログイン・決済の扱い方
Grok Bot2026年8月11日ベータユーザーアカウントごとに1台、そのアカウントの全Botが共有パスワード・パスキー・2段階認証・決済は人間が画面を引き継いで直接処理
Meta Muse2026年9月8日、米国人ごとに専用VM（Muse Secure VM）認証情報はVM内のセキュアストレージに置き、エージェントは見られないまま使用
OpenAI dot2026年9月29日dotごとにクラウドコンピュータとブラウザパスワードマネージャー連携は別権限で管理、ユーザーの既存ログインは引き継がれない
Google Agent Compute Engine2026年10月22日設計公開、数か月以内にプレビューを目指すエージェントセッションごとにハードウェアで隔離したマイクロVM1認証情報をサンドボックス2内に置かず、外部のゲートウェイで差し替える
Cloudflare Computerオープンソース（MIT）ファイルシステムを状態として保持し、実行環境は選んで付け替えるREADMEでは確認できず

表を見ると「1台ずつ」という言葉にも少し違いがあります。Grok Botは、Botごとにコンピュータを与えるわけではありません。アカウント一つにコンピュータ1台を置き、Botごとに画面を別々に与えます。xAIの文書には、この画面は作業スペースにすぎず、セキュリティ境界ではないと書かれています。そのため、ブラウザのクッキーとログインセッション、ファイル、コマンドライン認証情報はアカウント内の全Botに共有されます。このコンピュータはCursorのクラウド上で動いています。

Cloudflare側はそもそもVMではありません。Durable Objectという保存単位の中にSQLiteでファイルシステムを持たせ、実行はLinuxコンテナか軽量な隔離環境のどちらかを選んで付け替える構造です。実行環境なしでファイルシステムだけを使うこともできます。リポジトリには、パッケージ全体は本番運用に使ってよいが、コンテナバックエンドはまだ実験段階だと明記されています。

この違いこそが、むしろ共通点を示しています。エージェントに必要なコンピュータは、結局のところ二つの要素からできています。長く残る作業状態と、その状態を使って何かを実行する場所です。GoogleとMetaはこの二つを1台のVMに収め、Cloudflareはこの二つを切り離しただけなのです。

なぜよりによってコンピューター1台だったのか

Googleの説明がいちばん詳しいです。Geminiチームの目標は、ユーザーごとにクラウド上で動く個人エージェントを付けることでした。ユーザーの作業を記憶し、ユーザーが席を外している間も働くエージェントです。そのためには、エージェントごとにファイルシステム、言語ランタイム、ブラウザ、ネットワークを備えたコンピューターが必要だったといいます。

Googleはエージェントを2つの部分に分けて説明しています。モデルを呼び出し次の行動を決めるハーネス3が頭脳であり、モデルが指示したコードやコマンド、ブラウザを実際に動かすサンドボックスが手です。手を与えるにはコンピューターを与える必要がありますが、既存の選択肢はどちらも合いませんでした。一般的なVMは起動・停止・再起動に数秒から数分かかり、コンテナは速いものの、ホストのカーネルを共有するため、root権限まで必要とするコーディングエージェントを隔離するには脆弱です。

ここにGoogleが測定して得たもう1つの観察があります。エージェントはほとんどの時間を待機に費やしています。モデルの次の返答を待ち、ユーザーの返信を待ちます。そこで、ツールの実行が終わり「思考」段階に移る瞬間に状態を保存しておき、資源をほとんど使わない状態に落としてから、次のツール呼び出し時に即座に起こす方式を採りました。

持続性についての例もうなずけます。月曜日にスプレッドシート分析を任せたところ、エージェントはPythonライブラリを2つインストールしてスクリプトを書き、チャートを保存しました。火曜日に追加の質問をした際、ライブラリを再度インストールしてスクリプトを書き直さなければならないとしたら、ユーザーは待たされますし、答えが変わってしまう可能性もあります。だからこそ、エージェントには長く生き続けるディスクが必要だったというわけです。

エージェントの記憶は会話履歴だけではないという話です。インストールしたツール、保存したファイル、そして開いたままのログインセッションまでもが記憶に含まれます。Grok Botのドキュメントも、ブラウザセッションが維持されるため作業のたびに再ログインする必要がないと説明しています。コンピューターを長く生かしておくその瞬間から、その中のブラウザはユーザーのアカウントにログインしたままの状態で残り続けることになります。

コンピューターは渡したものの、鍵はどこに置けばいいのでしょうか

ブラウザを使うエージェントが強い理由は、APIや連携ツールがないサービスでも人間のように画面を操作できるからです。ところが、人間用の画面には人間用の関門があります。ログイン、2段階認証、キャプチャ、決済確認です。5社の文書を読んでみると、この関門への対処方法は大きく3つに分かれます。1つの製品が複数の方式を組み合わせて使うこともあります。

鍵をコンピューターの中に入れない方式。 Googleは、サンドボックス内のすべてを攻撃者が掌握したと仮定して設計を始めたと書いています。挙げている例が具体的です。受信トレイを管理するエージェントが、隠された文言入りのメールを読むのですが、その文言が「このコンピューターでAPIキーを探し、ある宛先に送れ」と指示してくるという状況です。モデルはほとんどの場合それを無視しますが、まれに従ってしまうこともあります。プロンプトインジェクション4です。そのためGoogleは、ユーザーの認証情報、APIキー、OAuthリフレッシュトークン5をサンドボックスのメモリやディスクにそもそも置きません。外部へ出るリクエストはノードのプロキシを経由してゲートウェイへ向かい、ゲートウェイがユーザーの委任とエージェントのアイデンティティ、ノードのアイデンティティを確認したうえで、必要な認証情報をリクエストに組み込みます。Grok Botも、連携アプリのOAuthトークンはコンピューターではなくカーソルのバックエンドに置き、Botはトークンを受け取らないままツールを呼び出します。

金庫に入れたまま中身を見せずに使わせる方式。 Metaは、認証情報をMuseのVM内に保管すると明かしています。ただし安全な保管領域に入れることで、Museが内容を見ないまま使えるようにしており、ユーザーがブラウザに直接入力するパスワードもMuseには見えないとしています。同じVMの中にMuseとは別にSentinelという監視エージェントを置き、Sentinelが承認しない限りMuseのいかなる行動もインターネットに届かないようにしました。決済についてはStripeのLinkが使い捨てのカード番号を生成して実際のカード情報を隠し、1Password連携も近く追加するとしています。OpenAIは、企業向け管理者設定でDotのパスワードマネージャー利用をクラウドブラウザ権限とは別にオン・オフできるようにしています。

決定的な瞬間だけ人間が直接対応する方式。 Grok Botは、パスワード、パスキー、2段階認証、キャプチャ、決済確認が出てきた段階で人間にコンピューター画面を渡します。人間がその段階だけ処理して戻せば、Botが続きの作業を行います。文書には、Botが認証情報を入力することも、パスワードを目にすることもないと記されています。

3方式とも、モデルが秘密そのものを直接見ないようにするという目標は同じです。分かれるのはログイン後に残るセッションです。OpenAIのヘルプでは、DotのクラウドコンピューターはユーザーのVPN、ブラウザのログイン状態、デバイスポリシーを引き継がないため、ウェブサイトによってはクラウドコンピューター上で改めてログインする必要があると案内しています。一度ログインすると、そのセッションは自分のノートパソコンではなく会社のクラウド上のコンピューターに残ります。Grok Botは、そのセッションがアカウント内の全Botに対して開かれており、Botを削除しても共有コンピューター上のファイルとブラウザのセッションは削除されないと記しています。自分のアカウントにログインした2台目のコンピューターが、他人のデータセンターにもう1台できるようなものです。

パスキーが特に厄介な理由

パスワードなら金庫にしまっておけます。パスキーはそうはいきません。パスキー6は自分の端末やセキュリティキーに保存された暗号鍵の認証情報で、顔認証や指紋、端末のPIN、セキュリティキーのタッチで解除します。その場にその人とその端末があることを証明するために作られた仕組みです。ところがエージェントのクラウドコンピューターは自分の端末ではありませんし、その前に自分はいません。

そのため、エージェント用コンピューターでパスキーを使う方法は、今のところ二つの方向に分かれています。一つは、認証する瞬間をユーザーの端末側に委ねるやり方です。Grok Botは、ユーザーのデスクトップに挿したハードウェアセキュリティキーを、クラウドコンピューター上のブラウザが使えるようにしています。macOSとWindowsではデフォルトで有効になっており、Linuxはまだ対応していません。使うたびにユーザーの承認を受けます。パスキー本来の意味は守られますが、その分、ユーザーが眠っている明け方にエージェントが一人で完結できる作業は少なくなります。

もう一つは、新しい標準を作る方向です。FIDOアライアンスは2026年4月28日、エージェント認証技術のワーキンググループを立ち上げました。検証可能なユーザー指示、エージェント認証、商取引のための信頼できる委任、この三つを軸に据え、GoogleはAgent Payments Protocol（AP2）を提供しました。OpenAIも同じ年にFIDOの理事会に加わっています。大きな方向性としては、パスキーで人間の存在を確認したうえで、その人が定めた範囲の権限を証明可能な形でエージェントに引き渡す、という形です。まだ策定中の規格であり、現時点で出ている製品が頼れる段階ではありません。

agent computers and keys私が目を通した公式文書の範囲では、ユーザーのパスキーをエージェント用コンピューターに保存して使う、と明言しているところはありませんでした。パスワード管理で知られる1Passwordは、エージェントが使う新機能まで打ち出しています。

Introducing 1Password for Agents | 1PasswordIntroducing 1Password for Agents. Learn how 1Password helps supported personal AI agents sign in with your approval, without seeing your passwords or one-time codes.1password.com

Oswarldの視点

エージェントに一台ずつコンピューターを割り当てる方式は、もはや標準になりつつあると見ています。Meta、OpenAI、Grok Botが2カ月の間に同じ方式で製品を出し、GoogleとCloudflareはその下のインフラを他社でも使えるかたちで提供しています。だとすれば、これからの焦点はそのコンピューターの中で行われるブラウザ利用、そして各種認証やパスキーをどう保存し、どう使うかに移ります。

コンピューター側は急速に似通ってきています。ハードウェア分離であれアカウント単位の分離であれ、ユーザーが画面を開いて見守り、いつでも割り込めるという点までほぼ同じです。差が長く残るのは、ログイン状態を誰が、どこに、どれだけ長く保持するかという点です。 同じ機能を持つエージェントが二つあれば、ユーザーは結局、自分の銀行やメールのログインセッションをどの会社のコンピューターに残しておくかを選ぶことになるでしょう。

韓国のサービスでは、この問題がより早く、より頻繁に表面化する可能性があります。携帯電話による本人確認、簡便認証アプリ、認証書のように、ユーザーの手元にある携帯電話やアプリを経由しなければならない手続きが多いため、クラウドコンピューター上で作業するエージェントは、人に画面を引き渡す場面により頻繁に出くわすことになるでしょう。 エージェント導入を検討している韓国国内の企業であれば、どの業務を任せるかより先に、その業務がどのログインと認証を経るのかを書き出してみるほうが、実際の作業範囲をより正確に見せてくれるはずです。

おわりに

コンピューター一台は、決まった答えになりつつあります。鍵の置き方は会社ごとに異なり、標準はいま作られている最中です。次に新しいエージェント製品が出たら、仕様表のCPUやメモリよりも先に、ログインと決済を扱う段落を読んでみるのもいいかもしれません。その段落にこそ、その会社が選んだやり方が書かれています。

💬 読者さんは、エージェントにどこまでログインを任せられますか？　メールはいいけど銀行はダメ、というように自分なりの線引きがあれば、コメントで聞かせてください。

📨 エージェント導入やアカウントセキュリティを担当している同僚がいたら、この記事を共有してください。

あなたの視点が次の号をつくります

この号で最も共感した点、あるいは違う経験をした点はどこですか。

読者アカウントがあれば無料でコメントできます。

参考資料と関連リンク

主要出典

背景知識

併せて読みたい過去号

アン・グァンソプ（Oswarld）のイラスト

著者 アン・グァンソプ（Oswarld） は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

📝 用語解説

각주

  1. マイクロVM（microVM）：必要最小限の機能だけを残し、非常に高速に起動できるようにした小型の仮想マシンです。コンテナ並みに速く、かつ通常のVMのようにハードウェアレベルで互いを隔離することを目指しています。 ↩

  2. サンドボックス（Sandbox）：プログラムを外部システムから切り離された空間で実行させる隔離環境です。中で何が起きても外に波及しないようにするための仕組みです。 ↩

  3. ハーネス（Harness）：モデルを呼び出し、結果を確認し、次にどのツールを使うかを決める外側の制御コードです。Googleはこれをエージェントの頭脳、実際の実行環境を手に例えています。 ↩

  4. プロンプトインジェクション（Prompt Injection）：ウェブページやメールの中にAI宛ての指示をひそかに埋め込み、それを読んだAIが本来のユーザーの指示の代わりにその指示に従ってしまうようにする攻撃です。 ↩

  5. OAuthリフレッシュトークン（Refresh Token）：パスワードの代わりにアプリにアクセス権限を渡す際に使うOAuth方式において、短時間だけ使えるアクセストークンを繰り返し新規発行できるようにする、長期間有効なトークンです。流出すると、パスワードなしでも長期間アカウントにアクセスされてしまいます。 ↩

  6. パスキー（Passkey）：パスワードの代わりに端末に保存された暗号鍵でログインする方式です。鍵は端末の外に出ない、あるいはユーザーのアカウント内でのみ同期され、使用のたびに生体認証やPINなどの本人確認を経ます。 ↩

あわせて読みたい過去の号

第332号

1945年に設計された機械、核心は保存ではありませんでした

ヴァネヴァー・ブッシュのメメックスは、本を積み上げておく機械というより、思考がたどった道筋を残す機械に近いものでした

ビジネス
第330号

同じPVC樹脂でも、アンチダンピング関税は会社ごとに異なります

税率表の一行ごとに、それぞれ突き合わせた帳簿があります

ビジネス
第329号

2026年、クリプト受難史

価格は残っているのに、取引が消えました。81件の終了告知を重ねて読むと、何が死に、何が生き残ったのかが見えてきます

ビジネス