AIでコードを書く前に、人が確認する6項目

結論：AIコーディングは6項目を確認してから公開する

AIコーディングを業務へ導入する時は、生成速度ではなく、公開してよい条件を先に決めます。最低限確認するのは、変更範囲、テスト、権限、秘密情報、レビュー担当、復旧方法の6項目です。6項目のどれかが空欄なら、コードを捨てる必要はありません。公開待ちとして人へ戻し、何が足りないかを記録します。

AIは既存コードの読み取り、定型処理、テストのたたき台を速くできます。しかし、顧客データへ触れてよいか、料金計算を変えてよいか、障害時に誰が戻すかは、コードの自然さだけでは確定できません。AIを開発者の代わりにするのではなく、差分を作る担当と、業務上の責任を確認する担当を分けることが出発点です。

AIで書けることと、会社が決めることは違う

AIコーディングの導入で最初に起きやすい誤解は、コードを生成できるなら、そのまま実行や公開まで任せられるというものです。実際には、生成は一工程にすぎません。変更の目的を決め、既存の正本を参照し、差分を確認し、テストし、承認し、公開後に戻せる状態を残す必要があります。

たとえば「問い合わせフォームの入力欄を追加する」という依頼でも、表示だけの変更なのか、CRMへ保存する項目なのか、個人情報を外部サービスへ送る処理まで含むのかで確認の重さは変わります。AIエージェント導入前の業務フロー図のように、入力、AIの処理、人の確認、停止後の戻し先を一枚にすると、開発作業と業務判断の境界が見えます。

工程	AIが支援しやすいこと	人が確定すること
理解	既存コードの要約、候補の抽出	参照する正本、変更の目的
実装	定型コード、テスト案、差分案	任せる範囲、入力してよい情報
公開	チェック結果の整理	承認者、公開時刻、停止・復旧

この分担はAIを疑うためだけのものではありません。人が毎回コード全体を読み直すのではなく、影響の大きい箇所へ確認を集中するための設計です。人へ戻す条件とAIの承認フロー表を先に置けば、担当者が一人で責任を抱えにくくなります。

公開前に確認する6項目

1. 変更範囲：どのファイル、画面、データ、利用者に影響するかを書きます。差分が広がっている場合は、目的ごとに分割します。
2. テスト：通常ケースだけでなく、空欄、権限不足、重複、外部サービス停止などの境界ケースを確認します。テストがないなら、ないこと自体を記録します。
3. 権限：認証、決済、顧客データ、公開設定へ触れる変更かを見ます。実装者がそのまま公開できる権限とは限りません。
4. 秘密情報：APIキー、個人情報、顧客の契約条件、社内限定のログをAIへ送っていないか確認します。入力前の4段階は送ってよい情報の判断に分けておくと運用しやすくなります。
5. レビュー担当：コードを読める人だけでなく、変更される業務を知る人を含めます。料金、問い合わせ、顧客情報の変更は業務責任者の確認が必要です。
6. 復旧方法：公開後に問題が出た時の停止操作、戻すコミット、連絡先、判断者を残します。復旧できない変更は、最初から小さく切り直します。

6項目は、すべてを同じ深さで確認するためのチェックではありません。画面の文言変更なら変更範囲と表示確認を中心にし、顧客データの保存なら権限、秘密情報、復旧を厚くします。AI導入の失敗を防ぐ確認でも、業務の影響度に応じて任せる・保留・停止を分ける考え方を扱っています。

通常・境界・停止の3段階に分ける

「人がレビューする」だけでは、現場は毎回どこまで見ればよいか迷います。そこで、変更を3段階に分けます。通常は担当者が差分とテストを確認し、境界は業務責任者を追加し、停止は公開せずにセキュリティや契約の確認へ戻します。

区分	例	公開条件	戻し先
通常	表示文言、社内だけの定型処理	差分、テスト、担当者を確認	開発担当
境界	問い合わせ分類、CRM項目、通知先	業務担当と開発担当が確認	業務責任者
停止	認証、決済、顧客データ、外部公開	公開前に専門担当・責任者が承認	情報管理・経営判断

