自社のSaaSアプリをClaude Codeで開発して、本番リリースした。
技術負債0件。Lint警告0件。 as any（型安全性を無視する記述）0件。 E2Eテスト46件パス。ユニットテスト143件パス。 セキュリティスコア100点満点。 CVE（脆弱性報告）は即日対応。
この数字は、エンジニアチームの成果ではない。 「データベース何それ美味しいの？」と言っていた52歳の非エンジニアが、 Claude Codeと二人で出した数字だ。
内製化の本質は「外注費を削る」ことではない。 「自分たちの仕組みを、自分たちの手で持つ」ことだ。
私がやったのは、CLAUDE.mdというファイルに プロジェクトのルールを全部書くことだった。
「as anyの使用禁止」「500行を超えるファイルの作成禁止」 「絵文字使用禁止、SVGアイコンを使用」「カラーパレット4色厳守」。
これだけで、Claude Codeは勝手にルールを守る。 as anyを使わなくなり、長いファイルは自動で分割を提案してくる。
外注なら仕様書→見積もり→契約→開発→テスト→納品→修正に3ヶ月。 Claude Codeなら「こういうツールが欲しい」→対話→完成が数時間。
費用はProプラン月額$20だけ。外注費ゼロ。 しかも品質は、上の数字が示す通りだ。
- CLAUDE.mdにルールを明文化するだけで、AIの出力品質が劇的に変わる
- 技術負債0件・Lint0件・セキュリティ100点——非エンジニアでもプロ品質を実現できる
- CVE（脆弱性）は番号を伝えるだけで、バージョン確認→アップデート→検証→デプロイまで一気通貫
- 「意図を伝える」が最も効く指示の出し方。「何を」より「なぜ」を伝える
- 人間の役割は要件定義・設計判断・技術レビュー。AIの出力を鵜呑みにしないレビュー習慣が品質を守る
CLAUDE.mdが品質を守る仕組み
私のプロジェクトでは、CLAUDE.mdに3つのセクションを書いている。「必読ドキュメント」「禁止事項」「カラーパレット」。必読ドキュメントには開発ガイドやコア仕様書のパスを列挙する。Claude Codeはコーディング前にこれを確認してから動く。禁止事項に「as any使用禁止」と書くだけで、AIは型安全なコードを書くようになった。500行制限を入れたら、長くなりそうなファイルは自動で分割提案が来る。カラーパレットを4色に固定したら、デザインの一貫性が崩れなくなった。CLAUDE.mdは「AIの行動規範」であり、チームにエンジニアがいなくても品質を担保する仕組みだ。結果として技術負債0件、Lint警告0件、as any 0件という数字が出た。
CVE即日対応——「番号を伝えるだけ」の開発体験
ある日、Next.jsに高深刻度のCVE（セキュリティ脆弱性）が報告された。CVE-2025-55184（DoS）とCVE-2025-55183（ソースコード漏洩）。私がやったのは、Claude Codeにこの2つの番号を送って「これ完了してるか教えて」と聞いただけだ。Claude Codeは現在のパッケージバージョンを確認し、必要なアップグレードを特定し、npmインストールを実行し、type-check・lint・buildの検証を通し、Gitコミット＆プッシュまで一気に完了した。両ブランチにプッシュ済み、Vercelで自動デプロイされます——そう報告が来て終わり。外注なら「セキュリティアップデートの依頼→見積もり→対応→テスト→デプロイ」で数日かかる。Claude Codeなら5分だ。
人間が担当すべき領域——Optimistic UIの落とし穴
Claude Codeは優秀だが、すべてを任せてはいけない場面がある。私はUIの楽観的更新（Optimistic UI）を実装したとき、「これ、コマンドパターンとセットでないと無限ループだよね」と指摘した。状態更新→useEffect発火→保存→状態更新…の無限ループだ。Claude Codeは「その通りです」と認め、コマンドパターンを追加した。人間がレビューしなければ、この落とし穴は本番で発覚していた。内製化で品質を守る鍵は、AIの出力を鵜呑みにしないこと。要件定義・設計判断・技術的レビューは人間の仕事だ。AIは「優秀だが経験の浅いエンジニア」と考えると、適切な付き合い方ができる。
AIネイティブ化の全体像は /for-ceo でご覧いただけます。
内製化を始めるための5ステップ
- プロジェクトルートにCLAUDE.mdを作成する。最低限「必読ドキュメントのパス」「禁止事項（as any禁止、行数制限）」「固定ルール（カラー、アイコン）」の3セクションを書く
- 小さなタスクから始める。「この型エラーを直して」「このCSVをパースする関数を作って」程度でいい。いきなり大きなシステムを作らない
- Claude Codeに「説明→方針→diff」の三段階で依頼する。いきなりコードを書かせると、どこが変わったかわからなくなる
- 開発の区切りごとに「ここまでの決定事項をMarkdownで出力して」と頼み、ドキュメントを蓄積する。未来のセッションへの引き継ぎ資料になる
- レビュー習慣を持つ。AIの出力を読み、「本当にこれで正しいか」と問う。技術的な懸念を指摘すれば、AIはそれを反映して改善する
内製化の本質は、ツールの話ではない。
「自分たちのプロダクトを、自分たちで持つ」 という意思の話だ。
あなたが外注に頼んでいるそのシステム、 本当に他人に任せたままでいいだろうか。
▼ 関連記事 /blog/ai-adoption-failure /blog/chatgpt-business-practical /blog/non-engineer-first-app