プロジェクトの途中でAIモデルを切り替え、コンテキストを失わない

新機能の開発に一時間かかっているとします。最初のタスクは新しいAPIルートの足場づくり——反復的でリスクも低く、最も速く安いモデルが三十秒で終わらせる作業。そこから本物の難しい部分に入ります。六ファイルにまたがるデータモデルの移行で、エッジケースについて本当の推論が必要です。これは別の仕事で、より強いモデルが要るとわかっています。次はCSSレイアウトの修正で、それもまた別の種類のタスク。そしてまたバックエンドロジックへ。

AIツールを使う経験豊富な開発者はみんなこの感覚を知っています。どの単一モデルもすべてに最適ではなく、タスクごとの「最適」は時間単位で変わる。問題は良いモデルを選ぶことではありません。ほとんどのツールがセッション全体で一つのモデルを選ぶことを強制し、プロジェクトの途中で切り替えると線を失うことです。

これは仮定の話ではありません。AIコーディングツールを毎日使う人に聞くと、みんな同じパターンを語ります。彼らは好みではなく、妥協として一つのモデルに決めているのです。最も速くもなく、最も強い推論でもなく、使っているフレームワークに最も適しているわけでもない——朝9時に選んで、午後2時に蒸し返したくないから選んだだけ。ツールがその決定を固定してしまったので、決定は適合の話ではなく慣性の話になりました。

タスクとモデルのミスマッチは実際にあり、絶えず起きている

速くて安いモデルは、ボイラープレート、反復的な編集、パターンが自明な作業に秀でています。強くて高価なモデルは、本物の推論——アーキテクチャ判断、手強いバグ、間違えると高価なリファクタ——で元を取ります。フロントエンド/CSS作業に特に調整されたモデルもあれば、バックエンドロジックに向くもの、多数のファイルにわたる機械的で簡潔な変更に向くものもあります。出力を並べて比較したことのある人は、どの仕事にどのモデルが欲しいかについてすでに意見を持っているはずです。欠けているのは意見ではありません。

これらはもはや新しくはありません。不足しているのはツールの側です。Cursorのような単一ペインのエディタなら、セッション開始時に選んだモデルは、そのセッションのすべてに付きまといます。些細なリネームも、手強い移行も、同じモデルを通る。切り替えるには新しいチャットを開くことになり、ファイルも制約も、試したことの説明を最初からやり直す必要があるからです。

本物のフィーチャーブランチが一日で実際に何を伴うか、考えてみてください。DBマイグレーション、新しいAPIエンドポイントが三つ、フォームのバリデーション、設定ページのリデザイン、去年他の人が書いたコードのバグ修正。これは五種類の性質の仕事であって、一つのモデルに連続した一つの仕事として扱うのは、あなたのためではなくツールの都合です。ツールは「ユーザーに設定させない」ことを最適化していて、そのコストの少なくとも半分は、リストの大半をあなたの側が吸収しているのです。

今日、モデルを「切り替える」実際にかかるコスト

スレッド一本のAIエディタでは、モデルの変更は設定ではなくコンテキストのリセットです。新しいモデルは、前のモデルが何をしていたか、どんな決定が下されたか、どのアプローチがすでに失敗したかを知りません。結局、ファイル内容を貼り直し、バグを説明し直し、十分前に確定したはずの制約をもう一度確立することになります。だからほとんどの人は切り替えないのです。切り替えコストがミスマッチコストより高いので、一つのモデルを選び、半分のタスクで間違えられても我慢します。

それが「各タスクに最適なモデルを使う」という、誰もが正しいと同意している方法が、現実には起きない本当の理由です。

しかも増幅します。手強いリファクタについて自信満々に間違えるモデルは、修正をやり直す時間だけでなく、間違いに気づく時間、実際に何が壊れているかを説明する時間、そして同じモデルが今度は上手くやると希望する時間までも要求します。唯一の手段が「同じモデルでもう一度」なら、ミスマッチの内側で反復することになり、外に出られません。複数のエージェントを同時に走らせることは抽象的にはよく話されますが、モデル切り替えの観点は特に話題になりにくい。おそらくほとんどのエディタでは、それに気づく機会がないからです。

