農業・農業DX

【2026年最新】農業法人の資材発注・原価管理をClaude Codeで自動化

施設園芸法人の資材発注ログと在庫台帳をClaude Codeで突合し、圃場別の原価配賦レポートを自動生成した実装手順とhooks/permissions設計を解説する想定事例。

【2026年最新】農業法人の資材発注・原価管理をClaude Codeで自動化


結論:農業法人の資材(肥料・農薬・種苗)発注と圃場別の原価管理は、Claude Codeに「集計」と「突合」だけを任せ、書き込み権限をhooksとpermissionsで塞ぐ設計にすると、経理・現場双方が安心して使える自動化になります(想定シナリオ)。

  • 要点1:圃場ごとにバラバラなLINE報告・紙の資材消費記録をCSV正規化し、Claude Codeに集計・突合させることで、月次の手作業時間を大幅に圧縮できます(試算)
  • 要点2:在庫マスタへの書き込みはpermissions.denyとPreToolUseフックで二重に塞ぎ、Claude Codeには読み取り専用のCSVスナップショットだけを渡す設計が安全です
  • 要点3:圃場別の原価按分ロジックはコード化して毎回同じ基準で計算させることで、担当者ごとの按分ブレをなくせます

対象読者:農業法人の情報システム担当者・農業DXを支援するSIerのエンジニア・生産管理/経理を兼務するPM

今日やること:直近1ヶ月分の資材消費ログをCSV1枚にまとめて、本記事の手順1(正規化プロンプト)を試してみてください。

事例区分:想定シナリオ(モデルケース)。以下は実在する特定の企業の事例ではなく、施設園芸を中心とする農業法人(圃場10〜15区画・従業員30名規模を想定)で典型的に起こりうる課題をもとに構成した仮説ベースの実装解説です。数値はすべて試算値であり、実測結果ではありません。

「資材の発注、いつも誰かの記憶と勘に頼ってません?」

農業法人のDX支援でよく聞く相談なんです。肥料や農薬、育苗用の種苗は圃場ごとに使用量がまったく違うのに、消費記録はLINEのテキストだったり、圃場の作業日誌に手書きだったり、フォーマットがバラバラ。月末になって「あれ、この資材どの圃場にいくら使ったんだっけ」と経理担当が困る、というのが典型的な流れです。正直に言うと、この手の「記録はあるのに集計できない」問題は、農業に限らず建設・製造の資材管理でもよく見かけます。

この記事では、施設園芸法人(想定)の資材発注・原価管理をClaude Codeで自動化した実装手順を、hooksとpermissionsによる安全設計まで含めて解説します。

導入前の状況:紙とLINEに散らばる資材ログ

想定した法人の業務フローはこうです。圃場担当者が肥料・農薬・種苗を使うたびに、LINEグループへ「〇〇圃場でA肥料20kg使用」と書き込むか、紙の作業日誌に手書きする。月末に経理担当がそれを目視で拾ってExcelへ転記し、在庫マスタ(別のExcelファイル)と突き合わせて発注リストを作る。この転記作業だけで月6時間ほどかかっていた、という試算です。

ボトルネックは大きく3つありました。

  • 圃場担当者ごとにLINE報告の書き方が違う(「20kg」「20キロ」「二十キロ」が混在)
  • 在庫マスタの更新が月1回のため、発注点割れに気づくのが平均3〜4日遅れる
  • 原価按分(どの圃場にいくらコストがかかったか)が担当者の感覚頼みで、月によって基準がブレる

Claude Codeに任せた5つの役割

実装チームがClaude Codeに任せたのは、判断や書き込みではなく「集計」「突合」「按分計算」の3種類だけに絞り込むことでした。具体的には次の5つです。

  1. 資材消費ログの正規化 — LINEのテキストログと手書き日誌のスキャン起こしをCSVに変換し、単位表記(kg/キロ/を統一)を揃える
  2. 在庫マスタとの突合・発注点判定 — 正規化したCSVを在庫マスタ(read-only CSVスナップショット)と突合し、発注点を下回った資材を抽出する
  3. 圃場別の原価按分計算 — 資材費を使用量ベースで圃場ごとに按分し、月次レポートを生成する
  4. 異常値の一次スクリーニング — 前月比で極端に消費量が増減した圃場・資材にフラグを立てる(最終判断は生産管理責任者が行う)
  5. 日次バッチでのレポート更新 — 非対話モードで毎朝スクリプトを実行し、発注アラートをSlackに通知する

