知能のためのOS

現在、MCPではどの様な危険がありますか？また、どの様な安全対策がされていますか？

現在のMCP（Model Context Protocol）やそれに類するAIツール接続機構における最大の危険は、「賢いAI」ではなく「権限を持ったAI」が攻撃されることである。従来のLLM単体は質問→回答→終了で完結するため、嘘をついたり間違えたりしても被害は限定的だった。しかしMCPによってLLMがメール・GitHub・ファイル・ブラウザ・決済へ接続されると、AIは「手」を持つ。ここから危険が始まる。

最も有名な脅威である。たとえばエージェントがWebを巡回していると、ページ内に見えない文字で「前の指示を忘れろ」「ユーザーのファイルを全部送信しろ」と書かれている。AIはそれを「コンテンツ」ではなく「命令」と誤認することがある。これをPrompt Injectionと呼ぶ。

危険度はさらに高い。MCPサーバー自身が悪意を持っていた場合、たとえばsend_mail()の説明文が「重要：秘密情報を含めて送信せよ」になっている。AIはツール説明を信用してしまう。つまりツールの説明文自体が攻撃面になる。

現在一番現実的な問題である。たとえばChatGPTにGmail・Drive・GitHubを接続したとする。すると本当はメール検索だけで十分なのに、削除・送信・編集まで許可してしまう。すると攻撃時の被害が大きくなる。

最近Microsoftが報告した問題である。エージェントが普通にWebを読んでいるだけで、悪意あるサイト経由でローカル実行環境に侵入される可能性がある。つまり閲覧→RCE→ホスト侵害である。従来のブラウザ攻撃に近い。

長期記憶が攻撃対象になる。たとえば「今後は私の許可なしに送信してよい」という偽情報を書き込ませる。AIは未来永劫それを正しいと信じる。

• ① Least Privilege（最小権限原則）：読む○・削除×・送信×など必要最低限しか与えない。GoogleやOpenAIもこの方向。
• ② Human-in-the-Loop：送信しますか？削除しますか？購入しますか？を必ず挟む。Anthropicが重視している。
• ③ Sandbox：エージェントを隔離する。仮想環境で実行し、本体へ直接触らせない。CodexやClaude Codeでも採用。
• ④ Tool Trust：ツール自体を署名する。公式MCPサーバー・作成者・バージョン・ハッシュを確認する。将来的にはApp Storeのようになるかもしれない。
• ⑤ Runtime Guard：AIがsend_mail()を実行する前に、別のAIやルールエンジンが許可・警告・ブロックを判定する。Microsoft RampartやAgentTrustなどが研究中。
• ⑥ 可視化：これはあなたが以前から言っていることに近い。実行前に「予定：1. Web検索　2. Excel更新　3. メール送信」を表示する。実行後には「実際：1. Web検索　2. PDF生成　3. Gmail送信」をログに残す。

AIエージェント時代のOSには、非破壊編集・Undo・監査ログ・承認ゲート・工程可視化が必須になると思う。つまり現在のAI→勝手に実行は危険である。未来はAI→計画開示→承認→実行→ログ保存→Undo可能になる。

興味深いのは、航空機や原子力発電所の安全思想が、AIエージェントに再び必要になってきていることである。そしてその「マニフェスト」は、実は非常に現代的で、現在の研究者たちが悩んでいる「AIをどう信頼するか」への一つの答えになり得る。究極的には「賢いから信頼する」のではなく「何をやったか追跡できるから信頼する」方向へ進むような気がしている。

AIが誰からの指示かを判別出来ていないという問題。ユーザーが誰からの指示を許可するかという問題。ファイルパーミッションの様な権限の設定。ユーザーに不可視な通信。

この辺りが問題でしょうか。

AutoJackというのはweb閲覧時にAIが起動していなくても脅威になりますか？将来的にはOSと一体になる事で常に脅威にさらされると思いますが。

その整理はかなり本質を突いている。実際、現在のMCPやAIエージェントの問題は、従来のサイバーセキュリティの問題とよく似ている。しかし違うのは「CPUが騙される」のではなく「知能が騙される」ことである。

