AIの答えを決まった形で受け取る方法｜後工程に流せる出力に

「同じ指示で動かしているのに、返ってくる答えの形が毎回そろいません」「表に貼り付ける係が、結局ひとり必要になってしまって」——AIの出力を業務の流れに載せようとした部署から、決まって上がってくる報告です。指示の書き方を工夫すれば形はそろうと考えて、例文を足し、念を押す一文を加え、それでも月に何度かは外れる。この繰り返しに入っている会社は少なくありません。ですが、答えの形は指示の書き方で整えるものではなく、受け取る側の枠を先に渡して固定するものです。この記事では、その枠をどう決めて、外れて返ってきたらどう扱い、枠を変えるときに何が壊れるのかまでを、順を追って整理します。

「うまく頼めば形はそろう」が、なぜ外れ続けるのか

AIに指示を出すとき、私たちは「箇条書きで」「表の形で」「項目名は次の5つで」と書きます。ほとんどの回はそのとおりに返ってきます。問題は、ほとんど、が100%ではないことです。100件のうち3件だけ項目が1つ多い、あるいは金額の欄に単位が付いている。この3件のために、100件すべてを人が見る運用に戻ります。

外れる理由は単純で、指示は依頼であって制約ではないからです。文章で頼んだ内容は、答えを作る過程で参照される材料のひとつにすぎません。頼み方を強めても、参照の重みが少し増えるだけで、従うことが保証されるわけではない。例文を増やしても、念を押しても、この性質は変わりません。

だから打ち手の方向を変えます。「従ってもらう」のではなく「従う以外の出力ができない状態にする」。枠から外れた答えを、そもそも作らせないようにするという考え方です。これは指示の改善の延長ではなく、別のやり方です。次の節から、なぜそこまでする必要があるのかと、具体的に何を決めるのかを見ていきます。

形がそろわないと、止まるのは後工程のほう

形の乱れが問題になるのは、AIの側ではありません。受け取った答えを次に流す仕組みの側です。問い合わせを分類して担当に振り分ける、見積の条件を台帳に登録する、記事の要点を管理表に入れる。どの流れも、決まった場所に決まった型の値が入っていることを前提に作られています。項目がひとつ増えただけで、受け取る側は止まります。

止まり方には2種類あります。エラーになって止まるほうは、まだ扱いやすい。厄介なのはそのまま通ってしまうほうです。金額の欄に「約12万円」という文字が入っても、文字として受け取れる作りなら通ります。通った後、集計の段階で数が合わなくなり、原因をさかのぼるのに半日かかる。形の乱れは、離れた場所で表に出ます。

そして現場では、たいてい人がこの隙間を埋めます。返ってきた答えを見て、形を整えて、次に渡す。1件30秒でも、日に200件なら1時間40分です。形を直す係が1人張り付いた時点で、その工程は自動化されていないと見るべきです。AIを入れる前と後で、担当者の仕事が「作る」から「直す」に変わっただけ、という状態になります。

形を決めるとは、お願いではなく枠を渡すこと

では枠を渡すとは何をすることか。JSONスキーマ（JSON Schema）という仕組みがあります。公式の説明では、データの構造と制約を宣言的に定義する言語とされています。用途として挙げられているのは、受け取ったものが定義に沿っているかの検証、機械と人の双方が読める文書の生成、そして検証規則によるデータ品質の維持です。仕様は版を重ねていて、現在の最新版は2020-12です。

この定義を推論の呼び出しに添えると、モデルの出力をその定義に従わせることができます。マイクロソフトが公開している説明（2026年8月24日付）は、この仕組みを説明したうえで、旧来のやり方は妥当な形式であることは保証したが、渡した定義への厳密な適合までは保証できなかったと明記しています。形式として壊れていないことと、こちらが決めた形に合っていることは、別の保証だということです。

実務上の意味は大きい。枠に入らない答えは出てこないので、受け取る側は「来るかもしれない例外」を想像して作らなくてよくなるからです。とはいえ、この枠が何をどこまで固定できるのかには、はっきりした線があります。その線を知らずに導入すると、固定できたつもりの箇所が固定されていません。以下、決め方を追いながら、線がどこにあるかも合わせて見ていきます。

枠で決められるのは4つ：項目・型・必須・選択肢

