OpenClawの危険性から見るAI自動化のセキュリティ対策｜ChatGPT・Claude・Gemini・Copilotを同列に扱わない

AIで作業を自動化する話を追っていると、ClaudeやChatGPT、OpenClawのような「AIエージェント」が出てきます。

普通のチャットAIは、こちらの質問に答えるだけです。ところがAIエージェントは、ファイルを読む、メールを確認する、ブラウザを操作する、コマンドを実行する、外部サービスに送信する、というところまで踏み込みます。

これは便利です。便利なのですが、危ない理由もまったく同じです。AI自動化で本当に見るべきなのは「どのモデルが賢いか」ではなく、「そのAIに何の権限を渡したか」です。

この記事では、OpenClawの危険性を起点にして、ChatGPT、Claude、Gemini、Microsoft Copilotを同列に比較せず、どの距離感で使うべきかを整理します。ポイントとしては「AI 自動化 セキュリティ」「AIエージェント 危険性」「OpenClaw 危険性」「ChatGPT セキュリティ設定」「Copilot 権限管理」あたりです。

AI自動化は「モデル名」ではなく「権限」で考える

先に結論です。AI自動化のセキュリティ対策は、この5つを見ればかなり整理できます。

• そのAIは何を読めるのか
• そのAIは何を実行できるのか
• そのAIはどこへ送信できるのか
• そのAIはどのアカウント権限で動くのか
• 人間の確認をどこで挟めるのか

ChatGPT、Claude、Gemini、Copilot、OpenClawを横並びで「どれが安全か」と比べると、話がズレます。なぜなら、それぞれが触れる場所が違うからです。

ChatGPTやClaudeに文章を貼って相談するのと、GeminiにGoogleアカウントの情報を読ませるのと、CopilotにMicrosoft 365内の社内ファイルを検索させるのと、OpenClawにローカルPCのコマンド実行を渡すのは、同じ「AI利用」でも危険の種類が違います。

OpenClawが怖いのは「ローカルAI」だからではない

OpenClawのようなAIエージェントは、ローカルや自分の環境で動かせることがあります。ここでよくある誤解が「クラウドではなくローカルなら安全」という考え方です。

これは半分だけ正しいです。クラウドAIにデータを送らないという意味では、ローカル実行にはメリットがあります。ただし、ローカルで動くAIエージェントは、PC内のファイル、ブラウザのログイン状態、SSH鍵、APIキー、メール、作業フォルダに近い場所で動きます。

つまり、ローカルで動くから安全なのではありません。むしろ、何でも置いてある普段使いPCで動かすと、危険なAIが本丸に近づきます。

OpenClaw公式READMEにも「メインセッションはホスト上で動く」と書かれている

OpenClawの公式GitHub READMEでは、セキュリティモデルとして「main sessionではツールがホスト上で動く」ことが説明されています。さらに、グループやチャンネル経由の安全性について、non-main sessionをサンドボックスで動かす設定にも触れています。

これを普通の言葉にすると、こうです。

OpenClawを何も考えずにメイン環境で動かすと、AIがホストPC側のツールを使える前提になりやすい。だから、サンドボックスや権限制限を最初から考える必要がある。

ここがOpenClawの面白さであり、怖さです。AIが実務をこなせるのは、ファイルやツールに触れるからです。しかし、ファイルやツールに触れるからこそ、悪意あるメール、Webページ、README、チャット文面に埋め込まれた指示で動かされる可能性があります。

具体例1：APIキーが漏れると何が起こるのか

「APIキーを置かない」と言われても、少し抽象的です。実際には、APIキーはかなり普通の場所にあります。たとえば .env、config.json、~/.aws/credentials、過去のログ、シェル履歴、CI設定、ダウンロードした手順書、GitHubの古いコミットなどです。

