Aurora MySQLでutf8mb3からutf8mb4へ移行するときに確認すること
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
utf8mb3(MySQL 5.7では `utf8` がこの別名)からutf8mb4へ移行するときは、(1) インデックスのキー長上限、(2) 照合順序の選択、(3) サーバーパラメータと接続時の文字セット、の3つを先に確認します。特に問題になるのはキー長で、utf8mb4は1文字最大4バイトのため `VARCHAR(255)` の単独インデックスは1020バイトを要求し、767バイト上限の環境では `ALTER TABLE` が失敗します。変換はテーブルの作り直しを伴うため、計画作業として扱ってください。
この文書の適用条件
| 対象製品 | Aurora MySQL(MySQL互換エディション)/ MySQL |
|---|---|
| 確認バージョン | Aurora MySQL 2.x(MySQL 5.7互換)/ 3.x(MySQL 8.0互換)。`utf8mb4_0900_ai_ci` はMySQL 8.0互換の 3.x のみ |
| 適用環境 | Amazon Aurora、Amazon RDS for MySQL、オンプレミスのMySQL |
| 必要権限 | 調査は `information_schema` の参照権限。変換は対象テーブルへの `ALTER` 権限、パラメータ変更はIAMの `rds:ModifyDBClusterParameterGroup` など |
| 実行影響 | 調査SQLは影響なし。`CONVERT TO CHARACTER SET` はテーブルの作り直し(データコピー)を伴う |
| 再起動 | テーブル変換は不要。サーバーパラメータの反映方法はパラメータごとに異なるため `ApplyType` を要確認 |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
- 権限
- 接続権限(グローバル変数の参照)
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
-- 権限: 接続権限(グローバル変数の参照のみ)
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SHOW GLOBAL VARIABLES WHERE Variable_name IN (
'character_set_server',
'character_set_database',
'character_set_client',
'character_set_connection',
'character_set_results',
'collation_server',
'collation_database',
'collation_connection'
);MySQL 5.7では `utf8` は `utf8mb3` の別名です。ここに `utf8` と表示されていても、実体は3バイト上限のutf8mb3だと理解してください。MySQL 8.0では `utf8` の別名としての使用が非推奨になっています。
- 対象
- Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
- 権限
- `information_schema` の参照権限(メタデータ可視性に従う)
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
-- 権限: information_schema の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
TABLE_SCHEMA,
TABLE_NAME,
ENGINE,
ROW_FORMAT,
TABLE_COLLATION,
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 1) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
AND (TABLE_COLLATION IS NULL OR TABLE_COLLATION NOT LIKE 'utf8mb4%')
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;`size_mb` の大きい順に並べています。変換はテーブル単位のデータコピーになるため、この順序がそのまま作業の重さの順序になります。
- 対象
- Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
- 権限
- `information_schema` の参照権限
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
-- 権限: information_schema の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
TABLE_SCHEMA,
TABLE_NAME,
COLUMN_NAME,
DATA_TYPE,
CHARACTER_MAXIMUM_LENGTH AS max_chars,
CHARACTER_OCTET_LENGTH AS max_bytes,
CHARACTER_SET_NAME,
COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
AND CHARACTER_SET_NAME IS NOT NULL
AND CHARACTER_SET_NAME <> 'utf8mb4'
ORDER BY TABLE_SCHEMA, TABLE_NAME, ORDINAL_POSITION;テーブル既定がutf8mb4でも、個々の列に明示的な文字セットが残っていることがあります。テーブル単位の確認だけでは漏れるため、列単位でも必ず確認してください。
- 対象
- Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0(InnoDB)
- 権限
- `information_schema` の参照権限
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0(InnoDB)
-- 権限: information_schema の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
-- utf8mb4 は 1 文字最大 4 バイト。プレフィックス長指定の無い文字列列だけを対象に、
-- 変換後に必要となるキー長(バイト)を見積もる。
SELECT
s.TABLE_SCHEMA,
s.TABLE_NAME,
s.INDEX_NAME,
GROUP_CONCAT(s.COLUMN_NAME ORDER BY s.SEQ_IN_INDEX) AS index_columns,
SUM(c.CHARACTER_MAXIMUM_LENGTH * 4) AS bytes_after_utf8mb4
FROM information_schema.STATISTICS s
JOIN information_schema.COLUMNS c
ON c.TABLE_SCHEMA = s.TABLE_SCHEMA
AND c.TABLE_NAME = s.TABLE_NAME
AND c.COLUMN_NAME = s.COLUMN_NAME
WHERE s.TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
AND c.CHARACTER_MAXIMUM_LENGTH IS NOT NULL
AND s.SUB_PART IS NULL
GROUP BY s.TABLE_SCHEMA, s.TABLE_NAME, s.INDEX_NAME
HAVING bytes_after_utf8mb4 > 767
ORDER BY bytes_after_utf8mb4 DESC;まず767バイト超を全部出し、そのうえで自環境の上限に照らして判定します。行フォーマットが `DYNAMIC` または `COMPRESSED` で3072バイト上限が有効な環境では、`HAVING` の閾値を3072に変えて絞り込んでください。`VARCHAR(255)` の単独インデックスは 255 × 4 = 1020バイトになり、767バイト上限の環境では必ず失敗します。
- 対象
- Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
- 権限
- 対象テーブルへの `ALTER` 権限
- 変更作業
- あり(テーブルの作り直しとデータコピー)
- Production実行
- 大きなテーブルでは不可。計画作業として実施する
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0
-- 権限: 対象テーブルへの ALTER 権限
-- 変更作業: あり(テーブル作り直し + 全行のデータコピー)
-- Production 実行: 大きなテーブルでは不可。所要時間を実測してから計画実行する
-- 1) 変換前に現在の定義を保存しておく(切り戻し判断の材料になる)
SHOW CREATE TABLE SampleDB.sample_table;
-- 2) テーブル既定と全文字列列をまとめて変換する
ALTER TABLE SampleDB.sample_table
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci,
ALGORITHM = COPY,
LOCK = SHARED;
-- 3) 変換結果を確認する
SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'SampleDB'
AND TABLE_NAME = 'sample_table'
AND CHARACTER_SET_NAME IS NOT NULL;`CONVERT TO CHARACTER SET` はテーブルを作り直すため、オンラインDDL(`ALGORITHM=INPLACE`)では実行できません。`LOCK=SHARED` は参照を許可し書き込みを止めます。書き込みを止められない大きなテーブルでは、`pt-online-schema-change` や `gh-ost` のようなオンラインスキーマ変更ツールを使う方法があります。所要時間はテーブルサイズ、インスタンスクラス、同時負荷で大きく変わるため、必ず本番同等データで実測してください(本記事では所要時間の目安を示しません)。
- 対象
- Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0(セッション単位)
- 権限
- 接続権限
- 変更作業
- あり(現在のセッションの文字セット設定のみ)
- Production実行
- 可能(セッション内で完結する)
-- 対象: Aurora MySQL 2.x / 3.x、MySQL 5.7 / 8.0(セッション単位の設定)
-- 権限: 接続権限
-- 変更作業: あり(現在のセッションのみ。他セッションには影響しない)
-- Production 実行: 可能
-- クライアント・接続・結果の3つの文字セットをまとめて切り替える
SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci;
-- 現在のセッションの値を確認する
SHOW SESSION VARIABLES WHERE Variable_name IN (
'character_set_client',
'character_set_connection',
'character_set_results',
'collation_connection'
);テーブルをutf8mb4にしても、接続がutf8mb3のままだと4バイト文字は保存時に落ちるか、エラーになります。JDBC・PDO・各言語のドライバにも接続文字セットの設定があるため、アプリケーション側の接続文字列も併せて確認してください。
- 対象
- Aurora MySQL(DBクラスターパラメータグループ)
- 権限
- IAM: `rds:DescribeDBClusterParameters`, `rds:ModifyDBClusterParameterGroup`
- 変更作業
- あり(クラスター全体に効くパラメータの変更)
- Production実行
- 変更管理を通したうえで実施。反映方法はパラメータごとに確認する
# 対象: Aurora MySQL(DBクラスターパラメータグループ)
# 権限: IAM rds:DescribeDBClusterParameters, rds:ModifyDBClusterParameterGroup
# 変更作業: あり(クラスター全体に効くパラメータ変更)
# Production 実行: 変更管理を通したうえで実施
# 1) まず現在値と反映方法(ApplyType)を確認する。static なら再起動が必要になる
aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name example-aurora-mysql-cluster-params \
--query "Parameters[?starts_with(ParameterName, 'character_set') || starts_with(ParameterName, 'collation')].{Name:ParameterName,Value:ParameterValue,Apply:ApplyType}" \
--output table
# 2) 既定の文字セットと照合順序を変更する
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name example-aurora-mysql-cluster-params \
--parameters '[
{"ParameterName":"character_set_server","ParameterValue":"utf8mb4","ApplyMethod":"pending-reboot"},
{"ParameterName":"collation_server","ParameterValue":"utf8mb4_unicode_ci","ApplyMethod":"pending-reboot"}
]'サーバーパラメータの変更は「これから作られるオブジェクトの既定値」と「明示指定の無い接続の既定値」に効くだけで、既存テーブルの文字セットは変わりません。既存データの変換は `ALTER TABLE` が必要です。`ApplyMethod` は上記1)で確認した `ApplyType` に合わせてください(`static` のパラメータに `immediate` を指定するとエラーになります)。
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| TABLE_SCHEMA / TABLE_NAME | 対象スキーマとテーブル | アプリケーションが実際に使うスキーマに絞れているか |
| INDEX_NAME | インデックス名 | 主キーか二次インデックスかで対処の選択肢が変わる |
| index_columns | インデックスの構成列 | 複合インデックスは全列のバイト長の合計が上限に当たる |
| bytes_after_utf8mb4 | utf8mb4化後に必要となるキー長の見積り(バイト) | 767を超えるなら旧設定の環境で失敗。3072を超えるならどの設定でも失敗する |
| ROW_FORMAT | InnoDBの行フォーマット | `DYNAMIC` / `COMPRESSED` かどうかでキー長上限の判定が変わる |
| TABLE_COLLATION | テーブル既定の照合順序 | utf8mb4系になっているか。列単位の設定も別途確認する |
| CHARACTER_OCTET_LENGTH | 現在の文字セットでの最大バイト数 | utf8mb3では3倍、utf8mb4では4倍になる。行サイズ上限の見積りに使う |
| size_mb | データ+インデックスの概算サイズ | 変換作業の重さの順序。大きいものほど事前の実測が必要 |
こういう状況で使います
- 絵文字や一部の漢字を保存すると `Incorrect string value` エラーになる
- 保存はできるが、絵文字が `????` や空文字になって戻ってくる
- `ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4` が `Specified key was too long` で失敗する
- テーブルはutf8mb4にしたのに、アプリケーションからは依然として文字化けする
- 同じ文字列の比較結果が、変換前後で変わった(重複エラーが増えた/減った)
考えられる原因(可能性の高い順)
01
utf8(utf8mb3)は3バイトまでしか格納できない
MySQL 5.7の `utf8` は `utf8mb3` の別名で、1文字あたり最大3バイトです。絵文字や一部のCJK拡張漢字は4バイト必要なため、格納できません。
02
インデックスのキー長上限に当たっている
InnoDBのインデックスキーには上限があり、旧来の設定(`innodb_large_prefix` 無効、`COMPACT` / `REDUNDANT` 行フォーマット)では767バイト、`DYNAMIC` / `COMPRESSED` では3072バイトです。utf8mb4は1文字4バイト換算になるため、`VARCHAR(255)` の単独インデックスで1020バイトを要求し、767バイト上限では失敗します。
03
接続側の文字セットが揃っていない
テーブルがutf8mb4でも、接続がutf8mb3なら4バイト文字はサーバーに届く前に落ちます。ドライバの接続文字列や `SET NAMES` の指定を確認してください。
04
列単位の指定が残っている
テーブル既定を変えても、列に明示的な文字セットが指定されていればその列は変わりません。列単位の洗い出しが必要です。
05
照合順序の違いで比較結果が変わった
`utf8mb4_general_ci` と `utf8mb4_unicode_ci` では等価とみなす文字の範囲が異なります。照合順序を変えると、一意制約に引っかかる行の集合が変わることがあります。
確認手順
- 1
サーバー・データベース・テーブル・列の4階層で現在値を確認する
参照のみ上位の設定は既定値にすぎず、下位に明示指定があればそちらが勝ちます。4階層すべてを参照専用SQLで確認します。
- 2
utf8mb4でないテーブル・列を一覧化する
参照のみ`information_schema.TABLES` と `information_schema.COLUMNS` で対象を確定します。
- 3
キー長上限に当たるインデックスを洗い出す
参照のみ変換を実行する前に必ず行います。ここで出た表は、変換前にインデックス定義の見直しが必要です。
- 4
行フォーマットと `innodb_large_prefix` の状態を確認する
参照のみMySQL 5.7互換環境では `SELECT @@global.innodb_large_prefix, @@global.innodb_default_row_format;` で確認します。MySQL 8.0では `innodb_large_prefix` は削除されています。
- 5
検証環境で1テーブルを変換して所要時間と結果を測る
中本番同等のデータ量で実測します。ここで得た時間が唯一の計画根拠になります。
- 6
照合順序変更による比較結果の差を確認する
中一意制約のある列で、変換後に重複が発生しないかを検証環境で確認します。
対応方法
すぐに実施できる低リスクの対応
接続側をutf8mb4に揃える
低アプリケーションの接続文字セットを `utf8mb4` にします。テーブル変換より先にこれを済ませておくと、変換直後から正しく扱えます。
対象と規模を確定させる
参照のみ洗い出しSQLの結果を作業一覧にします。テーブル数とサイズが分かるまで、日程は決められません。
事前検討が必要な変更
キー長超過のインデックスを先に手当てする
高列長を短くする(`VARCHAR(255)` → `VARCHAR(191)` など)、プレフィックス長を指定する、インデックス自体を見直す、のいずれかを選びます。いずれもスキーマ変更です。
行フォーマットを `DYNAMIC` に揃える
高3072バイト上限を使えるようにします。MySQL 5.7互換環境では `innodb_large_prefix` の有効化とセットで確認が必要です。テーブルの作り直しを伴います。
照合順序を決めて全テーブルで統一する
中テーブルごとに照合順序が異なると、結合時に照合順序の不一致エラーが起きます。移行時に統一してください。
再起動・サービス影響を伴う変更
`ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4` を実行する
高テーブルを作り直すため、大きなテーブルでは長時間かかり、その間の書き込みが止まります。所要時間は実測値をもとに計画してください。
オンラインスキーマ変更ツールで変換する
高`pt-online-schema-change` や `gh-ost` を使うと書き込みを止めずに変換できますが、コピー用テーブルの分だけストレージを消費し、レプリケーションやトリガーとの相互作用を事前検証する必要があります。
新クラスターへ再ロードして切り替える
専門家レビュー必須テーブル数が多い場合、utf8mb4で作った新環境へデータを入れ直し、切り替える方が確実なことがあります。切り替え計画は移行計画の記事を参照してください。
!注意事項
- `CONVERT TO CHARACTER SET` はテーブルを作り直します。テーブルサイズに比例した時間とストレージ、そして書き込み停止が必要です。無停止で終わる作業ではありません。
- 変換によって列の最大バイト数が増えるため、行サイズやインデックスキー長の上限に新たに当たることがあります。事前の洗い出しなしに実行しないでください。
- 照合順序を変えると文字列の比較・並び替えの結果が変わります。一意制約のある列では、変換後に重複エラーが出る可能性があります。
- サーバーパラメータの変更だけでは既存テーブルは変わりません。逆に、テーブルだけ変えても接続側がutf8mb3なら文字は落ちます。両方揃えてください。
- 4バイト文字を含むデータを既にutf8mb3列へ入れようとして失敗している場合、失われたデータは変換では戻りません。アプリケーション側のエラーログを先に確認してください。
- 所要時間の目安は本記事では示しません。テーブルサイズ・インスタンスクラス・同時負荷で大きく変わるため、必ず検証環境で実測した値を使ってください。
バージョン・環境による違い
これで解決しない場合に確認すること
アプリケーションのドライバ設定を確認する
JDBCの `characterEncoding`、PHPの `charset`、各言語のクライアントライブラリの既定値が `utf8mb4` になっているかを確認します。
結合するテーブル間で照合順序が揃っているかを確認する
照合順序が異なる列を結合すると、実行時エラーやインデックス不使用の原因になります。
ストアドプロシージャ・ビュー・トリガーの文字セットを確認する
ルーチンは作成時の文字セットを保持します。テーブル変換後に作り直しが必要な場合があります。
レプリカやDMSのターゲットも同時に変換されるかを確認する
ソースだけ変換するとレプリケーション先で不整合や適用エラーが起きます。
バックアップからの復元手順で文字セットが維持されるかを確認する
切り戻しの際に、変換前の定義に戻せることを事前に確認してください。
この文書の根拠と限界
製品の公式ドキュメントに基づく説明
MySQLの文字セット・照合順序(`utf8mb3` / `utf8mb4`、`utf8mb4_general_ci` / `utf8mb4_unicode_ci` / `utf8mb4_0900_ai_ci`)、InnoDBのインデックスキー長上限と行フォーマット、`ALTER TABLE ... CONVERT TO CHARACTER SET` の公開仕様、およびAmazon Auroraのクラスターパラメータグループの公開仕様に基づきます。変換の所要時間は環境依存のため記載していません。
よくある質問
utf8とutf8mb4は何が違いますか?
MySQL 5.7では `utf8` は `utf8mb3` の別名で、1文字あたり最大3バイトまでしか格納できません。絵文字や一部のCJK拡張漢字は4バイト必要なため、`utf8mb4` でなければ保存できません。MySQL 8.0では `utf8` を別名として使うことは非推奨になっています。
Productionで実行できますか?
洗い出し用のSQLはすべて参照専用なので本番で実行できます。`ALTER TABLE ... CONVERT TO CHARACTER SET` はテーブルの作り直しを伴い、その間の書き込みが止まるため、規模に応じて計画停止またはオンラインスキーマ変更ツールを使ってください。
ALTER TABLE が「キーが長すぎる」と失敗するのはなぜですか?
utf8mb4では1文字を4バイトとして計算するため、インデックスのキー長が増えるからです。`VARCHAR(255)` の単独インデックスは1020バイトになり、767バイト上限の環境では必ず失敗します。列長の短縮、プレフィックス長の指定、行フォーマットの見直しのいずれかを先に行ってください。
どの照合順序を選べばよいですか?
既存の比較結果を変えたくないかどうかで決まります。`utf8mb4_general_ci` と `utf8mb4_unicode_ci` では等価とみなす文字の範囲が異なり、一意制約のある列では重複判定が変わる可能性があります。`utf8mb4_0900_ai_ci` はMySQL 8.0互換環境でのみ使えます。検証環境で実データを使って重複を確認してから決めてください。
どの権限が必要ですか?
調査SQLは `information_schema` を参照できる権限で足ります(メタデータ可視性のルールに従うため、権限の無いオブジェクトは結果に出ません)。変換には対象テーブルへの `ALTER` 権限、パラメータグループの変更にはIAM権限が必要です。
サーバーパラメータをutf8mb4にすれば既存テーブルも変わりますか?
変わりません。パラメータはこれから作られるオブジェクトと、明示指定の無い接続の既定値に効くだけです。既存データはテーブルごとの `ALTER TABLE` が必要です。
この文書がカバーする質問
- MySQLで絵文字を保存すると Incorrect string value になる
- utf8mb4に変換したらインデックス作成に失敗する
- utf8とutf8mb4のどちらを使うべきか
- Aurora MySQLの既定文字セットをutf8mb4に変えたい
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
文字セット移行は「一度やれば終わる」作業に見えますが、実際には移行後も列の追加やテーブルの新規作成のたびに設定が揺れます。GIIPでは、utf8mb4化の対象洗い出しSQLを定期実行して、utf8mb4以外の列が新たに増えていないかを継続的に点検しています。差分が出たときだけ通知し、スキーマ変更の是非は人が判断する形にしているため、移行が終わった後も設定が元に戻っていくことを防げます。
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
Aurora MySQLで特定のクエリが遅くなったときの確認手順
スロークエリログ・PROCESSLIST・EXPLAIN・ダイジェスト集計の順に、危険度の低い確認から遅いクエリを特定する手順です。performance_schemaが無効な環境の代替手段も示します。
database-migration3TB規模のデータベースを移行するときの計画の立て方
3TB級の移行計画は、サイズの実測、切り替え方式の選択、試験実行による所要時間の実測、検証と切り戻しの設計、の順で組み立てます。目安値ではなく実測値で日程を引くための手順です。
tidbTiDBからAurora MySQLへ移行するときに確認する項目
TiDBはMySQL互換ですが同一ではありません。主キー・採番・トランザクション・統計・容量の各差分を、確認用SQLとともに移行前チェックリストとして整理します。
aurora-mysqlAWS DMSでError 1032が発生する原因と確認方法
DMSのCDCで出るError 1032はターゲットに該当行が無いという意味です。制御テーブルの読み方と主キー不一致の確認手順、タスク設定の選択肢を整理します。
関連サービス
文字セット変換の検証環境づくりを相談する
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
文字セット変換の検証環境づくりを相談する