引き継いだ既存システムの構成図を画面に表示し、AIと対話しながら設計の意図を読み解こうとしている開発者
設計・レビューでのAI活用約14分

既存設計の問題点をAIに説明させる｜理解を深める使い方

「このシステム、なんでこんな作りになってるんだろう」。 前任者が去ったあとの引き継ぎ、あるいは久しぶりに触る古いコード。動いてはいるけれど、設計の意図が読めない。直したいけど、下手にいじると何が壊れるか分からない——そんな夕方、ありますよね。

そういうとき、AIは「既存の設計を説明してくれる相手」になります。 ただ、ここで気をつけたいことがひとつ。「この設計、直しといて」と丸ごと任せるのではなく、まず「なぜこうなっているのか」「どこに弱点があるのか」を説明させて、自分が理解する。順番はこちらが先です。理解しないまま直すと、意図があってそうなっていた部分まで壊してしまうことがあります。

この記事は、AIを「設計を直す人」ではなく「設計を読み解く手伝いをしてくれる人」として使うための、問いの立て方の話です。既存設計への理解を、一緒に一段深めていきましょう。

結論：既存設計を理解したいときは、①まず設計の現状と意図を説明させる → ②問題点と、その理由を挙げさせる → ③「なぜあえてこうしたか」というgood reason（善意の理由）も考えさせる → ④指摘を一次情報（実際のコード・データ）で確かめる → ⑤直すかどうかは理解したうえで自分が決める、の順で問いを立てます。AIに批評させるのが目的ではなく、自分の理解を深めるための説明役として使うのがコツ。指摘は必ず裏を取ります。

既存の設計には、たいてい理由があります。 その理由ごと理解してから直すと、壊さずに前へ進めます。

「直して」より「説明して」から始める理由

いきなり修正を任せる進め方と、まず説明させて理解してから直す進め方を左右に並べ、壊すリスクの差を示した比較図

既存の設計を前にすると、つい「どこが悪いか教えて、直して」と聞きたくなります。 気持ちは分かります。早く分かるようになりたいし、早く直したい。でも、この聞き方には落とし穴があります。

既存設計でいちばん怖いのは、悪い設計を放置することより、理由を理解しないまま触って、動いていたものを壊すことです。「なぜか動かなくなった」の多くは、意図を読み違えた手直しから生まれます。

だから、順番を変えます。 まず説明させて、自分が理解する。問題点も、その理由も、言葉にしてもらう。そのうえで、直すかどうかを自分で決める。AIの役割は、理解の手伝いまで。ここを外さないだけで、既存設計との付き合いがずいぶん落ち着きます。

理解を深める4つのステップ

先に流れを出します。この順で問いを重ねると、AIが「批評する人」から「理解を助ける人」に変わります。

ステップ問いの狙いひとことで言うと
①現状と意図を説明させる全体像をつかむ「これは何をしてる？」
②問題点と理由を挙げさせる弱点を言葉にする「どこが苦しい？なぜ？」
③あえての理由も考えさせる早合点を防ぐ「わざとかもしれない所は？」
④一次情報で確かめる思い込みを外す「本当にそうか、コードを見る」

ポイントは、②で止めないことです。 問題点を聞いて「なるほど直そう」と進みたくなりますが、③と④を挟むことで、AIの一般論を自分の現場の事実に近づけられます。1つずつ見ていきましょう。

なお、この流れはチャットに図やコードを貼るだけでも回りますが、Claude Code・Cursor・GitHub Copilot のような CLI／エージェント型の道具を使うと、実際のコードを読ませたうえで説明させられる分、的外れが減ります。既存コードの文脈をうまく渡すやり方は既存コードにAIを馴染ませる文脈の渡し方にまとめました。

ステップ1：まず「現状と意図」を説明させる

最初にするのは、問題探しではなく全体像の把握です。 いきなり「悪い所は？」と聞くと、細かい欠点の羅列が返ってきて、木を見て森を見ずになります。まずは、この設計が何をしようとしているのかを、自分の言葉で言えるようにします。

聞き方の例：

この設計（構成図／コード）が、全体として何をしているのかを、
初めて見る人にも分かるように説明してください。
- 大きな役割ごとの分かれ方
- データがどこから来てどこへ行くか
- この設計が達成しようとしているとみられる目的
まだ良し悪しの評価はしなくて大丈夫です。

