Claude Codeを2週間使ってみた感想：実践経験とパワーユーザー視点のヒント

 (sankalp.bearblog.dev)
28 ポイント 投稿者 GN⁺ 2025-07-19 | 1件のコメント | WhatsAppで共有
  • CursorとClaude Codeを併用しながら、大規模コードベースでの実開発やLLM評価コンサルティングなど、さまざまな業務を経験
  • Cursorは便利なUI/UXと無制限のAPIアクセス性によりパワーユーザーから高く評価されていたが、最近厳しいレート制限が導入され、ユーザー体験が急激に制限された
  • Claude CodeのSonnet 4は、コード理解や編集、大規模コンテキスト処理などで高い信頼性と効率を示し、Opus 4との併用で難易度の高いバグも解決可能
  • コマンドベースのCLI環境、サブエージェント活用など、パワーユーザー向けのさまざまな高度機能が隠れており、継続的な実験と機能探索が重要な体験
  • 惜しい点としては、視覚的UIの不足、遅いコピー＆ペースト、他モデル活用の制約、チェックポイントなど、追加改善を望む点が残っている

CursorからClaude Codeへ：変化の背景

  • 最近までCursorは、無制限API利用と直感的なDiffレビューのワークフローにより開発者から支持されていた
  • そのため主にGumroad bountiesやAIエンジニアリング/LLM評価関連のアドバイザリー業務でコードを生成し、コードベースを素早く理解する過程で活用していた
  • しかし6月中旬以降、突然強力なレート制限が導入され、作業効率が急低下し、Cursor利用の利点が大きく減少した
  • Sonnet 4、Opus 4、GPT-4.1、Gemini Pro 2.5などさまざまなモデルの中で、実際にはSonnet 4とOpus 4の活用度が最も高かった
  • API料金負担、速度低下などの限界から、**Claude Code Maxサブスクリプション（月額200ドル）**まで検討し、本格的な移行を試みた

Claude Code実使用レビュー

  • Python、Ruby、TypeScriptなどの中〜大規模オープンソースコードベース（50M+トークン）にClaude Codeを投入し、仕様とテストによるフィードバックループを経験
  • 当初は単純な命令入力だけを使っていたが、基礎コマンドとplanモードを覚えるにつれ、より深い活用法を探るようになった
    • 単純な命令入力 → コマンド/計画モード習得 → 明確なコマンドの組み合わせによる自動化と生産性向上を実現
  • 問題解決の過程をまるで相談のように、自由に問題を投入してClaudeに全体の文脈を一気に渡し、必要に応じてOpusへ切り替えて計画を立て（Plan mode）、Sonnet 4で主要作業を進める混合戦略を使用
  • Claudeに**.claudeフォルダ内のファイル**へ記録・整理させることで、コンテキスト管理とコピー＆ペーストの不便さを緩和。Planモード/Auto-editモードの併用を推奨
    • コンテキスト管理: 圧縮(compaction)の代わりに定期的に新しいチャットを始め、重要な変更点は別ファイルにメモさせるよう促す

コンテキスト管理とサブエージェント活用

  • Claude Codeはコンテキスト圧縮をサポートしているが、遅く効率も低いため、自分で要点ファイルを作って新しいチャットを始める方法を好む
  • Scratchpadのような補助ファイルに変更点、メモ、履歴を記録させ、後のブランチ作業やセッション復旧（/resume）時に活用
  • サブエージェント: コードベース内で複数の作業（検索、分析など）を並列処理し、マルチスレッド構造で業務を分散可能
    • 内部的にはToDoリストベースのマルチエージェントが生成され、文脈管理に役立つ

