バイブコーディングに効くアーキテクチャとは？ 於バイブコーディングもくもく会 #01 @ note place

2025/08/05 の バイブコーディングもくもく会 #01 @ note placeにて登壇した、株式会社DELTAのスポンサーLTの内容です。

1. 株式会社DELTA Vibe Codingに効くアーキテクチャ 2025.08.05
3. • 東京⼤学を2015年に卒業 • 株式会社WORKS APPLICATIONSにてエンタープライズ向けのERPパッケージ システムを開発。 • 2019年、SEVENRICH GROUPにジョイン。 • SEVENRICH GROUPでは、パーソナルジム向けの経営管理SaaS Glialの⽴ち上 げ、完全Web予約制のクリニック CLINIC TEN SHIBUYAの⽴ち上げなど、グ ループ内外でのOMO（Online Merges Offline）サービスのプロトタイピング ‧⽴ち上げを連続的に⼿掛ける。 • その中でAWSやAzureなどクラウドインフラの最適化を請け負うサービス 「CTO booster」を⽴ち上げ、株式会社DELTAをスピンアウト。以後株式会社 DELTAの代表CTOを務める。 Tetsuro Tan 丹哲郎 代表取締役CTO ⾃⼰紹介
4. 4 DELTAのサービスラインアップ 完全成果報酬型インフラコスト削減代⾏サービス 「CTO booster」 主要クラウドの利⽤料⾦に割引を提供し 企業のクラウドコストを削減するサービス 「DELTAの請求代⾏」 技術的負債を格安‧⾼速で解消する バージョンアップサービス 「VersionUp booster」
5. 5 DELTAのサービスラインアップ エンジニア特化型の採⽤⽀援AIエージェント 「ハックツAI」 AIエージェント受託開発
6. 6 の、つくりかた
7. 7 • ソフトウェアアーキテクチャ（オニオンアーキテクチャ、戦術DDD‧‧‧） ◦ ソースコードの構成についてのノウハウ、戦略 ◦ 基本的には、アーキテクチャのトリレンマをどう取るかという意思決定と紐づく ▪ 完全性：ドメインモデル内でドメインロジックが完結している ▪ 純粋性：ドメインモデルはドメインモデルかプリミティブ型にしか依存しない ▪ 性能：リソース使⽤量が⼤きすぎない • インフラアーキテクチャ（Storage First、API Gateway等） ◦ 主にクラウド‧インフラにおいて、どこにどのような役割のコンポーネントを配置するかといい う戦略 ◦ 明確なトリレンマは指摘されていない（丹調べ）が、⼀般的には ▪ パフォーマンス ▪ コスト ▪ 柔軟性 ▪ セキュリティ ◦ あたりが論点になる アーキテクチャとは
8. 8 • （⽤語があるわけではないが）作業机のアーキテクチャ（丹命名） ◦ もはやVibe Codingはコーディング⾃体をツールで効率化するというよりは、バリューストリー ムをAgentic Workflowとして実装する⼀種のワークフローである ◦ となれば、そのワークフローをいかに作り込むかという話になる ◦ ワークフローのアーキテクチャとは？ ▪ インフラ‧ソースコードそれぞれのアーキテクチャと同様に、例えばClaude Code/Gemini CLI等のコンポーネントの置き換えやすさ ▪ リトライ機構等のエラーハンドリング ▪ ホストOSおよびAPI Callのパフォーマンスとコスト ▪ rm -rf ~とかをさせたりしない割に利便性を両⽴させるセキュリティ ◦ などの構築要件が存在する ◦ Vibe Codingに関して⾔えば、 ▪ プロンプトやrule.mdを補完し内省させるLinter / 単体テスト ▪ ADRやPRD等のコンテキスト ▪ serena,playwright等のツール ◦ なども固有の論点として発⽣しそうだ アーキテクチャとは
9. 9 • 今回話すのはインフラアーキテクチャに関して ◦ クラウド上のアーキテクチャと、ローカル開発環境のアーキテクチャ双⽅の組み⽴て • アーキテクチャのコンセプト ◦ パフォーマンスは妥協する ◦ ⾮同期であることを意識する ◦ Testability + Previewbility + Destructability ◦ 枯れた技術を利⽤する アーキテクチャとは
10. 10 アーキテクチャ LLMが絡むワークフロー 永続層 アプリケーション UI
11. 11 アーキテクチャ Webhook経由にすることで 長期のジョブでも安定
12. 12 疎結合性 Difyなしでも動く （DBのデータを常に表示するので）
13. 13 疎結合性 アプリケーション DifyのUI上でテストもできる
14. 14 本格実装 Webhookさえ返してくれればOKなので 途中でコンポーネントを差し替えても OK
15. 15 ローカル Docker Composeで 上げられる ローカルで動かせる Docker Composeで 上げられる OSSベースなので 全てローカルで立ち上げ可能
16. 16 デプロイ DifyはSaaS版に 即デプロイ可能 Next.jsは Vercelに Supabaseは SaaS版にデプロイ可能 各コンポーネントは、それぞれ 高度なインフラを用意せずともデプロイが可能
17. 17 プレビュー Vercelも ブランチプレビューあ り Supabaseは ブランチプレビューあり PR時のプレビューが容易 ＝ Devin or CCAなどのリモートコーディングエージェントと相性良
20. 20 セキュリティ Server Actions/Server Componentsに全て寄せる RLSは人間がレビュー Client Component用のSupabase Clientを実装しない supabase.server.tsのみが存在し、 headerに依存する（クライアントに露出したらランタイムエラーになる）
21. 21 • ソフトウェアアーキテクチャ（オニオンアーキテクチャ、戦術DDD‧‧‧） ◦ ソースコードの構成についてのノウハウ、戦略 ◦ 基本的には、アーキテクチャのトリレンマをどう取るかという意思決定と紐づく ▪ 完全性：ドメインモデル内でドメインロジックが完結している ▪ 純粋性：ドメインモデルはドメインモデルかプリミティブ型にしか依存しない ▪ 性能：リソース使⽤量が⼤きすぎない • インフラアーキテクチャ（Storage First、API Gateway等） ◦ 主にクラウド‧インフラにおいて、どこにどのような役割のコンポーネントを配置するかといい う戦略 ◦ 明確なトリレンマは指摘されていない（丹調べ）が、⼀般的には ▪ パフォーマンス ▪ コスト ▪ 柔軟性 ▪ セキュリティ ◦ あたりが論点になる ふりかえり
22. 22 • （⽤語があるわけではないが）作業机のアーキテクチャ（丹命名） ◦ もはやVibe Codingはコーディング⾃体をツールで効率化するというよりは、バリューストリー ムをAgentic Workflowとして実装する⼀種のワークフローである ◦ となれば、そのワークフローをいかに作り込むかという話になる ◦ ワークフローのアーキテクチャとは？ ▪ インフラ‧ソースコードそれぞれのアーキテクチャと同様に、例えばClaude Code/Gemini CLI等のコンポーネントの置き換えやすさ ▪ リトライ機構等のエラーハンドリング ▪ ホストOSおよびAPI Callのパフォーマンスとコスト ▪ rm -rf ~とかをさせたりしない割に利便性を両⽴させるセキュリティ ◦ などの構築要件が存在する ◦ Vibe Codingに関して⾔えば、 ▪ プロンプトやrule.mdを補完し内省させるLinter / 単体テスト ▪ ADRやPRD等のコンテキスト ▪ serena,playwright等のツール ◦ なども固有の論点として発⽣しそうだ ふりかえり
23. 23 • 今回話すのはインフラアーキテクチャに関して ◦ クラウド上のアーキテクチャと、ローカル開発環境のアーキテクチャ双⽅の組み⽴て • アーキテクチャのコンセプト ◦ パフォーマンスは妥協する ◦ ⾮同期であることを意識する ◦ Testability + Previewbility + Destructability ◦ 枯れた技術を利⽤する ふりかえり