ほとんどのオーケストレーション（制御）フレームワークは、数秒または数分間動作するエージェントを前提に構築されてきました。ところが今やエージェントは数時間、場合によっては数日間動作するようになっており、こうしたフレームワークがほころび始めています。
AnthropicのClaude CodeやOpenAIのCodexのように、複数セッションのタスク、サブエージェント、バックグラウンド実行によって長期ホライゾンのエージェントを早期から支える仕組みを導入したモデル提供企業もあります。しかし、これらのシステムは、たとえ長時間動作するとしても、エージェントが依然として制限時間付きのワークフローの範囲で稼働している前提を置いてしまうことがあります。
オープンソースのモデル提供企業Moonshot AIは、新しいモデルKimi K2.6によって、その先へ踏み出そうとしています。
Moonshotによれば、このモデルは連続実行向けに設計されており、内部のユースケースとしては、数時間実行されたエージェントや、あるケースでは5日間連続で稼働したものが含まれます。これらは、モニタリングとインシデント対応を自律的に処理しました。
しかし、この種のエージェント利用が広がるにつれて、オーケストレーションにおける重要なギャップが浮き彫りになっています。すなわち、多くのオーケストレーションフレームワークは、この種の連続的でステートフルな実行を想定して作られていないのです。Kimi K2.6のような、エージェントの群（スウォーム）に依存するオープンソースモデルは、ステートフルなエージェントを運用する点で、自社のオーケストレーション手法がかなり近いところまで到達していると主張しています。
長時間稼働するエージェントをオーケストレーションする難しさ
一部の企業が、自社のエージェストレーションフレームワークをエージェントのエコシステムに持ち込みたいと思うのは確かですが、モデル提供企業やエージェントのプラットフォームは、エージェント管理を提供することが競争上の優位性になり得ると認識しています。
ほかのモデル提供企業も、長時間稼働するエージェントの検討を始めており、その多くは複数セッションのタスクやバックグラウンド実行を通じて行われています。例えば、AnthropicのClaude Codeは、ユーザーが指示した定義のセットに基づいて他のエージェントを導くリードエージェントにより、エージェントをオーケストレーションします。OpenAIのCodexも同様に動作します。
Kimi K2.6は、改良版のAgent Swarmsによってオーケストレーションに取り組んでいます。最大300のサブエージェントを「4,000の協調されたステップを同時に実行する」ことが可能だと、Moonshot AIはブログ記事で述べています。Claude CodeやCodexの両方と比べて、K2.6は、事前に定義された役割ではなく、モデルによりオーケストレーションを判断させています。
Kimi K2.6は現在、Hugging Face上で、APIのKimi CodeおよびKimiアプリ経由で利用可能です。
長期ホライゾンのエージェントを試している実務者によれば、もろさ（脆さ）はプロンプトで直せる範囲よりもずっと深いとのことです。
実務者のMaxim Saplinはブログ記事でこう書いています。「それはサブエージェントが無用だという意味ではありません。意味するのは、オーケストレーションがまだ脆いということです。今の感覚では、“十分に厳しいプロンプトを書けば解決できる”というよりは、“製品と学習（トレーニング）の問題”に近いように感じます。」
長時間稼働するエージェントが引き起こす問題は、特に作業中に環境が変わり続けるため、ステート（状態）を維持するのが難しいことです。エージェントは実行中、さまざまなツールやAPIを絶えず呼び出したり、異なるデータベースにアクセスしたりします。現在の多くのエージェントは、1回か2回の実行で動作する可能性があるものの、異なるツールを呼び出すとしても、せいぜい1分程度です。
企業向けの自律型セキュリティ・プラットフォームを構築するArmorCodeのプロダクト担当最高責任者（CPO）Mark Lambertは、電子メールでVentureBeatに対し、ガバナンスのギャップはすでに導入（デプロイ）を上回って広がっていると語りました。
「これらのエージェント型システムは、現在、多くの組織がレビュー、是正、または統治（ガバナンス）できるよりも速くコードやシステム変更を生成できてしまいます。追加のスキャンだけでは不十分です。組織は、Kimiやその他のAIが生成したリスクが、蓄積されたエクスポージャー（潜在的な損失リスクの積み上げ）になる前に管理するために、チームが必要とするコンテキスト、優先順位、説明責任を提供する、より強固なAIガバナンスが必要です」とLambertは述べています。
長時間稼働するエージェントは、明確なロールバック（巻き戻し）がない場合に失敗のリスクもあります。とりわけ重要なのは、こうしたタイプのエージェントは、多くの場合、よく定義されたタスクのセットを欠いており、実行しながら計画を動的に調整する点です。
F5のプロダクト担当最高責任者（CPO）であるKunal Anandは、電子メールでVentureBeatに対し、長期ホライゾンのエージェントは、多くの企業が準備できていた以上に大きなアーキテクチャ上の転換を意味すると語りました。
「私たちは、スクリプトからサービスへ、コンテナへ、関数へ、そしていまや“永続的なインフラ”としてのエージェントへ移りました。すると、まだ適切な名前が付いていないカテゴリーが生まれます。つまり、エージェント実行（agent runtime）、エージェント・ゲートウェイ（agent gateway）、エージェント・アイデンティティ・プロバイダ（agent identity provider）、エージェント・メッシュ（agent mesh）です。APIゲートウェイのパターンは、エンドポイントや動詞だけを理解すればよいものから、“目標とワークフローを理解しなければならないもの”へと形を変えつつあります」とAnandは述べました。
13時間稼働し、さらには5日間も
モデルの能力が向上してきたため、企業が長期ホライゾンのエージェントに目を向け始めている一方で、オーケストレーションの革新はそれに追いついていない状況です。このため、エージェントをどうオーケストレーションするかを理解することが重要になっています。
Moonshot AIは、このモデルは「通常は、数週間または数か月に及ぶ、集団的な人間の努力を必要とする」現実世界の課題を反映したタスクのために作られていると述べています。VentureBeatに別途提供された技術文書の中でMoonshotは、K2.6が10時間でスクラッチからフルのSysYコンパイラを構築したと主張しています。これは、2か月間にわたって4人のエンジニアのチームが行う作業に相当すると同社は位置付けており、人間の介入なしに、140の機能テストをすべて通過したとのことです。
チームは、8年目のオープンソースの金融マッチング・エンジンを刷新することを含む、複雑なエンジニアリング作業にK2.6を投入しました。Moonshotのエンジニアは、「13時間の実行で、12の最適化戦略を反復し、コード4,000行以上を正確に変更するために、1,000回を超えるツール呼び出しを開始した」という内容を説明しました。
Moonshotは、同社のあるチームがK2.6を使って、5日間にわたり自律的に稼働するエージェントを構築したと述べています。そのエージェントは、モニタリング、インシデント対応、システム運用を管理しました。
