99%のコードをAIが書いた引越しアプリを1ヶ月でリリースした話

ミツモアの開発部長をしています坂本です。本日はAI駆動でアプリを短期間でリリースしたことについてお話ししようと思います。 LLMで何でも開発できると言われているが、実際問題どこまでできるのよ？カオスにならない？といった疑問をお持ちの方の役に立つと嬉しいです。

はじめに

「引越しの準備って、やること多すぎて何から手をつけていいかわからない」

そんな課題を解決するために、引越しタスク・荷物を一元管理できるアプリ「引越しサポート」を開発しました。

本記事では、AI（Claude）と1人のエンジニアで、99%のコードをAIに書かせることにより約1か月という短期間でアプリを開発した事例を紹介します。どのような課題があり、どう解決したのか。AI活用の実践的なノウハウを共有します。

なお、社内向けのツールであればもっとvibe codingで気軽に作っています。今回は社外向けということで、品質担保やアーキテクチャにより気を配りました。

開発の経緯

元々はミツモアの新たな依頼創出を検討する中で生まれた企画です。ちょうど社内で引越しを経験したメンバーから「ToDoに漏れがあって困った、こういうアプリが欲しかった」という声があり、開発することになりました。

仕様は事業本部長と2人で決めていきました。機能自体はそう多くなく、ToDo管理の仕組みは世の中にありふれています。新規性の高い複雑な機能ではないため、AI開発に適した題材だったと思います。

どのように開発を進めたか

自分はミツモアの開発部長なので、当然メイン業務があります。このプロジェクトに使えるリソースは20〜30%程度でした。

そこで、開発中は常にClaude Codeを3並列くらいで動かしていました。プランニングや実装をAIに任せつつ、それを横目にメイン業務を進めるスタイルです。

並列で作業を進めるために、モジュールごとに1タスクずつ切り出して依頼しました。たとえば「Todoモジュールの実装」「Boxモジュールの実装」「認証周りの実装」といった形です。モジュール間の依存を最小限にする設計にしていたため、並列作業がしやすかったです。

サービス概要

引越しサポートは、引越しに伴うタスクや荷物を一元管理するモバイルアプリです。

主な機能

機能	概要
ToDo管理	引越しタスクの期限管理・リマインダー通知
荷物管理	写真付きの荷物登録・段ボールへの紐付け
段ボール管理	梱包状況の追跡・新居での配置先指定
オンボーディング	ユーザー属性に応じたToDoテンプレート自動生成

技術スタック

バックエンド

Node.js 24 + Hono
PostgreSQL + Prisma 6
TypeScript 5.7 + Zod 4

フロントエンド

React 18 + Vite 6
shadcn/ui + Tailwind CSS
Redux Toolkit + RTK Query

技術選定の理由

Hono

軽量でTypeScriptサポートが手厚い
Hono RPC（hc）でバックエンドの型定義からフロントエンドのクライアントを生成でき、End-to-Endの型安全が実現できる
DIはフレームワークに頼らず素朴に実装。ファクトリ関数でリポジトリを注入するシンプルな構成

RTK Query

他のアプリケーションと実装方針を揃えるため
API呼び出しと型定義はHono RPCを使用し、RTK Queryはキャッシュ管理として活用

1人開発における課題

課題1: コードの配置場所が散らかる

コードベースが大きくなるとAIは途端に全体を把握しなくなります。最初の頃は他のディレクトリを確認しに行って構造を揃えてくれていたのに、突然バラバラに好き勝手実装するようになります。

解決策: 細かいルール策定

DDDに限らず、コードの配置場所やファイル命名規則を細かくドキュメント化しました。

module/
├── domain/           # ドメインを持つレイヤ
│   ├── entities/     # エンティティ（型定義とファクトリ関数）
│   ├── logic/        # ビジネスロジック
│   ├── schemas/      # 型定義・Branded Type
│   └── repositories/ # リポジトリ層
├── application/      # ユースケース
├── infrastructure/   # リポジトリ実装
└── presentation/     # ルーティング・コントローラー

このガイドラインをCLAUDE.mdとして配置することで、AIがコード生成時に一貫したパターンに従うようになりました。

課題2: コードレビューの不在

1人開発の最大の弱点は、コードレビューがないことです。バグの見落とし、設計の歪みに気づけないリスクがあります。

解決策: AI自身に繰り返しレビューさせる

Claude Code自身に設計・実装・テスト全てを複数セルフレビューさせました。レビューと修正のループを回すのですが、ループごとに守れなかったルールをドキュメントに適宜追記させます。大体3回くらいレビューと修正のループを繰り返すといい感じになることが多かったです。

