MENU

クラウドブラウザ活用ガイド

目的と想定読者
本ガイドは、クラウド型エージェント（例：Manus）において、クラウドブラウザを安全かつ効率的に利用するための標準手順を提供します。情報システム部門、開発者、監査担当者、そして実際にエージェントを構築・運用するプロジェクトメンバーを主な読者と想定しています。

1. クラウドブラウザの重要性

1.1 背景

生成 AI を搭載した自律型エージェントは、単なるチャットボットの域を超え、ユーザーの目的を達成するために Web を横断的に操作・収集・整理します。ローカル PC ではなく クラウドブラウザ を採用することで、以下のような運用上の利点を獲得できます。

  • 長時間ジョブ: 深夜帯クロールや定期巡回など、ユーザー PC を占有せず実行可能。
  • OS 依存の排除: Windows／macOS／Linux の違いを吸収し、チーム全体で統一した環境を共有。
  • 監査容易性: 実行ログ・操作履歴が自動でクラウドに保存され、証跡管理を簡素化。
  • セキュアサンドボックス: 外部サイト閲覧時のマルウェアリスクや機密情報流出を最小化。

Point: 当社エージェントの“エンジン”はクラウド側に置き、フロントエンドではなく“業務ロジック”に集中できる設計が鍵となります。

2. 認証・セッション管理

クラウドブラウザの安定稼働は 認証周りの設計 から始まります。

2.1 SSO／IdP 連携

  • Google Workspace、Microsoft Entra ID 等への SSO 対応を優先実装。
  • IdP 側で 最小権限のスコープ を付与し、不要な API 参照権限を与えない。

2.2 多要素認証 (2FA)

  • 初回ログインのみ人間がハンドオフでコード入力。
  • 以降は “アプリパスワード” または “長期有効トークン” のみをエージェントに渡す。

2.3 セッション有効期間と再認証

  • 標準値: 24 時間。短縮が必要な場合はジョブの冒頭で強制再ログインを実装。
  • 自動延長は禁止。セッション失効時は必ず再認証ロジックを発火させる。

2.4 トークン保管

  • Hashicorp Vault など「クラウド金庫」に格納。
  • アプリケーションコード内にハードコーディングしない（環境変数渡し）。

2.5 リトライ／ロックアウト対策

  • 失敗リトライ回数: 最大 3 回。
  • 3 回連続失敗でアラートを発砲し、アカウントロック前に人的対応を促す。

3. Cookie・セッション切れ時のリカバリ

以下の テンプレートフロー をライブラリ化し、すべてのエージェントに組み込みます。

［Cookie / セッション切れ対処テンプレート］
1) ページ再読込（ステータス 401 もしくは 302 リダイレクト検出時）
2) 保存済み資格情報で再ログイン試行
3) 失敗 3 回で管理者に Slack 通知（エラーログ添付）
4) 通知後はジョブを graceful stop し、再実行可能な状態を維持

注意: 自動リカバリを過度に試行するとアカウントロックのリスクが高まるため、回数制限を厳守してください。

4. ファイルレス運用の推奨

ローカル PC への一時保存を排除し、 “データを動かさずコードを動かす” 原則で運用します。

  • API 直接書き込み: 取得データは即時 Google Sheets／BigQuery／S3 等へストリーム送信。
  • クラウド一時領域: 解析用の中間ファイルは /tmp-equivalent な暗号化ストレージを利用し、TTL を 24h 以下に設定。
  • Export 抑制: 閲覧・共有は URL リンク（Signed URL/Pre‑Signed）を基本とし、ダウンロード機能は管理者のみ許可。

5. 長時間ジョブ設計

5.1 実行ウィンドウの設定

  • オフピーク（22:00～06:00 JST 推奨）で実行し、本番サイトへの負荷を分散。

5.2 負荷軽減

  • ページ遷移間隔に ランダムディレイ 1–3 秒 を挿入。
  • robots.txt → Crawl‑delay がある場合は必ず従う。

5.3 チェックポイントと再開

  • 1 URL 処理ごとに進捗を DynamoDB 等へ記録。
  • 障害発生時は 中断点から再開。

5.4 部分成功ログ

  • 途中まで取得したデータを Partial OK として保存。
  • 失敗 URL リストを JSON で別出力。

5.5 通知

  • 完了／失敗時は Slack の #agent‑ops チャンネルへ結果を POST。
  • 重大エラー時は PagerDuty へエスカレーション。

6. 証跡ログと監査

目的: 「そのデータが本当にエージェントによって取得されたか」を第三者が検証できること。

6.1 最低保存項目

項目説明
実行日時・タスク名ISO 8601 形式で記録
入力パラメータ例：開始 URL／検索キーワード
訪問 URL全アクセス URL を時系列で保存
抽出データスナップショットJSON/CSV（10 件毎など任意間引き）
エラー時スクリーンショットPNG (90 % 圧縮) 縮小版
出力先ハッシュSHA‑256 を JSON に追記

6.2 ログ保管ポリシー

  • 保存期間: 3 年間（法定要件に準拠）。
  • 暗号化: KMS 管理キーを用いたサーバーサイド暗号化 (SSE‑KMS)。

6.3 監査手続き

  1. 監査部門が対象期間を指定しログを取得。
  2. ハッシュ一致を確認し、改ざんの有無を検証。
  3. 必要に応じてスクリーンショットで UI 変化をレビュー。

7. 運用体制と責任分界

役割主な責務
オーナーポリシー策定・コンプライアンス維持
DevOpsエージェント構築・ジョブスケジューリング
SecOps認証情報管理・脆弱性対応
監査担当証跡ログの定期レビュー・報告

8. 付録：サンプル実装リソース

  • Git リポジトリ: git@example.com:cloud‑browser‑templates.git
  • Terraform モジュール: VPC・IAM ロール自動作成。
  • Python SDK: Cookie 自動更新ライブラリ cloud_cookie_keeper。
用語集