業務系のプログラマとして長年、VB.NET や C# で業務システムを作ってきました。そんな中、帳票の開発をすることになります。帳票デザインソフトを使う事がなかったこともあって思わぬ苦戦を…
このシリーズでは、現場で出会った「ちょっとした不便」をきっかけに、AI 開発ツール Claude Code と一緒に、自分なりの帳票システムを OSS として作っていく開発記録を書き残していこうと思います。
自作する帳票システムのタイトルは 「Kasane（重ね）」。日本の伝統「重ね色目（かさねのいろめ）」から名前を取りました。なぜこの名前にしたかは、後ほどゆっくり書きます。
発端: ある日の業務での「困った」
今回使う事になった帳票デザインソフトは業務でよく扱う業界ではメジャーな製品でした。長年お世話になっている方もいらっしゃるのではないでしょうか。
ある日の作業中、私はある機能でつまずきました。
それは 「条件によって帳票に重ねる図を変える」 という、業務帳票では割とよくある要求です。
例えば請求書なら:
- 通常時はそのまま
- 支払い済みなら「支払済」スタンプを重ねる
- 未払いなら「未払い」スタンプを重ねる
こういった条件分岐による表示の切り替えを、データ側の指定で制御したいわけです。テンプレートは1つで、流し込むデータ（条件）によって、最終的な見た目が変わる。
この帳票デザインソフトでは可能な機能なのですが、いえメイン機能といっていいかもしれません。この機能に思わぬ苦戦をしてしまいます。
ヘルプファイルを見ながら試行錯誤の末になんとか動かしたものの、「これ、もっと素直に作れないものかな」という疑問が頭に残りました。
「ある業務ソフト」が抱える、構造的な課題
冷静に考えると、その帳票デザインソフト自体はすごく優秀です。長い歴史のあるソフトで、当時のアーキテクチャは時代に合ってました。
ただ、今の業務ニーズと、いくつか噛み合わない部分もあります。
- PDF を直接生成する機能がない: PDF にしたい時は「Microsoft Print to PDF」のようなプリンタ経由で出力するしかない
- .NET から直接呼び出せない: 古い世代の COM や独自 API ベースで、最近の C# プロジェクトに組み込みづらい
- デザインファイルが独自バイナリフォーマット: 中身を読んだり、Excel など別形式に変換したりするのが難しい
現場では「いっそ Excel で帳票を作って、PDF 出力したい」という声もよく聞きます。古いソフトから離脱したいニーズが、確実にある。
「じゃあ、自分で作ってみるか」
業務での解決策を探すうち、ふと考えました。
「これ、自分で作れないだろうか」
私は別途、自作の PDF 編集 DLL も育てています。これは GitHub で OSS として公開していて、業務で PDF 編集機能が必要な時に使っています。
もし帳票デザイン部分と PDF 編集部分が、それぞれ独立した小さな OSS としてあれば、現代的な .NET 環境にきれいに組み込める帳票ソリューションが作れるのではないか。
そう考えた瞬間、頭の中で構想が膨らみ始めました。
ここで Claude Code の出番
ですが、ゼロから業務システムを作るには時間が足りません。普段の業務、副業、家族との時間、ブログの執筆、ゲーム開発の趣味…と、50代になって自分の時間は本当に限られています。
そこで頼ったのが Claude Code（Anthropic 社の AI 開発ツール）でした。
Claude Code は、ターミナルから AI と対話しながらコードを書き進められるツールです。私が「こういう設計で作りたい」と伝えれば、AI が実装の細部を埋めてくれる。私はレビューと方針判断に集中できる。
これまでも Claude（Web 版）と相談しながら設計を詰めることはありましたが、Claude Code を使い始めてから、個人開発のスピードが体感で何倍にもなった実感があります。
特に Anthropic の Max プランに変えてからは、応答が速くて作業が止まらない。これは私の体感ですが、20分かかっていた処理が7分ほどで終わることもあります。
Kasane プロジェクトの設計思想
Claude と対話しながら、最初の数時間で 3つの設計思想が固まりました。
1. レイヤー機能を中心思想に置く
冒頭で書いた「重ね合わせ問題」を、後付けの機能ではなく 設計の中心に据える。Photoshop のレイヤーパネルのように、複数の図を重ね合わせて、条件で表示を切り替える。
これは「重ね色目（かさねのいろめ）」という日本の伝統的な美意識にも通じます。複数の意匠を重ねて一つの表現を生み出す、その思想を帳票システムに持ち込みたい。
プロジェクト名「Kasane」は、ここから取りました。
2. シンプルさを最優先
機能を盛り込みすぎず、本当に必要なものだけ。XML と INI 形式の組み合わせで、人間が読み書きできるテンプレート。バイナリの独自フォーマットは作らない。
3. OS の力を借りる
PDF 生成ライブラリを自前で持たず、Windows 標準の印刷機能を経由する。これは、私が業務で長く付き合ってきた 「ある業務ソフト」の設計思想にも通じます。
その業務ソフトも PDF は「プリンタ経由」で出していました。プリンタという OS の抽象化レイヤーを使うことで、ソフト自体は印刷ジョブを作るだけでよくなる。
Kasane もこの思想を継承しつつ、.NET ネイティブで、現代的に書き直す。
技術スタック
これだけで、業務に耐えうる帳票システムが作れます。シンプルですね。
| 項目 | 採用 |
|---|---|
| 言語 | C# |
| ランタイム | .NET 8（LTS） |
| GUI | WPF |
| 開発環境 | Visual Studio 2022 Community |
| ライセンス | MIT |
| AI 支援 | Claude Code |
このシリーズで書いていきたいこと
このシリーズは、設計の判断の経緯を中心に書きたいと思っています。
「なぜこの選択をしたか」「Claude と相談する中で、最初の案がどう変わっていったか」「失敗してピボットした瞬間」など、開発の生きた記録として残せたら、似た課題を持つ業務系プログラマの方の参考になるかもしれません。
予定している章立て:
| 回 | テーマ |
|---|---|
| 第1回（今回） | プロジェクトの誕生 |
| 第2回 | 仕様策定 — file-format.md から始める |
| 第3回 | Phase 1 — コアライブラリの実装 |
| 第4回 | Phase 2 — WPF プレビューア |
| 第5回 | Phase 3 — 印刷の挫折と再生 |
| 第6回 | Phase 4a-1 — 図形・寸法線・ロゴ |
| 第7回 | Phase 4a-2 — 明細行（予定） |
| 第8回 | Phase 4a-3 — 画像化機構（予定） |
| 第9回 | Phase 4b — デザイナー（予定） |
開発が進む少し後を追って、隔週ペースで書いていく予定です。
次回予告
次回は、Kasane の設計を始めるにあたって最初に作った「仕様書」 の話です。
業務システム開発の方ならピンと来ると思いますが、仕様書を先に作ることには大きな意義があります。特に AI と対話して開発する時、仕様書が AI への共通理解の土台になります。
「.kasane ファイルと .dat ファイルの二層構造」「レイヤーをどう XML で表現するか」「データバインドの仕組み」など、具体的な設計判断の話に入っていきます。
それでは、また次回。