漢数字文字列のもう一歩実用的な数値変換 - その1

ブラウザアドオンを開発した際に、漢数字の文字列から数値への変換を実装しました。
せっかくなので何をしたのか、必要な知識などをまとめた次第です。



この漢数字変換を使っているのは、 daisy WarekiConv という和暦を西暦に変換表示してくれるブラウザアドオンです。

(Chromeにも対応。)
昭和や皇紀といった和暦で表記された年号を、頭で計算しなくても西暦に自動計算して表示してくれます。
このとき、和暦は年が漢数字で表記されていることが多かったため、漢数字文字列の変換が必要になった次第です。


なおソースコードをgithubのWarekiConvプロジェクトページにて公開しています。

(`kanNum.js`というファイルが漢数字変換なのですが、名前を変えるかもしれないので直リンクはしていません。)

## 前段の処理 / 文字列から漢数字列の抽出

実際に変換を行うまえに、まず必要な前処理から。
現実では解説などの文字列のなかに対象が埋まっており、漢数字部分だけ綺麗に存在するわけではないので抽出が必要です。

方法としてはあまりに単純、すべての漢数字文字を変数にあつめておき、これで作った正規表現でマッチをかけます。

```
const rsRekiStrNum = `元年|\\d+年?|[${wideNumAllChars}]+年?`;
```

## 漢数字文字列のいくつかのパタン


全角数字は
`1024`
くらいしかパタンがないのですが、漢数字はいくつかのパタンがあり、ちょっとした細則も持っています。

漢数字の場合は、以下のパタンが考えられます。
`一〇二四`
`千二十四`
`壱阡弐拾四`
`壱阡廿四`

大きなパタン分類として『桁の有無』、桁を書く場合と書かない場合があります。
-- 桁を書く場合、数がゼロの桁は桁の文字を省略する。
-- 桁を書かない場合、数がゼロの桁は`〇`。

さらに、以下のようないくつかの細則があり、またバリエーションが生まれます。
- 桁の数字が`1`のとき、文字を省略する場合としない場合がある。
- 『漢数字』と『大字』2種類の文字がある。
(この説明では、記述により多くの場合は両方まとめて漢数字と呼びながら書いています。)
- 『漢数字』『大字』では、同じ数字を表す文字が1つではない場合がある。
- 桁と数が一緒になっている文字もある(例:'卄'が20を表すなど)。

桁の数字が`1`のときというのは、たとえば1000の場合、
`千`
`壱阡`
のどちらでもかまわないということです。

漢数字、大字はそれぞれ
'〇一二三四五六七八九'
'零壱弐参肆伍陸漆捌玖'
というやつです。

同じ数字をあらわす文字として、たとえば以下はすべて『2』です。
'二弐弌貳貮弍'

----


以上、本記事では数字をあらわす漢数字と大字の文字列について、あつかうための前処理とパタン、また変換のさいに考慮しなければならない細則について書きました。
その2では実際に文字列から数値へ変換をおこなっていきます。

局地戦闘機『震電』ゼロベース制作(1/700スケール模型) - その2

 その1ではフルスクラッチで最初の大まかなモデリングと、3Dプリンタでの出力までを行いました。

この記事ではその続き、スジボリなどによるディティール追加と、量産、ついでに色つけについて書く予定です。




## スジボリなどによるディティール追加

最初は脚部のために、画像の通り腹を上に向けて出力していたのですが、スジボリを入れはじめた時にスジボリが綺麗にでるよう腹ばいに変更しました。
そのままの向きでは、スジボリの交点に下端が発生するため主翼の平面上にランナーが生えて、きれいに切り取るのが大変になります。



下付きだと脚にランナーがはえますが、細長いパーツのため、ランナーを外す作業中に折れてしまいます。
実際作業中に何度か折ってしまい、そのつど強度不足ということで脚太さを修正しています。



特に震電は特徴的な後部脚が翼から生えており、
事前に見えづらい箇所に支持枝をデフォルメした補強を入れていたのですが、これもつど厚く大きく変更していきました。

あわせて全体の形状も、当初の実機に近い形状から、どんどんデフォルメを強めています。

 
前脚は直線的なのと、元から根本を太めにしていたためか、先端の細い部分も意外と折れませ
んでした。

