AIエージェントCLI: ターミナルからサポートエージェントを実行・制御する

AIエージェントCLIが実際に意味すること

誇張を取り除けば、「AIエージェント」とはループです。モデルが入力を読み、行動を決め、ツールを呼び出し、結果を読み、完了するまでそれを繰り返します。CLI、つまりコマンドラインインターフェースは、そのループをグラフィカルなアプリではなくターミナルウィンドウから操作する手段にすぎません。

両者を組み合わせると、AIエージェントCLIはエージェントのためのテキストベースの操作面になります。コマンドを入力して起動し、タスクを与え、ツールやファイルを指定し、実行内容がスクロールしていくのを眺め、あなたがそこに座っていなくても動くように全体をスクリプト化します。これは、開発者がクリック操作のGitアプリよりもコマンドラインのgitを好むのと同じ本能です。より速く、再現性があり、他のスクリプトにそのまま組み込めるからです。

このパターンが爆発的に広まった理由は、ターミナルが自律型エージェントにとって絶好の居場所であることが分かったからです。すでにコマンドを実行し、ファイルを読み書きし、出力を次のツールにパイプできます。有能なモデルにその環境を与えれば、実際に仕事をこなせるエージェントになります。それこそコーディング用CLIが最初に成し遂げたことです。

なぜコマンドラインからAIエージェントを実行するのか

ダッシュボードは最初に見るには親しみやすいものです。同じことを2回以上したいと思った瞬間、コマンドラインが勝ちます。その魅力は、通常次のいずれかです。

• 再現性。 保存できるコマンドは、まったく同じように再実行したり、スクリプトに組み込んだり、チームメイトに渡したりできるコマンドです。UIをクリックして操作する方法は、そのどちらもできません。
• 自動化。 CLIはcronジョブ、CIパイプライン、Webhookに組み込めます。これにより、エージェントは「自分で実行した」から「毎晩午前2時に自動的に動く」へと進化します。
• 速度と集中力。 ブラウザのタブへの切り替えも、ページの読み込み待ちもありません。すでにターミナルで生活している人にとっては、単純に摩擦が少ないのです。
• バージョン管理。 設定をテキストファイルとして扱うということは、エージェントの設定が、後から誰も確認できないクリック操作としてではなく、履歴とレビューを伴ってコードのすぐ隣のGitに存在するということです。

これらはどれもサポート特有のものではなく、それがそもそもこの話がどこから来ているかを示す最初の手がかりです。「AIエージェントCLI」という言葉を生み出したツールは、ソフトウェアを書くエンジニアのために作られたものであり、それが得意とすることに表れています。

2026年のAIエージェントCLIツール

分けて考える価値のある3つの層があります。人々はこれらをひとまとめにしてしまい、その後なぜパーツがかみ合わないのか不思議に思うからです。

モデル提供元のCLI が花形です。これらはモデルラボ自身がリリースするターミナルエージェントです。Claude CodeはAnthropicのもので、複数ファイルにまたがる深い作業向けに作られ、MCPをネイティブにサポートしています。Codex CLIはOpenAIのオープンソースのターミナルエージェントで、Rustで書かれ、Apache-2.0ライセンスです。GoogleのGemini CLIも同じくApache-2.0のオープンソースで、大きなコンテキストウィンドウを持ちます。どれも優れていますが、明確にソフトウェアエンジニアリングを狙ったものです。

フレームワークのCLI は「自分で作る」層です。エージェントフレームワークは、コードで定義したエージェントを足場作りし、実行し、テストするためのコマンドラインツールを提供します。カスタムのサポートエージェントを求めるチームがたいてい行き着くのはここです。ループを自分で書き、ツールを配線し、CLIがそれを実行します。完全なコントロールと、構築するすべてに対する完全な責任です。

MCP は両者の下にある配線の標準規格です。Model Context Protocolは、Anthropicが2024年末に導入した、エージェントを外部のツールやデータに接続するためのオープンな標準規格です。すべてのAIアプリごとに手作業で統合を構築する代わりに、システムを一度MCPサーバーとして公開すれば、MCP対応のどのエージェントもそれを使えます。CLIはエージェントを操作する手段であり、MCPはエージェントがヘルプデスク、ドキュメント、注文システムに到達する手段です。

サポートのユースケースを検討している人にとって、この3つを比較すると次のようになります。

この表がギャップを浮き彫りにします。上位3行のCLIはいずれもエージェントを構築して実行する手段です。どれもサポートエージェントそのものではありません。この違いこそが、このテーマの本質です。

サポートエージェントの操作面が果たすべきこと

警告を無視して、それでもターミナルからサポートエージェントを実行することに決めたとしましょう。操作面が実際にカバーすべきことは何でしょうか。4つの仕事があり、コーディング用CLIが役立つのは最初の2つだけです。

