帳簿は377尾、再推定は360尾。差の17尾は死んだ魚なのか？養殖の魚群記録

たとえば、帳簿では377尾のはずなのに、数え直した推定値は360尾。差の17尾を、そのまま死亡した魚の数に足してよいでしょうか。この例では元の尾数にも推定が含まれるため、原因不明の差として残し、測り方や移動・出荷の記録を調べます。

出荷した魚を、元の群や給餌日誌まで戻って調べるときも、いけす名だけでは途中の分養や合流を追えません。

記録の軸は、場所を示す「いけすID」と、飼育するまとまりを示す「群ID」です。両者の対応に期間を持たせ、分養・合流のたびに元群、先群、日時、数量と測定区分を残します。出荷IDからそのつながりを逆にたどり、当時の給餌日誌を参照する設計です。群の由来をたどれる範囲と、出荷した個体の給餌履歴を確定できる範囲は分けて扱います。

MIC（南日本情報処理センター）の「養殖管理システム」は、移動・合流を含む経歴、日誌、出荷本数・重量の記録機能を説明しています。以下は公開機能を参考にした独自の記録設計例です。日付・数量・測定条件を設定しています（想定例）。給餌量・飼育密度・投薬・疾病判断は、専門的な管理基準に従ってください。

場所と魚のまとまりを、別々に追う

いけすI01を前年にも使っていたとしても、前年の群IDを今年の群IDへ書き換えません。いけすは場所として残し、群は別に登録します。群の台帳には魚種、導入日、由来を、所属の記録には群ID、いけすID、所属開始日時、終了日時を持たせます。

2026年9月1日から8日まで、マダイを扱う架空の2いけすI01・I02を使います。図では、最初に導入する群をA、分養して元のいけすに残す群をA1、もう一方へ移す群をA2としています。後から導入する群がB、A2とBを合流させた群がCです。実務では年度や拠点を含め、別の群に同じIDを再利用しないルールを決めます。

たとえばAの所属を「9月1日09:00から、9月3日10:00の直前まで」とし、分養先A1・A2は9月3日10:00から始めます。こうすると境目の時刻に旧群と新群を二重に所属させません。時刻が分からない移動は、前後関係を確認する対象として残します。

800尾を分けてから、新しい群と合流するまで

図1　2いけすの分養・合流。A1を全量出荷して空いたいけすにBを入れます。矢印は群の由来を示し、同じいけすに留まるつながりも含みます。

9月1日、最初のいけすへ推定800尾を入れます。3日10時に分養し、推定500尾をその場に残し、推定300尾を空いているいけすへ移します。分養後はどちらにも新しい群の番号を付け、元の群とのつながりを保存します。動かなかった500尾にも、由来が分かる記録が必要です。

4日9時に、残した群を全量出荷します。手で数えた500尾、正味重量750.0kgを記録し、いけすが空になったことを確かめた設定です。翌5日9時に、このいけすへ新たに実測200尾を受け入れます。6日10時、その200尾を、先に移した推定300尾と合流させます。

合流イベントM002には、A2からCへ300尾、BからCへ200尾の2行を作ります。A2はI02に留まり、BだけがI01から移ります。「親群」という一つの欄をBで上書きせず、両方の関係を保存します。Cの開始数500尾は、推定を含む合算値なので推定として残します。期間内のA2には、別の入出や確認済みの死亡した魚はないという仮定です。

現場担当が移動票を入力し、生産確認者が所属期間・親子関係・数量の根拠を確認してから、出荷担当へ渡します。「確認済み」は記録を照合した状態です。数量の「推定／実測」の区分はそのまま保持します。

給餌した時刻から、そのときの群へ戻る

移動日の記録を日付だけで結ぶと、午前の給餌を午後の群へ付けてしまいます。6日08:00にはB／I01への給餌2.0kgと、A2／I02への給餌3.0kgを記録し、合流後の14:00にはC／I02へ5.0kgを記録する例とします。

給餌ID、実施日時、群ID、いけすID、飼料の識別情報、量と単位、量の測り方、記録者を残します。環境記録にも、計測日時、測定項目、単位、機器、位置・深さなどの条件を付けます。たとえば水温24.0℃という値だけでなく「6日07:50、I02、温度計T01、水深1m」として保存し、後から当時の群A2へ対応付けます。

実施日時と入力日時は別欄にします。6日14:00の給餌を7日09:00に入力しても、7日の群へ付け替えません。時刻・対象・単位が欠ける記録は「要確認」とします。訂正は元の記録IDと版、訂正理由を残し、確認後に関連する集計も見直します。

