blog-thumbnail-ai-engineering-five-layers
AI 駆動開発閲覧数:

Prompt から Graph まで、AI エンジニアリング5層の進化史

torii
Kenta Torii

Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering、Graph Engineering。2021年から2026年にかけて、AI を扱うための用語が次々に生まれました。この記事では、5つの用語がどの順番で登場し、それぞれ何を対象にしているのかを命名の経緯とあわせて整理します。


対象が一段ずつ外側へ広がっている

5つの層を並べると、扱う対象が内側から外側へ順に広がっていることがわかります。

対象命名の時期
Prompt Engineeringモデルへの話し方2021年
Context Engineeringモデルに見せるもの2025年6月
Harness Engineering足場全体2026年前半
Loop Engineering足場の動かし方2026年6月
Graph Engineering複数ループの配線2026年7月

1回の入力を工夫するところから始まり、モデルに渡す情報全体の設計、ツールやフックまで含めた足場、その足場をいつどう動かすか、そして複数のエージェントをどう配線するか、と対象が広がります。新しい層が生まれても前の層が消えるわけではなく、外側の層が内側の層を包み込む関係にあります。

背景には、この期間にモデル自体が急速に進化したことがあります。OpenAI は GPT-3(2020年5月)から ChatGPT・GPT-3.5(2022年11月)、GPT-4(2023年3月)、GPT-4o(2024年5月)と進み、Anthropic は Claude 1(2023年3月)から Claude 3.5 Sonnet と Computer Use(2024年)、Claude Code の研究プレビュー(2025年2月)へ、Google は Bard(2023年3月)から Gemini へと改称して世代を重ねました。モデルにできることが増えるたびに、それを取り囲む足場の側で解くべき問題が新しく現れた、という流れです。

Prompt Engineering:1回の入力で勝負する(2021〜2022年)

用語としては Radford ら(2021)や Reynolds & McDonell(2021)の論文に登場します。プロンプトによる制御自体は GPT-2 / GPT-3 の時代からありましたが、2022年11月の ChatGPT 公開で「入力欄に書く」という形が一気に一般化しました。

対象は1回の入力と1回の出力です。system 指示の書き方、few-shot の例示、Chain-of-Thought といった技術で、一度のリクエストから引き出せる品質を最大化します。当時は試行錯誤を重ねる職人技として扱われ、専門職・学問分野・市場ニッチとして確立しました。

この層には明確な限界があります。モデルが持っていない情報、たとえば自社の顧客履歴や社内ドキュメントの中身は、言い回しをどれだけ工夫しても出てきません。この限界が次の層を呼びました。

Context Engineering:何をどの順番で見せるか(2025年6月〜)

2025年6月18日、Shopify CEO の Tobi Lütke が X で「prompt engineering よりも context engineering のほうが的確だ」という趣旨の投稿をしました。6日後、Andrej Karpathy が OS のアナロジー(CPU がモデル、RAM がコンテキストウィンドウ)を添えて拡散し、用語として定着します。

もっとも、Lütke が最初というわけでもありません。Devin を開発した Cognition の Walden Yan が同年前半から近い言葉を使っていました。2025年9月29日には Anthropic の Applied AI チームが定義を正式化しています。

この層が対象にするのは、指示・会話履歴・検索結果・社内ドキュメント・ツール群といった、モデルに渡るもの全部です。何をどの順番でどのように渡すかを設計して回答精度を上げる技術であり、プロンプトはその一部(サブセット)という位置づけになりました。プロンプトエンジニアリングが不要になったのではなく、より大きな枠の中に収まったと理解するのが正確です。

なお Lütke は同じ投稿で「新しいソフトウェアの厚い層」という言い方もしています。この表現は約8か月後、次の層の名前として再登場することになります。

Harness Engineering:モデルの外側を作り込む(2026年前半)

2026年2月上旬、Terraform の作者である Mitchell Hashimoto が「Agent = Model + Harness」という定式化を発表しました。その6日後、OpenAI の Ryan Lopopolo が社内実験の報告として論考を公開し、これが用語を業界へ広げます。数週間後には Martin Fowler のサイトで Birgitta Böckeler が guides と sensors という分類法を示し、議論が発展しました。

ハーネスとは、モデル自体を除いた、エージェントを構成するすべてを指します。ツール、メモリ、サンドボックス、フィードバックループがここに含まれます。前の層と比べて新しいのは、評価とフィードバック、ガバナンスと安全性が中心に来ることです。リクエストを受けた結果がうまくいったかどうかを判定し、その判定が次回に効くようにする、という発想が加わりました。

