Skip to main contentSkip to footer
Search
LINEヤフー Tech Blog

LINEヤフー株式会社のサービスを支える、技術・開発文化を発信しています。

Git自動化で見るMCPとAgent Skillの長所・短所

こんにちは。AI LabチームのHan Kil Roです。サービスに必要なAIモデルやソリューションを開発するチームで業務に携わっています。

最近、LINEヤフー社内で実施された Orchestration Development Workshop において、「MCPとAgent Skillの理解」というテーマで講師を務めました。

今回のブログでは、そのワークショップの内容にいくつかの具体例を補足しながらまとめています。

はじめに

最近のAIエージェント開発の動向を見ると、MCP（Model Context Protocol）サーバーを構築するアプローチから、Agent Skillベースへと開発方針を切り替える流れが明確になってきています。実際に適用してみると、実装は確かにシンプルになり、アーキテクチャ自体もかなり軽量になることを実感できます。すでに多くのユーザーがSkillの利点を認識し、積極的に活用していると思いますが、なぜこのような選択が広がっているのか、簡単に整理してみましょう。

インターネットで「Agent Skill」を検索すると、基本概念やよく作り込まれたGitHub上のサンプルは簡単に見つかります。しかし実際には、「では、これを使って自分の日常や実務で何をどのように作り、どう活用すればいいのか？」という疑問を解消してくれる、実践的で親切なガイドはあまり見当たりませんでした。

そこで今回は、Skillについてまだ詳しくない方でもすぐに実務や日常で応用できるよう、具体例とあわせてSkillの活用方法を一緒に組み立てていきます。

なお、Skillの概念的な説明や詳細な使い方そのものについては、今回は扱いません。

例：Gitスマートリリース自動化Skillを構築する

それでは、さっそく例を見ていきましょう。開発実務の中で役立つかもしれない「Gitスマートリリース自動化」Skillを実際に作ってみます。

この作業をゼロから一つずつ実装しようとすると、かなり煩雑です。そこで今回は、Anthropicが公式に提供している skill-creator Skill を積極的に活用します。文字どおり「Skillを作るためのSkill」を使って、リリース自動化用のSkillを効率よく生成していく構成です。

まずは、エージェントに実装させるための要件を整理してみます。この内容をそのまま skill-creator にプロンプトとして渡す予定です。

Gitスマートリリース自動化 Skill 要件定義

【目的】
skill-creator を用いて、カレントディレクトリ上の Git プロジェクトを自動リリースする Skill を構築する。

【機能要件】
1. Git Log 分析：現在のフォルダで git log を読み取り、直近のタグ（例：v0.1.0）以降の変更内容を取得する。
2. Changelog 更新：抽出した変更内容を要約し、CHANGELOG.md ファイルの先頭に追加する（ファイルが存在しない場合は新規作成する）。
3. バージョンバンプ（Version Bump）：pyproject.toml 内の version = "..." を検出し、バージョンを patch レベルで1段階上げる（例：0.1.0 → 0.1.1）。
4. Commit & Tagging：変更されたファイル（CHANGELOG.md、pyproject.toml）を git add し、chore: release v[新バージョン] というメッセージでコミットしたあと、最終的に git tag v[新バージョン] を作成する。

【主要な制約事項】
- 本 Skill は、必ず現在のターミナルにおけるカレントディレクトリ（pwd）を基準に動作するローカル Python スクリプトとして構成すること。

このように主要な条件とワークフローを明確に定義しておくことで、エージェントが意図しないディレクトリを操作したり、不必要に複雑な計画を立てたりすることを未然に防げます。

では、このプロンプトを入力したときに Skill がどのように完成し、実際にどのように動作するのかを、次のステップで具体的に見ていきましょう。

今回は Claude Code を使って進めます。

Gitスマートリリース自動化 Skill 要件定義

【目的】 skill-creator を用いて、カレントディレクトリ上の Git プロジェクトを自動リリースする Skill を構築する。

