先週、7日間で5つのリポジトリにまたがって102件のコミットをプッシュしました。「typoを直す」系のコミットではありません。AI支援開発で作った本物の機能です。スクラッチからのフルヘッドレスNext.jsフロントエンド。CRMからデータベースへの同期パイプライン。Content-as-a-Service API。GTMトラッキング。SEO最適化。管理パネル。
私はソロ開発者です。ほぼすべてにAIの助けがありました。
これは「AIが開発者を置き換える」という誇大宣伝記事ではありません。AI支援開発を1週間ほぼ全面的に取り入れたときに何が起きたのか、うまくいったこと、驚いたこと、そして今も考えていることを、一次情報として正直に書いたものです。
1週間でAI支援開発が生み出したもの：数字
gitログが語っています：
| Day | Commits | What I Built |
|---|---|---|
| ----- | --------- | ------------- |
| Thursday | 9 | SEOインフラ — IndexNow、Bingの修正、レンダーブロックの最適化 |
| Friday | 15 | デザイン仕様から初回コミットまで、Next.jsフロントエンド一式を足場から構築 |
| Saturday | 13 | 検索ダイアログの再設計、iOSのスクロール修正、画像パイプライン、SEO |
| Sunday | 1 | 休みの日。小さなコミット1件。 |
| Monday | 17 | 管理パネル、ニュースレター連携、Content-as-a-Service APIをローンチ |
| Tuesday | 22 | AIコンテンツパイプライン、WPプレビューシステム、ベクター知識ベース |
| Wednesday | 13 | 完全なCRM同期パイプライン（Perfex → Supabase → Next.js）+ GTMトラッキング |
5つのリポジトリ。4つの技術スタック（Next.js、PHP、Python、shell scripting）。チームメイトはゼロ。
参考までに、GitClearとLinearBの業界ベンチマークによると、平均的な開発者は週あたり5〜10コミットをプッシュします。私の経験では、AI支援開発によってそのベースラインに対する出力はおよそ10〜20倍に跳ね上がりました。ただし、コミット数の“生”の数だけでは物語の一部しか分かりません。
AI支援開発が実際にどんな感じか
人はAIコーディングを「プロンプトを打つとコードが出てくる」みたいに想像します。違います。全然違います。
それは、あなたの隣にいる“とても速くて、とても知識がある同僚”を持つようなものです。疲れない。深夜2時のあなたのアイデアを裁かない。PHP、TypeScript、bashの間を瞬時にコンテキストスイッチできるのに、瞬きもしない。私はこのワークフローのために複数のツールを試しました。詳しい内訳が欲しければ、Claude Code vs Cursorの比較→を見てください。
典型的なAI支援開発セッションはこんな感じでした：
Me: 「Perfex CRMからSupabaseにスタッフデータを同期したい。ソーシャルメディアリンク用のカスタムフィールドも含めて。」
AI: Perfex APIのドキュメントを読み、私の既存のSupabaseスキーマを読み、今のデータレイヤーを読みます。次に、同期エンドポイント、データ変換、エラーハンドリングを書き、型も更新します。私はレビューして、調整して、出荷します。
このサイクル――意図を説明し、出力をレビューし、調整して、出荷する――が1日に何十回も起きました。各サイクルは“数時間”ではなく“数分”で終わります。これがAI支援開発のコアループで、一度それを体に入れると、後戻りはできません。
スピードの倍率は本物。でも、思っている場所ではない
AI支援開発による生のコーディング速度のブーストは、おそらく3〜5倍です。すごい。でも本題ではありません。
本当の倍率はコンテキストスイッチです。水曜日、私はCRMコードベースでPHPのAPI修正を書いていたところから、Next.jsでTypeScriptのデータ同期を書き、GTMタグを設定し、Tailwindコンポーネントを更新しました。これらのコンテキストスイッチは、本来なら「どこにいたっけ？」というメンタルの読み込みに15〜30分かかります。AIがコンテキストを維持してくれるので、そのコストはほぼゼロまで落ちました。
2つ目の倍率はスコープの勇気です。「このスプリントでは複雑すぎる」としてスコープアウトしていたであろうことに挑戦しました：
AI支援開発で気づいた5つのパターン
コミット履歴を見て、5つのパターンが際立ちました：
1. デフォルトで垂直統合
AIなしなら、まずフロントエンドを作って、その後「次のスプリントで」CRM同期を計画して、いつかコンテンツパイプラインに取りかかる…となっていたでしょう。代わりに私は、1週間でフルの垂直スタックを作りました：CRM → API → Database → Frontend → Analytics。すべての機能がエンドツーエンドで完成しています。これは、私がNext.jsとAIエージェントで作ったカスタムCRM→を作ったのと同じ流れです。
2. 自動化を最初の本能にする
デプロイのたびに手動でCRMデータを同期する代わりに、私はそれを自動で行うprebuild hookを即座に作りました。毎回のプロジェクトでGTMを手動で設定する代わりに、それ用の再利用可能なClaude Codeスキルを作りました。AI支援開発は自動化のコストをここまで低くするので、手作業のプロセスよりも自動化がデフォルトの選択になります。
3. 夜に設計、昼に磨く
最も建築的に野心的なコミットは、日付が変わった後に起きました。2 AMの時点でプロジェクトの足場を完成させる。深夜0時の心理学に基づくUXでの問い合わせフォーム再設計。1 AMの管理パネル。昼間は修正、磨き込み、デプロイの時間です。私はこの仮説をgitデータで検証しました：全コミットの40%が22時〜6時の間に発生しています。AI支援開発があれば、自分のメンタルエネルギーが低い時間帯でも生産的になれます。
4. ツール作りが積み重なる
その週の間に、私は再利用可能なClaude Codeスキルを2つ作りました――GTMインストーラとApple Shortcutsジェネレーターです。これらはメインプロジェクトではありませんが、AI支援開発が「ワークフローを再利用可能なツールとしてパッケージする」ための限界コストをほぼゼロにしてくれるので、自然に生まれてきました。同じアプローチを、MCPサーバーを作る→と、MCPとエージェントフローでCMSを作った話→でも使っています。
5. ドキュメントはインラインで起きる
AIがコードを書くと、文脈に沿ったドキュメントも生成します――コミットメッセージ、CLAUDE.mdの更新、型定義など。ドキュメント作成が別の“面倒な作業”ではなくなり、AI支援開発のワークフローの自然な副産物になりました。
AI支援開発の正直なトレードオフ
このスピードには代償があります。私が格闘しているのは次の点です：
品質 vs. スピード。 速く出荷できている。でも、まだ見えていない技術的負債を積み上げていないか？ AIが生成したコードは私のレビューを通りますが、深夜2時の私のレビューは、10時の私のレビューではありません。私は自分の夜のコミットに対して、翌朝の“朝イチ”コードレビューを始めました。
理解 vs. 出力。 AIが複雑なデータ変換を書いたとき、私は*何をするのか*は理解します。でも、AIなしで6か月後にデバッグできるほど深く理解できているでしょうか？ 自信がありません。私は毎行を読むようにしていますが、読むことは書くことと同じではありません。
持続可能性。 7日で102コミット、47アクティブ時間、22時以降の作業が40%。これはマラソンではなくスプリントです。ツールがこのペースで働くことを*可能*にしてくれますが、可能と推奨は同じではありません。
依存リスク。 AI支援開発ツールが明日消えたら、このコードベースを同じ速度で維持できるでしょうか？ 絶対に無理です。このトレードオフは受け入れました。これらのツールが消えるとは思っていないからです。でも、正直に言う価値はあります。
AI支援開発について、他の開発者に伝えるなら
まだAIコーディングツールを使っていないなら、かなり大きな倍率を取りこぼしています。AIが完璧なコードを書くからではありません――そんなことはありません。野心的なプロジェクトがソロ開発者にとって“不可能に感じる”原因となる摩擦を取り除いてくれるからです。
AI支援開発を取り入れるためのおすすめの段階はこうです：
次の10年で伸びる開発者は、最速でコードを書く人ではありません。AIが実装を担当している間にシステムについて考えられる人。そして、速く進めるのが簡単なツールがあっても、いつ減速して慎重に考えるべきかを知っている人です。
視点を変えた1週間
私は、従来なら小さなチームの“月間の成果”に相当するものを作りました。7日で、完全なサイト移行、CRM連携、APIプラットフォーム、そしていくつかのオープンソースツール。
でも、私が出荷した中で最も価値があったのはコードではありません。ボトルネックが変わったという気づきでした。「これを作れるか？」ではなく、「これを作るべきか？」そして「正しいものを作っているのか？」。
AI支援開発は、ソフトウェアエンジニアリングで難しい部分を変えませんでした。難しい部分を“移動”させただけです。