Hitachi
お問い合わせお問い合わせ
6月11日(木) に開催された「AI要件定義サミット2026」に日立製作所アプリケーションサービス事業部の広瀬雄二が登壇しました。
本イベントは、「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×ローコード――30分で動くアプリを作る仕組み

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

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

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

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

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

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

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

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

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

「AI要件定義サミット2026」(主催:株式会社ROUTE06)インタビュー記事より転載
本記事は株式会社ROUTE06社より許諾を得て掲載しています。
イベントサイト:https://ai-requirement-definition-summit.com/2026
イベントレポート:https://ai.acsim.app/news/ai-requirements-summit-2026-report

AI要件定義サミット2026 登壇の様子

タイトル要件定義の認識ギャップをどう埋めるか
〜AI×ローコードによる合意形成の実践アプローチ〜
概要本講演では、AIとローコードツールを組み合わせた、
システムインテグレーションにおける要件定義の進め方そのものを
見直す新しいアプローチをご紹介します。
プロジェクト立ち上げ時に必要な成果物一式を、日立がこれまで培ってきたSIの知見と、
AIとローコードの活用によって、早期に“動く形”として可視化します。
この可視化を通じて、関係者間の合意形成をどのように加速し、
後続する開発をより円滑に進められるのか、実践的なヒントをお伝えします。

当日は会場内で最大規模のホールが満席となり、立ち見が出るなど、来場者の関心の高さがうかがえました。講演では、AIとローコードを組み合わせたアプローチの一例として、デモ画面のスライドなども提示され、大規模開発において要件定義段階から成果物イメージを可視化する取り組みが紹介されました。さらに、従来の「人が読む要件定義」から「AIが読む要件定義」への発展といった将来的な開発プロセスの方向性にも触れ、要件定義を成果物ベースで捉える新たな考え方の可能性が示されました。

画像1: 「動くアプリがあれば、コンセンサスは取れる」――AI×ローコードで要件定義の常識を書き換える
画像2: 「動くアプリがあれば、コンセンサスは取れる」――AI×ローコードで要件定義の常識を書き換える
画像3: 「動くアプリがあれば、コンセンサスは取れる」――AI×ローコードで要件定義の常識を書き換える
画像4: 「動くアプリがあれば、コンセンサスは取れる」――AI×ローコードで要件定義の常識を書き換える

日立へのお問い合わせ先

以下Webサイトのフォームよりお願いします

関連サイト

This article is a sponsored article by
''.