Sign in Subscribe

私のソフトウェア開発を一変させてしまった2025年のAIエージェントをふりかえる

2023年から段階的にAIを開発フローに組み込み、2025年は試行錯誤とツールの大きな変化、そしてエージェント化を経て、私のソフトウェア開発の進め方は明確に変化しました。
ここで言う「変化」とは、単に作業が速くなった、便利になったという話ではありません。
より具体的には「コードをタイピングする時間よりも、間接作業の比重と抽象的な思考・ロジックが増えた」という意味での変化です。

より深刻なのは文字入力回数の増大です。その結果、マイクに向かって話したり、タイピングの練習といったプリミティブな活動を取り入れるようになりました。

この変化は私だけのものではありません。Addy Osmaniは『Beyond Vibe Coding』で「開発者の役割はコードを書くことから、コードを指示すること（directing）へシフトしている」と述べ、アーキテクチャやデザインパターンといったシステム思考への集中を説いています。Latent SpaceのSwyxも「ソフトウェアエンジニアの強みは抽象化のレベルを上げることに最も長けている点だ」と指摘しています。

この流れに対して「コーディングがつまらなくなるのでは？」という問いがあります。私なりの答えは後半で触れます。

さて、本記事では、GitHub上でマージされたPull Request数の推移を観測指標として取り上げます。記事末尾に計測スクリプトを載せているので、みなさんも同じ方法で自分のアカウントを振り返ることができます。

比較の前提

比較対象は、AIエージェントを開発フローに組み込む前後です。短期的な増減ではなく、年単位での傾向の変化を見ています。

私の環境では、2023年はCopilot補完やCursorのチャットを中心としたコードを書き時の「補完的な利用」が主でした。ここではエディタのウィンドウであるか、サイドパネルであるかの差です。
2024年になると、Cursor ComposerやCopilot Editsを用いた開発自動化が入り始めます。複数のファイルを一括置換や、エディタからシェルコマンドが発行されたりし始めました。

この時点で相当の変化を実感していたのですが、2025年は更なる試行錯誤の連続でした。

業界全体を見ても、AIエージェントが前提となる開発スタイルが一気に広がった年でした。バイブコーディング[1]・AI駆動開発などを号令に「とりあえず全部AIに投げる」ような振る舞いも珍しくなくなりました。これはソフトウェアの外部観測（動くかどうか）のみを見て自然言語で開発するスタイルであり、現在も一定の支持を得ています。

開発行為そのものの性質が変わり始めた年であり、実際そのような記事を増えました。個人的にはその変化の速さに、正直なところ少し呆然とする場面もありました。このサイトでは一定の距離を置いて要素技術の分解と解説だけに注目していたと思います。

私自身の経緯に戻ると、年初の時点ではClineのOSS実装コード[2]やMCPの仕組み[3]に強い衝撃を受け、ほぼそれに賭けるような形で試行を進めていました。

名記事「CLINEに全部賭けろ」では「エージェントは危険だが強力で、プログラマの役割を根本から変える存在であり、仕事の再定義が必要」という立場が示されています。

この頃はCursorやCopilot Chatも併用しており、まだClineに限らず「どれが主軸になるか」は定まっていませんでした。2月以降はClaude Codeのプレビューが始まり、Sonnet系モデルを中心に本格的な利用へ移行します。

一方で、コストや安定性の問題もあり、常に手放しで満足していたわけではありません。重課金ユーザーが何十万も使っているのにドン引きしつつも、何気なく自分もAPIアクセスしていたら10万円超えの請求が発生しよく調べたらエージェントループがコンテナの内部で暴走していた、などのトラブルもありました。

春先にはMCPが業界全体に広く話題化したことで一度冷めたり、それに伴ってSNSで飛び交うような刺激の強い話題を眺めて、情報摂取自体を絞ったりと、ツールそのものよりも距離感の調整に意識が向く時期もありました。
Windsurfなど別の環境を試し、反復横跳びのような状態になっていたのもこの頃です。

夏以降はClaude 4やGPT-5などを機に、業界が一転します。特に定額プラン制の存在が大きく、2月時点では数十万円以上かかっていた規模の利用コストが、月1〜2万円程度で済むようになりました。

性能としてはClaude 4が一旦のマイルストーンで、個人的にはその後はツールやモデルの更新頻度がさらに上がり、「何がより賢いのか」よりも「どう計測するか」[4]に関心が移ります。
Aiderのベンチマークを参考に、観測結果やエラーメッセージも含めて記録する自分用の簡易ベンチマーク（ts-bench）を作り始めたのもこの流れでした。

TypeScriptファーストなコーディングAIエージェントのベンチマーク「ts-bench」を公開しました
AIコーディングエージェントのTypeScriptコード編集能力を評価するための、手軽に再現可能なベンチマークプロジェクト「ts-bench」を公開しました。この記事では、筆者がなぜ ts-bench を作ったのか、今後どうしていきたいかについてお話しします。 GitHub - laiso/ts-benchContribute to laiso/ts-bench development by creating an account on GitHub.GitHublaiso ts-benchの仕組み ts-benchは、プログラミング学習プラットフォーム Exercism のTypeScript問題セットを利用します。各問題には、仕様を説明するドキュメント、エージェントが編集すべきソースコードのひな形、そして正解判定に使うテストコードが含まれています。 ベンチマークタスクは、各問題に対して以下の4つのステップを順番に実行します。 1. AIエージェントの実行: 問題の指示書をプロンプトとしてAIエージェントに渡し、ソースコードを編集させます。 2. テストファイルの復元
laisolaiso

最終的にはClaude Codeを主軸とした構成に落ち着きますが、これは最初から決めていた結論ではありません。アップデートごとに注意を奪われ、試しては失敗し、ハイプに冷めてはまた使う、という揺れを経た結果です。

この経緯が、後述するマージPR数の変化を読み解く前提になります。
過程を振り返ると、変化は特定のツール導入の直後に起きたものではなく、試行回数そのものが増えた一年の結果だった、と表現するほうが近いように思います。

私の状況でユニークなのは、AI以外の環境要因が結果的に固定されていた点です。開発体制はほぼ一人、マージはセルフマージ、言語はPHPとPython、TypeScriptが中心。レビューもAIが担い、プロジェクト形態に大きな変更はありません。ブロッカーは自分自身で、開発対象の誤差はあれど、これが数年状況として変わっていません。

そのため、マージPR数の変化をAI導入と切り離して説明することは、むしろ難しい条件だと考えています。

使っているAIエージェントと開発の実態

まず、具体的なツールと開発フローについて書きます。

エディタ型からCLI型・自律型へと多様化するコーディングエージェントで紹介した中で、私が主に使っているのはGitHub Copilot、Claude Code、Cursorです。

エディタ型からCLI型・自律型へと多様化するコーディングエージェント
はじめに：コーディングエージェントの新たな分類 今年初めに筆者が投稿した「ClineとAIコーディングツールの現状」ではAIコーディングツールを「コード補完」「チャットアシスタント」「コーディングエージェント」の3つに分類しました。しかし現在では「エージェント」が包括的な概念となり、この区別の必要性が薄れています。 さらに現在は役割や機能ではなく * コーディングエージェントがどこまで自律的に開発プロセスに関与するのか * 開発タスクが実行される環境はどこか * ユーザーとの対話インターフェイス が本質的な違いになってきました。 本記事では、こうした変化を踏まえて解説します。 本記事の分類について 「AI Agents Are Here. What Now?」ではAIエージェントの重要な特性の一つとして「自律性（autonomy）」が挙げられています。「自律的（agentic）」であるとは、ある目標が与えられた際に、それをサブタスクに分解し、各サブタスクを人間の直接的な介入なしに実行して解決できることを指します。 AI Agents Are Here. What
laisolaiso

GitHub Copilotは2023年以前から契約しており、インラインコード補完のメインです。インライン生成機能は主にドキュメント編集で活躍しています。つまりチャットパネルではなく、エディタウィンドウ内で活躍してくれます。

Claude Codeは開発全般を行うメインツールです。理由はデータポリシーの都合で送信先をBedrock（AWS）にできるからです。もしAzure中心の環境であれば、Codex CLIを主軸にしていたと思います。

つまり、このレイヤーのツール差にはこだわっていません。それよりはモデルが重要で、モデルを選ぶとツールが付いてくるイメージです。

CursorはGUI派向けの選択肢として、評価と調査に時々使います。CLI型エージェントと根本的にデザインが異なるので最新状況が気になるのと、モデル開発元ではないサードパーティである点も重要です。ここをClineにしないのは従量課金を避けているから、ぐらいの理由です。

開発フロー

ここからは、普段どのように開発しているかを書きます。

  1. EdgeやChatGPT Atlas、Ask Devin、DeepWikiでドキュメントを読みながら開発したい内容を相談する
  2. 固まったらMarkdown（PLANS.md）に保存
    1. 保存しておくことで記憶を持たないLLMに初期データとして与えることができます
    2. このPLANS.mdはタスクごとのCLAUDE.mdのような役割でタスクが終わると清書してPRに貼り付けます
  3. それをPlanモードに渡し、動くアプリケーションをまず作る
  4. 動作確認し、スクショを与えつつUIを調整する
  5. テストコードに難癖をつける（初期化データを確認するだけで100行書くんじゃない、モックを外そう、他のテストの真似をして、など）

この時点で、UIやコードに気に入らない点が大量に残るのが常です。2025年初頭では、そもそも動くものが出てこないケースも多くありましたが、それはなくなりました。逆に言えば、いくら入力情報（プロンプトと呼ばれる）を増やしても動くものができないプロジェクトは、AIコード生成の難易度が高いと言えます。

入力情報を作るのもドキュメント生成というタスクの１つですのでAIが活用できます。慣れていない人はAntigravityに手伝ってもらうと良いでしょう。

AntigravityはどういうAIエディタなのか
GoogleがGemini 3と同時にAntigravityという新たなAI コーディングエディタを発表しました。 Google AntigravityGoogle Antigravity - Build the new wayGoogle Antigravity 内部技術としては、Google製のChromiumとV8エンジンを内蔵したエディタをGitHubが作った過程で生まれたElectronというフレームワークでマイクロソフトのWebエディタMonacoをデスクトップ化したVisual Studio CodeのOSS版ディストリであるCode-OSSをフォークしたWindsurfの取得時点のライセンスを使い再構築された[1]Googleの独自エディタアプリです（1周した！）。 [1]: 内部には Windsurf/Cascade 由来と思われるコード痕跡が見られる しサードパーティライセンス記述がある し開発チームにはKevin Houがいる ただし、表層の実装は魔改造Windsurf寄りでありつつも、プロダクト設計はKiroに近い方向へ振れており、AIエージェントを中心
laisolaiso

テストとデバッグ

  1. Chrome DevTools MCPを使い、Claude CodeとE2Eテストを実施する
    1. PLANS.mdを使い回して、ついでにここにタスク情報を書いていきます
  2. 詰まったところは自分で解消する
    1. ロボット掃除機のために床の物をどかす、という比喩が一番近い
    2. 実際にClaudeの推論中に床掃除をしているのは私ですが・・
  3. 動作確認できたらスクリプトにして保存する
    1. テストデータのセットアップ、APIリクエストシナリオなどは使いまわせることが多い
  4. リファクタリングしながらE2Eテストをしながら開発フローをループする

一時期は最後にPlaywrightでコード化もしていましたが、最近は面倒でやっていません。都度オンデマンドに実行しています。

レビュー

  1. /review $PR_NUM で手元で確認し、リファクタリングの参考にする
  2. デプロイ単位のブランチを作ってそれをClaudeのGitHub Actionでレビューします
    1. 手元で実行していると保存されないので、半ば記録用です

Claudeはインラインコメントを大量に書きますが、あえて抑制はせずに削除しながら中身を読むマーキングにしています。

これをやっても「読んだはずなのに実装を理解していなかった」という自己嫌悪は頻繁に起こります。やはり自分で書かないと理解は浅くなります。この点は外部委託で開発されたコードを受け取るときや、マネージャとしてプロジェクトに入った時とよく似ています。

モデル選択

プランニングやレビューのフェーズでモデルを使い分けるようなTIPSも世の中にはありますが、私のやり方では以下のとおりです：

  1. 基本デフォルトモデル
    1. 現在のClaude CodeならOpus。CursorやCopilotならAuto
  2. うまくいかなかったらリセットしてPLANS.mdに反映
  3. パラメータ調整して一番高性能な設定で再挑戦
  4. それでもうまくいかなかったら人力でカバー

実際、マージPR数はどう変化したのか

冒頭で述べたPR数の観測結果を示します。

結果として、AIエージェント導入後、マージPR数は明確に増加しました。

年 マージPR 前年比
2023 160 -
2024 222 1.4倍
2025 321 1.4倍（2023年比で2倍）

少なくとも過去10年で最高値です。

この数字をどう解釈すべきでないか

ここは明確に線を引いておきます。マージPRが増えたからといって、生産性が上がったとは言えません。そう言ってしまうのは安直です。生産性には時間あたりの売上という見方もあれば、エンジニアの影響範囲と取得できるメトリクスから定義する方法もあります。

マージPR数はあくまで確定した作業単位が増えた兆候であり、価値や成果そのものを示すものではありません。開発生産性カンファレンスなどで議論されているテーマであり、私も勉強中なのでここでは語りません。

