すべてをコードで: 1つのモノレポで会社を運営する方法

 (kasava.dev)
3 ポイント 投稿者 GN⁺ 2026-01-01 | 1件のコメント | WhatsAppで共有
  • Kasava は、製品開発の全工程を 1つの モノレポ(monorepo) 内で管理し、コード・ドキュメント・マーケティング・運用データをすべて統合
  • すべての変更が 単一コミット で反映され、バックエンド、フロントエンド、ウェブサイト、ドキュメントが同時に更新される構造
  • AIツール がコード・ドキュメント・ウェブサイトを直接参照して、一貫性検証、自動ドキュメント更新、コンテンツレビューなどを実行
  • CLAUDE.md、Selective CI/CD、独立した npm プロジェクト構造 などにより、大規模リポジトリの複雑さを最小化
  • このアプローチは AIネイティブな開発文化 を強化し、製品・コンテンツ・運用の境界を取り払い、迅速なデプロイとコラボレーションを可能にする

AIネイティブ開発とモノレポの意味

  • Kasava は、すべてのプラットフォーム構成要素を 1つの Git リポジトリ に統合し、コードだけでなくドキュメント・マーケティング・メール・投資資料まで含めている
    • 例: frontend/, backend/, website/, docs/, marketing/, external/ など、5,470個以上の TypeScript ファイルで構成
  • AI がコードとドキュメントに同時にアクセスし、コンテキストベースの自動化 を実行
    • ドキュメント修正、ウェブサイトの価格変更、ブログ検証などが AI との単一の会話で処理される
  • すべての変更は同じ Git ワークフロー(git push) でデプロイ
    • コード、コンテンツ、ドキュメント、マーケティングが同一のレビュー・CI/CD・監査手続きを通る
  • この方式は 速度と一貫性 を高め、「すべてをコードで管理する」文化を定着させる

1つのリポジトリに統合する理由

  • 境界をまたぐ原子的変更(Atomic Changes)
    • バックエンド API を修正する際、フロントエンドの型定義とドキュメントも同じコミットで更新
    • 例: Asana 統合機能を追加する際、バックエンド・フロントエンド・ドキュメント・ウェブサイトが 1つの PR でマージされる
  • 単一の信頼できる情報源(Single Source of Truth)
    • billing-plans.json 1つで料金プランの制限を定義し、すべてのサービスがこれを参照
    • AI がバックエンド・フロントエンド・ウェブサイト間の一貫性を自動検証
  • クロスプロジェクトのリファクタリング
    • IDE でコード全体・ドキュメント・ブログのサンプルまで検索・修正可能
  • 共有ツールとパイプライン
    • 共通 CI/CD、依存関係、検索環境により管理を簡素化

リポジトリ構造と構成要素

  • Core Application:
    • frontend/ は Next.js 16 + React 19 ベース、backend/ は Cloudflare Workers + Hono + Mastra を使用
    • API 変更時に型安全性とテストユーティリティを共有
  • Marketing:
    • website/, marketing/blogs/, investor-deck/, email/ を含む
    • ブログ・メール・投資資料もすべてコードとしてバージョン管理され、git revert でロールバック可能
  • Documentation:
    • docs/ は Mintlify ベースの公開ドキュメント、docs-internal/ は内部アーキテクチャ文書
    • コードと一緒に検索でき、Wiki の代わりにリアルタイムで最新情報を維持
  • External Services:
    • Chrome 拡張、Google Docs Add-on、GCP Functions など、外部にデプロイされるサービスを含む
    • API 契約を共有することで、変更時に同時反映される
  • Development Infrastructure:
    • github-simulator/, infra-tester/, scripts/ など、ローカル開発向けのモックサーバーやテストツールを含む

