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

2026年5月28日　リック・ハークス

AI導入を計画中の多くの企業と話をした結果、あることに気づきました。実は、多くの企業が間違った切り口からプロセスを始めています。どういうことかと言うと、「顧客チャットボットが欲しい」「AIが生成するレポートが欲しい」「承認キューを自動化したい」といった要望からプロセスを始めているのです。そして、それらの要望は既に誰かが構築中の3つか4つのユースケースと同じなのです。

しかし、異なる視点から始めれば、多くの可能性が待っています。もっと良い出発点があるので、何を構築したいかは、ひとまず忘れてください。代わりに、次のような単純な質問から始めます。
「現在RPGやSQLではできないことで、AIにできることは何でしょうか？」
つまり、人間の介入なしではIBM iで実現できなかったことは何かを考えましょう。

これらを「基礎」と考えてください。「RPGやSQLができないこと」で「AIが根本的にできること」を理解すれば、ユースケースは誰かから渡されるリストではなくなります。自分の職場でAIのユースケースを見つけることができるようになります。

この記事では、AIがビジネスにもたらす、これまでは不可能だった（あるいは少なくとも非常に困難だった）7つの基本的機能のうち、最初の4つについて概説します。これらの機能を理解すれば、IBM i上でAIを使って何を構築するべきかを、誰かに教わる必要は無くなります。あらゆる所でAIが活用されるようになるでしょう。

1. 入力済みの非構造化テキストの理解

エンタープライズAIの「不都合な真実」をご存知でしょうか。実は、エンタープライズAIのプロジェクトが失敗する場合、原因はAIモデルの品質ではなくデータの品質なのです。

RPGでは、物理ファイル内の定義済みフィールド、既知のレコード様式、ありきたりなレイアウトなどに対する構造化された入力が必要です。

しかし、ビジネスの過程で流入してくる情報の多くは構造化されていません。具体例を挙げると、顧客からのメール、PDF形式の注文書、20年間蓄積されてきたコメント欄の自由記述、余白に手書き文字が書かれているスキャン文書、などです。

AIは上述した全てを読み取り、意味を解釈します。ですから、たとえば、顧客が「2月以降いつもの注文に加え、このあいだの部品を50個追加で送ってください。青い箱に入っていたやつです」と書いた場合、AIは顧客を把握し、その「いつもの」注文を注文履歴の定期注文パターンと照合して「青い箱」に該当する品目の番号を確認し、顧客が期待している配送物を割り出します。

私が関わっているIBM i利用企業の大半では、Db2 for iのテーブルのコメント欄や注記欄に、何十年分ものフリーコメントのデータが誰にも検索できない状態で蓄積されています。フリーコメントのデータは構造化されていないテキストであるため、クエリーでは処理できません。このようなデータはAIによって初めて利用可能になるのです。

この基本機能を活用して実現したユースケース例
• 顧客がPDF形式の注文書を添付したメールを送信します。AIがそのメールを読み込み、PDFを解析し、明細項目を抽出し、商品マスターの品目番号と照合して、確認の準備が整った構造化された注文書を作成します。
• 倉庫の作業員が、余白に「3個不足、箱破損」と書かれた梱包明細書をスキャンします。AIは余白に書かれた手書きのメモの内容を読み取り、出荷ファイル内の出荷記録と紐付け、クレーム処理を開始します。
• 「過去に、解約の意思を示したことがある全ての顧客を表示しなさい」と指示すると、AIは顧客メモファイルの中から10年分のフリーコメントを検索して、該当する顧客を見つけ出します。

2. 文脈に沿った文章の書き出し

RPGやSQLは、データの取得と整形を一日中実行できます。一方、RPGやSQLにできないのは、データを理解し、データに基づいて文章を作成することです。

例えば、夜間の例外レポートで、レビューが必要な項目として47件が報告されたとします。現在は、誰かが各項目を開き、複数の画面を横断的に調査し、実際に問題があるかどうかを判断しなければなりません。このプロセスをAIが変革します。AIは各例外の背後にあるデータを読み取り、「マージンの逸脱でフラグが立てられました。これは過去3年間同じ利幅で繰り返されている特殊注文です。実際には問題ありません。」といった簡単な説明文を作成します。

あるいは、売掛金管理チームが同じ延滞通知を毎月何十通も作成しているとしましょう。AIは、顧客の売掛残高や売掛金支払い履歴に基づいて、顧客ごとに異なるメールの下書きを作成できます。顧客に応じて文面を調整することさえも可能です。

言い換えれば、AIは状況に応じて変化する臨機応変な文章作成を行います。RPGプログラムは物理ファイルからデータを取得し、名前と金額の記入欄に入力できますが、AIは状況に適した文章を作成できます。

この基本機能を活用して実現したユースケース例
• 毎晩作成される例外レポートが、「47行にフラグが立てられました」から「47行にフラグが立てられ、それぞれの行についてフラグが立てられた理由と対応が必要かどうかについて簡単な説明が付いています」に変更されます。
• 経理担当マネージャーが顧客番号を入力すると、注文履歴、売掛金履歴、サービス履歴から抽出された四半期ごとのビジネスレビュー資料（注文や利益率の傾向、サポート履歴、話し合いの論点など）を提供します。
• 売掛金管理は、顧客の支払い履歴、売掛残高、最近のサービスでのやりとりに基づいて、相手ごとにふさわしい督促メールを送信します。

