はじめに
第1回では、AIエージェントを「目的に向かって自らが環境と相互作用する知能システム」として定義しました。同回では、ツール実行と観測、ルーティングを伴うワークフロー、ループを伴うマルチエージェントといった基本パターンを紹介しています。
これまでに提示した定義や基本パターンは、現在でもAIエージェントを理解するうえで大きな参考になります。一方で、連載を開始した2025年10月ごろから半年ほどの間に、AIエージェント開発において考慮すべき点が、開発の主眼がモデル単体の性能やプロンプトの工夫から、モデルの外側を取り囲む「外部環境の設計」へと明確にシフトしつつあります。
そこで、連載の最後となる本稿では、連載開始以降の象徴的な変化として「スキル」の登場と「コーディングエージェント」の進化を解説し、あらためて現在のAIエージェント開発状況を整理します。
Agent Skillsの登場
Anthropicは2025年10月16日にAgent Skills（スキル）を発表しました。当初はClaudeアプリ用の機能として登場し、公式ブログでは「Claudeが必要に応じて読み込める、指示、スクリプト、リソースを含むフォルダ」と説明されています。
その後、2025年12月にはスキルがオープンスタンダードとして公開されました。すべてのエージェントが同様に対応しているわけではありません。しかし、現在はAnthropic固有の便利機能にとどまらず、主要なエージェント実行環境で共有可能な作業単位として扱われ始めています。
スキルとは
あらためて、スキルがどのようなものかを解説します。スキルは「SKILL.md」を中心としたディレクトリとして表現される、一つの作業単位（パッケージ）です。
SKILL.mdは、スキルの入り口となる説明書のような存在であり、何のためのスキルか、どのような依頼で使うべきか、実行時にどう進めるべきかを記述します。必要に応じて、同じディレクトリに参考資料、テンプレート、実行用スクリプトなどを配置し、SKILL.mdから直接参照させることが可能です。
スキルを捉えるうえで重要なのは、単なる「LLMへのツール説明書」ではないという点です。ツールが「何を実行できるか」をエージェントに渡すものだとすれば、スキルは「該当ツールを、どの文脈で、どう組み合わせ、どこで判断するか」までを含めて提示するものであり、より人間が実行するタスクに近い特性を持っています。
したがってスキルは、エージェントのための再利用できる作業手順に近いと言えます。ただし、人間向けの手順書とは異なり、読むためだけの文書ではありません。例えば、レポート作成のスキルを例に挙げると、単にPDFを読み込むツールを渡すだけでなく、「PDFから表を抽出し、数値を確認し、必要なら正規化スクリプトを実行し、最後に指定形式 of レポートにまとめる」といった一連のプロセスを定義できます。必要であれば、スクリプト、テンプレート、参照資料、確認観点も同じ単位に包含できます。
このように定義したスキルを読み込ませることで、モデルに毎回その場で手順を考えさせることなく、安定して繰り返し作業を進められます。スキルは、作業の再利用性を高めるための枠組みだと考えられます。
なぜスキルが広まったのか？
スキルが急速に普及した理由は、新しい種類のタスクを突然可能にしたからではありません。プロンプトに手順を書き、必要なツールを呼び出して、LLMやエージェントに特定の作業をさせること自体は、これまでも可能でした。
大きな違いは、作業手順を「共通の再利用可能な単位」として切り出し、エージェントが必要に応じて選択できる形にした点にあります。
従来の開発手法では、手順は個別のシステムプロンプトやワークフローの中に組み込まれていました。そのため、似た作業を別の環境で使い回すには、プロンプトの構成や参照ファイルの配置、テンプレートの扱い方をその都度作り込む必要があったのです。複数の手順から状況に合うものを選ばせたい場合も、候補の提示方法や選択ロジックを個別に設計しなければなりませんでした。
スキルは、こうした課題に対して共通のフォーマットを提供します。SKILL.mdを中心に、作業の説明、実行手順、参照資料、テンプレート、スクリプトを一つのパッケージとしてまとめられます。エージェントは、そのパッケージを候補として認識し、必要な場面で呼び出すことができます。つまり、作業手順をプロンプトの一部ではなく、「選択可能な独立した能力」として扱いやすくしたことに大きな価値があります。
こうした構造は、実際の業務の性質にも合致しています。人間が任せたい仕事は、一つの固定された手順だけで完結するとは限りません。調査、要約、レビュー、修正、ドキュメント化のように、複数の作業を組み合わせながら進めるケースが大半です。しかも、どの手順を適用すべきかは、入力内容や途中の出力結果によって動的に変化します。
動的な作業においては、最初から一つのワークフローに固定するよりも、エージェントが状況を判断して必要なスキルを選び、適切なファイルやスクリプトを使いながら進める方が自然です。「複数の候補から選ぶ」「複数のファイルを参照する」「結果に応じて判断を繰り返す」といった複雑なパターンは、まさにスキルという単位が真価を発揮する領域と言えます。
ただし、多数のスキルを用意すると、別の問題が発生します。すべての手順や資料を最初から読み込ませれば、コンテキストウィンドウ（モデルが一度に扱えるトークン数）を圧迫しかねません。そこで重要になるのが、「progressive disclosure（段階的開示）」というアプローチです。
Anthropicのドキュメントでは、スキルは必要な情報を段階的に読み込む設計（progressive disclosure）であると説明されています。まず各スキルのメタデータ（特にnameやdescription）を使って利用の是非を判断し、スキルが必要になった段階で初めて SKILL.md の本文を読み込み、さらに必要に応じて参照ファイルやスクリプトへと処理を進めます。すべてを最初から抱え込むのではなく、必要になった分だけ動的にロードする仕組みです。
この設計のおかげで、スキルの数を増やしてもコンテキストを圧迫しにくくなります。結果として、多数のスキルを用意したとしても、エージェントが破綻せずに複数の能力を扱いやすくなる仕組みです。
最後にもう一つ重要なメリットは、スキル自体のメンテナンス性の高さです。作業手順が共通フォーマットで構造化されていれば、過去の失敗例やレビュー観点、実行ログをもとに、エージェント自身にスキルの改善案を作成させることもできます。プロンプトやワークフローが個別のコードに埋め込まれている場合と比較して、エージェントによる自己改善が格段に容易になります。
もちろん、スキルの更新まで自動化するには、実行結果の履歴やレビュー記録などをスキルの外部に蓄積するエコシステムも必要です。しかし、作業手順を再利用可能な単位として切り出し、オンデマンドで段階的に読み込ませるための器としては、現在のエージェント開発の要求に非常に適しています。
従来のプロンプトや固定ワークフローで個別に実装していた要素を、より持ち運びやすく、選びやすく、拡張しやすい形に整理したからこそ、スキルが広く受け入れられたのは自然な流れと言えるでしょう。
