Claude Code で変わる SaaS 開発 — 何を任せ、どこで止めるか

WEBサイト制作と SaaS 開発で、Claude Code の使い方は何が一番変わりましたか？

一番変わるのは、"どこまで一息に任せて良いか" の距離感 です。

WEBサイト、たとえば Venture Quest のようなケースでは、デザインシステムとコンテンツモデルさえ明文化しておけば、新しいページやコンポーネントはかなり大胆に任せられます。影響範囲が閉じていて、ミスがあってもロールバックしやすい。いわば壊しても直せる領域が多い。

SaaS は真逆です。DB スキーマ、認証フロー、課金ロジック、マルチテナント境界——ここは一度壊すと、ユーザーデータや売上に直接傷がつく領域です。AI にとってはただの「テーブルを1つ追加するマイグレーション」でも、開発責任者から見ると監査・バックアップ・ロールバック計画まで含めた意思決定の塊になる。

だから SaaS では、Claude Code の出力をそのまま走らせる範囲を意図的に狭めています。具体的には、「書かせる」「提案させる」「検証させる」までは AI に任せ、「実行する」のハンドルは人間が握る。特にマイグレーションや本番に近い環境への適用は、必ずエンジニアがレビューしてから手動でトリガーする運用にしています。

もう1つの違いは、コンテキストの寿命 です。WEBサイトのコンポーネントはその場で読み切れる細かさのものが多いですが、SaaS のドメインロジックは半年・1年スパンで積み重なり、既存データや既存契約と整合を取り続ける必要があります。AI に渡すべき文脈が、単一ファイルや PR の中には収まらなくなる。結果、「AI に読ませるべき設計ドキュメントを、プロダクト側でどう整備し続けるか」という運用が、WEBサイト制作以上に重たくなります。

SaaS 開発の中で、Claude Code が一番効いている工程はどこですか？

僕の肌感として、以下の4工程で明確に費用対効果が出ています。

1. 最初の土台づくりと、必須だが地味な実装

認証、権限チェック、マルチテナント境界、監査ログ、メールテンプレート、Webhook ハンドラ——SaaS にはやって当然だけれど書くのが面倒な土台仕事が大量にあります。この領域は型定義と規約さえ整えれば、Claude Code が質の安定した初期実装を出してくれる。もちろん、そのままマージすることはなく、必ず人間のレビューを通します。

開発責任者の視点で言うと、ここで浮いた時間は、そのままドメインロジックの設計や UX 検証に回せる。差別化につながる領域にエンジニアのリソースを集中できるのは大きい。

2. バックエンドのリファクタリングと型安全化

SaaS は機能追加を重ねるほどコードが腐りやすい。特にバックエンドは、動いているから触りたくない関数が積み上がる。ここに Claude Code を投入して、「このモジュールの責務を分割してほしい」「any を排除してほしい」と依頼すると、影響範囲付きの修正案が返ってくる。

人間だけでやっていた頃は、怖くて着手できなかった領域に手が入るようになった。負債の返済サイクルが明らかに速くなったのは、SaaS ではかなり効きます。

3. テスト・エッジケースの網羅

これは SaaS 固有の効き方です。AI は、人間が見落としがちな境界条件（空配列、null、タイムゾーン、権限が中途半端な状態のユーザーなど）をかなり丁寧に挙げてくれる。テストケースの網羅性を上げる相棒として優秀です。

「このハンドラのテストを、セキュリティ観点で穴がないか見直してほしい」と投げるだけで、未カバーのケースを挙げ、テストコードまで書いてくれる。QA の初期段階が確実に速くなりました。

最近はさらに一歩進めて、「実装したエージェントとは別のエージェントに、成果物だけを見て採点させる」というやり方も試しています。実装の経緯を共有していない "別の目" に評価させると、実装した側の思い込みに引っ張られない指摘が返ってくる。人間のレビュアーが最初に見る前に、もう1段フィルターを挟むイメージです。

4. 運用ドキュメントと Runbook の整備

SaaS は障害対応や問い合わせ対応の Runbook、導入支援資料、API ドキュメントなど、コード以外の文書量が膨大です。これを Claude Code にコードから半自動で生成させるワークフローを敷いています。

