AI支援旅行アプリ「タベリエ」を、構造化ループエンジニアリングで作り上げた話
はじめに
旅行アプリ「タベリエ」はClaude Codeのみで開発しています。基本的にAIエージェント群が自律型で品質改善を図りながら進められるように工夫しています。タベリエそのものの紹介は前回の記事で書いたので、この記事では開発の進め方そのもの、つまり「AIエージェントをどう編成してきたか」だけに絞ります。
概要としては、自律型で実装と改善を可能にしています。自律型というとループエンジニアリングが浮かびますが、異なる点としては、ループを回すこと自体を目的としてWFを組んでいるのではなく、実PJと同じような形で体制を構築し、統制をかける仕組みを構造化することで、結果的に自律実行ができているという点です。本PJの第3者的存在であるCopilotにはこの仕組みのレビューのみを依頼したところ、「構造化ループエンジニアリング (Structured Loop-Engineering)」と名付けられました。段階的に進めてきた経緯もありますので、そのあたりをご紹介していきます。
フェーズ1: 1対1の壁打ち期(構想・モック)
最初は普通に、単体のAIチャットに相談しながら構想を練る期間でした。何を作るか、どんなデータモデルにするか、を1つのAIと会話しながら固めていく、いわゆる「壁打ち」です。部分的にモック作成も行いながら、イメージを固めていきました。
フェーズ2: PMを立てて、分業を始める
構想策定を経て今後の計画を立てる段階に入ってから、徐々に体制構築を進めていきました。まず、プランニングを担当し、今後のプロジェクトの全体進行を担うPMエージェントを立てました。他は必要最小限に、design(設計)、imple(実装&動作確認)、QA(レビュー&テスト) のエージェントを立て、PMからの指示に基づいて設計~テストまでが回る形にしました。私が直接会話するのはPMのみとし、私と確認した内容に基づいて、PMから各サブエージェントに指示が飛ぶ形です。実作業をするサブエージェントは常にクリーンな状態でAI最適化された指示が飛んできますし、PM役にも実作業を負わないルールを設け、コンテキストを汚さないように工夫をしました。
結果、私自身はPMに方針を伝えたり判断を下したりするだけで、PM配下で実装と検証が進んでいく体制ができあがりました。またループを回すための細かいルールを設定する必要はなく、PMとゴールを握るだけで残作業がある限り夜間も不在時も走り続けてくれます。
作業が回る体制の構築と同時に、品質対策を中心とした仕組みも入れています。基本的な考え方としては、私が実際のPJでやってきたことをAIの世界で回るようにすることです。
-
ナレッジの蓄積(
knowledge-base/): プロジェクト遂行に必要な技術情報、課題から得られた知見、市場調査の結果等を、ジャンルによってタグ付けして、担当を問わず参照できる場所に集約する。 -
設計開発標準の整備(
knowledge-base/standards/dev-standards.md/test-standards.md/design-standards.md): 設計及び開発を行う上でのルールを明文化し、アプリ構築の拠り所とする。 - 改善ループの土台: 欠陥が出たら、個別に直して終わりではなく、必ず振り返りを行い、Skill、ナレッジファイル、設計開発標準を更新し、再発防止策を講じるとともに、横展開調査を実施する。
フェーズ3: 「専門職」を増員する ― 開発を進めるにつれて気づいたこと
実装が形になってきたところで、3つの弱点に気づきました。UIが洗練されていないことと、市場調査・PR準備が足りていないこと、特商法対策等の準備が不十分であることです。
ここで、開発チームに新しい役割を"雇い入れ"ました。UI/UXデザイナーとマーケティング担当と法務担当です。それぞれ専門知識を集めるところから始め、Skillとしてプレイブック化しました。前述のとおり、私が会話する主セッションはあくまでPMのみですので、PMの指示に基づき、アプリ設計実装テスト、UI/UXの改善検討、競合調査を中心としたマーケティング調査、マネタイズに向けた準備・法務レビューが、サブエージェントとして並行で進めることができています。
- UI/UXデザイナー役は、実装担当とは別の視点で画面を通しでレビューします。実際、
docs/app-ui-review.mdという「UIデザイナー役の第2パスレビュー」の記録が残っており、ボタンの誤色(削除以外の操作なのに赤い「削除する」ボタンが出る)、コントラスト不足(text-slate-400がライト/ダーク両方でAA基準未達)、トーストが表示されないまま消えるモーダルなど、実装担当だけでは気づきにくい種類の指摘が積み上がっていきました。 - マーケティング担当役は、キャッチコピーの検討やPRページの構成案を作りました。紹介ページ(
#/about)の4スライド構成やキャッチコピーは、docs/marketing.mdの提案がそのままコードに転記されています。 - 法務担当役は、マネタイズに向けた特商法対策等の各種準備を進めながら、既存アプリの設計・実装を確認し、法的観点からの抜け漏れがないかをチェックしています。
面白いのは、「専門職を追加した」ことで、逆に"実装担当だけでは踏み込めない領域"がはっきり見えてきたことです。役割を分けるというのは、単に作業を分担するだけでなく、「誰の目が今どこに入っているか/入っていないか」を可視化する効果もありました。ちなみにタベリエという名前は、旅とアトリエ(工房)をもじって作成された名前ですが、アトリエというブランドコンセプトの検討や、名前そのものは、更に後続で作成したブランディング担当が複数の案を出し、マーケレビュー、PMレビューを経て、最終決定しています。大事なアプリの名前なので、もちろん私もアイデアを出したのですが、類似の名前があり却下となりました(笑)
フェーズ4: 重大インシデントの続発と、統合役の配置
プロジェクトが進行するにつれて、いくつかの問題が発生しました。
ローンチ当日、実際に離脱を生んだCTA不具合
公開直後、Xのローンチ告知に載せたURLが # 抜きの実パス /about だったため、初日約50人が訪問したにもかかわらず、「無料で始める」ボタンを押しても画面が変わらず、その多くが離脱するという実害が出ました。
真因はハッシュルーターの継ぎ目でした。招待コード・共有コードをサーバーログに残さないためアプリ全体は#/...のハッシュルーティングを採用していますが、aboutページだけSEO目的で実パス/aboutも持っていました(router.tsのPATH_ROUTES)。CTAのnavigate('#/')はハッシュを書き換えるだけで、実パス起点だとその変更がpathname側の正規化に負けてしまい、ボタンを押しても反応していないように見えていたのです(docs/history.md 2026-07-19「aboutページのCTA『無料で始める』がPCで反応しないバグを修正」)。
この経験がそのまま、「外部に配るURLは実ブラウザでボタンまで押して確認してから渡す」「表記を統一し、どちらが正規のURLか誰が見ても分かるようにする」という運用ルール(knowledge-base/decisions/外部に配るurlはハッシュ付きに統一する.md)につながっています。
人間からすると当たり前ですが、確かに言ってなかったなと。優秀なAIエージェント群ですが、ときどき考えられないような大ポカが出るので、都度ルールを整備していっています。
「PMは作業を持たない」を厳格化する
もう1つ、体制そのものの欠陥も見つかりました。PM(統括役)自身が"細かいから"という理由で直接コードを書いてしまい、QA担当のレビューを通さずに私に報告するという挙動を見せていました。結果、普段のプロセスを回したときよりもかなりクォリティの低い成果物があがり、大幅に工数をロスしました。なぜルールを守らなかったのかを聞いたところ、「軽微な修正だったから」という回答がありました。人間のPJでも見た気がします。ルールを厳格化するとともに、進めてきた体制の効果を実感できました。
他にも、ステージングのミス発覚時に、ステージング担当を足してQAにチェックさせるようにしたり、プロジェクトの進行に伴い、体制とプロセスを改善しながら進めてきています。この改善案も、それ専用の担当に考えさせています。
おわりに。この記事で言いたいこと
この1年でAIエージェントによる開発はかなりの進化を遂げ、それと同時に活用方法論も日々進化していると思います。もちろん唯一の正解などない中で、皆さん様々な工夫をしていると思いますが、QCDの観点でひとつの実績となったと考えていますので、ご参考頂ければ幸いです。また、アプリを使ってみてください(笑)
開発の様子や技術的な工夫は前回の記事にも書いているので、よければあわせて読んでみてください。
ひとつ次の記事がこちらです。
(https://zenn.dev/torukona/articles/e87a8981c88ebf)
Xアカウントです。もし良かったらフォローお願いします。
→ タベリエ: https://x.com/torukonauk
アプリも育ってきました。紹介ページだけでも見ていただけると嬉しいです。
→ タベリエ: https://tabelier.torukona.uk/?ch=zenn002#/about
Discussion