kintone帳票出力の設計方法｜見積書・請求書・報告書を壊さないデータ構成

kintoneで帳票出力をしたい相談では、最初にプラグイン比較になりやすいです。

見積書をPDFにしたい。

請求書を一括で出したい。

納品書、作業報告書、点検報告書、申請書を印刷したい。

Excelで使っていた帳票の見た目を再現したい。

顧客名、住所、明細、合計金額、印影、備考をきれいに配置したい。

たしかに、帳票出力プラグインは必要になることが多いです。

ただし、実務で崩れるのは「PDFが出せないこと」だけではありません。

本当に困るのは、次のような状態です。

• 出力元のkintoneレコードが、承認前なのか承認済みなのか分からない
• 帳票に出す項目と、社内管理だけに使う項目が混ざっている
• 明細の品目名、税区分、単価、数量が自由入力でばらつく
• 同じレコードから見積書、請求書、納品書を出しており、どの帳票が正式版か分からない
• PDFは出せるが、誰がいつ出力したかが残らない
• 出力後に元レコードを編集できてしまい、PDF控えとkintoneの数字がずれる
• ファイル名が手入力で、後から探せない
• 再発行、差し替え、取消のルールがない
• メール送付や電子契約、会計ソフト連携の境界が決まっていない
• Excel帳票の見た目だけを再現し、kintone側のデータ構造が崩れている

帳票出力は、画面をPDFにする作業ではありません。

業務データを、顧客・取引先・社内承認者へ渡せる正式な形に変換する処理です。

kintone帳票出力で最初に決めるべきなのは、どの帳票プラグインを使うかではなく、「どのレコード状態を正式な出力対象にするか」です。

この記事では、kintoneで帳票出力を崩れにくい業務システムとして設計する方法を整理します。

kintone見積書作成の設計方法はこちら
kintone請求書管理の設計方法はこちら
kintone日報の設計方法はこちら

先に結論：帳票出力はプラグイン選定の前にデータ設計を決める

kintoneで帳票出力をする方法はいくつかあります。

標準の印刷画面を使う。

帳票プラグインを使う。

PDF出力サービスを使う。

外部システムへデータを渡して帳票を作る。

どれを選ぶかは重要です。

ただし、選定の前に決めるべきことがあります。

それは、帳票の元になるデータをどこまでkintoneで正本にするかです。

分けるもの	1レコードの意味	役割
出力元レコード	見積、請求、報告、申請など1つの業務単位	帳票に出す主データを持つ
明細	1帳票の1行	品目、数量、単価、税区分、作業内容を持つ
マスタ	顧客、商品、担当者、税区分など	表記と計算のぶれを防ぐ
承認状態	作成中、確認中、承認済み、差し戻しなど	出力してよい状態かを判断する
帳票テンプレート	見積書、請求書、報告書などのレイアウト	出力形式と表示項目を決める
出力条件	権限、状態、帳票種別、版	誰が、いつ、何を出せるか制御する
PDF控え	出力済みの正式ファイル	顧客へ渡した内容を残す
出力履歴	1回の出力操作	実行者、日時、帳票種別、版を追う
送付履歴	1回のメール送付、再送、差し替え	顧客へ渡した事実を残す
外部連携	会計、電子契約、ストレージなど	帳票後の処理へつなぐ

帳票プラグインは、帳票を生成する道具です。

業務データの正本ではありません。

たとえば、見積書を出すなら、顧客、案件、見積ヘッダー、見積明細、商品マスタ、価格、承認状態が必要です。

請求書を出すなら、請求先、請求ヘッダー、請求明細、支払条件、請求番号、入金予定、会計連携が必要です。

作業報告書を出すなら、作業日、担当者、作業内容、写真、確認者、顧客サイン、報告状態が必要です。

これらを帳票レイアウト側だけで吸収しようとすると、kintoneのアプリ設計が弱くなります。

帳票出力の品質は、PDFレイアウトだけでは決まりません。元データ、明細、承認、保存、再発行のルールまで含めて決まります。

