GPT-5.4 Computer Use 実践レポート

「LLMに丸投げしたら本当に“現場作業”が終わるのか？」

Hook：LLMが「いい感じのコード」までは書くけど、そこからが地獄じゃないですか？

LLM にコードを書かせたけど、
ローカルに落として
依存ライブラリ入れて
環境変数いじって
失敗して
ちょっと修正して
…この「最後の 20%」だけなぜか人間が夜中にやっている。
RPA もそうです。
ちょっと UI が変わるたびにシナリオ修正。
例外パターンが増えるたびに if 文だらけのフロー。
「これ、人がやったほうが早くない？」と何回思ったか分からない。

正直、「LLM+RPA」で全部自動化できるという宣伝は、現場の感覚からするとかなり盛って聞こえます。

そこに GPT-5.4 の Computer Use が来たわけですが、
実際に動かしてみて感じたのは、

これは「チャットボットが賢くなった」話ではなく、
“仮想オペレーターを雇うための OS 側インターフェースが生えた” という話だ、

ということです。

これは何なのか：LLM界の「RPA × VDI × リモートワーカー」

一言で言うと、GPT-5.4 の Computer Use は、

「RPA を、LLM による“その場判断付き”でやらせる機構」

です。

OpenAI の説明や実装レポートをざっくり要約すると：

LLM に対して「ツール」を渡すのではなく、
「コンピューターという環境」を丸ごと渡す
ファイル IO / GUI 操作 / CLI 実行などをセッション継続で任せる
1 セッション = 1 人の「仮想オペレーター」のように扱う
ファイル構成や途中成果物を LLM 側が覚えながら作業を進める

歴史的なアナロジーでいうと：

以前：
「curl 打てるだけの Web アプリ」に
少しずつ Selenium / Puppeteer をくっつけて
画面操作も頑張って自動化していたフェーズ
今回：
OS そのものを操作できる Selenium を、LLM の中に埋め込んだ感じ

つまり、

従来の「LLM付きヘルプデスク」から、
「LLM に PC アカウントを一つ渡して、サーバールームの片隅で働いてもらう」世界へ

踏み出すための一歩です。

なぜ重要か：敵は「別の LLM」ではなく「既存の RPA と人力オペレーション」

3-1. LangChain や Claude と比べて、どこが違うのか

よくある誤解がこれです：

「LangChain エージェントあるし、Claude も Computer Use あるし、
GPT-5.4 の Computer Use って、ただの“別バリエーション”でしょ？」

実際に触ってみて感じる違いは、抽象レイヤの位置です。

LangChain 系：
開発者がツール群やフローを定義して、
「どの API をどの順番で呼ぶか」を LLM が決める
つまり、“ツール指揮官”としての LLM
GPT-5.4 Computer Use：
開発者は OS/コンテナとのインターフェースと制約だけを作る
そこから先の「ファイル編集する」「アプリ開く」「CLI 叩く」は LLM の自由
つまり、“PC オペレーター”としての LLM

この違いのせいで、設計の発想がかなり変わります。

これまで：
「この業務のための専用ツール関数を 10 個実装して…」
これから：
「とりあえず sandbox /workspace/session-xxx と
open_file / write_file / run_command だけ渡しておけば、
あとは LLM が勝手に仕事を組み立てる」

ぶっちゃけ、業務個別の“ラッパー関数だらけのコード”を書くコストは
かなり減らせる可能性があります。

3-2. RPA ベンダー視点でいうと、どこがまずいのか

RPA と比較すると、Computer Use の「やばさ」は分かりやすいです。

RPA：
人間がシナリオをきっちり設計
UI 変更に弱い
イレギュラー対応は if/else 地獄
GPT-5.4 Computer Use：
画面をスクリーンショットで“見る”
その場のレイアウト変化に、自然言語の理解で対応
ベンチマーク OSWorld で 人間専門家越え（75.0% vs 72.4%）

この組み合わせは、

「きっちり設計したロボット」から
「マニュアルを渡すと自分で手順を考えて動くロボット」へのシフト

にかなり近いです。

