目次を表示する

Cursor：AI統合エディタプラットフォーム

エピローグ ── Agentic Engineering の時代を生き抜く

エピローグ ── Agentic Engineering の時代を生き抜く

シリーズ構成 Ch.1 プロローグ / Ch.2 2026年1〜3月の新機能 / Ch.3 コア機能詳解 / Ch.4 Cursor Rules深掘り / Ch.5 コンテキスト管理 / Ch.6 Automations・Cloud Agents・Bugbot / Ch.7 ベストプラクティス / Ch.8 アンチパターン / Ch.9 エピローグ（本章）

「Agentic Engineering」とは何か

2025年初頭、「バイブコーディング（Vibe Coding）」という言葉が技術コミュニティを席巻した。AIに自然言語で指示を投げ、出てきたコードを「雰囲気で」承認していくスタイルだ。プロトタイプを短時間で作り上げる体験は確かに刺激的で、「エンジニアリングの民主化が来た」という興奮が業界全体に広がった。

しかし2026年に入り、その熱狂は静かに、しかし決定的に変容した。「雰囲気で承認する」では済まなくなったのだ。

Bugbot の直接マージ率が35%を超えた。つまり全プルリクエストの3分の1以上が、人間のレビューをほとんど経ずにメインブランチへ入っていく世界が現実になった。Automations によってバックグラウンドエージェントは常時稼働し、Linear のチケットを拾っては実装し、PagerDuty のアラートに反応してはパッチを作り続ける。エンジニアが席を外している間も、コードベースは変化し続ける。

この新しい地平を「バイブコーディング」の延長線上で語るのは正確ではない。2026年のエンジニアに求められているのは「雰囲気」ではなく、意図的なオーケストレーションだ。何をエージェントに委ねて何を自分で判断するか。どの出力を信頼してどこに検証の網を張るか。品質の最終責任を誰が持つか。これらを意識的に設計できるエンジニアと、ただ補完を享受するだけのエンジニアとの間には、2026年においてかつてないほど大きな能力差が生まれている。

この設計的な姿勢を Agentic Engineering と呼ぶ。コードを書く職人から、エージェントに指示し・検証し・改善するアーキテクトへ。Cursor が示すのは「コーディングの民主化」ではなく、エンジニアリングの高度化だ。ツールが賢くなるほど、そのツールを使いこなす人間に求められる判断の質も上がっていく。

Bugbot の35%マージ率が何を意味するか、もう少し深く考えてみる価値がある。35%はエージェントが自律的に判断できた範囲だ。残り65%は、人間のレビューが不可欠だと判断されて止まっている。この65%こそが、エンジニアの存在意義が凝縮した領域だ。ビジネスロジックの妥当性、アーキテクチャの一貫性、セキュリティリスクの文脈判断、将来の保守性──これらは2026年においても、まだ人間が最後の砦を守っている。

エージェントが得意な領域は広がり続ける。だからこそ人間の判断が問われる領域の質もまた、上がり続けていく。

今すぐできる5つのアクション（優先度順）

原則論はここまでにして、具体的な話をしよう。Agentic Engineering に向けて今日から始められることを、優先度の高い順に5つ挙げる。

アクション1：.cursor/rules/ にコーディングルールを書く

最初にやることは、ルールの言語化だ。.cursor/rules/ ディレクトリに .mdc 形式のファイルを置くことで、プロジェクト固有のコーディング規約・命名規則・禁止パターンをAIに強制できる。

重要なのは「最小限で書く」ことだ。全ての規約をルールに書き込もうとすると、ファイルが肥大化し、AIへの指示が散漫になる。まず始めるなら「このプロジェクトで絶対に守ってほしい3つのルール」だけをシンプルに記述する。たとえばエラーハンドリングのパターン、型の付け方の方針、テストファイルの命名規則の3点だ。残りは後から段階的に追加すればいい。

ルールを書いた瞬間から、AIの出力が変わる。この体験を早く積み重ねるほど、ルールをどう育てていくかの感覚が磨かれる。

アクション2：@docs で使用ライブラリのドキュメントを登録する

AIが誤ったAPIを提案してくる原因の多くは、学習データのカットオフ問題だ。2026年の最新ライブラリについて、AIは過去のバージョンの知識しか持っていないことがある。

@docs 機能を使えば、使用中ライブラリの公式ドキュメントURLをCursorに登録できる。以降のChat・Agent Modeでは、登録したドキュメントをコンテキストとして参照する。「なんか古いAPIを提案してくる」という問題が劇的に減る。React、Next.js、Prisma、あるいはチームが内製したライブラリのドキュメントまで登録しておくと、AIの回答精度が目に見えて上がる。

