雑記帳

  • X(Twitter)タイムラインがWordPressに埋め込めない問題をChatGPTと徹底調査した結果

    カテゴリー:

    はじめに

    このホームページにX(旧Twitter)のタイムラインを埋め込もうとしたところ、公式の埋め込みコードを使用してもタイムラインが表示されず、

    「Posts by ○○」というリンクだけが表示される

    という現象が発生しました。

    最初はWordPressの設定ミスを疑いましたが、原因が分からなかったため、ChatGPT(GPT-5.5)に調査を依頼し、一緒に原因を一つずつ切り分けていくことにしました。

    数時間にわたり、WordPress・Apache・HTML・JavaScript・ネットワーク・XのAPIまで順番に確認した結果、原因はX(旧Twitter)側の埋め込みサービスにある可能性が極めて高いという結論に至りました。

    同じ症状で困っている方の参考になればと思い、調査内容をまとめます。


    環境

    • WordPress 7.0.1
    • テーマ:Twenty Twenty-Five
    • サーバー:Ubuntu 24.04
    • Apache 2.4.64
    • PHP 8系
    • HTTPS(Let’s Encrypt)

    使用した埋め込みコード

    X公式(publish.x.com)が生成したコードをそのまま使用しました。

    <a class="twitter-timeline"
    href="https://x.com/kagaku_info?ref_src=twsrc%5Etfw">
    Posts by kagaku_info
    </a>
    
    <script async src="https://platform.x.com/widgets.js"
    charset="utf-8"></script>
    

    症状

    表示されるのは

    Posts by kagaku_info
    

    というリンクだけです。

    クリックするとXのプロフィールは正常に表示されますが、タイムラインは埋め込まれません。


    ChatGPTと一緒に原因を切り分ける

    ChatGPTからは

    「WordPressではなく、まず最小構成で試しましょう。」

    という提案がありました。

    そこで、WordPressを疑う前に、原因を一つずつ消していくことにしました。


    ① WordPressを疑う

    通常の段落ブロックではなく、

    カスタムHTMLブロック

    で公式コードを貼り付けました。

    結果

    改善せず。


    ② widgets.jsを確認

    Chrome DevTools の Network を確認すると

    https://platform.x.com/widgets.js
    

    は

    200 OK
    

    でした。

    つまりJavaScript自体は正常に読み込まれています。


    ③ JavaScriptエラーを確認

    Consoleには

    JQMIGRATE: Migrate is installed
    

    しか表示されません。

    JavaScriptエラーはありませんでした。


    ④ WordPressを完全に除外

    ChatGPTから

    「WordPressを使わないHTMLだけでも試しましょう。」

    と提案されたため、

    <!DOCTYPE html>
    <html lang="ja">
    <head>
    <meta charset="utf-8">
    <title>X Test</title>
    </head>
    <body>
    
    <a class="twitter-timeline"
    href="https://x.com/OpenAI">
    Posts by OpenAI
    </a>
    
    <script async src="https://platform.x.com/widgets.js"></script>
    
    </body>
    </html>
    

    という test.html を作成しました。

    結果は

    WordPressを使わなくても同じ症状でした。

    ここで

    WordPressは原因ではない

    ことが分かりました。


    ⑤ Apacheを疑う

    続いてChatGPTから

    「HTTPレスポンスヘッダーを確認しましょう。」

    という提案がありました。

    確認したところ

    • Content-Security-Policy
    • X-Frame-Options
    • Cross-Origin-Embedder-Policy

    などは一切設定されていません。

    Apache設定も確認しましたが、

    iframeをブロックする設定はありませんでした。

    ここで

    Apacheも原因ではない

    ことが分かりました。


    ⑥ ネットワークを変更

    さらに

    • スマホ4G/5G
    • スマホテザリング
    • VPNあり
    • VPNなし

    で確認しました。

    結果は

    すべて同じ。


    ⑦ OpenAI公式アカウントでも試す

    ChatGPTから

    「OpenAIなど別アカウントでも試してください。」

    という提案がありました。

    結果は

    OpenAIでも同じ症状。

    つまり

    アカウント固有の問題ではありませんでした。


    決定的な証拠

    ChatGPTから

    「Networkで syndication.twitter.com を確認してください。」

    と指示されました。

    すると

    https://syndication.twitter.com/srv/timeline-profile/...
    

    が

    429 Too Many Requests
    

    を返していました。

    つまり

    widgets.js
          ↓
    syndication.twitter.com
          ↓
    429
          ↓
    iframe生成失敗
    

    という流れになっていたのです。

    これが

    タイムラインが表示されない直接の原因

    でした。


    X Developer Communityでも確認

    ChatGPTに最新情報を調査してもらったところ、

    X Developer Communityには

    • widgets.jsは正常
    • timelineだけ表示されない
    • syndication.twitter.com が429
    • コードは変更していない

    という報告が複数ありました。

    つまり

    今回だけの現象ではありません。


    結論

    今回の調査では

    • WordPress
    • HTML
    • Apache
    • HTTPS
    • JavaScript
    • ネットワーク
    • スマートフォン
    • VPN

    まで一つずつ切り分けました。

    その結果、

    https://syndication.twitter.com/srv/timeline-profile/
    

    が

    429 Too Many Requests
    

    を返していることを確認しました。

    現時点では、

    WordPressやApacheではなく、X(旧Twitter)側の埋め込みサービスに原因がある可能性が極めて高い

    と判断しています。


    ChatGPTを使って感じたこと

    今回の調査では、ChatGPTは「答えを決めつける」のではなく、

    • 仮説を立てる
    • 一つずつ検証する
    • 結果に応じて仮説を修正する

    という形で、まるで一緒にデバッグを行うパートナーのように調査を進めることができました。

    途中で「WordPressではない」「Apacheでもない」といった結論も、実際の検証結果に基づいて修正しながら進められたため、最終的にはX側の埋め込みサービスが429を返しているという技術的な根拠までたどり着くことができました。

    AIは万能ではありませんが、人間が検証を行い、AIが次の切り分け手順を提案するという進め方は、トラブルシューティングにおいて非常に有効だと実感しました。


    とりあえず

    X(旧Twitter)とInstagram(インスタグラム)へのリンクはフッダーに付加してあります。

    また、埋め込みの試験をTESTで行っています。

    もし、Xのタイムラインの埋め込みがうまくいっている人がいらっしゃったらコメント欄からでも教えてください。

  • 温湿度データロガーを使ってみたら、エアコンの制御まで見えてきた

    カテゴリー:

    今年の夏も、昨年に負けないくらい暑い日が続いています。

    暑い日には「今日は暑いなぁ」、寒い日には「なんだか冷えるなぁ」と感じますが、そのとき実際の室温や湿度がどれくらいなのかを意識することは意外と少ないものです。

    皆さんは普段、部屋の温度や湿度をどのように管理しているでしょうか?

    時計に付いている温度計をちらっと見る程度という方もいれば、エアコン任せという方もいるかもしれません。

    実際、「暑い」「寒い」という感覚には個人差があります。

    職場でも、

    「今日は暑いね」

    と言う人がいる一方で、

    「えっ、27℃もあるの?もっと低いと思った」

    という人もいます。

    同じ空間にいても、人によって感じ方は大きく異なるのです。

    環境省では、省エネルギーを意識しながら快適性を保つ目安として、

    夏季:室温28℃
    冬季:室温20℃

    を推奨しています。

    しかし本当に部屋の温度はそのように推移しているのでしょうか。

    以前から、

    室内の温度変化
    車内温度の変化
    エアコンによる温湿度制御

    に興味があった私は、実際に測定してみることにしました。


    2千円で買える温湿度データロガー

    そこで購入したのが温湿度データロガーです。

    昔はデータロガーといえば研究用途や産業用途が中心で、数万円から数十万円する機器でした。

    ところが現在では、2千円で購入できる製品も珍しくありません。

    Amazonで探した結果、今回購入したのは JJWS23というモデルです。

    液晶表示はありませんが、

    ・温度・湿度を同時測定
    ・最短1分間隔で記録
    ・BlueToothによるデータ回収
    ・CSV出力対応
    ・低価格

    という条件を満たしていました。

    特にBluetooth対応なのが魅力です。

    測定場所へ行って本体を回収しなくても、その場でスマートフォンからデータを取得できます。


    まずは3日間、どこへ行くにもJJWS23を持ち歩いてみた

    せっかく購入したので、まずは徹底的に使ってみることにしました。

    購入後の3日間、 JJWS23を常に携帯し、自分が滞在する環境の温度と湿度を記録してみました。

    言ってみれば、自分自身が実験台です。

    この期間は平日だったので

    ・06:00~18:00頃:職場
    ・18:00~06:00頃:自宅

    という生活パターンになります。

    その結果をグラフ化してみると、温度と湿度が時間帯によって実に面白い変化を見せてくれました。

    8/3から8/7の筆者I-sattoの滞在した環境の温湿度のトレンド

    赤が湿度(humidity)、黒が気温(Temperature)です。

    また、グラフはグレーでハッチングしてあるところが職場での測定値になります。ちなみに、この三日間は比較的涼しく、以下のような気温でした。

    平均気温(℃)最高気温(℃)最低気温(℃)平均湿度(%)
    8月4日23.827.820.076
    8月5日24.428.919.375
    8月6日26.230.822.389

    データからエアコンの制御が見えてくる

    最も興味深かったのは職場での測定結果です。

    朝、出勤してエアコンを入れると室温が下がり始めます。

    しかし、設定温度付近に達すると冷房能力が弱まり、再び温度が上昇します。

    すると今度は冷房が強くなり、また温度が下がる。

    この繰り返しがグラフ上にはっきり現れていました。

    以下のグラフは8月5日の6時から18時の職場にいる時間帯を拡大表示したものです。

    2026年8月5日の筆者I-sattoの滞在した職場の温湿度の時間変化

    波打つような温度変化を確認すると、

    エアコンが約20分周期で室温を制御している

    ことが見えてきます。

    普段は意識することのない空調制御の動きが、温湿度データとして可視化された瞬間でした。

    さらに室温はおおむね27℃前後で維持されていることも確認できます。


    西日がエアコンに勝つ瞬間

    さらに興味深いのが午後の変化です。

    昼過ぎまでは安定していた室温が、14時半頃から急激に上昇します。

    職場は西日の影響を受けやすい部屋です。

    そのため午後になると窓から侵入する熱量が増加し、エアコン能力だけでは室温上昇を抑えきれなくなります。

    結果として、

    26℃
    27℃
    28℃
    一時的に29℃

    まで上昇する様子がグラフに記録されていました。

    まさに、

    「西日との戦い」

    がデータから読み取れたわけです。


    誰もいない職場は夜どうなるのか?

    さらに実験を続けました。

    8月5日はJJWS23を持ち帰らず、職場に置いたまま帰宅してみました。

    つまり、8月5日18時から翌日8月6日の6時までは

    無人・空調なしのオフィス

    の温湿度変化を測定したのです。

    結果は予想以上に興味深いものでした。

    夕方に29℃近くあった室温は、夜を通してゆっくりと低下していきます。

    一方、湿度は徐々に上昇します。

    そして日の出前後まで温度は下がり続け、朝になると再び上昇へ転じます。

    人がいない空間でも、建物全体が外気や日射の影響を受けながら呼吸するように温度を変化させていることがよく分かりました。


    実は意外と高機能だった専用アプリ

    このJJWS23にはスマートフォン用アプリが用意されています。

    単なる温湿度表示だけでなく、

    ・カビのリスク

    ・測定ログの最高温度/最低温度とその日時

    ・現在温度、現在湿度

    ・VPD(飽差)

     VPD(Vapor Pressure Deficit)は、空気がどれだけ水蒸気を保持できるかを示す指標で、植物の蒸散や水分管理に大きな影響を与え、「飽差」と呼ばれます。
    この値(VPDVPD)は飽和蒸気圧(VPesVPes)と相対湿度(RH)から、以下のテテンス(Tetens)の式で計算が可能です。

    VPD=VPes(T)(1−RH/100)VPD=VPes(T) (1-RH/100)
    VPes(T)=0.61078exp(17.27T)/(T+237.3))VPes(T)= 0.61078 exp( 17.27 T )/ (T + 237.3) )

    ここで、飽和蒸気圧(VPesVPes)は温度(TT)から求めることができるので、実質的にはVPDVPD(飽差)は温度(TT)と相対湿度(RHRH)が判れば計算できるので、ここで示されている値は計算値になるはずです。
     で、実際に計算すると
    28.5℃、52.4%時のVPDは1.85kPaとなり表示値と一致します。
    29.5℃、72.3%時には1.14kPaとなり、こちらも表示値と一致します。

    ・露点

    露点は結露する温度で、室内やビニールハウスなど閉じた環境で、そのまま温度を下げると、この露点まで下がったときに結露してしまいます。この露点(Td)も温度(T)と相対湿度(RH)から以下の式で計算が可能です。

    Td=237.3×γ/(17.27−γ)Td = 237.3 × γ / (17.27 − γ)
    γ(RH,T)=ln(RH/100)+17.27T/(T+237.3)γ(RH,T) = ln(RH/100) + 17.27 T / (T + 237.3)

    で、実際に計算すると
    28.5℃、52.4%時の露点は17.80℃となり表示値とほぼ一致します。
    29.5℃、72.3%時には23.98℃となり、こちらは表示値と一致します。

    ・暑さ指数

    なども表示できます。

    農業用途を意識しているためか、植物栽培で重要となるVPDまで表示されるのは少し驚きでした。


    「暑さ指数」の正体を調べてみた

    ところが、アプリの表示を見ていて気になる点を発見しました。

    表示される「暑さ指数」が、どう計算してもWBGT(湿球黒球温度):Wet Bulb Globe Temperatureと一致しないのです。

    そこで計算式を調べてみましたが、どうしても値が合いません。

    通常、黒球温度が判らないと推定が難しいのですが、室内用として簡易推定式(気温(T)と湿度(RH)のみで近似)が決められています。

    簡易推定式(気温と湿度のみで近似)

    WBGT=0.7×Tw+0.3×TWBGT = 0.7 ×Tw+ 0.3 ×T
    Tw(RH,T)=Tatan(0.151977(RH+8.313659)0.5)+atan(T+RH)Tw(RH,T)= T atan(0.151977 (RH+8.313659)^{0.5})+atan(T+RH)  
     −atan(RH−1.676331)+0.00391838・RH1.5atan(0.023101・RH) -atan(RH-1.676331)+0.00391838・RH^{1.5} atan(0.023101・RH)   −4.686035   – 4.686035 

    なお、上の湿球温度Tw(RH,T)はStull近似式といわれる計算式を用いて温度(T)と湿度(RH)から算出しています。

    で、実際に計算すると
    28.5℃、52.4%時のWBGTは26.37℃となり表示の「暑さ指数」値29.29℃と一致しません。また、 29.5℃、72.3%時には28.30℃となり、こちらも表示値34.35℃と全く一致しません。

    いったいどういうことでしょう?

    もしかして翻訳の問題ではないか?

    そう考えて英語表記を確認すると、表示されていたのは

    Heat Index

    でした。

    つまり日本語版では「暑さ指数」と表示されていますが、実際にはWBGTではなく「熱指数」を示していたのです。

    ということで、「熱指数」で計算してみます。熱指数(Heat Index:HI)は気温(T)と湿度(RH)のみで以下の式で熱指数を定義しているステッドマン表を近似できます。

    HI=c1+c2・T+c3・RH+c4・T・RH+c5・T2+c6・RH2HI=c1 + c2・T + c3・RH + c4・T・RH + c5・T^{2} + c6・RH^{2}
            +c7・T2・RH+c8・T・RH2+C9・T2・RH2         + c7・T^{2}・ RH + c8・T ・RH^{2} + C9・ T^{2} ・RH^{2}
      c1=−8.784694756 c2=1.61139411 c3=2.338548839  c1 = -8.784694756 c2 = 1.61139411  c3 = 2.338548839
      c4=−0.14611605 c5=−0.012308094 c6=−0.016424828  c4 = -0.14611605  c5 = -0.012308094 c6 = -0.016424828
      c7=0.002211732 c8=0.00072546 c9=−0.000003582   c7 = 0.002211732 c8 = 0.00072546 c9 = -0.000003582  

    で、実際に計算すると
    28.5℃、52.4%時のHeat Indexは29.29℃となり表示値と一致します。
    29.5℃、72.3%時には34.35℃となり、こちらも表示値と一致します。

    ということで、このアプリでいう暑さ指数とはHeat Indexすなわち、熱指数を表していることが判りました。いわゆる熱中症の判断材料とするWBGTとは異なりますので、注意してください。


    使ってみて分かったデータロガーの面白さ

    今回、温湿度データロガーを使ってみて感じたのは、

    「測るだけで世界の見え方が変わる」

    ということです。

    何となく暑いと思っていた環境も、

    エアコンがどのように制御しているのか
    建物がどのように熱を蓄えているのか
    湿度がどのように変動しているのか

    をデータとして確認できます。

    さらに、普段は意識しないVPDや露点、Heat Indexといった指標の意味を理解するきっかけにもなりました。

    2千円で購入できる小さな機器ですが、その中には思いのほか多くの「科学のつまみ食い」が詰まっています。

    温度や湿度の変化に興味がある方なら、一度試してみる価値は十分にあるのではないでしょうか。

  • リモート接続中にUbuntu 26.04へアップグレードしたら、RDPが切れた ― ChatGPTと一緒に復旧した顛末記 ―

    カテゴリー:

    はじめに

    以前から使用していたUbuntuサーバーを、Ubuntu 26.04 LTSへアップグレードすることにしました。

    今回は、普段使用しているWindows PCからRDP(リモートデスクトップ)でUbuntuに接続した状態のまま、リリースアップグレードを実行しました。

    アップグレードは順調に進んでいるように見えましたが、途中で突然RDP接続が切断されました。

    「アップグレードによって再起動したのだろう」と考え、その後あらためてRDP接続を試みました。

    ところが、思ったように接続できません。

    結果的には、アップグレード自体はかなり進んでいたものの、多数のパッケージがまだ設定されていない状態になっていました。

    この後、ChatGPTに状況を相談しながら状態を一つずつ確認し、最終的にUbuntu 26.04.1 LTSを正常な状態まで復旧することができました。

    今回は、その顛末を記録しておきます。


    1.リモートデスクトップからUbuntuをアップグレード

    今回の環境は、

    • Ubuntu 25.10系からUbuntu 26.04 LTSへアップグレード
    • GNOMEデスクトップ環境
    • Wayland
    • GNOME Remote DesktopによるRDP接続
    • Windows PCからリモート操作

    という構成です。

    UbuntuはノートPCにインストールし、直接ノートPCのモニターとキーボードを使用するのではなく、Windows PCからRDPで接続して使用しています。

    そこで今回も、リモート接続した状態でUbuntuのリリースアップグレードを開始しました。


    2.アップグレード途中でRDPが切断

    アップグレード処理は大量のパッケージを更新するため、かなり時間がかかります。

    しばらくすると、突然RDP接続が切れました。

    ここで、

    「アップグレードが終了して再起動したのだろう」

    と考えてしまいました。

    しかし、これは少し早い判断でした。

    アップグレードでは、GNOME、GDM、Wayland、ネットワーク関連など、現在のリモートデスクトップ環境そのものに関係するパッケージも更新されます。

    そのため、アップグレード途中でGUIやRDPのセッションが切断されることがあります。

    問題は、

    「RDPが切れたこと」と「アップグレードが完了したこと」は同じではない

    ということでした。


    3.再接続できず、アップグレードの状態を確認

    RDP接続を再度試みましたが、思ったように接続できませんでした。

    そこでChatGPTに状況を説明し、まずシステムのパッケージ状態を確認することにしました。

    実行したのが、

    sudo dpkg --audit
    

    です。

    すると、

    展開されましたが、まだ設定されていません

    というパッケージが大量に表示されました。

    GNOME関連のパッケージをはじめ、デスクトップ環境を構成する多数のパッケージが未設定の状態になっていました。

    つまり、

    Ubuntuのアップグレードは途中まで進んでいたものの、完全には終了していなかった

    ことが分かりました。


    4.apt-get -f installで未設定パッケージを処理

    次にChatGPTの助言に従い、

    sudo apt-get -f install
    

    を実行しました。

    すると、大量のパッケージについて、

    ○○○ を設定しています ...
    

    という処理が始まりました。

    GNOME、GDM、polkit、ibus、Remmina、Nautilusなど、デスクトップ環境に関係するパッケージが次々と設定されていきます。

    また、カーネルについても、

    linux-image-7.0.0-30-generic
    

    が処理され、initramfsの生成やGRUBの更新も行われました。

    最終的には、未設定だったパッケージの処理が完了しました。


    5.dpkg --auditで状態を確認

    修復できたかどうかを確認するため、再度、

    sudo dpkg --audit
    

    を実行しました。

    今度は何も表示されません。

    これは、dpkgから見て未設定のパッケージが残っていないことを意味します。

    ひとまずパッケージ管理上は正常な状態に戻ったと判断しました。


    6.再起動

    その後、システムを再起動しました。

    sudo reboot
    

    再起動後、Ubuntuのバージョンを確認すると、

    uname -r
    

    の結果は、

    7.0.0-30-generic
    

    となっていました。

    さらに、

    lsb_release -a
    

    では、

    Distributor ID: Ubuntu
    Description:    Ubuntu 26.04.1 LTS
    Release:        26.04
    Codename:       resolute
    

    と表示されました。

    これで、Ubuntu 26.04.1 LTSへのアップグレードが正常に完了していることを確認できました。


    7.ところが、RDPにはもう一つ問題があった

    OSのアップグレードは完了しましたが、ここで別の問題が出てきました。

    今回の目的は、

    Ubuntu本体側でログインしていなくても、Windows PCからRDP接続してUbuntuにログインしたい

    というものです。

    ところが、通常のユーザーセッション用RDPでは、本体側ですでにUbuntuへログインしていないと、思ったように接続できませんでした。

    そこでChatGPTと一緒にGNOME Remote Desktopの状態を確認しました。

    grdctl status
    

    と、

    sudo grdctl --system status
    

    を比較すると、通常ユーザー用とsystem-wideのRDPが別々に存在していることが分かりました。


    8.system-wideのRDPを有効化

    そこで、system-wideのGNOME Remote Desktopを有効にしました。

    sudo grdctl --system rdp enable
    

    状態を確認すると、

    RDP:
        Status: enabled
        Port: 3389
    

    となりました。

    一方、通常ユーザー側のRDPについては、

    gsettings set org.gnome.desktop.remote-desktop.rdp enable false
    

    として無効化しました。

    これは、通常ユーザー用とsystem-wideのRDPが二重に動作して混乱することを避けるためです。


    9.ログイン前のRDP接続に成功

    ここまで設定したところ、期待していた動作が実現しました。

    Ubuntu本体ではログインしていない状態で、

    Windows PCからRDP接続。

    すると、リモート側からUbuntuへログインできました。

    つまり、

    Ubuntu本体
        ↓
    ログインしていない
        ↓
    Windows PCからRDP
        ↓
    Ubuntuのログイン
        ↓
    GNOMEデスクトップ
    

    という使い方が可能になりました。


    10.しかもリモート側は大画面で使用できた

    当初は、RDP接続すると本体画面が表示されたままになり、リモート側が「拡張デスクトップ」のようになってしまう問題もありました。

    現在の設定を確認すると、

    gsettings get org.gnome.desktop.remote-desktop.rdp screen-share-mode
    

    は、

    'extend'
    

    となっています。

    ところが、system-wideのRDPからログインした場合には、以前とは異なり、リモート側の大きな画面を使って通常のUbuntuデスクトップを操作できるようになりました。

    また、

    echo $XDG_SESSION_TYPE
    

    は、

    wayland
    
    echo $WAYLAND_DISPLAY
    

    は、

    wayland-0
    

    となっていました。

    結果として、現在はリモート側で快適にUbuntuを操作できています。


    11.今回分かったこと

    今回のトラブルを通して、いくつか重要なことが分かりました。

    ① RDPが切断されたからといって、アップグレードが終了したとは限らない

    アップグレード中は、GNOMEやGDMなどの更新によってGUIセッションが切断されることがあります。

    そのため、

    RDPが切れた → アップグレード完了

    と判断するのは危険です。


    ② dpkg --auditは非常に有効だった

    今回、アップグレードが正常に終了しているかどうかを確認するために、

    sudo dpkg --audit
    

    を使用しました。

    大量の未設定パッケージが表示されたことで、アップグレードが完全には終了していないことが分かりました。

    復旧後に再度実行して何も表示されないことを確認することで、パッケージ管理上の状態を確認できました。


    ③ apt-get -f installで未完了の処理を継続できた

    今回の復旧では、

    sudo apt-get -f install
    

    によって、未設定だった大量のパッケージが順次設定されました。

    結果として、GNOMEを含むデスクトップ環境を正常な状態まで戻すことができました。


    ④ リモート環境では「接続が切れること」を前提にした方がよい

    今回もっとも勉強になったのは、この点です。

    OSのアップグレードをRDPだけに頼って実行すると、アップグレードによってRDPそのものが切断される可能性があります。

    今後、同じような作業を行う場合には、SSHやtmuxなど、GUIとは独立した方法でアップグレードの状態を確認できるようにしておく方が安全だと思います。


    12.今回のまとめ

    今回のトラブルは、

    「リモートデスクトップでUbuntuをアップグレードしていたところ、途中でRDPが切断され、アップグレードが完全に終了していない状態になっていた」

    ことから始まりました。

    その後、

    dpkg --audit
          ↓
    未設定パッケージを確認
          ↓
    apt-get -f install
          ↓
    パッケージ設定を完了
          ↓
    dpkg --audit
          ↓
    問題なし
          ↓
    再起動
          ↓
    Ubuntu 26.04.1 LTSを確認
          ↓
    system-wide RDPを有効化
          ↓
    ログイン前のRDP接続に成功
    

    という手順で復旧しました。

    今回の復旧では、ChatGPTに実際のターミナル画面の結果を一つずつ提示しながら、原因を切り分けていきました。

    「何となく操作して直す」のではなく、コマンドの結果を確認しながら次の操作を決めることが、今回の復旧につながったと思います。

    最終的には、Ubuntu 26.04.1 LTSへのアップグレードを完了し、さらに、

    「本体側でログインしていなくても、Windows PCからRDP接続してUbuntuへログインし、大画面で操作する」

    という当初の目的も達成することができました。


    おわりに

    今回の経験から、リモート環境でOSの大きなアップグレードを行う場合には、

    「リモート接続が切れる可能性をあらかじめ想定しておく」

    ことが重要だと感じました。

    また、トラブルが発生したときには、いきなり設定を変更するのではなく、

    sudo dpkg --audit
    

    などで現在の状態を確認し、その結果をもとに復旧作業を進めることが大切です。

    今回はChatGPTにも協力してもらいながら、最終的に無事復旧することができました。

    同じようにリモート環境からUbuntuをアップグレードする方の参考になればと思い、今回の顛末を記録として残しておきます。