IBM i(AS/400)の初心者が、AI(Claude Code)を使ってAPI層を構築してみた話 ― なぜDB2に直接SQLを投げないのか

前回の記事で、IBM i(AS/400。企業の基幹業務を支える古くからのサーバー製品です)のファイル容量分析に取り組んだ話を書きました。容量の全体像がつかめたところで、次に着手したのが「業務データをブラウザから検索できるようにする」というテーマです。

この記事では、その一歩目として作ったAPI層について、「なぜWebからDB2 for i（IBM i上で動くデータベース）に直接SQLを投げないのか」という構成の話と、実際に接続を組む過程でハマった点をまとめます。

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

なぜDB2 for iに直接SQLを投げないのか

一番シンプルな作り方は、ブラウザ（あるいはWebサーバー）から直接DB2 for iにSQLを投げることです。ただ、今回はその間にAPI層を1枚挟む構成にしました。

理由は次の3つです。

1. 接続情報を1箇所に集約できる: DB2への接続情報（接続先やアクセス権限）をAPI層だけが持つようにすれば、画面が増えてもその都度DB接続情報を配る必要がありません。
2. 同時接続数やクエリ負荷をコントロールできる: 複数の画面が同時に使われても、DB2 for iへの接続数やクエリの重さをAPI層でまとめて調整できます。基幹システムであるIBM iに想定外の負荷をかけないための安全弁です。
3. 画面側の実装とDBの都合を切り離せる: 画面はAPIが返すJSONだけを見ればよく、DB2 for i側のテーブル構造やクエリの書き方を意識しなくて済みます。

前回の記事でも触れた「接続はUbuntu1箇所にまとめる」という方針の延長で、API層もUbuntuサーバー上にNode.js/TypeScript(Express)で構築し、Dockerでコンテナ化しました。

ハマった点: ODBC接続がなぜか固まる

API層からDB2 for iへの接続には、ODBC（さまざまなデータベースに共通の方法でアクセスするための仕組み）を使います。ところが、最初に一般的なODBC用パッケージを使って接続を試したところ、TCP接続自体は成立するのに応答がまったく返ってこない、という不可解な状態にはまりました。

ヒントは身近にありました。同じLAN上のWindows端末では、同じIBM iへのODBC接続が(証明書設定など一切せず)普通に動いていたのです。使われていたのは「IBM i Access ODBC Driver」というWindows版のドライバでした。

そこで、これと同じ系統のLinux版・IBM公式ドライバ（IBM公式aptリポジトリで配布されているパッケージ）を導入したところ、キーストア設定なしであっさり接続できました。

curl https://public.dhe.ibm.com/software/ibmi/products/odbc/debs/dists/1.1.0/ibmi-acs-1.1.0.list \
  | sudo tee /etc/apt/sources.list.d/ibmi-acs-1.1.0.list
sudo apt update && sudo apt install -y ibm-iaccess

汎用のDB用ODBCパッケージと、IBM i専用の公式ドライバとでは、同じ「ODBC接続」でも中身の実装や既定の暗号化ネゴシエーションがまるで違う、というのが今回の学びでした。「普段使えている実例（今回はWindows端末）を観察して、同じ系統のものを探す」というのは、初心者が沼にはまったときの近道になりそうです。

おまけ: API層の実装(Node.jsのodbcパッケージ)では、接続文字列にCCSID=1208（文字コードをUTF-8として扱う指定）を明示しないと、日本語部分が文字化けしました。IBM i側は日本語混じりのデータが多いので、忘れずに指定する必要があります。

このあたりの原因調査は、エラーメッセージを渡してClaude Codeと一緒に切り分けを進めました。「TCP接続はできているのに応答がない」という中途半端な症状は、初心者だけで検索して解決するにはかなり時間がかかっていたと思います。

今できていること

このAPI層を土台に、社内向けの検索画面を1つ作りました。5250画面（IBM i特有の、緑色の文字だけのターミナル画面）でしか見られなかった業務マスタの1つを、品番・品名で検索できるようにしたものです。全角/半角の表記ゆれを吸収したり、関連するマスタ情報を自動で結合して表示したりする程度の、ごく小さな第一歩です。

イメージとしては、こんな画面です（項目名・データはすべて例です）。

品番・品名で検索すると、その工程がどの工場・班で行われ、どこから仕入れている部材かといった関連マスタの情報も一緒に、1つの表として表示されます。以前は5250画面で複数のマスタを別々に開いて突き合わせていた作業が、この検索窓1つで済むようになりました。

これからの構成予定

• API層・DB接続部分のDocker運用をもう少し固める(再現性・監視まわり)
• どのプログラムがどのライブラリ・ファイルを参照しているかという依存関係の可視化
• 他の業務マスタも、同じAPI層を通じて順次Web化

まずは1つの画面を無事に動かせたので、次はこの構成をどこまで横展開できるかを検証していく予定です。

まとめ

• Webから基幹DBに直接SQLを投げず、あえてAPI層を1枚挟むと、接続の一元管理や負荷コントロールがしやすい
• 「同じODBC接続」でも、汎用パッケージとベンダー公式ドライバでは挙動がまったく異なることがある
• 身近で動いている実例(今回はWindows端末)を観察するのが、原因調査の近道になることがある
• 初めて触る領域の切り分けほど、Claude Codeのように一緒にエラーを追ってくれる存在がありがたい