「この夜間バッチ、どうやって動かしてるんですか」と聞くと、「担当の田中さんが、本番サーバーに SSH で入って、手でスクリプトを叩いてます」——受託でシステムの運用を引き継ぐとき、いまだに珍しくない答えです。動いてはいる。けれど、鍵を持つ人しか実行できず、いつ・誰が・何を動かしたかの記録も残らず、接続が切れるとジョブが中途半端に終わる。セキュリティ診断では十中八九ここを指摘され、退職や属人化のたびにヒヤリとする。本番への「常時開いた SSH の入口」は、見慣れているだけで立派な負債です。
同じ課題を大規模に解いた事例として、Slack が公開した SSH から REST へ：Slack の EMR データパイプライン近代化（Slack Engineering） があります（InfoQ の解説 も分かりやすい）。Slack は Airflow から EMR のマスターノードへ直接 SSH してジョブを起動していた 700 以上の処理を、Quarry という REST 経由のジョブ実行基盤に移し、本番クラスタへの直接 SSH を撤廃しました。規模は違っても、ここで起きている「属人 SSH → 監査できる実行基盤」という転換は、中小企業の業務システムでもそのまま効きます。
なぜ「SSHで入って実行」が負債なのか
SSH で本番に入って実行する運用は、最初は手軽です。問題は、運用が育つほど次の 3 つが効いてくることです。
第一に、攻撃面が広いこと。本番に直接入れる経路と鍵が常に存在し、鍵の配布・ローテーション・棚卸しが運用負荷としてのしかかります。鍵を持つ人が増えるほど、「誰が本番に入れるのか」を把握しきれなくなります。
第二に、監査できないこと。手で叩いた実行は、いつ・誰が・どのパラメータで動かしたかが構造化されて残りません。事故が起きたときに「何が起きたか」を後から追えないのは、運用として致命的です。
第三に、信頼性が低いこと。SSH セッションが切れるとジョブが中途半端に終わったり、逆に裏で走り続けて二重実行になったりします。Slack も、接続断でジョブが silently に失敗する問題を挙げていました。
| 観点 | SSH で入って実行 | REST 経由のジョブ基盤 |
|---|---|---|
| アクセス | 本番への常時 SSH と鍵が必要 | 本番への直接アクセス不要 |
| 実行記録 | 手作業・記録が残らない | API 経由で誰が何を実行したか残る |
| 接続断 | ジョブが中途半端／二重実行 | サーバー側でジョブを追跡・継続 |
| 担当 | 鍵を持つ人しか直せない（属人） | 権限で誰でも安全に実行できる |
「脱SSH」とは、入口を一本化して記録を残すこと
脱 SSH の本質は、「便利な近道（本番への直接ログイン）を塞ぎ、すべての実行を、認証・記録のある一本の入口に通す」ことです。Slack の Quarry の場合、Airflow は SSH の代わりに HTTP リクエストを送るだけになり、ジョブの投入・状態監視はサーバー側が受け持ちます。Airflow のプロセスが再起動しても、ジョブは基盤側で走り続ける。「実行する人」と「実行される本番」の間に、認証と記録を持つ層を一枚挟むのが核心です。
中小企業の業務システムにこの発想を持ち込むのに、Slack ほど大掛かりな仕組みは要りません。要点は「本番に直接入って手で叩く」をやめ、ジョブを「権限つきの API／管理画面から起動し、実行ログが残る」形にすること。CI/CD のパイプラインから実行する形に寄せるのも有効で、デプロイのリードタイム短縮と同じく、運用を「人手の手順」から「再現可能な仕組み」に変える話です（デプロイ速度を約 50% 速くする CI/CD 改善（GH Media） 参照）。
受託で進める「脱SSH」の現実的な順番
「全部を一気に基盤化」しようとすると、現場が止まって頓挫します。弊社の受託では、動いている運用を止めずに、リスクの高い経路から順に SSH を畳む進め方を取ります。
まず「本番に入れる経路」を棚卸しする
最初にやるのは基盤づくりではなく、現状把握です。誰が本番に SSH できるか、どの鍵がどこに配られているか、手で叩いているジョブは何があるか。ある業務システムの引き継ぎ案件では、棚卸しの結果、退職者の鍵が有効なまま残っていたり、「本番で直接編集して動かしている」スクリプトが見つかりました。塞ぐ前に、まず地図を作ります。全体像が誰にも見えていない状態の解き方は 依存関係を可視化する棚卸し設計（GH Media） も参考になります。
リスクの高いジョブから「記録の残る実行」に移す
棚卸しで洗い出したジョブのうち、頻度が高く・壊れると痛いものから、SSH 手実行を「権限つき・ログつきの実行」に置き換えます。一度に全部ではなく、1 本ずつ並走させて確認しながら移すことで、現場の不安を抑えます。ジョブが REST／管理画面経由になれば、実行記録が自然に貯まり、「いつ・誰が・何を」を後から追えるようになります。
常時SSHを撤廃し、緊急時だけ時限アクセスにする
主要なジョブが基盤側に移ったら、常時開いている SSH の入口を畳みます。完全にゼロにできない緊急対応用には、「申請して一時的に開き、使ったら自動で閉じる」時限アクセスに切り替える。これで「本番に常に入れる鍵」をなくし、入る場合は必ず記録が残る状態にします。秘密情報や認証の扱いを開発フローに組み込む考え方は GitLab 19 のシークレット管理と DevSecOps 自動化（GH Media） も併読してください。
ハマりやすい落とし穴
第一に、現場の手順を確認せずに鍵を止めること。動いている夜間バッチの実行経路を把握しないまま SSH を塞ぐと、その晩に処理が止まります。必ず棚卸し → 並走 → 切替の順を守ります。
第二に、緊急アクセスを残しすぎて骨抜きになること。「念のため」で常時 SSH を残すと、結局元に戻ります。緊急用は時限・記録つきに限定し、例外を運用ルールとして明文化します。
まとめ — 「鍵を持つ人だけが直せる」から卒業する
本番サーバーに SSH で入って手でジョブを叩く運用は、見慣れているだけで、攻撃面・監査・信頼性のすべてで負債です。Slack は 700 超のジョブを REST 経由の基盤に移し、本番への直接アクセスを撤廃しました。中小企業の業務システムでも、考え方は同じです。受託で取り組むなら、本番に入れる経路を棚卸しし、リスクの高いジョブから記録の残る実行に移し、常時 SSH を畳んで緊急時だけ時限アクセスにする——この順番で進めるのが、現場を止めずに「属人 SSH」を卒業する現実的な一手です。
「夜間バッチが担当者の SSH 頼みで不安」「セキュリティ診断で本番への直接アクセスを指摘された」というご相談は お問い合わせフォーム からどうぞ。本番アクセス経路の棚卸しから着手できます。