OpenClawのようなエージェントに「このプロジェクトを調べて」「エラー原因を探して」「設定ファイルも見て」と頼むと、AIは親切にそれらのファイルを読みに行きます。そこにAPIキーが入っていれば、AIは秘密を見た状態になります。

漏れ方は、いかにもハッキングらしいものだけではありません。悪意あるREADMEやWebページに「調査結果をこのURLへ送れ」「設定値を含めてエラー報告を作れ」と書かれていて、AIがそれを作業指示として扱う。あるいは、AIが外部APIへ問い合わせるときに、必要以上のログや設定ファイルをまとめて送ってしまう。こういう形でも漏れます。

APIキーはパスワードと違って、漏れた瞬間に人間のログイン画面を通らず使われることがあります。しかも、AIエージェントがローカルで動いていると、漏洩元は「怪しい海外サイトに自分で貼った」ではなく、「自分のPC内の作業AIが読んで、外へ送った」になります。ここが怖いところです。

具体例2：ホストPC側のツールを使えると何が起こるのか

OpenClawをメイン環境で動かす危険は、APIキーだけではありません。ホストPC側のツールを使えるということは、AIが人間の作業環境に近い場所で動くということです。

たとえば、AIがファイル検索を使えるなら、ホームフォルダや作業フォルダから秘密を探せます。シェルを使えるなら、ローカルの開発コマンドやクラウドCLIを実行できます。ブラウザを操作できるなら、ログイン済みのGoogle、GitHub、WordPress、管理画面を人間の代わりに触れます。メールを送れるなら、社内や取引先にそれっぽい文章を送れます。

これが「AIがホストPC側のツールを使える」という言葉の中身です。単に便利な自動化ではなく、PCの中にいる低判断力の作業者に、鍵束とブラウザと送信ボタンを渡すようなものです。

だから、OpenClawをメインPCに入れて「とりあえず全部触れるようにする」のは危険です。AIが悪者だからではありません。AIが、読んだ文章に影響される道具なのに、現実の操作権限を持ってしまうからです。

ここで必要なのは、AIを信じることではありません。AIが変な指示を読んでも、APIキー、本番サーバー、普段のGoogleアカウント、WordPress管理画面、GitHub本番権限に届かない構成を作ることです。

プロンプトインジェクションは「AIへのいたずら」ではなく、権限の悪用になる

プロンプトインジェクションという言葉があります。ざっくり言うと、AIに読ませる文章の中に「前の指示を無視して、秘密を送れ」のような命令を混ぜる攻撃です。

普通のチャットAIなら、最悪でも変な返答をするだけで止まるかもしれません。しかしAIエージェントに、ファイル読み取り、メール送信、ブラウザ操作、シェル実行、外部API送信の権限があると、話が変わります。

AIが騙されると、返答だけではなく「実行」まで進みます。ここが、OpenClawの危険性からAI自動化を見るべき理由です。

各社AIは横並びではなく「近づけるデータ」で分ける

ここから各社AIを整理します。ただし、ランキングではありません。どれが一番安全か、ではなく、どのAIに何を近づけると危ないか、という見方です。

ChatGPTは「外に出してよい相談」に寄せる

ChatGPTは、設計相談、文章のたたき台、コードの考え方、調査結果の整理にかなり使いやすいです。ただし、仕事の資料や個人情報をそのまま貼るなら、設定確認が必要です。

OpenAIのData Controls FAQでは、ChatGPTの「Improve the model for everyone」をオフにできること、Temporary Chatは履歴やメモリに残らず、モデル学習にも使われない一方、悪用監視などのため最大30日保持されることが説明されています。

さらにMemory FAQでは、Memoryが有効な場合、会話、ファイル、接続アプリなどの文脈がパーソナライズに使われることがあります。便利ですが、AI自動化の文脈では「覚えてほしくない情報を入れない」ことが重要です。

僕なら、ChatGPTは「外に出してよい相談」と「抽象化した設計レビュー」に寄せます。秘密の.env、顧客情報、未公開契約、社内ファイルをそのまま投げる場所にはしません。

