Shuichiro Ogawa

Notes ・ updated 2026-06-27

AI エンジニアリングの分類とデザインの関与領域

2025年2月に Karpathy が「vibe coding」を投げてから18ヶ月で、AI を用いたエンジニアリング実践を記述する語彙が急速に分化した。 vibe coding、vibe engineering、agentic engineering、context engineering、harness engineering はそれぞれ異なる実践と異なる責任範囲を指す。 本ノートは各概念を一次ソースから定義し、デザインが関与すべき領域を段階ごとに特定する。

UI 生成エージェントの個別ツール（v0、Bolt、Lovable、Replit Agent）については vibe-coding-design-production を参照。 AX（Agentic Experience）の産業と学術の対照は agentic-experience-design-synthesis を参照。

関連: design-agent-tools-landscape-2026（ツール動向）／agentic-experience-industry（AX 産業言説）。

Vibe Coding：コードを見ない制作

Karpathy が2025年2月に X で投稿した語である1。

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

2026年2月、Karpathy 自身が「シャワー中の思いつきが $10B 以上の産業を生んだ」と振り返った2。

Willison はこの語を厳密化し、「AI の提案をレビューせずに受け入れ、無責任にソフトウェアを作る行為」と定義した3。 「自分だけが使うもので、バグの被害者が自分だけなら、好きにやればいい。本番コードには別の基準が要る」4。

Osmani も同様の区分を示し、CTO 調査で18人中16人が「AI 生成コードによる本番障害を経験した」と報告している5。

デザインの関与は限定的である。 プロトタイプや使い捨ての実験には有効だが、設計判断が入らないため、成果物の品質はエージェントの出力に依存する。

Vibe Engineering：判断を伴う AI 加速

Willison が2025年10月に提案した語で、vibe coding と対置される6。 経験豊富なエンジニアが AI で加速しつつ品質と信頼性を維持する実践を指す。

要件として12項目を挙げた。自動テスト、設計文書（DESIGN.md）、コードレビュー、手動 QA、バージョン管理の熟達などである。 Osmani はこれを「AI-assisted engineering」と呼び、「人間のエンジニアが確固として制御を握る」ことを要件とした5。

Osmani はさらにエンジニアの役割が「coder（書く人）→ conductor（指揮者）→ orchestrator（編成者）」へ進化すると述べた7。 conductor は AI を指揮する個人、orchestrator は複数エージェントを編成するシステム設計者である。

デザインは品質判断として関与する。 「生成されたものの品質を判断し修正できるかどうか」が vibe coding との分水嶺であり、タイポグラフィ、余白、インタラクションの一貫性、アクセシビリティの判断はデザインの職能に属する。 Dylan Field の「AI はフロアを下げたがシーリングを上げていない」はこの構造を表現している8。

Willison が要件に挙げた DESIGN.md は、設計判断を文書化してエージェントのコンテキストに供給する仕組みであり、次節の context engineering への橋渡しでもある。

Agentic Engineering：エージェントの操縦と taste

Karpathy が2026年4月に定義した語で、vibe coding の対義語として位置づけた9。

“You are in charge of taste, engineering, design, and whether the system makes sense. […] No, ‘agentic engineering’ is not a vibe—it’s a professional discipline of steering fallible agents while maintaining correctness, security, taste, and oversight.”

この定義で Karpathy は taste と design を engineering と並列に置いた。 エージェントは誤りうる（fallible）存在であり、人間が正確性、セキュリティ、taste、監視を維持する責任を負うという構造である。

Willison は2026年4月に「vibe engineering と agentic engineering の境界はすでに曖昧になりつつある」と述べた4。 両者は対立概念ではなく、AI 支援の度合いと人間の監視範囲の連続体上にある。

Rauch（Vercel CEO）は同時期に「domain-specific agents infused with taste, tools, and knowledge」を構想し、taste をエージェントに注入すべき要素として位置づけた10。 ここでの taste は個人の感性ではなく、特定ドメインにおける品質基準の構造化された知識を指す。

swyx は AI Engineer の分類として Software 1.0（古典的プログラミング）、2.0（ML）、3.0（LLM）を整理した11。 Software 3.0 ではコンテキストウィンドウがプログラム、LLM がインタプリタとなる。 IMPACT フレームワーク（Intent, Model, Prompt, Agent, Chain, Tool）でエージェント設計の6構成要素を提案した。