この3段階は、AIを使うなという禁止表ではありません。安全に試せる範囲を小さく定義し、境界を越える時だけ確認者を増やします。導入初期は、通常変更を一件選び、境界変更を模擬し、停止条件を文章にする順番が現実的です。

実務手順：一つの差分を公開可能な記録へ変える

1. 依頼文を「何を変え、何を変えないか」の一文へ直す。
2. AIへ渡した情報と、参照したREADME・仕様・テストを記録する。
3. 差分をファイル単位で読み、目的にない変更を外す。
4. 通常・境界・停止の区分を付け、必要な確認者を決める。
5. テスト結果と未確認のケースを残し、空欄を完了扱いにしない。
6. 公開日時、担当者、復旧先、公開後に見る指標を記録する。

記録は長い日報でなくて構いません。たとえば「問い合わせ分類の候補を作成。顧客名は入力していない。CRM保存は未実施。境界ケース3件は人が確認。公開後は誤分類と手修正を確認。問題時は前コミットへ戻す」と残します。小さな会社のAI活用ログのように、使ったことだけでなく、使わなかった範囲と戻した理由も次の担当者へ渡します。

チェックリスト：公開ボタンの前に空欄を探す

• 変更の目的と対象外の範囲が一文で説明できる
• 差分に目的外のファイルや権限変更がない
• 通常、境界、停止の区分が付いている
• 通常ケースと境界ケースのテスト結果がある
• AIへ送った情報に秘密情報や不要な顧客情報がない
• コード担当と業務責任者の確認範囲が分かれている
• 公開前に承認が必要な条件が決まっている
• 問題時の停止操作、戻す場所、連絡先が書かれている
• 公開後に見る指標と次回レビュー日がある

チェック欄が埋まらない時は、担当者の努力不足ではなく、業務設計の不足かもしれません。参照する正本がない、テスト用データがない、復旧権限が決まっていないといった問題は、コードの修正だけでは解決しません。空欄を判断ログへ残し、README、テスト、権限表、承認ルールのどこへ戻すかを決めます。

よくある質問

AIにコードを書かせたら、すぐ本番へ反映してよいですか？

すぐに反映せず、変更範囲、テスト、権限、秘密情報、レビュー担当、復旧方法を確認します。顧客データ、決済、認証に関わる変更は責任者の承認へ戻してください。

AIコーディングで最初に確認することは何ですか？

何を変え、何を変えないかという変更範囲です。差分が読めない、テスト対象がない、参照した正本が不明な場合は、実装を続けずに確認待ちにします。

小さな会社でもコードレビューのルールは必要ですか？

必要です。ただし全変更を重い承認にせず、通常、境界、停止の3段階に分けます。確認者が一人しかいない場合は、停止条件と復旧先を先に決め、責任を曖昧にしないことが重要です。

AIが作ったコードの品質をどう改善しますか？

誤りを直すだけでなく、変更理由、テスト、確認者、例外、復旧先をログへ残します。同じ迷いが続くなら、AIのプロンプトだけでなくREADME、入力欄、テスト、承認ルールを直します。

検索意図に対する次の一歩：安全な一件から始める

AIコーディングの導入を検討しているなら、いきなり本番の重要機能を任せる必要はありません。まずは社内向けの表示変更やテスト追加など、戻しやすい一件を選び、6項目を埋めます。次に、問い合わせやCRMの境界変更で確認者を増やし、認証・決済・顧客データは停止条件として別管理します。

どこまでAIへ任せるか、誰がレビューするか、問題時にどこへ戻すかが決まらない場合は、Miraigentの無料診断で一つの業務から整理できます。導入の進め方はサービスページ、関連する実務テンプレートはリソース一覧をご覧ください。AIコーディングを速さだけで評価せず、人が確認できる運用へ変えることが、継続して使うための最初の条件です。