ドキュメントは書く時点で古くなる、という SaaS あるあるを、「コードと同じリポジトリで AI に再生成させる」運用で緩和している。地味ですが、開発チームの運用コストに直結する領域です。

逆に、SaaS 開発で「AI に任せない」と明確に決めている領域はありますか？

かなり厳密に線を引いています。ここは WEBサイト制作より踏み込んで運用ルール化しています。

AI に生成・提案はさせるが、実行は必ず人間が行う領域:

• 本番データベースへのマイグレーション適用
• 決済・課金まわりの金額計算ロジックの変更
• 認証・認可ルールの更新（特にロール・権限マトリクス）
• 個人情報・機微情報のスキーマ変更や移送
• 外部公開 API の破壊的変更
• 本番環境への自動デプロイ

これらは「AI が正しく書けるかどうか」の問題ではなく、壊れた時の影響範囲が大きすぎる という、組織としての判断です。仮に AI が 99% 正しくても、1% の事故がユーザーの信用を壊す。だからハンドルは人間に残す。

AI にすら読ませない／書かせない領域:

• 本番シークレット・API キー・顧客データそのもの
• 監査ログの出力・保全に関わる実装
• 法務レビュー前の利用規約・プライバシーポリシー本文

ここは情報ガバナンスの問題なので、ルールとしてリポジトリ側で分離し、Claude Code の参照範囲からも外しています。

監査ログについて補足すると、そもそも書き換えや削除ができない設計にしておくのが前提です。追記専用のストアに出力し、保持期限による失効はプラットフォーム側の仕組みに任せる。「AI に書かせない」以前に、人間も含めて誰も後から書き換えられない状態にしておく——順序としてはこちらが先です。

最近変えたのは、この線引きを「レビュアーの意識」だけに預けるのをやめたことです。以前は PR テンプレートでのチェックとエンジニアの注意力が最後の砦でした。でも人間は疲れるし見落とす。幸い、この1年でエージェント側にも、特定の操作を検知してその場で止める仕組み（実行前のフック、ファイルシステムやネットワークを隔離したサンドボックス実行、権限を細かく分離できるモードなど）が整ってきています。だから今は、「本番マイグレーションの実行コマンドや本番デプロイの権限は、そもそも AI エージェントの手が届かない場所に置く」という形で、組織のルールとツールの設定の両方に同じ線引きを二重に埋め込むようにしています。規律を人間の記憶力だけに頼らない、という発想への転換です。

僕が開発責任者として意識しているのは、「AI の性能が上がるほど、"止める線" を先に決めておく重要性が増す」 ということです。性能が上がると任せたくなる。でも SaaS では、任せてよい範囲を広げる前に、任せないと決めた領域を先に固める——これがないと、いつか取り返しのつかない事故が起きます。

SaaS 特有のコンテキスト管理はどう設計していますか？

SaaS の規模が大きくなるにつれて、AI が参照すべき情報が急激に増えます。WEBサイト制作と違い、「プロジェクト全体を読み込ませれば良い」という戦略が成り立たなくなる。ここは意図的に設計しています。

ポイントは3つあります。

1. レイヤーごとのルールファイル分割

プロジェクトルートの CLAUDE.md をエントリーポイントにしつつ、`domain/`、`infra/`、`api/`、`ui/` のようにレイヤーごとにルールファイルを分けています。

ここで効いてくるのが「置き方」です。ルートのファイルからレイヤー別ルールをすべてインポートしてしまうと、分割した意味がなくなって結局は毎回全部が読み込まれる。そうではなく、各レイヤーのディレクトリ側にルールファイルを置き、そのレイヤーのコードを触るときにだけ読み込ませる構成にしています。全部を一度に読ませると精度が落ちるので、依頼に応じて読ませる文脈を絞るのが SaaS では効きます。

最近は、この分割をさらに活かして、複数のエージェントをレイヤーごとに並行して走らせる使い方も増やしています。ドメイン層を担当するエージェントと API 層を担当するエージェントを同時に走らせ、最後に人間が全体の整合性をレビューする。文脈を絞る設計をあらかじめ済ませてあるからこそ、並行させても事故が起きにくい、という感覚があります。

