ハクソク

世界を動かす技術を、日本語で。

すべてをコードとして：私たちの会社を一つのモノレポで管理する方法

107日前原文(www.kasava.dev)

概要

  • Kasavaでは、全てのプロダクト・ドキュメント・マーケティングを**単一リポジトリ（モノレポ）**で管理
  • AIネイティブ開発により、AIが全ソースに即時アクセスし、ドキュメントやマーケティングも自動整合
  • コード・ドキュメント・Webサイト・ブログなど、全てgit push一発でデプロイ可能
  • 一元管理でバージョン不一致や部門間の連携コストを排除
  • CI/CDやレビューも統一化し、誰でも即座に全体をアップデート可能

Kasavaのモノレポ戦略とAIネイティブ開発

  • 全社的なモノレポ管理により、コード・ドキュメント・マーケ・ブログ等、5,470+ファイルを一元化

    • frontend/: Next.js 16+React 19アプリ
    • backend/: Cloudflare Workers API
    • website/: マーケティングサイト
    • docs/: 公開ドキュメント
    • marketing/: ブログ・投資家資料・メールテンプレート
    • external/: Chrome拡張・Google Docsアドオン・GCP Functions
    • scripts/, infra-tester/, github-simulator/: 開発・テスト補助

  • AIネイティブ開発の実現

    • AIが全てのソース・ドキュメント・Webを横断的に参照・検証
    • ドキュメントやマーケの記述が実装と即時で同期
    • ブログやサイトの数値・仕様もAIがコードから自動検証

  • 全てが「git push」でデプロイ可能

    • コード・ドキュメント・Web・ブログ・メール・投資家資料まで、全て同じGitワークフロー
    • 部門横断のデプロイ調整不要、即時反映

モノレポのメリット

  • 原子性のある変更とAIによる一元検証

    • バックエンドAPI変更時、フロント型定義・ドキュメント・マーケも同時更新
    • 例: Asana統合追加時、全サービス・画面・ドキュメントを1PRで一括更新

  • 一元的な料金プラン管理

    • 1つのbilling-plans.jsonで全プロダクトのプラン・上限を定義
      • バックエンド＝上限 enforce
      • フロント＝設定画面で表示
      • マーケサイト＝料金ページ表示
    • 変更時、AIが全実装を自動で整合性チェック

  • クロスプロジェクトなリファクタリング

    • 関数リネーム等も全体横断で一括置換・コミット

  • 単一ソース・シンプルな依存関係管理

    • ツール設定・CI/CD・全文検索も一か所で完結

各ディレクトリ構成の詳細

  • frontend/

    • Next.js 15 App Router、AIチャット、バグレポート、ダッシュボード等
    • 45+コンポーネント、AI関連UI、Google Docs連携など

  • backend/

    • Hono APIエンドポイント、55+ビジネスロジックサービス、AIワークフロー
    • Drizzle ORMスキーマ、Durable Objects、AIエージェント

  • website/ & marketing/

    • マーケティングサイト、ブログ、投資家向けNext.jsデッキ、メールキャンペーン
    • ブログはMarkdownでPRレビュー、メールはMJMLでバージョン管理

  • docs/ & docs-internal/

    • 公開ドキュメント（Mintlify）、社内アーキテクチャ・仕様・研究ノート
    • プッシュで自動デプロイ、コードと一緒に全文検索可能

  • external/

    • Chrome拡張（WXT+React）、Google Docsアドオン（Apps Script）、GCP Functions

  • 開発インフラ

    • github-simulator/（モックAPI）、infra-tester/（統合テスト）、scripts/（デプロイスクリプト）

デプロイ先と技術スタック

  • Frontend: Next.js+React+Tailwind → Vercel
  • Backend: Cloudflare Workers+Hono+Mastra → Cloudflare
  • Website/Investor Deck: Next.js → Vercel
  • Docs: Mintlify MDX → Mintlify
  • Chrome Extension: WXT+React → Chrome Web Store
  • Google Docs Add-on: Apps Script → Google Workspace Marketplace
  • Tree-sitter Service: Node.js → GCP Functions
  • Email Templates: MJML → Loops.so

