AIコーディングの使い方：リスクを減らすワークフロー

AIに安全に手伝ってもらうためのルール

AIコーディングの使い方で一番効くのは、推測が危険になるまさにその場面で、AIをあえてゆっくり進ませることです。AIは見慣れないコードを説明し、エラーを仮説に変え、テストの下書きを作り、差分をレビューし、リファクタリングを提案できます。その一方で、存在しないAPIをでっち上げ、隠れた依存関係を見落とし、貼り付けた断片に過剰に合わせ、保ちたかった挙動を変えながらも見た目はきれいなパッチを出すこともあります。

このルールを使いましょう。AIは提案できますが、決めるのはあなたのリポジトリです。よりどころになるのは、コードベース、失敗する再現手順、テストスイート、実行時のログ、プロダクトの要件、そして人間のレビューです。良いAIのペアプログラマーは、それらの材料を置き換えるのではなく、そこから考えを進める手助けをしてくれるはずです。

ルール	なぜ重要か	モデルに何を頼むか
まず再現する	当てずっぽうのパッチを防ぐ	「コードを提案する前に、失敗している挙動と証拠を言い直して。」
範囲を小さく保つ	リグレッションのリスクを下げる	「最小で安全な変更を提案して、触るファイルを挙げて。」
挙動を保つ	利用者と公開インターフェースを守る	「この変更が壊してはいけない不変条件を挙げて。」
テストを必須にする	答えを検証できるようにする	「修正前は失敗し、修正後は通るテストを書いて。」
マージ前にレビューする	自信満々の間違いを捕まえる	「この差分を、正しさ、セキュリティ、抜けている境界ケースの観点でレビューして。」

これはどのモデルでも同じです。OpenAI、Anthropic、その他の提供元は、能力、コンテキストウィンドウ、ツール利用のパターンの違いを説明するモデル文書を公開しています。そうした能力は役に立ちますが、規律あるワークフローの代わりにはなりません。エンジニアリングの仕事では、チームメイトを見るのと同じ基準でモデルを見ましょう。足りない背景情報を尋ねてくるか、不確かさを減らすか、制約を守るか、あなたが検証できる痕跡を残すか、です。

デバッグのワークフロー

信頼できるAIデバッグのワークフローは5段階です。再現する、切り分ける、仮説を立てる、パッチを当てる、検証する。「これを直して」から始めてはいけません。証拠から始めましょう。失敗するコマンド、正確なエラー、期待する挙動、観測された挙動、関係するコード、環境の情報、そして原因になりえた直近の変更をモデルに渡します。

段階1：再現を記録する。バックエンドのコードなら、リクエスト、レスポンス、ステータスコード、ログ、失敗するテストを含めます。フロントエンドのコードなら、ルート、ユーザーの操作、ブラウザのコンソールエラー、ネットワークの応答、コンポーネントの状態、必要ならスクリーンショットの説明を含めます。ビルドの問題なら、コマンド、パッケージマネージャー、Nodeのバージョン、最初の失敗の前後を含む完全なエラーを含めます。

段階2：コードより先に仮説を求める。慎重なモデルなら、ありそうな原因を順位づけし、それぞれをどの証拠が支えるかを説明できるはずです。原因を区別できないなら、最小の診断ステップを聞きましょう。ログを1本足すこと、絞ったテストを1件書くこと、型チェック、あるいはもう1ファイル読むことかもしれません。

段階3：最小のパッチを求める。理由を正当化できない限り、変数名を変えない、周囲のコードを書き直さない、依存を増やさない、公開された挙動を変えない、とモデルに伝えます。根本原因、パッチの概要、触るファイル、テスト、リスクを返すよう頼みましょう。

段階4：ローカルでテストを走らせる。AIの出力は検証の工程ではありません。検証の工程は、挙動を証明するコマンドかユーザーの操作です。自動テストがないなら、まず回帰テストを作らせ、そのうえで修正を実装させます。

デバッグ用プロンプト：

