Steamworks 多言語メタデータ管理：手動メンテナンスから構造化ワークフローへ

2026/05/09

AI関与

このページの執筆、編集、またはレビューには AI が関与しています。

重要な内容は慎重に判断し、必要に応じて一次情報で重要な決定を確認してください。

Steamworks 多言語メタデータ管理：手動メンテナンスから構造化ワークフローへ

Steam プラットフォームでは、10言語のストア紹介コンテンツの提供が求められています。従来の手動メンテナンス方法は非効率でエラーが発生しやすいものです。この記事では、HagiCode を通じて構造化された多言語メタデータ管理システムを構築し、コンテンツ制作からエクスポート・公開までの一体化したプロセスを実現する方法を紹介します。

背景

Steam プラットフォームでは、ゲームやアプリケーションに対して、about（詳細説明）や short_description（短い説明）などのフィールドを含む多言語のストア紹介コンテンツの提供が求められています。世界中でリリースされる製品の場合、通常10言語のローカライズコンテンツをサポートする必要があります。

これは単純なコンテンツ管理作業のように聞こえますが、実際にやってみると、想像以上に多くの問題があることがわかります。

まず、メンテナンスの作業量が膨大です。10言語に2つのフィールドを掛けると、管理すべきコンテンツブロックは20個になります。Steamworks のWebサイトバックエンドで手動で言語を切り替えて編集するのは、効率が良くありません。コンテンツを更新するたびにこのプロセスを繰り返す必要があり、言うまでもなく涙が出るほど大変です。

次に、コンテンツが分散して管理が困難です。多言語コンテンツは通常、異なるツールやドキュメントに分散しており、統一されたローカル保存形式がありません。バージョン管理が困難になり、チームでのコラボレーションでもエラーが発生しやすくなります。結局のところ、分散したものは散らばった記憶のようなもので、探そうとしても見つからないのです。

さらに、DLCコンテンツとメインアプリケーションのコンテンツ管理が分断されています。もしゲームに複数のDLCがある場合、各DLCは個別に多言語コンテンツをメンテナンスする必要があり、管理の複雑さは指数関数的に増加します。これは生活と同じで、ことが積み重なるほど多くなり、どこから手をつければよいかわからなくなります。

最後に、エクスポート形式が直感的ではありません。Steamworksが要求するJSON形式は人間の読書習慣とは合致しておらず、手動編集ではエラーが発生しやすくなります。結局のところ、あのぎっしりとしたJSONを見たいと思う人はいないのでしょう。

これらの問題はすべて、HagiCodeプロジェクトの実際の開発で私たちが遭遇したものです。世界中の開発者向けのAIコーディングツールとして、私たちはSteamプラットフォーム向けに完全な多言語コンテンツをメンテナンスする必要があります。従来のメンテナンス方法ではすでにニーズを満たせなくなっており、より効率的なソリューションが切実に必要でした。実のところ、他に方法はないので、自分でやるしかありませんでした。

HagiCodeについて

この記事で共有するソリューションは、HagiCode プロジェクトでの実践経験から来ています。HagiCodeは複数のAIプロバイダーとコードエディターをサポートするAIコーディングツールです。開発プロセスの中で、Steamプラットフォーム向けに多言語ストアコンテンツをメンテナンスする必要があり、それが私たちに構造化されたメタデータ管理システムを構築させるきっかけになりました。

この記事で共有する多言語メタデータ管理ソリューションは、まさにHagiCode開発で実際に問題に直面し、実際に最適化されたものです。もしこのソリューションに価値を感じてくれたなら、私たちのエンジニアリング力は悪くないということです——では、HagiCode自体も注目に値するでしょう。結局のところ、問題を解決できるのが良いツールですよね？

コアコンセプト

言語とフィールド

Steamworksがサポートする言語リストはかなり完全で、主要な市場をカバーしています：

zh-CN, zh-Hant, en-US, ja-JP, ko-KR,
de-DE, fr-FR, es-ES, pt-BR, ru-RU

其中最常用的是 en-US（英語）、zh-CN（簡体字中国語）、zh-Hant（繁体字中国語）、ja-JP（日本語）和 ko-KR（韓国語）。毕竟这些语言覆盖了主要市场，先把这几个搞定了，其他的也就不那么可怕了。

メンテナンスが必要な主なフィールドは2つです：

• about：詳細説明、リッチテキスト形式をサポート
• short_description：短い説明、300文字の長さ制限あり

スコープの概念

Steamアプリコンテンツは2つのスコープに分けることができます：

