Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】The row that replaces nothing: how SharpOS connects a client's accounts without owning them

2026年09月07日に「Dev.to」が公開したITニュース「The row that replaces nothing: how SharpOS connects a client's accounts without owning them」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

SharpOSは、顧客が既存のGoogleなどのアカウントを「所有」せずに「接続」して利用できるサービスだ。これにより、アカウントの所有権は常に顧客に残り、代理店とのトラブルを防ぐ。SharpOSは顧客のアカウント内で自動化やエージェントを安全に動作させ、ビジネス連携を支援する仕組みを提供する。

ITニュース解説

システムエンジニアを目指す皆さんにとって、現代のビジネスシステム開発では、さまざまなサービスを連携させる「インテグレーション」の知識が非常に重要になる。今回解説するSharpOSの事例は、このインテグレーションにおいて、一般的なアプローチとは異なる非常に賢明な設計思想を持っているため、ぜひ学んでほしい。

IT業界では、ウェブ広告の運用を代行するエージェンシーと、そのサービスを利用する企業(クライアント)の間で、Google広告などのアカウントの所有権を巡るトラブルが頻繁に発生している。エージェンシーがクライアントのアカウントへのアクセスを拒否したり、許可なく請求情報の所有者になってしまったりするケースが後を絶たないのだ。このような問題が起こると、クライアントは自分のビジネスにとって非常に重要な資産であるアカウントを失うか、その管理権を奪われた状態に陥ってしまう。理想的な形は、ビジネスオーナーであるクライアントがアカウントの完全な所有権を持ち、エージェンシーは「管理者」としてそのアカウント内で作業を行うことだ。SharpOSは、まさにこの理想的な関係性を実現するための接続方法を提案している。

多くのSaaS(Software as a Service)製品は、「すべてを一つに」というコンセプトで、カレンダー、メール、メッセージング、フォームなど、さまざまな機能を自社サービス内で提供しようとする。これは「置き換え」のアプローチであり、例えば社内用のタスク管理ツールを別のツールに置き換えるのであれば問題ない。しかし、Googleカレンダー、メール配信サービス、WhatsAppの電話番号、AIモデルアカウントといったものは性質が異なる。これらはクライアントのビジネス全体で共有され、過去の重要な履歴を持ち、顧客とのやり取りの基盤となっている。もしSharpOSのようなサービスがこれらのアカウントを「置き換える」と主張する場合、それはGoogleカレンダーをゼロから再構築するという非効率なことをしているか、あるいはクライアントのアカウントを静かに自社の管理下に移動させているかのどちらかになる。後者は、前述のアカウント所有権を巡るトラブルで起きる「ホスト状態」と本質的に同じであり、単にUIが改善されているだけの危険な状況を生み出す可能性がある。

そこでSharpOSが採用しているのが「接続(Connect)」というアプローチだ。これは「置き換え(Replace)」とは根本的に異なる。クライアントは引き続きGoogle、Cal.com、Resend、Metaなどのサービスに対して料金を支払い、アカウントの所有権を保持する。SharpOSは、クライアントの特定の組織に対して「行動する許可(grant)」を得るだけだ。この許可は範囲が限定され、いつでも取り消すことができる。接続は「許可」であり、置き換えは「所有権の移転」なのである。

SharpOSの「Integrations(連携)」機能は、ハブの中の一つのページとして提供されており、管理者権限を持つユーザーのみがアクセスできる。管理者はカード形式で表示されたプロバイダーの中から接続したいサービスを選択する。OAuth(Open Authorization)を使用するプロバイダー(Googleなど)の場合、クライアントはプロバイダーが提供する同意画面でSharpOSへのアクセスを許可する。APIキーを使用するプロバイダー(Resend、ElevenLabs、OpenAIなど)の場合は、ダイアログにAPIキーを入力する形になる。一度接続が有効になると、そのプロバイダーの機能やトリガー(特定のイベント発生を検知する仕組み)は、オートメーション機能、REST API、そしてエージェントが使用するMCPサーバーという三つの利用元で即座に利用可能となる。

現在SharpOSが対応しているのは、Googleカレンダー、Googleシート、Google Search Console、Googleアナリティクス、Google広告、Googleマップ、Reddit、Hashnode、Dev.to、Resend、Facebookページ、WhatsApp、ElevenLabs、Cal.comなど多岐にわたる。さらに、Instagram、X(旧Twitter)、LinkedIn、GitHubといったソーシャルプロバイダーや、OpenAI、OpenRouterのようなAIプロバイダーもサポートしている。

