← レッスンに戻る
第7章 · Claude on the Web

クラウド版 Claude Code のジョブ設計と結果受け渡し

クラウド版 Claude Code Job Design & Handoff · 約 14 分

重要キーワード

English日本語説明
Job Spec ジョブ仕様 クラウド版 Claude Code への依頼を構造化した指示書
Definition of Done 完了の定義 タスクが終わったと判断する条件
Handoff 受け渡し 成果物をユーザー側に届ける形式と経路
Artifact (output) 成果物 PR / ファイル / レポートなどジョブの出力

Computer Use とは

Computer Use は Claude が コンピュータ画面を視認し、マウス・キーボードを操作する 機能です。 スクリーンショット → アクション の循環でブラウザや GUI アプリを操作します。

動作モデル

wzxhzdk:0 → 人が「画面を見て、考えて、操作する」のと同じプロセスを Claude が再現。

主なアクション

API での使い方 (概略)

wzxhzdk:3 実際の操作は 自分が用意したサンドボックス VM に対して行います。Anthropic はモデルを提供するだけで、操作対象 VM の構築・実装は利用側の責任。

クラウド版 Claude Code と Computer Use の関係

wzxhzdk:4 つまり クラウド版 Claude Code は内部で Computer Use を使ってブラウザを操作しています。 「自分で Computer Use を実装するのは クラウド版 Claude Code を自前で作るに近い」 ので、特殊な要件 (社内 VPN・特定 GUI アプリ) でない限り クラウド版 Claude Code を使う方が現実的。

クラウド版 Claude Code で十分な場合 vs Computer Use を直接使う場合

シーン 推奨
公開 Web のスクレイピング クラウド版 Claude Code (組み込み済み)
認証必要な SaaS 操作 クラウド版 Claude Code + Connector
社内 GUI アプリの操作 Computer Use 直接 (自前 VM)
RPA 置き換え (社内 ERP / CRM) Computer Use 直接
End-to-End テスト自動化 Computer Use 直接 (CI 統合)
アクセシビリティテスト Computer Use 直接

RPA (UiPath/Selenium) からの移行

Computer Use は 次世代の RPA とも言える領域。従来の RPA との比較:
従来の RPA (UiPath) Selenium Computer Use
操作対象 GUI / Web Web のみ GUI / Web 両方
学習方法 録画 → 編集 コード 自然言語で指示
UI 変更耐性 弱い (要素 ID 依存) 弱い (要素 ID 依存) 強い (画像理解)
保守性 中 中 高 (画面が変わっても適応)
速度 速い 速い 遅い (画像 + 思考のレイテンシ)
構築コスト 高 (専門ツール) 中 低〜中
ライセンス 高額 無料 API 課金
→ 「UI が時々変わる」「複雑なロジック判定」 が必要なケースは Computer Use の独壇場。 → 「同じ画面を高速大量処理」 は従来 RPA の方が速い。

移行判断のポイント


Use Case (実例)

UC: 古い社内 CRM のデータ抽出 (毎週 4 時間 → 30 分に)

従来: 担当者が CRM にログイン → 各案件の情報をコピー → スプレッドシートに転記 (毎週 4 時間) Computer Use 化: wzxhzdk:5 所要時間: 30 分 / 週、構築コスト 1 日

UC: Web アプリ E2E テスト

wzxhzdk:6 → Selenium 等の従来ツールよりも シナリオを自然言語で書ける のが強み。 UI が変わってもテストコードを書き換えなくて済む。

UC: 古い VBA Excel マクロ業務の置き換え

wzxhzdk:7 → Excel ネイティブ操作 (Computer Use で LibreOffice 経由でも可)。

サンドボックス構築 (リファレンス実装)

Anthropic 公式は Docker ベースのリファレンス実装を公開しています: wzxhzdk:10 → Linux + Firefox + Streamlit UI が立ち上がる。Web UI から自然言語で指示できる。

サンドボックス設計の要件

  1. 隔離: 操作対象を本番環境から分離 (Docker / VM / 専用マシン)
  2. ネットワーク: outbound を必要最小限にホワイトリスト
  3. 認証: 操作対象サービスの認証情報を環境変数で安全に渡す
  4. ログ: 画像 + アクション履歴を全保存 (監査・デバッグ用)
  5. タイムアウト: 1 タスクあたり最大時間を設定
  6. 人間承認: 重要操作 (送信・削除等) は人間に確認を求める設計

セキュリティと倫理のチェックリスト

技術面