とはいえ丈夫であるにこしたことはないので、後脚を太くするたびにこちらも太くしていきます。
(前脚は後脚より細いという実機の関係が保たれていれば、外観としても太さを合わせたほうが見た目がよく思います。)
 

スジボリについて、1/700 ではこれくらいだと全然スジボリが出なくて、かなり強くデフォルメが必要です。



もちろん最初は実機スペックを踏襲してモデリングしていたわけなのですが、強度やら何やら対応していくうちにどんどんデフォルメされていきました。
最終的に全長と全幅しか元スペックが残っていないのでは。
どちらにしろ1/700スケールで実機ママというわけにはいきませんが。
強度の問題もありますが、ヒトがモノを見るときの仕組みとして、モデルが小さすぎるため実機どおりのままのほうが実機と違うものに見えてしまうものなので。




銃口は、先頭部分にあいている銃口の穴も追加しました。このサイズではパット見では肉眼で確認できないのですが、よく見るとあるのがわかりますし、塗装してもいちおう潰れません。



垂直尾翼にもスジボリを入れてあります。
なお試作中に付けられていた尾翼の車輪はいずれなくなるとのことだったので、つけていません。

プロペラについて、量産では4翅プロペラになる予定だったそうなのですが、見慣れているであろう6翅プロペラをデフォルトにしました。
4翅版はモデルのプロペラ部分を置き換えれば簡単に作れます。


露光時間を1.5secに伸ばしたので細かい溝は埋まってしまうかと心配していましたが、最終的には上手くいってよかったです。


## 量産
Blenderではなく、スライサソフト上で増やしました。
CHITUBOXでは、ランナーを生やした状態で、ボタンひとつで増やせるので便利でした。

1つで出力して問題なく造形物が出てきていれば、特に悩むことはなく。



## 色つけ
レジンが白色なので、サンプル画像的にも海軍機らしい色が欲しくて着色を行いました。

『タミヤ エアーモデルスプレー No.21 AS-21 暗緑色2 (日本海軍) 』を数回にわけて吹付け。
細かい色分けは筆が必要だと思います。



海軍機は実際には灰色だという話もあるのですが、そうはいっても緑色のイメージは根深く、また震電は実験機で緑の機体しかないのでまあいいかなという判断です。




しかし艦上に並べるという。しかも戦艦の。水上機でもないのに。
ついでにいうと、震電はB29迎撃を意図した局地戦闘機かつ、プッシャ式のため滑走距離が長い(プロペラ風が翼に当たるのが重要らしい)とのこと。
緑のプッシャ機が甲板上に並んでいる絵はヘンテコの上にヘンテコというわけですが、あくまで実作例なので。


## おわりに
1/700震電モデリングの動機は以降のプロジェクトの前準備だったのですが、いろいろ楽しかったです。
また1/700では表現できることが限られるため、逆に作業工程がすっきりしていて、はじめての航空機模型の制作としては大変ありがたかったです。
(1/700 伊507フルスクラッチ デザインのときは、どこまでやろうか何ができるかと大変悩みました。)

伊507をモデリング&出力したときはもっといろいろやったので(モデルにも震電よりいろいろBlender機能を使ったり)、そのうちまとめて公開できたらなと思っています。

船舶模型メーカの艦載機、1/700なのにディティールすごい。
作ってあらためて、金型による成型の精度のすごさを思い知った感じです。
(主商品である船舶模型のディティールもこれくらい細かく...とか思ってしまいますが。)



3Dプリンタの解像度の限界を思い知りました。といってもこちらは設定の追い込みとかすれば違うのかもしれません。

 

とはいえ思っていたよりもずっとよいものが出来たので、pixiv/BOOTHで「震電 局地戦闘機 1/700 モデル」出力した模型を販売することにしました。



さて今後の予定について。
「震電」の1/144スケールモデル作成、また同じ1/144で「イリス漁業連合 汎用護衛戦闘機『桃音』(設定検証モデル)」を作ろうと考えています。



局地戦闘機『震電』ゼロベース制作(1/700スケール模型) - その1

 局地戦闘機『震電』の1/700スケール模型を作成した際の作業記録です。



無料の3Dモデリング ソフトであるBlenderでデジタル制作して、3Dプリンタで出力しています。

