引き算で作る社内iPad受付システム

「小さく作り、運用で人手を取られない」をコンセプトに、最小限の要素で構築された社内システムの開発実録です。Next.jsやSupabase、API Gatewayといった定番の技術や機能をあえて選ばず、素のHTML、S3、Lambda1本、DynamoDBという極小の5要素に絞り込む「引き算設計」の具体的な判断プロセスがまとめられています。1日数回・月1万円以内・ひとり運用という制約に対し、フロントから運用までの全フェーズで徹底的な割り切りを行った結果、インフラコスト月数百円、運用作業月30分未満という高い実績を達成しており、機能の豊富さではなく引き算の積み重ねがシステムの品質を支えることを証明した知見が詰まっています。

Transcript

1. 引き算で作る 社内iPad受付システム ～選定・フロント・バックエンド・運用の全判断～ SALT2 笠井 奏良
2. 2 2 © 2026 Boost Consulting, Inc. はじめに 小さな社内システムを「引き算」で作り切った記録とその中で得た学びを共有します 1 題材︓社内iPad受付システムとは 2 システムの規模と制約 DISCUSSION ① みなさんなら、どう作りますか︖ 3 本日の主張：引き算設計 4 各回ダイジェスト（選定／フロント／Slack／バックエンド／運用） 5 まとめ DISCUSSION ② あなたの現場に当てはめると？ 全5回シリーズ「引き算で作る社内iPad受付システム」を Zenn Books で公開
3. 3 3 © 2026 Boost Consulting, Inc. 題材 iPadにQRをかざすと、担当者のSlackに通知が飛ぶ受付システム ① 発行フロー（社員側） 担当者 /invite-person → Slack QR画像を発行 → 来訪者へ転送 LINE / メール ② 受付フロー（来訪者側） 来訪者 QRをかざす → iPad カメラで読取 → Slack通知 担当者に@メンション 3社が同居︓SALT2・Boost Consulting・顧問バンク。来訪先の会社に応じて通知先を出し分ける
4. 4 4 © 2026 Boost Consulting, Inc. 前提 「小さく作り、運用で人手を取られない」が機能要件と同じ重みを持つ アクセス頻度 1日 数回 多い月でも3桁に届かない インフラ予算 月 1万円以内 常時起動サーバーは置けない 運用体制 専任者なし 実装者がそのまま運用する この制約だと「何を選ぶか」より「何を選ばないか」が設計の中心になる
5. 5 5 © 2026 Boost Consulting, Inc. DISCUSSION 1 メインの主張の前に 「1日数回・月1万円・ひとり運用」。 この規模のシステム、みなさんなら どんな技術構成で作りますか︖ 3人1組 3〜5分 各グループ1分で共有 正解は不要・主観でOK
6. 6 6 © 2026 Boost Consulting, Inc. 新しいシステムを作るとき、つい 「とりあえず Next.js」「DB は Supabase で」 から入ってしまう 本日の主張 ─ 引き算設計 何を足すか ではなく、何を 足さないか そして引き算が正しかったかは、技術選定の段階では分からない。 フロント実装・本番運用まで追って、初めて見えてくる。
7. 7 7 © 2026 Boost Consulting, Inc. 全体構成 最終的な構成要素は5つに収まった iPad ブラウザ Slack（3社） → CloudFront OAC + IP制限 1枚の窓口 → Lambda × 1 Function URL S3（静的配信） → DynamoDB（入館ログ） Secrets Manager Slack Web API Lambdaは1関数だけ — lambda_main.py がパスを見て verify / no-qr / slack へ振り分ける CloudFront ・ S3 ・ Lambda ・ DynamoDB ・ Secrets Manager の5要素
8. 8 8 © 2026 Boost Consulting, Inc. 第1回 ｜ 技術選定・設計 「何を選ぶか」より「何を選ばないか・何を作らないか」が設計の中心 論点 定番の選択（足す） 採った選択（引く） 失うもの → それでも成立する理由 データベース Supabase DynamoDB JOIN・スキーマ管理を捨てる → 保存は入館ログだけ。IAM認証で完結、月数百件は実質無料 画面の作り方 Next.js 素のHTML / CSS / JS SPAの状態共有を捨てる → 画面は4枚、ビルド工程ゼロで最も壊れにくい 配信 FastAPI + Jinja2（SSR） S3静的配信 サーバー側のHTML生成を捨てる → 画面は固定HTML、動的処理はAPIへ分離 実行基盤 EC2 / ECS（常時起動） Lambda 常時起動を捨てる → 1日数十回。空き時間の課金ゼロ、OSパッチも消える データの持ち方 トークン＋DB参照 QRに全部JSON（約100B） 発行後の変更を捨てる → 発行と入館が疎結合。突き合わせ・有効性チェックがDB不要 「作らない」と決めた機能︓管理者画面 ／ 来訪予定の登録 ／ ユーザー認証 ／ 退室管理 — 1機能足すごとに画面・API・テスト・運用手順が付いてくる 主張への接続 この選定が正しかったかは、フロント実装（第2回）と本番運用（第4・5回）まで追って初めて分かる
9. 9 9 © 2026 Boost Consulting, Inc. 第2回 ｜ フロントエンド iPadキオスクは「普通のWeb開発」の常識から外して引き算する 論点 普通のWeb開発の常識 キオスクでの引き算判断 フレームワーク SPA（Next.js等）が標準 素のHTML4枚。ビルド・ランタイム追従を持たない 画面サイズ レスポンシブ対応 iPad 11"に決め打ち（1194×834）。調整が単純 常時表示 ブラウザで開くだけ PWA化＝manifest + SW の2枚で全画面固定が「要件」 カメラ起動 「HTTPS必須」と誤解されがち 正しくはsecure context必須（localhostはHTTPでも可） QRライブラリ 特徴 判断（撮影条件＝近距離・短いデータ） jsQR 軽量・CDN1行で導入 ◦ 採用。実機で待ち感なし（300ms間隔で十分） html5-qrcode 高機能・UIコンポーネント込み この規模には重い qr-scanner BarcodeDetectorを利用 iPad Safari非対応 → 内蔵検出器に倒れる 主張への接続 フロントの引き算はフレームワーク削減だけでなく、焼き付き対策・secure context・SWキャッシュ（変更時 CACHE_NAME を +1）への目配り まで含めて成立する
10. 10 10 © 2026 Boost Consulting, Inc. 第3回 ｜ Slack連携 1つのSlack Appで3社を捌き、3秒タイムアウトを非同期で逃がす 通知方式 できること 判断（3社へ出し分ける要件） Incoming Webhook 特定1chに送るだけ・設定が最も楽 × 送信先を動的に変えられず3社不可 Bot Token + Web API 任意ch投稿・画像・メンション ◦ 採用。QRの w（team_id）で投稿先を切替 Events + Socket Mode 双方向のリアルタイム通信 × 常時接続が要る → Lambda不向き・HTTP推奨 3秒対処 強み 代償（トレードオフ） Lazy Listener（公式） FaaS向けの正攻法・堅い ローカルモードで不安定 → 開発が回しにくい threading.Thread（採用） ローカルと本番で同じコード 3秒以内応答の凍結リスク → 即座にackだけ返すことで解決 設計の核 1 App × 3 WS は authorize で team_id → Bot Token を切替（3社でも30社でも同じコード）。QRに w（通知先）と sn（担当者名）を 載せ、受付側LambdaはDBを引かず通知できる 主張への接続 Webhook・Socket Mode・Lazy Listener と「定番」を1つずつ外し、常時接続と保管場所を引き算。w を載せる判断は第1回「QRに全部積 む」の続き
11. 11 11 © 2026 Boost Consulting, Inc. 第4回 ｜ バックエンド API Gatewayを撤廃しLambdaを1本に。CloudFront + Function URL + OAC へ 当初想定（定番） 最終構成 引き算の理由 CloudFront CloudFront 1枚の窓口。パスで S3 / Lambda に振り分け（CDN以上の役割を担わせる） API Gateway （撤廃） 使うのはHTTPSエンドポイント＋単純ルーティングだけ → Lambda Function URL（追 加料金なし）で代替 Lambda × 3 Lambda × 1 分けるとデプロイ・IAM・ログ・メトリクスが3倍。lambda_main.py が20行で振り分け S3 S3 静的HTML/CSS/JSの配信 DynamoDB DynamoDB 入館ログ（PutItemのみ） OAC × POST OACのSigV4署名にはボディのハッシュが要る。CloudFront の古いキャッシュ 設定では POST が届かずアクセス拒否 → Managed-CachingDisabled ＋ AllViewerExceptHostHeader へ切替で解決 コールドスタート対策＝「何もしない」 Provisioned Concurrency（月≈5.5USD）／定期ウォームアップ／何も しない の3択。カメラ起動の数秒でLambdaが暖まる → 設定・監視を増やさ ない 主張への接続 「分けるのが普通だから」で増やさず、その規模で本当に要るか1つずつ問い直す。第1回で許容したコールドスタートが、ここで「何もしない」として実証 された
12. 12 12 © 2026 Boost Consulting, Inc. 第5回 ｜ 運用 「ひとり運用」前提で、事故りにくく自分で直せる方向に実装 外したもの 代わりに採った形 引き算の判断 GitHub Actions 手動デプロイ（1スクリプト） 長寿命キーを置かない。月数回ならCI維持は割に合わない 長寿命キー STS AssumeRole 一時クレデンシャルで数時間失効。MFA必須の条件付き 広めのIAM権限 必要な3つだけ PutItem / GetSecretValue / PutLogEvents のみ ロック用DynamoDB S3 native locking use_lockfile=true だけで専用テーブル不要 環境変数の直書き Secrets Manager集約 アプリ起動時にシークレットを展開。漏洩ポイントを減らす 土台 Terraform を platform / app の2層に分割（destroyの巻き添え防止・planを絞る）／層間はSSMで疎結合／運用4設定︓Logs30日 ・ECR5世代・PITR（DynamoDBの継続的バックアップ機能）・S3 versioning 主張への接続 足したのは規模に見合う最小構成と、放っても痛まない最小限の設定だけ。第1回の選定が運用「月30分未満・月数百円」として結実した
13. 13 13 © 2026 Boost Consulting, Inc. まとめ 足し算より引き算が品質を支える 回 引き算したもの 第1回 技術選定 Next.js・FastAPI・Supabase・管理画面・来訪予定DB 第2回 フロント SPAフレームワーク・QRライブラリの「定番」 第3回 Slack連携 Incoming Webhook・Socket Mode 第4回 バックエンド API Gateway・Lambda 2つ 第5回 運用 GitHub Actions・長寿命キー・広めのIAM権限 月 数百円 インフラコスト 月 数回 デプロイ頻度 30分未満／月 運用作業 「客に渡せる品質」は機能の豊富さではなく、引き算の積み重ねで決まる
14. 14 14 © 2026 Boost Consulting, Inc. DISCUSSION 2 発表全体を振り返って ─ 自分の現場に当てはめる あなたの現場やプロジェクトで 「足しすぎている」ものはありますか︖ 削れるとしたら、何を・どう削りますか︖ 3人1組 5分 グループで意見をまとめて共有
15. Strictly confidential CONFIDENTIAL 本文書（添付資料を含む）は、ブーストコンサルティング株式会社が著作権その他の権利を有 する営業秘密（含サプライヤ等第三者が権利を有するもの）です。当社の許可なく複製し利 用すること、また漏洩することは「著作権法」「不正競争防止法」によって禁じられております。本 資料内の社名・製品名は各社の登録商標です。 また、本資料はブーストコンサルティング株式会社による口頭の説明を補助するために使用され るものであって、本件に関する検討内容や議論の過程を網羅的に掲載しているものではありませ ん。 15 © 2026 Boost Consulting, Inc.
16. Strictly confidential End of File