コンテンツへスキップ
Latchkey
EnglishPortuguês日本語
無料で始める
ドキュメントメニュー

はじめに

ダッシュボードと分析

マネージドランナー

キャッシュ

チームと通知

請求とプラン

ヘルプ

コスト分析

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

Cost Analysis ページ
Cost Analysis: 理論支出 vs 請求対象支出、上位リポジトリ、無料枠の追跡。

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

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

理解すべき2つの数字#

理論コスト

  • 標準の分単価であなたの使用量にかかるであろう額
  • GitHubホスト型とLatchkeyのランナーに分けられます
  • 無料分に歪められない: 傾向を見るべき数字です

請求対象コスト

  • 実際に課金される額
  • 無料枠とプランの含有分が適用された後
  • 請求書と一致する数字です

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

Cost Overview セクション#

  • Theoretical Cost。週ごとの傾向バッジと、その下にラベル付けされたGitHub vs Latchkeyの内訳を伴います。傾向バッジは直近7日の請求対象コストを前の7日と比較し、2週間分のデータが揃うまではダッシュを表示します。
  • Highest Spend (Theoretical): 選択した期間のモデル化コストによる上位3リポジトリ。
  • Cost Per Build と Build Efficiency Ratio で、支出を成果に対して正規化します。ビルドあたりコストは成功したビルドあたりの平均理論コスト。効率比は理論コストに対するビルド成功率で、高いほど1ドルあたりの成功ビルドが多いことを意味します。
  • GitHubとLatchkeyのKPIスタック: 期間の予測請求対象コストと、それぞれの側で使用済み・残りの無料枠分。
  • 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ランナーでジョブを実行することでチームが節約したドル額です。節約がプラスのときは必ず表示されます。

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

共有フィルターバーは、他のどこでもそうであるようにここでも機能します(ランナータイプ、リポジトリとワークフローのマルチセレクト、リセット)。ただし1つ違いがあります: 日付範囲ピッカーは請求向けのプリセットを使います: MTD、7D、30D、3M、6M、12M。すべてのチャートはフィルターバーを保持する全画面モードでも開き、表示設定の歯車には、ドル表記をセント精度と丸めた整数ドルとで切り替える "Show decimals" トグルがあります。

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

知りたいこと見る場所
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 の構成ごとの表

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

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

傾向を確立する

Theoretical Cost とその週ごとのバッジから始めます。傾向が横ばいなら、安定した請求を最適化していることになります。上昇しているなら、変化を追っていることになり、残りの一巡はいつどこでかを見つけることが目的です。

集中を見つける

Highest Spend (Theoretical) と Repository Costs を開きます。CI支出は通常集中しています: 少数のリポジトリが請求の大半を担う傾向があるので、このチャートの上位に費やす労力は他のどこよりもはるかに大きく報われます。

量と価格を切り分ける

Cost Per Build を確認します。総コストが上がる一方で横ばいなら、チームはより多く出荷しており、正直な解決策は最適化ではなく予算です。上がっているなら、個々のビルドが高くなっており、見つけるべき真の無駄があります。

パイプラインを分離する

リポジトリとワークフローのフィルターを使って1つの候補にズームインし、選択した範囲について Cost Over Time を読みます。これにより通常、急増が始まった日と、その原因となったワークフローが特定できます。

対処する

問題のワークフローを Optimization Insights へ持ち込みます。そこでAIが具体的な変更(キャッシュ、適正なサイズ調整、冗長な作業)を提案し、プルリクエストとして適用できます。問題が無駄ではなく無料枠の枯渇なら、ランナー使用状況と無料分 と 請求の管理 を参照してください。

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

メトリクス何を伝えるか
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 TrackingGitHubプランとLatchkeyプランについての "X / Y minutes used" ゲージを並べて表示
Cost Over Time日次の請求対象コストと理論コスト。請求対象の線が理論の線を追い始める点が、無料分が尽きた点
Cost by Runner OSLinux、Windows、macOSにわたる支出の分割。両方が存在する場合は Linux (GitHub) と Linux (Latchkey) のスライス
Estimated savings vs GitHub-hosted比較可能なGitHubホスト型ランナーの代わりにLatchkeyランナーでジョブを実行して節約したドル額。プラスのときに表示
Free tier applied: X / Y minプランの含有分に対して適用されたLatchkeyの無料分と、そのドル価値。ランナーコスト表のフッターに表示

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