Zenn で 2026 年 5 月 8 日に AI に「リポジトリの地図」を渡す — マルチレポを束ねるセントラルリポジトリ設計 という記事が公開され、トレンド入りしました。**「AI コーディングエージェントを複数リポジトリで使うと毎回コンテキストが空っぽから始まる」という現場課題に対し、「セントラルリポジトリで地図を集約する」**設計パターンを提示した内容です。
弊社では、受託で常時 10〜30 件のリポジトリを並行運用しており、案件横断で 「AI に同じ説明を毎回させる」コストが運用上の重荷になっていました。本記事では、セントラルリポジトリ設計を受託会社で運用するときの構成、契約条項、価格モデルを整理します。
何が課題なのか — マルチレポ × AI の 4 大摩擦
複数リポジトリを抱える受託会社で、AI エージェントを使うと頻発する 4 つの摩擦です。
| 摩擦 | 実例 | 影響 |
|---|---|---|
| コンテキスト初期化コスト | 案件切替のたびに AI に説明 | 月 30〜50h の浪費 |
| 規約のばらつき | 命名 / Lint / テスト戦略が案件ごと | レビュー基準が崩壊 |
| 過去解決の再発見 | 同じバグを別案件で再度解く | 知見の再利用率 <10% |
| 依存の多重管理 | 同じライブラリを別バージョンで | アップグレード事故 |
特に **「コンテキスト初期化コスト」が最大の浪費源で、「セントラルリポジトリに案件横断の地図を集約する」**だけで月数十時間の工数が浮きます。
これは agents.md / skill.md / design.md を受託で組む で扱った設計指針を 「単一案件内」から 「会社全体のリポジトリ群」にスケールアップする発想です。
受託で組むセントラルリポジトリの 4 階層
弊社では、セントラルリポジトリを以下の 4 階層で構成しています。
[Tier 1: 全社地図（central/map）]
├ 全リポジトリのインデックス
├ 各リポジトリの一行サマリ + 担当チーム
└ 横断検索用のタグ・キーワード
[Tier 2: 全社規約（central/standards）]
├ コーディング規約 / Lint / フォーマッタ設定
├ テスト戦略 / カバレッジ閾値
└ セキュリティ / 認証 / ログのデフォルト
[Tier 3: 案件メタ（central/projects/{name}）]
├ アーキテクチャ図 / ER 図 / シーケンス
├ 過去の意思決定ログ（ADR）
└ よくある質問 / トラブルシュート
[Tier 4: 共有スニペット（central/snippets）]
├ 案件横断で使う実装パターン
├ 言語 / フレームワーク別のベストプラクティス
└ AI が引用しやすい単位で粒度を揃える特に Tier 4 の共有スニペットは、「過去案件で書いた認証コード / ファイルアップロード / WebSocket ハンドラ」を AI に渡しやすい形に整えておくと、新規案件の立ち上げが 30〜50% 短縮されます。
これは GitHub CodeQL 宣言型セキュリティモデリング で扱った “知見の資産化” を、「セキュリティ」から 「実装全般」に拡張する形になります。
セントラルリポジトリへの「アクセス権設計」
受託会社特有の制約として、「顧客 A の機密情報が顧客 B のエージェントに漏れない」設計が必須です。
| アクセス階層 | 対象 | 公開範囲 |
|---|---|---|
| 公開地図 | リポジトリ存在 + 公開タグ | 全社員 |
| 規約・スニペット | 全社共通の知見 | 全社員 + 全エージェント |
| 案件メタ | 案件名 / 担当 / アーキテクチャ概要 | 該当案件メンバー |
| 案件詳細 | 顧客名 / 機微データ / 認証情報 | 該当案件メンバーのみ |
特に 「案件詳細」を Tier 3 に紛れ込ませると 「AI が別案件の文脈を出力する」事故が起きます。Tier 3 の案件メタは “顧客名抜き” で記述することを規約化します。
受託契約に書く「知見再利用条項」
セントラルリポジトリで案件知見を再利用する受託契約に明記すべき条項です。
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 知見の所有権 | 案件成果物の汎化版を弊社に帰属 | 競合他社への流出防止 |
| 匿名化義務 | 顧客名 / データを必ず匿名化 | 機密保持の担保 |
| 再利用範囲 | 業界別 / 言語別の再利用許諾 | 競合排除条項 |
| 顧客側のメリット | 過去案件知見の活用が前提 | 再利用の双方向性 |
| アップデート権 | スニペットの改善を顧客に還元 | 継続的な品質向上 |
特に **「匿名化義務」は最初に明文化しないと、「自社のロジックが他社の AI に出力された」という最悪のクレームに繋がります。「顧客名 / 商品名 / 数値は必ず匿名化」**を契約条項に明記します。
これは ソースコード secrets 監査を受託で運用する で扱った “受託のセキュリティ責務” の延長で、「知見再利用にはセキュリティと法務の両輪が必要」になります。
価格モデル — セントラルリポジトリ運用パッケージ
セントラルリポジトリを運用する受託会社内部の投資 / 案件への波及は、以下の構造で考えています。
| プラン | 投資規模 | 対象 | 内容 |
|---|---|---|---|
| CR Lite | 構築 200 万円 / 運用 月 8 万円 | 5〜10 案件規模 | Tier 1-2 + 月次更新 |
| CR Standard | 構築 600 万円 / 運用 月 30 万円 | 10〜30 案件規模 | Lite + Tier 3-4 + アクセス権管理 |
| CR Enterprise | 構築 1,500 万円〜 / 運用 月 80 万円〜 | 30 案件以上 / 上場 | Standard + 専任ライブラリアン |
弊社の現状規模は CR Standard に該当し、ROI として 「案件立ち上げ期の工数 30% 削減」+「過去案件知見の再利用率 50%」を回収目安にしています。
ハマりやすい 5 つの落とし穴
最後に、セントラルリポジトリを受託会社で運用するときに踏みやすい落とし穴を共有します。
落とし穴 1: 全部を 1 リポジトリに突っ込む
全案件のコード + ドキュメントを 1 リポジトリにすると、git の操作が遅くなり AI のコンテキストも肥大化します。地図だけを集約 / コードは各リポジトリのままが原則です。
落とし穴 2: 担当者に更新を任せる
「気づいた人が更新」ルールにすると 3 ヶ月で死にます。月次の “セントラル会” + ボット PRで強制的に更新を回します。
落とし穴 3: 機密情報の混入
「うっかり顧客名を ADR に書く」事故は必ず起きます。コミット時の自動 lint で固有名詞を検出し、merge を止める仕組みを入れます。
落とし穴 4: AI に全部渡す
セントラルリポジトリ全体を AI に投入すると トークンが爆発します。地図を渡し、必要なノードだけを取りに行く RAG 構成にします。
落とし穴 5: ドキュメントが古くなる
最も多い失敗が 「半年放置で誰も信じない」状態です。各 Tier に最終更新日 + 失効バッジを表示し、3 ヶ月超は警告を出します。
まとめ — 「案件ごとに AI を育てる」をやめる
セントラルリポジトリは、受託会社の **「案件横断の知見をエージェントに渡せる形に整える」ための基盤です。「案件ごとに AI を一から育てる」**運用は、案件数が増えるほど指数関数的に苦しくなります。
弊社では、自社で CR Standard 規模のセントラルリポジトリを運用しており、この設計知見を クライアントの社内マルチレポにもセントラル化を導入する受託として提供しています。「社内に複数のリポジトリがあって AI が迷子になる」「過去プロジェクトの知見が属人化している」というご相談は お問い合わせフォーム からお気軽にどうぞ。
