Posts

結論 npm error code ETARGET は、要求した版が候補の中に無いという意味です。npm が加える説明は1文だけで、「多くの場合、あなたか依存のどれかが存在しない版を要求している」と述べます。 前提として、パッケージ名そのものは見つかっています。名前が見つからない場合は E404 になります。つまり ETARGET が出ている時点で、確認すべきは名前ではなく版です。 読む場所は notarget の1行目です。実装は要求した名前と範囲を組み立てて No matching version found for <名前>@<範囲>. という文を作ります。ここに出ている範囲が、自分が書いたものと一致するかをまず見てください。一致しなければ、要求しているのは自分ではなく依存のどれかです。 もう1つ、この1行目には条件が付くことがあります。時刻による絞り込みが有効な場合、範囲の後ろに with a date before <日時> が加わります。この語句が見えたら、原因は版の指定ではなく絞り込みの設定です。 エラーが発生する処理段階 npm は依存の木を組み立てる過程で、パッケージごとに候補の一覧を取得し、その中から要求に合う1つを選びます。ETARGET はこの選択の段階で出ます。 第一段階は名前の解決です。レジストリから、そのパッケージの全版の情報をまとめた文書を取得します。ここで見つからなければ E404 になります。 第二段階は候補の絞り込みです。時刻による制約が設定されていれば、その日時より後に公開された版を候補から外します。この段階で候補が1つも残らなければ、別のコードが返ります。 第三段階が選択です。残った候補から、要求された範囲やタグに合うものを探します。見つからなければ ETARGET になります。 第四段階は取得です。ここまで来ていれば版は決まっているため、ETARGET は出ません。 つまり ETARGET は、候補の一覧は手に入っているが、その中に該当が無いという状態を指します。ネットワークや認証の問題ではありません。 最初に確認すること まず、notarget の1行目を正確に読みます。 npm error code ETARGET npm error notarget No matching version found for react@^99.0.0. npm error notarget In most cases you or one of your dependencies are requesting npm error notarget a package version that doesn't exist. @ の後ろが、実際に要求されている範囲です。自分の設定ファイルに書いた内容と一致するかを確かめてください。 ...

冒頭まとめ The container name "/web" is already in use を見たとき、動いているコンテナを探しても見つからないことがあります。docker ps に何も出ないのに拒まれる、という状況です。 理由は名前の持ち方にあります。Docker のデーモンは、名前とコンテナ ID の対応を、コンテナ本体とは別の表で管理しています。実装では names という名前の表で、containers の表とは分かれています。名前を確保するのは作成の時点で、その予約を消す処理が呼ばれるのは削除と改名の2か所だけです。 つまり名前は、動いているコンテナが占有しているのではありません。コンテナが存在する限り予約され続けます。停止しても、異常終了しても、作成に失敗して起動前で止まっていても、名前は返りません。docker ps が既定で動いているものだけを表示するため、この食い違いが起きます。 この仕組みが分かると、対処が3つに絞られます。予約しているコンテナを消すか、そのコンテナの名前を変えるか、こちらの名前を変えるかです。強制的に作り直しても、デーモンを再起動しても、原則としてこの3つ以外の道はありません。なお同じコンテナが同じ名前を確保し直す場合は衝突しません。予約の処理は、名前と ID の組が一致していればそのまま通る作りになっています。 もう1つ押さえるべき点があります。名前の一意性はデーモンごとです。ネットワークを分けても、Compose のプロジェクトを分けても、同じデーモンの上なら名前は1つしか使えません。 エラーの概要 出力は次の形です。 docker: Error response from daemon: Conflict. The container name "/web" is already in use by container "e7f8c9a2b1d4...". You have to remove (or rename) that container to be able to reuse that name. 読む場所は2つあります。1つ目は名前の先頭に付いた / です。これは入力の誤りではありません。実装は名前を予約する前に、先頭が / でなければ付け足します。だから表示にも / が現れます。 2つ目は後半のコンテナ ID です。これが予約している当事者で、調査の出発点になります。名前で探しても見つからない場合があるため、この ID で直接照会するのが確実です。 この応答は Docker Engine API では 409 として返ります。名前の衝突以外にも 409 になる場面はあるため、状態コードだけでは区別できません（Docker の 409 エラーの記事）。 ...

