Routinesは定期実行をFoundryプロジェクト内へ持ち込み、外部ジョブ基盤を用意せずAgentを起動できる。便利さの一方で、スケジュールが重なった場合や前回処理が未完了の場合の業務整合性は自動で保証されない。単純な定期処理と、承認・分岐・複数Agentを含むWorkflowを区別する必要がある。
何が変わったか
Microsoft Foundryでスケジュールをtriggerとして1つのagent actionを実行し、run historyを確認できるRoutinesが利用可能になった
| 項目 | 内容 |
|---|---|
| 対象 | Microsoft Foundry |
| API・機能 | Foundry Routines |
| 変更種別 | Agent・MCP |
| 重要度 | 高 |
| 対応期限 | 期限なし |
変更前後の差
従来はLogic Apps、Functions、CI、独自scheduler等からAgentを呼ぶ構成が必要だった。Routinesはタイマーまたはcronで一つのprompt agent・hosted agentを実行し、履歴を確認できる。最短間隔は5分で、1 routineは1 trigger・1 actionを前提とする。
誰に影響するか
日次要約、監視レポート、定期データ更新、定型問い合わせ処理に影響する。複数Agentの連携、分岐、承認、長い補償処理が必要な用途はWorkflow等の別機能が適する。
期限
プレビュー機能の導入期限はない。対応リージョンとプロジェクト条件を確認し、小規模な非重要処理から始める。
必要な対応
実行対象Agentのversionを固定し、routineへ秘密情報を直接書かない。業務日付とタイムゾーンを明示し、同じ予定時刻の再実行でも二重登録しない冪等キーを作る。失敗、遅延、連続失敗、手動再実行の担当を決める。
実装・移行手順
- 単一Agentで完結する定期処理を選ぶ
- 予定時刻とタイムゾーンを業務要件で確定する
- 対象Agent versionと接続権限を固定する
- 実行IDと業務日付を使った冪等制御を実装する
- 意図的に失敗させ、run historyと通知を確認する
- 複数actionが必要になった時点でWorkflowへ移行する
失敗しやすい点
cronのタイムゾーンを誤る、前回実行中に次回を開始する、手動再実行で二重処理する、routine入力へsecretを書く、複雑な業務を1 actionへ押し込むことが問題になる。
リスク
二重登録、通知漏れ、期限後実行、Agent version変更による出力差、権限過剰、プレビュー仕様変更がある。
評価方法
- 予定時刻からの開始遅延
- 成功・失敗・連続失敗率
- 重複処理件数
- 平均・最大実行時間
- 手動再実行件数
- Agent version別品質
ロールバック
routineを無効化し、従来のschedulerから同じAgent endpointを起動する。処理結果の正本と冪等キーを外部に維持しておけば、実行基盤だけを戻せる。
編集部分析
Routinesはオーケストレーターの代替ではなく、単純な定期起動をFoundry内で管理する機能である。採用判断はコード量削減ではなく、障害時の可視性と運用責任が明確になるかで行うべきである。
実務チェックリスト
- [ ] 1 trigger・1 actionで完結する
- [ ] タイムゾーンを確認した
- [ ] 冪等キーがある
- [ ] 秘密情報を書いていない
- [ ] 失敗通知を試験した
- [ ] Workflowへの移行条件を決めた