「うちの経理、月次の数字をまとめるだけで3日かかってるんです」。先月、ある中堅製造業のCFO補佐の方からこう聞いた時、思わずメモを取った。彼の手元には Excel が 7 ファイル、メールに添付された PDF が 12 通、それと社内 SharePoint のリンクが 4 本。月次決算のたびに同じ抽出を、同じ手順で、別の人が、別のフォーマットで繰り返している。
その帰りの電車で Impress Watch の記事を見た。Anthropic が 2026-05-05、金融機関向けに Claude のエージェントテンプレートを 10 種類公開したという話だ(出典: Impress Watch)。ピッチ作成、バリュエーション・レビュー、月次決算 — まさにあの CFO 補佐の方が手作業でやっていたやつだ。
金融向けの話ではあるが、構造そのものは中小企業の PoC にそのまま転用できる。今回はその転用を進める中で組んだ「Agent Skill 構成」と、ドキュメントには書かれていないハマりどころを残しておく。次に同じ問題に当たる人が 30 分でも早く帰れるように。
そもそも「テンプレートとして配布する」とはどういうことか
Anthropic が出したのはエージェント本体ではなく、エージェントの型だ。タスクの目的、参照すべきデータ、出力フォーマット、評価軸 — これらをひと塊にして、現場の担当者が自分のデータを差し込めば動くようにする。社内に AI に詳しい人がいなくても、テンプレートを選んで運用に乗せられる。これが鍵だ。
筆者は最初、これを「プロンプトテンプレート」だと早合点していた。実際にやってみると違った。プロンプトはあくまで一部で、本質はもっと地味な部分にある。具体的には次の 4 点だ。
業務定義(何を、どの粒度で、どこまでやるか)
参照リソース(どのファイル・DB・API を見るか、見ないか)
出力契約(列名・単位・並び順まで含めた厳格な型)
失敗時の振る舞い(分からない時に黙るか、聞き返すか)
この 4 点を Agent Skill という単位で梱包する。Claude Agent SDK でいうところの skill 定義に近い概念で、1 つの skill = 1 つの業務テンプレートとして扱う。
PoC で組んだ構成
製造業の月次決算補助という限定スコープで、3 週間の PoC を回した。社員 80 名規模、経理 2 名、決算は月初 5 営業日で締めるのが目標だが、実態は 7〜8 日かかっている。
構成図は頭の中ではこんな感じだ。
┌─────────────────────────────────────────┐
│ 社内ファイル(Excel/PDF/SharePoint) │
└──────────────┬──────────────────────────┘
│
┌──────▼──────┐
│ Skill Loader │ ← .skill.yaml を読む
└──────┬──────┘
│
┌──────▼──────┐
│ Claude Agent │ ← claude-sonnet-4-6
└──────┬──────┘
│
┌──────▼──────┐
│ Output 検証 │ ← Pydantic で型チェック
└─────────────┘
ポイントは Skill Loader を Claude Agent から分離したことだ。最初は 1 ファイルにまとめていたが、テンプレートを 3 つ目に増やした時点で破綻した。経理担当者が自分でテンプレートを書き換えたいというニーズがあって、コードと業務定義は分けたほうが運用が楽だったからだ。
Skill 定義の最小例
「月次仕訳サマリ生成」という skill の定義を、PoC で実際に使った形に近づけて書く。社内固有の項目はダミー化してある。
name: monthly_journal_summary
description: |
月次の仕訳データから、勘定科目別の集計と前月比をまとめる。
異常値(前月比 ±30% 超)はフラグを立てる。判断は人間に残す。
inputs:
name: journal_csv
type: file
format: csv
required: true
schema:
date: string (YYYY-MM-DD)
account: string
debit: number
credit: number
outputs:
format: json
schema:
summary:
- account: string
current_month: number
previous_month: number
variance_pct: number
flag: enum [normal, high_variance, missing_prev]
notes: string
guardrails:
数値は四捨五入せず、入力の有効桁数を保持する
前月データが欠損している勘定科目は flag=missing_prev で出力
推測で穴埋めはしない
出力以外の説明文は notes に 200 字以内でまとめる
guardrails の 3 番目「推測で穴埋めはしない」が地味に効く。Claude は良くも悪くも「埋めようとする」傾向があって、特に数値が欠損していると平均値で補完しようとすることがある。経理データでこれをやると即座に信頼を失うので、明示的に禁じる。
Python 側の最小実装
Skill Loader と Agent 呼び出しの骨格はこのくらい単純で済む。エラー処理は最小限にしてあるが、PoC ではこれで動いた。
import yaml
from pathlib import Path
from anthropic import Anthropic
from pydantic import BaseModel, ValidationError
client = Anthropic(api_key="YOUR_API_KEY")
class SkillRunner:
def init(self, skill_path: Path):
self.skill = yaml.safe_load(skill_path.read_text(encoding="utf-8"))
def build_system_prompt(self) -> str:
s = self.skill
guards = "\n".join(f"- {g}" for g in s["guardrails"])
return (
f"あなたは業務テンプレート '{s['name']}' を実行するエージェントだ。\n"
f"目的: {s['description']}\n"
f"出力は次のJSONスキーマに厳密に従うこと:\n{s['outputs']['schema']}\n"
f"守るべきルール:\n{guards}"
)
def run(self, user_payload: str) -> dict:
msg = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=4096,
system=self.build_system_prompt(),
messages=[{"role": "user", "content": user_payload}],
)
return self._parse(msg.content[0].text)
def _parse(self, raw: str) -> dict:
import json
start = raw.find("{")
end = raw.rfind("}") + 1
return json.loads(raw[start:end])
runner = SkillRunner(Path("skills/monthly_journal_summary.skill.yaml"))
result = runner.run(open("data/2026-04-journal.csv").read())
print(result)
ハマりどころ 1: JSON が壊れる
最初の数日、出力 JSON が 30% くらいの確率で壊れた。原因は、説明文をついでに添えてくる癖だ。{...} の前後に「以下が結果です」みたいな前置きが付いてくる。_parse で { と } の位置を切り出しているのはこのためだ。
本来なら Claude の tool use 機能で構造化出力を強制するのが正攻法だが、PoC の段階では実装の軽さを優先して文字列パースで逃げた。本番化する時はここを書き換える。
ハマりどころ 2: CSV のサイズと粒度
仕訳 CSV を丸ごと投げたら、月次で 1 万行を超えて、トークンが 4 万を超えた。動くには動くがコストが見合わない。これは PoC 2 週目に気づいた。対策として、Python 側で勘定科目ごとに事前集計してから渡すようにした。Claude にやらせるのは「集計後の数値の解釈と異常検知」だけで、純粋な集計演算は pandas で済ませる。
30% という数字は、最初は小さく見えた。でも 100 件の skill 実行のうち 30 件が失敗するということは、月次運用で経理担当者が手戻りを起こす回数が 30 回ということだ。これだと現場では使い物にならない。
ハマりどころ 3: 業務テンプレートの粒度
当初は「月次決算を全部やるエージェント」を作ろうとしていた。これが一番の失敗だった。スコープが大きすぎて、Skill 定義の guardrails が膨れ上がり、結果として全ての項目が中途半端になる。
2 週目から方針を変えて、1 つの Skill = 1 つの抽出か集計、というレベルまで分割した。最終的に PoC で残ったのは 5 つだ。
仕訳サマリ生成(上記)
勘定科目マスタとの突合
前月比異常値の自然言語コメント生成
会議向けハイライト 3 行要約
監査向けの根拠リンク列の付与
厳密にはこれら以外にもサブ skill があったが、運用に耐えたのはこの 5 つだった。Anthropic が金融向けに 10 種類のテンプレートを公開したという数字も、たぶん偶然ではない。1 業務 1 テンプレートで分けていくと、それくらいの数になる。
動作確認のログ
実行時のログを 1 サンプルだけ残しておく(数値はダミー)。
$ python run_skill.py monthly_journal_summary data/2026-04-journal.csv
[skill] loaded: monthly_journal_summary
[input] rows=8421, accounts=47
[pre-agg] reduced to 47 rows for agent
[agent] claude-sonnet-4-6 / tokens in=2104 out=1387
[parse] OK
[output]
{
"summary": [
{"account": "売上高", "current_month": 84210000, "previous_month": 79180000, "variance_pct": 6.4, "flag": "normal"},
{"account": "接待交際費", "current_month": 1240000, "previous_month": 320000, "variance_pct": 287.5, "flag": "high_variance"},
...
],
"notes": "接待交際費が前月比+287%。展示会出展月のため一過性の可能性が高いが、経理での確認推奨。"
}
「+287%」のような跳ね方を、ただ数字として出すか、人間に向けて 1 行コメントを添えるかで、現場の受け取り方は大きく変わる。経理担当者の方が言っていた。「数字は自分で見れば分かる。でも『何を疑え』と言ってくれる人が、社内には少ないんだ」。これが正直、一番刺さった。
応用の方向
製造業の品質月報(検査記録 → 異常傾向の言語化)
物流の遅延レポート(配送ログ → 原因分類)
小売の販促振り返り(POS データ → 商品ごとの仮説)
サービス業のクレーム要約(問い合わせ履歴 → 月次傾向)
共通するのは、データはすでに社内にあり、解釈が属人化していて、月次の作業として誰かが消耗している、という構図だ。Anthropic が金融向けで先に体系化したというだけで、業界依存性はそれほど高くない。
まとめ
業務テンプレートとして配布する、というのは、技術的には skill 定義を 1 ファイルに梱包しておくだけのことだ。難しいのはむしろ、業務の輪郭を「1 つの skill に収まるサイズ」まで切り出す側の作業で、ここはコードを書く時間より対話の時間のほうが長い。次は Claude Agent SDK の正式な skill 機能(tool use ベース)に書き換えて、JSON 破綻問題を構造化出力で潰すところまでやってみたい。
筆者は 5years+ で韓国・日本の中堅企業向けに Claude/LLM の業務応用を担当している。同じテーマで詰まっている方の参考になれば。