前回の続き——「モデル出力」をどう受け取るか
前回のT-03では、LLMへの入力にシステム指示・ユーザー入力・モデル出力という3つのレイヤーがあることを見ました。今回はその最後、モデル出力を「アプリがどう受け取るか」に焦点を当てます。相手が人なら文章のままで構いませんが、受け取るのがプログラムであれば、形が決まっていないと扱えません。引き続き、経費アプリの勘定科目を提案するAI機能を題材に進めます。
このスライドのポイント
- T-03: 入力には3つのレイヤー（システム指示・ユーザー入力・モデル出力）があった
- 今回はそのうち「モデル出力」を、アプリがどう受け取るかの設計
- 人が読むなら自由文でよい／アプリの部品として使うなら形が要る
- 共通例: 経費アプリの「勘定科目を提案するAI機能」の出力を扱う
定義——構造化出力とスキーマ
構造化出力とは、モデルの出力を自由な文章ではなく、決められた項目と型を持つデータ、つまりJSONの形で返させる仕組みです。ここでいう型は、E章で学んだ文字列や数値といったデータの種類のことです。そして、その項目と型の定義をスキーマと呼びます。たとえば勘定科目の提案なら、科目は20種のどれか、確信度は数値、理由は文字列、と決めておきます。アプリの後続処理、つまりデータベースへの保存や画面への表示は、いずれも決まった形を前提に作られています。だからこそ、AIをアプリに組み込むなら、出力は構造化しておくのが定石です。
このスライドのポイント
- 構造化出力: モデルの出力を自由文でなく、決められた項目と型（E章で見た型）のデータ＝JSON（K-04）で返させる仕組み
- スキーマ: その項目と型の定義（例: 科目＝20種のどれか／確信度＝数値／理由＝文字列）
- アプリの後続処理（保存＝L章・表示＝I章）は「決まった形」が前提
- だから組み込みには構造化出力が定石
なぜ必要か——自由文は「切り出し」で壊れる
構造化しないと何に困るのでしょうか。自由な文章で返ってきた答えから、必要な値を文面の中から探して切り出す実装になりがちです。この方法は、モデルの言い回しがほんの少し変わっただけで切り出しに失敗し、簡単に壊れます。AIがそうした壊れやすいコードを書いてきても、形を決める大切さを知らなければ、良し悪しを判断できません。E章で扱った型の考え方が、ここでようやく最後の実を結びます。
このスライドのポイント
- 自由文の出力から必要な値を無理やり切り出す実装は壊れやすい
- モデルの言い回しが少し変わるだけで、切り出しが失敗する
- AIがそうした壊れやすいコードを書いても、形の重要性を知らないと評価できない
- E章で学んだ「型」の議論が、ここで最後の実を結ぶ
構造——スキーマはモデルとの契約
全体像を対比で見ましょう。左は自由文のルートで、文章から値を切り出す工程が挟まり、壊れやすくなります。右はスキーマを指定するルートで、決まった形のデータがそのまま保存や表示へ流れます。ここで大切な位置づけがあります。スキーマは、モデルとの契約だということです。これはK章で学んだAPIの契約、つまり「この形式でやり取りします」という取り決めと同じ思想です。契約があるからこそ、受け取る側は「この項目が、この型で届く」と信じて後続を設計できます。
このスライドのポイント
- 対比: 自由文→切り出し→壊れやすい ／ スキーマ指定→検証済みのデータ→そのまま保存・表示
- スキーマ＝モデルとの契約（K-02のAPI契約と同じ思想）
- 契約があるから、受け取る側は「この項目がこの型で来る」と信じて後続を設計できる
処理の流れ——AI機能が「普通の部品」になる
具体例で流れを追います。勘定科目を提案するAI機能の出力スキーマを、科目は選択肢の中から、確信度は0から1の数値、理由は短い文字列、と決めます。するとモデルの答えは、この形のデータとして返ります。返ってきたデータは、そのままデータベースのテーブルに保存でき、画面にも表示できます。特別な切り出し処理はもう要りません。この瞬間、AI機能は魔法のような存在ではなく、これまで学んできた「普通の部品」の一つになります。
このスライドのポイント
- 勘定科目提案の出力スキーマ: category＝選択肢から／confidence＝0〜1／reason＝短文
- 出力がそのままL章のテーブルに入り、I章の画面に表示される
- 特別な切り出し処理は不要になる
- AI機能が特別なものでなく「普通の部品」になる瞬間
技術サンプル——出力スキーマと出力例の対
サンプルを見ます。上がスキーマ、下が実際の出力例です。スキーマでは、科目を20種の選択肢のいずれか、確信度を0から1の数値、理由を短い文字列と定めています。読み方の第一は、型が決まっているから検証できる、という点です。J章で学んだ入力の検証が、AIの出力に対しても同じように使えるようになります。第二は、科目を選択肢に限る制約が、想定外の値が返る暴走を防ぐ、という点です。
混同しやすい——チャット用途とアプリ組み込み
混同しやすい対を押さえます。一方はチャットのように人が読む用途で、この場合は自由な文章のままで構いません。もう一方は、アプリに組み込んでプログラムが読む用途で、こちらは構造化出力が定石になります。分かれ目は単純で、その出力を最後に読むのが人か、プログラムか、という点です。同じモデルの答えでも、使い道によって適した形が変わります。
バイブコーディングでの確認点
バイブコーディングでの確認点です。AI機能を実装させたら、まず「出力はスキーマで制約されていますか」と確認します。あわせて、「スキーマから外れた出力が来たときの処理はありますか」も必ず聞きます。モデルの出力は完全ではないため、契約どおりでない答えが返る場合を想定し、J章で学んだ例外の扱いを用意しておく必要があります。AIへの質問例は、「この出力がスキーマに合わないとき、アプリはどう振る舞う設計ですか」です。
このスライドのポイント
- AI機能の実装に確認: 「出力はスキーマで制約されているか」
- あわせて: 「スキーマ外の出力が来たときの処理（J-08の例外）はあるか」
- モデルの出力は完全ではない前提で、契約どおりでない場合を想定しておく
一問一答とまとめ
最後に一問一答です。アプリに組み込むAIの出力は、定石としてどんな形式にするのでしょうか。（間）答えは、構造化出力です。スキーマで項目と型を決め、決まった形で受け取ります。30秒でまとめます。構造化出力は、モデルの答えを決まった項目と型のデータで返させる仕組みで、スキーマはその定義であり、モデルとの契約でした。契約があるから後続の保存や表示がそのまま繋がり、型があるから検証もできます。次回は、モデルに「道具」を持たせ、選ばせる仕組みへ進みます。関連資料は「AI開発ワード100」と「DB設計プロンプト50」です。
このスライドのポイント
- 問: アプリに組み込むAI出力の、定石の形式は？
- 答: 構造化出力（スキーマで項目と型を決める）
- 30秒まとめ: 構造化出力＝決まった項目と型で返させる／スキーマ＝その定義であり、モデルとの契約
- 次回: モデルに「道具」を持たせ、選ばせる仕組みへ
- 関連資料: 「AI開発ワード100」「DB設計プロンプト50」
