ノーコード連携におけるOAuth認証とAI権限の安全な設計ガイド

本記事では、ノーコードツールとAIを安全につなぐための実践的な設計図を描いていきます。経営層から現場のエンジニアまで、組織全体で安心してAIを活用し、ビジネスを加速させるための方法を解説しましょう。

「連携できない」と「連携していいかわからない」の違い

皆さんが直面しているトラブルには、実は2つの異なるレイヤーが混在していることにお気づきでしょうか？

1. 機能的なトラブル（Can't）: 設定画面でエラーが出て接続できない、APIキーが見つからないといった技術的な壁。
2. 心理的・組織的なトラブル（May not）: 「これを許可して本当に大丈夫か？」「会社のポリシーに違反しないか？」という判断の迷い。

インターネット上の多くの記事は1番目の解決策に終始しがちですが、実務の現場で担当者を真に悩ませているのは2番目です。ここがクリアにならない限り、どんなに革新的なワークフローを構築しても、「シャドーIT（会社の許可を得ずに使われるITツール）」としての後ろめたさを抱え続けることになります。

AIエージェントに「鍵」を渡すことの意味

ノーコードツールを使って、ChatGPTなどのAIモデルと社内のGoogleドライブやSlackを連携させる行為は、AIという「新しい優秀なアシスタント」に、会社のオフィスの合鍵を渡すようなものと考えることができます。

• その鍵で、重要な情報まで開けられてしまわないか？
• そのアシスタントが利用されなくなった後も、鍵が残らないか？
• 利用状況を把握できているか？

これらを制御し、ガバナンスを効かせる技術的な仕組みが、「OAuth（オー・オース）」や「アイデンティティ管理（IAM）」です。

本記事で解消できる3つのセキュリティトラブル

今回は、よくある危険な兆候を3つに分類し、それぞれの実践的な対策を提示します。

1. 診断1：過剰な権限付与（Over-privileged）
   • AIに必要以上の権限を与えてしまっている状態。
2. 診断2：アイデンティティの混同（Identity Confusion）
   • AIが操作を行い、責任の所在が不明確になる状態。
3. 診断3：ゾンビトークンの放置（Stale Access）
   • 使われなくなった連携設定が残ってしまっている状態。

現在の設定が安全かどうか、プロトタイプを検証するような視点で一つずつ見ていきましょう。

診断1：なぜ「アクセス権限の警告」が出るのか？OAuthの仕組みを解剖する

MakeやZapierで新しいアプリケーション（例えばGoogle SheetsやSlack）を連携しようとすると、「アクセスを許可しますか？（Authorize Access）」と尋ねられます。皆さんは、内容を読まずに「許可」をクリックしていませんか？

ここがデータガバナンスの第一防衛線であり、最も注意すべきポイントです。

症状：画面に表示される「Scope（スコープ）」の警告

連携画面には、「Scope（スコープ）」と呼ばれる項目が表示されています。これは「許可される行動範囲」を定義したリストです。

もし、「AIにスプレッドシートのデータを読ませたいだけ」なのに、以下のようなスコープが表示されていたら、注意が必要です。

• drive (Googleドライブ内の全ファイルの閲覧・編集・削除)
• admin.directory.user (組織内の全ユーザー情報の操作)
• mail.send (Gmailでのメール送信)

これらは、本来の目的（シートの読み取り）に対して過剰である可能性があります。

原因：AIに「家の鍵」ではなく「部屋の鍵」を渡せているか

OAuthは、「パスワード」そのものを相手（MakeやZapier）に教えることなく、「アクセストークン」と呼ばれる一時的なチケットを発行して渡す仕組みです。

• パスワード: 全権限を持つ、永続的な証明書。
• アクセストークン: 「特定のスコープ」と「有効期限」が設定された限定的な鍵。

