より高性能で低コストなAIモデルが次々と登場しています。アプリをリリースした時点で理にかなっていたモデルが、数週間後には最善の選択肢ではなくなっているかもしれません。しかし、そのモデルIDが公開済みのiOSアプリやデプロイ済みサーバーに埋め込まれていると、アップグレードのたびに新たなリリースが必要になります。ユーザーがまだ古いビルドを使っている状態で、アプリケーションを最新に保つにはどうすればよいでしょうか？Haimakerを使えば、アプリケーションを再デプロイせずに利用するモデルを更新できます。 モデルIDとしてhaimaker/autoを送信し、ダッシュボードでデフォルトモデルやプロンプトごとのルールを変更するだけです。

この問題はモデルのリリースごとに繰り返されます。開発者は品質、コスト、機能をワークロードに対して検証する必要があります。モデルの選択をデプロイ済みコードの外に出しておくことで、アプリやサーバーのリリースをスケジュールしなくても、検証結果に基づいた対応が可能になります。

固定のモデルIDはリリース後に古くなる

固定のモデルIDを使うと、モデルのアップグレードがすべてアプリケーションのリリースプロセスに依存するようになります。最初のバージョンを作っている段階ではまだ管理できますが、ローンチ後は、有望な新モデルや価格変更のたびにコードの編集、テストの実行、サーバーのデプロイ、モバイルアップデートの提出が必要になる可能性があります。新モデルはリリースの合間に登場することがあります。

iOSアプリの場合、クライアントに埋め込まれたモデルIDは、アップデートをインストールしていないユーザーに対して変更できません。Appleは配布前にアプリのアップデートを審査します。新しいビルドが利用可能になっても、ユーザーが古いバージョンを使い続けることはよくあります。API呼び出しをバックエンドに移行すればプロバイダーキーをアプリ内に置かずに済みますが、そのバックエンドにハードコードされたモデルIDには、依然として設定変更やデプロイが必要です。

ゲートウェイエンドポイントだけではこの問題は解決しません。リクエストが固定のモデルを指定している限り、呼び出し側はその選択に縛られたままです。たとえばOpenRouterは、名前付きモデルのほか、独自のopenrouter/autoルーターもサポートしています。オートルーターを使えば、基盤となるモデルの選択をデプロイ済みコードから切り離せます。Haimakerでは、アプリケーションのリリース後に、独自のプロンプトクラスに対するルーティングポリシーを調整できます。

デプロイ済みアプリが新モデルに追従するには？

アプリケーションからは1つの安定したモデルIDを送信し、選択ポリシーはHaimakerで管理します。ルーターには、マッチしなかったリクエスト用のデフォルトモデルと、特定の種類のプロンプトを別のモデルに振り分けるルールがあります。ルーターはAPIキーに割り当てられます。ターゲットを変更すると、デプロイ済みの呼び出し側がhaimaker/autoを送信し続けていても、後続のリクエストは異なるモデルに到達できます。

モバイルプロダクトの場合、アプリはバックエンドを呼び出し、バックエンドがHaimakerを呼び出す構成にすべきです。これによりAPIキーをユーザーのデバイスに置かずに済みます。サーバーアプリケーションも同じパターンを直接使用できます。リクエストコードはそのままで、オペレーターがルーターを調整するだけです。セットアップドキュメントには、ルーターの作成、デフォルトの選択、APIキーの割り当て、リクエストのテスト方法が記載されています。

import OpenAI from "openai";

// Run this on your backend; do not bundle the API key in a mobile app.
const client = new OpenAI({
  baseURL: "https://api.haimaker.ai/v1",
  apiKey: process.env.HAIMAKER_API_KEY,
});

const response = await client.chat.completions.create({
  model: "haimaker/auto",
  messages: [{ role: "user", content: prompt }],
});

上記のコードは、デフォルトが変更されても新しいモデル名を必要としません。Haimakerはルーター設定を最大60秒間キャッシュするため、ダッシュボードでの編集が後続のすべてのリクエストに反映されるまで1分程度かかります。

デフォルトを更新し、低コストな処理は別途ルーティングする

デフォルトモデルを変更すると、広範なワークロードが更新されます。ルールを使えば、特定のタスクに対して新モデルが低コストまたは高性能な場合に、より限定的な変更を行えます。この区別は重要です。たとえば、長文編集には高性能なデフォルトモデルが必要でも、短いタイトル提案は低コストなモデルに送信できる場合があります。どちらの判断も、リリース後に呼び出し側のモデルIDを変更することなく実行できます。

あるライティングアプリのバックエンドが、すべてのAIリクエストを同じルーター経由で送信しているとします。新しくリリースされたモデルが長文編集の品質を向上させたため、チームはそれをテストしてルーターのデフォルトを変更します。その後、より低コストなモデルがタイトル提案に十分対応できることがわかりました。チームは「このノートに5つの短いタイトルを提案して」「この下書きに簡潔な見出しをつけて」といったサンプルを含むルールを追加し、そのルールを低コストなモデルに向けます。古いバージョンのアプリを使っているユーザーも、既存のバックエンドを通じて両方の変更を受け取れます。

