Androidのメモとか

そふとうぇあえんじにゃーの備忘録

酔って失くしたイヤホンを買い直したら、2年分の進化に気づいた話

右耳に、何もなかった。

ポキオ Xiaomi REDMI Buds 8 Lite

大失態

前の晩は会社の人たちとの飲み会で、正直そこからの記憶がほとんどない。家までどうやって帰ったのかもうろ覚えのまま、朝になって頭の重さに顔をしかめながらポケットやかばんの中をひととおり探してみたけれど、出てこなかった。椅子に座り込んで、もう一度かばんをひっくり返してみたけれど、結果は同じだった。使っていたのはXiaomiの「Redmi Buds 6 Lite」。

[フレーム]relativelayout.hatenablog.com

もう2年近く、毎朝の通勤で当たり前のように持ち歩いていたイヤホンだった。

また同じシリーズを選んだ

なくなったものはもう出てこないので、その日のうちに後継機の「Redmi Buds 8 Lite」を注文した。

ポキオ Xiaomi REDMI Buds 8 Lite

前のモデルが安くて、それなりに良い音だったから、特に迷う理由もない。気づいたら、また同じLiteシリーズを選んでいる自分がいた。

耳に入れた瞬間

箱を開けて、最初に耳に入れた瞬間、フィット感がはっきり違うのがわかった。それよりも意外だったのは、接続完了のときの効果音やノイキャンの切り替え音。地味な部分なのに、前のモデルより音の輪郭がしっかりしている。こんなところで進化を感じるとは思わなかった。

通勤電車で

使う場面はいつも同じ、電車に座って音楽かポッドキャストを流す通勤の時間。前と同じように聴いているはずなのに、流れてきた曲の低音がはっきり違う。一曲聴いただけで、解像感が上がっているのが伝わってきた。

たぶん自分のせい

なくした原因は、たぶん自分にある。酔った帰り道、ポケットに適当に押し込んだまま歩いていた気がする。次はちゃんと確認しよう、と思った。

ポキオ Xiaomi REDMI Buds 8 Lite

次の瞬間、新しいイヤホンを、また前と同じポケットにしまった。

M4 MacBook AirにローカルLLMを入れてみたら思ったより軽快だった

ローカルLLMも面白い。

ポキオ ローカルLLM MacBook Air M4 Ollama qwen3:4b-instruct

環境構築

大手AIサービスの値上げや利用量課金化を背景に、無料で使えるローカルLLMを試すことにした。検証環境は自宅の私物MacBook Air。

  • MacBook Air 13-inch, 2025
  • Apple M4
  • 16 GB

Homebrewの導入

まずはHomebrewをインストールした。

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

.zprofileにPATHを追加し、brewコマンドを有効化した。

node.js環境の構築

nodebrewを導入し、安定版のNode.jsをインストールした。

brew install nodebrew
nodebrew setup
nodebrew install-binary stable
nodebrew use v26.3.1

llm-checkerの導入

llm-checkerをインストールし、ハードウェア診断を実行した。

npm install -g llm-checker
llm-checker hw-detect

結果は以下の通り。

  • Apple M4 (16GB Unified Memory)
  • Tier: MEDIUM LOW
  • Max model size: 9GB
  • Best backend: Apple Metal

M4でもラップトップである以上、上位ティアの判定にはならなかった。

続けてllm-checker recommend --category codingを実行。qwen3.5:4b、qwen3:4b-instructなど、4B前後のモデルが推奨として表示された。

OLLAMAの導入

Ollamaをインストールした。

brew install ollama
ollama serve

LLMモデルの導入

llm-checkerの推奨モデルの一つであるqwen3:4b-instructを導入した。

ollama pull qwen3:4b-instruct

プロンプトの結果

テストプロンプトとして「桃太郎をソフトウェアエンジニア風にしてください」を入力した。内容は、犬をDocker、猿をTailwind、カエルをSQLiteに置き換え、鬼をバグの象徴として扱う構成だった。

