2026年6月2日火曜日の18時から、AI仕様駆動開発セミナーを開催しました。
参加者は、マネージャークラスからプログラマまで幅広い構成でした。立場も経験も異なる方々に向けて、単に「AIでコードを書こう」という話ではなく、AIを本番開発に組み込むために、仕様・Issue・レビュー・ナレッジ蓄積をどう設計するかを扱いました。
この記事では、セミナーで扱った内容と、実施後アンケートから見えた反応を整理します。アンケートは受講者数・回答数を公開せず、回答者内の割合として扱っています。5段階評価のグラフでは、評価5を最も肯定的な回答、評価4を肯定的な回答、評価3を中間的な回答として表示しています。
なぜ「AI任せ」は失敗しやすいのか
今回のセミナーで最初に扱ったのは、いわゆる「バイブコーディング」がなぜ失敗しやすいのか、という話でした。
「いい感じに動くものを作って」
このような指示でも、AIは一見それらしいコードを返してくれます。しかし、本番運用するシステムでは、そこに落とし穴があります。既存の設計方針、チーム固有の用語、認証や権限の暗黙ルール、エラー形式、テスト観点、将来の変更意図。これらが仕様として渡されていなければ、AIは推測で埋めるしかありません。
AI開発で課題になりやすいのは、コードを書くことそのものではありません。むしろ、既知のパターンの組み合わせ、定型的なCRUD実装、公開仕様やRFCに基づく実装、既存パターンに沿った関数追加はAIが得意とする領域です。
一方で、未記載の要件、チーム固有の暗黙の契約、プロジェクト特有のドメイン用語、3年先を見据えた設計意図は、自然には読み取れません。
だからこそ、AI開発では「プロンプトを上手に書く」より前に、AIが迷わない仕様を渡すことが重要になります。
AI仕様駆動開発は、魔法のプロンプトではなく開発プロセスである
フィールフロウが提唱しているAI仕様駆動開発は、独自メソドロジーではありますが、奇抜な手法ではありません。
核にある考え方はシンプルです。
- プロジェクトの目的と制約を文書化する
- Issueを、AIが1セッションで完結できる粒度に切る
- 受け入れ基準とテスト観点を明文化する
- AIが実装し、人間またはAIがレビューする
- レビューで得た知見をプレイブックとして蓄積する
つまり、AIを「何でも察してくれる相手」として扱うのではなく、仕様に従って作業するエージェントとして扱う。ここが出発点です。
セミナーでは、そのための土台として、AI開発で最低限整えておきたい7つの文書フレームワークも紹介しました。
- プロジェクト: ビジョン、目的、要件定義
- アーキテクチャ: システム設計、制約、ADR
- ドメイン: 業務ルール、用語、判断基準
- パターン: コーディング規約、実装パターン、禁止事項
- テスティング: テスト戦略、確認観点、品質基準
- デプロイメント: リリース手順、運用手順
- その他: プロジェクト固有の補助文書
これは、すべてを重厚な仕様書に戻すという話ではありません。むしろ、AIが迷う部分だけを、MarkdownやGitHub Issueとして軽量に残していくための枠組みです。
アンケートで最も反応が大きかったのは「失敗理由」と「仕様書」
アンケートで特に理解が深まった内容として最も多かったのは、「AIに任せるだけでは失敗しやすい理由」でした。次いで、「仕様書・ドキュメントの重要性」が高い割合で挙がりました。
この結果は、AI開発の導入で最初にぶつかる壁をよく表していると感じます。
現場では、AIツールを導入するとすぐに「どのモデルを使うか」「どのエディタがよいか」「Claude CodeかCodexか」といった話になりがちです。もちろんツール選定は重要です。しかし、アンケート結果を見る限り、参加者が強く受け取ったのはその手前にある構造でした。
AIに何を渡すのか。
どこまでをAIに推論させ、どこからを人間が明文化すべきなのか。
その境界が曖昧なままでは、優れたツールを入れても開発プロセスは安定しません。
導入意欲は高い。一方で、最初の壁は「チーム理解」と「ルール整備」
取り入れてみたい内容では、「要件定義・仕様書の整備」と「AIに渡すためのプロジェクト説明文書」が最も高い割合でした。続いて、受け入れ基準・テスト観点の明文化、GitHub Issueの書き方、AIレビュー、ナレッジ蓄積、エージェントスキルの作成が並びました。
一方で、導入時の課題としては、チームメンバーの理解、社内AI活用ルールの不足、セキュリティ・情報管理への不安が上位に挙がりました。
ここから見えてくるのは、AI開発の導入は「個人の生産性ツール導入」では終わらない、ということです。
プログラマ個人がAIを使いこなすだけなら、エディタやチャットツールの設定から始めてもよいかもしれません。しかし、チームで本番開発に使うなら、次のような論点を避けて通れません。
- AIに渡してよい情報と、渡してはいけない情報をどう分けるか
- 仕様書やIssueを、誰がどの粒度で書くか
- AIの実装を、誰がどの観点でレビューするか
- レビューで得た知見を、どう次回以降に再利用するか
- 既存の開発フローに、どこからAIを組み込むか
AI仕様駆動開発が重視しているのは、まさにこの部分です。AIを導入するのではなく、AIが働ける開発環境を設計する。そこまで含めて考えないと、最初は速くなっても、品質や運用で詰まりやすくなります。
「次は実演と演習を見たい」という声
次回さらに聞きたいテーマでは、Claude Code / Codexなどの実演が最も高い割合でした。続いて、AI仕様駆動開発の実践演習、仕様書テンプレートの書き方、AIレビューの実践方法、既存システムから仕様書を作る方法、チーム運用ルール、エージェントスキルの作り方が並びました。
これは自然な流れだと思います。
概念として「仕様を渡すことが重要」と理解できても、実際には次の疑問が出てきます。
- どのくらい細かくIssueを書けばよいのか
- 仕様書テンプレートは、どこまで埋めれば十分なのか
- AIレビューでは、何を見ればよいのか
- 既存コードから仕様書を作るとき、どこから始めればよいのか
- プロジェクト固有のSKILLと、汎用SKILLをどう分けるのか
アンケートでも、実践演習の題材として、PowerPoint資料の作成・成形、設計書やレビューの一貫作成、部門ホームページやテックブログの作成、プロジェクト固有スキルの育て方などが挙がりました。
AI仕様駆動開発は、講義で聞いて終わるテーマではありません。小さな題材で、Issueを書き、AIに渡し、レビューし、得た知見を残す。ここまでを一度体験して初めて、チームに持ち帰れる実感になります。
今回のセミナーから見えたこと
今回のアンケートで印象的だったのは、満足度や期待との一致度だけではありません。実践演習への参加意向が非常に高かったことです。
これは、参加者がAI開発を「知識として面白いもの」ではなく、「自分たちの業務に組み込めるかもしれないもの」として受け止めた結果だと考えています。
一方で、導入課題としてチーム理解や社内ルールが挙がったことも重要です。AI開発は、個人が先に進みすぎると、組織の合意形成やセキュリティ設計とズレることがあります。逆に、ルールだけを先に作りすぎると、実践が進まなくなります。
必要なのは、小さく試しながら、同時にルールとナレッジを育てることです。
AI仕様駆動開発は、そのための進め方です。仕様を整え、Issueに落とし、AIに実装させ、レビューし、知見を蓄積する。この一連の流れを、個人技ではなくチームのプロセスに変えていく。
今回のセミナーは、その入口として手応えのある場になりました。次回は、講義だけでなく、実際に手を動かす演習を通じて、「AIに任せるための仕様」を参加者自身が作れるところまで進めたいと考えています。
まとめ
AI開発の成果は、使うモデルだけで決まりません。
何を仕様として渡すか。どの粒度でIssueに分けるか。何をレビュー観点にするか。どの知見を次回に残すか。
この設計が整ったとき、AIは単なるコード生成ツールではなく、チームの開発プロセスに組み込める実行主体になります。
今回のセミナーとアンケート結果から見えたのは、参加者がその可能性を感じつつ、同時に「チームでどう始めるか」という現実的な問いを持ち帰ったことでした。
AI仕様駆動開発は、その問いに対するひとつの実践的な答えです。