枠に書けることは多くありません。実務で決めるのはどんな項目を置くか、その項目に入るのは何か、空を許すか、答えが決まっているものは一覧から選ばせるかの4つです。この4つをきちんと決めるだけで、現場で起きている乱れの大半は消えます。

決められること	決める内容	決めないと何が返ってくるか
項目	答えに含める箱の名前と、その並び	ある回だけ項目が増え、ある回だけ消える
型	その箱に入るのが数か、文字か、真偽か	同じ金額が、ある回は数、ある回は単位付きの文字で返る
必須	空を許すのか、必ず何かを埋めさせるのか	受け取る側が、値が無いのか空なのかを判断できない
選択肢	決まった答えの一覧から選ばせるかどうか	分類の呼び名が回ごとに言い換えられ、集計が合わなくなる

この表で見落とされやすいのは3行目の「必須」です。空を許すかどうかは、受け取る側の作りを左右します。読み取れなかったのか、そもそも無かったのかを、受け取る側が区別できる形にしておくと、後工程の分岐が単純になります。逆にここが曖昧だと、空欄の意味を担当者が推測する運用に戻ります。

形を決めて受け取るまでの6段階

決める順番があります。項目を先に広げてから絞るのではなく、後工程から逆算して必要なものだけを置くのが要点です。順番を守ると、後から項目を増やす回数が減ります。以下の6段階は、情報システム部門とAIの導入を進める担当が、同じ場で通すことを想定しています。

この6段階のうち、現場で飛ばされやすいのが4番目と6番目です。どちらも作っている最中には必要性を感じないからです。空の扱いは最初の数週間は問題になりませんし、版は項目を変えるまで出番がありません。ですが、この2つを後から足すのは、最初に決めるより手間がかかります。

段階1：後工程が本当に使う項目だけを数える

最初の作業は、項目を並べることではなく減らすことです。受け取った後に誰がどう使うかを言えない項目は、置かない。これを徹底すると、想定の半分くらいまで減るのが普通です。問い合わせの仕分けなら、区分と緊急度と連絡先があれば動きます。要約や所感は、後工程が使っていないなら不要です。

項目を減らすことには実利があります。項目が多いほど、どれか1つが外れる確率は上がるからです。5項目の答えより15項目の答えのほうが、検査に落ちる回数は増えます。落ちれば人が見ることになる。多く取るほど自動で流れる割合が下がる、という関係になっています。

並びも決めます。受け取る側の項目の順序は、渡した定義の順序に従います。つまり並びを変えたければ、渡す定義の側の並びを変えることになります。人が目で確かめる場面があるなら、確かめる順に並べておくと点検が速くなります。項目の数と並びは、後工程の作業の順番から決めると、現場の手戻りが減ります。

段階2：型を決める——数と文字と日付を混ぜない

扱える型は限られています。文字、数値、真偽、整数、まとまり、並び、そして決まった選択肢と、いくつかの型のいずれか、という指定です。ひとつ制約があって、いちばん外側のまとまりを「いずれか」にはできません。つまり答え全体の形が2通りある、という設計は取れない。答えの形はひとつに決めて、中で分岐させることになります。

型で最も事故が多いのは金額と日付です。金額を文字にすると、単位や区切り記号や「約」という語が混ざります。数にすれば混ざりません。一方で日付には専用の型がないので、文字として受け取ることになります。文字として受ける以上、形式は枠では固定できません。ここは受け取った後の検査に回す部分です。

真偽の型も便利ですが、使いどころを誤ると情報が落ちます。「該当する・しない」の2択にすると、判断できなかったという3つ目の状態が消えます。読み取れなかった場合を区別したいなら、選択肢の一覧にして3つ並べるほうが安全です。2択にしてよいのは、判断できないという状態が業務上ありえない項目だけだと考えてください。

段階3：答えが決まっているものは、一覧から選ばせる

分類、優先度、担当部門、対応の種別。答えの候補があらかじめ決まっているものは、必ず一覧にします。自由記述のままにすると、同じ内容が「見積依頼」「お見積り希望」「価格について」と言い換えられ、集計の段階で別物として数えられます。集計が合わない原因の多くはここです。

一覧を作るときの勘所は2つあります。ひとつは候補を増やしすぎないこと。20個の一覧は、選ぶ側にとって曖昧な区別を強いることになり、回ごとにぶれます。もうひとつは、どれにも当てはまらないときの受け皿を必ず置くことです。受け皿が無いと、無理にどれかへ寄せた答えが返り、その寄せが見えなくなります。

