なぜ曖昧な指示で直るのか。Claude CodeとComputer Use連携で画面確認から修正まで自律するAI開発

「音声が最後まで読み上げられていない」

僕らがAIに伝えたのは、たったこの一言だ。

エラーログでも、該当箇所の行数でもない。

ただの曖昧な感想だ。

しかし、AIは即座に原因調査を開始した。

音声ファイルの実際の長さを計測し、発話速度の計算ミスを突き止め、コードを修正し、動画を再生成した。

Claude Codeがターミナルを飛び出し、GUI操作や視覚的検証まで自律的に行う。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

ターミナル完結からの脱却と自律化の衝撃

MCPという拡張機能を活用することで、Claude Codeは全く新しい能力を手に入れた。

それがComputer Useとの連携だ。

この連携により、Claude Codeはマウスとキーボードを使ってデスクトップ上のアプリケーションを直接操作できるようになった。

たとえば、iOSアプリの開発フローを想像してほしい。

コンパイルを実行し、シミュレータを起動し、画面上のタブを順番にクリックして動作を確認する。

エラーが起きればスクリーンショットを撮影し、状況を報告する。

この一連のGUIテストまでを、Claude Codeが一貫して自律的にこなすようになっている。

特に注目したいのが、動画生成ライブラリであるRemotionを活用した自動化事例だ。

テキストだけのリリースノートを、テレビ番組のような紹介動画に自動変換するプロジェクトがある。

GitHubのリリースタグを渡すだけで、Claude Codeが動画の構成を考え、コードを生成する。

タイトルアニメーションから始まり、新機能のハイライト、バグ修正のリスト表示、そしてパフォーマンス改善のグラフ化。

すべてのシーンに自動生成された音声ナレーションが付く。

本当に恐ろしいのは、その後のデバッグプロセスにある。

生成された動画を人間がプレビュー再生したとき、ある違和感に気づいた。

各シーンのナレーションが、最後まで読み上げられる前に次のシーンへ切り替わってしまうのだ。

コード上にエラーは出ていない。

ビルドも正常に通っている。

ただ、聴いてみると「なんか途切れている」という、人間にしか分からない感覚的なバグだ。

ここで人間は、Claude Codeに対して「音声が最後まで読み上げられていない」とだけ伝えた。

するとClaude Codeは、驚くべきアプローチで問題解決に乗り出した。

* 音声ファイルの計測: Pythonのwaveモジュールを使い、全シーンの音声ファイルのデュレーションを正確に測定した。

* 計画値との比較: 台本作成時の見積もりと、実際の音声の長さを比較する表を作成した。

* 発話速度の算出: 利用した音声合成エンジンの実際の発話速度が、約5.4文字/秒であることを割り出した。

* 根本原因の特定: 見積もりの7文字/秒という想定よりも実際の読み上げが遅く、TransitionSeries.Sequenceの内部にAudioを配置しているためシーンのdurationInFramesを超えた時点で音声が強制終了されていることを突き止めた。

* 修正と検証: 音声をシーンから切り離し、Compositionルートに絶対フレーム指定で配置し直す修正方針を提案し、すべてのファイルに波及対応を行った。

人間がやったのは、最初の曖昧なフィードバックだけだ。

そこからの原因特定、影響範囲の洗い出し、修正、検証まで、すべてをClaude Codeが自律的に完結させた。

AIは自律型QAエンジニアへ

AnthropicのAIエージェントは用途によって明確に分類されていると認識されてきた。

開発作業やコーディング、テスト実行はターミナルで動くClaude Codeの領域。

一方で、ブラウザ操作やファイル整理、経費精算といったGUIを伴う非エンジニア向けのタスクは、デスクトップアプリであるClaude Coworkの領域だと。

多くの開発者が、この2つを別々のツールとして使い分けるものだと考えていたはずだ。

しんたろー：
正直、僕もずっとそう思ってた。
ターミナルで完結する作業はCodeに任せて、ブラウザでの確認は自分でやるか別のツールを探すしかないって。まさかCodeの中からGUIを直接叩きにいくアプローチがあるとは、という感じ。

