「思い描くことは、人間にしかできない」――Hakuhodo DY ONEが基幹会計のAI駆動開発で見た要件定義の現在地
株式会社Hakuhodo DY ONE

株式会社Hakuhodo DY ONE チーフAIストラテジスト 中原 柊 氏
中原 柊氏は、コンサルティングファームを経て4年前にHakuhodo DY ONEに参画した。AI×ITコンサル事業を統括するチーフAIストラテジストとしてチームを率いる中原氏には、確信に近い見立てがある。「思い描いたものは、AIが実現できる。だが、思い描くことは人間にしかできない」
中原氏がリードするチームは、開発プロセスそのものをAI前提に組み直す「AI駆動開発」を、数億円規模の基幹会計系のシステムで支援してきた。理論上は90%の工数削減が見える領域だ。だが、その数字の手前にある「過渡期の難しさ」を突破する実戦のノウハウは、まだ世の中にほとんど共有されていない――中原氏が描く、AI駆動開発の先にある要件定義の未来像を聞いた。
コンサル出身者で立ち上げた、AI・IT中心の事業
――中原さまが率いる組織のミッションを教えてください。
コンサルティング事業を作る、というのが私たちのミッションです。4年前に国内のコンサルティングファームを経て、そこから事業作りを進めてきました。広告会社というバックグラウンドは、今もグループの大事な柱ですが、それに加えてコンサルティング、テクノロジー、グローバル、ECを含む5つの事業領域で展開していく方針を掲げています。
――どのような案件が多いのでしょうか。
プロジェクトの比率としては、AIやIT関連が非常に多いですね。全体の7〜8割を、この領域が占めています。博報堂DYグループとしてAI活用に力を入れてきたところに、ITコンサルティング出身のメンバーが加わり、チームとして動いていく――それが私たちのコンサルティングビジネスの特徴です。
主な領域は上流工程で、まさに今回のサミットのテーマでもある要件定義などを多く手掛けています。私のチーム自体は開発部隊を持っていませんが、グループ内にはエンジニア組織もあるので、開発を伴うプロジェクトは連携しながら進めています。
――「チーフAIストラテジスト」とは、どのような役割ですか。
AIというキーワードに関わることであれば、基本的には何でもやる役割です。LLMの登場によってAIを取り巻く環境が大きく変わるなかで、AIと博報堂DYグループの強み、さらにコンサルティングを掛け合わせることで、クライアント企業にどんな価値を生み出せるのかを一気通貫で統括しています。私たちの役割は、社内向けのR&Dではありません。あくまで企業向けに、AIをどう事業や業務へ実装していくかを支援しています。

AI駆動開発はプロセスごとBPR――基幹会計でも実装
――「AI駆動開発」というアプローチを掲げていますね。これはどのようなものですか。
私たちは、AI活用を前提にしたプロジェクトそのものを設計し直す開発アプローチを、「AI駆動開発」と呼んでいます。単に開発工程でAIを使うという話ではなく、体制や作業環境、スケジュールや予算の組み方までを再設計していくニュアンスを含みます。
この1年で、技術的に最も進化した領域のひとつがコード生成です。要件定義のあとの詳細設計からコーディング、テストまでを自動化すると、私たちの実験では理論上、約90%の工数削減が見えてきています。ただ、システム開発はもともと一人で完結するものではありません。事業部門やユーザー部門があり、IT部門、システムベンダー、業務要件を整理する人、それをシステム要件に落とし込む人と、全体がつながりながら進んでいきます。そのため、AIが使えるからといって、いきなり全体の工数が90%削減されるわけではないのです。
――一つ一つの工程をAIに置き換えれば実現できる、というわけでもないと。
発想そのものが違います。これまでは、各プロセスのつなぎを担う人がいて、要件定義とプログラムの整合性を人がチェックしていました。そこが従来のまま残ると、結局ボトルネックになってしまうんです。なので、私たちはゼロベースで見直しています。人によるチェックポイントそのものをなくし、詳細要件以降のプロセスをテストまで含めてAIに担わせる。これが私たちの考えるシステム開発のBPR(ビジネスプロセス・リエンジニアリング)です。AIでできることを前提に、プロセスそのものを組み替えていきます。
そうなると、人を配置するタイミングも、運営委員会への報告のタイミングも変わってきます。リスク管理の考え方も、これまで以上に重要になるため、工数や予算の組み方自体が変わります。単にコーディング工程だけを考えてプロセスをAI化するのではなく、社内報告をどう設計するか、ユーザー部門へのヒアリングをいつ行うかまで含めて、プロジェクト全体を再設計していく必要があります。
――実際にはどのようなプロジェクトで実装されたのですか。
あるお客さまの会計系システムで、実際にAI駆動開発へ取り組みました。今回のサミットに来られる方の中には、「そこまでAIでやるのか」と驚かれる方もいるかもしれません。会計システムは、間違いが許されない、非常に重厚な基幹システムです。数億円規模のプロジェクトでしたが、先方の代表によるトップダウンの意思決定で、AI活用を前提に進めることになりました。
体制としてはマルチベンダーでしたが、お客さまの強い意思もあり、関係者全員が集まって、「どのような進め方をするか」を共通認識として持ちながら推進しました。
また並行して、グループ内のシステム統合プロジェクトでもAI駆動開発を実践してきました。この2つのプロジェクトを通じて、かなりノウハウが蓄積されてきています。

