IBM i 向けの基本的なAI機能（後編）

2026年6月10日　リック・ハークス

IBM i上のAIについて考える最も良い方法は、構築したいユースケースから始めることではないと前編で述べました。次のような、もっと単純な質問から始めましょう。
「現在RPGやSQLではできないことで、AIであればできることは何ですか？」

このような基本的な機能の名前を列挙できるようになれば、他社が構築しているようないくつかのユースケースを追い求めることを止め、自社の職場のいたる所でAIを使った事例を目にするようになるでしょう。

この2部構成の記事の前編では、最初の4つの機能、すなわち、「入力済みの非構造化テキストの理解」、「文脈に沿った文章の書き出し」、「複数のシステムを同時に参照して判断」、そして「誰も想定していなかったケースに対する判断」について解説しました。今回は、残りの3つの機能について説明します。

1. フォーマットごとのカスタム・コード無しでフォーマットを変換

従来のフォーマット変換では、フォーマット別に変換ツールを作成する必要がありました。例えば、1つは仕入れ先Aの請求書レイアウト用の解析プログラム、もう1つは仕入れ先Bの請求書レイアウト用の解析プログラム、そして3つ目はExcelファイルで注文を送ってくる顧客用の解析プログラムという具合です。新しいフォーマットが出てくるたびに、新しい解析プログラムが必要になります。

AIはフォーマットごとの専用解析プログラムを必要としません。AIは、入力データを読み込み、その構造と意図を理解し、必要な出力フォーマットにマッピングします。1つの機能で全てのフォーマットに変換できます。

このフォーマットの変換は双方向で機能します。構造化されていない入力テキストは、構造化されたDb2 for iレコードになります。逆に、構造化されたデータは、顧客向けメールになり、ステータスコードは文章になります。また、英語のサポートチケットはスペイン語の返答になります。

顧客の注文書フォーマットを注文ファイルに変換して格納するためのRPGプログラムを書いたことがあれば、その大変さはよく分かると思います。一方、AIは、フォーマットごとに作成する必要があったカスタム・コードを、1つの汎用機能で置き換えます。

この基本機能を活用して実現したユースケース例
• 仕入先からの請求書は、数十種類もの異なるレイアウトで届きます。AIは、それぞれの請求書から明細項目を抽出し、発注レコードと照合して、構造化された買掛金仕訳を作成します。仕入先ごとの個別のカスタム・コードは不要です。
• 顧客が、メールの添付ファイル、PDFファイル、スプレッドシートと、3つの異なる形式で注文を送ってきました。AIはこれら3つ全てを同じ方法で処理します。
• スペイン語でサポートチケットが届きます。AIはそれを翻訳して適切なチームに割り振り、スペイン語で返信の下書きを作成します。割り振られたチームはサポートチケットの元の言語を読む必要はありません。

2. コードとプロセスの読み書きと説明

私が関わっている多くのIBM i利用企業の環境では、15年や20年前に退職した開発者が書いたRPGプログラムが稼働しています。そのプログラムの動作を完全に理解している人はおらず、誰も手を出そうとしません。そのプログラムを開発した人が退職した時点で、長年培われてきたノウハウは失われてしまいました。残された人たちは、ただそのプログラムを実行し、うまくいくことを祈るばかりです。

AIはそのような古いコードを読み取り、プログラムの動作、ロジックに組み込まれているビジネスルール、特定のセクションを変更した場合に発生する不具合を説明できます。さらに、AIはプログラムが参照する物理ファイルと論理ファイルのDDS（データ定義仕様書）を読み取り、サービスプログラムやモジュール経由の呼び出しチェーンをトレースします。

開発者がファイル内のフィールドを変更したいとします。「このフィールドを変更すると何が壊れますか？」と彼は尋ねます。AIは、そのフィールドを参照している全てのRPGプログラム、CL、トリガー、SQLビュー、論理ファイルを読み込み、完全な影響分析を生成します。これによってどれ程の時間が節約できるでしょうか？

もちろん、これは優秀なRPG開発者を不要にするものではありません。そうではなく、これは開発者が古いRPGプログラムを読み解く代わりに、システム構築に時間を費やせるようになることを意味するのです。さらに重要なのは、古いコードの中に閉じ込められていた知識が、そのコードを書いた人以外の人からもアクセスできるようになるということです。