【機能要件】
Git Log 分析：現在のフォルダで git log を読み取り、直近のタグ（例：v0.1.0）以降の変更内容を取得する。
Changelog 更新：抽出した変更内容を要約し、CHANGELOG.md ファイルの先頭に追加する（ファイルが存在しない場合は新規作成する）。
バージョンバンプ（Version Bump）：pyproject.toml 内の version = "..." を検出し、バージョンを patch レベルで1段階上げる（例：0.1.0 →
0.1.1）。
Commit & Tagging：変更されたファイル（CHANGELOG.md、pyproject.toml）を git add し、chore: release v[新バージョン] というメッセージでコミットしたあと、
最終的に git tag v[新バージョン] を作成する。

【主要な制約事項】
本 Skill は、必ず現在のターミナルにおけるカレントディレクトリ（`pwd`）を基準に動作するローカル Python スクリプトとして構成すること。

⏺ Gitスマートリリース自動化 Skill を作成します。skill-creator を使用します。

⏺ Skill(skill-creator)
⎿ Successfully loaded skill

⏺ git-smart-release Skill の作成を支援します。この Skill が意図どおり正確に動作するよう、いくつかの点を先に明確化します。


要件の理解

提示された仕様をもとに、以下の内容を確認しました。

✅ 最後のタグ（例：v0.1.0）以降の git log を分析
✅ CHANGELOG.md の先頭を更新、または新規作成
✅ pyproject.toml の patch バージョンを更新
✅ "chore: release v[version]" メッセージで変更をコミット
✅ Git タグを作成
✅ カレントディレクトリ（pwd）で動作することが必須

要件が十分に明確でない場合は、LLMからの質問を通じて追加で要件を明確化していきましょう。

いくつか質問があります。

1. バージョン管理の柔軟性：常に patch バージョンのみを上げますか（0.1.0 → 0.1.1）。それとも minor / major のバージョンアップにも対応させますか？ たとえば、ユーザーが「minor リリースして」と依頼したときに 0.1.0 → 0.2.0 になるようにしますか？
2. 初回リリース：過去のタグが存在しない場合（初回リリース）はどのように処理しますか？ デフォルトを v0.1.0 にしますか、それとも v1.0.0 にしますか？
3. CHANGELOG 形式：チェンジログのエントリはどのような形式を希望しますか？ たとえば、次のような形式はいかがでしょうか。
  [0.1.1] - 2026-03-15
  feat: Added new feature X
  fix: Fixed bug Y
  docs: Updated documentation
4. Git push：この Skill は、コミットとタグをリモートリポジトリまで push しますか？ それともローカルでの作成までにとどめますか？
5. 例外処理：未コミットの変更が存在するかを事前に確認し、ワーキングディレクトリが dirty な場合は警告を出す、あるいは処理を中断するようにしますか？


1. すべてのバージョンアップに対応してほしい
2. v0.1.0 から始めてほしい
3. そのままでよい
4. リモートリポジトリまで対応してほしい
5. 処理を中断し、その理由も説明してほしい

要件が明確になったので、次に Skill を作成します。

⏺ 完璧です。要件を整理すると次のとおりです。

1. ✅ patch / minor / major のすべてに対応
2. ✅ 初回リリースは v0.1.0 から開始
3. ✅ CHANGELOG 形式はそのまま維持
4. ✅ リモートリポジトリまで push
5. ✅ dirty なワーキングディレクトリをチェックし、中断時には理由を説明

では、Skill を作成します。

⏺ できました。git-smart-release Skill の作成が完了しました。構成した内容は次のとおりです。

📦 Skill 構成

git-smart-release/
├── SKILL.md                  # Skill 定義とガイド
├── scripts/
│   └── smart_release.py      # Python 自動化スクリプト
└── evals/
└── evals.json            # テストケース

✨ 実装した機能

