2つのエンジン、1つの計測されたハーネス

Tinh Van Japan のプロダクト

あらゆるコードベースを数分で理解する。数週間ではなく。

Polyglotは言語を問わずドキュメント化し、MainframeはCOBOLを業務ルールと業務フローに変換します。どちらもコードの背後のグラフを描き、書いた内容に答えます。

課題

説明できないシステムは、動かせない

レガシーコードが問題になるのは、古いからではありません。「何をしているか」を完全に説明できるものがソースコードしかなく、そのソースを読める人がいなくなっていくからです。

知識が失われていく

業務ルールは手続き部以外のどこにも書かれてきませんでした。書いた本人が退職すれば、ルールは誰も触れないコードとしてだけ残ります。

ドキュメントは一覧表ではなくソースそのもの

コピーブック、CALLの連鎖、レコードレイアウトが索引もないまま数百ファイルに散らばっています。「このレコードを書いているのは誰か」を答えるには、全部読むしかありません。

どこで切ればいいのかが分からない

密結合したリポジトリには、移行の自然な境界がありません。共有コピーブックと、ごく少数のユーティリティCALL先が、すべてのプログラムを互いに結びつけています。

手作業では数週間かかる

アセスメント、依存関係の追跡、技術ドキュメント作成は、一度読んで一度書くだけの作業です。しかもコードが変わるたびに、そのすべてをやり直すことになります。

ハーネス

2つのエンジン、1つのハーネス

両エンジンは同一のオーケストレーション基盤(ハーネス)の上で動作します。ジョブストア、リアルタイムのイベントストリーム、共有のLLMキャッシュ、そして厳格なバジェット制御。そして、どちらのエンジンも1つのモデルに任せきりにはしません。役割ごとのエージェントが単一の観点で読み、成果物を次へ引き渡します。

  1. 生のソースコード

    レガシーコード、ドキュメントなし、知識は人の頭の中

  2. CodeLensエンジン

    クロール・分析・検証・執筆。すべて計測されたハーネスの上で

    2つのエンジンのいずれかへ

    • Polyglot Engine言語を問わず → 選んだ標準のドキュメントとチャット
    • Mainframe EngineCOBOL → 業務ルール・業務フロー・依存関係グラフ・移行単位
  3. リンクされた文書セット

    技術ドキュメント or BA:図表付きの構造化Markdown

  4. AIエージェント & RAGチャット

    文書に質問。コーディングエージェントやSDLCへ供給

生成前に選ぶ、2つの出力標準

Polyglot Engineでは、生成前に出力標準を選択します。技術ドキュメントはエンジニア向けのアーキテクチャリファレンスを、ビジネス分析(BA)は概要・業務フロー・機能要件・ユースケース・ビジネスルール・用語集を備えたBA文書を生成します。

  • 入力:.zip / git リポジトリ(言語不問)
  • 標準A:技術ドキュメント
  • 標準B:ビジネス分析(BA)

再現性のある出力、属人化しない

堅牢化・バージョン管理された生成スキルが、固定の出力スキーマと検証・修復(Mermaid図の自動サニタイズを含む)に基づいて全工程を駆動します。同じ入力なら、実行ごと・モデルごとに一貫した結果が得られ、プロンプトのノウハウが個人に閉じ込められることがありません。

  • バージョン管理されたスキル+出力スキーマ
  • 各セクションでの検証・修復
  • Mermaid図の自動サニタイズ

大規模コードベースに対応

スマートな除外ルールで node_modules・ロックファイル・ミニファイされたバンドル・バイナリ・一時ファイルを除外し、.gitignore も尊重します。ファイル数・バイト数のバジェットにより意味のあるソースだけをContext Windowに取り込み、実リポジトリでのContext Window超過を直接防ぎます。

  • .gitignore対応のスマート除外
  • 実行ごとのファイル・バイトバジェット
  • 実行はすべてContextバジェット内に収まる

担当範囲を絞り、精度を高める

依存関係の解析だけを担当するエージェントは業務ルールに気を取られず、その逆も同様です。

各工程を検証できる

エージェントごとに成果物を出力するため、結論の根拠をたどることができます。

