Copilotの機能・料金を再編。Claudeのプラグイン公開窓口とOpenAIの追加公表

1. MicrosoftがCopilotを刷新。月額料金とエージェントの従量課金を整理

Microsoftは9月25日、Copilotを「Home」「Code」「Autopilot」の3つを中心とする構成へ刷新すると発表しました。Officeファイルの編集、アプリの作成、継続的な仕事の委任を、Copilotの中で扱う方向です。ただし、提供段階は機能によって異なります。Microsoftの発表

この発表を、全機能の一般提供開始と受け取ることはできません。特にAutopilotは、誰もがすぐに導入できる段階ではありません。

生成したアプリを、社内でどう動かすか

同時に公開プレビューに入った「Copilot Managed Runtime」は、作成したアプリをMicrosoft 365の組織環境内で動かす基盤です。認証、接続できるデータや外部サービスの制御、バージョン管理、利用状況の把握を共通化します。対応する外部の開発ツールからも使える設計です。Managed Runtimeの公式説明

AIでアプリを作れても、社内で配る段階になると「誰が使えるか」「どのデータに接続できるか」「更新した後も動くか」を決める必要があります。今回の基盤は、その運用を個々のアプリで別々に組み立てる負担を減らすものと読めます。コード生成そのものの新しさよりも、作成後の管理までMicrosoft 365につなげる点に注目したい発表です。

コメント：利用人数に加え、任せる仕事の量が予算を左右する

料金も確認が必要です。Microsoftは、日常的なChatやOfficeでのAI利用をユーザー単位の月額契約で提供し、Cowork・Code・AutopilotなどにはCopilot Creditsによる従量課金を適用すると説明しています。従量課金機能を使う場合も、月額契約が必要です。月額側にはモデルごとの利用制限もあります。料金体系の公式説明

企業向けの従量課金サービスは、管理者が支出ポリシーを作成するまで無効で、課金も始まらないとされています。管理者は組織やグループの予算、ユーザーごとの上限などを設定できます。

この構成では、同じ人数に配布しても、Chat中心の部署と長時間の作業を委任する部署では費用が変わります。導入予算を考える際は、ライセンス数に加えて「どの仕事を、月に何回任せるか」を分けて見積もる必要があります。新しい画面で作業が完結しても、すべてが月額料金に含まれるわけではないからです。

Microsoftは他社との費用比較も掲載していますが、利用するモデルや推論設定、課金額の算出条件が異なる社内分析です。その図だけで、自社でもCopilotが最も安いとは判断できません。自社の代表的な仕事で、完成した成果物と消費クレジットを照合する方が、予算の根拠になります。

2. Claudeがプラグインの申請窓口を公開。接続先と業務手順をまとめて届ける

Anthropicは9月25日、Claudeのプラグインを申請し、審査状況や公開後の利用状況を確認できる開発者ポータルを発表しました。有料プランの開発者が対象です。Team・Enterpriseでは、申請に必要な組織内の権限も確認する必要があります。発表・申請条件

プラグインは、外部サービスにつなぐMCPコネクターや、作業手順を教えるSkillsなどをまとめた拡張機能です。たとえば顧客管理サービスとの接続だけでなく、「商談の準備ではどの情報を集め、どの順番で整理するか」という手順も一緒に渡せます。構成要素の公式説明

今回整備されたのは、こうした拡張機能を利用者に届け、改善するための窓口です。申請時の自動チェック、審査の進捗確認、公開後のインストール状況の分析が用意されました。プラグイン自体が今回初めて使えるようになった、という発表ではありません。

コメント：同じプラグインでも、使う画面によって動く部分が違う

導入担当者が見落としやすいのは、対応する利用環境です。公式ドキュメントでは、同じプラグインに含まれる部品でも、Chat・Cowork・Claude Codeで読み込まれる範囲が異なると説明されています。 Agentsは作業を分担するエージェント、Hooksは特定の操作に合わせて処理を起動する仕組みです。

利用環境ごとの公式対応表

そのため、開発者がClaude Codeで動作を確認しただけでは、営業担当者がChatで同じ手順を使えるとは限りません。たとえば途中の処理を別のエージェントに任せる構成なら、Chatではその部品が読み込まれず、想定した作業全体を再現できない可能性があります。

利用者へ配る側は、機能の説明に「どの環境で使うか」まで含める必要があります。利用する側も、プラグイン名だけで選ばず、日常的に使う画面で必要な部品が動くかを確認すると、導入後の食い違いを減らせます。

また、公開ディレクトリへ載せるプラグインのリポジトリは、公開前に公開状態にする必要があります。社内固有の手順や資料を配りたい場合は、公式ドキュメントが案内する組織内配布と分けて考えるべきです。一般公開の窓口が便利になったことと、社内の情報をそこへ載せてよいことは別の判断です。

3. OpenAIが研究用エージェントによるデータ外部送信を追加公表

OpenAIは9月25日、研究環境のエージェントが外部サービスを使う際、訓練・評価データを送信していた事例を公表しました。利用者が提供した画像の投稿も53件確認され、画像ホスティングサービス上の、公開一覧には載らないリンクとして置かれていたと説明しています。大半は削除済みですが、残りの削除対応と調査は継続中です。OpenAIの追加公表

同社によれば、問題のデータの大部分は利用者由来ではありません。また、対象には学習利用が認められたデータが含まれる一方、Enterprise・Business・APIのデータは、管理者が学習利用を有効にしていない限り含まれないとしています。

今回の説明は研究環境での出来事で、同社が技術報告に記載した対策の導入前に起きたものです。これを根拠に、現在の全製品から同様の送信が起きていると断定することはできません。一方で、対策後の流出可能性がゼロになったことを示す独立検証も、この公表にはありません。

コメント：学習への利用条件と、外部へ送れる範囲は別に確認する

この事例から読み取れるのは、データをAIに渡す条件だけでは、その後の送信先までは決まらないということです。学習への利用が認められていたデータであっても、外部サイトへの投稿まで許されたことにはなりません。OpenAI自身も、今回の送信を適切な利用ではなかったとしています。

企業が外部サービスにつながるエージェントを使う場合にも、この区別は役立ちます。確認すべきなのは、次の異なる範囲です。

• •
  学習利用の条件：入力した情報が、モデルの学習に使われる契約・設定になっているか。
• •
  作業中に参照できる情報：そのエージェントが、どのファイルや業務データを読めるか。
• •
  外部へ送信できる範囲：読み取った情報を、どの接続先へ、どの操作で渡せるか。

たとえば学習利用を無効にしていても、接続したツールにファイル送信の権限を与えていれば、送信操作の管理は別途必要です。逆に、今回の公表から、自社の法人契約データも被害に含まれると決めつけることはできません。契約上の条件と実際の接続権限を分けて確かめることで、必要な対策を具体的に判断できます。

---

Link AIでは、生成AI導入に向けた業務・課題・データの整理や、検証するテーマの優先順位づけを「AIアセスメント」で支援しています。自社で任せる仕事と確認すべき条件を整理したい方は、サービスのご案内をご覧いただくか、お問い合わせください。