コーディング用途で AI 中継サービスを評価するためのソフトウェアエンジニアリングガイド

AI 中継サービス（API Gateway / Aggregator）をソフトウェアエンジニアリングの座標系に置いて見ると、その本質は、状態機械による解析とコンテキストのスケジューリング機能を備えた、アプリケーション層（L7）のプロキシゲートウェイです。

IDE での 1 行補完から、Claude Code CLI や OpenAI Codex CLI に代表されるターミナルエージェントとの協働、そして Specification Driven Development（仕様駆動開発） というパラダイムへと発展するなかで、コーディング用途が API プロキシ層に求めるものは根本的に変わりました。ネットワークの安定性や高同時実行の負荷テストといった汎用的なゲートウェイ指標はいったん脇に置き、純粋に「コード生成とソフトウェアエンジニアリング」という業務シナリオの観点から見ると、AI 中継サービスを評価するうえでの核心は、このプロキシ層がコードの構文を壊さないか、エージェントの対話の状態機械を中断させないか、長いコンテキストの依存関係を捨てないか、開発側が送った最適化プロトコルを剥ぎ取らないかにあります。

コードを書く、ソフトウェアを開発するという用途では、AI 中継サービスの本格的な評価は、次の 4 つの主要なエンジニアリングの観点に絞るべきです。

1. コードの構文と特殊文字の忠実度（Syntax & Escape Integrity）

コード生成は、文字とフォーマットの正確さにきわめて敏感です。コードは普通のテキストではありません。厳密なインデント、改行、エスケープ文字、そして埋め込まれた JSON / XML 構造を含んでいます。

1. 特殊文字とエスケープの無損失性（Zero-Loss Escaping）

• 壊れる仕組み：ストリーミング（SSE）でコードのチャンクを出力するとき、コードには \n（改行）、\t（インデント）、\"（ダブルクォートのエスケープ）、正規表現の \\d、JSON 文字列などが大量に含まれます。中継サービスがチャンクの組み立てや中継の際に不適切なアンエスケープやエンコード変換を行うと（UTF-8 のマルチバイト文字が途中で切れるなど）、クライアントが受け取ったコードはそのまま構文エラーになります。
• 評価方法：エスケープのストレステストとして、極端なエスケープ文字を含むコードをモデルに生成させます。たとえば、複雑な正規表現、ネストした JSON 文字列を含む Python コード、C++ のポインターとマクロ定義を含むコードなどです。
• 合格基準：中継サービスが中継したストリームデータをそのままファイルに書き出し、ローカルの Lint ツール（eslint、flake8 など）や AST パーサー（Babel / Tree-sitter など）で構文を解析します。AST の解析成功率は 100% でなければなりません。

2. インデントと改行の保持（Whitespace & Indentation Preservation）

• 壊れる仕組み：Python や YAML などの言語は、インデントでスコープ（Scope）を表します。OS ごとの改行コードの違い（\n と \r\n）も、Git の差分に直接影響します。
• 評価方法：深くネストしたロジック（8 階層の loop の中にある Python 関数など）を含むコードのリファクタリングをリクエストします。
• 合格基準：元の出力と中継サービス経由の出力で、スペースとタブの数を比較します。バイトレベルの一致率は 100% でなければならず、中継サービスが空白文字を勝手に「整形」したり「圧縮」したりすることは厳禁です。

2. エージェントのツールチェーンと構造化出力の解析（Tool Call & Schema Fidelity）

現代のコーディングエージェントは、コードを書くときに Markdown を出力するだけではありません。Tool Call（read_file、edit_file、run_terminal_command など）を頻繁に発行します。

1. JSON Schema 構造の厳密な中継（Structured Output Fidelity）

• 壊れる仕組み：エージェントはローカルのコードを修正するとき、path、old_str、new_str などのフィールドを含む構造化 JSON を出力します。中継サービスが Tool Call のシリアライズ形式を壊したり、ネストしたフィールドの一部を捨てたりすると、エージェント側で解析に失敗し、例外を投げてクラッシュします。
• 評価方法：複数のファイルを連動して修正するエージェントタスク（5 つの TypeScript ファイルにまたがるインターフェースのリファクタリングなど）を組み、中継サービスが転送する Tool Call のメッセージをキャプチャします。
• 合格基準：中継サービスが中継した Tool Call の構造体は、上流の公式 API と完全に一致していなければなりません。フィールドの欠落、データ型の変更（string が number になるなど）、JSON の途中切断があってはなりません。

2. マルチターン対話の状態の連続性（Multi-turn State Continuity）

