プロンプトからエージェントへ：AI駆動開発を加速させる「エージェントエンジニアリング」への転換

プロンプトからエージェントへ：AI駆動開発を加速させる「エージェントエンジニアリング」への転換

TL;DR — プロンプトを磨く時代は終わり、AIに「ゴール・道具・権限」を渡して自律的に動かすエージェントエンジニアリングが主流になった。設計の軸は Context（知識環境）・Capability（実行能力）・Critical Thinking（自己修正） の3つ。まずは小さな自律ループから始めよう。

AIツール（ChatGPT, Gemini, Claude, Cursor）が登場した当初、私たちの関心は「いかに完璧なプロンプトを書くか」にありました。いわゆる「プロンプトエンジニアリング」の時代です。しかし、2026年の現在、開発の最前線ではすでに次のパラダイムシフトが起きています。

それは、「プロンプトエンジニアリング」から「エージェントエンジニアリング」への転換です。このパラダイムシフトの背景と、実践に移すための思考法についてはプロンプトからエージェントエンジニアリングへの転換でも詳しく解説しています。

2026 年中頃の業界状況として、Claude Code 公式 docs では Hooks / Subagents / Skills の 3 拡張レイヤーが標準提供され[公式値]、OpenAI Codex CLI 公式 も MultiAgentV2 の sub-agent 並列実行を正式サポート[公式値]、GitHub Copilot coding agent も Self-Review と Security Scanning を内蔵化しました[公式値]。本記事の主張する「Context / Capability / Critical Thinking」の 3 要素は、これら最新ツールの設計思想と整合しています。

1. 「出す」プロンプトから「任せる」エージェントへ

プロンプトエンジニアリングは、AIに対して「何をすべきか」を詳細に、かつ一撃で説明する手法です。しかし、どれほどプロンプトを工夫しても、人間がすべてのステップを手動で指示し、出力を確認し、次のプロンプトを打つというプロセス（Human-in-the-loop）がボトルネックになります。

一方、エージェントエンジニアリングは、AIに**「ゴール」と「道具（ツール）」と「権限」**を与え、目的達成まで自律的に試行錯誤させるワークフローを設計することを指します。もはや人間は「命令者」ではなく、エージェントが円滑に動くための環境を整える「オーケストレーター」となります。

両者の違いを整理すると、次のようになります。

2. エージェントエンジニアリングの3要素

優れたエージェントワークフローを構築するためには、以下の3つの要素を設計する必要があります。

① Context（知識と環境の接続）

エージェントが判断を下すために必要な「背景情報」をいかに過不足なく与えるかです。

• リポジトリのルール: .claudecodeignore や CLAUDE.md による制約。CLAUDE.md / AGENTS.md / Skill の役割分担は CLAUDE.md 最適化と Skill との分担 を参照
• ドメイン知識: 過去の設計書やドキュメントとの動的な接続。仕様駆動開発の落とし穴は 仕様駆動開発の落とし穴と対策 で扱う
• 現在のステート: エージェントが現在どのタスクを処理中で、何が未完了かを把握する仕組み（task.md 等）。観測基盤の設計は AIエージェントの可観測性と障害解析 を参照

② Capability（実行可能な能力の定義）

エージェントが「何ができるか」をツール（Skill）として定義することです。具体的なスキル定義ファイルの書き方は「スキル定義ファイル」でプロンプトを再利用可能な資産にする方法を参照してください。Skill と Subagent の使い分け基準は Skills対Subagents使い分け5軸 で整理しています。

• ファイル操作: コードを読み書きする能力
• ターミナル実行: テストを走らせ、エラーを確認する能力。Hook による deterministic 制御は Claude Code hooks の実践パターン集 を参照
• Web検索/ブラウザ操作: 最新情報を取得し、外部サービスを操作する能力
• MCP 経由の外部ツール接続: tool 粒度の決め方と権限設計は MCPサーバー設計パターン集 と MCP権限設計の判断軸 で扱う
• Responses API / Tool Use: ツール呼び出しの API 設計判断は Responses API 時代のツール呼び出し設計 を参照

これらの能力を「一塊のスキル」としてパッケージ化することで、エージェントの行動範囲が明確になります。承認ゲートを Hook で強制する運用例は PlanGate v8.6 Hook Enforcement を参照してください。

③ Critical Thinking（自己修正とループ）

失敗を前提とし、自ら軌道修正するロジックを組み込むことです。このループ設計の詳細はSkillとToolを結合して「勝手に仕事を見つける」自律エージェントを作るで掘り下げています。

• テスト駆動: コードを書いた後に自動でテストを回し、失敗したら自分で修正するループ。durable workflow による安定化は agent loop を durable workflow で安定化する実装 を参照
• セルフレビュー: 書き終えた成果物を、別の視点（Reviewer役割）から検証するステップ。GitHub Copilot coding agent の Self-Review もこの思想で実装されています[公式値]
• プランニング: 実行前に手順を構成し、人間と合意形成するプロセス。レビュー運用設計は AI時代のレビュー運用設計 を参照

典型的な自律ループのフローは次のとおりです。

Plan → Execute → Test → (失敗?) → Self-Fix → Re-Test → Review → Done

