🤖 AI

LLM-Rosetta: A Hub-and-Spoke Intermediate Representation for Cross-Provider LLM API Translation

異なる LLM 提供元の API 間の相互運用性を高めるため、共通の中間表現（IR）を用いたハブ・アンド・スポーク型翻訳フレームワーク「LLM-Rosetta」を提案し、複数の主要プロバイダー間での双方向変換とストリーミング処理を、極めて低いオーバーヘッドで実現可能とした。

原著者： Peng Ding

公開日 2026-04-13

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Peng Ding

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

LLM-ロゼッタ：AI 言語の「万国共通辞書」を作るプロジェクト

こんにちは。この論文は、今世界中で爆発的に増えている「大規模言語モデル（LLM）」と呼ばれる AI たちと、それらをつなぐ「翻訳機」についてのお話です。

少し難しい話になりがちですが、**「異なる国の言葉を持つ人々が、どうすれば円滑に会話できるか」**という視点で、まるで子供向けのおとぎ話のように説明してみましょう。

🌍 背景：バラバラな「AI 言語」の混乱

想像してみてください。世界中に、それぞれ独自の「言葉」や「挨拶のルール」を持っている AI 会社（OpenAI、Anthropic、Google など）がたくさんあります。

OpenAI は「こんにちは、私は助手です」と言います。
Anthropic は「やあ、私はシステムです」と言います。
Google は「こんにちは、私はコンテンツです」と言います。

これらはすべて「AI に質問して答えを返す」という同じことをしていますが、言葉の使い方が微妙に違うのです。

🚧 問題点：「2 乗の壁」

もし、あなたがこれらの AI たちをすべてつなげたいと思ったらどうなるでしょうか？
A 社と B 社をつなぐ翻訳機、B 社と C 社をつなぐ翻訳機、A 社と C 社をつなぐ翻訳機……と、すべての組み合わせごとに専用の翻訳機を作らなければなりません。

AI 会社が 10 社いたら、必要な翻訳機は 45 個！
これが 100 社いたら、4,950 個も必要になります。これを専門用語で**「O(N²) の問題」と呼びますが、簡単に言えば「組み合わせが爆発的に増えて、とても大変」**ということです。

💡 解決策：「ロゼッタ」の登場

ここで登場するのが、この論文で提案されている**「LLM-ロゼッタ」**という仕組みです。

🗺️ 比喩：「共通の言語（ハブ）」を使う

このプロジェクトは、**「ハブ＆スポーク（車輪のハブとスポーク）」**という考え方を使っています。

ハブ（中心）： 世界中のすべての AI が理解できる**「共通の中間言語（IR）」**を作ります。
スポーク（外側）： 各 AI 会社（OpenAI など）は、自分の独自の言語をこの「共通言語」に翻訳するだけでいいのです。

**「A 社⇄B 社」を直接つなぐのではなく、「A 社⇄共通言語⇄B 社」**という形にします。
これで、100 社の AI があっても、必要な翻訳機は「100 社分＋共通言語 1 つ」で済みます。劇的に楽になります！

🧩 なぜこれがうまくいくの？

実は、これらの AI たちの言葉は、「表面的な文法（単語の並び）」は違うけれど、「意味（中身）」はほとんど同じなんです。

「思考のプロセス」
「ツール（計算機など）を使うこと」
「画像や音声を送ること」

これらはどの AI も持っています。LLM-ロゼッタは、この**「共通する中身」**を 9 種類の「コンテンツの部品」と 10 種類の「イベント（出来事）」に整理した辞書（中間表現）を作りました。

⚙️ 仕組み：レゴブロックのような設計

この翻訳機は、**「 Ops（オペレーション）コンポジション」**という、まるでレゴブロックを組み立てるような設計になっています。

コンテンツの翻訳： 文字、画像、音声、ツール呼び出しなどを翻訳するブロック。
メッセージの翻訳： 「誰が話したか（システム、ユーザー、助手）」を翻訳するブロック。
設定の翻訳： 「温度設定」や「出力の長さ」などを翻訳するブロック。

新しい AI 会社が増えたら、このブロックを新しい会社のルールに合わせて少し変えるだけで、すぐに翻訳機が作れます。既存のブロックはそのまま使えるので、とても効率的です。

🚀 すごいところ：リアルタイム翻訳と「完全な復元」

1. 流れるように話す（ストリーミング対応）

AI は答えを全部まとめて返すのではなく、**「単語が一つずつ流れてくる」**ように話すことがあります。
LLM-ロゼッタは、この「流れてくる言葉」もリアルタイムで翻訳できます。まるで、通訳が隣で即座に翻訳しているように、遅延なく会話が続きます。

