「自分で考え、自分で作る時代は終わった」――日本IBMが描く、AIエージェントが動かす開発プロセスの全貌

コーディングの自動化だけがAI活用ではない。要件定義から設計、テストまで――開発ライフサイクル全体をAIで貫く構想を、日本IBMは持っている。その基盤が、開発情報を一元管理する「IBM ELM（Engineering Lifecycle Management）」、要求品質をAIで検証する「Engineering AI HUB」、そして対話を通じて要件生成からアプリケーション構築まで実行するAIエージェント「IBM Bob」だ。

20年にわたり製造業の開発支援に携わる藤巻 智彦氏と、エージェンティックAIによる全社変革を推進する木下 智文氏。製品技術とコンサルティング、2つの視点から、開発現場でいま何が変わりつつあるのかを聞いた。

「様子見」から「実装」へ――変わり始めた企業の空気

――「AIエージェントで開発が変わる」といわれますが、実際に企業の温度感はどう変化していますか。

藤巻氏： 開発業務においても、AIによる支援はほぼ必須という状況です。生成AIが話題になった一昨年から関心が徐々に広がり、この1年で一気に実装フェーズに入った感覚があります。

木下氏： 昨年の頭は、「エージェント元年」といわれました。ただ、この1年間は企業の中でも「どんなものだろう」という様子見の空気が続いていました。お客さまの経営幹部に動向を説明しても、「少し調べてみる」という反応がほとんどで、自分自身では触っていないため実感が湧かない。けれど第三者の声は聞いておきたい――そんな温度感でした。

それが年明け以降、今年度予算の議論に入った段階で空気が変わってきました。「何ができるのか」「どう進めればいいのか」という具体的な会話が増え、AIエージェントの実装に着手する企業が出始めています。各社からエージェンティックなプロダクトが相次いで登場していることも、背中を押しているのだと思います。

組織・ツール・商流――開発現場の3つの分断

――AIの活用が進む一方で、そもそも開発プロセス自体に課題を抱える現場も多いのではないでしょうか。

藤巻氏： おっしゃる通りで、一番大きいのは組織が違うということです。大規模な開発になればなるほど、要件を書く人、設計する人、実装する人、テストする人がそれぞれ別の事業体に属している。発注元と受託側という商流の分断も加わります。使っているツールもバラバラで、上流では要件をWordやExcelで書き、それをファイルで設計者に渡す。設計者はまた別のツールで設計し、次にプログラマーへ渡す。最初に作る時点ではまだいいのですが、途中で変更や不具合が発生した際、影響がどこまで及ぶのかが分からなくなる。上から下まで全体を見通せる人がいません。

木下氏： 根っこには日本の製造業の歴史があります。ハードウェア主体のものづくりが長く、ソフトウェアはハードで実現しきれない部分を補う位置づけでした。エレキ（電子回路）・メカ（機構）・ソフトの各領域を横断して全体を設計するシステムアーキテクトというポジションが存在しない、あるいは機能していないケースが非常に多い。本来であればシステム要件を上位で定義し、各領域にブレイクダウンしていくV字開発の階層があるはずですが、実際にはその中間層が飛ばされて、各担当部門が個別に動いているのが現実です。

そのため、1つの仕様変更に対して影響範囲を特定するだけで膨大な時間がかかる。協力会社に外注している部分があれば、そちらにも確認を取らなければならず、回答を待つだけでスケジュールが延びていく。ここが現場の一番の悩みどころです。

――分断の根が深いことはよく分かりました。では、IBMはそれをどう解こうとしているのですか。

藤巻氏： 私たちが提供している「IBM ELM」は、開発ライフサイクル全体の情報を一元管理するソリューションです。要件、設計、プログラムコード、テストケースとその結果――これらをすべてデータベースに格納し、細かい単位で関連性をトレースできるようにする。私たちはこれを「デジタルスレッド」と呼んでいます。開発工程における成果物を一連の情報として管理し、その関係性を追跡可能にするという考え方です。

たとえば自動車のクルーズコントロールシステムを開発する場合、「時速50km以上で前方車両に追従する」という要件をELMに格納します。その要件をブレイクダウンした設計情報や、設計に基づくプログラムコード、テストケースや結果も同じ基盤上で管理されます。

仮に要件が「時速30km以上」に変更された場合、設計のどこを修正し、コードのどこに影響し、テストをどのようにやり直す必要があるかを一連の情報として辿ることができます。Excelでファイルをやり取りしていると、どれが最新か、変更箇所はどこかを人が追いかけなければなりませんが、ELMではそれらが連携され、情報のつながりとして把握できます。

