【AI時代の個人開発】8. AIに全部任せればOKではなかった話

AIを使う側から、使いこなす側へ。

※2026年7月3日更新
シリーズを書き進める中で得た気づきを反映し、リード文・構成・文章表現を見直しました。

AIツールを使い分けるようになってから、個人開発の速度は大きく上がりました。

バックエンドの実装や環境構築はReplitに任せ、フロントエンドの修正はCursorで進める。GitHubで変更履歴を管理し、分からないことや開発方針はChatGPTへ相談する。

以前なら何日も立ち止まっていた作業が、次々と形になっていきました。

だから私は、いつの間にか二つのことを同じように捉えていました。

開発が速く進んでいること。
開発全体が正しく進んでいること。

適切なAIツールを選び、それぞれへ実装を任せていけば、サービスはそのまま完成へ近づいていく。

課金機能の実装を見直すまでは、そう考えていました。

個々の処理が動くことと、サービスが壊れないことは違った

画面からプランを選び、Stripeの決済画面へ進む。

決済が完了すると、Webhookを通じてサービス側のデータが更新され、契約状態に応じた機能を利用できるようになる。一連の処理は、実際に動いていました。

エラーが発生すれば、その内容をAIへ渡して修正してもらう。動作を確認できたら、次の機能へ進む。その繰り返しによって、実装は着実に完成へ近づいているように見えました。

ところが、リリースを意識して全体を見返すと、正常に動くことだけでは判断できない問題が残っていました。

• 決済の途中でエラーが発生したら、データはどうなるのか

• 同じWebhookが複数回届いても、処理は重複しないか

• Stripe側とサービス側の契約状態がずれたら、どう復旧するのか

• フロントエンドとバックエンドで、契約状態の解釈は一致しているか

• 障害発生後に、原因を追跡できるログが残っているか

一つひとつの処理が動いていても、サービス全体として安全に運用できるとは限りません。

ここで初めて、動く実装と、壊れにくい設計は別のものだと気づきました。

AIが間違えたのではなく、依頼の単位が小さかった

最初は、AIが生成したコードの品質に問題があったのではないかと考えました。

しかし、実装の経緯を振り返ると、少し違いました。

Replitへバックエンドの修正を頼めば、指定した処理を実装してくれます。Cursorへ画面の変更を頼めば、対象となるコードを読み、必要な修正を進めてくれます。

どちらも、依頼された範囲では役割を果たしていました。

問題は、こちらが渡していた依頼の単位にありました。

• このAPIを追加する

• このエラーを直す

• この画面に契約状態を表示する

こうした依頼は、個々の作業を前へ進めるには有効です。一方で、依頼の外側にある問題までは、自動的には拾われません。

その修正が最初に決めた要件と一致しているか。別の処理との間に矛盾を生まないか。正常系だけでなく、異常系でも状態を保てるか。

問題が起きたあとに元へ戻す手段があるか、今直すべきものと後回しにできるものをどう分けるかといった判断も、個別の実装依頼だけでは見えにくくなります。

AIは、担当者として優秀でした。

ただし、プロジェクト全体を担当するAIはいませんでした。

ChatGPTへ「質問」ではなく「レビュー」を依頼した

転換点になったのは、ChatGPTへコードレビューを依頼したことでした。

それまでもChatGPTは使っていました。分からない技術用語を聞き、エラーの原因を相談し、開発方針を練るための壁打ちをする。

あくまで、困ったときに相談する相手でした。

このときは、渡す情報を変えました。

コードの一部分だけではなく、レビューに必要だと思われる材料をまとめて共有しました。

• 最初に決めた要件

• これまでの実装経緯

• バックエンドのコード

• Gitの差分

• 発生したエラー

• テスト結果

• リリース前に感じていた不安

依頼したのは、新しいコードの生成ではありません。

現在の実装が、サービス全体として成立しているかの評価でした。

返ってきた内容は、私が想定していたコードレビューの範囲を超えていました。

