デプロイ方式の選定: 4つの質問で候補を2つに絞る

ここまでの5章で、5方式と7軸が出揃いました。この章では、それを自分の状況に当てて2つまで絞る手順にします。

決め方の順番が大事です。7軸を全部同時に見ると決まりません。効き方の強い順に4つの質問を通すと、たいていの状況で候補は2つになります。

質問1: 配る側から機械に入れますか

最初は到達性です。

機械が NAT の内側に居て、こちらから接続を張れないなら、push 型はここで落ちます。VPN に参加させる、踏み台を置く、といった工夫で候補に戻すことはできますが、それは「戻すために何かを増やす」ことなので、増やせない前提なら落ちたままです。

工場出荷して顧客のネットワークに入る機械、モバイル回線の先に居る機械、そもそも所在が分からない機械。相手の場所を自分で決められないなら、この時点で pull 系（B・C・D・E）に確定します。

質問2: 壊れたとき、現地に人が行けますか

次がロールバックの軸です。

行けるなら、ロールバックは「あると嬉しい」程度で、最悪は現地で SD カードを挿し直せば復旧します。

行けないなら、優先順位が入れ替わります。文鎮化が許されない以上、機械が単独で前の状態に戻れることが他の何より先に来る必須要件になるので、A/B パーティション型の常駐コスト✗と帯域✗はこの条件の前では誤差に落ちます。交通費と2面ぶんのストレージを比べる話になるので。

この質問だけは、答えが「行けない」なら他の軸をほぼ無視できます。他の質問は候補を絞りますが、この質問は答えを決めます。

質問3: 何台ありますか

ここが観測性の軸が効き始める境目です。

1台なら壊れたら気づきます。人間が見ているので。

数十台を超えると、「何台が新しい版になっているか」を数える手段が要ります。push 型の観測性◎は1台に入るのを100回やっても100倍にはならず、100回のうち3回失敗したときにどの3台だったかを追う仕組みを、別に作ることになります。

数百台になると通知の設計そのものが問題になり、全機械が同じ周期で取りに来れば、配布側から見える負荷は平らにならずに山を作ります。

質問4: 機械の状態を問い合わせる必要がありますか

最後はパッケージ型を選ぶかどうかの質問です。

「いま何がどのバージョンで入っているか」を聞けることは、他の4方式には無い性質です。台数が増え、機械ごとに状態がずれ始めると、この性質の価値が跳ね上がります。

逆に、全機械が常に同じ状態であるべきなら、この性質は要りません。イメージ型のほうが素直です。状態のばらつきを許容して管理するか、ばらつきを許さないかの分かれ道です。

4つ通した結果

最後の1つはどう決めるか

2つ残ったら、常駐プロセスを1つ増やせるかで決まります。

増やせるなら、機械側に判断を持たせる方式（B 以降）。ネットワークが切れても機械は動き続け、復帰したら自分で追いつきますが、代わりにその常駐物が落ちたことに気づく仕組みを持つことになります。

増やしたくないなら push 型。機械に置くのは公開鍵1行だけで、動かし続けるものはありません。代わりに、判断はすべて配る側に残ります。

これは技術の優劣の話ではなく、運用に人手をどれだけ割けるかの話です。監視すべきものを1つ増やす余裕があるかどうか。ここを技術で決めようとすると、たいてい間違えます。

決めた後にやること

方式が決まったら、その方式が弱い軸を1つだけ補強するのが費用対効果が高くなります。全部埋めようとすると、結局5方式ぶんの複雑さを1つの仕組みに詰め込むことになって、どの軸でも中途半端になります。

補強の順番を間違えると、動くけれど怖くて使えない状態になります。怖さの正体は2つしかありません。戻せないか、届いたか分からないか。

このシリーズの検証について

冒頭の pillar に書いたとおり、2026-09-01 時点で実機が動いているのは A（push）だけです。残り4方式の評価は一次資料と設計上の性質から書いたもので、実機で測った値は入っていません。

検証は公開リポジトリで進めます。このシリーズの共通課題（同じ設定ファイルを同じ機械に配る）を5通りで実装して、動いたものから表を更新します。セルが「一次資料」から「実測済み」に上がっていく構造にしてあるので、どこまで確かめたかが外から見えます。

実際に配ってみて表が変わったら、この章の決定木も直します。机の上で作った決定木が、そのまま残るとは思っていません。