Go言語（Golang）は、Googleによって設計された「シンプルさ」と「可読性」を極限まで追求したプログラミング言語です。

コードが読みやすく、多人数での開発においても一貫性を保てるように、命名規則についても非常に明確なガイドラインが存在します。

2026年現在、Go言語はクラウドネイティブな開発からマイクロサービスの構築まで、不動の地位を築いています。

プロジェクトの規模が拡大してもメンテナンス性を損なわないためには、公式が推奨する命名規則を正しく理解し、現場で実践することが不可欠です。

本記事では、初心者から中級者のエンジニアに向けて、Go言語における命名規則のベストプラクティスを網羅的に解説します。

目次 [ close ]
  1. Go言語における命名の基本思想
  2. パッケージ名の命名規則
    1. シンプルで具体的な単語を選ぶ
    2. パッケージ名の衝突を恐れない
  3. 変数の命名規則
    1. MixedCaps（キャメルケース）の使用
    2. 短い名前の推奨
  4. 関数とメソッドの命名規則
    1. Getterに「Get」を付けない
    2. エクスポート（公開）の管理
  5. インターフェースの命名規則
    1. 「-er」サフィックスの付与
  6. レシーバの命名規則
  7. 頭字語（略語）の扱い
    1. 正しい頭字語の表記例
  8. エラー変数の命名規則
    1. 定数的なエラーは「Err」から始める
    2. エラー型の名前は「Error」で終わる
  9. 定数の命名規則
  10. 現場で迷わないための判断基準
  11. まとめ

Go言語における命名の基本思想

Go言語の設計思想において、名前は「短く、かつ意図が明確であること」が理想とされています。

JavaやC#などの他の言語では、変数の役割を詳細に説明する長い名前が好まれる傾向にありますが、Go言語は異なります。

名前の長さは、その変数が使用される「スコープ（有効範囲）の広さ」に比例すべきであると考えられています。

スコープが狭いループ内などでは i や v といった1文字の変数が推奨され、逆にパッケージ外から参照される公開変数には、より説明的な名前を付けます。

このシンプルさを追求する姿勢こそが、Go言語らしいコード（Go-ishなコード）を書くための第一歩となります。

パッケージ名の命名規則

パッケージ名は、そのパッケージが提供する機能を端的に表す最も重要な要素です。

Go言語では、パッケージ名はすべて小文字で、アンダースコア（_）やハイフン（-）を含まない1単語にするのがルールです。

シンプルで具体的な単語を選ぶ

パッケージ名は、利用者がコードを書く際に常にプレフィックスとして現れます。

例えば、encoding/json パッケージを利用する場合、コード内では json.Marshal のように記述されます。

このように、パッケージ名自体が中身を説明しているため、冗長な名前を避けることが推奨されます。

json_parser や util_functions といった名前ではなく、json や util といったシンプルな名前を採用しましょう。

パッケージ名の衝突を恐れない

他のライブラリと同じ名前になることを過度に心配して、独自の名前をひねり出す必要はありません。

利用者はインポート時に別名を付けることができるため、標準的な単語を優先して使用することが一般的です。

ただし、base や common といった、中身が推測しにくい汎用的な名前は避けるべきです。

変数の命名規則

変数名の付け方には、Go言語特有の慣習が色濃く反映されます。

他の言語から移行してきた開発者が最も戸惑いやすいポイントの一つでもあります。

MixedCaps（キャメルケース）の使用

Go言語では、単語の区切りにアンダースコアを使用するスネークケース（snake_case）は使用しません。

代わりに、複数の単語を繋げる場合はMixedCaps（キャメルケース）を使用します。

具体的には、パッケージ外に公開する場合は大文字で始める UpperCamelCase 、パッケージ内限定の場合は小文字で始める lowerCamelCase を使い分けます。

短い名前の推奨

前述の通り、スコープが狭い変数には短い名前を付けます。

以下のコード例を見てみましょう。

Go
// 推奨される短い変数名の例
func CountItems(items []string) int {
    count := 0 // countという具体的な名前
    for i, v := range items { // インデックスはi、値はv（valueの略）
        if v != "" {
            count++
        }
    }
    return count
}

このように、ループ内での i (index) や v (value)、あるいは r (reader)、w (writer) といった略称は、Goの世界では一般的です。

一目で役割が分かる範囲であれば、記述量を減らしてコードの視認性を高めることが優先されます。

関数とメソッドの命名規則

関数やメソッドの名前は、その動作を動詞で表現するのが基本です。

Getterに「Get」を付けない

Go言語では、フィールドの値を取得するメソッド（Getter）に Get というプレフィックスを付けることは推奨されません。

例えば、obj.GetName() ではなく、単に obj.Name() と命名します。

一方で、値を設定するメソッド（Setter）には Set を付けて obj.SetName("Alice") とするのが一般的です。

エクスポート（公開）の管理

