AIエージェントの差は、もう「どのモデルを使うか」だけでは付きません。勝負を分けるのは、現場の手順や判断基準を、どれだけ再利用できる形で渡せるかです。 今回のトークが示したのは、用途ごとに専用エージェントを量産するより、必要な専門知識を「スキル」として配るほうが現実的だということでした。これはAIの話であると同時に、会社の仕事の仕組みの話でもあります。
このトークの出発点はシンプルです。MCPがエージェント接続の標準として広がり、Claude Codeのような実戦投入できるコーディングエージェントが出てきたことで、エージェントの土台そのものはかなり汎用化した、という認識です。 発表者たちは以前まで、「ドメインごとに別のエージェントが必要だ」と考えていたと話していました。金融、研究、法務、経理。それぞれで必要なツールも文脈も違うので、専用の足場が要ると思っていたわけです。 でも実際に作ってみると、基盤側は驚くほど共通していました。APIを叩く。調べる。ファイルを整理する。Pythonで分析する。レポートを作る。これらは全部、コードでできます。つまり、デジタル世界に対するユニバーサルなインターフェースは、かなりの部分が「コード」だったということです。 ここで重要なのは、コアの足場が薄くていいことです。bashとファイルシステム、それに実行環境があれば、多くの仕事は回り始める。問題は「汎用エージェントが弱いこと」ではなく、「専門知識をどう渡すか」に移った、というのがこのトークの核心でした。
発表で一番分かりやすかったのは、「納税申告を頼むなら、IQ300の天才より経験豊富な税務の専門家を選ぶ」という例えでした。どれだけ賢くても、2025年の税法をゼロから毎回推論させたい人はいません。欲しいのは、一貫して再現できる専門実務です。
今日のエージェントは優秀ですが、まだこの壁にぶつかります。事前の重要な文脈を持っていない。ユーザーの専門知識をうまく吸収できない。時間とともに学習した成果を、次の仕事に確実に持ち越せない。だから毎回、同じ指示を繰り返すことになります。
そこで出てきたのがAgent Skillsです。定義は「エージェントのための構成可能な手続き型知識をパッケージ化した、整理されたファイル群」。もっと雑に言えば、ただのフォルダです。
この「ただのフォルダ」が強い。Gitで管理できる。Google Driveに置ける。zipでも共有できる。誰でも作れる。しかも中にスクリプトを入れられるので、曖昧な自然言語の指示よりも、再現性のある処理をそのままツール化できます。
発表では、モデルが困ったときにツールそのものを変更できないこと、従来のツールは命令が不足しがちなこと、常にコンテキストウィンドウを圧迫することが課題として挙げられていました。コードはこの逆です。自己文書化しやすく、編集でき、必要になるまでファイルとして寝かせておけます。
しかもスキルは段階的に開示されます。普段はメタデータだけを見せ、必要なときだけ skill.md と関連ディレクトリを読む。だから大量のスキルを持っていても、文脈を無駄に食い潰しません。この設計はかなり実務的です。
ここで誤解しやすいのが、「スキルがあればMCPはいらないのか」という点です。答えは逆で、両者は補完関係にあります。トークでは、MCPは外部への接続を提供し、スキルは専門知識を提供すると整理されていました。 たとえばBrowserbaseは、オープンソースのブラウザ自動化ツール向けスキルを作り、Claudeがウェブをよりうまく操作できるようにしました。Notionも、ワークスペース全体の深いリサーチを支えるスキル群を出しています。ライフサイエンスや金融サービスのような分野でも、特定業務に効くスキルがすでに使われ始めています。 面白いのは、ここで主役がエンジニアだけではないことです。Fortune 100企業では、組織のベストプラクティスや社内ソフトウェアの癖を教える手段としてスキルが使われている。さらに財務、採用、会計、法務のような非技術職の人たちもスキルを作り始めていると話していました。 要するに、エージェントに新しい能力を与える方法が変わったわけです。専用エージェントをゼロから作るのではなく、汎用エージェントに適切なMCPサーバーとスキルのライブラリを装備させる。このほうが、速く、安く、組織に広げやすい。
この話が本当に重要なのは、スキルが単なる拡張機能ではなく、「学習の受け皿」になっているからです。発表者たちは、スキルをエージェントの記憶を具体化する仕組みとして捉えていました。何でも保存するのではなく、特定のタスクで再利用できる手続き型知識を残すのです。 その先には、テストと評価、バージョン管理、依存関係の明示といった話が出てきます。スキルが複雑になれば、ソフトウェアと同じく品質管理が必要になる。いつロードされるべきか、期待した出力品質を出せているか、どのMCPや他スキルに依存しているかを管理しないと、実運用では崩れます。 発表の中で印象的だったのは、「30日間一緒に働いたClaudeが、初日のClaudeよりもはるかに優れていてほしい」という目標です。これはモデル自体の再学習を待つ話ではありません。現場で生まれた手順を、スキルとして残し、共有し、改善し続ける設計の話です。 この考え方は、コンピュータの歴史になぞらえるとよく分かります。モデルはプロセッサ。実行環境はOS。そして本当の価値を生むのは、その上に載るアプリケーションです。スキルは、その「アプリケーション層」を一部の開発者だけでなく、現場で仕事を知っている人たちにも開くための仕組みだと私は受け取りました。 だから実務で最初にやるべきことも明快です。毎回口頭で説明している手順を洗い出す。Markdownにする。必要ならスクリプトにする。1タスク1フォルダで共有する。エージェント時代に強い組織は、モデルを追いかける組織ではなく、手続き型知識を配布できる組織です。 エージェントを作るな、スキルを作れ。今回のトークは、その方向にかなりはっきり舵を切った宣言でした。 AI活用・キャリア戦略 個別相談 https://www.shoeisha.co.jp/book/detail/9784798193427 #AI #生成AI #AIエージェント #AI時代 #AI活用 #AI人材 #AI研修 #AIツール #Claude #ClaudeCode