受け皿を置くときは、理由を書く欄を対にします。その他が選ばれた件数と理由の文面を月に一度眺めると、一覧に足すべき候補が現場の言葉で見つかります。一覧は最初に完成させるものではなく、その他の中身を読みながら育てるものです。育てた結果として一覧を変えるときは、後述する版の話につながります。

段階4：任意の項目は作らない。空も一つの答えにする

枠の仕組みには、少し変わった制約があります。すべての項目を必須にする必要がある、というものです。任意の項目という扱いは用意されていません。ではどうするかというと、空を許す型との組み合わせで表現します。つまり「あってもなくてもよい項目」ではなく「必ず返ってくるが、中身が空の場合がある項目」として設計します。

これは制約に見えて、実務では利点のほうが大きい。受け取る側が、項目の有無を確かめる処理を持たなくてよくなるからです。項目は必ず来る。中身が空かどうかだけを見ればよい。任意の項目を許すと、受け取る側は「無い場合」と「空の場合」の2通りを常に想定することになり、分岐が増えます。

設計のときに決めるのは、どういうときに空になるのかのほうです。元の文章に書かれていなかったのか、書かれていたが読み取れなかったのか。この2つを区別したいなら、空にするのではなく選択肢の一覧で「記載なし」と「判読不能」を分けます。空の意味を決めずに空を許すと、後工程で担当者が推測する運用に戻るので、ここは短くても書き残しておいてください。

枠には天井がある——100項目・5階層という上限

枠は無限に複雑にできるわけではありません。マイクロソフトの説明には、まとまりの中の項目は合計で100個まで、入れ子は5階層までという上限が示されています。加えて、定義していない項目の追加を認めない設定を必ず入れること、とも書かれています。この設定を外すと、決めた以外の項目が混ざる余地が残ります。

100項目という上限は、一見すると余裕があります。ただし入れ子の中の項目もすべて数に入るので、明細の行を持つような答えではすぐ近づきます。5階層の制限も同じで、まとまりの中にまとまりを置く設計を重ねると届きます。上限に近づいたら、ひとつの答えに詰め込みすぎている合図だと考えて、問いを分けるほうが結果的に安定します。

いくつか使える仕掛けもあります。同じ形を何度も書かずに定義を使い回すこと、そして入れ子が自分自身を参照する形も使えます。ただし読み手の側の負担は上がります。枠は後で人が読んで意味を確かめるものなので、短く保てる範囲で作るのが実務的です。凝った枠は、作った人が異動した時点で誰も触れなくなります。

形は固定できても、値の中身は固定できない

ここがこの記事でいちばん大事な線です。枠で固定できるのは、項目と型と選択肢までです。それ以外の条件は、指定しても効きません。マイクロソフトの説明には、効かない指定が型ごとに一覧で示されています。文字については最小と最大の長さ、決まった並び、書式。数値については最小と最大、倍数。並びについては件数の上下限や重複の禁止です。

これが何を意味するか。「金額は0以上」「日付は年月日の8桁」「要点は120字以内」「候補は3件まで」といった条件は、枠に書いても守られません。守らせたいなら、受け取った後に自分で検査する必要があります。ここを勘違いすると、枠を入れたから大丈夫だと思ったまま、範囲外の値が後工程へ流れ続けます。

そしてもうひとつ、より根本的な線があります。形が正しいことと、書かれている内容が正しいことは無関係です。存在しない会社名が、正しい型の文字として返ってくることがあります。枠は、答えの形を保証するだけで、答えの真偽には何も言っていません。形の検査と、中身の検査は別の工程として置く。この2つを混ぜて考えている限り、自動で流す範囲を安全に広げることはできません。

中身の検査をどこに置くかも、あわせて決めます。受け取った直後の一か所にまとめるのが、いちばん管理しやすい形です。見るのは三つで足ります。値が決めた範囲に収まっているか、項目どうしで矛盾していないか、そして元の文章に無い値が入っていないか。三つ目がいちばん効きます。渡した文章に一度も出てこない社名や日付が入っていたら、その一件は人に回す。この一つの規則だけで、後工程へ流れる誤りはかなり減ります。逆に検査を後工程のあちこちに散らすと、同じ確認が重複したうえに、どこで落ちたのかを追えなくなります。

外れて返ってきたときに、やり直すか人に回すか

