Claude Codeを6週間使ってみた記録

 (blog.puzzmo.com)
37 ポイント 投稿者 GN⁺ 2025-08-07 | 7件のコメント | WhatsAppで共有
  • Claude Code を導入して以来、大規模なコード作成と保守のやり方が大きく変化し、「コーディング界に写真術が導入された時期」にたとえられるほど、高速な実装と自由な表現が可能になった
  • 反復的で「技術的負債」と見なされていた作業（マイグレーション、フレームワーク置き換えなど）も、1人でも素早く並行処理でき、本来の業務と並行してもほとんど負担がない
  • 「まず使ってみて後で判断する」という実験的な開発パターンで、テスト／抽象化／実験コードを手軽に生成・削除しながら、開発生産性と洞察を得られる
  • ゲームのプロトタイピング、協業、実験的デプロイが大幅に加速し、ゲームデザイナーがコードなしでアイデアから実行までを数時間で実現できる
  • モノレポ、明確な技術スタック、最新のコードベースなど Claude Code と相性のよい環境では、実際の開発業務の速度と柔軟性が大きく向上した

序論: Claude Code導入後の変化

  • この6週間 Claude Code を活用してきて、コード作成と保守のやり方に重大な変化を感じた
  • すべてのコードを自分で直接書かなくてもよい、**「表現の自由」**が生まれたように思う
  • Claude Code を使えば、一度に全体構造を構想し、レビューと編集の能力を通じて成果物を作り上げられる
  • 写真の登場によって手で絵を描く魅力が薄れたように、いまやプログラミングの入力と生産のプロセスは大きく変わりつつある
  • この変化は不安に感じられるかもしれないが、LLM ベースのツールの登場はプログラミングにパラダイムシフトを起こしている

1. Claude Codeが変えたコード作成と保守の方法

  • 以前は数週間から数か月かかっていたマイグレーション、リファクタリング、技術的負債の解消作業を、Claude Code 導入後の6週間で並行して完了できた
  • 例: 数百の React Native コンポーネントの React への移行、RedwoodJS システムの置き換え、Jest→Vitest マイグレーション、サーバーサイドレンダリング、デザインシステムのリファクタリング、Node 22 へのアップグレードなど
  • これまでは「別途スケジュールを確保して処理」する必要があったサイドプロジェクトやバックログも、本業と並行して空き時間に処理可能で、業務負担はほとんどない
  • 従来の「技術的負債は日程確保→大規模投入」という定石が崩れ、**その場で開始→進行→完了までの“即時性”**が実現された

2. 「まず使ってみて後で判断する」実験的な開発文化

  • アイデアが浮かんだら Claude Code でまず試し、テストコードなども初期段階で自動生成・削除を繰り返しながら学習する
  • フロントエンドのテスト戦略がなくても、Claude Code で各 PR ごとにさまざまな方式のテストをその場で生成／削除し、経験を蓄積して全体方針の決定に役立てられる
  • アイデアや抽象化についての検討も、「まず試す→失敗しても負担がない」方式で素早く検証・探索できる
  • 失敗コストが劇的に下がり、実験-学習-意思決定のサイクルが大幅に加速した

3. 並列開発と協業の方法の変化

  • 2つの git clone / VSCode プロファイルを活用し、各 clone ごとに独立した作業（例: 片方は PR 作成、片方は実験的開発）を進める
  • Claude Code が作業している間に別の clone で並行作業したり、各 clone のテーマやポートを変えて明確に区別したりする
  • Pull Request を並列に作成し、開発サーバーのポート衝突を防ぎつつ作業効率を高める
広告

4. ゲームプロトタイプ／実験開発プロセスの革新

  • これまでは数週間から数か月かかっていたゲームプロトタイプ制作→社内配布→フィードバック→公開／廃棄の工程を、Claude Code 導入後はデザイナーでも数時間で自らコードを書いてサイトにデプロイできるようになった
  • アイデア→実行→チームからのフィードバック→実験終了／プロダクション移行（再実装）といったデプロイのサイクルが劇的に短縮した
  • ただし、一時的なゲームの管理や正式化／廃棄の基準など、新たな運用上の悩みも伴う

