AI エージェント開発を支える MaaS としての Azure AI Foundry

2025/2/15『第5回 Azure Travelers 勉強会 沖縄の旅』の『AI エージェント開発を支える Model-as-a-Service (MaaS) としての Azure AI Foundry』セッション資料です。

Transcript

1. Japan Azure Travelers 第 5 回 沖縄の旅 AI エージェント開発を支える Model-as-a-Service (MaaS) としての Azure AI Foundry Ryosuke Otaka Cloud Solution Architect Customer Success Group Microsoft Japan
2. 自己紹介 大髙 領介 / Ryosuke Otaka - 出身地: 埼玉県 - 仕事: マイクロソフトのクラウドソリューションアーキテクト (Azure AI) - 好きなもの: コーヒー、蒸留酒、シーシャ、自然 - 最近のマイブーム: PTCGL (Pokémon Trading Card Game Live) Ryosuke Otaka ryohtaka @ryohtaka117
3. アジェンダ  “AI エージェント” について考えてみる  Copilot & AI stack と Azure AI Foundry  Azure AI Foundry のモデルカタログ  Azure AI Foundry を使ったノーコードファインチューニング  ファインチューニングの使いどころ  クラウド推論とローカル推論と LLM と SLM  まとめ
4. “AI エージェント” について考えてみる
5. “AI エージェント”と言われて どんなものを想像しますか？
6. かしこまりました。 “AI エージェント” の意図するところ  厳密な定義は存在しないが、おおむね『ユーザーの指示に基づいて自律的にタスクを遂行するソフ トウェア』を意図して使われることが多い様子  “自律的に” とは、おおむね『ハイレベルな (細かい手順を指定せず全体的な視点で) 指示をする と手順を考えてタスクを遂行する』ことを意図して使われることが多い様子 実行計画 ① データ収集 ② トレンド分析 ③ インサイト抽出 ④ レポート作成 過去 3 年間の国内の加工食品 市場の分析を行ってください。 ユーザー 分析を行いました。こちらの レポートをご覧ください。 参照: report.pptx AI エージェント ① データ収集 ② トレンド分析 ③ インサイト抽出 ④ レポート作成 “自律的”なエージェントのイメージ ※個人の感想です。
7. AI エージェントの目的は業務自動化  AI エージェント は Robotic Process Automation (RPA) のような従来の単調定型作業の自 動化とは区別して使われることが多いようだが、業務自動化という観点での目的は同じ  AI エージェントはを AI エージェントたらしめるのは ”自律性” であるため、策定された実行計画 (具体的な手順) の中に RPA や従来からある機械学習モデル (特化型 AI などと呼ばれることも ある) による推論 (予測・分類、など) が含まれることもあり得る  投資対効果 (ROI) を意識し、 「①そもそもどんな業務を自動化したいのか」、「②それをどのよう な手段を組み合わせると自動化できそうか」といった順に考える (絶対に①を先に行い目的と手段が入れ替わらないように) 実行計画 手順 1: RPAによるデータ入力 手順 2: 機械学習モデルによる予測 手順 3: LLMによる要約 AI エージェント RPA や “特化型 AI” も含む AI エージェントのイメージ ※個人の感想です。
8. 用語の包含関係 (私の頭の中のイメージ)  AI: 人間の知性や認知機能を再現したアプリケーション  生成 AI: AI の中で特に生成モデルを使ったものを指す  AI エージェント: 生成 AI の中で特に自律性のあるもの (≒アシスタント?)  xxx Copilot: AI エージェントの実装 (具体的な製品名)  特化型 AI: 「特定業務を行う AI」と「特定タスクの分類や予測を行う機械 学習モデル」を意図していることが混在していて、単なる「ワークフローシステム」 を意図していることもまれにある印象  RPA ツール: 自動化ツールなので AI ではない気がするが、フロー内で実行 されるステップの中に AI / 生成 AI に関係するものがある場合ユーザーから見 れば「AI」かもしれない 生成 AI AI エージェント (≒アシスタント?) Copilot など? AI 特化型 AI RPA ツール 頭の中のイメージが十人十色になりがちな領域のため コミュニケーションを行う際にはしっかりとすり合わせを行うことが重要 ※個人の感想です。
9. 2025 年 2 月時点で “AI エージェント” はまだビジョン  Microsoft Ignite 2024 における Microsoft CEO Satya Nadella の基調演説では、多数の エージェントが人間の仕事を支援する未来像を “Agentic World” という言葉で表現している。  ガートナージャパンの見解:  「企業は、AIエージェントについて『すぐにすごいAIが登場した』『導入すればすべてをうまく実行し てくれるソフトウェアやシステムが登場した』と捉えてはなりません。これはあくまでも理想であり、 将来的な展望やビジョンです。ユーザーが何も設定等をせずに、企業ユーザーにとって気の利い た対応が出来る『AIエージェント』は、現時点では世の中には存在しません。AIエージェントを 試したい企業は、ベンダーの提供する『AIエージェント・フレームワーク』を用いて、特定されたタス クに対応するAIエージェントになるように適宜設定もしくは開発する必要があります」
10. 我々はいかにして “Agentic” な世界に近づいていくか  おおむね以下の 3 段階になると考えられるが、Level-2 以降は機能を開発する単位や対象 ユーザーが異なる別アプリケーションとなる。(後述)  Level-1: 汎用チャット (共通機能の羅列)  Level-2: シングルエージェント (特定業務エージェント)  Level-3: マルチエージェント (複数の特定業務エージェントのオーケストレーション) 業務 A 業務 B 業務 C 共 通 業 務 Level-1: 全ユーザーが対象 全社員共通の 事務手続きの単位 文章要約、Web 検索などの 業務に関わらず使える最大公約数 的な機能の単位 業務 A 業務 B 業務 C 共 通 業 務 Level-2 / Level-3: 各業務に従事するユーザーが対象 特定業務の単位
11. データ アプリ バックエンド機能 Level-1: 汎用チャット (共通機能の羅列)  やや “Agentic” な世界。  汎用チャットアプリケーションを介してバックエンドに準備された機能を選択して実行する。  各機能はあらかじめ実装されたとおりのフローで動く。  全ユーザーを対象にしたような最大公約数的な機能が羅列されている。  機能どうしのシナジーは特になく、アプリケーションは各機能を呼び出すルーターのような動きをする。 ユーザー 汎用チャット モデルとの素のチャット チャット検索 (社内) 社内文書ナレッジベース Web 検索 ESTA 申請費用はどの項目で 経費申請すればよいですか？ ユーザーによる機能選択もしく はアプリによる自動選択 ツール選択をアプリに行わせる 場合は“自律的”である あらかじめインデックス化されたデータ を検索して回答文生成を行う RAG 機能 社内手続きなどに関する 汎用資料 ESTA 申請費用は 『T&E Other(その他の旅費)』として計上します。 参照: xxx チャット検索 (Web) ...
12. Level-2: シングルエージェント (特定業務エージェント)  もっと “Agentic” な世界。  特定業務に特化したエージェントはハイレベルな指示に対して、与えられた機能を組み合わせた手順を “自律的に” 考えて遂行する。  Level-1 の汎用チャットとは根本的に異なるアプリケーション (一部バックエンド機能やデータに関しては共有できる可能性あり)  開発する上で、既存の人力業務がどう行われているかの分析が必須。 データ アプリ バックエンド機能 ユーザー 市場分析 エージェント データ収集 (1) トレンド分析 (2) インサイト抽出 (3) レポート作成 (4) 公的統計データ 過去 3 年間の国内の加工食品 市場の分析を行ってください。 分析を行いました。こちらのレポートをご覧ください。 参照: report.pptx 調査会社による レポート POS データ 社内データ ニュース・SNS ... ... 予測モデル作成 仮説検証 2022年から2024年にかけて加工食品市場は平均+x% で成長を記録しています。中でも、aaaに伴うxxxと yyyセグメントの成長が大きく寄与したとみられます。 … ユーザーの指示に応えるために、与え られた機能を組み合わせた実行 計画を”自律的に”考えて遂行する エージェントが考えた実行計画: 1. データ収集 2. トレンド分析 3. インサイト抽出 4. レポート作成 参照データの準備 (統合・クレンジング) はあらかじめ済ませておく
13. Level-3: マルチエージェント (複数の特定業務エージェントのオーケストレーション)  とても “Agentic” な世界。  マルチエージェント化とは、つまり複数エージェントのオーケストレーションを行うということ。  下記の例では “スーパーバイザーエージェント” が複数のエージェントを束ねている。 データ アプリ バックエンド機能 ユーザー スーパーバイザー エージェント データ収集 (1-1) トレンド分析 (1-2) インサイト抽出 (1-3) レポート作成 (1-4) 公的統計データ 過去 3 年間の国内の加工食品市場の分析を 行って、有望そうな投資先候補をリストアップ して。 リストアップを行いました。 こちらのレポートをご査収ください。 参照: report.pptx 調査会社によるレポート POS データ 社内データ ニュース・SNS ... 予測モデル作成 仮説検証 2022年から2024年にかけて加工 食品市場は平均+x%で成長を記 録しています。中でも、aaaに伴う xxxとyyyセグメントの成長が大きく 寄与したとみられます。… 市場分析 エージェント (1) 投資判断 エージェント (2) 先物取引分析 エージェント ... ファンダメンタル分析 (2-2) データ収集 (2-1) テクニカル分析 リスク評価 (2-3) レポート作成 (2-4) 株価データ 為替データ 決算書・財務諸表 アナリストレポート IR 情報 ... 市場分析エージェントが使う機能群 投資判断エージェントが使う機能群 ... ... ユーザーの指示に応えるために、 各エージェントを組み合わせた実行 計画を”自律的に”考えて実行する 実行計画: 1. 市場分析エージェント 2. 投資判断エージェント 呼ばれた各エージェントは 各々”自律的に”考えて動く (Level-2 と同じ)
14. 全部 “AI エージェント” LangGraph - Multi-agent Systems いわゆる “シングルエージェント” いわゆる “マルチエージェント” Function Callingみたいに LLM にツール選ばせるやつ (“自律性”は低め?) レストラン予約エージェント みたいなわかりやすいやつ リーダー役が各メンバーに 指示して仕事するやつ エージェントどうしが議論して 何やら決めるやつ その他フリースタイル スーパーバイザーパターンの もっと大組織なやつ
15. Copilot & AI stack と Azure AI Foundry
16. Copilot stack(Microsoft Build 2023) Microsoft Copilot Your copilots Copilot extensibility AI safety and security Your data Foundation models AI orchestration and toolchain AI infrastructure Microsoft Copilot Your copilots Copilot extensibility AI safety and security Your data Foundation models AI orchestration and toolchain AI infrastructure Microsoft Copilot Your copilots Copilot extensibility AI safety and security Your data Foundation models AI orchestration and toolchain AI infrastructure Cloud and Edge
17. Azure AI (Microsoft Build 2024) Best-in-class AI foundation models Azure AI Services Pre-trained, turnkey solutions for intelligent applications Responsible AI Tooling Build and manage apps that are trustworthy by design Azure Machine Learning Full-lifecycle tools for designing and managing AI models Azure AI Studio A comprehensive platform to develop and deploy custom copilots
18. Visual Studio + Copilot Studio GitHub + Azure Cloud to Edge Azure AI Foundry Data Infrastructure Trustworthy AI Copilot & AI stack(Microsoft Ignite 2024)
19. Azure AI Foundry Data Infrastructure Azure Cloud to Edge Trustworthy AI Copilot & AI stack(Microsoft Ignite 2024)
20. Azure AI Foundry The unified AI platform
21. Visual Studio Copilot Studio GitHub Azure AI Foundry SDK Azure AI Foundry Model Catalog Open-source models Foundational models Task models Industry models Azure AI Content Safety Azure AI Search Azure AI Agent Service Azure OpenAI Service Observability Customization Evaluations Governance Monitoring Azure AI Studio
22. Azure AI Foundry のモデルカタログ
23. Azure AI Foundry のモデルカタログとは  生成 AI アプリケーションを構築する際にモデルを検索して使用するためのハブ。  モデルカタログには様々なモデルプロバイダー (Microsoft、OpenAI、Mistral、Meta、Cohere、NVIDIA、NTT DATA、Hugging Face、など) の合計 1,800 以上のモデルが含まれている。(2025 年 2 月 15 日時点)  モデルプロバイダーは自社のモデル追加リクエストを行うこができ、承認プロセスを通過したモデルはモデルカタログで利 用可能になる。(NTT DATA の tsuzumi など)  元々は Azure Machine Larning のいち機能で あったが、Azure AI Studio との統合が進み、各 モデルプロバイダーによる多数のモデルをひとまとめ にしてアクセスするための上位概念になりつつある。 参考: • Azure AI モデルカタログ – 基盤モデル | Microsoft Azure
24. モデルコレクション  モデルカタログで利用可能なモデルは大きく分けて 2 つのコレクションに分類される: 1. Azure AI によりキュレーションされたモデル 2. Hugging Face Hub のオープンモデル 参考: • モデル カタログとコレクション - Azure Machine Learning | Microsoft Learn
25. Azure AI によりキュレーションされたモデル  Azure AI プラットフォーム上でシームレスに動作するようにパッケージ化と最適化がされたモデル群。  23 のモデルプロバイダー企業 により開発された 200 以上のモデルが含まれている。 (2025 年 2 月 15 日時点)  Azure AI によりキュレーションされたモデルは Azure SLA の適用対象。  モデルプロバイダーの一覧 (Hugging Face 以外): 参考: • モデル カタログとコレクション - Azure Machine Learning | Microsoft Learn • Licensing Documents (microsoft.com) • Azure OpenAI Service (OpenAI) • Microsoft • Meta • Mistral • Gretel • NVIDIA • AI21 Labs • Deci AI • Nixtla • JAIS • Cohere • Databricks • Snowflake • SDAIA • Paige AI • Bria • NTT DATA • Saifr • Rockwell • Bayer • Cerence • Sight Machine • DeeepSeek
26. DeepSeek R1  話題のモデルも既に含まれている 参考: • DeepSeek R1 is now available on Azure AI Foundry and GitHub | Microsoft Azure Blog • deepseek-ai/DeepSeek-R1 · Hugging Face
27. Hugging Face Hub のオープンモデル  Microsoft は Hugging Face 社と 2022 年からパートナーシップを締結しており約 1,600 のオープンモデルがカタログ から使用可能。 (2025 年 2 月 15 日時点) 参考: • ハギングフェイスハブ - Hugging Face NLP Course • Microsoft and Hugging Face deepen generative AI partnership - Microsoft Community Hub
28. モデルのベンチマーク  Azure AI Foundry ポータルでは一部のモデルのベンチマークの比較を行うことができ、モデル検討時のおおよその参 考にすることができる。 参考: • Azure AI Studio でモデル ベンチマークを調べる - Azure AI Foundry | Microsoft Learn ベンチマーク ありのマーク
29. モデルのライセンス  モデルカタログで公開されているモデルはモデルプロバイダーにより異なるライセンスが設定されているため、アプリケー ション開発に使用する場合は確認を行う必要がある。  例えば、Microsoft の Phi-3 ファミリーは MIT License のもと公開されているためほぼ自由に商用利用できるが、 Meta の Llama ファミリーは Meta 3 Community License のもと公開されているため、「月間アクティブユーザーが 7 億人を超える場合 Meta にライセンスをリクエストを行う必要がある。Meta が明示的に権利を付与しない限り利 用できない。Meta は独自の裁量でユーザーにライセンスを付与することができる。」等の追加の商用使用条件が存 在する。 参考: • licenses.opensource.jp/MIT/MIT.html • Meta Llama 3 License
30. デプロイオプション  モデルデプロイオプション (エンドポイントを作成して利用可能にするための選択肢) は以下の 2 種類: 参考: • モデル カタログとコレクション - Azure Machine Learning | Microsoft Learn サーバーレス API マネージドコンピューティング 両方に対応したモデルの場合は 選択ポップアップが表示される
31. サーバーレス API  Azure AI によりキュレーションされたモデルの一部モデルが対応。  利用者はモデルが実行されるインフラを自分で準備しなくてもトークン単位の重量課金ですぐに使用開始することが できる。  この形式で提供されるサービスは Model-as-a-Service (MaaS) とも呼ばれる。(PaaS でのデプロイと対比して)  モデルによって対応リージョンが異なる。(詳細は下記リンク参照)  サーバーレス API で公開されているモデルは Azure AI Model Inference API でラップされており、異なるモデルプロ バイダーのモデルであっても共通した操作性を持つ。 参考: • モデル カタログとコレクション - Azure Machine Learning | Microsoft Learn • サーバーレス API エンドポイントでのモデルに対する利用可能なリージョン - Azure Machine Learning | Microsoft Learn • Azure AI Model Inference API - Azure AI Studio | Microsoft Learn モデルが実行されるインフラは 利用者から隠されている 利用したトークンに応じた 従量課金 サーバーレス API
32. サーバーレス API に対応しているモデル  モデルカタログのデプロイオプションからフィルターをかけて検索することができる。  2025 年 2 月 15 日時点で対応しているのは Azure OpenAI Service (OpenAI)、Microsoft、Meta、Mistral、 Gretel、AI21 Labs、Nixtla、JAIS、Cohere、Bira、NTT DATA、DeepSeek によって提供されている 72 モデル。 参考: • サーバーレス API エンドポイントでのモデルに対する利用可能なリージョン - Azure Machine Learning | Microsoft Learn
33. サーバーレス API の購入先の違い  ファーストパーティーのモデル (Azure OpenAI Service と Phi ファミリー) は Azure の料金として請求される。  価格はAzure の価格サイトに記載されている。 参考: • モデル カタログとコレクション - Azure Machine Learning | Microsoft Learn • Microsoft Commercial Marketplace Terms of Use | Microsoft Learn • Phi-3 Pricing | Microsoft Azure • Azure OpenAI Service - 価格 | Microsoft Azure Azure の料金 Azure Marketplace から購入  サードパーティーのモデルは Azure Marketplace 経由 でモデルプロバイダーから購入する。  価格はデプロイ時に表示される。
34. サーバーレス API の購入先の違い Phi-3.5-mini-instruct の例 (ファーストパーティー) tsuzumi-7b の例 (サードパーティー)
35. サーバーレス API の購入先の違い Phi-3.5-mini-instruct の例 (ファーストパーティー) tsuzumi-7b の例 (サードパーティー) Phi-3 Pricing | Microsoft Azure
36. サーバーレス API とコンテンツフィルター  サーバーレス API デプロイ時にコンテンツフィルター (実体は Azure AI Content Safety) を有効にすることができる。  コンテンツフィルターを有効にすると、4 つの有害カテゴリー (ヘイトと公平性、性的、暴力、自傷行為) に関するフィルタリングが行 われる。  設定はデプロイ後に有効・無効を変更可能。  有効にした場合、別途 Azure AI Content Safety の料金がかかる。 参考: • モデル カタログとコレクション - Azure Machine Learning | Microsoft Learn • Azure AI Content Safety の危害カテゴリ - Azure AI services | Microsoft Learn • Azure AI Content Safety - 価格 | Microsoft Azure サーバーレス API 有効にすると Azure AI Content Safety による 入出力のフィルタリングが行われる デプロイ時のトグルで設定する
37. マネージドコンピューティング  機械学習基盤 PaaS である Azure Machine Learning のモデル公開機能 (マネージドオンラインエンドポイント) を 利用してモデルカタログで選択したモデルをデプロイする形式。  モデルはユーザーが指定したサイズ・インスタンス数のマネージド VM 上で動き、VM 稼働時間に応じた従量課金。  マネージドコンピューティングは停止できないため、課金を止めたい場合はデプロイを削除する。  サーバーレス API と同様にモデルは Azure AI Model Inference API でラップされており共通した操作性を持つ。 参考: • モデル カタログとコレクション - Azure Machine Learning | Microsoft Learn マネージドコンピューティング 利用者はモデルを実行する仮想 マシンのサイズ・インスタンス数を 自分で設定する VM の稼働時間に応じた 従量課金
38. エンドポイントの使用  モデルデプロイリストからエンドポイント情報を確認して使用する。  Azure AI Model Inference API による推論は REST に加えて Python、JavaScript、C# の各 SDK が使用可能。  マネージドコンピューティングの場合は API 認証方法としてキー認証 と Microsoft Entra ID 認証 から選択可能。(サーバーレス API はキー認証のみ) 参考: • モデル カタログとコレクション - Azure Machine Learning | Microsoft Learn • Azure AI Model Inference API - Azure AI Studio | Microsoft Learn • マネージド オンライン エンドポイントの認証 - Azure Machine Learning | Microsoft Learn Python SDK による推論のサンプルコード
39. デモ
40. Azure AI Foundry を使った ノーコードファインチューニング
41. モデルのノーコードファインチューニング  Azure AI によりキュレーションされたモデルの一部はファインチューニングのための API が公開されており、Azure AI Foundry ポータル経由でノーコードファインチューニングを行うことができる。 参考: • Azure AI Foundry ポータルでの微調整 - Azure AI Foundry | Microsoft Learn • Azure OpenAI Service を使用してモデルをカスタマイズする - Azure OpenAI | Microsoft Learn • Azure OpenAI Service モデル - Azure OpenAI | Microsoft Learn
42. ファインチューニングのオプション (1/3)  ファインチューニング時に選択できるコンピューティングは通常のモデルデプロイ時と同じく以下の 2 種類 参考: • Azure AI Foundry ポータルでの微調整 - Azure AI Foundry | Microsoft Learn • サーバーレス API エンドポイントでのモデルに対する利用可能なリージョン - Azure AI Foundry | Microsoft Learn • Fine-tune models using a managed compute with Azure AI Foundry portal (preview) - Azure AI Foundry | Microsoft Learn マネージドコンピューティング 利用者はモデルを実行する仮想 マシンのサイズ・インスタンス数を 自分で設定する VM の稼働時間に応じた 従量課金 サーバーレス API ファインチューニングが実行され るインフラは隠されている 学習データのトークンに応じた 従量課金
43. ファインチューニングのオプション (2/3) 両方に対応したモデルの場合は選択ポップアップが 表示される (Phi-3.5-mini-instruct の例)
44. ファインチューニングのオプション (3/3) マネージドコンピューティングの場合は 仮想マシンサイズ選択が入る それ以降の操作性は サーバーレス API と共通
45. モデルの蒸留  Azure OpenAI Service の一部モデルでは蒸留が可能。  モデルの蒸留 (知識蒸留) とは、大規模な教師モデルの知識・能力の一部を小規模な生徒モデルに伝達する手法で、特定の タスクをより小規模なモデルで行うことができるようになる。  『大規模なモデルにやらせるには過剰な簡単なタスクをより小さいモデルにやらせてコストやレイテンシーを削減したい』 というモチ ベーションで行われる。  Azure OpenAI Service の蒸留において実際にやっていることはシンプル。まず特定のタスクに関する入力を教師モデル (gpt-4o や o1-mini など) に対して行い、その出力を手に入れる。次に、教師モデルの入出力データを使って生徒モデル (gpt-35-turbo や gpt-4o-mini など) のファインチューニングを行う。 参考: • Introducing Model Distillation in Azure OpenAI Service | Microsoft Community Hub • Azure OpenAI Service の保存された入力候補および蒸留を使用する方法 - Azure OpenAI | Microsoft Learn • Azure OpenAI Service でモデルの蒸留 (Model Distillation) を行う • Distillation: Turning Smaller Models into High-Performance, Cost-Effective Solutions | Microsoft Community Hub • azureml-examples/sdk/python/foundation-models/system/distillation at main · Azure/azureml-examples · GitHub 引用元: https://arxiv.org/pdf/2410.18588
46. デモ
47. ファインチューニングの使いどころ
48. ファインチューニング (Fine-tuning) とは  学習済みの機械学習モデルをあるタスクに特化させるためにパラメーターの一部 (もしくは全部) を微調整する手法。  以下は OpenAI 社により開発されたモデルの場合の概念図。 ベースモデル Web上から収集された 膨大なテキストデータ 調整後モデル (InstructGPT) 人間が作成した教師データ タスク B における 教師データ 人間によるランク付け 人間によるランク付けを モデル化した報酬モデル によるランク付け タスク A における 教師データ 調整後モデル (InstructGPT) 微調整された (fine-tuned) モデル 調整後モデル (InstructGPT) 微調整された (fine-tuned) モデル 事前学習 人間のフィードバックによる強化学習 (RLHF) AOAI API で公開されている GPT-3.5 以降の世代のモデル ファインチューニング ファインチューニング タスク A に特化 タスク B に特化 入力テキストの “続き”を生成する 能力の獲得 人間の価値基準に 沿うように調整 あるタスク への特化 あるタスク への特化 参考: • Aligning language models to follow instructions | OpenAI • [2203.02155] Training language models to follow instructions with human feedback (arxiv.org)
49. ファインチューニングの一般的な使用例 (1/2)  モデルの『操作性』を向上させたいケース:  スタイル・トーン・フォーマットなどの定性的な特徴の設定  望ましい出力を行う信頼性の向上 (ハルシネーション対策以外)  複雑なプロンプトに従わない場合の修正  エッジケースへの対応  プロンプトで明確に表現するのが難しいタスクの実行 つまり 『指示をするよりも 見せた方が簡単』 な場合 タスク A における 教師データ 調整後モデル (InstructGPT) 微調整された (fine-tuned) モデル タスク A の具体的な 入力・出力データ例 参考: • Fine-tuning - OpenAI API • Fine Tuning: now available with Azure OpenAI Service - Microsoft Community Hub
50. ファインチューニングの一般的な使用例 (2/2)  『プロンプトを短くしたい』ケース:  レイテンシーの改善 (毎回書くプロンプト共通部分の省略、等)  プロンプトがコンテキストウィンドウ (最大トークン) に収まらない Prompt (入力) Completion (出力) 調整後モデル (InstructGPT) 微調整された (fine-tuned) モデル Prompt (入力) Completion (出力) ファインチューニングによって プロンプトの一部をモデルの パラメーターに埋め込むイメージ ただしモデルの進化 (生成スピードや最大トークンの向上) に伴いこうしたケースは減ってきていると考えられる。 参考: • Fine-tuning - OpenAI API • Fine Tuning: now available with Azure OpenAI Service - Microsoft Community Hub
51. ファインチューニングでアプローチするタスクの難度  ファインチューニングは教師あり学習のため、タスクの種類によって難度が異なる。  難度が低いタスクの例:  文章分類やスコアリングなどの、正解 (教師データ) の設定と評価がしやすいタスク  難度が高いタスクの例:  文章要約や翻訳などの、正解 (教師データ) がひとつに定まらず評価がしづらいタスク
52. ファインチューニングから始めるべきでないケース  ファインチューニングはトレーニングと評価に多くのデータ・時間・コストがかかるため闇雲に始めない。  ファインチューニングを行うと特定のタスクは得意になる可能性がある一方でそれ以外のタスクが不得意になる 可能性がある。 (汎化と特化のトレードオフ)  以下のようなケースではファインチューニングから始めるべきではない:  スモールスタートをしたい  カタログからのモデル選択やプロンプトエンジニアリングだけで解決できることもある。  ハルシネーション対策  ファインチューニングだけで情報・知識をモデルに埋め込むのは上手くいかない場合がある。  まずは情報検索・引用によるアプローチ (RAG など) により、モデルだけで解決するのではなく全体の仕組みで解決できないかを検討する。 参考: • Fine-tuning - OpenAI API • Fine Tuning: now available with Azure OpenAI Service - Microsoft Community Hub • Prompt engineering - OpenAI API
53. [補足] 検討のステップ ステップ 手法 モデルの変更 学習データサイズ コスト (時間・人的・ サービス費用) 備考 1 プロンプトエンジニアリング なし なし 小 以降の全てのステップにおいてもプロンプトエン ジニアリングとの組み合わせが必要。 2 Retrieval Augmented Generation (RAG) なし / あり なし 中 エンジニアリングだけで到達できるライン。 回答生成に用いるモデルは問わないため、 ファインチューニング済みモデルと組み合わせる パターンもあり得る。(後述) ※データ準備も含めてボトルネックの多い複 雑な仕組みになるため『使い物になるアプリ を作る』という観点での難度は高い。 3 ファインチューニング あり 数百～数千件規模の教師 データ 大 AOAIのファインチューニングなど機能がAPIとし て公開されている場合はエンジニアリングだけ でも可能。 オープンウェイトモデルの中からモデル選択や チューニングを行う場合はLLM領域の専門家 必須。 4 事前学習 (+調整) あり 数千億トークン規模の テキストコーパス (GPT-4o クラスの性能のモデルの場合) 特大 LLM領域トップクラスの専門家必須。 少なくとも数億円規模以上の予算、 および半年～数年のプロジェクト期間が必要。
54. [補足] Q&A タスクにおける RAG とファインチューニング それぞれ異なる特徴が存在するため、どちらを使うかといった排他的な関係ではなく組み合わせる選択肢もあり得る。 アプリ + LLM 質問 (Q) 回答 (A) 教師データ(QとAのセット)によって モデル自体を微調整する。 ファインチューニング • モデルをあるタスクに特化させる手法。(Q&A以外のタスクにも使 われる) • 試験に例えると『クローズブック』(外部の参照不可) • あくまでもモデルの『微』調整であるため、教師データに含まれる回 答を全て正確に再現する訳ではない。 • 都度チューニングが必要になるため、学習データが頻繁に更新され る状況には適さない。 • Q&Aタスクに適用してハルシネーションが発生した場合の原因の 推測や改善が困難。 アプリ + LLM 質問 (Q) 回答 (A) ナレッジベース (e.g. Azure AI Search) 回答生成時にモデルは ナレッジベースの検索結果を 引用するだけ。 回答根拠となる情報を検索できる ナレッジベースを作っておく。 Retrieval Augmented Generation (RAG) • Q&Aタスクに特化した手法。 • 試験に例えると『オープンブック』(外部情報の参照可) • 情報検索のレイヤーと回答生成のレイヤーを分割する。 • Q&Aタスクに適用してハルシネーションが発生した場合はナレッジ ベースの問題なのか、回答生成の問題なのか原因の切り分けがで きる。 • データ準備も含めてボトルネックの多い複雑な仕組みになるため 『使い物になるアプリを作る』という観点での難度は高い。
55. [補足] Retrieval Augmented Fine Tuning (RAFT)  RAG とファインチューニングを組み合わせた、特定のドメインにおける Q&A 性能を向上させるための手法。  教師データに回答と関係のない引用情報を意図的に混ぜることで、モデルは与えられた引用情報のうち無関係な もの (ノイズ) を無視して回答を生成する能力が向上するとされている。  また、教師データにて Chain-of-Thought (CoT) プロンプティングを使って推論 (回答生成) のプロセスも同時に示し てトレーニングを行っている。  ファインチューニングを使って『引用情報の分類』と『回答生成時の思考プロセス』をモデルに学習させている。(ファイン チューニングで『情報そのもの』をモデルに含めているわけではない。) 参考: • [2403.10131] RAFT: Adapting Language Model to Domain Specific RAG (arxiv.org) • RAFT (berkeley.edu) • RAFT (Retrieval Augmented Fine-tuning): A new way to teach LLMs (Large Language Models) to be better at RAG (Retrieval Augmented Generation) (microsoft.com) • Chain-of-Thoughtプロンプティング | Prompt Engineering Guide (promptingguide.ai) • https://x.com/llama_index/status/1772662480210198809
56. クラウド推論 と ローカル推論 と LLM と SLM
57. クラウド推論とローカル推論 両者にはそれぞれ異なる特徴が存在するため、状況に応じて使い分けたり組み合わせる。 Hugging Face ローカル 推論 モデルのダウンロード ローカル Microsoft Azure (クラウド) Azure OpenAI Service Azure Machine Learning Azure AI Foundry リクエスト レスポンス 推論 クラウド推論 (PaaS / MaaS)  最新の高性能なモデルをいち早く使うことができる  モデル実行インフラを自分で維持する必要がない  オフライン環境では使用できずネットワーク遅延や障害の影響を受ける  データをクラウド上で処理することが許容されない状況では使えない  など ローカル推論 (PC / モバイル / エッジ / 仮想マシン)  データ送受信のオーバーヘッド観点で低遅延で推論を行うことができる  オフラインで推論を行うことができる  推論がローカルで完結し、データをローカルにとどめることができる  高性能なモデルを使うことができない (推論自体は実行できるが極め て遅い可能性あり)  運用コストがさむ (モデル選択、モデル更新、実行環境維持、など)  など
58. モデルの量子化  モデル圧縮手法のひとつ。数値表現の精度を削減 (不可逆的な圧縮) をすることでモデルのメモリ使用量を削減する手法。  例: 32 ビット浮動小数点で表現されていたモデルの重みをより小さいビット数のデータ型で表現する。  量子化とモデルの性能はトレードオフの関係 (小さいビット数のデータ型で置き換えるほど性能が低下する可能性が高い)  Hugging Face では量子化済みのモデルも公開されており、メモリ量が限られるローカル推論シナリオにおける候補になり得る。 参考: • Introduction to Quantization cooked in with (huggingface.co) • GGUF (huggingface.co) • bartowski/Llama-3.2-3B-Instruct-GGUF · Hugging Face 引用元: ディープラーニングを軽量化する「モデル圧縮」３手法 – 株式会社Laboro.AI
59. クラウド推論・ローカル推論・LLM・SLM を適材適所で組み合わせる例 コスト・レイテンシーの最適化 Microsoft Azure (クラウド) Azure OpenAI Service Azure Machine Learning Azure AI Foundry AI エージェント (オンライン) 実行計画 タスク 1 (中量) タスク 2 (重量) タスク 3 (軽量) LLM 蒸留モデル 使用 LLM 使用 SLM 使用 オフライン時の挙動 Hugging Face AI エージェント (オフライン) 実行計画 タスク 1 (中量) タスク 2 (重量) タスク 3 (軽量) SLM のファイン チューニング (事前) SLM 使用 オフライン時は ローカル環境 のSLM で実行できるタスク のみを対象にする Microsoft Azure (クラウド) Azure OpenAI Service Azure Machine Learning Azure AI Foundry ローカル環境 にデプロイ (事前)
60. まとめ
61. まとめ  AI エージェントは『ユーザーの指示に基づいて自律的にタスクを遂行するソフトウェア』を意図して 使われることが多く、“自律的に” とは『ハイレベルな (細かい手順を指定せず全体的な視点で) 指示をすると手順を考えてタスクを遂行する』ことを意図して使われることが多い様子。  現時点で“Agentic World” はまだ未来像だが、①汎用チャット、②業務特化エージェント (シ ングルエージェント)、③マルチエージェント (複数エージェントのオーケストレーション) のように順を追っ てレベルアップしていくと良さそう。  Azure AI Foundry のモデルカタログやその中でサーバーレスで利用できる MaaS は AI エージェン ト開発におけるモデル選択を効率化してくれる。  Azure AI Foundry の一部モデルはノーコードファインチューニングやモデル蒸留に対応しており、モ デルのカスタマイズを効率化してくれる。  AI エージェント開発において、クラウド推論・ローカル推論・LLM・SLM を適材適所で組み合わせ て最適化を行なったりオフラインシナリオに備えると良さそう。
62. AIエージェントをAIエージェントたらしめるのは ”自律性” である。 Ryosuke Otaka
63. Thank you!!