Claude Codeで実際にできること30選 — 1年使ったエンジニアが本気でやってる業務まとめ
Claude Codeの「できること」を実際に1年使ったエンジニア視点で30個まとめた。コード生成、リファクタ、テスト、デプロイ、調査、ドキュメント、副業効率化まで。机上の機能紹介ではなく実体験ベース。
エンジニアのゆとです。
「Claude Codeって結局何ができるの？」という質問を、ここ1年でおそらく50回は受けた。
毎回、答えに詰まる。機能として列挙しようとすると「コード生成、バグ修正、テスト、ドキュメント…」みたいな無個性な羅列になる。でも「何でもできる」と言うと、「じゃあ今の自分の仕事に使えますか？」という核心をスルーした答えになってしまう。
この記事はそのジレンマを解消するために書いた。
1年間、フリーランスエンジニアとして Claude Code を本業と副業の両方で使い続けて気づいたのは、「できること」は機能の話ではなくワークフローの話だということ。だから30個を「僕が実際にどう使っているか」という視点で書く。型どおりの紹介ではなく、「これで詰まった」「これで時間が溶けた」「これで救われた」という体験ベースで。
全部読まなくていい。自分の仕事に近いカテゴリから読めばいい。
開発系（10個）
1. コードベース全体の把握
新しいプロジェクトに入ったとき、最初にやること。
cd inherited-project
claude
> このプロジェクトの全体像を教えて。主要ファイル、アーキテクチャ、認証の仕組み、テストの構成まで。返ってくるのは README の要約ではない。実際にファイルを読んで「この middleware.ts が認証ゲートになっていて、lib/auth.ts の verifyToken を呼んでいる。JWTの有効期限は30日。ただし tests/ ディレクトリは少なくて、middleware.ts 周りはほぼ無テスト」みたいな、実態に即した把握が返ってくる。
引き継いだプロジェクトが大量のファイルで構成されていても、最初の10分で骨格がわかる。以前は「まず3日間コードを読む」というフェーズがあったけど、今は「30分読んでClaude Codeに聞く」が当たり前になった。
効果: プロジェクト理解にかかる時間が体感で3日 → 半日。
2. 機能実装（複数ファイルをまたぐ変更）
「Webhookを受け取って、DBに保存して、Slackに通知する」みたいな、複数ファイルにまたがる機能追加。
以前は「どこに何を書くか」の設計だけで1時間使っていた。Claude Code なら:
> Stripe からの payment_intent.succeeded Webhook を受け取る機能を実装したい。
> 既存の認証フローを壊さずに /api/webhooks/stripe エンドポイントを作る。
> 処理内容: DB のオーダーステータスを更新、Slack の #orders チャンネルに通知。
> 既存のDB接続とSlack通知のパターンはこのコードベースのどこにある？コードベースを探索してから「lib/db.ts の updateOrder と lib/slack.ts の notify が使えます。エンドポイントは app/api/webhooks/stripe/route.ts に作れば既存の認証ミドルウェアをバイパスできます」という提案が出てくる。あとは「実装して」と言えばいい。
効果: 「どこに書くか」の調査と設計に使う時間がほぼゼロになった。
3. バグ修正（エラーメッセージから原因特定）
「本番でエラーが出た。スタックトレースがあるけど何が起きてるかわからない」という状況が一番助かる。
> このエラーが本番で出た。
> TypeError: Cannot read properties of undefined (reading 'id')
> at getUserData (lib/user.ts:47:23)
> 原因と修正を教えて。エラーの発生箇所だけじゃなく「lib/user.ts:47 の user.id を参照する前に、47行目より上の getUser() が null を返すケースがある。具体的には findByEmail が存在しないユーザーを検索した場合。const user = await getUser(email) の後に if (!user) throw new UserNotFoundError(email) を追加するか、呼び出し元でのガード処理を追加する」という形で、コードの文脈を読んだ修正案が出てくる。
効果: デバッグ時間が平均で半分以下になった感覚がある。
4. リファクタリング（コードの現代化）
「3年前に書いた処理系を現代のパターンに書き直す」というタスク。
Callback地獄を async/await に、古い CommonJS を ESM に、class コンポーネントを hooks に。全部やったことがある。
> auth.js の Callback パターンを async/await に全部書き直して。
> ただし外部インターフェース（エクスポートしてる関数の引数・戻り値）は変えないで。
> 書き直したら既存のテストを実行して、全部通ることを確認して。「外部インターフェースを変えない」「テストで確認する」という制約を渡すのがポイント。何も言わないと内側だけ変えて外を壊すことがある。
効果: レガシーコードの現代化にかかるコストが大幅に減った。ただし大規模リファクタは今でも自分でやる。
5. テスト生成（既存コードにテストを追加）
書いたコードに対してテストがない、という状況は日常茶飯事だった。以前はテストを書くのが面倒で後回しにしていたけど、Claude Code なら:
> src/lib/pricing.ts の全関数に対するテストを Vitest で書いて。
> エッジケース（0円、負の値、null入力、整数でない値）も含めて。
> 既存のテストパターン（tests/ ディレクトリ）に合わせて。既存のテストを読んだ上で、同じスタイルに合わせたテストが生成される。「既存パターンに合わせて」が重要で、これがないとテストフレームワークは同じでも書き方がバラバラになる。
詳しくは別記事で書いているのでこちらも。
効果: テスト書く心理的ハードルが激減。カバレッジが上がった。
6. コードレビュー（PR作成前の自己チェック）
コードを書いたあと、人間にレビューを投げる前にClaude Codeにチェックさせる。
> git diff main..HEAD を見て、コードレビューをしてほしい。
> 観点: バグの可能性、パフォーマンス問題、セキュリティ上の問題、可読性。
> 「問題なし」で終わらせるんじゃなくて、改善できる点を全部出して。自分が書いたコードは自分でレビューすると見落としが多い。Claude Codeは「この Promise.all は失敗した時に全部を巻き込んでrejectする。allSettled の方が安全では」みたいな、自分では気づきにくい指摘を出してくれる。
効果: 人間レビューでの指摘数が減った。レビュアーの時間を節約できるようになった。
7. Git操作（コミット・PR・ブランチ）
コードを書き終えたあとの Git 作業。
> 今の変更をコミットして。コミットメッセージは変更の意図が伝わるように書いて。
> Conventional Commits の形式で。> main ブランチに向けた PR を作って。
> タイトルと description は変更の背景・やったこと・テスト状況を含めて。コミットメッセージを「feat: update」みたいに雑に書いてしまう癖があったけど、Claude Code に任せると「feat(auth): add refresh token rotation to prevent token reuse attacks」みたいに意味のあるメッセージになる。
効果: コミット作業の後処理が自動化された。PR description の品質が上がった。
8. マージコンフリクトの解消
長く並行で開発していると避けられないのがマージコンフリクト。
> main との間でコンフリクトが出てる。両方の変更の意図を理解した上で解消して。
> 機能的に両立できる場合は両方残して、矛盾する場合は理由を教えてから聞いて。「矛盾する場合は聞いて」が重要。どちらを採用するかの判断を全部 Claude Code に任せると、意図しない変更が入ることがある。
効果: コンフリクト解消にかかる時間が短くなった。判断が必要な箇所だけ自分で対応できる。
9. 依存パッケージの更新（Breaking Changeの対応込み）
> package.json の依存パッケージを全部最新版に更新して。
> Breaking Change があるものは変更点を教えてから、コードを修正して。
> 最後に npm test を実行してテストが通ることを確認して。依存更新は「やらなきゃいけないのにめんどくさくて後回しにする」タスクの筆頭だった。特に Breaking Change がある場合は調査と修正で半日かかることも。これを丸ごと委ねられるのは地味に助かる。
効果: セキュリティアップデートのサイクルが速くなった。
10. 型定義の整備（TypeScript の型強化）
any が散らばったコードベースの型定義を整備する作業。
> src/types/ ディレクトリを見て、any が使われてる箇所を全部洗い出して。
> それぞれ適切な型定義に置き換えるための案を出して。
> まずは影響範囲が小さいものから対応して。TypeScript の型定義整備は地味に時間がかかる。型の伝播（どこを直したらどこに影響が出るか）の調査が大変で後回しになりがちだった。Claude Code はコードベース全体を見た上で「この any を直すと user.ts の12箇所に影響します」みたいな影響範囲の把握もやってくれる。
効果: TypeScript 化・型強化のハードルが下がった。
調査・学習系（5個）
11. 未知のライブラリを使う仕事の下準備
「使ったことないライブラリで実装してほしい」という案件は定期的に来る。以前は公式ドキュメントを2〜3時間読んでから着手していた。
今は:
> BullMQ（Redisベースのジョブキュー）を使ってバックグラウンドジョブの仕組みを作りたい。
> 基本的な使い方、このプロジェクトとの統合方法、注意点を教えてから実装して。ドキュメントを自分で読む前に「概要と注意点」を聞く。Claude Code が「BullMQ は v4 から ESM 専用になっています。このプロジェクトは CommonJS なので、dynamic import を使うか、設定を変える必要があります」みたいな落とし穴を先に教えてくれることがある。
ただし「知識のカットオフがあるライブラリ情報は古い可能性がある」という前提は常に持つ。公式ドキュメントの確認は別途行う。
効果: キャッチアップのスタートが速くなった。落とし穴を事前に把握できることが増えた。
12. 競合ライブラリの比較と選定
「date-fns と dayjs どっちを使えばいいか」「Zod と Yup、どう違うか」みたいな選定判断。
> このプロジェクトでバリデーションライブラリを導入したい。
> Zod、Yup、Valibot の3つを比較して。
> 観点: バンドルサイズ、TypeScript との親和性、学習コスト、このプロジェクトとの相性。
> 最終的にどれを選ぶべきか、理由とともにおすすめを出して。「このプロジェクトとの相性」という観点を入れるのがポイント。コードベースを見た上で「今すでに Zod を部分的に使っているので統一するなら Zod が自然です」みたいな文脈込みの判断が出てくる。
効果: 技術選定の調査時間が短くなった。「何を調べればいいかわからない」という状態が減った。
13. エラーハンドリングのパターン調査
「このエラーはどうハンドリングするのがベストか」という判断は意外と難しい。
> Next.js の API Routes でエラーハンドリングのベストプラクティスを教えて。
> このコードベースの現在のパターンも見た上で、何を改善すべきか教えて。「現在のコードを見た上で」というのが重要。一般論ではなく、今のコードとのギャップを教えてくれる。
効果: エラーハンドリングの一貫性が上がった。「どうすべきか」で詰まる時間が減った。
14. セキュリティの脆弱性チェック
> このコードベースにセキュリティ上の問題がないかチェックして。
> 観点: SQL インジェクション、XSS、認証バイパス、シークレットのハードコード、依存パッケージの既知脆弱性。自分で全部把握するのは難しいセキュリティの観点を網羅的にチェックしてくれる。ただし「Claude Code のチェックで安全」とは思わない。あくまで「見落としを減らすための一次チェック」として使う。
効果: セキュリティレビューの抜け漏れが減った。人間レビューの前段として有効。
15. パフォーマンスのボトルネック特定
「ページの読み込みが遅い。どこを直せばいいか」という問題。
> このAPIエンドポイントのレスポンスが遅い。コードを見てボトルネックを特定して。
> N+1クエリ、不要な再レンダリング、重いループ処理がないかチェックして。「N+1クエリ」という観点を明示的に渡すのが重要。何も言わないと表面的なチェックで終わることがある。コードを見て「この user.posts.forEach の中で毎回 DB クエリが走っています。include: { posts: true } で一括取得できます」みたいな具体的な箇所を指摘してくれる。
効果: パフォーマンス改善の調査フェーズが速くなった。
ドキュメント系（5個）
16. README の生成・更新
新しいプロジェクトを始めたときの README 生成。
> このプロジェクトの README を書いて。
> 含める内容: 概要、インストール方法、環境変数の設定、開発の始め方、テストの実行方法、デプロイ方法。
> 実際のコードを読んで正確な情報を書いて。「実際のコードを読んで」が重要。コードを読まずにテンプレートを貼り付けるような README になることを防ぐ。package.json の scripts を見て実際のコマンドを書いてくれるし、.env.example を見て必要な環境変数をリストアップしてくれる。
効果: README の質と鮮度が上がった。「コードは動くけどドキュメントがない」状態が解消された。
17. API ドキュメントの生成（JSDoc / TSDoc）
> src/api/ ディレクトリ内の全関数に JSDoc コメントを追加して。
> パラメータの型、説明、戻り値、エラーケース、使用例を含めて。
> 既存のコメントがある場合は更新して。ドキュメントコメントを書くのは重要だとわかっていても後回しになりがち。「型は TypeScript が守ってくれるから JSDoc は省略してもいいや」という誘惑に常に負けていた。Claude Code に任せると、引数の意味や意図も書いてくれるので、型だけではわからない情報が残る。
効果: コードの可読性が上がった。チームへの引き継ぎが楽になった。
18. 変更履歴（CHANGELOG）の生成
リリース前に CHANGELOG を書く作業。
> git log v1.2.0..HEAD を見て CHANGELOG.md を更新して。
> Keep a Changelog のフォーマットで。
> 機能追加、バグ修正、破壊的変更に分類して、ユーザー向けに書いて。コミットログをそのまま貼り付けるだけの CHANGELOG ではなく、「ユーザー向けに書いて」という指示を加えると「fix: null pointer exception」ではなく「ログイン後にプロフィールページが表示されないバグを修正しました」という形に変換してくれる。
効果: CHANGELOG 作成が5分で終わるようになった。
19. 仕様書・設計書の草稿生成
クライアントへの提出物として、実装した内容の設計書が必要なケースがある。
> 今実装した認証システムの設計書を作って。
> 対象読者はエンジニアでない PO。
> 含める内容: 概要、フロー図（Mermaid形式）、セキュリティ上の考慮点、制限事項。「対象読者がエンジニアでない」という指定が重要。技術用語を使った説明と、非技術者向けの説明は全然違う。
効果: ドキュメント作成の手間が大幅に減った。副業での追加対応コストが下がった。
20. コードコメントの追加（複雑なロジックの説明）
「なぜこう書いたか」がわかるコメントを後から追加する。
> src/lib/tokenBucket.ts のレートリミット実装にコメントを追加して。
> 「なぜこうしたか」という意図の部分を重点的に。コードを読めばわかる内容は書かなくていい。「コードを読めばわかる内容は書かなくていい」という制約が重要。// i に 1 を足す i++ みたいな無意味なコメントで溢れるのを防ぐ。アルゴリズムの選択理由や、一見奇妙に見えるコードに意図があることを説明するコメントが入る。
効果: コードの保守性が上がった。数ヶ月後の自分が混乱しなくなった。
自動化系（5個）
21. CI/CD パイプラインの設定
GitHub Actions や GitLab CI の設定ファイルを書く作業。
> このプロジェクト用の GitHub Actions ワークフローを作って。
> 内容: PR 時にテスト実行、lint チェック、型チェック。
> main マージ時に Vercel にデプロイ。
> 既存の package.json の scripts を見てコマンドを確認して。YAML の構文を毎回調べながら書く作業が不要になった。「既存の scripts を確認して」という指示で、実際に使えるコマンドを書いてくれる。
効果: CI/CD 設定の立ち上げ時間が大幅に短縮された。
22. データ処理スクリプトの生成
「CSV をこういう形式で処理して DB に入れたい」みたいなタスク。
> この CSV ファイル（フォーマットはこんな感じ）を読んで、
> PostgreSQL の users テーブルに一括インポートするスクリプトを書いて。
> 重複チェック、バリデーション（メールアドレスの形式確認）、
> エラーが出たレコードを別ファイルに書き出す処理も含めて。データ処理スクリプトは「動かして確認するまでの試行錯誤」が時間を食うけど、エラーハンドリングや境界条件をあらかじめ指定することで最初から使えるレベルのスクリプトが出てくることが多い。
効果: 単発のデータ処理案件が爆速になった。
23. 定期実行タスクの設定（Routines / cron）
Claude Code には Routines という機能がある。Anthropicのインフラ上でスケジュール実行できるので、ローカルPCがオフでも動く。
# Routines の設定
/schedule
> 毎週月曜9時に、先週マージされた PR をまとめて #dev Slack チャンネルに投稿する毎週の週次レポートや、定期的な依存パッケージのセキュリティチェックを自動化できる。「自分のPC上で実行」ではなく「Anthropicのサーバーで実行」なので、MacBook を閉じていても動く。
効果: 定期的な作業報告や監視タスクが自動化された。
24. GitHub Actions での自動コードレビュー
PR が作られたら自動でコードレビューを走らせる仕組み。
# .github/workflows/claude-review.yml
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: "このPRをレビューして。バグ・セキュリティ・パフォーマンスの観点で。"個人プロジェクトではセルフレビューが甘くなりがち。PR を開いたら自動でレビューコメントが入ることで、レビュー品質の底上げができる。
効果: セルフレビューの質が上がった。特にバグ混入が減った。
25. ログ解析とアラート
本番サーバーのログを解析してアラートを投げる処理。
tail -200 /var/log/app/error.log | claude -p "エラーのパターンを分析して。繰り返し出てるエラーがあれば原因を推測して。"パイプで繋ぐだけで、ログを読んで「DB 接続タイムアウトが過去1時間で47回発生。connect_timeout の設定か、DB のリソース不足の可能性」みたいな分析が出てくる。
効果: インシデント対応の初動が速くなった。「何が起きているか」の把握時間が短くなった。
副業効率化系（5個）
26. ブログ・技術記事の執筆補助
フリーランスの副業として技術ブログを書いているけど、「何をどう書くか」よりも「実際に書く」作業が時間を食う。
> 「Claude Code × TDD」をテーマにブログ記事の構成を作って。
> 対象読者: TypeScript で中〜上級のエンジニア。
> 一般論を並べるんじゃなくて、僕の実体験ベースで書けるようにアウトラインを。「一般論を並べない」という指示が重要。「TDD とは〜」から始まる記事ではなく、「先週、TDD で書いたコードがこういう理由でバグを防いだ」という切り口のアウトラインが出てくる。あとは自分の体験を肉付けするだけ。
効果: 記事の構成を考える時間が半分以下になった。
27. 提案書・見積書の草稿生成
クライアントへの提案書の草稿を作る。
> このプロジェクト（要件はこちら）に対する提案書の草稿を作って。
> 含める内容: 課題の整理、解決策、技術スタック、スケジュール案、費用感。
> 費用は時間単価 6,000円で計算して。提案書のフォーマットを毎回ゼロから作っていたのが、草稿を修正する形になった。技術スタックの選定理由や、スケジュールの内訳を説明する文章は Claude Code が書いてくれるので、自分は数字の確認と文体の調整だけ。
効果: 提案書作成が2時間 → 40分程度になった。案件獲得率が上がったかどうかはまだわからない。
28. 請求書・契約周りの確認補助
「この契約書の条件は標準的か？」という確認。
> この業務委託契約書のレビューをして。
> 特に: 知的財産権の帰属、成果物の定義、解約条件、損害賠償の上限。
> 自分に不利な条件があれば指摘して。法的な判断を Claude Code に任せるわけではないけど、「一般的な SES 契約と比べてこの条件は珍しい」という気づきを与えてくれる。「あれ、これ確認した方がいい」という箇所を見つけるための最初のフィルターとして使っている。
注意: 法的判断は必ず専門家（弁護士等）に確認する。Claude Code は「初期チェック」の位置づけ。
効果: 契約の確認漏れが減った。
29. 技術調査レポートの生成
クライアントから「○○ という技術を評価してほしい」という依頼が来ることがある。
> Temporal（JavaScriptの新しいDate API）の採用可否を評価して。
> 観点: ブラウザサポート状況、既存コードへの影響、移行コスト、代替案との比較。
> 結論と理由をまとめたレポート形式で。技術調査は「調べる → まとめる」の両方に時間がかかる。Claude Code は「まとめる」部分を担ってくれるので、「調べる」に集中できる。ただし知識のカットオフ問題があるので、最新情報は自分で確認する。
効果: 技術調査レポートの作成時間が短くなった。
30. Subagents での並列作業（複数タスクの同時進行）
これが一番「Claude Codeならではの体験」だと思う。
# ターミナルA
claude --worktree feature-payment
> Stripe の決済フローを実装して。テストも書いて。
# ターミナルB（同時に）
claude --worktree feature-auth
> JWT のリフレッシュトークン対応を追加して。
# あるいは、Subagents で1つのセッションから並列実行
> 以下を並列でやって:
> - Agent1: auth モジュールのテストカバレッジを80%以上に
> - Agent2: API ドキュメントの生成
> - Agent3: 依存パッケージの更新1人のエンジニアとして「同時に複数のタスクを並行で動かす」は物理的に無理だった。Claude Code の Worktree + Subagents を使うと、自分が1つのタスクをやっている間に別のエージェントが別タスクを進める、という形が取れる。
効果: 体感的な作業速度が1.5〜2倍になった。ただしコンテキスト管理が難しい。
できないこと（正直に書く）
30個「できること」を書いたので、逆のことも正直に書く。
曖昧な要件からの実装: 「いい感じの認証を作って」はほぼ機能しない。Claude Code は指示した通りに動くツールであって、要件定義の代わりにはならない。何を作るかは自分で考える必要がある。
本番リリース判断: 「このコード、本番に出していいか？」という最終判断はできない。ビジネスのリスク感覚、過去の障害履歴、チームの運用能力など、コードの外側にある文脈を持っていない。
人間との交渉・コミュニケーション: クライアントとの仕様すり合わせ、チームメンバーへの説明、ステークホルダーへのプレゼン。これは完全に人間の仕事。
長期的な設計の判断: 「今の設計、3年後も通用するか？」という問いに答えられない。技術的には正しいアドバイスをくれるけど、組織の方向性や市場の変化を織り込んだ判断はできない。
生成コードの無批判な使用: Claude Code が生成したコードは必ず自分で読む必要がある。「動いてるから OK」で終わらせると、意図しない挙動が本番で出る。これは経験則として強く感じている。
よくある質問
コストはどれくらいかかる？
Claude Code の Max Plan は月 $100（約15,000円）。
感覚としては、1日5〜8時間使って月 $100 以内に収まっている。使い方によって大きく変わるので、最初は従量課金のプランで試すのが安全。
初心者エンジニアにも使えるか？
使えるけど、正直に言うと「ある程度コードが読める人」じゃないと効果が半分以下になると思う。
生成されたコードが正しいかどうかを判断するためにも、コードを読む能力が必要。「生成されたコードをコピペして動けばOK」という使い方は、学習にならないし本番障害のリスクも上がる。
既存の IDE（VS Code、Cursor 等）と併用できるか？
できる。VS Code には公式の Claude Code 拡張がある。Cursor とも併用している人は多い（僕もそう）。
CLAUDE.md って何？
プロジェクトのルートに置くと、Claude Code が毎回読み込む設定ファイル。「テストは Vitest を使う」「コミットメッセージは Conventional Commits で」みたいなルールを書いておくと、毎回指示しなくて済む。
コードベースの規約、使用ライブラリ、禁止パターンなどをここに書くと、プロジェクト固有のコンテキストが保持されて生成品質が上がる。
セキュリティ的に大丈夫？
コードは Anthropic のサーバーに送られる。社内機密情報や顧客データを含むコードベースを使う場合は、利用規約や自社のセキュリティポリシーとの照合が必要。
.claudeignore を使うと、特定のファイルやディレクトリをコンテキストから除外できる。
まとめ
1年使って言えること。
Claude Code は「AIがコードを書いてくれるツール」ではなく、「自分の判断をベースに、作業を大幅に速くしてくれるアシスタント」だと思っている。
方向を決めるのは自分。生成されたコードをレビューして責任を持つのも自分。でも「決めた方向に進む作業」の大部分が Claude Code に移せる。
フリーランスとして1人で動いている自分にとって、これは「コード書く時間より考える時間を増やす」という変化をもたらした。それが一番の収穫だった。
始め方はこちらの記事が詳しい。
コンテキスト管理（長いセッションでの効率化）はこちら。
