スキーマレジストリとは？互換性モードとスキーマ進化の実装・採用判断を解説【2026年版】

スキーマレジストリは、メッセージ基盤を流れるデータの構造を一箇所に登録し、バージョン付けと互換性検査を機械的に回すコンポーネントです。プロデューサーはスキーマ定義そのものではなく登録済みのIDをメッセージに載せ、コンシューマー側はそのIDを手掛かりに定義を引いて復元する仕組みです。データ契約（Data Contract）が「何を守るか」を組織の側で決めるものだとすれば、レジストリはその取り決めを配信経路の上で実際に止める装置にあたります。この記事では、IDを埋め込むwire formatの構造、7つの互換性モードで変わる更新順序、サブジェクト命名の分岐、Confluent・AWS Glue・Apicurioの前提差、そして導入を見送るべき規模までを実装者の目線で整理します。

まとめ｜スキーマレジストリ導入の可否を分ける3条件と最初に決める設定

レジストリが噛み合うのは、次の3つが揃った場合です。第一に、同じトピックを読み書きする主体が複数チームまたは複数言語にまたがること。第二に、スキーマの変更が今後も続く見込みがあること。第三に、変更を入れる前に落とせる検査の置き場所（CIまたはリリース手順）があること。3つ目が無いままレジストリだけ立てると、単に登録されるだけの箱になり、破壊的変更は本番で顕在化します。

導入時に最初に決めるのは2点です。互換性モードをどれにするか、そしてサブジェクトをトピック名から導くか、レコード名から導くか。前者は「消費側と生産側のどちらを先に更新するか」という運用制約に直結し、後者は1つのトピックに複数の型を相乗りさせられるかを決めます。

見送りが妥当なのは、トピックが数本で、生産側と消費側を同じチームが同じ言語で同時にデプロイできる場合です。この規模ではレジストリの運用コストが検査の便益を上回るため、型定義をリポジトリで共有し、CIの差分検査で代替したほうが総工数は下がります。判断の分岐は第6章に条件付きで示しました。

プロデューサーとコンシューマーの契約としてスキーマを一元管理する仕組み

用語の混乱がいちばん起きやすいのは、データベース内部のスキーマとの取り違えです。ここを先に切り分けておくと、以降の設計判断が定まります。

データベースの三層スキーマとストリーミング文脈のスキーマの守備範囲の違い

リレーショナルデータベースでいうスキーマは、テーブルや制約の定義そのもの、つまり外部・概念・内部の三層で整理される構造を指します。ストリーミング文脈のスキーマは、これとは別物です。対象はトピックを流れる1レコードのシリアライズ形式であり、格納先の物理設計ではなく、書き手と読み手のあいだで交わされる型の取り決めを指します。

この差が効いてくるのが、変更の反映タイミングです。データベースなら定義変更は1回のDDLで全体に及ぶ仕組みです。トピックの場合、古いスキーマで書かれたレコードは保持期間のあいだ残り続け、新旧のスキーマが同じパーティションに混在します。だからレジストリは「今の定義」だけでなく、過去の全バージョンを保持したうえで互換性を検査する構造になっています。Apache Kafkaを採用する構成でレジストリが標準装備のように扱われるのは、この混在が避けられないためです。

スキーマIDだけを載せるwire formatとペイロード削減の実際

Confluentのシリアライザは、レコード本体の前にマジックバイトと4バイトのスキーマIDを付けます。コンシューマー側のデシリアライザはこの数バイトを読み、IDに対応する定義をレジストリから取得して復元する仕組みです。Confluent公式ドキュメントはこの設計を「スキーマ定義全体ではなくスキーマIDを渡すことで、ネットワーク上のペイロードを削減する」と説明しています。

効いてくるのは1レコードあたりの差です。フィールド数十のAvroスキーマをJSONで毎回同梱すれば数KB規模になりますが、IDなら数バイトで済みます。日次で億単位のレコードが流れる基盤では、この差がそのままストレージと転送量の差になります。

サブジェクト命名の3戦略とトピック相乗り時に生じる設計上の分岐

スキーマの登録単位はサブジェクトと呼ばれ、その名前の決め方が3つ用意されています。既定の TopicNameStrategy は、トピック名にキー用の -key か値用の -value を足した名前です。RecordNameStrategy は完全修飾のレコード名を、TopicRecordNameStrategy はトピック名とレコード名を連結した名前をサブジェクトにします。

分岐が生じるのは、1つのトピックに複数の型のイベントを相乗りさせたい場合です。既定のままでは、トピックにつき値のスキーマは実質1系統に固定されます。注文の作成・変更・取消を同一トピックへ順序保証付きで流したいなら、レコード名を含む後者2つの選択が必要です。逆に、トピックと型が1対1で対応する設計なら既定のままが扱いやすく、Kafka Connectのコンバータ設定もそのまま通ります。