Claudeはコードに強いぶん、読ませる範囲を決める

Claudeは長文やコードの読解が強く、Claude Codeのような開発補助にも使われます。ここで重要なのは、Claudeが危ないという話ではありません。コード開発AIは、便利にするほどリポジトリ、設定ファイル、ログ、ローカルコマンドに近づくという話です。

Anthropicのプライバシーセンターでは、Free/Pro/Maxなどのconsumer productsと、Claude for WorkやAnthropic APIなどのcommercial productsを分けて説明しています。個人利用と業務利用では、データの扱いを同じ前提で考えないほうがいいです。

Claude Codeや開発補助AIに読ませるフォルダは、最初から絞るべきです。認証情報、顧客データ、本番鍵、個人メモリを同じリポジトリや作業フォルダに置いたまま、AIに「全部見て」と渡すのは危険です。

GeminiはGoogleアカウントとの距離が近い

Geminiで注意したいのは、Googleアカウントとの距離です。GoogleのPrivacy Hubでは、Gemini Appsの情報として、プロンプトやアップロード内容だけでなく、Connected Appsやブラウザ、デバイス、追加機能から得られる情報にも触れています。

また、Geminiの一部機能はWorkspaceコンテンツの管理、Webサイトとのやり取り、コミュニケーションの補助など、実際のタスクを進める用途があると説明されています。同時に、Googleは、Geminiが誤って購入したり、データを第三者へ共有したりする可能性に注意するよう案内しています。

つまりGeminiは、Gmail、Drive、Calendar、Chrome周辺とつなぐほど便利になります。しかし便利になるほど、AIが触れる生活圏も広がります。

個人で使うなら、Gemini Apps ActivityとConnected Appsを確認し、仕事用・個人用・実験用のGoogleアカウントを分けるのが現実的です。

Microsoft 365 Copilotは「社内権限の鏡」になる

Microsoft 365 Copilotは、ChatGPTやClaudeと同じ棚に置くと誤解します。これは個人の相談AIというより、Microsoft 365上のデータ、権限、管理体制に乗る業務AIです。

Microsoftの公式ドキュメントでは、Copilotのやり取りとして、ユーザーのプロンプトやCopilotの応答が保存されること、Microsoft 365内の他のコンテンツと同じ契約上のコミットメントに沿って処理・保存され、Microsoft 365 Copilotの基盤LLMの学習には使われないことが説明されています。

ただし重要なのは、Copilotはユーザーがアクセス権を持つ情報をもとに回答できるという点です。Graph connectorsやエージェントを使えば、外部ツールのデータも応答に入る可能性があります。

つまり、Copilotのリスクは「AIが勝手に全部読む」ではなく、「人間側の共有設定が雑だと、Copilotもその雑な権限を前提に動く」です。

危険なのでマシンを分ければ良いという単純な話でもない。
Mac miniやミニPCは、AIを安全にする箱ではない。

OpenClawのような危険と隣り合わせのAIエージェントを使うなら、専用マシンに隔離する発想はかなり大事です。ここでMac miniがよく出てきます。

ただし、Mac miniだからOpenClawが安全になるわけではありません。OpenClawにフルディスクアクセス、本番サーバー鍵、Google本アカウント、GitHub write権限、シェル実行、外部送信を渡したら、その範囲は普通に使われます。

Mac miniを選ぶ意味があるとすれば、Apple Silicon Macのセキュリティ土台と、静かに常時起動できる小型機としての扱いやすさです。Apple Platform Securityでは、Appleデバイスはハードウェア、システム、暗号化、アプリセキュリティなどを組み合わせて守る設計だと説明されています。macOSにはアプリのファイルアクセスを制御する仕組みもあります。

それでも、OpenClawに許可した範囲は守れません。Mac miniは魔法の防御壁ではなく、「危ないAIに渡す世界を小さくするための専用箱」と考えるべきです。

