Upgrade to Pro — share decks privately, control downloads, hide ads and more …

上流工程からAIを組み込むと開発はどう変わるか?半年〜1年規模の施策における仕様駆動開発の事例

 上流工程からAIを組み込むと開発はどう変わるか?半年〜1年規模の施策における仕様駆動開発の事例

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  MIXI MEETUP!AI DAY 2026 - SESSION ARCHIVE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

上流工程からAIを組み込むと開発はどう変わるか?半年〜1年規模の施策における仕様駆動開発の事例

minimoでも積極的にAIの活用に取り組んでおり、そのうち今回はSpec Kitを活用した仕様駆動開発の事例となります。エンジニア2名体制でも半年〜1年ほどかかる施策に対し、企画段階から実装までAIを組み込み、具体的にどのように開発を進めていったか、導入した結果、通常の開発フローと比較してどう改善したか、その他細かいTipsなどを紹介できればと思います。

Vantageスタジオ/minimo事業部/開発3グループ/AI推進チーム
洗川 雄輝

────────────────────────────
□セッション情報
https://mixi.connpass.com/event/380889/
□イベントハッシュタグ
#miximeetup2026
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◇◆◇ Information ◇◆◇
◎ エンジニアSNS/メディア
X
https://x.com/mixi_engineers
MIXI Developers Blog (medium)
https://mixi-developers.mixi.co.jp/
Slide (SpeakerDeck)
https://speakerdeck.com/mixi_engineers/

◎デザイン職メディア
MIXI DESIGN note
https://note.com/mixi_design/
MIXI DESIGN Cocoda
https://cocoda.design/teams/mixi-design
Slide (SpeakerDeck)
https://speakerdeck.com/mixi_design/

◎採用情報
https://mixigroup-recruit.mixi.co.jp/

HP
https://mixi.co.jp/
X
https://x.com/mixi_PR
connpass
https://mixi.connpass.com/

Avatar for MIXI ENGINEERS

MIXI ENGINEERS PRO

April 06, 2026

More Decks by MIXI ENGINEERS

Other Decks in Technology