慎重なデバッグの相棒として振る舞って。まだコードは書かないで。最初に、再現手順、期待する挙動、観測された挙動、そして最もありそうな根本原因を3つ言い直して。各原因を証拠の強さで順位づけして。そのうえで最小の診断ステップを提案して。バグ：[説明]。コマンドまたはユーザーの操作：[貼る]。エラーやログ：[貼る]。関係するコード：[貼る]。制約：[技術スタック、触ってはいけないファイル、保つべき挙動]。

修正用プロンプト：

確認できた根本原因をもとに、最小で安全な修正を提案して。返すもの：根本原因、変更するファイルと関数、パッチの概要、修正前は失敗し修正後は通るテスト、境界ケース、切り戻しのリスク。関係のないコードはリファクタリングしないで。背景情報：[貼る]。

コードレビューのワークフロー

AIは、最初の書き手としてよりレビュアーとして力を発揮することが多いです。差分のレビューを頼めば、見落とした境界ケース、セキュリティの問題、古くなった前提、テストの抜け、挙動の変化を探せます。大事なのは、レビューを具体的にすることです。「これで良さそう？」と聞けば、丁寧な承認が返ってきます。正しさのリスクを聞けば、役に立つ反論が返ってくる見込みはずっと高くなります。

差分、意図した挙動、関連するテスト、そして制約をモデルに渡します。保守性に響かない限り、細かなスタイルは無視するよう頼みましょう。欲しいのは、見せかけの重箱の隅つつきではなく、バグを優先するレビューです。

レビュー観点	AIに答えてほしい問い
正しさ	この差分は本当に要件を満たしているか。
リグレッションのリスク	既存のどの挙動が意図せず変わりうるか。
セキュリティ	入力、認証、秘密情報、権限、インジェクションのリスクは扱えているか。
エラー処理	null、タイムアウト、再試行、不正な応答、中途半端な状態のときはどうなるか。
テスト	挙動についてのどの主張が検証されていないか。
保守性	プロジェクトの流儀に従い、変更を理解しやすく保てているか。

コードレビュー用プロンプト：

厳しいが実務的なメンテナーとして、この差分をレビューして。正しさ、リグレッションのリスク、セキュリティ、境界ケース、足りないテストに集中して。本当の保守リスクにならない限り、細かなスタイルは無視して。問題、優先度、差分の中の証拠、提案する修正、必要なテストを表にして返して。意図した挙動：[貼る]。差分：[貼る]。既存のテスト：[貼る]。

リスクの高い変更では、Whiziでモデルごとの修正を比べるワークフローを使いましょう。同じレビュー用プロンプトを2つか3つのモデルで走らせます。あるモデルが問題の可能性を見つけても、鵜呑みにしてはいけません。その問題がコードベースで本当に起きるのかを確かめます。目的は意見をたくさん集めることではありません。マージの前にレビューの面積を広げることです。

リファクタリングとテストのワークフロー

AIでのリファクタリングが危ういのは、多くのリファクタリングが「変わらなかったこと」で評価されるからです。モデルはコードを見た目よく整えながら、挙動、エラー処理、タイミング、公開インターフェースをひそかに変えてしまうことがあります。より安全なリファクタリングのワークフローは、実装に触れる前に不変条件を定義するところから始まります。

手順1：リファクタリングの目的を書く。例：重複を減らす、大きなコンポーネントを分割する、データアクセスを切り離す、分岐を単純にする、APIラッパーを移行する、テストしやすくする。そのうえで、変えてはいけないものを明言します。公開関数のシグネチャ、ルートの挙動、イベント名、レスポンスの形、分析計測、権限、アクセシビリティの挙動、性能の期待値です。

手順2：段階に分けた計画を求める。役に立つAIのリファクタリング計画は、元に戻せるものです。各段階は狭い範囲に触れ、テストを含み、動く中間状態を残すべきです。コードがごく小さくテストで十分に覆われている場合を除き、一気の書き直しは避けましょう。

