システム開発の世界に10年以上いる。だから自分が何をしたのか、その異常さがよくわかる。
複数のプレイヤーがリアルタイムで競い合う、WebベースのビジネスシミュレーションゲームをAIと一緒に作った。複数の参加企業が毎ターン経営判断を入力し、市場シェアが自動計算され、財務諸表が更新される。DX投資の効果が数値として現れ、意思決定の巧拙が最終的な自己資本に反映される。
そのシステムが今、https://dxgame.jp で動いている。
従来の感覚なら、要件定義に1ヶ月、設計に1ヶ月、開発に半年、テストに2ヶ月。合計9〜12ヶ月。費用は数百万円から規模によっては数千万円。それが「普通」だった。
私がかけた時間は、数週間だ。
何を作ったか
DX経営ゲームは、参加者がそれぞれ製造業の経営者となり、毎ターン複数の経営判断を下すビジネスシミュレーションだ。価格設定、原材料の仕入れ量、生産指示、広告投資、設備投資、そしてDXへの投資。これらの判断が複合的に絡み合い、毎ターン市場での競争結果として数字に返ってくる。
技術的な構成を正直に書く。
バックエンドはPython製のWebフレームワーク「FastAPI」、データベースはPostgreSQL、フロントエンドはPWA（Progressive Web App）として実装したHTML/JavaScript。インフラはAWSのEC2インスタンス一台。参加者はスマートフォンから専用URLにアクセスするだけで参加できる。追加のアプリインストールは不要だ。
ゲームのコア計算エンジンだけで3,000行を超える。市場シェアの配分ロジック、DX変革の確率計算、製造原価の算出、キャッシュフロー計算書の自動生成、6軸の診断スコア計算——それらすべてを含むシステムが動いている。
自動検証スクリプトを走らせると35項目、34項目、すべてPASSと出る。本番環境とステージング環境のデータベーススキーマが完全に一致していることも確認済みだ。
これが数週間で作れた。
何が変わったのか
2023年頃から、AIを使った開発に本格的に取り組み始めた。最初は「コードの補完ツール」程度の認識だった。それが今は違う。
「AIとペアで考える」という感覚に変わった。
設計の相談をする。「このゲームで参加者が最も混乱しそうな部分はどこか」と問えば、数十のシナリオを想定した答えが返ってくる。「市場シェアをどう計算すべきか」と問えば、線形配分と二乗配分の違い、研修効果の観点からの考察まで展開してくれる。
実装の話もする。「PostgreSQLでこのスキーマ設計に問題はあるか」と問えば、インデックス設計の注意点、将来の拡張性、パフォーマンスの懸念まで指摘してくれる。
デバッグも一緒にやる。本番環境で「502エラー」が出た朝、ログを貼り付けて状況を説明したら、SIGTERM起因の問題を数分で特定できた。
もちろん、AIが完璧に答えを出すわけではない。間違いもある。判断を誤ることもある。それでも、一人の開発者が持つ知識の限界を、大幅に押し広げてくれる。
「作れた」ではなく「考え続けられた」
速く作れた理由を「AIがコードを書いてくれるから」と言う人がいる。それは半分正しく、半分間違っている。
本当の理由は、「考え続けるコストが下がった」ことだ。
従来の開発では、「このゲームバランスは適切か」という問いを検証するには、コードを書き、テストデータを用意し、シミュレーションを走らせ、結果を集計し——という一連の作業が必要だった。一つの仮説を検証するのに半日かかることもあった。
今は違う。「dx_extreme戦略とno_investment戦略を140ゲーム比較したい」と言えば、シミュレーションスクリプトを一緒に書いて、数十分後には結果が出る。「破産条件を現金マイナスに変えたらゲームバランスはどうなるか」という問いに、その場で実験できる。
試行回数が増えた。考える量が増えた。だから質が上がった。
「これは研修になるのか」という疑問
正直に言うと、作り始めた当初は確信がなかった。「ゲームで経営が学べるのか」という根本的な問いに、自分自身が答えを持っていなかった。
その疑問が晴れたのは、実際に体験してもらった人の反応を見たときだ。
DX変革に成功した参加者の競争スコアが他社の3倍になり、市場シェアをほぼ独占する——その瞬間が画面に表れたとき、他の参加者が思わず声を上げた。「これは現実と同じだ」と言った人がいた。
数字が競争の結果として返ってくる。投資判断の巧拙が自己資本の差になって現れる。破産した会社が緊急融資で復活しても、ランキングには戻れない。これらは、座学では説明できても体感できないことだ。
ゲームだからこそ、失敗のコストなしに体験できる。
なぜ今、これを書くのか
このシリーズは、DX経営ゲームをどう作ったかの記録だ。設計の判断、失敗と修正、AIとどう対話しながら問題を解いたか——その過程を可能な限り正直に書く。
「AIを使えばシステムが作れる」という話ではない。どう考え、どう問い、どう判断したか、という話だ。完成品の説明ではなく、作る過程のドキュメントだ。
次回は、なぜ「製造業の社長になる」というゲーム設定を選んだのか——コンセプト設計の話を書く。
AIとの対話パターン：私が使い続けた「問いかけの型」
数週間でシステムを作れた理由を振り返ると、AIへの「問いかけ方」に一定のパターンがあることに気づく。
最も使ったのは「比較させる」問いかけだ。「AとBどちらが良いか」ではなく、「Aを採用したとき・Bを採用したときのそれぞれのメリットとデメリットを具体的に教えてほしい」と問う。AIは一方的に結論を押し付けず、両方の観点を展開してくれる。設計の判断を自分でする材料が揃う。
次によく使ったのは「壊れるケースを教えてほしい」という問いだ。「この設計でどんな場合に問題が起きるか」と問うと、AIは自分では思いつかなかったエッジケースをいくつも挙げてくれる。例えば「ターン計算が途中でタイムアウトした場合、DBの状態はどうなるか」という問いへの答えが、トランザクション設計の改善につながった。
三つ目は「なぜそう思うか根拠を教えてほしい」という問いだ。AIが「この方法を推奨します」と言ったとき、そのまま採用するのではなく「なぜか」を問う。根拠が弱ければ再検討し、根拠が強ければ自信を持って採用する。
具体的な問いかけ例をいくつか挙げておく。「PostgreSQLのUUID型とBIGSERIAL型、どちらをプライマリキーにすべきか、パフォーマンスとスケーラビリティの観点で比較してほしい」。「このAPIエンドポイントに毎秒100リクエストが来た場合、ボトルネックはどこになるか」。「ゲームのターン計算で競合が発生した場合、参加者の体験にどんな影響が出るか」。
AIは「答えを出す機械」ではなく「一緒に考えるパートナー」だ。問いかけの質が、パートナーの応答の質を決める。このことに気づいてから、開発の速度と質が同時に上がった。
*シンプルシステム株式会社 代表 伊藤勝彦**DX経営ゲーム：https://dxgame.jp*