第1章生成AIアプリケーション設計 / 想定学習時間:30〜40分 / 最終確認:2026年8月

1-1. 生成AIのユースケース分解(要件→タスクへの分解)

🎯 この節の学習目標

あいまいなビジネス要件を、生成AIパイプラインの「入力」と「出力」の具体的な記述に変換できる
要件を構成する個々のモデルタスク(要約・分類・抽出・生成など)を識別し、適切な順序に並べられる
「1回のLLM呼び出しで済むか、複数ステージに分けるべきか」を判断できる

1. なぜ「分解」から始めるのか

生成AIアプリケーション開発の出発点は、モデル選びでもプロンプト書きでもなく、ビジネス要件をAIが実行可能なタスクの列に分解することです。試験でも第1セクション「Design Applications」の中心テーマであり、次のような形で問われます。

「〜というビジネス課題がある。生成AIエンジニアが最初にすべきことは?」
「この要件を満たすパイプラインの構成要素として適切な組み合わせと順序は?」
「このゴールに対して望ましい入力と出力の記述はどれか?」

ビジネス側の要望は「顧客対応を効率化したい」「社内文書を活用したい」のように抽象的です。これをそのままLLMに投げても、期待する品質・形式の出力は得られません。分解とは、あいまいな要望を次の3点に落とし込む作業です。

入力(Input)の定義 — システムが受け取るデータは何か(顧客の質問文?PDF文書?チャット履歴?)。形式・言語・量はどうか。
出力(Output)の定義 — 最終的に返すものは何か(要約文?JSON?分類ラベル?根拠付き回答?)。誰が読むのか。形式の制約はあるか。
中間タスクの列挙 — 入力から出力に至るまでに必要な処理ステップは何か。それぞれは生成AIのどの「タスクタイプ」に当たるか。

2. 生成AIの基本タスクタイプを知る

分解の道具として、まず「LLMが得意とする代表的なタスクタイプ」を頭に入れます。要件を読んだら、この語彙で言い換えられないかを考えるのが分解の第一歩です。

タスクタイプ	内容	ビジネス要件での言い回しの例
要約(Summarization)	長いテキストを短くまとめる	「会議録を1枚にまとめたい」「問い合わせ内容を一目で把握したい」
分類(Classification)	テキストにラベルを付ける	「問い合わせを担当部署に振り分けたい」「レビューがポジティブか知りたい」
抽出(Extraction / NER)	テキストから構造化データを取り出す	「契約書から金額と期日を取り出したい」「履歴書からスキルを一覧化したい」
質問応答(QA)	質問に対して回答を返す	「社内規程について質問に答えるボットが欲しい」
生成(Generation)	新しいテキストを作る	「商品説明文を自動で書きたい」「返信メールの下書きが欲しい」
書き換え(Transformation)	文体変換・翻訳・整形	「専門用語を平易にしたい」「英語の問い合わせに日本語で対応したい」
コード生成	自然言語からコード・SQLを作る	「営業担当が自然言語でデータを検索できるようにしたい」

📝 試験のポイント

試験では「ビジネス要件 → 適切なモデルタスクの選択」という対応付けが直接問われます(公式試験ガイドの目標 “Select model tasks to accomplish a given business requirement”)。上の表の対応付けを、日本語・英語どちらの言い回しでも即座に判断できるようにしておきましょう。

3. 分解の手順:4つのステップ

Step 1 — ゴールを「誰が・何を・どう使うか」で言語化する

「顧客対応を効率化したい」なら、効率化の実体を確認します。誰が(サポート担当者?顧客自身?)、何を受け取り(回答案?FAQへの誘導?)、どう使うのか(そのまま送信?編集して送信?)。この確認だけで、必要な出力形式と品質基準が大きく変わります。

Step 2 — 入力と出力を仕様として書き下す

試験ガイドの目標 “Translate business use case goals into a description of the desired inputs and outputs for the AI pipeline” に対応する中核ステップです。例:

入力:顧客からの問い合わせメール本文(日本語、平均300字、製品名を含むことが多い)

出力:①問い合わせカテゴリ(「返品」「故障」「請求」「その他」のいずれか)、②担当者向けの回答草案(丁寧語、社内ナレッジベースの記事を根拠として引用)

Step 3 — 出力から逆算して中間タスクを洗い出す

出力側から「これを作るには直前に何が必要か」を逆算すると、抜け漏れなくステージを列挙できます。上の例なら:

カテゴリを出すには → メール本文の分類タスク
根拠付き回答草案を出すには → ナレッジベースから関連記事の検索(Retrieval) → 検索結果を文脈に含めた生成タスク

Step 4 — 1ステージか、マルチステージかを決める

洗い出したタスクが1つのプロンプトで確実にこなせるなら単一呼び出しで済ませます(シンプル・低コスト・低レイテンシ)。次のいずれかに当てはまるなら、複数ステージのチェーン(1-5で詳述)に分割します。

外部知識の参照が必要(→ 検索ステージを挟む。RAGは1-6で詳述)
前段の結果によって後段の処理を変えたい(例:カテゴリによって使うプロンプトを変える)
1プロンプトに詰め込むと指示が競合して品質が落ちる(例:「厳密なJSON抽出」と「自然な文章生成」の同居)
途中結果を人間が確認・監査したい

4. ケーススタディで練習する