この Skill は次の機能をサポートします。

✅ すべてのバージョン種別に対応：patch / minor / major（ユーザーが選択）
✅ 初回リリース：v0.1.0 から開始
✅ CHANGELOG.md：'Keep a Changelog' 標準形式で自動生成・更新
✅ ワーキングディレクトリのチェック（dirty check）：未コミット変更がある場合は処理を中断し、理由を説明
✅ リモート push：コミットとタグをリモートリポジトリまで自動で push
✅ コミット種別の自動分類：feat、fix、docs などを自動で分類

作成した Skill を実行する前に、まずは軽く中身を確認してみましょう。

git-smart-release フォルダに移動し、SKILL.md ファイルを開いてみます。

SKILL.md

SKILL.md ファイル

Frontmatter（YAML メタデータ）：エージェントがこの Skill を「いつ」「なぜ」使うべきか判断するために、常に軽量に（およそ100トークン程度）メモリ上へ読み込んでおく、いわば Skill の検索インデックス兼メタ情報です。（Skill 2.0 以降では、さまざまな新機能をこの Frontmatter に定義できます）

Markdown Body（本文ガイド）：エージェントが Skill の使用を決定した時点でのみ読み込まれ、「どのように」作業すべきかを具体的な手順として指示する、実行マニュアル（手続き的知識とワークフロー）です。

scripts / smart_release.py

scripts / smart_release.py ファイル

LLM が直接データを読み書きしてトークンを消費する代わりに、ローカル環境で複雑な処理（Git 操作、ファイル更新）を直接実行する実行スクリプトです。

今回作成した Git スマートリリース Skill は、SKILL.md に記述されたガイドに従ってユーザーの要求を実行し、必要に応じて smart_release.py スクリプトを利用します。

シナリオ：Python 計算機プロジェクト

先ほど作成した Skill をテストするために、非常にシンプルな Python 計算機プロジェクトを1つ用意しました。プロジェクト構成は次のとおりです。

Python計算機プロジェクトのプロジェクト構成

このプロジェクトの仕様と現在の状態は、テスト目的に合わせて極力シンプルにしています。

  • コアロジック（calculator.py）：加算（Add）と減算（Subtract）だけを実装した最小構成の Python モジュール
  • パッケージ設定（pyproject.toml）：プロジェクトのメタデータを含み、現在のバージョンは version = "0.1.0" と定義済み
  • 現在の Git 状態：初期セットアップ後に v0.1.0 のタグ付けを行い、コミットと push まで完了済み。つまり、基準となる過去のリリース履歴がすでに存在している状態です。

ここからの検証シナリオは次のとおりです。

この calculator.py に、シンプルな「乗算（Multiply）」機能を1つ追加して作業を完了させます。そのあと、先ほど作成した 「Git スマートリリース Skill」をエージェントに呼び出します。

エージェントが次の流れを正しく実行できるか、一緒に見ていきましょう。

  1. v0.1.0 以降の変更点（「乗算機能の追加」）を正確に抽出する
  2. CHANGELOG.md を作成する
  3. pyproject.toml のバージョンを 0.2.0（意図的に minor バージョンアップ）へ更新し、コミットとタグ付けを行う

calculator.py

def add(a, b):
    return a + b
 
def subtract(a, b):
    return a - b
 
if __name__ == "__main__":
    print(f"2 + 3 = {add(2, 3)}")

ここに「乗算」機能を追加します。

def add(a, b):
    return a + b
 
def subtract(a, b):
    return a - b
 
def multiply(a, b):
    return a * b
 
if __name__ == "__main__":
    print(f"2 + 3 = {add(2, 3)}")

追加できたら、コミットしてみましょう。

python-calculator % git commit -m "feat: 乗算機能を追加"
[main f8148cb] feat: 乗算機能を追加
 1 file changed, 3 insertions(+)

では、リリースしてみます。

