2026/05/08

C# WPFのデータバインディングで日本語プロパティ名を使ったら何が起きるか

C# WPFのデータバインディングで日本語プロパティ名を使ったら何が起きるか

「C#って日本語の変数名が使えるらしい」という話は聞いたことがあった。でも実際にWPFのデータバインディングで試したことはなかった。{Binding 名前}みたいに書いて本当に動くのか。動いたとして、実用に耐えるのか。半分好奇心、半分「どうせ落とし穴があるだろう」という気持ちで検証してみた。

そもそもC#は日本語識別子を正式にサポートしている

C#の言語仕様(ECMA-334)では、識別子にUnicode文字を使えると明記されている。つまり変数名・プロパティ名・クラス名に漢字・ひらがな・カタカナをそのまま使えるのは仕様として保証された挙動で、バグでも裏技でもない。

// これは正式に有効なC#コード
public class 利用者
{
    public string 名前 { get; set; }
    public int 年齢 { get; set; }
    public string メールアドレス { get; set; }
}

Visual Studio 2022でも普通にIntelliSenseが効く。補完候補に「名前」「年齢」が出てくる様子はなかなかシュールだけど、ビルドは通る。

WPFのXAMLバインディングでも使えるか

ViewModelに日本語プロパティを持たせてXAMLからバインドしてみた。

// ViewModel
public class 利用者ViewModel : INotifyPropertyChanged
{
    private string _名前;
    public string 名前
    {
        get => _名前;
        set
        {
            _名前 = value;
            OnPropertyChanged(nameof(名前));
        }
    }

