3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ゲームの権利表記からOSSを調べて実装してみた

Last updated at Posted at 2025-12-14

概要

  • 『龍が如く極』(SEGA)の権利表記画面に記載されているOSSライブラリを調査し、実際に動作するサンプルアプリを学習目的で作成しました。
    • タイトル画面から権利表記画面に直接飛べたので、ゲームを遊ぶ前に興味本位で見てみたところ思いのほか面白そうなものが並んでおり、それぞれのOSSについて調査したいと思い本記事の執筆に至りました。
  • サンプルアプリは全てCLIで動作するもので、簡易的な最低限の実装にとどめています。
    • サンプルアプリの作成には生成AI(Claude Sonnet 4.5)を使用しています。VSCodeでのAgentモードは一度知ると快適過ぎてもう戻れないですね。

免責事項

本記事は、筆者個人が『龍が如く極』のゲーム内に表示されている権利表記画面を見て、純粋な技術的興味から独自に調査・執筆したものです。

  • 株式会社セガとは一切関係ありません
  • 筆者は株式会社セガの社員ではなく、本ゲームの開発にも一切関与していません
  • 本記事の内容は、あくまで筆者個人の見解・推測であり、株式会社セガ及び開発チームの意向や公式見解を反映したものではありません
  • ゲーム内でのOSSライブラリの実際の使用方法については、公開情報のみに基づく推測であり、正確性を保証するものではありません
  • 本記事に記載された技術的見解や推測に誤りがある可能性があります

本記事は学習目的で作成されたものであり、商業目的での使用を意図したものではありません。

『龍が如く』は株式会社セガの登録商標です。
本記事で言及されているすべてのOSSライブラリは、それぞれのライセンスに従って使用されています。

権利表記画面で確認できたOSSライブラリ一覧

作成したサンプルアプリ

  • QRdemo: QRコードジェネレーターのサンプルアプリ。任意の文字列に対応するQRコードをPNG形式で出力、またはターミナルにASCIIアートで表示できる
  • Base64: Base64.h のサンプルアプリ。文字列のBase64エンコード・デコードを行う
    • 備考: Base64.h のみGithub Gistで公開されている単一ファイル。MITライセンスで公開リポジトリに含めてもよいという判断から、単一ファイルであることもあり、こちらのみフォルダ内にOSSを格納している
  • msgpack11Demo: JSONファイルを msgpack 形式に変換したり、msgpack形式のファイルの中身を読み書きできる
  • picojsonDemo: JSONファイルの読み込み・表示・整形を行う
    • read, write, format, validate, query, merge コマンドを実装
  • json11Demo: 同上(picojsonと同様の機能をjson11ライブラリで実装)

msgpackの補足

(以下、AIによる解説です)

MessagePack(msgpack)は、JSONよりもコンパクトで高速なバイナリ形式のシリアライゼーションフォーマットです。

msgpackの特徴

  • コンパクト: JSONよりもファイルサイズが小さい(通常30-50%程度削減)
  • 高速: パースと生成がJSONより高速
  • バイナリ形式: バイナリデータを効率的に扱える
  • 型保持: JSONと異なり、整数と浮動小数点数を区別して保存できる

ゲームでの活用例

ゲーム開発において、msgpackは以下のような用途で使用されることがあります:

  • セーブデータ: コンパクトで高速なため、頻繁に読み書きするセーブデータに適している
  • ネットワーク通信: データサイズが小さいため、通信量の削減に貢献
  • 設定ファイル: 人間が直接編集する必要がない設定データの保存

これらのOSSはゲーム中でどのように使用されていたか?

私は本ゲームの開発には一切関与していないため、以下の内容は全て筆者の推測です。
また、本ゲームは序盤しかプレイできていないため、推測の精度が低い可能性があることをご了承ください。

QRコード

ゲーム内でプレイ方法を見ようとすると、WebマニュアルへのリンクとともにQRコードが表示されました。現状、本ゲームでQRコードが確認されたのはこの箇所だけなので、おそらくQRコードジェネレーターはこのために使用していると思われます。

静的生成 vs 動的生成の謎

Webマニュアルのリンクは基本的に静的な値のはずなので、あらかじめ生成したQRコード画像を用意しておけば十分な気もします。考えられる可能性としては:

  1. 将来の拡張性: 将来的にユーザー固有のURLやセッション情報を含むQRコードを生成する機能を見越していた
  2. 多言語対応: 言語設定によって異なるマニュアルURLを動的に生成している
  3. ライセンス表記の徹底: ゲーム内にQRコードジェネレーターで生成したQRコード画像が含まれているため、ツール使用の事実を明記している