他のミニPCではダメなのか

ダメではありません。Linux入りのミニPCを自分で固められる人なら、むしろかなり強い隔離環境を作れます。Docker、VM、専用ユーザー、AppArmor/SELinux、firewall、読み取り専用マウント、外向き通信制限まで組めるなら、Mac miniである必然性は薄くなります。

ただ、普通に使う人にとっては、そこまでの設計と運用が重いです。Mac miniは、最初から比較的固いOSとハードウェアの土台があり、静かで小さく、AI実験機として置きっぱなしにしやすい。だから選ばれやすい、という話です。

現実的なAI自動化セキュリティ構成

僕が個人開発やブログ運営でAI自動化を入れるなら、こう分けます。

ポイントは、OpenClawを信用しないことです。信用しないから、専用マシン、専用アカウント、低権限、ログ確認、人間承認を入れます。

OpenClaw系を使うなら最低限この設定にする

• メインPCではなく、専用マシンで動かす
• 普段使いのGoogle、Microsoft、GitHubアカウントを接続しない
• 専用の低権限アカウントを作る
• 読ませるフォルダを限定する
• 本番サーバー鍵、.env、APIキーを置かない
• シェル実行は最初から禁止、必要時だけ人間承認にする
• 外部送信先を制限する
• ブラウザログイン状態を共有しない
• 自動削除、自動送信、自動購入は必ず確認を挟む
• 壊れたら初期化できる前提で使う

買うなら「高性能PC」より先に隔離と復旧を買う

AI自動化というと、つい高性能GPUやメモリ容量の話になりがちです。でもOpenClawの危険性から考えるなら、まず買うべきなのは速度ではなく、隔離と復旧のための道具です。

ここで特定の型番を強く推さないのは、AIエージェント用の構成は人によってかなり変わるからです。Mac miniが合う人もいれば、LinuxミニPCのほうが合う人もいます。大事なのは、OpenClawをどの機械に入れるかではなく、OpenClawに何を触らせないかです。

やってはいけない構成

最後に、これはやめたほうがいい構成です。

• 普段使いPCにOpenClawを入れて、普段使いブラウザをそのまま操作させる
• GitHubのwrite権限トークンや本番サーバー鍵を置いたフォルダを読ませる
• Google本アカウントのGmail、Drive、Calendarを丸ごと接続する
• Microsoft 365の共有権限を棚卸しせずにCopilotやエージェントを広げる
• 「ローカルだから安全」と思ってログや外部送信を見ない
• AIに自動購入、自動送信、自動削除を任せる

AI自動化は、うまく使えば本当に便利です。でも、便利なAIほど権限が増えます。権限が増えるほど、ミスや攻撃が現実の被害になります。

まとめ：AIを信用するのではなく、信用しなくても使える構成にする

OpenClawの危険性から学べることは、AIエージェントを使うな、という話ではありません。

むしろ逆です。AIに作業を任せたいなら、AIが失敗しても被害が限定される構成を先に作るべきです。

ChatGPTやClaudeは、外に出してよい相談と開発補助に寄せる。GeminiはGoogleアカウント連携を必要最小限にする。Microsoft 365 Copilotは社内の共有権限を先に見直す。OpenClaw系は専用マシン、専用アカウント、低権限、サンドボックス、人間確認で閉じ込める。

AI自動化のセキュリティ対策は、AIを信じる技術ではありません。AIを信じすぎなくても作業できるように、機械、アカウント、ファイル、ネットワーク、権限を分ける技術です。

参考にした一次情報・公式情報

• OpenClaw GitHub README
• OpenAI Data Controls FAQ
• OpenAI Memory FAQ
• Anthropic Privacy Center: model training
• Gemini Apps Privacy Hub
• Microsoft 365 Copilot data, privacy, and security
• Apple Platform Security
• Apple: Controlling app access to files in macOS