帳票出力機能の開発｜PDF・CSV出力の要件

01はじめに｜この記事でわかること

要点：請求書や納品書をシステムから出したい方に向けた解説です。帳票出力の要件で決めること、PDFとCSVそれぞれの注意点、費用と期間の目安、発注前の準備までを順に並べています。

「請求書はシステムから出せますよね」。打ち合わせの後半で、この一言が出てきます。答えは出せます。ただ、そこから確認したいことが一気に増えます。

帳票は最後に回されがちです。画面の話は盛り上がるのに、帳票は「今の書式と同じで」で終わる。ところが作り始めると、今の書式が1種類ではなかった、取引先ごとに違った、という話が出てきます。

この記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、Webシステム開発のご相談で帳票をどう詰めているかをご説明します。先に決めておくほど後が楽になります。

紙の帳票を電子で残す話も避けて通れません。まずは制度側の考え方を動画で押さえます。

02帳票出力機能とは｜画面表示との違い

要点：帳票出力は、システムの中のデータを決まった書式のファイルとして外に出す機能です。画面は見て操作するもの、帳票は渡して残すもの。この違いが、そのまま開発の難しさの差になります。

画面は幅に合わせて伸び縮みし、多少ずれても読めれば困りません。帳票は逆です。A4に収まること、毎回同じ位置に同じ項目が来ることが求められます。渡す相手も社外です。金額の桁が1つずれた請求書を送れば、その日のうちに電話が鳴ります。

• 画面は可変、帳票は固定。用紙サイズと余白が先に決まり、その中に収める設計になります。
• 画面は1件ずつ、帳票はまとめて。月末に300件を一括出力する要件が普通に出てきます。
• 画面は直せる、帳票は残る。発行済みの書類は差し替えが効かず、再発行の扱いを決めておく必要があります。

この「渡して残す」性質があるので、帳票は要件定義の進め方の中でも早めに手をつける領域です。画面の使い勝手は後から調整できますが、帳票の書式は後から変えると影響範囲が広がります。

03出力形式の選び方｜PDF・CSV・Excel・印刷

要点：形式は用途で決まります。社外に渡して書式を保つならPDF、他システムに取り込むならCSV、受け取った側が加工するならExcel。同じ帳票に2つの形式が必要なこともあります。

ここを最初に決めておくと、後の作業がぶれません。逆に「とりあえず全形式」と言われると、テストの手間が3倍になります。

迷ったときの基準はひとつです。相手が書式のまま見るならPDF、相手がデータとして使うならCSV。Excelは便利ですが、渡した先で数字を書き換えられる余地が残ります。金額を扱う帳票では、そこを許すかどうかを先に決めてください。

04要件定義で決めておきたい10項目

要点：帳票1本ごとに、用途、出力形式、用紙、項目、明細の最大行数、改ページの扱い、合計の出し方、採番、再発行、権限の10項目を決めます。ここが埋まっていれば見積りの精度も上がります。

ご相談で毎回うかがっている内容です。順番に埋めるだけで、認識のずれがかなり減ります。

1. 用途と提出先。社内の確認用か、取引先に渡すのか、税務で残すのか。
2. 出力形式。PDF、CSV、Excel、直接印刷のどれか。複数なら優先順位も。
3. 用紙と向き。A4縦、A4横、専用用紙。余白と印刷範囲もここで決めます。
4. 記載する項目。ヘッダー、明細、フッターに何を出すか。項目名の表記も統一します。
5. 明細の最大行数。1ページに何行入るか。改ページの前提になります。
6. 改ページと繰越。2ページ目以降にヘッダーを繰り返すか、小計を繰り越すか。
7. 合計と端数処理。消費税の計算単位、切り捨てか四捨五入か、税率ごとの内訳。
8. 採番のルール。請求書番号の形式、年度でリセットするか、欠番を許すか。
9. 再発行の扱い。再発行と分かる印字を入れるか、履歴を残すか。
10. 出力できる人。誰が出せて、誰が見られるか。権限の設計とつながります。

