AI駆動開発によって、ドメイン知識の重要性がより増した
この記事は 弥生アドベントカレンダー2025 1日目の記事です。
こんにちは！弥生の白井と申します。
気づけば今年もあっという間で、もうアドベントカレンダーの季節ですね。
私はいま5歳の子どもを育てているのですが、来年はもう小学生です！時の流れ早すぎ〜と思いつつ、小一の壁にも震えています🥶
今回は、ここ最近強く実感した 「AI駆動開発とドメイン知識の重要性」 についてお話します。
背景：AIを使った0→1開発が想像以上に速かった
弥生では弥生会計 Nextをはじめ、Nextシリーズの新しいプロダクトを積極的にリリースしています。
その一環として、私も0→1フェーズの新規プロジェクトに関わり、企画段階からAIをフル活用して開発を進めました。
実際にやってみると、開発スピードが想像以上に速く、AIの効果を強く実感しました。
今回は、そのプロジェクトをどのように進めたのか紹介します。
実際にどんな流れで進めたのか
大きく分けると、次のようなフェーズを高速で回しました。
1. 調査フェーズ
- 市場調査
- アンケート調査
- 競合分析
- 社内外のドメインエキスパートへのヒアリング
こうした調査内容をまとめ、「どんな課題があり、どんな価値を提供すべきか」を言語化しました。
2. 要件化フェーズ
調査結果をもとに、ターゲット・課題・提供価値を整理し、
「どの機能を実装すべきか」をリスト化しました。
新規プロジェクトの場合、基本的には競合に対して後発プロダクトとなるため、競合製品と全く同じ機能を最初から提供することはできません。そのため、どの機能を優先して入れるかの選別が重要になります。
ここでターゲットがブレていたり、ドメイン知識が不足していると、誤った選択をしてしまうため注意が必要です。
3. 体験設計フェーズ
Figma Make を使って、機能のモックを高速生成しました。
これは本当にすごくて、 「実際に動くかのような画面」 が数分で出てきます。
モックとして実際に見たり動かすことで、「これは違う」「これは良い」といった議論・判断が一気に進みます。
そのFBを受けた修正もまたすぐに反映できるため、修正と議論のループを高速に繰り返すことができ、体験の磨き込みを非常に速く回すことができます。
今回の0→1フェーズでは、このサイクルの高速化こそが、全体のスピードを押し上げた最大の要因だったと感じています。
4. 仕様・設計フェーズ
モックをもとにAIに仕様書を出力させます。
- 画面仕様
- データベース設計
- API仕様
- ロジック設計
これはChatGPTなどにFigma Makeのスクショを貼り付けて「仕様をつくって」と指示するだけで、大枠の仕様を出力してくれたので非常に便利でした。ざっくり生成した後、見えないロジックや設計などの足りない部分だけ人間が補うことで、素早く設計を作り込むことができました。
5. 実装フェーズ
設計を指定すると、AIがコードをかなりの粒度で生成してくれます。
フロントもバックエンドも、動くレベルのプロトタイプなら約1ヶ月で大半ができあがる勢いでした。
これまでのやり方と比べて、体感2〜3倍以上のスピードで進んだ印象でした。
最大の課題：結局「何を作るか」が一番難しい
AIを使うほど、逆説的に
「何を作るのか」問題がめちゃくちゃ重くなる
ということがわかりました。
というのも、AIは
- 書いてないことは理解できない
- 曖昧な指示だと曖昧な成果物が返ってくる
- 誤った前提を渡すと高速に間違ったものができあがる
という特徴があるためです。
だからこそ、作る前に
- ターゲットは誰か
- 課題は何か
- どんな価値を提供したいのか
- 何が競合との差別化ポイントか
- その体験を実現するための手段は何か
といったドメイン知識とその言語化能力が、これまで以上に重要になります。
例えば、Figma Makeは、雑なプロンプトからでも「それっぽい」画面を作ることが得意です。
その一方で、プロンプトで明確に指示していない機能やボタンが、勝手に生成されることもよくあります。
こうした出力を精査せずにそのまま採用してしまうと、根拠のない“謎の機能” がそのまま仕様として立ち上がってしまいます。
実際、私もエキスパートから
「この項目はどういう意味なのか？」
「何をもとに出力しているのか？」
「むしろ混乱する要素なら、ないほうが良いのでは？」
と指摘を受け、結果的に機能の見直しになった経験があります。
このとき、高速に作れる分、間違った前提がそのまま形になってしまうリスクも同時に大きくなるということを強く実感しました。
もう一つの課題：思考の「明文化」がめちゃくちゃ難しい
AIを活用するには、
自分の頭の中にある考えを“言葉として出す力”が欠かせません。
どれだけドメイン知識を持っていたとしても、
「どう伝えるか」「何を渡すか」が整理されていなければ、AIはまともに動きません。
ドメイン知識を言語化すること自体が難しい
私の場合、業務システム領域に10年以上いるため、ある程度のドメイン知識はありました。
しかし、そこから「全部を一気に言語化しよう」とすると情報量が多すぎて、何から手を付けるべきか分からなくなってしまいました。
そこで、まずは抽象レベルごとに知識を段階的に出力するという方法に切り替えました。
- 最終的に管理したい情報は何か
- どんなユーザーがいて、どんな役割で何をする人なのか
- 業務フローにはどんなパターンがあるのか
- 初手で実装する機能、後回しにする機能を決める
- ユビキタス言語の整理
このようにレイヤーごとに書き出していくと、徐々に全体像が見えてきて、
AIに渡せるレベルの情報へと“先鋭化”できました。
AIの出力にフィードバックするには「ビジョン」が必要
また、AIが提案してきた案に対して、どこをよくしてほしいのか、どこが違うのかを指摘するためには、自分の中にある程度ハッキリしたビジョンが不可欠です。
私はそのために、既存プロダクトを触り込んで
「どの体験は踏襲すべきで、どの部分は改善したいのか」
をあらかじめ自分の中で固めておくようにしました。
ここが最大の学習コスト
AIをうまく使うには、
“自分の思考を明確に言語化する力” と “ビジョンを持って判断する力” が必須です。
個人的には、これこそがAI活用における最大の学習コストだと感じました。
結論：AI駆動開発ではドメイン知識がより重要になる
まとめると、
- AIで0→1開発は爆速になる
- しかしそのためには、「何を作るべきか」が前よりずっと重要になる
- ドメイン知識の深さと言語化能力が、AI開発の最大の武器になる
ということを強く感じました。
高速で作れるようになった分、
前段でしっかり考える必要が増え、ある意味ウォーターフォールの再発明のようにも感じます。
ただしそれは後ろ向きな意味ではなく、
「考えるべきところは人間が考え、作るところはAIに任せる」
という、役割分担がよりハッキリした新しい開発スタイルだと思っています。
Discussion