Transcript

  1. ©MIXI プロジェクトの規模と対象 中⻑期的な施策における開発要件 技術‧ドメイン要件 広範なシステム領域と深い業務知識の要求 半年~1年規模となる開発プロジェクト CS (カスタマーサポート) 関連の施策 新機能の追加と、既存機能の拡張が主⽬的

    フロントエンド、バックエンド、運営⽤の管理 ツールすべてにまたがる実装が必要 CS全体を網羅する施策にあたるため、深いドメ イン知識が必要 > > > > > 今回の開発対象
  2. ©MIXI 認識齟齬による⼿戻り 要件定義から実装までの間にド キュメントが陳腐化。いざ実装す る段階になって仕様の⽭盾や抜け 漏れが発覚し、⼤規模な⼿戻りが 発⽣する ドメイン知識の属⼈化 特定のCS担当者やPMの頭の中に 詳細な知識が存在。エンジニアが

    真の要件を把握‧吸収するのに⼀ 定コミュニケーションコストを要 する 影響範囲特定の困難さ システムが広範であるため、仕様 変更が発⽣した際の影響調査とテ スト項⽬出しが⼿作業となり、開 発⼯数に与える影響は⼤きい 従来の開発⼿法の課題
  3. ©MIXI 上流⼯程からのアプローチ 実装やテストといった「後⼯程」 からではなく、要件定義や仕様策 定といった開発の最上流からAI エージェントを組み込み効率化 明確化によるブレの排除 ⾃然⾔語からシステムの振る舞 い、データモデル、API仕様まで をAIと共に⼀貫して定義。暗黙知

    を明確化し、⼈間同⼠の解釈のブ レや曖昧さを早めに排除 実装へのシームレスな移⾏ AIとの対話で明確に定義された仕 様書から、そのまま実装フェーズ へシームレスに移⾏。開発効率と 品質を⼤きく向上させる可能性が ある AIを⽤いた仕様駆動開発とは
  4. ©MIXI Spec Kitは、仕様駆動開発を実現する上で使⽤可能なツール GitHub提供の フレームワーク GitHub等が公開しているベストプ ラクティスに基づき、⾃律的な コーディング環境を構築 CLIツールとの シームレスな連携

    Claude Code等のCLIツールと組み 合わせ、ターミナル上から直接AI と対話。仕様策定から実装までを ⼀元管理可能 コンテキストの 深い理解 プロンプトやMarkdownを通じ、 AIエージェントにプロジェクトの ⽂脈やルールを深く理解させ、⼀ 貫性のある開発を実現 開発を加速する「Spec Kit」
  5. ©MIXI 憲法の制定 プロジェクトの開発スコープや、AIに守らせ たい絶対的なルールを定義 Tips: AIの挙動安定のため、「作業終了時に仕様書 側のCLAUDE.mdも作成‧更新すること」と明記 し、AIの精度を底上げさせている 具体化 解釈のズレを無くし、全員が「何を作るべき

    か」を100%理解する最重要フェーズ Tips: ボリュームが⼤きい場合は、Markdownファ イルを適切に分割して読み込ませることでコンテキ ストサイズ超過による情報の抜け漏れを防⽌ プロジェクト名称、参照リポジトリの徹底、⽇ 本語使⽤、セキュリティ要件などを指⽰ モブプロで仕様を記述して実⾏後、AIから不明 点を質問させるなどして徹底的に仕様を明確化 > > Phase 1: 仕様の定義と明確化 ※本開発ではClaude Codeを利⽤しています。
  6. ©MIXI 技術計画 「何を作るか」が確定後、「どう作るか」と いう技術的な計画をエンジニア主導で⽴案 Tips: 等の不明瞭な項⽬は随時AIに 質問を投げかけながらレビューを実施し、設計の精 度を向上 タスク化 承認された設計ドキュメントをもとに、実際

    の実装に向けた具体的な作業単位 (タスク) へ と落とし込む Tips: タスクのリストアップ後、AIに依存関係や論 理破綻がないか最終確認(セルフチェック)させ、 ⼿戻りのリスクを最⼩化 アーキテクチャ設計、APIの定義、データ構造 などを具体化 や コマンドを併⽤ > > Phase 2: 設計とタスク分解
  7. ©MIXI 実装 洗い出したタスク情報と蓄積されたコンテキ ストをもとに、AIエージェントに実際のコー ド実装を実⾏させる スケジュール⽣成の⾃動化 タスク分解までAIが⾏っているため、スケ ジュールの策定もAIに委譲可能 結果を に出⼒させる⽅法は、会社への

    説明等の場⾯でも活⽤できるためオススメ マルチリポジトリ構成において、リポジトリ参 照はSpec Kit実⾏者のリポジトリパスをプロン プトで付与 submodule化の⼿⽴てもあったが、検証も兼ね ており更新の⼿間を考慮して回避 メンバーの⼈数情報や⽇本の暦(祝⽇など)をプ ロンプトとしてAIに渡し、⼯数とスケジュール を算出させている > > > Phase 3: 実装とスケジュール⽣成
  8. ©MIXI ※規模によっては問題にならないケースもありました 観点 理想(Ideal) 現実(Reality) 実装の⾃動化 ⼀⽇放置していれば、全ての実装が終わっている そんなことはなく、コンテキストサイズの観点で 実装漏れなどはやはり発⽣する コード品質

    憲法や仕様を定義しているため、最初から本番 運⽤レベルの⾼品質 ⾼いと⾔えば⾼いが、結局⼿直ししなくてはなら ない箇所は出てくる ドキュメント運⽤ ここで⽣成したspecファイルをドキュメントと して扱っていく AI向けの記述であり、そのままドキュメントとし て運⽤できるかは悩ましい点がある 仕様の網羅‧追従 仕様漏れがなく、追加仕様などがなければ更新 することも少ない 仕様漏れはあり、修正が⼿間で軽微ならドキュ メントを直さず直接AIに実装させることも 仕様駆動開発の「理想と現実」
  9. ©MIXI プロジェクト全体の開発期間を約45%前後削減することに成功 仕様策定フェーズ 実装フェーズ 仕様書作成の段階から、全メンバーが集まりモ ブプロ形式で進⾏ specファイルのレビューに時間を要するが、従 来の仕様書作成‧レビューとほぼ同等のタスク にあたるので、そこまでネックにはならない 仕様の精微化において⾼い精度を発揮し、モブ

    プロ形式も相まって数%程度の短縮に成功 実装フェーズは明らかに短縮(全体の短縮分の ほとんどがこのフェーズ) AIエージェントが実装するのでコーディング時 間は当然短縮される 通常のAIエージェント利⽤時と⽐較しても、都 度仕様書を読み込ませて‧プロンプトを構築し て‧Planレビューして、などが発⽣しなくなる ので、明らかに早い > > > > > > 時短効果
  10. ©MIXI 最⾼級のPlanモード 完全⾃動化には⾄らなくとも、曖 昧な要件を整理し、的確なアーキ テクチャおよびタスク設計を⾏う 「Plan」機能としては、現状考え うる最⾼レベル(他⼈と共有可) 割り切った運⽤⽅針 specファイルはAIの可読性を重視 しているため、あくまでPlanモー

    ドとして扱い、ドキュメントは別 途⽤意する「割り切り」も規模に よっては必要 圧倒的な時短効果 理想と異なる泥臭い現実は多々あ るが、結果として「開発期間を約 45%削減できた」事実は揺るぎな く、⾮常に効率的な開発⼿法だと 実感 振り返りと得られた知⾒
  11. ©MIXI ⼤規模PJでの課題 ⼀つのspecファイルに全てを記述すると膨⼤ すぎて取り扱いが困難に 上記のように、機能単位で仕様書 (ディレクト リ)を分割する運⽤を検討 レビューコスト⼤ 実装スピードが上がる反⾯、⼈間のボトル ネックが顕在化

    specs/ 000-common/ 001-auth/ 002-profile/ 仕様のレビューコスト増: ⼤量に⽣成される仕 様の妥当性を確認するコストが増⼤ レビュアー不⾜: スキル領域を超えてフルス タックに実装できるようになる⼀⽅で、コード の妥当性を担保できるレビュアーが不⾜ 実際、今回のPJではエンジニアがバックエンド 担当のみであり、フロントエンドのレビューは 他チームに依頼する経緯が発⽣ > > > 振り返りと得られた知⾒