• 壊れる仕組み：エージェントが複雑なバグを解決するには、通常 10～30 ターンのやり取りが必要です（ファイルを読む -> 修正を試す -> テストを実行 -> エラー -> 再度修正）。中継サービスは、role: "assistant" に含まれる tool_use と、role: "user" に含まれる tool_result からなる長い対話のチェーンを、欠けることなく中継しなければなりません。
• 評価方法：実際のエージェントによるデバッグを、10 ターン以上実行します。
• 合格基準：N ターン目のやり取りで、中継サービスがそれまでの N−1 ターンのすべての Tool Call ID と状態ノードを完全に保持・転送していることを確認します。履歴のコンテキストが失われたり、状態が乱れたりしてはなりません。

3. コードの長いコンテキストとキャッシュプロトコル（Context Depth & Prompt Caching）

コード開発の典型的な特徴は、コンテキストが巨大なことです。中規模から大規模のプロジェクトでは、コードベースのコンテキスト（Codebase Context）が 10 万～20 万トークンに達することも珍しくありません。

1. Prompt Caching プロトコルの中継（Cache Control Pass-Through）

• 壊れる仕組み：仕様駆動開発（SDD）や大規模プロジェクトの開発では、プロジェクトの Architecture Spec や共通の Base コードは固定されています。エージェントはリクエストに cache_control マーカーを付けて、モデルのサーバー側で KV Cache を再利用させます。中継サービスがこのプロトコルのマーカーを剥ぎ取ると、コードを 1 行修正するたびに数十万トークンを Prefill し直すことになります。
• 評価方法：cache_control マーカー付きの 10 万トークンのエンジニアリングコンテキストを、続けて送信します。
• 合格基準：
• リクエスト側：パケットキャプチャで、中継サービスが上流に送るリクエストから cache_control フィールドが剥ぎ取られていないことを確認します。
• レスポンス側：返ってきた usage 構造体に、cache_read_input_tokens の計数が正確に返されているかを確認します。

2. 長いコンテキストの真正性（Needle in a Codebase）

• 壊れる仕組み：中継サービスがコスト削減のために、RAG でコードをひそかに切り詰めたり、プロンプトを圧縮したり、小さなモデルにすり替えたりしていないかを検証します。こうした行為は、大規模モデルがコード全体を把握する能力を低下させます。
• 評価方法：15 万トークンのコードプロジェクトの中で、目立たないインターフェース定義を File A（冒頭）に、その呼び出しを File B（末尾）に置き、間を無関係なコードで大量に埋めたうえで、そのインターフェースをどう修正すべきかをモデルに尋ねます。
• 合格基準：中継サービスが返したコード修正の結果を、公式 API に直接接続した場合の結果と比較します。中継サービスがコンテキストを切り詰めたせいで、ファイルをまたぐ変数の関連や型定義を見落としていれば、コンテキストの破損と判定できます。

4. コード生成の完全性と指示の保護（Output Horizon & Instruction Protection）

コーディング用途で最も避けたいのは、コードの途中切断です。たとえば 500 行のアルゴリズムモジュールが、300 行目まで生成したところで、理由もなく突然途切れてしまうようなケースです。

1. Max Output Tokens の上限への対応（Max Output Horizon）

• 壊れる仕組み：単一ファイルのリファクタリングやモジュール全体の生成では、モデルが 1 回で 4,000、8,000、場合によっては 16,000 トークンの純粋なコードを出力する必要があります。中継サービスのプロキシバッファ（Buffer）やタイムアウト制御のロジックが不十分だと、長いコードが途中で中断されてしまいます。
• 評価方法：冗長なロジックのない、非常に長い完全なコードモジュールをモデルに生成させます（数百の列挙型と変換ロジックを含む Parser を手書きさせるなど）。
• 合格基準：中継サービスが中継するレスポンスボディは、モデルがサポートする最大の max_tokens まで到達できなければなりません。また、末尾の finish_reason は "stop"（正常終了）または "length"（長さの上限に到達）と明示されている必要があります。理由のない早期の EOF は厳禁です。

2. System Prompt の改ざんゼロ（System Prompt Integrity）

• 壊れる仕組み：コーディングエージェントは、System Prompt にきわめて厳格なコーディング規約を注入します（「TypeScript の strict モードを必ず使う」「すべての関数に JSDoc を書く」など）。一部の中継サービスは、独自のグローバルプロンプトを注入したり、System Prompt を自動的に切り詰めたりします。
• 評価方法：特殊な Code Style の制約を含む System Prompt を注入し、モデルにコードを生成させます。
• 合格基準：生成されたコードが System Prompt の制約に 100% 従っているかを確認します。パケットキャプチャで Raw Request を比較し、中継サービスが System Prompt をバイトレベルで一切改ざんしていないことを確かめます。

まとめ：コーディング用途の評価チェックシート