【AI時代の個人開発】6. AI時代でも、Pull Requestは最後の防波堤だった話

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

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

AIは、驚くほど速くコードを書き換えてくれます。
だからこそ、正式に反映する前に「この変更を通してよいのか」と立ち止まる工程が必要でした。

その役割を担ったのが、Pull Requestです。

Pull Requestとは、修正したコードを正式に反映する前に、変更内容を確認するための仕組みです。どこを、どのように変えたのかを一覧で見直し、問題がなければ正式なコードへ反映します。

個人開発なのに、わざわざPull Requestを作る必要があるのか。
最初は私も、その意味を十分に理解していたわけではありません。

けれども、AIを使って開発を進めるほど、その重要性が見えてきました。

Pull Requestは、単にコードの間違いを探すための仕組みではありません。もっと手前にある、大切な問いへ戻るための場所でした。

個人開発なのに、Pull Request が必要なのか？

Pull Requestという言葉から、チーム開発を思い浮かべることがあります。

誰かがコードを修正し、別の誰かが変更内容をレビューする。問題がなければ、正式なコードへ反映する。複数人で開発するなら、とても自然な流れです。

一方、個人開発では、そのすべてを自分で行います。

• コードを修正する

• 変更内容を確認する

• 正式に反映するか判断する

確認する相手が自分自身なら、Pull Requestを省略してもよいように見えます。開発を急いでいるときほど、確認工程は遠回りにも感じられます。

とは言え、AIは人間が一つずつ手作業で直す場合よりも、はるかに速く、多くのコードを書き換えます。依頼した箇所だけでなく、関連する複数のファイルが同時に変更されることもあります。

短時間で開発が進む反面、変更内容の全体像を把握しないまま、次の工程へ進む可能性も生まれます。

Pull Requestは、AIが生み出した変更をそのまま通過させず、自分自身で最終確認するための関所になりました。

開発のスタート地点は、いきなりコード生成ではなかった

このシリーズでは、AIツールの選び方やGitHub連携、Firebase認証、ログイン状態を維持する仕組みについて振り返ってきました。

その一方で、アプリ開発の最初に行った重要な作業については、まだ詳しく触れていませんでした。

それは、要件定義リストを作ることです。

最初からAIに、

とだけ依頼したわけではありません。

まず、次の内容を整理しました。

• どのような人に使ってもらうのか

• どのような場面で役立つのか

• 最初のリリースで何が必要なのか

• 現時点では何を入れないのか

思いついた機能をすべて盛り込むのではなく、サービスの主軸となる機能へ絞り込む。そのうえで要件定義リストを磨き、初回のReplit生成へ進みました。

AIを使えば、コードを書く工程は大幅に速くなります。

それでも、何を作るのかを決める工程まで省略できるわけではありません。AIが高速で実装できる時代だからこそ、最初に定める方向が、その後の開発を大きく左右します。

要件定義リストは、開発中にも参照する設計図だった

当初、要件定義リストは、アプリの初回生成に使うための資料という位置づけでした。

どのようなアプリを作りたいのかをReplitへ伝え、必要な機能を整理して、最初の形を作ってもらう。その役割だけでも十分に重要です。

開発を進めるうちに、要件定義リストには別の役割もあると気づきました。

変更内容が適切か判断するための基準です。

AIへ修正を依頼すると、短時間で複数のコードが変わります。UIの改善、入力項目の追加、エラー処理の見直し、認証まわりの修正。頼めば作ってくれるからこそ、当初の範囲を超えた変更が入り込む可能性もあります。

個々の変更だけを見れば、どれも便利に見えるかもしれません。けれども、それらが積み重なると、作ろうとしていたアプリの軸が少しずつ動くことがあります。

そこで確認したいのが、単に「動くかどうか」だけではなく、次の問いです。

要件定義リストは、最初に一度だけ使う指示書ではありませんでした。

開発が進んだあとも、進む方向を確認するために立ち戻る設計図になったのです。

Pull Request は、コードレビューの前に「仕様レビュー」をする場所

Pull Requestを確認するとき、最初からコードの細部を見る必要はありません。

実装内容の確認も大切です。意図しないファイルが変更されていないか、不要なコードが残っていないか、既存機能へ影響が出ないか。こうした点も見ていきます。

ただ、その前に確認するものがあります。

変更そのものが、アプリの目的に沿っているかどうかです。

私の場合、次の順序で確認していました。