手順3：現状の挙動を固定するテスト（特性化テスト）を書く。コードを変える前に、いまの挙動を洗い出し、重要なケースを固定するテストの下書きをAIに頼みます。こうしたテストは、意図がはっきりしないレガシーコードでとくに役立ちます。通常の入力、境界の入力、失敗の経路、そしてリファクタリングの理由に結びついた回帰ケースを1つ含めましょう。

手順4：一度に1段階だけ実装する。各段階のあとにテストを走らせ、範囲を絞ったレビューを頼みます。モデルが大きな抽象化を提案してきたら、その抽象化が本当の重複やリスクを取り除くことを証明させましょう。そうでなければ、コードは退屈で局所的なままにしておきます。

リファクタリング計画用プロンプト：

段階に分けたリファクタリング計画を作って。目的：[目的]。現在のコード：[貼る]。制約：公開された挙動を保つ、変更量を最小にする、既存の流儀に従う、新しい依存を増やさない、各段階をテスト可能に保つ。返すもの：不変条件、依存関係の地図、段階、触るファイル、段階ごとのテスト、切り戻しのリスク、レビュー用チェックリスト。

ユニットテスト用プロンプト：

実装を変える前にテストを書いて。ここに示す既存のテストの書き方に合わせて：[貼る]。保つべき挙動：[貼る]。テスト対象のコード：[貼る]。テスト名、準備、入力、期待する結果、そして各テストが重要な理由を返して。正常系、境界ケース、エラーケース、回帰ケースを含めて。

プロンプトのテンプレート

良いコーディング用プロンプトが長いのは、飾り立てているからではありません。あいまいさを取り除くのに必要なだけ長いのです。モデルには、役割、タスク、背景情報、制約、出力形式、検証の基準が要ります。うまくいったプロンプトは保存しましょう。そうすればAIは、一度きりの雑談ではなく、繰り返せるエンジニアリングのワークフローになります。

コード解説用プロンプト：

このコードを、プロジェクトに新しく入る開発者向けに説明して。目的、入力、出力、データの流れ、依存関係、壊れ方、信頼度を上げるためのテストを扱って。コードから読み取れる事実と、あなたの推測を分けて。コード：[貼る]。

セキュアコーディング用プロンプト：

このコードをセキュリティのリスクの観点でレビューして。認証、権限、インジェクション、秘密情報、入力の検証、危険なリダイレクト、ファイルの扱い、依存関係のリスク、機微なデータの露出に集中して。返すのは問題だけにして、証拠、影響、提案する修正、テストまたは手動での確認方法を添えて。コードまたは差分：[貼る]。

モデル比較用プロンプト：

コーディングのタスクでAIモデルを比べています。提供した背景情報だけを使って。根本原因、最小で安全な修正、テスト、リスク、前提、質問を返して。自信度を1から5で評価し、あなたの答えを変えうる証拠を挙げて。タスク：[貼る]。背景情報：[貼る]。

AIが生成したコードを受け入れる前の品質チェック：

• モデルがタスクを正しく言い直している。
• パッチが問題より大きくなく、小さい。
• 公開された挙動とインターフェースが明示されている。
• テストがバグやリファクタリングの目的を直接カバーしている。
• 境界ケースと失敗の経路が挙げられている。
• セキュリティに関わる入力がレビューされている。
• 差分がプロジェクトの既存の流儀に従っている。
• 該当するテスト、リント、ビルド、手動での再現を自分で実行した。
• 最終的な差分を人間がレビューした。

タスクを変えずに修正だけを比べたいとき、Whiziが役立ちます。同じデバッグ用またはレビュー用のプロンプトを複数のモデルに貼り付け、証拠、範囲、テスト、リスクで出力を採点しましょう。モデル選びのガイドが欲しいならコーディング向けChatGPTの代替から始め、料金でプランを比べ、自分のコードでこのワークフローを走らせるならアカウントを作成しましょう。