運用方法と開発文化

  • ワークスペースを使わない
    • 各ディレクトリを独立した npm プロジェクトとして維持し、依存関係の衝突を防止
  • 選択的 CI/CD(Selective CI/CD)
    • GitHub Actions がパスベースでトリガーされ、関連するテストだけを実行
  • CLAUDE.md ルール
    • 各主要ディレクトリに技術スタック、コマンド、アーキテクチャ上の決定を文書化
    • AI アシスタントがこれを読んでプロジェクトの文脈を理解
  • 一貫したツール設定
    • .prettierrc, .eslintrc, tsconfig.json などの共通設定を維持

課題と対応

  • リポジトリのサイズ: 現在のクローン時間は約20秒で、Git の性能問題はない
    • 大容量アセットは R2/S3 に分離予定
  • ビルド時間: 各プロジェクトを独立してビルドし、Turbopack・Wrangler・WXT により高速に再ビルド
  • 権限の境界: 小規模チームでは全体にアクセス可能で、必要に応じて CODEOWNERS・ブランチ保護を適用可能
  • コンテキスト切り替え: さまざまな言語(TypeScript, Apps Script, MJML) 間の切り替えは、CLAUDE.md と統一フォーマットで緩和

結論

  • Kasava のモノレポは単なるトレンドではなく、コンテキスト統合によって生産性を最大化するためのツール
  • バックエンド・フロントエンド・ドキュメント・マーケティングが 1つの変更として動作し、AI がこれをリアルタイムで検証
  • 結果として、「モノレポは制約ではなく 加速装置(force multiplier) である」と機能する

関連記事

