「動くアプリがあれば、コンセンサスは取れる」――日立製作所、AI×ローコードで要件定義の常識を書き換える

銀行向けシステム開発に約20年携わり、現在はAI技術を活用した開発の標準化を推進する日立製作所の広瀬 雄二 氏。同氏が手がけるのは、生成AIとローコードツールを組み合わせ、プロジェクト開始から30分で「動くアプリケーション」を生成する仕組みである。エンタープライズSIの上流で繰り返されてきた「作り手と顧客の認識が揃わない」という構造的課題に、成果物を先に見せることで合意を前倒しする――「モダナイゼーション powered by Lumada」の一翼を担うこの取り組みについて、広瀬氏に聞いた。

――まずはご経歴と、現在のミッションを教えてください。

元々は銀行向けの受託開発を20年ほど担当していました。営業店まわりからバックエンドにかけて、勘定系を含む基幹系システムの周辺領域を幅広く経験しています。ここ最近は、そこで培った知見を他業種・他領域へ展開していく部署に異動し、現在はテクノロジートランスフォーメーション本部に所属しています。

ミッションは二つあります。一つはAI技術を使ったアセットの開発。もう一つは、AIを開発に活かす際の標準化や枠組み、進め方の整備です。「開発に資するものは、すべてカバーしていく」というのが基本的な立ち位置です。最近はLLMの性能が急速に上がっており、開発のあり方そのものが変わりつつあると感じています。その変化にどう付き合っていくかが、今いちばんホットなテーマになっています。

コンセンサスを得るまでが、とにかく長い要件定義の現場

――要件定義の現場では、どのような課題が起きやすいのでしょうか。

ひとことで言えば、「こういうものを作るんだよね」というコンセンサスを得るまでに、非常に時間がかかることです。

エンタープライズのお客さまの場合、作るものは相当複雑です。インターネット上に公開されている数画面のアプリとは、求められる内容や複雑さが異なります。画面数もエンティティの数も多く、全体像を掴むだけで大変です。お客さまから話を聞いて、我々も理解して、「こんな感じですかね」とやりとりしていくわけですが、まずそこに時間を取られる。加えて分量が膨大なので、一つひとつ詰めていく時間がどうしてもかかります。

さらに厄介なのが、プロジェクトの進行に伴う人の増加です。最初は少人数で始めるのですが、チームが拡大するにつれて新しいメンバーが入ってくる。その人たちに「今こういうものを作っている」と追いついてもらい、全員の認識を揃え続けるのは相当な労力です。これはAIが登場する以前からずっと続いてきた構造的な問題で、どの現場でも繰り返されてきたことだと思っています。

――AI登場以前から続く問題なのですね。それがなぜ今、打ち手が見えてきたのでしょう。

ここ最近のLLMの進化が大きいです。コーディングやテスティングの生産性を上げるという話はすでに広がっていますが、それだけではなく、情報を集めてきて推論する――つまり上流工程の「整理して考える」部分にも十分使えるレベルになってきました。以前は要件定義のような曖昧さを含む工程にAIを持ち込むのは難しかったのですが、今のモデルであればそこに手を入れられる。長年手つかずだった課題に、ようやく技術が追いついた。そういう感覚です。

生成AI×ローコード――30分で動くアプリを作る仕組み

――日立の取り組みは、具体的にどのような仕組みなのでしょうか。

生成AIを使ってローコードツールのインプットまでを作り、それをローコードツールに投入することで、最初のところから30分ほどで動くアプリケーション（プロトタイプ）が出来上がる。プロトタイプを元に、テスト項目の計画など、開発工程も変わる。といった流れです。

入り口は二つあります。一つは、まっさらな状態から始めるケース。お客さまの業種やシステムの概要を4つほどインプットとして与えると、AIが「この業界のお客さまであれば、こんな課題を抱えているはずで、こういう機能が必要だ」と膨らませて仕様書を作っていく。極端に言えば、お客さまを初めて訪問する前の段階で、たたき台を用意してしまうこともできるわけです。

もう一つは、既存のシステムがある場合です。専門ツールでソースコードを解析してメトリクスを取り、パスの解析などを行う。その情報をもとに「きっとこんなシステムではないか」とAIが推論し、そこから同じようにローコードのインプットを生成します。新規とモダナイゼーション、両方に対応できる構成です。

中の作りとしては、一連の作業ステップごとにAIエージェントを構築しています。仕様の推論、ドキュメント生成、ローコード向けの定義ファイル作成といった各工程を、それぞれのエージェントが担う形です。

――生成AIから直接プロトタイプを生成する選択肢もあると思います。なぜローコードを挟む構成を取ったのでしょうか。

