はじめに

ここまでの記事は、VS CodeのExtensionを使用してz/OSと直接連携してどのようなことができるのか、ということを見てきました。
当記事では少し観点を変えて、VS Codeをメインフレーム・モダナイゼーションの一つの入口としてみた時に、AIエージェントがどのように関係してくるかについて考えていきたいと思います。

関連記事

VS Code - z/OS連携 (1)概要
VS Code - z/OS連携 (2)基本構成
VS Code - z/OS連携 (3)基本操作: ソース編集
VS Code - z/OS連携 (4)基本操作: JES操作など
VS Code - z/OS連携 (5)DBBユーザー・ビルド
VS Code - z/OS連携 (6)Advanced Capability
VS Code - z/OS連携 (7)AIエージェントの活用: 概要
VS Code - z/OS連携 (8)AIエージェントの活用: 実践編

IT変革のためのAIエージェント活用

生成AIを中心とした技術革新は著しく、その活用はさまざまな業務領域へ急速に広がっています。これはITシステムの開発・運用の現場も例外ではありません。特にアプリケーション開発の現場では、GitHub Copilot、Claude Code、Cline、IBM Bob などに代表される、エージェント型の開発支援ツールへの関心が高まっています。
これらの支援ツールは、チャット形式でのQA対応 → Vibeコーディング(自然言語による直感的なコーディング) → 仕様駆動開発 というように、適用の範囲を広げる方向で進化を続けています。単に"アプリケーション開発支援ツール"の枠を超えて、様々な場面での活用が検討されています。

関連技術の整理

ここで、一般論としてこれらの支援ツールのベースとなっている重要な技術について整理しておきます。

AIエージェント

AIエージェントとは、簡単に言うと、与えられた目標に対して自律的に行動を決定し外部ツールを活用しながらタスクを遂行するシステム、と言えます。
単なるQA対応を超えて、

• 計画を立て、
• 状態を保持し、
• 実行結果に応じて柔軟に行動を変更できる

という特徴があります。多くの場合、計画立案や動的な意思決定には内部的に生成AI(LLM)が活用されることになります。

先に挙げたIBM BobやGitHub Copilotなどのツールは、AIエージェントをベースとした支援機能を提供しており、エージェント型開発支援ツールなどと呼ばれたりします。

MCP(Model Context Protocol)

参考: MCP - Architecture overview

AIエージェントの利用が想定されるシチュエーションとしては、より複雑なタスクを柔軟に処理することが求められるため、AIエージェントそれ単体で処理を完結させることは難しいことが多いです。すなわち、外部の環境を観察したり、外部システムの連携を行うということが必要になってきます。

そこで、AIエージェントが外部システムと連携するための作法を標準化しましょうということで、Anthropic社がMCP(Model Context Protocol)という標準プロトコルを提唱しています。

MCPイメージ:

MCPでは主要コンポーネントとして以下の登場人物が定義されています。

• MCPホスト
• MCPクライアント
• MCPサーバー

MCPホストというのはAIを活用するアプリケーション、いわゆるAIエージェントにあたる部分です。AIエージェントと連携したいバックエンドのシステムは、MCPサーバーを立ててあげると、MCPホストからはMCPクライアントを経由して連携ができます。

MCPプロトコルでは MCP Client - MCP Server 間の通信の作法を規定しています。中身はプロセス間通信、もしくは、HTTPベースの通信で、JSON-RPCというデータの通信方式を採用しています(RESTではありません！)。

その上で扱われる基本機能(Primitives)としては3つ規定されています。

• Tools: AIアプリケーションがバックエンドシステムに対して何らかのアクションを行うための機能を提供
• Resources: ファイルの中身やデータベースのレスポンスなど、コンテキストそのもの
• Prompts: LLMが利用できるプロンプトのテンプレートをやり取りするもの

アプリケーション同士の連携においては、Web API(REST/JSON)という標準化されたインターフェースが広く採用されています。それと同様に、MCPという標準プロトコル経由で関連システムにアクセスできるかどうか ということが、AIエージェントを活用する上では非常に重要な要素になってきます。

