AIコーディングを安全に進めるには、コード生成後の「差分を見る」「テストする」「人間が承認する」を工程として前もって決めます。AIは実装を早く書けますが、壊れる・漏らす・取り返しがつかない変更の最終判断は人間が担います。安全なソフトウェア開発の実践は NIST の SSDF でも整理されています[1]。

結論：生成後の差分・テスト・承認を工程化する

「コードを書いて」と頼むだけでは、AIの出力がそのまま本番に近い状態になる危険があります。生成のあとに、人間が差分を読み、テストし、承認する流れを組み込みます。

AIへコードを頼む前に決めること

  • 目的（何を達成するか）
  • 対象範囲（どのファイル・機能に触るか）
  • 条件（禁止事項・出力の形）
  • 完了条件（動作・要件の基準）

安全な10工程

  1. 目的を決める（HUMAN）
  2. 条件を書く（SHARED）
  3. 対象範囲を決める（HUMAN）
  4. コードを生成する（AI）
  5. 差分を見る（HUMAN）
  6. テストする（HUMAN）
  7. 危険な変更がないか確認する（HUMAN）
  8. 最終承認する（HUMAN）
  9. 保存する（SHARED）
  10. 作業ログを残す（SHARED）

対象範囲を限定する

影響範囲を小さく保つことで、差分レビューの負荷を減らします。「全体を直す」より「この関数だけ」のように境界を決めます。

変更差分を見る

AIが変えた箇所を人間が目で追います。意図しないファイルへの変更や、余計な削除がないかを確認します。OWASPは、不安全な出力処理やインジェクションをWebアプリの重大リスクに挙げています[2]。

秘密情報と設定ファイル

APIキーや認証情報をコードに埋め込まないよう確認します。設定ファイルの変更は本番挙動に直結するため、人間が見ます。CISAも、AIシステムの導入・運用時にデータと秘密情報の安全を優先事項に挙げています[3]。

依存関係（dependencies）

AIが新しいライブラリを追加する提案をしたら、その出所と更新状況を確認します。サプライチェーン経由の脆弱性は OWASP の LLM Top 10 でも取り上げられています[4]。未知のパッケージや突然のメジャーアップデートは人間が承認します。

migrations（スキーマ変更）

DBスキーマや設定の変更は、データの整合性に直結します。本番適用前に、ロールバック手順（元に戻す方法）が書けているかを確認します。

権限・認証

AIが認証や権限周りのコードを変えた場合、意図しない公開や権限昇格がないかを重点的に見ます。アクセス制御の不備は OWASP Web Top 10 の上位リスクです[2]。

diff review / typecheck / lint / unit / E2E

確認手段を層に分けます。

  • diff review：人間が変更箇所を読む（意図・余計な削除）
  • typecheck / lint：機械的に検出できる誤りを自動で弾く
  • unit：個別関数の期待動作
  • E2E：画面やAPIを通した全体の動作

GitHubの公式ドキュメントでも、AIによるコードレビューをプルリクエストのプロセスに組み込む方法が示されています[5]。ただし最終承認は人間が持ちます。

破壊的変更（destructive operations）

データの削除・スキーマ変更・公開範囲の変更は取り返しがつかないことがあります。これらは最終承認の前に明示的に確認します。

rollback（巻き戻し）

本番反映後に問題が出たときの戻し方を、反映前に決めておきます。戻し方がない変更は、承認のハードルを上げます。

本番反映前の承認（release approval）

公開・デプロイの直前に人間の承認を置きます。AGENT WORKBENCHでは「最終承認する」カードがこの役割です。

作業ログとcommit

いつ・何を変えたかを記録します。後から「なぜこうなったか」が分かるように、AIが下書きを人間が承認して残します。

悪い依頼と改善依頼

悪い例：「このリポジトリを最新技術に全部書き直して」

改善例：「ログイン処理のエラーメッセージを分かりやすくする。対象は auth/login.js のみ。既存の挙動を壊さないこと」

小規模修正の例

  1. 目的を決める（HUMAN）
  2. コードを生成する（AI）
  3. 差分を見る（HUMAN）
  4. テストする（HUMAN）
  5. 最終承認する（HUMAN）

大規模改修の例

  1. 目的・条件・範囲を決める（HUMAN/SHARED）
  2. コードを生成する（AI）
  3. 差分を見る（HUMAN）
  4. テストする（HUMAN）
  5. 危険な変更がないか確認する（HUMAN）
  6. 最終承認する（HUMAN）
  7. 保存・ログ（SHARED）

チェックリスト

  • 対象範囲が決まっている
  • 秘密情報をコードに埋めていない
  • 差分を人間が読んだ
  • テストを実行した
  • 破壊的変更を確認した
  • 本番反映前に承認した

FAQ

AIコーディングツールはどれを使えばいいですか？
特定の製品を推奨するものではありません。どのツールでも「生成後の差分・テスト・承認」の流れを設計すれば効果があります[5]。
自動テストがない場合は？
人間が手で動かして確認します。UIやエッジケースは自動だけでは足りません。
AI/HUMAN/SHAREDは公的基準？
いいえ。AGENT WORKBENCH独自の実務モデルです。公的文書は安全な開発と人間の確認を求めます[1][6]。
依存関係の追加をAIが提案したら？
出所と更新状況を人間が確認し、未知のパッケージは承認しません。
本番反映後にバグが出たら？
反映前に決めておいた rollback 手順で戻します。戻し方がない変更は承認のハードルを上げます。

AIコーディング用プリセットを開く

AIコーディング用テンプレートをツールで開く

参考資料

最終確認日：2026-07-13