はじめに
さて、前回までで、機能面はかなり充実してきました。3モード（何切るクイズ・待ち牌クイズ・点数計算クイズ）＋タイマー＋戦歴＋BGMと、最初の想定を大きく超えた内容になっています。
しかしずっと気になっていることがあります。牌がまだUnicodeの絵文字のままです。
🀇🀈🀉……これ、環境によってフォントが変わるし、何より「麻雀アプリ」という雰囲気に欠ける。
今回はここを改善します。
前回同様、記事の中で度々麻雀用語が出てきますが、その解説を挟んでいると記事が麻雀解説記事になってしまうので、適宜以下のリンクなどを参考にしていただければ幸いです。
まず画像アセットを探す
第1回目で、何かしらの素材を自分で探すなりする必要があるということがわかりました。ですので、牌の画像を用意するところから始めます。自分で描くのは無理なので、オープンソースのアセットを探しました。
【豆知識】
●画像アセット
→ アプリやゲームで使う画像素材のこと。「アセット（asset）」は英語で「資産・素材」という意味。
●SVG（Scalable Vector Graphics）
→ 画像ファイルの形式のひとつ。JPGやPNGと違い、どんなサイズに拡大・縮小しても画質が劣化しない。アイコンやイラストによく使われる。牌のような図形はSVGと相性がいい。
無料で使える素材を教えてもらいます。
投げたプロンプト：
麻雀牌のSVG画像アセットで、商用利用可能なオープンソースのものを教えて。
返ってきたコードは、以下の通りです。
● 商用利用可能なオープンソースのSVG麻雀牌アセットとして
知られているものを挙げます。
主な選択肢
1. Wikimedia Commons の SVG 麻雀牌
- ライセンス：パブリックドメイン（PD）または CC0
- 各牌が個別SVGファイルとして公開されている
- 商用利用・改変・再配布すべて可
2. GitHub: FluffyStuff/riichi-mahjong-tiles
- ライセンス：CC0（パブリックドメイン相当）
- リーチ麻雀の全牌（萬子・筒子・索子・字牌・裏面）のSVG
- そのままWebアプリで使いやすいサイズ感
3. OpenGameArt.org
- CC0 や CC-BY のセットが複数存在
- ゲーム向けに整備されたものが多い
個人的なおすすめ: FluffyStuff/riichi-mahjong-tiles
CC0でリーチ麻雀向けに整備されており、Webアプリへの
組み込みが最も楽です。Wikimedia Commonsは牌ごとに
個別ダウンロードが必要なので手間がかかります。
✻ Sautéed for 40s
ちゃんと選択肢を出しつつ、おすすめまで教えてくれました。今回は FluffyStuff/riichi-mahjong-tiles を使うことにします。CC0ライセンスなので商用利用も改変も自由です。
さて、そもそも今回使う riichi-mahjong-tiles は、FluffyStuffさんというGitHubユーザーが公開している麻雀牌のSVG素材集です。そこで初心者丸出しの私は思うわけです。「そもそもGitHubにある素材？それを自由に使えるの？？？」と。
GitHubでは、プログラマーが作ったコードや素材を公開・共有しています。「コードのSNS」みたいなイメージで、世界中の開発者が自分の作ったものを無料で公開しているのだそうです。ありがたいことです。
今回使う riichi-mahjong-tiles も、親切な開発者様が「麻雀牌のSVG画像、みんな使っていいよ」と公開してくれているものです。CC0ライセンス（著作権フリー）なので、商用利用も改変も自由。
ダウンロード方法はシンプルで、GitHubのページを開いて「Code」からZIPをダウンロードするだけ。解凍すると中はこんな構成になっています。
riichi-mahjong-tiles-master/
├── ExampleBlack.png ← 見本画像
├── ExampleRegular.png ← 見本画像
├── LICENSE.md ← ライセンス情報
├── README.md ← 使い方の説明
├── Regular/ ← 通常デザインの牌SVG ← これが欲しいもの
├── Black/ ← 黒背景デザインの牌SVG
└── Export/ ← 別形式のファイル
牌のSVG以外にも説明ファイルや別デザインのフォルダも入っているので、Regular/ フォルダの中身だけを mahjong-app/images/ にコピーします。
マッピングするには
次に「Unicodeの絵文字」と「画像ファイル名」を対応付けるコードを書かなければなりません。
アプリの中では牌を「🀇」のようなUnicode文字で管理しています。
でも画像ファイルは「Man1.svg」という名前。
つまり「🀇が来たらMan1.svgを表示する」という対応表を34種類分、コードで書く必要があります。
もちろんClaude Codeに丸投げします。
投げたプロンプト：
牌の表示を、images/フォルダに入れたSVG画像に変えて。
Claude Codeはまずファイルの構造を確認しにいき、最終的に以下のような内容で生成してくれました。
私のような者には目がチカチカします。
こちらも毎度のことながら中身の理解は一旦置いておいていただき、こんなことまでしてくれるんだ！というのを体感していただければと思いコードを載せます。
const TILE_HONOR_NAME = {
31:'East', 32:'South', 33:'West', 34:'North',
35:'Haku', 36:'Hatsu', 37:'Chun'
};
function tileImg(id) {
let n;
if (id >= 1 && id <= 9) n = `Man${id}`;
else if (id >= 11 && id <= 19) n = `Pin${id - 10}`;
else if (id >= 21 && id <= 29) n = `Sou${id - 20}`;
else n = TILE_HONOR_NAME[id];
return `<img src="images/${n}.svg" alt="${NAME[id]}" class="tile-svg">`;
}
萬子・筒子・索子という3種類の牌については、番号からファイル名を計算する形にしてくれたみたいです。
つまり34行の対応表を書かなくても、計算で全部導き出せる設計になっている、ということです。
こんなロジックまで短時間で考えるなんて、本当にすごいですよね。
こっちはただ対応付けして、としか言ってないのに……！
結果：ほぼ動いた、でも字牌だけ表示されない
実際に表示してみますと……。
よすぎる！！感動！！！！！
本物の牌っぽい画像が並んで、一気にアプリらしくなりました。
ただ、よく見ると字牌（東南西北）が表示されていません。Claude Codeが East.svg・South.svg・West.svg・North.svg という英語名でマッピングしていましたが、実際のファイル名は違ったことが原因のようです。
ひがし、みなみ、にし、きた、とは麻雀界では表現しないんですよね……。
PowerShellで images/ フォルダを確認してみると：
Ton.svg ← 東
Nan.svg ← 南
Shaa.svg ← 西（← しかも「Sha」ではなく「Shaa」！）
Pei.svg ← 北
Claude Codeに伝えます。
投げたプロンプト：
字牌の画像が表示されていない。
実際のファイル名は Ton.svg・Nan.svg・Shaa.svg・Pei.svg だった。
以下のように返してくれました。
● 修正しました。Shaa の二重 a も含め正確に反映しています。
┌────────┬──────┬──────────────┬─────────────┐
│ ID │ 牌 │ 旧（間違い） │ 新（正しい）│
├────────┼──────┼──────────────┼─────────────┤
│ 31 │ 東 │ East.svg │ Ton.svg │
├────────┼──────┼──────────────┼─────────────┤
│ 32 │ 南 │ South.svg │ Nan.svg │
├────────┼──────┼──────────────┼─────────────┤
│ 33 │ 西 │ West.svg │ Shaa.svg │
├────────┼──────┼──────────────┼─────────────┤
│ 34 │ 北 │ North.svg │ Pei.svg │
└────────┴──────┴──────────────┴─────────────┘
修正後、全34種類の牌が正しく表示されるようになりました！！すごい！！
「フォルダを確認する」の限界
今回、Claude Codeは雑な指示であっても、自分でファイル構造を読みに行くまでしてくれました。
しかし字牌は一撃では難しかったようで、特に Shaa.svg は「Sha ではなく Shaa である」という、予測しにくいケースです。ファイルを確認しに行っても、実際に開いて中身を見たわけではなく、名前の一覧を把握する程度の確認だったようですね。
「大体は自律的に動けるが、予測しにくいエッジケースは人間が確認してフォローする必要あり」というのが、今回の正直な観察でした。
「規則性のある繰り返し作業」はAIの独壇場
今回一番感じたのは、34種類のマッピングという「ルールが明確で量が多い作業」をほぼ一瞬でこなしてくれたことです。
| 作業の種類 | 人間 | AI |
|---|---|---|
| 規則性のある大量データのマッピング | △ 疲れてミスが出る | ◎ 疲れない・速い |
| 複雑なアルゴリズムの設計 | 〇 論理的だが時間はかかる | 〇 得意だがエッジケースでバグることも |
| 「なんかおかしい」の感知 | ◎ 使えば気づく | △ 気付かない可能性あり |
手動でやっていたらとんでもない工数がかかり、タイポバグを数個仕込んでいたと思います。
いずれにせよ、AIに任せることによるメリットは大きいと感じます。
Claude Code観察メモ④
| 観察 | 内容 |
|---|---|
| 34種類のマッピング生成 | ◎ 一瞬 |
| 画像置き換えのリファクタリング | ◎ imgタグへの一括置換も正確 |
| 予測しにくいファイル名 | △ 場合によりフォローが必要だった |
| 修正指示への対応 | ◎ 症状を伝えたら一発で直した |
「人間がやると疲れてミスが出る作業」こそ、AIに任せる価値が最も高い。
ただし「完全に任せて終わり」ではなく、実際に動かして確認するという工程は省けません。
次回予告
機能・デザインともに整ってきました。
次はローカルで動いているアプリをNetlifyで公開して、スマホでも使えるようにします。