呼び出し(Invoke) とは、チケットまたはその一群に対してエージェントを実行することです。設定(Configure) とは、その指示、ツール、そして返信すべきときとエスカレーションすべきときのルールを定めることです。観察(Observe) とは、ログとレポートを読み、エージェントが何をしたか、それが正しかったかを把握することです。自動化(Automate) とは、人間が介在せずに新しいチケットが来るたびにエージェントを起動するスケジュール、Webhook、トリガーのことです。

興味深いのは、この4つを満たす方法が「コマンドライン」だけではないということです。たとえばeeselのチームメイトは平易な言葉で設定され、対話形式で操作されるため、設定ファイルを編集する代わりに、変更内容を説明するだけで動作を更新できます。

サイドバーのツール呼び出しに注目してください。平易な言葉のレイヤーの下では、依然として実際の、名前の付いたツールが作業を行っており、それはCLIが呼び出すのと同じプリミティブですが、あなたが手作業で呼び出しを書く必要はありません。自動化 の仕事については、スケジュール実行は設定画面であり、あなたが世話をするcronファイルではありません。

重要なのはコマンドラインが悪いということではありません。サポートにおいては、インターフェースよりもこの4つの仕事の方が重要であり、そのほとんどはタイピングではなく、あなたのチケットとあなたのルールに関わるものだということです。

落とし穴: CLIは簡単な10%にすぎない

ここは私が正直に話したい部分です。私はeeselのインテグレーションを構築しており、チームがどこで行き詰まるかを見てきました。質問に答えるモデルをターミナルに立ち上げるのは、本当に週末プロジェクトです。もうほとんど完成したような気になります。実際にはそうではなく、そのギャップは人を欺きます。

CLIとモデルはスタックの一番上にすぎません。エージェントが本当に優れているかどうかを左右する下部は、それ以外のすべてです。すなわち、ヘルプセンターや過去のチケット、マクロを取り込んであなたの口調で回答できるようにすること、ヘルプデスクや注文システムに接続して実際に情報を調べ、行動できるようにすること、自動応答すべきときにだけ自動応答し、それ以外は放っておくための信頼度ルール、そして顧客の前に出す前にそのすべてをテストする方法です。それが90%であり、コーディング用CLIはそのどれも与えてくれません。

サポートリーダーから聞く最大の異議は、その最後の部分、つまりコントロールについてです。あるリーダーはこう述べました。

"The AI will never be able to answer 100% of the questions... I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

a DTC supplements CX lead, from an eesel sales call

その信頼度ベースのルーティングを、素のCLIの上に自分で構築するのは本当に大変な作業です。しかもそれは終わりません。モデルは変わり、あなたのプロダクトは変わり、ドキュメントは変わり、あなたが継ぎはぎしたパイプラインは、誰かがそれを継ぎはぎし続ける必要があります。

自分で構築するか、すでに完成したチームメイトを雇うか

つまり本当の決断は「どのAIエージェントCLIを使うか」ではありません。サポートパイプライン全体を自分で構築するのか、それとも完成した状態でやってくる既製のチームメイトを雇うのか、ということです。

エージェントのロジックがあなたの本当のプロダクトである場合、あるいはあらゆる層を自分たちで所有し続けたいエンジニアがいる場合には、自分で構築するのが正しい選択です。一部の技術チームは実際にこの道を選び、中にはマネージドなツールを離れてClaude APIの上に直接構築する例さえあります。それは正当な選択であり、そうではないふりをするつもりはありません。

しかし、ほとんどのサポートチームはLLMアプリケーションを運用したいわけではなく、チケットに回答してほしいだけです。あるeeselの顧客、ビットコインATMと暗号資産ハードウェアの企業でエンジニアリングリードを務め、300本以上の記事からなるナレッジベースを運用する人物は、そのトレードオフをはっきりとこう表現しました。

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Karel, GENERAL BYTES

それが決定的な要因です。誰が永遠にそれを保守するのか。自分で構築するCLIは、あなたが生かし続けるシステムです。マネージドなチームメイトは、他の誰かが生かし続けるシステムであり、あなたはそれを自社のヘルプデスクに向けるだけです。

eeselを試す

仕事がサポートエージェントであってコーディング用のコパイロットでないなら、eeselはその90%を飛び越える近道です。これは、すでに使っているヘルプデスク、Zendesk、Freshdesk、Gorgias、SlackなどにインストールされるAIヘルプデスクのチームメイトで、過去のチケットとドキュメントで学習し、開発サイクルではなく数分でキューに加わります。

その違いを生むのは、CLIでは提供できない部分です。本番稼働の前に実際のチケット履歴に対してエージェントをシミュレーションし、どこが強くどこにギャップがあるかを正確に確認し、うまく扱えるチケットについてのみ自律性をオンにできます。ある顧客のGridwiseは、初月でティア1のリクエストの73%を解決するのを目にしました。そして、プログラムによる制御を本当に望む場合には、APIとMCP形式のツールアクセスが用意されているため、裏側のパイプラインを所有することなくCLIのスクリプト化のメリットを得られます。価格は利用量に応じたもので、席数ごとの料金なしで解決済みチケット1件あたり約40セントであり、コストが実際に行われた作業に対応します。営業電話なしで無料で試すことができます。