テクノロジとデータは、エージェントが信頼性の高い安全な大規模な運用に必要な基盤を提供します。
組織が小規模なパイロットからエージェントのエンタープライズ展開に移行するにつれて、アドホックな技術的選択と断片化されたデータ アクセスがすぐに制限要因になります。 明確なアーキテクチャ、標準、ライフサイクル管理がなければ、AI ソリューションを管理することは困難であり、運用が困難であり、スケーリングするリスクがあります。
この柱は、開発とデプロイから監視、継続的な改善に至る継続的な AI 導入をサポートするために必要な技術的およびデータ基盤を組織がどのように構築するかに焦点を当てています。
注
運用とライフサイクル管理と責任ある AI と信頼は、横断的な機能です。 より明確な成熟度評価をサポートするために、このモデルは、実際にはセキュリティ、テクノロジ、プロセス実行全体に埋め込まれているにもかかわらず、それらを個別の柱に分割します。
AI エージェントのテクノロジとデータが重要な理由
エージェントは、依存しているテクノロジとデータ基盤と同じくらい効果的です。 弱い統合、一貫性のないデータ アクセス、または脆弱なアーキテクチャでは、エージェントが実行できる機能が制限され、システム間で確実に動作できなくなります。
効果的に運用するには、エージェントが確実に次の操作を行う必要があります。
- ワークフロー コンテキスト (プロセスの状態、依存関係、ビジネス ルール) について理解します。
- 適切な時点で適切な情報を取得します。
- セキュリティで保護された監査可能な統合を使用して、システム間でアクションを実行します。
強力なテクノロジとデータ基盤がない場合:
- エージェントは、質問と回答または単一ステップのタスクに限定される場合があります。
- 各新しいエージェントは、特注のエンジニアリング作業が必要です。
- リスク、運用上のオーバーヘッド、および不整合は、ビジネス価値よりも速く成長します。
成熟した基盤が整えば、プロセス間でエージェントを再利用、作成、調整できます。 Teams は、配管を再構築するのではなく、ワークフローの設計と価値の実現に集中できます。
成熟度が高い場合の外観
成熟度が高い組織は、堅牢なエンタープライズ レベルの AI プラットフォームを使用して運用します。
特性は次のとおりです。
- 標準化されたエージェントのアーキテクチャとプラットフォーム。 エージェントは、共有参照アーキテクチャ、テンプレート、およびパターンを使用して、承認されたプラットフォーム上に構築されます。
- マネージドで自動化された開発ライフサイクル。 開発、テスト、運用環境の分離、ソース管理、CI/CD、承認、ロールバックは、すべての運用エージェントの標準です。
- セキュリティで保護された管理されたデータと統合アクセス。 エージェントは、承認されたコネクタ、マネージド ID、および管理されたデータ ソースを使用して、シャドウ アクセスと資格情報のスプロールを排除します。
- システムと統合の明示的なインベントリ。 システム、API、およびツール エージェントが対話する機能は、インベントリされ、所有され、共有アーキテクチャ資産として扱われます。
- 再利用可能なコンポーネント。 一般的なアクション、ワークフロー、および統合は 1 回ビルドされ、複数ステップのシステム間実行を可能にするために再利用されます。
- 組み込みの可観測性と評価。 使用状況、品質、安全性、およびパフォーマンスは自動的にキャプチャされ、継続的にレビューされます。
成熟度が高い場合は、新しいエージェント パターン (マルチエージェント オーケストレーションなど) が出現するにつれてアーキテクチャ標準を更新します。 フェデレーション チームは、ガードレールが設計によって埋め込まれているため、中心的なボトルネックなしでエージェントを迅速に構築してデプロイします。
成熟度テーブルを読み取る方法
次の表は、テクノロジとデータの機能が 5 つの成熟度レベルでどのように進化するかを示しています。
レベルごとに、次のことに注意してください。
- テクノロジとデータの状態: 観測可能な技術的特性。
- 進む機会:次のステージを可能にする実用的な焦点領域。
組織は、プラットフォームまたはドメイン間で異なるレベルで動作する場合があります。 テーブルを使用して、主要なパターンを特定し、スケーリングの制約を削除する機能強化に優先順位を付けます。
テクノロジとデータの成熟度
| レベル | テクノロジとデータの状態 | 進展の機会 |
|---|---|---|
| 100: 初期 |
|
|
| 200: 反復可能 |
|
|
| 300: 定義 |
|
|
| 400: 対応 |
|
|
| 500: 効率的 |
|
|
一般的なアンチパターン
これらの兆候を見て、テクノロジとデータ基盤によって AI エージェントの導入が制限される可能性があります。
レベル 100 – 初期: "デモ駆動実験"
- Teams は、実際のデータやアクションの統合なしで、プロンプトでエージェントを完全に構築します。 このアプローチでは、実際のワークフローやエッジ ケースでは生き残れない印象的なデモが作成されます。
- Teams は、適切なコネクタとガバナンスを無視して「とにかく動かす」ことにより、セキュリティ、コンプライアンス、信頼性のリスクを招いています。
- エージェントは、個人アカウントから実行するか、明確な所有者、ライフサイクル、または運用環境へのパスを持たないテナントをテストします。
- Teams は、ALM、テスト、ロールバックの計画なしで、試験的なコードまたは構成を運用環境に直接昇格させます。
レベル 200 – 反復可能: "ヒーロー エンジニアリング"
- Teams は独立して同じシステムにコネクタを再実装し、重複や不整合が発生します。
- システムの実際の動作を理解している個人はごくわずかであり、ドキュメントはスパースまたは古くなっています。
- 一部のエージェントには、開発、テスト、および運用環境があります。 他の人はそうではありません。 運用環境への昇格は手動で行われ、エラーが発生しやすくなります。
- 進行状況は、再利用可能なパターンや共有サービスではなく、特定のエンジニアによって異なります。
- Teams はいくつかのデータ依存関係を理解しますが、エンドツーエンドの実行を有効にするには十分ではありません。
レベル 300 – 定義: "有効化を超えるプロセス"
- 多くのアーキテクチャ要件が単純なエージェントに適用され、配信が遅くなり、チームがストレスを感じる。
- 参照アーキテクチャと標準は存在しますが、テンプレートやツールには埋め込まれません。
- 設計パターンはパイロットで機能しますが、大規模、複数のドメイン、または負荷がかかっている場合には十分に検証されていません。
- 小さなグループが、スループットを制限し、フラストレーションを引き起こし、チームが離脱するすべての決定を行います。
レベル 400 – 対応: "安定しているが遅い"
- プラットフォームは堅牢ですが、エージェントをビルドまたはデプロイできるのは少数のチームだけです。
- ダッシュボードは存在しますが、分析情報は優先順位付け、改善、提供終了の決定を促進しません。
- データが安全に実行できることを示していても、チームはエージェントを厳しく制限します。
- 新しいパターンや機能を有効にするのではなく、既存のエージェントをチューニングすることに重点を置きます。
レベル 500 – 効率的: "自己満足による成熟"
- チームは、エージェント パターンが急速に進化しているにもかかわらず、プラットフォームと標準を完全と見なします。
- ガードレールは存在しますが、更新されないため、時間の経過に伴う相違と不整合につながります。
- Teams は、マルチエージェント オーケストレーション、より高い自律性、または新しい実行パターンを "将来の作業" として無視します。
- エージェントの能力が高くなるにつれて、チームは同じペースでコントロールと評価を更新しません。
この柱を実際に使用する
テクノロジとデータは、実現可能です。
導入が成熟すると、そのシステムやプロセスの効果がより明確になってきます。
- 技術的な厳しさは、チームを遅くするのではなく、摩擦を減らす必要があります。
- 標準では、安全な実験と再利用を促進する必要があります。
- プラットフォーム テレメトリは、ガバナンス、運用、価値の実現を通知する必要があります。
強力なテクノロジとデータ基盤により、信頼性、セキュリティ、制御によるイノベーションがサポートされるため、組織は AI エージェントを自信を持ってスケーリングできます。
次のステップ
次に、組織の準備と文化が、エージェント優先の持続的な働き方をサポートするために、人、役割、インセンティブをどのように可能にするかを調べます。