kintone見積書作成の設計方法｜明細・承認・帳票・受注連携まで

kintoneで見積書を作成したい相談では、最初に帳票の見た目が話題になりがちです。

会社ロゴ、宛名、件名、明細、合計金額、有効期限、備考、印影、PDF出力。

もちろん、顧客に提出する以上、見積書の見た目は重要です。

ただし、実務で困るのは、見積書を印刷できないことだけではありません。

本当に崩れやすいのは、次のような状態です。

• 見積番号や版番号がなく、どれが最新の見積か分からない
• 1つの見積に複数明細があるのに、ヘッダーと明細が混ざっている
• 商品名、単価、税区分、値引きが自由入力でぶれる
• 値引きや特別条件の承認ルールがない
• 見積を出した後に、受注、請求、売上管理へつながらない
• 見積PDFはあるが、送付日、送付先、顧客の反応が残らない
• 見積の改訂理由や失注理由が残らない
• 帳票出力プラグイン、受注管理、請求書、freeeのどこを正本にするか決まっていない

見積書作成は、帳票を出す仕事ではありません。

顧客へ提示する条件を決め、承認し、受注・請求へ渡せる状態にする仕事です。

kintone見積書作成で最初に決めるべきなのは、帳票レイアウトではなく、「見積データ・明細・価格・承認・受注連携のどれをkintoneの正本にするか」です。

この記事では、kintoneで見積書作成を崩れにくい業務システムとして設計する方法を整理します。

kintone案件管理の設計方法はこちら
kintone受注管理の設計方法はこちら

先に結論：見積書は帳票ではなく業務データとして設計する

kintoneで見積書を作るとき、見積書アプリ1つだけでも始めることはできます。

ただし、営業、承認、受注、請求までつなげるなら、最初から次の情報を分けます。

分けるもの	1レコードの意味	役割
顧客・案件	1社、1商談、1相談	見積先、商談背景、担当者を持つ
商品マスタ	1商品、1サービス、1SKU	商品名、標準単価、税区分、原価を統一する
価格表	1商品、1期間、1顧客条件	標準単価、顧客別単価、値引条件を管理する
見積ヘッダー	1見積、1提出単位	見積番号、顧客、件名、有効期限、状態を持つ
見積明細	1見積の1行	商品、数量、単価、値引、金額を持つ
承認	1回の社内確認	値引、粗利、特別条件、支払条件を確認する
版管理	1つの改訂	初版、再見積、条件変更、失注を追う
帳票出力	1回のPDF・印刷出力	出力日、送付先、出力版を残す
受注候補	1つの受注化対象	承認済み見積を受注や契約へ渡す
連携ログ	1回の外部連携	帳票、受注、請求、会計連携の成否を追う

見積ヘッダーは、見積全体の条件です。

見積明細は、商品やサービスの内訳です。

商品マスタは、品目の辞書です。

価格表は、単価と値引きのルールです。

承認は、提出してよい条件かを確認する場所です。

帳票出力は、承認済みデータを顧客に渡す形へ変える処理です。

これを1つの見積アプリに混ぜると、見積書は出せても、金額の根拠、値引き判断、改訂履歴、受注・請求への引き渡しが曖昧になります。

サイボウズのサンプルアプリ「商品見積書パック」でも、見積書と商品リストを関連付け、商品リストから型番、商品名、単価などをコピーして見積を作成する構成が紹介されています。

サイボウズ：商品見積書パック

重要なのは、この構成をそのまま使うことではありません。

自社の見積業務に合わせて、どこまでをkintoneで持ち、どこから帳票・受注・請求システムへ渡すかを決めることです。

見積・明細・商品マスタを分ける

見積書作成で最初に崩れやすいのは、見積ヘッダーと明細を混ぜることです。

1つの見積には、複数の商品やサービスが入ることがあります。

同じ顧客に対して、複数案の見積を出すこともあります。

数量、単価、値引き、税区分、備考は明細ごとに変わります。

そのため、最低限、次のアプリまたはデータ単位に分けます。