(3Dプリンタで作ってみた系のブログ記事はけっこうありますが、
観測範囲では内容はほとんどがプリンタの精度の話などで、ノウハウについても出力失敗時の硬化時間の工夫くらいで、
出力するためのモデルの作り方とか、実際に作っているときのトライアンドエラーの話はあまりされていないような気がしていたので、
そういう内容をいくらか含んでいます。)

『震電』は第二次世界大戦時に大日本帝国海軍により試作された局地戦闘機で、
前翼型(エンテ型)・推進式(プッシャー式)の、めずらしい形をした高速戦闘機となっています。

試作のみで終戦を迎え、実戦では使用されていません。

今回はこの『震電』を、艦船模型など組み合わせやすい 1/700 スケールで作成しました。

似たようなものには、艦船模型と合わせるための 1/700スケール 戦闘機の、
- ピットロード 1/700 スカイウェーブシリーズ 世界の現用戦闘機セット 
(F-15C, F-15J, タイフーン等)
- 静岡模型教材協同組合 1/700 ウォーターライン 日本艦載機 前期型
(零戦21型、99艦爆、97艦攻、彗星)
などが模型メーカから出ています。

主な仕様:
- 艦船模型と合わせやすい1/700スケール
- 艦船模型と合わせるので脚ありの接地モデルとする
- プロペラあり
- 船体外板のラインを入れて、ある程度ディティールをもたせる
- 3Dプリンタ出力と、塗装などの加工作業、移動や輸送を気軽にできる丈夫さ
- 扱いやすく手間のかからない一体型
(注意:足が折れやすいと思われるので対処が必要)

資料:
「異端の空」(文春文庫/渡辺洋二)
「幻の戦闘機」(光文社NF文庫/碇義郎)
参考:
wikipediaの震電のページ
https://仮想艦隊.jp/cms/blog5.php?itemid=139 の「震電オリジナルの図面」




スケール算出:
制作の前にサイズ感を得ておく。
同規模の競合である零式などはおおむね1円玉の上に乗るサイズであることが作例などからわかっています。

全幅11m の 1/700 = 1.571cm

また震電の実機サイズはあらかじめわかっています。
そこで制作は簡単のため原寸(1/10^nスケール)で行い、出力の段階で1/700スケールに変換することとしました。

変換の際にかける係数:(1/700)*100 = 0.1428571% 142.85


モデリング
まずはサイズのわかっている機体と翼を仮置きします。




震電の翼は翼端20度取り付け15度になっていましたので、翼をそのように作成。
とはいえ模型として作るぶんには外観が合っていれば取り付け角はどうでもよいため、このあとの作業での微調整では取り付け角はいいかげんに扱っています。

給気口、操縦席、各翼を追加していきます。
操縦席は悩みましたが、1/700スケールの必要ディティールと出力可能精度から、一体の塊としました。

ざっくりと足を追加。



ひととおりパーツが揃ったので、ここで出力できるか検証するため最初の3Dプリントをかけます。

今回、3Dプリント出力に使ったのは以下:
3Dプリンタ:Photon Mono SE
スライサAPP:CHITUBOX(for Linux 1.9.0)
レジン:エキマテ(低アレルゲン水洗いレジン)

スライサAPPで、モデルデータを3Dプリンタの出力データに変換します(スライシング)。

前述のとおり、スケール変更はこのスライシングのタイミングで行います。



スライシング作業で難しいのは、パーツ分割・出力角度の決定・自動ランナーの調整です。

スライシングの際、出力物の角度を調整します。
この角度の決定が難しく、(ここは細かい話をするのが大変なのでざっくり書きますが)
- 層出力中に宙に浮かない角度を見つける
- かつ、積層に対して45度以上の垂直な面をめざし、できるだけ水平に近い面を減らす。
- 自動ランナーが良い位置にランナーを生やしてくれる角度を探す。
などがあります。

3Dプリントでは浮いているものはランナーを生やしてつなげる必要がありますが、パーツ位置によりランナーをつけたくない箇所もあったりします。
浮かない角度をつけることが不可能ならパーツ分割です。
水平の面を減らすことについて、ほとんどの出力物は45度角ほどある部分があるため、あちらを立てればこちらが立たず(物理的に角度が寝る)のを、良いようにとりなす角度をを見つけなければなりません。
スライシングソフトの自動ランナーは不完全なので、手作業で補完しなければなりません。
必要な箇所にランナーがつかなかったり、不要な箇所・切り取りづらい箇所にランナーがついたりします。
モデルのサイズが大きかったり形状が複雑だと、手作業でランナーを調整するのも限界があります。