この接続の仕組みは、クレデンシャルブローカー「Composio」というサービスによって実現されている。SharpOSは、プロバイダーから受け取ったOAuthトークンやAPIキーといった認証情報を直接保存しない。代わりに、Composioがこれらの認証情報を組織ごとに厳密に管理する。SharpOSが保存するのは、「どのプロバイダーに、どの組織が、どのような状態(接続中、アクティブ、無効、失効済み)で接続しているか」という接続記録と、「どのアカウントとして動作しているか」という情報だけだ。オートメーションが実行される際、バックエンドは該当する組織のアクティブな接続情報をComposioからロードし、その組織としてプロバイダーのアクションを実行する。これにより、ある組織のワークフローが誤って別の組織のカレンダーにアクセスするといった事故は絶対に発生しない。

ただし、AIプロバイダーのカードだけは例外で、OpenAIやOpenRouterのAPIキーは暗号化された状態でSharpOS内に保存される。これは、SharpOSのバックエンドが直接推論処理を実行するためであり、アクションをプロキシするブローカーではストリーミングチャットのような処理を仲介できないためだ。ここでも、キー自体が外部に漏れることはなく、厳重に保護されている。また、誤ったAPIキーが入力された場合、SharpOSはそのキーを使って一度プロバイダーに実際に呼び出しを行う。もし呼び出しが失敗すれば、そのキーは保存されず、接続は拒否される。これにより、無効なキーがアクティブな状態として誤って登録されてしまうことを防いでいる。

トリガー機能も接続ごとに設定されるが、プロバイダーによってはトリガーを提供していない場合もある。例えばGoogleカレンダーのトリガーは接続時に登録され、署名付きのウェブフックを通じてSharpOSにイベントが通知される。Cal.comのようにブローカー経由でトリガーを提供しないプロバイダーに対しては、SharpOSがユニークなアドレスと署名シークレットを生成し、Cal.comのウェブフックに登録することで、予約イベントなどをSharpOSに通知する仕組みを独自に構築している。これにより、特定のプロバイダーのトリガー機能が不足していても、イベントを検知し、オートメーションを起動できる柔軟性を持っている。さらに、これらのイベントは、有効な接続と照合され、過去30日間の重複イベントは排除されるため、「カレンダーイベント作成 → カレンダーイベント作成」という無限ループのような問題も防ぐことができる。

エージェントがプロバイダーのアクションを実行する際には、厳密な入力スキーマが適用される。これは、フィールドのスペルミスのような誤った入力があった場合、それを即座に拒否し、黙って無視しないことを意味する。これにより、「意図しないアカウントに投稿してしまった」といったエージェントの誤動作を防ぎ、安全性を高めている。

SharpOSの「Integrations」機能は、特定のプロバイダーに対しては意図的に制限を設けている。例えば、Reddit、Search Console、Google Analytics、Google Ads、Google Mapsは、利用可能なトリガーを公開していないため、「Xが起きたら」というイベント駆動のオートメーションは構築できない。これらのサービスに対しては、別の方法で対応する必要がある。また、SharpOSはGoogle Adsのレポート機能を提供しておらず、XやLinkedInはブローカー経由ではテキスト投稿のみに対応している。Google Analyticsのレポートも、管理APIのみをカバーするツールキットを使用しているため、リクエストプロキシを介して提供される。そして重要な点として、クライアントに代わってGoogleアカウントなどを接続するRESTエンドポイントは存在しない。接続、切断、プロバイダー選択といった操作は、意図的にハブ(管理画面)上でのみ行えるようになっている。これは、悪意のあるプログラムによる不正な接続を防ぎ、セキュリティを確保するための設計である。

SharpOSは、汎用的な「マーケットプレイス」として何百ものコネクタを提供するのではなく、SharpHawという自社のエンゲージメントに必要な約20のプロバイダーに特化している。これは、SharpOSが「クライアントがすでに所有しているアカウント内で、そのクライアントのオートメーションやエージェントが行動できるようにする」という明確な目的を持っており、その目的の範囲内で機能を停止させることを意味する。もしブローカーサービスが利用できなくなった場合、すべての接続は再認証が必要になるかもしれないが、クライアントのアカウント自体は常にクライアントの管理下にあり続ける。この「アカウントの所有権」こそが、SharpOSが最も重視するポイントなのである。

この「Integrations」機能は、SharpOSのAIオートメーションの基盤となる。Cal.comに予約が入ると、ワークフローがカレンダーを読み取り、クライアントのResendドメイン経由でメールが送信され、WhatsAppのテンプレートで確認メッセージが送られる、といった一連の自動化を可能にする。クライアントはこれらすべてを自分自身のワークスペースで確認できる。そして、クライアントが自分のアカウントを他者に明け渡すよう要求されることは決してない。SharpOSのアプローチは、顧客との信頼関係を最優先し、ITシステム連携における新たな標準を提示していると言えるだろう。

関連コンテンツ

関連IT用語