Well-Architected Framework:AI アーキテクチャ決定フレームワーク

ファインチューニング、検索拡張生成 (RAG)、プロンプトエンジニアリング

モデルの入手元を決めた後の次の意思決定は、汎用モデルを特定の業務シナリオにどう適応させるかです。主なカスタマイズ手法は 3 つあり、それぞれに適した条件があります。

• プロンプトエンジニアリング は、初期コストが最も低く、反復のスピードも最速です。システムプロンプトを慎重に設計し、フューショット例を構築し、Chain of Thought (CoT) などの手法を活用することで、対象タスクにおけるモデルの性能を大幅に改善できます。これは、タスクを自然言語で明確に記述でき、公開知識で回答品質を担保でき、かつ業務ロジックが頻繁に変化して迅速な調整が必要な場合に適しています。Model Studio (Bailian) プラットフォームでは、アプリケーション設定インターフェイスからプロンプトを迅速に反復し、A/B テストを実施できます。

• 検索拡張生成 (RAG) は、プロンプトエンジニアリングに外部ナレッジの検索を組み合わせたものです。RAG は、モデルが企業の非公開ナレッジ (製品ドキュメント、社内ポリシー、顧客データなど) にアクセスする必要がある場合、ナレッジが頻繁に更新される場合 (週次の製品価格表など)、または回答に出典の追跡可能性 (特定の文書や段落の引用) が求められる場合に適しています。Model Studio (Bailian) のナレッジベース機能は、ドキュメントのアップロードと自動チャンク化から、ベクトル化、保存、検索までを含むエンドツーエンドの RAG パイプラインを提供し、RAG システム構築の参入障壁を下げます。

• プロンプトエンジニアリングと RAG で要件を満たせない場合は、モデルのファインチューニングを使用します。これは、モデルに新しい文体や専門用語 (特定の法的文書フォーマットなど) を学習させる必要がある場合、長いプロンプトが必要だったタスクを少ないトークンで完了させて実行時のコストを下げたい場合、または評価基準が強く主観的で大量の人手による嗜好データから学習させる必要がある場合に最適です。PAI プラットフォームは、フルパラメータファインチューニングと LoRA などのパラメータ効率の高い手法の両方をサポートし、学習データ管理とモデル評価のための包括的なツールチェーンを提供します。

実運用では、これら 3 つの手法を組み合わせて使用することがよくあります。典型的な進め方は、まずプロンプトエンジニアリングで実現可能性を素早く検証し、次に RAG を追加して企業ナレッジを取り込み、最後にコアシナリオに対してファインチューニングを適用して一貫性を高めます。DataWorks を使用して、RAG パイプラインのデータ前処理ワークフローを管理し、ナレッジベースの品質と鮮度を確保できます。

単一モデル、モデルルーティング、モデルアンサンブル

モデル戦略の最後の軸は、組み合わせ方です。

• 単一モデル 方式は最もシンプルです。高性能なモデルを 1 つ選び、すべてのリクエストを処理します。これは、単一目的の業務シナリオ、リクエストの複雑さが均一、かつコストが主要な制約ではない場合に適しています。たとえば、社内の経営層向け戦略分析アシスタントは、リクエスト量は少ない一方で極めて高い品質が求められるため、Qwen-Max を単体で使用すれば十分な場合があります。

• モデルルーティング は、リクエストの複雑さが不均一な場合に有効です。典型的なパターンでは、軽量な分類器 (ルールエンジン、小規模モデル、またはヒューリスティックアルゴリズム) が、特徴に基づいてリクエストを異なるモデルにルーティングします。たとえば、簡単なチャットは Qwen-Flash、RAG が必要な標準的な質問は Qwen-Plus、複雑な推論が必要なリクエストは Qwen-Max に振り分けられます。Model Studio (Bailian) のワークフローを使用して、このルーティングロジックをオーケストレーションし、将来の最適化に向けてルーティング判断をログとして記録できます。

