領域固有の業務ワークフローに向けたAIエージェントスキルの構築

汎用のAIコーディングエージェントは、驚くほど幅広いタスクを的確にこなします。十分なコンテキストがあれば、ドキュメントを読み、コードを書き、不具合を調べ、未知の問題についても推論できます。しかし、実際の業務に導入するチームの多くが同じ課題に直面します。そのコンテキストを提供すること自体が作業であり、対象領域が複雑になるほど負担も増えるのです。

形式の異なる発注書が混在するフォルダーから、サプライヤーのリードタイムを抽出したいデータアナリストは、発注書とは何か、自社の命名規則はどうなっているか、後続システムがどの出力形式を求めるかを、毎回説明したくはありません。インフラの監視を担当する開発者も、同じアラートのしきい値や重大度の定義を会話のたびに貼り付けたくはありません。問題は、この繰り返しです。

スキルは、領域固有の知識と動作指示を、呼び出せる一つの単位にまとめた再利用可能な設定です。この問題に直接応える仕組みとして、本記事ではスキルの構築方法、定期的なワークフローへの導入方法、そして確実に価値を発揮する場面を説明します。

スキルの実体

スキルはモデルの機能でも、APIの機能でもありません。ファイルです。具体的には、エージェントがセッション開始時に走査するディレクトリに置かれたMarkdownファイルです（たとえばClaude Codeでは、~/.claude/skills/またはプロジェクトの.claude/skills/配下のフォルダー内にあるSKILL.mdファイルです。他のエージェント実行環境では、それぞれ独自の保存場所を使います）。スキルの説明に一致する依頼を受けると、エージェントはタスクへの取り組み方を一から考える代わりに、スキルの指示を読み込んで従います。

ファイルには四つの要素があります。スキルを有効にするタイミングを伝える説明ブロック、対象のタスク群の処理方法を定める指示、実行環境に応じて、実行中にエージェントが使えるツールを事前承認したり制限したりする任意のツールアクセス宣言（Claude Codeのallowed-toolsは、他のツールを制限せずに、指定したツールを事前承認します）、そして実際に近い入力に対する正しい動作を示す任意の例です。

このファイルに業務データを固定値として埋め込むことはしません。スキルに記述するのは、領域の用語、推論の進め方、出力形式といった、ある種類のタスクへの取り組み方であり、個々のタスクそのものではありません。取り組み方を記述することとデータを記述することの違いが、長く使えるスキルを設計する際の中心的な論点です。

領域固有の知識を記述すべき場合と、すべきでない場合

スキルの導入が失敗する原因の多くは、情報を盛り込みすぎることです。仕組みに期待したチームが、特定のベンダー名、現在の料金プラン、顧客が好むレポート形式、現在使用しているAPIエンドポイントまでスキルに記述します。6か月後には、その情報の半分が誤りになり、スキルが実態からずれ、どこを信頼できるのか誰にも分からなくなります。

実務上の原則は、変化が緩やかなものを記述し、頻繁に変わるものはエージェントに任せることです。

領域の用語は緩やかに変化します。輸入書類を処理するスキルなら、原産地証明書とは何か、関税評価における国内販売価格に基づく課税価格の決定方法とは何か、対象市場の規制の枠組みはどうなっているかを理解している必要があります。この種の知識は、業務の細部よりはるかに緩やかに変化します。ただし、規制の枠組みは改正されるため、定期的な見直しは必要です。スキルに記述すべき情報です。

具体的な提出書式、取引先名、現在の規制上のしきい値、正確な期限は常に変わります。こうした情報はスキルの定義ではなく、実行時にエージェントへ渡すデータに含めます。スキルは、ある種類の文書の読み方を教えます。実際の文書はコンテキストとして渡します。

判断の目安は、業務環境が変わるたびにスキルを更新する必要があるなら、記述する情報の選び方が誤っているということです。適切に設計したスキルは組織の変化にも対応できます。設計が悪ければ、すぐに古くなります。

