ここに投稿した記事です。

https://t.co/rDustxtCsH
— 𝙎𝙝𝙞𝙣𝙜𝙤 真吾 (@yoshidashingo) 2026年2月12日

Werner Vogels 最後のキーノート

www.youtube.com

AWS re:Invent 2025 - Keynote with Dr. Werner Vogels

2025年12月、ラスベガス。Amazon CTOのヴァーナー・ボーガス博士が、14年間続けてきたキーノートの最終回の登壇をおこないました。

キーノートのタイトルは "With Echoes of Evolution and Innovation"。進化と革新のこだま。このタイトルが示すように、ボーガス博士の講演は過去と未来を往復しながら、一つの問いに収斂していきました ── AIが開発者の仕事を奪うのか？

その問いに対するボーガス博士の答えは、端的でした。

...maybe

「たぶん」── この一語の中に、ボーガス博士はある種の厳しさと、それ以上の希望を込めました。タスクは自動化されます。スキルは陳腐化します。しかし適応する者は、かつてないほどの力を手にします。その適応のあり方をボーガス博士は「ルネサンス・デベロッパー（Renaissance Developer）」と名付けました。

本論考では、この「ルネサンス・デベロッパー」という概念を、美術史における様式の転換 ── とりわけバロックから古典主義への移行 ── というアナロジーを通じて読み解きます。現在のAI開発エコシステムに満ちる華美な狂騒をバロック的状況と捉え、Vibe Codingに見られる「理性の放棄」を宗教的態度と重ね合わせ、スペック駆動開発やAI-DLCのような方法論的規律を古典主義的秩序として位置づけたうえで、ボーガス博士が提唱する「ルネサンス・デベロッパー」が指し示す人間中心主義の本質に迫りたいと思います。

ルネサンス・デベロッパーとは

ボーガス博士は、宇宙旅行、AI、ロボット工学などが同時に進化し、相互に加速し合っている現状を、暗黒時代の後に訪れた「ルネサンス（再生）」の時代に重ね合わせています。

私たちは再びルネサンスの時代にあり、あなた方は『新しいルネサンスの開発者(ルネサンス・デベロッパー)』なのです。

歴史上のルネサンス期の科学者たちが持っていた資質（好奇心、常識への疑問、広範な学習、分野間の架け橋となること、大胆な実験）は、今日でも同様に関連性があるとし、これらをルネサンス・デベロッパーの5つの要素というフレームワークにまとめました。→後述

暗黒の時代(バロック) ∽ 現在のAIエコシステム

バロックとは何か

17世紀ヨーロッパを席巻したバロック芸術は、その語源からして過剰さを内包しています。ポルトガル語の "barroco"（歪んだ真珠）に由来するとされるこの言葉は、後世の批評家たちが「不規則で奇怪な」様式を揶揄するために用いたものでした。

バロック芸術の特徴は明瞭です。装飾の過多、劇的な光と影のコントラスト（テネブリズム）、感情に強く訴える表現、そして圧倒的なスケール感。ルネサンス期の均衡ある構成や静穏な美とは対照的に、バロックは意図的にバランスを崩し、動的でダイナミックな表現を追求しました。

重要なのは、この様式が自然発生的に生まれたのではなく、明確な目的を持っていたということです。カトリック教会は対抗宗教改革（Counter-Reformation）において、プロテスタントに奪われた信者を取り戻すために、感覚に強く訴える芸術を必要としていました。バロック芸術は、理性的な説得ではなく感情的な圧倒によって、人々を信仰へと導く装置として機能しました。

現代AIエコシステムのバロック的様相

2024年から2025年にかけてのAIエコシステムを見渡すと、このバロック的な過剰さとの構造的類似性に気づかされます。

華美なデモと現実の乖離。 カンファレンスのステージでは、AIエージェントが複雑なタスクを自律的にこなす華麗なデモンストレーションが次々と披露されます。光り輝くプレゼンテーション、圧倒的なベンチマーク数値、革命的な未来のビジョン。しかしその舞台裏では、プロダクション品質のシステムを実現するために必要な地道なエンジニアリング ── エラーハンドリング、エッジケースの処理、可観測性の確保、セキュリティの検証 ── は、しばしば闇の中に沈んでいます。バロック絵画のテネブリズムと同じように、成功事例だけが劇的に照らし出され、失敗と苦闘は深い影に隠されます。

