Control-MとAWSによるAI対応実行

AWSにおけるAIワークフローオーケストレーションとは何ですか？

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

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

チームは、遅延が発生する前にビジネスの成果が順調かどうかを知るために、全プロセスを見ることができます。プロセスがAWSを超える場合、同じワークフローがハイブリッド環境全体を通じてそれを運びます。

AIイニシアチブが停滞する理由

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

エージェントの採用は問題を悪化させます。チームは、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管理は、応答する時間がまだある間に露出を報告します。
  
  
• ハイブリッドワークフローを一度定義する
  Control-Mは、パートナーファイル転送、ERPジョブ、クラウドサービスを1つのプロセスとして定義し、1つのチームによって実行され、1つの監査証跡に記録されます。ビジネスプロセスはこれらの境界に沿って調整されることはほとんどありません。パートナーからファイルが到着し、ERPジョブがそれを投稿し、クラウドサービスがそれを変換し、ビジネスユーザーにレポートが配信されますが、そのシステムの可視性はありません。
  
  ステップがどこで実行されるかは、Control-Mがそれを管理する方法を変更しません。管理されたファイル転送は、それに依存するステップと同じワークフロー内で実行されるため、遅延転送は他のすべてのステップと並んでSLAリスクとして表示されます。
  
  
• ワークフローが実行される場所に関係なく一様な制御を適用する
  Control-Mは、AWS上で実行されるか、ハイブリッド環境内の他の場所で実行されるかに関わらず、すべてのワークフローに同じポリシー、認可、および監視を適用し、開始するのが人、時間ベースのトリガー、イベント、またはエージェントであるかどうかを問わず、適用します。
  
  ワークロードポリシーは、AWSアカウントと環境全体でランタイムルールを強制します。役割ベースの認可と職務分掌が、誰がワークフローを定義、実行、および変更できるかを決定し、人間の承認チェックポイントが、誰かがサインオフするまで敏感なステップを保持します。
  
  すべての実行には、何が実行されたか、いつ、誰の権限で、どのような結果であるかの記録が含まれます。Control-Mは、同じ基準で自動回復およびロールバックアクションを記録しているため、監査人とオペレーターは同一の履歴に基づいて作業します。