運用の工夫

  • npm/yarnワークスペース非採用

    • 各ディレクトリは独立npmプロジェクト
    • 依存関係の混乱やバージョン不一致を排除

  • 選択的CI/CD

    • 5つのGitHub Actionsワークフローで、パスごとにテスト・デプロイを分離

まとめ：AI時代の一元開発体制

  • AIが全体を俯瞰し、全ての変更を一括整合・検証
  • 全員が同じワークフローで、どの領域も即時にアップデート可能
  • 分散管理の煩雑さを排除し、「すべてがコード」として管理・デプロイ
  • AIネイティブな開発体制が、プロダクトの進化速度と品質を最大化

Hackerたちの意見

以前はモノレポに反対だったんだけど、最近Claude Codeにハマって、初めてモノレポの良さが分かった。特にClaudeみたいなツールのおかげでね。技術的には親ディレクトリからいろんなリポジトリを開けるけど、やっぱり一箇所にまとめておく方が楽だよね。フロントエンドとバックエンドの変更も常に同期してるし。今はどっちのオプションでも作業できると思う。
└
親ディレクトリからClaudeを開くのが俺のやり方なんだけど、結構うまくいってるよ。でも、フロントエンドとバックエンドを一緒に変更できる単一のコミットができるモノレポのアイデアは好きだな。これって結構一般的な使い方だし。
└
Claudeのコンテキスト制限について何か懸念や問題はある？
└
backend-repo $ claude --add-dir ../frontend-repo モノレポを選ぶのは、フラグのエイリアスを使いたくないからっていうのも…まあ、できることだと思うけど。
└
同じ理由で、最大のプロジェクトをモノレポに変更したよ。最先端のLLMツールをたくさんいじってて、それらを正しく接続するのが本当に大変だったから、一つにまとめてコンピュータのために楽にしたんだ。
└
Claude Codeは実際に複数のディレクトリで作業できるから、これが絶対必要ってわけじゃないよ！依存関係のリファクタリングが必要なプロジェクトに取り組んでるときは、こういうことをするんだ。
└
モノレポにはずっとファンなんだけど、著者と同じでyarn workspacesはあんまり好きじゃないんだ。React Nativeはホイストで結構イライラするし。最近、実装計画やPRDをリポジトリに入れ始めたんだけど、今のところすごく気に入ってる。AIに良い選択をするための文脈を与えるのに役立ってるよ。
└
これはツール（Claude）によって導入された制限/仮定のように見えるね。複数のリポジトリでも同じようにうまく動作するようにツールを改善できるはず。
└
人間にとってどうなるかも考えてみてよ——複数のリポジトリにまたがって機能を分けてPRを出すと、レビュー過程が茶番になっちゃう（PRを一つのリポジトリにマージしないと一緒にテストできないから）か、コードレビューの認知的負担が大幅に増えるよね。
モノレポの大ファンで、「開発ブランチなし」も支持してるけど、開発とリリースには大きな違いがあるよね。安定したリリースを切ることができて、例えばチェリーピックができるのは重要だし、特にモノレポではそうだと思う。クロスAPI機能、つまりフロントエンドがバックエンドとやり取りする時に、原子的な変更はほとんど嘘みたいなもんだ。常に何らかの安定したAPIを定義するべきだよ。
└
古いブランチを残しておくのが好きだけど、たくさんのところはそれを捨てちゃうんだよね。なんでか理解できない。あと、git squashも嫌い。次のPRのために新しいブランチを作らなきゃいけないのが時間の無駄だと思う。マスターやデブ、メインを引き下ろして、作業中のブランチにマージできるはずなのに。これもGitHubのフォーク方式を好む理由の一つかな。開発者が自分のサンドボックスやブランチを持てるようにして、仕事を進められるようにすれば、準備ができたらPRしてくれると思う。
└
とても興味深いポイントですね。チェリーピッキングが必要な例と、なぜアトミック変更が嘘なのか、いくつか教えてもらえますか？ 私は3つ以上のプロダクトでモノレポを使っていて、今のところ安定したリリースから安定したリリースにデプロイしても問題は起きていません。
└
うちはモノレポを使っていて、新機能にはフィーチャーフラグを使って、デプロイのタイミングをコントロールしてるよ。
└
> "開発ブランチなし"ってことなんだけど、このコメントの意味を説明してくれる？メインブランチで直接開発するってこと？いろんな時間スケールや変更の複雑さをどう管理してるの？タスクやプロジェクトの長さは数時間から数年までバラバラだし、依存関係も単一のシステムからいろんなシステムまで、内部と外部を含めて幅広いよね。
自己宣伝は必要な時だけにするって約束するけど、これがまさに俺が作ってるものなんだ。https://nimbalyst.com/ で、非技術者がClaude Codeを使ってリポジトリとやり取りできるユーザーフレンドリーな方法を作ってる。特にマークダウンに焦点を当ててて、誰も持ってないレンダリングされたマークダウンファイルの赤/緑の差分を提供してる。開発者もサポートしてるけど、VSCodeのフォークよりもずっとユーザーフレンドリーになるのが目標なんだ。内部では、ここで話してることをたくさんやってて、デザイン作業やビジネスプラン、マーケティングをメインリポジトリでClaude Codeを使って進めてるよ。
└
俺がやってるクレイジーなことは、ワークツリーを使わないこと。複数のClaude Codeインスタンスを同じプロジェクトで同時に使って、例えば一つはログイン画面のCSSを編集してる間に、もう一つはプロジェクトの設定セクションを変更してるんだ。
└
マーケティングにおけるモノレポの著者の経験が気になるな。技術的じゃないPMと静的サイトジェネレーターを使うと、PMがWordPressやContentfulで独立して扱える仕事が増えて、エンジニアが不満を感じることが多かった。モノレポの大ファンとして、非エンジニアをモノレポのワークフローに取り込む方法について、みんなの意見を聞きたいな。
「一つの変更、どこでも、一度に」って話があるけど、それはAPIの変更で本番環境を壊す素晴らしい方法だよ。もしデータベースがあってノードが2つ以上あったら、古いスキーマを使ってる古いシステムと新しいスキーマを使ってる新しいシステムが共存することになる。前方互換性や後方互換性の変更を設計しない限りね。データベースのスキーマではもっと明らかだけど、ネットワークAPIでも同じことが言える。いつか多くのチームができるし、その中の一つはアップグレードを検証して受け入れられないことがある。もしかしたら、リグレッションが原因で彼らだけが使ってる何かが壊れるかもしれない。そうなると、組織全体が一つのチームのバージョンのニーズに囚われることになる。こういうことは少し大きな組織ではよくあるよ。何度も見たことがあるし。すでに後方互換性を持たせるように変更を設計しなきゃいけないなら、段階的なロールアウトを活用するのはどう？AWSが何かを更新した時にアプリを一緒に更新する？それともメールサービスプロバイダーがAPIを拡張した時に？もちろん、そんなことはしないよね。他のチームに自分を縛る必要もないし。モノレポはクロスコンタミネーションやAPIの境界を越える温床になりがちだけど、AIのためのすべてのコンテキストを一箇所にまとめるのはなかなか難しいよね。
└
なんで全部のコードを一つのリポジトリに保存することから、コードを同時に更新・デプロイするっていう論理的飛躍が生まれたのか、ちょっとわからないな。コードをどこに置くか（リポジトリ）は、変更をデプロイする方法とは切り離して考えるべきだよ。 > 古いシステムは古いスキーマを使い、新しいシステムは新しいスキーマを使うことになるよ、前方・後方互換性を考慮しない限り。もちろん、変更は後方互換性を持たせるように設計するよね。たとえ単一のノードで、ネットワークAPIがなくても。だって、ロールバックが必要になったらどうするの？ > もしかしたら、リグレッションが原因で特定のチームが使っている機能が壊れるかもしれない。そうなると、全体の組織が一つのチームのバージョンのニーズに囚われることになる。これは技術的な問題じゃなくて、組織的な問題だよ。一体誰がその一つのチームに、全体の組織に利益をもたらす大きな変更を妨げる権限を与えているの？ こういう人質状態には、しっかりしたディレクターやリーダーが「ノー」と言わないといけない。個々のチームのニーズと全体の組織のニーズをバランスさせる明確なポリシーが必要だよ。新機能を求めるチームと安定性やリグレッションを避けたいチームの間で、互いに受け入れられる妥協点を見つけるために話し合う必要がある。
└
100%、これは全て真実で、最終的には対処しなきゃいけないことだよね。こういう会社（Kasava）は、まあ、顧客が少ないからやり過ごせるんだろうけど、国際的な顧客が24/7あなたのSaaS製品に依存している規模で運営していると、数分のダウンタイムが重要になってくる。モノレポが悪いわけじゃないけど、いくつかのことに対して明らかにナイーブだよね； > 同期の問題なし。どのリポジトリが現在の価格を持っているかの「待って」もなし。3つのチーム間でのデプロイ調整もなし。変更は一つ、どこでも瞬時に。文字通り「一つの変更」を同時にデプロイするのは不可能だよ、最もシンプルなn層アーキテクチャでも。データベースのスキーマがいい例だよ。データベースのスキーマとアプリケーションコードを同時に変更することは物理的に不可能だよ。後方互換性を確保するか、古いアプリケーションコードが新しいデータベースに対して動作している間にダウンタイムが発生することを受け入れるか、どちらかだよ。そして後者は、予期しないデータが本番環境にあって自動DBマイグレーションが失敗する事故が起こるまでうまくいくけど、そのせいでデプロイされたコードが壊れて、オンコールのエンジニアがマイグレーションを修正するかアプリケーションコードをロールバックしてサイトを修正するかを判断するのにパニックになる。もっと皮肉を言うと、これは明らかに一時的なOpenAIラッパー会社が生成したAIブログ記事で、彼らはおそらくほとんど顧客がいないし、12ヶ月後には存在しないだろうと思う。顧客が少ないと、どんなエンジニアリングのパラダイムでも機能するから、単に重要じゃないんだよね。
└
前方互換性のあるデータスキーマの変更が厄介だと信じている人たちが、業界でスケールして生き残れるのか全く理解できない。実際、この問題を持たないのはすごく簡単だよ。「前方・後方互換性のある変更を考慮して設計する」って、成熟したプログラマーなら誰でもやってることだし。
└
ちょっと意見が違うかも。うちはモノレポを使っていて、自動コード生成（openapi-generator）を使って、サーバーフレームワークから生成されたOpenAPI.jsonに基づいて各サービスのAPIクライアントを作ってる。サービスクライアントの変更はすぐに反映されるよ。Gitをトレースして、どのプロジェクトが変更されたか（依存関係も含めて）を把握するカスタムCIジョブがあって、どのサービスを再構築・再デプロイする必要があるかを計算してる。もしかしたら、まだスケールしてないのかも—神様に感謝。うちは小さなチームだから。
└
特にアトミックアップデートって、C-suiteには良さそうに聞こえるけど、下のレベルではめちゃくちゃ崩れるんだよね。大きなプロジェクトがひどいことをして、マイナーなリファクタリングを無限に先延ばしにするせいで、重要なアップデートが数ヶ月遅れるのが普通になってる。でも、そいつらは大きいから政治的な力を持ってて、毎回逃げ切ってる。さらに悪いことに、ライブラリのオーナーとしては、すごく小さな変更が安全かどうかを確認するのに信じられないほどの時間を費やさなきゃいけない。リスクの低い初期採用チームに段階的に展開できないから、機能フラグをめちゃくちゃに設定しないといけないし、何か見落としたら、ロールバックして、レポートを書いて、「うっかり」って言うのに何回も会議で長々と説明する羽目になる。で、機能フラグが実際に機能するかを数週間かけて確認することになるんだけど（実際には、あなたのプロジェクトを使ってる27チーム以上では機能してない）、それから再挑戦。しかも、他の人たちもそのキューに引っかかってるし。モノレポは本当に最悪だと思う。ほとんどが会社のロックインで、他の仕事で必要なスキルをほとんど教えてくれないし（オープンソースに貢献するためにも - エコシステムにとっては脳の流出だよ）、外部のスキルは無駄になる。だって、モノレポはゴミのフラクタルスノーフレークだから。
└
> AIのためにすべての文脈を一箇所にまとめるのは、なかなか良いアイデアだね。ちょっと変な回避策に思えるけど、複数のリポジトリをワークスペースにクローンすればいいだけだし。他のポイントには同意するよ。
└
いつもこの問題があるから、APIにはリリースプロセスが必要なんだよ。モノレポでもそうじゃなくても、悪いソフトウェア開発者はこの問題に直面することになる。ほとんどのソフトウェアは「多くのチーム」で作られてるわけじゃないし、ほとんどはニッチなことをやっている小さな会社が書いてる。複数のチームを持つ大手ソフトウェア会社は、通常リリースマネージャーがいるよ。私のアドバイスは、外部向けAPIにはアーキテクチャの単体テストを使うこと。小さな会社なら、24/7が必須ってわけじゃないから、顧客にちゃんと伝えればいいけど、全体的にSaaSソフトウェアを運営していて、2025年や2026年にゼロダウンタイムデプロイメントのやり方がわからないなら、今やってることを続ければいいよ。ほんと、なんでそんなこともわからないのか…。
└
> いつかは多くのチームができるよ。そしてその中の一つは、アップグレードを検証して受け入れることができないだろうね。もしかしたら、回帰が原因で彼らだけが使っているものが壊れるかもしれない。そうなると、組織全体が一つのチームのバージョンの要件に囚われることになる。うん、これは少し大きな組織でも起こることだよ。何度も見たことがある。すべてのサービスがそれぞれのライブラリのバージョンを持っていて、決して更新しないという選択肢の方が悪いけどね。
これ、隣接するものにもいいよね。会社のウェブサイトが同じリポジトリにあると、ブログからブランド素材や会社のトーンが見つけられるから、顧客向けのスライドや動画デモも作れるし。さらに言うと、Docs + Code、バグや問題も一緒に管理したらどうかなって思う。
これは一種の全体的なプロダクトだけど、会社全体を管理しているわけじゃないよね。財務？人事？契約？最後のチームミーティングの写真？普通のフロントエンド＋バックエンドのモノレポに見えるけど、マーケティングフォルダが少し変わっただけ。
└
そうだけど、AI！AI！
└
実際に誰かが本物を見せてくれるのを楽しみにしてる。つまり、'artifacts'を含むすべてがGitHubリポジトリにある状態。リポジトリ自体から再構築できないアーティファクトもね。もしかしたらそれらは暗号化されていて、「暗号化キーはCEOが物理的に所有しているから、これがすべてだけど」って言えるかも。すべてを一か所にまとめる力ってすごいと思う。GitHubがプライベートフォルダの概念を追加するかも？でもそれはACLの話だし…ツールを押し進めすぎかもね。
└
インフラストラクチャーをコードとしても、リポジトリには見える限り入ってないみたいだね。
└
リンク先の記事を数クリックで見てみると、この会社は（少なくともLinkedInによると）一人だけみたいだね。だから、会社全体がリポジトリに収まるのも納得。でも、ここでの「インサイト」がどれだけ価値があるのか疑問に思わせるね。明らかに一人プロジェクトはモノレポを使うべきだし…。
前のスタートアップ、Pangeaでこんなのを作ったことがあるよ。[1] 全体的に振り返ると、またやりたいと思うけど、万能薬ではないね。遭遇したデメリットはこんな感じだった - リポジトリを通じて全てを進めることに賛同を得ること。機能フラグもリポジトリ内のyamlファイルで管理していて、機能フラグを更新するのにかかる時間に人々がすぐにイライラし始めた（MRをオープンして、MRをマージして、CIが環境で機能フラグを更新するまで）、それを最適化するのにかなり時間がかかった。これが、ブランチの不変条件を考えるのを難しくした（本番ブランチにあるものがライブ環境にあるものだけど、機能フラグを除いて）。だから、モノレポから実際のサービスに移した。 - CIの時間と複雑さ。独立してデプロイするサービスが20個くらいになると、GitLabがCI設定のサイズに耐えられなくなって、パイプラインが立ち上がる前に約5分間スピナーが回っていた。上記の機能フラグシステムのような特殊なものと組み合わせると、最終的にはロールアウトのエッジケースがどう機能するかを正確に知っているのは数人だけになった。その時点で、得られるものに対してコストが見合わなかった（得られるものは「リポジトリが全ての真実のソース」ってこと）。 - テスト時間。Cypressでe2e UIテストをいくつか実行していて、たくさんの強力なインスタンスが必要だったので、安全のために毎回実行していた。それにフレーク性が加わると、目標が常に100%グリーンなのに、赤いパイプラインがたくさんできてしまった。それでも、たくさんの良いことも得られたよ。特に、サービスのうち2つを除いて全てをARMで動かすように更新した日をはっきり覚えている。誰もm8gスポットインスタンスを使っていなかったから、その月のコンピュートコストが70%も下がったんだ。[1]: https://pangea.cloud/
└
ターボ、バックス、またはベイゼルを使った？モノレポのツールがないと（それを自分のユースケースに合わせて磨くための血と汗と涙を含めて）、CIでいろんなスケーリングの限界にぶつかるよね。
> Claudeに「新しい制限を反映するように価格ページを更新して」と頼むと、できる…え？マーケティングページを同じリポジトリから運営してるのに、LLMに更新させるの？データファイルは手元にあるんだから、設定ファイルから価格情報を読み込んで表示すればいいじゃん？
└
AIが一部の人にとっては中毒や頼りになる存在になってきてる気がする。
この投稿は明らかに（ほとんど侮辱的に）AIによって書かれたものだね。とはいえ、投稿のアイデア自体は良いと思う（IaCを極限まで持っていった感じ）。だから、どう感じるべきかすごく微妙な気持ちになってる。
└
せめて「なぜこれが重要なのか」みたいな明らかな部分を2分くらいかけて変えればいいのにって思うよね…。
└
ここでのコメントの中で、明らかにLLMっぽさに気づいてるのはほんの少しの割合だけってのが変だね（最初は気づかなかったけど、2回目の読みにしてみたら、あなたの言う通りだ）。これからLLMスタイルがもっと一般的になってきたら、これらのブログ投稿を振り返って、どれだけ露骨だったかに恥ずかしくなるんじゃないかって思ってる。モデルは改善されるし、人々もモデルの出力をそのままブログ投稿に使うのは無理だって気づくようになるだろうし、これらの投稿はすごく目立つ存在になると思う。（ちなみに、上のは100%人間が書いたよ ;)
└
記事の冒頭で明記されてないと、知的な不誠実に感じる。AIに関しては、著者がその使い方について正直であれば全然問題ないんだけど、LLMが少なくとも重要な部分を書いたってことを明確にしないで自分の名前を記事に載せるのは、不誠実に感じてしまう。そうなると、記事から距離を置いちゃうんだよね。
この文章、まるで4oが書いたみたいだね。人間が作ったコンテンツを見つけられないのが本当に疲れる。
└
そうだね、そう読めるし、ランダムなAI検出器（GPTZero）を信じるなら、ほぼ全部AI生成だって。明らかにAIっぽい表現「これはただの…じゃない」、「課題（そして私たちの対処法）」、「1つのPR。1つのレビュー。1つのマージ。すべて一緒に出荷。」がそのまま残ってるのが信じられない。これを書いた人が全然気にしてないっていうサインだよ。
└
AIの文章について文句を言ってる人を見るのが疲れるよね。じゃあ、代わりに何を求めてるの？ひどい記事？