形の検査に落ちたもの、あるいは中身の検査に落ちたものをどうするか。選択肢は3つです。同じ問いをもう一度投げる、欠けたまま人に回す、その件を処理せず記録だけ残す。どれを選ぶかは項目ごとに変わります。ここを決めずに運用に入ると、現場が毎回その場で判断することになります。

やり直しを選ぶときは、回数の上限を決めます。上限が無いと、同じ問いで詰まった件が延々と処理を消費します。2回で切って人に回すのが素直です。そして、やり直して通ったときにも記録は残します。1回目で通った件と2回目で通った件の比率は、枠の作りが厳しすぎるかどうかの手がかりになります。

人に回すときは、どこが外れたのかを添えて回すことが要点です。答え全体を渡して「確認してください」と言うと、受け取った人は最初から全部を読みます。区分の欄が一覧に無い値だった、と分かっていれば、見るのは1か所で済みます。外れた箇所を特定して渡すだけで、人が見る時間は数分の1になるので、検査の仕組みを作るときに合わせて用意しておいてください。

項目を足す・消すと、何が壊れるか

運用が始まると、必ず項目を変えたくなります。ここで壊れるものが3つあります。受け取る側の処理、過去の記録との比較、そして人が作った手順書です。項目を1つ足すだけでも、この3つすべてに影響が出ます。だから枠には版をつけ、変えるときの手順を決めておきます。

項目を足す場合は、比較的おだやかです。受け取る側が知らない項目を無視する作りなら、古い処理でも動き続けます。厄介なのは消すときと、意味を変えるときです。項目名はそのままで中身の定義だけ変える、というのが最も事故を呼びます。受け取る側は形が合っているので何も気づかず、数か月後に集計の傾向が変わって初めて発覚します。

手順としては、消す前にその項目を誰が使っているかを数えるところから始めます。後工程の処理、定例の集計、担当者が個別に作った表。3つ目が抜けがちです。項目の変更は、枠を直す作業ではなく、後工程と足並みをそろえる作業だと位置づけると、通知の相手を取りこぼしません。変更した日と版は、記録の側にも残しておきます。

拒否と途中打ち切りは、形の失敗とは別物

枠に沿わせていても、答えが返ってこない場合があります。ひとつは拒否です。内容の方針に照らして答えられないと判断されたとき、通常の答えとは別の枠で拒否が返ります。マイクロソフトの例でも、拒否が入っているかを先に確かめ、入っていれば処理を止める形が示されています。これを見ずに進むと、拒否の文言が答えの欄に入ったものとして扱われかねません。

もうひとつは途中での打ち切りです。答えの長さに上限があるため、長い答えは途中で切れます。切れた答えは形としても不完全になるので検査には落ちますが、原因が「形の決め方が悪い」ではなく「量が多すぎる」である点が違います。対処も違って、枠を直すのではなく、問いを分けるか、答えに含める件数を減らすことになります。

加えて、この仕組みが使えない場面もあります。自前のデータを持ち込む構成、一部のエージェントの仕組み、一部の音声のモデルでは併用できません。複数の道具を同時に呼び出す指定とも併用できないと明記されています。枠を前提に設計を進める前に、使う予定の構成で併用できるかを先に確かめる。ここを後回しにすると、作り込んだ後に設計をほどくことになります。

導入を決める前に、確かめておく項目がもう一つあります。この仕組みが働くのは、ある時期以降のモデルと、ある版以降の呼び出し方に限られるという点です。先のマイクロソフトの説明には、対応が始まった版と、対応するモデルの一覧が明示されています。手元の環境が古い版のまま止まっていると、形の定義を添えても効かず、以前と同じ運任せの状態が続きます。しかも定義が無視されただけでは、目に見える失敗が起きません。たまたま形の合った答えが返り続け、月に何度か外れる、という以前と同じ景色になります。検討に入る前に、使っている道具がその一覧に入っているかを情報システム部門に一行で確かめておいてください。

AIに任せてよい工程と、人が決める工程

枠の作成そのものは、AIに下書きさせて構いません。後工程の表の項目から枠の下書きを起こす、選択肢の一覧の候補を出す、その他に入った文面をまとめて傾向を出す。このあたりは人がやると数時間かかるものが十数分で形になります。既存の表を渡して形を起こさせる使い方は、素直に効きます。