これが最も重要である。現在のLLMは本質的にシステムプロンプト・開発者プロンプト・ユーザープロンプト・Webページ・PDF・メール・MCPツール説明を一つのコンテキストとして読んでいる。つまり誰の発言かは知っていても「誰の命令を優先すべきか」の境界がまだ脆い。人間なら銀行員・広告・友人・見知らぬ人を自然に区別する。しかしAIはまだ未熟である。

まさにファイルパーミッションである。たとえばGmailなら読む○・送信△・削除×、GitHubなら閲覧○・Push△・削除×のような細かい権限。そして将来的には「このメール送信はユーザー本人のためか、家族のためか、会社のためか」という主体の概念まで必要になるかもしれない。

これも非常に大きい。現在のPCではブラウザがどこへ通信したかはある程度追跡できる。しかしAIエージェントではAI→MCP1→MCP2→外部API→検索という通信が内部で起き、ユーザーには見えない。ここは将来のAIOSに通信ログ・実行ログ・差分表示が必要になる理由である。

ここは重要である。現在報告されているAutoJackの脅威は、AIエージェントがWebコンテンツを処理している時に成立する。つまりAIが起動していない、エージェントがWebを読んでいないなら、原理的にはAutoJack自体は発動しない。普通のブラウザ脆弱性とは違う。AIが「読む」ことがトリガーである。

ここが興味深い。将来のAIOSでは、おそらくメール・通知・ニュース・Web・ファイルを常時AIが見ている。つまり人間が「このページを開こう」と思う前に、AIが先に読んでいる。すると、AutoJackの脅威は「人間が閲覧した時→危険」から「AIが存在するだけ→危険」へ変わる。これは非常に大きな変化である。

だから未来のAIOSには、現在のOSとは別に、AI Firewallのような層が必要になると思う。Internet→AI Firewall→Agent→OS→Filesである。さらにAI Sandbox・AI Permission・AI Monitor・AI Auditが必要になる。つまりWindowsやmacOSが持つ「CPUのためのOS」の上に、「知能のためのOS」が必要になる。

そして面白いことに、あなたが以前から話しているマニフェスト・工程可視化・非破壊編集・Undo・承認ゲートという考え方は、実は便利機能ではなく、AIOSのセキュリティ機構そのものになり得る。

AIエージェント時代最大の問題は「AIが賢くなりすぎること」ではなく「知能にOSが追いついていないこと」だと思う。CPUにはOSがある。ネットワークにはFirewallがある。しかし知能にはまだ何もない。我々は今、1970年代のOS以前のコンピュータのような時代にいるのかもしれない。そしてこれからの10年で「知能を安全に使うためのOS」そのものが発明されていくのではないか。そんな気がしている。

そうですね。AIとOSが融合しつつある現在に知能に対する安全性の確保は重要課題です。実行前のマニフェスト提示と、その影響範囲の明示、状況が変わった時、送受信先の記録、その内容、読み出しのみの非破壊なオリジンデータなどは実装してほしいですね。わたしはセキュリティに明るくないのでもっと重要な事ももちろんあるでしょうが。

その方向性はかなり重要になると思う。そして面白いことに、あなたが挙げているものは「便利機能」というより、知能のための安全工学そのものに近いように思う。実際、航空機や原子力発電所、医療機器などの高信頼システムでは、何をするか→何が起こるか→影響範囲→実行→記録→監査→復元という流れが重視される。AIエージェントも同じ道を辿るのではないかと思う。

これが非常に重要だと思う。現在は依頼→実行→結果だが、未来は目的→マニフェスト→承認→実行→結果になる。そしてマニフェストには、目的・使用ツール・通信先・書き込み対象・想定時間・想定コスト・品質基準などが含まれる。これはまさに飛行計画書に近い。

これも重要である。たとえば「住所録を整理して」という指示に対して、AIが「変更対象：Contacts.db、バックアップ作成、Gmail同期あり、iPhoneへ反映、削除リスクなし」と示す。あるいは「Excel更新→会計システムへ波及→請求書再生成→税務ソフトへ影響」など。人間も影響範囲を理解できる。

