にしし ふぁくとりー:西村文宏 個人サイト

Presented by Nishishi via Movable Type. Last Updated: 2023/04/21. 23:49:49.

Sakura Scope (2023年02月)

ちょっと倒錯気味な、ただの日記です。(^^;)
これはやばいと思われた場合は、お早めに閲覧を中止されることをお勧め致します。

電気代が高ぇ! という話

過去に見たことがない電気代にビビる

1月の電気料金を見たら、今までに見たことがない額で驚きました。2ヶ月分をまとめて請求されたのかなと思うくらいに。
関西電力のウェブサイトにログインすると、1年間の電気料金と電力使用量が、今年と前年とを比較したグラフで閲覧できます。(つまり1つのグラフ内で合計2年分の情報が分かります。)
それを見たところ、たしかに1月は昨年よりも電力を消費しているのですが(=棒グラフの方)、それにしては電気代が上がりすぎ(=折れ線グラフの方)に思えます。

棒グラフは、薄い方が昨年の電力使用量で、濃い方が今年の電力使用量です。
1月(右端)を見ると、昨年よりも約10%ほど使用量は増えているのですが、料金は約40%も上がっています。(黄色矢印の先が今年1月の電気料金、橙色矢印の先が昨年1月の電気料金。)

関西電力は昨年の7月に電気料金を値上げしたので、例えば11月は今年と昨年とで使用量はほぼ同じなのに、電気代が高くなっているのが分かります。
なので、「高くなったな」とは思っていたのですけども、1月のように4割増しになるとは思っていませんでした。

なお、棒グラフに色が3種類あるのは、

  • 緑がリビングタイム(朝夕:7~10時・17~23時)
  • 橙がデイタイム  (昼間:10~17時)
  • 青がナイトタイム (深夜:23時~翌朝7時)

で、時間帯によって電力使用量に対する料金単価が分かれているからです。

オール電化なので

うちはオール電化なので、ガスを契約していません。
灯油も買っていないので、暖房もすべて電力です。
なので、エネルギーは電力に依存しています。(なかなか脆弱だなと思わなくもないですが。日常で停電する可能性をまったく想定していない生活形態ですね。^^;)

エアコンは夏も稼働していますが、夏よりも冬の方が(リビングタイムやデイタイムでも)電力使用量が多いのは、暖房運転の方が電力を食うからでしょうかね?
でも、一番使用量に差が出るのは、ナイトタイム(深夜)の電力使用量です。(さっきの棒グラフで青色の部分)

深夜は(寝ているので)暖房は使いませんが、それでも電力を消費します。お湯を作るために。

オール電化だと、お湯も電力で作る必要があります。
しかし、ガスとは違って水をすぐさまお湯にすることはできないので、お湯は「翌日1日で必要になりそうな量の分量を、深夜の安い電力を利用して前夜にまとめて湧かしておく」という仕組みになっています。電気温水器とかエコキュートとかで。

うちで使っているエコキュートの場合、「1日で必要になりそうな量」というのは、直近数日間のお湯の消費量から自動的に判断してくれるので、無駄に作りすぎることはあまりないっぽいです。詳しくは確認していませんが。(もちろん、お湯を溜めるタンクの最大容量を超えてお湯を作っておくことはできないので、居住人数に応じてタンク容量を選んでおく必要があります。370リットルとか560リットルとか。お湯の残量は台所にあるリモートの液晶画面でざっくり確認できます。旅行とかで数日間出かける場合には、無駄にお湯を作らないようにする設定とかもできた気がします。私は使ったことはありませんけども。)
よほどたくさんお湯を使って、日中に足りなくなりそうなら昼間でも追加でお湯を湧かす処理が自動で始まりますが、基本的には深夜の時間帯だけでお湯を作っておくようになっています。

※停電に対するダメージが大きい代わりに、日中に断水してもタンク内にある数百リットルのお湯は使えるというメリットはあります。(ただ、断水の経験はありませんけども。)

で、お湯は1年中使いますけども、圧倒的に冬に多く使いますよね。
夏にお湯を作っておく必要性は冬よりも低いです(それに、水の温度が高ければお湯にするのに必要なエネルギーも少なくて済みます)。なんせ、夏は水道の「水」の蛇口を捻ったってお湯が出てくるくらいですからね!(笑)
なので、冬には深夜にも電力をたくさん使うわけです。

深夜電力料金が約1.5倍になった