    private int _年齢;
    public int 年齢
    {
        get => _年齢;
        set
        {
            _年齢 = value;
            OnPropertyChanged(nameof(年齢));
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged(string name)
        => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
}
<!-- XAML -->
<StackPanel>
    <TextBox Text="{Binding 名前, UpdateSourceTrigger=PropertyChanged}" />
    <TextBox Text="{Binding 年齢, UpdateSourceTrigger=PropertyChanged}" />
    <TextBlock Text="{Binding 名前}" />
</StackPanel>

結果は——動く。{Binding 名前}でちゃんとViewModelの名前プロパティにバインドされて、TextBoxに入力した値がリアルタイムで反映される。WPFのバインディングは内部でリフレクションを使ってプロパティ名を文字列で解決しているので、Unicode名でも問題ない。

nameof()も日本語プロパティで機能する

INotifyPropertyChangedの実装でnameof(名前)と書けるのが地味に重要で、プロパティ名のタイポをコンパイル時に検出できる。ハードコードで"名前"と文字列を渡す実装より安全だ。

// nameof()は日本語プロパティでも正しく機能する
OnPropertyChanged(nameof(名前)); // → "名前" という文字列になる

実際に困った点

IME切り替えのストレス

コードを書くとき、英字と日本語の間で頻繁にIMEを切り替えることになる。public string まで英字で書いて、プロパティ名を入力するために日本語入力に切り替えて、また { get; set; }に戻す、という繰り返しが思ったより煩わしい。慣れの問題かもしれないけど、英語コードの中に日本語が挟まるリズムが崩れる感覚は否めない。

バックエンドとの連携がつらい

APIのレスポンスをViewModelにマッピングするとき、JSONのキーは英語("name""age")でプロパティは日本語、という状況になる。System.Text.JsonやNewtonsoft.Jsonで属性を付ければ対応できるけど、一段階手間が増える。

using System.Text.Json.Serialization;

public class 利用者
{
    [JsonPropertyName("name")]
    public string 名前 { get; set; }

    [JsonPropertyName("age")]
    public int 年齢 { get; set; }
}

StackOverflowやGitHub Copilotとの相性

英語のプロパティ名なら、同じ構造のコードがStackOverflowにいくらでもある。日本語プロパティ名のコードは検索してもほぼ出てこないし、Copilotの補完も精度が落ちる。サンプルコードをそのまま流用しにくい。

使ってみた正直な感想

「動く」と「実用的」は別の話だと改めて思った。一人で書く小さなツールで、日本語のビジネスドメインを扱う場合は選択肢としてアリかもしれない。「顧客番号」「請求金額」「納期」みたいな用語が英訳すると意味が曖昧になるドメインでは、日本語のまま書いた方がコードと仕様書の対応がはっきりする、という考え方はわかる。

ただチームで使う場合や、外部のAPIやライブラリとの連携が多い場合は苦労の方が大きいと思う。英語識別子のコードベースに日本語が混ざると、どちらのルールで書けばいいか迷う人が出てくる。「愚行」と言い切るほどではないけど、採用するなら明確な理由と運用ルールが必要だ。

まとめ

  • C#は仕様としてUnicode識別子をサポートしており、日本語プロパティ名は正式に有効
  • WPFのデータバインディング({Binding 名前}形式)も日本語プロパティで正常に動作する
  • nameof()INotifyPropertyChanged・XAMLバインディングすべて問題なく機能した
  • 実用上の課題はIME切り替え、JSON属性の追加、英語サンプルコードとの乖離
  • ドメイン用語が日本語で完結する一人プロジェクトなら選択肢になりうる。チーム開発では要検討

GolangよりC#記事が伸びた話——技術ブログのアクセス分析

GolangよりC#記事が伸びた——技術ブログのアクセスを分析してみたら意外な結果が出た

技術ブログを書き始めたとき、Golang関連の記事が一番読まれると思っていた。モダンで注目度が高くて、自分もよく書く言語だったから、ネタとしても自然だと思っていたんだけど、実際にSearch Consoleを見てみたら全然そうじゃなかった。C#の記事の方がずっとアクセスを集めていた。しかもGolang記事との差が思ったより大きかった。

なぜかが気になって調べ始めたのがこの記事のきっかけだ。

Golang記事は伸びなかった——数字で見るとはっきりわかる

Golang関連の記事をいくつか書いた後、Google Search Consoleで表示回数とクリック数を確認した。フォルダ構成の話やGin + GORMを使ったAPIの構成など、自分が実際に使った内容で書いたつもりだったけど、表示回数がそもそも少ない。検索結果に出ていないというより、そもそも検索しているユーザーの絶対数が少ないんだと思う。

一方でC#の記事は、書いてからそれほど時間が経っていないのにSearch Consoleの表示回数がGolangの記事より多かった。クリック率はどちらも似たようなものだったので、単純に検索ボリュームの差が出ている形だ。

なぜC#の方が検索ボリュームが大きいのか

日本市場を考えると、C#の根強さは納得がいく。以前、受託の案件で.NETのシステムを触ったことがあるんだけど、そのあたりの現場ではC#がごく当たり前に使われていた。日本のSIerはJavaが主流とはいえ、.NET/C#も業務系では広く生き残っていて、「C# ○○のやり方」という実務検索がコンスタントに発生し続けている。

Unityも大きい。ゲーム開発でC#を使う人が多くて、「Unity C# スクリプト」系の検索はボリュームがかなりある。ゲーム開発系の読者は技術ブログをよく読む層で、検索行動も活発だ。

Golangはというと、採用している企業はメルカリやCyberAgentなどのWeb系大手が多く、その層はQiitaや英語圏の記事を読む傾向がある。日本語でGolangを検索するユーザーは相対的に少ないかもしれない。公式ドキュメントやGitHub上の情報が英語で十分そろっているので、日本語記事を探すモチベーションが下がるのかもしれない。

Google Trendsで比べると差は明確

Google Trendsで「C#」と「Go 言語」または「Golang」を日本向けで比較すると、C#の方が継続的に検索されているのがわかる。Golangの検索量が急増したタイミングはあるものの、継続的なベースラインで見るとC#の方が安定して多い。

これはGolangが悪い技術だということじゃなくて、単純にユーザー数と歴史の差だと思っている。C#は2002年のリリース以来20年以上の蓄積がある。検索キーワードの種類も多いし、「困った人が検索する」シナリオがそれだけ多い。Golangは普及し始めたのも最近で、コミュニティの規模感がまだ全然違う。

技術ブログで「伸びるネタ」を選ぶ考え方

この経験から、記事ネタを選ぶときの判断軸を少し変えた。「自分が書きたいこと」だけで選ぶんじゃなくて、「その言語・技術を日本語で検索しているユーザーがどれくらいいるか」を先に確認するようになった。

確認する方法は簡単で、Google Trendsで気になる技術名を比較する、あるいはGoogle検索でキーワードを打ってみてサジェストにどんなキーワードが出てくるかを見る。サジェストが豊富なキーワードは検索ボリュームが大きいことが多い。

ただ、「検索ボリュームがあるテーマだけ書く」というのも違う気がしている。自分が実際に使っていない技術を書いても内容が薄くなるし、読んでいてすぐわかる。ボリュームがある技術を扱いつつ、自分の実務経験を乗せることで情報に厚みを出す、というのが今の方針だ。

C#でも書けるネタを探す

自分はGolangをメインに使っているけど、C#を完全に触ったことがないわけじゃない。過去に.NETの案件を触ったことがあるし、Unityも少しさわっている。そういう経験を引っ張り出して、C#記事のネタにしてみたら思ったより素直に書けた。「Go使いが初めてC#を触ったときの話」という切り口で書いたら、Goユーザー向けの比較記事になって意外とハマった。

「自分のメイン技術じゃないから書けない」という思い込みがあったけど、ちょっとさわった経験でも「初心者目線で書く」という切り口なら価値が出る。C#をゴリゴリ使っているベテランが書く記事と、「Golangメインで初めてC#を触ったエンジニアが書く記事」は読者が違う。

Golangを諦めるわけじゃない

C#が伸びたからといって、Golang記事をやめるつもりはない。Golangは自分が一番詳しい技術で、書ける内容の深さが違う。アクセスの絶対数は少なくても、ニッチな検索キーワードで上位を取れる可能性はある。ロングテールで拾う戦略だ。

それにGolang記事はこれから増える可能性も十分ある。国内でのGoの採用は増えていて、日本語で検索する人の数は少しずつ増えているはずだ。今のうちに記事を積み上げておくことで、ボリュームが増えたときに上位表示できる状態を作っておく、という考え方もできる。

結局のところ、自分の経験でいちばん腹落ちしたのは「書いてみないとわからない」という当たり前のことだった。想定と結果が違うことはよくあって、そのギャップから次の方針が見えてくる。Search Consoleは定期的に見る価値があると改めて思っている。

まとめ

  • 日本語での検索ボリュームはC#がGolangを上回る。記事を書く前にGoogle TrendsとGoogleサジェストで確認する価値がある
  • C#はSIer業務システム・Unityの層が厚く、「困って検索する人」が継続的に発生している
  • メイン技術でなくても、実体験があれば「初心者目線の記事」として書ける。ベテランとは読者層が違う
  • Golang記事はロングテール狙いで積み上げ続ける。検索ボリュームは少しずつ増えているはずだ