Pumbaとは？Dockerコンテナにカオステストを行う使い方とコマンド【1.6対応】

Pumba（パンバ）は、Dockerなどのコンテナを対象に、プロセス停止・ネットワーク遅延・パケットロス・CPU負荷といった障害をコマンド1行で注入するオープンソースのカオステストツールです。開発はAlexei Ledenev氏で、GitHubのalexei-led/pumbaで公開されています。2026年11月8日時点の最新版は1.6.0（2026年11月5日公開）で、各版の変更点はPumbaのGitHubリリース一覧で確認できます。

なお、検索語の「pumba」はInstagramで知られるカラカル（猫科の動物）の名前や、映画『ライオン・キング』のイボイノシシも指します。ライオン・キングのキャラクターの綴りは「Pumbaa」でaが2つです。この記事は、コンテナ向けツールのPumbaを扱います。

まとめ：Pumbaでできることと使う前に知っておく制約

• 注入できる障害は、コンテナの停止系（kill・stop・pause・rm・restart・exec）、ネットワーク系（netem・iptables）、リソース負荷（stress）の3系統です。対応ランタイムはDocker・containerd・Podmanで、Windows向けバイナリは今後も作らないと公式に明記されています。
• 障害を入れたPumbaが異常終了すると、障害はコンテナに残ります。検証環境ではkill -9の後も200ミリ秒の遅延が続きました。pumba status --checkで検知し、iptablesはpumba revertで戻せますが、netemのqdiscは手動で消します。
• 対象名が1件も一致しなくても終了コードは0です。CIでは--output ndjsonのrun.endを見てno_targetsを失敗扱いにします。
• netemは送信（egress）側だけに効きます。受信側のパケットロスはiptables lossで作ります。netemとiptablesは--durationが必須です。
• containerdでは--labelが動きません。1.6.0の公式デプロイガイドの例は--labelを使っていますが実行すると失敗するので、re2:でnamespace/pod/container形式の名前を指定します。

以下、導入から各コマンドの挙動、障害を残さない手順、他ツールとの使い分けの順に説明します。

Pumbaの仕組みと対応ランタイム・動作環境

Pumbaはコンテナランタイムのソケット（Dockerなら/var/run/docker.sock）に接続し、対象コンテナを名前やラベルで選んで操作します。停止系のコマンドはランタイムのAPIを呼ぶだけです。ネットワーク系は、tcやiptablesを含むヘルパーコンテナを対象コンテナと同じネットワーク名前空間で起動し、そこでルールを入れます。1.6.0のREADMEには、NetflixのChaos Monkeyに着想を得てカオスエンジニアリングをコンテナの単位に持ち込んだツールだと書かれています。

注入できる障害とコマンドの対応

既定値は1.6.0の--helpで確認したものです。execの既定値がkill 1である点は、後の章で扱う事故につながります。

Docker・containerd・Podmanの対応状況とWindows非対応

配布バイナリはLinuxとmacOSのamd64・arm64の4種類です。READMEはmacOS版を「開発者の利便性のため」と位置づけ、ColimaやPodman machineなどのLinux VMを操作する用途に限っています。Windows版は、Linuxのnetnsやcgroupへの書き込みに相当する仕組みが無いことを理由に「サポートせず、予定もない」と明記されています。WSL2上のDocker Desktopでも同じ扱いです。

1.3.0から1.6.0までの変更点と更新時の確認事項

8日間でマイナー版が4回上がっています。CIではlatestを使わず、ghcr.io/alexei-led/pumba:1.6.0のように版を固定してください。出力形式の変更で、結果の判定スクリプトが壊れることがあるためです。

1.2系から上げるときに影響が出るのは次の3点です。1.5.0のリリースノートによると、iptablesのルールには識別用のcommentが付くようになり、カーネル側でcommentマッチ（legacyならxt_comment）が使えないと、注入は失敗します。全てのdry-runは--durationを待たなくなり、ネットワーク系の計画は標準出力に出ます。ログを解析していたスクリプトは直してください。1.3.0以降は、スクリプトに負の--durationが残っていると起動時にエラーになります。

Pumbaのインストール方法（バイナリ・Homebrew・コンテナイメージ）

導入方法は3つです。どれも1.6.0を入手できます。

