DeepSeekでマルチクラウドの支出を分析し予測する方法

要点： 各クラウドから請求明細を書き出し、共通の形——日付、アカウント、サービス、リソース、タグ、数量、金額、通貨——に正規化したうえで、合計の要約ではなく2期間の差異の説明をDeepSeekに求めます。中国語のAlibaba Cloud明細をそのまま読めることが、たいてい詰まっていた工程を解消します。タグのないリソースは直せません。そしてタグのないリソースこそ、この種の分析が失敗する主因です。

経理からは四半期ごとに同じ問いが届きます。クラウド費用が30%増えた。なぜか。

単一クラウドの会社なら、事業者自身のツールで半日あれば答えられます。しかし本稿が扱う構成——中国本土のワークロードはAlibaba Cloud、地域のその他システムはAWSかAzure、法人は二つ、通貨も二つ——では誰も答えられません。そして正直な理由は能力不足ではありません。三つの請求書が比較可能な単位で並ぶ場所が、どこにも存在しないからです。

その結果、答えは「クラウドは高い」になり、予測は前四半期に一定率を足した数字になり、実際の要因はさらに三か月見えないままになります。

これは言語モデルの良い用途であり、とりわけDeepSeekが向いています。理由は地味です。Alibaba Cloudの請求明細は製品名も項目名も中国語で届くことが多く、それをそのまま読めるモデルは、経理チームが諦める工程を丸ごと取り除くからです。

複数クラウドの請求書が構造的に読めない理由

陰謀ではありません。各請求書はそれ自体としては一貫しています。一貫しないのは互いの間です。

分類体系が噛み合いません。 ある事業者が一つの「サービス」と呼ぶものを、別の事業者は三つのメーターに分け、さらに別の事業者はインスタンス料金に含めます。何を含めるかを誰かが決めない限り、「コンピュート」は二つのクラウド間で比較可能な行項目ではありません。

粒度が違います。 一方は時間単位のリソース明細を出し、もう一方はメーター単位の日次集計を出します。比較するには粗いほうに合わせて集約し、その情報損失を受け入れるしかありません。

税と通貨の扱いが違います。 契約主体と地域によって、一方は現地税込みで表示され、もう一方は税抜きということがあります。金額は異なる通貨で計上され、取引日レート、月末レート、経理システムが既に計上したレートのどれで換算するかによって、調査中の差異より大きく比較結果が動きます。一つの方針を決め、文書に残してください。

法人が違います。 中国法人が中国のクラウドに支払い、香港またはシンガポール法人がグローバルなクラウドに支払えば、グループ間の付替えが発生します。つまり連結の管理会計上の数字は、どの単独請求書の数字とも一致しません。

個々には難しくありません。すべてが重なることが、この問いが答えられないままである理由です。

請求データを比較可能な一つの形にする

エクスポートと、その違い

主要3事業者はいずれも、PDFの請求書だけでなく詳細な請求データを書き出せます。AWSの詳細なコスト・使用状況レポートは行項目レベルのデータをストレージへ配信し、Azureのコスト管理も同様に使用明細を書き出し、Alibaba Cloudの費用センターは項目別の請求書を書き出せます。中国本土のアカウントでは列見出しや製品名が中国語であることが一般的です。実際のファイル構造、項目名、書き出しオプションは時期によって変わるので、2年前に覚えたスキーマではなく各事業者の現行ドキュメントを確認してください。

すべてを同じ列を持つ一枚のフラットな表に正規化します。期間、事業者、アカウントまたはサブスクリプション、法人、サービス、リソース識別子、タグ、使用量、単位、原通貨での金額、通貨、そして報告通貨での金額。要点はこれだけで、まったく華やかではありません。

DeepSeekが力を発揮するのはここです。Alibaba Cloudのエクスポート見本と目標スキーマを渡し、項目のマッピングを作らせます——たとえば「云服务器」を、EC2やAzure VMに使っているコンピュートのカテゴリへ対応づける、中国語と英語の製品分類の対照表を含めて。マッピングは使い捨ての変換ではなく、保存して再利用する表として出させてください。点検して直せるマッピングは資産です。四半期ごとに再実行するブラックボックス変換は負債です。

タグ付けの規律が、この分析が成立するかどうかを決める

ここまではすべて機械的な作業です。この部分は違い、分析になるか肩をすくめて終わるかを分けます。

コストをチーム、製品、環境、顧客に紐づけられるのは、リソースがそう示すタグを持っている場合だけです。タグのないリソースは「持ち主のいない費用」として現れ、能動的に管理されていない環境では、その割合は答えを丸ごと飲み込むほど大きいのが普通です。あるインスタンスが倉庫システムのものだとモデルは推論できません。できるのは、支出の38%が帰属不明だと報告することだけで、それ自体は知る価値がありながら、ひどく不満の残る結果です。

