本文へスキップ
Kurahi

産業向けモダナイゼーション

English: Industrial modernisation

レガシーシステムのモダナイゼーションは、コードが何をしているかを正確に把握することから始まります。 Kurahiはそれをコード自体から導きます。決定的な解析エンジンが事実を抽出し、すべての事実に出典の ファイルと行番号を付け、エージェントは推測ではなくその事実に基づいて説明します。プログラムの業務上の 目的など、コードからは分からないことは「要確認」として残し、人が確認します。

これはIndustrialエディションの分析パックです。2026年10月25日時点で、 リリース2.2.0に含まれています。

解析の対象

「解析の対象」の見出し
言語・分野 状況 解析で得られるもの
COBOL、コピーブック、JCL 有効 段落、PERFORM・CALLのグラフ、ファイル・EXEC SQL・EXEC CICSのアクセス、データ辞書、業務ルール候補、影響範囲
Java 有効 path:line付きのクラス・メソッド・フィールド、継承、静的に解決できる呼び出し、Spring・JPA・MyBatisマッパーのテーブルアクセス
SQL DDL 有効 テーブル・ビュー・インデックス、型・NULL可否・既定値を含む列、キー、コメント（ANSI、DB2、Oracle、PostgreSQLの基本）。BEGIN ... END 本体を持つストアドプロシージャ・関数・トリガー（DB2 SQL PL、Oracle PL/SQL）：文ごとのテーブルアクセス、CALL、トリガーの起動イベント
FORTRAN 有効 プログラム単位、CALL・USEの関係、ユニット間で共有されるCOMMONブロック、INCLUDE、JCL経由で結び付くファイル入出力、型と精度
PL/I 有効 プロシージャとCALLの関係、%INCLUDE、DECLARE構造体、JCL経由で結び付くファイル、EXEC SQLのテーブル、ONユニット
PLC（IEC 61131-3 ST） 対応 PROGRAM・FUNCTION_BLOCK・FUNCTION、VAR 宣言、AT %I/%Q/%M アドレスの I/O 一覧、重複アドレス、ファンクションブロックのインスタンス、代入。PLCopen XML 出力も同様に解析（ST 本体、FBD・LD のブロック呼出しと出力変数・コイルへの書込み。IL・SFC 本体は未解析として記録）。ベンダーのラダー出力はファイル数のみ（未解析）
バッチスケジューラ 計画中 ジョブ定義の出力ファイル数を数えるのみ
保全記録、サイバーセキュリティのレビュー 計画中 解析エンジンなし

計画中の項目が事実を生成することはありません。対象となるファイルを報告するだけなので、 解析の範囲外にあるものがプロジェクト上でそのまま分かります。

ファイルは拡張子で、拡張子から判断できない場合（.txt、拡張子なしなど）は内容で認識します。 内容で認識したファイルは 1 つのエンジンだけが読みます。EXEC SQL CREATE VIEW を含む COBOL プログラムや、SYSIN にインストリーム DDL を持つジョブは、.cbl・.jcl 拡張子の場合と同じく COBOL/JCL エンジンが読み、DDL スクリプトとして二重に解析されることはありません。もう一方の エンジンの検出結果には、これらのファイルが別エンジンへ振り分けられた件数が表示されます。

テーブルは言語をまたいで1つのノードとして扱います。COBOLの EXEC SQL のテーブル、JPAの @Table、 同名の CREATE TABLE は同じテーブルです。そのため、CRUDや影響範囲の問いに、COBOL、Java、 データベーススキーマをまたいで答えられます。言語ごとの詳細と限界は レガシー解析（英語）を参照してください。

設計書の生成

「設計書の生成」の見出し

解析結果から、日本語または英語の設計書を生成します。構成は、システム概要、ジョブフロー、 プログラム仕様書、データ項目定義書、CRUDマトリクス、そしてすべての不足点と要確認事項をまとめた カバレッジです。対象フォルダにJavaやDDLがあれば、Javaのクラス仕様とテーブル定義（本体を解析したストアドルーチンの一覧を含む）も加わります。 PLCのStructured Textがあれば、POU一覧、%I/%Q/%Mアドレス順の入出力割付表、POUごとの変数を含むPLCプログラム仕様も加わります。

