CLIからAIエージェントを制御する方法:実践ガイド

そもそもコマンドラインからエージェントを制御する理由

私は仕事として統合を構築しているので、自分の偏りを認めます。四半期ごとに覚え直さなければならない設定画面をクリックして回るより、ターミナルから何かを実行するほうが好きです。しかし、ここでの論点は個人の好みより大きなものです。

ダッシュボードはエージェントを理解するには良い場所です。しかし、どんな規模であれエージェントを運用するには不向きな場所です。同じ変更を3つのエージェントに適用したい、あるいはインフラの他の部分と一緒にGitリポジトリに置かれた設定を使いたい、あるいは人間なしでCIジョブが実行できるロールアウトが欲しい、そう思った瞬間にブラウザがボトルネックになります。手作業で行うことはすべて、きれいに繰り返したり、レビューしたり、ロールバックしたりできないステップになってしまいます。

コマンドラインはエージェントの操作をテキストに変換することでこれを解決します。ランブックに貼り付けられるコマンド。差分を取れる設定。cronジョブやWebhookからトリガーできる実行。そしてますます、別のAIエージェントが操作できるインターフェースになりつつあります。だからこそ、eeselのドキュメントはコーディングエージェントに対して、ブラウザでダッシュボードをクリックして回るのではなくCLIを使うよう指示しているのです。

このガイドの残りの部分では、そのループを段階を追って説明します。具体的なコマンドにはeeselのCLIを使いますが、これは実在するとわかっており、ドキュメントを指し示せるものだからです。しかし、この形はターミナルを真剣に扱うあらゆるエージェントプラットフォームに当てはまります。

始める前に必要なもの

3つあり、どれも時間はかかりません。

• 最新のNode.js。 eeselのCLIにはNode 18.17以降が必要です。ここ数年で構築されたほとんどのマシンにはすでに入っています。
• 本物のCLIを持つエージェントプラットフォーム。 これは注意深く確認すべき点です。多くのツールは「開発者フレンドリー」を謳いながら、実際には設定画面しか渡してきません。導入を決める前に、実際のコマンド一覧が載った公開されたCLIドキュメントを探してください。
• 接続するデータソース。 サポートエージェントの場合、それはヘルプデスク、ナレッジベース、または過去のチケットを意味します。エージェントは読めるものの質に応じてしか良くなりません。

始めるのに必ずしもアカウントは必要ありません。eeselのCLIは匿名のワークスペースを立ち上げられるため、サインアップなしでウェブサイト上のバブルをテストでき、何かを決める前にフロー全体を確認するのに良い方法です。

ステップ1:CLIをインストールしてログインする

eeselのCLIを入手する方法は3通りあり、それぞれ異なる状況に対応しています。

まったくコミットせずにウェブサイトで試してみたいだけなら:

npx @eesel/cli init chat-bubble --site https://your-site.com

これはアカウントなしで実行でき、匿名のワークスペースを立ち上げます。本格的にインストールしたい場合は、npmからグローバルに取得するか:

npm i -g @eesel/cli

またはインストールスクリプトを使います:

curl -fsSL https://dashboard.eesel.ai/eesel-cli/install | sh

インストールが完了したら、認証を行います:

eesel login
eesel whoami

eesel loginは一度だけブラウザを開いてターミナルをあなたのワークスペースに紐づけ、whoamiはどのアカウントとエージェントに接続しているかを確認します。ここから先はターミナルにとどまることができます。

これをスクリプト化する人にとって重要な詳細があります。すべてのコマンドはJSONを出力し、リストは1行につき1オブジェクトを出力します。つまり、人間が読めるテキストを解析することなく、出力を直接jqやスクリプトにパイプできます。また、--fields(例:--fields id,status)で出力を絞り込み、スクリプトが必要なキーだけを見るようにすることもできます。

ステップ2:ヘルプデスクまたはデータソースを接続する

読むものが何もないエージェントはただの余興です。最初に行う本当に意味のあることは、エージェントにソースを与えることです。

eesel integrations connect zendesk

