過去のリボ払いとか、その他の返済とかを振り返る

世の中ではリボ払いはとかく悪者として扱われがちだが、個人的には便利な仕組みだと思っているので、振り返りがてら個人的な過去の事例を書いてゆく。リボ以外のことはあとがきにちょろっと書いている。

なお、この記事はリボ払いを推奨するものではない。リボの返済は面倒なので使わなくて済むなら使わないに越したことはないが、いざというときには頼りになる諸刃の剣といった感じの代物である。

過去のリボ利用

利用の順序的には2→1→3→4。

1. 収入が不安定な時に輝いたとき

月によって5万円だったり、20万円だったり、収入が変動する場合にリボは便利だ。

例えば翌月の収入が大幅に減ることが分かっていれば、リボの支払額を5000円など、最低支払額に設定することで、その月の不払いを逃れることができる。

その分当月分の請求が膨れ上がるが、それは翌月以降に返していけばいい。但しこれが使えるのは一瞬収入が落ちる瞬間だけで、継続的に落ちる場合は厳しい。

これは過去にSES会社で現場を切られて、なんかキレた社長から懲戒処分を受けて減給というアクシデントが起きたときの調整で使った。

2. 現金が底をつき、クレジットカードも枠上限まで使い切ったとき

気の迷いによりクレジットカードの利用枠を上限まで使い切り、現金さえも溶かしてしまったとき、こういうときにもリボは使えた。

私の利用している三井住友カードには「あとからリボ」というシステムがあり、現在までの利用分を全てリボ払いへ変更できる。これを使うことで、いきなり利用した全額が請求されることを回避できる。

この仕組みを利用することで一旦支払いについては何とかなった。しかしこの状態では、当月の生活費の捻出ができない。そこでどうするかだが、私は経験上キャリア決済が二ヶ月後に請求されることを知っていたため、これを使うことにした。キャリア決済の請求はクレジットカードに出来るため、現金がない状況でも誤魔化せたのである。

つまりクレカ利用不能+現金なしをキャリア決済を使うことで回避したという寸法だ。給与の振込日は25日、クレジットカードの引き落とし日は26日だったため、給与の入金直後にクレカの利用枠が空く。その枠で、翌月に請求されるキャリア決済分を支払うという戦略だ。

これは上手く回り、しばらくするとキャリア決済しなくてもいいだけの空きが出てきたので、そこからは普通に返済するだけでよくなった。

3. 手持ち金がないが大きな出費が複数発生したとき

ある転職で東京に引っ越す必要が出たが手持ち金がない問題が発生した。

引っ越すためには不動産屋の仲介手数料に、賃貸会社への前金、初回賃料、引っ越し業者への支払いなど様々なものが必要だったが、これらを分割で払うと具合が悪い問題があった。

そこでリボにまとめることにした。分割払いだと複数の異なる支払いを丸められず、出費の管理がしんどいが、リボにすれば毎月一定額で返せばよいので考えることが減る。

更に入社後三ヶ月で祝い金が出ることが分かっており、この祝い金を受け取り、リボの返済額を満額にすることで容易に返せたため、リボとの相性がとてもよかった。

4. 予期せぬ出張が大量発生したとき

転職活動で有休を使い切り、転職間際で仕事がなく、どうせなら自由にやっていこうと欠勤をしていたら、転職後にお金が無くなったケース。

欠勤による減給により手持ち金が減るのは想定内だったし、貯蓄もあったし、それ自体は特に問題はなかった。

問題は転職後の話だ。転職した会社には入社日の出張に、首都圏への一週間の出張研修があり、4月入社というのもあって首都圏の交通宿泊費が高騰していた。

私のお財布は去年資金難になることを承知で行った佐賀旅行と、年始に壊れたモニタの購入で割とカツカツだった。こんな時にもリボは活きる。そう、リボならすべて後に回せるのである。

但しこの時は計算を誤っており、二月末にリボに設定したものを、三月末に「たぶん行けるやろ」と解除したせいで資金ショートを起こす痛い目を見た。しかし、クレカの支払いが滞ったので時系列を書き出すにも書いたとおり、資金ショートが発覚した段階で迂回策を取り、何とか途中でリボに切り替えることに成功したため、延滞こそあったものの債務不履行という致命傷は逃れられた。

今までのリボ活用経験から、ショートした翌月に請求金額を満額支払い、手持ち現金をほぼ償却、その翌月はリボ設定となった残債を少額返し、更にその翌月は現金が復帰したため通常の支払いに戻すというフローが使えた。

