本記事は筆者個人の理解に基づくまとめです。
この分野は新しい言葉が次々に生まれていて、同じ言葉でも人や企業によって指す範囲が違います。厳密な定義が必要な場合は、各手法の提唱元の情報を確認してください。間違いや補足があれば、コメントで教えていただけると嬉しいです。
はじめに
「プロンプトエンジニアリング」の次は「コンテキストエンジニアリング」、その次は「ハーネスエンジニアリング」。ほかにも「バイブコーディング」「仕様駆動開発」「AIDD」など、AIを使った開発手法の言葉がここ1〜2年で一気に増えました。
正直、筆者自身も「これとこれって何が違うの?」と混乱していたので、自分の頭の整理も兼ねてざっくりまとめてみます。
本記事の整理の仕方
たくさんある手法を、筆者は次の3つの層に分けて捉えています。
| 層 | 問い | 主な手法 |
|---|---|---|
| ① 入力・環境の設計 | AIに 何を渡し、どんな環境で動かすか | プロンプト / コンテキスト / ハーネス / フローエンジニアリング |
| ② 開発の進め方 | AIと どう分担して開発を進めるか | バイブコーディング / エージェンティックコーディング / 仕様駆動開発 / AIDD・AI-DLC / マルチエージェント |
| ③ 品質と継続的な改善 | AIの出力を どう信頼できるものにするか | AI×TDD / 評価駆動開発 / Compound Engineering |
※この分け方自体も筆者の独自整理です。
手法どうしの重なり
それぞれの手法は独立しているわけではなく、かなり重なっています。筆者は次のように捉えています。
- 上段:AIが動く環境は「プロンプト ⊂ コンテキスト ⊂ ハーネス」の入れ子になっていて、ほかの多くの手法はどれかの層を強める工夫だと考えられます。
- 下段:開発の進め方は、どれだけ構造化・統制するかのスペクトラムとして並べられます。右に行くほど、上段の仕組み(仕様・テスト・承認)を多く使うことになります。
① 入力・環境の設計
扱う範囲が「1回の指示」から「AIを取り巻く環境全体」へと広がってきた流れとして見ると、わかりやすいと思っています。
プロンプト ⊂ コンテキスト ⊂ ハーネス
(1回の指示) (渡す情報全体) (動く環境・仕組み全体)
プロンプトエンジニアリング
筆者の理解:AIへの「1回の指示文」の書き方を工夫する技術。
- 役割を与える(「あなたはシニアエンジニアです」)
- 出力形式を指定する(JSON、箇条書きなど)
- 例を見せる(Few-shot)
- 段階的に考えさせる(Chain-of-Thought)
ChatGPTが登場したころから最初に注目された層です。モデルが賢くなるにつれて、細かいテクニックの重要度は下がってきている印象ですが、「やってほしいことを明確に伝える」という基本は今も変わらず大事だと思います。
コンテキストエンジニアリング
筆者の理解:プロンプトだけでなく、AIに渡す「情報全体」を設計する考え方。
AIが参照する情報には、プロンプト以外にもいろいろあります。
- プロジェクトのルールファイル(
CLAUDE.md、AGENTS.mdなど) - 関連するソースコードやドキュメント
- 会話の履歴
- ツールの実行結果(検索結果、テスト結果など)
「必要な情報を、必要な分だけ、適切なタイミングで渡す」ことが肝です。情報を詰め込みすぎると、かえって精度が落ちることもあります。2025年ごろから急に使われるようになった言葉という印象です。
ハーネスエンジニアリング
筆者の理解:AIエージェントが自力で正しく作業を進められるように、周りの「仕組み」を整えること。
ハーネス(harness)は「馬具」の意味で、AIという馬の力を正しい方向に導く道具立て、というイメージで捉えています。
- 使えるツールや権限の設定
- フック(例:ファイル保存のたびに自動でLint・テストを実行)
- テストやCIなど、AIが自分の成果をチェックできる仕組み
- エージェントの実行ループや、サブエージェントの構成
「AIへの指示を頑張る」から一歩進んで、「AIが自分でミスに気づいて直せる環境を作る」方向の考え方だと理解しています。
フローエンジニアリング
筆者の理解:1回の長いプロンプトに頼らず、「生成 → テスト → 修正」のような複数ステップの流れを設計すること。
AlphaCodium の論文で使われた言葉です。ハーネスエンジニアリングとかなり重なる部分があると感じています。
② 開発の進め方
バイブコーディング(Vibe Coding)
筆者の理解:コードをほとんど読まずにAIへ任せ、ノリと雰囲気で作っていくスタイル。
Andrej Karpathy氏が言い出した言葉です。
- 👍 とにかく速い。プロトタイプや個人ツールに向いている
- 👎 中身を把握していないので、保守性やセキュリティに不安が残る
「本番のプロダクトには向かないけど、試作には最強」という立ち位置だと理解しています。
エージェンティックコーディング / Agentic Engineering
筆者の理解:Claude Code や Codex のようなAIエージェントに、計画・実装・テスト・修正までを自律的に任せる開発スタイル。
バイブコーディングとの違いは、人間がちゃんと設計・レビュー・判断の責任を持つところだと捉えています。AIは「手を動かす人」、人間は「方向を決めてレビューする人」という分担です。
仕様駆動開発(SDD: Spec-Driven Development)
筆者の理解:いきなりコードを書かせるのではなく、まずAIと一緒に「仕様書」を作り、それをもとに実装させる手法。
要件定義 → 設計 → タスク分解 → 実装
↑ 各段階で人間がレビュー・承認
AWSの Kiro や GitHub の Spec Kit などが代表的なツールです。「AIは指示があいまいだと好き勝手に作ってしまう」という問題への対策として、とても理にかなっていると感じます。
AIDD(AI駆動開発)/ AI-DLC
筆者の理解:AIを単なる補助ツールではなく「開発の主役」に置き、人間は承認と意思決定に回る開発プロセス全体の考え方。
- AIDD(AI-Driven Development):AIを中心に据えた開発、という広い意味で使われることが多い言葉
- AI-DLC(AI-Driven Development Lifecycle):AWSが提唱している方法論。要件定義から運用まで、ライフサイクル全体をAI主導で回すことを想定している
個々のテクニックというより、チームや組織の開発プロセスをどう変えるかという、一段上の話だと理解しています。
マルチエージェント / 並列エージェント開発
筆者の理解:複数のAIエージェントに役割を分けて(実装役・レビュー役・テスト役など)、並列で作業させる手法。
git worktree で作業場所を分けて、複数のエージェントに別々のタスクを同時に進めさせる使い方がよく紹介されています。人間の役割は、ますます「マネージャー」に近づいていく印象です。
Ralph ループ
筆者の理解:同じプロンプトでエージェントを、タスクが終わるまで何度もループ実行させ続けるシンプルな手法。
仕組みは単純ですが、テストなどの「完了条件」をしっかり用意しておくと驚くほど進む、という点が面白いところです。
③ 品質と継続的な改善
AI × TDD(テスト駆動開発)
筆者の理解:先にテストを書かせて(または人間が書いて)、そのテストが通るように実装させる手法。
AIは「それっぽいけど間違っているコード」を書くことがあるので、正しさを機械的に判定できるテストが、AIを使った開発ではこれまで以上に重要になっていると感じます。ハーネスエンジニアリングとも相性が良いです。
評価駆動開発(Eval-Driven Development)
筆者の理解:LLMを組み込んだ機能を、評価用のデータセット(evals)で点数を測りながら改善していく手法。
LLMの出力は毎回少しずつ変わるので、「なんとなく良くなった気がする」ではなく、数字で比較するための考え方です。どちらかというと、AIを使って作る話より、AIを組み込んだアプリを作るときの話です。
Compound Engineering
筆者の理解:作業のたびに学んだこと(失敗・ルール・コツ)をドキュメントやルールファイルに書き戻して、AIがだんだん賢く動けるようにしていく考え方。
「compound=複利」のとおり、改善が積み重なって効いてくるイメージです。CLAUDE.md やスキルに知見を育てていく運用は、まさにこれだと理解しています。
手法を支える技術キーワード
手法そのものではありませんが、よく一緒に出てくるのでざっくり紹介します。
| キーワード | 筆者の理解 |
|---|---|
| MCP(Model Context Protocol) | AIと外部ツール・データ(GitHub、DB、Slackなど)をつなぐための標準仕様 |
| Agent Skills / カスタムコマンド | よく使う手順やノウハウを、AIが再利用できる形でまとめておく仕組み |
| サブエージェント | 調査やレビューなどの作業を、別のAIエージェントに切り出して任せる仕組み |
| RAG | 検索してきた情報をコンテキストに入れて回答させる手法 |
まとめ
| 層 | 手法 | ひとことで |
|---|---|---|
| ① 入力・環境 | プロンプトエンジニアリング | 指示文を工夫する |
| コンテキストエンジニアリング | 渡す情報全体を設計する | |
| ハーネスエンジニアリング | AIが動く環境・仕組みを整える | |
| フローエンジニアリング | 複数ステップの流れを設計する | |
| ② 進め方 | バイブコーディング | ノリで任せる(試作向き) |
| エージェンティックコーディング | エージェントに任せ、人間は判断する | |
| 仕様駆動開発(SDD) | 先に仕様を固めてから作らせる | |
| AIDD / AI-DLC | 開発プロセス全体をAI中心にする | |
| マルチエージェント | 複数のAIで分担・並列化する | |
| Ralph ループ | 完了までひたすら回す | |
| ③ 品質・改善 | AI × TDD | テストで正しさを担保する |
| 評価駆動開発 | 数字で測って改善する | |
| Compound Engineering | 学びを積み上げてAIを育てる |
こうして並べてみると、どの手法も根っこにあるのは 「AIに丸投げせず、人間がうまく舵取りする仕組みをどう作るか」 という共通の問いだと感じました。
流行り言葉に振り回されず、自分のチームや案件に合うものを組み合わせて試していくのが良さそうです。
参考
① 入力・環境の設計
-
Effective context engineering for AI agents(Anthropic Engineering Blog)
- コンテキストエンジニアリングを、プロンプトエンジニアリングの次の段階として解説した記事
-
Harness engineering: leveraging Codex in an agent-first world(OpenAI, 2026年2月)
- 手書きのコードを一切使わずにプロダクトを開発した事例をもとに、ハーネスエンジニアリングを紹介した記事
-
Harness Engineering - first thoughts(martinfowler.com)
- 上記の OpenAI 記事への考察
-
Code Generation with AlphaCodium: From Prompt Engineering to Flow Engineering(arXiv, 2024年1月)
- フローエンジニアリングという言葉が使われた論文。実装は GitHub で公開されている
② 開発の進め方
-
Andrej Karpathy 氏の X への投稿(2025年2月)
- 「バイブコーディング」という言葉が生まれた投稿
-
Spec-driven development with AI: Get started with a new open source toolkit(GitHub Blog, 2025年9月)
- GitHub Spec Kit の紹介記事
-
Kiro 公式サイト
- 仕様駆動開発を前面に出している AWS のエージェント型 IDE
-
AI-Driven Development Life Cycle: Reimagining Software Engineering(AWS DevOps Blog)
- AI-DLC を紹介した AWS の記事。日本語版もある
-
Ralph Wiggum as a "software engineer"(Geoffrey Huntley, 2025年7月)
- Ralph ループの元になった記事
③ 品質と継続的な改善
-
Compound Engineering: How Every Codes With Agents(Every)
- Plan → Work → Review → Compound のサイクルを紹介した記事
- Compound Engineering ガイド(Every)