90%削減の先に残るのは「要求を作る」仕事
――AI駆動開発の過渡期で、どのような課題が見えていますか。
理論上90%の工数削減ができるのなら、当然「事業会社から開発ベンダーへの発注金額は10分の1になるのか」という議論が出てきます。一方で開発ベンダー側からすれば、そう簡単に値下げに応じるわけにもいかず、少なくとも現状ではそれほどの理論値通りの開発はできないため、これまでの同じ水準の金額を請求します。そこにはどうしてもコンフリクトが生まれます。コンサルタントとしては、その間をどう整理し、落としどころを作っていくかが腕の見せ所です。
また、PoCのフェーズはすでに過ぎ、2026年は“実際にどれだけ収益インパクトが出せるか”を求められる局面に入っています。コーディングを担う人員は減っていく一方で、ユーザー要件をより細かく引き出せる人材は、むしろ増やさなければならない。あるいは、バックオフィスの人員を営業フロントへシフトして収益につなげる――こうした組織構造や人員配置の見直しも、いま経営者が重視している論点です。
――人間でなければできない部分は、どこに残るのでしょうか。
「要求定義」だと思っています。何を目指すのかというWhy、どう実現するかのHowがあって、その間にある「何を作るべきか」というWhatを考える仕事は、原理的にAIに代替させてはいけないのではないかと考えています。現在のAIは、基本的に人間の頭を超えないようにできていますから、思い描くことは人間にしかできないはずです。
たとえば、人事評価システムの設計で、「期初の目標設定を誰が入力できるか」という機能要件を検討したことがあります。あるお客さまでは、最初の申請は絶対に本人しかできない仕様にしました。目標は自分で立てるものであり、上から押し付けられるものではない――そうした会社としての考え方を、システムの機能で表現したわけです。これは、単にシステムだけを考えていても出てこない発想です。人がどうあるべきか、組織をどう作るべきかという議論を重ねながら設計するからこそ、生まれてくる機能だと思います。
――AI時代ならではのシステム設計の工夫もあるのでしょうか。
博報堂DYグループ内で使っている「STRATEGY BLOOM」というシステムがあります。AIに商品コンセプトの案を出させたあと、次の機能に進むには、最低限コピペでも自分の入力欄へ書き直さなければ先へ進めない設計にしています。OKボタン一つで進めるようにはしていません。そこで一度、自分の頭で考えて書いてほしいからです。
これから重要になるのは、AIと人間のインタラクション、いわゆる「Human-AI Interaction(HAI)」の設計だと思っています。たとえば、とても単純化すればこのような話になります。AIの返答の最後に「知らんけど」とつけるだけで、「全面的に信じるな」というニュアンスを自然に伝えられる、ということです。「間違えることがあります」と注意書きを表示するより、人間側の行動を促しやすい場合もあるんです。
AIをどう賢くするかだけではありません。人間がAIとどう向き合い、AIをどう制御するかまで含めて設計すること。それ自体が、新しい時代の要件定義になっていくのだと思います。

ユーザーとベンダー、双方の視点から語るAI駆動開発
――サミットでは、どのようなお話をされる予定ですか。
会計領域を含む基幹システムでAI駆動開発を実現するまでの過程について、難所と突破口を含めて実例ベースでお話しする予定です。私たちはコンサルタントの立場として、ユーザー企業側にも、開発ベンダー側にも関わっています。そのため、どちらか一方ではなく、双方の視点からみた、実戦のノウハウを共有したいと思っています。
「AIエージェントが意志を形にする」というのが今回の登壇テーマです。単なる技術論ではなく、AI駆動開発を企業のなかでどう実装し、どう運用していくのか。プロジェクト設計から組織のあり方まで含めて、要件定義そのものがここから変わっていく――そのリアルな現場の話にご期待ください。