エージェントの洪水。 AWS re:Invent 2025自体が、このバロック的状況の縮図でした。Stack Overflow Blogの記事は、このカンファレンスを的確に要約しています ── "the news was agents, but the focus was developers"（ニュースはエージェントだったが、焦点は開発者だった）。開発者エージェント、セキュリティエージェント、DevOpsエージェント。各社が競うようにエージェントを発表し、企業のリーダーたちは「AIによって労働力の30%を削減する」方法を模索していました。それは、バロック期の宮廷が互いの壮麗さを競い合った状況を彷彿とさせます。

派手さが構造的安定性に優先する。 バロック芸術がルネサンスの均衡を意図的に崩したように、AIエコシステムにおいても「インパクト」が「堅牢性」に優先する力学が働いています。印象的なデモ、急速なプロトタイプ、衝撃的なベンチマーク。しかし、ルネサンス建築の数学的均衡が数世紀を経ても揺るがないのに対し、バロック的な劇的効果は見る者を瞬間的に圧倒するものの、持続的な構造を約束するものではありません。

このバロック的状況の中で、ボーガス博士は新聞を配りました。テクノロジーの祭典において、最も古いメディアを選ぶことによって。

神頼みのVibe Coding

Vibe Codingの誕生

2025年2月、OpenAIの共同創業者でありTeslaの元AI責任者であるAndrej Karpathyが、一つの造語をX（旧Twitter）に投稿しました。

Andrej Karpathy @karpathy · 2025年2月3日

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. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper

「Vibeに完全に身を委ね、指数関数的な成長を受け入れ、コードが存在することすら忘れる」── Karpathy自身は個人プロジェクトの文脈でこの言葉を使いましたが、この概念は急速に広がり、Collins英語辞典の2025年Word of the Yearに選ばれるまでに至りました。Karpathyは自らの実践をこう描写しています ── 「プロジェクトやWebアプリを作っているが、本当の意味でのコーディングではない。ただ見て、話して、実行して、コピーペーストするだけで、だいたいうまくいく」。

Vibe Codingと暗黒時代の宗教的態度の同型性

暗黒時代のカトリック教会は、プロテスタントの合理的・聖書主義的アプローチに対抗するために、感覚と感情に直接訴えかける芸術を武器としました。カラヴァッジョの劇的な明暗法、ベルニーニの恍惚とした彫刻、バロック教会の圧倒的な内装 ── これらはすべて、理性的理解を迂回して、感情的体験を通じて信仰へと導くための装置でした。

信者に求められたのは、教義の精緻な理解ではありませんでした。圧倒的な美の前にひざまずき、自らを委ねること。理解するのではなく、信じること。

Vibe Codingの実践を仔細に検討すると、この宗教的態度との構造的な同型性が浮かび上がります。

理解なき委任。 バロック期の信者が教義の理解を聖職者に委ねたように、Vibe Coderはコードの理解をLLMに委ねます。生成されたコードの内部構造を精査することなく、「だいたいうまくいく」ことを確認し、次のプロンプトへ進みます。コードが存在することすら忘れるとKarpathyは言います。それは、宗教建築の構造力学を理解せずに、その壮麗さに感動する信者の姿と重なります。

検証なき信頼。 「AIが生成したのだから正しいだろう」という暗黙の前提。これは、「聖なるものが示したのだから正しい」という信仰的態度と同じ認知構造を持ちます。どちらも、出力の正当性を検証する責任を、自分ではない何か（LLM、あるいは神）に外部化しています。

ガチャでSSRを願う態度。 Vibe Codingの本質は、コードの生成過程を制御するのではなく、結果の「出来」を願うところにあります。プロンプトを書き、実行し、結果を確認し、うまくいかなければまたプロンプトを書きます。そのプロセスは、祈りを捧げ、結果を待ち、叶わなければまた祈るという構造と驚くほど似ています。

ボーガス博士の警告

ボーガス博士は、このVibe Codingに対して明確な警告を発しました。

"Vibe coding is fine, but only if you pay close attention to what is being built."

"We can't just pull a lever on your IDE and hope that something good comes out. That's not software engineering. That's gambling."

「レバーを引いて、いいものが出てくることを願う。それはソフトウェアエンジニアリングではない。ギャンブルだ」── この一節は、宗教的態度への風刺として読むこともできます。願い（hope）、出来栄え（something good）、偶然性（gambling）。エンジニアリングが本来持つべき「因果関係の制御」が、ここでは完全に放棄されています。

さらにボーガス博士は、AIの出力について辛辣な表現を用いています。

"If you put garbage in, you get really convincing garbage out."

