越境する AI のために、境界を取り払う ── AI 時代の開発体験向上に向けたリポジトリ統合の取り組み shibutani / @s_k_526 2026 年 6 月 11 日 AI時代に適したリポジトリって？カウシェ・LayerXに聞く最新リポジトリ構成 

自己紹介 shibutani / @s_k_526 株式会社 LayerX Platform Engineering 部 Enabling チーム 2025 年新卒入社 最近は CLI 盆栽に勤しむ（特に cc〇〇とか agent- 〇〇を作っています） © LayerX Inc. 2 

今日の内容 

今日の内容 フロントエンドとバックエンドのリポジトリを統合（モノレポ化）した話 © LayerX Inc. なぜ統合したのか ── AI エージェントが変えた前提 統合への不安 どう進めたか ── 学びになった CI 改善 統合がもたらしたもの 4 

1. なぜ統合したのか ── AI エージェントが変えた前提 

前提：もともとは分かれていた もともとの構成 → AI エージェント時代になり、この前提が崩れた © LayerX Inc. バックエンドは Go、フロントエンドは TypeScript 言語もエコシステムも違う 6 

変化①：バックエンドも TypeScript になってきた バックエンドの TS 化 → FE / BE で似た共通パッケージを二重にメンテナンスする辛さが顕在化 © LayerX Inc. AI Agent 開発では Vercel AI SDK など TypeScript 製のバックエンドフレームワークを使うことが増えた 「バックエンド = Go」という前提が崩れ、 フロントエンドと同じ言語・エコシステムを共有 7 

変化②：AI が FE / BE を横断して開発する 順々に → 横断で高速に → リポジトリが分かれていると、追従漏れ・バージョンのミスマッチが起きる → 越境する AI のために、リポジトリの境界を取り払う © LayerX Inc. これまでは FE ・ BE を順々に、別の PR ・開発単位で実装 AI エージェントで FE / BE を横断して一気に開発することが増えた 1 つの変更で FE / BE 両方を見たい 8 

2. 統合への不安 

当初は多くの不安の声があった 不安の中心は「遅くなる・重くなる」 → 不安の核心は、開発体験の悪化への懸念 © LayerX Inc. FE と BE を一つの PR で開発することになる 片方を push すると、もう片方の CI も走る リポジトリが大きくなり、IDE・Git も重くなる 10 

進め方：不安を、速さで打ち返す 取ったスタンス → 不安を減らす最良の手段は、速さで示すこと © LayerX Inc. 統合すると遅くなる、という不安が中心にあった ならば統合を機に、むしろ前以上に速くする 不安を一つずつ、速さで打ち返していく 11 

3. どう進めたか ── 学びになった CI 改善 

テスト実行範囲を絞る main との差分から、変更パッケージとその影響範囲だけをテスト Go：影響を受けるパッケージを逆引き TypeScript：Turborepo / pnpm の affected 機能を利用 © LayerX Inc. 内製 CLI で import グラフを構築し、変更箇所の依存元を再帰的に特定 自動生成ファイル（ .pb.go など）は対象から除外 turbo --affected と pnpm --filter=...[origin/main] 13 

ビルドキャッシュを効かせる 課題：キャッシュが効かない 打ち手 © LayerX Inc. go build は GitなどのVCS 情報をバイナリに埋め込む ソースが同じでもバイナリが変わり、キャッシュミスが起きる -buildvcs=false で VCS 情報を埋め込まない 同一ソース → 同一バイナリとなり、キャッシュがヒット 14 

他にも、速くする工夫を重ねた CIでのcheckout を速くする Go test CI をブロッカー / ノンブロッカーに分割 © LayerX Inc. sparse-checkout で不要なディレクトリを clone しない 履歴が要る場面は blob-less clone でサイズ削減 実行の重い -race 付きテストは main への push 時だけに回す PR 上の CI は軽量・高速に。落ちても気づける仕組み 15 

4. 統合がもたらしたもの 

もたらしたもの：FE / BE の一貫性 統合前：BE / FE で状態がズレる 統合後：状態が常に 1 つに揃う → FE / BE の状態が、常に 1 つに揃う © LayerX Inc. API スキーマが BE / FE でズレる（最新の変更の取り込み忘れなど） 共通ライブラリを BE / FE で二重にメンテナンス BE / FEでスキーマがズレない 共通ライブラリを 1 箇所で管理し、二重保守が消える 17 

もたらしたもの：越境のしやすさ 統合前：リポジトリを往復する（例：API を 1 本追加する） 統合後：端から端まで一気に貫ける → 越境する AI のための土台が整った © LayerX Inc. スキーマ → BE → FE を別々の PR で行き来 開発単位とPRの単位が一致しない スキーマ → サーバ実装 → クライアント実装まで 1 PR、AI に一筆書きで任せられる BE まで含めた Preview環境を提供し、 「動くもの」を触れるように 18 

まとめ © LayerX Inc. なぜ統合したか：TypeScriptがBEにも浸透し、なおかつAI が FE / BE を越境するように 不安：統合すると遅く・重くなるという開発者体験に対する懸念 どう進めたか：不安を、前以上に速くする姿勢で打ち返した もたらしたもの：FE / BE のズレが消え、一気通貫で開発できるように 19 

ご清聴ありがとうございました