ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
ガバナンスされたAIプレイブック
エージェントAIを、ビジネスが信頼するワークフローの中で実行する方法。
AIはControl-Mをより賢くします。Control-MはAIを製品化可能にします。
AIがワークフローに入ると、
ルールがテストされ、置き換えられることはない
Control-Mは、20年間複雑なワークフローを正しい順序で実行し続けています。生成AIとエージェントAIは、今やそのワークフローの中のさらなる要素であり、どちらも他のすべてのもののようには振る舞いません。
この本のすべてのプレイに共通しているパターン：AIは分析し、説明し、推奨します。Control-Mは結果を確認し、ログに記録します。
これらの5つのプレイは、既存のものを置き換えずにそれを取り入れる方法を示しています。
1
新しい物理学を見る
2
フラグメンテーションがあなたを見つける前に見つける
3
10のワークアラウンドではなく、1つのコントロールプレーンを構築する
4
AIを他のすべてと同様にガバナンスする
5
再スタートすることなく、パイロットから製品へ移動する
01
新しい物理学を見る
決定論的ワークフローは、自力で確率的AIを吸収できない理由。
給与計算、カード決済、航空スケジュール：すべてのステップが毎回同じように動作するからこそ機能します。生成AIはそうではありません。Amazon Bedrock上のモデルは、アクションを推奨したり、インシデントをトリアージしたりするかもしれませんが、明日は異なる回答を提供します。
AIのパイロットが停滞している理由として、信頼性や統合を挙げる説明が多いですが、実際の理由はもっとシンプルです：ガバナンスは固定された承認チェーンのために構築されており、確率的なステップはそれに結びつく場所がありません。Control-Mは、それに結びつく場所を提供し、提案し、確認し、ログを記録します。これはパイプライン内の他のすべてと同じ規律です。
02
見つける前に断片化を見つける
実際の失敗モードは悪いモデルではなく、盲点です。
ほとんどのオーケストレーションは静かに壊れます。複数のスケジューラーがサイロで動作し、スクリプトが隙間を埋め、手動ジョブの起動がビジネス全体に散らばっています。給与計算が実行を逃したり、決済ジョブが失敗したりするまで、誰も気づきません。
その上に AI を追加すると、盲点が悪化します。修正を推奨したり、インシデントをトリアージしたりするモデルは、作業している可視性に比例して良いものです。基盤となるパイプラインがすでにブラックボックスである場合、AI を追加することは、誰も完全に見ることができないシステムにもう一つの可動部分を追加することになります。
新しいものを追加する前に、右側のチェックを実行してください。Control-M の組み込み AI アドバイザーである Jett は、各質問に直接答えることができ、ログを調べる必要はありません。
03
10の workaround ではなく、1つのコントロールプレーンを構築する
AWS、データ、およびAIの単一ビュー
アプリケーション、データパイプライン、AIワークロードは通常、別々のスケジューラーでそれぞれ異なるルールの下で実行されます。それぞれは独自の問題を解決するために成長し、それぞれ独自の可視性、失敗ポイント、実際に機能している方法を知っている人がいます。それは、彼らの間の継ぎ目で何かが壊れるまで大丈夫ですが、誰も全体像を把握していません。
Control-Mは、そのパッチワークを一つのコントロールプレーンで置き換えます：一つの実行モデル、一つのSLAモデル、すべての3つにわたって。Amazon Bedrockを呼び出すワークフローは、同じように内部で実行されます。それは、パイプラインの外にあるブラックボックスではなく、一級のControl-Mジョブです。
| ドメイン | 通常これがどのように見えるか | Control-Mを使用して |
|---|---|---|
|
アプリケーション |
複数のスケジューリングツールと、各チームが管理するAWS Lambdaトリガーのミックス |
一つのプラットフォーム、共有実行およびSLAモデル |
|
データパイプライン |
AWS GlueジョブとSnowflakeタスクが別々のエラーハンドリングで縫い合わされています。 |
エンドツーエンドでオーケストレーションされ、依存関係と回復が中央で処理されます。 |
|
AIワークロード |
Amazon Bedrockを呼び出すワークフローで、他のすべてから切り離された一度きりのスクリプトとして実行されます。 |
同じSLA、承認、および監査トレイルを持つ管理されたジョブ |
03
AWSがクラウドを推進しています。
BMCが成果をオーケストレーションします。
AWSはAIが実行されるプラットフォームを提供します。Control-Mは、それが実行されている間、信頼性を保つための規律を提供します。どちらも互いに置き換えるものではありません。それが機能する理由です。AIパイロットは実行を監視し、何かが失敗したときに根本原因を明らかにし、修正を推奨します。
すでにAWSで構築中ですか？
Control-Mを、Amazon Bedrockを呼び出す既存のワークフローに向けてポイントします。AWS IAMが接続を処理し、新しい統合を構築する必要はありません。
すでにControl-Mを使用していますか？
Amazon Bedrockを活用したワークフローの追加は、他のジョブタイプを追加するのと同じように機能します：同じSLA、同じ承認、同じ監査トレイル。
試してみて: どちらの側から始めても、どのワークフローをこのガバナンスの下に持ってくるかを名前付けしてください。
まだどれかわからないですか？Play 5がそれを見つける方法を説明します。
ケーススタディ
Air EuropaがControl-MによってデータOpsを駆動し、飛躍する
700+
データリテラシー認定従業員
120+
稼働中のBIおよびデータソリューション
54%
DataOpsワークフローの効率が向上
“Control-M SaaSは、私たちのデータ、ML、およびAIロードマップの重要なエネーブラーであるAmazon SageMakerとの即時のアウトオブボックス統合へのアクセスを提供します。”
ホセ・カルロス・ベルメホ・ルビオ、データ＆アナリティクス部長、エア・エウロパ
03
AI ワークフロークリエーター: 意図から作業設計へ
ワークフローに名前を付けましたか？実際にそれを構築する方法は次のとおりです。
Control-M の技術的構造を知らなくても、ガバナンスされたワークフローを構築できます。あなたが望むことを説明する必要があります。平易な言葉で言ってください。AI ワークフロークリエーターが構造を提案し、ライブになる前にレビューして洗練する準備が整います。Control-M は、専門家が手作業で構築したものと同様にそれをガバナンスします。
1
欲しい内容を平易な言葉で説明してください
2
提案されたワークフローを確認する
3
すべての他のものと同様に、規制された状態で洗練し、アクティブ化します
試してみる: 実際に必要なワークフローのために、私たちのプロンプトを入れ替えてみてください。それが次回これを開いたときに提案されるものです。
04
他のすべてと同様にAIをガバナンスする
Control-MはAIプラットフォームでもエージェント構築ツールでもありません。
あなたの環境で今日すでに実行されているすべてのもの、決定論的なジョブとAI駆動のステップを同じ制御下で管理するためのガバナンスレイヤーです。Control-M MCPサーバーはそのガバナンスを外向きに拡張します：Claude Desktop、Cursor、またはVS Codeのような外部エージェントがControl-Mにアクセスするための標準ベースの方法を提供します。提案されたすべてのアクションはControl-Mの既存の権限、SLA、監査証跡、およびレート制限を通じて実行されます。これは、AI専用の承認プロセスではなく、人間によって開始された作業にすでに適用されている同じ制御です。
セットアップ方法
01
発見する
エージェント、Claude Desktop、Cursor、VS CodeをMCPサーバーを介してControl-Mに接続します。これにより、カスタム統合コードなしでワークフロー、ジョブ、状態を直接読み取ることができます。
試してみてください：エージェントに昨日の環境で何が失敗したかを尋ね、それを開かずに答えるのを見てください。
02
行動する
エージェントは、1度に正確に1つのアクションを提案します：ジョブをトリガーする、失敗を調査する、再実行をリクエストする。エージェントは独自に何も実行しません。
試してみてください：今週の実際の失敗を1つ与え、何も触れる前に何を提案するか見てください。
03
ガバナンス
あなたは提案された内容を承認または拒否します。その決定とそれに至るすべてのことは、個人が開始した作業と同じSLAおよび監査証跡の下で実行されます。MCPサーバーは、同時に接続できるエージェントの数と、1分あたりに送信できるリクエストの数を制限しているため、承認された範囲内でもシステムが氾濫することはありません。
試してみてください：承認後に監査エントリを見てください。それはコンプライアンスレビューが引き出す記録です。
04
AIを実行するだけでなく、信頼を構築するためのガバナンスされたサンドボックス
構築してから廃止するための別のAIサンドボックスはありません。同じガバナンスのワークフローで権限を調整しているのです。最初のアクションからControl-Mがすでに施行している権限、SLA、監査証跡、およびレート制限が適用されます。パフォーマンスを見守ってください。信頼を得るにつれて、自動で行えることを広げていきます。
1つのガバナンスモデル、3つの視点
CIO / VP IT
説明 – AIが新しい、監査が難しいチャネルを開かずにミッションクリティカルなオペレーションに入ります。リスク、SLA、およびガバナンスは一つの平面上に留まります。
データ＆AIリード
説明 – Amazon Bedrock駆動のステップが不透明な生産リスクにならなくなります。推奨事項は、検査および調整可能な制御レイヤーを通じて実行されます。
プラットフォーム / クラウドエンジニアリング
説明 – AWSサービス全体の自動化のスプロールが制御されます。エージェントと人間は、もう一つのポイントツールを確保するのではなく、同じインターフェースを共有します。
05
パイロットから本番へ移行しても、最初からやり直す必要はありません。
パイロットから本番へ移行することは、最初からやり直すことを意味するわけではありません。各ステージは前のステージに直接基づいています。Play 3でワークフローに名前を付けた場合、それが本当に正しいものであるかを確認する方法は以下の通りです。もし名前を付けなかった場合、見つける方法は以下の通りです。
Control-M ガバナンスレイヤー
認可、SLA、監査、およびレート制限が適用されます
05
3つのステップで最初のAI対応ワークフローを見つけます：
以下の例は、ワークフローを見つけることがエンドツーエンドでどのように見えるかを示しています：実際の候補が3つ、触れるもののタグ付けがされ、最初にガバナンスを行う価値のあるものに絞り込まれています。
同じ3つのステップを自分の環境に対して実行してください。ワークフロー、SLA、承認者、必要な監査証跡を得ることができ、Amazon Bedrock統合のコードを1行も書く前にそのプロセスを完了できます。
-
3つの候補を特定します。
私たちの例は、夜間のSnowflakeロード、週次のSAPバッチ実行、およびAmazon Bedrockのインシデントトリアージフローから始まります。
-
AWSとAIの接続を特定します。
この例では、SnowflakeロードがAWSを使用し、Amazon BedrockフローがAWSとAIの両方を使用しています。SAPバッチ実行にはマークされた接続はありません。
-
1つを選択し、そのガバナンス要件を定義します。
Amazon Bedrockのインシデントトリアージフローでは、SLAはトリガーから15分以内の報告を要求し、プラットフォームのオンコールリードが承認者であり、すべてのアクションはControl-Mに記録されます。
AI が意図を作成します。エージェントがアクションを計画します。
Control-M が実行をガバナンスします。
これがこのプレイブックで辿ったループです: Jett と AI パイロットが Control-M をより賢くし、AI ワークフロークリエーターが平易な言葉を作業設計に変換し、MCP サーバーが外部エージェントに同様の方法でアクションを提案させ、Control-M for Amazon Bedrock がその結果をガバナンスされたジョブとして実行します。どれも、あなたがすでに信頼しているものを置き換えるものではありません。それを拡張します。