59 ポイント 投稿者 GN⁺ 2025-08-25 | 12件のコメント | WhatsAppで共有
  • AIツール Claude Code は単なるコード生成器ではなく、同僚に業務を委任するような体験を提供する 生産性ツール
  • 反復的な実装の代わりに、システム設計、プロダクト思考、コミュニケーション といった人間固有の能力に集中できる 環境 を提供
  • 並列作業、多段階デバッグ、GitHub連携を通じて、少人数でも 大規模開発チーム級の成果物 を生み出せる 効果 がある
  • ただし、過剰なテスト作成や単純作業の過剰処理など、制約と性格的な癖 があり、ユーザーが管理する必要がある
  • 結果として、これは開発者の役割を実装者から指揮者へと移し、ジュニア開発者の教育、シニアの生産性向上、非開発者によるプロジェクト実行まで幅広い可能性を開く

AIが書くコードと開発者の役割の変化

  • ここ2か月で書かれたコードはすべて、人間ではなく Claude Code が直接書いたもの
    • ユーザーは実装ではなく、アーキテクチャ設計と成果の定義に集中
    • 反復的で細かなタイピングは次第に不要になっていく流れ
  • この過程で、開発者の価値は プロダクト企画、システム思考、美的判断 へと移っている

多段階デバッグ能力

  • キュー処理失敗の問題で、Claude Codeが数千行に及ぶ外部ライブラリのコード を解析して原因を突き止めた
    • 開発環境と本番環境でのキュー名の不一致問題を解決
  • これは、通常の開発者なら数時間から数日かかる問題を短時間で解決できた事例

オーケストラの指揮者のように働く

  • 複数のClaude Codeインスタンスを並列実行して、複数機能を同時に開発 できる
    • 各作業は別々の git worktree で進められ、衝突を防止
  • 開発者は自分でコードを書く代わりに、作業を指揮しレビューする管理者の役割 を担う
  • これにより、体力や集中力が落ちているときでも効率的に進められる

日常的な活用と摩擦の最小化

  • Cursor, Copilot のようなIDEベースのツールと異なり、Claude Codeは特定の環境に縛られない
  • CLI、git、tmux など既存の開発者ワークフローとスムーズに連携
  • 主なコマンド:
    • /issues → GitHub Issueを作成
    • /work → Issueベースで開発し、PRを作成
    • /review → PRをレビューして改善
  • これにより、調査、実装、レビューの各工程の摩擦 を最小化する

限界と個性

  • ときにはテストを必要以上に多く書いたり、単純な作業を複雑に処理したりする 過剰行動 を見せる
  • 間違った方向に進み始めた場合は、すぐに中断できる
  • 長所は、反復的なスタイル修正など 開発者が面倒がる作業も進んでこなす 点にある

ジュニア開発者と学習

  • ジュニア開発者はClaude Codeを 絶えず質問できるメンター として活用できる
    • "自分のPRの問題点は何か?"
    • "PythonとRubyではアプローチがどう違うのか?"
    • "言語ごとの落とし穴や注意点は何か?"
  • これにより、成長速度と実務への貢献度が大きく向上する

実際のワークフロー例

  • 午前9時: バグ報告をClaude Codeに渡す → 再現してGitHub Issueを自動作成
  • 9時20分: 4つのタブで別々の作業を並列実行(バグ修正、PRレビュー、changelog作成、背景調査)
  • 10時〜11時: 各PRを自動生成し、ドキュメントとエラー処理も含める
  • 11時30分: 人間が最終レビューを行い、UXとコードスタイルを調整
  • 11時45分: 顧客フィードバックを分析し、Issueへ自動変換

結論と推奨対象

  • 2人チームが毎月400ドルを投資して、大規模チーム級の成果物 を達成
  • 推奨対象:
    • 実装よりも 戦略と品質に集中したいシニア開発者
    • より多くの成果を出したいチームリード
    • 非開発者の創業者や初心者開発者
  • 入門は 月額20ドルのサブスクリプション で可能で、実際のプロジェクトを任せてみることが学習曲線短縮の鍵
  • コーディングの未来は 自ら実装することではなく、成果を指揮し委任すること へと移っている

12件のコメント

 
kaydash 2025-08-27

人は争うが、プログラムは争わず合理的だ..

 
bluekai17 2025-08-27

ワークツリーをうまく使うだけでも、十分いいと思いました。

 
bhjun 2025-08-25

あのようにやるなら、Proでは絶対に無理ですね。
非開発者としてiOSアプリを作っていますが、Proは上限到達のタイミングがあまりにも早いです。
毎回2時間も経たずに終わってしまいます。

一方で、上限到達がそのまま作業終了のタイミングでもあるので、それはそれで良い気もします……
(今日はここまで、、、みたいな感じで笑)

 
bluekai17 2025-08-27

Max$100 のものを使えば、それでもかなり余裕がありました。非開発者ではありませんが、アプリ開発は初めてで、1か月使ってみたんです。今まででだいたい $566.93 使っていました。

 
fanotify 2025-08-26

午前中に2〜3時間やったら、昼前にもうリミットに引っかかりました(Proユーザー)
3時からリセットされると出ていますが、Maxでなければ一日中は使えなさそうです(Maxでも上限到達がそこまで難しくない気はします)

 
neodasida 2025-08-25

自動で2時間のポモドーロみたいな感じですね(笑)

 
click 2025-08-25

20ドルのProプランで、みんなが勧めているやり方であるplan modeで詳細なプランを立てるように分析させてからeditモードに移る、という回し方だけでもすぐにlimitに達してしまいました。
確かにコード品質は良くなるのですが、最初から愚直にeditモードで始めるときよりもトークン消費が3倍は速い感覚です。

 
hanay 2025-08-25

無料プランでは使えないですよね?

 
bluekai17 2025-08-27

100ドルのものを使えば、ある程度はカバーできそうです。

 
helio 2025-08-25

20ドルのプランでもああいうふうにやるのは厳しいです。"ここ2カ月の間に書かれたすべてのコードは、人間ではなくClaude Codeが直接書いた" みたいに書くなら、
まず200ドルを注ぎ込んで、リミットに達したらまた200ドル使わないといけないんじゃないでしょうか

 
muroa96 2025-08-26

私も100ドルのプランを使っています。コードを書く前にPlanはOpusモデルで進め、実際のコーディングはSonnetを使っています。ここ2か月ほど、ほぼすべてのコード(少なくとも数千行)はClaude Codeが直接書きましたが、制限にかかったことはほとんどありません。誤ってOpusでコードを書いた場合でなければ、まったくありませんでした。
現在は最近出たOpus Plan Modeを使っていますが、これを使い始めてからはApproaching limitの警告文もほとんど出なくなりました。

 
progdesigner 2025-08-25

すでに同じように作業しています〜
コミュニティで投票してみると
8〜9割がこのように変わってきているように見えます