何人かのエンジニアが使う社内ツールになると、ホームディレクトリに放り込んでおくわけにもいかない。かといって、正しい置き場所と配り方を体系的に学ぶ機会はほとんどない。
この記事では、RHEL 9系/Ubuntu 24.04 LTSを想定環境として、自作シェルスクリプトを複数のサーバーや複数の担当者で使う「社内ツール」として整備するための設計——
/usr/local/binへの配置、installコマンドによる権限設定、--versionフラグの実装、Gitを使った更新の配布——を解説します。この記事のポイント
・installコマンドで/usr/local/binにroot:root・0755で配置できる
・root:root・0755で置くとsudoからも安全に呼び出せる
・--versionフラグを実装するとサーバーごとの版確認が1コマンドで済む
・Gitで管理しinstall.shで一括配置すれば複数サーバーへの更新が効率化できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
シェルスクリプトの置き場所がなぜ重要になるか
個人で使ううちは、スクリプトをホームディレクトリ（~/bin/）に置くか、その場でフルパス指定して実行すれば十分です。しかし複数のサーバーや複数の担当者が使うようになると、次の問題が現れます。・実行パスが人によって違う：「~/bin/backup.sh って言ったけど、自分のホームのことだよね？」
・sudoから呼べない：rootで実行したいのに
sudo ~/bin/deploy.shがパスを見つけられない・バージョンが人によって違う：誰かが古いコピーを手元に持っていて、最新版を配ったのに古い挙動をされる
これらを解消するのが「システム共通のディレクトリへの正しい配置」と「Gitによるバージョン管理」の組み合わせです。
シェルスクリプトの配置先：/usr/local/binと/optの使い分け
Linuxには慣例として、カスタムスクリプト・手動インストールしたツールの置き場が決まっています。・/usr/local/bin/：個々の実行ファイルを置く場所。
PATHに標準で含まれるため、ファイル名だけで呼び出せる・/usr/local/sbin/：root（管理者）専用のスクリプトを置く場所。一般ユーザーの
PATHには含まれないことが多い・/opt/<プロジェクト名>/bin/：スクリプト・設定・ドキュメントをひとまとめにしたい場合。1つのプロジェクトとして管理できる
選び方の目安は次の通りです。
| ケース | 推奨する配置先 |
|---|---|
| 単体のツールスクリプト（コマンドとして使う） | /usr/local/bin/ |
| root専用の管理スクリプト | /usr/local/sbin/ |
| 設定ファイルや補助スクリプトをセットで管理したい | /opt/<プロジェクト名>/bin/ |
/opt/以下に配置する場合は、/usr/local/bin/にシンボリックリンクを張るか、/etc/profile.d/にPATH追加のスクリプトを置いて対応するのが一般的です。「とりあえず1本のスクリプト」であれば
/usr/local/bin/が最初の選択肢です。ファイルを置くだけで全ユーザーが名前だけで呼び出せます。シェルスクリプトをinstallコマンドで配置する
ファイルを配置するとき、多くのエンジニアはcpコマンドを使います。しかしcpは権限をコピー元から引き継ぐため、chmodとchownを追加で実行する必要があります。installコマンドを使うと、コピー・所有者設定・パーミッション設定を1ステップで行えます。1. installコマンドの基本構文
# installコマンドでシェルスクリプトを配置する # install -o 所有者 -g グループ -m パーミッション コピー元 コピー先 sudo install -o root -g root -m 0755 backup.sh /usr/local/bin/backup
・-o root：所有者をrootに設定する
・-g root：グループをrootに設定する
・-m 0755：パーミッションを755に設定する（全員が実行可能・root以外は書き込み不可）
・コピー先のファイル名から
.sh拡張子を外すのは任意ですが、コマンドらしく見えるためによく行われます2. root:root・0755で配置する理由
sudoから呼び出すシェルスクリプトはroot:root・0755で配置するのが安全の基本です。理由は2つあります。1つ目は、一般ユーザーに書き込み権限を持たせないためです。スクリプトが誰でも書き換えられる状態（
0777など）だと、sudo経由で悪意ある変更を実行される可能性が出てきます。2つ目は、
sudoのセキュリティポリシーとの整合性です。sudoはデフォルトで「実行するバイナリがroot以外に書き込まれていないこと」を確認します。0755（rootのみ書き込み可）であれば、この条件を満たします。# 配置後の確認（出力例は環境により異なります） ls -la /usr/local/bin/backup # -rwxr-xr-x 1 root root 1234 Oct 26 10:00 /usr/local/bin/backup
--versionフラグでシェルスクリプトの版を管理する
スクリプトが複数のサーバーに展開されると「どのサーバーに何のバージョンが入っているか」が見えなくなります。--versionフラグを実装しておけば、確認が1コマンドで済みます。#!/bin/bash VERSION="1.2.0" case "$1" in --version|-v) echo "backup version ${VERSION}" exit 0 ;; esac # 以下にメイン処理を書く
MAJOR.MINOR.PATCH）を使うのが一般的です。破壊的な変更があれば MAJOR を、後方互換のある機能追加なら MINOR を、バグ修正なら PATCH を上げます。確認する際は次のように実行します。
# バージョンを確認する（出力例） backup --version # backup version 1.2.0
VERSION変数を変えてからinstallコマンドで再配置することで、バージョンアップを手作業で管理できます。Gitでシェルスクリプトを管理して更新を配布する
スクリプトをGitで管理することで、「誰が・いつ・何を変えたか」が記録に残ります。複数の担当者がメンテナンスするスクリプトでは特に効果が大きい設計です。1. リポジトリの基本構成
社内ツール用のリポジトリは次のようなディレクトリ構成が分かりやすいです。scripts-repo/ ├── bin/ # 配布するスクリプト本体 │ ├── backup │ └── deploy ├── install.sh # 配置スクリプト（installコマンドを列挙） └── README.md # 使い方・変更履歴
2. install.shで配置を自動化する
bin/以下のスクリプトを各サーバーに展開するためのinstall.shを用意しておくと、更新のたびに手作業でコマンドを打たなくて済みます。#!/bin/bash # install.sh - /usr/local/binへの一括配置スクリプト set -eu SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)" sudo install -o root -g root -m 0755 "${SCRIPT_DIR}/bin/backup" /usr/local/bin/backup sudo install -o root -g root -m 0755 "${SCRIPT_DIR}/bin/deploy" /usr/local/bin/deploy echo "インストール完了"
# 1. リポジトリをcloneまたはpull git pull origin main # 2. 配置スクリプトを実行 sudo bash install.sh
git pullしてからinstall.shを叩く」という更新手順が全サーバーで共通化されます。シェルスクリプトの設計・品質管理に関心がある方は、シェルスクリプト実践講座（shellscript.linuxmaster.jp）も参考にしてください。スクリプトの保守性を高める書き方を体系的に学べます。
利用者のPATHと/usr/local/binの関係
/usr/local/bin/は主要なLinuxディストリビューションで標準的にPATHに含まれています。ただし、環境によっては含まれていないことがあります。# PATHの確認（出力例は環境により異なります） echo $PATH # /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/usr/local/binが含まれていない場合は、/etc/profile.d/以下にファイルを追加してシステム全体に反映します。# /etc/profile.d/local-path.sh として配置する export PATH="/usr/local/bin:$PATH"
sudoはデフォルトで一般ユーザーのPATHを引き継がず、制限されたパスを使います。sudo bash script.shのようにシェル経由で呼べば問題ありませんが、sudo backupと直接呼ぶ場合はフルパスを指定するか、/etc/sudoersでsecure_pathに/usr/local/binを追記する必要があります。シェルスクリプト配置のトラブルシュート
「command not found」が出る
backup: command not found
・
ls -la /usr/local/bin/backupでファイルが存在するか確認する・
echo $PATHで/usr/local/binが含まれているか確認する・ファイルに実行権限がついているか（
xビット）を確認するsudoで実行しても「command not found」が出る
sudo backup # sudo: backup: command not found
sudoは独自のPATHを使うため、/usr/local/binを含まないことがあります。フルパスで実行するか、sudo env PATH=$PATH backupを試してみてください。install後に古い挙動のままになる
hashコマンドでシェルのコマンドキャッシュをクリアしてください。# コマンドキャッシュをクリアする hash -r
本記事のまとめ
自作シェルスクリプトを社内ツールとして整備するポイントをまとめます。| 設計ポイント | 推奨する方法 |
|---|---|
| 配置先（単体ツール） | /usr/local/bin/ |
| 配置コマンド | sudo install -o root -g root -m 0755 |
| バージョン確認 | backup --version で版番号を出力する実装 |
| 変更管理 | Gitで管理しinstall.shで一括配置 |
| sudo実行 | root:root・0755で配置し、フルパス指定またはsecure_pathを設定 |
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
シェルスクリプトの設計・実装から本番運用まで、体系的に学べる講座を用意しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：シェルスクリプトのコーディング規約｜命名・インデント・コメント・関数分割をチームで統一するスタイルガイドの作り方
- この記事の属するカテゴリ：シェルスクリプトへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます