Together AI、オープンソースモデルの品質向上と採用拡大を報告

OG 17 — MIGHT stack (2_1, 1200×600) (1).webp%20(1).webp)

OG 17 — MIGHT stack (2_1, 1200×600) (1).webp%20(1).webp)

オープンソースモデルの品質がクローズドソースモデルに迫るようになり、多くの開発者や企業が所有権、制御性、コスト面でメリットがあるとして、オープンソースモデルへの移行を検討しています。この記事では、クローズドからオープンソースへ移行する際に開発者が検討すべき「オープンモデル AI スタック」について詳しく解説します。

エージェント型ソフトウェア開発にオープンモデルを活用するには、モデルのトレーニング方法を学ぶ必要も、ラックいっぱいの GPU を購入する必要も、機械学習の専門家になる必要もありません。アプリケーション開発者の視点から見れば、このスタックはクローズドソースモデルを使うのと驚くほど似ています。プロンプトに応答するモデルと、あなたとモデルとの間のやり取りを管理するハネス（枠組み）があれば十分です。

もし Claude Code の使い方をすでに知っていれば、オープンモデルの利用も想像以上に近づいています。

The MIGHT Stack

このスタックは以下の主要な要素に分類できます：

• モデル: ユーザーの要求を解釈し、何を行うべきかを判断するコンポーネントです。
• 推論 (Inference): モデルが実際に動作するインフラストラクチャおよび推論プロバイダーです。
• ゲートウェイとルーター: 各リクエストをどのモデルやプロバイダーが処理するかを決定し、コスト、速度、能力のバランスを取るレイヤーです。
• ハーン (Harness): 会話を管理し、モデルにツールのアクセス権を与え、コードベースと接続するアプリケーションです。
• ツール (スキルおよび MCP): モデルが特定のタスクを実行する方法や、関連するコンテキストへのアクセスをモデルおよびハーンに与えるための知識です。

これらの層はすべて互いに独立しており、各レイヤーで開発ワークフローにより適した技術的な判断を下すことが可能になります。その結果、新しいモデルがリリースされた瞬間から実験を開始できます。

新しいモデルは絶えず登場します。より高速なモデルもあれば、コストパフォーマンスに優れたものもあります。また、特定の作業において驚くほど優秀なモデルも存在します。もしモデルの切り替えに数分しかかからないのであれば、ワークフローを再構築する必要なく、実際にそれらを試すことができます。

本稿では、このスタックの各層について詳しく解説し、その機能とカスタマイズの方法を探っていきます。まずはモデル層から始めましょう。

モデル (Models)

モデルはプロンプトを受け取り、学習データに基づいて最も確率の高い次のトークンを予測することで応答を生成します。当社のスタックでは、これは知能レイヤーとして機能し、推論や意思決定、コードベースにおける変更内容の判断を担当します。

モデルには様々なサイズがあり、一般的に大規模なモデルほど、複雑なタスクにおける能力、推論力、そして信頼性が向上します。現在、主要なオープンソースモデルの多くは「Mixture-of-Expert (MoE)」アーキテクチャを採用しており、多数の専門的な「エキスパート」を含みつつ、トークン生成ごとにその一部のみを活性化させます。これにより、パラメータ総数は膨大になりながら、実行時に必要な計算リソースは抑えられ、より少ない計算量で稼働することが可能になります。

大規模モデル

大規模モデルは、通常、内部のパラメータ数と学習に要する計算資源の規模によって定義されます。これらのモデルは、トレーニングデータからパターンや関係性、抽象概念を認識する驚異的な能力を持っています。実務的には、「大規模」という言葉には、より多くのデータを、より長い期間、そして大幅に増強された計算リソースを用いて学習したという含意も含まれます。

この追加された容量は、いくつかの重要な利点へと繋がります。大規模モデルは、複数の制約を同時に追跡し、問題の前半部分の結果に基づいて判断を下す必要がある多段階推論において、より優れた性能を発揮します。そのため、曖昧さや情報の不足があるタスクに対しても、学習した広範なパターンを活用して欠落部分を補完できるため、非常に適した選択肢となります。

大規模オープンモデルの好例として、Kimi K3 が挙げられます。このモデルは総パラメータ数が 1.8T、アクティブなパラメータ数は 104B を誇ります。

複雑なタスクを処理する必要がある場合、Kimi K3 のような大規模モデルが適しています。具体的には以下のようなケースです：