こちらは本記事執筆時点でまだ完済していないが、支払いが滞ったにも関わらずXperia 1 VIIIの与信は通って買えた。

リボ返済表

一回目のリボ

一回目のリボは返済表が残っていなかったが、記憶が確かなら毎月の遅刻と残業を記録することで当月の総支給と税金を計算し、手取りを弾き出すことで翌月支給される給与のうちどの程度を返済に充てられるか計算する機能があったと思う。

この時が人生で初めて自分の給与計算をした時だったと記憶している。確か予実計算には数円の誤差しかなった気がするが、よく覚えていない。

二回目のリボ

この表は一回目のリボ返済に使った表を転用した上で一部簡略化したり、形式を変えたりしているが、一回目の表が残っていないため比較できないのが残念だ。

この当時は支給される給与から手取りを計算したり、固定費をはじき出して目測を立てる方向で返済計画を立てていた。

この表は実際の予実表だが、途中で方式を変更しているようで、一枚目の表は2020年9月から始まり、2021年6月で切れているが、二枚目の表がそのあとに続いているのを見た感じ2021年の11月に完済したものとみられる。

見ていると2020年10月は減っているのに、そこから2021年4月までは残債が増えているのである。確かこの時、家の鍵が壊れたり、事故にあったりで謎の出費が多かった気がする。

恐らく全期間での推移をグラフにするとこんな感じだろう。リボは良くも悪くも増えるので、気を抜いているとモリモリ増えてしまう。

三回目のリボ

一回目の表を転用し計画を立てていたようだが記入の痕跡がほとんど残っていない。9月に入社祝い金が出てチャラに出来たはずなので恐らく表を作るだけ作って管理していない手抜きである。

四回目のリボ

現状の目測では悲観的に見ても今年中には返済できる予定だ。楽観だと二ヶ月後だが、何故か旅行に行くことにしたのでこれは無理だろう。

リボ払いの何が問題か?

まずここで言うリボ払いとは、残高スライド式リボルビング方式と呼ばれるものだ。

さて世の中では邪険にされているリボ払いだが、何が問題なのだろうか?

端的に言うとリボ払いは残債が見えづらい上に、使い方次第で増えてしまうのだ。これは見方を変えれば利点だが、多くの人には恐らく欠点だろう。

そしてリボ払いというのはだるま落としに似ている。

例えばリボ払いの初期残債が50万円で、月の生活費が10万円あり、毎月11万円返済するとする。すると11万円返しているので11万円減るはずである。

しかしこの場合、減るのは1万円である。理由は単純で10万円増えて11万払っているから差額の1万円しか減らないという訳だ。

これが残高がスライドするという話である。1万円のブロックが10個増えて、11個落とすから、いつの日かはだるまが落としきれる。単純計算だと50ヶ月後くらい。

グラフにするとこんな感じ。現実には手数料が入るためもっと減らない。つまり50ヶ月では済まない。恐らく52ヶ月程度かかるのではなかろうか?単純計算で完済に4年掛かる。

更にもし月10万円しか使わないはずが15万円使ったらどうなるだろうか?15 - 11 = 4で4万円増えるので、逆に借金が増えるのである。ブロックが14個増えて、11個落とすのでは減ることがない。前に書いたグラフでもなんか増えてるやつがあるが、まさにそれである。

分割払いの場合は毎月固定額が落ちていくのでいつかは消えるが、リボ払いはそうはならない。逆に増やすことができるので支出が苦しい時は増やして回避することができるのがリボの長所でもある。分割払いはこの月だけ支払額を減らすというのは普通出来ない。

そしてこの仕組みこそがリボが無限借金地獄のように扱われる元凶でもある。

また、リボと分割を併用している場合、分割分はリボに乗ってこないためリボ払いの返済額+分割払いの月次返済で二重苦になる。やるならどちらかに寄せておくのが良いが、分割払い中にリボを使う羽目になった場合、もうそこは覚悟を決めるしかない。なお先に掲載した表には「クレ分割」という列があるが、これは分割払いが固定で入ってくるので、それを勘案したものである。

要するに私は当時分割払いの固定請求とリボの返済を両輪で捌いていた訳だ。

逆にリボ払いが有用に働くケースは何か?

基本的には諸事情あって請求が膨れ上がったときにでも不払いになるような詰みを回避できるところだとは思う。

特に収入が不安定な時でも支払額を調整できるため収入に波がある場合でも少ない月は減らし、多い月は増やすという制御ができるため、そういったリスクを回避しやすい。