Go言語におけるカプセル化は、名前の先頭文字が大文字か小文字かだけで決定されます。

大文字で始まる関数は、外部パッケージから呼び出し可能な「公開（Exported）」状態となります。

小文字で始まる関数は、そのパッケージ内でのみ参照可能な「非公開（Unexported）」状態となります。

このルールにより、APIのデザインが名前だけで一目瞭然になります。

インターフェースの命名規則

インターフェースの命名は、Go言語において非常に特徴的なパターンを持っています。

「-er」サフィックスの付与

メソッドを1つだけ持つインターフェースには、そのメソッド名に「-er」という接尾辞を付けて名詞化するのが慣習です。

標準ライブラリの io.Reader や io.Writer、fmt.Stringer などが代表例です。

Go
// メソッドが1つのインターフェースの例
type Reader interface {
    Read(p []byte) (n int, err error)
}

type Stringer interface {
    String() string
}

もし2つ以上のメソッドを持つ場合は、その機能全体を表す適切な名詞（例えば ReadWriteCloser など）を選択します。

レシーバの命名規則

メソッドを定義する際に使用するレシーバ名にも、明確なルールがあります。

レシーバ名は、this や self といった一般的な言葉を避けるべきです。

通常、その型の名前から取った1文字または2文字の略称を使用します。

Go
type User struct {
    name string
}

// レシーバ名を "u" にする
func (u *User) SayHello() string {
    return "Hello, I am " + u.name
}

レシーバ名はメソッドごとに変えるのではなく、その型のすべてのメソッドで統一することが重要です。

頭字語（略語）の扱い

HTTP、ID、URL、JSONといった頭字語を名前に含める場合、Go言語には厳格なルールがあります。

それは、「頭字語のすべての文字のケースを一致させる」というものです。

正しい頭字語の表記例

以下の比較表を確認してください。

NGな例OKな例（推奨）
HttpServerHTTPServer
userIduserID
JsonDataJSONData
appUrlappURL

このように、頭字語が公開される場合はすべて大文字（HTTPServer）、非公開の場合はすべて小文字（userID の ID 部分は大文字ですが、先頭の u は小文字）とするのが慣習です。

これにより、ServeHTTP や URLString といった一貫性のある名前が保たれます。

エラー変数の命名規則

Go言語ではエラー処理が頻繁に行われるため、エラーを表す変数の命名も重要です。

定数的なエラーは「Err」から始める

パッケージレベルで定義されるエラー変数（Sentinel Error）には、Err というプレフィックスを付けます。

Go
var (
    ErrNotFound = errors.New("item not found")
    ErrPermissionDenied = errors.New("permission denied")
)

エラー型の名前は「Error」で終わる

一方で、独自のエラー型（構造体）を定義する場合は、末尾に Error を付けます。

Go
type PathError struct {
    Op   string
    Path string
    Err  error
}

func (e *PathError) Error() string {
    return e.Op + " " + e.Path + ": " + e.Err.Error()
}

定数の命名規則

他の言語では、定数を MAX_RETRY_COUNT のようにすべて大文字のスネークケースで書くことが一般的ですが、Go言語では異なります。

定数も変数と同様に、MixedCaps（キャメルケース）を適用します。

Go
// 公開される定数
const MaxRetries = 5

// 非公開の定数
const defaultTimeout = 30

すべて大文字で書く慣習はGoには存在しないため、注意が必要です。

大文字で始めてしまうと外部にエクスポートされてしまうため、カプセル化の観点からもキャメルケースの徹底が求められます。

現場で迷わないための判断基準

命名規則で迷ったときは、常に「利用側のコードがどう見えるか」を想像してください。

Goの命名規則は、宣言側を美しく見せるためではなく、利用側（コールサイト）を簡潔にするために設計されています。

例えば、user.UserEmail という名前は、利用時に user.UserEmail となり冗長です。

これを user.Email と命名すれば、意味が重複せず、かつ明確になります。

常にコンテキスト（文脈）を意識し、重複した情報を削ぎ落とすことが、洗練されたGoコードへの近道です。

まとめ

Go言語の命名規則は、非常にシンプルでありながら、コードの品質を高く保つための知恵が詰まっています。

パッケージ名は小文字の1単語、変数や定数はキャメルケース、インターフェースは「-er」サフィックス、そして頭字語は大文字小文字を統一するといったルールは、どれも一貫性を保つために不可欠です。

これらのルールを単なる「決まり事」として捉えるのではなく、その背景にある「簡潔さと可読性の追求」というGoの思想を理解することが大切です。

本記事で紹介したベストプラクティスを現場のプロジェクトに取り入れることで、チームメンバーにとっても、そして未来の自分にとっても読みやすい、メンテナンス性の高いコードを書き上げることができるでしょう。

正しい命名規則を身につけ、プロフェッショナルなGoエンジニアとしての第一歩を踏み出してください。