🎋 はじめに
11月ごろから知り合いと個人開発をスタートしました。
マネタイズまで行い、今後も様々なサービス開発を行っていく予定なのでAIを用いた高品質ハイスピードな開発を仕組み化して活用できるようにしようと思っています。
備忘録&アウトプットも兼ねて自分の環境紹介になります。
ちなみに、この記事は8割以上人力で書いてます。
🛀 開発フロー
要件・タスクを決めるところから、マージするまでのフローはざっくりとこのような感じになっています。
要件・タスクを決める or 定期的なリファクタリング
↓
決まった要件・タスクをGithub Issue化
↓
Issueの優先度・スケジュールを整理
↓
Issueをもとに実装
↓
PRを作成
↓
セルフレビュー・CodexがPR上でレビュー
↓
マージ
この部分で人力が絡む部分は、
- 要件・タスクを決める
- Issueの優先度・スケジュールを整理
- セルフレビュー
になります。それ以外はほぼAIにお任せです。
Claude Codeを用いた開発ワークフロー
2026年1月現在1 だと、人の役割は責任を持つことだと思っているのでサービス全体の責任を負うために必要な部分は人力で行い、それ以外に任せられる部分はAIに任せるスタンスです。
ちなみにAIエージェント・ツールはこのような感じで使い分けています。
| ツール | 主な用途 | 具体的な使い方 |
|---|---|---|
| Claude Code | メイン開発 | ・Issue作成 ・実装計画立案 ・コード実装 ・PR作成 |
| Cursor | 補助的な修正 | ・細かいバグ修正 ・UI微調整 ・その場でのコード確認 |
| Codex | レビュー専用 | ・PR作成時の自動コードレビュー |
Claude Codeをメインにした理由は、スラッシュコマンドやSkillsなどカスタマイズ性が高く、自分好みの環境が作りやすいからです。
次章からAIに任せている部分において、どのようにAIを活用しているかを書いていきます。
🗓️ 決まった要件・タスクをGithub Issue化
個人開発とはいえ、知り合いの方とサービス開発を行っているので毎週決まった曜日に定例があります。その議事録をもとにタスクに分解したり、実装中に発見したバグやリファクタリング箇所をタスク化したり、新機能開発の際にタスク化を行います。
それらのタスクをGithub Issueに落とし込む際に、スラッシュコマンドを用いています。
このコマンドではタスクをもとに、現在のコードを読み込み、どこを実装するか、どのような実装をするかのおおまかな実装計画を立ててissueを作成してくれます。
その際に、曖昧な要件があればユーザーに質問するようにしており、この過程で自分自身も要件漏れに気づくことができるため便利です。
また、複数個まとめてissue化することができ、issue同士の関連も記入してくれます。
細かいバグの修正や後回しにしたいリファクタリングも、とりあえずターミナルを開いて、コマンドとともに簡単に記入しておけばissueとして管理できるためタスクの抜け漏れも減りました。
/create-issue いいねページにおいて、マッチングをした時に、エンジニア側は案件がマッチングした表示UIになるが、表示するのはその案件によってマッチングしたユーザーだけにする。
...（略）...
⏺ 現状の実装を理解しました。
現状:
- エンジニア側のマッチングタブには2つのセクションがある:
a. 「案件とのマッチング」: CompactProjectCardで案件を表示
b. 「ユーザーとのマッチング」: MatchingCardでユーザー（依頼人）を表示
- 問題: 案件マッチングで案件カードを表示しているが、その案件を通じてマッチングした**ユーザー（依頼人）**を表示すべき
要件を確認させてください。
⏺ User answered Claude's questions:
⎿ · 案件マッチングの表示形式はどちらが良いですか？ → ユーザーのみ表示
⏺ Bash(gh issue create \
--title "エンジニアの案件マッチングタブで案件ではなくマッチングしたユーザーを表示する" \…)
⎿ https://github.com/KH37/****/issues/230
⏺ issueを作成しました。
作成したissue:
- #230: https://github.com/KH37/****/issues/230
変更内容:
- 現状: 案件カード（CompactProjectCard）を表示
- 変更後: その案件を通じてマッチングした依頼人のユーザーカードを表示
- 連絡先交換UI（ContactDisclosureStatus）も表示
補足:
- 同じ依頼人と複数案件でマッチングしている場合は、案件ごとに別カードとして表示する方針で記載しました（どの案件でマッチングしたか分かるように）
（↑怪しい日本語でも意図を汲み取ってくれる）
✏️ issueをもとに実装する
ここもスラッシュコマンドを用いて実装します。
/implement-issue 133
のようにコマンドと共にissue番号を渡せば、そのissueを読み込んで計画を立て、実装を開始してくれます。
/implement-issue 133
...（略）...
Issue #133 実装計画
概要
home/page.tsx（約400行）をドメインコンポーネントに分割し、責務を明確化します。
現状の問題点
ホームページがユーザータイプによって複雑に分岐している
依頼人でサブスク未入会の場合にリダイレクトが発生（UX悪い）
freelancer_client タイプへの対応が必要
実装計画
1. コンポーネント構成
ARCHITECTURE.mdに従い、client/components/features/home/ に配置します：
...（略）...
実装完了
Issue #133 の実装が完了しました。
変更内容のサマリー
新規作成ファイル ...
...（略）...
🧑💻 PR作成
PR作成のような定型的な作業も当然スラッシュコマンドで行います。
/create-pr
👀 セルフレビュー
セルフレビューはスラッシュコマンドを用いてskillを動かしながらレビューを行ってもらいます。
レビューする観点を3つに分類し、それぞれのskillがそれに対応してもらいます。
レビュー観点:
- 一般コードレビュー - ロジック、可読性、パフォーマンス、エラーハンドリング
- アーキテクチャレビュー - アーキテクチャパターン準拠、コーディング規約
- セキュリティレビュー - 認証・認可、入力バリデーション、機密データ取り扱い
また、Codexにリポジトリを連携させて、PRを作成したら自動でレビューする設定も行いました。
何気にいいレビューをくれるのでおすすめです。
⚙️ 定期的なリファクタリング
この記事を読んでやっぱり定期的なリファクタリングはAIドリブン開発で重要なんだなと感じました。
この記事を参考に、リファクタリングする箇所を見つけてくれるスラッシュコマンドを作成して、定期的に実行しています。
7つのサブエージェントを用いて、それぞれの観点からリファクタリング箇所を包括的に検出してもらっています。
分析観点
- コード品質・可読性 - 重複コード、長すぎる関数、不明確な命名
- 型安全性 -
any型の排除、型ガード、Zodバリデーション - アーキテクチャ整合性 - 層間依存ルール、ビジネスロジックの配置
- API設計 - エラーハンドリング、HTTPステータスコード、トランザクション
- パフォーマンス - N+1クエリ、再レンダリング最適化、画像最適化
- テストカバレッジ - 重要パスのテスト、エッジケーステスト
- セキュリティ - バリデーション、認可チェック、機密情報保護
リファクタリング箇所検出に使用しているサブエージェント
これらのサブエージェントはプロジェクト配下に作成しているので、プロジェクトに適応したエージェントになっています。
🤖 まとめ
現状のAIを用いた開発環境の紹介でした。
使用しているスラッシュコマンドやSkillsはこちらにまとめてあります。
この開発環境は常にアップデートしていく必要があり、様々な記事でもその必要性が書かれていました。
そのため来週には全く別物になっていたり、新しいものが追加されていることもあります。
目まぐるしく進化していく生成AI周りに追いついていかなければという楽しみと焦りがあります。
また、個人的に人間とAIの違いで意識していることは
- AIは責任を負うことができない。責任を負うのは人間
- 0→1が得意な人間と、1→♾️が得意なAI。人間がコンテキストを生み出し、そのコンテキストをAIが活用する
です。
この違いも将来なくなる可能性があるんだろうなという未知の恐怖感。
最後に
twitter始めました
フォローお願いいたします！
https://x.com/hasegawa_kei
-
2026年1月現在と書いたのは、「AI 2027」の記事を読んで感化されたからです。AIと人間の立場が逆転して、AIが責任を負うことになる将来があるのかなぁなんて思ったり。 ↩