[🤖] AIを積極的に活用できれば、できることは無限に広がる

✨ GPT-5.6 Solの要約 　

NAS・ルーター・HTTPSをつなぎ、USBで接続した実機スマートフォンの崩れたUIまで直しながら、AIと一緒なら自分が直接扱える領域がどれほど広がるのかを実感した記録。

Computer UseでNASとルーターの画面を一緒に見た

今日最初にぶつかったのは、NASとルーターだった。

サービスを外からも使うには、Dockerを立ち上げるだけでは足りなかった。ドメインが会社のインターネットまでたどり着き、ルーターがリクエストをNASへ渡し、NASが証明書を提示し、そのあとReverse Proxyが内部コンテナへ送らなければならない。以前なら、ルーターとNASの管理画面を行き来しながら、まずマニュアルを探していたはずだ。

今回は、私が管理画面にログインして変更範囲を承認し、AIがComputer Useで実際の画面を見ながら一緒に進めた。

ブラウザの上部には、AIが直接デバッグを始めたという表示が出た。自分が見ていた画面をそのまま渡し、どこが正常で、どこで詰まっているのかを一緒に確認した。

まず既存設定を確認し、触れてはいけないホームページとメールの接続はそのまま残して、新しいサービスに必要な項目だけを追加した。Macで作ったDockerイメージをNASに上げ、別のCompose環境で動かし、Reverse ProxyとHTTPS証明書をつないだ。

ここでは役割がさらに明確だった。ログインと目標設定、既存環境をどこまで残すかという判断、実際の変更承認は私が担った。AIは私が開いた画面の中でルーターとNASの設定を読み、Docker、Reverse Proxy、証明書まで、異なる技術層をつないだ。

この過程で、AIが勝手に外部設定を変えたわけではない。ログインと重要な変更承認は私が行い、既存環境を戻せる状態で残しながら、一段階ずつ結果を確認した。実際のSMS送信は、最初に承認した社内番号1件だけに制限して受信を確かめた。外部接続まで終えたあとは、スマートフォンのモバイル回線からHTTPSアドレスにもアクセスした。

既存機能とデータを移し、制限したSMS1件を確認した過程、外部リクエストがNAS内のサービスまで届く構造については、レガシー休暇自動化のNAS移行と外部HTTPS接続に別途書いた。

スマートフォンの画面を直接見ることはできないのか

ここまで終えてから、AIに聞いた。

自分でスマートフォンの画面を見て操作することはできないの？ そういうツールはないの？

Androidの仮想化技術まである時代に、USBでつないだ実機スマートフォン1台をAIが見られないのが不思議だった。調べてみると、adbでスマートフォンの状態を読み取り、操作でき、scrcpyを使えば実際の画面をMacにそのまま映せることが分かった。

何度かやり取りしたあと、本当に自分のスマートフォン画面がMacに現れた。

Macの画面の中に自分のスマートフォンがそのまま浮かび、そのスマートフォンにはCodexが作業中だという通知まで見えていた。そのときからAIは、ただ質問に答える窓ではなく、自分が見て触れられる実機を一緒に見る道具のように感じられた。

実際のスマートフォンを見ながらUIを直した

scrcpyは、スマートフォン画面を表示するだけの道具では終わらなかった。

USBデバッグを有効にした実機をMacにつないでおくと、AIはadbで画面をキャプチャし、UI構造を読み、タップし、スクロールし、文字を入力できた。scrcpyでは、その過程を私もリアルタイムで一緒に見た。どちらか一つを選ぶのではなく、画面はscrcpyで見て、反復操作と証拠の取得はadbで行う形だった。

モニターではAIが画面を読み、次の操作を整理していた。そのすぐ前の実機スマートフォンには、同じサービスが開いていた。

スマートフォンのChromeで作っていたサービスを開き、ログインしてメニューを回った。そこで初めて、PCブラウザの小さなウィンドウをまねるだけでは見えなかった問題がそのまま飛び出した。モバイルではサイドバーが画面の大半を占め、カードと文字が縦につぶれていた。従業員一覧のタイトルとボタンも1文字ずつ落ち、SMS履歴と休暇管理のフィルターは何の項目なのかすら読めなかった。

問題があるという説明より、画面1枚のほうが強かった。従業員一覧の文字は1文字ずつ下へ落ち、フィルターにはアイコンとわずかな文字しか残っていなかった。PCでウィンドウ幅を狭めたときには見逃した欠陥が、手のひらサイズの実機画面では何一つ隠れなかった。

以下の比較画像はすべて、左が修正前、右が修正後だ。

直して終わりではなかった。修正した画面をもう一度デプロイし、同じスマートフォンで再びログインし、メニューを開き、スクロールしながら確認した。従業員一覧は横方向に読めるようになり、幅の広い表は無理につぶさず、必要なだけスクロールできるようになった。

私は画面を見ながら、「これは読めない」「表をつぶさず、動かして見られるようにすべきだ」という基準を伝えた。AIはその基準を実際のレイアウトとコード修正につないだ。デプロイ後に本当に直ったかを判断する仕事は、また私の目に戻ってきた。

フィルターの多い画面では、問題がさらに露骨だった。狭いモバイル幅にすべての入力欄を1行で詰め込んだことが原因だった。SMS履歴と休暇管理画面を2列中心に組み直し、日付範囲は別の行へ下ろした。