手数料だの年利だのはどうしてもついてくるがクレヒスに傷を入れたり破産するよりはマシだろう。

あとがき

自慢ではないが私は過去に住民税を一年三ヶ月くらい滞納して財産の差し押さえ予告が送られてきたことがあるが、これも完納したことがある。これは役所の税務課へ出向き計画を示せば対応してくれる。

但し当年の納税分と過去の滞納分を同時に払うことになるため、中々苦しい。記憶が確かなら24回払いで完納した記憶がある。

この期間は国保にも入らずいたりして、中々壮絶な暮らしをしていたが、電気ガス水道通信費やクレカの支払いはちゃんとしていた。

国保未加入状態から国保に入ると確か未払い金の請求が来るのだが、社保に入って五年経つと時効で消滅するという事情があるため、未払い請求を回避する技もあったりする。とはいえ、全国民の保険金の原資であることから、とても勧められる行為ではない。他にも国保は自治体が管理しているので引っ越すと未払いだった過去が消えるとかいろいろある。実際に五年経過後に国保に入ったことがあるが、特に何も起きなかった。

まぁという訳で、自分は割合借金とかその手のものを返してきたなぁというのもあって書いてみた。と言うかこのネタは書こう書こうと思い二年くらいが経過したので、いい加減書こうという気持ちになったというのもある。ある意味、前日の資金ショート事件辺りはこの記事を書く良い刺激になった気もしている。

あとがき2 2026-08-13追記

リボを始めとする借金は金がないからするものであり、「手数料がかかるからもったいない、そんなことは無駄だ」というのは余裕があるからこそ言えることだと思う。誰しもやりたくてやっているわけではなく、必要に駆られてやらざるを得ないのだ。

住宅ローンを組む人に対して「手数料勿体ないよ?30年貯金して現金一括で買おうよ」とか「私ならここに6000万円があります。勿体なくてできません」とか、そんなことを言っても響きはしないのだ。

株式会社だって株主の投資を基に何かをして、配当を出したりしているわけで、借金というのは将来の時間を買う投資だと考えれば解り易いだろう。人生は有限で、今そこに必要な金がないのであれば、それは借りるしかないのである。

無尽という文化を発見した

「無尽」という言葉を聞くと何となく「無尽蔵」と繋げたくなるが、世の中には「無尽」という行為があるというのを知ったので備忘録として書いておく。

無尽というのは相互扶助の一形態で、ある物が欲しい人を集め、定期的に一定額を徴収することで、「ある物」を給付する仕組みらしい。

簡単に言うと10万円の背広を欲しい人を10人集め、各々から毎月1万円徴収すると、毎月1名に背広を給付することができる。

仕組み上、一番最初に背広をもらった人が有利になり、一番最後に背広を貰った人には何の利益もないことから、誰かが裏切ると即時破綻する極めて脆弱な制度であるが、原理上全員が約束を守る限り利子が発生しえないため、戦後などお金がない時は重宝したらしい。

あたかも貰える人が回転しているように見えるからか、英語ではRotating Savings and Credit Association(回転型貯蓄信用講)と呼ばれているらしい。

Wikipediaの無尽の記事によると、今日においては互助会費のようなものも無尽の一種として扱われているようだ。恐らく複数人で何かしらの目的のために金銭を積み立て、最終的に分配する形態を無尽と呼んでいるのかもしれない。Wikipediaによるとこの手のものは山梨に多いらしい。

そう考えると無尽は世の中に結構あるのかもしれない。例えば誰かが冠婚葬祭するたびに祝儀や香典を渡すのも貰う人が回転しているという意味では無尽と呼べるのかもしれないし、町内会費を集めて何かしたりだとか、日直の当番も輪番制なので金銭や物品を伴わない、無形の無尽と解釈できそうだ。

また無尽は業にすることが可能で、無尽業法という法律があり、かつては多くの金融機関が無尽を行っていたそうだ。しかし金銭無尽が禁じられた結果、その多くは相互銀行へと姿を変え、現在は日本住宅無尽株式会社が唯一の例となっているようだ。

日本住宅無尽株式会社のトップにも「ONLY ONE MUJIN」「弊社は100年以上の歴史を持つ日本唯一の無尽会社です。」とある。無尽会社は社名に「無尽」を付与する必要があるらしいので社名に無尽とついているようだ。

椅子の蒸れを解消するのにござを買った