特に5と6は見落とされがちです。「明細は多くて10行」と聞いていたのに、実際は50行の案件があった。そのたびに改ページの作り直しが発生します。過去1年分の実績から最大件数を調べておくと確実です。

05ご相談で挙がる帳票の種類と出力形式

要点：実際のご相談で最も多いのは請求書関連で、全体のおよそ3割を占めます。次いで納品書・受領書、在庫や売上の一覧表と続きます。上位3種類でおよそ7割です。

請求書と納品書で半分を超えます。どちらも社外に渡る書類で、書式のずれが許されません。一方、在庫や売上の一覧表はCSVが中心です。在庫管理システムの開発や販売管理システムの機能を検討する場面では、帳票の話がほぼ必ず出てきます。

06PDF出力の要件｜レイアウトと改ページ

要点：PDFで手間がかかるのは、見た目そのものより改ページとフォントです。明細が1ページに収まらないときの動き、ページ番号の表記、合計をどこに出すか。この3つを決めておくと作業が安定します。

PDFは「紙の再現」を求められます。だからこそ、紙のときに人が手で調整していた部分が課題になります。明細が45行のとき、担当者が余白を詰めて1枚に収めていた。よくある話です。

• 改ページの条件。何行で次ページに送るか、明細が1行だけあふれたときにどうするか。
• ヘッダーの繰り返し。2ページ目以降に宛名やタイトルを再表示するかどうか。
• 小計の繰越。ページごとに小計を出し、次ページに繰り越して表示するか。
• ページ番号。「1/3」の形式にするか、総ページ数を出さないか。
• フォントの埋め込み。環境によって字形が変わらないよう、使うフォントを含めます。
• ロゴと印影。画像の解像度と配置位置。印影は運用ルールもあわせて決めます。
• 外字の扱い。取引先名の環境依存文字は、置き換えるか代替表記にするかを先に決めます。

PDF帳票でもめる原因は、デザインではなく「あふれたとき」の決めごとです。

印刷イメージを先に紙で確認する方法も有効です。ワイヤーフレームの作り方と同じ考え方で、1枚描いて関係者に見せると、認識のずれがその場で見つかります。

07CSV出力の要件｜文字コードと桁落ち

要点：CSVでのつまずきは、ほぼ文字コードと数値の扱いに集約されます。Excelで開く前提ならBOM付きUTF-8かShift_JIS、システム連携ならUTF-8。先頭のゼロと長い桁の数値は文字列として出す指定が必要です。

CSVは単純に見えて、渡した先で崩れます。実務でよく起きるのは次のような症状です。

取り込み先が決まっているなら、その仕様書をもらうのが確実です。会計ソフトや基幹システムには受け入れ形式の定義があります。想像で作るより、先方の定義に合わせるほうが手直しがありません。基幹システムの刷新を並行して検討中なら、どちらに合わせるかも早めに決めてください。

08手直しが起きた原因と追加工数

要点：帳票の作り直しで最も多い原因は、後から出てきた別書式です。次いで明細行数の想定違い、税計算の解釈違いと続きます。いずれも要件定義の段階で防げるものばかりです。

1位の「別書式が後から判明」は、追加工数も最大です。原因は明快で、現場が個別に作ったExcelが共有されていないからです。経理と営業で違う請求書を使っていた例もありました。

防ぎ方は単純です。関係部署に「今使っている様式を全部見せてください」と依頼する。これだけで、開発が始まる前に本数が確定します。

09法令対応｜電子帳簿保存法とインボイス

要点：帳票をデータでやり取りするなら、電子帳簿保存法の電子取引の保存要件を満たす必要があります。請求書には、適格請求書として求められる記載事項もそろえます。どちらも設計段階で織り込むものです。

メールやシステムで請求書のデータをやり取りする行為は「電子取引」にあたります。国税庁の電子帳簿保存法一問一答（電子取引関係）に、データを電子のまま保存することや満たすべき要件が示されています。制度の全体像は電子帳簿等保存制度特設サイトにまとまっています。

