Skip to content

Find — 改善候補を見つける

コストが見えるだけでは、「で、どこを見直せばいいのか」には答えられません。Ncost は公式ツールの推奨に加えて、プロバイダ横断の独立ルールで具体的な改善候補を提示します。

すべての改善候補には、判定の根拠・危険条件・実行前の確認手順が付きます。「消してよさそうなリスト」ではなく、安全に判断するための材料を渡すのが Find の役割です。APIでは改善候補をFindingと呼びます(用語)。

改善候補 計画中

idle な Cloud SQL・未アタッチのディスク・停止インスタンスに残ったディスク・未割当の静的 IP などを、読み取り専用の観測だけで検出し、推定削減額と対処手順を表示します。

  • 各候補には判定根拠・重要度・経過日数が表示されます。一定期間の継続観測を経てから候補になるため、「たまたま今日静かだった」リソースが突然リストに現れることはありません
  • 対処手順には削除前の確認手順が含まれます。削除などの実行機能はありません — Ncost は表示までで、実行は常にあなたの手で行います
  • 対応不要・誤検知と判断したものは dismiss できます。理由は任意で残せます
  • Virtual Tag の絞り込みに対応しており、チーム単位で改善候補を見られます
  • 観測権限が未付与のプロジェクトは「権限不足」と理由付きで表示します —「改善候補なし」と区別することで、権限の付け忘れを見落とさないためです。最初に全プロジェクトへ権限を付ける必要はありません。付けた分だけ検知が広がります(はじめる)

何も見つからなかった場合も、それは結果です。ただし、検証できた範囲での「該当なし」と、権限やデータがなく判定できなかった状態は区別します。

現在の検知対象は GCP のみです。

判定規範 — ルールが守る約束 計画中

「本当に消して大丈夫か」を判断するのはあなたです。だからこそ、Ncost のルールは「多く検知する」より「間違った確信を与えない」ことを優先して実装・検査されます。

候補を捏造しません

  • 判定に必要なデータが取得できないときは「観測できない」と表示します。「候補なし」とは区別され、取得不能が 0 や「問題なし」に化けることはありません
  • 判定は3値です: 該当 / 非該当 / 判定保留。APIではmatched / not matched / unverifiedと表します。判定保留の観測が、既存の改善候補を勝手に解決することもありません
  • 削減額が推定できない場合も候補は表示し、金額 0 +「推定不能」の理由を明示します。それらしいプレースホルダの金額は使いません

判定は厳密に行います

  • sizing 判定はピーク値ではなく**パーセンタイル(既定 p99)**を使います — 瞬間値だけで「使っていない」と断定しません
  • 削除提案には経過時間ゲート(既定 15 日)が必須です。状態遷移の時刻が観測できない場合、ゲートは通過しません
  • idle 判定には観測窓全体の持続証明が必要です — 窓の一部だけを見た「たまたま静か」を idle と呼びません
  • 閾値・観測窓・ゲートの定数には出典(公式ドキュメント・参照 OSS・自己決定)が付きます

「見えなかったこと」も表示します

各候補は、観測できた事実と観測できなかった事実を同格で表示します。不足している事実には「なぜ見えなかったか」(権限不足・API無効など)と「どの権限を付与すれば見えるようになるか」が付きます。

Safety Tier — 「消してよい確度」を分けて示します

検知の確度とは別に、対処の安全度を high / medium / low で表示します(本番タグ・本番らしいプロジェクト ID・一時環境らしい名前などから推定):

Tier推奨アクション
highスナップショット取得 → 2 週間観察 → 削除
medium所有者への確認 → 1 か月観察 → 対処
low複数承認 + 30 日保留

誤検知の証明も「決着」です

「これは誤検知だ」と根拠付きで証明することは、削減の実行と同格の決着として扱われます。理由付き dismiss は記録され、ルールの改善に使われます。誤検知率は隠しません。

一覧に必要なものだけを出す 計画中

改善候補は、観測の完全さと推定削減額を使って並べます。独自スコアや複数の削減シナリオを覚える必要はありません。各行で確認できるのは次の情報です。

  • 対象リソースと推奨アクション
  • 推定月額と算出条件
  • 判定に使った根拠
  • 取得範囲と不足している事実
  • 危険条件と実行前の確認項目
  • open / dismissed / change detected / verified の現在地

構想では、一覧をそのまま共有するためのMarkdownと、自由に加工するための公開 APIを用意します。これらは現在利用できません。

提案は、後日の変更と照合できる 構想

改善候補には、文章の提案に加えて、後日のリソース状態と照合できる条件を持たせます。削除・停止・縮小・世代変更など、ルールごとに何を観測すれば同じ方向の変更といえるかを定義します。

その後の経過は、利用者が「対応済み」と入力するのではなく、Ncost がリソースの変化から検知します。詳しくは Verify — 変更を見つけ、請求で確かめるを参照してください。

コード・IaC・runbookの文脈が必要な場合も、Ncostへアップロードする必要はありません。Use your own toolsで、手元のAIや既存ワークフローから改善候補を扱えます。