さて、電気料金の話に戻りますが。
関西電力では昨年7月に電気料金が上がりました。上がりましたというか、昼間はむしろ下がっているのですけども。関西電力から送られてきた改訂内容は下図の通りです。(紙をスキャンしたもの。)

上図で「電力量料金」の区画を見ると、

  • デイタイム(昼間:10~17時)では、17%ほど安くなっていて、
  • リビングタイム(朝夕:7~10時・17~23時)では、2%ほど安くなっている

……のですよね。昼間は安くなっているんです。
しかし、

  • ナイトタイム(深夜:23時~翌朝7時)は、42%も高くなっています!😱

深夜料金、上げすぎじゃ……?😭
ほとんど1.5倍とか。

あと、「通電制御型蓄熱式機器割引」というのは電気温水器とかエコキュートとかを対象にした割引だったようで、これも廃止されています。この割引額は、うちの昨年1月の場合は264円でした(2単位分ですね)。まあ、あんまり違いが出るわけではないですが、ちょっとだけ高くなる要因ではありますね。

電気料金がどうなろうと、お湯を作らないわけにはいかないですからね。^^;
深夜の電気料金が約1.5倍になったと言っても、単価で比較すれば昼間の電気料金より安いことには変わりないので、やっぱり「深夜にお湯を作っておく」のが一番安いことにも変わりないわけですよね。
なので、要するに「ただ値段が上がった」だけで、何もできることはないわけですが。orz

燃料費調整額という項目があった(他にもいくつか)

で、上図だけを見ると、深夜に電力をたくさん使う冬で、深夜の電気料金が42%も上がったから高くなったように見えるわけですが(実際にその通りですけども)、それにしても総額が高くなりすぎなのでは……? と思いまして、電気消費量のグラフではなくて、電気料金全体の内訳が書いてある検針票を見てみました。

すると、「基本料金」・「電力量料金」以外にも、いくつか加算される料金がありました。
そのうちの1つが、燃料費調整額です。

関西電力のWebによると、燃料調整費というのは、為替レートとか原油価格を電気代に反映させる燃料費調整制度による費用で、1ヶ月の電気総使用量に単価を掛けて算出されるのだとか。
使用時間帯に関係なく、使えば使うほど高くなる要素がここにもあったんですね。

  • 今年1月の燃料費調整額は、約15,000円くらい。
  • 昨年1月の燃料費調整額は、約 1,500円くらい。

……10倍!?😱

検針票には、燃料調整費の単価も印字されていたんですが、

  • 今年1月の燃料調整費単価は、+10円91銭
  • 昨年1月の燃料調整費単価は、+1円20銭

と書いてありました。
燃料調達費が10倍とかになっているのか……。

12月の燃料調整費単価も、+10円15銭で同じくらい高いですが、1ヶ月の電気総使用量がそこまで多くなかったので絶対額はあまり高くなっていなかったんですね。
(直近の調達費が反映されるわけではなく、関西電力の解説を見ると、1月分の料金に反映されるのは、8~10月の平均燃料価格っぽいです。)

あと、昨年にはなかった「廃炉円滑化負担金相当額」という項目も加わっていましたが。これも総使用量に連動して増減するんですかね?
他には「再エネ促進賦課金」という項目もありましたが、これは昨年にもあって、額もほぼ同じでした。

2月の電力使用量は昨年とほぼ同じだった(でも料金は11%高い)

で、2月の電力使用量の通知が来たので、グラフで確認してみました。それが下図です。

たまたま、電力使用量は昨年とほぼ同じでした。約0.2%ほど今年の方が少ないだけです。(棒グラフ:黄色矢印の先)
しかし、電気料金は、11%ほど高くなっていましたが。(折れ線グラフの方:橙色矢印の先)

ただ、1月ほどの大きな差にはなっていません。
これは、総使用量が(1月よりも)少ないだけでなく、燃料費単価が+4円20銭で、1月より6割も減っていることも影響しているようです。燃料費ってそんなに上下激しいんですかね……。

今まで気にしたことがなかったんですが、12月半ばから1月半ばにかけて(=1月分の料金になる期間)が一番電力(とお湯)を使っているんですね……。
1月から2月にかけての方がもっと寒そうで電力もお湯も使いそうな気がするんですけども。

お湯の値段

そんなわけで、深夜電力料金が約1.5倍になったので、お湯を作る費用も約1.5倍になった、という話でした。orz

もうちょっと暖冬になってくれんかな……。^^;

