自由記述アンケートは AI の要約で数えない｜BigQuery で分類の案を出させ、回答ごとに分類を付けた表から数える

解約アンケートの自由記述を AI にまとめさせると、理由が見出しつきできれいに並び、頼めばそれぞれの件数まで添えてくれます。その件数を、そのまま会議の資料に載せてよいのでしょうか。

先に答えを書くと、資料に載せる件数は、要約に書かれた数ではなく、回答ひとつに分類をひとつ付けた表から数えた数にします。アンケートや問い合わせの自由記述を AI でまとめて報告に使う、マーケティング・CS・商品企画の担当者に向けて、そう言える理由と、分類の決め方、要約の使いどころを順に書きます。

以下の図と数字は、BigQuery の導入とデータ分析を支援している当社が、架空の解約アンケートを検証用の BigQuery に入れて試した結果です。

要約は理由を8つ並べたが、どれが多いかは書いていなかった

使ったのは、ミールキットの定期便の解約時アンケートで「解約の理由を教えてください」という質問に寄せられた自由記述200件です。答え合わせができるように、回答を作るときに、どの回答をどの分類に入れるかも決めてあります（以下、「決めておいた分類」と書きます）。この回答を BigQuery の表に入れ、AI 関数に、どんなアンケートの回答かを1文で伝えたうえで「解約の理由を要約してください」と頼みました。件数や書き方の指定はしていません。

返ってきた要約は、理由を8つの見出しに分けていました。価格・コスト、量やお届け頻度、メニュー・味、調理の手間、配送・受け取り、サイトの使い勝手・サポート体制、ライフスタイルの変化、その他です。見出しの下には「冷蔵庫や冷凍庫が圧迫される」「電話がつながらない」のような具体的な中身も書かれていて、どんな理由があるのかは、これを読めばつかめます。

書かれていないのは、それぞれの理由がどれだけあるかです。件数は一つも出てきません。手がかりになるのは言い方くらいです。1回目の要約では、価格と量の項目に「多く見られます」「多く寄せられています」とあり、ほかの項目の多くは「意見があります」「指摘があります」のような書き方でした。ここから分かるのは、価格と量が多いらしいということまでです。どちらが多いのか、ほかの理由とどれくらい差があるのかは分かりません。

決めておいた分類で数えると、いちばん多いのは量・届く頻度の44件で、価格・送料の36件が続きます。要約は、価格を1番目、量を2番目に書いていました。同じ頼み方でもう一度実行すると、見出しの言い回しは少しずつ違いましたが、扱う理由と並びは同じで、8番目だけが「その他」から「お試し・一時的な利用」に変わりました。

この要約は「どんな理由があるか」を知るには役に立ちます。ただ「どれだけあるか」は書いていないので、並び順を多い順として報告に載せることはできません。

件数も書かせると数字は出る。ただ、合計は200件にならず、2回で順位が変わった

では、件数も書いてもらえばよいのでしょうか。同じ回答に「解約の主な理由を多い順に挙げ、それぞれ何件くらいあるかも書いてください」と頼み、2回実行しました。

今度は、見出しごとに「約35件」のような数字が付きました。量・届く頻度は2回とも約35件で1位です。ここまでは、もっともらしく見えます。

ところが、ほかの見出しを並べると様子が変わります。1回目は見出しが6つで、ライフスタイルの変化とお試し、配送とサイトの使い勝手を、それぞれ1つにまとめていました。2回目は8つです。価格は、1回目が約25件で2位、2回目が約18件で3位でした。2回目は、調理の手間（約20件）が価格より上に来ています。決めておいた分類で数えると、価格・送料は36件、調理の手間は18件です。メニュー・味は2回とも約15件ですが、数えると28件あります。

書かれた件数を足すと、1回目は115件、2回目は139件で、回答の200件になりません。要約の中では、1回目は件数を「言及されている回答の多さ」と説明し、2回目は「件数はおおよその目安です」と自分で断っています。どちらも、回答を1件ずつ数えた数として読むことはできません。2回目の「約18件」をそのまま報告すれば、決めておいた分類で数えた36件の半分を伝えることになります。

件数が要るなら、AI に件数を書かせるのではなく、回答の一つひとつに分類を付けてから数えます。そのためには、先に分類を決めなければなりません。

分類の案は AI に出させる。どの分類で数えるかは人が決める

分類を一から考えるのは手間なので、案は AI に出してもらいます。同じ回答に「この回答を理由ごとに数えるための分類の案を作ってください。1件の回答が1つの分類に入るように、5〜8個にしてください」と頼み、これも2回実行しました。

案はどちらも7個で、価格、メニュー・味、調理の手間、ライフスタイルの変化、配送、サイトの使いにくさは、2回とも分類になっていました。違ったのは残りです。

1回目の案には、量・お届け頻度の分類がありません。量が多すぎる・少なすぎるという理由は、「メニュー・味に関する理由」の説明の中に入っていました。この案のまま分ければ、決めておいた分類でいちばん多い量・届く頻度の不満は、独立した件数としては出てきません。2回目の案には量の分類がある代わりに、その他がありません。「特になし」「なんとなく」のように理由が書かれていない回答を、どれかの分類に入れるしかなくなります。どちらの案も、案のままでの分類は実行していません。

