[生成AI] AIエンジニアリング4つのパラダイム — Prompt, Context, Agentic, Harness

概要

最近Claude Codeで作業をしていると、「プロンプトをうまく書くだけ」では足りないと感じることが多くなりました。同じ指示でも、一緒にどんな情報を渡すかで結果が変わりますし、エージェントの構成の仕方で作業の品質が大きく違ってきます。

こうした経験を整理していくうちに、AIを効果的に活用するにはプロンプト以外にも気を配るべき領域がかなりあることに気づきました。この記事では、実務で感じたことをもとに、AIエンジニアリングを4つのパラダイムに分けて整理してみました。

パラダイム	一言まとめ
Prompt Engineering	AIへの伝え方を磨くこと
Context Engineering	AIに見せる情報を選ぶこと
Agentic Engineering	AIがツールを使って自ら動くようにすること
Harness Engineering	AIが動く環境（権限、安全装置）を整えること

1. Prompt Engineering —「どう伝えるか」

最もよく聞く概念でしょう。AIに渡す指示文（プロンプト）をどう書くかで結果が大きく変わります。

同じ質問でも聞き方次第で答えが変わる経験、皆さんもあるのではないでしょうか。「コードレビューして」より「シニア開発者の観点で、セキュリティの問題を中心にレビューして」と言った方が、ずっと具体的なフィードバックが得られます。

よく使われる技法

Few-shot: 「こんな感じでやって」と例をいくつか見せる方法です。パターンを直接見せると、AIが意図をより正確に把握します。
Chain-of-Thought: 「ステップバイステップで考えてください」とお願いすると、AIが推論過程を経て、より正確な答えを出してくれます。
Role Prompting: 「あなたは10年経験のバックエンドエンジニアです」のように役割を与えると、その視点に合った回答が得られます。
出力形式の指定: 「JSONで回答してください」「Markdownテーブルで整理してください」のように、出力形式を事前に決めておくと後処理が楽になります。

実務ではこんな風に使います

範囲を制限すると、AIが不要な内容をたくさん出してしまうのを防げます。

要件のWhatとWhyのみを分析してください。
How（技術的な実装）は議論しないでください。

出力形式を事前に決めておくと、結果をそのまま使えて便利です。

以下の形式のテーブルで回答してください：
| 機能 | 説明 | 優先度 |

でもプロンプトだけでは限界があります

どれだけプロンプトを上手に書いても、AIに外部データを取得させたり、ツールを直接使わせたりすることはできません。「うまく聞くこと」と「仕事を任せること」は次元の違う話です。この限界を超えるために、次のパラダイムが必要になります。

2. Context Engineering —「何を見せるか」

まったく同じ質問をしても、AIにどんな情報を一緒に見せるかで結果がガラリと変わります。これを体系的に設計するのがContext Engineeringです。

たとえて言えば、プロンプトが「この問題を解いて」という質問だとすると、コンテキストは試験用紙の横に置く参考資料です。教科書を開きながら解くのと、何もなしで解くのでは結果が違いますよね。

ポイントは「必要な情報だけを選んで入れること」

LLMのコンテキストウィンドウは無限ではありません。情報を入れすぎると重要な内容が埋もれてコストも上がります。逆に少なすぎるとAIが十分な判断を下せません。

実務でよくある間違いと改善

APIレスポンス全体をそのままコンテキストに入れてしまうのは、よくある間違いです。必要なフィールドだけ抽出するだけで、結果の品質がかなり良くなります。

# これだと不要なデータまで全部入ってしまいます
curl -s https://api.example.com/comments | jq '.[].body'

# こうやって必要なものだけ選べば、ずっと効率的です
curl -s https://api.example.com/comments \
  | jq '.[] | select(.tag == "review") | .body'

指示文も同じです。一つの巨大なファイルにすべてのルールを入れるより、状況に応じて必要な部分だけロードする方が良いです。

# これだと毎回500行が全部コンテキストに載ります
instructions.md（500行）

# こう分けると必要なモジュールだけ載ります
router.md（50行） → 状況に合ったmodule.mdだけ追加ロード

Claude Codeをお使いでしたら、CLAUDE.mdをプロジェクトルートに一つだけ置くのではなく、サブディレクトリごとに分けて管理するのが良い例です。フロントエンドのコードを修正するときにバックエンドのルールまでロードする必要はないですよね。

それでも越えられない壁

情報をどれだけうまく選んで入れても、AIが自分からファイルを開いたり、APIを呼んだり、コードを実行したりすることはできません。Context EngineeringはAIの判断材料を最適化しますが、判断後の実行までは設計しません。

3. Agentic Engineering —「自分でやらせるか」

ここまで、プロンプト（どう伝えるか）とコンテキスト（何を見せるか）を扱ってきました。どちらもAIの**「入力」を最適化するものでした。Agentic Engineeringはここからさらに一歩進んで、AIがツールを使って自ら動くようにする**ことです。

簡単に言えば、AIに答えを求めるのではなく、仕事を任せるということです。「このコードをリファクタリングして」と言えば、AIがファイルを読み、修正し、テストを実行して、結果を報告してくれるわけです。

どんなことが可能になるか

