Zenn
🎱

claude code について感じていること (2025/06)

に公開
AI
プログラミング
Anthropic
Claude Code
idea

最近claude code を使い始めて、今感じていることを残しておく。

読んだらお得だと思う話は触ってみて意外に思ったこと と 工夫していることにまとめているので、そこだけ読んでもらっても良いと思う。

現状手元で動かしているので claude code action の話は書いていない。

触ってみて意外に思ったこと

導入ハードルが低い

CLAUDE.md を作ることが推奨されているが、無くても十分適切に動く。

更にCLAUDE.md は簡単に生成できる

/init

気に入らなければ、指示を出して更新することもできる

コーディング規約にfor-else 文を使ってはならないと追記して

/init は既存のCLAUDE.md を更新するのにも使える。
もちろん /init ではなく、CLAUDE.md を直接 claude code にレビューさせることも出来る。

CLAUDE.md をレビューして、追加できそうな内容を教えて。

賢い

  • cline は devcontainer のなかで動かしたいと感じていたが、claude code はローカル環境でも動かせると思っている
    • ユーザーPCへの破壊的変更をしようとしない
  • この実装を参照してほしいといった指示を渡すと、そのリポジトリの関係のあるコードも勝手に読んでくれる
XXXを実装してほしい。
参考実装は下記に存在するので、それを参照してほしい
https://example.com/example

コードを書くときは src/examples/example.rs の設計を真似ること
  • 提案してくる変更をそのまま apply できると感じることが多い
    • 自分であれば１日はかかるだろうと見積もったコードが20分程度で出来たりする体験がある
    • 既存AIが出してくるコードはネットに落ちているコードに手を加えたものという印象だったのに対し、claude code は必要であれば関連コードも読んでくれるので、自分でも同じように書くだろうと判断するコードが完成することもある

体験が良い

  • 簡単めのタスクであれば適切な指示を出せば、後でEnterを押し続けるだけで完成する。

    • Enterを押すだけ無駄だと思うことすらある

  • 割り込みの処理がスムーズでストレスを感じない

    • cline は割り込みをしにくい印象があったが、 claude code は割り込み処理をかけると素直に止まってくれる

レビューしてもらうのが楽しい

  • claude code はレビュー相手として会話が通じる

  • git の差分から差分の内容や意図はもちろん、変更はないが関係ありそうなコードをレビューしてもらうこともできる (しかも返答も早い)。

過去の3 commit を見て、変更内容を説明して。また関係ありそうなファイルを羅列して。
↓
⏺ Bash(git log --oneline -3)
  ⎿  Agent pid 88169                                                
     xxxxxx1 hoge
     xxxxxx2 fuga
     … +3 lines (ctrl+r to expand)

⏺ Bash(git show --name-only xxxxxx1)
  ⎿  Agent pid 88223                                                
     commit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1
     Author: xxxxxxxxxx <0000000+xxxxxxx@users.noreply.github.com>
     … +5 lines (ctrl+r to expand)

(中略)

⏺ Bash(git diff xxxxxx1^..xxxxxx3)
  ⎿  Agent pid 88285                                                       
     diff --git src/example/example.rs
     index xxxxxx1..xxxxxx3 xxxxxxx
     … +38 lines (ctrl+r to expand)

⏺ Read(src/example/example.rs)
  ⎿  Read xxx lines (ctrl+r to expand)

  Task(Check for any other files...)
  ⎿  Initializing…
  
(中略)

⏺ 過去3コミットの分析結果

  主要な変更内容
  1. src/example/example.rs の改善 (xxxxxx1)
  - 環境変数を受け取るように変更
  - 環境変数を struct example に渡す
  - src/example/piyo.rs にも環境変数を渡す必要があると考えます

工夫していること

呼び出すべきコマンドを教える

  • watch mode で呼び出されるコマンドを動かすと返ってこなくなるので、どれが呼び出すべきではないコマンドかは教えておく
  • cargo build --release なども無邪気に呼び出すと時間がかかるコマンドも多い
    • より軽量なコマンド(例えば cargo check)をさせたり、テストプロセスを最後まで実行させないようにするのも良い方法だと感じている

最後にやってほしい事を伝える

  • README.md や docs の更新は明示的に伝えておくと抜け漏れがない
  • 変更し終わった後に、変更した内容の意図についてサマリーを教えてもらえるように指示を出す
  • 変更し終わった後のリファクタリング・フォーマットも明示的に依頼する

