目次
問い合わせ文から「種類」「対象製品」「優先度」を取り出し、管理画面へ表示したい。さらに、必要なときはチケットも作りたい。この二つは似たAI活用に見えますが、アプリケーション側で設計すべき責任が違います。
文章を決まった形へ整える段階と、外部の状態を変える段階を分けると、構成を選びやすくなります。構造化出力とツール呼び出しを、どちらが高度かで選ぶ必要はありません。出力を受け取った後に何をしたいかが出発点です。
本記事は2026年10月20日に確認したGemini APIの公式資料を技術上の例として用いた実装解説です。製品固有の設定は利用するAPIとモデルの公式資料で確認してください。以下の問い合わせ例、検証方法、設計順序は本サイトの提案です。特定のSDKへそのまま投入する完成コードではありません。
スポンサーリンク
構造化出力は受け取りたいデータの形を決める
構造化出力では、モデルに返してほしい項目と型をスキーマで指定します。例えば問い合わせの種類は選択肢の中から選び、要約は文字列にし、判断できない製品名は欠損として扱う、といった設計です。
Googleの公式資料は、JSON Schemaに沿った出力を設定できることを説明しています。一方で、構文が正しくても値の意味をアプリ側で検証する必要があり、JSON Schemaのすべての機能が使えるわけではないと明記しています。形の制約と、内容の正しさを分けて考える必要があります。
Google AI for Developers：構造化出力
ツール呼び出しは処理の候補と引数を受け取る
ツール呼び出しでは、利用できる関数の目的や引数をモデルへ伝え、必要に応じて関数名と引数を受け取ります。例えば最新の注文情報を取得する、担当部署の一覧を調べるといった外部データへの接続に使えます。
GoogleのFunction calling資料は、モデル自身が関数を実行するのではなく、アプリケーションが引数を取り出して実行する責任を持つと説明しています。SDKによって自動実行の補助があっても、呼び出せる処理と実行条件を決める側の責任が消えるわけではありません。
Google AI for Developers：Function calling
スポンサーリンク
問い合わせ分類だけなら実行ループを増やさない
管理画面に分類の候補を出すだけなら、構造化出力を受け取り、検証して表示する構成から始められます。外部サービスへの書き込みをAIに選ばせないため、実行結果の確認や複数回のツール往復を持たずに済みます。
一方、問い合わせを見て現在の契約状態を調べ、その結果で次の案内を変えるなら、ツール呼び出しが役立つ場面があります。契約情報を取得して結果をモデルへ戻すことで、入力文だけでは分からない条件を補えます。
本サイトからは、最初に「必要なのは整ったデータか、外部情報の取得か、状態の変更か」を書き出すことを提案します。一つのAI呼び出しへ分類と調査と保存を詰め込むより、段階を分けた方が、失敗時にどこを直すべきか追いやすくなります。
スキーマは業務で使える契約として設計する
説明用の問い合わせ分類では、categoryをbilling、technical、otherのいずれか、summaryを要約、needs_clarificationを確認の要否として定義できます。ただし、これらの項目名や選択肢は仮想例です。実際の担当部署や業務に合わせて決めてください。
項目を増やすと、モデルも利用者も埋める負担が増えます。後続処理で使わない推定値を、念のために大量に生成させる必要はありません。まず保存や画面表示に必要な最小限の項目を決め、各項目に何を入れるのかを具体的に説明します。
「優先度が高い」という値を持つなら、システム停止、通常の相談、営業案内などの基準も定義します。モデルの雰囲気による判定を、そのまま対応期限へ結びつけないでください。影響が大きい項目は、確定値ではなく確認候補として扱う方法があります。
スポンサーリンク
不明を表現できない設計は推測を誘う
問い合わせ文に製品名が書かれていないのに、必ず製品を一つ選ばせると、誤った候補で埋まることがあります。不足している情報を、空文字、null、unknownなどのどれで表すかをアプリ全体で決めておきます。
どの欠損表現を使えるかは、利用するAPIやスキーマの対応範囲に依存します。独自に使えるはずと考えず、実際に受け付けられる形式を確認してください。データベース側の必須項目とも整合させ、未確定の分類を無理に確定レコードへ変換しないことを提案します。
また、モデルが返した確信度を、検証済みの確率として扱わないようにします。数値を付けたから信頼性が測れたとは限りません。自分たちの評価データで誤りとの関係を確認できない段階では、根拠や不足条件を表示する方が役立つ場合があります。
最小の出力例を使って担当者と合意する
説明用のJSONは、categoryがtechnical、summaryが「ログイン画面が開かない」、needs_clarificationがtrue、product_idがnull、といった形になります。この時点では、製品を確定したり、担当部署へ送信したりしていません。入力を整理して、何が足りないかを示している段階です。
担当者には、正常な例に加えて、どの値なら保存を止めるかを見てもらいます。例えば存在しないcategory、要約のないレコード、確認が必要なのに製品を断定したレコードを用意し、期待する振る舞いを確認します。これによって、モデルへの説明とアプリの検証条件を一緒に固められます。
スキーマを設計する担当者と、画面や保存処理を作る担当者が別でも、具体的な入力と出力があれば認識を合わせやすくなります。形式を決めて終わらせず、値を受け取った後の動作まで一つの仕様としてレビューしましょう。
構文の次に業務上の値を検証する
JSONの読み込みに成功し、型が一致しても、存在しない製品IDや過去の日付が入り得ます。スキーマ検証の後に、実際の製品一覧、日付の範囲、担当部署、依頼者が選べる契約などを照合します。
本サイトでは、検証を三段階に分けることを提案します。第一に形式と型、第二に項目同士の整合性、第三に業務データとの照合です。例えば確認が必要とされているのに、確定部署へ自動送信するような矛盾を、後続処理の前に止めます。
出力の検証は、プロンプトの改善とは別に残します。説明を詳しくすると誤りが減る可能性はありますが、アプリケーションが不適切な値を受け付ける設計まで正しくなるわけではありません。失敗を分類し、どの段階で止めたかを記録すると改善に使えます。
生成データと確定処理を別の状態にする
AIの提案を画面に表示する段階と、実際にチケットを作る段階を分けることを勧めます。提案データには入力との対応を残し、検証を通ったものだけを保存候補へ進めます。人が変更した内容があるなら、その変更を確定処理へ引き継ぎます。
モデルが作った引数へ、利用者IDや保存先の権限まで自由に決めさせる必要はありません。認証済みの利用者、組織、保存可能な範囲などは、サーバーが確認した情報を使います。単純な分類機能が、意図せず他の利用者のデータを書き換える構成へ広がらないようにします。
この境界を明確にすると、途中からツール呼び出しを導入する場合にも整理しやすくなります。「分類する」「必要な情報を読む」「保存する」という責務を分け、どこで自動化し、どこで確認するかを用途ごとに決められます。
スポンサーリンク
再試行は生成と書き込みで扱いを変える
形式が不適切な出力を作り直す処理と、結果が不明な書き込みをもう一度実行する処理は区別します。前者は候補の再生成ですが、後者はチケットの重複作成につながる可能性があります。
本サイトでは、書き込みに依頼を識別するキーを付け、同じ確定操作が再送されても結果を確認できる構成を提案します。通信が切れたら、まず保存済みかを照合し、未保存と確認できた場合に再実行する流れです。実装は保存先のAPIやデータベースの仕様に合わせます。
生成の再試行にも回数と時間の上限を設けます。分類不能な入力に対して、同じ生成を何度も繰り返しても改善しないことがあります。上限に達したら確認待ちへ回し、利用者に再入力を頼むなどの次の行動を決めておきましょう。
失敗の経路を用意してから公開する
本番では、生成の中断、応答の欠落、検証失敗、外部APIの停止などが起こり得ます。使うAPIで返る状態やエラーを確認し、正常なJSONだけが返る前提で画面を作らないことが必要です。
本サイトでは、読込中、候補を確認できる状態、追加情報が必要な状態、再実行できる失敗、担当者へ回す失敗を区別することを提案します。利用者には専門的な内部エラーをそのまま見せず、保存が完了したか、何をすればよいかを明確に伝えます。
特に、外部処理の成否が不明なときに「失敗しました」とだけ表示すると、利用者が何度もボタンを押すことがあります。操作を止める表示に加えて、状態を問い合わせる仕組みを持たせると、重複実行の扱いを整理しやすくなります。
スポンサーリンク
変更と評価をセットで管理する
スキーマへ項目を追加したり、選択肢を変更したりすると、画面や保存処理にも影響します。モデルの変更だけでなく、スキーマの変更もアプリケーションの契約変更として扱うことを提案します。
比較用の入力には、正常な相談、情報不足、複数の相談、無関係な内容、長文、表記揺れを含めます。形式に合った割合だけでなく、分類の正しさ、確認を求める判断、実行後の状態まで確認します。構造化されていることと、業務で使えることを別々に測ってください。
最初は分類候補の提示から始め、実データとの照合を加え、読み取りツールを導入し、必要な範囲だけ書き込みへ進めると段階を作れます。すべてをエージェント化することを目標にせず、用途に必要な責任と検証を持つ構成を選びましょう。