冒頭まとめ この記事は設定ミスの記事ではありません。 2026年8月6日から7日にかけて発生した、GitHub 側のサービス障害の記録です。 permissions の見直し、workflow ファイルの書き換え、トークンの再発行、ランナーの再登録——これらを行っても状況は変わりません。原因は利用者側の設定にないためです。 対象期間は、公式の調査開始が日本時間の8月7日 0:22（UTC 8月6日 15:22）、影響の緩和が確認されたのが8月7日 9:05（UTC 0:05）です。本記事の執筆時点で公式の状態は「監視中」であり、正式な解決の宣言はまだ出ていません。最新の状況は公式のインシデントページ（Incident with Actions）で確認してください。 この障害の特徴は、単一のエラー文言では説明できないことです。停止した処理の段階によって、症状がまったく違う形で現れました。「Actions が動かない」という同じ体験でも、どの段階で止まったかによって、取るべき対応が変わります。 何が起きたか：処理段階ごとの症状 公式の更新をもとに、停止した段階ごとに整理します。 処理段階 確認された症状 Webhook の受付 push や pull request がワークフローを作成しない ジョブのキュー queued のまま長時間開始しない、時間切れになる ランナーの割り当て 既に無効になったジョブがランナーへ割り当てられる ジョブの実行 起動に失敗する、途中で失敗する Actions API REST API がエラーを返す、想定外の利用制限がかかる 関連サービス Pages、Copilot のレビューとエージェント、Enterprise Importer の遅延や失敗 とくに重要なのが1行目です。公式の説明によれば、復旧を助けるために webhook の起点が意図的に絞られていました。一時は全体の約15%しか処理されていない状態です。 つまり、push しても何も起きない、pull request を作ってもワークフローの一覧に何も現れない、という状況が発生していました。利用者から見れば「自分の設定が壊れた」ようにしか見えませんが、実際には復旧のための措置です。この段階で workflow ファイルを触っても、何も変わりません。 3行目も特徴的です。公式は途中で「既に有効でないジョブがランナーへ割り当てられている」問題を特定したと発表しています。GitHub 側が用意するランナーと、自前で用意するランナーの両方が影響を受けました。 利用者側の問題との見分け方 以下の兆候が複数当てはまる場合、原因は自分の設定ではありません。 ワークフローそのものが作成されない。特定のジョブが失敗するのではなく、実行が始まらないのが特徴です。 複数のリポジトリで同時に発生している。設定はリポジトリごとに独立しているため、同時発生は外部要因を示します。 GitHub 側のランナーと自前のランナーの両方で失敗している。この2つは実行環境が別なので、片方だけの設定問題では説明できません。 設定を変更していないワークフローまで失敗している。 Actions API や Pages など、Actions 以外にも同時に症状が出ている。 公式のステータスページにインシデントが掲載されている。 逆に、特定のジョブや特定の API 操作だけが再現性をもって失敗する場合は、利用者側の問題です。とくに Resource not accessible by integration のように権限を示す文言が特定の操作で必ず出るなら、そちらを調べてください（GitHub の Resource not accessible by integration の記事）。 ...

冒頭まとめ GH013: Repository rule violations found を検索すると、秘密情報が混ざったときの対処が数多く出てきます。それは3系統あるうちの1つにすぎません。GH013 は ruleset（リポジトリに設定された規則の集まり）に違反したという符号で、中身はブランチやタグへの規則、push そのものへの規則、そして秘密情報の検知に分かれます。 見分ける手がかりは、符号のすぐ下に出ます。GitHub は Review all repository rules at に続けて、そのブランチに効いている規則の一覧を示すURL を返します。公式ドキュメントによれば、この一覧は読み取り権限さえあれば誰でも見られます。管理者に問い合わせる前に、まずここを開けば済みます。 もう1つ、bypass（規則を素通りする許可）についての誤解があります。bypass はアカウントに与える権限ではありません。ruleset は push のたびに、そのとき使われた資格情報の持ち主を bypass 一覧と照合します。だから自分を一覧に入れても、CI が別の身元で push していれば拒まれます。手元では通るのに自動処理では落ちる、という報告のほとんどはこれです。 branch protection との違いも押さえてください。公式ドキュメントは、branch protection の制限が既定では管理権限を持つ人に適用されないと明記しています。ruleset は逆で、bypass 一覧に載せない限り誰も素通りできません。管理者だから通るはずだ、という前提はここで崩れます。 エラーの概要 出力は次の形になります。実際に報告された表示です。 remote: error: GH013: Repository rule violations found for refs/heads/main. remote: Review all repository rules at http://github.com/OWNER/REPO/rules?ref=refs/heads/main remote: remote: - Changes must be made through a pull request. To https://github.com/OWNER/REPO ! [remote rejected] main -> main (push declined due to repository rule violations) error: failed to push some refs to 'https://github.com/OWNER/REPO' 読む場所は2つです。1つ目は Review all repository rules at のURL で、対象のブランチに効いている規則がすべて並びます。2つ目はその下の箇条書きで、実際に違反した規則の名前が入ります。 ...

