# Runners ページ: フリート管理

> ダッシュボードからランナーフリートを管理します: ランナータイプ、構成、使用量と節約、自己修復のアクティビティフィード、一括移行ツール。

Source: https://latchkey.dev/ja/documentation/runners-dashboard

## Summary

- **Runners** ページ = フリートのコストと節約、ランナー構成、自己修復のアクティビティフィード。
- 構成ごとの有効化/無効化、最大同時実行数、カスタムランナーのイメージビルド状況。自己修復は Settings でワークスペース全体として制御されます。
- **Migrate Runners** (サイドバー項目または Runner Types カード、オーナー/管理者) はリポジトリごとに 1 つの PR を、1 回のパスで最大 20 の監視対象リポジトリまで開きます。変更されるのは `runs-on` の行だけで、追加される場合は Latchkey のキャッシュステップが加わります。

マネージドランナーフリートに関するすべては、ダッシュボードのサイドバーにある **Runners** ページ ("Manage your runners and review jobs they've run") にあります。このセクションの残りで説明する機能の運用上の拠点です。

## ページに何があるか

- **フリートメトリクス** この課金期間のランナーコスト、GitHub ホステッド比の推定節約額、そして月間の割り当てに対して使用した無料ティアの分数。
- **Runner Types** Preset Runners (スペックと 1 分あたりの価格を備えた 4 つのサイズ) と AI Scan Runners をカバーする折りたたみ可能なカードで、フッターには Migrate Runners のショートカットがあります。
- **Your runners** ワークスペース内のすべての構成: 名前、ステータス、サイズ、最大同時実行数、自己修復の状態、オン/オフ、そして行ごとの Copy CI snippet アクション。
- **自己修復アクティビティ** 修復の KPI (Total Attempts、Heals、Success Rate)、アクティビティとカテゴリのチャート、そして Recent Heals フィード。

## 5 分間の週次レビュー

このページは短い週次の習慣に報います。おすすめのパス:

**週次フリートレビュー**
- [ ] フリートメトリクス: この課金期間のランナーコストは期待どおりに推移していますか。無料ティアの割り当てはどれだけ残っていますか。
- [ ] GitHub ホステッド比の推定節約額: まだ期待どおりですか。移行が引き続き報われている継続的な証拠です。
- [ ] Your runners: ワークフローがまだ対象にしているのに無効になっているものはありませんか。無効なラベルを狙ったジョブは失敗せずにキューに入るため、見落としやすいです。
- [ ] カスタムランナー: 保留中または失敗したイメージビルドはありませんか。構成の行にビルド状況が表示されます。
- [ ] Recent Heals: 今週はどのカテゴリが優勢ですか。単一のワークフローが繰り返し修復されていませんか。

## Your runners テーブル

**Your runners** テーブル ("Set up runners for your repos. Adjust size, concurrency, and on/off state.") は、ワークスペース内のすべての構成を一覧します: 4 つのプリセットに加えて、あらゆるカスタムランナー。列は名前、ステータス、サイズ、最大同時実行数、自己修復の状態、アクティブ状態をカバーし、テーブルヘッダーには **AI Scan Runners** アクションがあります。最初のランナーを作る前は **Set up your first runner** の空の状態が表示され、保留中のスキャンバナー ("Ready for review") がその上に現れます。各行では次のことができます:

- **有効化/無効化。** 無効化した構成は新しいジョブの受け入れを停止します (そのラベルを狙ったジョブはキューに入ります)。
- **Copy CI snippet**: 誰もラベルを記憶から入力しなくて済むようにします。
- 修復がそのランナーをカバーしているかを示す **Self Healing** 列。コントロール自体は **Settings、Self-Healing** にあるワークスペース全体のスイッチです。
- [カスタムランナー](/documentation/custom-runners) の **イメージビルド状況**: カスタムイメージがまだビルド中か、準備完了かを確認できます。
- 不要になったカスタム構成の **削除**。

無効化と削除は別の仕事をします。無効化は一時停止ボタンです: ラベルは存在し続け、それを狙ったジョブは再度有効化するまでキューに入ります。構成を調査している間の正しい手段です。削除は、永久に用済みになったカスタム構成のためのものです。

### 詳細ドロワー

行をクリックすると、完全な構成を含む詳細ドロワーが開きます: ラベル、OS、vCPU、RAM、ディスク、ベースイメージ、1 分あたりの価格、加えてラベルとコピー可能な GitHub Actions スニペットを備えた **Use in CI** カード。管理者はランナー名、カスタムラベル、**Max Concurrent** (0 = 無制限) を編集できます。管理者以外は同じ詳細を読み取り専用で見るため、チーム全員が各ランナーの提供内容を確認できます。