1件のコメント

 
GN⁺ 2026-01-01
Hacker Newsの意見

  • これは会社全体を管理しているというより、単に 1つの製品（monorepo） に見える
    財務、HR、契約書、チーム写真のようなものはなく、フロントエンド+バックエンド構成にマーケティング用フォルダが少し変わった形で含まれている程度だ

    • リンク先の記事を見ると、この会社は実質 1人会社 だと分かる
      だからすべてを1つの repo に入れられるのだろうが、そういう状況で得られる「インサイト」の価値には疑問がある
    • 「AI! AI!」
    • repo の中に インフラコード（IaC） も含まれていない
    • 本当にあらゆるものを GitHub repo の中に入れた事例を見てみたい
      たとえば 暗号化されたアーティファクト まで含めて、「暗号鍵は CEO だけが物理的に保有する」という形のように
      GitHub が private folder の概念を追加してくれるとよいが、それは ACL の問題なので要求が大きすぎるかもしれない

  • 私は monorepo と no development branch の哲学を支持する
    ただし開発とリリースは分けるべきだ
    安定版リリースを切って cherry-pick できる必要があり、フロントエンドとバックエンド間の API の安定性 は必ず維持されなければならない

    • 「no development branch」とは何を意味するのか、と尋ねる人もいた
      メインブランチに直接開発するなら、さまざまな規模の作業をどう並行管理するのか気になるという
    • cherry-pick が必要になる具体例を尋ねる人もいた
      自分は 3 つ以上の製品を monorepo で運用しているが、安定リリース単位でデプロイしても問題はなかったという
    • feature flag でデプロイ時点を制御しているという人もいた
    • 古いブランチを維持するのが好きだという人もいた
      git squash は嫌いで、forking 方式 の方が開発者により自由な環境を与えると述べていた

  • 「1回の変更ですべての場所が同時に更新される」という話は 危険な幻想 だ
    DB や API があるシステムでは常に 後方互換性 を考慮しなければならない
    複数チームがある組織では、あるチームがアップグレードを検証できず全体の足を引っ張ることがある
    だから段階的ロールアウトが必須だ

    • 完全に同意する。小さな会社（Kasava）ならともかく、グローバル SaaS では 数分のダウンタイム でも致命的だ
      monorepo 自体は悪くないが、「1回の変更ですべてが即時にデプロイされる」のは不可能だ
      DB スキーマとコードを同時には変えられないからだ
      こういう記事は AI が書いたブログ のように見えるし、実際の顧客もほとんどいないように思える
    • コードの保存場所（repo）とデプロイ方法は切り分けるべきだ、という反論もあった
      組織の問題を技術の問題と取り違えず、チーム間の方針とリーダーシップ で調整すべきだという
    • monorepo と 自動コード生成（openapi-generator） を使って、サービス間 API の変更を即座に反映しているという人もいた
      小さなチームだから可能なアプローチだとも付け加えていた
    • 「AI コンテキストを1か所に集めるのが強み」という話に対し、複数の repo を workspace として clone すればよいという意見もあった
    • 逆に、すべてのサービスがそれぞれバージョンを維持したまま更新しない状況の方が悪い、という意見もあった

  • 以前は monorepo が嫌いだったが、Claude Code を使って考えが変わった
    フロントエンドとバックエンドが1つの repo にあれば同期しやすい

    • 親ディレクトリで Claude を開いてもうまく動くが、単一コミットで両方を同時に変更 できる点がよいという
    • 「monorepo を使う理由が単にコマンドフラグを減らすためだけなら、ちょっと笑える」という反応もあった
    • 自分も複数の LLM ツール をつなげるのが難しくて monorepo にリファクタリングした
    • React Native の hoisting 問題 があるので yarn workspace は避けるが、PRD や計画文書を repo に入れるのは AI に文脈を与えるうえで有用だった
    • Claude Code は実際には複数ディレクトリを同時に扱えるので、monorepo が絶対に必要というわけではない

  • この記事は AI が書いたように 感じられる
    人間が書いたコンテンツを見つけにくくなっていて、うんざりする

    • GPTZero にかけると、ほぼすべて AI 生成に見える
      「This isn’t just for…」「The Challenges (And How We Handle Them)」のような文は典型的な AI 口調 だ
    • 逆に、「AI の文章だと文句を言うのももう飽きた」という意見もあった
      完璧でなくても人間が書いた文章よりましではないか、という感じだ

  • 「Claude に価格ページを更新しろと言う」という部分が奇妙だ
    マーケティングページを同じ repo で管理しながら、単に config ファイルのデータ を読めば済むことを LLM に任せるのは納得しがたい

    • AI が 中毒や依存 に変わりつつある、という指摘があった
    • 「コードレビューは今も存在する」という反論もあった
      AI があるからといって人間が確認しないわけではない、ということだ

  • 「フロントエンド、バックエンド、ウェブサイト」を1つの repo に入れるのは混乱を招く
    コミット単位で統合できるのはよさそうだが、3つの repo でも十分に管理可能 だ
    monorepo をきちんと運用するには 維持コストがかなり高い

  • 記事は AI が書いたように見えるが、IaC を極端に拡張したアイデア 自体は興味深い
    だから気持ちは複雑だ

    • コメントの大半が AI 作成っぽさに気づいていないのが不思議だった
      今後こうした LLM スタイル が大衆に慣れたものになれば、今の文章は野暮ったく感じられるかもしれない
    • 「Why This Matters」のような表現だけでも変えてほしかった、という意見もあった
    • AI の使用を明示せず人間の名前で投稿するのは 知的に不誠実 に感じる、という声もあった

  • 会社のウェブサイトを同じ repo に置けば、ブランディング資料やトーン を簡単に見つけられる
    そのため顧客向けスライドやデモ動画を自動生成しやすい
    さらに 文書、バグ、イシュー まで1か所に入れるのも興味深い

  • 以前のスタートアップ Pangea で似た構成を作ったことがある
    全体としてはよかったが、完璧ではなかった

    • すべてを repo で管理しようとしたため、feature flag の変更 が遅くなり、ブランチ不変性の管理も難しかった
    • サービスが 20 個ほどになると GitLab CI が遅くなって複雑化 した
    • E2E テスト が遅く不安定で、パイプラインがよく壊れた
      それでも ARM へ移行して コンピューティングコストを 70% 削減 といった成果もあった
      Pangea リンク
    • これに対して「turbo, buck, Bazel のような monorepo ツールを使ったのか」と尋ねる人もいた
      こうしたツールがなければ CI のスケーラビリティ限界にぶつかる、という