アプリ	1レコードの意味	主なフィールド
顧客・案件	1顧客、1商談	顧客名、担当者、案件名、営業担当、確度
商品マスタ	1商品、1サービス	商品コード、商品名、標準単価、税区分、原価
価格表	1商品の価格条件	適用期間、顧客区分、単価、値引上限
見積ヘッダー	1提出見積	見積番号、件名、顧客、提出日、有効期限、状態
見積明細	1見積の1行	商品、数量、単価、値引、金額、税区分
承認履歴	1回の承認・差し戻し	承認者、承認日、理由、修正内容
帳票出力履歴	1回のPDF出力	出力版、出力日、送付先、ファイル
受注連携ログ	1回の受注・請求転記	連携先、結果、エラー、再実行

見積ヘッダーに持たせる項目

見積ヘッダーは、顧客に提出する見積全体の条件を持ちます。

フィールド	型	設計意図
見積番号	文字列、採番	見積のキーにする
版番号	数値、文字列	改訂履歴を追う
件名	文字列	一覧や帳票の見出しに使う
顧客	ルックアップ	顧客マスタと紐づける
案件	ルックアップ	商談や提案の背景とつなげる
提出予定日	日付	営業の締切を見る
提出日	日付	顧客へ出した日を残す
有効期限	日付	価格や条件の期限を示す
見積状態	ステータス	作成中、承認中、提出済み、受注、失注など
支払条件	ドロップダウン、文字列	請求・契約前の条件
備考	文字列複数行	顧客向け補足、社内メモは分ける

見積明細に持たせる項目

見積明細は、商品やサービスの内訳です。

kintoneのテーブルは、1レコード内で複数行の入力を扱うのに便利です。

kintoneヘルプ：フォームにテーブルを追加する

ただし、明細をテーブルにするか、別アプリにするかは業務量で決めます。

設計	向いているケース	注意点
見積ヘッダー内のテーブル	明細数が少なく、見積内で完結する	明細単位の承認・集計・連携が弱くなる
見積明細アプリを分ける	明細単位で原価、納期、受注、請求を見る	アプリ間連携や一覧設計が必要
商品マスタからルックアップ	商品名、単価、税区分を統一したい	価格改定時の扱いを決める
帳票出力側で整形	レイアウトを重視する	業務データの正本にしない

明細に持たせる項目は、次のようになります。

フィールド	型	設計意図
関連見積	ルックアップ	見積ヘッダーと紐づける
商品コード	ルックアップ	商品マスタを参照する
商品名	文字列	提出時点の名称を残す
数量	数値	金額計算に使う
単価	数値	見積時点の単価を残す
値引額・値引率	数値	承認条件に使う
金額	計算	数量、単価、値引きから算出する
税区分	ドロップダウン	請求・会計連携の候補にする
原価	数値	粗利確認に使う
明細備考	文字列複数行	商品ごとの条件を残す

見積書は提出時点の条件を残す必要があります。商品マスタの現在値を参照するだけでなく、提出時の単価・名称・税区分を見積明細に保存します。

価格表・値引き・有効期限

見積書作成で事故になりやすいのは、価格です。

商品名や数量よりも、単価、値引き、有効期限、支払条件の方が後で揉めます。

価格表を使う場合は、次の情報を分けます。

価格データ	役割
標準単価	通常価格
顧客別単価	特定顧客に適用する価格
期間別単価	キャンペーン、価格改定前後
数量別単価	ボリュームディスカウント
値引上限	営業担当だけで判断できる範囲
承認必要条件	値引率、粗利、支払条件など
有効期限	いつまで提示条件が有効か

価格表アプリを作る場合は、次の項目を持たせます。

フィールド	型	設計意図
価格表コード	文字列、採番	価格条件のキー
商品	ルックアップ	商品マスタと紐づける
顧客区分	ドロップダウン	通常、代理店、既存顧客など
適用開始日	日付	価格改定に対応する
適用終了日	日付	古い価格の誤用を防ぐ
標準単価	数値	基準価格
最低単価	数値	承認なしで出せない下限
値引上限率	数値	承認条件に使う
税区分	ドロップダウン	請求前の候補にする
備考	文字列複数行	条件や例外を残す

値引きは、自由入力にしない方がよいです。

自由入力にすると、担当者ごとに判断が変わり、承認や粗利確認に使えません。

値引き条件	承認の考え方
値引率5%以内	営業担当で可
値引率10%以内	マネージャー承認
粗利率が基準未満	管理者承認
支払条件が通常外	経理・管理部門確認
契約期間が短い	営業責任者確認
個別開発や保守を含む	実装担当・管理者確認