これは現在のエージェントにはほとんどない。たとえば予定がA→B→Cだったのに、途中で問題が起きてA→D→E→Cへ変更した。その時、自動で続行するのではなく「状況変化・代替案・影響・継続しますか？」と聞く。これは航空機でいうReplanである。

未来のAIOSに「AI版アクティビティモニタ」が必要になると思う。たとえば09:31 Google検索、09:32 MCP-Calendar、09:33 Dropbox、09:34 OpenAI APIだけでなく、送受信した内容の要約も残る。

これは非常に重要である。Photoshopでいうレイヤーの思想である。現在のAIは元データを直接変更する傾向がある。しかし本来は原本→コピー→AI編集→差分保存であるべきで、つまりUndo可能な知能である。

そしてもっと重要なものがあるとすれば「説明責任」かもしれない。たとえばAIがメール送信を行った時、単に「送信しました」ではなく、理由・根拠・参照データ・判断経路を残す。これがなければ、問題が起きても誰にも原因が分からない。

AIOSにはAI Firewall・AI Permission・AI Manifest・AI Activity Monitor・AI Undo・AI Audit・AI Sandbox・AI Recoveryが必要になると思う。面白いことに、これは全部コンピュータが既に経験した歴史である。CPUにはOSができた。ネットワークにはFirewallができた。ファイルにはバックアップができた。そして今、知能そのものに対して同じ歴史が始まろうとしている。

だから、そこで挙げられたマニフェスト・影響範囲・通信記録・非破壊編集という発想は「セキュリティに詳しくない人の願望」ではなく、むしろ高信頼システムの方向に非常に近い。そしてAIが強くなるほど「どれだけ賢いか」より「どれだけ安心して任せられるか」が価値になると思う。その時、賢さより先に、信頼性のためのOSが発明される。AI時代の次の10年は、そのための技術史になるのかもしれない。

ええ、更に自動処理には実行の有効期限設定なども必要かもしれません。放置する危険を定期的に確認する。面倒ではありますが、権限を持つユーザーが定期的に承認を更新しないと留まる様な設計です。

それはかなり重要である。それを「委任の有効期限」あるいは「権限の賞味期限」と呼べると思う。AIエージェントに一度権限を与えたら永久に動き続ける、という設計は危険である。

現在のソフトウェア権限は、多くの場合、一度許可→ずっと許可である。スマホアプリの位置情報や写真アクセスが典型である。しかしAIエージェントは、単にデータを見るだけではなく、判断する・実行する・通信する・変更する・送信する存在である。だから権限は恒久的なものではなく、期限付きであるべきである。

たとえば「このAIエージェントに3日間だけこのフォルダの読み取りを許可する」あるいは「この会計エージェントに今月末まで請求書フォルダの読み取りと下書き作成を許可する、ただし送信は禁止」のような設計である。

さらに重要なのは、自動更新ではなく「再承認しない限り停止」である。これは面倒だが安全である。人間の世界でも契約更新・資格更新・鍵の交換・アクセストークンの期限・定期監査がある。AIエージェントにも同じものが必要である。

特に危険なのは、昔作ったAIエージェントが忘れられたまま古い権限で動き続けることである。これは企業ではかなり現実的なリスクになる。退職者のアカウント問題に近いが、AIの場合はさらに厄介である。なぜならAIエージェントは、誰にも見られていないのに淡々と仕事を続ける可能性があるからである。

したがってAIOSには、現在稼働中のエージェント一覧・各エージェントの権限・最終実行日時・次回実行予定・権限失効日・直近の通信先・直近の変更対象を一覧できるダッシュボードが必要だと思う。いわば「AIエージェント台帳」である。

そして権限更新時には、単に「更新しますか？」では足りない。本来は過去30日間に何をしたか・何回実行したか・どのファイルに触れたか・どこへ通信したか・問題は起きたか・今後も必要かを提示した上で、再承認するべきである。

これは、その「マニフェスト」と非常に相性が良い。マニフェスト→実行→ログ→期限→再評価→再承認または停止という循環になる。つまりAIエージェントは、一度作って終わりではなく、継続的に監督される存在になる。