2. 完全な復元（ロスレス）

「A 社の言葉」を「共通言語」に通して、また「A 社の言葉」に戻したとき、元の文章と 100% 同じになるように設計されています。
これは、翻訳して戻したときに「元のニュアンスが失われていないか」を確認するのに役立ちます。

📊 結果：実際に使われている！

このプロジェクトは、単なる理論ではなく、アメリカのアルゴンヌ国立研究所という大規模な研究機関で、実際に使われています（Argo-Proxy というシステムの一部）。

テスト： 1,300 以上のテストをすべてクリア。
速度： 翻訳にかかる時間は100 マイクロ秒（0.0001 秒）以下。人間の目が瞬きする間にも、何千回も翻訳が完了する速さです。
効果： 以前は手作業で 2,000 行以上のコードを書いていたものが、このシステムを使うことで整理され、OpenAI、Anthropic、Google などの主要な AI をすべてつなげられるようになりました。

🌟 まとめ

LLM-ロゼッタは、AI 業界の「言語の壁」を取り払うための**「万能な翻訳ハブ」**です。

問題： 各 AI がバラバラの言葉を使っていて、つなげるのが大変。
解決： 共通の「中間言語」を作って、すべてをそこに翻訳する。
メリット： 新しく AI が増えても簡単に対応できるし、超高速で、正確。

これにより、開発者たちは「どの AI を使うか」に悩むことなく、**「一番いい AI を選んで、自由に組み合わせる」**ことができるようになります。まるで、世界中の AI が同じテーブルで仲良く会話しているような未来を実現する、とても素敵なプロジェクトなのです。

LLM-ROSETTA: クロスプロバイダー LLM API 翻訳のためのハブ・アンド・スポーク中間表現

技術的サマリー（日本語）

本論文は、大規模言語モデル（LLM）プロバイダー間の API 形式の断片化という課題に対し、LLM-Rosetta というオープンソースの翻訳フレームワークを提案するものです。これは、コンパイラ設計やデータ交換で確立された「ハブ・アンド・スポーク（Hub-and-Spoke）」パターンを LLM API 翻訳に応用し、プロバイダー固有の形式を中立的な中間表現（IR）を介して相互変換可能にするものです。

以下に、問題定義、手法、主要な貢献、評価結果、および意義について詳述します。

1. 問題定義：API 形式の断片化と $O(N^2)$ の課題

現在、OpenAI、Anthropic、Google などの主要 LM プロバイダーは、それぞれ独自の API スキーマ（メッセージ構造、ツール呼び出し、ストリーミングイベント、生成制御など）を定義しています。

現状の課題: アプリケーション開発者は、各プロバイダーに特化した「接着コード（Glue code）」を記述する必要があり、複数のモデルを評価・利用する組織には統合の負担が伴います。
組み合わせ爆発: $N$ 個のプロバイダーが存在する場合、単純なペアワイズ（双方向）翻訳を実装するには $N(N-1)/2$ 個のアダプターが必要となり、計算量と保守コストが $O(N^2)$ 的に増加します。
既存ツールの限界:
- LangChain/Semantic Kernel: アプリケーションレベルの抽象化を提供しますが、生 API ペイロードのフォーマット変換層は提供していません。
- LiteLLM: OpenAI 形式を共通言語（リンガ・フランカ）として使用しますが、特定プロバイダーの機能（キャッシュ制御やグラウンディングメタデータなど）が失われるか、ターゲット形式にない構造は表現できません。また、双方向変換や完全な損失なしの往復変換には対応していません。

2. 手法：ハブ・アンド・スポーク中間表現（IR）

LLM-Rosetta は、主要な LLM API 間の構文の違いは大きいものの、意味的なコア（共通部分）は存在するという洞察に基づいています。

2.1 中間表現（IR）の設計

すべての主要プロバイダーの機能網羅を可能にする、プロバイダー中立な型付きデータ構造を定義しました。

9 種類のコンテンツモデル: テキスト、画像、オーディオ、ファイル、ツール呼び出し、ツール結果、推論（Reasoning）、拒否（Refusal）、引用（Citation）などのアトミックな単位。
10 種類のストリームイベント: セッション開始/終了、コンテンツブロックの開始/終了、テキスト/推論/ツール呼び出しのデルタ、完了、使用統計など。
メタデータ: プロバイダー固有の属性を保持するための provider_metadata フィールドや、拡張用の provider_extensions を備え、損失なしの往復変換を可能にしています。

2.2 オペレーション合成アーキテクチャ（Ops-Composition）

各プロバイダー用コンバーターを単一の巨大なクラスとして実装するのではなく、4 つの直交するモジュールに分解する設計を採用しています。これにより、既存プロバイダーのコードを変更せずに新しいプロバイダーを追加できます。