要件と実装のずれ、課金状態の持ち方に潜む危うさ、正常に処理できなかった場合の考慮不足。さらに、セキュリティ上の懸念や、障害発生後に状態を戻す手段の不足まで整理されました。

指摘は重要度ごとに分類され、どの問題から修正するべきかも示されていました。

そこで、ChatGPTに対する見方が変わりました。

ChatGPTがコードを書けること自体は、それ以前から知っていました。ただ、この個人開発では、実装を直接任せる使い方はしていませんでした。

分からないことを質問したり、戦略を練るための壁打ちをしたりする相手だったChatGPTが、要件・実装経緯・コード・テスト結果を横断し、開発全体に潜む問題を整理してくれた。

ChatGPTは、質問へ答えるだけでも、壁打ちをするだけでもない。
実装と設計を評価するレビュワーとしても使える。

私にとっては、それが大きな発見でした。

コードではなく、実装の理由までレビューする

コードベースへ直接入り込み、具体的な変更を進める作業では、ReplitやCursorが力を発揮します。

ChatGPTに感じた強みは、少し異なりました。

会話のなかへ、コード以外の情報も持ち込めます。

• 何を実現したいのか

• なぜその仕様にしたのか

• 途中でどのような問題が起きたのか

• どの修正を、どのAIへ依頼したのか

• テストで何を確認できたのか

• 運用開始後に何を懸念しているのか

それらをまとめて渡すことで、「このコードは動くか」だけでなく、「なぜこの実装になっていて、本来の目的に合っているか」まで確認できました。

コード単体では正しく見えても、前提となる要件とずれていることがあります。ある処理だけを直した結果、別の処理との整合性が崩れる場合もあります。

ChatGPTによるレビューは、個々のコードを確認する作業というより、要件・実装・運用の間にある矛盾を探す作業に近いものでした。

実装を直接進めるAIとは異なる役割を与えたことで、ChatGPTの強みが見えてきました。

レビューを、次の実装へつなげる

さらに大きかったのは、レビュー結果をそのまま次の実装へつなげられたことです。

それまでの流れは、各AIへ個別に依頼する形でした。

人間
　├─ Replitへ実装を依頼
　├─ Cursorへ修正を依頼
　└─ ChatGPTへ質問

各ツールから返ってきた結果を整理し、次に何をするか考える作業は、すべて自分の頭のなかにありましたが、ChatGPTをレビュワーとして使い始めてからは、流れが変わりました。

• 要件・現状・不安をChatGPTへ共有
  　　↓

• 問題点の整理と優先順位づけ
  　　↓

• ReplitやCursorへ渡す実装指示を作成
  　　↓

• 各AIがコードを修正
  　　↓

• Gitの差分とテスト結果をChatGPTへ戻す
  　　↓

• 再レビューして次の修正を決める

レビューして終わりではありません。

問題を構造化し、優先順位を決め、実装可能な指示へ落とし込む。戻ってきた結果をもう一度確認し、次の判断へつなげる。

この循環ができたことで、個別に動いていたAIツールが、一つの開発チームとしてつながり始めました。

ChatGPTを、AIツール群の管制塔として使い始めた

ここで、ChatGPTの役割は「質問に答えるAI」から、さらに変わりました。

人間：目的・要件・採否・最終責任
      ↓
ChatGPT：情報整理・レビュー・優先順位・指示設計
　├─ Replit：バックエンド・環境・デプロイ
　├─ Cursor：コード編集・フロントエンド修正
　└─ GitHub：差分・履歴・レビューの境界

ChatGPTが、すべてのコードを書くわけではありません。ReplitやCursorの代わりになるわけでもありません。

それぞれのAIが得意な仕事に取り組めるよう作業を切り分け、返ってきた成果物を全体の要件へ照らして確認する。

私にとってChatGPTは、AIツール群を見渡す管制塔になりました。

管制塔は、自ら飛行機を飛ばす役割ではありません。現在地と目的地を把握し、複数の動きを見渡しながら、衝突しないように進路を調整します。

AIを使った開発にも、それと似た役割が必要でした。

