Andrej Karpathy氏が2025年2月に提唱した「バイブコーディング（vibe coding）」は、わずか1年でその呼び名が陳腐化しました。2026年2月、本人が「agentic engineering（エージェント工学）」への移行を宣言し、Claude Code（Opus 4.7・SWE-bench 87.6%）やCursor 3.0（Agents Window）など、エージェントが自律的にコードベースを読み解いて書き換える時代に入りました。では、製造業の設計OS内製化という現場でこの変化は何を意味するでしょうか。本記事は「速度・粗利・カスタム性」の3軸で、バイブコーディング・エージェント実装・受託フル外注の3つの選択肢を並列評価し、設計部DX担当・情シスがどの選択肢を、どの業務に当てるべきかを判断するための補助線を提示します。

課題の構造化——設計OS内製化が「速度の話」で終わらない理由

製造業の設計部や情シスが「AIで業務を変えたい」と動き出すとき、議論はほぼ必ず「内製でやるか／外注で頼むか」に流れます。そこに2025年以降、第3の選択肢としてバイブコーディング（自然言語で業務を記述し、LLMにコードを書かせる開発スタイル）が加わりました。Karpathy氏が「コードを書くのではなく、コードを感じる（give in to the vibes）」と表現したこのスタイルは、Collins英語辞典の2025年「Word of the Year」に選ばれるほど普及しました。

しかし、現場で設計OS内製化の検討を始めると、3つの観点が衝突します。第一に速度——試作はバイブコーディングが圧倒的に速く、Claude CodeやCursorで1〜2週間で動くものが出ます。第二に粗利——内製化のコスト構造は「サブスク料＋自社工数」と「外注費」で全く別物で、設計部の工数を年間どれだけ投下できるかで現実解が変わります。第三にカスタム性——図面検索や設計変更通知のように、PLMやERPでは扱いにくい業務こそが内製化の本命ですが、業務を深く適合させるには業務分解の精度が決定的に効きます。

このとき、3つの観点を1軸（たとえば「いかに速く立ち上げるか」）だけで判断すると、ほぼ確実に詰みます。バイブコーディングで2週間で動いたツールが、3か月後に保守する人がいなくて死蔵される。エージェント受託で半年かけて作った業務基盤が、業務側の言葉に寄り添えていなくて使われない。受託フル外注で1年かけて構築したら、当の業務がもう変わっていた——これらは2025年から2026年にかけて、製造業の設計部DX案件で実際に多発したパターンです。1軸での判断ではなく、3軸を同時に見て、業務の段階（試作・運用化・全社展開）ごとに勝てる選択肢を切り替えるという発想が必要です。

