LINEヤフー Tech Blog

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

個人で育てたAIエージェント設定を、チームの資産にする(APMによるSkill・指示・MCPの配布とマルチエディタ展開)

Orchestration Development Workshop #13 APMでチームのAI駆動環境を1コマンド配布する

こんにちは、LINEヤフー株式会社の殿山雄大です。普段は社内のGPU/AI基盤の構築・運用を担当しています。

本記事では、2026年7月16日(木)に開催した社内ワークショップOrchestration Development Workshop(以下、ODW)の第13回での発表内容をもとに、個人で育てたAIエージェントの設定を、チーム全体で共有・再現・配布する方法をご紹介します。当日のハンズオンを、自分のペースで追える形に再構成しました。

Skill・指示・MCPといった設定を、Microsoftが公開しているAgent Package Manager(以下、APM)でチームに広げる方法を、実際に使えるコマンドとあわせて説明します。

自分の手元だけ問題

Claude CodeやCodex、GitHub Copilotを業務で使い込んでいると、手元にはよく効くSkillがいくつも溜まっていきます。

ある日、新しくチームに入ったメンバーに「その環境、どうやって作ったんですか」と聞かれます。設定ファイルを1つずつ探してSlackに貼り付け、「ここにこれを置いて、この値を書き換えて……」と説明した経験がある方も多いのではないでしょうか。

私が担当している基盤運用のチームでも、まさにこの状態になっていました。

  • 新しいメンバーが環境を用意するたびに設定値を手で転記していたため、転記ミスが起きやすくなっていた。
  • Skillを1つ追加するたびに、その内容を全員へ配り直す手間が発生していた。
  • 手作業で配布を繰り返した結果、誰がどの設定を持っているのか把握できなくなっていた。

一人ひとりが工夫して育てた設定が、その人の手元だけに閉じてしまい、チームで再利用しにくい。本記事で扱うのは、この「設定の配布」をどう仕組み化するか、という問題です。

APMとは

APMは、AIエージェント向けの設定をまとめて扱うためのツールです。Microsoftが2025年9月にOSSとして公開しています。

参考: Microsoft APM - GitHub

Gitだけの場合とAPM導入後の設定配布・依存関係・検証方法の比較

APMは、プログラムの世界で package.json や requirements.txt が依存ライブラリを宣言するのと同じことを、エージェント設定に対して行います。apm.yml に使いたいSkill・指示・MCPを書き、コマンドを実行するだけで各エディタの所定の場所へ設定を展開できます。

設定の共有には、APM以外にも次のような選択肢があります。

  • ファイルの標準規格: AGENTS.md(指示)や SKILL.md(Skill)は、多くのエディタが直接読み込めます。
  • エディタ固有の配布機構: Claude Codeのplugin、Copilotのカスタム指示、CursorのRulesなど。
  • エディタ横断の同期ツール: APMのほかにRulerやrulesyncといったOSSが存在します。

数ある選択肢の中で今回APMを取り上げるのは、「宣言ファイル1枚で、エディタを横断して配布できる」というシンプルで強力な強みがあるからです。

覚えることは、実質4つ

  • apm.yml: 何を使うかを宣言する設定ファイル。
  • apm install: 宣言を解決し、Claude CodeやCodexなど各エディタが参照するディレクトリへファイルを書き出す。
  • apm update: 配布元の更新を取り込み、各エディタの配置先を最新にする。
  • apm compile: 指示(規約)などを AGENTS.md の形に束ねる。

まず、apm.ymlの構造を示す最小例は次のとおりです。

name: sample-agent-pack
dependencies:
  apm: []          # 依存するSkill/agentパッケージ
  mcp: []          # 使うMCPサーバ

置き場所やエディタごとの差はAPMが吸収してくれるので、apm.yml に書くのは「何を使うか」だけです。裏を返すと、このファイルがそのまま「チームで使っているAI設定の一覧」になり、誰が見ても全体像を一目で把握・共有できるようになります。

apm install を実行すると、宣言されたSkillやMCPの実体を取得し、各エディタが参照するディレクトリへ自動で配置します。主な配置先は次のとおりです。

  • Skill: .claude/skills/、.agents/skills/
  • agent: .claude/agents/、.codex/agents/
  • 指示(規約): .claude/rules/
  • MCP: .mcp.json、.codex/config.toml

