shirokuronoir

クラウドAIとPCをつなぐ6つの安全策

クラウドAIとPCをつなぐ6つの安全策

クラウド上のAIエージェントから、手元のPCにあるファイルや開発ツールを使えたら便利です。ただし、接続できることと、安全に仕事へ組み込めることは別です。認証が通った後に何を許すか、PCからどの情報を返すか、異常時にどう止めるかまで決めなければなりません。

先に結論

クラウドAIとローカルMCPツールをつなぐ前に、次の6点を固定します。

1. PC側へインターネット公開ポートを作らない

2. 接続ごとに利用者とエージェントを認証する

3. 呼び出せるツールを許可リストで限定する

4. PCから返すデータを必要最小限にする

5. 利用者ごとにセッションと権限を分離する

6. 監査ログと即時停止手段を用意する

AWSが公開したMCPブリッジの事例では、ブラウザー拡張とChrome Native Messagingを使い、既存のWebSocket接続上で署名済みメッセージを往復させています。PCへ受信用ポートやVPNを新設せず、ローカルMCPサーバーをクラウド側エージェントから利用する構成です。

この記事では、その構成を手元で導入したとは断定しません。AWS公式ブログとAgentCore公式ドキュメントを照合し、実装前に決める安全境界を運用チェックへ落とし込みます。

公式情報で確認できたこと

Amazon Bedrock AgentCore Runtimeは、HTTPに加えて永続的なWebSocket接続をサポートしています。公式ドキュメントでは、接続にSigV4またはOAuth 2.0を使い、セッションIDごとに実行コンテキストを分離できると説明されています。

WebSocketは双方向通信に向きますが、接続が続いているだけでローカル操作を無制限に許可してよいわけではありません。AWSのMCPブリッジ事例でも、クラウドから任意のPCへ直接接続するのではなく、ブラウザー側から確立した経路を使っています。

さらに、AgentCoreのセキュリティガイドは、AWS内のサービス間ではIAM SigV4、エンドユーザーがIDプロバイダーで認証する場合はJWTを選ぶ考え方を示しています。接続の暗号化だけでなく、誰がどのエージェントを呼べるかを識別することが前提です。

1. PC側へ公開ポートを作らない

最初に守る境界は、PCを待受サーバーとしてインターネットへ公開しないことです。ルーターのポート開放や一時的なトンネルURLでMCPサーバーを直接公開すると、認証設定の漏れがそのまま侵入口になります。

PC側から認証済みのWSS接続を開始し、その接続内で要求と結果を往復させます。接続先、証明書、認証方式を固定し、未知のホストへ自動接続しない設定にします。

導入前には、Windows Defender Firewallやルーター設定で新しい受信規則が増えていないことも確認します。「動いたから公開ポートを残す」という状態を避けるためです。

2. 接続と操作を別々に認可する

接続時の認証に成功しても、すべてのツール実行を許可する理由にはなりません。利用者、エージェント、端末の3つを識別し、その組み合わせで許可範囲を決めます。

本番では短期トークンを使い、発行者、対象者、有効期限、スコープを検証します。共有APIキーをブラウザー拡張や設定ファイルへ埋め込まないことも重要です。長期キーを減らす設計は、AIエージェント認証、APIキーを減らす設計で詳しく整理しています。

操作要求には、利用者ID、端末ID、セッションID、要求ID、対象ツール、発行時刻を持たせます。同じ要求IDを再送しても二重実行されないよう、一定時間の重複拒否も入れます。

3. 許可ツールを小さく始める

最初からシェル、ファイル編集、ブラウザー操作を一括で許可しません。用途ごとに専用ツールを作り、入力値と対象範囲を狭くします。

例えばログ調査なら、任意コマンド実行ではなく「指定サービスの直近200行を読む」のような読み取り専用ツールから始めます。ファイル操作なら許可ディレクトリを固定し、`..`を含むパスやシンボリックリンク経由の逸脱を拒否します。

確認画面にはツール名だけでなく、対象ファイル、コマンド、送信先、変更内容を表示します。人が内容を判断できない長いJSONを承認させても安全策にはなりません。

4. PCから返す情報を減らす

ローカルツールの結果には、本文以外の情報が混ざります。絶対パス、ユーザー名、メールアドレス、アクセストークン、環境変数、ブラウザー履歴などです。