トラブルの原因は、ノーコードツール側が「設定を簡単にするため」に、広範囲なスコープ（Full Access）を要求してくるケースが多いことにあります。「まず動くものを作る」という観点では便利ですが、「とりあえず全部許可しておけば動く」という設計は、エンタープライズのセキュリティ観点からは大きなリスクを孕んでいます。万が一、連携先のツールが侵害された場合、その権限が悪用され、深刻な情報漏洩やデータ消失につながる恐れがあるのです。

解決手順：最小権限の原則に基づくスコープ設定の見直し

安全な連携を実現するための鉄則は「最小権限の原則（Principle of Least Privilege）」です。業務遂行に必要な最低限の権限しか与えない、という堅牢なシステム設計の基本です。

具体的なアクションプランは以下の通りです。

1. スコープの文字列を解読する

連携画面で求められているスコープの意味を確認してください。例えばGoogle Workspace（GCP）関連の場合、以下のような違いがあります。

• https://www.googleapis.com/auth/drive : 注意。全ファイルの読み書き削除が可能。
• https://www.googleapis.com/auth/drive.readonly : 読み取りのみ可能。
• https://www.googleapis.com/auth/drive.file : このアプリ（Make等）が作成したファイル、またはユーザーが明示的にこのアプリで開いたファイルのみにアクセス可能。

2. カスタム接続（Custom App / API Key）を活用する

Makeなどのツールでは、標準のコネクタを使うだけでなく、自分でGoogle Cloud Platform (GCP) やAzure AD上でアプリ登録を行い、必要なスコープだけを指定した「カスタム接続」を作成できます。

特にGCP環境では、APIやAIモデル（Gemini等）の更新サイクルが速く、推奨されるセキュリティ設定も変化します。自身のGCPプロジェクト内でOAuthクライアントを作成することで、「特定のバケットしか見せない」「Vertex AIの推論実行のみ許可する」といったきめ細かな制御が可能になります。

3. データの流れ（Read/Write）とライフサイクルを意識する

AIにデータを渡すだけなら Read 権限のみで十分です。AIが生成したコンテンツを保存する場合のみ Write 権限が必要です。この方向性を意識するだけで、リスクを大幅に減らせます。

また、クラウドサービスやAIモデルは頻繁にバージョンアップや廃止が行われるため（例：古いGeminiモデルのサポート終了など）、連携設定を見直すタイミングで、不要になった古い権限セットが残っていないか定期的に棚卸しを行うことを強くお勧めします。

診断2：AIが「別人」として振る舞う？アイデンティティ管理のトラブル

次に問題となるのが、「誰が操作したのか」というアイデンティティ（ID）の管理です。ここは見落とされがちですが、実務の現場では、後になって最も厄介なコンプライアンス問題を引き起こす要因の一つとして知られています。

症状：AIによる変更履歴が「自分（担当者）」の名前で残る

例えば、共有フォルダ内の重要な契約書ファイルが、意図しない内容で上書き保存されてしまったケースを想像してください。

セキュリティチームが操作ログ（監査ログ）を調査したところ、そこには「あなた」の名前が記録されていました。しかし、その時刻、あなたは別の会議でプレゼン中でした。

システムログ上はあなたが操作したことになっています。これは、社内での信頼を損なうだけでなく、企業としての追跡調査（デジタル・フォレンジック）を極めて困難にします。それが人間の意図的な操作なのか、AIエージェントの誤作動なのか、あるいは外部からの攻撃なのか、ログからは区別がつかないからです。

原因：ユーザー個人のアカウントでAIを認証させている

この問題の根本原因は、AIエージェントや自動化フローの認証に、「開発者や担当者個人のGoogle/Microsoftアカウント」を使用してしまっていること（User Contextでの実行）にあります。

さらに、もう一つ重大なリスクがあります。それは「属人化による連鎖停止（SPOF: Single Point of Failure）」です。

もし担当者が退職や異動になり、そのアカウントが削除・凍結されたらどうなるでしょうか？ アカウントに紐付いていたOAuthトークンも即座に無効化されます。その結果、ビジネスに不可欠な自動化システムが、ある日突然、何の前触れもなく停止してしまうのです。

