パスワードを持たないログイン設計：「コードがあれば通す、無ければ作る」を安全に実装する
ある子ども向けアミューズメント系システムの案件で、通常とはかなり毛色の違う認証要件に出会いました。
NFC来店・ポイント・承認フローを支える飲食店アプリのDB設計 — 100テーブル超を破綻させない5つの勘所
飲食店発見・来店ポイント系アプリのバックエンド設計に携わり、100テーブルを超えるスキーマを扱いました。「ユーザーが店を探す → NFCタグをスキャンして来店 → ポイントが貯まる → 投稿・応援・スタンプラリー」という体験を支えるデータモ…
計測データの時系列グラフAPIを「期間窓ごとに欠損ゼロ」で返す設計
計測機器向けのSaaS案件で、測定値の推移を「1ヶ月 / 3ヶ月 / 半年 / 1年」で切り替える折れ線グラフのAPIを担当しました。一見「期間で集計して返すだけ」ですが、実運用に載せると「測定が無い期間をどう扱うか」が最大の設計判断になり…
Reactのコンポーネント設計原則 ― 入門から実務で迷わないための指針
Reactを書き始めると、まず動くものは作れます。しかしプロジェクトが育つにつれ「このコンポーネント、どこまで責務を持たせるべきか」「propsが増えすぎて扱いづらい」「状態をどこに置けばいいか分からない」といった悩みに必ずぶつかります。
Django でクリーンアーキテクチャを導入する（全体設計編）
Django は「Fat Model / Fat View」になりやすいフレームワークです。ORM が強力で、ビジネスロジックをどこにでも書けてしまうからです。小規模なうちは問題ありませんが、ドメインが複雑化すると「この計算ロジックはどこに…
テーブル命名規約 — プレフィックスで種別を明示する設計
テーブルが数十を超えたあたりから、スキーマは「一覧を眺めただけでは構造がわからない」状態になっていきます。マスタなのかトランザクションなのか、それとも中間テーブルなのか。名前だけでは判別できず、毎回 DDL を開いて確認するという状況は珍し…
main ブランチのCIが通ったら本番へ——自動デプロイ「ゲート」の落とし穴と設計手順
手動デプロイを卒業し、「main にマージ → CIグリーン → 本番へ自動反映」というCD（継続的デリバリー）を組む案件は多い。だが実際にやってみると、パイプラインそのものより 「どのマージを本番反映の対象とみなすか」を判定するゲート で…
AIエージェントに本番UPDATEをさせる前に置くべき「承認ゲート」設計
AIエージェント（Claude Code や Cursor など）に実務フローを任せ始めると、ある日必ず「本番DBへの書き込みまでやってほしい」という要求にぶつかる。集計結果の反映、フラグの一括更新、特定期間のレコード修正——こうした破壊的…
【Laravel(PHP)】で2段階認証。出来る事やセキュアなログインをまとめてみる
【Laravel(PHP)】で2段階認証。出来る事をまとめてみる 最近「顧客情報などを不正に抜き取られた問題で...」なんてニュースが多くあります。 その際に必ず出てくるのが「2段階認証などセキュリティー対策が万全ではな […]
ユーザーが意図しない区分は廃止すべきだと痛感した件
ユーザーが意図しない区分は廃止すべきだと痛感した件 自作システムがある程度まとまり、何とか使えるレベルに持ってくることが出来ました。 DEMO版の作成も出来たしね。 と言う事で、色々弄ってバグ出しやら画面構成/遷移の見直 […]