npm ciとnpm installの違い｜CIとローカルで使い分ける判断基準

npm ciとnpm installは、どちらも依存パッケージ（プログラムが動くために必要な部品）を入れるコマンドですが、目的が違います。結論は、**依存関係を追加・変更するローカル開発ではnpm install、確定した依存関係をCI（継続的インテグレーション＝変更のたびに自動で検査する仕組み）で再現するならnpm ci**が基本です。この記事では、npm公式・GitHub公式・Node.js公式のドキュメントを根拠に、判断基準と失敗時の確認順を整理します。

npm ciとnpm installの違いを比較表で確認する

npm installは、パッケージを導入し、依存関係の定義を更新するコマンドです。パッケージ名を指定すれば、通常はpackage.jsonとpackage-lock.jsonへ反映されます。引数なしで実行した場合は、package.jsonとlockfile（ロックファイル＝依存関係の記録簿）を照合して、プロジェクトの依存関係を導入します（npm CLI公式「npm install」）。

npm ciは、CIやデプロイなど、自動環境でクリーンに依存関係を入れるためのコマンドです。npm公式は、既存のpackage-lock.jsonまたはnpm-shrinkwrap.jsonが必須であること、package.jsonと一致しない場合はlockfileを更新せずエラー終了すること、開始前に既存のnode_modulesを自動削除すること、package.jsonとlockfileには書き込まないことを明記しています（npm CLI公式「npm ci」）。

比較項目	npm install	npm ci
主な目的	依存関係を導入・追加・更新する	lockfileの内容をクリーンに導入する
lockfile	なくても実行でき、必要に応じて生成・更新する	package-lock.jsonまたはnpm-shrinkwrap.jsonが必須
package.jsonとの不一致	package.jsonを優先して解決し、lockfileを更新する	lockfileを更新せずエラー終了する
既存のnode_modules	差分を考慮して導入する	開始前に自動削除する
個別パッケージの追加	できる	できない
設定ファイルへの書き込み	実行内容に応じて行う	package.jsonとlockfileには書き込まない
主な利用場所	ローカル開発	CI、クリーンな再現確認、デプロイ前

1つ注意があります。npm ciは既存のnode_modulesを自動で消してから入れ直すため、node_modulesの中を手で直していた場合、その変更は残りません。手修正自体を避けるのが基本ですが、実行前に「消えて困るものがないか」を確認してください。

package.jsonとpackage-lock.jsonの役割を分けて理解する

判断の中心は2つのファイルの役割分担です。

• package.jsonは「許容するバージョンの範囲」を書くファイルです。たとえば"^1.2.0"は「1.2.0以上、2.0.0未満ならどれでもよい」という意味です。
• package-lock.jsonは「実際に解決した正確な依存ツリー（間接依存まで含めた全部品の一覧）」を記録するファイルです。npm公式は、後続のインストールで同じツリーを再現できるようにするためのファイルであり、ソース管理（git）へ含めることを意図していると説明しています（npm CLI公式「package-lock.json」）。

npm installは、lockfileに記録された版がpackage.jsonの範囲を満たすなら、その正確な版を使います。範囲を満たさない場合はpackage.jsonを優先して再解決し、lockfileを更新します。一方npm ciは更新しません。不一致なら直さずに失敗します。つまり、npm installは依存関係を整える側、npm ciはその結果を厳密に使う側です。

ローカル開発でnpm installを使うのは、主に次の3つの場面です。

1. 新しいパッケージを追加する（npm install <名前>）
2. package.jsonを手で変更した直後に、lockfileを同期する（引数なしのnpm install）
3. AIにコード変更を頼んだ後、依存関係が変わっていないか確認する

どの場面でも、実行後にpackage.jsonとpackage-lock.jsonの両方の差分を確認してください。頼んでいないのに大量の行が変わっていたら、採用する前に理由を調べます。

もう1つ大事な注意があります。lockfileが同じでも、実行環境まで同じとは限りません。package-lock.jsonにはパッケージが制約を指定した場合にOSやCPUの情報が記録される項目があり、環境によって入る部品が変わり得ます。Node.js・npmの版、環境変数、npm設定が違えば、結果や挙動に差が出る可能性があります。npm設定は、プロジェクト直下の.npmrc（npmの設定ファイル）に書けばそのプロジェクト固有の設定として全員へ効かせられます（npm CLI公式「.npmrc」）。

CIでnpm ciを使う理由とGitHub Actionsの最小例

CIでは、開発者のPCに残った状態ではなく、リポジトリの内容だけからテストやビルドを再現します。npm ciならnode_modulesをクリーンにし、lockfileを変更せずインストールできるので、「package.jsonだけ変更してlockfileを更新し忘れた」というずれをCIの段階で検出できます。

GitHub公式は、setup-nodeでNode.jsの版を指定し、npm ci、ビルド、テストを順に実行する形を案内しています（GitHub公式「Building and testing Node.js」）。最小例は次のとおりです。

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: '22'
      cache: 'npm'
  - name: 依存関係をインストール
    run: npm ci
  - name: ビルド
    run: npm run build
  - name: テスト
    run: npm test

3つ補足します。

• Node.jsの版は必ず明示します。 指定しないと実行環境の既定版が使われ、環境が変わると結果も変わり得ます。setup-nodeのREADMEも、システムの版に依存せずnode-versionを常に指定することを推奨しています（setup-node公式README）。どの版を選ぶかは、本番向けにはActive LTSまたはMaintenance LTS（長期サポート版）を使うようNode.js公式が案内しています（Node.js公式リリース一覧）。対象の版番号は時期で変わるので、公開時点の公式リリース表で確認してください。
• cache: 'npm'はnpm ciの代わりではありません。 このキャッシュはlockfileのハッシュをキーに使う「npmのグローバルパッケージデータ」のキャッシュで、node_modules自体はキャッシュしないと公式READMEに明記されています。ダウンロードを速くする補助であり、インストール工程そのものはnpm ciが担います。
• 速度は断定しません。 npm公式ページには154パッケージの例でnpm installが10秒、npm ciが5秒という記載がありますが、これは一例です。依存の数、キャッシュ、ネットワークで変わるため、自分のCIで同じ条件で計測してください。上の@v4などActionの版も更新され得るので、掲載時点の公式案内で確認してください。

