はじめに
今回もコードの解説ではなく、ChatGPTとの開発を
振り返って気づいたことを書きます。
前回の記事を書くために、昔の開発ログを読み返しました。
前回の記事：Pythonのif文とfor文がわかる程度の私が、生成AIとWindowsアプリを作って公開するまで
エラーがでてChatGPTに聞く。
教えてもらったコードを貼ってもエラーが出る。
……よく続けたな、当時の私。（笑）
今ならCodexにまとめて実装してもらえるような作業も、
2025年はChatGPTとのチャットで一つずつ進めていました。
効率だけ考えたら、ずいぶん遠回りだったと思います。
ところが、振り返ってみると、あれはあれでよかった気がするんです。
最初からCodexで全部作っていたら、
私はアプリがどんな構成で動いていて裏側で何が起きているのか、
もっとわからないままだったんじゃないか。
そもそも、最初から「利用者にどんな体験を届けるか」なんて考えていたら、
趣味のアプリは完成する前に投げ出していたかもしれません。
今回は、そのあたりの話を書いてみます。
チャットで作るのも、案外悪くなかった
最初の頃は、ChatGPTに聞いた手順を私が実行する、という開発でした。
「このファイルを作ってください」「ここにコードを貼ってください」「PowerShellで実行してください」
言われた通りにやってみる。動かなければ、エラーを持ち帰ってもう一度聞く。
あるとき、画面左側に表示するはずの画像が真っ黒になりました。
あれこれ修正しても直らないのに、テスト用の市松模様だけは表示される。そこでChatGPTに返したのが、こんな報告です。
市松模様はOK
画像は開かない
当時は原因を説明できるほどの知識がありませんでした。
それでも「ここまでは動いている」「こっちは動いていない」という
切り分けはできたんですね。
もちろん、ChatGPTが提示した修正も外れることがあります。
「完璧です！」と言われた直後に動かない、なんてこともありました。
完璧とは・・・。
まぁ、人間も同じことしちゃいますけどね。
「完璧な資料だ！」と思って、資料を上司に提出したら、
たくさん赤ペン先生された挙句、
その資料が使われない…なんてこと、あるよね。
やりとりが面倒だからこそ、「なんとなくわかるレベル」になれた
コードを貼って自分で実行していると、何となく見えてくるものがあります。
アプリは一枚の画面だけでできているわけじゃない。
ファイルがあって、実行するための環境があって、画像を読み込む処理がある。
問題が起きたら、どこまで動いているかを確かめる。
一つひとつは初歩的な話です。
コードの中身やアプリの構成を全部理解できているわけではありません。
それでも、開発ってだいたいこうやって進むんだな、という感覚は残りました。
Codexに任せるようになって
2026年のCwC開発では、Codexに日本語で要件を渡し、
コードの修正やファイル構成の整理を進めてもらいました。
これは本当に楽です。以前のように、返ってきたコードを
自分で一か所ずつ貼り替える必要がありません。
その代わり、「お、アプリができている！」「動いたからOK」で終わってしまう。
Codexは変更内容を確認する手段も用意してくれます。
でも、表示された差分や作業報告を読むにも、
多少の前提知識が必要です。
私の場合、チャットで散々つまずいた経験が、
その前提知識の一部になっていました。
ターミナルって何だよ…
と、ChatGPTに聞くところから積み重ねてきた経験が、
思わぬところで役に立っています。
最初は個人の趣味で開発をスタートしておいてよかった
もう一つ、今回の開発で大きかったと思うことがあります。
それは、いきなりガッチガチの要求定義、要件定義から入らなくてよかったこと。
お姉さんChatGPTと会話したい…
完全に欲求ベースの趣味です(笑)
欲求（要求）を、ひとつずつ具現化していく楽しさ
最初に作ろうとしたのは、世の中にリリースするための体験を与えるアプリではなく、
画面の左にキャラクター画像、右にChatGPTを表示するだけのアプリでした。
それが動くと、今度はBGMが欲しくなる。起動音も付けたい。
音のフェードインを調整したい。キャラクターに合わせて配色も変えたい。
次から次へと注文が増えました。完全に自分用です。
当時は「このアプリは誰のどんな課題を解決するのか」なんて考えていません。
自分が使って楽しいかどうか、それだけ。
でも、趣味の開発としては、それくらいでよかったと思っています。
もし最初に「想定ユーザーを決めましょう」
「利用シーンを整理しましょう」
「要求と要件を定義しましょう」と言われていたら、どうだったでしょう。
たぶん、画像を一枚表示する前に疲れていたと思います。（笑）
要求や要件の整理が不要という話ではありません。
後になって、その必要性は嫌というほど感じました。
ただ、まだ何も動いていない段階で、全部を決める必要はなかった。
作って、触って、気に入らないところを直す。
すると次に欲しいものが出てくる。
「アジャイル開発」という言葉は以前から知っていましたが、
小さく試して、その結果で次を決めるという進め方が、
自分の趣味の開発にも合っていたんだなと、後から思いました。
ただし、行き当たりばったりで機能を増やすだけなら、
いつか破綻するはずです。
私も「欲しいから追加」を繰り返すうちに、
自分が何を作っているのか整理する必要が出てきました。
使う人のための、ガチガチのコンセプト設計と要求・要件定義
自分用のアプリを触っているうちに、
「これ、他の人にも使ってもらえないかな」と思うようになりました。
ここで初めて、考えることが増えます。
アプリそのもの
そもそも、どのようなユーザーに、どのような価値を感じてもらうのか？
アプリの仕様
何度も触っている私ならわかる操作でも、初めて使う人は迷うかもしれない。
設定を間違えたらどうなる？
データが壊れたら戻せる？
配布するZIPに、余計なファイルが入っていない？
自分用なら、問題が起きても自分で直せば済みます。
他の人に使ってもらうとなると、そうもいきません。
CwCはこの段階で、Codexと一緒に配布を意識したWindowsアプリとして作り直しました。
初回設定や保存時の競合、バックアップ、配布物の検査など、
それまであまり意識していなかった部分も開発の対象になりました。
同時に、「そもそも何を届けたいアプリなんだろう」と考え直しました。
BGM、キャラクター画像、配色、画面の並べ方。
自分が欲しくて足してきた機能を眺めていると、
単にAIと会話したいだけではなかったようです。
そこで整理したのが、
キャラクターと日常を分かち合う場所
というコンセプトでした。
普通はコンセプトを決めてから機能を考えるのかもしれません。
でも私の場合は逆。
作ったものを見返して、ようやく自分が欲しかったものに名前を付けられた、
という感じです。
最初から利用者の体験を考えるべきだった、と言ってしまえばそれまでです。
でも、そうしていたら今のCwCは生まれなかった気もしています。
「動けばおｋ」から「動かなくなったときに戻せるようにする」
はじめのうちは、気が向いたときにフォルダ名を
「two-panel-app_rev**」に変えるくらいの、
おおざっぱなバージョン管理でした。
でも、Codexに実装を任せるようになると、開発がゴリゴリ進んでいく。
何を変えたのか追いきれないし、
ひとつ前に戻すのも、Ctrl+Zや単純なコピペではできません。
「ひとつ前に戻して」とCodexに頼めば、その分クレジットも減っていく……。
そこで、Gitで変更履歴を残す意味がようやく腑に落ちました。
チャットで自分の手を動かしていた頃と、Codexに任せるようになってから。
両方経験したからこそ、変更を追えて、
後戻りできる仕組みのありがたさがわかった気がします。
個人開発でこれだから、チーム開発となると…（ｿﾞﾜｯ
おわりに
最近のAI開発ツールを見ていると、
最初から本格的なアプリを作れそうな気がします。
実際、それができる人もいるでしょう。
でも、私の場合は違いました。
チャットでコードを貼って、エラーを出して、少しずつ仕組みを知る。
自分が欲しい機能から始めて、
作ったものを触りながら次を考える。
そうやって遊んでいるうちに、
いつの間にか人に配布するアプリを作る話になっていました。
順番を逆にしていたら、たぶん続かなかったと思います。
これから何か作ってみたい人も、
最初は「こんな機能が欲しい」くらいで
始めていいんじゃないでしょうか。
少なくとも私は、それでここまで来ました。
次回は「ガチガチのコンセプト設計」の話をします。
前回の記事：Pythonのif文とfor文がわかる程度の私が、生成AIとWindowsアプリを作って公開するまで
CwCの紹介・配布ページ：https://gyoumunohonshitsu.com/cwc/