倫理・規約面


苦手・注意点

課題 対策
遅い (1 操作に画像 + 思考) バッチ処理を許容、急ぎは従来 RPA
誤クリック 重要操作前に人間承認
CAPTCHA で詰まる 想定して避ける UI 経路を設計
モバイル UI で苦戦 デスクトップ UI を優先
複雑な状態 (タブ多数) タスクをシンプルなシナリオに分割
レート制限 適切な wait を入れる
▶ クラウド版 Claude Code ジョブ仕様レビュー

演習問題

演習 1: ジョブ仕様を 5 要素で書く

あなたが クラウド版 Claude Code に依頼したいタスクを 1 つ選び、目的 / 入力 / 手順 / 出力 / 完了の定義 の 5 要素で完全な仕様を書いてください。

チェックリスト: - [ ] 目的が 1 文で説明されている - [ ] 入力データの所在 (Drive 内 URL / リスト) が明確 - [ ] 手順が 5〜10 ステップに分解されている - [ ] 出力の形式・ファイル名・置き場が指定されている - [ ] DoD が箇条書きで 3〜7 件 - [ ] 制約 (時間上限・品質基準・倫理) が書かれている - [ ] 進捗報告と完了通知のチャネルが指定されている

スタータープロンプト:
私が来週やる予定の業務 (例: 競合 30 社の機能マップ作成) について、クラウド版 Claude Code に渡せるジョブ仕様を 5 要素 (目的/入力/手順/出力/DoD) で完全な形で書いてください。レビューしやすいよう Markdown で。
ヒントを見る

DoD を「定量的に判定可能」な形で書くのがコツ (「30/30 完了」「全行に典拠 URL あり」など)。「品質が高い」のような主観的基準は避ける。

演習 2: 失敗ジョブのリカバリー文を書く

クラウド版 Claude Code から「30 社のうち 18 社しか調査できなかった」という不完全な成果物が返ってきたと仮定し、再依頼のプロンプト を書いてください。

含めるべき要素: - 何が不十分だったか (建設的に) - 残りの 12 社をどう処理してほしいか - 既存の成果物を上書きしないファイル名指定 - 今回の制約変更 (もしあれば)

スタータープロンプト:
前回のタスクで残り 12 社が未処理でした。次の点を必ず守って残りを処理してください: 1) 既存の成果物 `/competitor-pricing-v1.md` を上書きせず `v2.md` に保存 2) 12 社それぞれ最大 5 分まで、取れなければ N/A 3) 完了したら #marketing-reports に通知 4) 表のフォーマットは v1 と完全一致 (列順・命名)。
ヒントを見る

再依頼では「前回のミスを責める」より「次に何を変えるか」を建設的に伝えるのが効果的。AI に対しても人と同じ。

理解度チェック

  1. 良い クラウド版 Claude Code 依頼の 5 要素に **含まれない** のは?
    1. 目的
    2. 入力
    3. 出力
    4. Claude のモデル指定
  2. 完了の定義 (DoD) として **不適切** なのは?
    1. 30 社全部の行が表にある
    2. 各行に典拠 URL がある
    3. サマリ 3 行が完成
    4. 品質が高い
  3. クラウド版 Claude Code が同じエラーを 3 回繰り返している時の対応は?
    1. ひたすら待つ
    2. Esc またはキャンセルして仕切り直す
    3. Opus に切り替える
    4. GPU を増やす
  4. クラウド版 Claude Code の成果物受け渡しで最も一般的なパターンは?
    1. コミットメール
    2. Drive / Notion / GitHub PR / Slack 通知
    3. FTP アップロード
    4. DM で送付
  5. 失敗ジョブのリカバリー文に含めるべき要素として最も重要なのは?
    1. 前回のミスを強く責める表現
    2. 何が不十分だったかを建設的に伝え、次に変えるべき点を明示
    3. 感情的な励まし
    4. モデル変更の依頼
解答と解説を見る
  1. D — 5 要素は 目的 / 入力 / 手順 / 出力 / 完了の定義。モデル指定は依頼の本質ではありません。
  2. D — 「品質が高い」は主観的で判定不能。DoD は定量的・チェック可能な形で書きます。
  3. B — 無限ループしそうな兆候を見たら早めにキャンセル。損切りが大事です。
  4. B — Drive・Notion・GitHub・Slack 等の Connector 経由が一般的。形式はタスクに合わせて選択。
  5. B — 建設的なフィードバックと変更点の明示。人に対するマネジメントと同じです。