---
title: "責任を引き受けるプログラミング：提出した人が責任を負う"
author: "Shawn Jiang"
lang: ja
date: 2026-09-16
canonical: https://tplog.dev/ja/essay/due-diligence-programming/
translations:
  en: https://tplog.dev/en/essay/due-diligence-programming/
  zh: https://tplog.dev/zh/essay/due-diligence-programming/
---

# 責任を引き受けるプログラミング：提出した人が責任を負う

AIはコードを書くコストを下げた。しかし、そのコードに責任を持つコストまでは下げていない。

「責任を引き受けるプログラミング」とは、提出した人が結果に責任を持つことだ。

AIが生成したコードであっても、提出者は結果に責任を負い、自分が引き受けるべきコストを他人へ押しつけない。

これは道徳的なスローガンではなく、責任の境界線である。

## mainに入るコードの責任は誰が負うのか

AI Codingについて語るとき、多くの人が注目するのは速さだ。より速く書き、より速く直し、より速く「動きそうな」状態へ持っていく。責任を引き受けるプログラミングが問うのは別のことだ。そのコードが共有のmainブランチに入ったあと、誰が責任を負うのか。

AIはコードを生成できる。修正もできる。チェックも実行できる。それでも、リポジトリに入り、他人へ影響し始めるのは、モデルとの対話記録ではなく、実際に動くコードだ。

だから、責任を引き受けるプログラミングは「もっと丁寧にPromptを書くこと」でも「AIの使用を減らすこと」でもない。決めるのは一つだけだ。コードを提出した人が、その結果に責任を持つ。責任をモデルへ外注することはできない。

## 反対するのは責任転嫁の自動化

「自分は生成するだけで、品質はツールの責任だ」という態度は現代的に聞こえるかもしれない。しかし実際には、自動化のプロセスの中へ責任を隠しているだけだ。

モデルはオンコールを担当しない。壊したインターフェースを修復することも、Reviewの場でその設計について代わりに説明することもない。そのコストは結局、下流へ流れる。Reviewする人、連携作業をする人、変更によって作業を止められた人が引き受けることになる。

責任を果たすとは、提出前に自分で一度確認し、下流へ流れるコストを食い止めることだ。完璧である必要はない。ただし、こう言えなければならない。このコードは自分で確認した。境界も理解している。問題が起きたら自分に言ってほしい、と。

## コードが安くなるほど、責任を持つ人は希少になる

コードが安くなると、人と人の成果の差はかえって広がるかもしれない。Promptの巧拙だけが差を生むわけではない。結果に責任を持つ人と、対話を終えることだけに責任を持つ人がいるからだ。

同じ一時間でも、ある人が渡すのは「それらしく見えるもの」であり、別の人が渡すのは「Reviewの場で説明できるもの」だ。前者はチームの協働に使える余力を消費し、後者はそれを節約する。

だから、これは個人の心がけだけの話ではない。協働の倫理であり、エンジニアリングの効率でもある。自分が先に引き受けなかった確認、判断、修正は、最後には誰かが補わなければならない。

## 自動化しても責任は消えない

自動化が成り立つのは、意図が明確で、実行経路を制約できる場合だ。自動化は成果を届ける助けにはなるが、責任まで取り除いてはくれない。

コードの九割をAIに書かせてもよい。すべてを書かせてもよい。それでも、そのコードが共有空間に入り、他人へ影響しうる限り、提出者の責任は消えない。すべてを自動生成しても、誰も責任を負わなくてよいことにはならない。

そうでなければ、手に入るのは完全な自動化ではない。判断の負債と事故の負債をチームへ残す、半自動の生産ラインだ。

提出した人が責任を負う。他人に対する責任を持ち、自分のコストを押しつけない。

AIはペンにも、手にも、チェック役にもなれる。しかし、身代わりにはできない。

対話を終えることより、仕事を成し遂げることのほうが、昔からずっと希少だった。そして「成し遂げる」には、今風ではない一つの行為も含まれる。結果に自分の名前を添えることだ。