2回の案は、どちらもそれらしく見えます。それでも、2回の実行で中身が変わった案を、そのまま数える物差しにはできません。案は「回答にどんな理由が出てくるか」の下書きとして読み、どの分類で数えるかは人が決めます。

案を読みながら確かめるのは、まず、いちばん多そうな理由が、ほかの分類に混ざらず独立しているかです。案だけでは多いかどうかは分からないので、回答を数十件ほど読んで見当をつけます。もう一つは、サービスの側で手を打てる理由と、打てない理由が分かれているかです。引っ越しや転勤、家族構成の変化は、量や価格を見直しても変えられない理由です。分けておけば、対策を考える分類の件数が、そうした理由で膨らまずに済みます。2回の案は、どちらも「ライフスタイルの変化」を分類として立てていました（1回目の案は、調理の手間の説明にも「自炊する時間が取れなくなった」を入れていて、一部が重なっていました）。その他を作ること、回答ひとつに分類をひとつにすること、理由が2つ書いてある回答の扱いは、口コミを理由別に数える記事と同じ決め方です（この記事では、最初に書かれている理由に入れました）。最後に、分類ごとにどんな回答を入れるかの短い説明を書き、次の表を作るときに AI に渡します。

ここに人の手間がかかります。案と回答を読み比べ、分類と説明を決めるのは人の仕事で、要約を1回頼むだけの場合より作業が増えます。なお、この記事の8つの分類は回答を作るときに決めたもので、AI の案を見て選び直したものではありません。そのため、案から選び直すと件数の出方がどれだけ変わるかは、この記事の結果からは言えません。言えるのは、2回の案のどちらにも、そのまま数えると困る抜けがあったことです。

回答ひとつに分類をひとつ付けた表にしてから数える

決めた8つの分類と説明、理由が2つある回答の例を2つ渡して、200件の回答に AI で分類を付けました。結果は、回答の番号、回答、分類の列を持つ表として保存します。表の先頭の6行は次のとおりです。

この表があれば、数えるのは分類ごとに行を数えるだけです。足せば回答の件数と一致し、保存した表から数え直しても数字は変わりません。要約に書かせた件数との違いはここにあります。

表から数えると、量・届く頻度が45件、価格・送料が34件で、1位と2位は決めておいた分類と同じでした。価格・送料は、2回目の要約に書かれた約18件（1回目は約25件）ではなく34件です。分類が決めておいたものと一致したのは200件中193件でした。ただしこの一致は、分類の説明を、分類を決めた側が自分の基準で書いたうえでの数です。説明を書くのに使っていない回答で確かめれば、もっと下がることもありえます。

違う分類に入った7件のうち5件は、生活の変化に入っていました。「物価が上がって節約中です」「家計が厳しくなった」は、決めておいた分類では価格・送料です。「家族と相談して」「キャンペーンの期間だけ使うつもりだった」など3件は、その他にしていました。そのぶん、生活の変化は24件から29件に増え、メニュー・味（28件）を1件上回っています。表の件数で順位を書く前に、件数が増えた分類の中身を確かめます。分類が合っているかを、人が分類を付けた回答と比べて確かめる手順は、口コミの記事に書いたので、ここでは繰り返しません。

要約は、数えたあとに分類の中で使う

表ができても、要約の出番がなくなるわけではありません。使う場所が変わります。表の分類ごとに回答をまとめ、「具体的に何が不満なのかを、多いものから順に2〜3点、短く書いてください」と頼みました。8つの分類のうち3つを並べます。

量・届く頻度なら、表の45件の要約に「量が多すぎる」「届く頻度が高すぎる」「保管場所・収納に困る」の3点が挙がりました。全体の要約でも同じような中身は読めましたが、今度はそれが、数えた件数と同じ行に並びます。資料では、分類ごとの件数を左に、その分類の要約を右に置くと、「どれだけあるか」と「何が起きているか」を取り違えずに伝えられます。

もう一つの使い道が、分類の点検です。生活の変化の要約の3点目には「物価高や家計の圧迫による節約・費用の見直し」とあります。前の節で生活の変化に入った価格・送料の2件、「物価が上がって節約中です」「家計が厳しくなった」にあたる内容です。一方で、その他から生活の変化に入った3件の中身は、要約には出ていません。要約は多いものから2〜3点を挙げるので、見つかるのは外れの一部です。それでも、分類の要約にその分類らしくない項目が出てきたら、その分類に入った回答を読み直すきっかけになります。

表を作った関数と、200件でかかった費用

