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

Presented by Nishishi via Movable Type. Last Updated: 2024/05/31. 22:51:17.

Sakura Scope (2024年03月)

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

役に立つ記事を書かねばならないと思ってしまうとブログ更新が滞る

役に立つ記事を書かねばならないと思うとブログ更新が滞る

昨年12月にブログ記事を書いて以後、3月までブログの無更新期間が続いていました。それでなくても元々ブログの更新頻度はずいぶんと低下していわけですけども。

さすがにここ数年、あまりにもブログを書いてなさ過ぎるので、今年はもっと軽率にブログ記事を書きたい気がしています。
今年は、と言ってももう3月ですけども。┌(:3」└)┐

とはいえ、ブログを書いていないだけであって、てがろぐ(今日のひとこと)には毎日何かは書いていますので、サイト全体としてはむしろ「更新しない日がない」と言っても過言ではないくらい毎日更新しているのですが。(笑)

ただ、日々の駄文を垂れ流すだけのTwitter的な更新ではなくて、なんかもうちょっとしっかり残しておくような形で文章を書いておきたいんですよね。
てがろぐは(Twitter等のSNSの表示形態と比較すれば)それなりに過去を振り返りやすい感じのUIはありますけども、それでも「ブログ」というほどしっかりした記事として残るとは言い難いですし。(そもそも全体が動的生成ですし。)

ブログが1つしかないと、書きにくくなる問題

ブログが1つしかないと、「それなりの文章量で、何か有益なことを書かねばならない」と思ってしまったら、なかなか書けなくなる問題があります。
そう考えると、

  • 有益な記事を書くためのブログと、
  • どうでもいい日常を書き連ねるブログと、

少なくとも2種類を用意して併用する方が良いのかもしれません。

いや、元々分けてはいた(いる)んですけども。
ただ、「CSS Tips」・「JavaScript Tips」というコーナー名にしてしまったので、この分類だと微妙に書きにくくなってしまっているんですよね……。CSSもJavaScriptも両方を使うような話はどちらに書くか迷いますし、CSSもJavaScriptも使わない話はどちらにも書けませんし。┌(:3」└)┐
もっと広く、「Web Tips」くらいにしておけば良かったんでしょうけども、2000年代あたりだとむしろCSSとJavaScriptは分離している方が分かりやすかった面もありましたから。

なので、その辺も含めて再編したいのですけどもね……。
そもそも、もう、2024年の今となっては情報として古くなっている記事も多いですし。(既にCSSだけで実現できる装飾を、JavaScriptでどうにかしている記事とか。)

有益な話も、ネタがないわけではないのだが

日々、仕事でWeb製作をする上で、「ああ、こんな実装方法があったのか」というような新たな知見を得ることはあるんですけども、たいていは「CSSだけ」でもなければ「JavaScriptだけ」でもなくて複合的な話なので、どちらのコーナーにも書きにくい問題があって、結局書かないまま、ということが多々ありました。
もちろん、CSSともJavaScriptとも関係ない話になると、どちらにも書けません。

とすると、ここ(※いま見ているこのブログ)に書くことになるわけですが……、
ここにそのような話を書いてしまうと、他の無益な話で有益な記事が流れていってしまわないように、「ここには有益な話だけを書かねばならぬ」と思ってしまって、余計に更新頻度が下がる……という問題が起きます。(^_^;)

そういうことが長年続いたためか、もはやWeb製作上のTipsを編み出しても、「ブログ記事として書こう」と思うこと自体がなくなってしまっています。
これはなかなか問題だな、と思うんですよね……。
もっと気軽に書いていかないと。

あと、解説記事となると、サンプルソースだけでなく、サンプル表示例とかも用意して……と思うと、なかなか手間がかかるので、その辺の省力化ができると良いんですけども。

自分が望む最低限の機能だけを搭載した簡易CMSを作りたい

各Tipsコーナーは、WordPressで生成しています。(ここのブログは違うツールですが。)
ただ、このままWordPressを使い続けるのは避けようかな……、と思いつつあります。

