# リポジトリの管理

> リポジトリごとに監視を有効/無効にし、プラン上限を理解し、AI が分析するブランチを選び、履歴のバックフィルがカバーする範囲を把握します。

Source: https://latchkey.dev/ja/documentation/managing-repositories

## Summary

- owner と admin は **監視モーダル** でリポジトリを有効/無効にします。変更は保存時に適用されます。
- プラン上限: 1 (Developer)、10 (Launch)、40 (Scale)、無制限 (Enterprise)。
- 有効化するとリポジトリが登録され、直近 30 日間の完了済み実行 (最大 500 件) をバックフィルします。無効化するとそのデータはアーカイブされます。

Latchkey は、明示的に有効にしたリポジトリのデータのみを取り込みます。オンボーディング中にそれらを選択し、ダッシュボードからいつでも変更できます。有効化はリポジトリをマネージドランナーの対象にするものでもあります。マネージドランナーは監視対象のリポジトリのみを扱います。

## 監視モーダル

ダッシュボードのサイドバーで **Monitoring** (ワークスペースの owner と admin に表示) をクリックすると、**リポジトリ監視の管理** が開きます。ヘッダーには、プラン上限に対して使用しているリポジトリ数が表示されます。各リポジトリにはトグルがあり、変更は「保留中の変更」としてキューに入り、**変更を保存** をクリックすると一緒に適用されます。

- **検索とスクロール:** リストは組織をリアルタイムで検索し、スクロールに応じてさらに読み込みます。
- **ブランチセレクター:** 監視対象の各リポジトリには、Latchkey の AI がワークフロー最適化のために分析するブランチを設定するブランチピッカーが表示されます (デフォルトはリポジトリのデフォルトブランチ)。他のブランチにのみ存在するワークフローは分析されません。
- **権限:** 監視の有効化と無効化には owner または admin ロールが必要です。

## プラン上限

| プラン | 監視対象リポジトリ |
| --- | --- |
| Developer | 1 |
| Launch | 最大 10 |
| Scale | 最大 40 |
| Enterprise | 無制限 |

上限に達すると、追加のトグルはブロックされ、モーダルがアップグレードを案内します。Developer では、唯一の監視対象リポジトリをモーダルから入れ替えることはできません。Launch または Scale へのアップグレードでこれが解除されます。

### 上限内でリポジトリを選ぶ

スロットよりリポジトリが多い場合は、上限を優先順位付けの問題として扱ってください。

- **マネージドランナーで動かしたいものはすべて監視する必要があります。** 監視対象外のリポジトリから `latchkey-*` ラベルを狙うジョブはピックアップされず、GitHub 上でキュー待機のままになります。ランナーの導入が目的なら、それらのリポジトリを優先します。
- **アクティビティの多いリポジトリは、分析に最も多くの材料を与えます。** ダッシュボードと AI の推奨事項はワークフローの実行から構築されるため、1 日に何度も CI を実行するリポジトリは、週に 1 回ビルドするものよりはるかに多くのシグナルを生み出します。
- **慢性的に失敗するパイプラインは有力な候補です。** 信頼性の検出結果は実行の失敗パターンから計算されるため、不安定なリポジトリは AI Insight が最初に真価を発揮する場所であることが多いです。[最適化インサイト](/documentation/optimization-insights) をご覧ください。
- **Developer では慎重に選んでください。** 唯一の監視対象リポジトリはモーダルから入れ替えられないため、CI を最も理解したいリポジトリを選んでください。Launch または Scale へのアップグレードで入れ替えが解除されます。

## リポジトリを有効にすると何が起こるか

バックフィルの実行中はダッシュボードに進捗バナーが表示されるため、何がまだウォームアップ中かが常にわかります。

### バックフィルがカバーするものとしないもの

バックフィルは、1 週間データを集めた後ではなく初日からダッシュボードを役立てるために存在します。直近 30 日間の **完了済み** 実行をインポートし、これはコスト、パフォーマンス、インサイトのページを実際の数字で埋めるのに十分です。ほとんどのチームは数分でデータを確認できます。設定しておくべき期待が 2 つあります。これはサンプルであって完全な履歴のインポートではないこと、そして存在するものしかインポートできないことです。直近 30 日間にワークフローの実行がないリポジトリは何もバックフィルせず、新しい実行が起きるまでそのページは空のままです。ダッシュボードの日付範囲フィルターもアクティビティと重なる必要があるため、バックフィル直後にページが空に見える場合は、何か問題があると決めつける前に範囲を広げてください。

> **バックフィルの深さ**
> バックフィルは直近 30 日間の完了済み実行をカバーし、リポジトリごとに 500 件が上限です。これはダッシュボードを埋めるためのサンプルであり、完全な履歴のインポートではありません。監視を有効にした瞬間以降のすべては完全に記録されます。

## リポジトリを無効にすると何が起こるか

無効化すると、そのリポジトリの取り込みが直ちに停止し、プラン上限に対するスロットが解放されます。その履歴データはダッシュボードに表示される代わりにアーカイブされます。マネージドランナーは監視対象のリポジトリのみを扱うため、そのリポジトリで `latchkey-*` ラベルを狙うジョブは、再度有効にするまで実行されずにキュー待機になります。後で再度有効にすると、新しいバックフィルが始まります。

## よくある質問

### リポジトリを無効にすると、そのデータはどうなりますか？

取り込みは直ちに停止し、プラン上限に対するスロットが解放されます。履歴データは削除される代わりに、ダッシュボードからアーカイブされます。完全な削除はワークスペースを削除した場合にのみ発生します。[セキュリティと GitHub の権限](/documentation/security-and-permissions) をご覧ください。

### リポジトリを再度有効にすると何が起こりますか？

リポジトリを初めて有効にするときと同じように、新しいバックフィルが始まります。直近 30 日間の完了済み実行がインポートされ、実行中は進捗バナーが表示されます。

### Member は監視を有効/無効にできますか？

いいえ。監視の有効化と無効化には owner または admin ロールが必要で、サイドバーの Monitoring 項目は owner と admin に表示されます。ロールについては [チームとロール](/documentation/team-and-roles) で説明しています。

### リポジトリを有効にすると、webhook やファイルが追加されますか？

いいえ。リポジトリごとの webhook は作成されず、リポジトリに何もコミットされません。イベントは組織にインストールされた GitHub App を通じて流れます。

### ブランチセレクターは何を制御しますか？

Latchkey の AI がワークフロー最適化のために分析するブランチです (デフォルトではリポジトリのデフォルトブランチ)。他のブランチにのみ存在するワークフローは分析されないため、インサイトが不完全に見える場合はまずこのピッカーを確認してください。[トラブルシューティング](/documentation/troubleshooting) をご覧ください。

### 監視対象外のリポジトリはマネージドランナーを使えますか？

いいえ。マネージドランナーは監視対象のリポジトリのみを扱います。監視対象外のリポジトリから `latchkey-*` ラベルを狙うジョブは GitHub 上でキュー待機のままになります。まず監視モーダルでリポジトリを有効にしてください。

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt