今までの記事一覧

前提

この記事は、フォーム回答を保存しているスプレッドシート側のGAS を前提にしています。
トリガーは以下を設定しています。

スプレッドシートから
フォーム送信時

前回、前々回では、

GoogleFormsの回答取得はlastRowより(e)のほうが安全
(e)を使いつつ手動実行でデバックする方法

をやりました。

今回は実際にフォームからの送信データを取り出す方法を考えてみたいと思います。

順番に取り出す：values

例えばeをJSON.stringify(e)したこんなデータ。

{
  "authMode": "FULL",
  "namedValues": {
    "お名前をどうぞ": ["ほげ田ほげ美"],
    "タイムスタンプ": ["2026/03/** **:**:32"],
    "これはテストですか": ["はい"]
  },
  "range": {
    "columnEnd": 3,
    "columnStart": 1,
    "rowEnd": 3,
    "rowStart": 3
  },
  "source": {},
  "triggerUid": "17*****",
  "values": [
    "2026/03/** **:**:32",
    "はい",
    "ほげ田ほげ美"
  ]
}

こうするとそれぞれのデータが取得できます。

Logger.log(e.values);  //["2026/03/** **:**:32","はい","ほげ田ほげ美"]
Logger.log(e.values[0]);  //"2026/03/** **:**:32"
Logger.log(e.values[1]);  //"はい"
Logger.log(e.values[2]);  //"ほげ田ほげ美"

つまり、e.valuesは回答データの中の"values"を1次元配列で返すので
配列の番号を入れると個別のデータが取得できるのです。

さて、今は回答が3つだけなのでいいですが、
これが何十個もあったらどうしましょう。

数えますか？
34,35,36・・・「電話ピロピロリン♪」　うわぁぁぁぁ！

そんなときに便利なのがnamedValuesです。

質問名で取り出す：namedValues

先ほどのイベントオブジェクトからnamedValuesを取り出すとこうなります。

 "namedValues": {
    "お名前をどうぞ": ["ほげ田ほげ美"],
    "タイムスタンプ": ["2026/03/** **:**:32"],
    "これはテストですか": ["はい"]
  }

質問 → 回答　という形でデータが入ってますね。
これを利用しましょう。

Logger.log(e.namedValues);  //  {お名前をどうぞ=[ほげ田ほげ美],タイムスタンプ=[2026/03/** **:**:32],これはテストですか=[はい]}
Logger.log(e.namedValues["お名前をどうぞ"]);  //["ほげ田ほげ美"]
Logger.log(e.namedValues["これはテストですか"]);  //["はい"]

こんなふうに質問名を指定するとそれに対する回答が取得できます。
ちなみに中身は見た目の順番が決まっていません。
なのでe.namedValues[1]のように番号で取り出すことはできません。

ただし、namedValuesの値は配列で返ってきます。
なので配列番号を入れると実際の回答だけを取得できます。

Logger.log(e.namedValues[1]);  //エラー（namedValuesは番号では取り出せない）

Logger.log(e.namedValues["お名前をどうぞ"]);  //["ほげ田ほげ美"]
Logger.log(e.namedValues["お名前をどうぞ"][0]);  //ほげ田ほげ美

というわけで、
namedValuesを使うと、質問名で回答を取得できるので
配列の番号を数える必要がありません。ちょー便利！

さて、こんなステキなnamedValuesですが
致命的な弱点があります。

namedValuesの弱点①：質問内容を変更すると壊れる

今のフォームの質問は

お名前をどうぞ
これはテストですか

でした。（タイムスタンプはシステムが勝手に入れてる）

では、フォームのほうで質問内容をこのように変えたらどうでしょう。
「お名前を入力してください」

これでイベントオブジェクトのnamedValuesはこうなりました。

 "namedValues": {
    "お名前を入力してください": ["ほげ田ほげ美"],
    "タイムスタンプ": ["2026/03/** **:**:32"],
    "これはテストですか": ["はい"]
  }

GAS側が前のままだと

e.namedValues["お名前をどうぞ"][0]

"お名前をどうぞ" なんて質問ないやん。エラー吐いたれ。ぺっ
undefined

namedValuesの弱点②：同じ質問があると配列化

例えばこんなフォーム

お名前をどうぞ
これはテストですか
これはテストですか

{"タイムスタンプ":["2026/03/** **:**:45"],
  "お名前をどうぞ":["ほげ田ほげ美"],
  "これはテストですか":["はい","いいえ"]}

同じ質問の場合はこのように配列にまとめられます。
配列の中身の順番はスプレッドシートの列の順番です。
ただし、
フォームの表示順とスプレッドシートの列順は一致するとは限りません
(フォームに質問を途中追加した場合とかね)

フォームに同じ質問があると
どの回答がどの質問なのか コードから判断できなくなる 可能性があります。

スプレッドシートにもこんなふうにアラートが出るし

質問タイトルは絶対カブらないようにする
これ、むっちゃ大事。

valuesのメリット：順番が変わらない

ここでもういちどvaluesに戻りましょう。
valuesの中身は順番で管理しています。
これは不変です。
フォームで新しい質問を入れても
新しい質問はvaluesの配列の一番後ろに追加されます。

つまり、既存の配列番号は変わりません。

このため、質問の追加や順番変更があっても
既存コードが壊れにくいのです。

まとめ

valuesとnamedValuesそれぞれ
メリットとデメリットがあることがわかりました。

	メリット	デメリット
values	安定	順番を数えるのが大変
namedValues	可読性	質問文変更で壊れる / 質問がカブると配列になる

これを踏まえて使い分けができるといいですね。

ちなみに実務では

安定性を重視する処理 → values
コードの読みやすさを重視する処理 → namedValues

のように使い分けることが多いようです。

以上です。
同じようなことにハマっている方のお力になれれば幸いです。

次回はe.valuesの挙動についてもう少し深堀りしてみましょう。