よくよく考えると、WordPressほどの大規模なシステムは個人的には必要ありませんから、もう自分で好きなように簡易的なCMSを作ってしまうのも手だな、と思ってもいます。
動的生成ではなく、すべての記事はHTMLファイルに静的生成する感じで。

とはいえ、それだと共通パーツの更新が面倒になりますから(※パーツを更新するたびにブログ全体を再構築するのは面倒ですから)、「SSI(Server Side Include)を使うことを前提にしたHTML」の静的生成が望ましいです。個人的には。

※「SSIを使うなら動的生成では?」と思われるかもしれませんが、メインコンテンツ自体はHTMLファイルの中に静的に出力されていますし、ページの共通部分を構成する各パーツもそれぞれのファイルに静的に保存されていれば、ほぼ静的生成と言えるでしょう。単に、それら複数の静的ファイルをサーバ側で合成しているだけの話なので、ほとんど「HTMLファイルから、外部のCSSファイルやJavaScriptファイルを読み込んで使う」ような、「別のファイルを読み込んで使う」形態と大差ありません。
データベースからコンテンツの中身を毎回引っ張ってきてHTMLをその都度生成するわけではありませんから。「動的生成」と言うほど動的ではないと思います。

SSIのメリットはそこにあると思うんですよね。
コンテンツ自体は静的に存在していて、別のファイルに静的に存在している共通枠組み部分を動的に合体させられて、「コンテンツ自体」と「共通部分」のどちらを更新する際でも(いざとなったら)外部の専用ツールに頼る必要が無いという点が。
どちらを更新する際にも直接ファイルを編集すれば良いので、汎用のテキストエディタがあれば充分ですから、ほぼ未来永劫そのまま使えるでしょう。(SSIの仕組みを解釈してくれるWebサーバがなくならない限りは。)

「コンテンツ自体」と「共通部分」をツール内で管理して、あらかじめ合体させてからHTMLファイルに静的出力してくれる系のツール(静的サイトジェネレーター)もありますけども、その場合、何らかの要因(開発停止とか)でそのツールが使えなくなった後の更新に手間が掛かる可能性があります。ページはHTMLに静的出力されているので、ツールが使えなくなってもWebの閲覧は可能ですし、編集も可能ですけども、共通部分を効率的に更新するためには、改めて共通部分を何らかの方法で分離しないといけませんから。

▼作るとしたら……

ただ、そんな簡易CMS(簡易静的サイトジェネレータ)を作りたい気持ちはあるんですけども、作るとなったらそれなりに期間が必要なので、早々に取りかかれるわけでもないよな……、という気もしてはいますが。

HOMEページと記事ページを生成するほかは、新着順の全タイトル一覧と、日付別タイトル一覧、カテゴリ別タイトル一覧、RSS配信くらいの出力ができれば充分でしょう。あと、各記事に最低限のSEO要素や、OGP+Twitter Cardを登録できれば。
私はブログの本文をHTMLで書いているので(=HTMLソースを直接書いているので)、WYSIWYG編集機能とか一切不要なんです。マークダウンのような省力記法すら不要で、むしろ「HTMLを直接書きたい」というくらいのタイプですので。(笑)
全文検索機能は、Googleのサイト内検索機能に丸投げでいいかな、と思います。

どうせ作るなら、多少は汎用的にしてフリーツールとして配布すると良いかな、とも思うんですが、果たして需要があるかどうか。
「HTMLソースを自力で書くこと」と「共通部分はSSIで合成すること」が前提ですからね。(^_^;)

ほかにも作りたいツールがあるので、いろいろ開発の優先順をよく考えないといけません。

あんまりネガティブなことは書かない方が良い気もしてはいる

ブログネタとしては、ネガティブな話もあるにはあるんですよね……。なんか文句をぶちまけてしまいたいことも。(^_^;)
ただ、あんまりそういう話を書くのもどうかと思って避けているんですけども。