助けになることが二つあります。命名規則、作成日、リージョン、タグ付きリソースとの近接性からタグなしリソースをクラスタリングさせ、人間が確認するための候補の帰属——推測であると明示した短いリスト——を作らせること。そしてもう一つ、次の分析の最中ではなくその前に、最小限のタグ集合——所有者、環境、コストセンター、アプリケーション——を合意しておくことです。なおAWSでは、タグは請求データに現れる前にコスト配分タグとして有効化する必要があり、これが「うちは全部タグを付けている」という思い込みの、よくある静かな原因です。

実例——30%の前四半期比増を説明する

従業員180名の企業が、中国向けプラットフォームを本土法人でAlibaba Cloudに、地域システムをシンガポール法人でAWSに載せています。連結のクラウド支出は第2四半期に第1四半期比で30%増。CFOが求めているのはグラフではなく原因です。

両方のエクスポートを正規化し、要約ではなく差異の分解を求めると、観察の羅列ではなく、30%に足し上がる内訳が出てきます。

約三分の一は為替と暦であり、消費量ではありません。 二つの四半期間の為替変動と請求日が1日多いことが、無視できない割合を占めます。これは削減余地ではなく説明です。切り分けておくことで、為替の問題を解決するためにエンジニアリングチームが送り込まれる事態を防げます。

半分弱は失効したコミットメントです。 予約済み容量のコミットメントが四半期の途中で期限切れとなり、ワークロードは何も壊れず何のアラートも出ないまま従量課金の単価に戻っていました。更新日を見ている人がいなかったのです。単一項目としては最大で、そして最も直しやすい項目です。

残りは実際の成長と、避けられた二項目です。 ライフサイクルポリシーがないまま積み上がったストレージのスナップショットと、4月の負荷試験のためにスケールアップしたまま戻されなかったステージング環境です。どちらも総額に対して小さく、どの請求書にも独立した行として現れないため、見えないままでした。

最後の項目は少し立ち止まる価値があります。見つかったのはモデルが賢いからではなく、「第2四半期に第1四半期より費用が増えたリソースはどれで、なぜか」という問いを立てたからです。それは機械的な比較であり、ただ二つの事業者にまたがって実行した人が誰もいなかっただけです。

AI支援のコスト分析 vs 各社標準のコスト管理ツール vs FinOpsプラットフォーム

• 事業者・通貨・法人をまたぐ比較 — AI支援の分析が優位。各社のツールは自社の請求書しか見えないため、構造的にできない唯一の項目です。
• 中国語の請求明細を読み、分類体系を突き合わせる — AI支援の分析が優位。DeepSeekがこの用途に向く具体的な理由です。
• 数字そのものの正確性 — 各社標準ツールが優位。それらが正典であり、割引やクレジットを正しく反映します。AIが導いた数値は、取締役会資料に載る前にそこへ突き合わせるべきです。
• 継続的な監視・アラート・異常検知 — FinOpsプラットフォームが優位。継続監視はプロンプトの問題ではなく製品の問題であり、四半期に一度の手作業を検知手段にすべきではありません。
• コミットメントや予約の最適化 — 標準ツールとFinOpsプラットフォームが優位。どちらも事業者自身の価格で、事業者固有の選択肢を実使用量に対してモデル化します。
• 非技術の経理チームへ差異を説明する — AI支援の分析が余裕で優位。原因を名指しし、それぞれに数字を添えた文章を作るのは、まさにこの作業の形です。

中小企業にとって現実的な形は、四半期の説明とクラウド横断のビューにモデルを使い、数字の裁定者としては各社コンソールを残し、支出がライセンス費を正当化する規模になったらFinOpsツールを買う、という順序です。この規模の企業の多くでは、まだそこには至りません。

誠実に予測する

四半期4回分の複数クラウド請求書に引いたトレンドラインは、自信に満ちた、滑らかで、間違った数字を出します。クラウド費用は滑らかではなく、どこが滑らかでないかは分かっています。

コミットメントは階段関数です。 予約の失効や更新はベースラインを不連続に動かします。更新カレンダーを入力に持たない予測は、系列のなかで最大かつ本来予測可能な変動を当てずっぽうで扱っています。

移行や一時費用が基準期を歪めます。 新旧環境を6週間並行稼働させれば、その四半期は膨らみます。完了した移行を含む基準から予測すれば、その二重コストを将来のすべての期間に組み込むことになります。

成長はサービス間で一様ではありません。 ストレージとデータ転送は人数や売上ではなく累積データ量とともに増えることが多く、一人あたり比率では過小評価されます。

求めるべきは、前提を分けて明示し、各構成要素の根拠を名指しした予測です——ここまでは確約済みで契約上固定、ここは明示した要因に連動、ここは既知のプロジェクト、ここは説明できない変動。そのうえで幅を求めてください。区間のない単一の数字は、未来についての虚偽の言明です。そして経理チームは、技術チームが思うよりずっと上手に幅を扱えます。

正しく進めるために——請求データの機微性、アカウント権限、そしていつITを入れるか

