FortytwoのCEO兼共同創業者、Ivan Nikitin ― インタビューシリーズ

Ivan NikitinはFortytwoのCEO兼共同創業者で、複数のAIモデルを連携させ、互いの推論や成果を評価し合うスウォーム推論技術を開発しています。ゲーム、対話型AI、生成AIのほか、TemporalとSensoriumでのインタラクティブシステム開発にも携わってきました。2011年にはVlad LarinとTemporalを共同創業しました。現在、LarinはFortytwoの共同創業者兼CTOを務めており、Nikitinはそこで、変化し続けるエージェント集団や、専門特化型モデルを組み合わせるシステムの開発経験を積みました。

Fortytwoは、推論時にモデル同士が協働できるAIインフラを構築しています。同社のFortytwo EngineはSwarm Decoderを用いて、進行中の推論プロセスを複数のモデルで共同制御し、長時間に及ぶタスクで精度を高め、不要なトークン生成を抑えることを目指しています。同社は、Fortytwo Engineを通じて開発者向けAPIを提供するほか、Fortytwo Harborを通じてオンプレミス導入にも対応しています。

Fortytwoを共同創業する前、SensoriumとTemporalで、対話型AI、生成AI、インタラクティブシステムを活用した製品の開発に長年取り組んでいました。こうした経験は、個々の大規模言語モデルの限界についての見方をどのように形作り、最終的にFortytwoを支えるスウォーム型のアプローチへとつながったのでしょうか？

私を含め、チームの多くはゲームを通じてAIの世界に入りました。ゲームはパーソナルコンピューティングと現代AIの揺籃の地です。GPUが生まれたのもゲームがあったからであり、ゲームプレイは強化学習における最初の本格的な実験場でした。ゲームの世界は、学習し、適応し、競い合うエージェントを構築するための実践的な環境を与えてくれました。2011年にVlad Larinと共同創業したTemporalでは、選択圧のもとで競い合うエージェント集団を通じて、進化する知能の研究を始めました。優れた貢献を見極め、それを生かす仕組みさえあれば、集団は個々のエージェントを超える成果を上げられるのではないかと考えていたのです。選択と評価は、私たちが知能を考えるうえで中心的なテーマになりました。現在、LarinはFortytwoの共同創業者兼CTOを務めています。

Transformerモデルが登場すると、私たちは対話型AIにも取り組みを広げ、記憶と個性を備えたAIキャラクターが、台本に縛られない自由な会話を続けられるプラットフォームを構築しました。これはChatGPTの登場より数年前のことで、当時扱っていたモデルのコンテキストウィンドウはわずか512～1,024トークンでした。初期の言語モデル1つに、そうした体験に求められる多様な要件をすべて確実に満たさせるのは、到底無理でした。そこで、それぞれの役割を絞った専門特化型モデルを組み合わせ、その成果を統合する仕組みを備えた独自のパイプラインを構築する必要がありました。体験全体を成立させるには、応答の順位付けと選択が不可欠でした。この経験から、能力に限りのあるモデルでも、適切に設計されたシステムに組み合わせれば、どれほど多くの能力を引き出せるかを学びました。

もう一つの教訓は、効率性です。明確に定義されたタスクであれば、専門特化型モデルをより効率的に学習・運用でき、限られた計算資源でより多くの成果を得られると分かりました。しかし、推論を大規模化するには依然として課題があり、一方にはAPIの利用上限、もう一方には大規模な自社運用のコストがありました。最先端の計算能力を利用できないなか、手元のリソースをどうすれば最大限に生かせるかを慎重に考える必要がありました。Fortytwoは、こうした教訓をスウォーム推論という構想に結実させました。複数のモデル、あるいは同一モデルの複数のインスタンスが推論に参加しながら、互いの成果を評価する仕組みです。その結果、集団全体の精度は、どの構成員単体よりも高くなります。

