- GPT-6 Astra 軽で実装
ChatGPT Plus以上であればSites機能が使える。
Webサーバー、簡易なDB、ログイン認証（必要な場合）を持たせることができる。
データベースはD1, R2と呼ばれる場所に保存される。
D1 Relational Database: Used for durable structured data, saved records, user progress, or game scores.
R2 Object Storage: Used alongside D1 for files, images, documents, audio, or video uploads with searchable metadata.
作成されたサイトは
https://任意のシステム名.ユーザー名.chatgpt.siteに
公開され、オリジナルドメインと連携させることもできる。
任意のシステム名はプロンプトで指定すれば応じてくれる。
Chat機能でプロンプトを固めて、
制限が厳しい（5時間・1週間制限がある）Work機能でSitesの作成作業に入る。
プロンプトはやりたいことを依頼すればそれなりのプロンプトが自動生成される。
ChatGPT 6 Astra 軽モードで作成した。
今回、複式簿記の会計・経理システムを作らせることにした。
できたシステムの見栄え（テストデータ）のサンプルはこちら：
かなり本格的なシステムがプロンプト指示で出来上がる。
重たくなるとかさらに本格的に使うようなことがあれば一応、
外部システムへのエクスポートも
ChatGPTで回答できるとのこと。
今回これに取り組んだのがSaaSに課金をしたくないのが主な理由。
ChatGPT Sites 開発事例集
2026/9/17更新:こちらの記事内容も対象とする開発事例集をまとめました。
https://first-success-development-portfolio.mnoda1979.chatgpt.site/
参考までに2回のプロンプトは次を流している
なお、1回目と2回目のプロンプトを同時に流すと5時間制限にかかった。
そのため、2回目のプロンプトを再実行している。
1週間制限にはかかっていない。
@Sites ChatGPT Sitesを使用して、日本の一人法人向け会計Webアプリを構築してください。
これはデモサイトではなく、実際の日常経理で使用することを想定したWebアプリです。ただし、税務申告ソフトを完全に置き換えることは現段階の目的ではありません。
最重要要件は以下です。
1. 複式簿記として会計ロジックが正しいこと
2. データが永続保存されること
3. 帳簿データを誤って物理削除しないこと
4. 会計期間のOPEN/CLOSED/LOCKEDを厳密に制御すること
5. 変更履歴・監査ログを保持すること
6. 全データを外部へエクスポートできること
7. 将来的に銀行CSV、カードCSV、AI仕訳候補、証憑、固定資産、消費税へ拡張できること
8. UIの華美さより、会計ロジック・データ整合性・保守性を優先すること
今回はPhase 1のみを設計、実装、テストしてください。
Phase 2以降を勝手に実装しないでください。
⸻
1. 開発方針
まず現在のChatGPT Sites環境で利用可能な機能を確認してください。
Sitesで利用できない機能や制約がある場合、存在しない機能を仮定して実装しないでください。
必要に応じて利用可能なデータベース、永続ストレージ、認証、ファイル保存等の仕組みを利用してください。
重要な制約が見つかった場合は、可能な範囲で安全な代替設計を採用してください。
会計データをChatGPTの会話履歴やMemoryだけに保存する設計は禁止します。
Siteの永続データとして保存してください。
⸻
2. 対象
日本の一人法人。
基本通貨：JPY
複式簿記。
当面の利用者は1名を想定するが、将来的に、
・Administrator
・Accountant
・Operator
・Viewer
等のユーザー権限を追加できる構造にしてください。
Phase 1で高度な認証システムの構築が困難な場合、認証機能そのものより会計コアの完成を優先してください。
ただし、認証されていないインターネット利用者から会計データを閲覧・変更できる状態では運用しないでください。
⸻
3. Phase 1で実装する機能
以下を実装してください。
・会社基本情報
・会計年度設定
・会計期間管理
・勘定科目マスター
・補助科目
・仕訳入力
・仕訳編集
・仕訳論理削除
・仕訳帳
・総勘定元帳
・試算表
・損益計算書（P/L）
・貸借対照表（B/S）
・監査ログ
・CSVエクスポート
・月次ダッシュボード（基本版）
⸻
4. 会社基本情報
最低限以下を設定できるようにしてください。
・会社名
・会計年度開始日
・会計年度終了日
・基本通貨
将来拡張用として法人番号等を追加できる構造にしてください。
⸻
5. 会計期間管理
会計年度および月次会計期間を管理してください。
各会計期間は以下のステータスを持ちます。
OPEN
CLOSED
LOCKED
OPEN
以下を許可。
・新規仕訳
・仕訳編集
・仕訳論理削除
CLOSED
以下を禁止。
・新規仕訳
・仕訳編集
・仕訳論理削除
管理者のみ再OPEN可能。
LOCKED
年度決算確定等を想定した強いロック。
通常操作では変更不可。
将来的に特殊な管理者操作で解除できる余地は残してもよいが、Phase 1の通常UIから簡単に解除できないようにしてください。
重要：
画面上で編集・削除ボタンを非表示にするだけでは不十分です。
データ更新処理側でも必ず会計期間ステータスを検証し、CLOSED/LOCKED期間への不正な更新を拒否してください。
⸻
6. 会計期間再OPEN
CLOSED期間は管理者が再OPENできるようにしてください。
その際、
・対象期間
・変更前ステータス
・変更後ステータス
・実行者
・実行日時
・理由
を監査ログに記録してください。
理由の入力は必須としてください。
再度CLOSEした日時・実行者についても記録してください。
⸻
7. 仕訳データモデル
単純仕訳だけを前提にした構造にしないでください。
複合仕訳を正しく表現できるよう、
Journal Header
Journal Lines
のようにヘッダーと明細を分離したデータモデルを推奨します。
最低限、以下を保持してください。
Journal Header
・journal_id
・journal_number
・transaction_date
・description
・counterparty
・status
・created_at
・created_by
・updated_at
・updated_by
・deleted_at
・deleted_by
・delete_reason
Journal Lines
・line_id
・journal_id
・account_id
・subaccount_id
・debit_amount
・credit_amount
・tax_code
・line_description
仕訳単位で、
SUM(debit_amount) = SUM(credit_amount)
にならなければ確定登録できないようにしてください。
金額に浮動小数点誤差が発生しないデータ型・計算方式を使用してください。
JPYでは円単位を基本とします。
⸻
8. 仕訳番号
仕訳には人間が確認可能な仕訳番号を付与してください。
内部IDとは別にしてください。
重複しないこと。
並び順・検索に使用できること。
論理削除した仕訳番号を別仕訳に再利用しないでください。
⸻
9. 物理削除と論理削除
重要要件です。
通常のアプリケーション操作から会計帳簿データを物理DELETEする機能を提供しないでください。
OPEN期間のみ論理削除可能としてください。
論理削除時には、
status = DELETED
等の状態に変更し、
・deleted_at
・deleted_by
・delete_reason
を必ず保存してください。
削除理由は必須です。
論理削除された仕訳は、
・総勘定元帳
・試算表
・P/L
・B/S
・ダッシュボード
の金額計算から除外してください。
ただし、仕訳帳には、
「削除済みを表示」
の切替を用意してください。
削除済み仕訳を表示した場合は、ACTIVEな仕訳と明確に視覚区別してください。
監査目的で内容を確認できるようにしてください。
⸻
10. 仕訳編集
OPEN期間のACTIVE仕訳のみ編集可能としてください。
編集前の内容が分からなくなる設計は禁止します。
最低限、監査ログに、
・対象仕訳
・変更日時
・変更者
・変更内容
を記録してください。
可能であれば変更前・変更後の値を記録してください。
⸻
11. 勘定科目マスター
最低限以下を保持してください。
・account_id
・account_code
・account_name
・account_type
・statement_type
・normal_balance
・default_tax_code
・display_order
・active
account_type：
ASSET
LIABILITY
EQUITY
REVENUE
EXPENSE
statement_type：
BS
PL
勘定科目コードは重複不可。
使用済み勘定科目を安易に物理削除しないでください。
不要になった科目はactive=false等で無効化してください。
⸻
12. 補助科目
勘定科目に紐付く補助科目を設定できる構造にしてください。
例：
普通預金
→ ○○銀行
→ △△銀行
売掛金
→ A社
→ B社
Phase 1では基本的な登録・選択ができれば十分です。
⸻
13. 仕訳帳
以下の検索・表示を実装してください。
・期間
・仕訳番号
・勘定科目
・補助科目
・摘要
・取引先
・金額
・ACTIVE/DELETED
CSV出力可能にしてください。
⸻
14. 総勘定元帳
勘定科目別に以下を表示してください。
・日付
・仕訳番号
・摘要
・相手科目
・借方
・貸方
・残高
期間指定可能にしてください。
期首残高から各取引を反映して残高推移を確認できるようにしてください。
⸻
15. 試算表
月次および年度単位で以下を表示してください。
・勘定科目
・期首残高
・借方発生額
・貸方発生額
・期末残高
借方合計と貸方合計の整合性チェックを表示してください。
不一致の場合は明確な警告を表示してください。
⸻
16. P/L
仕訳データから自動生成してください。
最低限以下を表現できる構造にしてください。
・売上高
・売上原価
・売上総利益
・販売費及び一般管理費
・営業利益
・営業外収益
・営業外費用
・経常利益
・特別利益
・特別損失
・税引前当期純利益
Phase 1では日本の一般的な中小法人で利用できる基本形を優先してください。
⸻
17. B/S
最低限、
・流動資産
・固定資産
・流動負債
・固定負債
・純資産
を表現できる構造にしてください。
必ず、
資産 = 負債 + 純資産
の整合性チェックを行ってください。
不一致の場合は警告してください。
⸻
18. 前期繰越・利益
会計年度をまたいで利用できることを前提に設計してください。
当期純利益と純資産の関係、翌期への残高繰越を考慮してください。
Phase 1で完全な決算振替自動化まで実装しない場合でも、将来実装可能なデータ構造にしてください。
⸻
19. 監査ログ
以下の操作を記録してください。
・仕訳作成
・仕訳編集
・仕訳論理削除
・会計期間OPEN
・会計期間CLOSE
・会計期間再OPEN
・会計期間LOCK
・勘定科目変更
・補助科目変更
・会社設定変更
最低限、
・event_id
・event_type
・target_type
・target_id
・user
・timestamp
・before
・after
・reason
を保持できる構造にしてください。
監査ログは通常UIから変更・削除できないようにしてください。
⸻
20. CSVエクスポート
システムへのロックインを避けるため重要です。
最低限以下をCSV等の一般的な形式でエクスポートできるようにしてください。
・全仕訳
・仕訳明細
・勘定科目
・補助科目
・会計期間
・監査ログ
論理削除済みデータも、バックアップ用途ではエクスポート可能にしてください。
日本語文字化けを起こしにくい形式にしてください。
⸻
21. 月次ダッシュボード
Phase 1では簡潔にしてください。
表示項目：
・当月売上
・当月費用
・当月利益
・年度累計売上
・年度累計利益
・現預金残高
・売掛金残高
・買掛金/未払金残高
可能なら前月比較も表示してください。
UIを派手にすることより数値の正確性を優先してください。
⸻
22. 将来拡張
Phase 1では以下を本格実装しないでください。
ただし、将来的に追加しても大規模なデータモデル変更が不要になるよう設計してください。
Phase 2：
・銀行CSVインポート
・クレジットカードCSVインポート
・重複取引検出
・仕訳候補
・AI仕訳候補
・ユーザー承認
Phase 3：
・証憑管理
・固定資産台帳
・減価償却
・消費税集計
・インボイス関連情報
・高度なダッシュボード
・外部会計ソフト向けCSV
・ユーザー/ロール管理強化
AI仕訳候補を将来実装する場合も、
AI候補
→ユーザー確認
→確定
を原則とし、AIが既存の確定仕訳を勝手に変更・削除する設計は禁止します。
⸻
23. UI
業務アプリとしてシンプルで見やすくしてください。
左側または適切なナビゲーションに、
ダッシュボード
仕訳入力
仕訳帳
総勘定元帳
試算表
P/L
B/S
勘定科目
補助科目
会計期間
監査ログ
設定
を配置してください。
PCでの利用を中心としつつ、スマートフォンでも主要情報を確認できるレスポンシブUIにしてください。
過剰なアニメーションは不要です。
⸻
24. 安全性
以下は禁止してください。
・会計データの無断物理DELETE
・AIによる確定仕訳の自動変更
・CLOSED期間への通常仕訳登録
・CLOSED期間の仕訳編集
・CLOSED期間の論理削除
・LOCKED期間の通常変更
・貸借不一致仕訳の確定
・監査ログの通常ユーザーによる変更
・会計データを会話Memoryだけに依存して保存すること
⸻
25. テストデータ
Phase 1完成後、テスト会社を作成し、最低限以下の取引を登録してください。
1. 資本金の普通預金入金
2. 現金売上
3. 売掛金による売上
4. 売掛金の入金
5. 現金による経費支払
6. 普通預金による経費支払
7. クレジットカード購入を想定した未払金計上
8. 未払金の普通預金からの支払
9. 普通預金口座間の資金移動
10. 固定資産購入を想定した仕訳
⸻
26. 必須テスト
テスト後、最低限以下を検証してください。
A.
すべての確定仕訳について、
借方合計 = 貸方合計
であること。
B.
試算表の貸借が一致すること。
C.
B/Sで、
資産 = 負債 + 純資産
が成立すること。
D.
P/Lの当期利益とB/S純資産との関係に論理的矛盾がないこと。
E.
OPEN期間で仕訳登録できること。
F.
OPEN期間で仕訳編集できること。
G.
OPEN期間で論理削除できること。
H.
CLOSED期間で新規仕訳が拒否されること。
I.
CLOSED期間で編集が拒否されること。
J.
CLOSED期間で論理削除が拒否されること。
K.
CLOSED→OPENの再OPEN履歴が監査ログに残ること。
L.
論理削除仕訳が、
・試算表
・総勘定元帳残高
・P/L
・B/S
・ダッシュボード
の計算から除外されること。
M.
削除済み仕訳を監査目的で確認できること。
N.
CSVエクスポート後も仕訳データを復元・移行するために必要な情報が失われていないこと。
⸻
27. 作業手順
以下の順序を守ってください。
STEP 1
要件を確認し、Sites環境の制約を確認する。
STEP 2
システムアーキテクチャを設計する。
STEP 3
データモデル・テーブル・リレーションを設計する。
STEP 4
会計ロジックを設計する。
STEP 5
OPEN/CLOSED/LOCKEDおよび論理削除・監査ログの制御を設計する。
STEP 6
Phase 1を実装する。
STEP 7
テストデータを投入する。
STEP 8
必須テストA〜Nを実施する。
STEP 9
発見した不具合を修正する。
STEP 10
再テストする。
STEP 11
最終結果を報告する。
⸻
28. 作業中の判断
軽微なUIや実装方式については、合理的な判断で進めてください。
不要な確認質問で作業を止めないでください。
ただし、以下の場合は勝手に推測せず明示してください。
・会計データの安全性に重大な影響がある
・Sitesの技術的制約で要件を満たせない
・データ消失の可能性がある
・セキュリティ上重大な問題がある
・会計ロジックについて複数の重大な解釈が存在する
⸻
29. Work利用量への配慮
今回はPhase 1完成を優先してください。
Phase 2およびPhase 3を実装しないでください。
UIの細かな装飾に過剰な時間を使わないでください。
不要な外部調査を繰り返さないでください。
既に正常に動作している部分を理由なく全面的に書き直さないでください。
修正は可能な限り局所的に行ってください。
⸻
30. 完了条件
「画面が表示された」だけでは完成としません。
以下をすべて満たした場合にPhase 1完成としてください。
・仕訳登録ができる
・複合仕訳ができる
・貸借不一致を拒否する
・OPEN/CLOSED/LOCKEDが機能する
・論理削除が機能する
・物理削除を通常操作から実行できない
・仕訳帳が正しい
・総勘定元帳が正しい
・試算表が正しい
・P/Lが正しい
・B/Sが正しい
・監査ログが機能する
・CSVエクスポートができる
・必須テストA〜Nを実施している
・重大な既知不具合が残っていない
最後に、
1. 実装済み機能
2. 未実装機能
3. テスト結果
4. 既知の制約
5. データ保存方式
6. バックアップ/エクスポート方法
7. セキュリティ上の注意
8. Phase 2へ進む際の推奨事項
を簡潔に報告してください。
Phase 1が正常に完成した時点で作業を終了してください。
Phase 2、Phase 3には進まないでください。
2回目は消費税、CSVアップロードダウンロード機能を実装。
既存Phase 1会計Webアプリへの機能追加
既に構築済みのPhase 1会計Webアプリに、以下の機能を追加してください。
1. 消費税・税抜経理対応
2. 税込／税抜入力
3. 税込金額から税抜金額・消費税額への自動分解
4. 消費税集計
5. CSVダウンロード
6. CSVアップロードによる仕訳の新規登録・上書き
これは新規システムの構築ではありません。
既存Phase 1への差分改修です。
既存コードを全面的に書き直さず、必要な箇所のみ変更してください。
⸻
1. 最重要：今回の実装方針
今回の最優先事項は、
利用可能なWork/Codex枠の中で、できるだけ多くの機能を「実際に使用可能な完成状態」まで実装すること
です。
広範囲の機能へ同時並行で手を付けて、最後にまとめて完成・反映する進め方は禁止します。
必ず後述するSTEP順に進め、
1つのSTEPを使用可能な状態まで完成させてから次のSTEPへ進んでください。
利用枠不足が予想される場合も、複数機能を未完成状態で残さないでください。
例えば、
消費税コア：完成
帳票：完成
CSVダウンロード：完成
CSVアップロード：未着手
という状態は許容します。
一方、
消費税：途中
帳票：途中
CSV：途中
という状態は避けてください。
⸻
2. 前回作業の状態確認
前回、消費税対応を実施しようとしたものの利用制限に到達し、ユーザーから確認できる変更は反映されていません。
ただし、
* コード
* DB
* migration
* 設定
* 未反映変更
等が途中状態で残っている可能性があります。
最初に現在の、
* コード
* DBスキーマ
* migration
* 仕訳処理
* 帳票処理
* 消費税関連コード
を確認してください。
前回作業が一部残っている場合は、二重migration、二重カラム追加、二重実装をしないでください。
現在の状態を確認してから差分実装してください。
ただし、ここで過度なシステム分析・設計書作成に時間を使用しないでください。
実装に必要な範囲だけ確認してください。
⸻
3. 既存機能を壊さない
以下の既存Phase 1機能を維持してください。
* 仕訳入力
* 複合仕訳
* 仕訳帳
* 総勘定元帳
* 試算表
* P/L
* B/S
* ダッシュボード
* 勘定科目マスタ
* 補助科目
* 会計期間 OPEN / CLOSED / LOCKED
* 論理削除
* 監査ログ
* 既存CSV機能
* 既存認証
* 既存セキュリティ機能
既存データを削除・再生成しないでください。
DBのDROP・再構築は行わないでください。
必要なDB変更はmigration等による差分変更としてください。
⸻
4. 今回やらないこと
Work/Codex利用枠を実装へ集中させるため、今回の変更に直接必要のない以下の作業は行わないでください。
* 全面的リファクタリング
* コードの美化だけを目的とした変更
* アーキテクチャ全面変更
* UI全面刷新
* デザイン調整
* 不要なアニメーション
* 詳細設計書作成
* 長大なドキュメント作成
* 大量のコメント追加
* 将来機能の先行実装
* 要件外の便利機能追加
* パフォーマンス改善だけを目的とした変更
* 網羅的テスト
* 大量のテストデータ作成
* 詳細なテストレポート
「ついでに改善できる」という理由だけで要件外変更をしないでください。
⸻
5. テスト方針
今回は、
実装を最優先し、網羅的テスト・回帰テストは別タスクとします。
ただし、
* syntax check
* build確認
* migration適用確認
* 最低限の起動確認
* 明らかなruntime error確認
* 実装継続に必要な最低限の動作確認
は実施して構いません。
明らかな構文エラーや起動不能状態を「テストしない」という理由で残さないでください。
⸻
6. テスト会社
今回または将来テストを行う場合、
既に存在する「テスト」という会社のみを使用してください。
新しいテスト会社を作成しないでください。
本番会社・実運用会社へテストデータを投入しないでください。
最低限の動作確認でデータ登録が必要になった場合も「テスト」会社のみを使用してください。
⸻
7. 消費税の基本方針
税抜経理方式を基本とします。
課税取引は、
* 本体価格
* 消費税
を分離してください。
仕入側：
仮払消費税
売上側：
仮受消費税
決算整理後の納付予定：
未払消費税等
とします。
将来的な還付に備えて「未収消費税等」にも拡張可能な構造としてください。
⸻
8. 税区分マスタ
税区分マスタを追加してください。
最低限、
* 課税売上10%
* 課税売上8%
* 課税仕入10%
* 課税仕入8%
* 非課税
* 不課税
* 対象外
を管理してください。
最低限、
* tax_code
* tax_name
* tax_type
* tax_rate
* effective_from
* effective_to
* active
を管理可能にしてください。
将来税率が変更された場合は新しい税区分を追加する方式とし、過去の税率を上書きしないでください。
⸻
9. 勘定科目デフォルト税区分
勘定科目マスタへ、
default_tax_code
を追加してください。
これは仕訳入力時の初期値として使用します。
仕訳明細単位で変更可能としてください。
既存勘定科目を破壊しないでください。
⸻
10. 仕訳明細への税情報保存
仕訳明細へ最低限、
* amount_input_type
* input_amount
* tax_code
* tax_rate
* taxable_amount
* tax_amount
* gross_amount
を保存してください。
仕訳確定時点の値を保存してください。
後から税区分マスタを変更しても過去仕訳を再計算しないでください。
⸻
11. 税抜／税込入力
仕訳明細単位で、
* 税抜
* 税込
を選択可能にしてください。
デフォルトは、
税抜
としてください。
複合仕訳内で異なる税区分・入力方式を使用可能にしてください。
⸻
12. 税抜入力
例：
課税仕入10%
税抜入力
10,000円
の場合、
本体：
10,000円
消費税：
1,000円
税込：
11,000円
として処理してください。
仕訳例：
借方
旅費交通費 10,000
仮払消費税 1,000
貸方
現金 11,000
⸻
13. 税込入力
例：
課税仕入10%
税込入力
11,000円
の場合、
本体：
10,000円
消費税：
1,000円
へ自動分解してください。
仕訳：
借方
旅費交通費 10,000
仮払消費税 1,000
貸方
現金 11,000
売上側についても、
現金等 11,000
を、
売上高 10,000
仮受消費税 1,000
へ分解可能としてください。
⸻
14. 入力画面
最低限、
* 勘定科目
* 補助科目
* 税抜／税込
* 税区分
* 税率
* 入力金額
を扱えるようにしてください。
勘定科目選択時にはdefault_tax_codeを初期値として使用してください。
税込入力の場合、
税込11,000円
→ 税抜10,000円
＋ 消費税1,000円
のような計算結果を確認できるようにしてください。
UIは既存デザインを踏襲してください。
今回、UIの全面的な作り直しは不要です。
⸻
15. 非課税・不課税・対象外
これらは消費税分解を行わないでください。
税額0と税情報未設定はデータ上区別してください。
⸻
16. 端数処理
税込→税抜＋消費税計算の端数処理を明示的に実装してください。
将来的に、
* 切捨て
* 四捨五入
* 切上げ
へ対応可能な構造としてください。
必ず、
税込金額 = 税抜金額 + 消費税額
を成立させてください。
計算済みtax_amountを保存してください。
帳票表示時に現在の税率から再計算しないでください。
⸻
17. 手動税額調整
請求書・領収書の端数差異等へ対応するため、必要に応じて税額を手動調整可能としてください。
変更前後を監査ログへ記録してください。
貸借一致は維持してください。
⸻
18. 総勘定元帳
PL科目は税抜金額で記帳してください。
例えば税込11,000円の旅費なら、
旅費交通費：
10,000
仮払消費税：
1,000
として記帳してください。
仮払消費税・仮受消費税・未払消費税等は通常のBS勘定として表示してください。
⸻
19. 試算表
PL科目は税抜金額で集計してください。
仮払消費税・仮受消費税・未払消費税等はBS科目として表示してください。
既存の貸借一致を維持してください。
⸻
20. P/L
P/Lは税抜表示としてください。
仮払消費税・仮受消費税を売上・費用へ含めないでください。
P/L側で税額を再計算しないでください。
確定仕訳を基礎に作成してください。
⸻
21. B/S
残高に応じて、
資産：
仮払消費税
負債：
仮受消費税
決算整理後：
負債：
未払消費税等
を表示してください。
将来的に未収消費税等にも対応可能な構造としてください。
⸻
22. 消費税集計表
新しい帳票として、
消費税集計表
を追加してください。
期間指定可能としてください。
最低限、
* 税区分
* 税率
* 税抜取引金額
* 消費税額
* 税込金額
* 取引件数
を表示してください。
参考情報として、
* 仮受消費税残高
* 仮払消費税残高
* 差額
も表示してください。
journal_linesの保存済み税情報を使用してください。
現在の税率マスタから過去税額を再計算しないでください。
正式な消費税申告書・e-Tax機能は今回実装しません。
⸻
23. 消費税決算整理
例えば、
仮受消費税 1,500,000
を、
仮払消費税 1,100,000
未払消費税等 400,000
へ整理できるようにしてください。
実際の納付：
未払消費税等 400,000
／普通預金 400,000
も通常仕訳として処理可能としてください。
自動的に決算整理仕訳を確定しないでください。
⸻
24. CSVダウンロード
CSVダウンロード機能を追加・拡張してください。
最低限、
* 仕訳
* 仕訳明細
* 勘定科目
* 補助科目
* 税区分
* 会計期間
をCSV出力可能としてください。
仕訳明細CSVには最低限、
* 会社識別情報
* 伝票番号
* 取引日
* 摘要
* 勘定科目
* 補助科目
* 借方金額
* 貸方金額
* amount_input_type
* input_amount
* tax_code
* tax_rate
* taxable_amount
* tax_amount
* gross_amount
等を含めてください。
再インポート・バックアップ・移行にも利用可能な形式としてください。
日本語Excel等で扱いやすいCSVとしてください。
⸻
25. CSVアップロード
仕訳CSVをアップロード可能としてください。
最低限、
CSV選択
↓
読み込み
↓
形式・内容確認
↓
登録内容確認
↓
実行
としてください。
CSVを選択しただけでDBへ即時登録しないでください。
複雑なインポートウィザードは今回不要です。
⸻
26. CSVの新規／上書きルール
伝票番号なし
新規仕訳として登録してください。
既存採番ルールで新しい伝票番号を採番してください。
伝票番号あり＋DBに存在しない
CSV記載の伝票番号で新規作成してください。
伝票番号あり＋ACTIVE伝票が存在
既存伝票を上書き更新してください。
物理削除はしないでください。
変更前後を監査可能にしてください。
DELETED伝票
自動復活させず、原則エラーとしてください。
CLOSED
新規・上書きとも拒否してください。
LOCKED
新規・上書きとも拒否してください。
⸻
27. CSV複合仕訳
同一伝票番号がCSV内に複数行存在することを許可してください。
同一番号の行を一つの複合仕訳として扱ってください。
既存伝票を上書きする場合、
CSVに存在する同一伝票番号の全明細を、その伝票の新しい明細集合として扱ってください。
旧明細の不要行を残さないでください。
ただし変更前の内容は監査ログ等で追跡可能にしてください。
⸻
28. CSVインポート時validation
以下はテストではなく本番機能として実装してください。
* 必須項目
* 日付
* 金額
* 勘定科目存在
* 補助科目整合性
* 税区分存在
* 税率
* 税額
* 借方合計＝貸方合計
* 伝票番号
* OPEN/CLOSED/LOCKED
* DELETED
* 会社整合性
エラー伝票を無理に登録しないでください。
⸻
29. CSVインポートのトランザクション
少なくとも1伝票単位でDBトランザクションを使用してください。
途中まで登録された伝票を残さないでください。
失敗した場合はその伝票をrollbackしてください。
⸻
30. 監査ログ
既存監査ログを維持し、最低限、
* 税区分変更
* 税率変更
* 税額変更
* 税込／税抜変更
* 手動税額変更
* CSV新規登録
* CSV上書き
* CSVインポート日時
を追跡可能としてください。
CSV上書きは変更前・変更後を追跡可能にしてください。
⸻
31. OPEN / CLOSED / LOCKED
既存ルールを維持してください。
OPEN：
作成・編集・論理削除・CSV新規・CSV上書き可能。
CLOSED：
変更不可。
LOCKED：
通常変更不可。
CSVを利用して期間制御を回避できないよう、サーバー側でも必ず検証してください。
⸻
32. 既存データ
既存仕訳へ税情報がない場合、推測で税情報を付与しないでください。
税情報未設定として保持してください。
税額0とは区別してください。
既存仕訳を一括で税抜化しないでください。
⸻
33. 実装優先順位
以下の順番を厳守してください。
STEP 1
現在のコード・DB・前回作業状態を必要最小限確認。
STEP 2
必要なDB migrationを実装。
STEP 3
税区分マスタ・勘定科目default_tax_codeを実装。
STEP 4
仕訳明細の税情報保存を実装。
STEP 5
税抜／税込入力と自動分解を実装。
STEP 6
仮払消費税・仮受消費税処理を完成。
CHECKPOINT A
ここまでを使用可能な状態にしてください。
ここまで完成する前に帳票・CSVへ広げないでください。
STEP 7
総勘定元帳・試算表・P/L・B/S対応。
STEP 8
消費税集計表。
CHECKPOINT B
ここまでを使用可能な状態にしてください。
STEP 9
CSVダウンロード。
CHECKPOINT C
CSVダウンロードを使用可能な状態にしてください。
STEP 10
CSVアップロード基本機能。
STEP 11
伝票番号による新規／上書き。
STEP 12
CSV複合仕訳・validation・transaction。
CHECKPOINT D
CSVアップロードを使用可能な状態にしてください。
STEP 13
監査ログ・期間制御等の不足箇所を仕上げ。
STEP 14
syntax/build/起動等の最低限確認。
ここで今回の作業を終了してください。
網羅的テストへ進まないでください。
⸻
34. 利用枠不足が予想される場合
全STEPを完成できないと判断した場合でも、広範囲を未完成状態で並行実装しないでください。
必ず、
現在のCHECKPOINTを完成させることを優先してください。
理想的な途中終了例：
CHECKPOINT A：完成
CHECKPOINT B：完成
CHECKPOINT C：完成
CHECKPOINT D：未着手
これは問題ありません。
避けるべき状態：
消費税：途中
帳票：途中
CSV出力：途中
CSV入力：途中
利用枠不足の場合は、未着手の後続STEPを残して終了してください。
⸻
35. 中断・再開安全性
利用制限・通信切断・その他の理由で作業が中断される可能性を前提にしてください。
各CHECKPOINT終了時点で、可能な限りシステムを整合した使用可能状態にしてください。
DB変更については、
* additive migration
* nullable追加
* 新規テーブル追加
等、既存コードとの後方互換性を可能な限り確保してください。
DBとコードの一方だけ変更された危険な状態を長時間残さないでください。
migrationや大量更新の前には、既存環境で利用可能な方法で復元可能性を確認してください。
中断した場合は、次回作業者が再開できるよう、
* 完了したSTEP
* 未完了STEP
* 適用済みmigration
* 未適用migration
* 変更済み主要ファイル
* 次回の再開地点
を簡潔に残してください。
再開時には「前回ここまで終わったはず」と推測せず、実際のコード・DB・migration状態を確認してください。
⸻
36. 禁止事項
禁止：
* 物理削除
* DB DROP
* 全面再構築
* 大規模リファクタリング
* 要件外機能追加
* UI全面刷新
* 過去税額の再計算
* 既存仕訳への推測税区分設定
* CLOSED/LOCKED変更
* CSVによる期間制御回避
* DELETED伝票自動復活
* CSV上書き履歴消失
* 貸借不一致登録
* AIによる無断確定仕訳
* AIによる無断決算整理
* 本番会社へのテストデータ投入
* 新しいテスト会社作成
* 網羅的テスト
* 大量テストデータ作成
* 詳細テストレポート
* 要件外の「ついでの改善」
⸻
37. 判断に迷った場合
軽微なUI配置や既存実装に合わせるだけの技術的判断は、自律的に判断して実装してください。
一方、
* 会計処理
* 税額計算
* データ破壊リスク
* 既存データ互換性
* 期間制御
* セキュリティ
* 監査
* CSV上書き
* migration
について重大な不明点があり、誤判断するとデータを壊す可能性がある場合は、勝手に推測して進めないでください。
⸻
38. 今回の完了目標
今回の目標はテスト完了ではなく、
可能な限り多くの機能を実際に使用可能な状態まで実装すること
です。
優先順位は、
第1優先：消費税コア
↓
第2優先：総勘定元帳・試算表・P/L・B/S・消費税集計
↓
第3優先：CSVダウンロード
↓
第4優先：CSVアップロード・伝票番号による新規／上書き
です。
後順位の機能を途中まで実装するために、前順位の機能を未完成にしないでください。
⸻
39. 作業終了時
最後に長大な説明は不要です。
以下だけ簡潔に報告してください。
1. 完成したCHECKPOINT
2. 実装完了機能
3. DB/migration変更
4. 主要変更ファイル
5. 未完了機能
6. 最低限確認で判明した問題
7. 次回の正確な再開地点
網羅的テストは今回実施しないでください。
将来テストを実施する場合は、既存の「テスト」という会社だけを使用してください。