Claude Codeで金型のショット数と保全周期を管理表から洗う

金型の保全は「前回の保全から何ショット打ったか」で決まります。ところが管理表には累積ショット数と前回保全時の値が別々の列で並び、日々のショット実績は別のCSVにあることが多く、目で突き合わせるのは手間がかかります。Claude Codeにはこの突き合わせを、集計スクリプトと検算の組で書かせます。この記事では、基準超過と「14日以内に基準へ届く」金型を一覧にする流れを、実行結果つきで示します。

先に決めておくのは入力の形と判定ルール

Claude Codeに「金型を洗って」と頼んでも、基準が曖昧なままでは出力の正しさを誰も判断できません。依頼の前に、次の3点を文章で固定します。

• 台帳(tools.csv): 金型ID、累積ショット数、前回保全時の累積ショット数、保全周期(ショット)、前回保全日
• 実績(shot_log.csv): 日付、金型ID、その日のショット数
• 判定ルール: 保全後ショット数が周期以上なら「超過」、直近の日平均で14日以内に周期へ届くなら「超過見込み」、周期の8割以上なら「接近」

保全周期は金型ごとに社内で決めた値を台帳に持たせます。この記事の数値はすべて架空のサンプルで、周期の目安として一般論を示すものではありません。

保全後ショット数は「累積ショット数 − 前回保全時の累積ショット数」で出ます。ここを実績ログの合計からも出せるようにしておくと、後で2系統の突き合わせに使えます。

CLAUDE.mdに判定ルールを書いておく

毎回プロンプトで基準を説明するとぶれます。プロジェクトのCLAUDE.mdに、判定ルールと検算の条件を置きます。

## 金型保全チェック
- 入力は tools.csv と shot_log.csv。列名は変えない
- 保全後ショット数 = shots_total - shots_at_last_pm
- 状態は 超過 / 超過見込み(14日以内) / 接近(80%以上) / 余裕 の4つ
- 日平均は shot_log.csv の直近3稼働日の平均
- スクリプトは標準ライブラリだけで書く。出力は状態順に並べる
- 実行後に、件数が台帳と一致していること、保全後ショット数が負でないことを確認する

Claude Codeの公式ガイドは、Claudeが確認できる検査を用意することを勧めています。検査があれば、Claudeが作業し、検査を走らせ、結果を読んで直すところまでを自分で回せるという説明です。金型の管理表でいう検査は、テストスイートではなく「数字が台帳と合っていること」を機械で確かめる行です。

権限の線引き: 読むものと書くもの

管理表には取引先の名前や型番、単価が混じることがあります。Claude Codeには、Readの拒否ルールで特定のパスを読ませない設定があります。

{
  "permissions": {
    "deny": ["Read(./customers/**)", "Read(./pricing/**)"]
  }
}

注意点が1つあります。ReadとEditの拒否ルールが効くのは、組み込みのファイルツールと、catなどClaude Codeが認識するファイルコマンド、リダイレクトの対象です。PythonやNodeのスクリプトが自分でファイルを開く場合は対象外で、OSレベルで止めたいときはサンドボックスを有効にする、と権限の説明にあります。

つまり、生成したスクリプトがcustomers/を読みにいけば、拒否ルールだけでは止まりません。入力CSVは作業用のフォルダに必要な列だけを書き出して置き、スクリプトもその中だけを読む作りにします。サンドボックスの仕組みはClaude Codeのサンドボックスで扱っています。

集計スクリプトを書かせて実行する

プロンプトは、入力・判定・検算を1回で渡します。

tools.csv と shot_log.csv から、CLAUDE.mdの金型保全チェックの
ルールで pm_check.py を書いて。標準ライブラリだけで。
実行して、状態順の一覧を出し、検算が通ったかも報告して。
通らなければ原因を直して再実行すること。

Claude Codeが書いたスクリプトの骨格は次の形になります。以下は説明用に整えた例で、判定の部分が肝です。

import csv, sys
from collections import defaultdict
 
WARN = 0.8          # 周期の80%で「接近」
HORIZON_DAYS = 14   # 14日以内に周期へ届くなら「超過見込み」
 
tools = list(csv.DictReader(open("tools.csv", encoding="utf-8")))
log = defaultdict(list)
for r in csv.DictReader(open("shot_log.csv", encoding="utf-8")):
    log[r["tool_id"]].append((r["date"], int(r["shots"])))
 