冒頭まとめ git の Repository not found は必ず2行で出ますが、その2行は書き手が違います。1行目は GitHub のサーバーが返したレスポンス本文を git がそのまま転記したもので、2行目は git 自身の判断です。書き手を分けて読むと、原因の範囲が一度に絞れます。 決め手は2行目です。git の実装では、fatal: repository '...' not found は HTTP 404 を受け取ったときにしか出ません（remote-curl.c の分岐と http.h の missing__target）。一方、2026年8月7日の実測では、GitHub は未認証のリクエストに 404 ではなく 401 を返しました。この2行が並んだ時点で、認証そのものは成功していて、そのトークンや鍵の持ち主にリポジトリが見えていない、という一点に絞られます。 ここで、よくある誤解が2つ崩れます。綴りの見直しは優先順位が下がります。GitHub は所有者名とリポジトリ名を大文字小文字の違いを無視して解決するため、OCTOCAT/HELLO-WORLD でも通りました（実測で 200）。改名や移管を疑う必要もほとんどありません。旧パスへの git clone・git fetch・git push は新しい場所への操作として動き続ける、と公式ドキュメントが明記しています。 最初に確定させるべきなのは、いま自分がどのアカウントとして GitHub と通信しているかです。HTTPS なら保存済みの資格情報、SSH なら提示している鍵が、その入口になります。 エラーの概要 HTTPS で出る場合、ログは次のようになります。GitHub Actions 上の実際の報告では、git の終了コードは 128 でした。 remote: Repository not found. fatal: repository 'https://github.com/OWNER/REPO.git/' not found URL 末尾のスラッシュは入力の誤りではありません。git は通信前に end_url_with_slash() で末尾を揃えており、揃えた後の値を表示しているだけです。ここを直しても何も変わりません。 SSH の場合は文言が変わります。 ERROR: Repository not found. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 1行目の ERROR: は GitHub の SSH サーバーが出したものです。2行目以降は git の connect.c にある die_initial_contact() の文言で、相手がプロトコルの応答を1つも返さずに接続を閉じると出ます。SSH に HTTP のステータスコードはないため、判断材料はこの1行だけです。 ...

冒頭まとめ Invalid for_each argument が拒む理由は3系統です。apply の後でないと決まらない値、map でも文字列の集合でもない値、機密の印が付いた値。別々の制限に見えますが、由来は1つです。 for_each に渡した値は、最終的に文字列をキーとする対応表へ変換されます。そしてそのキーが、そのままインスタンスのアドレスになります。公式ドキュメントは、Terraform がインスタンスを map のキーまたは集合の要素で識別すること、アドレスが <種別>.<名前>[<キー>] の形になることを明記しています。aws_iam_user.the-accounts["Todd"] の角括弧の中身が、渡した値から来ているという意味です。 アドレスには3つの条件が要ります。計画の時点で確定していること、並び順に左右されないこと、画面と記録に平文で出せることです。未確定値は1つ目を、list は2つ目を、機密値は3つ目を満たしません。制限を1つずつ避けようとすると行き詰まりますが、キーの条件として捉えると3つとも同じ方向で解けます。 つまりこのエラーは、値の書き方を咎めているのではありません。インスタンスの名前として使えない値が渡された、と言っています。直す先は式ではなく、何をキーにするかという設計です。 エラーの概要 出力は3つの部分でできています。先頭の要約、対象の位置、そして理由を述べる本文です。次は実際に報告された表示です。 Error: Invalid for_each argument on .terraform/modules/aks_primary/resource-tls.tf line 7, in resource "tls_private_key" "this": 7: for_each = var.ssh_key == null ? { "key" = {} } : {} ├──────────────── │ var.ssh_key has a sensitive value Sensitive values, or values derived from sensitive values, cannot be used as for_each arguments. If used, the sensitive value could be exposed as a resource instance key. 罫線の部分は補助情報で、式の中のどの変数が問題なのかを示します。ここに名前が出ていれば、追う対象はその変数です。 ...