コストを見通せる

大量のスキャンは低コストのエージェントが担い、高性能モデルは推論が必要な工程だけに使用します。

エンジン

一つのモデルに任せず、役割ごとに専任のエージェントを配置

2つのエンジン、1つのプロダクト。それぞれ固定構成のエージェント群が、単一の観点でコードベースを読み、結果を次へ引き渡します。下でエンジンを選ぶか、その下の比較表を読んでください。

Polyglot Engine

あらゆる言語、あらゆるドキュメント要件に

あらゆるコードベース → 必要な形式のドキュメント

言語を問わずZIPをアップロードし、出力標準を選択します。6つのエージェントが、章立てされた文書セットと、その内容から回答するチャットアシスタントを構築します。

  1. Crawler
  2. AbstractionIdentifier
  3. RelationshipAnalyzer
  4. ChapterOrderer
  5. ChapterWriter
  6. Composer

Mainframe Engine

COBOLリバースエンジニアリングと移行コンポーネント

COBOL → 業務ルール・業務フロー・移行コンポーネント

COBOLプログラムとコピーブックをアップロードすると、5つのエージェントが、これまで文書化されてこなかった業務ロジック・業務ルール・業務フロー・依存関係・移行単位を復元します。

  1. RepoScanner
  2. CobolAnalyzer
  3. BusinessLogicExtractor
  4. DependencyMapper
  5. ReportWriter

エンジンの選択

あなたのコードを読むのは、どちらか

両エンジンとも同じハーネスの上で動き、質問できるドキュメントに行き着きます。違いは、どこまで深く読むか、そして何を読むために作られたかです。

横にスクロールすると全体が見えます

Polyglot Engine速い汎用エンジン
Mainframe Engine高機能な専用エンジン
向いている用途
ドキュメントが追いついていないコードベース全般。言語は問いません。
アセスメント・ドキュメント化・移行準備の対象となる COBOL 資産。
入力
.zip または git リポジトリ。Java・C#・Python・VB6・TypeScript・COBOL ほか。
COBOL プログラムとコピーブックの .zip。Shift-JIS のソースも文字化けせずに読み取ります。
分析の深さ
抽象概念とその関係、そして抽象概念ごとの章。
DIVISION・段落・データ項目・業務ルール、そして CALL・COPY・I/O のすべてのエッジ。
エージェント
Crawler → AbstractionIdentifier → RelationshipAnalyzer → ChapterOrderer → ChapterWriter → Composer
RepoScanner → CobolAnalyzer → BusinessLogicExtractor → DependencyMapper → ReportWriter
出力
index.md と Mermaid 図付きの番号付き章、ダウンロード可能な zip、そして結果に対するチャットアシスタント。
相互リンクされたレポート一式、business-flows.json、dependency-map.json、移行単位のコンポーネント、そしてプロンプトと応答をすべて含む実行トレース。
対象の規模
単一サービスから大規模リポジトリまで。除外ルールとバジェットで、実行はContext内に収まります。
数本のプログラムから資産全体まで。スキャンモードが大規模リポジトリをコンポーネントに分割し、1つずつ解析できます。
相対的な所要時間
相対的なコスト
こんなときに選ぶ
システムの読めるドキュメントと、それに基づく回答が必要なとき。言語は問いません。
COBOL から業務ルールを復元し、依存関係グラフを作り、根拠のある移行の切り口が必要なとき。

グラフ

読むだけでなく、見て理解できるドキュメント

どちらのエンジンも、文章と同時にグラフを出力します。依存関係グラフ、業務フローとプログラムフロー、移行コンポーネント、実行トレース、そして描画される図です。形はソースの解析から生まれ、その周りの言葉をモデルが書きます。だからこそ、ここでのグラフはモダナイゼーション計画の土台にできます。

依存関係グラフ(階層)

プログラム、コピーブック、データファイルを一つの階層グラフに並べます。各エッジには生成元の命令(CALL、COPY、OPEN、READ、WRITE、CLOSE)が付き、ノードは種別ごとの色を保ちます。方向は左右と上下で切り替えられ、種別や関係で絞り込め、SVG または PNG に書き出せます。

