0
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?

ジェバンニが小一時間ぐらいでやってくれました

Last updated at Posted at 2025-10-08

私は現在、MC68030、YM2612 (OPN2)、自作VDPを搭載した新型16bitゲーム機 VGS-X を開発中です。(本書執筆時点では version 0.22.0 のβ版)

YM2612 (OPN2) の実装には ymfm という OSS を利用してます。

この ymfm を前世代のゲーム機 VGS-Zero に搭載して、VGS-Zero でも YM2612 (OPN2) の再生に対応させたいと考えたのですが、VGS-Zero は Circle フレームワークを用いて RaspberryPi Zero 2W のベアメタル環境にも対応していて、Circle フレームワークでは C++ の STL テンプレートなどが利用できないという制約があります。

ymfm は STL テンプレートをゴリゴリ使っていて、STL テンプレートを用いた実装を標準Cのみの実装に置き換えることは機械的にできるものの、中々大変な作業になります。

ただ、ChatGPT の Pro プランに加入すれば使える Codex が中々スゴイらしいということで、お試しで Pro プランに加入して使ってみたのですが、ものの小一時間程度でこの面倒な作業を完遂してくれました。

以下の Pull Request が、Codex への指示のみで作成したコードです。

これを作成するために実施した手順を記します。

1. Codex を準備

ChatGPTにVisual Studio Codeで目的の作業を実施する手順を確認。

以下の記事も参考になります。

2. 変更をリクエスト

プロンプトで、

stlを使用している箇所を標準cに変更したい

とリクエストを入力。

image.png

だいたい10分ぐらいでこの commit の成果ができました。

このコードを VGS-Zero へ持って行って Circle でビルドしたところ、C++のC標準ヘッダ(cstd*)との依存関係が解決できずにエラーが出ました。

そこで、「#include をC標準ヘッダに置換」とリクエスト。

また、ヘッダファイルを複数ソースから #include した時にシンボル衝突が発生してリンクエラーになったので、「ymfm_opn2.hppを複数ソースコードからincludeした時にシンボル衝突エラーが起こらないように修正」と指示しました。

このたった3回の修正リクエストだけで RaspberryPi ベアメタル向けのビルドが通るようになりました。

3. 実機テストで問題発覚

RaspberryPi Zero 2W ベアメタル向けのカーネルビルドが通ったのでいざ実機で動かしてみたら Synchronous exception...

image.png

とりあえずデバッグログを埋め込んで落ちている箇所を調べてみたところ、VGS0クラスのインスタンスを作成している箇所で落ちていることが分かりました。

そこで、codexに「VGS0クラスのインスタンス作成部分でSynchronous exceptionになる原因調査」とプロンプトで依頼したところ、サブモジュールで入れている circle まで辿って原因をアッサリと突き止めてくれました。

ちなみに原因はヒープ不足です。

VGS-Zeroカーネルは64MBのカーネルバッファ(デフォルトは2MB)を確保しているのですが、カーネルバッファがデカ過ぎる影響でヒープ領域がもの凄く少なく、それを回避するためにVGS0クラスのインスタンスをヒープではなくスタックで確保していたのですが、スタック上限を超過したことに加えてVGS0クラス内部で生成しているヒープの確保でもメモリ不足になっていたことが根本的な原因でした。(これぐらいの複雑度だと一発のプロンプトでは特定できず、テストコードを入れた実機テストをするなどして数回のプロンプトを繰り返して特定)

そこで、VGS0クラスではヒープを使わないようにする修正した上でインスタンスを静的領域に移動する処理の実装を依頼することで解決できました。

以下のPull Requestがその対応内容です。

上記Pull Requestで私がやったことといえば README.md を書いたり CHANGELOG.md を書いたりなど。(このあたりも実は codex に頼めるかも?)

かなり昔にオフショア開発のマネジメントをしていたことがあるのですが、その時の感覚に近いです。やりとりも全部英語だったので尚更。ちなみに日本語で依頼することもできて、当初私は日本語を使っていたのですが、結果は全部英語で返されます。なので、途中から質問も全て英語でするようにしました。その方が多分正確に伝わり無駄なやり取りが減りそうかなと。

所感

私の同人活動では当然ながら従業員を雇える程度の稼ぎは無いのですが、Codexを用いることで従来なら月1万ドルぐらいの優秀なプログラマを3人ぐらい雇わないと行けなかったステージへ進むことができそうな感触です。

3万ドル/月(社会保険料を考慮すれば6万ドル/月?)の固定費を捻出するのは非常に困難ですが、Codex氏なら20ドル/月なので私の個人事業の稼ぎでもお賃金をお支払いすることができます。

今後は「IT土方」ではなく「IT親方」のスキルが重要になりそうです。

Codex氏は超絶優秀ですが基本「指示待ち」なので、生成AIでできることの見極めとソリューションのための作業項目の洗い出しの最適化レベル(親方スキル)により「月1万ドルぐらいの優秀なプログラマn人分」のnが0にもなれば100にもなりそうです。

0
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
0
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?