『GOエコノミー 』(相乗りサービス) におけるスペック駆動開発

GO TechTalk #34 データサイエンティストの生成AI活用で発表した資料です。

■ YouTube
https://www.youtube.com/watch?v=7t9fIeBU2MQ
■ connpass
https://jtx.connpass.com/event/370877/

Transcript

1. 『GOエコノミー 』(相乗りサービス) におけるスペック駆動開発 GO TechTalk #34 データサイエンティストの生成 AI活用 福島 大祐 GO株式会社
2. GO株式会社 AI技術開発部 AI1グループ / 福島大祐 2020年に株式会社マイクロアドに入社後、広告オークションにおける配信最適 化に従事。その後、製造業 DXスタートアップでのリサーチャーを経て、 2026年1 月にGO株式会社に入社。 アルゴリズム開発やデータ分析やってます。チーム内では一番新入り。 趣味は猫、マラソン (初心者) © GO Inc. 2
3. アジェンダ ▪ ▪ ▪ ▪ 背景：相乗りサービスの開発 バイブコーディングの限界 スペック駆動開発の導入と仕様書の管理方法 蓄積された仕様書の資産活用 © GO Inc. 3
4. 01 背景 〜相乗りサービスの開発〜 © GO Inc. 4
5. 相乗りサービス『GOエコノミー』 東京都心エリアで展開中 タクシーの最大約半額※ なぜお得なのか？ ▪ 近くのスポットを選んで乗降 ▪ 同じ方面のお客さま同士で同乗の可能性あり ※ 一部手順省略 ※ 通常のタクシーの運賃・迎車料等の約50~90％の価格（事前確定運賃計算方法に基づく）/ 1席分 © GO Inc. 5
6. サービスを支えるアルゴリズムサーバー ここ開発してます バックエンド API ユーザー アプリ アルゴリズム サーバー ▪ ▪ ▪ コールバック 配車 プラットフォーム 情報取得 リアルタイムETA サービス (予約/運行管理) アルゴリズムサーバーの役割 ▪ 予約・運行管理 ▪ APIリクエスト駆動で検索・提案・ キャンセルなど ユーザーや運行の状態管理や配車依頼 ▪ 一定周期のバッチ処理（運行最適化） ▪ 経路データ、提供エリア関連のデータ生成 ▪ 車両配置最適化など ▪ 探車・配車依頼 ML予測 サービス 相乗りマッチング MySQL データ生成 BigQuery / S3 配給計画 役割が多岐にわたり複雑 & 「相乗り」という特殊なドメイン (※) ETA (Estimated Time of Arrival): 到着時間予測 © GO Inc. 6
7. AI開発が当たり前になりつつある。 複雑なドメインでAI開発は機能するの？ © GO Inc. 7
8. 02 バイブコーディングの限界 © GO Inc. 8
9. バイブコーディングとは？ AIに自然言語で指示しながら、対話的に開発するスタイル 手順 (WIP) バイブコーディングの図挿入 1. 2. 3. やりたいことをAIに伝える AIが実装 対話的に修正指示 「まず動くものを作る」までは非常に強力 © GO Inc. 9
10. バイブコーディングの限界 バイブコーディングは「部分的に動くものを作る」ことはすごく得意 ◦◦機能追加して </> 開発者 AI 部分的な実装 一見動作する ただし、規模が大きくなると Context Drift チャット履歴が流 れ初期要件を忘却 他の機能との不整合 機能追加のたび に別の場所が壊れる 統一性のない開発 実装方針がバラバラ で一貫性が失われる 収拾がつかないことに。。。 © GO Inc. 10
11. バイブコーディングの限界 『GOエコノミー』のアルゴリズムサーバーは非常に複雑 複雑なアルゴリズム 非同期処理・外部連携 • 経路生成 • 相乗りのマッチング • 運行最適化 • 運行・ユーザー状態管理 • 機械学習・統計処理 etc. • 車両探索依頼 etc. このような複雑性を持つ開発では特に、 対話ベースの場当たり的な実装では全体の整合性を保てない © GO Inc. 11
12. AIがシステム全体の「仕様」を理解し、 要求を正しく解釈しながら開発できる枠組みが必要 （＝「何を作るか」を合意してから実装させる） © GO Inc. 12
13. 03 スペック駆動開発の導入 © GO Inc. 13
14. スペック駆動開発とは スペック駆動開発（SDD: Spec-Driven Development） ▪ コードを書き始める前に、「仕様(Spec)」を明文化 ▪ 仕様書を「唯一の正解 (Source of Truth)」として、AIエージェント に参照させながら実装させる ▪ AIエージェントがシステムの全体仕様を把握できる ▪ → 整合性が保たれた開発が可能 ▪ 仕様書という前提知識が残るため、会話の文脈が切れてもAIがコン テキストを保ったまま実装を進められる © GO Inc. 14
15. SDDの基本サイクル 代表的なSDD開発ツール ▪ GitHub Spec Kit ▪ ▪ SDD実践のためのCLIツール (内部はエージェントスキル) ▪ SDDを前提にしたAI IDE Amazon Kiro GitHub Spec Kitの主要サイクル 1. Specify : 要件整理 → 成果物 spec.md 2. Plan : 技術設計 → 成果物 plan.md 3. Tasks : 実装タスクへの分解 → 成果物 tasks.md 4. Implement : AIエージェントが実装 5. converge : 仕様を満たしているか検査 © GO Inc. 15
16. Claude Codeの自作SKILL群として導入 SDD導入する上での検討事項 ▪ Spec Kit や Kiro は有用な実践例 ▪ ▪ 一方で、プロセスや成果物が固定化されやすい 導入初期は試行錯誤しながら運用を確立したい → Claude Codeの自作SKILL群でSDDプロセスを実装 SDDの思想を取り入れつつ、運用はチームに合わせて柔軟に © GO Inc. 16
17. SKILL構成 ▪ /idea ▪ /specify ▪ ▪ ▪ .steering/YYYYMMDD-<name>/idea.mdを新規作成 「背景・目的・実現したいことを記載」（対話ベースで書かせてる） ▪ ▪ idea.mdを読み込み、仕様書を新規作成・更新 仕様書の種別に応じて、以下サブスキルを呼び分ける ▪ /uc-design, /entity-design, /algorithm-design, /grpc-log-spec ▪ 仕様書の種別と管理に関しては後述 変更箇所のユーザー承認を得たら、workplan.mdを作成（何を実装するか合意） ▪ /implement ▪ workplan.mdを読み込んで、どのタスクまとめて実装するかユーザーに確認してから実装 仕様書を唯一の正解とし、仕様書にない挙動は実装しない ▪ 内容に応じてAIが判断するが、大体全タスクまとめて実装することが多い デフォルトはTDD(テスト駆動)で実装。完了後はテスト結果を通知して承認を得る ▪ ▪ 実装内容と仕様書の整合性を確認し、ズレがあれば仕様書を修正 仕様書↔実装ファイルの相互参照を追記 ▪ ▪ ▪ /finalize © GO Inc. 17
18. /implementの実行例 (雰囲気のみ) © GO Inc. 19
19. スペック駆動開発において仕様書(Spec)の管理は重要 どのように管理するのがいいのか？ © GO Inc. 20
20. AIが迷わない仕様書体系 仕様書はAIエージェントが作成・更新 (/specifyで実行)する （人間ではなくAIが編集する → AIが迷わないような仕様書管理が大事） 「まず全体を理解してから詳細を見る」 導線を提供することが重要 ▪ 階層的に管理 ▪ ▪ ▪ ▪ L1 : Project Context ▪ 全体ルール ▪ 機能の振る舞い ▪ 複雑なロジック、外部連携詳細 L2 : Use Case Spec L3 : Tech Detail 概要 → 詳細の順で理解可能なように下階層への参照を記載 © GO Inc. 21
21. 仕様と実装の整合性を保つ仕組み /finalize フェーズ ▪ 実装が仕様書通りかを確認 (仕様書と実装の相互参照) GitHubでコードと一緒に管理 ▪ Pull Requestで仕様変更をレビュー ▪ コードと仕様の乖離を防ぐ [重要！] 組織として取り組む ▪ 『GOエコノミー』のアルゴリズム開発では、基本的な開発はSDDで 行うことが前提 (更新されなくなったら陳腐化する) ▪ 「普段の開発フロー」として定着させることで更新が継続 ▪ ▪ 仕様書の差分が増えるため、PRの説明文を整えるSKILLなども整備され た チームでのAIとの向き合い方のアップデートも重要 © GO Inc. 22
22. SDDを導入した効果 (開発の高速化) ▪ SDDの型に乗ることで、 ▪ 仕様検討から開発→整合性確認を問題なく一通り回せる （仕様書があることで、新機能開発時の影響範囲調査も容易） ▪ 複数の機能追加を並行して開発可能に （コンテキキストが仕様で管理されるので、切り替えも容易） ▪ 自分でコード書くことはほとんど無くなった ▪ 毎回同じ手順を踏むことで、再現性高く高速に開発できるように なった © GO Inc. 23
23. SDDを導入した効果 (キャッチアップ負荷の低下) 実装と仕様が常に紐づいている ▪ 仕様書を読むことで、全体像を素早く把握 ▪ AIが仕様をベースに実装意図も含めて説明してくれる → 属人化の軽減 この処理の 意図は？ 開発者 この処理は 〇〇という 要件を満た すためのも のです 仕様とコードを 照らし合わせて回答 © GO Inc. 24
24. ただし ドメイン知識が不要になるわけではない ▪ 高度なことはAIエージェントがやってくれる (機能追加など開発はかなり高速化) ▪ これまで以上に分析や改善施策が妥当かどうか判断する必要が重要 © GO Inc. 25
25. 04 今後に向けて、 開発以外での仕様書の資産活用 © GO Inc. 26
26. SDDで溜まった仕様書の有効活用 SDDにおいては、仕様書の精度が開発の精度につながる 精度の高い仕様書 → 精度の高い開発 SDDを運用し、精度の高い仕様書が拡充してきたことで、 副次的に他の用途でも活用できた 実例を紹介 ▪ 検索：biz向けの仕様検索システム ▪ 分析：ML予測の精度改善分析 © GO Inc. 27
27. 活用例①：Biz向けの仕様検索システム 仕様書からINDEXを生成し、仕様書に基づいて回答される © GO Inc. 28
28. 活用例②：分析での活用 ロジックやログ出力に関する仕様書があるおかげで、AIエージェントが 自律的に分析・改善の検証を実施可能 予測の精度改善 したいのだけど... アルゴリズム ログ出(grpc) の仕様書 の仕様書 仕様調査 開発者 仕様を元に調査実行 BigQuery 実際に需要予測の精度改善を確認し、リリース済み © GO Inc. 29
29. 05 まとめ © GO Inc. 30
30. まとめ ↓ ▪ 課題：複雑なドメインではバイブコーディングが機能しなかった ▪ スペック駆動開発と仕様書の管理により解決 （コードを書くことはほぼ無くなった） ▪ 仕様書は「人間が読むもの」→「AIエージェントが読んで動くもの」に。 それに合わせた管理方法が重要 ▪ 仕様書がコードとセットで管理されることで、副次的な効果も ▪ 不具合調査、分析、仕様検索にも生成AIが活用可能に これからの働き方 AIエージェントと協業することを前提とした開発フローの設計が重要 © GO Inc. 31
31. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください © GO Inc.