第1回：子供に投資をどう教えるか — ゲームという選択肢
はじめに — 子供に投資を教えるには
2022年4月、日本の高校で金融教育が必修化されました。資産形成、投資、リスク管理といったテーマが、家庭科の授業に組み込まれたのです。
しかし、正直に言えば、大人ですら投資の仕組みを正しく理解している人は少数派です。「株は怖いもの」「貯金が一番安全」という固定観念が根強い日本で、子供に投資を教えるとは、一体どうすればいいのでしょうか。
教科書を読ませても、子供の目は輝きません。かといって実際のお金を使わせるわけにもいかない。
「ゲームにすればいいのではないか」
この素朴なアイデアが、すべての始まりでした。
2015年：最初の構想 — すごろくで投資を学ぶ
実はこのプロジェクトの原点は、2015年にまで遡ります。金融教育義務化よりもずっと前から、「子供が楽しみながら投資の基本を学べるボードゲーム」というアイデアを温めていました。
コンセプトは明快です。
- サイコロを振ってボード上を進む、誰でも知っているすごろく形式
- 止まったマスでニュースが発生し、景気が変動する
- プレイヤーは景気を読んで株の売買を判断する
- 最終的な資産総額で勝敗が決まる
この時点で、ゲーム内の銘柄は架空の企業として設計しました。子供が親しみやすいように、名前にはすべてオノマトペを使っています。
| 銘柄名 | 業種 | リスク |
|---|---|---|
| ミンナノ・インデックス | 景気連動（分散投資） | 低 |
| モグモグ・フーズ | 食品 | 中 |
| ビリビリ・エナジー | エネルギー | 低〜中 |
| ロボロボ・ワークス | 製造・AI | 中 |
| ピコピコ・ゲームズ | IT・ゲーム | 高 |
| キラキラ・ファッション | アパレル | 高 |
「ミンナノ・インデックス」はインデックスファンドの概念を子供に伝えるための銘柄です。個別株と比べてリスクが低く、分散投資の効果を体感できるように設計しました。
ルール設計の段階では、紙とペンでプロトタイプを作り、実際に家族で遊んでみました。「マスの種類はどのくらいが適切か」「景気変動はどの程度が面白いか」「子供が飽きないターン数は何回か」 — こうした問いに、手作業で答えを探していきました。
マスの設計思想 — 9種類のイベント
最終的に、ボードのマスは以下の9種類に落ち着きました。
| マスタイプ | 内容 | 教育的意図 |
|---|---|---|
| ニュース | 歴史的ニュースが表示され、景気を予測して投資判断 | ニュースと株価の関係 |
| 配当 | 保有株から配当金を受け取る | インカムゲインの概念 |
| 暴落（CRASH） | 特定銘柄が急落 | リスクの体感 |
| 急騰（BOOM） | 特定銘柄が急騰 | 好機の判断 |
| 倒産 | 特定の保有銘柄が紙くずに | 集中投資のリスク |
| IPO | 新規銘柄を購入できるチャンス | 新規上場の仕組み |
| ボーナス | 臨時収入（お年玉、ボーナスなど） | 貯蓄と投資の選択 |
| 税金 | 資産に応じた税金を支払う | 税の概念 |
| チャンス | ランダムイベント | 不確実性の体験 |
ポイントは、良いイベントと悪いイベントのバランスです。暴落マスだけが目立つと子供は「投資は怖い」と感じてしまいます。配当やボーナスで「持っているといいことがある」という体験を織り交ぜることで、リスクとリターンの関係を自然に学べるように配慮しました。
後にコード化した際には、CRASH/BOOMマスを「CHANCE（チャンス）」マスに統合し、景気フェーズに応じて急騰・急落の確率が変動する仕組みに進化させています。
2024年：HTML5プロトタイプの試行錯誤
構想から約9年。2024年に入って、ようやくデジタル化に着手しました。ただし、最初から完成形を目指したわけではありません。段階的に4つのプロトタイプを作り、それぞれで異なるアプローチを試しました。
プロトタイプ1：紙芝居（Canvas + ボタン管理）
最初に作ったのは、HTML5 Canvas上に「紙芝居」のように画面を描画するシンプルなプロトタイプです。
document.addEventListener('DOMContentLoaded', function() {
const canvas = document.getElementById('gameCanvas');
const ctx = canvas.getContext('2d');
let currentPage = 1;
let playerName = '';
const buttonManager = new ButtonManager();
function drawPage() {
ctx.clearRect(0, 0, canvas.width, canvas.height);
buttonManager.clearButtons();
switch(currentPage) {
case 2:
drawText("昔昔、おじいさんとおばあさんがいました。", 100, 200);
buttonManager.addButton("次へ", 350, 400, 100, 50)
.action = () => { currentPage = 3; drawPage(); };
break;
case 3:
drawText("桃を持ち帰って家で空けると子供が出ました。", 100, 200);
buttonManager.addButton("前へ", 200, 400, 100, 50)
.action = () => { currentPage = 2; drawPage(); };
buttonManager.addButton("次へ", 500, 400, 100, 50)
.action = () => { currentPage = 4; drawPage(); };
break;
}
buttonManager.drawButtons(ctx);
}
});ButtonManager クラスでクリック判定を管理し、ページ番号で画面遷移を制御する、いわば「手動ルーティング」の仕組みです。桃太郎の物語をサンプルコンテンツにして、Canvas上でストーリーを進められるかどうかを検証しました。
学んだこと： Canvas直描画でもページ遷移は実現できますが、ボタンの座標管理やクリック判定を手作業で行う必要があり、UIが複雑になるとすぐに限界が来ます。
プロトタイプ2：Scene管理の導入
紙芝居方式の限界を感じ、次に取り組んだのがScene（シーン）パターンの導入です。
class Scene {
constructor(name) {
this.name = name;
}
draw(ctx) {
ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
ctx.fillStyle = 'black';
ctx.font = '24px Arial';
ctx.fillText(`This is the ${this.name}`, 50, 50);
}
}
class Game {
constructor(canvas) {
this.canvas = canvas;
this.ctx = canvas.getContext('2d');
this.scenes = {
menu: new Scene('Menu'),
game: new Scene('Game'),
end: new Scene('End Screen')
};
this.currentScene = 'menu';
}
switchScene(sceneName) {
if (this.scenes[sceneName]) {
this.currentScene = sceneName;
this.scenes[sceneName].draw(this.ctx);
}
}
}メニュー画面 → ゲーム画面 → 結果画面という遷移を、switchScene() メソッドで制御する設計です。ゲームエンジンが持つシーン管理の概念を自前で実装したものですが、これはまさにPhaser 3のScene APIと同じ思想でした。
学んだこと： シーン管理パターンは正しい方向性でしたが、アニメーション、物理演算、スプライト管理、音声再生…ゲームに必要な機能を一つ一つ自前で実装するのは現実的ではありません。
プロトタイプ3：Semantic UIでのモーダル実験
Canvas以外のアプローチも試しました。Semantic UI（CSSフレームワーク）を使って、HTMLのモーダルダイアログでゲームイベントを表示する方式です。
見た目はきれいでしたが、ボード上でコマが動くアニメーションや、サイコロを振る演出をHTMLの世界で実現するのは無理がありました。
学んだこと： ゲームのUI部分（売買パネル、資産表示など）はHTMLが適していますが、ゲーム本体（ボード、コマ、アニメーション）にはゲームエンジンが必要です。
なぜこれらのプロトタイプではダメだったのか
4つのプロトタイプを通じて、明確な結論が出ました。
- Canvas直描画は座標管理が煩雑で、UIが複雑になると破綻する
- 自前のScene管理は方向性は正しいが、ゲームエンジンの機能を再発明することになる
- HTMLベースのUIはゲームのインタラクションに向かない
つまり、本格的なゲームエンジンが必要だということです。
しかし、UnityやUnreal Engineはオーバースペックです。ブラウザで動くこと、Web技術（JavaScript/TypeScript）の知識がそのまま活かせること、軽量であること — これらの条件を満たすゲームエンジンを探した結果、Phaser 3 にたどり着きました。
さらに、ゲームのUI部分（設定画面、ランキング表示、認証など）にはReactの力を借りたい。そこで、Next.js + Phaser 3 という組み合わせが最終的な技術選定となりました。
次回予告
プロトタイプの段階で、もう一つ重要な課題が浮上していました。
ゲームで使う「ニュース」をどうするか、という問題です。架空のニュースでは子供の学びにならない。かといって、実在のニュースを手作業で入力するのは膨大な作業量になります。
次回は、Pythonによるデータパイプラインを構築し、Wikipediaから1900年代のニュースを自動収集、マクロ経済指標と組み合わせて株価シミュレーションを行った過程を解説します。