rows = []
for t in tools:
    tid = t["tool_id"]
    total, base = int(t["shots_total"]), int(t["shots_at_last_pm"])
    interval = int(t["pm_interval"])
    since = total - base
    assert since >= 0, f"{tid}: 保全後ショット数が負"      # 検算1
    recent = [s for _, s in sorted(log[tid])[-3:]]
    daily = sum(recent) / len(recent)
    remain = interval - since
    days_left = remain / daily if remain > 0 and daily else 0
    ratio = since / interval
    if ratio >= 1:
        status = "超過"
    elif days_left <= HORIZON_DAYS:
        status = "超過見込み"
    elif ratio >= WARN:
        status = "接近"
    else:
        status = "余裕"
    rows.append((tid, t["tool_name"], since, interval, ratio, daily, days_left, status))
 
assert len(rows) == len(tools), "件数が合わない"            # 検算2

実行結果

次の5型の架空データで動かすと、出力は次のとおりでした(Python 3.xの標準ライブラリのみ)。

python3 pm_check.py

D-205 カバーB     保全後 36300/ 30000 (121%) 日平均  1100 残り  0.0日 超過
D-412 ギアD      保全後 55000/ 50000 (110%) 日平均  2500 残り  0.0日 超過
D-101 ケースA上型   保全後 32400/ 40000 (81%) 日平均  2000 残り  3.8日 超過見込み
D-102 ケースA下型   保全後 26900/ 40000 (67%) 日平均  1850 残り  7.1日 超過見込み
D-310 ブラケットC   保全後  1800/ 50000 (4%) 日平均   310 残り155.5日 余裕

標準エラー出力には件数 5 / 台帳 5が出ており、2つの検算を通っています。

読みどころは3行目と4行目です。D-102は周期の67%で、割合だけ見れば「余裕」に近い位置にいます。しかし日平均が1,850ショットあるため、残りの約13,100ショットは7.1日で尽きます。割合だけの管理表では拾えず、日平均を掛けて初めて見える金型です。

「接近」の行が1件もないことにも意味があります。このサンプルでは、80%を超えた金型はすべて14日以内の見込みにも入るので、状態が上位の区分に吸われています。判定の順序を変えると表示が変わるため、順序はCLAUDE.mdに書いたとおりにそろえます。

検算を足して数字を信用できる形にする

一覧が出ただけでは、数字が正しいかは分かりません。ここからが、この手順の中心です。

台帳とログの二重計算

台帳の「保全後ショット数」(累積 − 前回保全時)と、ログの「前回保全日以降の合計」は、本来一致します。ずれる場合は、台帳の更新漏れかログの欠測です。Claude Codeに次の追加を頼みます。

shot_log.csv の last_pm_date 以降の合計と、台帳の
保全後ショット数を金型ごとに突き合わせて、差が1%を超える金型を
別表で出して。差の原因は推測せず、差の大きさだけ書くこと。

「原因は推測せず」と書くのは、ログが直近3日分しかないときなど、差の理由がデータだけでは決まらない場合が多いからです。Claudeが理由を断定して書き添えると、現場が検算の結果を鵜呑みにしやすくなります。

境界値のテストを先に作る

判定の分岐は、周期ちょうど(100%)、80%ちょうど、14日ちょうどの3か所で挙動が変わります。ここを手で数えるのは手間なので、境界値の行だけを持つ小さなCSVを作らせ、判定結果を期待値と比べます。

境界値用の tools_edge.csv を作って。保全後ショット数が周期の
79.9% / 80.0% / 99.9% / 100.0%、日平均で残りちょうど14日と
14.1日になる金型を各1つ。期待する状態を一覧にして、
pm_check.py の出力と食い違う行がないか確認して。

公式ガイドの言い方でいえば、これがClaude自身が読める「パスか失敗か」の信号になります。期待値を先に人が決めておけば、Claudeが判定式を直したときも、基準の取り違えに気づけます。

終了条件を機械にする

検算が通るまで止まらないようにしたいときは、公式ガイドが挙げる方法が使えます。プロンプトの中で「検算が通るまで繰り返す」と頼む方法、/goalで条件を置く方法、Stopフックで検査スクリプトを走らせて通るまでターンの終了を止める方法です。夜間に回して朝に結果だけ見たい場合は、後者はスクリプトが機械的に止めるため、判断が人やモデルの気分に左右されません。