一方で、人が決める場所もはっきりしています。どの項目を残すか、選択肢に何を並べるか、空の意味をどう定めるか、そして外れたものを人に回すか捨てるか。いずれも業務の側の都合で決まるもので、答えの中には入っていません。とくに選択肢の一覧は、決め方しだいで集計の意味が変わります。

• 選択肢の一覧と、空の扱いは、AIの提案をそのまま採らない。決めた人と日付を記録に残す
• 枠の下書きをAIに作らせたら、後工程の担当が項目ごとに使い道を言えるかを1つずつ確かめる
• 形の検査に落ちた件をAIに判定させて自動で通さない。落ちたものは人か、決めた規則で分ける
• 中身が正しいかの確認をAIにさせると甘くなる。金額や社名など、間違うと影響が出る項目は原典で照合する

4つ目は実務で最もよく崩れます。答えの検算を同じ仕組みにさせると、形も理屈も整った検算が返ってくるからです。整った検算は、正しい検算とは限りません。人が確かめる範囲を先に決めておいてください。全項目を見る必要はなく、間違うと影響が出る数項目に絞れば、確認は現実的な時間に収まります。

つまずく決め方と、相談の場で通じる言い換え

最後に、導入時につまずきやすい決め方を並べます。どれも枠の技術的な誤りではなく、決める順番と役割の置き方の問題です。着手前に一度目を通しておくと、作り直しが減ります。

• あると便利そうな項目を全部入れる：項目が増えるほど検査に落ちる回数が増え、自動で流れる割合が下がる
• 分類を自由記述のままにする：同じ内容が回ごとに言い換えられ、集計の段階で別物として数えられる
• 値の範囲や書式を枠に書いて安心する：これらの指定は効かないので、範囲外の値がそのまま後工程へ流れる
• 版をつけずに項目を変える：どの版で作られた記録かが分からなくなり、過去との比較ができなくなる
• 形の検査に通ったものを正しいものとして扱う：存在しない社名でも、型が合っていれば検査は通る

相談の場では専門の言葉が飛び交います。噛み合わないまま決めると、後から認識の食い違いが出ます。次の言い換えを手元に置いておくと、情報システム部門との打ち合わせが進めやすくなります。

打ち合わせで出てくる言葉	意味	決めるときに効く言い換え
構造化出力	渡した形の定義に、AIの答えを従わせる仕組み	形から外れた答えは、そもそも出てこない状態にすること
JSON	項目名と値の組で書き表す、機械が読みやすい書き方	後工程がそのまま読み込める書き方
スキーマ	項目・型・必須・選択肢を書いた、形の定義そのもの	受け取る側の枠
検証	返ってきた答えが、決めた枠に収まっているかの確認	形の検査。中身の検査とは別物
版	枠そのものにつける番号。項目を変えたら上げる	後工程と足並みをそろえるための番号

実際に決めるときは、枠の中身を専門の記法で見せる必要はありません。日本語で項目を並べた紙を1枚作り、それを情報システム部門に渡せば足ります。たとえば問い合わせを仕分ける枠なら、次のような並びになります。

問い合わせ1件につき返してもらう項目
  区分     … 見積依頼 / 不具合 / 解約 / その他 のいずれか1つ
  緊急度   … 高 / 中 / 低 のいずれか1つ
  会社名   … 文字。読み取れなければ空
  希望日   … 年月日を表す文字。記載が無ければ空
  要点     … 文字。長い場合は受け取った側で切る
  判断不能 … 該当する / しない のいずれか1つ

この紙があれば、情報システム部門は枠の形に起こせますし、後工程の担当は使い道を確かめられます。決めるのは業務の側で、記法に直すのは情報システム部門の側、という分担にすると、打ち合わせが短くなります。決めた紙は版をつけて残し、項目を変えるときはこの紙から直してください。

まとめ

AIの答えを後工程に流せる形で受け取るために要るのは、指示の書き方の工夫ではありません。受け取る側の枠を先に渡して、枠から外れた答えが出てこない状態にすることです。枠で決めるのは項目・型・必須・選択肢の4つで、後工程が実際に使う項目だけに絞り、答えが決まっているものは一覧から選ばせ、空になる場合の意味を書き残します。同時に、枠には天井があり、値の範囲や書式や件数は固定できないことも押さえておく。形が合っていても中身が正しいとは限らないので、形の検査と中身の検査は別の工程として置きます。まずは、いま人が形を直している出力をひとつ選んで、後工程が本当に使っている項目を数え直すところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。