AI活用は「プロンプト」から「ループ」へ。気づけば一段ずつ進んでいた話

AIを使い始めた頃から、自分ではずっと「プロンプトを工夫している」くらいの感覚でした。

ところが最近、Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineeringという言葉をまとめて知って、自分の使い方を振り返ってみると少し驚きました。

いつの間にか、かなり違うところまで来ていたからです。

ただし最初に一つだけ整理しておくと、この4つが業界で正式に「第1世代→第2世代→第3世代→第4世代」と置き換わったわけではありません。互いに重なる部分もありますし、Prompt Engineeringが不要になったわけでもありません。

むしろ、AIに何を任せるかが広がるにつれて、設計する対象が一段ずつ外側へ広がってきた、と考えるとわかりやすいと思います。

4つを一言で整理すると
最初はPrompt Engineeringだった
気づけばContext Engineeringをしていた
それでも物足りなくなって、サーバーにつないだ
Vaultを作ったら、AIだけでなく自分の認知も拡張された
そこでLoop Engineeringに気づいた
一足飛びに来たようで、実は一段ずつだった
当時はまだ「ループ完成」ではなかった
「AIに何を聞くか」から「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の実用性を大きく左右するようになりました。

このHarness側の具体例が、正式連載の第2回「ChatGPTにコードを書かせるだけでは足りなかった。Development MCPを作った」です。コード生成だけでは残っていた人間の中継作業を、権限を限定したDevelopment MCPでどう減らしたかを書いています。

さらに、その実行能力を強くしていく過程では、「何を実行できるか」だけでなく、強い権限をどこに置くかが問題になりました。Docker操作や長時間処理をDevelopment Runnerへ分離し、制御面と実行面を分けた話は第3回「AIに自分自身を再起動させたら止まった。Development Runnerを分離した」で扱っています。

そのうえで、AIが変更を作れることと、その変更を正式採用してよいことも分離しました。@@INLINE0@@ブランチ、Pull Request、expected HEAD、fast-forward onlyなどで「生成」と「確定」の境界を作った話は、@@INLINE1@@にまとめています。

発信側でも同じ考え方を使いました。記事制作のように会話の途中で形が変わる仕事をn8nの固定workflowへ押し込まず、Publishing MCPへ分離。Publication、revision、preview、read-back verificationを持たせ、「作れること」と「公開してよいこと」を分けた経緯は、第5回「記事を書くだけでは自動化にならなかった。Publishing MCPを作った」にまとめています。

Vaultを作ったら、AIだけでなく自分の認知も拡張された

そして、その次に作ったのがVaultでした。

会話が終われば消えてしまう情報を、Markdownなどの形で外に残す。案件、判断、失敗、技術メモ、アイデア、記事、投資ルールなどを蓄積し、あとからAIが検索して使えるようにする。

これは技術的には「外部記憶」「永続状態」に近い役割を持っています。

Anthropicも、長時間動くエージェントでは、コンテキストウィンドウの外へノートを保存し、必要になったときに読み戻すstructured note-taking / agentic memoryを重要な手法として挙げています。

でも、自分にとってVaultの効果はAI側だけではありませんでした。

自分自身の認知も拡張された。

以前なら、その場で考えて終わっていたことが残る。

別の日の考えとつながる。

「あの話と、この話は同じ構造では？」と気づける。

今回もまさにそうでした。

AIに外部記憶を持たせるためにVaultを作った結果、そのVaultを使っている自分自身が、AI活用の構造を理解しやすくなった。

この外部記憶をなぜ作り始めたのかは、正式連載の第1回「ChatGPTに長期記憶が欲しくて、Knowledge MCPを作った」で開発記録から整理しています。

そして、次の疑問が出てきました。

「ここまで記憶できて、実行もできるなら、毎回自分が指示しなくても回せるのでは？」

そこで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へ残す
        ↓
その結果を読んで次の作業を決める
        ↺

