275 tests passedでもHuman Approvalを外さなかった

1. リード

自動化が安定してくると、次に外したくなるのは人の確認かもしれない。数字が揃い、朝の動作も整い、UI も見やすくなれば、最後の承認も機械に渡したくなる。だが 2026-07-26 時点の Current Context には、v1.1.0 で Human Approval の省略はやっていない と明記されている。さらに Governance の整理では、最終判断は人間が持つと固定されている。

PROJECT_RULES でも、公開・更新には Human Approval を要求し、Human Approval なしに公開・更新・削除しないと定めている。今回のテーマは、品質が上がったあとでも承認境界を外さなかったことが、運営を遅くする制約ではなく、責任の置き場を守る設計だったという話だ。

2. 背景

Current Context の現在地はかなり明快だ。v1.0.0 は正式リリース済み、v1.1.0 も正式リリース済み。その v1.1.0 で完了したこととして並んでいるのは、Dashboard UI 改善、9画面の最終 UI 受入、そして 275 tests passed。一方で、やっていないことの列には、新 Connector、DB / SQL / スキーマ変更、AI 要約・自動提案、新しい書き込み Action、そして Human Approval の省略がある。

この並びは重要だと思う。単に「まだやっていないこと」の一覧ではなく、便利にできそうでも境界は動かさなかったという意思表示になっているからだ。朝の判断を 60 秒以内にしやすくする改善は進める。それでも、最終的に押してよいか、公開してよいか、運用の責任をどう持つかは人間の位置に残している。

3. 今回のテーマ

テーマは、275 tests passed でも Human Approval を外さなかったことで、自動化の成功と本番判断を混同しないで済んだということだ。

テストが増え、UI が整い、毎朝の見え方が改善すると、「もう十分ではないか」と感じやすい。だがテストが通ることと、その結果をもとに本番判断を委ねてよいことは別だと思う。Current Context と PROJECT_RULES は、その別物感をかなり意識して残している。

4. 実際の出来事

Current Context の Governance と役割分担では、ChatGPT は設計・レビュー、Cursor は実装、GitHub は正本、最終判断は人間と整理されている。Qiita 作業も OS 本体と分離した独立プロジェクトで進める。ここで人間に残されているのは、単なる最終ボタンではない。どこで止めるかを持つ役割だ。

同じ Current Context の v1.1.0 では、改善対象がかなり慎重に絞られている。毎朝 60 秒以内に「正常 / 注意 / 要対応」を判断しやすくする Dashboard UI 改善はやる。9画面の受入もする。275 tests passed も確認する。だがその一方で、新しい書き込み Action は増やさず、Human Approval も省略しない。つまり、見え方と品質確認は強くしても、本番操作の境界は別レイヤーとして固定した形になっている。

PROJECT_RULES でもこの線はぶれていない。公開前レビューでは OS 本体正本との整合確認を行い、投稿基盤の運用ルールでは公開・更新に Human Approval を要求する。さらに「最終判断、公開、更新は人間が承認します。Human Approval なしに公開・更新・削除しません」と明記されている。ここまで書かれていると、Human Approval は単なる慎重さではなく、運用設計の一部だと分かる。

この設計が効いているのは、テストや UI が強くなったあとだと思う。品質が弱い段階で人間が見るのは当然に見える。だが 275 tests passed と書ける段階でも、その境界を残しているところに意味がある。もしここで「数字が揃ったから承認も自動化してよい」と進めていたら、テストの成功と責任の移譲が同じ話になってしまう。

実際には、Current Context が示す v1.1.0 の非実施項目は、その混同を避ける並びになっている。AI 要約や自動提案を足さない。新しい書き込み Action も作らない。Human Approval も外さない。つまり 判断を速くする工夫はするが、判断主体はずらさない。この切り分けがあるから、Dashboard 改善はあくまで見え方の改善として読めるし、運用責任の所在も動かない。

Qiita 運用のルールも同じ方向だ。このプロジェクトでは、二重投稿防止、投稿前確認、公開状態の記録、Token の非保存などが強く求められている。記事を書くことと公開することは近い作業に見えるが、実際には責任の重さが違う。Human Approval を残すと、その差を毎回確認できる。

