Codexで依存関係を準備する
公開 2026-09-14 更新 2026-09-18

関連テーマ:変更を調べ、試して確かめる
「必要なパッケージを入れてください」と表示されても、すぐに最新版を追加すると、元のプロジェクトと違う構成になることがあります。依存関係とは、そのアプリが動くために必要な別のライブラリやツールです。ここでは既存のNode.js・npmプロジェクトを例に、Codexへ準備を頼む前後の確認を整理します。
Codex本体の導入手順ではありません。CLIの導入が終わっていても、開いたプロジェクトの準備は別に必要なことがあります。
最初に読む三つのもの
| 確認するもの | 調べる内容 |
|---|---|
| README | 推奨するNode.jsの版、準備と起動の順番 |
| package.json | 必要なパッケージ、scripts、enginesなどの指定 |
| ロックファイル | プロジェクトで決めた依存関係の構成 |
package-lock.jsonはnpm、pnpm-lock.yamlはpnpmなど、使う管理ツールの手掛かりになります。複数がある場合は勝手に一つを削除せず、READMEやCIの設定で実際の運用を確認します。まずプロジェクトの構成を読む段階で調べましょう。
このプロジェクトの準備方法を調べてください。
README、package.json、ロックファイル、CIの定義を根拠に、
使用するツールと版、実行場所、準備・確認コマンドを整理します。
まだインストール、更新、ロックファイルの書き換えは行いません。
資料同士が矛盾する場合は、その箇所を報告してください。
この依頼で得たいのは「何をどこで実行するか」の確認です。ファイルを読めたことを、インストールや起動の成功とは区別します。
npm installとnpm ciを使い分ける
npm installは依存関係の追加や更新にも使われ、実行条件によってロックファイルが変わります。既存のnpmプロジェクトで、整合するロックファイルから構成を再現したい場合にはnpm ciが候補です。
npm ciには既存のpackage-lock.jsonまたはnpm-shrinkwrap.jsonが必要です。package.jsonとの不一致を自動で直す操作ではなく、不一致ならエラーで止まります。既存のnode_modulesを削除して入れ直すため、そこへ手作業の修正や保存物を置いていないか確認します。package.jsonやロックファイル自体は書き換えません。npm ciの公式説明
ロック作成時の設定によって同じオプションが必要になる場合もあります。エラーが出たからといってロックを消したり、--forceを足したりせず、元の準備方法と失敗理由を照合します。
各段階で確認してから、次の操作へ進みます。
- 1読むREADME・設定・ロックを照合
- 2準備する対象と影響を確認して実行
- 3確かめる依存関係と検査と起動を分ける
具体的な依頼と、結果の確かめ方は本文にあります。
先に決められた準備方法を読み、変更対象を確認して実行し、最後に結果を確かめます。最新版へ更新する作業は、既存構成の準備と分けて依頼します。
実行してよい範囲を決める
インストールはファイルを増減させ、パッケージの取得やスクリプト実行を伴う場合があります。信頼できるプロジェクトの、指定した作業フォルダーで行います。知らないリポジトリなら、まずコピーや隔離環境で内容を調べます。
確認したREADMEの準備手順を、このプロジェクト内で実行してください。
先にGit差分と既存の未保存作業を確認します。
依存関係の最新版への更新や、グローバルインストールは対象外です。
ロックファイルが不整合なら書き換えず、エラーと根拠を報告してください。
実行コマンド、終了コード、変更ファイルを記録してください。
管理ツールのスクリプト設定は版によって異なります。--ignore-scriptsを使う場合も、必要な準備処理が省かれて動かないことがあるため、「安全も起動も保証する万能設定」とは考えません。実行が必要な処理をREADMEやパッケージの内容から確認します。
入ったことと動いたことを別々に確認する
まず実行したコマンドの終了コードとエラーを確認します。次に、npmプロジェクトなら作業フォルダーで次のように直接の依存関係を表示できます。
npm ls --depth=0
missingやinvalidなどが報告されていないかを確認します。表示が正常でも、アプリ全体の動作を確認したことにはなりません。npm lsの公式説明
続けてnpm runでscriptsの一覧を見て、READMEに指定された検査を実行します。checkという名前が存在すると確認できた場合にだけ、npm run checkを使います。プロジェクトによってはtestやbuild、別の名前です。
準備の結果を次の三段階で報告してください。
1. 依存関係のインストール:コマンドと終了コード
2. プロジェクトの検査:実行した検査と結果
3. アプリの起動:実際に確認した場合だけURLや画面を記録
未実行は未実行とし、秘密の設定値や認証情報は表示しません。
失敗したら最初のエラーへ戻る
| 症状 | 次に確認すること |
|---|---|
| npmが見つからない | 対象のNode.js・npmがそのターミナルで使えるか |
| ロックが一致しない | package.jsonとロックの変更履歴、正しいブランチ |
| 認証・接続エラー | 取得先と権限、ネットワーク。トークンは共有しない |
| インストール成功後に検査失敗 | 準備処理、実行環境、検査の最初のエラー |
失敗時に無関係なパッケージを足す前に、エラーの伝え方で実行場所・コマンド・エラーをそろえます。設定値が必要な場合は環境変数の確認へ進めます。
やり直す場合は、作業前の差分と今回の変更を照合します。無差別なGitリセットで元からあった作業を消さず、今回変更した設定だけを戻します。インストール先の再構築と、ソースコードの復元も別の操作です。
本稿は公式仕様と説明用の依頼例です。読者のプロジェクトのインストール、Codexモデルによる実行、個別アプリの起動を検証したものではありません。
依存関係を準備した後は、npmの実行コマンドの確認で検査や起動の入口を調べられます。
このテーマを続けて読む
不具合修正、テスト、コード整理、ブランチで変更の結果を確認します。
変更を調べ、試して確かめるの記事をまとめて見る