IBM Bob Premium Package for Z (Bob PP4Z) は、特化した IBM Z の専門知識を Bob に直接組み込みます。PP4Z は Bob のエージェント基盤の上に構築されたプレミアム機能であり、メインフレームチームがより幅広い開発作業をこなせるよう設計されています。
PP4Z は、エンタープライズ・メインフレーム開発の現実に合わせて設計されています。大規模アプリケーション、密結合システム、難解な変数名、長年にわたるビジネスロジック、そして安全かつ一貫した深いアーキテクチャ意識を持って実施しなければならないモダナイゼーション作業などが対象です。
この記事では、大規模なメインフレーム環境において汎用 AI コーディングツールが限界に突き当たる理由を説明します。構造化メタデータとデータ辞書が単なるソース検索を超えて何をもたらすのか、モデル拡張が IBM の承認済みドキュメントに基づいて回答をどのように根拠付けるのか、そして PP4Z が Bob のモデル駆動型推論と決定論的な IBM Z 分析・検証ツールをどのように組み合わせるのかを取り上げます。
IBM Z 開発のためのプレミアム体験
現代の IBM Z 開発は、新しいコードを書くだけでなく、既存アプリケーションの理解、変更が大規模システムにどう波及するかの追跡、数十年分のビジネスロジックのドキュメント化、安全かつ正当化できるモダナイゼーション意思決定など、幅広い活動を包含しています。
PP4Z はこの幅広さを支援するよう設計されています。Bob のエージェント基盤の上に構築され、Bob の skills、サブエージェント、workflows を活用します。そして IBM Z 開発が特に必要とするものでそれらを拡張します。大規模で相互接続されたアプリケーション環境の構造化された知識、COBOL・PL/I・Assembler 向けの確定的分析ツール、メインフレームチームの働き方に合わせた Z 専用モードです。
より深いアプリケーション理解のためのローカルおよびエンタープライズメタデータ
大規模なメインフレームアプリケーションは、COBOL・PL/I・Assembler にまたがる数万の相互接続されたプログラムから構成され、バッチスケジューラにより調整され、Db2・CICS・IMS などのサブシステムと統合されていることがあります。モデルはコンテキストだけでこの環境全体を推論することはできません。質問に答える前に、どのプログラムと関係性が重要かを判断する必要があります。
これが単純なソース検索が破綻するところです。汎用 AI に、共有の日付処理ユーティリティを呼び出すすべてのプログラムを見つけるよう依頼する場合を考えてみましょう(大規模な COBOL 環境で数十のプログラムから呼ばれるような種類のルーチン)。静的テキスト検索は明示的な CALL 文を見つけますが、プログラム名が変数に格納されて実行時に解決される動的呼び出しは見落とします。同じクエリを 2 回実行すると、モデルが異なる検索戦略を選び、異なる結果を返すこともあります。回答は妥当に見えますが、信頼性がありません。
PP4Z は、AI 推論が始まる前に、アプリケーションの構造化されたクエリ可能な表現を構築することでこれに対処します。ローカルスキャナーがワークスペースから直接メタデータを生成します。これらは Z Understand コンテナーで使用されているのと同じスキャナーで、アップロード手順なしに利用できます。メタデータは、プログラムの関係性、呼び出し階層、制御フロー、データフロー、SQL 使用状況、トランザクション定義、リソース依存関係を、モデルが正確にクエリできる形式で記録します。
エンタープライズ規模の分析では、チームは PP4Z を Z Understand コンテナーに接続できます。これにより Bob は、開発者のローカルワークスペースを超えた関係性を含む、より広いアプリケーションポートフォリオ全体にわたる構造化メタデータにアクセスできます。開発者は Bob に次のような質問を投げかけられます:
- 特定のユーティリティを呼び出しているプログラムはどれか?
- 特定の SQL テーブルを読み込んでいるプログラムはどれか?
- このフィールドのサイズが変わると、何が影響を受けるか?
Bob はメタデータをクエリして関連するプログラムと関係性を特定し、より深い分析が必要な箇所では対応するソースを調査します。回答は、生のソースファイルに対する確率的検索ではなく、一貫したクエリ可能なアプリケーションデータに基づいています。

