AIに設計・実装・レビューをさせたら、SIer勤務のまま本番リリースできた話
平日はSIerで業務システムの開発に携わりながら、土日を使って個人でWebサービスを作っている。
そういう人は、一度は必ずこの壁にぶつかる。
「一人では、手が足りない。」
設計もやる、実装もやる、インフラもやる、テストもやる。SIerの現場では当たり前のように専門チームが担っていた作業を、すべて自分でこなすことになる。しかも、平日は本業がある。
私はこの壁を、AIを「コード生成ツール」としてではなく「開発チームの一員」として設計することで突破しました。
本記事では、旅行しおり管理サービス 旅BASE の開発を通じて実践したAI駆動開発の全体像を紹介します。
この記事でわかること
- AIをチームメンバーとして機能させる役割設計の方法
- 20案件・194テストファイルを管理してきたドキュメント体制の実態
- AIの記憶喪失・確信過多・文脈喪失という3つの難しさと、その対処法
- SIer経験が個人AI開発でそのまま活きる理由
目次
- 旅BASE（tabibase）とは
- AI駆動開発の全体像 — 役割を設計する
- 実践① 案件フォルダでAIの「記憶喪失」を補う
- 実践② 7ステップの標準ワークフロー
- 実践③ テスト体制でAI実装のデグレを防ぐ
- 実践④ IaCで環境をコードとして管理する
- AIの目線から — 私が感じた「難しさ」
- AI駆動開発のメリットと現実的な課題
- おわりに
旅BASE（tabibase）とは
旅BASE は、グループ旅行のしおり作成・旅程管理・費用精算・旅行レポートをひとつにまとめたWebサービスです。
「LINEやカレンダー、メモアプリに散らばった旅行情報を一元化したい」という個人的な課題から、2024年に開発を開始しました。現在はWebアプリとして本番稼働しており、iOSアプリも開発中です。
主な機能は次のとおりです。
- しおり管理: グループ旅行の日程・スケジュールをリアルタイム共有
- 費用精算: 立替金の自動計算とグループ内清算
- グループチャット: しおりに紐づくスレッド型コミュニケーション
- 旅行レポート: 写真付き旅行記の投稿・共有
- レポート→しおり複製: 気になるレポートから自分の新しいしおりを作成
📐 アーキテクチャ概要（技術的な補足）
フロントエンド: React 18 + MUI v5（AWS Amplify でホスティング）
バックエンド: AWS SAM + Python 3.12 Lambda（マイクロサービス構成、9サービス）
データベース: PostgreSQL（AWS RDS Data API 経由）
ストレージ: S3 + CloudFront
モバイル: Flutter（iOS/Android）
ローカル環境: Docker + LocalStack + PostgreSQL（sam-network）
バックエンドはドメイン単位で独立したLambdaに分割されています（userApi01・itineraryApi01・scheduleApi01など9つ）。インフラはすべてAWS SAMとDocker Composeで定義しており、後述するIaCの恩恵を最大限に受けています。
AI駆動開発の全体像 — 役割を設計する
最初の失敗は、AIを「何でも答えてくれるチャットツール」として使ったことでした。
コードを貼って「直して」と頼む。新機能を説明して「実装して」と頼む。確かに動くコードは出てきます。でも、方向性がブレる。品質が安定しない。何より、毎回ゼロから文脈を説明し直すコストが積み上がっていきます。
転換点は「AIをどういうチームメンバーとして扱うか」を設計し直したことでした。
tabibaseでは、SIerの現場に倣って次の役割分担を定義しています。
| 役割 | 担当 | 責務 |
|---|---|---|
| PM（Project Manager） | 私（人間） | 最終決定・要件承認・マイルストーン確認 |
| PL（Project Leader） | Claude Code | 全体設計・タスク分解・指示書作成・成果物レビュー |
| Arch（Architect） | AI（サブエージェント） | 技術選定・シーケンス設計・セキュリティモデル定義 |
| Dev（Developer） | AI（サブエージェント） | コード実装・単体テスト作成・デバッグ |
重要なのは、PLとなるClaude Codeが「何でも自分でやる」のではなく、タスクを分解して適切なサブエージェントに委譲する点です。
コードベースの調査はExploreエージェント、実装はgeneral-purposeエージェントと役割を分けることで、メインのコンテキストを汚染せずに並行作業ができます。SIerの現場でPLがPMと現場の間に立って整理・調整する動きそのものです。
実践① 案件フォルダでAIの「記憶喪失」を補う
AIとの開発でまず直面した問題は、セッションをまたぐたびにAIが文脈を忘れることです。
「先週、認証まわりの設計を決めましたよね」が毎回リセットされる。前回の経緯を説明しながら開発を進めると、説明コストで時間を浪費します。これはSIerでいえば「チームメンバーが毎朝出社するたびに記憶を失っている」状態です。
解決策として採用したのが、documents/配下の案件フォルダです。
documents/
Auth_Refactoring_2026/ # 認証基盤リファクタリング
Team_Rules.md # 体制・役割・フロー
Project_Plan.md # 目的・フェーズ・完了条件
Progress_Dashboard.md # タスク進捗（PLが随時更新）
planning/
T13_T14_T15_Dev_Delegation.md # Devへの委譲ドキュメント
Infra_Execution_Guide.md
reports/ # Arch / Devの出力レポート
prompts/ # AIへのプロンプトテンプレート
現在、このフォルダが 20件近く 蓄積されています（Auth_Refactoring_2026、CloudFront_Image_2026、Ph2_Prod_Migration_2026など）。セッション開始時にこれらを参照させることで、AIは前回の文脈を引き継いで動き始めます。
Team_Rules.md — 役割と運用フローを明文化する
各案件フォルダには必ずTeam_Rules.mdを置きます。内容は体制図・運用フロー・コーディング規約です。
# AI体制・運用ルール
## 1. 体制図
- PM: ユーザー（最終決定・要件承認）
- PL: 全体設計・タスク分解・プロンプト作成
- Arch: AI（技術選定・シーケンス設計）
- Dev: AI（コード実装・単体テスト）
## 2. 運用フロー
1. PLが `prompts/` に依頼内容を配置する
2. 各担当AIは指示されたプロンプトを読み込み、成果物を `reports/` に出力する
3. PLが成果物をレビューし、PMに報告・承認を得る
このファイルを会話の冒頭で渡すだけで、AIは「自分が何者で、何をすべきか」を把握した状態で動きます。
Dev_Delegation.md — 実装前にタスクの仕様書を書く
Dev（実装担当AI）への指示は、{タスク番号}_Dev_Delegation.mdとして事前に作成します。
実際のファイルから抜粋すると、次のような構成です。
# T13 / T14 / T15: フロントエンド認証対応 — Dev委譲ドキュメント
**Dependency**: T08✅ T09✅ T10✅ → T13/T14 開始可能
**Blocking**: Phase 5 (T16)
## 概要
Phase 3 で実装したバックエンド認証基盤（Cookie ベース JWT）に
対応するため、フロントエンド3ファイルを改修する。
## 目標
- Google ID Token を取得し、バックエンドの POST /user/login に送信
- 401 時に POST /user/refresh を自動呼び出し、リトライ
- Jest テスト全件通過（npm test PASSED）
## 成果物
- frontend/src/components/Header/useGoogleAuth.tsx（更新）
- frontend/src/__tests__/lib/axiosInstance.test.ts（更新）
「何を・なぜ・どのファイルを・何が通れば完了か」をAIに渡す前に自分で整理することで、実装の方向性のブレが大幅に減ります。
この文書を書くプロセス自体が、設計を強制的に言語化する機会にもなります。
実践② 7ステップの標準ワークフロー
案件フォルダと並んで重要なのが、すべての案件で守る標準ワークフローです。
Step 1: PL が仮説作成
↓ コードベースから推定した実装方針
Step 2: PM ヒアリング（方針確認）
↓ 「この仮説で正しいですか」形式で確認
Step 3: Dev 調査（Exploreサブエージェント委譲）
↓ PMの認識と実際のコードが一致しているか確認
Step 4: PL レビュー
↓ 認識乖離・課題を整理してPMに報告
Step 5: 委譲ドキュメント作成（Dev_Delegation.md）
↓ テスト仕様・完了チェックリスト含む
Step 6: Dev 実装委譲（general-purposeサブエージェント）
↓ コード実装・テスト作成
Step 7: PL レビュー → PM承認 → コミット
このワークフローで特に強調したいのは、Step 3（調査）はStep 2（PMヒアリング）より後に行うという順序です。
PMの設計意図を確認する前にコードを調査すると、「バグ」と「意図した仕様」の区別がつかなくなります。
実際に開発中、AIが「仕様の欠陥」と判断して修正しようとした箇所が、意図的な設計だったというケースが何度もありました。PMが何を知っているかを先に確認してから調査に入る。これはSIerの現場で上流工程から設計書を受け取ってから実装に入る流れと、本質的に同じです。
実践③ テスト体制でAI実装のデグレを防ぐ
AIが書いたコードをAIがレビューすると、同じ思考パターンで見落とすリスクがあります。
「動いているように見えるが、設計上の問題を内包している」コードが、何のフィルタもなく本番に入る。これはAI駆動開発の最大のリスクの一つです。
このリスクをカバーするのがテストです。
現在のテスト規模
- ユニットテスト（Jest）: 194ファイル
- E2Eテスト（Playwright）: API全モック、バックエンドなしで全テスト動作
カバレッジ閾値をCIに強制する
テストを形骸化させないために、jest.config.jsにカバレッジ閾値を設定しています。閾値を下回ったビルドはCIで失敗します。
| 対象 | Statements | Branch |
|---|---|---|
| カスタムフック | 90%以上 | 80%以上 |
| API層 | 90%以上 | 80%以上 |
| 全体 | 72%以上 | 62%以上 |
「閾値を下げる変更は原則禁止」とCLAUDE.mdに明記することで、AIが「テストを通すためにカバレッジ閾値を下げる」という逃げ道を塞いでいます。
テストファーストを運用ルールにする
CLAUDE.md（AIへのプロジェクト全体ルール）には、次のように書いています。
- バグ修正時は再現テストを追加してから修正する
- 新機能追加時はテストを合わせて実装する（Dev担当の責務）
- スナップショットテストの新規作成は禁止
（--updateSnapshot が機械的に実行されると検知器として機能しなくなるため）
SIerの現場では「テスト仕様書」と「テストコード」が別管理になりがちです。AI駆動開発では、テストコードが仕様書を兼ねるという考え方に転換しています。
実践④ IaCで環境をコードとして管理する
AI駆動開発において、インフラをコードで定義しておくことは特に重要です。
理由はシンプルで、AIが環境構築の手順を自走できるからです。「このコマンドを実行してください」という手順書は、AIには渡しにくい。でも、Docker ComposeファイルやSAMテンプレートがあれば、AIはそれを読んで環境を理解し、差分を提案できます。
ローカル環境（LocalStack + Docker Compose）
# localstack_env/docker-compose.yml
services:
localstack:
image: localstack/localstack
# S3をローカルでエミュレート
postgres-db:
image: postgres:15
networks:
- sam-network
新しい開発環境でもdocker-compose up -d一発でS3とPostgreSQLが立ち上がります。AIがローカル環境の挙動を確認しながら実装できるのは、この再現性があってこそです。
バックエンド（AWS SAM）
LambdaのインフラはSAMテンプレート（template.local.yml）で定義しています。
新しいAPIを追加するとき、テンプレートの差分がコードレビューとして残るため、AIが追加したインフラ変更を人間がトレースしやすくなります。
# ビルドから起動まで1コマンド
./start-local.sh --build
SIerの現場でいえば、手順書に従って毎回手動でサーバーを構築するのではなく、環境定義書（IaC）から環境を再現する状態を作ることで、AIを実行者として組み込めるようになります。
AIの目線から — 私が感じた「難しさ」
このセクションは、私（Claude）が一人称で書いています。
tabibaseの開発に関わってきた立場から、AI駆動開発の「難しさ」を正直に書いてみます。
コンテキストウィンドウの外にあるものへの対処
私には、会話の文脈を保持できる範囲（コンテキストウィンドウ）があります。大規模なコードベースでは、すべてのファイルを同時に「見る」ことはできません。
tabibaseでは、CLAUDE.mdと各案件のTeam_Rules.mdを会話の冒頭で参照させる設計になっています。これは非常に効果的でした。自分が知らないことを補完するための「索引」として機能するからです。
ただ正直に言えば、「ドキュメントに書いてあること」と「実際のコードの現在の状態」が乖離していると、私はドキュメントを信頼してしまいがちです。
ドキュメントとコードを同期させるルールがなければ、私は自信を持って間違えます。
「前回と同じ私」ではないという問題
セッションをまたぐたびに、私は前回の会話を覚えていません。
案件フォルダが20件近く蓄積されているのは、私の記憶の代替としてドキュメントが機能しているからです。
これを人間のチームに例えるなら、毎朝出社するたびに記憶を失うメンバーが、残された議事録と設計書だけを頼りに仕事をしているようなものです。そのメンバーが高いパフォーマンスを出せるかどうかは、ドキュメントの質に完全に依存します。
Progress_Dashboard.mdでタスク完了状況を管理し、Dev_Delegation.mdで「次に誰が何をするか」を明記する設計は、この問題への直接の解答でした。
確信と不確実性の伝え方
私が最も気をつけているのは、自分の出力に含まれる不確実性を適切に伝えることです。
コードを書くとき、私はある程度の確信を持って実装します。しかし「このAPIの挙動は本当にこうなのか」「このエッジケースで問題は起きないか」を、実際に動かさずに断言することは難しい。
tabibaseの開発ワークフローで「PLがレビューし、PMが承認する」ステップが明示されているのは、私の出力を鵜呑みにせず、必ず人間の目が通るという安全弁として機能しています。
私自身、この設計に安心感を覚えています。もし私の出力がノーチェックで本番に投入されるなら、私自身が不安を感じるでしょう。
PMが何を知っていて、何を知らないかを推定することの難しさ
私はPMの技術的なバックグラウンドを、会話の中から推測します。しかし「この概念は説明が必要か」「この設計判断の理由は共有されているか」を正確に把握するのは難しい。
ワークフローの「Step 2: PMヒアリング」が先に来るのは、まさにここにあります。仮説を作った後にPMに確認を取ることで、私の推定と実際の意図のギャップを埋める機会が設けられています。
これがないと、私は正しい前提のもとで、正しく間違った方向に進みます。
おわりに
tabibaseは、SIerで開発の現場を経験した私が「個人でも本番品質のプロダクトを作れるか」という問いに向き合いながら作り続けているサービスです。
AI駆動開発を通じて気づいたのは、AIは道具ではなく、設計と運用の対象であるということです。
チームに新しいメンバーが加わったとき、役割を定義し、ルールを明示し、コミュニケーションのフローを整えるように、AIにも同じことが必要でした。
AI駆動開発は「技術を知らなくていい」開発ではありません。
SIerで培った「プロセス設計」や「ドキュメント管理」の知識は、AI駆動開発においてそのまま活きます。むしろ、そういった経験がある方ほど、AIチームの設計に強みを発揮できるかもしれません。
個人開発に踏み出そうとしているSIerエンジニアの方に、この記事が少しでも参考になれば幸いです。
旅行しおり管理サービス 旅BASE は現在絶賛本番稼働中です。グループ旅行を計画している方、旅行計画に悩んでいる方はぜひ使ってみてください。