日本語でのSwiftプログラミング【詳解版】

Last updated at 2025-07-30Posted at 2025-07-25

本記事は、try! Swift Tokyo 2025の「Swift Programming in Japanese」を書き起こしたものです。

実際の登壇では、様々な事情で省略した内容が多々ありました。本記事では「省略した内容の追加」や「構成の調整」を行い、詳解版として整理しました。

はじめに

プログラミングには50年以上の歴史があり、そのソースコードは英語で書かれてきました。
最近のプログラミング言語は、Unicodeのおかげで様々な自然言語をスムーズに扱えます。
Swiftは10年前に誕生した最近のプログラミング言語です。
私は、とあるアプリの開発で日本語でのSwiftプログラミングに挑戦してみました。

この将棋盤アプリで日本語でのSwiftプログラミングに挑戦

将棋盤が題材のシンプルなアプリです。
3年前にリリースし、これまで継続的にアップデートしてきました。
Xcode、Swift、SwiftUIというスタンダードな構成で開発しました。

SwiftUIの強みを活かして、積極的にマルチプラットフォーム対応に取り組み、Apple Vision Pro含む全てのAppleプラットフォーム向けにリリースしました。

Appleの開発エコシステムを最大限活用してこのアプリを開発してきました。

将棋について

このアプリは日本の伝統的なボードゲームである将棋を題材にしています。

将棋の駒は8種類あり、各駒は日本語の文字によって表現されています。
これをソースコードで書いてみましょう。

こんな感じです。Swiftは日本語でも識別子を書くことが出来ます。良い感じですね。

日本語でソースコードを書いたので、UI上に駒をそのまま表示できます。追加のコードは必要ありません。

このアプリでは、こうした取り組みを積極的に検討してみました。

そして、ほぼ全てのソースコードを日本語で書くことにチャレンジしました。

本記事では、このアプリの経験を基に話をしたいと思います。

「日本語でのSwiftプログラミング」とは

「日本語でのSwiftプログラミング」とはどういう意味でしょうか？

SwiftのソースファイルはUTF-8でエンコードされます。
Swiftは英語ではない自然言語を扱えるように設計されています。
予約語やフレームワークの識別子はそのまま英語を使います。
識別子を日本語で命名します。

今回はこれを「日本語でのSwiftプログラミング」と呼ぶことにしましょう。

本記事の前提

プログラミング言語はSwift
デバイスはMac
IDEはXcode
Apple製の開発ツールのみを使用
特別なツールや設定は不使用
あくまで自分個人の経験に基づくもの

「本記事で話さないこと」

英語話者ではない人が母国語でプログラミングするメリットやデメリットについて
英語話者ではない人が英語でプログラミングすべきかどうかについて

日本語識別子の実現性

まず、識別子を日本語で書くことの実現性を検討してみましょう。

日本語のどの文字が識別子に使えるのか？

識別子として使えない文字ではXcodeはエラーメッセージを表示します。また、コンパイルにも失敗します。

では、文字のカテゴリーごとに検討してみましょう。

ひらがな

ひらがなは(Unicode基準で数えると)80個の文字があり、すべて使えます。

let あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよらりるれろわをんがぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽぁぃぅぇぉっゃゅょ = 123

カタカナ

カタカナは82個あり、すべて使えます。

func アイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワヲンガギグゲゴザジズゼゾダヂヅデドバビブベボパピプペポァィゥェォヵヶッャュョ() {}

漢字

日本では約3000個の漢字が使われており、すべて使えます。