帳票プラグインを選ぶ前に決めること

帳票プラグインを選ぶ前に、まず出力業務を分解します。

確認項目	決めること
帳票の種類	見積書、請求書、納品書、報告書、申請書、ラベルなど
正本データ	kintone、会計ソフト、販売管理、別システムのどれか
出力単位	1レコード1帳票か、複数レコードをまとめるか
明細構造	テーブルで持つか、明細アプリを分けるか
テンプレート数	1アプリ1帳票か、複数帳票を出すか
出力タイミング	作成中でも出すか、承認後だけ出すか
出力権限	誰がどの帳票を出せるか
PDF保存先	kintone添付、Drive、Box、OneDrive、会計ソフトなど
ファイル名	顧客名、帳票名、日付、番号、版をどう入れるか
再発行	再出力、差し替え、取消、再送をどう扱うか
送付方法	メール、電子契約、郵送、手渡し、外部サービス
連携先	会計、電子契約、ストレージ、チャット通知など

この表が埋まらない状態でプラグインを比較すると、機能一覧だけを見て決めることになります。

機能一覧は大事です。

しかし、帳票業務で本当に効くのは、自社の出力ルールに合うかどうかです。

たとえば、月末に請求書を一括出力する会社と、案件ごとに承認後すぐ見積書を個別出力する会社では、必要な機能が違います。

業務	重視する機能
月末請求書の一括発行	一括出力、個別PDF、ファイル名自動設定、保存先設定
営業見積書の個別発行	承認状態による出力制御、複数レイアウト、版管理
作業報告書の提出	写真、署名、作業明細、顧客確認、控え保存
ラベル・宛名印刷	用紙サイズ、出力開始位置、レイアウト調整
申請書・契約書	承認済み状態、電子契約連携、差し替え履歴
大量帳票	一覧出力、分割出力、保存先容量、実行ログ

k-Reportでは、kintoneから自由なレイアウトの帳票出力、PDFテンプレート、大量出力、一覧・詳細画面からの出力、クラウドストレージ連携などが紹介されています。

k-Report：kintoneに高機能帳票機能を

PrintCreatorでは、レコード詳細画面からの個別PDF出力、一覧画面からの一括出力、複数レイアウト、レコードへのPDF自動保存、ファイル名設定、出力権限やレコード条件による制御が紹介されています。

PrintCreator：機能一覧

ペパコミの記事では、kintoneの標準印刷や複数の帳票系サービスを比較し、複数帳票、一括印刷、画像読み込み、レイアウト、サポート体制などの選定観点が整理されています。

ペパコミ：kintoneで帳票出力する方法

これらは帳票出力の実装手段として有力です。

ただし、どちらを選ぶ場合でも、先に出力対象のレコード構造を決める必要があります。

見積書・請求書・報告書で必要な元データ

帳票ごとに、必要な元データは違います。

同じ「PDF出力」でも、見積書、請求書、作業報告書、申請書では、正本にすべき項目が変わります。

帳票	主な元データ	注意点
見積書	顧客、案件、見積番号、明細、単価、値引、有効期限	承認前の金額を出さない
請求書	請求先、請求番号、請求日、支払期限、税区分、明細	請求確定後の編集を制限する
納品書	受注、出荷、納品日、納品先、納品明細	出荷実績とずれないようにする
作業報告書	作業日、担当者、作業内容、写真、確認者、顧客確認	写真や署名の扱いを決める
点検報告書	点検対象、点検項目、結果、異常、対応方針	点検項目のマスタ化が重要
申請書	申請者、申請内容、承認者、承認日、決裁番号	承認プロセスと帳票の版を合わせる
ラベル・宛名	顧客、住所、部署、担当者、配送先	表記ゆれと住所分割に注意する

帳票ごとにアプリを分けるか、1つのアプリから複数帳票を出すかも決めます。