依存インストールとビルド・テストを別ステップに分けておくと、失敗がどちらの問題かを切り分けられます。CIで記事サイトを検品する具体例はGitHub Actionsで記事サイトを自動検品する方法も参考にしてください。

npm ciが失敗したときの確認順

失敗時に、いきなりpackage-lock.jsonを削除するのはやめてください。lockfileの再生成は依存ツリー全体が変わり得る操作です。次の順で確認します。

1. 最初に表示されたエラーの全文を読む（2つ目以降のエラーは1つ目の巻き添えのことが多い）
2. package.jsonとpackage-lock.jsonの差分を確認する
3. lockfileを作った環境とCIのNode.js・npmの版を比べる（node -vとnpm -v）
4. .npmrcと実行時フラグを比べる
5. ローカルでもnpm ciを実行して、同じエラーが出るか再現する
6. ここまでで原因を特定できた場合に限り、lockfileの再生成を検討し、変更されたパッケージとテスト結果を確認する

4番は見落としやすいポイントです。--legacy-peer-depsや--install-linksなど依存ツリーへ影響するフラグ付きでlockfileを作った場合、npm ciにも同じ設定が必要です。npm公式は、こうした設定をプロジェクトの.npmrcへ書いてリポジトリに含める方法を案内しています。

調査をAIへ頼む場合は、次の材料をまとめて渡すと一往復で済みやすくなります。

• 実行したコマンド
• 最初のエラーの全文
• package.jsonとpackage-lock.json
• Node.js・npmの版（ローカルとCIの両方）
• .npmrcの中身
• CI設定ファイルの該当ステップ

渡し方の型はCodexへの依頼テンプレートも利用できます。

よくある質問

npm ciはローカルPCでも使えますか？

使えます。CIの失敗を、既存のnode_modulesの影響なしで手元で再現したいときに向いています。ただし実行前にnode_modulesが自動削除されるため、その中の手修正は残りません。

package-lock.jsonがない場合にnpm ciは使えますか？

使えません。package-lock.jsonまたはnpm-shrinkwrap.jsonが必要です。ローカルでnpm installを実行してlockfileを生成し、内容を確認してからpackage.jsonとともにソース管理へ含めてください。

npm ciでpackage-lock.jsonは更新されますか？

更新されません。package.jsonとlockfileの依存関係が一致しない場合も、自動修正せずエラー終了します。依存関係を変更する工程ではnpm installを使い、両ファイルの差分を確認します。

npm ciは必ずnpm installより速いですか？

必ず速いとは言えません。npm公式には154パッケージでnpm installが10秒、npm ciが5秒という例がありますが、これは例示です。依存パッケージ数、キャッシュ、ネットワーク、インストールスクリプトで変わるため、同じ実行環境・同じNode.js・npmの版・同じキャッシュ条件で計測してください。

npm ciでdevDependenciesもインストールされますか？

設定しだいです。npm公式によると、omit（除外設定）の既定は空ですが、環境変数NODE_ENVがproductionのときは既定がdevになり、devDependencies（開発用の依存）はディスクへ入りません。CIのテストやビルドに開発用依存が必要なら、NODE_ENVとomit・includeの設定を確認してください。

まとめ

迷ったときの早見表です。

場面	選ぶコマンド	理由
新しいパッケージを追加する	npm install <名前>	package.jsonとlockfileを更新するため
package.jsonを直した直後	まずnpm install	lockfileを同期し、差分を確認するため
GitHub Actionsでテストする	npm ci	保存済みの依存関係をクリーンに再現するため
CIの失敗をローカルで再現する	npm ci	既存node_modulesの影響を減らすため

次にやることは3つです。

• 依存関係を変えるときはローカルでnpm installを実行し、package.jsonとpackage-lock.jsonの両方の差分を確認してからコミットする
• CIではsetup-nodeでNode.jsの版を明示し、npm ci→ビルド→テストの順にステップを分ける
• npm ciが失敗したら、lockfileを消す前に本記事の確認順1〜6をたどる。AIに調査を頼むときは材料6点をまとめて渡し、導入後はAI生成コードの検品チェックリストで変更内容と合格条件を記録する

公式一次情報

確認日: 2026-07-26

• npm CLI公式「npm ci」: lockfileの必須条件、不一致時のエラー終了、node_modulesの自動削除、フラグとomit設定の注意、154パッケージの速度例
• npm CLI公式「npm install」: パッケージの追加、引数なし実行時のpackage.jsonとlockfileの照合、再解決とlockfile更新の条件
• npm CLI公式「package-lock.json」: lockfileの生成目的、記録される依存ツリー、os・cpuの記録項目、ソース管理へ含める理由
• npm CLI公式「.npmrc」: npm設定の読み込み順と、プロジェクト直下の.npmrcがプロジェクト固有の設定を与えること
• GitHub公式「Building and testing Node.js」: setup-nodeでNode.js版を指定しnpm ci・ビルド・テストを順に実行する公式例、版未指定時の挙動
• setup-node公式README: node-versionを常に指定する推奨、npmキャッシュの対象がグローバルパッケージデータでnode_modulesではないこと
• Node.js公式リリース一覧: リリース段階の説明と、本番ではActive LTSまたはMaintenance LTSを使う案内