【AI with IBM i】基本を超えて：IBM iのAIエージェント向けの高度な機能

2025年12月2日　アダム・シェディヴィ、デヴァンシュ・クマール

「IBM i向けAIエージェントの構築法」という記事で、SQLサービスをツールとしてラップし、LLMによって統合されるというコアパターンを実証する「パフォーマンス監視のAIエージェント」を構築しました。

AIエージェントは、さらに高度化できる可能性があります。

本記事では、IBM iのAIエージェントを「便利なツール」から「インテリジェント・システム」へと変貌させる4つの高度な機能について簡単に紹介します。

4つの高度な機能

メモリー機能：学習するAIエージェント

メモリー機能は、AIエージェントが「やり取り」を「情報」として保存する能力と、「情報」から過去のやり取りを想起する能力を与えます。メモリー機能を持つAIエージェントは、全ての会話を新規扱いにせず、パターンを学習し、時間の経過とともに改善していきます。

例えば、先週どのプロファイルに警告が出されたかを記憶し、どの推奨事項が実装されたかを追跡し、「CPU使用率の急上昇は毎週火曜日のバッチジョブXと相関関係にある」といった繰り返し発生するパターンに気づくセキュリティー監査のAIエージェントを想像してみてください。

時間の経過とともに、セキュリティー監査のAIエージェントは、システムの動作とセキュリティー体制に関する組織知を構築します。

ストレージ機能：コンテキストの維持

ストレージ機能は、AIエージェントが複数のやり取りにわたる会話の状態を維持することを可能にします。モデルAPIは本質的にステートレス（処理状態を把握しない）であるため、各呼び出しは独立しています。ストレージ機能は、AIエージェントをステートフル（処理状態を把握する）にし、自然なマルチターン会話（複数回のやり取りを通じてAIとユーザーが進める段階的対話型の会話）を可能にします。

複雑なデプロイを支援する変更管理のAIエージェントを例に考えてみましょう。

午前中にプロセスを開始し（「テスト環境に給与計算の更新をデプロイ」）、
昼食時に進捗状況をチェックし（「デプロイの進捗状況は？」）、
午後に結果を確認する（「エラーはありましたか？」）、としましょう。

ストレージ機能がなければ、それぞれの質問は孤立して存在します。ストレージ機能があれば、AIエージェントはワークフロー全体を通して前後関係とコンテキストを維持し、その「デプロイ」なるものが何を指しているかを記憶し、「デプロイ」の状態を追跡できます。

ナレッジ機能: ドメイン固有の専門知識

ナレッジ機能は、AIエージェントが実行時に参照できる、検索可能なドメイン固有の情報です。それは、企業や組織のドキュメント、ポリシー、履歴データなどをベクトル・データベース（非構造化データをベクトル埋め込み［数値表現］に変換して保存・管理するデータベース）に保存し、必要なときに検索できるようにAIエージェントにライブラリーを提供するものと考えてください。

ナレッジ機能を持ち本番環境をサポートするAIエージェントは、トラブル・シューティングを行う際に社内ドキュメントを検索し、類似した過去のインシデントとその解決策を呼び出し、企業や組織固有のセキュリティー・ポリシーを参照し、「組織知」とリアルタイムのシステム・データとを組み合わせられます。

その結果、AIエージェントは、一般的なIBM iのエキスパートではなく、あなたの会社のIBM i環境のエキスパートになるのです。

推論機能：アクションを起こす前に考える

推論機能は、AIエージェントが応答する前に「考え」、アクション結果の「分析」を可能にします。推論機能により、特に重要な操作における信頼性と品質が劇的に向上します。

推論機能を持つデータベース保守のAIエージェントは、単にコマンドを実行するだけではありません。最初に本番環境への影響を検討し、タイミングとリソース使用量を考慮して、操作が意図した効果をもたらしたかどうかを分析します。

