AIを活用してプログラミング力を高める方法

• AIコーディングツールを使って、人間なら1〜2時間かかっていた変換作業を、15〜20分のレビュー程度まで短縮したい
• しかし、現状ではAIが生成するコードの品質が自分で書いたコードの90%にも達せず、実質的な助けになっていないように感じる
• そこで、AIをどう使えば生産性とコード品質を同時に引き上げられるのか、その方法が知りたい

AIでプログラミングの効率と品質を高めるための実践的なヒント集

1. 反復可能な作業にだけAIを集中的に投入する

• AIは 似た形の作業を何度も繰り返すとき に最も大きな効果を発揮する
• まず一度は人間が最高品質で実装し、それを基準となるサンプルとして使う
• その後、同じパターンの作業をAIに任せて大量処理する
• 思考や判断が必要な作業では、期待できる効率は急激に下がる

2. コーディング前に必ず計画を作る

• いきなりコードを生成せず、解決計画を先に作成する
• 計画段階で曖昧な点や疑問をすべて表に出させる
• 計画に納得できなければ実行段階に進まない
• 結果の品質はプロンプトよりも 計画書の明確さ に左右される

3. 作業単位を極端に小さく分割する

• ファイル1つ、コンポーネント1つ、関数数個といった単位で依頼する
• 「全体をリファクタリング」「idiomaticに改善」といった依頼は失敗確率が高い
• 構造設計は人間が行い、反復実装だけをAIに任せる

4. コンテキストは溜め込まず、こまめに初期化する

• 会話が長くなるほど、ルール順守と品質は急激に落ちる
• 1つのセッションでは1つの作業だけを処理する
• 方針が変わったら、新しいセッションでやり直す
• 長期作業は文書（plan.md など）で状態を保存し、再投入する

5. ルール文書は短く、機械的に作る

• CLAUDE.md / AGENTS.md は500〜1000トークン以内に保つ
• 宣言的な指示よりも、具体的で検証可能なルール を中心に書く
• よく間違えることだけを最小限記録する
• 残りはコードと自動チェックで強制する

6. テスト・リンター・ビルドをフィードバックループとして使う

• 「うまく作って」ではなく、通過条件を明確に示す
• テスト通過、ビルド成功、リンターエラー0件を目標に設定する
• フィードバックループがあってこそ、AIは自力で収束できる
• 既存の動作を検証するテストは、リファクタリングの難易度を大きく下げる

7. 実行中に修正せず、計画を直して再実行する

• 結果が気に入らなくても、コード修正の依頼を繰り返さない
• 計画書を修正したうえで、新しいセッションで再実行する
• 実行段階で方向転換すると、品質はすぐに崩れる

8. 例ベースでスタイルを学習させる

• 抽象的な「良いコード」という指示はほとんど効果がない
• Before / After の例を一緒に提供する
• 良い例と悪い例を明確に区別して示す
• 例を中心にルールを拡張する

9. 理解を放棄せず、責任の境界を明確にする

• AIが生成したコードは、必ず人間が理解しレビューする
• プロトタイプや低リスクのコード以外では、未レビューでの利用を禁止する
• セキュリティ・運用・長期保守のコードでは、理解が品質の前提になる

10. その作業がAIに適しているかを先に点検する

• 正解がなく、美的・構造的な判断が大きい作業はAIに不向き
• 視覚的な結果を自動検証しにくいUIリファクタリングは特に難しい
• 必要に応じて:
  • 1段階目: 動作維持を目的とした機械的変換
  • 2段階目: 人間が品質リファクタリングを実施

11. 期待値は「10%改善」から始める

• 最初から10xを期待しない
• 小さな改善を積み重ねる戦略のほうが、長期的にはより効果的
• 設計と品質基準を手放さないことが重要

[GN⁺]

Hacker Newsの意見

• Claude CodeチームのBorisです。いくつかコツを共有します

  1. Claudeがよく間違えたり理解できなかったりする部分はCLAUDE.mdに書いておくとよいです。Claudeはこのファイルを自動で読みます
  2. Planモード（Shift+Tabを2回） を積極的に活用し、先に計画を立ててから実行させると、難しい作業で2〜3倍よい結果を得られます
  3. 作業の検証方法を提供するとよいです。たとえばSvelteではPuppeteer MCPサーバーを使って、ブラウザで結果を確認させられます
  4. モデルはOpus 4.5をおすすめします。Sonnet 4.5より明らかに一段上にアップグレードされた感じです
     参考になれば幸いです
  • 私もPlanモードのおかげで大きな生産性向上を経験しました。ただ、最近のバージョンではPlanモードがセッション最初の計画だけをずっと参照し続けるバグが出て、ワークフローが壊れました。自分の使い方が変なのか気になります
  • 作業中にClaudeを修正したあとは、self-reflectionプロンプトを実行するとよいです。この過程で、手動で整理した内容をCLAUDE.mdに自動反映してくれます
  • 上の助言には共感します。特に(3)のフィードバックループが重要です。モデルが自分で修正し、結果を確認できるようにする必要があります。ログファイルを残させたり、疑似コードの計画を立てさせたりすると、複雑な問題も素早く解決できます
  • Opus 4.5は本当にゲームチェンジャーです。古いReactプロジェクトをリファクタリングするときに大いに役立ちました。プロンプトを精密に書き、CLAUDE.mdをうまく整備すると効果が大きいです
  • CLAUDE.mdは4〜5回くらいまではうまく機能しますが、その後は指示を忘れてしまいます。たとえば名前を「Mr. bcherny」と呼ぶように言っても、すぐ忘れます
  • Google Julesと比べると、Claude Codeのほうがずっとプロの開発者らしく感じられました。ただ、Claude Code Webにはプロジェクト機能がなく、.clinerulesファイルを使えという回答を受けたのですが、CLAUDE.mdとの違いを知りたいです
  • CLAUDE.mdの便利な機能の1つは**@import**です。ファイル名の前に@を付けると、強制的にコンテキストに含められます。ただし使いすぎると非効率です