個人の感覚も、プロジェクトの雰囲気や単に時期、私生活で変わります。つまらない結論ですが、環境を考慮して、数値が増えた以上のことは不確定です。N=1であるプロジェクトはAI以外の部分でもうまくいっている実感がありますし、生活は普通で、身体は今のところ健康です。

今後の見通し

数字を見た上で、今後どうなるかを考えます。

これが2026年も伸び続けるとは思っていません。理由はいくつも考えられます。

まず、LLMのコード生成の能力への評価指標が不足しておりモデル開発が進まないだろうという予測があります。現在主流のOSSパッチ生成ベンチマークで測れる範囲の性能は飽和しています（個人的にはClaude 4以降は誤差）。マーケットの落ち込みもあり、AIへの過剰投資の影響が2025年後半出てきていました。

もっとも、1年単位で見れば何が起きるかは分かりません。
Skills[5]で無尽蔵に動的生成されたコードを実行とか、AIエージェント企業の淘汰により開発リソースがリバランスされブレイクスルーが起きるとか、ユーザー側の変化として活用ポイントを絞るなど目的が変わるとか。変数はまだ多く残っています。

この結果は他の人にも当てはまるのか

分かりません。本記事は、単一個人・単一環境の事例であり、再現性は保証できません。

ただし、ソロ開発・セルフマージ・AIレビュー中心という条件が近い人にとっては、何を観測すべきかを考える材料にはなるかもしれません。
チーム開発ではどうなっているのか、個人的にも強い関心がありますので、そのような環境にいる方からのご意見をお待ちしています。

まとめ

まとめとして本記事の要点を整理します。

  • 2025年、AIエージェントを本格導入した結果、マージPR数は2023年比で2倍に増加した
  • ただし「マージPR数 = 生産性」ではない。確定した作業単位が増えた兆候にすぎない
  • 増加は特定ツール導入の直後ではなく、試行錯誤を重ねた一年の結果として起きた
  • AI以外の環境要因（一人開発、セルフマージ等）が固定されていたため、変化をAIと紐づけやすい条件だった

具体的な計測スクリプトは以下です。GitHub GraphQL APIを使ってアクティビティを集計するので、コマンドラインを使える方であれば、みなさんのアカウントでも同様の計測ができます。大量にリポジトリを保有する方はAPI制限に注意してください。

$ uvx --from git+https://github.com/laiso/github-metrics create-report --year 2023 2024 2025
Authenticated as: laiso (ID: MDQ6VXNlcjM5ODMw)
Scanning repositories for strict commit counts ([2023, 2024, 2025])...
  Scanned 40 repositories (Total: 290)...
Finished scanning 290 repositories.
Fetching search metrics for 2023...
Fetching search metrics for 2024...
Fetching search metrics for 2025...

=== GitHub Metrics Report ===
| Year   | Commits    | PRs Created  | PRs Merged   | Issues   |
|--------|------------|--------------|--------------|----------|
| 2023   | 375        | 178          | 160          | 200      |
| 2024   | 575        | 246          | 222          | 129      |
| 2025   | 1092       | 385          | 321          | 126      |

このような「関心を持つ→コードを書く→記事にまとめる」という行程自体も、最近はAIエージェントに手伝ってもらいながら進めています。計測スクリプトの実装から、この記事の構成・推敲まで、一連の作業がAIとの協業で成り立っています。

この結果、本サイト（やなぜかX）の投稿数も増えましたが、「AI生成で時短・楽勝🎵」というわけでもなく。情報量の爆発・校正で無限に文章を増やす・勝手に意見やクリシェをねじ込む、などを押さえ込んで執筆するために余計に時間がかかっています（つらい）。

シニア開発者への補足的な提言

ここまで読んで、「自分にはこのやり方は合わない」と感じた方もいると思います。
特に、長年ハンドライティング中心でコードを書いてきた開発者にとって、AIエージェント前提の開発は、仕事の品質を保ちにくい、あるいは単純に楽しくないと感じる場面があるでしょう。

冒頭で触れた「コーディングがつまらなくなるのでは？」という問いに戻ります。「バイブコーディング」に違和感を覚え、あえて距離を置くようにしている、という話もよく聞きます。筆者自身も、その一人です。

その場合、いくつかの現実的な選択肢があると考えています。

1. レイヤーを下げる、という選択

C++、例えばQtやChromiumのような巨大で長寿命な基盤をなすコードベースに精通したプログラマーは、AI生成コードに慎重になる傾向があります（プログラム雑談 373回で語られているレビュー問題が象徴的です）。
これは個人の好みを超えて、保守性・安全性・責任範囲を考えれば妥当な判断ですし、現実として学習データや分野の問題なのか、生成されるコードの品質も低い傾向があります。

