Appearance
バージョン管理・改訂履歴の運用
このページでできるようになること
Jw_cadで描いた建築図面を、案件の進行とともに どう改訂し・どう記録し・どう追跡するか の運用ルールが理解できるようになります。改訂のたびに版番号をどう振るか、表題欄の改訂履歴欄に何を書くか、旧版を作業フォルダから外してどこに退避するか、確認申請の前と後で改訂運用がどう変わるか、Dropbox／OneDrive／Google Driveの「バージョン履歴」機能や Git をどう併用するか、PERSC編集部が推奨する案件規模別の運用パターン3種までを通しで身につけます。
ファイル名側の命名規則は ファイル命名規則 に、表題欄の改訂履歴欄レイアウトは 表題欄の項目と配置ルール に、フォルダ構成の詳細は フォルダ構成・プロジェクト管理 にそれぞれ委譲しており、この記事は 「変更をどう記録し追跡するか」 の運用解説に集中します。
背景: 建築図面は、初回作成から完了検査までの間に 平均で5〜10回前後の改訂 が発生します。確認申請の指摘修正、施主からの仕様変更要望、現場での施工性確認による微修正、完了検査前の最終チェックなど、変更が起きるタイミングは多数あります。「最新版がどれか分からない」「申請時の図面が再現できない」「同じ案件で複数の版が並走して上書き事故が起きた」というトラブルは、運用ルールが曖昧な現場でほぼ確実に発生します。Jw_cad自体には改訂履歴を強制する機能はないため、運用ルール側で揃えるのが基本です。
要確認: 確認申請後の計画変更・軽微な変更の境界、電子納品要領の改訂管理規定など、行政運用に関わる項目は実機検証フェーズで一次情報を再確認します。
改訂とは何か（用語の整理）
建築実務でよく使われる「改訂」「修正」「変更」「リビジョン」「バージョン」は、近い意味ながら使われる場面が違います。最初に用語を揃えておきます。
| 用語 | 意味 | 使われる場面 |
|---|---|---|
| 修正 | 作成途中の細かな書き換え | 案件キックオフ〜初回提出までの作業内 |
| 改訂（リビジョン） | 提出済み版に対する正式な書き換え | 確認申請の指摘対応・施主指摘対応 |
| 変更 | 確認申請後の計画変更 | 計画変更確認申請・軽微な変更 |
| バージョン（版） | 時点を特定するための版番号 | 改訂のたびに版を切る |
| スナップショット | 特定時点の状態を退避保存したもの | 確認申請提出時・完了検査時など節目で取得 |
背景: 「修正」は 記録を残さない書き換え、「改訂」は 記録を残す書き換え という区別で運用するのが一般的です。同じ図面に対する1回目の書き換えでも、提出前なら「修正」、提出後なら「改訂」になります。「バージョン」と「リビジョン」は実務ではほぼ同義で使われますが、後述のとおり厳密には少し違う使い分けがあります。
バージョンとリビジョンの違い
| 用語 | 意味 | 例 |
|---|---|---|
| バージョン（Version） | 大きな変更単位。図面の趣旨や前提が変わるレベル | 確認申請版 → 実施設計版 → 施工版 |
| リビジョン（Revision） | バージョン内での小さな修正単位 | 実施設計版 v1 → v2 → v3 |
実務では両者を厳密に分けず 「リビジョン番号」一本で運用 する事務所が多いですが、規模の大きい案件ではバージョン＋リビジョンの2階層で管理することもあります。Ch.11の他記事と同じく、本マニュアルでは特記がない限り「バージョン番号 ≒ リビジョン番号」として扱います。
版番号の振り方
建築図面の改訂を追跡する版番号には、大きく分けて アルファベット系・数字系・日付系・併用系 の4方式があります。事務所単位でどれかに統一して、案件途中で切り替えないのが基本です。
4方式の比較
| 方式 | 例 | 利点 | 欠点 | 向く案件 |
|---|---|---|---|---|
| アルファベット系 | A／B／C／D… | 「Rev. A」のような国際標準的表記。改訂回数の上限が事実上ない（A〜Z＋AA〜） | 改訂回数の感覚が掴みづらい | 公共工事・実施設計 |
| 数字系 | 0／1／2／3… または v1／v2／v3 | 改訂回数が直感的 | 「v0」と「v1」のどちらが初版か事務所で揺れる | 個人事務所・住宅案件 |
| 日付系 | 20260501／2026-05-01 | 改訂日が一目で分かる | 同日改訂が複数あると区別困難 | 短期完結案件 |
| 併用系 | v1_20260501 | 版番号と日付の両方が分かる | ファイル名・表題欄が長くなる | 確認申請を経由する案件 |
PERSCの推奨: 個人事務所・小規模事務所の住宅案件では 数字系（v1／v2／v3） が最もシンプルで運用負荷が低いです。中〜大規模事務所・公共工事では アルファベット系（A／B／C） が国際慣行に沿っており、海外発注やBIM連携の可能性も含めて将来安全です。事務所単位でどちらかを選び、全案件で揃えるのを推奨します。
版番号運用の3つの分岐パターン
実務では、改訂のフェーズによって版番号体系を切り替える運用も使われます。
| パターン | 運用 | 場面 |
|---|---|---|
| 通し番号運用 | 着手から完了検査まで v1〜vN の通し番号 | 案件全体の改訂回数が少ない（〜10回程度） |
| フェーズ別運用 | 確認申請前は v1〜vN、申請後は r1〜rN、施工段階は s1〜sN | 改訂回数が多くフェーズで意味が違う |
| 大版＋小版運用 | 提出版で大版（A／B／C）を切り、フェーズ内修正で小版（A.1／A.2） | 大規模・公共工事 |
背景: 確認申請の前と後では、改訂の 法的意味合い が大きく変わります。申請前の修正は社内の作業履歴ですが、申請後の変更は計画変更確認申請または軽微な変更届の対象になります。版番号体系をフェーズで切り替えると、「この版は申請前か後か」が一目で判別できるようになります。
初版の番号付け
新人がよく迷うのが 「初版を何番にするか」 です。事務所ごとに流派があります。
| 流派 | 初版 | 解説 |
|---|---|---|
| ゼロ起点 | v0 | 製図前の素描・たたき台を v0 とし、社内承認後を v1 とする |
| イチ起点 | v1 | 最初の作図完了時点を v1 とする（最も直感的） |
| ドラフト＋本番 | draft → A | 製図前は draft、社内承認後を A とする |
PERSCの推奨: 個人事務所では イチ起点（v1） が最も迷いません。「最初の図面 = v1、その後の改訂 = v2／v3...」と覚えるだけで運用できます。テンプレ規約書に「初版はv1とする」と1行明記しておくと、新人も迷いません。
改訂履歴欄への記入ルール
表題欄に隣接して配置される 改訂履歴欄 は、改訂のトレース情報を集約する領域です。表題欄レイアウトの詳細は 表題欄の項目と配置ルール に委譲しており、ここでは 「何を書くか」 の運用ルールに集中します。
改訂履歴欄に必ず書く4項目
| # | 項目 | 内容 | 記載例 |
|---|---|---|---|
| 1 | リビジョン番号（Rev.） | この改訂の版番号 | A／B／v2／v3 |
| 2 | 改訂日 | 改訂を反映した日付 | 2026-05-12 |
| 3 | 改訂者 | 改訂を行った担当者 | 山田／YT |
| 4 | 改訂内容 | 改訂の概要を1行で要約 | 「玄関建具寸法変更」「基礎深さ修正」 |
背景: 改訂内容欄は 1行・15〜25文字 が読みやすさの上限です。それ以上長くなる場合は、改訂内容の詳細を別途「改訂内容説明書」として図面外に作成し、改訂履歴欄には「○○変更（説明書R3-1参照）」のように参照先を書きます。改訂履歴欄に長文を詰め込むと、後で読み返すときに視認性が落ちます。
改訂内容の書き方
改訂内容欄は 動詞＋目的語 の形式で簡潔に書くのが推奨です。
| 良い例 | 悪い例 | 理由 |
|---|---|---|
| 「玄関建具寸法変更」 | 「変更しました」 | 何を変えたか分からない |
| 「基礎深さ -100mm」 | 「基礎修正」 | 修正の方向と量が不明 |
| 「外壁仕上げ追加」 | 「外壁」 | 動詞がなく曖昧 |
| 「指摘事項No.3対応」 | 「対応済み」 | 何の対応か特定できない |
PERSCの推奨: 改訂内容欄は 「何を／どう／なぜ」を15文字以内に圧縮 する練習を新人時代に積むのが効きます。「玄関建具W900→W1200」のように 数値で書ける部分は数値で 書くと、後から見返したときの情報密度が上がります。
改訂回数が多くなった場合
改訂が10回を超えるような長期案件では、改訂履歴欄を 複数の図面または別紙に分割 します。
| 対応 | タイミング |
|---|---|
| 改訂履歴欄の行数を増やす | 5回程度まで |
| 改訂履歴欄の文字サイズを下げる | 8〜10回程度まで |
| 改訂内容説明書を別紙化 | 10回超 |
| 図面ごとに改訂履歴を分離 | 案件全体で20回超 |
注意: 改訂履歴欄の行を 古い順から削除しない こと。古い改訂を削除すると、過去にどんな指摘でどう修正したかのトレースが切れます。スペースが足りなくなったら別紙化が原則です。
改訂表示の図面本体への反映
図面本体の改訂箇所には、改訂を示す マーキング を入れる慣行があります。
| マーキング | 配置 | 意味 |
|---|---|---|
| 雲マーク（リビジョンクラウド） | 改訂箇所を囲う雲形の線 | 「ここが今回の改訂対象」 |
| △記号＋リビジョン番号 | 改訂箇所の近傍 | 「△A：今回のRev.Aで変更」 |
| 線色変更 | 改訂箇所のみ別色 | 視覚的に強調（社内運用） |
背景: リビジョンクラウド（雲マーク）は、AutoCADやRevit等の他CADで標準機能化されている表記法で、Jw_cadでも手作業で同等の表現を作れます。改訂箇所を一目で示すために、特に確認申請後の修正や施工図への反映で多用されます。
PERSCの推奨: 確認申請後の改訂・施工図への反映時は、リビジョンクラウドまたは△記号を 必ず 入れることを推奨します。改訂箇所が一目で分かることで、行政・施工者・施主からの問い合わせコストが大きく下がります。
旧版退避と参照履歴
改訂が発生した時点で、旧版をどう保管するかの運用です。命名規則の章でも触れましたが、改訂履歴側の視点から再整理します。
旧版退避の3パターン（再掲）
| パターン | 運用 | 評価 |
|---|---|---|
| 上書き保存のみ | 改訂のたびに上書き | 旧版が辿れない・最も非推奨 |
| 別名保存で履歴蓄積 | _v1→_v2→_v3 と連続保存 | 履歴は完全だが作業フォルダが肥大化 |
| 旧版を別フォルダ退避 | 最新版のみ作業フォルダ、旧版は _archive/ 等へ | 作業効率と履歴管理を両立 |
詳しくは ファイル命名規則 を参照してください。
スナップショットを取得すべき節目
旧版退避は「全改訂を残す」のではなく、節目でスナップショットを取得 するのが運用負荷の低い方法です。
| 節目 | 退避すべき理由 |
|---|---|
| 案件キックオフ後の社内合意版 | 起点を残しておくと後で「最初はこうだった」を参照できる |
| 確認申請提出版 | 申請時の図面は 法的に重要。後で行政や検査機関から再提示を求められる場合がある |
| 各回の指摘修正後 | 指摘事項への対応履歴として |
| 着工前の確定版 | 施工者に渡した版を再現可能にしておく |
| 中間検査・完了検査時 | 検査時点の図面の証跡 |
| 引渡時の最終版 | 竣工図書としての確定版 |
PERSCの推奨: 上記6つの節目では 必ず
_archive/{日付YYYYMMDD}/フォルダにフルセットを退避 することを推奨します。改訂のたびに毎回スナップショットを取ると_archive/が肥大化するため、節目だけに絞ります。日々の細かい改訂は版番号付きファイルで履歴を蓄積し、節目で_archive/にフルコピーする二段運用が現実的です。
スナップショットフォルダの命名
_archive/ 配下のスナップショットフォルダは、日付＋意味 の組み合わせで命名すると後から参照しやすくなります。
_archive/
├ 20260415_確認申請提出/
├ 20260420_第1回指摘修正/
├ 20260428_第2回指摘修正/
├ 20260512_着工前確定/
├ 20260901_中間検査/
└ 20270301_完了検査/背景: 日付だけのフォルダ名（
20260415/）でも機能しますが、半年〜1年後に参照する際に「これがどの節目だったか」を思い出すのに時間がかかります。日付＋意味の併記なら、フォルダ名を見ただけで案件の進行段階が分かります。
注意: スナップショットフォルダの中身は 「その時点で確定済みの全図面」 を入れます。一部の図面だけを入れると、後で「この時点での平面図はあるが立面図がない」状況が発生し、再現性が崩れます。
参照履歴の運用
過去版を参照したい場面では、_archive/ から該当版を 読み取り専用で開く のが基本です。
| 操作 | 方法 |
|---|---|
| 過去版を確認したい | _archive/{日付}/{ファイル名}.jww を Jw_cad で開く |
| 過去版を再利用したい | コピーしてから作業フォルダに戻し、新しい版番号で別名保存 |
| 過去版と最新版を比較したい | 両方を別ウィンドウで開いて比較 |
注意:
_archive/配下のファイルは 絶対に上書き保存しない こと。間違えて上書きすると過去スナップショットが破壊されます。可能なら_archive/配下を 読み取り専用属性 に設定するか、OneDrive／Dropbox の「ロック」機能 で改変防止をかけるのが安全です。
確認申請後の変更の扱い
確認申請を経由する案件では、申請の前と後で 法的な変更ルール が変わります。改訂運用の中で最も注意が必要なフェーズです。
確認申請後の変更3区分
確認申請が下りた後の変更は、建築基準法施行規則3条の2が定める 「軽微な変更」 に該当するかどうかで対応が変わります。
| 区分 | 必要な手続き | 例 |
|---|---|---|
| 軽微な変更 | 完了検査時に変更内容を申告 | 室名変更／仕様グレード変更 |
| 計画変更（軽微以外） | 計画変更確認申請の提出（再審査） | 階数変更／用途変更／構造変更 |
| 軽微の判断が難しい | 事前に行政・検査機関に確認 | 開口部位置の変更／構造耐力に関わる変更 |
要確認: 軽微な変更の境界は、建築基準法施行規則3条の2の最新条文と、指定確認検査機関ごとの運用差を実機検証フェーズで確認します。本文の記述は概念的な区分にとどめ、案件着手時には必ず最新の運用を確認します。
申請後の改訂を図面に反映する手順
| # | 手順 | ポイント |
|---|---|---|
| 1 | 申請時の図面を _archive/ から取り出す | 上書きせずコピーで作業 |
| 2 | 新しい版番号で別名保存 | 例: A-101_r2.jww（申請版が r1 だった場合） |
| 3 | 改訂箇所にリビジョンクラウド／△記号を配置 | 改訂対象を視覚化 |
| 4 | 表題欄の改訂履歴欄に1行追記 | Rev./日付/改訂者/内容 |
| 5 | 軽微な変更／計画変更の判断 | 行政・検査機関に確認 |
| 6 | 計画変更確認申請が必要なら申請書類作成 | 申請後の改訂版を新しい申請の添付図面とする |
背景: 申請後の改訂を申請前と同じ感覚で行うと、完了検査時に「申請図と現状図が違う」と指摘 されて検査が止まります。計画変更確認申請が必要なケースで未申請のまま着工すると、最悪の場合、検査済証が下りず建物が使用できなくなります。
PERSCの推奨: 確認申請後の図面変更は 「指摘前」に行政・指定確認検査機関に電話確認 するのを推奨します。「これは軽微な変更で大丈夫ですか？」の一本の電話で判断が済めば、計画変更申請を回避できます。判断が分かれそうな変更は躊躇なく問い合わせる文化を事務所内に作ると、トラブル予防になります。
軽微な変更の記録
軽微な変更で済むレベルの改訂でも、社内の改訂履歴には必ず残します。
| 記録先 | 内容 |
|---|---|
| 改訂履歴欄 | Rev./日付/改訂者/「軽微：○○変更」 |
_archive/ | 変更前後の版を両方残す |
| 完了検査図書 | 軽微な変更を一覧化した「軽微な変更一覧表」を別途作成 |
PERSCの推奨: 軽微な変更は数が多くなりがちです。改訂のたびに 「軽微な変更一覧表」 を更新する習慣をつけると、完了検査時に検査機関へ提示する際にゼロから作る必要がなくなります。Excel または図面と同階層に Markdown ファイルで管理するのが扱いやすいです。
クラウドベース管理の併用
近年は Dropbox／OneDrive／Google Drive／Box などのクラウドストレージを設計事務所が標準的に使うようになり、各サービスが備える 「バージョン履歴」機能 との併用が現実的な選択肢になっています。
主要クラウドサービスのバージョン履歴機能
| サービス | バージョン履歴の遡れる範囲 | 備考 |
|---|---|---|
| Dropbox | 30日（無料）／180日（Plus）／1〜10年（Business） | 全ファイル自動取得 |
| OneDrive | 直近25〜500世代（プランによる） | 個人版・Business版で差 |
| Google Drive | 30日または100世代まで（個人）／無制限（Workspace有料） | バイナリファイルでも世代管理 |
| Box | 100世代まで（プランによる） | 法人向けで強い |
要確認: 各サービスの世代管理仕様は頻繁に変更されます。実機検証フェーズで最新仕様を確認します。プラン変更でも仕様が変わるため、案件着手時に契約プランを確認する運用が必要です。
クラウド版管理機能の利点と限界
| 観点 | 利点 | 限界 |
|---|---|---|
| 自動性 | 上書き保存が自動でクラウド側にバージョン蓄積される | 意図しない上書きも全て履歴化される |
| 取得範囲 | 全ファイルを横断的に世代管理 | 「節目」の意味は付かない（全自動） |
| 復元の容易さ | クラウドのUI上から数クリックで復元 | 復元時に作業中の最新版を上書きする事故が起きやすい |
| 比較機能 | テキストファイルなら差分表示可能 | .jwwはバイナリのため差分比較ができない |
| ストレージ | 数十GBの履歴も自動で抱える | 履歴が肥大化する案件ではプラン圧迫 |
背景: クラウドの「バージョン履歴」は Jw_cad の上書き保存ごとに無条件で世代を取る ため、社内ルールでの「節目スナップショット」とは別の粒度で動いています。両者は競合せず 併用する のが正解です。クラウド側は「事故時の安全網」、
_archive/側は「意図的な節目記録」と役割を分けます。
クラウド併用時の推奨運用
| 役割 | 担当 |
|---|---|
| 自動の安全網 | クラウド（Dropbox／OneDrive 等）の自動バージョン履歴 |
| 意図的な節目記録 | _archive/{日付}_{意味}/ フォルダへのフルコピー |
| 共同編集の競合管理 | クラウドの「ロック」「チェックアウト」機能 |
| バージョン番号管理 | ファイル名の _v1／_r1 |
PERSCの推奨: 個人事務所・小規模事務所では 「クラウドの自動バージョン履歴 +
_archive/での節目スナップショット + ファイル名の版番号」 の3層を同時に運用するのを推奨します。一見冗長ですが、それぞれの役割が違うため、どれか1つ欠けると事故時に取り返しがつかなくなります。
クラウド併用の注意点
| 注意点 | 内容 |
|---|---|
| 同時編集の禁止 | Jw_cadは複数端末から同じファイルを開くと上書き衝突する。クラウドの「ロック」を活用 |
| オフライン編集の混乱 | 出先でオフライン編集→帰社で同期する際に競合が起きる。同期完了を確認してから次の作業へ |
| バージョン履歴の自動削除 | 無料プランは30日で自動削除されることが多い。重要な節目は別途 _archive/ に明示退避 |
| 個人情報の取り扱い | 施主情報を含むファイルのクラウド利用は契約・規約を確認 |
注意: クラウドの自動バージョン履歴を 「節目スナップショットの代替」と過信しない こと。プラン変更・契約解除・サービス側の仕様変更で履歴が消える可能性があります。重要な節目は
_archive/に明示退避するのが安全です。
Gitによる改訂管理（応用）
ITエンジニアリング領域では標準的な Git によるバージョン管理は、Jw_cad の .jww がバイナリファイルである制約から、建築実務では限定的な使われ方になります。ただし、組織によっては有効な選択肢になります。
Gitで.jwwを管理するときの実態
| 観点 | 実態 |
|---|---|
| バイナリ管理 | Git は .jww バイナリも記録できる。ただし差分比較は不可 |
| Git LFS 併用 | .jww は数MB〜十数MBになるため Git LFS（Large File Storage）併用が現実的 |
| コミットメッセージで履歴記録 | 「指摘No.3対応」のようにメッセージで改訂内容を残せる |
| ブランチ運用 | 申請版／実施版／施工版をブランチで分けられる |
| 差分の閲覧 | バイナリのため git diff で内容差分は見えない（コミット単位の存在のみ確認可能） |
背景: Gitは元来テキストファイル（プログラムのソースコード）の差分管理を目的としたツールであり、バイナリの設計図面に対しては差分比較ができません。建築実務でGitを使う場合は 「コミットメッセージで改訂内容を記録する履歴管理ツール」 として割り切る運用が現実的です。
Gitを採用するメリットがある組織
| 組織タイプ | 採用メリット |
|---|---|
| 開発元IT企業の建築部門 | 既存のGitインフラ・運用文化が活かせる |
| BIM/プログラム連携が多い設計事務所 | Revit／Dynamo／Grasshopper 等のスクリプトと一緒に管理できる |
| 大学・研究機関 | 研究プロジェクトの記録管理に整合 |
| オープンソース図面の公開 | GitHub／GitLab で図面を公開する場合 |
PERSCの推奨: 一般的な個人事務所・中小設計事務所では Gitは採用不要 です。Git LFS の運用負荷・学習コストに対して、得られるメリットが少ないためです。前述のクラウドストレージ＋
_archive/の組み合わせで十分機能します。Gitは「すでに事務所内でGitを日常的に使っているケース」に限り採用するのを推奨します。
PERSC編集部の推奨運用パターン
ここまでの内容を、案件規模別の 推奨運用パターン3種 にまとめます。自社の運用整備の出発点として活用してください。
パターンA：個人事務所・住宅案件
最小構成で運用負荷を抑えるパターン。クラウドストレージの自動バージョン履歴を活用する。
| 要素 | 運用 |
|---|---|
| 版番号 | 数字系（v1／v2／v3） |
| 初版 | v1（イチ起点） |
| ファイル名末尾 | {施主名}_{図面種別}_v{番号}.jww |
| 改訂履歴欄 | 表題欄内に4行確保 |
| 旧版退避 | クラウド自動 + 節目で _archive/{日付}_{意味}/ に手動退避 |
| 節目スナップショット | 確認申請提出時 / 完了検査時 の最低2回 |
| クラウド | Dropbox または OneDrive（個人プラン） |
| Git | 採用しない |
例:
山田邸/
├ 図面/
│ ├ 山田邸_平面図_v3.jww ← 最新
│ └ 山田邸_立面図_v2.jww ← 最新
└ _archive/
├ 20260415_確認申請提出/
│ ├ 山田邸_平面図_v1.jww
│ └ 山田邸_立面図_v1.jww
└ 20270301_完了検査/
├ 山田邸_平面図_v3.jww
└ 山田邸_立面図_v2.jww| 採用理由 |
|---|
| 改訂回数が比較的少ない（5〜10回程度） |
| クラウドの自動履歴で日常の事故対応は十分 |
| 節目スナップショット2回で法的要件もカバー |
パターンB：中規模設計事務所・実施設計案件
申請前後の運用差を版番号でも明示するパターン。
| 要素 | 運用 |
|---|---|
| 版番号 | 申請前は v1〜vN、申請後は r1〜rN |
| 初版 | v1（イチ起点） |
| ファイル名末尾 | {案件番号}_{図番}_{図面種別}_{版}.jww |
| 改訂履歴欄 | 表題欄内に5〜6行確保 |
| 改訂表示 | リビジョンクラウド or △記号を申請後改訂で必須 |
| 旧版退避 | 節目ごとに _archive/{日付}_{意味}/ |
| 節目スナップショット | キックオフ／確認申請／指摘修正各回／着工前／中間検査／完了検査 |
| クラウド | Business プラン（180日以上の履歴保持） |
| Git | 採用しない（クラウドで十分） |
例:
2026A001_○○邸/
├ 図面/
│ └ 2026A001_A-101_平面1階_r3.jww ← 申請後3回目改訂
└ _archive/
├ 20260301_キックオフ/
├ 20260415_確認申請提出/
├ 20260420_第1回指摘修正/
├ 20260428_第2回指摘修正/
├ 20260512_着工前確定/
├ 20260901_中間検査/
└ 20270301_完了検査/| 採用理由 |
|---|
| 申請前後の運用差が版番号で一目で分かる（v→r 切替） |
| 改訂回数が多い案件（10〜20回程度）に対応 |
| 中間検査・完了検査時の証跡が完備 |
パターンC：公共工事・電子納品案件
公共工事の電子納品要領に整合させるパターン。
| 要素 | 運用 |
|---|---|
| 版番号 | アルファベット系（A／B／C） |
| 初版 | A（社内承認後） |
| ファイル名末尾（社内） | {社内案件番号}_{図番}_{図面種別}_{版}.jww |
| ファイル名末尾（納品） | 電子納品要領準拠（8文字＋拡張子、改訂桁を末尾に） |
| 改訂履歴欄 | 表題欄内に6〜8行確保 |
| 改訂表示 | リビジョンクラウド + △記号を全改訂で必須 |
| 旧版退避 | 節目ごとに _archive/ + 納品ファイルを別フォルダに集約 |
| 節目スナップショット | 設計協議各回／確認申請／施工着手／中間検査／完了検査／納品 |
| クラウド | Business プラン or オンプレサーバ（公共工事の情報管理要件に応じて） |
| Git | 採用しない |
要確認: 電子納品要領の改訂桁（ファイル名8桁目）の運用ルールは、最新の電子納品要領で確認します。本文の記述は概念的な対応にとどめ、案件着手時に必ず最新版を参照します。
| 採用理由 |
|---|
| 電子納品要領の固定長フォーマットに整合 |
| 公共工事の長期保管要件に対応（20年超の参照可能性） |
| アルファベット系の版番号は国際慣行・公共工事の双方に整合 |
PERSCの推奨: 自社の主案件タイプに最も近いパターンを テンプレート規約書 として1ページにまとめ、新規案件のキックオフ時に関係者に配布する運用を推奨します。途中で運用を変えると、過去ファイルの一括変更が必要になるため、案件単位で運用を固定します。
実務での使い方 ★PERSC独自
改訂運用は「キックオフで規約を決める」
ファイル命名規則と同じく、改訂運用も 案件キックオフ時に規約として決定 するのが最善のタイミングです。後から決めると過去改訂のリトレースが必要になり、関係者への通知コストが膨らみます。
PERSC編集部の推奨する 「改訂規約1ページ」のテンプレート は次の構成です。
markdown
# プロジェクト 改訂規約
## バージョン番号体系
- 数字系（v1／v2／v3）／申請前
- リビジョン系（r1／r2／r3）／申請後
## 改訂履歴欄の記入
- Rev./日付/改訂者/内容（15文字以内）
- 例：「玄関建具W900→W1200」
## 改訂表示
- 申請前修正：マーキング不要
- 申請後改訂：リビジョンクラウド必須＋△A記号
- 軽微変更：△A記号のみ可
## 節目スナップショット
- キックオフ / 確認申請 / 各回指摘修正 / 着工前 / 中間検査 / 完了検査
- `_archive/{日付YYYYMMDD}_{意味}/` に全図面退避
## 旧版アクセス制限
- `_archive/` 配下は読み取り専用属性
- クラウドのロック機能を併用
## 軽微な変更の取り扱い
- 改訂履歴欄に「軽微：○○変更」と明記
- 別途「軽微な変更一覧表」を完了検査用に整備
## クラウド併用
- Dropbox Business（180日履歴）
- 自動履歴 + `_archive/` の二重管理PERSCの推奨: この規約書はプロジェクトフォルダのルートに
00_改訂規約.mdのファイル名で配置し、命名規約00_命名規約.mdと並べておくのを推奨します。フォルダを開けば必ず目に入る位置に置くことで、新規参加者にも自然に伝わります。
確認申請対応で生きる改訂運用
確認申請を経由する案件では、改訂運用がしっかりしているかどうかで、行政・検査機関とのやり取りの効率が大きく変わります。
| 状況 | 改訂運用がある場合 | 改訂運用がない場合 |
|---|---|---|
| 「申請時の○○図を再送して」 | _archive/20260415_確認申請提出/ から即送付 | 当時の版を特定するのに半日 |
| 「指摘事項No.3への対応はどう図面に反映した？」 | 改訂履歴欄＋ _archive/20260420_第1回指摘修正/ で説明 | 履歴を再構築する必要あり |
| 「軽微な変更の一覧を出して」 | 「軽微な変更一覧表」を即提示 | ゼロから作成（数日かかる） |
| 「最新版が分からない」 | ファイル名・版番号で一意に判別 | 担当者に問い合わせ |
設計事務所のチーム作業で生きる改訂運用
複数人が同じ案件に関わる場合、改訂運用は 「上書き事故」を防ぐ最後の砦 になります。
| 場面 | 改訂運用による予防効果 |
|---|---|
| AさんとBさんが同じ図面を別々に編集 | バージョン番号で衝突が即座に検知できる |
| 担当交代時の引継ぎ | 改訂履歴を見れば過去の議論経緯が追える |
| 派遣スタッフが慣れない案件に参加 | 改訂規約1ページで即戦力化 |
| クラウドの自動同期失敗 | _archive/ の節目スナップショットから復旧 |
改修工事・既存建物調査での改訂運用
改修工事では、現況図・改修前図・改修後図のそれぞれに 独立した改訂履歴 を持たせるのが運用しやすいです。
| 図面種別 | 改訂履歴の運用 |
|---|---|
| 現況図 | 現況調査時の確定版で固定。原則改訂しない |
| 改修前図 | 改修対象範囲の確定状態。設計協議で改訂が発生 |
| 改修後図 | 改修工事の完成イメージ。指摘修正で改訂 |
PERSCの推奨: 改修案件では 「現況図は触らない」 を社内ルールにすると運用がシンプルになります。現況確定後に変更が必要なら、現況図は固定したまま「改修前図」を別ファイルとして派生させる運用が安全です。
海外発注・BIM連携での改訂運用
海外建築事務所や BIM ソフト（Revit／ArchiCAD）と連携する案件では、改訂運用を 国際慣行に寄せる のが現実的です。
| 観点 | 推奨 |
|---|---|
| 版番号体系 | アルファベット系（Rev. A／B／C…）が国際標準 |
| 改訂表示 | リビジョンクラウドが世界共通の表記法 |
| 改訂日付 | ISO 8601形式（YYYY-MM-DD）で表記 |
| 改訂内容欄 | 英文併記（または英文のみ） |
| BIM連携時 | BIMソフト側のリビジョン管理に整合 |
PERSCの推奨: 海外案件・BIM案件を視野に入れる組織では、国内案件もアルファベット系の版番号で統一 するのが将来の負担を減らします。「国内は数字系、海外はアルファベット系」と運用を分けると、混合案件で混乱します。
設計事務所で「改訂を残す文化」を作る
改訂運用ルールを決めても、現場で守られなければ意味がありません。PERSC編集部の経験では、次の3つの仕組みが定着の鍵になります。
| 仕組み | 効果 |
|---|---|
| 規約書をプロジェクトフォルダのルートに置く | 新規参加者の目に必ず入る |
| 改訂のたびに改訂履歴欄を埋めるテンプレ動線 | 表題欄を更新せずに保存できないテンプレ運用 |
月次の _archive/ 健全性チェック | 節目スナップショットの抜け漏れを定期確認 |
背景: 「改訂を残す文化」は、ベテランがいる現場では自然に身につくものですが、若手中心の事務所では仕組み化が必要です。「忙しい時に改訂履歴を書く時間がない」という声が出る現場では、改訂履歴の記入を5項目以内に圧縮 する／改訂内容欄に定型句リストを用意 するなど、入力負荷を下げる工夫が定着の決め手になります。
つまずきポイント・対処 ★PERSC独自
Q: 改訂のたびに別名保存していたら作業フォルダが重くなる
→ 作業フォルダには 最新版のみ を残し、過去版は _archive/ に退避するのが基本です。_archive/ 内は節目スナップショットだけに絞れば、フォルダ全体のサイズは管理可能な範囲に収まります。日々の細かい改訂は版番号付きファイルで履歴を蓄積し、節目で _archive/ にフルコピーする二段運用を推奨します。詳しくは ファイル命名規則 を参照してください。
Q: 確認申請後に図面を変更したい。計画変更申請が必要か分からない
→ 軽微な変更（建築基準法施行規則3条の2）に該当するかどうかは、変更内容次第で判断が分かれます。判断に迷ったら指定確認検査機関または建築主事に電話で問い合わせる のが最短ルートです。「これは軽微で大丈夫ですか？」の一言で済む確認なら、5〜10分で済むケースが多いです。判断ミスで未申請の計画変更を着工してしまうと、最悪の場合、検査済証が下りません。
Q: 過去の版を間違えて上書きしてしまった
→ クラウドストレージ（Dropbox／OneDrive／Google Drive）の バージョン履歴 から復元できるケースが多いです。サービスのUIから対象ファイルを右クリック → 「バージョン履歴」または「以前のバージョンを表示」で復元できます。クラウドを使っていない場合は、Jw_cad の自動保存ファイル（.jws）またはバックアップファイル（.jwk／.bak）が残っている可能性があるため、 自動保存と復元 を参照してください。
Q: 改訂履歴欄が埋まりきってしまった
→ 表題欄に追加できる範囲を超えたら、「改訂内容説明書」を別紙化 します。改訂履歴欄には「改訂内容説明書R3-1参照」のように参照先だけ残し、詳細は別ファイル（Excel または Markdown）で管理します。一般的に、案件あたり改訂10回を超えたら別紙化を検討するタイミングです。
Q: クラウドのバージョン履歴と _archive/ のどちらを信用すればいい?
→ 両方併用するのが正解で、役割が違う ことを意識します。クラウドの履歴は 「事故時の安全網」（自動・全保存・短期間）、_archive/ は 「意図的な節目記録」（手動・節目のみ・長期間）です。短期復旧はクラウドから、長期参照は _archive/ から、と使い分けます。クラウドだけに頼ると契約解除・プラン変更・サービス側の仕様変更時にリスクがあります。
Q: チームで複数人が同時に同じ図面を開いてしまった
→ Jw_cad は同時編集に対応していないため、上書き衝突で 後から保存した方が勝つ 仕様です。クラウドの 「ロック」「チェックアウト」機能 で物理的にロックをかけるか、社内チャット等で「○○のファイルを開いています」と宣言する運用を推奨します。Dropbox Business／OneDrive Business には対応機能があります。
Q: 改訂内容欄に何を書けばいいか毎回迷う
→ 「動詞＋目的語」 の形式で15文字以内に圧縮します。事務所内で 定型句リスト を作っておくと迷いが減ります。例：「○○寸法変更」「○○位置変更」「○○仕様変更」「○○追加」「○○削除」「指摘No.X対応」のようなパターンを集めて社内テンプレ化すると、新人も即戦力になります。
Q: 古い案件の改訂履歴が _archive/ に残っていない
→ 過去案件で _archive/ を運用していなかった場合、復元は不可能です。今後の案件から _archive/ 運用を始め、過去案件はそのまま現状のファイル状態を保管します。「過去には触らない、今後を整える」 が現実的なリカバリー方針です。クラウドの自動バージョン履歴に最近のものなら残っている可能性があるため、案件が活きているなら確認しておきます。
Q: 計画変更確認申請の改訂版は元の番号を引き継ぐべきか
→ 一般的には、元の確認申請の図面を起点として、リビジョン番号を付け直す 運用が分かりやすいです。「申請当初A／計画変更申請でB」のように、版番号がフェーズの変化を表すよう設計します。事務所単位で「計画変更時は番号をリセットするか」「継続するか」を決めて、案件全体で統一します。
Q: 引渡時の確定版が分からなくなる
→ 引渡時の確定版は _archive/{引渡日付}_引渡/ フォルダにフルセット退避 して固定します。それ以降のメンテナンス改修等で図面を触る際は、引渡フォルダは絶対に触らず、別フォルダにコピーしてから作業します。引渡フォルダは竣工図書としての法的位置づけがあり、改変は許されません。
Q: 改訂運用を社内に浸透させる方法
→ 規約を作るだけでは浸透しないことが多いです。「改訂履歴を埋めずに保存しようとすると先輩が指摘する」「キックオフで規約を10分でレクチャーする」「月次でフォルダ健全性をチェックする」 の3点セットが効きます。最初の3案件で規約に従って完走させると、4案件目以降は自然に流れます。新人教育のカリキュラムに組み込むのも有効です。
関連項目
- JIS A 0150（建築製図通則）の全体像 — Ch.11のハブ記事
- 表題欄の項目と配置ルール — 改訂履歴欄のレイアウト
- ファイル命名規則 — 版番号を含む命名フォーマット
- フォルダ構成・プロジェクト管理 —
_archive/フォルダ設計の詳細 - 履歴（最近開いたファイル） — Jw_cadの「履歴」コマンド
- タグジャンプ — 過去ファイルへの素早いアクセス
- 自動保存と復元 — 自動保存ファイル（.jws）からの復元
- 名前を付けて保存 — 別名保存の操作
- 古いバージョンのJWWで保存 — 旧バージョン互換保存
まとめ
- 建築図面の改訂は 「修正（記録なし）／改訂（記録あり）／変更（法的手続き対象）」 で意味が違う
- 版番号は アルファベット系・数字系・日付系・併用系 の4方式から事務所単位で1つを選ぶ
- 改訂履歴欄には Rev.／日付／改訂者／改訂内容（15文字以内） の4項目を必ず記入
- 改訂箇所には リビジョンクラウドまたは△記号 で視覚的なマーキングを入れる
- 旧版退避は 節目スナップショット（キックオフ／確認申請／指摘修正／着工前／中間検査／完了検査）を
_archive/{日付}_{意味}/に退避 - 確認申請後の変更は 軽微な変更／計画変更 の判断を行政・検査機関に確認するのが最短ルート
- クラウド（Dropbox／OneDrive 等）の自動バージョン履歴と
_archive/の節目スナップショットは 役割が違うため併用 するのが正解 - Gitによる管理は .jww がバイナリのため限定的。一般的な事務所では採用不要
- 改訂運用は 案件キックオフ時に規約として決定 し、フォルダルートに
00_改訂規約.mdとして配置するのが定着の鍵