Notionで見積書テンプレートを作る方法と見積管理データベース設計｜税込計算・明細・返信のない見積の督促まで
見積書をNotionで作る記事は数多くありますが、そのほとんどは「列を設計して消費税を自動計算する」ところで終わっています。実際の受注業務でつまずくのは、その先――送った見積の返信が来ない、有効期限が近づいているのに追いかけられていないという局面です。この記事は、Excel/Wordの見積から脱却してNotionで見積を作り始めた（または検討中の）フリーランス・制作会社に向けて、見積管理データベースの作り方を実務レベルで示し、さらに上位記事のほぼ空白地帯である「返信のない見積・期限切れ間近だけを自動でリマインドする運用」と「Notionを使わない取引先にどう届けるか」まで一気通貫で解説します。
この記事の要点（TL;DR）
- 見積管理データベースの核は「見積番号・案件名・クライアント名・見積額・有効期限・ステータス」のプロパティ設計。ここまでは多くの記事が解説済み。
- 明細（内訳）は親アイテム/サブアイテムで作り、消費税は数式（
prop()で単価×数量を参照）、合計はロールアップで親に集計するのが定石。- 上位記事に薄いのは「作ったあと」。承認済み・失注済みには送らず、返信のない見積・期限切れ間近だけを条件抽出して自動リマインドする運用と、Notion非利用の取引先への届け方が空白。
- Kapselとは、Notionの期日・担当・ステータスを監視し、Notionを使わない社外の相手にもメールで自動リマインドを送り、受信者のワンクリックでNotionのステータスへ書き戻す通知ツールです。承認済み・失注・入金済みには送りません。
この記事の対象読者と前提
この記事は、次のような人を想定しています。
- 見積をExcel/Wordで作っていたが、案件管理はNotionに移しており、見積もNotionで一元化したいフリーランス・制作会社
- 見積の作り方（列設計・税計算）だけでなく、送ったあとの返信管理・催促まで含めて仕組みにしたい人
前提として、Notion標準のリマインダーやメンションは「Notionを開いている本人」に届く通知です。社内メンバーには有効ですが、Notionアカウントを持たない取引先（クライアント）には届きません。見積の相手はたいてい社外なので、「作る」だけをNotionで完結させても、「催促を届ける」段階でNotionの外に出る必要がある――この前提を最初に押さえておくと、後半の設計がすっきりします。
Notionデータベースそのものの基礎（テーブルの作り方・プロパティの種類・数式の基本）はNotionデータベースの作り方に譲り、本記事は見積特化で進めます。
Notionで見積書データベースを作る（列設計）
まず土台となるデータベースを1つ作ります。1行（1アイテム）＝1件の見積、というシンプルな構造です。見積書を「文書」ではなく「データベースの1レコード」として扱うことで、あとからステータス別に集計したり、期限で絞り込んだりできるようになります。これがWord/Excelの見積との決定的な差です。一度この構成を作ってしまえば、次の見積のたびにゼロから組み直す必要はありません。ページを複製（Duplicate）すれば、同じプロパティ・数式を引き継いだまま次の見積に取りかかれます——配布されているテンプレートを複製して使うのと同じ発想を、自分の運用に合わせて作った構成でも再現できます。
最低限必要なプロパティ
見積管理データベースで最初に用意したいプロパティは次のとおりです。多機能にしすぎず、まずこの範囲で運用を始めるのが、運用が崩れにくいコツです。
| プロパティ | 種類 | 役割 / 入れる値 | 読者にとっての意味 |
|---|---|---|---|
| 見積番号 | ユニークID or テキスト | Q-2026-001 など連番 | 問い合わせ時に案件を一意に特定できる |
| 案件名 | タイトル | 「コーポレートサイト制作」等 | 一覧で何の見積か即わかる |
| クライアント名 | テキスト or リレーション | 取引先名 | 取引先ごとの絞り込み・集計の軸になる |
| 見積日 | 日付 | 発行日 | 発行からの経過日数を追える |
| 有効期限 | 日付 | 「発行から30日」等 | 期限切れ間近を絞り込む鍵になる |
| 見積額（税込） | 数式 or 数値 | 合計金額 | ステータス別の金額集計に使う |
| ステータス | ステータス or セレクト | 送付済み/確認中/承認済み/失注 等 | 送る/送らないの判定軸になる |
| 担当者 | ユーザー | 自社の担当 | 社内リマインドの宛先になる |
💡 ポイント：「有効期限」と「ステータス」の2つは、後半の自動リマインド運用で送信対象を絞り込む条件になります。この2列だけは最初から入れておくと、あとで運用を自動化するときの手戻りを減らせます。
見積番号は「ユニークID」プロパティを使うと採番が自動化できますが、Q- のような接頭辞を付けて連番で振る運用でも十分です。
親アイテム/サブアイテムで明細行を作る
見積には「デザイン ¥150,000」「コーディング ¥200,000」のような明細（内訳）が必要です。Notionではサブアイテム機能を使うと、1件の見積（親）にぶら下げる形で明細行（子）を管理できます。
設定は、データベースの設定 →「サブアイテム」をオンにするだけです。すると各アイテムにトグルが付き、その中に子アイテム＝明細行を追加できます。ウェブ制作なら親＝「コーポレートサイト制作」、サブアイテム＝「デザイン」「コーディング」「ディレクション」という構造です。
この構造にしておくと、明細を増減しても親の合計が自動で追従するので、金額の計算ミスが起きにくくなります。
消費税の自動計算式
明細ごとの金額は「単価 × 数量」で出し、そこに消費税を掛けて税込を求めます。Notionの数式（フォーミュラ）では、prop() で他プロパティの値を参照して計算できます。
各サブアイテムに「単価」「数量」プロパティ（数値）を用意し、「小計（税抜）」と「税込」を数式で出す考え方は次のとおりです。
// 小計（税抜）＝ 単価 × 数量
prop("単価") * prop("数量")
// 税込（10%）＝ 小計 × 1.1 を四捨五入
round(prop("小計") * 1.1)
税率を掛けた結果には端数が出るため、round()（四捨五入）・floor()（切り捨て）・ceil()（切り上げ）のいずれで処理するかを取引先ごとの慣習に合わせて統一しておくと、あとで金額がずれません。軽減税率（8%）の品目が混ざる場合は、税率を固定で掛けず、品目ごとに税率プロパティを持たせて prop("小計") * (1 + prop("税率")) のように参照するのが安全です。
⚠️ 注意（端数処理とインボイス）：消費税の端数処理は、1つの適格請求書（インボイス）につき税率ごとに1回、というのが制度上の原則です。明細1行ごとに端数処理して積み上げると、適格請求書の要件と合わなくなる場合があります。明細では税抜で積み上げ、税額の端数処理は請求書単位（税率ごとの合計に対して1回）で行う設計にしておくと、後工程の請求書でつまずきません。具体的な制度要件は国税庁のインボイス制度の資料で確認してください。
数式の細かな構文（ifs() や lets() など）は本記事の主題から外れるため、Notionデータベースの作り方の数式パートを参照してください。
合計金額のロールアップ
サブアイテム（明細）の金額を親アイテム（見積本体）に集計するにはロールアップを使います。ロールアップは「関連づいた別レコードの値を、集計して表示する」プロパティです。サブアイテムは親と自動でリレーションされているため、それを対象にできます。
手順は次のとおりです。
- 親アイテム側に「ロールアップ」プロパティを追加する
- 参照元（リレーション）として「サブアイテム」を選ぶ
- 集計対象のプロパティに「小計（税抜）」を選ぶ
- 計算方法に「合計（Sum）」を選ぶ
これで、明細を1行足すだけで親の合計が自動更新されます。手で足し算し直す必要がなくなるので、「明細を直したのに合計を直し忘れた」というミスが起きにくくなります。同じ要領で「税込合計」もロールアップできます。
💡 縦の計算と横の計算：ロールアップ（サブアイテムの合計を親に集める）は縦方向の集計、数式（1レコード内で単価×数量×税率）は横方向の計算、と役割が分かれています。この2つを組み合わせるのが、Notionで見積金額を自動化する基本形です。
見積のステータス設計と有効期限管理
見積を「作る」仕組みができたら、次は「追える」状態にします。ここがステータスと有効期限の設計です。後半の自動リマインドは、すべてこの2つの列を条件に動きます。
ステータス例
ステータスは多すぎると運用が崩れます。見積のライフサイクルを表す最小限に絞るのがコツです。
| ステータス | 意味 | この後のアクション |
|---|---|---|
| 送付済み | 見積を相手に送った | 返信待ち。数日で確認中へ |
| 確認中 | 先方が検討している | 有効期限が近ければ督促対象 |
| 承認済み | 受注確定 | 請求フェーズへ。督促は止める |
| 失注 | 他社決定・見送り | クローズ。督促は止める |
| 期限切れ | 有効期限を過ぎた | 再提案するか失注にするか判断 |
ポイントは、「承認済み」と「失注」はそれ以上追いかけてはいけない終端ステータスだということです。ここに督促が飛ぶと事故になります（後述）。ステータスでグループ化したボード（カンバン）ビューを1つ作っておくと、提案中・承認済み・失注がそれぞれ何件あるかが一覧でわかり、見積の進捗をダッシュボード的に俯瞰できます。
有効期限が近いものだけを絞り込むビュー
「有効期限が近い、まだ確認中の見積」だけを一覧にするビューを作っておくと、毎朝ここを見るだけで追うべき案件がわかります。
フィルタの条件はシンプルです。
- ステータス が「確認中」または「送付済み」（＝まだ決着していない）
- かつ 有効期限 が「今日から◯日以内」（相対日付フィルタ）
Notionの日付フィルタには「Is on or before」「Is within（相対日付：今後1週間 など）」があるので、「有効期限 is within the next 1 week」のように設定すれば、期限が迫った未決着の見積だけが並びます。並べ替えを「有効期限の昇順」にすれば、切れそうな順に見られます。
💡 ポイント：このビューは「手動で追う」ための最短装置です。ただし、これは自分がNotionを開いて巡回する前提です。開かなければ気づけない――この巡回そのものを自動化するのが次の章です。
【上位に薄い／Kapsel独自】返信のない見積・期限切れ間近だけを自動でリマインドする運用
ここからが、見積管理の記事の多くが触れていない領域です。上位記事は「ステータスで可視化しましょう」「ダッシュボードを作りましょう」で終わり、そこから先の実際に催促を届けるアクションは、Notionと切り離された「催促メール例文サイト」に分断されています。見積データベースと催促を連動させる、その橋渡しをここで示します。
なぜ『全件一律の督促』はNGか
「確認中の見積に一括でリマインドを送る」という発想は危険です。理由は、ステータスの更新が常にリアルタイムとは限らないからです。既に電話で受注が決まっているのにNotion上はまだ「確認中」、といったズレは日常的に起きます。この状態で機械的に全件へ督促すると、すでに承認してくれた相手に「まだご返信いただけていません」と催促が飛ぶ――信頼を損なう典型的な事故です。
したがって督促は「送る対象」ではなく「送ってはいけない対象を除外する」発想で設計します。承認済み・失注は必ず除外し、送るのは「確認中／送付済み かつ 有効期限が近い」ものだけに絞ります。
確認中を全部リマインド → 受注済み・失注にも督促 → 信頼を損なう
承認済み・失注を除外、期限が近い未決着だけ → 誤送信のリスクを抑えられる
Notionのステータス×有効期限を条件に、未回答の見積だけを抽出してメールで自動リマインド
前章で作ったビューの条件（ステータス＝確認中/送付済み、かつ有効期限が近い）を、そのまま自動配信の条件にできれば、巡回そのものが不要になります。
Kapselは、Notionの見積管理データベースを監視し、「ステータスがこれ、かつ有効期限がこの範囲」という条件に合う見積だけを抽出して、リマインドメールを自動送信します。条件から外れたもの（承認済み・失注）は送信対象になりません。見積番号・案件名・見積額・有効期限などは差し込み変数として本文に差し込めるため、1件ずつ文面を書き換える必要がありません。
これにより、「期限が近い未回答の見積がないか、毎日Notionを開いて確認する」という手動の巡回作業が不要になります。追い忘れによる失注・取りこぼしを、意志の力に頼らず仕組みで防ぎやすくなるのが実務上の価値です。
Notionを持たない取引先にもメールで届き、先方のワンクリックでステータスが書き戻る仕組み
見積の相手は、ほぼ必ずNotionを使わない社外のクライアントです。ここが最大の落とし穴で、Notion標準の通知やメンションは相手に一切届きません。相手はNotionアカウントを持っていないからです。
Kapselのリマインドはメールで届くため、受信側にNotionアカウントもログインも不要です。さらに、メール内のボタンを相手がワンクリックすると、その応答（「確認しました」等）がNotion側のステータスに書き戻ります。一方向の「作って共有する」で止まらず、先方の反応がNotionに戻ってくる双方向になっている点が、既存の見積記事にない部分です。
見積の督促と対になる「入金の督促」まで進んだ場合の運用は入金督促メールの例文集や未入金の督促を自動化する運用に、請求フェーズ以降の自動リマインドは請求書の入金リマインド自動化にまとめています。見積〜入金までの追いかけを俯瞰したい場合はフリーランスの入金管理ハブも参照してください。
見積から請求への連携
見積が「承認済み」になったら、次は請求書です。Notionでは、見積管理データベースと請求管理データベースをリレーションでつなぐと、書類一式（見積書→請求書→領収書）を同じ案件の情報でひもづけられます。
考え方はシンプルです。
- 「請求管理」データベースを別に作る
- 請求側に「対応する見積」というリレーションプロパティを追加し、見積DBと関連づける
- 請求書には、見積からロールアップで金額やクライアント名を引いてくる
- PDF化・送付まで自動化したい場合は、NotionをMake（旧Integromat）やStripeと連携し、承認済みステータスをトリガーにPDF生成・メール添付までを自動化する構成を組んでいる記事もあります（本記事が扱うリマインド運用とは別レイヤーの応用編です）
こうすると、承認済み見積からワンクリックで請求レコードを起こし、金額の二重入力を避けられます。見積→請求→入金の流れ全体を「案件」という1本の線でつなげるのが、Notionで書類管理を一元化する利点です。入金が確認できたら、同じ要領で「請求管理」データベースに「領収書発行済み」のチェックボックスや発行日プロパティを追加しておくと、見積→請求→領収書という書類一式の進捗を、同じ案件ページから最後まで追えます。請求フェーズでの入金リマインドの具体は商談・見積後の追客ハブ記事および前掲の請求・督促クラスタ記事に接続します。
よくあるつまずきを先回りで回避する
最後に、見積管理をNotionで運用するときに実際に起きやすいつまずきと、その回避策を整理します。
| つまずき | 何が起きるか | 先回りの回避策 |
|---|---|---|
| 承認済みなのに督促が飛ぶ | 受注済み客に催促メール→信頼低下 | 送信条件を「承認済み・失注は除外」で組む。送る対象ではなく送らない対象を定義する |
| 消費税計算のズレ | 明細ごとに端数処理して合計が合わない | 明細は税抜で積み上げ、端数処理は請求書単位（税率ごとに1回）で行う |
| サブアイテムが重い | 明細を作り込みすぎてページが重くなる | 1見積の明細は必要な粒度に留める。大量明細は別DBリレーションに切り出す |
| ステータス更新漏れ | Notion上の状態が実態とずれ、督促が誤爆 | 受注・失注が決まったら即ステータス更新を徹底。自動リマインドは終端ステータスを必ず除外 |
| 相手に通知が届かない | Notionメンションしたのに気づかれない | 社外相手にはNotion内通知は届かない前提。メールで届く手段を使う |
⚠️ 注意：最も避けたい事故は「承認済み・失注への誤送信」です。ステータス更新は人間が行う以上、更新漏れは必ず起きます。だからこそ、自動リマインドは終端ステータスを条件で除外する設計（＝人の運用に依存しすぎない設計）にしておくことが、事故防止の要になります。
よくある質問
Notionで見積書は無料で作れますか（テンプレートは複製だけで使えますか）
はい。Notionの無料プランでも、データベースを作って見積管理・見積書テンプレートを運用できます。配布されている見積テンプレートは、ページ右上の「複製（Duplicate）」で自分のワークスペースにコピーすれば、そのまま編集して使えます。プロパティや数式もコピーされるため、消費税の計算式などを一から組む必要はありません。
Notionの見積書テンプレートで消費税はどう自動計算しますか
数式（フォーミュラ）プロパティで、prop("単価") * prop("数量") で税抜小計を出し、それに税率を掛けて税込を求めます。端数は round() などで統一して処理します。ただし明細1行ごとに端数処理すると請求書（インボイス）要件とずれる場合があるため、端数処理は請求書単位（税率ごとに1回）で行う設計が安全です。
見積書と請求書をNotionで連携させるにはどうすればいいですか
見積管理データベースと請求管理データベースを別々に作り、リレーションプロパティでつなぎます。請求側から「対応する見積」を参照すれば、金額やクライアント名をロールアップで引いてこられ、二重入力を避けられます。承認済みの見積から請求レコードを起こす運用にすると、案件情報が1本の線でつながります。
見積の有効期限が切れたものだけを一覧で見る方法はありますか
はい。ビューにフィルタを設定します。「有効期限 is on or before 今日」で期限切れだけ、「有効期限 is within the next 1 week」で期限が近いものだけを抽出できます。ステータスで「確認中／送付済み」に絞り、有効期限の昇順で並べ替えると、追うべき見積が切れそうな順に並びます。
見積の返信が来ない相手にだけ自動でリマインドを送ることはできますか
条件を「ステータス＝確認中/送付済み、かつ有効期限が近い」に絞れば、未回答の見積だけを対象にできます。Kapselはこの条件に合う見積だけを抽出してメールを自動送信し、承認済み・失注は対象から除外します。全件一律ではなく、返信のない未決着の見積だけを追いかけられます。
取引先がNotionを使っていなくても見積の催促は届きますか
届きます。Notion標準の通知やメンションはNotionアカウントを持つ人にしか届きませんが、Kapselのリマインドはメールで送られるため、受信側にNotionアカウントもログインも不要です。メール内のボタンを相手がクリックすると、その応答がNotionのステータスに書き戻ります。
見積が承認済みなのに督促メールが飛んでしまうのを防ぐには
送信条件で「承認済み・失注」を除外するのが基本です。送る対象を定義するのではなく、送ってはいけない終端ステータスを除外する発想で組みます。Kapselは承認済み・失注・入金済みには送らない設計のため、ステータスさえ更新されていれば受注済み客への誤送信を防げます。
Notionのサブアイテム機能で見積の内訳（明細）を作るにはどうすればいいですか
データベース設定でサブアイテムをオンにすると、各見積（親）の中に明細行（子）を追加できます。子に「単価」「数量」「小計」を持たせ、親側にロールアップ（合計）を設定すれば、明細を増減するだけで親の合計金額が自動更新されます。手計算の足し直しが不要になります。
補足・注記
- 本記事の公開日は2026-10-01です。記載しているNotionの機能（サブアイテム、ロールアップ、数式／フォーミュラ、日付フィルタ、ユニークID等）および操作手順は、Notion公式ヘルプセンターで公開されている仕様に基づきます。UIの名称や挙動はアップデートにより変わる場合があるため、最新の仕様は公式ヘルプで確認してください。
- 消費税の端数処理・適格請求書（インボイス）の要件については、国税庁が公開するインボイス制度の資料を一次情報として参照してください。本記事の税計算の記述は執筆時点の一般的な考え方であり、個別の税務判断は税理士等の専門家にご確認ください。
- Kapselの機能（Notionの期日・担当・ステータスの監視、社外へのメールリマインド、ワンクリックでのステータス書き戻し、承認済み・失注・入金済みへの非送信、差し込み変数、対象の絞り込み、送信記録）および料金（税込：Free ¥0／Standard ¥1,980／Pro ¥4,980）は執筆時点のものです。最新の内容はサービスサイト（getkapsel.com）でご確認ください。