前にデスクチェア探しの終わりで椅子を買い替えたわけだが、以前使っていたNシールドカルカと比べると蒸れやすい問題があり、夏になりちょっと耐えられないレベルになってきたのでござを買って対処することにした。

買って気に入ったもの

ニトリの竹マット(ブルー 45X65 SQ07)を買った。椅子全体を覆うサイズ感があり、胡坐をかいたり、片足を下ろしてもカバーしてくれるので丁度いい。

クッション性もほとんどなく、裏地に薄い布地がある他は、ほぼ竹なため、通気性がいいのが特徴だ。裏に滑り止めがついているため上で動いても滑らないのもいい。

買ったけどイマイチだったもの

竹シートクッション(SQ09)はクッション性があったのと、中綿が少し蒸れてちょっとこれはないなと思った。

チェアシート(Nクール極冷26 ネイビー)は触り心地は悪くないのだが、ちょっと小さすぎるのが残念だった。

2026-09-01追記

この夏使い続けてみて、全く蒸れなかったので良い買い物だった。

R86S U1のNICを交換した

R86S U1のNICについているSFP+ポートの片方が不安定という問題があり、これがずっと悩みの種だった。

しかしR86S U1のNICはOCP2.0のメザニンカードという特殊な規格であり、入手が難しかった。あと最近なんでも高いことや、ここ一年近く財政が悪く資金がショートしていたこともあり、中々購入のタイミングがなかったが、偶然安いのを見つけたので交換を決意した。

購入したもの

ほぼ新品 Mellanox ConnectX-4 CX4421A MCX4421A-ACQN ネットワーク インターフェイス PCIe カード (OCP2.0 用)

ほぼ新品とあるが中古なのは間違いない。

写真を見る限り左右でコネクタが異なるといったこともなく、3,745円でConnectX-3からConnectX-4に上げられて不調もなくなるならアリではないか?と思い、購入することにした。

配送

荷物はいつも通りCainiaoから発送され、国内ではエスポ便という聞いたこともない業者に引き渡された。軽く調べたところ株式会社エスポリアという越境ECのサービス会社がやっているようで、ここ最近のアリエクに増えているらしい。ここ自体は仲介業者で配送はしてないらしい。

そういえば最近中華特有のテカテカしたプチプチ袋減った気がする。

実際の配送はかつてAmazon便で悪名を馳せたTMG、椿本グループだった。久々に見たので、一般消費者向け宅配便事業で生きてたのかお前…となった。

開封の儀

結構ちゃんとした箱に入っていた。

中身。緩衝材が底にあり、本体も一応元袋らしきものに入っていた。いい感じのヒートシンクがついているのが素晴らしい。

賞味期限ラベルみたいなものが貼ってあったが非常に強力なシールで、爪でカリカリすると爪が削れるレベルで剥がせなかったため剥がすのを諦めた。

新旧比較をすると上が今まで使っていたやつで、下が今回新たに買ったやつだ。

裏返したところ。裏面には薄いアクリルフィルムが基板を保護するように付いていた。短絡防止用だろうか?ヒートシンクを支えるプッシュピンも見えた。

ラベルを見る限り2019年6月製とみられ、比較的新しい製品なのも嬉しい。以前使っていたConnectX-3は製造時期不明だがCX342Aは2015年のモデルらしいので、だいぶ古い。

どこで見たか記憶にないがConnectX-3はサポート切れが近いか、切れていることもあるという話も見た気がするのでConnectX-4を入手できたのはよかった。メイン機もサーバー機もNICはConnectX-4なのでお揃いになった。

装着は既存のConnetX-3を外し、カードを刺す場所に元々ついてたチップクーラーを除去して取り付けたら、そのまま何事もなく普通に装着できた。

このクーラーがあるとヒートシンクに干渉するので、外す必要があった。

OpenWrt上でのセットアップ

OpenWrt 24.10.0にはドライバがなかったのでドライバを入れるのをやっていく。

SFP+以外に接続手段のない私の環境ではルーターのSSHに繋ぐ術がなかったので、R86S U1本体にキーボードとモニタを接続して作業した。

# まずはNIC周りの調査ツールを入れる
opkg update
opkg install pciutils ethtool

# ドライバの状態とかが見れる
# Kernel driver in use: igcならドライバがない
lspci -nnk

# ドライバを入れる。kmod-mlx4-coreは後で消した
opkg install kmod-mlx5-core
# JISキーボードだとアンスコが出せないので頑張って探して打った
modprobe mlx5_core

あとはこのまま再起動したら普通に繋がった。

そのまま使うと温度が上がりすぎた

