（掲載 2026年10月24日）
Qt 5 で動いているアプリケーションを Qt 6 に移行するとき、最初に決めたいのは「どの API を書き換えるか」よりも、「移行後にどのような状態を実現したいか」です。現在の機能を維持して保守を続けたいのか、画面の応答性を改善したいのか、新しい OS や機器に対応したいのか。この違いによって、変更範囲も試験内容も変わります。
本記事では、Qt 5 を利用するアプリケーションの開発者と移行計画の担当者に向けて、移行先の選び方、変更範囲の決め方、段階的な進め方を説明します。そのうえで、既存システムの調査、試験移行、見積もり、完了判定を具体化します。
基にしたのは、SRA が 2025 年 1 月 23 日に開催したセミナーの公開動画「そろそろ Qt 6？ ～ Qt 5 から Qt 6 への最適な移行戦略とは？ ～」です。第 1～7 節では動画の論点を独自の文章で解説し、必要な補足を加えています。第 8～12 節の作業表・計画例・チェックリストは、本記事で追加した実務上の提案です。
動画は当時の Qt 5.6、5.15、6.5、6.8 を比較しています。そこで示された保守期限や採用製品の状況は当時の情報として扱います。本記事の技術的な補足は、2026 年 10 月 24 日に確認した Qt 公式文書を参照しています。Qt 6.12 の文書を参照している箇所も、すべての Qt 6 にそのまま適用できるという意味ではありません。
1. なぜ移行するのかを、製品の要件から考える
動画では、Qt 5 の長期利用と Qt 6 の成熟を背景に、移行を検討する時期に来ていると説明しています。ここで製品ごとに整理したいのは、次の三つです。
| 判断すること |
確認する内容 |
計画への影響 |
| 今後も維持する環境 |
対象 OS、CPU、機器、必要な運用期間 |
移行先の Qt と開発ツール一式（ツールチェイン）の候補が決まる |
| 現在困っていること |
修正の入手、OS 更新への追従、性能、保守負担 |
移行の目的と優先順位が決まる |
| 今回変えること |
動作維持のみか、機能追加や設計改善まで含めるか |
工数と完了条件が決まる |
たとえば「次期 OS でも現在の操作を提供する」と「一覧画面の表示を速くする」は、別の成果です。前者には互換性確認が、後者には原因調査と移行前後の測定が必要です。両方を目標にする場合も、合否は別々に判定できるようにします。
セキュリティも、Qt の版番号だけで判断しません。利用するモジュールに関係する修正を入手できるか、製品に適用できるか、修正後の試験を継続できるかまで含めて考えます。新しい版を導入しても、その後の更新が止まれば保守上の課題は残ります。
保守計画には、修正の入手先、入手できる期間、製品への適用担当を記載します。
2. Qt 5 と Qt 6 の違いを、移行への影響で読む
動画はセキュリティ、ライセンス、機能、性能の観点から比較しています。移行作業では、それぞれを「自分たちのアプリケーションの何に影響するか」に置き換えて読むと役立ちます。
開発環境と C++ の前提が変わる
Qt 6 は C++17 以降に対応するコンパイラを必要とします。ただし、C++17 に対応していれば、どのコンパイラでもすべての Qt 6 を利用できるわけではありません。採用する Qt の版に対して、OS、コンパイラ、SDK（対象環境向けの開発キット）の組合せを確認します。Qt の CMake 入門と対応プラットフォームが確認の入口になります。
組込み製品では、アプリケーションのソースを直す前に、BSP、クロスコンパイラ、GPU ドライバ、外部ライブラリが候補の環境にそろうかを調べます。BSP は対象ボードで OS や周辺機器を動かすためのソフトウェア一式、クロスコンパイラは開発 PC とは異なる実機向けのプログラムを作るコンパイラです。開発 PC での成功と実機での成立は分けて扱います。
動画では、描画 API の抽象化によるプラットフォームへの対応を紹介しています。Qt Quick の移行では、OpenGL が常に既定の描画 API であるとは仮定できません。独自の描画処理やシェーダーを使っている場合は、標準部品だけの画面とは別に移行課題を確認します。Qt Quick の変更点
公式移行ガイドは、Widgets のグラフィックスバックエンドについて Qt 5 から変更していないと説明しています。Widgets と Quick の混在、独自 OpenGL 描画、高 DPI の影響など、自分たちが利用している部分を切り分けて調べます。公式移行ガイド
モジュールの変更は、名前の置換だけでは済まない
動画では、Qt Graphs、Qt Multimedia、Qt WebEngine、Core・QML・Quick 内部の変更を取り上げています。新しいモジュールの存在を知ることと、既存コードを置き換えられることは別です。
Qt Graphs は、2D・3D のデータをグラフで可視化するモジュールです。たとえばセンサー値を折れ線で表示したり、立体的なデータを散布図や曲面で表示したりします。Qt Charts や Qt Data Visualization からの移行では、使用中のグラフ種別、軸、操作、画面への組込み方法を洗い出し、対応する API と比較します。公式文書には両モジュールからの移行ガイドへの入口があります。Qt Graphs
Qt Multimedia では、録音・録画を構成する API が変更され、削除された機能もあります。利用中の再生・録画・デバイス選択を列挙してから、それぞれの代替手段を確認すると、単なるビルド修正で済む部分と、処理構成を変更する部分を分けられます。Qt Multimedia の変更点
Qt WebEngine を使用する場合も、ブラウザーエンジンの更新を版番号の比較だけで終わらせず、実際に表示するページ、認証、ファイル操作などを試験対象にします。アプリケーションの画面が起動しただけでは、埋込みブラウザーを使う業務の成立までは分かりません。
性能改善には、変更せずに得られる効果と追加作業が必要な効果がある
ライブラリ内部の変更による効果と、新しい API やコンパイル機能を使って得る効果を分けます。動画で紹介された技術の役割を、公式文書に基づいて補足すると次のようになります。
| 技術 |
何をするものか |
移行時に検討すること |
| C++ のバインド可能なプロパティ |
値どうしの依存関係を表し、依存先の変更に応じて値を更新する |
手作業の更新処理を整理できる箇所を選ぶ |
| qmltc（QML 型コンパイラ） |
QML の型から C++ クラスを生成する |
生成クラスを利用する C++ 側の変更と、扱える QML 機能の範囲を確認する |
| qmlcachegen／qmlsc（QML スクリプトのコンパイル） |
バインディングや関数を事前にバイトコードや、変換可能な部分では C++ にする |
ビルド設定と導入済みツールに応じた処理を確認し、起動や実行時間を測る |
プロパティバインディングは、たとえば「合計金額は単価×数量」という関係を表す仕組みです。QML では以前から使われていました。Qt 6 の C++ では QProperty などを使い、依存する値が変わったときの更新を記述できます。通常の C++ 変数を式に使うだけでは変更が自動追跡されないため、関係する値もバインド可能なプロパティとして設計します。主な利点は更新処理の整理であり、速度向上は別に測定します。Qt Bindable Properties
Qt Quick Compiler 関連では、型を生成する qmltc と、式や関数を処理する qmlcachegen／qmlsc を分けて理解すると、変更範囲が見えます。qt_add_qml_module() を使う構成ではスクリプトのコンパイルがビルドに組み込まれ、Qt Quick Compiler Extensions が導入されている場合は qmlsc が qmlcachegen に代わって使われます。すべての JavaScript が C++ に変換されるわけではありません。Qt Quick Compiler
また、処理時間の大半を通信やファイルの読み込みが占めていれば、描画部分の改善だけで全体の待ち時間が大きく縮むとは限りません。「Qt 6 なら必ず高速になる」「最小限の移行では一切性能が改善しない」という、どちらの前提も置かずに測定します。
ライセンスは、利用するモジュール単位で確認する
動画は、古い Qt から移行するときにライセンス条件も確認する必要があると指摘しています。
公式のライセンス案内でも、OSS 版のすべてのモジュールが LGPL で提供されるわけではないこと、第三者コードには個別の条件があることが示されています。利用する Qt の版、モジュール、配布形態を確定し、その構成に対する条件を確認します。Qt Licensing
3. 採用事例から、どこまで判断できるか
動画の 13 分 51 秒以降では、デスクトップ向けの Qt アプリケーション 13 件を調べた結果を説明しています。公開情報だけでなく、実際にインストールしたバイナリーも確認した調査です。スライドには Maya、AutoCAD、KDE、Krita、MuseScore、Scribus、VirtualBox、Wireshark などが挙げられています。
当時は Qt 5 と Qt 6 が混在し、Qt 5 を使うプロジェクトでも Qt 6 対応が進んでいる、という説明でした。ただし、この対象製品の傾向を、そのまま Qt 全体の採用率や現在の市場状況とは扱えません。組込み分野について述べられた今後の移行増加も、当時の見通しです。
自分たちの計画に活かすなら、採用件数よりも構成の近い事例を探します。同じ OS、同じ画面技術、同じ主要モジュールを利用する製品の情報は、調査対象を絞る手がかりになります。一方で、別製品の移行成功から自社製品の必要工数を直接見積もることはできません。
4. 移行先の Qt は、必要な機能と動作条件を合わせて選ぶ
動画では、必要とする機能・性能と、使用できるツールチェインから移行先を選ぶと説明しています。新しい版の採用だけを先に決めると、あとから OS や機器の制約が見つかり、計画をやり直すことがあります。
動画で Qt 6.5 と Qt 6.8 を比較した理由
字幕の 07:56～08:28 では、当時の最新 LTS だった Qt 6.8 と、その一つ前の LTS である Qt 6.5 を取り上げた理由を説明しています。LTS は Long-Term Support（長期サポート）の略です。長期間の保守を計画するときの候補になりますが、実際の提供期間や修正の入手条件は契約・配布形態に応じて確認します。
講演では、Qt 6.8 の稼働条件を組込み環境が満たせず、Qt 6.5 を選ぶ場合があると説明しています。この例から得られる判断軸は、「必要な機能があるか」と「その版を支える実機・開発環境を用意できるか」の両方です。現在の計画でも、候補の版の対応条件と機器ベンダーの提供する環境を照合します。
候補ごとに、採用できる理由を記録する
本記事では、候補ごとに次の比較表を作ることを勧めます。
| 比較軸 |
記録する内容 |
| 製品の機能 |
必須モジュールと API、必要な変更・代替手段 |
| 動作環境 |
OS、CPU、コンパイラ、SDK、BSP、描画環境 |
| 周辺部品 |
外部ライブラリ、ドライバ、独自プラグインの対応状況 |
| 継続保守 |
製品の運用期間、修正の入手方法、更新時の試験体制 |
| 配布条件 |
モジュールごとのライセンス、契約、配布物の構成 |
候補を選ぶ段階では「不明」も残して構いません。ただし、不明点を対応済みとみなさず、確認方法と担当者を記録します。Qt 公式の対応構成に載っていることと、未掲載の環境で独自に動作を確認できたことも区別します。対応プラットフォーム
5. 移行方針を、動作維持と機能活用に分ける
動画の中心となるのが、変更を抑えて Qt 6 で動かす方針と、Qt 6 の機能を積極的に使う方針の比較です。
| 方針 |
今回の主な成果 |
作業範囲の考え方 |
| 動作維持を優先する |
合意した既存機能を Qt 6 で提供できる |
必須の互換性修正を優先し、任意の設計変更を抑える |
| 機能・性能の改善も行う |
動作維持に加え、測定可能な改善を実現する |
新しい API、モジュール、ビルド方式などの活用も評価する |
| 段階的に進める |
先に動作を成立させ、その後に改善する |
各段階の差分と完了条件を分離する |
互換モジュールで変更範囲を抑える
Qt 5 Core Compat は、Qt 6 の Qt Core から削除された一部の Qt 5 API を利用するためのモジュールです。既存コードを段階的に移行する際の選択肢になります。Qt 5 Core Compatibility APIs
対象は個別の API であり、アプリケーション全体の互換性を保証するものではありません。たとえば QStringRef は互換モジュールに残っていますが、それを返していた QString::leftRef() などは Qt 6 の QString にはありません。互換モジュールを追加しても、その呼出し箇所は修正が必要です。
読み取り専用の部分文字列で、text の長さが 4 以上と分かっている場合は、text.leftRef(4) を QStringView{text}.first(4) のような式へ移すことが候補になります。短い文字列も受け付ける処理では、切り出す長さを元の文字列の範囲内に収める必要があります。QStringView は元の文字列を所有しないため、使用中は元の text を生存させ、参照を無効にする変更を避けます。クラス名だけでなく、引数の条件とデータの寿命まで確認する例です。QStringView::first()、Qt Core の変更点
採用する場合は、利用箇所と理由を記録します。将来置き換える予定なのか、その構成を継続保守するのかを決めておくと、後から移行途中の状態と誤解されずに済みます。
段階を分けると、問題の原因を追いやすい
移行と同時に画面設計やデータ処理まで変更すると、不具合の原因が Qt の変更なのか、独自の修正なのかを見分けにくくなります。
たとえば第 1 段階で既存画面とファイル入出力の互換性を成立させ、第 2 段階で遅い画面の処理を改善します。それぞれに試験結果を残せば、改善が期待どおりでなかった場合も、動作が確認できている地点に戻って判断できます。段階を分ける分だけ評価の手間は増えるため、変更の大きさと切り分けの必要性から選びます。
6. Qt 5 のうちに準備し、Qt 5.15 を経由するかを決める
動画では、古い Qt 5 から一度に Qt 6 へ移行する負担を考慮し、時間とコストを踏まえて Qt 5.15 を経由する案を説明しています。公式移行ガイドも、Qt 5.15 に更新したうえで Qt 6 に進む流れを案内しています。公式移行ガイド
これは、すべてのアプリケーションで経由しなければ技術的に移行できないという意味ではありません。経由する利点は、Qt 5 内の整理と Qt 6 固有の変更を分離しやすいことです。反対に、中間環境の構築と試験にも費用がかかります。現在の Qt の版、既存試験の充実度、変更量を材料に判断します。
Qt 5 上で進められる変更を先に行う
動画では、Qt Quick Controls 1 から 2、Qt WebKit から Qt WebEngine への変更を例にしています。これらは名称の置換ではなく、画面や処理の見直しを伴い得る変更です。Qt 5 上で対応可能な構成なら、先に変更して動作を確認すると、Qt 6 移行時の問題を絞れます。
ほかにも、ビルド警告の整理、使用していない依存関係の除去、外部ライブラリの対応確認などを先行できます。ただし、変更を一度にまとめず、従来と同じ動作を確認できる単位に区切ります。
警告を手がかりに、API と型の違いを調べる
警告や解析ツールは調査の入口になりますが、警告がなくなったことと、業務上の動作が同じことは別です。置換する API の入力・出力・エラー時の挙動を確認します。
たとえば QList::size() の戻り値は、Qt 5 の int から Qt 6 の qsizetype に変わっています。int count = records.size(); と受け取っていた箇所は、auto count = records.size(); とすれば戻り値の型を保持できます。Qt 5 と Qt 6 の両方に対応するコードでも使える考え方です。
ただし、その count を渡す先が int を要求するなら、そこにも確認が必要です。受け取り側の型を変更するか、値が範囲内に収まることを確かめてから変換します。キャストだけで警告を消すと、大きい件数を正しく扱えない問題が残ることがあります。これは非推奨 API の置換とは別に必要になる、型の変更への対応です。Qt Core の変更点
7. 移行補助ツールは、用途と限界を決めて使う
動画は三つの補助ツールを紹介し、自動処理の対象が限定されることや、修正結果を人が確認する必要性にも触れています。
| ツール |
主な用途 |
利用時に確認すること |
| Clazy |
Qt 向けの C++ 静的解析 |
利用する版・チェック項目と、自分たちのビルド設定に合う解析条件 |
| qmllint |
QML の構文・型情報を用いた診断 |
自作モジュールを含む import パスと型情報 |
| qmake2cmake |
qmake プロジェクトの CMake 化の補助 |
条件分岐、生成処理、リンク設定、配布処理の変換結果 |
Clazy の公式リポジトリはチェック項目や利用方法の確認先です。すべての移行課題を検出する専用ツールと考えず、対象となる指摘を選んで利用します。
qmllint の公式説明では、正しく診断するために型情報が必要であると説明しています。独自の QML モジュールが見つからない状態で大量の診断が出た場合は、ソース修正を始める前に解析環境を確認します。
qmake2cmake の案内を参考に変換する場合も、生成された CMake ファイルが従来の製品を再現するかを確認します。ビルドできても、翻訳ファイル、画像、プラグイン、インストール先などの扱いが抜けていれば、配布物としては完成していません。
Qt 6 への移行と、アプリケーションの CMake 化は、必ず同時に行う一つの作業ではありません。ただし、利用する新機能が CMake を前提にする場合は、その条件を計画に含めます。CMake 化する場合は、単に .pro の各行を置き換えるより、実行ファイルやライブラリごとに依存関係を整理すると保守しやすくなります。
8. 実務への補足：既存システムを棚卸しする
ここからは、動画の考え方を実際の計画に落とし込むための提案です。まず、現状を再現するための情報をまとめます。ソースコードだけでなく、ビルド・実行・配布の三つを対象にします。
| 調査対象 |
記録する内容の例 |
見落とした場合の影響 |
| 開発環境 |
Qt の正確な版、コンパイラ、SDK、ビルドオプション |
同じソースでも再現できない |
| Qt の利用範囲 |
モジュール、Widgets／Quick、独自描画、private API（公開 API ではない内部実装への依存） |
変更量を過小評価する |
| 外部依存 |
ライブラリ、ドライバ、プラグイン、バイナリー提供のみの部品 |
再ビルドや置換ができない |
| データ |
文字コード、保存形式、設定、通信形式 |
既存データや他システムと互換性を失う |
| 操作と性能 |
主要操作、入力方法、待ち時間、メモリ使用量 |
移行後の良否を判定できない |
| 配布と更新 |
同梱ファイル、導入方法、権限、更新・復旧手順 |
開発環境以外で動かない |
各項目には「確認済み」「未確認」「対応が必要」を付けます。「たぶん動く」を確認済みに含めないことが、この表の役割です。
とくにバイナリーでしか提供されていない部品は、早い段階で対応可否を確認します。自社で直せるソースのエラーが多数ある場合より、代替できない部品が一つある場合の方が、計画全体への影響が大きいことがあります。
9. 実務への補足：小さな試験移行で難所を確かめる
最初の試験対象は、最も簡単な画面だけではなく、製品の難所を代表する機能から選びます。たとえば独自描画、外部機器との通信、特殊な文字コードの読み込み、埋込みブラウザーの利用などです。
一つの対象について、次の順で確認します。
- Qt 5 版で、入力データ・操作・期待結果を記録する。
- 候補の Qt 6 環境でビルドし、失敗箇所と依存関係を記録する。
- 互換性修正を行い、同じ入力と操作で結果を比較する。
- 実機または実際の配布先に近い環境でも試す。
- 修正内容、調査時間、試験時間、未解決事項を残す。
ここで得たいのは「何行直したか」だけではありません。同じ修正をほかにも適用できるのか、機能ごとに調査が必要なのかを判別します。
たとえば一つの共通ライブラリの修正で多数のエラーが解消した場合、そのエラー件数をそのまま個別作業数に換算しません。逆に、一つの画面が表示できても、すべての描画方式が検証できたとは扱いません。
10. 実務への補足：ビルド成功から完了判定までをつなぐ
動画でも、Qt の仕様・実装やツールチェインの変更によって、ビルドが通ったあとに挙動が変わる可能性を説明しています。完了条件は、実行時エラーが出ないことより広く設定します。
| 観点 |
具体的な比較例 |
| 業務機能 |
同じ入力に対して同じ計算結果・帳票・保存データになるか |
| 表示と操作 |
フォント、改行、拡大率、キーボード、マウス、タッチ操作 |
| エラー処理 |
通信切断、ファイル不足、権限不足、機器の未接続 |
| 性能と資源 |
起動、画面切替、処理時間、メモリ、長時間運転 |
| 配布 |
Qt の開発環境がない端末で起動し、必要な機能を使えるか |
| 更新と復旧 |
旧版の設定・データを引き継げるか、想定した方法で戻せるか |
性能は、同じ機器・入力・ビルド種別・測定条件で複数回測ります。たとえば画面切替では、最初の一回と繰り返した場合を分けると、初期化と通常操作の違いを見つけやすくなります。Qt の変更に合わせて OS やコンパイラも更新した場合は、その条件も記録し、差のすべてを Qt だけの効果とはしません。
データ形式を変更する場合には、実行ファイルを旧版に戻すだけで復旧できるとは限りません。旧版で読めるデータの保全方法まで含めて、更新手順を試します。
11. 実務への補足：見積もりを、分かっている作業と不確実な作業に分ける
動画の「変更範囲を広げると費用・期間も増える」という説明を、実際の見積もりでは作業単位に分解します。
| 区分 |
含める作業 |
| 調査・環境構築 |
現状再現、依存関係の確認、候補環境の準備 |
| 必須の移行 |
ビルド修正、削除 API の置換、実行時の互換性修正 |
| 評価・配布 |
回帰試験、実機確認、配布・更新・復旧試験 |
| 任意の改善 |
性能改善、新機能、設計整理、保守性の改善 |
| 未確定部分 |
外部部品の回答待ち、代替方式の調査、未検証の機器 |
未確定部分は、確定済みの作業に埋め込まず、「何を確認すれば見積もれるか」を記録します。試験移行の結果で見積もりを更新する前提を共有すると、初期の概算を確約として扱う誤解を減らせます。
たとえば、既存の計測機器向けアプリケーションなら、次のような段階が考えられます。これは説明用の計画例であり、実案件の工数や成果を示したものではありません。
| 段階 |
実施内容 |
次に進むための条件 |
| 調査 |
機器ドライバ、Qt モジュール、既存データを確認 |
移行を妨げる依存関係と確認方法が分かる |
| 試験移行 |
機器接続、データ読込み、代表画面を移行 |
実機で主要経路が成立し、残作業を分類できる |
| 動作維持 |
残る機能を移行し、互換性を確認 |
合意した機能・配布試験を満たす |
| 改善 |
遅い画面や保守上の問題を改善 |
合意した測定条件で目標を満たす |
この形なら、改善の調査が長引いても、動作維持の達成状況を別に報告できます。一方、製品要件として性能改善が必須であれば、動作維持だけでリリース可能とは判定しません。
12. 段階ごとのチェックリスト
調査開始前：目的と調べる範囲をそろえる
- 移行の目的、対象製品、希望時期を説明できるか。
- 現在の Qt・OS・機器について、判明している情報と不明点を整理したか。
- ソース、ビルド環境、比較用データを入手できるか。入手できないものの担当窓口は分かるか。
- 調査の担当者と、試験に使用できる機器・環境を決めたか。
この段階では、未確認事項を調査項目に変えられれば着手できます。
試験移行後・本格移行前：計画と完了条件を確定する
- 現在の Qt 5 版を再現してビルドし、比較対象として動かせたか。
- 移行先の Qt と、OS・ツールチェイン・外部部品の組合せを確認したか。
- 利用するモジュールと配布形態に対して、ライセンス条件を確認したか。
- Qt 5.15 を経由するか、Qt 5 上で先行する変更は何かを決めたか。
- 必須の移行と任意の機能・性能改善を分けたか。
- 難所を代表する機能を試験移行し、残作業と未解決事項を記録したか。
- エラー時・長時間運転・配布先を含む試験計画と、合否基準を定めたか。
- 見積もりに残る不確実性、移行を見送る条件、復旧方法を関係者と共有したか。
未解決事項がある場合は、その影響・解決期限・担当者を示して、先に進める範囲を決めます。
具体的なビルド設定、C++・Widgets、QML、配布の確認は、続編の実践編「Qt 6.12 への移行実践」を参照してください。
移行を相談するときに用意するとよい情報
動画の終盤では、SRA のトレーニング、コンサルティング、受託開発、サポート、テスト・CI 関連の支援を紹介しています。具体的な支援範囲は、対象環境と課題を基に確認します。
相談時には、まず「現在の Qt と OS」「主な利用モジュール」「動かす機器」「移行の目的」「希望時期」「現在分かっている障害」を共有すると、調査の入口をそろえやすくなります。最初からすべてを調べ切る必要はなく、不明な項目は不明として伝えて構いません。
支援内容は、Qt に関する SRA のサービスをご覧ください。
出典と記事の範囲
主な情報源は、SRA ソリューション公開の移行戦略セミナー動画です。開催日は 2025 年 1 月 23 日、動画公開日は 2025 年 6 月 30 日です。
| 動画の位置 |
主な内容 |
本記事の対応箇所 |
| 02:10～02:38 |
発表の対象と範囲 |
導入 |
| 02:46～06:58 |
Qt 5・Qt 6 の経緯と新機能 |
第 1・2 節 |
| 07:05～13:45 |
バージョン、セキュリティ、ライセンス、機能・性能の比較 |
第 2・4 節 |
| 13:51～15:28 |
デスクトップ製品の採用状況 |
第 3 節 |
| 15:47～20:50 |
移行先、方針、準備、段階的な移行 |
第 4～6 節 |
| 20:55～22:08 |
移行補助ツールと限界 |
第 7 節 |
| 22:14～23:28 |
講演のまとめ |
各節の判断軸 |
| 23:33～24:15 |
参考文献への言及とサービス紹介 |
相談案内 |
作業表・計画例は、移行計画を具体化するために本記事で作成したものです。特定製品での移行実績や性能の実測値は含めていません。技術的な補足の根拠は該当箇所の公式資料へのリンクに示しています。