Go言語の構造体の可視性（大文字小文字）の仕組みを理解しよう

先生と生徒の会話形式で理解しよう

生徒

「Go言語で構造体のフィールド名を大文字にする意味ってあるんですか？」

先生

「はい、大きな意味があります。Goでは大文字と小文字で、そのフィールドが外部から見えるかどうか（公開か非公開か）を決めているんですよ。」

生徒

「えっ？ただの名前の書き方かと思ってました！」

先生

「では、実際のコードでその違いを見てみましょう！」

1. Go言語の構造体と可視性とは？

Go言語の可視性（エクスポート/アンエクスポート）は、名前の先頭が大文字か小文字かだけで決まります。これはとてもシンプルですが、パッケージ間でデータを安全に受け渡しするうえで重要なルールです。特に構造体（struct）のフィールドでは、このルールがそのまま「外から見える/見えない」を表します。

大文字で始まるフィールド名は「公開（エクスポート）」で、ほかのパッケージからも読み書きできます。反対に、小文字で始まるフィールド名は「非公開（アンエクスポート）」で、同じパッケージの中からだけアクセスできます。覚え方は簡単で、頭文字がA〜Zなら外に公開、a〜zなら中だけというイメージです。

まずは雰囲気をつかむために、超シンプルな例を見てみましょう。ここでは同じパッケージ内なので、公開・非公開どちらのフィールドにもアクセスできます（外部からのアクセス可否は後で意識すると理解しやすいです）。


package main

import "fmt"

// Book構造体：Titleは公開、pagesは非公開
type Book struct {
    Title string // 大文字開始：公開（エクスポート）
    pages int    // 小文字開始：非公開（アンエクスポート）
}

func main() {
    b := Book{Title: "Go入門", pages: 200}
    fmt.Println(b.Title) // OK：同じパッケージ内
    fmt.Println(b.pages) // OK：同じパッケージ内（非公開でも同一パッケージならOK）
}

ポイントは、「大文字=公開」「小文字=非公開」という単純な規則が、構造体のフィールドのアクセス可否を左右することです。まずはこの基礎を押さえておくと、後でパッケージを分けたときも迷いにくくなります。

2. 大文字・小文字の違いを実際に見てみよう

まずは構造体を定義して、大文字と小文字の違いを試してみましょう。


package main

import "fmt"

// Person構造体を定義
type Person struct {
    Name string  // 公開フィールド
    age  int     // 非公開フィールド
}

func main() {
    p := Person{Name: "田中", age: 30}
    fmt.Println(p.Name) // OK
    fmt.Println(p.age)  // OK（同じパッケージ内だから）
}

このコードでは、Nameは大文字で始まっているため、外部からアクセスできます。ageは小文字で始まっているため、同じパッケージ内からしか使えません。

3. 別パッケージからアクセスしたときの挙動

次に、構造体を別パッケージから使ってみましょう。以下は別のファイルやディレクトリにあるコードからPerson構造体を使おうとする例です。


package main

import (
    "fmt"
    "example/person"
)

func main() {
    p := person.Person{Name: "佐藤"} // OK
    fmt.Println(p.Name)              // OK
    fmt.Println(p.age)               // コンパイルエラー！
}

このコードはperson.ageにアクセスしようとしてエラーになります。小文字のageは非公開なので、他のパッケージからは使えません。


./main.go:10:17: p.age undefined (cannot refer to unexported field or method age)

4. フィールドだけでなく関数や構造体名にも可視性のルールがある

Go言語では、構造体のフィールド名だけでなく、関数名や構造体名にも同じルールが適用されます。大文字で始めると公開、小文字で始めると非公開になります。


// 公開された構造体
type Animal struct {
    Name string
}

// 非公開の関数（他パッケージから呼べない）
func makeNoise() {
    fmt.Println("ワンワン！")
}

// 公開された関数（他パッケージから呼べる）
func MakeNoise() {
    fmt.Println("ワンワン！")
}

