ゼロから家計簿アプリをAIが開発！Devinの実力と生産性を検証してみた
概要
「家計簿アプリを作りたい」と思いながらも、忙しさに追われて着手できずにいました。
そこで今回は、人間はコードを1行も書かず、AIエンジニア Devin に開発を丸ごと依頼。
どこまで実装できるのか、そして開発時間やコストがどれだけ削減できるのかを検証しました。
テーマ
今回の検証では、以下の条件で進めました。
- 家計簿アプリをゼロから自然言語だけで開発する
- コード品質や実装方針はDevinに一任し、人間は細かい品質チェックを行わない
- 要件調整や仕様変更はすべてチャットベースで指示
- ACU消費量と工数削減効果を定量的に記録
やりたいこと
- 家計簿アプリの基本機能を実装
- DevinのACU消費計測と工数差分
大枠は計測が目的になります。どのくらいのACUを消費するのかをゴールに設定しました。
やらないこと
- 過度な品質チェック
- 動作保証
- ACUの消費が切れたら終了するため、完了までは目指さない
- 本番環境構築およびデプロイ
今回の目的は、ライトに依頼してどこまで自走できることが目的になっているため、たたき台レベルが今回も目標とした。
家計簿アプリ開発セッション記録
このセッションでは、個人用家計簿アプリ（kakeibo-app）をゼロから開発しました。
モノリポ構成でNext.js（フロントエンド）とNest.js（バックエンド）を使用し、GraphQL API、PostgreSQL、Prisma ORMを組み合わせた本格的なWebアプリケーションを構築しました。
完成したUI
主な機能
- 収支管理
- 月次集計
- カテゴリ管理
- 取引登録・編集・削除
- テンプレート管理
- 一括取引登録
技術スタック
- フロントエンド: Next.js 14, React, TypeScript
- バックエンド: Nest.js, GraphQL, TypeScript
- データベース: PostgreSQL (ローカル: Docker, 本番: Supabase想定)
- ORM: Prisma
- UI: shadcn/ui, Tailwind CSS
- 状態管理: Apollo Client
- フォーム: react-hook-form + zod
- 開発環境: Docker, pnpm (モノリポ管理)
最初のチャットである程度の技術スタックを記載して、Devinが提案してくれました。
個人用の家計簿アプリを作りたい
技術スタック
- Next（フロントエンド）
- Nest （バックエンド）
- GraphQL（API）
- shadcn ui（CSSフレームワーク）
- Prisma（ORM）
- PostgreSQL（本番環境はSupabase想定）
開発フェーズと作成したPR
Devinが立てたPRは、11PRを作成してもらいました。
利用できるACUの中で開発環境構築〜基本機能実装までを今回の範囲としました。
開発の内訳
エンジニア1名の費用
費用感を比較するために、1エンジニアが行った場合の概算工数を計算しました。
- 1時間あたりのエンジニア費用: 6,000円（平均単価）
- トータル：46時間稼働：276,000円
Devinで行った場合の計測結果と1エンジニアが行った場合の工数を比較してみました。
1エンジニアが行った場合は、概算ベースでの工数としています。
工数については人によって異なる部分はありますが、一般的な思考や調査を考慮しての工数として計上しています。
| 作業依頼内容 | 作業時間 | 消費ACU | Devin 課金 | 1エンジニアの工数（予想） |
|---|---|---|---|---|
| Phase 1: 環境構築 | 20分 | 2.56 ACU | 2時間 | |
| Phase 2: データベース設計（Prisma スキーマの定義） | 5分 | 1.09 ACU | 4時間（要件を検討及び実装含む） | |
| Phase 3: フロントエンド画面実装（UI作成） | 10分〜20分 | 3.29 ACU | 8時間 | |
| Phase 4: データ表示問題の解決 （UIの実装不具合調査と実装） | 15分 | 2.56 ACU | 4時間 （調査含む） | |
| Phase 5: 月次集計機能強化 | 20分 | 3.8 ACU | 8時間 | |
| Phase 6: GraphQLスキーマエラー修正 | 10分 | 3.33 ACU | 4,995円 | 2時間 |
| Phase 7: カテゴリ管理機能 | 10分 | 2.08 ACU | 4時間 | |
| Phase 8: モーダル表示問題の解決 | 10分 | 3.76 ACU | 4時間 | |
| Phase 9: React警告の修正 | 15分 | 2.15 ACU | 2時間 | |
| Phase 10: 取引テンプレート機能を実装 | 10分 | 2.37 ACU | 4時間 | |
| Phase 11: テンプレート取引の表示問題を修正 | 20分 | 3.24 ACU | 3,330円 | 4時間 |
| 合計 | 約2時間25分〜2時間35分 | 30.23 ACU | 8,325円 | 46時間 |
🧮 人間 vs Devin 開発生産性比較表
| 指標 | 1エンジニア | Devin（AI） | 差分 / 削減率・向上率 |
|---|---|---|---|
| 作業時間 | 46時間 | 約2.5時間 | ▲94.6% 短縮 |
| 作業費用（目安） | 276,000円（@6,000円/時間） | 8,325円 | ▲約97% 削減 |
| 生産性向上倍率（時間ベース） | - | - | 約18.4倍 の効率 |
1エンジニアが行う場合は、概算工数のため正確な向上率にはなっていません。
少なくともかかるであろう作業時間と、今回11工程に要した時間を比較すると、時間短縮になっていることがわかります。
各Phaseの詳細
Phaseごとに依頼した内容に対して、Devinが何を実装してもらったのは以下になります。
環境構築〜実際の実装や不具合までを対応してもらいました。
Phase 1: 環境セットアップ
- モノリポ構成の基盤構築
- Next.js + Nest.js の同時起動環境
- Docker Compose でのPostgreSQL環境
- pnpm workspace設定
Phase 2: データベース設計
- Prismaスキーマ設計
- ユーザー、アカウント、カテゴリ、取引モデル
- 定期取引テンプレート機能
- 月次集計機能の基盤
Phase 3: フロントエンド画面実装
- 認証システム（ログイン・登録）
- ホーム画面
- 取引登録画面
- 収支管理画面
- 月次集計画面
- GraphQL連携
- 日本語対応
Phase 4: データ表示問題の解決
問題: 新規ユーザーでアカウントとカテゴリが0件のため取引が表示されない
解決策:
- ユーザー作成時にデフォルトアカウント自動作成（現金、銀行口座、クレジットカード）
- 日本の家計簿に適したデフォルトカテゴリ自動作成（食費、住居費、交通費など）
- 取引登録フォームのUX改善
Phase 5: 月次集計機能強化
- 左側：収入取引、右側：支出取引の2カラムレイアウト
- 各取引の編集・削除機能
- 合計金額と残高計算
- カテゴリ別集計表示
Phase 6: GraphQLスキーマエラー修正
問題: /summaryで入力した値が集計されない
原因: GraphQLリゾルバーでInt型の適切な型デコレーターが不足
// 修正前
@Args('year') year: number,
@Args('month') month: number
// 修正後
@Args('year', { type: () => Int }) year: number,
@Args('month', { type: () => Int }) month: number
Phase 7: カテゴリ管理機能
-
/categoryページの完全実装 - カテゴリの追加・編集・削除
- 検索・フィルター機能
- カラーピッカーとアイコン対応
- レスポンシブデザイン
Phase 8: モーダル表示問題の解決
問題: 月次集計ページで取引編集時に入力値が正しく表示されない
解決策: モーダルコンポーネントに動的keyプロパティを追加してリマウントを強制
<TransactionEditModal
key={editingTransaction?.id || 'edit'}
// ...
/>
Phase 9: React警告の修正
問題: "A component is changing an uncontrolled input to be controlled" 警告
原因: PR #8のkeyプロパティによるモーダル再マウント時に、フォームのdefaultValuesがundefinedから定義済み値に変更される
解決策: Logical OR (||) を Nullish Coalescing (??) に変更
// 修正前
defaultValues: {
amount: transaction?.amount || 0,
description: transaction?.description || '',
// ...
}
// 修正後
defaultValues: {
amount: transaction?.amount ?? 0,
description: transaction?.description ?? '',
// ...
}
Phase 10: 取引テンプレート機能を実装
- テンプレート管理ページ (/templates): テンプレートのCRUD操作、検索・フィルター機能
- 一括取引登録ページ (/templates/bulk-entry): テンプレートから金額のみ入力で取引作成
- テンプレート編集モーダル: 新規作成・編集用のモーダルコンポーネント
- GraphQL mutations追加: UPDATE_TRANSACTION_TEMPLATE, DELETE_TRANSACTION_TEMPLATE
- ホーム画面更新: テンプレート機能へのナビゲーションリンク追加
Phase 11: テンプレート取引の表示問題を修正
問題: テンプレート取引が正しく表示されない
原因:
- GraphQLミューテーションの不完全なレスポンス: CREATE_TRANSACTION_FROM_TEMPLATEが通常のCREATE_TRANSACTIONと異なる限定的なフィールド構造を返していた
- フロントエンドのキャッシュ管理不足: テンプレートから取引作成後にApollo Clientのキャッシュが更新されていなかった
解決策:
- CREATE_TRANSACTION_FROM_TEMPLATEミューテーションにuser, account, categoryリレーションを追加し、通常の取引作成と同じデータ構造に統一
- 一括取引登録ページのuseMutationにrefetchQueriesを追加して、取引作成後に月次集計と取引一覧のキャッシュを自動更新
成果物
完成した機能
大きく8つの機能を実装してもらいました。
精度といった部分で言えば、6〜7割程度の完成度ですが、個人開発ベースでは十分な機能が実装されました。
たたき台レベル（詳細設計なし）で、自律的にここまで実装してくれたことがわかりました。
細かい指示しながらやるとACUを無駄に使ってしまうことはありますが、ある程度の指示だけで自律的に実装してくれる点が非常に便利でした。
- ユーザー認証システム
- 取引登録・編集・削除
- 月次集計とグラフ表示
- カテゴリ管理（CRUD）
- アカウント管理
- レスポンシブデザイン
- 取引テンプレート機能
- 一括取引登録機能
作成したファイル数
- バックエンド: 30+ ファイル（モデル、リゾルバー、サービス、マイグレーション）
- フロントエンド: 25+ ファイル（ページ、コンポーネント、GraphQLクエリ）
- 設定ファイル: 10+ ファイル（Docker、Prisma、TypeScript、ESLint）
今後の拡張や機能について（Devinに依頼したいこと）
短期的な改善
- ログイン機能
- 取引テンプレート機能の実装
- データエクスポート機能
- 予算管理機能
長期的な拡張
- 複数ユーザー対応（家族共有）
- AI による支出分析
- 銀行API連携
短期的・長期的な開発以外にもDevinで画像やファイルから読み取って、実装は可能かどうかの検証は別途行いたいと感じました。
デザインツールを使っている場合は、MCPとの連携で実現はできます。
しかし、個人レベルのワイヤーレベルの抽象度が低いものでどこまで自律的にUI実装できるのかも検証したいと思いました。
まとめ
Devinに家計簿アプリ開発を依頼した結果、コードを1行も書かずに以下のことを実現できました。
上がってきたPRを確認しながら、動作検証を行いフィードバックを回して開発を行いました。
感じた部分としては、細かく指示しなくても自律的に実装を行ってくれる点が非常に便利でした。
個人開発レベルでは夜や朝といった本業以外での時間帯を使うことになるため、睡魔や思考停止したりすることが最近多かったため、Devinを使って課題を解消することができました。
個人開発ベースで単純な指示だけで開発を行いましたが、実際の本業では設計を具体的・詳細につめていきます。
Devinへの指示が明確であればあるほど、より意図する成果物に高まります。
Devinのメリット
利用してみて、Devinの守備範囲として大きく4つあると感じました。
- Deep Wikiで、エンジニア以外（POやPM）でも調査することができる
- ブラウザベース/Slackベースでのやり取りのため、POやPMとのコミュニケーションが取りやすい
- 設計から実装までの範囲はDevinで行うことが可能
- KnowledgeやPlaybookを活用することで定型的な業務を自動化できる
設計から実装までの範囲までDevinを活用する以外にも、コミュニケーションとしてDevinを活用することがメリットが高いと感じました。
ブラウザやSlackベースのため、POやPMが状況を把握したり実装仕様を調べるところでもDevinを活用できます。
Devinの活用方法
今回の活用方法ではありませんが、最近では設計・見積もりといった部分もDevinを活用しています。
実装設計・調査・見積もりといった部分は、Devinを使うことで効率的に行うことができます。
- 設計フェーズでの要件出しやコード調査を依頼する
- Devinが提案した設計をもとに、フィードバックを行う
- 工数はどのくらいかかるかを見積もり依頼
- 見積もりを判断を、人間が行う（提供されたコードを確認・影響範囲）
実装開発期間: 2025年7月29日 - 8月1日
作成PR数: 11個（すべてマージ済み）
Discussion