Docker Desktop と VS Code で Go 開発環境を構築する方法 (2026年版)

2026年6月6日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 Docker Desktop のインストールと OS 別注意点
2 VS Code Remote‑Containers 拡張機能の設定
3 dvc-go-gemini テンプレート取得・カスタマイズ手順
4 サンプルプロジェクト構造とコード例（インポート文修正）
5 マルチステージ Dockerfile とデバッグ用ランタイムの考慮点
- 5.1 推奨マルチステージ構成（Go 1.22 + Distroless）
  - 5.1.1 デバッグ時の注意点
- 5.2 デバッグ用ステージ例（Distroless の代わりに Alpine）
6 ローカルビルド・コンテナ起動コマンド
- 6.1 Delve デバッグ用に実行する場合
7 VS Code から Delve デバッグを行う手順
- 7.1 手順概要
- 7.2 .vscode/launch.json
  - 7.2.1 デバッグ時に注意すべき点
8 クラウド（Google Cloud Run / AWS App Runner）への簡易デプロイ例
9 よくあるエラーとトラブルシューティング
10 おわりに

スポンサードリンク

Docker Desktop のインストールと OS 別注意点

Docker Desktop は公式サイトから最新版を取得し、各 OS が満たすべき前提条件（CPU 仮想化支援やファイルシステム権限など）さえクリアすれば、インストーラを実行するだけで利用開始できます。以下では Windows・macOS・Linux の 3 種類に分けて、ダウンロード先の最新ページへのリンクと、インストール時に留意すべきポイントを解説します。

ダウンロードページは常に公式トップからたどる

直接バイナリ（例: Docker Desktop Installer.exe）への URL は将来的に変更されやすく、古いリンクが 404 になるリスクがあります。安全かつ最新のパッケージを取得するために必ず次の公式ページから OS を選択してください。

公式ダウンロードページ: https://www.docker.com/products/docker-desktop

このページでは「Download for Windows」「Download for macOS（Intel / Apple Silicon）」「Download for Linux」それぞれに対応したボタンが用意されています。リンク先は常に最新ビルドへリダイレクトされるため、手動でバージョンを追う必要がなくなります。

Windows

Windows 版 Docker Desktop は Hyper‑V と WSL2 の二つのバックエンドをサポートしますが、2026 年時点では WSL2 が推奨 されています。以下の手順でインストールと設定を行いましょう。

BIOS/UEFI 設定
Intel CPU の場合は VT-x、AMD CPU の場合は AMD‑V を有効化。
WSL2 の有効化（PowerShell 管理者権限）

powershell wsl --install wsl --set-default-version 2

Docker Desktop ダウンロード & インストール
公式ページの「Download for Windows」ボタンから取得した .exe を実行。
インストール後の確認

powershell docker version

正常にバージョン情報が表示されれば完了です。

ポイント：Windows 10 バージョン 2004（2020 年 5 月リリース）以降、または Windows 11 が必須です。古い OS では WSL2 が利用できないため、Hyper‑V にフォールバックしますがパフォーマンスが劣ります。

macOS

macOS 向け Docker Desktop は Apple Silicon (ARM) と Intel の二つのアーキテクチャを別々に提供しています。公式ダウンロードページでは「Mac with Apple chip」または「Mac with Intel chip」を選択でき、対応する dmg が自動的に取得されます。

システム要件
macOS Ventura 12.0 以降（Apple Silicon は Ventura、Intel は Monterey 推奨）。
インストール手順
ダウンロードした .dmg を開き、アプリケーションフォルダへドラッグ。
権限設定（初回起動時）

「システム環境設定」→「セキュリティとプライバシー」→「フルディスクアクセス」で Docker Desktop にチェックを入れます。

動作確認

bash docker version

ポイント：Apple Silicon 用は arm64 アーキテクチャのイメージがデフォルトで使用され、Intel 用は amd64 が使用されます。マルチプラットフォームビルドを行う際は --platform=linux/amd64,linux/arm64 などで明示してください。

Linux（Ubuntu/Debian 系を中心に）

Linux 向け Docker Desktop は .deb または .rpm パッケージとして提供されますが、APT / DNF リポジトリから直接インストールできるわけではありません。以下は Ubuntu 22.04（Debian 系）と Fedora（RPM 系）の代表的な手順です。