Go言語ではこのようにして、シンプルな書き方でアクセス制御（可視性）を実現しています。これは他の言語でいうpublicやprivateといったアクセス修飾子の代わりになります。

5. 実際に自分で書いて確かめてみよう

ここまでの内容は、「名前の最初の文字を大文字にするかどうか」という一見単純なルールに見えますが、Go言語の設計思想にもとづいた非常に重要なポイントです。

初学者の方も、自分で構造体や関数を書いて、大文字・小文字の違いでアクセスできるかどうかを試してみると理解が深まります。

まとめ

この記事ではごとく簡潔で迷いの少ない記法を採用するごの設計思想に沿ってごの可視性の考え方を整理した。ごの構造体のフィールドや関数やメソッドや型名は頭文字の大小だけで公開範囲が決まり、外側に見せたいものは大文字ではじめ、内部に閉じたいものは小文字ではじめるという一貫した作法がある。とくに構造体の設計では名前の一文字が意図の伝達そのものであり、読み手にも書き手にも負担をかけず、依存を最小化しながら安全なデータの受け渡しを実現できる。実務では小さな構造体から大きなドメインまで一貫してこの原則が効き、可読性や保守性やテスト容易性に直結する。ごの言語ならではの最小主義を活かすためにも、最初の段階で公開と非公開の境界をていねいに決め、意図を名前に刻む習慣を持とう。

まずはごの基本ルールを確認する。頭文字が大文字ならエクスポートであり、別のパッケージからも参照できる。頭文字が小文字ならアンエクスポートであり、同じパッケージの内部からのみ利用できる。難しい記号や特別なキーワードを覚える必要はなく、単純な命名規則だけで安全なアクセス制御が成立する。学びはじめの段階ではつい詳細な設定に目を向けがちだが、最小の労力で最大の効果を出すには名前の設計に集中するのが近道である。読み書きの方向や責務の境界が曖昧なときは、外から触れてよいものを大文字にそろえ、内部の詳細は小文字のまま閉じておくと整理が進む。

次に実装時の考え方を整理する。構造体の大文字のフィールドは他のパッケージの呼び手にとっての契約の入り口であり、外部との交換に耐える安定した名前にすべきである。逆に小文字のフィールドは内部の都合や最適化や一時的な状態などを含むことが多く、いつでも変更できる前提で扱える。これにより呼び手に余計な知識を要求せず、変更の影響範囲を小さく保てる。関数やメソッドでも同じであり、外から呼ばれる入口は大文字でそろえ、内部の補助は小文字で隠す。命名は設計であり、設計は命名に現れる。名前が揃えば仕様が自然と読み取れ、レビューやドキュメントやテストも軽くなる。

実際の開発ではうっかり起こりやすい落とし穴がいくつかある。ひとつは型名を小文字で定義してしまい、構造体のフィールドを大文字にしても他のパッケージからその型自体が見えなくなる点である。もうひとつは大文字と小文字を混ぜすぎて意図が読み取りにくくなる点である。用途が外部向けか内部向けかを先に決め、単語の区切りや略語の扱いをチームで統一しておくと誤解が減る。さらにテストの観点では、公開の最小化はモックの過剰な準備を避ける助けになる。必要な入口だけが大文字で表に出ていれば、テスト対象の境界がはっきりし、意図しない結合を防げる。

設計指針としては、まず公開したい情報を最小限に絞り、読み手が理解に迷わない単純な名前を与える。外から直接触れてほしくない状態は小文字のままにし、必要があれば公開された関数経由で安全に扱う。データの整合性を守るルールや前提条件は公開側の表面で満たされるようにし、内部の小文字側では軽量な最適化や差し替えを自由に行う。これにより長期の運用でも仕様の安定と実装の自由を両立できる。ごの言語の現場ではこのような地味な命名規則が最終的な品質に直結しており、学習直後から意識しておく価値が高い。