BACKWARDからFULL_TRANSITIVEまで7モードで変わる更新順序の制約

互換性モードの選択は、実質的にデプロイ手順の選択です。どの変更が通るかだけでなく、生産側と消費側のどちらを先に入れ替えるかまで決まります。

7つの互換性モードで許容される変更と先に更新すべき側の対応方法

既定のBACKWARDが消費側の先行更新を要求する理由と巻き戻し要件

Confluentが既定をBACKWARDに置く理由は明快で、公式ドキュメントは「コンシューマーをトピックの先頭まで巻き戻せること」を挙げています。新しいスキーマで古いデータを読めるという性質があるため、オフセットをゼロに戻して過去分を再処理しても壊れません。障害復旧やバックフィルを前提にする基盤では、この性質が効きます。

運用手順としては「新しいイベントを流し始める前に、全コンシューマーを先に更新する」順序になります。ここで消費側の更新を後回しにすると、新スキーマのレコードを旧デシリアライザが受けて落ちます。BACKWARDで通る変更は、フィールドの削除と、既定値を持つ任意フィールドの追加です。必須フィールドの追加は通りません。

FORWARDとFULLで入れ替わる更新順序と独立更新が成立する条件

FORWARDは順序が逆になります。公式の記述どおり、先に全プロデューサーを新スキーマへ上げ、そのうえでコンシューマーを更新します。既に稼働している読み手を触らずに新フィールドを足したい場合に噛み合う設定です。通るのはフィールドの追加と任意フィールドの削除で、BACKWARDとちょうど裏返しの関係になります。

FULLは両方の条件を同時に満たすため、生産側と消費側を独立して更新できます。この自由度と引き換えに、許される変更は任意フィールドの増減だけです。組織をまたいでデプロイのタイミングを合わせられないなら、制約が強くてもFULLを選ぶほうが事故は減ります。逆に、同一チームで両側を同時にリリースできるならBACKWARDのままで支障ありません。

TRANSITIVE系が全過去バージョンを検査する場面と運用上の代償

非TRANSITIVEのモードが見ているのは直近の1版だけです。v1からv2、v2からv3がそれぞれ互換であっても、v1からv3が互換である保証はありません。長期保持のトピックを先頭から読み直す運用があるなら、この抜けが実害になります。

TRANSITIVE系は登録済みの全バージョンに対して検査するため、この抜けを塞ぎます。代償は変更の自由度で、版が積み上がるほど「過去のどれかに引っかかって登録できない」状況が増えます。判断の目安は保持期間です。保持が数日で再処理も直近しか見ないなら非TRANSITIVEで足り、コンプライアンス要件で年単位の保持と全期間の再処理を抱えるならTRANSITIVEを選ぶ、という切り分けになります。

スキーマレジストリ実装の選定で効くライセンス・費用・移植性の差

実装は事実上3系統に絞られます。ここで見るべきは機能一覧よりも、ライセンス条件と運用主体、そして後から乗り換えられるかどうかです。

Confluent・AWS Glue・Apicurioの3実装比較で分かる前提の違い

Confluent Community Licenseが実務に効かせる制約

Confluent Schema Registry の本体は Confluent Community License で提供されています。自社利用や自社サービスへの組み込みには支障ありませんが、これはOSI承認のオープンソースライセンスではなく、競合するマネージドサービスとして提供する行為が制限されます。SaaSとして再提供する構想がある場合だけ、法務確認が要る条件です。

もう1点、セキュリティ関連の一部機能は Confluent Enterprise ライセンスの範囲になります。Schema Registry Security Plugin と、ブローカー側でスキーマIDを検証する Schema ID Validation が対象です。ブローカー側で未登録スキーマを弾く構成を前提に設計すると、商用ライセンスが要件として乗ってくるため、そこまで含めて見積もる必要があります。公式ドキュメントのcurrentは2026年8月時点で Confluent Platform 8.3系です。

AWS Glue Schema Registryの無料提供と1万バージョンの上限

AWS Glue Schema Registry は公式ドキュメントが「serverless and free to use」と明記しており、レジストリ自体に追加料金が発生しません。統合先は Apache Kafka・Amazon MSK・Kinesis Data Streams・Managed Service for Apache Flink・AWS Lambda。対応形式は AVRO(v1.11.4)、JSON Schema(Draft-04・06・07)、Protobuf(proto2とproto3、extensionsとgroupsは非対応)で、任意でZLIB圧縮も掛けられます。

設計時に効く数字は3つです。1リージョン1アカウントあたりレジストリは100まで、スキーマバージョンは合計10,000まで、スキーマペイロードは170KBまで。いずれもハード上限で、緩和申請では動きません。大規模なマルチテナント基盤でトピックごとにバージョンを積む設計にすると、この1万に触れます。

