IBM Cloud Logsとは？料金3ティアとTCO Optimizer・移行と監視設計【2026年9月時点】

IBM Cloud Logsは、IBM Cloudのログを収集・検索・アラートするオブザーバビリティサービスです。2024年6月24日に一般提供が始まり、旧来の IBM Log Analysis と IBM Cloud Activity Tracker が2025年3月30日にサポートを終了したことで、IBM Cloud上のログ基盤はこのサービスに一本化されました。この記事では、料金の3ティアとTCO Optimizerによるコスト設計、ログの取り込み経路、LuceneとDataPrimeの使い分け、アラートの構成までを公式ドキュメントの実値で整理します。単価やティアの仕様は改定されるため、契約前の最終確認はIBM Cloud Logs のService plans and pricingで行ってください。

まとめ：導入前に決めておく4点

• 移行期限は過ぎている：IBM Log Analysis と IBM Cloud Activity Tracker は2025年3月30日にサポート終了。旧2サービスに代わるIBMのログ検索・分析サービスとして、Cloud Logsが案内されています。
• 料金は取り込みGB課金で、単価はティアで約7倍差：Store and search が0.48ドル/GB、Priority insights の90日保持が3.25ドル/GB。全ログを既定のPriority insightsに流すと費用が跳ねます。
• Object Storageバケットを先に用意する：バケット未接続でもインスタンスは動きますが、TCO Optimizerが使えず、ティアを分けられません。
• インフラのメトリクス収集はCloud Monitoringで設計する：CPUやメモリなどのメトリクス監視は IBM Cloud Monitoring 側の担当です。ログから生成した指標なら、Cloud LogsのEvent2MetricsとMetricアラートで監視できます。

IBM Cloud Logsの守備範囲と、旧サービスからの移行

IBM Log AnalysisとActivity Trackerのサポート終了日

IBM Cloudのドキュメントは、2つの旧サービスの終了をこう書いています。「The IBM Log Analysis and IBM Cloud Activity Tracker hosted event search services reached end of support on 30 March 2025.」そして「Users of these services should use IBM Cloud Logs, which replaces these services.」と続きます。つまりアプリログ基盤（Log Analysis）と監査イベント基盤（Activity Tracker）が、Cloud Logsの1サービスに統合されました。

統合の実務上の効果は、インスタンス数の削減です。旧Activity Trackerはリージョンごとにインスタンスを立てる必要がありましたが、Cloud Logsのターゲットを使えば、複数リージョンの監査イベントを1インスタンスへ集約できます（「you can use the same IBM Cloud Logs instance for collecting auditing events in your account across multiple regions」）。ただし公式ドキュメントは、性能とネットワーク遅延の観点からリージョンごとにインスタンスを定義する選択肢も併記しています。集約を優先するか遅延を優先するかは、監査要件と拠点数で決めてください。監査イベントは通常のログと同じ検索・アラート・保持ポリシーの対象になるため、検索操作は共通化できますが、監査ログの転送経路、閲覧権限、保持要件は別途設計します。

IBM Cloud Monitoringとの役割分担

「IBM Cloud 監視」で検索してCloud Logsに辿り着いた場合、探しているものがログではなくメトリクスであることがあります。両者は別サービスです。

IBM Cloud Monitoringは公式に「a cloud-native, and container-intelligence management system」と説明され、「collect metrics from a number of platforms, orchestrators, and a wide range of applications such as Prometheus, JMX, StatsD, Kubernetes」とあるとおり、メトリクス側を担います。障害の予兆をメトリクスで拾い、原因の特定をログで行う分業になるため、本番運用では両方を有効化するのが基本形です。この分け方の考え方はオブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツールを解説で整理しています。

東京・大阪リージョンでの提供

Cloud LogsとCloud Logs Routingは、東京（jp-tok）と大阪（jp-osa）を含む13リージョンで提供されています。ほかはシドニー、チェンナイ、ムンバイ、フランクフルト、ロンドン、マドリード、トロント、モントリオール、ダラス、ワシントン、サンパウロです。国内にデータを留める要件がある場合は、東京・大阪のインスタンスに加え、接続するObject Storageバケットの配置とログ転送先も国内になるよう確認します。

料金3ティアとTCO Optimizerのコスト設計

消費ティア別の単価

プランはStandardの1種類だけで、課金はサービスが取り込んだギガバイト数で計測されます（「Data is metered by the service per gigabytes ingested.」）。単価は消費ティアで変わります。

