Claude Code Computer Use実践ガイド — CLIからMacのGUI操作を自動化するE2Eワークフロー構築

Claude Codeでnpm run buildもgit pushも自動化できた。でも「ブラウザで実際の表示を確認して」「Figmaのデザインと見比べて」と言われた瞬間、CLIの限界にぶつかる。2026年3月、Computer Use機能の追加でその壁が崩れた。

本記事では、既存ツールでは届かない「GUIの壁」をComputer Useでどう突破するか、そして実際に動くE2Eワークフローの構築パターンをコード付きで解説する。

Computer Useとは何か — 既存ツールとの決定的な違い

Bash・Read・Editで完結する世界と、その境界線

Claude Codeの標準ツール群（Bash、Read、Edit、Grep等）はファイル操作とコマンド実行に特化している。ビルド、テスト、デプロイまではこれで十分だ。しかし「デプロイ後の画面表示が正しいか」「ネイティブアプリのUIが崩れていないか」といった視覚的な検証になった途端、CLIの守備範囲を超える。

Computer Useは、macOSのデスクトップをスクリーンショットで「見て」、マウスクリックやキーボード入力で「操作する」機能だ。2026年3月末〜4月初旬にCLI版のResearch Previewとしてリリースされ、Pro/Maxプラン限定で利用できる。CLI版の対応OSはmacOSのみ（2026年4月時点。Desktop版はWindows対応済み）。

ツール選択の優先順位：MCP → Bash → Claude in Chrome → Computer Use

ここが最も重要なポイントだが、Computer Useは最終手段だ。公式ドキュメントが明示する優先順位は以下の通り。

1. MCP（専用API連携）
2. Bash（CLI/シェルコマンド）
3. Claude in Chrome（ブラウザ内操作）
4. Computer Use（デスクトップGUI操作）

例えば「ブラウザでURLを開いてスクリーンショットを取得する」という同じタスクでも、手段によってコスト・速度・信頼性が大きく異なる。

# 方法1: Bash + Puppeteer（最速・最安・最も信頼性が高い）
npx puppeteer screenshot https://example.com --output screenshot.png

# 方法2: Computer Use（OS全体のGUI操作 — 最も高コスト）
# Claude Codeの対話モードで:
# "Safariを開いてexample.comにアクセスし、スクリーンショットを撮って"

CLIで完結するタスクにComputer Useを使うと、スクリーンショット送信によるトークン消費でコストが数倍になる。Computer Useが真価を発揮するのは以下の3領域だ。

• ネイティブアプリ操作（Xcode、Figma Desktop、System Settings等）
• ビジュアル検証（ネイティブフォント描画、OS依存レイアウトの目視確認）
• GUIしかないツールの自動化（管理画面の定型操作）

セットアップと権限設定 — 動かすまでの3ステップ

Accessibility・Screen Recording権限の付与手順

必要環境はClaude Code v2.1.85以降、Pro/Maxプランだ。

ステップ1: Claude Codeの対話モードで /mcp メニューからcomputer-useサーバーを有効化する

ステップ2: 初回使用時にmacOSが自動でAccessibilityおよびScreen Recordingの権限ダイアログを表示するので、許可する

ステップ3: ターミナルアプリを完全に再起動する（ウィンドウを閉じるだけでは不十分）

# 権限が付与されたか確認（Screen Recordingの場合）
# screencaptureが正常に動作すれば権限OK
screencapture -x /tmp/test_capture.png && echo "権限OK" || echo "権限NG"

claude -pでは使えない：対話モード必須の制約

正直、これが一番痛い制約だと思う。非対話モード（claude -p --dangerously-skip-permissions）ではComputer Useは使用できない。自動化パイプラインに組み込む場合、対話セッションをラップする工夫が必要になる。

# expectでClaude Code対話セッションをラップする例
#!/usr/bin/expect -f
spawn claude
expect ">"
send "Computer Useでブラウザを開いてlocalhost:3000のスクリーンショットを撮って\r"
expect -timeout 120 ">"
send "/exit\r"
expect eof

実践ユースケース3選

①デプロイ後のビジュアルリグレッションテスト

Puppeteerでもスクリーンショットは撮れるが、ネイティブフォント描画やOS設定依存のレイアウト崩れはヘッドレスブラウザでは再現できない。Computer UseならSafariの実際の描画結果をキャプチャできる。

# Claude Code対話モードでのプロンプト例
Safariで https://myapp.vercel.app を開いて、
ページ全体が読み込まれたら以下の操作をして:

1. トップページのスクリーンショットを ~/screenshots/top_current.png に保存
2. 下に500pxスクロールしてスクリーンショットを ~/screenshots/scroll_current.png に保存
3. Safariを閉じて

取得したスクリーンショットを前回デプロイ時のものと比較する。

// compare-screenshots.mjs
import Pixelmatch from "pixelmatch";
import { PNG } from "pngjs";
import fs from "fs";

const img1 = PNG.sync.read(fs.readFileSync("screenshots/top_baseline.png"));
const img2 = PNG.sync.read(fs.readFileSync("screenshots/top_current.png"));
const { width, height } = img1;
const diff = new PNG({ width, height });

const mismatch = Pixelmatch(
  img1.data, img2.data, diff.data, width, height, { threshold: 0.1 }
);

fs.writeFileSync("screenshots/diff.png", PNG.sync.write(diff));
console.log(`差分ピクセル数: ${mismatch} (${(mismatch / (width * height) * 100).toFixed(2)}%)`);

if (mismatch > width * height * 0.01) {
  console.error("1%以上の差分を検出。ビジュアルリグレッションの可能性あり。");
  process.exit(1);
}

②Xcodeプロジェクトのビルド＆Simulator操作

xcodebuildコマンドでビルドはできるが、Simulatorで実際にアプリを起動して画面遷移を確認するにはGUI操作が必要だ。

# Claude Code対話モードでのプロンプト例
以下の操作をして:
1. Xcodeで ~/Projects/MyApp/MyApp.xcodeproj を開く
2. iPhone 16 Pro Simulatorを選択してビルド＆実行
3. Simulatorが起動したら、画面中央のログインボタンをタップ
4. ログイン画面のスクリーンショットを ~/screenshots/login.png に保存

③GUIしかない管理画面の定型操作自動化

macOS System SettingsやVercel DashboardなどAPIが提供されていない管理画面の操作を自動化できる。ただし、これは信頼性が最も低いユースケースでもある。UIの変更で操作が壊れるリスクを許容できる場面に限定すべきだ。

ハマりポイントと対処法

権限エラー・タイムアウトの主要トラブル

権限エラー: Screen Recording権限を付与した後、ターミナルアプリのプロセスごと再起動が必要。Cmd+Qで完全終了してから再度起動する。ウィンドウを閉じただけでは権限が反映されない。

タイムアウト: 高解像度環境ではスクリーンショットのサイズが大きくなりトークン消費と応答時間が増大する。スクリーンショットは自動的にダウンスケールされるが、UI要素が小さくて認識しにくい場合はアプリ側で表示サイズを拡大することで改善できる（ディスプレイ解像度自体を下げる必要はない）。

# 現在のディスプレイ解像度を確認
system_profiler SPDisplaysDataType | grep Resolution

プロンプト設計のコツ

Computer Useの精度を上げるには、視覚的特徴で指示するのがポイントだ。

# 悪い例
「保存ボタンをクリック」

# 良い例
「画面右上にある青色の『保存』ボタンをクリック」

位置・色・テキストの3要素を組み合わせると、Claude Codeがスクリーンショットから正しい要素を特定しやすくなる。

セキュリティとリスク管理

Computer Useに渡してはいけない操作

Computer Useを使う際、スクリーンショットはAnthropicのAPIに送信される。以下の操作は避けるべきだ。

• パスワード入力画面での操作（スクリーンショットに認証情報が映る）
• 決済画面や機密情報が表示される画面での操作
• 信頼できないWebサイトの閲覧（プロンプトインジェクションで操作を乗っ取られるリスク）

サンドボックス的運用のベストプラクティス

本番環境での利用を検討する場合は、専用のmacOSユーザーアカウントを作成し、最小限の権限でComputer Useを実行するのが安全だ。メインの作業アカウントとは分離することで、万が一の誤操作の影響範囲を限定できる。

Research Preview段階であることを念頭に、本番ワークフローへの組み込みは慎重に進めてほしい。

Computer Useは「CLIでできることをGUIでもできる」ツールではない。CLIでは原理的に不可能な「見た目の検証」「ネイティブアプリ操作」という領域を開拓する機能だ。ただしツール選択の優先順位（MCP → Bash → Claude in Chrome → Computer Use）を守ることが成功の鍵になる。

まずは本記事のビジュアルリグレッションテストのパターンから試して、自分の開発ワークフローのどこに「GUIの壁」があるかを見極めてほしい。