現状片側のSFP+しか使っていないうえ、それも初日なので不具合は何もない。以前使っていたのも最低でも一週間は使ってないと不安定化しなかったので、まだ安定性は不明だ。

ただソケットが両方とも同じ形に見えるので、以前使っていたものよりは安定するのではないかと考えている。

温度については高くなりがちなようで、R86S U1本体のCPU温度が51度に達することもあった。

以前のNICの温度はデータがなく比較できないのだが、ここまで上がっていることはなかった気がしている。

NIC本体の温度は取得する方法が今のところ分かっていない。mstflintでmstflint -d xxxx -reg_name MTMPとかしたら、提供されていないとか出た気がするがログは取っていない。

参考までに以下の手順でレジスタの値が取れるっぽい。参考:man/mstreg

# 必要なツールのインストール
opkg install lspci mstflint
# MellanoxのデバイスIDの取得
lspci | grep Mellanox | awk '{print $1}'
# レジスタ名一覧
mstflint -d <デバイスID> -show_regs
# レジスタ値の取得
mstflint -d <デバイスID> -reg_name <レジスタ名> -g

関係ないがデータがないのはGrafanaに出しているデータを永続化していないため、tmpが吹き飛ぶと消える状態なので、ここはそのうち何とかしないといけない。

冷却対策

端的に言うとヒートシンクを剥がし、R86S U1に元からついてるクーラーを装着した。

まずはConnectX-4を取り出し、ヒートシンクを外し、グリスを塗りなおす。この時ついでに裏のフィルムも剥がし、熱が溜まらないようにした。

R86S U1に元々ついてたチップクーラー(前述の奴)を持ってきて、付け直した。

ファンレス冷却(ヒートシンク)とファン冷却(クーラー)で同時刻に温度を比べたところ、5度ほど下がるという結果が出たので、かなり効果があった。

新しい奴のヒートシンクの方が目が細かく作りもしっかりしているように見えるが、風のあるなしがそれほどまでに大きいということだろう。

しょぼいヒートシンクと小さいファンの組み合わせなのであまり意味がないだろうと侮っていたが、結果は歴然だった。恐らくこれはケースが小さく通気の余地が少ないこともあり、自然対流には期待できないということの表れなのだろう。

ベンチマーク

以下の構成で速度を計測した結果。そもそもLAN内でパケットがルーターの中を通っているかが謎なのでルーターNIC交換の影響があるかどうかは不明である。

Windows - R86S U1 - MikroTik CRS305-1G-4S+IN - Ubuntu

以前の計測結果はこっち。

Windows → Ubuntu

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec  1.07 GBytes  9.13 Gbits/sec
[  5]   1.01-2.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   2.01-3.00   sec  1.08 GBytes  9.36 Gbits/sec
[  5]   3.00-4.00   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   4.00-5.01   sec  1.10 GBytes  9.36 Gbits/sec
[  5]   5.01-6.00   sec  1.08 GBytes  9.36 Gbits/sec
[  5]   6.00-7.01   sec  1.10 GBytes  9.36 Gbits/sec
[  5]   7.01-8.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   8.01-9.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   9.01-10.00  sec  1.08 GBytes  9.36 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  10.9 GBytes  9.34 Gbits/sec                  sender
[  5]   0.00-10.00  sec  10.9 GBytes  9.33 Gbits/sec                  receiver

Ubuntu→Windows

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.08 GBytes  9.30 Gbits/sec    0   1.54 MBytes       
[  5]   1.00-2.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.62 MBytes       
[  5]   2.00-3.00   sec  1.08 GBytes  9.27 Gbits/sec    0   1.70 MBytes       
[  5]   3.00-4.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   4.00-5.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   5.00-6.00   sec  1.08 GBytes  9.29 Gbits/sec    0   1.78 MBytes       
[  5]   6.00-7.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   7.00-8.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
[  5]   8.00-9.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
[  5]   9.00-10.00  sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  10.8 GBytes  9.28 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  10.8 GBytes  9.28 Gbits/sec                  receiver

まとめ

前回と比較すると若干速度が落ちているが、サーバーとして動かしてて帯域を食っている分減っているのかもしれない。

Windows→Ubuntu(上り) Windows→Ubuntu(下り) Ubuntu→Windows(上り) Ubuntu→Windows(下り)
9.34 Gbps 9.33 Gbps 9.28 Gbps 9.28 Gbps

交換前のConnectX-3が改造品だった話

