PHPから抜け出したいが、中身が分からない
2026年10月に公表されたPHPの重大な脆弱性のように、言語や基盤の問題がそのまま事業のリスクになっています。PHPのレイヤをなくしてモダンなアーキテクチャへ移行したいが、いまの処理を正確に把握できていない。
KEEPALIVE / AI-READY
AI-Ready.
AI-Readyモダナイゼーション
古くなったシステムの「図面」を描き直し、AIと一緒に変えていける状態へ。
こんなお悩みは
ありませんか？
長く使ってきたシステムほど、中身を知る人や正しい資料が少なくなりがちです。いまの姿を正しく描いた図面があれば、新しいアーキテクチャへの移行も、業務ロジックのAPI化も、確かな土台の上で進められます。
よくある4つのお悩み
業務ロジックがAPIになっていない
業務のルールが画面やバッチのプログラムに埋もれていて、AIエージェントから呼び出せる形になっていない。このままでは、AI活用の準備が整わない。
説明書がいまのシステムと合わない
改修を重ねるうちに説明書の更新が追いつかず、書かれている内容と実際の動きが食い違っている。移行や改修の前提にできる資料がない。
詳しい人がいないと改修できない
システムの中身を知る人が限られ、その人が不在だったり退職したりすると、改修が止まってしまう。
01WHAT WE DO
システムの図面を、
いまの姿で描き直す。
長く使ってきたシステムは、増改築を重ねた建物に似ています。図面が古いままだと、リフォームのたびに壁を壊して中を確かめることになります。私たちは、いまの建物を実際に調べて図面を描き直し、AIにも人にも読める形に整えます。図面が正しければ、改修をAIに安心して任せられるようになります。
3つの約束
いまの実物から書き起こす
古い資料ではなく、実際に動いているシステムを調べて書きます。
分からないことは書かない
推測で埋めず、確かめられなかった点ははっきりお伝えします。
本当に正しいか確かめる
描き直した図面だけでシステムを再現できるかを、AIを使って検証します。
02WHY IT WORKS
なぜ、
うまくいくのか。
描き直した図面が本当に正しいかは、読んだだけでは分かりません。そこで私たちは、図面だけを頼りにシステムを作り直し、元のシステムと比べることで正しさを確かめます。これを「可逆性検証」と呼んでいます。
たとえるなら、描き直した図面だけを、元の建物を見たことのない大工さんに渡して、図面どおりに建ててもらうようなものです。比べるのは見た目の仕上げではなく、間取りや配管・配線のつながりが元の建物と同じかどうかです。違う部分があれば、それは図面の書き漏れや誤りなので、図面を直してもう一度確かめます。
可逆性検証の流れ図面だけで作り直し、新旧を比べる
- 図面を描くいま動いているシステムを調べ、AIと一緒に図面（設計書）を描きます。
- 図面だけで作り直す元のシステムを見せていないAIに、図面だけを渡してプログラムを作り直させます。
- 新旧を比べる作り直したプログラムと元のプログラムを、処理の順番・条件・扱うデータの単位で照らし合わせます。
- 違いがあれば図面を直す違いが見つかったら、その原因になった図面の書き漏れや誤りを直します。
02〜04を、新旧の違いがなくなるまで繰り返します。
うまくいく3つの理由
書き漏れが必ず表に出る
元を見ていないAIは、図面に書かれていないことを再現できません。そのため、図面の書き漏れや誤りが、新旧の「違い」としてはっきり表に出ます。
人の目に頼らず確かめられる
読み合わせのレビューでは、どうしても見落としが生まれます。作り直して比べることで、人の注意力に頼らずに正しさを確かめられます。
繰り返すほど図面が正確になる
違いを見つけては直す、を繰り返すことで、図面は少しずつ元のシステムに近づき、最後には図面だけでシステムを再現できる状態になります。
03HOW IT WORKS
進め方
お客様にお願いすることは、業務のご説明と資料のご用意、内容のご確認です。調査と書き起こしは当社が行います。
- ご相談対象の範囲と進め方を決めます。お客様にお願いすること業務とシステムの概要をお聞かせください。
- 準備調べ方と書き方のルールを、お客様のシステムに合わせて整えます。お客様にお願いすることソースコードと既存の資料をご用意ください。
- 書き起こしAIと一緒にシステムを調べて書き起こし、正しさを確かめます。お客様にお願いすること途中経過をご確認いただきます。
- お渡しできあがった設計書をお渡しし、使い方や引き継ぎを支援します。お客様にお願いすること内容をご確認ください。
04WHAT CHANGES
導入後に変わること
BEFORE中身を知る人しか改修できない
AFTER担当者が替わっても引き継げる
システムの中身が書き残されるので、特定の人に頼らずに済みます。
BEFORE改修のたびに、いちから中身を調べ直す
AFTER改修のたびの調査を減らせる
正しい図面があれば、毎回いちから中身を調べ直す時間と費用を抑えられます。
BEFORE正しい仕様がなく、AIに任せられない
AFTERAIに任せる準備が整う
AIが読める正しい図面があることで、保守や改修をAIと進められるようになります。
05DURATION
期間の目安
業務領域4つ程度の中規模システム（画面100前後・テーブル200前後・API250前後）の場合、3名体制でおよそ1〜1.5か月が目安です（立ち上げ期間を含みます）。同じ範囲を手作業で書き起こすと、一般に数か月〜1年規模の作業になります。
対象システムの構成や既存資料の状況により変わります。費用は対象範囲に応じて個別にお見積りします。
FAQ.よくあるご質問
社内にITに詳しい人がいなくても頼めますか？
はい。技術的な調査と書き起こしは当社が行います。お客様には、業務のご説明と、ソースコードや既存資料のご提供、できあがった内容のご確認をお願いしています。
いま動いているシステムを止める必要はありますか？
調査はソースコードと既存の資料を読み取って進めるため、稼働中のシステムに手を加えることはありません。
どのくらいの期間がかかりますか？
中規模システムで、3名体制の場合およそ1〜1.5か月が目安です。対象の範囲をうかがったうえで、個別にお見積りします。
TECHNICAL DETAILS技術詳細（進め方と成果物）
目指す状態
AIが確実に読める
機械が読み取れる構造で書き、AIが誤解せずに仕様を理解できるようにします。
人がレビューしやすい
AIがつくった設計書を、人が短時間で確かめられる構成と表示にします。
コードと往復できる
設計書からコードを、コードから設計書を、互いにたどり直せる状態をつくります。
6つの原則
ソースコードが正
既存の設計書ではなく、実際に動いているコードを唯一の根拠にします。
バグもそのまま書く
現在の挙動をありのままに記録し、不具合や懸念は「指摘事項」として分けて残します。
出典を必ず示す
すべての記述から、根拠となるソースコードの箇所をたどれるようにします。
意味と見た目を分ける
機械が読むための構造と、人が読むための表示を分けて設計します。
JavaScriptが無くても読める
どの環境でも、AIでも人でも、設計書の全内容を読めるようにします。
推測で埋めない
コードから確かめられないことは、分からないこととして明示します。
4つの工程
- 調査対象の処理に関係するクラス・テーブル・呼び出し元を、ツールで洗い出します。
- 設計書の作成記述ルールに沿って、AIと人が読めるHTML設計書をつくります。
- 形式チェックルール違反や記載漏れを、チェックツールで機械的に検出します。
- 可逆性検証元のコードを見ないAIに設計書だけからコードを再生成させ、元のコードと論理的に比較します。
お渡しするもの
AI-Ready設計書
概要・API仕様・処理概要・指摘事項・テスト・可逆性検証・トレーサビリティを1つにまとめたHTML設計書。
検証の証跡
設計書から再生成したコードと、元のコードとの比較結果。
記述ルールとチェックの仕組み
内製化支援（Consourcing）と組み合わせ、設計書を書き続けるためのルールとツールをチームに引き継ぎます。
NEXTLET’S TALK
サービスに関するご相談をお待ちしています。
お問い合わせ