Fortytwo Engineは複数のオープンウェイトモデルを使い、単一の推論プロセスを導きながら、応答の生成中に互いの成果を確認します。このアプローチは、従来のマルチエージェントシステムやモデルアンサンブル、あるいは複数のモデルを実行してから最良の回答を選ぶ方法と、どのように異なるのでしょうか？

大きな違いは、スウォーム推論が私たちの開発した推論エンジンに直接組み込まれている点です。私たちはこれをSwarm Decoderと呼んでいます。複数のモデル参加者が、生成中の単一の推論経路を継続的に形作ります。評価と方向づけはそのプロセスの内部で行われるため、応答が完成する前にモデルが進行方向に影響を与えられます。

他の方式は仕組みが異なります。回答単位のアンサンブルでは、モデルがそれぞれ別の応答を生成し、その後で順位付け、選択、または統合を行います。2025年に実装されたFortytwoの初期アーキテクチャでは、完成した回答を相互に順位付けしていました。これにより回答精度は大幅に向上しましたが、遅延と計算オーバーヘッドが増加しました。従来型のマルチエージェントシステムの多くは、オーケストレーターと自然言語のメッセージを用いて各エージェントの役割を管理しながら、作業を分担します。こうした受け渡しには、推論の追加呼び出しやコンテキストの反復が必要になることがあり、どの情報を別のエージェントに渡すかも決めなければなりません。Swarm Decoderには受け渡しがありません。参加モデルは一つの推論経路に取り組み、やり取りするのはどちらの方向が望ましいかという評価だけです。

Swarm Decoderは、弱い前提が後の推論の土台になる前に、生成中にそれを検出できるよう設計されています。目指しているのは、誤りや後戻り、不要な生成を減らすことです。確認によって、それに伴う追加作業を上回る作業を防げたときに、効率面でのメリットが生まれます。遅延が増えないのもそのためです。実行がより直接的な経路をたどるため、Engineは同じモデルを単独で使う場合よりも少ない時間でタスクを完了し、参加するすべてのモデルを含めた総トークン数も少なくなります。

長時間にわたるタスクでのモデルのドリフトが大きな問題だと指摘されています。そもそもドリフトは何が原因で起きるのでしょうか。また、ソフトウェアエンジニアリングや研究、自律型AIエージェントなどの実用場面では、どのような形で現れますか？

ドリフトとは、モデルのコンテキストが徐々にタスクから外れていくことです。長時間の実行では、コンテキストがモデル自身の出力、ツールの実行結果、ファイルの内容、再試行の結果などで埋まっていきます。モデルが注目する情報の中で、当初の指示が占める割合は次第に小さくなり、以前の誤りも推論の材料に含まれるため、誤りは打ち消されるのではなく積み重なっていきます。さらに、現在の推論モデルはタスクを完了するよう強化学習で訓練されており、完了したように見える近道を学習します。たとえば、ツールの呼び出しを省く、成功したと宣言する、確認する代わりに要約するといったことです。私たちはこれを「怠慢」と呼んでいます。オープンウェイトモデルだけでなく、最先端モデルでも同じように起こります。根本的な原因は、単一のモデルには外部からのチェック機能がないことです。モデルは自分の作業を自分で評価しますが、正確な自己評価は苦手です。

ソフトウェアエンジニアリングでは、最初のメッセージで伝えた制約を破りながら、説明したバグを修正するエージェントとして現れます。簡単に通るだけのテストを書いたり、すでに把握した内容を見失って同じファイルを4回読んだりすることもあります。研究では、長時間の実行のうちに、尋ねた質問から、答えやすい質問へと焦点がずれていき、ありきたりな要約を返す形で現れます。自律型エージェントでは、さらにコストのかかる問題になります。脱線やツールの繰り返し呼び出し、後戻りが生じ、トークンコストはタスクに必要な量の数倍に膨らみます。