解決手順：サービスアカウント（ボット用アカウント）の活用と分離

この問題を解決する業界標準のアプローチは、「サービスアカウント（Service Account）」または「機能用アカウント（Non-human Account）」の導入です。

サービスアカウントとは、特定の人間に紐付かない、システム実行専用のアカウントです。Google WorkspaceやMicrosoft 365、あるいはGoogle Cloud Platform（GCP）などの環境では、管理者がこれを作成・管理することができます。

実践ステップ

1. 専用アカウントの申請: 情報システム部門に依頼し、システム専用のアカウント（例: bot-marketing-01@company.com）を発行してもらいます。これがAIエージェントの「固有のID」になります。
2. 最小権限の付与: その専用アカウントに対し、業務に必要な特定のフォルダやチャンネルへのアクセス権のみを付与します。管理者権限のような強力な権限は避けてください。
3. 連携の実施: MakeやZapierでのOAuth認証時、個人のアカウントではなく、このサービスアカウントの認証情報を使用して連携を行います。

導入のメリット

• ログの透明性: 操作履歴には bot-marketing-01 と記録されるため、AIによる自動操作であることが一目瞭然になります。
• ビジネスの継続性: 担当者が変わっても、サービスアカウントは削除されないため、システムは安定して稼働し続けます。
• セキュリティ境界の明確化: 万が一このアカウントの認証情報が漏洩しても、被害はそのボットがアクセスできる範囲に限定され、個人のメールやチャットなどが覗かれるリスクを遮断できます。

実務におけるアドバイス:
クラウドサービス（Google CloudやAzureなど）の認証仕様やセキュリティポリシーは頻繁に更新されます。例えば、Google Cloudでは古いAPIバージョンや特定の認証方式が廃止されることがあり、個人アカウントで管理しているとこれらの変更通知を見落としがちです。専用のサービスアカウントを使用し、システム管理者が集中管理することで、プラットフォームの仕様変更にもアジャイルかつ安全に対応できるようになります。

AIを単なる「便利な道具」としてではなく、「デジタルの同僚」として扱い、専用のIDを持たせることが、倫理的かつ持続可能なAIガバナンスの第一歩です。

診断3：連携ツールが増えすぎて管理不能？「ゾンビトークン」の駆除

3つ目の診断は、「ゾンビトークン」についてです。

ノーコードツールは高速なプロトタイピングや試行錯誤が容易なため、とりあえず連携してみて、うまくいかなかったらそのまま放置……ということが起こりがちです。しかし、ここに大きな落とし穴があります。

症状：使っていない連携ツールからアクセスがある

一度OAuth認証を行い「許可」ボタンを押すと、アクセストークン（短期的な鍵）と共に「リフレッシュトークン（Refresh Token）」という長期的な合鍵の引換券が発行されます。

Make側でシナリオ（Zap）を削除しても、あるいは解約しても、GoogleやSlack側には「このアプリ（Make）にアクセスを許可した」という事実は残り続けます。つまり、リフレッシュトークンは有効なまま残ります。

近年、攻撃者はセキュリティの甘いサードパーティアプリ（連携ツール）を乗っ取り、そこにある「ゾンビトークン」を経由してデータにアクセスする手法を多用しています。放置された鍵は、侵入経路になる可能性があります。

原因：テスト的に連携した後の「解除忘れ（Revoke漏れ）」

原因は単純な「片付け忘れ」です。ツール側（Make等）での設定削除と、データ元（Google等）での認可取り消しは、別の操作であるという認識が不足していることが大半です。

解決手順：Google/Microsoftアカウント設定からの定期的な棚卸し

ゾンビトークンを駆除するには、データ元のプラットフォーム側で「棚卸し（Revoke）」を行う必要があります。

Google Workspaceの場合