インスタンス作成時の保持期間は7日・14日・30日・60日・90日から選び、既定は7日です。設計上の要点は、取り込んだデータが既定でPriority insightsに流れることです。ドキュメントは「By default, when you send data to an IBM Cloud Logs instance, data is routed to the Priority insights data pipeline at ingestion.」としています。何も設定しなければ、90日保持なら全ログが3.25ドル/GB。Store and searchの約6.8倍です。月1,000GBを取り込む場合、Cloud Logsの取り込み料金は月480ドルと3,250ドルになります。これとは別に、接続するIBM Cloud Object Storageの料金が発生します。

消費ティア別の検索・アラート機能の違い

単価を下げれば機能も落ちます。安いティアへ機械的に寄せると、必要なアラートが鳴らなくなります。

アラートを鳴らしたいログをStore and searchに落とすと、通知が来ません。逆に、四半期に一度の監査でしか見ない監査イベントをPriority insightsに置き続けるのは払い過ぎです。ログの種類ごとに「即時に人が見るか」「アラートの根拠になるか」「保管だけか」の3択で振り分けるのが、TCO Optimizerの正しい使い方です。

TCO Optimizerポリシーの評価順と最初の一致

TCO Optimizerのポリシーは、アプリケーション名・サブシステム名・重大度の3つのメタデータフィールドで絞り込み、優先度（High／Medium／Low／Block）でパイプラインを決めます。HighがPriority insights、MediumがAnalyze and alert、LowがStore and search、Blockは破棄です。

ここで事故が起きやすいのが評価順です。ドキュメントは「Policies are evaluated in order, top down by default. The first matching policy is applied, and no other policies are evaluated.」と明記しています。最初に一致した1件で確定し、以降は評価されません。広い条件のポリシー（アプリケーション名がすべて、など）を上に置くと、その下に並べた個別の例外が永久に効かなくなります。破棄するポリシーは最後に置くのがTCO Optimizerのドキュメントの推奨です。

絞り込みに使うアプリケーション名は、ログの出どころで決まります。監査イベントはibm-audit-event、プラットフォームログはibm-platform-logs、KubernetesとOpenShiftのクラスターはkubernetes.namespace_name、Linuxサーバーは${HOSTNAME}です。ポリシーを書く前にこの値を確認しておくと、条件が空振りしません。

データバケット未接続時のAnalyze and alert・Store and searchの制約

Cloud LogsはObject Storageのバケット無しでもプロビジョニングできます（「You can run Cloud Logs without a data bucket or a metrics bucket.」）。ただしその状態では、データはPriority insightsに流すか破棄するかの2択になります。

問題は、バケットを付けないままTCO Optimizerのポリシーを書いてしまったときです。ドキュメントは「If you do not have the data bucket attached to the instance and you configure policies that send data to the Analyze and alert or the Store and search data pipelines, the data is not available for search or alerting as it cannot be archived in the bucket.」と警告しています。設定画面ではポリシーが保存でき、コスト削減もできたように見えるのに、そのログは検索にもアラートにも出てこない。コスト最適化のつもりで監視の穴を空ける典型パターンなので、データバケットとメトリクスバケットを先に用意してからポリシーを書く順序を守ってください。

バケット側にも制約があります。ストレージクラスはSmart TierかStandardに限られ、長期保管で単価の安いVaultやCold Vaultは選べません。またCloud Logsが削除権限を必要とするため、接続したバケットにretention policyやObject Lockを掛けてWORM保管先にすることはできません。改ざん防止を要件に持つ監査ログは、Cloud Logsの接続バケットとは別に、要件を満たす保管先へ複製する設計が必要です。

ログを送り込む3つの経路

ロギングエージェント（Fluent Bitベース）

アプリケーションログの主経路はロギングエージェントです。実体はFluent Bit（「Fluent Bit open-source agent which is used to collect and process log data」）で、Red Hat OpenShift on IBM Cloud、IBM Cloud Kubernetes Service、オンプレミスや他社クラウドのKubernetes/OpenShiftクラスターに加え、RHEL 8/9、Ubuntu 20/22、Debian 11/12、Windows Server 2016/2019/2022といった非オーケストレーション環境にも対応します。入力形式はJSON、apache、apache2、apache_error、nginx、docker、cri、syslogです。

エージェント経由のログには16Kの長さ上限があります（「Logs processed by the logging agent cannot exceed 16 K in length.」）。スタックトレースや巨大なリクエストボディをそのまま1行で吐くアプリでは、この上限で切れます。送信前にログを構造化して必要なフィールドだけ出す設計が有効です。なお、OpenTelemetryのOTLPデータはエージェント同梱のFluent Bitが持つopentelemetry入力プラグインで受けられますが、このプラグインはIBMの直接サポート対象外と明記されています。OTLPを本番の主経路に据える場合は、その前提で構成を決めてください。考え方は構造化ログとは｜JSONでログを機械可読にする仕組みとslog/structlog実装・オブザーバビリティでの使いどころを実装者目線で解説にまとめています。