ollama run qwen3:4b-instruct
>>> 昔話の「桃太郎」をソフトウェアエンジニア風にしてください。
もちろん! 
「桃太郎」をソフトウェアエンジニアの視点で、現代の開発現場に合わせて「ソフトウェアエンジニア風」にリメイクしてみます。 
---
## 🍑「桃太郎」をソフトウェアエンジニア風に再構成 
### 🚀 タイトル:**「桃太郎:スケルトン・プロジェクトの完成」**
---
### 📌 ストーリーの構造(エンジニア風) 
> **背景**: 
> ある開発チームが、AIを搭載した「スマートハウス」の開発を進めていた。 
> しかし、開発環境が不十分で、**バグが多発**、**リリースが遅延**、**ユーザーの満足度が低い**という状況に陥っていた。 
> チームのリーダー(おばあちゃん)は、「このままではプロジェクトは失敗する」と警告する。
> **解決策のアイデア**: 
> おばあちゃんが「**桃**」を発見! 
> その桃は、**リソースが少ない環境でも動く、軽量なフレームワーク**(例:React + Node.js)だった。 
> 桃の中から、**3つのツール**が登場する。
---
### 🚀 3つのキャラクター(エンジニア風) 
| キャラクター | ツール | 能力 | バグ対策 |
|------------|--------|------|---------|
| **犬(ボス)** | **Docker** | コンテナ化で環境を標準化 | バージョン管理と依存関係の管理 |
| **猿(アーティスト)** | **Tailwind CSS** | フロントでUIを高速に作成 | レスポンシブデザインの自動調整 |
| **カエル(DBエンジニア)** | **SQLite** | ローカルデータベースで軽量に動作 | データの保存と読み込みの最適化 |
---
### 🛠️ プロジェクトの進展(開発サイクル) 
1. **要件分析(おばあちゃんの声)** 
 → 「ユーザーは、シンプルで使いやすいアプリを欲している」と明確にした。
2. **初期構築(桃の開封)** 
 → 桃を開けた瞬間、**Gitリポジトリが自動生成**された。 
 → メインブランチに「`main`」と`README.md`が作成された。
3. **開発フェーズ(3人のツール)** 
 - 犬(Docker):開発環境を**コンテナ化**し、開発者がどこにいても同じ環境で開発できるようにした。 
 - 猿(Tailwind):**CSSのバグを減らす**ために、UIを迅速に構築。 
 - カエル(SQLite):**ローカルデータを安全に保存**し、データの整合性を確保。
4. **テストフェーズ(鬼の出現)** 
 → ある日、**バグの王**(「鬼」)が登場! 
 → 鬼は、**バグのエラーメッセージを無視する**、**テストをスキップする**、**コードを破壊する**という行為をしていた。 
 → 3つのツールが連携し、**自動テストパイプライン**を立ち上げる。
5.**解決** 
 → バグの王(鬼)は、**テストが失敗したコードを無視する**という行動をやめ、 
 → 代わりに、**CI/CDパイプライン**が自動でバグを検知し、**コードレビュー**を強制するようになった。