Claude Code で「現在のプロジェクトの新しいバージョンのリリースを進めてください」と依頼してみます。

⏺ 🎉 リリース v0.2.0 完了！

git-smart-release Skill が次の処理を自動で実行しました。

📋 実行プロセス

1. 事前検証

- ワーキングディレクトリがクリーンであることを確認
- 現在のバージョンを確認（v0.1.0）

2. CHANGELOG.md の生成 ✨

- 最後のタグ（v0.1.0）以降のコミットを分析
  - feat: 乗算機能を追加
  - chore: Python プロジェクト用 .gitignore を追加
- コミット内容をもとに変更ログを自動生成
- Features セクションと Chores セクションに分類

3. pyproject.toml のバージョン更新

- version = "0.1.0" → version = "0.2.0"（minor バージョンアップ）

4. Git コミットの作成

- コミットメッセージ：chore: release v0.2.0
- 変更ファイル：CHANGELOG.md, pyproject.toml

5. Git タグの作成

- 新しいタグ：v0.2.0

6. リモートリポジトリとの同期

- リモート変更を rebase（3コミットを処理）
- コミットとタグをリモートリポジトリへ push

📊 最終状態

タグ一覧：
- v0.1.0（初回リリース）
- v0.2.0（現在のリリース）← NEW!

コミット履歴：
312a774 (HEAD -> main, tag: v0.2.0) chore: release v0.2.0
ba3525c chore: add .gitignore for Python project
58710a5 feat: 乗算機能を追加
b74ac36 Create README.md
299bf56 (tag: v0.1.0) feat: 初期計算機実装（加算、減算）

すべての変更がリモートリポジトリへ push されました！ 🚀

一連の処理は問題なく完了したようです。

では、要件どおりに CHANGELOG.md と pyproject.toml がどのように更新されたか確認してみましょう。

CHANGELOG.md

Changelog
 
All notable changes to this project will be documented in this file.
 
[0.2.0] - 2026-03-15
 
Features
 
乗算機能を追加
Chores
 
add .gitignore for Python project

pyproject.toml

[project]
name = "python-calculator"
version = "0.2.0"
description = "A simple calculator for testing release automation"

きれいに更新されています。

ここまで、私たちが構築した「Git スマートリリース Skill」を通じて、これまで煩雑だったリリース自動化フローを無事に完了できました。エージェントは、こちらが定義した手順を正確に実行しています。

  • Git Log 分析：現在のフォルダで、最新タグ以降のコミット履歴を読み取る
  • Changelog 更新：抽出した変更内容を要約し、CHANGELOG.md の先頭に自動追加する
  • バージョンバンプ（Version Bump）：pyproject.toml を確認し、major / minor / patch のいずれかでバージョンを1段階更新する（例：0.1.0 → 0.1.1）
  • Commit & Tagging：変更されたファイルを git add し、chore: release v[新バージョン] でコミットし、タグ付けまで完了する

ここで注目したいのは、エージェントが単に機械的にスクリプトを実行して終わるわけではない、という点です。定義されたワークフローを遂行する途中で、追加の対応や例外処理が必要だと判断した場合には、AI が次のアクションまで提案してくれます。LLM の柔軟性とスクリプトの厳密性が組み合わさることで、高い相乗効果が生まれているわけです。

もちろん、次のように考える方もいるかもしれません。

「実際のところ、この一連の流れは、わざわざ Skill を作らなくても、毎回チャット欄に長いプロンプトを書けば実現できるのではないか？」

はい、そのとおりです。機能面だけを見れば十分可能です。ただし、実務環境では事情が異なります。複数ステップにまたがる複雑な作業において、担当者が毎回プロンプトの内容を漏れなく記憶し、正確に入力してくれることを前提にするのは、それ自体がリスクであり非効率です。

