# コスト分析

> 理論コストと請求対象コストの違いを理解し、GitHubとLatchkeyの無料枠分を追跡し、最もコストのかかるリポジトリとワークフローを見つけます。

Source: https://latchkey.dev/ja/documentation/cost-analysis

## Summary

- **理論**コスト = 定価レートでのあなたの使用量(傾向のシグナル)。**請求対象** = 実際に課金される額。
- Highest Spend と Repository Costs はコストのかかるリポジトリを見つけます。無料枠ゲージはGitHubとLatchkeyの分を追跡します。
- 十分な使用履歴が蓄積されると、予測がGitHubの請求対象支出をサイクル終了まで見込みます。
- Latchkeyランナーのコストに関するKPIは、日付フィルターに関係なく常に現在の請求期間を反映します。

Cost Analysis ページは、GitHubホスト型とLatchkeyの両ランナーについて "CIのお金はどこへ行っているのか?" に答えます。

ページは3つのセクションで構成されています: **Cost Overview**(見出しのKPI)、**Cost Analysis**(掘り下げるチャート)、**Latchkey Runner Costs**(マネージドランナーが今回の請求期間にいくらかかっているか)。ただし、それらが役に立つ前に、ページ全体が拠り所とする区別を理解しておく必要があります。

## 理解すべき2つの数字

なぜ2つの数字なのか? 無料枠は使用量の最初の一部を吸収するため、請求対象コストは傾向のシグナルとしては不向きです: 期間の一部でほぼゼロに留まり、無料分が尽きた途端に急上昇することがあります。たとえ実際の使用量が滑らかに増えていてもです。理論コストは使用量に比例して動くので、"先月よりCIを多く使っているか?" と問うときに読むべきものです。請求対象コストは "いくら支払うのか?" と問うときに読むべきものです。

> **具体例(説明用の数字)**
> これらの数字は形を示すために作ったもので、どのプランから取ったものでもありません。ある月、標準レートでの使用量が理論コスト $60 になり、無料枠の含有分がそのうち最初の $45 をカバーするとします: 請求対象コストは $15 です。翌月、使用量が20%増えるので理論コストは $72 に上がります。無料枠は依然として $45 をカバーするので、請求対象コストは $27 に跳ね上がります: 使用量の20%の変化から80%の増加です。請求対象の線だけを読むと、コストが急増したと結論づけてしまいますが、理論の線は真実、つまり控えめな成長を教えてくれます。

## Cost Overview セクション

- **Theoretical Cost**。週ごとの傾向バッジと、その下にラベル付けされたGitHub vs Latchkeyの内訳を伴います。傾向バッジは直近7日の請求対象コストを前の7日と比較し、2週間分のデータが揃うまではダッシュを表示します。
- **Highest Spend (Theoretical)**: 選択した期間のモデル化コストによる上位3リポジトリ。
- **Cost Per Build** と **Build Efficiency Ratio** で、支出を成果に対して正規化します。ビルドあたりコストは成功したビルドあたりの平均理論コスト。効率比は理論コストに対するビルド成功率で、高いほど1ドルあたりの成功ビルドが多いことを意味します。
- **GitHubとLatchkeyのKPIスタック**: GitHubスタックはサイクル終了までの予測請求対象コストに加え、今サイクルの残り・使用済みの無料枠分を表示します。"Current billing period" と表示されるLatchkeyスタックは、今回の請求期間の推定コストに加え、今期間の残り・使用済みの無料枠分を表示します。
- **Free Tier Minutes Tracking**: GitHubの含有分とLatchkeyの含有分のセグメント化されたゲージを並べて表示し、上限はあなた自身のプランの割り当てを反映します。

**Cost Per Build** について一言: チームがより多く出荷するたびに総コストは上がりますが、これは通常は問題ではなく良い知らせです。ビルドあたりコストは量を絵から取り除きます。総コストが上がっているのにビルドあたりコストが横ばいなら、単に多くビルドしているだけです。ビルドあたりコスト自体が上がっているなら、各ビルドが高くなった証拠です: 実行時間の延長、より大きなランナー、新しいステップ、それが調査に値する傾向です。

**予測**にも注記が必要です。当月に十分な使用履歴が蓄積されると、GitHub KPIスタックは、月初来の支出パターンに基づいて請求サイクル終了までの請求対象支出を **Forecasted billable cost by end of cycle** として見込みます。それまでカードは "Not enough data yet - run more jobs for a forecast" と表示します。いずれにせよ、まだ対応する時間があるうちに月がどこへ向かっているかがわかります。

## Cost Analysis セクション

