1. はじめに
「デモは動くのに、本番運用に進めない」は、AI エージェント開発で典型的な悩みです。Google ADK も "Build production agents, not prototypes." と掲げています[^16]。本番では応答品質のドリフト、ツール仕様の変更、モデルや API の非推奨にも継続して対処しなければなりません[^10][^15]。
Microsoft・Google・LangChain（LangSmith）は、エージェント開発を一度きりの実装ではなく、企画から廃止まで続くライフサイクルとして整理しています[^1][^16][^18]。本記事の目的は、その共通構造を特定製品に依存しない 8 フェーズとして示し、実装者・アーキテクト・プロダクトマネージャーが現在地と不足工程を確認できるようにすることです。
個別実装は Microsoft Agent Framework の徹底解説（Part 1）、横断的な運用ガバナンスは AI エージェント管理の 12 領域を扱う記事 を参照してください。
2. AI エージェントのライフサイクル全体像
2.1 8 フェーズの定義
以下は複数ベンダーの資料を対応づけた本記事独自の整理です。統一規格ではありませんが、主要な工程を一つの時間軸で確認できます。
| # | フェーズ | このフェーズで問うこと | 主な成果物 |
|---|---|---|---|
| 1 | 企画・要件定義 | そもそもエージェントが必要か？成功指標は何か？ | ビジネス要件、成功指標（KPI）、投資判断 |
| 2 | 設計 | ワークフローで十分か、自律エージェントが必要か？ | アーキテクチャ設計書、ツール・メモリ・オーケストレーション設計 |
| 3 | 実装 | どのフレームワーク・SDK で組むか？ | エージェントコード、バージョン管理された設定 |
| 4 | 評価（Evaluation） | 期待どおりに動くか？安全か？ | 評価データセット、評価スコア、品質ゲート |
| 5 | デプロイ | 安全に段階的に出せるか？ | 段階的ロールアウト計画、ID・権限設定 |
| 6 | 運用・監視（Observability/AgentOps） | 本番で今何が起きているか？ | トレース、ダッシュボード、アラート |
| 7 | 継続的改善 | どう良くしていくか？ | 改善済みプロンプト・スキル、A/B 結果 |
| 8 | 廃止・移行（Retirement/Deprecation） | いつ・どう畳むか、何に載せ替えるか？ | 退役計画、移行ガイド、監査ログの保管 |
図 1 のとおり、継続的改善は設計・実装へ、運用中のドリフトは評価へ、廃止・移行は次の企画へ戻ります。ライフサイクルは一直線ではなく、複数のフィードバックループを持つ循環構造です。
図1: AI エージェント開発ライフサイクル全体図（8 フェーズと主要フィードバックループ）
2.2 ベンダー横断で見る共通構造
各社の段階名を対応づけると次のようになります。たとえば Google は開発フレームワーク ADK と本番基盤 Gemini Enterprise Agent Platform を分け、設計・実装から運用・改善までをカバーしています[^16][^17]。表内の名称は一次情報、対応関係は本記事の整理です。
| 本記事のフェーズ | Microsoft CAF（AI agent adoption）[^1] | Google（ADK / Gemini Enterprise Agent Platform）[^16][^17] | LangSmith（Evaluation lifecycle）[^18] | Azure Well-Architected GenAIOps[^9] |
|---|---|---|---|---|
| 企画・要件定義 | Plan for agents（business plan） | — | — | — |
| 設計 | Plan for agents（technology plan） | Studio | Development | — |
| 実装 | Build agents | Studio → Build | Development | GenAIOps（プロンプト実装） |
| 評価 | Build agents（observability） | Evaluation Service | Offline evaluation | Evaluation and refinement |
| デプロイ | Manage agents（integrate） | Scale（Agent Runtime デプロイ） | Deployment | Deployment |
| 運用・監視 | Manage agents（operate） | Scale（Trace/Logging/Metrics） | Online evaluation | Monitoring |
| 継続的改善 | Manage agents（operate 内の改善サイクル） | Optimize | Continuous improvement | Continuous evolution |
| 廃止・移行 | Manage agents（asset lifecycle management） | Govern（Agent Registry） | — | Model maintenance |
3. 企画・要件定義フェーズ
Microsoft Cloud Adoption Framework は、作り始める前に エージェントを使わない選択肢 を検討するよう促しています[^2]。
- 手順が固定・予測可能なタスク: 通常のコードや非生成 AI モデルの方が高速・安価・確実。
- 静的な知識検索が目的: マルチステップ推論やツール呼び出しが不要なら、フルエージェントではなく古典的な RAG で十分。
必要な場合も、SaaS 型で満たせるかを先に調べ、難しいときに PaaS や GPU/コンテナでの構築へ進む順序が推奨されています[^3]。同時に、タスク完了率や人手介入率など、評価で検証できる成功指標を仮決めします。Anthropic の成果報酬型サポート事例も、測定可能な基準を先に置く重要性を示しています[^12]。
組織体制は AI エージェント管理 12 領域の記事、実装方式の比較は Agent Builder vs Copilot Studio vs Foundry を参照してください。
4. 設計フェーズ
4.1 ワークフローか、自律エージェントか
Anthropic は「まず最もシンプルな解決策を探し、複雑性は効果が実証されたときだけ足す」ことを設計原則として掲げています[^12]。同社はエージェント的なシステムを「ワークフロー（あらかじめ定義されたコードパスで LLM とツールを組む）」と「エージェント（LLM が自らの処理とツール利用を動的に制御する）」に区別し、次の代表的なパターンを整理しています[^12]。
| パターン | 概要 | 向いている場面 |
|---|---|---|
| Prompt chaining | タスクを直列のステップに分解し、途中に検証ゲートを挟む | タスクを固定ステップへきれいに分解できる場合 |
| Routing | 入力を分類し、専門化した後続処理に振り分ける | 入力カテゴリごとに最適な対応が大きく異なる場合 |
| Parallelization | 複数の LLM 呼び出しを並列実行し結果を集約する（分割 または 多数決） | 高速化したい場合、複数視点の合議が必要な場合 |
| Orchestrator-workers | 中心の LLM がタスクを分解し、ワーカー LLM に委譲・結果を統合する | 必要なサブタスクを事前に予測できない場合 |
| Evaluator-optimizer | 生成担当と評価担当の LLM がループして改善する | 明確な評価基準があり、反復改善に価値がある場合 |
| 自律エージェント | LLM がツール利用とその後の計画を継続的に自ら決定する | 手順を事前に固定できないオープンエンドな課題 |
自律性を上げるほどコストとエラー経路も増えるため、サンドボックスでのテストとガードレールを併用します[^12]。
4.2 ツール・オーケストレーション・メモリの設計
ツールはエージェント向けの UI と捉え、入力制約・エラー・戻り値を明確にします。Anthropic は、ファイル操作を絶対パス必須に変えて誤操作を防いだ例を紹介しています[^12]。オーケストレーション層では、必要な制御方式と運用機能からフレームワークを選びます。
- OpenAI Agents SDK: エージェントループ、ハンドオフ、ガードレール、セッション、トレーシングを備えます[^13]。
- Google ADK: LLM エージェント、グラフベースのワークフロー、マルチエージェント協調を扱います[^16]。
- Microsoft Agent Framework: 詳細設計・実装パターンは Part 1・Part 2 で解説済みのため、本記事では割愛します。
メモリは、OpenAI Sessions や Google Memory Bank のように、短期の会話状態と長期記憶を分離します[^13][^17]。モデル選定は Foundry Models の種類と機能ガイド を参照してください。
4.3 セキュリティ・バイ・デザイン
Responsible AI の「Discover → Protect → Govern」を全フェーズに置き、デプロイ前にはジェイルブレイク耐性も評価します[^6]。ガードレールは入力、ツール呼び出し、ツール応答、最終出力の複数箇所に配置します[^4]。権限設計や Prompt Injection の脅威モデルは OWASP LLM Top 10 とエージェント脅威の記事 を参照してください。
5. 実装フェーズ
OpenAI Agents SDK や Google ADK は少ないコードで開始できますが[^13][^16]、本番ではコードだけでなく、プロンプト・ツール定義・モデル設定も同じ単位で版管理します。Microsoft Foundry のように保存ごとに不変バージョンを作り、比較とロールバックができる構成が有効です[^7]。
シークレットはマネージドなストアから参照し、エージェント ID には最小権限を割り当てます[^7]。コンテナベースの実装例は Microsoft Foundry Hosted Agent の手順ガイド を参照してください。
6. 評価（Evaluation）フェーズ
6.1 オフライン評価とオンライン評価
LangSmith（LangChain の評価・観測プラットフォーム）のドキュメントは、評価を「オフライン評価」と「オンライン評価」の 2 種類に整理しています[^18]。
| 観点 | オフライン評価 | オンライン評価 |
|---|---|---|
| 対象 | 参照出力つきのデータセット（Examples） | 本番トラフィックの実行ログ（Runs/Threads） |
| 主な目的 | ベンチマーク比較・回帰テスト・単体テスト | リアルタイム監視・異常検知・本番フィードバック収集 |
| 実施時期 | デプロイ前（開発中） | デプロイ後（本番運用中） |
| 正解データ | あり（期待される出力と比較） | なし（参照フリーな品質判定が中心） |
Microsoft Foundry も「ベースモデル選定 → デプロイ前評価 → デプロイ後モニタリング」と整理しており、この流れはベンダーを問わず共通します[^8]。
6.2 評価手法の使い分け
評価手法は人手、決定的なコード検証、LLM-as-judge、ペアワイズ比較を使い分けます[^18]。LLM-as-judge には位置バイアスなどがあるため、評価基準とアンカーを明文化します。詳細は エージェント品質スコアリングルーブリック を参照してください。
Microsoft Foundry には一般品質（一貫性・流暢性）、RAG 特化（グラウンディング・関連性）、安全性、エージェント特化（ツール呼び出し精度・タスク完了度）といった組み込み評価器が用意されています[^8]。
OpenAI は Evals プラットフォームを 2026-11-30 に終了予定とし、トレースグレーディングから始めて、再現性が必要になればデータセット評価へ進む手順を案内しています[^14][^15]。Google ADK も Criteria、User Simulation、Environment Simulation、Custom Metrics に対応します[^16]。
図2: 評価（Evaluation）フェーズにおけるオフライン評価とオンライン評価のフィードバックループ
7. デプロイフェーズ
Azure Well-Architected Framework の GenAIOps ガイダンスは、デプロイを「本番投入前の最後の関門」と位置づけ、カナリアリリースやブルーグリーンデプロイのような 段階的な露出（progressive exposure） を基本パターンとして推奨しています[^9]。
Microsoft Foundry では、エージェントを「エージェントアプリケーション」として発行すると安定したエンドポイントが得られますが、見落としがちな注意点があります。プロジェクトの ID に割り当てた権限は、発行後のエージェントアプリケーションの ID には自動的に引き継がれません。発行後に必要な権限を再割り当てする作業が必須です[^7]。
Google の Agent Runtime には、開発ニーズに応じた 5 通りのデプロイ方法が用意されており、IAM によるエージェント ID 管理や、Agent Gateway 経由でのガバナンスされたトラフィックルーティングにも対応しています[^17]。
デプロイ前チェックリストとして、以下を確認してからロールアウトすることをおすすめします。
- 評価フェーズの品質ゲートを通過しているか（6 章）
- 本番投入前にトレーシングが有効化されているか（9 章）
- エージェント ID・ツール接続の権限が「必要最小限」に再設定されているか[^7]
- バージョン管理により切り戻し（ロールバック）が可能な状態か[^7]
8. 運用・監視フェーズ（Observability / AgentOps）
Microsoft Foundry は AI オブザーバビリティを「Evaluation（継続的評価を含む）・Monitoring・Tracing」の 3 つの柱で定義しています[^8]。
- トレーシング: LLM 呼び出し・ツール呼び出し・エージェントの意思決定・サービス間の依存関係を記録します。LangChain、LangGraph、OpenAI Agents SDK、Microsoft Agent Framework など主要フレームワークに対応します[^8]。
- モニタリング: トークン消費量・レイテンシ・エラー率・品質スコアをダッシュボードで追跡し、閾値を下回った際にアラートを発報します[^8]。
- 継続的評価: 本番トラフィックを一定のサンプリングレートで継続的に評価します。既定では 1 時間あたり最大 100 回の評価実行という上限（
max_hourly_runsで変更可能）があり、有効化にはプロジェクトのマネージド ID に Foundry User ロールの割り当てが必要です[^19]。
OpenAI の Agents SDK にも、ワークフローの可視化・デバッグ・監視を行う組み込みトレーシングがあり、評価・ファインチューニング・蒸留といった他のツール群ともシームレスに連携します[^13]。本番での品質確認は、前章で触れたトレースグレーディングのワークフロー（Logs > Traces を開く → 代表的なトレースを検査 → グレーダーで採点 → プロンプト・ツール構成・ルーティング・ガードレールを改善）を反復する形が推奨されています[^14]。
Google の Agent Runtime は Cloud Trace・Cloud Logging・組み込み/カスタムメトリクスとアラートを提供し、Agent Gateway 経由でトラフィックを一元的にガバナンスできます[^17]。
エージェント特有の観測情報を統一的に扱う土台として OpenTelemetry の GenAI セマンティック規約が業界横断で採用されつつありますが、属性設計やスパン構造の詳細は AI エージェント管理 12 領域の記事「6.3 Observability」 で扱っているため、本記事では割愛します。ID・認可・コンプライアンスまで含めた AgentOps 全体のガバナンス設計についても同記事を参照してください。
9. 継続的改善フェーズ
運用フェーズで集めたトレースとフィードバックを、次の改善サイクルへつなげるのがこのフェーズの役割です。LangSmith は「本番のユーザーフィードバックや異常検知が新しいオフライン評価データセットの材料になり、それを使って修正を検証し、オンライン評価で本番改善を確認する」という反復ループを推奨しています[^18]。
自動化の面では、次のようなツールが登場しています。
- OpenAI Prompt Optimizer: 評価データセットをもとにプロンプトを自動改善します[^14]。
- Microsoft Foundry Agent Optimizer（プレビュー）: Hosted Agent の指示文を自動改善し、有用なスキルを発見します[^7]。
- Foundry のクラスター分析: 評価で失敗したケースをクラスタリングし、優先度の高い改善対象を可視化します[^8]。
版間比較の仕組みも改善サイクルを支えます。Foundry はエージェント設定・チャット出力・YAML 定義の 3 種類の版間比較を提供しており[^7]、旧来の Azure Machine Learning「Prompt flow」でも A/B デプロイによる比較機能が提供されていました。ただし Prompt flow 自体は 2027-04-20 に退役予定であり、新規開発では推奨されていない点に注意してください（詳細は次章）[^10]。
コードを再デプロイせずに振る舞いだけを更新したい場合、Microsoft Foundry の Skills のように「新バージョンを作成 → テスト → default に昇格」という中央集権的な更新の仕組みも有効な選択肢です。
自組織がどの成熟度にあるかを把握したい場合は、GenAIOps の成熟度モデル（Level 1: initial → Level 2: defined → Level 3: managed → Level 4: optimized の 4 段階）に照らして自己点検すると位置づけが明確になります[^11]。
10. 廃止・移行フェーズ（Retirement / Deprecation）
10.1 モデル・機能の非推奨（2026-07 時点の実例）
OpenAI は API のモデル非推奨について、次のような最低予告期間のルールを明文化しています[^15]。
| モデル区分 | 最低予告期間 |
|---|---|
| GA（一般提供）モデル | 6 か月以上 |
| GA モデルの特殊バリアント（chat・codex・deep research 等） | 3 か月以上 |
| プレビューモデル | 短くて 2 週間程度 |
OpenAI は deprecated、legacy、shut down を区別し、非推奨の発表時に終了日を示します[^15]。
2026-07-07 時点で実際に進行中・予定されている非推奨の代表例は次のとおりです。
| 対象 | 非推奨発表 | シャットダウン予定 | 移行先 |
|---|---|---|---|
| Assistants API | 2025-08-26 | 2026-08-26 | Responses API + Conversations API[^15] |
| Evals プラットフォーム（API・ダッシュボード） | 2026-06-03 | 2026-11-30（10-31 に読み取り専用化） | Datasets・トレースグレーディング[^14][^15] |
| Agent Builder | 2026-06-03 | 2026-11-30 | Agents SDK・ChatGPT Workspace Agents（ChatKit は継続提供）[^15] |
| Azure Machine Learning / Foundry の Prompt flow | — | 2027-04-20 | Microsoft Agent Framework[^10] |
Prompt flow はコンテナイメージのセキュリティ更新が止まっているため、新規開発には推奨されません。GenAIOps の考え方は維持しつつ、後継フレームワークへ移行します[^10]。
10.2 エージェント自体の退役
モデル単位の非推奨とは別に、エージェントという成果物そのものを退役させる意思決定も必要です。Microsoft の Cloud Adoption Framework は、これを「Asset lifecycle management」として次のように整理しています[^5]。
- デプロイされたまま使われていない「休眠エージェント」は、セキュリティリスクとクォータの浪費を生む。
- 四半期ごとの棚卸し（quarterly review）を実施し、ビジネス価値を生んでいないエージェントを退役させる。
- 個別プロジェクトごとの管理ではなく、統一されたコントロールプレーンでエージェント資産全体を可視化・管理する。
実務上のチェックリストとしては、次の流れが有効です。
- エージェント資産の棚卸し（誰が・何のために使っているか）
- 利用実績がない、または目的を終えたエージェントの特定
- 依存する統合・ワークフローへの影響確認と関係者への通知
- 認証情報・ID・権限の失効
- 監査・コンプライアンス目的でのトレースと評価履歴のアーカイブ
さらに、土台となるモデルやフレームワークを乗り換える際は、切り替え前に 6 章で構築したオフライン評価スイートを回帰テストとして再実行する ことが安全な移行の鍵になります。これにより、廃止・移行フェーズは孤立したイベントではなく、評価フェーズへとつながる一つのループとして機能します。
11. まとめ
- AI エージェント開発は「企画・要件定義 → 設計 → 実装 → 評価 → デプロイ → 運用・監視 → 継続的改善 → 廃止・移行」の 8 フェーズが循環するライフサイクルです。
- Microsoft・Google・LangChain など主要プレイヤーは用語こそ異なりますが、計画・構築・評価・運用・改善・退役という骨格において驚くほど似た構造を採用しています[^1][^9][^16][^17][^18]。
- 評価とオブザーバビリティは「本番前」「本番後」の二段構えで設計し、両者をフィードバックループでつなぐことが継続的な品質維持の要です。
- 廃止・移行は設計段階から見込んでおくべきフェーズです。モデル・API・ツールの非推奨は今この瞬間にも進行しており[^15]、評価スイートを回帰テストとして持っておくことが安全な移行を支えます。
- 自分のプロジェクトが 8 フェーズのどこに位置し、どこが手薄かを 2 章の表で棚卸ししてみてください。ガバナンス・セキュリティ・コストの詳細は AI エージェント管理 12 領域の記事 を、個別実装は本文中でリンクした各記事を参照してください。
12. 参考情報
[^1]: AI agent adoption — Microsoft Cloud Adoption Framework（参照日: 2026-07-07）
[^2]: Business plan for AI agents — Microsoft Cloud Adoption Framework（参照日: 2026-07-07）
[^3]: Technology plan for AI agents — Microsoft Cloud Adoption Framework（参照日: 2026-07-07）
[^4]: Process to build agents across your organization — Microsoft Cloud Adoption Framework（参照日: 2026-07-07）
[^5]: Manage AI agents across your organization — Microsoft Cloud Adoption Framework（参照日: 2026-07-07）
[^6]: Responsible AI for Microsoft Foundry — Microsoft Learn（参照日: 2026-07-07）
[^7]: Agent development lifecycle — Microsoft Foundry ドキュメント（参照日: 2026-07-07）
[^8]: Observability in generative AI — Microsoft Foundry ドキュメント（参照日: 2026-07-07）
[^9]: MLOps and GenAIOps for AI workloads on Azure — Azure Well-Architected Framework（参照日: 2026-07-07）
[^10]: GenAIOps with prompt flow and GitHub — Microsoft Learn（Prompt flow は 2027-04-20 に退役予定と明記、参照日: 2026-07-07）
[^11]: Advance your maturity level for Generative Artificial Intelligence Operations (GenAIOps) — Microsoft Learn（参照日: 2026-07-07）
[^12]: Building effective agents — Anthropic Engineering（2024-12-19 公開、参照日: 2026-07-07）
[^13]: OpenAI Agents SDK — OpenAI 公式ドキュメント（参照日: 2026-07-07）
[^14]: Evaluate agent workflows — OpenAI Platform ドキュメント（参照日: 2026-07-07）
[^15]: Deprecations — OpenAI Platform ドキュメント（参照日: 2026-07-07）
[^16]: ADK — Build production agents, not prototypes — Google, Agent Development Kit 公式サイト（参照日: 2026-07-07）
[^17]: Scale your agents — Google Cloud, Gemini Enterprise Agent Platform ドキュメント（参照日: 2026-07-07）
[^18]: Evaluation concepts — LangChain, LangSmith ドキュメント（参照日: 2026-07-07）
[^19]: Monitor agents with the Agent Monitoring Dashboard — Microsoft Foundry ドキュメント（参照日: 2026-07-07）
この記事の執筆にあたり、AI の支援を受けています。
