Claude Code を1ヶ月使ってみた感想
目次
2025年6月から Claude Code を Max プランで1ヶ月以上使い続けていますが、状況の変化が非常に早いため熱が冷めないうちに書き上げたいと思い筆を取りました。走り書きっぽくなっているのはご容赦ください。
なお、内容は備忘録的なので中身はそんなにないです。Claude Code 自体の tips 等については、Zenn などで今盛り上がっているのでそちらを参照してください。
使ったモデルについて
基本的には Claude 4 Opus (ハイブリッドではなく固定) を使っていました。
プロジェクトについて
弊社では WP RAG という WordPress のプラグインの開発をしています。元々は鹿島が一人で開発していた小さなプロジェクトだったのですが、今回いくつか機能を追加する事になり私も参加することになりました。せっかくなら Claude Code を試す良い機会だと思い、このプロジェクトではほぼ全てのコーディングを Claude Code でやってみる事にしました。
システム自体は WordPress のプラグイン本体 (PHP) の他に、 RAG システムを提供する API を Flask (Python) を使って開発しています。
CLAUDE.md の作成
最初に始めるのは CLAUDE.md の作成になります。 /init コマンドを実行するとコードベースを解析して、自動的にプロジェクトの構成などをまとめたドキュメントを CLAUDE.md に書き込んでくれます。
私自身このプロジェクトの事を大まかな概要しか把握していなかったのと、Flask に関しては完全に初めてだったので作成されたドキュメントを軽く眺めても特に評価もできなかった為一旦そのまま使う事にしました（後述しますがこれが結構微妙だった可能性があります）。
実際にやったタスク
WP RAG は（2025/07/12 時点では）パブリックベータな状態で絶賛機能の追加中です。将来的に有償機能も公開予定ですが、その先駆けとして「事前に購入した有料の API キーを登録したサイトのみ特定のエンドポイント（有料機能）を認可する」と言う認証・認可の機能を追加する事になりました。
Flask も Laravel や Rails の様なフレームワークと基本的な部分は一緒なので対応する事といえば
- DB スキーマの変更を行うのでマイグレーションを追加
- 新規にエンドポイントを作ったり、既存のエンドポイントを更新する為にアプリケーションを修正
- 自動テストの追加や既存テストの修正
とよくある内容になります。
指示を投げる
実際に使ったプロンプトは残ってないので正確ではありませんが、だいたい次の様な内容だったと思います：
有償の API キーを追加したい。
現在はサイト登録時に自動で発行される無料 API キーを使って認証をしているが、有償の機能を今後追加する予定なのでその機能にアクセス可能なキーを別途発行したい。
ユーザーへの有償キーの発行業務自体は当面運用で管理するので、その部分を自動化する必要はない。必要な実装は大まかに
- PremiumApiKey モデルとテーブルの追加
- key は無料 API キーと同様の N 文字のセキュアランダムな文字列
- create_site エンドポイントに "premium_api_key" (任意) を追加し、値があれば検証、問題がなければ登録する Site と紐付ける
- update_site エンドポイントにも "premium_api_key" (任意) を追加し、値があれば検証、問題がなければ Site と紐付ける
- 1つの Site につき1つの PremiumApiKey のみ紐づく
また今回追加・修正したコードについては自動テストも追加してください。
一部、技術的な詳細に触れてはいますが具体的なファイルの場所や完全なテーブルスキーマの提案はしませんでした。
先述した通り、今回は既存のコードや DB スキーマの構成について私自身があまり詳しくない状況で作業を依頼しているのと、エージェントが色々探索してくれてよしなにやってくれるだろうと思いこれでも割と十分だと考えていました。
しかし結果的にはあまりうまくいきませんでした。
指示が雑すぎた
実装した機能はボリューム的には（中級者以降の人間が対応するなら）そこまで大きくない物なので、あの様な指示でも機能すると思いましたがたがこれがうまくいかなかった様です。具体的には次のような事が起きていました:
- 誤った修正
- 既存のエンドポイントの一部が何故かボトルネックになっており、それを問題と認識してコードの修正が発生していた
- 結果的にはそれは Claude の判断ミスで、ただ一見すると妥当性がある様に感じたのでそのまま採用してしまった（後で人間のレビューでミスに気づいた）
- 無関係な修正
- WordPress プラグイン側の修正で API の通信を何故か AJAX で対応すると言い出した
- これは明らかに無意味だと思ったのですぐやめさせた。なぜその様なプランになったかは不明（既存のコードに AJAX 処理はない）
- 勝手に画面デザインを変え出した
- これも特に支持していないが CSS を追加したりして何故かデザインを変え出した
- WordPress プラグイン側の修正で API の通信を何故か AJAX で対応すると言い出した
他にも細かい所でイケてない部分がいくつかありましたが割愛します。
ドキュメントが足りていなかった
元々 0 -> 1 ベースで、それも1人で作ったプロジェクトなので仕方がない事ではありますが、 AI 的にはここもボトルネックになっていました。具体的には README.md が Flask のデフォルトのものになっている等、テストやマイグレーションの実行方法などの基本的なイテレーションの操作手順などが欠落していた状況です。
逆にうまくいった事
既存機能へのテストの追加や修正はうまくいく印象がありました。もちろん使っている技術スタックやタスクの内容に大いに依存すると思いますが、テストコードはアプリのコードと比較するとパターンが固定されやすく、十分な学習量があると言うのもあるかもしれません。テストケースが足りないと感じた場合は具体的に何が足りないとかこれ足して、とか自然言語で書けばうまくいく事が多いです。
改善した点
まずコードベースを（自分自身が）ある程度理解する
そもそもここを疎かにしていたのが最大の失敗でした。AI エージェントを駆使すれば、スタートで自分があまり知識がなくてもワークし、それに伴って徐々に自分の理解を深められればと言う目論見は誤算に終わりました。もしかしたらこの先 AI が賢くなればうまくいくかもしれませんが現状はそうではありませんでした。
また理解を深める事により、後述の環境の整備や、エージェントが間違った方向に行っていそうな時にすぐインターラプトできる様にもなります。
開発環境とドキュメントを整備した
README.md が貧弱だったので、最低限開発に必要な、開発環境に関するドキュメントやイテレーションにおいてよく使うコマンド群などをまとめました。また、 CLAUDE.md には README.md にその辺りが書かれている事を明記した上で、細かいコーディングルールや、README.md に書くほどではない Tips などをまとめておきました。実際に生産性パフォーマンスが上がったか定量的に測ってはいませんが、以前より満足のいくコードが出力される率が高くなった印象はあります。
プランモードを使ったり、指示は小さく、ただし細かくする
Claude Code では Shift + TAB を押すと Plan mode と言うモードに入る事ができます。ここでもプロンプトを入力するんですが、一旦それを鑑みて必要に応じてコードベースの探索などを行いながら、具体的にどの様な作業をするかプランニングしてまとめ、計画を表示してくれます。その内容に問題がなければ Go を出せば作業が始まるし、ツッコミどころがあればプロンプトを追加します。
また、指示についてはマイクロマネジメントになっている程（当然ですが）ワンショットでうまくいく可能性が高いです。実際に変更を加えるファイルを指示に含めたり、採用するアーキテクチャなどの詳細な設計はなるべく細かくプロンプトに入れるとうまくいきます。人間がコーディングする場合もそうですが、ほぼ頭を使う事なく「後はコーディングするだけ！」くらいまで落とし込めるとその後ノータッチで行ける確実性が高まる印象です。
また関連して、人間が開発する時もそうですが、関わるファイルが5〜6ファイルを超えるようなタスクではコンテキストから溢れて途端にパフォーマンスが悪くなったりする場合があるので、その場合は細かい粒度毎に作業させるとうまくいきます（PR を分けるイメージです。と言うか実際に PR は分けていいです）。
要は探索空間を絞る訳ですが、この様にすると消費するトークンも節約され、 Usage Limit への到達も遅くなるのでオススメです。
コンテキストのバイアスについて
今回の機能を実装する上で、ある程度形になった段階でユビキタス言語が更新され、それに伴ってクラス名やメソッド名を大幅に変更したくなりました。ドメインロジック自体に変更はないので単に名前を変えるだけなんですが、元のやり取りや成果物がコンテキストに入っていてそれに大いに引っ張られ、多くの変更漏れやドメイン的に（命名の）不規則性や矛盾が目立つ変更が多く混入してしまいました。
この様な状態に陥った時は、素直に元の変更はどこかにセーブしておいて、最初からやり直した方が良いかもしれません。
番外編：1発でうまく行った例
上記のプロジェクトと全く関係がないんですが、私がプライベートで運用している、 Go で実装されたある AWS Lambda の関数があります。 mailbot と言う名前で、子供の学校や塾関連の連絡を受け取っているメールアドレス宛に飛んできたメールを内容に基づいて、予め決められた家族がメンバーになっている LINE のグループチャットにメッセージを飛ばす物となっております。
元々勉強も兼ねて数年前に作って以来ちまちま運用している関数なのですが、これまた勉強がてら Rust にリプレースしたくなり去年試みました。しかし重なる機能追加によってそこそこ複雑な関数になっていた事もあり、OpenAI の o1 ではうまくリプレースできませんでした（その時はエージェントではなく ChatGPT を使っていました）。
今回 Claude Code なら行けると思ったので再挑戦してみる事にしました。例によって CLAUDE.md はほぼ用意せず、 plan mode で以下のプロンプトを投げました:
mailbot package を Cargo Lambda に置き換えてほしい。
mailbot は、Amazon SES の Email receiving 駆動で起動する Lambda 関数（SES Event）。
機能をざっくり説明すると、SES はEメールメッセージを受け取ると、MIME メッセージを S3 バケットに MessageId をオブジェクト名にして保存した上で当 Lambda 関数を invoke します。
この関数は、その MIME メッセージを S3 バケットからダウンロードしてパースし、件名、本文、添付ファイルを抜き出して解析を行い、内容に応じて LINE の予め決められたトークの部屋にメッセージを送信します。
宛先の部屋はメッセージの内容に応じて変化します。添付ファイルは別の S3 バケット（CloudFront で配信している）に配置した上でその URL をそれぞれ個別のメッセージにして送信します。
画像ファイルは画像メッセージとして送信します。
アプリ自体は三層構造のアーキテクチャを取っていて、
1. Lambda のエントリポイントを定義する lambda/msgforwarder.go.
2. アプリケーションビジネスロジックを定義する msgforwarder/forwarder.go と、各種主要なドメインロジックを定義したプログラムが同じディレクトリ内にあります。
3. インフラ層として、 aws パッケージ（S3 を直接操作）と line パッケージ（LINE の SDK を使ってメッセージを送信）
いわゆるクリーンアーキテクチャですね。
こちらを完全に Cargo Lambda (Rust) に置き換えてください。
重要なポイントとしては、
1. まず当たり前だけど Lambda 関数自体の挙動は変えない事. 同じ MIME メッセージに対しては完全に同じ動作をする事
2. ビジネスロジックにはユニットテストが用意されているので、同じテストケースを書く事
一方、Go と Rust で異なる部分があると思うので、「Rust 的にはこう書いたほうがいい」みたいなテクニックがあったら既存の Go のコードに引っ張られる必要はなく臨機応変に変えても良いです。
またロギングなど細かい非機能要件部分も完全に一致させる必要はありません。
なお、移植にあたって Rust 言語が持つ最大のメリットでもあるパフォーマンスをかなり損ねるとかじゃなければ、できれば現状のクリーンアーキテクチャのような、IO とビジネスロジックを分離した世界観は維持して欲しいです。
すでに Rust と Cargo Lambda はシステムにインストール済みです。
また、 CDK のコードは変更しないでください。一旦ローカルで動作するところまで確認できたらそのあたりはゆっくり考えます。
また、あなたは AWS のクレデンシャルを持っていないので、権限が必要な操作が必要になった段階でコマンドを伝えて貰えば代わりに実行し、その出力結果を随時教えることは可能です。
それではよろしくお願いいたします。
この内容で掲示されたプランを元に実装を進めさせたところ、コンパイルエラーに何回か遭遇していましたがその後エラーは解消され（Warning が1件残ってましたが）、実際に Lambda にデプロイしても全く問題なく動作しました。正直これにはかなり驚きましたが、Rust コンパイラはエラーの詳細をかなり詳しく出力してくれるので、作業結果を常にコンテキストに入れ続ける AI エージェントとは割と相性が良いのかもしれません。
感想
現時点では、システム開発におけるいわゆる上流工程的な部分の大半を人間が決める必要があり、まだまだ人間の手が完全に離れる事はなさそうだなと思いました（なのでプログラミング、ひいてはソフトウェア開発における複合的な知識はまだまだ必要です）。しかし、うまく指針させ出す事ができればノータッチで作業が進んでいく様子は見ていて楽しいです。またうまく動作している間は他のことをできるので、（今回はブログを書いていますが）複数プロジェクトを1人で回す事も結構できそうです。
また今回はまだ MCP や Hooks などの機能を全く使えていないので、この1ヶ月ではその辺りを中心にさらに効率化を進めていきたいと思っています。
コメントを残す