「partial」を失敗扱いにしない理由

1. リード

自動化の結果を見るとき、success 以外は全部失敗だと考えたくなる。私も最初はそうだった。だが 2026-07-26 の Current Context では、最終無人検証で Metricool は既知許容の partial で 7 / 7 保存 と記録されている。さらに既知の制限として、未提供指標がある場合 partial を仕様として許容する と明記されている。

これは甘い判定ではなく、朝の運用に必要な線引きだったと思う。今回のテーマは、partial を失敗扱いにしない運用ルールを先に決めたことで、無人実行の朝を現実に即して判断できるようになったという話だ。

2. 背景

Current Context の Operational Validation では、Day 7 の一時 No-Go を経て、2026-07-26 の最終無人検証で Go になっている。その確認項目には、DarkWake 中は Connector を開始しないこと、通常 Wake 後に GA4 / GSC / Clarity が success だったこと、wrapper exit code 0、stderr 空、全 178 tests passed などが並んでいる。その中に、Metricool だけは partial だが 7 / 7 保存 という形で書かれている。

既知の制限の節にも、同じ方向の整理がある。GSC は標準で数日のデータ遅延があり、Clarity は取得可能期間が短く、Metricool は未提供指標がある場合 partial を仕様として許容する。つまり Season 2 の現在地では、全部が毎朝きれいに success で揃うわけではないことを、先に事実として受け止めている。

3. 今回のテーマ

テーマは、partial を単純な失敗と分けたことで、仕様上の欠けと本当の異常を混同せずに済んだということだ。

無人実行の朝では、結果表示は短い方がよい。だが短い表示ほど、分類の精度が重要になる。仕様上ありうる欠けまで全部失敗に入れてしまうと、本当に止めるべき異常が埋もれやすい。Current Context が残している partial 許容は、その混同を避けるための分類だった。

4. 実際の出来事

Current Context の最終無人検証では、Metricool について「partial で 7 / 7 保存」と書かれている。この書き方は重要だと思う。単に partial だけで終わらず、保存自体は継続できていることも併記されているからだ。つまり、ここで見ているのは完璧さではなく、朝の運用としてどこまで任せられるかだった。

同じ Current Context の既知の制限では、Metricool の partial は未提供指標がある場合の仕様として扱われている。これは認証失敗や通信断と同じ箱に入れていない、ということでもある。もし同じ箱に入れていたら、毎朝の確認で「仕様どおり欠けているだけ」と「本当に壊れている」が同じ赤信号に見えてしまう。

GSC や Clarity の制限が一緒に明記されているのも大きい。GSC には標準で数日の遅延がある。Clarity は取得可能期間が短い。つまり、この運営 OS は「全部そろった完全な朝」を前提にしていない。外部サービス側の制約を含んだ現実の朝を前提にしている。その前提に立つなら、partial を無条件で失敗扱いにしない方が、むしろ誠実だ。

PROJECT_RULES の方でも、公開や判断では正本との整合を優先し、不明な事実を推測で埋めないことが求められている。partial の扱いも近いと思う。見た目がきれいだからといって success に寄せるのではなく、逆に雑に失敗へ落とすのでもない。何が起きているかを、そのまま名前で分ける姿勢が一貫している。

さらに大きいのは、partial を許容したからといって基準を緩めたわけではないことだ。最終無人検証では、DarkWake 除外、通常 Wake 後の GA4 / GSC / Clarity success、wrapper exit code 0、stderr 空、178 tests passed が揃っている。つまり partial を残したのは、失敗を見逃すためではなく、仕様上の欠けを説明可能なまま残しつつ、本当に止めるべき条件は別に立てるためだった。

この分類は Go 判定にも効いている。最終無人検証で Go にできたのは、全部が完璧な success にそろったからではない。運用条件が整い、そのうえで partial は既知許容として説明できたからだ。つまり Go を支えたのは、見栄えのよい結果一覧ではなく、成功・制限・異常を分けた説明可能性だった。

朝の運用で怖いのは、失敗を見逃すことだけではない。毎回のように仕様どおりの欠けで赤く見えてしまい、本当に止めるべき異常への感度が落ちることも怖い。partial を独立させておくと、制限付きで続けられている状態と、止まっている状態を分けて扱える。その差があるだけで、朝の判断はかなり現実的になる。

5. 考えたこと

非エンジニアの立場では、ここはかなり学びが大きかった。最初は、partial と表示された時点で「まだダメなのでは」と感じやすい。だが実際には、何が欠けていて、なぜ欠けていて、それでも朝の運用として受け入れる理由が説明できるなら、partial は曖昧な逃げではない。むしろ 現実を削らずに残すためのラベルだと思う。

AI と一緒に運用していると、結果をきれいにまとめたくなる。全部 success に見えた方が安心するからだ。だが安心しやすさのために分類を粗くすると、あとで本当に止めるべき異常を見落としやすい。partial を残すのは、完璧に見せることより、判断を壊さないことを優先した形だった。

Human Approval の考え方とも少し似ている。できることと、やってよいことを分けるのが Human Approval なら、取れていることと、十分に取れていることを分けるのが partial の運用だと思う。全部を二択にしないことで、朝の判断はむしろ強くなる。

もう一つ大きいのは、partial を success に偽装していないことだ。制限付きで通してよいなら success に寄せたくなるが、Current Context はそうしていない。partial のまま、ただし既知許容として扱う。この残し方があるから、あとで読み返しても「何が満点で、何が制限付きだったか」が分かる。判断の透明性という意味では、ここもかなり重要だった。

さらに、GSC の遅延や Clarity の取得期間制限が同じ文脈に並んでいることで、外部サービスの都合まで含めた現実の朝を前提にしていることも見えてくる。システムの内側だけを見れば白黒で切りたいが、外部サービスを跨ぐ運用では灰色を灰色のまま扱う設計も必要になる。partial は、その灰色を雑音ではなく情報として残すための言葉だったのだと思う。

6. 学び

• partial を全部失敗に入れない方が、仕様上の欠けと本当の異常を分けやすい
• 無人実行の朝では、表示の短さより分類の正確さの方が重要になる
• Metricool の partial 許容は甘さではなく、既知制限を前提にした運用設計だった
• GSC の遅延や Clarity の取得期間制限も含めて、現実の朝を前提にした方が説明しやすい
• Go 判定を支えるのは、完璧な見た目より成功・制限・異常を分けた説明可能性だった

7. 次回メモ

この続きで書くなら、Season 2 で「全部自動化する」より「人が短時間で判断できる状態を作る」方を優先した話につながる。分類を細かく残すのは、そのための土台でもあるからだ。