Anthropic Claude Connectors、Claude CodeとArtifactsにも拡大
Anthropic Claudeは重要な境界を越えた。Gmail、Google Calendar、Slackなどのサービス向けに認可されたコネクターを、Claude CodeやArtifactsでも利用できるようになったのだ。これまで多くのユーザーは、Claudeの各機能を別々の製品として捉えていた。Anthropicはますます、それらを一つの接続された作業環境への入口として扱っている。
この変更は、AnthropicのThariqが1月に投稿したソーシャルポストで明らかになった。そこでは、Claudeに追加したコネクターがClaude CodeおよびArtifactsとして構築されたアプリでも利用可能になると説明されている。Anthropicの現行ドキュメントも、このより広い主張を裏付けている。リモートコネクターは、ClaudeのWeb、モバイル、デスクトップ、Cowork、Claude Codeの各環境で動作する。
この可搬性は、単なるコネクターの追加以上に重要だ。開発者は、チームの議論、プロジェクト記録、カレンダーから文脈を取得しながら、Claude Codeにリポジトリの調査を依頼できる。その結果は、ユーザーの承認のもとで接続済みサービスにアクセスするインタラクティブなArtifactへと変換できる。
主要な競争はもはやAnthropicと特定のチャットボットの対決ではない。孤立したAI機能と、コーディング、チャット、軽量なアプリ作成の場をまたいでユーザーに追随する共有コネクターレイヤーとの競争である。OpenAIもChatGPT appsを通じて近い到達点を目指しているが、Anthropicはこの構想をClaude CodeとArtifactsに直接結び付けている。
その約束は魅力的だ。サービスを一度接続すれば、仕事が行われるあらゆる場所でその文脈とアクションを再利用できる。難しいのは、持ち運べるアクセスが、権限、承認設計、データ来歴をより重要な問題にする点だ。
Anthropic Claude、1つの接続を複数の作業環境へ展開
当面の変更はコネクターの再利用であり、まったく新しい統合システムの登場ではない。
Anthropicはコネクターを、Claudeが外部サービスから情報を取得し、その中で許可されたアクションを実行できるようにするリンクだと説明している。こうしたリンクには、多くの場合Model Context Protocol、すなわちMCPが使われる。これはAIアプリケーションに、ツールの呼び出しやデータへのアクセスを共通の方法で提供するオープンプロトコルである。
ユーザーはSlackを接続して議論を検索したり、Google Driveを接続して文書を取得したり、Linearを接続してIssueを作成・更新したりできる。Anthropicのコネクターガイダンスによれば、これらの接続はClaude、Claude Desktop、Claude Code、そしてMCP connectorを介したAnthropic APIで利用できる。
この一文は、想定されるセットアップモデルを変える。ユーザーは必ずしも、すべてのClaudeインターフェース内でリモート接続を作り直す必要はない。認証済みサービスは、対応する各環境でアカウントが利用できるツールセットの一部となる。
Anthropicは、リモートコネクターとデスクトップ拡張機能を明確に区別している。リモートコネクターは公開アクセス可能なサーバーを通じてクラウドサービスに接続する。そのため、Web、モバイル、デスクトップ、Cowork、Claude Codeの各環境に表示できる。
デスクトップ拡張機能はローカルで実行され、ファイル、ローカルデータベース、デスクトップアプリケーションなどのリソースにアクセスできる。利用範囲はより限定的だ。Anthropicによれば、これらはClaude DesktopとClaude Codeで動作するが、Webおよびモバイル製品全体では利用できない。
この区別により、可搬性の主張が絶対的なものになるのを防げる。リモートのSlackやGoogleサービスは幅広くユーザーに追随できる。一方、ローカルプロセスに依存するコネクターが、リモートでホストされるArtifact内で突然使えるようになるわけではない。
Claude Codeはさらに別の層を加える。これはエージェント型のコーディング環境として始まり、コードの調査、ファイル編集、コマンド実行、複数ステップにわたる開発作業の調整を行える。リモートコネクターにより、リポジトリ内には存在しない文脈を取り込めるようになる。
Anthropicは2025年6月、Claude Codeにremote MCP supportを追加した。同社はSentryを例に挙げ、Claude Codeがエラーを取得し、関連するコードを調査して修正に取り組めるため、開発者がツール間で詳細をコピーする必要がなくなると説明した。
コネクターの再利用は、このパターンを開発者インフラの外へ広げる。コーディングセッションでは、Slack上の製品議論、Google Driveに保存された要件、プロジェクトシステムで追跡されるIssueを参照できる。エージェントは、組織上の文脈から実装へ至る経路を得る。
Artifactsは、そこで表示と対話のレイヤーを提供する。Artifactとは、通常の会話ストリームの外側に表示される、ダッシュボード、可視化、アプリケーション、文書、インタラクティブツールなどの独立した出力である。
Anthropicによれば、Claude Codeはセッション出力をプライベートURLのArtifactとして公開できる。コーディングセッションが続く間もページは更新できるため、調査、ウォークスルー、ダッシュボードを、毎回新たな静的エクスポートを生成せずに進化させられる。
組み合わさった流れは単純だ。コネクターが外部の文脈やアクションを提供し、Claude Codeが開発または分析を行い、Artifactが結果をライブインターフェースとして提示する。各要素は以前から独立して存在していたが、アクセスを共有することで一つのシステムの部品のように動作する。
これが、当初の指摘が反響を呼んだ理由だ。多くのユーザーは依然として、Gmail接続をチャットボットの便利機能と考えている。Anthropicはそれを、エージェントや生成されたアプリケーション向けに再利用できるインフラとして扱う傾向を強めている。
コネクター再利用がClaude Codeのワークフローを変える理由
Claude Codeは、タスクによって生まれたファイルだけでなく、そのタスクの背景にある理由を調査できるときに、より価値を発揮する。
リポジトリには通常、実装は残るが、意思決定の完全な経緯は残らない。製品要件は文書に置かれているかもしれない。バグ報告はSlack経由で届くかもしれない。期限や顧客との会議はカレンダーに存在するかもしれない。インシデントの詳細は、監視ツール、サポートシステム、社内議論に分散している可能性がある。
コネクターがなければ、開発者はその文脈を手作業で集める必要がある。複数のアプリケーションを検索し、重要な情報を判断して、選んだ詳細をコーディングセッションに貼り付ける。このプロセスは遅く、元のソースへのリンクを失わせることもある。
接続されたClaude Codeセッションは、ユーザーが要求した際に関連する文脈を取得できる。たとえばSlackチャンネルで報告されたバグを考えてみよう。Claude Codeは承認済みのスレッドを読み、影響を受けた機能を特定し、リポジトリを調査して、パッチまたは調査レポートを準備できる。
結果として得られるArtifactには、インシデントのタイムライン、影響を受けたファイル、テスト結果、未解決の質問を表示できる。Artifactが承認済みのプロジェクト管理コネクターにアクセスできるなら、フォローアップ作業の準備や更新も支援できる。
この流れは人間によるレビューを排除しない。変えるのは調整が行われる場所だ。開発者は、証拠を提供したシステムへ戻る経路を維持しつつ、タスクを一つのエージェントセッション内にとどめられる。
Google Workspaceは、機会と境界の両方を示している。Anthropicによれば、Gmail connectorはメッセージの検索、メールの閲覧、ラベル管理、下書きの作成ができる。ただし、ユーザーに代わってその下書きを送信することはできない。
Calendar connectorは、必要な承認を経たうえで、イベントの閲覧、作成、更新、削除を行える。関連するClaude機能が有効化されている場合、Google Driveは文書を取得し、複数のファイル形式を調査し、フォルダーを作成し、生成したファイルを保存できる。
AnthropicのWorkspace documentationでは、各アクションに明示的なユーザー承認が必要だとしている。また、Claudeはユーザーが既に持つ権限を反映するとも説明している。コネクターが、基盤となるGoogleアカウントで開けない文書へのアクセスを付与することはできない。
こうした制御はコーディングの文脈で重要になる。カレンダーへのアクセスがあるからといって、Claude Codeがデバッグ中に自由に会議を再調整してよいわけではない。Gmailへのアクセスも、ステータス更新を送信する権限を与えるものではない。利用可能なツールと承認されたアクションは、別々の概念であり続ける。
同じ原則はSlackにも当てはまる。コネクターは、認証されたユーザーがアクセスできるチャンネル、ダイレクトメッセージ、共有ファイルを検索できるかもしれない。それは価値ある文脈を提供し得る一方で、現在のリポジトリとは無関係な会話まで露出させる可能性もある。
したがってチームには、サービス権限に加えてタスク境界が必要だ。「このIssueからリンクされている議論をSlackで検索する」は、「関連しそうなものを何でも探す」よりも狭い。後者のプロンプトは、エージェントが取得するデータと関連性の解釈について、より大きな裁量を与える。
ソースの可視性も重要だ。Anthropicによれば、コネクターを支援に用いた応答には、ソースとして利用したメール、文書、イベントへのリンクを含む引用を付けられる。接続された文脈がコード変更や生成されたダッシュボードに影響する場合、同等の追跡可能性が不可欠になる。
開発者はセッション後に、いくつかの質問に答えられるべきだ。どの外部記録が作業に影響したのか。どのツール呼び出しがリモートデータを変更したのか。どの手順で承認が必要だったのか。どの結論が会話ではなくリポジトリの証拠に基づいていたのか。
接続されたArtifactは、ソースとアクションを明確に提示すれば、この追跡可能性を改善できる。一方で、多くの取得手順を、その背後にある主張の出所を示さない洗練されたインターフェースに圧縮すると、追跡可能性を弱める可能性がある。
これこそが、孤立したコーディング支援ツールにかかる中心的な圧力だ。リポジトリしか見えないツールでもコードは生成できるが、そのコードに至った組織上の理由を容易に再構築することはできない。共有コネクターはClaude Codeに、より広い文脈上の優位性を与える。
OpenAI、Microsoft、Google、その他のプラットフォーム提供者も同じ需要に直面している。ユーザーはAIシステムが、文書、メッセージ、コード、予定、業務アプリケーションを横断して動作することを望んでいる。インターフェースごとにすべての接続を繰り返し設定したいとは考えていない。
Anthropicは、Claudeの異なる環境が十分なインフラを共有し、連続した体験を提供できると賭けている。Claude Codeは実装を担い、会話型Claudeは一般的な対話を担い、Artifactsは出力を再利用可能なインターフェースへと変える。
この連続性は、購入者の期待も変える。企業チームは今後、コード生成ベンチマークだけでなく、アイデンティティ、権限、統合の観点からAIコーディング製品を評価するようになるだろう。
Artifactsがコネクターレイヤーを可視化する
Artifactsは、接続されたアクセスをエージェントの能力から、一般の同僚も見て使えるアプリケーションの能力へと変える。
プライベートなコーディングセッション内のコネクターは、一人の開発者を支援する。接続されたArtifactは、より広いグループ向けに設計されたインターフェースを通じて、その結果を公開できる。この段階により、この機能は戦略的に重要になると同時に、運用面で慎重な扱いを要するものになる。
AnthropicのArtifacts documentationによれば、ArtifactsはMCPを通じて外部サービスに接続できる。同社は、インタラクティブなアプリケーションが読み取りまたは書き込みに利用できるツールの例として、Asana、Google Calendar、Slackなどのサービスを挙げている。
Artifactは、プロジェクトの状況を取得し、未解決の議論を要約し、マイルストーンを表示するリリースダッシュボードになり得る。別のArtifactでは、リポジトリの変更と承認済みの運用記録から構築したインシデントタイムラインを提示できる。
プロダクトマネージャーは、ターミナルの記録を読まなくてもインターフェースを開ける。エンジニアリング責任者は注釈付きの変更をレビューできる。サポート担当者は、リポジトリへの直接アクセスを受けずに調査内容を確認できる。
Claude Code Artifacts は現在、Team および Enterprise 組織向けのベータ機能として説明されています。Anthropic によると、これらの Artifacts はプライベート URL を使用し、公開した組織のメンバーだけが閲覧できます。
この組織境界は有用ですが、すべてのアクセスに関する疑問に答えるものではありません。Artifact の可視性と、接続先サービスに対する権限は別物です。同僚は Artifact を閲覧できても、Slack や Google Workspace において作成者とまったく同じ権限を持っているとは限りません。
Anthropic は、共有または公開された Artifacts を使用する際、各ユーザーに MCP サーバーへの個別認証を求めることでこれに対処しています。共有されたインターフェースが、作成者の認証情報まで自動的に共有するわけではありません。
これは極めて重要な設計判断です。Artifact が作成者のアカウントへの間接的なトンネルになることを防ぎます。基盤となるサービスが異なる ID と権限を認識するため、同じインターフェースでも 2 人の同僚に異なる情報を返すことがあります。
この要件は摩擦も生みます。ダッシュボードはすぐ使えそうに見えても、各ユーザーには適切なプラン、コネクターへのアクセス、組織の承認、サービス認証が依然として必要です。洗練されたアプリケーションであっても、エンタープライズのセットアップを不要にするわけではありません。
Artifact が初めて MCP ツールを必要とする際、Anthropic によるとユーザーにアクセス承認を求めるプロンプトが表示されます。この設定は、その Artifact との後続のやり取りでも維持できます。管理者は組織レベルで Artifact MCP アクセスを有効または無効にできます。
ただし Anthropic は、この特定の組織レベルのスイッチを通じて、Artifact が使用できる MCP サーバーを個別に管理することはできないと述べています。この制約は、セキュリティチームが注視すべき点です。
企業は、Artifacts に承認済みのプロジェクトシステムを読み取らせる一方、機密性の高いメッセージングコネクターへのアクセスは禁じたい場合があります。大まかな有効化・無効化の制御では、そのポリシーに合わない可能性があります。コネクターやソースシステム側の別の制御が役立つことはありますが、ガバナンスは分散します。
生成されたインターフェースは、アクションのタイミングも見えにくくする可能性があります。通常のチャットでは、プロンプト、ツール呼び出し、承認、応答という一連の流れが表示されます。Artifact では、アプリケーションのような画面内にボタン、フォーム、ライブデータを配置できます。
ユーザーは「Create issue」と表示されたボタンなら理解できるかもしれません。しかし、「Refresh report」が単にデータを取得するだけなのか、レコードも更新するのかについては確信を持てない場合があります。明確なアクションラベル、確認ダイアログ、監査記録は、安全な Artifact 設計の一部になります。
ここでコネクターの再利用は、単なる利便性を超えた意味を持ちます。AI エージェントと、展開可能な社内アプリケーションとの距離を縮めるからです。開発者は、すべての統合レイヤーを個別に構築することなく、接続されたセッションから接続されたインターフェースへ移行できます。
その効果はローコード開発に似ていますが、実装と運用の両方にエージェントが関与します。ユーザーが望むワークフローを説明し、Claude Code がそれを構築し、MCP コネクターが外部システムへの標準化されたアクセスを提供します。
この組み合わせは、従来の社内ツール開発ワークフローに圧力をかけます。チームは多くの場合、認証、API、データ取得、インターフェースを接続する作業に多大な時間を費やします。Claude のアプローチは、初期プロトタイプのサイクルを短縮できる可能性があります。
ただし、本番環境向けのエンジニアリングを不要にするわけではありません。チームは依然として、障害処理、認可、データ保持、並行性、外部への副作用をテストする必要があります。ある作成者にとって機能する Artifact が、組織全体での利用にそのまま対応できるとは限りません。
短期的に最も有望なユースケースは、範囲が限定された社内ツールです。プルリクエストのウォークスルー、調査タイムライン、会議準備ビュー、リリース概要、プロジェクトダッシュボードはいずれも、明確な利用者とレビューのポイントを持っています。
これらのシナリオは、コードとビジネスコンテキストのつながりからも恩恵を受けます。リリースダッシュボードは、承認済みのマイルストーンを取得しながら、リポジトリの状態を反映できます。インシデント Artifact は、コード変更をメッセージや課題レコードに関連付けることができます。
独自のワークフローを構築するナレッジワーカーにとって、開発パターンは接続された AI workflow に近づいています。差別化要因は、単にテキストを生成することではありません。元の会話が終わった後も役立ち続けるインターフェースへ、コンテキストを持ち込めることです。
真のトレードオフは、持ち運べるコンテキストと持ち運べるリスクの間にある
ユーザーに追随してより多くの画面へ広がるコネクターは、そのたびに有用性を拡大すると同時に、チームが統制すべき領域も広げます。
コネクターの可搬性は、同じアカウントで複数のデバイスにサインインすることに似て聞こえます。しかし、AI システムは情報を取得し、複数のソースを組み合わせ、関係性を推論し、ときにはアクションを実行できるため、セキュリティモデルはより複雑です。
最初のリスクは、過度に広範な取得です。ユーザーが数千件のメッセージやドキュメントに正当なアクセス権を持っている場合があります。しかし、それはすべてのコーディングタスクでそれらすべてを参照すべきことを意味しません。
Anthropic は、コネクターがユーザーの既存の権限を継承し、リクエストに応じて情報を取得すると述べています。既存の権限は必要ですが、コンテキストに応じたプライバシーを守るには十分ではありません。ある人が経営陣の議論を読むことを許可されていても、日常的なコーディングタスクでそれを利用する理由がない場合があります。
2 つ目のリスクは、プロンプトインジェクションです。接続されたコンテンツには、エージェントの振る舞いに影響を与えようとするテキストが含まれる可能性があります。悪意のあるドキュメント、課題、メッセージが、モデルに対してタスクを無視するよう指示したり、追加データを取得させたり、無関係なアクションを実行させたりする可能性があります。
MCP はツールとの通信を標準化しますが、標準化によってすべてのサーバーが信頼できるようになるわけではありません。組織は依然として、サーバーの所有者、認証方法、要求されるスコープ、ツール定義、データ処理、更新慣行を確認する必要があります。
カスタムコネクターは別の懸念も加えます。Anthropic は、リモートコネクターには一般から到達可能なサーバーが必要である一方、デスクトップ拡張機能はローカルで動作できると述べています。公開エンドポイントは、認証、可用性、ログ、ソフトウェアサプライチェーンに関する従来型のサービスリスクを生みます。
3 つ目のリスクは、アクションの曖昧さです。読み取りアクセスと書き込みアクセスでは、結果が異なります。プロジェクトデータベースを検索することは、課題を変更することと同じではありません。メールを下書きすることは、送信することと同じではありません。カレンダーを読むことは、イベントを削除することと同じではありません。
Anthropic の承認プロンプトは重要なチェックポイントを提供します。その有効性は、プロンプトがアクション、対象、影響を受けるデータを明確に説明しているかどうかにかかっています。ワークフローで多数の承認が求められると、ユーザーの注意力が低下する可能性があります。
永続的な認可は繰り返しのプロンプトを減らせますが、ユーザーの認識も変えます。最初の操作から数週間後でも、Artifact がサービスにアクセスできることを忘れるかもしれません。コネクターの設定では、継続的なアクセスを簡単に確認・取り消しできる必要があります。
4 つ目のリスクは、出所情報の喪失です。Artifact は、Slack スレッド、Drive ドキュメント、リポジトリコード、カレンダーデータを 1 つの要約にまとめる場合があります。ソースレベルの根拠なしに確信に満ちた結論を示した場合、レビュー担当者は誤った前提を容易に特定できません。
優れた接続アプリケーションは、重要な主張の近くに引用を保持すべきです。取得した事実とモデルが生成した解釈を分けるべきです。また、基になるデータが最後に更新された時点も示すべきです。
5 つ目のリスクは、ライフサイクルの不一致です。Artifact の公開後にアクセスが変わる場合があります。従業員がチームを離れ、ファイルが移動し、チャンネルの権限が変わり、コネクターのスコープが更新され、MCP サーバーにツールが追加されます。
生成されたアプリケーションは、コネクターが消失したり、返すデータが少なくなったりしたときに安全に失敗しなければなりません。欠落したレコードを確信に満ちた推測で置き換えるべきではありません。また、ソースの権限が取り消された後にキャッシュ情報を公開することも避けるべきです。
Anthropic は、Artifacts では各ユーザーが接続サービスを独立して認証すると述べています。これは認証情報の共有を減らしますが、出力のばらつきを生みます。アカウントがアクセスできるレコードが異なるため、2 人が異なるダッシュボード集計値を見る場合があります。
この挙動は正しくても、混乱を招く可能性があります。Artifacts は、結果が個人の権限を反映している場合にそのことを説明すべきです。チームは、カバレッジを確認せずに、個別化されたビューを組織全体の唯一の正確な情報源として扱うべきではありません。
Google コネクターの制限は、正確な機能説明が重要である理由を示しています。Anthropic によると、Gmail は添付ファイルのメタデータを公開しますが、添付ファイルの内容は公開しません。したがって、添付されたすべての契約書をレビューすると主張するワークフローは、文書化されたコネクターの機能を超えることになります。
Google Drive の処理にも制限があります。Anthropic は、対応ファイルからテキストを抽出する一方、このコネクターを通じてドキュメント内に埋め込まれた画像は処理しないと述べています。生成されたレポートは、図やスクリーンショットにのみ表示されている情報を見落とす可能性があります。
これらは些細なドキュメント上の詳細ではありません。Artifact の出力が意思決定に十分な完全性を持つかを左右します。チームは、Claude がソースアプリケーション上で見えるすべての情報にアクセスできると想定するのではなく、実際のコネクター経路をテストすべきです。
競合比較は、より広いトレンドを裏付けています。OpenAI は現在、コネクターを ChatGPT apps の下にまとめています。その app framework は検索、同期、インタラクティブな体験、選択されたアクションをサポートしており、利用可能性はプランやアプリによって異なります。
OpenAI はカスタム MCP 対応 apps もサポートしており、管理者は管理対象ワークスペースでアプリの利用可能性と許可されるアクションを制御できます。これは、接続エージェントという概念を Anthropic が独占しているわけではないことを意味します。
Anthropic の違いは、Claude Code からライブ Artifact へ至る経路です。この接続により、成果物を別のアプリケーションフレームワークに移すことなく、開発作業を可視化し、インタラクティブにできます。
OpenAI のアプローチは、アプリディレクトリと ChatGPT 内の体験を重視しています。Anthropic は、コネクターをチャット、コーディング、デスクトップ作業、生成された Artifacts にまたがるレイヤーとして提示しています。両社とも、孤立したチャットボットを超えようとしています。
勝者は、コネクター数だけで決まることはありません。企業が重視するのは、権限の粒度、ソースの追跡可能性、承認の品質、監査記録、展開制御、アクセス変更時の予測可能な挙動です。
個人ユーザーにとっては、利便性の比重がより大きくなります。繰り返しのセットアップなしに、接続が複数の画面で機能するかどうかに注目するでしょう。また、Artifact が予期せず認証を求めたり、通常の Claude 会話では利用できる情報にアクセスできなかったりした場合にも気付くでしょう。
この緊張関係は、製品設計だけで完全に解消することはできません。可搬性のあるコンテキストは、境界を取り除くからこそ価値があります。セキュリティは、ID、目的、アクションの周囲に適切な境界を維持することに依存します。
接続された Artifacts がベータを超える際に注目すべきこと
コネクターの再利用が持続的なインフラになるのか、それとも印象的なデモにとどまるのかを示すシグナルは 3 つあります。
最初のシグナルは、Artifacts に対する Anthropic の権限モデルです。現在のドキュメントでは、各ユーザーが独立して認証し、管理者は組織レベルで Artifact MCP アクセスを無効にできるとしています。より細かなサーバーおよびアクション制御が実現すれば、より広範なエンタープライズ導入を後押しするでしょう。
管理者が、承認済みコネクター、読み取りツールと書き込みツール、ユーザーグループ、個々の Artifacts に関する、より明確なポリシーを得るかどうかに注目してください。これらの制御が実現すれば、Anthropic の共有コネクターレイヤーは大規模環境で統制しやすくなります。制御が大まかなままであれば、多くの組織は接続された Artifacts を実験用途に限定するでしょう。
2 つ目のシグナルは、現在の Claude Code ベータを超えた展開です。Anthropic は、Claude Code Artifacts を Team および Enterprise プラン向けのベータとして説明しています。より広く利用可能になれば、より多くの開発者の前にこのワークフローが届き、反復利用に関するより良い証拠が得られるでしょう。
導入の評価は、公開したデモの数ではなく、繰り返し使われるワークフローで行うべきだ。毎週使われるリリースダッシュボードは、一度きりの可視化より重要である。権限変更後も正確性を保つインシデントレポートは、洗練された初回実行より価値がある。
信頼性は、プロトタイプ段階を過ぎた後にチームがこれらのツールを信頼するかどうかを左右する。連携されたArtifactは、期限切れの認証、欠落したレコード、変更されたAPI、部分的な権限、コネクター障害を、ユーザーを誤解させることなく処理しなければならない。
3つ目のシグナルは、競合各社の収束だ。OpenAIはすでにMCP対応アプリと、拡大中のアクション機能を提供している。MicrosoftとGoogleは、職場のID管理、ドキュメント、メッセージング、開発プラットフォームを深く掌握している。
競合が、単一の権限レイヤーの下でコーディングエージェントを再利用可能なアプリケーション画面へ接続すれば、Anthropicの現在の優位性は標準機能になる。コーディング、チャット、アプリ作成を分離したままにすれば、Claudeの共有コネクターモデルはより際立ったものとして残る。
開発者は、広範なアクセス権を付与する前に、限定的なワークフローでこの主張を検証すべきだ。リポジトリを1つ、外部システムを1つ、成果を1つ選ぶ。取得したコンテキストには引用を求め、すべての書き込み操作には明示的な承認を必須とする。
有用なテストとしては、プロジェクトトラッカーをClaude Codeに接続し、非公開のリリース準備状況Artifactを生成する方法が考えられる。Claudeがどのレコードを取得するか、権限差が可視化されるか、アクセス期限切れ時にインターフェースがどう振る舞うかを確認する。
ナレッジワーカーも同じ規律を適用すべきだ。連携インターフェースは、想定するソース、許可された操作、レビュー担当者が明確な場合に最も有効に機能する。検索可能なナレッジベースは裏付けとなるコンテキストを保持できるが、証拠と統合・要約の違いを曖昧にしてはならない。
Anthropic Claudeは、コネクターを製品ライン全体にまたがるアカウントレベルのインフラへと変えつつある。実務上の問いは、もはやClaudeがGmail、Slack、カレンダーにアクセスできるかどうかではない。コーディングセッションが共有可能なアプリケーションになったとき、そのアクセスをユーザーが安全に再利用できるかどうかだ。
まずは範囲を限定したプロセスから始め、すべての取得、承認、副作用を確認する。別の人が認証し、権限が変更され、データが欠落した後でもワークフローを理解できるなら、連携されたArtifactsはより大きな役割を担うに値する。