最初の実装エピソードとして印象的だったのが、正規化の段階でした。圃場担当者Aさんは「20kg」、担当者Bさんは「20キロ」、担当者Cさんは日付を「7/3」と「07月03日」で書き分けていて、単純な正規表現だけでは拾いきれなかったんです。ここでClaude Codeに渡したプロンプトが次のものです。

以下はLINEグループから抽出した資材消費ログのテキストです。
各行から「日付」「圃場名」「資材名」「数量」「単位」を抽出し、
数量はすべてkgまたはL(リットル)に統一したCSVを出力してください。

- 日付表記のゆれ(7/3, 07月03日 など)は ISO8601 (YYYY-MM-DD) に統一
- 単位表記のゆれ(キロ, kg, 20kg など)は数値と単位を分離
- 抽出できなかった行はスキップせず、"要確認" 列に理由を記録
- 不足している情報があれば、最初に質問してから作業を開始してください
- 仮定した点は必ず"仮定"と明記してください

入力:
{LINEログのテキスト}

2つ目のプロンプトは、在庫マスタとの突合・発注点判定です。

正規化済みの資材消費ログ(consumption.csv)と、在庫マスタの
スナップショット(inventory_snapshot.csv)を突合してください。

- 資材ごとに「現在庫 = 前月末在庫 - 当月消費量」を計算
- 在庫マスタの reorder_point 列を下回った資材を抽出
- 出力は shortage_list.csv とし、列は
  [資材名, 現在庫, 発注点, 不足量, 主要使用圃場] とする
- inventory_snapshot.csv は読み取り専用です。書き込み・更新は行わないでください
- 数字と固有名詞は、根拠(計算式)を添えてください

3つ目は圃場別の原価按分です。ここで実装チームが最初につまずいたのが「按分ロジックを毎回自然言語で説明し直す」やり方でした。担当者によって「面積按分」「使用量按分」の解釈が微妙にずれて、月ごとに数字の傾向が変わってしまったんです。そこで按分ロジック自体をPythonスクリプト化し、Claude Codeにはそのスクリプトの生成・修正だけを任せる形に変えました。

圃場別の資材原価按分スクリプト(cost_allocation.py)を作成してください。

要件:
- 入力: consumption.csv(圃場・資材・数量), price_master.csv(資材単価)
- 按分方式: 資材ごとの「使用量 × 単価」を圃場ごとに合計する(面積按分は使わない)
- 出力: field_cost_report.csv(圃場名, 資材費合計, 内訳)
- 按分方式を変更する場合はコード内の定数 ALLOCATION_METHOD で切り替えられるようにする
- テストケースを3件(圃場1つのみ使用/複数圃場で同一資材/データ欠損あり)作成する

4つ目は異常値の一次スクリーニングです。前月比で消費量が跳ねている圃場・資材を見つけて、経理担当に「確認してほしいリスト」を作らせる、という位置付けにしました。

field_cost_report.csv(今月)と field_cost_report_prev.csv(前月)を比較し、
資材ごとの消費量が前月比±30%を超えて変動した圃場をリストアップしてください。

- 出力: anomaly_watchlist.csv(圃場名, 資材名, 前月消費量, 今月消費量, 変動率)
- これは異常の確定ではなく「確認してほしいリスト」です。原因の断定はしないでください
- 変動率の計算式をレポート内に明記してください

実装スタック

  • Claude Code CLI(非対話モード -p / --bare
  • Python 3 + pandas(CSV正規化・突合・原価按分)
  • settings.jsonpermissions.allow / deny によるコマンド制御)
  • PreToolUse hook(在庫マスタへの書き込み系コマンドをブロック)
  • cron(毎朝の日次バッチ実行)+ Slack Webhook(発注アラート通知)

hooksとpermissionsによる安全設計

正直、ここが今回の実装で一番気を使った部分です。在庫マスタや原価マスタは経理データなので、Claude Codeに誤って書き込み権限を渡すと、圃場担当者の一言のプロンプトで数字が上書きされてしまうリスクがあります。そこで採用したのが、settings.jsonpermissionsとPreToolUseフックによる二重ガードです。

まず.claude/settings.jsonで、在庫マスタや原価マスタを更新しうるコマンドをdenyに入れ、読み取り専用のスクリプト実行だけをallowにします(Claude Code公式ドキュメントの permission rule syntax に準拠)。

{
  "permissions": {
    "allow": [
      "Bash(python3 scripts/normalize_logs.py *)",
      "Bash(python3 scripts/match_inventory.py *)",
      "Bash(python3 scripts/cost_allocation.py *)"
    ],
    "deny": [
      "Bash(*inventory_master* UPDATE*)",
      "Bash(rm *)",
      "Write(./data/inventory_master.csv)"
    ]
  }
}