• モデルアンサンブル は、判断精度が最重要の場合に使用します。複数のモデルが同じリクエストに対して独立して応答を生成し、投票、重み付き融合、または整合性チェックにより最終出力を決定します。これは、金融のリスク管理や医療の診断支援など、許容できる誤りが極めて小さいシナリオに適しています。トレードオフは、コストとレイテンシーが乗算的に増えることです。実運用では、2 つの小さめのモデルで合意を取ることで、1 つの巨大モデルの代わりとなり、特定のシナリオでより良いコスト対品質比を実現できる場合もあります。

トレードオフマトリクス

モデル戦略における主要なトレードオフは、次の 4 つの観点で分析できます。

• レイテンシー：API モデルは通常、ネットワークのオーバーヘッド (50～200 ms) があります。セルフホストモデルは極めて低いレイテンシーに最適化できますが、そのための運用投資が必要です。大規模モデルは推論が遅くなりますが、Mixture of Experts (MoE) などのアーキテクチャにより、大規模モデルの能力を維持しつつ推論のオーバーヘッドを抑制できます。

• コスト：API はトークン単位の課金であるため、コストは利用量に比例して線形に増加します。これは変動の大きいワークロードに最適です。セルフホスティングは GPU 時間で課金され、固定費を伴う一方で、限界費用は低く、安定して高ボリュームのワークロードに適しています。ファインチューニングには一度きりの学習コストがかかりますが、短いプロンプトでタスクを完了できるようになり、実行時のトークン消費を削減できます。

• 品質：一般に、パラメータ数が多いモデルほど品質は高くなりますが、すべてのタスクでそうとは限りません。特定の垂直領域タスクでは、ファインチューニングした小規模モデルが汎用の大規模モデルを上回る場合があります。RAG は事実の正確性を大幅に高めますが、システムの複雑さが増します。

• データプライバシー：API モデルでは、データが企業境界の外に出ます (伝送時に暗号化されていても同様です)。セルフホストモデルでは、データはネットワーク外に出ません。ファインチューニングでは、学習データを学習プラットフォームにアップロードする必要があります (PAI は VPC 内での学習をサポートし、リスクを低減できます)。RAG では、ナレッジベースデータの保存場所に関するコンプライアンスを評価する必要があります。

次の場合はモデル戦略を再評価してください。モデル API コストが 3 か月連続で予算を 20% 以上超過した場合、新世代モデルが 50% を超える価格性能比の改善を提供した場合、規制更新によりデータプライバシー要件が強化された場合、またはセルフホスティングの運用チームがセキュリティパッチに追随できなくなった場合です。

純粋なベクトル検索、ハイブリッド検索、グラフ拡張 RAG

純粋なベクトル検索 は、RAG システムの最も基本的な形です。ドキュメントをチャンクに分割し、埋め込みベクトルに変換してベクトルデータベースに格納します。検索時には、ユーザーのクエリをベクトル化して近似最近傍探索を行い、意味的に最も近いドキュメントチャンクをコンテキストとして返します。この方法は実装が簡単で、非構造化テキストに対して有効に機能します。質問と回答が意味的に関連する FAQ 形式の Q&A や、簡易なドキュメント検索 (製品マニュアルの参照など) に適しています。Model Studio (Bailian) のナレッジベースのデフォルトモードはベクトル検索です。

ただし、純粋なベクトル検索には明確な制約があります。意味的類似度しか捉えられないため、完全一致が必要な要件 (たとえば SKU-20240315 のような特定の製品 ID を検索する) に弱く、構造化メタデータによるフィルタリング (たとえば「2026 年に公開されたドキュメントのみ表示」) を活用できず、エンティティ間の関係理解が必要な複雑な質問でも性能が低下します。

ハイブリッド検索 は、ベクトルのセマンティック検索と従来のキーワード検索 (BM25 など) を組み合わせ、さらにメタデータフィルタリングを追加します。両方の検索を同時に実行し、その後リランカーモデルで結果を統合して再ランキングします。このアプローチは、意味理解と完全一致の両方を提供できるため、エンタープライズ RAG システムの主流の選択肢です。明確なメタデータを持つ社内ドキュメントライブラリ、概念と厳密なパラメータの両方を含む技術ナレッジベース、セマンティックな FAQ と完全一致 ID の両方を含むカスタマーサポートのナレッジベースに適しています。Model Studio (Bailian) のナレッジベースはハイブリッド検索モードをサポートし、AnalyticDB for PostgreSQL が基盤となるベクトルと全文インデックスの統合機能を提供します。