設計	向いているケース	注意点
1アプリ1帳票	請求書、作業報告書など業務が明確	アプリ数が増える
1アプリ複数帳票	見積書と注文請書、請求書と納品書など	出力条件を分けないと誤出力しやすい
親アプリ＋明細アプリ	明細を集計・連携したい	関連レコードや連携処理が必要
外部システム正本	会計や販売管理が正式データ	kintoneは確認・補助に寄せる

たとえば、見積書と請求書を同じ案件アプリから出すことはできます。

しかし、見積金額と請求金額は同じとは限りません。

見積は提案条件です。

請求は確定した取引です。

この2つを同じフィールドで扱うと、差額や変更理由が追えません。

同じように、作業報告書と請求書も違います。

作業報告書は、実施内容の証跡です。

請求書は、金銭請求の正式書類です。

作業実績から請求へつなぐことはできますが、帳票としては別物です。

明細テーブルとマスタ参照の設計

帳票出力で最も崩れやすいのが、明細です。

見積明細、請求明細、納品明細、作業明細、点検項目。

帳票には行が並びます。

その行を、kintoneでどう持つかを決めます。

明細の持ち方	向いているケース	注意点
レコード内テーブル	明細が少なく、帳票内で完結する	明細単位の集計・承認・連携が弱い
明細アプリを分ける	明細単位で集計、請求、在庫、会計へつなぐ	アプリ間の紐づけが必要
商品マスタからルックアップ	商品名、単価、税区分を統一したい	価格改定時の扱いを決める
作業項目マスタから選択	点検項目や報告項目を標準化したい	現場の自由記述とのバランスが必要

kintoneのテーブルは便利です。

ただし、帳票の明細行をすべてテーブルに入れればよいわけではありません。

明細単位で次のような管理が必要なら、別アプリ化を検討します。

• 明細ごとに承認者が違う
• 明細ごとに売上計上月が違う
• 明細ごとに在庫や出荷とつながる
• 明細ごとに原価や粗利を見たい
• 明細ごとに会計ソフトへ連携する
• 明細ごとに作業実績や写真を持つ

逆に、1帳票内で完結する短い明細なら、テーブルでも十分です。

例	推奨
5行程度の見積明細	テーブルでもよい
月末請求の多数明細	明細アプリを検討
点検項目30個以上	点検項目マスタと結果明細を分ける
作業写真つき報告書	写真や作業履歴を分ける
納品明細と在庫連携	明細アプリを検討

帳票に出す項目と、社内管理項目も分けます。

種類	例
帳票に出す項目	顧客名、件名、明細名、数量、単価、金額、作業内容
社内管理項目	粗利、原価、承認コメント、社内メモ、連携エラー
両方に関係する項目	税区分、担当者、支払条件、納期、作業日

社内メモや原価が帳票に出てしまう事故は避ける必要があります。

そのため、テンプレート側だけではなく、kintoneアプリ側でも項目の意味を分けます。

出力タイミングと承認ステータス

帳票出力で一番大事なのは、いつ出力してよいかです。

作成中の見積書を顧客へ出してはいけません。

未承認の値引き見積を出してはいけません。

請求確定前の請求書を正式版として送ってはいけません。

作業報告書も、現場担当の入力直後と責任者確認後では意味が違います。

出力可否は、ステータスと権限で制御します。

状態	出力の扱い
作成中	原則、社内確認用だけ
申請中	正式出力は不可
差し戻し	正式出力は不可
承認済み	正式出力可
出力済み	再出力は履歴を残す
送付済み	差し替えには理由を必須にする
取消	出力不可、または取消版のみ

PrintCreatorでは、レコードの状態に応じた出力制御や、出力後にkintone内のレコードを編集する機能が紹介されています。

このような機能を使う場合でも、まず自社側のステータス設計が必要です。

帳票	出力してよい状態	出力してはいけない状態
見積書	承認済み、提出可	作成中、申請中、差し戻し
請求書	請求確定、発行可	締め前、金額確認中、取消
作業報告書	確認済み、提出可	作業中、確認待ち、差し戻し
申請書	承認済み、決裁済み	申請中、差し戻し
納品書	出荷確定、納品準備完了	出荷前、数量未確定