さらに、万が一denyルールをすり抜けるコマンドが来た場合の保険として、PreToolUseフックで「在庫マスタ本体へ書き込もうとするBashコマンド」を検知してブロックするスクリプトを仕込みました。実装中、実際にテスト用のプロンプトで「在庫マスタも直接更新して」と指示したところ、このフックが動作をブロックしてくれた場面があり、二重ガードの効果を実感したエピソードです。このフックスクリプト自体もClaude Codeに次のように依頼して生成しました。

PreToolUseフック用のシェルスクリプトを作成してください。

要件:
- Bashツールのコマンドに inventory_master.csv への書き込みを示す
  パターン(リダイレクト、tee、sed -i、cp/mv での上書き)が含まれる場合はブロックする
- ブロック時は permissionDecision: "deny" のJSONを標準出力に返す
- 該当しない場合は exit 0 で通常のフローに戻す
- jq コマンドが使える前提で書いてください

生成されたスクリプトが次のものです。

#!/bin/bash
# .claude/hooks/block-inventory-write.sh
cmd=$(jq -r '.tool_input.command // ""')
if echo "$cmd" | grep -qiE 'inventory_master\.csv' \
   && echo "$cmd" | grep -qiE '(>|tee|sed -i|cp |mv )'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "在庫マスタ本体への書き込みはブロックされています。read-onlyスナップショット経由で突合してください。"
    }
  }'
else
  exit 0
fi

hooksの設定方法や利用できるイベントの詳細はClaude Code Hooks実践ガイドにまとめています。permissionsのルール設計をチームでどう合意形成するかはClaude Code権限設計ガイドも参考になります。

日次バッチ運用(非対話モード)

Claude Codeには-p--print)フラグを使った非対話モードがあり、CIやcronから呼び出せます。今回は起動を軽くするため--bareを付け、hooks・skills・MCP・CLAUDE.mdの自動読み込みをスキップし、必要な権限だけを--allowedToolsで明示的に渡す構成にしました(Claude Code公式ドキュメントで案内されている構成です)。