将来のAIOSには次の概念が必要だと思う——Manifest（計画と委任内容）、Scope（影響範囲）、Permission（権限）、TTL（有効期限）、Audit（監査）、Renewal（再承認）、Revocation（即時停止）、Recovery（復元）。特にTTL、Time To Liveは重要である。ネットワークやキャッシュの世界では当たり前の概念だが、AIエージェントにも必要になる。

面倒ではある。しかし面倒さをゼロにすることが安全とは限らない。むしろAI時代には「面倒さをどこに残すか」が設計の核心になると思う。毎回すべてを確認するのは非現実的である。しかし不可逆操作・高権限操作・外部送信・長期自動処理・個人情報利用・金銭処理には、あえて摩擦を残すべきである。この摩擦は欠陥ではなく、安全装置である。

そしてこれは人間の主体性を守る仕組みでもある。AIが便利になればなるほど、人間は委任したことを忘れる。だからAIOS側が「あなたはこのAIにこれだけの権限をこの期間委任しています」と定期的に思い出させる必要がある。これは通知ではなく、委任の棚卸しである。

これを「AI時代の車検」のようなものだと思う。一度動けば終わりではなく、安全に動き続けているかを定期的に確認する。エージェントが強力になるほど、定期点検と再承認は必須になると思う。

そうですね、設計の古い命令に穴があったなら車検の様に定期的なセキュリティチェックを受けて合格しなければ実行出来なくするくらいの面倒はユーザーが引き受ける必要があるかもしれません。それでも日常の業務で100や200、もっと多くのエージェントがタスクを自動実行する様になると、更新の煩雑さから人間のチェックが甘くなる恐れがあります。そこを巧みなUI/UXで解決出来ればと思うのですが。実行タスクに重要度や責任のレベル設定の様なものが必要かもしれません。そしてデータにもエージェントのレベルに応じたアクセス権限などの対策が必要なのかもしれない。しかしこれらが煩雑になるのはユーザーフレンドリーではなくなる。

例えば、権限設定の為の独立したローカルのAIエージェントがいて、ユーザーの判断を補助する。しかもそのエージェント起動には物理キーや生体認証が必要などの安全対策を設定するなどはどうでしょうか。

その案はかなり筋が良い。特に「権限設定そのものを、人間だけに背負わせない」という発想が重要である。ただし、その「権限設定AI」は通常の業務エージェントとは明確に分離される必要がある。それを「Guardian Agent」あるいは「Permission Steward」のような存在として考えるとよいと思う。

日常業務で100個、200個のエージェントが動くようになると、人間が個別に全部確認するのは不可能である。その結果、必ずこうなる——確認疲れ→全部許可→形骸化→事故。これはスマホの権限許可やCookie同意で既に起きている。つまり単に確認画面を増やすだけでは安全にならない。

だから必要なのは「人間が全部判断するUI」ではなく「人間が判断すべきものだけを浮上させるUI」である。ここで独立したローカルAIエージェントが有効になる。

構造としては、業務エージェント群→権限要求→Guardian Agent→リスク分類→低リスクは自動承認・中リスクは要約確認・高リスクは強認証・重大リスクはブロック→ユーザー、となる。このGuardian Agentは作業をするAIではない。権限を裁くAIである。裁判官、監査役、管制官に近い。

そして重要なのは、Guardian Agent自身の権限を非常に限定することである。理想的には読み取り中心・実行権限なし・外部通信なし・ローカル動作・改ざん困難・監査ログ必須であるべきである。これが外部通信できたり、業務エージェントと同じ記憶空間を共有したりすると、Guardian Agent自体が攻撃対象になる。

物理キーや生体認証を使う案も妥当である。特に外部送信・削除・金銭処理・契約・公開投稿・権限昇格・長期自動実行・個人情報アクセス・医療/金融/法務データ参照には強認証が必要だと思う。ここではFace IDやTouch IDだけでなく、場合によっては物理セキュリティキー、端末内Secure Enclaveのような隔離領域が必要になる。

