Continuum：OpenAI 互換 Agent Runtime を選ぶときに見るべき能力

あなたの agent はまだ notebook の中で動いていますか？ それは多くの場合、本番向け runtime が足りていないサインです。framework はたくさんあります。LangGraph、CrewAI、AutoGen、DeepAgents。名前は聞いたことがあっても、実際の選定ではどの観点を見るべきでしょうか。

Continuum は ShyftLabs が出している企業向け agent runtime です。位置づけは明確で、「出荷する人」のためのもの。prototype tool でも notebook のおもちゃでもなく、multi-agent collaboration、cost control、durable execution、observability といった本番に必要な能力を、type-safe API の背後にまとめる Python framework です。

どの agent runtime を評価するときも、軸は 7 つです。オーケストレーションパターン、モデルルーティング、メモリシステム、ツール標準、永続化実行、可観測性、デプロイガバナンス。Continuum はあくまで例ですが、完全な選定 framework こそが判断材料になります。

位置づけ：Continuum とは何か、なぜ例にするのか

Agent runtime の役割は、「きれいな agent core + multi-model reasoning + stateful memory + tool calling + durable execution + observability」を、組み合わせ可能な production system としてまとめることです。

Continuum では、この 6 つの能力がそれぞれ runtime の構成要素として現れます。

• typed agent core（BaseAgent、AgentRunner）
• multi-model inference（公式は 250+ models / 45+ providers 対応と説明）
• 短期/長期 memory（Redis session history + mem0 vector memory）
• MCP tool の native support
• Temporal durable workflow
• Langfuse tracing による observability

選定時に、Continuum が唯一の答えというわけではありません。ただし、本番向け runtime が持つべき能力 stack を示す、まとまった例にはなります。

選定 framework：Agent Runtime を評価する 7 つの核心能力

オーケストレーションと multi-agent パターン

オーケストレーション能力は runtime の中心的な判断点です。multi-agent collaboration を支えられるか。どの pattern を支えるか。

Continuum は 9 種類の multi-agent pattern を提供します。

選定時の問い：あなたの scenario にはどの pattern が必要ですか？ runtime はそれを支えますか？

agent が single-thread の順次実行だけでよいなら、sequential pattern で足ります。しかし並列 task、agent 間の協議、重要 node の human approval が必要なら、parallel、debate、supervised のような pattern を支えるかを見る必要があります。LangGraph のオーケストレーション実践は LangGraph の state 管理実践 も参考になります。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

モデル接続とコストルーティング

最初の問いは model independence です。OpenAI、Claude、Llama、local model など複数 model を扱えるか。OpenAI 互換か。

Continuum の設計では、agent は 1 つの OpenAI 互換 endpoint を呼びます。その背後で Smart Inference が、公式説明では 250+ models の間を複雑さと cost に応じて routing します。この設計には重要な概念があります。

• single endpoint：agent は具体的な model を意識せず、SMART_GATEWAY_URL だけを呼ぶ
• classifier routing：Smart Inference が task complexity と cost budget に応じて model を選ぶ
• budget ledger：dynamic output limit により token explosion を防ぐ
• quality tier：agent ごとに strict / modest / quality などの quality tier を切り替えられる

選定時の問い：runtime は cost-aware routing を持っていますか？ agent ごとに quality tier を分けられますか？

cost control は「節約できるか」だけの話ではありません。「請求が暴走しないか」の問題です。multi-model call、long-running task、繰り返し reflection する agent は、budget cap と cost routing がないと想定以上に token を消費します。

メモリシステム：短期 session + 長期 vector memory

memory は agent の context 基盤です。短期 session history は現在の conversation 用で、長期 vector memory は session をまたぐ retrieval に使います。

Continuum の実装は次のとおりです。

• 短期：Redis session history（session module）
• 長期：mem0 + Qdrant/Milvus vector memory（memory module）

選定時の問い：短期と長期を分けていますか？ vector database integration は柔軟ですか？

agent が現在の conversation history だけを必要とするなら、Redis や in-memory state で十分です。しかし user preference、過去の decision、project document を session 間で retrieve したいなら、runtime が vector memory integration を持つか、Qdrant、Milvus、Chroma などの vector DB を差し替えられるかを見る必要があります。memory system の設計は Agent memory system design も参考になります。

ツール標準：MCP native support

tool calling は agent の手足です。では、どの protocol を使うべきでしょうか。

MCP（Model Context Protocol）は、AI agent の tool integration における重要な standard になっています。MCP は JSON-RPC transport を使い、Tools / Resources / Prompts という 3 つの primitive を提供します。

Continuum の実装は、MCP server native support と、統一された ToolExecutor interface です。

選定時の問い：runtime は MCP native ですか？ それとも custom API ですか？

MCP native であれば、filesystem、database、API tool など既存の MCP server を直接使いやすくなります。独自の tool protocol adapter を書く必要が減ります。runtime が custom API を使うなら、別の tool interface standard を保守することになり、ecosystem 拡張の cost が上がります。MCP Server 開発の入口は MCP Server 開発入門 も参考になります。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

永続化実行と human review

long-running task には永続化が必要です。checkpoint からの復旧、人間の承認（approval gate）です。

Continuum は Temporal durable workflow を使い、次を支えます。

• checkpoint recovery：task が中断したあと、中断点から続行
• approval gate：重要 node では人間の承認を待ってから続行

選定時の問い：runtime は durable execution を持っていますか？ human review で中断し、再開できますか？

