瀕死のルンバが大復活！互換バッテリーに交換してみた
「最近、うちのルンバが掃除の途中で力尽きてホームに戻れなくなる…」
「充電器にずっと置いているのに、動かしたら数分で止まってしまう…」
せっかく家事を自動化してくれる頼れる相棒なのに、これではストレスが溜まってしまいますよね。
でも、諦めて買い替えるのはちょっと待ってください！
それ、本体の故障ではなく、単なる「バッテリーの寿命」かもしれません。
我が家のルンバ（620）も、最近すっかり息切れ気味で、30分もすると「充電してください…」と寂しそうな鳴き声を上げて力尽きていました。
そこで今回、Amazonで評価の高かった「Powayup 互換ルンバ バッテリー」を購入して交換してみたところ、見違えるほどの大復活を遂げました！
この記事では、実際に交換してみて分かったメリットや、現在のリアルな使用感をレビューします。
今回購入したアイテム：Powayup 互換ルンバ バッテリー
私が「これなら失敗なさそう！」と選んだリプレイス品（互換品）がこちらです。
| 商品名 | Powayup 互換ルンバ バッテリー 14.4V |
|---|---|
| 容量 | 4500mAh（大容量で純正同等以上のパワフルな駆動時間） |
| 対応機種 | ルンバ 500・600・700・800シリーズに完全対応 |
| 価格帯 | 2,000円台（※購入時点の価格です） |
👉 Amazonで「Powayup 互換ルンバ バッテリー」の詳細を見る
実際に使ってみて分かったリアルな感想（メリット）
1. 途中で止まることなく、最後まで部屋がピカピカに！
交換前はどこかで遭難していたルンバですが、交換後は信じられないほどパワフルに、非常に快適に動作しています。
掃除後にルンバのゴミ箱を開けた時、ゴミがギッシリ詰まっていて「そうそう、昔はこんな感じでしっかり掃除してくれてた！」と嬉しくなりました（毎日ちゃんと掃除していれば、ここまでギッシリにはならないはずなんですけどね。笑）。
2. 交換作業がめちゃくちゃ簡単（実質5分で完了）
「自分でバッテリーの交換なんてできるかな…」と少し不安でしたが、驚くほど簡単でした！
サイドブラシを先に外す（ここがスムーズにやるコツ！）
裏面のネジを外してカバーを開ける
古いバッテリーを抜いて、新しいものと入れ替える
これだけです。拍子抜けするほど簡単で、交換作業自体は実質5分もかかりませんでした。
💡 裏話：思わぬ大掃除タイムが始まります
交換自体はすぐ終わるのですが、カバーを開けると至る所にホコリが詰まっています。これをつまんで掃除するのが思いのほか楽しくなってしまい、気づけば小一時間、ルンバの内部を徹底的に掃除してしまいました（笑）。でも、愛着がさらに湧くのでおすすめです！
まとめ：眠っているルンバがあるなら、絶対交換がおすすめ！
「もう動かなくなったから、高い最新機種に買い替えかな…」と諦める前に、一回バッテリー交換を試してみる価値は大アリです！
わずか2,000円台の投資で、また毎日健気に床をピカピカにしてくれる優秀な相棒が戻ってきますよ。
おうちのルンバが対応しているか、ぜひチェックしてみてくださいね！
👇 今回ご紹介したコスパ最強バッテリーはこちら
WSL2 + VS Code環境でGitパスワードが「どこにもない」のに認証が通る理由
WSL2 + VS Code環境でGitパスワードが「どこにもない」のに認証が通る理由
WSL2上のターミナルでGitを使っている際、git config --global credential.helper を確認しても空欄。それなのに、git push をしてもパスワードを一度も聞かれない……。そんな不思議な現象に遭遇したことはありませんか？
今回は、その「隠れた認証情報」の正体について解説します。
結論：犯人はVS Codeの「Terminal Authentication」
結論から言うと、Gitの設定ファイル（.gitconfig）に保存されているのではなく、VS Codeが認証を完全に肩代わりし、Windows側の「資格情報マネージャー」に保存しています。
認証が通る仕組みの3ステップ
なぜGitの設定が空っぽでも動くのか、その裏側は以下のようになっています。
- VS Codeの設定: 拡張機能のGit設定にある
Git: Terminal Authenticationが有効になっている（デフォルトでオン）。 - 認証の横取り: WSL2の統合ターミナルで
gitコマンドを打つと、VS Codeが「認証ハンドラー」として割り込み、自分の持っている鍵をGitに貸し出す。 - Windowsへの保存: VS Codeが使用する実際のパスワード（トークン）は、WSL2内ではなく、ホストOSであるWindowsの「資格情報マネージャー」にセキュアに保管されている。
保存場所を確認する方法
もしパスワード（トークン）を削除したり、中身を確認したい場合は、LinuxコマンドではなくWindows側を操作します。
1. VS Codeの設定を確認
VS Codeの設定画面で git.terminalAuthentication を検索します。ここにチェックが入っている限り、Gitの credential.helper 設定は無視（または上書き）されます。
2. Windowsの資格情報マネージャーを確認
Windowsのスタートメニューから「資格情報マネージャー」を起動し、「Windows 資格情報」タブを開きます。
- ターゲット名:
vscodevscode.github-authentication/github.auth - ユーザー名:
github.auth
ここに「パスワード」として保存されているのが、GitHub等と通信するための実際の認証情報（Personal Access Tokenなど）です。
この構成のメリット
- セキュア: WSL2内のプレーンテキストファイルにパスワードを保存（
store）しなくて済む。 - 利便性: Windows側で一度GitHubにサインインしてしまえば、複数のWSLディストリビューションで共通して認証が通る。
- 管理が楽: パスワードの有効期限が切れても、VS Codeのポップアップから再ログインするだけで更新が完了する。
まとめ
git config を叩いても保存先が出てこないのは、Gitの設定レイヤーではなく、エディタ（VS Code）とOS（Windows）の連携レイヤーで認証が完結しているからです。
もし「別のリポジトリで別のパスワードを使いたい」といった理由でこの挙動を止めたい場合は、VS Codeの Terminal Authentication をオフにすることで、標準の git config による管理に戻すことができます。
【追記】WSL2 での構成
もし「VSCode の認証（GitHub へのサインインを促す UI）」をメインで使い続けたいのであれば、Windows の .exe を helper に入れるのではなく、Ubuntu 側の store または cache を使うのが安全な回避策です。
案A：Ubuntu 内でパスワードを保存する（確実）
VSCode で一度認証した情報を、Ubuntu 側のファイルに保存させます。
git config --global credential.helper store
- メリット: VSCode の Terminal Authentication が介入しやすく、一度成功すれば二度と聞かれません。
- デメリット: パスワード（トークン）が
~/.git-credentialsに平文（テキスト）で保存されます。自分専用の PC ならこれでも十分です。
案B：WSL2 向けの特別な設定（Microsoft 推奨）
もし Windows 側の git-credential-manager.exe を使う設定にしても、以下の設定を組み合わせると VSCode との相性が良くなります。
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe" git config --global credential.useHttpPath true
結論：どうすべきか？
「VSCode のあの認証画面が好きだし、余計な挙動をしてほしくない」という場合は、**案A の store** を試してみてください。
git config --global credential.helper storeを実行。git pullする。- VSCode の認証が走る（あるいはターミナルでユーザー名/パスワードを打つ）。
- 完了！ 次回からは聞かれません。
「平文保存はちょっと……」 と思われる場合は、まずは cache で試してみるのが一番低リスクです。
# 1時間（3600秒）だけ記憶する git config --global credential.helper "cache --timeout=3600"
Ubuntu on WSL2で再起動後にでるCan't create the symlink for multishells at "/run/user/{userID}/エラーについて
■現象
Ubuntu on WSL2で再起動後にbashを開くと以下のエラーが出る。
error: Can't create the symlink for multishells at "/run/user/1000/fnm_multishells/xxxx_xxxxxx". Maybe there are some issues with permissions for the directory? No such file or directory (os error 2)
原因
systemd は、ユーザーがログインしている間だけ /run/user/UID ディレクトリを維持し、ログアウトすると（正確にはそのユーザーのセッションが全てなくなると）自動的にクリーンアップする仕様になっています。
WSLの環境では、ターミナルウィンドウを開いたり閉じたりする際の「セッション管理」が通常のLinuxと少し異なる場合があり、セッションがすぐに終了したと誤認され、ディレクトリが消されてしまうことがあります。
解決策：「Linger」を有効にする
この問題を解決するために、systemd には Linger（リンガー） という仕組みがあります。
Lingerを有効にすると、「このユーザーはログアウトしてもセッションを維持し続けてください」とsystemdに伝えることができます。これにより、WSLをシャットダウンするまで /run/user/1000 ディレクトリが削除されなくなります。
設定コマンド 以下のコマンドをUbuntuのターミナルで実行してください。
sudo loginctl enable-linger $(whoami)
【参照】
RTX830でDHCP内の特定マシンに固定IPを付与する
【結論】
dhcp scope bind 1 192.168.xxx.xxx ethernet xx:xx:xx:xx:xx:xx
【メモ】
ラズベリーパイで自宅内サーバを作っていた。 「ip a 」コマンドで調べてわかったmacアドレスに対して、YAMAHA RTX830で固定IPを付与したかったがGUIではできなさそう。 調べたところ、dhcp scope bindで特定のmacアドレスと関連付けられそうだったが、そのままではだめだった。client-idが来るとそっちを見てしまうらしい。 明示的にtypeにethernetを指定してやると行けた。
設定値 説明 type が ethernet の場合 MAC アドレス type が text の場合 文字列 type が省略された場合 2 桁十六進数の列で先頭は type フィールド
【参考】
Surface Pro(第5世代)にWindows11をインストール(USBメモリ使用)
【参考記事】 note.com
【上記の記事と異なる内容】
isoイメージからのインストールだと失敗してしまった。また参考記事の事例と異なり対象のマシンはタイプカバーがついており、USBポートが使えたため、USBメモリからクリーンインストールする流れで進めたところ、無事Windows11にすることができた。
【作業メモ】
1. Windows11 ISOファイルのダウンロード
https://www.microsoft.com/ja-jp/software-download/windows11
上記の「Windows 11 のインストール メディアを作成する」よりダウンロードして メディア作成ツールを実行。 用意したUSBメモリを対象としてインストールメディアを作成する
2. レジストリの編集
TPM 2.0やCPUのチェックをスキップするため、コマンドプロンプト(管理者)で以下のコマンドを実行します。 (see. https://ascii.jp/elem/000/004/072/4072115/)
reg add HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup /v AllowUpgradesWithUnsupportedTPMOrCPU /t REG_DWORD /d 1 /f
3.「デバイス暗号化」の解除、無効化
Windows10の検索窓でbitlockerを検索し、c:\ドライブの暗号化を無効化します
4. Windows11 インストールメディアの実行
Surfaceをシャットダウンし、インストールメディアが展開されているUSBメモリをさして[音量小]を長押ししながら電源ボタンを押すと、USBメモリから起動されます。 後はインストーラの実行に任せます。
5.ネットワーク接続の回避
初期設定画面でWiFiに接続できなかったため（後続の作業でドライバを入れなおしたら使えるようになったのでドライバ問題？）先に進まず。 以下を参考に[Ctrl]+[Fn]+[F10]でコマンドプロンプトを表示して
OOBE\BYPASSNRO
を実行後、
shutdown /r /t 0
で再起動。これでネットワーク選択画面で[インターネットに接続していません]を選択できるようになった。 www.pasoble.jp
6.ドライバの適用
WIndows11のクリーンインストールは完了したが、ネットワーク(WiFi)に接続できない。 別マシンで以下よりダウンロードしたドライバ群をUSBメモリ経由などで適用。無事WiFiも接続できるようになった。 www.microsoft.com
Windows11でDocker Desktopが無料利用できなくなったので回避する（いまさら
有料サブスクリプションの件
https://www.docker.com/ja-jp/pricing/faq/
曰く
Docker Desktopを使用するには、従業員が250名を超える組織、または年間収益が1,000万ドルを超える組織の場合、利用規約に従ってユーザーごとの有料サブスクリプションが必要です。
回避策
https://qiita.com/ain1084/items/6cb6d82852c91416ec0e
やったこと
1)WSLのUbuntu上でDockerサービスを動かす
【前提】WSLでUbuntu22が動いている（上記手順にはWSLでUbuntu動かすところまで入ってるのでそのままやればよい） ※Ubuntu20ではうまくいきませんでした。Ubuntu22を新規インストールの上実施ください
# WSLでUbuntuで以下を実施 sudo apt-get update # Docker Engine のインストール curl -fsSL https://test.docker.com -o test-docker.sh sudo sh test-docker.sh # ユーザをdockerグループに追加する(root 以外のユーザーから docker を使用できる様にする) sudo usermod -aG docker $USER # WSL の再起動(PowerShellから) wsl --shutdown # 再度接続して確認 docker images > REPOSITORY TAG IMAGE ID CREATED SIZE
※自動起動しない場合は以下を参照 https://qiita.com/junkor-1011/items/60f92800e9a80e3f70da
2)ためしにDev Containerを動かす
ためしに単純なUbuntu22コンテナを動かす VS Codeを開く Ctrl + Pでコマンドパレットを開く
Dev Containers Open Folder in Containerを選択しプロジェクトを作りたいフォルダを選択 作りたい環境を選択してGo
GitHubで特定のプルリクエストがマージされた時の内容と、最新のプルリクエストの内容を比較する方法
GitHubで特定のプルリクエストがマージされた時の内容と、最新のプルリクエストの内容を比較する方法について説明します。
1. 特定のプルリクエストがマージされた時の内容を特定する
特定のプルリクエスト（PR）がマージされたときの内容は、そのPRのマージコミットまたはそのPRの最後のコミットで確認できます。
マージコミットの特定方法
GitHub UIで特定のPRを開く：
- 対象のリポジトリの「Pull requests」タブをクリックします。
- 特定のPRを見つけて開きます。
マージコミットを確認する：
- PRページの下部に「Merged」と表示され、その横にマージコミットのSHAが表示されます。このSHAをコピーします。
GitHubのコマンドラインで比較する方法
- リポジトリをクローン：
bash git clone https://github.com/username/repository.git cd repository
- マージコミットをチェックアウト：
bash git checkout <マージコミットのSHA>
- 最新のPRのブランチをフェッチ：
bash git fetch origin <最新のPRのブランチ>:latest-pr-branch
- 差分を表示：
git diff HEAD latest-pr-branch
これにより、特定のプルリクエストがマージされた時の内容と最新のプルリクエストの間の差分が表示されます。
■マージコミットの内容表示
git show <マージコミットのSHA>