課題3: 型安全性の担保

フロントエンドとバックエンド間のAPI型定義の乖離は、バグが起きやすいですしメンテナンスに無理が出ます。

解決策: Hono + Zod + Hono RPC

ミツモアではNestJS + OpenAPI + RTK Query でバックエンドのスキーマから型を自動生成してるんですが、今回はより新しく軽いHonoのRPC機能を採用し、バックエンドのAPI定義からフロントエンドのクライアントコードを自動生成する仕組みを導入しました。

// バックエンド: API定義
const app = new Hono()
  .get('/todos', async (c) => {
    const todos = await getTodos()
    return c.json(todos)
  })

export type AppType = typeof app

// フロントエンド: 型安全なクライアント
const client = hc<AppType>('/api')
const todos = await client.todos.$get()
// ↑ 戻り値の型が自動的に推論される

これにより、APIの型変更がフロントエンドで即座にエラーとして検出されるようになりました。バックエンドとフロントエンドの変更を同時に依頼しても最後まで走り切ることができます。

課題4: ドキュメントの維持コスト

仕様書やアーキテクチャドキュメントの維持は、1人開発では後回しにされがちです。しかし、AIを活用するためには、コンテキストを正確に伝えるドキュメントが不可欠です。

解決策: ドキュメントファーストな開発

本プロジェクトでは、実装前にドキュメントを書くアプローチを取りました。

docs/
├── overview.md              # 機能要件
├── architecture.md          # 技術スタック・ER図
├── backend-ddd-guidelines.md # DDD設計ルール
├── frontend-guidelines.md   # フロントエンド規約
├── authentication.md        # 認証フロー
├── onboarding-flow.md       # オンボーディング仕様
└── reminder.md              # リマインダー仕様

ドキュメントを先に書くことで：

実装前に仕様を明確化できる
AIへのコンテキスト提供が容易になる
後から見返したときに「なぜこう実装したか」がわかる

課題5: 品質担保

1人開発でAIがコードを生成する場合、「本当にこのコードは正しく動くのか？」という不安が常にあります。すべてのコードを目視レビューするのは現実的ではありません。

解決策: エンドポイントE2Eテストを最重要視

本プロジェクトでは、APIエンドポイントのE2Eテストを最重要視しました。

考え方はシンプルです：

APIの振る舞い（入力と出力）を正確に定義する
テストでその振る舞いが満たされていることを確認する
アーキテクチャのルールに従っていれば、内部実装はおおよそ正しい/綺麗と推測できる

// todo.e2e.spec.ts
describe('POST /api/todos', () => {
  it('タスクを作成できる', async () => {
    const response = await app.request('/api/todos', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        title: 'テストタスク',
        dueDate: '2025-03-01',
      }),
    })

    expect(response.status).toBe(201)
    const body = await response.json()
    expect(body.title).toBe('テストタスク')
    expect(body.id).toBeDefined()
  })

  it('タイトルが空の場合は400エラー', async () => {
    const response = await app.request('/api/todos', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ title: '' }),
    })

    expect(response.status).toBe(400)
  })
})

このアプローチのメリット：

振る舞いが担保される: APIが仕様通りに動けば、ユーザー体験は保証される
リファクタリングに強い: 内部実装を変更してもテストが通れば安心
AIが理解しやすい: E2Eテストがあればそのエンドポイントの責務がわかる

もちろん、認証処理やビジネスロジックの複雑な部分は目視でレビューしています。しかし、CRUD操作のような定型的な処理は、E2Eテストのみで品質を担保している箇所も多いです。

人間が全てをレビューすることを諦めて「テストが通る = 正しい」という信頼を置けるテストスイートを構築することが、AI活用時代の品質担保の鍵だと感じました。

AI活用の実践的Tips

Tip 1: CLAUDE.mdによるコンテキスト設定

プロジェクトルートにCLAUDE.mdを配置し、以下を記述しました：

プロジェクトの目的と対象ユーザー
技術スタック
ディレクトリ構成
コーディング規約
よく使うコマンド

これにより、AIが毎回コードベースを理解し直す必要がなくなり、回答の精度と速度が向上しました。

Tip 2: 小さなタスクに分解する

「ToDoリマインダー機能を実装して」のような大きな依頼ではなく、以下のように分解しました：

TodoReminderエンティティのスキーマ定義
リマインダー作成ロジックの実装
スケジューラーによる定期実行処理
プッシュ通知の送信処理