「受注表の最適化」とAIエージェントに指示すると、営業時間中はアクセスが集中する表であることをAIエージェントが認識し、適切な時間帯に保守作業をスケジュールするように推奨するかもしれません。

今後の展望

これら４つの機能（メモリー機能、ストレージ機能、ナレッジ機能、推論機能）を組み合わせることで、「自動化」というよりも環境を理解している「経験豊富な同僚」のようなAIエージェントを構築できます。これら4つの機能を全て備えたAIエージェントは、過去のインシデントのパターンを記憶し、複雑な調査全体でコンテキストを維持し、企業や組織における手順を検索し、アクションを起こす前に慎重に「考える」ことが可能です。

重要な点は、本記事で示した基本的なAIエージェントのパターンはあくまでも「出発点」にすぎない、ということです。ツールやIBM iサービスに慣れてきたら、本記事で紹介した高度な機能を活用してAIエージェントを次のレベルに引き上げることが可能になります。

そして、AIエージェントがどれだけ高度になろうとも、IBM iサービスがAIエージェントの基盤であり続ける、ということは覚えておいてください。

AIエージェントを使用するべき場合（使用するべきではない場合）

あらゆるものに対してAIエージェントを構築し始める前に、トレードオフを理解してください。AIエージェントは、「柔軟性」と引き換えに「速度」と「コスト」を犠牲にします。AIエージェントは単純なスクリプトよりも遅く、直接的なSQLクエリーよりもコストが高く、従来の自動化よりも予測が困難です。

AIエージェントを使用するべき場合：　柔軟性と意思決定が必要な場合
曖昧な要求の解釈、予測不可能なシナリオの処理、事前に方法が定義できない情報を組み合わせるタスクなどには、AIエージェントが適しています。
AIエージェントを使用するべきではない場合：　定義が明確で、反復可能なプロセスの場合
SQLクエリー、CLプログラム、スケジュールされたジョブの方が、高速かつ低コストで、信頼性も高くなります。

最初は、正常に機能するであろうシンプルなソリューションから始めましょう。IBM iにおける多くのタスクは、SQLサービスを直接使用する簡単なスクリプトです。AIエージェントは、人間のような判断が真に価値をもたらすシナリオに割り当ててください。複雑さが正当化される段階に至れば、AIエージェント機能は後からいつでも追加できます。

重要なポイント: IBM iのエージェント型AIの優位性

エージェント型AIのアプローチに、IBM iが特に適している理由を考察してみましょう。

「IBM i向けAIエージェントの構築法」という記事で、具体例としてパフォーマンスを監視するAIエージェントを取り上げました。このAIエージェントは、システム・データを取得、分析し、平易な自然言語で応答します。そして、これらの作業に関する全てを、50行ほどのPythonコードで実現しています。

興味深い点は、AIエージェントに関するコードそのものではなく、私たちが構築する必要がなかった要素にあります。パフォーマンスを監視するAIエージェントの構築にあたり、実は、ミドルウェアもカスタムAPIも統合レイヤーも不要でした。私たちは、IBM iサービスに直接接続し、ツールとしてラップしただけなのです。

ユニバーサル・インターフェースとしてのSQL

IBM iのアーキテクチャーでは、事実上全てのシステム機能にSQLを介してアクセスできるため、AIエージェントの開発が容易になります。セキュリティー設定、パフォーマンス指標、ジョブ管理、ストレージ分析など370以上のサービスは、全てSQLによる組み込みサービスを通じてクエリー可能です。

QSYS2.SERVICES_INFOをクエリーすることで、全カタログを調べられます。以下に列挙するサービスは、事実上システム運用のほぼ全領域を網羅しています。

• セキュリティー
  ユーザー・プロファイル、権限管理、監査ログ
• パフォーマンス
  CPUメトリクス、メモリー・プール、ジョブ統計
• データベース
  オブジェクト管理、インデックス、制約、プラン・キャッシュ分析
• 作業管理
  ジョブ・キュー、サブシステム、アクティブ・ジョブ