---
### 🎯 最終成果(完成) 
> 🎉 **「スマートハウス」が成功!** 
> - ユーザーは、**10分でアプリを起動**できる 
> - バグは**ゼロ**(または極めて少ない) 
> - チームは、**リリース日を1週間早め**に達成 
> - ユーザーは「これは、**スムーズでシンプル**だ」と評価!
---
### 💡 モチーフの現代的な意味 
- **桃** → **軽量で実用的な技術(例:React, Vue)** 
- **犬・猿・カエル** → **開発の3つの柱(DevOps, UI, DB)** 
- **鬼** → **バグや不正なコードの象徴** 
- **解決策** → **自動化、テスト、CI/CD**(現代のソフトウェア開発の核) 
---
### 📝 まとめ(エンジニアの教え) 
> 「**環境が整っていないとき、シンプルなツールから始める**」 
> 「**バグを防ぐには、テストを常に意識する**」 
> 「**チームの協力が、コードの質を上げる**」 
👉 これは、**桃太郎**の物語が、 
**ソフトウェア開発の哲学**に、まさにぴったりな例なのです。
---
🎉 **結論**: 
> 桃太郎は、 
> 「**シンプルなスタートから、強力なチームで、問題を解決する**」 
> という、**現代のソフトウェア開発の真髄**を、 
> とても自然に伝えているのです。
---
💡 おまけ: 
> もし、このストーリーを**開発者向けのSlackチャンネルのルール**にしたら? 
> たとえば: 
> - 「犬が来た」→「Dockerを起動する」 
> - 「猿が来た」→「TailwindでUIを書く」 
> - 「カエルが来た」→「SQLiteでデータを保存」 
> - 「鬼が来た」→「CIパイプラインを実行」 
> → すべて、**自動で実行される**!
---
✅ 桃太郎、ソフトウェアエンジニアの心に、**再び生き返った**!
--- 
✨ これで、**昔話が、エンジニアの日常に溶け込んでいます**。 
次は「うさぎとキノコ」をAI風にどうにかしますか? 😄

なぜ、猿・キジ・犬ではないのかは永遠の謎だが、絵文字を入れる余裕を見せつけられた。

所感

このレベルのプロンプトであれば、レスポンスは速かった。MEDIUM LOW判定のハードウェアでも、4B程度のモデルであれば実用的な速度で動作することが確認できた。

挨拶も謝罪もしない人が羨ましくて、でも気の毒にも思っている

事実をもとにしたフィクションです。

ポキオ Kids these days effect

最近気になったこと

挨拶をしない人が、職場にいる。

朝、廊下で目が合っても、向こうは何も言わない。エレベーターで二人きりになっても、無言のまま数字が変わるのを見ている。その人の隣に立つたびに、なぜか自分のほうが居心地悪くなる。

何か失敗しても謝らない。説明を求めると答えは返ってくるが、相手に伝える気があるのかどうか、よくわからない言葉が続く。話が終わったあと、私は「つまりどういうことだったんだろう」と頭の中で整理し直すことになる。若手の社員だ。

何も言わないし、言うつもりもない

私は何も注意しない。するつもりもない。

注意したところで変わる気がしない。ただ、最近になってふと思うことがある。もしかしたら、あの人は「やり方を知らない」だけなのかもしれない、と。

コロナ禍で、大学時代の先輩・後輩の付き合いがほぼ消えた世代がいる。飲み会も、部活の合宿も、先輩に怒られる経験も、ほとんどなかった。タクシーの手配の仕方も、エレベーターで上司より先に降りてはいけないという感覚も、誰かに見せてもらう機会がなかった。そういう世代が、今、社会に出てきている。

気の毒だとは思う。思うけど、消耗するのは消耗する。

周りの人も何も言わない。「あの人ってさ......」と言いかけて、濁して終わるような会話が、たまにある。みんな同じように、少しずつ何かを引き受けながら、特に何もしていない。

「損か得か」と「身についているか」

何かで読んだのだが、今の若い世代はマナーを「損か得か」で捉える傾向があるらしい。挨拶して自分に得があるか。謝って何か変わるか。それを無意識に計算している、と。

それを知ったとき、なるほどと思った。私はマナーを損得で考えたことが、たぶんほとんどない。考える前に体が動いている。「おはようございます」と言うのに理由なんてなくて、もう体がそうなっている。

その前提が最初から違うのだとしたら、噛み合わないのは当然かもしれない。

「Kids these days effect」という言葉があるらしい。「最近の若者はダメになった」「自分の若い頃はもっとちゃんとしていた」と大人が思い込んでしまう、認知バイアスのことだ。自分の若い頃の失敗や未熟さは都合よく忘れて、今の成熟した自分と若者を比べてしまうから、そう見える——という仕組みらしい。