この問題は数値で示せます。Qwen 3.8 27Bを、長いコンテキストとツール利用を伴う実際のソフトウェアエンジニアリング作業であるDeepSWEの450タスクで実行し、単独で使った場合とFortytwo Engineを通した場合を比較しました。単独の場合、モデルの平均トークン数は1回の実行あたり1,630万、合計74億でした。Engineを通した場合、同じモデルの平均トークン数は1回の実行あたり1,230万、合計56億で、24.7%減少しました。それだけでなく、タスクの正解率も上がり、42.2%に対して47.8%となりました。モデル自体には何も変更を加えていません。1回の実行あたり400万トークンが減ったのは、ドリフトによるものでした。具体的には、読み直しや再試行、後戻りです。単一のモデルでは、誤った方向に進んでいる最中にそれを誰も指摘しないため、こうした無駄が生じます。スウォームが誤りを検出するので、その分のコストを払わずに済むのです。

Fortytwoでは以前、モデル同士が互いの完成済みの回答を評価していましたが、現在のアーキテクチャでは、推論の生成中にモデル同士がそのプロセスに影響を与えられます。以前の方式から何を学び、リアルタイムで軌道修正するほうが効果的なのはなぜでしょうか？

2025年のアーキテクチャによって、最大規模のモデルを追い求めるのではなく、参加するモデルを増やす水平スケーリングで、最先端モデル級の能力を実現できることが証明されました。オープンウェイトモデルのスウォームが互いの完成済みの回答を順位付けする方式では、スウォーム内で最も優れた単独モデルを最大17パーセントポイント上回りました。また、単一モデルにはない頑健性も示しました。ノイズの多いプロンプト、注入された指示、誤答が多数を占める状況にも対応できたのです。

このアーキテクチャにできなかったのは、途中で介入することです。完成した回答を順位付けする方式は、1つの質問には有効ですが、エージェントの実行は途中でツールを呼び出しながら何百ものステップを進みます。そして、決定的な誤りは早い段階で起き、積み重なっていきます。最後に評価するのでは、すべてのモデルがすでにトークンコストを全額支払った後であり、評価役が選べるのは、すでに分岐してしまった実行経路だけです。また、この方式ではスウォームのコストがモデルの数に応じて増えていました。難しい質問が1つだけなら問題ありませんが、コーディングエージェントには適しません。

リアルタイムの軌道修正なら、その両方を解決できます。実行中に継続して順位付けを行うことで、選択圧をかけ、誤った方向への進行を、それが広がる前に発生した場所で修正できます。より怠惰な試みは、より慎重な試みに順位で負けるため、スウォームは怠慢な試みで妥協しません。このため、同じ仕組みで精度を高めると同時に、トークン数も減らせるようになりました。

Qwen 3.8 27Bを使ったテストでは、FortytwoはDeepSWEの450回の実行でトークン数を24.7%削減し、6つのベンチマークすべてで結果を改善したと報告しています。スウォーム内では、性能を高めながらトークン消費も減らすために、どのようなことが起きているのでしょうか？

スウォームによるチェックには、小さく一定のコストがかかります。一方、それによって防げる手戻りのコストはタスクが長くなるほど増えていきます。修正されない誤った方向への進行は、その上に積み上げられた作業すべてを無駄にするからです。そのため、タスクが長いほど削減できる量も増えます。DeepSWEはこの幅の中でも長時間のタスクに当たるため、トークン全体のおよそ4分の1近くを削減できています。

精度の向上は、モデルの能力にばらつきがあることに関係しています。モデルの性能向上は、一般に分野によって一様ではありません。ある領域では博士号取得者並みの推論ができる一方、別の領域ではまったく筋の通らない答えを出すことがあります。これは、ファインチューニングやRLなどの追加学習が、モデルの訓練に使われたデータに対する性能を高める一方、実際のタスクがそのデータから離れるほど、向上幅が小さくなるためです。Swarm Decoderはモデル自体には手を加えません。推論そのものを一貫して改善するため、6つのベンチマークは、私たちが最適化した6つの分野ではありません。同じことを測定した6つの場なのです。全体としてモデルはより賢く、注意深くなり、あらゆるステップを仲間のモデルが確認することで、タスクにより多くの力を注いでいるように感じられます。だからこそ、Engineの価格をベースモデルと同じトークン単価に設定できます。顧客が支払うのは、より大きな予算ではなく、正しい答えに至るまでの道のりを短縮することに対する料金です。

