「AIが書いたコードだから」——責任主体が消えていく開発現場
2026.06.05執筆者：DigKnow株式会社 CTO 桑原 脩
先日、PRレビューで気になった実装について「ここ、なんでこうしたの?」と聞いたところ、「AIが書いたので、内部のロジックは把握できていないです」と返ってきました。悪気はありません。私自身、似たような答えを返したことがあります。マージされ、動いているこのコード——もし障害を起こしたとき、「これは私が責任を持っているコードです」と立てる人が、いま、このチームに何人いるのでしょうか。
障害が起きたとき、責任主体は誰になるのか
障害が起きたとき、組織として最初にやるべきことは、技術的な原因究明と、責任主体を立てることです。原因がわかっても、責任を引き受ける主体が組織内に立ち上がらなければ、顧客への説明も、再発防止策の決定も、規制当局への報告も、前に進みません。
責任主体には実は二つの層があります。組織として責任を引き受けるマネジメント層（顧客への説明、再発防止策のコミット、経営判断）と、コードに対する技術レベルの責任主体（コードの中身を説明し、原因を突き止め、修正にコミットする立場）です。
この二層は依存関係にあります。マネジメント層が顧客に対して「当社として責任を持って対応します」と立てるのは、現場に「このコードの中身は私が把握しています」と立つ技術レベルの主体がいるからこそです。後者がなければ、マネジメント層は「対応中です」以上のことが言えません。
従来は、技術レベルの責任主体は自動的に成立していました。Author欄に名前があり、本人が中身を把握している。主体は議論するまでもなく、自然に浮かび上がっていたのです。
AIコーディングが日常化した現場で起きているのは、この自動的な浮上の崩壊です。Author欄には人間の名前があります。でも、その人は「AIに書かせたので、中身は……」と言う。承認したレビュアーも「テストが通っていたから」と言う。誰一人として、嘘をついていません。
その結果、技術レベルの責任主体が、組織のどこにも明確に立ち上がらなくなります。書いた事実はあるけれど、理解の事実はない。承認の事実はあるけれど、読み解いた事実はない。そして技術レベルが空洞化した瞬間、それを依存先としていたマネジメント層の責任も連鎖的に空洞化します——コードは残るが、仕様は誰も知らないで書いた構造的問題が、AIコーディングによってさらに深く変質した姿です。私はこの状態を「責任主体不在」と呼んでいます。
法的責任は消えない、実務責任だけが消える
「責任主体が空洞化する」という言い方は、法的責任や契約的責任までもが消えるという意味ではありません。そこは何ひとつ変わっていないのです。
契約上の品質保証条項、SaaSのSLA、改正個人情報保護法やGDPRの説明責任、PL法上の製造物責任——これらは、コードを誰が書いたかに関係なく、組織に課されています。「AIが書いたので」は、これらの責任を法的にも契約的にも消すことはできません。顧客に「実装はAIに任せた範囲なので、当社としては……」と言える局面は存在しません。規制当局に「該当処理はLLMが生成したので、当社の説明範囲外です」と説明することも、できません。
起きているのは、責任そのものが消えることではなく、法的責任は組織に課され続けるのに、それを実体として引き受ける現場の主体だけが空洞化している、という非対称です。マネジメント層は責任を負わざるを得ない。でも、その責任を技術的に支える層が組織内に立ち上がらない——マネージャーは責任を取らなければならないのに、説明材料を組織内部から調達できないのです。
この非対称が放置されると、インシデント時の対応速度と説明の質が落ち、組織は顧客と取引先からの信頼を静かに削られていきます。法的責任は重く課されたまま、それを履行する実体だけが消えていく——これは想定されているよりはるかに大きなリスクとして、現場のあちこちで進行していると感じています。
実装は委ねられるが、責任は委ねられない
「責任を引き受ける」というのは、能動的な行為です。コードに目を通し、中で何が起きているかを理解し、リスクの輪郭を把握したうえで「これで進めます」と判断する——この一連の能動性があって初めて、責任主体が成立します。「目の前にあったから採用しただけ」では、責任を引き受けたことにはなりません。
AIは、この能動性を持ちません。確率的にもっともらしいコードを生成しますが、生成したコードに対して「私が責任を持ちます」と立つ主体ではないのです。実装は委ねられても、責任は委ねられない——これがAIコーディング時代の構造的な真実です。
結果として、実装をAIに任せれば任せるほど、責任の引き受け手はあくまで人間側に残ります。AIが実装の労力を肩代わりすることと、責任主体が消えることは、まったく別の話です。むしろ、AIが実装を加速させればさせるほど、人間側に残る「責任を引き受ける」役割の比重は、相対的に大きくなっていきます。AIが10倍速くコードを書けるなら、人間は同じ時間で10倍のコードを引き受けなければならないのです。
「AIに任せれば人間は楽になる」という議論が進むと、組織は気づかないうちに、責任主体が誰なのか誰も答えられない状態に陥ります。これは生産性向上の物語ではなく、責任主体喪失の物語です。
「理解の代替」という業界論の落とし穴
AIコーディングの議論で、最近よく聞くようになった主張があります。「AIが実装してくれるなら、人間はもうコードを理解する必要はない。仕様だけ伝えれば十分だ」というものです。生産性の文脈では魅力的に響きますが、これまで見てきた責任主体の構造に当てはめると、危うさが浮かび上がります。
人間がコードを理解しなくていい、という主張は、人間が責任を引き受ける主体性を放棄してもいい、という主張と同義だからです。理解していないコードに対して、責任は引き受けられません。引き受けたつもりでも、いざ説明を求められたときに何ひとつ語れないのであれば、それは責任主体として機能していません。
「理解の代替」は、表面的には人間の負荷を下げる方向に見えながら、実は組織から責任主体を消し去る方向に作用します。技術レベルの責任主体が消え、それを依存先としていたマネジメント層の責任も同時に空洞化する——「理解の代替」を選んだ組織の数年後の姿は、おそらくこれです。
私自身、AIに実装を委ねる場面は増えており、Claude Codeに任せる範囲も広がっています。でも、生成されたコードを「読まない」選択肢は取れません。読まずに採用すれば、責任主体として立てなくなるからです。これは効率の問題ではなく、職業倫理に近い感覚です。AIが何を出しても、最終的に採用し、責任を引き受けるのは私である——この一点だけは、生産性のためにも譲ってはいけない線だと考えています。
責任主体を残すための「理解の加速」
組織が選ぶべき方向は、「理解の代替」ではなく「理解の加速」です。
理解の代替は、コードを理解する行為そのものを省略する考え方です。理解の加速は、理解できる状態を保ったまま、その到達速度を上げる考え方です。前者は責任主体を消し去る方向に、後者は温存する方向に作用します。
理解を加速するために必要なのは、設計判断の理由や内部ロジックの要点を、人間が短時間で辿れる形で残しておくことです。設計の意図、選んだ実装パターン、検討した代替案、経由する中間処理——これらが言語化されて残っていれば、人間は短時間で理解の状態に到達できます。「読まなくていい」ではなく「短時間で読み解ける」を目指す方向です。
これは新人の立ち上がりや引き継ぎの話だけではありません。障害が起きたときに責任主体として立てる人間を、組織が用意できるかどうかの話です。理解を加速する仕組みがあるチームでは、責任を引き受けるコストが下がり、技術レベルの責任主体は自然に立ち上がり、マネジメント層の責任も支えられます。
「書かなくても残る仕組み」は、この理解の加速を支える基盤に位置づけられます。コードが書かれた瞬間に、設計判断と内部ロジックの言語化が並走する仕組み——それが組織にあれば、責任主体は自然に保たれます。
まとめ
「AIが書いたコードだから」の背後には、責任主体が組織から消えていく構造があります。法的責任は消えないのに、技術レベルで支える主体が現場に立ち上がらない——AIコーディング時代の新しい状態です。実装は委ねられても、責任は委ねられません。「人間はもう理解しなくていい」という業界論は、責任主体喪失への直行便です。選ぶべきは「理解の代替」ではなく「理解の加速」。責任を引き受けられる人間を残し続けることが、生産性と引き換えに失ってはいけない一線です。
明日、システムに障害が起きたとき、「このコードの中身は私が把握しています」と立てる人と、それを支えに「当社が責任を持って対応します」と顧客に言える人——あなたのチームには、どちらも揃っているでしょうか。
次回は、ドキュメントのないシステムの維持コストを、数字で冷静に見積もってみるつもりです。感覚的に「負債だ」と感じていたものが、実際にはいくらの請求書になって返ってくるのか——その輪郭を描きます。