AI外観検査やOCRを動かし始めると、画像は毎日確実に積み上がります。とりあえず全部原寸で残すと、数か月後にストレージ費用と「探せない」で行き詰まる現場は少なくないと考えられます。この記事では、何のために残すのかを起点に、保管期間・解像度・メタデータを逆算して決める考え方を整理します。
AI外観検査やOCRを導入した現場が最初にぶつかりやすいのが、画像の保管方針を決めないまま「とりあえず全部残す」で走り出してしまう構図だと考えられます。導入直後は容量に余裕があり、判定結果を全部残しておけば後で何かの役に立つだろう、という判断は自然です。問題が見えてくるのは、日々の撮像が積み重なって数か月が経ったころだと考えられます。
画像は、テキストのログと比べて1件あたりの容量が桁違いに大きい種類のデータです。1ラインで1日に数千枚を撮り、それが稼働日ごとに積み上がると、ストレージの空きは想定より早く減っていく可能性があります。増設や上位プランへの移行を迫られたとき、その費用の根拠を説明できないまま判断を迫られるのは、情報システム担当にとって負担の大きい状況だと考えます。
容量以上に早く効いてくるのが検索性だと考えられます。クレームが入って「先月○日に出荷したロットの画像を出してほしい」と言われたとき、日付とフォルダ名だけで数十万枚の中から目的の1枚にたどり着けるかは、保管を始めた時点の設計でほぼ決まっています。全部残してあること自体は、探せることを意味しません。ここでクレーム対応と画像の証拠が噛み合わず、せっかく残した画像が使えなかった、という事態が起こりうると考えます。
つまり画像保管の設計は、ストレージ製品を選ぶ話に見えて、実際には「何を・どの粒度で・どれだけの期間・どう探せる形で残すか」を先に決める話だと考えられます。この記事では、その順番を逆にしないための考え方を整理します。
保管方針は、目的を3つに分けて考えると設計しやすくなると考えられます。同じ「検査画像」でも、証跡として残すのか、AIの再学習に使うのか、工程改善の分析に使うのかで、必要な保管期間も解像度も付随情報も変わってくるためです。まず目的を分け、それぞれに要件を割り当てるのが出発点になりうると考えます。
1つ目は、クレームや監査が発生したときに、その製品を「なぜOK/NGと判定したか」を後から示すための証跡です。ここで重要なのは、画像単体ではなく「いつ・どの製品を・どの基準で・どう判定したか」がひも付いていることだと考えられます。判定根拠の残し方そのものは検査の証跡と説明責任で扱う論点と重なります。証跡としての価値は、保管期間と、画像に付いたメタデータの完全性で決まってくると考えます。
2つ目は、検査モデルを育てていくための教師データです。ここでいうアノテーション（画像のどこが良品/不良かを人が印を付けて正解を与える作業）の対象になるのは、主に判定が難しかった画像だと考えられます。全部のOK品を溜め込むより、判定が曖昧だったものや誤判定を集めるほうが学習に効く可能性があります。集め方の実務は検査データの集め方に整理があります。ここで必要なのは原寸に近い解像度で、期間よりも「偏りなく集まっているか」が問われると考えます。
3つ目は、不良の傾向やライン条件との相関を見て工程を改善するための分析データです。ここでは1枚1枚の高解像度画像より、判定ログや不良種別・発生時刻といった構造化された情報のほうが役立つ場面が多いと考えられます。画像は代表例だけあれば足りることもあり、必ずしも全数を原寸で持つ必要はないと考えます。
保管期間は、社内の都合で先に決めるのではなく、取引先や業界の要求から確認するのが安全だと考えます。自動車部品のトレーサビリティや食品の期限管理のように、納入先や規制が最低保管期間を実質的に定めている場合があり、社内で短く決めてしまうと後から要求と食い違う可能性があるためです。
特定の業界で「何年」という数字が語られることはありますが、その具体的な年数・適用範囲は取引条件や制度改定で変わりうるため、この記事では断定しません。該当する規制や業界基準の数値・適用範囲は、所管省庁の最新の公表資料と、取引先から提示される品質保証協定でご確認いただくのが確実だと考えます。
証跡としての保管は、いざクレームや回収が起きたときに「残っていなかった」では取り返しがつかない性質があります。だからこそ、保管期間の下限は自社の容量事情ではなく、外部から求められる水準に合わせて決めるのが筋だと考えられます。逆に上限、つまり「いつ消してよいか」も、要求期間を過ぎたものを機械的に間引くルールとして先に決めておくと、際限なく溜め込む状態を避けられる可能性があります。
確認すべき相手は取引先の品質保証部門であることが多いと考えられます。「御社の製品に関する検査画像を何年保管する必要があるか」を早い段階で書面で握っておくと、後の設計の前提が固まります。ここが曖昧なまま容量設計を進めても、前提が動けばやり直しになりうると考えます。
現実的な解は、すべての画像を同じ粒度で扱わず、判定結果に応じて残し方を変える階層化だと考えられます。NG品と判定が曖昧だったものは原寸で長期保管し、明確なOK品はサムネイル（縮小版）と判定ログだけ残す、という分け方が一つの型になりうると考えます。証跡としても学習用としても価値が高いのは前者に偏るため、容量の大半を占めるOK品を軽くできれば、伸びを大きく抑えられる可能性があります。
階層化を考えるとき、どちらの層に入れるかは目的から逆算すると整理しやすいと考えられます。原寸で長く残す価値が高いのは次のような画像です。
・NG判定された画像、および判定スコアが閾値の境界付近だった画像。証跡としても再学習の教師データとしても効くと考えられます。
・顧客から問い合わせが来る可能性が相対的に高いロットの画像。後から根拠を示す場面に備える意味があると考えます。
一方、サムネイルと判定ログだけに落としてよい可能性が高いのは、明確にOKと判定され、スコアも余裕をもって良品側だった画像です。判定の事実と時刻・製品IDが構造化ログとして残っていれば、「その時刻に確かに検査してOKだった」という記録は担保できると考えられます。原寸画像そのものが後で必要になる確率と、それを全数持ち続けるコストを天秤にかける判断になると考えます。
階層化を機能させる前提は、画像に付随するメタデータが揃っていることだと考えます。撮像時刻・製品/ロットID・カメラ位置・照明条件・判定結果とスコア・モデルのバージョンといった情報が画像と確実にひも付いていれば、後から「この条件で撮ったNG品だけ」を抽出できます。逆にメタデータが薄いと、原寸で全部残していても目的の画像にたどり着けず、階層化の判断もできません。残す対象を絞る設計は、探せる設計と一体だと考えられます。
増設の要否を判断するには、まず単純な掛け算で増え方を客観的に把握するのが出発点になると考えます。基本は「1日あたりの撮像枚数 × 1枚あたりの容量 × 稼働日数」で、一定期間に積み上がる総量の見当がつきます。ここに階層化を掛けると、原寸で残す分とサムネイルに落とす分を分けて見積もれると考えられます。
この記事では実測の容量値は書きませんが、1枚あたりの容量は、カメラの画素数・画像フォーマット・圧縮の有無で大きく変わります。だからこそ、他社の数字を借りるより自社のカメラ設定で数百枚を実際に撮ってみて、平均容量を測るのが確実だと考えます。撮像枚数も、1個あたり何枚撮るか（複数アングル・複数照明なら増える）で変わるため、実ラインの条件で数える必要があると考えられます。
1日あたりの増加量が分かれば、現在の空き容量を割ることで「あと何日でどこまで埋まるか」の目安が出ます。ここで、証跡の要求期間を過ぎたものを間引くルール（04で触れた上限側の運用）を織り込むと、無制限に増え続ける前提ではなく、ある水準で頭打ちになる見通しを立てられる可能性があります。増設は、この頭打ちの水準が現状の容量を超えるかどうかで判断すると根拠が説明しやすくなると考えます。
見積りで見落としやすいのが、稼働の変動です。増産期・多品種切り替え・撮像枚数を増やす検査項目の追加は、いずれも1日あたりの量を押し上げます。平常時の数字だけで設計すると、繁忙期に前提が崩れる可能性があるため、ピーク時の枚数でも一度計算しておくと安全だと考えられます。
画像を社外に出さないオンプレミス（自社内の設備で処理・保管を完結させる構成）では、保管もすべて自社の責任範囲になる点を先に押さえておく必要があると考えます。クラウドに預ければ事業者側が担う冗長化やバックアップも、オンプレでは自社で設計・運用することになるためです。データを外に出さないメリットと引き換えに、守る責任も自社に集約されると考えられます。
検査画像には製品の形状や不良の情報が含まれ、取引先や自社のノウハウに直結することがあります。だからこそ社外に出さない選択をする現場は多く、その考え方は工場データの主権とオンプレAIで扱う論点と重なります。一方で、社内に閉じるということは、故障・災害・誤削除に対する備えも社内で完結させるということです。証跡として長期保管する画像ほど、二重化やバックアップの方針を保管設計と同時に決めておくのが望ましいと考えます。
運用で曖昧になりやすいのが、保管ルールの持ち主です。撮像するのは製造現場、判定基準を決めるのは品質保証、ストレージを管理するのは情報システム、と関係者が分かれるため、「要求期間を過ぎた画像を消す」判断が誰にも属さず放置される可能性があります。保管期間・階層化の基準・間引きのルールを文書化し、定期的に見直す担当を明確にしておくと、溜め込みも早すぎる削除も避けやすくなると考えられます。こうした運用設計まで含めた土台は工場データ基盤として一体で考えると整理しやすいと考えます。
設計の考え方が正しくても、運用の細部でつまずくことがあります。実際に起こりやすいのは次のような点だと考えられます。いずれも「やってみないと分からない」部分を含むため、最初から完璧を狙うより、早く小さく回して気づくほうが現実的だと考えます。
最初の一歩は、製品や価格を検討することではなく、自社の現状を数字で客観的に把握することだと考えます。1日あたりの撮像枚数と1枚あたりの容量を実測し、稼働日数を掛けて増え方の見当をつける。この基礎データがないまま保管期間や構成を議論しても、前提が空いたままになりうるためです。
次に、証跡・再学習・工程改善の3つの目的のうち、自社で今いちばん重いものはどれかを決めると、要件の優先順位が定まると考えられます。証跡が重いなら取引先への保管期間確認とメタデータ設計が先、再学習が重いなら境界事例を偏りなく集める仕組みが先、というように、目的が決まれば手順も決まってくると考えます。
その上で、階層化の基準（何を原寸で長期保管し、何をサムネイル＋ログに落とすか）と間引きルールを小さく試し、実際のクレーム模擬や抽出で「探せるか」を確かめるのが現実的だと考えます。運用設計まで含めて伴走が必要な場合は導入コンサルティングのように、現場の条件から一緒に組み立てる進め方もありうると考えます。いずれにせよ、現物・現場での検証を出発点にするのが、無理のない画像保管設計への近道だと考えます。
一律の正解はなく、取引先や業界の要求から下限が決まる場合が多いと考えられます。自動車部品のトレーサビリティや食品の期限管理などでは実質的な最低保管期間が求められることがあります。具体的な年数・適用範囲は取引条件や制度改定で変わりうるため、取引先の品質保証協定と、該当する規制については所管省庁の最新の公表資料でご確認いただくのが確実だと考えます。
「1日あたりの撮像枚数 × 1枚あたりの容量 × 稼働日数」で概算できると考えられます。1枚あたりの容量はカメラの画素数・フォーマット・圧縮で大きく変わるため、他社の数字を借りるより自社設定で数百枚を実測して平均を出すのが確実です。増産期や検査項目追加で増えるため、ピーク時の枚数でも一度試算しておくと安全だと考えます。
必ずしも全画像を原寸で残す必要はないと考えられます。NG品や判定が曖昧だったものを原寸で長期保管し、明確なOK品はサムネイルと判定ログだけ残す階層化でも、「その時刻に検査しOKだった」という記録は担保できる可能性があります。ただし要求される証跡の水準は取引先で異なるため、どこまで軽くしてよいかは事前確認が前提になると考えます。
自社内で完結させる構成は可能ですが、冗長化・バックアップ・誤削除対策も自社の責任範囲になる点に留意が必要だと考えます。画像を社外に出さないメリットと引き換えに、守る責任が自社に集約されます。特に証跡として長期保管する画像は、二重化やバックアップの方針を保管設計と同時に決めておくのが望ましいと考えられます。
溜めるだけでは学習に十分とは限らないと考えられます。再学習で効くのはNGや判定が曖昧だった境界事例で、OK品ばかりが溜まると偏りが出て学習が進みにくい可能性があります。加えて、どこが不良かを人が印付けするアノテーションが別途必要になる場面が多いと考えます。何を残すかは容量だけでなく学習の観点からも設計するのが望ましいと考えます。
保管期間も容量も、他社の数字ではなく自社のカメラ設定と実ラインで測るところから見えてきます。証跡・再学習・工程改善のどれを重く見るかを起点に、現物での検証から一緒に設計を組み立てます。
画像保管設計について相談する