Continuum とエージェントランタイム選び：notebook から本番へ、見るべき 7 つの能力

notebook で 1 回動く Agent でも、本番では並行処理、復旧、記憶、モデル費用、tool audit、trace、人間の承認が必要になります。

Continuum は ShyftLabs の Python agent runtime です。typed agents、Smart Inference、MCP tools、Redis/vector memory、Temporal workflow、Langfuse observability を組み合わせます。 見るべき点は、どこに入れるか、どの境界を守るか、どこから先は自動化しないかです。

まず位置づけを決める

Continuum は ShyftLabs の Python agent runtime です。typed agents、Smart Inference、MCP tools、Redis/vector memory、Temporal workflow、Langfuse observability を組み合わせます。

既存の作業を全部置き換えるものとしてではなく、ひとつのレイヤーとして入れるほうが安全です。最初の接続範囲を小さくすれば、戻すのも監査するのも簡単になります。

境界で何が壊れるか

客服 Agent を本番へ出すなら、tool が呼べるかだけでは足りません。session state を Redis に置くのか、長期記憶を Qdrant/Milvus に置くのか、Temporal で失敗 workflow を再開できるのか、model routing で費用を抑えられるのか、approval gate はどこかを確認します。

失敗はたいてい境界で起きます。file access、model routing、write permission、token handling、billing fields、release credentials。ここが曖昧なまま自動化すると、間違いが速く大きくなります。

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

15%割引を入手 →広告

実際の能力を分解する

担当するレイヤー

Continuum が担当するのは、リクエストが tool call、configuration change、model route、file operation、external API call に変わる場所です。ログ、承認、費用制御、マスキングは、この近くにあるべきです。

担当しないレイヤー

これは小さな script library ではありません。Redis、vector database、Temporal、Langfuse は運用コストです。LangGraph、bare SDK、軽量 runtime と同じ表で比較するべきです。 ツールは作業を楽にしますが、compliance policy、secret storage、data retention、production rollout の責任までは肩代わりしません。

健全に動いているサイン

健全な構成には 5 つのサインがあります。設定を backup または version 管理できること。失敗時に rollback できること。sensitive data を最小化していること。cost や permission を role ごとに分けられること。依存する挙動を公式ドキュメントで説明できることです。

最小のコマンド例

最初は最小経路だけを試します。初回から全アカウント、全リポジトリ、本番データをつなぐ必要はありません。

export SMART_GATEWAY_URL=http://localhost:8080/v1
python -m continuum.worker --redis redis://localhost:6379 --temporal localhost:7233
python -m continuum.trace --langfuse-url http://localhost:3000

このコマンドは形の例です。package name、port、flag、binary name は、現在の README、release notes、または --help を優先してください。

判断表

この表はチームレビューにも使えます。便利なツールでも、permission、log、rollback、cost、代替案の答えが必要です。

リスクチェックリスト

第一に、若いプロジェクトは変わります。README の新しいコマンドを rollback なしで重要な workflow に固定しないほうが安全です。第二に、互換性は実測です。model、Office file、macOS release step、runtime demo はサンプルで動いても、実データで落ちることがあります。第三に、secret handling は別設計にします。API key、refresh token、signing profile、model billing key を prompt や repository に入れてはいけません。

監査ログも読みやすさが必要です。raw log があるだけでは足りません。誰が起動し、どの tool が走り、何が変わり、承認があったか、失敗後にどう戻すかまで追える状態にします。

公式ソース確認

shyftlabs/continuum README と docs を確認。Smart Inference、OpenAI 互換 endpoint、プロジェクト自述の 250+ models / 45+ providers、Redis/Qdrant/Milvus/Temporal/Langfuse の取捨選択を確認しました。

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

今すぐ始める →広告

これは信頼の丸投げではありません。一次情報で支えられる事実と、自分の環境で検証すべき仮説を分けるための記録です。

次に読むもの

• DeepAgents アーキテクチャ：planning tools、subagents、file system
• Workers で OpenAI API のプライベート経路を作る
• Workers AI 完全チュートリアル：毎日 10,000 回の無料モデル呼び出し

どれも、AI ツールを実作業へ入れるときに context、permission、cost、deployment を崩さないための話です。

runtime 比較：動くかだけで止めない

Redis、vector DB、Temporal、Langfuse

Redis は short-term session と state recovery を扱います。long-term knowledge ではありません。Qdrant/Milvus は vector memory を扱いますが、embedding、recall quality、deletion を管理します。Temporal は long task、retry、compensation、resume に向きます。Langfuse は trace、metrics、replay を提供します。

本番門番を acceptance criteria にする

production 前に、failed run はどこから resume するか、task あたり token/cost の上限はいくらか、どの tool call に approval が必要か、memory をどう delete するか、trace をどれだけ保存するか、provider failure の fallback は何か、logs の user data を誰が読めるかを答えます。

Smart Inference の現実的な境界

Smart Inference は routing を OpenAI 互換 endpoint の裏へ集約します。cost と migration には効きますが、classifier、provider availability、budget、output cap に依存します。本番では、なぜその model が選ばれたか、失敗時に retry するか、budget overflow 時に degrade するか reject するかも記録します。

acceptance test では失敗を作る

agent runtime の価値は壊れたときに見えます。success path だけを走らせないようにします。Redis を切る、model provider を止める、tool が 500 を返す、Temporal worker を restart する、vector store が no result を返す。task が retry、degrade、pause、fail のどれになるか、trace が残るかを見ます。

budget gate は task を止められるべき

cost routing があとから report するだけなら control ではありません。production では per-task budget、per-agent daily budget、per-provider monthly budget が必要です。超過時は cheaper model へ degrade、output を短縮、または task を reject します。

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

価格を見る →広告

段階的に移行する

LangGraph や raw SDK の project を一度に移す必要はありません。まず tracing を入れます。次に失敗しやすい long task を Temporal へ移します。そのあと repeated context と durable preferences を memory に入れます。Smart Inference は logs と cost tables で価値を確認してからです。

導入順序の提案

まず tracing と minimal runner だけを入れます。次に Redis で session と recovery を固めます。長期記憶が本当に必要な内容だけ vector store へ入れます。Temporal と approval gate は long task のために追加します。cost routing は、workflow を見て制御できるようになってから最後に入れます。

infrastructure の受け入れ順序

すべての dependency を一度に有効化しません。まず Langfuse か同種の tracing を入れ、model choice、tool calls、errors、cost を見えるようにします。次に Redis を入れて session recovery を確認します。その後 vector store に rebuild 可能な knowledge chunks だけを置き、最後に long tasks を Temporal へ移します。この順序なら問題を分離できます。trace が見えない段階で scheduling を疑わず、state recovery が不安定な段階で memory を広げません。

rollback switch も config に入れる

production pilot では能力ごとに rollback switch を用意します。Smart Inference を切って model を固定する、memory を切って current session だけ使う、MCP を切って manual tools に戻す、Temporal を切って short tasks だけ許可する、といった形です。各 switch には default、owner、trigger condition を持たせます。

導入順序

初日は read-only か低リスクのタスクだけを動かします。installation、logs、rollback を確認します。そのあとで、file write、external service call、billing を発生させる機能を追加し、高リスク操作には人間の承認を付けます。チーム利用へ広げるのは、version pin、runbook、secure secret storage、定期的な source review ができてからです。

この順序なら、実験コストを低く保てます。Continuum が本当に workflow の問題を解くのか、それとも動く部品を増やすだけなのかも見えやすくなります。