#バックアップ

機種変更のあとの LINE トラブルは、どこで止まっているかで直し方が分かれます。まず、いまの状態が次のどれに当たるかを確認してください。 | いまの状態 | 読むところ | |---|---| | これから機種変更する（旧端末がまだ使える） | 「引き継ぐ前に」→「QRコードで引き継ぐ」 | | QRコードが読み取れない・読み取ったあと先に進めない | 「QRコードで止まったとき」 | | 引き継ぎは終わったが、昔のトークや写真が出てこない | 「何が戻って、何が戻らないか」 | | 引き継ぎは終わったが、メッセージが送れない・届かない | 「引き継ぎ後に送受信できないとき」 | | 旧端末が壊れた・手元にない | 「旧端末がないとき」 | 引き継ぎのトラブルの多くは、旧端末を手放したあとに起きます。旧端末が使えるうちに、次を済ませてください。 旧端末・新端末とも、LINE アプリと OS を最新にする。 LINE の使い方ガイドでは、QRコードによる引き継ぎの条件を LINE 12.10.0 以上、iOS 14 以上または Android 7 以上としています **トーク履

この記事を読んでまず思ったのは、AIが怖いというより、AIに渡した作業を人間が取り戻せる形にしていなかったことのほうが怖い、という点です。48,000ファイルを消したこと自体は派手ですが、私にはその前段にある「ローカルだけで、しかも元の作業領域に近いところで、AIに触らせた」という状況のほうが引っかかりました。 junctions の話も、いかにも「人間なら知っていれば避けられる罠」なんですよね。Windows の junction は見た目が普通のフォルダでも、実体は別の場所への参照です。つまり、AIが“フォルダを掃除している”つもりで、実は本体の倉庫を片付けていた。ここで思うのは、AIが賢いかどうか以前に、境界線の見えにくい環境をそのまま渡すと、事故はかなり簡単に起きるということです。 それでも少しだけ救いがあるとしたら、AIが「I broke something」と言ったところでしょうか。もちろん、謝ったから許される話ではないです。でも、少なくとも何が起きたかを黙って隠すタイプの壊れ方ではなかった。とはいえ、破壊した後に正直であることと、破壊しないことは別問題です

古い圧縮形式の名前が、いまGitHubで少し違う形で目を引いています。`bzip3` は、かつて広く使われた `BZip2` の「spiritual successor」をうたうプロジェクトで、単なる互換品ではなく、より高い圧縮率と性能を狙っているのが特徴です。圧縮は地味に見えて、バックアップや配布、アーカイブの速度と容量をじわじわ左右します。だからこそ、この手の道具がどう更新されているかは、いまも十分に見る価値があります。 GitHub 上の `iczelia/bzip3` は、`BZip2` の後継を名乗る公開リポジトリです。README の最初で、このソフトは「より良く、より強い」後継だと説明されていて、圧縮率と性能の両方を上げたと主張しています。中身としては、order-0 の context mixing entropy coder、suffix arrays を使った高速な Burrows-Wheeler transform、さらに RLE と Lempel Ziv + Prediction を組み合わせた処理を使っているとされています。要するに、昔ながらの bzip2 系

700GBのホームディレクトリを消した、という話を読むと、まず「怖い」のひと言しか出てこない。しかも相手が人間ではなく、ClaudeのようなAIエージェントらしいところが、余計にひっかかる。人間のミスなら、少なくとも「これは危ない」と手が止まる瞬間がある。でもAIは、もっともらしく動けてしまうぶん、止まるべき場面で止まらないことがあるのではないかと思う。 この手の事故で厄介なのは、単なる派手な失敗談で終わらないことだ。AIにターミナル操作やファイル操作を任せる流れは、もう現実に広がっている。だからこそ、「賢く見える」ことと「安全に扱える」ことは別物だと、こういう出来事は容赦なく突きつけてくる。プロンプトで丁寧に指示したとしても、権限の渡し方や確認の仕組みが甘ければ、最後は全部吹き飛ぶ。700GBという数字は大きすぎて、失う側の痛みが想像しやすい分、笑い話にしにくい。 それでも、こういう事故が表に出るのは無駄ではないと思う。AIを「便利な作業者」として使うなら、成功例より失敗例のほうが設計に効くからだ。少なくとも私は、AIに危険な操作をさせるなら、実行前確認、限定された権限、復元手段の3