日立製作所のAgentic AI Integration Platformとは？要件定義240倍の衝撃

この記事のまとめ

日立製作所が発表した「Agentic AI Integration Platform」は、要件定義から運用までの全工程にAIを全面適用する新しい仕組みです。社内検証では、要件定義で最大240倍、設計からテストで約200倍の生産性向上を確認しました。ここでは、その全体像と押さえておきたいポイントを紹介します。

要件定義最大240倍・設計からテスト約200倍という社内検証の数値を公表しました。
金融や公共、社会インフラなど大規模システムへの適用を進めます。
2027年度に工程全体で生産性30%向上を目標に掲げています。
フロンティアAIの選択やFDEによる伴走で安全性と実効性を両立します。

Agentic AI Integration Platformとは

Agentic AI Integration Platformは、日立がエンタープライズ向けシステム開発の全工程にAIを組み込んだ基盤です。構想策定から要件定義、設計、コーディング、テスト、運用までの各工程に、目的に合ったAIエージェントを配置し、連携して動かします。私がこの発表で注目したのは、部分的なコード生成支援ではなく、上流の構想段階から下流の運用まで一気通貫でエージェントを配置するという設計思想です。ここでは、その位置づけと社内で確認された生産性の数値を見ていきます。

まず基盤の全体像を押さえ、次に発表された実証値の中身を確認します。数字だけが独り歩きしやすい発表だからこそ、条件も丁寧に見ておく必要があります。

プラットフォームの定義と位置づけ

本プラットフォームは、顧客のAIトランスフォーメーションを加速するために開発された基盤です。構想策定や外部環境分析から要件定義、設計、コーディング、テスト、運用まで、工程ごとに最適なAIエージェントを組み込む構成です。AI駆動型のシステムインテグレーションを実現し、安全性を確保しながら生産性を高めるとしています（参照*1）。

発表は7月24日に行われ、エンタープライズ向けシステム開発にAIを全面適用する基盤として位置づけられました（参照*2）。

この位置づけのポイントは、部分的なコード生成ではなく、上流の構想から下流の運用まで一気通貫でAIエージェントを配置するところにあります。読者としては、どの工程にどのエージェントが入るのか、全体の流れをまず頭に入れておくと理解が進みます。

要件定義240倍・設計〜テスト約200倍の実証値

社内検証では、要件定義工程で最大240倍、設計からテスト工程で約200倍の生産性向上を確認しました。OT領域の実務者とIT部門がシステム画面仕様を確定する作業で最大240倍、自社パッケージ製品の機能拡張を対象にした仕様駆動開発の試行で約200倍の生産性向上という内容です（参照*3）。

この基盤は9月より大規模プロジェクトへ順次適用され、社内利用環境は整備が完了し、6月から先行利用が始まっています。設計からテスト工程で約200倍の生産性を実証し、第1四半期では期初計画を上回る効率を実現したと公表しました（参照*4）。

数値はいずれも社内の特定工程、特定条件下の実証値です。私が生成AIの導入支援をする中で何度も見てきたのですが、「○○倍」という数字は、比較対象の設定次第で大きく変わります。対象工程が要件定義や設計からテストに絞られている点、社内の題材を使った検証である点を踏まえたうえで、自社への適用可能性を判断するのが自然です。

開発の背景と日立のSI変革の系譜

本プラットフォームが生まれた背景には、日立がこれまで積み上げてきたシステム開発の歴史と、現場が直面している課題があります。この2つは切り離して考えられないため、順番に見ていきます。

熟練エンジニア不足とレガシー刷新の課題

本プラットフォームは、熟練エンジニアの減少という社会課題に応えるために開発されたとしています。加えて、大規模なレガシーシステムを抱える金融・公共分野やエネルギー、鉄道といった社会インフラの領域では、モダナイゼーション需要が拡大しています（参照*1）。