#!/bin/bash
# cron: 毎朝6時に実行
cd /opt/agri-cost-report
claude --bare -p "consumption.csv と inventory_snapshot.csv を突合して
shortage_list.csv を更新し、発注点を下回った資材があれば要約を出力して" \
  --allowedTools "Bash(python3 scripts/*.py *),Read" \
  --output-format json > /var/log/agri-report/$(date +%F).json

出力を--output-format jsonにしておくと、total_cost_usdを含むメタデータが得られるため、月あたりのAPIコストを別途トラッキングする運用にも使えます。

【要注意】よくある失敗パターンと回避策

失敗1:曖昧すぎる指示

❌「資材ログを整理して」
⭕「LINEログから日付・圃場名・資材名・数量・単位を抽出し、単位はkg/Lに統一したCSVを出力して。抽出できなかった行はスキップせず要確認欄に理由を記録して」

なぜこれが重要か:出力スキーマと突合キーを具体的に指定しないと、実行のたびに列名や単位がぶれて、下流の突合スクリプトが毎回壊れます。

失敗2:在庫マスタへの書き込み権限を直接渡す

❌ Claude Codeに在庫マスタCSVへのフルアクセスを与える
permissions.denyとPreToolUseフックで書き込み系コマンドを塞ぎ、read-onlyスナップショットだけを渡す

なぜこれが重要か:経理データは誤更新のリスクが業務影響を伴います。読み取りと書き込みを物理的に分離しておくと、指示の解釈ミスがあっても実害が出ません。

失敗3:発注〜原価計算〜請求まで一度に自動化しようとする

❌「資材管理を全部自動化して」と一括で依頼する
⭕ まず「突合」だけをPoCで検証し、次に「原価按分」、最後に「発注アラート」と段階的に広げる

なぜこれが重要か:大きなタスクを分割すると、各段階で数字の妥当性を人間が確認でき、原価按分ロジックのような合意形成が必要な部分で手戻りが少なくなります。

失敗4:按分結果を鵜呑みにして圃場別損益を確定する

❌ Claude Codeが出したレポートをそのまま経営会議の確定数値として使う
⭕ 一次スクリーニングとして使い、最終確認は経理担当・生産管理責任者が行う

なぜこれが重要か:実装チームが原価按分の結果を確認したところ、想定より人件費相当の按分が特定の圃場に偏っていたケースがあり、按分ロジックの前提(面積按分か使用量按分か)を都度確認する必要があると分かった、という教訓です。AIは補助ツールであり、最終判断者ではありません。

段階的導入のロードマップ

Phase 1(1〜2ヶ月):単一圃場・単一資材カテゴリ(肥料のみ等)でPoC。CSV正規化と突合の精度を検証する。

Phase 2(3〜4ヶ月):全圃場・全資材カテゴリへ横展開。発注点割れのSlack通知アラートを追加する。

Phase 3(5〜8ヶ月):会計ソフト(freee・マネーフォワード等)とのデータ連携を検討し、圃場別原価配賦を月次仕訳の下書きに反映する。

想定効果(試算)

指標 導入前(想定) 導入後(想定)
資材消費ログの月次集計時間 約6時間 約1時間
発注点割れの発見リードタイム 3〜4日 当日中
圃場別原価按分の手作業時間(月次) 約4時間 約30分
転記ミスによる再確認件数(月次) 2〜3件 0件(想定)

※上記はすべて想定シナリオに基づく試算値です。実際の効果は圃場数・資材の種類・既存の記録方法によって変わります。

適用余地のある業界・規模

「ログはあるが集計・突合ができていない」「書き込み権限を絞りつつAIに集計だけ任せたい」という構図は、農業に限りません。建設業の資材発注・製造業の部品在庫・飲食業の食材原価管理など、現場の消費記録と経理の原価管理が分断されている業種であれば、同じ設計思想(read-only突合 + hooks/permissionsによる書き込み制限)が応用できます。圃場・現場の数が10〜50拠点程度の中堅規模が、PoCを始めやすい規模感だと考えられます。

内部リンク:関連事例・参考記事

まとめ:今日から始める3つのアクション

  1. 今日やること:直近1ヶ月分の資材消費ログをCSV1枚にまとめ、本記事の正規化プロンプトを試す
  2. 今週中:在庫マスタのread-onlyスナップショットを用意し、突合スクリプトのPoCを回す
  3. 今月中permissions.denyとPreToolUseフックを設定し、書き込み権限を物理的に分離してから横展開する

正直にお伝えすると、この構成はまだ発展途上です。按分ロジックの前提(面積按分か使用量按分か)は業種・法人ごとに合意形成が必要ですし、最終的な数字の解釈ミスはAI単体では防げません。だからこそ「AIに丸投げ」ではなく、集計と突合だけをAIに任せ、判断は人が行う「AIと協業」の設計が重要だと考えています。

次回予告:次の記事では、資材発注アラートと会計ソフトの仕訳連携を、Claude Codeでどこまで自動化できるかを検証する予定です。

FAQ

Q: Claude Codeは農業法人の資材管理に使えますか?
はい、CSVの正規化・突合・原価按分計算のようなデータ処理タスクであれば、Claude Codeが生成するPythonスクリプトを使って自動化できます。ただし在庫マスタなど経理データへの書き込みは、permissionsとhooksで制限することを推奨します。
Q: 在庫マスタへの書き込み権限はClaude Codeに与えるべきですか?
推奨しません。読み取り専用のスナップショットを渡し、settings.jsonのpermissions.denyとPreToolUseフックで書き込み系コマンドをブロックする二重の安全設計にすることで、指示の解釈ミスがあっても実データへの影響を防げます。
Q: hooksとpermissionsの違いは何ですか?
permissionsはsettings.jsonのallow/ask/denyルールで、コマンドパターンごとに実行可否を宣言的に設定します。hooksはPreToolUseなどのイベントごとにスクリプトやHTTPエンドポイントを実行し、実行時の内容を見て動的に許可・拒否を判断できる仕組みです。両方を組み合わせると二重の安全設計になります。
Q: 本記事の事例は実在するものですか?
本記事の事例・数値・コードはすべて想定シナリオ(モデルケース)です。実在する特定の農業法人の事例ではありません。
Q: 農業法人でなくても同じ設計は応用できますか?
応用できます。現場の消費記録と経理の原価管理が分断されている業種であれば、建設業の資材発注や製造業の部品在庫管理など、同じ設計思想がそのまま流用できます。

参考・出典


著者プロフィール

佐藤傑(さとう・すぐる)。株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X(@SuguruKun_ai)で活用法を発信(フォロワー約10万人)。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆。

Claude Code 個別指導・農業DX導入支援

hooks・permissions設計を含めた安全なClaude Code導入を、Uravationが伴走します。ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。

▶ お問い合わせはこちら

Next Step

この事例を、自社の業務に置き換える。

対象業務、利用データ、評価基準、社内展開の順番まで整理すると、AI開発ツール導入の失敗を減らせます。

導入を相談する