テキストからプロダクトを一度で生成できるツールはいくつもありますし、当然さまざまなものを試しました。ただ、フロントエンドからバックエンド、データベースまで含めて、すぐにビルドできるコードを一度で出力できるかというと、現状ではまだ難しいのが実情です。

一方、ローコードツールを介せば、定義ファイルに従って正しいコードを生成してくれます。ルールベースでガッチリ動いてくれるので、出力の信頼性が担保できる。ここが生成AIだけで完結させる場合との決定的な違いです。現時点の技術的なバランスとしては、これがベストだと判断しました。もう少し先はわかりませんが、現時点ではこの構成が最適解だと考えています。

――どのようなシステムを想定されていますか。具体例があれば教えてください。

ターゲットは業務システム、いわゆるマスターデータを更新していくタイプのシステムです。照会をかけて一覧が出てきて、クリックすると明細にドリルダウンして、そこで変更をかける――受発注システムのような、入力パターンと出力パターンがある程度確定しているものであれば、このアプローチが効果的です。すべてのアプリケーションをカバーできるわけではありませんが、ローコードの守備範囲に収まるものは十分に手応えがあります。

実際、ローコードベンダー経由でお客さまにデモをお見せした際の反応としては、大変驚かれていました。店舗ごとの在庫管理システムを題材にしたのですが、ポイントはアプリケーションだけでなく、マスターデータやトランザクションデータもAIで一緒に生成した点です。照会をかけるとそれらしい名前や電話番号が出てくる。テスト用のダミーデータではなく、実際の運用を想起させるデータが入っている状態で見せられるので、お客さまの解像度が一気に上がります。30分でそこまで出来上がるのは、やはりインパクトがあったようです。

成果物がある状態からスタートする――開発プロセスの逆転

――最初から動く成果物がある状態でスタートすると、後工程はどう変わりますか。

一つ確実な変化だと言えるのは、最初からテスト項目を作り始めることができるという点です。今は散々開発した後にテストのチェックリストを作っていますが、動く成果物があれば、場合によってはお客さまに「先にテスト項目を作っておいてください」とお願いすることもできる。それが完了条件になる、という進め方も現実味を帯びてきます。

開発プロセス全体の順序も変わります。従来は要件定義書から仕様書、コーディングと順を追って進めていましたが、このアプローチでは最初の段階から仕様書もソースコードも、ビルド手前のものも設計書も一通り出せる。「一番最初から雛形がある、そんな世界」です。ゼロから積み上げるのではなく、ある程度の形が揃った状態から精度を上げていくイメージに変わります。

通常のプロジェクトでも、テスト後半になると全員が仕様を把握し、バグ修正が速くなるケースがよくありますよね。その状態に近いところからスタートできれば、仕様の変更や追加が発生しても、すぐに取り込んで対応できる。ループが最初から速く回る、そういう効果が期待できます。

――このアプローチで、日立ならではの強みはどこにあると考えますか。

AIの出力品質は、何を指示するかで決まります。そこで効いてくるのが、最初に生成するドキュメントの種類や記載レベル、フォーマットに関する蓄積です。長年のSI開発で培ってきた「このプロジェクトならこの成果物をこの粒度で出す」というノウハウがあり、それを生成AI側に「このフォーマットで出力して、こういう項目を必ず含めてください」と指定できる。AIが賢くなっても、何を出すべきかの設計がなければ出力は揺れます。そこを標準化できているのが、日立の基盤になっています。

こうした取り組みは、日立が提供している「モダナイゼーション powered by Lumada」ソリューション群の一部に位置づけられます。モダナイゼーションにはさまざまなアプローチがありますが、今回お話ししたのはそのなかでも上流工程にフォーカスした取り組みです。既存システムの解析から新規開発まで、AI×ローコードで初期の合意形成を高速化する――これがモダナイゼーション全体のなかで果たす役割だと考えています。

ドキュメントの読み手は、人間か、AIか

――「AI要件定義サミット2026」ではどのようなお話が聞けますか。見どころを教えてください。

成果物が最初からある状態でスタートできるので、そこから先の開発のやり方も変わっていく――この点をお伝えしたいと思っています。要件定義書を書いてから仕様書を書いて、それからコーディング、という従来の順序が崩れつつあります。日立グループが蓄積してきた開発ノウハウをAIに組み込むことで、初期段階から成果物一式が揃う世界がどう実現するのか、具体的にお見せできればと考えています。

また、個人的に問題提起したいのは、ドキュメントの読み手の話です。今は人間が読むことを前提に成果物を作っていますが、本当にそれが正しいのか。今後は、人だけでなくAIも理解し活用することを前提としたドキュメントへと発想を変えていく必要があるのかもしれません。そこは今後の発展次第ですが、そうした問いも、これからの開発のあり方を考えるうえで重要だと認識しています。