グラフ拡張 RAG は、ハイブリッド検索にナレッジグラフを追加し、エンティティ間の関係を明示的にモデル化します。質問がマルチホップ推論を伴う場合 (たとえば「サプライヤー A の部品のうち、田中一郎が管理するプロジェクトで使用されているものはどれですか？」)、セマンティック検索ではドキュメント間の情報を結び付けにくくなります。一方、ナレッジグラフでは、エンティティ関係パスをトラバースすることで迅速に答えを見つけられます。このアプローチは、複雑なエンティティ関係を持つ領域 (サプライチェーン管理や学術引用ネットワークなど) や、マルチホップ Q&A に適しています。グラフ拡張 RAG の複雑さと保守コストは大幅に高くなるため、ハイブリッド検索で精度要件を満たせない場合にのみ検討してください。

マネージドナレッジベースと自作パイプライン

Model Studio (Bailian) のナレッジベース機能は、すぐに使える RAG パイプラインを提供します。ドキュメントをアップロードすると、プラットフォームが自動解析、インテリジェントなチャンク化、ベクトル化、インデックス構築、検索 API を処理します。エンジニアリング工数はほぼ不要で、RAG の実現可能性を迅速に検証する場合や、小～中規模のナレッジベースに最適です。利点は、開発効率が高いこと (数分でセットアップ可能)、運用負荷がゼロであること、Model Studio (Bailian) アプリケーションとシームレスに統合できることです。

一方、マネージドナレッジベースではカスタマイズに制約があります。チャンク化戦略を細かく制御できず (たとえば、コードと表で異なるロジックを適用するなど)、前処理パイプラインにカスタムのクレンジング手順 (データマスキングや用語正規化など) を挿入できず、検索戦略も大幅にはチューニングできません。RAG の品質要件が極めて高い場合、自社でデータパイプラインを構築する必要が生じることがあります。

自作パイプライン とは、データ取り込みから検索サービスまでのチェーン全体を自社で構築することです。これには、ドキュメント解析 (PDF、Word、Web ページ)、前処理 (クレンジング、マスキング、メタデータ抽出)、チャンク化 (意味段落、固定サイズ、階層など)、埋め込み (DashScope モデルの呼び出し、または自社学習モデル)、インデックス格納 (AnalyticDB for PostgreSQL、Lindorm、Elasticsearch など)、およびカスタムのリコールと再ランキングのロジックを備えた検索サービスが含まれます。DataWorks を使用して、このパイプラインのスケジュール実行と増分更新をオーケストレーションできます。

重要なのは、チームの注力領域です。チームが 5 人未満で、AI がコア事業ではない場合は、マネージドナレッジベースから開始してください。専任のデータエンジニアがいて、RAG の品質がコアの差別化要因である場合は、完全な制御を得るために自作パイプラインを構築します。その中間の場合は、まずマネージドナレッジベースから始め、ボトルネックを特定してから必要なコンポーネントだけを自作してください。

データ鮮度とアーキテクチャへの影響

ナレッジベースに求められるデータの即時性は、データパイプラインアーキテクチャの複雑さを直接決定します。

• リアルタイム更新 (秒～分)：注文ステータスや在庫情報など、急速に変化するデータに適しています。アーキテクチャはストリーミングパイプラインであり、メッセージキュー (Kafka や RocketMQ など) を使用してデータ変更イベントをリッスンし、増分ベクトル化とインデックス更新をトリガーします。これは最も複雑な選択肢であり、整合性、順序入れ替わりイベント、重複メッセージへの対応が必要になります。

• ニアリアルタイム更新 (時間単位)：ニュース、告知、製品ドキュメントなど、中程度の更新頻度のコンテンツに適しています。アーキテクチャはスケジュールジョブです。DataWorks を使用して時間単位または日次のデータ同期タスクを設定し、増分データをバッチで処理してインデックスを更新します。複雑さは中程度で、多くのエンタープライズナレッジベースにとって現実的な選択肢です。