ここまで閉じれば、人間が毎ターン「次はこれをやって」と指示する必要がかなり減ります。

実装では、この継続性を会話履歴だけに依存させませんでした。仕事そのものをRunとして扱い、現在状態・Event・CheckpointをSQLiteへ残し、Chatやサービスが途中で切れても同じ仕事へ再接続できるようにしています。

→ 第7回：AIが途中で止まっても、続きを再開できるようにした

そして第8回で、Loop Engineeringと普通のAutomationをさらに分けて考えました。手順が決まっている仕事はAutomation / Workerへ、GoalとSuccess Criteriaを持ち、Evidenceを見て次の一手を選ぶ仕事はAutonomous Loopへ。 自律性とは「何でも勝手にすること」ではなく、制約された範囲で次のbounded actionを選べることだと整理しています。

→ 第8回：作業自動化と「自律するAI」は何が違うのか

さらに複数のRun / Chatを同時に動かすと、Loop Engineeringにはcoordinationも必要になりました。各Runが正しく動いていても、同じworking tree、同じmain、同じdeploy境界、あるいは別Chatの責務を共有すれば衝突します。

そこでisolated workspace、component lease、shared mutation serialization、live state control plane、workspace ownershipを追加しました。

→ 第9回：複数のChatGPTに同じシステムを開発させたら、普通に衝突した

並列化が進むと、次に目立ったのは人間の承認待ちでした。複数のRunが動いても、routineな可逆作業のたびに全てが「承認します」を待つなら、人間が中央のqueueになります。そこでStanding Delegationを入れ、安全で可逆・scopeが明確な処理は次の本当のprotected boundaryまで進め、秘密・不可逆・目的変更などだけを人間へ戻す形へ整理しました。

→ 第10回：AI開発のたびに「承認します」と打つのをやめた

ただし、本当に人間が必要な境界は残ります。そこで最後に、Owner intentの入力だけを軽くするApproval UIを追加しました。UIはAuthorityそのものではなく、実行可否はserver-sideのpolicyとlive-state再検証で決める構造です。

→ 第11回：AIに「承認」ボタンを作った。でも、ボタンに権限は渡さなかった

一足飛びに来たようで、実は一段ずつだった

振り返ると、最初からこういう設計思想を知っていたわけではありません。

むしろ逆でした。

もっと良い答えがほしい。

→ プロンプトを工夫した。

毎回説明したくない。もっと自分の状況を知っていてほしい。

→ コンテキストを積み重ねた。

答えるだけじゃなく、実際に作業してほしい。

→ サーバーを立てて、MCPで外部システムにつないだ。

会話が終わっても知識を失いたくない。

→ Vaultを作った。

記憶も実行環境もあるなら、自分で改善を回せないか。

→ Loop Engineeringに興味を持った。

一足飛びに最前線へ来たような気分になっていましたが、実際にはそうではありませんでした。

一つ前の段階で感じた不満を、一つずつ潰してきただけだった。

その結果、後から名前を知った技術概念と、自分が作ってきたものがつながった。

これはかなり面白い経験です。

当時はまだ「ループ完成」ではなかった

この記事を最初に書いた時点では、Vaultを作ってサーバーにつないだだけでLoop Engineeringが完成したわけではありませんでした。

多くの場合、最初の仕事はまだ自分が与えていました。

「これを調べて」

「開発を続けて」

「この記事を作って」

と指示して、AIが動く。

当時の現在地を正確に言えば、Harnessと外部Memoryがかなり整い、Loopを作れる条件が揃ってきた段階でした。

その時に考えていた次の形は、AIが自分で、

状態を読む
未解決課題を見つける
次の行動を決める
実行する
別の仕組みで評価する
結果を記録する
次のサイクルへ進む

という閉じたループです。

この記事を書いた時点では、ここはまだ構想でした。

