2026年に向けた私のLLMコーディング・ワークフロー

 (addyosmani.com)
91 ポイント 投稿者 GN⁺ 2026-01-12 | 1件のコメント | WhatsAppで共有
  • AIコーディングアシスタントは2025年を通じて実践的な開発の中核ツールとして定着し、効果的に活用するには構造化されたワークフローと人間による責任ある介入が不可欠
  • すぐにコード生成を依頼するのではなく、まず明確な仕様と計画の策定を行い、それを基に段階的に実装を進める方式が品質と生産性を同時に高める
  • 作業を小さな単位に分解し、十分なコンテキストと制約を与えるほど、LLMのエラーや一貫性の問題を大幅に減らせる
  • 単一モデルに依存せず、複数のLLMやツールを目的に応じて選択し、開発の全ライフサイクルにわたってAIを補助的に活用する流れが広がっている
  • 最終的にテスト、レビュー、バージョン管理を通じて人間が主導権を維持するとき、AIは強力な生産性増幅器として機能する

概要

  • 2025年を通じてAIコーディングアシスタントが実際のプロダクトコード作成に大規模に活用され始めた
  • AnthropicのエンジニアたちはClaude Codeを積極的に導入し、現在ではClaude Codeのコードの約90%をClaude Code自身が作成する水準に達している
  • LLMをプログラミングに活用することはボタン一つで済む魔法ではなく、新しいパターンの学習と批判的思考が必須
  • AIを積極的に活用しつつも、生成されたソフトウェアに対する責任は開発者本人が負わなければならない
  • 核心は、LLMを自律的な判断者ではなく、明確な方向性、コンテキスト、監督を必要とする強力なペアプログラマーとして扱うこと

明確な計画から始める（仕様が先、コードは後）

  • LLMに漠然とした依頼を投げるのではなく、問題定義とソリューション計画から始めるべき
  • 新規プロジェクトの場合はアイデアを説明し、LLMに反復的に質問するよう依頼して要件やエッジケースを具体化する
  • 最終的に要件、アーキテクチャの決定、データモデル、テスト戦略を含むspec.mdにまとめる
  • その仕様を推論可能なモデルに入力し、実装を論理的で小さなタスク単位に分割したプロジェクト計画を作成する
  • Les Orchardの表現を借りれば、**「15分でウォーターフォール」**という形で素早く構造化された計画段階を経ることで、その後のコーディングが格段に円滑になる
  • 明確な仕様と計画があれば、人間とLLMの双方が何を、なぜ作るのかを正確に認識でき、手戻りや無駄なサイクルを防げる

作業を小さく反復的なチャンクに分割する

  • LLMに一度で巨大な出力を求めるのではなく、プロジェクトを反復可能なステップ・チケット単位に分割して順次処理する
    • 例: 「計画のStep 1を実装」といった単位でプロンプトを与え、コーディング後にテストを経てStep 2へ進む流れを定着させる
  • 一度に範囲を広げすぎると、モデルが混乱したりちぐはぐな成果物を出したりして、収拾コストが急増する
  • アプリの大きな塊を丸ごと生成させたところ、一貫性の崩壊と重複コードが積み上がり、「会話もなく10人が作ったようだ」という評価まで出た
  • 各反復で既に構築されたコンテキストを引き継ぎながら段階的に追加していくため、**TDD（テスト駆動開発）**のアプローチとも相性が良い
  • 一部のコーディングエージェントツールはこのチャンクワークフローを明示的にサポートしており、プロンプトプランファイルを生成して順次実行できる