実作業では、出してみてダメだったらアレコレ調整、を何度か繰り返すことになります。
出力角度の調整も、そのうちのひとつです。

以前、伊507やイリスヨナを作ったときは、ツルツルの断面に自動ランナーが上手くつかないため、ランナー接着用の突起をわざわざモデルの断面部に追加したりしました。
また、パーツ分割でもいろいろ苦労したので、一体型の震電はそこについては楽です。
(大きいものはプリントサイズに納めるために分割が必要。
複雑な形状のものは層で出力しようとすると支えるためのランナーを付けられず空中に浮いてしまうため、やはり分割が必要になってしまう。)
(できれば中空構造にすることでレジンを節約したい、というストレッチングゴールもある。)

ランナー接触面の設定、という悩みどころもあります。
これは小さいほど出力物をランナーから切り離すのが楽なのですが(プチプチと楽しい音で手でちぎれる)、支えが小さいということは印刷中に出力物が木になったりんごのように落ちて失われる可能性が増えます。




初期の出力結果は、プロペラ部分と後足がきちんと出力されませんでした。
どうやら細すぎて印刷中に千切れてしまったようです。
また、プロペラが千切れたことでボディの支えも失われて、機体後部が出力されないことが繰り返されました。

都度プロペラを太く修正しつつ、支えも太くなるよう設定を調整していき、だんだんと出力結果が良くなっていきます。
しかしプロペラ〜機体後部まわりがどうにも安定せず、苦労しました。

最終的に、UV照射時間を1sec->1.5secへ伸ばして硬度を上げることで、出力に成功しました。
(Photon Mono SEは基本的に、1層あたり照射時間1secで出力可能。)
小さいモデルの出力には照射時間を伸ばすのが有効のようです。
なお、出力時間は伸びますが、40min->50min程度でした。印刷中には台座の移動時間などもあるため、単純に1.5倍にはなりません。



続きの記事では切り込みラインによるディティール追加と、量産、ついでに色つけについて書く予定です。

 

 

electron12 でdialogを呼び出す(ContextBridge)

electron12対応へ、前回は

右クリックメニュー(ContextMenu)カスタム処理をmain-processへ移動した(electron 12対応) 

 まで。

 nodeIntegrationはともかくmoduleは将来廃止になるとのこと。

npmパッケージで逃げることもできるが、まとめて移行することに。

つまりいろいろなものをrender-processからmain-processへ移動することになり、ContextBridgeの導入を避けることができない。

 

 # electron11まで使えたdialog呼び出しコード

これまではrender-process側の適当なjsファイル内で完結する下記2行程度の記述で ダイアログを表示することができたのだが、ようはこれが使えなくなる。

 ``` js/mypage.js

const {dialog} = require("electron").remote;

dialog.showMessageBoxSync(null)

```

 

# contextIsolationを有効化

 エラーメッセージによると、ContextBridgeを使うには、contextIsolationを有効化しなければならない

(electron12からデフォルトでtrue)

# ページ上のjsでdialogは呼べない(renderer-process)

ContextBridgeでmain-processへ飛ばしてそこからrequest('electron').dialogを呼ばなければならない。

```

MN@daisy-bell:lina_dicto/$ git diff lina_dicto/js/index.js         }catch(err){
-               message_dialog('error', 'user preference error', "user preference load error:\n" + err.message);
+               window.myApi.message_dialog('error', 'user preference error', "user preference load error:\n" + err.message);
        }
 
 }, false)
```


 

# preload.js内でdialogは呼べない

最初はpreload.js内でdialogを呼ぼうとしたのだが、なぜかrequire('electron')からcontextBridge, ipcRendererのようにdialogを取り出すことができない。

(preload.js内でcontextBridge, ipcRenderer以外が使えないということかもしれない。

後のContextBridgeのサンプルコードなども、見る限りpreload.js自体はrender-process側ということのように見えるし。)

 

# ContextBridgeでdialogを呼び出す

 


 