試したのは2026年10月、当社の検証用の BigQuery（東京のデータセット）です。使った AI 関数は2つです。全体の要約、件数つきの要約、分類の案、分類ごとの要約には、たくさんの行をまとめて、まとめた単位ごとに1つの答えを返す AI.AGG 関数（2026年10月13日に一般提供）を使いました。分類の案だけは、名前と説明の組で返すよう出力の形を指定しています。回答ごとに分類を付けた表は、決めた分類に入力を分ける AI.CLASSIFY 関数で、分類の名前と説明の組を渡して200件に1回実行しました。コードのデータセットの名前は置き換えています。

CREATE OR REPLACE TABLE mydataset.survey_classified AS
SELECT resp_id, answer,
  AI.CLASSIFY(answer,
    categories => [
      ('量・届く頻度', '1回に届く量が多い・少ない、届く間隔や回数が生活に合わない'),
      ('価格・送料', '値段、送料、割引、値上げ、値段に見合うか'),
      ('メニュー・味', 'メニューの種類や飽き、味付け、食材の質、家族の好み'),
      ('調理の手間', '作る時間や手間、下ごしらえ、洗い物、料理が苦手'),
      ('生活の変化', '引っ越し、転勤、家族構成、働き方、入院など、サービスの外の事情'),
      ('配送', '届く日時、置き配、箱や食材の届いた状態、受け取り'),
      ('手続き・サイト', 'スキップ・変更・休止・解約・支払いの手続き、サイトやアプリの使いにくさ、問い合わせの窓口'),
      ('その他', '理由が書かれていない、一時的に休むだけ、上のどれにも当たらない')],
    examples => [('メニューが単調なうえに、送料も高い', 'メニュー・味'), ('送料が高く、メニューも単調', '価格・送料')],
    endpoint => 'gemini-3.5-flash-lite') AS category
FROM mydataset.survey_answers;

SELECT category, COUNT(*) AS n,
  AI.AGG(answer,
    '次は、解約時アンケートの「解約の理由」の自由記述のうち、同じ分類に入った回答です。具体的に何が不満なのかを、多いものから順に2〜3点、短く書いてください。',
    endpoint => 'gemini-3.5-flash-lite') AS summary
FROM mydataset.survey_classified
GROUP BY category
ORDER BY n DESC;

実行したときは、比べるために決めておいた分類の列も表へ書き出しました。上の文では、その列と、表に付けた期限・ラベルの設定を省いています。

モデルは、どちらの関数でも gemini-3.5-flash-lite を指定しました。2026年10月時点で、AI.GENERATE 関数がモデルを指定しなかったときに使う既定のモデルです。AI.AGG と AI.CLASSIFY は、指定しなければ BigQuery がモデルを選ぶと公式ドキュメントにあり、どのモデルの単価で見積もればよいかが前もって決まらないので、指定しています。東京のデータセットから地域を付けないモデル名で呼ぶと、グローバル エンドポイントが使われ、処理される地域は指定も把握もできないとも書かれています。必要な権限や、送ったデータの扱いは、口コミの記事の後半（全件で実行するときの節と、作り方の節）にまとめました。

費用は、BigQuery の処理と、Gemini のトークンの2つです。BigQuery の処理は、AI の処理も集計も、どれも最低の10 MB でした（表を消す処理は0）。トークンは、200件をまとめて渡した全体の要約・件数つきの要約・分類の案が1回あたり入力4,983〜5,114・出力348〜657、分類ごとの要約が入力5,843・出力688でした。1件ずつ分類した AI.CLASSIFY は入力86,606（1件あたり433）・出力1,042で、入力は回答そのもの（200件で2,741字）よりずっと多くなりました。分類の名前・説明・例などが1件ごとに入力に入るためと考えられます（内訳はジョブの履歴には出ません）。1件ずつ呼ぶ関数なので、回答の件数が増えれば入力も増えます。

gemini-3.5-flash-lite の単価は、100万トークンあたり入力0.30米ドル、出力2.50米ドルで、自動でキャッシュされた入力は0.03米ドルです（2026年10月時点、グローバル エンドポイント、価格ページ）。今回は2回の実行で入力の一部（合わせて8,049）がキャッシュされていました。換算すると、AI の処理8回分のトークンは合わせて0.046米ドル、BigQuery の処理（東京のオンデマンドで1 TiB あたり7.50米ドル。ジョブの履歴を読んだ分を含む）を足して0.047米ドルでした（無料枠を引く前）。AI.CLASSIFY はジョブの履歴に処理の地域が出なかったので、公式ドキュメントの決まり（東京からはグローバル エンドポイント）に沿ってグローバルの単価で換算しています。トークン数は、ジョブの履歴（INFORMATION_SCHEMA.JOBS_BY_USER）から読みました。作った表は、確かめたあとに削除しています。

この記事の数字は、架空の回答200件に、全体の要約・件数つきの要約・分類の案を2回ずつ、表と分類ごとの要約を1回ずつ実行したものです。頼み方を変えた比較や、もっと多い件数では試していません。

次の報告で「約〇件」と書かれた AI の要約を見かけたら、その数字が表から数えたものか、要約が書いたものかを、一度たずねてみてください。分類を決める作業や表の作り方で手が止まったら、BigQuery の導入支援のページからご相談いただけます。