2025 年から 2026 年にかけて、トップ AI 企業が相次いで同じカテゴリの製品をリリースした——CLI 形態の Agent ツールだ。
Anthropic はターミナル上で動く AI プログラミングアシスタント Claude Code を発表し、OpenAI は Codex CLI を、Google は Gemini CLI を発表した。この波の中で、注目に値するほぼすべての AI 企業がコマンドラインに賭けた。
これは直感に反する。コマンドラインは 1970 年代の産物であり、GUI の登場でコンピューターが大衆に普及し、今やモバイルインターネットでタッチ操作が当たり前になった。通常の論理では、技術の方向性はどんどん「ビジュアル化」「使いやすく」なるはずだ。なぜ AI の時代に、最も古い対話形式が復活するのか？
答えはノスタルジーではなく、工学的ロジックだ。
GUI は AI に優しくない
GUI は人間の視覚ナビゲーションのために設計されている。ボタン、ポップアップ、ドラッグ、ホバーエフェクト——これらのインタラクションパターンは人間の視覚的直感に基づいている。人間は画面を一瞥してボタンの位置をスキャンし、直感的に次の操作を判断する。この仕組みは人間にとって極めて自然で、ほぼ学習コストがかからない。
しかし LLM の動作原理はまったく異なる。LLM の入力はトークンであり、出力もトークンだ。その「思考」は言語空間で行われ、ピクセル空間ではない。
AI に GUI を操作させるということは、巨大な溝を越えることを意味する：
理解コストが極めて高い。 AI はコンピュータービジョンやアクセシビリティツリーを使って画面を「読み解く」必要がある——どのボタンがクリック可能か、入力フィールドはどこにあるか、今のポップアップは何を意味するか。これは AI の得意分野ではなく、むしろ余分な負担だ。
状態が暗黙的で予測不可能。 同じボタンでも、今日はクリックできて、明日はある条件で無効になることがある。この暗黙の状態は人間にとっては「文脈」だが、AI にとっては不確実性だ——「この操作はどの条件下で使えるか」を確実に推論できない。
操作が組み合わせられない。 二つの GUI 操作をパイプでつなぐ方法がない。「検索結果 → フィルタ → エクスポート」は GUI では三回のクリックであり、一体として渡したり、再利用したり、自動化したりする方法がない。
テストと検証が難しい。 AI が GUI 操作を実行した後、成功したかをどう確認するか？スクリーンショットを撮り、画面状態を解析しなければならず、フィードバックループ全体が遅くて脆い。
対照的に、CLI のあらゆる特性は AI のために設計されたかのようだ。
CLI が AI Agent に持つ三つの優位性
組み合わせ可能性（Composability）
Unix 哲学の核心は「各プログラムは一つのことだけをうまくやれ。プログラムが協調して動けるようにしろ」だ。
この数十年前の設計原則が、AI の時代に新たな意味を持つ。
CLI ツールは標準入出力で連携する。linkly search "React パフォーマンス最適化" | head -5 は検索結果を次のコマンドに渡せる。linkly search "アーキテクチャ設計" --json | jq '.results[].doc_id' はすべてのドキュメント ID を抽出して後続処理に使える。
AI Agent にとって、組み合わせ可能性とは複数のコマンドを連鎖させて複雑なマルチステップワークフローを構築できることを意味する。各ステップの出力は構造化テキストであり、次のステップが消費できる。GUI の「クリック → 待機 → スクリーンショット → 解析」ループはなく、クリーンな入出力だけがある。
予測可能性（Predictability）
各コマンドの動作は完全にパラメータで決まる。linkly search "データベース" --limit 10 を今日実行しても明日実行しても（データベースが変わらない限り）同じ結果になる。暗黙の状態はなく、「この機能が前は動いていたのに今は動かない」という混乱もない。
これは AI にとって極めて重要だ。AI がツールについて推論するとき、心理モデルを構築する必要がある——このツールへの入力は何か、出力は何か、副作用は何か。GUI の暗黙的な状態はこの心理モデルを不確実にする。CLI の明示的なパラメータはこの心理モデルを信頼できて精確なものにする。
linkly read 42 --offset 80 --limit 100——このコマンドの意味はパラメータで完全に決まる。AI はその動作を正確に推論でき、暗黙のコンテキストを推測する必要がない。
監査可能性（Auditability）
すべての CLI 操作は記録可能なテキストのシーケンスだ。AI が実行したコマンドと得られた出力は、すべて人間が読めるテキストだ。
この透明性には二つのメリットがある。
AI 自身にとって：自己検査ができる。「前のステップ linkly search "契約テンプレート" が 0 件を返した。キーワードが合っていないので 契約 雛形 に変えて再試行しよう」——このテキストベースの自己修正が AI Agent を確実に動作させる基盤だ。
人間にとって：事後検査ができる。AI がどのコマンドを実行し、各ステップの入出力が何だったかを確認でき、推論の連鎖全体が一目瞭然だ。GUI 操作の「何をクリックしたか」は追跡が難しいが、CLI 操作のログは本来的に監査記録だ。
Linkly AI CLI の設計実践
Linkly AI の CLI ツールを設計する際、最初から AI Agent を主要ユーザーの一つとして考慮した。
4 つの精密に設計されたコアコマンド
Linkly AI CLI のコアコマンドはたった四つだ：
linkly search <query> # ドキュメントを検索し、構造化リストを返す
linkly outline <doc_id> # ドキュメントのアウトラインを表示
linkly read <doc_id> [--offset N] [--limit N] # 指定した行範囲を正確に読み取る
linkly grep <pattern> # 全文正規表現検索この四つのコマンドは Unix 哲学に完全に沿っている——それぞれ一つのことだけを行い、明確な入出力コントラクトを持つ。AI Agent はこれらを任意に組み合わせて複雑な検索フローを構築できる。
典型的な Agent ワークフローは次のようになる：
# Agent がまずツールの利用可能性を確認
which linkly && linkly status
# ドキュメントを検索
linkly search "React hooks パフォーマンス" --json
# 興味あるドキュメントのアウトラインを見て目標セクションを特定
linkly outline 42
# 目標セクションを正確に読み取る
linkly read 42 --offset 80 --limit 100各ステップの出力は構造化テキストで、AI が直接消費・推論できる。GUI 操作はなく、視覚的解析の負担もまったくない。
パイプなどとの組み合わせ
CLI のもう一つの優位性は、システム内の他のコマンドと自由に組み合わせて、単一ツールの能力を超えた新たな力を生み出せることだ。
フィルタリングと抽出：--json 出力は jq で直接フィールドを抽出し、次のツールに渡せる：
# ドキュメントを検索し、doc_id リストだけ取り出して一括アウトライン取得
linkly search "データベース設計" --json | jq -r '.results[].doc_id' | xargs -I{} linkly outline {}grep との組み合わせで二次フィルタ：セマンティック検索で範囲を絞り、次に正確なキーワードでフィルタ：
linkly search "アーキテクチャ設計" | grep -i "マイクロサービス\|分散"統計と分析：wc、sort、uniq などと組み合わせてドキュメント統計：
# ナレッジベースに PDF が何件あるか集計
linkly search "" --json | jq '.results[].type' | sort | uniq -cスクリプトとの連携：シェルスクリプト内で一括処理し、繰り返しタスクを自動化：
# 検索されたすべてのドキュメントのアウトラインをファイルに出力
linkly search "プロダクトデザイン" --json \
| jq -r '.results[].doc_id' \
| while read id; do linkly outline "$id"; done \
> all-outlines.txtGUI ツールはこれらの組み合わせに参加できない。CLI ツールの出力はテキストストリームであり、本来的に他のあらゆるツールが消費できる。これによりシステム全体の能力は各ツールの単純な足し算をはるかに超える。
CLI は最もシンプルな MCP ブリッジ方式でもある
CLI と MCP は対立するものではない。linkly mcp 一つのコマンドで CLI を stdio MCP サーバーに変換でき、MCP をサポートする任意の AI クライアントから使用できる：
{
"mcpServers": {
"linkly-ai": {
"command": "linkly",
"args": ["mcp"]
}
}
}これは HTTP MCP サーバーを直接設定するよりはるかにシンプルだ——ユーザーはポート番号を知る必要がなく、JSON 内に URL を手書きする必要もなく、AI クライアントに「このコマンドを実行せよ」と伝えるだけでいい。
CLI は MCP エコシステムへの入場券となり、ユーザーにとってほぼゼロ設定の摩擦だ。
より大きなトレンド
Claude Code が IDE プラグインではなく CLI 形態を優先してリリースした決断には、明確な工学的ロジックがある：IDE プラグインはホスト環境に制約されるが、CLI ツールはターミナルがある場所なら どこでも動き、あらゆる Agent から呼び出せ、あらゆる他ツールと組み合わせられる。
これはより根本的な法則を示している：AI Agent がツールを呼び出す本質は、コマンドを実行することだ。ツール呼び出し（function call / tool use）はセマンティック的に CLI そのものだ——名前とパラメータを与えて結果を返す。CLI ツールは本来的に Agent が呼び出せる関数であり、変換レイヤーは不要だ。
「Terminal as the new IDE」という言葉は AI の台頭以前から言われていたが、AI の時代にまったく新しい意味を得た。「ターミナルでコードを書く」だけでなく、「Agent がターミナルを通じて世界とインタラクションする」ということだ。
かつて CLI は技術者専用のツールだった。将来、CLI は Agent の共通言語になるかもしれない——人間は自然言語で Agent と対話し、Agent は CLI でシステムとやり取りする。
まとめ
GUI はなくならない。人間がコンピューターを直接操作する最良のインターフェースであり続ける。しかし AI ツールが別のツールを呼び出す必要があるとき、CLI が最も自然な橋渡しだ——組み合わせ可能で、予測可能で、監査可能だ。
これが、トップ AI 企業が示し合わせたようにコマンドラインを選んだ理由だ。懐古趣味ではなく、工学的な必然と言えるかもしれない。
ターミナルでドキュメントを検索してみたい？こちらの二つの記事をどうぞ：ターミナルを離れずに AI でドキュメントを検索する と 一行コマンドで 30 以上の AI ツールがローカルファイルを読める。