[🤖] 骨と肉に刻まれていく開発パラダイム転換

✨ GPT-5.5の要約 　

面接で体感した開発者役割の変化から、バイブコーディングの限界とハーネスエンジニアリングの必要性まで、AI時代の核心能力が手作業のコーディングから企画、設計、実行、フィードバック、文脈判断へ移っていることを整理した記録。

体に刺さってきたパラダイム転換

面接で刺さった結論

今日の面接で一番強く残ったのは、開発者に必要な能力の中心が、手でコードを書く力から企画/設計/実行/フィードバック能力へ移っているということだった。

そこに、全体の文脈を読むための概念、ドメイン知識、直感も必要になる。ただ「AIを使えます」では足りない。

ずっと積もっていた感覚

この感覚は急に出てきたものではない。

GPT, o3, AGI, Humanoids… the Singularity Is Coming…では、GPTを外部脳のように感じる衝撃を記録した。

A Shift in the Development Paradigmでは、開発プロセスの一部がコーディング労働からAI APIを使った「クリック」へ移っていると見ていた。ただし当時は、context windowやoutput tokenの限界から、せいぜい簡単なMVPだとも書いた。

つまりバイブコーディングの限界を今になって発見したわけではない。最初から限界は見えていた。ただ、その境界線が異常な速度で後ろへ押されている。

Survival Guidelines for the AI EraではAIリテラシー、文脈的知性、人間の判断領域をつかもうとした。

The Level of VSCode Copilot AI Autocompleteでは、AIに企画意図をコメントで渡し、生成された構造を読み、適用を許可する形が現実になった。

Stopping the Flutter Course and Switching to a Vibe-Coding Businessでは、さらに露骨にバイブコーディングという新しいパラダイムが来たと書いた。

今年の Whether Claude Code or Codex, It Is a Garbage-Tier, Oblivious Genius. では、問題がもっとはっきりした。AIがコードを書けるかどうかではない。この空気を読まない天才たちをどう止め、どう検証ループの中に閉じ込めるかが問題だった。

就職市場の言葉として返ってきた変化

その流れが今日、就職市場の言葉として返ってきた。いま開発者には、事業家的な感覚を伴う企画、設計、実行、フィードバック能力が求められている。

月500万ウォン以上もらっていた開発者より生産性は高くなったのに、受け取る給料は……はあ。悲しい。

だからこれは頭だけで理解した変化ではない。だんだん体で食らっているパラダイム転換だ。

コーディングの時代は終わった

手でコードを書く力は中心ではない

少し荒く言えば、いまやコーディング能力そのものは以前ほど重要ではない。

もちろんC言語、アセンブリ、機械語を学べばシステム構造の理解には役立つ。コーディング知識が無価値になるわけではない。

ただし市場がより大きく求める能力は、もう「自分の手で実装できるか」ではない。

かつてPythonで多くの反復作業が解ける時代が来た。今はAIで多くの実装問題が解ける時代へ移っている。

抽象化の歴史は繰り返す

The Chicken Game Over Humanity’s Fate After the AI Boomで、私は技術発展をこんなふうに並べた。

• ついに火を作った！うれしい。（約50万年前）
• ついに電気を作った！うれしい。（1880年代）
• ついにコンピュータを作った！うれしい。（1940年代）
• ついに人工知能を作った！うれしい。（2010年代）
• ついに汎用人工知能を作った！うれしい。（2030年代と予想……？）
• ついに超知能を作った！うれしい。（2050年代……？）

開発も似ている。

• 電灯スイッチをクリック。（1880年代）
• 機械語クリック。（1940年代）
• アセンブリクリック。（1940〜1950年代）
• C言語クリック。（1970年代）
• Pythonクリック。（1990年代）
• フレームワーククリック。（2000〜2010年代）
• AIクリック。（2020年代）
• ハーネスクリック。（2020年代半ば〜）

冗談のようだが、結局これは抽象化の歴史だ。

人間は下の階層を機械へ渡し続けてきた。下の階層を知らない人は毎回不安だったし、下を触れる能力も一定程度は重要だった。しかし市場の中心は結局上へ上がった。

「コーディング能力など重要ではない」と言いたいのは、何も知らなくていいという意味ではない。コーディング能力が開発の中心から押し出されているという意味だ。

評価基準も変わる

いま揺れているのは道具一つではなく、開発という仕事のパラダイムそのものだ。