メインフレーム・エリアでのエージェント型開発支援ツールの活用

オープン環境 - メインフレーム環境間のギャップ

GitHub CopilotやClaude Codeなど、エージェント型開発支援ツールとして使われているツールは、基本的にはオープン系システムの環境をベースに作られているものと思います。
従って、それらを旧来からの使われ方をしている"メインフレーム"のエリアに適用しようとすると、なかなか難しい場合があります。

主に以下の観点でギャップがあると考えています。

(1) 基盤モデル特性

AIエージェントや生成AIのベースとなっている基盤モデル(LLMなど)は、大量のデータを学習させることでその性能を向上させています。

メインフレームの世界は以下のような環境にあると考えています。

• インターネットやオープンソースの登場以前から使われている
• ミッション・クリティカルな業務で使われておりセキュリティ・レベルの高い環境で使用される
• オープンなコミュニティが限られている

このような環境であるが故に、現在世の中に出回っている基盤モデルではメインフレーム関連の学習データは、オープン系システム関連の学習データに比べてだいぶ少ないであろうと推察されます。
(例えば言語で言えば、COBOL, PL/I, Assembler, JCL, REXXなど、インフラ関連で言えば、z/OS, IMS/CICS/Db2など、これらのメインフレーム関連の情報がどこまで学習データとして含まれているか...)

また、メインフレームのアプリケーションは1つのソース・コードのサイズが非常に大きかったり、関連するソースの数が膨大になることも多いです。現在のLLMでは一度に扱えるコンテキストのサイズ(トークン数)の上限がそれほど大きくはないため、そのような大量データを扱う際には何らかの工夫が必要になるかもしれません。

ただ、基盤モデルは日進月歩で進化し続けており、メインフレーム関連の対応についても相当改善されてきていることは日々実感しています。トークン数上限の改善、AIエージェントなど周辺の技術革新、ノウハウの蓄積なども含めて、この辺りの課題は時間が解決してくれそうな気もします。

※IBMさんはEnterprise COBOL(z/OSのCOBOLコンパイラ)を重点的に学習させたLLMを作ったりもしています。

(2) オペレーション環境

オープン系のシステムと、メインフレームのシステムではオペレーション環境が大きく異なります。例えば、ざっとあげてみると以下のような違いがあります。

観点	オープン系システム	メインフレームシステム(旧来型)
文化	Open な技術共有・コミュニティ活用・迅速な変更が多い	Closed / 統制重視。標準手順、変更管理、安定運用を重視。現行踏襲の傾向。
ネットワーク	接続性重視 (インターネット接続も容易)	セキュリティ重視 (直接的なインターネット接続は不可)
ファイルシステム	OSの階層型ファイルシステムを使用（ディレクトリ/パスで管理）	データセット中心で管理（PS, PDS, PDSE など）
文字コード	UTF-8、Shift-JIS、EUC、ASCII系が中心	EBCDIC 中心
基本オペレーション	シェルコマンド、シェルスクリプト、バッチ、PowerShell などで操作	MVSコマンド、TSOコマンド、REXX、JCL によるジョブ実行などで操作
UI	GUI、CUI、IDE、Webコンソールなど多様	3270エミュレーター(ISPF, SDSF)
ソース管理	Gitなどを活用するのが一般的	z/OS内で管理(PDSメンバーや専用ツールによる手動・集中管理)
テスト環境払い出し	容易 (クラウド、コンテナ等の利用)	困難 (共有利用)
変更の進め方	アジャイル、継続的デリバリー、頻繁な更新と親和性が高い	事前検証・承認・本番統制を重視。変更は慎重に実施される傾向
得意分野	Web、クラウド、分散処理、API連携、フロント開発	大量トランザクション、高信頼性、高可用性、基幹業務処理

大抵のエージェント型支援ツールは上のようなオープン系システムの特性をベースに作られていると思います。