## Recent Heals

自己修復セクション ("Recent heal attempts, agent reports, and PR proposals across your org.") は、修復の KPI と **Heal Activity Over Time** および **Heal Rate by Category** チャートの下に、各修復をその結果バッジ (Healed、No Action、Failed、または Pending) とカテゴリとともに一覧します。行をクリックすると、完全なレポートを含む **Heal Details** ドロワーが開きます: 何が失敗したか、診断、取られた正確なアクション (平易な言葉で)、そして AI が診断した障害についてはエージェントのイテレーション。[パイプラインパフォーマンス](/documentation/pipeline-performance) で修復された実行は、同じレポートへのディープリンクになっています。自己修復がオフの場合、このセクションは "Self-Healing is disabled." と表示し、Settings で有効化するためのリンクを示します。

このフィードは単なる救済ログではなく、シグナルとして読んでください。多くのワークフローに散らばった単発のネットワーク修復は、レジストリや外部サービスが調子を崩す通常のバックグラウンドノイズです。パターンのほうが興味深いです: 同じワークフローが同じカテゴリで繰り返し修復されるのは、根深い何かを指しています。メモリ修復の繰り返しは [より大きなランナーサイズ](/documentation/runners-overview) を求めるジョブを示唆し、ディスク修復の繰り返しは毎回ディスクを満杯にするジョブを、ツール修復の繰り返しはワークフローが決してインストールしないツールを前提とするステップを示唆します。これらこそ、毎晩救済されるより恒久的な修正が勝るケースです。自己修復がそうした修正をどのように自ら提案するかは [修復プルリクエスト](/documentation/self-healing) を参照してください。

## Migrate Runners

このツールには 2 つの入口があり、どちらも同じ **Migrate runners** モーダルを開きます: ダッシュボードのサイドバーにある **Migrate Runners** 項目と、Runner Types カードのフッターにある CTA ("Already have workflows on GitHub-hosted runners? Migrate them to Latchkey runners in a few clicks.") です。このセクションはモーダルそのものを扱います。正確なラベルマッピング、PR の内容、検証、ロールバックを含む完全なガイドは [GitHub ホステッドランナーからの移行](/documentation/migrate-from-github-hosted) です。

各プルリクエストは、サポートされるすべての `runs-on` ラベルを適切な Latchkey サイズに書き換え (標準の Ubuntu ラベルは `latchkey-small` になります)、それ以外には一切触れません。Windows と macOS のジョブ、認識されないラベル、`${{ }}` 式を含む行はそのまま残されます。各ファイルの変更前後のマッピングテーブルが、何が変わったかを正確に示すため、レビューには数日ではなく数分しかかかりません。

- PR が開かれると、モーダルはそれぞれを PR 番号と View PR リンクとともに一覧します: "Opened N pull requests. Merge each on your schedule."
- リポジトリに既に開いている移行プルリクエストがある場合、Latchkey は重複を開く代わりにそれへリンクします。
- 切り替えるものが何も残っていない場合、モーダルは **Nothing to migrate** の状態を表示します。
- 移行 PR を開くには管理者またはオーナーのロールが必要です。チームがマージするまで、あなたのリポジトリでは何も変わりません。

> ****
> このページのフリートコストの数字は常に現在の課金期間を反映するため、分析ページで使用する日付フィルターとは独立して、課金モーダルが請求する内容と一致します。

### Runners ページには何がありますか?

フリートのコストと削減額、ランナー構成、自己修復のアクティビティフィードが 1 か所にまとまっています。各構成は有効・無効の切り替えと最大同時実行数の設定ができ、カスタムランナーではイメージのビルド状況も表示されます。

### リポジトリを Latchkey ランナーへ一括移行するには?

サイドバーまたは Runner Types カードにある Migrate Runners を使います (owner と admin が利用可能)。1 回の実行で監視対象の最大 20 リポジトリに対し、リポジトリごとに 1 件のプルリクエストを作成し、変更は `runs-on` 行と、追加する場合の Latchkey キャッシュステップのみです。

### 自己修復のオン・オフはどこで切り替えますか?

構成単位ではなく、Settings でワークスペース全体に対して切り替えます。Runners ページは構成ごとの有効化と同時実行数を制御します。自己修復はワークスペース単位の単一スイッチで、ランナー種別ごとに挙動がずれないようにしています。

---

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