古いパラダイムでは、よい開発者は自分でコードをうまく書いて問題を解いた。新しいパラダイムでは、AIがコードを作り、人間は問題を定義し、文脈を与え、実行環境を設計し、結果を検証する。

だからこの変化は「コードを書く速度が上がった」で終わらない。何を学ぶべきか、どんな人を採用すべきか、どんな教育が有効かまで揺らす。

業界も同じ方向を見ている

バイブコーディング

バイブコーディングは、自然言語で意図をAIに投げ、コードは必要な分だけ見て、実行結果を見ながらまた言葉で直す開発方式に近い。

アンドレイ・カパシーがこの言葉を使ったときの核心も、人がコードと直接格闘する時間が減り、自然言語の意図からモデルが実装を進める感覚だった。¹

彼のSoftware 3.0論も同じ方向だ。自然言語が新しいプログラミングインターフェースになり、モデルが実装の大部分を担う。²

有名人たちも同じことを言っている

これはカパシーだけの話ではない。

• NVIDIA CEOのジェンスン・フアンは、人間の言語そのものが新しいプログラミング言語になったと語った。³
• Meta CEOのマーク・ザッカーバーグは、2025年には中級エンジニア級にコードを書くAIを持つことになると語った。⁴
• Anthropic CEOのダリオ・アモデイは、AIがまもなくコードの90%を書き、さらに進めばほぼすべてを書けるという強い予測を出した。⁵
• Microsoft CEOのサティア・ナデラは、SaaSのビジネスロジックがAIエージェント層へ移ると既存アプリのあり方が揺らぐと見た。⁶
• GitHub CEOのトーマス・ドームケは、開発者の役割がコード入力から委任と検証へ移っていると整理した。⁷

OpenAIもCodexを単なるコーディングモデルではなく、ソフトウェアエンジニアリングエージェントとして押し出している。⁸⁹

コーディング文法学習の時代は終わった

基礎はまだ意味がある。C、アセンブリ、資料構造、ネットワーク、OSを知れば、AIが出した結果をよりよく判断できる。

しかし「文法を覚えれば就職できる」という式のコーディング講座は、時代をかなり外している。

いま必要なのは、AIが作った実装を見てこう言える能力だ。

• 「方向が違う」
• 「ここでユーザーフローが壊れる」
• 「この構造は後で保守で爆発する」
• 「今必要なのは機能追加ではなく問題定義だ」

バイブコーディングは入口にすぎない

コードは出るが、まだ製品ではない

小さなプロトタイプでは、バイブコーディングは魔法のように見える。言えば画面ができ、APIがつき、データが流れ、ボタンが動く。

しかしアプリが少し大きくなると、「それっぽく動くコード」と「継続して運用できる構造」はまったく別物になる。

• 要件が途中で変わる。
• 例外ケースが出る。
• 権限とデータフローが絡まる。
• UIは動くが製品意図とズレる。
• テストがなく、直すほど別の場所が壊れる。
• AIが前のターンで作った構造を忘れる。

文脈と権限がなければ事故になる

AIがルールを落としたときはもっと危ない。

• 開発DBだと思って本番DBを消す。
• テストアカウントだけ消すつもりで実ユーザーデータを削除する。
• バックアップなしで破壊的クエリを走らせる。
• 権限ポリシーを単純化してprivateデータをpublicに開く。
• ビルドを通すために検証コードを消す。

AIが悪いという話ではない。文脈、権限境界、検証が弱いと、その方向へ滑りやすいという話だ。

だからコンピュータ知識の少ない非開発者が不用意に触ると、最初は「動く」と感じても、結局文脈の限界にぶつかる。

フィードバックは感情の排泄ではなく照準だ

もちろん、ときどき最初に「いや、俺が言ったのはそれかよ」と出てくる。しかしそれをそのまま投げるのは自分にもよくない。

罵倒が常にモデル性能を落とすと断定する根拠はないが、プロンプトのトーンや感情フレーミングが出力に影響するという研究はある。¹⁰¹¹

結局問題はAIの気分ではなく自分の理性だ。怒りを投げ続けると、自分がより感情的になり、指示が曖昧になり、ストレスだけが積もる。

本当の限界は実装ではなく文脈だ

Anthropicの長時間エージェント記事も同じ地点を指す。高水準プロンプトだけではproduction-qualityアプリには届きにくく、作業分解、持続メモリ、文脈管理、検証ループが必要だ。¹²

バイブコーディングの本当の限界はコードを作れないことではない。コードは作る。むしろ作りすぎるほど作る。

