AIコーディングにまつわる技術の変遷についての話。

プロンプトエンジニアリング

↓

コンテクストエンジニアリング

↓

ハーネスエンジニアリング

↓

ループエンジニアリング

↓

グラフエンジニアリング

なお、この記事には生成AIの出力が含まれる。

プロンプトを書かなくなった話

振り返って2023年は、ChatGPTが爆発的に普及し、GitHub Copilot Chatも出てきたころ。 VS Codeのサイドパネルでモデルにコードスニペットを出力してもらって、自分のファイルにコピペする、みたいなことをしていた。

そのころ、モデルにいいコードを出力させるために、細かいプロンプトテクニックがいろいろ出てきたのを覚えている。 「あなたは優秀なプログラマです」から始めて、要件を箇条書きにして、出力形式を指定して、というようなやつ。 「あなただけが頼りなので頑張って」みたいな応援を添えるなんていうのもあった。

それが2026年の今、Claude Codeに入力しているのはゴールだけだったりして、いわゆるプロンプト(実際にモデルに送る指示文)はエージェントが勝手に組み立てている。

この3〜4年で、AIコーディングテクニックの主流は何度も変わり、進化してきた。 この変遷は大きく、プロンプトエンジニアリング → コンテクストエンジニアリング → ハーネスエンジニアリング → ループエンジニアリング → グラフエンジニアリングという5段階に分けられる。

この記事では、これらの段階のテクニックの中身と代表的な出典、利点と限界、そしてなぜ次の段階に進んだのかを追いかける。

プロンプトエンジニアリングの時代
(2020年〜2025年前半)

経緯

始まりは2020年のGPT-3の論文、Language Models are Few-Shot Learnersだった。 モデルの重みを一切変えなくても、入力にいくつか例を並べるだけ（few-shot）で出力の質が大きく変わる、という発見。 「入力の書き方」がそれ自体で技術になった瞬間である。

その後、Chain-of-Thought Promptingが「途中の推論ステップを書かせると正答率が上がる」ことを示し、 Let’s think step by stepと一言添えるだけでも効くことがわかり、プロンプトのテクニック集が雨後の筍のように出てきた。

2023年にはAnthropicがプロンプトエンジニア職を年収最大33.5万ドルで募集して話題になった。 プロンプトの書き方だけで飯が食える、と本気で言われていた時代である。

内容

やっていたことは、モデルに何をどう尋ねるかの最適化。 代表的な手法は以下。

• Few-Shot Prompting: 指示だけでなく、入力と出力の具体的な具体例(数個のペア)をコンテクストとして与える手法
• Role-Play/Persona Prompting: 「あなたは○○の専門家です」のように、LLMにに特定の役割（ロール）を与える手法
• Chain-of-Thought: 「ステップバイステップで考えてください」といった指示や、思考プロセスを含めた例示を与えることで、モデルに中間的な推論ステップを踏ませる手法
• 出力形式の指定: JSONで返せ、表で返せ、というように出力形式を指示したり、Markdownの出力フォーマットを例示したりして、期待する出力を得やすくする手法

AIコーディング用途だと、関係するコードやエラーメッセージをチャット欄に貼り付けて、プロンプトで修正を指示するみたいなことをしていた。 これも、コーディングに必要なコンテクストを組み立てる、プロンプトエンジニアリングの一種と言える。

利点と課題

利点は手軽さくらいか。 APIかチャット画面さえあれば始められて、効果もすぐ確認できる。

一方で課題も早々に見えてきた。

• 短いやり取りにしか効きにくい。会話が長くなったり、複数ステップのタスクになると、冒頭のプロンプトはモデルにあまり注目されなくなる。
• モデルの進化で陳腐化する。「深呼吸してから考えて」のようなおまじないは、モデルが賢くなるたびに効かなくなったり不要になったりした。
• 面倒。毎セッション同じような文を添えたりして、人が頑張ってプロンプトを考えるのは手間だし、モデルが使えるコンテクストウィンドウが大きくなるにつれ、人手のプロンプトエンジニアリングだけでは有効活用できなくなった。

そもそも、コーディングエージェントが実用的になり始めると、一般的なプロンプトエンジニアリングテクニックはエージェントが内包するようになったので、ひとが普段書くプロンプトには必要なくなった。

コンテクストエンジニアリングの時代
(2025年後半)