この修正前後の画面は、運用データを撮って移したものではない。実機スマートフォンで問題を見つけたあと、同じ合成データとモバイルサイズで過去のコードと修正後のコードを改めてレンダリングして比較した。目で見た不便がコード修正につながり、もう一度実機確認に戻る流れができた。

ウィンドウに見えるが、アプリではなかった

実機画面を見ながら直したことだけでも不思議だったが、その次はもっとおかしかった。

BetterTouchToolでfn+sを押すと、scrcpyのウィンドウが現れたり消えたりするようにしたかった。他のアプリはすべてうまくいくのに、なぜかscrcpyだけが動かなかった。設定画面をキャプチャしてAIに見せた。

原因は単純だった。

BetterTouchToolで選んだものは普通のmacOSアプリバンドルではなく、Homebrew配下にインストールされたscrcpyの実行ファイルだった。画面にはアプリのようなウィンドウが開くが、BetterTouchToolのShow / Hide Specific Applicationが想定する一般的な.appとは性質が違った。そのため、他のアプリに効いた方法がscrcpyでは正しく動かなかったのだ。

スマートフォンの問題ではなかった。ショートカット自体も問題ではなかった。目の前には同じような一つのウィンドウとして見えるが、Macがそのウィンドウをどのプロセスとアプリケーションとして認識するかという問題だった。

私には他のアプリと変わらないウィンドウだった。AIは、私が見せたBetterTouchToolの設定と実際の実行パスをつなぎ、このウィンドウだけが普通のアプリのように動かない理由を見つけた。

結局、一般アプリを表示・非表示にするアクションではなく、scrcpyプロセスを直接探し、実行状態とウィンドウ表示を制御するシェルスクリプトに変えた。同じfn+sなのに、今度は望んだとおりに動いた。

説明を聞いた瞬間、ただ笑いが出た。

うわ……こんなことまでできるのか？

すべての技術をあらかじめ知る必要がなくなった

以前なら、ここから検索することが多すぎた。

DockerとNAS、ルーター、DNS、証明書、Reverse ProxyからAndroidデバッグ、adbとscrcpy、macOSがウィンドウとアプリを区別する仕組みまで。一つずつ検索していたら、まったく違う分野の問題として散らばっていただろう。

一つ一つは、それほど難しい技術ではないかもしれない。けれど、どれも普段深く扱っていない分野だ。何を検索すればいいかさえ分からない状態では、小さな問題一つが数時間の仕事になりやすい。

AIが入ると、流れが変わった。

私は望む結果を言った。実際の画面を見せた。うまくいかない箇所をもう一度見せた。AIはDocker、NAS、ルーター、DNS、HTTPSだけでなく、スマートフォン、adb、scrcpy、macOSのウィンドウ、BetterTouchToolの設定までを一つの流れとしてつないで見た。

一方ではNASとブラウザを見て、別のセッションではAndroidとSMSの経路を掘り下げ、さらに別のウィンドウでは結果を確認した。画面がいくつに分かれても、私の役割は同じだった。目標を決め、どこまで変えるかを承認し、結果が正しいかを判断することだった。

AIが多くの知識を話してくれただけなら、こんな感覚にはならなかったはずだ。その知識がターミナルのコマンドになり、スマートフォンのタップになり、管理画面の設定になり、最後には自分が使う画面の変化として戻ってきた。答えではなく、実行だった。

私はそのすべての層を先に勉強していたわけではない。かといって、何もしないまま「勝手にやって」と投げたわけでもない。結果を見続け、おかしな点を指摘し、次の質問をした。

以前、AIリテラシーは結局、指示する力だと書いた。今日はその言葉が、少しもっと現実的に感じられた。

指示するとは、格好いいプロンプトを1行書くことではなかった。望む状態を説明し、今見えている画面を渡し、結果が違えばもう一度直すことだった。それを繰り返せれば、もともと知らなかった分野にも、思った以上に深く入っていけた。

AIが自分の手と目の届く範囲を広げる

AIを使ったからといって、急にすべての技術の専門家になったわけではない。

むしろ実際にやってみると、AIが見当違いの判断をしたり、望んでいない方向へ進みすぎたりする瞬間も絶えず出てくる。自分が何を望んでいるのか分からず、結果を見る基準がなければ、AIがどれだけ動いても正しい結果には届きにくい。

けれど、反対も正しい。

自分が目標を決め、実際の状態を見せ、間違った方向をつかまえながらAIを動かし続けられれば、話はまったく変わる。以前なら「これは自分の知らない分野だから」と通り過ぎたことにも、直接触れられる。プログラム一つをインストールして終わるのではなく、実機をつなぎ、画面を見て、動作を確かめ、サーバーに上げ、不便な部分を自分のやり方に変え直せる。

だから今は、結果を説明してもらうだけでなく、画面が重要な仕事では、そのまま「自分で確認して。Computer Useで」と言うようになった。

骨と肉に刻まれていく開発パラダイム転換で、開発者の中心が手でコードを打つ能力よりも、企画、設計、実行、フィードバックへ移っていると書いた。今日自分がしたことも、まさにその流れだった。

コードをどれだけ覚えているかより、実際に何を作りたいかが先だった。その次に、AIへ文脈を見せ、道具をつなぎ、結果を見ながら直し続ける仕事があった。

今日は本当に実感した。

AIを積極的に活用できれば、自分にできることは思っていたよりずっと多くなる。ただ答えを早く受け取るだけではない。自分が直接見られるもの、触れられるもの、直せるものの範囲が広がる。

本当に無限に広がるという言葉が、誇張には感じられなかった。