ContentOps: コンテンツ部分（テキスト、画像、ツール呼び出しなど）の変換。
MessageOps: メッセージシーケンス、ロールマッピング、システムプロンプトの抽出。
ToolOps: ツール定義とツール選択設定の変換。
ConfigOps: 生成パラメータ、推論設定、レスポンス形式、キャッシング設定の変換。

2.3 双方向変換とストリーミング対応

双方向性: 要求（Request）と応答（Response）の両方で、Provider A ↔ IR ↔ Provider B の変換が可能です。
ストリーミング: 各プロバイダーが異なる SSE（Server-Sent Events）スキーマを使用する問題に対し、IR 上で 10 種類の標準化されたイベントに正規化し、状態管理（StreamContext）を通じて順序と整合性を保ちながら、チャンクレベルでリアルタイム変換を行います。

3. 主要な貢献

API 発散の実証的解明: 主要 4 社（OpenAI Chat/Responses, Anthropic, Google）の API は構文の違いこそあれ、共通の意味的コアを持つことを示し、それを 9 種類のコンテンツと 10 種類のストリームイベントで捉えることを実証しました。
型付き IR と Ops 合成アーキテクチャ: 構文の違いを扱うためのモジュール化されたコンバーター設計により、新規プロバイダーの追加コストを最小化し、テスト容易性を高めました。
完全な双方向変換とストリーミング対応: 生ペイロードの損失なし往復変換（Lossless Round-trip）と、状態管理を伴うストリーミング変換を実現しました。
実証的評価と実運用: 1,364 件のテスト（Open Responses 準拠テストを含む）を通過し、サブミリ秒のオーバーヘッドで動作することを実証。Argonne 国立研究所の生産環境（Argo-Proxy）で導入されています。

4. 評価結果

往復忠実度（Round-Trip Fidelity）:
- 4 社すべてのプロバイダー間で、1,364 件のテスト（987 件のコンバーター単体テスト＋377 件の IR/ロジックテスト）を 100% 通過。
- 「Preserve モード」ではプロバイダー固有のメタデータを含め完全な等価性を、「Strip モード」では意味的に重要なフィールドのみを保持してクロスプロバイダー転送を可能にしました。
- OpenRouter が提供する「Open Responses 準拠テストスイート」の全 6 項目を合格。
ストリーミングの正確性:
- 各プロバイダーのイベント順序の違い（例：Google の累積パース、Anthropic の明示的なブロックライフサイクル）を正しく処理し、IR 上で整合性のあるイベントシーケンスを生成しました。
クロスプロバイダー翻訳:
- 6 通りのプロバイダーペア（例：OpenAI Chat ↔ Anthropic）間の変換において、メッセージ内容、ロール、ツール定義、画像データなどの意味的コンテンツが正しく維持されました。
- 表現力の差（例：Anthropic のキャッシュ制御が Google 形式にないなど）は、警告を記録しつつ対象プロバイダーにない機能は破棄する戦略をとっています。
パフォーマンス:
- 変換オーバーヘッドは100 マイクロ秒未満（中央値 21〜77 µs）。
- LiteLLM の一方向変換と比較して、単純なテキストでは同等かそれ以上（24 µs vs 28 µs）、複雑なタスクでも 1.6〜2.2 倍程度のオーバーヘッドに留まり、ネットワーク遅延や推論時間に比べれば無視できるレベルです。
- 双方向性やプロバイダー中立性という追加機能を得るためのコストとして許容範囲内です。

5. 意義と結論

LLM-Rosetta は、LLM エコシステムにおける「相互運用性」の重要なインフラを提供します。

アーキテクチャ的意義: コンパイラ分野の IR 概念を LLM API 領域に適用し、 $O(N^2)$ のアダプター問題を $O(N)$ に削減する実用的な解決策を示しました。
実用性: 特定のアプリケーションフレームワーク（LangChain など）に依存せず、生 API レベルで動作するため、既存のシステムやゲートウェイ（Argo-Proxy のように）に容易に統合可能です。
将来展望: 現在サポートされている 4 つの API 標準は市場の大部分をカバーしており、新しいプロバイダーがこれらに準拠すれば即座に対応可能です。今後の課題としては、埋め込み（Embeddings）やファインチューニングなど、チャット以外のモダリティへの対応、およびより包括的な準拠テストスイートの構築が挙げられます。

総じて、LLM-Rosetta は、LLM プロバイダー間の断片化を解消し、アプリケーションのポータビリティとマルチプロバイダーアーキテクチャを可能にする、実用的かつ高性能な基盤技術です。