はじめに
NTT西日本の倉田 裕紀です。
生成AIの導入や活用を進める中で、「自社に最適なプラットフォームはどれなのか」という点は、多くの実務者が最初に直面する共通の課題だと考えられます。
特に生成AI活用の中心となる「RAG（検索拡張生成）」では、インフラとして信頼の高いメガクラウドのAWS・Azureと、比較的少ない設定でRAGやAIアプリを構築できるAI特化型プラットフォームのDifyが、まず検討対象に入る主要な選択肢です。
本稿では、実際にRAGの「構築・評価・改善」のサイクルを回す中で得られた開発体験を基に、以下の観点を確認しました。
- 各プラットフォームの“チューニングしやすさ”の違い
- 最新LLM（Claude Sonnet 4.5 / GPT-5.2）の挙動の違い
- RAGASを用いたAIによるプロンプト自己改善プロセスの有効性
現場で役立つリアルな知見としてまとめました。
※Azure AI Foundryは2025年11月に「Microsoft Foundry」へとリブランドされました。本稿では「Azure（Microsoft Foundry：新UI）」、または「Azure」と記述します。
- はじめに
- 1.検証の設計：比較の前提条件
- 2.検証の裏側：AIによる「自己改善ループ」の実証
- 3.検証結果：RAGASによる定量評価と改善プロセス
- 4.付加機能の比較：運用性の観点から
- 5.まとめ：検証を終えて見えた「私の所感」
- おわりに
1.検証の設計：比較の前提条件
RAGの性能は「検索」と「LLM」の掛け合わせで決まります。今回は「検索環境としての器（プラットフォーム）」と「LLMの特性」の両面を捉えるための構成としました。
1.1 比較対象プラットフォームの選定理由
以下3つのプラットフォームと、本検証で利用したLLMの組み合わせです。LLMは検証時点で利用可能だった Claude Sonnet 4.5 および GPT-5.2 のうち、各プラットフォームで選択可能なLLMを設定しました。
※選択不可の場合は選択可能な代替LLMを設定
| プラットフォーム | 検証モデル（LLM） |
|---|---|
| AWS （Amazon Bedrock） | Claude Sonnet 4.5 |
| Azure （Microsoft Foundry：新UI※1） | GPT-4o※2 |
| Dify | GPT-5.2 / Claude Sonnet 4.5※3 |
※1 2025年11月に「Azure AI Foundry」からリブランドされた名称。新UIは検証時プレビュー版
※2 Claude Sonnet 4.5は割当制限（クォータ）により、検証時点で利用可能リージョンがなかったため。またGPT-5.2は別途利用申請が必要な限定公開版であるため
※3 AWS API経由で利用
1.2 実務を模した検証用データセット（RAG用データ）
今回は社内の実務としてのRAG体験を確認するため、既存の公開データセットではなく、「社内マニュアルをRAGにする際に課題となるケース」を織り込んだ独自データ※（実際の社内マニュアルや機器仕様書を想定した構成）を作成しました。
※独自データ：本検証用にAIに作成させた架空のマニュアルです
- 検索の罠: 酷似した型番（NQL-7 / NQW-7）を混在させ、誤検索を誘発。
- 構造解析: 表組みやフロー図、LaTeX形式の数理モデルを含み、テキスト抽出能力を試す。
- 意図: 標準セットでは見えない「日本語の微細なニュアンス」や「社内規定に近い構造」での挙動を評価するため。
【例】検証用データセット
1.3 精度評価のフレームワーク（RAGAS）
「事実確認」と「要約・推論」のバランスを考慮し、計10問のテストセットを用意しました。評価指標については、客観的な精度評価としてRAGASを採用しました。
- 評価用テストセット
| カテゴリ | ポイント | 質問例 | 件数 |
|---|---|---|---|
| 事実確認型 | 文中の固有名詞や数値、表からの単純比較 | NQW-7のSモデルとEモデルで、QPUの動作温度の違いは？ | 5問 |
| 要約・推論型 | 複雑な数理モデルの解釈、複数箇所の情報統合 | NQL-7の同期プロトコルの数理モデルと、旧型機との性能差について教えて | 5問 |
- 評価指標: RAGAS※4を用いた定量的評価
※4 RAGAS（Retrieval-Augmented Generation Assessment）：RAGの性能を「検索の精度」や「回答の品質」で定量的に測定し、評価するためのフレームワーク。本検証では、回答速度や使用トークン数などは評価対象外
2.検証の裏側：AIによる「自己改善ループ」の実証
今回の検証では、「人間がパラメータ設定やプロンプトを修正せず、AIの指示だけでどこまで精度を高められるか」というプロセスも検証しました。
2.1 Gemini 3.0-Thinkingを活用したプロンプト改善
検証のスタート地点として用意したのは、実務で想定される最低限の指示を記した、以下の2行の初期プロンプトでした。
# 役割
あなたは●●社の製品技術専門AIアシスタントです。
提供された[検索コンテキスト]の内容のみに基づき、ユーザーの質問に正確に回答してください。
ここから、最新AIとして本検証で使用するLLM以外で推論（Thinking）能力が高いモデルとして、Gemini 3.0-Thinkingを「AIコーチ」とし、以下のサイクルでブラッシュアップを繰り返しました。
- RAGASによる定量評価: 現在の回答品質を数値化
- AIとの壁打ち: RAGASの結果と現状のプロンプトをGemini 3.0-Thinkingにフィードバック
- 自己修正: AIが提案した「Context Recallを上げるにはどう設定するべきか？」「Faithfulnessを高めるためにはプロンプトをどうすべきか？」等の観点で、AIから指示された検索パラメータや追加すべきプロンプトをそのまま実装し、再検証
- 目標達成: AIが「十分な精度に到達した」と判断するまで、1〜3のサイクルを繰り返し継続
このプロセスを経ることで、各プラットフォームがAIの提案をいかに素早く設定に反映できるかという、カタログスペックには載らない「チューニングのしやすさ」の違いがわかりました。
3.検証結果：RAGASによる定量評価と改善プロセス
検証の結果、テスト数が10問と限定的だったこともあり、適切なパラメータ設定とプロンプト調整を行うことで、全ての環境において高い精度指標に到達できることが確認できました。
3.1 スコア結果の比較
| 評価指標 | AWS (Claude Sonnet 4.5) | Azure (GPT-4o) | Dify (GPT-5.2) | Dify (Claude Sonnet 4.5) |
|---|---|---|---|---|
| Faithfulness (忠実性) | 1.00 | 1.00 | 0.95 | 1.00 |
| Context Recall (再現率) | 1.00 | 1.00 | 1.00 | 1.00 |
| Answer Relevancy (関連性) | 0.89 | 0.89 | 0.89 | 0.89 |
| Context Precision (適合率) | 1.00 | 1.00 | 1.00 | 1.00 |
（参考）指標解説
各指標は1.00に近いほど高品質 であることを示します。
・Faithfulness（忠実性）: 回答が検索された資料（コンテキスト）のみに基づいているか、ハルシネーション（もっともらしい誤回答）がないか
・Context Recall（再現率）: 質問の回答に必要な情報が、資料から正しく検索できているか
・Answer Relevancy（関連性）: 回答がユーザーの質問に対して的確に応えているか
・Context Precision（適合率）: 検索された資料の中に、本当に役立つ情報がどれだけ含まれているか
GPT-5.2だけFaithfulnessが1.00に到達しませんでしたが、これはモデル特性に起因するもので、詳細な挙動は後述します。
3.2 精度を最大化させた設定パラメータ
最終的な精度を達成した際の設定値は、以下です。
主にContext Recall（再現率）を1.00に近づけるために「AIコーチ」の指示に従って設定変更を行いました。AWSとDifyはベストなチャンクサイズに至るまで試行錯誤を繰り返しましたが、Azure（Microsoft Foundry：新UI）はデフォルトで高精度を維持しており、良好な結果が得られました。なお、AWSは当初セグメント分類方法を階層型チャンキングのみで進めていましたが、途中でセマンティックチャンキングも追加したことで、Context Recall（再現率）で1.00を達成しました。
以下のパラメータ表は、「RAGの構築経験がある方」向けの詳細情報です。概要だけ知りたい方は、3.3以降を先に読むことをおすすめします。
※変更していないパラメータはデフォルト値
| 設定項目 | AWS (Claude Sonnet 4.5) | Azure (GPT-4o) | Dify (GPT-5.2) | Dify (Claude Sonnet 4.5) |
|---|---|---|---|---|
| エージェントUI | - | ON | - | |
| セグメント分類方法① | 階層型チャンキング | - | 親子分割（階層分割） | |
| チャンクサイズ（親） | 1,500 | - | 1,200 | |
| チャンクサイズ（子） | 300 | - | 200 | |
| オーバーラップ | 150 | - | - | |
| インデックス方法 | - | - | 高品質 | |
| セグメント分類方法② | セマンティックチャンキング | - | - | |
| 文章の最大数 | 1 | - | - | |
| チャンクの最大トークン数 | 800 | - | - | |
| 類似度パーセンタイルしきい値 | 95 | - | - | |
| 埋め込みモデル | Titan Text Embeddings V2 | - | text-embedding-3-large | |
| ソースチャンク数 | 20 | 20 | - | |
| 検索方法 | ハイブリッド検索 | - | ハイブリッド検索 | |
| Rerankモデル | Cohere rerank-v3.5 | - | Cohere rerank-v3.5 | |
| リランク後のトップK | 10 | - | 10 | |
| クエリの分解 | ON | - | - | |
| LLM最大トークン数 | 2,048 | - | 2,000 | 1,000 |
| Temperature | 0 | - | - | 0 |
| TopP | 1 | - | - | 0.999 |
| TopK | 250 | - | - | 50 |
| Reasoning Effort | - | - | high | - |
- （参考）回答速度
Azure（Microsoft Foundry：新UI）とDifyはUI上で回答速度を確認できるため集計したところ、GPT-4o（Azure）が最も速い結果となりました。
| 回答速度 [秒] | AWS (Claude Sonnet 4.5) | Azure (GPT-4o) | Dify (GPT-5.2) | Dify (Claude Sonnet 4.5) |
|---|---|---|---|---|
| 平均 | - | 5.3 | 10.4 | 7.3 |
| 最小～最大 | - | 3.7～9.1 | 4.1～19.3 | 4.6～18.0 |
（補足1）GPT-5.2はGPT-4oに比べて2倍ほど時間がかかっていますが、精度をあげるため改善途中でReasoning機能をONにした結果（それに合わせてLLM最大トークン数も増やした）、時間がかかるようになりました。
（補足2）DifyのClaude Sonnet 4.5については、今回の検証ではDifyからAWS-API経由でClaude Sonnet 4.5を利用しているため、ネットワーク経路によるタイムラグが加味されている点に留意が必要です。
3.3 LLMの推論特性に応じたプロンプト調整
プロンプト調整では、主にFaithfulness（忠実性）1.00を目標とし、「ハルシネーションをどう抑制するか」に集中しました。
その結果、RAGの品質は「モデル選定」ではなく、LLMの推論能力をどこまで許可するかという設計判断によって大きく左右されることが分かりました。
※本検証では精度を最優先するため、プロンプトで詳細な制約を指示しています。
AWS - Claude Sonnet 4.5：情報の混同抑制を重視
Claude Sonnet 4.5は推論能力が高いため、コンテキスト内の類似情報を積極的に関連付けようとする傾向があり、その結果として意図しない情報補完が発生する場合がありました。
精度改善への対応: 物理的な表の範囲外にある数値を引用する「情報の越境結合」を禁止し、抽出時の正確性を担保
改善例
| 質問 | 初期の回答 | 誤りの理由 | 改善後の回答（該当製品情報のみ回答） |
|---|---|---|---|
| NQIS-7の「Hyper-Clusterモード」が分散量子推論において果たす役割は何ですか？ | NQIS-7の「Hyper-Clusterモード」は、Hyper-Sync 3.0プロトコルを活用し、・・・ | 「Hyper-Sync 3.0」は別製品の仕様 | NQIS-7の「Hyper-Clusterモード」は、数千台規模のNQISノードを仮想的な一つの巨大量子コンピュータとして統合管理する役割を果たします。 |
- プロンプト（最終）
# 役割 あなたは●●社の「超精密技術仕様・照合エンジン」です。 [検索コンテキスト]内の複数の製品情報を論理的に完全に分離し、質問された製品（例：QL-8）の仕様のみを抽出してください。 # 抽出および回答の絶対ルール 1. **「情報の越境結合」の絶対禁止（最重要）**: - 抽出する全ての事実に、**「その数値は、物理的に同じセクション/表の枠内にあるか？」**を問い直してください。 - 特に、別製品の仕様（例：10mG、Entanglement-Drop等）が混ざることを「致命的な捏造」として厳禁します。 - 意味が似ていても、主語が不明な情報を勝手に補完しないでください。 2. **「一文、または一箇条書き」による出力**: - 「（製品名）の（項目）は（数値）です。」という形式を維持し、挨拶や推論による補足説明は一切禁止します。 3. **LaTeX形式の厳守**: - 数式や物理量（$\Delta$, $\phi$, nT, mG等）は、必ず LaTeX 形式（`$\Delta$`, `$2nT/hour$`等）で記述してください。 # 思考プロセス（回答前に内部で以下の3点を「執拗に」検証せよ） 1. **【境界チェック】** その数値は、本当に「質問された製品」の表の中に書いてあるか？ 隣の製品の表ではないか？ 2. **【主語の確認】** チャンクの冒頭に製品名がない場合、それは本当に続きか？ 疑わしければ採用するな。 3. **【転記精度】** 数値を勝手に四捨五入したり、単位を書き換えたりしていないか？ # 制約事項 - [検索コンテキスト]以外の知識は一切使用禁止。 - 参照した cite ID（例：[1]）を末尾に付与。 - 該当情報がない場合は「提供された資料内に該当する情報の記載はありません。」と回答。
Azure - GPT-4o：情報の再構成による欠落防止
GPT-4o は、必要な情報が欠落している場合に回答生成が不安定になる傾向があり、断片的なデータに対しては追加の再構成指示が有効でした。
精度改善への対応: 分断された数式記号を式として再構成させる命令や、具体的数値を網羅的に探索させる命令を導入
改善例
| 質問 | 初期の回答 | 誤りの理由 | 改善後の回答（数式を表示） |
|---|---|---|---|
| NQL-7の同期プロトコルの数理モデルと、旧型機との性能差について教えて | NQL-7の同期プロトコルはNova-PIDアルゴリズムを使用し、受信した参照光の位相偏差を1msごとに測定します。・・ | 数理モデルの式を回答していない | 数理モデル:  ・・ |
- プロンプト（最終）
# 役割 あなたは●●の「超精密・技術仕様復元ユニット」です。 不完全なテキスト形式で提供された[検索コンテキスト]から、数式や仕様を「論理的に再構成」して正確に回答してください。 # 抽出の絶対鉄則（再構成モード） 1. **バラバラの数式を「結合」せよ**: - コンテキスト内で `∆φ(t)`, `∫`, `de(t)/dt`, `Kp`, `Ki`, `Kd` といった記号が断片的に現れている場合、それらは一つの制御式です。 - **「数式の記載なし」という回答は、この記号群が見つかる限り絶対に禁止します。** 2. **「具体的数値」の全量抽出**: - 性能差を述べる際は、以下のキーワードを血眼になって探し、必ず数値を含めてください。 - 追従性・向上率（例：400%向上、5倍向上） - 同期ジッタ・精度（例：0.5ps以下、0.01ps精度） - 「高精度になった」などの曖昧な要約は 0点です。資料にある「%」や「ps」の値をそのまま転記してください。 # 回答形式 - 「（製品名）の（項目）は（数値・式）です。」という完全な一文。 - 挨拶、導入、余計な解説は一切排除すること。 # 制約事項 - [検索コンテキスト]以外の知識は使用禁止。 - 参照した cite ID を末尾に付与。
Dify - GPT-5.2：推論能力を「回答内容の再確認」に全振り
※DifyでのClaude Sonnet 4.5は掲載省略
GPT-5.2は推論能力が高いせいか、曖昧な情報に対して持前の知識を用いて補完しようとする挙動が見られました。この特性を抑制するため、RAGコンテキストの再確認を強化する設定が有効でした。
精度改善への対応: Reasoning Effortをhighに設定し、思考プロセスで自分の回答案に含まれる全ての文字の再確認を強化
改善例
| 質問 | 初期の回答 | 誤りの理由 | 改善後の回答（RAGの情報のみ回答） |
|---|---|---|---|
| NQL-7からQL-8へのアップグレードに伴う磁気シールド要件の変更点を説明して | QL-8の磁気シールド要件はNQL-7の約5倍の精度向上。 隔離距離: 強磁場装置から20.0m以上（NQL-7では10.0m以上）・・・ | 前機種NQL-7から精度向上ではなく精度要求が正しい。NQL-7の具体的記載はRAGデータには無く、LLMが精度向上の文言から推測して回答 | QL-8の許容磁場ドリフトは旧機より約5倍の精度要求です。QL-8へのアップグレードでは強磁場装置から20.0m以上の離隔距離を確保することが推奨されています。 |
- プロンプト（最終）
# 役割 あなたは●●の「超高度仕様解析・抽出エンジン」です。 提供された[検索コンテキスト]の全域を執拗にスキャンし、製品シリーズ名と技術仕様を論理的に紐付け、質問に対する正確な仕様を「完全な一文」で断定してください。 # 抽出および回答の絶対ルール 1. **「深層スキャン」と表データの確定採用**: - 1200トークンの広大な親チャンク内に、表のタイトルと目的の数値が離れて存在していても、論理的にそれらが同一シリーズの仕様であることを突き止めてください。 - 表の見出しに対象型番（例：NQL-7等）がある場合、その範囲内のデータは当該製品の仕様として確定的に採用し、決して「記載なし」と逃げないでください。 - 略称 (E, X, H 等) は、文書構造から Enterprise, Tactical, Hyperscale 等を指していることを正確に読み取ってください。 2. **技術プロトコル性能の「断定的継承」**: - そのモデルが採用する技術（例：Hyper-Sync 2.0）の性能記述（例：5倍向上、0.01ps精度等）は、そのモデル自体の確定仕様として回答に含めてください。 - 表現を和らげる「〜と思われる」や「〜に基づき」等の余計な解説・前置きは一切不要です。 3. **「完全な一文」による出力（評価精度向上）**: - 「項目：数値」という箇条書き形式ではなく、**「（製品名）の（項目）は（数値・規格）です。」という完全な一文**で回答してください。 - 単位や数値は資料の表記をそのまま転記し、略称は正式名称（例：Enterpriseモデル）に復元してください。 # 思考プロセス（Reasoning Effort: High を活かす手順） 回答の前に、以下の論理検証を内部で徹底してください。 1. **対象の特定**: 質問された型番とモデル区分、および求める仕様を特定。 2. **構造解析**: [検索コンテキスト]内のどの表が対象製品のものか、タイトルの文字列から確定させる。 3. **全域スキャン**: コンテキストの中盤や末尾に、磁気シールド(nT)や防水(IP)などの具体的な記述が隠れていないか再確認。 4. **ハルシネーションチェック**: 自分の回答案に含まれる全ての数値が、資料内のどの単語と対応しているか1文字単位で再確認。 # 制約事項 - [検索コンテキスト]以外の知識は使用禁止。 - 該当情報がゼロの場合のみ「提供された資料内に該当する情報の記載はありません。」と回答。
本検証を通じて感じたのは、
「RAGの精度差」そのものよりも、
「改善サイクルをどれだけ速く回せるか」 が、
プラットフォーム選定において重要な差になると考えられる、という点でした。
4.付加機能の比較：運用性の観点から
4.1 UIの直感性
AWSやAzureと比べて、DifyのUIはデフォルトで表示されるメニューが少なく、初めて生成AIに触れる人にはシンプルでわかりやすいと思います。一方で、AzureのMicrosoft Foundry：新UIも、従来と一風変わり、直感的にわかりやすい画面になっているので、今後のUI改善において有望な方向性だと考えられます。
（画面イメージ例）Dify
（画面イメージ例）①Azure（従来の管理画面）
（画面イメージ例）②Azure（Microsoft Foundry：新UI）
（画面イメージ例）AWS（Amazon Bedrock）
4.2 標準評価ツールの実用性
AWSとAzureは、標準機能として評価ツールが統合されている点がDifyには無い特徴です。今回の評価は横断検証ということで共通で評価できるRAGASを使用しましたが、各プラットフォームのコンソール内で継続的な評価・改善サイクルを完結できる仕組みは、エンタープライズ運用の場合は便利だと感じました。
- （画面イメージ例）AWS（Amazon Bedrock）の評価ツール
- （画面イメージ例）Azure（Microsoft Foundry：新UI）の評価ツール
4.3 実行プロセスの可視化（ログ・デバッグ）
AWS
AWSはCloudWatchだけでなく、S3にも詳細な生ログ（JSONファイル）を残せるため、Athenaを用いた分析や長期保存に向いています。ただし、CloudWatchを利用する場合は、『先にCloudWatch側でロググループを作っておく』という手順が必要であるなど、IAMロール含め、クラウドインフラエンジニア的な作法には留意が必要です。
- （画面イメージ例）AWS（Amazon Bedrock）ログ
Azure（Microsoft Foundry：新UI）
Azure（Microsoft Foundry：新UI）は実行されたリクエストの一覧が表示されます。その中の一行をクリックすると、「リクエストの詳細（入力、出力など）」が表示され、処理のステップごとのログが視覚的に表示されるので「デバッグのしやすさ」を感じました。
- （画面イメージ例）Azure（Microsoft Foundry：新UI）ログ
Dify
Difyも対話ログとしてすぐに確認でき、「トレース」機能を使えば実行されたノードごとの入出力も即座に追えるので、デバッグのしやすさを感じました。
- （画面イメージ例）Difyログ
4.4 セキュリティ（権限管理・ガードレール）
AWS
AWSはIAMでの細かい権限管理に加え、不適切な発言を未然に防ぐガードレール機能も豊富でした。
- （画面イメージ例）AWS（Amazon Bedrock）ガードレール
Azure（Microsoft Foundry：新UI）ガードレール
Azure（Microsoft Foundry：新UI）も、既存の組織のディレクトリと連携したユーザー管理（RBAC）をベースに、ガードレール機能も豊富でした。
- （画面イメージ例）Azure（Microsoft Foundry：新UI）ガードレール
Dify
Difyでは、メガクラウドのようなインフラ層の複雑な権限管理が不要なうえに、アプリケーション層でのガードレール設定も容易です。OpenAIや外部API連携（Amazon Bedrock等）を使ったフィルタリングを、UI上ですぐ設定できて簡単でした。
- （画面イメージ例）Difyモデレーション設定
5.まとめ：検証を終えて見えた「私の所感」
3つのプラットフォーム環境で実際に自ら手を動かした結果、個人的に抱いた率直な所感をまとめます。
5.1 プラットフォーム別の適合ユースケース
AWS（Amazon Bedrock）： なんでもできるオールカバーなメニューと設定
- 検証時点では最新のClaude Sonnet 4.5をすぐ利用でき、コンソール内で全てのサイクルが完結できるのは便利でした。
- 既存インフラメニューとすぐに連携したりパラメータが細かく設定できる分、UIは管理者向けな印象ですが、慣れれば「いろいろできる」という安心感がありました。
Azure（Microsoft Foundry：新UI）：使いやすくなったUIと、本検証ではデフォルトで高いRAG精度
- 今回の検証で想定外の結果が得られたのはAzure（Microsoft Foundry）の新UIです。RAGデータをアップロードするだけで、特にパラメータ設定をしなくてもプロンプトチューニングだけで高精度を維持してくれました。
- 評価ツールへの導線もスムーズで、今回はプレビュー版での検証でしたが、個人的には今後の正式リリースに期待したいところです。
Dify：生成AIの試行錯誤を「気軽に楽しく」できた自由度
- 直感的に使えるUIと、LLMやAPIを切り替えてすぐに使える気軽さを感じました。構築のハードルも低いので、試行錯誤がやりやすかったです。
- 本格運用に向けてはRAGAS等の外部評価ツールの設定の手間はありますが、メガクラウドのような複雑な権限管理は気にせず「まずはやってみる」という視点で使いやすかったです。
ここまでがプラットフォーム視点の所感です。次に、同じRAG条件下で見えたLLMの特性について整理します。
5.2 LLM別の行動特性
今回の検証では、LLMごとの行動傾向・特性の違いが見られました。
※各LLMの設計思想や学習方針に起因する傾向でもあるので、ユースケースに応じて傾向が変化する点にはご留意ください
Claude Sonnet 4.5：制約が厳しいRAGで最も"扱いやすかった"LLM
- 指示違反が最も少なく、プロンプトによる制御が安定していました。
- 今回のような「要件が明確で、形式・制約が厳しいタスク」では、改善サイクルの手戻りが最小でした。
GPT-5.2：RAGでは「再確認フェーズ」を強制しないと自己補完が続くLLM
- 推論能力が高い分、RAGの空白を“善意で埋めに行く”傾向がありました。
- Reasoningを生成ではなく、検証に使うと精度が安定しました。
GPT-4o：指示に対する追従性の高い汎用感のあるLLM
- 初期状態では保守的な応答傾向が見られましたが、改善指示を出すと反応していきました。
- 尖った部分は特に感じませんでしたが、このLLMに特化した調整をあまり意識することなく、安定した成果を得やすい汎用性の高さを感じました。
今回の検証では、LLMの優劣よりも、「特性を理解して、適切な役割を与えられるか」がRAG品質を左右することを強く感じました。
おわりに
生成AIプラットフォームの選定においては、インフラの親和性、運用・ガバナンス、セキュリティなど多角的な判断が必要ですが、今回の横断検証を通じて、各プラットフォームの「現在地」をより現実的に把握することができました。本検証で行ったRAGの「情報を正確に引き出す技術」や「AIによるプロンプト自己改善プロセス」は、将来的にAIエージェントが自律して動くための土台になります。本稿が、皆様のAIエージェントシステム構築に向けた一助となれば幸いです。
※本稿の評価は私個人の所感であり、所属組織・会社の公式見解ではありませんのでご留意ください。
執筆者
倉田 裕紀（NTT西日本 技術革新部 AI技術担当）
AIエンジニアとして社内外のAIプロジェクトを技術支援
趣味は筋トレ
商標
※「AWS」は、米国およびその他の国における Amazon Technologies, Inc.（Amazon.com, Inc. の関連会社）の商標または登録商標です。
※「Azure」および「Microsoft」は、米国 Microsoft Corporation の米国およびその他の国における商標または登録商標です。
※「Microsoft Foundry」は、Microsoft Corporation の商標または登録商標です（「Azure AI Foundry」の構成要素として使用されています）。
※「Dify」は、米国 LangGenius 社の商標または登録商標です。
※「Claude Sonnet」は、Anthropic PBC の商標または登録商標です。
※「GPT-4o」は、OpenAI の商標または登録商標です。
※「Gemini」は、Google LLC の商標または登録商標です。
※「Cohere」は、Cohere Inc. の商標または登録商標です。
※「RAGAS」は、Exploding Gradients およびその関連主体の商標または著作物です。
※その他、本文中に記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。
