記事のサマリー（TL;DR）
- freee人事労務チームがspec-kitをカスタマイズした独自ツール「takoyaki-kit」を開発・他チームへも展開
- AIエージェントの暴走を防ぐには「仕様作成と実装のセッション分離」「1タスク＝1PR単位」が有効
- 設計書は薄くし、設計判断はADRへ、最新の正解はソースコードへと役割を明示的に分離
業務SaaS開発チームがAIエージェント導入時に直面するリスクと参考ポイント
freeeは国内の中小企業を中心に広く利用されている会計・人事労務SaaSであり、その開発現場の知見は同種のサービス——kintone拡張開発・Salesforce連携・SmartHR周辺システム開発など——に携わるエンジニアチームにも直接応用できる。
今回の発表で示された「仕様書を細かく書きすぎるとコードベースとの乖離（腐敗）が生じる」という指摘は、既存業務SaaSへのアドオン開発でも共通する課題だ。特にJIRAや独自チケット管理との連携部分はツールのデフォルト動作と合わないケースが多く、freeeチームがspec-kitをカスタマイズして「takoyaki-kit」に育てたアプローチ——既存OSSを諦めずに自社運用に合わせて改造する姿勢——は、業務システムのUI補完や専用ダッシュボード開発を進めるチームにとっても参考になる。
また、「生成コストの低さを活かして複数候補を並べて比較する」という検証フローは、要件定義が曖昧になりがちなカスタマイズ開発においてリスクを早期に検出する手段として機能する。
詳細
登壇の背景：関西拠点立ち上げとAIエージェント活用の1年
freee人事労務エンジニアの miya-c（GitHub: @keganokami）氏は、2026年7月に新設された関西拠点の立ち上げメンバーとして、コア機能の開発に携わっている。
2026年7月28日、株式会社U-NEXT HOLDINGS本社で開催されたファインディ株式会社主催のMeetup「プロダクト開発、AIに丸ごと任せられるのか？Meetup Spec/Issue駆動知見を語り尽くす！」に登壇し、チームが直近1年間取り組んできたAIエージェントを活用した仕様駆動開発の実践内容を発表した。
本記事で伝えたい結論は明快だ。AI時代の仕様駆動開発を成功させるカギは「土台の固定」と「役割・工程の分離」にある。
- ドキュメントの割り切り：設計判断（ADR）と正解（コード）を明確に分ける
- 人間の役割：解くべき課題の構造化と、ブレない「固定部分（土台）」の定義に集中する
- AIの役割：生成コストの低さを活かし、固定された土台の上で「複数候補」を高速に生成・比較する
登壇内容：チームに適合する手法を模索し続ける
OSSをカスタマイズして自社専用ツール「takoyaki-kit」を開発
freeeチームはオープンソースのフレームワーク「spec-kit」を使って仕様駆動開発の導入を試みた。しかしそのままでは自社の開発フローに合わなかった。具体的な課題は2点だ。
- JIRAによるチケット管理との連携が弱い
- 複数チームが1つのリポジトリを運用するスタイルに適さない
チームは利用を諦めるのではなく、開発リポジトリ内でツール自体をカスタマイズすることを選んだ。既存機能を変更しながら、自社運用に合わせた機能追加と改善を繰り返した結果、独自ツール「takoyaki-kit」が完成。現在では部署を超えて他チームにも使われるツールへと成長している。
モブレビューと仕様の可視化による品質向上
AIモデルの進化でコード生成のスピードと品質は大きく向上した一方、複雑なコンテキストやタスクの依存関係はAI単体ではコントロールしづらい場面も残る。
仕様駆動開発における「仕様」とは「信頼できる唯一の情報源（Single Source of Truth）」を指す。ウォーターフォール開発のように作り方まで固め切る必要はなく、開発スコープと受け入れ条件が定まっていれば重厚なドキュメントは不要という考え方だ。
takoyaki-kitをGUIアプリケーション化し、仕様書やタスク一覧などのMarkdownファイルを可視化。タスクの依存関係を視覚的に把握しやすくすることで、AIエージェントが出力したファイルのレビューコストを大幅に削減できると見込んでいる。
1つのアプリケーション上で仕様を確認しながらチームで「モブレビュー」を実施することで、メンバー全員が仕様・設計・実装を深く理解した状態でAIエージェントへ精度の高い指示を出せる体制を整えた。
Meetup全体の学び：AI時代の仕様駆動開発に共通する4つのポイント
1. ドキュメントと仕様の「役割の分離」
AIが高速でコードを生成・変更できる現代において、「1つの設計書にすべてを細かく書き込み、常に最新に保つ」という運用は破綻しやすい。各社に共通していたのはドキュメントの役割を割り切って分離するという考え方だ。
| 役割 | 置き場所 |
|---|---|
| 最新の設計・実装状態 | ソースコード（最新スナップショット） |
| 設計判断の記録 | ADR（Architecture Decision Record） |
仕様書を細かく書きすぎると、必ずコードベースとの乖離（腐敗）が発生する。「過去の判断の記録」と「最新のコード」を分けることが、AI時代の基本的な文書管理戦略となる。
2. AIの暴走を防ぐ「工程とセッションの切り方」
「AIに仕様作成から実装まで一括で任せると暴走する」という課題に対しては、工程（セッション・SKILL）を明示的に切り離すアプローチが有効だ。効果があるのは「仕様の厳密さ」よりも「工程の切り方」であり、具体的には以下の工夫が挙げられた。
- 仕様作成と実装のセッションを分ける：仕様作成フェーズでは「コードは一切変更しない」ことを制約として明記する
- 1タスク＝1PR＝リバート可能な単位にする：親Issueから子Issueへ細かく切り出し、受け入れ基準と対象外範囲を明確にする
3. 生成コストの低さを活かした「複数候補の検証」と「前提を壊すフィードバック」
AIエージェントの最大のメリットは「生成コストが圧倒的に低いこと」だ。薄い目的だけを与えて走らせ、「動くものを複数作って候補を並べて比べる」探索的な検証フローが現実的に回せる。実際に動かすことで、机上の空論ではなく実装の穴を事前に発見できる。
ただし、このサイクルを機能させるための2つの条件がある。
- 固定する部分は絶対に固定する：仕様と設計の根幹や判断基準が明確に定まっているからこそ、複数候補を正しく比較・判断できる
- ループするなら「壊して」からフィードバック：フィードバックループの中にAIエージェントの推測が混入するのを防ぐため、一度前提を壊してから仕様へフィードバック（判定を校正）するアプローチが重要
「固定された土台（仕様の大枠・ADR・ハーネスなど）」の上でAIを自由に走らせ、ループに陥ったら前提を疑って仕様へフィードバックするサイクルこそが、仕様駆動開発の核心だとまとめられた。
4. 仕様決定における「解くべき問題の構造化」
AIのコード生成速度が飛躍的に上がった結果、開発チームの課題は「何を作るか（顧客理解と構造化）」という領域にも広がっている。顧客の要望を「表層の困りごと」で終わらせず、「構造的に解消すべきポイント」に落とし込む力が求められる。
構造化作業自体はAIエージェントが得意とするが、「単純に受け止めるのではなく、背景にある問題を認識して『何を作るか』を決める」判断は、依然として人間の役割として残る。
まとめ：freeeチームが今後のプロセスに取り込む5点
Meetupでの学びを踏まえ、freeeチームは開発プロセスを以下のようにアップデートする方針を示した。
- Design Doc（DD）は思い切って薄くする：概要・基本設計・セキュリティ要件など必須項目のみ残し、詳細設計・実装内容は記載しない
- 重要な設計判断はADRに任せる：「何を作るか」「なぜその設計にしたか」の履歴をADRに集約する
- 最新スナップショットはソースコードに委ねる：方針が固まったらAIエージェントでPR作成まで高速に進める
- 仮説や技術検証ではまず「候補」を並べる：意思決定スピードを上げるため複数候補比較を標準化する
- 問題を構造的にとらえる訓練をする：ドメインエキスパートや顧客と近い環境を活かし、「どう解決するか」を日常的に考える習慣をつける