本事例について
株式会社BoundFor様は、企業のWebサイト構築・運営を継続的に支援している会社です。BoundForとフィールフロウは、いずれもSDWホールディングスグループのグループ会社です。
今回は、BoundFor様のエンジニアチームに向けて、オンラインでAI仕様駆動開発のレクチャーを実施しました。参加されたのは、ディレクションと開発を兼務する方を含む、バックエンド・フロントエンド・ツール開発などを担当するエンジニア4名です。
フィールフロウがこのチームに勉強会を開くのは、約1年ぶり2回目です。
出発点 — 全員がAIで書いている。だからこそ残る迷い
1年前とは状況が大きく変わっていました。冒頭では参加者から、「もう手でコードを書いていない」「書く量が激減した」という声が上がりました。
一方で、共通の迷いも残っていました。
- AIに任せた方が良いのは分かっているが、AIが間違うケースもある
- 小さな修正なら、指示を書くより自分で直した方が速い
- AIの回答が正しいかどうか、自分で判断しきれないことがある
いずれも、AIを使いこなしているチームだからこそ出てくる悩みです。今回のレクチャーは、この迷いに答える形で組み立てました。
変えたいのは「AIを使うかどうか」ではありません。人が工程のつなぎ目に立ち続ける開発から、AIがループを回し、人は仕様とIssueを書くこと、判断と承認に集中する開発へ。その移行を、上の図のように整理してお伝えしました。
レクチャー内容
1. 人をボトルネックにしない、という設計思想
AI仕様駆動開発の基本思想は、人が開発工程のボトルネックにならないよう、可能な限り人が介入しなくても進む仕組みを設計することです。
流れは、要件 → 仕様 → Issue登録 → AIによる実装 → AIによるレビューと修正のループ → マージ。人が主に関わるのは前半の3つです。実装からレビュー・修正まではAIが自走し、人はマージ前の最終判断に関わります。
「仕様駆動」と呼ぶのは、大規模言語モデル（LLM）が言葉、つまりコンテキストで動くからです。仕様を先に言葉で整えておくほど、AIの実装は安定しやすくなります。
なお、レクチャーでは目安として、AIの初回出力の完成度は70〜90%程度という前提に立つことをお伝えしました。残りを人が手で埋めるのではなく、レビューと修正のループで90%以上へ引き上げるのが基本の考え方です。
2. AIに渡す「前提」を、リポジトリに置く
仕様は、リポジトリのdocs/フォルダに文書として置きます。計画・要件、制約・前提条件、アーキテクチャ、API設計、コーディング規約、デザインシステムといった文書を揃え、CLAUDE.mdやAGENTS.mdを目次として、AIがどこに何があるかを辿れるようにします。
あわせて、作業の進め方は「スキル」と呼ぶ手順書にしておきます。Issueからブランチを切り、実装し、テストし、レビューを通してマージする——この流れを手順として定義しておけば、AIは毎回同じ順番で進みます。
自分では分かっている前提も、書いて渡さなければAIには分かりません。AIの間違いは、AIの能力よりも、この「渡し方」の弱さに原因があることが少なくありません。
3. Issueの書き方が、実装の質を決める
AIに作業を渡す単位はIssueです。ここで丁寧に書くべきなのは、背景、受け入れ条件、検証シナリオの3つです。あわせて、参照すべきdocs/の仕様も書いておきます。
もう一つの目安が「1 Issue＝1セッション」です。1つの会話の中で作業が長くなると、それまでの文脈が圧縮され、細部が抜け落ちていきます。1つのIssueが1セッションで終わる大きさに分けておくことが、品質を保つうえで効いてきます。
4. 小さな修正でも、AIに任せる
参加者の多くが引っかかっていたのが、「指示を書いている間に自分で直せるのに、なぜAIに任せるのか」という点でした。
答えは記録にあります。Issueを起点にAIへ依頼すれば、背景の説明から実装・コミットまでが同じ流れの中で進むため、なぜ変えたのかが自然にIssueやコミットに残ります。一方、手作業の修正は記録を残す手順から抜け落ちやすく、AIにとっては「理由の分からない変化」になりがちです。記録が残っていれば、次の作業でAIも人も参照できます。
これは属人化の解消にもつながります。作業・判断・レビュー結果がすべてIssueに残っていれば、担当者が不在でも引き継げます。
5. レビューは別のセッションで
AIが書いたコードのレビューも、AIに任せます。ポイントは、実装したセッションとは別の新しいセッション（サブエージェント）でレビューを走らせることです。実装の経緯を知らない状態で読ませる方が、客観的な指摘を得やすくなります。
レビュー用のプラグインを使えば、セキュリティやコードの複雑さなど複数の観点で自動レビューを回せます。こうしたスキルやプラグインをチームで共有・配布する方法もあわせて紹介しました。
6. AIが自分の道具を改善していくループ
Issueをクローズするたびに振り返りを行い、問題点を蓄積してスキルに反映する。この仕組みを回すと、AIが自分の使う手順書を少しずつ改善していきます。
AIが間違えたときに直すべきなのは、出力そのものより、その出力を生んだ指示（仕様やスキル）の側です。
メンバーそれぞれの取り組みへ
レクチャーの後半では、メンバーの方々に現在の取り組みを発表していただき、一つずつ具体的なアドバイスをお伝えしました。なお、取引先や個別の案件が特定されないよう、内容は一般化して記載しています。
サイト改修 — 方針検討から実装まで、コードは手書きしない
チャット上で方針を検討し、その結果からAIに指示書を作らせ、実装まで進める流れがすでに回っていました。コードは一切手書きせず、AIが判断に迷った箇所にだけ人が答える進め方です。
CMSのテンプレートへ反映する工程には手作業が残っており、ここが次の改善対象になります。
厳しいセキュリティ要件のある案件 — 要件文書ごとAIに渡す
取引先が定めるセキュリティ要件への準拠が求められる案件で、大量の要件文書をすべてAIに読み込ませ、作業を段階に分けて、段階ごとに指示書と記録を残す運用をされていました。
課題は、セキュリティチェックとビルドに時間がかかり、緊急対応のときにそこがボトルネックになることです。あわせて、段階ごとの記録をIssueに移しておくと、担当者が替わっても判断の経緯ごと引き継げるようになる点をお伝えしました。
個人で試すIssue駆動 — 「次にやるべきこと」をAIが提案する
GitHubのIssueから次のおすすめタスクをAIが提案する仕組みや、言語・フレームワーク別のレビューエージェントを並列で動かす仕組みを、個人で試験運用されていました。よく使う指示をワンクリックで入力できる画面まで自作されています。
一方で、AIの公式アプリは進化が速く、自作した機能がすぐに標準機能として追いつくこともあります。自作の仕組みを広げる前に、公式アプリの機能をまず活用することをおすすめしました。
フロントエンドのコーディングと、公開前チェックの仕組み化
デザインデータから書き出した画像をAIに読み込ませ、1セクションずつコーディングを依頼する進め方で、手で書くより大幅に速くなっていました。一方で、余白や色などの細かい指示を毎回伝える必要がありました。
原因は、デザインシステムが事前に解析・文書化されていないことです。デザインデータを解析してdocs/に文書として置いておけば、細かな指示を繰り返す手間を大きく減らせます。
また、公開前のサイトを自動で確認するスクリプトと、AIが確認する項目・人が確認する項目を分けたチェックリストを組み合わせた、公開前チェックの仕組みも自作されていました。表記ゆれの検出まで組み込まれています。
AIの回答を、そのまま使わない
議論の中では、AIが出した回答を精査せずに伝え、誤った情報が相手に届いてしまった経験も語られました。
対策はシンプルです。背景や前提条件を十分に渡したうえで、「クリティカルシンキングで評価して」と一言添える。それだけでも、AIは自分の回答を前提・根拠・反証の可能性まで見直しやすくなります。そのうえで、最後に判断して責任を持つのは人です。
チームで決めた次の一手
セッションの最後に、チームとして次に取り組むことを整理しました。
個人の工夫として始まっていた取り組みを、チーム共通の運用へ広げる段階に入っています。
お客様の声
株式会社BoundFor エンジニアチームの皆様より、セッション後にいただいた感想です（お名前は伏せて掲載しています）。
メンバーA様
これまでは、自分で直した方が早い修正は手作業で済ませがちでした。そのため「小さな修正でもAIに任せるべき」と聞いたときは、指示を書いている間に直せるのになぜだろうと不思議に思いました。
しかし、人が直すとAIにはその経緯が分からないが、AIに直させれば記録として残るという話を聞き、ハッとなりました。
その他にも、自分では分かっている前提も伝えなければAIには分からないことや、クリティカルシンキングなどの思考法で再考させてミスを減らす手法からも、多くの学びを得ることができました。
それと同時にAIを活かせるかは使い手次第なんだなと改めて実感しました。変化の速いAIの進歩に遅れないようこれからも学び続け、今回得たことは早速業務に取り入れてまいります。
メンバーB様
1年程前に初めて岡崎さんに勉強会を開いていただいた時は、自分もまだあまりAI自体に向き合えていない状態だったので、正直持ち帰れる知識がほぼなく、ちゃんとAIを使いこなして仕事に活かしていこうという目標しか立てられなかったのが心残りでした。
今回の勉強会では、現在取り組んでいる仕組みづくりを発表したところ「使いこなしているね」と言っていただけて嬉しかったです。
「全部AIにやらせる」努力をするということはうかがっていたのですが、「人間が開発工程のボトルネックにならないよう、可能な限り人間が介入しなくても進む仕組みを設計する」という思想にはそこまでするんだ！と目から鱗でした。でも振り返るとその通りだなと思うことがよくあった気がします。早速、取り組み中の仕組みづくりに活かしていきたいと思いました。
「AIの回答が正しいか判断できない場合がある」という懸念を持ちながら作業をすることがあるのですが、背景や前提条件を十分に伝えること、「クリティカルシンキングで評価して」などと追加で指示し、AIの回答をそのまま採用せず、前提、根拠、反証の可能性まで確認することが大切だと教えていただきました。
AIの誤回答と自分の知識不足で不正確な情報を共有してしまったことがあり、相手に迷惑をかけてしまったことがあります。最後に判断するのは人間である以上、すべてをAI任せにせず、責任を持って取り組んでいきたいと思いました。
Issue駆動とdocsフォルダによるドキュメント管理、これから実践していきたいです。
メンバーC様
Issue駆動の取り入れ方を教えていただき、AIの利用により前向きになれたと思います。現在は手動と半自動とでAIを利用していますが、より自動化を進められそうと感じました。
現在AIの導入ルールやフローなどが曖昧で未確定な箇所が多いですが、Issue駆動を取り入れればそれらも解決すると考えてます。
公開しているGitHubを参照すれば導入できるとも思いますが、ハンズオンの様な形式で勉強会を開いていただけるとより解像度が上がって導入へのハードルが下がる鴨と思いました。
セッションを終えて
すでに全員がAIで開発しているチームでは、伸びしろは「AIをもっと使うこと」ではなく、AIが迷わずに進める前提と仕組みを整えることにあります。今回は、メンバーそれぞれの取り組みがその入口になっていました。
1年前は「AIを使いこなして仕事に活かしていこう」という目標を立てるところからだった、という声もいただきました。今回は、メンバーが自分たちの仕組みづくりを発表する側に立っていました。次は、その仕組みをチーム共通の運用にしていく段階です。ハンズオン形式での勉強会のご要望もいただいており、導入の定着まで引き続き伴走していきます。
本事例は、フィールフロウのAI仕様駆動開発の導入支援の一例です。
開発チームへの生成AIの定着や、AI仕様駆動開発の導入にご関心のある方は、サービス詳細またはお問い合わせからご相談ください。