zendeskをあなたが使っているプラットフォームに置き換えてください。eeselはZendesk、Freshdesk、Gorgias、Front、Help Scout、HubSpot、Salesforce、Jira Service Managementなど、多数の製品に接続します。このコマンドはOAuthのハンドシェイクを処理し、ソースが有効になると報告します。

いつでも状態を確認できます:

eesel status

statusは何が接続されているか、エージェントが何を認識しているか、まだ同期中のものがあるかを教えてくれます。セットアップの途中で唯一重要な問い、つまり「これは実際に準備できているか」に答えてくれるので、私が最もよく実行するコマンドです。

ステップ3:エージェントの指示を設定する

ここで「制御」が現実味を帯びてきます。指示とはエージェントが従う常設のルールのことです。トーン、答えてよい範囲、いつエスカレーションすべきか、どのアクションを自分の判断で取れるか、といったものです。

eesel instructions

これは現在の指示を読み込み、エージェントがどのようなルールの下で動いているかを正確に把握させ、編集も可能にします。テキストであるため、指示をバージョン管理下のファイルに保管し、エージェントの振る舞いの変更を、誰かが3週間前に設定パネルで行った謎の編集ではなく、差分と履歴を伴うレビュー済みの他の変更と同様に扱うことができます。

このガイドから1つだけ習慣を持ち帰るなら、これにしてください。誰が何を変えたのか誰にも見えないためにエージェントの振る舞いがずれていくことは、こうしたロールアウトが静かに失敗していく最も一般的な原因です。

ステップ4:野放しにする前にシミュレートする

ここが、ほとんどの人が飛ばしてしまう部分であり、私が強く主張したい部分です。

私たちは何年もAIエージェントをライブのサポートキューに投入してきましたが、身についた教訓は、自信ありげに聞こえるボットが正しいボットとは限らないということです。モデルは安心させるような口調で間違った答えを平気で返します。それを顧客より先に見つける唯一の方法は、まず現実に対してテストすることです。

eeselはこれを、過去のチケットを再生し、エージェントの回答をチームが実際に送った内容と照らし合わせて採点するシミュレーションとして実行します。例えば、最近のチケットに対してシミュレーションを実行するよう依頼することで呼び出せます。エージェントがチームと一致していたであろう箇所、外していたであろう箇所、そして指示のどこを変更すべきかを返してくれます。意図的に行わないことの1つは、解決率やコスト予測をでっち上げることです。そのような数値を主張するツールには注意すべきです。なぜならその数字は測定値を装った推測にすぎないからです。

シミュレーションを実行し、ギャップを読み、ステップ3の指示を修正し、再度実行してください。このループこそ、これをターミナルから行うことの全ての意味です。各サイクルは繰り返し実行できるコマンドであり、覚えておかなければならないクリックの連続ではありません。

ステップ5:実行をトリガーしてアクティビティログを読む

いよいよ運用です。エージェントに直接話しかけます:

eesel chat "Where is my order #DL-4821?"

そして、エージェントが何をしてきたかを新しい順に読みます:

eesel activity

eesel activityは可観測性のためのインターフェースです。パターンを見つけられるように実行を一覧表示し、個々の実行を開いてエージェントが何を読み、何を判断し、何を行ったかを正確に確認できます。何かがおかしいと感じたら、まずここを見るべきです。エラーも構造化されています。失敗したコマンドはerror、hint、そしてretryableかどうかを含む単一のJSON行をstderrに出力し、ゼロ以外の終了コードで終了します。これがCLIをCIジョブに組み込んでも安全である理由です。スクリプトは「コマンドを間違って入力した」のか「サービスに一時的な不具合があったので再試行すべき」なのかを区別できます。

ステップ6:承認でアクションをゲートする

完全に自律的なエージェントと役に立たないエージェントのどちらかを選ぶ必要はありません。中間的な解決策は人間参加型の承認キューであり、これはコマンドラインにおける第一級の機能です。

eesel approvals list
eesel approvals approve <id>
eesel approvals deny <id>