諸々の非同期を経由で呼び出しているが、 dialog.showMessageBoxSync()はウィンドウを渡せばウィンドウはモーダルに動作する(意図どおりブロックする)ように見える。

(まあとりあえずエラー通知にしか使ってないのでそこはどちらでもよしとする。 )

ページ上のjs -> preload.js上のcontextBridge -> main-processのjs と飛ばす。


 ``` js/index.js (renderer-process)

 window.myApi.message_dialog('error', 'HELLO', 'hello!');

 ```

```preload.js

 const { contextBridge, ipcRenderer, } = require("electron");
contextBridge.exposeInMainWorld(
    "myApi", {

        message_dialog: (strtype, strtitle, strmessage) => {

            ipcRenderer.invoke('tomain-message-dialog', strtype, strtitle, strmessage);

```

``` index.js(main-process)

const { ipcMain } = require('electron');
ipcMain.handle('tomain-message-dialog', async (event, strtype, strtitle, strmessage) => {
    const { dialog } = require('electron');
    dialog.showMessageBoxSync(

            // win, // ここmain-processで生成したwindowを指定できる
            {
                type: strtype,
                buttons: ['OK'],
                title: strtitle,
                message: strmessage,
            });
});
```

 

TODO: 確認ダイアログを出してOK,NGを同期で返す。

(現行の互換動作。あるいはこれは諦めてもいい。今は不要なので)

TODO: ファイル読み出し結果を戻す

 TODO: ところでcontextIsolationが有効な時に nodeIntegration: trueが 無効になってない?

 

 

右クリックメニュー(ContextMenu)カスタム処理をmain-processへ移動した(electron 12対応)

右クリックメニュー(ContextMenu)カスタム処理をmain-processへ移動した。

electron 12へ移行するための対応の一部。

(移行作業としてはelectron11で移行作業をしてから12にアップデートするつもり)。


``` エラーメッセージ

 Uncaught ReferenceError: Menu is not defined
```


 



 

Menuはmein-processでいじるものになっていた模様。

ApplicationMenuカスタム処理をmain-processへ移動した(electron 12対応)

を参照 。

 

main-processのindex.jsの先頭付近に移動した。

```

  7 require(path.join(__dirname, 'main-process/application-menu.js'))¬
  8 require(path.join(__dirname, 'main-process/context-menu.js'))

```

 electron-api-demosでは`  Menu.setApplicationMenu()`はコールバックに仕込んでいたが、コンテキストメニューではしていないので、踏襲してそのまま呼び出しで済ませることにした。

```

 10 const {Menu, MenuItem, app, ipcMain} = require('electron')¬
 11 let menu = new Menu();¬
 12 ¬
 13 menu.append(new MenuItem({¬
 14 >-------label: 'Copy',¬
 15 >-------accelerator: 'CmdOrCtrl+C',¬
 16 >-------role: 'copy'¬
 17 }));¬

 ```

 

またコンテキストメニュー表示のコールバックも、 renderer-processでしていたのをelectron-api-demosの通りにmain-processへ移した。

rendererとmain-processでイベント が違う。

Before:

``` (renderer-process)

 11 >------->-------window.addEventListener('contextmenu', function (e) {¬
 12 >------->------->-------e.preventDefault();¬
 13 >------->------->-------menu.popup(remote.getCurrentWindow());¬
 14 >------->-------}, false);¬

```

After: 'main-process/application-menu.js'(main-process)
 ```

app.on('browser-window-created', (event, win) => {
  win.webContents.on('context-menu', (e, params) => {
    menu.popup(win, params.x, params.y)
  })
})

ipcMain.on('show-context-menu', (event) => {
  const win = BrowserWindow.fromWebContents(event.sender)
  menu.popup(win)
})

```

 

 

 

ApplicationMenuのときと同じく、Rendererに持たせたmoduleを呼び出す機能は動作しない。

 

そちらは後でpreload.js, ipcRendererなどを使う方式へ移行する。

ApplicationMenuカスタム処理をmain-processへ移動した(electron 12対応)

ApplicationMenu(画面上部のメニューバー)カスタム処理をmain-processへ移動した。

electron 12へ移行するための対応の一部。

(移行作業としてはelectron11で移行作業をしてから12にアップデートするつもり)。


``` エラーメッセージ

 Uncaught ReferenceError: require is not defined
    at menu.js:3

```

