製品概要

TightVNC は、標準 VNC（RFB）プロトコルに互換のリモートデスクトップソフトウェアです。ネットワーク越しに Windows コンピューターの画面を表示し、操作できます。いわゆる “VNC の基本モデル” に沿って、管理対象側に TightVNC Server、操作側に TightVNC Viewer を配置して運用します。

自己ホスト型での運用を前提に、標準プロトコル互換（相互運用性）と、運用・展開に必要な機能（サービス動作、MSI 展開、権限分離など）を重視した構成を取りやすい点が特徴です。

コンポーネント構成

• TightVNC Server（Windows）
  管理対象（エンドポイント／サーバー）で稼働し、画面共有とリモート操作を提供します。
• TightVNC Viewer（Windows）
  管理者・サポート担当端末側で稼働し、Server に接続して画面表示／操作を行います。
• TightVNC Java Viewer
  Java 環境で動作するクライアント。環境によってはブラウザ経由（Java アプレット）での利用も想定されます。

互換性と標準プロトコル（VNC/RFB）

TightVNC は VNC の標準である RFB プロトコルに互換で、混在環境での相互運用を前提に利用できます。

• TightVNC Viewer で、一般的な VNC サーバーへ接続できる
• 一般的な VNC ビューアで、TightVNC Server へ接続できる

また、TightVNC 独自の拡張（後述の Tight エンコーディングなど）は、接続の両端が対応している場合に効果を発揮します。

主要機能

1) 高効率な画面転送：Tight エンコーディング（JPEG 圧縮オプション）

TightVNC は “標準的な VNC” と比較して、帯域効率を意識した Tight エンコーディングを備えます。必要に応じて JPEG 圧縮を用い、低〜中速回線でのトラフィック削減と操作性向上を狙えます。圧縮レベルや JPEG 品質といった調整により、CPU 負荷と通信量のバランスをとる運用が可能です。

2) デスクトップ・スケーリング（拡大縮小）

• Windows Viewer
• Java Viewer

でスケーリングに対応し、小さな画面で全体を見たい場合や、詳細確認のために拡大したい場合に有効です。

3) ファイル転送（Windows 版）

Windows 版では、リモートセッション中にファイル転送（アップロード／ダウンロード）を行えます。ログ収集やツール配布など、運用手順に組み込みやすい機能です（組織のルールに沿った利用が前提となります）。

4) 権限分離：フルコントロール／読み取り専用（Read-only）

TightVNC Server は 2 種類のパスワードを設定でき、接続時に使用したパスワードに応じて操作権限を分離できます。

• フルコントロール：キーボード／マウス操作を含む遠隔操作
• 読み取り専用：画面閲覧のみ（入力イベントを許可しない）

監視と操作を分けたい運用（監視→承認後に操作、など）に適しています。

5) Web 経由アクセス（Java Viewer 配信）

TightVNC Server には Java Viewer を配信するための小規模な Web 機能があり、ブラウザ接続で Java Viewer を利用する構成が想定されています。利用には Java アプレット対応など、クライアント環境側の条件を満たす必要があります。

対応 OS と動作特性

Windows 環境での利用を前提に、幅広い Windows バージョンでの運用が想定されています（クライアント／サーバー双方）。また、一般的な運用では常駐プロセスとして軽量に動作する設計が志向され、ディスク容量やメモリ消費を抑えた利用が可能です。

サーバー動作モード（アプリケーション／サービス）

Windows の TightVNC Server は、運用要件に応じて主に次の 2 モードで動作します。

• アプリケーションモード
  ログオン中ユーザーのセッションで動作し、ログアウトで停止する形になりやすいモード。
• サービスモード
  OS のサービスとしてバックグラウンド稼働し、再起動後も自動起動できるモード。
  無人運用（再起動後の再接続、ログオン前の管理など）を重視する場合に適しています。

ネットワーク要件（ポートと接続の考え方）

一般的な VNC の挙動に従い、Viewer から Server へ TCP 接続します。代表的な既定値として、以下のポートがよく使われます。

• RFB（VNC 接続）：5900（既定）
• HTTP（Java Viewer 配信）：5800（既定）

ルーター配下やセグメント環境では、必要な経路のみを許可する設計（許可元の限定、FW 制御、管理ネットワーク経由など）が重要です。

セキュリティ設計のポイント

TightVNC は、VNC パスワード交換の保護は行われますが、セッション全体の通信が常に暗号化される設計ではありません。そのため、信頼できないネットワークをまたぐ利用では、暗号化された経路を別途確保する必要があります。

代表例として SSH トンネリングによる保護が挙げられます。加えて、運用設計としては以下のような基本統制が重要になります。

• ネットワーク分離と到達性制御：管理ネットワーク／踏み台経由／許可元の限定
• 認証情報の統制：強固なパスワード設計、読み取り専用とフルコントロールの使い分け
• 露出面の最小化：インターネットへの直接公開を避ける、FW で閉域化する
• 運用統制：変更管理、監査、手順化（必要な範囲で）

