案件が1つなら混ざりようがありません。2つでも注意していれば管理できます。3つを超えたあたりから、注意力での管理は破綻します。
この回は、取り違えが構造的に起きない形をどう作るかと、どこまでやるかの線引きを扱います。
1. 注意力に頼る方式が破綻する理由
「気をつける」が機能しない理由は単純で、注意力は一定ではないからです。事故は決まって、疲れているとき、急いでいるとき、割り込みが入ったときに起きます。
| 状況 | 起きること |
|---|---|
| 急いで対応している | プロファイルの指定を省略する |
| 割り込みで別案件に切り替えた | 前の案件の設定のまま作業する |
| 似た名前の環境がある | 本番と検証を取り違える |
| 久しぶりに触る案件 | どの設定を使うか思い出せない |
共通しているのは、判断を要求されているという点です。毎回「どの設定を使うか」を判断させる構成は、判断を誤る機会を毎回作っていることになります。判断させない形にするのが対策です。これは の扱い全般に言えることで、人間の注意力を前提にした設計は、規模が大きくなるほど破綻します。
EP.2 で「既定のプロファイルを作らない」と書いたのは、この原則の適用です。間違えたときに静かに動いてしまうのが最悪で、間違えたらエラーになるなら被害は出ません。
2. 分離の段階
分離には段階があります。下ほど確実で、上ほど日常の負担が軽い。全部を最上段でやる必要はありません。
| 段階 | 分けるもの | 確実さ | 日常の負担 |
|---|---|---|---|
| 設定で分ける | プロファイル、git 設定、鍵 | 中 | 軽い |
| シェルで分ける | 環境変数を案件ごとに切り替える | 中 | 軽い |
| ブラウザで分ける | プロファイル、または別ブラウザ | 中 | 軽い |
| 利用者を分ける | OS のユーザーアカウント | 高い | 重い（切り替えが要る） |
| 環境ごと分ける | 仮想環境、コンテナ | 高い | 重い |
| 端末を分ける | 物理的に別のマシン | 最も高い | 最も重い |
実務的には、上3つを全案件に適用し、機微な案件だけ下の段階を足すというのが現実的です。すべてを最上段でやると日常が回りません。逆に、上3つすら適用していない状態は、案件が2つを超えた時点で危うい。費用がかからず、日常の負担も軽いので、ここは全案件に適用しない理由がありません。
3. 切り替えを1コマンドにする
設定で分ける方式の弱点は、切り替えを忘れることです。ここを1コマンドにまとめ、いま何の案件モードかが常に見える状態にすると、忘れにくくなります。
# ~/.zshrc などに追加するuse-client() { local client="$1" local dir="$HOME/work/$client"
if [[ ! -d "$dir" ]]; then echo "そんな案件はありません: $client" >&2 return 1 fi
export CURRENT_CLIENT="$client" export AWS_PROFILE="$client" export CLOUDSDK_ACTIVE_CONFIG_NAME="$client" cd "$dir"
echo "案件: $client" aws sts get-caller-identity --query Arn --output text 2>/dev/null \ || echo " (AWS 未認証)"}
# プロンプトに常時表示して、取り違えを目で防ぐPROMPT='%F{yellow}[${CURRENT_CLIENT:-none}]%f %~ $ 'プロンプトに案件名を出すのが、地味ですが最も効きます。コマンドを打つたびに目に入るため、別案件のつもりで作業している状態に気づけます。切り替え時に接続先を表示するのも同じ狙いです。
同じ案件の中でも、本番環境のときだけプロンプトの色を変えると効果があります。赤色が出ていれば「いま本番だ」と身体が反応します。視覚に頼るのは、注意力に頼るのとは違います。判断ではなく認識だからです。
4. ブラウザを分ける
見落とされがちなのがブラウザです。管理画面、クラウドのコンソール、業務システム ── ログイン状態が混ざると、別案件の画面で操作します。
- プロファイルを案件ごとに作る — 履歴も拡張機能も分かれる
- プロファイルごとに見た目を変える — 開いている窓がどの案件か分かる
- 案件のブックマークをそのプロファイルに置く — 入口を間違えにくくなる
- 離任時はプロファイルごと消す — 残骸が残らない
4番目が効きます。プロファイルを消せば、その案件のログイン状態とパスワードの保存が丸ごと消えます。混ざった状態から個別に消すのは困難なので、分けておくこと自体が離任処理になります。特に をブラウザの拡張機能で管理している場合、どの案件の登録がどこにあるかが分からなくなりがちです。プロファイルごとに分けておけば、この問題も同時に解決します。
5. どこまでやるかの判断
分離は徹底するほど安全ですが、日常の作業が重くなります。重すぎる仕組みは守られなくなるため、それ自体がリスクです。判断の材料を挙げます。
- 1扱うデータの機微さ — 個人情報や金銭に関わるなら段階を上げる
- 2権限の強さ — 本番を壊せる権限があるなら分ける価値が高い
- 3案件の数 — 増えるほど混ざる確率が上がる
- 4切り替えの頻度 — 1日に何度も切り替えるなら、軽い方式でないと続かない
- 5顧客側の要求 — 契約で環境分離が求められている場合がある
5番目は事前に確認しておくべき項目です。契約で端末や環境の分離が求められていることがあります。後から発覚すると、作業のやり直しになります。受任時（EP.2）に確認しておくのが正解です。 の設計として顧客側が分離を前提にしている場合もあり、こちらの都合で1つのアカウントにまとめると、相手の統制を崩すことにもなります。
毎回の切り替えに数分かかる構成にすると、「今回だけ」と省略するようになります。そして省略が常態化します。続けられる重さに収めることが、安全性の一部だと考えてください。
6. 定期的に点検する
分離しても、時間が経てば例外が入り込みます。四半期に一度でも点検すると、混ざりかけた状態を早く戻せます。
#!/usr/bin/env bash# 手元の設定が案件ごとに分かれているかを確認する
echo "=== クラウドのプロファイル ==="grep '^\[' ~/.aws/credentials 2>/dev/null || echo "(なし)"echo "既定プロファイルの有無:"grep -c '^\[default\]' ~/.aws/credentials 2>/dev/null || echo 0
echoecho "=== SSH鍵 ==="ls -1 ~/.ssh/*_ed25519 2>/dev/null || echo "(なし)"
echoecho "=== git の案件別設定 ==="grep -A1 'includeIf' ~/.gitconfig 2>/dev/null || echo "(includeIf の設定なし)"
echoecho "=== 各案件ディレクトリで実際に使われるメールアドレス ==="for d in ~/work/*/; do [[ -d "$d/.git" || -d "$d" ]] || continue email=$(cd "$d" && git config user.email 2>/dev/null) printf ' %-28s %s\n' "$(basename "$d")" "${email:-(未設定)}"done最後の確認が要点です。設定したつもりで効いていないケースを見つけられます。ディレクトリごとに実際のメールアドレスを出せば、取り違えたまま作業していた案件がその場で分かります。
既定プロファイルの有無を確認しているのも同じ狙いです。いつの間にか既定が作られていることがあり、そうなると EP.2 で作った「指定を忘れたらエラー」という安全装置が無効になります。ツールの初期設定や、他のコマンドの副作用で作られることがあるため、自分では作っていないつもりでも確認する価値があります。安全装置が外れていることに気づかないのが、最も危険な状態です。
注意力に頼る方式は必ず破綻する（疲れているとき、急いでいるときに事故る）。判断させない形にするのが対策で、間違えたらエラーになる構成にする。分離には段階があり、上3つを全案件、機微な案件だけ下の段階が現実的。プロンプトに案件名を出すのは地味だが効く。そして重すぎる仕組みは守られないので、続けられる重さに収めてください。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。