個人的には、3番目の可能性が高いのではないかと考えています。ライセンス表記を徹底するという開発姿勢は素晴らしいですね。

とAIが申していますが、個人的には2な気がします。
国内版Switch2しか持っていないので言語設定を切り替えた時の挙動は確かめられませんが……。

JSON/MessagePack系ライブラリの用途

セーブデータとしての使用

最近読んだ本『ゲームプログラミングC++』にてたまたま紹介されているのを読みましたが、どうやらゲームのセーブデータにJSON形式を使用するケースは多くあるらしいです。古くはドラクエの「ふっかつのじゅもん」でユーザーが手入力していた内容を、今ではソフトウェアが自動で処理してくれていると考えると、技術の進歩を実感できますね。 ( ドラクエやったことないけど )

テキスト形式 vs バイナリ形式

『ゲームプログラミングC++』でも言及されているように、JSONのようなテキストベースのファイルは読み書きの速度がバイナリ形式に比べて遅い傾向にあります。そのため、実際のゲームでは以下のような使い分けがされている可能性があります:

  • 開発中・デバッグ用: JSON(人間が読みやすく、編集しやすい)
  • 本番環境: MessagePack(バイナリ形式で高速・コンパクト)

本ゲームでpicojson、json11、msgpack11の3つのライブラリが使用されているのは、このような用途の使い分けがあるのかもしれません。

3つのJSONライブラリを使用する理由

picojsonとjson11の2つのJSONライブラリに加え、msgpack11も使用されているのは興味深い点です。考えられる理由:

  1. 用途による使い分け: 設定ファイル、デバッグ出力、ネットワーク通信など、用途ごとに最適なライブラリを選択
  2. レガシーコードの共存: 開発時期の異なる複数のコンポーネントで異なるライブラリが使用されている
  3. パフォーマンス要件: 重要度の低いデータはJSON、頻繁にアクセスするデータはMsgPackで保存

ゲーム開発の現場では、このような複数のシリアライゼーションライブラリの併用は珍しくないのかもしれません。

これもAIによる推測ですが、概ね妥当そうです。
特に「2.レガシーコードの共存」は、『龍が如く 極』がリメイク作であることを考慮すると説得力が増すかもしれません。

補足: 『龍が如く』(初代)の発売年など

  • 『龍が如く』 (2005・PS2)
  • 『龍が如く 極』 (2016-2025, PS3,4 や Switch2 など多数)
    • 筆者が遊んでいるのは 2025年11月13日に発売されたSwitch2版

Base64エンコーディング

Base64は、バイナリデータをテキスト形式で表現するための標準的なエンコーディング方式です。ゲームでの使用例としては:

  • セーブデータの保護: 簡易的な難読化(セキュリティ目的ではなく、誤編集防止)
  • ネットワーク通信: テキストベースのプロトコルでバイナリデータを送信
  • 設定ファイル: バイナリ設定をテキストファイルに埋め込む

本ゲームでの具体的な使用方法は不明ですが、上記のいずれかの用途で使用されていると推測されます。


この辺りの実装詳細は、ゲーム開発会社に所属しておらず、ゲーム開発者としても初心者である筆者には正確には分かりません。機会があれば、現場の方に最近のゲームの実際の実装について伺ってみたいですね。

各ライブラリの技術的特徴

(※このセクションはほぼ丸々AIに書いてもらってます。筆者も一通り目を通して問題なさそうなことは確認していますが、もし誤った内容が含まれていたらご指摘いただけると幸いです。)

picojsonの実装について

picojsonは、ヘッダーオンリー(header-only)のC++向けJSONライブラリです。リポジトリに含まれるのは主にテストファイルで、picojson.h 1つをインクルードするだけで使用できます。

picojson::value クラスの設計

picojsonの中核となる picojson::value クラスは、JSONのあらゆる型を表現できる汎用的な設計になっています:

class value {
public:
  typedef std::vector<value> array;
  typedef std::map<std::string, value> object;
  
  // JSONの各型を格納するためのunion
  union _storage {
    bool boolean_;
    double number_;
    int64_t int64_;        // オプション
    std::string *string_;
    array *array_;
    object *object_;
  };
  
  // 主要なメンバ関数
  template <typename T> bool is() const;        // 型チェック
  template <typename T> const T &get() const;   // 値の取得
  std::string serialize(bool prettify = false) const;  // JSON文字列化
  // ...その他のメンバ関数
};

使いやすいAPI設計

picojsonの特徴は、C++のテンプレートを活用した直感的なAPIです:

  • is<T>(): 値の型をチェック
  • get<T>(): 値を取得
  • serialize(): JSON文字列に変換
  • contains(): キーや要素の存在確認

