技術 約9分で読めます

CLIからAIへ、人間がソフトウェアと話す入口が変わる

AI CLI UI UX AIエージェント
いけさん目次

DEV Community に出ていた 原典記事 は、パンチカードからCLI、GUI、Web、モバイル、チャットボット、LLMエージェントまでを「人間と機械の会話」の歴史として並べている。
原典の一番おいしいところは、GUIがCLIを殺したわけではなく、AIもGUIやCLIを消すわけではない、という見方だと思った。

いま起きている変化は、入力欄が自然言語になったことだけではない。
人間が「何をしたいか」を書き、AIがCLI、API、ブラウザ、IDE、MCPツールへ落とし込む。
ソフトウェアの入口は柔らかくなったが、実行面ではむしろテキストで機械が読める層の価値が上がっている。

AIはGUIの次ではなくCLIの上に乗っている

原典は、CLIを「厳密な文法を覚えた人だけが使える会話」として扱っている。
cp source.txt /destination/ のように、少しでも構文を外すと通じない。
GUIはこの硬さを隠し、ファイル、ボタン、メニュー、ウィンドウという視覚的な対象に置き換えた。

ただ、現在のAIエージェントを見ると、裏側ではCLIがむしろ濃くなっている。
Claude Code、Codex、Copilot CLI、Cursorのクラウドエージェントは、自然言語の依頼を受けても、実際には git、pnpm、gh、docker、kubectl、各種MCPツールを呼ぶ。
ユーザーは文法を覚えなくてよくなったが、エージェントは文法が明確な道具を必要としている。

この構造は、CLI-AnythingであらゆるソフトウェアをAIエージェント対応にするで見た話とかなり近い。
CLI-AnythingはGIMPやBlenderのようなGUIソフトウェアから、エージェントが叩けるCLIハーネスを生成する。
人間にとってはGUIのほうが自然でも、エージェントにとっては --json と安定したサブコマンドのほうが扱いやすい。

graph TD
    A[人間の自然言語] --> B[AIエージェント]
    B --> C[CLI]
    B --> D[API]
    B --> E[MCPツール]
    B --> F[GUI操作]
    C --> G[実ソフトウェア]
    D --> G
    E --> G
    F --> G

この図で見たいのは、AIが一番上の入力面を柔らかくしているだけで、下の実行面は複数の古いインターフェースをそのまま使っている点だ。
CLI、API、GUI、MCPは競合するというより、AIが選ぶ実行経路として並ぶ。

文法を覚える人から、結果を検査する人へ

CLI時代の負担は、コマンド名、引数、順序、パス、引用符、終了コードを人間が覚えることだった。
GUI時代の負担は、どこに機能が隠れているかを探し、画面の流れに沿ってクリックすることだった。

AIエージェント時代の負担は少し違う。
人間は細かい操作を覚えるより、エージェントの実行結果が正しいかを検査する側に回る。
コードならdiffを読む。
デプロイならログとロールバック条件を見る。
デザイン修正ならブラウザ表示とソース差分を見る。

Cursor 3はIDEをエージェントの管制塔に作り替えたで書いた通り、IDEも「人間がコードを書く場所」から「複数エージェントの作業を監督する場所」に寄っている。
Cursor 3のAgent Tabsやクラウドエージェントは、エディタというより作業キューとレビュー画面に近い。

ここで効いてくるのは、AIの文章力ではなく検査可能性だ。
エージェントが「修正しました」と返しても、差分、テスト結果、スクリーンショット、実行ログがなければ信用できない。
自然言語の入口が便利になるほど、出口側には機械的に検査できる証拠が要る。

エージェント向けCLIが増えている理由

最近の公式ツールを見ると、単に人間向けCLIを整備しているだけではない。
エージェントが読むことを前提に、構造化出力、スキーマ、dry-run、権限制御、監査ログを持つCLIが増えている。

Google Android CLI v0.7プレビュー公開、エージェント向けにandroid createやskillsを整備では、GoogleがAndroid開発の操作を android コマンドに寄せ、SkillsやKnowledge Baseまで合わせて出してきた。
Android Studioの画面をAIに見せるより、公式CLIと公式Skillを読ませるほうが、トークンも失敗経路も減る。

SwitchBot公式CLI @switchbot/openapi-cli が登場、MCPサーバーとMQTTストリームでAIエージェントから家電操作も同じ流れだ。
人間向けの色付きテーブル、スクリプト向けのJSON、エージェント向けのMCPサーバーを同じバイナリに載せている。
さらに --dry-run、監査ログ、破壊的操作のガードがある。
これは「AIから呼ばれるCLI」に必要な部品が、かなりはっきりしてきた例だ。

原典は「CLIは死ななかった、勝った」と書いている。
この言い方は少し強いが、少なくともエージェント時代にCLIが見直されているのは確かだ。
画面上のボタンは人間に優しい。
でもAIに作業を任せるなら、ボタンの裏にある操作が名前付きコマンドとして露出しているほうが強い。

GUI操作モデルは最後の逃げ道ではない

とはいえ、すべてをCLIに寄せればいいわけでもない。
画面の状態を見ないと判断できない操作は残る。
フォームの崩れ、ドラッグ操作、デザインレビュー、ブラウザゲーム、既存アプリの自動操作は、GUIを直接扱うモデルのほうが自然な場面がある。

UI-TARS-1.5-7B: GUIグラウンディングでSOTAを達成したVision AIエージェントや、1100万時間の動画で学習したFDM-1と50倍効率のビデオエンコーダは、まさにこの側の進化だ。
スクリーンショットや動画からUI状態を読み、マウスやキーボード操作を予測する。
CLIやAPIがない対象でも、人間と同じ画面を見て動ける。