5. 日常的なコーディング／協業でのClaude Code活用

  • 週次 triage では、Claude Code GitHub アクションを活用してその場で PR を生成／実験し、小さな課題はすぐ適用する
  • プロダクトと技術の両面の能力と主体性を持つチームメンバーが Claude Code を最も効果的に活用できる、いわば「フルブレッド開発者」
    • "Full-breadth developers" : 1人の開発者が作業全体の流れを自由にリードできるよう支援する
  • コードレビュー、文脈の提供、修正と意思決定の役割を人間が維持するとき、チーム全体の生産性と創造性が向上する

6. Claude Codeと相性のよいコードベース環境

  • モノレポ: コード全体、DB スキーマ、API、画面ロジックが1か所にあるため、Claude Code が文脈を把握し自動化作業を行うのに最適
  • **標準化された技術スタック（React, Relay, GraphQL, TypeScript, StyleX, Bootstrap など）**を採用すると、LLM が理解・自動化しやすい
  • コードベースを最新化し、レガシーを最小化することで、LLM 活用の効率を最大化できる

7. Claude Codeの限界と実際に感じた変化

  • PR 数やコミット数など定量的な変化は大きくないが、業務で体感する速度・柔軟性・生産性は大きく向上した
  • Claude Code は**「経験豊富なジュニア以上」のペアプログラマー**として機能し、エンジニアがコード品質・ロジック・コンテキストを管理すれば最高のパートナーになる
  • 反復作業や技術的負債の解消、迅速なサイドプロジェクト推進など、質的に異なる業務体験を提供する

8. ジュニア／学習者に勧める「並行実装」戦略

  • LLM エコシステムの最新トレンドに過度に執着する必要はない
  • 初学者には、まず自分でコードを書いた後に、同じ課題を Claude Code に依頼して、比較・分析しながら学ぶことを勧める
    • Claude Code の解法を参考にして、多様な抽象化や実務パターンを素早く習得できる
    • LLM を「競争相手＋メンター」として活用し、実務能力と最新エコシステム感覚を同時に伸ばせる
    広告
  • Claude Code は携帯電話のようなもので、常にオンにしておく必要はない
    • 最終的には主導権を持って効率的に使うことが重要だ

9. サイドプロジェクト／短期実験の爆発的増加

  • 以前は時間やエネルギーの制約で試しにくかった小さな実験、ツール開発、ブログ改善なども、Claude Code なら数時間で実現できる
  • アイデア→即実装→失敗しても負担なし、という流れで、プロダクションとは別に創造的な実験や個人プロジェクトを並行しやすい

10. 実際のClaude Code対話・コードレビュー事例

  • DB 整理スクリプト、パズル REPL、クロスワード PDF レイアウトなど、具体的な要求→コード生成→実行→修正→レビューの流れの実例がある
  • LLM には誤り（推論ミス、誇張、ハードコーディングなど）が起こりうるため、エンジニアが論理的検証と品質責任を必ず担ってこそ実質的な価値が得られる

11. Claude Codeのエンジニアリング上の位置づけと結論

  • Claude Code は参考コード、スクリーンショット、追加説明などの広い文脈を取り込む能力に優れている
  • Claude Code は**「Post-Junior（熟練ジュニア以上）」レベルの補助プログラマー**であり、無限の忍耐と速度で実務パートナーとして非常に効率的に機能する
  • 設計／品質／最終コントロールは人間のエンジニアが担い、Claude Code は実装・実験・自動化の範囲と速度を大きく拡張する
  • 「自分で1行ずつコーディングしなければならない」という制約から離れ、設計・品質管理・革新により集中できる開発環境が実現する

関連記事

7件のコメント

 
benjamin 2025-08-08

私もClaude Codeをとても満足して使っています。
私ももう6週間ほど使っている気がしますね。
内容の大半に共感します。

https://jeho.page/essay/2025/07/15/claude-code.html
 