3. 複数のシステムを同時に参照して判断

IBM iの利用企業では、「注文番号48291はどうなっていますか？」というような質問への回答に、15分もかかることがよくあります。

カスタマーサービス担当者が、照会プログラムで注文を表示して状況を確認すると、保留中であることが分かります。次に、担当者はクレジット照会画面に移動します。そして、在庫割り当てジョブが実行されたかどうかを確認するために画面を切り替え、配送業者の追跡ページを見るためにブラウザーを開きます。それでも解決しない場合は、顧客関係の管理システムで、顧客がすでにこの件について問い合わせているかどうかを確認します。15分後、6つの異なるインターフェースを操作した後、ようやく答えの半分が得られます。

AIは、これら全ての情報源から同時に情報を収集し、次のような一貫性のある回答を作成します。「注文番号48291は、Acme社の与信限度額を12,400ドル超過しているため、信用保留になっています。Acme社からの最終支払い日は52日前で、これは同社にとって異例です。在庫は割り当て済みです。運送会社のAPIによると、出荷準備は完了状態です。推奨される対応法：売掛金管理部門に連絡して与信限度額の引き上げを検討するか、Acme社に連絡して一部支払いを行っていただき保留を解除してください。」

さて、皆さんの中には「でも、わが社のアプリケーションはすでに複数のシステムからデータを取得して1つの画面に統合しています。これと何が違うのでしょうか？」と思われる方もいらっしゃるでしょう。違いは、データが取得された後に何が起こるかです。従来の統合では、データを人間に提示し、人間がそれを解釈します。それに対して、AIはデータを取得し、解釈し、推奨事項を人間に提示します。

この基本機能を活用して実現したユースケース例
• 「注文番号48291はどうなっていますか？」という質問に対し、AIは注文ファイルを読み込み、信用調査RPGプログラムを呼び出し、在庫を照会し、運送業者のAPIを動かし、顧客履歴を取得して、推奨事項を含む1つの文章を返します。
• 「なぜ中西部地域は今月18％減少しているのですか？」という質問に対し、AIは注文、顧客、サービス、売掛金に関する各ファイルを相互参照し、売上減少の原因を3社の特定の顧客に絞り込みます。そして、それぞれの顧客について説明するとともに、実は3社を除く残りの顧客では4％増加していることを指摘します。
• 営業担当者が顧客の360度ビューを求めると、AIは6つの異なるインターフェースを操作する代わりに、顧客マスター、注文ファイル、売掛管理システム、サービスチケット、顧客関係管理システム（CRM）からのデータを合成して1つの文章を表示します。

4. 誰も想定していなかったケースに対する判断

RPGは決定されている論理処理に優れています。そして、開発者が想定したあらゆるケースが完璧に処理されます。

問題は、プログラムの作成時に誰も予想していなかったケースが発生することです。例えば、発注書が既存の承認ルールに一致しない場合はどうなるでしょうか？請求の問題、品質の課題、顧客維持リスクも伴うような顧客からの苦情はどうでしょうか？あるいは、一見正常に見える注文でありながら、プログラム中のIF文では対処できないような些細な違いが1つだけある注文の場合はどうでしょうか？

このようなケースは手作業で処理されます。通常はメールまたは報告書の形で対応部門に回され、担当者が時間的余裕のある時にチェックします。人間が1つ1つの注文を調査し、判断を下して処置の方法を決定します。

AIは、こうした見落とされがちな問題に対応します。複数の要素を比較して重み付けし、推奨事項を提示できます。
「この発注書は、ベンダーが価格体系を先月変更したため通常とは異なります。ただし、合計額は予算内に収まっています。次回の発注前に再交渉するよう、調達部門にメモを残した上で、この発注書を承認することを推奨します。」

この基本機能を活用して実現したユースケース例
• 承認プログラム内の既存の検証ルールに一致しない発注書を受け取ったとき、AIはベンダーの履歴、予算状況、過去の承認状況などを考慮し、適切な担当者へ簡単な説明文を添えて転送します。
• 受け取った苦情は、請求に関する問題、品質に関する問題、顧客維持リスクといった複数の要素を含んでいます。AIはメールを読み取り、顧客の支払い残高、品質ログ、顧客の活動履歴を照合して、どのチームが対処するべきかを判断し、適切に振り分けます。
• 過去に発生したことがない品目と顧客の組み合わせによる注文は、通常の処理から外されます。AIは注文履歴、顧客プロファイル、品目データを評価し、自動承認しても安全か、人間の判断が必要か、あるいはまず顧客への確認が必要かを判断します。

次回予告

こまで述べてきた4つの機能だけでも、既存のIBM i環境で可能なことを大きく変えます。後編では、さらに次の3つの機能について説明する予定です。

• フォーマットごとにパーサーを作成せずに、フォーマット間で変換を行う方法
• チーム内の誰も理解できなくなったレガシーコードを解読し説明する方法
• IBM iのデータと真の対話を行う方法