デザインが設計構造の中心に位置する段階である。 Karpathy が taste と design を名指ししたことは、エージェントの出力品質がドメイン知識と判断基準に依存することの表明である。 「何を生成すべきか」「生成されたものの何が問題か」を判断する能力は、デザインの中核的職能と重なる。

Context Engineering：情報環境の設計

Lutke（Shopify CEO）が2025年6月に命名した語である12。

“The most important skill for the AI age, by far, is what I’ve started calling ‘context engineering’.”

Karpathy はこの語を即座に支持し、「prompt engineering → context engineering への移行は正当」と述べた13。 prompt engineering が単発の指示文を最適化する行為であるのに対し、context engineering は動的にコンテキストを組み立てるシステム全体の設計を指す。

Anthropic は技術定義を提示した14。 「context engineering とは、タスクが LLM によってもっともらしく解決可能になるために必要なすべてのコンテキストを提供する技術」であり、構成要素として system prompts、ユーザーメッセージ、ツール定義と結果、会話履歴、取得した知識（RAG）、構造化された出力ガイドラインを挙げた。 さらに context rot の概念を提示した。 コンテキストは時間とともに腐敗（rot）し、古い情報がエージェントの判断を歪める。

Chase（LangChain CEO）は「成功も失敗もコンテキスト次第。すべては context engineering だ」と述べた15。

Willison は「LLM は不安定なプラットフォームであり、context engineering は有用な成果物を引き出す条件を整える行為」と評価し、prompt engineering からの連続的な進化と位置づけた16。

NNg は context engineering の上位概念として context architecture を提案した17。 3層を区別する。 第1層は prompt engineering（単発の指示最適化）。 第2層は context engineering（動的なコンテキスト組み立て）。 第3層は context architecture（情報環境全体の設計）。 NNg は context architecture を「新しいデザイン分野」として位置づけた。

デザインの関与が構造的に求められる領域である。

第一に、デザインシステムのコンテキスト化がある。 Figma は Config 2026 で「デザインコンテキストなしで AI にコード生成を依頼することは、オンボーディング前に新人に本番コードを書かせるようなもの」と述べた18。 Google の DESIGN.md、Apple の App Intent Domains は、デザイン判断を宣言的にコンテキストに供給するアーキテクチャの実装である。 デザインシステムの成熟度がエージェント出力品質の上限を決める。

第二に、ユーザー意図のモデリングがある。 context engineering の成否はユーザーの意図をどこまで正確にコンテキストに変換できるかに依存する。 意図を理解し、エージェントが処理可能な形式に構造化する行為は、UX リサーチとインタラクションデザインの拡張である。

第三に、context rot への対処の設計がある。 コンテキストの鮮度管理、古い情報の検出と更新のタイミングは、情報アーキテクチャの問題である。

Harness Engineering：監視構造の設計

Anthropic が提唱した概念で、エージェントの実行を管理するフレームワーク（harness）の設計を指す19。

Anthropic はまず workflows と agents を区別した20。 workflows は LLM とツールを事前定義された制御フローで組み合わせるもの、agents は LLM が自らツール選択と次のステップを動的に決定するものである。 ほとんどのタスクには workflows で十分であり、agents は「意思決定の柔軟性がコスト増に見合う場合にのみ」使うべきだとした。

harness はこれらの上位に位置する。 「エージェントの複数セッションにわたる動作を管理するフレームワーク」であり、設計原則は次の一文に集約される。

“Every component of an agentic harness encodes an assumption about what the model can’t do on its own.”

harness の各部品は「モデルが自力でできないこと」についての仮定を体現している。 その仮定が正しい限り harness は機能し、モデルの能力が向上すれば harness の部品は外せる。

コストは高い。 マルチエージェント構成はトークン消費が15倍、harness のオーケストレーションはコストが20倍になるとの実測がある21。

Zhou et al.（2026）は学術側からこの領域を補強し、「中間確認が最適」という知見を報告した22。 確認なし（完全自律）でも毎ステップ確認（完全監視）でもなく、中間的な頻度の確認がタスク成功率と効率の均衡点である。 Chase の leash length（v0=short、Cursor=middle、Devin=long）にとって「どの長さが最適か」の定量的指針を与える知見である。