冒頭まとめ 同じ Pod を見ているのに、表示が ErrImagePull になったり ImagePullBackOff になったりする。この入れ替わりを原因の変化だと受け取ると、調べる方向を誤ります。 2つは原因の違いではありません。同じ失敗を、時間軸の別の地点から呼んだ名前です。kubelet は取得を求められると、まず待機の途中かどうかを確かめます。待機中なら取得を行わず ImagePullBackOff を返します。待機が明けていれば実際に取得を試み、失敗したときに ErrImagePull を返します。つまり前者は次の試行を待っている時間帯、後者は試して失敗した瞬間です。 したがって、どちらが表示されているかは原因を何も語りません。実際、この入れ替わりは利用者にとって分かりにくいと開発側も認めており、待機中の表示に前回の失敗理由を残す変更が v1.32 で入りました。 もう1つ、名前そのものの意味も押さえてください。ErrImagePull は取得失敗の総称ではありません。実装はレジストリに届かない場合と署名の検証に失敗した場合を先に切り分け、そのどちらでもない残り全部を ErrImagePull にしています。分類できなかった、という意味の名前です。 だから原因は名前ではなくメッセージ本文にあります。実際に取得を試みた瞬間に出る警告のイベントだけが、コンテナの実行基盤が返した文言をそのまま載せています。ここを取り逃がすと、手がかりが無くなります。 エラーの概要 kubectl describe pod のイベントは、失敗が続くと次の並びになります。 Normal Pulling 2m kubelet Pulling image "example.com/app:v1" Warning Failed 2m kubelet Failed to pull image "example.com/app:v1": rpc error: code = NotFound desc = ... Warning Failed 2m kubelet Error: ErrImagePull Normal BackOff 95s kubelet Back-off pulling image "example.com/app:v1" Warning Failed 95s kubelet Error: ImagePullBackOff Failed という理由が2行出ますが、意味が違います。1行目は実際に取得を試みて返ってきた文言で、原因はここにしかありません。2行目は状態の名前を告げているだけです。この違いは実装の作りから来ています。取得の失敗は Failed to pull image %q: %v の形で記録され、状態の名前は別の箇所から Error: %v の形で記録されます。 ...

冒頭まとめ PVC（PersistentVolumeClaim、ストレージの割り当てを求めるオブジェクト）が Pending のままになったとき、まず容量や設定ファイルを読み返す人が多くいます。順序としては後回しでかまいません。先に読むべきなのは kubectl describe pvc の Events に出る Reason の1語です。 理由は実装にあります。Kubernetes の制御側は、未結合の要求を1か所で3つの経路に振り分けています。結合を遅らせる設定で誰も使っていない場合、クラス名が指定されていて動的な作成に進む場合、そのどちらでもない場合です。この3分岐がそのまま Reason になるため、Reason を見れば自分がどの経路にいるかが確定します。 分かれ方は5通りです。WaitForFirstConsumer と WaitForPodScheduled は待機、ExternalProvisioning と ProvisioningFailed は動的な作成、FailedBinding は既存の領域との突き合わせで、それぞれ直す場所が違います。 最も見落とされるのが2番目です。WaitForPodScheduled が出ているなら、待たせているのは PVC ではありません。それを使う Pod が配置できずに止まっています。PVC の定義を読み直しても原因は出てきません。 WaitForFirstConsumer も異常ではありません。公式ドキュメントは、この設定が Pod ができるまで結合と作成を意図的に遅らせるものだと説明しています。Pending の表示だけを見て設定を書き換えると、かえって配置できない Pod を作ることになります。 エラーの概要 一覧では、状態が Pending のまま止まり、割り当て先の欄が空になります。 NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE data-pvc Pending standard 6m41s この Pending は、実装では要求の段階を表す3つの値のうちの1つです。Pending（まだ結合されていない）、Bound（結合済み）、Lost（結合していた領域が失われた）の3つが定義されています。つまり Pending 自体は失敗ではなく、結合がまだ済んでいないという事実だけを示します。 理由は Events に出ます。表示例は次のようになります。 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal WaitForFirstConsumer 20s (x6 over 87s) persistentvolume-controller waiting for first consumer to be created before binding 出所は persistentvolume-controller です。このコードは未結合の要求を3つに振り分けます。第一に、結合を遅らせる設定で、まだ配置の判断が渡ってきていない場合。第二に、クラス名が空でない場合。第三に、そのどちらでもない場合です。1番目からは WaitForFirstConsumer または WaitForPodScheduled、2番目からは ExternalProvisioning・ProvisioningFailed・ProvisioningSucceeded、3番目からは FailedBinding が出ます。 ...