取り込みAPI（singlesエンドポイント）

エージェントを置けない環境や、バッチから直接送りたいときはREST APIを使います。以下はIBM Cloud CLIにログイン済みで、curlとjqが利用できる環境向けの例です。実行時はINSTANCE_IDを送信先インスタンスのGUIDに置き換えます。認証はIAMのベアラートークンで、送信側にSenderロール（権限はlogs.data.send）が必要です。

export IAM_TOKEN=$(ibmcloud iam oauth-tokens --output json | jq -r '.iam_token')

curl -v --location "https://<INSTANCE_ID>.ingress.jp-tok.logs.cloud.ibm.com/logs/v1/singles" \
--header "Content-Type: application/json" \
--header "Authorization: $IAM_TOKEN" \
--data '[{
      "applicationName": "payment-api",
      "subsystemName": "checkout",
      "severity": 5,
      "text": "gateway timeout after 30s"
    }]'

必須フィールドはapplicationName、subsystemName、textの3つです。severityは数値で、1がDebug、2がVerbose、3がInfo、4がWarn、5がError、6がCriticalを表します。省略すると1（Debug）が入るため、指定を忘れるとエラーログが最低重大度で記録され、重大度で絞るTCOポリシーもアラートも素通りします。1リクエストの本文サイズ上限は10MiB、タイムアウトは30秒です（Limits）。送信できるログ件数は、各ログとリクエスト全体のサイズによって変わります。あわせて、24時間より古いログと4時間より先の未来日時のログは受け付けません。バッチで過去分をまとめて送り込む設計は、この窓に収まるかを先に確認してください。

Logs Routing V1のテナント設定とV3のルート設定

IBM Cloudのサービス自身が出すプラットフォームログは、Cloud Logsのインスタンスを作っただけでは流れてきません。IBM Cloud Logs Routing側で、リージョンごとにテナントを作り、送信先のターゲットとしてCloud Logsインスタンスを指定します。V1では、東京と大阪の両方から収集する場合、各リージョンにテナントを作成します。V3では、グローバルなターゲットとルートで転送先を定義します（v3への移行手順）。V1からV3への移行は元に戻せないため、切り替え時期は既存のテナント構成を棚卸ししてから決めます。以下のコードはV1を使用するアカウント向けの例です。実行前に、Logs Routingから送信先Cloud Logsへのサービス間認可も設定してください。

curl -X POST "https://management.jp-tok.logs-router.cloud.ibm.com/v1/tenants" \
-H "Content-Type: application/json" \
-H "Authorization: $IAM_TOKEN" \
-H "IBM-API-Version: 2024-03-01" \
--data '{
  "name": "tenant-jp-tok",
  "targets": [
    {
      "log_sink_crn": "<CLOUD_LOGS_INSTANCE_CRN>",
      "name": "target-cloud-logs",
      "parameters": {
        "host": "<INGRESS_ENDPOINT>",
        "port": 443
      }
    }
  ]
}'

ターゲットのCloud Logsインスタンスは、同一アカウントでも別アカウントでも、同一リージョンでも別リージョンでも構いません。プラットフォームログを本番アカウントから分離した管理用アカウントへ送る構成が取れます。監査イベントの転送には、別途IBM Cloud Activity Tracker Event Routingのターゲットとルートを設定します。他社クラウドの同種サービスとの構成の違いは、Cloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違いを実装者目線で解説とAzure Log Analyticsとは？ワークスペース設計・KQL検索・テーブルプラン別の保存コストを実装者目線で解説が参考になります。

LuceneとDataPrimeの使い分け

検索欄はLuceneとDataPrimeをスイッチで切り替えます。障害対応の初動でキーワードを叩き込むならLucene、集計や加工が要るならDataPrimeという分担です。

Luceneはフィールド検索・範囲検索・正規表現検索に対応します。正規表現はスラッシュで囲みます。

msg:"failed transaction" AND level: "ERROR" NOT env:"staging"

status_code.numeric:[500 TO 599]

version.keyword:/.*v.[1-5].[0-9]{2}.*/

範囲検索は角括弧が境界値を含み、波括弧が含みません。status_code.numeric:[200 TO 300}なら200を含み300を含みません。正規表現は.keyword付きのフィールドに当てるのが公式の推奨です（キーワードはアナライザーを通らないため）。

DataPrimeはパイプ演算子で処理を連ねるクエリ言語です。フィルターしてから集計する、といった段階的な処理が書けます。

source logs
| filter $l.applicationname == 'ibm-platform-logs'
| groupby $m.severity calculate count()

