OpenClaw を運用に乗せると、API キーやアクセストークンなどの機密情報をどこで、どう渡すかがすぐに問題になります。最初に設計を雑にすると、あとから漏えいリスクや切り分けの難しさが一気に増えます。
結論: OpenClaw 環境変数と機密情報の安全な管理方法は、最小構成で始めてログを見ながら段階的に広げるのが最短です。
Background
毎日の運用タスクは、手作業だと実行漏れや設定ブレが起きやすくなります。特に OpenClaw のように自動実行や外部 API 連携を含む環境では、機密情報の渡し方が安定性と安全性の両方に直結します。
重要なのは、最初から大量の環境変数を流し込まないことです。必要なものだけを明示し、どのジョブがどの秘密情報を使うのかを追える状態にしておくと、事故が起きても影響範囲をすぐに限定できます。
Step-by-step
1. 目的と対象範囲を決める
まずは 1 つのジョブだけを対象にします。たとえば「毎朝 9 時に要約を実行するジョブ」だけに絞り、そのジョブに本当に必要な機密情報だけを洗い出します。
この段階で確認したいのは 2 点です。どの外部サービスに接続するのか、そしてそのために必要な環境変数は何個か、です。
2. 機密情報をコードやコマンドに直書きしない
API キーをシェル履歴やリポジトリに残さないために、機密情報は .env のようなローカルファイルか、OS のシークレット管理機構で保持します。少なくとも、コマンド引数に直接書く運用は避けます。
1
2
3
4
5
6
7
8
# .env は Git 管理しない
cat > .env <<'EOF'
OPENAI_API_KEY=<REDACTED>
INTERNAL_API_TOKEN=your-internal-token
EOF
# 念のため権限を絞る
chmod 600 .env
.gitignore にも追加しておきます。
1
2
# 機密ファイルを Git に含めない
printf ".env\n" >> .gitignore
3. OpenClaw を起動する前に必要な変数だけ読み込む
環境変数は「常に全部見える」状態にせず、ジョブ実行前に必要なものだけ読み込むのが安全です。これなら不要な秘密情報が別ジョブへ漏れるのを防げます。
1
2
3
4
5
6
7
# .env の値を現在のシェルに読み込む
set -a
source .env
set +a
# 変数が入っているか確認する
env | grep -E 'OPENAI_API_KEY|INTERNAL_API_TOKEN'
確認時は値そのものをログに出さない運用が前提です。表示確認が必要なら、存在確認だけに留めます。
1
2
3
# 値そのものではなく、設定済みかどうかだけ確認する
test -n "$OPENAI_API_KEY" && echo "OPENAI_API_KEY is set"
test -n "$INTERNAL_API_TOKEN" && echo "INTERNAL_API_TOKEN is set"
4. 最小構成で OpenClaw ジョブを登録する
ジョブ登録時は、まず 1 本だけ作って挙動を見ます。スケジュール、タイムゾーン、実行メッセージを明示して、問題が出たときに切り分けしやすくします。
1
2
3
4
5
6
7
# 例: 毎日 9:00 に isolated セッションで実行する
openclaw cron add \
--name "daily-summary" \
--cron "0 9 * * *" \
--tz "Asia/Tokyo" \
--session isolated \
--message "ジョブを実行して結果を要約"
--tz "Asia/Tokyo" を省略すると、想定外の時刻に動いたように見えることがあります。最初から明示しておくほうが安全です。
5. ログを見て段階的に広げる
ジョブが通ったら、次に見るべきは「成功したか」だけではありません。認証エラーが出ていないか、余計な情報をログに吐いていないか、再実行時の挙動が安定しているかを確認します。
問題がなければ、そこで初めて対象ジョブや渡す環境変数を増やします。最初から複数ジョブを同時に動かすより、原因追跡が圧倒的に簡単です。
Common pitfalls
-
.envを Git にコミットしてしまう
git statusと.gitignoreを必ず確認します。すでにコミットした場合は削除だけでなく、履歴からの除去とキーのローテーションまで実施します。 -
API キーをコマンド引数に直接書く
シェル履歴やプロセス一覧に残ることがあります。exportやsource .envを使い、引数に秘密情報を載せない形へ寄せます。 -
使わない環境変数までまとめて読み込む
別ジョブに不要な秘密情報が見える状態になります。ジョブごとに必要な変数を絞り、用途単位で.envを分けるのが安全です。 -
タイムゾーン未指定で想定時刻とずれる
特に定期実行では発見が遅れます。--tz "Asia/Tokyo"のように明示し、登録後に実行時刻を確認します。 -
ログに秘密情報を出してしまう
デバッグ時のecho $TOKENは避けます。存在確認はtest -n "$TOKEN"のように行い、値そのものは出力しません。 -
認証切れや権限不足を成功扱いで見逃す
外部 API はキー期限切れや権限変更で突然失敗します。定期的にログを確認し、失敗時の再実行手順を先に決めておきます。
Summary
OpenClaw で環境変数と機密情報を安全に扱うには、必要最小限の秘密情報だけを明示的に読み込み、まず 1 ジョブで挙動を確認するのが基本です。ハードコードを避け、ログを見ながら段階的に広げる運用にすると、安全性と保守性を両立しやすくなります。
最初にやるべきことは多くありません。.env を Git 管理から外し、必要な変数だけを読み込み、最小構成の OpenClaw ジョブで検証する。この順番を守るだけで、機密情報の扱いはかなり安定します。