それを知ったとき、少し自分が恥ずかしくなった。私が「当たり前」だと思っていることも、たまたまそういう環境で育っただけの話で、あの人を見て感じるモヤモヤの一部は、このバイアスが混じっているのかもしれない。

そうわかっていても、消耗するのは消耗する。頭と体は別だ。

羨ましいけど、一緒にいたくない

正直に書くと、私はその人のことを少し羨ましいと思っている。羨ましいのと、一緒に働きたいのは別の話だ。でも、羨ましいのは本当だ。

相手の反応を気にしない。気まずい空気を感じていない。謝らなくていいと思っている。そういう鈍感さが、もし自分にもあったなら、どれだけ楽だっただろうと思う。

私は人の顔色を読みすぎるところがある。会議で「これは言ったほうがいいか」と考えているうちに話題が変わって、結局何も言えなかった、なんてことが先週もあった。夜になってもひとりで答え合わせをしている。

あの人にはたぶん、そういうことがない。朝、廊下で誰かとすれ違っても、挨拶をしなかったことを気にしながら席に戻る、なんてことはしていないはずだ。

ただ、ラベルで見ても仕方ない、とも思う。「Z世代だから」と括ってしまうと、その人個別の話が見えなくなる。反応が薄く見えるだけで、頭の中では深く考えているのかもしれない。そういえば、あの人が仕事以外で何を考えているか、私は何も知らない。名前以外、ほとんど何も。

それでも先に「おはようございます」と言う

挨拶がない職場は、じわじわと何かが摩耗していく。謝れない人と仕事をすると、ミスのたびに誰かがそっと引き受けることになる。説明が通じない会話は、終わったあとに疲労だけが残って、何も前に進んでいない。

私が羨ましいのは、あくまであの人の「鈍感さ」だけだ。気にしなくていいことを気にしない、その能力だけが羨ましい。でも今のあの人を見ていると、気にすべきことまで気にしていないように見えて、そこが違う。

羨ましくて、気の毒で、でも消耗する。その三つが全部本当なのが、自分でも少し不思議だ。

今日もこちらから先に「おはようございます」と言った。向こうは、また小さく頷いただけだった。

ああ、自分も老害になってきたんだなと感じた。

鉄ヲタとして、京急ファミリー鉄道フェスタ2026で気になったこと

ちょっと気になる。

ポキオ 京急ファミリー鉄道フェスタ2026

前回は、割とポジティブな内容を書いた

こちら。

[フレーム]relativelayout.hatenablog.com

今回は「参加できたけど、ちょっとモヤッとしたこと」を書いてみる。

帰りの電車で、隣に座っていた親子

おかえり電車の座席に腰を下ろしたとき、隣に親子が座ってきた。

しばらくして、子供が靴のまま席の上に立った。親はスマホのカメラを構えたまま、こちらには気づいていない様子だった。子供が多少騒いでも、特に声をかけることはなかった。

注意するかどうか、少し迷って、やめた。

今年から抽選制がなくなった

今年の京急ファミリー鉄道フェスタは、昨年までの事前抽選制から変わって、子連れであれば誰でも参加できる形式になった。間口が広がること自体は悪いことではない。

ただ、その分だけ人が増えた。そして、気になる場面も増えた。

長時間、動かない人たち

車両撮影エリアでは、後ろに人が並んでいても構わず場所を陣取り続ける人がいた。

子供をそっちのけで撮影に夢中になっている大人も目についた。子供は近くをうろついているだけで、親はカメラを向けたまま動かない。子供のためのイベントのはずなのに、何のために来たのかよくわからなかった。

ベビーカーをそのまま押してくる人たち

会場の入口付近にベビーカー置き場が用意されていたけれど、構わずそのまま押して歩く参加者がいた。

混雑した狭い通路でも、周りを気にせずズカズカと進んでくる。ぶつかりそうになって、避けたのはこちらだった。

会場の外でも