システム側で用意するのは、おおむね次の3点です。

• 検索できること。取引年月日、取引金額、取引先で探せる仕組みを持たせます。
• すぐ見られること。画面と書面で確認でき、システムの説明資料も備えます。
• あとから変えられないこと。訂正や削除の記録が残る作り、または事務処理規程で担保します。

請求書については、国税庁のインボイス制度の解説で示された記載事項を、帳票の項目としてそのまま持たせます。発行者の名称と登録番号、取引年月日、取引内容、税率ごとに区分した対価の額と適用税率、税率ごとの消費税額、交付先の名称。この6つが漏れると受け取った側が困ります。

なお、税務や会計の判断は税理士など専門家の領域です。ZenWeb Japanは、決まった要件をシステムに落とし込む部分を担当します。保管方法とあわせてWebシステムのセキュリティ対策も同時に検討してください。

10作り方の3つの選択肢と選び分け

要点：帳票の作り方は、システムに直接組み込む、PDF生成ライブラリを使う、帳票ツールを導入するの3つです。本数が少なければ組み込み、20本を超えるなら専用ツールが有利になります。

どれが正解というより、本数と今後の増え方で決まります。

• システムに直接組み込む。帳票が数本で、書式が当分変わらない場合に向きます。初期費用を抑えられます。
• PDF生成ライブラリを使う。10本前後の中規模に向きます。細かい表現が効き、ライセンス費用がかからない選択肢もあります。
• 帳票ツールを導入する。本数が多く、書式変更が頻繁な場合に向きます。担当者がレイアウトを直せる製品もあります。

判断で効くのは「誰が書式を直すか」です。開発会社に毎回依頼する前提なら、組み込みでも困りません。社内の担当者が直したいなら、その操作ができるツールを選ぶ価値があります。判断に迷う構図はRPAとシステム開発の違いと似ていて、目先の費用より運用の形で決まります。

11帳票の本数別 費用と期間の目安

要点：帳票の開発費は本数にほぼ比例します。3本までなら30〜60万円で2〜4週間、10本規模で100〜200万円、20本を超えると帳票ツールの費用を含めた比較が必要になります。

1本あたりの単価は、本数が増えるほど下がります。同じ土台を使い回せるからです。逆に特殊な書式が1本混ざると、それだけで数十万円かかることもあります。専用用紙や取引先指定のレイアウトがこれにあたります。

見積書を受け取ったら、帳票が何本分として計算されているかを確認してください。システム開発の見積もりの見方のとおり、人月の合計だけでは中身が読み取れません。

12Excel・紙からの移行で気をつけること

要点：既存のExcel帳票をそのまま再現しようとすると高くつきます。手作業で調整していた部分を洗い出し、残す項目と捨てる項目を分けてから移行してください。

長年使ってきたExcelには、その場しのぎの工夫が積み重なっています。セルを結合して見た目を整えた、備考欄に手入力で条件を書いた、印刷時だけ列幅を変えていた。システム化するときは一度分解が必要です。

1. 現物を全部集める。部署ごとのファイルを実物で回収します。名前が同じでも中身は違います。
2. 共通と個別に分ける。8割の帳票で共通する項目と、一部でしか使わない項目を仕分けます。
3. 手作業の箇所に印をつける。毎回人が書き換えている欄が、そのまま要件になります。
4. 残す項目を決める。「昔から入っているが誰も見ていない欄」は、この機会に落とします。

4で迷ったら、直近1年で誰かがその欄を参照したかを聞いてください。答えが出ない項目は、たいてい不要です。項目を減らすほどレイアウトが素直になり、メンテナンスも軽くなります。業務システムのUI改善と同じで、削る判断が効いてきます。

13テストで必ず確認する項目

要点：帳票のテストは、正常な1件だけでは足りません。明細が0件、1件、ページをまたぐ件数、長い取引先名、値引きやマイナス金額。この5つを通せば、大きな不具合はほぼ見つかります。