「ゴミを入れれば、説得力のあるゴミが出てくる」── これもまたバロック的な概念と響き合います。バロック芸術の本質は、内容の真実性ではなく、表現の説得力にありました。カラヴァッジョが描くホロフェルネスの斬首は、解剖学的な正確さよりも感情的なインパクトを優先しました。同様に、LLMが生成するコードは、論理的な正確さよりも「もっともらしさ」を最適化する傾向があります。

Verification Debt ── 新たな技術的負債

ボーガス博士はこの問題を「Verification Debt（検証負債）」という新概念で定式化しました。

従来の技術的負債（Technical Debt）が、時間的制約のもとで意図的に行われた設計上の妥協の蓄積であるのに対し、検証負債はより深刻な問題を孕んでいます。AIがコードを生成する速度が人間の理解速度を超えることで、検証されないままのコードが本番環境に到達します。技術的負債は「理解した上での妥協」ですが、検証負債は「理解しないまま蓄積される負債」です。

この非対称性こそが、Vibe Codingの宗教的側面の核心です。信仰が理性の代替として機能するとき、蓄積されるのは「知っていて先送りした問題」ではなく、「そもそも何が問題なのかわからないまま積み上がった構造」です。それは、バロック教会の壮麗な外観の裏側で、誰も検査していない構造的な脆弱性が蓄積されていくようなものです。

古典主義の規律 ── スペック駆動開発とエージェントハーネス

新古典主義 ── バロックへの理性的反動

18世紀後半、ヨーロッパの知的世界は一つの転換点を迎えました。ドイツの美術史家ヨハン・ヨアヒム・ヴィンケルマン（Johann Joachim Winckelmann）が古代ギリシャ美術に関する著作を発表し、その核心的な美学を一文で要約しました ── 「高貴なる単純さと静穏なる偉大さ（edle Einfalt und stille Größe）」。

この言葉は、バロックとロココの装飾過多に対する明確なアンチテーゼでした。新古典主義は、啓蒙思想と深く共鳴しながら、感情と感覚に訴えるバロック的アプローチを退け、理性・秩序・普遍的価値の追求へと舵を切りました。重要なのは、新古典主義が単に「装飾を減らした」のではなく、「形式（フォーム）によって内容を規律する」という原理を確立したことです。

建築において、新古典主義は古代ギリシャの列柱様式を復活させました。それは単なる意匠の模倣ではなく、数学的比例に基づく構造的合理性の回復でした。柱の太さと高さの比率、柱間の距離、ペディメントの角度 ── すべてが計算され、すべてが理由を持っていました。

仕様駆動開発(Spec-driven Development) ── 現代のSDLCにおける古典主義的な規律による統制

AWS re:Invent 2025で、ボーガス博士はKiro IDEを紹介しました。KiroチームのシニアプリンシパルデベロッパーであるClare Liguori（クレア・リグオリ）がデモンストレーションしたこのIDEは、「スペック駆動開発（Spec-driven Development）」という方法論を体現しています。

スペック駆動開発の流れは明確です。

要件定義（Requirements）: 何を作るかを自然言語で明確に記述します
設計（Design）: 要件に基づいてアーキテクチャと技術的設計を行います
タスク定義（Tasks）: 設計を実装可能な単位に分解します
コード生成（Code Generation）: 上記の仕様に基づいてAIがコードを生成します

各段階は、次の段階に進む前に精緻化（refine）されます。

この方法論と新古典主義建築の原理との類似は、偶然ではないでしょう。新古典主義が「列柱のオーダー（様式）」によって建築の自由度を制約し、その制約の中で美と機能を実現したように、スペック駆動開発は「仕様」によってAIの生成自由度を制約し、その制約の中で品質と正確性を実現します。

ボーガス博士は、このアプローチの効果を具体的に示しました。

Kiroのある機能は、スペック駆動開発アプローチにより、通常の半分の時間で構築された。

「高貴なる単純さ」は、無駄を省いた仕様書に宿ります。「静穏なる偉大さ」は、仕様に基づいて静かに生成される、検証可能なコードに宿ります。

エージェントハーネスとガードレール

ボーガス博士の講演は、個々の開発者の規律だけでなく、システムレベルのガードレールにも言及しました。

AWSはBedrock AgentCoreにポリシーガードレールと評価（evals）を追加し、エージェントの行動を制御する仕組みを整えています。また、Arnab Bose（Asana）は、エージェントが相互に発見し、コンテキストを共有し、明確なワークフローの中で協調できるようにするために、「アイデンティティ、パーミッション、ガードレールが組み込まれている」ことの重要性を強調しました。

ボーガス博士はこれを「メカニズム」の問題として捉えています。

良い意図（intention）をメカニズム（mechanism）に変換せよ