• 音声入力を活用すると、モデルが意図をより正確に理解します。500語ほどのプロンプトを話して伝えています。タイピングより、話すほうが思考が自然につながります。
  「計画を立てて、質問があれば聞いて」と言うと、Claudeが実際に質問してきます。以前のコードスタイルを模倣するよう指示するのも効果的です

  • 私も音声でlaboratory.loveをほぼ全部作りました。ショートカットで「コードを書く前に問題と要件を分析して、曖昧な点を質問して」とよく入力しています
  • 話すのが速いからといって、何も考えずに話しているわけではありません。むしろ、考えずに話すことのほうが問題かもしれません
  • 誰かに聞かれているときにAIに話しかけるのは少し気まずいですが、長い文は私も音声で入力します
  • どの音声認識サービスを使っているのか気になります

• プロンプトにループ条件（loop condition） を含めるべきです。例: 「yarn testが通るまで繰り返す」。
  LLMは結局のところツールを反復実行するエージェントなので、そのように扱うべきです
  参考: Prompting the Agent Loop

• 私が作ったnori-profiles設定をおすすめします。
  4か月間の実験の結果、Claude Codeの性能が目に見えて向上しました。
  関連記事: Averaging 10 PRs a Day with Claude

  • Claude Codeのskillsと比べると、どんな違いがあるのか気になります

• 会社でGolangの大規模コードベースを扱っています。Cursor、Claude Code、Gemini CLIなどいろいろなツールを使いましたが、ほとんどはコード量に圧倒されます。
  しかしaiderははるかに制御しやすく、精度も高かったです。ファイル追加は手動ですが、ほぼ100%正確です。
  最新のClaude SonnetやGemini 2.5 Proと組み合わせると最も正確です

  • aiderは完全なエージェント型ではない点が利点です。手動でコンテキストを管理できるので、誤ったファイルを修正されることがありません。トークン節約や速度の面でも有利です

• Cursorで作業するときは、まず1つのルートをリファクタリングしながらルールファイルを生成させます。その後は別のルートで「refactor」と言うだけで済みます

  • 長いプロンプトを恐れないこと。これこそがcontext engineeringです。会話履歴そのものがコンテキストを豊かにしてくれます。
    残りのコンテキスト容量を常に意識し、必要なら早めにcontext clearするのがよいです

• エージェントをチームメンバーのように扱う視点が重要です。お互いの強みと弱みを観察しながら、協業の仕方を調整する必要があります。
  私は検証可能な問題や実験用コードにエージェントの力を集中させます。
  Svelteはあまり詳しくありませんが、TDDスタイルの使い捨てテストでリライトを誘導するのがよさそうです。
  ときには以前の誤った文脈を捨てて、新しいワークスペースでやり直すのが最善です

  • その「認知スタイルとチームワーク」に関するテキストの要約を共有してもらえるとうれしいです

• 私はLLMを探索者（searcher） だと見ています。質問を小さく具体的にすると探索しやすくなり、訓練データから離れるほどエラー確率は高くなります。

  1. プロジェクトをZedで開き
  2. Gemini CLI、Qwen code、Claudeのいずれかを接続
  3. ファイルの修正を依頼してテスト
  4. だめならGrokやGemini 3 Chatを試す
  5. それでもだめなら手動で解決
     新規プロジェクトならone-shotプロンプトだけでも十分可能です
  • ただし小さすぎるプロンプトは**情報不足（underspecification）**の問題を引き起こします。計算コストは下がっても、品質面では不利です

• 私が愛用しているClaude Codeのツールセットはsuperpowersです

  1. まずブレインストーミングセッションで機能を説明
  2. Claudeが設計文書と実装計画を書いてディスクに保存
  3. 新しいClaudeのウィンドウでExecute Planコマンドを使い、段階的に実行してコミット
  4. 3段階ごとに自己レビューをさせてコード品質を高める
     2週間使っていますが、ほとんど失敗したことがありません

• 私のAIプログラミング原則はシンプルです

  1. 一発完成（one-shot） は失敗する
  2. 作業を検証可能な単位に分割する
  3. 全体計画をMarkdownファイルに整理する
  4. 各段階ごとに新しいセッションで実行し、レビューしてからコミットする
     核心は**「Less is more」**です。コンテキストウィンドウは新しいほどよく、500〜750語程度が理想です。すべての段階は検証可能であるべきです

• Java関連の作業では、Claudeが継続的に方向を変えたり矛盾した提案をしてきます。ChatGPTのほうがずっとよいと感じます

  • プロンプトにより具体的な指示を与えれば改善するかもしれません
  • Claude Codeのバージョンを試したことがあるか気になります

• 「Idiomatic code」 を求めるなら、まず自分が考えるスタイルを細かく定義する必要があります。よい例・悪い例を小さく分け、それをOpus 4.5のPlanモードに入れて計画を立てたうえで実行します。一度で完璧にならなければ、計画文書を修正して再挑戦します。ジュニア開発者のように細かく指導しようとすると、かえって非効率です

  • 別の人は「最近のモデルは必ずしもセッションを新しく始めなくてもよい」として、インラインリファクタリングでも十分安定しているという経験を共有しています