Excelで先頭の0が消える｜16桁は戻らない、直すのは開く前

2026年9月11日 20:52

取引先から届いたCSVを開いて、少し直して、そのまま保存した。
それだけで、商品コードの「00123」が「123」になっていた。

やってしまった経験のある方も、これから踏む方もいると思います。
厄介なのは、この事故がエラーも警告も出さずに起きることです。

しかも、失われるのは見た目ではありません。
16桁以上の数字なら、15桁を超えた部分は0に置き換わり、書式を直しても戻りません。

この記事で扱うのは、その仕組みです。
なぜそうなるのか、どこで止められるのか、そして渡す側に何ができるのか。

先に結論を1つ書いておきます。
この一連の事故は、Excelの使い方の問題ではありません。
渡した側が決めた意味を、開いた側が別の規則で読み直している、という構造の問題です。

この記事は、Microsoft の公式サポート記事と Microsoft Learn のドキュメント、総務省統計企画会議の申合せ（令和2年12月18日）、e-Stat の「結果表における機械判読可能なデータ作成に関する表記方法」Ver.1.2 をもとに、2026年9月11日時点の内容にしています。

開いた瞬間に、Excelが値の意味を決めている

これはバグではなく、仕様として書かれている

まず、原因をはっきりさせます。
Excelは、ファイルを開いた瞬間に、その値が何であるかを判断しています。

Microsoftの公式サポート記事には、こう書かれています。

Excel では、自動的に先頭のゼロが削除され、大きな数値が 1.23E+15 などの指数的表記に変換されて、数式や算術演算が使用できるようになります。

数式や算術演算が使えるようにするため、と書かれている点が大事です。
壊しているのではなく、計算できる形に直しているつもりの動作です。

Excelから見れば「00123」は数の123であり、先頭の0に意味があるとは思っていません。
商品コードや伝票番号のような、計算しない数字の並びを、こちらが渡してしまっているわけです。

変わるのは4種類あって、日付もその中にある

この自動変換には名前が付いていて、Microsoftは「自動データ変換」と呼んでいます。
変換されるのは、次の4種類です。

数値テキストから先頭のゼロを削除して数値に変換する。
数値データを 15 桁の精度に切り捨て、指数表記で表示される数値に変換します。
文字 "E" を囲む数値データを指数形式に変換する。
連続した文字と数字の文字列を日付に変換します。

3つ目と4つ目は、あまり知られていないと思います。
「123E5」のような型番が指数表記になり、「JAN1」のような文字と数字の並びが日付になります。

そして、これが起きる場面も書かれています。

自動データ変換は、.csv ファイルまたは .txt ファイルを開く、データの入力または入力、外部ソースからのコピーと貼り付けの操作、検索と置換の操作、およびテキストから列への変換ウィザードの使用の方法で行うことができます。

ファイルを開いたときだけではありません。
どこかからコピーして貼り付けたときにも、置換をかけたときにも起きます。

この4つは、設定で個別に止められます。
ただし、注意が2つあります。

1つは、対応している版が限られることです。
先ほどの記事には「この機能は、Excel for Microsoft 365、Excel for Microsoft 365 for Mac、Excel 2024、Excel 2024 for Mac で使用できます。」と書かれています。
社内のExcelが2019や2021のままなら、この設定欄はありません。

もう1つは、止めきれない形が残ることです。
日付への変換について、Microsoftはこう補足しています。

たとえば、 JAN1 はテキスト内では JAN1 のままであり、 1 月 1 日の日付には変換されません。ただし、 JAN 1 や JAN-1 など、スペースやその他の文字を含む値は、引き続き日付として扱われる場合があります。

設定を変えても、区切り記号の入った形は日付になります。
設定は保険であって、解決ではありません。

「表示が変なだけ」と区別がつかない

なぜ多くの人が油断するのか。
表示の問題で済む場合が、実際にあるからです。

たとえば12桁の数字が「1.23457E+11」と表示されていても、これは15桁以内なので、表示形式を数値に直せば元の数字が出てきます。
一度これを経験すると、Excelは見た目を変えるだけで中身は持っている、と学習してしまいます。

しかし、16桁を超えると同じ操作をしても戻りません。
ここが、この事故の分かれ目です。

15桁を超えると、値そのものが戻らない

書式を直しても、桁は戻らない

