ENECHANGE Developer Blog

ENECHANGE開発者ブログ

モバイルアプリ開発をAIで自動化！Notion×Figma×Claude Codeの実践ワークフロー

AIエージェント活用リレーブログ

こんにちは、ENECHANGE で EV Dev チームのエンジニアをしている利廣です。

前回はSentry・Slack・GitHub MCPを使ったエラー解析ワークフロー(*1)についてお話ししましたが、今回は「開発フロー全体」をAIで自動化した話をしたいと思います。

正直に言うと、最初は「AIに開発を任せるなんて...」と思っていました。でも、実際にやってみると想像以上に効率的で、今では手放せないワークフローになっています。

きっかけ：繰り返し作業の多さに気づいた

モバイルアプリの新規機能開発では、基本設計がある前提で以下のようなフローを毎回繰り返していました：

  1. 基本設計から、タスク分解
  2. 各タスクを実装、実装に対してテストを作成、ドキュメントを追加
  3. PR作成

これらの作業、よく考えると「パターン化できる」部分が多いんですよね。特にタスク分解や PR 作成は、毎回似たような作業をしている気がしていました。

「これ、Claude Code に任せられるんじゃない？」

そう思ったのが始まりでした。

実践：3つのスラッシュコマンドで開発フローを自動化

1. タスク分解の自動化 - /divide-into-tasks

私たちのプロジェクトでは Notion で基本設計を管理し、Figma でデザインを管理しています。これらの情報を Claude Code に読み取らせて、タスクに自動分解するコマンドを作りました。

divide-into-tasksコマンドの内容 

# Notion ページから To-Do 実装コマンド

このコマンドは、{{DESIGN_URL}}ページに記載されている基本設計のネイティブ部分を参考にタスクに細分化してください。細分化したタスクは{{TASK_URL}}の Board の`Not Started`ボードに移動し、To-Do リストを追加してください。

## 使用方法

NotionページのURL: [ここにNotionページのURLを貼り付け]

上記のNotionページを読み取り、以下の手順で実装してください：

1. **ページ内容の解析**
   - Notionページのネイティブの基本設計からTo-Doリストを抽出
   - 各タスクの詳細や要件を理解
   - 優先度や依存関係を確認

2. **実装計画の作成**
   - TodoWriteツールを使用してタスクリストを作成
   - 各To-Doを具体的な実装タスクに分解
   - 実装順序を決定

3. **実装の実行**
   - 各タスクを順次実装
   - 実行済みのTodo TaskはNotionの方でもDoneの状態にする
   - コードレビューとテストを含める
   - 進捗をTodoWriteツールで管理

4. **完了確認**
   - 全てのTo-Doが完了していることを確認
   - 必要に応じてテストを実行
   - 実装結果をまとめて報告

## 注意事項

- Notionページへのアクセス権限があることを確認してください
- 実装前に既存のコードベースとの整合性を確認してください
- CLAUDE.mdの指示に従って日本語で回答してください
- セキュリティやパフォーマンスに配慮した実装を心がけてください

使用例

/divide-into-tasks DESIGN_URL=https://www.figma.com/design/... TASK_URL=https://www.notion.so/...

このコマンドの面白いところは、Notion の Board 形式のデータベースに書き込むようにしている点です。なぜかというと、タスクを少しずつ実行したい時があるからです。

実際に使ってみると、Figma の MCP サーバーも活用して UI 部分のタスク分解もしてくれるので、デザインと実装の乖離が少なくなりました。

2. タスク実装の半自動化 - /dev-with-notion

タスク分解ができたら、次は実装です。でも全部一気に実装させると、正直レビューが大変なんですよね...。

そこで、Notion の Board で In Progress に移動したタスクだけを実装するコマンドを作りました

dev-with-notionコマンドの内容 

# Notion のタスク実装

Notion URL：$ARGUMENTS

このコマンドは Notion のタスクボード内の「In Progress」ステータスのタスクを実装します。

