2026-08-20 · biz, code

38歳が「その数字、どのファイルから取った？」に3回即答できず信用を失ってから作り直したデータ管理の3原則：出典を成果物の構造に埋め込む設計

データの正しさだけでは信用されない

「その数字、どのファイルのどの列から取った？」

検査報告書の数値を確認する場面で、この質問に即答できなかったことが3回続いた。数値そのものは合っている。計算ミスもない。それでも「出典を辿れない」という理由だけで、成果物全体の信用が揺らいだ。

私は兵庫県姫路市を拠点に、個人事業USサービスと株式会社USを併営している。NDT検査歴20年の現場では、報告書・見積もり・補修計画といったデータ成果物を日常的に扱う。データの正しさは大前提だが、それだけでは足りない。データがどこから来たのかを即座に示せる状態が、信用の土台になる。

出典を即答できないデータは、正しくても使われない。この教訓を3回の失敗から学び、出典を成果物の構造に埋め込む設計を標準化した。今回はその3原則を書く。

最初の失敗は、元データから数値だけを抽出して「きれいな表」を作ったときだった。見やすさを優先して、ファイル名・シート名・列名といった出典情報を削除した。結果、確認時に「この減肉量はどのファイルから？」と聞かれて答えられず、元データを探し直す羽目になった。

出典列は成果物の一部として、最初から組み込む設計に変えた。

これらを成果物の右端に常に残す。見た目の「きれいさ」より、追跡可能性を優先する。Excel・CSV・Notion DB のいずれでも、この4列は削除しない運用にした。

Claude Code で抽出スクリプトを書くときも、出典列の追加をデフォルト仕様にしている。「データを取るときは出典も一緒に取る」を自動化した。

2回目の失敗は、元データを加工・補正したときだった。単位換算（mm → μm）や欠測値の補完をしたが、どのセルを編集したかの記録を残さなかった。確認時に「この値は元データのまま？それとも計算で出した？」と聞かれて曖昧な答えしかできず、再検証を求められた。

編集箇所の明示を成果物の構造に組み込んだ。

この3列を追加するだけで、「元データのまま」と「加工済み」の境界が明確になる。確認者は編集フラグ列を見るだけで、検証すべき行を絞り込める。

Excel では条件付き書式で編集フラグ列が edited のセルを黄色く塗る設定にした。視覚的にも編集箇所が一目で分かる。

3回目の失敗は、元データが更新されたときだった。同じファイル名の古いバージョンと新しいバージョンが混在し、どちらから抽出したのか不明になった。成果物の日付と元データの更新日が一致せず、整合性が取れなくなった。

出典ファイルのフルパスとタイムスタンプを、成果物のヘッダー（シートの1行目 or ファイルのメタデータ）に埋め込む設計にした。

出典ファイル: Z:\2024_定修\測定データ\2024_定修データ_v3.xlsx
出典ファイル更新日時: 2024-05-12 14:32:15
成果物作成日時: 2024-05-12 16:45:03

この3行をヘッダーに入れるだけで、「どのバージョンのファイルから、いつ抽出したか」が一意に確定する。元データが更新されても、成果物の出典を遡れる。

Claude Code で抽出スクリプトを書くときも、ヘッダー生成をデフォルトにした。os.path.getmtime() で更新日時を取得し、成果物の1行目に自動挿入する仕様にしている。

出典を即答できないデータは、正しくても使われない。この教訓を3回の失敗から学んだ。

原則1: 出典列を成果物の一部として必ず残す——ファイル名・シート名・列名・行番号を右端に常に追加する。

原則2: 編集箇所を明示して「どこをいじったか」を可視化する——編集フラグ列・編集内容列・編集日時列で加工履歴を記録する。

原則3: 出典ファイルのパスとバージョンを成果物のヘッダーに埋め込む——フルパス・更新日時・作成日時をヘッダーに入れて一意性を担保する。

この3原則を実装してから、確認時の「どこから取った？」質問に即答できるようになった。成果物の信用が上がり、再検証の手間も減った。データの価値は、正しさだけでなく追跡可能性で決まる。

Claude Code で業務を自動化するときも、出典情報の埋め込みは最優先の仕様として設計している。AI が出力したデータほど、出典の明示が信用の分水嶺になる。