もう1つ、知っておいたほうがよい制限があります。
同じ記事に、こう書かれています。

Excel の有効桁数の最大桁数は 15 桁です。つまり、クレジットカード番号など、16 桁以上の数値については、15 桁を超える数値はゼロに切り捨てられます。

16桁以上の数字は、15桁までしか保持されず、残りは0になります。
表示形式を「文字列」に変えても、桁は戻りません。
列の幅を広げても戻りません。

失われたのは見た目ではなく、値そのものだからです。

先頭の0についても、同じ記事が明記しています。

書式設定する前に削除された先頭のゼロは復元されません。書式設定を適用した後に入力される数値にのみ適用されます。

削られたあとで書式を変えても、0は復活しません。

なお、書式を文字列にして持たせた場合にも、別の落とし穴が用意されています。

さらに、数値形式 ( 通貨など) への変換では、データは常に有効桁数 15 桁の精度に切り捨てられます。

文字列として持っている16桁の番号を、あとから通貨書式にすると、そこで切り捨てられます。

確かめる方法は1つしかない

見分ける方法は1つです。
元のCSVを、Excelではなくメモ帳などのテキストエディタで開いて、Excelの画面と突き合わせることです。

CSVは中身がそのまま文字で書かれたファイルなので、テキストエディタなら、渡された本来の値が読めます。
保存してしまう前にこの確認を1回入れるだけで、取り返しのつかない上書きは防げます。

順番が大事です。
開いてから直すのではなく、開く前に決める。
この記事の後半は、その「開く前」の話になります。

同じファイルが、開く環境で違う値になる

「03/04/2026」は、3月4日か、4月3日か

もう1つの事故があります。
同じCSVを、こちらで開くと3月4日、相手が開くと4月3日になる、というものです。

日付の書き方は、国によって順番が違います。
月・日・年で書く国もあれば、日・月・年で書く国もあります。

そして、CSVに書かれているのは、ただの文字の並びです。
どちらの順番で書いたかは、ファイルの中に書いてありません。

Microsoft Learn のドキュメントは、この問題をこう説明しています。

このロケール設定は、テキスト値を特定のデータ型に解釈するために重要です。たとえば、ロケールが English (米国) として設定されているが、CSV ファイルの 1 つの列に日付が日/月/年の英国形式で書式設定されていることを想像してください。

そのときに何が起きるかも書かれています。

これらのエラーは、使用されているロケールが英語 (米国) 形式 (月/日/年) で日付を解釈しようとしているために発生します。カレンダーに月 22 がないため、エラーが発生します。

22日のデータは、エラーになります。

ここで気づいてほしいのは、エラーになるのは幸運な場合だ、という点です。
22という数字は月として成立しないので、機械が止まってくれます。

しかし3日や4日なら、月としても日としても成立します。
だから何も言わずに通り、間違った日付として集計されます。

気づけない事故のほうが、件数としては多いはずです。

意味を決めているのは、開いた人のパソコン

なぜこうなるのかは、Power Query の「カルチャ」という考え方を見ると分かります。

国や言語グループによって、数値、日付、時刻など、さまざまな種類のテキストを書式設定するための規則が異なります。

そして、その規則がどこから来るのかも書かれています。

既定のカルチャは、クエリが最初に作成される特定のドキュメントのシステムロケール (Windows、MacOS) に設定されます。

パソコンの設定です。
ファイルの中身ではなく、開いた人のパソコンが、意味を決めています。

同じことは、Power Query を使わずにファイルを開いた場合にも当てはまります。
別のドキュメントには、こう書かれています。

Power Query Desktop では、Power Queryはオペレーティングシステムの地域形式を自動的に認識し、データ型変換の値を解釈するために使用します。

一度作った手順は、動かしても元の規則で動く

実務で効いてくる一文が、もう1つあります。

クエリを作成する場所に関係なく、別の既定のカルチャを使用する別の場所にクエリを移動しても、クエリでは元の場所のカルチャが使用されます。

一度作った手順は、別の環境に持っていっても、作った場所の規則で動き続ける。
結果が安定するという意味では、ありがたい性質です。

ただし、裏があります。
手順を引き継いだ人が自分のパソコンの設定を見ても、実際に使われている規則は分からない、ということでもあります。

どの規則で読んでいるかは、手順の中に書いてあります。
引き継ぐときは、そこを開いて確かめる必要があります。

