AIを使い始めた頃から、自分ではずっと「プロンプトを工夫している」くらいの感覚でした。
ところが最近、Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineeringという言葉をまとめて知って、自分の使い方を振り返ってみると少し驚きました。
いつの間にか、かなり違うところまで来ていたからです。
ただし最初に一つだけ整理しておくと、この4つが業界で正式に「第1世代→第2世代→第3世代→第4世代」と置き換わったわけではありません。互いに重なる部分もありますし、Prompt Engineeringが不要になったわけでもありません。
むしろ、AIに何を任せるかが広がるにつれて、設計する対象が一段ずつ外側へ広がってきた、と考えるとわかりやすいと思います。
4つを一言で整理すると
| 考え方 | 自分なりの理解 |
|---|---|
| Prompt Engineering | どう言えば、うまく答えるか |
| Context Engineering | 何を知った状態で考えさせるか |
| Harness Engineering | 何を見て、何を使い、どこまで実行できるようにするか |
| Loop Engineering | 次の仕事をどう見つけ、実行し、評価し、また次へ進ませるか |
そして、自分の場合はこの間にVaultという外部記憶が入っています。
これがかなり重要でした。
最初はPrompt Engineeringだった
AIを使い始めた頃は、まさにPrompt Engineeringでした。
「この聞き方では曖昧だから、条件を足そう」
「役割を指定した方がいい」
「出力形式を決めよう」
「一度に全部聞かず、分解して聞こう」
要するに、入力する文章をどう書けば、より良い答えが返ってくるかを考えていました。
これは今でも重要です。プロンプトが雑なら、どれだけ周囲の仕組みが良くても意図は伝わりません。
ただ、AIを長く使うようになると、だんだん別の不満が出てきました。
「毎回、前提を説明するのが面倒だ」
「この案件では以前こう判断したことを知っていてほしい」
「この資料を基準に考えてほしい」
「過去の会話も含めて判断してほしい」
ここから、実際に自分がやっていたことはPrompt Engineeringだけではなくなっていました。
気づけばContext Engineeringをしていた
AnthropicはContext Engineeringを、Prompt Engineeringの自然な発展として説明しています。単に指示文を書くのではなく、システム指示、ツール、MCP、外部データ、会話履歴などを含めて、その時モデルに何を見せるかを設計する考え方です。
参考：Anthropic – Effective context engineering for AI agents
Sourcegraphも、Prompt EngineeringとContext Engineeringは対立するものではなく、異なる層の設計だと整理しています。
参考：Sourcegraph – Context Engineering: A Practical Guide for AI Agents
振り返ると、自分のChatGPTの使い方はかなり前からこちらに寄っていました。
仕事の案件ごとに、背景、これまでの判断、相手とのやり取り、技術条件、見積条件などを積み重ねる。ブログ運営なら、媒体ごとの方針、過去記事、SNSの使い分けを前提にする。
重要なのは「どんな文章で命令するか」だけではなく、AIが判断する瞬間に、必要な情報がちゃんとそこにあるかになっていました。
それでも物足りなくなって、サーバーにつないだ
次に出てきた不満は、もっと単純でした。
答えるだけじゃなく、やってほしい。
ファイルを読んでほしい。
保存してほしい。
コードを動かしてほしい。
テストしてほしい。
WordPressへ下書きを作ってほしい。
SNS投稿までつなげたい。
そこでVPSを立て、MCPを使ってChatGPTから自分のサーバーや各種システムへ接続するようになりました。
この経緯は以前の記事にもまとめています。
→ ChatGPTに自分のサーバーをつないだら、AIの使い方が変わった
ここまで来ると、考えているのは「どう答えさせるか」ではありません。
AIにどんな環境を与え、何を見せ、何を実行させ、どこで止めるかです。
これはHarness Engineeringの考え方にかなり近い。
OpenAIが2026年2月に公開したHarness Engineeringの記事では、AIエージェントを使った開発で、人間の役割がコードを書くことから、環境を設計し、意図を明確にし、エージェントが信頼できる仕事をするためのフィードバックループを構築することへ移ったと説明されています。
参考：OpenAI – ハーネスエンジニアリング：エージェントファーストの世界におけるCodexの活用
この文章を読んだとき、自分がサーバー接続後にやっていたこととかなり重なって見えました。
AIそのものを改造できるわけではない。
だから、その外側を作る。
- どのツールへ接続できるか
- どのディレクトリを触れるか
- 何を実行できるか
- どこまで自動で進めるか
- テストをどう行うか
- 失敗したとき何を残すか
この周囲の設計が、AIの実用性を大きく左右するようになりました。
Vaultを作ったら、AIだけでなく自分の認知も拡張された
そして、その次に作ったのがVaultでした。
会話が終われば消えてしまう情報を、Markdownなどの形で外に残す。案件、判断、失敗、技術メモ、アイデア、記事、投資ルールなどを蓄積し、あとからAIが検索して使えるようにする。
これは技術的には「外部記憶」「永続状態」に近い役割を持っています。
Anthropicも、長時間動くエージェントでは、コンテキストウィンドウの外へノートを保存し、必要になったときに読み戻すstructured note-taking / agentic memoryを重要な手法として挙げています。
でも、自分にとってVaultの効果はAI側だけではありませんでした。
自分自身の認知も拡張された。
以前なら、その場で考えて終わっていたことが残る。
別の日の考えとつながる。
「あの話と、この話は同じ構造では？」と気づける。
今回もまさにそうでした。
AIに外部記憶を持たせるためにVaultを作った結果、そのVaultを使っている自分自身が、AI活用の構造を理解しやすくなった。
そして、次の疑問が出てきました。
「ここまで記憶できて、実行もできるなら、毎回自分が指示しなくても回せるのでは？」
そこでLoop Engineeringに気づいた
Addy Osmaniは2026年6月の記事で、Loop Engineeringを、ざっくり言えば自分が毎回エージェントをプロンプトする代わりに、エージェントをプロンプトする仕組みを設計することとして紹介しています。
参考：Addy Osmani – Loop Engineering
彼の整理では、ループは仕事を見つけ、配り、チェックし、何が終わったかを記録し、次に何をするかを決めていきます。そして、そのループを成立させる要素として、Automation、Skills、Connectors、Sub-agentsなどに加えて、会話の外に残るMemoryが挙げられています。
このMemoryの部分を読んで、Vaultの位置づけが一気にはっきりしました。
Vaultは単なる「AI用のメモ帳」ではない。
ループが前回の状態を引き継ぐための基盤になり得る。
たとえば、こんな流れです。
Vaultから未解決課題を読む
↓
AIが次にやる作業を決める
↓
MCP経由で実行する
↓
テスト・評価する
↓
結果と失敗理由をVaultへ残す
↓
その結果を読んで次の作業を決める
↺ここまで閉じれば、人間が毎ターン「次はこれをやって」と指示する必要がかなり減ります。
一足飛びに来たようで、実は一段ずつだった
振り返ると、最初からこういう設計思想を知っていたわけではありません。
むしろ逆でした。
もっと良い答えがほしい。
→ プロンプトを工夫した。
毎回説明したくない。もっと自分の状況を知っていてほしい。
→ コンテキストを積み重ねた。
答えるだけじゃなく、実際に作業してほしい。
→ サーバーを立てて、MCPで外部システムにつないだ。
会話が終わっても知識を失いたくない。
→ Vaultを作った。
記憶も実行環境もあるなら、自分で改善を回せないか。
→ Loop Engineeringに興味を持った。
一足飛びに最前線へ来たような気分になっていましたが、実際にはそうではありませんでした。
一つ前の段階で感じた不満を、一つずつ潰してきただけだった。
その結果、後から名前を知った技術概念と、自分が作ってきたものがつながった。
これはかなり面白い経験です。
今はまだ「ループ完成」ではない
もちろん、Vaultを作ってサーバーにつないだからといって、Loop Engineeringが完成したわけではありません。
今でも多くの場合、最初の仕事は自分が与えています。
「これを調べて」
「開発を続けて」
「この記事を作って」
と指示して、AIが動く。
今の現在地を正確に言うなら、Harnessと外部Memoryがかなり整い、Loopを作れる条件が揃ってきた段階だと思います。
次にやるべきことはかなり明確です。
AIが自分で、
- 状態を読む
- 未解決課題を見つける
- 次の行動を決める
- 実行する
- 別の仕組みで評価する
- 結果を記録する
- 次のサイクルへ進む
この閉じたループを、どこまで安全に、汎用的に作れるか。
自分が今作ろうとしているのは、おそらくそこです。
「AIに何を聞くか」から「AIが働く仕組みをどう作るか」へ
Prompt Engineeringを知ったときは、AI活用とは「上手な質問の仕方」だと思っていました。
今はかなり違います。
質問の文章だけでなく、知識、記憶、道具、権限、実行環境、評価方法、フィードバック、継続性まで含めて考えるようになりました。
つまり関心が、
AIをどう使うか
から、
AIが継続的に働けるシステムをどう設計するか
へ移っている。
先にこの世界を進んでいる人たちから見れば、まだ入口だと思います。
でも、用語を知らないまま必要に迫られて一段ずつ進み、後から地図を見つけた感覚があります。
地図が見えたなら、ここからはもっと速く進めるはずです。
今はそれがかなり面白い。
コメント