• Base App：メインアプリケーションのコンテンツ
• DLC：ダウンロードコンテンツ、各DLCは独立したコンテンツ管理を持つ

この区別は重要です。DLCは通常、独立したストア説明が必要であり、一つのゲームに複数のDLCがある可能性があり、統一管理が必要です。生活と同じで、主要なものもあれば追加のものもありますが、すべてちゃんと管理しないと混乱してしまいます。

データモデル設計

システムは多言語コンテンツ管理を支えるために明確なデータモデルを定義しています：

// サポートされる10言語コード
const STEAMWORKS_SUPPORTED_LOCALES = [
  'zh-CN', 'zh-Hant', 'en-US', 'ja-JP', 'ko-KR',
  'de-DE', 'fr-FR', 'es-ES', 'pt-BR', 'ru-RU'
];

// サポートされるフィールド
const STEAMWORKS_SUPPORTED_FIELDS = [
  'about',           // 詳細説明
  'short_description' // 短い説明
];

// コンテンツスコープ
type SteamworksScopeKind = 'base' | 'dlc';

このモデル設計にはいくつかの考慮点がありますが、どういうわけか、実のところ物事をもう少し簡単にしたかっただけです：

1. 標準的な言語コード形式（chinese ではなく zh-CN のように）を使用します。標準的なものは常に信頼性が高いからです
2. フィールドタイプを明確にリストアップし、将来の拡張に便利です。将来さらに多くのフィールドが必要になるかわかりません
3. スコープタイプを区別し、Base AppとDLCの統一管理をサポートします。物事を区別するのは常に良いことです

ファイル保存構造

コンテンツはプロジェクトディレクトリの .hagiclaw-data/steamworks-metadata/ に保存され、階層的なディレクトリ構造を採用しています：

.hagiclaw-data/
└── steamworks-metadata/
    └── default-app/
        ├── workspace.json              # ワークスペース設定リスト
        ├── base/                       # ベースアプリコンテンツ
        │   ├── en-US/
        │   │   ├── about.md
        │   │   └── short_description.md
        │   ├── zh-CN/
        │   │   ├── about.md
        │   │   └── short_description.md
        │   └── ...
        └── dlc/                        # DLCコンテンツ
            └── turbo-engine/
                ├── en-US/
                │   ├── about.md
                │   └── short_description.md
                └── ...

この構造設計にはいくつかの利点があります、または、少なくとも以前の方法よりもずっと良いです：

1. 人間が読みやすい：各コンテンツは独立したMarkdownファイルで、直接編集できます。結局のところ、人間の目はやはり明確なものを見るのが好きです
2. バージョン管理に親しい：テキストファイルは変更履歴の追跡や差異の比較に便利です。こうして何を変更したかが一目でわかります
3. 拡張性が高い：新しい言語やフィールドを追加するには新しいファイルを作成するだけで、ブロック遊びのように何でも追加できます
4. 構造が明確：ディレクトリ構造はコンテンツの組織化方法を直感的に反映しており、混乱を感じさせません

workspace.json はワークスペース設定を保存し、DLCリストと言語設定情報を含みます。結局のところ、リストが必要なものもありますし、時間が経つと、何を置いたか覚えている人はいないでしょう。

MarkdownからBBCodeへの変換

Steamは標準的なMarkdownではなく、BBCode形式のリッチテキストを使用します。これによりコンテンツ制作に追加の作業が発生します——BBCodeを直接書くか、後で手動変換する必要があります。

HagiCodeのソリューションは次のとおりです：開発者は慣れ親しんだMarkdownで制作し、システムが自動的にSteam BBCodeに変換します。結局のところ、人は常に慣れ親しんだものを好むものであり、あの奇妙な中括弧に無理に適応する必要はないのです。

変換ルール

// 見出し変換
# HagiCode        → [h1]HagiCode[/h1]
## Features        → [h2]Features[/h2]

// テキストスタイル
**bold text**     → [b]bold text[/b]
*italic text*     → [i]italic text[/i]
`code`            → [code]code[/code]

// リンクと画像
[text](url)       → [url=url]text[/url]
![alt](src)       → [img src="{STEAM_APP_IMAGE}/extras/..."][/img]

// リスト
- item 1
- item 2          → [*]item 1
                   [*]item 2
                   ([list] でラップ)

言語ラッピング

エクスポート時には言語タグでコンテンツをラップする必要があります：

wrapWithSteamLanguage(locale: SteamworksLocaleCode, bbcode: string): string {
  // [lang=english]...[/lang] 形式を返す
}

言語コードをSteamの形式にマッピングする必要があります：

