先日、ものすごく小さな不満があった。
Macに外部ディスプレイをつないでいる。MacとはUSB-Cで接続していて、同じディスプレイのHDMIにはブルーレイレコーダーをつないでいる。だから、
- Macを使う → USB-C
- テレビを見る → HDMI
と、ディスプレイの入力を切り替える必要がある。
問題は、そのディスプレイの物理ボタンがものすごく押しにくいことだった。高級ディスプレイでもない。リモコンもない。毎回ディスプレイの下に手を伸ばして、小さなボタンをカチカチ押す。
たいした問題ではない。たいした問題ではないからこそ、何年もそのまま使うことになる。
そこでChatGPTに聞いてみた。
Macから、この入力を切り替えるのは無理なの？
すると、DDC/CI（パソコンからモニターに命令を送るための仕組み）を使えば、モニターによってはMacから入力ソースを変更できるという。そこで次に言った。
いや、君に作ってほしい。
ここから話がおかしくなってくる。
Table of contents
数時間前まで存在しなかった「自分専用アプリ」
できたのが「InputSwitch」というMacアプリだ。メニューバーから、
- USB-Cへ
- HDMIへ
- モニターの消音
- 音量変更
- 画面オン／オフ
などを操作できる。
HDMIへ切り替えたときは、そのディスプレイをMacのデスクトップから切り離すこともできる。これが意外と重要だ。
映像だけブルーレイに切り替えても、Macからするとディスプレイはまだ接続されている。すると、見えない画面の向こうへウインドウやマウスポインターが行ってしまう。そこでInputSwitchは、
- HDMIへ切り替える
- Macからその画面を外す
- USB-Cへ戻す
- Macにも再接続する
ところまでやる。
ここまで来ると、もう「入力切替アプリ」ではない。完全に、私の机専用の装置である。
安いモニターは、仕様書通りに動かない
面白かったのは、ここからだった。
一般的な規格では、モニターの入力ソースには番号が割り当てられている。ところが実際に私のディスプレイで試してみると、素直に動かなかった。
読み取った値と、書き込んだときの動作が合わない。ある値を送るとHDMIへ行き、別の値を送るとUSB-Cへ戻るのだが、どうも規格上の意味と実際の挙動が逆なのである。さらに、切り替え直後は命令を受け付けなかったり、別のディスプレイ制御アプリとの通信が混ざったりする。
普通の市販アプリなら面倒なケースだと思う。世界中のモニターで動くようにしなければならないからだ。
でも、私には関係ない。私のモニターで動けばいい。
そこでClaude Code（プログラムを読んで直接書き換えてくれるAI）にも、アプリのソースコード一式を渡して、実機の結果を見ながら修正していった。
「この値を送ったらHDMIになった」
「戻らない」
「今度は戻った」
「このモニターでは値が逆に作用しているようだ」
そんなやり取りを繰り返す。最終的には、モニターごとに「実際に効いた値」を記憶して、次からそれを優先して使うようになった。
つまり、規格だけを信じるのではなく、私の机にある実物に合わせてアプリそのものを変えた。これが市販ソフトとの大きな違いだと思う。
ついでにブルーレイまで操作させた
入力切替ができるようになると、人間は欲が出る。
HDMIに切り替えたあと、今度はブルーレイレコーダーのリモコンを探すのが面倒になった。だったら、これもMacから操作できないのか。
調べていくと、私が使っているPanasonicのDIGAにはLAN経由で操作できる仕組みが残っていた。そこでInputSwitchはさらに膨らんだ。
Macのメニューバーから地デジやBSのチャンネルを変更し、電源を操作し、再生・停止・一時停止・10秒戻し・30秒送り・早見再生までできる。録画番組一覧もMacに表示する。さらに番組表を取得して、「今このチャンネルで何を放送しているか」まで表示するようになった。
最初の不満は、「モニターのボタンが押しにくい」だったはずである。
これが、生成AIのかなり便利な使い方だと思う
ChatGPTというと、文章を書かせる、検索する、要約する、質問する。そういう使い方がまず思い浮かぶ。
Claude CodeなどのコーディングAIになると、「プログラマーが開発を高速化するためのもの」というイメージがさらに強い。
でも、最近は少し違うと思っている。プログラミングをしない人ほど、「自分専用の小さなソフト」を作らせる使い方が面白い。
重要なのは、最初から仕様書を書くことではない。今回、私は、
「DDC/CIのVCP 0x60を使ったmacOSメニューバーアプリをSwiftUIで作ってください」
などとは言っていない。そんなことは知らなかったからだ。言ったのは、
MacとUSB-Cでつながっているモニターがある。HDMIにはブルーレイがつながっている。モニターの物理ボタンが押しにくい。Macから切り替えられない？
ほとんどこれだけである。
方法を考えるのはAI側でいい。人間が伝えるべきなのは、「何が面倒なのか」「最終的にどうなってほしいのか」の方だ。
「アプリを探す」から「アプリを作らせる」へ
以前なら、まずGoogleで「Mac モニター 入力切替」と検索して、対応アプリを探していただろう。見つからなければ諦める。見つかっても、自分のモニターでは動かない。設定項目が足りない。欲しい機能だけない。そこで終了である。
しかし生成AIによって、選択肢が一つ増えた。
「なければ、自分用に作る」である。
しかも重要なのは、このInputSwitchを私は販売するつもりがないことだ。このアプリはAppleの非公開APIも使うし、App Sandbox（アプリの動きを制限する安全装置）も切っている。DDCの挙動も私のモニターにかなり依存している。DIGAの操作も、私が使っている機種を実際に調べながら作った。
万人に配布するソフトとして考えれば、面倒なことだらけである。でも、一人のためのソフトなら、それでいい。ここが生成AIによるソフト開発の面白いところだと思う。
商売にならないソフトが、一番便利だったりする
これまでソフトウェアには、どうしても経済合理性が必要だった。開発には人件費がかかる。だから、ある程度多くの人が欲しがるものでなければ製品にならない。
「特定の安いモニターと、古いブルーレイレコーダーを使っている一人の人間のためのMacアプリ」など、普通なら誰も作らない。市場が小さすぎる。というより、市場が一人しかいない。
ところがAIによって開発コストが極端に下がると、この前提が変わる。
市場がなくてもいい。公開しなくてもいい。売れなくてもいい。自分が毎日10秒ラクになるなら作る。そんなソフトウェアが成立する。これは意外と大きな変化ではないかと思っている。
自分も試してみたい人へ
「面白そうだけど、プログラミングは分からない」という人のために、始め方を簡単にまとめておく。
用意するもの
- ChatGPTやClaude：まずは「どうすれば実現できるか」を相談する相手
- Claude Codeなどのコーディング用AI：実際にアプリを作り、動かしながら直してもらう相手
- 困っている“実物”：今回ならモニターとブルーレイレコーダー。試して結果を伝えるのは人間の仕事
最初のお願いは「困りごと」だけでいい
技術用語は要らない。今回の最初のお願いは、ほぼこれだけだった。
MacとUSB-Cでつながっているモニターがある。HDMIにはブルーレイがつながっている。モニターの物理ボタンが押しにくい。Macから切り替えられない？
あとは「動いた」「動かない」「こうなった」を正直に返していく。それだけで、AIの側がどんどん直していく。
気をつけたいこと
- 自分用だから許されることがある：非公開APIやサンドボックスの無効化は、自分のMacで自分の責任で使うから成り立つ。人に配るなら話は別
- 機械を操作するアプリは慎重に：いきなり大事な設定を変えるのではなく、一つずつ試して結果を確認する
- AIの説明をうのみにしない：今回のように「規格ではこう、でも実物は逆」ということは普通にある。最後に信じるのは実機の結果
AIに聞くべきは「何ができますか？」ではない
ChatGPTやClaudeを開いて、「何ができますか？」と聞いても、たぶんあまり面白くない。それよりも、
今日、自分が何にイラッとしたか。
を考えた方がいい。
- 毎回同じファイル名を変更している
- 毎朝同じWebサイトを開いている
- 同じ文章を何度もコピペしている
- 使っている機械の操作が一つだけ面倒
- 仕事で毎回同じ変換作業をしている
そういう、わざわざ人に相談するほどでもない不便。そこに生成AIをぶつける。
場合によっては、答えを教えてくれる。場合によっては自動化できる。そして今は、場合によっては、その場で専用アプリまで作れる。
「モニターのボタンが押しにくい」。そんなくだらないところからでもいい。むしろ、そのくらいの不満の方が面白い。
AI時代に価値が出てくるのは、壮大なアイデアだけではない。これまで我慢する方が安かった、小さな不便。そこが、次々にソフトウェア化できるようになってきた。
