包むのは物言い、中身は包まへん#

京都弁のスキルで一番こわいのは、婉曲が中身にまで掛かることだ。「バグです」が「ちょっと気になるとこがあるかもしれまへんなあ」になると、情報が変わってしまう。そこで、京ことばにするのは利用者に話しかける地の文だけにした。

• コード、コマンド、パス、数値、エラーの引用、専門用語は標準のまま
• コードのコメント、コミットメッセージ、PR の説明など、ファイルに書くものも標準語のまま（後で別の人が読むため）
• エラー、断り、取り消せない操作の確認では、いけずを使わず結論から言う

最後の項目について、スキル本体には「京都の人も、火事のときに遠回しには言いません」と書いてある。

京都らしくない形を表と検査スクリプトで止める#

モデルに京都弁を書かせると、決まった誤りが出る。大阪弁の混入（せや、〜ねん、けえへん、言いはる）、形容詞に「どす」を付ける（高いどす）、舞妓さんの口まね（何どすえ）などである。これをスキル本体の表にまとめ、同じものを正規表現の検査スクリプトでも拾えるようにした。

1
reply.md:1:1: [error] osaka-seya 「せや」 → そや（「せや」は大阪の形）
2
reply.md:2:6: [error] haru-renyou 「言いはった」 → 言わはった（5段動詞の「はる」は未然形に付く（連用形に付けるのは大阪の形））
3
reply.md:3:1: [error] adj-dosu 「高いどす」 → 高うおす／高うございます（ウ音便＋おす）（形容詞に「どす」は付かない）

文法や京阪の違いは、主に「京言葉」というサイトを参考にした。とても詳しいサイトだが、転載は非商用に限られる。okureyasu は MIT ライセンスなので、サイトの文章は写さず、事実だけを自分の言葉でまとめ、例文はすべて自作している。

いけずは一滴#

京都弁らしさを残すために、いけずは残した。ただし、愛される話し方にしたいので約束を付けた。

1. いけずの後には、同じ返答の中で本音を言う（種明かし）
2. コードや状況に向けて、人には向けない
3. 1 返答に 1 つまで
4. エラー、断り、危険な操作の確認、困っている人には使わない
5. 本気で褒めるときは「ほんまに」と理由を付けて、いけずと区別する
6. 最後は手を貸す

効き方の違いは、コードレビューで比べるとよく分かる。名前が一文字だらけの関数を渡したときの書き出しだ。

スキルなし。

まあ、えらいすっきりした短いコードどすなあ。名前もみぃんな一文字で、書かはったご本人さんしか読めへんよう、よう工夫してはりますこと。

スキルあり。

えらい無口なコードどすなあ。d も r も x も、's' も 'p' も、誰も名乗らはらへん。……ほんまのこと言うたら、動きはこれで合うてます。そやけど、半年後に読んだら何の処理か分からんようになりますさかい、名前と数字に意味を持たせときましょ。

スキルなしのいけずは書いた本人に向いていて、この後は見出しと太字で区切ったいつもの書式に戻る。スキルありは、いけずをコードに向けて一つだけ言い、すぐ本音に移っている。

試用して直したこと#

あっさりで試していて、「丁寧語に近いな、特に返答の途中」と感じた。そう伝えると、こう返ってきた。

張り替えときます。あっさりが丁寧語寄りに聞こえるいうのもその通りやわ。自分の返答を読み返したら「〜しときました」「〜です」がずっと続いてて、京都の言葉いうより、ちょっと訛った丁寧語になってた。

そのまま、あっさりの定義を「常体が中心、です・ます は頼むときと謝るときだけ」に直し、検査スクリプトに「あっさりで です・ます の文末が3文続いたら警告する」項目を足すところまで進んだ。直したあとの報告は、ちゃんと常体で締めていた。

この返事も直した定義で書いてる。まだ硬いとこがあったら、また言うて。

自分の滑りも、京ことばで申告してくる。はんなりで話していたとき、スキルで使わないと決めた「〜まへん」「〜まひょ」が出てしまったのだが、次の返答でこう言ってきた。

それと、言うとかなあきません。さっきの返事で「効くとは限りまへん」「置いときまひょか」と書いてしまいました。「まへん」「まひょ」はこのスキルでは使わへんと決めた形どす。試用で見つかった滑りとして、覚えときます。