この設計により、型安全でありながら簡潔なコードが書けます。
(実際、AIが実装してくれたサンプルアプリでも主に上記のAPIが使用されていました)

json11との比較

json11もpicojsonと同様にC++向けのJSONライブラリですが、いくつかの違いがあります:

共通点

  • C++11以降をターゲット
  • 軽量で使いやすいAPI
  • MITライセンス

主な違い

  • エラーハンドリング: json11は parse() 時にエラーメッセージを文字列で返す仕組みを持つ(picojsonは get_last_error() を使用)
  • 実装: json11は .cpp ファイルが必要(ヘッダーオンリーではない)
  • 開発元: json11はDropbox社が開発

この2つのライブラリが両方使用されているのは、それぞれの長所を活かした使い分けがされている可能性が高いです。

msgpack11の特徴

msgpack11は、MessagePack形式のC++実装です。json11と同じ開発者(ar90n氏)が、json11のAPIスタイルを踏襲して開発したライブラリです。

APIの一貫性

json11と同様のAPIデザインを採用しているため、JSONとMsgPackの切り替えが容易です:

// json11
auto json = Json::parse(json_string, err);

// msgpack11
auto msg = MsgPack::parse(msgpack_data, err);

この一貫性により、開発時はJSON(デバッグしやすい)、本番環境ではMsgPack(高速・コンパクト)という使い分けが容易になります。

生成AI時代のプログラミング学習について

今回のサンプルアプリ作成では、Claude Sonnet 4.5(VS Code Agent モード)を使用し、ほぼ全てのコードを生成AIに書いてもらいました。

「勉強にならない」のか?

最初は「生成AIが全部書いてくれるので勉強にならないのでは?」と思っていましたが、実際にやってみると従来とは異なる形で学びがありました。

新しい学習パターン

  1. 動くものをまず作る: 生成AIに実装を任せ、動作するサンプルを素早く作成
  2. 挙動を観察する: 実際に使ってみて、ライブラリの振る舞いを把握
  3. コードを読む: 生成されたコードを読み、実装の詳細を理解する
  4. ドキュメントを確認: 疑問点をドキュメントで確認し、理解を深める

実務との親和性

職業エンジニアとしては、コードを書くよりも読むことの方が多くなる傾向にあると思います。その意味で、「動くコードを読んで理解する」という学習法は、より実務に適応的なスキルかもしれないと思いながら作業をしていました。

GitHub Copilotを使った記事執筆の工夫

リポジトリと記事を紐付ける

今回の記事執筆では、以下のワークフローを採用しました:

  1. リポジトリ内に記事を配置: .md形式で記事の下書きをリポジトリ内に作成
  2. .gitignoreに追加: 記事ファイルをバージョン管理から除外
  3. GitHub Copilotで添削: リポジトリのコンテキストを持った状態でCopilotに添削を依頼

このアプローチの利点は、GitHub Copilotがリポジトリの内容(コード、README、実装の詳細など)を参照しながら、より正確で具体的な添削やサジェストをしてくれることです。

記事の内容とコードが乖離することを防ぎ、技術的な正確性を保ちながら執筆できるため、非常に効率的でした。

まとめ

  • 『龍が如く極』の権利表記画面から始まった今回の調査では、QRコード生成、Base64エンコーディング、JSON/MessagePackシリアライゼーションという、ゲーム開発で実際に使用されているOSSライブラリについて学ぶことができました。
  • 特に、picojson、json11、msgpack11という3つのシリアライゼーションライブラリが併用されている点は興味深く、それぞれの特性を活かした使い分けがされている可能性を感じました。
  • また、生成AIを活用した学習方法についても新たな気づきがあり、「書く」から「読む」へのシフトは、今後のプログラミング学習において重要な視点になるかもしれません。
  • ゲームの権利表記画面からここまで深掘りできるとは思っていませんでした。思わぬところに技術的な学びのタネは埋まっているのかもしれません。

(おまけクイズ)

上の4つの箇条書きの内、一点だけ生成AIではなく筆者が記載した文章があります。
それは上の4つの内どれでしょうか?
正解は↓にスクロールすると出てきます

(スクロール用の空のコードブロック)


























正解は4番目の

ゲームの権利表記画面からここまで深掘りできるとは思っていませんでした。思わぬところに技術的な学びのタネは埋まっているのかもしれません。

でした!

生成AIの出力する「優等生」で「なんか上手いこと言ってやった」感のある文章を読んでる内に、筆者にもそれが移ってきたのを感じたのでクイズにしてみました。当てられましたか?
(なお、最後の「おまけクイズ」のコーナーは全部AIではなく自力で書いてます)

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?