connector への改名

繋いでくるのは「ユーザ」ではない

📅 作成: 2026-08-31 / 更新: 2026-08-31

← README へ戻る

なぜ変えるのか

user_id users user_role という名前を使っているが、ここに来るのは「ユーザ」ではない。繋いできた人か AI である。

名前が実体を言い当てていない

user_role が ai と human の 2 つを持っていること自体が、「user」で括れていない証拠である。人と AI を同じ土俵に載せているのに、名前は片方（人）だけを指している。

いまの名前実際に入るもの
user_idプロジェクトのフォルダ名（ai-chat-lite html2md）、または human
user_roleai か human
users繋いできたものの一覧。人も AI も混ざる

「参加者」という日本語は既に使っている。画面の見出しも「参加者」である。英語の名前だけが user のまま取り残されている。

いま変えるのが安い

これから 2 つの機能が列を足す。

課題足すもの
i260830-09アーカイブ機能。archives テーブルと archived_user_id
i260831-01返信・リアクション・投票。messages に列を足す

あとから変えると、足した分も変えることになる。先に名前を決めてから、これらを作る。

新しい名前

connector にする

このプロジェクトで一度も使っていない語である。置き換えても既存の記述に混ざらない。実測で 0 件だった。

語出現選べるか
client74不可 src/client/ で使用中
node291不可 Node.js の node: と衝突
session4避ける 会話ログの文脈で使用
agent3避ける AI エージェントの意味で使用
connector0これにする

すでにある似た語と、どう区別するか

connector は「繋ぐもの」という意味なので、既にある client connection と紛れる。それぞれが何を指しているかを実測した。

語行いま何を指しているかどうするか
client74 3 つの別物に使っている。下記 意味ごとに分ける
connection68 1 本の接続。active_connection_count は本数 変えない
presence73 在席の状態（online / grace / offline） 変えない
waiter24 long-poll で待っている接続 変えない

client の 3 つの意味

意味場所例どうするか
① CLI そのもの src/client/ 「CLI クライアント」chat.mjs の置き場 変えない。フォルダ名も
② SSE の 1 接続 hub.mjs server.mjs sseClients addSseClient() 変えない。接続を指しており正しい
③ ブラウザの API chat.js clientHeight 変えない。DOM の名前

client はどれも「繋ぐ側の道具・1 本の接続」を指しており、connector（繋いでくる人か AI）とは別のものである。区別はついている。

ただし読み手には紛らわしい。改名したあと、connector と client の違いを設計に 1 行書く。

日本語も似た語が並んでいる

語行指しているものどうするか
参加者125繋いでくる人か AI（= connector）これを正とする
接続1421 本の接続。connection の訳変えない
クライアント44CLI そのもの（= 上記①）変えない
相手57会話の相手。参加者と同じものを指す場面が多い読み直す
セッション60Claude Code のセッション変えない
エージェント30AI エージェント変えない
利用者2読み直す下記
ユーザー / ユーザ212 種類が混ざっている下記
接続者1読み直す

「相手」57 行は放っておくと不統一が残る。「相手が居なくなった」は参加者を指しており、「参加者」と書ける場面がある。ただし「会話の相手」という自然な日本語でもあるので、1 件ずつ読んで判断する。

置き換えの対応

テーブルと列

いまあと場所
usersconnectorsテーブル名
user_idconnector_idconnectors cursors
user_roleconnector_roleconnectors
from_user_idfrom_connector_idmessages
to_user_idto_connector_idmessages

active_connection_count は変えない。接続の本数を数える列で、connector とは別のものである。名前が似ているが指すものが違う。

API のキー

DB の列名と揃える。設計に「JSON のキー名は DB の列名に揃える」と書いてあるので、そのまま従う。

エンドポイント変わるもの
/api/join入力・応答の user_id user_role、応答の users
/api/say入力の from_user_id to_user_id、応答（発言そのもの）
/api/pollクエリの user_id
/api/usersパスも変える（/api/connectors）。応答の users
/api/eventsクエリの user_id、presence イベントの中身
/api/leave入力・応答の user_id

他プロジェクトが chat.mjs 以外から叩いていれば壊れる。API を直接叩く手順は USAGE に書いてあるので、使っているところがあるかを先に確かめる。周知が要る。

コードの中の名前

いまあと
userIdconnectorId
USER_ID（CLI）CONNECTOR_ID
AICHAT_ID変えない（i260831-02 で別途扱う）
joinUser touchUser getUserjoinConnector touchConnector getConnector
userList userCount userIds（画面）connectorList connectorCount connectorIds
#user-list #user-count（HTML の id）#connector-list #connector-count

CLI のコマンドとオプション

いまあと備考
who変えないコマンド名は据え置く。他プロジェクトの手順を二度変えないため（--connector-id の周知を今日すでに 1 回出している）。/api/connectors とは揃わないが、who は「誰が」を尋ねる語として意味が通る
--role ai|human変えないrole に user は入っていない
--to <id>変えない同上
join wait say recent dump leave変えない同上
USER_ID（内部の定数）CONNECTOR_ID

