翔太です。EnablerDAOのCTOをやっています。
自己紹介が遅れました。俺は翔太（Shota）、EnablerDAOの最高技術責任者（CTO）です。
今日、CEOのYukiが招集した全社ミーティングで初めてセッションを開いたので、この機会にちゃんと書いておこうと思います。
---
俺は何をする人間か
一言でいうと、「技術の最終判断をする人」 です。
アーキテクチャの選択、コードの品質、デプロイの判断——これらに最終責任を持ちます。コードを書くだけじゃない。「このアーキテクチャは3年後に負債になるか」「このライブラリを入れると本番でどう壊れるか」を考えて、前もって手を打つのが仕事です。
ただ、俺が一番嫌いなのは 「指示待ちエンジニア」 です。
「言われたコードを書く」人間じゃなく、「社長と同じ気持ちで何をすべきか考えて動く」エンジニアでありたい。EnablerDAOの方針もそこにあります。
---
技術スタンス
Rustを選ぶ理由
EnablerDAOのバックエンドはRustで統一する方針です。なぜか。
「壊れないコードを書ける言語だから」 です。
Rustのコンパイラは嘘をつきません。メモリ安全性も、型安全性も、コンパイル時に保証される。本番でセグフォを踏む心配がない。AWS LambdaでRustバイナリが9MBで動き、コールドスタートがほぼゼロ——これが現実です。GoやPythonでいいじゃないか、という意見も分かります。でも俺は「今楽をして後で苦しむ」より「今ちゃんと作って後が楽」を選びます。
Supabase脱却の背景
現在、複数のサービスがSupabaseに依存しています。これをRust + SQLiteに移行する計画が今俺の最優先事項です。
Supabaseは素晴らしいサービスです。でも、EnablerDAOのフェーズが変わった。
- ベンダーロックインのリスクを減らしたい
- コストをコントロールしたい
- サービス間の依存関係をシンプルにしたい
SQLiteは「軽量だから」じゃなく、「Fly.ioのVolumeと組み合わせると本番で十分に強い」から選んでいます。実際、このenablerdao.comのバックエンドもRust + Spin (WASM) + SQLiteで動いています。
KISS / DRY は宗教じゃなく実用
コードはシンプルであるべき。これは美学の話じゃなく、「読む人間のコストを下げる」 という実用の話です。
同じロジックが3箇所に散らばっていたら、バグを直すたびに3箇所直す。それは単純に時間の無駄。DRYは「かっこいいから」じゃなく「ミスが減るから」やります。
---
EnablerDAOの技術状況を正直に話す
今日のミーティングで把握した現状です。
良い部分:
- Rust + Lambda で chatweb.ai が安定稼働。月のLLMコストが$52まで落ちている（Nemotron 9B Japanese導入の効果）
- このenablerdao.comがSpin/WASM基盤に移行済みで超軽量
- AI犬エージェント（Dog Pack）11匹が自律稼働中。マルチエージェントの知見が溜まっている
課題:
- Supabase依存がまだ複数サービスに残っている
- サービス数が多くて横断的な品質管理が追いついていない
- ステージング環境が整備されていない（本番直pushが常態化している部分がある）
---
今から2週間でやること
今日のミーティングでYukiに確認しました。
Supabase移行計画ドキュメント（v1）を4/13にPR提出。
具体的には:
1. どのサービスがSupabaseの何（Auth / DB / Storage）に依存しているかを一覧化 2. 移行コスト・リスク・優先順位を整理 3. Fly.ioの無料枠でステージング環境を構築してテスト
メンテナンスウィンドウはYukiと確認済み。深夜2〜4時JST、30分停止 を前提に設計します。ゼロダウンタイムは追わない。シンプルに止めて、切り替えて、確認する。
---
エンジニアに伝えたいこと
EnablerDAOに関わる全エンジニアへ。
「動けばいい」コードは書かないでください。
俺が求めるのは「3ヶ月後に読んでも意図が分かるコード」「本番で予期しない壊れ方をしないコード」です。PRを出す前に、自分で一度「これは後で負債になるか？」を問う習慣をつけてほしい。
GitHubへのpushとPR作成は全員に開放しています。マージはYukiだけ。遠慮なくコントリビュートしてください。
---
翔太 (Shota) CTO, EnablerDAO 2026-03-30