• en-US → english
• zh-CN → schinese
• zh-Hant → tchinese
• ja-JP → japanese
• ko-KR → korean

このマッピング関係は実際にはそれほど複雑ではありませんが、覚えておく必要があります。結局のところ、各プラットフォームには独自のルールがあり、私たちは適応するしかありません。

エクスポート形式

エクスポートされるJSONはSteamworksの構造要件に従う必要があります：

{
  "itemid": "1158573",
  "languages": {
    "english": {
      "app[content][about]": "[h1]HagiCode[/h1]\n[b]About[/b]...",
      "app[content][short_description]": "AI coding tool..."
    },
    "schinese": {
      "app[content][about]": "[h1]HagiCode[/h1]\n[b]关于[/b]...",
      "app[content][short_description]": "AI 编码工具..."
    }
  }
}

重要なポイントは実際にはそれほど多くありませんが、これらの形式要件を覚えておく必要があります：

1. itemid はSteam AppIDに対応
2. languages の下ではSteamの言語コード（schinese など）を使用
3. フィールドパスは app[content][fieldName] 形式を使用
4. 値は変換後のBBCode文字列

これらのルールは少し面倒に見えますが、慣れればそれだけです。結局のところ、各プラットフォームには独自の癖があり、私たちは適応するしかありません。

APIサービス設計

システムは多言語コンテンツ管理ワークフローを支えるために完全なREST APIを提供しています：

ワークスペースの読み込み

GET /api/steamworks/metadata

ワークスペース設定、すべての言語とフィールドのコンテンツを返します。結局のところ、すべてのものを取り出して見る場所が必要です。

コンテンツの保存

POST /api/steamworks/metadata

{
  "scopeId": "base-app",
  "scopeKind": "base",
  "values": {
    "en-US": {
      "about": "Markdown content...",
      "short_description": "Short text..."
    },
    "zh-CN": {
      "about": "Markdown 内容...",
      "short_description": "简短文本..."
    }
  }
}

保存時にシステムはMarkdownコンテンツを対応する .md ファイルに書き込みます。こうして失われることはありません。結局のところ、記憶は常に信頼できないものです。

プレビューのレンダリング

POST /api/steamworks/metadata/preview

{
  "locale": "zh-CN",
  "field": "about",
  "content": "# HagiCode\n\n这是关于..."
}

Markdownレンダリング結果とBBCode変換結果を返し、プレビューに便利です。プレビューは鏡を見るようなもので、出かける前に自分の姿を見る必要がありますよね。

JSONのエクスポート

POST /api/steamworks/metadata/export

{
  "scopeId": "base-app",
  "scopeKind": "base"
}

Steamworks形式に準拠したJSONを生成し、Steamworksバックエンドに直接インポートできます。このステップは基本的にすべてのものを梱包し、発送の準備をするものです。

DLC管理

POST /api/steamworks/metadata/dlc    // 作成
PUT /api/steamworks/metadata/dlc     // 更新
DELETE /api/steamworks/metadata/dlc  // 削除

DLC管理には、DLCのメタデータ設定の作成、更新、削除が含まれます。結局のところ、DLCもコンテンツであり、ちゃんと管理する必要があります。

使用プロセス

1. メタデータパネルにアクセス

HagicLawワークスペースでSteamworks Metadataパネルを開くと、システムが現在のワークスペースの設定とコンテンツを読み込みます。すべての準備が整ったら、開始できます。

2. 編集スコープを選択

左側のナビゲーションでBase Appまたは特定のDLCを選択します。各スコープは独自の多言語コンテンツを管理します。部屋の片付けと同じで、まずものを分類して、それから一つ一つ片付けます。

3. 多言語マトリックス編集

編集する必要のある言語を展開し、about と short_description のMarkdownコンテンツを直接編集します。システムは以下をサポートします：

• リアルタイムMarkdownレンダリングプレビュー
• Steam BBCode変換プレビュー
• 文字数と長さのチェック

これらのプレビュー機能は実際に便利です。少なくとも自分が書いたものがどのような見た目になるかを知ることができます。結局のところ、たくさん書いたものの、最後にフォーマットが全部間違っていたと言う人はいないでしょう。

4. コンテンツの保存

保存ボタンをクリックすると、コンテンツは自動的に対応する .md ファイルに書き込まれます。ファイルはGitバージョン管理に含まれ、変更の追跡に便利です。保存というアクションは、記憶を書き留めるようなもので、時間が経っても忘れません。

5. 検証チェック

システムは自動的にチェックします：

