エージェント開発ライフサイクル：AI エージェントの構築、テスト、デプロイ、監視 | LangChain

誰もがエージェントをリリースしたがる。 最も優れた組織は、それを反復的かつ安全に、体系的に行う方法を確立している。彼らは早期にリリースし、実際の利用から学び、迅速に改善を重ねる。エージェントを単発のデモや孤立したプロジェクトとして扱うことはない。 むしろ、彼らは**エージェント開発ライフサイクル**を構築しており、これにより実験を反復可能なシステムへと転換することで、リリース・学習・継続的な改善における勢いを生み出している。 このライフサイクルには4つの部分がある： **ビルド → テスト → デプロイ → モニタリング** ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78da_99648614.png) この順序は意図的なものである。テストは、エージェントが本番環境に到達した後ではなく、その前に開始されるべきだ。チームはデプロイ前にエージェントをテストし、制御された方法でデプロイし、本番環境での振る舞いを監視し、そこから得た知見を次のビルドと評価サイクルへフィードバックする必要がある。 単一のエージェントであれば、このプロセスは軽量に保つことができる。しかし、多数のエージェントにわたると、それはインフラストラクチャおよびガバナンスの課題となる。チームは、コスト制御、ツールアクセスの管理、ツールの呼び出しの検査、コンテキストの再利用、そして人間が関与すべき箇所の決定などを行うための共有された方法が必要になる。 一度だけエージェントを動作させることと、反復可能なプラクティスとしてエージェントを構築することの違いは、適切な開発ライフサイクルを整備しているかどうかにかかっている。 ## ビルド ビルドフェーズでは、チームがどのようなエージェントシステムを作成するか、そしてどのレベルの抽象化を使用するかを決定する場所である。 ここには幅広いツールが存在します。コードファースト型のものもあれば、ノーコードやローコードの選択肢もあります。抽象化に焦点を当てるものもあれば、プロンプト、ツール、スキル、状態を備えたエージェントが動作する環境を提供することに注力するものもあります。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78e0_14009bc9.png) コードファーストの側では、チームはオープンソースのフレームワークやハッチ（harness）を利用することがよくあります。LangChain エコシステムにおいては、[LangChain](https://www.langchain.com/langchain)、[LangGraph](https://www.langchain.com/langgraph)、そして [Deep Agents](https://www.langchain.com/deep-agents) がこれに該当します。LangChain 以外では、CrewAI や Claude Agents SDK が例として挙げられます。 これらのツールは、スタックの異なるレイヤーで動作します。 **エージェントフレームワーク**（Agent frameworks）は主に抽象化に焦点を当てています。開発者がモデル呼び出し、ツール、プロンプト、検索、構造化された出力、そしてエージェントループを組み立てるのを支援します。LangChain や CrewAI がこのカテゴリーの例です。 **ランタイム**（Agent runtimes）は実行に焦点を当てています。状態、制御フロー、耐久性、および人間の介入を必要とするエージェントをサポートします。LangChain エコシステムにおける最も明確な例が LangGraph です。これにより、分岐、ループ、一時停止、再開、そして時間経過に伴う状態の永続化が可能となる、エージェンティックなシステムを構築する方法を提供します。 **エージェント・ハーネス**は実行に焦点を当てています。長時間実行されるタスクに必要な周囲の構造、つまりプロンプト、スキル、MCP サーバー、フック、ミドルウェア、そして場合によってはファイルシステムを提供します。Deep Agents や Claude Agent SDK はこのパターンの例です。 これらの区別が重要なのは、「エージェントを構築する」という言葉が異なる意味を持つ可能性があるからです。 単純なアプリケーションの場合、ツール呼び出しループの定義のみで済むかもしれません。より洗練されたエージェントの場合は、プロンプトの作成、スキルの定義、MCP サーバーへの接続、ミドルウェアの設定、そして時間が経つとともに取得または更新できるコンテキストのセットアップなどが必要になる場合があります。 *ノーコードでの構築* ビルドフェーズには、ノーコードおよびローコードの側面もあります。LangSmith Fleet、Claude Cowork、n8n などのツールにより、より多くの人々がエージェント開発に参加できるようになります。これは、必要なワークフローを理解している人物が、必ずしもコードを書く人物とは限らないため、重要です。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78dd_5f6458d6.png) 同時に、ノーコードツールがエンジニアリングによる制御の必要性を排除するわけではありません。システムが複雑化するにつれ、チームは通常、コードで動作を拡張または上書きする方法を必要とします。ここで特に重要なのがフックやミドルウェアです。これらは、ツール呼び出し、コンテキスト処理、承認、認証、ビジネスルールなどの周囲にカスタムロジックを追加できるようにし、すべてのエージェントをゼロから再構築する必要をなくします。 最高のビルド環境とは、単純なことをシンプルにし、複雑なことを可能にするものです。ドメインエキスパートがプロンプト、スキル、コンテキストを編集できるようにしながらも、信頼性、テスト可能性、ガバナンスが必要な部分についてはエンジニアが制御できる仕組みを提供します。 ## テスト エージェントをデプロイする前に、チームはそれが実際に準備ができているかどうかを判断する方法が必要です。 それは、誰もエージェントを使用する前に完璧な評価スイート（eval suite）を構築することを意味しません。実際には、そのようなことはめったに現実的ではありません。重要なのは、明らかな失敗を検出し、バージョンを比較し、盲目的に変更をリリースしないために、十分な数の評価（evals）を用意しておくことです。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78d4_4627dcc1.png) ほとんどの評価ワークフローは、代表的なタスクの小さなデータセットから始まります。例の一部は期待されるユースケースから得られ、他のものは手動テスト、ドッグフーディング（社内利用）、サポートチケット、過去のトレース、または既知のエッジケースから得られます。時間が経つと、本番環境でのトレースがこれらのデータセットを大幅に強化しますが、テストは本番環境に移行する前に行うべきです。 *データセットとメトリクス* データセットとは、チームが学んだことを保存する方法です。これがないと、プロンプトの変更、モデルのアップグレード、ツールの更新後に同じ失敗が繰り返される傾向があります。 適切なメトリクスはタスクによって異なります。 場合によっては、明確な正解（ground truth）が存在します。エージェントは正しい値を抽出しましたか？正しいラベルを選択しましたか？正しいフィールドを更新しましたか？これらのタスクは、正確性に対して直接測定することができます。 一方で、単一の正解が存在しない場合もあります。エージェントは応答の作成、会話の要約、エスカレーションの判断、あるいは複数の有効な経路を持つタスクの完了などを必要とすることがあります。そのようなケースでは、チームは基準ベースの評価により依存します。問いかけられるのは、「応答が根拠に基づいているか」「エージェントがポリシーに従ったか」「不明確な点を明確にするよう質問したか」「不要なツール呼び出しなしに効率的にタスクを完了できたか」といった点です。 *実験* 実験は、データセットと指標を反復プロセスに結びつける役割を果たします。これにより、チームは同じ評価セットに対してプロンプト、モデル、検索戦略、ツールスキーマ、オーケストレーションパターンを比較検討できます。時間の経過とともに、これらの実験を通じてエージェントが改善されているのか、後退しているのかが明らかになります。 目標は、初日に完璧な評価スイートを作成することではありません。重要なのは、有用なものから始めて継続的に改善していくことです。最も価値のある評価データセットは、困難な事例から構築されます：まず開発段階と社内利用（dogfooding）から始まり、その後本番環境からの事例が加えられます。 *シミュレーション* シミュレーションもテストの重要な一部です。 多くのエージェントは多ターンシステムです。単に一つの質問に答えるだけでなく、会話を交わし、情報を収集し、ツールを呼び出し、状態を更新し、曖昧さから回復します。そのようなエージェントにとって、単一ターンの評価だけでは不十分です。チームは多ターンの評価と、シミュレーションされたエンドツーエンドの相互作用が必要となります。 音声エージェントは明白な例ですが、このパターンはより広範です。一連のやり取りを通じて動作するあらゆるエージェントには、シミュレーションが必要となる可能性があります。サポートエージェントは、怒った顧客に対応し、追跡質問を行い、注文ステータスを確認し、エスカレーションが必要かどうかを判断する必要があります。コーディングエージェントは、リポジトリを検査し、変更を加え、テストを実行し、フィードバックに応答する必要があります。内部運用エージェントは、行動を起こす前に不足している情報を収集する必要があるかもしれません。 良いテストプラクティスは、チームが直感に頼らずに体系的にエージェントを改善することを支援します。期待される動作をデータセットに変換し、データセットを実験に変え、実験をシステムのより良いバージョンへと導きます。デプロイ後、モニタリングは、それらの評価を強化する実世界の例を提供します。 ## Deploy（デプロイ） エージェントが構築され、評価された後は、信頼して実行できる環境が必要です。 単純なエージェントの場合、デプロイは従来のアプリケーションのデプロイと似ているかもしれません。しかし、多くのエージェントには、ステートレスサーバー以上のものが必要です。彼らは長い期間にわたって動作し、ツールを呼び出し、人間の入力を待ち、ファイルを書き込み、中断から回復し、複数の対話やタスクにわたって状態を維持します。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78d1_beca6459.png) そのため、ランタイム（実行環境）が重要なのです。 本番環境のエージェントランタイムでは、通常、永続的な実行と人間を介したループパターンをサポートする必要があります。永続的な実行とは、何かが失敗した場合に作業を失うのではなく、進捗をチェックポイントして再開できることを意味します。人間を介したループとは、承認や明確化、レビューが必要な場合にエージェントが一時停止できることを意味します。 これに対する市販のソリューションが存在します。[LangSmith Deployment](https://docs.langchain.com/langgraph-platform) は、Deep エージェントおよび LangGraph エージェントのデプロイと管理のためのインフラストラクチャを提供します。AWS AgentCore も、エージェント向けのマネージドランタイムの別の例です。一部のチームは、スタック内の他の場所で既に Temporal を長期間実行されるワークフローに使用している場合など、Temporal などのシステムの上に独自のランタイムを構築することもあります。 *サンドボックス* 多くのエージェントには、専用の実行環境も必要とされます。 エージェントはますますコードの記述、コードの実行、ファイルの検査、ドキュメントの変換、またはファイルシステムとの対操作を行う必要があります。そのような場合、チームはその作業がどこで行われるかを決定する必要があります。サンドボックスは一般的な解決策です。これらは、ファイルシステムへのアクセス権を持つ隔離された実行環境を提供しつつ、ミステイクや不安全な行動による影響範囲を縮小します。 例としては、[LangSmith Sandboxes](https://www.langchain.com/blog/introducing-langsmith-sandboxes-secure-code-execution-for-agents/)、Daytona、および E2B が挙げられます。 すべてのエージェントに完全なサンドボックスが必要というわけではありません。場合によっては、エージェントは単にファイルを保存および取得できる場所があれば十分です。仮想ファイルシステムで十分な場合があります。Deep Agents は、このパターンをサポートしており、エージェントがサンドボックス内で任意のコードを実行する必要なく、ファイルを作業メモリとして使用できるようにしています。その背後にあるファイルシステムは、Postgres や S3 などのシステムによってバックアップされている可能性があります。 *Context Hub* デプロイにおいてしばしば見落とされがちなのが、プロンプトとコンテキストの管理です。 エージェントの中で最も重要な要素の一部は、従来のアプリケーションコードではありません。プロンプト、検索コンテキスト、スキル、タスク指示などは、アプリケーション自体よりも頻繁に変更が必要になる場合があります。また、エンジニアではない人々によって編集される必要もあるかもしれません。 これにより、プロンプトまたはコンテキストハブの必要性が生じます。これは、エージェントの非コード部分を保存、バージョン管理、レビュー、更新するための場所です。これにより、チームは完全なデプロイを行わずにエージェントの動作を調整でき、ドメインエキスパートが最もよく理解するコンテキストを自ら管理できるようになります。 実際的な運用において、デプロイとは単にエージェントをサーバー上に配置することだけではありません。それは、エージェントが実際の業務を行うために必要なランタイム、実行環境、およびコンテキスト管理システムを提供することを意味します。 ## Monitor 一度エージェントがデプロイされると、チームは本番環境における実際の動作について可視性を持つ必要があります。 ここが、エージェントの監視と従来のソフトウェアの監視を分ける点です。レイテンシ、コスト、エラーレート、稼働率といった指標は依然として重要ですが、それは全体像の一部に過ぎません。技術的に成功した回答を返しても、タスク自体には失敗する可能性があります。間違ったツールを呼び出したり、誤った文脈に依存したり、必要な承認ステップをスキップしたり、もっともらしく聞こえるが実際には間違っている回答を生成したりすることがあります。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78d7_8e9617a3.png) これらの失敗を理解するためには、チームはトレース（trace）が必要です。 トレースとは、エージェントが受け取った入力、実行したモデル呼び出し、使用したツール、取得した出力、そして生成された最終的な回答やアクションという、エージェントの全軌跡を記録するものです。これが、エージェントが実際に何を行ったかを理解するために必要な詳細レベルです。 そのため、私たちは「エージェントの観測可能性（agent observability）が評価を支える」と主張し、「エージェント改善ループはトレースから始まる」と述べてきたのです。もし軌跡が見えなければ、振る舞いを信頼性を持ってデバッグしたり、これらの失敗を将来の評価指標に変換したりすることはできません。 *シグナル* 監視には、これらのトレースからのシグナル（signals）の収集も含まれるべきです。 これらのシグナルの一部は、LLM-as-judge（LLM を用いた評価者）から得ることができます。例えば、評価者はエージェントがユーザーの質問に答えたか、ポリシーに従ったか、適切なトーンを使用したか、タスクを完了したかなどをスコアリングできます。他のシグナルはより単純なもので構いません。正規表現（regex）を用いて、必須フレーズが表示されたか、禁止されたツールが呼び出されたか、既知の失敗パターンが発生したかを検出できます。 これらのシグナルは品質チェックだけでなく、製品分析（product analytics）としても有用です。ユーザーがエージェントにどのようなタスクを依頼しているか、エージェントがどこでつまずいているか、ユーザーがどれほど頻繁に修正を行っているか、またユーザーがエラーを認識している箇所はどこかなどを把握できます。 *フィードバック* フィードバックは監視の別の重要な要素です。 トレース（traces）を単に保存するだけでは不十分です。チームはこれらのトレースとともにフィードバックも保存する必要があります。そのフィードバックは、LLM 評価者、正規表現ベースのシグナル、人間によるレビュー、または API を通じて収集された直接ユーザーフィードバックなどから得られます。例えば LangSmith では、チームがユーザーフィードバックを基盤となる実行（run）に直接紐付けることで、「ユーザーが不満を抱いた」という事象と「エージェントが 3 ステップ前に誤ったツールを使用した」という事実を結びつけやすくなります。 *ダッシュボード* 最後に、チームは時系列のトレンドを可視化できるダッシュボードとアラートが必要です。 有用なエージェントダッシュボードは、使用状況、フィードバック、レイテンシ、コスト、ツール呼び出し、評価者スコア、および反復する失敗パターンなどの指標を追跡します。重要な閾値を越えた場合、例えばレイテンシの上昇、コストの増加、ツールの故障、ユーザーフィードバックの低下、またはポリシー違反の急増などが発生した際にアラートがトリガーされるべきです。 優れたモニタリングは、単にシステムが稼働しているかどうかを知るだけではありません。それは、エージェントが正しい作業を、適切な方法で実行しており、時間とともに改善されているかを理解することです。 最も強力なモニタリングシステムは、直接評価フィードバックループに組み込まれています。重要なトレースはデータセットの例となり、反復する失敗は指標となり、本番環境での動作が次の改善ラウンドの基盤となります。 ## 反復（イテレーション） 最も優れた組織は、エージェント開発ライフサイクルを迅速かつ体系的に遂行します。 完璧なエージェントができるまで出荷を待つことはありません。代わりに、有用なものを作り、その振る舞いを理解する十分なテストを行い、制御された方法でデプロイし、本番環境でのパフォーマンスをモニタリングし、その学習結果を次のバージョンにフィードバックします。 それは無謀に出荷することを意味するわけではありません。鍵は可視性を持つことにあります。 データセット、実験、トレーシング（追跡）、フィードバック、およびダッシュボードを備えたチームは、実際の使用状況から直接学ぶことができます。広範囲に展開する前に変更をテストし、本番環境で何が壊れたかを特定し、失敗を評価（eval）に変換し、推測に頼らずエージェントを改善することができます。 これがチームのヒルクライミングであり、エージェントシステムが時間とともに改善していく方法です。 最も効果的なチームは困難な事例を見つけ、なぜエージェントが失敗したのかを理解し、プロンプト、ツール設定、検索戦略、モデル、ミドルウェア、またはワークフローを調整します。そして評価を再実行し、より良いバージョンを展開し、モニタリングが次のエッジケースや障害をもたらします。 企業内では、そのループをチーム全体で反復可能にすることが課題となります。 各チームが独自の評価フレームワーク、展開インフラストラクチャ、トレーシングシステム、フィードバックパイプライン、ダッシュボードを一から構築しなければならない場合、エージェント開発は遅々として進みません。最も効果的な組織は、共有インフラストラクチャ（shared infrastructure）に投資し、チームが基盤となるシステムを常に再発明することなくライフサイクルを進められるようにします。 それが、エージェント開発ライフサイクルを実践的な運用プラクティスとする理由です。 ## ガバナンス（Governance） ガバナンスは、エージェント開発のライフサイクル全体を取り囲むものです。 単一のエージェントであれば、軽量なコントロールで十分かもしれません。しかし、組織がより多くのエージェントを展開するにつれ、ガバナンスが必要となります。それがなければ、チームはすぐに、発見が困難で、監視が難しく、実行コストが高く、何ができるのか不明瞭なエージェントを抱え込むことになります。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78ce_1e0b2abf.png) *コスト* 最初のガバナンス上の課題はコストです。 エージェントは、複数のモデル呼び出しや長いコンテキストウィンドウの処理、ツールの繰り返し使用、リトライの実行、長時間の稼働などを伴う場合があるため、コストが高額になる可能性があります。組織は、予算管理、利用状況のモニタリング、アラート設定、およびどのエージェント・チーム・モデル・ツールがコストを発生させているかという可視性を通じて、その支出を追跡・管理する方法を必要としています。 *ツールのアクセス権限* 2 つ目のガバナンス上の課題は、ツールのアクセス権限です。 エージェントはアクションを実行できるため有用ですが、それと同時にリスクも生じます。チームは、どのツールにエージェントがアクセスできるか、どのような条件下でアクセスできるか、そして誰の名代として実行されるのかについて、明確な制御策を必要とします。 ここで監査証跡（audit trails）の重要性が高まります。エージェントがツールを呼び出した場合、組織はその呼び出しを行ったエージェント、使用された入力、生成された出力、およびそのアクションを許可したユーザーまたはポリシーを検査できる必要があります。ツールの呼び出しは、しばしばエージェントの振る舞いがビジネスへの影響をもたらす箇所であるため、監視可能でレビュー可能な状態にしておくことが不可欠です。 ヒューマン・イン・ザ・ループ（human-in-the-loop）は、もう一つの重要なガバナンスメカニズムです。 すべてのツール呼び出しを完全に自動化する必要はありません。顧客や金融システム、機密データ、本番環境のインフラストラクチャに関わる業務については、人間のレビューのために一時停止するべきです。ヒューマン・イン・ザ・ループのワークフローは、最初からシステムに組み込まれて設計されている場合に最も効果的に機能します。 *発見可能性* 3 つ目のガバナンス上の課題は、発見可能性と再利用性です。 組織がより多くのエージェントを構築するにつれ、プロンプト、スキル、ツール、検索ソース、ポリシー、さらには他のエージェントといった再利用可能な資産も蓄積されていきます。適切な発見およびガバナンスの仕組みがない場合、チームはこれらのコンポーネントを繰り返し再作成することになり、結果として一貫性が失われます。共有された文脈や共有されたエージェントは、見つけやすく、再利用可能で、適切に管理される必要があります。 これは特にスキルにおいて重要です。スキルにはワークフロー、ライティングスタイル、ドメイン固有の手順、またはツールの使用方法に関する指示が記述されます。あるチームがすでに優れたスキルを構築している場合、別のチームはそのスキルを見つけ、ゼロから新しいバージョンを作成するのではなく、それを利用できるべきです。 適切なガバナンスとは、チームの速度を落とすことではありません。それは、エージェントシステムがスケールしても、可視性、制御、一貫性を失うことなく、迅速な反復を可能にするためのものです。 ## 結論 最も優れた組織はすでにこのように運用を開始しています。彼らは早期にリリースしますが、盲目でリリースすることはありません。デプロイ前には評価を行い、デプロイ後には動作を監視し、得られた知見を継続的に活用して次のバージョンをより良くします。 これこそが、エージェント開発を反復可能にする要素です。また、これがエージェントを実証段階から信頼性の高い本番システムへと移行させる要因でもあります。

エージェント開発ライフサイクル：AI エージェントの構築、テスト、デプロイ、監視 | LangChain

背景や根拠まで確認しますか？

調べる

選ぶ

サイト