// ↓常用漢字2136文字と人名用漢字863文字の計2999字
enum 一乙九七十人二入八力刀丁又了卜乃下口三山子女小上夕千川大土丸弓工才万士久干己寸亡及巾乞丈刃凡与叉也勺之已巳円王火月犬手水中天日文木六五引牛元戸午公今止少心切太内父分方毛友化区反予欠氏不夫支比仏尺収仁片牙介刈凶斤幻互勾孔升冗井双丹弔爪斗屯匂匹乏厄匁壬尤勿巴丑云允廿右玉左四出正生石田白本目立外兄古広市矢台冬半母北用央去号皿仕写主申世他打代皮氷平由礼以加功札史司失必付辺包末未民令圧永可刊旧句示犯布弁穴冊処庁幼凹瓦且甘丘巨玄巧甲込𠮟囚汁召尻斥仙占旦奴凸丼尼氾払丙矛卯仔乎戊凧叶只疋汀禾弘気休糸字耳先早竹虫年百名羽回会交光考行合寺自色西多地池当同肉米毎安曲血向死次式守州全有羊両列衣印各共好成争仲兆伝灯老因仮件再在舌団任宇灰危机吸后至存宅扱芋汚汗缶企伎吉朽臼叫仰刑江旨芝朱舟充旬巡如匠尽迅壮吐弐肌伐帆汎妃伏忙朴妄吏劣亥此弛亘而肋瓜牟汐尖汝圭托丞辻旭匡亙伍庄夷凪伊亦收曳花貝見車赤足村男町何角汽近形言谷作社図声走体弟売麦来里医究局君決住助身対投豆坂返役位囲改完希求芸告材児初臣折束低努兵別利良冷労応技均災志似序条状判防余快我系孝困私否批忘乱卵亜壱戒肝含岐忌却狂吟串迎呉坑抗攻更克佐沙伺寿秀床抄肖伸芯辛吹杉即汰妥択沢但沖沈呈廷那尿妊忍把伯抜伴阪尾肘扶芳邦坊妨没妙冶妖抑沃励戻呂弄牡辿劫壯宏芹佃佛兎冴佑芭玖灸吾迄庇沌甫芙迂吻亨伽宋坐吞步杜每辰巫芦杖邑孜伶汲酉灼芥李杏雨学金空青林画岩京国姉知長直店東歩妹明門夜委育泳岸苦具幸使始事実者取受所昔注定波板表服物放味命油和英果芽官季泣協径固刷参治周松卒底的典毒念府法牧例易往価河居券効妻枝舎述招承制性版肥非武延沿拡供呼刻若宗垂担宙忠届乳拝並宝枚宛依炎押旺欧殴岡佳苛怪拐劾岳玩奇祈宜拒拠享況屈茎肩弦股虎拘肯昆采刹刺祉肢侍邪呪叔尚昇沼炊枢姓征斉析拙狙阻卓拓抽坪抵邸泥迭妬到突奈杯拍泊迫彼披泌苗怖阜附侮沸併奉抱泡房肪奔枕抹岬免茂盲弥拉炉枠狀昌拂昏帖社坦欣阿爭苔沓忽卑尭陀些茅杷昂亞來宕杭怜穹迪或侑竺於茄苺昊肴庚奄茉朋祁苑斧卷枇杵拔孟兒其沫侃函音草科海活計後思室首秋春食星前茶昼点南風屋界客急級係研県指持拾重昭乗神相送待炭柱追度畑発美秒品負面洋胃栄紀軍型建昨祝信省浅単飛変便約勇要逆限故厚査政祖則退独保迷映革巻看皇紅砂姿城宣専泉洗染奏段派背肺律哀威為畏茨咽姻疫怨卸架悔皆垣柿括冠軌虐糾峡挟狭契孤弧枯侯恒洪荒郊香拷恨砕削柵咲拶施狩臭柔俊盾叙浄拭侵津甚帥是牲窃荘促俗耐怠胎胆挑勅珍亭貞帝訂怒逃洞峠栃虹卑眉訃赴封柄胞某冒勃盆昧幽柳侶厘郎珊洲柊哉柘茜茸勁奎昴洸洵珈珀拜恆侮勉祈祉突者俠俐玲亮穿殆祢姪祐盃柏毘姥柾俣籾耶柚宥洛卽巷竿臥彦柑恰娃祇衿按恢廻胤俄郁迦頁珂胡校夏家記帰原高紙時弱書通馬員院荷起宮庫根酒消真息速庭島配倍病勉流旅案害挙訓郡候航差殺残借笑席倉孫帯徒特梅粉脈浴料連益桜恩格個耕財師修素造能破俵容留株胸降骨座蚕射従純除将針値展討党納俳班秘陛朗挨唄畝悦宴翁俺華蚊核釜陥既飢鬼恐恭脅恵桁倹兼剣拳軒娯悟貢剛唆挫宰栽剤索桟恣脂疾酌殊珠袖准殉徐宵症祥称辱唇娠振浸陣粋衰凄逝脊隻扇栓租捜挿桑捉泰託恥致畜逐秩衷酎朕逓哲途倒凍唐桃透胴匿悩剝畔般疲被姫浜敏浮紛哺捕浦俸倣峰砲剖紡埋眠娘冥耗紋竜倫涙烈恋浪脇捗栗浬桧哩恕耽狹倭乘倖紐峻凌屑哨豹臭隼啄祝悌悔莞晋海凉秦神訊圃赳倦莉氣秤祖祐桂閃峯娩桔紗涉笈烏祕荻栞砥莫紘矩眞峨晒柴栖朔窄峽套桐晟晏俱浩郞畠砧莊挽挺晃晄狼釘魚強教黄黒細週雪船組鳥野理悪球祭終習宿商章深進族第帳笛転都動部問貨械救健康菜産唱清巣側停堂得敗票副望陸移液眼基寄規許経険現混採授術常情責接設率断張貧婦務略異域郷済視捨推盛窓探著頂脳閉訪密訳郵欲翌尉萎逸淫陰菓崖涯殻郭掛喝渇乾勘患貫亀偽菊脚虚菌惧偶掘啓掲渓蛍舷控梗頃婚痕紺彩斎埼崎惨斬鹿執赦斜蛇釈寂羞渋淑粛庶渉紹訟剰紳酔崇据惜戚旋措粗掃曹曽爽唾堆袋逮脱淡窒彫眺釣陳偵添悼盗陶豚貪梨軟捻粘婆排培陪舶販描猫瓶符偏崩堀麻猛唯悠庸粒隆涼猟陵累紬雫朗徠祷彪淨祥桶猪釧訣菩敍兜捧畢掬萄袈將專梶從圈琢晝梯彬條寅舵陷淀國捺帶萌彗笠脩晦淋笙菱梁絆淚惇琉淳掠梧渚惟雀梛砦笹萊崚惚偲晨晚埜梓毬巢庵悉皐這袴捷羚絃菅冨逗牽逞埴敏梅椛逢捲萠眸凰菫菖梢森雲絵間場晴朝答道買番飲運温階寒期軽湖港歯集暑勝植短着湯登等童悲筆遊葉陽落開覚喜給極景結最散順焼象然隊達貯博飯費満無量街営過賀検減証税絶測属貸提程統備評富復報貿割貴勤筋敬裁策詞就衆善創装尊痛晩補棒揮握嵐偉椅詠越媛援奥渦葛喚堪換敢棺款閑幾棋欺喫距御暁琴遇隅圏堅雇喉慌硬絞項詐酢傘紫滋軸湿煮循掌晶焦硝粧詔畳殖診尋須遂随婿疎訴喪痩葬堕惰替棚弾遅貼超椎塚堤渡塔搭棟痘筒鈍廃媒斑蛮扉普幅雰塀遍募傍帽喩愉湧猶裕雄揚揺絡痢硫塁裂廊惑湾腕惺隈湊惡凱椀敦卿稀翔琵淵喬琶萱禄斐琥椋筈葡釉瑛裡惠堯雁琳皓黃堰單焚曾堺萬葵遥董琢猪竣巽虜著視葺萩戟喰腔爲湛惣都粥甥渚粟絢硯厨棲貰疏喧揃閏逸剩搜渴揭斯盜渥湘欽堵焰犀虛脹惹黑寓筑喋智註渾園遠楽新数電話暗意感漢業詩想鉄農福路愛塩試辞照節戦続置腸働解幹義禁群鉱罪資飼準勢損墓豊夢預絹源署傷蒸聖誠暖賃腹幕盟裏彙違煙猿鉛虞嫁暇禍靴雅塊楷慨蓋該較隔滑褐勧寛頑棄毀詰嗅僅愚窟傾携継詣隙傑嫌献遣誇鼓碁溝傲債催塞歳載搾嗣慈嫉腫愁酬奨詳飾触寝慎腎睡裾跡摂煎羨腺詮践禅塑僧賊滞滝嘆痴稚蓄跳艇溺塡殿塗督頓漠鉢搬煩頒微蜂飽睦滅誉溶腰裸雷酪慄虜鈴零廉賂楼賄溫溜詢頌瑚蒐蓉嵯楊椰葦裟蓑塙跨蓮馳稜蒔煉楢瑶滉幌舜遁嵩楯碗暉煌嘩獅傭碑愼碓蒲禽奧楓圓楕詫廊裝與馴楠祿鳩煤鼎禎椿搖傳蒼溢稔勤蒙牒暑瑞靖碎稟煮楚歌語算読聞鳴駅銀鼻様緑練管関旗漁察種静説歴演慣境構際雑酸精製銭総像増態適銅徳複綿領閣疑誤穀誌磁障層認暮模維隠寡箇概駆熊綱酵豪酷獄魂雌漆遮需銃塾緒彰誓箋漸遭憎駄奪端綻嫡徴漬摘滴稲寧髪罰閥碑漂腐蔑慕貌僕墨膜慢漫蜜銘網誘瘍踊辣僚瑠暦漏遡遜樺蔭禎斡壽摑鳶寢漱盡團綠蔣窪漢粹齊奬署嘉僧綸綺實槇榮遙僞嘆寬滯禍榎颯賓福蔓暢魁聡綜漕槍銑碩翠賑槙榛肇蔦輔碧箔厩箕頗緋蓬嶋鞄綴槌裳嘗爾膏閤漣鳳竪榊瑳綾摺線横談調箱億課器賞選熱標養輪確潔賛質敵導編暴遺劇権熟諸蔵誕潮論慰影鋭謁閲縁稼餓潰潟歓監緩畿輝儀戯窮緊勲慶憬稽撃稿駒撮暫摯賜趣潤遵憧衝縄嘱審震穂請潜遷槽踪諾誰鋳駐嘲澄墜締徹撤踏罵輩賠箸範盤罷膝賓敷膚賦舞噴墳憤幣弊蔽餅舗褒撲摩魅黙憂窯履璃慮寮霊餌慧澁播劍樋蕎徵憎撰樣瘦蕃彈鞍儉價撒幡緣磐稻增醇練節噌穀糊墨層樟蕉噂髮撞駈廣緖蝶諏德歎賣醉蕨鄭篇誼毅蕪黎蝦劉魯樂駕熙諄凛鋒諒遼嬉槻撫凜廟親頭館橋整薬機積録衛興築燃輸激憲鋼樹縦操糖奮緯憶穏壊懐諧骸獲憾還凝錦薫憩賢錮衡墾錯諮儒獣壌嬢錠薪醒薦膳濁壇緻諦賭篤曇濃薄縛繁避壁縫膨謀頰磨麺諭融擁謡頼隣隷錬賴樫醍龍曆衞諸蕾蹄默曉黛燈靜橫薙險縞橙薗燒燕樽戰錫鴨憐歷謂縣謁蕗錄醐輯勳澪橘叡錆鞘器錘燎鋸窺諺錐鮎講謝績厳縮優覧曖臆嚇轄環擬犠矯謹謙鍵購懇擦爵醜償礁繊鮮燥霜戴濯鍛聴謄瞳謎鍋頻闇翼療瞭齢徽薰螺駿鍬曙檢繁輿濡篠檜燭嶺謠彌擊霞縱瞥鞠鴻壕穗燦檎藁薩濕擢檀瓢應禪磯鍊戲顔曜題観験類額織職簡難臨穫顎鎌韓騎襟繭顕鎖瞬繕礎騒贈懲鎮藤闘藩覆璧癖翻癒濫藍糧鎭鯉穣鞭鎧藏蟬醬藝藥轉燿謹蹟儲麿壘襖叢雜簞櫂鵜雛禮願鏡識警臓韻艶繰鶏鯨璽蹴髄瀬藻覇爆譜簿霧羅離麗麓顚難贈櫓櫛簾瀨繫繡禱蘭曝麒寵鯛懷類蟹鵬壞瀕蘇瀧懲獸禰議競護響懸鐘譲醸籍騰欄馨騷嚴纂巌孃耀艦顧鶴魔躍露櫻轟纏飜鰯欄蠟鷄攝驚襲籠疊聽鷗饗鑄讃驍覽臟穰灘響鑑顯巖纖鷲鱒驗鷹麟鱗讓釀鷺廳鬱 {}