幅広いコンテキストとガイダンスを提供する

  • LLMは与えられたコンテキストの範囲内でしか性能を発揮できないため、関連コード・文書・制約条件を十分に提供する必要がある
  • ClaudeはProjectsモードでGitHubレポジトリ全体をコンテキストとして読み込め、CursorやCopilotのようなIDEアシスタントは開いているファイルを自動的に含める
  • ブレインダンプ方式で、モデルが知るべき情報を事前に渡すのが効果的であり、高レベルの目標・望ましい解法の例・避けるべきアプローチまで含める
  • gitingestやrepo2txtのようなツールを活用して、コードベースの必要な部分をテキストファイルとしてダンプし、LLMに提供できる
  • Claude Skillsは、繰り返しのプロンプトに依存していた従来のやり方を超え、指示・スクリプト・ドメイン専門知識を永続的かつ再利用可能なモジュールとして束ねるアプローチ
    • コミュニティでキュレーションされたSkillsコレクションもある
    • frontend-designスキルは、LLMが生成したUIにありがちな紫寄りのデザイン美学を補正してくれることもある
  • プロンプト内にコメントやルールを直接含めてAIを導くと効果が大きい
    • 例: 「ここにXの現在の実装がある。これをYへ拡張するが、Zは壊さないこと」
  • LLMは指示に文字どおり従うリテラルな特性を持つため、詳細で文脈が明確な指示を与えるほど、幻覚や的外れな提案を減らせる

適切なモデルを選ぶ（必要に応じて複数モデルを活用）

  • すべてのコーディングLLMが同じ水準というわけではなく、タスクの性質に合ったモデルやサービスを意図的に選ぶことが重要
  • 場合によっては2つ以上のLLMを並列に使い、同じ問題に対する異なるアプローチを相互検証する方法が有効
  • 各モデルは固有の傾向と強みを持つため、あるモデルが行き詰まったり平凡な結果しか出さなかったりしたら別のモデルに切り替える判断が必要
  • 同じプロンプトを別のサービスにそのまま移して試す**「モデル取り替えっこ」**方式で、特定モデルの盲点を避けられる
  • 可能であれば最新のプロティアモデルを使うほうが、品質面で明確な利点がある
  • 長時間の協業を前提とするなら、AIペアプログラマーの**「バイブ」—応答のトーンややり取りの感覚が自分に合うか**も重要な選定基準

AIコーディングをライフサイクル全体で活用する

  • コマンドライン環境ではClaude Code、OpenAI Codex CLI、Google Gemini CLIのようなAIエージェントが登場し、プロジェクトディレクトリ内でファイルの読み取り・テスト実行・多段階の修正作業を行える
  • GoogleのJules、GitHubのCopilot Agentは、レポジトリをクラウドVMに複製して作業した後にPRを開く非同期コーディングエージェントとして活用される
  • これらのツールは完全ではなく、限界を理解したうえで使うことが必須
    • ボイラープレート生成、反復的な変更の適用、自動テスト実行のような機械的作業では大きな加速効果を示すが、それでも品質を左右するのは人間のガイダンス
  • エージェントを使う際は、初期段階で計画やToDoリストを併せて渡すと、正確な作業順序の認識に大きく役立つ
  • AIエージェントが機能全体を無人で実装して完璧な結果を出す段階にはまだ至っておらず、監督付きで使うのが現実的なアプローチ
  • Conductorのようなオーケストレーションツールを使って複数のエージェントを並列稼働させ、異なる機能を同時に処理する実験が進んでいる

ヒューマン・イン・ザ・ループを維持する - 検証、テスト、レビューを徹底

  • AIはそれらしく見えるコードをためらいなく生成するが、品質と結果に対する責任は完全に開発者にある
  • Simon Willisonの表現を借りれば、LLMペアプログラマーは 自信過剰でミスしやすい存在 として認識すべきであり、バグや筋の通らないコードも自信満々に書く
  • AIが生成したコードスニペットは ジュニア開発者のコードのように 扱うべきで、コードを自分で読み、実行し、必要に応じてテストを行う
  • テストをワークフローの中に自然に組み込み、計画段階から各ステップごとの テスト一覧とテストプラン を一緒に設計する
  • Claude Codeのようなツールには、タスク実装後に テストスイートの実行を明示的に指示 し、失敗した場合は原因分析と修正まで進める
  • コーディングエージェントを最もうまく活用できるのは、多くの場合 しっかりしたテスト文化 を持つチームや個人である
  • テストがない環境では、エージェントが実際には複数の箇所を壊していても 問題ないと仮定 して見過ごしてしまう危険がある
  • 自動テストに加えて コードレビューを必須ステップとして維持 し、手動レビューとAIベースのレビューを並行して行う
    • 別のAIセッションや他のモデルを使って、最初のAIが書いたコードを批評・レビューするよう依頼する
    • 例: Claudeがコードを書いた後、Geminiにその関数の不具合や改善の余地を確認させる
  • Chrome DevTools MCPを デバッグと品質ループの中核ツール として活用し、静的解析と実際のブラウザ実行の間のギャップを埋める
    • AIエージェントにDOM構造、パフォーマンストレース、コンソールログ、ネットワークリクエストを直接観察できるアクセス権を与える
    • 手動でコンテキストを移し替えることなく、LLMベースの自動UIテストを実行できる
    • 実際のランタイムデータに基づいて、バグを 精密に診断して修正 する流れが可能になる
  • 急ぎのプロジェクトでAI生成に過度に依存した結果について、ある開発者は 一貫性のないぐちゃぐちゃな状態 だったと語っている
    • 重複ロジック、ばらばらなメソッド名、統合されていないアーキテクチャが蓄積した
    • ひたすら作り続けるばかりで、AIが組み上げた全体構造を点検するために一歩引いて見直さなかったと反省している
    • 最終的には大規模なリファクタリングを行い、二度と監督なしで任せないという結論に至った
  • AIの使用量に関係なく、開発者は最後まで責任あるエンジニアであり続けなければならない
  • 実務的には、コードを理解したうえでのみマージやデプロイを行い、AIが複雑な実装を出してきた場合は説明コメントの追加や、より単純な形への書き直しを求める