Lopopolo が報告した実験の数字がこの層の性格をよく表しています。2025年、OpenAI の小さなチームが5か月間、人間はコードを1行も書かないという制約で開発を行いました。3人のエンジニアが Codex だけを使って1,500件の PR と約100万行のコードを積み上げ、実際に社内ユーザーを持つ製品を出荷しています。ただし順風満帆だったわけではなく、当初は毎週金曜(勤務時間の20%)を「AI スロップ」の掃除に費やしていました。これは長続きせず、最終的には掃除を自動化する仕組みを作ることになります。

発想の転換は、モデルの賢さに期待するのをやめて、リンターやテストのような仕組みの側で間違いを起こせなくする点にあります。Lopopolo は、よいハーネスの部品はいずれ削除されることを前提に設計されている、とも振り返っています。モデルが賢くなれば足場の一部は不要になるという前提で作る、ということです。

Loop Engineering:足場をいつ、どう動かすか(2026年6月〜)

2026年6月、Google Cloud の AI ディレクターである Addy Osmani(同年2月に Chrome チームから異動)が Loop Engineering と名付けました。Claude Code の責任者である Boris Cherny や、OpenClaw の作者である Peter Steinberger らの発言を統合した造語です。同年6月30日には Andrew Ng が Inner / Outer ループという製品開発寄りの視点を加えています。

Inner Loop はエージェントが回す内側のループで、調査・実装・検証を繰り返す部分です。Outer Loop は人間が所有する外側のループで、品質の検証、出荷の判断、説明責任がここに入ります。1回ずつプロンプトを打つのではなく、仕事を発見させ、実行させ、検証させ、記憶させるシステムそのものを設計する、という考え方です。

前の層との違いは「再実行」が入ることです。実行して観測して評価するところまでは Harness の範囲でもできますが、そこに改善と再実行が加わると、フックなどをきっかけにループが自律的に回り始めます。1つの指示を投げたあと、品質が継続的に上がっていく運用が視野に入ります。

Andrew Ng は、分単位のコーディングループが時間単位の開発者フィードバックに入れ子になり、それがさらに日単位のユーザーフィードバックに入れ子になる、と整理しています。ループは1本ではなく、時間スケールの違う複数のループが重なっている、という見方です。

Graph Engineering:複数のループをどう配線するか(2026年7月〜)

2026年7月18日、explainx.ai の記事が graph engineering という議論を統合しました。ただし用語の出自は定まっておらず、既存の「ナレッジグラフ」という語法との衝突も指摘されています。グラフベースのオーケストレーションという実践自体は LangGraph や AutoGen の GraphFlow として以前から存在しており、新しいのは名前のほうです。

輪郭が定まっていない様子は、当事者の反応からも見て取れます。2026年7月、DeepLearning.AI のナレッジグラフ講座と Linear の AI 機能「Loops」が同時期に話題になり、エージェントの組み方はグラフかループかという古い論争が再燃しました。LangChain の作者である Harrison Chase は、graph engineering が何を指すのか自分もよくわかっていない、それは LangGraph のことではないのか、という趣旨の投稿をして大量の反応を集めています。

扱う対象は、エージェント・分岐・並列・人間の承認といった構造です。Loop Engineering が1つのエージェントの内部を対象にするのに対して、Graph Engineering はエージェントの集まり全体を対象にします。マルチエージェント組織の配線をグラフが担い、各ノード内部の実行をループが担う、という役割分担で捉えると整理しやすくなります。

実務的な狙いとしては、情報同士のつながりをデータ化することが挙げられます。社内ドキュメント、Web 上の情報、会話履歴は本来関係を持っているのに、その関係が離散していて機械には見えません。現状はプロンプトやコンテキストの中に「これとこれはこういう関係だ」と書き込んで補っていますが、関係性そのものをデータとして持たせれば、モデルが検索して理解できる状態に近づきます。

5層に共通する4つのパターン

5つの層を並べると、共通する動き方が見えてきます。

  • 対象が外側へ拡大する: 呼び出し、情報、足場、起動、配線と一段ずつ広がる
  • 実践が先で、命名は後: OpenAI の社内実験のように、先に現場の実践があり、名前は後から追いつく
  • 命名がミーム化する: X 上の投稿や衝突が、数日で業界の語彙になる
  • 成熟度に差がある: Prompt と Context は定着済みだが、Graph はまだ用語の定義が係争中