エラーハンドリングと観測指標は別軸で必須です。retry / idempotency / circuit breaker の実装パターンは エラーハンドリング設計ガイド を、長時間運用時の疲弊回避は オンコール疲弊を防ぐ運用設計 を参照してください。

3. 実戦：小さなタスクからエージェントに委ねる方法

いきなり大規模な開発をすべて任せるのは困難です。まずは以下のような「小さな自律ループ」から設計を始めましょう。

1. ブログ記事のSEO最適化: 記事を読み込み、SEOタイトルを生成し、フロントマターを書き換える
2. Lintエラーの自動修正: 静的解析ツールを走らせ、指摘された箇所を自動で修正し、再度検証する
3. ドキュメントの相互参照チェック: 仕様書とコードの不整合を見つけ、修正提案を行う

これらを「単なるプロンプト」ではなく、一連の**スキル（Skill）**として定義し、ボタン一つ（あるいは自動トリガー）で完走するように設計するのがエージェントエンジニアリングの第一歩です。

4. 未来のエンジニア像：エージェントのオーケストレーター

これからのエンジニアに求められるのは、優れたコードを自ら書く力以上に、「24時間365日、高品質なコードを書き続けるエージェントチーム」をマネジメントする能力です。

コードを書く作業はエージェントに委ねられ、人間はアーキテクチャの戦略、品質の最終定義、そしてエージェント同士の「通信プロトコル（意思疎通）」の設計に注力することになります。複数エージェントの役割分担や権限設計の実践パターンはAIをチームメンバーとして働かせる運用プレイブックにまとめています。

サブエージェントの粒度や責務分離をどう設計するかについてはClaude Code subagents の実運用パターンも参考になります。

まとめ：今日から始めるエージェントとのチーム開発

「プロンプトエンジニアリング」がAIとの会話の基礎だとすれば、「エージェントエンジニアリング」はAIと共に生きるためのインフラ設計です。

まずは、あなたのリポジトリに CLAUDE.md や task.md を作成し、エージェントが「自ら次の一歩を考えられる環境」を作ってみてください。一撃の魔法の言葉を探すのをやめ、自走する仕組みを設計し始めた瞬間、あなたの生産性は劇的な変化を遂げるはずです。

次に読む記事

• プロンプトからエージェントエンジニアリングへの転換（思考編）
• スキル定義ファイルでプロンプトを再利用可能な資産にする
• SkillとToolで自律ループを構築する
• マルチエージェント・デザインパターンの実践
• Claude Code subagents の粒度設計と責務分離
• AIをチームメンバーとして働かせる運用プレイブック
• Skills対Subagents使い分け5軸
• Claude Code hooks の実践パターン集
• PlanGate v8.6 Hook Enforcement
• 仕様駆動開発の落とし穴と対策
• AIコーディング組織展開の段階設計

FAQ

Q1. プロンプトエンジニアリングとエージェントエンジニアリングは別物ですか？

別物ではなく、前者を内包する上位概念です。優れたエージェントワークフロー設計でも、エージェント内部のプロンプトは依然として重要ですが、ボトルネックがプロンプト品質から「Context / Capability / Critical Thinking の設計品質」に移った、というのが本記事の主張です（経験則）。

Q2. Claude Code / OpenAI Codex CLI / GitHub Copilot のうち、エージェントエンジニアリングに最適なツールは？

単一最適解はなく、役割分担が現実解です。Claude Code は Hooks / Subagents / Skills の再利用性で長期運用に強く[公式値]、OpenAI Codex CLI は MultiAgentV2 で並列タスクに強く[公式値]、GitHub Copilot coding agent は Issue → PR の閉ループで組織運用に強い[公式値]、というのが 2026-05 時点の傾向です。詳細は 2026年の AIコーディング自動運転最前線 を参照。

Q3. 「小さな自律ループ」から始めるとは、具体的にどのくらいの粒度ですか？

実務目安として 「1 タスク 5〜30 分で完走するループ」 が現実解（経験則）。SEO 最適化、Lint エラー修正、ドキュメント整合性チェック等、確実に検証可能なタスクを選びます。詳細は SkillとToolで自律ループを構築する を参照。

Q4. エージェントの暴走や事故をどう防ぎますか？

Hook による deterministic な制御 + 権限境界（MCP / OAuth）+ 観測（agent-observability）の 3 層で防ぎます。具体的な実装パターンは Claude Code hooks の実践パターン集、権限設計は MCP権限設計の判断軸、承認境界の強制は PlanGate v8.6 を参照[公式値]。

Q5. 組織全体に展開する手順は？

Skills（最初）→ Hooks（次）→ Subagents（最後） の順で段階導入するのが現実解です（経験則）。組織展開の具体的な段階設計は AIコーディング組織展開の段階設計 を参照してください。

References

• Claude Code 公式 docs — Hooks / Subagents / Skills の 3 拡張レイヤー
• Claude Code Subagents 公式 — Subagents の定義と運用
• OpenAI Codex CLI 公式 — MultiAgentV2 の正式仕様
• OpenAI Codex Subagents 公式 — Sub-agent 並列実行
• GitHub Copilot coding agent 公式 — Self-Review / Security Scanning
• Anthropic Tool Use 公式 — Tool Use の API 仕様
• OpenAI Responses API Reference — Responses API
• MCP 仕様 — Model Context Protocol の標準