Tool Use: AIがターミナルコマンドを実行したり、ファイルを読み書きしたり、APIを呼び出したりします。
Multi-Agent: コードを探索するエージェント、レビューするエージェント、実装するエージェントに役割を分担します。
計画してから実行: 複雑なタスクを一度に投げるのではなく、まず計画を立てさせて確認してから実行します。
自己修正: AIが結果を自ら検証し、問題があれば修正するプロセスを繰り返します。

実務で特に効果的なパターン

タスクの特性に応じて異なるモデルを使うと、コストと品質を両立できます。

探索エージェント: コードベースを素早く調査して構造を把握
  → Sonnet（速くて安価なモデルで十分）

レビューエージェント: 成果物を丁寧に検証して欠陥を見つける
  → Opus（批判的思考が必要なタスクに適している）

成果物の品質が重要な場合は、一発で終わらせようとせず反復検証ループを作るのも良いです。

最大3ラウンド繰り返し：
  1. タスク実行
  2. 自己レビューまたは別エージェントによるレビュー
  3. 合格なら終了、不合格なら修正して次のラウンドへ

Claude CodeでAgentツールでサブエージェントを作ったり、/planモードで先に計画を立ててから実行するのが、このパラダイムに該当します。

自律性が高まるほど必要になるもの

エージェントが勝手にファイルを修正してコマンドを実行するようになると、自然と**「これ、やっていいのか？」**という疑問が湧いてきます。重要なファイルを誤って削除したり、意図しないコマンドを実行してしまう問題が起きる可能性があります。この問題を解決するために、最後のパラダイムが必要です。

4. Harness Engineering —「どこでやらせるか」

Harnessはもともと馬の力を安全に制御する馬具を意味します。AIも同じで、強力な能力を持っていますが、適切な制御装置なしに放っておくと予期しない問題が起きることがあります。

Harness Engineeringは、AIが働く部屋のルールを決めることです。どのツールを使えるか、どのファイルにアクセスできるか、危険な操作の前にどんな検証を通る必要があるかを、事前に設定しておきます。

実務ですぐ使える設定

最小権限の原則: AIが必要なことだけをできるように制限します。読み取りは許可しつつ、削除や管理者コマンドはブロックする形です。

{
  "permissions": {
    "allow": ["Bash(ls:*)", "Bash(cat:*)", "Read(/src/**)"],
    "deny": ["Bash(rm:*)", "Bash(sudo:*)"]
  }
}

Hooksで自動検証を挟み込む: AIがコードをコミットしようとしたとき、自動的にリントを走らせることができます。人が毎回チェックしなくても、一定水準の品質が保証されます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit:*)",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint"
          }
        ]
      }
    ]
  }
}

Claude Codeをお使いでしたら、settings.jsonで権限を設定し、Hooksで検証パイプラインを構築するのがまさにHarness Engineeringです。

Hooksの具体的な設定方法はClaude Codeとterminal-notifierで作業完了通知を受け取るで詳しく紹介しています。

環境だけでは足りません

どれだけ安全な部屋を作っても、中で働くAIがおかしな指示を受けたり、間違った情報を見ていたりすれば、良い結果は期待できません。良い環境は、良いプロンプト、良いコンテキスト、良いエージェント設計と組み合わさって初めてその役割を果たします。

一目で比較

観点	Prompt	Context	Agentic	Harness
何を扱うか	指示文	情報	行動	環境
たとえ	「これをやれ」	「これを見てやれ」	「このツールで自分でやれ」	「この部屋でやれ」
核となる活動	指示を明確に	情報を選んで	ツールとエージェントを	権限と安全装置を
成果物	プロンプトテキスト	データパイプライン	エージェント構造	設定ファイル、Hooks
Claude Code	明確な指示作成	CLAUDE.mdのモジュール化	Agentツール、/plan	settings.json、Hooks

4つのパラダイムの関係

この4つはバラバラに存在するのではなく、重なり合ったレイヤー構造を成しています。

┌─────────────────────────────────────────┐
│  Harness Engineering（実行環境）          │
│  ┌───────────────────────────────────┐  │
│  │  Agentic Engineering（行動設計）    │  │
│  │  ┌─────────────────────────────┐  │  │
│  │  │  Context Engineering（情報）  │  │  │
│  │  │  ┌───────────────────────┐  │  │  │
│  │  │  │  Prompt Engineering   │  │  │  │
│  │  │  │ （指示）               │  │  │  │
│  │  │  └───────────────────────┘  │  │  │
│  │  └─────────────────────────────┘  │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

一番内側から見ていくと：

PromptはContextの一部です。プロンプトも結局はコンテキストウィンドウに入るテキストですから。
ContextはAgentが参考にする材料です。エージェントはコンテキストにある情報を見て判断し、行動します。
AgentはHarnessの中で実行されます。どれだけ優秀なエージェントでも、環境が許可しないことはできません。

外側のレイヤーが内側のレイヤーの効果を増幅させます。逆に、どれか一つのレイヤーが不十分だと、他のレイヤーがどれだけ良くても全体の結果が落ちます。プロンプトをどんなにうまく書いてもコンテキストに的外れな情報が入っていれば意味がないですし、エージェントをうまく設計しても実行環境の権限が足りなければ作業を完了できません。

結局、4つをバランスよく意識することがAIを最もうまく活用する方法だと思っています。