【ITニュース解説】How Long Before Your Agent Says Anything? Time 4 Coding Agent CLIs With hyperfine

AIエージェントの利用が広がる中で、システムエンジニアを目指す皆さんも、これらのツールを日常的に使う機会が増えるだろう。AIエージェントは、コード生成、デバッグ、ドキュメント作成など、様々な開発作業を助けてくれる強力な相棒だ。しかし、その便利さの裏には、ユーザーがコマンドを入力してからAIモデルが実際に思考を開始し、応答を返すまでに、いくつかの段階を踏む必要がある。この一連の「起動プロセス」にかかる時間は、日々の開発体験に大きく影響するため、その仕組みを理解し、実際に時間を測定することは非常に重要となる。

まず、AIエージェントのCLI（コマンドラインインターフェース）が起動してから、ユーザーのプロンプトがAIモデルに届くまでの間に何が起きているのかを具体的に見ていこう。このプロセスは大きく四つのステップに分けられる。

一つ目は「プロセスの開始」だ。これは、皆さんがターミナルでclaude -p helloのようなコマンドを打ったときに、そのコマンドが実行可能ファイル（バイナリ）を探し、メモリにロードされて動き出すまでの時間だ。例えば、Codexのようにnpmからインストールした場合、codexというコマンドは実際にはNode.jsのスクリプトであり、それがさらにネイティブな実行ファイルを起動するといった複雑な手順を踏むこともある。この段階は、エージェントが「目を覚ます」最初の瞬間だと言える。

二つ目は「設定ファイルやメモリファイルのロード」だ。AIエージェントは、ユーザーの設定や過去の会話履歴、利用可能なツールといった情報を読み込むことで、より賢く、文脈に沿った応答を生成できるようになる。例えば、Claude CodeはCLAUDE.mdファイルや様々なフック、スキル、カスタムコマンド、プラグイン、そして自動メモリといったものを読み込む。これらはエージェントが持つ「能力」や「知識」を定義する重要な要素だ。一方、CodexはAGENTS.mdファイルから命令チェーンを構築し、これもエージェントの挙動を形作る。これらのファイルサイズが大きかったり、読み込む設定の数が多かったりすると、当然ながらこのロード時間は長くなる。エージェントが思考を始める前に、その「思考の基盤」を準備する時間と考えると良いだろう。

三つ目は「MCP（Model Context Protocol）サーバーの起動と待機」だ。AIエージェントは、単体で動作するだけでなく、外部のツールやサービスと連携することで、その真価を発揮することが多い。MCPサーバーは、このような外部ツールとの通信を仲介する役割を担う。エージェントは起動時に、利用可能なMCPサーバーを探し、接続が確立されるまで待機する。各CLIは、このMCPサーバーの接続を待つ時間にそれぞれ異なる上限を設定している。例えば、Claude Codeは最大30秒、Codexはオプションのサーバーに対しては1秒、必須のサーバーに対しては10秒まで待機するといった具合だ。もしMCPサーバーが見つからなかったり、応答が遅かったりすると、エージェントは待機し続けるため、起動時間が大幅に伸びる可能性がある。これは、エージェントが「他の専門家と連携準備を整える」時間と言えるだろう。

四つ目は「モデル呼び出し」だ。上記の準備が全て整った後、ようやくユーザーのプロンプトがAIモデルに送られる。このステップには、ネットワークを通じてプロンプトをAIモデルに送信する時間、AIモデル側でリクエストが処理されるまでキューで待機する時間、プロンプト全体を読み込む時間、そしてAIモデルが応答を生成し、それをユーザーに返す時間が含まれる。これらは「エージェントが実際に思考し、会話する」時間そのものだ。

これらの起動プロセスにかかる時間を測定するために、hyperfineという強力なコマンドラインベンチマークツールが活用される。hyperfineは、指定したコマンドを複数回実行し、その平均時間、標準偏差、メモリ使用量などを詳細にレポートしてくれるツールだ。また、最初の数回を「ウォームアップ」として測定対象から外すことで、ディスクキャッシュの影響など、一時的な要因による誤差を減らすことができる。

具体的な測定は、以下のステップで進める。