• 既存の認証システムの書き換え
• コードベースを新しいフレームワークへアップグレードすること
• プルリクエストのレビュー
• SQL データベースが突然遅くなった原因の特定

大規模モデルの利点は、さまざまな種類の作業に対して高い堅牢性を発揮することです。コード作成、システム解説、デバッグ、変更計画など、タスクの種類を切り替えても、細かく限定された指示なしで柔軟に対応できます。そのため、次のアクションを自分で判断する必要があるエージェント型ワークフローにおいて特に有用です。

また、大規模モデルは長い会話履歴や多量の情報をより効果的に活用できます。一度に多数のファイル、ログ、情報を受け取っても、全体の一貫性を保ちながら関連する詳細をつなぎ合わせることができます。

「モデルが大きいほど常に優れている」と考えがちですが、実際には大規模モデルと小規模モデルの間にはトレードオフが存在します。次項では、大規模モデルよりも小規模モデルを選ぶべき理由について解説します。

小規模モデル

小規模モデルと大規模モデルの違いは、品質そのものではなく、どちらがより多くの曖昧さを自然に扱えるかにあります。

タスクが明確に定義され、範囲が限定されている場合、小規模なモデルでも大規模モデルと同等の性能を発揮できます。何を求めているかを具体的に明示することで曖昧さを排除すれば、これらのモデルは極めて効果的に機能します。

小規模モデルは、仕様が明確な作業において特に優れています。なぜなら、アーキテクチャを推測したり、隠れた要件を読み取ったり、複数の解釈の可能性を探ったりする必要がないからです。与えられた指示に従って実行するだけです。

小規模なオープンソースモデルの一例として、GLM 5.3 Flash が挙げられます。このモデルは総パラメータ数が 320B、アクティブパラメータ数が 18B です。Kimi K3 と比較すると、サイズは約 6 分の 1、コストは約 20 分の 1 です。

タスクが狭く明確に定義されている場合、これらのモデルは驚くほど高い性能を発揮します。具体的には以下のようなケースです。

• この関数に別のオプションを受け付けるように更新する
• このファイルのテストコードを書く
• 特定のエラーの内容を説明する
• バグがないか 50 行の関数をレビューする
• API の名前を変更し、呼び出し元を更新する

これらのタスクには曖昧さがほとんどありません。モデルはコードベース全体の詳細な理解を構築する必要もなければ、複数のアーキテクチャ手法の中から選択する必要もありません。

小規模モデルのもっとも重要な利点は、実行速度が圧倒的に速く、コストが大幅に低いことです。

トークン生成に必要な計算リソースが少なくて済むため、実用上はレスポンスの遅延が低く抑えられ、1 リクエストあたりのコストも大幅に削減できます。多くの日常的なコーディングタスクでは、モデルが即座に応答し、反復作業が高速化されるため、この速度差をすぐに実感できるでしょう。また、コストを気にせず何度も実行できる点も大きなメリットです。

「大きいモデルの方が小さいモデルより優れている」と考えるのではなく、これらは工具箱にある異なる種類のツールだと捉えるのが適切です。

モデルはツールとして扱う

大きなモデルの方が問題を確実に解決できる場合もありますが、その反面、処理速度が数倍遅くなったり、コストが高騰したりする可能性があります。小さなモデルで 1 ファイルの変更を正しく行えるなら、わざわざ大きなモデルを使う理由はありません。

時間をかけて、モデルの選択を「勝者を選ぶ」ことではなく、「適切な工具を選ぶ」ように意識的に変えていきましょう。

まずは大規模モデルと小規模モデルを数種類ずつ使いこなし、実際の使用を通じてそれぞれの能力と限界を理解してください。そうすれば、コードベースのどのタスクをどのサイズのモデルに任せるべきかという判断がすぐにできるようになります。

次は、最適なモデルを見つけるための場所について見ていきましょう。

モデルの選び方

新しいモデルは週ごとにリリースされており、すべてを手動で評価するのは現実的ではありません。

「The Open Frontier」や「Artificial Analysis」のようなリーダーボードは、利用可能なモデルの概要を把握し、知能レベル、コーディング能力、速度、価格といった観点でモデル同士を大まかに比較するのに役立ちます。

