最近の個人開発では、かなりAIに手伝ってもらっています。
ただ、ひとつのAIに最初から最後まで全部を任せているわけではありません。
今は、ざっくり分けるとこんな感じです。
- ChatGPT ：やりたいことの整理、Codexへの指示づくり、作業結果の確認（レビュー）、NotionやGitHubへの記録
- Codex ：コードを書いたり直したりする作業（実装）と、そのテスト。変更内容をまとめた提案（プルリクエスト）づくりまで
- 自分 ：見た目や実際の端末での動きを確認して、最後に決める
止まっていたBlogを動かし直したときも、Codexに相談しながら進めていました。
🌱 
止まっていたBlogを、Codexと動かし直した話（Astro × Notion）
最初からこの形だったわけではなくて、いろいろ任せているうちに少しずつ役割が分かれてきました。
AIに全部やってもらうというより、 実装する役と、いったん横から見る役を分けた方が自分には扱いやすかった 、という話です。
全部をCodexに任せるより、間にレビュー役がほしかった
Codexには、開発中のコードや関連するファイルを直接読んでもらい、そのまま修正やテストまで進めてもらっています。
自分でファイルを1つずつ開いて直すより、かなり速いです。
ただ、実装が速いぶん、出てきた結果をそのまま採用するのは少し怖いところもありました。
コードとしては動いていても、最初に話していた意図と少し違っていたり、見た目は成立しているけど自分が気になっていたところが残っていたりします。
そこで今は、Codexの作業結果をChatGPTにも共有して、 意図した変更になっているかを自分と一緒に確認する ようにしています。
「仕様とずれていないか」
「この修正で別のところを壊していないか」
「Codexの説明と実際の変更内容は合っているか」
そんな感じです。
ひとりで見ると、どうしても「動いたからまあいいか」と流してしまうところがあります。。
そこをもう一度見る役がいるだけで、いったん立ち止まって確認しやすくなりました。
ChatGPTは、実装の前と後にいる
ChatGPTにコードを書かせないわけではありません。
ただ、今の使い方では、実装そのものより Codexへ渡す前と、返ってきたあと に使うことが多いです。
曖昧なままCodexへ渡さない
何か直したいところがあると、まずChatGPT側で話します。
「ここが気になる」
「前の仕様と合っている？」
「この変更を入れるなら、どこまで触るべき？」
自分の中ではまだ曖昧な状態でも、会話しながら条件を整理して、Codexへ渡せる形まで詰めます。
必要ならNotionにまとめた仕様や、GitHubに残している課題のメモ（Issue）、過去に決めたことも見てもらって、そこからCodexへの指示を作ります。
ここで自分がやっているのは、細かいコードの書き方を決めることより、 どこまでが今回の変更なのかをはっきりさせること に近いです。
出てきた結果を、そのまま次へ進めない
Codexの作業が終わったら、結果をそのまま次へ進めず、ChatGPT側でもう一度見ます。
変更内容、テスト結果、プルリクエストの説明、残っている懸念。
必要ならコードの変更箇所や画面のスクリーンショットも見ながら、次に直すべきことを整理します。
そこで問題があれば、またCodex向けの指示を作る。
この往復が、今の自分には合っています。
コードだけに残すと、「なんでこうした」が抜ける
もうひとつ分けているのが、実装そのものと記録です。
Codexにはコードの修正を進めてもらいますが、仕様の追記や判断の記録は、なるべくChatGPT側からNotionやGitHubへ書き残すようにしています。
- Notionの仕様を更新する
- GitHubに課題のメモ（Issue）を作る
- プルリクエストの説明を整える
- レビューで決まったことを追記する
- 次の作業へつながるメモを残す
このあたりをコードの中だけで済ませると、あとから「なんでこうしたんだっけ、、」と分からなくなりそうな気がしてなりません。
コードはGitHub、変わり続ける仕様や考えたことはNotion、その間をChatGPTでつなぐ。
今のところは、この分け方が一番追いやすいです。
SkillとMCPの使い分けを考えたときも、正本はNotionやGitHubへ残す、という分け方に落ち着いていました。
🧩 Notion SkillとMCP、結局どう使い分ける？実際にSkillを作って見えてきた役割
コストを気にするのは、主にCodexを動かすところ
AIを使っていると、モデル選びやコストも少し気になります。
ただ、自分が気にしているのは主に Codexに作業してもらうたびにかかる利用量やコスト の方です。
確認のたびにCodexをもう一度動かすより、まずChatGPT側で結果を読んで、本当に直してほしいところだけCodexへ伝える方が使いやすいです。
作業の内容によって、Codexで使うAIモデルや、どのくらいじっくり考えさせるかの設定も変えています。
小さな修正と、原因が分からない不具合の調査を、同じ設定で進める必要はないなと。
このあたりはまだ試している途中で、今後は「どのモデルが一番賢いか」より、 自分の作業をちゃんと終わらせるのにどれくらい手戻りとコストがかかったか で比べてみたいと思っています。
1回で終わらせず、何度か往復する前提にする
最近は、だいたい次の順番で進めています。
- 自分がChatGPTへ、やりたいことや気になるところを話す
- ChatGPTで仕様・過去の判断・関連するNotionやGitHubを整理する
- Codexへ渡す実装指示を作る
- Codexがコードの修正やテスト、必要ならプルリクエストの作成まで進める
- ChatGPTで結果を確認する
- 自分で見た目や実際の端末での動きを確認する
- 直してほしい点があれば、Codexへ伝える
- 最後にNotionやGitHubへ判断や進捗を残す
きれいに1回で終わることは、そんなに多くありません。
むしろ何回か往復する前提です。
でも、誰が何を見るかが分かれているので、「AIに任せたまま今どこにいるのか分からない」という感じはかなり減りました。
サイト刷新では、コードだけでは決められないところが残った
最近公開したtsukurun-Labのサイト刷新も、ほぼこの流れでした。
🪴 ショップだけでも、Blogだけでもない場所へ。tsukurun-Labのサイトを見直しました
自分が画面を見て「ここが少し気になる」と伝える。
ChatGPT側で仕様や前後の変更を確認して、Codexへ修正指示を出す。
Codexが直したら、公開前の確認用画面でまた見てみる。
特に見た目の調整は、コードだけ読んでも分からないことが多いです。
たとえばHero（ページを開いたときに最初に目に入る大きなエリア）は、背景が少し薄く感じて色を戻したら、今度はバナー画像の四角い輪郭が目立つようになりました。調べてみると画像そのものに背景が入っていて、透明背景の画像に差し替えています。
Blog一覧の詰まって見える感じや、右下の植物の見え方も、実際に画面を見て初めて気づくことが多かったです。
なので、最後の判断までAIへ渡すというより、 AIに進めてもらいながら、自分が気になったところへ戻れる形を残しておく 方が、自分には合っています。
AIに任せる範囲より、戻す場所を決めておく
最初は「どこまでAIに任せられるか」の方が気になっていました。
今はそれより、 どこでいったん止めて確認するか の方が気になります。
Codexが直したあとにChatGPTで見て、最後に自分が確認する。仕様が変わったらNotionに書き残して、コードの変更はGitHubに残す。
全部を自動でつなげるより、このくらい途中に止まる場所がある方が、安心して任せられます。
たぶん、この役割分担もモデルやツールが変わればまた少し変わると思います。
それでも今のところは、 実装はCodex、レビューはChatGPT、最後は自分で決める くらいの距離が、ちょうどよさそうです。