OpenRouter APIの「モデル切り替え」は、台本の書き直しまでしてくれる？
短い動画の台本をAIに頼むなら、最初の案がいまいちだったときの直し方まで考えておきたいんです。
文章は返ってきたのに、冒頭がぼんやりしている。説明は合っていても、映像にすると何を見せればいいのか分からない。
そういう台本を、別のモデルに渡して見直してもらう流れは作れそうだな、と思いました。
そこで気になったのが、OpenRouter APIのモデル切り替えです。
候補のモデルを並べておけば、必要に応じて次へ進んでくれる。ただ、この「必要に応じて」が何を指すかで、制作フローの組み方は変わります。
先日、OpenRouterが公開した記事を読みました。モデルの選択、提供元の選択、作業全体の管理を、別々の役割として整理している内容です。
私は普段、AI Codingを入れる前に「どこで止まるか」を見るタイプです。台本づくりでも、まずここを分けて理解したいと思いました。
まだ手は動かしていないので、今回は設計メモとして残します。
エラーで切り替わることと、台本を直すこと
OpenRouterのmodelsパラメータには、使いたいモデルを優先順に並べられます。
最初のモデルでエラーが起きると、次の候補を試す。これがモデルのフォールバックです。利用制限やサービス停止などで応答を得られないときに、別のモデルへ回る経路を用意できます。
一方で、台本が正常に返ってきたあとはどうでしょうか。
「説明が長すぎる」「言い回しがありきたり」と感じても、それを理由に次の候補へ切り替わるわけではありません。
OpenRouterが説明しているフォールバックは、出力の品質を評価して切り替える仕組みではないからです。初稿を別のモデルに見直してほしいなら、その依頼を次の工程として自分で用意する必要があります。
「台本が返ってこなかった」と「返ってきた台本を採用したくない」では、次にやることが違います。これがけっこう、大事で。
前者なら、代わりのモデルを試す経路を用意します。後者なら、何を直したいのかを伝えます。
ちなみに、モデルを切り替えることと、同じモデルを提供する事業者を切り替えることも別の話です。OpenRouterのプロバイダー選択は、選んだモデルをどの提供元で動かすかを扱います。
提供元が変わることと、別のモデルに台本を批評してもらうことは、混同しないようにしたいところです。
ここまでを整理すると、似て見える3つは別の話でした。
返事が来ない → モデルのフォールバック（modelsに候補を並べる）
同じモデルの提供元を変えたい → プロバイダー選択
返ってきた台本を直したい → 見直しの依頼を、次の工程として用意する
「もう一度考えて」だけでは、見直す場所が曖昧になる
ざっくり言うと、私なら台本づくりをこんな順番に分けます。
企画メモ → 初稿 → 指定した観点で見直す → 人が採用を決める
初稿を作る工程と、見直す工程で、それぞれ使うモデルを選びます。必要なら、各工程にエラー時の代替モデルも設定します。
具体的には、見直しの依頼で次の点を渡したいです。
冒頭で、この動画が何を伝えるのか分かるか
映像にできない抽象的な説明が続いていないか
素材にない事実や、確かめていない数字を足していないか
「もっとよくして」だけより、直してほしい場所が具体的になります。これは私が考える使い方で、OpenRouterが自動でこの基準を当ててくれるという意味ではありません。
レビューするモデルには、元の企画メモや守ってほしい条件も渡します。初稿だけだと、何のための動画なのかが伝わらないことも考えられるからです。
そして、別のモデルが確認した文章でも、事実確認まで済んだ扱いにはしません。気になる主張は元の資料に戻って確かめ、最終的に使う表現は人が選びます。
コードレビューと同じで、AIが「問題なし」と言っても、マージするかどうかは人が決めるものだと思っています。
私は、候補が増えることよりも、どの理由で書き直したのかが分かる流れにしたいです。修正理由がログのように残っていれば、次の台本にも同じ確認項目を使い回せます。
どこまでOpenRouterに任せるか
初稿を作って、別のモデルで見直す。そのくらい決まった順番なら、まずは各工程のAPI呼び出しと、結果を渡す処理から考えられます。
工程が増えてくると、管理するものも増えます。途中で人の確認を待ちたい、保存した状態から再開したい、条件に応じて別の作業へ進めたい。そういう要件が出てきたときの話です。
LangGraphは、状態を持つ処理や中断・再開、人の確認を組み込むための仕組みを提供しています。モデルへのアクセスはOpenRouterに任せて、作業の順番や状態は別の層で管理する構成も取れます。
OpenRouter側にも、Agent SDKがあります。ツールの実行と、その結果をモデルへ戻す繰り返しを扱うSDKで、TypeScriptでも使えます。公式の紹介ページでは、人の承認待ちや実行の再開にも触れられています。
単発のAPI呼び出しから、ツールを使う処理へ進みたいときの選択肢です。ただ、modelsに候補を並べるだけで、こうした工程まで生まれるわけではありません。
私なら、最初に台本づくりで困っていることを書き出します。
返事が来ないことに困っているのか。返ってきた文章を直す手間が大きいのか。それとも、どこまで確認したか分からなくなるのか。
そこが分かれば、代替モデルを設定する、レビュー工程を足す、状態を保存する、と次の作業を選べます。
※PR：WaveSpeedAIについて
台本が固まったあとに、画像や動画の素材生成もAPIで扱いたい方は、WaveSpeedAIのAPI導入手順が参考になると思います。APIキーの発行から結果の取得までの流れが載っています。
文章を整える工程と、素材を作る工程を分けて、まずは小さな素材生成から結果の取得まで確認してみてください。
一点だけ補足します。手順ページによると、APIキーは入金してからでないと有効にならないようです。試す前に、確認しておくと安心です。
モデルの紹介や使い方の記事は、WaveSpeedAIのブログにまとまっています。
まずは、同じ企画メモから初稿と修正版を作って、修正理由と一緒にdiffで見比べられるところまで組んでみたいと思っています。
AI Codingのときと同じで、便利そうだから入れる前に、どこで止まるかを見ておきたいんです。
この記事が誰かの参考になればうれしいです。