会場周辺の道路も混んでいた。マイカーで来る参加者が、狭い道路で乗降をしていたせいだった。近くのコンビニでも同じようなことをしていた。鉄道のイベントにマイカーで来る。その発想がよくわからないし、周辺の店舗や住民への迷惑を考えると、来年以降の開催が心配になった。

鉄ヲタとして思うこと

私も鉄ヲタだ。息子も、たぶん鉄ヲタになりつつある。

鉄道ファンへの世間の目は、正直あまり優しくない。そういう状況の中で、こういうイベントで目立つマナーの悪さは、余計に気になった。息子と並んで歩きながら、自分たちも同じように見られているのかと、少し思った。

同じ趣味の業界で言うと、釣りではDAIWAが「DAIWA YOUNG FISHING CLUB」という子ども向けクラブを運営していて、釣りの楽しさだけでなく、自然や釣り場でのマナーも一緒に教えている。鉄道業界でも、正しく鉄道を好きになってもらうための取り組みがあってもいいのではと思った。

それでも、開いてくれることには感謝しかない

京急がこういうイベントを開いてくれること自体は、ありがたい。子供が鉄道を好きになる入口として、これ以上ない機会だと思っている。

だからこそ、たとえ1000円でも入場料を設けてほしいと思った。来場者の数よりも、来場者の質が、このイベントの未来を決めると思うので。

そう思いながら、久里浜を後にした。

京急ファミリー鉄道フェスタ2026に参加してきた、去年の分も

2年ぶりの参戦。

ポキオ 京急ファミリー鉄道フェスタ 2026

去年、封書が届いた

去年の5月、強風でフェスタが中止になった翌月のことだった。

京急から封書が届いて、中には配布予定だったグッズと手紙が入っていた。子ども向けと大人向け、2通。息子に手渡したら、真面目に手紙に目を通していた。

[フレーム]relativelayout.hatenablog.com

今年こそはと思い、応募フォームが出た日に、すぐ送った。

お迎え列車の抽選に外れた

今年は抽選制がなくなり、誰でも参加できる形式に戻った。その分だけ、会場は人が多かった。

久里浜工場まで向かう「お迎え列車」は別途抽選があって、そちらは外れてしまった。貸切列車に乗って工場入りするあの体験は、また来年に持ち越しになった。

仕方なくシャトルバスに乗ることにした。バス乗り場に並んで、20分ほど待った。

ポキオ 京急ファミリー鉄道フェスタ 2026

来たのは京急バスの電気バス。最新式で、静かで、乗り心地は悪くなかった。お迎え列車への未練はあったけれど。

ただ、シャトルバスは会場直接ではなく、会場を通り過ぎた先の「吉井バス停」が終点で、そこから徒歩で戻る形だった。

ポキオ 京急ファミリー鉄道フェスタ 2026

ちょっと遠いなぁとは思ったけど、久里浜工場が見えてくると少しずつ楽しくなってきた。

会場に入ってしまえば、いつものフェスタだった

崎陽軒の京急ファミリー鉄道フェスタ記念弁当を早めに確保して、昼食にした。通常の炒飯弁当の特別版という感じで、普通に美味しかった。

ポキオ 京急ファミリー鉄道フェスタ 2026

ポキオ 京急ファミリー鉄道フェスタ 2026

クイズラリーにも参加して、参加賞のけいきゅんのぷっくりシールをゲット。参加していた娘も、これには少しテンションが上がっていた。

ポキオ 京急ファミリー鉄道フェスタ 2026

この「いつもの感じ」が好きだ。去年それができなかったから、余計にそう思った。

車両が揃いすぎていた

撮影エリアはかなりの混雑で、ゆっくり撮れる状況ではなかった。でも並んでいる車両を見て、混んでいる理由はわかった。

ポキオ 京急ファミリー鉄道フェスタ 2026

ブルースカイトレイン、イエローハッピートレイン、2100形の赤・青・黄が揃い、京成線・都営浅草線の車両も鎮座。さらに1000形1700番台まで。これだけの顔ぶれが一度に並ぶのは、なかなかない。

