自社AI基盤「AIDD」をベースに、実行時にLLMが自律的にツールを呼び出す AI Agent ランタイムを設計し、顧客のレガシー移行・コード自動生成・テスト自動化を支援。3案件いずれもランタイム型で、社内PoCから実顧客への導入フェーズへ展開しています。
プロジェクト概要
顧客の設計書やコード資産をAIDDに取り込み、AI Agent ランタイムを設計します。ランタイムは実行時に、LLMが状況に応じて「RPG／既存コードの取得」「設計書の参照」「コード生成」「テスト実行」「バグ修正」などのツールを自律的に呼び出しながら処理を進めます。ケースごとに方式（Pythonによるルールベース修正 / LLM生成）を切り替えられるのが特徴で、3案件いずれもこのランタイム型です。現在2社で導入・実施中、1社で新規開始しています。
担当（役割）
共通の狙い
アーキテクチャ（共通）
3案件に共通するのは、固定パイプラインではなく「ランタイム」である点です。実行時にLLMが次のアクションを判断し、必要なツール（コード取得・生成・テスト実行・修正）を自律的に呼び出しながら、完了まで反復します。
flowchart LR
IN["設計書 / 既存コード資産"]
KB["AIDD（Knowledge Graph 基盤）"]
LLM["LLM（次のアクションを判断）"]
TOOLS["ツール群：コード取得 / 生成 / テスト実行 / 修正"]
OUT["Java コード + テスト成果物"]
IN --> KB --> LLM
LLM -->|ツール呼び出し| TOOLS
TOOLS -->|結果を返す| LLM
LLM --> OUT案件 A
2026年06月 〜 継続中。RPGとケース設計書をAIDDに取り込み、顧客ツールで約70%を自動生成。残り30%（ケース設計書 約100件）を、Orchestratorがケース単位に分解し、AI Agent ランタイムで自動化しました。生成方式はケースに応じて Python（ルールベース）と LLM生成 を切り替え、UT失敗・整合性不一致は同じランタイム内で自己修正して収束させます。
flowchart TD
IN["RPGコード + ケース設計書（約100件）"]
PARSE["取り込み：RPG構造・ケースをAIDDに登録"]
KG[("AIDD Knowledge Graph")]
T70["顧客ツール：コードの約70%を自動生成"]
ORC["Orchestrator：残り30%をケース単位に分解・進行管理"]
subgraph RT["AI Agent ランタイム（実行時にLLMがツールを自律呼び出し）"]
direction TB
DEC{"① ケースごとに生成方式を判断"}
PY["② Python（ルールベース）でコード修正"]
LLMGEN["② LLM生成（必要なRPGコードを実行時に取得）"]
TSPEC["③ 単体テスト仕様書 生成"]
RUN["④ UT 実行"]
FIX["バグ修正（エラーを読み自己修正）"]
CHK["⑤ 設計書・KGとの整合性チェック"]
DEC -->|定型パターン| PY
DEC -->|非定型| LLMGEN
PY --> TSPEC
LLMGEN --> TSPEC
TSPEC --> RUN --> CHK
RUN -->|失敗| FIX --> DEC
CHK -->|不一致| DEC
end
TOOLS["ツール群：RPG/コード取得・KG検索・コード生成・テスト実行・ファイル書込"]
HUMAN["人手レビュー（要確認のみ）"]
OUT["Java コード + 単体テスト成果物"]
IN --> PARSE --> KG
KG --> T70
KG --> ORC
ORC --> DEC
T70 --> OUT
RT -. ツール呼び出し .-> TOOLS
CHK -->|OK| HUMAN --> OUT定型パターンはPythonのルールベースで確実に修正し、非定型なケースはLLM生成に回します。どちらで処理するかを、ランタイムがケースごとに判断します。
LLM生成では、事前に全部を渡すのではなく、必要になったRPGコードや関連情報をLLMが実行時に自分で取得（ツール呼び出し）してから生成します。UTのバグ修正も同じランタイム内で反復します。
案件 B
2026年04月 〜 2026年07月。設計書理解からコード・テスト・画面確認までを、Orchestratorが画面・機能単位にタスク分解し、各エージェントが実行時にツールを呼び出しながら進めるランタイムとして構築。生成→テスト→自己修正、生成→画面突合の2つの検証ループを内蔵しています。
flowchart TD
IN["設計書（Word / Excel / PDF / 画面）"]
KG[("AIDD Knowledge Graph")]
ORC["Orchestrator：画面・機能単位に分解し進行管理"]
subgraph RT["AI Agent ランタイム（実行時にLLMがツールを自律呼び出し）"]
direction TB
UND["① 設計書理解（VLMで画面・表も解析）"]
MD["② Markdown設計書 生成"]
GEN["③ コード生成"]
TSPEC["④ 単体テスト仕様書 生成"]
RUN["⑤ ビルド / UT 実行"]
FIX["バグ修正（エラーを読み自己修正）"]
SHOT["⑥ 画面起動 / スクリーンショット"]
VER["⑦ 設計書との突合（整合性確認）"]
UND --> MD --> GEN --> TSPEC --> RUN --> SHOT --> VER
RUN -->|失敗| FIX --> RUN
VER -->|不一致| GEN
end
TOOLS["ツール群：設計書/コード取得・KG検索・ファイル書込・テスト実行・スクショ取得"]
HUMAN["人手レビュー（要確認のみ）"]
OUT["コード + 単体テスト仕様書 + 画面エビデンス"]
IN --> KG --> ORC --> UND
RT -. ツール呼び出し .-> TOOLS
VER -->|OK| HUMAN --> OUT「ビルド/UTが失敗したら自己修正して再実行」「設計書との画面突合で不一致ならコード生成に戻す」の2ループで、生成物の品質を実行時に収束させます。
画面レイアウトや遷移は文字だけでは検証できないため、実際に画面を起動してスクリーンショットを取り、設計書と突き合わせてエビデンスとして残します。
案件 C
2026年07月 〜 継続中。VB資産をAIDDに取り込んで依存関係を把握し、Plannerが移行単位を依存順に決定。各単位を「文脈収集 → 変換 → ビルド → UT → 整合性チェック」の全自動ランタイムで処理し、コンパイル・テストエラーは自己修正で吸収します。
flowchart TD
IN["VB資産（フォーム / モジュール / コード）"]
PARSE["解析：VB構造をAIDDに取り込み（画面・モジュール・依存）"]
KG[("AIDD Knowledge Graph")]
PLAN["Planner：依存関係順に移行単位を決定"]
subgraph RT["AI Agent ランタイム（全自動 / 実行時にツールを自律呼び出し）"]
direction TB
CTX["移行単位の文脈収集（関連VB・KGから取得）"]
CONV["VB → Java 変換 生成"]
BUILD["ビルド / コンパイル"]
UT["UT 生成 / 実行"]
SELF["自己修正（コンパイル・テストエラーを反映）"]
CHK["設計書・KGとの整合性チェック"]
CTX --> CONV --> BUILD --> UT --> CHK
BUILD -->|エラー| SELF --> CONV
UT -->|失敗| SELF
CHK -->|不一致| CONV
end
TOOLS["ツール群：コード取得・KG検索・ビルド・テスト実行・ファイル書込"]
HUMAN["人手レビュー（例外・低信頼のみ）"]
OUT["Java プロジェクト（コード + テスト）"]
IN --> PARSE --> KG --> PLAN --> CTX
PLAN -->|単位ごとに反復| CTX
RT -. ツール呼び出し .-> TOOLS
CHK -->|OK| HUMAN --> OUTVBはフォームやモジュールが相互依存するため、AIDDのKnowledge Graphで依存関係を先に把握し、下流から順に移行することで手戻りを減らします。
変換・ビルド・テストは全自動で回しつつ、例外や低信頼のケースだけ人手レビューに回す設計で、自動化率と品質を両立させます。