AI時代の開発高速化スペシャル by クラスメソッド で「全てのコンテキストを集約し真の仕様駆動を実現。プロジェクト全体の開発を高速化する方法」というテーマで登壇しました
リテールアプリ共創部 マッハチームのるおんです。
2026/01/21 AI時代の開発高速化スペシャル by クラスメソッド で「全てのコンテキストを集約し真の仕様駆動を実現。プロジェクト全体の開発を高速化する方法」というテーマで登壇しました。
登壇資料
概要
今回の登壇では、AIエージェントを活用した開発において「真の仕様駆動」を実現するための具体的な方法についてお話ししました。
KiroやGitHub Spec Kitといった仕様駆動ツールが登場していますが、実際のプロジェクトではこれらのツールだけでは対応できない複雑さがあります。その課題と解決策について、マッハチームでの実践を交えてご紹介しました。
仕様駆動開発の課題
仕様駆動開発とは、AIにコードを書かせる前に「仕様」を先に作る開発手法です。KiroやGitHub Spec Kitなどのツールでは、requirements/design/tasksなどのファイルを生成し、AIに読み込ませます。
しかし、実際のプロジェクトでは エンジニア1人とAIだけ で完結することはほとんどありません。
- お客様（発注者）
- PM / ディレクター
- デザイナー
- 他社ベンダー（API連携先など）
- 社内の他チームメンバー
といった多くのステークホルダーが存在し、Backlogの課題やMTGでの合意内容、先方のスケジュール、使用できる予算など、機能仕様以外の プロジェクト全体のコンテキスト がAIに伝わらないと、的外れな提案や手戻りが発生してしまいます。
「真の仕様駆動」の定義
今回の登壇では、「真の仕様駆動」を以下のように定義しました。
全ての会話・やり取り・決定履歴を参照可能にし、本番環境で顧客の要望を満たす実装を実現すること
従来の仕様駆動ツールは「計画の構造化」に過ぎず、実案件の複雑さには対応できません。コンテキストエンジニアリングのエッセンスを加えることで、初めて「実案件に耐えうる仕様駆動」が実現できます。
コンテキストをローカルに集約する
情報はBacklog、Jira、GitHub、Teams/Slack、Google Drive、Figma、Notionなど様々な場所に散らばっています。
これらをすべてMCPやAPIで接続する方法もありますが、設定が複雑でレスポンスが遅く、コンテキスト制限に引っかかることもあります。
そこで私たちが採用しているのは、全てをローカルに落とす というアプローチです。
apparel-membership-card-context/
├── MTG/ # 議事録（Teamsの自動文字起こしを配置）
├── 共有資料/ # 要件整理・見積もりなど（Google Driveからインポート）
├── Backlog/ # Backlogからエクスポートされたデータ
│ ├── documents/ # 仕様書・シーケンス図など
│ └── issues/ # Backlog課題
├── GitHub/ # GitHubからエクスポートされたデータ
│ ├── issues/ # Issue定義ファイル
│ ├── src/ # ソースコード 🔗 サブモジュール
└── └── wiki/ # GitHub Wiki 🔗 サブモジュール
例えば、Backlogの課題をローカルに落とすには、backlog-exporter というツールを使用しています。
pnpm dlx backlog-exporter@latest update
このローカル集約アプローチには以下のメリットがあります。
- 全文検索が可能 - AIも人間も同じファイルを検索できる
- ローカル環境で編集可能 - AIエージェントが直接ファイル編集できる
- API/MCPが不要 - コンテキスト取得が高速でレート制限を気にしない
- プレビューが容易 - Markdownはプレビュー表示、CSVはExcel風に確認
rulesyncの活用とカスタムコマンド
複数のルールファイルから統合されたルールファイルを生成するツール rulesync を活用し、チーム全体で統一されたルールとカスタムコマンドを共有しています。
pnpm dlx rulesync@latest generate
定型化されたタスクをコマンド化しておくことで、議事録生成やIssue進捗サマリー生成などのフォーマットを統一して生成することが可能です。
| コマンド | 用途 |
|---|---|
/create-minute |
Teams文字起こしから議事録を自動生成 |
/generate-issue-summary |
PBIの進捗サマリーを生成 |
/structured-commits |
作業内容から構造化されたコミットを作成 |
/create-pull-request |
コミットログからPRを自動作成 |
/update-issue-from-request |
実装後にIssueを詳細化 |
GitHub Issue/PR/コードをドキュメントとして機能させる
仕様駆動ではSpecファイルを作成することが多いですが、仕様書を別途作成・維持しようとすると、追従が難しく陳腐化しやすいという問題があります。そこで、GitHub Issue/PR/コードをドキュメントとして機能させるアプローチを採用しています。
| 従来 | 提案 |
|---|---|
| 仕様書を別途作成 | GitHub Issueに仕様を記載 |
| 設計書を別途管理 | PRに設計意図を記載 |
| 変更履歴を別管理 | コミットメッセージが履歴 |
| ナレッジを別ツール | GitHub Wikiに集約 |
コードと一緒にバージョン管理され、レビューのコンテキストも含まれる。これ以上のドキュメントはありません。
詳しくは以下のブログでも紹介しています。
さらなる開発高速化のための工夫
既存アセットの活用
さらなる高速化のために、テンプレートリポジトリを事前に用意しています。
含めておくべきもの：
- 認証認可周り - ソーシャルLogin, パスワード認証等
- アーキテクチャ - Clean Architecture, Feature-Based等
- インフラ構成 - CDK, Terraform等
- エラーハンドリング - 共通エラーレスポンス
- CRUDシステム - TODOアプリ的な基本APIエンドポイント
各案件ごとにcloneしてカスタマイズすることで、毎回同じ品質でスタートでき、既存コードの再利用でAIが既存コードを参照可能になります。
Figma連携
FigmaはMCP経由でリモート状態を読む形で連携しています。Figmaのデザイントークンをtailwind.config.jsにマッピングすることで、AIがFigmaを参照しながらコンポーネント実装でき、Figmaと全く同じデザイン でフロントエンド構築が可能になります。
まとめ
今回の登壇の要点は以下の4つです。
-
仕様駆動を行うためには、機能だけでは不十分 - KiroやSpec-kitのデフォルトの機能だけでは不十分。プロジェクト全体のコンテキスト（Backlog、MTG、予算、スケジュール等）を含める必要がある
-
全てをローカルに集約する - APIやMCPに頼らず、ファイルとしてコンテキストを持つことで高速化
-
GitHub Issue/PR/コードをドキュメントとして機能させる - 別途仕様書を作るのではなく、開発成果物自体がドキュメントに
-
既存アセット + Figma MCPでさらに高速化 - テンプレートリポジトリとデザインの連携で品質と速度を両立
AI時代だからこそ、顧客との対話・要件の深掘り など上流工程がより重要になってきています。AIと協働して上流工程を加速することが、プロジェクト全体の開発を高速化する鍵だと考えています。
今後の展望
現在はカスタムコマンドやルールを使ってAIと協働しながらタスクを実行していますが、今後は Skill / Subagent に移行し、より任せる範囲を広げていきたいと考えています。AIが自律的にタスクを判断・実行し、人間は最終確認とレビューに集中する、より高度な協働開発を目指しています。
おわりに
以上、AI時代の開発高速化スペシャル by クラスメソッド で発表した登壇レポートでした！
AIエージェントを使った開発はまだまだ模索中ですが、コンテキストをいかに整理してAIに伝えるかが重要だと実感しています。今回紹介した「ローカル集約」や「GitHub Issue/PRのドキュメント化」といったアプローチが、皆さんの参考になれば嬉しいです。
「うちではこうしている」「こういう工夫をしている」といったアイデアがあれば、ぜひ教えてください！
お知らせ
クラスメソッドのリテールアプリ共創部 マッハチームではエンジニアを募集しております。
マッハチームではClaude CodeやCursor等のAIエージェントを導入してプロジェクト開発を高速に実現してます。
AI駆動開発がしたい人、モダン技術を用いてフロントエンドもサーバーサイドもインフラ周りもTypeScriptでフルスタックに開発したい人、プリセール・顧客折衝も要件定義も開発も全部やりたい人、AI時代に価値提供し続けられるエンジニアになりたい人は是非以下のブログを見てご応募いただけると幸いです。
参考
