最近「〇〇エンジニアリング」という言葉が増えました。
プロンプトエンジニアリング。コンテキストエンジニアリング。ハーネスエンジニアリング。ループエンジニアリング。
新しい言葉が出るたびに「また覚えることが増えた」と思っていました。
でも調べてみたら、これらはバラバラの手法ではなく、入れ子になった4つの層でした。しかも順番に学べばいい構造になっている。
この記事では、その4層をできるだけ噛み砕いて説明します。後半では、実際に自分がどう組み立てているかも並べます。
結論：4つは入れ子になっている
先に全体像です。
外側にいくほど、AIに任せる範囲が広がります。
| 段階 | 何を設計するか | ひとことで |
|---|---|---|
| ① プロンプト | 1回の指示の書き方 | なんて言うか |
| ② コンテキスト | AIに渡す情報 | 何を知らせるか |
| ③ ハーネス | 使える道具と、守らせる枠 | 何をさせるか / させないか |
| ④ ループ | 繰り返しの回し方 | どう回し続けるか |
新しいものが古いものを置き換えるわけではありません。外側を作るには、内側も要る。
① プロンプト ── なんて言うか
一番内側。ChatGPT や Claude に打ち込む、あの指示文です。
NG: いい感じにコードを書いて
OK: このエラーの原因を3つ挙げて、それぞれの確認方法も書いて
ここは多くの人が既にやっているところだと思います。具体的に書く、役割を与える、出力形式を指定するあたりが定番です。
ただ、プロンプトだけで頑張ろうとすると限界が来ます。AIが前提を知らないからです。
② コンテキスト ── 何を知らせるか
「このプロジェクトは Node 18 では動かない」
これをAIが知らなければ、どれだけ丁寧にプロンプトを書いても、Node 18 前提のコードが返ってきます。
コンテキストエンジニアリングは、AIに渡す情報を設計することです。
- プロジェクトのルールをファイルに書いておく（
CLAUDE.mdやAGENTS.md） - 関連するコードだけを渡す（全部渡すと逆に精度が落ちます）
- 過去のやりとりを覚えさせる
ポイントは、「全部渡す」が正解ではないこと。情報が多すぎると、大事な指示が埋もれます。過不足なく渡すのが設計です。
③ ハーネス ── 何をさせるか、させないか
ハーネス（harness）は「馬具」「安全帯」のことです。
AIに手足を与えつつ、危ないことをさせない枠を作る層だと考えてください。
手足を与える
- ファイルを読み書きさせる
- コマンドを実行させる
- 検索させる
枠をはめる
- 本番環境には触らせない
- テストが通らなければ次に進ませない
- 危ない操作は人間の承認を挟む
ここで大事なのは、枠を「お願い」で作らないことです。
プロンプトに「本番DBは触らないで」と書いても、守られる保証はありません。そもそも権限を渡さない、アクセスできないようにしておく。そういう仕組みで縛るのがハーネスです。
④ ループ ── どう回し続けるか
一番外側。AIが1回答えて終わり、ではなく、繰り返し回る仕組みを設計する層です。
たとえば「テストを書いて → 実行して → 失敗したら直して → また実行する」。この繰り返しをAIに自分で回させる。人間は毎回指示しません。
ここで登場するのが HITL と HOTL です。名前は似ていますが、役割が違います。
| 読み方 | 人間の位置 | 実際の動き | |
|---|---|---|---|
| HITL | Human in the Loop | ループの中 | AIが止まって承認を待つ。人が OK を出すまで進まない |
| HOTL | Human on the Loop | ループの外 | AIは自分で進む。人は監視して、おかしければ止める |
HITL は確実ですが、人間が待ち構えている必要があります。HOTL は速いですが、止めるボタンと、異常に気づく仕組みが要ります。
全部を HITL にすると人間が疲弊します。どこを止めて、どこを任せるかの線引きそのものが設計対象です。
ループは1つじゃない
もう一つ大事なのが、ループは時間の違う入れ子になっているという点です。
| 周期 | 誰が回すか | やること |
|---|---|---|
| 数分 | AI | 実装して、自分でテストして、直す |
| 数十分 | 人間 | 方向がズレていないか見て、直す |
| 数時間〜数週間 | 人間 | 実際の反応を見て、作るもの自体を見直す |
内側の「数分ループ」はAIに任せられます。でも外側のループは人間が回す。
「AIに丸投げしたら変なものができた」というのは、たいてい外側のループを誰も回していないときに起きます。
実際にどう組んでいるか
ここからは、自分がやっていることを4層に当てはめてみます。技術記事をQiitaに投稿する作業を、AIと一緒に回している例です。
① プロンプト
普通に指示を書きます。ここは特別なことはしていません。
② コンテキスト
- プロジェクトのルールを
CLAUDE.mdに書く（ただし長くしない。長い指示書は守られないという研究があります） - 記事を書くときは、論文のPDFから本文を抽出して渡す。要約サイトの内容は渡しません（要約は結論が抜けていることがあるため）
③ ハーネス
工程ごとにやることを決めた手順書を用意しています。
| 手順書 | 役割 |
|---|---|
| ネタ収集 | 情報源を巡回して、記事にできるか3軸で採点する |
| 執筆 | 文体ルールと、書いてはいけない表現の一覧 |
| 検証 | 事実確認と、Markdown記法の自動チェック |
| 投稿 | 下書き → 確認 → 公開の手順 |
特に検証は、人間の目視をやめてスクリプトに置き換えました。目で見て2回見落としたからです。
これが「枠をはめる」の実例です。「気をつけて確認する」ではなく、機械が0件と言うまで先に進まない。
④ ループ
- 数分のループ：AIが書く → 検査スクリプトを回す → 引っかかったら直す。ここはAIが自分で回します
- 数十分のループ：出てきた記事を読んで、方向が違えば軸から直す。ここは人間（HITL）
- 週単位のループ：いいね数や閲覧数を見て、次に何を書くか決める。ここも人間
一番効いたのは、数分のループを自動化したことでした。今まで自分がやっていたチェックを、機械が代わりにやってくれます。
逆に、外側のループを自動化しようとは思いません。「何を書くべきか」はAIには決められないからです。
どこから手を付けるか
初心者向けの結論として、順番に上っていくのがよいと思います。
| 今いる場所 | 次にやること |
|---|---|
| プロンプトを書いている | プロジェクトのルールをファイルに書く（②へ） |
| ファイルに書いている | AIに実行させる範囲と、させない範囲を決める（③へ） |
| 範囲を決めている | 繰り返しの一部を自動で回す（④へ） |
いきなり④から始めても、②と③がないと変な方向に高速で走っていくだけになります。
そして④まで行くと、人間の役割が変わります。
「AIに何て言うか」を考える人から、「AIがどう回るか」を設計して見張る人へ。
これがこの4層を通しての一番の変化だと思います。
まとめ
- 「〇〇エンジニアリング」は別々の手法ではなく、入れ子の4層
- ① プロンプト（なんて言うか）→ ② コンテキスト（何を知らせるか）→ ③ ハーネス（何をさせるか）→ ④ ループ（どう回すか）
- 新しいものが古いものを置き換えるのではなく、外側を作るには内側も要る
- ループには HITL（止めて待つ） と HOTL（監視して必要なら止める） がある
- ループ自体も数分・数十分・週単位の入れ子。内側はAIに任せられるが、外側は人間が回す
まずは②から。プロジェクトのルールを1ファイルに書くだけでも、返ってくる答えが変わります。
参考
- 「〇〇エンジニアリング」が増えすぎたので整理してみた — 4層の入れ子構造について、この記事より詳しい整理があります
- Human in the Loop (HITL) vs Human on the Loop (HOTL) — 2つの違いの解説