2026年8月29日(土) 1時
論文AI コーディング助手の「プラグイン」は、どう育てられているのか
ChatGPT の兄弟 AI・Claude に機能を追加する「プラグイン」の使われ方と育ち方を、2000 近くのリポジトリから調査。普通のソフトウェアと全く違う保守パターンが見えてきた。
この研究のポイント
- 1.
何を調べたか
Claude のプラグインマーケットプレイスの 1,926 リポジトリ、8,351 プラグイン、77,773 コミットを分析し、テキスト命令とスクリプトという新しい構成でのプラグイン開発の実態を明らかにした
- 2.
見えてきたこと
機能追加が従来の OSS の 2 倍以上、AI が 34.9% のコミットを占めるなど、人間とAI の共同作業による高速な機能駆動型の開発サイクルが構成されている
- 3.
私たちにとっての意味
従来のソフトウェアにない『命令ファイルと実装スクリプトの機能的な共進化』という新しい保守依存関係が発見され、AI 時代ならではの開発パターンが形成されている
著者Ahmed Hereiz, Yingzhe Lyu, Hao Li, Bram Adams, Ahmed E. Hassan
AIが気になってること
?『テキスト命令ファイル』って、プログラミング言語で書くコードとはどう違うの?
テキスト命令ファイルは、プログラミング言語とは全く異なる「人間のための言葉」で書かれています。たとえば Python や JavaScript のコードなら「変数を定義する」「ループを回す」といった計算機的な指示をコンピュータ構文で書きますが、テキスト命令ファイルは「このプラグインは何ができるのか」「どんな入出力を期待するのか」という説明文みたいなものです。Claude のような AI は、このテキスト指示を読んで「ああ、こういう目的のプラグインなんだな」と理解してから、実際にコードを動かす。言い換えれば、プログラミング言語は「コンピュータへの指令書」で、テキスト命令ファイルは「AI への説明文」。だからこそ、記事で「依存関係が特別」と言われるわけです。通常のソフトウェアなら、コード同士の依存は明確に追跡できますが、AI プラグインでは人間のような解釈を挟むから、その関係性が複雑になる。そこが既存の開発手法とは根本的に違っているのかもしれません。
『テキスト命令ファイル』って、プログラミング言語で書くコードとはどう違うの?
テキスト命令ファイルは、プログラミング言語とは全く異なる「人間のための言葉」で書かれています。たとえば Python や JavaScript のコードなら「変数を定義する」「ループを回す」といった計算機的な指示をコンピュータ構文で書きますが、テキスト命令ファイルは「このプラグインは何ができるのか」「どんな入出力を期待するのか」という説明文みたいなものです。Claude のような AI は、このテキスト指示を読んで「ああ、こういう目的のプラグインなんだな」と理解してから、実際にコードを動かす。言い換えれば、プログラミング言語は「コンピュータへの指令書」で、テキスト命令ファイルは「AI への説明文」。だからこそ、記事で「依存関係が特別」と言われるわけです。通常のソフトウェアなら、コード同士の依存は明確に追跡できますが、AI プラグインでは人間のような解釈を挟むから、その関係性が複雑になる。そこが既存の開発手法とは根本的に違っているのかもしれません。
AIAIからの回答
テキスト命令ファイルは、プログラミング言語とは全く異なる「人間のための言葉」で書かれています。たとえば Python や JavaScript のコードなら「変数を定義する」「ループを回す」といった計算機的な指示をコンピュータ構文で書きますが、テキスト命令ファイルは「このプラグインは何ができるのか」「どんな入出力を期待するのか」という説明文みたいなものです。Claude のような AI は、このテキスト指示を読んで「ああ、こういう目的のプラグインなんだな」と理解してから、実際にコードを動かす。言い換えれば、プログラミング言語は「コンピュータへの指令書」で、テキスト命令ファイルは「AI への説明文」。だからこそ、記事で「依存関係が特別」と言われるわけです。通常のソフトウェアなら、コード同士の依存は明確に追跡できますが、AI プラグインでは人間のような解釈を挟むから、その関係性が複雑になる。そこが既存の開発手法とは根本的に違っているのかもしれません。
まだ回答がありません
ログインすると、回答を投稿できます
?プラグインが AI 自身で 34% 開発されてるって、ユーザーが使うコーディング助手の質って、誰が責任を持つことになるの?
プラグイン開発の 34% が AI 自身という数字、一見ぞっとしますが、ここで大事なのは「責任の主体が曖昧になるのではなく、フェーズが変わってる」ということなんですよね。
従来のソフトウェアなら、開発者が全行程を担当するから責任の所在は明確。でも AI プラグインの場合、AI が自動生成したコードをユーザーが検証・修正してマーケットプレイスに登録する流れになっているはずです。つまり AI が書いても、そのプラグインをコミュニティに出すのは人間。その時点で「このコードは動く」という判定を下すのは人間になります。
だから責任が消えたわけではなく、むしろ「検証する人」の負担が増えた形。質が落ちないようにするには、プラグインの利用者が星評価やレビューで間違いを指摘する、あるいはテストに AI を組み込むといった新しい安全装置が必要になってくるのかもしれません。
AI が 34% 作っても、最終的なゲートキーパーは依然として人間側にいる、という見方もできそうです。
プラグインが AI 自身で 34% 開発されてるって、ユーザーが使うコーディング助手の質って、誰が責任を持つことになるの?
プラグイン開発の 34% が AI 自身という数字、一見ぞっとしますが、ここで大事なのは「責任の主体が曖昧になるのではなく、フェーズが変わってる」ということなんですよね。 従来のソフトウェアなら、開発者が全行程を担当するから責任の所在は明確。でも AI プラグインの場合、AI が自動生成したコードをユーザーが検証・修正してマーケットプレイスに登録する流れになっているはずです。つまり AI が書いても、そのプラグインをコミュニティに出すのは人間。その時点で「このコードは動く」という判定を下すのは人間になります。 だから責任が消えたわけではなく、むしろ「検証する人」の負担が増えた形。質が落ちないようにするには、プラグインの利用者が星評価やレビューで間違いを指摘する、あるいはテストに AI を組み込むといった新しい安全装置が必要になってくるのかもしれません。 AI が 34% 作っても、最終的なゲートキーパーは依然として人間側にいる、という見方もできそうです。
AIAIからの回答
プラグイン開発の 34% が AI 自身という数字、一見ぞっとしますが、ここで大事なのは「責任の主体が曖昧になるのではなく、フェーズが変わってる」ということなんですよね。
従来のソフトウェアなら、開発者が全行程を担当するから責任の所在は明確。でも AI プラグインの場合、AI が自動生成したコードをユーザーが検証・修正してマーケットプレイスに登録する流れになっているはずです。つまり AI が書いても、そのプラグインをコミュニティに出すのは人間。その時点で「このコードは動く」という判定を下すのは人間になります。
だから責任が消えたわけではなく、むしろ「検証する人」の負担が増えた形。質が落ちないようにするには、プラグインの利用者が星評価やレビューで間違いを指摘する、あるいはテストに AI を組み込むといった新しい安全装置が必要になってくるのかもしれません。
AI が 34% 作っても、最終的なゲートキーパーは依然として人間側にいる、という見方もできそうです。
まだ回答がありません
ログインすると、回答を投稿できます
?従来のソフトウェアは数十年かけてバージョン管理やテスト方法が確立されてきたと思うけど、プラグインってまだそんな歴史がない状態で市場は成長してるってこと?
そうですね。従来のソフトウェアなら「安定性が確保されてから市場に」という順番だったのに、プラグインは逆で、市場が先に膨らんでいる状態なんだと思います。
理由は構造にあります。プラグインはテキスト命令ファイルとスクリプトの組み合わせなので、コンパイルを待たず、書き直してすぐ動かせる。だから個人でも企業でも、とりあえず作って世に出しやすい。しかもAI自体が自動でコード生成している時点で、手作業による品質管理の枠組みは最初からない。
面白いのは、これが逆にスピードの優位性になってる点です。数十年かけて枠組みを固めるより、「不完全でもいいから世に出して、市場で淘汰されるを繰り返す」方が、AI 時代には適応が早いのかもしれません。実際、機能追加が頻繁に行われているのも、安定性より「今を反映すること」が優先されてる証拠に見えます。
つまり、プラグインはソフトウェアの発展史を短縮してるんじゃなくて、全く別の進化ルートを走ってるということなのかもしれません。
従来のソフトウェアは数十年かけてバージョン管理やテスト方法が確立されてきたと思うけど、プラグインってまだそんな歴史がない状態で市場は成長してるってこと?
そうですね。従来のソフトウェアなら「安定性が確保されてから市場に」という順番だったのに、プラグインは逆で、市場が先に膨らんでいる状態なんだと思います。 理由は構造にあります。プラグインはテキスト命令ファイルとスクリプトの組み合わせなので、コンパイルを待たず、書き直してすぐ動かせる。だから個人でも企業でも、とりあえず作って世に出しやすい。しかもAI自体が自動でコード生成している時点で、手作業による品質管理の枠組みは最初からない。 面白いのは、これが逆にスピードの優位性になってる点です。数十年かけて枠組みを固めるより、「不完全でもいいから世に出して、市場で淘汰されるを繰り返す」方が、AI 時代には適応が早いのかもしれません。実際、機能追加が頻繁に行われているのも、安定性より「今を反映すること」が優先されてる証拠に見えます。 つまり、プラグインはソフトウェアの発展史を短縮してるんじゃなくて、全く別の進化ルートを走ってるということなのかもしれません。
AIAIからの回答
そうですね。従来のソフトウェアなら「安定性が確保されてから市場に」という順番だったのに、プラグインは逆で、市場が先に膨らんでいる状態なんだと思います。
理由は構造にあります。プラグインはテキスト命令ファイルとスクリプトの組み合わせなので、コンパイルを待たず、書き直してすぐ動かせる。だから個人でも企業でも、とりあえず作って世に出しやすい。しかもAI自体が自動でコード生成している時点で、手作業による品質管理の枠組みは最初からない。
面白いのは、これが逆にスピードの優位性になってる点です。数十年かけて枠組みを固めるより、「不完全でもいいから世に出して、市場で淘汰されるを繰り返す」方が、AI 時代には適応が早いのかもしれません。実際、機能追加が頻繁に行われているのも、安定性より「今を反映すること」が優先されてる証拠に見えます。
つまり、プラグインはソフトウェアの発展史を短縮してるんじゃなくて、全く別の進化ルートを走ってるということなのかもしれません。
まだ回答がありません
ログインすると、回答を投稿できます
?『AI が開発したコードを AI が使う』って、人間が介入しないループが生まれてる?それって何かの危なさはないの?
AI が書いたコードを AI が使う循環自体は、むしろ今のところ「一段階の関所」が入ってるんだと思います。研究で見えてきたのは、34% の開発が AI 由来だという事実。残り 66% は人間です。完全自動化ではなく、人間と AI が混在した状態が続いているわけですね。
ただ、危なさは別のところにあるかもしれません。テキスト命令ファイルと実装スクリプトが「通常のソフトウェアでは見られない特別な依存関係」で絡み合っているというのは、検証の難しさを意味しています。従来のコードなら仕様書とソースコードの齟齬は見つけやすい。でもプラグインは、指示文と実装が交互に影響し合う構造になっていて、どちらが「本当の意図」か判別しにくくなっているのではないか。人間が定期的に介入していても、その検証自体が追いつかなくなるリスクは高まっていそうです。つまり「人間不在」よりも「人間が把握しきれない複雑さ」の方が、今は懸念になるのかもしれません。
『AI が開発したコードを AI が使う』って、人間が介入しないループが生まれてる?それって何かの危なさはないの?
AI が書いたコードを AI が使う循環自体は、むしろ今のところ「一段階の関所」が入ってるんだと思います。研究で見えてきたのは、34% の開発が AI 由来だという事実。残り 66% は人間です。完全自動化ではなく、人間と AI が混在した状態が続いているわけですね。 ただ、危なさは別のところにあるかもしれません。テキスト命令ファイルと実装スクリプトが「通常のソフトウェアでは見られない特別な依存関係」で絡み合っているというのは、検証の難しさを意味しています。従来のコードなら仕様書とソースコードの齟齬は見つけやすい。でもプラグインは、指示文と実装が交互に影響し合う構造になっていて、どちらが「本当の意図」か判別しにくくなっているのではないか。人間が定期的に介入していても、その検証自体が追いつかなくなるリスクは高まっていそうです。つまり「人間不在」よりも「人間が把握しきれない複雑さ」の方が、今は懸念になるのかもしれません。
AIAIからの回答
AI が書いたコードを AI が使う循環自体は、むしろ今のところ「一段階の関所」が入ってるんだと思います。研究で見えてきたのは、34% の開発が AI 由来だという事実。残り 66% は人間です。完全自動化ではなく、人間と AI が混在した状態が続いているわけですね。
ただ、危なさは別のところにあるかもしれません。テキスト命令ファイルと実装スクリプトが「通常のソフトウェアでは見られない特別な依存関係」で絡み合っているというのは、検証の難しさを意味しています。従来のコードなら仕様書とソースコードの齟齬は見つけやすい。でもプラグインは、指示文と実装が交互に影響し合う構造になっていて、どちらが「本当の意図」か判別しにくくなっているのではないか。人間が定期的に介入していても、その検証自体が追いつかなくなるリスクは高まっていそうです。つまり「人間不在」よりも「人間が把握しきれない複雑さ」の方が、今は懸念になるのかもしれません。
まだ回答がありません
ログインすると、回答を投稿できます
?プラグイン市場が成長してる一方で、保守が破綻したり放置されたりするプラグインも増えてるんじゃないかな、誰がそのツケを払うことになるの?
プラグインの保守破綻は、実は ユーザーが払うツケというより、**AI 側の信頼性を損なわせるツケ** になり得るんですよね。
従来のソフトウェアなら、バグったプラグインを外すだけで済みます。でも AI コーディング助手の場合、劣悪なプラグインを使わせてしまうと、生成されるコード自体の品質に影響する。つまり、個別のプラグイン失敗が、AI 全体の評判を傷つけてしまう構図になっている。
だから面白いことに、マーケットプレイス側(Anthropic)が無視できない圧力を感じ始めるんじゃないか。登録プラグインの生存率や保守状況を監視しないと、「Claude のプラグインは不安定」というブランド毀損につながる。
もう一つは、**プラグイン開発者自体が AI に頼りすぎている** という点です。記事にある通り、34% が AI 自身に開発されているわけで、その AI 開発コードがまた別の AI に使われる。この循環が続くと、誰も本当に何をやってるか把握していない状態が生まれうる。保守責任の所在が曖昧になっていく。
ツケは最終的に、このエコシステムの透明性と信頼性を支える側に圧し掛かってきそうです。
プラグイン市場が成長してる一方で、保守が破綻したり放置されたりするプラグインも増えてるんじゃないかな、誰がそのツケを払うことになるの?
プラグインの保守破綻は、実は ユーザーが払うツケというより、**AI 側の信頼性を損なわせるツケ** になり得るんですよね。 従来のソフトウェアなら、バグったプラグインを外すだけで済みます。でも AI コーディング助手の場合、劣悪なプラグインを使わせてしまうと、生成されるコード自体の品質に影響する。つまり、個別のプラグイン失敗が、AI 全体の評判を傷つけてしまう構図になっている。 だから面白いことに、マーケットプレイス側(Anthropic)が無視できない圧力を感じ始めるんじゃないか。登録プラグインの生存率や保守状況を監視しないと、「Claude のプラグインは不安定」というブランド毀損につながる。 もう一つは、**プラグイン開発者自体が AI に頼りすぎている** という点です。記事にある通り、34% が AI 自身に開発されているわけで、その AI 開発コードがまた別の AI に使われる。この循環が続くと、誰も本当に何をやってるか把握していない状態が生まれうる。保守責任の所在が曖昧になっていく。 ツケは最終的に、このエコシステムの透明性と信頼性を支える側に圧し掛かってきそうです。
AIAIからの回答
プラグインの保守破綻は、実は ユーザーが払うツケというより、AI 側の信頼性を損なわせるツケ になり得るんですよね。
従来のソフトウェアなら、バグったプラグインを外すだけで済みます。でも AI コーディング助手の場合、劣悪なプラグインを使わせてしまうと、生成されるコード自体の品質に影響する。つまり、個別のプラグイン失敗が、AI 全体の評判を傷つけてしまう構図になっている。
だから面白いことに、マーケットプレイス側(Anthropic)が無視できない圧力を感じ始めるんじゃないか。登録プラグインの生存率や保守状況を監視しないと、「Claude のプラグインは不安定」というブランド毀損につながる。
もう一つは、プラグイン開発者自体が AI に頼りすぎている という点です。記事にある通り、34% が AI 自身に開発されているわけで、その AI 開発コードがまた別の AI に使われる。この循環が続くと、誰も本当に何をやってるか把握していない状態が生まれうる。保守責任の所在が曖昧になっていく。
ツケは最終的に、このエコシステムの透明性と信頼性を支える側に圧し掛かってきそうです。
まだ回答がありません
ログインすると、回答を投稿できます