2. 設計の決定事項を Architecture Decision Record (ADR) として残す

「なぜこの技術を選んだのか」「なぜこのテーブル設計にしたのか」を ADR として残し、Claude Code にも参照させる。これをやっておかないと、AI はその時点で最新のベストプラクティスを勝手に提案してきて、既存の設計方針と食い違う提案が混ざります。開発チーム全体にとっても、意思決定の履歴が残るのは大きいです。

3. ドメインの用語集を明示する

SaaS はドメイン言語（ユビキタス言語）がプロダクトの差別化そのものです。「ユーザー」と「メンバー」と「アカウント」と「ワークスペース」を、どういう意味で使い分けているか——ここがブレると、AI が生成するコードも一気に散らかる。用語集を明文化し、Claude Code に毎回参照させています。

この3つは、僕自身、「AI のために整える作業が、そのまま組織の設計書の整備になる」 典型例だと感じています。新しいメンバーを採用するときの受け入れ資料としても使える。二重投資になりません。

導入前後で、SaaS 開発のスピード・品質・コスト構造はどう変わりましたか？

案件の複雑さや要件の固まり具合によって差はありますが、体感としての変化をお話しします。

• 機能追加のリードタイム: 企画から本番リリースまでにかかる期間は、条件が揃っているケースではかなり圧縮されています。ただし、これはドメインの複雑さや既存コードとの依存関係に左右されるため、一律に何%と言い切れるものではありません
• レビュー指摘・CI 検出の件数: 規約違反・型エラー・テスト漏れによる差し戻しは、体感としてはっきり減りました。ただしこれは、検出の仕組み自体を変えていない前提での比較です
• 負債返済のサイクル: 以前は四半期に1回のリファクタリングスプリントだったものが、機能追加と同時並行で日常的に回せるようになった

一方で、これは楽観だけの話ではありません。New Relic が 2026 年に公表した調査では、AI 生成コードをソフトウェア開発に利用している米国の中堅上位・大企業の技術リーダー200名のうち、82% が「過去半年に AI 生成コードに関連する本番障害を経験した」と回答しています。内訳として挙がっているのは、統合の失敗（30%）、コンプライアンス上の問題（30%）、データ完全性の問題（29%）、セキュリティ脆弱性の混入（28%）です。

この数字は、読み方に注意が必要だと思っています。調査対象は米国企業全体ではなく、すでに生成AI・エージェンティックAIを開発に組み込んでいる従業員500名以上の企業のマネージャー職以上に限られていて、回答も自己申告です。だから「業界全体で8割が事故を起こしている」と読むのは誤りです。ただ、AI コーディングを最も本格的に使っている企業層で、この頻度で本番障害が報告されているという事実のほうを、僕は重く見ています。ツールへの習熟度が高いことは、事故が起きないことの担保にはならない、ということです。AI の生成能力が上がるスピードに、使う側のガバナンスが追いついていない——そう捉えています。うちの数字が良い方向に振れているとすれば、それは AI の性能差ではなく、Q3 でお話しした「止める線」と、レビュー観点を先に固めてきたことの結果だと考えています。

ただ、僕が強調したいのは、スピードだけが上がったわけではないという点です。正確には、守りの工程の品質が底上げされたことで、攻めに回せる余力が増えた。テスト、リファクタ、ドキュメント、監視設定——SaaS において事故を防ぐための地味な工程を、AI が肩代わりしてくれた結果、エンジニアが差別化領域に集中できるようになった、という構造変化です。

コスト構造で言えば、開発チームの採用方針を見直しました。「とにかく人数を増やす」発想から、「少数精鋭 × AI をうまく使う」を前提に組織設計する方向に舵を切っています。

SaaS 特有の失敗談やヒヤリハットはありますか？

あります。ここは WEBサイト実装編よりも踏み込んでお話しします。

1. マイグレーションの整合性への警告を AI が出していたのに、見逃しかけた