記号

日本では、このような記号が主に使われます。30個以上の記号があります。

記号に関しては使える文字と使えない文字があります。

無効な記号

記号	Unicode	呼称	備考
`。`	U+3002	句点
`、`	U+3001	読点
`「`	U+300C	始めかぎ括弧(全角)
`」`	U+300D	終わりかぎ括弧(全角)
`『`	U+300E	始め二重かぎ括弧
`』`	U+300F	終わり二重かぎ括弧
`【`	U+3010	始めすみ付き括弧
`】`	U+3011	終わりすみ付き括弧
`※`	U+203B	米印
`…`	U+2026	三点リーダ
`⋯`	U+22EF	Midline Horizontal Ellipsis
`〃`	U+3003	ノノ字点 / Ditto Mark
`—`	U+2014	ダッシュ（全角）	長音符ではない
`〜`	U+301C	波ダッシュ	「全角チルダ(U+FF5E)」は有効

10個以上の無効な記号があります。

句点や読点、カッコなどの記号は使えません。ただ、これらの記号は文章の最初、もしくは最後に書かれることが多く、実際には識別子としての必要性は低い文字ばかりです。つまり、これらの「無効な記号」は「日本語でのSwiftプログラミング」にとっては問題にならないでしょう。

唯一、識別子として一定の必要性を持つが無効な文字として「〜(波ダッシュ)」があります。「お〜いお茶」のような固有名詞や、自動販売機の「あったか〜い」といった表現をソースコードとして書くことが出来ないというわけです。残念ですが、そうした場面では何かしらの個別の対処が必要になります。

