事例発表　「水産缶詰等におけるトレーサビリティシステムの導入について」

マルハ株式会社（マルハ原料トレース推進協議会）　品質管理課長　山口龍一氏

ただいまご紹介いただきましたマルハの品質管理を担当しております山口と申します。
冒頭に“優良な導入事例”という紹介でございましたが、本当に優良かと点ではまだまだ課題も多く、ちょっと耳の痛いところではございます。私どもは、トレーサビリティの構築に2002年から取り組みまして、品目は10種類以上、工場も20工場以上に導入しましたが、うまくいった事例と今でも問題が起きている事例や課題なども含めて、私どもの取り組みをご紹介したいと思います。
まず私どもがどのような商品を取り扱っているかという説明ですが、今は片仮名の「マルハ」となっておりますけれども、昔鯨を捕っていた大洋漁業といった方が馴染みのある方もおられるかと思います。現在、水産物の扱いが6割以上ですが、魚肉ハム・ソーセージなどの加工食品、畜産品や冷凍農産品、デザート、健康食品などの化成食品、なども扱っております。
製造拠点ですが、私どもの直営工場は4工場しかございません。それ以外は国内外の200社以上に製造を委託しております。委託工場の規模は小さいところで5人くらいから、多いところは4,000〜5,000人と規模は大小まちまちです。これらの工場に対して、プラントでなければ導入できないようなトレーサビリティシステムですと一部の商品しか対象とできず、基本的には使用対象に汎用性を持たせたシステムで、5人の工場でも導入していただけることを念頭に取り組んでおります。
システムで扱う品目も、農・畜・水産の3つの分野にわたって同一システムで、かつ扱い項目も共通化した項目で扱っております。この内容は順次紹介していきます。
今日は40分の持ち時間しかありませんので、最初に加工食品にシステムを導入する場合のポイントを、後半はできる限り多くの個別事例をご説明したいと思います。システム導入経過でございますが、最初は原料から加工、流通にわたるトレーサビリティ情報を順次渡していくという基本的な考えの下に、東芝テック（株）にソフト構築部分を依頼し、複数のモデル工場を設定した上で、共通して導入できる仕様の基本的な情報処理システムを作りました。これは弊社向けの専用ソフトですが、本日の展示会にもメーカー出展のパッケージソフトがありますが、類似のものとご理解いただければと思います。
現在このシステムは、冷凍農産品、中国産のウナギ蒲焼、水産缶詰、練り製品などの製造工場に導入しております。まだ缶詰は導入していることをあまり外部にアナウンスしていないのですが、製品の賞味期限が2年と長く、市場に流通している在庫はシステム導入前に製造されたものもあり、情報を集めて2年経った段階で情報を公開する予定です。ただし練り製品などの日販品、あるいは新発売の商品については在庫が無い関係で即に履歴情報を公開しております。
過去2年間、システム導入を進める中で、工場個別のパソコンで履歴データを集計して、その情報を工場から本社に送信してもらい、本社から販売先や消費者に情報を提供する作業を進めてきました。しかし取り扱う工場数や品目が増えてきた為、情報を管理する側の作業が増加することに対応して、インターネットを利用したWebサーバを構築し、ここに情報を集約する方式への切替え作業を進めています。
具体的には、日本冷凍食品検査協会がトレーサビリティ管理に設置しているサーバを借用して、基本的にはPC版で構築したシステムを転用し、更にWebアクセスに関しては複数の製造者、販売者が固有のIDとパスワードでアクセス権限を設定する方法でWebサーバを構築して、この4月から運用を開始しております。
これでパソコンにプログラムのインストールをしなくても、インターネットに接続してURLとパスワードを入力すればシステムの稼動が可能となり、データ管理上のトラブルやデータ送受信による管理の手間も大きく削減しました。
また新規導入する工場でも簡単に取り組めるため、各地の取引工場でもまず試用してみようということで、カニ、エビ、魚卵、鶏肉などを扱う工場で導入作業がスタートしています。
先ほど紹介されたカキや牛乳のように、一次産品や低次加工品では生産履歴をストレートに紹介できますが、加工食品になると、多くの原料、供給者の組み合わせで製品が作られるため、生産時期や生産者の違いによるバラツキなどが発生することがあります。たとえば原料で1年保存したものが履歴の公開で判明すると、「もっと短く保管されたものはないのか?」となります。また農産品の場合で「このような農薬を使っています」と公開すると「では使ってないロットは無いのか」、このような事が現実問題として発生します。またこの生産者のこの時期のものが欲しいとの要望が出てくることも考えられます。
商品仕様書や生産日などを全て公開すると、仕様を真似られたり、月単位で賞味期限を設定していても、原料保存期間が最も短く、1日でも早い製造の商品を要求されたりといった問題もございます。
ただ、このような懸念がある中で、最初のPC版システムでは直接のお得意様宛に履歴情報をFAXで提供する方法をとりました。今はインターネットでも一部の情報は簡単に見られますが、業務用などの商品によってはこれも直接販売先であるお客様にパスワードを連絡して情報公開を限定しています。商品知識がある相手からの問合せや質問であれば、説明によってご理解はいただけます。
私どもの会社は業務用食品の扱いが多く、トレーサビリティ取組みに対する評価をいただけるのは、消費者よりも直接販売先、つまり量販店とか生協などの購買担当者からの反応の方が大きく感じられます。商品が劣っていれば競争力はありませんが、同じ品質・価格で履歴情報がプラスできれば、他社との競争の中でご採用いただける。そういったメリットはあります。
どのような生産者の原料を使っているかを製造者の立場でどんどん公開してあげることは、原料供給者にとっても好都合になります。原料供給者の宣伝にも一役かっているわけで、原料の供給者と製造者の間の相互メリットに繋がる面があります。
導入効果と課題ですが、システムを導入するプラス面として、営業面では、まず商品に興味を持っていただける点があげられます。類以商品が多い場合は、興味を持っていただけないとなかなか商談にも入れません。但しホームページで一般向けに商品履歴を公開しても、時間が経ち、コンテンツが乏しいと、しばらく経つと飽きられてしまいます。逆に問題が起きて、十分な対応が出来ないと、何だ!トレーサビリティをやっているのに・・、やっていることはウソじゃないかと言われることもあります。
実際の例を挙げますと中国産のウナギなどに抗生物質の残留問題が発生し、“君の会社のウナギは本当に安全なのか”と問われたときに、他社は取り敢えず1つのでも分析検査結果を取り出して、大丈夫ですと沈静化対策をとりましたが、生真面目にトレーサビリティが出来るため、抗生物質の検査はこの池とあの池のロットだけで、全部やっているわけでないので、まだ確認できません、1週間お待ちください・・と返事したため、却って不安を広げてしまったということもありました。プラス面はもちろん大きいのですが、一時的にマイナスな面も起こりうることは覚悟しなくてはなりません。
怪しいと思ったら少なくとも1〜2日中には、ある程度問題の商品を特定しなくてはなりません。そのときに商品識別を素早く、かつ関私は品質管理担当なので強調したいのは、トレーサビリティの本来の目的は、リスクへの対処です。私ども製造者にとっての直接的リスク対処とは、一番がお客様に対する健康被害があってはならないということ、次に法令に違反してない食品を提供するというコンプライアンス上の問題です。このような問題は、商品設計と実際の商品との食い違いや、記載の間違いに何かのきっかけで気がつく、或いはクレームが何件か連続発生して異常に気がつくことが発端となることが多いのですが、怪しいと気がついて、生産記録から販売ルートまでの調査を開始して、原因と製品範囲の特定に1週間以上もかかってしまっては遅すぎます。怪しいと思ったら少なくとも1〜2日中には、ある程度問題の商品を特定しなくてはなりません。そのときに商品識別を素早く、かつ関係者に正確に伝達できるか、これがリスク管理上で要求される重要な点です。しかし私どものトレーサビリティのシステムでも流通上の識別追及という点では不十分な点があります。これはまた後でも説明します。
ここ説明する履歴データの中で、固定的なデータが非常に多くあります。これらをきっちり整理しないとデータの洪水になってしまいます。また整理作業によって製造上のリスクも確実に把握しておく。この作業をトレーサビリティ導入時に時間をかけて行わなくてはいけません。この作業が問題点を発見する重要なツールになっているわけです。整理しないままのデータを、可能だからと次々入力するとデータが膨大になってきます。最初に気合いを入れて作業するのは良いのですが、いざ運用してみたら大量のデータの中で、本当は何にデータが利用できるのかわからなくなることがあり得ます。
そういう中で、データ収集の目的を明確にしておかないと、システムに投資する金額の問題もかさみ、導入に踏み切れないところが出てくると思います。
トレーサビリティシステムだけを導入しても省コストや省力化には繋がらないため、別の側面も合わせてシステム構築することが必要です。その考え方のひとつとして、工場のファクトリーオートメーション整備を兼ねたシステム導入の考え方があると思います。ただし、これを製造工程に関して一つ一つ正確にやると、工場別に管理を変えねばならず、汎用性を考えるとちょっと難しい部分が出てきます。よって私どもは別の目的として、山積みになった商品仕様書の管理を共通化するという点を掲げてシステムの整備を進めました。
次にトレーサビリティ情報を伝達するということを念頭に置くのか?情報を1箇所に集めることを念頭に置くべきか?の側面で考えたいと思います。食品衛生法では問題が起きた場合の責任の所在は明確で、加工食品の場合は製造者の責任、輸入品では輸入者の責任、となっています。回収リスクを持っている業者は(図表の中の)赤い点線で囲んだ部分です。例えば回収の必要性が生じたときに、原料生産者に遡ってデータの調査・確認をする時間的余裕は極めて限られます。そうなると、伝達だけではなくて、その商品に対する責任を持つ者に必要な情報が集中する体制が必要になってきます。
トレースするデータを大別すると、原産地はどこであるか、どういった薬を使用しているか、アレルゲンは何が含まれているか?などの原料に由来する情報があります。また製造工程の温度や時間、どういう原料ロットを組み合わせたか?などは製造に由来する情報です。最後は販売の履歴。この3つに分けられますが、私どもの今のシステムで扱っているのは(図表中の)青色の点線の部分です。どうして製造工程の(図表中の)黄緑の点線を扱ってないかというと、工場と製品毎の工程によって違いが非常に大きいということがあります。これを全部一緒に合わせた汎用化システムにするには、かなり無理が発生します。製品別に類型化するという方法もありますが、例えば同じウナギを生産していても工場によっても管理手順が違います。また販売履歴は回収などを迅速に行うには販売経路ごとにどのロット商品が通過したかの記録が必要となりますが、現状では業者間のシステム規格が統一されておらず、簡単な解決策は見つかっておりません。
次に考えることは、データがどの時点で必要かということです。販売商品に問題が起きたときにすぐ必要なデータとは?あるいは製品履歴を公開するときに何を公開するのかという観点からすると、どのような原料で作られていて、検査結果はこうですというデータは必要ですが、工場で毎時間どういう温度で作られたかというのは、工程中では重要管理点として管理すべき項目ですが、異常がないことを前提に販売するので、その後はあまり必要がないのですね。
ただ問題が起きたときに、本当にこの工程で問題なかったかという点を検討するに際には多少時間をかけても多くの証拠と確実なデータが必要になります。このような実際の回収事故などの経験から考えると、これらのデータは確実に検索ができる形で工場に残しておけば良いという考え方を持っています。もちろん、工程記録に関するトレーサビリティのシステムを導入している工場は、(図表の)青い部分のシステムに対して、製造時間などで紐付けを行い、システム上の融合を図っています。
先ほど、データの固定化という話をしましたが、データ項目がいろいろあって、これを入力するとなると、加工食品の場合には原料数が多く、原料供給者も変化するため、毎回個別に入力するのでは、とんでもないデータ入力量になってしまいます。この作業を軽減するために私どもがやっているのは、基本的に固定的なデータを全てマスター化してしまうことです。たとえばウナギを作る生産者が30業者あれば、その個々の生産者の池の特徴から、どこにあって、どんな人が生産しているか。これらを1枚1枚のマスター表として作ります。また製品仕様書ごとに使用する原料も幾つかに限られますから、その個別の原料仕様書を全部作ってしまう。製品に対する検査仕様も同様にマスター化し、その中で検査方法や基準、たとえば高速液クロを使ってどの項目を測定し、定量下限は何ppmであるかなども、基本的にマスター化してしまいます。
これらのマスター化作業が終わると、その後、原料の受入に際して毎日入力すべきデータとは、どのロットの原料を何番の生産者から何時受け入れ、その状態はどうであった、という点だけを記録すれば良く、工場で製造した時点では、どの受入番号の原料をどのラインで何時使ったか?これを製造日報で記録しておけば、基本的には原料の組み合わせから原料生産者、製品の製造時間、検査結果などが製造時間軸を中心に紐付けできるわけです。また製造中の温度や金属探知機の結果などの工程上のデータについても、無理にデータをシステムに入力しなくても、現場記録を時間とライン番号ごとに記録を入れておけば、エクセル形式などでファイル化していればファイル名でハイパーリンクで結ぶ方法、また手書き文書の場合であればスキャナで取ってPDFファイル名でリンクする方法があります。最も手をかけない手段としては、どの書類棚の何ページに記録があるということだけをシステムに入力しておけば、問題時にはインデックスとしてすぐ拾うことができるわけです。
基本的に、紐付けをあまり難しく考えると混乱してしまいます。単純に製造・生産日と時間を基本として、加工原料の場合は原料製造ロットで識別します。たとえば、私の工場で今日1番のラインで朝9時から作業を開始したとき、9時から10時半までの原料の組合せを最初のバッチとしてAとします。次に10時半から原料の組合せが切り替わり13時まで続いた次のバッチをBにします。これらのバッチ名を賞味期限と共に表示しておけば、何月何日製造の○バッチということで一意的にどの製品かを特定できます。このような単純なわかりやすい形で商品の切り分け、識別を心がけております。
ロット識別番号については、品質保証番号として10桁くらい表示されていると一見ロット管理がしっかり行われているよう見えますが、実際の回収の際には、たとえば1商品毎に製品の番号が違うと想定してみて下さい。問屋さんに「これはひょっとすると危ないかもしれないから、販売止めてください」というケースの場合、何番と何番を止めますかという連絡に関して、1万個あったら、その1万個を正確に伝えられるのかという問題が発生します。まだ連番であれば何とかなりますが、飛び番号になったら連絡は難しくなってきます。
牛の場合ですと1頭1頭別々にBSEのリスクがありますので1頭毎の管理は非常に大事なことではありますが、それ以外原料では1つの容量が小さかったり、かつ原料生産時のリスクもまとまった量で起こりうる場合など、ある程度まとまったロットで、かつロットの大きさも回収発生時にどの範囲までを1つの対象にするかを念頭で組み立てておくと、整理しやすくなると思います。
次に、具体的な事例をご紹介させていただきます。
最初の図表は私どもでやっていることではございません。スーパーでよく見るケースです。たとえば生産者A、B、Cが存在していて、加工場でAの生産者のものを使った場合、出荷する箱に「A」という番号を付けておきます。契約したスーパーの店舗では、予めA、B、Cの生産者情報を記載したカードを用意しておいて、Aの記号の商品が入荷したらAのカードを売場に掲示するわけです。そうすると、消費者はこの人が作ったのかと、写真入りのカードを見てトレーサビリティも整備されている・・との印象を受けます。これは非常に基本的な考え方ではないかと思います。単純ではありますけれども、わかりやすい。
私どもが今、缶詰で行っているのは、この考えをもうちょっと進めております。先ほど述べた履歴データのマスター化作業を進めて、原料を受け入れ時には受入れ原料日報を入力します。
原料日報は、どの生産者、何時、どのような状態で、などを入力します。それを実際の製造時には、どの原料を使いましたという情報を、製造日報というページで、使用原料を選択します。
今日は「何月何日に受入れしたカニの2番」を使いました。調味料は「何日受入のロット何番を使いました」と、選択をするわけです。これらを全てパソコンでデータ処理できますから、まとまった履歴データを電子メールで販売先の会社に送ります。私どもの場合は、委託工場にデータ入力をやっていただいて、賞味期限の長い缶詰などで毎日ではなく、週1回まとめてCSV形式のテキストデータで弊社に送っていただいているという仕組みです。
これだけでも、ホームページに掲載する、原料の組成や生産時期及び生産者名、どういうアレルゲンが含まれているかなどを公開することは可能です。一例ですがこれが現在私どもの会社のホームページで公開している内容です。
次の事例は、ちょっと複雑になってきます。これはちくわのトレースシステムで、先程の缶詰とシステムのソフトは同じですが、運用方法が違います。主原料はすり身ですが、北米産からタイ産からいろいろあって、北米でも何々海域産などのロットがいろいろあります。実際の製造では、一つのちくわを作るにも3種類から4種類のすり身を組合せて使います。更に様々な副材料、添加物も使用されてます。それを(図表の)このミキサーで混合します。その次は連続ラインに投入され、加熱調理後に冷却され、最後に包装されて出来上がるわけですが、問題は違う製品アイテムも同じ日に2〜4種類製造しなくてはならず、また1アイテムでも使用する原料のロットが途中で無くなる場合は違う原料ロットに切り替える必要があります。このように数種類ある原料のロット切替毎に、製品のバッチを区分しようとすると、1日に10〜20ものバッチに区分されてしまいます。その都度ラインを洗浄して交換していたら、毎回洗浄に30分や1時間はかかりますので、製造するより洗っている時間の方が長くなってしまいます。かといってアレルゲンが含まれている原料の切替時には、きちんと洗浄して区分しなくてはならず、製造途中での洗浄の必要性はアレルゲンの有無で決めています。
洗浄せず、工程を連続しながら原料を切替える場合、どうバッチ区分しているかですが、一例として魚のすり身のF1というものがあって、10時42分にF2というすり身に切り替わりました、という時間の切り替わりを記録する方法を取っています。ただしその都度の洗浄はしていないので、実際は一定時間混合が起きています。10時42分から今度11時15分まではF1とF2が混ざっていますけれど、その後はF2だけになります。混合する時間はホッパーの残存量などで測定して、ほぼ間違いない時間を決めて対応する方法を取っています。
ただし、このように何分までの管理・記録が面倒でできない場合もあります。その場合は、9時から10時までは何を使っていましたか?次の1時間は?という記録を行う場合もあります。さきほどの原料ロットの切替えをこの方式で記録した例では、最初の1時間はF1だけ、次の1時間はF1とF2の混合、更に次の1時間もF1とF2の混合、となります。混合原料の時間が不正確で原料が混合される製品バッチが増えることになりますが、管理は多少手を抜くことができます。これら工場の人手や原料の切替え頻度などを見て2つの考え方をそれぞれ適用しています。
またちくわの場合、原料受入れ記録については基本的に缶詰と流れは一緒ですが、扱う原料数が多く、識別が煩雑ということで、原料受入日報の作成後、原料ロットを示すインデックスとしてQRコードのラベルを印刷発行しています。このラベルは、原料ロットのわかりにくいものに個別あるいはパレット毎に貼っておきます。また原料に識別できる番号などが記載されている場合は、普通のノートに原料バーコードラベルを貼った台帳を作り、発行したQRラベルを台帳に貼っておきます。具体的には原料に「03年8月19日製造BX」と識別番号が書いてある場合は、発行QRラベルにその識別番号を記載しておきます。そうすると製造で使われた原料の記録で「03年8月19日BXロットとあれば、それに該当するQRコードを台帳でリーダーで読めば、原料を検索しなくても製造日報作成時に原料組み合わせの選択が短時間でできることになります。
次の図表は、鶏肉のトレースの事例説明です。A、B、Cの鶏舎から原料が加工場に入荷して、時間を追って処理されます。処理は工場の中で1羽の鶏から部位ごとに切り分けられ、異なるラインに分岐しながら、モモ肉、手羽先肉など個別の処理が行われ、最後に包装が行われます。これらの精肉は直接店舗に送られる場合もありますが、一度配送センターに送られて、ピッキングされて量販店の店舗に送られる場合もあります。店舗では、まとまった部位ごとの肉をバックヤードでトレイ包装して店舗に並べます。この場合、バックヤードが最終包装・表示の場合になるので、ここで賞味期限や識別記号が記入されていなければ、トレースバックもトレースフォワードもできません。現在進めているケースではバックヤードでEAN128やITFなどのコード読取り装置を備えており、納品する箱にこれらのバーコードを印字しておけば、識別番号を読取ってもらい、トレイ表示にも識別記号の印字が可能になっています。このように自社のシステムで作成した識別情報を流通先の識別システムに合わせることがトレーサビリティを確立する上で重要です。
加工者とピッキングを行う業者が同じトレースシステムで結ばれている場合であれば、工場で識別用のバーコード印字を行わなくても、工場で単純に製造日とバッチ番号だけを印字しておけば、ピッキング場でその製造日とバッチ番号に対応したバーコードを印字して最終配布する包装単位で貼り付けることも可能となります。このシステムは、最初に述べたWebシステムでデータが一元化されているので、加工場とピッキング場が離れていても、容易にデータの照合が可能です。ただこの事例は、まだ実験段階で7月以降に実用化する予定です。
またこのシステムでは、トレイの品質保証番号をお客様が量販店のホームページにアクセスして、トレーサビリティ欄の商品検索窓で番号を入力すると、その検索キーで自動的に加工者側が作成したホームページにリンクされ、肉の商品履歴がわかる仕組みになっています。消費者は、量販店がトレーサビリティ管理をしているように映る仕組みです。
鶏肉をどのように工場内でロット区分をするかという方法は、ちくわの例とは異なり、単純な方法を採用しています。鶏肉加工ラインは原料搬入から最終工程まで一連のコンベアがほぼ一定のスピードで動いています。鳥を原料受入口からラインに吊るしてあげると、屠殺、脱毛、切り分け、洗浄、冷却など工程が一定速度で推移して、その後ラインが分岐しても肝、モモ、正肉などのそれぞれの包装までの時間を計測することによって原料投入から出来上がりまで、部位ごとに分単位の経過時間の基準ができます。原料投入する者が、「今から原料ロットがAからBに変わります」と、工場内に一斉放送すると、それぞれの部位のパッキングする工程でタイマーをセットします。そうすると52分かかる工程であれば52分後にタイマーが鳴って、ロットが切り替わったことが判明し、製品バッチの記号を入れ替えてあげればいいわけです。
もちろんラインスピードの多少のズレはありますので、±5分程度の混ざりがあるものとして区分しておきます。
写真は、原料投入から屠殺、検査されて、それぞれの枝肉処理工程を経て、製品ごとにラインが分岐して包装されるまでの様子です。
次は中国と台湾の冷凍農産品の事例です。このシステムは弊社で最初に導入したトレーサビリティシステムです。ソフトの製作は、東芝テック（株）に委託しました。
農産品には収穫時期があり、原料の入手は年の数ヶ月だけなので、その時期には工場に1年分の原料を受入れて保管します。その時に原料受入台帳に原料履歴データを入力すると同時に2次元QRコードのラベルを印刷して、パレットごとに貼付しておきます。これを製造時にQRリーダーで読み込み、原料ロットの使用日、時間を製造記録として自動的に入力してゆきます。これに加えて農薬などの分析検査記録もデータ入力した後、まとめて週に1回、日本の私どもの会社にCSVデータを送ってもらいます。(図表参照)
履歴情報について顧客からの問合せがあった場合には、所定のアウトプット様式(図表)を使ってFAXで提供する体制をとっています。
またこの製品については、製品の履歴テキスト情報をQRコード化して、製品の箱にラベルとして貼り付けています。ストックポイントや店舗などではQRリーダーがあれば原料の履歴や製造工程などが直接テキスト情報として読むことができます。
ここに示すのが製品用のQRコードラベルです。原料識別用のQRと比べて情報量が大きいので、QRを3分割してラベルを大きくなっています。ただしスキャナが安価ではないため、得意先に広くリーダーを配布するのは難しく、今後は最新型の携帯電話でQRコードを直接読めるように仕様を修正する予定です。最近はテレビの宣伝でもQRコードの読み取りが取上げられていますね。予想以上にこのような機器の進歩が早いので、ICチップなども含めて、今後の技術進歩や利用拡大に備えておく必要はあります。その場合でもトレース情報のデータベースが確立していれば、対処は比較的容易です。またホームページへのアクセスもパソコンからではなく、携帯電話からの利用も普及していますが、ホームページのURLを入力して、商品の保証番号などを入力する手間は正直面倒です。ここでQRコードにそのままURLと品質保証番号の検索コードを入れてしまえば、直接携帯電話でQRコードを読めば、履歴が検索されたページを表示することも可能です。この仕組みについては今年中に実用化する計画です。
製品ロットの識別方法ですが、(写真の)「賞味期限2004年4月27日AC」と記載されていますが、日付後の記号のうち最初の1文字の意味は、8時からこの工場は操業しているので毎朝8時から9時までは「A」,9時から10時までは「B」、を示します。また2文字目は、原料の組み合わせを示しその日の最初から数えてA,B,Cと3回目の切り替わりを意味します。工程の温度管理記録など時間と相関するので1文字目の「A」で紐付けし、原料の組み合わせは2文字目の「C」で紐付けます。また製品のJANコードと工場固有記号、賞味期限と2文字のロット番号でどのような製品でも特定することが可能です。
次に中国のウナギ蒲焼の例ですけれども、基本的には缶詰のシステムと同じです。ただしウナギについては抗生物資の残留などが特に問題になっているので、工場で原料受け入れ後に高速液体クロマトグラフィーで自主分析検査を行っています。その検査結果を原料ロット紐付けしてデータ入力して、養殖池ごとの安全性を履歴データとして確認できるようにしています。
次に図は、ウナギのPC版トレースシステムを日本冷凍食品検査協会のWebサーバーにアクセスするシステムに切り替える状態を示しています。従来、工場にあるパソコンにインストールしたソフトウエアで処理していたものを全ての情報をWebのデータベースに直接入出力することになります。そのためデータの受け渡しは省略され作業が簡素化されます。またソフトウエアは頻繁に更新されることが多く、不具合があった場合は迅速に修正しなくてはなりませんが、Web利用の場合はサーバーソフトを専門家が操作するため、メンテナンスが飛躍的に楽になります。これまで台湾や中国など海外の工場にシステムを導入して、動作不良の場合、従来はインターネットのMessengerにあるリモートアクセス機能でパソコンを遠隔操作して対処していましたが、言語や使用環境の違いもあり僅かな修正にも半日以上かかることもありました。工場で製品を何時までに作らねばならない場合、ラベル印刷が間に合わない等のトラブルも起こしていました。
もとろんWeb環境の良し悪しでWebシステムが導入できるかが決まりますが、PC版のシステムとWeb版のデータ交換を可能にして、相互にバックアップできるシステムを構成しようと思っています。
最初に履歴情報をできる限りマスター化する作業そのものに意味があると述べましたが、これがその一例です。中国のウナギ養殖で使用される薬剤のマスター作成作業で、様々な漢字名称の薬が出てきます。しかしこれでは一見何の薬かわかりません。漢方薬だと言われると、何となく納得してしまいますが、抗生物資の残留が問題になっている業種なのでこれら薬剤の本質をこの時点で徹底的に調査しておけば、原料生産履歴の中でこの薬を使用している事実があっても安全性の判断の参考になります。他のケースでもこれらの作業の積み重ねが、リスクを把握する点で重要な作業になります。
次にチリサーモンの例ですが、現在ヨーロッパとチリではサケ養殖が非常に盛んで、EUではトレーサビリティの法制化も予定されています。その中で北欧のAKVAシステムというトレーサビリティシステムがチリの多くの養殖業者でも導入されており、孵化場から始まり養殖や加工場までの詳細履歴をインターネットのXML形式で履歴データを入手することが可能です。しかし残念なことに言語の問題や、輸入コンテナ単位のロット区分と、日本国内での流通単位に対応する識別との紐付けが対応しておらず、そのままデータを日本で利用・閲覧するには問題が残ります。
しかしこのシステムがXMLファイリングシステムである利点を生かし、国内販売の識別コードを私どものWebトレースシステムで管理し、識別コードの相関表とXMLデータをファイルとして直接私どものWebサーバーに取り込み、一部お客様にホームページで公開する部分だけを日本語に変換する作業を行えば、少ない労力で大量の履歴データを活用できるようになりました。問題が発生した時点ではファイル検索も容易にできるので、対処も可能です。このようにして海外のシステムとの融合も可能となりました。
最後にトレースシステム導入に際してのまとめです。加工食品の場合、データ量が膨大になるので、変動的・固定的なデータの区分、システムに文字情報として入力が必要なデータと紐付けだけで良いデータの区分けをすること、また工場や工程によって異なる部分は独立しておけば、品種を越えて同一システムによる共通使用が可能です。またメンテナンス性を十分考慮しておけば、国内外、規模の大小を超えた導入も可能です。
履歴データのインプットと、識別情報などのアウトプットについては他のシステムとのデータ交換は、今後どうしても避けて通れないのでシステム接合の柔軟性が要求されます。またアウトプット部分であるQRコードやRFIDなどは注目されていますが、商品やシステムに興味をもってもらう意味では重要で、今後の利用範囲の拡大にも備えておく必要がありますが、まだ活用面ではコストや機器、規格統一などで不十分な点が残っています。ただデータベースをしかっり構築しておけばアウトプット部分であるこれらユビキタス端末などの今後の発展に対応することは比較的容易です。
またデータ処理量に直接関係するのがロットの考え方です。回収リスクを想定して、必要な程度のまとまったロットで整理すれば、不要なデータ処理作業は軽減されます。
最後に私どものシステムで課題と認識していることは、「基準の逸脱状態がシステムで明示されること」です。例えば製品マスターの入力内容に関して二重チェックや責任者の承認がされているか、データの更新管理が確実になされているか。製品検査は対象ロットのリスクを担保できる範囲・頻度で行われているか、など、システムを構築しても、往々にしてデータの管理体制が出来ていないと、扱うデータが膨大になるために却ってリスクを見逃す要因に繋がってしまうことに注意しなくてはなりません。システムの信頼性を確立するにはまだ時間がかかるとは思いますが、トレーサビリティ構築のためにはISO9001などの管理を取り入れた体系的なシステムにしていくことが大事だと思っています。
急ぎ足の説明で時間も若干オーバーしてしまいました。以上で説明を終わりにしたいと思います。どうもありがとうございました。

ページトップへ