♪♪ きほん｜返信案と確認事項を、迷わず受け取るために
「APIでAIに依頼して、結果を受け取る。そこまではわかった！」
第6話を終えた、ほんねくん。返信支援アプリの画面に「顧客向けの返信案」と「社内向けの確認事項」を分けて表示しようと考えます。
でも、AIの回答が毎回長い文章で返ってくると、どこまでが返信案なのか、プログラムはどう判断すればよいのでしょうか。
「人には読めても、アプリには取り出しにくいんだね」
そこで登場するのが、JSONです。今回も、架空の研修会社「まなびサポート」を例に考えます。😊
結論：情報に名前を付けて、決めた形で渡す
JSONはJavaScript Object Notationの略で、構造のあるデータを表すテキスト形式です。JavaScript以外の言語でも使われ、Webアプリのデータ交換などで利用されます。[1]
このシリーズで「共通言語」と呼ぶのは、AIとアプリが同じ項目名と形式で情報を受け渡す、という意味です。JSONそのものが、AIの考え方や正しさを保証するものではありません。
返信案に「reply_draft」、確認事項に「check_items」と名前を付ければ、アプリ側は対応する値を取り出して、別々の欄に表示できます。
① 「キー」と「値」を読んでみよう
まず、次の例を見てください。これは説明用に作成したデータで、APIで得た実測結果ではありません。
{
"reply_draft": "お問い合わせありがとうございます。研修料金は現在未定です。",
"check_items": [
"料金の確定時期を社内で確認する"
],
"needs_confirmation": true
}コロンの左側にある「reply_draft」などがキー、右側にある文章や配列などが値です。
| キー | 受け取る値 | 画面での使い方 |
|---|---|---|
| reply_draft | 返信案の文字列 | 顧客向け下書き欄に表示 |
| check_items | 確認事項の配列 | 社内向け欄に一覧表示 |
| needs_confirmation | trueまたはfalse | 追加確認の目印に使う |
キー名はアプリの設計で決めます。英語でなければならないわけではありませんが、今回は上の名前で統一します。
「needs_confirmation」が表すのは、追加の確認事項があるかです。falseでも、人の確認を省いて自動送信してよい、という意味にはしません。
② 最初に覚えたい、書き方のルール
JSONでは、次の記号と値をよく使います。[1]
- { }：キーと値をまとめるオブジェクト。
- [ ]：複数の値を並べる配列。
- " "：キーや文字列を囲む、半角のダブルクォーテーション。
- true・false：真偽値。文字列と区別し、引用符を付けない。
項目はカンマで区切りますが、最後の項目の後にカンマは付けません。JSONの中にコメントを書くこともできません。
ほかに数値やnullも扱えます。null、空文字列、項目そのものがない状態は別なので、必要に応じて意味を決めます。今回の確認事項がなければ、文字列の「なし」ではなく、空の配列 [ ] を返す約束にします。
なお、画面に表示した例の見出しやコード枠は説明用です。JSONデータとして読む対象は、波かっこから始まる中身だけです。
③ JSONの文字列と、プログラム内のデータは別
見た目が似ていても、通信などで受け取ったJSONのテキストと、プログラム内で項目を扱うデータは区別します。
JavaScriptでは、JSONのテキストを読み取るときにJSON.parse()、データをJSONのテキストにするときにJSON.stringify()を使えます。[1][2]
受け取った文字列をそのまま実行するのではなく、JSONとして解析してから項目を取り出します。構文に誤りがあれば、解析に失敗することがあります。
ただし、ライブラリや通信方法によっては、すでに解析されたデータが返ります。何を受け取ったか確認せず、毎回parseするわけではありません。
「文章から『確認事項』を探すより、決まった名前の項目を読む方が扱いやすいね！」
④ 「JSONで返して」と頼むだけで大丈夫？
指示だけでJSONを求めると、前置きが付いたり、項目名が変わったりする可能性があります。文章の見出しをそろえるだけよりも、アプリが期待する形式を明確にしておくことが大切です。
対応するAPIでは、構造化出力を使って、出力の形式を指定できます。Gemini APIにもJSON Schemaに基づく構造化出力があり、対応する仕様の範囲は公式資料で確認します。[3]
スキーマは、どんな項目や型を持つデータにするかを定めるルールです。今回なら「reply_draftは文字列」「check_itemsは文字列の配列」「needs_confirmationは真偽値」と決めます。
さらに、3項目を必須にするか、長さをどこまで許すかなども設計します。ただし、指定した形式に合っていても、内容が正しいとは限りません。[3]
資料にない料金を、それらしい返信文として文字列に入れてしまえば、JSONの形が正しくても業務上は不合格です。
⑤ 受け取った後は、3段階で確かめる
ほんねくんのアプリでは、次の3段階で確認する設計にします。
- 構文：JSONとして読み取れるか。
- 項目と型：必要なキーがあり、文字列・配列・真偽値が約束どおりか。
- 内容：研修案内と一致し、根拠のない料金や約束がないか。
形式の検査はプログラムで行い、内容は第4話の合格基準でも確認します。足りない項目や型の違いがあったら、正常な返信案として扱わず、確認用の案内を出します。
AIの文章を画面に出すときも、下書きは文字列として扱います。HTMLとしてそのまま挿入せず、表示の安全性を考えることも、実装時の確認点です。
「形をそろえることと、仕事として合格すること。両方が必要なんだ！」
今日の実践：確認事項がない場合を作ってみよう
5分ほどで、同梱のJSON例を見ながら、次の状態へ書き換えてみてください。
- 返信案を「研修はオンライン開催で、所要時間は90分です。」にする。
- 確認事項を空の配列にする。
- 追加確認の目印をfalseにする。
これは、第4話の架空の研修案内に合わせた練習です。人の送信前確認は残します。
さらに、falseを "false" にしたら何が違うか考えてみましょう。どちらもJSONの構文としては有効ですが、後者は真偽値ではなく文字列です。今回のスキーマでは、型の検査で止める対象になります。
🍀 今日の理解
JSONは、情報に名前を付け、決めた形式で渡すためのテキスト形式。受け取った後は、構文・型・内容を確認する。
🔍 ほんねチェック
JSONとして読めたからといって、そのまま送信や保存へ進めないこと。型や必要項目を確認し、内容には人の確認も残しましょう。
📝 会社づくりメモ⑦
- 返信支援で受け取る項目名は？
- 各項目の型と、空の場合の表し方は？
- 不正な形式のときは、どう止める？
- 顧客向けの返信案と、社内向け情報をどう分ける？
次回：GAS＋AIで、問い合わせの返信案を作ろう
画面、API、JSONをつなぎ、担当者が確認できる小さな試作品へ進みます。
シリーズ案内：全24話。原則1日1話、休みを挟みながら進めます。
前回：第6話「APIはAIへの窓口！鍵と利用制限を知ろう」
参考資料（2026年10月19日確認）
- [1] MDN：Working with JSON — データ形式と基本の記法。
- [2] MDN：JSON.parse() — JSONテキストの解析。
- [3] Google AI for Developers：Structured outputs — 構造化出力と内容の検証。