「〜(波ダッシュ)」の対処案の例
	内容	注意点
案1	「ー(長音符)」で代替する
案2	ほぼ同じ見た目かつほぼ同じ用途の「～(全角チルダ)」で代替する	・稀に「〜(波ダッシュ)」と「～(全角チルダ)」の見た目が異なるフォントがあるため、UI上で表示する際は要確認。・「～(全角チルダ)」で識別子を宣言した場合、「〜(波ダッシュ)」では対象識別子を呼び出せないため混乱を招く可能性がある。
案3	識別子をRaw Identifiersで宣言する。例: `あったか〜い`	Swift 6.2以降でしか動作しない

特殊な記号: 結合文字

Unicodeには結合文字という特殊な文字があります。結合文字は他の文字と合成することで新たな1つの文字を作ります。日本語では濁点や半濁点の結合文字があります。なんと、これらも使えます。

let あ゙ = "a"

func ト゚() {}

アルファベット

日本ではアルファベットをこれまで紹介した文字と組み合わせて利用されます。もちろん、アルファベットは識別子として使えます。全角アルファベットも問題ありません。

// ↓半角
let abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ = 123

// ↓全角
let ａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺ = 123

アラビア数字

日本ではアラビア数字も使われます。もちろん、識別子として使えます。全角アラビア数字も問題ありません。
半角アラビア数字は識別子の先頭では使えませんが、全角アラビア数字は使えます。