また、OpenAIとの連携も本格化しており、両社のFDEが組み、OpenAIのAIエージェント「Codex」を使ってレガシーシステムの既存コード解析や上流仕様の可視化、新システムへの移行テストまでを支援するAIモダナイゼーション手法の確立を目指しています（参照*5）。

人手不足と老朽化した基幹システムの刷新は、どの企業にとっても「わかってはいるが動けない」問題です。上流の要件を読み解く力と既存コードを解きほぐす力の両方が必要なため、AIエージェントで工程全体を支える発想が現実味を帯びてきます。私がコンサルティング現場で見る限り、レガシー刷新の最大の壁は技術よりも「誰が要件を言語化するか」にあります。そこへAIを当てようとしている点に、この取り組みの本質があると見ています。

Justwareから生成AI活用への進化

日立は1970年から日立標準システム開発方法論を確立し、開発プロセスや成果物の標準化に取り組み、50年以上にわたり継続的にアップデートしてきました。2002年には、設計書からソースコードをルールベースで自動生成する「Hitachi Application Framework Justware」を導入し、社会インフラをはじめとする200以上の大規模ミッションクリティカルシステムで、高品質・高信頼のシステム構築を進めてきました（参照*6）。

この流れは近年の生成AI活用にもつながっています。MS&ADシステムズとは、保険分野の基幹システム開発のコーディング・単体テスト工程で約25%の生産性向上を実証し、静岡銀行と静銀ITソリューションとは、ミッションクリティカルなオープン勘定系システム開発のコーディングと単体テスト工程で約30%の生産性向上を実証し、実適用を進めています。こうした先行案件を通じて、日立のシステム開発におけるAI活用率はすでに60%を超える水準に達しています（参照*1）。

ルールベースの自動生成から、生成AIを組み込んだ工程横断の支援へと、道具立ては段階的に変わってきました。Justware以来の標準化の積み重ねが、本プラットフォームの土台になっている点は重要です。50年以上の知見をAIが読み取れる形にそろえてきた蓄積があるからこそ、エージェントに任せられる範囲が広がるとも言えます。

AI駆動型SIを支える仕組み

AI駆動型SIを支える仕組みは、大きく3つの要素で構成されています。フロンティアAIを柔軟に選べる基盤、企業ごとの知識を蓄えるナレッジ、そして現場に入り込む専門家集団です。ここから順に見ていきます。

エンタープライズAI基盤とフロンティアAIの柔軟な選択

日立は、Anthropic、Google Cloud、OpenAIなどの先進的で高い情報処理能力を持つフロンティアAIを柔軟に選択できるエンタープライズAI基盤を整えています。この基盤には、大規模システム開発向けの「Hitachi GenAI System Development Framework」や、アジャイル開発に適したGlobalLogicの「VelocityAI」といったツールに加え、セキュリティ・コスト・信頼性を管理統制する機能が含まれます。VelocityAIとの連携環境では、AI単体での利用比でトークン利用料を最大54%削減する運用面の効果も確認しています（参照*1）。

複数のフロンティアAIを切り替えられる設計は、用途ごとに得意分野の違うモデルを使い分けたい現場には扱いやすい構造です。私自身、ChatGPT・Claude・Geminiを業務によって使い分けていますが、エンタープライズの大規模開発では「どのモデルを使うか」より「コストとセキュリティをどう管理するか」が先に問題になります。その管理を一元化できる点は、大規模開発では見逃せないところです。

企業コンテキストとAI Readableナレッジ

顧客ごとの業務知識や判断基準などの暗黙知は「企業コンテキスト」として蓄積されます。ここには、日立がミッションクリティカルシステム開発で培った知見を集約したナレッジベースも備わっています。AIエージェントは、構想策定から開発、運用までの各工程で得た情報を継続的に学習し、ナレッジを自律的に更新することで、開発の品質と生産性を高めていきます（参照*3）。