モデル拡張:IBM Z の知識ギャップを埋める
IBM Z アプリケーションコードの大部分は、プライベートなエンタープライズリポジトリに存在します。汎用モデルは、それらのシステムのソース、慣例、ビジネスコンテキストにアクセスできません。また、主流の言語やフレームワークよりも公開サンプルが少ない状況でも対応しなければなりません。
PP4Z はモデル拡張によってこれに対処します。厳選された IBM Z リファレンス資料を分析・インデックス化して Bob が利用できるようにすることで、IBM Z 言語やミドルウェアに関する回答が IBM の実際のドキュメントに根拠を置くようにします。拡張レイヤーは、IBM Z ドキュメントを、開発者が実際に尋ねる具体的な質問に活用できる形で処理します。たとえば、呼び出し規約、フィールド構造、ミドルウェアの動作のほか、こうした環境に触れる機会が限られた汎用モデルでは誤りやすく、その誤りを見抜きにくい文書化済みのエッジケースなどです。
実際の違いは、開発者が IBM Z ミドルウェアと連携するコードを書いたり修正したりするときに現れます。汎用モデルは構文的にはもっともらしくても、IBM が定めた厳密な契約に違反するコードを生成することがあります。モデル拡張により、PP4Z が回答を構成する際に参照する知識は IBM が実際に規定している内容に基づくものとなり、限られた学習データから導いた最善の推測ではありません。

データ辞書によるビジネス認識 AI
不明瞭な変数名はどのコードベースにも存在しますが、IBM Z アプリケーションでは異なる規模と形でこの問題が現れます。多くの長寿命 COBOL アプリケーションでは、ビジネスロジックとアプリケーションロジックが密接に絡み合っています。意味は簡潔なフィールド名、copybook レイアウト、および一貫した強制なしに数十年にわたって蓄積された命名規則にエンコードされています。この WORKING-STORAGE SECTION を考えてみましょう:
01 WK10.
10 WK10-QUDISP PICTURE 9(10)
VALUE ZERO.
10 WK10-QUPIL PICTURE 9(3)
VALUE ZERO.
10 WK10-QUDIS PICTURE 9(15)
VALUE ZERO.
10 WK10-QUMYD PICTURE 9(10)
VALUE ZERO.WK10 というグループに 4 つの数値アキュムレーターがあります。名前も PICTURE 句も、開発者やモデルにそれぞれが何を表しているかを教えてくれません。追加コンテキストのないモデルは、WK10-QUDISP と WK10-QUDIS がどちらも数値フィールドで、QU と DIS の断片から距離に関連している可能性があり、似た目的を果たしていると推測するかもしれません。その推測は間違いです。両者の 1 文字の違いがすべてを物語っています。
PP4Z 生成のデータ辞書では、その区別が明確です。WK10-QUDIS はすべてのパイロットの累積飛行距離合計です。フライト記録処理全体を通じてインクリメントされ、最終的な平均計算で使用されます。WK10-QUDISP はパイロットごとのアキュムレーターです。各パイロットの処理ブロックの開始時にゼロにリセットされ、そのパイロットの識別情報とともに表示されます。一方はパイロットごとにリセットされ、もう一方は決してリセットされません。これらを混同した説明や影響分析は、プログラムが何をするかについて誤った答えを出します。

PP4Z は各変数がプログラム内でどのように機能するかの静的分析を通じてこれらのエントリを生成します。分析は制御フロー、I/O 操作、計算、データ移動をカバーします。すべてのフィールドをドキュメント化しようとするのではなく、プログラムの動作に最も影響する変数、すなわち一度名付けられるとプログラムの残りを読みやすくする変数を特定します。データ辞書エントリはローカルに管理するか、Z Understand コンテナーを通じて管理でき、一括生成、レビュー、チーム間の同期をサポートします。
ドキュメント化、説明、リファクタリング
メタデータ、データ辞書、モデル拡張についての各セクションでは、PP4Z がアプリケーションの全体像をどのように構築するかを説明しています。このセクションでは、開発者がその全体像をどのように活用するかを説明します。
ドキュメント化とビジネスルール抽出は、大規模な永続的なアプリケーション知識を生み出します。チームは COBOL・PL/I・Assembler プログラムの構造化ドキュメントを生成でき、プログラムロジック、データフロー、埋め込まれたビジネスルールをカバーします。フォーカスされたスコープにはローカルスキャナーメタデータを、アプリケーション全体には Z Understand コンテナーを使用できます。ビジネスルールはそのプロセスの一部として明らかになり、技術チームとモダナイゼーションステークホルダーに、すべての段落を手動でトレースすることなく、アプリケーションが何をするかの読みやすい記録を提供します。