```menu.js:3

const remote = require('electron').remote;

```

 


 

だが根本的にはMenuはmein-processでいじるものになっていた模様。

electron-api-demos ではそうしている。

```electron-api-demos main.js

function loadDemos () {
  const files = glob.sync(path.join(__dirname, 'main-process/**/*.js'))
  files.forEach((file) => { require(file) })
}

``` 

ただしこの時点でelectron-api-demosはelectron9を使っていた。

(いろいろ言いたいことはあるが略)


Before:

``` index.html

<script type="text/javascript" src="./js/menu.js"></script>

```

After:

```

 require(path.join(__dirname, 'js/menu.js'))

```

これだけでもMenuカスタムが動作するようになってしまう。

ようは`  Menu.setApplicationMenu()`を呼んでしまえばOKのようだが、electron-api-demosではコールバックに仕込むことをオススメしている模様。

```

app.on('ready', () => {
  const menu = Menu.buildFromTemplate(template) // テンプレートを変数に格納
  Menu.setApplicationMenu(menu)
})

```


これをすることで、Menuカスタムは動作するし、Quit(App.quit()呼び出し)などは動作するが、Rendererに持たせたmoduleを呼び出す機能は動作しない。

 

そちらは後でpreload.js, ipcRendererなどを使う方式へ移行するとして、とりあえず次は右クリックのContextMenu。

食洗機の分岐水栓をDIY工事はあきらめてお願いした(結果的によかった)

 食洗機の『プチ食洗(NP-TCR3)』を購入しました。
食洗機にはビルトイン・据え置き水栓・据え置きタンク式、がありますが、購入したのは水栓をつなげる必要がある機種です。
わたしが購入前に参考にしたブログでは『買って取り付ければ終了だよ』で、『分岐水栓を取り付ける必要があるけれど自分でできるし簡単だよ』という感じでした。
おおむねそのとおりではあるものの、わたしの場合はイロイロあって業者さんに頼むことにし、結果的に頼んでよかった、と思ったのでその話を。





ちなみに、のちに出てくる蛇口と分岐水栓は以下。
蛇口 takagi JA200LN-NNDK01
分岐水栓 JH9024



# 設置前の準備
設置場所が必要なのもそうですが、ちょこちょこと以下のような必要なものが出てきます。

「分岐水栓」以外は、近所のスーパーやドラッグストアで当たり前に売っているようなものばかりなので、本体を買ってからつどつど集めるとかでも十分だと思います。
以前、3Dプリンタを買ったときは、必要な周辺小物の多さに驚き苦労しました。
それからすれば本当に少なく、3Dプリンタのように通販でしか手に入らないような専用品もほぼありません。
とはいえあらかじめ買っておいたほうが、設置と動作確認がスムーズです。

必要なもの
- 分岐水栓
- 食洗機専用洗剤

場合によって必要
- 電源延長コード
買った食洗機の電源コードは1mくらいでした。
食洗機の設置場所はおおむね水道の横、炊飯器等の家電から離れているため、我が家の場合は必要でした。

本体を中古で購入する場合、
- 給水ホース
- 排水ホース
がついてくるかどうか確認しておくといいです。
なければ家電量販店で買えるようです。


# なぜ水場工事業者さんに頼まなければならなかったか
『DIYでやってみて、だめだったら業者にお願いしよう』というのもアリだと思います。
(それで水道を壊したりしたら余計に出費がかさむことにはなりますが。)
というか私のばあい、その方針でやってみて、工事をする前に降参した流れになります。

## 1. 分岐水栓のとりつけには専用の工具が必要
購入前に参考にした、同じ蛇口と分岐水栓のブログ記事などでは、言及がなくて驚きました。

分岐水栓の取扱説明書を見ると、分岐水栓のとりつけには『「トルクレンチ」が必要』とあります。
このトルクレンチが厄介で、必要なのは「水道工事用の10Nのトルクレンチ」であるのに対し、市販されているのは車用の「40N以上のトルクレンチ」ばかりです。
水道工事用の10N前後のトルクレンチは、ホームセンタではとりあつかいがありません。
Webで見てみると、どうやら6000円スタートの業務用キットには含まれているようですが、あきらかに業務用で、Web上で軽く調べるだけでは、詳細情報を知ることができません。

