OpenRouter、単一のコードで複数モデルのツール呼び出しを切り替え可能な共通仕様を公開
要点
- OpenRouterは、モデル指定文字列を変更するだけでClaudeやGPT、オープンソースモデル間で同一のツール呼び出し処理を使い回せる実装手法を公開した。
- ツール定義をOpenAI互換のJSONスキーマで一度記述すれば、AIプロバイダーごとにコードを書き直す必要がなくなる。
- ツール呼び出しはモデル自身が直接外部サービスを実行するのではなく、アプリ側が実行して結果を返す4ステップのループ構造をとる。
- 応答に含まれる呼び出し要求は引数がJSON文字列の配列形式で返されるため、適切なパースとモデルごとの対応確認が必要となる。
AIモデルのAPI集約サービスを提供するOpenRouterは、2026年8月12日、単一のプログラムループを記述するだけで複数プロバイダーのAIモデル間でツール呼び出し（Tool Calling）を共通化できる実装ガイドを公式ブログで発表した。モデル名の指定文字列を差し替えるだけで、ClaudeやGPTシリーズ、オープンウェイト（オープンソース）モデルを横断して同じツール連携コードを動作させられる仕組みを解説している。
プロバイダーごとの仕様差を解消する共通アプローチ
ツール呼び出しは「ファンクションコーリング（Function Calling）」とも呼ばれ、AIモデルに対して利用可能な関数をJSON形式の仕様（JSONスキーマ）として提示し、必要に応じて構造化された引数付きの実行リクエストを返してもらう仕組みである。これまで主要なAI開発企業がそれぞれ独自にツール呼び出し機能を実装していたため、OpenAIのガイドに沿って作成した連携コードをClaudeなど別プロバイダーのモデルへ移行する際には、大幅なコードの書き直しが発生するという課題が存在していた。
OpenRouterが提供するAPIでは、業界で広く普及しているOpenAI互換のJSONスキーマ形式を共通フォーマットとして採用している。これにより開発者は、ツール定義とリクエスト・レスポンスを処理するループ構造を一度作成すれば、ツール側の実装コードを一切変更することなく、接続先のモデル名文字列を変更するだけで異なるプロバイダーのモデルへ切り替えられるようになったという。
安全性を維持する4段階の呼び出しサイクル
元記事では、ツール呼び出しが成立する一連の流れについて、以下の4つのステップで構成されるループ処理として解説されている。
- 会話とツール定義の送信: アプリケーション側から、会話履歴と共に対象となるツールの名称や引数仕様（JSONスキーマ）をモデルへ送信する。
- 呼び出し要求の受信: モデルが必要と判断した場合、関数名とJSON形式の引数が格納された
tool_callsリクエストが返される。 - ローカル側での実行と結果追加: アプリケーションが指定された関数をローカル環境で実行し、その処理結果を会話履歴の配列に追加する。
- 会話の再送と最終回答の取得: 更新された会話履歴を再びモデルへ送信し、モデルがツールの実行結果を読み取った上で最終的な回答を生成する。
OpenRouterは、モデル自身が勝手に外部のAPIを叩いたり、データベースを直接操作したり、コードを実行したりするわけではない点を強調している。モデルの役割は「どのツールをどの引数で呼び出すべきか」を構造化データとして指示することに留まり、実際の関数実行やAPIキーの管理、処理の検証、意図しない副作用の防止などはすべて開発者のアプリケーション側が制御し続けられる設計となっている。
最小限の変更で動く実装例とSDK対応
ガイド内では、都市名と単位を受け取って天気を返す get_weather(location, unit) という単一の関数を例に、具体的な実装手順が紹介されている。OpenRouterのAPIはOpenAIのAPI仕様と互換性を持つため、既存のOpenAI公式SDK（PythonまたはJavaScript/TypeScript）を利用している場合、エンドポイントのベースURL（https://openrouter.ai/api/v1）とAPIキーの設定を書き換えるだけで動作させることが可能だという。
記事中では、cURLコマンドによる直接のリクエスト例や、PythonおよびNode.js環境における処理コードが提示されている。モデルからツール呼び出し要求が届かなかった場合はそのままテキスト応答を返し、要求があった場合には引数を展開して関数を実行、その結果をメッセージ履歴に追加して再送する汎用的なループ関数 run_tool_loop の構造が解説されている。
実装時の注意点と対応状況の確認
また、ツール呼び出しを安全に実装するための注意点として、APIレスポンスのデータ構造に関する留意事項も挙げられている。モデルから返却される tool_calls フィールドは複数の呼び出し要求を含み得る配列（Array）形式であり、個々の引数（arguments）はJSON形式の文字列として渡される。そのため、受け取った側で各引数文字列を正しくJSONパース（解析）する必要があり、常に1つしかツールが呼ばれないと決め打ちしたコードにしてはならないと指摘している。
さらに、ツール呼び出し機能への対応状況や精度は各モデルによって異なるため、利用するモデルを切り替える前には、対象モデルがツール呼び出しに対応しているかどうかを事前に確認することが推奨されている。