しかし、リーダーボード上で「唯一最高のモデル」を探そうと時間を費やしすぎないほうがよいでしょう。ベンチマークは多様な動作を一つのスコアに圧縮したものに過ぎず、実際の業務はもっと具体的なケースが多いからです。総合順位がわずかに下でも、あなたが日常的に行うコーディング作業においては非常に優れた性能を発揮するモデルもあるかもしれません。

参考までに、現在最も人気のあるオープンソースモデルには、GLM 5.3 Flash、DeepSeek V4 Flash、Kimi K3、そして MiniMax M3 が挙げられます。ただし、これらの状況は非常に速く変化するため注意が必要です。

いくつかのモデルを試す対象に選んだら、次はそのモデルをホストするプロバイダーを探す段階です。

推論プロバイダー

オープンソースモデルは単一のエコシステムに縛られないため、実行環境を自分で選択できます。最も手軽に始める方法は、クラウド推論プロバイダーやクラウドゲートウェイを利用することです。

これらのプロバイダーの仕組みはシンプルで、API リクエストを送信すると、彼らの GPU 上でモデルを実行してくれます。利用料金は、モデルに入力したトークン数と、モデルから出力されたトークン数に基づいて計算されます。

この仕組みにより、クラウドプロバイダーは実験に最適な環境を提供します。新しいモデルを試したい場合、API キーを作成し、モデル名を指定するだけでリクエストを送信できます。Together AI などのプロバイダーは豊富なカタログを保有しており、1 つのアカウントで多数の大規模・小規模モデルにアクセス可能です。

同じモデルを実行しているプロバイダー同士であれば、通常は類似した結果を生成します。特に同一のモデルバージョンとサンプリング設定を使用した場合、その傾向は顕著です。パフォーマンスや価格、レイテンシ、API 機能には差異が生じる可能性がありますが、基盤となるモデル自体は共通しています。

この分離構造により、ユーザーはまずモデルの挙動を好んで選択し、次に価格やパフォーマンスに基づいてプロバイダーやゲートウェイを選定できます。

ゲートウェイとルーター

すべての推論プロバイダーが均一にモデルをホストしているわけではありません。残念ながら、1 つのプロバイダーですべてのモデルを利用することはできません。そこで登場するのがゲートウェイとルーターです。これらは複数の推論プロバイダーにまたがる多様なモデルへのアクセスを提供し、特にクローズドソースモデルとオープンソースモデルの間で柔軟にルーティングしたい場合に威力を発揮します。

複数の推論プロバイダーの前方にゲートウェイを配置し、単一の API の背後でそれらを統合します。これにより、異なるバックエンド間でリクエストをルーティングしたり、価格やレイテンシを比較したり、コードを変更せずにモデルを切り替えたりすることが可能になります。このゲートウェイは、ユーザーと基盤となる推論プロバイダーの間に位置する翻訳およびルーティング層として機能します。

探索すべき人気のあるクラウドゲートウェイとして、https://openrouter.ai/ と https://vercel.com/ai-gateway が挙げられます。

また、https://www.litellm.ai/ などのツールを用いて、ローカル環境や独自サーバー上で独自のルーターを実行することも可能です。これらのルーターは、複数の推論プロバイダーに既に設定済みのアカウント間でルーティングできる単一の API エンドポイントを提供します。

推論プロバイダーまたはクラウドゲートウェイを選択したら、次はハネス（harness）のセットアップです。

ハネス

ハネスは、このスタックの中でユーザーが直接対話する部分です。通常、これはユーザー、コードベース、そしてモデルの間に入るコンピュータ上で動作するプログラムです。会話を維持し、モデルが現実世界と相互作用するために使用できるツールを提供します。

例えば、「このコードベース内で認証処理はどこで行われていますか？」と質問したとしましょう。

ハネスはその質問をモデルに送信します。

モデルは、その質問に答えるためにまず行うべきことは、auth、session、login といった用語でコードベースを検索することだと判断するかもしれません。そして、ハネスに対してそれらの検索を実行するよう依頼して応答します。

このハルネスは、お使いのコンピュータ上で検索コマンドを実行し、その結果をモデルに返します。

これらの結果に基づき、モデルはハルネスに対して複数のファイルからコードを読み取るよう指示を出します。ハルネスはそのファイルの内容を、モデルとの会話コンテキストに追加していきます。

このやり取りを数ラウンド繰り返すことで、モデルは認証に関する質問に答えるための十分な情報を得ます。具体的には、コードベース内で認証コードが含まれるすべてのファイルと行を特定して回答できます。