# Linux：単体バイナリ（tar.gzではなく実行ファイルそのものが配布される）
curl -sL https://github.com/alexei-led/pumba/releases/latest/download/pumba_linux_amd64 -o pumba
chmod +x pumba
./pumba --version
# 以降の例を pumba コマンドで実行するため、PATH上へ配置
sudo install -m 0755 pumba /usr/local/bin/pumba

# macOS：Homebrew（homebrew-coreのformula）
brew install pumba

# コンテナとして実行（READMEの推奨）
docker pull ghcr.io/alexei-led/pumba:1.6.0
docker run -it --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  ghcr.io/alexei-led/pumba:1.6.0 --version

イメージの正規の配布先はGitHub Container Registryです。READMEではDocker Hub側を非推奨（Deprecated）としています。古い解説記事に出てくるヘルパーイメージgaiadocker/iproute2は書き写さないでください。1.6.0のヘルパーの既定値はghcr.io/alexei-led/pumba-alpine-nettools:latestです。

コンテナで動かす場合、PumbaはDockerソケット経由でホストのコンテナを操作できるため、実質的にホストのroot権限を持ちます。共有の検証環境では、実行できる人を限定してください。

Pumbaの基本構文と対象コンテナの指定方法

構文はpumba [グローバルオプション] コマンド [コマンドオプション] 対象コンテナです。--interval・--random・--label・--dry-runはグローバルオプションなので、コマンド名より前に置きます。netemやiptablesの--durationは、delayなどのサブコマンドより前に置きます。

名前・re2正規表現・ラベルでの絞り込み

# 名前で指定（複数並べられる）
pumba kill myapp mydb

# RE2正規表現は "re2:" を先頭に付ける
pumba kill "re2:^test"

# ^test に一致するコンテナから1つだけ無作為に選び、30秒ごとに停止
pumba --interval=30s --random kill "re2:^test"

# ラベルで絞る（複数指定はAND条件・Docker向け）
pumba --label app=db kill "re2:.*"

--labelはDocker APIのfiltersパラメータとして渡されます。Docker Composeで起動したコンテナは、Compose v2の既定ではプロジェクト名-サービス名-連番という名前になります。名前が変わりやすい環境では、com.docker.compose.service=dbのようなラベル指定のほうが安定します。

対象から外したいコンテナにはcom.gaiaadm.pumba.skip=trueラベルを付けます。検証環境では、このラベルのコンテナを名前で直接指定してもno containers foundとなり、選ばれませんでした。

dry-runで計画を確かめる手順

--dry-runを付けると、実際の障害は起こさず計画だけを出力します。1.5.0からは、netemとiptablesで適用と解除の実コマンドまで表示されます。次の出力は1.6.0の実行結果です。コンテナ名は読みやすく置き換え、シェルの引用符と事前確認の行は省いています。

$ pumba --dry-run netem --duration 30s delay --time 200 mydb
would run on /mydb via sidecar ghcr.io/alexei-led/pumba-alpine-nettools:latest:
  apply:  tc qdisc add dev eth0 root handle 504d: netem delay 200ms 10ms 20.00
  revert: tc qdisc del dev eth0 root handle 504d:

--jitterを指定していないのに、10msの揺らぎと相関20.00が入っています。netem delayの既定値だからです。--duration 30sを渡しても実行は0.69秒で終わりました。CIの前段では確認処理の時間はかかりますが、指定した30秒の終了待ちは発生しません。

障害を残さない実行手順（max-targets・run-id・status・revert）

netem・iptables・pause・stressと、--restart付きのstopは終了時に解除処理を行います。kill・rm・--restartなしのstopは、正常終了しても元の状態には戻しません。問題は解除の前にPumbaが落ちた場合です。ここからの実測はColima上のDocker Engine 29.5.2（linux/amd64、cgroupfs）とPumba 1.6.0のイメージで、2026年11月8日に行いました。遅延はコンテナ間のpingで測っています。

対象数の上限とrun-idを付けた実行

pumba --max-targets 1 --max-duration 15m --run-id drill-01 \
  netem --duration 5m delay --time 3000 --jitter 0 mydb

--max-targetsは既定で無効なので明示します。2件選ばれる条件で--max-targets 1を渡すと、refusing to run: 2 containers selected, --max-targets is 1で何も注入せずに終了コード1になりました。--skip-errorを付けても同じです。正規表現の書き間違いで全コンテナを止める事故は、これで防げます。

