Guri
Guri's IBM i Page on GitHub
Copyright 2026 "Guri The Cat".

AI ネイティブ時代の IBM i のあるべき姿

IBM i (OS/400) は V3.2/V3.6 の CISC → RISC 移行以来、OS の根源的な機能の拡張はされておらず、今でも S/38 時代からの仕様が制限になっています。AI ネイティブの時代になり、このくびきから脱却する時期が来たと考えています。

S/38 時代の制約からの脱却


冒頭に述べた「S/38 時代からの仕様」は、具体的には次の 3 点を指します。

  • オブジェクト名が 10 文字まで1で、使える文字は英大文字・数字と一部の記号のみ
  • 文字コードが EBCDIC
  • QSYS.LIB という独自の 3 階層ファイルシステム (ライブラリー/オブジェクト.メンバー) による平坦な名前空間

IBM i の強み (安定性・強固なセキュリティ・使いやすさなど)は、いずれも本質的に S/38 (AS/400) 時代から変わっておらず、それ自体はすばらしいことです。一方で、現代の多機種 (およびクラウド) 共存環境において IBM i は少数派であり、上記 3 点を解消して他システムとスムーズに連携することの重要性は年々増しています。その阻害要因となるのが前述の 3 点であり、例えば次のような形で表面化します。

  • 5250 画面や印刷装置、データ連携で UTF-8 がきちんと扱えないケースが多い
  • 長いファイル名のシステムと連携する際、短い PF 名と対応を管理する必要がある
  • 階層型ファイルシステムを前提とした git のワークフローを適用しにくい

詳しい方は「Unicode も長い名前も対応済みのはず」というかもしれません。しかし、「対応している」と「業務で使える」は別物です。

機能 対応状況 実際に使うと起きること
SQL の長い名前 対応済み システム名が自動生成され、SQL 名と分裂する
5250 の Unicode 対応済み UCS2 限定、フォント指定が必要、画面レイアウトが崩れる
ILE RPG や Db2 の UTF-8 CCSID 1208 に対応 内部処理は可能だが、5250 画面・帳票 (AFP 以外) という出口が追随しない

これらはいずれも 1. 機能は存在する 2. しかし使うと別の問題が発生する2 3. だから使われない という構造になっています。つまり「対応済みか否か」ではなく、入口から出口まで意識せずに使えることが重要です。


IBM i のあるべき姿は？


では、次世代の IBM i はどのようにあるべきでしょうか。個人的に次の 3 点を実現すべきと考えます。

  • IFS に新しいファイルシステムを追加し、長いパス名・UTF-8・階層構造でネイティブオブジェクト (PGM も DB も) を自由に配置できるようにする
  • UTF-8 を標準文字コードにし、EBCDIC はレガシー互換のために残して相互運用を可能とする
  • QSYS.LIB は S/38 との互換性のためにそのまま残す。PASE も同様に残す

IFS は既に QSYS.LIB、QDLS、root (/) といった複数の名前空間を、それぞれ異なる命名規則のまま並存させています。よって、IBM i の設計思想の延長として「新しいファイルシステムを追加」し、これにオブジェクトモデルやセキュリティなどの先進アーキテクチャーを適用します。

IBM i ユーザーにとって、既存の IT 資産を守ることは最重要事項です。新しいファイルシステムを追加する際も、IBM i 実行環境、S/38 実行環境、S/36 実行環境は堅持すべきです。PASE は AIX の成果物から派生した、開発 W/L やコスト負担が小さい有用な仕組みであり、これも維持すべきでしょう。


「そんな大改修は無理だ」と言われそうですが、IBM 自身が過去に同じことを何度もやっています。

年 事例 内容
1988〜 S/36 環境・S/38 環境 前世代機の実行環境を OS に内蔵
1993 (V2R3) ILE *MODULE、*SRVPGM を新設し、新しい実行モデルを追加。OPM は無傷
1994 (V3R1) IFS 異なる命名規則の名前空間を統合する枠組みを新設
1995 (V3R6) CISC → RISC TIMI の下 (VLIC) を全面的に書き換え

S/36・S/38 環境は今も生きています。S/38 は 1978 年、S/36 は 1983 年の製品です。IBM は 40 年以上前のマシンの実行環境を、今も維持し続けているわけです。しかも異アーキテクチャの完全模倣という意味では、今回提案する内容より難易度が高かった可能性すらあります。

