エージェントには計器盤から

資料基準：2026年8月14日午前、韓国時間

AIモデルの発表は最高速度を前に出しがちだ。しかし私が運用するサービスには、もっと広い計器盤が要る。最初の文字が出る速さ、最後まで仕事を終えたか、失敗から戻れるか、そして請求書が先に椅子で待っていないかを一緒に見たい。

時速300キロでも目的地を通り過ぎれば、タクシー料金が速く増えるだけだ。そこでエージェントに付ける計器盤を整理した。

1. 「速い」を四つに分ける

OpenAIのFast mode文書は、GPT-5.6 Solに速く安定した処理を提供する一方、トラフィックが急増するとStandardへ戻る場合があると説明する。平均値一つでは、この動きを見落とす。

私は最低でも四つ測る。

1. TTFT：要求から最初のトークンまでの時間
2. 出力速度：1秒あたりの出力トークン数
3. p95レイテンシ：遅い5%の要求にかかった時間
4. 作業全体時間：ツール呼び出しと再試行を含む完了時間

返却された service_tier とエラー率も付ける。Fastを要求してStandardで処理されたなら、その事実を性能表に残す。ストップウォッチを押してゴールを見ない実験は、運動会でも叱られる。

出典：OpenAI API Fast mode

2. モデルとエージェント実行基盤を分ける

Vercelの HarnessAgent はClaude Code、Codex、Piなどを共通インターフェースの背後に置く。AI SDK 7はこの実行層を広げた。私の構成は単純だ。

業務機能 → AgentRuntime → 実際のエージェント → モデル・ツール

業務機能は「リポジトリを点検して安全な修正案を作る」とだけ依頼する。セッション、ストリーミング、中止、権限承認、サンドボックスの後始末は AgentRuntime が担当し、実装は設定で選ぶ。

それでも各ランタイムの違いは検証する。

• ツール呼び出しと構造化出力
• セッション再開と中止
• ファイル・ネットワーク・シェル権限
• ログと費用の可視性
• 失敗後の後始末と再試行

共通リモコンを作っても、すべての家電に「炊飯」ボタンが生えるわけではない。抽象化は差を消す技術ではなく、差を一か所で管理する技術だ。

出典：Vercel HarnessAgent、Vercel AI SDK 7

3. 完了はPRを作ったところで終わらない

応答成功率だけで採点すると、自信満々に間違えた回答も合格する。私は先に完了条件を書く。

• 要求されたファイルだけを変更したか
• テストと静的検査を通過したか
• 関係ない変更を加えていないか
• 人が理解できる根拠を残したか
• 失敗時に元の状態を守ったか

20秒で修正して二度戻すモデルより、40秒で一度正しく終えるモデルのほうが安いことがある。そのため、トークン単価ではなく 完了作業1件あたりの費用を見る。

中心となる四つの表示はこれだ。

完了率 | 作業全体時間 | 完了1件あたり費用 | 復旧成功率

ベンチマークは面接点に似ている。入社後、コピー機の前で固まらないかも確認したい。

4. AIが選んだパッケージを入口で検査する

GitHubのライセンス準拠公開プレビューは、企業が中央ルールを定め、問題のある依存関係をマージ前に止められる。コード生成が速くなるほど、パッケージ搬入も速くなるので、この門番は重要だ。

私のCI順序は次のとおりだ。

1. lockfileからSBOMを作る。
2. 新規依存とバージョン変更を検出する。
3. 許可・禁止ライセンスを確認する。
4. 脆弱性と悪意あるパッケージを検査する。
5. 例外の承認者と期限を記録する。

「AIの推薦」はライセンスではない。自動補完は契約書の署名欄に印鑑を押してくれない。

出典：GitHubオープンソース・ライセンス準拠の公開プレビュー

5. エージェントの財布は小遣い袋から始める

Circle Agent StackとNanopaymentsテストネットでは、エージェントがx402でAPIやサービスに支払う実験ができる。技術的に可能であることと、運用で安全であることは別だ。

私は決済の前にポリシー層を置く。

エージェント → 購入要求 → ポリシー検査 → 上限付き財布 → 決済 → 領収書

最低限、次が必要だ。

• 1回・1時間・1日の支出上限
• 許可された販売者と資産
• 重複決済を防ぐidempotency key
• 購入目的と成果物の関連付け
• 取消・紛争・失敗時の規則
• 人の承認が必要な金額

無制限の財布を渡すのは、冷蔵庫を確認してと頼みながら家の鍵と法人カードも渡すようなものだ。賢さと節約は同じオプションではない。

出典：Circle Agent Stack、Circle Nanopaymentsテストネット

私が使う運用基準

新しいモデルやエージェントを追加するとき、私は次の順で確認する。

1. 実業務20〜50件で完了条件を固定する。
2. 同じ入力でStandardと高速経路を比べる。
3. p50・p95と完了1件あたり費用を記録する。
4. ランタイムごとの権限・セッション・復旧差を表にする。
5. 依存関係と決済を別のポリシーゲートに通す。
6. 意図的に失敗させ、原状復帰を確認する。

今日の結論は、エージェントにはターボボタンより計器盤を先に付けようだ。速いデモは拍手をもらう。速度・費用・権限・復旧が一緒に見える仕組みは、月曜の朝を守ってくれる。