宮城県涌谷町が、イベント申込用のGoogleフォームで設定を誤り、申込者26人分の氏名・電話番号・年齢・メールアドレスが、ほかの申込者から閲覧できる状態になっていたことを公表しました（2026年6月15日公表）。原因は「結果の概要を回答者と共有する」設定が有効になっていたこと。特別な攻撃ではなく、チェックボックス1つの見落としで起きた、ありふれた事故です。
そして、これは涌谷町に限った話ではありません。同じ設定ミスによる漏えいは自治体・企業・イベント事務局で繰り返し起きています。「うちは大丈夫か」を、今すぐ自部門と現場部門のフォームで確認すべき事案です。
この記事でわかること
- 涌谷町で実際に何が起きたのか（事実の整理）
- 原因となったGoogleフォームの設定はどれか
- なぜ同じ事故が各所で繰り返されるのか、情シス目線の本当の課題
- 情シスとして現場部門にどう手を打つか
何が起きたのか
町が公表した内容を整理します。
| 項目 | 内容 |
|---|---|
| 公表者 | 宮城県涌谷町 |
| 公表日 | 2026年6月15日 |
| 事象発生 | 2026年5月18日 19時頃〜（同日21時半に修正） |
| 対象フォーム | 純米大吟醸「花時雨」お披露目イベントの申込フォーム（Googleフォーム） |
| 原因 | 「結果の概要を回答者と共有する」設定が有効だった |
| 閲覧可能だった情報 | 氏名・電話番号・年齢・メールアドレス |
| 申込件数 | 26件 |
| 実際に閲覧したと推定される人数 | 4〜5人 |
| 発見の経緯 | 申込者からの指摘で判明 |
申込者からの指摘で同日中に気づき、約2時間半で設定を修正できた点は、不幸中の幸いといえます。外部からの指摘がなければ気づけなかった、という事実は重く受け止める必要があります。
原因となった設定はどれか？
「結果の概要を表示する（回答者と共有する）」をオンにすると、回答者は送信後に他の回答の集計や内容を閲覧できるようになります。これが今回の直接原因です。
Googleフォームでは、回答送信後の画面に「前の回答を表示」「概要を表示」といったリンクが現れ、これをたどると他の回答者が入力した内容が見えてしまいます。アンケートの集計結果を参加者に見せたいケース向けの機能ですが、氏名や連絡先など個人情報を集めるフォームでこれを有効にすると、そのまま漏えいに直結します。
この設定はデフォルトではオフです。つまり「うっかりオンにした」「テンプレートを流用したらオンのままだった」といった経緯で事故が起きます。フォーム作成後に、設定 →「回答」内の該当項目がオフであることを必ず確認してください。
これは涌谷町だけの問題ではない
同種の事故は繰り返し報じられています。報道ベースの情報も含みますが、傾向として押さえておくべきです。
- 地方自治体の交流イベント申込フォームでの同様の設定ミス
- 金融機関の記念講演会の申込フォームで、氏名・電話番号・住所が閲覧可能だった事例
- 大規模イベント事務局のアンケートで、数百人分の氏名・メールアドレスが第三者から見える状態だった事例
共通するのは、「攻撃された」のではなく「設定を間違えた」点です。脆弱性のパッチ適用とは異なり、ツール側に欠陥があるわけではないため、CVE番号も注意喚起も出ません。だからこそ気づきにくく、横展開もされにくい。情シスにとっては、見えないところで静かに増えていくタイプのリスクです。
情シス目線の本当の課題
正直なところ、現場の課題は「Googleフォームの設定を覚えてもらう」ことではありません。本質は、情シスの目が届かないところで、現場部門が業務ツールを自由に作って公開できてしまうという構造にあります。いわゆるシャドーIT、あるいは「シャドーSaaS」の問題です。
イベント告知のスピード感の中で、担当者が手元のGoogleアカウントでフォームをさっと作り、URLを配って募集を始める——この身軽さこそがクラウドツールの価値であり、同時に事故の温床でもあります。情シスが全フォームを事前レビューする運用は、人員的に現実的ではありません。「禁止」と通達したところで、現場は別の手段で似たことをやるだけ、という実感を持っている担当者も多いはずです。
だからこそ、点（個別の設定指導）ではなく、面（つくる前の前提づくり）で効かせる発想が要ります。チェックリストを配って終わりにせず、「個人情報を集めるフォームは作成時にこの3点を確認」「公開前に第三者の目で1回だけ確認する」といった、軽くて続く運用に落とし込めるかが勝負どころです。
情シスはどうすべきか
個別の対策手順を長々と並べるより、まずは公的機関の指針を土台にするのが近道です。
- 中小企業・組織の基礎固め：IPA「中小企業の情報セキュリティ対策ガイドライン」。クラウドサービス利用時の留意点を含め、組織としての基本方針づくりに使えます。
- 現場担当者への啓発：IPA「対策のしおり」。フォームを作る非IT部門の担当者向けに、噛み砕いた啓発資料として活用できます。
- 「もし漏れたら」の備え：IPA「インシデント対応 机上演習教材」。今回のように外部指摘で発覚する事態を想定し、初動と公表の流れを一度なぞっておくと動きが変わります。
そのうえで現場に伝えるべき最小限のポイントは、「個人情報を集めるフォームでは、回答の集計を回答者に共有する設定をオフにする」「共有範囲を必要な人だけに絞る」「公開前にもう一人がテスト送信して見え方を確認する」の3つに尽きます。地道なユーザー教育の積み重ねが、結局いちばん効きます。
まとめ
- 涌谷町の事故は、Googleフォームの「結果の概要を回答者と共有する」設定が有効だったことが原因。攻撃ではなく設定ミスで、26人分の個人情報が他の申込者に閲覧可能だった。
- 同じ設定ミスは自治体・企業・イベント事務局で繰り返し起きている。CVEも注意喚起も出ない、気づきにくいリスク。
- 本質はシャドーIT/シャドーSaaSの構造問題。禁止や個別指導ではなく、「作る前の最小限の確認」を軽く続けられる運用へ。公的指針を土台に現場啓発を。
コメント