その後、MCP群でCapabilityを増やすだけでは「次に何をするか」は自動化されないと分かり、既存MCPを置き換えず、その上にGoal → Plan → Execute → Evidence → Evaluate → Next Actionを回すLoop Engineを実装し始めました。

→ 第6回：MCPをいくつ作っても、AIは自律化しなかった。そこでLoop Engineを作った

つまり、この概念記事で書いていた「次に作りたいもの」が、その後の正式連載第6回で実装史として続いています。

さらに第7回では、そのLoopを「一回のChatの中で回るもの」から、途中で停止・再起動・引き継ぎがあっても続くdurableなRunへ変えていった経緯を扱っています。

第8回では、そのdurableなRunの上で、「固定された処理を繰り返すAutomation」と「Evidenceを見て次の行動を選ぶAutonomous Loop」を分離しました。AIを自由にするのではなく、Goal・Capability・risk・budget・approval boundaryで安全に選べる空間を作る方向へ進んでいます。

第9回では、そのLoopを複数同時に動かした時に必要になるcoordination layerへ進みました。一つのLoopが安全でも、複数のLoopが共有状態を持てば別の安全設計が必要になるという段階です。

第10回では、そのcoordinationが進んだ結果として人間自身が承認queueになった問題を扱っています。bounded autonomyを崩すのではなく、routineな可逆作業だけをStanding Delegationで前へ進め、protected boundaryを人間へ残す段階です。

第11回では、残ったprotected boundaryでの人間判断をApproval UIから入力できるようにしました。ただし、UIは権限境界ではなく、Owner intentとAuthorityを分離しています。

→ 第11回：AIに「承認」ボタンを作った。でも、ボタンに権限は渡さなかった

Season 1の最終回では、こうして一段ずつ増えた仕組みを、Knowledge MCPから並列開発・Authorityまで一本の開発史として振り返りました。

→ 第12回：記憶から並列開発まで。自分専用AI基盤は、いったんここまでできた

Season 1は第1回〜第12回で一区切りです。Season 2は別番号体系で、作った基盤を「疑う」ところから続きます。

「AIに何を聞くか」から「AIが働く仕組みをどう作るか」へ

Prompt Engineeringを知ったときは、AI活用とは「上手な質問の仕方」だと思っていました。

今はかなり違います。

質問の文章だけでなく、知識、記憶、道具、権限、実行環境、評価方法、フィードバック、継続性、そして複数AI間のcoordinationまで含めて考えるようになりました。

つまり関心が、

AIをどう使うか

から、

AIが継続的に働けるシステムをどう設計するか

へ移っている。

先にこの世界を進んでいる人たちから見れば、まだ入口だと思います。

でも、用語を知らないまま必要に迫られて一段ずつ進み、後から地図を見つけた感覚があります。

地図が見えたなら、ここからはもっと速く進めるはずです。

今はそれがかなり面白い。

参考資料

追記：この記事は連載本編ではなく、概念編として残します

この記事は、Prompt / Context / Harness / Vault / Loopという概念のつながりを考えた記事です。実際にKnowledge MCP、Development MCP、Development Runner、GitHub PR、Publishing MCP、Loop Engine、Run / Checkpoint / Resume、Autonomous Loop、Parallel Chat / Workspace、Standing Delegation、Approval UIを作った順番と理由は、正式連載「ChatGPTと育てる、自分専用AI基盤」で開発史として整理しています。

第6回はLoop Engineの誕生、第7回はそのLoopを長時間の仕事として継続可能にした実装史、第8回はAutomationとAutonomous Loopの境界、第9回は複数のRun / Chatを安全に並列化するcoordination layer、第10回は並列化後の人間の承認ボトルネックとStanding Delegation、第11回はHuman-in-the-loopの意思入力を楽にしつつAuthorityをserver-sideへ残すApproval UIを扱っています。第12回でSeason 1全体を一区切りにしました。

この記事はそれらの概念的な背景として読む位置づけになりました。