例えばアプリ開発に関して言えば、ソースはGitで管理されている前提で、まずローカルにソースをCloneしてローカルのファイルシステム上のファイルを操作します。ドキュメントはMarkdown形式で扱われて、不足する情報はWeb上から探索し、少し複雑な操作を行うのであれば、OSのシェルコマンド(bashやPowerShell)やPython, Javaなどのプログラムを作って処理を行ったります。
このような、PC上で一般的に行う簡単な操作は、エージェントからも容易に行えるようになっています。

メインフレーム関連のオペレーションが難しいのは、PCだけで完結しないことと、z/OSに接続して操作するオペレーションはオープン系と根本的に考え方が異なるということが、大きな要因として挙げられると思います。

ギャップを埋めるためのモダナイゼーション

上のようなギャップがあるため、エージェント型支援ツールをメインフレームのエリアに適用してそのメリットをフルに発揮するというのはちょっと難しいように思います。

ただし、それはあくまでも旧来型のメインフレームの管理を行っている場合、ということです。メインフレーム自体もバージョンアップを繰り返すたびに新しい技術を取り入れて進化をしており、使い方の幅も広がっています。それを"モダナイゼーション"と呼んだりしていますが、その代表的なものが今回のシリーズ記事で紹介してきたVS Code連携に他なりません。

これまで紹介してきた通り、Zowe Explorer、Z Open EditorはVS Codeからz/OS関連リソースを取り扱うための機能を提供していますし、特に重要なのは、これらのオペレーションをAIエージェントからMCP経由で実行できるようにしている点です(Advanced CapabilityのAgent Mode)。

VS CodeをUIとして使用し、z/OS上のリソースも扱えるようにしておく、ソースコードなどのリソースはGitで管理しておくなど、オープン系と同じような技術を使用できるようにしておくことで、エージェント型支援ツールの恩恵を受けやすくなると考えています。

まとめ

上に示したように、メインフレーム・エリアでAIエージェントを活用をするためには、ある程度モダナイゼーションを行う必要があり、そのうちの1つがVS Code連携である、と考えています。

新しい技術は別の新しい技術のベースになっていくので、継続的にモダナイゼーションをしていくことが必要である というのは別の記事でも主張していることです。
参考: メインフレーム担当者の必須スキルを再考する

一足飛びにいきなり「AI活用したい！」と言っても難しいため、その前にUIや接続性や考え方をモダナイズして、新しい技術を適用するための下地を整えておく必要がありますよ、ということです。

ちなみにモダナイゼーション(オープン系技術利用)の観点はたくさんあり、UIというのはそのうちの一つであると思います。

• UIのモダナイゼーション例:
  • VS Codeの活用
• ソースコード管理の例:
  • Gitの活用
• CI/CD適用例:
  • Jenkinsの活用
• インフラ構成の自動化例:
  • Ansibleの活用
  • Terraformの活用
• 柔軟な開発/テスト環境構築の例:
  • クラウド上での仮想z/OS環境利用
• 既存アプリケーションのAPI連携例:
  • API Connect, z/OS ConnectによるAPI公開
• などなど..

メインフレームのシステムであっても、例えばGitでリソースの管理ができていればAIエージェントから扱いやすいですし、Ansibleでの管理が行えるようになっていればPlaybookの作成/変更にAIエージェントが活用しやすいよね、という話です。

過去にモダナイゼーション関連記事を色々と書いていますのでご参考まで。
参考:
z/OSにおけるGitの活用
Jenkins - z/OS連携
Ansibleを用いたz/OSカスタマイズ自動化
クラウド上でのメインフレーム開発環境構築
API Connect関連メモ

一方で、モダナイズしていくにあたっては先に挙げたようなオープン系とメインフレームの違いに起因する向き合うべき課題も色々と出てきます。例えば、メインフレーム開発環境のモダナイゼーションを行う場合の課題については以下の記事も公開していますので参考にしていただければと思います。
参考:
メインフレーム開発環境モダナイゼーションにおける課題