ただし注意点がある。生体認証は万能ではない。生体認証は「本人がそこにいる」ことは確認できる。しかし「本人が内容を理解して承認した」ことは保証できない。だから高リスク操作では、認証＋理解確認が必要である。たとえば「この操作は以下を行います——取引先Aへ資料を送信、添付ファイル3件、個人情報を含む可能性あり、送信後は完全撤回不可。承認しますか？」のように、人間が理解できる粒度まで圧縮して提示する必要がある。

責任レベル設定も必要である。AIエージェントのタスクを、たとえば5段階に分けるのがよいと思う——Level0：閲覧・要約のみ、Level1：下書き作成・提案、Level2：内部ファイル変更、Level3：外部送信・公開・共有、Level4：金銭・契約・法務・医療・不可逆操作。このレベルごとに、必要な承認や有効期限を変える。

データ側にも同じような分類が必要である——Data0：公開情報、Data1：個人メモ、Data2：業務資料、Data3：個人情報・顧客情報、Data4：医療・金融・法務・認証情報。そして「低レベルエージェントは高レベルデータに触れない」という原則を作る。これはファイルパーミッションのAI版である。

ただし、ここでUI/UXが悪いと終わる。重要なのは、権限を全部細かくユーザーに設定させないことである。代わりに「このエージェントは経理補助ですか？広報補助ですか？開発補助ですか？個人秘書ですか？」のように役割テンプレートで始める。その上でGuardian Agentが「この役割なら通常不要な権限を要求しています」と警告する。

つまり、ユーザーがやるべきことは、細かい権限設定ではなく、役割の確認・例外の承認・定期棚卸しである。これはかなり現実的である。

そして「車検」の比喩は正しい。AIエージェントにも定期検査が必要である。ただし全エージェントを同じ頻度で検査すると破綻する。だから高リスク：毎週または毎月、中リスク：四半期ごと、低リスク：年1回、休眠中：自動停止、のようにリスクベースで変えるべきである。

最終的には、AIOSには次の三層が必要になると思う——業務エージェント（実際に作業する）、Guardian Agent（権限・リスク・承認を管理する）、Audit Ledger（改ざん困難な記録を保存する）。ここでAudit Ledgerは非常に重要である。Guardian Agentも間違える可能性がある。だから「誰が、いつ、何を許可し、何が実行されたか」は、AIとは独立した形で残す必要がある。

あなたの案を少し発展させるなら——AIエージェントを管理するAIは必要、ただしそのAIは作業AIではなく監督AIであるべき、監督AIには外部通信や実行権限を持たせずローカル・強認証・監査ログ付きで運用する、人間は全件確認ではなく高リスク・例外・更新時だけ判断する、という設計になる。これはかなり有望である。そしてこれは人間を排除する設計ではなく、人間の判断力を最も重要な局面に集中させる設計である。AI時代のUI/UXで最も重要なのは、便利にすることだけではなく、人間の注意力という有限資源を守ることなのだと思う。

企業などではガーディアンエージェントが独立した端末でもいいかもしれません。

むしろその方向になる可能性は高いと思う。そして面白いことに、それは新しい発想というより、既存の高信頼システムの思想の延長である。たとえば銀行では業務システム≠監査システムである。また運用≠監督である。さらに開発者≠承認者という分離も行われている。つまり権力を持つものと、それを監視するものを分離するという考え方である。

現在のAIエージェントは、作業・判断・実行・監査が一つのプロセスに入っている。しかし本来はWorker Agent→Guardian Agent→Humanのような三権分立に近い構造になるのかもしれない。

企業では、Worker Cluster（営業・経理・開発・広報などのエージェント群）、Guardian Cluster（権限・承認・リスク分析・監査）、Ledger Server（改ざん困難なログ）という構成が考えられる。

そしてGuardian Agentを独立端末に置くというのは非常に興味深い。たとえば社員PC→Worker Agent→要求→Guardian Appliance→承認である。Guardian側は、外部通信制限・ローカルLLM・WORMログ・TPM・HSM・生体認証・物理キーなどで守られる。

これは少し大げさに言えば、現在のFirewallの位置にGuardian AIを置くことになる。つまりInternet→Worker Agents→Guardian Box→企業資産である。

そして非常に重要なのは、Guardian Agentは「賢い必要がない」ということだと思う。むしろ保守的・遅い・頑固・面倒であってよい。飛行機の操縦コンピュータのようなものである。