コードレビュー、CIパイプライン、スペック駆動のワークフロー ── これらはすべて、「こうあるべき」という意図を、「こう動く」という仕組みに変換するメカニズムです。バロック的な「願い」ではなく、古典主義的な「構造」です。

規制対応の文脈では、この区別はさらに鮮明になります。

"If you create code that violates regulatory requirements, you can't blame the AI."

AIが生成したコードが規制要件に違反した場合、AIを責めることはできません。責任は常に人間にあります。だからこそ、メカニズム ── 自動推論、テストパイプライン、仕様書に基づく検証 ── が不可欠なのです。

AI-DLC (AI-Driven Development Life Cycle) フレームワークの提唱

ここで注目したいのは、ボーガス博士が提唱する規律的アプローチと、AI-DLC（AI-Driven Development Life Cycle）フレームワークとの構造的親和性です。

AI-DLCは、INCEPTION（企画・要件定義）→ CONSTRUCTION（設計・実装・テスト）→ OPERATIONS（運用）の3フェーズで構成されるソフトウェア開発ライフサイクルであり、以下の特徴を持ちます。

適応的（Adaptive）でありながら規律的（Disciplined）: 各ステージは独立に評価され、必要なもののみが実行されます。しかし、実行されるステージには明確なプロセスと承認ゲートが設けられています
監査可能性（Auditability）の確保: すべてのユーザー入力とAI応答がタイムスタンプ付きで記録されます
仕様先行: 要件分析 → ワークフロー計画 → 機能設計 → コード生成という順序は、スペック駆動開発の思想と完全に一致します

新古典主義が「自由の中の秩序」を追求したように、AI-DLCは「AIの生成能力を活かしながら、プロセスの規律で品質を保証する」というバランスを志向しています。それは、柱のオーダーが建築家の創造性を殺すのではなく、むしろ共通の文法を提供することで協働を可能にしたのと同じ構造です。

ルネサンス・デベロッパー ── 人間中心主義への回帰

ルネサンスの本質

4世紀から16世紀にかけてイタリアを起点に広がったルネサンスは、単なる芸術様式の転換ではありませんでした。それは、世界観そのものの根本的な転換でした。

中世ヨーロッパにおいて、知的活動の中心は神学であり、人間の存在意義は神との関係の中で規定されていました。ルネサンスのヒューマニズム（人文主義）は、この構図を転倒させました。古代ギリシャ・ローマの文献を再発見することで、人間の理性と創造性が独立した価値を持つことを再確認したのです。

ルネサンスを象徴する人物像は「ポリマス（万能人、uomo universale）」でした。レオナルド・ダ・ヴィンチは画家であり、彫刻家であり、建築家であり、解剖学者であり、エンジニアでした。レオン・バッティスタ・アルベルティは建築、絵画、暗号学、言語学に通じていました。彼らにとって、知の領域に壁はありませんでした。

ボーガス博士はキーノートの中でこう述べています。

"It was a time where art and science were part of the same conversation."

芸術と科学が同じ会話の一部だった時代。この一節は、ルネサンスの本質を凝縮しています。

ルネサンス開発者の5つの資質

ボーガス博士はルネサンス開発者を構成する5つの重要な資質を定義しています。

1. 好奇心（Curiosity）と実験精神（Experimentation）

"Curiosity is critical. As developers, you always have to continuously learn because everything changed all the time."

ボーガス博士は自身がCOBOL、Pascal、68000アセンブラという「絶滅した言語」を学んだ経験に言及し、そうした低レベルの理解が現代のアーキテクチャ判断を支えていると述べました。好奇心とは、今すぐ役立つ知識だけを追い求めることではありません。それは、ダ・ヴィンチが解剖学と絵画の両方を探究したように、一見無関係な領域の知識が後に統合される可能性への投資です。

そして、正しく実験するためには、失敗する意思を、そしてそれを真摯に改善する意思を持つ必要があります。

ボーガス博士はダ・ヴィンチの失敗した飛行機を引き合いに出します。その試みは失敗しましたが、その背後にある空気力学の探究が、数世紀後の近代航空の基礎となりました。好奇心が「知りたい」という欲求だとすれば、実験精神は「試してみよう」という行動の原理です。

失敗したデプロイメントは、ドキュメンテーション以上のことを教えてくれるとボーガス博士は述べました。ルネサンスの工房では、師匠の技法を忠実に模倣するだけでなく、新しい顔料の配合、遠近法の実験、未知の構図への挑戦が日常的に行われていました。失敗は恥ではなく、学習の不可分な一部でした。AI時代においても、この実験的姿勢 ── 安全に失敗し、そこから学ぶこと ── は不可欠です。