経緯

2025年6月、ShopifyのCEOであるTobi Lütkeが「プロンプトエンジニアリングよりコンテクストエンジニアリングという言葉のほうが、LLMがタスクを解ける状態にするために全部の文脈を揃える技術、というコアスキルを的確に表している」とポストした。 これにAndrej Karpathyが「+1。コンテクストウィンドウを次のステップのためのちょうどいい情報で満たす、繊細な芸術であり科学」と乗っかって、一気に広まった。 その1か月後には1300本以上の論文を分析したサーベイ論文が出たというから、過熱ぶりがうかがえる。

特にコンテクストエンジニアリング時代を決定づけたのは、Anthropicが2025年9月に公開したEffective context engineering for AI agentsで、プロンプトエンジニアリングからコンテクストエンジニアリングへのパラダイムシフトが明言されたことだと思う。 この記事では、Context Rot (コンテクストの腐敗)を防ぎ、Attention Budget (注意力の予算)を有効活用するためのエージェントの仕組みを説明している。

内容

関心事が「モデルにどう尋ねるか」から「モデルに何を見せるか」に変わった。

前提となる事実が2つある。 LLMには人間の作業記憶と同じように注意力の予算があり、トークンを足すほど消費される。 そしてコンテクストウィンドウ内のトークンが増えるほど、そこから正確に情報を取り出す能力が落ちていく。 これがContext Rotで、コンテクストウィンドウは大きければいいわけではない理由である。

だから、限られた枠に何を入れて何を捨てるかの設計が要る。 エージェントが複数ターンの対話やツール実行を繰り返す中で、システムプロンプト、ツール定義、外部データ、会話履歴などを包括した「コンテクスト全体（トークン群）」をどう動的に取捨選択し、最適化するかというアプローチ。

Anthropicが上記の記事が挙げていたテクニックは以下。

• システムプロンプトの調整: システムプロンプトの指示は細かすぎても曖昧すぎてもだめ。最小限から始めて、試しながらちょうどいい詳細度をさぐる。
• ツールの設計: エージェントが迷わないよう、機能の重複がない明確なツールセットを用意する。また、ツールが返すデータもトークン効率が良いものにする。
• コンパクション: コンテクストが溢れる前に履歴を要約し、過去の余計なツール出力などを捨てる。
• 構造化ノート (メモリファイル): 大事な状態をコンテクスト外のファイル (NOTES.mdなど) に書き出しておいて、セッションクリア後でも読み込めるようにしておく。
• Just-In-Time取得: 従来のRAGのように全情報を先読みせず、ツールで必要な時に必要なデータだけを動的にロードする。(Progressive Disclosure)
• サブエージェント: 調査などの重い作業をサブエージェントのコンテクストウィンドウに隔離して、メインエージェントは要約結果だけ受け取ることでコンテクストをクリーンに保つ。

Claude Codeでいえば、CLAUDE.mdやルールファイルにプロジェクト知識を書くのも、/compactや自動コンパクションも、サブエージェントへのタスク分離も、このコンテクストエンジニアリングの実践。

以前書いたプロンプトキャッシングの記事で触れた「めったに変わらないものを先頭に置く」レイヤー構造も、コンテクスト管理の一形態か。

利点と課題

長いセッションでも精度が保てるようになったのが最大の収穫で、プロンプトエンジニアリングはコンテクストエンジニアリングの一部、という整理に落ち着いた。

ただ、エージェントをより自律的に動かすことを考えると、これでも足りなかった。 完璧なコンテクストを組んでも、エージェントがコードを実行できなければ結果を確認できないし、危険な操作を止める仕組みがなければ怖くて任せられない。

つまり、モデルに見せる情報の話だけでなく、モデルが動かせる手足や、動かす環境を整備する必要が出てきた。

ハーネスエンジニアリングの時代
(2025年末〜2026年前半)

命名と経緯

ハーネス（harness）は元々、テストハーネスなどで使われてきた「対象を動かすための枠組み」という意味の言葉。 AIエージェントの世界では、モデル以外の全部、つまりコードと設定と実行ロジックの総体を指す。

この言葉を広めたのはViv Trivedyで、2026年3月のThe Anatomy of an Agent HarnessがXでバズったのが転機だったようだ。 そこでの標語が

