2025年のAIエージェント躍進を振り返り、2026年の今何をすべきか考える

本記事はあくまで私の観測している範囲での出来事について整理したものです。時期や数字の細部は記憶ベースなので、「これは違うのではないか？」という部分があれば指摘いただけるとありがたいです。

…とものすごく逃げ腰の予防線を張っておきます。

AIエージェントの躍進〜2025年編〜

2025年は体感としてCLI系の流れが強かった1年でした。

生成AIの進化は日進月歩で、UIを丁寧に作り込むよりもCLIで素早く統合した方が価値が出やすい、と感じています。CLIの方がGitHubやCI/CDツールなど様々なコマンドやツールとのインテグレーションが容易な点などが、CLI系が選ばれた理由として挙げられると思います。

CLI（Command Line Interface） とは、テキストベースでコマンドを入力してコンピュータを操作するインターフェースのことです。

そしてなにより、Claude CodeがCLIで広まったことが大きな要因の一つだと思います。時期は記憶ベースですが、2025年前半にCLIとしての存在感が増し、そこから一気に話題が広がった印象です。OpenAIやGoogleもターミナルで動くエージェント（Codex CLIやGemini CLI）を公開しており、CLI系の流れが加速したと感じています¹。

私の観測範囲では、依然としてCLI中心の利用が多い印象です。加えてClaude Codeには、CLAUDE.md・Slash Commands・MCP・Subagents・Skillsなどの仕組みが公式ドキュメント上でも説明されており²、CLI系ツールの作法を整理する役割を果たしているように感じます。これがClaude Codeを生成AIエージェントおよび生成AIツールのデファクトスタンダードに近い存在に見せている理由の一つかもしれません。

ターミナル環境への注目

CLIツールはターミナルで完結するため、ターミナル環境そのものへの関心が高まったと感じます。自分の環境ではエディタ内蔵ターミナルで文字化けや表示崩れが起きることがあり、専用ターミナルの方が安定する場面がありました。結果的にGhosttyやWezTerm、NeoVimといったターミナル周りのツールが話題になっている印象です。憧れこそありますが、私自身まだしっかり使用できていないので実際の使用感は語れません。ただ「慣れると異常に早く作業ができる」「使いやすい」ということはよく言われているので、そうなんだろうなと思います。自分の体験に置き換えると、普通のマウスよりもトラックボールマウスの方が慣れると楽だと感じるものに似ているのかなと思っています。

Claude Codeがもたらしたもの

話を戻します。Claude CodeはCLI系AIエージェントの流行を進めた立役者ですが、このツールや流行がもたらしたものは他にも多々あります。というかこちらが本題かもしれません。

個人的にざっくり挙げると、Claude Codeは以下の項目の重要性を提起したと思っています。

プロンプト
コンテキスト
AIモデル
エージェントの使い方（垂直・並列など）
CI/CD
テスト
レビュー
仕様書（ドキュメントも含む）
セキュリティ

実際は上記以外にもあると思いますが、集約するとこのあたりに落ち着くのではないでしょうか。これら9つを集約すると「AIエージェントを使用しアウトプット、いやアウトカムを最大化するにはどうすればいいか」から分岐したものだと感じます。

アウトプット/アウトカムの最大化とはすなわち、AIエージェントを使用して如何に最短で最大のアウトプット（コードやアプリ開発）を出し、最終的なアウトカム（提供する価値）を最大化できるかということです。人がスクラッチで何かを作るよりも、より低コストでより良いものを量産したい——そういうことだと思います。

列挙した9つの詳細は、世の中に良記事がすでに存在すると思うので省略しますが、ざっくりとだけ個人の主観も含めて整理します。

AIエージェントで議論が活発化した9つの項目

先に述べた通り、私の観測では、2025年はそれ以前の生成AIを「開発者が使用する」段階、つまりAIの仕事は開発者の作業補完という段階から、AIに基本的に開発してもらい開発者がレビューするという段階に近づいたように感じました。流行ったスライドの表現を引用させていただくと、自動車でいうハンドルを握る主体が開発者からAIに移行したと言えます。

アウトプットおよびその質を担保するために、以下の9つの項目が重要なのではないかと言われています。

プロンプト

AIおよびAIエージェントに与える指示のことです。一般的には自然言語ベースで指示を与えることが多いです。JSONやYAML、JSONC、TOMLなどで与えた方が構造化されていて良いという話もありますが、私の周辺ではマークダウン形式が多く、たまにXML形式も見かけます。個人的にはリスト（-）やヘッディング（#）などを使用しマークダウン形式で指示することが多いです。