// ↓半角
enum A1234567890 {}

// ↓全角
enum １２３４５６７８９０ {}

文字の一覧

ここまで紹介してきた文字は、「一般的に使われている日本語の文字」です。

ただ、Unicodeには更に多くの日本語の文字があります。

	カテゴリー	一般的な文字の数	あまり使われない文字の数
✅	ひらがな	80	4
✅	カタカナ	82	106
✅	漢字	2999	3000+
⚠️	記号	19	28+
✅	アルファベット	104
✅	アラビア数字	20
✅	結合文字	2

「実際にはあまり使われない日本語の文字」を含めると約2倍の数になり、合計で6500以上の文字があります。

つまり、日本語の文字はほぼ全て使えます。使えないのは、いくつかの記号のみです。

【補足】識別子の文字の扱いについて

Python 3でも日本語で識別子を書くことができます。各識別子はUnicode正規化された上で識別されます。

一方、SwiftではUnicodeコードポイントベースになっています。

上記の「が」のような「見た目は全く同じだがコードポイントが異なる識別子」については多少の混乱が発生するかもしれません。
こうした状況を考慮すると、Swiftで日本語識別子を採用する際は「Swiftの識別子はUnicodeコードポイントベースである」という知識は持っておいた方がよろしいでしょう。

コンパイラ

次に、Swiftコンパイラについて検討してみましょう。Swiftコンパイラは日本語識別子を適切にビルドできるのでしょうか。
思い浮かぶ懸念を挙げてみます。

バグはありませんか？
英語と異なる振る舞いはしませんか？
パフォーマンスは落ちませんか？

これら、全く問題ありません。
(※あくまで個人の経験に基づきます)

Xcode

次は、Xcodeについて確認しましょう。Xcodeで日本語識別子を使っても適切に動作するのでしょうか。
思い浮かぶ懸念を挙げてみます。