💼 ケース1:カスタマーサポート支援ボット

要望:「サポートチームの返信作成を速くしたい」

分解結果:

分類 — 問い合わせをカテゴリ分け(ルーティングと後段プロンプト切替のため)
検索 — ナレッジベースから関連記事を取得(Databricks AI Search(旧 Vector Search))
生成 — 記事を根拠に回答草案を作成(引用元リンク付き)

入力:問い合わせ本文/出力:カテゴリ + 根拠付き回答草案。担当者が編集して送信する運用なので、多少の生成ミスは許容されるが引用元の明示が必須。

💼 ケース2:契約書レビューの一次スクリーニング

要望:「法務のレビュー負荷を下げたい」

分解結果:

抽出 — 契約金額・期間・解約条項などの構造化抽出(JSON出力)
分類 — 各条項をリスクレベルで分類
要約 — 法務担当向けのリスクサマリー生成

ポイント:「抽出はJSONで厳密に」「要約は自然文で」と性質が異なるため、1プロンプトに同居させずステージを分けるのが定石。法務判断そのものはAIに任せず、人間のレビューを前提とした出力設計にする。

5. 分解がその後の全設計を決める

ここで決めた内容は、この後の章の判断の入力になります。分解が甘いと後工程がすべてブレるため、試験でも「最初にやるべきことは要件の明確化・入出力の定義」という趣旨の選択肢が正解になりやすいことを覚えておいてください。

分解で決まること	影響する後続の設計判断
タスクの複雑さ	モデル選定(1-2):小型で足りるか、大型が必要か
外部知識の要否	RAG/ファインチューニング/プロンプトのみの選択(1-6)
ステージ数と順序	チェーン設計(1-5)、LangChainでの実装(3-1)
出力形式の厳密さ	プロンプト設計(1-3)、出力パーサーやガードレール(3-6)
入力データの種類	データ準備・チャンキング戦略(第2章)

✅ この節のまとめ

生成AI設計の第一歩はビジネス要件を入力・出力・中間タスクに分解すること。モデルやツールの選定はその後。
要件は「要約・分類・抽出・QA・生成・書き換え・コード生成」などのタスクタイプの語彙で言い換える。
出力から逆算して中間ステージを洗い出す。外部知識が必要なら検索(RAG)ステージを挟む。
性質の異なるタスクは1プロンプトに詰め込まず、マルチステージに分割する。

練習問題

問1. 小売企業が「顧客レビューを活用して製品改善のインサイトを得たい」と考えている。生成AIエンジニアが最初に行うべきことはどれか。

最も高性能なLLMを選定し、全レビューを入力して分析させる
要件を確認し、パイプラインの望ましい入力と出力を定義する
レビューデータで埋め込みモデルをファインチューニングする
AI Searchインデックスを構築する

解答と解説を見る

正解:B

設計の出発点は常に「要件 → 入出力の定義 → タスク分解」です。モデル選定(A)、ファインチューニング(C)、インデックス構築(D)はいずれも、入出力とタスクが定義された後に行う判断です。試験では「まず要件と入出力を明確にする」タイプの選択肢が正解になるパターンがよく問われます。

問2. 「問い合わせメールを内容に応じて適切な部署に自動で振り分けたい」という要件は、どのモデルタスクに最も対応するか。

要約(Summarization)
分類(Classification)
翻訳(Translation)
テキスト生成(Generation)

解答と解説を見る

正解:B

「振り分ける」「ルーティングする」「カテゴリ分けする」という言い回しは分類タスクの典型シグナルです。出力は自由文ではなく、あらかじめ定義された部署ラベルの1つになります。

問3. 「社内規程PDFに基づいて従業員の質問に回答し、根拠となる規程の箇所も示すボット」を設計する。パイプラインの構成要素として最も適切な順序はどれか。

質問受付 → LLMで回答生成 → 回答を規程PDFと照合
質問受付 → 規程文書から関連箇所を検索 → 検索結果を文脈に含めてLLMで回答生成
規程PDF全文をプロンプトに毎回含める → LLMで回答生成
質問をLLMで要約 → 要約を従業員に返す

解答と解説を見る

正解:B

外部知識(社内規程)に基づく根拠付きQAは、検索 → 拡張生成(RAG)パターンの典型です。Aは生成後に照合しており根拠の担保が困難、Cは文書が大きいとコンテキスト長とコストの面で非現実的、Dはそもそも要件(質問応答)を満たしません。

問4. 契約書から「金額・期日を厳密なJSONで抽出する」処理と「経営層向けの自然文サマリーを書く」処理を1つのアプリで提供したい。設計として最も適切なのはどれか。

1つのプロンプトで両方を同時に指示し、1回のLLM呼び出しで済ませる
抽出ステージと要約ステージを分け、それぞれに最適化したプロンプトを使うマルチステージ構成にする
JSON抽出は不可能なので、サマリーだけを提供する
2つの別々のLLMをファインチューニングする

解答と解説を見る

正解:B

「厳密な構造化出力」と「自然な文章生成」は要求される出力特性が大きく異なり、1プロンプトに同居させると指示が競合して品質が下がります。性質の異なるタスクはステージ分割が定石です。Dのファインチューニングは、プロンプト設計で十分達成できるタスクに対しては過剰投資です(1-6で詳述)。