掲載済み (2025-10-18号)
#124 633文字 • 4分

## LLMのコーディングエージェント(主にCodex)を効率よく使うために

日本語

掲載情報

概要

https://zenn.dev/takeshy/articles/ffe23204d1d326

詳細内容

## LLMのコーディングエージェント(主にCodex)を効率よく使うために https://zenn.dev/takeshy/articles/ffe23204d1d326 開発者が自ら全体戦略を策定し、タスクを細分化することで、AIコーディングエージェントの生産性を最大化する具体的な10の活用術を解説します。 **Content Type**: ⚙️ Tools **Language**: ja **Scores**: Signal:5/5 | Depth:5/5 | Unique:4/5 | Practical:5/5 | Anti-Hype:5/5 **Main Journal**: 96/100 | **Annex Potential**: 93/100 | **Overall**: 96/100 **Topics**: [[LLMコーディングエージェント, プロンプトエンジニアリング, 開発ワークフロー改善, CRM連携開発, 自動テスト]] この記事は、著者がHubspotからTwentyへのCRM移行プロジェクトでLLMコーディングエージェント(主にCodex、Gemini、Claude Code)を活用した3週間の経験から得た、生産性を最大化する10の知見を共有しています。当初AIを過信し期間を大幅に超過した経験を踏まえ、AIの得意不得意を見極め、人間が主導することの重要性を強調しています。 著者はエージェントの使い分けを推奨します。Codex(gpt-5-codex)は実装とデバッグに優れるものの、大規模修正やリファクタリングでは「BigJobだ」と手を抜く傾向があります。Gemini(Gemini 2.5 pro)はリファクタリングやドキュメント作成に素直だが、テスト解決力が弱いと分析。Claude Codeはフロントエンド向きと位置付けます。この特性から、新規実装はCodex、リファクタリングやメソッドコメント生成はGemini、テスト修正は再度Codexという連携プレーを提案しています。 生成AIはプロダクトの状況や設計意図を考慮しないため、開発者自身が先行して「おおまかな戦略」を策定する必要があるといいます。特にCRM連携のようなアーキテクチャ設計では、人間が最適なパターン(例:CrmServiceの導入)を決定し、その方針をプロンプトに明記することで、AIの誤ったアプローチを防ぎ、開発期間短縮につながると強調しています。 また、Codexが大きなタスクで不完全な結果を出すことから、「依頼するタスクを細かく分割する」ことが重要です。メソッド単位での依頼が有効とされています。複雑な変換ロジックなどは、AIに処理させるのではなく、「いったんデータとして掃き出してマスターデータ化する」ことで、コンテキストの肥大化を防ぎ、AIの処理負荷を軽減する工夫も紹介しています。 さらに、AIとの共同作業では「ドキュメントを頻繁に更新させる」ことで、AIが常に最新のコンテキストで作業できるようになります。トークン不足による精度低下対策には、「引き継ぎプロンプト」を作成させ、コンパクトな形で状況を新しいチャットに引き継ぐ方法が効果的です。 その他、Codexエージェント版用に「テスト環境(ローカルシミュレータなど)」を整える必要性や、不具合発生時に復旧しやすくするための「依頼実装ごとのcommit」、そして「E2Eに近いテスト」で全体影響を確認することの重要性を説きます。最も重要だが忘れがちな点として「仕様書をちゃんと書く」ことを挙げ、AIに正確な指示を出し、意味のあるドキュメントを生成させる基盤となると強調しています。 著者は、生成AIが個人の能力をブーストし、着手できなかった機能開発を可能にする一方で、それはあくまで人間の戦略と理解があってこそ機能すると結論付けています。「自分が理解できていないことはAIにもできない」という教訓は、AIコーディングの現場で働くwebアプリケーションエンジニアにとって、実践的な洞察と言えるでしょう。