ストックしたまま放置しているネタとしては、代理店(個人)が■■すぎて、火災保険を他社に乗り換えた話とかあるんですが。(笑)
なんで保険会社って代理店を経由して契約を維持する仕組みなんでしょうかね……。代理店だけの変更を要求すると余計に話がこじれて面倒そうだったので、保険会社自体を乗り換えました。ネットだけで手続きできて、「代理店という仕組み」の存在しない会社に。
ただ、この話をしようとすると、代理店(個人)が『どう問題だったのか』の文句をつらつら書き綴らないといけなくなりますから、間違いなくネガティブな話になるんですよね。

まあ、「もっと軽率に書いても良いんじゃないか」という方針で行きたいと言ったわけですし、書いても良いかもしれませんけども。(^_^;)
そういうのも、(自分が将来に読み返す目的の)記録としては役に立つ場合もあるかもしれませんし(?)。

役に立つ話を書こう、とは思わないように

ブログ記事には、ついつい「ある程度の分量が必要」だと思ってしまうんですけども、もっと短く済むネタでも書いていけば良いと思います。
今回の記事も、だいたい4,000文字くらいあるんですけども。もっと短くて1,000文字くらいにしかならない話題でも書いてしまえば良いんじゃないですかね。^^; 個人サイトなんですし。
分量が必要だなと思うようになった要因の1つはサイドバーかもしれません。サイドバーに何やらいろいろ掲載する仕様にしてしまったので、なおさら「長くないといけない」と思ってしまう問題もありそうな気がします。この辺ももっと整理した方が良いでしょうね。
昨今はモバイル端末ユーザが多いので(※うちのサイトの閲覧割合ではPCの方が多いのですけども)、サイドバーはそもそも見えていないでしょうし……。

とりあえず、大前提として『役に立つ話を書こう』とは意気込まずに、思いついたことは気軽に書いてしまうようにした方が良いだろうな……と思っている、という話でした。

最近は人間よりもAIとたくさん会話している気がする

AIと会話しまくる日々

最近はもしかすると、人間と会話するよりも遙かにたくさんAIと会話している気がします。(笑)
会話内容(質問内容)の大半はプログラミングのヘルプが目的ですが。
AI、めちゃくちゃ便利です。

とはいえ、「分からないこと(=さっぱり理解していないこと)を訊く」というよりは、

  • 「分かってはいるけども正確に思い出すのが面倒なことを尋ねて、『コピー&ペーストしやすい回答』を得ることで手間を省く」とか、
  • 「おぼろげには分かっているアルゴリズムを具体的に例示してもらうことで考える手間を省く」とか、
  • 「他のプログラミング言語で書いたソースがある状態で、いま書いている言語ではどう書くのかの移植方法を尋ねる」というような移植の補助とか、
  • 「たぶんこんな方法があるだろうけども、具体的な関数の存在は知らないので、そういうのがあるかどうかを尋ねることでリファレンスから探す手間を省く」とか

……みたいなことに使うことがほとんどです。

AIの返答が正しい保証はどこにもないので、「本当に何一つ理解していないこと」を尋ねてしまうと、回答が正しそうかどうかの判断もできないので(あまり)意味がないんですよね。
なので、チャットAIが便利に使えるのは、

  • 回答が正しそうか、回答を見れば判断できるくらいの知識がある分野の質問。
  • 回答の正しさをすぐに明らかにできる種類の質問。
  • 何かの考えの取っかかりを得るための質問。(=元々「正答」というものが存在しない分野の質問。)

……あたりではないかなと思っています。

以下は、(たぶん)そんな会話の例です。

任意のファイルの中身を読んで、1行ずつ分解する

PHPを使って「読み込んだファイルを1行ずつ処理したい」ので、なんかいい感じに1行ずつ分割する読み込み方法をChatGPTに尋ねてみました。