code executionツールでAPIから同じ作業を行う場合

Claude Codeではなく、自社の業務システムからAPIで呼ぶ形にするなら、code executionツールが同じ位置に入ります。CSVをFiles APIにアップロードし、container_uploadのブロックで参照し、ツールを有効にしてリクエストします。

押さえておく仕様は次のとおりです。

• コンテナはインターネットに接続できず、実行時にパッケージを入れられません。使えるのは導入済みのライブラリで、pandasやnumpyなどが含まれます
• コンテナのメモリは5GiB、ディスクは5GiB、CPUは1つです
• コンテナの作成から30日で期限が切れ、実行中のデータも最大30日保持されます
• 課金は実行時間ベースで、1か月あたり組織ごとに1,550時間までは無料、超えた分は1コンテナ・1時間あたり0.05ドルです。Web検索やWeb Fetch(web_search_20260209やweb_fetch_20260209以降)と併用した場合は、コード実行の追加料金がかかりません
• ファイルを添えたリクエストでは、ツールが呼ばれなくても、ファイルがコンテナに先読みされるため実行時間が課金対象になります

ZDR(ゼロデータ保持)の対象外である点も、金型の図面や取引先情報が混じる管理表では確認しておきたい条件です。その場合は、図番・取引先・単価の列を落としたCSVだけを渡します。Files APIとcode executionでCSVを集計したときの精度の比較は、Files APIとcode executionでCSVを集計するに実測があります。

この記事のスクリプトは標準ライブラリだけなので、そのままAPI側のコンテナでも動く作りです。違いは、実行結果をClaudeが読んで直す回数の制御を、自分のコードで持つかClaude Codeに任せるかにあります。

つまずきやすい点

累積カウンタの巻き戻し

金型の交換や、カウンタのリセット、管理表の転記ミスで、累積ショット数が前回の値より小さくなることがあります。検算1のassertが落ちるのはこのときです。ここでは値を補正して先へ進まず、該当の金型を人に返します。Claudeに「負なら0にして続行」と書かせると、超過している金型を余裕に分類しかねません。

日平均の窓が短い

サンプルは直近3稼働日の平均を使いました。段取り替えや休止の前後で日平均が大きく動く現場では、窓を広げる、または稼働日だけで数える設計に直します。窓を変えるときは、CLAUDE.mdの記述とスクリプトの両方を同時に直します。片方だけだと、次のセッションで元に戻されます。

超過した行の残日数が0になる

すでに超過した金型は残りショットが負になるため、サンプルでは残日数を0と表示しています。これは「0日で保全」ではなく「すでに超えている」の意味です。一覧を現場に回すときは、状態列を先頭に出して読み違いを避けます。

保全周期が型ごとに違う

同じ型番の上下型でも、周期が異なる運用があります。周期を台帳の列として持たせておけば、スクリプトを触らずに管理表を直すだけで済みます。スクリプトの中に周期を埋め込まないよう、CLAUDE.mdに一行置いておくのが安全です。

次の保全計画につなげる

超過と超過見込みの一覧は、保全の順番を決める入口に過ぎません。実際の段取りは、生産計画や保全担当の空き、金型の予備の有無が決めます。設備全般の優先度を週次で見直す流れはCoworkで設備保全の優先度を週次で見直す手順に、保守マニュアルを問い合わせ窓口にする方法はClaudeで設備の取扱説明書・保守マニュアルを保全の問い合わせ窓口にする手順にあります。

CSVの結合と行数チェックを含む一般的なデータ処理の組み方は、Claude Codeでpandasのデータ処理を書く実践手順にまとまっています。突き合わせの検算という点では、銀行入金の消込も同じ型です。

まとめ

金型の保全判定は、割合と日平均の掛け算に尽きます。ただし、数字が合っているかを人が毎回追うのは続きません。判定ルールをCLAUDE.mdに固定し、件数照合と符号チェック、境界値の期待値という3つの検算をスクリプトの側に持たせると、Claude Codeの出力は読むだけで済む形になります。

最初の一手は、既存の管理表から金型ID・累積ショット数・前回保全時の値・周期の4列だけを書き出し、全件の状態を出させることです。そこで出た「超過見込み」の行を、現場の感覚と1件ずつ照らし合わせると、判定ルールの調整点が見えてきます。