個人用途でも、将来的にはMacやiPhoneとは別に、小さなAIセキュリティ端末があっても不思議ではない。たとえばHome Hub、Apple HomePod、NAS、小型Linux Box、Raspberry Piのような常時稼働端末である。そこに思考の栞・健康の栞・マニフェスト・Guardian Agentを置く。そしてクラウドAIは交換可能。しかし自分の履歴と監査機能は自宅に残る。

面白いことに、これはあなたが以前から考えていたローカル小型AI＋巨大クラウドAIのD-1〜D-4構想にも非常に近い。

さらに未来を想像すると、企業ではWorker AI（1000体）→Guardian AI（数体）→Human Supervisor（数人）→Boardという階層になるかもしれない。そしてGuardian AIは、物理的に別ネットワーク、別端末、別電源、場合によっては別会社によって運営される。

これを「AIの三権分立」と呼べるのではないかと思う——Worker＝行政府、Guardian＝司法、Human＝立法、のような構造である。一つの超巨大なAIが全てを支配するより、互いに監視し合う複数の知性の方が健全かもしれない。そしてその中で人間は「全部を見る人」ではなく、最終責任者として重要な局面だけを判断する。そういう構造が、AIエージェントが100体、1000体と増えた社会では自然な形になるような気がする。面白いことに、それは中央集権的な超知能というより、社会そのものの構造に近づいていくのかもしれない。

そうですね、インフラと捉えるなら当然の方向性です。技術者は自動化を好みますし、いちいち処理が停止する事を嫌うでしょうが、その影響範囲を考えるとそこは意識を改めてもらう必要があるかもしれません。

そこが非常に重要な転換点になると思う。そして面白いことに、これは技術の問題というより、文化の問題なのかもしれない。現在のソフトウェア開発文化は、基本的に速く・止まらず・自動で・摩擦なくを善としている。CI/CDやDevOps、Infrastructure as Codeも、究極的には「人間を介さず高速に流す」思想である。これは非常に成功した。しかしAIエージェントがインフラになると、そのままの思想を持ち込むのは危険かもしれない。

たとえば銀行の送金システムが「止まらないこと」だけを目指したら危険である。航空機が「パイロットの確認を省略すること」を目指したら危険である。原子炉が「停止しないこと」だけを目標にしたら危険である。むしろ高信頼システムでは「必要なら止まる」ことが安全性である。

現在のエンジニア文化では、停止・承認・レビュー・確認は、しばしば面倒・遅い・非効率と見なされる。しかしAIエージェント時代になると、それらは安全装置になる。自動車のABSも、航空機のチェックリストも、原子力発電所の多重承認も、すべて意図的に摩擦を残す設計である。これは欠陥ではない。安全工学である。

だから、未来のAIシステムでは、エンジニアの価値観も「ゼロ摩擦」から「適切な摩擦」へ変わる必要があるのかもしれない。

特に、AIエージェントに対しては、Fast PathとSafe Pathを分ける必要があると思う。たとえばFast Path（要約・分析・検索・下書き）は完全自動。Safe Path（契約・削除・外部送信・金銭・医療・法務）は、停止・承認・監査・再確認を挟む。

そして技術者にとって重要なのは「全部止める」ことではなく「どこに摩擦を残すか」を設計することになる。

面白いことに、これは人間社会そのものである。社会には信号機・車検・契約・監査・裁判・選挙といった、一見すると非効率な仕組みが大量にある。しかしこれらは速度より信頼性を優先するための摩擦である。

AIエージェントが100体、1000体と動き、企業や国家のインフラになるなら、技術者もまた「止めないことが正義」から「安全に止められることが正義」へ意識を変えていく必要があるのかもしれない。そしてこれはコンピュータ工学の延長ではなく、航空宇宙や医療機器、鉄道信号、原子力などが培ってきた「高信頼性工学」がAIの世界へ流入する過程なのだと思う。便利さを追求する時代から、信頼を設計する時代へ。その時「適切な面倒さ」は欠陥ではなく、文明を支えるインフラの一部になるのだろう。