以前使っていたPCB000620は元々SFP+片ポートモデルで、どうやらR86S U1では2ポートに改造していたようだ。

その影響なのか明らかに片方だけソケットの形が異なる。上側のほうが綺麗で、下側は使いこまれているのか、ややぼろ目に見える。

裏面を見ると片方ははんだ付けされているが、片方は差し込んであるだけ。シールも一度剥がしたものを貼り付けているのか、ペラペラしていてすぐに剥がせた。

おそらく上側(PORT 0)のはんだ付けされていた方が本来のソケットで、後から付けたやつ、つまり下側(PORT 1)が差し込んだだけの奴と思われる。

本来のソケットがぼろい方、後付けのが綺麗な方である。

奥の方の作りも異なる。左がPORT 0、右がPORT 1。

R86S U1のNICについているSFP+ポートの片方が不安定だった話で不安定だったのはPORT 1の方なので、改造して無理に取り付けていた方が不具合を発していたのだろう。本来できないことをしているので無理もない。

裏面の形も異なる。

恐らくよくある片ポートの奴にソケットを増設したのだと思う。

ソケットが片ポートしかなくても回路が実装されていることはよくあるので、この回路を流用しているのだと思う。回路もあるし、チップも恐らく同じなので原理的には問題なく動きそうに思える。

R86S U1のSFP+を使い始めたのは2025年の9月17日からだった[1]が、同年12月13日にはリンクアップとリンクダウンが繰り返される事象を確認していて、同年12月25日にSFP+差し込みポートの変更を行ってからは一度も起きていない。

この時の気温が落ちたので金属製のSFP+ソケットの接触不良になったのではないか?と考えていたが、恐らくソケットではなく、基板本体との接触が寒暖差でダメになったのかもしれない。実際、先ほどの写真を見ても基板の穴からピンが出たり出ていなかったりするので、寒暖差でここが僅かに狂った結果、基板と接触不良になり、回路がチャタリングした結果、リンクアップとリンクダウンをミリ秒単位で繰り返す状態が起きていたのかもしれない。

もし、この理屈が正しければ強く押し込んではんだ付けすれば改善しそうではある。

あとがき

NIC交換の時に取り出した時、酷い埃まみれになっていたのでいい加減、冷却面をどうにかしたい気がしている。

普段は上に80mm角ファンを載せて運用しているため、埃の元凶はこれである。一旦はファンフィルターを買ってその場を凌ぎたいところだが、本質的にはちゃんとしたケースに収めてちゃんとしたクーラーをつけるのが最良だと思っている。

R86S U1を冷やそうとした作業の残渣にも書いているが、R86S U1の冷却機構は耐久性があるように見えず、また大して冷やしてもくれない。上にファンを載せて風を入れていると、いつの日か中が埃まみれになってしまうし、このケースはメンテナンス性が良くないので清掃も面倒だ。

理想論としてはこんな感じのケースに組み込めればよいだろう。これならメンテナンスがしやすいし、NICのヒートシンクも元の奴が生かせそうだ。ファンも40mm角ファンだろうから壊れても交換が容易である。

まぁこれは行き過ぎとしても、ラズパイのタワークーラーを載せるとか、そういうのができるとよいなとは思っている。基板むき出しは埃が溜まってショートしそうなので、ケースもあった方がいいだろう。

ただそれをどう実現するかが難しいところで、まず本来的には3D CADでケースやCPUクーラーをモデリングし、CNCで金属を削るという工程が必要だろうが、そんなものはないし、仮に3Dプリンタである程度何とかするにしても、3D CADの使い方を学ぶところからだと気が遠くなる話で、なかなか難しい…。

そもそもノギスで測っても測るたびに数ミリ単位の誤差が出るので、アナログな図面を書くことすら困難だ(多分ノギスの角度が微妙に毎回ズレてる)

こんなことであれば去年アリエクのセールでファンレスのR86SであるR86S-FLN100を買っておけばよかった。今は22.7万もするが、去年は11万くらいで、セールでは9万にまで落ちていて、買いだった。まぁあとからは何とでも言えるし、そもそも9万でも安くないわけで、言ったところで仕方がない。

現実案としては厚紙にボードを固定して外枠をペンで引き、ネジ穴については基板のネジ穴スレスレの何かを差し込んでマーキングすればそれなりに正確なものが取れるだろうから、一度手書きで図面を書き、それを基にアクリル板を加工し、簡単なケースを作るのが一段階目としてはよさそうな気がする。