帳票出力は、ボタンを押せることより、押してよい状態を制御できることが重要です。

出力権限も分けます。

営業担当は見積書を出せるが、請求書は経理だけ。

現場担当は報告書の下書きPDFを出せるが、顧客提出版は責任者だけ。

管理者は再発行できるが、一般ユーザーはできない。

このようなルールを決めます。

権限	できること
作成者	下書き、社内確認用の出力
承認者	正式出力の許可、差し戻し
経理・管理	請求書、領収書、控え保存
現場責任者	報告書の提出版出力
管理者	再発行、取消、テンプレート変更

帳票プラグイン側の権限機能だけに任せず、業務プロセスとして誰が責任を持つかを決めることが重要です。

PDF保存先・ファイル名・再発行ルール

帳票は、出力した後の管理が重要です。

PDFをダウンロードして終わりにすると、あとで次の問題が起きます。

• どのPDFを顧客へ送ったか分からない
• 出力後にkintoneの元データを直してしまい、控えと数字がずれる
• ファイル名が人によって違い、検索できない
• 再発行と差し替えの区別がない
• 送付済みPDFの保存先が個人PCや個人Driveに散らばる
• 帳票テンプレートを変えた後、過去帳票の見た目が再現できない

PDF保存先は、運用によって決めます。

保存先	向いているケース	注意点
kintone添付ファイル	レコードと控えを一緒に見たい	容量、アクセス権、再保存ルール
Google Drive等	大量PDFや社外共有が多い	フォルダ権限、共有URL、命名規則
Box・OneDrive等	組織の文書管理に乗せたい	保存先ルールとkintoneへのURL戻し
会計ソフト	請求書など会計が正本の場合	kintone側は控えや連携ログに寄せる
電子契約サービス	契約書、申込書、同意書	締結済みPDFとkintone状態の同期

k-Reportでは、PDF出力時にクラウドストレージへ同時に出力し、共有URLをkintoneフィールドへ戻す機能が紹介されています。

PrintCreatorでも、レコード内の添付ファイルフィールドへPDFを保存する機能や、出力先とファイル名の初期設定、レコード内データを使ったファイル名設定が紹介されています。

こうした機能を使う場合、先に命名規則を決めます。

帳票	ファイル名例
見積書	見積書_見積番号_顧客名_v02_20260609.pdf
請求書	請求書_請求番号_請求先_202606.pdf
作業報告書	作業報告書_案件番号_作業日_担当者.pdf
申請書	申請書_申請番号_申請者_承認日.pdf
納品書	納品書_納品番号_納品先_納品日.pdf

ファイル名には、最低限、帳票種別、管理番号、相手先、日付、版を入れます。

日本語ファイル名を使うか、半角英数字に寄せるかも決めます。

外部システム連携や大量処理がある場合は、半角英数字の管理番号を入れた方が安定します。

再発行ルールも必要です。

操作	意味	必要な記録
再出力	同じ内容をもう一度出す	出力日時、実行者
再発行	正式に再発行する	再発行理由、版、旧版との関係
差し替え	内容を修正して出し直す	修正内容、承認者、送付先
取消	発行済み帳票を無効にする	取消理由、取消日、通知先
控え保存	顧客へ出したPDFを保存する	保存先、ファイル名、版

帳票出力後に元データを編集できる運用では、PDF控え、出力版、変更履歴を分けないと、何が正式だったのか分からなくなります。

一括出力と個別出力の使い分け

帳票出力には、個別出力と一括出力があります。

どちらがよいかは、業務で決まります。

出力方法	向いている業務
個別出力	見積書、作業報告書、申請書、契約書
一括出力	月末請求、宛名ラベル、納品書、点検予定表
自動出力	定期請求、承認後の控え作成、ステータス更新時のPDF保存
プレビュー出力	社内確認、レイアウト確認、下書き