互換性モードの呼称も違います。Confluentが TRANSITIVE と呼ぶ全版検査を、Glueは BACKWARD_ALL のように _ALL で表します。加えて Glue には版の追加自体を止める DISABLED があり、モードは8種です。ドキュメントを行き来する際は、この名前の対応をあらかじめ揃えておくと混乱を避けられます。

Apicurio Registry 3.3系のApache 2.0と保存先選択の自由度

Apicurio Registry は Apache 2.0 ライセンスの実装で、3.3.0 が2026年6月16日にリリースされました。この版でデータ契約のサポートとCLIの刷新が入っています。Confluent API 互換のエンドポイントを備えるため、既存のConfluentシリアライザを大きく書き換えずに寄せられる点が実務上の利点です。

もう1つの差はストレージです。Kafka・PostgreSQL・MySQL・SQL Server・インメモリから保存先を選べます。Kafkaクラスタ自体を運用したくない、あるいは既存のRDBのバックアップ体制に乗せたい、という制約があるならこの自由度が有効です。扱える定義も Avro・Protobuf・JSON Schema に加え、OpenAPI・AsyncAPI・GraphQL・Kafka Connect Schema まで含みます。

レジストリ導入時の実装工程とCIでスキーマ破壊を止める検査の組み込み

レジストリを立てただけでは破壊的変更は止まりません。止まるのは、登録の試行がリリース前に走る導線を作った場合だけです。

レジストリ選定から互換性モード確定までの5工程と決裁すべき順番

1. 対象トピックを棚卸しし、生産側と消費側の担当チームと言語を一覧化する
2. 保持期間と再処理要件を確認し、TRANSITIVE系が要るかを先に判定する
3. デプロイのタイミングを揃えられるかで、BACKWARD・FORWARD・FULLを選ぶ
4. トピックに型を相乗りさせるかで、サブジェクト命名戦略を決める
5. 実装（Confluent・Glue・Apicurio）を選び、既定値を明示的に設定として書き下す

順番を入れ替えないでください。実装の選定を先にすると、そのプロダクトの既定値が事実上の設計になります。互換性モードとサブジェクト戦略は業務要件から決まる項目であり、製品都合で決める項目ではありません。

スキーマIDのキャッシュとレジストリ障害時のフェイルセーフ設計

レジストリが単一障害点に見えるという懸念は、実際には設計次第で薄まります。クライアント側のシリアライザはスキーマIDと定義の対応をローカルにキャッシュするため、既知のIDだけを扱っているあいだはレジストリへ問い合わせません。障害中に止まるのは、新しいスキーマの登録と、未知のIDに遭遇したコンシューマーの復元です。

設計として押さえるのは2点。プロセス起動直後にキャッシュが空になる点と、キャッシュ上限を超えると再取得が走る点です。ローリングリスタートとレジストリのメンテナンス時間を重ねない運用にするだけで、実害はほぼ消えます。

データ契約のルール適用へ接続する場合の責務分担と導入の実装順序

レジストリが検査するのは構造の互換性までで、値の妥当性は範囲外です。金額が負でないこと、区分値が定義済みの集合に収まること、こうした条件は互換性検査を素通りします。ここを埋めるのがデータ契約とルール適用の枠組みで、Confluent と Apicurio はいずれもレジストリ側の機能として取り込みつつあります。

実装の順序としては、互換性検査を先に固めてから値のルールへ進みます。逆順にすると、構造が動くたびにルール定義も壊れ、二重の手戻りが出ます。構造を止めてから値を止める。この順番だけは崩さないでください。

スキーマレジストリを導入しない判断が成立する規模と失敗パターン

レジストリは常に正解ではありません。導入コストが検査の便益を上回る領域は確実にあります。

トピック2本・単一チーム・単一言語であれば見送りが妥当になる条件

トピックが2、3本で、生産側と消費側を同じチームが同じ言語で書き、同じパイプラインでデプロイしている。この条件下ではレジストリを入れないほうが速いです。型定義を共有ライブラリとしてリポジトリに置き、CIで互換性の差分を見るだけで実質的に同じ検査が回ります。レジストリを足すと、運用対象のコンポーネントと監視項目、ライセンス確認の作業が増えるだけになります。

逆転する境界は、明確に「主体の数」です。読み手が別チームになった時点で、口頭やSlackでの合意が追いつかなくなります。言語が2つ以上に増えた時点で、共有ライブラリという手段そのものが使えなくなります。この2つのどちらかが起きたら、規模が小さくても導入側へ倒す判断が妥当です。データ基盤の構成そのものから相談したい場合は、データ分析基盤構築・MLOps構築支援で設計から実装まで対応しています。