有効期限も重要です。

価格改定やキャンペーンがある会社では、見積を出した日と受注日がずれることがあります。

そのため、見積ヘッダーに有効期限を持ち、期限切れ見積から受注・請求へ進めないルールを作ります。

承認フローと版管理

見積書は、顧客に提出する前に承認が必要になることがあります。

特に、値引き、粗利、支払条件、納期、契約期間、個別作業を含む場合です。

kintoneのプロセス管理は、ステータス、作業者、アクションを使って業務の進捗を管理できます。

kintoneヘルプ：プロセス管理

見積承認では、次のようなステータスを使います。

ステータス	意味	次に動く人
下書き	営業が作成中	営業担当
承認申請中	提出前確認中	マネージャー、管理者
差し戻し	修正が必要	営業担当
承認済み	顧客へ提出可能	営業担当
提出済み	顧客へ送付済み	営業担当
再見積	条件変更が必要	営業担当
受注	顧客が承諾	受注・契約担当
失注	受注しない	営業担当

承認条件は、できるだけ構造化します。

承認条件	見ること
値引率	標準価格からどれだけ下げたか
粗利率	原価を引いた利益が基準を満たすか
支払条件	前払い、月末締め、分割、後払いなど
契約期間	短期、長期、自動更新の有無
納期	実現可能な納期か
個別条件	特別対応、保証、保守範囲
法務・経理確認	契約や請求条件に問題がないか

版管理も必須です。

見積は一度出して終わりではありません。

顧客からの要望で、数量、範囲、値引き、納期、契約期間が変わります。

そのたびに見積を上書きすると、どの条件で顧客と合意したのか分からなくなります。

版管理で残すもの	例
版番号	初版、2版、3版
改訂理由	数量変更、値引き、範囲変更
改訂元見積	どの見積から作ったか
改訂日	いつ変更したか
改訂者	誰が変更したか
顧客提出有無	社内案か、顧客提出済みか
失注理由	価格、納期、競合、時期

kintoneのアプリアクションは、開いているレコードのデータをコピーして、同じアプリや別アプリに新しいレコードを作成できます。

kintoneヘルプ：アプリアクションでできること

これを使うと、前回見積をコピーして再見積を作る運用を設計できます。

ただし、コピーしただけでは版管理になりません。

改訂元、版番号、改訂理由、提出状態を必ず持たせます。

帳票出力プラグインの選び方

見積書では、帳票出力の見た目も大事です。

ただし、帳票出力プラグインを選ぶ前に、kintone側のデータ設計を固めます。

帳票プラグインは、業務データをきれいなPDFにするためのものです。

価格、承認、版管理、受注連携の責任を帳票側に持たせすぎると、後から追えなくなります。

判断軸	確認すること
レイアウト	既存の見積書フォーマットを再現できるか
明細行	行数、改ページ、小計、税区分に対応できるか
PDF保存	出力したPDFをkintoneに保存できるか
一括出力	複数見積をまとめて出せるか
権限	誰が出力できるか制御できるか
出力条件	承認済みだけ出力できるか
送付連携	メール送付、電子契約、ストレージ保存とつながるか
保守	フォーマット変更を誰が直すか

トムスの記事では、kintone標準機能での作成、サンプルアプリ、PrintCreatorや印刷設定プラグインなどの選択肢が紹介されています。

トムス：kintoneで見積書を作成する方法

コムデックの記事でも、見積書作成・印刷、請求書管理、プラグイン活用が整理されています。

コムデックAIラボ：kintoneでの見積書作成・印刷

これらの選択肢を検討するとき、Bitlightなら次の順番で決めます。

1. 見積ヘッダーと明細のデータ構造を決める
2. 承認済みの見積だけを帳票出力するルールを決める
3. 出力したPDFをどこに保存するか決める
4. 顧客へ送付した事実をどこに残すか決める
5. 受注・請求へ進める条件を決める
6. 最後に帳票プラグインを選ぶ

帳票プラグインは見積業務の最後の出力手段です。見積データ、承認、版管理、受注連携の設計がないまま入れると、きれいなPDFは出ても業務は追えません。

受注・請求・freee連携

見積書作成は、提出して終わりではありません。