SKILL.mdの構造

標準的なスキルファイルの構造はシンプルです。フロントマターでスキルを識別し、有効にする条件を定め、本文で使い方を定義します。

---
name: import-document-processor
description: Use when processing import declarations, ACP applications,
  or customs documentation for Singapore, Japan, or EU markets
---

## Context
Background on the domain: what this class of documents is, why it
exists, what the agent needs to know to interpret one intelligently.

## Approach
Step-by-step instructions for handling the task: what to look for,
how to handle ambiguous cases, what to escalate to human review.

## Output Format
Exactly what the output should contain, in what structure.

## Edge Cases
Known failure modes and how to handle them.

運用上、最も重要なのは説明ブロックです。そもそもエージェントがスキルを有効にするかどうかを決めるためです。「文書に使用する」のような曖昧な説明では、有効化の動作が安定しません。文書の種類、業務上の状況、対象市場を明示した正確な説明なら、安定した動作につながります。

ただし、説明を細かく限定しすぎてもいけません。狭すぎると、本来適用すべき依頼を見逃します。目指すのは、実務に詳しい人が自分の状況に合うと判断できる、過不足のない説明です。実際の運用で調整する必要があり、初期導入時には境界となるケースを試して、有効化の範囲が想定どおりか確認するとよいでしょう。

定期タスクの/loopパターン

業務ワークフローの中には、決まったスケジュールで実行するものがあります。APIエンドポイントからの日次抽出、サプライヤーのレポートの週次集計、顧客向けサマリーの月次作成などです。これらは単発のやり取りではなく、誰かが手動で開始するかどうかにかかわらず継続する業務プロセスです。

Claude Codeでは、/loopコマンドが、スキルを使ったやり取りを定期的な処理に変えます。

/loop 24h /process-supplier-reports

指定した間隔で対象のスキルを現在のセッション内で再実行し、呼び出しのたびにそのセッションがコンテキストを提供します。スキルが作業を担当し、ループがスケジュールを担当します。2026年10月時点のClaude Codeのドキュメントでは、/loopはセッション内でのみ有効とされています。タスクはセッションの実行中にのみ起動し、定期タスクは7日後に期限切れになります。そのため、本番環境で長期間運用するスケジュールには、同じスキルを呼び出すcronジョブ、CIパイプライン、またはクラウドのスケジュールタスクを使う必要があります。

定期実行するスキルには、対話型のスキルとは異なる設計上の配慮が必要です。まず、冪等性が必要です。同じ入力に対して同じスキルを2回実行しても、レコードや通知が重複したり、後続システムの状態が壊れたりしてはいけません。エラー時の動作も明示します。入力の形式が不正な場合、APIが利用できない場合、期待するデータがない場合にどうするかを、明確に定義する必要があります。後続システムが出力を利用するなら、人が読めるだけでなく、機械で処理できる形式にします。

ループで安定して動作するスキルは、ほぼ例外なく、対話型のスキルより対象範囲が狭くなります。対話型なら、5種類の文書を扱い、未知の形式でも可能な範囲で処理できるかもしれません。定期実行版は一つの文書形式を正確に処理し、想定外の入力には明示的なエラーを返します。運用の信頼性を重視するなら、柔軟性より対象を明確にすることが優先されます。

実務的な目安として、エラー時も含めたスキルの想定動作すべてを10分未満で説明できなければ、安定した定期実行には対象範囲が広すぎる可能性があります。

本番環境での実例

当社が実際の業務環境で使用した三つのパターンを紹介します。