apm compile は、指示(規約)をCodexなどが読み込める単一の形式である AGENTS.md にまとめます。

ハンズオン:取り込む・増やす・配る

題材にするのは、Skill5個・agent1個・指示1個・MCP4個からなる、小さなサンプル構成です。運用でよくある「取り込む → 増やす → 配る」の3場面を、順番に追っていきます。

取り込む

まず apm install を実行し、apm.yml の宣言どおりにファイルが置かれたことを確認します。

apm install --trust-transitive-mcp # 間接依存のMCPを確認したうえで信頼して導入
cat apm.yml                        # 宣言(Skill5個・agent1個・instruction1個・MCP4個)
ls .claude/skills .agents/skills   # SkillがClaude用とハーネス共通の両方に置かれている
cat .mcp.json                      # 宣言したMCPの設定

apm install後に各エディタへ配置されたSkillとagent

実行結果には、apm.yml で宣言した5つのSkillが .claude/skills/ と .agents/skills/ の両方に並びます。agentも .claude/agents/ と .codex/agents/ に配置されます。これにより、同じ宣言からエディタごとのファイルが生成されたことを確認できます。

--trust-transitive-mcp は、依存先を経由して導入されるMCPを信頼するオプションです。出どころと内容を確認できるMCPにだけ使用してください。エディタを再読み込みすると、配置されたSkillを呼び出せます。

増やす

次に、サブエージェントを1つ足して配り直します。

cp path/to/new-agent.agent.md .apm/agents/
apm install                       # .claude/と.codex/のagent置き場が変わる

apm installを実行すると、追加したagentが.claude/agents/と.codex/agents/へ配置され、Claude CodeとCodexの両方で利用できる状態になります。

配る

最後に、配られる側——新しく参加するメンバーの視点です。手元に何もない状態から、GitHub上のリポジトリを直接指定して取り込みます。

mkdir consumer && cd consumer && ls -a   # 空。apm.ymlもまだ無い
apm install https://<git-host>/<org>/<repo>.git \
  --target claude --trust-transitive-mcp
cat apm.yml            # apm.ymlが自動生成され、取り込んだ設定がdependenciesに記録される
ls .claude/skills      # cloneせずにSkill一式が手元にそろう

空のディレクトリはエディタ構成を自動判別できないため、--target で対象エディタを明示します。実行後には apm.yml が生成され、取り込んだ設定が依存として書き込まれます。

配布元に更新があった場合、利用側は apm update を実行して更新を取り込みます。APMは自動更新しないため、必要なタイミングで明示的に実行します。

社内では、Skillを一覧できるカタログから取り込む運用もできます。apm marketplace add でカタログを登録し、apm install <skill>@<marketplace> で取り込みます。取り込んだものは apm.yml に依存として記録されます。

導入すると変わること

この仕組みを導入すると、次のような変化が起きます。

  • 新メンバーの受け入れ: 参加初日に、リポジトリをcloneして apm install を実行するだけで、チーム標準のSkill・指示・MCPがそろいます。手での転記作業がなくなります。
  • 横断作業の重複をなくす: 複数チームにまたがる共通作業をSkillにして配れば、各チームが同じものを作り直さずに取り込めます。
  • ベンダーを問わず設定を育てる: チーム内で改善したSkillを配り直せば、利用するAIベンダーやエディタが異なるメンバーにも同じ知見を共有できます。

特に面白いと感じているのは、メンバーが使うAIベンダーやエディタに依存せず、チーム内で同じ開発環境を育てていける点です。誰かがSkillを改善して配り直せば、その知見をClaude CodeやCodexなど異なる環境でも共有できます。設定を「配れる」状態にしておくことで、チーム全体が改善に参加できる仕組みになります。

おわりに

AIエージェントがうまく回らないとき、つい「どのモデルを使うか」「プロンプトをどう書くか」に目が行きます。でも一度、「その設定は、自分以外の人も再現できる形になっているか」を見直してみると、打ち手が変わってきます。

個人の手元に閉じていた設定を、チームで再現・配布できる形にする。それがAPMでやりたかったことでした。最初の一歩として、自分のチームで配りたいSkillを1つ決め、apm.yml に宣言するところから始めてみてください。

参考リンク

AI活用スキル向上ワークショップ「Orchestration Development Workshop」記事一覧