文字化けも、まったく同じ構造をしている

印が付いているかどうかで変わる

文字化けは、別の話に見えて、同じ形の事故です。

文字は、コンピューターの中では数字で保存されています。
どの数字がどの文字を指すかの対応表を、文字コードと呼びます。

渡した側がUTF-8という対応表で書き、開いた側が別の対応表で読むと、文字化けします。

Microsoftのサポート記事には、こう書かれています。

You can open a CSV file encoded with UTF-8 normally if it was saved with BOM (Byte Order Mark).

BOMという印が付いた状態で保存されていれば、UTF-8のCSVファイルは普通に開ける。

逆にいえば、その印がなければ普通には開けない、ということです。
そして印が付いているかどうかは、ファイル名からも見た目からも分かりません。

対処は、日付と同じ

同じ記事が案内している対処法は、1つ目の事故と同じ方向です。

Through PQ (Power Query) using the Get Data dropdown. Navigate to Data tab > Get Data > From file > Get Data from Text/CSV.

ダブルクリックで開かず、データタブから取り込む。

日付も文字コードも、渡した側が決めた意味を、開いた側が別の規則で読んでいます。
この1点さえ押さえておけば、原因の見当がつきます。

開く前に決める、という順番にする

Power Query は「繰り返し可能なプロセス」を作る道具

Excelには、この取り込みと整形を記録しておく機能が入っています。
Power Query といいます。

公式ドキュメントは、こう定義しています。

Power Queryは、データ変換とデータ準備エンジンです。これには、ソースからデータを取得するためのグラフィカルインターフェイスと、変換を適用するためのPower Query エディターが含まれています。

新しいソフトを買う必要はありません。
データタブの中にあります。

プログラムを書く必要もありません。
画面で操作した内容が、そのまま手順として記録されます。

そして、この道具の本体は便利な変換機能ではありません。
同じドキュメントの、次の説明が本体です。

Power Queryを使用してデータにアクセスして変換する場合は、繰り返し可能なプロセス (クエリ) を定義します。このプロセス (クエリ) は、将来簡単に更新して up-to-date データを取得できます。

繰り返し可能なプロセスを定義する。
つまり、1回目にやることは作業ではなく、手順を決めることです。

2回目以降は、新しいファイルを指して更新するだけになります。
毎月の30分が3分になる、という話ではありません。
毎月の判断が、初回の1回だけになる、という話です。

なぜ、これで前半の事故が消えるのか

ここが、この記事でいちばん伝えたいところです。

ダブルクリックで開くと、Excelが値の種類を判断します。
その判断は、取り消せない形で値を変えます。

取り込みの手順を作ると、順番が逆になります。
先に「この列は文字列」「この列は英国式の日付」と決めておき、そのうえで読み込む。

日付については、指定のしかたまで書かれています。

Date データ型を選択する代わりに、列見出しを右クリックし、[型の変更] を選択してから、[ロケールを使用] を選択します。

単に「これは日付です」と指定するのではなく、「これは英国式の日付です」と指定できるということです。

判断するのがExcelではなく、こちらになります。
だから来月も再来月も、同じ列が同じ型で読まれます。

自動データ変換との関係も、Microsoftが明記しています。

これらの自動データ変換オプションは、データ形式を指定する他の方法がある Power Query を使用してインポートされたデータには直接影響しません。

前半で見た4つの自動変換は、この経路には効きません。
注意力で防ぐのではなく、順番を入れ替えることで消える、という話です。

ただし、自動の型検出は最初の200行しか見ていない

ここで、見落としやすい点を1つ。

取り込み画面でも、Power Query は型を自動で推測します。
その推測の範囲が書かれています。

この設定は、非構造化ソース専用です。テーブルの最初の 200 行に基づいて列の種類とヘッダーを自動的に検査して検出することで役立ちます。

最初の200行です。
201行目から先に、先頭が0の値や16桁の番号が初めて出てくると、推測は外れます。

しかも、この設定は既定で有効です。

既定では、この設定は有効です。

つまり、Power Query から取り込んでも、型を自分で指定しなければ同じ事故が起きます。
取り込み画面で列を選び、型を明示するところまでが手順です。

手順が見えなくなることへの備え

最後に、注意点も書いておきます。

更新のしかたは、こう書かれています。