timelocal関数に渡す年の値は、西暦から1900を引かない方が良い

timelocal関数へ渡す「年」の値は、西暦を-1900せずに、そのままの4桁を渡す!

エポック秒(UNIX時間)から日時を得るPerlの組み込み関数 localtime では、「年」の値が1900年からの相対値で得られる仕様なので、返ってきた値から西暦を知るには 1900 を足してやる必要があります。

で、そのlocaltime関数と逆のこと(=日時をエポック秒に変換)をやってくれる Time::Localモジュールの timelocal関数では、当然「年」の値を「西暦-1900」で渡さねばならないのだろう……と思ってそうしていたのですけども、そうするのは望ましくないんですね!
timelocal関数に「年」の情報を渡すときには、普通に西暦の4桁をそのまま渡せば良いのであって、1900を引いてしまうと(たまたま意図通りの結果が得られるケースもあるのですけども)場合によっては意図しない結果が得られることもあるのだと知りました。

▼過去の日付のつもりなのに、未来の日付だと解釈されるケースがある

具体的には、西暦から1900を引いた結果が2桁の数値になる場合、その2桁の数値を年の値としてtimelocal関数へ渡してしまうと、「現在から50年以上前の日付」に対しては未来の日付だと解釈されてしまう仕様なのだそうです。

  • 西暦から1900を引いた値が2桁の場合、それは「今年から見た前後50年間の西暦の下2桁」だと解釈される
  • 西暦から1900を引いた値が3桁の場合は、1900年からの経過年数だと解釈される。(なので2899年までは問題ない)

……という仕様なのだとか。

わざわざ -1900 する手間をかけると(変換可能な年の幅に制約ができて)不便になってしまい、
そのまま西暦を渡せば何の問題もなく変換できる仕様だったとは……。

なんてこったい。┌(:3」└)┐

▼気付いたのは50年以上前の日付を扱ってみたとき

なんか1973年あたり以前の日付を処理するときにおかしなことになるなあ……と思って調べてみたところ、下記の分かりやすい解説記事を見かけて初めて知りました。^^;
Perl : [ timegm / timelocal ] で「年」引数の仕様の正しい理解と使い方について

今年が2023年なので、50年前の1973年あたり以前の日付を示そうとして例えば 72 を渡すと、それは 1972年のことではなく 2072年のことだと解釈されるわけですね。
1972年を示したいのなら、単に 1972 をそのまま(timelocal関数へ)渡せば良かったのでした。

localtime関数でエポック秒(UNIX時間)から日時を得る場合 → 年には1900を足し、月には1を足す

例えば、変数 $epoch に任意のエポック秒が入っているとき、

my ($sec, $min, $hour, $mday, $month, $year, $wday) = localtime($epoch);
$year += 1900;	# 1900を足すと西暦になる(=西暦1900年からの相対値で得られるため)
$month += 1;	# 1を足すと月になる(=Januaryが0でDecemberが11なので)

……のような感じでPerlソースを書くと、変数 $year には西暦、$month には月、$mday には日、$hour には時、$min には分、$sec には秒が入ります。
なお、$wday には曜日が数値で入ります。(0=日曜日、1=月曜日、……、6=土曜日)

このように、localtime関数では、西暦を得るには返ってきた年の値に 1900 を足さないといけませんし、月を得るには返ってきた月の値に 1 を足さないといけません。

timelocal関数で日時からエポック秒(UNIX時間)を得る場合 → 年には西暦そのまま、月は1を引く

上記の逆で、各変数に格納された任意の年・月・日・時・分・秒の値(=下記2行目)からエポック秒を求める場合は、

use Time::Local;
my ($year, $month, $mday, $hour, $min, $sec) = (2023, 2, 23, 12, 34, 56);  # 年・月・日・時・分・秒の値
$year -= 1900;	# ←この処理は要らない……!
$month -= 1;	# 月は0~11でないといけないので1を引く
my $epoch = timelocal($sec,$min,$hour,$mday,$month,$year);

変に西暦から1900を引いたりせずに西暦4桁はそのまま渡して、上記のような感じでPerlソースを書くと、変数 $epoch に指定した日時のエポック秒(UNIX時間)が数値で入ります。

というわけで

localtime関数とは違って、timelocal関数の年の値は最初から西暦4桁をそのまま渡せる仕様なので、何も加工せずに西暦4桁の数値を引数に与えれば良いのだった、という話でした。

Google Pixel 6a を手に入れて携帯電話がようやくスマートフォンになった話