確認していただきたいのは、次のような境目のデータです。

• 明細が0件のとき。金額ゼロの請求書を出す運用があるかも含めて確認します。
• ちょうど1ページに収まる件数と、1件だけ超える件数。改ページの境目が一番崩れます。
• 取引先名や品名が長いとき。折り返すか、省略するか、はみ出すか。
• マイナス金額と値引き行。合計の計算と表示位置がずれやすい箇所です。
• 複数税率が混ざるとき。税率ごとの内訳が正しく分かれるかを確認します。

あわせて、実際に印刷して現物を見てください。画面上のPDFでは気づかない余白のずれが、紙にすると分かります。専用用紙は必ず本番の用紙でテストしてください。

14稼働後3年の帳票の増え方

要点：帳票は稼働後も増えます。当社の実績では、10本で始めたシステムが3年後には平均15本前後になっています。増えるのを前提に、追加しやすい作りにしておくかどうかでメンテナンス費が変わります。

増え方は1年目が最も大きく、その後は落ち着きます。使い始めてから「この一覧も出したい」という要望が出るためです。改修も同じ傾向で、法令や取引先の都合による変更が中心です。

だから設計時に決めておきたいのが、追加の手順です。1本増やすのに毎回ゼロから作るのか、土台を共通化して差分だけ作るのか。ここでメンテナンス費が変わります。契約範囲の考え方はシステム保守・運用費用の相場をご覧ください。

15まとめ｜今日からできる3ステップ

要点：帳票のシステム開発は、本数・形式・明細行数・法令の記載事項を先に固めるほど安く終わります。まずは今お使いの様式を全部集めるところから始めてください。

帳票は地味な機能に見えますが、社外に渡って残るものだけに、やり直しの影響が大きい部分です。着手前の準備が、そのまま費用と期間に返ってきます。

今日からできる3ステップ

1. 様式を全部集める。関係部署に依頼し、いま使っている帳票を現物で回収します。
2. 件数と最大行数を調べる。帳票ごとの月間発行件数と、過去1年の明細の最大行数をメモします。
3. 形式と担当を決める。帳票ごとにPDFかCSVかを決め、稼働後に書式を直す担当も決めておきます。

この3つがそろえば、初回の打ち合わせで「帳票は8本、うち2本が特殊」といった整理まで進められます。画面の設計から一緒に考えたい場合は要件定義の進め方を、依頼先を比べたい場合はWebシステム開発のページをあわせてご覧ください。

16よくある質問

要点：帳票出力機能の開発について、よくいただく質問です。既存システムへの追加、専用用紙、一括出力、書式変更の依頼方法の4点が中心です。

1. 今あるシステムに帳票出力だけを追加できますか

追加できます。既存システムのデータベース構成と使われている技術が分かれば見積りできます。帳票に出す項目がデータとして持たれていない場合のみ、その項目を追加する作業が必要になります。

2. 取引先から指定された専用用紙にも印刷できますか

対応できます。用紙の実物と印字位置の指定資料をご用意ください。専用用紙は位置の精度が求められるため、本番の用紙とプリンタでテストします。汎用の帳票より工数がかかる点はご了承ください。

3. 月末に数百件をまとめて出力することはできますか

できます。件数が多い場合は、画面で待たせずに裏で処理し、完了したら通知する作りにします。1つのPDFにまとめるか、1件ずつ分けるかも選べます。

4. 稼働後に書式を変更したいときはどうすればいいですか

メンテナンス契約の範囲として対応します。項目の追加や配置の変更なら、通常は数日で反映できます。社内で直したい場合は、担当者がレイアウトを編集できる帳票ツールを選んでおく方法もあります。

5. 帳票だけを先に作って、システム本体は後からでも大丈夫ですか

可能ですが、おすすめはしません。帳票に出す項目は本体のデータ構造で決まるため、後から本体を作ると帳票側の修正が発生します。同時に設計し、開発の順番だけ帳票を先にする進め方が確実です。