
Claude Code を使い始めて、やめた5つの開発習慣
はじめに
Claude Code を毎日使うようになって、気づいたら自然にやらなくなった開発習慣がいくつもあります。
「これからはやめるぞ」と意気込んだわけではなく、AI に任せたほうが明らかに速かったから、静かに手放した、という感じです。
この記事では、そんな「気づいたらやっていなかった習慣」を 5つ挙げます。
まだやっている方を否定するつもりはありません。自分にとって合う・合わないがあるだけです。
ただ、同じように感じている方の言語化のきっかけになればうれしいです。
1. 構文エラーの文面をググる
以前は、知らないエラーが出たらまず Google で文面を検索していました。
スタックトレース(エラーの発生箇所を示す情報)から英語部分だけ抜き出して、ダブルクオートで囲んで投げる、というあの儀式です。
いまは、エラー出力をそのまま Claude Code に貼って聞きます。
文脈ごと読んで「この設定と関係がありそう」「依存パッケージの更新で変わった挙動だろう」と、周辺のファイルまで見て答えてくれるので、検索より圧倒的に速いです。
Google の検索結果は一般論を返してきますが、AI は自分のプロジェクトの事情を踏まえて返してくれます。
この差が一番大きいと感じています。
もちろん、AIが堂々と間違った解決策(ハルシネーション)を出してくることもあります。
でも、そのときに「やっぱりGoogleで調べ直そう」とはなりません。
「そのコードだと〇〇というエラーに変わった」と対話で軌道修正したり、公式ドキュメントや仕様書を NotebookLM(指定した資料だけを元に回答するGoogleのAIツール)のようなツールにまるごと読み込ませて、その中で答えを探させるようになりました。
トラブルシューティングの手段が「自力での検索」から「適切なコンテキスト(前提知識)をAIに与えて考え直させること」へと完全に置き換わった感覚です。
2. スクリプトのストックを作る

これが一番、自分の中で大きな変化でした。
以前は、よく使う SQL、お決まりのシェルスクリプト、便利な Python のワンライナーを `snippets/` フォルダや Gist にストックしていました。
「あのとき書いた集計用の SQL、どこに置いたっけ」と探しては貼り付ける、という運用です。
いまは、ストックを作らなくなりました。
「こういう結果が欲しい」と AI に伝えれば、その場で生成されます。
ストックを作る・探す・メンテするという3つの作業が丸ごと消えたので、コード資産のフォルダを見る機会がほぼなくなりました。
とくに SQL は顕著です。
JOIN の構文を思い出そうとする前に、「このテーブルとこのテーブルを突き合わせて、月別の集計が欲しい」と日本語で伝えたほうが速いです。
コードという「資産」への執着がなくなり、使い捨ての道具として割り切れるようになった、とも言えるかもしれません。
3. コマンドのオプションを暗記する
`tar`・`find`・`sed`・`awk` あたりのオプションを、昔はがんばって覚えようとしていました。
「よく使うから覚えておいたほうがいい」と自分に言い聞かせながら、`man` を読んで付箋を貼る、というやつです。
いまは、やりたいことを日本語で伝えて、生成されたコマンドを確認してから実行します。
覚える対象が「オプションの文字列」から「やりたいことの表現のしかた」に変わった感覚です。
暗記をやめた分、コマンドの副作用や危険度を判断する目を持つことに頭を使うようになりました。
AI が提案するコマンドを鵜呑みにせず、実行前に内容を読むのは、暗記以上に大事な習慣です。
4. 人に頼る(聞く/お願いする)
これは賛否が分かれそうな項目ですが、正直に書きます。
有識者に「聞く」ことが減った
以前は、社内の詳しい人や Stack Overflow で質問することが多くありました。
いまは、ほとんどの技術的な疑問を AI に聞いて解決しています。
これは自分だけの変化ではないようです。
Stack Overflow の 2024 Developer Survey では、開発者の 76% がすでに AI ツールを使用中または導入予定と回答しています(前年は 70%)。
同時期に、Stack Overflow への月間質問数も大きく落ち込んでいます。
外部の分析によれば、2022年11月比で約76%減(2024年12月時点)とのことです。
人に聞く前には、少なからず「相手の時間を奪うな」「こんなことも知らないのかと思われないか」という遠慮が働きます。
AI にはこれが一切ありません。
何度聞いても怒らず、同じ質問を3回しても丁寧に答えてくれます。
雑タスクを「お願いする」ことも減った
「これやっておいて」と誰かに振っていた小さなタスクも、自分で片付くようになりました。
背景を説明し、依頼内容をまとめ、結果を確認する。一連の手間を考えると、AI に投げて自分で動いたほうが速いからです。
気づいたのは、人に頼るのはコストの高い行為だったということです。
タイミングを伺う、遠慮する、前提を説明する——これらが積み重なって、意外なほど時間を使っていました。
AI がそのコストを消してくれたので、頼る前に自分でやってみる、というのが初期動作になりました。
人間関係に無頓着になったわけではなく、頼る場面を本当に必要なときに絞れるようになったという感覚です。
5. コミットメッセージや PR 説明を自分で書く
最後は地味ですが、全員が通っている道だと思います。
コミットメッセージや PR の説明文は、差分を AI に読ませて生成してもらうようになりました。
自分で書くより、差分に忠実で、言葉の揺れも少ない文章が出てきます。
以前は「今日はメッセージに凝るぞ」と気合を入れて書いていた時期もありましたが、いまは気合の入れどころを別のところに移しています。
レビュアーに伝わる最低限の情報を安定して出す、という仕事を AI に任せるのは、想像以上に効きました。
やめてみて気づいたこと
5つ並べて気づいたのは、これは単なる時短の話ではないということです。
意思決定のしかたが変わっていました。
昔の習慣の多くは「覚える」「貯める」「探す」という、未来の自分を助けるための投資でした。
いまは、必要になった瞬間に AI に生成・参照してもらうので、投資の必要性が薄れています。
別の言い方をすると、**「あらゆるケースを想定して手元に完成品の資産を持つ」から「最小限の元ネタだけを持ち、必要なときにAIで呼び出す」**への移行です。
もちろん、AIに指示を出すための「元ネタ(仕様や前提となるコンテキスト)」は依然として必要です。ただ、以前のように「もしかしたら使うかも」と多数のパターンを事前にストックしておく防衛的な準備は綺麗になくなりました。
これは道具の使い方だけでなく、仕事の組み立て方そのものを変える変化だと感じています。
まとめ

ここまで 5つ、やらなくなった習慣を挙げてきました。
構文エラーの文面をググる
スクリプトのストックを作る
コマンドのオプションを暗記する
人に頼る(聞く/お願いする)
コミットメッセージや PR 説明を自分で書く
全部やめたほうがいい、とは思いません。
自分で書くことで身につく感覚は確かにありますし、人に頼ることで生まれる関係もあります。
ただ、意識しないまま続けていた習慣に気づくことは、AI との付き合い方を整える第一歩になりました。
AIに下働きを任せることで浮いた認知リソースは、AIが生成したコードの「副作用や危険度を評価する」といった、より高度な判断に回せるようになりました。
逆に、AI を使い始めてから増えた習慣もあります。例えば、文法を暗記する代わりに「背景(コンテキスト)を言語化する習慣」などです。これらについては、また別の記事で書こうと思います。
ツール選びだけでなく、日々の所作レベルでも同じパラダイムシフトが起きていたことに気づいた記事もあります。よければ合わせてどうぞ。
あなたが、気づかないうちにやらなくなった習慣はありますか?
もしあれば、コメントで教えてもらえるとうれしいです。