こまめにコミットし、バージョン管理をセーフティネットとして使う

  • AIと作業して高速に大量のコードを生み出すほど、より細かいバージョン管理の習慣 が必要になる
  • 小さなタスクを終えたり、自動修正が成功したりするたびに、意味が明確なメッセージでgitコミット を残し、次の変更が問題を起こしてもすぐ戻せるチェックポイントを確保する
  • コミットを ゲームのセーブポイント のように扱い、LLMセッションが逸脱したらいつでも最後の安定状態に戻れるようにする
  • バージョン管理はAIとの協業でも重要な役割を果たし、コンテキストウィンドウの制限によってすべての変更を覚えていられない状況で、git履歴が信頼できる作業ログ になる
  • 最近のコミットをざっと見返しながら、変更点をAIや自分自身にすばやくブリーフィングできる
  • git diff やコミットログをプロンプトに含めれば、LLMは新しいコードと以前の状態を正確に把握できる
  • LLMはdiffの解釈や git bisect のようなツール活用に長けており、コミット履歴をたどりながらバグが入り込んだ地点を粘り強く追跡できる
  • 細かく分けられたコミットと明確なメッセージは、開発プロセスを 自然に記録 し、コードレビューの際に大いに役立つ
  • AIエージェントが複数の変更を一度に行った場合でも、変更がコミット単位で分離されていれば 問題を引き起こした箇所を正確に特定 しやすい
  • ブランチやworktree を使って、AIの実験を本番コードから隔離する
    • Jesse Vincentに着想を得た方法として、新機能やサブプロジェクトごとにfreshなgit worktreeを作成する
    • 同じリポジトリで複数のAIコーディングセッションを互いに干渉させず並列実行し、その後に結果を選択的にマージする
    • 各AIタスクが独自のサンドボックスブランチにあるのと同じようなもので、失敗した実験を破棄してもmainには影響しない
  • 理解できず、説明もできないコードは 絶対にコミットしない原則 を守る