--max-durationは実行時間の予算です。3秒を指定して30秒のnetemを流すと、約5.4秒で終了コード1になり、その後のstatus --checkはcleanでした。解除が終わるまで待つため、指定どおりの秒数では止まりません。

0件一致をCIで失敗にするndjson判定

対象名が1件も一致しないとき、Pumbaは警告を出すだけで終了コード0を返します。これは1.6.0でも変わりません。障害が入らなかったのに「耐えた」と記録される誤判定になるので、結果イベントで判定します。

set -euo pipefail
pumba --output ndjson --run-id ci-42 --max-targets 1 \
  netem --duration 30s delay --time 200 --jitter 0 mydb | tee pumba.ndjson
jq -e 'select(.type=="run.end") | .status=="ok"' pumba.ndjson

存在しない名前で実行すると、run.endのstatusはno_targetsになりました。上のjq -eはfalseを受けて終了コード1で落ちます。statusの値と終了コードの対応はagents.mdにあります。

kill -9で残った障害の確認と復旧の実測

障害の注入中にPumbaのコンテナをdocker killで落とし、残り方を比べました。

差が出る理由は、iptablesのルールには--comment "pumba:drill-01"のように、サイドカーにはラベルでrun-idが刻まれる一方、qdiscにはコメント欄がないためです。revertはrunに帰属できないものを消さず、qdiscs are not attributable to a run; not removedと報告しました。netemの残留は手で消します。

# 先に中身を確かめ、ハンドル 504d: であることを確認する
docker run --rm --net container:mydb --cap-add NET_ADMIN --entrypoint tc \
  ghcr.io/alexei-led/pumba-alpine-nettools:latest qdisc show dev eth0

docker run --rm --net container:mydb --cap-add NET_ADMIN --entrypoint tc \
  ghcr.io/alexei-led/pumba-alpine-nettools:latest qdisc del dev eth0 root handle 504d:

pumba status --check mydb   # clean なら終了コード0

ヘルパーイメージの既定エントリーポイントはtailなので、--entrypoint tcを省くと終わらないコマンドになります。削除後のpingは平均0.11ミリ秒に戻り、status --checkはcleanでした。

statusもrevertも、対象を省くと稼働中の全コンテナを検査します。他のシステムが同居するホストでは、必ずコンテナ名を渡してください。revertは元の実行が止まっていることが前提で、走行中のrunには使いません。

コンテナ障害の注入（kill・stop・pause・rm・restart・exec）

# SIGKILLで強制終了（--signal SIGTERM などに変更可）
pumba kill --signal SIGKILL myapp

# 5秒間だけ一時停止し、自動で再開
pumba pause --duration 5s myapp

# 停止して20秒後に起動し直す
pumba stop --restart --duration 20s myapp

# 削除（Dockerでは既定で稼働中も強制削除し、匿名ボリュームも消える）
# ボリュームを残すなら --volumes=false を明示
pumba rm --volumes=false myapp

kill・stop・pauseはランタイムのAPIを呼ぶだけで、ヘルパーコンテナを使いません。--limitで一度に操作する台数を絞れます（0は一致した全台）。

stopのdurationとrestartの併用条件

stopの--durationは、--restartを付けたときだけ使われます。dry-runでstop --duration 2s myappを実行すると停止のログだけが出ました。--restartを付けると、starting containerのログが続きます。「一定時間止めて戻す」つもりで--restartを落とすと、コンテナは止まったままになります。

execのcommand・args指定と既定のkill 1

execは、実行する内容を--commandと--argsで指定します。docker execと同じ感覚でpumba exec myapp -- touch /tmp/testfileと書くと、--以降は無視されます。1.6.0のdry-runでもcommand="kill 1"となり、コンテナのPID 1を終了させる既定値が選ばれました。

# 正しい書き方
pumba exec --command "touch" --args "/tmp/testfile" myapp

ファイルを作るつもりでコンテナを落とす事故になるので、execを使うときは必ずdry-runでcommandの値を確認してください。

ネットワーク障害の注入（netemとiptables）

netemはLinuxカーネルのトラフィック制御（tc qdisc netem）を使います。効くのはコンテナの送信側（egress）だけです。受信側を落としたい場合はiptablesコマンドを使います。

