2026/08/04(火)PHPとPerlでは配列変数を変数に代入してもシャローコピーされない
私は今までプログラミング言語の鉄則として、プリミティブを代入すれば値が、オブジェクトを代入すれば参照が渡され、オブジェクトの実体を渡す場合にはディープコピーが必要だと考えていたが、PHPでは違うことに気が付き、常識を打ち破られたので備忘録として残す。
調べている中でPerlでもPHPと同じ振る舞いをすることに気づいた。
言語別の比較
以下は言語別に配列変数を別の変数に代入し、代入側変数を操作したときに、元の変数に影響を与えるか、つまり参照代入になるか調べた結果だ。
❌通常代入=プリミティブと同じ、✅参照代入=いわゆるポインタ渡しされる、という意味合いで書いている。頭の絵文字は視認性のために付けているだけで、特に意味はない。
| 言語 | PHP | Perl | Ruby | Python | JavaScript | C# |
|---|---|---|---|---|---|---|
| 配列 | ❌通常代入 | ❌通常代入 | ✅参照代入 | ✅参照代入 | ✅参照代入 | ✅参照代入 |
| 連想配列 | ❌通常代入 | ❌通常代入 | ✅参照代入 | ✅参照代入 | ✅参照代入 | ✅参照代入 |
| クラス | ✅参照代入 | ✅参照代入 | ✅参照代入 | ✅参照代入 | ✅参照代入 | ✅参照代入 |
PHPは公式ドキュメントにもそう書いてあった。
配列への代入においては、常に値がコピーされることに注意してください。 配列をリファレンスでコピーする場合には、 リファレンス演算子を使う必要があります。
そもそもPHPではオブジェクトと配列が別の概念として書かれているので、扱いが異なるのかもしれない。
各言語による処理結果
PHP
PHP 8.5.8で確認。
<?php
$arr1 = array('1', '2');
# ARR1 1, 2
echo "ARR1 {$arr1[0]}, {$arr1[1]}\n";
$arr2 = $arr1;
$arr2[0] = '3';
# ARR2 1, 2
echo "ARR2 {$arr1[0]}, {$arr1[1]}\n";
# ARR3 3, 2
echo "ARR3 {$arr2[0]}, {$arr2[1]}\n";
$hash1 = array(
'hoge' => 'a',
'fuga' => 'b'
);
# HASH1 a, b
echo "HASH1 {$hash1['hoge']}, {$hash1['fuga']}\n";
$hash2 = $hash1;
$hash2['hoge'] = 'z';
# HASH2 a, b
echo "HASH2 {$hash1['hoge']}, {$hash1['fuga']}\n";
# HASH3 z, b
echo "HASH3 {$hash2['hoge']}, {$hash2['fuga']}\n";
$cls1 = new stdClass();
$cls1->hoge = 'A';
$cls1->fuga = 'B';
# CLS1 A, B
echo "CLS1 {$cls1->hoge}, {$cls1->fuga}\n";
$cls2 = $cls1;
$cls2->hoge = 'Q';
# CLS2 Q, B
echo "CLS2 {$cls1->hoge}, {$cls1->fuga}\n";
# CLS3 Q, B
echo "CLS3 {$cls2->hoge}, {$cls2->fuga}\n";
# ARR1 1, 2
# ARR2 1, 2
# ARR3 3, 2
# HASH1 a, b
# HASH2 a, b
# HASH3 z, b
# CLS1 A, B
# CLS2 Q, B
# CLS3 Q, B
Perl
Perl v5.38.2で確認。
use strict;
use warnings;
my @arr1 = ('1', '2');
# ARR1 1, 2
print "ARR1 $arr1[0], $arr1[1]\n";
my @arr2 = @arr1;
$arr2[0] = '3';
# ARR2 1, 2
print "ARR2 $arr1[0], $arr1[1]\n";
# ARR3 3, 2
print "ARR3 $arr2[0], $arr2[1]\n";
my %hash1 = (
'hoge' => 'a',
'fuga' => 'b'
);
# HASH1 a, b
print "HASH1 $hash1{'hoge'}, $hash1{'fuga'}\n";
my %hash2 = %hash1;
$hash2{'hoge'} = 'z';
# HASH2 a, b
print "HASH2 $hash1{'hoge'}, $hash1{'fuga'}\n";
# HASH3 z, b
print "HASH3 $hash2{'hoge'}, $hash2{'fuga'}\n";
my $cls1 = bless {
hoge => 'A',
fuga => 'B'
}, 'StdClass';
$cls1->{'hoge'} = 'A';
$cls1->{'fuga'} = 'B';
# CLS1 A, B
print "CLS1 $cls1->{hoge}, $cls1->{fuga}\n";
my $cls2 = $cls1;
$cls2->{'hoge'} = 'Q';
# CLS2 Q, B
print "CLS2 $cls1->{hoge}, $cls1->{fuga}\n";
# CLS3 Q, B
print "CLS3 $cls2->{hoge}, $cls2->{fuga}\n";
# ARR1 1, 2
# ARR2 1, 2
# ARR3 3, 2
# HASH1 a, b
# HASH2 a, b
# HASH3 z, b
# CLS1 A, B
# CLS2 Q, B
# CLS3 Q, B
Ruby
Ruby 4.0.5で確認。
arr1 = ['1', '2']
# ARR1 1, 2
puts "ARR1 #{arr1[0]}, #{arr1[1]}"
arr2 = arr1
arr2[0] = '3'
# ARR2 3, 2
puts "ARR2 #{arr1[0]}, #{arr1[1]}"
# ARR3 3, 2
puts "ARR3 #{arr2[0]}, #{arr2[1]}"
hash1 = {
'hoge' => 'a',
'fuga' => 'b'
}
# HASH1 a, b
puts "HASH1 #{hash1['hoge']}, #{hash1['fuga']}"
hash2 = hash1
hash2['hoge'] = 'z'
# HASH2 z, b
puts "HASH2 #{hash1['hoge']}, #{hash1['fuga']}"
# HASH3 z, b
puts "HASH3 #{hash2['hoge']}, #{hash2['fuga']}"
class HogeCls
attr_accessor :hoge, :fuga
def initialize(_hoge, _fuga)
@hoge = _hoge
@fuga = _fuga
end
end
cls1 = HogeCls.new('A', 'B')
# CLS1 A, B
puts "CLS1 #{cls1.hoge}, #{cls1.fuga}"
cls2 = cls1
cls2.hoge = 'Q'
# CLS2 Q, B
puts "CLS2 #{cls1.hoge}, #{cls1.fuga}"
# CLS3 Q, B
puts "CLS3 #{cls2.hoge}, #{cls2.fuga}"
# ARR1 1, 2
# ARR2 3, 2
# ARR3 3, 2
# HASH1 a, b
# HASH2 z, b
# HASH3 z, b
# CLS1 A, B
# CLS2 Q, B
# CLS3 Q, B
Python
Python 3.12.0で確認。
arr1 = ['1', '2']
# ARR1 1, 2
print(f"ARR1 {arr1[0]}, {arr1[1]}")
arr2 = arr1
arr2[0] = '3'
# ARR2 3, 2
print(f"ARR2 {arr1[0]}, {arr1[1]}")
# ARR3 3, 2
print(f"ARR3 {arr2[0]}, {arr2[1]}")
hash1 = {
'hoge': 'a',
'fuga': 'b'
}
# HASH1 a, b
print(f"HASH1 {hash1['hoge']}, {hash1['fuga']}")
hash2 = hash1
hash2['hoge'] = 'z'
# HASH2 z, b
print(f"HASH2 {hash1['hoge']}, {hash1['fuga']}")
# HASH3 z, b
print(f"HASH3 {hash2['hoge']}, {hash2['fuga']}")
class HogeCls:
def __init__(self, _hoge, _fuga):
self.hoge = _hoge
self.fuga = _fuga
cls1 = HogeCls('A', 'B')
# CLS1 A, B
print(f"CLS1 {cls1.hoge}, {cls1.fuga}")
cls2 = cls1
cls2.hoge = 'Q'
# CLS2 Q, B
print(f"CLS2 {cls1.hoge}, {cls1.fuga}")
# CLS3 Q, B
print(f"CLS3 {cls2.hoge}, {cls2.fuga}")
# ARR1 1, 2
# ARR2 3, 2
# ARR3 3, 2
# HASH1 a, b
# HASH2 z, b
# HASH3 z, b
# CLS1 A, B
# CLS2 Q, B
# CLS3 Q, B
JavaScript
Node.js v24.16.0、Microsoft Edge 150.0.4078.105で確認。
const arr1 = ['1', '2'];
// ARR1 1, 2
console.log(`ARR1 ${arr1[0]}, ${arr1[1]}`);
const arr2 = arr1;
arr2[0] = '3';
// ARR2 3, 2
console.log(`ARR2 ${arr1[0]}, ${arr1[1]}`);
// ARR3 3, 2
console.log(`ARR3 ${arr2[0]}, ${arr2[1]}`);
const hash1 = {
hoge: 'a',
fuga: 'b'
};
// HASH1 a, b
console.log(`HASH1 ${hash1['hoge']}, ${hash1['fuga']}`);
const hash2 = hash1;
hash2['hoge'] = 'z';
// HASH2 z, b
console.log(`HASH2 ${hash1['hoge']}, ${hash1['fuga']}`);
// HASH3 z, b
console.log(`HASH3 ${hash2['hoge']}, ${hash2['fuga']}`);
class HogeCls {
constructor(_hoge, _fuga) {
this.hoge = _hoge
this.fuga = _fuga
}
}
const cls1 = new HogeCls('A', 'B');
// CLS1 A, B
console.log(`CLS1 ${cls1.hoge}, ${cls1.fuga}`);
const cls2 = cls1;
cls2.hoge = 'Q';
// CLS2 Q, B
console.log(`CLS2 ${cls1.hoge}, ${cls1.fuga}`);
// CLS3 Q, B
console.log(`CLS3 ${cls2.hoge}, ${cls2.fuga}`);
// ARR1 1, 2
// ARR2 3, 2
// ARR3 3, 2
// HASH1 a, b
// HASH2 z, b
// HASH3 z, b
// CLS1 A, B
// CLS2 Q, B
// CLS3 Q, B
C#
バージョンの基準が謎だが、Visual Studio 2022の標準的な環境で確認した。
var arr1 = new[] { "1", "2" };
// ARR1 1, 2
Console.WriteLine($"ARR1 {arr1[0]}, {arr1[1]}");
var arr2 = arr1;
arr2[0] = "3";
// ARR2 3, 2
Console.WriteLine($"ARR2 {arr1[0]}, {arr1[1]}");
// ARR3 3, 2
Console.WriteLine($"ARR3 {arr2[0]}, {arr2[1]}");
var hash1 = new Dictionary<string, string> {
["hoge"] = "a",
["fuga"] = "b"
};
// HASH1 a, b
Console.WriteLine($"HASH1 {hash1["hoge"]}, {hash1["fuga"]}");
var hash2 = hash1;
hash2["hoge"] = "z";
// HASH2 z, b
Console.WriteLine($"HASH2 {hash1["hoge"]}, {hash1["fuga"]}");
// HASH3 z, b
Console.WriteLine($"HASH3 {hash2["hoge"]}, {hash2["fuga"]}");
var cls1 = new HogeCls("A", "B");
// CLS1 A, B
Console.WriteLine($"CLS1 {cls1.Hoge}, {cls1.Fuga}");
var cls2 = cls1;
cls2.Hoge = "Q";
// CLS2 Q, B
Console.WriteLine($"CLS2 {cls1.Hoge}, {cls1.Fuga}");
// CLS3 Q, B
Console.WriteLine($"CLS3 {cls2.Hoge}, {cls2.Fuga}");
class HogeCls {
public string Hoge { get; set; }
public string Fuga { get; set; }
public HogeCls(string hoge, string fuga) {
this.Hoge = hoge;
this.Fuga = fuga;
}
}
// ARR1 1, 2
// ARR2 3, 2
// ARR3 3, 2
// HASH1 a, b
// HASH2 z, b
// HASH3 z, b
// CLS1 A, B
// CLS2 Q, B
// CLS3 Q, B
あとがき
PHPのクラスなんて連想配列の派生形だと思ってたら、PHPではクラスこそがオブジェクトということで大変驚いた。一般論としては文字列・数値・真偽型がプリミティブ、それ以外の配列や連想配列(ハッシュ)・クラス・構造体はオブジェクトとして考えていただけに強く常識を打ち破られた気持ちだ。
とはいえ、配列は構造体ではないはずなので、構造体から派生するクラスと配列が別になるという思想そのものもわからなくはない。わからなくはないけど気持ち悪い。
PHPも進化しているので将来的には見直されるかもしれないし、されないかもしれない。後方互換性をしょっちゅう切り捨ててる印象があるので、何があっても不思議がないのも、またPHPだと思う。そしてPerlは恐らく変わらないだろう。
しかしいわゆるLL、軽量プログラミング言語と呼ばれているPerl、PHP、Ruby、Pythonのうち、RubyとPythonは違う振る舞いを示したのも興味深かった。一体何があったのか…。
2026/07/28(火)第七話 ここ一ヶ月くらいのサイトいじり
第六話 最近のサイトいじりの続き。気が向いたときに地道に直している。
やっていることとしてはほとんど昔ながらのHTML直書きなのでどうにかしたいが、まぁ今は過渡期ということで…。
リンク集のスタイリングを共通化
ビフォーもあっさりしていて、それはそれでよかった気がしなくもないが、まぁ…。
コード的には共通化分がざっくり消えている。
リンク集のスタイリングの見直し
三列は詰まりすぎていたので、二列にした。
更新履歴の余白を改善
どっちかというと共通化時にパディング用のコンテナの挿入が漏れていただけだが…。
スライド置き場を新設し、スタイリングを段階的に改善
単にスライドが見れるだけだった状態から、いつどこで発表したスライドかが解るようにした。
以前はGoogle Docsに置いており、Googleフォントに勝手に置換されたり様々な変換が行われた結果、MS Officeで作ったスライドのレイアウトが崩れていたが、自分のサイトにPDFで置くことでこの問題が地味に改善した。
スライドのセルフホストに当たり幾つか検討したものがあり、セルフホストできるスライド共有サイトをつくったや、jukkan/ShareSlidesの二つを検討したが、結果としてPDF直置きにした。
「セルフホストできるスライド共有サイトをつくった」は画像になっており、文字が取れず、リンクも拾えない部分がマッチしなかった。またラスタ画像なのでベクタ画像を拡大すると微妙になりそうなのもあり、採用しなかった。
jukkan/ShareSlidesはPDFを正常に表示することができず断念した。運用上もGitHub Actionsを使わないなら複数のJSONをいじったり仕組みが大げさすぎて運用が結構面倒だと思う。GitHub Actionsを使う場合も画面操作が面倒めだと感じた。
参考までにjukkan/ShareSlidesでPDFを表示するとこのようにセグメントの隙間に線が入り、ちょっとこれはないなという感じだった。これはjukkan/ShareSlidesがPDF表示に使ってるPDF.jsのバグだと思う。
最近はブラウザのPDF閲覧環境も良くなり、そのまま開いてもさして問題がないと感じたので、直置きにした。余計な細工がなく運用コストが低いのがメリットだ。
自己紹介ページのCSSを共通化
体裁を整えるために微妙な書き方になっているのでそのうち何とかしたい。
あとがき
徐々に共通化しているが出来ていないところやページによってまちまちなところもあるので気長に直していきたい。
2026/07/28(火)A5M2からWSL2経由でRDSに接続する方法
A5M2でRDSに繋ぐ方法。aws-cliを使い、WSL2にプロキシを立てるとよい。
この方式だとSSHDを立ててトンネリングするとか、そういう作業が不要なので楽。
手順
前提としてAWSにログインしておく必要がある。
- InstanceId探し
REGION=ap-northeast-1 aws ssm describe-instance-information --region ${REGION} | jq -r '.InstanceInformationList.[].ComputerName + "\t" + .InstanceInformationList.[].InstanceId' - DBホスト探し
REGION=ap-northeast-1 aws rds describe-db-instances --region ${REGION} --query 'DBInstances[].{Endpoint:Endpoint.Address,Port:Endpoint.Port}' --output table - ブリッジの作成。これはInstanceIdに対応したDBホストを当てる必要があるが、複数ある場合どうやればいいのかはよくわかっていない
REGION=ap-northeast-1 INST_ID=i-xxxxxxxxxxx HOST=xxxxxxx.yyy.rds.amazonaws.com DIST_PORT=3306 LISTEN_PORT=13306 aws ssm start-session \ --region ${REGION} \ --target ${INST_ID} \ --document-name AWS-StartPortForwardingSessionToRemoteHost \ --parameters 'host=${HOST},portNumber=${DIST_PORT},localPortNumber=${LISTEN_PORT}' - A5M2でDB接続を次の要領で新規作成すると繋がる
- ホスト名:
127.0.0.1 - ポート番号:LISTEN_PORT
- ユーザーID:DB接続するときのもの
- パスワード:DB接続するときのもの
- ホスト名:
2026/07/24(金)PerlスクリプトをWSL2からデバッグする方法
Perlスクリプトをブレークしたりしたい時に。
確認環境
| Env | Ver |
|---|---|
| Perl | v5.38.2 |
| Ubuntu | 24.04.4 LTS |
| VSCode | 1.114.0 |
| richterger.perl | 2.6.2 |
やり方
- VSCodeにPerl拡張を入れる
code --install-extension richterger.perl 拡張機能が必要とする依存を入れる
sudo apt install build-essential libanyevent-perl libclass-refresh-perl libcompiler-lexer-perl \ libdata-dump-perl libio-aio-perl libjson-perl libmoose-perl libpadwalker-perl \ libscalar-list-utils-perl libcoro-perl sudo cpan Perl::LanguageServer.vscode/launch.jsonを書く{ "name": "Perl Debug", "type": "perl", "request": "launch", "program": "${workspaceFolder}/path/to.pl", "args": ["hoge"] }- デバッガを起動して実行する(launchモードなのでシェルから叩く必要はない)
2026/07/23(木)過去のリボ払いとか、その他の返済とかを振り返る
投稿日:
世の中ではリボ払いはとかく悪者として扱われがちだが、個人的には便利な仕組みだと思っているので、振り返りがてら個人的な過去の事例を書いてゆく。リボ以外のことはあとがきにちょろっと書いている。
なお、この記事はリボ払いを推奨するものではない。リボの返済は面倒なので使わなくて済むなら使わないに越したことはないが、いざというときには頼りになる諸刃の剣といった感じの代物である。
過去のリボ利用
利用の順序的には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万円があります。勿体なくてできません」とか、そんなことを言っても響きはしないのだ。
株式会社だって株主の投資を基に何かをして、配当を出したりしているわけで、借金というのは将来の時間を買う投資だと考えれば解り易いだろう。人生は有限で、今そこに必要な金がないのであれば、それは借りるしかないのである。