このページでは、Google Cloud Platform（GCP）の利用時によく出るエラーと、その対処の考え方をまとめます。認証・権限（IAM）やSSH接続、課金・割り当て（Quota）、APIの有効化、ネットワークなど、つまずきやすいポイントを「カテゴリ別の入口」として整理し、個別の詳しい解説は子記事へ案内します。まずは全体像を押さえ、遭遇しているエラーがどのカテゴリに属するかを見極めることから始めてください。

この記事の要点

GCPのエラーは大きく「認証・権限（IAM）」「SSH接続」「課金・割り当て（Quota）」「API有効化」「ネットワーク」などに分類できます。 多くのエラーは エラーメッセージ自体に原因のヒント（呼び出し元・不足している権限・対象リソース）が含まれています。まずメッセージを丁寧に読むことが近道です。 HTTP 403 系のエラーは、権限不足だけでなく「APIが無効」「割り当て超過」「組織ポリシーによるブロック」など複数の原因がありえます。 SSHで Permission denied (publickey). が出る場合は、子記事 SSHでPermission denied (publickey). に詳しい対処をまとめています。 調査では、エラーメッセージでの検索と Cloud Logging での確認が基本になります。具体的な数値・仕様は公式ドキュメントで最新を確認してください（本記事は2026年時点の一般的な整理です）。

このページの位置づけ

GCPは多数のサービス（Compute Engine、Cloud Storage、IAM、VPC など）が連携して動くため、同じ「権限がない」「接続できない」という症状でも、原因の置き場所はサービスや設定によってさまざまです。このページは、それらを横断的に見渡すための目次・入口として用意しています。個別のエラーについては、該当する子記事や公式ドキュメントへリンクしていきます。

「どのカテゴリのエラーか分からない」という段階の方は、まず次の一覧表で当たりをつけてください。

よくあるエラーのカテゴリ

GCPで遭遇しやすいエラーを、カテゴリ・代表的なメッセージ例・主な対処の方向性で整理します。下表は一般的な傾向をまとめたもので、実際の原因はメッセージ全文やプロジェクト設定によって異なります。

カテゴリ	代表的なエラー例	主な対処の方向性
認証・権限（IAM）	PERMISSION_DENIED / HTTP 403 「caller does not have permission」	操作している主体（ユーザー／サービスアカウント）を確認し、必要なIAMロール（権限）が適切なスコープ（プロジェクト・フォルダ・組織）で付与されているかを見直します。権限付与の反映には時間差が生じる場合があります。
SSH接続	Permission denied (publickey). 接続タイムアウト	SSH鍵やOS Loginの設定、ファイアウォール（22番ポート）などを確認します。詳細は子記事を参照してください（後述）。
課金・割り当て（Quota）	QUOTA_EXCEEDED / RATE_LIMIT_EXCEEDED HTTP 403（割り当て関連）	該当リソースの割り当て（Quota）使用状況を確認し、必要に応じて割り当ての引き上げ申請を行います。請求先アカウントが有効・連携済みかも確認します。
API有効化	SERVICE_DISABLED 「API has not been used / is disabled」（HTTP 403）	利用しようとしているサービスのAPIが、対象プロジェクトで有効化されているかを確認し、無効なら有効化します。有効化直後は反映に少し時間がかかることがあります。
ネットワーク	接続不可 / タイムアウト 到達不能・拒否	VPCのファイアウォールルール、サブネット、ルート、外部IPの有無などを確認します。対象ポートが許可されているか、送信元レンジが適切かを点検します。
リソース・状態	NOT_FOUND / ALREADY_EXISTS 「リソースが見つからない／競合」	対象リソースの名前・リージョン・プロジェクトが正しいかを確認します。別プロジェクトを参照していないか、削除済みでないかも点検します。

SSHエラーの詳細（子記事）

SSH接続まわりは原因が多岐にわたるため、別記事に切り出しています。代表的な Permission denied (publickey). については、原因の切り分けと具体的な対処を次の記事にまとめています。

• SSHでPermission denied (publickey). — 鍵認証で接続が拒否される場合の確認手順

このページはあくまで入口です。SSH固有の詳しい手順は子記事側を参照し、本ページでは「どのカテゴリの問題か」を判断する用途に使ってください。

エラー調査の基本

カテゴリの当たりがついたら、次の基本ステップで原因を絞り込みます。GCPに限らず有効な進め方ですが、特に最初の2点は効果が大きいです。

• エラーメッセージを全文読む・検索する： GCPのエラーは、呼び出し元・不足している権限・対象リソースなどの手がかりを含むことが多くあります。要約せず、メッセージ全文（エラーコードや権限名を含む）をそのまま検索すると、公式ドキュメントや事例に行き当たりやすくなります。
• Cloud Logging を確認する： 操作に対応するログを Cloud Logging（ログエクスプローラ） で確認すると、API単位の失敗理由やステータスを追えます。いつ・どの主体が・何をして失敗したかを時系列で把握できます。
• 対象を正しく指定しているか確認する： プロジェクトID・リージョン／ゾーン・リソース名の取り違えは頻出です。意図したプロジェクトに対して操作しているかを最初に確認します。
• 公式ドキュメントで最新仕様を確認する： 割り当ての上限値やエラーコードの細かな挙動は変わりうるため、具体的な数値や手順は公式ドキュメントで最新情報を確認してください。

補足：403エラーは「権限不足」とは限らない
HTTP 403 はIAMの権限不足を連想しがちですが、GCPでは「APIが無効（SERVICE_DISABLED）」「割り当て超過（QUOTA_EXCEEDED）」「組織ポリシーによるブロック」なども403で返ることがあります。403を見たら権限付与に走る前に、まずメッセージ本文の理由コードを確認するのが安全です。

よくある質問（FAQ）

Q. 「PERMISSION_DENIED（403）」が出ました。まず何を見ればよいですか？
A. メッセージ本文の理由を確認します。SERVICE_DISABLED ならAPIの有効化、割り当て関連なら割り当て状況、純粋な権限不足なら「操作している主体」と「付与済みのIAMロール／スコープ」を見直します。権限を追加した直後は反映に時間がかかることがあります。

Q. SSHでつながりません。このページで解決できますか？
A. このページはカテゴリの入口です。Permission denied (publickey). の具体的な対処は子記事 SSHでPermission denied (publickey). にまとめています。接続タイムアウト系はネットワーク（ファイアウォールの22番ポートなど）を疑ってください。

Q. 割り当て（Quota）を超えたと言われました。どうすればよいですか？
A. まず該当リソースの割り当て使用状況を確認します。一時的なものでなければ、割り当ての引き上げを申請します。上限値や申請手順、反映までの時間は変わりうるため、公式ドキュメントで最新の手順を確認してください。

具体的なエラーコードの挙動や数値は2026年時点での一般的な整理です。最終的な確認は、必ずGoogle Cloud公式ドキュメントの該当ページで行ってください。