# コーディングエージェントの現状の整理とエンジニアの仕事の変化について コーディングの仕事における AI 技術の関わりといえば、[GitHub Copilot](https://github.com/features/copilot) を代表するエディタ補完型が主たるものとして認識されてきました。補完型の AI はユーザーが途中まで書いたコードを補完する形で提案を行うことから、ペアプログラムの相方のような存在として捉えられていました。例えば `function add` と書き始めると、AI は `(a: number, b: number): number { return a + b; }` といった形で関数の定義を提案します。ユーザーは Tab キーを押すことで提案を受け入れたり、提案が気に入らなければそのままコードを書き続けたりできます。  補完型の AI がユーザーにもたらす利点は以下のような点が挙げられます。 - 定型コード自動生成：テストコードのモックデータの作成や、`console.log` を用いたプリントデバッグ用のコードなど退屈で反復的な作業を任せられる。これにより開発のスピードが向上したり、開発者はより重要なロジックに集中できるようになる。 - 新しい言語やフレームワークの学習支援：普段なれない言語やフレームワークを扱う際に、AI がその言語やフレームワークの書き方を提案してくれる。これはまさにペアプログラミングによる知識移転の効果に近い。 さらに、以下の記事では GitHub Copilot が開発者の生産性に与える影響についての調査結果が紹介されています。 http://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/ しかし、補完型の AI はあくまでユーザーが書いたコードを補完するものであり、ユーザーが書くコードの範囲内でしか提案を行うことができません。つまり、ユーザーが書かない限り AI は何も提案しないのです。つまりは開発者の生産性や幸福度は確かに向上するものの、開発者が与えられたタスクを遂行するために自らコードを書く必要があるという点では従来の開発スタイルと大きく変えることはなかったのでした。 ChatGPT の登場による AI を取り巻く環境の変化は記憶に新しいところです。ChatGPT は自然言語での対話を通じて質問に回答したり、文章を要約できます。コーディングの分野においても対話型の形式でコードに生成や修正を行ったり、コードの内容の説明を求めたりできるようになりました。対話形式によりコードの生成を行う AI アシスタントは「チャット型」と類型できるでしょう。  コード補完型の AI と比較するとコードを 1 文字も書かずとも AI がユーザーの意図を理解し、必要なコードを生成してくれる点が大きな違いです。ユーザーは自然言語のみで AI に指示を出してやり取りを行うことができます。コード補完の例ではそもそも `function add` と書き始める必要があり、前提知識として TypeScript における関数の定義方法を知っている必要がありました。一方でチャット型の AI では「2 つの数値を足す関数を TypeScript で書いてください」といった自然言語での指示を与えるだけで目的を達成するコードを生成してくれます。このことはコーディングの知識持たない非エンジニアの人々にとっても AI を利用してコードを書くことができる可能性を示唆しています。 このようなチャット型の AI は開発者の生産性を向上させるだけでなく、開発者がコードを書くことに対するハードルを下げる可能性があります。特にプログラミング初心者や非エンジニアの人々が AI を活用して自分のアイデアを実現する手助けとなるでしょう。しかし、不明瞭な指示を与えた場合、AI が意図した通りのコードを生成できなかったり、品質の低いコードを生成してしまうこともしばしばあります。チャット型の AI アシスタントでは自然言語でコンテキストを正しく伝えるといったプロンプトエンジニアリングのスキルが求められるようになりました。AI に対して適切な指示を与えるためには、AI の特性を理解し、どのような情報を提供すれば望ましい結果が得られるかを学ぶ必要があります。結局のところ、AI に適切な指示を出したり、AI が生成したコードをレビューするためにはソフトウェアエンジニアリングの知識が求められており、開発者の仕事は依然として重要な役割を果たしていました。 一方チャット型の形式という制約があることから、開発者の仕事を大きく変化させるようなブレイクスルーまでには至っていませんでした。チャット型の AI では「ユーザー」→「AI」→「ユーザー」という双方向のやり取りが必要であり、AI がコードを生成するたびにユーザーによるフィードバックを与える必要があります。タスクの目的を達成するためには通常複数回の会話の往復が必要であるため、AI にコードを生成させている間に開発者は他のタスクに取り組むといった並行処理が難しく、開発者の生産性を大きく向上させることはできませんでした。また、既存のコードベースをコンテキストとして参照してコードを生成させることはできたものの、参照すべきファイルをユーザー自身が選択する必要があります。コードベース全体のアーキテクチャを理解し、適切なファイルを選択するという点では、開発者の高度な知識と経験が必要でした。適切なファイルを選択できない場合には、モジュール間で一貫性のないコードが生成されてしまうこともありました。 その後 ChatGPT の登場による社会の激変から数年が経過し、AI 技術は大きく進化しました。LLM が従来よりも高精度なコードを生成できるようになり続けていることに加え、自律的に稼働する AI コーディングエージェントの登場により、開発者の仕事は大きく変わろうとしています。この記事ではコーディングエージェントの登場による開発者の仕事の変化について考察します。 ## コーディングエージェントとは コーディングエージェントとは、ユーザーからの指示に基づいて自律的にコードを生成し、実行する AI のことを指します。[エディタ型からCLI型・自律型へと多様化するコーディングエージェント](https://blog.lai.so/agent/)という記事では、コーディングエージェントの進化を以下の 3 つのタイプに分類しています。 > ### エディタ型（GitHub Copilot, Cursor） > - 自動運転レベル： レベル2（部分自動化） > - 開発者の関与： 常に監視し、いつでも介入可能。リアルタイムに差分確認・承認・修正 > - 動作環境： エディタ内 > - 重視する価値： 安全性 - 全ての変更を制御可能 > ### CLI型（Claude Code, Codex CLI） > - 自動運転レベル： レベル3（条件付き自動化） > - 開発者の関与： エージェントが開発担当。重要な判断時に確認を求められる > - 動作環境： ターミナル、ファイルシステム > - 重視する価値： 効率性向上 - エージェントのモジュール化 > ### 自律型（Devin, OpenHands） > - 自動運転レベル： レベル4（高度自動化） > - 開発者の関与： 目標設定と結果確認のみ。緊急時のみ介入 > - 動作環境： VM・コンテナ（サンドボックス） > - 重視する価値： 生産性最大化 - タスク完全自動実行 それぞれのタイプに応じて開発者の関与の度合いは異なるものの、コーディングエージェントの核となる機能は一致しています。「自律的にコードを生成する」とは、ユーザーからの介入を受けずにユーザーから与えられたタスクを完了を目指して AI がコードを生成し、実行することを指します。コーディングエージェントが自律的に動くために例えば以下のようなことが行われています。 - 現在のコードベースを理解するためにコードをインデックス化し、修正が必要な箇所を特定する - コードを書くにあたって必要な情報を収集するために、Web サイトをブラウジングする - 生成したコードが正しいかどうかをテストするために、テストや lint を実行する 開発者の関与の度合いはコーディングエージェントがコードを書いている最中にどの程度ユーザーが介入できるかに依存します。自立型と定義されている Devin ではユーザーはほとんど介入することはありません。ユーザーはタスクの目的を与えると、プルリクエストを作成するまでの一連のコード生成を自律的に行います。このフローは人間の開発者にタスクを指示する流れとほとんど変わりません。AI が生成したコードの評価はプルリクエスト上でのコードレビューを通じて行われます。 ユーザーの介入をほとんど必要としない自律型のコーディングエージェントは、AI にタスクを任せている間ほかの仕事（ミーティングやドキュメント作成など）に集中できる点が大きな利点です。また通常人間の開発者よりも高速にコードを生成できるうえに、複数のタスクを並行して処理することも可能であるため、生産性が大きく向上する可能性があります。 その一方で大きな手戻りが発生した場合にはかえって生産性が低下してしまう可能性があります。これから指示を出す予定のタスクの確度が高い場合には自律型のコーディングエージェントは非常に有用ですが、タスクの内容が不明瞭な場合や、AI に任せるには難易度が高いと判断される場合には適していません。そのような場合には、人間が細かいフィードバックを与えながらコードを生成するエディタ型や CLI 型のコーディングエージェントを選択すべきと言えます。AI が情報の収集に苦戦している場合にはユーザーから適切な追加の情報を与える、これから生成しようとしているコードをレビューして修正を加えるといった人間の細かい介入を与えることによって、より早く正確にタスクを完了できる可能性が高まります。 人間の仕事の進め方に例えるならば、マイクロマネジメントと放任主義をどのように使い分けるかという点に近いでしょう。人間のマネジメントでは一般的に部下の経験年数（オンボーディング期間ではマイクロマネジメントを行い、経験を積むにつれて放任主義に移行する）やタスクの内容に応じてマネジメントのスタイルを変えることが多いです。コーディングエージェントも同様に、タスクの内容を見極めて適切なタイプのコーディングエージェントを選択することが重要であると考えます。 !> 人間と違い AI はモデルの更新以外では経験を積むことはできないものの、これは人間側のプロンプトエンジニアリングスキルの向上という形に置き換えて考えられるでしょう。つまり、はじめから的確な指示を与えることができているならば、途中で AI に介入する頻度を減らすことができるということを示しています。 私はタスクを大まかに以下の 3 つに分類してコーディングエージェントを使い分ける一種のルールとして使用しています。 1. 30 分以内で完了する小さなタスク → 自立型のコーディングエージェント 2. チャレンジングなタスク → CLI 型, もしくは自立型のコーディングエージェント 3. 大規模なタスク → 人間によるタスク分解が必要 ### 30分以内で完了する小さなタスク 30 分以内で完了する小さなタスクは、コーディングエージェントに任せるのに適しています。例えば、バグ修正や小さな機能追加など、明確な目的があるタスクが該当します。昨今の優秀な AI モデルであるならば、既存のコードベースを理解したうえで適切なコードを生成してくれる可能性が高いですし、たとえ手戻りが発生したとしても修正に多く労力が割かれることはないでしょう。 小さなタスクをコーディングエージェントに任せるメリットは仕事のスケーリングにあると言えます。一人の開発者が複数のタスクを同時に処理できるため、1 つの期間でより多くのタスクを完了することが期待できます。またバグが報告されてから修正までの時間を短縮するような効果もあるでしょう。 チームの仕事の進め方にもよりますが、すぐに修正ができそうな画面上のバグ（ダークモードでの表示崩れや、ボタンの位置がずれているなど）が報告されたような例を考えてみましょう。これらのバグは通常、開発者が数分で修正できるものとここでは仮定します。しかし、実際にコードの修正が本番に反映されるまでには思った以上にコストがかかります。なぜならバグが報告されたタイミングでは、開発者が修正作業に着手するまでに他のタスクが優先されることが多いためです。一旦タスクを中断してバグの修正を先に行うことにしたとしても、元のタスク戻るうえでのコンテキストの切り替えが必要になります。 コーディングエージェントにバグ修正を任せるには一言 Slack でメッセージを送るだけで済みます。このように突発的に発生した小さなタスクをコーディングエージェントに任せることで、開発者は他の重要なタスクに集中できるようになるでしょう。 ### チャレンジングなタスク チャレンジングなタスクは、自律型のコーディングエージェントに任せるには難易度が高いようなタスクです。例えば既存のコードベースに参考となるようなコードが存在しない、もしくは AI が理解するのに十分な情報が与えられないようなタスクが該当します。このようなタスクを自律型のエージェントに任せると、思考の過程で袋小路に入ってしまいタスクの完了までに多くの時間がかかってしまったり、ユーザーの期待とは大きく乖離したコードが生成されてしまう可能性があります。 基本的にはチャレンジングなタスクに取り組む場合には人間が介入可能な CLI 型やエディタ型のコーディングエージェントを使用するべきです。個人的には Claude Code を使用するのが好みです。コーディングエージェントとして評価が高い Claude 系列のモデルをしており、期待通りにコードを生成してくれることが多いです。タスクを実行する前に TODO リストを作成してくれたり、ユーザーの入力をキューイングしてくれるといったように UI 面での使いやすさも優れています。さらに IDE 統合機能が追加されたことにより、現在開いているファイルのコンテキストを参照するといったように、エディタ型のコーディングエージェントのような使い方も可能になりました。 状況に応じて、チャレンジングなタスクに対して自律型のコーディングエージェントを使用する場合もあります。例えばこの後の時間にミーティングが入っており、タスクに取り組む時間が限られている場合です。ミーティング中には CLI 型のコーディングエージェントを使用していたとしても人間が介入する余地がないため、エージェントを有効に働かせられないことが想定されます。このような場合には期待する成果が得られないことが想定されていたとしても、自律型のコーディングエージェントにタスクを任せることがあります。何も生み出さないよりは 60% くらいの成果を出してくれたほうがマシだと考えるからです。 実際にミーティングが終わった後にゼロからタスクに取り組むよりも、AI が生成したコードをベースにして修正を加えるほうが早くタスクを完了できることが多いです。AI が生成したコードは必ずしも完璧ではありませんが、少なくともゼロからコードを書くよりは時間を節約できる可能性があります。多少修正した程度ではどうしようもないようなコードが生成されてしまった場合には、潔くタスクを中止して人間がゼロから取り組むこともあります。 私自身も仕事でコードを書く際には、Devin を並行して起動しておき、それぞれのタスクが完了した順に Claude Code を使用してコードを修正していくといったような使い方をしています。ただし、このような Devin の使い方は金銭的なコストを度外視しているため、検証が必要でしょう。 ### 大規模なタスク 大規模なタスクはどのタイプのコーディングエージェントを使用しても完了できないようなタスクです。例えば、アプリケーションの大規模なリファクタリングや複数のマイクロサービスの修正が必要な新しい機能の追加などが該当します。このようなタスクは通常、複数のサブタスクに分割され、それぞれのサブタスクに対して個別に取り組む必要があります。このことは Devin を使用する際のガイドラインとしても記載されています。 https://docs.devin.ai/essential-guidelines/when-to-use-devin 大規模なタスクに取り組むのは通常テックリードやアーキテクトといった経験豊富な開発者です。タスクの内容を理解し、適切なサブタスクに分割するためには高度な知識と経験が必要です。AI に任せることができるのはあくまでサブタスクのレベルまでであり、タスク全体のアーキテクチャを理解しているのは人間の開発者だけです。 そもそも大規模なタスクは AI に限らずそのまま人間の開発者に任せるべきではありませんね。 ## コーディングエージェントの登場で変化する仕事のあり方 コーディングエージェントが開発プロセスに深く関わるようになることで、開発者の仕事のあり方は大きな変革期を迎えています。これまでのように、仕様を元にひたすらコードを書くという作業から、より戦略的で俯瞰的な役割へとシフトしていくと考えられます。 ### 適切にタスクを分割し割り当てる能力 自律型を含むコーディングエージェントがタスクを実行できるようになったとしても、どのようなタスクを、どの程度の粒度で、どのエージェントに（あるいは人間に）割り当てるかという判断は依然として人間に委ねられます。むしろ、この「タスクの分割と割り当て」の能力が、開発者の生産性を左右する重要なスキルとなるでしょう。 前述の通り、大規模なタスクや定義の曖昧なタスクは、そのままコーディングエージェントに任せることは困難です。開発者は、まずプロジェクト全体の目標を理解し、それを実現可能なサブタスクへと分解する必要があります。その上で各サブタスクの特性（単純作業か？創造性が必要か？既存コードへの依存度は高いか？など）を見極め、最適なコーディングエージェントを選択したり、場合によっては人間が担当したりといった采配が求められます。 これは、従来のプロジェクトマネージャーやテックリードが担っていた役割の一部を、より多くの開発者が担うようになることを意味します。AI が理解しやすく、かつ期待する成果物を生み出せるような、明確で質の高い指示（プロンプト）を作成する能力も、この文脈で重要性を増してくるでしょう。 ### コードレビューが仕事の中心に コーディングエージェントがコード生成の大部分を担うようになると、開発者の主な仕事の 1 つとして「コードレビュー」の比重が格段に高まると予想されます。AI が生成したコードは人間が書いたコードと同様に、あるいはそれ以上に、品質・セキュリティ・保守性そしてプロジェクト全体の設計思想との整合性といった観点からの厳密なチェックが必要です。 特に自律型のコーディングエージェントを使用している場合には、途中で介入することはほとんどないため、コードレビューの時間が AI にフィードバックを与える唯一の機会となりえます。幸いチーム開発において「コードを読む」という行為は元々重要視されていたスキルです。この点においては、従来のスキルがそのまま活かされるでしょう。 一方でコードレビューの比率が高くなりすぎるという潜在的な問題もあります。我々開発者はコードを書いて何かを作るのが好きでこの仕事を選んでいる人も多いでしょうから、仕事としての楽しさはレビューするよりもコードを書くことにあると考える人が多いのではないでしょうか。今までは多くとも半々位の比率でコードを書くこととレビューを行うことはできていたのではないでしょうか。 しかしコーディングエージェントがコードを書くスピードはあまりにも早すぎます。結果として人間はただただ積まれていったプルリクエストのコードレビューに追われるといった状況に陥る可能性があります。結果として開発者自身の仕事の満足度が低下してしまうことも考えられます。 AI を活用したコードレビューも手法として提案されていますが、私自身この方法はあまり効果的ではないと感じています。小さな typo などの指摘はうまく行えているように思いますが、コードベースの根的にある設計思想や、コードの意図を理解したうえでのレビューは AI には難しいと感じています。またコードレビューの目的の 1 つに知識の共有があることも忘れてはいけません。 ## AI 疲れにどう向き合うか コーディングエージェントをはじめとする AI 技術の進化は目覚ましく、開発者の仕事の生産性を飛躍的に向上させる可能性を秘めています。しかしその一方で、「AI 疲れ」と呼ばれる現象も広がりつつあります。[@t_wada](https://x.com/t_wada)さんのポストでは 2 種類の AI 疲れが指摘されています。 > 最近の「AI疲れ（AI fatigue）」は2種類ありそう。1つめはわかりやすく「AIの進化が速すぎるのでキャッチアップに疲れる」なのだけど、2つめは「AIの仕事が速すぎるので人間がボトルネックになり、休みなく高頻度で判断が迫られ続け、労働強度が高すぎて疲れる」だと考えている。 https://x.com/t_wada/status/1927908798099759342 2 つ目の「AI の仕事が速すぎるので人間がボトルネックになり、休みなく高頻度で判断が迫られ続け、労働強度が高すぎて疲れる」という現象は、コーディングエージェントの登場によって体感されるようになった方も多いのではないでしょうか。多くの簡単なタスクは自律型のコーディングエージェントが行うようになれば、開発者に残されるのはより複雑なタスクや、AI が生成したコードのレビューといった仕事になります。複雑で責任の重いタスクだけが人間に残されるという構造は [AI マインスイーパー](https://x.com/mametter/status/1662979669053050881) を思い起こさせます。 また今までの仕事では求められていなかった能力が要求されるようになったことも、AI 疲れの一因と言えるかもしれません。自律型のコーディングエージェントは複数のタスクを並行稼働できるため、開発者は自分が指示したタスクの進捗を常に把握し、必要に応じてフィードバックを与える必要があります。これまでのように 1 つのタスクに集中して取り組むことができなくなり、常に複数のタスクを同時に意識しなければならないという状況は、プレイヤーからマネージャーへと役割が変わったような感覚を与えるかもしれません。 また多くのプルリクエストが並んでいるのを見ると、自身がレビューを行うべきタスクが山積みになっていることに気づくでしょう。AI が短期間に多くのタスクを完了させる一方で、人間がその速度に追いつけずにボトルネックになってしまうという状況は、開発者にとって大きなストレスとなります。 かといって AI を使わないという選択肢は別のリスクを伴います。同僚や競合他社が AI を活用している中で、自分だけが AI を使わないという選択をすると、仕事の効率が大きく低下し、結果として自分自身のキャリアに悪影響を及ぼす可能性があります。いつの時代でもこのような競争は避けられません。 AI 疲れにどう向き合うかは、これからの開発者にとって重要なテーマとなるでしょうが、まだ明確な答えのようなものは見つかっていません。コーディングエージェントにタスクを任せている間自主的に休憩を取るといった対策も考えられますが、真面目な性格の開発者ほど「AI がタスクを完了するまで自分は何もしていない」という罪悪感に苛まれうまく休むことができないかもしれません。またコーディングエージェントの生産性を基準にスプリントの計画を立ててしまうことも考えられます。 ## 時代の転換点に立ち会えたことを楽しもう 思えば人類の歴史は、技術革新による仕事の変化の連続でした。原始時代の狩猟採集から農耕社会、産業革命、そして情報化社会へ様々な「ゲームチェンジャー」が登場し、それぞれの時代で人々の働き方や価値観が大きく変わってきました。現在の AI 技術の進化も「ゲームチェンジャー」といえるでしょう。一度ゲームチェンジが起これば、二度と後戻りはできません。また歴史の流れに逆らうものは例外なく亡ぼされてきました。つまり生き残りたければ、「つねに時代の波を読み、これに乗ること」が大切なのです。 歴史の知識としては知っていても、実際にその時代の転換点に立ち会うことはなかなかできるものではありません。リアルタイムで社会が変化していく様子を目の当たりにできることは、非常に貴重な体験ではないでしょうか？仕事が AI によって変わることに対して不安を感じる方も多いかもしれませんが、ある意味変化を楽しむチャンスとして捉えるのも良いかもしれません。 ## まとめ - AI によるコーディングの支援は GitHub Copilot のような補完型 AI から、ChatGPT のような対話型 AI、そして自律的にタスクを遂行するコーディングエージェントへと進化を遂げている - ユーザーの指示に基づき、自律的にコード生成、テスト、修正を行うコーディングエージェントは、開発者の生産性を飛躍的に向上させる可能性を秘めている - エディタ型、CLI 型、自律型など、関与の度合いやタスクの特性に応じて適切なコーディングエージェントを選択することが重要。小規模タスクは自律型、チャレンジングなタスクは CLI 型や状況により自律型、大規模タスクは依然として人間による分割が必要である。 - コーディング作業そのものよりも、タスクを適切に定義・分割し、AI エージェントに的確に指示・割り当てる能力がより重要になると考えられる - AI が生成したコードの品質、セキュリティ、保守性を担保するため、人間による高度なコードレビューの重要性が増している ## 参考 - [Research: quantifying GitHub Copilot’s impact on developer productivity and happiness - The GitHub Blog](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/) - [CLINEに全部賭けろ](https://zenn.dev/mizchi/articles/all-in-on-cline) - [エディタ型からCLI型・自律型へと多様化するコーディングエージェント](https://blog.lai.so/agent/) - [Cognition | Introducing Devin, the first AI software engineer](https://cognition.ai/blog/introducing-devin?ref=blog.lai.so) - [The End of Programming as We Know It – O’Reilly](https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/) - [ゲームチェンジの世界史 (日本経済新聞出版) 電子書籍: 神野正史](https://www.amazon.co.jp/%E3%82%B2%E3%83%BC%E3%83%A0%E3%83%81%E3%82%A7%E3%83%B3%E3%82%B8%E3%81%AE%E4%B8%96%E7%95%8C%E5%8F%B2-%E6%97%A5%E6%9C%AC%E7%B5%8C%E6%B8%88%E6%96%B0%E8%81%9E%E5%87%BA%E7%89%88-%E7%A5%9E%E9%87%8E%E6%AD%A3%E5%8F%B2-ebook/dp/B09XN2VXJT/ref=tmm_kin_swatch_0)