PrintCreatorでは、レコード詳細画面からの個別PDF出力と、一覧画面からの一括出力が紹介されています。

k-Reportでも、一覧画面の絞り込み条件に応じた一括印刷、一覧印刷、詳細画面での個別印刷が紹介されています。

個別出力は、1件ずつ内容を確認しながら出せます。

見積書や作業報告書のように、顧客ごとに内容確認が必要な帳票に向いています。

一括出力は、件数が多い業務に向いています。

月末の請求書、宛名ラベル、納品書、点検予定表などです。

ただし、一括出力には事故もあります。

事故	対策
未承認レコードまで出力する	出力対象一覧を承認済みだけにする
対象月が違う請求書を混ぜる	締め月、請求日、状態で絞り込む
ファイル名が重複する	管理番号と日付、版を入れる
一括PDFの中身を後から探せない	個別PDF保存も検討する
出力途中のエラーが分からない	出力ログと再実行対象を残す
出力後の状態更新が漏れる	出力後ステータス更新を設計する

一括出力では、出力前の一覧が重要です。

「今から出す対象が正しいか」を確認できる一覧を作ります。

たとえば、請求書なら次のような一覧です。

一覧	条件
今月発行対象	請求月が今月、状態が請求確定
未出力	請求確定、PDF未作成
出力済み未送付	PDF作成済み、送付日空欄
送付済み	送付日あり、送付先あり
差し替え対象	差し替え理由あり、再承認済み

帳票出力ボタンだけではなく、出力前後の一覧を作ることが大事です。

メール送付・電子契約・会計連携との境界

帳票出力は、出して終わりではありません。

多くの場合、その後に送付、契約、会計、保管が続きます。

帳票	出力後の処理
見積書	メール送付、顧客確認、受注化
請求書	メール送付、入金予定、会計連携、消込
作業報告書	顧客確認、社内確認、請求根拠化
契約書・申込書	電子契約、締結済みPDF保存、契約管理
納品書	出荷・納品実績、受領確認

ここで、kintoneだけで全部やるかどうかを決めます。

メール送付は、kintone連携サービスを使う場合もあります。

電子契約は、電子契約サービスを正本にした方がよい場合があります。

請求書や会計処理は、会計ソフトを正本にした方がよい場合があります。

重要なのは、帳票PDFそのものをどこで正式管理するかです。

領域	kintoneに向くこと	外部サービスに任せやすいこと
メール送付	送付対象、送付状態、履歴管理	大量配信、到達確認、テンプレート送信
電子契約	契約前の申請、顧客・案件との紐づけ	署名、締結、証跡、締結済み原本
会計連携	請求前確認、連携ログ、エラー確認	正式請求、仕訳、入金消込
ストレージ	保存URL、社内参照、控え管理	大量PDF保管、共有権限、文書管理
チャット通知	出力完了、送付漏れ、承認依頼	会話、個別確認、例外対応

帳票出力の設計では、「PDFを作る場所」と「正式に保管する場所」を分けます。

kintoneでPDFを作る。

PDFをDriveやBoxへ保存する。

保存URLをkintoneへ戻す。

送付履歴をkintoneに残す。

請求書の正式データは会計ソフトに連携する。

契約書の締結済み原本は電子契約サービスで管理する。

このように、役割を分けると運用が安定します。

よくある失敗パターン

kintone帳票出力でよくある失敗を整理します。

1. Excel帳票をそのまま再現しようとする

既存のExcel帳票を再現すること自体は悪くありません。

ただし、Excelでは見た目と計算と入力欄が同じシートに混ざっていることがあります。

kintoneでは、元データ、明細、マスタ、帳票テンプレートを分けます。

見た目を先に作ると、データ構造が帳票に引っ張られます。

2. 承認前の帳票を正式版として出せてしまう

出力ボタンがいつでも押せると、未承認の見積書や請求書が出てしまいます。

ステータス、権限、帳票種別で出力条件を分けます。

3. PDF控えを残さない