クラウドへ送る前に、PC側で削除または置換します。重要なのは、クラウド側へ届いてから隠すのではなく、端末内で最小化することです。ログ全文ではなく必要な行だけを返し、ファイル一覧ではホームディレクトリを基準にした相対表示へ変換します。

次の文字列は最低限の検査対象です。

  • `password`、`token`、`authorization`を含むキー
  • 秘密鍵やCookieの形式
  • メールアドレス、電話番号、顧客ID
  • PCの絶対パスとユーザー名
  • `.env`、資格情報ストア、ブラウザープロファイル

5. セッションを利用者ごとに分ける

AgentCoreのWebSocketドキュメントでは、セッションIDによって別々の実行コンテキストへ振り分ける仕組みが説明されています。同じ考え方をローカル側にも適用します。

異なる利用者の要求、別案件のファイル、検証環境と本番環境を同じセッションへ混ぜません。接続が切れた後に古いセッションを再利用する場合は、利用者と端末の組み合わせを再確認します。

セッションIDは推測しにくい値を使い、表示名やメールアドレスをそのまま入れないようにします。JWTのSubjectなどログへ残る識別子にも、個人情報ではなくGUIDやペアワイズ識別子を使う方針が安全です。

6. 監査ログと停止手段を先に作る

記録するのは成功したツール名だけでは不十分です。誰が、どの端末で、何を要求し、どのポリシーが許可または拒否し、どれだけのデータを返したかを残します。本文や秘密値は保存せず、必要なメタデータへ絞ります。

監視項目は次の通りです。

  • 認証失敗とスコープ不足
  • 未許可ツールの要求
  • 1分あたりの実行回数
  • 返却データ量と処理時間
  • 同一要求IDの再送
  • 切断後の実行継続

異常時にブラウザー拡張を閉じるだけではなく、サーバー側でセッションを無効化し、端末側でも新規要求を拒否できるキルスイッチを用意します。監視の基本はAIエージェントが遅い時に見る5項目にもつなげられます。

30分で作る導入前チェック表

| 項目 | 決めること | 合格条件 |

|—|—|—|

| 接続 | PCから開始するWSS接続 | 受信ポート追加なし |

| 認証 | SigV4または短期JWT | 期限、対象、スコープ検証 |

| ツール | 最初の1用途 | 読み取り専用、対象固定 |

| データ | 端末内の削除規則 | 秘密値と絶対パスが外へ出ない |

| セッション | 利用者、端末、案件の分離 | 別利用者の状態を参照できない |

| 監査 | 拒否と異常も記録 | 要求IDから追跡可能 |

| 停止 | クラウドと端末の両方 | 1操作で新規実行を拒否 |

正常系だけでなく、期限切れトークン、未許可ツール、巨大な返却値、切断直後の要求、同じ要求IDの再送も試します。安全確認は「一度成功した」ではなく、「危険な要求を拒否できた」で評価します。

今日から行う3つの作業

1. クラウドAIに許可するローカル操作を1つだけ選ぶ

2. その操作で返してはいけない情報を10個書き出す

3. 認証失敗と未許可要求を再現し、停止ログが残るか確認する

AI検索と同様に、外部情報とローカル情報の境界を分けることが重要です。AI検索を仕事で使う前の5確認も併せて確認してください。

まとめ

クラウドAIからPC内のMCPツールを使う価値は、ローカル作業を安全な範囲で自動化できることです。しかし、WebSocketやMCPを採用しただけでは安全になりません。

公開ポートを作らず、短期認証、許可ツール、端末内のデータ削減、セッション分離、監査と緊急停止をセットで設計します。最初は読み取り専用の1ツールに限定し、危険な要求を拒否できることを確認してから範囲を広げてください。

関連記事

著者情報

しろのあ。AIとCodexを使ったWordPress、note、アプリ制作、ゲームサーバー運用の自動化を実践し、確認できた手順と判断材料を記録しています。

出典

1. How we built an MCP bridge to give our AgentCore-hosted AI agent access to local MCP tools / AWS Machine Learning Blog

2. Get started with bidirectional streaming using WebSocket / AWS Documentation

3. Security best practices for AgentCore Runtime / AWS Documentation

4. Set up inbound authorization for your gateway / AWS Documentation