導入と展開（MSI・サイレント導入・事前設定）

Windows 向け TightVNC は MSI で提供され、無人導入（サイレントインストール）に対応します。代表的な展開要件に対し、次のような設計が可能です。

• サイレント導入：「msiexec」 を用いた無人インストール
• コンポーネント選択：Server のみ／Viewer のみ／両方
• インストール時のオプション指定：サービス登録、ファイアウォール例外、SAS（Ctrl-Alt-Del）関連など
• 事前設定：インストール時に構成値を設定できる仕組み（プロパティ指定）により、初期設定の標準化をしやすい

※実際に利用できる MSI プロパティや挙動は、導入対象のリリース／パッケージにより異なる場合があります。

運用と自動化（コマンドライン）

展開後の運用では、コマンドラインによる制御が役立ちます。代表例として以下の用途が挙げられます。

• サービスとしての登録、開始／停止
• サービスモード／アプリケーションモードの切り替え・制御
• 構成画面の呼び出しや運用作業の手順化
• 特定の画面・領域共有など、限定的な共有要件への対応

GUI 操作に依存しない運用は、標準手順や自動化（運用スクリプト、ジョブ化）に組み込みやすくなります。

製品ラインアップと商用ライセンス領域

TightVNC は、Windows の Server/Viewer だけでなく、組み込みやクロスプラットフォーム要件に対応する商用ライセンス領域を持ちます（用途に応じて選択）。

1) TightVNC Server for Windows：商用ソースコードライセンス

自社製品への組み込み、カスタマイズ、再配布などを想定する場合、商用のソースコードライセンスを選択できます。開発期間やコストを抑えつつ、既存の実装をベースに統合できる点がポイントです。

2) Remote Core SDK（.NET Viewer SDK）

.NET 向けに、Viewer 機能をライブラリ／コンポーネントとして提供する SDK です。

• .NET 3.5 以上（4.0 以上推奨とされるケースあり）
• WinForms／WPF に対応
• シンプルな API で統合しやすい GUI コンポーネントを提供
• RFB 互換に加え、Tight 系の圧縮アルゴリズム／拡張への対応が想定される

既存アプリにリモート閲覧機能を組み込む、専用 UI／ワークフローで遠隔操作を提供する、といった要件に適します。

3) Server for Unix/Linux/X11（商用ソースコードライセンス）

Unix/Linux/X11 向けのサーバー実装として、TightVNC 2.0 系をベースにした共通コードベースを採用する構成が提示されています。機能例：

• ファイル転送
• アクセスリスト
• 追加ポート
• 組み込み Web サーバー
• JavaScript クライアント（例：noVNC）向けの WebSocket 対応
• HTTPS／WebSocket Secure（WSS） によるチャネル暗号化に対応する構成（追加ソフトウェアなしでの暗号化を想定）

4) Server for macOS（商用ソースコードライセンス）

macOS 向けは、一般的な “ダウンロードしてすぐ使う” 形式ではなく、商用のソースコード提供として位置づけられます。特徴例：

• TightVNC 2.0 系をベースにした共通コードベース
• Tight エンコーディング（JPEG 圧縮を含む）などのエンコーダー対応が想定される
• SDK やバイナリ提供ではなく、ソースコードライセンスとしての提供を想定

5) 追加コンポーネント（パフォーマンス／互換性拡張）

• DFMirage（ミラードライバー）：Windows 環境での画面更新検出効率を高め、パフォーマンスや CPU 使用率の改善を狙う用途で言及されることがあります。
• Pure C Tight Decoder：C/C++ ベースの VNC クライアントへ Tight/JPEG 系エンコーディングの対応を追加する目的で扱われるコンポーネントです。

代表的な利用シーン

• Windows エンドポイントのリモートサポート
  組織内の標準 Viewer を用いた遠隔操作／画面共有。ファイル転送やスケーリングが運用に有効。
• Windows サーバーの運用管理
  サービスモードによる無人稼働を前提に、再起動後の管理性や運用手順化を重視するケース。
• 回線が細い拠点・分散環境の支援
  Tight エンコーディングや圧縮設定で、帯域制約のある環境でも操作性を維持しやすい。
• 監視優先（読み取り専用）→必要時に操作
  まず閲覧のみで状況確認し、承認後にフルコントロールへ移行する運用。
• アプリへの組み込み／専用クライアント開発
  .NET SDK や商用ソースコードライセンスを用い、独自 UI や業務ワークフローに統合するケース。
• クロスプラットフォーム要件（Unix/Linux/macOS 側サーバー）
  商用ソースコード提供により、各 OS でのサーバー実装・統合を進めたいケース。

他製品との位置づけ

クラウド中継型のリモートサポート製品

“どこからでも簡単接続” を重視し、ベンダーの中継や独自セッション層を持つカテゴリがあります。
TightVNC は、標準プロトコル互換・自己ホスト運用に寄せた設計を取りやすい一方で、暗号化経路の確保や到達性制御などはネットワーク設計側で担う考え方が基本になります。