木下氏： 先ほどお話しした、エレキ・メカ・ソフトの振り分けについても、上位のシステム要件からどう各領域に落とし込むかが本来の手順です。日本の現場ではその階層が抜け落ちがちですが、ELMを導入することで少なくとも情報のつながりが可視化され、変更時の影響範囲を特定できるようになる。今まで見えなかったものが、徐々に見えるようになってくるわけです。

藤巻氏： もう一つ、「Engineering AI HUB」という機能があります。これは、ELMに記述された要求が分かりやすいかどうかをAIがスコアリングし、ガイドラインに基づいて判定する仕組みです。たとえば、曖昧な表現がないか、単位や条件の記述に抜けがないか、文の構造に不備がないかといった観点で自動的にチェックを行います。これにより、要求文書の品質を上流の段階で底上げすることができます。こうした抜け漏れや曖昧さは、これまで人がレビューするしかなかった。そこをAIが初期段階でチェックすることで、下流工程での手戻りを減らすことができます。

社内9,000名が使う、AIエージェント「Bob」の実力

――ELMが開発情報の基盤、AI HUBが品質チェックだとすると、そのうえでAIが実際に手を動かすレイヤーもあるのでしょうか。

藤巻氏： はい、それがAIエージェント「IBM Bob」です。ユーザーとの対話を通じて要件を生成し、コードを書き、最終的には動作するアプリケーションまで作ることができます。ぼんやりとしたニーズであっても、Bobに投げると問い返しながら、やり取りを重ねて望む形に近づけていきます。汎用の生成AIツールとの違いは、企業利用を前提に設計されている点です。Bobで扱う情報はIBM内に保存されず、データは転送時・保存時ともに暗号化されます。セキュリティとガバナンスが最初から組み込まれている仕組みです。

木下氏： もう一つの違いはプロセスの制御です。最近はバイブコーディングという言葉が広まっていますが、これは自然言語でざっくりとイメージを伝えるだけでAIにコードを書かせる手法です。ただ、そのまま使うと指示を出したら最後まで一気に処理が進んでしまう。Bobには「ここまで進んだらレビューする」といったチェックポイントが組み込まれています。速さだけではなく、途中で立ち止まって確認できる。企業の開発にはそうした仕組みが必要です。

IBM社内ではBobをすでに本格的に使用しています。私たちはこれを「クライアントゼロ」と呼んでおり、自分たちが0番目のクライアントとして徹底的に使い込みます。現在、約9,000名が利用しており、全体で約45%の効率向上がみられています。

藤巻氏： こうした社内実践を経て、2026年3月から外部提供も開始し、すでに数十社に導入いただいています。特に長年使い続けてきた既存システムの解析や刷新といったレガシー資産のモダナイゼーションにおいて、AIエージェントを活用したいという声が多く、そこでの引き合いが増えていますね。

「考える」は変わらない――エンジニアに求められる新しい力

――AIがここまで開発プロセスに入り込むと、エンジニア自身の役割も変わらざるを得ないのではないでしょうか。

藤巻氏： これまでエンジニアは、自ら考え、手を動かしてものを作ることが役割でした。それがAIエージェントの登場によって、考えるという部分は変わらないものの、手を動かす作業はAIに移っていきます。そしてもう一つ、AIが出した結果が適切かどうかを見極めるという仕事が加わります。現場の実務担当者であっても、これまでリーダーやマネージャーが担っていたレビューの視点を持つことが求められます。さらに、リーダーやマネージャーも、各メンバーがAIの出力をきちんとレビューしたうえで成果物として提出しているかどうかを判断する必要があります。

木下氏： そこで問われるのが説明責任です。AIの処理はブラックボックスになりやすく、なぜこのコードになったのか、なぜこの設計なのかを、人が説明できなければ発注元は受け入れられません。

正直にいうと、外注開発の領域ではAIの活用はまだ難しい面があります。AIが生成したものをどこまで信用できるかの基準やガイドラインが十分に整っておらず、合意形成もこれからの段階です。自社内の開発でAI活用が先行しているのは、こうした事情があります。

――自社開発と外注開発で温度差があるなか、サミットではどんなメッセージを伝えたいですか。

藤巻氏： AIを使った開発の効率化と品質のトレードオフを、どう担保するか。その考え方と手段を紹介したいと思っています。速く作れるようになっても、品質が落ちては意味がない。トレーサビリティと要求品質を押さえながら、AIエージェントで開発を加速する――その両立の道筋をお見せしたいですね。

木下氏： ソフトウェア開発にはさまざまな分野があります。情報システム系もあれば、製品開発系もある。今回のセッションではその両方のお話をしたいと考えています。日本のソフトウェア開発は、長年の積み重ねの結果として、現在はかなり複雑で難しい状況にあります。多重下請け構造、分断されたプロセス。こうした苦しさを打開するために、AIは大きな可能性を持つと考えています。セッションがそのヒントを持ち帰っていただく場になればと思います。