らんらんアドカレ 9日目、待降節第二火曜日の記事です。前回の記事(一昨年)では中国語で書いたものの、結局誰も読めなそうな感じだったので日本語に戻します。

本当は今年こそは(語³アドカレに)記事を書こうと思っていたものの、人工言語アドカレ記事の存在をアドベント始まって暫くするまですっかり忘れていた大間抜けです(昨年は人工言語アドカレ記事の存在自体は覚えていて苔塔アドカレに名乗りを上げていたものの記事を落とした間抜けをやらかしたので、今年こそは...と思っていたんだけども....orz)

---

皆様お久しぶりです、佐藤陽花です。(往々にして方々で名前が出てきがちなうちの一人だし、多くの界隈人は私のことはご存知だと思うので、改めての自己紹介は省略します)

はじめに

さて相変わらずして人工言語多産の佐藤陽花であり、以前から継続して制作しているオ ェｼﾞｭルニョェーッ語 (オエル語)やオイナルシャルム語のほか、最近も制作しだしている共作言語や個人言語などの諸言語がありますが、数週間前に某所でCLAコードに関するお問い合わせと新規申請をいただいたこともあり、今回は個別人工言語の話題ではなく、CLAコードの現況と今後の展望について書いていこうとおもいます。

---

CLAコードといえばこのサイト、Migdal (SNS)にも重要な(記事(やその一部)の言語指定において人工言語を指定出来るように成り立たせている一つがCLAコードです (もう一つが同じくCL-KIITAの策定しているLIISコード及びその補助仕様))。

CLAコード - Conlang Layered Assignment

以下、 人工言語Wiki記事や、個別申請における説明内容、CLAチーム内部の運用規範などを掻い摘んで、また整理して説明していきます。

CLAコードの概説

CLAコード(Conlang Layered Assignment コード)とは、ISO 639 に倣い、各人工言語のコードを規定するものです。このコードを用いることで、辞典データなどのデータベース上や、各種アプリケーション上・システム上で人工言語を取り扱いやすくなります。

2015年7月21日におかゆ氏により初版(CLA v1)が提案され、運用されていました。2021年8月5日に提案された試案(CLA v2)を経て、これをもとにCL-KIITA (人工言語知識情報・情報技術事業体)において現行版(CLA v3)の仕様策定が進められ、同8月17日に仕様の策定、9月2日に標準規格が発行され、以降これが運用されています。

コード仕様概略

CLAコード(CLA v3)こと人工言語層状割当コード(Conlang Layered Assignment Code)は、広い方から制作者(個人、共同、又は集団)、語族(語族・語派など言語グループ)、言語、方言の4階層から構成されていて(大雑把に分けられているだけなので層の名前にそこまで縛られる必要はなくある程度柔軟にできます)、それぞれ英小文字3字、3字、2字、2字のコードを割当られます。語族及び方言はないことも可能で、その場合は「未定義」と記録されます(「未定義」というネーミングはプログラミング界隈の用語なので余り気にしないでください)。

また制作者及び語族、言語及び方言はそれぞれ一つの名前空間を構成しており、制作者及び語族はグローバルに、言語及び方言は語族ないし制作者ごとにユニークなコードを持たなければなりません。

申請の方法と手続

CLAコードの申請には、まずそのコードの指し示す対象となる人工言語(やその方言等)の制作者(或いは代理者)たる申請者が、どのコードが良いか決めるところから始まります。

コードの決め方については(CLAコード仕様に基づかなければならないこと以外は)決まりはなく、申請者の自由となっています。なお、概ね次のような手法が慣例になっています。

• 原語名称のASCII英字への翻字をベースとする。
• 数字はa, b, c, ...或いはi, ii, iii, ...などに置き換えるか、又はその言語/方言による読み方を用いる。

また、申請において希望するコードの各々(各層)につき、何の何処の部分からどのように採ったのかの釈明を添付する必要があります(これをもとに申請されたコードが妥当かどうか判断します)。その他、その人工言語(或いは方言)が実際に存在することを明らかにするもの(資料サイトや紹介記事・辞書など)の提示をお願いしています(なお、制作者が審査担当者と知己深く、存在が既知である場合は提示の省略を許すことがあります)。

コードの申請は、制作者/語族/言語/方言の各層に区分して行い、その各々について個別に申請・審査されます。既に発行された制作者コードに属する言語コードの場合、言語コードのみの申請者で十分であり、他のケースも同様です。

各々の層について、申請において必要な項目は、上記に示したものを含め次の通りです。

• 層の区分
• コード要素
• コードの選定の釈明
• 対象の存在証明
• 原語名: その言語の自称(内名)をUnicode記録可能なよう適宜転写等を施したもの
• 日本語名: 主に日本語やアジア諸言語中で言及される場合のための名称で、漢字(変種(地域字形)を含む)及び仮名(変体を含まない)を用いることが出来る
• 英語名: 主に欧文中で言及される場合のための名称で、ダイアクリティカルマークや合字を含むラテン文字を利用することが出来る。
  • 目安として、Latin-1、Latin-2、Latin-9及びLatin-10、並びにこれらに(単体又は合成済み形で)出現するダイアクリティカルマークや合字が利用可能
• 読み仮名: 主に口頭で読み上げたり記述上においてソートする場合のための表記
• ASCII翻字: 主にシステムの内部で取り扱う場合のための表記で、原語名を標準ASCII英字に縮退転写させたもの

この他、規則及び慣習に従って審査チームが独自に採録し記録する項目があります。

