--- Title: "データの先へ：クロスシステム権限同期の悪夢をいかに解決したか" Url: "https://devrev.ai/blog/solving-permission-sync" Published: "2026-03-04" Last Updated: "2026-06-02" Author: "Tilen Kavčič" Category: "Blog, Livestream Learnings" Excerpt: "クロスシステムの権限障害を解消し、信頼性とスケーラビリティを備えたアクセス制御を実現するために、認可アーキテクチャをどのように再設計したかを詳しく解説します。" Reading Time: 6 --- # データの先へ：クロスシステム権限同期の悪夢をいかに解決したか **_Computer AirSyncの背後にあるアーキテクチャと、権限を正しく管理することがセキュアなAI活用の基盤である理由を詳しくご紹介します。_** 私たちが話すすべての企業が、気づいているかどうかに関わらず、同じ問題を抱えています。エンジニアリング向けのJira、セールス向けのSalesforce、ドキュメント向けのGoogle Driveなど、十数もの一流ツールを導入し、それぞれが誰が何を見られるかを制御する独自の複雑な権限ウェブを持っています。これらのツールを[Computer](https://devrev.ai/meet-computer)のようなAIに接続し始めると、その権限ウェブはデータと一緒に移行されません。データは移動する。アクセス制御は移動しない。 その結果、目に見えないセキュリティギャップが生まれます。AIが理論上、ソースシステムの意図に関係なく、誰にでも何でも表示できてしまうシステムです。エンタープライズのバイヤーにとって、それは生産性ツールではありません。受け入れられないリスクです。 私たちがそのギャップをどのように埋めたかをお話しします。 ### 1. はじめに：マルチツール環境における目に見えないセキュリティギャップ すべてのエンジニアには、取り憑かれている問題があります。私のそれは、権限ドリフトという静かに時を刻む時限爆弾でした。そして[DevRev](https://devrev.ai/)では、それは抽象的な問題ではなく、私たちが販売しているものに対する直接的な脅威でした。 私たちのLandモーションはシンプルです。サポートチームやセールスチームに即座に価値を提供することで、Computerを新しいアカウントに素早く導入する。しかし、バイヤーが「Jira、Salesforce、Google Driveを接続したら、誰が何を見られるのか？」と質問した瞬間、そのモーションは崩壊します。信頼できる回答がなければ、Landは成立しません。 私たちは数十の専門ツールにまたがる作業を統合するプラットフォームを構築していました。データの同期は完璧に行えていました。しかし、アクセス権は砂上の楼閣でした。 あるシステムから別のシステムにデータをインポートする際、誰が何を見られ、何を編集できるかという複雑な権限ウェブは、通常そのまま置き去りにされます。これにより生産性を殺す選択を迫られます。数え切れない時間をかけて手動で権限を再作成するか（人的ミスだらけのプロセス）、大規模なセキュリティ脆弱性を受け入れるかです。統合データに安全にアクセスし推論する必要があるAIを導入する企業にとって、これは些細な不便ではありません。ブロッカーです。 DevRevでは、この問題の解決を後回しにできないと認識しました。**これはアーキテクチャの基盤となる要素でなければなりませんでした** — なぜなら、これなしではComputerは信頼されず、Computerが信頼されなければ、Landできないからです。 ### 2. 核心の問題：「権限ドリフト」が単なる煩わしさ以上である理由 異なるシステム間で権限を管理することは、3つの重大な課題をもたらします — そしてそれぞれがセールスサイクルにおける潜在的な反対意見になります： - **手動のオーバーヘッド。**データを新しいシステムにインポートする際、管理者は通常ゼロから権限を再設定することを強いられます。これは労力がかかり、退屈で、ミスが起こりやすい作業です。一つのミスが必要なアクセスをブロックしたり、さらに悪いことに、間違った人にアクセスを付与したりする可能性があります。セキュリティ意識の高いバイヤーはこれを受け入れません。 - **権限ドリフト。**これは、ソースシステムと移行先システムのアクセス権が時間とともに乖離していく、微妙だが危険な現象です。ある従業員がプロジェクトを離れ、Jiraでアクセスが取り消されても、二次システムではアクティブのまま残ります。時間の経過とともに、小さな不一致が予測不能なセキュリティホールとコンプライアンスの悪夢に積み上がります。エンタープライズアカウントにとって、これは契約を破綻させる要因です。 - **セキュリティとコンプライアンスのリスク。**権限を間違えると、財務予測、未発表のプロダクト機能、顧客PIIなどの機密データが、見るべきでないユーザーに露出するリスクがあります。この露出は直接的に、あるいは不適切にセキュリティ保護されたデータをインデックスするエンタープライズ検索や生成AIツールなどの二次システムを通じて間接的に起こりえます。これはまさにComputerが活動する攻撃対象領域です。Computerが誰にでも何でも表示できてしまうなら、それは生産性ツールではなく、負債です。 私たちのLandモーションは、バイヤーが最も機密性の高い部門横断データをComputerに委ねることへの信頼に依存しています。その信頼はここから始まります。 ### 3. 私たちのアプローチ：権限をファーストクラスシチズンとして扱う AirSyncにおける私たちの哲学はシンプルです：**権限はメタデータではない — データそのものの一部である。** AirSyncが外部システムに接続する際、レコードを取得するだけではありません。関連する権限、ユーザー、グループを自動的にインポートし、ほぼリアルタイムで同期を維持します。ソースシステム — Jira、Google Drive、その他のツール — は常に唯一の信頼できる情報源として扱われます。ユーザーのアクセスがそこで変更されれば、その変更はComputerにほぼ瞬時に反映されます。 私たちのアーキテクチャは、異なるシステムがアクセスを管理する多様な方法に対応します： - **オブジェクトタイプレベルの権限。**Jiraの「Browse Projects」権限のような粗粒度の制御で、オブジェクトのコンテナ全体、またはその中の特定のアイテムに適用できます。 - **アイテムごとの権限。**特定のGoogle Docを特定のユーザーと共有するような細粒度の制御で、アクセスはその個別アイテムに固有です。 これにより、Computerのアクセスモデルはソースシステムの完全なミラーとなり、ドリフトと手動オーバーヘッドを排除します。これこそが、Computerを安心して導入できる理由です。 ### 4. 内部構造：ユニバーサル権限トランスレータのアーキテクチャ **4.1. 問題：互換性のないモデルの世界** すべての外部システムは、権限をモデル化する独自のプロプライエタリな方法を持っています。Jiraの「Browse Projects」権限 — プロジェクト内のすべてのイシューに適用される — は、特定のGoogle Docの「Viewer」権限とは概念的にまったく異なります。スケーラブルな解決策は、すべてのシステムに対するハードコードされたロジックを含むことはできません。それは脆くメンテナンス不能な混乱を生みます。私たちには抽象化が必要でした。どんなコネクタでも話せる、権限のためのユニバーサル言語です。 **4.2. 私たちの解決策：Authorization Policyメタオブジェクト** 私たちの答えはAuthorization Policy — 権限のユニバーサルトランスレータとして機能する抽象化レイヤーです。この開発者フレンドリーなメタオブジェクトは、シンプルなポリシーをDevRevネイティブのRole Setsに変換するエンジンである内部のDevRev Loaderにクリーンな入力を提供します。 これにより、コネクタ開発者を内部の権限システムの複雑さから守ります。その深い構造を理解する必要はなく、新しいコネクタを構築する開発者は、外部システムの権限を標準化されたフォーマットで記述するだけです。権限（作成、読み取り、更新、削除）、それが適用されるプリンシパル（ユーザーとグループ）、そしてターゲット（権限が管理するオブジェクト）。 この設計の戦略的根拠は明確でした。コネクタ開発者に内部の権限オブジェクトと直接やり取りさせることも検討しましたが、却下しました。短期的な利便性は、密結合と脆いインテグレーションという長期的なコストに比べれば取るに足りないものでした。クリーンなインターフェースを作成することで、新しいコネクタの構築を根本的に簡素化し、AirSyncエコシステムを拡張可能にし、新しいシステムへの対応をはるかに迅速に追加できるようにしました。新しいコネクタの追加はすべて、Landの新たな理由になります。 **4.3. 同期と更新のライフサイクル** コネクタがAuthorization Policyを提供すると、DevRev Loaderはその抽象ポリシーを具体的なネイティブRole Setsに自動的に、裏側で変換します。 権限ドリフトを防ぐため、スナップショット手法を使用しています。コネクタが差分を検出すると、外部システムの現在の権限状態の完全なスナップショットを提供します。DevRev Loaderはその後、2ステップのプロセスを実行します： 1. 新しいスナップショットに基づいて新しいRole Setsを作成します。 2. 前回の同期に関連するすべての古い権限を削除します。 ![image](https://cdn.sanity.io/images/umrbtih2/production/755c95666ed5a0a46167f7786095fc206f555b8d-2608x522.webp) **_Authorization PolicyのETLプロセスの簡略図。_** この「作成してから削除」のアプローチは、一見乱暴に見えますが、セキュリティとコンプライアンスの観点から戦略的に優れています。新しい状態を先に作成することで、正当なユーザーのアクセスに一瞬の途切れもないことを保証します。そして、ソースシステムで取り消されたアクセスがComputerでも必ず取り消されることを保証します — 古い権限なし、ドリフトなし、セキュリティホールなし。 ### 5. AirSyncの実践：JiraとDevRev間のアクセス管理 理論は素晴らしいですが、本当のテストは実際にどう動作するかです。**[DevRev Liveセッション](https://youtu.be/0Z_W7RXQUMU?si=jGt8cn9YKytFV8bP)で実演した一般的なシナリオを見ていきましょう。** **5.1. シナリオ1：Jiraでのアクセス取り消し** あるユーザーが機密性の高いJiraプロジェクトへのアクセスを持ち、それらのイシューがDevRevに同期されているとします。そのユーザーは作業を確認し、優先度を見て、担当者を確認し、ディスカッションに参加できます。 ![image](https://cdn.sanity.io/images/umrbtih2/production/b206111117127ba4edec925aba19692bed788753-1600x445.webp) _JiraプロジェクトのイシューがDevRev内のカンバンボードに表示され、ユーザーの初期アクセスを反映しています。_ 次に、管理者がJiraの権限スキームに入り、そのユーザーを「Browse Projects」権限を持つグループから削除します。 ![image](https://cdn.sanity.io/images/umrbtih2/production/687c5f529a574c9ce615e5f27a50e1fd9054dd37-1600x327.webp) Jiraの権限スキームのサイドバイサイド表示。変更前はユーザー名が「Browse Projects」権限に存在し、変更後は不在であることを示しています。 AirSyncの定期同期が変更を検出します。DevRevでの手動介入なしに、ユーザーのアクセスがほぼ瞬時に取り消されます。ビューを更新すると、ほんの少し前まで見えていたイシューが消え、「アクセス拒否」メッセージに置き換わります。同期は自動的で、Jiraのグラウンドトゥルースを完全にミラーリングします。 ![image](https://cdn.sanity.io/images/umrbtih2/production/9213c7178396d00397c4cc2a032b2a570e16af09-1600x890.webp) 権限変更後のDevRevでのユーザーのビュー。イシューのリストが空になるか「アクセス拒否」メッセージが表示され、アクセスが取り消されたことを確認しています。 **5.2. さらに一歩進んで：DevRevでの追加権限の付与** 真のコラボレーションには、ソースシステムに存在しないステークホルダーを巻き込むことがしばしば必要です。ここでAirSyncのレイヤードモデルがLandピッチの重要な要素になります。 私たちのモデルは2つの異なる権限レイヤーを作成します。ソースシステムの不変のミラーである基盤レイヤーと、Computer内で直接管理されるオプションの追加レイヤーです。 プロダクトリーダーや営業担当者にJiraのイシューを可視化したいが、Jiraライセンスを付与したりプロジェクトのコア権限を変更したくない場合を考えてください。AirSyncを使えば、そのユーザーをComputer内の対応する同期グループに直接追加できます。これによりComputer内でのアクセスが付与されますが、重要なのは、**Jira自体へのアクセスは付与されないということです。**ソースシステムの整合性は保たれます。部門横断的なコラボレーションが解放されます。 これがプロダクトに組み込まれた拡張モーションです。あるチームでLandし、ソースシステムに触れることなく、安全に隣接するステークホルダーを巻き込む。 ### 6. 成果：エンタープライズ検索とAIのためのセキュアな基盤 これらすべてのアーキテクチャ的な厳密さ — 抽象化レイヤー、スナップショット同期、2ステップの作成・削除 — は一つの目標に奉仕しています。Computerをパワフルなだけでなく、**エンタープライズセーフにすること。** 完全にミラーリングされた信頼できる権限モデルにより、Computerはセキュリティホールを作ることなく、組織の全データ資産にまたがって動作できます。バイヤーがツールを接続する際、すべての従業員が情報を検索しても、ソースシステムを制御するのと同じ権限に基づいて、閲覧を許可されたものだけが表示されることを確信できます。 エンジニアと財務チームのメンバーが同じクエリを実行しても、まったく異なる、そして等しくセキュアな結果を得ます。それは制限ではありません — それが機能です。 これにより、エンタープライズ検索は潜在的なセキュリティリスクから、大規模でセキュアな生産性のレバレッジに変わります。そして、競合他社のどのソリューションよりも優れたセキュリティ上の懸念への回答です。 ### 7. 今後の展望：より深い粒度へ まだ終わりではありません。私たちのロードマップは、特に規制の厳しいセキュリティ意識の高い環境にいるエンタープライズ顧客が今日求めているギャップに対応しています： 1. **フィールドレベルの権限。**オブジェクト全体ではなく、オブジェクト内の特定のフィールドに対する権限を同期する機能です。これにより、コスト見積もりや顧客PIIなどの機密フィールドを特定のユーザーだけが閲覧・編集できるシナリオが可能になります。 2. **複雑な条件付き権限（「キャビアット」）。**高度なルールベースの権限のサポート — 例えば、特定のフィールドが特定の値を持つ場合にのみイシューへのアクセスを付与する（例：ステータスが「Approved」の場合）。 Authorization Policyメタオブジェクトは最初から拡張可能に設計されており、これは書き直しではなく自然な進化です。これらは遠い将来のロードマップ上の機能ではありません — 最大のLand機会が存在するアカウントでComputerを解放する能力です。 私たちの進捗を追い、会話に参加するには、[DevRev Discordサーバー](https://discord.com/invite/DjUujyDGAD)をチェックするか、[DevRev Live YouTubeチャンネル](https://www.youtube.com/@devrevinc)を登録して、さらなるディープダイブをご覧ください。 [Video](https://www.youtube.com/watch?v=0Z_W7RXQUMU)