2026年4月から8月までの約5ヶ月間で、20を超えるアプリケーションを一人で構築し、本番環境で運用している。ペースにするとほぼ週1本。試作やデモではなく、実際にユーザーがいて、日々使われているシステムだ。

内訳はさまざまで、マルチテナントのセキュリティ監視SaaS、社内開発者ポータル、PMOダッシュボード、メール書庫を解析して案件をマッチングするAIツール、クラウドCTI(電話基盤)、観光地の予約システム、リアルイベントの運営アプリなどが含まれる。守秘義務の関係で個別の名前や金額は書けないが、いずれも「動いているだけ」ではなく、業務やイベントの現場で実際に使われている。

この数字は自慢のために書いているのではない。AI駆動開発によって個人の生産性の上限がどこまで動いたのかを示す一次データとして、事業や開発組織を預かる立場の人に共有する価値があると思っている。

週1本ペースを可能にした3つの条件

振り返ると、条件は3つある。

1. AI駆動開発を「ハーネス」として運用する

Claude Code のようなコーディングエージェントを、単発のコード生成ツールとしてではなく、要件整理からレビュー、デプロイ、運用確認までを流すパイプラインとして使っている。人間の仕事は、何を作るかを決めること、途中の判断、最後の検収に集約される。

これは開発だけの話ではない。事業本部の運営業務 — 勤怠収集、工数集計、請求処理、週報や経営会議資料の生成、Slack での異常検知まで — を Python 製の自動化ハーネス群(合計で約1万行規模)に載せた。開発デリバリーと事業責任者としての業務が両立できているのは、この自動化があるからだ。

2. インフラ運用コストをほぼゼロにするエッジ基盤

20本のアプリを一人で「運用」できているのは、Cloudflare Workers / D1 のようなエッジプラットフォームを前提にしているからだ。サーバのパッチ当ても、スケーリングの設定も、深夜のアラート対応も基本的に存在しない。アプリを増やすことの限界費用が、インフラ面ではほぼゼロに近い。

AWS で同じ本数を一人で運用しようとは思わない。技術選定の段階で「運用が消える構成」を選ぶことが、量産の前提条件になっている。

3. 量産を前提とした共通基盤の設計

技術顧問先では、SFA・請求管理・LMS など21の業務アプリを、認証・DB・CI/CD・監視を共通化した Hub & Spoke 型のモノレポの上で約6ヶ月かけて構築した。1本目のアプリと21本目のアプリでは、立ち上げにかかる時間がまったく違う。

AIエージェントに書かせることを前提にすると、共通基盤の価値は従来以上に大きくなる。エージェントは「前例のあるパターン」の再現が非常に得意だからだ。基盤とリファレンス実装を一度作れば、そこから先は量産になる。

ボトルネックは「作れるか」から「何を作るか」へ

この半年で一番大きく感じた変化は、技術的に作れるかどうかを心配する時間がほぼ消えたことだ。代わりにボトルネックになるのは、

  • 何を作るべきかを決める判断
  • 作ったものを業務や営業の現場に載せる段取り
  • 増えたアプリ群を把握し続けるための管理(これ自体もアプリ化した)

つまり、事業側の意思決定と運用設計である。実装速度が上がるほど、この部分の巧拙が全体の速度を決める。

開発組織の前提が変わる

個人でこの生産性が出るなら、組織設計の前提は変わらざるを得ない。

「エンジニア1人×AIハーネス」というユニットが、従来の数名チームに相当するアウトプットを出すケースは、もう例外ではない。一方で、それは「人数を減らせば同じことが起きる」という意味ではない。ハーネスの設計、共通基盤、運用が消える技術選定という前提条件を整えずに人だけ減らすと、単に手が足りなくなる。

発注側の視点でも同じことが言える。従来「数ヶ月・数名体制」で見積もられていた規模のシステムが、条件さえ整えば大幅に短いリードタイムで形になる。見積もりと体制の常識が変わりつつある今、その前提を知っているかどうかは、事業判断に直接効いてくる。

ここに書いた数字は、意図的にぼかしている部分がある。個別の事例や具体的な構成については、ご相談の場で話せる範囲でお伝えできる。