エンジン
Mainframe
アプリ内
依存関係グラフ

グラフから AI-DLC へ

グラフから、モダナイゼーション計画へ

AI-DLC は TVJ の AI 駆動開発ライフサイクルです。チーム全員が同じものを指し示せる対象が必要で、文章はその役目を果たしません。これらのグラフがその対象です。何が存在し、何が何に依存し、次にどこまでなら安全に着手できるかを示すため、AI 支援のリライトを、要約ではなくシステムの実際の形から始められます。

AI-DLC を詳しく見る

01

理解する

依存関係グラフとフローを開きます。ファイルの集まりが、ハブ・クラスタ・受け渡しを持つ一つのシステムになり、議論がファイル名の話から離れます。

  • 依存関係グラフ(階層)
  • 依存関係グラフ(ネットワーク)
  • フォーカスと展開

02

決める

分割を読みます。外に出るエッジが少ないコンポーネントは、1チームで担える単位です。すべてと強く結び付いたコンポーネントは、見積もる前に読むべき警告です。

  • 移行コンポーネント
  • 依存関係グラフ(ネットワーク)

03

実行する

移行先コードを書くエージェントには、リポジトリ全体ではなく、1コンポーネントのプログラムフローと業務ルールを渡します。グラフがそのままスコープの定義になります。

  • プログラムフロー
  • 業務プロセスフロー
  • ドキュメントとチャットの図

04

検証する

結果をトレースと出典で確認します。回答には参照したレポート名が付き、呼び出しはすべてディスクに残り、構造はモデルの記憶ではなく解析から得られています。

  • 実行トレース(シーケンス)
  • 実行アーキテクチャマップ

形は解析、言葉は生成

ノード、エッジ、段落、判断、コンポーネントは、いずれもソースに対する決定的な抽出から生まれます。COPY・CALL・ファイル入出力の正規表現による事実抽出、段落グラフのための構文解析、分割のための連結成分とラベル伝播です。モデルは、そこにあるものを言葉にするだけで、形をつくり出しません。これが精度の根拠です。

描き直しにコストはかからない

どのグラフも実行がすでに書き出した成果物なので、絞り込み、フォーカス、レイアウト変更、書き出しはすべて手元の操作で、背後にモデルはいません。同じ実行を繰り返せば、キャッシュされた呼び出しが再生され、もう一度支払う必要はありません。

製品ツアー

アプリの中身

1つの実行を5つのビューで見ます。質問すると出典付きで回答が返り、依存関係グラフを開き、業務フローをたどり、実行が実際に読んだソースを確認し、エージェントの呼び出しをすべて再生できます。

PayrollBatch-COBOL

実行

  • PayrollBatch-COBOL
  • banking-service
  • inventory-api

処理パイプライン

1回のアップロードから、5つのステージでドキュメント化まで

両エンジンとも、同じハーネスの上で5つのステージを実行します。エンジンを選ぶと、そのチェーンをたどれます。一覧は画面に入ると自動で進み、操作するとその場で止まります。

ステップ 1/5
一時停止中

出力

出力を選び、実行が残したものを持ち帰る

実際の出力からの抜粋です。Polyglot Engineは選んだ標準に沿って目次と番号付きの章を書き出します。Mainframe Engineは相互リンクされたレポート一式と、機械可読な依存関係マップ、そして業務フローを出力します。

生成する前に出力を選ぶ

Polyglot Engineは2つの標準のいずれかで生成します。事前に選択することで、対象読者に合わせて構造・深さ・図表を最適化します。

STANDARD A

技術ドキュメント

エンジニア向けリファレンス:システム概要、アーキテクチャ、技術スタック、データモデル、詳細機能仕様。Mermaid図はテキストとして含まれます。

STANDARD B

ビジネス分析(BA)

ステークホルダー向けBA文書:概要、業務フロー、機能要件、ユースケース、ビジネスルール、用語集。

エンジン
出力標準
# ShopService - Technical Documentation

The API gateway routes every request to the order service, which authorises payment through an external gateway and persists the order through the repository layer.

