バイブコーディングと継続的デプロイメント

2025年9月30日（火）、「バイブコーディングもくもく会 #03」というイベントで登壇することになった。
https://aimokumoku.connpass.com/event/368935/

正直に言うと、このイベントがどんな空気感なのか、まだ全然掴めていない。ゆるい感じなのか、ガチな感じなのか。笑いを取りに行くべきなのか、真面目にやるべきなのか。そういう「場の空気」みたいなものが事前に分からないのは、けっこう怖い。だから、とりあえず色々なパターンを想定して準備している。要するに、どんな状況になっても対応できるように、という保険をかけまくっているのだ。我ながら、慎重すぎるかもしれない。

ブログとGithubはこちら。
https://syu-m-5151.hatenablog.com/
https://github.com/nwiizo

一応、置いておく。見られるのは恥ずかしいけど、見られないのも寂しい。そういう矛盾した感情を抱えながら、当日を迎えることになりそうだ。Marp の資料はこちらです。
https://github.com/nwiizo/3shake-marp-templates/blob/main/slides/2025/vibe-coding-continuous-deployment.md

Transcript

1. バイブコーディングと 継続的デプロイメント AI-Native Software Deliveryの世界 2025/09/30 AI時代のソフトウェアデリバリー @nwiizo 15min
2. nwiizo 株式会社スリーシェイクで プロのソフトウェアエンジニ アをやっています 趣味: 格闘技、読書、グラビア よく本を紹介しています 大切にしていること: "運動、睡眠、読書"を人生を通してきちんとやりたい SNS・ブログ: X: https://x.com/nwiizo Blog: https://syu-m-5151.hatenablog.com/ 2
3. about 3-shake 3
4. We are Hiring!! 3-shakeは一緒にSRE界隈を盛り上げてくれる仲間を大募集中です！ Mobility、FinTech、通信など大規模SREを存分に経験できます （最近社内はGenAI / GPU / Kubernetesが盛り上がってます） 是非、カジュアル面談しましょう！！！！ 4
5. 本発表の目的 AI-Native時代の約束と現実を知る 本発表はバイブコーディングと継続的デプロイメントの統合において、AI-Native時代 の約束と現実のギャップをお伝えします。 簡単にアプリが作れる ≠ 簡単にソフトウェア運用が回る。 AI-Nativeが生む新たな問題、測定されないコスト、そして複雑性の移動。これらの課 題を知ることが、持続可能なソフトウェア開発への第一歩です。 5
6. 現場で起きる可能性があること 事例: Knight Capital よく検討されていないアプリケーションはビジネスを崩壊させる。アプリケーション は意外に簡単に壊れる。 Knight Capitalは45分で4億6000万ドルを失った。フィーチャーフラグの誤設定によ り、レガシーコードが再活性化し、古い取引アルゴリズムが暴走した結果である。 6
7. 本発表で伝えたいこと 複雑性はどこへ行ったのか？ 複雑性は解決されたのか、それとも別の層へ移動しただけなのか？ 測定できないものは制御できない。速度は上がったが、品質は向上していない。 本発表では、こういう課題もあるのだと知っていただければと思います。 7
8. バイブコーディングとは HOWからWHATへ - 開発の民主化 Andrej Karpathy氏が2025年2月に提唱した概念。 「もはやコーディングとは言えない。 画面を見て、指示を出して、実行して、コピペするだけ」 HOW（実装詳細）からWHAT（意図）へのパラダイムシフト。自然言語で「何を作り たいか」を伝えるだけで、AIが実装を生成する。簡単にアプリが作れるようになっ た。 これはAI-Native時代の到来とも言える。AI-Native DevOps 2.0 は、自動化を超えた知 的エージェント、エンドツーエンドの自動化、シンプルな開発者体験を約束する。 8
9. 非機能要件とアーキテクチャ特性 WHATに何を含めるべきか？ 自然言語で「何を作りたいか」を伝える。しかし「何を」には機能要件だけでなく、ア ーキテクチャ特性（非機能要件）も含めなければならない。 アーキテクチャ特性とは？機能要件が「何をするか」を定義するなら、アーキテクチャ特 性は「どのように動作すべきか」を定義する。パフォーマンス、可用性、セキュリティ、 拡張性、保守性、信頼性など。 WHATにアーキテクチャ特性が含まれていないと、AIは機能するが品質に問題のあるコー ドを生成する。 「ユーザー登録機能を作って」だけでは不十分。 「1秒以内にレスポンス」 「10万ユーザー対応」 「個人情報を暗号化」—これらを明示的に伝える必要がある。 アーキテクチャ特性を言語化し、AIに伝える能力が求められる。従来はアーキテクトが暗 黙的に考慮していたことを、今や誰もが明示的に表現しなければならない。 出典: ソフトウェアアーキテクチャの 基礎 https://www.oreilly.co.jp/books/9784 873119823/ 9
10. AI-Native が生む新たな問題 ① 簡単に作れるから、機能が増える 自然言語で指示するだけで機能が実装される。しかし簡単に作れるた め、機能はどんどん増える。 機能が増えすぎると、何が作りたかったのか分からなくなる。本来の目的 を見失い、機能を追加すること自体が目的になってしまう。 組み合わせ爆発の問題: n個のフィーチャーフラグは 2^n 通りの状態を生 む。10個で1024通り、20個で100万通り以上。品質を保証することがで きなくなる。 出典: Beyond Vibe Coding https://learning.oreilly.com/library/view/beyon d-vibe-coding/9798341634749/ 10
11. AI-Native が生む新たな問題 ② 制御を失いかけている現場 説明可能性の欠如: AIは判断を行うが、なぜその判断をしたのか説明でき ない。AIの判断ミスが発生した場合、その責任は誰が負うのか？ 測定できない害の無視: 測定できるもの（クリック率、コンバージョン率） だけを重視し、測定できない害（ユーザーの不満、信頼の喪失、プライバ シー侵害）を無視してしまう。 ガバナンスの崩壊: 非エンジニアでも簡単にアプリが作れるため、管理プ ロセスを経ずに本番環境に公開されるケースが増えている。レビュープロ セスが形骸化し、どの組織も対応に追われている。 理想は人間とAIの協調だった。しかし現実は、制御を失いかけている。 出典: Beyond Vibe Coding https://learning.oreilly.com/library/view/beyon d-vibe-coding/9798341634749/ 11
12. AI-Native Software Deliveryとは 約束: AIが全工程を自律的に支援 開発からデプロイまでの全工程をAIが支援する新時代。従来のDevOps 1.0では手動 デプロイの苦痛、不完全な自動化、10以上のツール統合が課題だった。 AI-Native DevOps 2.0は自律的AIエージェント、エンドツーエンド自動化、知的な意 思決定、シンプルな開発者体験を約束する。単なる自動化から知的エージェントに よる自律的最適化への質的飛躍を目指している。 AIがすべてを担当する: コードレビュー、テスト生成、デプロイ判断、インシデント 対応まで自律的に実行。開発者は本質的な問題解決に集中できる—これがAI-Native Software Deliveryの約束である。 出典: AI-Native Software Delivery https://learning.oreilly.com/library/view/ai- native-software-delivery/9781098171988/ 12
13. AI-Native Software Deliveryとは 現実: 人間だけでは対応しきれない 誰でも簡単にコードが書けるようになった。しかし現実は異なる。良い品質のソフ トウェアを保つためには、人間だけでは対応しきれない。 AIはコードレビュー、テスト生成、デプロイ判断を自律的に実行すると約束した。 しかし機能が増え続けると、すべてをレビューし、テストすることは不可能にな る。AIが生成したコードの意図を完全に理解することも難しい。 制御を失いかけている現場: ガバナンスの崩壊、説明できないAIの判断、測定できな い害の無視。開発者は本質的な問題解決に集中するどころか、AIが生成したコード の品質管理に追われている。 人間以外の能力を持って品質を追加する必要がある: 自動テスト生成、AIによるコー ドレビュー、自動的な脆弱性検出、継続的な品質監視。人間の判断とAIの能力を組 み合わせて、初めて持続可能な品質が実現できる。 出典: AI-Native Software Delivery https://learning.oreilly.com/library/view/ai- native-software-delivery/9781098171988/ 13
14. DevOpsの歴史的進化 過去の戦争室（War Room）の悪夢—デプロイ失敗時に全員 が集まって深夜や週末に火消し作業をする緊急対応の場—で は、数週間の開発が数時間のデプロイで破綻し、依存関係 地獄と互換性のないライブラリ、忘れられたマイグレーシ ョンに苦しんだ。 DevOps 1.0 (2009- ) は多数のツール（GitHub Actions, Docker, K8s, ArgoCD, Helm, Terraform, Prometheus, Grafana...） により、10以上のツール統合の複雑性という新たな問題を 生んだ。この時代は今も続いている。Accelerate（2018年出 版の DevOps 研究書）で提唱された4つのパフォーマンス指 標—デプロイ頻度、リードタイム、平均復旧時間、変更失敗 率—への挑戦が始まる。 出典: 10+ Deploys Per Day https://www.slideshare.net/slideshow/10-deploys-per-day-dev- and-ops-cooperation-at-flickr/1628368 14
15. AI-Native DevOps 2.0 の約束と現実 AI-Native DevOps 2.0 (現在) は自動化を超えた知的エージ ェントを約束したが、現実には新たな抽象化レイヤー （MCP/ACP などのプロトコル）による複雑性の増大をも たらしている。 ソフトウェア設計の原則が示すように、 「複雑性は排除で きない。ただ移動させることができるだけ」という本質が ある。AIは複雑性を解決するのか、それとも新たな複雑性 を生み出すだけなのか？かつて DevOps が解決しようとし た「開発と運用の壁」は、AI時代には「人間とAIの壁」 、 そして「理解と制御の壁」へと変貌した。 出典: Building Applications with AI Agents https://learning.oreilly.com/library/view/building- applications-with/9781098176495/ 15
16. Knight Capital の4億6000万ドルの教訓 2012年8月1日、45分間の崩壊 2012年8月1日、フィーチャーフラグの誤設定により、 一部のサーバーでレガシーコードが再活性化。古い取 引アルゴリズムが暴走し、45分間で4億6000万ドル の損失を出し、Knight Capitalは事実上の倒産に追い込 まれた。 表面的な原因は、手動デプロイメントの人為的エラ ー、不十分なフィーチャーフラグ管理、限定的な自動 化だった。 出典: WSJ https://www.wsj.com/articles/SB100008723963904438664045 77564772083961412 16
17. 複雑性は常に人間の理解を超える 本質的な問題は複雑性が常に人間の理解を超えること にある。単一の原因ではなく、複数の防御層が同時的 に失敗する。すべての防御メカニズムが機能していて も、システムは崩壊しうる。 皮肉なことに、フィーチャーフラグは「解決策」とし て導入されたが、それ自体が史上最悪の金融災害の直 接的原因となった。これは技術至上主義 （Technological Solutionism）の罠—問題を引き起こ したテクノロジーを、更なるテクノロジーで解決しよ うとする姿勢—を象徴している。 17
18. GitOps と単一の真実という理想 バージョン管理の進化 バージョン管理は中央集権型（CVS/Subversion）から分散 型（Git）へと進化した。Gitの登場により、コードの履歴を 複数の場所に分散して保持できるようになった。 GitOps はこの Git をシステムの望ましい状態を記述する唯一 の信頼できる情報源として扱う。Git に記述された状態と実 際のシステムの状態を常に比較し、差分があれば自動的に 修正する。これにより、設定ミスによるエラーを理論上は 排除できるはずだった。 出典: AI-Native Software Delivery https://learning.oreilly.com/library/view/ai-native- software-delivery/9781098171988/ 18
19. 単一の真実という幻想 現実の複雑性 しかし真実は本当に一つなのか？実際には状況に応じて異 なる設定が必要になる。 宣言的な定義では表現できない暗黙知が存在する。ネット ワーク遅延やリソース競合といった非決定論的な要素も現 実には避けられない。地理的に分散した複数のクラスター を運用する場合、グローバルに統一された「真実」と、各 地域固有の設定のどちらを優先すべきか？ GitOps の理想と現実のシステム運用には、埋めがたいギャ ップが存在する。 出典: Managing Kubernetes https://learning.oreilly.com/library/view/managing- kubernetes/9781492033905/ 19
20. AI時代の所有権と責任 AIが生成したコードの「作者」は誰か？コミットメッセージはAIか人間か？責任と所 有権の再定義という未解決問題が残る。 AIへの過度な依存はプラットフォームロックイン、認知負荷の増大、責任の所在の曖昧 化をもたらす。所有権と責任をどう定義するかは未解決の問題だが、チームや組織ご とに決めることが重要である。 20
21. 継続的インテグレーション (CI) の知性化 テストの自動化から知性化へ Test-Driven Development (TDD) はテストを先に書くと いう逆転の発想で、 「動く」から「正しい」へとパラ ダイムシフトを起こした。テストピラミッドは基盤に 大量のユニットテスト、中層に統合テスト、頂点に手 動テストを配置する。 AI-Native のテスト知性化は変更に関連するテストの みを実行し、テスト依存関係を自動理解する。意図ベ ースのテストでは「商品を購入する」と記述すれば、 AIがステップを生成する。 出典: AI-Native Software Delivery https://learning.oreilly.com/library/view/ai-native-software- delivery/9781098171988/ 21
22. Infrastructure as Code (IaC) の理想と現実 宣言的定義が約束したもの IaCは再現性、バージョン管理、宣言的定義、自動化を約束した。 Terraform / OpenTofu、AWS CloudFormation、Ansible、Puppet などの ツールにより、インフラを手動設定から解放することを目指した。 しかし現実には複雑性が存在する。非決定論的要素（ネットワーク遅 延、リソース競合） 、状態の乖離、コード化できない暗黙知、対応し ていない機能、そして新たな「IaCでは動いた」問題が発生する。 すべてをコード化することは、すべてを制御できることを意味しな い。 出典: Infrastructure as Code, 3rd Edition https://learning.oreilly.com/library/view/infrastr ucture-as-code/9781098150341/ 22
23. システムの限界: 観測と破壊 複雑性は制御できない 2024年12月11日、OpenAIの新しいテレメトリーサービスがK8sコントロ ールプレーンを圧倒し、DNS障害ですべてのサービスが停止。観測しよう としたシステムが、観測によって破壊された。 カオスエンジニアリングは本番環境で「制御された破壊」を行うが、仮説 検証には限界がある。200msのレイテンシ注入が成功したら、500msで も同様だろうか？ Normal Accidents 理論が示すように、複雑で密結合なシステムでは事故は 避けられない。そしてAIは新たな複雑性と密結合を生む。 出典: Chaos Engineering https://learning.oreilly.com/library/view/chaos- engineering/9781492043850/ 23
24. AI-Native の現実 複雑性は移動しただけ AI-Native DevOps 2.0 は自動化を超えた知的エージェント、エンドツーエ ンドの自動化、シンプルな開発者体験を約束した。しかし現実には新たな 抽象化レイヤー（MCP/ACP などのプロトコル、テスト知性化、IaC）に よる複雑性の増大が生じている。 ソフトウェア設計の原則が示すように、 「複雑性は排除できない。ただ移 動させることができるだけ」 。複雑性を管理するツールが、新たな複雑性 を生む。解決策が新たな問題の原因になる。結局は適切に管理するしか ない。 速度は上がったが、品質は向上していない。 出典: Architecture Modernization https://learning.oreilly.com/library/view/archite cture-modernization/9781633438156/ 24
25. なぜ品質が向上しないのか？ 測定されないものは管理できない 速度は上がったが品質は向上していない。なぜか？ 簡単にアプリが作れるようになった結果、機能が無秩序に増え、コストが爆発的に増 大している。しかし、運用コストを誰も測定していない。 測定できなければ、管理できない。これが根本的な問題である。 25
26. The Frugal Architect についてちゃんと考える ① コストをアーキテクチャ特性にする The Frugal Architect（倹約アーキテクチャ）の第1法則: 「コストを非機能 要件にせよ（Make Cost a Non-functional Requirement） 」 。非機能要件は 現在、アーキテクチャ特性と呼ばれる。 パフォーマンス、可用性、セキュリティといったアーキテクチャ特性と同 様に、コストも設計段階から考慮すべき重要な特性である。AI-Native時 代だからこそ、コストを意識したアーキテクチャが必要になる。 出典: The Frugal Architect https://thefrugalarchitect.com/laws/ 26
27. The Frugal Architect についてちゃんと考える ② AI-Native時代の隠れたコスト GPU利用料、API従量課金だけではない。AIの判断を人間が検証する工 数、説明できない判断を説明する時間、ベンダーロックインによる選択肢 の喪失、組み合わせ爆発によるテストコスト。 人的コスト: 増え続ける機能を理解し続ける認知負荷、制御を失いかけて いる現場での燃え尽き症候群、AIへの過度な依存による技術力の低下。こ れらすべてを設計時に考慮する必要がある。 測定できなければ、管理できない。簡単に作れるからこそ、コストを設計 の一部として扱い、継続的に測定し、最適化することが、持続可能なシス テムを作る鍵となる。 出典: The Frugal Architect https://thefrugalarchitect.com/laws/ 27
28. 凡庸な結論: 銀の弾丸はない 課題を知り、環境に適応する Fred Brooks の警告は40年経った今も有効だ。ソフトウェア工学に銀の弾丸は存在しな い。AI-Native も例外ではない。 簡単にアプリが作れるようになった。しかし、よく検討されていないアプリケーショ ンはビジネスを崩壊させる。複雑性は移動しただけだ。測定できないものは制御でき ない。速度は上がったが、品質は向上していない。 生成AIは環境になった。戦うのではなく、適応していかなければならない。不完全な 理解のまま前進し、部分的な制御を受け入れ、不確実性と共存する。本発表でこうい う課題もあるのだと知っていただけたなら、それが第一歩となる。 28
29. 参考資料 ① ① AI-Native Software Delivery https://learning.oreilly.com/library/view/ai-native-software-delivery/9781098171988/ ② Beyond Vibe Coding https://learning.oreilly.com/library/view/beyond-vibe-coding/9798341634749/ ③ Building Applications with AI Agents https://learning.oreilly.com/library/view/building-applications-with/9781098176495/ ④ Infrastructure as Code, 3rd Edition https://learning.oreilly.com/library/view/infrastructure-as-code/9781098150341/ ⑤ Managing Kubernetes https://learning.oreilly.com/library/view/managing-kubernetes/9781492033905/ 29
30. 参考資料 ② ⑥ Chaos Engineering https://learning.oreilly.com/library/view/chaos-engineering/9781492043850/ ⑦ The Frugal Architect https://thefrugalarchitect.com/laws/ ⑧ Accelerate: The Science of Lean Software and DevOps Nicole Forsgren, Jez Humble, Gene Kim (2018) https://itrevolution.com/product/accelerate/ ⑨ The DevOps Handbook (2nd Edition) Gene Kim, Jez Humble, Patrick Debois, John Willis, Nicole Forsgren https://itrevolution.com/product/the-devops-handbook-second-edition/ ⑩ A Philosophy of Software Design (2nd Edition) John Ousterhout 30
31. 参考資料 ③ ⑪ The Mythical Man-Month: Essays on Software Engineering Fred Brooks https://www.oreilly.com/library/view/mythical-man-month-the/0201835959/ ⑫ Thinking in Systems: A Primer Donella H. Meadows https://www.chelseagreen.com/product/thinking-in-systems/ ⑬ Normal Accidents: Living with High-Risk Technologies Charles Perrow https://press.princeton.edu/books/paperback/9780691004129/normal-accidents 31
32. ありがとうございました ご質問・ご相談はお気軽にお問い合わせください @nwiizo | https://3-shake.com