meshcodeのペインはどう解決するか

meshcodeは各ペインを独立したエージェントセッションとして動かし、モデルはペインごとに選べます。一つのペインで、慎重な推論が必要な移行にClaudeを走らせる。同時に開いた別のペインでは、速いモデルにボイラープレートを消化させる。三つ目は、CSSに一番効くと感じるモデルを。共有チャットで順番に待つわけではなく、それぞれ別のセッションで、希望すれば並行して、それぞれが自分のモデルで動きます。

重要なコンテキスト——実際のコード——はチャット履歴の中に閉じ込められていません。ディスク上、プロジェクトの中にあります。どのペインでも任意のファイルを開き、別のペインが直後に変更したところを見て、続けられます。新しいモデルにプロジェクトを毎回説明し直すのではなく、同じコードベースに違うモデルを指すだけです。モデルの切り替えは会話のリセットではなく、新しいペインを開くだけのコストになります。

これは事前にコミットしていないという意味でもあります。速いモデルのペインが、見た目より難しいタスクで手に負えないと判明したら、より強いモデルの新しいペインを開いて同じファイルを渡せば、線を失うことはありません。そもそも失う線が一本もなかったからです。

普通の午後に何が起きるかを、具体的に描いてみます。新しいAPIルート用のペインを開き、速く安いモデルを指します。作業は機械的で、パターンはコードベースの他所に確立済みで、推論モデルの価格を払うつもりはありません。同時に開いた二つ目のペインでは、移行により強いモデルを指します。スキーマ変更を間違えると高価なので、エッジケースを捕まえるのに最も向いたモデルが欲しいからです。三つ目のペインでは、フロントエンドに効くモデルに設定ページのリデザインを渡します。これらのペインは互いに待たず、他二つが何をしているかを伝える必要もありません。これまでの進み具合をすでに反映した、ディスク上のファイルを読むだけです。移行のペインが終わってAPIルートのペインに戻ると、新しいスキーマが見えます。スキーマは会話の中にあった記憶ではなく、ファイルだからです。

これはより狭い用途にも使えます。まったく同じバグに、二つの別のペインで違うモデルを向けて、どちらの修正にもコミットする前に、それぞれの返って来るものを比べる。モデルがセッション全体の単一グローバル設定であるツールでは、気軽にできることではありません。

従来のやり方 vs meshcode

これは特定のモデルへの批判ではありません。meshcodeの要点は、プロジェクト全体を1つのモデルに賭け強要されないことです。主要三社の間の選び方についてはClaude vs. Codex vs. Cursor比較で、複数エージェントの並走についてはマルチAIコーディングワークフローガイドで詳しく書いています。

meshcodeはアーリーアクセス中です。最新の料金はダウンロードページをご覧ください。

で、meshcodeはあなたに合いますか？

• 今のモデルではタスクによっては合わないと感じたことがあっても、切り替えは面倒すぎて試したことがない。
• すでに複数のAIプロバイダーを使っている（推論にはClaude、速度やコストのために別のもの）が、アプリを切り替えたり回したりせずに、同じプロジェクトで働いてほしい。
• 定額サブスクに疲れて、静かな週も忙しい週も同じ$20を払うのではなく、実際に使った分だけ払いたい。
• AIのコンテキストがチャットウィンドウに閉じ込められず、ファイルの中にあってほしい。ツールを変えるたびにリセットされるのがうんざりしている。
• 同じモデルに二度払いたくないので、自分のClaudeやCodex CLIのログインを持ち込みたい。
• タスクの途中で、「この一部分だけ別のモデルに渡せたら」と思ってしまうことがある——その直感こそが、ペインの存在理由です。

どれもピンとこず、どこでも一つのモデルを選び、そのトレードオフと付き合うので満足なら、単一ペインのエディタの方がシンプルです。でも「この一部分にだけ別のモデルを投げたい」と思ったことが一度でもあるなら、それはまさにmeshcodeのペインが埋めるために作られたギャップです。

👉 meshcodeをダウンロード — Mac、Windows