--- title: "アップデート" description: "ThinkTerm がアップデートを確認・インストールする方法、インストール方法によって誰がファイルを置き換えるかが決まる理由、そしてリモートサーバーをセッションを終わらせずに更新する方法。" url: "https://docs.closex.org/ja/thinkterm/updates.html" markdown_url: "https://docs.closex.org/ja/thinkterm/updates.md" site: "CloseX Docs" product: "ThinkTerm" language: "ja" last_updated: "2026-11-08T12:04:16.000Z" alternates: en: "https://docs.closex.org/thinkterm/updates.md" zh-Hans: "https://docs.closex.org/zh/thinkterm/updates.md" ja: "https://docs.closex.org/ja/thinkterm/updates.md" --- # アップデート ThinkTerm が自動でアップデートをインストールすることはありません。確認し、知らせ、あとはあなたの判断を待ちます。 ## 確認する デスクトップアプリは動いているあいだ、GitHub に新しいリリースがないかを自分で確認します。起動からおよそ 10 秒後に、記録にある前回の確認が確認の頻度より古ければ確認し、その後は同じだけの時間が経つたびに確認します。コマンドラインツール、TUI、セッションサーバーが自分から確認することはありません。 これを決めるのは `設定 › ソフトウェアアップデート` の 2 つの行です。`アップデートを自動確認` はスイッチで、`確認の頻度` は `12 時間ごと`（既定）、`毎日`、`毎週` から選びます。スイッチがオフのあいだはグレーアウトします。変更は 1 分以内に反映されます。この 2 つの行を使うまでは、設定ファイルの `check_for_updates` と `check_for_updates_interval_seconds` に従います。両者の関係と確認のタイミングは、設定のページの [アップデートの確認](https://docs.closex.org/ja/thinkterm/configuration.md#the-update-check) を参照してください。 `設定 › ソフトウェアアップデート` には確認の結果が表示されます。実行中のバージョン、新しいリリースがわかっているかどうか、このコピーがどうインストールされたかです。 - 上部のボタンは、新しいリリースがわかっていて、このコピーが ThinkTerm の置き換えてよいものなら `アップデートをインストール`（その下に `アップデートを確認` が重なります）、それ以外では `アップデートを確認` だけです。`アップデートを確認` は `アップデートを自動確認` がオンかどうかにかかわらず、その場で GitHub に問い合わせます。リクエストの間、ボタンは `確認中…` と表示され、終わると少しのあいだ `確認しました` に変わり、上のカードに結果が表示されます。失敗するとカードに `アップデートを確認できませんでした。` と表示され、理由はその下に出ます。ターミナルからは、後述の `thinkterm update --check` が同じことをします。 - `最終確認` は読み取り専用です。アプリ自身が行ったものでも `アップデートを確認` で行ったものでも、記録にある直近の確認がいつ行われたかを示します。 - `新機能` は提示されているリリースのリリースノートをブラウザで開きます。提示されているものがなければ `すべてのリリースを見る` が一覧を開きます。 - `ダウンロード元` は、更新がリリースをどこから取得するかを決めます。このマシンとリモートサーバーの両方で使われます。既定の `自動` は GitHub から始め、GitHub が遅いかつながらないときはミラーに切り替えます。`GitHub(直接)` はミラーを使いません。特定のミラーを 1 つ選ぶこともできます。どこから取得しても、GitHub が記録したチェックサムと一致した場合だけインストールします。 新しいバージョンが見つかると、画面を占有するウィンドウではなく、ウィンドウの隅にカプセルが浮かびます。[アップデートのカプセル](#the-update-capsule) を参照してください。見つけたのが自動確認なら、あわせて通知も出ます——*ThinkTerm の新しいバージョンがあります*——クリックすると、そのリリースの GitHub のページがブラウザで開きます。`Check for Updates...`（macOS の ThinkTerm メニューとコマンドパレットにあり、名前は翻訳されません）は `設定 › ソフトウェアアップデート` を開きます。キーに割り当てた `CheckForUpdates` アクションも同じです。 リリースが新しいかどうかはバージョン番号で決まります。例外は同じ番号のときです。macOS でソースのチェックアウトから手でパッケージした `ThinkTerm.app` は、あとから公開されるリリースと同じバージョン番号を持っていることがあり、そのリリースはより新しいコードから作られています。この場合 ThinkTerm は、アプリの元になったコミットの時刻とリリースのコミットの時刻を比べ、より新しいコードから作られたリリースを `新しいビルドがあります` として知らせます。通知は *ThinkTerm の新しいビルドがあります*、`設定 › ソフトウェアアップデート` には `お使いのものより新しい ThinkTerm x.y.z のビルドがあります` と表示されます。リリースのコミット時刻を調べるために GitHub のコミット一覧への問い合わせが 1 回増えますが、それは一度だけで、保存した確認結果と一緒に残ります。正式なリリースのパッケージはこの方法で比較されないので、自分自身であるリリースを知らされることはありません。 その問い合わせを除けば、確認は GitHub のリリース API への 1 回のリクエストで、資格情報は載せません。自分で `THINKTERM_UPDATE_TOKEN` を設定した場合だけ読まれます。これは GitHub の匿名レート制限を外すためのもので、プライベートなフォークを見に行くときにも要ります。インストールスクリプトが受け取る `GITHUB_TOKEN` とは別の変数で、それは意図的です — ThinkTerm 自身のコードは `GITHUB_TOKEN` を読まないので、ほかのツールのために export したトークンが確認によって送られることはありません。アップデートが実行するインストールスクリプトはこれを読みますが、アーカイブを自分でダウンロードしなければならないときだけです。[インストールする](#installing) を参照してください。ThinkTerm がほかに何を送るかは [プライバシーとセキュリティ](https://docs.closex.org/ja/thinkterm/privacy.md) にまとめてあります。 ## インストールする {#installing} `アップデートをインストール` はファイルをその場で置き換えます。置き換えのあいだも目の前のウィンドウは使えますし、ThinkTerm は起動時のバージョンのまま動き続けます。 最後の点は誤解されやすいので、確認メッセージがはっきり伝えます。*ThinkTerm x.y.z をインストールしました。ThinkTerm を再起動すると新しいバージョンを使えます。* 実行中のセッションの下で勝手に切り替わることはありません。 見つかったリリースのあとに、さらに新しいリリースが出ていることがあり、古いほうを入れてもすぐ次のアップデートが必要になるだけです。そこで設定の `アップデートをインストール` とカプセルは、まず GitHub に最新のリリースをもう一度尋ね、それをインストールします。カードとカプセルもそのあとは新しいほうの名前を示します。この 2 度目の問い合わせが GitHub に届かないときは、提示されていたリリースをインストールします。 ページ上部のカードはインストールの進み具合を示します。まず `ThinkTerm x.y.z のインストールを準備中…` と表示され、そのあいだ ThinkTerm はインストールスクリプトを用意しています。次に進行状況バーと `63.1 MB / 80.0 MB · 79%` のような行を伴う `ThinkTerm x.y.z をダウンロード中…` が出て、ダウンロードが 1 秒続くと `残り約 12 秒` が加わります。そのあとが `ThinkTerm x.y.z をインストール中…` です。うまくいかなければ、カードに `アップデートをインストールできませんでした。` と表示され、理由がその下に出ます。インストーラーまで進んでいた場合は、インストーラーが出力した内容も添えられます。 ThinkTerm はアーカイブを自分でダウンロードし、インストールスクリプトに渡す前に、ファイルのアップロード時に GitHub が記録した SHA-256 と照合します。一致しないダウンロードは削除され、何もインストールされません。GitHub にそのアーカイブのチェックサムがない場合は、スクリプトが手で実行したときと同じように自分で取得して判断し、進行状況バーも出ません。 デスクトップアプリはシステムのプロキシ、または環境が指定するプロキシ（SOCKS を含む）を通して取得します。`thinkterm update` はシステムの `curl` で取得し、環境が指定するプロキシを使います。 インストールが終わると、カードに `ThinkTerm を再起動` が現れますが、再起動してもどの端末も終了しない場合に限られます。ThinkTerm 自身が動かすシェル — アプリ自身のプロセス内のもの、または直接の SSH 接続越しのもの — は一緒に終わり、セッションサーバーに置かれた端末は終わりません。前者のペインが 1 つでも開いていればボタンは出ず、都合のよいときに自分で ThinkTerm を終了して開き直します。Windows も同じです。インストーラーは ThinkTerm を終了させず、カードはインストーラーが終わるのを待ってから、同じ再起動のボタンを出します。 アップデートの前から動いていたセッションサーバーは、次に ThinkTerm が起動したときに新しいバージョンへ移されます。動いているサーバーがペインを新しいビルドに引き渡し、中の端末は動き続けます。起動したアプリより新しいサーバー — サーバーの更新で取り残されたアプリなど — はそのままにされ、そのウィンドウは自分の端末を使います。サーバーの中の端末は残っていて、ThinkTerm を更新すれば戻ってきます。代わりに設定でセッションサーバーを止めると、それらは終了します。 ## アップデートのカプセル {#the-update-capsule} 新しいリリースがわかっている間、各ウィンドウの端末領域の右下に、`アップデートがあります` とバージョンを書いた角丸のカプセルが浮かびます。このコピーが ThinkTerm の置き換えてよいものなら、クリックすると `アップデートをインストール` と同じことをします。それ以外のコピーでは `設定 › ソフトウェアアップデート` が開き、ファイルの持ち主が示されます。カプセルは、メニュー、コマンドパレット、ダイアログの邪魔にならないよう脇によけます。 そのあとカプセルは、カードの代わりにインストールを追います。まず `ダウンロード中` とパーセントが出て、アイコンの周りで進捗リングが回り、続いて `インストール中` になります。インストールが終わると、再起動してもターミナルが終了しない場合は `再起動してアップデート` と表示され、クリックすると ThinkTerm が再起動します。再起動するとターミナルが終了する場合は `アップデート済み` と表示され、クリックすると設定のページが開きます。インストールに失敗すると `アップデートに失敗` と `再試行` が表示され、クリックするともう一度試します。ダウンロードやインストールの間は、クリックしても何も起きません。 ポインタをカプセルに置くと、閉じるボタンが開きます。閉じると、カプセルはたたまれて、サイドバーの設定ボタンの上のドットへ飛んでいき、次の起動までそこに残ります。インストールに失敗したときはドットが赤くなり、その状態で設定ボタンを押すと、設定ではなく `設定 › ソフトウェアアップデート` が開きます。ダウンロード中にカプセルを閉じても、インストールは止まりません。 ## ファイルを置き換えてよいのは誰か ThinkTerm が更新するのは自分でインストールしたコピー、つまりインストールスクリプト経由のものだけです。それ以外のインストール方法にはそれぞれ持ち主がいます。パッケージマネージャー、Homebrew、Nix、AppImage 自身のアップデーター、あるいは `cargo build` を実行した本人です。そうした場合、ThinkTerm はファイルを上書きせず、持ち主を伝えます。 | このコピーのインストール方法 | ThinkTerm の動作 | |---|---| | インストールスクリプト | 同じ版を保ったままアップデートをインストール | | 手動で置いた `ThinkTerm.app` | その場所で置き換え、コマンドラインツールを `~/.local/bin` に追加 | | AppImage | AppImageUpdate、またはリリースページの新しい AppImage を案内 | | Homebrew | `brew upgrade thinkterm` の実行を案内。Homebrew の cask はここに入りません。cask は `ThinkTerm.app` を `/Applications` に置くので、アプリは手動で置いたものとして扱い、その場所で置き換えます | | Nix | Nix の設定から更新するよう案内 | | システムのパッケージマネージャー | `apt` や `dnf` など元の方法で新しいパッケージを入れるよう案内 | | Windows インストーラー | このマシンのアーキテクチャ向けの新しいインストーラーをダウンロードして実行 | | ソースからのビルド | リポジトリを更新して再ビルドするよう案内 | | 判別できない | 置き換えを拒否し、元の方法で更新するよう案内 | ファイルを置き換えない場合、`thinkterm update` は主体を示すだけで終わりません。macOS と Linux では逃げ道も表示します — インストールスクリプトを一度実行すれば、そのマシンはスクリプト管理のインストールになり、以後の更新はボタンかコマンドで済みます。またインストーラーが動いたうえでそのマシンを拒んだとき（glibc が古い、musl、対応するアーキテクチャのビルドがない）は、理由のない失敗ではなくそのことを伝え、そのリリースをソースからビルドするコマンドも示します。 ## コマンドラインから `thinkterm update` は設定画面のボタンとまったく同じ規則に従います。 ```bash thinkterm update # 確認し、インストール前に尋ねる thinkterm update --check # 新しいリリースの有無を報告するだけで、インストールしない thinkterm update -y # 確認せずにインストール thinkterm update --version X # 最新版ではなくリリース X をインストール（ダウングレードも可） ``` どちらの経路もインストーラーを実装し直してはいません。リリースのアーカイブを先にダウンロードして [インストールする](#installing) に書いた方法で検証し、そのうえで処理を `install.sh` に渡します。アーカイブの構成と、デスクトップ版・サーバー版の切り替えを把握しているのはこのスクリプトだけだからです。ThinkTerm がダウンロードしたアーカイブは `--from` で渡され、`--version` と、そのインストールを作った `--prefix` が添えられます。スクリプトはインストール対象のリリースからではなく、デフォルトブランチから取得されます。こうすることで、インストーラーの修正が次のリリースを待たずに既存のすべてのインストールへ届きます。Windows にはインストールスクリプトがないため、どちらの経路も新しいインストーラーをダウンロードして実行します。 `thinkterm update` はスクリプトの出力をそのまま端末に流すので、サーバー版のインストールではスクリプト自身の引き渡しが働きます。動いている mux サーバーがセッションを新しいビルドに渡す仕組みは、[アップグレードとアンインストール](https://docs.closex.org/ja/thinkterm/install.md#upgrading-and-removing) で説明しています。設定の `アップデートをインストール` はスクリプトの出力を取り込む方式で、デスクトップアプリは次に起動したときに自分のセッションサーバーを引き渡します。 ## リモートサーバーを更新する {#updating-a-remote-server} クライアントとサーバーはプロトコルが変わると通信できなくなります。よくあるのは、デスクトップ側を更新した一方で、どこかのホストのサーバーが先月のビルドのまま動いているという状況です。 ThinkTerm はそのホストへの SSH セッションをすでに持っているため、あなたに手動ログインを強いる代わりに、自分で不一致を修復できます。attach 時にバージョン不一致を検出すると、まず双方がどのバージョンで動いているかを伝え、そのあとの動きはホストによって決まります。 直せない不一致もあり、何かを尋ねる前にそう伝えます。そのうち 2 つは、あなた自身の設定からわかります。ドメインが ThinkTerm を固定のパスから実行するよう設定されている場合と、クライアント自身が対応するリリースのない開発ビルドである場合です。3 つ目は、サーバーがこのクライアントより新しい場合です。そのサーバーは古いビルドにセッションを引き渡さないため、何も変えずにそのままにされ、代わりにこちらの ThinkTerm を更新するよう案内が出ます。 そうでなければ、ThinkTerm はホストへの SSH セッションを開き、そこに何が入っているかを読みます。この時点では GitHub に何も要求しておらず、ホストも何も変わっていません。ホストの glibc が、そこに入るバリアントには古すぎる（サーバー版は 2.31 未満、デスクトップ版は 2.35 未満）、musl を使っている、そのアーキテクチャのリリースがない、といった場合は、この段階で、質問の前に、ソースからビルドする方法とともに伝えます。glibc 2.31 から 2.33 のホストには、OpenSSL を組み込んだサーバービルドが入ります。どのバリアントを入れるかは、ホストにあるものに合わせます。そこにデスクトップ版のインストールがあれば GUI は保たれ、Linux ではディストリビューションのパッケージのデスクトップアプリ（インストール記録を残さないもの）も同じです。その場合は `~/.local` の下にデスクトップ版が入り、ランチャーは新しいインストールに移り、アプリとサーバーは同じバージョンに揃います。ホストの glibc がデスクトップ版には古すぎる場合は、サーバーだけが更新され、アプリは元のバージョンのままだと質問の中で伝えます。ホスト上の macOS アプリのバンドルは、自分で更新するので触りません。 そのあと、質問は 1 回だけです。質問には、どのバージョンをどのバリアントでホストに入れるか、SSH ユーザーとして `~/.local` の下に root なしで入れること、SSH で何が送られるか、そしてデスクトップアプリのように一緒に変わるものが書かれています。未コミットのソース変更を含んでビルドされたクライアントは、それだけでは拒否されません。質問に、リリース版がそれと合わないままかもしれないという警告が付きます。`n` と答えれば、どこも変更されません。ThinkTerm はホストで自分で実行するためのコマンドを表示します。 yes と答えて初めて、ThinkTerm は GitHub に行ってそのリリースを調べます。これはこのクライアントが動かしているバージョンで、最新版とは限りません。照会に失敗すると `Could not resolve release x.y.z` と理由を伝えて止まります。成功すれば、SSH セッションでインストールスクリプトとそのリリースのチェックサムをホストに送り、アーカイブはホスト自身がダウンロードします。ダウンロードは ThinkTerm を経由しません。スクリプトは、4 秒以内に検証できればオンラインで取得した署名つきのコピーで、できなければ ThinkTerm に組み込まれたコピーです。検証されていないものが実行されることはありません。`ダウンロード元` の設定も適用されるので、GitHub が遅ければ [インストール](https://docs.closex.org/ja/thinkterm/install.md#the-install-script) で説明しているとおりミラーに切り替わります。インストーラーの出力は、ダウンロードのバイト数と速度とともに、接続ウィンドウへ中継されます。 そのあと実行中のセッションがどうなるかは、同じ `設定 › ソフトウェアアップデート` のページにある次の設定で決まります。既定はオンです。 **`リモートサーバー更新時にセッションを維持`** —— *実行中のサーバーは停止せず、ペインを新しいバージョンに引き継ぎます。実行中の処理は中断されません。* 引き渡しが途中で失敗したときは、最大 3 回まで再試行します。ペインを引き渡せないほど古いサーバーは、次の確認に戻ります。オフの場合、ThinkTerm は古いサーバーを停止する前に確認します。停止するとそのサーバーが保持しているセッションはすべて終わるからです。これが無断で行われることはなく、断れば古いサーバーは、あなたが止めて接続し直すまで動き続けます。 引き継ぎ自体は [リモート](https://docs.closex.org/ja/thinkterm/remote.md) で説明している仕組みと同じです。実行中のサーバーがペインを新しいバイナリへ渡し、セッション側はそれに気づきません。 ## 関連 - [リモート](https://docs.closex.org/ja/thinkterm/remote.md) —— 切断・再起動・更新をまたいでセッションが残る仕組み - [コマンドライン](https://docs.closex.org/ja/thinkterm/cli.md) —— `thinkterm` のその他のサブコマンド - [インストール](https://docs.closex.org/ja/thinkterm/install.md) —— すべての更新が実行するインストールスクリプト