TypeScriptで書いているのに、気づけばコードがごちゃごちゃ…。
こんなこと、ありませんか？
「ちゃんと直したい気持ちはある。でも、どこから手をつければいいのか分からない。」
これ、かなり多くの人がハマるポイントです。
この記事では、
をまとめて紹介します。
読み終わるころには、
「よし、まずここを直してみよう」と1つ行動できる状態になります。
コードは才能ではなく、整え方です。
今日から一緒に、読みやすくて安心できるTypeScriptにしていきましょう。
なぜTypeScriptのコードは読みにくくなるの？
TypeScriptで書いているのに、「なんか読みにくい…」となること、ありますよね。
実はこれ、だいたい原因は決まっています。
「長い」「同じ」「any」が増える3つの理由
読みにくさの正体は、ほぼこの3つです。
① 関数が長い
1つの関数の中に、あれもこれも詰め込みすぎていませんか？
まるでランドセルに教科書もおもちゃも全部入れている状態です。
探すのが大変になります。
② 同じ処理があちこちにある
コピペで増えていったコード。
最初はラクですが、あとで1か所直すと「他も直さないと…」と地獄になります。
③ any が増えていく
とりあえず any にして動かす。
これは応急処置です。
型がゆるいと、間違いに気づけません。
直さないと何が困る？（バグ・レビュー・改修コスト）
「まあ動いているからいいか」と思いがちですが、放置するとこんなことが起きます。
部屋が散らかっていると、物を探すだけで時間がかかりますよね。
コードも同じです。
まずは「読みにくいサイン」に気づくこと。
それだけで、直す場所の当たりがつけられるようになります。
次は、「じゃあどこから直せばいいの？」に答えていきます。
まずはここから！リファクタリング5ステップ（チェックリスト）
「直したいけど、どこからやるの？」
ここで迷うと止まりますよね。なので、順番を固定しましょう。
まずはこの5ステップです👇
✅ ステップ1：目標を決める（読みやすさ／安全／重複削除）
いきなり直し始めないでください。
「今日は何を良くするのか」を決めます。
テーマは1つで十分です。
✅ ステップ2：怪しい場所を見つける（臭いのサイン）
次に、「どこが変か」を探します。
こんなサインはありませんか？
全部見ないで大丈夫です。1か所でOKです。
✅ ステップ3：小さく直す（1回で全部やらない）
リファクタは「ちょっとずつ」が基本です。
一度に大きく変えると、どこで壊れたかわからなくなります。
小さく、安全にです。
✅ ステップ4：型を強くする（any卒業）
TypeScriptの強みは「型」です。
いきなり完璧にしなくて大丈夫です。
ここが一番「将来ラクになる」ポイントです。
✅ ステップ5：動くことを確認する（テスト／ログ）
直したら、必ず確認します。
「きれい」と「正しい」は別です。
🔑 大事なのは「一度に全部やらない」
リファクタは掃除と同じです。
今日は机だけ。
明日は本棚だけ。
少しずつ整えるほうが、結果的に早いです。
次は、実際に「どう直すの？」を
前→後の具体例で見ていきましょう。
例でわかる：リファクタ前→後（TypeScript）
ここがいちばん大事なパートです。
「どう直すのか」を、前→後で見ていきましょう。
毎回この順番でいきます👇
- 困りごと
- 直し方
- 何が良くなったか
例1：anyをやめて型を作る（入力／戻り値）
❌ リファクタ前
function formatUser(user: any) {
return user.name + " (" + user.age + ")";
}
😓 困りごと
✅ リファクタ後
type User = {
name: string;
age: number;
};
function formatUser(user: User): string {
return `${user.name} (${user.age})`;
}
👍 良くなった点
いきなり完璧な型が作れないときは、
any→unknown- 中でチェック
- 最後に型を作る
という段階でもOKです。
例2：同じ処理を関数にまとめる（重複削除）
❌ リファクタ前
const total1 = price1 * 1.1;
const total2 = price2 * 1.1;
const total3 = price3 * 1.1;
😓 困りごと
✅ リファクタ後
function addTax(price: number): number {
return price * 1.1;
}
const total1 = addTax(price1);
const total2 = addTax(price2);
const total3 = addTax(price3);
👍 良くなった点
基準はシンプルです。
同じ形が3回出たら、まとめられないか考える。
例3：長い関数を小さく分ける（責任を1つに）
❌ リファクタ前
function handleOrder(order: any) {
// バリデーション
if (!order.user) throw new Error("no user");
// 合計計算
let total = 0;
for (const item of order.items) {
total += item.price;
}
// メール送信
sendEmail(order.user.email, total);
}
😓 困りごと
✅ リファクタ後
function validateOrder(order: Order) { ... }
function calculateTotal(order: Order): number { ... }
function notifyUser(email: string, total: number) { ... }
function handleOrder(order: Order) {
validateOrder(order);
const total = calculateTotal(order);
notifyUser(order.user.email, total);
}
👍 良くなった点
🧩 イメージは「箱に分ける」です。
- 入力
- 計算
- 出力
1つの箱に1つの役目。
これだけで一気に読みやすくなります。
例4：条件分岐のごちゃごちゃを整理する（早めに返す）
❌ リファクタ前
function getDiscount(user: User) {
let discount = 0;
if (user) {
if (user.isPremium) {
discount = 20;
} else {
discount = 5;
}
}
return discount;
}
😓 困りごと
✅ リファクタ後（早めに返す）
function getDiscount(user: User): number {
if (!user) return 0;
if (user.isPremium) return 20;
return 5;
}
👍 良くなった点
「ダメなケースを先に返す」と、スッキリします。
🎯 何を基準に「良い」と言えるの？
次の3つがクリアできていればOKです。
これがそろうと、読むのがラク＝直すのもラク になります。
次は、これをChatGPTにうまくやってもらう方法を紹介します。
ChatGPTにうまく直してもらう質問のしかた（プロンプト集）
ChatGPTって便利なんですが、聞き方がふわっとしてると、返事もふわっとします。
逆に、必要な情報をちゃんと渡すと「お、仕事できるやん」ってレベルで直してくれます。
まず渡す情報（目的・制約・入出力・例）
まずはこのテンプレでOKです。コピペして埋めるだけで精度が上がります。
✅ 小ワザ：「差分だけ出して」 って言うと読みやすいです。
✅ もう一つ：「テスト観点も出して」 って言うと安全になります。
コピペで使える基本プロンプト10個
目的別に置いておきます。必要なのをそのまま使ってください。
- anyをなくしたい（型を作って）
次のTypeScriptコードの any を減らして、適切な型（type/interface）を定義してください。
挙動は変えず、入力と戻り値の型は必ず明示してください。
修正後コードと、変更点の理由を箇条書きでください。
- いきなり型が難しいので段階的に（any→unknown→型）
any をいきなり厳密型にできないので、まず unknown に置き換え、
必要な型チェック（typeof や in など）を追加して安全にしてください。
最後に作れそうなら型定義案も出してください。挙動は維持してください。
- 重複を消したい（共通関数化）
次のコード内の重複処理を探して、関数にまとめてください。
呼び出し側は読みやすい名前にして、同じ挙動のまま短くしてください。
- 長い関数を分割したい（責任を1つに）
次の関数が長いので、役割ごとに小さな関数へ分割してください。
各関数の責任が1つになるようにし、命名も改善してください。
最後に「分割した理由」を箇条書きで説明してください。
- 条件分岐のネストを減らしたい（早めにreturn）
次の条件分岐を、ネストが浅くなるように整理してください（早めに return など）。
読みやすさ優先で、挙動は変えないでください。
- 命名を直したい（意味が通る名前へ）
次のコードの変数名・関数名が分かりにくいので、
意味が伝わる命名にリネームしてください。処理内容は変えないでください。
変更した名前の対応表も出してください。
- 例外処理を整えたい（境界チェック）
次のコードのエラー処理を見直して、安全な境界チェックを追加してください。
throw する場面と、戻り値で扱う場面を整理して提案してください。
- 型を強くしたい（戻り値をunionで安全に）
次の処理は失敗しうるので、戻り値を union 型（成功/失敗）で表現する案をください。
例：{ ok: true, value: ... } | { ok: false, error: ... }
既存の呼び出し側の修正も含めて提案してください。
- テスト観点も欲しい（壊してない確認）
次のコードをリファクタしたいです。挙動は変えません。
リファクタ案に加えて、最低限のテスト観点（ケース）を箇条書きで提案してください。
- PRレビューみたいに指摘してほしい
次の差分（またはコード）をレビューしてください。
指摘は「重要度（高/中/低）」を付け、理由と具体的な修正案もください。
観点：型安全、責任分離、重複、命名、例外、境界、可読性。
失敗しがちな頼み方と直し方（追加質問の型）
よくある失敗はこれです👇
❌「このコードきれいにして」
→ 何をどうしたいかが不明で、提案がブレます。
そこで、追加質問はこの型にすると強いです。
✅ 追加質問の型（コピペ用）
今の提案で、挙動が変わりそうな点はありますか？
変わる可能性があるなら、変えない案に修正してください。
✅ もっと短くしたいとき
可読性を落とさず、もう少し短くできますか？
「やりすぎ」になりそうな部分は注意点も添えてください。
✅ 型が怖いとき（安全側に倒す）
型は安全側に倒したいです。strict を前提にしても壊れないように、
不確かな値は unknown からチェックして扱う形にしてください。
✅ レビューで通したいとき
チームレビューで指摘されやすい点を先回りで潰したいです。
命名・責任分離・境界チェックの観点で、修正案を優先順位付きでください。
ちょい補足：ChatGPT（無料/有料）についての触れ方
ここは断定しすぎず、この記事ではこのくらいの温度感でOKです。
次は、ChatGPTを「レビュー担当」として使う手順にいきます。
チーム開発だとここがめちゃ効きます。
ChatGPTを「レビュー担当」にする手順（チーム開発向け）
チーム開発でよくあるのがこれです。
レビューで止まると、地味にダメージ大きいですよね。
そこでおすすめなのが、PR前にChatGPTに一度見てもらうことです。
PR前セルフレビュー手順（差分→指摘→修正）
流れはこれだけです👇
- 差分を用意する（変更部分だけ）
- 目的を伝える（挙動は変えない）
- 観点を指定する（後述）
- 指摘をもらう
- 修正して、もう一度確認
コピペ例：
次の差分をレビューしてください。
挙動は変えていません。
観点：型安全、責任分離、重複、命名、例外処理、境界チェック。
重要度（高/中/低）付きで指摘と修正案をください。
これだけで、かなり精度が上がります。
「指摘の質」を上げる指示（観点リスト）
ただ「レビューして」だと弱いです。
観点を固定すると、安定します。
おすすめ観点はこの7つです。
特に境界チェックは見落としやすいです。
外から入る値は疑う、これ大事です。
ルール化のコツ（チームで同じ基準に）
チームで使うなら、「これだけは守る」を3つに絞ります。
anyは原則禁止（どうしても必要なら理由を書く）- 1関数1責任
- 重複は3回出たら共通化検討
これをREADMEやWikiに書いておくだけでも、
レビューのブレが減ります。
補足：レビュー支援カテゴリ（ざっくり）
より強くしたい場合は、
と組み合わせるのがおすすめです。
多くは無料枠から始められます。いきなり有料にしなくて大丈夫です。
人ががんばる部分と、機械に任せる部分を分ける。
それだけで、チームのコード品質は一段上がります。
次は、機械に任せられる便利ツールを紹介します。
便利ツールでラクする（自動整形・静的チェック・テスト）
リファクタって、全部を人の気合いでやると疲れます。
なので、機械に任せられるところは任せましょう。
役割はこの3つです。
順番にいきます。
自動整形：Prettier
まずは Prettier です。
これは「見た目」を自動でそろえてくれるツールです。
地味ですが、効果は大きいです。
人によって書き方が違うと、
レビューで「そこじゃない」議論が増えます。
Prettierを入れると、
基本は無料で使えます。
まずはこれだけでも入れておくと、かなり平和になります。
ルールチェック：ESLint（TypeScript対応）
次は ESLint です。
これは「ルール違反を止める」係です。
例えば：
TypeScriptと組み合わせることで、
型まわりもチェックできます。
人が気づく前に、機械が怒ってくれる
レビュー前にエラーが出るので、
手戻りが減ります。
これも基本は無料で始められます。
型の力を引き出す：tsconfigの考え方
TypeScriptは、設定しだいで「やさしくも、きびしくも」なります。
おすすめは、
まずは新しいファイルから厳しくする、など段階的にいきましょう。
「怖いからゆるくする」より、「少しずつ強くする」が正解です。
テスト：最低限ここだけ（回帰を防ぐ）
最後はテストです。
たとえば Vitest や
Jest があります。
全部を完璧に書く必要はありません。
最低限これだけでもOKです。
「前と同じ結果になる」ことを確認する
これがあると、安心してリファクタできます。
🎯 まとめると
全部、基本は無料で始められます。
人ががんばるのは「設計」。
細かいチェックは機械に任せる。
これだけで、コードの安心感が一気に上がります。
次は、よくある不安をサクッと解消していきます。
まとめ：今日からできる最短ルート
ここまで読んでくださったなら、もう準備OKです。
やることは、たった3つだけです。
✅ 今日やる3ステップ
- チェックリストを見る
- まずは「長い・同じ・any」のどれか1つを選びます。
- 例のどれか1つをマネする
anyを型にする- 同じ処理を関数にまとめる
- 長い関数を分ける
完璧じゃなくていいです。1か所で十分です。
- ChatGPTにレビューしてもらう
- 「挙動は変えていません。危ない点ありますか？」
これを聞くだけで安心感が変わります。
- 「挙動は変えていません。危ない点ありますか？」
🎯 大事なのは「小さく続ける」
リファクタは、一発で終わるイベントではありません。
これだけで、数週間後には別物になります。
コードは才能ではありません。
整え方を知っているかどうかです。
まずは今日、1つ直してみてください。そこから全部、変わり始めます。
よくある質問
- Qリファクタって、いつやるのが正解ですか？
- A
結論：機能追加やバグ修正の“ついで”がベストです。
理由はシンプルで、その部分をすでに触るからです。
別のタイミングでやろうとすると、後回しになります。👉 まずやること：
修正する関数だけ、ついでに1つ整えてください。
- Qコードが大きすぎて、どこから手をつければいいかわかりません…
- A
結論：一番短くできそうな場所からです。
いきなりラスボス級の巨大ファイルに挑むと挫折します。
👉 まずやること：
- 30〜50行くらいの関数を探す
anyが1つだけある場所を直す
「勝てる戦い」から始めるのがコツです。
- Q型を厳しくしたらエラーが大量に出ました。どうすれば？
- A
結論：一気にやらないでください。
エラーが100個出ると心が折れます。
👉 まずやること：
strictは段階的にany→unknownに置き換える- 新規ファイルから厳しくする
“全部直す”ではなく、“増やさない”が最初の目標です。
- QChatGPTの提案が毎回ちょっと違います。どれを信じれば？
- A
結論：一番シンプルで説明が明確な案です。
リファクタは「正解1つ」ではありません。
でも、説明できない変更は危険です。👉 まずやること：
「なぜこの変更が良いのかを箇条書きで説明して」と追加で聞いてください。
理由が弱い案は採用しなくてOKです。
- Qリファクタで逆にバグを出すのが怖いです…
- A
結論：だから小さくやるんです。
100行書き直すから怖いんです。
5行なら怖くありません。👉 まずやること：
- 1関数だけ直す
- 実行してログ確認
- 可能なら簡単なテストを書く
「きれいにする」と「壊さない」はセットです。