顧客が承諾したら、受注、契約、納品、請求へ進みます。

そのため、見積から次に渡す情報を決めます。

見積側の情報	受注・請求側で使うもの
顧客	注文者、請求先、納品先
件名	受注名、請求件名
明細	商品、数量、単価、税区分
金額	受注金額、請求金額
支払条件	請求日、支払期限
有効期限	期限切れチェック
承認状態	受注へ進めてよいか
PDF	送付控え、契約前資料

kintone受注管理の設計方法でも触れたように、受注管理では、受注ヘッダー、受注明細、出荷、請求を分けます。

見積から受注へ進めるときも、同じ考え方が必要です。

連携方法	向いているケース	注意点
アプリアクション	見積から受注レコードを作る	明細や版情報の扱いを確認する
プラグイン	見積・請求の転記を簡単にしたい	プラグイン依存と保守を考える
API連携	freee、販売管理、基幹へ渡す	エラー、再実行、同期キーが必要
手動確認	件数が少なく例外が多い	転記ミスを防ぐチェックが必要

freeeなどの会計ソフトへつなぐ場合、kintoneを請求書の正本にするか、会計ソフトを正本にするかを決めます。

多くの場合、正式な請求書、入金、会計処理は会計ソフト側を正本にした方がよいです。

kintoneは、見積から請求候補を作る前段として使います。

領域	kintoneで持つ	会計・請求側で持つ
見積条件	見積番号、明細、承認、版	必要に応じて参照
受注判断	受注候補、契約前確認	正式な取引登録
請求予定	請求対象、締め、確認状態	請求書番号、送付、控え
入金	入金予定、確認メモ	入金消込、売掛金
会計	連携ログ、エラー	仕訳、税区分、帳簿

ここで重要なのは、二重管理を避けることです。

見積金額をkintoneで直し、請求金額を会計ソフトで直し、どちらが正しいか分からない状態にしない。

承認済み見積から受注・請求へ進む条件を明確にします。

権限設計と変更履歴

見積には、営業上の機密情報が含まれます。

単価、値引き、粗利、原価、支払条件、競合情報、顧客の予算感。

誰でも全見積を見られる設計にしてよいとは限りません。

特に、原価や粗利、値引き上限は見せる範囲を分けます。

役割	見せる範囲
営業担当	自分の案件、提出見積、顧客向け条件
営業マネージャー	チームの見積、値引き、承認対象
管理部門	支払条件、契約条件、請求前確認
経理	請求候補、税区分、支払条件
実装・納品担当	作業範囲、納期、前提条件
一般社員	原則、必要な範囲だけ

変更履歴も重要です。

サイボウズのサンプルアプリ説明でも、コメントや変更履歴で後から経緯を確認できることが紹介されています。

サイボウズ：商品見積書パック

ただし、変更履歴だけに頼らず、承認履歴や版管理を構造化します。

残すべき履歴	理由
値引き理由	なぜ標準価格から下げたか
承認者	誰が条件を認めたか
差し戻し理由	何を修正すべきか
改訂理由	顧客要望、数量変更、条件変更
送付日	いつ顧客へ出したか
受注・失注理由	次の営業判断に使う

見積は、顧客との約束の前段です。

変更や承認の経緯を残さないと、受注後に「どの条件で合意したのか」が分からなくなります。

よくある失敗パターン

kintone見積書作成でよくある失敗は、帳票出力から始めることです。

失敗	起きること	対策
見積アプリ1つに全部入れる	明細、承認、版、受注連携が混ざる	ヘッダー、明細、承認、版を分ける
商品名・単価を自由入力にする	集計や請求連携でぶれる	商品マスタと価格表を作る
提出時点の単価を残さない	価格改定後に根拠が追えない	見積明細に提出時の値を保存する
値引き承認を持たない	利益や条件が担当者依存になる	値引率・粗利で承認条件を分ける
見積を上書きする	改訂や失注理由が消える	版番号、改訂元、改訂理由を持つ
PDFだけを正本にする	受注・請求へデータ連携できない	見積データを正本にする
帳票プラグインに業務判断を寄せる	保守や変更が重くなる	kintone側で承認・状態を持つ
受注・請求への転記ルールがない	二重入力や金額差異が出る	連携条件とログを作る
原価や粗利の権限を考えない	見せるべきでない情報が広がる	役割別に閲覧範囲を決める

