6 ヶ月で AI業務管理秘書を立ち上げた振り返り — 個人開発タイムラインの全部
6 ヶ月の全体マップ
連載前半の最後に、 たすきば Knowledge Relay を 6 ヶ月で立ち上げたタイムラインを、月別に振り返ります。
2025-12: 着手（構想 + 技術スタック決定）
↓
2026-01: 基盤（認証 + マルチテナント）
↓
2026-02: コア機能（プロジェクト + ナレッジ）
↓
2026-03: 提案エンジン（Voyage + pgvector）
↓
2026-04: パフォーマンス改修 + 課金基盤
↓
2026-05: 仕上げ（品質ゲート + ドキュメント）
↓
2026-06-01: リリース6 ヶ月で MVP リリース。 連載第 1 回 で書いた問題意識から、ここまでの距離を、月単位で記録しておきます。
Month 1（2025-12）— 着手
やったこと:
- vision の言語化（
docs/vision/README.mdの元） - 技術スタック調査
- 「たすきば」というサービス名決定
- Next.js + Prisma + Supabase でプロトタイプ
学んだこと:
- vision を最初に書く価値 — 後の判断軸になる
- 技術スタックは早めに決める — 後で変えると痛い
主要 ADR: ADR-0001（マルチテナント基盤）、ADR-0004（Prisma 採用）
Month 2（2026-01）— 基盤
やったこと:
- NextAuth v5 で認証
- Credentials + MFA（TOTP）
- マルチテナントの基本設計
- Service 層認可パターン確立
学んだこと:
- 認証は枯れたライブラリで OK — NextAuth で十分
- テナント越境は最初から防ぐ — 後付けでは困難
- viewerTenantId 必須化 が効く
主要 ADR: ADR-0005（二段階認可）、ADR-0009（MFA）
Month 3（2026-02）— コア機能
やったこと:
- プロジェクト CRUD
- ナレッジ / リスク / 課題 / 振り返り
- WBS / ガントチャート
- CSV インポート
学んだこと:
- コア機能こそ細部までこだわる — UI 一貫性が後の体験を決める
- テストを並行で書く — 後で書こうとすると地獄
- dialog 全画面トグル のような UX 細部
主要 ADR: ADR-0010（状態マシン）、ADR-0011（論理削除）、ADR-0017（WBS インポート）
Month 4（2026-03）— 提案エンジン
やったこと:
- Voyage AI embedding 導入
- pgvector + HNSW インデックス
- 3 軸合算スコア
- Graceful Degradation Mode
学んだこと:
- 意味検索の威力 — 全文検索とは別格
- コスト最適化 — visibility=‘draft’ は embedding 不要
- fail-safe 設計 — 外部 API 障害でも止まらない
提案エンジンの中身は、 B-2 で詳しく書いた通り です。
主要 ADR: ADR-0003（Embedding 提案エンジン）、ADR-0008（Graceful Degradation）
Month 5（2026-04）— パフォーマンス + 課金
やったこと:
- パフォーマンス改修（N+1 解消、 1.8s → 0.7s、60% 改善）
- Stripe Metered Billing 連携
- ApiCallLog 真値モデル
- DB 容量 / ファイル容量の従量課金
学んだこと:
- N+1 解消の威力 — シンプルな改善で大きな効果
- 請求 invariant の重要性 — 事業継続性の根本
- 3 レイヤ同期 の必要性（現在値 / cron snapshot / 履歴クエリ）
課金体系の細部は、 B-3 で書いた通り です。
主要 ADR: ADR-0002（per-call 課金）、ADR-0006（Stripe）、ADR-0020（DB 容量課金）
Month 6（2026-05）— 仕上げ
やったこと:
- 品質ゲート完成（5 段階: lint / tsc / test / coverage / build）
- E2E カバレッジ強制
- ドキュメント再編
- マスコット導入（M-1 で書いた通り）
- ADR-0019 課金体系改定
学んだこと:
- リリース前の最後の月は仕上げに集中 — 機能追加禁止
- マスコット導入で温度感が変わる — ブランド形成
- ドキュメント再編で保守性向上
主要 ADR: ADR-0014（CRUD 設計刷新）、ADR-0019（課金改定）、ADR-0021（ファイル容量）
累計指標
Total Stats (2025-12 〜 2026-05):
- PR 数: 450+
- コード行数: 約 40,000 行
- テスト数: 1,500+（単体）+ 100+（E2E）
- ADR: 21 本
- KDD: 16,000 行
- ドキュメント: 60+ ファイル
- 環境変数: 30+
- データテーブル: 30+個人開発で、これを 6 ヶ月で——というのが、率直なところです。
“AI 駆動なくしては無理だった”
正直に書くと、 AI 駆動なしでは 6 ヶ月リリースは不可能でした。
- コード生成: 70-80% を Claude Code が担当
- ドキュメント生成: Claude が ADR / KDD のドラフトを書く
- レビュー補助: Claude にレビュー依頼
AI が コードを書く速度を 5-10 倍 にしている感覚です。 判断は私、実行は AI 、という分担。 心理的安全性の話 で書いた「再現できる人」になるための型化が、AI と組むことで一気に楽になる、という発見もありました。
投下時間の見積もり
本業の傍ら：
- 平日夜: 1-2 時間 × 5 日 = 10 時間 / 週
- 週末: 4-6 時間 × 2 日 = 10 時間 / 週
- 合計: 20 時間 / 週
6 ヶ月 = 約 24 週 = 480 時間 。
平均的なフルタイム開発の 3 ヶ月分 の工数。AI 駆動なしなら、5-10 倍の時間がかかっていたはずです。
個人開発で大変だったこと
1. 一人で全部を判断する
設計判断 / ビジネス判断 / 法務判断、すべてを一人で。レビュアーがいない。
対策：
- ADR で判断を可視化
- Claude Code に「この判断、妥当か？」と確認
- 数日寝かせて判断
2. 集中力の維持
本業 + 個人開発で、消耗します。
対策：
- 週末は休む日を設ける
- 散漫になったら、別タスクへ
- 体調管理を最優先
3. リリースの怖さ
「ちゃんと動くか？」「バグはないか？」という不安。
対策：
- 品質ゲートで構造的に保証
- 段階的リリース（Dogfooding 期間）
- 緊急対応 SOP を準備
やってよかったこと
- vision を最初に書く — 6 ヶ月通して、判断が安定
- ADR / KDD を即時記録 — 後の自分が助かる
- AI 駆動で時間を稼ぐ — 個人で 6 ヶ月 MVP 達成
- 品質ゲートを早めに — CI が整えば後が楽
- Dogfooding — 自分で使うことで質を保つ（L-2 で詳述）
やらなくてもよかったこと
- 過剰な機能 — MVP に必要なものだけに絞るべきだった
- 早すぎる最適化 — リリース後でも遅くなかった改修も
- 完璧な UI — 細部こだわりすぎて時間消費した部分も
「何をやらないか」を最初に決める重要性を、振り返って痛感しています。
次の 6 ヶ月の予測
リリース後 6 ヶ月（2026-06 〜 11）：
- 各機能の精度改善（チャット意味検索 / 提案エンジン）
- Stripe 本接続 + 初期テナント
- Dogfooding からの改善反映
- メンバー第 1 号加入（予定）
リリースは、終わりではなく 新しい始まり です。
10 年後への接続
- 金のなる木として安定収益
- 心理的安全性の高い組織の実証
- 複数事業の原資
——その第一歩が、この 6 ヶ月の MVP です。 小さな成果が、長期の夢に繋がる 。
まとめ
| 月 | フォーカス | 成果 |
|---|---|---|
| 12 月 | 着手 | vision + 技術スタック |
| 1 月 | 基盤 | 認証 + マルチテナント |
| 2 月 | コア機能 | プロジェクト + ナレッジ |
| 3 月 | 提案エンジン | Voyage + pgvector |
| 4 月 | パフォーマンス + 課金 | 60% 改善 + Stripe |
| 5 月 | 仕上げ | 品質ゲート + マスコット |
6 ヶ月で MVP を立ち上げた、私個人の経験。 個人開発で SaaS を作りたい人への、 現実的な工数感の参考 になればうれしいです。
連載前半、ここで一区切り（＋技術補章 2 本へ続きます）
ここまで、たすきば Knowledge Relay 連載の前半 20 本にお付き合いいただき、ありがとうございました。
| 章 | 内容 | 本数 |
|---|---|---|
| A | 思想・原点ストーリー | 6 |
| B | プロダクト概要・リリース | 4 |
| K | コミュニティ・募集・文化 | 4 |
| L | リリース後・ロードマップ | 3 |
| M | マスコット（補章） | 2 |
| O | 6 ヶ月振り返り（本記事） | 1 |
| 計 | 20 |
そして連載は、 技術補章 2 本 で締めくくります。たすきばのユニークな 3 つの機能のうち、まだ深く触れていない 2 つ——
——を、明日以降の 2 日間でお届けします。技術深堀の主役は Qiita 連載に譲りますが、 ホームページ読者に向けて「何ができる SaaS なのか」が伝わる程度の濃さ で書き残しておきたいテーマです。
これで本当の前半終了。後半は、 Phase 2 / Phase 3 の進捗、Dogfooding からの気づき、メンバー加入時の話など、 状況の変化に応じて 続けていきます。
たすきば Knowledge Relay は、 プロダクトページ からいつでもご覧いただけます。Discord でも、気軽に声をかけてください。
——“たすき” を、未来へ。
関連記事
- 3 つの元画像を使い分ける設計 — 汎用 / チャット / SNS で構図を変える — 連載第 19 回・マスコット運用
- 毎日「1 時間」が蒸発していた — 私がたすきばを作った理由 — 連載第 1 回。6 ヶ月の旅の出発点
- 「10 年後の金のなる木」というシナリオ — たすきばに人生で果たしてほしいこと — 6 ヶ月の MVP が向かう先
たすきば について
たすきば Knowledge Relay は、 6 ヶ月の個人開発を経て 2026-06-01 にリリースされた業務 SaaS です。 プロダクトページ からサービス概要をご確認のうえ、お気軽にお試しください。