以下の手順を実行してください：

## 1. **引数の確認**

- ユーザーから指定された Notion URL を確認
- URL が有効な Notion ページであることを確認

## 2. **Notion MCP サーバーを使用してタスクを取得**

- Notion MCP サーバーを利用してページ内容を取得
- 「In Progress」ステータスのタスクを特定
- タスクの詳細説明と要件を読み取り

## 3. **タスクの実装**

### 実装時の注意事項

- **コーディング規約の遵守**: 既存のコードスタイルに従う
- **テストの作成**: 必要に応じてユニットテストを追加
- **エラーハンドリング**: 適切な例外処理を実装
- **パフォーマンス**: 効率的なコードを心がける

### 実装手順

1. タスクの要件を分析
2. 必要なファイルを特定
3. 実装計画を立案
4. コードを実装
5. 動作確認を実施

## 4. **コードフォーマットの修正**

- 実装後、自動フォーマットによる差異を確認
- 不要なフォーマット変更を元に戻す
- コードの一貫性を保つ

## 5. **Notion ステータスの更新**

- 実装完了後、タスクのステータスを「Done」に変更
- Notion MCP サーバーを使用してステータスを更新
- 必要に応じて実装内容のコメントを追加

## 重要な注意事項

- **権限確認**: Notion ページへのアクセス権限があることを確認
- **変更の確認**: 変更を行う前に必ずユーザーに確認を求める
- **ドキュメント**: 複雑な実装の場合はコメントを追加

## トラブルシューティング

### Notion MCP サーバーが利用できない場合

- MCP サーバーの設定を確認
- 認証情報が正しいか確認

使用例

/dev-with-notion https://www.notion.so/...

このコマンドの特徴は： - Plan Mode で開始：どんな計画で実装しようとしているかを確認できる - 部分的な実装：レビューしやすい単位で実装 - テストも自動作成：これが意外と優秀で、手書きより網羅的なテストを作ってくれる

3. PR 作成の自動化 - /create-pr

最後は PR 作成です。ここでは「コミット粒度」にこだわりました。

create-prの内容 

# PR を作成してください

マージ先のブランチ名：$ARGUMENTS

このコマンドは現在の変更をコミットし、指定されたブランチに向けてプルリクエストを作成します。

以下の手順を実行してください：

1. **引数の確認**

   - ユーザーから指定されたマージ先ブランチ名を確認

## コミット粒度のガイドライン

適切なコミット粒度は開発効率とコードの品質に大きく影響します。以下の基準に従ってコミットを作成してください：

### 基本的な考え方

コミットは「何かあったらここまで戻りたい！」という単位で作成します。これは**ドラクエのセーブポイント**のようなイメージです。

### コミットすべきタイミング（4つの基準）

1. **変更の意図や目的が後から分かる単位**
   - 1つの機能追加、1つのバグ修正、1つのリファクタリングなど
   - コミットメッセージで変更理由を明確に説明できる範囲

2. **プログラムが正常に動く状態**
   - テストが通る状態でコミット
   - ビルドエラーが発生しない状態
   - ロールバック時にアプリが壊れないようにする

3. **TODOリストの1つのタスクが完了した時**
   - 計画していた作業の1単位が終わったタイミング
   - 次の作業に移る前の区切りとして

4. **失いたくない作業のポイント**
   - 時間をかけて実装した内容
   - 複雑なロジックを完成させた時
   - 動作確認が取れた状態

### 避けるべきコミット例

❌ **細かすぎるコミット**
- 1行ずつのコミット
- タイポ修正のみのコミット（他の変更と一緒にまとめる）

❌ **大きすぎるコミット**
- 複数の機能をまとめたコミット
- 異なる目的の変更を含むコミット
- 数日分の作業をまとめたコミット

### 実践的なアドバイス