ただし、GUI操作モデルは便利な万能レイヤーではない。
画面解像度、アクセシビリティ情報、座標変換、アニメーション、モーダル、ログイン状態に左右される。
同じ処理を100回繰り返すなら、GUIをクリックするよりCLIやAPIを叩くほうが速く、記録も検証もしやすい。

エージェントに渡す入口は、対象ごとに変わる。
人間が見て判断する部分はGUI、繰り返し実行する部分はCLI、状態を問い合わせる部分はAPI、外部ツール連携はMCP。
AIはそれらを束ねる上位レイヤーであって、全部を自然言語だけに溶かす存在ではない。

会話できるソフトウェアほど境界が要る

原典では、2015〜2016年ごろのチャットボットが「決定木にテキスト入力を被せただけ」で失敗した、と整理されている。
これは今でもかなり大事な指摘だ。
自然言語入力があっても、裏側に実行可能な操作、状態取得、エラー処理、権限境界がなければ、ただの曖昧なフォームになる。

StripeのMinions記事を読んだときも、そこが一番印象に残った。
StripeのAIコーディングエージェント「Minions」の内部アーキテクチャ詳解では、Devbox、Blueprints、Toolshed、CI反復の上限が明確に分けられていた。
自然言語でタスクを渡せることより、どの環境で、どのツールを、何回まで、どの権限で実行できるかが設計の中心になっている。

ソフトウェアが「会話できる」ようになるほど、設計対象はUIだけでは済まなくなる。
人間向けには自然な依頼文を受ける。
エージェント向けには構造化された道具を出す。
運用向けにはログ、権限、dry-run、ロールバック、テストを残す。
この並びが揃っていないと、AI対応はただのチャット欄で止まる。

原典の歴史整理は抽象的だが、今の開発現場に引き寄せると見え方はかなり具体的になる。
AI時代のインターフェース設計は、自然言語UIを足す話ではなく、ソフトウェアの操作面を人間にもエージェントにも読める形で出し直す話だ。

GUIの対比がCLIになった経緯

GUIの反対語として、日本では「CUI」が定着している。
Character User Interfaceの略で、文字ベースの操作画面という意味だ。
ところが英語圏ではCUIはほとんど使われない。

英語圏でのテキスト操作画面の分類は、CLI（Command Line Interface）とTUI（Text User Interface）に分かれる。
CLIはコマンドを打って結果を受け取る対話形式。
TUIはncursesやhtopのように、テキストで描画されたメニューやウィンドウを操作する形式だ。
日本語のCUIはこの両方を包含するが、英語圏ではその包括語自体が浸透しなかった。

AIエージェントの文脈でCLIが前面に出てくる理由もここにある。
エージェントにとってTUIは人間向けの視覚的レイアウトであって、GUIと同じく直接操作には向かない。
htopは人間には見やすいが、エージェントがプロセスを殺すなら kill コマンドのほうが確実で速い。

エージェントが必要としているのは文字画面ではなく、名前付きの操作と構造化された出力だ。
だからCUI（文字ベースの画面全般）ではなく、CLI（コマンド行インターフェース）が単位になる。

MCPとCLI、コンテキスト消費の差

この記事ではエージェントの実行経路としてCLI、API、MCPを並べたが、実際の使い分けで効いてくるのがコンテキストウィンドウの消費量だ。

MCPツールは、ツール定義のJSONスキーマがモデルのコンテキストに載る。
サーバーに10個のツールがあれば、10個ぶんの名前、パラメータ、説明がシステムプロンプトに展開される。
ツール定義だけで数千トークンになることは普通にあるし、実行結果もコンテキストに戻ってくる。

一方、CLIはシェルツールの定義が1個あればどんなコマンドでも叩ける。
git status でも docker ps でも、ツール側のスキーマは「コマンド文字列を受け取って実行する」の1つだけだ。
ツールが増えてもコンテキスト消費は増えない。
出力もstdoutのテキストがそのまま返る。

ここだけ見るとCLIのほうが圧倒的に軽い。
ただしCLIには、正しいコマンドとフラグをモデルが「知っている」前提がある。
git や npm のように学習データに大量に含まれるツールなら問題ないが、社内ツールやニッチなCLIだとモデルが構文を間違える。

MCPのスキーマ定義はこのギャップを埋める。
パラメータ名、型、必須か任意か、説明をJSON Schemaで渡すので、モデルが呼び方を推測する必要がない。
SwitchBotのCLIが --json とMCPサーバーを同じバイナリに載せたのは、CLI側の軽さとMCP側の発見性を両立させる設計だった。

もう一つ見えてきた問題がある。
MCPサーバーの数が増えすぎると、使わないツールの定義だけでコンテキストが埋まる。
Claude CodeがMCPではなくシェル経由のCLI実行を基本にしているのは、汎用エージェントにとってコンテキスト効率が優先だからだろう。
MCPは「このエージェントが確実に使うツール群」に絞って接続するのが、現実的な落としどころになる。

自分の運用だと、CLIをデフォルトにして、モデルが構文を外すツールだけMCPに切り替える方式に落ち着いている。
gitやdockerをMCP経由にする理由はないし、逆に社内APIやIoTデバイスの操作をCLIだけで叩かせるとパラメータの組み立てで失敗する。
迷ったらまずCLI、精度が足りなければMCP、という順序で試すのが手っ取り早い。

参考