対応の取れた BEGIN ... END 本体を持つストアドプロシージャ・関数・トリガーは、グラフ上のルーチンになります。 静的な各文は参照するテーブルと結ばれ（CRUDマトリクスとテーブルの影響範囲にルーチンが含まれます）、CALL は 呼出し先ルーチンと結ばれ（定義のない名前も残し、未定義と明記します）、トリガーは起動イベントとともにテーブルから 結ばれます。動的SQL（EXECUTE IMMEDIATE、PREPARE、EXEC(...)）と本体内のDDLは推測せず不足点として列挙します。 Oracleのパッケージ本体はメンバーごとに分割し、各メンバーを PACKAGE.MEMBER という名前のルーチンにします （CALL pkg.member と、パッケージ内の兄弟メンバーへの修飾なしの CALL はそのメンバーと結ばれます）。 パッケージレベルのカーソル、初期化ブロック、外部ルーチンのメンバーは不足点とし、入れ子のサブプログラムを宣言する メンバーを含むパッケージは一つの不足点のままです。 PostgreSQLのドル引用符の本体、パッケージ仕様部、BEGIN のない本体、対応の取れない本体は、従来どおり言及テーブルを記した 一つの不足点のままです。Java（JDBC、JPA、MyBatis）とCOBOL・PL/I（EXEC SQL CALL）からルーチンへの静的な呼出しも 結ばれるため、テーブルの影響範囲はルーチンを経由してそれらの呼出し元にも及びます。

同じテーブル名を二つのスキーマが定義している場合（HR.EMPLOYEE と PAYROLL.EMPLOYEE）、スキーマごとのテーブルは それぞれ独自の列を持つ別のノード（table:HR.EMPLOYEE）となり、名前だけのノード table:EMPLOYEE の下に置かれます。 スキーマを明記した参照（JPAの @Table(schema = ...)、Javaやルーチン本体のスキーマ修飾付きSQL）はそのスキーマの テーブルと結ばれ、スキーマのない参照は名前だけのノードに残り、そのノードは名前が曖昧であることを示します。 スキーマを明記した外部キー・ビューの参照元・インデックスも同様で、 スキーマを明記した ALTER や COMMENT はそのスキーマのテーブルを変更します。 一つのスキーマのテーブルの影響範囲にはそのテーブル自身のアクセス元だけが、名前だけの影響範囲にはすべてが含まれます。 一つのスキーマだけが定義するテーブルは、従来どおり一つのノードのままです。

JPAの @ManyToOne / @OneToOne（所有側。mappedBy 側は除く）は、エンティティのテーブルから対象エンティティの テーブルへの JOIN エッジとなり、結合列（@JoinColumn、@JoinColumns の各列、または JPA の既定名 フィールド名_ + 対象の @Id 列）を持ちます。これはマッピング側の主張であり、DDLと照合されます。 所有側のテーブルがDDLにあるのに一致する外部キーがない結合は「DDLに外部キーなし」と示され、 エンティティがマッピングするテーブルの外部キーのうち、どの関連も使わないものはマッピング未使用として一覧されます。 列は集合として比較します。@JoinColumn を持つ単方向 @OneToMany は、対象のテーブルから所有側のテーブルへの結合です。 結合テーブル（@ManyToMany、または @JoinTable を持つか結合列のない @OneToMany）は、所有側への結合（joinColumns）と 対象への結合（inverseJoinColumns）の2本の JOIN エッジとなり、名前が書かれていなければ JPA の既定名 （所有側_対象、逆側のフィールド名またはエンティティ名 + _ + @Id 列、フィールド名_ + 対象の @Id 列）を使います。 結合テーブルの外部キーはエンティティのテーブルと同様に判定します。mappedBy 側は何も追加しません（結合は所有側が持ちます）。 @SecondaryTable、@Inheritance、@Embedded はまだモデル化していません。

  • 事実の各行に path:line を記載。 レビュー担当者はどの行もソースと照合できます。

  • 推測で埋めない。 プログラムの業務目的と、各業務ルール候補の業務上の意味は「要確認」と記載します。

  • 決定的。 同じソースからはバイト単位で同一の文書が生成され、元にしたソースのフィンガープリントが記録されます。

  • Word でも出力。 legacy_design_doc に output_format: "docx" を指定すると、同じ内容を Word 文書としてプロジェクトの output/design-docs/設計書_<YYYYMMDD>.docx（英語は design-doc_<YYYYMMDD>.docx）に書き出します。既存のファイルは上書きせず、-2、-3 と番号を付けます。計画 Plan または 実行 Act モードのプロジェクトで、office ツールと同じパスの制限（書き込み可能なフォルダーのみ、シンボリックリンク不可）に従います。