そもそも日本語のテキストエディターとして機能しますか？
サジェストやその他の機能はスムーズに動作しますか？
- 特に日本語のIMEと競合しませんか？
日本語のフォントは適切に表示されますか？
- 文字化けしませんか？
- 中華フォント(俗称)で表示されませんか？
(識別子をファイル名に転用することは一般的ですが)ファイル名が日本語でも大丈夫ですか？
- フォルダー名が日本語でも大丈夫ですか？
XcodeにビルドインされているGitは大丈夫ですか？
- GitHubやGitLabといったGitホスティングサービスも大丈夫ですか？

これら、全て問題ありません。全て適切に動作します。
(※ターゲット名やパッケージ名に関しては私個人としては未経験かつ未検証なためノーコメントです。)

自動テスト

Xcodeにおける自動テストについても考えてみましょう。

XCTestではテストケースの書き方にルールがあります。testというアルファベットのプレフィックスを書く必要があります。少し残念ですね。

最近、これが解決しました。

Xcode 16で導入されたSwift Testingでは、testプレフィックスをつける必要はなくなりました。素晴らしいですね。

【補足】Stringリテラル

識別子ではありませんが、Stringリテラルについても検討してみます。

「Plain将棋盤」のアプリ言語設定は日本語と英語の2言語に対応しています。UI上で表示する文字列は日本語Stringリテラルで実装しました。

Xcodeプロジェクトの言語設定変えれば、日本語Stringリテラルでも概ね問題なく動作します。

しかし、そのような実装では「日本語圏でもなく英語圏でもないOS設定のデバイス」だと各UIが日本語で表示されます。そうしたデバイスでは一般的に英語の方が好ましいため、広く利用されるプロダクトでは英語Stringリテラルで実装する方がよろしいでしょう。(※自分の理解が浅いため不正確な情報かもしれません。)

ここまで、「日本語で識別子を命名すること」の実現性を検討してきました。

つまり、「SwiftとXcodeは日本語の識別子を完全にサポートしている」と言っても過言ではないでしょう。

全て日本語で上手くいくのか？

では、全て日本語で上手くいくのでしょうか？答えは、いいえです。

これまでの話は、全てSwiftの内側の話でした。Swiftの外側で日本語を使うことはリスキーです。

例えば、

Xcodeプロジェクトネーム
Bundle Identifier
URL
サードパーティーの開発ツールを使う場合…
- ファイル名
- フォルダー名
- ターゲット名
Swift外とのシリアライゼーション
- Codable

あたりでは「日本語を使うこと」に対して一定の注意を払う必要があります。

Bundle Identifierのようにそもそも仕様的に日本語は不可というパターンもあります。

前章でファイル名やフォルダー名は問題ないとお伝えしました。また、CodableもSwift内でエンコード&デコードする分には問題ありません。
しかし、サードパーティーの開発ツールを使う場合は注意してください。その開発ツールが日本語をサポートしているかどうかは、その開発ツール次第です。

(軽微な)具体的な課題

「SwiftとXcodeは日本語の識別子を完全にサポート」と前述しましたが、日本語識別子採用を明確に阻むほどではないレベルの軽微な課題はいくつかあります。

コード補完

英語では1回のキーボードタイプでコード補完がサジェストされます。

しかし、日本語では複数のキーボードタイプを必要とします。Xcodeのコード補完についてのTipsを紹介します。

Tips 1: キーボードショートカット

キーボードショートカットを使うことで、すぐにサジェストを表示することができます。

Tips 2: selfやSelf、メソッドチェーンなどを活用

selfやSelf、メソッドチェーン、型推論などを活用することでスムーズにコード補完を表示できます。

インデント

日本語フォントは英語等幅フォントのサイズと異なりますが、多くのケースで問題ありません。

ただし、引数の自動インデントが崩れてしまうことによって可読性が低下することがあります。
Xcodeのデフォルトフォントでは日本語はアルファベットと等幅ではありません。また、Xcode内蔵フォーマッタは日本語の1文字をアルファベット1文字相当として認識するようです。
全角1〜3文字文程度のズレであれば少しの可読性低下で済むのですが、全角4文字以上のズレの場合は可読性が著しく低下します。

Swiftは様々な構文を柔軟に採用できます。例えば、以下のような構文を採用することで可読性低下を軽減できたりします。

プロジェクトネームやパッケージネーム

「Xcodeプロジェクトネーム」や「SPMパッケージネーム」といったトップレベルの命名における日本語の実現性を考えてみましょう。