「まだ評価しないで」と添えるのがコツです。 そう言わないと、説明のふりをして批評が混じり、事実と意見の区別がつきにくくなります。まずは中立に、地図を描いてもらう。その地図が、後で問題点を位置づける土台になります。

返ってきた説明は、自分の理解と照らし合わせながら読みます。 「ここは合ってる」「ここは自分の認識と違う」を見つけるだけで、既存設計への解像度が上がります。違いを見つけたら、それはコードで確かめるポイントです。

ステップ2：問題点と「その理由」を挙げさせる

全体像がつかめたら、次に「どこが苦しいか、なぜ苦しいか」を挙げてもらいます。 ここで大事なのは、問題点だけでなく理由をセットで言わせることです。理由がないと、直す価値の判断も、人への説明もできません。

聞き方の例：

この設計で、保守や変更のときに苦しくなりそうな点を挙げてください。
それぞれについて、次をセットで。
- 何が問題か（具体的に、どの部分か）
- なぜ問題か（どういうときに、どう困るか）
- 放っておくとどうなりそうか
深刻そうな順に並べてください。

「なぜ問題か」を必ず言わせると、指摘の重みが見えてきます。 「今すぐ困る」のか「いつか困るかも」なのか。「毎回の修正で地味に効く」のか「めったに触らないから実害は小さい」のか。全部を直す必要はありません。自分の現場で本当に効く問題はどれかを、理由から見分けます。

この段階で出てきた指摘は、まだ「AIの見立て」です。 正しいかもしれないし、的外れかもしれない。判断は次のステップに回します。

ステップ3：「あえてこうした理由」も考えさせる

問題に見える設計の裏に、過去の障害対応や外部連携の都合といった隠れた理由が隠れている様子を示した概念図

ここが、このやり方のいちばん大事なところです。 問題点が出そろったら、今度は逆に「これは、あえてこうした可能性はないか」を考えさせます。いわゆる good reason（一見おかしく見えても、実は妥当な理由がある）を探す問いです。

聞き方の例：

いま挙げた問題点について、逆の見方もしてください。
「一見おかしく見えるが、当時の事情を考えると、あえてこうした可能性がある」
というものはどれですか。考えられる善意の理由を挙げてください。
（例：過去の障害への対処、外部システムの制約、納期優先の妥協、
　当時のライブラリの都合 など）

なぜこれを挟むか。 既存の設計には、その場に居なかった人には見えない事情が織り込まれていることが多いからです。「なんでこんな冗長な作りに」と思ったら、過去に一度データが壊れた対策だった。「なぜここだけ古いやり方」と思ったら、外部システムがそれしか受け付けなかった。こういう理由は、コードのコメントにも残っていないことがよくあります。

AIに善意の理由を挙げさせると、「直すべき問題」と「触ってはいけない事情」を分けて考える癖がつきます。 もちろん、AIが挙げる理由も推測です。当たっているとは限りません。でも「そういう可能性もあるのか」と一度立ち止まるだけで、勢いで壊すのを防げます。当時を知る人がまだ社内にいるなら、ここで挙がった仮説を持って、ひとこと確認しにいくのが確実です。

ステップ4：指摘を「一次情報」で確かめる

AIの説明も、問題点も、善意の理由も、すべて画面に渡した情報からの推測です。 だから、動く前に実際のコード・データ・設定で裏を取ります。ここを飛ばすと、AIの一般論を自社の事実と勘違いしたまま進んでしまいます。

確かめ方は、むずかしくありません。

AIは、それらしい断定を自信ありげにします。もっともらしいのに事実と違う、いわゆるハルシネーション（もっともらしい誤り）も混じります。見抜き方はAIのハルシネーションの見抜き方にまとめましたが、いちばん確実なのは、自分の目でコードを見ることです。エージェント型の道具を使っているなら、気になる箇所だけAIに読み直させて、該当行を示させると早く確かめられます。

裏が取れた指摘だけが、「理解した問題点」になります。 取れなかったものは、保留にしておいて大丈夫です。無理に全部を白黒つけなくて構いません。

