メインフレーム運用はどう進化すべきか　～標準化・自動化・可視化を軸にした新しい運用モデルの構築に向けて

Text＝髙﨑 和貴（日本IBM）、清水 友明（日本IBM）、澤田 遼太郎（日本アイ・ビー・エム システムズ・エンジニアリング）、松本 啓太（日本IBM）、三上 鉉人（日本IBM）

メインフレームは長年にわたり高い互換性と安定性を提供し、企業の基幹業務を支えてきた。

しかしその強みである安定性は、同時に課題も生み出している。テクノロジーの進化に伴い、システムのサイロ化や運用の属人化が顕在化し、次世代に向けた運用モデルの再考が求められている。

本稿では、複数企業へのヒアリングを通じて得た知見をもとに、今後メインフレーム運用がどのように進化すべきかを整理する。

メインフレーム運用の現状と改善策

ヒアリングと分析の枠組み　

まず我々はメインフレーム運用の現状を把握するために、複数の企業の運用担当者にヒアリングを実施した。ヒアリング項目については、IPAの公開情報やITILの運用管理プロセスを参照し、可用性、性能、構成、変更管理、バックアップ、監視など主要領域を網羅的に確認した。

これにより、企業ごとの運用状況を同一フレームワークで把握し、ヒアリング結果を偏りなく整理することを目的とした。

現状の課題
事後対応・手作業・分断　

ヒアリング結果から明らかになった主な点について、以下に記載する。

◎障害対応
NetViewでのメッセージ検知を起点に、発生したメッセージに応じた対応がExcel文書などでマニュアル化されており、オペレーターが実施するか、場合によっては運用担当者に電話で連絡をするケースが大半であった。

「障害が起きてから対応する」という事後対応型の運用が依然として中心であり、障害対応時のコミュニケーションプロセスも電話やメールベースが半数以上であった。

◎性能状況や構成情報の把握
手作業で作成された月次レポートでの性能把握が大半であった。変化をリアルタイムに捉えづらい構造となっている。また、構成情報の管理やジョブ運用がExcelや独自ドキュメントに依存しているため、標準化にも課題が残っている。

◎運用品質
ベテランエンジニアの暗黙知に強く依存しており、熟練者が少人数で運用を維持できてしまう構造であることも、ヒアリング全体を通じて明らかになった。これはメインフレームの強みであるものの、同時に育成や知識継承を難しくする要因ともなっている。

我々の考察
長年の強みが変革の遅れを生む

これらの課題を整理して見えてきたのは、メインフレーム運用が直面している問題の多くは、長年積み重ねられた“完成された仕組み”が変革しづらい構造を生んでいるという点である。

メインフレーム運用は長い歴史の中で成熟したプロセスを形成し、少人数でも安定稼働を実現してきた。この完成度の高さは大きな強みである反面、改善の必要性が表に出づらく、自動化・標準化・可視化の優先度を低く見せてしまう傾向がある。

一方、分散系はプラットフォームの多様性ゆえに人手だけでは運用が成立しづらく、標準化・自動化・可視化が必然的に求められてきた。メインフレームと比較すると、「時代に応じたテクノロジーを取り込みやすい土壌であった」と表現することもできる。

メインフレームの運用は、長い間変更がなくても、安定稼働を実現できたのであれば、今後も今までの運用を継続すればよいのだろうか。決してそうではない。ベテランエンジニアの引退やスキル構成の変化という現状を踏まえると、次世代に向けた運用モデルへの移行は必須であると考える。

そのためには、メインフレーム運用においても分散系プラットフォームと同様の発想が必要であり、属人性の排除や冗長な手作業の削減を進めなければならない。

次世代運用への方向性と
それを実現するソリューション

こうした背景を踏まえ、メインフレーム運用が今後取り組むべき方向性を次の4点に整理する。またそれを実現するソリューションについても簡潔に記載する。

❶ 事後対応から「未然防止型」運用へ移行する

現状では、性能変化や異常兆候がリアルタイムに捉えられておらず、障害が顕在化して初めて対応が始まる体制となっている。しかし、ビジネス要求の高度化と障害時の影響範囲拡大を踏まえると、発生後の対処だけではリスクを抑えきれない。

このため、システム状態を常時観測し、兆候段階で異常を把握する可観測性の思想を取り入れ、先手を打つ“未然防止型の運用文化”への転換が求められる。メインフレーム運用を未然防止型へと進化させるには、予兆検知、依存関係の可視化、リアルタイム監視を組み合わせたアプローチが不可欠である。

この実現を強力に推進する製品が、「IBM Concert for Z」である（図表1）。

IBM Concert for Zの基本機能である「Operations Management」は、メインフレーム上のSMFデータ、運用ログ、イベント情報をリアルタイムに近い状態で収集し、機械学習と組み合わせて、異常を兆候段階で検知することが可能である。

たとえば、平常稼働時のデータより学習させたCPU使用量の予測に対して、乖離が生じている状況を異常として早期に検知できる。

検知した異常はダッシュボードで管理され、メトリクスの可視化情報およびトポロジーによる影響範囲分析を活用して迅速に対応できる。このように異常を早期に検知し、分析および対応に着手することで、システム稼働に重大な影響が生じる問題を未然に防止する運用が可能となる。