この後も、二人称は使わないと決めていた「あんさん」を使ってしまい、また自己申告していた。どちらも引き継ぎメモに残してあり、次に直す。

こってりで README を組み替える#

README に「スキルなし・あっさり・はんなり・こってりの例文を載せたほうがいいか」と、こってりで聞いたときの返答。

へえ、載せといたほうがよろしゅうございます。ただ、半分はもう README に入ってますさかい、足すより組み替えるほうがすっきりしますやろ。

提案は具体的で、「例文は手で書かんと、実際の返答から取ります」「表にはせんと、引用を4つ縦に並べます」と続いた。実際に同じお題で4通り（後に標準語を足して5通り）走らせ、その返答から README の比べを作っている。

公開前のセキュリティ点検も京ことばで#

public にする前に、漏洩がないかの点検を頼んだ。ここで、コミットの作者メールアドレスが個人のアドレスになっていることを指摘された。GitHub の noreply アドレスに書き換えて force push したが、それで終わりではなかった。

はっきり申し上げときます。このまま public にしたら、Gmail は見えます

ブランチから外れた古いコミットを、GitHub はしばらく消さずに持っとります。

書き換え前のコミットのハッシュを GitHub の API に聞くと、古いコミットがそのまま返ってきた。ハッシュを知っていれば、public にした後でもブラウザで開けてしまう。結局、まだ Issue もスターもない状態だったので、リポジトリを一度消して作り直し、書き換えた後の履歴だけを push してから public にした。点検とリポジトリの作り直しで約10分、公開の設定（Secret scanning、説明文、トピック、タグと Release）まで含めても約20分だった。

内容は真面目なセキュリティの話なのに、報告がずっとこってりの京ことばで返ってくる。「取り消せない操作の確認では結論から言う」という決めごとも、ここではちゃんと効いていた。

京都弁にしても、開発は普通に進んだ#

始める前は、京都弁で話させるとモデルの能力が落ちるのでは、という懸念もあった。方言で話すことに気を取られて、肝心の作業が雑になるのではないか、という心配である。

実際には、京ことばで話していた後半の約1時間20分（18:38〜19:58）も、開発は普通に進んだ。この間にやったのは次のような作業である。

• 試用中のスキルをコピーからシンボリックリンクに張り替える
• あっさりの定義を直し、検査スクリプトに項目を足して、テストを通す
• README 用に同じお題を5通り並べて走らせ、その返答から比べの節を組み替える
• その過程で見つけた検査スクリプトの漏れ（「こうへん」）を直し、テストを足す
• 全ファイルと全履歴の漏洩点検、履歴の書き換え、リポジトリの作り直し
• Secret scanning の有効化、タグ付けと GitHub Release の作成

しくじりは1回あった。ワークスペース側の CLAUDE.md を書き換えるときに括弧の全角と半角を取り違え、中身の入っていないコミットを作ったのだが、自分で気づいて push の前に直していた。京ことばのせいかどうかは分からない。

おそらく、京ことばにするのを話しかける部分だけにしたのが効いている。コード、コマンド、コミットメッセージは標準語のままなので、作業の中身は普段と変わらない。評価でも、スキルありの返答は確度を落とさなかった。コードレビューの場面で、スキルなしは「float で 1 円ずれることがあります」と言い切ったが、スキルありは「今の範囲では同じ値になる」と確かめたうえで整数演算を勧めていた。もっとも、これは1回ずつの比較と体感で、能力の差を測ったわけではない。

楽しかった#

作ってみたら、これが意外と面白くて楽しかった。

作業の報告そのものは、標準語のときと中身が変わらない。それでも「張り替えときます」「足しときました」くらいの軽いやりとりが続くと、こちらの返事もつられて「張り替えておくれやす」「いい提案どす。足しといて」になっていった。

ただ、筆者は大阪生まれで、京都にもしばらく住んでいたが、大阪なまりのほうが強い。こってりの提案に「ほな言いはるとおり組み換えで提案してみせて」と返したのだが、「言いはる」は検査スクリプトが大阪の形として拾う誤りである。作った本人がいちばん京ことばを間違えている。