重要なのは、モデルが直接あなたのファイルシステムを検索したり、シェルスクリプトを実行したりしない点です。何を行うべきかを判断するのはモデルであり、ハルネスはそれを実行する役割を担っています。

つまり、コーディングエージェントの品質は、モデルそのものの性能だけでなく、ハルネスの質にも大きく依存します。

優れたハルネスとは、ツールの公開方法や関連コンテキストの収集、長文の会話管理、パッチの適用、変更内容の表示、適切なタイミングでのユーザー許可の要求、そしてコマンド実行失敗時の回復処理などを適切にこなせるものです。

同じモデルでも、使用するハルネスによって体感される性能は大きく異なることがあります。

ハルネスの選び方

モデルと同様に、選択できるハルネスのリストも絶えず増え続けています。

これらのハルネスにはさまざまな形態があり、ターミナルベースの CLI ツールや IDE 内で動作するエディタ拡張機能、より視覚的なインターフェースを提供する Web アプリやデスクトップアプリケーションなどが含まれます。

また、各製品が掲げる哲学にも大きな違いがあります。

あるハーンセスは数十もの機能、統合、バックグラウンドエージェント、プロジェクト管理ツールを備えている一方、別のハーンセスはあえて会話、シェル、ファイル編集といった最小限の機能しか提供しないこともあります。どちらのアプローチが本質的に優れているというわけではありません。

オープンモデルに対応する人気のあるハーンセスをいくつか紹介します。

• PI: https://pi.dev/
• OpenCode: https://opencode.ai/
• Amp: https://ampcode.com/

ほとんどのハーンセスでは、プロバイダーやモデルを簡単に切り替えられます。実際、これがオープンソースのハーンセスの売りの一つでもあります。モデルの切り替えは、単なるコマンドの実行か設定の変更で済むことがほとんどです。

Claude Code や Codex といったクローズドソースのハーンセスでも、TogetherLink のようなツールを使えば、現在の人気のあるオープンウェイトモデルと接続することが可能です。

ハーンセスを選んだら、次はワークフローに合わせてカスタマイズする段階です。

ツール（スキルと MCP）

ハーンセスは、スキルや MCP サーバーによって拡張することもできます。これらは、ハーンセスがモデルに共有できる指示やツールを提供する便利な追加機能です。

スキルとは、モデルが特定のタスクを実行したり、特定のツールと連携したりするための再利用可能な指示です。すべての情報を一つの大きなプロンプトに詰め込むのではなく、必要な時にハネス（実行環境）がスキルを読み込むことで、アプリのデプロイやコードレビュー、フレームワークとの連携などにおいて、モデルに専門的な知識を与えることができます。コミュニティが提供するスキルは、https://www.skills.sh/ ウェブサイトで確認できます。

MCP（Model Context Protocol）とは、AI エージェントを共通のインターフェースを通じて外部ツールやデータソースに接続するための標準規格です。このサーバーを利用すれば、各ツールごとにカスタム統合を行うことなく、データベース、API、ファイルシステム、開発者向けツールなどに対してハネスが直接アクセスできるようになります。既存の MCP サーバーは https://mcp.so/ ウェブサイトで探すことができます。また、プロバイダーによっては独自に MCP サーバーを提供している場合もあります。例えば、Together AI のサーバーについてはこちらをご覧ください。

次に、ハネス内でコンテキストを効果的に扱う方法について見ていきましょう。

コンテキストの管理

モデルを切り替え始めると、コンテキストの扱いが重要になります。

コンテキストとは、現在の会話においてモデルに共有されるすべての情報のことです。これには、ユーザーからのプロンプト、モデルによる過去の応答、ハネスが添付したファイル、シェル出力、検索結果、ツール呼び出し、そしてセッション中に蓄積されたその他の情報が含まれます。

モデルには処理できるコンテキストの上限があります。そのハードリミットに達する前でも、非常に長い会話になると有用性が低下します。

コーディングセッションは、狭く定義されたタスクから始まることが多く、最終的には 20 個ものファイルが蓄積され、数回の失敗したアプローチ、何ページにもわたるテスト出力、そしてもはや関連性のなくなった議論が含まれるようになります。

その結果、モデルは応答するたびにそれらすべてを推論する必要に迫られます。

モデルの出力を改善するための最も簡単な方法の一つは、現在のセッションを終了して新しい会話を開始するタイミングを知ることです。

