Computer Use（コンピューターユース）

macOSでアプリやツールを触っていて、Claudeに画面を操作させて動作確認やGUI操作を任せたい人向け

Computer Use は、ターミナルの中にいるClaude Codeに、あなたのMac画面そのものを触らせる仕組みです。アプリを開く、ボタンを押す、文字を打つ、画面を見る。人がマウスとキーボードでやる操作を、会話の流れのまま肩代わりさせられます。

狙いどころは「コードを書かせたあと、そのまま動作確認まで一気にやらせる」場面です。公式の説明では、Swiftで書いたアプリをその場でビルドして起動し、全部のボタンをクリックして結果をスクショするところまで、コードを書いた同じ会話の中で完結する、とされています。

噛み砕くと

新しく入った社員に、自分の席を一時的に貸すようなものです。マウスもキーボードも本人のものを使ってもらって、目の前で作業してもらう。Claude Code の Bash がガラスケースの中の作業台だとしたら、Computer Use はあなたの実際の机そのものです。

だから便利な反面、机の上にある物には全部手が届きます。公式は「sandboxed Bash と違い、実デスクトップ上で動き、あなたが承認したアプリに触れる」と書いています。ここが一番大事な性格です。

力は強い。代わりに気軽ではない。そういう機能だと思って読み進めてください。

大事な前提：使えるプラン・OS・モードが厳しく決まっている

これは「とりあえず叩けば動く」機能ではありません。公式が条件を細かく固定しています。順に確認していきます。

まずプランです。Computer Use は Pro または Max プラン限定で、Team や Enterprise では使えません。Code Review が Team/Enterprise 専用なのと真逆なので、ここを取り違えると延々ハマります。

次にOSとモード。ターミナル版は macOS 専用で、Linux や Windows のターミナルでは動きません。さらに Claude Code v2.1.85 以降が要り、対話セッション専用です。-p をつけた一回きりの実行（画面を見ずに結果だけ返す使い方）では動きません。

認証も限定的で、Amazon Bedrock・Google Cloud Vertex AI・Microsoft Foundry 経由では使えません。claude.ai の認証が必要です。

これだけ条件があるので「研究プレビュー」という位置づけです。完成品ではなく試験提供だと思っておくと、挙動の粗さに驚かずに済みます。

「自作のmacOSメニューバー時計アプリ」を例に、実際の手順を見る

ここからは具体例で動かします。題材は、画面上のメニューバーに常駐する自作の時計アプリ（MenuBarClock）です。Claude にコードを書かせたあと、ビルド→起動→設定画面のボタンを全部クリックして動作確認→壊れた画面があればスクショ、まで任せてみます。

ステップ1: 前提が揃っているか確認する

最初にバージョンとプランを見ます。古いと有効化メニューにそもそも出てきません。

$ claude --version

v2.1.85 以降であればOK。続けて対話セッションの中でプランを確認します。

/status

ここで Pro か Max になっているか見ます。Team や Enterprise だとこの機能は出ません。

ステップ2: computer-use を有効化する

有効化は /mcp から行います。意外とここで迷う人が多いです。

/mcp

サーバーの一覧が出るので、computer-use を選びます。最初は disabled と表示されているはずです。これを選んで Enable を選択すれば、このプロジェクトでは画面操作が有効になります。

設定はプロジェクトごとに残るので、同じプロジェクトでは一度やれば次回以降は不要です。

ステップ3: 自然言語でそのまま頼む

あとは普段の指示と同じです。何のコマンドを覚える必要もありません。会話でこう投げます。

MenuBarClock の target をビルドして起動して。
設定画面の各ボタンを順番にクリックして動作確認して、
表示が壊れている画面があればスクショを撮って。

ここで初心者がやりがちな勘違いがあります。「有効化したんだから、もうこのアプリも勝手に触れるはず」と思い込むこと。実際はこの先でもう1段、承認が要ります。

ステップ4: macOS の許可を2つ与える

Claude が初めてあなたの画面を使おうとすると、macOS が許可を2つ求めてきます。

• Accessibility: クリック・入力・スクロールを許す設定
• Screen Recording: 画面に何が映っているかを見せる設定

Screen Recording を許可したあとは、Claude Code の再起動を求められる場合があります。求められたら一度落として起動し直します。

ステップ5: そのセッション用にアプリを承認する

computer-use を Enable しただけでは、Mac の全アプリに触れるわけではありません。Claude が特定のアプリを初めて必要とした瞬間に、ターミナルに承認の確認が出ます。

確認には、どのアプリを操作したいか、クリップボード等の追加の許可が要るか、作業中に隠される他アプリの数、が表示されます。ここで「Allow for this session」を選びます。

この承認はそのセッションの間だけ有効です。セッションを閉じれば次回はまた聞かれます。

ステップ6: ビルド・起動・クリック・スクショが流れる

承認すると、Claude が MenuBarClock をビルドして起動し、設定画面のボタンを順にクリックしていきます。操作の開始時、他の見えているアプリは画面から隠されます。ただしターミナルだけは見えたまま残ります。

そして重要な仕様がここです。ターミナルはスクショの対象から外されます。つまり Claude は自分が動いているターミナル画面を見られません。崩れた設定画面を見つけたら、その画面だけをスクショして返してくれます。

途中で止めたくなったら Esc を押せばどこからでも即中断、ターミナルで Ctrl+C でも止まります。止めると Claude はロックを手放し、隠したアプリを元に戻し、操作をあなたに返します。

つまり Computer Use は何をしてくれるのか