推論モデルがより長いトークン列を生成するようになるなか、AI開発者の間では推論コストへの懸念が高まっています。推論プロセスそのものの効率を高めることは、最終的に個々のモデルを小型化、高速化、低コスト化するのと同じくらい重要になると思いますか？

はい。すでに、こちらのほうが大きな効果をもたらす要因だと考えています。モデルの小型化、高速化、低コスト化によって、トークン単価は下がります。しかし、トークンそのものを買う人はいません。買うのはタスクの完了です。そしてエージェントの時代には、タスクあたりのトークン数が急増しています。実際のコーディングタスクに取り組む推論モデルは数百万トークンを費やし、そのかなりの部分は同じ手順を何度もやり直すことに使われています。タスクあたりのトークン数を25%削減することは、価格を25%引き下げるのとまったく同じ価値があります。しかも、その効果はハードウェア、量子化、カーネルのあらゆる改善に上乗せされ、市場にあるあらゆるオープンウェイトモデルに適用できます。

この業界には、3つの改善の方向性があります。1つ目は、トレーニングによるモデルの高性能化で、コストがかかります。2つ目は、ハードウェアとサービングの改善によるトークンの低コスト化です。誰もが同じGPUを使っているため、この面では各社の差が縮まりつつあります。3つ目は、推論の実行方法を工夫してタスクあたりのトークン数を減らすことですが、これはほとんど未開拓です。これまでのスケーリングは、より大きなモデルと、より長い思考の連鎖を意味していました。どちらも、1つのモデルに1つの推論過程のなかですべてを行わせるものです。私たちは、次の方向性は複数モデルによる協調だと考えています。複数のモデルが一緒に推論し、判断を分担することで、推論過程そのものを短く、より信頼性の高いものにできます。これは、パラメーター数や推論時の計算量を増やすのとは異なるスケーリングのあり方であり、私たちが賭けている方向性です。私たちはこれを「パラメーターよりもピア」と捉えています。

Fortytwo Engineはオープンウェイトモデルを実行しながら、OpenAI APIとの互換性を備えています。既存のAI開発スタックとの互換性はどれほど重要だったのでしょうか。また、開発者は従来型の単一モデルAPIからスウォーム型アーキテクチャへ、どれほど容易にアプリケーションを移行できるのでしょうか。

互換性は不可欠です。エージェントのエコシステムを構成するコーディングエージェント、ハーネス、フレームワーク、評価ツールは、OpenAI APIの仕様を前提に構築されています。そのため、Fortytwo Engineを利用する開発者にとって、移行は推論プロバイダーを切り替えるのと同じです。互換性のあるアプリ、エージェント、ハーネス、サービスであれば、通常、エンドポイント、APIキー、モデルの選択を変更するだけで済みます。

変わるのは挙動であり、連携方法ではありません。その違いが表れるのは、長時間にわたるエージェント実行です。トークン消費量と初回の正答率がコストを左右します。同じモデルでも、Engine経由で実行すれば、より速く、より少ないトークンで完了し、より多くのタスクを正しく処理できます。私からのアドバイスは、ほかのモデルに切り替えるときと同じように扱うことです。エージェントで現在使っている評価を実行し、タスクあたりのトークン数と成功率を比較して、より良い結果が出たほうを使いましょう。

素晴らしいインタビューをありがとうございました。スウォーム推論や、ピア評価によって推論効率を高める方法について詳しく知りたい方は、Fortytwoをご覧ください。