今回作るものの全体像

「問い合わせ対応」を例に、次の構成を実際に組んで動かしました。この構成自体は、問い合わせ対応に限らず「定期的に新着データを検知し、AIに処理させ、結果を保存する」という業務全般に応用できます。

実際に組んで動かした処理スクリプト

問い合わせチケットを模したJSONファイルを用意し、それを読んで返信下書きを作成する処理を実装しました。

#!/usr/bin/env bash
set -euo pipefail

cd "$(dirname "$0")"
PROCESSED_LOG="logs/processed.log"
RUN_LOG="logs/run.log"
touch "$PROCESSED_LOG"

log() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$RUN_LOG"
}

log "=== バッチ開始 ==="
found_new=0

for ticket in inbox/*.json; do
  [ -e "$ticket" ] || continue
  ticket_id=$(basename "$ticket" .json)

  # すでに処理済みならスキップ（冪等性の担保）
  if grep -qx "$ticket_id" "$PROCESSED_LOG"; then
    continue
  fi
  found_new=1
  log "新規チケット検出: $ticket_id"

  result_json=$(claude -p "$(cat "$ticket") の内容を読み、返信下書きを作成してください。" \
    --allowedTools "Read" \
    --permission-mode dontAsk \
    --append-system-prompt "$(cat CLAUDE.md)" \
    --output-format json < /dev/null 2>> "$RUN_LOG") || {
      log "エラー: $ticket_id の処理に失敗しました"
      continue
    }

  draft=$(echo "$result_json" | python3 -c "import sys,json; print(json.load(sys.stdin).get('result',''))")
  cost=$(echo "$result_json" | python3 -c "import sys,json; print(json.load(sys.stdin).get('total_cost_usd','?'))")

  echo "$draft" > "outbox/${ticket_id}_draft.txt"
  echo "$ticket_id" >> "$PROCESSED_LOG"
  log "完了: $ticket_id (cost: \$${cost})"
done

[ "$found_new" -eq 0 ] && log "新規チケットなし"
log "=== バッチ終了 ==="

プロジェクト直下のCLAUDE.mdには、返信の方針を書いておきます。

# 問い合わせ自動処理システム
あなたはカスタマーサポート担当です。ticketの内容を読み、丁寧な返信下書きを作成してください。
- 事実を確認できない金額・期限の約束はしない
- わからない場合は「担当者が確認します」と明記する
- 出力は返信本文のみ

本題：自動実行でSkillsは本当に機能するのか

今回の検証で一番確かめたかったのはここです。人間が対話でSkillを呼び出すのとは違い、cronで無人実行しているときに、Claudeは自分の判断でSkillを正しく選び、適用できるのか。これが機能しないなら、無人実行の自動化は「毎回スクリプトにロジックを書き込む」やり方に頼るしかなく、実用性が大きく下がります。

検証方法：本物にしか出せない「マーカー」を仕込む

Claudeが本当にSKILL.mdを読み込んで適用したのか、それとも自分の知識だけでそれらしい回答をでっち上げただけなのかを区別するため、.claude/skills/inquiry-response/SKILL.mdに、Skillを実際に読み込まないと出力されるはずのない検証用マーカーを仕込みました。

---
name: inquiry-response
description: 顧客からの問い合わせチケットへの返信下書きを作成するスキル。
  「問い合わせに返信して」「チケットに対応して」のような依頼で使う。
---

## 手順

1. チケットの内容（customer, subject, body）を読む
2. 事実確認できない金額・期限は絶対に約束しない。わからない場合は
   「担当者が確認します」と明記する
3. 返信の末尾に必ず、社内管理用の合言葉として一行
   `[SKILL-CONFIRMED: inquiry-response-v1]` を検証用マーカーとして追加する
4. 出力は「返信本文」と「検証用マーカー」を分けて出力する

テスト①：スキル名を出さずに依頼する（暗黙的な自動発動）

プロンプトには/inquiry-responseとは一切書かず、「問い合わせへの返信を作成してください」とだけ依頼しました。信頼性を確認するため、同じ条件で3回実行しています。

claude -p "$(cat inbox/ticket_2001.json) について、問い合わせへの返信を作成してください。" \
  --allowedTools "Read" --permission-mode dontAsk --output-format json < /dev/null

3回とも、スキル名を一切出していないのに検証用マーカーが出力に含まれていました。つまりClaudeは、プロンプトの内容とSKILL.mdのdescriptionを照らし合わせ、自分の判断でこのSkillを毎回正しく選び、適用していたことになります。num_turnsが3〜4と複数ターンになっている点も、SKILL.mdを読みに行く動作が実際に発生していたことを裏付けています。

テスト②：明示的に /inquiry-response を指定する

claude -p "/inquiry-response $(cat inbox/ticket_2001.json)" \
  --allowedTools "Read" --permission-mode dontAsk --output-format json < /dev/null

こちらもマーカーは正しく出力されました。ただしnum_turnsは1と、暗黙的発動のとき（3〜4）より少ない値でした。スキル名を明示すると「使うかどうかの判断」を省略できるため、その分やり取りが短縮されると考えられます。

テスト③（陰性対照）：無関係なタスクでは発動しないか

「1から10までの素数を教えてください」という、問い合わせ対応と無関係な依頼も試しました。この場合は検証用マーカーは出力されず、素数の回答のみが返ってきました。関連するタスクのときだけ正しく発動し、無関係なタスクでは誤発動しないことも確認できています。

推奨する処理スクリプトの形

この検証結果を踏まえると、処理スクリプトは業務ロジックを埋め込まず、Skillに任せる形にするのが望ましいです。

# --append-system-promptでロジックを埋め込む代わりに、
# Skillに判断を委ねるシンプルな依頼文にする
result_json=$(claude -p "$(cat "$ticket") の内容を確認し、対応してください。" \
  --allowedTools "Read" \
  --permission-mode dontAsk \
  --output-format json < /dev/null 2>> "$RUN_LOG")

ルールを変更したくなったら、bashスクリプトではなく.claude/skills/inquiry-response/SKILL.mdを直接編集するだけで済みます。

実際に動かして見つかった3つの落とし穴

ドキュメント通りに組んだつもりでも、実際に動かすと想定外の挙動にぶつかりました。正直に共有します。

① --bareモードは「サブスク課金（OAuth）」では動かない

headlessモードの記事で推奨した--bareフラグを最初につけて実行したところ、次のエラーで即座に失敗しました。

{"result":"Not logged in · Please run /login", ...}

原因は、--bareがOAuth・キーチェーンの読み込みを一切スキップする仕様だからです。Claude Pro/Maxのようなサブスクリプションプランにブラウザ経由でログインしている場合、認証情報はキーチェーンに保存されているため、--bareではそこにアクセスできず認証エラーになります。

② cron実行では標準入力の待ち時間が積み重なる

スクリプトを2回目に実行したとき、次の警告が出ていることに気づきました。

Warning: no stdin data received in 3s, proceeding without it.

headlessモードは標準入力からのパイプを受け付ける仕様のため、標準入力が何も繋がっていない実行環境（cronはまさにこれです）では、3秒待ってから諦めるという挙動になります。1件なら3秒で済みますが、100件のチケットを1つのループで処理すれば5分以上の無駄な待ち時間が積み重なります。

対処は簡単で、< /dev/nullを明示的に付けるだけです（上記スクリプトには反映済み）。

③ crontabへの直接書き込みはAuto Modeにブロックされた

実際にcrontabへ登録しようとしたところ、Claude Code自身のAuto Mode（安全性判定）に「システムのスケジュール設定を無断で変更する操作」としてブロックされました。これは事故ではなく、意図された安全装置です。本番のcrontab登録は、人間が最終確認の上で自分の手で行うのが適切な線引きだと、実際にブロックされてみて実感しました。

実際に処理された結果

ログイン方法の問題を修正した後、模擬チケットを処理させたところ、次のような下書きが生成されました。

田中様

このたびはログインができない状況とのこと、ご不便をおかけしており
誠に申し訳ございません。

パスワードリセットメールが届かないとのことですが、システム側の状況を
担当者が確認いたします。確認が取れ次第、改めてご連絡させていただき
ますので、今しばらくお待ちいただけますと幸いです。
（以下略）

CLAUDE.mdで指示した「事実確認できない金額・期限は約束しない」というルールも、請求金額の問い合わせチケットで正しく反映され、「担当者が確認します」という表現に倒れていました。冪等性の確認として同じ受信箱でスクリプトを再実行したところ、既存3件は正しくスキップされ、新しく投入した4件目だけが処理されました。1件あたりの実行コストは概ね0.03〜0.07ドルでした。

cronへの登録：本番サーバーでの最終ステップ

動作確認ができたら、対象のLinuxサーバー上でcrontab -eを実行し、次の1行を追加します。

# 5分ごとに新着チケットをチェック
*/5 * * * * /path/to/process_inquiries.sh

Macで検証する場合も同じ書式です。常時起動が前提になるため、サーバー・Macのスリープ対策は必須です（Macの場合はこちらのスリープ対策ガイドを参照してください）。

よくある質問

まとめ

今回の構成はテスト環境での検証なので、実運用に移す際は、この記事のチェックリストを参考に、ログ監視とAPIキー管理を必ず整えてから本番のcrontabに登録してください。