コードとして正しく動いていても、不要な機能であれば、初期リリースへ加える必要はありません。

技術的に実装できることと、サービスとして今必要なことは別です。

Pull Requestは、コードレビューを行う場所であると同時に、仕様レビューを行う場所でもありました。

Pull Request で確認していた４つのこと

1. 要件定義から外れていないか

最初に見るのは、アプリの目的との整合性です。

• この変更は、初期リリースに本当に必要か

• 要件定義リストに存在しない機能が増えていないか

• 便利そうだからという理由だけで、仕様が膨らんでいないか

• 誰のための機能なのか説明できるか

• アプリの主軸から外れていないか

コードの良し悪しを判断する前に、変更そのものが必要かを考えます。

もちろん、開発を続ける中で、当初の要件を見直すこともあります。その場合は、実装だけを先へ進めるのではなく、要件定義リストも更新します。

変更後の前提をAIツールとも共有し、設計と実装が別々の方向へ進まないようにします。

2. 変更範囲は適切か

次に、影響範囲を確認します。

• 依頼した箇所以外まで変更されていないか

• 想定外のファイルが修正されていないか

• UI修正だけのつもりが、APIやデータ構造まで変わっていないか

• 不要な削除が混ざっていないか

• 既存機能に影響しないか

AIが複数のファイルをまとめて修正してくれることは、大きな強みです。その反面、変更範囲が広がりやすいからこそ、一覧で確認する意味があります。

3. 実装内容を自分の言葉で説明できるか

ここは、特に重要な基準です。

• なぜ、この修正が必要なのか

• どのファイルが変更されたのか

• 変更前と変更後で、何が変わるのか

• エラーが起きた場合に、どのような挙動になるのか

• 元に戻す必要が出たとき、影響範囲を把握できるか

すべてのコードを、自力で一から書ける必要はありません。AIに助けてもらいながら、変更内容への理解を深めていけばよいと考えています。

ただし、自分でも説明できない変更を、そのまま正式なコードへ反映すると、実際の仕様を把握できなくなる可能性があります。

AI開発を進めるうえで、私はこの基準を大切にしています。

4. 実際に問題なく動くか

最後に、動作確認を行います。

• 想定した操作が正常に完了するか

• 既存機能が壊れていないか

• 入力ミスや通信失敗時に、不自然な挙動にならないか

• 一時的なデバッグコードが残っていないか

• 画面表示だけでなく、裏側の処理も想定どおりか

「動いたから問題ない」ではなく、仕様と実装の両方が整っていることを確認します。

AIに任せることと、判断まで任せることは違う

AIへ任せられる範囲は、確実に広がっています。

コードを書く。関連箇所を探す。修正案を出す。エラーの原因を考える。改善案を提示する。これらの工程では、AIが頼もしい存在になります。

一方で、作りたいサービスを決め、要件との整合性を確認し、正式に反映するか判断する役割は、人間側に残ります。

AIを使うことと、AIへ丸投げすることは同じではありません。

Pull Request は、その境界線を明確にする場所でした。

Pull Request は、開発速度を落とす工程ではなかった

Pull Request を作り、変更内容を確認する。
この工程だけを切り取ると、手順が増えたように見えます。

すぐに反映できる変更を、あえて一度止める。
個人開発であれば、少し面倒に感じることもあります。

それでも、AIによって開発速度が上がるほど、立ち止まる工程の価値も上がります。

変更内容が要件から外れていないか。不要な機能が紛れ込んでいないか。自分の言葉で説明できるか。問題が起きたとき、どこを確認すればよいか。

これらを整理してから進めることで、結果として手戻りを減らせました。

AIが生み出した変更を、正式なコードへ通すかどうか。

最後に判断するのは、自分自身です。

Pull Request は、その判断を省略しないための最後の防波堤でした。

AIが進化するほど、問われるのは人間だった。

次回：
課金機能は最後の仕上げではなかった話

要件定義を基準に、AIが生み出した変更をPull Requestで確認する。個人開発でも、安全に前へ進むための形が少しずつ整ってきました。

そして次に向き合ったのは、これまでとは性質の異なる実装です。

お金が動く機能。

課金機能です。

当初は、課金機能はサービスが完成する直前に追加すればよいと考えていました。けれども、実際に実装へ進むと、その考え方を見直すことになります。

次回は、
「7. 課金機能は最後の仕上げではなかった話」
について振り返ります。

関連情報

次回：シリーズ７

前回：シリーズ５

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

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