OpenRouter gpt-oss-120b モデルが中国語リクエストをサポートしていないデバッグ記録

OpenRouter が提供する無料モデル API を使用している際、戸惑う問題に遭遇しました。全く同じリクエスト構造で、プロンプトの言語を変更しただけなのに、全く異なる結果が出力されたのです。

問題の再現

openai/gpt-oss-120b:free モデルを使用してテストを行いました。2つのリクエストの唯一の違いは、プロンプトの言語だけです。1つ目のリクエストでは中国語のプロンプトを使用しました：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-or-v1-xxxxxxxxxxxxxxxxxxxxxx" \
  -d '{
  "model": "openai/gpt-oss-120b:free",
  "messages": [
    {
      "role": "user",
      "content": "你是一个专业的本地化翻译专家"
    }
  ]
}'

このリクエストは常に 429 ステータスコードを返し、リクエストが頻繁すぎるか、クォータ制限を超えていることを示します。しかし、英語のプロンプトを使用した場合：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-or-v1-xxxxxxxxxxxxxxxxxxxxxx" \
  -d '{
  "model": "openai/gpt-oss-120b:free",
  "messages": [
    {
      "role": "user",
      "content": "You are a professional localization translation expert"
    }
  ]
}'

リクエストは正常に応答し、期待されるモデル出力が返されました。

デバッグプロセス

この一貫性のない動作は混乱を招きます。429 エラーは通常、レート制限を意味しますが、問題は2つのリクエストがほぼ同時に送信されており、レート制限の問題が存在するはずがない点です。そこで、考えられる原因を体系的に調査し始めました。

まず、API キーのクォータ制限を確認しましたが、制限を超えていないことが確認されました。次にリクエスト頻度を検証しましたが、短時間に少量のリクエストしか送信しておらず、いかなるレート制限メカニズムもトリガーされるはずがないことがわかりました。これらの一般的な原因を排除した後、唯一の変数がプロンプトの言語であることに気づきました。

より強力な AI モデルの支援を求め、Opus 4.6 Max と GPT-5.2 Extra High に相談しました。それらは現在の最も先進的な言語モデルの一部ですが、このバグの根本原因を明確に指摘することはできませんでした。これは、いくつかのエッジケースや特定の制限は、実際のテストでのみ発見される可能性があることを示しています。

手動検証

自動化デバッグツールが答えを出せなかったため、手動でさまざまな仮説を検証することにしました。簡単な挨拶、技術的な質問、長文など、異なる中国語コンテンツをテストしましたが、すべての中国語リクエストが 429 エラーを返しました。対照的に、同じ長さの英語リクエストは正常に応答しました。

この現象は、openai/gpt-oss-120b:free モデルが中国語のリクエストをサポートしていないという明確な結論を指しています。モデルが中国語コンテンツを処理する際、ドキュメントに記載されていない制限メカニズムがトリガーされ、API がよりわかりやすいエラーメッセージではなく、直接 429 エラーを返している可能性があります。

経験のまとめ

このデバッグの経験から、注目すべきいくつかの要点があります。まず、API エラーメッセージが誤解を招く可能性があることです。429 エラーは通常レート制限を示しますが、特定の状況では他の制限が隠れている場合があります。次に、自動化デバッグツールは強力ですが、万能ではありません。モデルやプラットフォーム固有の制限の一部は、実際のテストでしか発見できません。

もう一つの重要な教訓は、仮説を検証する必要性です。複数の高度な AI モデルが問題を見つけられなかったとき、手動の体系的なテストが依然として最も信頼できる方法です。変数を制御し、一つずつ検証することで、最終的に問題の根本原因を特定できます。

多言語コンテンツを処理する必要があるアプリケーションにとって、これはモデルを選択する際にドキュメントを注意深く確認するか、十分なテストを行うよう注意を喚起するものです。無料モデルには往々にして様々な制限があり、これらの制限はメインのドキュメントには明記されていない可能性があります。

関連ツール

多言語コンテンツの翻訳を処理する際、プロジェクトの多言語ローカライゼーションワークフローに特化した VS Code 拡張機能 Project Translator を開発しました。翻訳が必要なファイルを自動的に識別し、複数の翻訳サービスを統合し、翻訳の文脈の一貫性を保つことができます。

この拡張機能の設計の主眼は、実際のプロジェクトで遭遇する多言語処理の課題を解決することにあります。自動化によって手動翻訳の作業量を削減しながら、翻訳品質を保証します。開発プロセスでも様々な API 制限やエッジケースに遭遇し、それぞれの問題を注意深くデバッグし検証する必要がありました。

結び

技術的なデバッグプロセスにおいては、常に予期せぬ問題に遭遇します。重要なのは忍耐強く、体系的に考えられる原因を調査し、どんな細部も見逃さないことです。時には最も先進的なツールも役に立たず、むしろ最も基本的な検証方法が必要になることがあります。

OpenRouter は豊富なモデル選択と柔軟な API を提供しており、これがその利点です。しかし同時に、異なるモデルには異なる制限や特性がある可能性があることにも注意が必要で、使用前に十分なテストを行うのが望ましいです。無料モデルは特にそうで、それらの制限は往々にしてより厳格で不透明です。

• ←前へ
• 次へ→