agent task が数時間動く可能性がある、または送金、公開、承認のような重要 decision を扱うなら、durable execution と human review は本番必須です。そうでなければ、network の揺れや timeout で task 全体が失われたり、agent が止まるべき場所で走り続けたりします。

可観測性：tracing、metrics、error reporting

agent の execution chain は長いため、observability は本番必須です。

Continuum は Langfuse tracing を統合し、次を提供します。

• execution trace（各 agent、各 model call、各 tool call）
• metrics（latency、cost、success rate）
• error reporting（exception、timeout、failed node）

選定時の問い：runtime は tracing integration を持っていますか？ error tracking はどの程度できますか？

tracing のない agent system は、本番では black box です。どの node が遅いのか、どの model call が失敗したのか、どの tool call が timeout したのかが見えません。問題調査は log grep に戻ってしまいます。monitoring と recovery design については AI Agent の監視、alert、失敗復旧 も参考になります。

デプロイとガバナンス：self-hosting、cloud independence、enterprise compliance

deployment model は self-hosted、cloud-independent です。

Continuum は enterprise-grade、self-hosted という位置づけです。Docker、Redis、vector DB、Temporal、Langfuse に依存し、これらは自社 infrastructure 上で動かせます。

選定時の問い：runtime は self-hosting を支えますか？ enterprise governance design を持っていますか？

project に「data を社外に出せない」という要件がある、または audit、compliance record が必要なら、self-hosting は hard constraint になります。runtime が特定 cloud platform の managed service に強く依存する場合、data compliance を満たせないことがあります。

能力 checklist：Continuum の complete capability table

選定時は、この表を使って Continuum の能力も、他の runtime の能力も照らし合わせます。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

この表は Continuum の product introduction ではありません。選定 framework です。各行が 1 つの観点であり、それぞれが選定時の問いに対応します。

類似 framework との比較：Continuum は ecosystem のどこにあるか

2026 年の agent runtime ecosystem で主な選択肢は次のとおりです。

Continuum の独自性は、Smart Inference の cost routing、MCP native support、enterprise self-hosting の組み合わせです。

選定時、production readiness では LangGraph と DeepAgents のほうが mature です。一方、Continuum は cost routing と MCP native の設計に特徴があります。scenario が cost-sensitive で、MCP tool ecosystem を必要とするなら、Continuum の設計は検討する価値があります。LangGraph と AutoGen の state tracking 比較は LangGraph vs AutoGen state tracking も参考になります。

上手コストと risk

dependency list

Continuum は「pip install だけで終わり」の軽量 framework ではありません。enterprise runtime には infrastructure requirement があります。

• Python 3.13+
• Docker
• Redis（session history）
• Qdrant / Milvus（vector memory）
• Temporal（durable workflow）
• Langfuse（observability）

installation example

# インストール
git clone https://github.com/shyftlabs/continuum
cd continuum
python3.13 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
docker compose up -d
echo "SMART_GATEWAY_URL=https://continuum.shyftops.io/v1" >> .env

# 最小構成の形
python - <<'PY'
from orchestrator.agent import BaseAgent
from orchestrator.agent.runner import AgentRunner

agent = BaseAgent(
    name="assistant",
    instructions="You are a helpful assistant.",
    model="gpt-4o-mini",
)

# 実際の project では、async runner、session、memory、gateway configuration を公式 docs に従って使う
PY

注意点として、docker compose up -d が起動するのは local infrastructure の一部です。production deployment では Temporal、Langfuse、provider key、network permission の追加設定が必要です。細部は公式 documentation を source of truth にしてください。

向いている scenario

• enterprise project：cost control、durability、observability が必要
• self-hosting requirement：data を社内に残し、cloud independence が必要
• multi-agent collaboration：複数の orchestration pattern が必要
• cost-sensitive workload：Smart Inference routing が必要

risk note

• new-project risk：2026-06 時点で GitHub stars は約 70+。API や module name は変わる可能性があります。
• cost claim の検証：250+ models / 45+ providers は project-stated figures であり、実測確認が必要です。
• boundary limitation：Temporal、Langfuse に依存するため、lightweight scenario には向きません。
• documentation dependency：command は最小例にとどめ、詳細は official docs に委ねます。

まとめ：自分の Agent Runtime 選定 framework を作る

agent runtime の選定で見る軸は 7 つです。

1. オーケストレーションパターン：multi-agent collaboration を支えるか。sequential / parallel / routing / planning / reflection など、どの pattern が必要か。
2. モデルルーティング：cost-aware mechanism があるか。請求の暴走を防げるか。
3. メモリシステム：短期と長期を分けているか。vector DB integration は柔軟か。
4. ツール標準：MCP native か。既存の MCP server ecosystem を使えるか。
5. 永続化実行：checkpoint recovery と human approval を支えるか。
6. 可観測性：tracing integration があるか。error tracking はどこまでできるか。
7. デプロイガバナンス：self-hosted、cloud-independent か。enterprise compliance need に対応できるか。

Continuum は、production runtime stack の例として役立ちます。9 種類の multi-agent pattern、Smart Inference cost routing、MCP native support、Temporal durable execution、Langfuse tracing を示しているからです。ただし、選定は模倣ではありません。自分の scenario の重みに合わせて、LangGraph、DeepAgents、CrewAI と比較してください。

次の step は、自分の scenario requirement を書き出し、この 7 つの観点で runtime ごとに照合することです。