事例システム開発
システム開発会社様｜24名が参加した30分のミニレクチャー。AI開発の進め方をチームで共有
AI伴走支援の一環として、システム開発会社様の24名に向けて30分間のミニレクチャーを実施しました。Claude Codeでの並行開発を中心に、Worktreeによる作業場所の分離、サブエージェントへの役割分担、作業後の整理まで、チームで試すための考え方を共有しました。
- お客様
- システム開発会社様（社名非公開）
- 公開日
FeelFlow Core Competency
AI仕様駆動開発
— 品質とガバナンスを
開発の仕組みに
AIで誰もが作れる時代に、組織で品質を守る仕組みを。 品質基準・責任分担・変更履歴を開発プロセスに組み込む、 フィールフロウのAI仕様駆動開発。
仕様・実装・テスト・承認の記録をつなぎ、担当者が変わっても使い続けられる開発体制へ。 自社開発で磨いた方法論を、御社のチームに定着させます。
品質
共通の基準で確かめる
責任
判断と承認を明確にする
履歴
変更の理由までたどる
保守
次の担当者へつなぐ
Quality & Governance
AI仕様駆動開発とは、
品質保証を含む開発ガバナンスの方法論
フィールフロウのAI仕様駆動開発は、品質基準・責任分担・変更履歴を開発プロセスに組み込む方法論です。 「何を満たせば完成か」を仕様で共有し、実装・検証・承認・運用をつなぎます。
品質保証（QA）は、求める品質を満たすための活動です。 開発ガバナンスは、そこに「誰が判断するか」「公開してよい条件は何か」「変更の理由を説明できるか」まで含めた組織の仕組みです。
- 01
仕様を合意する
何のために、何を満たすか
残す記録目的・制約・受け入れ条件
- 02
実装する
誰が、何を、なぜ変えたか
残す記録変更内容・担当者・日時・理由
- 03
検証・承認する
基準を満たしたか、誰が判断したか
残す記録テスト結果・レビュー・承認記録
- 04
公開・運用する
本番で動くか、誰が保守するか
残す記録公開した版・動作確認・保守担当
検証から実装へ戻す品質基準を満たさなければ、修正・再検証へ。責任者の承認を経て公開します。
運用から次の仕様へ戻す不具合や利用者の声を、次の仕様・テスト・開発ルールへ反映します。
AIが仕様化・実装・検証を支援し、人が目的・品質基準・公開を判断します。 管理する範囲や確認の深さは、アプリの用途とリスクに応じて設計します。
「なぜ変えたか」まで、
次の担当者へ残す
依頼・仕様・変更・検証・承認を関連づけて管理します。 コードの履歴に、業務の目的と判断の根拠を結びつけます。
記録のイメージ：申請フォームの改修（説明用の例）
- 目的
- 申請の二重送信を防ぐ
- 変更
- 送信処理と受付条件を更新
- 担当・日時
- 開発担当A・変更日時
- 検証
- 再送時に重複しないことを確認
- 承認
- 業務責任者B・承認日時・判断理由
- 公開・保守
- 公開した版・確認結果・保守担当C
The Problem
作れる人が増えるほど、組織で決めたい4つのこと
AIでアプリを作る機会が広がっています。業務で使い続けるためには、品質・責任・変更履歴・保守を、個人任せにしない仕組みが必要です。
品質の判断基準が揃わない
アプリが動いても、業務の例外や権限の扱いまで確かめたかは別の問題です。完成の基準が曖昧なままでは、担当者ごとに確認の範囲が変わります。
責任者と承認の手順が曖昧
誰が公開を判断するのか、問題が起きたときに誰が対応するのか。アプリが増えるほど、持ち主と承認の手順を組織で決める必要があります。
変更の理由をたどれない
誰が、いつ、何を、何の目的で変えたのか。チャットや担当者の記憶だけに残ると、影響の調査や判断の説明が難しくなります。
作った人しか直せない
仕様や設計の意図が残っていないアプリは、異動や退職のたびに引き継ぎが課題になります。作った後も保守できる状態を整える必要があります。
The Process
4フェーズのプロセス詳細
AI仕様駆動開発は、仕様書作成から継続的改善まで4つのフェーズで構成されます。各フェーズで判断することと、残す記録を明確にします。
01
目的と品質基準を仕様にする
Purpose & Specification
AIと対話しながら、何のために作るか、何を満たせば完成かを言語化。依頼者と開発側で合意します。
残す成果物・記録
合意した仕様受け入れ条件責任・承認のルール
実施内容
1
利用者・業務目的・対象範囲・対象外を明記
2
入力、判断基準、例外、成果物、受け入れ条件を具体化
3
権限・情報の扱い・性能など、必要な品質要件を定義
4
アプリの責任者と、変更・公開の承認手順を決定
5
仕様の抜けや矛盾をレビューし、人が内容を確認
02
仕様に沿って実装し、変更を記録する
Implementation & History
AIが実装とテスト作成を支援。依頼と変更内容を結びつけ、誰が何のために変えたかを残します。
残す成果物・記録
変更内容テストコード変更理由と履歴
実施内容
1
合意した仕様をもとにAIが実装を支援
2
正常系・例外・権限の境界を確かめるテストを用意
3
変更者・日時・目的・対象範囲を記録
4
仕様の変更が必要なら、理由と影響を確認して更新
5
AIの提案をそのまま採用せず、変更内容をレビュー
03
検証し、責任者が公開を判断する
Verification & Approval
レビューとテストで品質基準を確認。検証結果をもとに責任者が受け入れを判断し、承認後に公開します。
残す成果物・記録
検証結果承認記録公開する版
実施内容
1
仕様と実際の動作を照らし合わせて確認
2
案件に応じたセキュリティ・権限・性能の検証
3
レビュー指摘とテスト結果を変更に関連づけて保存
4
基準未達や未解消の問題があれば、修正・再検証へ戻す
5
承認者・日時・判断理由と公開する版を記録
04
運用の学びを次の仕様に戻す
Operation & Improvement
公開後の動作を確認し、問い合わせや不具合を改善につなげます。仕様と履歴を残し、保守を次の担当者へ引き継ぎます。
残す成果物・記録
本番確認の記録運用・引き継ぎ手順改善の履歴
実施内容
1
公開した版と本番の動作を確認
2
不具合の原因・影響・対応を記録
3
改善の目的と優先順位を決め、次の仕様へ反映
4
再発防止策をテストと開発ルールへ追加
5
仕様・運用手順・責任者を更新して引き継ぐ
Comparison
開発ガバナンスを、日々の進め方に落とし込む
| 管理すること | 仕組みが整っていない状態 | AI仕様駆動開発 |
|---|---|---|
| 目的・完成条件 | 作る機能は決めたが、受け入れ条件が曖昧 | 目的・制約・例外・受け入れ条件を仕様で共有 |
| 品質の確認 | 担当者ごとにレビューやテストの範囲が異なる | 共通の基準に沿って検証し、結果を記録 |
| 変更の管理 | チャットや個人の記憶に判断理由が分散 | 依頼・仕様・変更内容・検証結果を関連づける |
| 公開の判断 | 動いたので公開し、責任者や承認が不明確 | 責任者が受け入れを判断し、承認後に公開 |
| 保守・引き継ぎ | 作った本人への確認から始める | 仕様・設計意図・変更履歴を手がかりに改修 |
| 継続的な改善 | 不具合への対処がその場限りになる | 学びを仕様・テスト・ルールへ反映 |
Benefits
組織で使い続けるための6つの価値
品質のばらつきを抑える
誰が担当しても、同じ品質基準で開発・検証できる体制へ。受け入れ条件とレビュー・テストの観点を共有します。
変更の経緯を説明できる
誰が・いつ・何を・なぜ変更し、誰が承認したかを記録。判断の根拠を、後から確認できるようにします。
保守・引き継ぎがしやすい
仕様と実装を一緒に更新し、設計の意図を残します。担当者が変わっても、変更の影響を把握しやすくなります。
公開の判断に責任を持てる
責任者と承認手順を明確にし、必要な検証を終えてから公開。基準を満たさない変更は修正に戻します。
手戻りを減らす
目的・対象範囲・例外・完成条件を先に言語化。作り始める前に認識を揃え、認識のずれによる作り直しを抑えます。
経験が組織の資産になる
不具合やレビューで得た学びを、次の仕様・テスト・開発ルールへ。個人の経験をチームで再利用できる形に残します。
Conceiver
考案者の声
岡崎 太Futoshi Okazaki
フィールフロウ CTO・AI仕様駆動開発 考案者
AI仕様駆動開発は、フィールフロウがFeelFlow AI プロダクトの開発を通じて磨き上げてきたメソドロジーです。AIで作れる人が増えるからこそ、品質をどう確かめ、誰が判断し、どう保守していくかを組織の仕組みにする。そのために、仕様と実装、検証と承認の記録をつなぎ、日々の開発で実践しています。
Tech Stack
フィールフロウが使用するAIツールスタック
開発では Claude Code を中心に、Cursor、GitHub Copilot、Codex、Devin などを組み合わせて運用しています。最前線のAIツールを常時評価・採用し、メンバー１人あたり月$200のAI投資を行い、最新の知見を実務に反映しています。
開発AI・エージェント
Claude Code（主軸）CursorGitHub CopilotCodexDevin
仕様書管理
Notion AIConfluence AI独自テンプレート
品質保証
VitestPlaywrightSonarQube
CI/CD
GitHub ActionsVercelAWS CodePipeline
モニタリング
DatadogSentryFeelFlow AgentHub（エージェントHub）
For Your Organization
御社への移植・定着支援プロセス
AI仕様駆動開発は、フィールフロウが自社で実践・検証したメソドロジーです。 単なる研修ではなく、実際のプロジェクトを通じた伴走支援により、組織に根付いた変革を実現します。
サービス内容の詳細はシステム開発 AI伴走コンサルティングをご覧ください。
Phase 11〜2週間
現状診断・メソドロジー理解
現在の開発プロセスを可視化し、AI仕様駆動開発の概念・ツール・プロセスを習得。導入ロードマップを策定します。
成果物
- 現状開発プロセス診断レポート
- AI仕様駆動開発導入計画書
- 品質基準・責任者・承認手順の設計
Phase 24〜8週間
パイロットプロジェクト実施
実際の小規模案件でAI仕様駆動開発を実践。フィールフロウのエンジニアが伴走し、御社流のカスタマイズを行います。
成果物
- パイロット案件の成果物
- カスタマイズ済みプロンプトライブラリ
- 社内ガイドライン初版
- 仕様・変更履歴・検証・承認をつなぐ運用
Phase 32〜3ヶ月
チーム展開・自走化
成功パターンを組織全体に展開。社内チャンピオンの育成と自走体制の構築を支援します。
成果物
- 社内トレーニング実施
- ナレッジベース構築
- KPIモニタリング体制
- 保守・引き継ぎ手順
Phase 4継続
継続的改善・最新化
AI技術の急速な進化に対応し、メソドロジーを継続的にアップデート。フィールフロウが最前線の知見を提供し続けます。
成果物
- 月次改善レポート
- 新ツール・手法の導入支援
- コミュニティアクセス
システム開発 AI伴走コンサルティングは同時3社限定。まずはお気軽にご相談ください。
導入相談をする（無料）Case Study
AI仕様駆動開発の導入事例
- 事例Web制作・システム開発
株式会社BoundFor様｜デザインチームへのAI伴走支援。制作ルールと仕事の進め方を言葉にする
株式会社BoundFor様のデザインチームに、AI伴走支援の一環としてレクチャーを実施しました。デザイン制作でのAI活用から、Skillsへのルール登録、背景情報の文書化、GitHub・GitLabによるタスク管理までを共有。参加メンバー5名の感想と、次に試したい取り組みを紹介します。
- お客様
- 株式会社BoundFor
- 公開日
- 事例Web制作・システム開発
株式会社BoundFor様｜エンジニアチームへAI仕様駆動開発をレクチャー。人がボトルネックにならない開発体制へ
Webサイトの構築・運営を手がける株式会社BoundFor様のエンジニアチームに、AI仕様駆動開発のレクチャーを実施しました。すでに全員が日常的に生成AIで開発している状態から一歩進め、「人が開発工程のボトルネックにならない」ための仕様・Issue・レビューの仕組みと、AIの回答を検証する習慣を、メンバーそれぞれの取り組みに沿って整理しました。
- お客様
- 株式会社BoundFor
- 公開日
Official Guide
メソドロジーを標準仕様から学ぶ
AI仕様駆動開発をチームで導入するための標準仕様と公式実装を、公式ガイドとしてまとめています。導入担当者、テックリード、開発標準の策定者に向けたリファレンスです。
