AOAI で AI アプリを開発する時に まず考えたいこと Global Azure 2025@Tokyo May 10, 2025 まっぴぃ | Yuji Masaoka (Igarashi) 

Announcement • Java on Azure Day 2025 で登壇します • Java + Azure OpenAI + Cosmos DB を利用した QA アプリケーション開発（予定） • よかったら聞きに来てください！ https://msevents.microsoft.com/event?id=172327856571 

本題 あなたは Azure を使って AI アプリを開発するときにまず何を考えますか？ 

最も大切なことは 「ユースケース/シナリオ」 を固めること どんな input / output を期待？ • ユーザーはチャットを入力してやり取りをする？ それとも音声でやり取りをする？ • 入力する内容は命令？質問/相談？ • output を元にユーザーの NEXT アクションは？ • 検索物の確認？申請/作業？資料作成？ etc. 出力された内容を人はどう受け取る？ • チャットで答えを全部受け取る？それともプロセス を経る必要あり？ • 会話の場合、コンテキストは結果生成に必要？ 

“ ” 企業は、AIエージェントについて『すぐにすごいAIが登場した』『導入すればす べてをうまく実行してくれるソフトウェアやシステムが登場した』と捉えてはなりま せん。 これはあくまでも理想であり、将来的な展望やビジョンです。ユーザーが何も 設定等をせずに、企業ユーザーにとって気の利いた対応が出来る『AIエージェ ント』は、現時点では世の中には存在しません。 AIエージェントを試したい企業は、ベンダーの提供する『AIエージェント・フレー ムワーク』を用いて、特定されたタスクに対応するAIエージェントになるように適 宜設定もしくは開発する必要があります。 Gartner、急速に期待が高まっているAIエージェントに関する最新の見解を発表 

“ ” AIエージェントを実践する前段階として、AIを推進する担当者やエンジニアは、 まずはリアリティを把握することが重要です。 理解できる・できないにかかわらず、ベンダー等のWEBサイトにアクセスして 初期の探索を行うことは、そのリアリティを知るために最初にやるべきことです。 すべての企業は、ベンダーやシステム・インテグレーターに『丸投げ的なPOCを 依頼』しないように、自分たち自身で出来る体験や学びをまずは行い、事前 に目利き力を強化する必要があります。 Gartner、急速に期待が高まっているAIエージェントに関する最新の見解を発表 

つまり HOW (技術) に先走ってはいけない！ これまでのアプリケーション開発でも言われてきたこと！ 「結局何がどうなればいいんだっけ？」 → 生成 AI / LLM においては、この観点がより重要！ リアリティの追求こそ、エンジニア (開発者) に課せられた使命！ 

シナリオがしっかりしていればアーキテクチャも自ずと決まる Chat Completion • ユーザーが入力したプロンプトに基づき(対応する) 自然な文章生成や回答を作成 • 質疑応答 (FAQ / QA etc.) • クリエイティブ作業 (ブログ/メールなどの文章生成) • シンプルな会話型アシスタント • 特定のシナリオに適応した回答を素早く出力 AI Agent • 複数のツールやデータソースを活用して、複雑なタ スクを実行 (入力に対する回答が必須ではない) • 外部 API 連携/実行 • フローチャート型のタスク進行 (プロセス) 管理 • 状況に応じた複雑な会話型アシスタント • 複雑なタスクに対応した高度なロジックの実行や、 状況に応じた柔軟な解決策 (回答) の提示がメ イン 

シナリオがしっかりしていればアーキテクチャも自ずと決まる API Management • 正直、本番運用するなら必須 • LLM のモデルバージョンが変わればエンドポイント も変わってしまう部分をカバー • 認証/認可やセキュリティ部分もしっかり考慮 MCP (Model Context Protocol) • MCP は単なるプロトコル • クライアントとサーバサイドを分離できる (分離するかどうかは管理方針次第) • 企業内でのみ AI アプリを利用する場合は MCP を無理して組み込む必要性はない (先行投資する価値はある) 

ユースケース/シナリオをサポートする機能は Azure にちゃんと存在 Azure OpenAI • AOAI Evaluation • VNet 統合 • コンテンツフィルタリング • Fine-Tuning • Prompt Transformation (DALL-E) etc. Azure AI Foundry • Agent Service • Azure AI Foundry Evaluation • Private Link • Content Safety • Fine-Tuning • LLM Tracing etc. 

ユースケース/シナリオ がしっかりしていれば評価も悩まない • なんとなく RAG でアプリ作ってみたけど、LLM の評価方法がわからない = あるある • PoC ではうまくいったけど本番展開してみたら全然性能が出ない、なぜ？ = 超あるある • 利用者が 「なぜ」「何のために」「他ではない」 AI アプリを利用するのか • 利用者は AI アプリに何を期待するか/AI アプリでどのように楽をしたいか (理想があるはず) • input / output は開発者の独りよがりな作りになっていないか 要求分析/要件定義 がしっかり出来ていれば、LLM の評価は自ずと出来る 原因は 使用者目線 で ユースケース/シナリオ を全く想定出来ていない から!! 

参考: LLM の評価について • AI Foundry Evaluation & Control model-deployment 

Conclusion • 生成 AI アプリを開発するときは、まず最初に ユースケース/シナリオ を考える！ • input/output はどの形式を採用するか (チャット? 音声? 画像? ファイル? etc.) • output はどのように利用するか (一度に全部返す? プロセスを踏む必要がある? 会話形式? etc.) • ユースケース/シナリオに合うモデル選択/アーキテクチャを採用する • Chat Completion / AI Agent どっち使うか問題も自ずと決まる • ユースケース/シナリオが決まっていれば、評価ロジックも困らない • 想定する Input/Output も自ずと決まるはず • AI アプリを利用するユーザーへの協力も必要不可欠