Temporalの複数AIフレームワーク連携が一般提供、再生機構とプレビューのストリームを区別

Temporalは10月30日、複数のAIライブラリとエージェント用フレームワーク向けの連携機能を一般提供すると発表した。本サイトの掲載日は11月1日で、元の発表日は10月30日である。一般提供という表示は列挙された連携パッケージに関するものだ。トークンを流すWorkflow StreamsはPythonとTypeScriptで別途パブリックプレビューとされ、同じ提供段階として扱えない。

対応表には言語の範囲が明示されている。Google ADKはPython、Go、TypeScript、OpenAI Agents SDKはPythonとTypeScriptで、Python版はすでに一般提供だった。AWS StrandsはPythonとTypeScript、LangGraphはPython、LangSmithはPythonとTypeScript、Vercel AI SDKはTypeScript、Gemini SDKはPythonである。単に「多くのフレームワークに対応」と読むと、存在しない言語の実装まであるかのように誤解する。導入時には実際に使う言語のパッケージと文書を確かめる必要がある。

設計上の境界は、長く続く調整を担うWorkflowと、外部で作用するActivityとの分離だ。モデル呼び出し、API要求、データベース操作などはActivityで実施する。連携機能は各フレームワークの振る舞いをこの境界に対応づける。Google ADKのPython例では、通常のモデル名に代えて`TemporalModel`を指定し、モデル呼び出しをActivityとして実行する。ClientとWorkerに`GoogleAdkPlugin`を登録して再生可能なループにする。他のフレームワークにはそれぞれ異なる接続点がある。

復旧はEvent Historyに記録された進捗に依存する。Workerの再起動やデプロイによる中断の後、TemporalはWorkflowを履歴から再構築し、完了したActivityについては保存済みの結果を再利用する。原則として同じモデルやツールへの要求を再送しない。費用が生じたり外部状態を変えたりする処理では重要な性質だが、どんなコードでもパッケージを読み込むだけで安全になるわけではない。副作用を正しいActivityの境界に置く必要がある。

再試行の責任も整理する。Temporalの説明では、フレームワーク側の再試行ループを止めるか調整し、Temporal側で再試行とタイムアウトを管理する。二重の再試行は呼び出し回数を増やし、障害の原因を見えにくくする。クライアントと資格情報はWorkerに置き、Workflow履歴に混ぜない。プロセス間でトレースの文脈を渡しつつ、再生によって同じspanを重複出力しないことも連携の役割に含まれる。

エージェントは人の承認や外部入力を待つ間、Workerのプロセスを占有せずに済む。対応する環境ではWorkflow Streamsでトークンを流せるが、ここだけは公開プレビューという条件を保つべきだ。既存のWorkflowを更新する場合はrelease notesを読み、破壊的変更やWorker Versioningの必要性を確認する。古い実行が終わる前に新しいコードへ一律に切り替える判断は避けたい。

実務上は、対象言語のサンプルを動かし、意図的にWorkerを中断して復旧させ、履歴と外部APIの記録から重複呼び出しがないか確かめる。その結果を本記事は測定していない。公表されたのは連携群の一般提供と共通の実行モデルであり、具体的な運用品質は利用者のフレームワーク、言語、Activity境界の設計で検証する必要がある。