メタデータは$m、ラベルは$l、ログ本体は$dで参照します。groupbyの結果キーパスは常に$d配下に置かれ、asで別名を付けられます。Priority insightsで期待したデータが出ない場合は、検索時間範囲とTCOの振り分け先を確認し、インデックス対象フィールドの上限やマッピング例外も調べます。

アラート7種類と通知先の構成

アラート設定画面に並ぶ種類は7つです。閾値だけで組むと、単発のスパイクで鳴り続けるか、逆に静かな異常を取り逃がします。

SLO監視に効くのはRatioです。エラー件数の絶対値は流量に比例して増えるため、ピーク時間に閾値を合わせると閑散時の異常を見逃します。エラー数を総リクエスト数で割った比率なら流量の違いを吸収できますが、低流量時は少数のエラーで比率が跳ねるため、評価期間とリクエスト件数も条件に入れます。New valueは、未知のエラーコードの出現をデプロイ時刻や変更内容と照合する起点に使えます。

Metricアラートは、ログからEvent2Metricsで生成した指標に対する閾値監視です。クエリはPromQLで書きます。「メトリクスの監視はCloud Monitoringの担当」と先に書きましたが、ログから導いた指標に限れば、Cloud Logs単体でも閾値監視とアラートまで到達できます。エラーログ件数と総リクエスト件数をそれぞれ指標化できれば、両者の比率をPromQLで計算してエラー率を監視できます。

これとは別に、AIアルゴリズムで24時間先の想定挙動を予測し、そこから外れた振る舞いを検知する異常検知アラートがあります。閾値を人が決めなくてよい代わりに、Store and searchのログでは使えません（前掲の機能表のとおり）。

通知先は、Cloud LogsからIBM Cloud Event Notificationsへのアウトバウンド統合を構成し、Event Notifications側でメールやSlackなどの宛先を設定します。Cloud Logs単体でSlackに直接投げる構成ではないため、インスタンス作成後の初期設定にEvent Notificationsの用意を含めておきます。多数のサービスからログを集めるときの経路設計はログ集約とは？収集・転送・保存・可視化の仕組みとエージェント選定・導入判断を実装目線で解説【2026年版】も合わせて確認してください。

よくある質問

IBM Cloud Logsは東京リージョンで使えますか？

使えます。東京（jp-tok）と大阪（jp-osa）の両方が対応リージョンに含まれ、いずれもマルチゾーン構成です。プラットフォームログを国内のインスタンスへ集める場合は、Logs Routingの送信先を国内に指定します。

IBM Log AnalysisやIBM Cloud Activity Trackerはまだ使えますか？

2025年3月30日にサポートを終了しています。公式ドキュメントはCloud Logsを置き換え先として案内しており、新規に組むなら選択肢はCloud Logsです。旧サービスからの移行ツールはアラート・ダッシュボード・ビューなどの設定を引き継ぎます。

料金を抑えるには何から手を付けますか？

振り分けの初手は、監査イベント（アプリケーション名ibm-audit-event）のうち日常的に見ないものをStore and searchへ、監視に使うプラットフォームログをAnalyze and alertへ落とすことです。単価0.48〜0.75ドル/GBの帯に寄せられます。ただし前提として、データバケットの接続をポリシー作成より先に済ませてください。

IBM Cloud MonitoringとCloud Logsは両方契約が必要ですか？

用途によります。ログの検索と監査だけならCloud Logsのみで足ります。CPU使用率やレイテンシーなどのメトリクスで閾値監視したいなら、収集方式に応じてIBM Cloud Monitoringなどを使用します。ただし、応答時間などをログに記録している場合は、Cloud LogsのEvent2Metricsで指標化し、Metricアラートで監視する構成も可能です。障害の検知をメトリクス、原因の特定をログで行う運用なら両方を有効化します。

IBM Cloudで障害が起きたとき、Cloud Logsだけで原因を追えますか？

自社アプリの不具合であれば、エージェントが送ったログとプラットフォームログで追えます。ただしIBM Cloud側のサービス障害かどうかの判断は、IBM Cloudのステータスページで公表される情報と突き合わせる必要があります。Cloud Logsに出るのはあくまで自アカウントのリソースが出したログとイベントで、基盤側の障害宣言はそこには現れません。

関連記事

• Cloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違いを実装者目線で解説
• Azure Log Analyticsとは？ワークスペース設計・KQL検索・テーブルプラン別の保存コストを実装者目線で解説
• ログ集約とは？収集・転送・保存・可視化の仕組みとエージェント選定・導入判断を実装目線で解説【2026年版】
• 構造化ログとは｜JSONでログを機械可読にする仕組みとslog/structlog実装・オブザーバビリティでの使いどころを実装者目線で解説
• オブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツールを解説