CET INSIGHTS / 技術で見る業務自動化 ②
オンプレの古いシステムを、API化して、その先へ
技術で見る「接続」のすべて
「うちのオンプレのIBM iに、本当に繋がるのか」——情シスの方からよくいただく、最も切実な問いです。この記事では営業トークを脇に置き、オンプレ環境の古いシステムを起点に、どうデータを取り出し、どう変換し、どうAPIにし、そして接続したあと何をするのか。その技術的なフローを、順を追って具体的にご説明します。
「うちのオンプレのIBM iに、本当に繋がるのか」——情シスの方からよくいただく、最も切実な問いです。この記事では営業トークを脇に置き、オンプレ環境の古いシステムを起点に、どうデータを取り出し、どう変換し、どうAPIにし、そして接続したあと何をするのか。その技術的なフローを、順を追って具体的にご説明します。
古い基幹システムの近代化と聞くと、「全部作り直す大工事」を思い浮かべるかもしれません。CETのアプローチは違います。既存システムは止めず・触らず、横からデータを取り出してAPI化する。そのために踏むのが、次の5つのステップです。
順番に見ていきましょう。今回は、最も手強いとされるオンプレのIBM i(AS/400)を主な例にします。これが繋がるなら、たいていの環境は繋がります。
いきなり繋ぎにいくことはしません。最初に、対象システムの「繋ぎ方」を見極めます。CETは初期診断で、次の4つを確認します。
第一に、基幹システムはオンプレか、クラウドか。第二に、オンプレなら仮想基盤(VMware / Hyper-V)があるか。第三に、外部ネットワーク接続が許可されるか。第四に、リアルタイム連携が必須か、日次バッチで足りるか。
この4問だけで、後述する接続方式と設置形態が、ほぼ自動的に絞り込めます。「とりあえず繋いでみる」のではなく、繋ぐ前に最適な道を決める。これが手戻りを防ぎ、見積もりの精度を上げます。
CETの接続アダプタ本体は1つです。変えるのは、それを動かす場所(器)だけ。オンプレかどうか、エッジサーバーが要るかどうかで、次の4パターンから選びます。
外部接続を許さない・隔離されたオンプレ向け。CETが小型サーバーを社内に持ち込み、LAN内に設置。最も手間はかかるが、最も安心感が高い。
既にVMware / Hyper-V等の仮想基盤がある場合。そこにアダプタのVMを1つ立てるだけ。機材持込不要で設置が早い。中堅企業の主力パターン。
基幹が既にクラウド(SAP S/4HANA・各種SaaS)にある場合。エッジ不要で、CET側からAPIで直接接続。設置作業はほぼゼロ。
リアルタイム接続が難しい・不要な場合。日次でCSV等を共有フォルダやSFTPに置いてもらう。原始的だが、どんな環境でも必ず動く「最後の砦」。
4パターンで中身を作り分けているわけではありません。アダプタは環境に依存しないDockerコンテナとしてパッケージされており、「物理サーバーに載せる」「顧客のVMに載せる」「CETのクラウドで動かす」を、同じ成果物を置く場所だけ変える形で実現します。だから品質が安定し、構築も速い。
器を置いたら、次は実際にデータを引き出します。「古すぎて取り出せないのでは」と心配されますが、レガシーには必ず引き出し口があります。CETは対象に応じて最適な方法を選びます。
IBM i のDb2 for iや、SQL Server・Oracleなどは、SQLで直接読み取れます。最も素直で確実な方法です。まずはここを狙います。
IBM i のジャーナル機能のように、データの変更履歴を記録する仕組みがあれば、それを監視して「変わったところだけ」を効率的に取得できます。リアルタイム連携に向きます。
DBに直接触れない場合の手段です。人が緑画面(5250端末など)を操作するのと同じことを、AIが画面越しに行ってデータを取得・入力します。最後の手段ですが、これがあるからこそ「繋がらないシステム」はほぼありません。
夜間バッチが吐き出すCSVや固定長ファイルを受け取る方法。リアルタイム性は落ちますが、最も確実で、どんな環境でも成立します。
取り出したデータは、そのままでは使えません。古いシステム特有の形式を、現代のシステムが理解できる形に変換し、標準的なAPIとして外に出します。この一連が「API化」の実体です。
変換でよく出てくる「古い世界の言葉」と、その翻訳先は、たとえば次のようなものです。これらはどの会社でも判で押したように同じ罠として現れるため、CETでは共通の変換ライブラリとして資産化しています。
さらに、夜間バッチでしか動かなかった処理を、リアルタイムに呼び出せるAPIへと変換するのがRHYTHMです。「夜間バッチで翌朝確認」という非同期の業務文化を、秒単位で応答する世界へ置き換えます。これにより、古いシステムが現代のSaaSやAIエージェントと対等に会話できるようになります。
API化できた瞬間に、業務が自動化されるわけではありません。むしろここからが本番です。取り出せるようになったデータを使って、どう安全に業務を任せていくか。CETは段階を踏みます。
この「検証 → 見せる → 任せる → 見守る」の流れは、技術的な接続(STEP0〜3)の上に乗る業務の育成プロセスです。詳しくは別記事「AI業務自動化を育てる4つの局面」で解説しています。
「会社ごとにシステムが違うなら、毎回ゼロから作るのでは?」——よくある疑問です。答えは「いいえ」。CETは7〜8割を共通化しています。秘訣は、3つの層に分けることです。
YAML等の設定に外出し。新規顧客の追加が「設定1枚」で済む。たとえるなら、注文住宅と工務店の標準工法の違いです。基礎・配管・電気配線(接続・変換・基盤)は標準化された工法で組み、間取りと内装(各社固有の業務)だけを合わせる。毎回ゼロから設計するのをやめることで、初期構築は大きく圧縮できます。
※ 本記事に記載した接続方式・割合・期間は、中堅企業で典型的に見られる状況をもとにした想定・試算です。実際の方式・期間は、対象システムや要件により異なります。具体的なご提案は初期診断にて個別に行います。
初期診断で、御社のオンプレ環境にどう接続し、どうAPI化できるかを、
具体的な方式と進め方に落とし込んでご提案します。