半年間Claude Codeを使ってわかった、向いているタスクと向いていないタスク

CodeCraft Labを立ち上げる前後を含めると、Claude Codeを使い始めてからおよそ半年が経ちました。最初の頃は「何でも任せられるのでは」と期待しすぎて空振りした場面もあれば、「ここまで安心して任せられるのか」と驚いた場面もあります。今回は、その半年間の実感をベースに、向いているタスクと向いていないタスクを率直に振り返ってみます。

向いていたタスク

定型的なコード生成

CRUDのAPIエンドポイント、フォームのバリデーション処理、設定ファイルのひな形など、「パターンが決まっているもの」の生成は、半年通して最も安定して任せられた領域です。既存コードのスタイルを読み取らせてから依頼すると、命名規則やエラーハンドリングの書き方まで揃えてくれるため、レビューの負荷もかなり減りました。

リファクタリング

「このファイルの責務を分割してほしい」「重複しているロジックをユーティリティ関数にまとめてほしい」といった依頼は、テストが整備されているプロジェクトであれば非常に頼りになります。変更前後の挙動が変わっていないことをテストで確認しながら進められるため、安心して任せられる場面が多かったです。

テストコードの作成

実装が終わったあとに「このコードのテストを書いて」と依頼すると、正常系だけでなく境界値や異常系まで一通り洗い出してくれることが多く、自分では見落としがちなケースに気づかされることもありました。テストを書く心理的なハードルが下がったのは、半年間で得た最大の収穫かもしれません。

ドキュメント・コミットメッセージの生成

変更内容を要約してコミットメッセージを書いてもらう、READMEのセットアップ手順を最新の状態に同期してもらう、といった「言語化はできるが面倒」な作業は、ほぼ全面的に任せるようになりました。

向いていなかったタスク

高度なアーキテクチャ判断

「このサービスをマイクロサービスに分割すべきか」「状態管理ライブラリを何に統一すべきか」といった、複数の選択肢にそれぞれ妥当性があり、長期的な影響が大きい意思決定は、Claude Codeに丸投げしてうまくいった試しがありません。候補や論点の整理は手伝ってくれるのですが、最終判断には、プロジェクトの将来像やチームの体制といった、コードには書かれていない文脈の重みが必要だと感じています。

ドメイン知識が深く必要な意思決定

たとえば「この業界特有の端数処理のルールをどう実装に落とし込むか」のような、業務知識そのものを深く問われる場面では、こちらが正確な前提を与えない限り、もっともらしいが微妙にずれた実装が出てくることがありました。これはAIの限界というより、こちらの説明責任の問題でもあるのですが、「説明しきれない暗黙知」が多いタスクほど苦戦しやすいという実感があります。

長期間にわたる一貫性が求められる設計変更

数週間がかりの大規模な移行作業では、セッションをまたぐたびに文脈の再共有が必要になり、人間が「進捗の番人」として介在し続ける必要がありました。CLAUDE.mdやドキュメントに途中経過を書き残す運用でかなり改善はしますが、それでも「今全体としてどこまで進んでいるか」を俯瞰する役割は、結局自分で持ち続けることになります。

「AIに任せる」と「自分で考える」の境界線

半年間の試行錯誤を経て、筆者なりに見えてきた境界線は次のようなものです。

任せやすい: 検証可能 × パターンが既知 × 影響範囲が局所的
自分で考えるべき: 検証が難しい × 前例がない × 影響範囲が広い・長期的

ここで強調したいのは、この境界線は固定ではなく、自分の説明力とプロジェクトのドキュメント整備度によって動くということです。アーキテクチャ判断そのものは自分で行うとしても、「なぜその判断に至ったか」をCLAUDE.mdや設計ドキュメントに残しておけば、次にその文脈を踏まえた実装作業はClaude Codeに任せやすくなります。逆にドキュメントが何もない状態だと、本来は任せられるはずの定型タスクでさえ、前提共有のコストで割に合わなくなることがあります。

まとめ

半年間使ってきた結論を一言でまとめるなら、「Claude Codeは優秀な実行者であり、優秀な意思決定者ではない」ということに尽きます。意思決定は人間が引き受け、検証可能な実行はできる限り任せる。この役割分担を意識するようになってから、Claude Codeとの付き合い方は格段に楽になりました。次の半年でこの境界線がどう動くのか、引き続き本サイトで発信していきたいと思います。