UiPath などの RPA もすぐに死ぬわけではありませんが、
「画面ポチポチだけ」のプロダクトは、
正直、今後はかなり厳しくなると思います。

実装して分かった“現実”：必要なのは「プロンプト職人」ではなく「インフラとガバナンス担当」

ここからは実務寄りの話です。

開発者として Computer Use を触ってみて、
一番印象が変わったのは、

「LLM アプリ開発」から「VDI + セキュリティ + 監査基盤付きのリモートワーク環境の設計」に
仕事の重心が移る

という点でした。

4-1. まず Sandbox とコンテナが“絶対前提”

LLM に OS 操作を解禁する以上、
以下は「やるかどうか」ではなく「どこまでやるか」の議論です。

コンテナ or VM 前提
Docker / LXC / Firecracker なんでもいいですが、とにかく隔離
ファイルシステムの制限
/workspace/session-<id> 以外見せない
ネットワーク・コマンドの制限
外向き通信禁止、もしくは特定ドメインだけ許可
実行コマンドのホワイトリスト

これらはアプリ側で必須です。
LLM プロンプトにいくら「危険なことはしないで」と書いても意味はありません。

正直、「プロンプトエンジニア」がメインスキルの人だけで
Computer Use をプロダクションに出すのは、かなり危険だと思います。

4-2. セッション = 「仮想オペレーター」という設計に変わる

従来は「1 リクエスト = 1 回の賢い相談」でしたが、
Computer Use では、

1 セッション = 1 つの仮想 PC + 1 人の“AI オペレーター”
必要な情報：
セッション ID
作業ディレクトリ
許可される操作種別（ファイル種、ネットワーク可否など）
これを DB なりメモリなりに保持し、
LLM のツール呼び出しを全部そこにぶら下げる

という構造になります。

ここで地味に効いてくるのが、

ログと監査の設計

です。

どのユーザーの、どのプロンプトがトリガーで、
どんな OS 操作（コマンド、ファイル書き換え）が実行され、
結果はどうだったか

これをタイムラインで追えるようにしておかないと、
トラブルシューティングもコンプラ対応も詰みます。

「LLM による PC 操作」というと夢があるように聞こえますが、
実態としては、

「SaaS + VDI + 監査ログ + セキュリティ製品」を全部いっぺんに導入するようなもの

で、アーキテクチャの複雑さはかなり増えます。

The Gotcha：ぶっちゃけ、万能ではないし、安くもない

ここからは、「テンション上がる話」ではなく
「実際にやってみてキツかった点」の話です。

5-1. コスト：小さいタスクまで全部投げると、普通に高い

Computer Use の1タスクは、

LLM 呼び出し（しかも長コンテキスト）
ツール呼び出し（スクリーンショット、ファイル IO、コマンド）
それをさばくためのコンテナ/VM リソース

が全部乗ってきます。

1 回の「Excel ちょっと直して PDF にしてメールして」の裏で、
何十ステップも OS 操作＋LLM ステップが走る
当然トークンコストも増える
同時セッション数が増えるとインフラコストも一気に上がる

正直、「全部 Computer Use に投げればいいじゃん」はかなり危険です。

現実的には、

LLM の通常 API（テキスト/コード生成）
既存の API / バッチ処理
Computer Use（人間の PC 操作を代行させたい領域だけ）

をちゃんと切り分けないと、コスト負けします。

5-2. テストの難易度：RPA よりむしろキツいまである

RPA でさえ E2E テストは大変でしたが、
Computer Use はさらに条件が増えます。

そのときのファイル状態
ネットワークや外部システムの応答
LLM の確率的な応答

すべてに依存するので、

「毎回、ほぼ同じ操作をしてくれること」を
テストで担保するのがかなり難しい

実運用では、

「常に 100% 成功させる」のではなく
失敗前提で、やり直しやロールバックを組み込む設計
重要な操作は人間による承認フローを挟む
ログを見て「なぜ失敗したか」を追いやすくする

といった、オペレーション設計が重要になります。

5-3. ベンダーロックイン：ノウハウの出口がほぼない

