事例紹介2026年2月21日by K.hirano

Claude CodeとCursorを使い込んで、コーディングという概念が変わった話

Claude CodeとCursorを実際に使い込んだHWエンジニアが「書く」から「判断する」への変化を語る。AIコーディングが便利な理由と、依存する危険を正直に解説。

#コーディング#AI#Claude Code#Cursor

この記事の結論（2分で読める要約）

Claude CodeとCursorは「コードを書く」から「コードを指示する」への転換を加速した
変わったのは手段だけでなく、何に時間を使うべきかの判断基準そのもの
コードを書かなくなっても、「何を作るか」の判断と品質の責任は人間に残る
出力を読む目を持ち続けること。「指示する側」でいるための最低限の条件だと思っている
「書く技術」より「判断する技術」の重要性が増した

情報の鮮度: 2026年2月時点の観察をもとに記述

このプロダクトを動かしているコードの大半は、私が書いたものではない。

Claude CodeとCursorが書いた。それでも動いている。これは事実だ。

「書く」から「判断する」へ

2022年頃からAIコーディングツールを使い始めた。最初はGitHub Copilotの補完程度だったが、LLMが本格的にIDEに統合されてから、作業の質が変わった。

Cursorは、コードベース全体のコンテキストを理解した上で編集・生成を行う。「このファイルのこの関数を、Supabaseのリアルタイムサブスクリプションを使って書き直してほしい」という指示が、そのまま動くコードになる確率が飛躍的に上がった。

Claude Codeはさらに進んでいる。ターミナルから直接コードを読み、実行し、エラーに対応し、テストを書く。何をするか指示すれば、あとは勝手に進む。

最初は半信半疑だったが、今は「自分が手を動かすべき場所」の判断基準が変わった。

何が残るか

AIがコードを書いても、以下は残る。

要件の定義: 何を作るかは人間が決める
アーキテクチャの判断: どう作るかの大枠は、今のAIには任せにくい
コードレビュー: AIの出力が正しいかの判断。ここをサボると後で困る
最終的な品質責任: 動かないプロダクトの責任は人間が取る

特にコードレビューが重い。コードを書く時間が減った分、レビューに使う時間は増えている感覚がある。

正直に言うと、最初は舐めていた

正直に言うと、私自身も最初は「動けばいい」という感覚でいた。

問題が出たのは深夜だった。AIが書いたコードの一箇所が想定外の動きをしていた。何をしているかを読もうとして、初めて「あ、ここをちゃんと確認していなかった」と気づく。動いているうちは問題が見えない。問題が出てから読もうとすると、意図がわからなくて手が止まる。

出力を流し込むだけでは、「使っている」のではなく「使われている」になる。そのことを、失敗してから実感した。

FAQ

Q: Claude CodeとCursorはどう使い分けるの？ A: Claude Codeはターミナル・CLIベースで自律的な実行まで対応。Cursorはエディタ統合でコードを書きながら即座にAI補完・編集を使いたい場合に向く。用途によって併用することも多い。

Q: コードが書けなくてもAIコーディングツールは使えるの？ A: 使える。ただ、私の経験では「出力を眺めて何かおかしいと気づける」感覚があるかどうかで、後々の手間がかなり変わる。「書ける」は必須ではないが、「読める」と「違和感を持てる」はあったほうがいい。

Q: 今から「書ける」スキルを身につけるべき？ A: 状況による。プロとして開発するなら基礎は必要。ただし、AIとの協業が前提なら「完璧に書ける」より「正しく判断できる」スキルのほうが投資対効果は高いかもしれない。

コードを書く時間が減り、判断する時間が増えた。

それが楽になったかというと、単純にそうとは言えない。判断の精度に責任がかかるようになった分、別の種類の重さがある。

この記事を書いた人

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！