サンプルベースのルールには、タスクごとに3〜10個の代表的なプロンプトを使用します。マッチしたリクエストはそのルールのターゲットにルーティングされ、マッチしなかったリクエストにはデフォルトが使用されます。機能チェックにより、ビジョン、ツール使用、構造化出力のリクエストが対応できないモデルに送信されるのを防ぎます。ルーティングログには、実際にルーティングされたモデルと、その選択に使われたルールが表示されます。マッチングとフォールバックの仕組みについては、ルーティングのウォークスルーとコストルーティングガイドをご覧ください。

ローンチ後のチームにとって何が変わるのか？

最大のメリットは、モデルの選択をリリーススケジュールではなく、ワークロードに合わせて変えられるようになることです。チームは新しいデフォルトを採用したり、繰り返し発生するプロンプトクラスを低コストなモデルに移行したり、結果が悪化した場合は以前のターゲットに戻したりできます。サーバーコードやインストール済みのモバイルクライアントは、同じAPIリクエストを送信し続けます。作業の中心は、ルーティング判断のテストとレビューに移ります。

ローンチ後の変更コード内の固定モデルの場合haimaker/autoの場合
より優れた汎用モデルが登場したモデルIDを変更し、コードまたは設定をリリースするテストした後、ルーターのデフォルトを変更する
低コストなモデルが特定のプロンプトクラスに適しているアプリケーションのルーティングロジックを追加してデプロイするそのプロンプトクラス用のルールを追加・編集する
モデル変更で出力品質が低下したコードまたは設定の変更を元に戻す以前のルーターターゲットを復元する
ユーザーがまだ古いモバイルビルドを使用している埋め込まれたモデルIDは古いままバックエンドが現在のルーターポリシーを使用できる

これは、サーバーリリースに無関係な作業が控えている場合にも役立ちます。モデルの判断をそのデプロイウィンドウまで待つ必要はありません。異なるAPIキーに割り当てることで、ワークロードごとに別のルーターを使用できます。Haimakerはキーごとに1つのルーターをサポートしています。

ルーティングの変更には、コードの変更と同じだけの判断が必要です。ダッシュボードのサンドボックスは、プロンプトがどのモデルを選択するかを示しますが、回答の品質を保証するものではありません。代表的なプロンプトを候補のモデルに対して実行し、実際の出力を確認し、選択されたモデルのログを確認し、品質が低下したら以前のターゲットに戻してください。Haimakerはモデルの選択を変更しますが、プロンプト、ツールスキーマ、アプリケーションの動作を変更するには、引き続きアプリケーション側の作業が必要です。

次のリリースに備えてモデルの選択を準備しておく

ルーターを作成し、デフォルトモデルを選択して、バックエンドが使用するAPIキーに割り当てます。リクエストにはhaimaker/autoを送信し、ワークロードを代表するいくつかのプロンプトでテストします。新しいモデルが登場したら、デフォルトや限定的なルールを変更する前に、それらのプロンプトに対して評価を行ってください。Haimakerのドキュメントには、ルーターのセットアップ、テストサンドボックス、ルーティング履歴について記載されています。

新モデルは次のアプリリリースより前に登場することがあります。モデルの選択をHaimakerで管理することで、開発者がリリースサイクルを新しいコードを必要とする変更に集中させながら、アプリケーションを最新の状態に保てます。

よくある質問

公開済みのモバイルアプリでAIモデルを変更するにはどうすればよいですか？

アプリからバックエンドを呼び出し、バックエンドからHaimakerにmodel: ‘haimaker/auto’を送信するようにします。その後、ダッシュボードでルーターのデフォルトモデルやプロンプトルールを変更すれば、新しいモバイルビルドを提出する必要はありません。ルーターの変更が反映されるまで最大60秒かかる場合があります。

Haimaker経由でモデルを切り替える際にサーバーのデプロイは必要ですか？

いいえ。デプロイ済みのサーバーがすでにmodel: ‘haimaker/auto’をルーターに割り当てられたAPIキーとともに送信している場合、ダッシュボードでルーターのモデルターゲットを変更できます。アプリケーションのプロンプト、リクエスト形式、コードの変更には、通常通りのデプロイが必要です。

シンプルなプロンプトだけを低コストなモデルに移行できますか？

はい。シンプルなタスク用に3〜10個のサンプルプロンプトを含むルールを追加し、低コストなターゲットモデルを選択します。Haimakerはターゲットがそのリクエストをサポートしているか確認し、ルールにマッチしないプロンプトにはルーターのデフォルトモデルが使用されます。

HAIMAKERをセットアップする