何がリリースされ、それによって実際に何が可能になったのか
ori は curl -fsSL https://openrouter.ai/labs/ori/install.sh | bash でインストールできます。OpenRouterの認証情報でログインし、それを通じてハーネスを実行します。OpenRouterは、これが解決する課題について率直に語っています。「OpenRouterのようなゲートウェイを使用する場合、Anthropicのファーストパーティ製ハーネスを使用するのと同等の体験をClaude Codeで即座に得るには、非常に多くの環境変数を設定する必要があります」また、このCLIは実行中の環境にも適応します。「ori claude では、--model フラグを検出し、使用しているモデルに最も最適になるように設定を切り替えます」
これと並行して、OpenRouterのClaude Codeクックブックには、3つの環境変数を使用してCLIをAnthropic互換のエンドポイントにリダイレクトする方法が記載されています。これが整えば、クレジット経由で課金されるClaudeモデルを使い続けることも、Opus、Sonnet、Haikuの「スロット」をより安価なオープンモデル（GLM-5.2、DeepSeek V4、Qwen3-Coder、Kimiなど）に置き換えることも可能になります。
Googleのゲートウェイアプローチは、インフラ側から同様の動作をターゲットにしています。OpenAPI 3.x仕様で仮想モデル名を設定し、Gemini、Claude、OpenAIのOSS-GPTモデルを含むバックエンドにそれらを紐付け、エンドポイントをハードコーディングしたり独自のプロキシを実行したりすることなくトラフィックをルーティングします。
価格設定も同じ方向性を後押ししています。OpenAIのチームは、GPT-5.6 Lunaの80%の値下げはプロモーションではなく恒久的なものであると公言しており、同週の業界分析では、AnthropicのFable 5が100万出力トークンあたり$50で登場した数日後にこの値下げが行われたことが指摘されています。具体的な数値は2026年8月初旬時点のものであり、計画を立てる前に現在の価格を確認してください。しかし、方向性に疑いの余地はありません。モデルの選択はタスクごとの意思決定になりつつあり、ツール側もそれを頻繁に行うことを前提として設計されています。
モデルを切り替えるとコンテキストがリセットされる理由
モデルは呼び出し間で状態を保持しない
すべてのリクエストは自己完結しています。モデルがあなたのプロジェクトについて「知っている」ように見える内容はすべて、そのリクエストのコンテキストウィンドウに渡されたものであり、リクエストの終了とともに消え去ります。Cursor自体のドキュメントにも、一般的なケースが明快に述べられています。「大規模言語モデルは、補完（completion）間でメモリを保持しません。」ルーティングによってこれが変わることはありません。ゲートウェイはリクエストを転送するだけであり、知識を蓄積するわけではないからです。
各ベンダーのメモリ機能はベンダー独自のもの
現在使用されているツールには、実際に機能するメモリ機能が備わっており、それらは非常に有用です。しかし、それらはそれぞれ独自の製品にロックインされています。Claudeのメモリ、ChatGPTの合成クロスチャットメモリ、Codexのローカルメモリファイル、IDEのルールディレクトリなどです。リクエストを別のバックエンドにルーティングすると、これらは一切引き継がれません。そもそもリクエストの一部ではなかったからです。
ハーネスの設定はコンテキストではない
これは ori によって陥りやすくなる誤解です。環境変数、モデルスロット、推論設定がすべて自動で処理されると、切り替えが完全に完了したように感じられます。ツールが起動し、モデルが応答し、すべてが設定されているように見えます。しかし、実際に移動したのは「配管（インフラ）」だけです。コードベースに関する蓄積された知識、これまでの決定事項、行き詰まったアプローチ、特定のモジュールが不自然に見えるもののそのままでなければならない理由などは、どこにも移動していません。
安価なモデルは問題を軽減するどころか、より顕著にする
ルーティングの経済的なメリットは本物です。日常的な作業は安価なモデルに送り、高価なモデルは困難な問題のために温存します。しかし、コンテキストを持たない安価なモデルは、修正が必要な成果物を出力しがちであり、その修正には節約しようとしていたはずの人間の時間が費やされます。コスト削減が実現するのは、安価なモデルが高価なモデルと同じ理解度を持ってスタートできる場合に限られます。
人々が試みる対策
ブリーフィングの再貼り付け。 各セッションの冒頭にプロジェクトのコンテキストをまとめたブロックを貼り付ける方法です。これは機能し、汎用的であるため、ほぼすべての人が行っています。しかし、呼び出しのたびにトークンコストが発生し、また要約であるため、誰かが短く書き直すたびに詳細が失われていきます。
指示ファイル。 AGENTS.md、.cursor/rules、CLAUDE.md、.trae/rules など。これらは常に適用すべきルールに適したツールであり、ほとんどのハーネスは背後にあるモデルに関係なくこれらを読み込むため、最もポータブルな選択肢です。しかし、これらは知識ストアではありません。毎週肥大化する900行のプリアンブルを手動でメンテナンスしたい人はいませんし、リクエストごとに読み込まれるルールは、リクエストごとにコストを支払うことになります。
すべての作業に1つのモデルを使い続ける。 最もシンプルな解決策、つまり切り替えを避けることです。しかしこれは、些細な作業に対してプレミアムな料金を支払い、特定のタスクに最適なモデルを使用しないことを意味します。
ツールごとのメモリ機能。 あらゆる場所でメモリ機能をオンにして、うまくいくことを祈る方法です。結果として、断片的な理解がいくつも生まれ、それらが乖離していき、最悪のタイミングでそのズレに気づくことになります。これは、複数のエージェントが共有メモリなしで動作するときに必ず発生する失敗と同じです。
リポジトリに対する検索（Retrieval）。 有用であり、何もないよりはマシです。しかし、検索はクエリに類似したテキストを見つけるだけであり、6月に行った決定や、すでに却下したアプローチを保持しているわけではありません。これが、検索単体ではメモリにならない理由です。
解決策：ルーターが干渉できないレイヤーにコンテキストを保持する
モデルが交換可能なコンポーネントになったのであれば、コンテキストをモデルの内部に置くのをやめなければなりません。知識を独自のレイヤーに配置し、ルーティング先のどのモデルからでもそれを読み取れるようにします。これは、ori がどのモデルを選択しても同じハーネスを使用できるようにするのと同じ仕組みです。
MemoryLake は、スタックにおけるまさにその位置のために構築されています。メモリを独自のレイヤーとして扱い、MCPやAPI経由でアクセス可能にし、前回どのモデルが応答したかに依存しないようにします。
ステップ 1: APIキーを作成する
キーを生成すれば、約30秒で最初のリクエストを送信できます。
ステップ 2: 最初のメモリをアップロードする
どのモデルが稼働しているかに関係なく、すべてのモデルが必要とする資料（アーキテクチャのメモ、APIコントラクト、決定ログ、ランブック、コードからは明らかでない規約など）を読み込みます。ドキュメント、画像、その他のファイルはすべて同じ場所に保存されます。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、その他のエージェントにMCP経由でアクセスを許可します。ネイティブのMCPクライアントではなくゲートウェイ経由でアクセスするものについては、APIを通じて関連するメモリを取得し、ルーターが転送するリクエストにそれらを含めます。ルートは変わりますが、モデルがプロジェクトについて知っていることは変わりません。
実務においてこれがもたらす変化
第一の効果は、ルーティングの決定が純粋に経済的なものになることです。現在、安価なモデルを選択することには「コンテキスト再構築コスト」という隠れたコストが存在します。そのため、チームはそれほど高度な処理を必要としない作業であっても、静かに高価なモデルを使い続けています。そのコストを取り除けば、「このタスクにはどのモデルが適しているか」という問いに、価格と機能だけで答えることができるようになります。これこそが、ルーティングエコシステム全体が前提としていることです。
第二に、新しいモデルのリリースに振り回されなくなります。ここ数ヶ月だけでも、切り替える価値のあるフロンティアモデルのリリースが6〜7回ありました。新しいモデルを評価するたびにコードベースの理解を再構築しなければならないとしたら、おもちゃのような問題でしか評価できず、有用な知見は得られません。コンテキストが共有されていれば、同じメモリを指し示すだけで、半日で実用的な比較を行うことができます。
第三に、混在するモデル群全体での一貫性です。安価なモデルがテストの足場（scaffolding）を処理し、フロンティアモデルがアーキテクチャを処理する場合、それらはシステムに対する同じ理解に基づいて動作する必要があります。そうでなければ、安価なモデルの出力が高価なモデルの設計と矛盾し、誰かがその修正に追われることになります。
マルチモデルセットアップのベストプラクティス
ルールと知識を異なる場所に保管する
指示ファイルはハーネスやモデル間での移植性に優れているため、常に適用すべきルールに使用します。一方で、増え続けるプロジェクトの知識はメモリレイヤーに配置します。これにより、リクエストごとに巨大なプリアンブルのコストを支払う必要がなくなり、毎週変更されるファイルを手動で編集する手間も省けます。
どこにルーティングしたかだけでなく、なぜルーティングしたかを記録する
「テスト生成は安価なモデルに送る」という決定は、午前2時のオンコール担当者によって静かに覆されてしまう可能性があります。「テスト生成を安価なモデルに送るのは、フロンティアモデルの優位性が我々のテストスイートにおいて3%未満と測定されたためである」という記録であれば残り続け、次の担当者に何を再測定すべきかを伝えてくれます。
ルーティングを再設定する際は事実を再検証する
モデルの機能、コンテキスト制限、価格は毎月変動しており、この記事の具体的な内容は2026年8月初旬時点のものです。ルーティングポリシーを確定する前に、一次情報で最新の数値を確認してください。これまでのすべてのモデル切り替え（Opus 5、DeepSeek V4、GPT-5.6など）から得られる一般的な教訓は、最も重視すべきベンチマークはあなた自身のコードベースであるということです。
結論
今週、ツールが追いつきました。ori により、Claude Code、Codex、OpenCode、Hermesを任意のモデルに対して実行することが1行のインストールで可能になり、ゲートウェイレベルのルーティングにより、インフラレイヤーでも同様のことが実現しました。モデルの選択はタスクごとの意思決定となり、切り替えを稀なものにしていた摩擦はほとんど解消されました。
しかし、日々の業務で最も重要となる問題は解決されていません。モデルは呼び出し間で状態を保持せず、ベンダーごとのメモリ機能は他のベンダーに引き継がれず、完璧に設定されたハーネスであっても、リポジトリを初対面の他人に渡すことに変わりはありません。プロジェクトの知識が、ルーティング対象 of モデルの外部にあるレイヤーに配置されるまでは、切り替えを行うたびに既存のコンテキストが失われ、切り替え先の安価なモデルは、間違った出力を出すことで節約したはずのコストを消費してしまいます。