私は厳密な仕様について詳しくありませんが軽く試した限りだと、これらで日本語を使うことは仕様上は可能なようです。しかし、実際の実現性は非常に低そうです。詳細は割愛しますが、Xcodeの様々な挙動から察するに「AppleはXcodeプロジェクトネームなどのトップレベルで非アルファベットを使用することはほぼほぼ想定していない」感じでした。

前述したように「Swiftの外側で日本語を使うことは非常にリスキー」なため、Xcodeプロジェクトネームなどはアルファベットで命名するのが無難ですね。

ファイル名やフォルダー名

「ファイル名/フォルダー名は日本語でも大丈夫」と前述しましたが、あくまで「Xcode中心」かつ「Apple製ツールのみ使用」という前提の話でした。

ファイル名/フォルダー名における日本語活用にはとても根深い課題が潜んでいます。それは「ファイルシステムの仕様や正規化」です。

「Swiftでのソフトウェア開発」はmacOSだけではなくLinuxやWindowにも対応しています。macOSで作成したファイル名/フォルダー名がLinuxやWindowsでは変な感じになるという実際に起こり得るシナリオです。「濁点/半濁点がなぜか2文字として表示される現象」は典型的な例です。(私が詳しくないため詳細な説明は割愛します。)

[補足] 濁点/半濁点のパターン

濁点/半濁点が含まれている(合成済み?の)単一文字
結合文字による濁点(U+3099)や半濁点(U+309A)
半角サイズの独立した濁点(U+FF9E)や半濁点(U+FF9F)
全角サイズの独立した濁点(U+309B)や半濁点(U+309C)

Unicodeにおける濁点/半濁点は上記の4パターンあります。ファイル名でトラブルが起きて何か対策を取らなければならないとしても、これらで工夫すれば解決すると思います。(たぶん)

命名規則

一定規模以上のプロジェクトで全面的に日本語識別子を採用するケースでは、意外なポイントがやや大きな障壁となると思います。それは命名規則です。

一般にアッパーキャメルケースやローワーキャメルケースを使って型名などを区別しますね。

let data = Data()

let ??? = データ()

しかし、日本語ではこれを表現する明白な方法がありません。

「Plain将棋盤」では型名もインスタンス名も日本語で命名しているため、アッパーキャメルケースやローワーキャメルケースの使い分けによる可読性向上のメリットを得られていません。実際、プロジェクト規模が大きくなるにつれて可読性の低下は顕著に感じていました。

アッパーキャメルケースやローワーキャメルケースの使い分けをなんとか日本語でも表現できないかと調査や試行錯誤を重ねてみました。しかし、残念ながら自信を持って紹介できるような正解は見つかりませんでした。

(※この課題はSwiftに限った話ではありません。他のプログラミング言語でも同様です。)

LLMレスポンスの構造化

今秋公開されるiOS 26ではApple IntelligenceのオンデバイスLLMを呼び出せるFoundationModelsフレームワークがリリースされます。
FoundationModelsにはレスポンスの言語を指定する直接的なAPIがありません。特定言語でレスポンスを得る方法の1つとして「プロンプトなどを対象言語で記述すること」が挙げられます。
FoundationModelsの「構造化レスポンス」では(JSONではなく)Swift型宣言に合わせてLLMレスポンスを取得できます。その際、型名やプロパティ名をLLMの入力として活用されます。つまり、構造化レスポンスで日本語レスポンスを得たい場合は日本語で型宣言すると良いのかもしれません。

@Generable
struct 小説 {
    var 小説の題名: String
    var 小説の本文: String
    var 作者: String
    var 出版日: String
}

let session = LanguageModelSession()
shousetu = try! await session.respond(to: "", generating: 小説.self).content

詳しくは以下の記事を参照してください。

Raw Identifiersについて