コマンド名は 1 つも変えない。どのコマンドにも user が入っておらず、触る理由がない。

名乗る ID を --connector-id で渡す

AICHAT_ID をやめる。いま名乗る ID は環境変数で渡しており、待受けを張るのに 2 行が要る。しかも 1 行目がシェルごとに違う。

$env:AICHAT_ID = 'ai-chat-lite'
node <ai-chat-lite>/src/client/chat.mjs wait

これを 1 行にする。

node <ai-chat-lite>/src/client/chat.mjs wait --connector-id ai-chat-lite
得られること中身
どのプロジェクトの待受けか分かる コマンドラインに ID が出る。環境変数はプロセス一覧に出ないため、いまは node ...\chat.mjs wait しか見えず、複数が待受けを張っていると見分けられない
シェルを問わない bash でも PowerShell でも同じ 1 行で起動できる。環境変数は PowerShell が $env:、bash が export、cmd が set と書き方が分かれる
取り違えが減る 環境変数は同じシェルに前の値が残る。引数なら毎回明示される

これは実験で実際に困った点である。待受けを 4 通りで起こしたとき、Win32_Process の CommandLine に ID が出ず、どの PID がどれなのか起動時刻から推測するしかなかった。

AICHAT_ID は残さず廃止する。両対応にすると、引数と環境変数のどちらが勝つかという規則が増え、取り違えの余地が残る。

まだ決めていない

論点選べる形
省略できるか 設計では「無ければ path.basename(process.cwd())」としていたが、実装は必須にしている。省略を許すと、違う場所から叩いたとき別の名前で参加する。明示させる方が安全か、省略できる方が楽か
会話ログに残る量 コマンドラインに ID が出る＝呼び出しのたびに記録される。ID はプロジェクトのフォルダ名なので秘匿の対象ではないが、増えることは事実である

ファイル名

プロジェクト内に user を含むファイル名は無い。実測で 0 件だった。

PlayWright 側に chat-users.png がある。これはテストが撮るスクリーンショットで、出力なので Git 管理外である。撮る側（chat-ui.spec.ts）の名前を chat-connectors.png に変える。

日本語の記述

語出現どうするか
参加者125そのまま。日本語としてこれが自然で、画面の見出しでもある
ユーザー / ユーザ21読み直して個別に判断する（下記）
接続者1読み直す

「ユーザ」の 21 行は 2 種類が混ざっている。一括では置き換えられない。

意味例どうするか
繋いでくるもの「ユーザが参加すると…」「参加者」に直す
この道具を使う人「ユーザが指示するまで実行しない」そのまま（意味が違う）

「コネクタ」というカタカナは使わない。読み手にとって分かりにくくなるだけで、得るものがない。英語の識別子は connector、日本語は「参加者」で通す。

データをどうするか

いま入っているもの

テーブル件数中身
messages48他プロジェクトとのやり取り
users7各プロジェクトと human
cursors7どこまで読んだか

3 つのやり方

案やり方難点
A 捨てて作り直す。3 ファイルを消して新しいスキーマで作る やり取りが消える。いちばん単純で確実
B 移す。新しい名前のテーブルを作り、INSERT … SELECT で写す 手数が増える。途中で止まると中途半端な形が残る
C 改名で済ませる。ALTER TABLE … RENAME COLUMN を並べる 索引も張り直す。順序を 1 つ間違えると分からなくなる

捨てるなら、その前に控えを取る。バックアップは自動で動いているので直近のものがあるが、改名の直前に手で 1 つ取るほうが確実である。読み返したくなったら、その zip を開けばよい。

捨てるとき何が消えるか

他プロジェクトとのやり取り 48 件。md-skip や callout の分類について交わした議論が入っている。資料には反映済みだが、経緯そのものは消える。

各プロジェクトの読み位置（cursors）も消える。次に待受けを張ると、そこから読み始める。取りこぼしにはならないが、過去の分は流れない。

段取り

順序

#やることなぜこの順か
1控えを手で 1 つ取る戻せる状態にしてから始める
2他プロジェクトへ周知するAPI のキーが変わる。直接叩いているところがあれば先に知る
3store.mjs のスキーマと関数ここが源。他はこれに合わせる
4単体テストを通す3 の直後に通す。ここで止めれば影響が閉じている
5presence.mjs server.mjsAPI のキーとパス
6画面（chat.js index.html chat.css）id とクラス名
7CLI（chat.mjs）who → connectors、USER_ID → CONNECTOR_ID
8道具（purge-test-data.mjs）列名で絞っている
9画面テスト（PlayWright の spec）別リポジトリ。スクショの名前も
10日本語の「ユーザ」21 行を読み直す意味が 2 種類ある。一括では置き換えられない
11設計・USAGE・手引き・課題すべて決まってから

触るファイル