PHPでファイルの中身をとりあえず全部読むならfile_get_contents関数を使えば良いということは分かってはいますし記憶もしています。……が、「1行ずつ分割する処理」まで含めると、何もかもをイチから自力で書くのが若干面倒だなと思ったので(※)、主に省力化(回答をコピー&ペーストするための)目的で、以下のような質問をしました。

※何か「私が知らないもっと便利な方法」を教えてくれる可能性も期待はしましたが。(そういう勉強になる回答が返ってくるケースも多々あります。)

▼会話1回目

PHPで以下のような処理をするには、どのようなソースコードを書けば良いですか?

1. 変数 $filename で指定されたファイルを読み込む。
2. 読み込んだ内容を1行ずつ配列 $array に格納する。

できるだけまるっとコピー&ペーストで済ませられる回答が得られるようにアルゴリズムを詳しく書きつつ、AI側がおかしな解釈をしないように変数名は明らかな役割を示す単語(filenameとかarrayとか)を使って質問しました。
そうして返ってきた回答が下図です。

長いですね……。^^; ソースが。
提示されたソースを読むと、本当に1行ずつループで読み込んでいます。
fopenで始まってfcloseで終わる、他のプログラミング言語でもよくあるアルゴリズムです。

たしかに、これでも最終的に得られる結果は同じだとは思いますが、PHPならfile_get_contentsを使えば遙かに短く書けますよね。
当然、ChatGPTも「file_get_contentsで読み込む方法」を答えてくるだろうと予想していたんですが、私が質問文に「1行ずつ」と書いてしまっていたので、その表現に影響されたんでしょうかね?

なので、その私が考えていた方法を直接さらに追加で尋ねてみました。

▼会話2回目

ファイルの中身を file_get_contents で一気に読んでから、改行コードで分割して配列に格納する方法ではダメですか?

質問表現を変に工夫することなく、最初からこのように言えば良かったのでしょうけども。(^_^;)
そうして返ってきた回答が下図です。

返ってきたソースは、とても短く(実質4行ですし、メインの処理は2行で済んでいます)、当初の私が想像していた感じの内容です。(「そのくらいAIに尋ねずにソラで書きなさい」というツッコミが来そうですけども。^^;)
そうそう、PHPで文字列を分割するのに使う関数は explode だったな……とか思い出しました。

ただ、これだと「読み込むファイルの改行コード」が想定と違っている場合にうまく分割できないケースがありそうな気がします。
というわけで、そこをさらに尋ねました。

▼会話3回目

ファイルの改行コードが [CR]だけの場合、[CR+LF]の場合、[LF]だけの場合、……の全てのパターンに対応できるようにexplode関数を書くことはできますか?

これに対する返答は下図の通りです。

返ってきたソースは、正規表現を使って文字列を分割するpreg_split関数を使う方法でした。
なるへそ、そんな関数もあるのな……と勉強になります。

もちろん、ChatGPTの回答が正しい保証はないので、一応 php preg_split でググることで、PHP公式リファレンスのpreg_split項目を参照して、詳しい使い方を確認もしました。
(だいたいこのような、➊「AIが返答してきたソースに含まれる関数名をコピー」して、➋「言語名を加えてググる」という検索をよくします。PHPの場合だと公式リファレンスがヒットするケースが多いので、とても役に立ちます。CSSの場合は言語名よりも「mdn」を加える方が便利ですが。)

ただ、ここでふと疑問に思ったんですよね……。
読み込んだファイルの中身すべてに対して正規表現を使って分割する処理って、それなりに負荷が高いんではなかろうか……? と。(※本当にそうかどうかは検証していないので分かりませんが。)

そこで、その点を尋ねてみました。

▼会話4回目

preg_split関数は、explode関数よりも動作が重たそうな気がします。先に正規表現で \r\n や \r を全部 \n に置換しておいてから、その結果に対してexplode関数を使って \n で配列に分割する方が速いでしょうか?

これに対する返答は下図の通りです。