- **迷った時は小さめに**: 大きすぎるよりも小さすぎる方が安全
- **レビューのしやすさを意識**: 1つのコミットで1つの変更意図
- **将来の自分への配慮**: 3ヶ月後に見返して理解できるかを考える

2. **コミット作成（追加機能）**

   - まず現在の変更状況を確認: `git status`
   - 変更差分を確認: `git diff`
   - 最近のコミット履歴を確認してコミットメッセージのスタイルを把握: `git log --oneline -5`
   - **上記のコミット粒度ガイドラインに従って適切な単位でコミット**
   - 変更内容に基づいてコミットメッセージを自動生成
   - 適切なファイルをステージング: `git add .` または特定ファイル
   - コミットを作成: `git commit -m "[自動生成されたコミットメッセージ]"`

3. **既存の PR テンプレートを確認**

   - `.github/PULL_REQUEST_TEMPLATE.md` のテンプレートに従う
   - ベースブランチとの差異を全て考慮して PR の内容を考案

4. **プルリクエスト作成**
   - 現在のブランチを origin にプッシュ: `git push -u origin [現在のブランチ名]`
   - `gh pr create` コマンドで PR を作成
   - ベースブランチは指定されたブランチを使用
   - タイトルと本文は変更内容とテンプレートに基づいて設定
   - PR は Draft の状態で作成する

## PR の作成例

PR URL: https://github.com/enechange/mobile-ev-app/pull/1587

＜テンプレートを貼り付ける＞

## 重要な注意事項

- 必ず日本語で PR 内容を作成してください
- PR テンプレートがある場合は必ず使用し、適切に記入してください
- ユーザーの承認なしには PR を作成しないでください
- エラーが発生した場合は適切にユーザーに報告してください

使用例

/create-pr release/2.5.0

コマンドに組み込んだガイドライン： - ドラクエのセーブポイントのイメージでコミット - 「何かあったらここまで戻りたい！」という単位 - レビューのしやすさを意識

今回は実験的に、自分では一切コミットせず、すべて AI に任せる方針で進めました。結果的に、適切な粒度でコミットしてくれました。

実際に使ってみた気づき

良かった点

  • テスト作成が本当に優秀：エッジケースまで考慮したテストを作ってくれる
  • コードの一貫性：既存のコンポーネントをちゃんと探して再利用してくれる
  • 開発速度の向上：機械的な作業から解放され、設計に集中できる

工夫が必要だった点

  • 既存コンポーネントの認識：「このコンポーネントは〇〇ページでも使われている」と教えてあげる必要がある場合がある
  • タスク粒度の調整：大きすぎるタスクは Plan Mode で修正が必要
  • 見当違いな実装への対処：タスクを記載しているNotionページの内容を少し具体的にする必要がある

正直な課題

  • PR 作成時の精度：変更点以外のことを含める場合がある
  • 初期設定のハードル：スラッシュコマンドの準備には時間がかかる
  • 完全自動化は難しい：最終的には人間のレビューと判断が必須

今後の展望：開発者の役割の変化

このフローが完成すれば、ほとんど人の手で実装をする必要がなくなりそうです。でも、それは開発者が不要になるということではありません。

むしろ、開発者の役割は： - より良い設計を考えること - AI への適切な指示を出すこと - 品質の最終チェックをすること

に変わっていくのかなと感じています。

まとめ

モバイル開発における「タスク分解→実装→PR作成」の流れを AI で自動化することで、開発効率が大幅に向上しました。完璧ではありませんが、機械的な作業から解放され、より創造的な仕事に集中できるようになったのは大きな収穫です。

この記事は、実際のモバイルアプリ開発プロジェクトで構築した AI 活用ワークフローを基に執筆しています。ENECHANGE では、こうした AI エージェント活用の知見を日々蓄積し、より効率的な開発プロセスを追求しています。

*1：Sentry エラーを Slack、GitHub 連携で Cursor と共に解析する未来 - ENECHANGE Developer Blog