[{"data":1,"prerenderedAt":55},["ShallowReactive",2],{"article-0s5wahzwf4":3,"prev-article-0s5wahzwf4":27,"next-article-0s5wahzwf4":53},{"contents":4,"totalCount":25,"offset":26,"limit":25},[5],{"id":6,"createdAt":7,"updatedAt":8,"publishedAt":8,"revisedAt":8,"title":9,"content":10,"tags":11,"is_no_index":24},"0s5wahzwf4","2026-07-13T20:36:41.461Z","2026-07-13T20:40:28.103Z","知性","\u003Cp>嫌な時代になったもので、わたしが知性を感じていたもの達は、軒並みLLMによって6割くらいの完成度で再現可能になってしまいました。\u003C/p>\u003Cp>文章も、コードも、設計も、映像も。おかげさまで世の中はslopまみれです。検索結果を開けばLLM製のまとめ記事、技術記事サイトを開けばどこかで見たような解説の劣化版焼き直し。SEO汚染で瀕死だったインターネットに、とどめの一撃が入った格好です。\u003C/p>\u003Cp>この6割という数字が、また嫌らしい。2割なら誰も相手にしませんし、10割なら諦めもつく。6割は、素人目には十分に見えて、よく見ると粗が見える感じの、ちょうど厄介なラインです。そして残念なことに、世の中の大半の場面は6割で十分だったようです。残念で仕方がありません。\u003C/p>\u003Cp>極端な話、LLMの出力する任意の成果物は単なるパターンマッチに過ぎません。確率的に尤もらしいトークンを並べているだけで、そこに理解と呼べるものがあるのかは怪しいところです。\u003C/p>\u003Cp>ただ、残念なことに、わたし達が知的作業と呼んでいたモノの多くは、そこまで崇高なものではなく、パターンマッチで代替可能でした。とりあえず動くものをつくる、目の前のエラーに場当たり的なパッチを当てる。そういうある種の短絡的な思考で解決できる問題は殆どLLMで解決可能になっているように感じています。認めたくないですがね。\u003C/p>\u003Cp>正直、コーディングや設計で現行のLLMに負ける気は更々ありません。が、これも今だけでしょう。そのうち負ける気がしています。というか、Fable 5相手ですら怪しいですからね。1年前のモデルには余裕を感じていたというのに。\u003C/p>\u003Cp>本当に負けた日には、わたしも「オデ、Fableノウデ、クウ。オデ、ツヨイエンジニアニ、ナル」とか言い出しかねません。まぁ、相手に腕は無いんですが。\u003C/p>\u003Cp>以前、LLMがどれだけ優れていても、つまらない人間はつまらないという記事を書きました。今回は、その矛先を自分に向けてみようと思います。\u003C/p>\u003Cp>私は幼い頃から気持ちの悪いコンピュータのオタクでした。それ自体はただただ気持ち悪いだけなのでいいのですが、いつの日からか、技術は好奇心の対象というより、無価値な自分を価値あるものに見せるための粉飾の材料になっていたようにも思います。技術の話をしている間だけは、何者かでいられるためです。\u003C/p>\u003Cp>念のため書いておくと、これは私が特別高度な事を理解していることを示唆するものではありません。\u003C/p>\u003Cp>とは言え、世の中の大半は(詳しいとされている人でさえ)基礎的な部分を碌に理解していません。TCPの輻輳制御を説明できないままインフラを語り、ベジェの制御点の意味も知らないままモーションを売っています。だから、尤もらしいことを言うだけで相対的に浮上できてしまう。ただそれは、周囲の無理解に支えられた非本質的な虚構でしかないとも思うのです。\u003C/p>\u003Cp>白状すると、私は自分を大きく見せようとする無知な人が苦手です。それは私自身がそういう側面を持ち合わせているからなのかもしれませんし、そうではないのかもしれません。実際のところ、周りが私のことをどう思っているかなんて知りようがないので、どちらとも言えないのですが。\u003C/p>\u003Cp>そして今、尤もらしいことを言う能力なら人間よりよほど上手い計算機が現れてしまいました。虚構で嵩上げしていた部分から順に価値が剥がれ落ちていきます。これは困ったことになりました。\u003C/p>\u003Cp>では、何が残るのでしょうか。\u003C/p>\u003Cp>私は、分からないことを分からないと自分で認識して、批判的に内省できることだと考えています。視座が高い話をしたいわけではありません。むしろ逆で、それすら出来ないメタ認知で、現代社会に適応できるのか？という純粋な疑問です。\u003C/p>\u003Cp>LLMは自分が何を分かっていないのかを分かっていません。知識の穴に差し掛かっても速度を落とさず、同じ自信で虚偽を出力してくる。あれだけ流暢に喋る計算機が、自分の限界の認識だけは絶望的に下手なわけです。裏を返せば、自分の理解の輪郭を把握していること, どこまでが検証済みでどこからが受け売りかを区別できること, 分からないと言えること。今のところ、ここあたりだけは辛うじて人間の役割として残っています。\u003C/p>\u003Cp>むしろ、それを持たない人間には価値がないので、LLMでいいです。分かっていないことを分かっていないまま断言する人間は、品質でも再現性でもコストでもその辺の計算機に劣ります。存在意義がありません。\u003C/p>\u003Cp>偉そうなことを書きましたが、真っ先に価値が剥がれる側は多分わたしです。コーディングで負ける日が来たとき、身の程を知る知性とやらが飯の種になる保証はどこにもありません。\u003C/p>\u003Cp>とはいえ、他にやれることも特に思いつかないので、当面は自分がどこから分かっていないのかの確認だけ続けることになりそうです。それすら粉飾の一部だと言われたら、返す言葉もありませんが。\u003C/p>",[12,18],{"id":13,"createdAt":14,"updatedAt":15,"publishedAt":14,"revisedAt":15,"slug":16,"name":17},"wia4slp55q","2025-04-28T07:14:14.541Z","2025-12-03T16:08:13.798Z","thoughts","独り言",{"id":19,"createdAt":20,"updatedAt":21,"publishedAt":20,"revisedAt":21,"slug":22,"name":23},"qfey3yw0z1","2025-04-29T08:44:41.687Z","2025-12-03T16:07:14.622Z","technology","テクノロジー",true,1,0,{"contents":28,"totalCount":52,"offset":26,"limit":25},[29],{"id":30,"createdAt":31,"updatedAt":32,"publishedAt":33,"revisedAt":32,"title":34,"content":35,"tags":36,"is_no_index":50,"summary":51},"hp0fd0z-gnnt","2026-07-04T12:48:34.820Z","2026-07-04T13:57:28.343Z","2026-07-04T13:11:31.078Z","塩漬けのMisskey v12を最新版にアップグレードする","\u003Ch1 style=\"text-align: start\" id=\"h8d027c8ed3\">はじめに\u003C/h1>\u003Cp style=\"text-align: start\">どうも、わたしです。\u003C/p>\u003Cp style=\"text-align: start\">先日、お友達の運営する2つのMisskeyインスタンスを、v12.119.1ベースのフォークから最新の2026.6.0ベースの\u003Ca href=\"https://github.com/lqvp/misskey-tempura\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">別フォーク(tempura)\u003C/a>へ移行しました。およそ3年半の塩漬けインスタンスです。\u003Cbr>バックアップはありませんでしたし、FWもなく、inbound全解放の状態でした。よく今まで無事だったなと。\u003C/p>\u003Cp style=\"text-align: start\">旧サーバはConoHa VPS上のUbuntu 22.04にMisskey install shell scriptで構築された環境でした。これをKAGOYA VPSのUbuntu 26.04へDocker構成で丸ごと引っ越します。DBはPGroonga入りのPostgreSQL18にし、\u003Ccode>files/\u003C/code>配下にあったメディア類はR2へ、デプロイはcompose-cdでGitOps化するところまでやりました。当エントリはその備忘録です。\u003C/p>\u003Ch1 style=\"text-align: start\" id=\"h8aea7b1b68\">移行前と移行後\u003C/h1>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>\u003C/p>\u003C/th>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>旧\u003C/p>\u003C/th>\u003Cth colspan=\"1\" rowspan=\"1\">\u003Cp>新\u003C/p>\u003C/th>\u003C/tr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>サーバ\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ConoHa VPS(Ubuntu 22.04)\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>KAGOYA VPS(Ubuntu 26.04LTS)\u003C/p>\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Misskey\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>v12.119.1フォーク(systemd)\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>tempura 2.0.9(Docker)\u003C/p>\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>DB\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>PostgreSQL15\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>PostgreSQL18.4+PGroonga\u003C/p>\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>全文検索\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>無し\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>PGroonga\u003C/p>\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>メディア\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>ローカル\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Cloudflare R2\u003C/p>\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>リバースプロキシ\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>nginx+certbot\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>Caddy+Cloudflare Origin証明書\u003C/p>\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>バックアップ\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>無し\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>R2へ1日2回\u003C/p>\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>デプロイ\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>\u003C/p>\u003C/td>\u003Ctd colspan=\"1\" rowspan=\"1\">\u003Cp>compose-cd\u003C/p>\u003C/td>\u003C/tr>\u003C/tbody>\u003C/table>\u003Cp style=\"text-align: start\">compose一式は、以前\u003Ca href=\"https://misskey.blue/\" target=\"_blank\" rel=\"noopener noreferrer\">misskey.blue\u003C/a>用に組んだ\u003Ca href=\"https://github.com/chan-mai/misskey.blue-docker-provision\" target=\"_blank\" rel=\"noopener noreferrer\">provisionレポジトリ\u003C/a>を下敷きにしています。 概ね中身は\u003Ca href=\"https://mq1.dev/entry/krpvl5itbr9h\" target=\"_blank\" rel=\"noopener noreferrer\">以前書いた構築記事\u003C/a>のものです。\u003Cbr>成果物は\u003Ca href=\"https://github.com/miel-misskey/rochka.club-docker-provision\" target=\"_blank\" rel=\"noopener noreferrer\">ここ\u003C/a>に置いてあります。\u003C/p>\u003Cp style=\"text-align: start\">\u003Ca href=\"https://github.com/miel-misskey/rochka.club-docker-provision\" target=\"_blank\" rel=\"noopener noreferrer\">\u003Cu>https://github.com/miel-misskey/rochka.club-docker-provision\u003C/u>\u003C/a>\u003C/p>\u003Ch1 style=\"text-align: start\" id=\"hd196191eab\">アップグレードの方針\u003C/h1>\u003Cp style=\"text-align: start\">フォークのまま多段アップグレードはしません。というより、できませんでした。\u003C/p>\u003Cp style=\"text-align: start\">旧サーバが使っていたv12.119.1ベースのフォークは元レポジトリ自体がすでに消滅していて、差分をたどって移行パスを検証するという選択肢がなかったためです。なのでDBをバニラ相当とみなし、上流の通常アップグレード手順にそのまま追従させて最新版まで上げてから、最後にtempuraフォーク差分を適用することにしました。\u003C/p>\u003Cp style=\"text-align: start\">手順としては、旧サーバで\u003Ccode>pg_dump\u003C/code>したものを新サーバのpostgres:15コンテナへ\u003Ccode>pg_restore\u003C/code>し、あとはappイメージのtagを差し替えて起動、マイグレーションの完走を見届けてまた次のtagへ。\u003C/p>\u003Cp style=\"text-align: start\">ここで\u003Ccode>docker compose exec -T\u003C/code>がstdinを消費することにハマりました。スクリプトを流し込む段階で、execが残りのスクリプトをstdinとして食ってしまい、以降のコマンドが実行されなかったためです。restoreやインデックス作成がエラーを出さずに飛ぶので気づきにくいですが、SQLは\u003Ccode>< file\u003C/code>、参照系は\u003Ccode></dev/null\u003C/code>で明示的にリダイレクトするといいでしょう。\u003C/p>\u003Cp style=\"text-align: start\">今回は、12.119.1 → 13.14.2 → 2023.12.2 → 2024.10.0 → 2025.1.0 → 2026.6.0 → tempura 2.0.9の順でアップグレードしました。最大の難所はv12→v13で、かなり大規模な差分が入っています。マイグレーション数でいうと350本前後、tempura独自の57本を足して最終的に400本ちょっとでした。 \u003C/p>\u003Cp style=\"text-align: start\">v12からの移行で苦しんだことも記憶に新しいですが、もう3年前なんですね、あれ。\u003C/p>\u003Cp style=\"text-align: start\">移行に際して、\u003Ccode>default.yml\u003C/code>の項目も幾分か変わっているのですが、id方式(aid)だけは全世代を通して変えないことが必要です。これはデータの整合性を担保するために必須です。\u003C/p>\u003Cp style=\"text-align: start\">また、PG15からPG18への移行はメジャーバージョン跨ぎなのでデータディレクトリの流用はできず、ここもdump/restoreで行いました。PGDATAが\u003Ccode>/var/lib/postgresql/18/docker\u003C/code>にあるので、親ディレクトリごとマウントすれば永続化できます。今回は合わせてPGroongaの導入も行っているので、\u003Ccode>CREATE EXTENSION pgroonga\u003C/code>して\u003Ccode>note.text\u003C/code>にインデックスを張り、\u003Ccode>fulltextSearch: sqlPgroonga\u003C/code>を有効にしました。v12には無かった全文検索が使えるようになりました。\u003C/p>\u003Ch1 style=\"text-align: start\" id=\"h19474baa06\">メディア移行とMIME\u003C/h1>\u003Cp style=\"text-align: start\">\u003Ccode>drive_file\u003C/code>は53,534行ありましたが、ローカルに実体を持つのは4,007件だけで、残り49,527件はリモートのリンク参照でした。ファイルそのものは9,564個(原本4,007+サムネイル3,898+webpublic1,659)で計8.8GiBほどありました。これらをまとめて旧サーバからrcloneでR2へ直接上げました。\u003C/p>\u003Cp style=\"text-align: start\">DB側の既存メディアのURL書き換えは、\u003C/p>\u003Cpre>\u003Ccode class=\"language-sql\">UPDATE drive_file SET url = replace(url, 'https://<domain>/files/', 'https://media.<domain>/local/') WHERE ...;\u003C/code>\u003C/pre>\u003Cp style=\"text-align: start\">で行い、空のフィールドは空のまま残るので404は出ません。非空URLの合計(4,007+3,898+1,659=9,564)が物理ファイル数とぴったり一致したことを確認しました。\u003C/p>\u003Cp style=\"text-align: start\">また、リモートには\u003Ccode>files/\u003C/code>配下のファイルを参照するデータが残っていることを考慮し、アプリケーションの前段に置いているCaddyでリダイレクトする経路をあわせて用意しています。\u003C/p>\u003Cpre>\u003Ccode>example.com {\n\ttls /etc/ssl/certs/certificate.pem /etc/ssl/private/key.pem\n\tencode gzip\n\theader /assets Cache-Control "public, max-age=31536000, immutable"\n\tfile_server\n\n\tlog {\n\t\toutput file /var/log/caddy/access.log {\n\t\t\troll_size 500mb\n\t\t\troll_keep 10\n\t\t}\n\t\tformat json {\n\t\t\ttime_format iso8601\n\t\t}\n\t}\n\n\t# 旧メディアURLをR2へ\n\t@legacyfiles path_regexp legacyfiles ^/files/(.*)$\n\tredir @legacyfiles https://media.example.com/local/{re.legacyfiles.1} permanent\n\n\treverse_proxy app:3000 {\n\t\theader_up X-Real-IP {header.CF-Connecting-IP}\n\t\theader_up X-Forwarded-For {header.CF-Connecting-IP}\n\t\theader_up X-Forwarded-Proto {scheme}\n\t\theader_up X-Forwarded-Host {host}\n\n\t\thealth_uri /\n\t\thealth_interval 10s\n\t\thealth_timeout 2s\n\t\thealth_status 200\n\t}\n\n\thandle_errors {\n\t\t# appコンテナ停止時などのバックエンドエラー\n\t\t@backend_down `{err.status_code} in [500, 501, 502, 503, 504, 522]`\n\t\thandle @backend_down {\n\t\t\t# /api系は外形監視のためメンテナンスを返さず本来のエラー(5xx)を通す\n\t\t\t@api path /api/*\n\t\t\thandle @api {\n\t\t\t\trespond {err.status_code}\n\t\t\t}\n\t\t\t# それ以外はメンテナンスページを200で返す\n\t\t\thandle {\n\t\t\t\treverse_proxy maintenance:80 {\n\t\t\t\t\thandle_response {\n\t\t\t\t\t\tcopy_response_headers\n\t\t\t\t\t\tcopy_response 200\n\t\t\t\t\t}\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t}\n}\u003C/code>\u003C/pre>\u003Cp style=\"text-align: start\">R2への転送で一つ問題があり、Misskeyのローカルファイルはファイル名に拡張子がなく(accessKeyがそのままファイル名)、rcloneは拡張子からしかMIMEを判定しないため、全部\u003Ccode>application/octet-stream\u003C/code>でアップロードされていました。画像はブラウザのスニッフィングで表示されてしまうため気づきにくいのですが、動画がインライン再生できない等の問題が発生します。 修正として、S3のCopyObject(metadata REPLACE)で、Content-Typeだけ貼り替えました。\u003Ccode>file --mime-type\u003C/code>の実判定値を9,564件流し込んで完了しました。ちなみに、並列に\u003Ccode>aws-cli\u003C/code>を立ち上げるやり方はメモリ2GiBの子には荷が重すぎたようでOOMしてしまいました。boto3+スレッドプールの単一プロセスでやるのが速くて安全そうです。\u003C/p>\u003Cp style=\"text-align: start\">余談ですが、アップロード中に止めようとして打った\u003Ccode>pkill -f "rclone copy"\u003C/code>は、自分がsshで送ったコマンド文字列そのものにもマッチするようでセッションごと死んでしまい、exit 255が返ってきて数秒固まりました。\u003Ccode>pkill -x rclone\u003C/code>を使いましょう。\u003C/p>\u003Ch1 style=\"text-align: start\" id=\"hc07c39fafc\">全員のアイコンがidenticonになる\u003C/h1>\u003Cp style=\"text-align: start\">v12からv13へのアップグレードで、既存ユーザの\u003Ccode>avatarUrl\u003C/code>/\u003Ccode>bannerUrl\u003C/code>がnullになりました。Misskeyの挙動として、identiconにフォールバックされるので、移行直後は全ユーザーのアイコンがidenticon表示になってしまいました。失敗したのかとちょっと焦りましたね。\u003C/p>\u003Cp style=\"text-align: start\">解決策として、\u003Ccode>drive_file\u003C/code>自体は無事(なはず)なので、そこから再構築しました。\u003C/p>\u003Cpre>\u003Ccode class=\"language-sql\">UPDATE "user" SET "avatarUrl" = COALESCE(NULLIF(f."webpublicUrl", ''), f."url") FROM drive_file f WHERE ...;\u003C/code>\u003C/pre>\u003Cp style=\"text-align: start\">これで9,507人のアバターと7,238件のバナーが正常に表示されます。\u003Cbr>注意点として、ユーザ情報はin-memoryでキャッシュされているので、DBを直しただけでは反映されませんので、Misskeyのアプリケーション本体を再起動するところまでやりましょう。\u003C/p>\u003Cp style=\"text-align: start\">ちなみに、絵文字も似たような問題を踏んでいて、\u003Ccode>emoji.publicUrl\u003C/code>が旧URLのまま残り、ローカルの絵文字だけダミー画像にフォールバックしていました。URLを\u003Ccode>drive_file\u003C/code>と同じ直R2形式に置換し、Redisの\u003Ccode><domain>:singlecache:localEmojis\u003C/code>を消して再起動することで事なきを得ました。 ここで安直に\u003Ccode>FLUSHALL\u003C/code>してしまうとジョブキューごと消えてしまうのでやってはいけません。\u003C/p>\u003Ch1 style=\"text-align: start\" id=\"h61e6f6ae5a\">管理者がいない\u003C/h1>\u003Cp style=\"text-align: start\">今回利用しているフォークのtempuraでは、管理者/モデレータの判定を\u003Ccode>permissionGroup\u003C/code>という独自カラム(Admin/MainModerator/Normal/Community)で行っており、バニラにある\u003Ccode>isAdministrator\u003C/code>のbool値を見ていません。管理者ロールをDBで作って割り当てても、\u003Ccode>permissionGroup='Admin'\u003C/code>でなければ権限は付かないことになります。\u003C/p>\u003Cp style=\"text-align: start\">さらに、v12からの移行では\u003Ccode>user.isAdmin\u003C/code>がロールに変換されません。よって、移行後のインスタンスには管理者が存在しないインスタンスが完成してしまいます。\u003C/p>\u003Cp style=\"text-align: start\">対応として、DBで管理者ロールを手組みしました。IDはaid形式(タイムスタンプのbase36を8桁+ランダム2桁)を自前で用意し、\u003Ccode>role_assignment\u003C/code>で割り当てて、ロールキャッシュ解消のためapp再起動。これで事なきを得ました。\u003C/p>\u003Ch1 style=\"text-align: start\" id=\"hcb82afc914\">横展開\u003C/h1>\u003Cp style=\"text-align: start\">同じ手順で2台目も移行しました。1台目のレポジトリをコピーしてfindとsedでドメインとレポジトリ名を置換し、\u003Ccode>compose.yaml\u003C/code>を初期状態(postgres:15+バニラ)に戻してから、同じ手順をもう一度たどるだけで、データ規模が小さかったこともあり、あっさりと終わりました。\u003C/p>\u003Cp style=\"text-align: start\">\u003Ca href=\"https://misskey.blue/notes/01KWHYKPNCBKFFHH66VA7D1Z8T\">https://misskey.blue/notes/01KWHYKPNCBKFFHH66VA7D1Z8T\u003C/a>\u003C/p>\u003Ch1 style=\"text-align: start\" id=\"h1afe451c43\">さいごに\u003C/h1>\u003Cp style=\"text-align: start\">移行結果を確認しておきます。1台目でいうとnotes 189,545、users 9,841、drive_file 53,534。移行の前後で1件も欠けていません(usersだけ+1ですが、これはインスタンスactorが追加されたぶんなので正常です)。\u003Cbr>3年半塩漬けだったデータを、そのまま現行環境へ載せ替えられました。\u003C/p>\u003Cp style=\"text-align: start\">同じようなことを試みる誰かの参考になれば幸いです。\u003C/p>\u003Cp style=\"text-align: start\">それでは。\u003C/p>",[37,43,44],{"id":38,"createdAt":39,"updatedAt":40,"publishedAt":39,"revisedAt":40,"slug":41,"name":42},"vmhb23sq4","2025-07-29T12:56:07.884Z","2025-12-03T16:06:19.140Z","misskey","Misskey",{"id":19,"createdAt":20,"updatedAt":21,"publishedAt":20,"revisedAt":21,"slug":22,"name":23},{"id":45,"createdAt":46,"updatedAt":47,"publishedAt":46,"revisedAt":47,"slug":48,"name":49},"4oy2jc8mdg","2025-04-28T07:14:01.179Z","2025-12-03T16:08:24.495Z","diary","日記",false,"はじめにどうも、わたしです。先日、お友達の運営する2つのMisskeyインスタンスを、v12.119.1ベースのフォークから最新の2026.6.0ベースの別フォーク(tempura)へ移行しました。およそ3年半の塩漬けインスタンスです。バックアップはありませんでしたし、FWもなく、inbound全解",68,{"contents":54,"totalCount":26,"offset":26,"limit":25},[],1783975274073]