そのプログラムレベルのドキュメントは、アプリケーションビューにまとめることができます。アプリケーション全体にわたる図解とクロスリファレンスページを含む構造化サイトです。個々のプログラムドキュメントは 1 つのプログラムに関する質問に答えます。アプリケーションビューは、チームとモダナイゼーションステークホルダーにアプリケーション全体のマップを提供します。

包括的な説明では、その時の作業に最も適した Architect、Developer、Business のいずれかの視点から、プログラムを詳しく説明します。PP4Z は、アプリケーションメタデータ、データ辞書エントリ、モデル拡張レイヤーを活用し、プログラムの動作に根ざした説明を提供します。

リファクタリングは収集されたコンテキストを使用して、既存のコードを機能を保持しながらモジュール式で再利用可能なサービスに再構成します。Refactor COBOL or PL/I program workflow は抽出候補を特定し、その依存関係をマッピングし、変換を案内します。これにより、完全な書き直しを必要とせずに保守性を向上させる実践的なモダナイゼーションパスがチームに提供されます。


統合された開発、品質、デバッグ機能
開発者のワークフローの一部には確定的な答えがあります。コードがルールに準拠しているかどうか、特定の変数がプログラムのどのパスをたどるか、PERFORM の後に制御がどこに移るか。PP4Z はこれらを専用ツールで処理します。モデルは、開発者が達成しようとしていることのコンテキストで結果の事実を解釈します。
PP4Z カスタムモード Z Code では、Z Code Scan が COBOL および PL/I プログラムに対して高速なルールベースの静的分析を提供します。リンタースタイルのフィードバックは、確率的推論なしに問題を検出します。カスタムモード Z Architecture は制御フローとデータフローの分析を提供し、実行がプログラムをどのように進むか、データが段落と copybook の間を流れるときにどのように変換されるかを含みます。これらのツールは、質問の表現に関係なく、一貫した再現可能な結果を生み出します。

モデルはそれらのツールの出力を扱います。提案された変更のコンテキストでスキャン結果を解釈したり、プログラム動作に関する特定の質問に答えるためにデータフローをトレースしたりできます。確定的分析はルールに縛られたものを処理し、AI は判断が必要なものを処理します。
PP4Z には IBM Debug for z/OS とコードカバレッジ機能も含まれており、チームは同じ環境内で AI 支援開発から実行レベルの検証へ直接移行できます。
エンタープライズ固有の知識のための Skill Builder
アプリケーションメタデータ、データ辞書、モデル拡張、決定論的な分析は、PP4Z が提供する IBM Z の基盤を形成しています。Skill Builder は、組織がその上に自社の知識を積み重ねる方法です。
Skill Builder を使用すると、チームはコーディング標準、命名規則、技術パターン、ビジネス用語、環境固有のガイダンスなど、エンタープライズ固有の知識を取得して適用するカスタム skills を作成できます。これらの skills は、特定の組織内で開発がどのように行われているかを Bob が理解し、汎用的な仮定を減らし、AI 生成の回答の関連性を向上させるのに役立ちます。Skills はユーザーのリクエストとコードコンテキストに関連するときに自動的に取り込まれ動的に呼び出され、既存の PP4Z workflows に直接統合されます。

すべてをまとめて
規模、意味的密度、独自のコンテキストにより、汎用 AI ツールでのメインフレーム開発は困難になります。PP4Z は、規模に対応する構造化メタデータ、ビジネス上の意味を扱うデータ辞書、IBM Z ドキュメントを網羅するモデル拡張、ルールに従う分析を行う決定論的ツールによって、それぞれの要素に直接対処します。
このアプローチでは、AI 推論と確定的知識が互いを強化します。Bob は構造化メタデータから始め、厳選されたドキュメントを活用し、ルールベースのツールの出力を解釈します。開発者はミッションクリティカルな環境で回答に基づいて行動する前に、その証拠を検査できます。
始めるには、チームが避けてきたプログラム、おそらくその目的が不明確だったり、ビジネスロジックが何年も触れられていないものを 1 つ選びましょう。ローカルスキャナーを実行してメタデータを構築し、主要変数のデータ辞書を生成します。explain workflow を使用してプログラムが何をするかを理解し、次にドキュメント化 workflow を実行してその知識をワークスペースに記録します。そこから同じ基盤が影響分析、リファクタリング、品質検証をサポートします。チームは今や理解しているプログラムから始められます。