アクション3：大きなタスクは必ず Plan Mode を経由する

実装を始める前にPlan Modeで計画を立てる習慣は、シリーズを通して繰り返し強調してきた。ここでもう一度強調しておく理由は、実際にこれをやらないエンジニアが多いからだ。

大きなタスクをいきなりAgent Modeに投げると、AIは最短経路で実装を始める。その経路が自分の想定と違っていた場合、出てきた成果物を見て初めて「あ、そういう方向じゃなかった」と気づく。修正のコストは、後になるほど高くなる。

Plan Modeで先に計画を出力させると、AIがどのアプローチを取ろうとしているかが言語化される。その計画に対して「この部分は別の実装方針でいきたい」とフィードバックするコストは極めて低い。計画段階での修正と、実装後の修正では、かかるコストが桁違いだ。5分の計画確認が、30分のリファクタリングを防ぐ。

アクション4：テストを先に書いてからAgent Modeに実装させる

「AIがテストも実装もまとめて書いてくれる」は本当だが、「AIが書いたテストはAIの実装に最適化されている」という罠がある。

テストファーストの原則をAI時代にも守る理由はここにある。人間が先にテストを書くことで、「この機能がどう振る舞うべきか」の仕様が言語化される。Agent Modeはその仕様に沿って実装を生成し、テストをパスすることで完了を証明する。

具体的には tests/ 以下に期待動作を記述したテストファイルを作成してからAgent Modeを起動し、「これらのテストを全てパスする実装を作って」と指示する。エージェントはテストという明確なゴールに向かって実装を進め、成果物の検証コストが大幅に下がる。テストという「答え合わせの基準」がある場合とない場合では、エージェントの出力品質に雲泥の差がある。

アクション5：Agent Review Tab を閉じてから「Fix in Chat」を使う

これは見落とされがちだが、実害が大きいアンチパターンの回避策だ。

Agent Modeが変更を提案した後、Agent Review Tab が開いた状態で「Fix in Chat」を使うと、AIは「現在のファイル状態」と「提案中の変更」の両方を同時に参照しようとする。この状態は意図せずファイルがサイレントリバートされるリスクを持つ。既に取り込んだつもりの変更が静かに消える、という事故が起きやすい。

正しいフローは、Agent Review Tab でまず変更を Accept/Reject して確定させること、その後で追加修正が必要な場合に Chat を使うことだ。「Tab を閉じてから Chat」という順序を守るだけで、このクラスの事故を防げる。Cursorを使い始めた初期に一度でもこの事故を経験すると体が覚えるが、経験する前に知っておいた方がいい。

Cursor を使いこなす「問い」

スキルは問いによって研ぎ澄まされる。以下の3つの問いを、折に触れて自分に問い直してほしい。

6ヶ月後の自分が「あのとき始めておいて良かった」と感じるプラクティスは何か。

今日の自分にとってやや面倒に思えることが、半年後には「なぜ早くやらなかったんだろう」と思えるものに変わっていることがある。Cursor Rules の整備、テストファーストの徹底、チームでのルール共有といったプラクティスはその典型だ。面倒さを感じる今この瞬間こそ、始めるべき合図だと思うといい。Agentic Engineering のコンテキストで言えば「今すぐ全部やる必要はないが、今すぐ一歩踏み出す必要はある」のだ。

AIが生成したコードを「信頼するか検証するか」の基準をどう持つか。

「AIのコードは全て疑え」も「AIのコードは効率的に承認せよ」も、どちらも極端だ。現実的な基準として参考になるのは、変更の影響範囲とリバーサビリティだ。影響範囲が局所的で、問題が出ても容易にリバートできる変更は信頼して進めやすい。反対に、データスキーマの変更・認証ロジック・外部APIとの契約に関わるコードは、AIが自信満々に提案してきても必ず目を通す。この判断軸を自分の中に育てることが、Agentic Engineering の実践だ。

チームとして使うとき、誰がルール管理をするか。

個人で使う分には「自分がルールを書いて自分が使う」で完結する。しかしチームで使い始めると、「誰がCursor Rulesを所有・管理するか」という問いが浮かび上がる。これはAI活用の問いであると同時に、チームのコーディング文化をどう作るかという問いだ。技術リードが一人で書いて終わりにするのではなく、チーム全員がプルリクエストベースでルールを提案・議論・改善できる構造を作ると、ルール自体が生きたドキュメントとして育っていく。Cursor Rulesをリポジトリの .cursor/rules/ に入れてバージョン管理することが前提の設計になっているのは、そういう理由がある。

シリーズ習熟マップ

このシリーズ全9章の関係性と、あなたの経験レベルに応じた入り口を整理しておく。