やりたい事を具体的に伝える

  • タスクチケットのように、何をしたいか、どこに何を書くかを必ず伝える
  • Good First Issue を書くような気持ちでやっている。claude code に頼めばすぐ終わるかもしれないが、ここをサボらないことが成果物の品質に出てくると思う
あなたはYYYのためにXXXという機能を実装する。

この機能を実装するためにあなたは下記をする。
1. 参照実装を確認する
2. ライブラリである xxx を導入する
3. src/example/hoge.rs にその実装を追加して、それを確認するテストを書く

参考になる実装が https://example.com/example にあるので参照してほしい。

気になるところ

CLAUDE.md に最後まで従わない時もある

コンテキスト長の問題があるとはいえ、思ったよりもCLAUDE.md に従っているか怪しい挙動を示すことがある。
CLAUDE.md を生成したり、禁止する指示を追記させると、大体 never と書いてくるので、本当にダメなことは never と書くとよさそうに見えている。タスクが長引いた時は注意してレビューが必要。

想定しない指示の理解をする時もある

Typescript の Snapshot Testを書くように指示したところ、このようなコードが出た。

HOGE = 3;
(中略)
expect(HOGE).toMatchSnapshot();

指示通りではあるが、モックや定数をスナップショットテストしてほしいわけではなかった。

他にもPython3でファイルサイズのバリデーションテストを書かせると、実際にバリデーションを超えるサイズのファイルを作るテストが生成された。

with open("test.bin", "wb") as f:
    f.write(b'\x00' * size_gb * 1024 * 1024 * 1024)

とはいえ、これらは追加で指示をすれば収まる挙動なのでチマチマアップデートしている。

変更差分について git add -p 的なことがしたい

やり方を知らないだけかもしれないが、ここだけ直してほしい。残りはOK みたいな事を簡潔に伝える方法が知りたい。

感じていること

型付き言語と相性が良い

実際触った範囲で一番理解度が高いのはRustだと感じている。適当に書くとコンパイルが通らないのは勿論、Structの設計でコード生成が誘導できるのもあると感じている。

同様に型のあるTypeScriptも精度高く出力されるが、こちらは生成されるコードに大分良し悪しがある気がしており、そこは適切にRejectできる能力が要求される。

Python3 も同様で自由度が高い故に、細かい指示まで出さないとコピペされた定型句のようなコードが出てくる時がある。

設定より規約で誘導する

ここまで褒めておいたのだが、claude code にやりたいようにやらせたいとは思ってはいない。

（今のところは）人間が事前にレールを引いて、そのレールに従うように設計をするべきだと思う。

AIに指示を出して毎回従わせるというよりも、AIが従わざるを得ないような設計がベストだと思う。

現状人間の実力が介在する

  • claude code がタスクを実装してきた時に、リファクタリングは必要であると考えている

    • 最初の変更をRejectをして修正依頼を出したり、出来上がった成果物に対して「この観点はどうですか？」といった質問や「どうしてこの実装にしたの？」という質問をしながら直している。

  • それは簡単なことのように見えて、希望通りに動いているコードをRejectしたり、設計や観点への質問が思い浮かぶ事自体は人間の実力に起因している（気がしている）

    • （今のところ）そういった事を思いつくのには、私たちの頭の中にあるプロダクトコードベースの将来像や、既存の動作振る舞いへの理解が必要だと思う
    • claude code は動くコードを出してくれるが、だからこそ実装の筋の良さを見る目は常に持っておく必要がある

  • 300行の差分を作ってきたとして、それが正しいかレビューすることは避けては通れない

    • そしてその実装をレビューするのにも結局コードの理解は必要な気がしている
    • anthropic CEO が語る未来のように、大半のコードについては受け入れテストだけする未来は来ると思うが、受け入れテストをするための知恵は、結局開発経験から導かれるんじゃないかな...

眺めていて楽しい

claude code の振る舞いは人間が高速で試行錯誤するのを眺めているような面白さがある。

build して失敗したり、テストが動かなかったりすることも多くあるが、その度にエラーメッセージを読み直して直していくのが見ていて楽しい。自分が10分はかける事をclaude code は早まきでやってくれる。

# こんな感じの動きが1~2分で見られる
cargo build
(Error Log Reading)
↓
Edit request
↓
cargo build
(Success)
↓
Adding tests
↓
cargo test

一緒にコードを書くのが楽しい

業務外でコードを書くぞーという気持ちにさせられる

Discussion