netemの遅延・損失・帯域制限と既定値

# 3秒の遅延を5分間
pumba netem --duration 5m delay --time 3000 mydb

# 送信パケットの5%を破棄
pumba netem --duration 5m loss --percent 5 mydb

# 送信帯域を1Mbitに制限
pumba netem --duration 10m rate --rate 1mbit mydb

# 10%を破損・10%を重複
pumba netem --duration 5m corrupt --percent 10 mydb
pumba netem --duration 5m duplicate --percent 10 mydb

200ミリ秒の遅延を実コンテナに入れ、20回のpingを4回繰り返した結果です。注入前の平均RTTは0.1〜0.3ミリ秒でした。--jitter 0では200.2〜201.0ミリ秒に収まり、既定のjitterでは190.5〜210.4ミリ秒に揺れました。タイムアウトの境界値を試すときは--jitter 0を明示してください。

--durationを省略するとunset or invalid duration valueで終了します。--interval 3sに--duration 5sを渡すとduration must be shorter than intervalで起動しません。損失をまとまって発生させたい場合は、4状態マルコフモデルのloss-stateか、Gilbert-Elliottモデルのloss-gemodelを使います。

netem combineによる単一qdiscへの複合効果の設定

1.2.0でnetem combineが追加され、遅延と損失のような複数の効果を1つのqdiscにまとめて設定できるようになりました。

# 100msの遅延と20%の損失を同時に
pumba netem --duration 5m combine \
  --delay --delay-time 100 \
  --loss --loss-percent 20 \
  -- mydb

効果を1つしか指定しないとat least two netem effects are requiredで拒否されます。Pumbaが作るqdiscには予約ハンドル504d:が付き、Pumba以外が作ったqdiscは書き換えずに拒否します。

targetとmatch-allで特定の通信だけ劣化させる方法

--targetを付けると、指定した通信先への通信だけを劣化させられます。IPv4アドレス、CIDR、稼働中のコンテナ名またはIDを指定でき、コンテナ名は実行のたびにIPアドレスへ解決されます。

# service-a から service-b への通信だけに1秒の遅延
pumba netem --duration 10m --target service-b delay --time 1000 service-a

# 10.0.0.1 宛て、かつ送信元ポート5432 の通信だけ（1.6.0）
pumba netem --match-all --duration 5m --target 10.0.0.1 --egress-port 5432 \
  delay --time 200 mydb

--targetと--egress-portを併用するとき、--match-allの有無で意味が変わります。dry-runの計画では、無しだとtc filterが2行に分かれてどちらか一方に一致すれば遅延します。有りだと1行のmatch ip dst … match ip sport …にまとまり、両方に一致した通信だけが対象です。「DBへの通信だけ遅い」を再現したつもりで全ポートを巻き込まないように、複数の条件を組むなら--match-allを付けます。IPv6は--targetの対象外で、渡すとis not supportedで終了します。

iptables lossによる受信パケットの破棄

# 受信パケットの10%を2分間破棄
pumba iptables --duration 2m loss --probability 0.1 myapp

# 192.168.1.100から8080番ポートへのTCPを5パケットに1つ破棄
pumba iptables --match-all --duration 5m --protocol tcp --source 192.168.1.100 --dst-port 8080 \
  loss --mode nth --every 5 myapp

--probabilityは0.0〜1.0の割合で、netemの--percentとは単位が違います。--dst-portを指定するときは--protocol tcpかudpが必須で、省くとusing destination port is only supported for tcp and udp protocolで止まります。--match-allを付けない場合、dry-runの計画では-sと--dportのルールが2本に分かれ、どちらかに一致したパケットが破棄対象になります。

ヘルパーイメージとminikubeでの制約

対象コンテナにtcやiptablesが入っていなくても、Pumbaがヘルパーコンテナを起動して処理します。独自イメージを--tc-imageで指定する場合は、ネットワーク障害のガイドにある必須コマンド（sh・grep・tcに加え、Docker・Podmanではwhich・tail、containerdではsleep、--match-allではawk）を含めます。statusとrevertにはiptables-nftかiptables-legacyの実体も要ります。公式のヘルパーイメージには入っています。minikubeはVMにsch_netemカーネルモジュールが無くnetemが動かないと、デプロイガイドが注意しています。

