領収書をメールで送るシステムを、あえて1,180行で作った理由 — 非エンジニアが育てられる土台として
領収書をPDFで発行して、ダウンロードURLをお客様へメールで送るシステムを公開しました。
kinvoice — コードは MIT License で無償公開しています。
デモも触れます（https://proto.exbridge.jp/kinvoice/・パスワード demo2026）。
作るときに決めたことがひとつあります。完成品にしないことです。
1,180行に収めた理由
このシステムは、全部で約1,180行です。ファイルは5つ。
| ファイル | 行数 | 中身 |
|---|---|---|
kinvoice.php |
約390 | 管理画面 |
kinvoice_dl.php |
約135 | お客様のダウンロードページ |
kinvoice_auth.php |
約160 | ログイン |
kinvoice_lib.php |
約270 | 台帳・税計算・メール送信 |
kinvoice_pdf.php |
約225 | PDF生成 |
この大きさは、意図してこうしています。
これ以上減らすと、本番で必要なもの（認証・排他制御・CSRF・レート制限）が抜け落ちます。おもちゃになる。
これ以上増やすと、買った人が最後まで読めなくなります。読めないコードは、改変できません。改変できないものは、完成品と同じで、渡された瞬間から劣化していきます。
「全部読めるサイズ」が、育てられるかどうかの境目だと考えました。
データベースも外部ライブラリも使いません
顧客名・金額・メールアドレスは、JSONファイルに flock で書いています。PDFは、仕様を直接書いて生成しています。TCPDF も Composer も使いません。
理由は設置できる場所を増やすためです。
日本の小さな会社が持っているのは、たいていPHPが動く共有レンタルサーバーです。そこに MySQL の設定から始めさせると、多くの人がそこで止まります。Composer が無いサーバーで数十MBの vendor/ をFTPで上げるのも現実的ではありません。
FTPで上げるだけで動く。そこまで下げないと、届く相手が減ります。
PDFをメールに添付しない
設計でいちばん悩んだところです。
添付にすると、宛先を1文字間違えた瞬間に、領収書が他人の手元に残ります。取り消せません。相手の受信箱にあるものは消せないからです。
なので、こうしました。
メールに送るのは、推測困難なURL（32桁）だけ
↓ 開く
宛先メールアドレスの入力を求められる
↓ 一致
PDFがダウンロードされる
URLだけが漏れても開けません。宛先を間違えても、その人のアドレスとは一致しないので開けません。認証前の画面には、顧客名も金額も領収書番号も出しません。
便利さより、取り返しのつかなさを避けることを優先しました。
VWork を同梱した理由
このパッケージには、VWork というドキュメント一式を入れています。AIと仕事を進めるための作法です。目的と成果物の決め方、禁止事項、そして「できました」と言う前の確認手順。
正直に書くと、VWork は単体では価値が伝わりにくいものでした。
マークダウンの束です。書いてあることは実運用から出てきたものばかりで中身には自信がありますが、それだけ見せられても「で、どう使うの」で終わります。
動くものに載せて、初めて意味が出ると思いました。
このシステムを1日で作る間に、私たちは6回つまずいています。メールが「送信済」なのに届かない、設定を置いても効かない、動いているのに売り物にならなかった。全部その記録を同梱しました。
そしてその6つは、すべてVWorkの確認手順を守っていれば早く気づけたものでした。
抽象的な作法と、具体的な失敗が1対1で対応している。この形なら、読んだ人が「なるほど、この手順はこういう事故を防ぐためにあるのか」と分かります。
（失敗の詳細は こちらの記事 に書きました）
非エンジニアの土台になってほしい
このシステムを作った本当の目的は、領収書を送ることではありません。
非エンジニアの方がバイブコーディングを始めるとき、いちばん困るのは「最初の1つ」です。白紙からは重い。かといって、完成品を渡されても学びになりません。
動く土台があって、それを自分で少しずつ変えていく。これが一番現実的な入り口だと考えています。
なので、改造の練習問題も同梱しました。
領収書 → 請求書 → 見積書 → 発注書
領収書と請求書の違いは、実はそれほど多くありません。「上記正に領収いたしました」が「下記のとおりご請求申し上げます」になり、お支払期限と振込先が増える。それだけです。
AIに「請求書も出せるようにして」と頼めば、出てきます。そして自分でPDFを開いて、期限が入っているか確かめられます。小さく変えて、結果を自分の目で確認できる。教材としてこれ以上の題材はないと思っています。
見積書まで行くと、明細が複数行になるのでデータの持ち方を決める必要が出てきます。そこが「AIに頼む前に、自分で決める」を体験する場所になります。
何が有償なのか
コードは GitHub で無償公開しています。有償で提供しているのは、それをどう作ったかの記録と、作法です。
docs/02-failures.md— 実際に踏んだ6つの罠と、その気づき方docs/03-exercises.md— 請求書・見積書への改造練習AGENTS.md/CLAUDE.md/INSTALL.md— AIに渡せば設置が進む手順書vwork/— AIと仕事を進めるための作法
Kurage App Store で 55,000円（税込）です。ダウンロード販売のため、設置作業と伴走支援は含まれません。設置代行や改造代行は、有償のサポートとして別途承ります。
関連書籍『AIと作る自動取引ボット入門』
『AIと作る自動取引ボット入門：バイブコーディング×バイブトレーディングで暗号資産・FX戦略を育てる』（小嶋 篤 著・Kindle）は、非エンジニアがAIと対話しながらシステムを組み上げ、運用するまでを、実際の失敗と学びから全49章にまとめた実践書です。
この記事で書いた「読めるサイズにする」「自分で育てられる形で残す」という判断は、この本に記録した実運用の経験から来ています。Kindle Unlimitedなら追加料金なしで読み放題です。
まとめ
完成品は、渡された瞬間から劣化します。変えられないからです。
変えられる大きさで、変えられるライセンスで、変え方の作法まで付けて渡す。それが、非エンジニアの方にとって一番長く役に立つ形だと考えました。
まずはデモを触ってみてください。https://proto.exbridge.jp/kinvoice/（パスワード demo2026）