• 必須フィールドが完全かどうか
• short_description が300文字を超えていないか
• Markdown構文が正しいかどうか

これらのチェックは些細なエラーを避けることができます。結局のところ、人は常に間違いを犯すものであり、機械に手伝ってもらうのは常に良いことです。

6. JSONのエクスポート

エクスポートするスコープ（Base Appまたは特定のDLC）を選択すると、システムがすべての言語を含むSteamworks JSONを生成します。JSONをコピーしてSteamworksバックエンドに貼り付けるだけでインポートが完了します。このステップが完了すると、プロセス全体も終了です。すべての準備が整い、公開を待つだけです。

注意事項

言語コードマッピング

システム内の en-US はSteamの english に対応し、zh-CN は schinese に対応します。このマッピング関係はエクスポート時に自動的に処理されますが、JSONを手動編集する際には注意が必要です。結局のところ、機械がやってくれることもありますが、自分で覚えておかなければならないこともあります。

BBCode制限

SteamはBBCodeのサブセットのみをサポートしており、複雑なMarkdownは完全に変換できない可能性があります。プレビューで変換結果を確認することをお勧めします。プレビューは鏡を見るようなもので、出かける前に自分の姿を見る必要がありますよね。

画像パス

画像は [img src="{STEAM_APP_IMAGE}/extras/..."] プレースホルダー形式に変換されます。実際の画像は別途Steamバックエンドにアップロードする必要があります。画像というものは、時には文字よりも説得力がありますが、アップロードは少し面倒です。

フィールド検証

short_description には厳格な300文字の長さ制限があります。システムはエクスポート前に検証しますが、編集時に長さを制御することをお勧めします。結局のところ、たくさん書いても意味がありません。プラットフォームは最初の300文字しか見ないので、簡潔にするしかありません。

バージョン管理

すべてのMarkdownファイルはGitバージョン管理に含めることができ、変更履歴の追跡やコラボレーション編集に便利です。定期的に変更をコミットすることをお勧めします。バージョン管理はタイムマシンのようなもので、過去のある瞬間に戻って、当時何を書いたかを見ることができます。

DLC管理

DLCの itemId はSteamworksバックエンドのDLC AppIDに対応している必要があります。DLCを作成する際はIDが正確であることを確認してください。IDのようなものは、一度間違えると修正が難しいので、やはり慎重にするのが良いでしょう。

まとめ

Steamworks多言語メタデータ管理の核心的な課題は、大量の多言語コンテンツを効率的にメンテナンスする方法です。構造化されたデータモデル、人間的なファイル保存、自動化された変換エクスポートプロセスを通じて、この面倒なプロセスを管理可能なコンテンツ制作ワークフローに変えることができます。

このソリューションは、HagiCodeプロジェクトの実践で有効であることが証明されました。私たちは手動メンテナンスでエラーが発生しやすい状態から、構造化され、検証可能で、コラボレーション可能なワークフローに転換しました。これは効率を向上させただけでなく、人的エラーも減少させました。結局のところ、ツールが良くなれば、物事も簡単になります。

もしあなたがSteamプラットフォーム向けにアプリケーションを開発しており、多言語コンテンツをメンテナンスする必要があるなら、このソリューションが何らかのインスピレーションを与えてくれることを願っています。多言語コンテンツ管理は必ずしも痛苦的なことではありません。適切なツールとプロセスがあれば、比較的楽にすることができます。または、少なくともそこまで絶望的ではありません…

参考資料

• Steamworks Documentation - Store Metadata
• Steam BBCode Guide
• HagiCodeプロジェクトアドレス：github.com/HagiCode-org/site
• HagiCode公式サイト：hagicode.com

もしこの記事が役に立ったなら：

• GitHubにStarを付けて：github.com/HagiCode-org/site
• 公式サイトにアクセスして詳細を確認：hagicode.com
• 正式版のデモ動画を視聴：www.bilibili.com/video/BV1z4oWB3EpY/
• ワンクリックインストールで体験：docs.hagicode.com/installation/docker-compose
• Desktopデスクトップ版のクイックインストール：hagicode.com/desktop/

AI翻訳

このページは簡体字中国語の原文をもとに、AI の支援で翻訳されています。

表現、技術的なニュアンス、最新の更新を確認したい場合は、簡体字中国語の原文も参照してください。

簡体字中国語の原文を見る

Tags:

• Steamworks
• 多言語
• メタデータ管理
• BBCode
• 国際化

AI コストパフォーマンスの定量化評価

デスクトップアプリ P2P 配布加速の実践：コンシューマー側からパブリッシャー側までの全パス接続