限界は、そのコードが何のためにあり、どこまで変えてよく、どんな基準を通るべきで、どの文脈を壊してはいけないのかを、AIだけで安定して握り続けることが難しい点にある。

だから企業はバイブコーディングの限界をハーネスで捕まえようとしている。

だからハーネスが本番だ

ハーネスはモデル周辺の実行構造だ

ハーネスはもともと、力のある対象をつかまえて望む方向へ使うための装具、ベルト、リードのようなものだ。

プロンプトエンジニアリングが一回の会話で何をどう言うかだとすれば、ハーネスエンジニアリングはモデル周辺の実行環境全体を設計する仕事だ。

LangChainはエージェントをModel + Harnessと説明し、ハーネスが状態、ツール実行、フィードバックループ、強制可能な制約を提供すると整理する。¹³

Martin Fowlerも、コーディングエージェントをより少ない監視で使うには、feedforwardとfeedback sensorを備えたハーネスが必要だと書く。¹⁴

OpenAIのCodexハーネス記事でも、ボトルネックはコード生産ではなく人間が検査できる量だった。そこでログ、メトリクス、ブラウザ操作、構造的テストをエージェントに見せる方向へ進んだ。¹⁵

重要なのは、どのモデルがコードをうまく書くかだけではない。どの文脈を渡し、どの道具を開き、どの権限を止め、どのテストを必須にし、どこで人間が介入するかだ。

ハーネス構造が競争力になる

Claude Codeのソースコード流出が騒がれた理由もそこにある。流出したのは単なるプロンプト一行ではなく、文脈の組み立て、ツールとガードレール、ユーザー指示とシステム指示を扱う構造に近かった。¹⁶¹⁷

モデル性能だけが重要なら、それは小さな見物で終わったはずだ。しかし実際には大きな話題になった。いまやハーネス構造そのものが製品競争力だ。

強いモデルほど強いハーネスが必要だ

MythosとProject Glasswingは、同じ流れをセキュリティ側でさらに強く示す。

MythosはAnthropicの未公開フロンティアモデルで、脆弱性を見つけるだけでなく攻撃コード、つまりexploitまで構成できる能力を持つ。AnthropicはClaude Mythos Previewが主要OSやブラウザで多数の高リスク脆弱性を見つけたと説明した。¹⁸

Project Glasswingは、そのような強力なモデルをそのまま公開した場合の衝撃を防ぐため、AWS、Apple、Google、Microsoft、NVIDIA、CrowdStrikeなどのパートナーへ限定的に開いた防御プロジェクトに近い。¹⁸

Axiosは、Mythosが公開済み脆弱性情報から数時間で動作するexploitを作り、Windows kernel脆弱性のproof-of-conceptを31分で作ったと報じた。¹⁹

この程度のモデルを普通にばらまけば大事故になりうる。誰がアクセスでき、どのコードをスキャンでき、結果をどう公開し、パッチを誰が検証し、攻撃コード生成をどこで止めるのかまで、全部ハーネスで縛らなければならない。

弱いハーネスはモデルをつかまえられない

AI Studio系のハーネスが私にとってもどかしいのもここだ。

もちろんAI Studioが無価値という意味ではない。GoogleもAI Studio Build modeを、Gemini機能を試しながら自然言語で素早くアプリを作る道具として説明している。²⁰

ただ、運用できるソフトウェアを継続的に直していくハーネスは別問題だ。repo、terminal、IDE、diff、test、review、deployment log、permission boundaryが必要になる。Googleが別途Gemini CLIやGemini Code Assistを押しているのもその差を示す。²¹²²

チャット欄、実行ボタン、モデル選択はあるのに、作業範囲、権限境界、rollback、test、review、source of truth、長期文脈管理が弱ければ、良い開発ハーネスとは言いにくい。

モデルがどれほど優れていても、つけるリードが弱ければ、モデルはいつかリードを引きちぎって暴走する。

人間は企画/設計/実行/フィードバックを担う

結局、核心はAIクリックではない。どれほど精密なシステムを企画し、設計し、実行させ、フィードバックするかだ。

人間に残る能力は、手で大量にコードを書く力ではない。何を作るかを企画し、AIが動く場を設計し、実際に動かし、結果にフィードバックをかけて方向を戻す力だ。

そのためには全体の文脈を読む概念とドメイン知識、そして違和感をすばやく感じる直感が必要になる。

結局、波に乗るしかない