2. システム思考 (Think in Systems)

ここで言うシステムとは単なるコンピュータシステムではなく、全体的な相互作用のことです。「構造が変われば振る舞いが変わり、フィードバックが変われば結果が変わる」というシステム思考に基づき、部分的な最適化ではなく、全体像（ビッグピクチャー）を理解して強靭なシステムを構築する必要があります。

ボーガス博士は、ドネラ・メドウズ（Donella Meadows）のシステム思考の枠組みを引用し、イエローストーン国立公園のオオカミ再導入の事例を紹介しました。捕食者の排除は論理的には草食動物の増加に繋がるはずでしたが、実際にはエコシステム全体のバランスが崩壊しました。オオカミの再導入は、単に一つの種の復元ではなく、川の流れまで変えるほどの連鎖的影響をもたらしました。

ソフトウェアシステムも同様です。リトライポリシーの変更、キャッシュ戦略の修正 ── 一つのパラメータの変更が、可用性目標、インシデントプロファイル、運用コストに波及します。ルネサンスの建築家たちが構造全体を理解した上でドームを設計したように、ルネサンス・デベロッパーは個々のコンポーネントではなく、システム全体の挙動を理解しなければなりません。

3. コミュニケーション（Communication）

"The ability to express your thinking clearly is just as critical as the thinking itself."

"If you cannot explain what you want clearly, AI will just guess."

"Vague prompts turn into vague software."

AI時代において、自然言語はプログラミング言語と同じくらい精確でなければなりません。「曖昧なプロンプトは曖昧なソフトウェアになる」── この警句は、新古典主義的な形式の規律と直結します。

「思考を明確に表現する能力は、思考そのものと同じくらい重要」であり、エンジニアやリーダーにとって強力なコミュニケーションスキルを磨くことはキャリアにおいて最も重要なことの一つです。

AIによるコーディング支援が進む中、自然言語の曖昧さを減らし、仕様書（スペック）などを通じて正確に意図を伝える能力が求められます。

ルネサンス期のヒューマニストたちは、古典ラテン語の精確さを復活させることで、曖昧な中世の言語使用を克服しようとしました。同様に、ルネサンス・デベロッパーは、AIとのインターフェースとして機能する自然言語の精確さを磨かなければなりません。コミュニケーションは「ソフトスキル」ではありません。それは技術力そのものです。

4. オーナーシップ（Ownership）

"The work is yours, not that of the tools. You build it, you own it."

ボーガス博士は特に「ソフトウェアの品質に対するオーナーシップ」を持つことを強調しました。AIツールを使用しても、規制要件や品質に対する責任は依然として人間にあります。「仕事はあなたのものであり、ツールのものではありません」。

これは、ルネサンスのヒューマニズムが中世の神中心主義から人間中心主義への転換を宣言したのと同じ構造を持ちます。中世において、創造はすべて神の業であり、人間は神の道具に過ぎませんでした。ルネサンスは、人間を創造の主体として再定位しました。

同様に、Vibe Codingの文脈では、コードの生成はAI（ツール）の業であり、開発者はプロンプトを書く存在に過ぎません。Vogelsのオーナーシップの強調は、この関係性を転倒させます ── 開発者こそが創造の主体であり、AIはその道具に過ぎません。道具がどれほど高度になっても、創造物の責任と誇りは人間に帰属します。

「あなたが作ったものは、あなたが責任を持つ（You build it, you own it）」という原則は変わりません。

5. 博識家（ポリマス）になること (Become a Polymath)

ポリマスとは「多くを学ぶこと」を意味し、深い専門知識を持ちながらも、多くの異なる主題にわたる知識を持つことを指します。

ボーガス博士はデータベースのパイオニアであるJim Gray（チューリング賞受賞者）を「ルネサンス・デベロッパー」の現代版として紹介しました。Grayの専門はデータベースでしたが、彼の関心は科学、ビジネス、物理学にまで及んでいました。ある伝説的なエピソードでは、Grayはディスクの音を聴くだけでランダムI/Oの問題を診断したといいます。それは、深い専門性と幅広い知識の融合がもたらす、単なるスペシャリストには到達できない洞察でした。

これは、ダ・ヴィンチが解剖学、光学、水力学、軍事工学を横断しながら、絵画において比類のない深みを達成したのと同じ構造です。

すべての人がダ・ヴィンチになる必要はありませんが、「T型人材（T-shaped developers）」として、特定のドメインに深く精通しつつ（縦棒）、他の分野やシステム全体がどう適合するかを理解する広さ（横棒）を持つべきなのです。