Goはシンプルな文法ゆえに学習コストが低い一方で、Generics・Interface・Channels・Contextなどは設計意図を理解していないと実務でつまずきやすいポイントです。本記事では、Go 1.25時点での基本から実務適用パターン、そしてGCP上での活用までを一気に解説します。
1. Generics（ジェネリクス）
Go 1.18で導入されたジェネリクスは、型をパラメータとして扱うことを可能にし、コードの再利用性と型安全性を飛躍的に向上させました。
基本的な使い方
ジェネリクスの基本は「型パラメータ（Type Parameter）」と「型制約（Type Constraint）」です。
型パラメータ:
[T any]のように、関数や型の定義で仮の型を宣言します。Tが型パラメータ、anyが型制約です。型制約: 型パラメータが満たすべき要件を定義します。
anyは任意の型を受け入れる最も緩い制約です。comparableは==や!=で比較可能な型（数値、文字列、ポインタなど）に限定します。
// Mapは、スライスと関数を受け取り、各要素に関数を適用した新しいスライスを返す
func Map[T any, U any](collection []T, iteratee func(T) U) []U {
result := make([]U, len(collection))
for i, item := range collection {
result[i] = iteratee(item)
}
return result
}
// 使用例
numbers := []int{1, 2, 3}
doubled := Map(numbers, func(n int) int {
return n * 2
})
// doubled is []int{2, 4, 6}
strs := []string{"a", "b", "c"}
uppercased := Map(strs, func(s string) string {
return strings.ToUpper(s)
})
// uppercased is []string{"A", "B", "C"}実務応用：共通レスポンスやRepository層の抽象化
APIのレスポンスや、データベースアクセスのためのRepository層でジェネリクスは特に有効です。
// ページネーション付きのAPIレスポンスを抽象化
type PaginatedResponse[T any] struct {
Data []T `json:"data"`
Total int `json:"total"`
NextCursor string `json:"next_cursor"`
}
// FirestoreなどのNoSQL DBに対する汎用的なRepository
type Repository[T any] struct {
client *firestore.Client
coll string
}
func NewRepository[T any](client *firestore.Client, collectionName string) *Repository[T] {
return &Repository[T]{client: client, coll: collectionName}
}
func (r *Repository[T]) Get(ctx context.Context, id string) (*T, error) {
doc, err := r.client.Collection(r.coll).Doc(id).Get(ctx)
if err != nil {
return nil, fmt.Errorf("failed to get document: %w", err)
}
var entity T
if err := doc.DataTo(&entity); err != nil {
return nil, fmt.Errorf("failed to map data to entity: %w", err)
}
return &entity, nil
}まとめ
ジェネリクスは型を引数に取り、コードの再利用性を高める。
[T any]のTが型パラメータ、anyが型制約。comparable制約は、キーとして使われる型などで有用。コレクション操作やデータ構造の抽象化で威力を発揮する。
アンチパターン / 落とし穴
過度な抽象化: 何でもジェネリクスにすると、かえってコードが読みづらくなる。動作の抽象化には interface の方が自然なケースも多い。
anyの乱用:anyは便利ですが、より具体的な制約（例:interface{ Method() }）を定義した方が、型安全性が高まる場合がある。パフォーマンスへの誤解: ジェネリクスはコンパイル時に型が具象化されるため、
interface{}を使うリフレクションベースの実装より高速に動作することが多い。
チェック（自己点検）
[ ] そのジェネリクスは、本当に複数の型で再利用されるロジックか？
[ ]
interfaceで振る舞いを定義する方が、よりシンプルに書けないか？[ ] 型制約は、必要最小限の要件を満たしているか？
2. 無名関数とクロージャ
Goの無名関数（Anonymous Function）は、関数を「値」として扱う強力な機能です。 クロージャ（Closure）は、自身が定義されたスコープの変数を「記憶」する無名関数の一種です。
文法と典型的なバグ
無名関数は func() {} の形でその場で定義し、変数に代入したり、関数の引数として渡したりできます。
クロージャで最も有名なバグは、for ループ内で go func() を使う際の変数キャプチャ問題です。
// 典型的なバグ
func main() {
values := []string{"a", "b", "c"}
for _, v := range values {
go func() {
// このvはループの最後の値をキャプチャしてしまうため、
// ほとんどの場合 "c" が3回表示される
fmt.Println(v)
}()
}
time.Sleep(1 * time.Second)
}
// 修正版
func main() {
values := []string{"a", "b", "c"}
for _, v := range values {
v := v // ループ変数をゴルーチンローカルな変数にコピーする
go func() {
fmt.Println(v) // これで "a", "b", "c" が順不同で表示される
}()
}
time.Sleep(1 * time.Second)
}実務応用：HTTPミドルウェア
HTTPサーバのミドルウェアは、クロージャの代表的な活用例です。
http.Handler を受け取り、http.Handler を返す関数として実装します。
// LoggingMiddlewareは、リクエストの処理時間やステータスをログに出力する
func LoggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
// negroni.ResponseWriterのようなラッパーを使いステータスコードを捕捉
lrw := negroni.NewResponseWriter(w)
// 本来のハンドラを実行
next.ServeHTTP(lrw, r)
// 構造化されたログ形式で出力
log.Printf(
"method=%s path=%s status=%d duration=%s",
r.Method,
r.URL.Path,
lrw.Status(),
time.Since(start),
)
})
}まとめ
無名関数は、関数を値として扱えるようにする。
クロージャは、定義されたスコープの変数を参照できる無名関数。
forループ内のゴルーチンでは、ループ変数をコピーしないと意図しない挙動になる。ミドルウェアやデコレータパターンの実装に非常に有用。
アンチパターン / 落とし穴
クロージャによる予期しない変数の捕捉:
forループ以外でも、クロージャがどの変数をどのタイミングで参照しているか意識しないとバグの温床になる。メモリリーク: クロージャが大きなオブジェクトへの参照を保持し続けると、そのオブジェクトがGCされずメモリリークの原因になることがある。
チェック（自己点検）
[ ]
go func()の中で、ループ変数や外部の変数を直接参照していないか？[ ] クロージャが意図せず大きなメモリを確保し続けていないか？
[ ] よりシンプルな関数で代替できないか？
3. Interface と 構造体の埋め込み
Goの interface は、ダックタイピング（Duck Typing）を実現する強力な仕組みです。
「もしそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである」という考え方で、構造体が特定のメソッドセットを持っていれば、その interface を実装しているとみなされます。
暗黙の実装とポインタレシーバ
明示的な implements 宣言は不要です。
type Reader interface {
Read(p []byte) (n int, err error)
}
type FileReader struct {
// file descriptorなど
}
// FileReaderはReadメソッドを持つので、暗黙的にReader interfaceを実装
func (f *FileReader) Read(p []byte) (n int, err error) {
// ファイルから読み込む処理
return 0, nil
}
// ポインタレシーバ vs 値レシーバ
type Counter struct {
count int
}
// 値レシーバ: 呼び出し時にCounterのコピーが渡される
func (c Counter) Value() int {
return c.count
}
// ポインタレシーバ: Counterのポインタが渡される。状態を変更できる
func (c *Counter) Increment() {
c.count++
}ポインタレシーバでメソッドを定義した場合、その型のポインタ（*Counter）だけが interface を満たすことに注意が必要です。
実務応用：GCP SDKのモック化
interface の最大の利点の一つは、依存関係の注入（Dependency Injection）とモック化です。
例えば、GCPのCloud Storageクライアントをテストで置き換えたい場合、interface を切って対応します。
// uploader.go
// 独自のUploaderインターフェースを定義
type Uploader interface {
Upload(ctx context.Context, bucket, object string, data []byte) error
}
// gcs_uploader.go
// GCPクライアントをラップした実装
type GCSUploader struct {
client *storage.Client
}
func (u *GCSUploader) Upload(ctx context.Context, bucket, object string, data []byte) error {
// GCPのSDKを呼び出して実際にアップロードする処理
return nil
}
// handler.go
type Handler struct {
uploader Uploader // 具象型ではなくインターフェースに依存
}
func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
// handlerの処理
err := h.uploader.Upload(r.Context(), "my-bucket", "my-object", []byte("data"))
if err != nil {
// エラーハンドリング
}
// 成功レスポンス
}
// handler_test.go
// テスト用のモック実装
type MockUploader struct {
UploadFunc func(ctx context.Context, bucket, object string, data []byte) error
}
func (m *MockUploader) Upload(ctx context.Context, bucket, object string, data []byte) error {
return m.UploadFunc(ctx, bucket, object, data)
}
func TestHandler(t *testing.T) {
mock := &MockUploader{
UploadFunc: func(ctx context.Context, bucket, object string, data []byte) error {
// ここでアップロードが呼ばれたことや引数を検証
assert.Equal(t, "my-bucket", bucket)
return nil
},
}
handler := &Handler{uploader: mock}
// handlerに対するテストを実行
// ...
}具象型とinterfaceの選び方
具象型で良いケース：アプリ内で1つの実装しかない／テストの抽象化が不要
interfaceが必要なケース：依存を切り離したい（外部SDKなど）、テストでモックしたい、プラガブル設計をしたい
まとめ
Goの
interfaceは、メソッドセットによる暗黙の実装が特徴。ポインタレシーバのメソッドは、ポインタ型のみが
interfaceを満たす。依存関係を
interfaceにすることで、テスト時のモック化が容易になる。
アンチパターン / 落とし穴
巨大なインターフェース: 何でもかんでもメソッドを詰め込んだ巨大な
interfaceは、実装が大変になり、再利用性も低い（Goではio.Readerのような小さなinterfaceが好まれる）。使う側ではなく、実装側にインターフェースを定義する:
interfaceは、それを利用する側が「こういう振る舞いが必要だ」と定義するのがGoの流儀。nilインターフェースの罠:(T, error)を返す関数で、Tがinterfaceの場合、具象型のnilポインタを返すとinterfaceとしてはnilにならず、バグの原因になる。
チェック（自己点検）
[ ] その
interfaceは、本当に必要か？具象型で十分ではないか？[ ]
interfaceの定義場所は、それを利用するパッケージにあるか？[ ]
interfaceのメソッド数は、必要最小限になっているか？
4. Channels と 並行処理
Goの並行処理の主役はゴルーチン（go キーワード）とチャネル（chan）です。
「メモリを共有することで通信するな、通信することでメモリを共有せよ」という哲学を体現しています。
基本的な使い方
無バッファチャネル:
make(chan int)。送信と受信が同時に行われないとブロックする。同期処理に使う。バッファ付きチャネル:
make(chan int, 3)。バッファが空くまで受信をブロックせず、バッファが満杯になるまで送信をブロックしない。非同期なキューとして機能する。select: 複数のチャネル操作を待機し、最初に準備ができたものから実行する。defaultを使うとノンブロッキングになる。
// ワーカープール
func worker(id int, jobs <-chan int, results chan<- int) {
for j := range jobs {
fmt.Printf("worker %d started job %d
", id, j)
time.Sleep(time.Second) // 処理をシミュレート
fmt.Printf("worker %d finished job %d
", id, j)
results <- j * 2
}
}
func main() {
const numJobs = 5
jobs := make(chan int, numJobs)
results := make(chan int, numJobs)
// 3つのワーカーを起動
for w := 1; w <= 3; w++ {
go worker(w, jobs, results)
}
// 5つのジョブを送信
for j := 1; j <= numJobs; j++ {
jobs <- j
}
close(jobs) // 全てのジョブを送信したらチャネルを閉じる
// 結果を待つ
for a := 1; a <= numJobs; a++ {
<-results
}
}ゴルーチンリークの防止
ゴルーチンがチャネルの受信待ちなどで永遠にブロックされ、終了できなくなるのがゴルーチンリークです。
context パッケージと select を組み合わせることで、キャンセルを検知して安全にゴルーチンを終了させることができます。
func process(ctx context.Context) {
for {
select {
case <-ctx.Done(): // 親コンテキストからのキャンセルを検知
fmt.Printf("goroutine cancelled: %v
", ctx.Err())
return // ゴルーチンを終了
case <-time.After(1 * time.Second):
fmt.Println("processing...")
}
}
}
func main() {
// 3秒後にタイムアウトするコンテキストを作成
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel() // 念のためcancelを呼ぶ
go process(ctx)
// キャンセルされるまで待機
<-ctx.Done()
time.Sleep(1 * time.Second) // 終了メッセージを確認
}まとめ
チャネルは型付けされた、ゴルーチン間で安全にデータを送受信するためのパイプ。
select文は、複数のチャネル操作を多重化する。ゴルーチンリークを防ぐため、必ず終了条件（
contextのキャンセルなど）をselectに含める。
アンチパターン / 落とし穴
close()の誤用: 受信側でチャネルをclose()してはいけない。パニックを引き起こす。送信側が「もう送るデータはない」と判断したときにclose()する。無バッファチャネルによるデッドロック: 送受信のペアが揃わないとデッドロックする。
selectのdefault乱用:defaultを安易に使うと、CPUを無駄に消費するビジーループになることがある。
チェック（自己点検）
[ ] すべてのゴルーチンは、必ず終了することが保証されているか？
[ ] チャネルの
close()は、送信側が責任を持って行っているか？[ ]
select文に、キャンセルをハンドルするcase <-ctx.Done()があるか？
5. Context 徹底特集（本記事の中核）
context パッケージは、Goにおけるリクエストスコープの管理、特に キャンセル伝播 と タイムアウト制御 のための標準的な仕組みです。
APIサーバ、バッチ処理、マイクロサービス間の連携など、現代的なバックエンド開発に不可欠です。
目的と哲学
キャンセル伝播: 親の処理がキャンセルされたら、そこから派生した全ての処理（ゴルーチン、外部API呼び出しなど）にキャンセルシグナルを連鎖的に伝える。
タイムアウト/デッドライン: 処理全体の制限時間を設定し、それを超えたら関連する処理を中断させる。
context.Background(): 通常、リクエストの起点となる場所で使われる、空のコンテキスト。context.TODO(): どのcontextを使うべきか不明な場合や、後で対応する予定の場所で使う、いわば「仮置き」のコンテキスト。
APIの使い分け
context.WithCancel(parent):cancel()関数を呼び出すことで、明示的にキャンセルできるcontextを生成。context.WithTimeout(parent, duration): 指定時間後に自動的にキャンセルされるcontextを生成。context.WithDeadline(parent, time): 指定時刻に自動的にキャンセルされるcontextを生成。context.WithValue(parent, key, value):contextにリクエストスコープの値を埋め込む。注意: これはリクエストIDや認証情報といった、横断的なメタ情報に限定して使うべきです。ビジネスロジックのデータを渡すために使うべきではありません。
WithCancel や WithTimeout で生成した context は、親 context の子となります。親がキャンセルされると、その子 context も全てキャンセルされます。ctx.Err() を使うと、context がなぜ終了したのか（context.Canceled または context.DeadlineExceeded）を知ることができます。
キャンセルされない場合の挙動
select で ctx.Done() を監視するのはキャンセルを検知するためですが、もしキャンセルが発生せず、他のチャネル操作もブロックされたままだと、ゴルーチンは永久に待ち続ける可能性があります。
select {
case <-ctx.Done():
// キャンセルされた
return ctx.Err()
case result := <-someChannel:
// someChannelから受信できた
return result
}
// もしctxがキャンセルされず、someChannelにも永遠にデータが送信されない場合、
// このゴルーチンはここでリークします。context はあくまでキャンセルを伝播させる仕組みであり、処理の「正常終了」を保証するものではありません。タイムアウトと並行して、ゴルーチンが必ず終了する条件（例: チャネルが close される、有限回のループで処理が終わるなど）を明確に設計することが、ゴルーチンリークを防ぐ鍵となります。
実例1: HTTPサーバでのタイムアウト設計
Cloud RunなどのHTTPサーバでは、リクエストごとにタイムアウトを設定し、それをデータベースや外部API呼び出しまで伝播させることが重要です。
func main() {
// ... http server setup
server := &http.Server{
Addr: ":8080",
// http.TimeoutHandlerでリクエスト全体のタイムアウトを設定
Handler: http.TimeoutHandler(http.HandlerFunc(myHandler), 30*time.Second, "request timeout"),
}
log.Fatal(server.ListenAndServe())
}
func myHandler(w http.ResponseWriter, r *http.Request) {
// http.TimeoutHandlerが設定したdeadline付きのcontextを取得
ctx := r.Context()
// DB呼び出しに5秒のタイムアウトを設定
dbCtx, dbCancel := context.WithTimeout(ctx, 5*time.Second)
defer dbCancel()
if err := queryDatabase(dbCtx); err != nil {
// contextのエラーをチェックして、原因に応じたステータスを返す
if errors.Is(err, context.DeadlineExceeded) {
log.Printf("database query timed out: %v", err)
http.Error(w, "database timeout", http.StatusGatewayTimeout)
return
}
log.Printf("database query failed: %v", err)
http.Error(w, "internal server error", http.StatusInternalServerError)
return
}
// 成功レスポンス
w.WriteHeader(http.StatusOK)
}実例2: Pub/Sub サブスクライバでのバックオフ＋キャンセル
イベント駆動のCloud FunctionsやPub/Subサブスクライバでは、処理全体の上限時間を意識しつつ、リトライ処理に context を活用します。
func subscribe(ctx context.Context, sub *pubsub.Subscription) error {
// subscription.Receiveはブロッキングするため、
// アプリケーション終了シグナル(ctx)をハンドリングする
return sub.Receive(ctx, func(ctx context.Context, msg *pubsub.Message) {
// Pub/Subメッセージごとに60秒の処理タイムアウトを設定
procCtx, cancel := context.WithTimeout(ctx, 60*time.Second)
defer cancel()
err := processMessageWithRetry(procCtx, msg.Data)
if err != nil {
log.Printf("failed to process message, nacking: %v", err)
msg.Nack() // 処理失敗。再配信させる
return
}
msg.Ack() // 処理成功
})
}
func processMessageWithRetry(ctx context.Context, data []byte) error {
bo := backoff.NewExponentialBackOff()
bo.MaxElapsedTime = 30 * time.Second // リトライ全体のタイムアウト
return backoff.Retry(func() error {
// contextのキャンセルを最優先でチェック
select {
case <-ctx.Done():
return backoff.Permanent(ctx.Err()) // contextが終了したらリトライしない
default:
}
err := callExternalAPI(ctx, data) // 外部API呼び出し
if err != nil {
// 再試行可能なエラーか判定
if isRetryable(err) {
log.Printf("retryable error: %v", err)
return err // backoff.Retryがリトライを継続
}
return backoff.Permanent(err) // 恒久的なエラーならリトライ終了
}
return nil
}, backoff.WithContext(bo, ctx))
}まとめ
contextはキャンセルとタイムアウトを管理するための必須パッケージ。contextは関数の最初の引数として、明示的にリレーしていく。WithValueは、リクエストIDのような横断的関心事のみに使い、乱用しない。サーバではリクエストごとに
contextを生成し、クライアントでは呼び出しごとにcontextを渡す。
アンチパターン / 落とし穴
contextを構造体に含める:contextはリクエストスコープに紐づくべきもので、長寿命なオブジェクトに含めるべきではありません。リクエストごとに異なるcontextを渡すべきところに、古いcontextを使い回してしまうバグの温床になります。WithValueでビジネスロジックの引数を渡す: 関数のシグネチャが不透明になり、依存関係が隠蔽されます。引数は明示的に渡すべきです。cancel()を呼び忘れる:WithCancelなどで生成したcontextは、処理が完了したら必ずcancel()を呼び出す。defer cancel()が定石。nilのcontextを渡す:contextが必須の関数にnilを渡すと、実行時パニックになる可能性があります。context.TODO()を使う。
チェック（自己点検）
[ ] ネットワークやDBアクセスを行う関数は、第一引数に
context.Contextを受け取っているか？[ ]
context.WithValueを使って、関数の振る舞いを制御するような引数を渡していないか？[ ]
defer cancel()は正しく呼ばれているか？
6. エラーハンドリング (errors パッケージ)
Go 1.13で導入された errors.Is, errors.As, %w によるエラーラッピングは、エラーハンドリングをより構造的にしました。
%w:fmt.Errorf("...: %w", err)のように使い、エラーをラップする。これにより、エラーの連鎖（チェーン）が作られる。errors.Is(err, target): エラーチェーンを遡り、targetと一致するエラーがあるか判定する。errors.As(err, &target): エラーチェーンを遡り、targetに代入可能な型のエラーを探し、見つかればtargetに代入してtrueを返す。
// 独自のエラー型
type MyError struct {
Code int
Message string
}
func (e *MyError) Error() string {
return fmt.Sprintf("code %d: %s", e.Code, e.Message)
}
func doSomething() error {
return &MyError{Code: 500, Message: "internal error"}
}
func main() {
err := doSomething()
wrappedErr := fmt.Errorf("failed in main: %w", err)
// errors.Asで特定のエラー型を取り出す
var myErr *MyError
if errors.As(wrappedErr, &myErr) {
// myErrにエラーが代入されるので、中身を参照できる
fmt.Printf("Error is of type MyError, code: %d
", myErr.Code)
}
// errors.Isで特定のエラー値と比較する
// 例: データベースからレコードが見つからない場合
err = sql.ErrNoRows
if errors.Is(err, sql.ErrNoRows) {
fmt.Println("record not found")
}
}注釈: errors.As の第二引数には、エラーの型を代入するためのポインタを渡します。As はエラーチェーンの中から引数の型に一致するものを探し、見つかった場合にその値をポインタ経由で設定するためです。
まとめ
%wでエラーをラップし、コンテキストを追加する。errors.Isで特定のエラー（センチネルエラー）と比較する。errors.Asで特定のエラー型を取得し、詳細な情報を取り出す。
アンチパターン / 落とし穴
%vでラップする:%wの代わりに%vを使うと、エラーチェーンが途切れてしまい、IsやAsで追跡できなくなる。エラーをラップせずに返す: 下層からのエラーをそのまま返すと、どこでエラーが発生したかのコンテキストが失われる。
チェック（自己点検）
[ ] 他の関数を呼び出してエラーが返ってきたら、
%wでコンテキストを追加してラップしているか？[ ] エラーの型や特定の値によって処理を分岐させたい場合、
errors.Asやerrors.Isを使っているか？
7. defer の挙動と設計
defer は、関数がリターンする直前に実行される処理を登録します。
リソースのクリーンアップ（ファイルのクローズ、ロックの解放など）に不可欠です。
実行順序:
deferはLIFO（Last-In, First-Out）の順序で実行される。後からdeferしたものが先に実行される。引数の評価:
defer文の引数は、deferが呼ばれたその場で評価される。
func main() {
defer fmt.Println("first") // 最後に実行
defer fmt.Println("second") // 最初に実行
fmt.Println("main")
}
// 出力:
// main
// second
// firstまとめ
deferは関数の終了時に処理を保証する。リソースの解放処理は、取得直後に
deferするのが定石。複数の
deferは、登録された逆順で実行される。
アンチパターン / 落とし穴
ループ内での
defer:forループの中でdeferを使うと、関数の終了時まで実行が遅延されます。これにより、ファイルディスクリプタやメモリなどのリソースが、ループが終了するまで解放されずに枯渇する可能性があります。エラーチェックの
defer:f.Close()のようなエラーを返す可能性のある処理をdeferで呼び、そのエラーを無視してしまう。
deferとエラーハンドリング
defer で呼び出すクローズ処理などがエラーを返す場合、それを無視すべきではありません。無名関数を defer することで、エラーハンドリングも記述できます。
// 良い例: defer内でエラーハンドリングを行う
func GoodProcess(filename string) error {
f, err := os.Open(filename)
if err != nil {
return err
}
defer func() {
if closeErr := f.Close(); closeErr != nil {
// ここではログ出力に留めることが多い
// なぜなら、関数の主要な戻り値（エラー）を上書きすべきではないため
log.Printf("warn: failed to close file %s: %v", filename, closeErr)
}
}()
// ... ファイル処理 ...
// ここで発生したエラーが、この関数の主要なエラーとなる
return nil
}チェック（自己点検）
[ ] ファイルやDBコネクションを開いたら、直後に
deferでClose()を呼んでいるか？[ ] ループ内で
deferを使っていないか？（もし使っているなら、それは意図通りか？）
8. init と パッケージ初期化
init() 関数は、パッケージがインポートされた際に、main() 関数より先に実行される特別な関数です。
パッケージレベルの変数の初期化などに使われます。
実行順序: インポートされたパッケージの
init()が先に実行される。一つのパッケージに複数のinit()がある場合、ファイル名の辞書順で実行される。
まとめ
init()はパッケージの初期化処理に使われる。main()より先に、一度だけ実行される。副作用を伴う処理や複雑なロジックは避けるべき。
アンチパターン / 落とし穴
init()での副作用:init()の中でネットワーク接続やファイルI/Oなどを行うと、パッケージをインポートするだけで副作用が発生し、テストが困難になる。複雑なロジック:
init()に複雑なロジックを書くと、実行順序の依存関係が生まれ、デバッグが難しくなる。
チェック（自己点検）
[ ]
init()で行っている処理は、本当にパッケージのインポート時に必須か？[ ]
init()が、隠れた副作用（設定ファイルの読み込み、外部サービスへの接続など）を持っていないか？
9. Goの機能をGCP上でどう活かすか？
これまで見てきた概念が、GCP環境でどのように活きるかを見ていきましょう。
Cloud Run:
各HTTPリクエストには、Cloud Run自体が設定したタイムアウトを持つ
contextが渡されます。このcontextをDB（Firestore, Spanner）や外部API呼び出しに伝播させることで、リクエスト全体のタイムアウトを一貫して管理できます。
Pub/Sub:
並列でメッセージを処理する際、各ゴルーチンに
contextを渡してキャンセルを可能にします。ack_deadline内に処理が終わらない場合、contextを使って処理を中断し、Nack()を返すことで安全に再試行させることができます。
Cloud Functions:
イベント駆動のFunctionも実行時間上限があります。
contextを使ってこの上限を監視し、Firestoreへの書き込みなどが時間内に終わらない場合に処理を中断できます。
Firestore/Storage:
GCPのGoクライアントライブラリは、全てのAPI呼び出しで
context.Contextを第一引数に取ります。これにより、クライアント側で設定したタイムアウトやキャンセルが、サーバサイドへのリクエストに正しく反映されます。
Cloud Tasks / Workflows:
長時間かかる処理や複数のサービスをまたぐ処理は、Cloud Tasksで非同期タスクに分割したり、Workflowsでリトライや分岐ロジックを外部化したりできます。その際も、各ステップの実行には
contextによるタイムアウト制御が重要になります。
まとめ
GCPの各サービスは、
contextを通じてタイムアウトやキャンセルを制御するGoの設計思想と非常に相性が良い。Cloud RunやCloud Functionsではリクエスト/イベントのライフサイクルが
contextに紐付けられる。Pub/SubやCloud Tasksでは、非同期処理の信頼性を
contextを使って高めることができる。
チェック（自己点検）
[ ] GCP SDKのクライアントライブラリを呼び出す際、必ず
contextを渡しているか？[ ] Cloud Run/Functionsのタイムアウト設定と、コード内の
contextのタイムアウト設定は整合性が取れているか？[ ] 非同期処理（Pub/Sub, Tasks）で、冪等性を担保しつつ、
contextで安全に処理を中断できる設計になっているか？
10. まとめ
本記事では、Go言語の実務でつまずきやすいポイントを横断的に解説しました。
Generics: 型安全な再利用コードのために使うが、
interfaceとの使い分けを意識する。クロージャ:
go func()での変数キャプチャに注意し、ミドルウェアなどで活用する。Interface: 依存関係の疎結合化とモック化の要。小さく、利用側で定義する。
Channels: ゴルーチン間の安全な通信路。リークしないよう
contextと共に使う。Context: リクエストスコープのキャンセルとタイムアウト管理の心臓部。
WithValueの乱用は避ける。エラー/defer/init: それぞれ定石とアンチパターンを理解し、予測可能で堅牢なコードを書く。
「初学者→中級者が最初に直すべき癖」チェックリスト
[ ] エラーを
log.Fatalやpanicで処理せず、ラップして呼び出し元に返しているか？[ ] グローバル変数に状態を保存せず、関数の引数や構造体のフィールドで渡しているか？
[ ] ネットワークやDBアクセスには、必ず
contextを渡しているか？[ ]
interface{}(any) を安易に使わず、具体的な型やinterface、ジェネリクスを検討しているか？[ ] ゴルーチンを起動したら、それがいつ、どのように終了するのかを明確に設計しているか？
Goは"書ける"から"設計できる"へ。この記事がその第一歩になることを願っています。
学びを深めるための外部リソース
さらに学びを深めたい方のために、以下の公式リソースをおすすめします。
Go by Example: 実践的なコード例が豊富な学習サイト
GCP Go Client Libraries: GCP各サービスのGoクライアント公式リファレンス