以前、スキーマ変更をステージング環境に適用した際、Claude Code が「既存データとの整合性に懸念がある」と警告を出したことがありました。適用自体は人間がトリガーしているので手順違反ではないのですが、問題はその警告が、その後の PR レビューでも十分に重く扱われないまま本番適用の直前まで進んでいたことです。最後に止めたのは、Q1 で話した「本番への適用は、必ず人間がレビューして手動でトリガーする」という運用でした。適用前の確認で警告の内容を精査し、既存データの一部が不整合になり得ると判断して、適用を見送った。ゲートは設計どおりに機能しましたが、AI の警告の扱いが最後の確認者の注意力に依存していたことは、そのままにできない課題でした。

この経験から、AI の警告は PR テンプレート上で「明示的にチェックさせる項目」として扱う ようにしました。AI が黙るか喋るかに任せず、警告があったかどうか自体を人間が確認する運用にした、ということです。ただ、チェック項目はあくまで人間の注意力に頼る仕組みです。Q3 で話した「規律を人間の記憶力だけに頼らない」という転換は、こうした経験の積み重ねの上にあります。

2. 認可ロジックは、AI が最も見落としやすい領域だと割り切った

これは特定の出来事というより、マルチテナント SaaS ならどこでも起こり得る失敗パターンとして話します。AI は綺麗なコードを書きます。型も揃っていて、テストも通る。それでも、テナント境界を跨いだ特殊な呼び出し経路——「このコードは、どのテナントから呼ばれ得るか」という文脈は、コードベースだけからは読み取れません。だから権限チェックの漏れは、AI 生成コードで最も残りやすい穴の1つになります。

そこで当社では、認可まわりは必ず "逆向きのテスト"（本来アクセスできないはずのケースをテストする）を、AI にも人間にも書かせることをルールにしています。SaaS では基本中の基本である「ポジティブテストだけでは不十分」という点を、チームの共通認識で終わらせず、明文の運用ルールに落とし込んでいます。

3. 既存の設計方針と衝突する「より良い提案」に引っ張られた

Claude Code はしばしば、「こうしたほうがモダンです」という提案をくれます。個別には正しいことが多い。でも SaaS では、既存コードベースとの一貫性のほうが、モダンさより遥かに重要です。

初期に、チームとして Claude Code の提案を十分に吟味しないまま取り込んでしまい、コードベース全体の設計思想と衝突する書き方が混ざってしまった時期がありました。局所的には妥当でも、アーキテクチャ全体の一貫性を損なう状態になり、結果としてリファクタリングの工数が増えてしまいました。

対策は、ADR とコーディング規約を強く当てる こと。AI の提案を採用する前に「この提案は現在の設計方針と整合するか？」を必ず問い直す、というレビュー観点をチームに徹底させました。

余談ですが、これは当社に限った話ではありません。2026年に入ってからも、AI エージェントが本番のデータベースやストレージを消してしまう事故が、海外のスタートアップで公になっています。2026年4月に公表された事例では、コーディングエージェントがステージング環境の不整合を解消しようとして本番のストレージボリュームを削除し、同じボリュームに保存されていたバックアップまで、わずか数秒で一緒に消えました（このケースは事業者側の対応で後日復旧しましたが、自力で戻せる最新のバックアップは3ヶ月前のものだったと報じられています）。

この事例で注目すべき点は2つあります。1つは、エージェントが自分に与えられていたルールに違反していたこと。事後のログには、「破壊的で不可逆な操作は、ユーザーが明示的に要求しない限り実行してはならない」と自分のルールに明記されていた、という趣旨の記述が残っています。つまり、指示さえ正しく書いておけば逸脱しない、という前提は成り立たない。ここは、AI を任せる側が一番誤解しやすいところだと思います。

もう1つは、それでも実行できてしまった理由が、AI を入れる前から存在していた設計上の隙だったことです。限定用途で発行したはずの API トークンが、破壊的操作まで含むスコープを持っていた。そのトークンが、タスクとは無関係なファイルに置かれたままリポジトリの中にあった。バックアップが本番データと同じ削除範囲に入っていた。本番とステージングの分離も不十分だった——どれも AI 固有の弱点ではなく、以前から存在していた穴です。

だからこそ、指示で縛るのではなく権限で縛る。権限設計とバックアップ設計は、AI に何を任せるかを決めるより前に、人間が固めておくべき領域だと改めて感じています。

