IBMによるIBM i の生成AI戦略について思うこと
世界中が生成AIで半狂乱になっているところで、このテクノロジーをどのように使用したら、ミッションクリティカルなアプリケーション用のプラットフォームとしてIBM i を稼働するPower Systemsを選んでいる企業に役立てられるかということについて、IBM i プラットフォームを取り仕切っている人達が時により懐疑的、楽観的、現実的になっている姿を目にするのは新鮮です。
ハードウェアおよびソフトウェア テクノロジーの導入に関して、IBMロチェスターは常に現実的であり、しばしば革新的であったため、IBM i CTO（最高技術責任者）のSteve Will氏が、「COMMON Guided Tours 2024」シリーズの一環として、先日の「 IBM i & AI - Strategy & Update 」で明らかにした戦略は、なるほど、まさに予想していた通りのものでした。
AIとの統合が、IBM i にとって目新しいことではないのは言うまでもありません。IBMが、人気クイズ番組「 ジェパディ! 」に出演したWatson QAシステムを開発し、それを商用化し始めたのとほぼ同時期には、それをIBM i アプリケーションおよびデータベースに関連付ける仕掛けがありました。AIツールのWatsonスタックの商業的成功については異論もあるようですが、疑う余地がないのは、こうしたAIのQAバリアントの最初の波は、今日、大規模言語モデルで稼働している生成AIとは似ても似つかぬようなものだったということです。
しかし、これとは別に、IBMは顧客と協働して、より従来型の統計的なバージョンのAIの取り組みも行っています。それらは、LLMベースではなく、信用スコアの確認や、企業および個人の財務状況のリスク評価を行うのに利用されたり、食品の安全性の追跡管理や予測を行ったり、製造業者向けに製品設計の支援や顧客の好みの予測を行ったり、チャットボットを採用して運用や顧客対応を行なったりするものでした。
「Guided Tour」でWill氏が説明したように、IBMロチェスターは、生成AIで無茶なことをしようとするのではなく、以下のような、現時点で目を向けている生成AI向けの「3つの明らかなユース ケース」を念頭に置いているようです。
3つ目の領域、すなわち開発者エクスペリエンスに関しては、RPG向けコード アシスタントを開発するために、IBMが生のRPGコードとコード/説明のペアの提供を求めていることについて、すでにお伝えしたところです。 5月の記事では、コード アシスタント製品に関する取り組み を紹介し、 7月の記事では、RPGコードを理解するGranite 8Bモデルを開発するためにIBMが提供されたコードをどのように使用するのかについて取り上げています。
「これまでの戦略は、IBM i 上で稼働するソリューションがIBM i およびPowerのメリットを生かして、現在そして次に必要となるどのようなことでも実現できるよう投資することでした」とWill氏は説明しています。「つまり、そうしたソリューションの改善をどう進めるかを選べるようにし、テクノロジーを統合することによってそれを可能な限り単純化するということでした。そのため、AIに関して言えば、顧客は彼らのソリューションおよび彼らのデータで稼働するAIを求めているのだということを私たちが承知しているということでもあります。顧客は新たなAIワークロードを稼働するためだけにIBM i を購入するのではないのです。それは、私たちが目指しているものではありません。私たちが目指しているのは、現在使用しているソリューションを、AIを活用するように拡張できるようにすることなのです。それは、AIがどのようにデータベースを使用するかという点かもしれませんし、AIがどのようにAIワークロードとやり取りするかという点かもしれません。」
Db2データ アナリティクスでは、生成AIは、トレンド分析や異常検知を行うために使用されることになります。つまり、これまではアルゴリズムでプロシージャ―的およびプログラム的に処理されてきましたが、今では生成AIモデルに分析や検知を処理させられるようになっているということです。Will氏が指摘したように、これらの生成AIモデルは、プログラミングする必要なく、データの異常を検知するようにトレーニングすることができます。本質的には、LLMは、過去のデータに基づいて、パターンを認識し、新しいものが出現したらそれらを確認するようにニューラル ネットワークをコーディングします。アルゴリズムまたはアルゴリズムのセットにそうしたパターン検索をコーディングさせる必要はありません。顧客が本当に求めているのは、トランザクショナル データにおかしなところがあるかどうかを発生時に確認できるようになることです。
ちなみに、これは、生成AIがIBM i プラットフォームにどのように役立つ可能性があるかについて意見を求められたときに、アプリケーション開発者が一番要望したことでした。これは、コーディング アシスタントよりも、リストの上位にありました。
生成AIがこのプラットフォームにどのように役立つ可能性があるかについてIBMが尋ねたときに、ユーザーが次に重要視したことは、IBM i プラットフォームの管理のオートメーションでした。特に、自力で、またはIBM i キャパシティをレンタルしている顧客に代わって数多くのマシンを管理している担当者にとっては重要でした。よくご存じのように、AS/400およびその後継機は、自己チューニングおよび自己管理で有名ですが、マシンの稼働環境の改善のために行う必要がある作業は常にあるため、AIが果たす役割としては、人力で行う必要がないように、IBM i プラットフォームが自身を管理する機能を強化することになります。
もちろん、IBMは、兄貴分のメインフレーム上ではCOBOLコードをJavaに移植する支援を行っているのとは異なり、RPGコードをJavaに移植するためにコーディング アシスタントを開発しているわけではないことはお気付きでしょう。System zチームは同様の方針を採り、COBOLのショップがCOBOLアプリケーションをより適切に拡張し、モダナイズする手助けになったのかもしれません。それゆえ、System zメインフレーム向けのニーズを維持するのに役立っているのかもしれません。しかし、COBOLからJavaへ移植するツールは、顧客がIBMに要望したことであるようにも思われます。
IBMは、組立ラインや倉庫の作業員に取って代わる生成AIモジュールを開発していませんし、顧客サポートや営業の担当者に取って代わるシステムを構築してもいません。IBMは、そのいずれも行っていません。
IBM i のショップがそのようなことに関心がないと言っているわけではありません。おそらく、関心はあるのでしょう。しかし、IBMおよびIBM i ユーザーは、サードパーティ ソフトウェア開発者がそのようなものを提案するのを待つことになるのだと思います。市場における何らかの競争優位性およびコスト優位性を得るために、そのような生成AIシステムをゼロから構築するIBM i のショップもあるかもしれません。もちろん、そのような取り組みには、GPUアクセラレーテッド ハードウェアへの莫大な投資や、生成AIモデルの専門知識が必要となるでしょう。だとすると、そのことは、IBM i のショップがそのような取り組みのための予算を集めることはできないことを意味するのかもしれません。Will氏が示したユース ケースを除けば、生成AIは、プレイヤーのほとんどがハイパースケーラーやクラウド ビルダー、そしてNvidia社、というビジネスになってしまうのかもしれません。