flowchart TD
    Ch1["Ch.1 プロローグ<br/>Cursorの立ち位置と歴史"]
    Ch2["Ch.2 2026年新機能<br/>Composer 2・Bugbot・Automations"]
    Ch3["Ch.3 コア機能詳解<br/>Tab / Agent / Chat / Rules"]
    Ch4["Ch.4 Cursor Rules深掘り<br/>.mdc形式・スコープ・チーム運用"]
    Ch5["Ch.5 コンテキスト管理<br/>@docs / @codebase / MCP"]
    Ch6["Ch.6 Automations・Cloud Agents・Bugbot<br/>常時稼働エージェントの設計"]
    Ch7["Ch.7 ベストプラクティス<br/>Plan Mode・テストファースト・コスト管理"]
    Ch8["Ch.8 アンチパターン<br/>サイレントリバート・コンテキスト汚染"]
    Ch9["Ch.9 エピローグ<br/>Agentic Engineeringを生き抜く（本章）"]

    Ch1 --> Ch2
    Ch1 --> Ch3
    Ch3 --> Ch4
    Ch3 --> Ch5
    Ch3 --> Ch6
    Ch4 --> Ch7
    Ch5 --> Ch7
    Ch6 --> Ch7
    Ch7 --> Ch8
    Ch8 --> Ch9
    Ch2 --> Ch9

    style Ch1 fill:#e8f4f8,stroke:#4a90d9
    style Ch9 fill:#fff3e0,stroke:#f5a623

    subgraph 入門者["入門者（Cursor導入直後）"]
        E1["▶ Ch.1 から読む"]
        E2["▶ Ch.3 でコア機能を理解する"]
        E3["▶ Ch.4 でRulesを設定する"]
    end

    subgraph 中級者["中級者（Agent Modeを使い始めた）"]
        M1["▶ Ch.5 でコンテキスト精度を上げる"]
        M2["▶ Ch.7 でプラクティスを固める"]
        M3["▶ Ch.8 でアンチパターンを潰す"]
    end

    subgraph 上級者["上級者（チーム展開・自動化を検討中）"]
        A1["▶ Ch.6 でCloud Agentsを設計する"]
        A2["▶ Ch.2 で最新機能をキャッチアップする"]
        A3["▶ Ch.9 で方向性を俯瞰する"]
    end

各章のキーテイクアウェイを以下の表にまとめる。

章タイトルキーテイクアウェイ
Ch.1プロローグCursorはVS Code拡張ではなくフォーク。AI-firstの設計が全ての差異を生む
Ch.22026年新機能Composer 2・Bugbot GA・AutomationsでCursorは「エディタ」を超えた
Ch.3コア機能詳解Tab/Agent/Chat/Rulesの4本柱は独立していない。連携させて初めて威力が出る
Ch.4Cursor Rules深掘り.mdc形式でスコープを絞る。書きすぎず、チームでバージョン管理する
Ch.5コンテキスト管理コンテキストの質がAI出力の質を決める。@docsと@codebaseを積極活用する
Ch.6Automations・Cloud Agents常時稼働エージェントの設計は「何を自動化し何を人間が持つか」の設計だ
Ch.7ベストプラクティスPlan Mode先行・テストファースト・コスト可視化の3点セットが基本姿勢
Ch.8アンチパターンサイレントリバートとコンテキスト汚染はCursorを使い込むほど踏みやすい
Ch.9エピローグAgentic Engineeringは「雰囲気」ではなく「設計」だ

おわりに

このシリーズを書き終えて感じることがある。Cursor というツールは、使えば使うほど「自分がどれだけ考えているか」が可視化されるツールだということだ。

指示が曖昧なままエージェントに投げると、曖昧な成果物が返ってくる。設計の意図を言語化できていない状態でAgent Modeを走らせると、AIは勝手に「合理的」な実装を選ぶ。テストも仕様もなく「いい感じにして」と頼めば、AIは何かを作るが、それが正しいかどうかを判断する術がない。

逆に、自分の意図が明確なとき、Cursorは驚くほど強力なパートナーになる。「このインターフェースをこう変えたい、この制約を守って、このテストをパスしながら」という指示に対して、エージェントは忠実かつ高速に動く。AIの能力を引き出しているのは、人間の思考の質だ。

Agentic Engineering の時代において、エンジニアに問われているのはコードを書く速度でも、AIプロンプトのテクニックでもない。何を作るべきかを問い続ける力、作られたものを正しく判断する力、そしてその責任を引き受ける意志だ。

エージェントはいくらでも速く動く。2026年のエンジニアの本当の仕事は、その速さを正しい方向に向け続けることにある。

このシリーズが、あなたの Agentic Engineering の出発点になれば幸いです。