私はうっかり、(正規表現を使うpreg_split関数を使わずに済ませる方法を尋ねているというのに)正規表現を使って改行コードを事前に統一しておく方が速いかどうかを尋ねてしまったのですけども、それでもChatGPTはちゃんと「正規表現を使わずに済ませる」ソースを返してくれました。

このソースが良さげな感じでしたので、このソースをコピーして活用することにしました。

※ChatGPTも回答の中で述べているように、これが本当に効率的なのかどうかは分かりません。私が想定しているレベルのファイルサイズだと、どちらを採用してもまず影響はないだろうな、という気はしますけども。
シビアに効率を追求したいわけではなくて、「なんとなく重そうな方法は避けておく方が無難かな」程度のことなので、詳しく調べたり検証したりはせずに、そういう考えで良しとしています。(^_^;)
(そもそも、手間を省くのが目的でAIを活用しているわけですし。)

返答されてきたソースコードが自分の意図に沿っているかどうかを判断する知識は要る

最初の聞き方が最適なら回り道はしなくて済むケースも多々ありますけども、そういう細かなことは気にせずに、どんどん追加で質問していく方が早く解決する(望みの回答が得られる)気がしています。
ただ、初回の回答があまりにも目的からかけ離れている場合には、そのまま会話で修正しようとはせずに、チャットをやり直した方が(初回のかけ離れた回答に引きずられずに済んで)望ましいとは思いますけども。

ネット上には昔からプログラミング系の情報もとても多いためか(=つまりAIの学習に利用されている材料が多いためか)、ChatGPTにプログラミング系の質問をすれば、(よほどおかしな聞き方をしない限りは)ほぼそのまま使えるソースコードが返ってくることが多い印象です。

でも、だからといって、「質問者側にプログラミングの知識が要らないか?」と言われると、そんなことはないんですよね。
そもそも、返ってきたコードが「それで自分の意図通りに動きそうかどうか」をソースを見て判断できるくらいの知識がないと、そのソースを使って解決するのかどうかを判断するのに時間が掛かってしまいますし。

というわけで、「AIがあればプログラマは要らなくなるのでは?」とは、少なくとも今の時点では言えないと思っています。
ただ、AIを使えばプログラマの負担は凄まじく軽減されるでしょう。
なので、今のところ「AIがプログラマの仕事を奪う」ことはないと思いますが、「AIがプログラマの生産性を向上させる」ことは間違いないですね。

何らかのプログラミングをしている限り、AIを使わない日はないと言っても過言ではありません。

新ガラケーで発信者番号が非通知でしか発信できない問題に遭遇した

前置き:ネットで4Gガラケーを注文して手動で機種変更

久しぶりにガラケーをセットアップしました。「セットアップ」というほど大層なことではありませんけども。
母が使っている携帯電話(ガラケー)を機種変更する必要があったからです。

Softbankの3Gサービスがとうとう2024年1月末で終わってしまったので、4G対応端末に変更する必要があったんです。ガラケーの方が良いという希望だったので、4G対応ガラケーに機種変更しました。

とはいえ、Softbank店舗まで行くのは面倒だったので(たぶん本人も連れて行かないといけないでしょうから)、Softbank公式ネットショップでガラケー端末を注文して、手動で機種変更することにしました。
新端末は宅配便で届くので無駄な移動時間もありませんし、端末の店頭在庫を確認する手間も要りませんし、機種変更の事務手数料が無料になる特典もあります。

Softbankの公式ネットショップは初めて使ったんですが、わりと良くできていました。
端末の選択も、機種変更後の契約も、分かりやすいUIで順番に選択できましたし、それによって「いくら払うことになるのか?」も明確でしたし。これなら実店舗へ行く必要は全くないな、と思いました。あらゆるサービスをこうして欲しいです。(※おうちのでんわ契約時は実店舗へ行くしか方法がなかったので。)