またドキュメントやレビューの場では、公開の名前の一覧を用意して、何を外部に約束しているかを共有するとよい。名前の変更は互換性に影響するため、理由を明らかにし、段階的な移行を計画する。内部の小文字の変更は原則として自由だが、影響と前提を軽くメモしておくと後からの追跡が容易になる。小さな約束の積み重ねが大きな信頼につながり、利用者にとっても提供者にとっても無理のない進化が実現できる。

すぐ試せる小さなサンプル

下の最小サンプルは外に見せたい名前だけを大文字でそろえ、内部の詳細は小文字で隠す構成になっている。まずはそのまま動かし、その後で頭文字を入れ替えて挙動を比べると理解が深まる。小さな成功体験を積み重ねることで、命名の判断が自然に速くなる。


package main

import "fmt"

// 公開の窓口は大文字でそろえる
type User struct {
    Name string // 公開
    id   int    // 非公開
}

func NewUser(name string, id int) User { // 公開
    return User{Name: name, id: id}
}

func (u User) Label() string { // 公開
    return fmt.Sprintf("%s", u.Name)
}

func (u User) raw() int { // 非公開
    return u.id
}

func main() {
    u := NewUser("花子", 7)
    fmt.Println(u.Label())
    // fmt.Println(u.id) // 外からは非公開
}

実務で役立つ観点

現場では読み手が多様であり、短時間で要点を把握できるかどうかが生産性を左右する。公開された名前が安定していればインターフェースの学習コストは下がり、内部の変更も安全に進められる。名前は最初の設計書であり、最終の仕様書でもある。頭文字のルールを守ることは、目に見えない約束事を目に見える形にする作業である。ごの開発では道具や枠組みに頼らずとも、命名だけで設計を明確にできる。

学習の次の一歩としては、小さな練習課題を積み重ねるのが効果的である。日常の小さな機能でも公開するものと非公開にするものを必ず決め、迷いがあれば大文字と小文字の意味に立ち返る。名前を通して意図を外部に伝え、内部では柔軟に改善を続ける。こうした姿勢が長く使われるコードにつながり、仲間との協力も円滑になる。

確認用チェックリスト

公開にしたいものは本当に外部の利用者に必要かを自問し、長く安定させられる名前かを点検する。内部に留めるものは実装都合や一時的な状態かを確認し、将来の差し替えや最適化がしやすい配置かを見直す。構造体の型名は公開するなら大文字、内部専用なら小文字という基本を守り、関数やメソッドの入口も同じ基準でそろえる。加えて、読み手が迷わない単語選びと一貫した表記が保たれているかを点検する。

よくある勘違いと対処

大文字と小文字の区別は見た目の装飾ではなく仕様の宣言である、という理解が欠けると設計が崩れやすい。名前は短くても意味が通ることが大切で、略語はチームで合意した形に統一する。外部に出す名前を増やしすぎると将来の変更が重くなるため、最初は最小限に絞り、必要が生じたときに慎重に追加する。内部の小文字の部分は自由度が高いが、前提や期待する振る舞いを軽く書き残しておくと学習コストが下がり、継続的な改良が進めやすくなる。

先生と生徒の振り返り会話

生徒

きょうは頭文字だけで公開と非公開が分かれることがわかった。大文字にすると他のパッケージから見えるので、外に約束したい情報だけを慎重に選ぶ必要があると感じた。

先生

その通りだ。見せたい入口を大文字でそろえ、内部の詳細は小文字で守る。名前の設計が決まれば依存の線引きがはっきりし、変更の影響も読みやすくなる。

生徒

型名を小文字にしてしまうと型そのものが外から見えない点も印象に残った。公開したい構造体は型名も大文字で書くように気をつけたい。

先生

よい気づきだ。まず外に示す名前を決め、次に内部の名前を整える。小さな練習を重ねれば、自然と判断が速くなる。

生徒

これからは公開したいものだけを大文字にして、内部の詳細は小文字にする。迷ったら名前の意味を見直して、意図を短い言葉で表すようにする。

先生