この基本機能を活用して実現したユースケース例
• 開発者が、10年間誰も触れていない2,000行のRPGLEメンバーを開き、「これは何をするもので、どのようなビジネスルールが含まれているのですか？」と尋ねます。すると、AIはソースコード、コピーメンバー、ファイルDDSを読み込み、平易な言葉で説明します。
• 「注文ステータスフィールドを変更すると、何が壊れますか？」と質問すると、AIは、そのフィールドを参照する全てのRPGプログラム、CL、SQLビュー、トリガー、論理ファイルをスキャンし、数日ではなく数秒で完全な影響リストを作成します。
• 新入社員が「5,000ドルを超える破損した荷物の返品ポリシーはどうなっていますか？」と質問します。すると、AIはIFSに保存されているポリシー文書を読み、具体的な条項、承認階層、例外条件を回答します。

3. コンテキストを保持して会話を続ける

従来のクエリ―では、一度に1つの質問にしか答えられません。選択条件を変更すると、クエリ―を再実行して新しい結果を取得する必要があります。その結果、全ての質問は始めからやり直しになります。

AIは会話のコンテキストを引き継ぎ、対話を行います。たとえば、「Acme社の未処理注文を表示してください」、「どれが一番大きい注文ですか？」、「なぜ保留になっているのですか？」、「これについて、どうすればいいですか？」といった具合です。4つの異なるクエリ―を実行するのではなく、1つの連続した流れとして処理されます。それぞれの会話の続きは、それ以前の会話の内容に基づいて展開されます。AIは、あなたがAcme社について話していることや、どの注文について詳細に確認したかを記憶し、そのコンテキストを継続的に保持します。

これは些細なことのように聞こえるかもしれませんが、人々がIBM iデータとやり取りする方法を変えてくれるのです。どのコマンドを実行するべきか、どの画面に移動するべきかを事前に正確に理解する必要は無く、思考を声に出しながら考えられます。漠然とした質問から始めて、学習しながら絞り込んでいけるのです。

IBM iを20年間運用してきたITディレクターにこの機能を紹介すると、ほぼ全員が同じ反応を示します。彼らはこれまで自社のデータについて考えたことが無かったような疑問を抱き始めます。なぜなら、これまで質問とそれに対する回答から成る一連のメッセージ群を追跡できるツールがなかったからです。

この基本機能を活用して実現したユースケース例
• 「60日以上滞納しているのは誰ですか？」、「それぞれいくら滞納していますか？」、「過去に滞納歴があるのは誰ですか？」、「上位3社への督促メールを作成してください」という4つの質問が1つのスレッドにまとめられ、それぞれが前の質問に基づいて展開されます。
• 「前の四半期の売上高上位10社の顧客を表示してください」、「製造業だけを表示してください」、「前の四半期と比較してください」、「上司向けに要約を作成してください」という具合に、データに精通している同僚と話すように、考えながら質問を絞り込んでいけます。
• 「今月、利益率が低下した製品はどれですか？」、「上位3つの製品に絞り込んでください」、「製品Xの何が変わりましたか？」、「コストですか、それとも価格ですか？」、「調達先の変更点を見せてください。」それぞれの質問は、コンテキストを失うことなくより深く掘り下げられます。

IBM i使用企業にとって意味すること

前回の記事で4つ、今回の記事で3つ、合計7つの機能を紹介してきましたが、これら7つの機能は、すでに皆さんがお持ちのIBM i環境の上にAIがもたらすものです。

最大のメリットは、AIが既存の全ての環境と連携して働くことです。RPGプログラムは引き続きビジネスロジックを実行し、Db2 for iファイルは引き続きデータを保持し、IBM iのセキュリティーモデルは引き続き誰が何にアクセスできるかを管理します。AIはこれら全てを取り巻くギャップ（過去30年間、人手による回避策や暗黙知によって対処されてきたギャップ）を埋めてくれます。

これら7つの機能を理解できれば、AIのユースケース一リストを、誰かから渡されるのを待つ必要はなくなります。皆さんの職場のいたる所でこれらの機能を目にするようになるでしょう。