検索とコマンド活用

  • Cursorでは通常/セマンティック検索、agentic searchなど多様なツールが使え、検索速度も速い
  • しかしClaude Codeの検索は遅いことがある。sub-agents利用時は大規模コードベース内で並列処理が可能
  • sub-agentとtask tool、/think、/ultrathinkなどのコマンド活用により、大規模リポジトリ探索と分業化を実現
  • Shift + ?ショートカットでコマンド一覧を見て、新機能をすばやく確認することが重要
  • ターミナルコマンド（bash）は!で、headlessモードでも実行可能
  • ファイルタグ（@ファイル）、memorize機能（ユーザー向けカスタムsystem prompt）、CLAUDE.md活用など、高度機能が多数内蔵されている

Sonnet 4 vs Opus 4比較とワークフローのヒント

  • Sonnet 4: 大半の状況でより高速で、長いコンテキスト+エージェント作業に強み。Python、フロントエンド作業で優位
  • Opus 4: Instructionsが何度も蓄積されると混乱しやすい傾向があり、その場合はファイルに記録して新しいチャット開始を推奨。Sonnet 4が行き詰まった際の高難度バグ解決に活用
  • 複雑な問題はOpusで始め、一般的なコーディングはSonnetで処理するハイブリッド運用を推奨

カスタムコマンドとその他のヒント

  • /pr-comments、/reviewなどのカスタムコマンドをサポート、Github CLIが必要
  • ブランチ変更時に会話を再開し、mainとの差分レビューなど、柔軟なワークフロー構成が可能
  • Escを2回で、会話中どこからでもフォーク可能
  • /permissionsでセッション前に権限調整が可能
  • 勇気があるならclaude --dangerously-skip-permissionsを使ってみる
  • Cluade Code Pro TIPS動画のおすすめ

今後試してみたいこと

  • カスタムコマンドを自分で定義して活用する方法を試してみたい
  • Playwright serverなどのMCPサーバーを活用し、フロントエンド自動化開発を試したい
    • Claudeがスクリーンショットを撮り、結果を認識してUIを反復的に改善するフィードバックループ構築に焦点を当てる予定
  • how-i-bring-the-best-out-of-claude-code-part-2で提案されている高度活用法をすべて実践してみる予定
  • プロンプト最適化に挑戦する予定
    • 評価基準（rubric.md）を明確に定義し、contextが入ったファイル（pmdなど）とともにプロンプトを評価/改善するループを設計したい
    • Claudeインスタンスを複数用意し、あるインスタンスがプロンプトで結果を出したら、別のインスタンスがそれを評価・フィードバックし改善する方式（単一またはマルチエージェントシステム）へ発展させる構想
    • この方式はNirantの投稿から着想を得た
  • 複数のClaude Codeインスタンスがアクションログを通じて相互通信するマルチエージェントシステムを構築してみたい

結論と改善要望

  • CursorはUI/UX面で非常に強い一方、Claude CodeはパワーユーザーやCLIに親和的な環境で、生産性と実験精神を刺激する
  • 探索的な学習と実験が大きな見返りをもたらすツールであり、Nerd/パワーユーザーに強くおすすめ

改善されてほしい機能

  • UI統合（Claudia参照）
  • Cursorのようなチェックポイント対応。Gitはあるが、Cursorの方式は非常に便利
  • コピー＆ペースト品質の改善
  • 多様なモデル利用への対応

関連記事

