ASADASHI
バイブコーディング
バイブコーディング2026.09.27·読了 2分·難易度: ふつう

AIコーディングを「ひとつの道具箱」にまとめるプラグイン基盤が登場

朝の出汁版(通勤2分)

  • ポイント1: Claude Code・Cursor・GitHub Copilotなど主要AIコーディングツールを横断して使えるエージェント型プラグイン基盤「agents」がGitHubで4万スター超えを記録している。
  • ポイント2: ツールごとにプロンプトや設定をゼロから組み直す手間がなくなり、「どのAIコーディング環境を使っても同じ作業フローを再現できる」ことがこの仕組みの本質。
  • ポイント3: GitHubリポジトリ(wshobson/agents)にアクセスし、自分が普段使っているCursorやCopilotの設定から読み込む手順を確認するところから始められる。

出汁の素(深読みモード)

Claude CodeもCursorもCopilotも「ひとつの設定」で動かす仕組み

GitHubで4万スターを超えたリポジトリ「wshobson/agents」が、AIコーディング界隈で静かに注目を集めている。

このプロジェクトが解決しようとしているのは、複数のAIコーディングツールを使い分ける人が全員抱える問題だ。Claude Codeでうまく動かしていたプロンプト設定を、Cursorに持ち込もうとすると一から組み直し。GitHub Copilotに切り替えたらまた別の流儀で書き直し——この「ツールを変えるたびにゼロリセット」が、実際に複数環境を横断している人ほど重くのしかかる。

「agents」はこれを「マルチハーネス型のプラグイン基盤」というアプローチで解消しようとしている。Claude Code、Codex、Cursor、OpenCode、GitHub Copilot、Google Antigravity、Piという主要ツールを横断して読み込める共通のエージェント定義を作り、「どの環境でも同じ作業フローが再現できる状態」を目指す設計だ。

以前の記事「AIエージェントに「道具箱」を持たせる時代へ」でも触れたように、AIエージェントに何をさせるかを「外から差し込める構造」にする流れは加速している。このリポジトリはその流れの延長線上にある実装のひとつとして位置づけられる。

「ハーネス」という概念がなぜ重要になってきたのか

リポジトリ名にある「multi-harness」という言葉は、もともと複数の馬を一頭のように御するための器具を指す。AIコーディングの文脈では、「異なるツールやエージェントを束ねて統一的に制御する層」を意味する。

「AIエージェントを束ねる「ハーネス」とは何か」でも整理したが、単体のAIツールが賢くなることと、複数のツールをつなぐ制御層が整うことは別の話だ。後者がなければ、ツールが増えるほど管理コストが比例して増える。

「agents」が提示している解法はシンプルで、「プラグインとしてエージェントの定義を書いておき、各ツールのインターフェース側でそれを読み込む」という構造だ。ツール側の仕様が変わっても、共通のエージェント定義さえ保守すれば全環境に反映できる理屈になる。

ただし、現時点でどこまでが動作確認済みで、どのツールとの連携が実験的段階かは、リポジトリのREADMEやissueを直接確認する必要がある。スター数が急増しているのは「方向性への期待」を反映している面が大きく、「すでに全ツールで安定稼働している」と読み取るのは早計だ。

コードなしでも動けること、コードが書けると広がること

devカテゴリのツールだからといって、プログラマー専用というわけではない。このリポジトリの使い方は、大きく2層に分かれる。

コードなしで試せる範囲としては、既存のプラグイン定義をそのまま自分のCursorやCopilot環境に読み込む使い方がある。READMEに記載された手順に従い、自分が普段使っているツールの設定ファイルに数行追記するだけで、他の人が作ったエージェント定義を自分の環境に取り込める。動画編集のワークフロー補助や、コードレビューの指示セットなど、すでに誰かが書いたプラグインをそのまま流用する使い方は、コードの読み書きがなくても現実的だ。

コードが書けると広がる範囲としては、自分専用のエージェント定義を書いてプラグイン化し、環境をまたいで再利用できるようにすること。たとえば「自分のブログ文体でコードコメントを書き直す」「特定のファイル構造でプロジェクトを初期化する」といった個人ルールをエージェント化して持ち歩く、という使い方が想定できる。

「AIがコードを自律最適化、動画処理が劇的に速くなる」でも取り上げたように、AIが自律的に動く範囲を「自分で決められる人」と「ツールに任せるしかない人」の差は、こういった設定の主導権を握れるかどうかで出てきている。

まず触るなら:リポジトリのどこを見るか

始め方として現実的な手順を整理する。

まずは「https://github.com/wshobson/agents」にアクセスして、READMEを読む。自分が普段使っているツール(CursorなのかCopilotなのかClaude Codeなのか)に対応する設定セクションがあるかを確認するのが最初の判断ポイントだ。

次に「agents」フォルダの中身を見て、どんなエージェント定義がすでに用意されているかを確認する。自分のユースケースに近いものがあれば、それをそのまま試すのが最短ルートになる。

気をつけたいのは「自分の普段使いのツールが、どのバージョンでこのプラグインに対応しているか」という点だ。特にCursorのようにアップデートが頻繁なツールは、プラグインの読み込み仕様が変わることがある。issueタブで「自分のツール名」で検索して、既知の問題が報告されていないかを先に確認しておくと無駄な時間を省ける。

試す順番としては、「いちばん使用頻度の高いツール」×「いちばんシンプルなプラグイン定義」の組み合わせから始めるのが安定している。

自分でプラグインを書いて「環境依存ゼロ」の作業フローを作る

より踏み込んで使いたい人向けの視点として、「agents」の本当の価値は「他人のプラグインを使う」ことより「自分のワークフローをポータブルにする」ことにある。

Pythonでエージェント定義を書けるなら、自分が繰り返しやっている作業——「PRの説明文を一定フォーマットで生成する」「コードに特定の命名規則を適用する」「デプロイ前のチェックリストを自動で走らせる」といったものをプラグインとして書き出すことで、ツールが変わっても作業フローだけは引き継げる状態を作れる。

GitHub Copilotが主力の今日、明日にはOpenCodeが有力になるかもしれない。そのたびに「自分のやり方」を作り直すコストを避けたいなら、作業定義をツールに依存しない形で持つという習慣が長期的に効いてくる。リポジトリのcontributing guideも公開されており、自分が作ったプラグインをPRとして送る導線も用意されている。

参照ソース