本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
著者: Wang Chen
最近、2つの記事が大きな注目を集めています。どちらの記事も、AIの発展に伴いAIアプリケーションのエンジニアリング面が過小評価されていることに言及しています。たとえば、より優れた仮想マシン、長いコンテキスト、多数のMCP（マルチコントロールポイント）、さらにはスマートコントラクトなど、多くのエンジニアリング問題が求められています。AI向けのエンジニアリングツールは数多く存在し、LangGraphやLangChainなどがその例です。これらはレゴブロックのようなもので、ブロックが豊富であるほど複雑な構造を組み立てる能力が高まります。しかし、「エンジニアリング」という用語は非常に包括的な技術用語であり、幅広い内容を含んでいます。広義には、アルゴリズム以外の技術実装や製品設計はすべてエンジニアリングに分類されます。この記事では暫定的に、エンジニアリングを「プロダクトエンジニアリング」と「技術エンジニアリング」に分類し、これを視点としてAIエージェントのエンジニアリングシステムの構築を簡略化しようとしています。
エンジニアリング = プロダクトエンジニアリング + 技術エンジニアリング
これらの2つの要素の連携により、AIエージェントが使用可能で使いやすく、スケーラブルであるかどうかが決まります。
1. プロダクトエンジニアリング
目標: AIを簡単に使える形にし、ユーザーにとって理解しやすく、快適に利用でき、持続可能な形にすること。成長の観点からは、ダウンロード数だけでなく、リテンション率やユーザーのアクティビティも重要です。
プロダクトエンジニアリングは、製品哲学、ビジネス、インタラクションデザイン、ユーザーエクスペリエンス全体を考え、AIがブラックボックスではなく、知覚的で、指導的で、フィードバックに富んだ自己修正メカニズムを持つことを確保します。まずプロダクトエンジニアリングを分解し、その後、成功するAIエージェントを達成する上で重要なモジュールに焦点を当てます。
| モジュール | 定義 |
|---|---|
| 需要モデリング | AIアプリケーションの対象となるユーザー層を明確にし、解決できる問題を特定し、AIを単に使うためだけに使うのではなく、具体的な目的意識を持たせる。 |
| UI/UXデザイン | AIの複雑な動作を、ユーザーが理解し操作できるインターフェースやプロセスに変換する。 |
| 人間-機械インタラクションプロセス | AIが質問を投げかけ、意思決定を確認しながら、アシスタントのようにリズミカルにタスクを完了させる。 |
| プロンプトエンジニアリング | プロンプトを魔法の杖のように活用して、AI出力の品質と一貫性を向上させる。 |
| フィードバックループ | ユーザーが結果に対してフィードバックを提供し、システムが改善を学習したり失敗を検知したりできるようにする。 |
| 権限とコンプライアンス | 誰がどのデータを使えるかを制御し、AIの悪用やデータ漏洩を防ぐ。 |
1️⃣ 需要モデリング
従来のソフトウェア開発では、最初に「ユーザーの主要な課題は何ですか？」という問いを立てます。これと同じことがAIエージェントにも当てはまります。もしターゲットユーザーとユースケースを明確にしなければ、AIが何でも答えるように見えても実際には役に立たない状況に陥りやすくなります。
AIエージェントを構築する第一歩はモデルを選ぶことではなく、むしろ以下のようなプロダクトマネージャー的な質問に答えることです。「このAIは誰を助けるのか？どのように問題を解決するのか？どのような問題に対応できるのか？どの程度まで問題を解決できるのか？そして、ユーザーはこの価値のために支払う意思があるのか？」これが製品と市場の適合を定義します。
例: Manus[3]
Manusは世界初の汎用AIエンティティで、手と脳の組み合わせを核とする概念に基づいており、AIが受動的なツールから能動的な協力者へと移行することを強調しています。
-
AIの役割の明確化
需要モデリングの段階で、ManusはAIを単なる提案や回答をするものではなく、独立して考え、計画し、複雑なタスクを遂行できる「能動的な協力者」として位置づけています。例: ユーザーがタイへの7日間予算20,000元を入力すると、Manusは自動的に通貨変換を行い、ホテルの比較、旅程の計画を行い、PDFマニュアルを生成します。この役割定義には、システムプロンプトにおいてAIの責任範囲と行動境界を明確にすることが含まれており、タスク実行における自律性と信頼性を確保します。
-
タスクの閉鎖能力の設計
Manusはタスクをクローズドループで実行する能力を重視しています。これは、指示を受け取って完全な結果を提供するまでの全プロセスが自動化されることを意味します。例: ユーザーが株式xxの分析を要求すると、Manusは関連データを自動的に取得し、財務モデリングを行い、インタラクティブなダッシュボードを作成し、それをアクセス可能なウェブサイトとして展開します。需要モデリングでは、ユーザーの要求を複数のサブタスクに分解し、それに応じた実行プロセスやツール呼び出し戦略を設計することが必要です。
-
マルチエージェントの協力アーキテクチャ
Manusは計画層、実行層、検証層に分かれたマルチエージェントアーキテクチャを採用しており、各層が協力して複雑なタスクを完了します。- 計画層: タスクの分解とプロセスの計画を担当。
- 実行層: 各種ツールやAPIを呼び出して特定のタスクを実行。
- 検証層: タスク結果を検証し、出力の正確性とコンプライアンスを確保。
-
人間-機械協力モデルの革新
Manusは非同期処理やタスク中の介入をサポートしており、ユーザーが実行中に指示を追加したり、タスクパラメータを変更できるようになっています。これは実際の職場での協力形式を模倣したもので、需要モデリングでは、人間-機械インタラクションの柔軟性と制御可能性を考慮する必要があります。
2️⃣ UI/UXデザイン
AIエージェントは伝統的なソフトウェアとは異なり、その出力はしばしば不確定で遅延があり、予測が困難です。そのため、UI/UXデザインは単にインターフェースを美しくするだけでなく、ユーザーの心理や行動リズムを理解することも重要です。
例: DeepSeekは大規模モデルの思考プロセスを可視化した最初の例です。レスポンスを生成する前に、モデルの思考チェーンを表示することで、AIがランダムに推測しているわけではなく、論理的に考えていることをユーザーに示します。この設計により、ユーザーは受け身で結果を待つのではなく、問題解決のプロセスに参加し、信頼関係を築きます。
現在、進行的な情報提示、思考プロセスの可視化、構造化された結果などのインタラクション戦略がAIエージェントの標準となっています。ユーザーはコールチェーンを表示し、参照元を追跡でき、Qwenでは信頼できないインターネットソースによる幻覚現象を減らすために参照元を削除するオプションさえ提供されています。
3️⃣ システムプロンプト
システムプロンプトとは、AIエージェント開発者が事前に設定する一連の指示または制約で、特定のアプリケーションシナリオにおけるモデルの行動フレームワーク、役割設定、インタラクションスタイル、出力ルールを定義
タスク指向のプロンプト配置とフィードバックループ、およびAIアプリケーションの技術的エンジニアリング
タスク指向のプロンプト配置は、従来の会話形式の質問応答を超越し、タスクスクリプトのような形態となり、マルチモーダルAIアプリケーションの基盤能力を形成しています。 4️⃣ フィードバックループ
AIエージェントの出力が最初から完璧であることはありません。実際には、特定の入力に対してパフォーマンスが悪く、他のデータでは意味的な逸脱が発生するため、失敗例を集めて入力から評価までのループを形成することが必要です。例えば、Monicaのメモリ機能では、ユーザーが推奨されたメモリエントリを閲覧中に「事実として採用する」ボタンをクリックできます。これらの項目はその後、メモリデータベースに書き込まれ、次の会話で使用されますが、採用されなかった項目は強制的に記憶されることはありません。このフィードバック → 選択的吸収 → 次ラウンド調整のメカニズムは、従来のプロンプト＋チャットモデルを向上させます。Monicaは継続的にユーザー特性から学習し、ニーズ理解や応答の正確性を改善します。本質的には、会話インタラクションにおけるコンテキスト認識を再構築しています。人間同士のコミュニケーションと同じように、二人が長く交流すればするほど、お互いに親しみを持ち、相手の表現をよりよく理解できるようになります。
2. 技術的エンジニアリング
目標:
AIの背後にあるシステムが迅速に起動し、安定して動作し、効果的にスケールし、観測可能であることを保証することです。
技術的エンジニアリングは製品エンジニアリングを検証します。インターネット時代の「速い魚が遅い魚を食べる」ように、AI時代においても技術的エンジニアリングの効率は、迅速に製品エンジニアリングを実行し、市場を検証し、迅速に反復を行う上で非常に重要です。技術的エンジニアリングは、AIアプリケーションを支えるロジスティックシステムであり、アーキテクチャとモジュール化、ツール呼び出し機構、モデルとサービスの統合、トラフィックとアクセス制御、データ管理と構造化出力、安全性と分離メカニズム、DevOpsと観測可能性などを含みます。
モジュール定義
アーキテクチャとモジュール化
AIアプリケーションを小さなモジュールに分解し、各コンポーネントに明確な責任を持たせることで、組み合わせやすく、保守しやすいものにします。
ツール呼び出し機構
AIがデータベースを呼び出したり、天気を確認したり、注文を行ったりできるようにすることで、実際にタスクを遂行します。
モデルとサービスの統合
複数のモデル（DeepSeek、Qwen、ローカル大規模モデルなど）を統合し、一元的に呼び出しと管理を行います。
トラフィックとアクセス制御
異なるユーザーとモデルに対する利用頻度とアクセス権限を制御し、誤用やクラッシュを防ぎます。
データ管理と構造化出力
AIが出力する自由テキストを構造化データに変換し、システムがそれを直接使用したり、データベースに保存したりできるようにします。
安全性と分離メカニズム
データの相互利用や不正操作を防ぎます。これは特にマルチテナントまたは企業アプリケーションにおいて重要です。
DevOpsと観測可能性
グレーリリース、機能のロールバック、パフォーマンスアラームをサポートし、各呼び出し時に何が起こったかをログに記録し、問題を特定し、最適化のための指標を提供することで、継続的かつ安定した運営を確保します。
1️⃣ アプリケーションアーキテクチャとモジュール化
AIアプリケーションがプロトタイプから本番システムへ移行する中で、重要な課題の一つは、プロンプト、モデル拡張、アドバイザー、検索、メモリ、ツール、評価、MCPなどの複数の異種モデルの機能をどのように組織化し、統一的なアーキテクチャにまとめ上げるかです。同時に、高水準の保守性、観測可能性、スケーラビリティを確保する必要があります。これがモジュラー型アーキテクチャとオーケストレーションツールの役割です。
LangChainやLangGraphのようなPython中心のエコシステムに加えて、Spring AI AlibabaはJavaコミュニティ向けにネイティブで企業レベルのAIアプリケーションオーケストレーション機能を提供し、モジュラー型AIアプリケーションを構築するための重要なツールとなっています。そのコア機能には、上述の8つの基本的な能力に加え、以下が含まれます：
- マルチエージェントフレームワーク: GraphはSpring AI Alibabaコミュニティの主要な実装の一つであり、Spring AIとは異なり、低レベルの原子抽象に焦点を当てるのではなく、開発者がエージェントアプリケーションをより簡単に構築できるよう支援することを目指しています。AIエコシステムの統合を通じて、企業エージェント実装の課題を解決します。
- Bailianプラットフォームとの深い統合: モデルアクセスとRAG知識ベースソリューションを提供します。
- 観測可能性製品とのシームレスな統合: ARMSやLangfuseなどの観測可能性製品をサポートします。
- 企業レベルのMCP統合: Nacos MCPレジストリによる分散登録と発見、自動ルーター経路選択を含む企業レベルのMCP統合をサポートします。
- 汎用エージェント製品とプラットフォームの探索: Spring AI Alibabaフレームワークに基づいたJManusエージェントを公開し、自律計画のエージェント開発における応用を探るとともに、開発者に低コード、高コード、ノーコードでのエージェント構築のための柔軟なオプションを提供します。
例えば、内部企業向けのインテリジェントカスタマーサービスシステムを開発しており、以下の要件があるとします：
- 多段階の会話でユーザーコンテキストを記憶できること。
- 内部ナレッジベースへのアクセスによる高度な検索能力。
- ERPやCRMなどのバックエンドシステムのAPIを呼び出す能力。
- K8s上でのデプロイが可能で、高並列処理と統一されたログ追跡をサポートすること。
Spring AI Alibabaを使用すると、次のように設計できます：
プロンプトイントフェース宣言
@Prompt注釈を使用して、複数のビジネスモジュール（顧客苦情対応、経費精算照会など）のプロンプトテンプレートを定義します。各モジュールはコンポーネントクラスとして扱われ、独立した反復とメンテナンスが可能です。
ツール関数の呼び出し
@Toolや@Function注釈を使用して、バックエンドのHTTPインターフェースやローカルJavaメソッドをLLMによって呼び出し可能な関数として公開します。例えば、顧客の注文ステータスを確認したり、CRMの更新をトリガーしたりすることができます。これはLangChainのツール呼び出しモードに似ていますが、Spring Beanライフサイクルと依存注入を自然にサポートします。
コンテキストとセッション管理
Redisやローカルメモリを使用して組み込みのメモリ管理モジュールを活用し、セッション状態を記録することで、会話のコンテキストを自動的に連結します。従来の方法（トークンコンテキストの手動管理）と比較して、マイクロサービスのデータ隔離とカプセル化設計により適合しています。
分離されたモジュールとデプロイメント
各ビジネスライン（財務アシスタント、人事アシスタント、技術Q&Aなど）は、独立したSpring Bootマイクロサービス
認証メカニズムとAIアプリケーションの監視に関する詳細解説
hmac-auth: HMACベースの署名認証メカニズム
HMAC（Hash-based Message Authentication Code）に基づく署名認証メカニズムです。各リクエストには署名値が含まれており、ゲートウェイはキーに基づいて署名の有効性を検証します。例えば、Webhookコールバックの検証があります。サードパーティプラットフォーム（例: Stripe、OpenAI）がイベントを送信する際に、ソースの信頼性を確認するために署名を付与します。改ざん防止のインターフェース保護として、一部の敏感なインターフェース（推論タスクの発行など）はリクエストの改変を防ぐために署名を使用します。これは、荷物を発送する前に個別の印を押すようなもので、受取人はその印を確認することで荷物が改ざんされていないことを確認できます。署名は通常、リクエストボディ＋タイムスタンプ＋キーに基づいて生成され、リプレイ攻撃や偽造を防ぎます。
jwt-auth: JWTによるユーザー認証と認可
JWT（JSON Web Token）を用いたユーザー認証と認可を実装します。リクエストには発行されたJWTが含まれており、ゲートウェイは署名とペイロードに基づいてこれを検証します。例えば、ユーザーがログイン時にトークンを取得し、それを使用してAIアシスタントにアクセスしたり、セッションシステムを利用したり、ロールベースの権限を実装することができます（例: role=admin）。これは「私はVIP顧客です」と書かれたデジタルパスのようなもので、システムがそのパスをスキャンして身元と権限を確認します。この方式は、フロントエンドとバックエンドが分離されたアーキテクチャでよく使用され、SSO（シングルサインオン）をサポートする企業システムに適しています。
jwt-logout: JWT無効化メカニズム
JWTには組み込みの有効期限がありますが、ユーザーが自発的にログアウトした場合、システム全体で無効化する必要があります。例えば、セキュリティ強化のシナリオでは、ユーザーがログアウトした際に古いトークンを使用してモデルインターフェースを呼び出すことを許可してはいけません。AI SaaSプラットフォームでのセッション管理では、ユーザーがデバイスを変更したりログアウトしたりした際に、身元証明情報を積極的にクリアする必要があります。これは、他人が発行したアクセスカードを取り消して再利用できないようにすることに似ています。
oauth: OAuth 2.0プロトコルに基づくサードパーティ認証ログインとアクセス制御
Google、GitHub、WeChatなどの認証プラットフォームを介してユーザーがログインできるようにします。例えば、ワンクリックログインにより、ユーザーがGoogleでログインして認証後に身元トークンを取得し、企業の身元システムと統合します。さらに、Higress / Alibaba Cloud API Gatewayに代表されるAIゲートウェイは、柔軟で拡張可能なプラグイン機構を通じてより多くの機能を提供し、ユーザーがカスタムプラグインを開発して機能を拡張できるようにします。
AI Retrieval-Augmented Generation (RAG)
ベクトル検索サービス（DashVector）と連携してRAGアプリケーションの開発を簡素化し、大規模モデルからの出力を最適化します。
セキュリティとコンプライアンス
ゲートウェイで入力と出力をインターセプトし、コンテンツセキュリティ保護戦略はゲートウェイのリクエストとレスポンスに対してリアルタイムスキャン能力を持ち、潜在的なリスク情報を識別します。大規模モデルレイヤーでは、入力と出力に対してリアルタイム検査を行い、潜在的なリスク情報が意図せず露出または伝達されることを防ぎ、データ漏洩のリスクを軽減します。インターネット検索エンジンレイヤーでのインターセプトでは、応答に潜在的なリスク（違反、悪意のあるリンク、機密情報など）がないかをチェックします。
コンテンツキャッシュ
繰り返しのAIリクエストシナリオにおいて、Redisデータベースに大規模言語モデルによって生成されたレスポンスをキャッシュし、大規模言語モデルの再呼び出しを避け、応答速度を向上させます。
ロギングとモニタリング
クラシックなインターネットアプリケーションにはトレース可能なデバッグがありますが、大規模モデルアプリケーションには標準化されたデバッグツールが不足しており、問題の追跡、特定、解決が著しく困難です。以下はいくつかの重要な比較要素とコアの違いです。
観測対象の違い
| カテゴリ | 従来のアプリケーション | 大規模モデルアプリケーション |
|---|---|---|
| 観測対象 | バックエンドロジック、データベースクエリ、API呼び出し | プロンプトの入力/出力、モデル推論プロセス、コンテキストの変化、思考チェーン |
| 注目点 | パフォーマンスのボトルネック、サービスステータス、例外スタック | レスポンスの妥当性、一貫性、偏差、幻覚、潜在的な誤解 |
| 観測粒度 | 関数レベル、コールチェーンレベル | トークンレベル、セマンティックレベル、行動パスレベル |
例えば、従来のアプリケーションでは「このインターフェースはタイムアウトするか？」に注目する一方で、大規模モデルアプリケーションでは「なぜこのモデルが不適切なことを言ったのか？」や「ユーザーの意図を誤解したか？」といった質問にも対処する必要があります。
観測目標の変化
従来のシステムでは、観測目標はシステムが正常に動作しているかどうか（例: レスポンスのタイムアウト、CPUやメモリの使用率、エラー率など）でしたが、大規模モデルアプリケーションでは状況が異なります。システムが正常に動作していても、結果が間違っている可能性があります！したがって、観測目標は可用性指標だけでなく、以下の点にも焦点を当てる必要があります：
- レスポンス内容が正しいか、合理的か（セマンティックな正確さ）
- 設定された挙動から逸脱していないか（例: システムロール）
- 幻覚、許可されていない行動、有害な言葉が存在しないか
- モデルの挙動がバージョン、プロンプト、またはコンテキストと相関しているか
例えば、AI医療Q&Aシステムでは、クラッシュログがなくても、モデルが出した薬を飲まないことを推奨するような誤った結果が生じた場合、それはセマンティックレベルでの観測が必要です。これらの問題に対処するために、最初のステップは、単一の呼び出しに関係するコンポーネントを特定し、それらすべてを呼び出しチェーンを通じて接続することです。完全な経路診断のためにリンクを確立し、リクエストに問題があった場合、どの段階で失敗したのか（AIアプリケーションか内部モデル推論か）を迅速に特定する必要があります。次のステップは、すべてのデータをうまく関連付けられるフルスタックの観測可能データプラットフォームを構築することです。これにはリンクだけでなくメトリクスも含まれます。例えば、モデル内のGPU利用率は、問題がアプリケーションレベルにあるのかモデルレベルにあるのかを判断するのに役立ちます。最後に、各呼び出しの入力と出力情報を含むモデルログを分析し、このデータを使用して評価と分析を行い、AIアプリケーションの品質を検証します。これらの3つの手段から、さまざまな観測技術とコアフォーカスポイントを異なるレベルで提供します。
結論
この記事では、AIエージェント工学のコアモジュールと主要なパスについて概説しましたが、現実世界の課題はここで述べたよりもはるかに複雑であることを認識しなければなりません。人間の論理と大規模モデルの有機的な連携、複雑なタスクを処理