今までの記事一覧
- GASでGoogleForm回答を取得するなら lastRow？(e)？試してみた
- onFormSubmit(e)を手動実行でデバッグする方法
- どっちを使う？onFormSubmit(e)の values と namedValues の違いと使い分け ＜この記事
- onFormSubmit(e) の e.values 配列順のしくみ
- Googleフォームで質問を変えても壊れない！cleanFormData(e)でnamedValues防御力をアップ
- Googleフォームの質問変更に負けない！｢部分一致｣と｢秘密の暗号｣でcleanFormData(e)の防御力を鉄壁に
- 手動コピペはもう卒業！Googleフォームの回答別に処理を自動仕分け
- Googleフォームで同時に大量送信されても踏ん張る！LockServiceで順番制御！try - catch - finally でバトンを繋げ！
- LockServiceでは順番は守れない？受付番号で順序を保証する方法
前提
この記事は、フォーム回答を保存している スプレッドシート側の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の挙動についてもう少し深堀りしてみましょう。