チーム単位で必ず守るべき厳格なルールや、反復的に実行するワークフローがあるのであれば、それを「Skill」という標準化されたモジュールとして内在化し、配布しておくことで、担当者のコンディションやプロンプト作成スキルに依存せず、誰がいつ実行しても一貫した品質の高い成果を得られます。

MCPで同じ作業を実行してみると？（比較分析）

では次に、同じプロセスを MCP 環境でもう一度実行してみましょう。（mcp-builder を使ったサーバー構築の詳細はここでは省略します）

今回は、計算機プロジェクトに「除算」と「mod」機能を追加したあと、作成済みの git-release-mcp サーバーを呼び出し、新しいバージョンのリリースを依頼してみました。

User: git-release-mcp サーバーを使って、現在のプロジェクトの新しいバージョンのリリースを進めてください。

では、今回は除算と mod 機能を追加してみます。

calculator.py

def add(a, b):
    return a + b
 
def subtract(a, b):
    return a - b
 
def multiply(a, b):
    return a * b
 
def divide(a, b):
    return a / b
 
def mod(a, b):
    return a % b
 
if __name__ == "__main__":
    print(f"2 + 3 = {add(2, 3)}")

追加できたら、コミットしてみましょう。

python-calculator % git add calculator.py
python-calculator % git commit -m "feat: 除算機能とmod機能を追加"
[main 96e32f8] feat: 除算機能とmod機能を追加
 1 file changed, 3 insertions(+)

では、もう一度リリースしてみます。

git-release-mcp サーバーを使って、現在のプロジェクトの新しいバージョンのリリースを進めてください。

⏺ git-release-mcp サーバーを使って新しいバージョンのリリースを進めます。まず、前回のリリース以降の変更内容を分析します。

⏺ git-release - Analyze Git Commits Since Last Tag (MCP)(params: {})
  ⎿  {
       "result": "# Git Commit Analysis\n\n**Current Tag:** v0.2.0\n**Total Commits:** 1\n\n**Suggested Version Bump:** minor (new features added)\n\n---\n\n## Features\n\n- feat: 除算機能とmod機能を追加\n"
     }

⏺ 📊 コミット分析結果

よいニュースです。前回のリリース以降に新しい変更があります。

- 現在の Git タグ：v0.2.0
- 前回タグ以降のコミット数：1件
- 推奨バージョン種別：minor（新機能追加）

変更内容：

- Features（機能追加）🎉
  - 除算機能と mod 機能を追加

---

⏺ Read 1 file (ctrl+o to expand)

⏺ 現在のバージョンは 0.2.0 です。新機能が追加されているため、**minor バージョン（0.3.0）** でリリースを進めます。

⏺ git-release - Create Git Release with Version Bump (MCP)(params: {"version_type":"minor","working_directory":"/Users/kilro.han/workspace/python-calculator"})

⎿{
  "result": "# 🎉 Release Successful!\n\n**Version:** v0.2.0 → v0.3.0\n**Version Type:** minor\n\n## Files Modified\n\n- ✓ CHANGELOG.md (updated with new entries)\n- ✓ pyproject.toml (version bumped to 0.3.0)\n\n## Git Operations\n\n- ✓ Created commit …"
}

⏺ 🎉 リリース成功！

git-release-mcp サーバーを通じて、v0.2.0 から v0.3.0 へのリリースが正常に作成されました。

📊 リリース概要

| 項目      | 内容           |
| ------- | ------------ |
| 旧バージョン  | v0.2.0       |
| 新バージョン  | v0.3.0       |
| バージョン種別 | minor（新機能追加） |
| リリース日   | 2026-03-16   |

✅ 自動で実行された処理

1. ✓ pyproject.toml 更新
   - バージョン：0.2.0 → 0.3.0
2. ✓ `CHANGELOG.md` 更新
   - 新しいセクションを追加：[0.3.0] - 2026-03-16
   - 変更内容を自動分類して記録
3. ✓ Git コミット作成
   - コミットメッセージ：chore: release v0.3.0