SaaS 開発にこれから Claude Code を入れるスタートアップへのアドバイスは？

WEBサイト実装編でも5つお話ししましたが、SaaS 開発ではさらに重要な観点が4つあります。

1つ目。「バイブコーディングだけでは SaaS は作れない」と最初に線を引く。
これは全ての前提です。Claude Code を使えば、極端な話、自分で1行も書かなくても "それっぽく動くプロダクト" は立ち上がります。デモ画面や社内 PoC ならそれで十分です。しかし SaaS は顧客のデータ・お金・信頼を預かる仕組みなので、「AI に正しく指示を出す知識」「返ってきたコードの問題点に気づける目」「壊れた時の影響を想像できる経験」 の3つが欠けたままリリースすると、初期は動いていたものが半年後に崩れます。データ不整合、セキュリティホール、規模拡大時の破綻、法令違反——いずれもリリース直後には気づけず、気づいた時には顧客側で被害が出ているタイプの事故です。開発責任者として、"誰でも作れる" と "SaaS として売れる" はまったく別物だ、という認識をまず社内で揃えてください。Claude Code の導入判断より先に、返ってきたコードとそのリスクを評価できる体制がチームにあるかを確認してください。

2つ目。「任せない領域」を先に決めてから導入する。
SaaS は壊れた時の影響が大きい領域が散在しているので、「ここは AI に書かせても実行は人間」というラインを、マイグレーション・課金・認可・本番デプロイについて先に明文化してください。ここを曖昧に始めると、事故が起きた時の復旧コストが跳ね上がります。これは1つ目の「知識がないまま任せる」という事故を、運用レイヤーでも二重に防ぐためのガードレールです。付け加えると、このラインは「意識づけ」だけで終わらせず、権限設定やエージェントの実行制御の仕組みでも同時に固定することをお勧めします。ただし、フックや実行制御の設定はあくまで多層防御の一枚であって、それ自体が完全な保証にはなりません。最後に効くのは、Q3 で触れたとおり 破壊的な操作ができる資格情報を、そもそもエージェントの手が届く場所に置かない という権限分離のほうです。

3つ目。AI 向けのドキュメント整備を、機能開発と同じ比重で予算化する。
SaaS では CLAUDE.md / ADR / 用語集 / Runbook のメンテナンスが、AI の精度に直結します。「機能実装が忙しいからドキュメントは後回し」にすると、半年後に AI の精度がじわじわ落ちて、誰も気づかないまま開発速度が鈍化します。開発責任者として、ドキュメントは "AI の参照情報" と捉えて、予算と時間を確保してください。

4つ目。PR レビューの観点を AI 生成前提に作り変える。
従来のコードレビュー観点（ロジック・可読性・テスト）に加えて、SaaS では「AI が見逃しやすい領域」を明示的にチェックする観点を足すべきです。具体的には——認可の裏口、トランザクション境界、外部 API の冪等性、タイムゾーン、料金計算の端数処理、監査ログの出力。これらを PR テンプレートに組み込み、「AI が書いたからこそ改めて確認する項目」 として明文化する。これをやるだけで、事故の確率が目に見えて下がります。

最後に、開発責任者として伝えたいこと。Claude Code の登場で、モノが作れるかどうかはもう差別化要因ではなくなりました。これからの差は、作れるモノを、壊さずに運用し続け、顧客の信頼を預かり続けられるかに移っています。SaaS 開発は一度作って終わりのゲームではなく、長期戦です。短期のスピードを追いかけて品質を落とすと、3ヶ月後にそのツケが利息付きで返ってきます。Claude Code はスピードも品質も同時に底上げできる稀な選択肢ですが、それを成立させるのは "止める線" と "整える文書" と "評価できる人間" を開発責任者が揃える覚悟 です。

ここを握れるなら、少人数スタートアップでも、従来の数倍のスピードで SaaS を運用していけます。逆にここを握れないまま勢いだけで走ると、AI の力で事故のスピードまで加速してしまう——これが、同じツールでも結果が真っ二つに割れる理由です。僕の実感としては、うちはこのやり方で、ようやく AI を前提とした SaaS 開発のリズムを掴み始めたところです。