今のコーディングエージェントに対するメモ

geminiと一緒に作ったやつをメモしとく来月には変わってそう（泣

これで自分の能力の最大化は一旦飽きてきたから、次はこっち方面やる https://zenn.dev/tesla/articles/3abc9e61da0b1e

コーディングエージェント時代のソフトウェア開発戦略

はじめに

AIによるコーディングエージェントは、ソフトウェア開発の現場に大きな変革をもたらしつつあります。本レポートでは、現状（2025年6月時点）を踏まえたコーディングエージェントの最適な活用法、開発プロセス、組織への影響について、筆者の見解を述べます。

筆者は日本のSaaSを提供する企業に勤務しており、新規の技術開発よりも、既存の技術やソリューションを効果的に組み合わせ、自社のビジネスに最適化することに主眼を置いた業務特性を持っています。また、小規模チームでの開発経験が多いです。あくまでその背景からの意見となります。

1. 現時点での最適な活用と開発スタイル

現状、特に開発タスクに集中して取り組むエンジニアにとって、ClaudeCodeのような対話型コーディングエージェントが最も実践的かつ効率的と考えます（2025年6月時点）。その理由として、特定のタスクに対するインタラクティブな試行錯誤が容易で、人間が主導権を持って開発を進めるサイクルに適している点が挙げられます。

具体的なスタイルとしては、二つのウィンドウを開き、一つは開発タスクをClaudeCodeに実行させ、一つは人間がClaudeCodeの出力をレビュー・修正していき、終わり次第、ウィンドウの役割を交換するという進め方が、自分にとって現時点で最も高い効率を実現できています。

また、コーディングエージェントを確実に介することで、最初の出力がコーディング規約などをより遵守するようになるため、オンボーディング期間の削減や、人間の記憶の節約に繋がります。

2. バックグラウンドAIエージェントの課題と可能性

Devinのような、より自律的にバックグラウンドで大規模なタスクを遂行しようとするエージェントに関しては、現時点では人間の認知負荷やレビュー・修正速度がボトルネックとなります。エージェントがどれだけ速くコードを生成・修正しても、人間がその内容を理解し、必要なレビューや修正を行う速度が律速段階となるため、完全なバックグラウンド自律実行のメリットを十分に享受できていない側面があります。そのため、UX面で、出力の途中確認や、修正レビューのフローの流れが容易なClaudeCodeなどの対話型に軍配が上がると考えます。

しかし、これらのバックグラウンドAIエージェントは、日々の機能開発といったメインフロー以外の場面で有効性を発揮すると考えられます。例えば、本番障害発生時の原因調査、プロジェクトマネージャーからのコードに関する質問への対応など、エンジニアの主務ではない、突発的・非定型的なタスクにおいて、裏で情報収集や分析を行うサポート役として活用することで、人間の負担を軽減できる可能性があります。

3. コードレビュープロセスの変革

コーディングエージェントが生み出すコードは、レビュープロセスを変化させます。まず、AIが生成したコードに対する人間の初期レビューはClaudeCodeを使った開発であれば確実に行われているはずで、これに加えてCoderabbitのような自動レビューAIツールを併用することで、コード規約や一般的なバグパターンのチェックは自動化できます。これにより、開発した人以外の細かいコード記述に関するレビューは不要となり、レビュー効率が大幅に向上します。

一方で、システム全体の整合性、ビジネスロジックの妥当性、想定されるエッジケースへの対応など、仕様の深い理解に基づくクリティカルな部分の抜け漏れ確認は、引き続き人間の重要な役割となります。

4. 開発プロセスの転換：コード先行とドキュメント生成

コーディングエージェントの能力を活かすには、開発プロセスを「ドキュメント作成 → コード実装」から、「コード実装 → コードからのドキュメント生成 → レビューを受けて作り直し」へと変えることが有効です。コードはドキュメントより記述の自由度が低く、具体的であり、学習対象も多いため、コードというプログラミング言語を出力してもらうことで、仕様の曖昧さや潜在的な問題に早期に気づきやすくなります。