どうやら、購入前に参考にしたブログ記事などの方々は適当に締めているようです。
家庭で特殊めな10Nのトルクレンチを持っていたのかもしれませんが。
また後に書く工事の様子を見た限り、それでも多くの場合はうまく行くのかもしれません。
専用工具で適切な強さで締める必要があるナットを、素人の自分がやって、水が飛び散って止まらないなどとなったら目もあてられないので、業者にお願いする判断をしました。

## 2. 蛇口や水道管が悪くなっていた場合に対処できない
分岐水栓を設置する水まわり工事をお願いするにあたって、ネットなどで水道工事は悪い業者に引っかかると見積もり以上のすごい額を請求される、という話をどこかで読んだことがあったので、事前にいろいろ確認しました。
その、電話口での概算見積もりの段階で「見積もりから大きく外れる事情にはどんな場合がありますか」と訊いてみたところ、「水道の蛇口が経年劣化でダメになっていて、蛇口の交換等が必要になってしまう場合があります」との回答をいただきました。

確かにDIYでそうなったら、蛇口の交換になって(まあそれもがんばればDIYできる範囲ではありますが)手に負えないだろうなと思いました。
(がんばれる人もいると思いますが、わたしはやめておきたい)

## 3. 蛇口が固着して素人工事が難しい場合がある(私の場合)
実際に工事をお願いして、作業者の方がとりつけ工事をしているのを間近で見学させてもらいました。

そのときに起こったことなのですが、蛇口の「化粧リング」が固着して外れませんでした。
この化粧リングは、ナットやパッキンのように固く締めて水漏れを防ぐような部品ではなくて、ネジ溝はあるけれど固定用で「かぶせてあるカバー」程度のものです。
しかし(それゆえなのか)、水道のカルキで固まってしまっていました。
わりと強めに蛇口を揺すったりしてみたものの、通常のレンチでは、化粧リングが外れず。
最終的に「蛇口に傷がついてしまいますが良いですか?」という確認のあと、見たことのないゴツめのレンチで無理やりねじ開けてもらいました。
(借家なので退出料に上乗せになるかもしれません。言われないと気づかない程度の跡なので大丈夫だろうだとは思っていますが。)

なお固着していたのは半分内側みたいな位置の部品だったため、日頃の掃除の有無は、固着の発生にあまり関係ないと思います。
住んでいるのは、わたしが入居した時点で築3年程度、住み始めてから2年程度なので、蛇口は設置してから長くて5年くらいのはずでした。


# 工事をお願いする際の注意

- 予備の部品とかを持ってきていないかも
これは、かなり推測混じりですが。
分岐水栓の付属品はあらかじめ確認しておいたほうがよいです。
工事中に『パッキンがないかも』という話が出て、そのときにけっこう真剣に探して、すぐに手持ちがあるような話にはなりませんでした。
こちらは確認したわけでないですし、汎用の水栓などは持ってきているのだと思います。
しかし分岐水栓は種類も多いので、部品の代替えがある期待はしないほうがよいかもです。

- 分岐水栓はあらかじめ買っておいて大丈夫
というか、分岐水栓に種類がたくさんあるのもあって、あらかじめ買っておかないと在庫や手持ちにない場合があるのかもしれません。
私の場合、上記のとおりあらかじめ買った状態で工事のお願いをしたので、そのへん持ち込みしてもらって別途購入できるのか等は、確認していません。

- 分岐水栓の取扱説明書をなくさない(工事経験のない機種かも)
自宅の蛇口はメーカがtakagiだったので、それなりにメジャな蛇口なのではと思っていたのですが、そうでもなかったようです。
作業者の方は、分岐水栓についてきた取扱説明書を見ながら作業、という感じになっていました。
分岐水栓の取扱説明書のほうに蛇口側のことについてはそれなりに書いてあったので蛇口の取扱説明書は不要でした。
(でもあるなら用意しておいたほうが良いと思います。)

ComfyUIでXYZ-PlotするワークフローのサンプルとTips(ComfyUI-XYZ-Stitch)

 ComfyUIでAutomatic1111的なXY-Plotをしたいのだが、ComfyUIデフォルト機能には用意されていない。     カスタムノードが必要となるのだが、Webには古いとか何故か動かないとかなXY-Plotパッケージの使ってみた系記事か、githubに上げられた...