前回の記事（見積書 3 案から実用版へ）では、Claude Code に見積書を 3 案作らせ、評価をもとに実用版へ仕上げました。今回はその続編です。
今回の目的は、Claude Code を前提に作った帳票作成のしくみで、Codex も帳票を作れるかを試すことです。これまで用意した帳票仕様・レシピ・設定ファイルの検査とプレビュー用のコマンドを使い、同じアプリのレコードから請求書を作らせました。
本記事で使った Codex は、VS Code の Codex 拡張機能です。ChatGPT Business の契約で利用し、モデルは GPT-6.1 Sol、推論設定は「中（medium）」にしました。
結果として、今回の環境では、Codex でも請求書の設定 JSON を作成し、検査と HTML プレビューの出力まで進められました。設定・計算式のエラーは 0、HTML 生成関数についての警告は 1 件でした。その後、印刷屋プラグインで PDF を生成し、明細 4 行と金額・振込先・備考が 1 ページに収まることも確認しました。
最初は既存の見積書を土台にした形になったので、続けて「既存の見積書は参考にせずに、あらためて請求書をデザインして」と依頼しました。この記事では、その 2 回のやり取りと確認結果を紹介します。
印刷屋プラグインで生成した PDF の比較（左：最初の請求書、右：請求書としてあらためてデザインした版）
最初の版は、見積書を引き継いだ枠と表を中心とした形です。再デザイン版は、請求金額を横長の帯で大きく見せ、明細の下に振込先と税額内訳を並べています。発行元や振込先などの「要設定」は、試作のため残しています。
帳票作成用のテンプレート、kintone への接続、印刷屋プラグインの zip については、最初の記事を参照してください。ただし、そちらの接続・権限設定は Claude Code 用です。本記事は、Codex から同じ作業フォルダーの資料とオーサリング用コマンドを使える環境で行った作成例で、Codex の初期設定手順は扱いません。
使ったアプリ
前回と同じ、ゲストスペース 15 の見積書アプリ（アプリ番号 3443）、レコード 5 を使いました。今回は、アプリに 請求番号・請求日・請求書ファイルの項目も用意されています。
| 帳票に使う内容 | フィールドコード | 種類 |
|---|---|---|
| ご請求先 | 宛名 | 文字列（1 行） |
| 請求書の番号 | 請求番号 | 文字列（1 行） |
| 請求日 | 請求日 | 日付 |
| 担当者 | 担当者 | ユーザー選択 |
| 請求する商品の明細 | 見積明細 | テーブル（型番・商品名・単価・数量・金額） |
| 税抜小計 | 小計金額 | 計算 |
| 消費税 | 消費税 | 計算 |
| 税込合計 | 合計金額 | 計算 |
| 備考 | 備考 | 文字列（複数行） |
| PDF の保存先 | 請求書ファイル | 添付ファイル |
テーブルのフィールドコードは「見積明細」のままですが、その内容を請求書にも使います。金額もレコードにある小計・消費税・合計を表示する形です。
例のレコードは明細 4 行で、備考は 2 行です。請求番号と請求日には値があり、請求書ファイルは空でした。既存の見積書ファイルとは、保存先を分けています。
発行元の会社名・住所・電話番号・登録番号、振込先、支払期限に対応する項目は、今回のアプリにはありません。これらは帳票に **「要設定」**の欄として用意されました。
今回使ったレコード（請求番号・請求日・請求書ファイルの項目を用意）
1 通目: レコードの URL と、これまでの記事を渡す
最初は、レコードの URL と作り方の参考記事を添えて頼みました。
https://（kintone のドメイン）/k/guest/15/3443/show#record=5
のレコードから印刷屋プラグインの請求書の設定ファイルを作成して
作成方法は下記を参照
・AI(Claude Code)に帳票を作らせる
・AI(Claude Code)に帳票を作らせる（時計カタログ編）
・AI(Claude Code)に帳票を作らせる（見積書 3 案から実用版へ）
実際の依頼には、各記事へのリンクも付けています。
Codex は、作業フォルダーの資料と既存の設定を調べ、kintone から項目定義とレコードを取得しました。参考記事の公開ページは取得できなかったため、ローカルにあった記事原稿を読んでいます。
途中では、請求専用の項目がないとして、請求日に作成日を使う案を説明してきました。しかし、最新の項目定義を取得すると「請求番号」「請求日」「請求書ファイル」が見つかり、説明を訂正しました。最終的には、専用の項目を使う設定になっています。
AI が最初に説明した項目の有無も、実アプリと照らし合わせます。 今回は、最新の定義を読み直して修正されました。
最初の請求書
最初にできたのは、前回の実用版の見積書を土台にした請求書です。見出しと項目を請求書に合わせ、振込先と支払期限の欄を足していました。
印刷屋プラグインで生成した PDF の比較（左：前回の実用版の見積書、右：最初に作った請求書）
中央の見出し、金額の枠、右上の番号・日付の表などに、見積書の形が残っています。一方、請求書には空き行を足していないため、明細 4 行の下に備考・合計・振込先が続きます。
設定の検査はエラー 0。レコード 5 から HTML プレビューを書き出し、明細や金額の一致も確認されました。
ただ、今回ほしかったのは、見積書の形を引き継ぐ請求書ではなく、請求書として新しく考えたデザインです。そこで、続けて方向を伝えました。
2 通目: 「あらためて請求書をデザインして」
既存の見積書は参考にせずに、あらためて請求書をデザインして
色や配置を細かく指定したわけではありません。「何を土台にするか」を変える依頼です。
Codex は、請求書の本文と CSS を書き直しました。返答では、新しい方向を次のように説明しています。
白地に深い青緑のアクセントを使い、上部に請求番号・請求日、中央に大きな請求金額、下部に振込先と税額内訳を置く構成にしました。
請求番号・請求日・明細などのデータの対応はそのまま使い、見せ方を作り直しています。
新しい請求書の構成
| 場所 | 配置と見せ方 |
|---|---|
| 上部 | 左に小さな「INVOICE」と大きな「請求書」。右に請求番号と請求日 |
| 宛先と発行元 | 左にご請求先、右に発行元。宛名の敬称は「様」 |
| 請求金額 | 薄い青緑の帯に、税込金額を大きく表示。右に支払期限 |
| 明細 | No.・型番・商品名・数量・単価・金額。縦罫線を使わず、横罫線で区切る |
| 明細の下 | 左に振込先、右に税抜小計・消費税（10%）・税込合計 |
| 下部 | 備考。ページの末尾に請求番号とページ番号 |
見積書の実用版にあった、15 行にそろえる空き行は入れていません。今回のレコードでは、登録されている 4 行だけを出します。
単価・金額には YEN() を使い、「¥」付きの桁区切りで表示します。数量・単価・金額は右寄せ。商品名の列は残りの幅を使い、長い文字は折り返す設定です。
冒頭の比較画像の右側が、再デザイン版の PDF です。長い商品名は 2 行に折り返し、明細 4 行・税額内訳・振込先・備考まで、下に余白を残して表示されています。白黒印刷の結果や、別のレコードでの収まりは、別途確認します。
VS Code 内で、生成された HTML プレビューを開いた画面
左側に設定ファイル APP3443-見積書-請求書.json、右側に out/請求書.html のプレビューが見えます。この画像は HTML プレビューで、PDF の表示画面とは別です。
できあがった設定
設定ファイルは、最初に作ったものと同じ名前で更新されました。
settings/APP3443-見積書-請求書.json
| 設定 | 内容 |
|---|---|
| ボタン名 | 請求書 |
| 表示する画面 | 詳細画面 |
| 用紙 | A4 縦、96 dpi、1 ページの構成 |
| ボタンを表示する条件 | 請求番号と請求日が入力され、明細が 12 行以下 |
| PDF のファイル名 | 請求書-<請求番号>.pdf |
| 保存先 | 請求書ファイル |
| ボタンを押したとき | 確認後に PDF を作る設定 |
| 再発行 | PDF がすでにあっても、表示条件を満たせばボタンを出す |
12 行という制限は、はみ出しを確実に防ぐものではありません。 商品名や備考が長ければ、12 行以下でもページの下が切れる可能性があります。また、今回は例の 4 行で確認しており、12 行の収まりは未確認です。行数の上限は Codex が設定したもので、こちらから指定した条件ではありません。
前回の見積書は 15 行まで、今回の請求書は 12 行までです。12 行は Codex が最初の版で設定した上限で、再デザイン後の収まりを実測して決めたものではありません。
発行元・登録番号・振込先・支払期限は「要設定」のままです。請求書として使う前に、正しい内容を伝えて入れ替えます。
発行元は〇〇株式会社、住所は……、電話番号は……。
登録番号は……。
振込先は〇〇銀行〇〇支店、普通……、口座名義は……。
お支払期限は……。
請求書の「要設定」をこの内容に差し替えて。
上は追加依頼の例です。今回のやり取りでは、実情報への差し替えまでは行っていません。支払期限が請求ごとに変わるなら、アプリに項目を用意して、その値を帳票に出すよう依頼する方法もあります。
Codex が確かめたこと
Codex は、印刷屋プラグインの zip に含まれるコードを使うオーサリング用コマンドで、設定の検査と HTML プレビューの出力を行いました。
| 確かめたこと | 結果 |
|---|---|
| 設定ファイルの検査 | エラー 0、警告 1 |
| HTML プレビューの計算式 | エラー 0 |
| ページ要素の数 | 1 ページ |
| 明細 | 4 行。型番・商品名・数量・単価・金額がレコードと一致 |
| 請求番号 | レコードと一致 |
| 請求金額と税額内訳 | 合計金額・小計金額・消費税がレコードと一致 |
| ページ番号 |
1 / 1 に置き換わった |
| HTML の差し込み | 未置換の式や明細の目印は残っていない |
最初の版では、請求日・宛名・備考の改行も確認しています。デザインし直した後は、上の表の内容を確認しました。
警告 1 件は、FVAL と TABLE_HTML が生成した内容を HTML に入れることについてです。意図した使い方なので警告を隠さず残しています。型番と商品名には ESC_HTML() を使い、文字として表に入れる形にしました。
プレビューは out/請求書.html に出力されます。手元の Chrome で開いて見た目を確認できます。ただし、今回は Codex がブラウザーで描画した画面を見て評価したわけではなく、生成された HTML の内容を確認した結果です。
また、「ページ要素が 1 個」と「文字や表が 1 ページに収まる」は別の確認です。今回の明細 4 行の収まりは、HTML のページ数だけでなく、印刷屋で生成した PDF でも確認しました。
印刷屋で生成した PDF で確認できたことと、残る確認
最初の版と再デザイン版の両方を印刷屋で PDF にし、明細から備考まで表示されていることを確認しました。その PDF が冒頭と途中の比較画像です。添付ファイルへの保存や、条件によるボタン表示の動きは、別の確認として残っています。
| 確かめること | 結果 |
|---|---|
| レコード 5 の PDF の文字・罫線・金額・改行 | 明細 4 行・長い商品名の折り返し・金額・備考の 2 行を確認 |
| 明細 4 行の PDF が 1 ページに収まるか | 両版とも 1 ページに収まり、下に余白がある。ページ番号は 1 / 1
|
| 請求書ファイルへの保存 | 未確認 |
| 再発行時、PDF が追加されるか置き換わるか | 未確認 |
| 請求番号・請求日が空の場合のボタン表示 | 未確認 |
| 明細 12 行・13 行の場合のボタン表示 | 未確認 |
| 明細 12 行で、商品名や備考が長い場合の収まり | 未確認 |
今回、Codex は kintone の項目・レコード・プラグイン設定を書き換えていません。作成したのは、ローカルの設定 JSON とプレビューです。
kintone に取り込む
「要設定」の内容を差し替えてから、印刷屋プラグインの設定画面に取り込みます。
- アプリの設定 → プラグイン → 印刷屋プラグインの 設定
-
設定をアップロード で
APP3443-見積書-請求書.jsonを選ぶ - 請求書ボタンを新しく足すなら 追加。すでに最初の版を取り込んでいるなら 一部置換で、置き換え先の「請求書」を選ぶ
- 保存する → 運用環境に反映
- レコードの詳細画面で「請求書」を押し、PDF の見た目・ファイル名・保存先を確かめる
「追加」と「一部置換」を使うと、既存の見積書ボタンを残したまま請求書を取り込めます。同名のボタンがある状態で「追加」にすると「請求書 (2)」になるため、差し替えたい場合は「一部置換」を選びます。
かかった時間・トークン数・概算コスト
今回の会話ログから、請求書作成の 2 回の依頼を集計しました。契約は ChatGPT Business、モデルは **GPT-6.1 Sol、推論設定は「中（medium）」**です。ログにも gpt-6.1-sol と medium が記録されています。
2 回の作業時間は合計 6 分 33 秒。Business の購入クレジットの Standard 単価に換算すると 約 11.05 クレジット、1 クレジット＝$0.04 と仮定すると 約 $0.44です。これは今回の実請求額ではなく、月額料金・税を含めない概算です。公式の料金案内
時間にはツール実行・承認待ちを含み、依頼と次の依頼の間の時間、記事作成、kintone での取り込み・PDF 確認は含みません。Business の標準席でプラン内の利用枠に収まっていれば、この作業の追加支払いはありません。
時間・トークン数の集計方法と、コスト計算の内訳
| 回 | 依頼 | 経過時間 | 入力トークン | うちキャッシュ入力 | 出力トークン |
|---|---|---|---|---|---|
| 1 通目 | 請求書の設定ファイルを作成 | 4 分 28 秒 | 1,090,112 | 1,022,592 | 5,942 |
| 2 通目 | あらためてデザイン | 2 分 05 秒 | 536,307 | 516,736 | 5,455 |
| 計 | 6 分 33 秒 | 1,626,419 | 1,539,328 | 11,397 |
- 時間はローカルの会話ログの
task_startedからtask_completeまでです。秒未満を四捨五入しています。ツール実行と承認待ちを含み、依頼と次の依頼の間の時間、記事作成、kintone での取り込み・PDF 確認は含みません。厳密には「送信ボタンを押した時刻」ではなく、ログに記録された処理開始から完了までの時間です - トークン数は、各依頼の前後の
token_count.info.total_token_usageの差分です。累積値を毎回足すと重複するため、差分で集計します。キャッシュ入力は入力トークンの内数で、別途加算しません - 入力には依頼文だけでなく、資料・ツールの結果・会話履歴などを、処理を続けるために何度も読み込んだ分が含まれます。最終回答の文字数や、設定ファイルの大きさを表す数値ではありません
- この表はログに記録された使用量で、請求額ではありません。実際の作業単位の支払額は確認していません
次回も同じように測るなら、対象の依頼の開始・終了イベントと、直前・終了時点の累積使用量を保存します。人が PDF を確認する時間も含めたい場合は、それを別に計測します。
Business の購入クレジットに換算すると
2026 年 10 月 7 日に確認した公式の料金案内では、GPT-6.1 Sol の Standard 速度の単価は、100 万トークンあたり通常入力 50 クレジット、キャッシュ入力 2.5 クレジット、出力 250 クレジットです。この単価で今回の使用量を換算しました。
| 回 | 依頼 | 概算クレジット | 1 クレジット＝$0.04 と仮定した換算額 |
|---|---|---|---|
| 1 通目 | 請求書の設定ファイルを作成 | 7.42 | $0.30 |
| 2 通目 | あらためてデザイン | 3.63 | $0.15 |
| 計 | 11.05 | $0.44 |
合計は丸める前の値から計算しています。各行のドル表示を足すと $0.45 になりますが、丸める前の合計は $0.4420848 なので、合計欄は $0.44 です。
計算の内訳は次のとおりです。キャッシュ入力は入力トークンの内数なので、通常入力から差し引きます。
通常入力 87,091 × 50 / 1,000,000 = 4.35455 クレジット
キャッシュ 1,539,328 × 2.5 / 1,000,000 = 3.84832 クレジット
出力 11,397 × 250 / 1,000,000 = 2.84925 クレジット
合計 11.05212 クレジット
約 11.05 クレジット、仮に 1 クレジット＝$0.04 なら約 $0.44です。ドル換算の単価は仮定で、実際の購入単価や割引を確認したものではありません。月額料金・税は含めていません。
Business の標準席でプラン内の利用枠に収まっていれば、この作業の追加支払いはありません。上の金額は、購入クレジットで同じ使用量を処理した場合の相当額で、今回の請求額ではありません。Codex 専用席や購入クレジットの利用状況によって扱いが変わるため、実際の支払いは契約と使用量画面で確認します。
また、「中（medium）」は推論の強さで、Standard / Fast という速度設定とは別です。今回の計算は Standard 速度を前提とした概算です。ログの速度設定は確定できていません。Fast 速度で購入クレジットを使った場合は公式単価が 2 倍になり、約 22.10 クレジット（同じドル換算の仮定なら約 $0.88）です。
今回の試作で分かったこと
Claude Code を前提に用意した帳票作成のしくみは、今回の試作では Codex でも使えました。 帳票仕様やレシピ、オーサリング用コマンドを使い、請求書の設定 JSON を作成し、検査と HTML プレビューの出力まで進められました。
請求書の作成だけでなく、言葉でデザインの変更を依頼する流れも試せました。これから同じしくみで帳票を作るなら、次の条件を伝えると進めやすくなります。
- 既存の帳票を参考にするかを最初に伝える。「前回の見積書を土台にして」か「既存の帳票は参考にせず、新しくデザインして」かで、作る方向を指定します
- 未確定の業務情報は「要設定」にする。会社名・登録番号・口座情報を推測させず、正しい情報がそろってからまとめて差し替えます。今回も、実情報への差し替えは残っています
- 業務の条件を伝え、最後は実物で確認する。明細の最大行数、支払期限、宛名の敬称などを指定し、使うレコードで PDF の収まりと保存先を確かめます
前回は Claude Code、今回は Codex を使いました。どちらの回も、作業フォルダーの帳票仕様とオーサリング用コマンドを使って設定を作っています。ただし、今回は同じ条件で性能を比較した実験ではありません。前回は 3 案の作成と評価、今回は請求書の作成と再デザインなので、時間の違いをそのまま AI の性能差とは扱えません。
関連記事
- rex0220 印刷屋プラグイン - AI(Claude Code)に帳票を作らせる（環境の用意とご提案書）
- rex0220 印刷屋プラグイン - AI(Claude Code)に帳票を作らせる（時計カタログ編）
- rex0220 印刷屋プラグイン - AI(Claude Code)に帳票を作らせる（見積書 3 案から実用版へ）
- 続編: rex0220 印刷屋プラグイン - AI(Claude Code)に帳票を作らせる（画像から見積書を再現）（見積書の画像 1 枚から、同じ見積書を Claude Code に作らせる）
- 帳票作成用のテンプレートリポジトリ
- rex0220 印刷屋プラグイン
- rex0220 印刷屋プラグイン FAQ