この記事は、2025/12/29に公開された「Context Is the Hard Part: Practical Lessons in Building Agentic AI Systems」の翻訳です。
コンテキストエンジニアリングが重要な理由と、それを実現する方法
「適切なデータを、適切な場所とタイミングで入手するにはどうすればよいでしょうか？」
これは、企業でエージェント AI を導入する時の根本的な課題です。大規模言語モデル（LLM）によって強力な推論機能とオーケストレーション機能が実現しましたが、その有効性はもっと基礎的な要素、つまり推論とアクションの実行に適切なビジネスコンテキストを提供することにかかっています。コンテキストエンジニアリングは、データ、メタデータ、アクセスポリシー、メモリを組み合わせて、エージェントの動作を安全かつ説明可能な方法でガイドすることに重点を置いた分野です。
Cloudera では、新しい生成 AI（GenAI）やエージェント AI のユースケースを実験している企業カスタマーとパートナーシップを組む中、この課題を目の当たりにしています。エージェント AI システムの構築は、AI ライフサイクル全体から知識をキャプチャ、管理、再利用するデータアーキテクチャという、ほとんどの組織が苦労するアーキテクチャに依存しています。
このブログでは、基本的な機能を「つながり」、「コンテキスト化」、「消費」の 3 つのバケットに分類するエージェント AI システムの構築アプローチを紹介します。このアプローチにより、当社の企業カスタマーは、インテリジェントで信頼性が高く、説明可能で、実運用に適したエージェント型システムを構築することができます。
連携：コントロールを活用してサイロを打ち破る
現代の AI エージェントは断片化された環境ではうまく機能しません。しかし、ほとんどの企業では、データが複数のクラウド、データセンター、レガシーシステムに分散され、フォーマットの一貫性もありません。そのデータを構造や保護手段のない AI システムに公開すると、パフォーマンスの問題やガバナンスのリスクにつながります。
成功した実装では、組織がまず、異なる環境や形式に広がる統合データ層の作成に重点を置いていることがわかりました。これはすべてのデータを集中管理するという意味ではなく、データをデータファブリックのアーキテクチャでつなぎ合わせるという作業です。これにより、共有メタデータ、アクセスポリシー、フェデレーションデータエンジニアリング、ランタイム相互運用性を備えた統合レイヤーが提供されます。
オープンテーブル形式と標準 API アクセスを実装することで、柔軟性を提供しつつデータアクセスが簡素化されます。オープンレイクハウスアーキテクチャは、特に信頼性の高い検索拡張生成（RAG）と推論に依存するエージェントワークフローにおいて、エンジン間でデータのリアルタイムかつ一貫したビューを提供するため、ここでは非常に重要になります。
コンテキスト化：エージェントにアクセス以上の価値を提供する
データが接続された後は、どのようなデータが存在し、どのように使用されているかを、エージェントが理解できるように支援することが課題になります。それは検出から始まります。クラウドおよびオンプレミスのシステム間でデータソースを自動的に特定し、メタデータ（テーブル名、フィールド、フォーマットなど）を有効化します。Cloudera Octopai Data Lineage のようなツールは、ETL スクリプトをスキャンし、パイプラインロジックをリバースエンジニアリングし、データがソースから最終目的地までシステム間でどのように移動して変換されるかを、その途中のすべての依存関係を含めキャプチャします。
この情報は、データセットがどのように関連し、時間の経過とともにどのように変化するかを示すリネージの基盤を作ります。リネージが重要になるのは、結果を検証したいとき、推奨事項やエージェントの行動を説明したいとき、あるいは壊れた出力を原因元までたどりたいときです。これでエージェントが関わるシステムに透明性と信頼が生まれます。
最後に、カタログ化によってこれらの情報が実用的な構造にまとめられます。集中管理されたメタデータストアがあると、人もエージェントも必要なものを見つけやすくなり、データセット同士の関係を理解できるようになります。また、データをどう扱うべきかに影響するポリシーも把握できます。強力なカタログは設計図のような役割を果たし、エージェントが企業のデータ資産を明確にたどれる、ナビゲーション可能な地図となるナレッジグラフを提供します。さらに、データを理解して行動に移すために必要な、すべての業務定義や業務ロジックを含む、技術、運用、ビジネスの各種メタデータを取り込みます。
コンテキスト化により、エージェントは情報の取得以上のことができるようになります。パターンを調査し、より的確な質問をするようになり、動作する環境をより深く理解した上で意思決定を行うことができます。
消費：適切なコンテキストを適切なタイミングで提供する
エージェントシステムを構築する最後のステップでは、追跡可能で安全かつ適切な情報に基づいた方法で AI がアクションを実行できるようにする必要があります。ここでアーキテクチャの選択が重要になります。ガードレール、可観測性、制御されたアクセスはすべて、エージェントが重要なときに予測どおりに動作するかどうかを左右します。
一般的なコンテキストエンジニアリングの手法を、それが解決するために設計された根本的なデータ課題にマッピングすると役立つことが分かりました。以下に、それが実際にどのように現れるかの例を示します。
データ準備の課題 |
コンテキストエンジニアリング技術 |
Clouderaのアプローチ |
プロンプトに機密データが漏洩する |
プロンプトエンジニアリング |
機密データを編集するためのプロンプト用のゲートウェイ |
整理されていない非構造化データ、古くなったベクトルインデックス |
RAG |
ガバナンスされ安全なリアルタイムのストリーミングデータパイプライン |
リネージの欠如、脆弱なトレーニングセット |
微調整 |
リネージ追跡により AI の説明可能性を向上 |
エージェントの越権行為、不透明な決定 |
ツール/APIアクセス |
メタデータのタグ付け、自律的なデータ分類、きめ細かなアクセス、すべてのシステムコールにおける完全な監査証跡 |
エージェントが社内のエンタープライズナレッジにアクセスできない |
モデルコンテキストプロトコル（MCP） |
REST カタログを使用した Apache Iceberg ベースのコンテキストへのアクセス制御 |
適切な手法の選択は、エージェントの役割、データの機密性、運用環境によって異なります。以下は、一般的なエンタープライズユースケースと、実際にうまく機能した推奨される方法の組み合わせです。
ユースケース |
推奨される方法 |
社内のナレッジアシスタント |
RAG + ベクトルデータベース + プロンプトエンジニアリングのフォールバック |
顧客関係管理（CRM）データを活用した営業支援ボット |
関数呼び出し + ビジネスコンテキスト注入 |
製品固有のサポートエージェント |
微調整または RAG + MCP 共有コンテキスト |
インサイトを抽出するための、データ分析向けマルチエージェントワークフロー |
LangGraph + MCP + ツールアクセス + チャンクメモリ |
ドキュメントの理解（PDF、Excel） |
マルチモーダル入力＋前処理パイプライン |
この消費アプローチにより、エージェントは正確かつ安全に、ビジネス目標に沿って業務を遂行できるようになります。
まとめ：フレームワークから実行へ
Cloudera では、企業データの複雑さに対処するために長年を費やしてきました。サイロを解消し、ガバナンスを強化し、AIと分析のための安全なパイプラインを構築し、ハイブリッド環境全体でリネージを可視化させています。そのため、エージェント AI のパターンが現れ始めたとき、私たちはゼロから始めたわけではありませんでした。コンテキストがどこに存在するのか、また適切なガードレールを使用して安全かつ確実にキャプチャする方法を知っていました。
Cloudera Octopai Data Lineage を使用すると、チームはクラウドとオンプレミスの環境間でデータフローを自動的にマッピングし、依存関係を追跡し、メタデータをカタログ化することができます。データカタログ、可観測性、アクセス制御を階層化することで、エージェントはシステムとより安全かつインテリジェントに対話できるようになり、これらのワークフローを企業全体で拡大するために不可欠な可視性、ガバナンス、信頼を獲得できます。
これらの機能を実用化するために、これらの機能を Open Data Lakehouse と Cloudera AI Studios に統合し、企業が本番環境で安全なエージェントシステムを設計、展開、管理するための基盤を提供しています。
Cloudera が AI エージェントを適切なビジネスコンテキストで本番稼働させるのにどのように役立つかについて、Webサイトにてさらに詳しくご確認ください。