ガラケーからスマートフォンに

2022年の終わりにスマートフォンとして「Google Pixel 6a」を調達しまして、ようやく私が個人的に持つ携帯電話がガラケーではなくスマートフォンになりました。(^_^;)

Google Pixel 6a
▲Google公式ストアから調達したGoogle Pixel 6a

いや、モバイル端末としては、以前から iOS端末(iPod touch)も Android端末 も FireOS端末(Kindle)もあったので、別にモバイル環境に不自由はしていなかったのですけども。ただ、電話機能のあるモバイル端末を所有していなかっただけで。(どれもWi-Fi通信専用の端末なのでSIMが挿せないため、「電話」ではなかったのでした。)

普段から電話(音声通話)を使うことが滅多にないこともあって、その環境に困ってはいなかったのですけども、そろそろ携帯各社が3G回線の提供自体を終了してしまう感じなので(SoftBankは2024年1月で終わるらしいです)、あと1年程度でガラケー(の少なくとも私が所有している機種)は使えなくなりますから、さすがにそろそろ電話もスマートフォンにするか……、と思い立ったのでした。

サービス終了ギリギリまで待っても良かったのですが(以前はそのつもりだったのですけども)、ガラケーのバッテリの持続時間がものすごく短くなってきていましたので、いざ電話しないといけない緊急事態になったときにバッテリが切れていたら意味がありませんから、まあ今のうちに変えておくことにしました。ガラケーはスマートフォンとは違ってバッテリは簡単に交換可能ですけども、もはや交換バッテリが販売されていないので調達しようがありませんし、たとえ調達できたとしても最大であと1年しか使えないのでは意味が薄いですしね。

OSをAndroidにすることは決まっていたので、選択肢が多い

スマートフォンとしてはAndroid端末を調達することは最初から決めていました。
小型モバイル端末としては既に第7世代 iPod touch を所有しているわけですから、小型モバイルなiOS環境はあります。ここでiPhoneを調達してさらに同じOSの端末を重複させても意味が薄いですから。
それに、iPhoneよりAndroid端末の方が全体的に安めですしね。(しかも、めちゃくちゃすごい円安に突入してしまった影響なのか、半導体の品薄の影響なのか、あとアメリカのインフレの影響も加わってか、Appleの値上げもすごいですし。)

※ただ、AppleはiPod touchの製造を終了すると正式に発表してしまいましたから、iPod touchは現在の第7世代で終わってしまいます。なので、今後はiPhoneしか選択肢がなくなる感じですけども。代わりにもっと小型で安価な(スマートフォンサイズの)iPadを出してくれることを期待したいところですが。(その期待が薄そうな感じがする話は、先月に書きました。)

▼どこ製の端末にするか

で、Android端末はハードウェアメーカーがいろいろなので選択肢が豊富です。
SONYのXperiaは魅力的でしたが、めちゃくちゃ高いですね……。^^;
逆にSHARPはすごく手頃な価格です。

日本メーカーの製品(まあSHARPを今でも日本メーカーと言って良いのかどうかよく分かりませんが)を買おうかなとも思ったのですけども、開発用途のためにはOSメーカー純正の機器(≒OS的に最も標準的なハードウェア構成なのだろうと思われる機器)があった方が良いかなとも思いまして、結局Google Pixel 6aを選択しました。
いや、Androidアプリを開発する予定は今のところないのですけども。
まあ、この先どうするかは分かりませんし?^^;

Google Pixel 6a を調達

というわけで、冒頭の写真にあるとおり、Google Pixel 6a を手に入れました!
Googleストアの直販で、53,900円でした。

iPod touchと比較するとずいぶん違いますね(当たり前ですけども)。
下写真の左側がGoogle Pixel 6aで、右側がiPod touchです。どちらも樹脂製の透明ケースを付けています。

Google Pixel 6a と 第7世代iPod touchとの比較写真

なんとなくぼんやり予想していたよりは大きく感じます。あと、予想よりもずっしり重量がある感じもします。
スマートフォンとしては別に重たいわけではないだろうとは思いますが。カタログ値で176gですから。

▼もう値下げされておるorz ……と思ったけど

「Google Pixel 6a」自体は昨年7月の発売なので、そこから4ヶ月後の昨年11月にGoogle直販で購入したわけですが、今年の1月に改めてGoogleストアを覗いてみましたら、10,920円引きの42,980円で販売されていました……。orz
値下げが早い……。