サプライヤーからの連絡に含まれるデータの抽出。サプライヤーから届く注文確認、出荷通知、請求書の更新は、形式が統一されていません。構造化されている場合もありますが、そうでないことが多いのが実情です。各サプライヤーの連絡形式に合わせたスキルが、非構造化テキストから構造化データを抽出します。あるサプライヤーは確認メールの第2段落に発注書の参照番号を記載すること、日付形式がDD.MM.YYYYであること、商品コードが特定のパターンに従うことを、スキルに定義します。週ごとに変わるのはメールの内容であり、解析方法は変わりません。抽出結果は在庫システムに直接送られ、メッセージの受信からデータ入力までの間に手作業を挟む必要がありません。

業務データからのレポート作成。週次の業務サマリーを作るには、重要な指標、有意な変化と判断するしきい値、期間をまたいで意味のある比較、対象読者に合わせた結果の伝え方を理解する必要があります。これらは週ごとには変わりません。スキルに一度記述すれば、エージェントは実行時に最新データを受け取り、定義済みの分析枠組みを適用します。出力形式、文体、必ず含めるセクションも、毎回指定し直すのではなく、すべてスキルで定義します。その結果、多数の処理を手動のプロンプトで行う場合には得にくい一貫性が生まれます。

システム監視とアラート。インフラは継続的にログを生成します。監視スキルでは、注目すべきイベントとなるパターン、重大度の分類方法、アラートを受けた人が適切に対応するために必要な情報を定義します。ループパターンと組み合わせて短い間隔で実行すれば、定義した条件を確認し、条件を満たしたときに構造化されたアラートを生成できます。

ここで重要なのは、誤検知の管理です。あらゆる異常にアラートを出すスキルは、担当者がアラートを無視する習慣を作ってしまいます。必要なのは調整、つまり人が注意を向ける価値のある条件を正確に定めることです。これは技術の問題ではなく、領域の知識の問題です。適切に定めるには、現在手動で問題に対応している人から詳しく情報を得る必要があります。その人たちは、意味のある兆候と雑音の境界をすでに身につけているからです。スキルはその知識を明文化します。

スキルでは解決できないこと

スキルは、特定の領域で的確に作業するための知識と手順を記述します。汎用的な能力そのものを生み出すわけではありません。

適切に設定されたスキルは、既知のパターンを安定して処理します。一方、まったく新しい状況にはうまく対応できません。慣れた状況で動作を安定させる指示が、未知の状況では制約となるためです。したがって、スキルが最も有効なのは、特定市場の輸入書類、定義済みの指標に基づくレポート作成、既知のアラートパターンに照らしたログ分析など、タスクの範囲がある程度限定されている場合です。「業務を支援する」では範囲が限定されていません。何をもって的確な作業とするかを誰も定義していない領域で、スキルによってエージェントを有能にすることはできません。

もう一つの制約は保守です。領域の知識を記述したスキルは、その知識が変われば更新が必要です。適切に設計したスキルは変わりやすい情報を含めないため、すべての変化に対応する必要はありませんが、一部の変更は避けられません。スキルを最新に保つには、ドキュメントを最新に保つのと同じ継続的な管理が必要です。そこに投資しない組織では、徐々にスキルが実態からずれていきます。失敗は静かに進みます。スキルは動作し続け、出力し続けますが、その出力には検出までに時間がかかる微妙な誤りが含まれるようになります。

スキルから最大の価値を得る組織は、初期設定と継続的な調整の両方に投資しています。初期投資は多くの人が想像するより小さく済みます。一方、継続的な保守への負担は、多くの組織の想定より大きくなります。その負担を現実的に計画することが、使い続けられるスキルと、気づきにくい誤りの原因になるスキルを分けます。

関連記事

• Claude Skills：AIのカスタマイズという課題に対するAnthropicの回答：Anthropicのスキルシステムの設計と、それが解決する組織の課題
• Web検索対応のローカルAIアシスタントを構築する：MCPとOllamaのセットアップ：セルフホスト環境でAIエージェントを使うためのツール設定
• WooCommerceとのPunchOut連携：高度な自動化によるB2B調達の効率化：構造化されたB2Bワークフローへの領域固有の自動化の適用