• やってくれる: APIの無いネイティブアプリやシミュレータを実際に開いて、クリック・入力・スクロールで動作確認し、画面をスクショして見せる
• スクショを自動で縮小してから送る: Retinaディスプレイ（例: 16インチMacBook Proで3456×2234）でも、モデルへ送る前に約1372×887まで勝手に縮小する。だから解像度を下げたりウインドウを小さくする必要はない。文字が小さすぎて読めないときは、画面の解像度ではなくアプリ側で文字を大きくする
• やってくれない: 自分が動いているターミナルの中身を画面越しに読むこと（安全のため対象外）。Linux/Windows のターミナルでの動作。-p での一回きり実行
• 意味が薄い場面: Claude はまず MCPサーバー、次に Bash（コマンド実行）、次に Claude in Chrome の順に試して、どれでも届かないときだけ Computer Use を使う。この4段階の優先順位は公式に明示されている。MCPで動かせるサービスやBashで終わる操作を画面操作に回すのは、速度も正確さも損なので避けたい

使いどころ3シナリオ（具体題材で再現）

シナリオ1: 自作のSwiftアプリの見た目バグを潰したいとき

例えば、メニューバーの時計アプリで「設定画面を開くとフォントサイズの数字が枠からはみ出す」というバグがあるとします。コードを直しては自分でビルドして目視確認、を10回繰り返すのは正直しんどい作業です。

Computer Use なら「直して、ビルドして、設定画面を開いてスクショ」を1つの会話で回せます。崩れていればスクショが返るので、見たまま次の修正に入れます。手と目の往復が消えるのが効きます。

シナリオ2: APIの無いGUIだけのツールを動かしたいとき

世の中には、コマンドで操作する口（API）を一切持たず、画面のボタンでしか動かせないアプリがあります。古い業務ソフトや一部のデザインツールがそうです。

こういうツールは Bash でも MCP でも届きません。公式も「画面操作は、他の何でも届かないもの専用」と書いていて、ネイティブアプリ・シミュレータ・APIの無いツールが対象だと明言しています。GUIしか入口が無いものを自動で触らせたいときの最後の手段です。

シナリオ3: シミュレータ上のアプリを通しで触らせたいとき

iOSシミュレータで動くアプリを、画面遷移ごとにポチポチ確認するのも地味に時間を食います。「ログインして、設定タブを開いて、各項目をタップして、おかしい画面はスクショ」のような通し確認を任せられます。

ここでも注意は同じで、シミュレータを初めて触るときにそのセッション用の承認が1回入ります。許可したらあとは流れていきます。

初心者が踏みやすい落とし穴

• プランの向きを真逆に覚える。Computer Use は Pro/Max 限定で、Team/Enterprise では使えません。Team/Enterprise 限定の Code Review と混同しやすいので要注意です。
• サードパーティ経由だと使えない。Amazon Bedrock・Google Cloud Vertex AI・Microsoft Foundry 経由では動かず、claude.ai の認証が必要です。
• -p での一回きり実行では動かない。Computer Use は対話セッション専用で、v2.1.85 以降が要ります。画面を見ずに結果だけ返すモードには非対応です。
• Linux/Windowsのターミナルでは動かない。ターミナル版は macOS 専用です。ちなみに Desktop アプリ版なら macOS と Windows に対応します。
• 有効化したのに「触れない」と焦る。computer-use を Enable しても、アプリごと・セッションごとに「Allow for this session」承認が別途必要です。承認はそのセッション限りで、閉じればまた聞かれます。
• 同時に2つ動かそうとして失敗する。1台のMacで画面を操作できるのは1セッションだけです（ロック）。別セッションが使用中だと新規は失敗し、ロックを持っているセッションを知らせるメッセージが出ます。
• ターミナルに出した指示を画面越しに読ませようとする。ターミナルはスクショの対象外なので、Claude は自分のターミナルを見られません。安全のための仕様で、外せません。
• 触らせるアプリの危険度を見落とす。アプリには操作範囲の差があり、ブラウザやトレード系は閲覧のみ、ターミナルやVS Codeはクリックのみ、それ以外は全操作です。VS Codeやターミナル系には「shell access 相当」、Finderには「あらゆるファイルを読み書きできる」、System Settingsには「システム設定を変更できる」と警告ラベルが出ます。承認前に必ず読みます。
• Escが効かないと思い込む。Esc はどこからでも即中断できます。しかもこのキー入力は消費されるので、外部からの不正な指示が Esc を使ってダイアログを勝手に閉じることはできません。ロック取得時には「Claude is using your computer · press Esc to stop.」という通知が出ます。

書き方

/mcp  → computer-use を選んで Enable（プロジェクト初回1回）。以降は自然言語で依頼するだけ

やってみるとこうなる

入力

/mcp
（一覧から computer-use を選び Enable）
MenuBarClock の target をビルドして起動して、設定画面の各ボタンをクリックして動作確認、壊れた画面があればスクショして

出力例

初回は macOS が Accessibility と Screen Recording の許可を要求（Screen Recording 許可後は再起動が要る場合あり）。アプリ操作前にターミナルへ承認の確認（操作するアプリ・追加の許可・隠れるアプリ数）が出るので「Allow for this session」を選ぶ。Claude が MenuBarClock をビルド・起動し、ボタンを順にクリック、崩れた設定画面をスクショして返す。操作中は他アプリが隠れ、ターミナルだけは見えたまま＆スクショ対象外。Esc または Ctrl+C でいつでも中断でき、ロックが外れてアプリが元に戻る。

関連項目

• Code Review（コードレビュー）
• MCP と Skills の違い（エムシーピー・スキルズ）
• --no-chrome（ノークローム）
• Permission Modes（パーミッションモード）
• Option+P / Alt+P（オルト・ピー、Switch Model）

公式ドキュメント

https://code.claude.com/docs/en/computer-use