発売後半年で1万円も下げるんですねえ……。
しかも、こんな円安の世の中なのに。

……と思っていたのですが、いま見たら、また53,900円に戻っていました。
あれは年始のキャンペーン価格とかだったのかな……?^^;

回線はLINEMO

回線はLINEMOを契約しました。
とはいえ、別にLINEMOに特別な思い入れは何もありません。
LINEMOを採用したのは、SoftBankからの乗り換えだとMNP予約番号が不要で、手続きが楽だからです。
(今までSoftBankのガラケーを使っていましたので、そこから電話番号を維持しての乗り換えですから。)

SoftBankからの決済方法をそのまま引き継いだからかもしれませんが、実際に本人確認すらも不要で、あっという間にWeb上だけで契約移行手続きが完了しました。

契約したのは月額990円のミニプランです。ガラケー時代のSoftBank基本料金が934円でしたから、ほぼ同じくらいですね。
LINEMOの通信サービスそのものに特別な魅力は感じていないので他の会社にしても良いのですが、別に他の会社にしなければならない理由も特にありませんから、しばらくはLINEMOを使うつもりです。

携帯各社が格安プランを作る前だったらもっといろいろ考えたと思いますが、今では各社もMVNO並に安いですものね……。

※通信速度が300kbpsで良いならMVNOのmineoで月額660円とかもありますけども。しかも、なんと通信速度が32kbpsで良いなら(つまり本当に電話としてしか使わないなら)月額250円のコースも新たにできるようですが。本当に電話(=電話番号経由の音声通話)しか使わない人にとっては、月額250円で回線を確保できるのは理想的な気がします。私はその逆で「電話ほとんど使わない」わけですが。^^;

なお、留守番電話サービスは契約していませんし、留守電機能もないので、留守電はありません。
そもそも、電話が掛かってくること自体がほとんどないんですよね。なので、留守電も別に要らないかなと。
ガラケーで困らなかったのも、携帯電話はあくまでも「緊急連絡用の保険」みたいなもので、持ち歩きはするものの通話に使うことは滅多にない(年に数回)というような感じでしたから。
通話よりも、SMSによる個人認証用途の方がよほど使用頻度が高い感じです。

単独でネットに繋がる端末

で、早速 Google Pixel 6a にSIMを挿してスマートフォンとして使っているわけですが。

モバイルルータにWi-Fiで接続しなくても、モバイル端末(スマートフォン)単独でネットに繋がる感覚がちょっと新鮮です。(笑)
SIMを挿しているのですから当たり前ですけども。

これまでに所有してきたどのモバイル端末も(SIMを挿す機能自体がないので)通信手段はWi-Fiのみですから、外でインターネットに接続するためには(普段から持ち歩いている)モバイルルータにWi-Fiで接続しなければなりません。繋ぎっぱなしにしておけば問題ないので、別に不便はないのですが。(自宅で使う場合は自宅回線にWi-Fiで接続します。)
「こいつは、モバイルルータがなくてもネットに繋がるのだな……」と思ったらちょっと不思議な感じがしました。(笑)

あと、スマートフォン上の通信回線の表示が「5G」になると、「おぉ、これが5Gか……」とちょっと思いました。^^;
別にだから何か変わるわけではありませんけどもね。^^;

5G表示

モバイルルータを維持するか、テザリングを使うか

私は各種モバイル機器を外出時に一括してネット接続するために、モバイルルータを持ち歩いています。
最初(10年以上前)は外出時にノートPCをネット接続する目的だったのですけども、今では iPad touch とかその他のタブレットとかを接続する用途にも使っています(外出時だけ)。そのモバイルルータに挿しているSIMの月額料金が990円です。月間の通信量をもっと多くしたい場合にはもうちょっとかかるんですが、コロナ禍以後の働き方ではほとんど外で通信することがなくなりましたので、概ねこの料金で済んでいます。

とすると、LINEMOの契約で月間3GBの通信が可能なので、スマートフォンのテザリングを使って各種モバイル機器を接続させることにすれば、モバイルルータが不要になります。そうすると、もちろんそのモバイルルータに挿しているSIM契約も不要になります。
これをどうするかな……と考え中です。

携帯電話にかかる料金はこれまでとほぼ同じなので、別にそこを節約しなければならないわけではないのですけども。
でも、無駄な料金を払うのも完全な無駄ですからね……。

テザリングを使うことにするメリットは、

  • モバイルルータを持ち歩く必要がなくなる。
  • モバイルルータに挿しているSIMを解約できるので月額990円が浮く。