CISC → RISC 移行は、下層を総取り替えしながら上位互換を完全に保った実例です。既存のオブジェクトは再コンパイルなしでそのまま動きました。互換環境をこれまでと全く同じに動かすことは、IBM にとって実績のある作業です。


なぜ「今」なのか？


では、なぜ 30 年間にわたって名前空間・文字コード・オブジェクトモデルという根幹部分に本質的な改修がなされていないのでしょうか。個人的には、過去の経験からコストと需要(売上)のバランスを考慮した上の判断と推測しています。これまでは、IBM の 1 サーバー OS である IBM i に、潤沢な予算を手当てするのはビジネス的に難しかったのかもしれません。

この状況を変えたのが生成 AIです。IBM が推進する Bob などの生成 AI を活用すれば、阻害要因が解消され、継続したビジネスが可能になるでしょう。

開発コストの大幅な削減

IBM i の実装言語を実際に調べてみました。TIMI より下の SLIC は C++ で 200 万行以上、TIMI より上の OS 本体も、ILE 化されている部分はモジュール単位で約 70% が C++ です。つまり新しく書かれた部分ほど C++ であるという状態で、生成 AI が得意な言語です。IBM 社内には当然ソースコードがあり、MI のマニュアルも公開されています。学習データの不足は Premium Package for i のように、追加学習や RAG で埋められる範囲と思われます。

需要の維持・拡大

IBM i ユーザーにとって最大の課題の一つが開発者の高齢化と不足です。生成 AI はその直接の解になりえます。ところが現状の QSYS.LIB は、AI コーディング環境の前提を満たしていません。ソースとオブジェクトの識別子が一致せず、git のワークフローに乗らず、EBCDIC が標準的なツール群と噛みあいません。この状態が続けば、AI で開発生産性を回復できるプラットフォームと、できないプラットフォームの差が今後数年で決定的に開きます。そうなれば、IBM i を選び続ける理由は失われていきます。つまり新しいファイルシステムは、単なる機能追加ではありません。IBM i を AI 時代の選択肢とするための前提です。新規ユーザーの獲得のみならず、非常にロイヤリティの高い既存 IBM i ユーザーにとっても福音となるでしょう。

「UTF-8 や git などの OSS を使いたいなら PASE で良いのでは」という声もあるかもしれません。しかし約 30 年かけてオープン系の受け皿をそちらに育てた結果、新規開発の多くが「IBM i の強みの効かない側」に流れる構造ができてしまいました。他サーバーとの差別化が可能なネイティブ環境の刷新が必要な理由はここにあります。


IBM i の設計そのものは今なお優位性があります。オブジェクト・ベースのアーキテクチャも、単一レベル記憶も、TIMI という抽象レイヤーも、40 年前の発明とは思えないほど現代的です。だからこそ、今となっては「10 文字」「EBCDIC」「平坦なライブラリー」という制約が古めかしく思えるのです。

IBM は Bob で生成 AI をマーケットの中心に据えています。その技術を自らのプラットフォームの足かせを外すために使わない理由は思い当たりません。AI ネイティブな OS として刷新された IBM i (同時に名前も変えて欲しい。これはまた別の話…) を想像すると胸が躍るのは私だけではないでしょう。


  1. Windows と比較しても、IBM i はさすがに仕様の古さが目立ちます。Windows は 9x で内部的に Unicode に対応し、Vista で本格的に使えるようになりました。パス長についても、Windows 3.1 の 8.3 時代には「ライブラリー + オブジェクトで 20 文字」使える AS/400 の方がまだマシでしたが、Windows 95 の LFN で後塵を拝しました。安定性も Windows 7 の頃には実用上問題ない水準に達しています (強固なセキュリティを持ち、1 年以上 IPL なしで運用できる IBM i の方がまだまだ上ですが)。 ↩

  2. 長い名前の挙動は特に分かりやすい例です。10 文字を超える名前を付けると、システム名は「先頭 5 文字 + 連番 5 桁」で自動生成されます。これは IBM のドキュメント に明記された仕様です。

    CUSTOMER_MASTER  (SQL 名)
CUSTO00001       (システム名 = RPG や CL から使う名前)

    連番は作成順で決まるため、開発機と本番機、あるいは顧客ごとにオブジェクトの作成順が違えば、同じ SQL 名が異なるシステム名になりえます。だから結局、人手で対応表を管理することになります。実際、長い名前を使いながらシステム名を手で指定し直している例は珍しくありません。二重管理の義務が発生しているわけです。 ↩