## Table of Contents
1.[System Overview](01_system_overview.md)
2.[Feature List & Capabilities](02_feature_list.md)
3.[Tech Stack & Integrations](03_tech_stack.md)
4.[Architecture Design](04_architecture_design.md)
5.[Functional Design](05_functional_design.md)
6.[Database / Data Design](06_data_design.md)
7.[Detailed Feature Specifications](07_feature_specs.md)

1回の実行で得られるもの

Polyglot Engine

あらゆる言語、あらゆるドキュメント要件に

Polyglot Engineを開く

成果物

Mermaid図を含むMarkdownの章立て文書、ダウンロード用ZIP、生成された文書から回答するチャットアシスタント。

Mainframe Engine

COBOLリバースエンジニアリングと移行コンポーネント

Mainframe Engineを開く

成果物

業務・技術ドキュメント、business-flows.json、dependency-map.json、移行コンポーネント、そして実行トレース一式(すべてのイベント・プロンプト・応答)。

  • 数週間ではなく数分
  • 同じ入力なら同じ結果
  • すべてのモデル呼び出しを記録し、あとから再生できる

信頼度

どこまで信じ、どこを確認するか

エンジンは人より速く、そして一定の質で読み続けます。リポジトリの途中で疲れることもありません。それでも最後の判断者ではありません。どこが強く、どこで確認が要り、どこは人が署名するのかを示します。

エンジンが強い領域

ソースからのドキュメント生成
アーキテクチャとモジュール構成の把握
依存関係マッピング(CALL・COPY・I-O)
データモデルとファイルレイアウトの特定
業務ルールの抽出
業務フローの再構成
移行単位(コンポーネント)の提案

同じ作業を、2通りで

大規模コードベースの読解
システムアセスメント
移行アセスメント
技術ドキュメント作成

相対的な工数であり、実測値ではありません。実際に要する量は、リポジトリ・モデル・要求する深さによって変わります。

高い信頼度

  • プログラムとコピーブックの棚卸し
  • コールグラフとコピーブックの依存関係
  • ファイルとデータストアのI-Oマッピング
  • 部・段落・データ項目のレイアウト
  • ソースに基づく構造化ドキュメントの生成
  • 描画できるMermaid・PlantUML図
  • ファイルと見出しを示した回答
  • すべてのモデル呼び出しの記録

中程度の信頼度

  • プログラムを横断するデータフロー
  • ユーザーストーリー単位の業務フロー再構成
  • 手続き部から読み取った業務ルール
  • 移行コンポーネントの切り分け位置
  • 変更影響の評価

人による検証が必要

  • 業務ルールの解釈
  • ドメイン固有の要件
  • 組織のプロセス
  • コンプライアンス固有の判断
  • 戦略的なモダナイゼーション提言

AI支援の解析は最初の一巡であり、結論ではありません。エンジニアは、白紙のリポジトリを読むかわりに、記述されたシステムを相手に議論を始められます。すべての成果物は、移行やモダナイゼーションの判断に使う前にレビューされます。

主な成果

  • アプリケーション評価と発見の高速化
  • ソースから復元された業務ルール
  • 探索できる依存関係グラフ
  • プログラム単位・ストーリー単位の業務フロー
  • 計画の単位となる移行コンポーネント
  • 技術ドキュメントの自動生成
  • 出典を示す回答
  • 一貫し再現でき再生できる実行

主な機能

主要機能

両エンジンが共有するハーネスから受け取るもの。

モデルは自由。ホスト型でも自前でも

両エンジンとも OpenRouter 経由で Claude・Gemini・GPT・Grok・DeepSeek をはじめ、カタログにあるあらゆるモデルを利用できます。設定画面から OpenAI 互換のエンドポイント(自社ゲートウェイ、LiteLLM、vLLM、Ollama)に切り替えることもできます。既定モデルはエンジンごとに設定でき、実行ごとの上書きも可能です。

再現性のある構造化出力

バージョン管理された生成スキルが、固定の出力スキーマに沿って各実行を駆動します。セクションごとに検証と修復を行うため、同じ入力なら実行やモデルが変わっても同じ形のドキュメントになります。

描画される図