出力したPDFを手元に保存して終わると、後から顧客へ何を送ったか分かりません。

出力履歴とPDF保存先を決めます。

4. 出力後に元データを自由に編集できる

PDF出力後に金額や明細を変えられると、控えとkintoneの数字がずれます。

出力後は編集制限、差し替え申請、再承認などのルールを入れます。

5. ファイル名が人によって違う

見積.pdf、A社見積最新.pdf、最終版2.pdf のような名前では、あとで探せません。

帳票種別、管理番号、相手先、日付、版を入れた命名規則を作ります。

6. 一括出力の対象確認が弱い

一括出力は便利ですが、対象を間違えると影響が大きいです。

出力前に確認用一覧を作り、承認済み、対象月、未出力などで絞ります。

7. 帳票テンプレートの変更履歴がない

テンプレートを変えた後、過去に出した帳票を同じ見た目で再出力できないことがあります。

テンプレートの版、適用開始日、変更理由を残します。

8. 会計や契約の正本が曖昧になる

請求書や契約書は、kintoneだけで完結しないことがあります。

会計ソフト、電子契約サービス、文書管理システムのどこを正式な保存先にするかを決めます。

まず決める設計チェックリスト

kintoneで帳票出力を導入する前に、最低限次の項目を決めます。

確認項目	決めること
帳票種別	何を出すか。見積書、請求書、報告書、申請書など
出力元	どのアプリ、どのレコードを正本にするか
明細	テーブルか、明細アプリか
マスタ	顧客、商品、税区分、担当者を参照するか
承認	どの状態から正式出力できるか
権限	誰が、どの帳票を出せるか
テンプレート	帳票レイアウト、版、適用開始日
出力方法	個別、一括、自動、プレビュー
PDF保存	添付、Drive、Box、会計、電子契約など
ファイル名	帳票種別、番号、相手先、日付、版
出力履歴	日時、実行者、帳票種別、版、保存先
再発行	再出力、差し替え、取消の扱い
送付履歴	送付先、送付日、再送、差し替え
外部連携	会計、電子契約、メール、ストレージ
編集制限	出力後に元データをどう守るか

この表が埋まっていれば、帳票プラグインの選定はかなり楽になります。

自由レイアウトが必要なのか。

一括出力が必要なのか。

PDFの自動保存が必要なのか。

出力条件や権限管理が必要なのか。

複数レイアウトが必要なのか。

クラウドストレージ連携が必要なのか。

判断軸が機能名ではなく、業務ルールになります。

Bitlightに相談できること

Bitlightでは、kintoneの帳票出力を、プラグイン設定ではなく業務設計として整理できます。

たとえば、次のような支援ができます。

• 見積書、請求書、報告書、申請書の出力元アプリ設計
• ヘッダー、明細、マスタ、承認、出力履歴の分離
• 帳票に出す項目と社内管理項目の整理
• 明細テーブルと明細アプリの使い分け
• 承認済みだけを正式出力するステータス設計
• 帳票テンプレートの版管理、適用開始日の整理
• PDF保存先、ファイル名、出力履歴、再発行ルールの設計
• 個別出力、一括出力、自動出力の使い分け
• メール送付、電子契約、会計ソフト、ストレージ連携の境界整理
• 既存Excel帳票をkintone向けのデータ構造に分解する支援

帳票出力は、入れるだけなら早いです。

しかし、見積書、請求書、報告書のように社外へ渡す書類では、出力後の管理まで決めないと危険です。

PDFの見た目を整える。

承認済みデータだけを出す。

出したPDFを保存する。

誰がいつ出したかを残す。

送付済み、再発行、差し替えを追えるようにする。

外部サービスの正本と矛盾しないようにする。

この順番で設計すると、kintoneの帳票出力は単なる印刷機能ではなく、業務データを正式な書類へ変換する仕組みになります。

kintone帳票出力は、帳票をきれいに作るためではなく、承認済みの業務データを正しい版・保存先・送付履歴つきで扱うために設計します。