1. OpenCostを入れたのに、出てきた数字が現実と合わない
K3sで組んだオンプレクラスタのコストを可視化しようと、CNCFサンドボックスプロジェクトの OpenCost を導入した。ダッシュボードには確かに数字が出てきたので、ひとまず安心した。ところが請求書や電気代と突き合わせてみると、まったく噛み合わない。ノード1台あたりの単価が、明らかに自社の実コストより高くも安くもない、どこかの「相場」で計算されているように見えた。
これは珍しいことではない。2024年に報じられたCNCFとFinOps Foundationによる調査では、Kubernetes導入後に「コスト超過の主因」として可視性のギャップ（visibility gaps）を挙げた組織が40%にのぼり、実際にコスト削減まで運用できているFinOps成熟組織はわずか20%にとどまるという。オーバープロビジョニング(70%)と並んで、「見えていないこと」自体がコストを膨らませる要因になっている。OpenCostのようなツールを導入しても、設定を詰め切れていなければこの「見えていない」側に含まれてしまう。コスト可視化の設定そのものに工数がかかる状況は、マネージドなK8s基盤を選ぶかどうかの判断にも関わってくる。
2. 原因は「デフォルト価格がGCP基準」だったこと
OpenCost 公式ドキュメントによると、オンプレミス/ベアメタル環境向けのデフォルト価格は「GCP us-central1 リージョンの料金」を基準に設定されている。具体的には CPU が1コア時間あたり約0.0316ドル、RAM が1GB時間あたり約0.0042ドルというのがデフォルト値だ。クラウド上で動いているなら、この仕組みは便利に働く。OpenCost のリポジトリでも説明されている通り、AWS・Azure・GCPそれぞれの請求APIと連携し、動的にオンデマンド価格を反映する設計になっているからだ。
問題は、オンプレ/ベアメタル環境ではこの請求APIが存在しないことだ。OpenCostはハードウェアの減価償却費や電気代、ラック費用といった「自社固有のコスト構造」を自動で推測する手段を持たない。連携先のクラウドAPIがなければ、黙ってデフォルト値、つまりGCPの料金で計算を続ける。ダッシュボードはエラーも警告も出さず、ただ「それらしい数字」を表示し続けるため、気づかないまま運用してしまいやすい。KuboのようにK3sをマネージドで提供する基盤では、そもそも利用者側がこの価格設定の前提を意識する必要がない。
3. K3sだから余計に気づきにくい
K3s は公式ドキュメントで「軽量・単一バイナリ・100MB未満」の完全準拠Kubernetesディストリビューションと説明されている通り、エッジ・ホームラボ・IoT・オンプレ用途で選ばれることが多い。つまりK3sを選ぶ時点で「クラウドの請求APIが使えない環境」である確率がもともと高い。
一方でOpenCost自体は、CNCF のブログが紹介している通り、特定のディストリビューションに依存しない「コスト測定の共通標準」を目指して設計されている。K3sかEKSかを意識せず同じように動く汎用性は長所だが、裏を返せば「K3sだから自動で正しい値にしてくれる」特別扱いは一切ない。マネージドK8s（EKS/AKS/GKE)ならクラウドAPI連携がほぼ自動で効くため気づきにくい問題が表面化しないが、K3sオンプレでは設定を怠ると最初から誤差を抱えたまま運用が始まってしまう。
Kuboのように、K3sベースでありながら料金体系があらかじめ固定されているKuboのようなマネージドサービスであれば、この「価格設定を自分で追い込む手間」自体が発生しない。コストの予測性は、ツールの設定精度に依存しない形で担保される。
4. 正しいコストを出すには、カスタム価格を明示する
OpenCostはHelm Chart のカスタム価格設定で、customPricing セクションに自社の実単価を明示できる。
opencost:
customPricing:
enabled: true
costModel:
CPU: 1.25
RAM: 0.50
storage: 0.25
ここで指定しなかった項目は、先述のGCPデフォルト値にフォールバックする点に注意が必要だ。サーバーの減価償却費、電気代、ラック・データセンター費用を按分して単価を出し、CPU・RAM・ストレージそれぞれに反映させて初めて、ダッシュボードの数字が意味を持つようになる。
OpenCostはAdobe・AWS・Google・SUSEなど複数のクラウド/インフラベンダーが共同で立ち上げた、特定ベンダーに依存しないコスト測定の標準を目指すプロジェクトだ。裏を返せば「ベンダー非依存であること」と「自社の実コストを自動で知っていること」は別問題であり、後者は利用者側が明示的に設定して初めて成立する。この設定作業をゼロにしたいなら、Kubo Cloudのように月額固定でコストが最初から見えているマネージドK3sを選ぶという手もある（4vCPU/8GB/40GB×3ノード構成でEKSの約58%のコスト感）。
まとめ
コスト可視化ツールは、導入しただけでは「コストが分かった」ことにならない。そもそもKubernetes公式ドキュメントが定義するrequests/limitsの設計が曖昧なままでは、OpenCostがいくら正確な単価を持っていても配分の土台がぶれる。特にK3sのようなオンプレ・エッジ寄りの環境では、クラウドAPIに頼れない前提を踏まえてカスタム価格を自分で設定するところまでがセットだ。この手間を省きたいなら、最初から運用コストが固定・予測可能な基盤を選ぶという選択肢もある。KuboはK3sベースのマネージドKubernetesとして、EKS/AKS/GKEよりも低いコストをあらかじめ提示しており、価格設定ツールの調整に時間をかける前に、まず料金プランを比較してみる価値はあるはずだ。コスト可視化に悩んでいるなら、一度お問い合わせから相談してみてほしい。