CPU・メモリ負荷の注入（stressとinject-cgroup）

# CPU 2ワーカーを負荷80%で1分（1.4.0以降のフラグ）
pumba stress --duration 1m --cpu 2 --cpu-load 80 myapp

# CPU 2ワーカーと256MBのメモリ確保を30秒
pumba stress --duration 30s --cpu 2 --memory 1 --memory-bytes 256M myapp

# 対象と同じcgroupに入れて負荷をかける
pumba stress --inject-cgroup --duration 60s --cpu 2 myapp

1.4.0で--cpu・--memory・--ioのフラグが入り、stress-ngの--timeoutは--durationから自動で作られます。従来の--stressorsも使えますが併用はできません。stressはghcr.io/alexei-led/stress-ng:latestをサイドカーとして起動します。

systemdドライバの既定モードとリソース制限の非共有

既定モードは、Dockerの--cgroup-parentでサイドカーの配置先を決めます。cgroupドライバがcgroupfsなら対象の子cgroupに入り、対象のCPU・メモリ制限を共有します。cgroupfsの環境で--cpu 1 --cpu-load 50を流すと、docker statsにはサイドカーで51.34%、対象コンテナ側にも48.82%が計上されました。systemdドライバでは子cgroupを作れないため、サイドカーはsystem.sliceの兄弟cgroupに置かれ、対象コンテナの制限は共有されません。

ホストのドライバはdocker infoの「Cgroup Driver」欄で確認できます。systemdのホストで既定モードのまま「メモリ上限に達したときの挙動」を試しても、対象コンテナは上限に届きません。対象と同じcgroupで負荷をかけるには--inject-cgroupを使います。stress-ngイメージのタグ0.20.01（2026年2月27日公開）以降が必要で、OOMの範囲も対象と共有するため、対象コンテナ自体がOOMで終了する可能性があります。

KubernetesでPumbaを使うときのDaemonSet構成

公式リポジトリのdeploy/pumba_kube.ymlは、各ノードの/var/run/docker.sockをマウントするDaemonSetで、イメージも旧名のgaiaadm/pumbaのままです。Kubernetesは1.24でdockershimを削除したため、containerdで動く現行のKubernetesではそのまま使えません。公式のデプロイガイドにcontainerd向けの例がありますが、そこにある--labelの指定を次のように直す必要があります。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: pumba-containerd
  namespace: pumba # 事前に kubectl create namespace pumba で作成
spec:
  selector:
    matchLabels:
      app: pumba
  template:
    metadata:
      labels:
        app: pumba
    spec:
      hostPID: true
      containers:
        - name: pumba
          image: ghcr.io/alexei-led/pumba:1.6.0
          args:
            - --runtime
            - containerd
            - --containerd-namespace
            - k8s.io
            - --max-targets
            - "1"
            - --interval
            - 30s
            - netem
            - --duration
            - 20s
            - --tc-image
            - ghcr.io/alexei-led/pumba-alpine-nettools:latest
            - delay
            - --time
            - "3000"
            - "re2:^default/target-pod/"
          securityContext:
            privileged: true
          volumeMounts:
            - name: containerd-socket
              mountPath: /run/containerd/containerd.sock
      volumes:
        - name: containerd-socket
          hostPath:
            path: /run/containerd/containerd.sock

containerdで失敗するlabel指定とre2での代替

1.6.0のpkg/runtime/containerd/client.goは、ラベルの指定があるとlabel filtering is not yet implementedを返します。containerdのソケットに--label付きで接続すると、このメッセージで終了コード1になりました。READMEのフラグ表には未対応と書かれており、デプロイガイドの例は実装と合っていません。

containerdでは、KubernetesのコンテナにPumbaがnamespace/pod/container形式の名前を付けます。re2:^default/target-pod/のように名前空間とPod名で絞ってください。Podラベルでの保護も当てになりません。ユーザーガイドは、Pumbaが読むのはランタイムのコンテナのラベルでありPodのメタデータではないと明記しています。除外リストではなく、対象を許可リストの形で指定します。

この構成はノード上の全コンテナを操作できる特権DaemonSetです。対象をnodeSelectorで検証用ノードに限定し、本番クラスタの常設には使わないでください。