業務ルールをAIが読み取れる形にそろえておくことは、エージェントの判断精度に直結します。私が生成AI導入支援で最初に詰まる場面もここです。「AIに何をさせるか」を定義する前に、業務の判断基準や暗黙知が言語化されていないケースが多い。AI Readableなナレッジをどう作り、どう更新し続けるかが、成果の持続性を左右する最重要ポイントだと考えています。

FDEによる伴走型導入

FDE（Forward Deployed Engineer）は、顧客の開発現場に入り込み、顧客の経営意図や実務ルールをAIが読み取れるデータ形式に変換して蓄積する役割を担います。この仕組みにより、AIエージェントが業務を実行して得た結果やフィードバックをもとに、自律的に知識を更新して品質を高めるサイクルを確立します（参照*7）。

FDEは、利用部門から要件を聞き出し、システムを設計し、プロトタイプから本番までの開発を主導し、時にはコードまで書く役割として説明されています（参照*8）。

AIエージェントは万能ではなく、現場の暗黙知をどう吸い上げるかで成果が大きく変わります。FDEは、その入り口を担う役割です。経営意図と実務ルールをAIが扱える形に変換できる人材は、実務ではまだ希少です。ここが整備できるかどうかが、導入の成否を分けると見ています。

AI支援型からAI自律型への進化段階

AIエージェントの使い方は、一段ずつ進化してきました。ここでは、その進化の段階と、工程全体を任せる設計の考え方を整理します。

プロンプト支援型・協働型・自律型の違い

日立の元山氏は、当初はプロンプトベースのAI支援型の活用だったが、その後、AIエージェントベースのAI協働型に進化させ、今回のAgentic AI Integration PlatformによりAgentic AIベースのAI自律型へと進化させることができると述べています（参照*6）。

支援型は人が指示を出しながらAIに手伝ってもらう段階で、協働型は人とAIが役割を分けて一緒に作業する段階です。自律型は、AIエージェント自身が工程を回していく段階にあたります。

段階が進むほど、人が担う仕事は「指示を出す」から「監督する」に変わっていきます。私が導入支援で見てきた企業の多くは、まだ支援型の段階にあります。自社の現状がどの段階にあるかを見立てておくと、次に何を準備すべきかが具体的に描けます。

工程全体をエージェントが主導する設計

新プラットフォームは、構想策定や要件定義から設計、コーディング、テスト、運用に至るまでのシステム開発全域をAIエージェントが担う仕組みです。これまでの部分的なコード生成にとどまらず、各フェーズに最適な能力を持った複数のAIエージェントを連携させて協調動作させます（参照*9）。

マルチエージェントシステムは、複数の特殊エージェントを組み合わせて、単一のエージェントでは扱いにくい複雑な問題を解きます。大きな目標を小さなサブタスクに分解し、それぞれを得意なエージェントに割り当て、協調型または階層型のワークフローで最終目標を達成する考え方です（参照*10）。

この設計は、工程の切れ目でエージェントを乗り換える運用に近い発想です。どこで人がレビューし、どこをエージェント同士に任せるかの線引きは、あらかじめ設計しておかないと品質管理が難しくなります。「できるだけAIに任せる」という方針だけでは、責任の所在が曖昧になるため、介在ルールの設計をセットで考える必要があります。

適用領域と導入ロードマップ

本プラットフォームの適用先と、その先に置かれた目標を見ていきます。適用領域の広がりと、生産性向上の到達点を順に確認します。

金融・公共・社会インフラでの展開

日立は、勘定系システムや運行管理システムなどの止めてはいけない基幹業務、データレイクや周辺系・情報系システムなどの止まっても致命傷ではないシステム、PoCやMVPといった試すためのシステム、制御系システムや決済業務などの規模は小さいが失敗できないシステムのいずれにも対応できるとしています（参照*6）。

また、大規模なレガシーシステムを有する金融・公共分野やエネルギー、鉄道などの社会インフラへも適用し、システムの継続的な進化を通じて顧客の競争力向上と持続的な成長に貢献するとしています（参照*1）。