まず、hyperfineをインストールし、空のGitリポジトリを作成するなどの準備を行う。これは、一部のCLI（例：Codex）がGitリポジトリの内部でなければ動作しないためだ。また、各CLIのバージョン情報も記録しておくことが重要だ。なぜなら、ソフトウェアは常に更新されるため、バージョンが変わればパフォーマンスも変わる可能性があるからだ。さらに、テスト用のMCPサーバーを事前にインストールし、測定前に各CLIコマンドを一度手動で実行して、サインイン画面で止まらないか、エラーで終了しないかを確認する習慣をつける。これは、ベンチマークが正確な結果を出すための下準備となる。

最初の測定は「Run 1: プロセス起動時間」だ。ここでは、各CLIに--versionオプションを付けて実行する。このコマンドは、CLIが起動してバージョン情報を表示し、すぐに終了するため、まさにバイナリがロードされ、最低限の処理が行われるまでの「フロア」の時間を測定できる。この時間が、エージェントが動作を開始するための最低限のコストとなる。

次に「Run 2: 1語のプロンプトから完全な回答まで」を測定する。ここでは、helloのような簡単なプロンプトを各CLIに与え、AIモデルからの応答が完全に返ってくるまでの時間を測定する。この時間には、プロセス開始、設定読み込み、MCPサーバーの待機、そしてモデル呼び出しという、先ほど説明した全てのステップが含まれる。つまり、これはエージェントを実際に利用する際の「体感時間」に最も近いものだ。 さらに、このステップでは、設定ファイルを読み込まない「Stripped-down run」も行い、通常の場合と比較する。例えば、Claude Codeでは--bareフラグを使うことで、フックやスキル、MCPサーバー、メモリファイルといった設定のロードをスキップできる。これにより、設定ファイルの読み込みなどが、どれだけ全体の起動時間に影響を与えているかを具体的に把握できる。また、Claude Codeのように、JSON出力でttft_ms（Time To First Token: 最初のトークンが返ってくるまでの時間）のような詳細なタイミング情報を提供するCLIもある。この情報は、ユーザーが「エージェントが何かを考え始めた」と感じるまでの時間を示しており、UX（ユーザー体験）の観点から非常に重要だ。

最後の測定は「Run 3: 一つのMCPサーバー、一つのAGENTS.md、応答しないサーバー」だ。このステップでは、MCPサーバーの存在や、AGENTS.mdのような設定ファイルが起動時間に与える影響を深掘りする。一つMCPサーバーを追加してプロンプトを実行する時間を測定することで、サーバーの起動とツール定義の読み込みにかかるオーバーヘッドを評価できる。AGENTS.mdのような設定ファイルが長ければ長いほど、エージェントがその内容を読み込み、AIモデルにコンテキストとして渡す必要があるため、時間がかかる。 また、意図的に応答しないMCPサーバー（例えば、60秒間停止するsleep 60コマンドをサーバーとして設定する）に接続させ、各CLIがどのくらいの時間でタイムアウトするかを確認することも重要だ。これにより、壊れたサーバーがあった場合に、エージェントがどれだけ待機し続けるか、あるいは適切にタイムアウトして処理を進めるかといった挙動を検証できる。

これらの測定結果は、日常の開発ワークフローに直接的な影響を与える。特に、Hermes IDEのようなツールでは、タスクごとに新しいAIエージェントのセッションを開始する場合が多く、そのたびにこれらの起動プロセス全体が繰り返される。もし一度の起動に数秒かかる場合、一日に数十回タスクを開始すれば、その遅延は積み重なり、一日の作業効率に大きな影響を及ぼすだろう。

したがって、起動時にロードするコンテキスト（MCPサーバーのツールリスト、AGENTS.md、メモリファイルなど）を必要最小限に抑えることが、効率的な開発にとって非常に重要となる。どの情報がエージェントの起動時に必須で、どの情報が後から要求に応じて読み込まれても良いのかを判断することは、まさにプロンプトエンジニアリングの一部だと言える。

AIエージェントの起動時間の理解と最適化は、単に技術的な興味にとどまらない。それは、皆さんの日々の開発作業の効率を向上させ、よりスムーズでストレスの少ない開発体験を実現するための、実践的な知識となるだろう。自分の開発環境でこれらの測定を行い、エージェントの「素顔」を知ることは、システムエンジニアとしてのスキルアップにも繋がるはずだ。