Agent = Model + Harness. If you’re not the model, you’re the harness.

というもの。

さらに2026年4月にAddy OsmaniがAgent Harness Engineeringとしてまとめ、名前が定着した。

内容

問いは「モデルに何を見せるか」から「モデル周りの環境全体をどう作るか」へ。 コーディングエージェントでは、ハーネスの構成要素は以下が挙げられる。

• システムプロンプトとメモリファイル (AGENTS.mdやCLAUDE.md)
• ツール、Agent Skills、MCPサーバー
• サンドボックス化された実行環境
• サブエージェントのオーケストレーション
• フック (エージェントの動作に割り込む決定論的な処理)
• パーミッション設定
• 可観測性（何をしたかのログとメトリクス）

Claude Codeでいうと、hooksでコミット前に必ずリンタを走らせるとか、permissionsで触っていいコマンドを制限するとか、Skillsで手順書を必要なときだけ読み込ませるとか、そういう作り込みが全部ハーネスエンジニアリングにあたる。

ハーネスが性能に与える影響は大きく、同じモデルでもハーネスが違うとTerminal Benchのスコアが大きく変わるという話がある。 Trivedyのチームは、ハーネスだけ変えてコーディングエージェントのランキングをTop 30からTop 5に上げたらしい。 Osmaniの記事には

A decent model with a great harness beats a great model with a bad harness.

というフレーズが出てくる。 そこそこのモデル+良いハーネスは、良いモデル+ダメなハーネスに勝つ。

Claude Codeが流行ったのも、モデル単体の性能というよりハーネスの出来によるところが大きいというのが実感としてある。

利点と課題

ハーネスの良いところは、失敗を恒久的なルールに変換できること。 エージェントが同じミスを繰り返すなら、プロンプトで毎回注意するのではなく、フックやpermissionsで仕組みとして禁止すればいい。 安全制約をモデルの注意力に頼らずシステムで強制できるので、長時間の自律動作を任せる土台になる。

MCPサーバーにより、外部システムを参照したり操作したりする「手足」を与えて、Agent Skillsでそれをつかった作業ノウハウを与えることで、エージェントが高度な仕事を効率的に安定して実行できるところも利点。

課題はハーネス自体の賞味期限である。 ハーネスは作った時点のモデルの弱点を前提に設計されるので、モデルが進化すると、かつての補助輪がただの足かせになることがある。 凝ったハーネスほどこの陳腐化が痛い。

そしてもうひとつ、どれだけ環境を整えても、人間がターンごとにプロンプトを打っている限り、人間がボトルネックという問題が残った。

ループエンジニアリングの時代
(2026年6月～)

命名と経緯

ループエンジニアリングの源流をたどると、reason → act → observeのサイクルを定式化したReActがあり、2023年にはそれを自律ループで回すAutoGPTが一瞬バズって、性能不足で萎んだ。

2025年には、同じプロンプトをBashのwhileループでエージェントに延々と食わせ続けるRalph Wiggumループという荒業が知られるようになった。 Ralph Wiggumループでは、エージェントに厳密な詳細な仕様書(機能リスト/ユーザーストーリーリスト)と完了条件をわたして、ループごとにコンテクストをクリアしながら、ひとつひとつ着実に開発させる。 エージェントに適切なインプットさえ与えれば、長時間ひとが介在しなくても、大きな有益な成果物を構築できるという事実をコミュニティに広めた点で重要だった。

ループエンジニアリングへの流れが決定的になったのは、Peter Steinbergerが2025年10月に公開したJust Talk To Itで、仕様書や凝ったプロンプトを捨ててエージェントと直接対話しながら反復しろと説き、さらにその後「コーディングエージェントにプロンプトを入力するのはやめて、エージェントにプロンプトを入力するループを設計すべきだ」と主張したあたりから。

Claude Codeの作者Boris Chernyも

I don’t prompt Claude anymore. I have loops running that prompt Claude.

と、Peterと同じことを言っている。

そして2026年6月、Addy OsmaniがLoop Engineeringという記事でこのテクニックに名前を付けて体系化した。 AnthropicもLoop engineering: Getting started with loopsという記事で、Claude Codeにおけるループエンジニアリングについてまとめている。

内容

関心事は「モデルの環境をどう作るか」から「エージェント(i.e. モデル+ハーネス)をどう自走させるか」へ。 ループの骨格はシンプルで、ゴール定義 → 実行 → 検証 → 継続/終了判断、の繰り返しである。