- **Cost Over Time**: 選択した日付範囲にわたる日次の請求対象コストと理論コストを2つの系列として表示。
- **Repository Costs**: リポジトリごとの理論コストと請求対象コスト。Top 5 / Bottom 5 のドロップダウン付き。リポジトリ名はGitHubへ直接リンクするので、コストの急増からその背後にあるワークフローファイルへワンクリックで行けます。
- **Cost by Runner OS**: Linux、Windows、macOSにわたる支出のドーナツ。両方が存在する場合は Linux (GitHub) と Linux (Latchkey) を分けます。

このセクションの読み方のヒントを2つ。**Cost Over Time** では、請求対象の線が理論の線を追い始める点が、無料枠分が尽きた点です。それ以前は無料分が差分を吸収していました。そして **Cost by Runner OS** では、GitHubがWindowsとmacOSの分に割増を課すことを思い出してください。WindowsやmacOSの大きな割合は、より安価なLinuxランナーへ移す価値のあるジョブのリストであることが多いです。

## Latchkey Runner Costs セクション

マネージドランナーでジョブを実行する場合、このセクションは構成ごとのコスト表とともに表示されます: **Config Name**(`latchkey-small` のようにワークフローファイルで使うランナーラベル付き)、**Custom or Preset** のタイプバッジ、**Jobs**、**Avg Duration**、選択期間の **Cost**。無料分が使われた場合、フッターに **"Free tier applied: X / Y min"** と節約されたドル額が表示されます。Latchkeyランナーのコストに関するKPIは、日付範囲フィルターに関係なく常に現在の請求期間を反映します。

表の上部に、**"Estimated savings vs GitHub-hosted: $X"** という注記が表示されます: 選択した期間に、比較可能なGitHubホスト型ランナーの代わりにLatchkeyランナーでジョブを実行することでチームが節約したドル額です。節約がプラスのときは必ず表示されます。

## CLI Jobs 行

チームが [Latchkey CLI](/documentation/latchkey-cli) または MCP の `run_job` ツールから単発ジョブを実行する場合、その支出は独立した **CLI Jobs** 行として、その期間の支出とジョブ数とともに表示されます。これらのジョブはどのリポジトリにもどのワークフローにも属さないため、この行はリポジトリの内訳では位置づけられないお金にあたります。それでも Theoretical Cost には含まれます。リポジトリまたはワークフローのフィルターが有効な間、あるいはランナータイプフィルターが GitHub のみに設定されている間はこの行は非表示になり、CLIジョブのない期間には完全に消えます。

## このページのフィルター

共有フィルターバーは、他のどこでもそうであるようにここでも機能します: ランナータイプ、リポジトリとワークフローのマルチセレクト、7D、30D、90D、1Y、YTDのプリセットとカスタム範囲を備えた同じ日付範囲ピッカー、そしてリセットです。すべてのチャートはフィルターバーを保持する全画面モードでも開き、表示設定の歯車には、ドル表記をセント精度と丸めた整数ドルとで切り替える "Show decimals" トグルがあります。日付フィルターの唯一の例外: Latchkeyランナーのコストに関するKPIは常に現在の請求期間を反映します。

## どのチャートがどの問いに答えるか

| 知りたいこと | 見る場所 |
| --- | --- |
| CI支出は増加傾向か減少傾向か? | **Theoretical Cost** とその週ごとの傾向バッジ |
| どのリポジトリが最もコストがかかるか? | **Highest Spend (Theoretical)**、次に Top/Bottom 切り替え付きの **Repository Costs** |
| 支出が増えたのは、より多くビルドしたからか、ビルドが高くなったからか? | **Cost Per Build** と **Build Efficiency Ratio** |
| 急増は正確にいつ起きたか? | **Cost Over Time**、その周辺に日付範囲を絞って |
| 請求書はどうなりそうか? | GitHubとLatchkeyの **KPIスタック**(期間の予測請求対象コスト) |
| 無料分を使い切るまでどれくらい近いか? | **Free Tier Minutes Tracking** のゲージ |
| 1つのOSが請求を押し上げているか? | **Cost by Runner OS** |
| 各ランナーサイズはいくらかかっているか? | **Latchkey Runner Costs** の構成ごとの表 |
| 単発のCLIジョブやエージェントのジョブはいくらかかったか? | **CLI Jobs** 行 |

## このページを使って実際にコストを削減する

支出を下げる必要があるときの推奨ルーティンです。ここにあるものは製品によって強制されるものではなく、単にチャートが互いの問いに答える順序です:

1. **傾向を確立する** **Theoretical Cost** とその週ごとのバッジから始めます。傾向が横ばいなら、安定した請求を最適化していることになります。上昇しているなら、変化を追っていることになり、残りの一巡はいつどこでかを見つけることが目的です。
2. **集中を見つける** **Highest Spend (Theoretical)** と **Repository Costs** を開きます。CI支出は通常集中しています: 少数のリポジトリが請求の大半を担う傾向があるので、このチャートの上位に費やす労力は他のどこよりもはるかに大きく報われます。
3. **量と価格を切り分ける** **Cost Per Build** を確認します。総コストが上がる一方で横ばいなら、チームはより多く出荷しており、正直な解決策は最適化ではなく予算です。上がっているなら、個々のビルドが高くなっており、見つけるべき真の無駄があります。
4. **パイプラインを分離する** リポジトリとワークフローのフィルターを使って1つの候補にズームインし、選択した範囲について **Cost Over Time** を読みます。これにより通常、急増が始まった日と、その原因となったワークフローが特定できます。
5. **対処する** [AI Insight](/documentation/optimization-insights) を確認してください: 毎晩の分析が定量化されたコストの検出結果を表面化します。各検出結果にはLatchkeyが代わりに実行できる1つのアクション(大きすぎるランナーのダウンサイズ、キャッシュの追加)が付き、あなたが承認するプルリクエストとして適用されます。問題が無駄ではなく無料枠の枯渇なら、[ランナー使用状況と無料分](/documentation/runner-usage-and-free-minutes) と [請求の管理](/documentation/managing-billing) を参照してください。

> ****
> コストの急増が現れたら、ワークフローフィルターを使って1つのパイプラインを分離しましょう。Cost Over Time チャートと組み合わせれば、通常はその日と原因のワークフローが特定できます。

## メトリクスリファレンス

| メトリクス | 何を伝えるか |
| --- | --- |
| Theoretical Cost | 選択範囲内の全CI使用の合算コスト。GitHubホスト型とLatchkeyを合わせ、無料分の前の価格で算出 |
| Week over Week | 請求対象コストの変化率、直近7日 vs その前の7日。2週間分のデータが揃うまではダッシュ |
| Cost Per Build (Theoretical) | 成功したビルドあたりの平均理論コスト、無料枠の前 |
| Build Efficiency Ratio | 理論コストに対するビルド成功率。高いほど1ドルあたりの成功ビルドが多い |
| Forecasted billable cost by end of cycle | 月末までのGitHub請求対象支出の見込み。履歴が蓄積されるまでは "Not enough data yet" |
| Free Tier Minutes Tracking | GitHubプランとLatchkeyプランについての "X / Y minutes used" ゲージを並べて表示 |
| Cost Over Time | 日次の請求対象コストと理論コスト。請求対象の線が理論の線を追い始める点が、無料分が尽きた点 |
| Cost by Runner OS | Linux、Windows、macOSにわたる支出の分割。両方が存在する場合は Linux (GitHub) と Linux (Latchkey) のスライス |
| Estimated savings vs GitHub-hosted | 比較可能なGitHubホスト型ランナーの代わりにLatchkeyランナーでジョブを実行して節約したドル額。プラスのときに表示 |
| Free tier applied: X / Y min | プランの含有分に対して適用されたLatchkeyの無料分と、そのドル価値。ランナーコスト表のフッターに表示 |
| CLI Jobs | Latchkey CLI または run_job MCP ツールから開始されたジョブの支出とジョブ数。どのリポジトリにも属さないため、リポジトリの内訳ではなく、ここと Theoretical Cost の中に表示 |

このページに現れる前に支出をモデル化するには - 新しいリポジトリ、より大きなランナー、より多くのジョブ - Learn の [GitHub Actions コスト計算ツール](/learn/ci-cost/github-actions-cost-calculator) を使うか、プロバイダー横断の価格の仕組みについては [CIコストガイド](/learn/ci-cost) を参照してください。

### 理論コストと請求コストの違いは何ですか?

理論コストは使用量を定価で計算したもので、無料枠や割引を無視するため、傾向を見るのに適した指標です。請求コストはそれらを適用した後に実際に請求される金額です。使用量が増えているかは理論コストで、支払額は請求コストで確認してください。

### なぜ Latchkey ランナーのコストは日付フィルターを無視するのですか?

Latchkey ランナーのコスト KPI は、フィルターの範囲に関わらず常に現在の請求期間を反映します。これは「今サイクルの支払額」という請求期間の問いに答えるもので、日付範囲の問いではないためです。GitHub のコストグラフはフィルターに従います。

### 支出予測はいつ表示されますか?

現在のサイクルに予測できるだけの使用履歴が蓄積された時点です。予測は請求期間末までの 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