Power BIなどの特定の製品でスケジュールされた更新機能を使用するか、Excel オブジェクトモデルを使用してプログラムによって、Power Queryクエリを手動で更新できます。

手動でも、決めた時刻でも、プログラムからでも動かせます。

便利さには裏があります。
手順がファイルの中に隠れるため、外から見ると「なぜかできあがっている表」になります。

作った本人がいなくなると、中で何をしているのか誰も説明できない、という状態になりがちです。
これを避けるには、次の3つを別の文書に残しておくことです。

どのファイルを取り込んでいるか。置き場所を含めて書く
どの列を、どの型で読んでいるか。日付はロケールも書く
想定と違う形が来たとき、誰に相談するか

なお、入力の形が変わったときの直し方も書かれています。

基になるデータまたはスキーマの変更を考慮してプロセスまたはクエリを変更する必要がある場合は、クエリを最初に定義したときに使用したのと同じ対話型で直感的なエクスペリエンスを使用できます。

最初に作ったときと同じ画面で直せる、ということです。

ここで大事なのは、変わったことに気づける、という点です。
手作業なら、列が1つ増えてもそのまま貼って気づかないことがあります。
手順を決めてあると、想定と違う形が来たときに止まります。

止まるのは面倒に見えますが、黙って間違うよりはるかに良い状態です。

渡す側は、国と同じ基準を使えばよい

令和2年12月18日の申合せ

ここまでは、受け取ったファイルをどう扱うかの話でした。
残りは、渡す側の話です。

事故の多くは、開いたときではなく、渡すときに仕込まれています。
そして、この点については、国が自分の統計に課しているルールがそのまま使えます。

総務省の統計企画会議は、令和2年12月18日に、統計表の表記方法について申し合わせを行っています。
その目的は、こう書かれています。

本申合せは、統計利用者の利便性を一層高める観点から、各府省がインターネット上に公表する統計表における機械判読可能なデータの表記について、標準的な方法を定めるものである。

機械判読可能、という言葉が使われています。
人が見て読めるかどうかではなく、コンピューターが処理できる形になっているかどうか、という基準です。

適用の範囲と時期も明記されています。

本申合せは、各府省が政府統計の総合窓口（e-Stat）に掲載している統計表（既にデータベース形式として対応している統計表を除く。）について適用するものとする。

本申合せは、令和３年１月１日以降に公表する統計表について適用するものとする。

すべての公表資料にかかるわけではありません。
e-Stat に載せる統計表が対象です。

そのうえで、この申合せに付いている別紙には、チェック項目が並んでいます。
社内でファイルをやり取りするときにも、そのまま使える内容です。

Excelで渡すときの13項目

別紙のチェック項目は、次のとおりです。

1-1 ファイル形式は Excel か CSV となっているか
1-2 1セル1データとなっているか
1-3 数値データは数値属性とし、文字列を含まないこと
1-4 セルの結合をしていないか
1-5 スペースや改行等で体裁を整えていないか
1-6 項目名等を省略していないか
1-7 数式を使用している場合は、数値データに修正しているか
1-8 オブジェクトを使用していないか
1-9 データの単位を記載しているか
1-10 機種依存文字を使用していないか
1-11 e-Stat の時間軸コードの表記、西暦表記又は和暦に西暦の併記がされているか
1-12 地域コード又は地域名称が表記されているか
1-13 数値データの同一列内に特殊記号（秘匿等）が含まれる場合

さらに、表全体についての項目が2つあります。

2-1 データが分断されていないか
2-2 1シートに複数の表が掲載されていないか

社内で使うなら、統計に固有の1-11の前半、1-12、1-13は読み替えが要ります。
それ以外は、そのまま社内の受け渡しの基準になります。

なぜ1セル1データなのか

項目だけ見ると、細かい決まりごとに見えます。
理由が書かれているので、そちらを見ると納得できます。

１セルに複数のデータが入力されていると、計算や昇順・降順の並べ替え、コピーペーストやグラフ化等加工編集する場合に多くの手作業やプログラムの作成が必要となり、すぐにデータとして利用できないため、１セル１データの入力とすること。

すぐにデータとして利用できない、という部分が要点です。

1つのセルに「東京都千代田区」と入れるか、都道府県と市区町村を分けるか。
見た目は同じでも、受け取った側の作業量がまったく変わります。

