Notionフォームの作り方｜問い合わせ・申請・アンケートをDBに集める

Notionフォームを使うと、Notion内に回答を集められます。

問い合わせ、社内申請、アンケート、研修後の確認、イベント申込など、軽い受付業務には便利です。

Notion公式ヘルプでは、フォームを使うとNotionワークスペースに参加していない人やNotionを使っていない人も含めて情報を収集でき、フォームはデータベースに接続され、各質問がデータベースプロパティに接続されると説明されています。

Notion公式ヘルプ：フォーム

ただし、会社で使う場合の問題は、フォームを作れるかどうかではありません。

問題になるのは、フォーム送信後です。

• 回答は集まるが、誰が処理するか決まっていない
• 問い合わせ、申請、アンケートが同じDBに混ざっている
• 必須項目が足りず、回答後に聞き直しが発生する
• 個人情報を含む回答DBを広く見せている
• Slack通知だけ来て、Notion側のステータスが更新されない
• フォームを止める方法や受付終了日が決まっていない
• 回答数が増え、Notion DBだけでは処理や集計が重くなる

Notionフォームは、入力画面ではなく、回答DBに業務を流し込む受付システム として設計する方が安定します。

この記事では、Notionフォームの作り方を、フォーム作成手順だけでなく、回答DB、問い合わせフォーム、社内申請フォーム、通知と自動化、権限と個人情報、外部フォームを使う判断まで整理します。

先に結論：回答DBを先に設計する

Notionフォームは、先に回答DBを設計してから作ります。

フォームの質問は、DBのプロパティになります。

つまり、質問設計を雑にすると、回答DBも使いにくくなります。

最初に決めるべき項目は、次の通りです。

項目	例
フォームの目的	問い合わせ、社内申請、アンケート
回答者	社内メンバー、外部顧客、匿名回答者
受付後の担当	営業、管理部、情シス、採用担当
ステータス	未確認、対応中、確認待ち、完了、却下
期限	初回返信期限、承認期限、回答締切
通知先	担当者、チャンネル、管理者
保管期限	いつ削除するか、いつ別システムへ移すか

Notionに向いているフォームは、受付後にチーム内で確認し、ステータスを進めるものです。

Notionフォームに向く	別フォームや専用システムが向く
社内申請、軽い問い合わせ、簡易アンケート	決済、本人確認、厳密な個人情報収集
採用前の軽い質問、イベント申込	大量回答、複雑な分岐、監査ログが必要な申請
マニュアル改善要望、FAQ投稿	法務・人事・医療など高い管理が必要な入力

Notionは柔軟ですが、すべてのフォーム業務の最終システムではありません。

回答DBとして処理しやすい範囲をNotionに置き、厳密な受付や大量処理は外部フォームや専用システムを使う判断が必要です。

Notionフォームでできること

Notionフォームでは、ページ上で新しいフォームを作るか、既存のデータベースにフォームビューを追加できます。

公式ヘルプでは、新規フォームは /form から作れること、既存DBからフォームを作るには接続先DBへのフルアクセスが必要なことが説明されています。

また、フォームの回答はデフォルトで回答用のテーブルビューに保存され、質問はデータベースプロパティとして表示されます。

できること	業務での使い方
フォームを作成する	問い合わせや申請の入力口を作る
既存DBにフォームを追加する	既存の問い合わせDBや申請DBに回答を集める
質問をDBプロパティに接続する	回答後にフィルター、並べ替え、担当割り当てを行う
必須項目を設定する	回答漏れを減らす
質問の説明を追加する	回答者の迷いを減らす
フォームを共有する	社内、外部、受付停止を切り替える
回答DBをビュー化する	未確認、対応中、期限切れを管理する

BusinessプランやEnterpriseプランでは、回答に応じて表示する質問を変える条件付きロジックも使えます。

ただし、複雑な分岐が多いフォームは、Notionで無理に作らない方がよい場合もあります。

分岐、本人確認、決済、添付ファイル制御、厳密な同意取得が必要なら、専用フォームや業務システムを検討します。

回答DBを先に設計する

Notionフォームの設計では、フォーム画面より回答DBを先に作ります。

問い合わせフォームなら、次のようなプロパティが必要です。

プロパティ	型	目的
件名	タイトル	何の問い合わせか
回答者	作成者、テキスト	誰から来たか
会社名	テキスト	外部問い合わせの場合の所属
メールアドレス	メール	返信先
種別	セレクト	資料請求、相談、サポート、その他
内容	テキスト	問い合わせ本文
ステータス	ステータス	未確認、対応中、完了
担当者	ユーザー	処理する人
初回返信期限	日付	放置を防ぐ
個人情報含む	チェックボックス	権限と削除判断に使う

社内申請なら、項目は変わります。

プロパティ	型	目的
申請名	タイトル	申請の名前
申請者	ユーザー	誰が出したか
申請種別	セレクト	経費、備品、アカウント、休暇など
希望日	日付	いつまでに必要か
承認者	ユーザー	誰が判断するか
承認状態	ステータス	未確認、承認、差し戻し、却下
差し戻し理由	テキスト	何を直すか

フォームの質問名は、回答者に分かりやすい言葉にします。

DBのプロパティ名は、運用者が扱いやすい短い名前にします。

公式ヘルプでは、フォームの質問とDBプロパティ名の同期を切り替えられることも説明されています。

回答者向けの文言と、DB運用者向けのプロパティ名を分けると、フォームとDBの両方が使いやすくなります。

Notionデータベースの作り方

問い合わせフォーム

問い合わせフォームでは、回答を受けるだけでなく、受付後の処理をDBで回します。

最低限のビューは次の通りです。

