AI コーディング：生成された変更を確認して公開する手順

結果を説明できる小さな変更から始める

AI に依頼する変更は、目に見える結果が一つあると評価しやすくなります。「アプリを改善して」には明確な終点がありません。「検索結果がゼロなら案内を表示し、ほかの検索は正常に動くようにして」なら、確認する対象が定まります。以下は当サイトが考えた練習手順であり、ベンダーによる成果の保証ではありません。

GitHub は、生成されたコードにもレビューとテストが必要だと説明しています。制約は Copilot のアプリケーションカード ↗で確認できます。Anthropic の検証ループの記事 ↗は、確認と修正の繰り返しを紹介しています。自分の開発手順を組み立てる際の参考になります。

生成前に受け入れ条件を書く

小さな検索機能なら、三つの条件を記録します。空の検索語では全項目を表示すること、タイトルの検索で英字の大文字と小文字を区別しないこと、一致する項目がなければ明確な案内を出すことです。それぞれに入力例を添えます。選択中の言語や記事リンクなど、維持したい挙動も書いておきます。

関連ファイル、プロジェクトで使っている確認コマンド、入力例を助手に渡し、編集前に変更予定の箇所を説明してもらいます。結果と照らし合わせられる短い仕様ができ、目的と関係のない変更を問い直す根拠にもなります。

動作を確認してから差分を読む

まず、プロジェクトで既に使われているチェックを実行します。そのうえで、今回の機能に対応した動作確認を一つ選びます。画面の画像だけでは検索ロジックの正しさは証明できません。この練習では、大文字と小文字を変えた二つの検索語と、絶対に一致しない検索語を試します。画面を変更した場合は、狭い幅でも確認します。

次に、実際のファイル差分を読みます。削除された入力検証、無視されるエラー、新しい依存関係、共通コンポーネントの変更に注意します。余分に変更された各ファイルが何に役立つかを確認してください。チェックの成功は、そのチェックが対象にしたケースの証拠であり、機能に関するあらゆる疑問を解決するわけではありません。

失敗した場合は、具体的な入力と観察した結果を伝え、その問題の修正を依頼して、関係するチェックを再実行します。コマンド、結果、コミットを簡単に記録すると、確認した版を特定できます。

戻せる形で公開する

プレビュー環境で、受け入れ条件の例をもう一度試します。この練習は表示と検索に範囲を絞り、データベースの移行を伴わない変更にします。以前に公開したコミットを保存し、復元方法を把握しておきます。公開後は、実際の URL で同じ短い確認を繰り返します。

30 分の練習

自分が理解しているプロジェクトから小さな改善を一つ選びます。最初の五分で受け入れ例を三つ書き、十五分で生成と確認、残り十分で差分とプレビューを確認します。これは練習用の時間配分で、速度を保証するものではありません。役立つ成果は、確認できる証拠が付いた小さな変更です。公開前に練習を終える場合も、その記録は残してください。