direnv徹底解説：インストール (macOS/Windows/Linux) から活用例・ベストプラクティスまで
開発プロジェクトごとに異なる環境変数を管理するのは面倒な作業です。ディレクトリごとに環境変数を自動で切り替えてくれるツールがdirenvです。direnvを使えば、ディレクトリに入るたびにそのプロジェクト専用の環境変数を自動ロードし、抜けるとクリーンにアンロードできます。環境設定が各プロジェクトに閉じ込められるため、グローバルなシェル設定を汚染せずに済み、12-factorアプリの理念に沿った環境変数管理も容易になります。本記事では direnv の概要から、macOS・Windows・Linuxへのインストール方法、基本的な使い方、実践的なユースケース、セキュリティ上の注意点、応用的な活用方法、トラブルシューティング、CI/CDでの扱いまでを網羅的に解説します。
direnvとは何か？その目的とメリット
direnvは既存のシェルに機能拡張する形で動作するツールで、カレントディレクトリに応じて環境変数を自動的にロード／アンロードしてくれます。専用の.envrcファイル（設定次第で.envファイルも）に書かれた内容を利用し、ディレクトリに入る (cdする) と環境変数を読み込み、ディレクトリを出ると設定を元に戻します。これにより、プロジェクトごとに異なる環境構築を実現しつつ、~/.bash_profileや~/.zshrcといったグローバルな設定ファイルを煩雑にせずに済みます。
direnvの主なメリットは以下の通りです：
- プロジェクトごとの環境分離：プロジェクトAとBで異なるバージョンのツールや異なる環境変数が必要な場合でも、各ディレクトリに専用の環境変数を定義することで自動で切り替わります。グローバル環境を切り替える手間がなく、隔離された開発環境を実現できます。
- 環境変数管理の簡素化：従来は
.envファイルを用意して手動でsourceしたり、シェル起動時にプロファイルで設定したりしていました。direnvを使えばディレクトリ移動に連動して自動適用されるため、手動の読み込み忘れや設定切り替えミスが減ります。 - チームでの環境共有：リポジトリに
.envrcを含めておけば、チームメンバー全員が共通の環境変数設定（例：開発用のAPIエンドポイントやデバッグフラグ）を利用できます。メンバー各自がdirenvを導入しdirenv allowするだけで、共通の開発環境を再現できます。 - シークレットの適切な管理：プロジェクトごとに異なる機密情報（APIキーや認証情報）をディレクトリ単位でロードできるため、うっかり他プロジェクトに混在させることがありません。さらに後述するベストプラクティスにより、シークレットをソースコード管理に含めず安全に扱えます。
- 高速かつ言語非依存：direnvは単一の静的バイナリで提供されており、各コマンド実行前にフックする処理も非常に高速です。また特定のプログラミング言語に依存せず、PythonのvirtualenvやNodeのnvmなど言語別ツールの代替・補完としても使えます。
以上のように、direnvは開発者の環境変数管理をシンプルかつ強力にしてくれるツールです。それでは具体的な導入方法から見ていきましょう。
インストールとセットアップ
direnvのインストールは 「本体のインストール」 と 「シェルへのフック設定」 という二段階で行います。まず各OSごとにdirenv本体をインストールし、その後使用しているシェルにdirenvをフック（連携）させる設定を追加します。対応するOS・シェルごとの手順は以下です。
macOSでのdirenvインストール
macOSではHomebrewを使用するのが最も簡単です。Homebrewがインストール済みであれば、以下のコマンドでdirenvを導入できます：
# Homebrewでdirenvをインストール
brew install direnv
インストール後、シェルのフック設定を行います。macOSのデフォルトシェルはZshなので、~/.zshrcファイルの末尾に次の一行を追加してください：
# Zshにdirenvフックを追加
eval "$(direnv hook zsh)"
Zshをご利用でない場合は、お使いのシェルに応じて以下のように設定します（※それぞれシェルの初期化ファイルに追記します）：
- Bashの場合：
eval "$(direnv hook bash)"を~/.bashrcに追加 - Fishの場合：
direnv hook fish | sourceを~/.config/fish/config.fishに追加 - その他のshell（tcshやElvish等）：公式ドキュメントの指示に従い
direnv hook <shell名>の出力をシェル設定に組み込んでください。
設定を追加したら、source ~/.zshrc やシェルの再起動を行い、フックを有効化します。これで、新しいシェルでdirenvが自動的に動作するようになります。
Linuxでのdirenvインストール
Linuxでは多くのディストリビューションでdirenvが公式パッケージとして提供されています。以下は主要ディストロにおけるインストール方法の例です。
- Ubuntu/Debian系:
sudo apt install direnv - Fedora系:
sudo dnf install direnv - Arch Linux:
sudo pacman -S direnv
パッケージマネージャでインストールした後、シェルの設定ファイルにフックを追加します。基本的な手順はmacOSの場合と同様で、Bashなら ~/.bashrc に、Zshなら ~/.zshrc にそれぞれ対応する行（例：Bashなら eval "$(direnv hook bash)"）を追記します。使用中のシェルに合わせて正しいコマンドを入れてください。
フックを設定したらシェルを再読み込みし（source ~/.bashrc 等）、direnvのフックが有効になっていることを確認します。正しく設定されていれば、後述の.envrc作成時に自動で読み込みが行われるようになります。
Windows (WSL含む)でのdirenvインストール
Windows環境でもdirenvを利用可能です。Unix系のシステムではありませんが、いくつか方法があります。
- WSL (Windows Subsystem for Linux)で使用する場合：WSL上でUbuntuなどLinuxディストリを動かしている場合、そのWSL内にdirenvをインストールします。手順は上述のLinuxの場合と同様で、例えばWSL上のUbuntuなら
sudo apt install direnvでインストール可能です。その後、WSL上のシェル（BashやZsh）の設定ファイルにeval "$(direnv hook bash)"等を追記してください。WSL経由でVSCodeを使っている場合も、WSL内でdirenvが動作し環境変数を設定できます。基本的にWSL内ではLinuxと同じ手順で問題ありません。 - ネイティブWindowsで使用する場合：Windows上で直接direnvを使うには、まずdirenvの実行ファイルを入手します。公式が提供するバイナリを使用するか、Windows用パッケージ管理ツールを使う方法があります。例えばWingetを使う場合、管理者権限のターミナルで次のコマンドを実行します：
winget install --id=direnv.direnv -e上記によりdirenvのWindows版バイナリがインストールされ、パスが通ります。または、Scoopを使用してscoop install direnvとしてインストールすることも可能です。手動でGitHubのリリースページからdirenv.windows-amd64.exeをダウンロードして配置する方法もあります。 インストール後、PowerShell上でdirenvをフックさせる設定を行います。PowerShellは他のシェルと設定方法が異なりますが、公式ドキュメントによれば、PowerShell用のhookスクリプトを呼び出すには$PROFILE（PowerShellのプロファイルスクリプト）に以下を追記します。# PowerShellにdirenvフックを追加 Invoke-Expression "$(direnv hook pwsh)"$PROFILEはPowerShellのバージョンによって場所が異なりますが、一般的には%USERPROFILE%\Documents\PowerShell\Microsoft.PowerShell_profile.ps1などに相当します。エディタでこのファイルを開き、上記の行を追加してください。追加後、PowerShellを再起動するとdirenvのフックが有効になります。 Git BashやCygwin/MingW等を使用している場合は、それら環境に合わせてdirenvを導入します。Git Bashの場合は、上記の手順でWindows用バイナリを入手し、Git Bashの~/.bashrcにフック（eval "$(direnv hook bash)"）を追加すれば動作します。Cygwinの場合も同様に、Cygwin内にdirenvパッケージを導入しシェル設定を行います。
💡 補足: Windows上でdirenvを使う際は、可能であればWSLやGit Bashの利用をおすすめします。direnv自体はPowerShellや他のshellにも対応していますが、やはりUnix系シェル上での利用が主眼となっているためです。WSLならLinuxと同等の操作性でdirenvを活用できます。また、Git Bash経由でVSCodeを使うケースでもdirenvは問題なく動作します。
ここまででdirenv本体のインストールとシェルへの組み込みが完了しました。次はいよいよdirenvの基本的な使い方を見てみましょう。
基本的な使い方と.envrcの書き方
direnvを導入したら、各プロジェクトディレクトリで環境変数定義ファイル .envrc を作成します。このファイルにそのディレクトリで有効にしたい環境変数の設定やコマンドを記述します。.envrcはシェルスクリプト（基本的にbash文法）として解釈されるため、export VAR=valueのように環境変数をエクスポートする記述や、他のファイルを読み込む簡単なロジックなども書くことができます。
基本的な手順：
- 任意のプロジェクト用ディレクトリに移動します。例えば
my-projectディレクトリを作って移動します：mkdir ~/my-project cd ~/my-project - そのディレクトリ直下に
.envrcファイルを作成し、設定したい環境変数を書き込みます：
例）my-project/.envrcの内容:export FOO="foo" # 環境変数FOOをセット export BAR="bar baz" # 値に空白がある場合は引用符で囲む.envrcにはこのようにexport文で環境変数を定義します。単なる「KEY=VAL」のような形式では読み込まれない点に注意してください（シェルスクリプトなのでexportが必要）。 .envrcを保存したら、最初の一回だけ許可を与える操作を行います。セキュリティのため、direnvは初見の.envrcを自動では実行しません。direnv allowコマンドを実行して、そのディレクトリの.envrcを信頼・許可します。$ direnv allow direnv: loading ~/my-project/.envrc direnv: export +FOO +BAR上記のように表示されれば成功です。direnv: export +FOO +BARはFOOとBARが現在のシェル環境に追加されたことを示しています。- 以降は、このディレクトリに
cdで入るたびに自動で.envrcの内容が反映され、環境変数FOOとBARがセットされます。逆にディレクトリを離れる（親ディレクトリに戻る等）と、direnv: unloadingによりそれら変数は自動的にアンロード（解除）されます。
.envrcファイルの構文と例： 基本はシェルスクリプトです。よく用いられるパターンをいくつか紹介します。
- 環境変数を直接エクスポートする:
export API_KEY="abcdef12345" export DEBUG=1単純にキーと値をエクスポートすればOKです。値にスペースやシェルの特殊文字が含まれる場合はクォートしましょう。 - 別ファイルから読み込む: 機密情報を別途
.envファイルに記載し、.envrc側で読み込む方法があります。direnvには.envファイルを読み込むdotenv関数が用意されています。例えば.envrc内でdotenvと書くと同ディレクトリの.envファイルの内容を取り込みます。設定でグローバルに.envの自動ロードを有効にすることも可能です（v2.32以降）。.envrc example dotenv # 同ディレクトリの.envを読み込むexport PATH_add bin # binディレクトリをPATHに追加（後述のstdlib関数）
上記のように書けば、.envファイル（例えばAPIキーなどを含む）をソースしつつ、binディレクトリをPATHに加える設定もできます。 - direnvの標準ライブラリ（stdlib）を活用する: direnvは
.envrc内で使える便利な関数を多数提供しています。例えば、環境変数PATHへのディレクトリ追加にはPATH_add <ディレクトリ名>が使えます。これはexport PATH=$PWD/<dir>:$PATHをより安全に簡潔に書くための関数です。
また、特定の言語やツール用のヘルパーもあります。例としてlayoutという一連の関数があり、layout pythonと書くと現在のディレクトリ用にPythonの仮想環境(venv)を自動生成・有効化します。layout goならGo言語のビルド環境をセットアップする、といった具合です。これらを使うと、.envrcに一行書くだけで面倒な環境構築を自動化できます。
（※標準ライブラリの詳細はdirenv stdlibコマンドや公式manページを参照してください。） - コマンドの実行:
.envrc内では任意のコマンド実行も可能です。ただし実行結果を環境変数に設定する場合はVAR=$(command)のようにシェル文法を用います。例:export AWS_DEFAULT_REGION=$(aws configure get region)これは事前に設定されたAWS CLIのデフォルト地域を環境変数にセットする例です。
.envrcを変更した場合は、内容を更新後に再度 direnv allow を実行する必要があります。direnvはセキュリティのため、ファイル内容が変わると「許可済み」であってもブロックします。毎回許可するのは煩わしく感じるかもしれませんが、プロジェクト外から不意に変更が加えられた場合などに自動実行されないようにする安全策です。
ℹ️ ヒント: 現在のディレクトリでdirenvが有効か確認したい場合、
direnv statusコマンドで.envrcの読み込み状態を確認できます。「loaded」と表示されれば適用済み、許可が必要な場合はその旨が表示されます。.envrcのトラブルシュートに役立つコマンドです。
代表的なユースケース
direnvは様々な場面で活躍します。ここでは実際の開発現場での主なユースケースを紹介します。
- プロジェクト毎に異なる環境変数を自動適用：複数プロジェクトを並行して扱う開発者にとって、プロジェクトA用の環境変数をプロジェクトBで誤って使ってしまうミスは避けたいものです。direnvなら、各プロジェクトディレクトリにそれぞれ
.envrcを置き、例えばAではデータベースURLやAPIエンドポイントを開発用に、Bではそれぞれ別の値に設定しておく、といったことが容易です。ディレクトリを移動するだけで適切な環境変数セットに切り替わるため、開発環境の切り替え漏れによる不具合を防止できます。 - チーム開発での環境設定共有：direnvの設定ファイル
.envrc（またはテンプレートとなる.env.exampleファイル等）をリポジトリに含めておくことで、プロジェクトに新しく参加したメンバーもスムーズに環境構築できます。「このプロジェクトではどんな環境変数が必要か」をドキュメントで伝える代わりに、.envrc自体が生きた構成情報になります。ただし、後述するように機密情報は直接コミットしないよう注意が必要です。必要に応じてダミーの値やテンプレートファイルを用意し、実際の値は各自が.envに記入してもらう運用が望ましいでしょう。 - 機密情報（シークレット）の管理：direnvはセキュリティの観点でも有用です。プロジェクトごとに異なるAPIキーやパスワードなどのシークレットを、各ディレクトリ内でのみ読み込みます。他のプロジェクトに影響を与えず、安全に隔離できます。また、direnv自体はシークレット管理ツールではありませんが、例えば
.envrc内でMozillaのSOPSやgopassと組み合わせて暗号化された秘密情報を復号・エクスポートするような使い方もできます 。必要なときにだけシークレットを環境変数化し、ディレクトリを出れば破棄されるので必要最小限の露出で済むわけです。 - 複数言語・ツールのバージョン切り替え：プロジェクトごとに使うプログラミング言語やツールのバージョンを変えるケースでもdirenvは便利です。例えば、Pythonの仮想環境をプロジェクトディレクトリ内に自動で構築・有効化したり（
layout python）、Node.jsのバージョンをプロジェクトごとに切り替えたりできます。RubyやGo、Javaなどでも、必要なパス（例えば特定SDKのパス）をプロジェクト単位で通すことができます。これにより、プロジェクト間での依存関係の衝突を避け、各プロジェクトが要求する正確なバージョンや設定で動作するよう保証できます。 - 本番・ステージング環境との切り替え：インフラ構築やデプロイの作業でもdirenvは活躍します。たとえばTerraformのIaCプロジェクトでは、AWSのクレデンシャルやTerraform用の環境変数（
TF_VAR_xxxやTF_CLI_ARGSなど）を環境ごとに変える必要があります。direnvを使って環境名ごとのディレクトリを作り、そこにそれぞれ異なるAWS認証情報や設定ファイルを読み込ませることで、アカウントやリージョンの切り替えをスムーズに行えます。「開発用AWSアカウントではdev用の変数セット、本番用ではprodのセット」といった具合に、ディレクトリ移動だけで切り替わるため安全です。
以上のように、direnvはローカル開発からクラウドデプロイまで幅広いシーンで有用です。次章では、安全にdirenvを活用するためのセキュリティ上のポイントを解説します。
セキュリティ考慮事項とベストプラクティス
direnvは便利な反面、扱う内容（環境変数）には機密情報が含まれる場合も多いため、セキュリティに注意した運用が重要です。ここではdirenvを安全に使うためのポイントとベストプラクティスを紹介します。
- 初回許可 (
direnv allow) の意味：direnvは、プロジェクトディレクトリに置かれた.envrcを自動では実行しません。「そのディレクトリの.envrcを本当に実行しても良いか」をユーザーに確認するために、明示的にdirenv allowコマンドを要求します。この仕組みにより、例えば第三者のリポジトリからクローンしてきたプロジェクトに悪意ある.envrcが含まれていても、許可しない限り実行されないため被害を防げます。必ず内容を確認し、信頼できる設定か判断してからdirenv allowするようにしましょう。逆に、実行を取り消したい場合はdirenv denyコマンドで許可をリセットできます。 - 機密情報を直接コミットしない：基本中の基本ですが、APIキーやパスワードなどのシークレット値をそのまま
.envrcに書いてリポジトリにコミットしないようにしましょう。公開リポジトリであれば漏洩につながりますし、プライベートリポジトリでも不要な人に権限が渡れば漏洩し得ます。ベストプラクティスとして、シークレットは.gitignoreされた外部ファイル (.env等) に置き、.envrcからdotenv等で読み込む運用が推奨されます。または、.envrc内でAWS Vaultなどの外部ツールを呼び出して一時的に環境変数を取得する方法も考えられます。 .envrcの共有方針：チームでdirenvを使う場合、.envrcをリポジトリに含めるか否か検討が必要です。一般的には機密情報さえ含まなければ.envrcを共有して問題ありません。しかし、開発者ごとに異なる設定が必要な場合は、.envrcにテンプレート的な内容を書き、各自が適宜修正して使う運用もあります。例えば.envrc内で「存在すれば.local.envrcを読み込む」としておき、個人ごとのオーバーライド設定を.local.envrcに書く、といった柔軟な構成も可能です。direnvは親ディレクトリの.envrcも探査する仕組みがあるため、共通部分と個別部分をファイル分割することもできます。- 平文でのシークレット保存とその代替：
.envrcや.envに平文でシークレットを書きたくない場合、暗号化された値を保存し実行時に復号する方法があります。前述したMozilla SOPSや各種Vaultサービスと組み合わせ、.envrc内で復号コマンドを呼び出して環境変数にエクスポートするのも一手です。direnv自体はその結果を環境に取り込むだけなので、汎用的に利用できます。ポイントは、復号に必要な鍵自体は別途安全に管理することです（例えば個人のPGP鍵やクラウドのKMSを使用）。 - 信頼できないリポジトリでの利用：知らない他人のプロジェクトをクローンして動かす際には、特に
.envrcの内容に注意してください。rm -rf ~/重要フォルダのような悪意あるコマンドを仕込むことも理論上は可能です。direnvはあくまでシェルを自動実行するツールなので、実行前に内容を確認する習慣をつけましょう。同僚の書いた.envrcであっても、思わぬ副作用（例：グローバルな環境変数を上書きするような設定）がないかチェックすると安心です。
以上の点を踏まえてdirenvを運用すれば、大きな事故無く便利さを享受できるでしょう。要は「コードで環境変数を管理する」ことになるので、通常のコードレビューやセキュリティチェックと同様の意識で扱うことが大切です。
応用編: フックと他ツールとの連携
direnvはシンプルな仕組みですが、工夫次第で様々なツールと連携して高度な活用が可能です。ここでは言語バージョン管理ツールとの統合や、Docker／Terraformなど他ツールとの組み合わせによる便利な利用方法を紹介します。
- 言語のバージョン管理ツール（asdf や pyenv など）との統合: direnvは言語ごとのバージョン管理ツールと組み合わせることで強力になります。特に有名なのがasdfとの連携です。【asdf】は複数の言語ランタイムを統一的に管理できるツールですが、
asdf-direnvというプラグインを導入すると、ディレクトリに入った際にそのプロジェクトの必要とする言語バージョンを自動で有効化できます。例えば.tool-versionsファイルに指定された言語（RubyやNodeなど）のバージョンを、direnvがディレクトリ入場時にasdfコマンド経由でセットしてくれる仕組みです。
他にもPythonのvirtualenvとの連携では、.envrcにlayout pythonと書くだけで仮想環境が自動生成・アクティベートされます。プロジェクトフォルダごとに隔離されたPython環境が手に入るため、開発が終わってフォルダを出れば環境変数VIRTUAL_ENVやPATHの変更も消え、グローバル環境は汚れません。Node.jsなら、nvmやvoltaといったツールをdirenv経由で呼び出して自動バージョン切替することも可能です。要するに、direnvをハブにして各種開発ツールの設定を自動化できるのです。 - Docker／コンテナ環境での利用: Dockerコンテナの開発でもdirenvは役立ちます。例えばDocker Composeでは通常
.envファイルで環境変数を定義しますが、開発時にdirenvで.envをロードしておけば、ホスト側シェルで各種コマンドを試す際にも同じ環境変数が使えます。また、Docker上で動かすアプリの設定もdirenvで一元管理できるため、コンテナとホストの環境変数の齟齬を防ぐことができます。
さらに、VS CodeのDev Containersのような開発コンテナ環境でも、コンテナ内部にdirenvを導入しておけばプロジェクトごとに必要な環境変数を自動ロードできます。ホストのdirenv設定とコンテナ内のdirenv設定を共に整えることで、開発者の手元（ホスト）でもCI用コンテナ内でも一貫した環境を実現できます。 - Terraformやクラウドツールとの組み合わせ: 前述したように、インフラ構築コード（IaC）でもdirenvは有用です。特にTerraformではプロジェクトごとに多数の環境変数（認証情報や変数ファイルパスなど）を切り替える必要があり、direnvでそれらを自動化すると効率的です。実例として、あるチームではdirenvを使ってTerraform実行時の変数ファイル(
-var-file)やAWSアカウント情報を自動設定し、AWSアカウントの切り替えや機密変数のロードを透過的に行っています。また、aws-vaultコマンドと組み合わせて、ディレクトリごとに異なるAWS認証を利用する運用もできます。これにより一つのコードベースでマルチアカウント・マルチリージョンを扱う場合でも、direnvが裏で適切な環境をセットアップしてくれるのです。 - その他のフック活用: direnvはシェルごとにフックを仕込む機能だけでなく、ユーザー自身がグローバルな拡張を仕込むことも可能です。
~/.config/direnv/direnvrcというファイルを作成すると、そこに書いた内容が全プロジェクトの.envrcの前に実行されます。たとえば共通で使う関数を定義したり、会社独自の便利コマンド（社内プロキシ設定など）を組み込んだりできます。各開発者が共通のdirenvrcを利用すれば機能を拡張できますが、その内容もまたdirenv allowの管理下にある点には留意してください。
このように、direnvは他ツールとの組み合わせで真価を発揮します。言い換えれば「ディレクトリに入る/出る時に自動でできたら嬉しいこと」は何でもdirenvに任せられるのです。工夫して活用してみてください。
トラブルシューティング: よくある問題と対策
direnv導入後によく遭遇する問題と、その解決策をまとめます。
- 「
direnv: command not foundと表示される: direnvインストール後にこのエラーが出る場合、パスが通っていない可能性があります。インストール方法によっては~/.profileや~/.bash_profileへのパス設定が必要です。Homebrew経由で入れた場合は通常大丈夫ですが、手動でexeを配置した場合は自分で環境変数PATHにディレクトリを追加してください（WindowsならシステムのPATHにexeの場所を登録）。インストールが正しくできているか確認し、which direnvでパスが表示されるかチェックしましょう。 - 環境変数がロードされない／
.envrcが無視される: 考えられる原因はシェルへのフックが機能していないことです。シェル設定ファイルに追記したeval "$(direnv hook ...)"の行が正しく実行されていないと、direnvはディレクトリ移動を検知できません。対策として、シェルを再起動する、設定ファイルをきちんとsourceする、設定行がプロンプト変更の後ろに来ていないか確認する（他の設定の後に置く必要があります）などを試してください。またZshの場合、~/.zprofileではなく~/.zshrcに入れる点にも注意です。direnv statusコマンドを実行すると、direnvフックが有効かどうか確認できます。 - 「
.envrc is not allowedと表示される: これは正常な動作で、direnvが当該ディレクトリの.envrcをまだ信頼していない状態です。対処法はカレントディレクトリでdirenv allowを実行することです。一度許可すれば、次回以降その.envrc（内容が変わらない限り）は自動でロードされます。同様に、.envrcを書き換えた後にも再度direnv allowが必要になる点を思い出してください。逆に、許可済みの.envrcを無効化したい場合はdirenv denyを使います。 - Windows+WSL環境で
.envrcが正しく読まれない: WSLでdirenvを使う場合に稀にあるのが、改行コードの問題です。Windows側で編集した.envrcファイルにCRLF（Windows改行）が含まれていると、bashでの読み込み時に予期せぬ挙動をすることがあります。実際、WSLでdirenvが.envrc内のsource_env_if_existsという関数を無視するように見えたケースでは、ファイルの改行コードをLFに修正することで解決しています。VSCodeで編集する際は改行コード表示に注意し、必要ならdos2unixコマンドでLFに変換してください。 - 環境変数が解除されない／別ディレクトリに影響が残る: 通常direnvはディレクトリを出たときに設定した変数を全て外しますが、もし残ってしまう場合は手動でexportしたものではないか確認してください。例えば、direnvを介さずに一時的に環境変数を上書きしてしまうと、それはdirenv管理外なので解除されません。direnv管理下の変数かどうかは、direnvの出力メッセージ（
direnv: export +VARやdirenv: unloadingで-VARが表示される）で判断できます。また、direnvはサブシェルで動作するためエイリアスやシェル関数はエクスポートできない仕様です。エイリアスが引き継がれないといった現象は仕様によるものなので注意しましょう。
これらのポイントを踏まえれば、大抵の問題は素早く解決できるはずです。それでもうまく動作しない場合は、direnv statusの出力や--verboseオプションを付けてデバッグし、必要なら公式のGitHubリポジトリでIssueを検索してみてください。
CI/CDパイプラインでの利用
開発マシン上ではdirenvは便利ですが、CI/CDの自動化パイプラインにおける扱いも考えてみましょう。結論から言えば、CI環境では必ずしもdirenvを使う必要はありません。なぜならCIジョブ内では、スクリプト中で明示的に環境変数を設定したり、専用の設定機構（GitHub ActionsのシークレットやGitLab CIの変数）を利用するのが一般的だからです。しかしプロジェクトによっては、開発時と同じ.envrcをCIでも利用したいケースもあります。
direnvをCIで活用する方法としては次のようなものがあります：
- direnvのCLIを用いて環境変数をロードする: direnvには対話的シェル以外でも環境を適用するコマンドが用意されています。その一つが
direnv exec <DIR> <COMMAND>です。これは指定したディレクトリの.envrcを読み込んだ環境で任意のコマンドを実行するものです。例えばCIスクリプト内でdirenv exec . terraform planのようにすれば、カレントディレクトリの.envrcを適用した状態でTerraformコマンドを実行できます。
また、direnv export bashを使う方法もあります。これは現在の.envrcから環境変数をエクスポートするためのシェルスクリプト断片を出力します。それをevalすればCIジョブのシェルに環境変数を取り込めます。具体的には:eval "$(direnv export bash)" # これで.envrcの環境変数が現在のシェルに適用される上記をCIのビルドステップ中に実行すれば、以降のステップでプロジェクトと同じ環境変数が使えるようになります。 - シークレット／環境変数の供給: CI上では、安全のためシークレットは通常CIツールの機能で注入します（例えばGitHub ActionsのEncrypted SecretやAWS Parameter Storeなど）。direnvの
.envrcにシークレット読み出し処理を書く場合、CIでもその処理が実行されます。例えば.envrc内でaws-vault exec <profile> -- direnv allowのような処理を入れておけば、CIでもAWS Vault経由で一時クレデンシャルを取得できます。ただし、CI上で自動的にdirenv allowが必要になる点に注意してください（初回は許可がないため）。CI環境はクリーンなマシンなので、事前にdirenv allow相当の操作ができない場合、DIRENV_ALLOW_DIR環境変数を使って許可ファイルをリポジトリと一緒に置いておく裏技もありますが、セキュリティ上あまり推奨はできません。 - 代替策: CI/CDでは、無理にdirenvを使わずとも**.envファイルをロードする**だけで事足りる場合が多いです。開発時はdirenv +
.envrcで快適にしつつ、デプロイやテストのCIでは.envやCI変数を用意しておき、スクリプト内でexport $(cat .env | xargs)のように読み込む運用もシンプルで良いでしょう。direnvで設定している環境変数一覧はdirenv export jsonコマンドでJSON形式で取得できるので、それをCIに渡して環境差分を検討するといった応用も可能です。
まとめると、direnvは主にローカル開発支援ツールであり、CI/CDでは状況に応じて使っても使わなくても良いという立ち位置です。CIではセキュアな変数注入方法が既にあるため、そちらを優先するのが無難です。ただ、開発と本番で環境変数の値に差異が出ないよう、direnvで使っている設定をそのままCIに適用できる仕組みを用意しておくと、本番環境との齟齬を減らせるでしょう。
公式リソースへのリンク
最後に、direnvに関するさらなる情報源として公式リソースを紹介します。
- 公式サイト・ドキュメント: direnv.net – インストール手順や基本的な使い方、FAQなどが掲載されています。特に「Community Wiki」には様々なTipsやレシピがあり、一読の価値があります。
- GitHubリポジトリ: direnv/direnv – GitHub – direnvのソースコードとIssueトラッカー。新機能の議論や不具合報告はこちらで行われています。CHANGELOGやREADMEも公開されています。
- マニュアルページ:
man direnvコマンドや、オンラインマニュアル – コマンド詳細やstdlibの関数一覧が確認できます。 - コミュニティ: Matrix上の公式チャットやGitHub Discussionsがあります。困ったときは質問してみると開発者やユーザーから回答が得られるかもしれません。
公式情報を活用しつつ、ぜひdirenvを使いこなしてみてください。
この記事が気に入ったら
いいね または フォローしてね！
コメント