最近では、開発者やユーザーがその場で考えて1対1でAIに与えるという文脈だけでなく、Claude Codeでいうスラッシュコマンドのようにカスタムプロンプトを事前に保存しておき、それを呼び出して与えるという使用法も見られます。

Claude CodeではCLAUDE.mdを置いて起動時に読み込ませる形で、リポジトリにカスタム指示を持たせられます²。なのでプロンプトはなんだかんだずっと重要な項目だなと思います。いずれユーザーがプロンプトを意識しなくても高性能を発揮できるようになっていくのかなとも思います。最近のモデル進化を見ると、ユーザーの意図をかなり読み取ってくれるようになった体感があります。

今の段階だと、ユーザーはAIエージェントを使う時に3つを意識すればいいのかなと思います。どのようにプロンプトを与えるか、どのようなプロンプトを与えるか、いつプロンプトを与えるか——この3点です。

コンテキスト

コンテキストに関しても重要な項目です。プロンプトと混同する部分もありますが、いわゆるAIが保持している情報（文脈）のことだと思います。要するに、プロンプトがコンテキストとしてAIに保持されるイメージです。プロンプト以外で保持されるコンテキストとしては、MCPや仕様書などにより流入してくる情報もあります。

MCP（Model Context Protocol） とは、AIモデルに追加の情報やツールを提供するためのプロトコルです。³

AIエージェントが一般的になるにつれ、保持してもらうコンテキストを如何に効果的なものにするかの議論が白熱し重要視されるようになってきた印象があります。

コンテキストを効果的なものにするためには、無駄な情報は与えない方がいいこと、状況によって適切な情報を与えること（短くシンプルなコンテキストが必ずしも最適だとは限らない）が重要だと思います。「不要にコンテキストを圧迫する」という認識からMCPが敬遠される空気も見かけました。Claude CodeではMCPツールを必要に応じて検索・読み込む仕組み（tool search）が用意されており³、このあたりの議論を少し整理してくれる印象があります。

AIモデル

AIモデルはそもそもAIエージェントが世に出る前から存在する概念であり、無論超重要です。Claude CodeもClaudeモデルの性能向上が普及の追い風になったと感じますし、AIモデルがAIエージェントに与える影響は計り知れません。

これはAIモデル開発ベンダーの進歩を静観するしかない状態ですが、開発者ができることといえば、AIモデル・AIエージェントを積極的に使用しフィードバックを公式に送ることくらいでしょうか。

あとは、AIモデル自体の進化以外であれば、そのAIモデルの性格を観察し汲み取ることかなと思います。Claude・ChatGPTらのモデルは、Claude Code・Codexへのエージェント化の段階でカスタムプロンプトが与えられていると推測できますが、それ以前のモデル自体のファインチューニングの段階で与えられている（食わされている）リソースの種類や質・量も異なります。これらを具体的に予測するのは中の人でもない限りほぼ不可能です。

しかし実際にAIモデルを使用する中で、「プロンプトAに対してClaude Codeは良い結果を出してくれるがCodexは微妙な結果しか出さない」といった状況や現象は開発者側でも確認できます。その結果を元に「じゃあこっちのモデル・ツールにはこういうプロンプトで情報を与えてみようか」という試行錯誤ができると思います。

エージェントの使い方

ここでいうエージェントの使い方とは、AIエージェントをどのように開発・作業時に使用するのかという項目です。例えば、垂直で使用するか並列で使用するかという考え方があります。

Claude CodeなどのCLI系エージェントはターミナルで使用しますが、いくつかのターミナルツールではタブの分割ができます。つまり並列でClaude Codeを起動し、別々の指示を出し作業させることも可能です。ただ個人的にこれは乱発すると認知負荷がかかりすぎてしんどいです。また一つのブランチ内で並列作業させると、作業内容によってはコンフリクトが起きます。そのため作業内容ごとにGitブランチを分けたり、並列作業をしやすくするためのものがtmuxやGit worktreeだと認識しています⁴。

また、並列という単語が正しいか定かではないですが、Claude CodeでいうSubagents機能も広義では並列に入るのかなと思います。イメージでいうと、複数のClaude Codeくんが影分身をして作業ごとに担当を割り振り、別々の作業を同時並行でさせる。これらは別々のコンテキストウィンドウで行われるというものです。一つのGitブランチ内での作業ではありますが、別々にコンテキストを保持し作業を並行で行ってくれるという、並行作業に最適化された機能と言えます。

テスト

ここでいうテストとは、主に以下のようなものでAIエージェント普及につれてより言及されている印象があります。

ユニットテスト
結合テスト
E2Eテスト
ビジュアルリグレッションテスト

