IBM i(AS/400)の初心者が、AI(Claude Code)を使ってクラウド移行検討のためにファイル容量を分析してみた話

情報システム担当として、サーバーやネットワークまわりの「何でも屋」をしていますが、ある日突然「IBM i（アイビーエムアイ）」の管理を任されることになりました。IBM iは、かつて「AS/400」という名前で知られていた、企業の基幹業務（販売管理・生産管理など）を支えるためのサーバー製品です。歴史が長く、今も現役で動いているシステムが多いのが特徴ですが、私自身はほぼ触ったことがありませんでした。

任された初日に求められたのは、いきなり本格的な運用改善ではなく、もっと手前の話でした。「クラウド移行を検討したいので、今どれくらいのデータ量が乗っているか調べてほしい」というものです。

この記事では、その第一歩であるファイル容量分析を進める過程で組んだ構成について、「なぜその構成にしたのか」を中心にまとめます。技術的な詰まりどころの詳細は別記事に譲り、ここでは全体像に絞ります。

※社内システムの実名・IPアドレス・具体的な数値などは伏せ、一部一般化して書いています。

なぜ「容量を知る」ことから始めるのか

クラウド移行の検討は、「今のシステムをそのままクラウドに持っていけるか」「どのくらいのコストになりそうか」を判断するところから始まります。そのためには、まず今どれだけのデータが、どのライブラリ（IBM iにおけるデータやプログラムの保管単位。Windowsで言うフォルダに近いものです）に入っているかを正確に把握する必要があります。

ここが曖昧なまま話を進めると、見積もりの前提そのものが崩れてしまいます。なので最初のタスクとして、全ライブラリの容量を洗い出す分析ツールを作ることになりました。

全体構成

初心者がいきなりIBM i本体をあれこれいじるのは怖かったので、間に1台Linuxサーバー（Ubuntu）を挟む構成にしました。

Windows端末からIBM iに直接つなぐのではなく、いったんUbuntuサーバーを経由してIBM iにアクセスする、という構成です。

なぜIBM iに直接つながず、Ubuntuサーバーを1台挟んだのか

初心者なりに、次のような理由でこの構成を選びました。

1. 分析に使いたい道具が、IBM i本体では自由に使えない

容量分析には、Pythonや各種ライブラリ、後述するClaude Codeのような開発ツールが必要でした。しかしIBM iは基幹業務が動く本番機であり、検証目的とはいえ本体にあれこれパッケージを追加でインストールするのは避けたいところです。Ubuntuを別に用意すれば、本番機に手を加えずに好きなだけ試行錯誤できます。

2. 接続経路を1箇所にまとめたかった

Windows端末から都度IBM iに直接つなぐ形にすると、接続先の情報や認証情報があちこちに散らばってしまいます。Ubuntuサーバーを踏み台にして「IBM iへの接続はここだけ」とまとめておけば、接続情報の管理や、同時にどれだけの接続・問い合わせが飛んでいるかの把握もしやすくなります。

3. 将来の構成を見据えた土台にしたかった

今回の容量分析はあくまで最初の一歩で、この後API層やWeb画面を作っていく計画があります。であれば、最初から「開発・実行基盤はUbuntu上に置く」という前提で環境を作っておいた方が、後々の手戻りが少ないと考えました。

Claude Codeをどう使ったか

ことり主任がAIロボットと並んでノートパソコンの画面を一緒に見ている様子のイラスト

IBM iはほぼ初めて触るシステムだったので、コマンド一つひとつの意味を調べながら進めるだけでもかなりの時間がかかります。そこで、Ubuntuサーバー上での開発作業にClaude Codeを使いました。

やってもらったことは主に次の3つです。

IBM iのライブラリ一覧やオブジェクト情報を取得するPythonスクリプトの作成
実行してみて出たエラーメッセージや想定外の挙動をもとにした原因調査
「実機で試す→結果を見る→修正する」というサイクルの高速化

初心者が手探りで公式ドキュメントとにらめっこするより、実際に動かした結果を見ながら一緒に原因を追ってもらえたのは助かりました。

分析でわかったこと(一例)

この分析は、私が自分でコードを書いて掘り下げていった、というより次のような流れで進みました。

Claude Codeに「ライブラリの容量をレポートして」と依頼する
Claude Codeが分析スクリプトを実行し、レポート(容量の合計)を出してくる
数字の整合性を確かめたかったので、Claude Codeに相談すると「WRKSYSSTS(Work with System Status。IBM i標準のコマンドで、ディスク使用率などシステム全体の状況を確認できます)で確認してみましょう」とコマンドを教えてもらう
教えてもらったWRKSYSSTSを、自分で5250画面(IBM i特有のターミナル画面)から実行する
レポートの値と、WRKSYSSTSで見えた実際の使用量が、まったく違うことに気づく
その乖離をそのままClaude Codeに伝える
Claude Codeがそれを踏まえてもう一度実行し、原因を突き止めていく

つまり私の役回りは、自分で手を動かして原因を探るというより、AIに実行させて、出てきた結果の整合性を確認するという立ち位置でした。しかもその整合性確認自体、自分でコードを書いて検証したわけではなく、会話の中でClaude Codeにやり方(コマンド)を教えてもらい、それを自分で実行する、という流れです。

原因を調べると、「ライブラリのサイズ」はライブラリという入れ物自体の大きさであって、中に入っているデータの合計ではないことが分かりました。あるライブラリを例にすると、入れ物としてのサイズは数MBしかないのに、中身のオブジェクトを1件ずつ数えて合計すると、実際には数百MBに達していました。桁が一つ以上違う、というレベルの差です。

正確な容量を知るには、「ライブラリのサイズ」を見るのではなく、ライブラリの中身を1件ずつ数えて合計する必要がある、というのが今回の分析でつかんだポイントでした。数千件規模のライブラリすべてに対してこれを行うバッチ処理をClaude Codeに組んでもらい、WRKSYSSTSの実測値に近い、実態に近い合計値にたどり着けました。

これからの構成予定

容量分析はまだ入り口で、今後は次のような段階を踏んでいく予定です。

API層の追加: UbuntuサーバーにNode.js/TypeScriptベースのAPIを立て、IBM iのDB2に直接SQLを投げるのではなく、必ずAPI経由でデータを取得する形にする（接続の一元管理・負荷コントロールのため）
Docker化: API層やその周辺ツールをコンテナ化し、環境の再現性を上げる
社内向けWeb画面の拡充: 5250画面（IBM i特有の緑色の文字だけのターミナル画面）でしか見られなかった業務データを、ブラウザから検索できるようにする
依存関係の可視化: どのプログラムがどのライブラリ・ファイルを参照しているかを分析し、クラウド移行時にどこまで一緒に移す必要があるかを判断できるようにする

クラウド移行そのものはまだ先の話ですが、「今何がどれだけあるか」を正確に把握できたことで、次の判断がしやすくなったのは大きな収穫でした。

まとめ

IBM iの管理を初めて任されたら、まず本番機に手を加えずに済む「踏み台サーバー」を1台挟むと、安心して試行錯誤できる
接続経路を1箇所にまとめておくと、後からAPI層を足すときにも構成がぶれない
クラウド移行の検討は、まず正確な現状把握（今回で言えば容量）から
初めて触るシステムほど、Claude Codeのような「一緒に実機を見ながら調べてくれる」ツールの効果を感じやすい

引き続き、API層の構築や依存関係分析に取り組み次第、続報を書いていく予定です。API層構築編はこちらの記事にまとめました。