Azure OpenAI Service の「構造化出力（Structured Outputs）」は、
LLMに文章を書かせるのではなく、業務システムがそのまま扱えるJSONを出させる
ための機能です。
これは生成AI活用において、非常に重要な転換点でした。
従来の使い方は、
自然文 → LLM → 自然文 → 人間が読む
でしたが、構造化出力を使うと
自然文 → LLM → 業務APIの引数(JSON) → システムがそのまま処理
になります。
つまり 「チャット」から「業務自動化」へ変わります。
Contents
実務に寄せた例：自然文から「稟議申請JSON」を作る
例えば、社員がこう入力したとします。
「来週の大阪出張のため、新幹線とホテル代で8万円の出張申請を出したいです。目的は展示会参加です。」
これを、社内の稟議APIにそのまま渡せるJSONに変換させます。
出力させたいJSONは以下のとおりです。
{
"applicant": "string",
"purpose": "string",
"amount": 0,
"destination": "string",
"date": "YYYY-MM-DD"
}
コード全体
from openai import AzureOpenAI
from dotenv import load_dotenv
import os
from pydantic import BaseModel
load_dotenv(override=True)
api_key = os.getenv("GPT5_MINI_OPENAI_API_KEY")
api_version = os.getenv("GPT5_MINI_OPENAI_API_VERSION")
azure_endpoint = os.getenv("GPT5_MINI_AZURE_OPENAI_ENDPOINT")
deployment = os.getenv("GPT5_MINI_AZURE_DEPLOYMENT")
client = AzureOpenAI(
api_key=api_key,
api_version=api_version,
azure_endpoint=azure_endpoint,
)
messages = [
{
"role": "system",
"content": "あなたは与えられたJSON Schemaに厳密に従って、稟議申請APIの引数を構造化して返してください。"
},
{
"role": "user",
"content": "来週の大阪出張のため、新幹線とホテル代で8万円の出張申請を出したいです。目的は展示会参加です。申請者は佐藤です。"
}
]
response = client.chat.completions.create(
model=deployment,
messages=messages,
response_format={
"type": "json_schema",
"json_schema": {
"name": "travel_expense_request",
"strict": True,
"schema": {
"type": "object",
"properties": {
"applicant": {
"type": "string",
"description": "申請者名"
},
"purpose": {
"type": "string",
"description": "出張の目的"
},
"amount": {
"type": "integer",
"description": "申請金額（円）"
},
"destination": {
"type": "string",
"description": "出張先"
},
"date": {
"type": "string",
"description": "出張日 (YYYY-MM-DD)"
}
},
"required": ["applicant", "purpose", "amount", "destination", "date"],
"additionalProperties": False
}
}
}
)
print(response.choices[0].message.content)
実行結果（例）
{
"applicant": "佐藤",
"purpose": "展示会参加",
"amount": 80000,
"destination": "大阪",
"date": "2026-02-20"
}
この形式であれば 稟議APIにPOST可能 です。
人間は一切JSONを書いていません。
なぜこれが「AIチャット」ではなく「AIエージェント」なのか
この仕組みは、単なるチャットではありません。
LLMは 文章を生成しているのではなく
業務システムのインターフェースに合わせて、厳密なデータを生成している
のです。
つまりこれは
- RAGでもない
- 要約でもない
- チャットでもない
業務APIの自動入力エンジン です。
Pydanticと組み合わせるとさらに強い
class TravelExpenseRequest(BaseModel):
applicant: str
purpose: str
amount: int
destination: str
date: str
このモデルにそのまま流し込めます。
LLMの出力を アプリケーションの型に直結 できるのがポイントです。
実務での本当の使い所
このパターンは以下のような応用が可能です。
- 問い合わせメール → チケット発行JSON
- 議事録 → タスク登録JSON
- 日報 → 工数登録JSON
- チャット → DB登録JSON
生成AIの活用が進まない理由の一つに
「文章は出るけど、システムに繋がらない」
構造化出力はその課題を解決します。
まとめ
Azure OpenAI Service の構造化出力は、
自然文を、業務システムの入力に変換するための機能
です。
「チャット構築」から「業務の自動化」 へ移行するための、重要な機能です。
