Cosine AI と主権的フロンティア AI の必要性

主権 AI の使命

米国のフロンティア AI モデルに対する輸出規制、特に「Fable」と呼ばれるシステムの禁止は、英国が独自の主権的な大規模言語モデル（LLM）を開発する戦略的必然性を生み出しました。Cosine の CEO 兼共同創業者である Alistair Pullen は、外部委託された AI に依存すると、国家の最も有能なツールが外交政策によって撤回され得る脆弱性が生まれると説明しています。

この課題に対処するため、Cosine は英国政府の主権 AI 部門から支援を受け、ブリストルにある Isambard スーパコンピュータクラスターへの重要な計算リソース割り当てを受けました。この政府支援の計算資源は、スタートアップにとって最大の財政的障壁である膨大なトレーニングハードウェアコストを取り除き、米国ラボで見られる数十億ドル規模の予算を必要とせずにフロンティア規模のモデルを追求できるようにします。

数十億ではなく数百万でスケールする

予算を抑えてフロンティアモデルを構築するには、ビジネスモデルを「推論会社」から「技術ライセンサー」へシフトすることが鍵です。

推論オーバーヘッドの回避

米国のフロンティアラボの多くは、独自の API をホストしトークンマージンを管理するためにデータセンターに数十億ドルを投じています。Cosine は、モデルを金融サービスや防衛などの高度にセキュアでエアギャップされた、またはハイサイド環境に直接デプロイすることでこれを回避します。顧客は自社の GPU 上でモデルウェイトを実行するか、ハイパースケーラーのクラウドインスタンスをレンタルします。トークンを販売するのではなく技術をライセンスすることで、スケールした推論のホスティングに伴う巨額の運用費用を排除します。

コンソーシアム・フィードバック・ループ

Cosine は、実際のユースケースと要件を直接トレーニングプロセスに流し込む英国大手企業のコンソーシアムを活用しています。これにより、モデルは全世界向けの汎用ツールになるのではなく、特定の国家的・産業的ニーズに最適化されたターゲットフィードバックループを形成します。

フロンティア性能のためのアーキテクチャ要件

クローズドソースモデル（Claude の Sonnet/Opus など）の性能上限に到達するため、Pullen は以下の 3 つの重要なアーキテクチャ要因を挙げています。

1. 総パラメータ数：サイズそのものが能力のベースラインです。
2. アクティブパラメータ数：Mixture-of-Experts（MoE）モデルでは、フォワードパス時に実際に活性化されるパラメータ数がモデルの「感触」や推論深度を決定します。Pullen は、総サイズは同程度でも、アクティブパラメータ数が少ない MoE（例：gpt-oss-120b）よりも、密結合モデル（例：Devstral 2）の方が優れた感触を持つことが多いと指摘しています。
3. データ品質と軌跡：プレトレーニングコーパスはモデルが 30 兆トークンに達すると収束しますが、真の「α」は大規模なポストトレーニングデータと強化学習（RL）にあります。

「スロップ」解消とエージェント信頼性の向上

AI コーディングにおける「スロップ」とは、ユニットテストは通過するものの、アーキテクチャ的に劣悪なコード（いわゆる「スパゲッティコード」）を指します。これは技術的負債を増大させます。

結果よりプロセスを報酬化

従来の RL はユニットテストが合格すれば 1/0 の二値報酬を与えます。これにより、結果が正しくても非効率的・安全でない経路が強化されてしまいます。Cosine は軌跡内で「クレジット帰属」を実装し、成功に至った具体的なトークンや意思決定点を特定します。結果（テスト合格）だけでなく、プロセス（エレガントな経路）に報酬を与えることで、モデルは表面的な統計相関ではなく、再利用可能な抽象化を学習します。

ランタイム証明をコードレビューに

AI 生成コードのレビューに伴う認知負荷を軽減するため、Cosine は「エクスプロイト検証」またはランタイム証明を提唱します。人間が git diff を読む代わりに、システムは仮想マシン上でアプリケーションを起動し、エージェントに機能が実際に動作する（またはバグが修正された）ことをライブ環境で証明させます。これによりコードレビューは手作業の読解タスクから機能的証明の検証へと変換されます。

高度なエージェントオーケストレーション：Swarm

シンプルなエージェント活用はモデルが bash を使いこなすようになるにつれ重要性が低下しますが、複雑な問題分解には依然としてオーケストレーションが必要です。Cosine の「Swarm」システムはサブエージェントのオーケストレーションを極限まで拡張します。

• 階層構造：トップレベルのオーケストレーターが問題を「サブプランナー」向けのサブ問題に分割し、サブプランナーは平坦な「ワーカー」層を管理します。
• 大規模並列性：ある例では、Cosine は 253 のサブエージェントを単一のショットで使用し、物理エンジンと 3D ビューアを含む機械式時計 SDK を構築しました。これは単一パス LLM では到底実現できないタスクです。
• コンフリクト管理：エージェント同士がファイルを書き換えるのを防ぐため、システムはファイルに対して書き込みロックを設定し、別エージェントが編集した際にはコンテキスト更新を提供します。

記憶と合成データの課題

記憶ハック

Pullen は、現在の AI 記憶（VectorDB、RAG）はエージェントが「いつ記憶を照会すべきか」「いつ書き込むべきか」判断できない点で「ハック」だと指摘します。目指すべきは、継続学習を通じて記憶をモデルの潜在空間に統合することですが、報酬ハックや RL 中のデータ漏洩といった技術的課題が依然として残ります。

RL 用合成グレーダー

バグ修正のように組み込みテストが存在しないタスクに対して RL を実行するため、Cosine は「グラウンドトゥルース」またはグレーダーを合成するパイプラインを使用します。実際の機能開発を取り込み、実装に依存しない機能的正当性の検証方法を合成することで、SystemVerilog のようにテストスイートが不十分な言語やスタック向けに RL データを生成できます。