さらに効いているのは、Current Context が v1.1.0 の範囲をはっきり制限していることだ。完了したのは Dashboard UI 改善、9画面の最終受入、275 tests passed までで、新 Connector や新しい書き込み Action はやっていない。改善対象を広げず、承認境界も動かさなかったから、どこまでを自動化の成果として語り、どこからを人の責任として残すかが崩れにくい。

PROJECT_RULES の公開前レビューでも、確認済み正本と一致しない情報は書かない、事実が曖昧なら本文へ入れない、Human Approval なしに公開しない、という線が重ねて置かれている。つまり承認は「最後に気分で押すボタン」ではなく、設計・実装・記事化のどこでも境界として機能している。テストの数字が大きくなっても、この境界まで自動化の勢いで飲み込まなかったところが重要だった。

5. 考えたこと

非エンジニアの立場では、ここはかなり大きい。テスト数が増えると安心する。UI が見やすくなると、さらに安心する。だがその安心を、そのまま「もう人は見なくてよい」に変えると、安心の種類を取り違えやすい。テストが保証しているのは、定義した条件に対して壊れていないことだ。だが「今日この状態で公開してよいか」「この操作を本番へ流してよいか」は、別の判断を含む。

Human Approval を残すことは、AI や自動化を信用しないことではないと思う。むしろ逆で、何を信用しているかを正確に分けることだ。テストは品質確認として信用する。Dashboard は状況把握として信用する。GitHub は正本として信用する。そのうえで、公開や更新の最終判断は人間が持つ。この分け方があると、どこかで違和感が出たときにも、何を見直せばよいかが分かりやすい。

PROJECT_RULES に Human Approval が強く残っているのも、そのためだと思う。Qiita 記事のように、内容確認、公開タイミング、二重投稿防止、URL の記録まで含む作業では、「投稿できる」と「投稿してよい」は一致しない。できることを増やすのは自動化だが、やってよいことを決めるのは governance だ。この二つを混ぜないために、Human Approval が最後まで残されている。

もう一つ大きいのは、承認境界があると改善の方向もぶれにくいことだ。もし承認まで外す前提なら、改善は「どこまで自動化で押し切れるか」に寄りやすい。だが承認を残すと、改善対象は「人が短時間で正しく判断できるか」に寄る。Current Context にある「毎朝 60 秒以内に『正常 / 注意 / 要対応』を判断しやすくする」という目標は、まさにその方向だった。

これは非エンジニアにとって特に大きい。UI が見やすくなれば、どうしても「もう任せてよいはずだ」と思いやすい。だが、見やすさと承認権限は別に残す方が、あとで迷いにくい。どこに違和感があるか、どこで止めるべきかを最終的に引き受ける人が明確だからだ。自動化が強くなるほど、人間の役割は減るのではなく、どこを機械に任せ、どこで止めるかを定義する役割へ絞られるのだと思う。

さらに、承認境界を残すと「速さ」の定義も変わる。全部を自動で流す速さではなく、人が短時間で正しく判断できる状態を毎朝作る速さになる。Dashboard 改善が v1.1.0 の中心で、新しい書き込み Action や Human Approval 省略が中心でなかったのは、その速さの定義を崩さなかったからだと感じている。

6. 学び

• 275 tests passed は強い事実だが、それだけで Human Approval を外す根拠にはならない
• 見え方の改善と承認境界の維持を分けると、自動化の成功と本番判断を混同しにくい
• Governance に「最終判断は人間」と固定すると、責任の戻り先が明確になる
• 公開・更新のような本番操作では、「できる」と「やってよい」を分け続ける必要がある
• Human Approval を残すと、改善の軸が「全部自動化」ではなく「人が短時間で正しく判断できること」に揃う

7. 次回メモ

この続きで書くなら、Season 2 で「見え方だけを改善した版」と「まだ着手していない計画」をどう分けて語るかにつながる。境界を守る運用は、承認だけでなく記事の書き方にも表れるからだ。