AIに型エラーを直させるとanyが増える｜安全な直し方の型
エディタに真っ赤な型エラー。とりあえずAIに「このエラー直して」と投げたら、一瞬で消えた。 助かった——と思ったのも束の間、差分をよく見ると、変数に any がついていたり、as で型を押し通していたり。エラーは消えているのに、なんだかスッキリしない。そんな経験、ありますよね。
厄介なのは、型エラーは「消す」だけならいくらでも消せてしまうこと。any をつける、as でキャストする、@ts-ignore で黙らせる。どれも赤い波線は消えます。でも、それは型が守ってくれていた安全網ごと外している、ということでもあります。
この記事は、AIに型エラーを直させるときに「消しただけ」を「ちゃんと直した」に変えるための型をまとめたものです。長く見えますが、全部は要りません。まず「差分に any・as・@ts-ignore が増えていないか見る」だけ持ち帰れば、今日から危ない直し方に気づけます。
30秒のファストパス（最低ライン）
- 原因を先に聞く：「直して」の前に「なぜこの型エラーが出ている？」を一度聞く
- 黙らせ系を数える：直したあとの差分にany/as/@ts-ignoreが増えていないか目で確認する
- 1つでも増えたら聞き返す：「anyを使わずに正しい型で直せる？」ともう一度頼む
※型エラーは「消えたか」ではなく「型で守れているか」で見る。消すだけなら誰でもできる、が合言葉。
結論：AIは型エラーを消すのは速いけれど、いちばん楽な消し方（any・as・@ts-ignore）を選びがちです。だから、①「なぜ出ているか」を先に説明させる → ②「黙らせずに正しい型で直して」と条件をつけて頼む → ③直したあとの差分でany/as/@ts-ignoreが増えていないかを数える → ④増えていたら「これは本当に型を諦めるしかない箇所か」を確かめる、の順で見ます。エラーを消すスピードはAIに、「型を諦めていいか」の最終判断はあなたに。この分担で、赤い波線を消すだけの作業が、安全網を保ったままの修正に変わります。
型エラーをゼロにすることがゴールではありません。型に守ってもらったまま、エラーを消す。その線引きを、AIに丸投げしないための話です。
何が起きているか——なぜAIは any で消したがるのか
AIが手を抜いているわけでも、あなたの頼み方が悪いわけでもありません。型エラーの「いちばん簡単な消し方」が、たまたま危ない直し方と一致しているという構造的な事情があります。ここを押さえると、どこに気をつければいいかが見えてきます。
- 消す手段が複数あり、楽な順に危ない：同じエラーでも、
anyをつける・asでキャストする・@ts-ignoreを置く・正しい型を書く、と直し方は何通りもある。手っ取り早い順に、型の安全網を捨てる度合いが大きい - AIは「エラーが消える」を成功と見なしやすい：「このエラーを直して」と頼むと、AIは赤い波線が消える最短ルートを探す。正しい型を突き止めるより、
anyで黙らせるほうが速いので、そちらを選びがち - 本当の型を知らないまま直すことがある：外部ライブラリの戻り値やAPIレスポンスの型など、AIが正確な型を把握できないとき、確定させる代わりに
asで「たぶんこの型」と押し通してしまう - エラーは症状で、原因は別：型エラーは「どこかで型が食い違っている」というサイン。その食い違いの元を直さず、鳴っている箇所だけ黙らせると、原因は残ったまま警告灯だけ消える
裏を返せば——正しい型が何かを一緒に考えることは、AIが得意な作業です。楽な逃げ道をふさいで頼めば、ちゃんと型で直してくれる。順に見ていきます。
手順1：「直して」の前に「なぜ出ているか」を聞く
いきなり「直して」と投げると、AIは最短で消しにいきます。その前に一度、エラーの原因を説明させるだけで、直し方の質が変わります。
そのまま使える聞き方の例です。
次の型エラーが出ています。まず、なぜこのエラーが出ているのかを説明してください。どの値の型と、どの期待される型が食い違っているのかを教えてください。（直すのはそのあとで頼みます）
原因が言葉になると、あなた自身も「ああ、ここでnullが混じる可能性があるのか」と腑に落ちます。そのうえで直せば、AIの直し方が的外れなときにすぐ気づけます。急がば回れで、この一手間が「消しただけ」を防ぐ入口になります。
- エラーメッセージは、行番号やルール表示も含めてそのまま渡す（整形して要点だけにしない）
- そのコードが何をする箇所かを一言添える（「外部APIのレスポンスを画面用に変換している」など）。文脈があるほど、正しい型にたどり着きやすい
- 前提や制約の整え方そのものはAIにコードを書かせる前に渡す前提・制約の伝え方も参考になります
手順2：「黙らせずに正しい型で直して」と条件をつける
原因が見えたら、直しを頼みます。ポイントは、逃げ道をあらかじめふさぐこと。条件をつけないと、AIは楽な消し方を選びがちです。
そのまま使える頼み方の例です。
このエラーを直してください。ただし、次の条件を守ってください。
-any型を新しく増やさないでください
-as（型アサーション）や@ts-ignoreで黙らせないでください
- どうしてもそれらが必要な場合は、なぜ正しい型で書けないのかを説明してください
値が本当に複数の型を取りうるなら、anyではなく具体的な型の組み合わせ（ユニオン型）や、nullの可能性を含んだ型で表現してください。
補足すると、any は「どんな型でもOK」と型チェックを丸ごと止めてしまう指定、as は「これはこの型だと自分が保証する」とAIやコンパイラの確認を上書きする書き方です。どちらも便利ですが、間違っていても誰も止めてくれません。だから、使うなら理由が要る——という線引きを最初に伝えておきます。
「必要なら理由を説明して」を添えるのが効きます。本当にやむを得ない箇所（型定義が壊れている外部ライブラリなど）はありますが、理由が読めれば、それが妥当な諦めか、ただの手抜きかを見分けられます。
手順3：直したあとの差分で「黙らせ系」を数える
直してもらったら、差分に any / as / @ts-ignore が増えていないかを見ます。ここが、丸投げにしないための肝です。
- 増えた
anyを探す：変数や引数、戻り値にanyがついていないか。「エラーは消えたけどanyが1個増えた」は、消しただけのサイン asの押し通しを探す：as SomeTypeやas unknown as ...が増えていないか。とくにas unknown asは「無理やり感」が強いので要注意@ts-ignore/@ts-expect-errorを探す：コメントで丸ごと黙らせていないか。1行あるだけで、その行の型チェックは働いていません
見つけたら、責める必要はありません。「この any、正しい型に置き換えられる？無理ならなぜか教えて」ともう一度聞き返すだけです。多くはそれで、ちゃんとした型に直ります。
差分の見方そのものはリファクタリングをAIに任せるときの差分の確認方法も地続きの話です。エラーが消えたことと、意味が変わっていないことは別、という視点はそのまま使えます。
手順4：それでも any が残るなら「本当に諦める箇所か」を確かめる
世の中には、正しい型で書ききれない箇所も確かにあります。型定義が用意されていない古いライブラリ、形が定まらない外部データ、まだ移行途中のコード。そういうときは、any や as が現実解になることもあります。
大事なのは、それを「今回は諦める」と意識して選ぶこと。なんとなく紛れ込んだ any と、事情があって残した any は、見た目は同じでも意味が違います。
- 範囲を最小にする：どうしても
anyを使うなら、変数1つ・1行だけにとどめる。関数の戻り値まるごとをanyにすると、そこから先が全部ノーチェックになる - 境界で型を固める：外部データが入ってくる入口で一度だけ型を確定させ、そこから内側は正しい型で扱う。
anyを奥まで持ち込まない - 印を残す：やむを得ず黙らせるなら、
@ts-ignoreより@ts-expect-errorを使い、なぜ黙らせたかを一言コメントで添える。あとで読む人（未来の自分）が事情を追える
AIが「これは any にするしかない」と言い切っても、それは鵜呑みにしないところです。もっともらしく必要性を語ることがあるので、AIのハルシネーション（もっともらしい誤り）の見抜き方の視点で、本当にそうかを一度照らしてみてください。
手順5：型が通ったら、動きも一度確かめる
型エラーが消えて、any も増えていない。それでも最後に、実際に動かして挙動が変わっていないかを軽く見ます。型が通ることと、正しく動くことは、必ずしも同じではありません。
とくに as で型を書き換えた箇所は要注意です。as は「この型だと思って進めて」という指定なので、実際の値が違っていても、実行するまで気づけないことがあります。型の上では通っていても、動かすと undefined が来て落ちる、というのはよくある落とし穴です。
- 直した箇所を通る、いちばん基本の動作を1回試す（画面を開く、その関数を1回呼ぶ）
asを使った箇所は、実際に来る値がその型と合っているかを、ログや実データで一度確かめる- 最低限の動作確認の型は生成コードをそのまま使わない——最低限の動作確認の型にまとめています
具体例：APIレスポンスの型エラーを直させる
たとえば、外部APIのレスポンスを扱う箇所で「user.name は string | undefined かもしれない」という型エラーが出たとします。AIに「直して」と投げると、こんな直し方が返ってくることがあります。
- 危ない直し方：
const name = (user as any).name——anyで丸ごと黙らせる。エラーは消えるが、userの他のプロパティも全部ノーチェックになり、タイポしても気づけなくなる - まだ危うい直し方：
const name = user.name as string——asで「絶対stringだ」と押し通す。実際にundefinedが来たら、その先で落ちる - 型で直す：
const name = user.name ?? "（名前なし）"——undefinedの可能性を受け止めて、来なかったときの値を用意する。型エラーの原因（値が無いかもしれない）に、正面から答えている
3つ目が、エラーの原因そのものに向き合った直し方です。同じ「エラーが消える」でも、1つ目・2つ目は問題を先送りしているだけ。AIに頼むときは「undefined の可能性を握りつぶさずに直して」と一言添えると、3つ目に寄せやすくなります。
ありがちな落とし穴
- 「エラーが消えた＝直った」と思う：消し方が
anyでも、赤い波線は消える。消えたことと直ったことは別 - 差分を見ずにコミットする：
anyやasが増えていても、動いてしまうと気づかないまま入る as unknown as ...を見逃す：二段構えのキャストは「無理やり通した」印。ふつうのasより警戒したい@ts-ignoreを無言で置く：理由のコメントがないと、あとで消していいのか触れなくなるanyを関数の入口や戻り値に置く：そこから先が全部ノーチェックになり、影響が奥まで広がる- AIの「これは
anyしかない」を鵜呑みにする：本当は正しい型で書ける箇所まで、必要だと言われて諦めてしまう - 型が通ったから動作確認を飛ばす：
asで押し通した箇所は、実行して初めてズレが分かることがある
明日からやること（小さく始める3つ）
- 型エラーをAIに投げる前に、「なぜ出ているか」を一度説明させる
- 直しを頼むときに、「
any・as・@ts-ignoreで黙らせないで」と一言添える - 直ったら、差分に
any/as/@ts-ignoreが増えていないかを数える
この3つだけでも、「赤い波線を消すだけ」から「型に守ってもらったまま直す」に変わります。慣れたら、境界での型固めや @ts-expect-error の使い分けを足していけば十分です。
AI型エラー修正のチェックリスト
「関係する所だけ見る」が前提です。全部に○は要りません。いま直している型エラーに関わる所だけ、さっと確認します。
頼む前
- エラーメッセージを、行番号ごと加工せず渡したか
- そのコードが何をする箇所か、一言の文脈を添えたか
- 「まずなぜ出ているか説明して」と原因を先に聞いたか
頼み方
- 「
anyを新しく増やさない」と条件をつけたか - 「
as・@ts-ignoreで黙らせない」と伝えたか - やむを得ない場合は「理由を説明して」と添えたか
直したあとの確認
- 差分に
anyが増えていないか数えたか -
as（とくにas unknown as）が増えていないか見たか -
@ts-ignore/@ts-expect-errorが無言で置かれていないか - 残した
anyは「今回は諦める」と意識して選んだものか
動きの確認
- 直した箇所の基本の動作を一度試したか
-
asを使った箇所は、実際の値が型と合っているか確かめたか
最後に
赤い型エラーを前に、とりあえずAIに消してもらう。その動き自体は、なにも悪くありません。むしろ、消えた差分をもう一度見直そうとした時点で、あなたは十分に丁寧です。多くの人は、消えた安心でそのまま閉じてしまうのですから。
型エラーは、消すだけなら一瞬です。でも、型が守ってくれていた安全網を外してまで消す必要は、たいていありません。消すスピードはAIに、「型を諦めていいか」の最後の判断はあなたに。役割を分ければ、赤い波線を消す作業は、安全網を保ったままの修正に変わります。
any を1個増やさずに直せた——その小さな一手が、半年後の自分を、静かに助けてくれます。
今日ひとつ、「型エラーは消えたかではなく、型で守れているかで見る」を決められたなら、それはもう、"波線を消すだけ"を"ちゃんと直す"に変える確かな一歩です。
よければ、こちらも
- 直したあとの差分の見方はリファクタリングをAIに任せるときの差分の確認方法へ。
- AIの「必要だ」を鵜呑みにしないための見方はAIのハルシネーション（もっともらしい誤り）の見抜き方へ。
- 直したコードの最低限の動作確認は生成コードをそのまま使わない——最低限の動作確認の型へ。