動画記事 · AI Engineer
マイクロサービスが 2015 年に持っていたのは、今やエージェントの時代へ
動画の文字起こしと公開情報をもとにAIで要約・構成しています。 正確な発言は元動画と時間位置で確認してください。
まず要点
Navan のアーキテクトが、マイクロサービスの教訓を踏まえ、エージェント開発におけるランタイム、メモリ、文脈管理、観測性、ガバナンスの各層の実践的アプローチと標準化の現状を解説する。
マイクロサービスの教訓から学ぶ:エージェント開発の現実的なアーキテクチャ指針
マイクロサービス移行期に「構造化されたモノリシックなシステムが作れないのに、なぜマイクロサービスを目指すのか」という問いが投げかけられました。現在、生成 AI エージェントの時代において、同じく「単一のエージェントループが確立できないのに、複雑なマルチエージェント系へ移行すべきか?」という根本的な問いが浮上しています。
Navan のアーキテクトらは、生産環境で多数のエージェントを運用し続ける中で得た教訓を基に、状態管理やメモリ、観測性、ガバナンスに至るまで、実用的なエージェントアーキテクチャのレイヤー構造を提示します。これは単なるプロトタイプ段階を超え、堅牢なエンタープライズ運用へと移行する過渡期における重要な指針です。
マイクロサービスからの教訓:複雑さへの依存戒む
技術トレンドは常に波のように押し寄せますが、その本質的な課題は共通しています。マイクロサービスの時代には、コンテナオーケストレーションやサービスマッシュなど多くの良い成果が生まれましたが、それは一夜にして実現したわけではありません。多くの組織が直面したのは、複雑な分散システムを管理する難しさでした。
この経験から得られた重要な教訓があります。
「もし構造化されたモノリシックなシステムを構築できないなら、なぜマイクロサービスに挑戦するのか?」
これは現在の AI エージェント開発にもそのまま当てはまります。単一のエージェントループ(Single Agentic Loop)が安定して動作しない状態で、複雑なマルチエージェントオーケストレーションを試みるべきではありません。
まずは「単一のマスター型」アプローチで、エージェントの基本的なループを確立することが最優先です。Navan の実践では、複数のエージェントを連携させる前に、まず一つの強力なエージェントがドメイン固有のスキルを動的に読み込み、適切に動作することを目指しています。
状態を持つランタイム層:セッションと永続化の重要性
従来のマイクロサービスはステートレス(状態を持たない)で設計されることが一般的でしたが、AI エージェントは本質的に「ステートフル(状態を持つ)」です。エージェントには継続的なセッション維持や、プロセスの分断からの復元(リハイドレーション)が不可欠です。
AWS、GCP、Azure などの主要クラウドプロバイダーもこの課題に気づき、「Agent Core」のようなランタイム層を提供し始めています。しかし、これらの標準機能だけで全てをカバーできるわけではありません。
Navan の実践では、AWS Agent Core を基盤としつつ、独自に以下の機能を追加実装しています:
- セッションの永続化: エージェントが中断された後でも状態を保持する仕組み
- リハイドレーション: 過去のコンテキストから状態を復元し、継続して実行する機能
これにより、従来の API サービスとは異なるライフサイクルを持つエージェント特有の要件を満たすランタイム層を構築しています。
メモリと文脈管理:スキルの活用で限界を超える
LLM のコンテキストウィンドウには物理的な限界があり、無限の情報を詰め込むことはできません。また、情報が多すぎるとエージェントは焦点を失い、パフォーマンスが低下します。
この課題に対する解決策として、Navan は「スキル(Skill)」を文脈管理の単位として活用しています。スキルとは、特定のドメインやタスクに関する指示・設定(コンテキスト)と、ツール実行機能(アジェンシー)の両方を含む、再利用可能で独立してテスト可能なモジュールです。
具体的なアプローチは以下の通りです:
- 動的な文脈組成: ドメイン固有のスキルを必要に応じて組み合わせ、動的にコンテキストを構築します。
- プログレッシブ・ディスクロージャー: 最初は限定的なスコープで開始し、必要なメタデータや情報を段階的に追加して範囲を広げます。
これにより、コンテキストウィンドウの制約の中で、エージェントが焦点を保ちつつ複雑なタスクを処理できるようになります。また、短期間の会話メモリから長期記憶、成功・失敗事例のエピソード記憶へと、時間軸に応じてメモリを管理するパイプラインも構築されています。
非確定的動作の観測:ログ分析を超えたデバッグ手法
従来のマイクロサービス時代には、ログを分析して問題を特定するのが一般的でした。しかし、AI エージェントは「思考プロセス」を出力するため、ログの量が膨大になり、人間が追跡するのは現実的に不可能です。
エージェントの開発では、以下の観測性(Observability)の強化が不可欠です:
- フックによる自動追跡: ツール呼び出しの前・後や意思決定の前・後にフックを設定し、自動的にトレースデータを収集します。
- 信頼スコアの取得: エージェントが判断を下す際の「自信度」を信号として取得し、推論プロセスを追跡します。
- 軌跡評価(Trajectory Evaluation): エージェントが目標に到達するまでの経路を可視化し、効率性や完全性を評価します。
これにより、エージェントがどこでつまずいたのか、なぜその判断を下したのかを特定できるようになります。特に「推論された回答」かどうかの信号を取得することで、必要に応じて人間の介入(Human-in-the-loop)を適切に組み込むことが可能になります。
ガバナンスと単一マスター型:権限委譲の明確化
エンタープライズ環境では、エージェントによる権限委譲の曖昧さが大きな課題となります。例えば、「$200 以下の便があれば予約して」という指示に対し、それが「ユーザー自身」の行動なのか「エージェント」の代行行動なのかを区別する必要があります。
この問題を解決するために、Navan は以下の方針を採用しています:
- 事前・事後のガードレール: すべてのツール呼び出しの前と後に厳格な認証・認可チェックを実装し、ポリシー違反を防ぎます。
- 単一マスター型アーキテクチャ: 複雑なマルチエージェント系よりも、一つのマスターエージェントがサブスキルを動的に読み込むアプローチを採用しています。
これにより、権限の委譲先を明確にし、セキュリティとガバナンスを維持しつつ、柔軟なタスク処理を実現しています。マルチエージェント間の通信が必要なケースも存在しますが、まずは単一エージェントの成熟度を高めることが優先されます。
まとめ:実用性を重視したエージェント開発へ
AI エージェントの開発は、複雑さへの依存から脱却し、実用的で堅牢なアーキテクチャへと移行する過渡期にあります。マイクロサービスの教訓を踏まえ、単一のエージェントループの確立、状態管理の標準化、スキルの活用による文脈管理、そして厳格な観測性とガバナンスの実装が、生産環境での成功には不可欠です。
開発者は「複雑さ」に惑わされず、まずは基礎的な部分を固めることから始めましょう。それが、将来のスケーラブルで信頼性の高い AI エージェントシステムの基盤となります。
Original Source
元動画で発言を確認
プレイヤーは必要になるまで読み込みません。YouTubeのCookieと通信も再生を選ぶまで開始しません。
時間位置から根拠を確認
章や引用を選ぶと、元動画をその位置から再生します。