ポートフォリオサイトに、訪問者が私の経歴やプロジェクトについて質問できる小さなAI機能を組み込みたかった。ただし、OpenAIやAnthropicのAPIキーを直接配線して、プロバイダーごとの請求を管理するのは避けたかった。結果的に、OpenRouterがそこへ到達する最も簡単な方法だった。
なぜOpenRouterなのか
OpenRouterは、単一のOpenAI互換APIの背後に数十のモデルプロバイダーを配置している。プロバイダーごとに別々のSDKやAPIキーを扱う代わりに、1つのエンドポイント、1つのAPIキー、そしていつでも切り替え可能なモデル文字列を得られる。トラフィックの少ないポートフォリオ用チャットボットにとっては、絶対的な最高品質のモデルを追求することよりも、この柔軟性のほうが重要だった。
安価なモデルを選ぶ
このボットは自分の経歴やプロジェクトに関する範囲の限定された質問(自由な推論ではない)にしか答える必要がないため、フロンティアモデルは不要だった。私はGemini FlashやDeepSeek Chatのような低価格帯のオプションを選んだ。これらはOpenRouterで他のモデルとまったく同じリクエスト形式で利用できる。ポートフォリオサイトの裏でバックグラウンド動作する用途でトークン単位の課金を払う場合、プレミアムモデルとのコスト差はかなり大きい。
構成
チャットボットはポートフォリオのNext.jsフロントエンドの背後で動いており、実際のOpenRouter呼び出しを処理する軽量なバックエンドサービスがある。フローはシンプルだ。
- フロントエンドが訪問者の質問をバックエンドのエンドポイントに送信する
- バックエンドが自分の経歴・プロジェクトに関するコンテキストを含むプロンプトを組み立て、安価なモデルを対象にOpenRouterへ転送する
- OpenRouterがリクエストを下層のプロバイダーにルーティングし、標準的なチャット補完のレスポンスを返す
- バックエンドがその回答をフロントエンドのチャットウィジェットに中継する
OpenRouterはOpenAIのチャット補完スキーマをそのまま踏襲しているので、後でモデルを切り替える(あるいは特定のプロバイダーに問題が起きたときに別のモデルにフォールバックする)のは、書き直しではなく単なる設定変更で済む。
知っておくべきこと
- レート制限とクォータはモデルごとに設定されており、プロバイダーによって異なるので、カジュアルな利用を超える用途で特定のモデルに決める前に、OpenRouterのモデルページを確認しておく価値がある。
- プロンプトの範囲設定が重要だ — 安価なモデルを使っているため、システムプロンプトは簡潔に保ち、コンテキストも自分の履歴書を丸ごと毎回投げ込むのではなく、関連性のある範囲に限定している。
- コストが予測可能なままなのは、OpenRouterがモデルごとのリクエスト単価を表示してくれるので、モデルを切り替える前に月間コストを見積もれるからだ。
現在の状況:動いてはいるが、RAG部分は未完成
チャットボットは稼働しており応答もしているし、会話の中である程度の記憶を保持できる。しかし検索拡張生成(RAG)の部分はまだ未完成だ。ChatGPTやClaudeのような記憶機能ほど鋭くはない。それらのシステムはコンテキスト管理と検索の面ではるかに成熟しているのに対し、私のものはまだかなり基本的な実装にとどまっている。今のところ、直近の会話コンテキストは保持できるが、より大きなナレッジベースから適切な背景情報を確実に引き出すことが、まだきちんと作り込まなければならない部分だ。
全体として、OpenRouterのおかげで、単一のベンダーに縛られることも、予算モデルで十分こなせるタスクに過剰な費用を払うこともなく、サイドプロジェクトにAIをボルトオンで組み込むのが簡単になった。次に正しく仕上げるべきは、RAGと記憶レイヤーだ。