大規模言語モデル（LLM）を意思決定エンジンとして活用し、所定の目標達成に必要なタスクを自律的に計画、実行するソフトウェアシステムであるAIエージェントの能力と普及は、企業のワークフローに急速な変革を引き起こしています。そのトランスフォーメーションのスピードは、エージェント型AIの連携に特有の要件を反映させるために、従来のITインフラを適応させる多くの組織の能力を上回り、その結果、断片化したエコシステムが生み出されています。ADLCは、さまざまなツール、プラットフォーム、ベンダー、エンタープライズ環境にわたって信頼性の高いエージェント型システムを促進するために、共通の仕様と共有プラクティスを導入しています。
今日の標準的なITプロセスの多くは、従来のソフトウェア開発のコンテキストの中で進化してきたものであり、静的で確実性のあるシステムという前提に合わせて調整されています。こうしたプロセスは、エージェントの行動を駆動するLLMの動的で確率的な性質には不適合であることが多くあります。これらが「AIエージェント」と呼ばれるのは、タスクの実行方法を決定するための自律性（エージェンシー）を文字通り備えているためです。この移行を考慮した共有の規範や仕様は、関連するリスクを大幅に軽減し、責任あるエージェント型AIの導入を加速させることができます。
エージェント型AIを持続的かつ効果的に拡張するには、AIエージェントは、さまざまなモデル、プラットフォーム、ベンダー、業界エコシステムにわたって予測可能な方法で連携する必要があります。現在、 AIエージェントを構築するためのプラットフォームのほぼすべてが、エージェント定義のための独自のフォーマット、ツールおよび関数呼び出しスキーマ、メモリーおよび状態管理モデル、テスト一式、導入プロトコル、およびバージョン管理システムを備えています。この断片化は相互運用性を妨げ、切り替えコストを増加させ、ベンダー・ロックインを増やします。最近の研究によると、AIエージェント・ベンダー・エコシステムをナビゲートするビジネスおよび技術リーダーにとって、これはセキュリティーに次いで主要な懸念事項となっています。1 運用面では、断片化により、移転可能なスキルやワークフローなどの可能性も低減します。
標準化された規範やプラクティスはこれらの非効率性を緩和できますが、組織にとっては、開発者の確立された傾向や好みに逆らうのではなく、それに沿って機能する構造的なプロトコルを受け入れ、強制することが重要です。したがって、ADLCは、新たな開発者のプラクティスをベスト・イン・クラスのエージェント体験へと変換することを目指しています。
ADLCは、コアとなるDevSecOpsの原則を統合し、AIエージェント開発を相互に連結させ、相互に大きく依存する一連のフェーズにマッピングします。各フェーズの目的と実践、およびそれらの相互関係については、この記事の後半で詳述します。詳細、提案事項、および仕様については、IBMのADLCガイドに記載されています。
IBMニュースレター
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。
従来のソフトウェア開発ライフサイクル（SDLC）における標準的な前提やベスト・プラクティスのいくつかは、AIエージェントの構築には適していません。エンタープライズAIエージェントの取り組みを成功させるには、組織は従来のソフトウェアとエージェント型システムの根本的な違いを理解し、考慮に入れる必要があります。
決定論と確率論の違い：従来のソフトウェアは、明示的で決定論的な指示（命令型コードの形式）を与えられ、暗黙のうちに示されている最終目標を追求します。一方、AIエージェントは、明示的な最終目標と行動上のガードレールが設けられツール、データ・ソース、自律的な推論を用いて、それを達成するための最善の方法を推論するよう求められます。エージェント型システムでは、同じインプットを2回入力すると、2つの異なるアウトプットが生成される可能性があります。
静的対適応型：従来のソフトウェアには固定された機能があり、その行動を制御するコードが能動的に変更された場合にのみ行動が変化します。エージェントの行動は、環境からのフィードバックに基づいて進化する可能性があります。
コード駆動型と結果駆動の違い：従来のソフトウェアの決定論的で直線的な性質により、開発者は安定した（比較的客観的な）コード品質の尺度でプログラムの成功を予測できます。エージェント型AIの確率論的な性質により、最適な実装であってもエージェントの性能が最適とは限らず、雑で最適ではないプロンプトであっても、正確な出力が得られることがあります。したがって、エージェント型システムの評価には、ビジネス成果とエージェントの行動を長期にわたって体系的に測定する必要があります。
おそらく最も重要な点は、エージェント型システムと従来のソフトウェアでは、故障モードが大きく異なることです。
従来のソフトウェアが失敗するのは、ソフトウェアのコードの厳密な命令を「壊す」ロジック・エラーやエッジ・ケースが原因です。こうした失敗は一般に明らかで、ソフトウェアがクラッシュしたり、無意味な出力を生成したりします。従来のソフトウェアは決定論的であるため、あらゆる障害はコードの特定の欠陥に遡って特定できます（そしてそれをデバッグできます）。
一方、エージェント型は通常、ハルシネーション（幻覚）や整合性の問題によって機能しなくなります。AIエージェントは、従来のソフトウェアのような厳密なルールベースのロジックを実行するのではなく、（システム・プロンプト、ガードレール、コンテキストを通じて提供される）意図を確率論的に解釈することによって動作します。エージェントは、制約に違反したり、自信を持って誤った結果を出したりすることで、表面上は問題を「解決」する場合があります。このような障害は見逃しやすくなります。妥当ではあるものの、誤ったアウトプットは、システム・クラッシュよりも発見が困難です。また、原因の特定も困難です。複雑な複数ステップのエージェント型ワークフロー全体の失敗は、一つの確率論的ツール呼び出しの誤った結果に起因する可能性があり、問題となるエラーはその後の評価では再現されない可能性があります。
したがって、ADLCはオブザーバビリティー、封じ込め、および継続的な評価を各フェーズに組み込みます。エージェント型開発は、リアル・ワールドのシナリオにおける徹底的なテストの必要性と、リアル・ワールドのリスクを封じ込める必要性とのバランスを効率的に取る必要があります。
エージェント開発ライフサイクル（ADLC）は、AIエージェントの構築、導入、最適化、管理のプロセスを明確なフェーズにマッピングし、いくつかのフェーズを組み合わせて反復ループを形成します。
計画：関係する利害関係者全員と協力して、ユースケース、目標、成功メトリクス、理想的なビジネス成果について調整します（評価フレームワークを伝えるため）。エージェントの望ましい動作と標準操作手順を自然言語で確立し、文書化します。
コードとビルド：エージェントの開発（これには、とりわけモデル選択、プロンプト・デザイン、およびオーケストレーションが伴う）。ツール、データベース、APIなどの関連する外部サービスを特定し、モデル・コンテキスト・プロトコル（MCP）を使用してそれらをエンタープライズ・レイヤーに統合します。きめ細かなバージョン管理、サンドボックス、およびゲートウェイ・パターンの適用。
テストとリリース：事前に定められたベンチマークを基に構造化された評価を実行し、ポリシー・チェックを強制し、セキュリティー・テストやレッド・チーミングを実施し、エージェントがガバナンスされたカタログに属していることを認証します。必要に応じて、コードと構築およびテストとリリースをループで反復します。
導入：認定が完了したら、エージェントを本番環境に移行し、段階的に導入してリスクを管理します。効果的なガバナンスとポリシーの適用を可能にするゲートウェイ・パターンを採用します。サンドボックス化、バージョン管理、ロールバック戦略、セキュリティー対策、性能制限などを通じて、ランタイム時のガバナンスを確保します。
運用：展開されたエージェントを継続的に観察および最適化し、リアルタイムのメトリクス（精度、レイテンシー、コスト、ユーザー満足度など）を追跡し、モデルのドリフトや性能の低下に常に注意を払います。これらのフィードバック・ループを使用して、性能とセキュリティーのためにプロンプト、ツール、モデル、およびメモリーのポリシーを最適化し、必要に応じて導入-運用ループを繰り返します。
監視：システムが完全に検証され、最適化された後は、公正性、透明性、規制遵守のために継続的に監視し、監査を実施します。オブザーバビリティーと再現性を促進するために、適切に管理されたエージェントとツールのカタログを維持します。
これらのフェーズと、それらが対処するように設計されている優先事項（それぞれの詳細については以降のセクションで説明します）を遵守することで、組織はエージェントの信頼性、監査可能性、およびビジネス価値との整合性を維持し、安全かつ自信を持ってエージェントを拡張できます。
エージェント開発プロセスは、ユースケースの整合から始まり、そこから他のすべての計画上の考慮事項が展開されます。
エージェントが達成すべき具体的なビジネス成果によって、エージェントの性能評価に使用する主要業績評価指標（KPI）やその他の成功メトリクスが決まります。カスタマー・サポートの自動化は、主にエンド・ユーザーの満足度とコスト削減の観点から評価されるのに対し、コーディングエージェントは、レイテンシーとコード品質で評価されるかもしれません。計算方法が異なれば、成功シグナルや運用上のインセンティブが異なる可能性があるため、これらのメトリクスの特定の数式を選択することは、それ自体が極めて重要なアーキテクチャー上の決定です。
エージェントが駆動する特定のビジネス成果をもたらすには、特定のプロセス、タスク、およびサブタスクをエージェントによって自動化する必要があり、それらのタスクの多くでは、AIエージェントに特定のツール、データ・セット、ナレッジ・ベース、およびAPIへのアクセスをプロビジョニングすることが必要になります。コードとビルドのフェーズに先立って、必要なすべてのリソースのリストをコンパイル（および調達）することは、効率的かつ効果的な開発プロセスにとって不可欠です。
とはいえ、計画フェーズで行うべき最も重要な決定は、そもそもAIエージェントを構築すべきかどうかということです。
IBMは、お客様固有のビジネス・ニーズに対応できる最もシンプルなソリューションを見つけることを推奨します。従来型の自動化、検索システム、あるいはよく考えられた指示によって解決できる問題であれば、エージェント型AIは不必要な複雑さを招く可能性があります。例えば、顧客からのeメールへの返信を自動化するシステムにはAIエージェントが必要となりますが、eメールを分類するシステムに必要なのはLLMと適切に設計された指示だけです。
ユースケースにおいて、エージェント型AIがよりシンプルなソリューションよりも優れた性能を発揮できると仮定し、それによるコストやレイテンシーの増加が正当化される場合、企業環境におけるエージェント型AIの理想的な実装には通常、以下のことが必要になります。
明確に定義された製品範囲。広範なルールベースのアプローチでは適切に解決できない、判断力や多段階の推論を必要とする特定のビジネス上の問題を優先的に解決します。文脈に応じた判断、複数ステップの推論、大規模に複雑な意思決定を必要とする問題は、エージェント型AIの理想的な候補です。
明確なメトリクス。エージェント型AIは、成功を客観的かつ定量的に評価でき、基準を遵守させることができるシナリオにおいて、真価を発揮します。これは、ビジネスの観点から必要とされる確固たる根拠だけでなく、運用面から必要とされる最適化目標も提供します。
管理可能な複雑さ。エージェント型AIの確率的な性質は、マルチエージェント・システムが、単一のステップの失敗が広範な影響を及ぼす可能性があるスキャフォールディング・リスクを伴うことを意味します。エージェント型システムの理論的なメリットは、運用の複雑さを明確に上回る必要があります。
エージェント型AIのエンタープライズ・デプロイメントを徹底的に分析した結果、一貫した価値と管理可能なリスクをもたらす特定のパターン（文書中心のプロセス、顧客サポート（または顧客サービス）、および文書化可能なナレッジ・ワーク）が明らかになりました。これらは、開始するのに理想的な領域です。
利害関係者全員が目標、要件、制約、測定基準に同意したら、チームはAIエージェントを実際に構築するプロセスに動き、プロンプト、メモリー戦略、オーケストレーション・ロジック、評価フレームワークを実装します。
エージェントは企業システム、API、外部ツールやナレッジ・ベースと連携する必要があります。これらの連携は、セキュリティーとテレメトリーを念頭に置いて設計する必要があります。主要なワークフローの段階では、オブザーバビリティー・フック（瞬時に運用されるデータや測定値を自動的に取得するコード）を挿入して、エージェントの推論トレース、ツールの呼び出し、アウトプットなどのエージェントのトランスクリプトを記録する必要があります。
各開発段階において、チームは個々のエージェントのバリアントと、（関連する場合は）マルチエージェント・システム内でそれらの作業を調整するオーケストレーション・ロジックの両方に対して、厳格なバージョン管理ポリシーを実装する必要があります。
どのLLMがAIエージェントを強化するかを選択することは、アーキテクチャーに関する最も重要な決定の一つです。すべてのタスクや役割に単一のモデルを使用することは、性能面から見て最適な構成であることはめったなく、たとえ最適であったとしても、そのわずかな性能の向上には、コスト効率やレイテンシー、あるいはその両方の面でトレードオフが伴います。
開発者は多様なモデルのポートフォリオから活用すべきです。複雑な計画にはフロンティア推論モデル 、専門的なタスクにはドメイン固有のモデル（モデル提供者から直接取得するか、組織のファイン・チューニングを通じて得られるもの）、よりシンプルで大量のタスクにはコストと遅延を最小限に抑えるための小規模モデルです。
可能な限り、再現性とオープンス・タンダードを優先してください。例えば、ツールやリソースにはMCP、オブザーバビリティーにはOpenTelemetry、プロンプトには再利用可能なスキーマなどです。同様に、ストレージと検索、ツールへのアクセス、タスクの委任についても、一貫したパターンを採用すべきです。
現実世界のリスクにさらされるエンタープライズ・システムの場合、エージェント型AIセキュリティーは、事後的に組み込むのではなく、セキュリティー・バイ・デザイン原則を使用して各開発ステップに直接織り込む必要があります。
すべてのAIエージェントには、エージェントによって実行されるすべてのアクションを記録、監査、および適切に帰属できるように、一意の識別タグを発行する必要があります。これにより、セキュリティー問題の発生源を確実に突き止められるようになるだけでなく、エージェント型AIの導入が成熟するにつれて進化し続ける規制フレームワークへのコンプライアンスも容易になります。
サンドボックスやその他の封じ込めはリスクを抑制するために不可欠です。エージェントの実行環境、ネットワーク・アクセス、ファイルシステムへのアクセスは、常に最小権限の原則に基づいて動作する必要があります。エージェント型システムの各構成要素には、指定されたタスクを実行するために必要な最小限の権限を与える必要があります。
エージェントのプロトタイプをテストして、本番環境へのリリースの準備が整っていることを確認するには、従来のソフトウェア設計ライフサイクルの単体テストや静的分析以上のものが必要です。また、現実世界のシナリオに対する広範な行動検証または忠実度の高いシミュレーションも必要になります。エージェント型システムの確率論的な性質を考慮すると、これらのテスト・シナリオのサンプル・サイズは、潜在的に発生するすべてのエージェントの挙動が観察され評価されるという合理的な確信を得るために、十分に大きく、かつ多様でなければなりません。
AIエージェントは、望ましい動作を正確に反映し、強制する、事前定義されたベンチマークとポリシー・チェックに基づいてテストされるべきです。そのためには、インプットの種類や状況ごとにエージェントがたどるべき軌跡を示す、地上検証データのデータ・セットの収集または作成が必要になるかもしれません。LLM審判と人間参加型のレビューの両方を用い、前者が実現する規模と後者がもたらす信頼性のバランスを取る必要があります。
初期導入の前後では、必要な規模でテストと評価を実行し、評価を自動的に実行し、ツールの信頼性をテストし、安全ガードレールを適用するために、堅牢な継続的統合/継続的デリバリー（CI/CD）パイプラインが不可欠です。テスト中は、継続的統合（CI）システムが、構成モデルや指示が更新されても、エージェントの推論論理が壊れないことを保証するのに役立ちます。すでに使用しているLLMの最新モデル・バージョンに切り替えても、動的な環境では予測できない影響が生じる可能性があります。
エージェント型システムの成功には、ADLC（アプリケーション開発ライフサイクル）の構築後のあらゆる段階におけるAIエージェントの継続的な評価が不可欠です。ビルドおよびCI中のオフライン評価は、全体的なエージェントの動作と成果のベンチマークに役立ちます。ループ内評価は、エージェントの個々の決定をガイドするためにランタイム時に呼び出されます。たとえば、エージェント型RAGアプリケーションでは、ワークフローはコンテキスト関連性スコアの計算を強制し、取得したソースを使用してアウトプットを生成する必要があるかどうかを決定できます。
企業のエージェント評価フレームワークは、以下を含む複数種類のメトリクスで構成する必要があります。
タスク成功率（％）、正確性、ツール呼び出し成功率などの品質メトリクス
ポリシー違反や機密データ漏洩率などの安全性メトリクス
レイテンシー、トークン消費量、タスクあたりのコストなどの運用メトリクス
満足度スコアや成果あたりのコストなどのビジネス・メトリクス
レッド・チームは、敵対的な脆弱性や潜在的なアライメント失敗を先見的に特定します。プロンプト・インジェクション攻撃やジェイルブレイクの試みといった敵対的な条件をシミュレートし、標準的な行動テストでは見落としがちなシナリオで安全性の制約をテストします。
徹底的なテスト、最適化、検証を経た後、AIエージェントは企業環境に安全に導入されます。導入フェーズは、いわゆる大きな赤い「DEPLOY」ボタンを押すような単一の動作ではなく、計画的、戦略的に段階を踏んだ活性化として捉える必要があります。ADLCは、サンドボックス、バージョン管理、ロールバック戦略、フェイルセーフを通じて、ランタイム時のシステムの安全性を確保します。
AIエージェントのロールアウトは、リスクを管理するために段階的に実行する必要があります。ユーザーの利用トラフィック・パターンにどれが最も適しているかを判断するために、ブルー・グリーン、ローリング、またはカナリア・デプロイメントなどのさまざまなロールアウト戦略を検討してください。実際の現実世界のエンタープライズ環境では、安定性が最優先事項であり続ける必要があります。ロールアウトを慎重に複数のステージに分割することで、重要なアップデートに対するシステムのレジリエンスを検証できます。
サンドボックスとは、エージェントとそのツールを、計算、ストレージ、ネットワーク、システムAPIへの最小特権アクセスを強制する制約された実行環境内で実行することで、エージェントとそのツールの範囲と能力を厳密に制限することです。エージェントが障害を起こしたり誤動作をしたりした場合でも、適切なサンドボックスにより、潜在的な問題の範囲と規模が最小限に抑えられます。これは、1つのエージェントのツールの誤用、コード生成、データ変換が、コードベース、データ整合性、顧客、他のエージェント全体に影響を及ぼしかねないあらゆるシナリオで重要な実践です。
サンドボックスの一般的な実装戦略は次のとおりです。
軽量仮想化
コンテナ・セキュリティー・プロファイル
ネットワーク制御 （通常はMCPゲートウェイ経由）
ファイルシステム・アクセス・ポリシー
ゲートウェイ・レベルのポリシーの適用
AIエージェントが完全かつ正常に導入された後も、ADLCは継続します。コードとビルド・フェーズとテストとリリース・フェーズで形成される反復ループと同様に、導入フェーズと運用フェーズは、継続的なフィードバック・ループの 2 つの部分として捉える必要があります。最初のビルド/テスト・ループの最終目標は、エージェントが目的のビジネス成果を達成するために必要な最小の性能しきい値を満たすことですが、導入/運用ループの目標は最適化です。
導入後、エージェントの性能が実環境において信頼性が高く、効果的で安全であることを保証するためには、継続的な運用監視が必要です。統一されたダッシュボードにコンパイルされ、すぐにアクセスできるリアルタイムのメトリクスは、ドリフトや性能の低下がないか、積極的に監視すべきです。業務効率であれエンド・ユーザーからのフィードバックであれ、顕著な低下があれば積極的に対処すべきです。これらの新たな問題に対する解決策として生じる変更は、徹底的にテストし、段階的に導入する必要があります。
フル・スタックのオブザーバビリティーは、最適なパフォーマンス、安全性、および信頼性を達成するだけでなく、長期にわたってそれを維持するエージェント型システムにとって極めて重要です。
エージェントの実装が実際の運用環境で完全に検証および最適化されたら、全体的な性能に加えて、公平性、透明性、セキュリティー・リスク、規制遵守についての継続的な監査を実施します。
業界標準や法的要件は進化し続けており、その両方に積極的に対応できない場合、規制上の結果、競争上の不利益、またはその両方を招く可能性があります。モデルのドリフトは避けられない現象であり、プロアクティブなアプローチで対処するのが最善です。ビジネス・ニーズは変化するため、それらのニーズを満たすために導入されているエージェント型システムもそれに応じて変更する必要があります。
現在および将来のニーズに対応するため、企業は以下の点を明記した、明確に整理されたエージェントおよびツールのカタログを作成すべきす。
所有権：説明責任と問題のエスカレーションを促進するため
バージョン：規律あるチェンジ・マネジメントの実践のため
リスク体制：意思決定への情報提供のため
すべての関連環境：徹底的な運用監視を維持するため
監査可能性：証拠収集、評価、承認、およびレッド・チーミングの迅速化
生成AIを使用してワークフローとプロセスを自動化する強力なAIアシスタントとエージェントを構築、デプロイ、管理しましょう。
信頼できるAIソリューションでビジネスの未来を構築します。
IBMコンサルティングAIサービスは、企業がAIをトランスフォーメーションに活用する方法を再考するのに役立ちます。