新しいセッション

エージェントワークフローに対してできる最もシンプルな改善策の一つが、より頻繁に新しいスレッドを開始することです。

例えば、あるタスクを完了したら、次のタスクに取り掛かる前に必ず新しいセッションを開始してください。あるいは、一つの試行をした後に別の角度から問題を再考したい場合も、最初からやり直すのが良いでしょう。

モデルを変更する場合も、同様に新しく始めることをお勧めします。

その理由は、会話の内容自体が問題へのアプローチに影響を与えるからです。長いデバッグセッションに突然投入された新しいモデルは、前のセッションで蓄積されたすべての前提条件、実験結果、行き詰まりをそのまま引き継いでしまいます。

計画・実装・レビュー

試してみる価値のあるワークフローの一つとして、プロンプトを 3 つの異なるモデルに分割して使用する方法があります。各モデルには特定の役割を持たせます。最初のモデルが計画を担当し、2 つ目のモデルが実装を行い、3 つ目のモデルがレビューを行います。

大規模モデルは優れたプランナーです。オープンエンドなプロンプトを、明確で独立したタスクに分解する能力を持っています。

その後は小規模モデルを使用し、各タスクを一つずつ実装していきます。コンテキストを小さく保ち、焦点を絞るために、各タスクごとに新しいセッションを作成しましょう。もし小さなモデルにとってタスクが複雑すぎる場合、大規模モデルに切り替えて完了させます。

最後に、タスクが完了したら大規模モデルで全ての作業を検証します。検証中に問題が発生すれば、このプロセス全体を繰り返すことができます。レビューからのフィードバックに基づいて新しいプランニングセッションを開始し、プロセスをループさせるのです。

このアプローチの利点の一つは、正式なシステムとして構築する必要がないことです。異なるモデルを使いこなせるようになれば、コードベースでの作業中に、プランニング、実装、検証の間を素早く行き来できるようになります。

実験のために設計する

スタックの各層を理解していれば、ワークフロー全体を変更することなく、さまざまなモデルやプロバイダー、ハーン（harness）を簡単に試すことができます。多くの場合、モデルの差し替えは設定値を変えるだけで済みます。プロバイダーの変更も、同じハーンを別の API エンドポイントに指し直すだけです。ルーターやゲートウェイの導入といった構造的な変更でさえ、日々の作業方法に触れることなく追加可能です。

この分離により、新しいモデルの導入に伴う通常の問題を解消できます。単一のシステムに縛られるのではなく、モデルを安定したワークフロー内の交換可能なコンポーネントとして扱えるようになります。ハーン（基盤）は一定のまま、ツールやショートカットも変わらず、変化するのは背後にある知能層だけです。これにより、実際のタスクでモデルを試すことが容易になり、コストとレイテンシを実践的に比較できます。また、どのような問題にどのモデルが最も適しているかという直感を徐々に養うことができます。

モデルのアップグレードやプロバイダーの切り替え、ルーティング層の追加などを通じてスタックを継続的に改善でき、日々の開発作業で勢いを失うことはありません。

オープンなスタック

オープンモデルの最も魅力的な点は、単に選択肢が増えることだけではありません。重要なのは、スタック全体がコンポーザブル（組み立て可能）になることです。

タスクに応じてモデルを選択し、価格とパフォーマンスに基づいてプロバイダーやゲートウェイを選び、作業スタイルに合わせてハーンを選定できます。さらに、ワークフローに必要なスキルやツールを自由に追加してハーンを拡張することも可能です。

例えば、コーディングスタックは以下の構成にできます：基盤として OpenCode を使い、Together AI で GLM 5.3 Flash を実行し、優れた UI の構築には grill-me と hallmark のスキルを活用し、ブラウザ自動化には Playwright MCP を採用します。

これらのコンポーネントはすべて同じ企業から調達する必要はありません。もし来週より優れたモデルが登場しても、他の部分を一切変更せずにそのモデルと差し替えるだけで済みます。

オープンウェイトモデルを使えば、モデルを別の場所へ持ち運ぶことも可能で、場合によっては自分自身で実行することもできます（ollama などのツールを使えば、自分のノートパソコン上でも動作します）。

これがオープンモデルが持つ大きな可能性です。

AI コーディング製品を選ぶのではなく、自分だけの AI コーディングスタックを構築できるのです。