マイクロSaaSの技術スタックは、1年でこう変わった
目次
ノーコードからAIネイティブへ。1年の技術選定を、当時のコミットでたどる
PentaTrail は、この1年で技術スタックを丸ごと作り替えました。
といっても、確固たる計画があったわけではありません。長くやってきたセキュリティの経験を、急速に進む AI 技術の潮流にどう合わせていけばいいのか ── 正直、先がどうなるかも分からないまま、暗中模索で、糸を手繰るように進めてきた結果です。要件定義も設計も実装も混在したまま、何を残し何を捨てるかをその都度考え、「これは合わない」と気づくたびに乗り換えてきた ── その足あとが、当時のコミットやファイルに残っています。大きく3つの章に分けて、淡々と振り返ります。
第1章 ── Microsoft とノーコードで始めた（2025年4月〜7月）
最初は、Microsoft のノーコード基盤で組んでいました。Power Platform、Dataverse、そして Azure。
良い面は確かにありました。UI を中心に、画面から設計を進められる。 何を作るかが目に見えるので、立ち上がりは速い。
ただ、使い込むほどに、構造的な限界が見えてきました。
- 人間が前提 ＝ 人間がボトルネックになる。 ノーコードは「人が画面で操作する」ことを前提に作られています。作業を自動化したり、AI に肩代わりさせたりする方向とは、根っこで逆を向いていました。
- 設定管理やバックアップの仕組みが弱い。 コードのように差分を取り、履歴をたどり、壊れたら戻す ── その当たり前がやりにくい。
- DB のカラム名がブラックボックス。 Dataverse は内部のカラム名を自動生成します。人が画面で触る分には困らなくても、生成 AI にコードを書かせようとすると、その名前が分からない・予測できない。ここが致命的に相性が悪かった。
- 認証を含む連携の実装が大変。 外部サービスや認証システムとつなぐ段になると、ノーコードの枠の中で苦労ばかりが増えていきました。
Azure についても、実際に触ってみて分かったことがあります。マイクロSaaS には細かすぎる、ということでした。設定の粒度も運用の前提も、最低でも複数人のエンジニアチームで開発・運用することを想定して作られている。少人数で、しかも運用を AI に寄せていきたい立場には、明らかに重すぎました。良し悪しの話ではなく、想定している規模が、そもそも違っていたのです。
象徴的だったのは、当時の開発の仕方です。web 版の ChatGPT や Claude にソースコードをコピペし、返ってきた生成結果を VSCode に戻して git で管理する ── AI への指示も、結果のとりまとめも、人間が手作業で行うアプローチでした。
ただ、当時の ChatGPT や Claude は、今ほどの性能ではありませんでした。こちらの意図を十分に汲めず、AI が勝手に思い込んだ仕様で作り込んでしまう。出てきたコードは単体ではそれらしく動くのに、いざ既存のものと結合しようとすると噛み合わない。手戻り → 修正 → また手戻り、の繰り返しでした。
AI に頼りたいのに、AI もまだ未熟で、足元のノーコード基盤も AI を活かせない ── 第1章は、その二重のもどかしさの時期でした。この食い違いが、次の一歩につながります。
第2章 ── Supabase / Vercel へ全面移行（2025年7月〜）
ノーコードの限界を感じて、それまで作ってきたものをすべて捨てる覚悟で、「AI 時代にマッチする基盤技術は何か」を模索し始めました。
たどり着いたのが、Supabase と Vercel でした。2025年7月、「Supabase + Vercel」と題した最初のコミットで、リポジトリを新しく切り直す。土台を、ノーコードから、AI フレンドリーな完全コードベースの基盤へ置き換えていったのです。
Supabase を選んだ理由は、はっきりしていました。
- オープンソースの PostgreSQL がベース。 枯れた標準技術なので、生成 AI が知識を豊富に持っていて相性がいい。第1章で苦しんだ「カラム名がブラックボックス」のちょうど逆で、スキーマを完全に握れます。
- 認証システムがビルトイン。 認証の土台が最初から入っていて、一から作らずに済む。
- Vercel との公式連携。 フロントの Next.js と相性のよい Vercel が、Supabase と公式にサポートされた形でつながる。
決済は、デファクトスタンダードの Stripe を採用しました。Checkout も顧客ポータルも Webhook も一通り揃っていて、Supabase との連携実績も豊富。ここは奇をてらわず、実績のある定番に乗るのが正解でした。
基盤は固まっても、開発そのものはまだ綱渡りでした。この頃は Claude や Codex を CLI で使い続けていたものの、セッションをまたぐと文脈が途切れてしまう ── その継続性の弱さに、ずっと足を取られていたのです。一貫した開発を続けるのが難しく、認証をはじめ、あちこちで“どはまり”する日々が続きました。この手詰まりが動き出すのは、次の章です。
第3章 ── AIネイティブへ（2026年2月〜）
本当の転機は、開発そのものを AI に寄せ始めたところでした。その前段として、2025年10月ごろに“バイブコーディング（vibe coding）”という言葉を知り、同じ志の個人開発者をフォローし始めていました。とりたてて突飛な動きではなく、大きな流れの中の一人なのだと感じ始めた頃です。
そして2026年2月、.claude/skills を置いて、繰り返す作業を“スキル”として定義し始めました。スキルというのは、AI に毎回読ませる“手順書”です。たとえば ── レビューの回し方（どの観点で、何を確認するか）、リリースの段取り（コミットからプルリクエスト、レビュー、マージまで）、仕様を固めてから計画に落とし、実装するまでの流れ。それまで頭の中にあった“進め方のコツ”を、AI がそのとおりに再現できる手順へ書き出していきました。属人的だった作業が、再現可能な手順に変わっていきます。
4月には memory の運用を始めました。セッションをまたいで残る、事実の置き場です。ここに置くのは ── プロジェクト固有のコーディング規約、いま何がどこまで進んでいるかの状態、そして何より、過去にやらかした失敗とその教訓です。「この書き方をすると、ここで壊れる」「この前提は間違っていた」── そうした学びを書き残しておくと、次のセッションの AI が、同じ罠を踏まなくなります。AI に毎回ゼロから説明し直す、という消耗も、ここで大きく減りました。
ここから、アウトプットが目に見えて変わっていきます。マージ済みの PR 数で見ると ──
| 月 | マージ済み PR |
|---|---|
| 2026年2月 | 3 |
| 3月 | 10 |
| 4月 | 178 |
| 5月 | 274 |
| 6月 | 250（月の途中まで） |
この跳ね上がりは、体制を大きくしたからでも、スキルとメモリだけで起きたものでもありません。効いたのは、AI ワークフロー全体の成熟でした。スキルとメモリを足場に、開発の各工程が順に AI 前提へ移っていきます ── MCP で実環境を触らせ、仕様を計画（plan）に落として auto モードで自走させ、pgTAP や vitest による TDD で検証し、別系統の AI を突き合わせる二段レビューを回し、CI と品質ゲートで全体を担保する（どれも、それぞれ独立した記事になる話で、追って個別に書いていきます）。第1章で味わった「手戻りの繰り返し」も様変わりし、AI が思い込みで突っ走る頻度は大きく減りました。
伸びたのは、LLM そのものの賢さだけではありません。それを動かすハーネスや周辺ツール（スキル、メモリ、MCP、plan/auto、レビューやテストの仕組み）の進化が、同じくらい大きかった。とりわけ2026年2月以降、Claude まわりの進化はすさまじく、同じモデルでも、持たせる道具と段取り次第で、出せるものがまるで変わる。Supabase が良かった、Vercel が速かったのも事実ですが、決定打は個別のライブラリ選定ではなく、進め方とその道具立てが、まるごと成熟したこと ── 同じ人間が同じ時間で桁違いの量を出せるようになった理由は、そこにあります。
この作り方の現物
こうして1年、作り替えながら出荷し続けているマイクロSaaS が、PentaTrail です。外から見える攻撃面を AI で継続的に把握する、CTEM のサービスです。
もしよければ、あなたの会社の「外から見える攻撃面」を、一度のぞいてみてください。