はじめに
こんにちは！技術本部 Bill One Engineering Unitの市川です。
突然ですが、皆さんのチームでは、AIをどう活用していますか？
「CursorやClaude Codeを導入してAgent機能を活用している」「プロンプトエンジニアリングの勉強会を開いた」など、様々な試行錯誤をされているかもしれません。
2023年以降の生成AIの進化、とりわけAI Coding Agentの台頭は、ソフトウェア開発の世界に地殻変動をもたらしました。
コーディングやテスト実装が半自動化される中、
エンジニアの価値の源泉は「どう作るか（How）」から 「何を作るべきか（What）」 と 「なぜ作るのか（Why）」 へと、急速にシフトしています。
プロダクトの価値を定義する、要件定義・設計フェーズの重要性は、かつてないほど高まっているのです。
この大きな潮流を受け、私たちBill Oneの開発組織も「AI駆動開発」へと舵を切りました。
これは単なるツール導入による生産性向上を目指すものではありません。
AIを開発プロセスに深く組み込み、プロダクトの設計思想や改善サイクルそのものを変革するための壮大な旅路です。
そして、この挑戦が組織全体に適用可能なのかを確かめるべく、2025年7月に開発部長やマネージャーを巻き込み、熱海にてオフサイトでの「AI駆動開発合宿」を開催しました。
本記事では、その合宿で私たちが得た学びやインサイトをお伝えします。
なぜマネジメント層が挑んだのか？
今回の合宿には、AI駆動開発を実践しているエンジニア2名に加え、Bill Oneの開発部長・グループマネージャー・チーフアーキテクトの3名が参加しました。
オフサイトの合宿形式を採ったのは、日常業務から隔離された環境でAI駆動開発のプロセスに深く没入してもらうことが狙いです。
3名ともエンジニア出身の方々ですが、日々のマネジメント業務の中で開発に充てられる時間は限られています。
そのため今回は、あえて時間を確保し、自ら手を動かしながら現場の「肌感覚」を掴んでもらうことを意図しました。
「なぜ、マネジメント層が？」と思われるかもしれません。
それは、プロダクトの方向性を定め、組織文化を創る立場にあるマネジメント層こそ、”現場感”を深く理解する必要があると考えたからです。
現場エンジニアによるボトムアップのアプローチだけでなく、意思決定を担うメンバーが自ら手を動かして「肌感覚」を掴む。
そのリアルな体験こそが、実効性のあるAI戦略や組織の変革に繋がるとの考えでした。
合宿の題材には、実際のBill Oneのプロダクトバックログに起票されている、とある機能拡張案件を選定。
次のツールを使い、仕様駆動開発のプロセスに沿ってAIと人間が協業する未来の姿を模索しました。
AI駆動開発プロセスとツール
今回の合宿では、仕様駆動開発（SDD）のアプローチをベースに、人間とAIがそれぞれの強みを最大限に活かせるような開発プロセスを設計しました。
各フェーズで人間とAIがどのように連携し、どのツールを活用したのかを具体的にご紹介します。
AI駆動開発プロセス
フェーズ 1：要件定義
AI がプロダクトバックログの情報を基にプロダクト要求仕様書（PRD）の初稿を生成。
それをたたき台に人間が議論し、AIに指示を出してリアルタイムで内容をブラッシュアップします。
フェーズ 2：設計
確定した PRD をインプットに、AIが設計ドキュメントのたたき台を生成。
人間はその内容をレビューし、ビジネス要件やドメイン知識を補完しながら修正を加えます。
フェーズ 3：計画
完成した設計書に基づき、実装タスクを洗い出します。
並列で実装を進められるよう、依存関係を考慮してAIにタスク分割させます。
フェーズ 4：実装
分割されたタスクをAIに指示して実装を進めてもらい、人間は生成されたコードのレビューに集中します。
フェーズ 5：テスト
PRDを基に、AIに受け入れテストのテストケースを作成してもらいます。
そのケースを基に、人手で受け入れテストを実施します。
利用した主なツール
今回のプロセスを支えた主要なAIツールは次の2つです。
Cursor: VS Codeをベースに開発されたAIネイティブなコードエディタ。リポジトリ全体をコンテキストとして認識させ、チャットベースでコード生成やリファクタリングが可能です。今回は主に要件定義フェーズで、議論の内容を即座にPRDへ反映させるために活用しました。
Claude Code: Anthropic社が提供するCLI型のAIコーディングアシスタント。自然言語の指示に基づき、大規模なコードベースの理解、コード生成、テスト実行を一貫して行えます。実装・テストフェーズで中心的な役割を果たしました。
得られた3つのインサイト
二日間の開発合宿を通じて、実践的な3つのインサイトを得ることができました。
1. 要件定義：AIが理解できるくらいの”シンプルさ”が、要求の本質を突く鍵
最初のセッションはAIを活用した要件定義です。事前に用意した仕様の元となるドキュメントをAIに読み込ませ、所定のフォーマットに従ってプロダクト要求仕様書（PRD）の初稿を生成させました。
私たちの役割は、そのPRDを元に「この仕様はどうあるべきか」を徹底的に議論し、深掘りすることです。
そして、議論で生まれた修正点や改善案を、今度はAI（Cursor）に自然言語で指示し、PRDをリアルタイムで更新させていきました。
このプロセスで得られた最大の学びは、 「AIが正しく理解できるくらい、人間の意図をシンプルにする必要がある」 ということでした。AIは、曖昧な指示や複雑すぎる要求をうまく解釈できませんでした。AIに意図を正確に伝えてPRDを修正させるには、私たちが「何を」「どうしたいのか」を、過不足なく明確な言葉で表現する必要があったのです。
結果として、私たちは仕様の”贅肉”をそぎ落とし、複雑な仕様ではなく、ユーザーの要求を真に満たすシンプルな仕様へとたどり着くことができました。AIとの対話は、図らずも私たち自身の思考を整理し、要求の本質を見極めることができました。
2. 設計：爆速ドラフトの先にあった”罠”。AI時代に再発見した設計の「勘所」
次に、固まった要件を元に、ドメイン設計・データ設計・API設計といった項目について設計ドキュメントの生成を試みました。
AIは圧倒的なスピードでドキュメントを作成してくれます。
しかし、アウトプットの品質は60点といったところ。
大枠は捉えているものの、細かな考慮漏れや修正点が散見されました。
特に課題だったのは、その内容が「実装に寄りすぎていた」点です。
例えば、Kotlinのインターフェースだけでなく具体的な実装クラスまで出力されたり、データモデルがレビューの難しいDDLで記述されていたり…。
これではレビューコストが高く、本来このフェーズで議論すべき本質からズレてしまいます。
この実装先行とも言える状況を前に私たちは一度立ち止まり、どのようなアウトプットをAIに対して求めるかを考え直しました。
AIにいきなりコードを求めるのではなく、普段Bill Oneのエンジニアが行っているように「図」で対話・議論してみることはできないだろうか、と。
そこで、Markdownと相性の良いMermaid記法を使い、ER図・シーケンス図・ユースケース図といった設計図のドラフトをAIにて生成。続いて、人間がそれをレビューし、修正するというアプローチに切り替えました。
この方針転換は、とても上手くいきました。
設計が図で可視化されたことで、チームの共通認識を齟齬なく形成でき、レビューや修正も格段にしやすくなったのです。
AIが素早く生成したドラフトに、人間がドメイン知識やビジネスの意図を吹き込み、共に設計図を磨き上げていく。
このプロセスを通じて、設計ドキュメントの完成度が高められました。
この体験は、私たちにドラフト作成の高速化以上の、もっと本質的な気づきを与えてくれました。それは、AI駆動開発という新しい取り組みの中であっても、ER図やシーケンス図といった 「図を介した対話」 がいかに強力かということでした。それは決して古い手法ではなく、複雑な問題を解きほぐし、チームの認識を合わせるための、時代を超えた手堅いアプローチなのだと。AIとの協業において、私たちは設計の最も大切な「勘所」を再発見したのです。
3. 実装：仕様駆動開発が切り開く、実装の「スケールアウト」
設計が固まると、いよいよ実装フェーズです。Claude Codeを使い、バックエンドAPIの実装・テストコード生成を一気に行いました。
人間の役割は、AIが生成した6〜7割程度の完成度のコードに対し、特にビジネスロジックの根幹に関わる部分のレビューに集中することです。
今回の案件では2つのAPIエンドポイントを作成する必要がありました。2人のエンジニアがそれぞれAIエージェントを活用し、並行して作業を進めました。
ここで私たちが強く可能性を感じたのは、実装プロセスそのものを「スケールアウト」させられるという点です。これが可能になった背景には、前工程で実践した仕様駆動開発（SDD）の存在がありました。要件定義、設計、そして実装計画のフェーズで、依存関係のないタスクとして明確に分割されていたからこそ、複数のAIエージェントが迷いなく同時に実装を進められたのです。アウトプットされるコードの総量は、これまでの開発スタイルとは比較にならないほど増大していく。そんな未来を垣間見た瞬間でした。
もちろん、実装がスケールすれば、次なるボトルネックは「人間のレビュー」になります。
この点も、AI駆動開発の文脈で解決していくべき課題です。
今後は静的解析ツールやLinterの整備・ルール拡充を進め、生成コードの品質をさらに高めていきます。
そのうえでAIによるレビュー支援ツールを組み合わせることで、レビューコスト自体を削減し、開発プロセス全体の生産性をさらに高められると考えています。
マインドセットの変化こそが最大の成果
これらのインサイトは、参加者のマインドセットにどのような変化をもたらしたのでしょうか。
合宿後のアンケートでは、参加者の8割以上が「目的をほぼ達成できた」と回答しました。また、「AI駆動開発への理解度」は、全員が「要点を掴み、他者に説明できる」レベルへと向上しました。
「質の良いインプット（プロンプト・ドキュメント）が良いアウトプット（コード）に繋がることを、身をもって体感しました。これからのエンジニアには、実装能力と同じくらい、AI への”問い”を設計する能力が求められると感じます。」
「設計の初期段階で具体的な実装コードをAIに書かせると、その後の手戻りが大きい。まずはインターフェース（APIスキーマなど）だけをAIと壁打ちしながら設計し、合意形成することの重要性を学びました。」
これら参加者の声は、AI駆動開発が単なる技術論ではなく、「人間とAIの新たな役割分担」という、より本質的なテーマであることを示唆しています。
合宿を点から線へ、そして未来のBill Oneへ
この合宿はゴールではありません。Bill OneのAI駆動開発を次のステージへ進めるための力強いキックオフです。
私たちは、合宿で得た学びを元に、次の2つのアクションを推進し、AIとの協業を開発組織全体へと広げていくことを計画しています。
AIが支援する仕様駆動開発プロセスの確立と展開
プロダクト要求仕様書（PRD）の作成から、設計ドキュメントの書き起こし、タスクへの分割、そして実装まで。この一連のプロセスをAIがアシストする再現可能なワークフローを確立し、Bill Oneの開発組織全体へ展開していきます。
プロセスの継続的な進化とアーキテクチャ改善への挑戦
AIエージェントや関連ツールは日々進化しています。私たちはその動向を常に追い、開発プロセスを絶えず最適化し続けます。また、AI駆動開発を前提とした、よりモダンなアーキテクチャのあり方も探求していきます。
これらの取り組みを通じて、AIと人間がそれぞれの強みを最大限に発揮できる、真の 「AIネイティブな開発組織」 を確立することが私たちの最終目標です。
おわりに
AI駆動開発は、まだ夜明け前の領域であり、銀の弾丸のような確立されたプラクティスもまだありません。
しかし、今回の合宿を通じて私たちは、AIと正しく向き合えば、創造性を加速させる大きな可能性を秘めているという確かな手応えを得ることができました。
Bill Oneでは、この挑戦を一過性のイベントで終わらせることなく、組織全体の文化へと進化させていきます。AIを取り巻く世界は、凄まじいスピードで変化しています。だからこそ私たち自身も、常に学び、変化し続ける組織でありたいと考えています。
「アーキテクチャ Conference 2025」 に登壇します！
本記事で触れたAI駆動開発の実践は、Bill Oneのアーキテクチャ進化とも密接に関わっています。
2025年11月20日（木）・21日（金）に開催される「アーキテクチャ Conference 2025」では、
マイクロサービスの急成長の先に直面した課題に対し、AIを前提にどのように軌道修正を進めているかをお話しします。
現場で得られたリアルな学びを共有する予定ですので、ご関心のある方はぜひ会場にお越しください！
architecture-con.findy-tools.io
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