ただCPUクーラーをどうするかという問題が根深く、ここが難点になると思う…。これはCPUクーラーを作るにはCPUのヒートスプレッダに乗ってくれるヒートシンクを持ったファンと、そのファンと基板のネジ穴を繋ぐ足が必要になるからだ。ヒートシンクと基板のネジ穴がマッチしないとならないので、恐らくこれが一番の難関だろう…。

たぶん厚紙→アクリル板がいければ図面を起こせるので、カスタムアルミケース業者に発注すれば、きちんとしたものも作れると思う。そこまでやるかどうかは未定だが…w


  1. 宅内に10GbE環境を導入してみたの写真のタイムスタンプから推定。 ↩

日本語に由来するプロダクト名や製品名、企業名の一覧

最近日本語に由来しているプロダクト名や製品名、企業名を見かける頻度が増えたのでまとめてみた。クールジャパンの影響か何かは不明だが、意外と日本語由来の名称は多い。

探しても意外と見つからないので、日々の生活の中で見つける中でメモってきたものをまとめている。最後の方は根拠が薄い。しかしこの記事を書こうと思い二ヶ月ほど集めていたが、そこそこ集まったと思う。

Matomo

Matomo

恐らく世界で最も使われているセルフホストのアクセス解析。

日本語の「まとも」に由来している。「まともなアクセス解析」ということである。

Matomo means honesty in Japanese. We believe this reflects the culture of our community, contributors and staff, who are dedicated to delivering the most valuable and user-centric digital analytics platform.

Matomo Analytics - privacy-friendly analytics, CRO, SEO and Tag Manager

Umami

Umami

セルフホストのアクセス解析。

特に明言されていないがアイコンがご飯を盛った茶碗なので、日本語の旨味に由来していることが分かる。

Bulma

Bulma

有名なCSSフレームワーク。

ドラゴンボールの登場人物の一人、ブルマに由来している。

Did Dragon Ball have anything to do with naming it?

Absolutely.

Initially, the project was supposed to be a theme generator named Trunks but trunks.io was unavailable.

I imagined dividing the generator into "capsules" that you would choose a selection from to generate the theme you want. That's where the name Bulma came into mind, as her father founded Capsule Corp.

what is the motivation for this project? · Issue #17 · jgthms/bulma

Onsen UI

Onsen UI

Web UIフレームワーク。

特に明言されていないがアイコンが温泉マークなので、日本語の温泉に由来していることが分かる。

Jinja

Jinja

Python製テンプレートエンジンのデファクトスタンダードともいえる存在。

特に明言されていないがアイコンが鳥居なので、日本語の神社に由来していることが分かる。恐らくTempleとTemplateを掛け合わせた洒落だろう。

Nokogiri

Nokogiri

RubyのXHTML, HTMLパーサー。ブランドアイコンが「鋸」の文字であるため日本語由来であることが分かる。

HCL

HCL

AWSなどのクラウドインフラを管理する上ではデファクトといっても過言ではないIaaS。

作者の橋本さんの名字から取られているので一応日本語由来と言える。ちょっとこれは無理があるかもしれない。

HCL and HIL originate in HashiCorp Terraform, with the original parsers for each written by Mitchell Hashimoto.

MeCab

MeCab

日本語の形態素解析エンジンでは最も有名なものだと思う。

由来はわかめの根っこの部分、ぬるぬるコリコリしたあのめかぶ。

Mozc

Mozc

Google日本語入力の元になったと言われるIMEシステム。かつてはLinux系のデスクトップ環境のIMEの定番だったが最近は揺らぎつつあるという話も…?

由来は沖縄で主に生産されている海藻のもずくだと思われるが、特に明言されていない。

Anthy

Anthy

かつて日本語Linux環境でデファクトスタンダードだったIME。

Wikipediaによると由来は少女革命ウテナの登場人物、姫宮アンシーからとのこと。

Oniguruma

Oniguruma

恐らくPCREに次ぐ知名度を誇る正規表現エンジンだったもの。かつてはPHPの正規表現エンジンだったこともあった。2025年で開発が終了している。開発者は日本人。

由来は鬼車。意味がある言葉なのかは謎。

Namazu

Namazu

昔よく使われていた日本語全文検索エンジン。かつて規模が大きめのPerl CGIに搭載されていた。

由来は魚のナマズ。

Noto

Noto - Google Fonts

Googleのフォントシリーズ、Noto <書体> <言語名>というフォントが存在し、ほとんど大抵の言語でゴシック体(Sans-serif)と明朝体(Serif)のフォントをカバーしている。

