阿野 幸裕（株式会社GxP）
検証日：2026年9月2日
はじめに
生成AIによるIBM i活用というと、RPGやCOBOLのソースコードをAIに読み込ませ、内容を説明させたり、改修案を作らせたりする使い方を思い浮かべる方が多いのではないでしょうか。
これまで私も、IBM BobやClaude CodeからX-Analysis MCPを利用し、IBM iアプリケーションの構造をAIから調査する検証を行ってきました。今回は少し違うことを試しました。
ひとりのAIに調査を任せるのではなく、複数のAIエージェントに役割を与え、「情報システム部門」として仕事をさせたらどうなるのか。
Claude CodeのAgent Teamsを使い、情報システム部長、基幹システム担当、データベース・影響分析担当、システム運用・保守担当、品質管理・テスト担当というチームを編成しました。
狙いは、AIに人間の情シス担当者を置き換えさせることではありません。人間が判断する前に、AIチームが現行システムを分担して調査し、どこまで判断材料を揃えられるのかを検証することです。
X-Analysisは、IBM iアプリケーションを解析し、RPG／COBOL／CL、DDS／Db2 for iなどの資産から、プログラムの呼出関係、ファイルの参照・更新、フィールド使用箇所、データフロー、Business Rule、メトリクスなどを解析リポジトリに保持するアプリケーション解析製品です。
今回の検証では、各AIエージェントがIBM iの大量のソースをその都度すべて読み込んで調査するのではなく、X-Analysis MCP Serverを介して、この解析リポジトリに蓄積された構造情報や必要なソース情報を共通の調査基盤として利用しています。
いわば、複数のAI担当者が同じ「システムの地図」を参照しながら、それぞれの専門領域を調査する構成です。
AI情報システム部を編成する
最初にClaude Codeへ、X-Analysis MCPを共通の調査基盤として利用する「AI情報システム部」をAgent Teamとして編成するよう指示しました。メインセッションを情報システム部長とし、4つのTeammateに専門領域を持たせます。
| 役割 | Agent | 主な担当 |
|---|---|---|
| 情報システム部長 | メインセッション | 依頼受付、調査計画、タスク分解、担当割当、結果統合、追加調査、最終報告 |
| 基幹システム担当 | core-app | RPG/RPGLE/COBOL/CL、呼出関係、処理フロー、画面・帳票、Business Rule |
| システム運用・保守担当 | ops-maint | エラー処理、外部依存、バッチ・ジョブ、排他・ロック、運用上の要確認 |
| 品質管理・テスト担当 | qa-test | 他担当のレビュー、矛盾検出、事実と推定の混在チェック、テスト観点 |
| DB・影響分析担当 | db-impact | PF/LF、フィールド、キー、CRUD、Where-Used、データフロー、変更影響 |
▲図1. Claude Codeが編成した「AI情報システム部」。部長の下に4つの専門Agentを配置
画像をクリックすると拡大表示します
各担当には「一人ですべてを調べない」「担当外の論点は部長へ戻す」という分業ルールを設定しました。また、基幹システム担当、DB・影響分析担当、運用・保守担当の調査結果は、品質管理・テスト担当が別の観点からレビューします。
さらに、すべての結果を「X-Analysisで確認済み」「AIによる整理・推定」「要確認」の3区分に分けるようにしました。AIの出力をそのまま事実として扱わないためのルールです。
▲図2. 編成完了。QA担当がレビュー用チェックリストを整備し、各Agentは調査依頼を待機
画像をクリックすると拡大表示します
営業部門から「顧客管理機能を改修したい」
AI情報システム部へ最初の仕事を依頼します。想定したのは、IBM iユーザー企業で実際にありそうな「曖昧なざっくり」相談への対応です。
対象にはX-Analysisリポジトリ「GRSXADM8JE」を指定しました。依頼を受けた情報システム部長は、すぐに結論を出すのではなく、まずスコープを確認し、その後、調査を複数のPhaseとタスクへ分解しました。
▲図3. 情報システム部長が策定した調査計画。並行調査、独立ベースライン、クロスレビュー、追加調査、最終報告までを段階化
画像をクリックすると拡大表示します
Phase 1では基幹システム、DB・影響分析、運用・保守の3担当が並行して調査します。同時に品質管理・テスト担当が独立したベースラインを取得し、Phase 2でクロスレビューを行う計画です。ここでは、ユーザーが各Agentへ個別に指示したのではなく、部長役のAIが依頼を分解し、専門担当へ仕事を割り振っています。
調査結果が、いきなり食い違った
最初から、チームで調査する意味が現れました。品質管理・テスト担当が独立して取得したベースラインでは、顧客マスター「CUSTS」の参照が13件と見えていました。ところが基幹システム担当が別のX-Analysis MCP機能を使って調べると、50件が検出されました。「CUSF」でも19件と57件という大きな差が出ました。
その後の再調査では、この件数差は単純な精度の優劣ではなく、各MCP Toolが対象とする関係や集計単位の違いによるものだと整理しました。
今回の検証では、プログラムからのファイルアクセスを広く確認する場合はgetFileCrudReferences、LFなどを含むWhere-Usedを確認する場合はgetObjectWhereUsedというように、目的に応じて複数のToolを組み合わせています。
▲図4. core-appとqa-testで母集団が大きく食い違い、部長が前回報告を訂正して追加調査を指示
画像をクリックすると拡大表示します
AIチームは、どちらか一方の回答を採用しませんでした。調査を進めると、利用したX-Analysis MCP Toolによって拾う関係が異なることが分かり、単一の検索結果だけで影響範囲を判断すると過小評価につながる可能性が見えてきました。
品質管理・テスト担当も、当初出した「顧客管理の中核はCOBOL系」という暫定結論を取り消し、チェックリストを改訂しています。取得しやすい情報だけを見て全体を語ってしまう危険は、人間の調査だけでなくAIにもあります。
調べるほど「顧客情報」の意味も変わってきた
調査が進むと、営業部門の「顧客情報を改修したい」という依頼そのものにも確認が必要であることが分かりました。X-Analysis MCPでファイル構造を確認すると、顧客属性・与信・実績・口座情報を持つCUSTSと、住所・電話・メール・監査情報を持つCUSFでは役割が分かれています。
したがって、営業部門が言う「顧客情報」が住所や連絡先を意味するのであれば、改修対象はCUSTSではなくCUSFになります。改修範囲、影響範囲、工数の前提が変わるため、情報システム部長はまず依頼内容を具体化するよう求めました。
情報システム部長が、調査対象そのものを疑い始めた
今回の検証で、最も興味深かった場面の一つです。基幹システム担当が調査を進める中で、リポジトリ名に「XAN4CDEMJP DEMO」が含まれること、ソースにチュートリアル用と考えられる「XAN4TUTOR」をLIBLへ追加する処理があること、同名のプログラムバリエーションが複数存在することなどを報告しました。
▲図5. 情報システム部長が「このリポジトリは本番系か」を最重要の要確認事項として提起
画像をクリックすると拡大表示します
ここで大切なのは、AI部長が「教材リポジトリだ」と断定したわけではないことです。複数の兆候からデモ／教材用アプリケーションである可能性を推定し、営業部門の改修相談を見積る前に、本番リポジトリが別に存在しないかを人間へ確認すべきだと判断しました。
AIが出した「重大リスク」を、別のAIが否定した
Agent Teamらしさが最も分かりやすく表れたのが、RTNMTXを巡る訂正です。基幹システム担当はRTNMTXを「存在しない呼出先プログラム」と判断し、部長も一度は重大なリスクとして受け取りました。
▲図6. 品質管理・テスト担当がソース実体を確認し、部長が「最も深刻」とした判断を訂正
画像をクリックすると拡大表示します
ところが品質管理・テスト担当がソースを確認すると、RTNMTXはプログラム名ではなく、値がRTNMSGTEXTの名前付き定数でした。
RTNMSGTEXT自体が実在することも確認され、少なくとも『呼出先プログラムが存在しないため、エラーメッセージ表示機構が動作しない』という当初の判断は誤りであることが分かりました。なお、本検証では実行時の正常動作そのものを確認したわけではありません。
部長は「私が『最も深刻』として報告した内容は誤りでした」と明示的に訂正しました。調べるAIと、疑うAIを分けることで、AI自身が作った誤りをチーム内で発見できた例です。
最終的に「現行調査報告」を作成
調査とクロスレビューを終えた後、情報システム部長はHTML形式の「顧客管理機能 現行調査報告」を作成しました。報告書では、確認できた事実、AIによる整理・推定、要確認を明確に分けています。
▲図7. 最終成果物「顧客管理機能 現行調査報告」。確認済み・推定・要確認を区分して表示
画像をクリックすると拡大表示します
かなり調べた。それでも部長は「見積りを出さない」と判断した
最終報告書の冒頭には、技術的な発見より先に「改修検討に入る前に解消すべき事項」が置かれました。
▲図8. 最終報告の冒頭に置かれた3つのブロッカー。P1本番／教材判定、P2稼働版、P3実機LIBL
画像をクリックすると拡大表示します
P1は、今回のリポジトリが本番システムなのか、デモ／教材リポジトリなのか。P2は、同じ機能を持つ複数のプログラムのうち、実際の稼働版を特定できないこと。P3は、実機のライブラリリストが不明で、非修飾参照が実行時にどのライブラリへ解決されるか確定できないことです。
つまり、AI情報システム部は「何も分からないから見積れない」のではありません。かなり深く調査した結果、工数を提示する前に解消しなければならない前提条件を見つけました。
クロスレビューで残した「訂正記録」
最終報告には、調査途中で誤っていた結論も残しました。RTNMTXの誤読、顧客管理の母集団、CNTACSの参照数、更新対象ファイルの誤認など、複数の訂正が記録されています。
▲図9. 最終報告書に残された訂正記録。誰が誤りを検出したかも明示
画像をクリックすると拡大表示します
AIの品質を「一度も間違えないこと」で評価するのではなく、誤りを検出し、根拠を再確認し、最終成果物へ訂正履歴として残せることも重要です。今回の検証では、役割を分けたクロスレビューがそのために機能しました。
訂正記録から見えた3つのポイント
- 品質管理担当がRTNMTXの誤読を発見し、重大リスク判定を取り消した。
- DB・影響分析担当が、プログラム名や機能名から推測した更新対象を実際のファイル利用で裏取りした。
- 部長自身も件数を検算し、「18本」という見出しを「24本」へ訂正した。
部長からの進言
最終的に情報システム部長は、営業部門へ今すぐ回答できることと、まだ判断してはいけないことを分けました。
▲図10. 情報システム部長の最終進言。「要確認事項を解消するまで工数と影響範囲を提示しない」
画像をクリックすると拡大表示します
現時点で回答できるのは、たとえば「顧客属性・与信・実績はCUSTS、住所・電話・メール・監査項目はCUSFに分かれている」といった、X-Analysisで確認できたデータ構造の事実です。一方、要確認事項を解消するまでは工数と影響範囲を提示しないという判断になりました。
見積りを出すための前提条件が揃っていないことを発見し、
「今は見積るべきではない」と判断した。
「何でも答えるAI」より、「分からないことを見つけるAI」
生成AIを業務で使う場合、つい「どこまで答えられるか」に注目しがちです。しかし情報システム部門の仕事では、答えを出すことと同じくらい、「まだ答えを出してはいけない」と判断することも重要です。
今回のAI情報システム部は、営業部門が言う「顧客情報」の意味が曖昧であることを指摘しました。調査対象が本番環境なのかを疑い、実際に稼働しているプログラムを特定できていないことを指摘し、LIBLが分からなければ影響分析の前提が確定しないことも整理しました。
さらに、担当者間で調査結果が食い違ったときには再調査を行い、自分たちが出した誤った結論を訂正しました。AIだから正しいのではなく、AIも間違えることを前提に、分業とレビューの仕組みを設計する必要があるという示唆が得られました。
X-Analysis MCPを、AIチームの「共通情報」にする
今回、各AI担当者はX-Analysis MCPを使い、それぞれ異なる観点から現行システムを調査しました。基幹システム担当はプログラム構造やBusiness Rule、DB・影響分析担当はファイルやCRUD、運用・保守担当はエラー処理や実行環境上のリスク、品質管理・テスト担当は別の方法による再確認とクロスレビューを行いました。
ここで重要なのは、各AIエージェントがソースコードだけからシステム全体を想像しているわけではないことです。X-Analysisが解析したIBM iアプリケーションの構造情報を、MCPを通じて共通の調査基盤として利用しました。
一方で、実際の業務運用、本番環境のLIBL、現在使用しているプログラム、業務部門が本当に変更したい内容などは、X-Analysisだけでは確定できません。そこは「要確認」として人間へ返す。この境界を明確にすることも、企業でAIエージェントを使ううえで重要だと考えます。
おわりに
今回試したのは、Claude Code Agent Teamsを使って、IBM iユーザー企業の「AI情報システム部」を作るという実験です。結果として見えたのは、複数のAIを並列に動かせることだけではありませんでした。
役割を分ける。調査方法を分ける。別の担当が結果を疑う。食い違えば再調査する。分からないことは要確認として残す。そして最後に、判断できることと、まだ判断してはいけないことを分ける。これは、実際の情報システム部門が日々行っている仕事にも近いものがあります。
もちろん、AI情報システム部が人間の情シス担当者に代わるわけではありません。AIチームが現行システムを調べ、関係を整理し、矛盾を洗い出し、確認すべき事項を揃える。そのうえで「では、どうするか」を人間が判断する。AIエージェント時代の情報システム部門では、このような役割分担も一つの形になるのかもしれません。
今回、情報システム部長役のAIが最後に行った仕事は、見積り金額を出すことではありませんでした。「今は、まだ見積ってはいけない」と判断することでした。私はそこに、今回の検証で最も興味深い結果があったと考えています。
今回は実顧客の本番システムではなく、検証用として使用しているX-Analysisリポジトリを対象としたため、実業務そのもののリアリティには一定の限界があります。一方、複数のAIエージェントによる分業、クロスレビュー、前提条件の確認というチーム作業の検証として参考にしていただければ幸いです。
参考情報
- X-Analysis 技術コラム AIエージェントとX-AnalysisをMCP連携した各種検証結果を掲載
- X-Analysis MCP iWorld 記事
免責事項
本稿は、X-Analysisの解析リポジトリとClaude Code Agent Teamsを利用した検証結果を紹介するものです。AIエージェントが生成した調査結果には推定や誤りが含まれる可能性があり、本検証でもクロスレビューによる訂正が発生しています。
X-Analysisから確認できる情報は、対象リポジトリに解析・保持されている内容を基礎としています。実際の本番環境、ライブラリリスト、運用手順、ジョブスケジュール、業務部門独自の運用ルールなどは別途確認が必要です。
実際のシステム改修、工数見積り、テスト、運用変更等を行う際は、AIによる調査結果だけで判断せず、担当エンジニアおよびシステム管理者による確認を行ってください。
著者紹介
|
|
株式会社GxP |