ポキオ 京急ファミリー鉄道フェスタ 2026

息子は端から端まで歩いて確認していた。

展示ブースで工事の話を聞いた

個人的に一番印象に残っているのが、連続立体交差事業の展示ブースだった。

泉岳寺駅から新馬場駅にかけて、京急本線を高架化する工事が進んでいる。担当の方に話を聞いていたら、北品川駅の移設の話になった。品川駅から南下するにつれて勾配がきつくなるため、北品川駅を新馬場駅側に少し動かすことになったという。それでも35パーミルという急勾配になるとのことだった。

鉄道の工事って、こういう制約の積み重ねでできているのか。毎日乗っている路線の話なのに、知らないことばかりだった。

工場の中から改札して帰った

帰りは久里浜工場から「おかえり電車」で京急久里浜駅まで。久里浜工場の構内に改札機が設置されていて、Garmin Forerunner165のGarmin Pay(Suica)で恐る恐るタッチして乗車した。

ポキオ 京急ファミリー鉄道フェスタ 2026

工場の中で電車に乗る。これだけで少し非日常だった。

ポキオ 京急ファミリー鉄道フェスタ 2026

来年も来られたらいいな、と思いながら、子どもたちと並んで久里浜を後にした。

GWはnoteを執筆するためのSkillsを作っていた

100%AIに書かせるのはまだ早い。

ポキオ Claude Skills note 執筆

連休の使い方とやったこと

ゴールデンウィークは外に出ることもほとんどなく、noteを書くための仕組みづくりに時間を使っていた。

やっていたのはClaude向けSkillsの作成で、最終的には「案だし・調査」「執筆」「評価」の3つに分ける形に落ち着いた。記事のネタを考えて、調べて、書いて、最後に見直す。この流れ自体は普段やっていることと同じだけど、それを明確に分解して、それぞれに役割を持たせた。

特に評価スキルは重要で、書きっぱなしにしないための仕組みとして入れている。一度書いた文章を客観的に見直して修正する、このサイクルを回す前提で設計した。

まだ荒削りな状態

一応動く形にはなっているけど、中身はまだ荒い。

細かい調整も足りていないし、精度もこれから上げていく段階。なので、具体的な中身やプロンプトはもう少し整ってから記事にするつもりでいる。現時点では「こういう構成で回す」という枠組みだけが固まった状態で、実際に使いながら改善していくフェーズに入ったという感覚に近い。

AIを使う理由とスタンス

そもそもこういう仕組みを作り始めた理由は、単純に文章を書くのが面倒だからだ。

文才もないし、日本語もそこまで得意ではない。頭の中にあるものをうまく言語化できずに手が止まることが多い。だからAIの力を借りることにした。

ただし、案だしから執筆まで全部を任せるつもりはない。自分で考えた内容をベースにして、AIには日本語として整える役割を担わせる。この線引きはかなり意識している。

[フレーム]relativelayout.hatenablog.com

以前、自分で書いた記事をAIに読み込ませて、その特徴を抽出し、それをもとに記事生成のプロンプトにできないか試したことがある。

いわゆる「自分の文体を再現する」方向のアプローチだったが、出来上がった記事はかなり違和感があった。今読み返すと、感情の入れ方もジョークの置き方も不自然で、全体的に気持ち悪さが残る文章だった。表面的には若干似ている(?)が、中身が伴っていない感覚が強かった。

この経験から、感情やニュアンスの扱いはAIが苦手な領域だと認識したため、そういった部分は無理に再現させず、人間側で補完する前提に切り替えている。

最近のnoteと自分の方針

最近のnoteを見ていると、最初から最後までAIで作られたような記事が増えていると感じる。

内容自体は整っているけど、体験がなく、構造も似通っていて、アフィリエイト目的だとわかるものが多い。自分もアフィリエイトはやっているが、それを主目的にすると記事の中身が薄くなると感じている。だからこそ、実体験ベースの記事を書くことは崩したくない。(と言いながら、私もここでアフィリエイトをぶち込んでおきますね。)

