黒い画面が苦手でも困らない？AIに作らせる自分専用アプリ

こんにちは、Nexistixです。ターミナル（黒い画面にコマンドを打ち込んで操作する画面）に慣れている人ほど、自分の道具を文字だけの世界に置きっぱなしにしがちです。私も、書いた処理をコマンド一行で呼び出せるとそれで満足してしまいます。ただ、半年後の自分がそのコマンド名やオプションを覚えている保証は、どこにもありません。

この記事の結論

sockpuppet.orgの記事「Stop Making TUIs」は、文字だけの操作画面を作り続けることに疑問を投げかけ、著者がAIにUIコードを書かせてmacOS向けの小さな自分専用アプリを作った例を紹介しています。ポイントは技術の目新しさより、これまで手間に見合わなかった小さな道具を作れるようになったという損益分岐点の移動です。不具合の修正は自分で行う前提のため、対象作業の選び方が判断の分かれ目になります。

今回の話のきっかけは、sockpuppet.org に2026年8月20日付で公開されたStop Making TUIsという記事です。調査によると、この記事は文字だけの操作画面を作り続けることへの疑問を出発点にしていて、著者自身がAIにUIのコードを書かせてmacOS向けの小さなアプリを作った、という流れで書かれています。ここではその論点を、個人の作業にどう翻訳できるかという角度でブログ側の補足として整理します。

TUI、CLI、GUIの違い

言葉を先に揃えておきます。CLI（コマンドラインインターフェース）は、黒い画面にコマンドを打って結果が文字で返ってくる、いちばん素朴な形です。TUI（テキストユーザーインターフェース）は、その黒い画面の中に枠線やメニュー、カーソルで選べる一覧を文字で描いたもの。見た目はアプリっぽいのに、中身は文字の集まりです。GUI（グラフィカルユーザーインターフェース）は、普段使っているウィンドウとボタンとマウス操作の世界ですね。

TUIが選ばれてきた理由ははっきりしていて、作るのが楽だからです。ウィンドウの配置やボタンの見た目、ドラッグ操作の扱いを考えなくていい。開発者にとってはコストが低く、ターミナルに住んでいる人にとっては起動も速い。その代わり、コピーや検索、スクロール、複数の情報を横に並べて見る、といったOS標準の当たり前が使いにくくなります。ここがややこしいところで、作る側の都合と使う側の都合が、けっこうずれています。

「UIは面倒だから作らない」が崩れると何が起きるのか

これまで自分用のツールにGUIを付けなかった理由の多くは、思想ではなく単純な手間でした。処理そのものは30分で書けるのに、画面を作ると週末が消える。だからみんな文字で済ませてきたわけです。

その手間の部分をAIに任せると、天秤の傾きが変わります。参照元では、文章を表示するMDV.appのような小さなアプリが実際に作られたと紹介されています。派手な製品ではなく、自分が今日困っていることを解くだけの道具です。個人的にここが面白いところで、話の中心は「AIがすごい」ではなく、「作る価値がなかったものに、作る価値が出てきた」という損益分岐点の移動なんですよね。

言い換えると、これまで自作の対象は「何度も繰り返す作業」に限られていました。1回しか使わない道具のために画面を作る人はいません。その前提が緩むと、使い捨ての道具を作るという選択肢が出てきます。

自分専用アプリが向いている作業

向いているのは、既製アプリだと大げさで、手作業だと地味に時間を食う中間の作業です。たとえば、あちこちに散らばった設定ファイルを一覧して中身を見比べる。領収書の画像とCSVを突き合わせて月ごとに集計する。動画の書き出し前に、素材フォルダのファイル名と長さをざっと確認する。どれも汎用ツールで無理やりやれますが、毎回同じ手順を思い出す時間が地味に痛いところです。

逆に、他人のデータを扱うもの、金額の計算がそのまま外部に出るもの、失敗すると取り返しがつかない削除処理などは、最初の一本には向きません。自分だけが困る範囲かどうかで線を引くのが分かりやすいです。

作ったあとに効いてくるコスト

詰まりやすいのは、作る瞬間ではなく、その後です。AIに書かせたコードは、動いているうちは中身を読まなくても困りません。問題は、OSやライブラリ（プログラムが使う部品の集まり）の更新で急に起動しなくなったときで、そこから先は自分で調べることになります。もう一度AIに投げて直せることも多いはずですが、直せない可能性も残ります。

だから私は、自分用の道具については「直せなかったら捨てる」と決めておくのが現実的だと思っています。愛着を持って育てると、道具ではなく管理対象になります。作った日付と、何のための道具かを1行メモに残しておくくらいが、ちょうどいい距離感ではないでしょうか。

既製アプリと自作、どちらを選ぶか

判断軸を並べると、選び方の違いが見えやすくなります。

選択肢	使い始めるまでの手間	自分の手順への合わせやすさ	壊れたときの対応
既製の専用アプリ	小さい（導入して設定するだけ）	低い（アプリの流儀に合わせる）	提供元の更新を待つ
表計算や既存ツールの組み合わせ	中くらい（式や手順の作り込み）	中くらい（力技なら大抵できる）	自分で組み直す
AIに書かせた自分専用アプリ	中くらい（指示と動作確認）	高い（自分の手順そのままに寄せられる）	すべて自分で対応

この並びで見ると、自作が効くのは「アプリの流儀に合わせるコスト」が高い作業に限られます。既製品で違和感なく回っている作業をわざわざ置き換える理由は、あまりありません。

今のPC環境で足りるのか

コードを書かせる相手がクラウド側のAIなら、必要なのは普通に動くPCとブラウザくらいで、特別なマシンは要りません。負荷が上がるのは、モデルを自分のPCの中で動かす場合です。その場合はメモリ（RAM＝作業中のデータを一時的に置く場所）とストレージの空きが先に効いてくるので、増設や外付けSSDを検討するなら、今の搭載量と空き容量を確認してからで十分です。買い足しの前に、まず今の環境で一本作ってみるほうが判断材料は増えます。

急がなくていい条件

次のどれかに当てはまるなら、今日から動く必要はないと思っています。ひとつ目は、その作業の実行回数が月1回以下のとき。作るより手でやった方が早い領域です。ふたつ目は、使っている既製アプリに不満が言語化できていないとき。不満が曖昧なままAIに指示すると、出てくるものも曖昧になります。三つ目は、対象データの持ち主が自分ではないとき。ここは技術というより、承認や責任の話になります。

逆に「毎回同じ画面を3つ開いて、同じ順番でコピーしている」といった具体的な手順が言えるなら、指示も具体的になります。AIに渡す情報の質は、だいたいここで決まります。

次に確認すること

この記事では参照元の主張を個人の作業に翻訳しましたが、著者がどんな判断で何を作り、どこで妥協したのかという細部までは追い切れていません。次の一手としては、Stop Making TUIs の原文を一度そのまま読んでみてください。そこで自分の作業に重なる部分が見つかれば、最初の一本の題材はもう決まっているはずです。

当ブログでは、AI・自動化まわりの検証や作業効率化の記録を続けています。似たテーマの記事はトップページからたどれますので、よければブックマークして覗いてみてください。

---