1. Googleアカウント管理画面（myaccount.google.com）にアクセス。
2. 「セキュリティ」>「アカウントにアクセスできるサードパーティ アプリ」を選択。
3. 一覧を確認し、現在使用していないアプリがあれば詳細を開き、「アクセス権を削除」をクリック。

Microsoft 365の場合

1. 「マイ アカウント」ページ（myaccount.microsoft.com）にアクセス。
2. 「アプリの権限」を選択。
3. 不要なアプリの「取り消し（Revoke）」をクリック。

Slackの場合

1. 「App管理」ページにアクセス。
2. 「インストールされたアプリ」を確認し、不要なものを削除。

この作業を定期的に行うことが強く推奨されます。これだけで、不要なリスクを劇的に減らすことができます。

予防と対策：情報システム部門に相談するための準備

これらの知識をベースに、情報システム部門と建設的な対話をするための準備をしましょう。

情報システム部門が懸念している本質を理解し、システムの構造を可視化し、リスク対策済みであることを論理的に示せば、強力なバックアップを得やすくなります。

情報システム部門が最も懸念しているポイントとは

懸念は、主に以下の3点に集約されます。

1. Data Flow（データの流れ）: データがどこを経由し、どこに保存されるのか？
2. Access Control（アクセス制御）: 誰がそのデータに触れるのか？ 権限は適切か？
3. Auditability（監査可能性）: 何かあった時に、誰がやったか追跡できるか？

現場で用意すべき「利用申請書」のテンプレート要素

これらを網羅した、仕様書（または利用申請書）を作成してみましょう。以下の項目を埋めて提出することで、理解を得やすくなります。

• プロジェクト名: 例：カスタマーサポート一次回答案作成Bot
• 使用ツール構成: Make (iPaaS) + OpenAI API (LLM) + Gmail
• データフロー図: [Gmail受信] → [Makeでテキスト抽出] → [OpenAIで要約生成] → [Slack通知]
• 扱うデータの機密性: 社内レベル（顧客情報はMake側で処理）
• 接続アカウント: 専用サービスアカウント cs-bot-01@company.com を使用
• 付与する権限（Scope）:
  • Gmail: readonly（送信権限なし）
  • Slack: 特定チャンネルへの投稿のみ
• リスク対策: 生成された回答案はSlackに通知するのみで、自動返信は行わない。

このように、「技術の利便性だけでなく、リスクを理解し、具体的な対策を講じている」という姿勢を明示することが、組織的な合意形成において極めて重要です。

万が一インシデントが起きた時の対応

トラブルが起きた時のために、DevOpsの観点からも「緊急停止ボタン（Kill Switch）」の場所を必ず把握しておきましょう。

MakeやZapierには、シナリオ全体を停止するスイッチがあります。また、Google/Microsoftの管理画面から、連携そのものを強制解除（Revoke）すれば、アクセスを遮断できます。

アクセルを踏む前に「ブレーキのかけ方」を知っていることが、システム運用における鉄則です。この準備があれば、いざという時にも冷静に対応できるはずです。

まとめ：安全なAI活用がビジネスを加速させる

ノーコードツールとAIの連携は、業務を劇的に効率化し、ビジネスに革新をもたらします。しかし、そのポテンシャルを最大限に引き出すためには、堅牢なデータガバナンスと安全管理が欠かせません。

今回ご紹介した3つのポイントを振り返りましょう。

1. OAuthは「合鍵」。スコープを確認し、必要最小限の権限だけを渡す。
2. AIには「専用のID」。個人のアカウントを使い回さず、サービスアカウントでログを分離する。
3. 定期的な「鍵の回収」。使わなくなった連携は確実に解除する。

これらは、高度なプログラミングスキルが必要なものではありません。技術の本質を理解し、適切な運用ルールを設計するだけで実現できます。安全な基盤の上でこそ、AIエージェントは真の価値を発揮します。ぜひ、皆さんのプロジェクトでも実践してみてください。