今回作ったSkillsも、AIが勝手に話を膨らませないようにして、あくまで自分の経験から外れないように設計している。効率は多少落ちるが、その分、自分が書いたと思える文章になる。この構成でしばらく回しながら、どこまで使えるかを見ていくつもり。

クレジットカードで京急に乗ってみた話

本当にオトクなのか?便利なのか?

ポキオ 三井住友カード タッチ決済 鉄道 バス

オトクなキャンペーン?

三井住友カードのキャンペーンを見つけた。スマホのタッチ決済で対象路線に乗ると、最大7〜8%のVポイントが還元されるというものだ。

[フレーム]www.smbc-card.com

「これは試してみるしかない」と思い、翌朝の通勤で使ってみることにした。

朝、最寄り駅に着いてから気づいた。いつもと違う改札機を探さなければいけない。クレジットカードのタッチ決済に対応している端末は、すべての改札機にあるわけではないのだ。

スマホを持ったまま、改札の列を横目に対応機を探す。朝の通勤時間帯にこれをやるのは、思ったより面倒だった。

7%還元の「実態」を少し計算してみた

横浜駅まで乗って、ポイントが付く。それ自体はうれしい。ただ、少し気になることがあった。

クレジットカードで乗車した場合、運賃はIC乗車券(PASMOなど)の割引運賃ではなく、通常の乗車券価格になる。ICと比べると数円〜十数円高くなる区間もある。7%の還元がそこに乗っかるので、単純にお得とは言いきれない部分がある。

それから、京急にはリピートポイントという仕組みがある。同じ月・同じ運賃区間をPASMOで乗り続けると、乗車回数に応じて還元率が上がる。8〜15回で3%、16〜23回で6%、24回以上になると10%だ。

[フレーム]www.keikyu-point.jp

私はテレワークと出社のハイブリッドで、週3出社くらいのペースで働いている。片道ずつカウントされるリピートポイントの仕組み上、月の乗車回数は15〜18回程度に収まることが多く、6%の段階で止まる可能性が高い。そうなると、三井住友カードの7%還元と大差ない、あるいは逆転されるラインに入ってくる。単純な損得だけで見れば、PASMOのままのほうがわずかに有利かもしれない。

それでも試す意味はあると思う

ではクレジットカード乗車は損か、というと、そうとも言いきれない。

たとえば、三井住友カードには年間利用額に応じて特典が変わる仕組みがある。いわゆる「修行」として、カードの利用実績を積みたい場面がある。そのために毎日の通勤運賃をクレジットカードに流す、という使い方は合理的だと思う。ポイント還元の損得より、年間特典の条件達成を優先するなら、交通費はいい「積み上げ先」になる。

私はひとまず、PASMOに戻すつもりでいる。週3出社の自分には、リピートポイントで6%を狙うほうが手間がなくて合っている。

ただ、一度はやってみてほしいと思う。改札でスマホをかざして乗る体験は、PASMOとは少し違う感触がある。何より、自分の通勤がどの還元ルートで最適化できるかを考えるきっかけになる。クレジットカードの修行を検討しているなら、交通費から積み上げる選択肢として頭に入れておいて損はない。

「Androidのメモとか」は、Amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、Amazonアソシエイト・プログラムの参加者です。

このブログは個人的なメモ書きであったり、考えを書く場所であります。執筆者の所属する団体や企業のコメントや意向とは無関係であります。また、このブログは必ずしも正しいことが書かれているとは限らず、誤字脱字や意図せず誤った情報を載せる場合がありえます。それが原因で読者が不利益を被ったとしても、執筆者はいかなる責任も負いません。ありがとうございます。

引用をストックしました

引用するにはまずログインしてください

引用をストックできませんでした。再度お試しください

限定公開記事のため引用できません。

AltStyle によって変換されたページ (->オリジナル) /