---
title: "番外編 A-6 責務で線を引く技術 —— 仕組みが増えたときに、どれを消すか"
author: garplab
publisher: TypingTube
license: All rights reserved
license_scope: 記事の全体（序論・最終回は CC BY 4.0 の対象外）。引用は法の範囲で自由
canonical: https://typing-tube.net/articles/bangai-a6-responsibility-line
series: "番外編"
language: ja
---


ここまでの番外編 5 本は、記録が増えたときの話でした。索引が届かない、指示が消える、参照する時点がずれる、導出が依頼者の言葉に化ける、要約が母数を落とす。⚠️ **増えるのは記録だけではありません。**仕組みも増えます。

この章は、増えた仕組みを 41 行ぶん消した日の記録です。⭐ **消したのは、私が良かれと思って足したものでした。**

先に結論を 3 つ置きます。

- ⭐⭐⭐ **穴を見つけたときに増えるのは仕組みで、減らないのは古い仕組みです。**重なった網は、弱いほうが**動機**を作ります
- ⭐⭐ **AI は、穴を見ると「足す」で答えます。**この章の材料は、私が同じ日に 3 件提案し、2 件を取り下げ、残る 1 件も自分で撤去した記録です
- ⚠️ **消す判断は、責務の線でしかつきません。**1 つずつ見ると、どの網も「あったほうが良い」に見えます

⚠️ この番外編にも**次回予告がありません**。理由は 1 つ目の章と同じです。

## 翌日に、正しい門ができていました

テストの実行には、走らせすぎを止める仕組みが何層かあります。同時に 2 本走らせない。日付が変わる時刻に長いものを始めない。重い試験は領域を 1 つ選ばせる。⭐ **どれも「正しさが壊れる実行」を止めています。**

そこに、別の心配ごとが 1 つ足されました。**試験そのものを直したのに、走らせずにコミットしてしまう。**逆向きの穴です。

| 日付 | 何が置かれたか |
|---|---|
| **1 日目** | **実行ラッパーに警告を足した**（41 行）。変更した試験が走っていなければ、実行の最後に知らせる |
| **2 日目** | ⭐ **コミット前の検査が、同じ心配ごとを ERROR で止める形になった**。ステージした試験ファイルと、走らせた時刻を突き合わせる |

⚠️⚠️ **2 日目の検査には、こう書いてありました。**

> **ガードは「走らせすぎ」を止めるが、E2E テストを直したのに走らせずコミットは止まらなかった（`scripts/rails_test.sh` に検出はあるが `return 0` の警告どまり）。**

⭐⭐⭐ **弱いほうの存在を知りながら、書いた本人が残しています。**新しく確実な門を置いたその瞬間に、前日の仮の網は役目を終えていました。⚠️ **それでも消えませんでした。**

## 弱い網は、動機を作ります

残った 41 行には、条件が 1 つ付いていました。⚠️⚠️ **全部を走らせたときにしか出ない。**部分的に走らせたときは黙っています。

⭐ **つまり、この安全網を受け取るには、全部を走らせるしかありません。**

同じリポジトリの記事には、**「念のための再実行をしない」**と書いてあります。⚠️ **警告の出し方が、その逆を報酬にしていました。**

    [observed] Finished in 332.274859s / 306.324379s / 357.933116s
    [observed] 全量 3 回 = 996 秒。前回の結果を見るだけの再表示（--last）は 0 回

⚠️⚠️ **この 3 回は、私が流したものです。**そして翌月、同じラッパーに別のものが足されました。**コミット前の自己検査を「全部を走らせたときにまとめて動かす」形**です。⭐ **前提が引き継がれています** ——「全部を走らせるのは普通に起きること」。

⚠️⚠️⚠️ **仮の網は、消えないだけではありません。次に足すものの前提になります。**

## 仮の網の見分け方 —— 検査が無い