管制塔ができても、目的地を決めるのは人間だった

ChatGPTを管制塔として使い始めても、新たに「ChatGPTへ全部任せればよい」と考えたわけではありません。

管制塔があっても、目的地まで自動的に決まるわけではないからです。

人間には、引き続き決めるべきことがあります。

• 何を作るのか

• 誰のために作るのか

• 今回は何を作らないのか

• どの要件を優先するのか

• どこまでのリスクを許容するのか

• AIの提案を採用するのか

• 最終的な結果に責任を持てるか

ChatGPTは、共有された要件を基に矛盾や不足を見つけ、選択肢ごとの利点と危険性を整理できます。

一方で、サービスとして何を大切にするのかは、人間が決める領域です。

ChatGPTが管制塔になっても、目的地を決めるのは人間でした。

人間がすべての実装を抱える必要は薄れていきます。その代わり、人間の仕事は、AIが判断するために必要な情報を渡し、役割を設計し、最終判断を下すことへ変わっていきました。

「全部任せる」の意味が変わった

開発を始めたころ、私にとって「AIに任せる」とは、作業を渡して完成したものを受け取ることでした。

実装を依頼し、コードを受け取る。エラーを伝え、修正版を出してもらう。その繰り返しだけでも、開発速度は大きく上がります。

しかし、サービスが複雑になるにつれて、それだけでは足りなくなりました。

必要だったのは、一つのAIへすべてを丸投げすることではありません。

• 実装を進めるAI

• コードベースを読み、直接修正するAI

• 要件と実装を横断してレビューするAI

• 変更履歴を残し、差分を確認できる仕組み

• 目的と優先順位を決める人間

それぞれの役割を分け、情報と成果物が循環する開発体制を作ることでした。

AIに何を任せ、どの情報をどこへ集め、誰に全体を見せるのか。

「AIに任せる」という言葉には、作業を依頼するだけでなく、そこまで含めた設計が必要でした。

「AIを使いこなす側」とは

この個人開発を始めたころ、私にとってAIを使うとは、目的に合うツールを選び、必要な作業を依頼することでした。

しかし、複数のAIが開発へ参加するようになると、ツールを選ぶだけでは足りません。

それぞれの得意分野を理解し、役割を分ける。必要な情報を渡し、返ってきた成果を別のAIにレビューさせる。そして、全体を見ながら次の指示を組み立てる。

AIを使う側から、使いこなす側へ。

私にとって、その境界線は、AIへコードを書かせた瞬間ではありませんでした。

コードを書くAI、修正するAI、レビューするAIに役割を与え、情報と判断の流れまで設計し始めた瞬間でした。

私にとって「AIを使いこなす側」とは、複数のAIへ役割を与え、その力が一つの目的へ向かうように、情報と判断の流れを設計できる人でした。

動く実装を、壊れにくい設計へ

ChatGPTを中心としたレビューの流れができたことで、すでに動いていたStripe実装を、あらためて全体から見直せるようになりました。

そこで見つかったのは、単独のバグではありません。

• 課金状態をどのように保持するか

• Webhookをどの順序で処理するか

• 同じイベントが重複して届いた場合にどうするか

• エラー時の再送をどのように扱うか

• 何をログとして残すか

• 状態がずれたときに、どのように復旧するか

• フロントエンドとバックエンドで状態をどう共有するか

一つずつ継ぎ足して直すのではなく、全体を一つの設計として組み直す必要がありました。

次回のサブタイトルは、
「Stripe実装を『壊れない設計』に作り直した話」
です。

動いていたStripeの課金機能を、あえて一から見直しました。

決済に成功するだけではなく、問題が起きても検知し、正しい状態へ戻せる設計を目指しています。

決済できる仕組みから、安心してお金を預けてもらえる仕組みへ。

関連情報

次回：シリーズ９

前回：シリーズ７

【AI時代の個人開発】シリーズを最初から読む

創作大賞2026の選考期間中は、創作大賞2026 ビジネス部門 応募作品｜AI時代の個人開発 にも全10話をまとめています。