• 静的または低頻度更新 (週～月)：規制、研修資料、過去アーカイブなど、ほとんど変化しないコンテンツに適しています。アーキテクチャは手動または定期的なフルリビルドです。すべてのドキュメントを一括処理し、大きなコンテンツ変更がある場合にのみ手動でリビルドをトリガーします。これは最も単純な選択肢であり、Model Studio (Bailian) のナレッジベースのデフォルトモードで十分にサポートされます。

トレードオフ：再現率と適合率、レイテンシー、ストレージコスト

データアーキテクチャ設計では、常に次の 3 者間のトレードオフを扱う必要があります。

• 再現率と適合率 を改善する手法 (チャンクサイズの縮小、高次元の埋め込みベクトル、リランカーの追加、検索候補の増加など) は、通常ストレージコストと検索レイテンシーを増加させます。1 億件の 1536 次元ベクトルを持つインデックスには約 600 GB のストレージが必要で、検索 1 回あたり 50～100 ms かかる場合があります。

• レイテンシー を下げる手法 (インメモリのベクトルインデックスの使用、検索候補の削減、再ランキングロジックの簡素化など) は、再現率と適合率を犠牲にする可能性があります。インデックスを完全にメモリへロードすると検索レイテンシーを 1 桁ミリ秒まで下げられますが、メモリはディスクストレージよりはるかに高価です。

• ストレージコスト を抑える手法 (ベクトル次元数の削減、量子化圧縮の使用、チャンクサイズを増やしてベクトル総数を減らすなど) は、再現率と適合率に悪影響を与える可能性があります。直積量子化 (PQ) はベクトルストレージを元の 1/4 に圧縮できますが、一定の精度低下を伴います。

アーキテクトは、シナリオに基づいて優先順位を設定する必要があります。ユーザー向けのリアルタイム Q&A では、低レイテンシー (P95 < 200 ms) と基礎的な精度を優先すべきです。アナリスト向けの調査アシスタントでは、レイテンシーが数秒でも再現率と適合率を優先すべきです。膨大なドキュメントストアのアーカイブ検索では、低ストレージコストを優先すべきです。

次の場合はデータアーキテクチャを再評価してください。RAG システムの精度が継続的に業務要件を下回る場合 (純粋なベクトル検索からハイブリッド検索、またはグラフ拡張への移行が必要な可能性がある)、ナレッジベースの増大により検索レイテンシーが SLA を超過する場合、またはデータ鮮度要件が日次から分単位へ変化した場合です。

シングルエージェントとマルチエージェントオーケストレーション

シングルエージェント アーキテクチャは最も直接的な実装です。1 つのエージェントが、意図理解、ツール呼び出し、応答生成に必要なすべての能力を持ちます。これは、タスク範囲が明確で限定的であり、必要なツール数が 10 未満で、複雑なロールプレイやプロセス調整が不要な場合に適しています。たとえば、カレンダー管理エージェントは「明日の 15 時に田中一郎さんと会議を設定して」という依頼を理解し、カレンダー API を呼び出して空き枠を見つけ、招待を作成し、通知を送信します。これらはすべて 1 つのエージェントで処理できます。

タスクの複雑さが単一エージェントの能力を超える場合、マルチエージェントオーケストレーション が必要になります。その兆候には、異なる専門知識とツールセットが必要であること (コード解析用のエージェントとドキュメント理解用のエージェントなど)、サブタスクを並列実行して結果を集約する必要があること、役割間の牽制が必要であること (計画を作るエージェントとコンプライアンス観点でレビューするエージェントなど)、または単一エージェントのコンテキストウィンドウが小さすぎてタスク情報を保持しきれないことが含まれます。

一般的なマルチエージェントオーケストレーションのパターンには、中央のエージェントがタスクを分解して複数の専門エージェントへ配分する Orchestrator Pattern、あるエージェントの出力が次のエージェントの入力になる Pipeline Pattern、複数のエージェントが異なる角度から問題を分析して「議論」し、最適解に収束させる Debate Pattern があります。

ツール呼び出し、ワークフロー駆動、自律型エージェント

エージェントの内部アーキテクチャは、自律性の度合いに基づいて 3 つに分類できます。