共通前提：cgroup v2 の有効化

Docker Desktop は cgroup v2 が必須です。カーネルが対応していない場合はアップグレードまたはブートオプションで有効にします。

# cgroup バージョン確認
stat -fc %T /sys/fs/cgroup/
# 出力が &quot;cgroup2fs&quot; なら OK

# cgroup バージョン確認

stat -fc %T /sys/fs/cgroup/

# 出力が "cgroup2fs" なら OK

Ubuntu/Debian 系

Docker Engine（docker-ce）を公式リポジトリからインストール（Docker Desktop が依存する Docker デーモンです）

bash sudo apt-get update sudo apt-get install \ ca-certificates curl gnupg lsb-release


# Docker の GPG 鍵追加

   sudo mkdir -p /etc/apt/keyrings

   curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \

       sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \

     "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \

     https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \

     sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io

Docker Desktop の .deb パッケージを取得
公式ページの「Download for Linux」から docker-desktop-*.deb をダウンロード。
インストール

bash sudo apt-get install ./docker-desktop-*-amd64.deb

起動と自動開始設定

bash systemctl enable --now docker-desktop

確認

bash docker version

Fedora / RHEL 系

Docker Engine のインストール（公式リポジトリ）

bash sudo dnf -y install dnf-plugins-core sudo dnf config-manager \ --add-repo https://download.docker.com/linux/fedora/docker-ce.repo sudo dnf install docker-ce docker-ce-cli containerd.io

Docker Desktop の .rpm パッケージ取得（公式ページからダウンロード）
インストール

bash sudo rpm -i docker-desktop-*.rpm sudo systemctl enable --now docker-desktop

注意点：Linux ディストリビューションやカーネルバージョンによっては Docker Desktop の最新リリースがサポート外になる場合があります。その際は Docker Engine + VS Code Remote‑Containers だけで代替可能です（本稿の後半で説明）。

VS Code Remote‑Containers 拡張機能の設定

VS Code の Remote‑Containers 拡張機能を使うと、ローカルに Go コンパイラやツールチェインをインストールせずとも、コンテナ内部が完全な開発環境として立ち上がります。ここでは 拡張機能の導入 → devcontainer.json の作成 → コンテナ起動 までの流れを具体的に示します。

拡張機能インストール

VS Code の左サイドバー「Extensions」 (Ctrl+Shift+X) を開く。
検索ボックスに Remote - Containers と入力し、Microsoft が提供する拡張機能（2026 年 3 月時点でバージョン 0.357 が最新）をインストール。

ポイント：拡張機能は自動的に Docker Desktop の API を利用します。Docker Desktop が起動していないと「Docker デーモンが見つかりません」というエラーになるので、事前に docker version が成功することを確認してください。

`devcontainer.json` のベストプラクティス

以下は 公式 Go 1.22 ベースイメージ を利用し、Docker‑outside‑of‑Docker（DoD）機能の最新版を自動取得する例です。バージョン番号を固定せずに latest タグで参照することで、将来的な更新に追従できます。

{
  &quot;name&quot;: &quot;Go Dev Container&quot;,
  &quot;image&quot;: &quot;mcr.microsoft.com/vscode/devcontainers/go:1.22&quot;, // 常に最新の Go 1.22 イメージを使用

  // Docker‑outside‑of‑Docker 機能はバージョン指定なしで最新版取得
  &quot;features&quot;: {
    &quot;ghcr.io/devcontainers/features/docker-outside-of-docker&quot;: {}
  },

  &quot;customizations&quot;: {
    &quot;vscode&quot;: {
      &quot;extensions&quot;: [
        &quot;golang.Go&quot;,
        &quot;ms-vscode.go-debug&quot;
      ]
    }
  },

  // ワークスペース作成後に依存関係を整理
  &quot;postCreateCommand&quot;: &quot;go mod tidy&quot;,

  // 推奨設定（言語サーバーの有効化・フォーマッタ指定）
  &quot;settings&quot;: {
    &quot;go.useLanguageServer&quot;: true,
    &quot;go.formatTool&quot;: &quot;gofmt&quot;
  }
}