他にもパフォーマンスやアクセシビリティ改善を狙ったテストもあります。それらも含めて、持続性が高い開発をするためにテストの必要性はより増しています。ただし闇雲にテストを書けばいいというわけでもなく、とにかくカバレッジを上げればいいというわけでもないと思います。そこらへんは書籍などを活用しながらキャッチアップ中です。

CI/CD

CI/CDについては、リンター・フォーマッター導入と起動タイミングの整備、自動テスト、自動デプロイといった領域が重要になっています。AIが生成したコードの品質を担保し、継続的に安定したデリバリーを実現するために、これらのパイプライン整備は欠かせません。

レビュー

レビューもテストと同じく、持続可能な開発をするために必要だと思っています。CodeRabbitやCodex、Claude Codeなどのレビュー支援ツールを組み合わせながら日々取り組んでいます。

2026年は特にレビューが重要になりそうだと感じています。Gitがそもそもエージェントによる開発作業に最適化されていないという説もありますが、Gitよりも良いサービスはそうそう作れないと思うので、基本的にはレビューの必要性やどのようにレビューするかを考えることになりそうです。

仕様書

SDD（Spec-Driven Development）など開発手法として取り上げられているくらい、AIエージェント開発において有効だとされています。これも先述したコンテキストの重要性に関係します。

SDD（Spec-Driven Development） とは、仕様書を先に書き、それをAIエージェントに与えて開発を進める手法です。

cc-sddやspec-kitといったパッケージがあるので、場面に応じて使用してみるのはアリだなと思います。

セキュリティ

正直、この領域はまだ勉強中で全貌は見えていません。AIは確かに賢いですが、脆弱なコードを生成したり、インフラ構成・設定をセットアップしたりすることが多々あります。エンタープライズ開発では特にそれらの脆弱性は防止したいため、セキュリティの知見が必要だなと感じています。

2025年を振り返って、結局2026年はどうするのが良いのか

振り返って最初に思ったのは「どうしよう…（考えることが多すぎて脳死）」でした。

まぁ何もやらずとも死にはしませんが、やるべきことはたくさんあります。自分の判断が正しいとは限りませんが、自分はまだあらゆる知識が浅く付け焼き刃だと感じることがあります。自分の状況・世間の状況・AIの力を考えた時に、AIを脳死でただ使ってただアウトプットを出すだけでは長期的に見てリスクだと思っています⁵。

そのため、2026年は以下のように立ち回ろうかなと思っています。

AI中心の開発フローを考える——先述した9つの項目を中心にAIでどのように効率的開発するかを考えたいです。

学びをAIだけに傾倒しすぎない——自分自身の知識が浅いとAIのアウトプットの良し悪しを判断できず、うまく使いこなせません。そのため、実際に自分の手を動かしAI以外もキャッチアップしていきます。

AIについて学ぶだけでなくAIで学ぶ——キャッチアップにあたっては、AIを積極的に活用し理解を高速で深めていきます。その理解の過程の途中または最終的に、守破離の離として自分独自のものを作れればいいなと思っています。

ドメインの知識を深める——事業やビジネスモデルへの理解も深め、自分の言葉で説明できるようにしておきたいです。AIを使ってただ作るのと、AIに正しい情報を与えて作るのでは成果が違います。

持続的な生活をする——社会人として過ごしていて思うのは、地頭の良さやコミュニケーション力・技術力なども重要ですが、最終的に体力が重要だということです。毎日適度に運動を取り入れ、栄養がある食事、質の良い睡眠、ストレスフリーな人間関係などは大事にしていきたいです。

頑張りどきは確かに存在しますが、大体の場面では継続力が重要だと思います。

最近はフレームワークではAstroやTanStack Start、リンター・フォーマッターはBiomeやOx系などに触れています。今後の展望としてはテスト領域、TCP/IP・ブラウザ・OSなどより低レイヤー領域への理解も深めようと思っています。あとは純粋にDBやサーバーなどサーバーサイド・インフラ方向へのスケールも考えていますし、セキュリティ領域にも手を出したいです。これらのいくつかはすでに手をつけていますが、一度に広げすぎても頭に入らないので、時間の使い方は定期的に見直していきたいです（デザインの理解もしっかりし直したい）。

余談ですが、最近は「CSSむずくね？？」と思っています。最初はなんてことなく触れていましたが、進化速度がえげつなく速いですし、CSS変数が出て以降は難化の一途を辿っている気がします。だが挫けない…!! CSS得意な人が何を考えてマークアップしているか、ものすごく気になります。

以上で本記事を締めようと思います。読んでいただきありがとうございました！