もう 1 つ地味に効くのが、ロックインです。

GPT-5.4 Computer Use の挙動やエラー傾向
それに合わせたプロンプト・制約・リトライ戦略

こういうノウハウは、
ほぼそのまま 他社モデル（Claude、DeepSeek など）の Computer Use には転用できません。

Claude 系は「慎重に確認してくる」操作スタイル
GPT-5.4 は「わりと決断して一気にやり切る」スタイル

という違いだけでも、

人間レビュー前提の設計か
バックグラウンド完全自律エージェントか

でアーキテクチャが変わってきます。

正直、「将来別ベンダーにも切り替えたいから、今は薄く統合しよう」というのは、
Computer Use レベルまで踏み込んだ瞬間にかなり難しくなります。

個人的結論：プロダクション投入は「局所戦ではアリ、本丸はまだ様子見」

最後に、「じゃあ実際どうするの？」という話です。

6-1. どこから使うべきか

実務的には、こんな順番をおすすめします。

まずは 明確に sandbox できるタスクから
社内検証用のファイル整理
ログ集約や簡易レポート作成
UI 変化が激しい SaaS 画面からの情報抽出など
影響範囲が限定され、
データ消えても痛くない / バックアップがある
誰かが最後に目視で確認できる
こういう領域から始めるのが現実的です。

逆に、いきなり本番システムの管理コンソールを触らせるのは、
よほどセキュリティ設計に自信がない限り、やめたほうがいいです。

6-2. 「採用する会社」と「まだ様子見の会社」の線引き

自分なりに線を引くとこうなります。

いま採用していい会社：
既にコンテナ/VM を前提に業務プロセスを組んでいる
監査ログや権限管理が「SaaS 標準」レベル以上に整っている
RPA や手作業オペレーションがボトルネック化していて、
多少コストを払っても自動化したい圧が強い
正直まだ様子見したほうがいい会社：
「プロンプト設計」がメインスキルで、
インフラ/セキュリティは外注任せ
現場の IT ガバナンスが緩く、
ログや権限周りがなんとなく運用で回っている
そもそも人手でもそんなに困っていない

ぶっちゃけ、Computer Use は「魔法の自動化ボタン」ではなく、
“LLM オペレーターを安全に雇うための重厚な基盤”です。

その基盤を作る体力がある組織にとっては、
- RPA の保守地獄から抜ける強力なカード
- 「最後の 20% の実務作業」を本当に AI に渡すための入口

になり得ます。

一方で、そこまでの体力がない現場にとっては、

コストも
セキュリティも
運用のしんどさも

全部一気に跳ね上げるリスクのほうが、現状では大きいと感じています。

まとめ：いま押さえておくべき「3つの視点」

最後に、技術者目線で GPT-5.4 Computer Use を評価するなら、
この 3 点だけは押さえておいて損はないと思います。

① 何が本当に新しいのか
LLM に「API を呼ばせる」のではなく、
OS そのものを“継続的に”操作させるインターフェースが出てきた。
② 開発者の役割はどう変わるのか
プロンプト設計より、
Sandbox / 権限 / 監査 / ロールバックをどう設計するかが重要になり、
いわば「AI オペレーター用の業務環境を作るインフラエンジニア」に近づく。
③ どこまで踏み込むかをちゃんと決める
すべてを Computer Use に任せるのではなく、
どの領域を OS レベルに委ね、どの領域は従来 API / バッチ / 人間に残すのか、
事前に線を引いておかないと、コストもリスクも制御不能になる。

正直、プロダクションの「コア業務」にいきなり投入するのは、
まだ様子見だと思います。

ただ、「RPA と人力で目をつぶってきたグレーゾーン」を
一気に片付けられるポテンシャルがあるのも事実です。

既にコンテナと監査の土台があるチーム
RPA の限界を痛感している現場

から順番に、この“仮想オペレーター”を試していくのが、
2026 年の現実解かなと感じています。

GPT-5.4 Computer Use 実践レポート

GPT-5.4 Computer Use 実践レポート