そして、一度実装されたコードから、コーディングエージェントがAPIドキュメント、設計概要、実装詳細などのドキュメントを自動生成します。これにより、ドキュメント作成の工数が削減され、コードとドキュメントの一貫性も保ちやすくなり、開発サイクル全体が高速化します。

5. テスト戦略とアーキテクチャへの影響

この新しい開発プロセスでは、E2E（End-to-End）自動テストも、開発対象のコードと同じリポジトリに配置し、同時並行で作成することが自然な流れとなります。これにより、継続的なテスト実行と品質確保が可能になります。

開発単位が小さく、テストしやすい設計が求められることから、システムアーキテクチャは必然的にマイクロサービス寄りの思想になると考えられます。マイクロサービスにおいては、各サービスの「境界面（インターフェース）」の明確な定義が極めて重要であり、これは人間のアーキテクトによる高度な意思決定が不可欠な部分です。ただし、Devinのようなマルチリポジトリ対応エージェントは、サービス間の依存関係分析などを支援し、アーキテクトの素早い意思決定に貢献できる可能性があります。

6. 組織構造と成果物の定義の変化

コーディングエージェントの普及は、エンジニア、プロジェクトマネージャー（PjM）、QAエンジニアといった従来の職能の境界を曖昧にするでしょう。将来的には、一つのGitリポジトリを中心に、仕様定義、コード実装、テストコード作成、デプロイ設定まで、開発に関わる全員がプログラムという共通言語で直接的に貢献していく形になる可能性があります。

この新しい体制において、最も重要な開発成果物は、品質を保証する自動テストコードと、実検証環境、実際に動作するコードそのものとなります。それ以外のドキュメントは、コードやテストからコーディングエージェントが必要な時に都度生成するものとして位置づけが変わります。

7. 必要なドキュメンテーションとその管理

全てのドキュメントが不要になるわけではありません。特に、開発内容をモジュール単位に分け、それぞれの役割、設計の意図、そして特定の意思決定が行われた理由など、人間の判断や背景を示す重要な情報は引き続き必要です。これらは、対象コードと紐づけてリポジトリ内でバージョン管理し、エージェントによる参照や更新が容易な形式で保持することが望ましいでしょう。

8. AIコーディング時代の新たな課題：人間の疲労と開発スタイルの再考

コーディングエージェントの高速なコード生成は効率を向上させる一方で、人間が時間あたりにレビュー・確認する必要のあるコード量が飛躍的に増加させ、新たな疲労や認知負荷を生む可能性があります。そのため、一部の人間しか適応できない可能性があると思います。おそらく、コード全体を追うのではなく、ビジネスロジックの核心や既存システムとの連携部分など、重要な箇所に絞って読む「国語の試験」のような効率的なコードリーディングスキルを持つ必要が必須かもしれません。

ただ、一時的な負荷増は、チャットツール導入時のような過去の経験と同様に、人間の順応によって慣れていく側面もあると考えられます。しかし、単に慣れに頼るだけでなく、チームでの開発スタイルを導入することも考えてみたいです。

例えば、「毎日リファインメント」を軸に、午前中は前日のAI生成コードのレビューに集中し、午後にはチームで次のタスクを相談し、AIに依頼準備を行うといった、人間の「レビュー/修正」とAIの「生成」のサイクルを意図的に分けたスタイルを提案します。このように個人単位でなく、チーム単位で負荷を制限するという形が必要になるかもしれません。

結論

コーディングエージェントは、ソフトウェア開発のプロセス、アーキテクチャ、そして組織構造を大きく変容させています。人間の役割は、コードの細かい記述から、AIが生み出すコードをレビュー・修正・統合し、仕様やアーキテクチャに関するクリティカルな意思決定を行うことへとシフトします。テストとコードを最重要成果物とし、ドキュメントはコードから生成するスタイルに移行し、一つのリポジトリを中心に職能横断的に連携する。このような新しい開発スタイルに適応し、AIの力を最大限に引き出すことが、今後の競争力を左右する鍵となります。