ルールと例でAIの振る舞いをカスタマイズする

  • AIのデフォルトのスタイルやアプローチをそのまま受け入れるのではなく、明確なガイドラインを与えるだけでも出力の品質と一貫性に大きな影響 がある
  • CLAUDE.md ファイルを定期的に管理してClaudeが従うべきプロセスルールや好みを明記し、Gemini CLIを使う場合も同様に GEMINI.md を活用する
    • 例: プロジェクトのスタイルに合わせてコードを書く、lintルールを守る、特定の関数の使用を禁止する、OOPより関数型スタイルを好む、など
    • セッション開始時にそのファイルをClaudeへ渡し、作業全体を規約に沿わせる方法
    • Jesse Vincentによれば、このアプローチによってAIが 望まない方向に逸脱したり、見慣れないパターンを持ち込んだりする頻度が減る という
  • 別個のルールファイルがなくても、カスタムインストラクションやシステムプロンプト を通じて全体的なトーンや振る舞いを設定できる
    • GitHub CopilotとCursorはいずれも、プロジェクト単位でAIの振る舞いをグローバルに設定する機能を提供している
    • コーディングスタイルを短い段落で明記する: “4スペースインデントを使う、Reactではアロー関数を避ける、説明的な変数名を使う、コードはESLintを通過しなければならない”
    • Ben Congdonは、Copilotのカスタムインストラクション機能 がほとんど使われていない現状に驚いたと述べ、いくつかの例や好みを事前に与えるだけでも、チームの慣用表現に合ったコードを出力できると指摘している
  • インラインで例を示すこと は特に強力な手法である
    • 特定のやり方で関数を実装してほしい場合、コードベース内にすでに存在する類似の関数を先に見せて「Xはこのように実装したので、Yでも同じアプローチを使うこと」と案内する
    • コメントスタイルを揃えたいなら、自分で1行書いてから、そのスタイルを引き継ぐよう依頼する
    • つまり、モデルが従うべきパターンで プライミング する方法であり、LLMはこうした模倣を非常に得意としている
  • コミュニティでは、LLMの振る舞いを洗練させるためのさまざまな ルールセット が共有されている
    • "Big Daddy"ルール や、プロンプトに「幻覚・欺瞞の禁止」条項を追加する方法など
    • AIが存在しないコードをでっち上げたり、過度に自信を見せたりする振る舞いを減らすための仕組みである
    • 例: 「不確実であったり、コードベースのコンテキストがなかったりする場合は、作り話で答えず明確化を求めること」をプロンプト冒頭に追加して幻覚を減らす
    • 別のルールとして「バグ修正時は必ずコメントで理由を簡潔に説明する」を入れておけば、AIは // Fixed: 仕様に従いZを防ぐためXをYに変更 のような説明コメントもあわせて残す

テストと自動化をレバレッジとして取り込む

  • CI/CD、リンター、コードレビューボットを積極的に活用するほど、AIはミスを自動でふるい落とす環境で最もよく機能する
  • AIコーディングの比重が大きいリポジトリほど、堅牢な継続的インテグレーション環境が不可欠
    • すべてのコミットやPRごとに自動テストを実行し、ESLint・Prettierのようなコードスタイル検査を強制し、可能であればブランチごとのステージングデプロイまで含める
    • AI自身がこれをトリガーし、結果を評価するよう構成することも可能
    • 例: JulesやGitHub Copilot AgentがPRを開くとCIがテストを実行して失敗を報告 → 失敗ログをAIに渡し、「統合テストがXYZで失敗したので、一緒にデバッグしよう」へつなげる
    • バグ修正のプロセスは高速なフィードバックを伴う協業ループへと変わり、AIは特にこれにうまく対応する
  • 自動化されたコード品質チェックもAIの羅針盤として機能する
    • リンターの出力をそのままプロンプトに含め、lintに引っかかるコードを書いた場合はエラーメッセージをコピーして「これらの問題を解決して」と依頼する
    • 厳しい先生がAIの肩越しに見張っているような効果
    • AIはテスト失敗やリンター警告のようなツール出力を認識すると、粘り強く修正を試みる
  • AIコーディングエージェント自体にも、徐々に自動化フックが組み込まれている
    • 一部のエージェントは、すべてのテストが通るまで作業を「完了」と認めない
  • コードレビューボット（AIでも人でも）も追加のフィルターとして活用できる
    • レビューコメントをそのまま改善用プロンプトとして使う
    • 例: CodeRabbitやほかのレビュー担当者が「この関数はXをしているが理想的ではない」と残したら、AIに「このフィードバックを反映してリファクタリングできるか」と依頼する
  • AIと自動化を組み合わせると、好循環の構造が生まれる
    • AIがコードを書く → 自動化ツールが問題を検知 → AIが修正 → 反復、開発者は高レベルの方向性だけを監督する
    • 極めて高速なジュニア開発者の作業を、疲れを知らないQAエンジニアが即座に検証するような感覚
    • ただし、この環境は開発者自身が構築しなければならず、テストや自動化のないプロジェクトではAIの微妙なバグや品質低下がかなり後になって表面化するリスクがある
  • 2026年に向けた目標の一つは、AIによるコード貢献の周辺にある品質ゲートの強化
    • さらに多くのテスト、さらに多くの監視、必要であればAIがAIをレビューする構造まで含む
    • あるモデルが見落とした問題を別のモデルが見つけるケースが、実際に観察されている