1件のコメント

 
GN⁺ 2025-07-19
Hacker Newsの意見

  • Claude Code を絶賛する人たちを見るたびに、まるで全員インフルエンサーか、ターミナルや Emacs、Vim のような伝統的ツールに熱狂するファンばかりなんじゃないかという感覚を拭えない。自分はいつも「Claude Code は Cursor よりはるかに良い」というコメントを見るたびに、実際に契約して大規模な TypeScript コードベースに適用してみるのだが、プロセスは時間がかかるし学習曲線もきつい。結果は結局 Cursor 内蔵の Claude と同じなのに、より遅くて曖昧で、コードレビューもしづらい。今では、コメント欄の熱狂的ファンはみんな支援を受けているか、すでに 200 ドル払ってしまったので自分の選択を正当化しているだけのように感じる。正直、Cursor のほうがずっと生産性が高かった。自分は 18 年目のプログラマーで、毎日たくさんコードを書くし、Gemini 2.5 Pro と Claude 4.0 を交互に使っているが、それでも Cursor のほうが得るものが多い。いまだに一人として自分を納得させた人はいない。実質的な利点が見えない。後で考えが変わるかもしれないが、今のところはまったく感じない

    • 多くの人が、ソフトウェア開発で本当に難しい部分が何なのかを深く誤解していると思う。実際の仕事の大半は複雑なアルゴリズム開発ではなく、既存のアイデアをうまく組み合わせてはめ込むことだ。だがそれらはすべて、事前の仕様策定・設計・アーキテクチャといった先行作業の後に来る。AI でこういうプログラムをさっと作るのは格好よく見えるし、デモではすぐに「終わった」ように感じるが、本当の問題は 30 年使うシステムを品質基準に合わせてきちんと作ることだ。プロトタイプや一回限りの用途には最高だが、長期的な耐久性には限界が大きい

    • こうしたツールで生産性を最大化するには、非常に短くて速いフィードバックループが核心だ。Cursor のタブ補完モデルは、エディタ利用者が何をしようとしているかを直感的に把握して、まるで狂ったように賢い減速機を踏んでくれる感じがある。自分で頭を抱えてマクロ的にプログラミングする必要はなく、不要なら Esc で取り消せばいいし、必要なら徐々に agentic モードへ移ればいい。完全なエージェント型エディタは 15〜30 分もかかるし、ワークフローが完全に途切れる問題もある。成果物をレビューすること自体が仕事になり、短い受け入れ／却下ループとは比べものにならないほど神経を使う。ネットワーク権限を与えるか、オフラインで動かすかという悩みも大きく、保守性・セキュリティ・信頼性が重要でないコードを急いで雑に作るときだけ試す価値がある。それ以外ではむしろ生産性が落ちる。今後改善はされるだろうが、現時点では間違いなく Cursor のほうが良い結果を出せる

    • 自分も以前はそう感じていたが、最近 Claude Code を実際に使ってみて、Cursor よりずっと良いと感じた。なぜかはよく分からないが、Claude のほうが全体構造をよりよく把握し、不要な修正を避けるのがうまいようだ。もちろん自分で方向を示さなければならない時もあるが、効率はずっと高い。特徴の一つは、普通は一度に 1 つのファイルだけをきっちり見せるので、レビューがはるかにしやすいこと。Cursor は複数ファイルを一度に開き、変更量も多くて素早く把握しづらい。ちなみに自分は VSCode のターミナルウィンドウで Claude Code 拡張機能を使っている。Claude が変更するファイルのタブを開いて、変更案を提示する

    • まだ多くの人が分かっていないのは、Cursor は 1 つの完成された製品というより、あらゆるツールが急いで追随しようとして追加している機能の寄せ集めだという点だ。本当の教訓は、ディープなインターフェースだけでなく、各自が好きなエディタにベストインクラスのエージェントソリューションを組み合わせる戦略もあるということ。こうした体験が最終的に「ベストプラクティス」として収束し、人々が自分のエディタや IDE に自然に適用するようになって、こういう vscode フォークはすべて消えていくだろう

    • 1 か月にも満たない期間、17 ドルのプランで使ったが、新鮮さと苛立ちが半々だった。Rust で 8,000 行、Markdown で 12,000 行を書き、作業仕様と具体的タスクを、まるでテストハーネスのように分離して AI とやり取りした。魔法のように見えるのが VC の補助金のせいなのかは分からないが、Rust がまるでスクリプト言語のように感じられるほどだった。（参考: GitHub リポジトリは knowseams）

  • AI の一番いいところは、面倒なときに「これやって」と言えることだと思う。出来が良くても悪くても関係ない。とにかく出発点を作ってくれる

    • LLM のおかげで白紙恐怖症がなくなった。複雑な文脈を頭の中で再構成しなくても、「自分たちは何をしていたんだっけ？」「このコードって何だっけ？」と聞けば、AI がすぐ説明してくれて、そのまま再び没頭できる。ラバーダックデバッグや反復的で細かな雑務（yak shaving）まで非常に速く処理してくれるので、本当に便利だ。Slack、Notion、Linear などとも連携して使っていて、自分にとってはタスク／プロジェクト管理ツールでもある

    • 自分で直接やりたいときでも、AI に計画を立てさせて Markdown に残している。今日も refactor 計画を頼んだが、40 ファイルからなるプロトタイプのコードブロックを下から構造変更するような、間違ったアプローチをしていた。もしその方向でミスしていたら、デバッグに膨大な時間がかかったはずだ。それでも攻め口は与えてくれたし、計画も 1 時間で修正して適用できた。自分一人だったら複雑さにうんざりして始めることすらできなかったか、文書化を繰り返して諦めていたと思う

    • 一日の終わりには、もう集中できず、書く量と巻き戻す量が同じくらいになってくるので、AI にハンドルを任せて一息つける。小さな問題なら diff を軽く見ればいいし、難しい問題でも何が問題かを具体的に分かっていれば、AI に方向性を与えて説得できる。作業の 40〜60% くらいまで完成したら、自分で引き継いで仕上げることが多い。普段は自分が頭の冴えている時間帯に集中して、自分で考えながら開発し、残業時間や反復的な雑務は AI に任せて、翌日の準備やより高次の文章作成・設計に充てている

    • 自分はただ散歩してコーヒーを飲む。人間の問題は人間的なやり方で解決するほうが、少し自然に感じる

  • Claude Code は言葉で説明しにくいほどだ。使って以来、まるで職業そのものを変えたような気分にすらなった。以前から Claude をワークフロー全面に導入していたが、Claude Code はまさに「ステロイド」級だ。まだ使ったことがないなら無条件で勧めたい。本当にジュニアエンジニアと一緒に働いている感覚を初めて味わった

    • 自分の経験は正反対だ。何か指示すると数分かけて何らかの結果を出してくるが、実際にはアプリが壊れていて、デバッグしてみると完全に見当違いの作業をしており、結局全部捨てることになる。それでも Claude を使い続けるのは、他の人たちのようにうまく回れば本当に素晴らしいからだ。現実にはボイラープレートを吐き出す程度で、かなり自分でデバッグする必要があり、最悪の場合は 1 時間とトークンだけ失う

    • 今日初めて会社で使ってみたが、Cursor より圧倒的に革新的な変化だった。同じ foundation model を使っているのに、体験はまったく違う。1 か月前までは AI のせいで仕事が遅くなっていたが、今日 Claude Code では 20 分で処理が終わり、API 利用料も 10 ドル未満だった。コンテキスト管理に気を遣う必要が非常に少なく、Claude Code は自分で必要な文脈を探しに行って入れてくれるので、はるかに長い時間、生産的に作業できる。Cursor の agent モードは 3〜5 分の作業までなら使い物になるが、Claude Code は 10 分を超える作業でも道を見失わず、着実に前進する。ツールの使い方も卓越していて、ループにはまりにくい点が驚きだ

    • 「ジュニアエンジニアと働いているようだ」と言っていたが、自分の感覚ではむしろ自分が部下で、Claude が上司みたいだ。「こんなすごいものをやりました！」と自慢すると、「でもそれは私が指示したことじゃないよ……」と返される感じだ

    • どんな作業、言語、ドメインで活用したのか、もう少し具体的に説明してもらえる？ みんなケースが違いすぎるので気になる

    • 自分も同じ経験だ。Claude は単なるジュニア以上だ。選択肢の提案、意思決定のための推奨、そしてトレードオフの可視化が本当にうまい

  • 実際に Claude Code でアプリやライブラリを作るウォークスルー事例はあまりないのだろうか？ 単に「すごい」という話ではなく、本当にそのツールで実戦開発している様子を見たい。そういう事例のまとめがあると本当にありがたい

    • 全体的に少し奇妙な状況に感じる。Claude Code 自体は確かに良くて、ドキュメントや Stack Overflow をずっと速く探すのに使える。でも、もし誇張された噂が本当なら、こういうツールで猛烈なスピードでソフトウェアイノベーションが起きていないとおかしくないかとも思う。Stripe の CEO は AI ツールで生産性が 100 倍になると言っていたが、3〜4 か月たっているなら、今ごろ Stripe はロケットでも打ち上げていないと変じゃないか？ Microsoft も AI コーディングに全振りしているというのに、Teams はなぜ相変わらず微妙なのか。1 年以上このツールが革命だと言われているのに、実際の現実は 3〜4 年前と大差ないように見える

    • 最近目立つ 2 つのトレンドは、(1) 非熟練者が小さなプロジェクトに AI を使うこと、(2) 開発者がアプリ全体の構造、ファイル、インターフェース、テックスタック、テストフレームワークまで事前にぎっしり仕様化しておき、LLM に細かく扱わせて、ようやくそこそこの結果を引き出すことだ YouTube の例。PR や YouTube などで語られる 80〜99% の話は、実質的に前者のグループから出ている。生産性が上がったと感じるのは、LLM と会話し、文書化し、誘導し、修正することが、直接開発するより疲れにくく感じられるからだ。時間や総労力が同じでも、心理的負担が軽くなる

    • YouTube で本当に生産性ブーストを出している現場のストリームや事例を探しているが、「うわ、本当に速い！」と感じたケースは見たことがない

    • 賛否両極端の意見が多いが、大半は静かに各自コミットしている（この言い方自体が皮肉だが）。自分の場合、作業によって 1.5〜10 倍速くなるのを本当に体感している。最大の利点は、純粋に創造的・一回性・ボイラープレート・リファクタリング系の作業で認知負荷が大きく減り、安定して成果を出せることだ。依然として「手でコードを書く」ことも多いし、ほぼすべての行を最後までレビューしている。何時間も単独で走らせるのは Nightmare だ。実際、10 年以上運用中の本番アプリでも、どこかのブログに宣伝する時間などない。一方で、自分は非常にスリムな組織にいてシステム全体の文脈も手元にあるので、問題をより速く把握できる面も大きい。自己効率の確保が重要な環境では確実に土台を強くする。大規模組織ではこういう体験は得にくい

  • 自分の経験では、Claude.md という Markdown ファイルを各コードフォルダのルートに置いて、パイプラインのような最小限のルールセットを追加する。テスト生成や配置を指定されたフォルダと方式に必ず合わせさせ、デバッグファイルの生成を防ぐ。新しいクラスや構造が乱立しないようにし、必要な場合以外は再利用するようルールを置く。プロンプトも長々とは書かず、たいてい不確実な部分だけ計画書を書く。LLM の知識範囲を超える新しい問題にも、大きな入力は最小限しか渡さない。こうすると 1 input–1 output（深い層まで全部適用）の結果を一貫して得られる。最近は Claude Code の代わりに CLI モードで Opus など他の大型モデルをより安く使うように移行した。CLI こそ本当の力だ。60〜70 のエージェントストリームを同時に回していて、2 億トークン規模（react/typescript/golang）のコードベースも無理なく管理している。追加指示を出したのはせいぜい 1〜2 回だけだ

    • エージェントストリームで何を運用しているのか、一覧にできる？ かなり気になる

    • Anthropic 以外にどのモデルを使っているのか知りたい。Kimi K2 は試したが、自分の用途にはいまいちだった

    • 「エージェントストリーム」とは何を意味しているのか気になる。60〜70 個をどう管理しているのか、認知負荷が想像もつかない

  • たまに Claude Code で特定の作業をすると、生産性が劇的に上がる。Slash command を活用して、過去の会話を slash command にする方法を勧めたい。こうすると、だんだん使い回せるプリミティブなコマンドセットを積み上げていける。自分の例は GitHub に置いてある make-command.md, improve-command.md

    • 非決定論的なブラックボックスをプログラミングしようとしている点が本当にすごいと思う。勇気がすごい

  • PSA（お知らせ）: このリポジトリ を使えば、どんなモデルでも Claude Code と連携できる。最新の Kimi-K2 でもかなりうまく動くと言われている

    • 自分も Kimi-K2 を試したが、Sonnet/Opus 4.0 より性能は落ちる一方で、tool calling は Gemini 2.5 Pro より良いほうだった。Claude Max（月 100〜200 ドル）が負担なら強く勧めたい。モデル自体が無駄のない非常にシンプルな作りで良い。Anthropic もいっそ Claude Code をオープンソース化すれば、CLI coding agent 界の VSCode になれるかもしれない。それから opencode も勧める。すべてのモデルをネイティブサポートし、Claude Code に似た機能を提供する

    • 複数モデルで使うなら sst/opencode をそのまま勧める（自分も Claude Pro で使っている）

    • ちなみに、まだ CC を使ったことがない人向けに言うと、CC クライアントは npm で入れて無料で使える

  • Claude Code、local LLM、Continue、VSCode で簡単な Python アプリを「vibe coding」して遊んでいて、Claude の無料枠を知って、進行中のコードと LLM の結果を入れてみた。エラーや更新点を一度で正確に整理・修正してくれて感動した！ そこで次の段階として、pygame ベースの 2d ゲーム（マニックマイナー風）プロジェクトの仕様とプロンプトを ChatGPT で作って Claude に入れてみたが、Claude が存在しないメソッドを参照し続けたり、コードベースのバージョン差だの何だのと的外れなことを言ったりする。行番号や周辺コードをピンポイントで示しても、まだ gaslighting されている感じだ。どう解決すればいいだろう、完璧は求めていないが、local LLM のときと似た限界にぶつかっている感覚がある。健康があまり良くなく、断続的にしかできないので助言が欲しい

    • 「曖昧なインターフェースと隠れた前提だらけのコード地獄」に落ちている可能性が高い。こういうときは、むしろ既存の ChatGPT の結果を全部要約して、現在のゲームが何をするのか／すべての機能を深く列挙した文書を作り、それを Claude に渡して要件を最初から再度 break down させたほうが、ずっときれいな結果を得られる。Claude は zero-shot でも優れたサンプルを出せるし、最悪でも反復的に自分でブラッシュアップできる。それでも Claude がとんでもない機能を作るなら、context7 MCP サーバーをインストールして、Claude に context7 を使うよう明示的に要求するのを勧める

    • これは LLM 技術の根本的な限界だ。確率的に「最ももっともらしい」トークン列を出力するが、「もっともらしさ」と「正確さ」が一致しないなら打つ手がない。各 LLM ごとにこの「もっともらしさ」の基準は学習やファインチューニングごとに異なる

  • 基本設定のあと、このツールをうまく動かすためにどんな追加の工夫をしているのか気になる。つまり、文脈/context やコードベース構成の面で、ツールが自力で正しい方向をつかめるようにする実務的な方法が何か、ノウハウを共有してほしい。自分なりの考えは この記事 にまとめてある。もっと良い方法論は今後も出てくると思う

  • Claude Code ではさまざまなアルファを得ているが、チーム全体に広げるのが悩みだ。チームメンバーや自分が管理している人たちが Claude Code を効果的に使えるようにするための、実務的なヒントやベストプラクティスの共有方法があれば知りたい