Mermaid と PlantUML はテキストとして生成され、描画の前にサニタイズされます。ドキュメントでもチャットの回答でも同じ扱いです。どの図も、絵としてもソースとしても読め、どちらの形でもコピーできます。

ドキュメントは日本語でも

ドキュメントは英語・日本語・ベトナム語で生成されます。チャットは質問した言語で回答します。訳されるのはラベルではなく中身です。

実行はライブで、記録も残る

ステージ・ファイル・チャンク・モデル呼び出しは、ジョブの実行中にそのまま流れてきます。同じ実行をエージェントのレーン・シーケンス図・ライブのアーキテクチャマップとして読め、表示の深さもコンパクト/詳細/ディープから選べます。終了後も呼び出しは1件ずつ開けます。送ったプロンプト、返ってきた応答、その間の再試行まで。

一式まるごと持ち出せる

成果物は相互リンクされた Markdown の zip としてまとめられ、どのウィキにもそのまま持ち込めます。実行そのものも、全イベントと全呼び出しを含むトレースとして書き出せます。

深掘り

エンジニア向け詳細:実装のなかみ

判断のために読む必要はありません。それでもエンジニアは必ず尋ねるので、答えを打ち合わせにせず、ここに置いておきます。各項目は個別に開き、次回の訪問でもその状態を覚えています。

アーキテクチャアーキテクチャ全体を1枚の図に。パケットが job.zip から完成したレポート一式まで進みます。展開
エージェントの協調同じ実行をシーケンスで。誰に依頼し、何が返り、どれがモデル呼び出しだったか。展開
ループの設計1回目でうまくいかなかったときの動き。出力打ち切り、レート制限、接続断、そして明確なエラー。展開
エンジンの仕組みエンジン内部の3層。ハーネス、エージェント構成、そして実行が生む2つのグラフ。展開
システム構成構成の全体像。ホスト上の Next.js アプリ、その隣の COBOL 解析サービス、両者の上のナレッジレイヤー。展開

ロードマップ

今後3か月の計画

2つのエンジンの周辺で、すでに着手または計画している4件です。画面を操作して読み取るシミュレーションエンジン、同じ解析深度をより短時間で行う改善、移行先向けの変換インプット、そして変換後の挙動が元と同じであることを示すテスト。

1か月目2か月目3か月目

開発中

  1. 人間の操作を再現するシミュレーションエンジン

    実際の利用者と同じようにアプリケーションを操作し、レガシーな Windows/Windows Server のデスクトップ・Web アプリの画面マップを自動生成します。要件とソースの突き合わせや、ソースが失われ実行モジュールしか残っていない資産のドキュメント復元にも使えます。

    1〜2か月目

  2. パフォーマンス改善

    同じ解析深度をより短時間で。並列度の向上・キャッシュ強化・呼び出し削減。

    2か月目

  3. Mainframe エンジンのコード変換支援

    復元した業務ルール・フロー・コンポーネントを、移行先プラットフォーム向けの変換インプットに変換します。

    2〜3か月目

計画済

  1. 単体・自動テスト生成エンジン

    復元した業務ルールから単体テストを、再構成したフローと画面マップから自動テストを生成します。変換後の挙動が元と同じであることを示すテスト一式です。

    3か月目

時期は目安です。スコープは案件ごとに確定します。

お問い合わせ

対象のコードベースについてお聞かせください。

言語・稼働年数・おおよそのファイル数など、課題の輪郭をお送りください。エンジンが読み取れる範囲と、初回実行の概算費用をご返信します。

お問い合わせ後の流れ

  1. 担当エンジニアより、通常1営業日以内にご返信します。
  2. 短時間のお打ち合わせで規模を把握し、成果物の範囲を決めます。
  3. サンプルコードでの試験実行。費用は事前に明示します。

メールをご希望の場合は、こちらへ直接お送りください。

tvj.sale@tinhvan.com
0 / 2000

送信することで、プライバシーポリシーに記載のとおり個人情報を取り扱うことに同意したものとみなします。

レガシーコードに、エンジンを向けるだけ。

リポジトリをアップロードして、モデルを選ぶ。本来あるべきだったドキュメントが、そこにあります。

Tinh Van Japan 株式会社