Pumbaを選ぶ場面と他のカオスツールを選ぶ場面

最新版はGitHub Releases APIの値です。成熟度はChaos MeshとLitmusChaosのCNCFプロジェクトページで確認しました。Gremlinの料金ページに定価は無く、個別見積もりです。30日間のトライアルはクレジットカードなしで始められます。

Pumbaが向いているのは、Docker ComposeやCIの結合テストで「DBが3秒遅れたら」「キャッシュが落ちたら」を再現する場面です。クラスタにコンポーネントを入れる必要がなく、バイナリ1つかイメージ1つで始められます。Dockerのコンテナ起動コマンドで環境を立ち上げ、そのままPumbaで障害を入れる流れが最も手軽です。

Kubernetesのクラスタ全体で実験を管理するなら、Pumbaは選ばないほうがよいです。PumbaにはPod単位の実験定義と、CRDとして残る実験履歴がありません。特権DaemonSetを置く運用も重くなります。この場合はCRDで実験を宣言できるChaos MeshかLitmusChaosを使います。AWSのマネージドサービスを止める実験は、コンテナの外側で起きるためPumbaでは作れません。AWS Fault Injection Service（FIS）の領域です。障害を前提にした基盤の設計ごと見直すなら、AWS・Google Cloud・Azureのインフラ構築支援も相談先になります。

Toxiproxyはアプリとの間にTCPプロキシを挟む方式で、コンテナの権限を必要としません。アプリの接続先をプロキシに向けられるなら、NET_ADMINや特権を避けたいCI環境ではToxiproxyのほうが扱いやすい場合があります。実験設計や停止条件の決め方はカオステストの実験設計とツール選定でまとめています。

よくある質問

Pumbaという名前にはどういう意味がありますか？

ツール名の由来は、READMEや公式ドキュメントには書かれていません。検索で「pumba」と調べると、Instagramで人気のカラカルや、『ライオン・キング』のイボイノシシ（綴りはPumbaa）の情報も表示されます。この記事で扱うPumbaは、GitHubのalexei-led/pumbaで公開されているコンテナ向けのカオステストツールです。

PumbaはDockerコンテナとして実行できますか？

できます。READMEが推奨する方法で、docker run -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/alexei-led/pumba:1.6.0の後ろにPumbaのコマンドを続けます。イメージはscratchベースで、Pumbaのバイナリに加えてCA証明書とタイムゾーンデータを含みます。ソケットを渡すのでホストのroot相当の権限を持つ点と、CIでは版のタグを固定する点に注意してください。

PumbaのGitHubリポジトリとライセンスは？

リポジトリはgithub.com/alexei-led/pumba、ライセンスはApache License 2.0で、Go言語で書かれています。2026年11月8日時点でスター数は約3,200、最新版は1.6.0です。1.3.0以降は短い間隔でリリースが続いているため、導入時にリリース一覧で最新の版を確かめてください。

WindowsでPumbaは使えますか？

使えません。Windows向けバイナリは配布されておらず、READMEにはWindows対応のプルリクエストも受け付けないと書かれています。netnsやcgroupなどLinuxの機能に依存するためで、WSL2上のDocker Desktopでも同じ扱いです。Windows端末から使う場合は、Linux VMの中でPumbaを実行してください。

PumbaとChaos Monkeyの違いは何ですか？

Chaos Monkeyは、Spinnakerで管理しているクラウドのインスタンスを無作為に終了させるツールです。PumbaはChaos Monkeyに着想を得ていますが、対象はコンテナで、終了だけでなくネットワーク遅延やCPU負荷も注入できます。Spinnakerも必要なく、バイナリ1つかコンテナイメージ1つで動きます。

関連記事

• カオステストとは？障害注入の実験設計とツール選定・本番実施の判断を実装者向けに解説
• AWS Fault Injection Service（FIS）とは？カオスエンジニアリングの仕組み・実験テンプレート・料金と採用判断を実装者目線で解説
• サーキットブレーカーとは？マイクロサービスの障害連鎖を止める仕組みと実装・導入判断を解説
• バルクヘッドパターンとは？障害隔離の仕組みと実装方法・採用判断を実装者目線で解説
• Dockerコンテナ起動コマンドの使い分け｜run・start・execと起動しない時の対処