Google フォームのチェックボックス回答にカンマがある場合：選択内容を正確に取り戻す

表を変更する前に、元の回答を一件確認する

編集権限のあるアカウントで元のフォームを開き、Responses → Individual を選びます。選択されたラベルにカンマを含む回答を一件選び、選択肢を省略せずに書き留めてください。該当する場合は、Email と Email newsletter のように文字列が重なるラベルを含む回答も選びます。これが、これから作る表を元データと照合するための基準になります。現在のエクスポートはそのまま保ち、コピーで試してください。

実際の質問形式も確認します。このガイドで扱うのは、一つの質問に対して複数の選択肢を選ぶ通常のチェックボックスです。チェックボックスのグリッドには行構造があり、配列の形も異なります。また、必要なのが選択肢ごとの件数なのか、特定の選択肢を含む回答の一覧なのか、視覚的な概要なのかを決めてください。フォームに既にある集計画面で目的を満たせるなら、エクスポートは余分な作業になることがあります。

独自のエクスポートを作る前に、フォーム本体の CSV を試す

フォーム本体で Responses → More → Download responses (.csv) を使います。これは、連携先の Google スプレッドシートを CSV としてダウンロードする方法とは別です。2026年2月に更新された Displayr の連携ドキュメントでは、フォーム本体からダウンロードしたファイルの複数回答値をセミコロン区切りと説明しています。既存の Stack Overflow の回答も同じ違いを報告しています。そのため、ラベル内にカンマがあるだけで、その CSV が使えなくなるわけではありません。

まず CSV に対応した読み取り機能で外側の CSV を読み込み、先ほど確認した回答のチェックボックス欄を調べます。CSV フィールド全体を囲む引用符は、そのフィールドを一まとまりとして保ちますが、内部の複数の選択肢がどう符号化されているかまで決めるものではありません。実際のファイルで内部の区切り文字とエスケープ方法を確認してください。分割ルールを採用する前に、その区切り文字を含むラベルと、自由入力の Other 回答を試します。得られた選択内容が元の回答と正確に一致するなら、この簡単な方法を使ってください。連携先のシートが扱いにくく見えたという理由だけで、問題なく使えるエクスポートをスクリプトに置き換える必要はありません。Other の自由入力にその区切り文字を含めることができ、信頼できるエスケープ規則を確認できない場合は、元の配列を使います。

分割と文字列検索で結果が食い違う理由を理解する

選択可能なラベルが ["A", "A, B", "B, C", "C"] の四つだとします。["A, B", "C"] という選択と ["A", "B, C"] という選択は、どちらもカンマとスペースで連結すると A, B, C になります。選択肢の全リストが分かっていても、この二つの結果のどちらかを決めることはできません。これは表現形式を説明するために作った例であり、Google のすべてのエクスポート形式についての主張ではありません。

文字列検索では別の誤りが起きます。選択された値が ["Email newsletter", "Food, drinks"] の場合、連結後の文字列から Email を検索すると、選ばれていない選択肢まで数えてしまいます。その文字列をカンマとスペースで分割してから値全体を照合すると、今度は Food, drinks が失われます。私たちはこの二つの反例をローカルで実行しました。実務上の要点は、数える前に選択内容の境界を確定することです。部分文字列の照合と分割を切り替えても、境界を確定したことにはなりません。

元のフォームから、選択された値の配列を取得する

Google の Apps Script リファレンスでは、通常の CheckboxItem の回答は、選択された値を含む String[] と定義されています。Stack Overflow にある既存の完全な例は、getResponses() を読み取り、各回答の getItemResponses() を走査し、CHECKBOX 項目を選んで getResponse() を呼び出します。Apps Script を使う場合は、フォームの More → Apps Script メニューから開始すると、そのフォームに紐づくスクリプトになります。編集権限が必要です。元のサンプルは下の出典から参照でき、API メソッドは Google が説明しています。

そのチェックボックス処理のループ内で、itemResponse.getResponse() が返した配列をそのまま保持してください。values を配列として扱う前に Array.isArray(values) を確認し、別々の文字列を保ったテキスト表現が必要なら JSON.stringify(values) を使います。配列を文章のように連結してから後で分割し直すと、この目的を損ないます。値とともに回答 ID と項目の ID を保持してください。質問タイトルはラベルであり、項目の位置はそれとは別のプロパティです。また、Google はチェックボックス配列内の順序が変わることがあるとしています。クリックした順番だと解釈しないでください。

ページ単位の構造化データが必要なら、公式の回答 API を使う