業務の重要度も規模もばらばらのシステムを、同じ基盤で扱う設計になっています。自社のどのシステムを最初の題材にするかは、リスクと効果のバランスで選ぶべきです。私が推奨するのは、止まっても致命傷ではない周辺系から始め、小さく試して条件を確認してから基幹系へ広げる順序です。

2027年度に生産性30%向上という目標

日立は、約15,000のお客さまシステムのインストールベースと、長年の運用保守で培った経験を生かしながら、拡大するモダナイゼーション需要に対して本プラットフォームを全面的に適用し、2027年度に工程全体で生産性30%向上を実現するとしています（参照*1）。

特定工程の240倍や200倍という数字と、工程全体の30%という数字は、見ている範囲がまったく異なります。部分最適の効果と、全体を通したときの効果を分けて捉えると、目標の意味が読み取りやすくなります。現場への期待値のすり合わせに使う際は、この違いを明確に伝えることが重要です。

導入時の注意点とガバナンス

実務で使いこなすには、数字の読み方と、AIエージェントを動かす際のルール整備が欠かせません。ここでは、その両面を確認します。

実証値の解釈と過度な期待の抑制

日立は要件定義工程で最大240倍の生産性向上を確認したとしています。ただし、これらは同社内の特定工程、特定条件下での実証値であり、効果はプロジェクトの規模や特性で異なるとしています（参照*2）。

倍率の大きさだけが独り歩きすると、現場の期待と結果がずれてしまいます。対象工程がどこで、どんな条件で、何と比べた数字なのかを社内で共有しておくことが安全です。私が生成AIの導入相談を受ける中で感じるのは、効果測定の基準が曖昧なまま進んでしまうプロジェクトが多いということです。導入の初期は、自社の題材で小さく試し、条件をそろえた比較で効果を測る進め方が現実的です。

自律性の許容範囲と安全性の設計

業務で利用するAIエージェントについては、当該業務で許容できるリスクの程度に応じて、人の介在の程度を変える考え方が採用されています。介在の型として、常時介入するHITL、通常は自動で処理し例外時に人が介入するHITLFE、監督者として待機し必要に応じて介入するHOTL、人の介在なしに実行されるHOOTLの4つが挙げられています（参照*11）。

また、AIエージェントは、データにアクセスし業務システム上で行動するため、通常の生成AI機能ではなく管理対象のリソースとして扱い、所有者、目的、アクセス範囲、一意IDを台帳で管理することが重要だとしています。全AIエージェントに共通するガバナンスとセキュリティのベースラインを設定し、エージェントが動作を許可される前に満たすべき最低限の要件を定めておく考え方が示されています（参照*12）。

自律性の水準は、業務のリスクに合わせて選ぶものです。どの業務をどの型で運用するか、台帳とベースラインの整備をセットで進めると、安心して自律性を広げていけます。私が企業のAI導入を支援する中で感じるのは、ガバナンスの設計が後回しになりやすいという点です。「とりあえず動かしてから考える」では、ミッションクリティカルなシステムでは通用しません。

おわりに

日立のAgentic AI Integration Platformは、要件定義から運用までをAIエージェントが主導する構想を、社内検証の数値とともに具体的な形で示した発表です。要件定義最大240倍、設計からテスト約200倍という数字は、対象工程と条件を踏まえたうえで読み解く必要があります。数字の印象に引っ張られず、「自社のどの工程に、どんな条件で当てはめるか」を考えることが出発点です。

フロンティアAIの選択、企業コンテキストの整備、FDEによる伴走、そして人の介在の設計。この4つを自社の業務に合わせて一つずつ設計していくことが実務上の出発点になります。私が支援現場で繰り返し言うのは、「小さな業務で入力・出力・確認・効果測定を回し、ノウハウを貯めてから広げる」という順序です。大きな成果を目指すほど、最初の一歩を小さく設計することが重要になります。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））