デザインの新しい職能領域を形成する。

第一に、監視構造の UX 設計がある。 エージェントが長時間自律的に動作するとき、人間にどのタイミングで何を報告し、どの粒度の判断を求めるかは UX の問題である。 Anthropic の実測で「ユーザーの93%が permission prompt を承認する」ことが分かり、per-action 承認は監視として機能しないと判断された23。 この結果、「境界内自由動作」モデルへ設計が変更された。 境界をどこに引くかは、技術的制約とユーザーの信頼モデルの両方を考慮する設計判断である。

第二に、委任インターフェースの設計がある。 ユーザーがエージェントに何をどこまで任せるかを設定し、その設定が適切かどうかを評価できるインターフェースはデザインの問題である。 「任せすぎ」と「介入しすぎ」の間の適切な均衡点を、ユーザーのスキルとタスクの性質に応じて動的に調整する仕組みが必要になる。

第三に、コスト構造がデザイン判断を制約する。 15倍のトークン消費、20倍のコストという実測は、「監視を手厚くするほどコストが上がる」というトレードオフを意味する。 どの監視を維持し、どの監視を省くかは、ビジネス制約の中での設計判断になる。

5段階の対照表

段階命名者(年)人間の責任ボトルネックデザインの関与
Vibe codingKarpathy (2025-02)なし（結果を受け入れる）作れるかどうか限定的（プロトタイプのみ）
Vibe engineeringWillison (2025-10)品質保証（テスト、レビュー）判断できるかどうか品質判断（タイポグラフィ、余白、一貫性）
Agentic engineeringKarpathy (2026-04)taste, design, 正確性, セキュリティ何が良いか判断できるか中心（taste と design が名指し）
Context engineeringLutke (2025-06)情報環境の構造化何をコンテキストにするか構造的（デザインシステム、意図モデリング、context rot）
Harness engineeringAnthropic監視構造と境界の設計どう監視するか新領域（監視UX、委任IF、コスト制約下の設計）

5段階を通じた一貫した方向がある。 vibe coding では「作れるかどうか」がボトルネックだが、段階が進むごとに「何を作るべきか」「出力は十分か」「どこまで任せるか」へ移行する。 AI がコードを生成する能力が向上するほど、判断と構造化が人間の側に残る職能になる。 この職能はデザインの中核と重なる。

ただし、この分析は産業側の言説に基づく。 agentic-experience-design-synthesis で整理したように、学術はジュニアの学習経路の喪失、探索の終局化、監視 UI の構造的限界を指摘しており、「デザインが関与すべき」という産業の主張が実際に機能するかは未検証である。

参照文献

Footnotes

  1. x.com/karpathy/status/1886192184808149383 (2025-02-02) ↩

  2. x.com/karpathy/status/2019137879310836075 (2026-02-04) ↩

  3. x.com/simonw/status/1975570458683834729 ↩

  4. simonwillison.net/2026/Apr/2/lennys-podcast/ ↩ ↩2

  5. medium.com/@addyosmani/vibe-coding-is-not-the-same-as-ai-assisted-engineering-3f81088d5b98 (2025-11-30) ↩ ↩2

  6. simonwillison.net/2025/Oct/7/vibe-engineering/ ↩

  7. [要一次検証: Osmani conductor → orchestrator 論考] ↩

  8. figma.com/blog/config-2026-recap/ (Config 2026 keynote) ↩

  9. Karpathy X 投稿 (2026-04) [要一次検証: 具体 URL] ↩

  10. [要一次検証] ↩

  11. [要一次検証] ↩

  12. Lutke X 投稿 (2025-06) [要一次検証] ↩

  13. [要一次検証] ↩

  14. [要一次検証: Anthropic context engineering docs] ↩

  15. [要一次検証] ↩

  16. [要一次検証] ↩

  17. NNg context architecture [要一次検証] ↩

  18. figma.com/blog/config-2026-recap/ ↩

  19. [要一次検証] ↩

  20. anthropic.com/research/building-effective-agents (2024-12) ↩

  21. Anthropic 実測。マルチエージェント15×トークン、harness 20×コスト ↩

  22. Zhou et al. (2026) [要一次検証: DOI] ↩

  23. Anthropic 実測。permission prompt 93%承認 ↩

← Notes 一覧 ・ ホーム