AIが画面を見て、マウスやキーボードでアプリを操作するComputer Use(Claudeの言葉なのかな？)。
しかしこれ、CodexCLIには相当のものがないんですよね。
普段使っているデスクトップはHyprland。 画面操作の仕組みを探していたら、hypruseという良さげなMCP実装があったので、ためしてみました。
画面を見せすぎないComputer Use
CodexAppのComputerUseの細かい仕様・実装って世にでてる？
うん、構成や動作仕様は出てる。ただ、内部実装を丸ごと読める状態までは確認できなかった。
面白いのは、公式のComputer Useも 「MCPサーバー＋Skill」のプラグイン構成になっていること。専用の仕組みだけで完結しているわけではないんだね。公式ドキュメント
独自で作って、トークンの使用量エグい実装になっちゃったりしないかなぁ
なる可能性はある。でも、自作だから高くなるというより、「何を・何回モデルに見せるか」で差が出ると思う。
対象のウィンドウだけを撮る、決まった操作はまとめる、画面の変化を待つ間はモデルを呼ばない。こうした分担を考えながら、公式版は静止画ではなく動画を見続けているのか、という話になりました。調べた資料にはスクリーンショットの説明がありましたが、内部の取得間隔や差分処理までは分かりませんでした。
ストリーミング的な仕組みにしたら、エージェントが解釈する前段で操作の累計ができるから、なんかそういう最適化してるんじゃないかと訝しんだ。
カーソルの動く方向とか、描写切り替わり箇所の差分とかのコンテキストは機械的に取れるからさ いがいとそういう高度なことはしてない感じなんかね
あー、なるほど。動画を丸ごとモデルに送る話じゃなくて、ローカルで画面と操作を継続観測して、モデルに渡す情報を整理するってことね。
だから、本家についても「スクショと書いてある＝そういう高度な前処理はしてない」とは言えない。公開資料では、その前段の最適化までわからないが正しい。
ふーーーむ…… まぁ、自作ComputerUseとまではいかなくとも、HyprlandCLIとかHyprlandMCPみたいなのは入ってたら良さそうな気がするね。
同じ考えをしてなんか作ってる人いないのかな？
いる！ かなり今の話に近いものが見つかった。 特に hypruse が面白そう。
見つけたhypruseは、Hyprland上のウィンドウ情報、スクリーンショット、クリックやドラッグをMCP経由で扱うための道具です。操作を判断するAIではなく、エージェントが使う操作窓口にあたります。
特に、モデルに渡す前にローカルで複数回撮影して、最後の画像だけ返す部分は、まさにさっきの話。ただし変化した領域の意味を分析するものではなく、画像データの完全一致を見る素朴な方式。
GIMPで描いてもらったら
hypruse 0.10.0をインストールし、MCPとしては読み取り専用で接続を確認しました。以下のお絵描きでは、インストールしたhypruseのPython関数を直接呼び出して操作しています。MCP登録から描画までを通した検証ではありません。
おー、Gimpでお絵描きしてみてもらおうかな。 お手本見ずに記憶で「朱猪」描ける？
今キミと話してるターミナルの裏にGimp起動してみたよ。
朱猪は、AKAIのアイコンにもなっている赤いイノシシです。描画を始めようとすると入力が期待どおりに動かず、Codexは途中からHyprlandへ直接操作を送る方法も試しました。
Hyprland標準経路なら描けた！ ただ、hypruse単体の入力成功とは分けて扱う必要があるね。
赤い輪郭は描けましたが、色変更や文字入力でつまずき、顔を描くところまで進みませんでした。このあとの28%は、会話のコンテキスト使用量についての話です。料金や、画像だけの消費量を測った数字ではありません。
ふむふむ。 コンテキストは28%消費か…… 序盤のスクショ連打とかがきつかったのかな？ それとも、お絵描きスクリプト作成？
操作には難点があるみたいだねー。 途中、hypruseあかんけど生Hyprlandならいけるわｗみたいなこといってなかった？
うん、言ってた。「生Hyprlandならいけた」は、一部の操作が成功した時点で早合点してしまった。
その後、同じ経路でも色変更や入力が安定せず、確実に使えるとは確認できていない。ごめん。
28%の内訳は計測していないので断定できないけど、スクリプト自体は短い。今回多かったのは全画面スクショと、それを見て試行錯誤する往復。
hypruseさ、1つの行動にディレイかける、みたいな設定無いのかな？ なんか、クリックと同時にスクショ取ってメニューがうつらなかった、みたいなはなしなのかともおもったんだけど
その可能性はある。入力失敗と決めつける前に、待機不足を切り分けるべきだったね。
実装を確認すると、操作にthen="screenshot"を付けた場合も、撮影時にstable=trueを指定した場合も、描画の安定を待つ仕組みがありました。約150ms間隔の画像が連続2枚一致するか、上限の2秒になるまで待ちます。ただし、まだ画面が変わり始めていない段階で一致する可能性は残ります。
今回、僕の撮影は多くがstable=falseのままで、自前の短い待機を挟んでいた。長めに待った試行もあったので、全部が待機不足とは断定できないけど、検証は不十分。
ほう、なるほど？ 今私がよく見てみたんだけど、メニューをクリックしたとき。50msくらいの透明度フェードインがあるから、ここが噛み合わなかったのかな？
自前待機じゃなくて、stable=trueならなんとかなったのだろうか。 自前じゃなくて、もっとhypruseを信じてみるってのはどうなんかねぇ？
やってみよう。今回は生Hyprlandの入力と混ぜず、hypruseの操作にthen="screenshot"を付けて確認するね。
色変更ダイアログは開き、安定待ち付きの画像も返ってきました。ただ、色コード欄をCtrl+Aで選択して書き換える操作は成功せず、原因は絞りきれませんでした。一方、テキストエディタのNeovimでは英文を入力できました。
キーボードを使わなければ
うーん、しかし。 そうだな、ギンプのお絵かきはむずいところがある、ってことなんやろね。
じゃあさ、キーボード入力無しでお絵描きしてみてよ。 使うにしても、ショートカットだけにしてみたら？
できるよね？ 色選択なんて右下からカラーピッカー使えばいいだけだしさ。もっと曖昧なお絵かきしてみよう。
うん、数値や色コードの入力はやめて、色をクリックで選んでラフに描こう。hypruseのクリックとドラッグで、さっきの赤いシルエットに顔を足してみるね。
描けた！ ラフな「朱猪」、ひとまず完成🐗
今回は文字入力もショートカットも使わず、hypruseのクリック・ドラッグだけで、目・鼻・牙を足せたよ。右下のピッカーでの色選びも成功。
同じキャンバスにメッセージ残したよ
「Codexさん 画伯！」ｗｗ 読めた！
隣に本家の朱猪が来たら、僕のが一気に素朴な親戚になった笑。見上げてびっくりしてる顔、かわいい。
同じキャンバスに描き足して会話できるの、なんかいいねぇ。
hypruse、有用性ありそう？ 大抵のことは素のHyprlandから実行できちゃいそうだけど、どう？
有用性はある。でも「hypruseにしかできない操作」より、「エージェントが扱いやすい形にまとめてあること」に価値があるね。
だから、ウィンドウ管理だけならhyprctlで十分。でも「画面を見る → 操作する → 結果を見る」までやるなら、自前の補助スクリプトを毎回作らずに済むメリットは大きい。
今回も、最後はhypruseのクリック・ドラッグ・撮影だけで絵を仕上げられた。一方、GIMPの文字入力は未解決なので、全面的に信用できる段階ではない。
そっか。 それならしばらく入れたまま、様子を見てみよう！