コードの申請が提出されたときは、申請チームは速やかに審査に着手します。申請者と対話したり調査したりしつつ、審査事項・留意事項について点検し(不備があれば適宜修正や追加説明を求め)、問題ないことが確認できたら承認して付与・発行します。

なお、申請の結果、申請チームの一員たる審査者による最終判断は次の3種類あります。

• 承認: 審査の結果申請内容に問題が見られず、かつ申請を受け入れることができない事由が存在しない場合
• 棄却: 申請内容に不備が存在し、かつそれが修正されない場合
• 留保: 本人申請原則への抵触など、申請自体には問題ないが、申請を受け入れることができない事由が存在する場合 (その事由及び解除条件を明示の上で行われます)

審査チームについて

CL-KIITAの中でも特に、コード割当総部 (Code Assignment Authority; CAA)という部署がコード類の策定＆運用・発行を担っています。コード割当総部はコード類やシステムの規格策定・仕様策定を担う「策定チーム」と、コード類の運用・発行を担う「審査チーム」に分かれています(往々にして共通メンバーがいますが)。

審査チームのメンバーは、全体の運営管理と審査・発行を担う審査権者、雑多な事務処理や記録管理を担う総務書記、そして外国語による申請や問い合わせに対する窓口通訳とに役割分担しています。なお、審査チームの現行のメンバーは次の通りになりますので、お見知りおき下さい。

• 審査権者 (= 審査担当者)
  • 佐藤 陽花 (@halka_ffez)
  • Ziphil (@ziphil)
  • Xirdim (@xirdim)
  • かえる (@kaeru2193)
• 総務書記
  • Atridott (@atridott)

手動発行体制の報告と経緯

CLAコードv3の仕様策定・運用開始以来、(同じくCL−KIITAメンバーの)Ziphilさんの開発によるCLAコードPortal(Webアプリ)で申請及び審査・発行を行なっていました。しかし、当時用いていたホスティングサービスに関連する事情で、2022年11月28日付けにて当該Portalの運用を終了し、(次世代Portalの開発を続行しつつ)手動体制にて発行してきました(2023年4月16日付けで「後ほど正式な発表をする予定」と言及していましたが、まさかの2年半越しとなってしまいました)。

ここMigdal(SNS)を管理しているA.I.御大による機能紹介記事には未だポータルへの言及とリンクがありますが、現在使用出来ないのでご留意ください。

(後ほど正式発表すると言及していた)非正式発表曰く、

半年〜一年以内には後継システムを開発・稼働させる予定ですが、現在は暫定措置として人力による手動登録・管理を行っています。

このような事情のため、コード付与をご希望の方やコード照会、お問い合わせなどは当分の間、本拠CL-KIITA鯖やその他DLL鯖等、KIITA言語コード担当者(総代表の私佐藤陽花、主任のじふぃるさん、又は事務役のXirdim)のいる汎人工言語鯖や、KIITA言語コード担当者本人のDM等で、当該担当者までお申し付けください。

(但し多忙等の理由で対応にお時間を頂くことがありますので、ご理解ご了承の程宜しくお願い致します)

という内容となります。

(ここでも「半年〜一年以内には後続システムを」と言及していますが、相変わらずして何年も時が経っているものの、余り進捗が出せず、後続システム始動の目処が全く見えない状況です)

---

CLAコードはかねてより手動発行体制となっているわけですが、まずは簡易API＆簡易ツールによる半自動の手動体制にしようというのが私達CLAコード審査チームの当面の思惑です。

実際、数日前から私が簡易API＆簡易ツールの仕様作成＆開発に取り掛かかっているところです。

手動発行体制の手続

手動発行体制では、本拠CL-KIITA鯖やその他DLL鯖等や、あるいはDM等でのメッセージにおいて、はたまた対面やVCでの会話によって随時受付ております。申請者本人が所定の申請様式を備えたメッセージないし電子ファイルを審査チーム成員に送付するか、あるいは審査チーム成員が申請意思及び申請内容を聴取してこれら所定様式に起こします。このあと、通常の手続と同様に審査・発行がされます。

手動発行体制においては、発行したコードはDiscordのアナウンス機能による告示をもって有効としてきました(なお、それ自体によって有効となる訳ではありませんでしたが、Discordのアナウンス機能による告示自体は以前のポータル発行体制においても用いていましたし、次世代ポータルでも同様とする予定です)。なお、このアナウンス機能のみだと到達範囲が思いの外狭く、有用には周知出来ていないきらいがあったので、有難いことにみかぶるさんが纏めリストを作ってくださいました。

CLIR Assignment Management Table

ここ最近はCLIRという(CLIRのCとRはそれぞれConlangとRegistryですが、間のLとIが自分でも謎)という基本台帳(現時点ではGoogleスプレッドシート)及び周辺プログラムを使って管理しています。

(’25年12月9日午後追記 ― CLIRのIはIdentifiersでした)

さいごに

末筆になりますが、皆様におかれましては今後ともCL−KIITAとCLAコードへのご理解のほどよろしくお願いします。また、CLAコード及びシステムの策定や運用、発行に協力したいひと、興味関心があるひとは非常に大歓迎ですので、どしどしお声がけ下さい。

---

アドカレ枠の余剰が残っていて、CLIRの実装がある程度終わって、かつ記事執筆の時間的余裕と体力的余力が残っていたら、CLIRの基本仕様と使い方を紹介する続編アドカレ記事を書きたいと思います(期待しないでください)。