直すかどうかは、理解したうえで自分が決める

ここまで来ると、既存設計への理解がずいぶん深まっているはずです。 何をしているか、どこが弱いか、なぜそうなっているか、どこは触ってはいけないか。この理解こそが、この記事の目的でした。

そのうえで、直すかどうかは自分で決めます。 理解したからといって、全部を直す必要はありません。「今は触らない」も立派な判断です。むしろ、動いているものを理由もなく作り替えるほうが、リスクが大きいこともあります。直すと決めた部分については、変更の差分を丁寧に確認しながら進めます。

どの指摘をどう扱うかの線引きは、AIレビューの指摘を取捨選択する判断軸の考え方がそのまま使えます。 理解したうえで「触らない」と決められること。それも、既存設計と付き合う立派な成果です。

ありがちな落とし穴と、その回避

既存設計の読み解きでつまずきやすい所を、先に潰しておきます。

落とし穴のほとんどは、「AIに答えてもらって、早く片付けよう」とした瞬間に生まれます。 「AIと一緒に、既存設計を読み解く」に意識を変えるだけで、多くは避けられます。

明日からやること（小さく始める3つ）

いきなり全部やろうとせず、まずこの3つから。

  1. 分からない既存コードを、まず「これは何をしてる？」とAIに説明させる：評価は後回しで、全体像から。
  2. 問題点を聞いたら、続けて「あえてこうした理由は？」と聞く：早合点を防ぐひと呼吸。
  3. AIの指摘を1つ、実際のコードで確かめる：裏を取る癖が、思い込みを外します。

この3つだけでも、引き継いだシステムと向き合う気持ちが、少し軽くなります。

コピーして使う「既存設計の読み解きテンプレ」

分からない既存設計に出会ったら、上から順に問いを重ねてください。一度に全部でなく、必要な所から使えば十分です。

# 既存設計の読み解き

## ① 現状と意図（最初に）
「この設計（図／コード）が全体として何をしているか、初めて見る人にも
 分かるように説明してください。役割の分かれ方・データの流れ・目的。
 まだ良し悪しの評価はしないでください。」

## ② 問題点と理由
「保守や変更で苦しくなりそうな点を、深刻な順に。
 それぞれ『何が』『なぜ問題か』『放置するとどうなるか』をセットで。」

## ③ あえての理由（good reason）
「いま挙げた点のうち、当時の事情を考えるとあえてこうした可能性が
 あるものは？ 考えられる善意の理由を挙げてください。」

## ④ 一次情報で確認（自分の手で）
- AIの指摘のうち、コード／データで裏を取る項目：
- 確かめた結果（合っていた／違った／保留）：

## ⑤ どう扱うか（自分で決める）
- すぐ直す：
- 記録して保留：
- 触らない（理由）：

読み解き前後のチェックリスト

理解を深める前と、直すかを決める前に、さっと確認します。全部に○が要るわけではなく、関係する所だけで十分です。時間がない日は、太字の2つ——「意図を自分の言葉で言える」「指摘を1つはコードで確かめた」——だけ押さえれば及第。残りは余裕があるときの確認項目だと思ってください。

理解を深めるとき

裏を取るとき

直すかを決めるとき

最後に

引き継いだシステムと向き合うのは、心細いものです。 なぜこうなっているか分からない、下手に触れない、でも直さないといけない。前任者はもういないし、聞ける人も少ない。その状況は、簡単には変わらないかもしれません。

でも、答えを写すためでなく、一緒に読み解く相手としてAIを使えば、ひとりで抱えていた既存設計に、もうひとつの光が当たります。

既存設計の意図と弱点を理解し終え、次にどこを直すか落ち着いて見通せるようになった開発者

全部を一度に理解しなくても、今日ひとつ「これは何をしてる？」と聞けたなら、それはもう、分からないまま触る怖さを少し減らす一歩です。 既存設計を読み解けたら、新しく設計するときの相談にもAIは使えます。その型はAIを設計の壁打ち相手にするに、設計レビューで見落としを洗う型は設計レビューの見落としをAIに洗わせるにまとめました。読み解く・考える・洗う。この3つがそろうと、設計との付き合いがずいぶん落ち着きます。

よければ、こちらも

関連用語