生成AIによるコーディング支援は、便利さと同時に「誰が責任を負うのか」「ライセンス適合をどう担保するのか」という実務課題を伴います。Linuxカーネルはこの点を運用ルールとして明文化し、AI支援を条件付きで容認しつつ、最終責任は人間が負う方針を示しました。
“AIで書いたコード”の責任主体は誰か
Linuxの方針が明確にしたポイントは、AIはあくまでツールであり、DCO（Developer Certificate of Origin）を法的に担保できるのは人間だけという前提です。提出者は、AIが生成・提案したコードであっても内容をレビューし、ライセンス要件を確認したうえで、自らSigned-off-byを付けて責任を引き受ける必要があります。
日本企業の開発ガバナンスに置き換えると、次の3点が核になります。
- レビュー責任：AI提案を「理解して承認した」人が責任主体になる
- 署名責任：コミット/変更の承認者が、後から説明できる形で責任を負う
- ライセンス責任：生成物が自社の配布形態・契約条件・OSS方針に適合することを担保する
“禁止”より「手順化」：社内規程に落とすチェック項目
Linuxが採ったのは、AI利用の全面禁止ではなく、人間の責任と透明性をプロセスに埋め込むアプローチです。AI関与がある場合は、コミット（またはパッチ）にAssisted-byタグを付けて、どのツールが関与したかを明示するルールを示しています。
企業が社内規程に落とすなら、例えば次のような“チェック項目化”が現実的です。
1) 利用可否の範囲（ユースケース別）
- 仕様策定、テスト、リファクタ、翻訳など「影響範囲が限定される用途」は可
- セキュリティ境界・暗号・認証・課金・安全制御など「高リスク領域」は追加レビュー必須（または利用制限）
2) レビューの深さ（AI関与の有無で変える）
- AI関与あり：レビュー担当が「理解した」ことを記録（レビューコメント、承認理由）
- 重要変更は二重レビュー（コードオーナー＋セキュリティ/法務）
3) ライセンス適合（OSS/契約）
- SPDXの付与・更新ルール、依存ライブラリのライセンス確認
- 生成物が自社の配布（SaaS/オンプレ/組込）と整合するかをチェック
※Linux側でもライセンス整合やSPDX等の要件を前提としており、責任は人間に置かれています。
4) 透明性（開示とトレーサビリティ）
- 「AI関与を示すタグ」または同等の記録（例：コミットメッセージ、PRテンプレ）
- どのツールを使ったか（最低限の再現性確保）
監査・ライセンス・責任を“後追い”にしない運用体制
AI支援の普及で重要になるのは、問題発生時に「誰が何を根拠に承認したか」を追えることです。LinuxがAssisted-byで関与を可視化するのは、のちの分析や責任所在の明確化に資するためです。
企業側の運用体制としては、次の整備が効きます。
- 監査ログ：AI関与の有無、レビュー承認、ライセンス確認、変更理由を記録
- 変更管理：重要モジュールは承認者・証跡・ロールバック手順をセット化
- インシデント対応：権利侵害疑義やセキュリティ不備が出た場合の切り分け・修正・開示フロー
まとめ
Linuxが示したルールの要点は、「AIは使ってよいが、責任は人間が負う」「AI関与はAssisted-byで可視化し、レビュー・署名・ライセンス適合を運用で担保する」という整理です。
日本企業が開発ガバナンスに活かすなら、全面禁止ではなく、**①責任主体の明確化（レビュー/署名）②ライセンス適合の手順化（SPDX/OSS方針）③AI関与の記録（監査ログ）**をセットで規程化することが、現実的な“実務スタンダード”になり得ます。