冒頭まとめ npm install が ERESOLVE で止まったら、まずログの Found: と、その下の peer が要求する版を比べる。パッケージ本体と、それを利用するプラグインなどの要求が合わず、npmが依存関係を配置できない場合に起きる。 npm error code ERESOLVE npm error ERESOLVE unable to resolve dependency tree could not resolve と表示される場合もある。古いnpmでは接頭辞が npm ERR! になる。文言の違いだけで対処を変える必要はない。 基本の対処は、競合する両側を互換性のある版に揃えること。--legacy-peer-deps はpeerの要求を無視する回避策であり、--force はさらに広い保護を外す。インストール完了だけでは動作確認にならない。 Foundとpeerの要求を読み比べる peer dependencyは、プラグインなどが利用側に求めるパッケージと版の条件を表す。たとえば次は説明用の例である。 Found: host-lib@2.0.0 Could not resolve dependency: peer host-lib@"^1.0.0" from plugin-lib@1.0.0 host-lib@2.0.0 は ^1.0.0 を満たさない。plugin-libを2系のhostに対応した版へ変えるか、host側を1系へ揃える必要がある。 表示 読み取る内容 While resolving: 解決中のプロジェクトやパッケージ。必ずしも競合元そのものではない Found: 解決中のツリーで使おうとしている版。既にインストール済みとは限らない peer ... from ... 要求されるパッケージ・範囲と、その要求を出したパッケージ Conflicting peer dependency: 競合するpeerを満たす候補。これを単独で入れれば直るとは限らない ログにレポートのパスが表示されたら、そのファイルも読む。保存先はnpmの版や設定で変わるため、~/.npm/eresolve-report.txtに固定しない。 npm/cli Issue #6476には、npm 9.5.1・Node.js 18.16.0での実例がある。rootがcommonを1.0.6に固定する一方、解決されたdecoratorsがcommonの1.0.8以上を要求していた。投稿者がcoreを1.0.6へ固定していても、そのpeer範囲から別パッケージの1.0.8が選ばれていた。これは過去の報告であり、現在のnpm全般に同じ不具合があると示すものではない。 ...

結論 npm ERR! code EACCES は、OS が書き込みや読み取りを拒んだという意味です。npm 自身の判断ではなく、システムコールが返した値がそのままコードになっています。 重要なのは、npm がこのエラーに対して2種類の文面を用意している点です。実装では、失敗した経路または書き込み先がキャッシュの置き場から始まっていて、かつ Windows でない場合にだけ、キャッシュの所有者を直す案内を出します。それ以外は、OS に拒まれたという汎用の文面になります。 つまり文面を読めば、直す対象が二分できます。キャッシュの所有者の話なのか、書き込み先そのものの権限の話なのか、という分かれ方です。 sudo を付けて回避するのは勧められません。多くの場合、それが次回以降の失敗の原因を作ります。root で作られたファイルがキャッシュに残り、通常の利用者では触れなくなるためです。 エラーが発生する処理段階 npm の処理は大きく3段階に分かれます。どの段階で拒まれたかで、疑う場所が変わります。 第一段階はキャッシュへの読み書きです。取得したパッケージの内容はキャッシュの置き場に保存されます。既定の場所は、POSIX 系が ~/.npm、Windows が %LocalAppData%\npm-cache です。 第二段階は導入先への展開です。通常の導入なら作業ディレクトリの node_modules、全体向けの導入なら prefix の下です。公式の説明によれば、全体向けの導入ではパッケージが {prefix}/lib/node_modules に置かれ、実行ファイルが {prefix}/bin に、説明書が {prefix}/share/man にそれぞれ結び付けられます。 第三段階は導入後のスクリプト実行です。ここで失敗する場合、拒まれているのは npm ではなくスクリプトが触ろうとした場所です。 npm ERR! path と npm ERR! syscall の2行が、どの段階かを教えてくれます。 最初に確認すること まず、拒まれた経路と操作を出力から読み取ります。 npm ERR! code EACCES npm ERR! syscall mkdir npm ERR! path /usr/local/lib/node_modules/typescript npm ERR! errno -13 npm ERR! Error: EACCES: permission denied, mkdir '/usr/local/lib/node_modules/typescript' path がどこを指しているかで、次に見る場所が決まります。キャッシュの置き場の下なら原因1、prefix の下なら原因2、作業ディレクトリの下なら原因3です。 ...