4. ✓ Git タグ作成
   - タグ：v0.3.0

📝 今回のリリース変更点

Features（新機能）
- ✨ 除算機能と mod 機能を追加

やはり MCP サーバー経由でも、リリースは問題なく進みました。ただし、このログを丁寧に見ていくと、Skill 方式との決定的な違いが見えてきます。

ログ中に現れる「⏺ git-release - 」という項目は、LLM が MCP サーバーと直接やり取りしているプロセスを示しています。つまり、LLM が「Git Log 分析 → Changelog 更新 → バージョンバンプ → コミット / タグ付け」という4つの工程を進めるために、各ステップごとに MCP サーバーを呼び出し、その結果を受け取って次のアクションを自律的に判断しているわけです。一方、先ほど見た Skill では、この1〜4の工程をローカルスクリプト側で直接まとめて処理します。

このような MCP の「各ステップで LLM の判断が介在する」方式には、潜在的なリスクやデメリットがあります。

  1. 過剰な権限（Over-privileged）：LLM が毎回ツールを自律的に組み合わせるため、意図しない危険な操作や不要なデータにアクセスするリスクが存在する
  2. 中間結果の二重通過（Double Pass）：大きな中間結果（たとえばコミットログ全体）が、何度も LLM と MCP サーバーの間を往復するため、不要なトークンコストが増大する

Skill は、こうした手続き的知識を内在化することで、権限過剰や二重通過の問題をシンプルかつ自然に解消してくれます。

では、すべてを Skill にすべきか？

ここまで読むと、次のように考える方もいるでしょう。

「では、MCP の代わりにすべて Skill として実装すればよいのではないか？」

結論から言うと、必ずしもそうではありません。私自身の経験も含め、多くの専門家が共通して指摘しているのは、「MCP と Skill は競合するものではなく、相互補完の関係にある」という点です。

すべての機能を1つの Skill の中へハードコードして押し込んでしまうと、保守性の観点で大きな問題が生じます。新しいプラットフォームを連携するたびにスクリプトを修正しなければならず、MCP が本来持っている高い拡張性を、自ら捨ててしまうことになるからです。

理想的なアーキテクチャは、この2つの役割を明確に分離することです。

  • MCP：外部システム（DB、API、ファイルなど）との接続を担うインフラ / コネクティビティ層
  • Skill：複雑な作業ステップを定義し、ビジネスロジックを適用するワークフロー / オーケストレーション層

一言でまとめると、MCP はデータが走るための「堅牢な高速道路」であり、Skill はその上を目的地まで安全かつ効率的に走る「賢い自動運転トラックのソフトウェア」に相当します。

実務導入前に必ず把握しておきたい Caveat（注意点）

最後に、現時点で Skill を実務導入しようとしている方が、必ず認識しておくべき重要な事実を1つ共有します。

現在の Agent Skill エコシステムは、Claude Code のような「CLI ベースのコーディングエージェント」や、Claude Desktop のようなアプリケーション上で最適に動作するよう設計されています。これを無理に MCP サーバーのような汎用サーバー環境で実装しようとすると、現状では中途半端な構成にとどまる可能性が高いです。

現時点で Skill 機能を公式にサポートしている SDK は Anthropic SDK のみであり、それですら、ユーザーがローカルで作成した Skill 一式をクラウドへまとめて送信し、そのうえで仮想環境を作成して実行する方式を採っています。つまり、意図せず大量のトークン消費が発生しうる構造になっているわけです。

今後、Anthropic やオープンソースコミュニティがこのアーキテクチャをどのように発展させていくのかは、引き続き見ていく必要があります。ただし現時点では、CLI 環境のコーディングエージェントやデスクトップアプリケーション上で適切に動作するよう設計されている点を理解しておくべきでしょう。

こうした特性や長所・短所を正確に理解し、自分たちの業務に合った Skill を適切に構築できれば、はっきりとした生産性向上を実感できるはずです。