由来としては豆腐文字をなくすところにあるとされており、ノー豆腐から来ている。

The name is also short for "no tofu", as the project aims to eliminate 'tofu': blank rectangles shown when no font is available for your text.

Bento.me

Bento.me

リンクアグリゲーター。弁当箱の中身のようにコンテンツを配置してレイアウトできるのが特徴だった。

特に明言されていないがアイコンが弁当箱なので、日本語の弁当に由来していることが分かる。

Linktreeに買収されたはずなのに復活していた。

Raku

Raku

プログラミング言語。本来Perl 6となるはずだったが、大人の事情でRakuに改名されたもの。恐らく改名の理由としてはPerlという名前が世界的に非常に悪い印象を持っていたせい。

Rakuの名前に関する議論では、日本語での読み方が提唱されていることから、Rakuは日本語に由来しているとみてよいと思う。

I'm pretty sure that Raku is pronounced らく. I hope you're all up for pronouncing [ɾ].

また後述するがRaku言語の実装であるRakudoは確実に日本語に由来しており、RakudoのRakuを切り取ったのがRaku言語だと思われるので、日本語に由来といっても過言ではないと考える。

参考までにPerl6のIRCログでは「Raku」が完全に日本語と紐づけられた文脈で語られており、YAPC-JPの話さえ登場している。

Rakudo

Rakudo

プログラミング言語Rakuのコンパイラ。RakuはJavaScriptやC言語のように仕様だけが存在する言語なので、実装としてRakudoが存在する。昔はPerl v6と呼ばれていたが、Perlと決別して別の道を歩み始めたらしい。

明確な一次ソースが見当たらないがuse Perlの記事によると次のようにある。

Some years ago, Con Wei Sensei introduced a new martial art: "The Way
Of The Camel". Or, in Japanese: "Rakuda-do". This name quickly became
abbreviated to "Rakudo", which happens to mean "paradise" in Japanese.

要約すると「Perlのマスコットはラクダだが、Perlをラクダの道と表現する場合、日本語では駱駝道になる。そしてラクダドウを省略して呼ぶと楽土となり、これは天国を意味する。」ということだ。

Raku言語の公式サイトにも次の記述がある。

Rakudo is the name of a Raku implementation that runs on MoarVM and the JVM. It is an abbreviation of Rakuda-do, which, when translated from Japanese, means "The Way of the Camel". Also, in Japanese, "Rakudo" means "Paradise."

Hanko

Hanko

認証基盤。

特に明言されていないがアイコンが判子なので、日本語の判子に由来してことが分かる。

Itamae

Itamae

日本製と思われる構成管理ツール。

特に明言されていないが日本人が作っていることや、組織名がitamae-kitchenであるため、日本語の板前に由来していることが分かる。

Sensu

Sensu

Sumo Logicという会社が開発している監視ツール。

扇子の折り畳みのような柔軟性が由来らしい。

Sensu means “folding fan” in Japanese, which speaks to Sensu’s flexibility and fanout model

https://sensu.io/blog/announcing-the-sensu-roadmap-sensu-go-release-date

MEGANE

MEGANE

ルノーの自動車製品。

Wikipediaによると日本語の眼鏡を意識して命名されたらしい。日本語読みは「メガーヌ」。

SharkNinja Operating, LLC

SharkNinja Operating, LLC

アメリカにある家電メーカーの会社名。掃除機で有名なSharkの社名のフルバージョン。

Ninjaという単語が日本語以外由来である可能性が考えづらいので、恐らく日本語と思われる。

Ninjaというクッカーも出しているので、一応これは製品名と言える。ヤマダ電機やエディオンの店頭では見なかったが、ケーズデンキには置いてあった。

Atari

ゲーム開発の会社。アタリショックという社会現象を引き起こしたことで知られる。

公式情報ではないがWikipediaの記事には次のようにあり、日本語が由来であると考えられる。

社名は囲碁の日本棋院初段を持つブッシュネルが囲碁用語「アタリ」から取った

Zen

AMDのRyzen CPUに採用されているマイクロアーキテクチャ。

一般論として「禅」であるとされているが公式資料が見つからなかった。

PCWorldの記事には次の一文があり、日本語の書かれた円相の写真もあることから、日本語由来である可能性がある。

The font adheres to Zen principles

Ryzenのパッケージに円相が書いてあるのも恐らくその関係。

あとがき

はてなとか、日産サクラとか、あからさまなものは除外しているが、その割にNamazuが入ってるし選定基準は我ながら恣意的だなと思った。