Swiftの最新バージョンであるSwift 6.2の新機能「Raw identifiers」を紹介します。
識別子をバッククォート(`)で囲むことによって通常では無効な文字も識別子として有効になります。

enum 温度設定 {
    case つめたい
    case `あったか〜い`
}

enum 商品名 {
    case エビアン
    case `お〜いお茶`
    case 健康ミネラルむぎ茶
    case `TULLY’S COFFEE`
}

前述した「〜」や句点、読点といった無効な日本語文字も識別子として採用することができるようになるのです。
「日本語でのSwiftプログラミング」において必ずしも必要なテクニックというわけではないですが一応紹介しますね。

段階的導入

「Plain将棋盤」アプリでは全ての識別子を日本語で命名しましたが、「日本語でのSwiftプログラミング」としては極端な例になります。「日本語でのSwiftプログラミング」はピュアSwiftであり、英語とともに書くことができます。つまり、段階的に日本語識別子を導入できるのです。

まず、「固有名詞」や「自動テスト」などで日本語識別子を検討してみると良いのではないかと思います。

「仕様やUI上の表現」をそのまま転用するのも良いと思います。

登壇後の情報交換

try! Swiftでの登壇の後にオフィスアワーや懇親会で多くの日本語話者Swiftデベロッパと情報交換しましたが、日本語識別子プログラミングを実践しているエンジニアはほぼほぼ居ませんでした。

自動テストにおいては日本語識別子が結構使われているらしい

ただ、「自動テストにおいては例外的に日本語でテストメソッドを命名している」というエンジニアが数名いらっしゃいました。趣味のソースコードではなく、プロダクションのソースコードでそういった運用をされているそうです。

Appleデベロッパリレーション

AppleデベロッパリレーションのMasashi ToyotaさんやShun Takeishiさんもtry! Swiftの会場に来られており、私の登壇も聴講されていました。登壇後、お二人に「日本語識別子の採用事例を知っているか？」などの質問をしてみましたが、残念ながらそういった事例や取り組みは特にご存じないようでした。

リクエスト

try! Swift登壇というせっかくの機会ですので、皆さんへリクエストを伝えたいと思います。

SwiftやXcodeに対する(優先度高めの)リクエスト

登壇が決まってからの2ヶ月間ほどずっと考えてきましたが、ありませんでした。

これまで説明した通り、SwiftやXcodeは日本語の識別子を完全にサポートしています。そのため、リクエストは必要ありませんでした。

(※予約語やフレームワーク、XcodeのUIを日本語にすることは求めていません。)

SwiftやXcodeに対する(優先度低めの)リクエスト

優先度が低いリクエストはいくつかあります。もし「日本語でのSwiftプログラミング」が普及し始めた際には、AppleやSwiftチームにはこれらの改善を検討していただきたいですね。

その1: 日本語識別子のインデント対応

前述した通り、日本語識別子ではインデントがズレるケースがあります。幸運にも日本語の大半は「全角(Full width)」という固定のサイズなため、対処はしやすいかなと思います。ぜひ、Xcodeのフォーマッタに「全角文字に合わせたインデント補正」を実装していただきたいです。

その2: Xcodeプロジェクトネームの日本語対応の改善

プロダクションレベルではXcodeプロジェクトネームはアルファベットベースの方が良いと思います。ただ、プロトタイピングやSwiftプログラミング入門といった場面では日本語でXcodeプロジェクトネームを命名できるとスムーズで嬉しいですね。

日本語話者に対するリクエスト

日本語で識別子を書いてみましょう。

ピュアSwiftなので準備は必要ありません。
英語とともに書くことができるので段階的に導入できます。
一緒に日本語の識別子についてのベストプラクティクスを探していきましょう。

非英語話者に対するリクエスト

あなたの母国語で識別子を書いてみましょう。

(日本語に限らず)Swiftは様々な非英語言語に対応しています。
ピュアSwiftなので準備は必要ありません。
英語とともに書くことができるので段階的に導入できます。

ぜひ、あなたの「母国語でのSwiftプログラミング」について教えてください。

余談

Appleはデベロッパ向けの情報をApple自身で日本語翻訳しています。高品質な翻訳で、日本語話者にとって非常にありがたい存在です。

トップページだけではなく、特集ページやニュース、ビデオ、ヒューマンインターフェイスガイドライン、これら全てに公式の日本語翻訳があります。これらは、OSアップデートや最新デバイスについてのキャッチアップを強力にサポートしてくれます。Appleに感謝ですね。ありがとうございます。

ちなみに、APIリファレンスやチュートリアルシリーズ、XcodeのUIには、日本語翻訳が存在しません。逆に言えば、この3つ以外は日本語翻訳がある状況です。

もうひとつ余談

有志によってSwift公式リファレンスを日本語翻訳するプロジェクトがあります。こちらの方々にも感謝です。ありがとうございます。

まとめ

Swiftにおいて日本語識別子は適切に動作する。
Swiftの外で日本語を使うことは安全ではないので注意が必要である。
日本語でのSwiftプログラミングに挑戦しよう。