S001からCを逆にたどると、合流後のCの給餌と、合流前のA2・Bの給餌に到達します。A2の親であるAの分養前記録も参照できます。一方、分養後の兄弟群A1の給餌はCの祖先の記録ではありません。また、Cから出荷した120尾がA2由来かB由来かは、この群単位の記録だけでは確定できません。両親群の日誌を参照できても、そのすべてを120尾の給餌履歴として確定表示しない設計です。

帳簿の377尾と、再推定した360尾の差を調べる

8日09:00、CからS001として120尾を出荷した例を考えます。尾数は全尾を手で数え、重量ははかりW01による正味180.0kgとし、尾数と重量の記録を別の根拠として保存します。重量を平均魚体重で割って尾数を出した場合は、重量が実測でも尾数は推定です。

開始時のCは推定500尾です。7日に回収して数えた死亡した魚3尾を別記録D001として残し、ほかの入出がない条件で計算すると、出荷後の参考残数は500−120−3＝377尾です。出発点が推定なので、377尾も確定した在池数ではありません。

同日15:00に再推定した値が360尾なら、照合差は360−377＝−17尾です。まず推定条件、二重入力、未入力の移動・出荷、尾数の記録を確かめ、理由が分からなければ不明差として保留します。17尾を自動的に死亡数へ加えません。360尾の新しい観測記録を追加しても、500尾の旧記録や377尾の計算結果は消さず、基準の採用判断と差異の確認状態を分けて残します。

表1は同じ例の要約です。照合用記入シート（Excel）では、群と場所、移動、給餌日誌、出荷、推定根拠、尾数照合を同じIDで追えます。記入例と空欄版を分けて用意しています。

時点（2026年）	I01の群・状態	I02の群・状態
9/1 09:00 導入	A：推定800尾	空
9/3 10:00 分養M001	A1：推定500尾	A2：推定300尾
9/4 09:00 S000全量出荷後	空。実測500尾を出荷	A2：推定300尾を引継ぎ
9/5 09:00 B導入	B：実測200尾	A2：推定300尾を引継ぎ
9/6 10:00 合流M002後	空	C：推定500尾（親群合算）
9/8 S001出荷・再推定後	空	参考377尾／再推定360尾。差−17尾は保留

表1　いけす別の時点照合（架空例）。開始・分養・再推定の尾数は、総魚体重量の見積りを標本平均魚体重で割る設定です。標本20尾、平均1.5kgなどの入力値は計算説明用で、推定精度や標本数の妥当性は未検証です。

シートの未入力と、確認済みの0は別に扱います。死亡した魚の重量を測っていなければ空欄で残し、0kgに置き換えません。照合差が0でも、数量の根拠や担当者の確認状態は別に残します。

今ある日誌で、出荷した魚の由来をたどる

まず自社の出荷を一件選び、「元群まで戻れるか」「移動前後の給餌を分けられるか」「尾数と重量の根拠へ戻れるか」を確認します。既存の給餌日誌と出荷台帳に共通IDや日時を足すだけで答えられるなら、記録全体を作り直す必要はありません。

次の3つは、組み合わせても使える方法です。同じ分養・合流・出荷例を追えるか、記録をどこで持つかを比較します。

選択肢	合う場面	同じ例で確かめること	入力・確認の負担
既存日誌・台帳を整理	原票を残して照合できる	S001→C→A2・Bを人が追えるか	共通IDの付与、版の管理、転記確認
現場入力を追加	記録の遅れや対象違いを扱いたい	移動前後の実施時刻と入力時刻を分けられるか	入力項目の絞込み、未送信・訂正の確認
養殖向け専用システム	群の扱いが標準機能に合う	複数親群、推定区分、履歴出力が実務に合うか	初期台帳整備、実データでの操作確認

たとえば専用システムを使いながら、現場の入力だけ補う組合せも検討対象です。MICの公開ページだけでは、この記入シートと同じ列、推定区分、出力形式や連携仕様が備わるとは確認できません。導入前に、同じ分養・合流・出荷例を製品上で再現できるかを確認します。

既存ツールで残る受け渡しや履歴の課題が具体的になった場合は、匿名化した日誌、移動票、出荷台帳と、追えない一件をそろえると相談対象を説明しやすくなります。

群に加えて一頭ずつ追う必要がある業務では、牛の個体・群・場所を別々に管理する例が比較になります（牛の個体・群・場所を出荷までたどる台帳の作り方）。

養殖の記録整理をNeoLogicに相談

参考出典

• 南日本情報処理センター（MIC）「養殖管理システム」（分養・合流の経歴、養殖日誌一覧、出荷一覧、生簀履歴照会）

出典確認日：2026年9月15日。ページに発行日・版番号の表示はありません。移動・日誌・出荷の機能説明を参照しています。記入シートの列・数式・ID体系は独自の設計例です。