変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。AI-901 第5章を新規作成（ドメイン2: Content Understanding=多モーダル情報抽出（文書/フォーム/画像/音声/動画→構造化）、スキーマ/フィールド定義、prebuilt vs custom、Document Intelligence/Vision/Speech との位置づけ、構築の流れ＝アナライザー→スキーマ→解析→結果、RAG/エージェントとの連携）
5.2情報抽出アプリを構築する
Content Understanding を使って軽量な情報抽出アプリを作る流れ（アナライザーの作成→スキーマ定義→入力を解析→構造化結果を受け取る）と、Foundry や SDK との組み合わせ、典型的なユースケースを理解します。
情報抽出アプリ作りの基本は「
①アナライザーを作る →
②抽出スキーマ（フィールド）を定義する →
③ファイルを解析させる →
④構造化された結果を受け取る」という流れです。アナライザー（analyzer）は「どの種類のコンテンツを・どのスキーマで抽出するか」をまとめた設定で、これにファイルを渡すと、各フィールドが埋まった結果（JSON など）が返ります。Foundry のポータルでスキーマを設計・試行し、アプリからは SDK で解析を呼び出す、という組み合わせが一般的です。
5.2.1構築の流れ
| ステップ | 内容 |
|---|---|
| 1. アナライザー作成 | 対象コンテンツ種別に合わせて作成 |
| 2. スキーマ定義 | 抽出したいフィールド（名前・型）を指定 |
| 3. 解析 | ファイルを渡して解析を実行 |
| 4. 結果取得 | 各フィールドが埋まった構造化データを受領 |
5.2.2Foundry・生成 AI・エージェントとの組み合わせ
情報抽出は単体でも有用ですが、他のワークロードと連携するとさらに力を発揮します。抽出した構造化データを グラウンディング（RAG）の根拠として生成 AI に渡せば、ファイルの中身に基づく回答ができます。また エージェント のツールの1つとして情報抽出を組み込めば、「書類を読み取って→内容を判断して→次の処理を実行」という自律フローが作れます。第2〜4章で学んだ Foundry のモデル・グラウンディング・エージェントと、この情報抽出が結びつく、という全体像を押さえましょう。
シナリオ：請求書処理の自動化。
①受領した請求書 PDF を Content Understanding で解析（スキーマ＝請求元/金額/期日）→
②抽出結果を社内規程と照合（RAG）→
③問題なければ エージェント が会計システムに登録（ツール）→
④高額は human-in-the-loop で承認。情報抽出が、生成 AI・グラウンディング・エージェントをつなぐ「入口」になります。
混同・注意：
①アナライザー（抽出の設定一式）とスキーマ（抽出フィールドの定義）——スキーマはアナライザーの一部。
②抽出結果の品質はスキーマの明確さと入力品質に依存（不鮮明な画像などは精度低下）。
③情報抽出は「取り出す」処理で、要約文や回答を「作る」のは生成 AI の役割——連携はするが役割は別。
④機微情報を扱うためプライバシーとセキュリティの配慮を忘れない。
頻出：
①情報抽出アプリの流れ＝アナライザー作成→スキーマ定義→解析→構造化結果。
②「抽出結果を根拠に回答」＝グラウンディング/RAG と連携。
③「読み取り→判断→実行を自律化」＝エージェントのツールとして情報抽出を利用。
④抽出（取り出す）と生成（作る）の役割の違いを問う問題に注意。
5.2.3この節のまとめ
- 構築の流れ：アナライザー作成 → スキーマ定義 → 解析 → 構造化結果の取得
- Foundry のポータルでスキーマ設計、アプリからは SDK で解析を呼ぶのが一般的
- 情報抽出はグラウンディング（RAG）やエージェントのツールと連携して真価を発揮
- 品質はスキーマの明確さと入力品質に依存。機微情報のプライバシー配慮も必須
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Content Understanding で情報抽出アプリを作るときの基本的な流れとして正しいものはどれですか？
Q2. 情報抽出で得た構造化データを根拠として生成 AI に渡し、ファイル内容に基づいて回答させる手法はどれですか？
Q3. 「書類を読み取り→内容を判断→次の処理を自律実行」する仕組みを作る場合、情報抽出はどう使われますか？
Q4. アナライザーとスキーマの関係として正しいものはどれですか？
Q5. 情報抽出アプリの品質や運用に関する注意点として正しいものはどれですか？