書き出す前に、実務上の3点。

クラウドの請求書は自社に関するビジネスインテリジェンスです。 リソース数、リージョン展開、サービス構成、成長率、そして社内システムの名称が詳細エクスポートから推測でき、合わせるとアーキテクチャと方向性を記述してしまいます。営業秘密として扱ってください。顧客や製品が分かるリソース名は削り、データ取り扱い・保持条件を実際に読んだ階層を使い、そして中国本土のデータ所在義務がある組織なら、処理がどこで行われるかを既定値ではなく意識的な決定として扱ってください。制約が現実にあるなら、オープンウェイトのモデルを自社環境で動かすことも正当な選択肢です。

請求データへの読み取り専用アクセスで十分であり、それが正しい上限です。 コスト分析に書き込み権限は不要です。各事業者は請求向けのロールを用意しており、「そのほうが早いから」と広い権限を渡すことこそ、経理の作業をセキュリティ指摘に変える典型的な経路です。

請求書を説明することと、請求書を変えることは別です。 指摘に基づいて動くとは、インスタンスの適正化、ストレージのライフサイクル設定、正しいコミットメントの購入、そしてどのワークロードが移せてどれが移せないか——ICP登録やデータ所在の制約により「移せばいい」が成り立たないものを含めて——を見極めることです。それがマネージドITクラウドサービスの仕事であり、Alibaba Cloud・AWS・Azureをまたぐマルチクラウド設計と、中国本土での準拠したホスティングを含みます。当社のAI+サポートとマネージドITサポートはその両側に位置します。Brocentは2007年の北京での創業以来アジア全域で越境ITを手がけ、本社はシンガポール、2016年から香港にオフィスがあります——つまり、まさにこの形の環境について、この会話を何度も重ねてきました。同じ「正規化してから問い詰める」型は、Alibaba Cloudのセキュリティグループ規則の統制にも当てはまります。

よくある質問

クラウドの請求書に機微な事業情報は含まれますか？

含まれます。多くの人が思うより多く含まれます。詳細エクスポートからは、いくつのリソースをどのリージョンでどの速度で増やしているかが分かり、リソース名やタグを通じて社内システムや顧客の呼称まで分かることがよくあります。営業秘密として扱い、識別につながるリソース名は可能な限り削り、処理環境は意識的に選んでください。

Alibaba CloudとAWSの行項目を公平に比べるには？

各事業者の製品分類と、自社の共通カテゴリ集合との明示的な対応表を作り、再利用可能な文書として保管します。粒度は粗いほうに合わせて集約します。通貨換算の方針を一つに固定し、明記します。この三つを文書化せずに行った比較は再現できず、つまり四半期ごとに議論をやり直すことになります。

遊休や過剰なリソースは見つけられますか？

請求データだけでも有力な候補は見つかります——継続課金されているのに本番らしい使用パターンでないリソース、対応する計算資源のないままストレージだけが増えている状況、テスト用と名づけられて24時間動いている環境などです。本当に遊休かの確認にはコストではなく使用率メトリクスが必要なので、出力は削除リストではなく確認すべき短いリストとして扱ってください。

通貨とグループ間付替えはどう扱いますか？

まず換算方針——取引日、期中平均、期末——を決め、一貫して適用してください。この選択の影響は、調査対象の差異より大きいことがあります。付替えについては、各事業者に実際に支払った請求書の水準で分析し、付替えは別の会計処理として扱います。両者を混ぜることが、コスト分析が管理会計と合わなくなる原因です。

読み取り専用の請求アクセスは必要ですか、月次エクスポートで十分ですか？

始めるにはエクスポートで十分で、摩擦も小さい経路です。四半期ではなく月次で回したくなったとき、あるいは誰かにファイルを作ってもらうのを待たずに確認したくなったとき、常設の読み取り専用アクセスが価値を持ちます。いずれにせよ、読み取り専用が正しい上限です。

この用途でDeepSeekは本当に有利ですか、それともどのモデルでも同じですか？

計算と推論だけなら、能力のあるモデルならどれでもできます。具体的な優位性は、中国本土の請求エクスポートに含まれる中国語の製品名・項目見出し・請求用語を、劣化する翻訳工程を挟まずに扱える点です。中国＋グローバルの構成では、まさにそこでこの種のプロジェクトが止まります。請求書がすべて英語なら、ツール選びより正規化の規律のほうがはるかに重要です。

最初の一歩

クラウドを一つだけ選び、前四半期とその前の四半期について、その事業者単独で差異分解を作ってください。半日で終わる規模でありながら、支出のうちどれだけがタグなしかがすぐに分かります。それが、マルチクラウド版に取り組む価値がいまあるのか、それともタグ付けこそが最初のプロジェクトなのかを決めます。答えが分析ではなくアーキテクチャの問題だと分かったなら、それは別の会話であり、私たちが喜んでお受けする種類のものです。お問い合わせください。