なぜ数値の欄に単位を書いてはいけないのか

実務で頻繁に起きる項目の理由も引いておきます。

数値データに、円、￥、kg、㌧などやマイナス記号（▲）を文字列として入力すると、Excel では数値ではなく文字列として扱われてしまうため、関数等で計算ができなくなる（エラーとなる）ほか、昇順・降順等の並べ替えも正確にできない場合がある。

これは前半の裏返しです。
前半は、計算しない数字を数値にされて困る話でした。
ここは、計算したい数字を文字列にしてしまって困る話です。

どちらも同じ原因から来ています。
1つの列の中に、種類の違うものを混ぜているのです。

同じ項目には、カンマについての警告も入っています。

また、ヒトが見やすくするための工夫として、千円単位を示す「,（カンマ）」を文字列として直接入力している場合、関数によっては正確に計算できない場合があるほか、当該 Excel ファイルを csv化すると思わぬ挙動を示す場合がある（csv はカンマでデータを区切るため）。

見やすくするために入れたカンマが、CSVにした瞬間に列の区切りとして読まれます。

では、桁区切りを諦めるのかというと、そうではありません。
同じ項目の補足に、答えが書かれています。

Excel の場合「書式設定」により体裁を整えることは可能であるため、データは数値として扱いつつ、見た目の体裁を整えることができる。

金額の列には数字だけを入れ、見やすさは書式設定で付ける。
単位は項目名のほうに書く。
マイナスは記号ではなく、マイナスの数値として入れる。

それだけで、受け取った側は計算できます。

セルの結合が禁止される理由

セルの結合についても、理由が書かれています。

レコード及びフィールドはそれぞれ独立しており、レコードの場合は上下の並べ替えをしてもデータの意味が変わらず、フィールドの場合は左右で入れ替えても意味が変わらないようにセルの結合又は不必要な分離を行わないこと。

行を並べ替えても意味が変わらない。
列を入れ替えても意味が変わらない。
これが、データとして扱える表の条件です。

結合したセルは、この条件を壊します。
見出しを見やすくするための結合が、受け取った側では並べ替えのできない表になる、ということです。

資料として印刷する表と、データとして渡す表は、別に作る。
これがいちばん確実な解決です。

この考え方は、国の側にも書かれています。

結果表の解説や注釈、図が入った報道発表資料や報告書ベースのファイル（PDF や印刷することを目的として作成した表形式データ）で掲載する場合であっても、それとは別途、その表の基データを登録する。

和暦だけで書かない

1-11の前半は統計固有ですが、後半の「西暦表記又は和暦に西暦の併記」は社内でもそのまま効きます。
理由はこうです。

時間軸を示すデータについて、ソフトウェア等のプログラムは、年の値の大小により認識することが多いため、和暦表示のみでは、元号が切り替わる際に手作業で西暦等に変換する必要がある。

「令和8年4月1日」と「2026年4月1日」が同じ日だと、コンピューターは知りません。
社内のファイルでも、和暦と西暦が混ざっている表は珍しくないと思います。

CSVで渡すときは、もう一段ある

e-Stat が公開している「結果表における機械判読可能なデータ作成に関する表記方法」Ver.1.2 には、CSV向けのチェック項目が加わっています。
そのうち、社内の受け渡しでも効くものを挙げます。

4-1 変数行から始まり、次行からデータ入力がされているか
4-2 1フィールド1データとなっているか
4-5 1行1データで表現されているか
4-12 各フィールドの値をダブルコーテーション（“）で囲んでいるか
4-13 データが分断されていないか
4-14 1ファイル内に変数とデータのセットが複数掲載されていないか

1行目に項目名、2行目からデータ。
1つのファイルに1つの表。

当たり前に見えますが、報告用のファイルはたいてい、上に表題と作成日が入り、下に注記が入っています。
その形のまま渡されると、受け取った側は毎回それを削る作業から始めることになります。

そして、空白行を挟むと何が起きるかも書かれています。

機械読み取りでは、空白行列をデータの終わりとみなすため、空白行があるとそれ以降のデータを読み取ることができない。

見やすさのために入れた1行の空白が、そこから下を丸ごと消します。

ダブルコーテーションの理由も書かれています。

フィールドの文字列にカンマが含まれている場合、機械はそのカンマでフィールドが区切れると判別し、以降のフィールドを列がずれた状態で読み取る。