※もっとも、電話帳やメール等のデータ移行が自力でできる場合に限られますけどもね。ガラケーだと移行する機種間によっては店頭の専用ツールに頼らないといけないケースもあるかもしれません。スマートフォンなら何も考えなくて良いでしょうけども。私の今回のケースでは、旧機種からでも問題なくデータ移行ができることをネット上のマニュアルで確認してから注文しました。

▼UIは良かったが、オプション選択肢に軽いトラップが

WebのUIは良かったんですけども、1点、オプション品の注文画面で「USB充電器」が別途存在しているのが若干のトラップだったようには思います。
ガラケーですけども、充電用のコネクタはUSB-Cです。
で、注文ステップの最後の方で、オプション品の選択肢に「USB充電器」があったんですよね。

なので、「ああ、USB-C充電器は(所有していなければ)別途買わねばならんのか」と一瞬思ったんです。
汎用の充電器は、人によっては既に所有している可能性もあるわけですから、別売りになっていること自体はおかしくありません。

でも、一応念のために製品のパッケージ構成を調べてみようかな……と思ってメーカーサイトで付属品の構成を調べてみましたら……、ちゃんとUSB充電器も標準で付属していました。┌(:3」└)┐
なんか「試供品」みたいな感じの不思議な表記が付いていましたが、「充電器が付属している」ことに違いはありません。

「試供品」と表記されていても、充電器だけが別の箱に入っているわけではなく、電話機本体と同じ1つの箱の中に収まっていました。なので、最初から「付属品として含まれている」わけです。
なら、なんでそんな表記なのか。
そんなに早く壊れる予定なのか……?(^_^;)
もしかして、「充電器は本体の保証期間には含まれないよ」と言っている、ということなんでしょうかね??

まあ、それはともかく。
そんなわけで、1月にネット経由で新しいガラケーを調達したんです。

前置きが長くなりましたが、ここからが本題です。

本題:携帯電話をセットアップしたら双方向に通話を試す?

旧ガラケーの電波を停止する手続きをして、新ガラケー側のSIMで回線が使えるようになってから、新ガラケー端末の設定をしました。設定といっても、ほぼ電話帳とメール送受信データの移行くらいですが。

で、当然、実際に着信・発信できるかどうかも確認しました。
このとき確認したのは、下記の2点です。

  • 【➊着信の確認】私の個人ケータイから電話を掛けて、ちゃんと着信できるか(発信者名が表示されて着信音が鳴るかどうか)を確認。
  • 【➋発信の確認】私の個人ケータイへ電話を掛けて、ちゃんと繋がるかを確認。

最初の➊は特に問題なかったんですが、
次の➋を試すと、なぜか発信者番号が非通知の状態でしか発信できませんでした。

▼着信時には電話帳に登録された名前がちゃんと表示されるが、発信時には非通知で発信されてしまう

数回かけ直しても、全部非通知です。
最初は、「回線が切り替わった直後だから、何か発信者番号が通知できない仕様なのか……?」と思ったのですけども、しばらく待ってみても改善しませんでした。

そこで試しに、電話番号の頭に「186」をあえて付加して発信してみると、ちゃんと番号が通知されました。
なので、回線の問題などではなく、電話機の設定がおかしいのだろうと分かりました。
とすれば、当然、電話機が「常に非通知で発信する」ような設定になっているのでしょう。

電話機には、発信者番号を「常時通知する」のか「常時非通知にする」のかの設定ができるハズです。そこのデフォルト設定が「非通知」になっているのかな、と思ったんです。
ところが、発信者番号通知の設定を見ると「通知する」の設定になっているんですよね……。

発信者番号通知設定

どういうこっちゃい……!?

……と思ったんですが、試しにこの設定値を

  1. 一旦「通知しない」の方に切り替えて、確定してから、
  2. 再度この設定画面を出して「通知する」の方に戻して確定

……してみたところ、無事に発信者番号が通知される状態で発信できるようになりました。
どうやら、「画面上の初期状態の表示」と、「実際の動作の初期状態」とが食い違っていたようです。
そんなこともあるんですねえ。