小さく分解することで、AIの出力が正確になり、レビューも容易になります。

Tip 3: AI自身にレビューさせる

CLAUDE.mdにルールを書いていても、AIは読み飛ばしたり忘れたりすることがあります。レビューの質は回数で補います。

実装が終わったら「CLAUDE.mdのルールに違反していないかレビューして」と依頼します。たとえば logic/ に書くべきビジネスロジックが repositories/ に紛れ込んでいるような規約違反は、このレビューでほぼ見つかります。

AIは自分が書いたコードでも客観的にレビューできるので、実装→レビュー→修正のサイクルを何度か回すことで品質を担保できます。

学びと振り返り

うまくいったこと

ドキュメントファーストのアプローチ: AIの精度向上に直結した
型安全なスタック選定: Hono + ZodでフルスタックTypeScript
DDDの採用: コードの配置場所が明確になり、AIへの指示も簡潔に
E2Eテスト重視の品質担保: 振る舞いベースのテストでAI生成コードの信頼性を確保

改善したいこと

フロントエンドのテスト: バックエンドほどテストカバレッジを確保できなかった

まとめ

AI + 1人という体制で、約1か月で社外向けアプリを開発できました。成功の鍵は以下の4点だと考えています：

ドキュメントへの投資: AIが活躍するための基盤
型安全なスタック: 型による保証がなければおおよそ実現不可能
明確なアーキテクチャ: レールに乗って開発
E2Eテストによる品質担保: 振る舞いを定義し、テストで信頼性を確保

AIは何でもできる魔法のツールではありません。しかし、適切なコンテキストを与え、小さなタスクに分解し、テストで品質を担保する仕組みを作れば、1人の開発者の生産性を数倍に引き上げてくれます。

1人開発に挑戦する方、AIを活用した開発に興味がある方の参考になれば幸いです。

余談: AI時代のコードレビューについて

今回の開発を通じて、コードレビューについて考えさせられました。

現時点では「コードレビューは人間がしなければならない」という固定観念があり、それ自体は正しいと思っています。しかし、AIによって新規作成されたコードに関しては、レールを敷いていればテストやドキュメントがかなり充実します。そのため、AIによるレビューで一定の品質担保は可能だという感覚もあります。

今後AIによる開発がさらに進化した場合、人間によるレビューの価値は相対的に低下していくでしょう。実はすでにそうなっているのかもしれませんが、人間側がまだ受け入れられていないだけかもしれません。

E2Eテストで振る舞いを保証し、内部実装はAIに任せる。これがソフトウェア開発の標準的なやり方になっていく可能性を感じています。

ただし、これはバックエンドについてはそこそこの確信を持って言えますが、フロントエンドに関しては50:50といったところです。生成の質そのものや、テストの難しさを含めて、まだまだ発展途上という感覚があります。

余談2: コードを書きたいという欲がなくなった

引越しアプリの開発で全てのコードをAIに書かせたことにより、とてつもないスピードでプロダクトが作られていきました。

今までは大きく分けて「プロダクトを作りたい欲」と「コードを書きたい欲」の2つが自分の中にありましたが、今回の経験により「コードを書きたい欲」が消え失せました。

なぜ自分がコードを書かなければならないのか？くらいの感覚になりました。

一方でプロダクトを作りたい、改善したいという欲はより強くなり、その欲を満たすにはAIに超高速でコーディングさせるしかなくなってしまいました。

今Claude Codeが10倍に値上げして会社がサブスクリプションを止めてしまった場合、私はもうエンジニアとして働くことはできないかもしれません。それくらいの影響がありました。

一昔前CursorがTab補完をしてくれていた頃はTabキーなくては生きていけないと感じていましたが、今はコードを書くなんて面倒だなと感じています。

この変化は加速度的に起きており、AIコーディングは一種の麻薬のようなものかもしれません。

ミツモアで一緒に働きませんか？

ミツモアでは、生成AIを活用して圧倒的な生産性を生み出し、日本のGDPを向上させるという目標に向けて、一緒に働く仲間を募集しています。

今回ご紹介したように、AIエージェントを活用した業務自動化や、プロダクトへのAI組み込みなど、様々な領域で生成AIの活用が進んでいます。

一緒にスタートアップでデータ活用や生成AIアプリケーションの開発をしてみませんか？少しでも興味をお持ちの方は、カジュアル面談からでも大歓迎です。ぜひお気軽にご応募ください！

ミツモア採用ページをチェックする！

ミツモア Tech blog

「ミツモア」を運営する株式会社ミツモアの技術ブログです