見積書は、営業の入口に見えます。

しかし、受注、契約、請求、納品、会計へつながるため、後工程の設計を無視すると必ず詰まります。

1週間で始めるならこの順番

kintone見積書作成を小さく始めるなら、最初から複雑な帳票やAPI連携を作らない方がよいです。

まずは、見積データが崩れず、承認済みの見積だけを出せる最小構成を作ります。

日程	やること	成果物
1日目	現在の見積書と運用を棚卸しする	フォーマット、項目、承認条件
2日目	見積ヘッダーと明細を分ける	見積番号、顧客、明細、金額
3日目	商品マスタと価格表を作る	商品コード、単価、税区分、原価
4日目	値引き・粗利の承認条件を決める	承認フロー、差し戻し理由
5日目	版管理と改訂ルールを決める	版番号、改訂元、改訂理由
6日目	帳票出力と送付履歴を設計する	PDF、出力条件、送付控え
7日目	受注・請求への引き渡しを試す	受注候補、請求候補、連携ログ

最初の検証では、対象を絞ります。

例えば、標準商品だけ、営業チーム1つだけ、値引きあり見積だけ、受注につながる見積だけ、などです。

この範囲で、次の点を確認します。

• 商品マスタから正しい単価を引けるか
• 提出時点の単価と税区分が残るか
• 値引きや粗利の承認条件が実務に合うか
• 改訂版を作ったときに元見積が分かるか
• 承認済みだけ帳票出力できるか
• PDFの送付日と送付先が残るか
• 受注・請求へ渡す項目が足りるか
• 権限設定で原価や粗利を見せすぎていないか

ここで詰まるなら、帳票レイアウトを作り込む前に、データ設計を直します。

実装前チェックリスト

kintone見積書作成を始める前に、次を確認します。

• 見積書を帳票として作るのか、受注・請求へつながる業務データとして作るのか決まっている
• 見積ヘッダーと見積明細を分ける方針が決まっている
• 商品マスタと価格表を使うか決まっている
• 提出時点の商品名、単価、税区分を見積明細に残す設計になっている
• 値引き、粗利、支払条件の承認ルールがある
• 見積番号、版番号、改訂元、改訂理由を持っている
• 承認済みだけ帳票出力するルールがある
• 出力したPDFの保存先と送付履歴が決まっている
• 受注、請求、freee・会計連携へ渡す項目が整理されている
• 連携エラーや未転記を一覧で見られる
• 原価、粗利、値引き条件の閲覧権限が決まっている
• 失注理由や再見積理由を残す設計になっている

このチェックリストで詰まるところが、kintoneの設定前に決めるべきことです。

特に、明細、価格、承認、版管理、受注・請求連携は後から直すと重くなります。

まとめ

kintoneで見積書を作成すること自体は難しくありません。

顧客名、商品名、数量、単価、金額を入れれば、見積書アプリは作れます。

帳票プラグインを使えば、PDFとして整った見積書を出すこともできます。

しかし、営業から受注・請求までつながる見積業務にするには、帳票だけでは足りません。

必要なのは、見積ヘッダー、見積明細、商品マスタ、価格表、承認、版管理、帳票出力、受注候補、請求連携を分けることです。

kintoneは、見積条件を整理し、承認し、受注・請求へ渡す前段の業務DBとして使うと強いです。

一方で、正式な請求書、入金、会計処理は、freeeなどの会計ソフトを正本にした方がよいケースが多いです。

見積書作成をkintoneで始めるなら、まず次の3つを決めてください。

• 見積ヘッダー、明細、商品・価格をどう分けるか
• 値引き、粗利、版管理、承認をどう扱うか
• 承認済み見積を受注・請求・freee連携へどう渡すか

この3つが決まっていれば、kintone見積書作成は単なる帳票出力ではなく、営業条件を社内で確認し、受注・請求へ正しく渡す業務システムになります。

逆に、ここを曖昧にしたまま帳票出力だけ作ると、PDFは出ているのに、価格根拠、承認、改訂、受注後の請求が後ろで詰まります。

見積書作成は、きれいな書類を出す仕事ではありません。

顧客に提示する条件を決め、社内で確認し、合意後に受注・請求へ渡せる状態を作る仕事です。