ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
マルチステップエージェントAIワークフローの可観測性と障害回復
インシデントが発生する前にSLAリスクを予測します。モニタリングのみでは、これらの下流の障害を検出できません。
エージェントが企業プロセス内で決定を下すと、その結果は別の場所に影響を及ぼします。管理されたファイル転送がトリガーされ、データパイプラインが開始され、バッチジョブが解放されるか、記録システムが更新されます。作業はビジネスを実行するシステム全体に広がり、そこで悪い決定が遅延支払いの実行、SLAの遅延、または顧客が気付くまで誰も見ない下流の障害になります。
AIモデルを監視するために構築されたツールは、モデルが何をするかを伝えるのが得意ですが、次に何が起こるかを伝えるために構築されていません。Control-Mは、その「次」が起こる層で動作します - ワークフローが実行され、依存関係が解決され、SLAのコミットメントが時間通りに満たされるか失敗する層です。この層には常に独自の障害があり、エージェントAIがそれらを予測しにくくし、回復困難にしています。
このガイドは、これらの障害と、それを早期にキャッチし安全に回復するために必要なことについてのものです。
ワークフローの可視性が意味すること (および意味しないこと)
ワークフローの可視性は、マルチステップビジネスプロセスの実行に対する可視性です。各ステップの状態を示します - 実行中、待機中、完了、失敗 - そしてその状態がプロセスが提供することになっている結果に何を意味するのかを示します。モデル層ではなく、実行層を監視します。
この区別は、エージェントAIが関与する場合に、生成AIの世界よりも重要です。モデルの出力がほとんどストーリーの終わりだった時代は終わりました。今やその出力が下流の実行を引き起こし、両方の層が追跡すべきライブなものになります。
モデルの可視性はエージェントを監視します: プロンプト、トークン使用量、呼び出しの待機時間、出力が幻覚のように見えるかどうか。
ワークフローの可視性は、エージェントが動かしたものを監視します: エージェントが実行すべきだと決定したパイプライン、次のステップが開始される前に完了しなければならない転送、すべてが時間通りに完了することに依存するSLAです。
モデル監視ツールは、エージェントが特定のツールを呼び出すことを選択したと告げることができます。それは、その呼び出しによってトリガーされたジョブが現在40分遅れており、3つの依存サービスがリスクにさらされているかどうかを伝えることはできません。それは異なる信号であり、異なるシステムによって追跡され、生産環境でAIを運用している企業は両方が必要です。
|
ツールの動作 |
モデルの可視性 |
ワークフローの可視性 |
|
監視 |
エージェント |
エージェントが動かしたもの |
|
追跡 |
プロンプト、トークン使用量、呼び出しの待機時間、出力の質 |
ジョブのステータス、依存関係、タイミング、SLAのステータス |
|
伝えられること |
エージェントが特定のツールを呼び出すことを選択した |
その呼び出しによってトリガーされた下流のジョブが遅れており、依存サービスにリスクを与えている |
|
伝えられないこと |
下流の実行が順調であるかどうか |
エージェントの出力が幻覚であったかどうか |
ワークフローの可視性は、エージェントの出力がスケジュールされたジョブの予測可能性よりも低い設定で難しくなります。従来のワークフローは、同じステップを同じ順序で実行します; 何かが壊れると、馴染みのある場所で壊れます。エージェントが次に何をすべきか決定できると、作業の形状は実行ごとに異なり、したがって下流の依存関係、タイミング、回復経路は、固定スケジュールが課していたよりも多くの変動に耐えなければなりません。ワークフロー層での可視性は、オペレーションチームがその変動がSLA違反に変わるのを防ぐ方法です。
障害モード: ワークフロー層で何が間違っているのか
実際の損害を引き起こすワークフロー層の障害は、報告されたステータスと実際の結果が不一致のものです。ジョブがホストに到達できずにエラーが発生した場合、ステータスと結果は一致し、障害は処理されます。より難しいケースは静かです: プロセスは技術的には良好ですが、ビジネス結果はそうではなく、ステータスにおいて二つを区別するものは何もありません。
これらの難しいケースのうちの4つがよく発生します。
- 遅延到着: エラーベースの監視が見逃す障害
最も一般的なのは遅延到着です。エージェント駆動のステップは、プロセスが予期していたよりも遅れて出力を生成し、それに依存するすべてのステップが遅延を受け継ぎます。通常、ビジネス日が始まる前に完了するデータパイプラインが午前9時にまだ実行中です。4時間の余裕があった調整が今は何もありません。何もエラーが発生していないため、アラートはトリガーされませんが、SLAはすでに破られています; それはまだ気付かれていません。遅延は、エラーが発生していないため、エラーに基づく監視が単純に見逃す障害モードです。 - 静かな依存関係の失敗: ワークフローが完了するが結果が信頼できない場合
静かな依存関係の失敗では、ステップがワークフローを停止させない方法で失敗します: おそらく、次のステップが十分すぎると見なすステータスを返すか、誰も見守っていないブランチで失敗します。プロセスは信頼できない結果の上に進行し続けます。ワークフローは完了しますが、完了は嘘です。障害が表面化する頃には、悪いまたは欠落している出力が次に実行されたものにすでに伝播しており、質問はもはや「何が失敗したか」ではなく「失敗の上に何を構築したか」です。 - 部分的な完了: 再実行が安全でない場合
部分的な完了は、「再実行する」ことがいつも安全ではない障害モードです。プロセスが途中まで進み、停止します: ホストがダウンし、資格情報が期限切れになり、接続が切断されます。それは一部のステップは完了し、一部は完了せず、一部は誰も確信できない状態に置きます。再実行すると、すでに成功した作業が繰り返される可能性があり、トランザクションが二重投稿されたり、ファイルが再送信されたりすることがあります。安全な回復には、プロセスがどこで停止したか、何が無害に再開できるかを正確に知る必要があります。 - 暴走再試行: ローカル障害がシステム全体のSLAリスクになる
暴走再試行は、完了できないステップから始まり、再試行し続けます - そして、何度再試行できるかを制約するものがないため、再試行し続けます。同じ作業が何度も試みられ、他のジョブが必要とする実行容量を消費します。即時の症状は障害ではなく、競合です。クリティカルパスの作業が遅くなるのは、他の場所でスタックしたプロセスがそれに依存するリソースを消費しているためです。障害はローカルですが、SLAリスクはシステム全体に及びます。
これらの4つの障害はすべて異なりますが、同じ盲点を暴露します: それぞれにおいて、エラーに基づく監視によって表面化された情報は、ビジネス結果が安全かどうかを判断するには不十分です。このような障害をワークフロー層でキャッチするには、ステップがクリーンに実行されるかどうかだけでなく、それらの上流および下流の依存関係と、実行されているコミットメントを可視化する必要があります。これらの障害のうちの3つは、正しい方法で実行を監視するだけで十分です。4つ目はもう少し必要です: 異常パターンに気づくためにオペレーターを待たない検出が必要です。
これらの障害の可視性はどのようなものか
ワークフロー層の可視性には三つの種類があり、これらの障害に対抗するために大部分の作業を行いますが、二つのAI機能がさらに進んでいます。
サービスビュー：SLA違反が発生する前に見る
最初はサービスビューです。個々のジョブの上にある層で、ステップのセットがビジネスサービスとして理解されます。Control-Mのサービス管理は、重要なフローを特定し、重要なジョブが必要なときに完了する予定であるかどうかを追跡することで、予測的なSLAリスクの可視性を提供します。これは、遅延が明白になる高度です。「ジョブ47が長く実行されています」ではなく、「ジョブ47が属するサービスがそのウィンドウを逃すことになります」となります。仕事だけでなくサービスを監視しているオペレーターは、まだ防ぐ時間がある間にSLA違反が来るのを見て取ることができます。
依存関係ビュー：障害が何をダウンさせるかを追跡する
次に依存関係ビューがあります。プロセスのステップがどのように接続しているかを示す地図で、どのものがどれに供給しているかや、特定のジョブがチェーンのどこに位置しているかを示します。Control-Mは、明示的な依存関係を持つ視覚的に接続されたジョブとしてワークフローを表現し、オペレーターがフラットなジョブリストとしてではなく、上流および下流の関係とともにワークフロー全体を見ることを可能にします。これにより、静的な依存関係の障害が謎から位置に変わります。次のステップが信頼すべきでない結果を返すと、依存関係ビューがその下流にあるすべてのものを示します。
状態ビュー：プロセスがどこにあるかを正確に知る
三つ目は状態ビューです。プロセスがどの状態にあるかを正確に知る能力です：完了したもの、実行中のもの、待機中のもの、失敗したもの。Control-Mのビューは、障害、待機、ボトルネックを一目で可視化し、オペレーターが症状から特定のジョブとそのログに掘り下げることを可能にします。これは部分的な完了から回復するのに必要なことです：プロセスが停止した正確な場所と、そこに残された状態を知ることが必要です。
Control-MのAI機能によるAIエージェントの可観測性
モニタリングのためのAIパイロット：障害の可視化から理解へ
これらの上には新しい層があります。Control-MのAIパイロットによるモニタリングは、Control-M SaaSで利用可能で、オペレーターが手動で読むのと同じ実行データにAIを適用します。「Not OK」またはホスト上で待機中のジョブがあった場合、そのジョブのステータス分析は、ジョブの出力、ログ、定義、およびホストの状態から、考えられる原因を説明し、修正アクションを推奨します。一方、そのワークフロー分析は、そのジョブが属するワークフローの構造と目的を説明します。AIパイロットは、オペレーターが見えないものは見えません。同じ信号をより早く読み、考えられる原因と推奨される修正をオペレーターの前に置きます。サービス、依存関係、状態ビューが障害を明白にするのに対し、この層は、障害を見て理解するまでの距離を短縮します。
実行インサイト：危機になる前に無限リトライを捉える
無限リトライは別のものを求めます。それは、既に見えている障害を診断するのではなく、危機になる前にパターンを特定することです。Control-Mの実行インサイトは、Control-M SaaSで利用可能で、異常検出を最近のジョブ履歴のロールウィンドウに適用し、通常の動作を大きく外れて動作するジョブ、遅延のある開始、キューの蓄積、バッチパフォーマンスに圧力をかける同時実行のピークをフラグします。圧力をかけている特定のジョブを指摘し、それによって単に苦しんでいるジョブではなく、早期にパターンを見つけて損害を抑えます。リトライ嵐を早期に捕まえることで、ローカルな障害がクリティカルなジョブの連鎖を倒すのを防ぎます。
リカバリー: 安全な対応に必要なもの
障害を見ることは問題の最初の半分です。残りの半分は、それを悪化させずに対応することです。ここで、エージェント駆動プロセスからのリカバリーは、通常のプロセスから最も大きく逸脱します。失敗した作業が予測可能なものであった場合、修正も通常そうです: ジョブを再実行し、パイプラインを再開し、先に進みます。しかし、エージェントの決定が何を実行するかを形作った場合、これらの反射的な修正が安全であるとは限りません。
If-Actions: 事前にリカバリーをエンコードする
一部の障害は、エージェントが何をしたかを知る必要はありません; それらは単にジョブのステータスを知る必要があります。その場合、Control-MのIf-Actionsを使用すると、特定の条件が満たされたときに何をすべきかをワークフロー定義にエンコードできます。すべてが間違っている前に: 終了時にジョブを再実行し、定義された試行回数まで試みます; 失敗数が達成されたら再試行を停止し、代わりにアラートを上げます; ジョブを既知の状態に設定し、その出力を別の宛先に渡すか、次に実行するものを制御するイベントを追加または削除します。リカバリー論理はすべての実行に対して同じであり、ワークフローをレビューする誰にでも見えるものであり、予め設定された制限によって制約され、プレッシャーの下で即興で行われるものではありません。 (実行が開始される前に制約をエンコードする原則は、Control-Mのリカバリー以上のものに適用されます。)
Jett: 何をするかを決定する前に何が起こったかを再構築する
応答する前に何が起こったかを理解する必要がある障害については、Jett (Control-MのAIアドバイザー, Control-M SaaSで利用可能) がオペレーターにその状況を平易な言葉で把握させます。ログやステータス画面をナビゲートするのではなく、どのジョブが実行されたか、どのジョブが失敗したか、どの状態が残されたか、およびどのようなアクションが取られたかを尋ねることができ、テキスト、表、またはチャートで答えを得ることができます。その文脈は、オペレーターが自信を持って行えるリカバリー決定と、部分的な可視性の下で行われる決定との違いです。
AIパイロットによるモニタリング: 原因と推奨アクション、迅速
ジョブがエラーステータスで終了するか、ホストを待って停止しているとき、AIパイロットによるモニタリングはJettのワークフロー全体の画像を超えます。ジョブの出力、ログ、定義、ホストのステータスを基に、可能性のある原因を特定し、是正措置を推奨し、オペレーターが迅速かつ情報に基づいた決定を下すための準備をします。
MCPサーバー: AIエージェントによる管理された実行
MCPサーバー, Control-M SaaSで利用可能, はその機能をAIエージェントへ直接もたらします。AIエージェントはジョブのステータスを照会し、ログを取得し、修復アクションを実行できます: ジョブを再実行する、保持する、解放する、OKに設定する。すべてのステップで人間が介在する必要はありません。MCPサーバーは、アクションが実行される前に確認を要求することができ、Control-Mの他のすべてのアクションを管理する役割ベースのアクセス制御が適用されます。
実際には、同じワークフローがIf-Actionsに依存して既知の障害を自動的に処理し、JettとAIパイロットによって人間の判断が必要な障害に対するオペレーターを装備します。MCPサーバーは、他のすべてと同じ管理されたフレーム内で直接行動できるAIエージェントという第三の道を追加します。
監査、説明責任、実行を超える記録
プロセスが完了すると、質問は止まりません。数週間後、誰かがなぜ数値が間違って見えたのか、制御が遵守されたか、壊れたステップを変更したのは誰か、またはSLAが遅れた夜に何が実行されたかを尋ねます。これらの質問に答えるには、プロセスが残した記録に依存します。(AIワークフロー全体でControl-Mがどのように実行したことを記録し証明するかの詳細については、監査の準備が整った実行の系譜を参照してください。)
エージェント駆動の作業は、その記録の重要性を高めます。各ステップを人が開始した場合、説明責任には名前が付いていました - 誰がそれを行ったか、なぜそうしたかを尋ねることができます。エージェントが実行時に何を実行するかを決定した場合、さまざまな実行の中で誰が詳細を覚えているかを尋ねることはできません。アカウントはシステム自体から来る必要があります。
Control-Mはそのアカウントを保持します。結果だけでなくアクションも記録されます - ジョブに対して取られたユーザーアクションとジョブ定義に加えられた変更 - そのため、「誰がこれを変更したのか」という質問には、記憶に依存しない答えがあります (Jettはそれを平易な言葉で引き出すことができます)。
そのアーカイブサービスはワークフロー実行データを監査のために保持し、チームが現在の実行を過去のものと比較できるようにします。そして、Control-Mはメインフレーム、クラウド、ハイブリッド実行を1つの場所で横断しているため、メインフレームバッチジョブ、クラウドデータパイプライン、およびファイル転送に触れるプロセスは、3つのツールに散在する3つの部分的な記録ではなく、1つのトレース可能な記録を残します。
完全で読みやすい記録は、可視性が説明責任に変わる場所です。
AIエージェントワークフロー可視性のFAQ
ワークフローの可視性はAIエージェントとどのように機能しますか？
ワークフローの可視性はモデルの可視性とどのように異なりますか？
AIエージェントが引き起こすワークフローの障害はどのようなものですか？
AIエージェントによって引き起こされたワークフローの障害からどのようにリカバリーしますか？
エージェント駆動のワークフローにおける監査と説明責任はどのように機能しますか？
Control-Mはエージェント駆動のAIワークフローに対してどのように可視性を提供しますか？
AIエージェントワークフロー可視性のFAQ
ワークフローの可視性はAIエージェントとどのように機能しますか？
ワークフローの可視性はモデルの可視性とどのように異なりますか？
AIエージェントが引き起こすワークフローの障害はどのようなものですか？
AIエージェントによって引き起こされたワークフローの障害からどのようにリカバリーしますか？
エージェント駆動のワークフローにおける監査と説明責任はどのように機能しますか？
Control-Mはエージェント駆動のAIワークフローに対してどのように可視性を提供しますか？