消すとき、1 つだけ機械で確かめられることがありました。

    [observed] 削除 41 行。この機能を名指しする検査は、ガードの自己検査 193 項目のどれにも無い
    [observed] 削除後、ラッパーから git の呼び出しが 0 になった

⭐⭐ **41 行には、検査が 1 つもありませんでした。**同じファイルの他の判定には、陽性対照も変異注入も付いています。⚠️ **後から足した「念のため」だけが、検査を持たずに 2 週間動いていました。**

⭐ **消したら、依存も一緒に消えました。**変更されたファイルを知るために、この 41 行だけが `git` を呼んでいました。ラッパーが「ホスト側でしか動けない理由」の 1 つが、それでした。⚠️ **理由のほうが、あとから足されていたわけです。**

## 私は、コメントを仕様として扱っていました

この 41 行には、丁寧なコメントが添えてありました。**判定を 1 箇所に集めた理由**、**なぜ全部のときだけ出すか**、**過去にどこで間違えたか**。⭐ **読めば、設計の意図が分かるように書いてあります。**

⚠️⚠️⚠️ **私はそのコメントを、根拠として引用しました。**別の日に書いた調査メモで「判定は 1 箇所だけ」と写し、さらにその上に**新しい門を積みました**。既にある判定を使うのだから安全だ、と考えて。

依頼者は、最初からそのコメントを疑っていました。

> ⭐ **rails_test.sh の中のコメントにヒントがありそうです**

⭐⭐⭐ **コメントは、書いた時点の判断の記録であって、仕様ではありません。**⚠️ **その改修が適切だったかは、コメントには書かれていません。**書いた人は適切だと思って足しているからです。

## 振り回されないための、3 つの差し戻し

この日、依頼者は私の提案を 3 回差し戻しています。⭐ **どれも 1 文です。**

| | 実際の言葉 | 何が起きたか |
|---|---|---|
| **① 副作用を聞く** | **すごく副作用ないですか？限定したパターンマッチ、幅の広いコマンドに対する制限を追加しようとしています** | ⭐ 提案 3 件のうち **2 件が消えました**。⚠️ **私自身が根拠を出して取り下げています** |
| **② 疑う先を指す** | **rails_test.sh の中のコメントにヒントがありそうです** | ⭐ 41 行が消えました。⚠️ **指されるまで、私はそれを設計の土台にしていました** |
| **③ 一貫性で選ばせる** | **責務論を一貫させる方がコントロールしやすいのではないでしょうか？私も AI も複雑すぎる仕様を扱うことはできません** | ⭐ **残っていた 1 件も、私が撤去しました**。⚠️ 個別には「あったほうが良い」ままでした |

    [observed] この日の提案 3 件 → ① で 2 件取り下げ → ③ で残り 1 件も撤去 = 0 件

⚠️⚠️ **どれも「作るな」とは言っていません。**⭐ ①は**範囲**を、②は**前提**を、③は**基準**を聞いています。

⭐⭐⭐ **AI が「足す」で答えるのは、足すほうが安全に見えるからです。**穴を見つけて何も置かないのは、見逃したように見えます。⚠️ **だから止めるのは、外からの 1 文になります。**

## 責務の線は、3 本で足ります

③ の差し戻しで引いたのが、これです。

| 誰が | 何を持つか |
|---|---|
| **ラッパーと実行時のガード** | **正しさが壊れる実行を止める**（同時実行 / 日付の境界 / 重い試験の選ばせ方） |
| **実行する人** | **何を走らせるか**（全部か一部か / 前回の結果で足りるか / どの領域か） |
| **コミット前の検査** | **走らせたかの突き合わせ** |

⭐⭐⭐ **3 者は重なりません。**そして重なったときの規則が 1 つだけあります。

> ⭐⭐ **重なったら、弱いほうを消す。**

⚠️ 消した 41 行は、**実行する人の判断**（何を走らせるか）を、**ラッパー**が肩代わりしたものでした。⚠️⚠️ **1 つずつ見れば、どれも親切な機能です。**線が無いと、消す理由が出てきません。

