はじめに
ウイスキーのテイスティングノートを記録する Web サービス「tayst whisky」を、企画から本番公開まで1人で行いました。 最初のコミットから一般公開までは約 2 ヶ月半です。
- サービス: https://whisky.tayst.jp/
- 香り・味・余韻をタグで記録し、ボトルごとの傾向をレーダーチャートで見られます。日本語と英語に対応しています
普段は業務でバックエンドエンジニアをしていますが、自分でゼロから立案して公開まで持っていくのは初めてでした。 この記事は連載の導入として、なぜ作ったか、何を決めて始めたか、どこを捨てたかをまとめます。 個々の判断は次回以降の記事で1つずつ書きます。
1. モチベーション
動機は 3 つありました。
- 自分で使いたいプロダクトをゼロから作りたかった。 ウイスキーの味は紙の「テイスティングノート」に記録するのが定番です。しかし紙は常に持ち歩くものではなく、Web 上でサッと入力できるものがあれば便利だと考えていました。
- エンジニア視点しか無かった自分に、ゼロベースで考える視点があるか確かめたかった。 何を作るか、誰に使ってもらうか、規約や問い合わせ窓口をどうするかまで含めて構築してみたいという思いがありました。
- AI を使うとどのくらいの品質と期間で公開まで行けるか見たかった。 実装だけでなく、設計の壁打ちや文書化にも AI を利用しました。
出発点は「自分が使いたいものを作る」でした。 自分 1 人が使うだけなら、認証も規約も問い合わせ窓口も要りません。ローカルで動けば十分です。
それでも公開に踏み切ったのは、同じようにウイスキーの記録に困っている人に使ってもらい、その人の時間が少しでも豊かになればよいと思ったからです。 「自分のため」で始めたものを「誰かのため」に出すと決めた時点で、やることは一気に増えました。
- 認証、利用規約とプライバシーポリシー
- 問い合わせ窓口、監視、コスト感
この連載は、これらを 1 つずつ決めながらプロダクトを公開まで持っていった話です。
正直、公開するかどうかは、かなり悩みました。 機能も見た目もまだ足りない、と思う箇所がいくつも残っていたからです。
背中を押したのは、LinkedIn 共同創業者のリード・ホフマンの言葉です。
製品の最初のバージョンで恥ずかしい思いをしていないなら、リリースが遅すぎだ
（リード・ホフマンに学ぶシリコンバレー流・意思決定の秘訣 | DIAMOND ハーバード・ビジネス・レビュー）
足りないところは公開してから直せばよい、と割り切って 2026 年 8 月 25 日に一般公開しました。
2. 初期構成として決めたこと
始める前に、次の方針を決めました。
| 方針 | 理由 |
|---|---|
| BaaS を使わない | ログインの中身を理解しないまま本番に出すのはセキュリティ面で不安でした |
| AI に書かせても、作りは自分で説明できる状態を保つ | 作りが分からないまま AI に任せる「バイブコーディング」は避けたかったです。ただし線を引いたのは設計で、コードの行までは追っていません（6 章） |
| スケール前提で、業務と同じアーキテクチャにする | ECS on Fargate と Aurora Serverless v2 から始めました。業務で扱う構成を個人でも一通り触っておきたかったからです |
| SPA と NoSQL を使わず、テーブル設計を初期から行う | 後から作り直すのが一番高くつく部分だからです |
| コストは最小にし、1 日単位で費用を見る | 個人の財布で払うので、月末にまとめて見るのでは遅いと考えました |
| 英語表示に対応する | 海外のウイスキー好きにも使ってもらえる形にしておきたかったです |
| デザインは AI と壁打ちし、コンセプトに近ければ採用する | 自分でデザインを起こす時間は取れないので、Miro の AI アプリデザイン生成を無料期間のうちに使い、一気に画面を作りました |
| 時間は本業に支障の無い範囲で使う | 1 時間でも空けば AI と対話して進めるスタイルです |
このうちいくつかは、公開までの途中で変えています。Aurora Serverless v2 は費用の理由で RDS PostgreSQL に移し、 イベント会場向けの機能だけは例外として SPA と DynamoDB を使いました。変えた理由も連載の中で書きます。
3. 採用した技術
バージョンは執筆時点のものです。
| 領域 | 採用したもの |
|---|---|
| フロントエンド | Next.js 16（App Router / SSR）、React 19、TypeScript 5、next-intl 4（多言語）、Tailwind CSS 4、Recharts 3（レーダーチャート） |
| バックエンド | Ruby 4.0、Ruby on Rails 8.1（API モード）、PostgreSQL 17、Mobility（DB の多言語化）、Solid Cache |
| 認証 | Logto（一般利用者向け IDaaS）、Amazon Cognito（運営者向け） |
| テストと静的解析 | RSpec 8、Vitest 4、ESLint 9、Prettier 3 |
| ソース管理と CI/CD | GitHub、GitHub Actions、ecspresso v2 |
| インフラ | AWS（ECS on Fargate、CloudFront、ALB、RDS、Lambda、DynamoDB）、Terraform 1.11 以上 |
| 監視 | Sentry、CloudWatch アラーム + SNS |
| 開発環境 | Docker Compose（Node 22 / Ruby / PostgreSQL / DynamoDB Local） |
| ドキュメント | tbls（DB スキーマの自動生成）、draw.io（構成図）、Swagger UI（API） |
| AI | Claude Code（実装・設計の壁打ち・文書化） |
4. 工夫した点
| 工夫 | 内容 |
|---|---|
| ADR（アーキテクチャ決定記録）を最初から書く | 公開時点で 91 本、執筆時点で 98 本になりました。AI と壁打ちした結果を「なぜそう決めたか」の形で残すと、次のセッションの AI にも自分にも効きました |
| tech-note を書く | 技術のキャッチアップ用のメモをリポジトリに置き、ADR とは分けています |
| 管理画面は作り込まない | 最初は DB を直接見ていましたが限界が来て、途中で運営者向けの管理画面を足しました。見た目は OSS のテンプレート、ログインは Cognito（数人なら $0）に寄せ、自作は最小にしています |
| STG 環境を用意し、業務と同じフローにする | ローカルで通したものを STG に出し、手で触ってから本番にタグを打ちます |
| AWS Organizations で環境ごとにアカウントを分ける | 管理アカウントの下に STG と本番のアカウントを持ち、請求はまとめて費用は環境ごとに見ます |
| AWS Well-Architected の 6 本の柱で判断を点検する | 公式ツールは通していませんが、どの柱に効く判断か、どの柱を意図的に落とすかを ADR に残しています。対応表は連載 2 本目に載せます |
| Claude Code が読む文書を、Claude Code にレビューさせて直す | 毎回読み込まれる CLAUDE.md が肥大したので、索引を 1 行 1 文に圧縮して 70KB から 23KB にしました。後日、スキルが実在しない構造を指示していたのも見つかり、4 つの CLAUDE.md と 9 つのスキルの正を 1 つに揃えました |
| コミット前フックで文書の更新漏れを止める | コードだけ変えて文書を触っていないコミットや、ADR を足して索引を更新していないコミットを、フックが止めます |
5. 品質はどう担保したか
「AI でどのくらいの品質で公開できるか」を見るために、品質は 3 つの層で考えました。
| 概要 | 内容 |
|---|---|
| 自動で止める | フロント・バックエンドともに単体テスト（合計 1,600 例前後）とリンターを整備し、push 前のフックでテストを回します |
| 人が確認する | STG で手動で動作確認してから本番に出します |
| 出たあとに気づく | Sentry のエラー通知と CloudWatch のアラームをメールで受けます |
6. 逆に、捨てたもの
全部をやろうとはしていません。やらなかったこと、なぜ捨てたか、代わりに何で受けたかを書いておきます。
| 捨てたもの | なぜ捨てたか | 代わりに何で受けたか |
|---|---|---|
| AI 同士のレビュー | ADR には残していない、自分の判断です。1 人開発でレビューの往復に時間をかけるより、テストとフックで機械的に止めるほうが割に合うと考えました | 正直に言うと、実装は細かく読まず、動作と設計意図が合っていれば取り込んでいました。設計は ADR と壁打ちで押さえ、コードはテストとフックと STG の手触りに任せています |
| E2E テスト | async な Server Component は Vitest / Jest で直接テストできず、単体テストの範囲を lib/ と Client Component に絞りました。E2E は将来の課題として残しています | STG で手で触る確認に寄せました |
| CI でのテスト実行 | 開発者が 1 人のうちは GitHub Actions に課金してまでクラウドで回す必要が無いと判断しました | push 前のフックが、変更のあったサービスのテストだけを Docker の中で回します |
| APM（アプリ性能監視） | Datadog を入れたものの APM は一度も有効にせず、固定費でコンテナのメトリクスを送るだけになっていました。Agent は NAT 経由で常時送信するので、静かな時間にも払います | 一度入れて止めました。本番は CloudWatch のアラームと Sentry のメールだけです。戻す条件は「実利用者がいて、原因不明の遅さが 2 回起きたら」 |
| DB の Multi-AZ | インスタンス代が $18 → $36 と倍になり、Aurora から移して削った分の半分が消えます。Single-AZ の代償はインスタンス障害で数分〜数十分の停止で、データは gp3 と日次バックアップ、PITR で守れます | Single-AZ の小さなインスタンスにし、復旧手順を runbook に書きました |
| 常時稼働のジョブワーカー | Solid Queue を動かすには専用 DB とスキーマの読み込み、ロールの分離が必要で、ECS サービスが 1 つ増えて費用と監視の対象も増えます。非同期にしたい処理は JSON の書き出しと数個の S3 PutObject で、年に数十回しか走りません | 重い処理は同期実行にし、ワーカーは置いていません。遅くなったらまずアップロードの並列化で受けます |
いずれも「利用者が増えたら戻す条件」を ADR に書いてあり、今は意図的に払っていない状態です。
7. 数字で見た公開まで
| 項目 | 値 |
|---|---|
| 最初のコミットから一般公開まで | 約 2 ヶ月半（2026 年 6 月 7 日 → 8 月 25 日） |
| コミット数（main） | 約 250 |
| マージした Pull Request 数 | 約 155 |
| ADR 数 | 91 本（執筆時点では 98 本） |
Claude Code のプランは途中で上げた
Claude Code は Pro プランで始めました。 しかし進めるうちに利用上限に当たる回数が増え、上限が戻るまで手が止まる時間のほうが長くなりました。
「1 時間でも空けば AI と対話して進める」というスタイルは、空いた時間に上限で止められると成り立ちません。 公開までの期限を優先して、途中で Max（5x）プランに切り替えました。
| プラン | 使い方 | 困ったこと |
|---|---|---|
| Pro | 立ち上げ期。小さな実装と壁打ち | 設計の壁打ちと実装を同じ日にやると上限に当たる |
| Max（5x） | 途中から公開まで | 上限で止まることはほぼ無くなった |
AI で個人プロダクトを公開まで持っていくなら、AI のプラン代も AWS と同じく「払う費用」として最初から見ておくべきでした。
8. 連載の予定
- 個人プロダクトを自ら立案して、公開まで実施した話（本記事）
- BaaS を使わず、業務と同じ構成を選んだ理由
- AWS 費用を 1 日単位で見て削った話
- Claude Code が読む文書を、Claude Code にレビューさせて直した話
- 原則 RDBMS、イベントだけサーバーレスにした話
- ADR と tech-note で、人間と AI の意思決定を残す
- 認証を Auth0 で始めて、STG に出す段階で Logto に乗り換えた話
- Datadog で始めた監視を止め、Sentry と CloudWatch アラームに落ち着いた話
- STG を挟んだら、本番構築が STG のレビューになった話
- Rails の DB ユーザーを操作用とマイグレート用に分けた話
- タグ入力をフレーバーホイールに置き換えた話
- GA4 と Clarity を Cookie 同意バナー無しで入れた話
- デザインを AI で一気に作り、あとから育てた話
おわりに
「AI があれば個人でも業務水準の構成で公開まで行ける」というのが、やってみた実感です。 ただし、どこを捨てるかを自分で決めないと、時間も費用も際限なく増えます。
同じように個人プロダクトを公開まで持っていきたい方の参考になれば嬉しいです。