Forms REST API も、内部の区切り文字を独自に決めずに済む、文書化された方法です。公式の forms.responses.list リファレンスで Try it を開き、フォームの回答を読む権限のあるアカウントを使って、編集用 URL に含まれるフォーム ID を入力します。OAuth トークンやリクエストヘッダーをコピーするのではなく、返された JSON を回答データとして保存してください。forms.get メソッドではフォーム定義を別途取得でき、チェックボックス質問の questionId を確認できます。

その質問で選択された各値は、textAnswers.answers の別々の要素として格納されます。保存したページとともに、responseId、questionId の対応関係、フォーム ID を保持してください。list メソッドは、返される回答オブジェクトの一つ一つに formId を繰り返し含めるわけではありません。REST の質問 ID は、この API のデータモデルに属するものです。別のエクスポートにある Apps Script の項目 ID で代用しないでください。

最初のリクエストが成功しても、エクスポートが完了したとは限りません。nextPageToken があれば、そのトークンを使い、同じフォームと同じフィルターで次のページを要求します。トークンがなくなるまで続けてください。指定する pageSize は上限であり、サービスがそれより少ない件数を返すこともあります。すべてのページを保持し、回答 ID の重複を除いた件数を確認してから、収集が完了したと判断します。このガイドでは、実アカウントでのエクスポートや、トランザクションとして同一時点に固定されたスナップショットを取得したとは主張していません。

完全一致で数え、未回答は別に扱う

通常のチェックボックス回答を既に配列で取得している場合、values.includes("Food, drinks") は、そのラベル全体が選択されたかを調べます。別のラベルの一部には一致しません。REST の表現では、対象の回答の textAnswers.answers から .map(x => x.value) で文字列を取り出した後、同じ完全一致の所属確認を行います。そのラベルについては、一件の送信につき最大一回だけ数えてください。複数選択の回答を、複数の別人として扱わないようにします。

回答がない場合は別の扱いが必要です。Apps Script の getItemResponses() は、この形式で未回答の項目を返す配列から除外します。そのため、配列内の位置で回答を対応づけると、後ろの回答を別の質問へ紐づけてしまうおそれがあります。代わりに項目 ID または質問 ID で照合してください。チェックボックスの未回答を明示的な選択と区別し、割合を求める場合は分母を意識して決めます。回答がないだけでは、その質問が飛ばされたのか、分岐で表示されなかったのか、後から追加されたのかは分かりません。これらのエクスポートで、削除済みの過去の質問定義を復元することもできません。

行数だけでなく、実際の選択内容と照合する

元の回答にある省略のないラベルを、取得した配列、またはフォーム本体の CSV から解析したフィールドと照合します。句読点を含むラベル、長いラベルに含まれる短いラベル、フォームで許可されている場合は自由入力の値、そして任意質問の未回答を含めてください。さらに、選択されたラベルと選択されていないラベルを一つずつ、完全一致の集計で確認します。全体の行数が正しくても、各行の内部で選択内容が間違っていることはあります。

私たちがローカルの Node 24.22.1 で実行した十件のアサーションは、区切り文字の衝突、二種類の集計ミス、UTF-8 JSON の往復変換、別々の項目 ID、欠落した項目、安全なテキスト処理を対象にしました。ローカルのテスト用データで、文書化された Forms オブジェクトの形を使っています。Google フォーム、Apps Script の認証、実際の CSV エクスポート、ログイン済みアカウントでの API Explorer は実行していません。受付中のフォームでは、合計件数を比較する前に、エクスポート時刻または対象の回答範囲を記録し、新しい送信の増加を考慮してください。

曖昧なセルしか残っていない場合は、不確実性を残す

元のフォーム回答を利用できない場合でも、既知の選択肢リストから解釈を一つに絞れることはあります。ただし、必ず絞れるわけではありません。A, B, C の例では、二つの選択内容がどちらも有効です。Other の自由入力があると、特定の区切り文字が値には現れないという前提は特に崩れやすくなります。解決できないセルには確認対象の印を残し、所有者に元の回答、または境界を確認できる別のエクスポートを求めてください。

情報が一つの文字列に平坦化された後でカンマをセミコロンに変更しても、失われた情報は戻りません。セル全体を引用符で囲んでも同じです。変換を承認した場合は、元ファイルと、その変換で使った前提を保管してください。作業の割り当てや件数の報告に結果を使う前に、正確な選択値を元の回答までたどれる状態にするか、未解決の記録を明示することが完了条件です。