この構図は他の分野でも見られます。DevOps(2009年、Patrick Debois)から SRE(Google、2016年に書籍化)を経て Platform Engineering(2022年)へ至る流れも、実践が先で命名が後、そしてスコープが外側へ広がるという同じ形をしています。Platform Engineering が出てきたときにも「DevOps は終わったのか」という論争が起きました。今の Graph Engineering をめぐる議論とよく似ています。そもそも AI Engineer という職種名自体、2023年6月に swyx が提唱した比較的新しい言葉で、ここまで挙げた用語はすべてその傘の下にあります。

5層はすべて「精度」と「適合」のための手段

ここまでの5層は、突き詰めると2つの目的のための手段の集まりです。

1つは精度で、出力そのものが正しいか、論理が通っているかを問います。ここが崩れていると他の議論は意味を持ちません。

もう1つは適合で、受け取り手が使いやすい状態になっているかを問います。人間が読むのか、次のシステムが受け取るのかによって、望ましい形は変わります。

この2つは別物です。正確なのに使われない出力もありますし、多少粗くても目的を達成する出力もあります。Harness Engineering が legibility(可読性)や証拠を残すことを重視するのは適合の話ですし、Loop Engineering の Outer Loop を人間が持つという設計も適合の話です。

そして最終的なゴールは、人に説明して納得してもらい、顧客に価値を届けるところにあります。裏側でハーネスやループをどれだけ作り込んでも、伝わらなければ目的は達成されません。聞き手のリテラシー、それまでの関係性、相手に時間があるかどうか。それに応じてどれくらいの情報量を渡すかを判断する部分は、引き続き人間の仕事として残ります。モデルは調査も速く、多くの場面で自分より正確な答えを出しますが、それをどう届けるかまでは肩代わりしてくれません。

基礎を飛ばして応用には入りにくい

用語が次々に生まれる状況で実務上つまずきやすいのが、Prompt Engineering の段階を経験しないまま Harness や Graph に入ってしまうケースです。ChatGPT 登場からの流れをリアルタイムで追ってきた人にとっては自然な積み上げでも、途中から参加した人にとっては応用編だけが並んでいるように見えます。案件の事情で生成 AI を使えず、経験を積む機会が少なかった人もいます。チーム内で知識レベルをどう揃えるかは、技術そのものとは別に残る課題です。

同じ理由で、モデルが賢くなるほど基礎の価値が見えにくくなる点にも注意が必要です。プロンプトを雑に書いても成果が出るようになったのは事実ですが、AI がどう動くからこういう出力になる、という感覚がないと、ハルシネーションを見抜けません。資料を1本作る間にも、もっともらしい誤りは混ざります。実際に、有名な発言としてスライドに引用しようとした一文を裏取りしたところ、原文とは意味が違っていたことがありました。出力を疑って一次情報に当たる習慣は、層がいくつ増えても要ります。

もう1つ、チームで運用する際に効いてくるのがばらつきの解消です。同じスキルや設定ファイルを共有していても、指定するモデルが人によって違えば結果も揃いません。どのモデルをどの用途で使うかを定義として共通化しておくと、成果の再現性が上がります。

こうした知識レベルの平準化や、自走できる開発体制づくりに課題を感じている場合は、AIDD キャンプ(集中ハンズオン研修)や AIDD インハウス(伴走型の技術移転)のような形で外から型を入れる選択肢もあります。

まとめ

  • AI エンジニアリングの用語は、モデルへの話し方(Prompt)、見せるもの(Context)、足場全体(Harness)、足場の動かし方(Loop)、複数ループの配線(Graph)の順に、対象を外側へ広げてきました
  • 名前が付く順番は実践より後で、X 上の投稿が数日で業界の語彙になることもあります。定着度には差があり、Graph Engineering はまだ輪郭が定まっていません
  • 5層はすべて、出力の精度と、受け取り手にとっての適合という2つの目的のための手段です
  • 応用的な層から入る前に、モデルがどう動くかという基礎に一度立ち返っておくと、ハルシネーションの検知や期待値の調整がしやすくなります

新しい用語は今後も出てきますが、どの層の話をしているのかが分かれば取り込みやすくなります。KDDIアイレットでは社内でも継続的にこうした知見の共有と平準化を進めています。AI 駆動開発の導入や社内での定着にお悩みの際は、お気軽にご相談ください。

この記事をシェア