飲み会のために開発したチケット受付システムのソフトウェア設計論

【ShizuokaTECH#2】 飲み会のために開発した チケット受付システムの ソフトウェア設計論 Github: junseinagao / Twitter: @junpai_code

自己紹介 長尾准誠 (ながおじゅんせい) KODANSHAtech 合同会社 Webエンジニア 1997年2月生まれ (29歳) X: @junpai_code / Github: junseinagao （`#ShizuokaTECH` で感想よろしく！） 静岡大学人文社会科学部卒です 静岡大学吹奏楽団という大学部活に青春した JUNSEINAGAO/@JUNPAI_CODE

チケット受付システムとは？ ライブイベントのチケットや長距離バスのチケットを考えてほしい 機能としては... 参加者はメールにチケット（QRコード/バーコード）が送られてくる 運営者はチケットを読み取って（受付）入場許可の確認ができる JUNSEINAGAO/@JUNPAI_CODE

チケット受付システム開発の経緯 OBOG会のシステム屋として今年は設立60周年記念事業のために色々 動いてる（団体のための会員システムを開発運用したり...） JUNSEINAGAO/@JUNPAI_CODE

チケット受付システム開発の経緯 2027年初頭には関係者を集めた大規模なセレモニーを開催する予定 本番イベントでいきなり動かすのは怖いな... → よし、システムを飲み会で試験運用しよう！ （と近い期日へ向けてチケットシステムをAgentic Codingで実装してもら ったら...） JUNSEINAGAO/@JUNPAI_CODE

AI（Fable 5）が設計実装したアーキテクチャ JUNSEINAGAO/@JUNPAI_CODE

実際にQA（手動テスト）してみると... データをPostgres→Firestoreへエクスポートするときにバリデーション 💢 エラーでうまく動かない Claude Fable 5などのフラッグシップモデルであっても複雑すぎる仕様 と実装の前には正常系をパスできない実装 （データバリデーションの 見落とし）を余裕でする どうするか... → 仕様・実装の複雑性を招かないために概念設計をする JUNSEINAGAO/@JUNPAI_CODE

概念設計が大事 概念設計とは？ システムが扱う「概念」 、 「責務」を整理する 概念どうしの関係や境界の線引きを決める 境界を元にデータモデルやシステム構成へ設計を落とし込む （Zenn記事『概念設計が、その後のコードの命運を左右する』を参考に） 例えば： 複数システムで持つ同じデータを常に同期し続ける必要はない 受付に必要な情報だけをPostgres（既存データストア）からFiresstore にシードして受付システム側でデータ操作を完結させる JUNSEINAGAO/@JUNPAI_CODE

• https://zenn.dev/takeshi_teshima/articles/bae79b2f0f97be

概念設計しなおしたアーキテクチャ JUNSEINAGAO/@JUNPAI_CODE

アーキテクチャの比較用の旧設計図 （旧） （新） JUNSEINAGAO/@JUNPAI_CODE

まとめ 2026年8月時点のフラッグシップAIは、与えた要件をすべて設計・実装 で解決しようとする 人間が概念設計で問題を小さくしてからAIに実装させる まだまだ人がアーキテクトとして判断すべきことはたくさんある 2026年12月13日（富士市文化会館ロゼシアター）／2027年2月14日 （清水市民会館マリナート）でそれぞれ演奏会を開催予定ですので、 ぜひお立ちよりください JUNSEINAGAO/@JUNPAI_CODE

ご静聴ありがとうございました