上記の基本機能に加えて、IBM Concert for Zは各種運用管理ソリューションと連携した「Resiliency & Risk Management」による連続稼働やセキュリティ脅威への対策など、メインフレームの運用高度化のハブとしての機能を提供している。

❷ 統合的に運用を把握できる仕組みを整える

従来のメインフレーム運用は、基盤自体の安定性の高さもあり、運用範囲が比較的閉じた構造で成立していた。しかし、現在では周辺システムとの依存関係が増大し、メインフレーム単体を見ていても全体像を把握できない状況が一般的になっている。

このため複数のシステムや運用領域を横断し、単一の視点で状況を捉え、影響範囲を評価できる仕組みを整えることが重要である。

このようなハイブリッドクラウド環境に対応した運用ソリューションとして、「IBM Instana Observability for z/OS」（以下、Instana for Z）が活用できる（図表2）。

Instana for z/OSでは、オープン系やホストにまたがってエンドツーエンドでアプリケーション・フローを観測・可視化でき、複雑な障害が発生した場合にも素早く問題の切り分けを行い、対応することが可能となる。

＜参考＞
Instana on z/OS　～分散環境とz/OSシステムを一元的に可視化する次世代の可観測性基盤

また、メインフレームでもオープン系技術の活用が進む一方で、オープン系とメインフレームでは担当者が分断されていることが多く、運用面の課題として両方のプラットフォームのスキルを持ち合わせている要員の少なさが挙げられる。

このような課題に対して、「z/OS Container Extensions」（以下、zCX）を活用できるケースもある。

zCXは、DockerコンテナーとしてパッケージされたLinux on Zアプリケーションをz/OS上でそのまま稼働させられるz/OSの機能であり、メインフレーム担当者がオープン系のアプリケーションをz/OS上で運用したり、オープン系の担当者がz/OS上で稼働するアプリケーションを開発することが可能となる。

これらのソリューションを活用することで、運用担当者がオープン系か、ホストかを意識することなく、業務を実行できる仕組みを整えられる。

❸ 属人性を排除し、スキル継承を支える仕組みをつくる

メインフレーム運用は、長年にわたりベテランエンジニアの豊富な経験や暗黙知によって支えられてきた。しかし、その暗黙知が形式知として整理されていない場合、引退や人員入れ替えの際に運用品質を維持できなくなるリスクが高い。

そのため、手順・判断基準・ナレッジを仕組み化し、誰が担当しても一定の品質で運用できる体制が必要である。特に、AIを活用して作業ガイドや判断補助を実現し、「知識を人から仕組みに移す」ことで属人性を解消することは、育成コストと品質リスクの両面を抑える有効なアプローチであると考える。

上記に課題とアプローチについて整理したが、サポートする製品として「IBM watsonx Assistant for Z」（以下、WXA4Z）がある（図表3）。

動きとしては、まずOrchestratorがチャットツールで依頼を受け取り、LLMと連携して内容を判断し、適切なAgentに処理を振り分け、結果を返す。必要に応じて、zRAGのデータベースにも問い合わせる。

これによりAIを活用したメインフレーム操作と運用管理の簡素化が可能となる。WXA4Zは従来の生成AIチャットによるアシスタント機能だけでなく、メインフレーム用のAIエージェントの構築、管理、デプロイ、拡張が可能になっており、より迅速に次世代運用を実現できる。

❹ 構成管理を標準化し、再現性を確保する

次世代の運用を見据えるうえで、メインフレームにもIaC（Infrastructure as Code）の概念を取り入れる意義は大きい。

従来、メインフレームのリソース定義やI/O定義、ジョブ実行等の運用作業は手作業や個別ドキュメントに依存しがちであり、変更内容の追跡や環境の再現性に課題が残っていた。

IaCによって構成情報をコードとして管理することで、変更履歴の可視化、レビューによる品質担保、環境差異の排除が可能となり、属人性の軽減と運用品質の向上を同時に実現できる。

またCI/CDと連携することで、構成変更の自動適用や検証が行えるようになり、分散系と一貫した“モダンな運用プロセス”をメインフレームにも拡張できる。

こうしたIaCの考え方をメインフレームで実装する具体的な手段として、「IBM Terraform Self-Managed for Z and LinuxONE」（以下、Terraform for Z。図表4）と、「Red Hat Ansible Automation Platform for IBM z/OS」（以下、Ansible for Z。図表5）というソリューションが存在する。

Terraform for ZはICIC（IBM Cloud Infrastructure Center）やHMCと連携し、z/OSやVM、仮想テスト環境のリソース定義、I/O定義をコードで記述できるようにする。

一方、Ansible for Zはプレイブックに基づき、データセット作成、JCL配備、パラメータ変更などを自動化し、日々の運用作業を安定した形で繰り返し実行できる。

両者は役割こそ異なるものの、いずれも“構成をコードとして宣言する”というIaCの思想をメインフレームにもたらすものであり、標準化・自動化・再現性という次世代運用の基盤を支える重要な技術である。

今後の展望　

メインフレーム運用の進化は、運用プロセス全体を再設計し、標準化・自動化・可視化を軸にした新しい運用モデルを構築することである。その上で、企業間やコミュニティで知見を共有し合うことで、運用モデルの成熟度向上を加速させることができる。

メインフレームは今後も企業の重要な基盤であり、運用モデルの進化こそが、その価値を次世代へつなぐ要となると我々は信じている。