マイクロSaaSの技術スタックは、1年でこう変わった

PentaTrailは、この1年で技術スタックを丸ごと作り替えました。

といっても、確固たる計画があったわけではありません。長くやってきたセキュリティの経験を、急速に進むAIの潮流にどう合わせるのか。作っては確かめる進め方で、何を残して何を捨てるかをその都度考え、「これは合わない」と気づくたびに乗り換えてきました。その足跡を大きく3つに分けて振り返ります。

第1章：Microsoftとノーコードで始めた（2025年4月〜7月）

最初はMicrosoftのノーコード基盤で組んでいて、使ったのはPower Platform、Dataverse、Azureです。

良い面は確かにありました。UIを中心に画面から設計を進められて、何を作るかが目に見えるので立ち上がりも速いです。ただ、使い込むほどに構造的な限界が見えてきました。

• 人間が前提で、人間がボトルネックになります。ノーコードは「人が画面で操作する」ことを前提に作られていて、作業を自動化したりAIに肩代わりさせたりする方向とは、根っこで逆を向いていました。
• 設定管理やバックアップの仕組みが弱く、コードのように差分を取り、履歴をたどり、壊れたら戻すという当たり前が、やりにくいのです。
• DBのカラム名がブラックボックスです。Dataverseは内部のカラム名を自動生成するので、人が画面で触る分には困りませんが、生成AIにコードを書かせようとすると名前が分からず、予測もできません。ここが致命的でした。
• 認証まわりの連携が大変です。外部サービスや認証システムとつなぐところで、ノーコードの枠に収めようとするほど苦労が増えていきました。

Azureも実際に触ってみると、マイクロSaaSには細かすぎました。設定の粒度も運用の前提も、最低でも複数人のエンジニアチームで開発・運用することを想定して作られており、少人数で、しかも運用をAIに寄せていきたい立場には明らかに重すぎます。良し悪しの話ではなく、想定している規模がそもそも違っていたのです。

また、いまでは考えられないことですが、1年前は、Web版のChatGPTやClaudeにソースコードをコピペし、返ってきた生成結果をVSCodeに戻してgitで管理していました。指示も結果のとりまとめも人間の手作業です。ChatGPTやClaudeも、今ほどの性能ではありませんでした。こちらの意図を十分に汲めず、AIが勝手に思い込んだ仕様で作り込んでいきます。出てきたコードは単体ではそれらしく動くのに、いざ既存のものと結合しようとすると噛み合わず、手戻りと修正を何度も繰り返す日々でした。

AIに頼りたいのにAIもまだ未熟で、足元のノーコード基盤もAIを活かせません。二重のもどかしさを抱えたまま、次の一歩に進みます。

第2章：Supabase / Vercelへ全面移行（2025年7月〜）

ノーコードの限界を感じて、それまで作ってきたものを一度手放すつもりで、「AI時代に合う基盤技術は何か」を探し始めました。

たどり着いたのがSupabaseとVercelです。2025年7月、「Supabase + Vercel」と題した最初のコミットでリポジトリを新しく切り直し、土台をノーコードからAIフレンドリーな完全コードベースの基盤へ置き換えていきました。

Supabaseを選んだ理由は、はっきりしていました。

• ベースがオープンソースのPostgreSQLです。枯れた標準技術なので生成AIが知識を豊富に持っていて相性がよく、第1章で苦しんだ「カラム名がブラックボックス」のちょうど逆で、スキーマを完全に握れます。
• 認証の土台が最初から入っているため、一から作る必要がありません。
• Next.jsの開発元が出しているVercelと、公式にサポートされた形でつながります。

決済は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が同じ罠を踏まなくなり、毎回ゼロから説明し直す消耗も大きく減りました。

アウトプットは、ここから目に見えて変わります。マージ済みのプルリクエスト（PR）の数で見ると、はっきりしています。

表1：月別のマージ済みPR数

この跳ね上がりは、体制を大きくしたからでも、スキルとメモリだけで起きたものでもありません。効いたのは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のサービスです。

PentaTrail / CTEM を見る