エージェントがまだ完全には信頼していないアクションを取ろうとすると、それはそのまま実行されるのではなく承認キューに入ります。ターミナルからそれを確認し、承認または拒否します。特定の種類のアクションが信頼を得たら、それを自動化に昇格させます:

eesel approvals approve <id> --always

これが、恐ろしいスイッチを一気に切り替えるのではなく、自律性を段階的に引き上げていく方法です。すべてをゲートした状態から始め、エージェントが何を提案するかを観察し、正しく行動することを確認できたアクションを--alwaysで一つのカテゴリずつ引き渡していきます。

CLIを超えて:他の3つの制御インターフェース

CLIはあなたが日常的に使うインターフェースですが、エージェントを操作する唯一の方法ではありません。それぞれが異なる問いに答えるため、全体像を把握しておくと役立ちます。

• MCPサーバーは、別のAIが操作者である場合のためのものです。すべてのeeselワークスペースは同時にMCPサーバーでもあります。npx @eesel/cli mcp tokenを実行すると、URL、30日間有効なトークン、そして貼り付けるだけで使えるclaude mcp addコマンドが出力され、Claudeのようなクライアントが同じ操作をツールとして呼び出せるようになります。これにより、コーディングエージェントにサポートエージェントを管理させることができます。
• Webhookは、外部イベントがエージェントを駆動すべき場合のためのものです。固有のWebhook URLは、スタック内の他の場所で何かが起きたときにエージェントを起こし、新しい注文やフォームの送信が、誰もコマンドを入力することなく実行を開始できるようにします。
• Network Accessは、エージェントが外部に手を伸ばす必要がある場合のためのものです。ドメインを許可リストに登録し、認証ヘッダーを付与すると、エージェントは実行中にGET、POST、PATCH、DELETEでそのREST APIを呼び出せるようになります。認証情報はヘッダーとして保存され、モデルには決して見せられません。これはセキュリティチームが尋ねてくる詳細です。

ヘッドレス環境では、対話的なログインを完全にスキップできます。EESEL_API_URLとEESEL_API_TOKEN(特定のエージェントを固定するためのEESEL_AGENT_IDも)を環境変数として設定すれば、CLIはそこから認証します。これがCIパイプラインにきれいに組み込める理由です。

避けるべきよくある間違い

人々がつまずくのを見てきたいくつかのことを紹介します。これを読めばその教訓を飛ばせます:

• シミュレーションなしで本番運用に移る。 このリストの中で最も高くつく間違いです。ステップ4を毎回実行してください。
• 急いで手作業で指示を編集する。 エージェントの振る舞いがバージョン管理下になければ、いずれ誰も説明できない障害が発生します。eesel instructionsの出力をコードのように扱ってください。
• 初日から完全な自律性をオンにする。 すべてを承認キューに入れた状態から始め、--alwaysへの昇格を1つずつ勝ち取ってください。信頼は一度に1つのアクションカテゴリずつ築かれます。
• 終了コードを無視する。 CLIが構造化されたエラーとゼロ以外の終了コードを返すのには理由があります。それらをチェックしないスクリプトは、失敗を平然と通り過ぎてしまいます。
• REST APIが存在すると思い込む。 ベンダーを評価していて、あなたの計画が文書化されたRESTエンドポイントに依存しているなら、構築を始める前にそれが存在することを確認してください。eeselについて言えば、正直な答えは、CLI、MCP、Webhook、Network Accessがインターフェースであり、それはエージェントを制御するには十分ですが、REST製品と同じではないということです。

eeselを試す

ターミナルから本当に運用できるサポートエージェントが欲しいなら、eeselはまさにそのために作られています。CLIは1つのコマンドでインストールでき、すでに使っているヘルプデスクに接続し、ライブの会話に触れる前に実際の過去のチケットに対してシミュレートし、あなたが別の指示をするまですべてのアクションを承認キューの背後に保ちます。料金は従量課金制で、対応したチケット1件あたり40セントです。無料トライアルにはクレジットカード不要で50ドル分の利用枠が含まれているため、何も費やす前にロールアウト全体をスクリプト化して動作を確認できます。