しかし、現実はすでにその先を行っている。

Claude CodeにMCP経由でComputer Useのサーバーを組み込むことで、ターミナルベースの開発エージェントが、そのままGUI操作の権限を獲得してしまう。

コードを書いて終わりではない。

自分が書いたコードをビルドし、立ち上がったアプリケーションの画面を自分の「目」で見て、レイアウト崩れがないか確認する。

AIは、論理的な整合性の確認や、膨大なログからのエラー特定には圧倒的な強さを誇る。

先ほどの動画生成の事例でも、音声ファイルの長さをミリ秒単位で計測し、フレームレートと照らし合わせて計算のズレを特定する作業は、人間が手作業でやれば数時間はかかるだろう。

しかし、AIには決定的な弱点がある。

「感覚的な違和感」を検知できないことだ。

コードがエラーを吐いていなくても、UIの余白がなんとなく気持ち悪い。

アニメーションのテンポが少し遅くてイライラする。

音声の語尾が不自然にぶつ切りになっている。

こういった「人間が実際に使ってみて感じる違和感」は、今のAIには自己完結で検知できない。

人間の役割は「コードを書くこと」から「完成品を感覚的にテストし、曖昧な言葉でフィードバックすること」へと移行していく。

「ここがおかしい」「なんか変だ」という人間の直感的な気づき。

それをトリガーにして、AIが論理的な推論を回し、根本原因を特定してコードを修正する。

この「感覚的フィードバック」と「論理的修正」の超高速なループが、これからのAI開発の形だ。

しんたろー：
ThreadPostのUI実装でも、スマホ実機で見たときの微妙なマージンの気持ち悪さとかって絶対あるんだよね。
「なんか詰まってる感あるから直して」って投げるだけで、CSSのどこを触るべきか特定してくれるなら、開発スピードは次元が変わる気がする。

さらに、このハイブリッドなアプローチは、自動化の幅を広げる。

APIが用意されている部分は、MCPサーバーを使って高速かつ確実に処理させる。

一方で、APIが存在しない古い社内システムや、デザインツール、ハードウェアの制御パネルなどは、Computer Useを使って直接GUIを操作させる。

Claude Codeは、これらの手段を自動的に使い分ける。

最も精度の高いツールを優先し、他の手段で到達できない場合にのみ、最終手段として画面操作を実行するのだ。

テストコードを書くのが面倒で手動確認していた部分すら、AIに「画面を見て確認して」と丸投げできる実装が、すでに動き始めている。

視覚テストの自動化パイプラインと実務への影響

フロントエンド開発やGUIアプリ開発における「視覚的なデバッグ」の概念が根本から覆る。

これまでのUIテスト自動化といえば、要素のIDやクラス名を指定してスクリプトを書く必要があった。

Claude Codeに対して、自然言語で画面の操作と確認を依頼するだけで済むようになる。

具体的な実務での活用シナリオをいくつか挙げる。

* ビジュアルバグの再現と修正:

設定モーダルのフッターが、ウィンドウ幅を狭くすると見切れてしまうバグがあったとする。

「ウィンドウを縮小してバグを再現し、スクリーンショットを撮って。その後CSSを修正して再度確認して」と指示するだけだ。AIが自らウィンドウを操作し、視覚的にバグを確認し、コードを直し、修正後の状態までスクリーンショットで報告してくる。

* オンボーディングフローの通しテスト:

新規ユーザー登録から初期設定までの流れをテストしたい場合。

「シミュレータを起動して、オンボーディング画面を順番に進めて。画面の読み込みに1秒以上かかる箇所があれば報告して」と依頼する。AIは画面のボタンを認識してクリックし、遷移時間を計測しながらレポートを作成する。

* CLIを持たないツールの操作:

開発環境の中には、どうしてもGUIでしか操作できないツールが存在する。

そういったツールへの設定変更やデータ抽出も、AIに画面操作を委譲することで、開発パイプラインの中に組み込むことができる。

