Claude Code × Computer Use実践ガイド — CLIで足りないときにGUI操作へ自動フォールバックする開発自動化パターン
Claude Codeで開発を自動化していて、こんな場面で手が止まったことはないだろうか。「ブラウザで実際の表示を確認してほしい」「Figmaからデザイントークンを取得したい」「管理画面のフォームを操作してテストデータを作りたい」——CLIだけでは届かない"壁"だ。
2026年3月23日、Anthropicはこの壁を壊す機能をリリースした。Claude Code Computer Use(研究プレビュー)。CLIエージェントが必要に応じてGUI操作に自動フォールバックする仕組みだ。本記事では、セットアップから実践的なワークフロー設計、安全なパーミッション運用まで、開発者目線で解説する。
Computer Useとは何か — CLI自動化の「最後のピース」
従来のClaude Codeでできたこと・できなかったこと
Claude Codeは元々、Bash・Read・Edit・Write・WebFetchといったCLIツール群で強力な開発自動化が可能だった。ファイルの読み書き、ビルド、テスト実行、git操作、さらにはWeb検索まで、ターミナル内で完結するタスクなら大抵こなせる。
しかし、GUIしかインターフェースがないアプリには手が出せなかった。ブラウザ上のSPA表示確認、Figmaでのデザイン参照、APIが公開されていない管理画面の操作——こうした場面では結局、人間が画面を見て手動で操作する必要があった。
Computer Useはその名の通り、マウスとキーボードの操作をClaudeが代行する機能だ。スクリーンショットで画面を認識し、クリック・入力・スクロールを実行する。
ツール選択の優先順位を理解する
ただし、Computer Useは「常にGUI操作する」機能ではない。ここが設計上の重要なポイントだ。Claudeは以下の優先順位でツールを選択する。
① Connector(Slack, Linear, Google Calendar等の専用連携)
↓ 対応するConnectorがない場合
② Bash(シェルコマンド)
↓ CLI操作では対応できない場合
③ Claude in Chrome(ブラウザ内での作業)
↓ 上記すべてで対応不可な場合
④ Computer Use(画面全体のGUI操作)
つまりComputer Useは最終フォールバックであり、効率の良い手段が使えるなら自動的にそちらが選ばれる。この設計が、Computer Useを「遅くて不安定なGUI操作ツール」ではなく「CLIで解決できない場面だけの切り札」にしている。正直、この優先順位設計を知ったとき、よく考えられているなと感心した。
セットアップ手順(macOS研究プレビュー)
前提条件と有効化
Computer Useを利用するための前提条件は以下の通り。
- macOSのみ対応(Windows/Linuxは未対応)
- Pro または Max プランが必要(Team/Enterpriseプランでは利用不可)
- Claude Code Desktopアプリがインストール済みであること
有効化の手順はシンプルだ。
- Claude Code Desktopを開く
- Settings > Desktop app > General に移動
- Computer Use のトグルをONにする
- macOSのアクセシビリティ権限と画面収録権限を付与する
macOS権限の付与とトラブルシューティング
macOSの権限付与は「システム設定 > プライバシーとセキュリティ」から行う。必要なのは2つ。
| 権限 | macOSでの表記 | 役割 |
|---|---|---|
| Accessibility | アクセシビリティ | クリック・入力・スクロールの実行 |
| Screen Recording | 画面収録とシステム音声の録音 | スクリーンショットによる画面認識 |
よくあるハマりポイント: 権限を付与した後、Claude Code Desktopの再起動が必要になる場合がある。権限を変更してもトグルがグレーのままなら、一度アプリを完全終了して再起動してみてほしい。また、Screen Recordingの項目はmacOSのバージョンによって「画面収録」ではなく「画面収録とシステム音声の録音」と表示されることがあるので注意が必要だ。
有効化できたかどうかは、Claude Codeに対して画面操作を含むタスクを依頼してみるのが最も確実な確認方法だ。
# Claude Codeで試してみる例
> Safariを開いて、現在表示されているページのタイトルを教えて
Computer Useが有効であれば、アプリへのアクセス許可を求めるプロンプトが表示される。
実践パターン3選 — CLI×GUI連携ワークフロー
パターン1: デプロイ後のビジュアルリグレッション確認
なぜCLIだけでは不十分か: ビルドやデプロイはCLIで完結するが、「画面が正しく表示されているか」の確認は人間が目視で行うしかなかった。Playwrightのスクリーンショット比較もあるが、セットアップと維持が手間になりがちだ。
Claude Codeへの指示例:
localhost:3000をブラウザで開いて、トップページのスクリーンショットを撮って。
レイアウト崩れがないか確認して、問題があればCSSを修正して。
修正後にもう一度確認して、OKならコミットして。
このとき内部では以下のように処理が流れる。
- Bashでdev serverを起動(
npm run dev) - Computer Useでブラウザを開きスクリーンショットを取得
- Claudeが画像を分析し、レイアウトの問題を検出
- EditでCSSファイルを修正
- Computer Useで再度ブラウザを確認
- Bashで
git commit
CLI→GUI→CLI→GUI→CLIと、必要な場面だけGUI操作に切り替わるのがポイントだ。
パターン2: 管理画面操作の自動化
なぜCLIだけでは不十分か: 社内ツールや管理画面にはAPIが用意されていないことが多い。テストデータの投入やステータス変更のために、毎回ブラウザで手動操作するのは非効率だ。
Claude Codeへの指示例:
以下のテストユーザーを管理画面から登録して。
- 名前: テスト太郎
- メール: test-taro@example.com
- 権限: 編集者
管理画面のURL: http://localhost:8080/admin/users/new
ログイン情報: admin / admin123
Computer Useがブラウザを操作してフォーム入力・送信を行う。ただし、ブラウザに対するComputer Useの権限はView onlyに制限されている点に注意が必要だ(詳細は次セクション)。ブラウザ内の操作が必要な場合は、Claude in Chrome拡張との併用が推奨される。
パターン3: デザインツールからの情報取得
なぜCLIだけでは不十分か: FigmaにはAPIがあるものの、トークン取得やエンドポイント設定が必要で、ちょっとした色確認のためにAPI連携を組むのは大げさだ。
Claude Codeへの指示例:
Figmaで開いているデザインファイルから、プライマリカラーとセカンダリカラーの
カラーコードを読み取って、src/styles/variables.cssに反映して。
Computer UseがFigmaアプリのスクリーンショットを取得し、画面上のカラー情報を読み取り、CLIでCSSファイルを更新する。Connector/APIが使えないツールへの「目」として機能するわけだ。
パーミッション設計 — 安全にComputer Useを運用する
アプリ別パーミッションの仕組み
Computer Useは強力な機能だけに、安全設計がしっかりしている。Claudeが初めてアプリにアクセスする際、セッションごとに許可を求めるプロンプトが表示される。
さらに、アプリのカテゴリによって操作レベルが固定されている。
| カテゴリ | 操作レベル | 対象アプリ例 |
|---|---|---|
| ブラウザ・取引プラットフォーム | View only | Safari, Chrome, 取引アプリ |
| ターミナル・IDE | Click only | Terminal, VS Code |
| その他 | Full control | Finder, メモ帳等 |
この分類はユーザーが変更することはできない。ブラウザがView onlyに制限されているのは、認証情報の誤操作を防ぐためだ。ブラウザ内での操作が必要な場合はClaude in Chromeを使い、Computer Useでは画面の閲覧のみ——という使い分けが設計思想として組み込まれている。
Dispatch経由の30分タイムアウトに注意
Dispatch(iPhoneからClaude Codeにタスクを指示する機能)経由でComputer Useを利用する場合、アプリへの承認が30分で期限切れになる。通常のデスクトップセッションではセッション全体で有効なので、これはDispatch固有の制約だ。
つまり、Dispatchで長時間のGUI操作タスクを投げる場合は、30分以内に完了する単位にタスクを分割する設計が必要になる。外出先からスマホでタスクを投げる運用を考えている人は、この制約を頭に入れておこう。
なお、--dangerously-skip-permissionsフラグを使ったAuto Modeでも、Computer Use操作には段階的な許可が効く。CLIの権限をスキップしたからといって、GUI操作まで無制限になるわけではない。これは野良スクリプトからの無制限なGUI操作を防ぐ重要な安全弁だ。
既知の制約とワークアラウンド
研究プレビュー段階であることを踏まえ、現時点の制約を正直に整理しておく。
- 複雑なドラッグ&ドロップやマルチウィンドウ操作は不安定。ファイルのD&Dやウィンドウ間の切り替えが絡む操作は失敗することがある
- 高解像度ディスプレイではUI要素の座標認識がずれることがある。Retinaディスプレイで小さなボタンをクリックする操作は特に精度が落ちやすい
- macOS限定。Windowsは将来対応予定とされているが、Linux対応の言及はない
- Team/Enterpriseプランでは使えない。そのため、チーム全体のCI/CDパイプラインにComputer Useを組み込むのは時期尚早だ。現時点では個人の開発ワークフロー改善に活用するのがベストプラクティスと言える
ワークアラウンドとしては、操作対象のUIを可能な限りシンプルに保つこと(大きなボタン、明確なラベル)、1回の指示で行うGUI操作を最小限にすること、失敗時のリトライを前提とした指示設計を心がけるとよい。
まとめ
Claude Code Computer Useは「CLIエージェントがGUI操作もできるようになった」という単純な話ではない。Connector → Bash → Claude in Chrome → Computer Useという優先順位設計により、最も効率的な手段を自動選択しつつ、どうしてもGUI操作が必要な場面だけをカバーする"最後のピース"だ。
研究プレビュー段階のため制約はあるが、デプロイ後の目視確認やAPIのない管理画面操作など、開発者が日常的に手動で行っていた作業を自動化できるポテンシャルは大きい。
まずは小さなワークフローから試して、CLI×GUIの連携パターンを自分の開発スタイルに組み込んでみてほしい。
参考リンク
