デプロイ方式の選定: 4つの質問で候補を2つに絞る
デプロイ5方式を比べた7軸を、自分の状況に当てて2つまで絞る手順です。
決め方の順番が大事です。7軸を全部同時に見ると決まりません。効き方の強い順に4つの質問（機械に入れるか / 現地に行けるか / 何台あるか / 状態を問い合わせるか）を通すと、たいていの状況で候補は2つになり、最後は常駐物を1つ増やせるかで決まります。
質問1: 配る側から機械に入れますか
最初は到達性です。
機械が NAT の内側に居て、こちらから接続を張れないなら、push 型はここで落ちます。VPN に参加させる、踏み台を置く、といった工夫で候補に戻すことはできますが、それは「戻すために何かを増やす」ことなので、増やせない前提なら落ちたままです。
工場出荷して顧客のネットワークに入る機械、モバイル回線の先に居る機械、そもそも所在が分からない機械。相手の場所を自分で決められないなら、この時点で pull 系（B・C・D・E）に確定します。
質問2: 壊れたとき、現地に人が行けますか
次がロールバックの軸です。
行けるなら、ロールバックは「あると嬉しい」程度で、最悪は現地で SD カードを挿し直せば復旧します。
行けないなら、優先順位が入れ替わります。文鎮化が許されない以上、機械が単独で前の状態に戻れることが他の何より先に来る必須要件になるので、A/B 型（A/B パーティション）の常駐コスト✗と帯域✗はこの条件の前では誤差に落ち、比べる相手は交通費と2面ぶんのストレージになります。
この質問だけは、答えが「行けない」なら他の軸をほぼ無視できます。他の質問は候補を絞りますが、この質問は答えを決めます。
質問3: 何台ありますか
ここが観測性の軸が効き始める境目です。
1台なら壊れたら気づきます。人間が見ているので。
数十台を超えると、「何台が新しい版になっているか」を数える手段が要ります。push 型の観測性◎は1台に入るのを100回やっても100倍にはならず、100回のうち3回失敗したときにどの3台だったかを追う仕組みを、別に作ることになります。
数百台になると通知の設計そのものが問題になり、全機械が同じ周期で取りに来れば、配布側から見える負荷は平らにならずに山を作ります。
質問4: 機械の状態を問い合わせる必要がありますか
最後はパッケージ型を選ぶかどうかの質問です。
「いま何がどのバージョンで入っているか」を聞けることは、他の4方式には無い性質です。台数が増え、機械ごとに状態がずれ始めると、この性質の価値が跳ね上がります。
逆に、全機械が常に同じ状態であるべきなら、この性質は要りません。イメージ型のほうが素直です。状態のばらつきを許容して管理するか、ばらつきを許さないかの分かれ道です。
4つ通した結果
| 状況 | 残る候補 |
|---|---|
| 自宅やオフィスの機械 1〜数台、設定ファイルを配る | A（push） / B（pull） |
| 顧客先に納めた機械、現地に行けない | E（A/B） |
| 社内の数十台、何が入っているか把握したい | C（パッケージ） / D（イメージ） |
| 自分のアプリを数台、環境ごと揃えたい | D（イメージ） / B（pull） |
最後の1つはどう決めるか
2つ残ったら、機械側で自分から動くもの（常駐プロセスや定期実行）を1つ足せるかで決まります。
足せるなら、機械側に判断を持たせる方式（B 以降。B はエージェントを常駐させ、C は定期実行で apt を叩きます）。ネットワークが切れても機械は動き続け、復帰したら自分で追いつきますが、代わりに、それが止まったことに気づく仕組みを持つことになります。
足したくないなら push 型。動かし続けるものは無く、機械に置くのは公開鍵と sudoers の数行だけです。代わりに、判断はすべて配る側に残ります。
これは技術の優劣の話ではなく、運用に人手をどれだけ割けるかの話です。監視すべきものを1つ増やす余裕があるかどうか。ここを技術で決めようとすると、たいてい間違えます。
決めた後にやること
方式が決まったら、その方式が弱い軸を1つだけ補強するのが費用対効果が高くなります。全部埋めようとすると、結局5方式ぶんの複雑さを1つの仕組みに詰め込むことになって、どの軸でも中途半端になります。
| 選んだ方式 | 最初に補強する軸 |
|---|---|
| A（push） | ロールバック。手続きの途中死を潰す |
| B（pull） | 観測性。取りに来なかった機械を検出する |
| C（パッケージ） | conffile の方針。対話で止まらないよう固定する |
| D（イメージ） | 自動復帰。健全性の確認と戻す判断を組み込む |
| E（A/B） | 帯域。差分更新が要るか測る |
補強の順番を間違えると、動くけれど怖くて使えない状態になります。怖さの正体は2つしかありません。戻せないか、届いたか分からないか。
このシリーズの検証について
シリーズの入口（Raspberry Pi デプロイ5方式を7軸比較）に書いたとおり、2026-09-30 時点でも実機が動いているのは A（push）だけで、2026-09-01 の公開時から変わっていません。残り4方式の評価は一次資料と設計上の性質から書いたもので、実機で測った値は入っていません。
検証用の公開リポジトリは準備中です。このシリーズの共通課題（同じ設定ファイルを同じ機械に配る）を5通りで実装して、動いたものから表を更新します。セルが「一次資料」から「実測済み」に上がっていく構造にしてあるので、どこまで確かめたかが外から見えます。
実際に配ってみて表が変わったら、この章の決定木も直します。机の上で作った決定木が、そのまま残るとは思っていません。
この記事は役に立ちましたか？