• ツール呼び出しエージェント は、モデルのツール呼び出し能力を中心に設計されます。モデルが、いつどのツールを呼び出すか、結果をどう解釈するかを判断します。実行経路は動的で、各ステップでコンテキストに基づいて次のアクションをモデルが決定します。これは、すべての実行経路を事前定義できないオープンエンドな問題空間で、柔軟性が必要な場合に適しています。たとえば、汎用データ分析アシスタントは、質問に応じて、どのデータソースを参照し、どの分析を実行し、どう可視化するかを動的に判断する必要があります。

• ワークフロー駆動エージェント は、事前定義されたフローチャートを実行します。各ノードは、モデル呼び出し、ツール呼び出し、条件分岐、手動承認などの決定的なステップです。分岐を含む実行経路は設計時に定義されます。これは、固定プロセスと厳格なコンプライアンス要件を持つ業務シナリオ (融資審査：与信チェック → 収入確認 → リスク評価 → 最終判断、医療トリアージ：症状収集 → 緊急度評価 → 診療科推薦など) に適しています。

• 自律型エージェント は、最も高い自律性で動作します。自らサブゴールを設定し、実行ステップを計画し、実行中に内省して戦略を調整できます。これは、「この業界の競合環境を分析してレポートを作成して」のような複雑で長時間の調査タスクや、不確実性の高い探索的タスクに適しています。一方、自律型エージェントはリスクも最大です。制御されていないエージェントは無限ループに陥ったり、高額な API コストを発生させたり、意図しない操作を実行したりする可能性があります。明確な終了条件 (最大ステップ数、トークン予算、タイムアウト) とチェックポイント (重要な判断の前に手動確認で一時停止するなど) を実装する必要があります。

同期実行と非同期実行

エージェントの実行モードは、タスクの所要時間とユーザーの対話モデルに依存します。

同期実行 は、短時間 (数秒以内) で完了するタスク向けです。ユーザーがリクエストを送信し、エージェントが処理し、結果を直接返します。これは、多くの会話シナリオにおけるデフォルトモードです。主な考慮事項には、タイムアウトで総実行時間を制御すること、応答しない API がリクエスト全体をブロックしないようにツール呼び出しにレイテンシー制約を設けることが含まれます。

非同期実行 は、完了までに長時間かかるタスク向けです。ユーザーはタスクを送信した後に離脱でき、完了時に通知を受け取ります。たとえば「過去 3 か月の売上データを分析して週次レポートを作成して」は数分かかる可能性があります。非同期アーキテクチャには、タスクステータス追跡 (保留、実行中、完了、失敗)、ユーザーに状況を伝える進捗報告、失敗時のデータ損失を防ぐ中間結果の永続化、結果通知 (メッセージ、メール、または UI プッシュ) が必要です。

ハイブリッドモデル は両者を組み合わせます。エージェントはまず同期的に簡易な暫定応答 (たとえば「データを分析中です。約 3 分で完了する見込みです」) を返し、その後、詳細分析を非同期で実行して完了時に完全な結果をプッシュします。

総所有コスト (TCO)

AI システムの総所有コスト (TCO) は、クラウドリソース料金をはるかに超えます。完全な TCO 評価には、次を含める必要があります。

• 開発コスト：ゼロから構築するためのエンジニアリング工数です。SaaS ではほぼゼロ、PaaS ではアプリケーション層の開発 (人週)、IaaS ではフルスタック開発 (人月～人年) が必要です。

• 運用コスト：監視、トラブルシューティング、更新など、保守に必要な継続的な人的工数です。SaaS ではベンダーが対応し、PaaS では責任が分担されます (Alibaba Cloud がプラットフォームを管理し、利用者がアプリケーションを管理します)。IaaS ではすべて利用者側の責任です。

• モデル更新コスト：進化する基盤モデルに追随するための投資です。SaaS の更新は通常自動です。PaaS では設定変更で新モデルへ切り替えられます。IaaS では、ファインチューニング済みモデルの再学習を含め、置き換え、評価、再デプロイのプロセス全体を管理する必要があります。

