同じ調べ物なのに、担当者によって1時間で終わる人と半日かかる人がいる。ZOZOTOWNのカスタマーサポート問い合わせ調査をClaude Code Skillで自動化した事例は、判定ロジックをサブスキルに分離し、マニュアルそのものを実行可能な形にするという設計を教えてくれる。
複数ツールを横断する調べ物を「親スキル＋判定用サブスキル」に分解する設計と、「リードタイム70%削減」という数字の読み方（アンケートベースという注記まで含めて）、個人開発の運用にも移植できる小さな応用案。
ZOZOTOWNのカスタマーサポートに届く問い合わせの調査は、会員データや注文データ、アプリケーションログ、過去の問い合わせ会話、関連コードといった複数の情報源を横断して確認する作業で、1件あたり1〜2時間以上かかっていたという（ZOZO TECH BLOG）。
厄介なのは時間そのものより、情報源ごとにツールが違い、検索の勘所にメンバー間で差が出ることだった。加えてシステムのリプレイス途中で新旧環境が混在しており、「どちらの環境の話をしているか」を見極めるだけで一手間かかる。新人や初担当者には専任サポーターの伴走が必須という、典型的な属人化案件だった。
親スキル「inquiry」は7ステップで構成され、判定が難しい2箇所だけをサブスキルとして独立させている。
Slack MCPで問い合わせ内容を拾った直後、蓄積した過去事例を参照し、Slackの過去ログも検索した上で「自チーム対応かどうか」を判定する。担当外なら早い段階で他部門へルーティングし、無駄な深掘りを止める。
screen-url-map.mdで問い合わせ対象の画面URLを特定し、Akamaiのルーティング設定と照合して新環境か旧環境かを二段階で判定してから、対象リポジトリを決める。「どちらの環境か」という一番間違えやすい判断を、独立した1ステップに固定している。
担当と環境が決まった後は、Splunk MCPでのログ段階検索、code-investigatorエージェントによるコードベース調査へと進み、最後に統合レポートと「スキル改善メモ」を出力する。判定・探索・統合を1つのプロンプトに詰め込まず、役割ごとに分けている。
ここが核心。難しいのは調査作業そのものより、「どこから調べ始めるか」の判定だった。だから判定部分だけを独立したサブスキルに切り出し、迷いやすい1箇所ずつを固定化している。
このSkillの位置づけは「人間が読むためのマニュアルであり、かつそのままClaudeが実行する手順書でもある形」だという。従来は先輩の頭の中にしかなかった「調べ方」を、Skillとしてリポジトリで管理する形に変えた。一度書けば人間とAIの両方に効く資産になるため、整備そのものへの動機が生まれる、という順番になっている。
judgment-knowledge.mdやscreen-url-map.mdといった知識ファイルは、使うほど内容が増え、次回以降の判定精度が積み上がっていく設計だ。以前この場で書いた「別のAIに仕事を渡すプロンプトの書き方」でも触れたが、会話を読まなくても実行できる自己完結した指示にするほど委任は軽くなる。この事例はその発想を、1回限りの依頼文ではなく「繰り返し使われる資産」にまで伸ばしたものと言える。
ただし数字には注記が要る。「Claude Code Actionsの起動から一次回答の出力までおよそ10分」で完結し、リードタイムを平均70%削減——ここまでは強い結果だが、この70%はアンケートベースの数値であり、稼働ログの厳密な実測ではないと明記されている。
以前「AIの『できました』を信じない｜3段階で検品する運用」で書いた検品文化と同じ話だ。10分で一次回答が出ることと、その回答をそのまま信じていいことは、別の話として扱われている。
個人開発では複数リポジトリ・複数MCPを横断するほどの規模はなくても、応用できる部分は具体的にある。