flowchart TB
    A["現場の業務課題
（図面検索・設計変更・DR）"] --> B{"既存PLM・ERP・
SaaSで解けるか？"}
    B -->|Yes| C["既存ツール導入で解決"]
    B -->|No| D{"バイブコーディングで
1〜2週で試作可能か？"}
    D -->|Yes| E["内製試作→社内検証→
効果出れば業務OSへ昇格"]
    D -->|No| F{"業務基盤として
3年運用に耐えるか？"}
    F -->|Yes| G["業務OS／個社別
エージェント受託"]
    F -->|No| H["業務を再分解
（人＋ツール再設計）"]
    classDef start fill:#1D4ED8,stroke:#1E3A8A,color:#FFFFFF,stroke-width:2px;
    classDef decision fill:#FEF3C7,stroke:#B45309,color:#1F2937,stroke-width:2px;
    classDef vibe fill:#DBEAFE,stroke:#1D4ED8,color:#1E3A8A,stroke-width:2px;
    classDef os fill:#D1FAE5,stroke:#065F46,color:#064E3B,stroke-width:2px;
    classDef fail fill:#FEE2E2,stroke:#B91C1C,color:#7F1D1D,stroke-width:2px;
    class A start;
    class B,D,F decision;
    class E vibe;
    class C,G os;
    class H fail;

本論——3軸評価で見える、設計OS内製化の現実解

軸1：速度——「立ち上げ速度」と「運用化までの速度」を切り分ける

2026年現在、設計業務を試作レベルで動かす速度は、バイブコーディングが圧倒的に速くなりました。Claude Code（Opus 4.7・コンテキスト100万トークン）やCursor 3.0のAgents Windowを使えば、図面ファイル名の整理ルール、設計変更通知の宛先振り分け、DR議事録の要約といった試作レベルなら、設計者本人が業務を語りながら1〜2週間で動くものを作れます。

ただし、ここで言う「速度」は立ち上げ速度であり、運用化までの速度とは別物です。試作はサンプル図面10枚で動いても、本番の数万枚で動かすには例外処理・権限制御・他システム連携・監査ログが要ります。この「最後の1マイル」は、バイブコーディングではなく、エージェント実装か受託の領域に切り替わります。速度を1つの数字で語らず、業務の段階ごとに違う指標で測る習慣が、内製化の判断ミスを減らします。

軸2：粗利——「自社工数を埋めるか／キャッシュを払うか」の構造比較

粗利の話は、経営層に向けて整理しないと議論がかみ合いません。バイブコーディングは「サブスク料＋自社工数」で動き、Claude CodeやCursorは月数十〜数百ドルの個人プランからMaxプランまで階層があります。一方、受託フル外注は「受託費の全額キャッシュアウト」で、初期費に数百万円〜1,500万円規模の稟議が必要です。エージェント実装は両者の中間で、内製＋外注の混合体制が多くなります。

気をつけたいのは、自社工数を「タダ」と見なすバイアスです。担当が月20時間を投下するなら年240時間、3年で数百万円規模の隠れコストになります。これを粗利計算から外すと、バイブコーディングが過大評価されます。逆に「触れる時間」を確保しなければ、いくらサブスクを契約しても価値は出ません。キャッシュとタイムの両方を可視化し、どちらの資源が御社で稀少かを先に決めるほうが意思決定が早く進みます。

軸3：カスタム性——業務分解の深さが効く領域、効かない領域

カスタム性は「業務にどれだけ深く寄せられるか」で測ります。バイブコーディングの強みは業務に詳しい人が直接コードに触れる点です。設計者本人が「ここはこう判定したい」と自然言語で指示し、エージェントが即座に書き換える。この往復は、外注を間に挟む受託モデルでは出ない速度で回り、試作期のカスタム性で勝てる理由になります。

一方、業務基盤として運用化する段階では、カスタム性は「業務分解の精度」に依存します。設計OSは図面・部品表・設計変更・DR・原価試算を横断統合する基盤で、個別ツールを後付けで貼り合わせる方式は破綻します。業務分解を1段深く下ろし、「人が握る判断」「エージェントに任せる定型処理」「自動化していい部分」を線引きする作業が必要です。この線引きが業務OSのコアで、試作物を束ねて昇格させるか、最初からエージェント実装で組むかの分岐点になります。

3軸の関係——設計OS内製化の段階別「勝てる選択肢」マップ

3軸を業務の段階（試作期・運用化期・全社展開期）に重ねると、どの選択肢が勝てるかのマップが描けます。試作期はバイブコーディングが速度・粗利・カスタム性のすべてで勝ち、運用化期はエージェント実装が運用耐久と業務適合の両立で勝ち、全社展開期は受託フル外注かパッケージ業務OSが保守責任の明確化で勝つ。重要なのは、すべての業務を同じ選択肢で揃えようとしないことです。図面検索のような3年以上残る業務は最初から運用化期の選択肢で組み、設計変更通知の振り分けルールのように業務ごとに微調整が必要な部分は試作期の選択肢で動かす、という使い分けが2026年現在の現実解です。

業務OSと個別ツールの関係——内製化の終着点をどこに置くか

もう一つ押さえたい論点は、内製化の終着点を「個別ツールの集合」に置くか「業務OS」に置くかです。試作したツールが10個並ぶ状態と、業務横断で1つの基盤に統合された状態では、3年後の運用負荷が桁違いに変わります。業務基盤は、データ層（PLM・ERP連携）・処理層（エージェント・LLM呼び出し）・業務インターフェース層の3層構造で考えるのが堅実で、バイブコーディングは「業務インターフェース層」の試作には強いものの、データ層と処理層の正規化には別の枠組み（エージェント実装か受託）が要ります。

過去記事でも繰り返し述べてきた、業務OSという業務基盤の考え方は、ここでも有効です。

ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であって、業務そのものを実行する仕組みではない

業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体

記録台帳と保管庫の間に、業務を実行する層が欠けているからこそ、設計者が日々の業務時間の多くを探索と転記に使う構造が温存されてきました。バイブコーディングはこの「欠けている層」の試作に対しては鋭い手段ですが、長期運用するには業務OSの設計思想で組み直す必要があります。

もう一つ、内製と外注の境界を決めるうえで参考になるのが、直近の関連記事です。

「現場発のAI内製依頼」を全部やる／全部止めるの二択で捌くと、シャドーAI繁殖か業務停滞のどちらかが起きる

内製と外注の境界線——設計OS構築で「自社で握るべき層」「任せていい層」を分ける3つの軸

バイブコーディングは「全部やる」側に過大に振れがちな手段で、業務を握る基準を持たずに導入すると、シャドーAI（業務に潜り込んだ非公式ツール）の温床になります。「握るべき業務」と「任せていい業務」を線引きしたうえで、その線引きの内側でバイブコーディングを試作手段として使うのが安全です。

そして、設計OS内製化の議論は最終的には「業務をフロー図で書ける人がいるか」「業務とコードの両方を読める人を社内に育てられるか」に収束します。設計DRが形骸化している現場ほど、業務の構造が文書化されていないため、バイブコーディングで試作しても業務分解の浅さがそのままアウトプットに出ます。

DRは本来の「設計品質を上流で確定させる場」から「形式上やっておく会議」に変質

設計DRが形骸化する5つの理由と、AIエージェントで補える部分・補えない部分

業務の構造が薄いままバイブコーディングを試作の主軸に据えると、3か月後に「動くけれど使われないツール群」が残ります。業務分解の地力を上げる活動と並行して試作を進めるのが、長期で見たときの近道です。

ROI試算の考え方——3軸を金額に翻訳する

ROI試算は、3軸それぞれを金額に翻訳して足し合わせる発想で行います。速度はキャッシュフローのタイミング差、粗利は3年累計のキャッシュアウトとタイム投下の合計、カスタム性は業務改善効果の幅（工数削減・品質改善・売上機会増）で換算します。3軸を別々に積算した後に、選択肢が3年運用に耐えるかという「運用耐久係数」を最後にかける点が重要です。試作レベルの選択肢に過大なROIを期待し、3年運用前提のキャッシュフロー計算をすると、現実から大きく乖離します。

反論への先回り——「Claude CodeやCursorで全部書ける時代では？」

「2026年のClaude Code（Opus 4.7・SWE-bench 87.6%）やCursor 3.0なら、設計部の業務はもう全部内製で書けるのでは？」という反論をよくいただきます。Karpathy氏も「自分のコードの80%以上はエージェントが書いている（2025年12月時点）」と述べているとおり、コードを書く速度は劇的に上がりました。

ただし、設計OS内製化の本当のボトルネックは、コードの書き出し速度ではなく業務分解の質と、業務を握る人材の育成速度です。コードが速く書けても、「何を作るべきか」を業務側が言語化できないと、エージェントは間違った業務を高速に実装します。図面・部品表・設計変更通知・DR・原価試算といった抽象度の高い概念が絡み合う設計部の業務では、フロー図で書き下ろせる人がいない現場ではClaude CodeもCursorも投資効果が出ません。

もう一つは運用責任の所在です。試作ツールが本番で動くと例外処理・障害対応・データ整合性確認の負荷が発生し、個人が試作したツールはその個人の異動・退職で保守不能になります。3年以上運用したい業務は、最初から業務OS・エージェント実装・受託の保守契約のいずれかで責任所在を明確にするのが長期最小コストです。バイブコーディングを否定する話ではなく使う場所を選ぶという話です。

自己診断ミニチェックリスト——あなたの設計OSはどの選択肢が向くか

• □ 今、解きたい業務課題は「試しながら寄せていきたい」段階だ（バイブコーディングが向きやすい）
• □ 業務に詳しい人がコードに触れる時間を、月20時間以上確保できる（内製の前提条件）
• □ 3年後も同じ業務が残っている自信がある（業務基盤として組むべき）
• □ 設計部・調達部・品質部の業務をまたぐ連携が必要だ（業務OS／エージェント受託の領域）
• □ 失敗しても業務が止まらない範囲で試作できる（バイブコーディングの安全圏）

3つ以上当てはまる場合は、バイブコーディングで試作→効果検証→業務OS／エージェント実装へ昇格する2段構えが現実的な進め方です。0〜2個の場合は、業務分解を先にやらないと、どの選択肢を選んでも投資効果が出にくくなります。

FAQ

Q1. バイブコーディングは「コードが書けない人」でも本当に使えますか？

A. 2025年から2026年にかけてClaude CodeやCursorのエージェント機能が成熟したことで、業務を分解できる人なら、コードを「読める」段階で実装まで進められるようになりました。ただし「読めない／レビューできない」状態で動かすと、後工程の保守で詰みます。最低限「自社業務をフロー図で書ける」「ログを見て挙動を判断できる」レベルは必要です。

Q2. バイブコーディングで作ったツールを業務OSに昇格させる手順は？

A. 試作で「使い続ける価値があるか」を3か月運用で測り、(1) 業務フローを文書化、(2) データ層をPLMやERPと正規の連携にし、(3) 例外処理と監査ログを整える、の3点を満たした段階でエージェント実装か受託に移します。試作のままスケールさせると、保守責任が個人に偏在して属人化します。

Q3. 設計部の業務でバイブコーディングが向かない業務はどれですか？

A. (a) 図面検索・部品表メンテのような「3年以上同じ業務が残る基幹業務」、(b) ECN（設計変更通知）や品質情報のように「データの正確性が担保されないと後工程が止まる業務」、(c) DR資料作成のように「複数部署のレビューを通る業務」は、最初から業務OSかエージェント実装の領域として設計したほうが安全です。

Q4. Karpathyが「バイブコーディングは陳腐化した」と言いましたが、もう手段として古いのですか？

A. Karpathy氏が2026年2月に「agentic engineering」という呼び名に切り替えたのは、エージェント側がプロジェクト全体を読み解いて自律的にコードを書く時代になったから、という意味です。「自然言語で業務を書き、エージェントが実装する」という基本動作はむしろ強化されています。製造業の業務内製化の文脈では、呼び名よりも「業務を分解できる人がいるか」が引き続き勝敗を分けます。

関連記事

• 内製と外注の境界線——設計OS構築で「自社で握るべき層」「任せていい層」を分ける3つの軸：本記事の「3軸評価」と表裏一体の意思決定フレーム。投資判断を稟議に乗せる前に読む
• 設計エージェントの実装アーキテクチャ——RAG・MCP・社内データ連携の現実解：バイブコーディングから昇格させた業務を、運用化期の実装パターンに落とし込む技術詳細
• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体：業務OSという業務基盤の概念を最初に押さえたい場合の参照ハブ

次のアクション

設計OS内製化の方針を、御社の業務分解状況と人材リソースに合わせて切り分けたい場合は、30分の業務分解レビュー（無料）をご利用いただけます。「バイブコーディングで試作すべき業務」「エージェント実装で運用化すべき業務」「受託で外に出すべき業務」を御社固有の文脈で判定し、3か月後・1年後の人員配置と投資額のシミュレーションまでをセットでご提示します。