ビュー	フィルター	見る人
未確認	ステータスが未確認	管理者、一次受付
自分の対応中	担当者が自分、完了以外	各担当者
初回返信期限切れ	初回返信期限が今日以前、完了以外	責任者
種別別	種別でグループ化	チームリーダー
完了済み	ステータスが完了	管理者

問い合わせフォームで重要なのは、初回返信期限です。

「未確認」だけでは、どれが危ないか分かりません。

フォーム送信日から1営業日以内など、自社の基準で初回返信期限を持たせます。

問い合わせ内容をAIで要約したい場合もあります。

ただし、AI要約は下書きです。

顧客への返信、契約条件、個人情報の扱い、対応方針は人が確認します。

社内申請フォーム

社内申請フォームは、承認フローを軽く回す用途に向いています。

たとえば、備品申請、アカウント発行依頼、マニュアル修正依頼、軽い稟議前相談などです。

申請	Notionで管理しやすい項目
備品申請	希望品、希望日、理由、承認者、対応状態
アカウント発行	対象システム、権限、利用者、期限
マニュアル修正	対象ページ、修正内容、優先度、担当者
社内問い合わせ	部署、内容、回答者、FAQ化

ただし、正式な稟議、契約、労務、会計処理は、Notionだけで完結させない方がよいです。

Notionで受け付けるとしても、正式な承認や証跡は、freee、ジョブカン、Google Workspace、kintoneなどの専用システムへ分けます。

Notionには、次の役割を持たせます。

Notionに置く	外部システムに置く
受付、分類、担当、下書き相談	正式承認、会計処理、労務記録
差し戻しコメント	契約、給与、監査ログ
FAQ化、マニュアル更新	法的保存が必要な証跡

通知と自動化

フォームは、回答が集まるだけでは不十分です。

新しい回答が来たら、誰かが気づき、DB上で処理できる必要があります。

Notion公式ヘルプでは、フォームにオートメーションを組み込み、新しい回答を受け取ったときや回答内容に応じてアクションを実行できると説明されています。

Notion公式ヘルプ：データベースオートメーション

実務で使いやすい自動化は、次のようなものです。

自動化	目的
新規回答時に担当チャンネルへ通知	見落としを防ぐ
種別に応じて担当者を設定	一次振り分けを軽くする
ステータスを未確認にする	ビューで拾えるようにする
期限を設定する	初回返信や承認期限を管理する
回答者へ受付完了を返す	送信後の不安を減らす

自動化で何でも処理しようとしない方がよいです。

判断が必要なもの、例外が多いもの、顧客への返信文面、承認可否は人が確認します。

Notionフォームの自動化は、受付、通知、初期分類、期限設定までに絞ると安定します。

Notion通知設定の基本

権限と個人情報

フォーム回答DBには、個人情報や機密情報が入りやすいです。

問い合わせなら、名前、メールアドレス、会社名、相談内容が入ります。

社内申請なら、社員名、希望日、申請理由、場合によっては労務や経費に関わる情報が入ります。

フォームを作る前に、次を決めます。

項目	確認すること
回答DBの閲覧者	誰が回答を見られるか
回答DBの編集者	誰がステータスや担当者を変えられるか
回答者の送信後アクセス	回答を見られるか、編集できるか
Web共有	社外や匿名回答を許可するか
保管期限	いつ削除するか
外部共有	顧客、パートナー、ゲストに見せてよいか

公式ヘルプでは、フォームの共有設定や回答者の送信後アクセス、匿名回答、回答DBを見るために必要な権限が説明されています。

また、Enterpriseプランでは、ワークスペースメンバーがフォームをWeb上のリンクを知っている全員に共有できないようにする設定もあります。

Notion公式ヘルプ：共有と権限

フォーム回答DBは、広く共有しすぎない方がよいです。

外部共有ページに回答DBをそのまま置かない。

社内全体に見せる必要がない回答は、担当チームだけに絞る。

個人情報を含む回答は、保管期限と削除方法を決める。

ここまで決めてからフォームを公開します。

外部フォームを使う判断

Notionフォームは便利ですが、すべてのフォームに向いているわけではありません。

次のような場合は、Googleフォーム、Typeform、HubSpot、kintone、専用申請システムなどを検討します。

外部フォームを検討するケース	理由
回答数が多い	Notion DBが重くなりやすい
複雑な分岐が多い	専用フォームの方が設計しやすい
決済や本人確認が必要	Notionフォームの範囲外
高度な集計や分析が必要	SheetsやBIに寄せた方がよい
厳密な承認フローが必要	専用ワークフローの方が安全
個人情報や契約情報を扱う	権限、監査、保存ルールが重要

Notionフォームが向いているのは、回答後にNotion DBで処理する業務です。

問い合わせを受け、担当を決め、期限を見て、FAQやタスクにつなげる。

社内申請を受け、承認者を決め、差し戻し、完了まで管理する。

アンケートを受け、分類し、改善項目やナレッジに反映する。

この範囲なら、NotionフォームはNotion DBの入口として有効です。

まとめ

Notionフォームは、Notion内に回答を集められる便利な機能です。

ただし、フォーム画面だけ作っても、業務は回りません。

先に回答DBを設計し、種別、担当者、ステータス、期限、通知、権限、保管期限を決めます。

問い合わせ、社内申請、アンケートでは、回答後に誰が何を確認し、どの状態に進めるかをビューで見えるようにします。

通知や自動化は、受付、初期分類、期限設定、担当通知までに絞ると安定します。

個人情報や外部共有を含むフォームでは、回答DBの閲覧範囲、回答者の送信後アクセス、Web共有の可否を必ず確認します。

Notionフォームは、単なる入力画面ではありません。

回答DBに業務を流し込み、担当・期限・ステータスで処理するための受付システムです。