眼鏡店やレンズ加工ラボで「VCA通信」「VCAフォーマット」と呼ばれている、トレーサーや加工機（エッジャー）などの機器と PC の間でデータをやり取りするための規格を、実装する人向けに日本語で解説します。
あわせて、この規格のデータを読み書きできる JavaScript のライブラリと、自作のサンプルファイルを置いています。
前提とした版：The Vision Council Data Communication Standard v3.14（2025 年公開） この記事は規格書の翻訳ではなく、規格を読んだうえで要点を独自にまとめたものです。正確な定義は必ず公式の規格書で確認してください。
- VCA通信とは
- 登場する機器と役割
- 接続方式
- レコードの書き方
- パケットの構造
- 確認応答とタイムアウト
- セッションの流れ
- 玉型（トレース）データ
- 実装の手順
- つまずきやすい点
- このリポジトリの中身
- 参考資料
- 免責とライセンス
同じ規格がいくつもの名前で呼ばれています。
| 呼び方 | 由来 |
|---|---|
| VCA | 規格を管理する団体の旧名 Vision Council of America（2008 年に The Vision Council へ改称）。日本では「VCA通信」「VCAフォーマット」がよく使われる |
| OMA | さらに前の団体名 Optical Manufacturers Association（1999 年に統合されて VCA に）。英語圏ではこの呼び方が主流で、ファイル拡張子も .oma が多い |
| DCS | 正式名 Data Communication Standard の略 |
| OMAV | 規格のバージョンを表すレコード名（例：OMAV=3.14） |
英語で情報を探すときは「VCA」より「OMA」で検索したほうが見つかります（OMA file format、OMA TRCFMT など）。日本語で「OMA ファイル」と検索するとソニーの音声形式（同じ拡張子）が出てくるので注意してください。
- かつては ISO 16284 と ANSI Z80.24 としても出版されていました。v3.14 の前書きによると、どちらも取り下げられ、現在は The Vision Council の DCS が唯一の規格とされています。
- 日本の JIS T 7335:2005（眼鏡レンズ製造システム間の情報交換）は ISO 16284:2001 を基にしています。基本的な仕組みは同じですが、内容は 2000 年代前半のものです。
規格では、通信の両端を次のように呼びます。
- ホスト（host）：受注データや加工データを持つコンピュータ。ラボ管理システム（LMS）や店舗の PC。
- デバイス（device）：実際に作業する機械。トレーサー、加工機、カーブジェネレーター、ブロッカー、レンズメーターなど。
最も大事な原則は「通信は必ずデバイスから始める」ことです。ホストからデバイスに話しかけることはありません。デバイスが「このジョブのデータをください」「測定したデータを送ります」と要求し、ホストが応じます。
デバイスが何をしたいのかは、要求パケットの REQ レコードの値で表します。主なものは次のとおりです。
| 値 | 意味 | 方向 |
|---|---|---|
INI |
初期化（機器の自己紹介と取り決め） | 双方向 |
TRC |
トレーサーからの玉型送信 | アップロード（デバイス→ホスト） |
EDG |
加工機（エッジャー）へのデータ要求 | ダウンロード（ホスト→デバイス） |
GEN |
カーブジェネレーターへのデータ要求 | ダウンロード |
SBK / FBK |
ブロッカー（表面加工用／加工機用） | ダウンロード |
LMD |
レンズメーター | ダウンロード |
INS |
検査機器からの測定結果 | アップロード |
INF |
作業完了の通知 | アップロード |
UPL / DNL |
汎用のアップロード／ダウンロード | アップロード／ダウンロード |
FIL |
ファイルとして保存したデータ | 通信なし |
もともとの接続方式です。既定値は 9600 bps・データ 8 ビット・ストップ 1 ビット・パリティなしです。フロー制御を使う場合は RS-232C の制御線で行い、XON/XOFF（ソフトウェア制御）は使いません。
v3.04 から規定されています。通信の中身（セッション）はシリアルと全く同じで、通り道が TCP になるだけです。
| ポート | 用途 |
|---|---|
| 50000（既定） | デバイスが待ち受けるポート。ホストがここへ接続する（ローカル接続） |
| 33511 | オートコネクト用。デバイスが起動時に UDP ブロードキャストで「自分の IP とポート」を知らせる |
| 33512 | ホストが待ち受けるポート。デバイスから接続する（リモート接続） |
TCP で接続してから最初のセッションを始めるまで、デバイスは 3 秒待つ決まりです。後述の CRC はもともと省略できますが、TCP 自体に誤り検出があるため、ネットワーク接続では付ける意味がありません。
通信せずにファイルでやり取りする方法もあります（v3.02 から）。中身は後述のパケットとほぼ同じで、次の点だけが違います。
- パケットの開始・終了などの制御文字、
CRC、STATUSは入れない - 1 行目は
REQ=FIL、ジョブのデータなら 2 行目はJOB=... - 玉型データは形式 1（ASCII）のみ
「VCA ファイル」「OMA ファイル」と呼ばれるものの多くはこの形式です（機器やソフトによっては独自の拡張があります）。samples/ に例があります。
データは 1 行 1 項目の「レコード」の集まりです。
ラベル=値1;値2
-
ラベルと値の区切りは
=、値どうしの区切りは; -
左右（chiral）レコードは「右眼の値;左眼の値」の順
SPH=-2.25;-2.50 右 -2.25、左 -2.50 SPH=;-2.50 左眼だけの注文 DBL=18.0 左右の区別がない項目は値 1 つ -
左右レコードなのに値が 1 つしかない場合は、両眼に同じ値を使う（受け取る側はこれを許容する）
-
値が不明なときは
?を入れる（例：IPD=?;31.0） -
1 つの値の中に複数の数値を入れるときは
|で区切る -
ラベルは最大 16 文字。
_で始まるラベルは機器メーカーの試験用 -
知らないラベルは無視する（エラーにしない）
-
文字は ASCII の 32〜127（
;を除く）。文字列の欄だけは、初期化で取り決めれば UTF-8 も使える（TXTENCレコード） -
v3.03 より前は文字列を
"で囲むことがあったので、受け取る側は引用符を外せるようにしておく
- 長さは mm、角度は度、屈折力はディオプター
- カーブ（
FRNT・BACKなど）はTINDで指定された屈折率で換算したディオプター（既定は 1.53）。素材の屈折率LINDとは別物です - 凸面は正、凹面は負の値で表します
通信では、レコードを「パケット」にまとめて送ります。制御文字を <FS> のように表記すると、形は次のとおりです。
<FS>REQ=TRC<CR><LF>
JOB=A0001<CR><LF>
DEV=TRC<CR><LF>
<RS>CRC=12345<CR><LF>
<GS>
（CRC=12345 の値は説明用の仮の数字です）
| 文字 | コード | 役割 |
|---|---|---|
| FS | 0x1C | パケットの開始 |
| GS | 0x1D | パケットの終了 |
| RS | 0x1E | CRC レコードの直前に置く（CRC が無ければ GS の直前） |
| CR LF | 0x0D 0x0A | レコードの区切り |
| ACK | 0x06 | 受信成功の返事 |
| NAK | 0x15 | 受信失敗の返事 |
| ESC | 0x1B | バイナリデータ中のエスケープ |
順序の決まりは 3 つだけです。
- 最初のレコードは
REQ（要求）またはANS（応答） - 初期化以外では、2 番目は必ず
JOB（ジョブ番号）。ホストは受け取った形式のまま返す CRCを付けるなら最後
CRC は省略できます。付ける場合は CCITT CRC-16（多項式 0x1021、初期値 0。XMODEM と同じ計算）で、FS の次の文字から RS までの全文字を対象に計算し、10 進数で書きます。相手が CRC を付けてきたら、こちらも付けて返すのが推奨です。
// 確認用: "Hello World!" の CRC は 0x0CD3
function crc16(str) {
let crc = 0;
for (const ch of str) {
crc ^= (ch.charCodeAt(0) & 0xff) << 8;
for (let b = 0; b < 8; b++) crc = crc & 0x8000 ? ((crc << 1) ^ 0x1021) & 0xffff : (crc << 1) & 0xffff;
}
return crc;
}パケットを受け取った側は、1 文字の ACK か NAK を必ず返します。
- NAK を受けたら同じパケットを送り直す。再送は 3 回まで（合計 4 回 NAK なら中止して操作者にエラー表示）
- 決められた時間内に返事が来なければ、再送せずにセッションを中止します
| タイムアウト | 既定 | 内容 |
|---|---|---|
| 確認応答 | 6 秒 | パケット送信後、ACK/NAK が来るまで |
| パケット | 12 秒 | ACK を受けてから、相手のパケットが届き始めるまで |
| 文字間 | 5 秒 | パケット受信中、次の文字が来るまで |
この値は初期化時に TIMEOUT レコードで変更できます（2〜255 秒）。
1 つのジョブについての一連のやり取りを「セッション」と呼びます。セッションは途中で別のセッションと混ざることはなく、必ず 1 つずつ完結させます。
デバイス ホスト
<FS>REQ=TRC / JOB=A0001 <GS> →
← <ACK>
← <FS>ANS=TRC / JOB=A0001 / STATUS=0 <GS>
<ACK> →
<FS>ANS=TRC / JOB=A0001 /
TRCFMT=... / R=... <GS> →
← <ACK>
← <FS>ANS=TRC / JOB=A0001 / STATUS=0 <GS>
<ACK> →
ホストが返す STATUS が 0 以外なら、そこでセッションは失敗です。
デバイス ホスト
<FS>REQ=EDG / JOB=A0001 <GS> →
← <ACK>
← <FS>ANS=EDG / JOB=A0001 / STATUS=0 /
（加工に必要なレコード一式）<GS>
<ACK> →
電源投入時などに、デバイスが自分の情報（メーカー VEN、機種 MODEL、種別 DEV など）や、対応できる玉型形式（TRCFMT）をホストに伝えるセッションです。必須ではありませんが、強く推奨されています。
- 自動フォーマット初期化：デバイスが「今後このレコード一式を送ってほしい」というリストを
DEF・D・ENDDEFレコードで送ります。ホストはそのリストに要求 ID（整数）を割り当てて返し、以後デバイスはREQ=要求IDで要求します。 - ホストが再起動して要求 ID を忘れた場合などは、ホストが
STATUS=5（初期化が必要）を返し、デバイスは初期化をやり直します。 - 初期化しない機器は
REQ=EDGのような決まった種別で要求します（簡易モード）。
| コード | 意味 |
|---|---|
| 0 | 正常 |
| 1 | ジョブが見つからない |
| 3 | 一般エラー（内容は説明欄） |
| 4 | この機器向けには処理できないジョブ |
| 5 | 初期化が必要 |
| 7 | 必要なレコードが不足 |
| 10 | 値が範囲外 |
| 14 / 15 | 自動フォーマット初期化に非対応／初期化に非対応 |
| 17 | 非対応の玉型形式 |
フレームの形は、中心からの半径を角度ごとに並べたデータで表します。
玉型データは必ず TRCFMT から始まり、直後に半径の R レコードが続きます。
TRCFMT=形式;点数;角度モード;眼;対象
| 項目 | 値 |
|---|---|
| 形式 | 0 データなし（この場合は項目 1 つだけ）／1 ASCII／2 バイナリ絶対値／3 バイナリ差分／4 パックトバイナリ |
| 点数 | 半径の個数（400 や 512 など） |
| 角度モード | E 等角度／U 不等角度（A レコードで角度を送る）／C 自由（角度が戻ってもよい。v3.09〜） |
| 眼 | R 右／L 左（初期化と要求では B 両眼も可） |
| 対象 | F フレーム／P 型板／D デモレンズ |
両眼分を送るときは、右眼と左眼それぞれに TRCFMT を付けます。
- 形式 1 の半径は 1/100 mm 単位の 4 桁の整数。例：
2479は 24.79 mm - 1 行は 80 文字以内なので、
R=が何行にも分かれます - 角度（
A）も 1/100 度単位の整数で、0〜35999 - 立体形状（サグ）は
ZFMTとZ・ZAで同様に送ります
TRCFMT=1;360;E;R;F
R=2490;2492;2495;2499;2504;2509;2515;2521;2528;2535;2543;2552;2560;2569;2577
R=...
（samples/frame-right.vca の冒頭。0° の半径は 24.90 mm）
- 最初の点は 0°（時計の 3 時の方向）で、反時計回りに並べる
- 検者が装用者を正面から見た向きで表す。このため、右眼のデータは鼻側から、左眼のデータは耳側から始まる
- 右眼用のデータを左眼に使うときは、左右反転（角度 θ → 180° − θ）する
- 半径の基準は玉型の幾何中心（ホストが意図的にずらす場合は
FBFCIN・FBFCUPでずれ量を示す） HBOX（横幅）、VBOX（縦幅）、CIRC（周長）は、送った半径データの形と一致していなければならない
- 形式 2：半径 1 つを 16 ビット整数（下位バイトが先）で表す
- 形式 3：最初の半径は 16 ビット、以降は前の値との差を符号付き 1 バイトで表す。差が大きすぎるときは
0x80を置き、続く 2 バイトを絶対値とする - 形式 4：16 ビット・8 ビット・4 ビットの 3 種類を切り替えて詰め込む、最も効率のよい形式（規格書の附属書 B に完全な例あり）
- バイナリ中に予約制御文字（FS・GS・RS・CR・LF・ACK・NAK・ESC など）と同じ値のバイトが出たら、ESC を前に置き、そのバイトの最上位ビットを立てて送る（例：0x0A → 0x1B 0x8A）。受け取る側は逆の処理をする
- CRC はエスケープ後のデータで計算する
玉型データを受け取って使うまでの流れです。
- 受信：FS から GS までをためる。文字間 5 秒を超えたら中止
- 確認応答：CRC があれば検証し、ACK か NAK を返す
- 分解：CR/LF で行に分け、
ラベル=値を取り出す。知らないラベルは読み飛ばす - トレースの復元：
TRCFMTの形式に従って半径（と角度）を取り出す。バイナリ形式ならエスケープを戻してから復号する - 座標に変換：i 番目の点の角度は、等角度なら
i × 360 / 点数。半径 r と角度から x = r cos θ、y = r sin θ - 眼の向きを合わせる：必要なら左右反転
このリポジトリの src/vca-parser.js を使うと、3〜6 は次のように書けます。
const data = VCA.parse(fileText); // ファイル内容（1 文字 = 1 バイト）
const trace = data.traces.find(t => t.eye === 'R') || data.traces[0];
const points = VCA.tracePoints(trace, 'R'); // 右眼の向きの座標列（mm）
const { hbox, vbox } = VCA.boxOf(points); // 横幅・縦幅
const ipdRight = VCA.sideNumber(data.rec.IPD, 'R');ファイルを読むときは、バイナリ形式が壊れないよう UTF-8 として解釈せず、1 バイト = 1 文字で読み込んでください（ブラウザなら file.arrayBuffer() → VCA.bytesToString()）。
玉型データが表すのは、箱の中心を基準にした形だけです。眼の位置との関係は、次のような別のレコードで送られます。
MPD：フレーム PD。左右のHBOXの平均にDBLを足した値IPD：片眼の中心間距離（いわゆる片眼 PD）OCHT：箱の下端から測ったプリズム基準点（PRP）の高さ。光学中心の高さではない点に注意
- データが来ない：初期化に応答していない、ACK を返していない、通信速度などの設定が違う、のどれかが多い原因です
- 機種によってはバイナリ形式で送ってくる：初期化で対応形式を伝えるか、機器側の設定で形式 1 に変える
UとCの違い：Uは角度が順に増える、Cは角度が戻ってもよい（鍵穴のような形）。Cは等角度データに変換できない- 左右の値の扱い：値が 1 つなら両眼、空欄や
?は「不明」 - カーブの符号：凸面は正、凹面は負。眼鏡レンズの後面は通常凹面なので、
BACKは負の値になる TINDとLIND：カーブはTIND（既定 1.53）基準、素材の屈折率はLINDDBLは左右の区別がない：値は 1 つ- 引用符：古い機器は文字列を
"で囲んで送ってくることがある
README.md この記事
docs/records.md よく使うレコードの一覧（日本語）
src/vca-parser.js VCA データの読み書きライブラリ
tests/run-tests.html ライブラリのテスト（ブラウザで開くだけで実行）
samples/*.vca 自作のサンプルファイル（右眼、両眼、不等角度）
- レコードの解析（左右の値、
?、引用符、_ラベルに対応） - 玉型データの復元：形式 1・2・3、角度モード E・U・C、ZFMT（サグ）
- 座標への変換、左右反転、HBOX・VBOX・周長の計算
- パケットの組み立てと分解、CRC-16 の計算と検証
- 形式 4（パックトバイナリ）は未対応
- ブラウザでは
<script>で読み込むとwindow.VCAとして使えます。Node.js 向けにrequireでも読み込める書き方にしてありますが、動作確認はブラウザでのみ行っています
- The Vision Council, Data Communication Standard v3.14（2025）：規格の原文（英語、無料） https://thevisioncouncil.org/sites/default/files/assets/media/DCS_v3.14_Final.pdf
- The Vision Council 技術フォーラム（DCS の Q&A） https://forums.thevisioncouncil.org/
- JIS T 7335:2005 眼鏡レンズ製造システム間の情報交換：日本産業標準調査会（JISC）の JIS 検索で閲覧できます
- OptiBoard（眼鏡業界の英語フォーラム）の OMA 関連スレッド
- eeng/lens_protocol：Ruby による OMA パーサー
- この記事とコードは個人が規格を読んで作成したもので、The Vision Council や JIS とは関係ありません。規格への準拠を保証するものではありません。実機との接続に使う場合は、機器メーカーの資料と規格の原文で確認してください。
- The Vision Council、VCA、OMA、Data Communication Standard などの名称は、それぞれの権利者に帰属します。このリポジトリは公式のものではなく、権利者から承認や支援を受けたものでもありません。
- 文章（README.md と docs/）は © 2026 Nriv、CC BY 4.0 で提供します。コードは MIT License です。
- これらのライセンスが対象とするのは、このリポジトリの文章とコードだけです。規格そのものの著作権は The Vision Council に帰属し、ここでは許諾していません。