継続的な学習と適応（AIがスキルを増幅する）

  • すべてのAIコーディングセッションを学習の機会として扱うと、知識が増えるほどAIの助けも大きくなる好循環が生まれる
  • LLMを開発に活用することで、普段なら試さなかった新しい言語、フレームワーク、手法に自然と触れるようになる
  • しっかりしたソフトウェアエンジニアリングの基礎があるとAIは生産性を何倍にも増幅するが、基礎が弱いと混乱も同時に増幅される
  • 熟練した開発者たちの共通した観察として、LLMは既存のベストプラクティスを強化する傾向がある
    • 明確な仕様作成、十分に整ったテスト、継続的なコードレビューは、AIが関与するほどさらに大きな効果を発揮する
  • AIがボイラープレートを処理している間、開発者は設計・インターフェース・アーキテクチャのような高レベルの抽象化に集中できるが、そのためにはそうした能力が前提として必要
  • Simon Willisonの指摘の通り、シニアエンジニアをシニアたらしめるほぼすべての要素—システム設計、複雑性の管理、自動化と手作業の判断—は、いまやAIと組み合わさることで最良の結果につながる
  • AI活用は実際にエンジニアリング能力の向上を促進する
    • 計画段階でより厳密になり、アーキテクチャについてより意識的に考えるようになる
    • 非常に速いがややナイーブなコーダーであるAIを管理する役割を担うことで、判断力が鍛えられる
  • AIが能力を低下させるのではないかという懸念については、適切に使えばむしろ逆の結果になる
    • AIのコードレビューを通じて新しいイディオムや解決方法を学べる
    • AIのミスをデバッグしながら、言語や問題領域への理解が深まる
    • コードや修正理由を説明させ、候補者を面接するように絶えず質問してインサイトを得る
    • ライブラリやアプローチが不明確なときは、AIをリサーチアシスタントとして使って選択肢とトレードオフを比較する
  • 大きな流れとして、AIツールは専門性を増幅する
    • 2026年に近づくほど、仕事を奪われる不安よりも、反復的で単調な作業から解放され、創造的で複雑な問題により多くの時間を使えるという期待が大きい
    • 逆に、しっかりした土台がない場合は、AIがステロイドを打たれたダニング＝クルーガー状態につながる危険もある
  • 助言としては、技術を継続的に磨きつつAIで学習と生産性を加速し、定期的にAIなしでコーディングして基礎力を鋭く保つという意図的なバランスが必要
  • 結局のところ、開発者とAIの組み合わせはどちらか一方だけの場合よりはるかに強力であり、その組み合わせの中で開発者側が自分の役割をきちんと果たす必要がある

結論

  • AIを開発ワークフロー全体に積極的に導入しているが、慎重で専門家主導のやり方を維持している
  • 目指しているアプローチはAIがすべてを自動化する開発ではなく、「AI拡張ソフトウェアエンジニアリング」
  • 最良の結果は、AIとの協業にも古典的なソフトウェアエンジニアリングの規律をそのまま適用したときに得られる
  • 設計してからコーディングすること、テストを書くこと、バージョン管理、コード標準の維持のように苦労して積み上げてきた実践は今なお有効であり、AIがコードの半分を書く状況ではむしろさらに重要
  • ツールは進化し続け、ワークフローもそれに合わせて進化していく見込み
    • 完全自律型の「AI開発インターン」が単純作業をより多く引き受け、人間は高レベルの問題に集中する
    • 新しいデバッグ方法やコード探索パラダイムが登場する可能性がある
  • どんな変化の中でも、常にループの中に居続ける姿勢を保つ
    • AIを導き、結果を検証し、その過程で学び、責任を持って生産性を拡張する
  • 最終的な結論は明快だ: AIコーディングアシスタントは強力な増幅器だが、舞台のディレクターは最後まで人間のエンジニアである

関連記事

1件のコメント

 
gracefullight 2026-01-12

抽象化が進むほど、エンジニアリングの重要性は増していくように思います。