ZigはLLM利用を禁止しそれを促進するGitHubからも離脱、Linux KernelはAI生成コードの開示を要件化、Gentoo Linuxは2024年から全面禁止しています。これは「低レイヤーだから」ではなく、著作権のリスク、存在しないAPIをハルシネーションする品質問題、限られたレビューリソースの圧迫、などが関係すると考えています。結果として、広く組み込まれる基盤ほど「人が読み書きする前提」で運用されています。

ZigとAI Slob｜laiso
1,128字
しずかなインターネット

私自身、iOS や Android のネイティブ開発に触れる機会では、Web 開発と比べて AI の苦手さを強く感じました。

AIが不得意なレイヤーへ降りる、というのは逃げではなく、適材適所の判断だと思います。

2. より先端で、正解のない領域を見る

もう一つの方向性は、あえて AIがまだ得意でない領域に目を向けることです。

たとえば、Mozaic.fm の 2025年振り返りで語られていた話題群は象徴的でした。
学習データが少ない、正解が定義できない、文脈依存が極端に強い――そうしたテーマは、AIにとって依然として難易度が高い領域です。

特に Figma Make を巡る「デザインと開発の境界」の議論は必聴です（Mozaic.fm ep.194、Tailwind CSS→shadcn/ui→Figma Makeの流れ）。
エンジニアが想像するデザイン成果物と、そこに至るまでのデザイナーの作業とのギャップは、単純なテキスト生成の延長では解決できない複雑さを含んでいると感じました。

これらデザイン工程はコーディングと比較して「ベストプラクティス」が確立しておらず、組織・プロジェクト・チームの文脈によって最適解が大きく異なる領域であり、AIによる自動化・支援が困難な分野です。

大規模・高負荷システムの開発も同様です。一般的なコード生成の文脈から大きく外れ、独自のコンテキストを多く抱える領域では、AIの支援が効きにくい場面が増えます。

逆に、スタートアップや個人開発はAIエージェントとの相性が良いと考えています。プロダクトや市場の側には正解がなく、一方でコードの側には定型が多い。この組み合わせが、AIの得意領域とうまく噛み合います。

3. AIエージェントそのものを作る側に回る

最後は少しおまけですが、AIエージェント自体を開発する、という選択肢もあります。

これは当サイトで繰り返し扱ってきたテーマでもありますが、
「AIを使う」から「AIを設計する」へ視点を移すことで、違和感が知的な面白さに変わるケースも少なくありません。

AIエージェントは思ったより万能ではありませんし、合わない人がいるのは自然なことです。重要なのは、無理に乗ることでも、全面的に拒否することでもなく、自分の立ち位置を意識的に選び続けることだと思っています。

2025年の学びとして、AIエージェントの要素技術は私たちのよく知る手法の集合体で構成されていることがわかりました。

そして、3つ目の選択肢に関連して、来年についてお知らせがあります。

余談：来年の予定

プロジェクトが頓挫しなければ本が出ます。

最近Claude Code本がよく出ていますが、拙著はClaude Codeのエージェントのレイヤー自体を作る本です。これはSimon Willison や Andrej Karpathy もまだ成し得ていない、類を見ない書籍です。よく企画が通ったと感心します。

ただ世の中にあるエージェントOSSを参考にしているので、書ける人（賭ける人なのか？）は存在します。しかしAIマネーのビッグウェーブの最中、書ける人は本を書いている場合ではないので、私がやる価値はあります。それが狙いです。

状況が確定したら改めてお知らせします。未定ですが、余裕があったらレビューのお誘いをこのサイト登録者に発信するかもしれません。↓から登録してお待ちください。

  1. バイブスでコーディング — Karpathyが提唱した「コードを書かずAIに指示→ノールックマージ→エラーガチャ」という方針の解説 ↩︎
  2. プログラマとCLINE - これはパンドラの箱なのか — 暴走性・自律性・人間介入の希薄化を早期に認識した記録 ↩︎
  3. MCPクライアントアプリを作ってコマンドラインでエージェントを走らせよう — MCPを実装レベルで触った技術的根拠 ↩︎
  4. Kiroとコンテキストエンジニアリングの時流 — コードより「設計断片・Plan・決定ログ」の中間成果物管理が重要になる流れ ↩︎
  5. Claude Skillsとは何なのか？ — 「SKILL.md + スクリプト」をパッケージ化してモデルに機能拡張する仕組みの解説 ↩︎

Subscribe to laiso

Sign up now to get access to the library of members-only issues.
Jamie Larson
Subscribe