LEGACY SYSTEM AI STUDIO
HyCortex ／ レガシーシステムAI工房
大規模レガシーの保守で分かったことを、組織の資産として残し、AIに正しく使わせます。
既存のリポジトリ、設計書・手順書・帳票、過去の対話を取り込み、コードグラフ・LLM Wiki・スキル・対話メモリという、版と公開範囲と装備先を持つ資産に変えます。
既存の接続先をプロキシへ向けるだけで、Claude Code や Codex などのコーディングAIが、セッションの開始時にその資産を装備した状態になります。プロトコルは変わらず、プラグインの開発も要りません。
知識の置き場所が人であるかぎり、保守の工数は減らない
止めているのは技術スタックではありません。経済産業省が2018年の『DXレポート』で示した「2025年の崖」── 既存システムの老朽化と複雑化により、2025年以降に最大12兆円／年の経済損失が生じうるという試算 ── は、刷新しても形を変えて残ります。現場では次の四つが同時に起きています。
禁則、例外、過去の障害の経緯は、コードにも設計書にも残りません。頭の中に持っている人が退職・異動した時点で消え、残った人は同じ調査をやり直すことになります。
数十万行から数百万行の中で、どこを直すとどこが動くのかが見えません。現行踏襲のつもりで見誤ると、そのまま品質事故になります。
契約と検収は設計書で行うのに、実装だけが先へ進みます。項番と実装が食い違ったまま、どちらが現行なのか誰にも言えなくなります。
命名、禁則、帳票の様式は案件ごとに違います。手順が人についたままなので、担当が代わるたびに覚え直しから始まります。
資産をそろえてから着手し、作業のたびに資産が増える流れ
最初の仕事を「プロジェクトの再学習」にしないために、必要な資産を先に用意してから作業へ入ります。作業で分かったことは、その場で資産へ戻ります。
取り込みが終われば、コードグラフと LLM Wiki は非同期で使い始められます。三本の道がすべてそろうのを待つ必要はありません。
関門では人が中身を見ます。公開できないと判断したものは装備しないので、自動で全公開にはなりません。
メモリを持たないループは、同じ調査を速く繰り返すだけになります。還元の一歩が、この流れの要です。
次の改修が、前回の調査から始められる仕組み
01 の四つは、どれも「知識の置き場所が人である」という同じ原因から出ています。置き場所を資産へ移すと、引き継ぎは前回の続きから始まり、調査は全文を読まずに済み、いま使っている道具も替えずに済みます。
対話メモリは、好み・事実・決定・禁則を階層に分けて持ちます。チャットの履歴に頼らないので、セッションを切り替えても、担当が代わっても、同じ前提から再開できます。
「旧認証はモバイルがまだ使っている」のような、資料のどこにも書かれていない前提を、人が毎回口で伝える必要がなくなります。有識者の頭にあった禁則が、退職や異動で消えなくなります。
コードグラフは、記号・呼び出し関係・影響経路をコードの構造として持ちます。改修の起点を指定すると、そこから辿れる先を階層をさかのぼって並べ、要対応・要確認・影響なしの三つに分けて返します。
数十万行から数百万行を人が読み通す必要はありません。ファイルごとの要約も併せて持つので、はじめて触るモジュールでも、そこが何をしている場所なのかを先に把握できます。
新しいIDEを全員に配る話ではありません。既存の接続先をプロキシへ向けるだけで、Claude Code や Codex などが、セッションの開始時にスキル・Wiki・グラフ・メモリを装備した状態になります。プロトコルは変わらないので、プラグインの開発も要りません。
コーディングAIを開かない人には、コンソール上のチャットアプリという別の入口があります。調査・運用・レビュー・協力会社が、同じ Wiki と同じグラフを根拠に質問できます。入口は二つでも、成果はどちらもスキルとメモリへ戻るので、ナレッジは割れません。
四つの資産 ── 何を構造にして、何ができるようになるか
資産は保存されたファイルではありません。版と公開範囲と装備先を持ち、所有者と状態で管理して、必要なら取り下げられます。
資産の管理、組み分け、権限、装備の設定は、お客様の環境に置いたコンソールで一元的に行います。
LLM を呼ぶのは抽出・要約・回答のときだけです。コード全文を常に外へ送る作りにはなっていません。
公開範囲は資産ごとに、本人だけ・チーム・限定・エージェントの4段で決めます。所有者・版・状態が付いているので、あとから取り下げれば装備先の複製も外れます。
コーディングAIそのものは当社が作るものではありません。置き換えるのではなく、土台として資産を装備させるところまでを担います。応答の品質は、お使いのモデルに依存します。
取り込んだものが自動で全員に公開されることはありません。人が中身を見てから装備する手順を挟むので、そのぶんの工数はかかります。
定量評価を行ったのは、導入済み4現場のうち2現場です。残る2現場は調査と成果物作成の日常業務で継続して使っていますが、測定は行っていません。
現場Aの数字は工程全体の効果、現場Bの数字はコーディングAI単体との差分です。口径が違うので足し合わせられません。「独力対応までの期間」は体感であって、計測値ではありません。
4現場での導入と、うち2現場で測った効果
導入済みは4現場、定量評価を行ったのは2現場です。工程全体で測ったものと、コーディングAI単体と比べたものを、混ぜずに並べます。
現場A ── 大規模パッケージ保守で、工程全体を測った
| 領域と指標 | 導入前 → 導入後 | 効果 |
|---|---|---|
| 仕様調査 ── 現行仕様の調査時間 | 10H／件 → 6H／件 | 40% 短縮 |
| コード品質 ── レビュー指摘密度（CDI） | 5.78 件／KL → 3.89 件／KL | 32% 改善 |
| 生産性 ── 詳細設計書作成〜実装完了 | 0.55 KL／人月 → 0.72 KL／人月 | 30% 向上 |
| 手戻り ── 指摘対応時間（CD） | 12.75H／KL → 7.5H／KL | 41% 削減 |
| 立ち上がり ── 独力対応までの期間 | 1年以上 → 3ヶ月 | 体感 |
十数年運用の大規模パッケージ保守（VB.NET／C#、約12,000 KL）での実測値（2026年8月時点）。調査時間は5件の平均です。「独力対応までの期間」だけは計測値ではなく担当者の体感で、資料でもそう明記されています。KL は1,000行、CDI はレビュー指摘密度、CD は指摘対応時間を指します。
現場B ── 大規模 Java レガシーで、コーディングAI単体と比べた
| 作業 | 効果 |
|---|---|
| プロジェクト専用スキルの構築 | 2ヶ月 → 3週間 |
| 専用スキルを使ったコード作成 | 約1.5倍（50% 向上） |
| 専用スキルを使ったテスト仕様書の作成 | 30% 短縮 |
| コーディングAIへの1回の問い合わせトークン | 35% 削減 |
| 依存関係の調査時間 | 50% 短縮 |
250万行超の Java レガシーで、第三者のコーディングAIに本ソリューションを接続し、AI単体の状態と比べた実測値（2026年8月時点）。上の現場Aは工程全体の効果なので、口径が違います。足し合わせないでください。
導入の規模
NEXT
ご相談は、担当者までご連絡ください。
対象を一つ指定いただければ、成果物とその検証レポートを実物としてご提示します。
この方式が有効かどうかは、件数の説明ではなく、ご自身のシステムから出てきた成果を見ていただくのが最短です。
対象を一つお知らせいただくところから始まります。