• コンプライアンスコスト：規制要件を満たすための工数です。SaaS ベンダーが対応している場合が多いものの、自社ユースケースをカバーしているか確認する必要があります。PaaS はプラットフォームレベルのコンプライアンスを提供しますが、アプリケーションについては利用者側の責任です。IaaS では、コンプライアンス対応はすべて利用者側の責任です。

• 機会費用：ある選択肢を選ぶことで失われる潜在的な利益です。AI システムを数か月かけて構築することは、リリースの遅延を意味します。変化の速い市場では、6 か月の遅れが先行者利益の喪失につながる可能性があります。この隠れたコストは過小評価されがちです。

• 撤退コスト：将来、新しいソリューションに移行する際の費用です。SaaS ベンダーと深く統合するとデータ移行が困難になる場合があります。高度にカスタマイズされた自社構築システムは、アーキテクチャのロックインにより移行が難しくなる場合があります。撤退コストを下げるために、適切な抽象化レイヤーを意識して設計してください。

チーム能力と推奨パス

チームの AI エンジニアリング能力は重要な制約です。技術的に最適な解がチーム能力を超えている場合、実務では最悪の選択になります。

• 専任の AI/ML チームがいない：業務系開発者が AI 対応も担い、専任のアルゴリズムエンジニアや MLOps ロールがありません。推奨パス：まず、SaaS ソリューションで要件を満たせるか評価してください。満たせない場合は、Model Studio (Bailian) のローコード機能でアプリケーションを構築します。プラットフォームのエージェントオーケストレーション、ナレッジベース管理、モデル評価機能を活用して、専門性の障壁を下げます。基盤のエンジニアリングではなく、業務シナリオとプロンプト最適化に注力します。

• 小規模 AI チーム (3～10 人)：少数のアルゴリズムエンジニアと AI アプリケーション開発者がいて、一定のモデル評価とデータ処理能力があります。推奨パス：Model Studio (Bailian) を中核基盤として使用します。標準機能で十分な箇所は迅速に提供し、コアの差別化要因にのみ深いカスタマイズ投資を行います。選択的なモデルのファインチューニングには PAI プラットフォームを使用し、カスタムデータパイプラインの構築には DataWorks を使用します。自社で構築すべき部分と、プラットフォームに残すべき部分の切り分けに注力します。

• 大規模 ML エンジニアリングチーム (10 人以上)：研究、学習、推論最適化、データエンジニアリング、MLOps を含む、完全な AI R&D 組織があります。推奨パス：ハイブリッドな IaaS+PaaS アプローチです。IaaS 上でコアのモデル能力を自社構築 (ACK 上でカスタム推論サービスをデプロイし、PAI で大規模学習を実行) し、最大限の制御とコスト優位性を得ます。周辺要件には PaaS の機能 (Model Studio (Bailian) のコンテンツセーフティなど) を利用して効率を高めます。競争優位の堀を築く領域にエンジニアリングリソースを集中します。

チーム規模にかかわらず、共通の推奨は、Model Studio (Bailian) プラットフォームで概念実証 (PoC) を開始し、最小限の投資でビジネス価値を検証することです。PoC により AI ソリューションが実際の業務課題を解決できると確認できたら、チーム能力と長期戦略に基づいて、プラットフォームに留まるか自社構築へ進化させるかを判断します。早すぎる自社構築への投資は、AI プロジェクトでよくあるリソースの浪費です。多くの企業は、カスタムサービスの構築に数か月を費やした後で、ビジネスケースが成立しない、またはプラットフォームソリューションで既に要件を満たしていた、という事実に気付きます。

アーキテクトは、各意思決定の根拠と前提を文書化する必要があります。これにより、チーム拡大、事業成長、新モデルのリリース、規制更新など、外部条件が変化した際に迅速に再評価して調整できます。AI アーキテクチャは一度きりの設計ではなく、ビジネスとともに進化する継続的な最適化プロセスです。

次の場合は技術パスを再評価してください。PaaS プラットフォームの制約が繰り返し要件を阻害する場合 (IaaS へ移行すべきシグナル)、SaaS ソリューションのカスタマイズコストが自社構築コストに近づき始めた場合、または 6～12 か月の期間でチームの AI エンジニアリング能力が大きく向上した場合です。