• ストレージ
  ASP使用量、ディスク割り当て、オブジェクト・サイズ
• ジャーナル
  変更追跡、監査証跡、データベースの回復
• PTF
  フィックス管理、インストール履歴
• バックアップとリカバリー
  保管操作、復元追跡
• スプール
  出力キュー、印刷管理
• IFS
  統合ファイル・システムのナビゲーションと管理
• システムの健全性
  問題の検出、システム値、リソース監視
• メッセージ処理
  システム・メッセージ、ジョブ・ログ、アラート
• 通信
  ネットワーク接続、TCP/IP 構成
• その他

それぞれのサービスは、AIエージェントにとって潜在的なツールです。数十年前に行われたIBM iのアーキテクチャー上の決定が、現在、AIエージェントの構築をきわめて実用的にしています。

繰り返し可能なパターン

IBM i用のAIエージェントの構築は、以下の一貫したアプローチに従います。

1. 公開したい機能（セキュリティー監査、パフォーマンス監視、ジョブ管理）を特定する
2. 公開したい機能を提供するSQLサービスを特定する（QSYS2.SERVICES_INFO をクエリーして調査）
3. デモを実施したパターンを用いて、ツールとしてラップする

複雑な統合もカスタム・コネクターも不要です。必要なのは、Python関数でラップされたSQLだけです。

検索からアクションへ

本記事で取り上げた例ではデータの検索に焦点を当てましたが、同じパターンは、アクションの実行にも適用できます。

• ユーザー・プロファイルの作成と管理
• ジョブの開始と停止
• セキュリティー設定の変更
• レポートの生成と配布
• システム・アラートへの対応

それぞれのアクションは、ツールとしてラップされた別のSQL文です。AIエージェントが意思決定を担当し、SQLが実行を担当します。

実用的な活用

現在、IBM iのチームは、以下のようなAIエージェントを構築しています。

• システム管理者
  システムを監視し、問題を診断し、修正案を提示するAIエージェント
• セキュリティー・チーム
  設定を継続的に監査し、異常を警告するAIエージェント
• 運用管理者
  レポートの生成、メトリクスの追跡、アラート送信を行うAIエージェント
• 開発者
  データベースの管理、デプロイ、テストを支援するAIエージェント

IBM iのインフラストラクチャーには、数十年にわたって改良されてきた成熟したSQLサービスが存在しています。AIエージェント層は、その上に構築された新しいインターフェースにすぎません。

スターティング・ポイント

高度でマルチエージェントなシステムは、最初は必要ありません。目的を絞りこんだ単一のユースケースから始めましょう。

• アドホックな質問に答えるパフォーマンス監視AIエージェント
• 異常なプロファイル変更を警告するセキュリティー監査AIエージェント
• 害の問題解決を支援するジョブ管理AIエージェント

上述したパターンに慣れてきたら、IBM iサービスのツールを追加して機能を拡張しましょう。そして、新しいサービスを公開することで、AIエージェントの能力が増えていきます。

コミュニティーに参加する

GitHubのオープンソースリポジトリ「db2i-agents」では、 特にIBM i向けのさまざまなAIエージェントのフレームワーク、デザイン・パターン、ユースケースが紹介されています。

「db2i-agents」は、何が可能かを確認し、開発を加速するための実用的なリソースです。

長期的な視点

多くのエンタープライズ・プラットフォームは、AIエージェントがシステムにアクセスできるように、新しいAPIの構築、統合レイヤーの作成、インターフェースのドキュメント化などを大慌てで行っています。

一方、IBM iは、長年にわたる安定的かつ包括的なIBM iサービスによって、AIエージェントがアクセス可能な基盤がすでに整っています。したがって、特定のタスクにAIエージェント導入が適していると判断した場合、IBM iの場合は容易に構築できます。

IBM iサービスはシステム管理用に構築されましたが、図らずもAIエージェントにも完全に適合しているのです。