はじめに
子どもとスマホアプリの「ポケポケ」にハマっています。
家族の写真でポケモンカード風の画像を作れたら面白そうだと思い、Webアプリを開発しました。
私のアカウントではChatGPT Plusを1か月無料で試せたので、使ってみることにしました。
CodexでのWebアプリ開発だけでなく、リポジトリを使った家族旅行の計画や職歴の整理にも利用しています。
思った以上に用途が広く、無料期間が終わってもそのまま契約を続けちゃいそうです。。。
このアプリの開発でもCodexを利用しました。
実装の指示はほぼスマートフォンから日本語で出しています。
この記事自体もCodexに執筆を依頼しました。
伝えたい内容や文章の違和感を私が伝え、生成された文章を確認しながら修正しています。
対象読者
- Codexを使った開発に興味がある方
- スマートフォンからどこまで開発できるか知りたい方
- AIを個人開発でどのように使うか知りたい方
- GitHub Copilotなどのコード補完は使ったことがあるが、AIへ実装全体を任せたことがない方
作成したアプリ
作成したのはOriginal Card Studioです。
名前や属性、技、説明文、画像を設定してオリジナルカードを作成できます。
入力内容はリアルタイムでカードへ反映されます。
完成したカードは高解像度PNGで保存できます。
- 公開URL: Original Card Studio
- GitHub: yuhara-4113-ai/original-poke-card-generator
- 使用技術: React 19、Vite 8、JavaScript、SVG、Canvas API、CSS、GitHub Actions、GitHub Pages
1年前にGitHub Copilotで挑戦した
約1年前にもGitHub Copilotに実装を任せて同じアイデアに挑戦しました。
当時は期待した見た目や操作感まで仕上げられませんでした。
完成できず、手元には中途半端なコードの残骸が残りました。
GitHubに残っているのはREADMEとライセンスだけです。
今回はCodexへリポジトリ全体の作業を依頼しました。
依頼した範囲には調査、実装、検証、修正、Git操作を含みます。
作り始めた当日に最初の動くバージョンができました。
数日間改善を続けて公開できる状態まで進めました。
AIの機能だけでなく、私自身の依頼方法も1年前とは変わっています。
単純な製品の性能比較ではありません。
それでも、以前は形にできなかったものが短期間で動いたことには驚きました。
スマホから指示する前の準備
スマホだけで開発を始められるわけではありません。
最初にPC側でCodexのプロジェクトを作成し、作業対象のGitHubリポジトリを指定する必要があります。
今回の流れは次のとおりです。
- PCにCodexアプリをインストールしてサインインする
- 対象リポジトリをPCへクローンする
- Codexでプロジェクトを追加してリポジトリのフォルダを選択する
- PC側の「Set up Codex mobile」からスマホを接続する
- スマホのChatGPTアプリから対象プロジェクトを開く
スマホ側のCodexは接続先PCにあるプロジェクトやファイルを利用します。
対象リポジトリを事前にプロジェクトへ登録していない場合、スマホから指示を出せません。
PC側のCodexアプリを起動し、PCをオンラインにしておく必要もあります。
PCがスリープすると接続は止まります。
詳しい接続方法はOpenAI公式のRemote connectionsを参照してください。
スマホからCodexへ指示した内容
私はコードをほとんど直接編集していません。
次の内容をスマホからCodexへ伝えました。
- 作りたい機能と背景
- ユーザーにどのように操作してほしいか
- 実際に使って感じた違和感
- 確認してほしい画面幅と操作
- ブランチ作成からPull Request作成までの作業範囲
画像を直接動かせるようにする
最初の実装では画像位置をスライダーで調整していました。
スマホでは操作しにくかったため、次の指示を出しました。
画像の位置調整を直感的にしたい。
今はスライダーだけど、画像の位置を直接調整できるようにしたい。
修正後はプレビュー上の画像をドラッグして位置を変更できます。
実装には既存のimageAdjustmentを利用しています。
画像描画の仕組みを作り直さず、入力方法だけを変更できました。
実際にスマホで触ると、スライダーよりもかなり操作しやすくなりました。
使いにくいと感じた点をそのまま日本語で伝えられるのは便利でした。
スマホで確認できる検証環境を作る
本番へ反映する前にスマホで確認したかったため、次の指示を出しました。
本番以外に検証環境を作ってほしい。
スマホで検証環境にアクセスし、問題がなければマージして本番環境にデプロイしたい。
codex/**ブランチへPushすると、GitHub Pagesの/staging/へ検証版がデプロイされます。
私は検証URLをスマホで開いて表示と操作を確認します。
問題がなければPull Requestをマージします。
スマホから自然言語で指示
↓
Codexがリポジトリを調査・実装
↓
lint / production build / ブラウザ確認
↓
codex/** ブランチへPush
↓
GitHub Pagesのstagingをスマホで確認
↓
Pull Requestをマージして本番公開
この流れを作ったことで、PCの前にいない時間でも開発を進められました。
寝ながら修正を依頼し、出先から検証環境を確認することもありました。
アプリの構成
バックエンドを持たないReact製のSPAです。
入力内容とアップロード画像はブラウザ内で扱います。
カード本体はSVGで描画しています。
PokemonCardGenerator（カード情報をstateで管理）
├── CardForm（入力）
├── PokemonCard（プレビュー、傾き、光沢）
│ └── CardArtwork（SVGでカードを描画）
└── DownloadButton（SVGをCanvas経由でPNG化）
フォームから受け取った値はPokemonCardGeneratorのstateへ集約します。
SVGのプレビューとPNG出力は同じデータを使います。
プレビュー用と保存用で別のカードを実装する必要がありません。
SVGとCanvas APIによるPNG出力
カードは660 × 921の固定座標を持つSVGです。
保存時はプレビュー中のSVGを複製します。
属性アイコンなどの外部参照画像をData URLとして埋め込み、Canvasへ描画します。
Canvasのサイズは1320 × 1842 pxです。
プレビューの2倍にすることで高解像度PNGを生成します。
光沢ありで保存する場合はCanvas上で光沢表現を合成します。
インタラクティブな光沢表現は@simeydotme/pokemon-cards-cssを参考にしました。
ライセンスを確認し、このアプリもGPL-3.0で公開しています。
画像はブラウザ内だけで処理
アップロード画像はFileReaderでData URLへ変換します。
変換後の画像はReactのstateとして保持します。
バックエンドへ画像を送信する処理はありません。
家族の写真を使うアプリなので、画像をサーバーへ送らないことは最初から意識していました。
アプリの画面にもブラウザ内だけで処理することを記載しています。
GitHub Actionsで検証と公開を自動化
mainブランチへ反映するとGitHub Actionsが次の処理を実行します。
npm cinpm run lintnpm run build- GitHub Pagesへデプロイ
検証環境ではmainから本番版をビルドします。
作業ブランチからは検証版をビルドします。
2つのビルド結果を1つのGitHub Pages成果物へまとめています。
site/
├── 本番版
└── staging/
└── 検証版
本番URLを維持したまま検証版を公開できます。
スマホで確認してから本番へ反映できるため、安心して修正を進められました。
コードレビューもAIに任せた
このアプリ開発では、人間によるコードレビューをしていません。
Pull Requestを作成した後は、Googleの「Gemini Code Assist on GitHub」へレビューを依頼しています。
Pull Requestへ/gemini reviewとコメントするとレビューが始まります。
レビューコメントはCodexに妥当性を確認させ、現在の実装に合う指摘だけを修正しています。
実際のデータの流れやコンポーネントの役割と合わない指摘は採用しません。
修正後はもう一度レビューを依頼します。
この進め方がすべての開発で正解だとは思っていません。
チーム開発や高い品質保証が必要な開発では、人間によるレビューが必要になると思います。
個人開発でまず成果物を作りたい場合は、スピードを保ちながらAIによるコードレビューも入れられます。
個人開発の1パターンとしてはアリだと感じました。
残念なのは、今回使っている一般ユーザー向けのGemini Code Assist on GitHubが2026年7月17日に終了することです。
Enterprise版は終了の対象ではありません。
詳しくはGoogle公式の終了案内を参照してください。
AI主導開発で人が担当したこと
期待する操作を言葉にする
同じ機能でも実装方法は複数あります。
今回は「画像位置を変更して」ではなく「スマホで画像を直接動かしたい」と伝えました。
実装方法を細かく指定するより、目的と制約を伝えることを意識しました。
生成結果を実際に触る
初回の実装後も修正を続けました。
スマホで操作して気になった点を追加で依頼しました。
- 入力欄の重なり
- 文字の位置
- ボタン名
- 光沢の初期値
- 画像の操作方法
UIは実際の画面で確認する必要があります。
Codexにも390 × 844相当の画面でブラウザ確認を依頼しました。
lintやbuildだけでは見つからない問題を修正できました。
変更範囲を決める
入力内容の保存機能では「画像以外でよい」と指定しました。
保存データのバージョン互換性も今回の対象外にしました。
範囲を絞ることで実装と確認を小さくできました。
小さな単位で依頼する
複数の機能を一度に依頼すると確認が難しくなります。
1つの機能ごとに実装、lint、build、ブラウザ確認を行いました。
固定座標を使うSVGは1箇所の変更が別のレイアウトへ影響します。
通常版と全面アート版、日本語と英語、PCとスマホを組み合わせて確認しました。
まとめ
1年前はGitHub Copilotを使っても形にできませんでした。
今回はCodexを実装担当として利用し、公開まで進められました。
寝ながらでも出先でもスマホから指示できます。
ここまでPCを開かずに開発できるとは思っていませんでした。
コードを書く時間は大きく減りました。
何を作るか、どこまで対応するか、完成と判断できるかは自分で決める必要があります。
個人のアイデアを動くプロダクトにするハードルが下がったと感じました。
今後のAIの発展にも期待しています。
本アプリは非公式のファンメイドツールです。
株式会社ポケモンおよび関連各社とは関係なく、承認・提携を受けたものではありません。