AI対応の実行をControl-MとAWSで

AWS上のAIワークフローオーケストレーションとは何ですか？

AWS上のAIワークフローオーケストレーションは、AIモデル、エージェント、およびそれらに供給されるデータパイプラインを1つの統制された生産プロセスとして実行することです。

Control-Mを使用して、Amazon Bedrockエージェント、Amazon SageMakerモデル、AWSデータサービス、アプリケーション、およびファイル転送を単一のワークフローで調整します。Control-Mはステップ間の依存関係を追跡し、サービスレベル契約（SLA）を管理し、すべての実行に対して監査証跡を保持します。

チームはプロセス全体を把握し、ビジネス結果が順調かどうかを確認し、遅延が発生する前に対処します。プロセスがAWSを超える場合、同じワークフローがハイブリッド環境全体に持ち込まれます。

AIイニシアチブが停滞する場所

AWSを含むハイブリッド環境でAIを運用するほとんどの企業にとって、制約はモデルの品質や自動化の範囲ではありません。それは、システム間で何が起こるかの信頼できる記録が欠如していることです。パイプラインが遅れて終了し、エージェントが生成したものに基づいて行動し、下流の作業が不完全なデータに基づいて実行されます。誰かがこれらのイベントを接続したときには、ビジネスプロセスはすでにそのウィンドウを逃しています。単一のシステムが失敗したわけではなく、それが問題が検出されなかった理由の1つです。

エージェントの採用は問題を悪化させます。チームは、Amazon Bedrockエージェント、カスタムエージェント、およびフレームワークベースのエージェントを別々のAWSアカウントやビジネスユニットに展開します。それぞれが独自のトリガーを持ち、承認パス、実行ポリシー、または監査記録を共有するものはほとんどありません。すべてのエージェントステップは、ビジネスが依存する別の実行パスを追加します。どのチームもそれらのパスがどのように接続されているかの完全なビューを持っていないため、停滞したステップは通常、アラートではなく欠落したレポートを通じて表面化します。

Control-MがAWSでオーケストレーションするもの

AWSを超えて、Control-MはSnowflakeおよびDatabricksと統合されており、プラットフォームの境界を越えるパイプラインは単一のワークフロー内に留まります。

企業がControl-MでAIをオーケストレーションする方法

AI駆動のオーケストレーション

AIはControl-Mをより直感的で知的、そして生産的にします。

• AIエージェントとアシスタントからControl-Mを操作する
  Control-Mモデルコンテキストプロトコル（MCP）サーバーは、AIエージェントとアシスタントにControl-Mへの安全な標準ベースのインターフェースを提供します。ワークフローのステータスを確認したり、障害を調査したりするだけでなく、エージェントは既存のユーザーと役割の承認の下でタスクをトリガーするなどの運用アクションを実行できます。
  
  
• ワークフローライフサイクル全体でAIを活用する
  Control-Mは、Amazon Bedrock上で独自のAI機能を構築しています。Control-M AIアドバイザーのJettは、チームがワークフローを理解し、実行された内容をトラブルシューティングするのを助けます。Control-M AIパイロット機能、AIワークフロークリエイターを含むそれらは、チームがワークフローを構築、分析、および最適化するのに役立ちます。これにより、チームの誰もがワークフローを理解し、構築し、分析できるように、ワークフローライフサイクルの各段階に知性がもたらされます。
  
  BMCは、その柔軟性、安全性、および基盤モデルの幅広いサポートのためにAmazon Bedrockを使用しています。

生産におけるAIをオーケストレーションする

Control-MはAIモデルとエージェントを生産準備が整ったワークフローに組み込み、実行を管理します。

• ワークフローステップとしてAIエージェントを実行
  Control-Mは、すでにSLA、承認チェックポイント、監査要件を備えた生産ワークフロー内でAmazon Bedrockエージェントステップを実行します。生産データで動作するエージェントには、他の生産ステップと同様の制御が必要であるため、各エージェントステップには依存関係、再試行ポリシー、および実行記録が含まれています。
  
  
• モデルとダッシュボードに完全なデータを提供
  Control-Mは、Amazon S3、AWS Glue、AWS Glue DataBrew、Amazon Redshift、Snowflake、Databricks、およびAmazon SageMaker全体での取り込み、変換、および配信を1つのワークフローで調整し、1つの依存関係セットを提供します。分析およびAI出力は、フィードするパイプラインの信頼性に依存します。
  
  ソースファイルが遅れて到着した場合、Control-Mはすでにそのファイルを待っている下流のステップと、どのSLAがリスクにさらされているかを特定しています。Control-M SLA Managementは、まだ対応する時間がある間にリスクを報告します。
  
  
• ハイブリッドワークフローを一度定義する
  Control-Mは、パートナーのファイル転送、ERPジョブ、およびクラウドサービスを1つのプロセスとして定義し、1つのチームによって実行され、1つの監査証跡に記録されます。ビジネスプロセスは通常、これらの境界に沿って整合しません。パートナーからファイルが到着し、ERPジョブがそれを掲載し、クラウドサービスがそれを変換し、ビジネスユーザーに誰もシステムの可視性を持っていないレポートが配信されます。
  
  ステップがどこで実行されるかは、Control-Mがそれを管理する方法を変更しません。管理されたファイル転送は、それに依存するステップと同じワークフロー内で実行されるため、遅れた転送は他のすべてのステップと同様にSLAリスクとして表示されます。
  
  
• ワークフローが実行される場所に関係なく一貫した制御を適用する
  Control-Mは、AWS上で実行されるか、ハイブリッド環境内の他の場所で実行されるかに関係なく、すべてのワークフローに同じポリシー、権限、および監視を適用し、人、時間ベースのトリガー、イベント、またはエージェントがそれを開始します。
  
  ワークロードポリシーは、AWSアカウントおよび環境全体にわたって実行時ルールを強制します。役割ベースの認可と職務分離により、誰がワークフローを定義、実行、変更できるかが決まり、人間の承認チェックポイントは、誰かがサインオフするまで敏感なステップを保持します。
  
  すべての実行は、何がいつ、誰の権限の下で、どのような結果で実行されたかの記録を保持します。Control-Mは、同じ基準で自動回復およびロールバックアクションを記録し、監査人とオペレーターが同一の履歴から作業できるようにします。