NONE設定のまま本番運用に入って障害を起こす典型的な失敗の形

いちばん多い失敗は、開発中の検証で互換性エラーが煩わしくなり、モードをNONEにしたまま本番へ持ち込むケースです。NONEは非互換な変更をそのまま通します。レジストリは立っていて、スキーマは登録されていて、それでも何も守られていない状態が完成します。

この状態が発覚するのは、たいてい本番のコンシューマーが落ちてからです。しかも既に非互換な版が登録済みなので、モードを戻すだけでは解消しません。開発環境でNONEを使うなら、本番へ昇格させる手順の中にモード設定の検査を必ず1工程として置いてください。

レジストリ導入が投資として見合う組織の規模と変更頻度の判断目安

投資判断の軸は2つに絞れます。スキーマ変更のリードタイムと、破壊的変更が起きたときの復旧コストです。変更のたびに関係チームへ事前調整が要り、その調整だけで数日を溶かしているなら、レジストリの互換性検査がそのまま調整の代替になります。

復旧コスト側はより単純です。トピックが止まったときに下流のダッシュボードや請求処理まで巻き込むなら、検査の自動化に掛ける工数は1回の障害対応より安く付きます。この2つのどちらも当てはまらない、つまり調整が即日で終わり、止まっても業務影響が限定的なら、導入は先送りしてかまいません。判断を保留にする理由にはならず、条件が揃った時点で入れる、という運用で足ります。

よくある質問

スキーマレジストリの検討で実際に問い合わせの多い論点を5つ挙げます。

スキーマレジストリとデータカタログは何が違いますか？

対象と目的が異なります。スキーマレジストリは配信経路上のレコード構造をバージョン管理し、互換性に反する変更を登録の時点で弾く実行装置です。データカタログはデータ資産の所在・意味・所有者を人が検索するためのメタデータ管理基盤で、処理を止める機能は持ちません。両者は競合せず、レジストリで機械的に止め、カタログで人が探す、という役割分担で併用します。

スキーマレジストリを使わずにAvroを扱えますか？

扱えます。Avroはスキーマをファイル先頭に含む形式（Object Container File）を持ち、レコードごとにスキーマを同梱する運用も可能です。ただしメッセージ単位で毎回スキーマを載せるとペイロードが膨らみ、変更時の互換性検査も自前で作る必要があります。トピックが少なく変更頻度も低いなら選択肢になりますが、主体が複数に増えた時点で破綻しやすい構成です。

互換性モードは後から変更できますか？

変更できます。Confluent Schema Registry はグローバル既定とサブジェクト単位の両方で設定でき、サブジェクト側の設定が優先されます。ただし、変更前に登録された版は遡って検査し直されません。NONEで非互換な版を積んでからBACKWARDへ戻しても、既存の版の並びはそのまま残るため、過去分の再処理は依然として壊れます。移行時は対象サブジェクトの版履歴を確認してください。

Confluent Schema RegistryはKafka以外でも使えますか？

スキーマの保存先として Kafka のトピックを使う設計のため、Kafka そのものは前提になります。Kafka以外のメッセージ基盤で同種の仕組みが要るなら、保存先に PostgreSQL や MySQL を選べる Apicurio Registry のほうが適合しやすい構成です。なお Kafka互換のプロトコルを提供する基盤であれば、Confluent 実装をそのまま向けられる場合もあります。

スキーマIDはトピックを跨いで共有されますか？

共有されます。スキーマIDはレジストリ全体で一意に採番されるため、同一の定義を複数のトピックで使った場合もIDは同一です。一方でサブジェクトはトピック単位で分かれ、互換性の検査もサブジェクトごとに独立して行われます。IDは定義の実体、サブジェクトは版管理の単位、と分けて理解しておくと設定の見通しが立ちます。

関連記事

• データ契約（Data Contract）とは？ODCSとdbtでスキーマ破壊を止める実装を解説【2026年版】：レジストリで止めきれない値の妥当性まで含めた取り決めの作り方を扱っています。
• Kafka Connectとは？構成要素とコネクタ運用を実装視点で解説【2026年版】：コンバータ設定でレジストリを参照する側の運用を整理しています。
• Amazon MSK（Managed Streaming for Apache Kafka）とは？仕組み・料金・使い方とKafka自前運用との違いを解説：AWS上でレジストリと組み合わせる基盤側の選定にあたる記事です。
• データベースのスキーマとは？三層スキーマ（外部・概念・内部）の違いと設計・管理の実務：同じ「スキーマ」でもデータベース内部の構造を扱う側の記事です。
• Debeziumとは？CDCコネクタの仕組みと運用設計を実装視点で解説：データベースの変更をトピックへ流す上流側の実装にあたります。