マルチモーダルAI推論の統合：なぜAIClient2APIなのか？

AIアプリケーションの開発やエージェントワークフローのプロトタイピングにおいて、最適なモデルを見つけるために複数の大規模言語モデル（LLM）を試す機会は頻繁にあります。しかし、各プロバイダーでAPI構造やプロトコルが異なるため、切り替えのたびに煩雑なコードのリファクタリングやバックエンドロジックの修正が必要になるのが一般的です。

AIClient2API は、まさにこの課題を解決します。これは、Gemini CLI、Antigravity、Codex、Grok、Kiroといったプラットフォームのクライアントリクエストを模倣し、単一の標準化されたOpenAI互換APIインターフェースへとカプセル化するインテリジェントなプロキシ層です。プロトコルの統一に加え、各ノードのライブ状況を監視するためのWeb UIダッシュボードも提供します。

主な機能

モデル切り替えのコストゼロ: OpenAI SDK形式で一度統合コードを書けば、ビジネスロジックを修正することなく、バックエンドのプロバイダーを動的に切り替えることができます。
視覚的な管理コンソール: 設定のリアルタイム管理、稼働状況の監視、内蔵PlaygroundによるAPIテスト、リクエストログの監査が可能なWeb UIダッシュボードを搭載しています。

技術アーキテクチャと実装

本プロジェクトは、プロトコルの変換と高可用性を維持するために、AIファーストのモジュール式アーキテクチャを採用したNode.jsベースで構築されています。

plaintext
1[ Your Application (Cherry-Studio / Cline / Custom Code) ]
2                           │ (Standard OpenAI / Claude Request)
3                           ▼
4            ┌─────────────────────────────┐
5            │     AIClient2API Gateway    │
6            └──────────────┬──────────────┘
7                           │
8             ┌─────────────┴─────────────┐
9             ▼                           ▼
10     ┌──────────────┐            ┌──────────────┐
11     │  Adapters    │            │ Provider Pool│
12     └───────┬──────┘            └───────┬──────┘
13             │                           │ (Health Check / Cooldown)
14             ▼                           ▼
15     ┌──────────────┐            ┌──────────────┐
16     │ TLS Sidecar  │            │ Failover &   │
17     │ (Go uTLS)    │            │ Fallback     │
18     └───────┬──────┘            └───────┬──────┘
19             │                           │
20             └─────────────┬─────────────┘
21                           ▼
22   [ Backends: Gemini, Grok, Kiro...]

1. 戦略およびアダプターパターン

リクエストがゲートウェイに到達すると、システムは対象のモデルプロバイダーを特定し、専用のサービスアダプターを経由してルーティングを行います。アダプターは、OpenAIやClaudeの標準ペイロードを、アップストリームのクライアントが必要とする正確な構造（Geminiの内部CLI構造やGrokのエンドポイントなど）に変換し、標準応答とストリーミング（text/event-stream）応答の両方をシームレスに処理します。

2. インテリジェントなプロバイダープールとフォールバックチェーン

本番環境レベルの信頼性を確保するため、プロキシはアカウントとエンドポイントのプールを管理します。

自動ヘルスチェックとクールダウン: システムは定期的にハートビートを実行します。ノードの障害や「429 Too Many Requests」制限が発生した場合、該当ノードは自動的に一時的なクールダウンキューに入れられ、ルーティング対象から外されます。
クロスタイプ・フォールバック: 特定のプロバイダーのクォータがすべて消費された場合、ゲートウェイは事前設定されたフォールバックチェーンに従ってリクエストを切り替えます（例：gemini-cli-oauthからgemini-antigravityへの切り替え）。ただし、プロトコルが一致している必要があります。

3. TLSフィンガープリント模倣（TLS Sidecar）

一部のアップストリームサービスは厳格なネットワークチェックを実施しており、ブラウザのTLSフィンガープリントと一致しないリクエストをブロックします。これを解決するため、本プロジェクトにはGo（uTLS使用）で記述されたTLSサイドカープロキシが組み込まれています。これにより、Chromeの標準的なTLSハンドシェイクをエミュレートし、HTTP/2ネゴシエーションを自動処理して「403 Forbidden」エラーを回避します。

エコシステムの統合：AtlasCloudのネイティブサポート

atlascloud

最新のアップデートにより、AIClient2APIは、オールインワンのマルチモーダルAI推論プラットフォームである AtlasCloud をネイティブサポートしました。

AtlasCloud は、Qwen 3.6、DeepSeek v4 pro、Kimi k2.6、GLM 5.1 といった非常にコスト効率の高いモデルを単一のエンドポイントで集約しています。AtlasCloudをAIClient2APIプールに組み込むことで、以下のメリットが得られます。

シームレスな切り替えと安定したスループット: DeepSeekの推論能力、Qwenの言語処理、マルチモーダル生成の間をストレスなく切り替え可能です。基盤となるエンタープライズインフラが、安定した同時実行レートを保証します。
すぐに使えるテンプレート: リポジトリには
text
```
1provider_pools.json.example
```
に設定プリセットが含まれており、専用のルーターパスと合わせてすぐに利用を開始できます。

この構成は、インフラのオーバーヘッドを最小限に抑えたい開発者が、AtlasCloudの低コストな Coding Plan Promotion を活用する上で非常に有効です。

利用開始方法

Dockerでのデプロイ:
Bash

plaintext
1docker run -d -p 3000:3000 -p 8085-8086:8085-8086 -p 1455:1455 -p 19876-19880:19876-19880 --restart=always -v "your_path/configs:/app/configs" --name aiclient2api justlikemaki/aiclient-2-api

Web UIによる設定:
text
```
1http://localhost:3000
```
（デフォルトパスワード: admin123）にアクセスし、認証情報を追加してプロバイダーを視覚的に管理します。
トラフィックのルーティング: 使用するAIデスクトップクライアントやバックエンドSDKの接続先を、ローカルのゲートウェイインスタンスに向けます。

実装の詳細、ドキュメント、高度な設定オプションについては、GitHubリポジトリをご覧ください。

👉 AIClient2API

一覧に戻る