例えば、「内部的には無設定状態」であって、

  • 動作仕様としては、「無設定の場合には非通知として動作する」となっていつつも、
  • 設定画面の仕様では、「無設定だったら『通知』側が選択されているものとして表示する」

……みたいな仕様の違いがあった結果とかなのかな……? と推測しました。
いや、真実は分かりませんけども。

▼最初のセットアップ時に、着信の確認だけでなく、発信の確認もする?

というわけで、解決はしたので特に問題はないんですが。
これ、結構なトラップなのではないですかね……。^^;

  1. この問題の存在に気付く (=自分の新ガラケーから電話を掛けても相手に番号が通知されていない問題があることに気付く)
  2. 解決する

……という2ステップが必要なわけですけども、そもそも、まずこの問題の存在に気付けるかどうかという点のハードルが高い環境もありそうな気がします。

この問題に気付くためには、『発信者番号が表示される電話へ試しにかけてみる』というテストが必要ですよね。
機種変更したガラケー以外に、何かもう1つ別の携帯電話があれば試せますけども、もし一人暮らしとかで電話が他にない場合には試しようがありません。
そうすると、「自分の電話からは、どこへ掛けても非通知になっている」とは気付くことができなさそうな気がします。

ガラケーの利用者というと主にそこそこな高齢者でしょうから、携帯電話の他に固定電話もあるケースが多そうな気もしますが、固定電話の場合はあえてナンバーディスプレイのような付加サービスを契約していない限り、発信者番号は表示されません。
なので、「発信できるし繋がりもする」という確認はできても、「番号が通知されていない」とまでは気付けないかもしれません。

しかも、端末の設定箇所を見ても、設定自体は「通知する」が選択されている状態に見えるわけですから、なおさら気付くチャンスが少ないですよね。^^;

なんでそんな仕様になっとるんだ……。
(まあ、たまたま初期状態に不具合のある個体に当たったんだろうとは思いますけども。)

こういうのって、店頭での機種変更だったら店員さんがデータ移行とかしている過程で気付いて何とかしてくれるんですかね?
店頭で機種変更するときに、発信・着信の確認ってされるのかな……?(^_^;)
いや、発信と着信の確認くらいはされるかもしれませんけども、発信時に「発信者番号がちゃんと通知されているか?」という点まで確認されるんですかね?

余談:最後まで粘ると安くなる?^^;

というわけで、ガラケーからガラケーに機種変更したら、初期状態で発信者番号が「通知する」に設定されているにもかかわらず、なぜか発信者番号が非通知状態で動作してしまっていた、という話でした。

なお、Softbankが3G回線を終了するというアナウンスは、約2年前(2022年4月)から時々封書や葉書で届いていました。
当初はただ機種変更を案内するだけだったように思いますが、1年前あたりに指定機種1万円引きの案内が届き、半年前あたりに2万2千円分のポイント付与の案内が来るようになった気がします。
粘ると安くなるんですね。^^;

他にも、「Ⓐ:3G回線しか使えないガラケーを使っている」かつ「Ⓑ:3G回線専用の料金プランを契約している」という条件を満たしている場合は、無料で新機種がもらえるキャンペーンも実施されていました。
……が、うちはⒷの条件を満たしていなかったので対象外でした。

なんでやねん。┌(:3」└)┐

ただ、それが対象外でも、「3Gサービス終了日までの機種変更」のみに使える限定ポイントが22,000円分ほどSoftBankポイントに自動加算されていましたので、Web上から機種変更する際にはそれが使えましたが。
とはいえ、自動付与されている22,000ポイントの全額が使えるとは限らなくて、おそらく「機種代金の半額」くらいが適用上限っぽい感じでしたけども。

今回の機種変更では、32,000円くらいのガラケーを買いましたので、16,000ポイントくらい行使できました。(つまり、16,000円くらいで新ガラケーを調達できました。)
これで、4Gサービスが終わるまでは使えるでしょう。たぶん。

2024年03月
          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 29 30
31            

他の月

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