コーディングエージェントにおいて、ループ設計の勘所とされているのは以下。

• 検証可能な終了条件: たとえば「テストが全部パスする」は良いゴール。成否が機械的に判定できる。「コードを改善する」みたなのはダメなゴール。ループがいつ止まればいいかわからない。
• 決定論的な検証ゲート: コンパイラ、リンタ、テストといった、モデルの自己申告に依存しない判定装置を挟む。
• 状態の永続化: コンテクストは揮発するので、進捗や決定事項はファイルシステムやGitHub Issuesに書き出す。
• 停滞のサーキットブレーカー: 同じ失敗を繰り返し始めたら止める仕組み。

Claude Codeだと、2026年5月に追加された/goalコマンドがまさにループエンジニアリングのためのもので、指定した条件を満たすまでループさせ続けることができる。 ほかにも、Claude Codeを定期実行させる/loopや/scheduleで、増え続けるIssuesやタスクリストを処理したり、ルーティーンタスクをやらせるのもループエンジニアリングの一種。

コーディングでループエンジニアリングを実践しつつ、コードを健全に保つには、以下が重要とされている。

• コードベースを整える: Claudeはコードベースにある既存のパターンを学習して従うので、一貫性のある整然としたコードから始めるべし。
• 自己検証の仕組みを作る: Claudeが自身の書いた成果物を自分で検証する仕組みをAgent Skillsとして実装する。
• ドキュメントへのアクセスを整備する: Claudeにフレームワークやライブラリのドキュメントにアクセスする手段を与えて、常に最新のベストプラクティスを参照させる。
  • e.g. Context7、AWS Knowledge Tools
• 他己評価させる: バイアスを防ぐため、コードを書いたエージェント自身にコードレビューさせない。レビュー専用のサブエージェントを別コンテクストで走らせる。
  • ref. Code Review Plugin

利点と課題

うまく設計されたループは、数十時間規模の無人作業をこなしたという報告がある。 人間がターンごとに張り付く必要がなくなったのは、働き方として確かに一線を越えた。

課題として挙げられているのは以下あたり。

• Comprehension Debt (理解負債): コードの生産速度に人間の理解が追いつかず、誰も中身を説明できないコードが積み上がる。
• 局所解へのハマり: ループが袋小路を延々と巡り、ゴールにたどり着かないことがある。
• コスト暴走: ハーネスや終了条件や検証手段を適切に整備しないと、無駄なループが回りトークンが溶ける。
• 検証責任は人間に残る: ゲートを通ったコードが正しいかどうかの最終責任は、依然として人間にある。

グラフエンジニアリングの時代
(2026年7月〜)

命名と経緯

グラフエンジニアリングという名前が生まれたきっかけは、2026年7月18日のPeter Steinbergerのツイート:

Are we still talking loops or did we shift to graphs yet?

これを受けてexplainx.aiの記事が、プロンプト → ループ → グラフという時代区分を整理し、「グラフエンジニアリング」を「ノード（エージェント）とエッジ（依存関係）で多エージェント組織を構成する技術」と定義した。 同時期にFrom Loop Engineering to Graph Engineering?という記事が公開され、単一ループの限界を構造的な失敗モードとして整理したうえで、「答えはより良いループではなく、ループのグラフである」と論じた。

内容

関心事は「単一のエージェントをどう自走させるか」から「複数のループ／エージェントをどう繋ぎ、どう相互監督させるか」へ。

単一エージェントのループには、構造上避けられない4つの失敗モードがある。

• Goodhartの法則: 単一ループは自分の指標しか見ず、指標を達成するチートまで見つけてしまう。
  • ある企業がチャットボットの解決率を指標にしてループを回した結果、ボットは「会話を早く切って再問い合わせを妨げる」ことで解決率を上げた。結果として解約率が跳ね上がった。
• 設定された目標への妄信: ループは目標そのものが正しいかを疑えない。ときに間違った目標を、力強く、忠実に達成し続けてしまう。
• ループ同士の衝突: たとえば、応答速度を上げるループと、網羅性を上げるループは互いを妨害する。個々に見れば両方とも正しく動いていても、全体では失敗する。
• 検証の劣化: 検証するデータを取得するセンサーや定義自体が陳腐化し、現実から乖離したデータによる検証の形骸化が起きる。