user を含む 78 ファイル中 15 件以上。多い順に並べる。

ファイル行中身
tests/server.test.mjs59API のキー
src/server/store.mjs58スキーマと関数。ここが源
src/server/server.mjs50API のキーとパス
notes/10_plan/p260829-01-設計.html47スキーマの説明・API 一覧
src/web/js/chat.js38変数名・DOM の id
tests/store.test.mjs32
src/client/chat.mjs24who と USER_ID
tests/presence.test.mjs20
src/server/presence.mjs19
tools/40_test/purge-test-data.mjs14列名で絞っている
notes/10_plan/p260830-02-アーカイブ機能.html12archived_user_id
src/web/css/chat.css9クラス名
USAGE-FOR-PROJECTS.html9API とコマンドの説明
PlayWright の spec 4 本—別リポジトリ
生成された .md—直さない。HTML から作り直す

3 を入れた時点で全部落ちる。テストも画面も CLI も古い名前を使っている。4 で単体テストを通してから 5 へ進む。一度に全部直すと、どこで壊れたか分からなくなる。

置き換えは機械的にできない

user を connector に一括置換してはいけない。次のものが巻き込まれる。

巻き込まれるもの理由
USAGE-FOR-PROJECTSファイル名に USAGE が入っている
$env:USERPROFILE環境変数
日本語の「ユーザー」変えない方針
test-project 等のテスト用 ID値であって名前ではない

語ごとに指定して置き換える。user_id → connector_id、users → connectors のように、長いものから順に当てる（from_user_id を user_id より先に処理する）。

確かめること

数えて確かめる。「たぶん置き換えた」で済ませない。user の残数を実際に数え、残っているものが日本語・USAGE・環境変数のいずれかであることを 1 件ずつ見る。

残ってよいもの

もの理由
USAGE-FOR-PROJECTSファイル名。USAGE は「使い方」の意味
$env:USERPROFILE $env:USERNAMEWindows の環境変数
active_connection_count接続の本数。connector とは別のもの
「ユーザが指示するまで」等この道具を使う人を指す。意味が違う
参加者（125 行）日本語としてこれが自然

決めたこと

#論点決めたこと
1順序 改名 → アーカイブ。アーカイブを先にすると、作った直後に列名を変えることになる。テーブルの作り直しを 1 回で済ませる
2既にあるデータ 移す。INSERT INTO … SELECT で写す。捨てる案を書いていたが、読み返せなくなるのを避ける
3API のキー 揃える。user_id → connector_id。両方受ける形にすると名前が 2 つ残り、改名の目的に反する
4/api/users のパス /api/connectors に変える。キーを変えるならパスも揃える
5who コマンド 変えない。他プロジェクトの手順を二度変えないため（--connector-id の周知を今日すでに 1 回出している）
6notice いま足す。作り直す機会が今回なので、msg_kind の CHECK を say / join / leave / archive / notice の 5 つにする（i260901-03）
7アーカイブの単位 ルームと参加者の両方
8作り直しの手順 専用のスクリプトを作る。手作業だと再現できない。印を置く・止める・移す・印を消すまでを 1 本にする

作り直しの前に控えを取る。途中で書き込まれると整合が崩れるため、メンテナンスの印を置いてから行う。-wal と -shm も 3 つ一組で退避する（本体の大きさから中身の量は判断できない）。

残っていること

データを捨てるか移すか

案 A（捨てる）を勧める。移す手数に見合うものが 48 件のやり取りの中に無い。資料には反映済みである。

ただしこれは判断を要する。捨てると読み返せない。

API のキーを変えるか

設計は「JSON のキー名は DB の列名に揃える」としている。揃えると他プロジェクトが壊れる可能性がある。

案内容難点
揃える列名と同じ connector_id にする他プロジェクトが直接叩いていれば壊れる
両方受ける入力は user_id も connector_id も受ける名前が 2 つある状態が残る。改名の目的に反する
揃えないAPI は user_id のまま設計の方針に反する。いちばん分かりにくい

揃えるのが筋だが、まず他プロジェクトが API を直接叩いているかを確かめる。叩いていなければ迷う必要がない。

/api/users のパス

/api/connectors に変えるかどうか。キーを変えるならパスも変えるのが自然だが、パスは URL として外に出るので影響が読みにくい。

--connector-id を省略できるか

省略を許すと、違う場所から叩いたとき別の名前で参加する。明示させる方が安全か、省略できる方が楽か。詳細は「CLI のコマンドとオプション」に書いた。

他の課題との順序

アーカイブ機能と返信・リアクションは、この改名より後にする。先に作ると、足した列も変えることになる。

ただしアーカイブ機能は着手中である。止めてこちらを先にするか、アーカイブを終わらせてから改名するかを決める。

待受けの時間指定もCLI のオプションを触る。--retry-count を廃止して --wait-min / --wait-hour を足す課題なので、--connector-id と同じ行を書き換えることになる。どちらを先にするかを決めてから始める。