内容、サンプル、限界：設計書と移行ウェーブ案（英語）。

変更検知

「変更検知」の見出し

legacy_changes（{path, since?: "baseline", limit?}）は、現在の事実インデックスを保存済みの基準と比較し、COBOL プログラム、コピーブック、JCL ジョブ、SQL DDL のテーブル・列・ストアドルーチンの追加・削除・変更と、CALL、PERFORM、EXEC SQL、JCL ステップの関係の追加・削除を、すべて path:line の根拠付きで返します（削除は基準側の行を (baseline) 付きで示します）。件数は完全で、一覧は limit 件まで、順序は固定です。初回は基準を作成するだけで、変更としては何も報告しません。

基準はプロジェクトの解析キャッシュ output/.legacy-index/baseline/ に保存し、顧客のソースフォルダーには書きません。基準を進めるのは legacy_baseline_advance（{path, snapshot?}）だけで、直前の比較に使ったスナップショットを基準にします。オートパイロットの legacy.baseline_advance は夜間の案件を起票した後にこれを実行します（オートパイロット）。リセットするには legacy_baseline_advance {path, rebuild: true} を実行するか、output/.legacy-index/baseline/ を削除します（次回の実行で新しい基準を作ります）。詳細：変更検知（英語）。

移行ウェーブ案：人がレビューするための提案

「移行ウェーブ案：人がレビューするための提案」の見出し

移行ウェーブ案は、COBOLプログラムを移行する順序を提案します。CALLとプログラム間で受け渡される データセットから依存関係を求め、まとめて移行すべき循環、ウェーブ、リスク点数を算出します。 リスクの計算式と根拠となるソース行は案の中に記載します。これはあくまで提案です。業務上の優先度、 チームの体制、切り替えの時間枠、移行方式は考慮しておらず、それらは人が判断します。

エンジニアのエディタで：kurahi-legacy MCPサーバー

「エンジニアのエディタで：kurahi-legacy MCPサーバー」の見出し

kurahi legacy mcp --root <project> は、同じ解析をVS Code、Eclipse系のメインフレームIDE、 Model Context Protocol（MCP）に対応した任意のクライアントに提供します。読むのは指定した1つの プロジェクトフォルダだけで、読み取り専用、ゲートウェイの起動は不要、事実は path:line 付きで返します。 設計書、移行ウェーブ案、言語横断のツール（modernise_plan、modernise_crud、modernise_impact、 modernise_inventory）も利用できます。

設定方法：エディタでレガシー解析（MCP）。

ワークベンチでの位置づけ

「ワークベンチでの位置づけ」の見出し

プロジェクトの Assets ビューで「設計書の生成依頼を開く」または「移行ウェーブ案の生成依頼を開く」を 選ぶと、そのプロジェクトのチャットに日本語または英語の依頼文が入ります。内容を確認して送信すると 解析を依頼できます。ゲートウェイへの接続、プロジェクトフォルダー、およびプロジェクトで有効な legacy-analyzer プラグインが必要です。明示されたプラグイン一覧は、空の一覧も含めてテンプレートより優先されます。

生成した最新の文書は解析キャッシュに保存されますが、成果物のバージョンは自動作成されません。 回答の「成果物として保存」で下書きを保存してください。既存の成果物の改訂を残す場合は、 その成果物を開いて新しいバージョンとして保存します。レビューと承認は別の手順です。 移行ウェーブ案は提案であり、システムを変更する許可ではありません。

Industrialエディションでは、解析はプロジェクトの中で行います。プロジェクトのフォルダが権限の境界となり、 プロジェクトのモード（参照・計画・実行）がエージェントにできることを制限します。エージェントの成果物を 有効とする前に承認を必須とするよう、プロジェクトごとに設定できます。コマンドなどの重要な操作は、 Kurahiの他の部分と同じ承認を経由します。