この強力な機能を使う上で、セキュリティと権限の管理は外せない。

Computer Useは、サンドボックス化された安全な環境の中だけで動くわけではない。

普段使っている実際のデスクトップ環境に直接アクセスし、アプリケーションを操作する。

そのため、Claude Codeが特定のアプリを操作しようとするたびに、ターミナル上に承認プロンプトが表示される仕組みになっている。

この承認はセッション単位で管理される。

Claude Codeを再起動するたびに、改めてアプリへのアクセスを許可する必要がある。

しんたろー：
ターミナルからブラウザの操作権限を渡すって、冷静に考えるとかなり怖いことだからね。
本番環境のDB管理ツールとかを開いた状態でAIに画面操作させるのは、検証用のクリーンな環境を用意してからにしたい。

AIにGUI操作を依頼する際の「指示の出し方」にもコツがいる。

UI操作は、コードの実行と違って曖昧さが生まれやすい。

「設定を変更して」といったざっくりした指示では、AIがどの画面のどの項目を触るべきか迷走してしまう可能性がある。

「設定ウィンドウを開き、全般タブのインターバルスライダーを右端まで動かして」というように、操作対象とアクションを具体的に言語化することが、精度を上げる。

最初は「アプリを起動してスクリーンショットを撮って」という単純なタスクから始めるのがおすすめだ。

AIがどのように画面を認識し、どの程度の速度で操作を行うのか。その感覚を掴んでから、複雑なテストフローや自動化ワークフローの構築に進むといい。

よくある質問（FAQ）

Q1: Claude CodeでGUI操作を行うにはどう設定すればいいですか？

まずClaude Codeのバージョンがv2.1.85以降であることを確認し、古い場合はアップデートする。

Claude Codeのセッション内で `/mcp` コマンドを実行し、サーバー一覧に表示される `computer-use` を選択してEnableを実行する。

この設定はプロジェクト単位で保存されるため、同じプロジェクトでは再設定不要だ。

初回使用時にはmacOSのシステム設定からアクセシビリティと画面収録の権限を付与するよう求められるので、プロンプト内のリンクから該当画面を開いて権限を付与する。

画面収録の権限付与後はClaude Codeの再起動が必要な場合がある。

再起動後、プロンプトのTry againを選択すれば、AIがマウスやキーボードの操作を代行できるようになる。

Q2: 開発業務において、デスクトップ版のAIエージェントとどう使い分けるべきですか？

ターミナルベースのClaude Codeは、コーディング、ビルド、テスト実行、Git操作など、プロジェクトのソースコードに直接関わる業務に特化させるのが基本だ。

一方、デスクトップ版のClaude Coworkは、経費精算、フォルダの整理、ブラウザを使ったリサーチなど、開発以外の一般的なナレッジワークに向いている。

ただし、今回解説したようにMCP経由でComputer Useを有効化すれば、ターミナル側からも画面操作が可能になる。

開発中のアプリの動作確認などはターミナル側で完結させるのが最も効率的だ。

Q3: AIが生成したコードや動画の品質を担保するためのベストプラクティスは？

AIは論理的なエラーを見つけるのは得意だが、人間の感覚的な品質基準は検知できない。

必ず人間が最終的なプレビューを確認するプロセスを挟む。

動画の音声が不自然に途切れていないか、UIのレイアウトに違和感がないか。

人間が実際に見て、聴いて感じた「なんかおかしい」という曖昧な感覚をそのまま自然言語でAIに伝えることで、AIが根本原因を特定して修正するループが回る。

まとめ

Claude Codeは「コードを書くツール」から、自ら動かして画面を確認し、バグを直す「自律型エージェント」へとフェーズが変わった。

発話速度5.4文字/秒という計測値一つで、人間が感じた「なんか途切れてる」を根本原因まで分解してみせた。

僕ら開発者は、AIが検知できない感覚的な違和感をフィードバックするディレクターとしての役割に集中する。

それだけでいい。

👉 ThreadPostでSNS運用を自動化する