IBM iを使用する企業の間では、2010年代から既存システムのモダナイゼーションを課題とする企業が増え、現在に至るまで幅広い取り組みが続いています。
IBM iシステムをモダナイズする際に、まず欠かせないのが、現在稼働しているRPGやCOBOLプログラムの内容を正確に把握し、分析することです。どのシステムを、どのような方法でモダナイズするのかを判断するには、既存資産の構造や影響範囲を把握しておく必要があります。
しかし実際には、この作業は容易ではありません。
長年利用されてきたシステムでは、仕様書などのドキュメントが残っていなかったり、実際のシステムと内容が一致していなかったりするケースがあります。さらに、開発当時の担当者がすでに不在となり、システムがブラックボックス化していることも珍しくありません。
こうした課題に対して、従来から利用されてきたのが、当社の開発・保守支援ツール「SS/TOOL-ADV（以下、SS/TOOL）」です。
IBM iの既存資産を可視化するSS/TOOL
SS/TOOLは、IBM iのシステム稼働環境にある実行オブジェクトやソースを解析し、アプリケーション構成情報の分析、プログラム解析、プログラム修正時の影響範囲の特定、データベース解析などを行うツールです。
実際の稼働環境をもとに分析するため、現在のシステムの状態に即した情報を確認できます。また、IBM i上で稼働するため別サーバーを必要とせず、アプリケーションと同一プラットフォーム上で分析結果を照会できます。また解析結果は、スプールファイル、Excel、データファイル、PDFなど、用途に応じた形式で出力することができます。
SS/TOOLは1995年に当社が自社開発した製品で、30年以上にわたり、お客様が運用中のIBM iシステムの保守・改修をご支援してきました。
IBM Bobがあれば、SS/TOOLは不要になるのか
そうした中で登場したのがIBM Bobです。
IBM Bobは、自然言語で指示するだけで、プログラムの内容を読み解き、説明や分析を行えます。
たとえば「このプログラムがどのような処理をしているのか説明してほしい」と質問すれば、対象となるソースを読み込み、人が理解しやすい形で説明してくれます。初めて見るプログラムの内容を理解したり、仕様を確認したりする場面では、非常に有効な手段です。
そのIBM Bobについて、お客様から「既存コードを理解して説明できるのであれば、SS/TOOLのような解析ツールは必要なのか」「IBM BobとSS/TOOLはどう使い分けるのか」といった質問が寄せられるようになりました。
そこで当社では、IBM BobとSS/TOOLの関係や、両者を組み合わせた場合の効果について検証しました。
IBM Bobを含めた生成AIツールを使ってプログラムの調査・解析を行うとき、生成AIが強力な武器になることも、不足する場合があることも認識していたからです。
IBM Bob単体で約800本のプログラムを調査
まず、IBM Bob単体で既存システムを調査しました。
検証では、IBM BobからIBM i上のソースへアクセスできるMCPサーバーを当社で用意し、「銀行マスターの銀行コードを使用しているプログラムを洗い出し、それぞれの難易度と工数、銀行コードを拡張する際の注意点を提示する」という調査を行いました。
IBM Bobは自然言語による指示を受けると、対象となるソースを読み込みながら調査を進めます。
その結果、対象となるプログラムだけでなく、それぞれの難易度や想定工数、修正時の注意点まで提示されました。
約800本規模のプログラムを対象とした今回の検証では、IBM Bob単体でも、消費コイン5.49、回答時間17分04秒で調査することができました。
自然言語で依頼するだけで、これだけの調査ができることは生成AIの大きなメリットです。
しかし、ここで１つ課題があります。
IBM Bobがソースを直接調査する場合、対象となるソースを１つずつ読み込み、内容を判断していく必要があります。対象が増えれば、その分だけ読み込む情報量も増加します。
今回の約800本という規模は、実際のお客様環境から見れば比較的小規模なケースです。IBM iのユーザー企業では数千本、多い場合には数万本のプログラム資産を保有しているケースもあります。
システムの規模が大きくなるほど、すべてのソースを直接読み込ませる方法では、回答までの時間や生成AIの利用コストが増える可能性があります。
そこで着目するのが、SS/TOOLがあらかじめ蓄積している「構造化データ」です。
SS/TOOLの構造化データをIBM Bobから利用する
SS/TOOLでは、最初に分析処理を実行することで、使用箇所や呼び出し関係など、IBM iのアプリケーション資産に関する情報をデータベースとして構造化して保持します。
通常は、この情報を利用して影響調査を行ったり、各種ドキュメントを出力したりします。
今回の検証では、この構造化された情報をIBM Bobから利用できるようにしました。
IBM BobはMCPクライアントとして自然言語による指示を受け取り、MCPサーバーを介してSS/TOOLの情報にアクセスします。
つまり、IBM Bobが大量のソースを一つひとつ最初から読み解くのではなく、SS/TOOLによってあらかじめ整理された構造化データを検索し、必要な情報を取得する仕組みです。
この違いが、調査時間とコイン消費に大きな差を生みました。
回答時間とコイン消費を約5分の1に削減
IBM Bob単体と、IBM Bob＋SS/TOOLで同じ内容の調査を行い、結果を比較しました。
IBM Bob単体では、消費コインが5.49、回答時間が17分04秒でした。
一方、SS/TOOLと組み合わせた場合は、消費コインが1.10、回答時間が3分26秒となりました。
つまり、コイン消費、回答時間ともに約5分の1になりました。
しかも、必要なプログラムの検出結果は両者で一致しています。検証では31本の対象プログラムを双方が検出しました。
一方、ソースを直接参照したIBM Bob単体では、バックアップなどとして残されていた未使用ソースも含めて35件が候補となりました。この場合、実際に使用されているプログラムかどうかを、人が確認して除外する作業も必要になります。
今回の検証から見えてきたのは、生成AIそのものの能力の違いではありません。
ポイントは、生成AIにどのような情報を渡すかです。
SS/TOOLが持つ構造化データを利用することで、IBM Bobが一から大量のソースを読み込む必要がなくなります。その結果、生成AIの柔軟な分析能力を活かしながら、調査の効率を高めることができます。
そして、この効果はシステムの規模が大きくなるほど重要になります。
今回の検証対象は約800本でしたが、実際のIBM i環境では数千本、数万本のプログラムが存在することもあります。対象が大きくなればなるほど、「すべてを生成AIに読ませる」のではなく、「構造化された情報で対象を絞り込んでから生成AIに考えさせる」というアプローチが有効になります。
利用コストにも差が生まれる
回答時間だけでなく、IBM Bobの利用コストにも差が生まれます。
今回の試算では、IBM BobのPro+プラン（月額60ドル・160コイン）を基準とし、1ドル＝163円として計算しています。
IBM Bob単体の5.49コインは1回あたり約336円、SS/TOOL連携の1.10コインは約67円となり、その差は1回あたり約269円です。
もちろん、これはIBM Bobのコイン消費を中心とした試算であり、SS/TOOLのライセンス費用などを含めて総合的に判断する必要があります。
また、1回あたり269円という差額は、約800本規模の今回の検証を前提としたものです。実際の環境が数千本、数万本へと大きくなれば、ソースを直接読み込む量も増えるため、構造化データを利用するメリットがさらに大きくなる可能性があります。
そのため、単純な1回の金額だけではなく、調査の頻度、対象となるシステムの規模、回答までに要する時間、調査後の人による確認作業なども含めて評価することが重要です。
IBM BobとSS/TOOLは「どちらか」ではなく「使い分ける」
今回の検証で得られた結論は、IBM BobとSS/TOOLのどちらか一方を選ぶということではありません。
それぞれの強みを活かして使い分けることが重要です。
たとえば、特定フィールドの使用箇所やプログラム間の呼び出し関係など、システム全体を対象に漏れなく影響範囲を調べたい場合には、SS/TOOLの構造化データをIBM Bobから利用する方法が適しています。
一方、「このソースは何をしているのか」「この処理をどのように修正すればよいのか」といった個別プログラムの仕様の解釈や修正方法の検討では、生成AIであるIBM Bobの柔軟な対話能力が力を発揮します。
大量のプログラムを調査する場合には、まずSS/TOOLで対象を絞り込み、その後IBM Bobに詳細を分析させるという方法も考えられます。
また、SS/TOOLで得られた調査結果をIBM Bobで要約・整理し、ドキュメントや報告資料へ展開するといった利用方法もあります。
生成AIと既存ツールは対立するものではない
生成AIの登場によって、IBM iの開発・保守のあり方も変わり始めています。
自然言語による質問から、既存プログラムの内容を理解し、分析や提案まで行えることは、これまでにない大きな可能性をもっています。
一方、大規模なIBM iシステムには、長年蓄積されてきた膨大なプログラム資産があります。そのすべてを毎回一から生成AIに読み込ませることが、必ずしも最も効率的な方法とは限りません。
今回の検証では、SS/TOOLによって既存資産を構造化し、その情報をIBM Bobから利用することで、調査精度を維持しながら、コイン消費と回答時間を約5分の1に削減できました。
つまり、IBM BobとSS/TOOLは競合するものではなく、互いの強みを補完し合う関係と考えることができます。
SS/TOOLが既存システムの「事実」を速く、正確に整理し、IBM Bobがその情報をもとに、人が理解しやすい形で解釈・分析・提案する。
「構造化された既存資産」と「生成AIの柔軟性」を組み合わせることが、IBM iにおけるこれからのシステム調査・分析の一つの有効なアプローチになると考えています。
まとめ
IBM iのモダナイゼーションを進めるには、既存システムを正しく理解することが欠かせません。
生成AIは、その作業を大きく変える可能性をもつ技術です。しかし、大規模な既存資産の調査では、生成AIだけですべてを処理するのではなく、SS/TOOLのような既存の解析ツールが持つ構造化データを組み合わせることで、より効率的な活用が可能になります。
IBM Bobか、SS/TOOLか－－これは、二者択一ではなく、「何を調べるのか」に応じて両者を使い分け、組み合わせる。それが、生成AIをIBM iの実務で有効活用するためのポイントです。
