AIコーディング支援は、個人の便利な道具として導入されやすい一方、チームでは生成コードの責任、秘密情報、レビュー量が問題になります。
ツール名より先に、何を入力し、どこまで変更させ、誰が確認するかを決めます。
最低限決める7項目
| 項目 | ルール例 |
|---|---|
| 入力データ | 個人情報、秘密鍵、顧客データを入力しない |
| 対象リポジトリ | 利用許可されたコードだけを扱う |
| 変更範囲 | 依頼に必要なファイルへ限定する |
| 危険な操作 | 削除、デプロイ、DB変更は人が承認する |
| 依存関係 | 新規パッケージは目的と保守状況を確認する |
| 検証 | lint、型、テスト、ビルドを実行する |
| 責任 | 採用した人がコードを説明できる状態にする |
生成コードを特別扱いしすぎない
AIが作ったコードにも、手書きコードと同じ品質基準を適用します。
- 仕様を満たすか
- 既存設計に合うか
- 失敗時の動作があるか
- 入力を検証しているか
- 権限境界を越えないか
- テストで重要な動きを確認できるか
「AIが出したから正しい」も「AIが出したから危険」も判断にはなりません。コードと実行結果を確認します。
差分を小さくする
一度に多くのファイルを書き換えさせると、人間のレビューが形だけになります。一つの目的ごとに変更を分け、なぜ必要かを説明します。
目的: 送信失敗時のメッセージを追加
変更範囲: ContactForm.tsx と既存テスト
変更しないもの: API仕様、依存関係、デザインシステム
確認: 400、500、通信失敗の表示
AIの出力を検証する担当を決める
生成した本人だけで確認すると、依頼時の思い込みをそのまま見落とします。認証、決済、個人情報、インフラなど影響の大きい領域は、知識のある別の人が確認します。
注意: AIへの入力は、組織の契約、データ保持設定、利用規約によって扱いが変わります。利用中のサービスと組織ルールを確認してください。
参考リソース
- CyberAgent Developers Blog:ビジネス職がClaude Codeを安全に使うための研修
- OWASP Top 10 for Large Language Model Applications