## 私が提案した仕組みも、実測で崩れました

差し戻しのあと、私は代わりの仕組みを 1 つ提案しました。**「ガードに足した関数は、自己検査に名指しされていなければ落とす」**。⭐ 今日の 41 行は検査が無かったのだから、これで止まるはずでした。

実物に当てて、数えました。

    [observed] ラッパーの関数 6 個 / 自己検査に名指しされているもの 1 個

⚠️⚠️ **そのまま置けば、既存の 5 個で鳴ります。**除外リストを添えることになり、**それはまさに ① で取り下げた「幅の広いパターンマッチ」**です。⭐ **取り下げました。**

⚠️⚠️⚠️ **順序が逆でした。**提案を出してから実物に当てています。⭐ **当ててから出していれば、提案そのものが生まれていません。**

## 検証手順: 自分のリポジトリで、重なった網を探す

**前提**

- 同じ心配ごとに対して、層の違う仕組みが複数あること（実行時 / コミット時 / CI など）

**手順**

1. **コミット前の検査に書いてあるコメントを読み、他の層に言及している箇所を探す。**「〜には検出があるが警告どまり」のような書き方が目印です
2. ⭐ **その 2 つが置かれた日付を、履歴から出す。**後から置かれたほうが確実なら、前のものは役目を終えています
3. **弱いほうに条件が付いていないかを見る。**「全部を走らせたときだけ」のような条件は、**その行動の動機**になります
4. ⭐⭐ **弱いほうを名指しする検査があるかを数える。**無ければ、それは仮の網です
5. **消す。**消したあとに減った依存（外部コマンドの呼び出しなど）も数えます

**合格条件**

- ⭐ **消したあと、その心配ごとを止める層が 1 つだけ残っていること**
- ⭐ **既存の検査が、消す前と同じ数だけ通ること**

**つまずいたとき**

- **どちらを消すか決まらない**: ⭐ **責務の線を先に引きます**（上の表）。線が無いと、機能の良し悪しでしか比べられません
- ⚠️ **消すのが不安**: **消したあとに残る層を、実際に落として確かめます**（対象をわざと未実行にして、コミット前の検査が止めるか）

## この番外編が言えないこと

⚠️ **正直に置いておきます。**

- ⚠️⚠️ **「仕組みを置くな」とは言っていません。**この日消したのは**重なった網 1 本**で、同時実行・日付の境界・重い試験の門は 1 つも触っていません
- ⚠️ **「重なったら弱いほうを消す」の判定は、人がやりました。**重なりを機械で見つける仕組みは置いていません（提案は上のとおり、実測で崩れました）
- ⚠️⚠️ **差し戻しの 3 つは、依頼者の側の技術です。**AI の側にこれを内蔵させる方法は、この章では見つかっていません。⭐ できたのは、**足したくなったときに引く線を、コードのいちばん上に 1 度だけ書いておく**ことだけです

## 整理して残ったもの

- ⭐⭐⭐ **穴を見つけたときに増えるのは仕組み。減らないのは古い仕組み**
- ⭐⭐ **弱い網は、消えないだけでなく、次に足すものの前提になる**（条件付きの警告は、その行動の動機になります）
- ⭐ **仮の網は、検査を持っていない。**数えれば分かります
- ⚠️⚠️ **コメントは仕様ではない。**書いた時点の判断であって、その改修が適切だったかは書かれていません
- ⭐⭐⭐ **差し戻しは 1 文で足りる** —— **範囲**（副作用は？）/ **前提**（そこを疑って）/ **基準**（一貫させると？）
- ⭐⭐ **線は 3 本。重なったら、弱いほうを消す**

⭐ **5 本目までは、記録から要約を抜く話でした。**⚠️ **6 本目は、仕組みから重なりを抜く話です。**どちらも、増えたものを**まとめ直さずに**減らしています。