GN⁺ 2025-08-07
Hacker Newsの意見

  • 約2週間Claude Codeを使ってみた結果、普段はAIコーディングに懐疑的な立場だったが、本当に驚かされた。慣れるには多少の学習曲線があり、適切なコンテキスト提供とタスク分割が必須。もちろんプログラミングの実力も必要で、分からないことを丸ごとAIに投げると必ず問題が起きる。25年以上の経験があるので、Claude Codeがどんな結果を出してもレビューし、間違っていればすぐ修正できる自信がある。10〜15年前にはコードを直接書かなくてよい神経インターフェースのようなものを夢見ていたが、Claude Codeはある程度それを実現している感じがする。たまに1日の利用上限に達してGemini CLI 2.5 proモデルを代わりに使ってみたが、Claude Codeとは比較にならない。Geminiはもどかしすぎて使えない。昔は月100ドルを超える開発ツールを使うなんて想像もできなかったが、Maxプランへのアップグレードを真剣に検討している。

    • シニア開発者がジュニア開発者に助言やガイドを与えられる状況なら、このツールは相性が良いと思う。周囲のシニア開発者の話を聞くと、ジュニアはむしろLLMでさらに妙なコード、遅いコード、セキュリティに脆弱なコード、あるいは完全にめちゃくちゃなコードを作り、それを理解しないままPRに上げてくるという不満が多い。自分にとって最も有用なのは、ボイラープレート生成（説明だけでクラス設計まで出してくれる）、JSONをクラスや別形式へ変換すること、そして「このコードの何が問題？ Staff級エンジニアならどう直す？」のような質問だ。実際、自分が直接打ち込んだコードのバグをClaude Codeが先に見つけたこともある。

    • 興味深いのは、「vibe coding」に懐疑的な人たちは、実際にツールを使ってみるまで期待値がものすごく低いことだ。多くの人がLLMの出すコードはゴミだと思い、極端な事例だけを平均だと見なしている。しかし実際に使ってみると、予想以上に良いことに自分で驚く。もちろんClaude Codeで10人チームだけで10億ドル規模のSaaSをさっと作れるわけではないが、それでもツールの実際の力を過小評価している人は多い。

    • 実際、厳密に言えばあなたはvibe codingをしているわけではない。AIを活用したソフトウェアエンジニアリングに近い。vibe codingとは、AIがどんなコードを出してきてもそのまま使い、理解もないまま進み続けることを意味する。用語の定義は人によって違うので、vibe codingという言葉自体はあまり信用しない方がいい。

    • 自分もほんの数か月前まではどんなサブスクリプションサービスにも20ドル以上払ったことがなかったのに、今は毎月Max 20プランに200ドル払っている。アメリカ在住のスロバキア出身で、20年のキャリアを持つ開発者だが、それでも自分で驚いている。他のツールも使ってきたが、ここまで直接的に生産性や効率を体感できたことはなかった。Claude Codeは本当に次元が違う。もちろん継続的に細かく面倒を見る必要はあるが、自分のやり方はPlan Modeで徹底的に要件とコード変更計画を立て、それに100%納得したら実行させ、その結果をコードレビューする流れだ（コンパイラエラー、ユニットテスト、lintの問題はAIが自分で直す）。少し変だが知識豊富で、とてつもなく速いジュニアエンジニアがいる感じだ。ソフトウェア開発の方向性は間違いなくこちらに向かっており、未来だと思う。

    • 最近のClaudeモデルはSQLの作成・修正に関しては信頼性が低いと感じる。たとえば条件節はうまく作るが、AND/ORを括弧で囲まないことがあり、Gemini proがそこを正しくバグとして指摘してくれた。

  • Claude Codeがあらゆる競合ツールより明確に先行しているという点に強く同意する。2023年からAIコード生成用のcliツールを自作していて、主要な選択肢はほぼすべて試してきたと言える。筆者のいくつかの方法論には深く共感する:

    1. モノレポは多くの時間を節約してくれる
    2. 明確な仕様から始めること、そしてその仕様に十分な時間をかけること。良いアウトラインさえあれば、AIが仕様の大半を書いてくれる
    3. 最初から必ずテストを用意すること。これが最も重要。良いテストと仕様があれば、AIはより良い解決策を再帰的に探索できる。TDDが戻ってきた感じがする
    4. 型とリンターは非常に大きな助けになる
    5. 外部ドキュメントはプロジェクト内の別ディレクトリに整理して置いておくとよい（例: docs/external-deps）
    6. どのツールでもそうだが、自分に合ったテクニックを身につけるには多少時間が必要。以前よりは簡単になったが、それでも学ぶべきことはある。各自のワークフローが少しずつ異なるので、むしろコーディング工程そのものに近い感じがする 最近、Permiso(https://github.com/codespin-ai/permiso)という超シンプルなGraphQL RBACサーバーもvibe codingで作った。まだ安定してテスト・レビューされたプロジェクトではないが、シンプルなものが必要な人にはすでに役立つかもしれない。

    • 2番目の項目（良い仕様から始めること）について、具体的にどうやって仕様を整理しているのか気になる。Markdown文書として切り出すのか、どの程度まで詳細が必要なのかなど知りたい。また「最初からテストを用意せよ」という助言には共感するが、実際にはClaudeがテストのフックがあると、むしろ先にテストコードを書く過程を飛ばして、バグや前提の検証もなく修正だけを繰り返すこともある。テスト関連の挙動をオン・オフするフラグを作って使うこともある。

    • モノレポはあなたの時間を節約してくれるが、Claudeのツール呼び出しやトークン消費はずっと増える。Aiderのように必要なファイルだけ選んでAIに渡す方が良いと思う。Claudeがなぜこれほど人気なのかあまり理解できない。Aiderはほぼすべての面でより優れたツールで、さまざまなLLMも連携して使える。

    • CCをきちんと使うには、プロジェクト構造がしっかり整っている必要がある。Djangoプロジェクトでテスト、型、ドキュメントが整っている状態では、CCがほぼ何でもうまくやってくれたが、途中途中でガイドは必要だった。最近はCCをオフラインでローカルモデル上で動かすサイドプロジェクトも進めている。最初のバージョンはChatGPTの助けでうまく作れたが、CCに移ると、CCはむしろ核心的な問題の周りをぐるぐる回ってミスを回避し、既存コードのリファクタリングやバグ修正の代わりに、新しいファイルやスクリプトを次々作りたがる癖を見せる。

    • 外部ドキュメントをプロジェクト内に直接整形して入れているのか気になる。ほとんどのプロジェクトはドキュメントがWebサイトにしかないが、わざわざきれいなMarkdownファイルを作るために時間をかけているのか聞きたい。

  • Claude Codeの真の力は、単なるコーディングを超えてコンピュータ全体を制御できる点にある。CLIツールがあればClaudeはそれを使えるし、なくてもClaudeに聞いてみると驚かされることが多い。たとえば画像のクロップやリサイズ、YouTube動画からmp3を抽出すること、音声ファイルの無音部分を削除することなど、雑多な作業をすべて任せてきた。そのおかげで膨大な時間を節約できている。以前どうやっていたのか思い出せないくらいで、もう昔のやり方には戻れない気がする。

    • Claudeには自分の実際のコンピュータをつなぐよりも、（常に自分のPCではない）別のコンピュータを与える方がよい。自分の場合はクラウドVM上でIDEを動かし、そこにClaudeを接続してブラウザからアクセスしている(https://brilliant.mplode.dev)。自分としては、この方式がエージェント運用に最も近い最適なUXだと思う。ターミナルやsshの準備なしにログインするだけでよく、インスタンスは自動生成・一時停止される。つまりClaude + 個人用Linuxインスタンス + IDEをリンクひとつで立ち上げられるわけだ。今後はインスタンスを好きなだけ複数起動し、権限、ファイルシステム、コンテナ権限（JWTなど）も細かく制御する予定だ。もし障害やレビューが必要な状況になっても、IDEにそのまま入って解決できる。別途UIも不要で、IDE内の複数パネルで見ることも、コンテナ内でWebアプリを立ち上げて直接使うこともできる。今ほど技術の進歩に興奮したことはない。

    • 何もかも良さそうに見えても、実際のコード成果物だけを見ると、データ上は前後でほとんど差がない。Claudeで作業してもコミット、PR、コード行数は以前と大差ない。つまりAIコーディングは「生産性が上がった」という感覚や、「自分が手を動かさずに何かを作れて気分が良い」という気持ちはあるが、実際には大量のレビュー、修正、再プロンプトが必要で、結局アウトプット総量は似たようなものだ。そして難しい部分をAIに任せることで、自分自身の設計力や思考力が徐々に弱くなっていく。1か月間ClaudeなどのLLMだけを使った後で、自力で小さなアプリを作ろうとすると、コードだけでなく全体構造の設計自体も難しく感じる。長期的にはコードベースがゆっくり壊れていき、最終的にはマイナスになる危険も大きい（少なくとも今世代のLLMでは）。

    • 昔はImageMagickのmogrifyコマンドを古いやり方でひとつひとつ手作業で組み立てていた。AIツールの支援を受けるようになって、狂ったように時間が節約できている。

    • Linux PCが何度もクラッシュする原因の診断をClaudeに頼み、journalctlでログを引っ張って原因まで突き止めてくれて大いに助かった。問題解決にも直接役立った経験だ。

    • 別の例として、静的サイト生成が非常に簡単になった。どんな文法で書いてもClaude Codeに「この投稿をブログ用フォーマットにして」と頼めば、勝手にやってくれる。たとえば「画像 image.jpeg を入れて」と書くだけですぐ対応してくれる。MarkdownやHugoフォーマットに縛られなくて済むので便利だ。

  • Claude Codeを1日12〜16時間使ってきた者として、次のようなコツを見つけた:

    1. 起動したらすぐsonnetモデルに切り替えること（opusとは品質差が大きい）
    2. compacting（会話ログ圧縮）は進行中に品質が大きく落ちるので、最適なタイミングを見極めるべき
    3. 最初のプロンプトが非常に重要で、セッションの性格はここで決まる。もしClaudeインスタンスが躊躇したり不親切になったら、そのセッションを終えて新しく開き直した方がよい
    4. 「これはあまり良くない案かもしれませんが、〜を実装したいです」のように丁寧に頼むと、ずっと積極的に助けてくれる傾向がある
    5. DockerオーケストレーションをClaudeに任せると、生産性が10倍になったように感じる。コンテナの再起動、エラーログ確認、削除/再ビルドなど、全体フローをClaudeに任せて、一度のプロンプトでサービス全体を立ち上げられるようになった

    • 5番はDocker以外にもplaywright MCPサーバーと連携すれば、UIやリクエストもその場ですぐ確認できる。6. まず計画モード（plan mode）で始めて、計画が気に入るまで繰り返し修正する 7. スラッシュコマンド（/コマンド）機能を積極的に活用し、ミニプロンプトで継続的な改善とコンテキスト提供、ghなど外部ツール活用の指示まで含める compactingは0%の状態からいきなりやるのではなく、適切な中間で適用するのがよい 1番（sonnet推奨）には同意しない人もいるかもしれない。

    • Dockerは避ける傾向があるが、5番のコツ（ClaudeでDockerオーケストレーション）がとても気になる。どんなプロンプト形式を使っているのか知りたい。

    • かなり詳細なplan.mdファイル（システム間の接続、全体構成など）から作り始めて、claude-loop(https://github.com/DeprecatedLuke/claude-loop)のようなツールで一晩回し、朝に手動でパッチするやり方も成功した。

    • Claude Codeを1日16時間もどう使っているのか気になる。

    • ときどきClaudeがコンテナ内部をかき回しすぎることがある。単にコードを理解させたかっただけなのに、コンテナ内で無数の方法でコードを実行しようとして、かえっておかしくなったこともある。以前、ファイルをcliコマンドにパイプして何も起きない動作をしていたこともあったが、何か執着的に実行したがる傾向の例だ。

  • Claude Codeが実際にどれほど良いのかは分からない（自分では使ったことがない）が、個人的に悩んでいる点がある。非常に遅くて散らかったgdscript（Python系）をC#にリファクタリングしたい。もっときれいで速くしたい個人プロジェクトだ。この作業は自分にとって新しい挑戦で、学びの要素も大きい。Claudeを使うと、学べるはずの貴重な機会を自分で奪ってしまう気がするし（長期的な成長にも役立ちそうだ）、使わないと、実際には今後自動化されるような退屈な作業に貴重な時間を浪費している気持ちになる。そんなジレンマが繰り返される。

    • 35年の開発経験の中で、どんなLLMでも自分で解けるがやりたくない時（退屈、反復的）だけAIに任せる方式を取っている。たとえばOpen API 3.0スキーマの修正も、自分でやっても学びがないのでClaudeに任せたし、サンプルコード生成もAIにやらせる。本当に新しく学ぶポイントがある時は、Anki SRSのようなアプリにフラッシュカードとして整理したり、TILブログに書き留めたりする。あるいは自分でサンプルを何度も実装して経験値にする。重要なのは、新しい学びを脳に少なくとも2回以上結び付けることが効果的な学習になるということだ。新しい自然言語の単語を覚えるとき、3つの文に組み込んで使ってみるようなものだ。

    • 生成されたコードを自分でレビューしないと（つまりC#を十分に身につけていないと）、コードベースはあっという間に壊れる。LLMコーディングはエラーが蓄積しやすい傾向があるので、必ず改善が必要だ。そうでないと保守不可能なゴミの山になる。周りの友人たちは、AIに十分なテストコードを生成させることで問題を初期段階で見つけていると言っているが、自分はまだその方法までは試せていない。自分のコードはアルゴリズムよりロジック寄りなので、テストを書くのも難しい。

    • 16年間プロの開発者として働いてきたが、Claude Codeのおかげで、壁にぶつかって頭を抱えていたこともかなり簡単に解決できるようになったと感じる。新しいことを素早く身につける時には、AIツール（特に質問応答のaskモード）が効果的で、比喩、ケース、暗記法を積極的に使っている。もし目標がゆっくりした成長を通じた深い学習なら、遅くても従来のやり方を自分でやる方が良い。しかし素早く学ぶのが目的なら、AIを活用するのも悪くない。結果を出したいだけなら、仕様をきちんと書き、テストも十分に用意することが重要だ。結局どちらのやり方でも、何かを作り続けることに意味があると思う。

    • 昔、「自分だけのxライブラリを作ってみよう」というブログの流行があった。自分で何かを実装する過程で最も多くを学べる。たとえばクライアントサイドルーターが気になるなら、自分でルーターを作ってみるようなものだ。LLM時代には何でもライブラリコードで置き換えられるが、本当にC#を学びたいなら自分でポーティングするのがよい。単に成果物だけが必要で、別のことに集中したいならClaudeに任せてもよい。学びには必ず苦しい区間が伴い、あまりに楽だと実は何も学べていない。

    • AI以前はコピペが主流だった。Stack Overflowから理由も分からずコードを持ってきていた友人たちは、結局何も学べなかった。助言や概念説明をAIに求めるのは問題ないと思う。ただ、すべてを代わりに書かせれば、学びがないのは確かだ。一方で、開発者として自分の時間を守るのも賢い。学ぶべきことは無数にあるので、もし目標がゲーム開発なら、GDscriptのポーティング作業は必須の経験ではないかもしれない。もちろん学べる点は確かにある。

  • 約3週間Claude Codeでコーディングした経験から言うと、自分は10年選手で、PythonのML/データエンジニアリングを中心に働いている。理由はいくつかある:

    1. 始める苦痛がなくなり、最初の1行を書くハードルがない
    2. 実行中、自分の頭を完全に思考に使える
    3. 同時に複数の作業を並列で進められる
    4. 「あれもやるべきだった」が浮かんだら、すぐ新しいClaudeセッションで試せる（もうTODOを残さない）
    5. 分析・可視化、プロットなども簡単にscriptを自動実行して試せる
    6. 単純なlint/型/テストの問題は自動で直してくれる 全体として、コードの本質――何をすべきか、出力は正しいか、どう改善できるか――にだけ集中できる。

    • 始める苦痛をなくしてくれるのは本当に大きい。以前なら「時間さえあればやりたい」と思っていたことも、今はプロンプトを数個書くだけで実行できる。実際、NYT Connectionsゲームをターミナルで作りたかったが、3つのプロンプトで完成した(https://github.com/jleclanche/connections-tui)

    • 4番が特に印象的だ。以前はテストや技術的負債を残すのが当たり前だったが、今はテストスイートも「必要だ」と一言言えばかなりまともなものが自動生成される。完璧でなくても、中程度の難易度の仕事は確実に片付けられるようになったわけだ。

  • エージェントベースのコーディングに挑戦し続ける好奇心の強い少数派として、なぜ自分の経験が主流と違うのか、その原因を考えてきた。次の説明が核心だと思う:

    "Claude Codeによって、私たちは『写真が登場した時代のプログラミング』にいる。手で絵を描くムードが消えるのは、アイデアひとつをすぐ現実化でき、自分のコードレビューと編集能力で望む形に削り出せるからだ" この比喩は適切ではあるが、それでも人は絵を描き続けるし、お金を払って絵を買う人もいるし、コーディングそのものを芸術として楽しむ人もいる。自分にとって直接コーディングすることは趣味であり、コードレビューは嫌いだが仕方なくやっている。選べるなら自分で作る方を選ぶだろう（だからICであり続けている）。人はAIコーディングエージェントを「すごいジュニア開発インターン」のように言うが、自分にはむしろ恐ろしく感じられる。

    • いまだに人が絵を描き、絵にお金を払う環境が続いているのかを問いたい。大半の手工業は組み立て式・大量生産に押しやられたが、今では商品そのものよりも、生産者と消費者が想像力を通じて共有する体験のほうが重要な価値になっている気がする。ただAmazonで物を注文するのではなく、職人との関係や創作過程そのものが物語として消費される。コーディングも将来生き残るには、こうした方向が必要になるのかもしれない。

    • 自分もこの立場はとてもよく理解できる。小さな作業、バグ修正、草案づくりにはエージェントコーディングの有用性を認める。ただ、少数のモデルだけを包むさまざまなインターフェースをめぐって賛否の論争が激しくなるのはよく分からない。それと、ジュニア開発者への影響についてはまだ考え中だ。もしAIがコードレビューまで自動化してくれるなら、自分の人生はもっと幸せになりそうだ。

    • その比喩が完全に有効だとは思わない。歴史的に絵画は現実世界を再現する唯一の手段だったが、芸術は単なる模写ではなく、創作者の解釈だ。だから今でも人は絵を描く。コーディング自体を芸術だと考えるなら、これからも続けられる。ただ、多くの人にとって目標は製品開発であり、製品そのものが芸術でもある。AIによってその目標により速く到達できるなら、当然AIを選ぶ方がよいのではないか。一方で、「コードモンキー」時代（純粋にコーディングだけしていた頃）が懐かしくもある。これからは誰もがリード開発者のように、ディレクション、コードレビュー、技術判断だけをする状況になるのかもしれない。現場で自分の手でコードを書く機会が減る変化は、少し寂しい。

    • より適切な比喩は、hand-toolからpower toolへの移行に近い。絵画-写真の比喩は、新しいメディアの登場とは違うのに広げすぎている気がする。エージェントコーディングはそこまで革命的ではない。

  • Claude Codeをたくさん使ってみようとしたが、遅すぎるし、いつもどこか噛み合わなくて苛立つ。大半の作業でメンタルエネルギーを節約できる感じがしない。いくつかの作業では助けになったが、何度も裏切られたような経験もあって、あまり使いたくない。たとえばnushellで.zshrcを変換してほしいと頼んだが、30分格闘しても動かず、自分で公式ドキュメントを読むなら10分もかからなかった。こういう失望する経験のせいで、Claudeをまた使いたい気持ちになれない。

    • この経験は自分にも似ている。テストコード作成などで助けを借りようとしたが、結局毎回自分で全部書き直すことになった。デバッグで成果が出たことは一度もない。ごく単純なスクリプト変換（コマンド出力のパースなど）や新規プロジェクトのスキャフォールディング程度なら使える（とはいえ、そんな作業をどれほど頻繁にするだろうか）。簡単なコードポーティングには悪くなかったが、失敗体験の方がずっと多かった。

    • context7 MCPのようなものを使ったことがあるか聞きたい。あまり人気のない言語や馴染みの薄いドメインでは、LLMは弱い傾向がある。context7のように最新ソースから参照を直接引いてくる方式の方が良いように感じる。

  • RSIと手根管症候群のせいでコーディング量が減っていたが、Claudeのおかげで（痛みが10分の1に減って）再びプログラミングできるようになった。むしろ拒否したかった技術だが、キャリアを続けるには今や不可欠だ。

    • 似たような人の話をたくさん聞く。RSIを抱える人にとって、Claudeのようなツールは本当のゲームチェンジャーだ。最もつらく退屈なボイラープレートなどの反復作業を、ずっと楽にしてくれるからだ。以前は繰り返しコードを見るだけで手首もメンタルも痛んだが、今では気にする必要もなく、むしろ抽象的で新しい問題に集中できるので、プログラミングそのものがもっと楽しくなった。「こういうツールのせいでキャリアが終わるかもしれない」という不安もあるが、むしろ逆に自分のキャリアを救ってくれると信じている。

    • Claudeを使い始めてからRSIの痛みはほとんど消えた。特に、非常に正確な命令や文章で反復作業を置き換えられる。音声認識の活用例も多く聞くし、それによってアクセシビリティの扉が開いているように思う。

    • 音声でClaude Codeをそのまま活用できれば、さらに助けになるのではないかと思う。MacOSには無料のTTS/ASRオプションがあり、BYOKで他の音声エンジンも接続できる(https://github.com/robdmac/talkito)

    • 十分に正確で使いやすいSTT/音声認識アプリを使えば、Claude Codeに詳細なコンテキストを伝えるのも効果的だ。さまざまな音声認識アプリを試した結果、キーボードショートカットベースのハンズフリーモードと、精度・速度の両方を備えたWispr Flowが最もしっくりきた。ただ、ローカルアプリも対応してほしいとは思っている。

    • もしかしてテキスト入力そのものを音声で行っているのか気になる。

  • 保守の観点から、著者の考えにとても同意する。以前ならリファクタリングや後で思い出すためのTODOやチケットだけ作っていた作業も、Claudeのおかげですぐ実装してしまえる。その結果、反復的な手間が大きく減った。リファクタリングのアイデアも素早く試し、気に入らなければ捨てるのが簡単になった。こうした種類の作業に対する起動エネルギーが著しく下がった。AIエージェントを並列・オフラインで無差別に回すと、むしろバーンアウトやコード品質低下につながりかねないので、必ず人間の監督モードを維持すべきだという点にも同意する。追加で整理した文章は https://www.modulecollective.com/posts/agent-assisted-coding... にある。
 
zxavi 2025-08-07

私の気持ちも、まさに元の投稿者の気持ちと同じです（笑）
200ドル支払って、わずか1時間で4年来の難題を解決しました。
おそらく私一人では……Cursorを使っても絶対に解決できなかったと思います
 
beoks 2025-08-07

Claude Code と Cursor + Claude LLM を使ったときの違いは分かりますか？
私は Cursor を使っているのですが、Claude Code に乗り換えるか悩んでいます。
 
zxavi 2025-08-07

Claude LLM というと、APIキーのことをおっしゃっているのでしょうか？
それとも、チャット欄の下にある Agent モデルのことですよね？

Cursor にも十分満足して使っていましたが、使用量制限にしょっちゅう引っかかって、$60 のプランを使っていてもリミットにかからないか常に気が気ではありませんでした。
そのせいで gemini cli を交互に使いながらで、かなりストレスが多かったです。

Cursor + Claude 4 sonnet でも十分良いのですが、1日経つとリミットに引っかかり、しかも一度リミットに達すると1か月使えないのが一番の問題でした。

Cursor + Claude 4 opus は試してみようという気にもなれませんでした。

Claude Code は結局 cli ベースで、IDE の特性にも左右されないので使ってみることにしたんです。

最初は $20 ドルのプランを使っていましたが、でもこれにも opus がありません。

それで、どうせリミットにかかりそうだったので、1か月だけ使ってみようという気持ちで $200 を払って使ってみたら、

新世界が開けました。opus …格が違うんだなと…。

今 $200 を使い始めて4日目ですが、寝かせていた難題を全部解決しているところです（笑）
 
zxavi 2025-08-07

投稿が編集できませんね

Cursor + Claude 4 Sonnet も十分に良いのですが、1日経つとリミットに達してしまい、リミットに達すると1か月の間使えないのがいちばんの問題でした。

1か月ではなく1日だった気がします。1か月の間ずっと気が気ではありませんでした。
そして Cursor とはかなりよく衝突しましたが、
Claude Code とはあまり衝突しません。
 
beoks 2025-08-07

おお、詳細なご回答ありがとうございます。
私も制限に引っかかってやむを得ずAutoモードでCursorを使っていますが、乗り換えるべきですね。