OS ネイティブのリモート機能（特定 OS 依存の方式）

特定 OS に最適化された方式は、環境によっては運用が容易です。一方で、VNC/RFB 互換が必要な機器・ソフトウェアが混在する場合、VNC 互換クライアント／サーバーの採用が運用上の整合を取りやすくなります。

他の VNC 実装

VNC 系は実装ごとに、圧縮方式、配布形態、運用機能（展開・権限分離・Web アクセス等）に差があります。TightVNC は、Tight エンコーディングやスケーリング、Windows のファイル転送、MSI 展開・サービス運用といった要素で、運用性と帯域効率を重視した整理がしやすい構成です。

Q&A（よくある質問）

Q1. TightVNC はどのような構成で使いますか？

A. 基本は 2 コンポーネント構成です。管理対象側に Server、操作側に Viewer を配置して接続します。

Q2. 標準 VNC（RFB）と互換ですか？

A. はい。RFB 互換のため、混在環境でも相互接続しやすい設計です。なお、Tight などの拡張は両端が対応している場合に効果を発揮します。

Q3. “Tight エンコーディング” とは何ですか？

A. 画面転送の圧縮方式（エンコーディング）で、回線が細い／遅い環境でも通信量を抑えやすい点が特徴です。JPEG 圧縮を使う運用も想定され、圧縮率と CPU 負荷のバランスを調整できます。

Q4. スケーリング（拡大縮小）はできますか？

A. Windows Viewer と Java Viewer でスケーリングに対応します。小さな画面で全体を見たい場合や、細部確認で拡大したい場合に有効です。

Q5. ファイル転送は可能ですか？

A. Windows 版では、セッション中のファイル転送（アップロード／ダウンロード）に対応します。

Q6. “読み取り専用” と “フルコントロール” を分けられますか？

A. はい。Server 側でフルコントロール用と読み取り専用用の 2 種類のパスワードを設定し、接続時の権限を分離できます。

Q7. Server を Windows サービスとして常駐できますか？

A. はい。サービスモードでバックグラウンド稼働させ、再起動後の自動起動など無人運用に向く構成にできます。

Q8. ログオン前（ユーザー未ログイン）でも使えますか？

A. サービスモード運用を前提に、ログオン状態に依存しない到達性・継続性を設計しやすくなります（環境・権限制御は運用設計に依存します）。

Q9. 既定のポートは何ですか？ 変更できますか？

A. 一般的に RFB は 5900、Java Viewer 配信（HTTP）は 5800 が既定として扱われます。運用要件に応じてポートや到達経路の設計（制限／変更）を行うのが一般的です。

Q10. 通信は暗号化されますか？

A. パスワード交換の保護はありますが、セッション全体を常に暗号化する設計ではありません。信頼できないネットワークをまたぐ場合は、暗号化された経路（例：SSH トンネリング等）を別途用意する前提で設計します。

Q11. MSI でのサイレント導入や一括展開はできますか？

A. MSI での展開が想定され、サイレント導入（「msiexec」）や、Server／Viewer の導入選択、サービス登録などの自動化が可能な構成です。

Q12. インストール時に設定を“事前投入”できますか？

A. MSI プロパティ等を用いて、初期設定の標準化（例：特定オプションの有効／無効、挙動の統一）を行える設計が想定されます。利用できる項目は配布パッケージ（リリース）に依存します。

Q13. 運用自動化（サービス開始／停止など）はできますか？

A. コマンドラインでの制御（サービス登録、開始／停止、モード制御など）を運用手順に組み込みやすい構成です。

Q14. 商用ライセンスが関係するのはどんな場合ですか？

A. 自社製品への組み込み、ソースコードベースの統合、再配布を伴う開発用途、あるいは SDK を用いたアプリ組み込みなど、開発・組み込み要件がある場合に商用ライセンス領域が関係します。

Q15. .NET Viewer SDK（Remote Core SDK）で何ができますか？

A. Viewer 機能を .NET（WinForms／WPF）アプリに組み込み、独自 UI／ワークフローでリモート画面表示・操作を提供する用途に向きます。

Q16. Unix/Linux/macOS 向けサーバーはどう扱われますか？

A. これらは一般的な “バイナリ配布で導入” というより、商用のソースコードライセンスとして位置づけられる整理がしやすく、要件に応じてコード統合・機能実装を行う前提の選択肢になります。

まとめ

TightVNC は、VNC/RFB 互換をベースに、自己ホスト型の運用を組み立てやすいリモートデスクトップソリューションです。
Windows 環境では、サービス動作や MSI による展開自動化、読み取り専用／フルコントロールの権限分離、Tight エンコーディングや スケーリング、（Windows 版の）ファイル転送といった機能を組み合わせ、企業内の運用要件に合わせた設計が可能です。

また、組み込みやクロスプラットフォーム要件に対しては、商用ソースコードライセンスや .NET 向け SDK、Unix/Linux/macOS 向けサーバーなど、用途別の商用ライセンス領域を選択できる点がポイントになります。