先ほどのカンマの話と、同じところに戻ってきます。

なお、Ver.1.2 と別紙では章の構成が違うため、項目の番号がずれています。
別紙のExcel向けが1章・2章、Ver.1.2 では2章・3章になり、CSV向けは Ver.1.2 の4章にあります。
引用するときは、どちらの資料の番号かを添えてください。

まとめ

Excelは、ファイルを開いた瞬間に値の種類を判断する。先頭のゼロを削り、大きな数値を指数表記にするのは、計算できる形に直すための仕様である
変換されるのは4種類で、指数表記への変換と、文字と数字の並びを日付にする変換も含まれる
自動変換が起きるのは、ファイルを開いたときだけではない。貼り付け、置換、区切り位置ウィザードでも起きる
設定で止められるが、対応しているのは Microsoft 365 と Excel 2024 の系列だけ。「JAN 1」のように区切り記号の入った形は、止めても日付になる
有効桁数は15桁。16桁以上は15桁を超えた部分が0になり、書式を直しても戻らない。削られた先頭のゼロも戻らない
確かめる方法は、元のCSVをテキストエディタで開いて突き合わせること
日付の順番は国によって違い、CSVにはどちらで書いたかが記録されていない。解釈するのは、開いた人のパソコンの設定である
月として成立しない数字ならエラーになるが、3日や4日のように成立してしまう場合は、何も起きずに間違った値が通る
文字化けも同じ構造で、BOMという印の有無で結果が変わる
取り込みの手順を作ると、判断するのがExcelではなくこちらになる。自動データ変換は、この経路には効かない
ただし自動の型検出は最初の200行しか見ておらず、既定で有効になっている。型は自分で指定するところまでが手順である
手順はファイルの中に隠れる。何を取り込み、どの列をどの型で読んでいるかは、別に書き残しておく
渡す側は、1セル1データ、数値の欄に文字を混ぜない、セルを結合しない。国が自分の統計に課しているのと同じ基準を使えば足りる
CSVで渡すときは、1行目に項目名、1ファイルに1つの表、空白行を入れない

最後に1つ付け加えます。

この記事で挙げたことは、どれも新しい道具を買う話ではありません。
すでに手元にあるExcelの使い方と、渡すときの取り決めだけの話です。

それでも直らないとすれば、原因は道具ではなく、社内でその取り決めがされていないことのほうです。

皆さんの会社では、部署のあいだでファイルを渡すときの決まりが、文書になっているでしょうか。

参考・引用元

Microsoft（サポート記事）

Microsoft「先頭のゼロおよび大きい数値の保持」 https://support.microsoft.com/ja-jp/excel/keeping-leading-zeros-and-large-numbers
Microsoft「自動データ変換を設定する」 https://support.microsoft.com/ja-jp/excel/set-automatic-data-conversions
Microsoft「Opening CSV UTF-8 files correctly in Excel」 https://support.microsoft.com/en-us/excel/opening-csv-utf-8-files-correctly-in-excel

Microsoft（Microsoft Learn）

Microsoft「Power Queryのデータ型」 https://learn.microsoft.com/ja-jp/power-query/data-types
Microsoft「Power Queryとは」 https://learn.microsoft.com/ja-jp/power-query/power-query-what-is-power-query
Microsoft「カルチャがテキストの書式設定にどのように影響するか」（PowerQuery M） https://learn.microsoft.com/ja-jp/powerquery-m/how-culture-affects-text-formatting

総務省・e-Stat

総務省統計企画会議「統計表における機械判読可能なデータ作成に関する表記方法について」（令和2年12月18日申合せ。別紙を含む全23ページ） https://www.soumu.go.jp/main_content/000723697.pdf
総務省統計企画会議「統計表における機械判読可能なデータ作成に関する表記方法」別紙（令和2年12月18日申合せ。全22ページ） https://www.soumu.go.jp/main_content/000723626.pdf
e-Stat 政府統計の総合窓口「結果表における機械判読可能なデータ作成に関する表記方法」Ver.1.2（全38ページ） https://www.e-stat.go.jp/estat/html/machine-readable-stats-format.pdf

実務で使う書式について

この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。
規程のひな形、対応フロー、チェックシート、報告書式などです。

実務で使う書式・キット
https://note.com/yunta_fukurou/m/mfc25857fab40