デメリットは、

  • スマートフォンのバッテリ残量の減り方が速くなる。
  • モバイルルータよりもスマートフォンの方が遙かに重たい。(モバイルルータは71gしかありません)

くらいでしょうか?

「予備回線が1つ減る」という点もデメリットと言えるかもしれませんが、そこは従来は電話にしか使えなかったガラケー回線がネット回線化したわけですから、「回線数は変わらない」という考え方もできる気もします。

自宅の固定回線が何らかのトラブルで接続不能になったときのバックアップとして、モバイルルータ側の回線を使うことが過去に何度かありました。モバイルルータはUSB経由でPCに接続すれば、そのPCをネットに接続できますので。デスクトップPCとかで、PC側にWi-Fi機能がなくても使えます。
そのバックアップがなくなるデメリットもありますね。もっとも、PC側にWi-Fi通信を可能にする機器を買えば済む話ではありますけども。(そんなに高くはないでしょうし。)

あと、モバイルルータに挿しているSIMで契約しているのは月間1GBのコースなのですけども、過去に使わなかった通信量が無期限に繰り越せる契約なので、だいたい25GB分くらいの通信権利が残っているのですよね。(だから、安心して月間1GBのコースを契約していられるわけです。)
解約するとその権利を丸々失ってしまうのもちょっともったいない気がしています。(無期限に繰り越せるという、なかなか太っ腹に思えるサービスを提供できている理由が、まさにその私が感じている「解約したら貯まっている全権利を失う(のでもったいなくて解約する気になりにくい)」という点なのでしょうけども。^^;;;)
貯まっている通信容量をサンクコスト的に考えて解約してしまえば、月990円が浮くのでその方が望ましい気もするのですけども……?

ただ、モバイルルータの月額990円をそのまま維持して、スマートフォンの方をmineoが新しく新設するという「月額250円、ただし通信速度32kbps」回線に切り替えて、スマートフォンもネットにはWi-Fiで(自宅の回線経由かまたはモバイルルータ経由で)接続することにする手もありますが。(スマートフォンをメインに使っている人々だとそんな通信方法は面倒なだけでしょうけども、私の場合は今所有している各種モバイル端末の通信方法がそれなので、スマートフォンもそれと同じようにしてもさほど不便は感じなさそうな気がしています。)

まあ、その辺は、実際にスマートフォンのテザリングで全モバイル機器を1日ネット接続してみたときに、どれくらいスマートフォン側のバッテリが消費されるのかも確認してみてからでしょうかね。
まだ試していません。面倒くさくて。_(┐「ε:)_
従来の「ガラケー月額934円」が「LINEMOの月額990円」に変化しただけなので、急いでどうにかしようという気が起きないことも要因の1つです。^^;

SMSでの認証が楽

最近は、携帯電話へSMSで認証コードを送信する本人確認とか2段階認証とかを必須にしているサービスも多いですよね。ガラケーでもSMSは受け取れるので、サービスの利用自体は問題ないのですが、ガラケーに届いたデータをPC等に入力するには、自分で見て覚えて手で入力するしかありません。まあ、せいぜい多くても5~6桁の数字であることがほとんどなので問題はありませんでしたけども。

Googleは、「PC版メッセージ」というサービスで、スマートフォンに届いたSMSをPCから確認できるサービスを用意していると知りました。このサービスを使うと、スマートフォン側にSMSで届いたテキストをPC上でコピーできる点がちょっと便利ですね。
いや、微々たる差ではありますけども。(^_^;)

この機能を使えば、PCからSMSを送信することもできます。
実際には、PC(のブラウザ)からスマートフォンにアクセスして、そのスマートフォンがSMSを送受信しているわけですが(なので、スマートフォン側でSMSの送信料金が掛かります)。操作している人間側から見れば「PC上でSMSの送受信ができている」ように見えます。
スマートフォンのキーボードよりもPCのキーボードの方が入力が早いですから、PCからSMSが送れるなら便利そうです。
ただ、SMSを送る機会もほとんどないんですが。(^_^;)

というわけで

というわけで、ガラケーからスマートフォンにようやく乗り換えたという話でした。
だいたい購入後3ヶ月間くらい使ってきましたが、特に問題なく便利に使えています。(この間、電話として音声通話に使ったのはたぶん3回くらいだけです。^^;)

2023年02月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28        

他の月

--- 当サイト内を検索 ---