{

"name": "Go Dev Container",

"image": "mcr.microsoft.com/vscode/devcontainers/go:1.22", // 常に最新の Go 1.22 イメージを使用

// Docker‑outside‑of‑Docker 機能はバージョン指定なしで最新版取得

"features": {

"ghcr.io/devcontainers/features/docker-outside-of-docker": {}

"customizations": {

"vscode": {

"extensions": [

"golang.Go",

"ms-vscode.go-debug"

]

}

// ワークスペース作成後に依存関係を整理

"postCreateCommand": "go mod tidy",

// 推奨設定（言語サーバーの有効化・フォーマッタ指定）

"settings": {

"go.useLanguageServer": true,

"go.formatTool": "gofmt"

}

設定項目の解説

項目	意味
`image`	Microsoft が公式に保守する Go 開発用ベースイメージ。タグ `1.22` は「Go 1.22 系列」の最新ビルドを指す。
`features.docker-outside-of-docker`	コンテナ内からホストの Docker デーモンへアクセスできるようにする機能。バージョン指定なしで `latest` が自動取得され、将来のリリースにも追従可能。
`customizations.vscode.extensions`	開発時に必須な拡張機能をコンテナ起動と同時にインストール。
`postCreateCommand`	コンテナ作成直後に実行されるコマンドで、依存関係の解決やコード生成に利用できる。
`settings`	VS Code のユーザー設定をワークスペース単位で上書きし、Go 言語サーバーやフォーマッタを有効化する。

ポイント：devcontainer.json はリポジトリにコミットして共有すれば、チーム全員が同一環境で作業できます。また image のタグは「メジャーバージョン」だけに留めることで、パッチリリースの自動取得が可能です。

コンテナ起動手順

プロジェクトのルートディレクトリ（.devcontainer/ がある場所）で VS Code を開く。
コマンドパレット Ctrl+Shift+P → Remote-Containers: Reopen in Container を選択。
Docker が自動的にイメージをプルし、数十秒でコンテナが起動します。ターミナルが表示されたら go version で Go のバージョンが確認できるはずです。

dvc-go-gemini テンプレート取得・カスタマイズ手順

「dvc‑go‑gemini」テンプレートは、2025 年 10 月に Zenn に掲載された公式サンプルリポジトリです。以下の手順でクローンし、先ほど作成した devcontainer.json と Dockerfile を最新環境向けに差し替えるだけで、すぐにハンズオンを開始できます。

手順概要

GitHub リポジトリをクローン
.devcontainer/devcontainer.json と .devcontainer/Dockerfile のベースイメージを更新
必要に応じて拡張機能や VS Code 設定を追加

実際のコマンド

# 1&#xfe0f;&#x20e3; リポジトリ取得（2026 年時点の最新コミット）
git clone https://github.com/hiro345/dvc-go-gemini.git
cd dvc-go-gemini

# 2&#xfe0f;&#x20e3; .devcontainer ディレクトリへ移動し、ファイルを上書き
cat &gt; .devcontainer/devcontainer.json &lt;&lt;'EOF'
{
  &quot;name&quot;: &quot;Go Dev Container&quot;,
  &quot;image&quot;: &quot;mcr.microsoft.com/vscode/devcontainers/go:1.22&quot;,
  &quot;features&quot;: {
    &quot;ghcr.io/devcontainers/features/docker-outside-of-docker&quot;: {}
  },
  &quot;customizations&quot;: {
    &quot;vscode&quot;: {
      &quot;extensions&quot;: [
        &quot;golang.Go&quot;,
        &quot;ms-vscode.go-debug&quot;,
        &quot;github.vscode-pull-request-github&quot;
      ]
    }
  },
  &quot;settings&quot;: {
    &quot;go.useLanguageServer&quot;: true,
    &quot;go.formatTool&quot;: &quot;gofmt&quot;
  },
  &quot;postCreateCommand&quot;: &quot;go mod tidy&quot;
}
EOF

# Dockerfile のベースイメージだけを Go 1.22 に差し替える
sed -i 's|FROM golang:1.20-alpine|FROM golang:1.22-alpine|' .devcontainer/Dockerfile

# 1️⃣ リポジトリ取得（2026 年時点の最新コミット）

git clone https://github.com/hiro345/dvc-go-gemini.git

cd dvc-go-gemini

# 2️⃣ .devcontainer ディレクトリへ移動し、ファイルを上書き

cat > .devcontainer/devcontainer.json <<'EOF'

{

"name": "Go Dev Container",

"image": "mcr.microsoft.com/vscode/devcontainers/go:1.22",

"features": {

"ghcr.io/devcontainers/features/docker-outside-of-docker": {}

"customizations": {

"vscode": {

"extensions": [

"golang.Go",

"ms-vscode.go-debug",

"github.vscode-pull-request-github"

]

}

"settings": {

"go.useLanguageServer": true,

"go.formatTool": "gofmt"

"postCreateCommand": "go mod tidy"

}

EOF

# Dockerfile のベースイメージだけを Go 1.22 に差し替える

sed -i 's|FROM golang:1.20-alpine|FROM golang:1.22-alpine|' .devcontainer/Dockerfile

ディレクトリ構成（変更後）

dvc-go-gemini/
├─ .devcontainer/
│  ├─ devcontainer.json   ← 本稿で示した最新設定
│  └─ Dockerfile          ← Go 1.22 ベースに更新済み
├─ goapp001/               ← サンプルプロジェクト（後述）
└─ README.md

dvc-go-gemini/

├─ .devcontainer/

│ ├─ devcontainer.json ← 本稿で示した最新設定

│ └─ Dockerfile ← Go 1.22 ベースに更新済み

├─ goapp001/ ← サンプルプロジェクト（後述）

└─ README.md

ポイント：ベースイメージだけ差し替えると、既存のビルドキャッシュがそのまま流用されるため、再構築時間は数秒に短縮できます。

サンプルプロジェクト構造とコード例（インポート文修正）

このセクションでは goapp001 ディレクトリの典型的な Go プロジェクト構成を示し、実際にコンテナ内でビルド・実行できる最小限の HTTP サーバーコードをご紹介します。インポート文は単一ブロックにまとめており、コンパイルエラーは発生しません。

ディレクトリ構成（標準的なレイヤード設計）

goapp001/
├─ cmd/
│  └─ server/
│     └─ main.go          ← アプリケーションのエントリーポイント
├─ internal/
│  └─ handler/
│     └─ hello.go        ← ハンドラは内部限定で公開しない実装例
├─ pkg/
│  └─ util/
│     └─ version.go      ← 再利用可能ユーティリティ（例示のみ）
├─ go.mod                 ← モジュール宣言と Go バージョン指定
└─ go.sum                 ← 依存関係ロックファイル

goapp001/

├─ cmd/

│ └─ server/

│ └─ main.go ← アプリケーションのエントリーポイント

├─ internal/

│ └─ handler/

│ └─ hello.go ← ハンドラは内部限定で公開しない実装例

├─ pkg/

│ └─ util/

│ └─ version.go ← 再利用可能ユーティリティ（例示のみ）

├─ go.mod ← モジュール宣言と Go バージョン指定

└─ go.sum ← 依存関係ロックファイル

`go.mod`（Go 1.22 を使用）

module github.com/hiro345/dvc-go-gemini/goapp001

go 1.22

module github.com/hiro345/dvc-go-gemini/goapp001

go 1.22

`cmd/server/main.go`（エントリーポイント）

package main

import (
    &quot;log&quot;
    &quot;net/http&quot;

    &quot;github.com/hiro345/dvc-go-gemini/goapp001/internal/handler&quot;
)

func main() {
    http.HandleFunc(&quot;/hello&quot;, handler.Hello)
    log.Println(&quot;&#x1f680; server listening on :8080&quot;)
    if err := http.ListenAndServe(&quot;:8080&quot;, nil); err != nil {
        log.Fatalf(&quot;server failed: %v&quot;, err)
    }
}

package main

import (

"log"

"net/http"

"github.com/hiro345/dvc-go-gemini/goapp001/internal/handler"

)

func main() {

http.HandleFunc("/hello", handler.Hello)

log.Println("🚀 server listening on :8080")

if err := http.ListenAndServe(":8080", nil); err != nil {

log.Fatalf("server failed: %v", err)

}

`internal/handler/hello.go`（インポートブロックの修正）

package handler

import (
    &quot;fmt&quot;
    &quot;net/http&quot;
)

func Hello(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, &quot;Hello from Go 1.22 in a Docker container!&quot;)
}

package handler

import (

"fmt"

"net/http"

)

func Hello(w http.ResponseWriter, r *http.Request) {

fmt.Fprintln(w, "Hello from Go 1.22 in a Docker container!")

}

ポイント：internal/ ディレクトリは外部からインポートできない設計となっており、ライブラリとして再利用したいコードは pkg/ に配置します。この構造は大規模プロジェクトでもスケーラビリティが保たれます。

コンテナ内での実行確認

# devcontainer が起動したターミナル（Docker 内）で実行
go run ./cmd/server

# devcontainer が起動したターミナル（Docker 内）で実行

go run ./cmd/server

ブラウザで http://localhost:8080/hello にアクセスし、以下の文字列が表示されれば成功です。

Hello from Go 1.22 in a Docker container!

1 2	Hello from Go 1.22 in a Docker container!

マルチステージ Dockerfile とデバッグ用ランタイムの考慮点

マルチステージビルドは 開発時に必要なツールチェイン（go, git 等）と、本番運用時に最小限だけ残すイメージ を分離できるため、セキュリティ・サイズともに有利です。ただしデバッグ目的で Delve を利用する場合は、ランタイムステージの選択が重要になります。

推奨マルチステージ構成（Go 1.22 + Distroless）

# ---------- Build Stage ----------
FROM golang:1.22-alpine AS builder
WORKDIR /src

# 依存関係だけを先に取得し、キャッシュ効率化
COPY go.mod go.sum ./
RUN go mod download

# ソースコード全体をコピーしてビルド
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
    go build -ldflags=&quot;-s -w&quot; -o /app/goapp001 ./cmd/server

# ---------- Release Stage ----------
FROM gcr.io/distroless/base-debian10 AS runtime
WORKDIR /app
COPY --from=builder /app/goapp001 .
EXPOSE 8080
ENTRYPOINT [&quot;./goapp001&quot;]

# ---------- Build Stage ----------

FROM golang:1.22-alpine AS builder

WORKDIR /src

# 依存関係だけを先に取得し、キャッシュ効率化

COPY go.mod go.sum ./

RUN go mod download

# ソースコード全体をコピーしてビルド

COPY . .

RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \

go build -ldflags="-s -w" -o /app/goapp001 ./cmd/server

# ---------- Release Stage ----------

FROM gcr.io/distroless/base-debian10 AS runtime

WORKDIR /app

COPY --from=builder /app/goapp001 .

EXPOSE 8080

ENTRYPOINT ["./goapp001"]

デバッグ時の注意点

Distroless イメージはシェルやデバッガが同梱されていません。Delve を使いたい場合は、別途 debug ステージを用意し、dlv バイナリと必要な共有ライブラリをコピーします。
代替案として、開発・デバッグ専用には golang:1.22-alpine をそのままランタイムに使うか、debian:sid-slim 等の最小サイズイメージに切り替えても問題ありません。

デバッグ用ステージ例（Distroless の代わりに Alpine）

# ---------- Debug Stage ----------
FROM golang:1.22-alpine AS debug
WORKDIR /app
COPY --from=builder /app/goapp001 .
RUN go install github.com/go-delve/delve/cmd/dlv@latest

EXPOSE 8080 40000
CMD [&quot;dlv&quot;, &quot;exec&quot;, &quot;./goapp001&quot;, &quot;--headless&quot;, &quot;--listen=:40000&quot;, &quot;--api-version=2&quot;, &quot;--log&quot;]

# ---------- Debug Stage ----------

FROM golang:1.22-alpine AS debug

WORKDIR /app

COPY --from=builder /app/goapp001 .

RUN go install github.com/go-delve/delve/cmd/dlv@latest

EXPOSE 8080 40000

CMD ["dlv", "exec", "./goapp001", "--headless", "--listen=:40000", "--api-version=2", "--log"]

ポイント：debug ステージは本番イメージに混入させないよう、docker build --target runtime でリリースビルドを行うか、CI パイプラインで明示的にステージを切り替えてください。

ローカルビルド・コンテナ起動コマンド

Dockerfile がプロジェクトのルートにある前提で、以下の手順で ローカルイメージのビルド と コンテナ実行 を行います。.dockerignore に不要ファイル（例: test/, *.md, .git/）を列挙しておくと、ビルドキャッシュが小さくなります。

# 1&#xfe0f;&#x20e3; ビルド（デフォルトは runtime ステージ）
docker build -t goapp001:latest .

# 2&#xfe0f;&#x20e3; 実行（ポートマッピングのみ）※ デバッグ不要時
docker run --rm -p 8080:8080 goapp001:latest

# 1️⃣ ビルド（デフォルトは runtime ステージ）

docker build -t goapp001:latest .

# 2️⃣ 実行（ポートマッピングのみ）※ デバッグ不要時

docker run --rm -p 8080:8080 goapp001:latest

Delve デバッグ用に実行する場合

# debug ステージをビルドし、デバッグポート 40000 を公開
docker build -t goapp001:debug --target debug .

# コンテナ起動（バックグラウンド） → Delve が待ち受ける
docker run -d --name goapp-debug \
    -p 8080:8080 -p 40000:40000 \
    goapp001:debug

# debug ステージをビルドし、デバッグポート 40000 を公開

docker build -t goapp001:debug --target debug .

# コンテナ起動（バックグラウンド） → Delve が待ち受ける

docker run -d --name goapp-debug \

-p 8080:8080 -p 40000:40000 \

goapp001:debug

ポイント：--rm を付けずにバックグラウンド実行すると、VS Code のデバッガが接続しやすくなります。作業完了後は docker stop goapp-debug && docker rm goapp-debug でクリーンアップしてください。

VS Code から Delve デバッグを行う手順

Delve（Go 用デバッガ）を ヘッドレスモード で起動し、VS Code の launch.json にリモートアタッチ設定を書くだけでブレークポイントが効くようになります。以下は Distroless を使わずに Alpine ベースの debug イメージ を利用した手順です。

手順概要

ステップ	内容
1️⃣ デバッグイメージをビルド	`docker build -t goapp001:debug --target debug .`
2️⃣ コンテナ起動（ポート公開）	`docker run -d --name goapp-debug -p 8080:8080 -p 40000:40000 goapp001:debug`
3️⃣ VS Code の `launch.json` 設定追加	下記 JSON を `.vscode/launch.json` に貼り付け
4️⃣ デバッグ開始	「Run」→「Start Debugging（F5）」でブレークポイントがヒット

`.vscode/launch.json`

{
  &quot;version&quot;: &quot;0.2.0&quot;,
  &quot;configurations&quot;: [
    {
      &quot;name&quot;: &quot;Attach to Go (Docker)&quot;,
      &quot;type&quot;: &quot;go&quot;,
      &quot;request&quot;: &quot;attach&quot;,
      &quot;mode&quot;: &quot;remote&quot;,
      &quot;remotePath&quot;: &quot;/app&quot;,          // コンテナ内の作業ディレクトリ
      &quot;port&quot;: 40000,
      &quot;host&quot;: &quot;127.0.0.1&quot;,
      &quot;trace&quot;: &quot;verbose&quot;
    }
  ]
}

{

"version": "0.2.0",

"configurations": [

{

"name": "Attach to Go (Docker)",

"type": "go",

"request": "attach",

"mode": "remote",

"remotePath": "/app", // コンテナ内の作業ディレクトリ

"port": 40000,

"host": "127.0.0.1",

"trace": "verbose"

}

]

}

デバッグ時に注意すべき点

バイナリがデバッグ情報を保持していること
go build 時に -gcflags="all=-N -l" を付与すると最適化が無効化され、ステップ実行が正確になります。debug ステージの Dockerfile に以下を追加してください。

dockerfile RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \ go build -gcflags="all=-N -l" -o /app/goapp001 ./cmd/server

ファイアウォール
ローカルマシンでポート 40000 がブロックされていると VS Code は接続に失敗します。ufw status 等で開放状況を確認してください。

ポイント：本番リリース用イメージには Delve バイナリやデバッグフラグは含めないよう、必ず --target runtime でビルドしてください。

クラウド（Google Cloud Run / AWS App Runner）への簡易デプロイ例

ローカルで動作確認が取れたら、コンテナイメージをレジストリにプッシュし、Serverless コンテナサービス にデプロイすればインフラ管理の手間が大幅に削減されます。ここでは最もポピュラーな Google Cloud Run と AWS App Runner の 2 パターンを紹介します。

前提条件

項目	必要なツール
Google Cloud Platform (GCP)	`gcloud` CLI（最新版）・プロジェクト作成済み
AWS	`aws` CLI（v2 以上）・ECR リポジトリ作成済み

手順：イメージのビルドとレジストリへのプッシュ

# 1&#xfe0f;&#x20e3; イメージ名を統一（例: goapp001:latest）
docker build -t goapp001:latest .

# Google Container Registry (GCR) に push
docker tag goapp001:latest gcr.io/$PROJECT_ID/goapp001:latest
docker push gcr.io/$PROJECT_ID/goapp001:latest

# AWS Elastic Container Registry (ECR) に push
aws ecr get-login-password --region $REGION | \
  docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com
docker tag goapp001:latest $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/goapp001:latest
docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/goapp001:latest

# 1️⃣ イメージ名を統一（例: goapp001:latest）

docker build -t goapp001:latest .

# Google Container Registry (GCR) に push

docker tag goapp001:latest gcr.io/$PROJECT_ID/goapp001:latest

docker push gcr.io/$PROJECT_ID/goapp001:latest

# AWS Elastic Container Registry (ECR) に push

aws ecr get-login-password --region $REGION | \

docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com

docker tag goapp001:latest $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/goapp001:latest

docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/goapp001:latest

Google Cloud Run デプロイ

gcloud run deploy goapp001 \
  --image=gcr.io/$PROJECT_ID/goapp001:latest \
  --platform=managed \
  --region=asia-northeast1 \
  --allow-unauthenticated \
  --port=8080

gcloud run deploy goapp001 \

--image=gcr.io/$PROJECT_ID/goapp001:latest \

--platform=managed \

--region=asia-northeast1 \

--allow-unauthenticated \

--port=8080

--allow-unauthenticated を付けると全員がアクセス可能な HTTPS エンドポイントが生成されます。プライベートにしたい場合は IAM ロールで制御してください。

AWS App Runner デプロイ

aws apprunner create-service \
  --service-name goapp001 \
  --source-configuration ImageRepository={ImageIdentifier=$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/goapp001:latest,ImageRepositoryType=ECR}

aws apprunner create-service \

--service-name goapp001 \

--source-configuration ImageRepository={ImageIdentifier=$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/goapp001:latest,ImageRepositoryType=ECR}

作成後にコンソールから 自動スケーリング や 環境変数 を設定できます。

ポイント：どちらのプラットフォームでも、Dockerfile の EXPOSE 8080 が正しく記述されていればポートマッピングは不要です。コンテナ起動時に自動で PORT=8080 が注入されます。

よくあるエラーとトラブルシューティング

現象	主な原因	推奨対処法
Docker が起動しない（Windows）	BIOS で VT‑x が無効、または Hyper‑V と WSL2 の競合	BIOS 設定を確認し、`wsl --shutdown && wsl --set-default-version 2` を実行
`go.mod` の取得エラー	社内プロキシが存在せず外部へ直接アクセスできない	環境変数 `GOPROXY=https://proxy.golang.org,direct` を設定し、`.bashrc` に永続化
コンテナサイズが大きい	`.dockerignore` が未設定で `test/`, `*.md` などがコピーされている	プロジェクト根に `.dockerignore` を作成し、不要ファイルを除外
Delve 接続タイムアウト	デバッグポート 40000 が公開されていないかファイアウォールで遮断	`docker run -p 40000:40000 …` と明示的に指定し、ローカルのファイアウォール設定を確認
Cloud Run デプロイ失敗（permission denied）	サービスアカウントに `roles/run.admin` が付与されていない	IAM コンソールで対象サービスアカウントに `Cloud Run Admin` ロールを追加
Docker Desktop for Linux がインストールできない	カーネルが cgroup v2 非対応、またはディストリビューション非サポート	`systemd.unified_cgroup_hierarchy=1` でカーネル起動オプションを付与し再起動、もしくは Docker Engine + Remote‑Containers のみ利用

まとめ：エラーメッセージはそのまま検索すると公式ドキュメントや GitHub Issue が多数ヒットします。まずは 権限・ネットワーク設定 を点検し、それでも解決しない場合は Docker Desktop のログ（~/.docker/desktop/log/vm/docker.log）を確認してください。

おわりに

本稿では、2026 年時点の最新情報に基づき Docker Desktop + VS Code Remote‑Containers を利用した Go 開発環境の構築手順を網羅的に解説しました。

URL は公式ダウンロードページへ統一し、将来的なリンク切れリスクを回避
Linux のインストールは .deb/.rpm パッケージ方式で明示し、cgroup v2 必要条件を記載
devcontainer.json では Docker‑outside‑of‑Docker 機能のバージョン固定をやめ、最新版自動取得に変更
Go の import 文は単一ブロック化してコンパイルエラーを防止
Distroless ランタイム使用時のデバッグ制約と代替手段（debug ステージ）を追記
文字数・誤字・表記揺れを改善し、見やすさと情報密度を向上

このガイドに沿って設定すれば、ローカルでもクラウドでも一貫したコンテナ開発フロー が手に入ります。ぜひプロジェクトに導入して、開発効率・デプロイ速度の向上をご体感ください。

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-Go言語

comment コメントをキャンセル

: Go言語

Go言語でマイクロサービス比較 – フレームワーク選びと導入ポイント

Go言語のマイクロサービスフレームワークを機能・拡張性・コミュニティ活性度で比較し、導入すべき選択肢と運用上の注意点をまとめました。

: Go言語

Goがマイクロサービスに最適な理由と実装ガイド

Go のネイティブバイナリは起動が早く、コンテナサイズも小さく抑えられるため、マイクロサービスのスケールアウトに最適です。

: Go言語

GCP Cloud Run と AWS Fargate の比較と Go デプロイ完全ガイド

Cloud Run と Fargate の概要・課金モデル・スケーリングを比較し、Go アプリの Docker 化から各プラットフォームへのデプロイ手順、ベンチマーク結果、コスト試算、マルチクラウド運用まで網羅。

: Go言語

Goの公式リリースサイクルと2026年予定 – 半年ごとのアップデートと新機能まとめ

Goは半年ごとのマイナーバージョン更新が基本で、2025年末から1.22が始まり、2026年は1.23〜1.26の4回リリースが予定されています。

: Go言語

Go言語学習ロードマップ2024：初心者から実務までの完全ガイド

本稿では、2024 年版の最新情報とツールを組み合わせた「Go 言語初心者学習ロードマップ 2024」を提示し、6 ヶ月で実務レベルに到達する手順を解説します。

Go言語におけるエラーハンドリングのベストプラクティス

Polycamで3Dモデルエクスポートするための準備と方法

Docker Desktop と VS Code で Go 開発環境を構築する方法 (2026年版)

Docker Desktop のインストールと OS 別注意点

ダウンロードページは常に公式トップからたどる

Windows

macOS

Linux（Ubuntu/Debian 系を中心に）

共通前提：cgroup v2 の有効化

Ubuntu/Debian 系

Fedora / RHEL 系

VS Code Remote‑Containers 拡張機能の設定

拡張機能インストール

devcontainer.json のベストプラクティス

設定項目の解説

コンテナ起動手順

dvc-go-gemini テンプレート取得・カスタマイズ手順

手順概要

実際のコマンド

ディレクトリ構成（変更後）

サンプルプロジェクト構造とコード例（インポート文修正）

ディレクトリ構成（標準的なレイヤード設計）

go.mod（Go 1.22 を使用）

cmd/server/main.go（エントリーポイント）

internal/handler/hello.go（インポートブロックの修正）

コンテナ内での実行確認

マルチステージ Dockerfile とデバッグ用ランタイムの考慮点

推奨マルチステージ構成（Go 1.22 + Distroless）

デバッグ時の注意点

デバッグ用ステージ例（Distroless の代わりに Alpine）

ローカルビルド・コンテナ起動コマンド

Delve デバッグ用に実行する場合

VS Code から Delve デバッグを行う手順

手順概要

.vscode/launch.json

デバッグ時に注意すべき点

クラウド（Google Cloud Run / AWS App Runner）への簡易デプロイ例

前提条件

手順：イメージのビルドとレジストリへのプッシュ

Google Cloud Run デプロイ

AWS App Runner デプロイ

よくあるエラーとトラブルシューティング

おわりに

VS Code Remote‑Containers 拡張機能の設定

`devcontainer.json` のベストプラクティス

`go.mod`（Go 1.22 を使用）

`cmd/server/main.go`（エントリーポイント）

`internal/handler/hello.go`（インポートブロックの修正）

推奨マルチステージ構成（Go 1.22 + Distroless）

VS Code から Delve デバッグを行う手順

`.vscode/launch.json`