ここでいきなり「だからAIの波に乗ろう」と終わると飛躍になる。怖い問題を全部飛ばして楽観に包むだけになる。

言いたいのは、AI時代が来たから楽しいという話ではない。手作業コーディングの価値が下がり、AIが実装を持っていき、人間には企画/設計/実行/フィードバックの責任がより大きく残る流れは、嫌だと言って止められるものではないということだ。

選択肢はだいたい二つだ。

• 古いコーディング学習と文法暗記に集中して取り残される。
• それともAIにコーディングを任せ、プロンプトを磨き、さらにハーネスを設計し、AIリテラシーを育てて生き残る。

私はもう後者しかないと確信している。

波に乗るとは、ただ楽しいという意味ではない。津波のような巨大な波に無防備に飲まれないために、先に乗って方向を取り、姿勢を保つという意味に近い。

参考資料

1. Andrej Karpathy, X post, 2025-02-02. https://x.com/karpathy/status/1886192184808149383 ↩

2. Y Combinator, Karpathy lecture, 2025. https://www.ycombinator.com/library/MW-andrej-karpathy-software-is-changing-again ↩

3. Business Insider, Jensen Huang interview coverage, 2025-06-09. https://www.businessinsider.com/nvidia-ceo-jensen-huang-ai-prompts-human-lets-anyone-program-2025-6 ↩

4. ITPro, Mark Zuckerberg interview coverage, 2025-01-14. https://www.itpro.com/software/development/a-sign-of-things-to-come-in-software-development-mark-zuckerberg-says-ai-will-be-doing-the-work-of-mid-level-engineers-this-year-and-hes-not-the-only-big-tech-exec-predicting-the-end-of-the-profession ↩

5. Skeptics Stack Exchange, 2025-09. https://skeptics.stackexchange.com/questions/59213/as-at-september-2025-is-ai-not-writing-90-of-code ↩

6. CX Today, Satya Nadella interview summary, 2024-12-23. https://www.cxtoday.com/customer-analytics-intelligence/microsoft-ceo-ai-agents-will-transform-saas-as-we-know-it/ ↩

7. Thomas Dohmke and Irini Kalliavakou, “Developers, Reinvented”, 2025-08-03. https://ashtom.github.io/developers-reinvented ↩

8. OpenAI, “Codex is now generally available”, 2025-10-06. https://openai.com/index/codex-now-generally-available/ ↩

9. OpenAI, “Introducing GPT-5.2-Codex”, 2025-12. https://openai.com/index/introducing-gpt-5-2-codex/ ↩

10. Ziqi Yin et al., “Should We Respect LLMs?”, arXiv, 2024-02-22. https://arxiv.org/abs/2402.14531 ↩

11. Cheng Li et al., “Large Language Models Understand and Can be Enhanced by Emotional Stimuli”, arXiv, 2023-07-14. https://arxiv.org/abs/2307.11760 ↩

12. Anthropic, “Effective harnesses for long-running agents”, 2025-11. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩

13. LangChain, “The Anatomy of an Agent Harness”, 2026. https://www.langchain.com/blog/the-anatomy-of-an-agent-harness ↩

14. Martin Fowler, “Harness engineering for coding agent users”, 2026-04-02. https://martinfowler.com/articles/harness-engineering.html ↩

15. Ryan Lopfolo, “Harness engineering”, OpenAI, 2026-02-11. https://openai.com/index/harness-engineering/ ↩

16. Varonis Threat Labs, “A Look Inside Claude’s Leaked AI Coding Agent”, 2026-04-03. https://www.varonis.com/blog/claude-code-leak ↩

17. Drew Breunig, “How Claude Code Builds a System Prompt”, 2026-04-04. https://www.dbreunig.com/2026/04/04/how-claude-code-builds-a-system-prompt.html ↩

18. Anthropic, “Project Glasswing”, 2026-04-07. https://www.anthropic.com/glasswing ↩ ↩²

19. Axios, 2026-06-08. https://www.axios.com/2026/06/08/exclusive-anthropics-mythos-can-exploit-new-flaws-in-hours ↩

20. Google AI for Developers, “Build apps in Google AI Studio”, 2026. https://ai.google.dev/gemini-api/docs/aistudio-build-mode ↩

21. Google, “Gemini CLI”, 2025-06-25. https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemini-cli-open-source-ai-agent/ ↩

22. Google for Developers, “Code with Gemini Code Assist”, 2026. https://developers.google.com/gemini-code-assist/docs/write-code-gemini ↩