地域向けのアンケートが長文化し、気づけば100問を超えていた…という状況は珍しくありません。さらに「1世帯につき1回だけ回答してほしいのに、同居家族（複数人・多世代）の属性情報は人数分取りたい」となると、Microsoft Formsの設計は一気に難しくなります。本記事では、フォーム内に別フォームを“埋め込む”ことができるのか、できない場合に現実的に運用できる代替案を、突合（データ連携）まで含めて具体的に解説します。
Microsoft Formsで「長いアンケート＋世帯内複数人の属性情報」が難しい理由
まず押さえておきたいのは、Microsoft Formsは「アンケートを素早く作って配布する」ことに強い一方で、同じ設問セットを人数分くり返すような“繰り返し入力（リピート）”が苦手だという点です。
質問数の上限がある（しかも分岐で隠れていてもカウントされる）
Microsoft Formsは、1つのフォーム／クイズあたりの質問数に上限があります。世帯アンケートの本体だけで約120問ある場合、ここに「個人属性（年齢、性別、就業、続柄、健康状態など）」のブロックを人数分くり返すと、上限に到達しやすくなります。
また、Likert（マトリクス）形式を使うと一見“1問”に見えますが、実際には「ステートメント（行）」が質問数として数えられます。つまり、表の行を増やせば増やすほど質問数の消費が増えるため、質問数節約のつもりが逆効果になることがあります。
「フォームの途中から別フォームへ飛ばして、終わったら元のフォームへ戻す」仕組みがない
結論から言うと、Microsoft Formsには「フォームの中に別フォームを埋め込む」「分岐で別フォームへ遷移させる」といった、いわゆる“サブフォーム”機能は用意されていません。フォームはフォームごとに独立して動作するため、1本の回答セッションの途中に別フォームを差し込むような設計はできません。
混同されやすいのが「Webページにフォームを埋め込む（iframe等）」という別の意味での埋め込みです。これは“サイト側”にFormsを置く話であり、「Formsの中にFormsを入れる」こととは別物です。アンケート設計の文脈では、後者はできないと理解しておくのが安全です。
できること／できないことを整理する
| やりたいこと | Microsoft Forms単体 | コメント |
|---|---|---|
| 1フォーム内で同じ属性ブロックを人数分「自動で繰り返す」 | 不可 | 繰り返し回数を動的に増減する機能はありません（最大人数分を固定で用意する設計は可能） |
| 途中で別フォームへ遷移（分岐）し、完了後に元へ戻す | 不可 | 自動リダイレクトやサブフォーム遷移は標準機能として用意されていません |
| 本文中に別フォームのURLを案内として載せる | 可 | 説明テキストにURLを記載し、回答者がクリック（またはコピー）して移動する運用は可能 |
| 送信完了後に任意URLへ自動でリダイレクト | 不可 | 自動リダイレクトの要望は多いが、少なくとも現状は標準で提供されていないという案内が多い |
| 送信完了メッセージ（お礼のメッセージ）の編集 | 可 | 文面は編集できます（ただしリンクのクリック可否は環境依存・制約あり） |
現実的な解決策：2つのフォームを“リンク”して行き来させる設計
「埋め込み」ができない以上、最も現実的なのはメイン（世帯）アンケートと個人属性フォームを分け、回答者に“行き来”してもらう運用です。設計のコツは、単にリンクを貼るだけではなく、後工程の集計まで含めて「迷わない導線」と「突合できるキー」を用意することです。
全体像：世帯レベルと個人レベルのデータを分離する
| フォーム | 取得する情報の例 | 回答回数 | ポイント |
|---|---|---|---|
| メインアンケート（世帯） | 地域施策の満足度、困りごと、居住年数、世帯全体の状況、同居人数 など | 1世帯につき1回 | まず「同居人数」を先に聞いて、追加フォームの回数を明確にする |
| 属性情報フォーム（個人） | 続柄、年代、性別、就業、健康状態、支援ニーズ など | 追加世帯員1人につき1回 | 短く・必須を絞り、離脱を防ぐ |
ステップ1：まず「共通キー（識別子）」を決める
2フォーム運用の肝は、後から確実に突合できるように両フォームに同じ識別子を入れることです。よくある失敗は「住所」や「氏名」に頼ってしまい、表記ゆれ・誤記で結合できなくなるケースです。できるだけ“入力が楽で、間違いにくい”キーを設計しましょう。
| 共通キー案 | おすすめ度 | メリット | 注意点 |
|---|---|---|---|
| 世帯コード（事前に配布した8桁など） | 高 | 表記ゆれが少なく、個人情報の取り扱いも軽くできる | 配布・管理が必要。紛失時の再発行ルールを決める |
| 回答者が自分で決める合言葉（例：好きな4文字＋誕生月） | 中 | 配布不要で始められる | 重複リスクがある。ルールを細かくしても誤入力が起きやすい |
| 住所（町名まで）＋世帯主の生年など | 低〜中 | 追加の配布が不要 | 個人情報性が上がり、表記ゆれ・入力ミスで結合不能になりがち |
| Microsoft 365のログインID（組織内限定） | 条件付き | 「1人1回」を制御しやすい | 世帯単位ではなく“個人単位”になりがち。外部配布には使えない |
さらに「同じ世帯内で何人目か」を表す世帯員番号（例：1〜6）も、属性フォームに入れておくと集計が格段に楽になります。例として、属性フォームの最初に「世帯コード」「世帯員番号（1=回答者本人、2以降=同居家族）」を必須で置くと、後工程の整形が一気に安定します。
ステップ2：メインアンケートに「追加属性フォーム」への導線を設計する
メインアンケートの設問の途中（世帯構成を聞いた直後など）に、次のような案内文を置きます。ポイントは、リンクを貼るだけでなく、具体的な手順と回数を明記することです。
- 同居人数（回答者本人を含む）を先に聞く
- 「追加世帯員がいる場合は、属性フォームを人数−1回送信する」ルールを明文化する
- 入力後にこのフォームへ戻って続けることを明記する（迷子防止）
案内文の例（メインフォーム内）
同居のご家族（回答者本人以外）がいる場合は、「追加世帯員の属性情報フォーム」をご家族1人につき1回入力してください。入力が終わったら、このアンケートに戻って続けてください。
※世帯コードは、この後のフォームでも同じものを入力します。
Formsの仕様として、送信完了後に自動で別URLへ飛ばすことはできないケースが多いので、「別タブで開く」「入力後は元のタブに戻る」といった行動を、文面で補うのが現実的です。
ステップ3：属性フォーム側に「メインへ戻る」導線を用意する
属性フォームは、追加世帯員1人分のデモグラ情報に絞って短く作ります。送信後に表示される「お礼のメッセージ」をカスタマイズし、メインアンケートに戻る手順を明記しましょう。設定画面から「お礼のメッセージをカスタマイズする」をオンにできます。
ただし、送信後メッセージにURLを入れても“クリックできるリンク”として機能しない、という報告もあります。その場合でも、短いURL（短縮サービスや短いパスのページ）にしてコピーしやすくする、あるいは「戻るボタンで戻ってください」と案内するなど、運用でカバーします。
案内文の例（属性フォームの送信後メッセージ）
ご入力ありがとうございました。追加のご家族がいる場合は、このフォームを続けて送信してください。入力が完了したら、ブラウザーのタブ（または戻るボタン）でメインアンケートに戻り、残りの設問に回答してください。
「共通キー」の入力ミスを減らす：事前入力（プレフィル）リンクの活用
2フォーム運用で最も多い事故が、「世帯コードの入力ミス」です。これを減らす方法として、Microsoft Formsの事前入力（pre-filled link）機能が役立ちます。フォームのリンクに“初期値”を持たせ、回答者が開いた時点で世帯コード欄が埋まった状態にできます。
運用例としては、次のような形が現実的です。
- 紙の案内や郵送物に「世帯コード」と「メインアンケートのリンク」を印字する
- 属性フォームへ誘導する際は、世帯コードが入った状態のリンク（事前入力リンク）を使う
- これにより、追加フォーム側での世帯コードの誤入力を大きく減らす
事前入力リンクは、フォーム編集画面のメニューから取得でき、特定の質問に対して既定値を入れたリンクを生成する流れになります（表示名称は環境により多少異なります）。
集計・突合の現実解：Formsの回答を後で結合する
2フォーム運用は「入力時」に少し工夫が必要ですが、設計さえ固めれば、集計時の見通しは悪くありません。ここでは、実務で使われやすい突合パターンを3つ紹介します。
パターンA：Excelにエクスポートして結合（小〜中規模向け）
どちらのフォームも、回答をExcelへエクスポートできます。メインと属性のExcelを用意し、共通キー（世帯コード）で結合します。Power Query（クエリ）を使うと、更新ボタンで再結合できるため、集計作業の手戻りが減ります。
- メイン：世帯コードごとに1行
- 属性：世帯コード＋世帯員番号ごとに複数行
- 最終的に「世帯テーブル」と「個人テーブル」を分けて分析する（正規化）と扱いやすい
パターンB：SharePointリストに書き出して“世帯”と“個人”を管理（組織内運用向け）
Microsoft 365を使っている組織なら、SharePointリスト（またはMicrosoft Lists）に書き出して管理すると、共同編集・権限管理・監査の面で運用が安定します。「世帯マスタ（世帯コードを主キー）」と「世帯員（世帯コードを外部キー）」を別リストにしておくと、後からPower BI等に接続する際もスムーズです。
パターンC：Power Automateで自動集約（手作業を減らしたい場合）
Power Automateを使うと、フォームの新規回答をトリガーにして、Excel／SharePoint／Dataverseなどに自動で追記できます。たとえば次のようなフローが実務的です。
| 目的 | トリガー | 格納先 | 得られる効果 |
|---|---|---|---|
| 回答の自動蓄積 | フォームに新しい回答が送信されたとき | Excelテーブル | 担当者がダウンロードしなくてもデータが揃う |
| 世帯コードの入力ミス検知 | 属性フォームの送信 | SharePointリスト＋通知 | 存在しない世帯コードならTeamsやメールでアラート |
| 送信後の案内（リンク配布） | メインフォームの送信 | メール送信 | 「次にやること」をメールで案内し、迷子を減らす |
なお、Formsの送信完了画面でリンクがクリックできない場合でも、Power Automateで「回答者へメールを送る」形にすれば、本文にリンクを入れて導線を強化できます。
離脱率を下げるための設計・運用のコツ
120問規模のアンケートは、それだけで回答者に負担がかかります。さらに属性フォームが追加されると、離脱しやすいポイントが増えます。ここでは、現場で効きやすい改善策をまとめます。
同居人数は早めに聞く（そして回数を明示する）
「あと何回入力が必要か」が見えないと、人は途中でやめます。メインフォームの序盤で同居人数を聞き、案内文で「属性フォームは（人数−1）回」と具体的に書きましょう。
属性フォームは“短く・必須を絞る”
属性フォームは、集計の軸になる項目に絞るのが基本です。たとえば、年代は5歳刻みではなく10歳刻み、就業は大分類、健康状態は選択肢中心…というように、分析に必要な粒度まで落とします。自由記述は、後で分類コストがかかるため、どうしても必要な1問に限定するのが無難です。
途中保存・再開を前提にする
長いアンケートでは「途中離脱＝未回収」になりがちです。回答者側の環境によっては、途中保存が期待通りに働かないこともあるため、案内文に「時間がかかる場合は、途中で一度メモしてから再開してください」など、現実的な注意喚起を入れると回収率が上がります。
完了ページの導線は“テキスト＋行動指示”で補う
送信完了後に自動遷移できない以上、完了ページは「次に何をするか」を文章で伝える場になります。お礼のメッセージは最大4,000文字まで入れられるので、手順を丁寧に書く余地があります。
よくある質問と、現場での着地点
Q：属性フォームを何回も送らせると、同じ人が間違えて2回送信しませんか？
A：起こり得ます。対策としては、属性フォームに「世帯員番号（1〜）」を必須で入れ、送信前に確認させるのが効果的です。可能なら「このフォームは世帯員2人目の入力です」のように、入力する人の対象を明確にする文言を冒頭に置きます。
Q：「1世帯1回」をFormsで厳密に守れますか？
A：Formsの「1人1回」はアカウント単位での制御であり、世帯単位の制御とはズレます。また、規模が大きい場合の注意点も公開されています。厳密な重複排除が必要なら、世帯コードの配布や、Power Automate／集計時の重複検知を組み合わせるのが現実的です。
Q：個人アカウントで配布したら、回答数に制限はありますか？
A：Microsoft personal account（Outlook.com等）の場合、回答数に上限があるため、地域向けの大規模アンケートでは想定外の停止が起きることがあります。配布規模に応じて、Microsoft 365（組織アカウント）で実施するか、別の回収手段も検討しましょう。
どうしても1リンクにしたい場合の代替案
「2フォームに分けると説明が難しい」「紙で配るのでリンクが増えると困る」といった事情もあります。その場合は、次の代替案も検討対象になります。
| 代替案 | 概要 | 向くケース | 注意点 |
|---|---|---|---|
| 最大人数分の属性セクションをフォーム内に固定で用意 | 例：最大6人まで想定して属性ブロックを6回分作る | 世帯人数が上限内で読める／上限200問に収まる | 質問数を消費する。該当しない人のブロックが邪魔になりやすい |
| 属性情報を1問の自由記述でまとめて書いてもらう | 例：「家族全員の年代・性別・続柄を改行で記入」 | どうしても質問数を増やせない | データ整形コストが高い。入力品質がばらつく |
| Power Apps＋SharePoint（フォームではなくアプリ） | 世帯員の追加・削除を画面で繰り返せる | 入力体験とデータ構造を重視したい | 開発・保守が必要。短期で作るには体制が要る |
まとめ：Microsoft Formsは“分割＋突合”で考えると上手くいく
Microsoft Formsで「長いアンケートの途中に別フォームを埋め込みたい」という要望は非常に自然ですが、Formsはフォーム単位で独立しているため、サブフォームのような埋め込みはできません。質問数の上限（200問）を前提に、世帯（1回）と個人属性（人数分）を分け、共通キーで突合する設計にすると、現実的に運用できます。
導線（リンク案内）とキー設計（世帯コード）さえ丁寧に作れば、回答者の迷子を減らしつつ、必要なデモグラ情報を漏れなく回収できます。さらにPower AutomateやSharePointを組み合わせれば、回収〜集計の自動化も視野に入ります。アンケートは「作って終わり」ではなく「集計して意思決定につなげる」までが本番です。最初にデータ構造を整える設計が、後の分析コストを確実に下げてくれます。
コメント