PL/IをAIエージェントに書かせてみて見えた、トークン上限という壁
3つ目の課題である人材・開発スタイルへの対応として、鈴木氏はメインフレームの開発ツール・プロセスを分散システムの開発プロセスに統合する取り組みを進めてきた。コードエディタはVSCodeに、ソースコード管理はGitLabに、CIパイプラインはGitLab CIに集約し、メインフレーム開発者と分散システム開発者が同じUI・プロセスでリソースを融通し合えるようにした。この共通化が、生成AI活用の土台にもなったという。
その実証として鈴木氏が紹介したのが、昨年のIBM TechXchange summit Japanで実施した、AIエージェント「Cline」を使ったデモだ。自然言語による指示からメインフレーム言語であるPL/Iのコードを生成し、コンパイルさせたうえで実際にメインフレームへリモート実行し、結果を取得するところまでを実演した。「レガシー言語でも十分にAIが使える可能性を示せた」と鈴木氏は振り返る一方、その後の検証で見えてきたのは限界でもあった。複雑・肥大化した勘定系プログラムの全体構造解析を試みたところ、数千のソースコードと数万のマクロファイルという規模の前では、AIエージェントのトークン上限やコンテキスト制約、キャッシュ・履歴の制約に阻まれ、解析自体が成立しなかったという。ごく単純な文字列抽出プログラムを1つ作らせるだけで、大半のトークンを使い切ってしまうほど非効率だったと鈴木氏は明かした。
半年ほど経った現在では、IBM Watsonx Code AssistantやIBM Bobの活用によって同等以上のAI支援開発環境が標準化され、特定のスキルに依存せず誰でも利用できる段階に進化した。メインフレーム言語に特化したAIエージェントもすでに登場しており、活用は検証段階から実用段階へと移りつつある。ただし鈴木氏は「すべてが万能ではない」と釘を刺す。
「バイブコーディング」ではなく「仕様駆動開発」、価値が高まるのは設計情報
この実証を踏まえて鈴木氏が導き出した現実解は、対話しながらその場でコードを書かせる「バイブコーディング」ではなく、「仕様駆動開発」だ。AIに任せるのは仕様の解釈からコードを生成する部分であり、その品質を決めるのは入力側、つまり人が整理する仕様・ルール・設計資産・情報資産の質だという。「エンタープライズAIの競争力は、AIのコード生成能力そのものではなく、AIが活用できる設計資産・知的情報資産の質と量で決まる。AI時代であるからこそ、価値が高まるのは人間の能力の方だ」と鈴木氏は語った。IBMも同様の課題意識のもと、文書・設計情報との連携を通じてコンテキストを標準化するソリューション「ALSEA」を提供しており、業界全体が単なるコード生成から開発プロセス全体でのAI活用へと向かっていると鈴木氏は説明した。
開発だけでなく、運用面でもAI活用を模索している。分散系ではDynatrace社のソリューションを中心にObservability（O11y）を実践する一方、メインフレーム領域ではIBM Concert for Zを活用した研究を進めている段階だ。狙いは、メインフレームと分散システムを横断した可視化と、障害検知・原因分析の高度化である。
鈴木氏は最後に、今回のモダナイゼーションが特定システムの刷新にとどまらず、アーキテクチャ・開発・運用を横断した継続的な変革であると強調した。「システムの中の生成AIは、あくまで変革を加速する手段だ。前提となるのは、人がシステム全体を見渡す視座を持ち、AIが正しく活用できる設計資産・知的資産を整備し続けること」。40年稼働してきた巨大な勘定系を前に、鈴木氏が導き出したのは、技術を入れ替えることではなく、人がその設計を担い続けるという、地に足のついた結論だった。