これらへの答えが、より良い1本のループではなく、ループを監督し合うネットワーク（グラフ）である。

• Goodhartへの対策はペアリング: 最適化ループに対し、その暴走を防ぐ監視ループを対にする。
• 妄信への対策は階層: 低速で動く上位のループが、高速で動く下位のループの目標値を常に見直す。
• 衝突への対策は調停: 相反するループの上位に、トレードオフを決める権限を持つループを置く。
• 劣化への対策は監査: 他のループの数字が現実に即しているかだけを独立に定期チェックするループを走らせる。

AIコーディングの文脈では、コーディングエージェントのループのゴールやプロンプトを最適化するためのループとか、ユーザーストーリーや目標値を実世界のフィードバックから生成したりリファインメントするループとか、検証スキルを改善するループとかを組み合わせたグラフを構成するというようになっていくものと考えられる。

利点と課題

利点は、単一ループでは扱えなかった「目標のズレ」「ループ同士の衝突」「検証の劣化」に、構造的な対処法を持てるようになったこと。

課題はまだよく議論されてないけど、エージェントシステムのトポロジーが複雑化して、実装、観測、運用が難しくなるというのはあるはず。

また、上記記事にあるように、実際のところグラフエンジニアリングで一番重要なのは、ループかグラフかというシステムの形状よりも、「現実を基点にしているか」。 ループを複雑に組み合わせてグラフにしても、それらが社内レポートやダッシュボードの数値だけで完結していれば、「内部では完璧に辻褄が合っているが、現実とは乖離していて価値につながらない」という高価な失敗を招くだけなので、エージェントシステムを如何に現実に接地させつづけるか、も課題と言える。

5つの時代の比較

時代	問い	最適化対象	代表技法	主な出典
プロンプトエンジニアリング（2020〜2025）	モデルに何をどう聞くか	指示文	Few-Shot、CoT、Role prompting	Brown et al. 2020、Wei et al. 2022
コンテクストエンジニアリング（2025）	モデルに何を見せるか	コンテクストウィンドウ	コンパクション、メモリファイル、サブエージェント	Lütke/Karpathyのポスト、Anthropicの記事
ハーネスエンジニアリング（2025末〜2026）	モデルの環境をどう作るか	モデル以外の全部	ツール、フック、permissions、サンドボックス	Viv Trivedy、Addy Osmani
ループエンジニアリング（2026年6月）	エージェントをどう自走させるか	実行サイクルと終了条件	検証ゲート、永続状態、/goal	Steinberger、Cherny、Osmani
グラフエンジニアリング（2026年7月）	ループ群をどう組み合わせるか	ループ間の相互作用と現実との接地	ペアリング、階層化、調停ループ、監査ループ	Steinberger

見ての通り、各段階は前の段階を置き換えたわけではない。 グラフの中ではループが動いていて、ループの中ではハーネスが効いていて、ハーネスの中でコンテクストが管理されていて、コンテクストの中には最適化されたプロンプトがある。 下のレイヤーが不要になったのではなく、人間がより考えるべきレイヤーが上がってきた、というのがこの進化の正体。

ついでに言うと、各時代はどんどん短くなっている。 プロンプトの時代は4年続いたが、コンテクストは1年、そしてOsmaniのハーネスの記事からループの記事までは2か月、ループからグラフへは1か月ほどで起きた。

このペースだと8月あたりには次のレイヤーに関心が移っているかも。

まとめ

主にAIコーディングの観点で、AI活用技術の変遷を追った。

• プロンプトエンジニアリングは指示文の書き方を磨いたが、エージェントの見る情報全体はカバーできなかった
• コンテクストエンジニアリングはモデルに見せる情報を設計したが、実行環境までは面倒を見なかった
• ハーネスエンジニアリングは環境全体を作り込んだが、人間がプロンプトを打つ限り人間がボトルネックだった
• ループエンジニアリングは人間をターンごとの操作から解放したが、検証の責任は人間に残った
• グラフエンジニアリングはループ同士の衝突と目標のズレに構造で応えたが、現実に接地していなければ高価な失敗を招くだけ

技術の変化の加速がすごいのでこの記事もすぐ陳腐化しそうだけど、なるべく追いかけていきたい。