MENU

Fireflies.aiとMicrosoft Entra IDでSSOを実現するOIDC/OAuth設定徹底ガイド

Azure

Fireflies.ai を社内で本格導入するタイミングで「Microsoft Entra ID（旧 Azure AD）で SSO したいのに、SAML の設定画面が見当たらない」とつまずくケースは少なくありません。しかし Fireflies.ai がサポートしている OpenID Connect（OIDC）と OAuth 2.0 を正しく理解して設定すれば、結果としてユーザーはしっかり “SSO 体験” を得られます。本記事では、その考え方と具体的な設定手順をわかりやすく整理します。

Fireflies.ai を Microsoft Entra ID と連携して SSO を実現する方法（OIDC/OAuth 解説付き）

Fireflies.ai のノートテーカーを Microsoft Teams や Zoom、Google Meet などで使う場合、「ユーザーをどう認証するか」は情報システム部門にとって大きなテーマです。特に、Microsoft Entra ID をアイデンティティ基盤としている企業では、Fireflies.ai も同じアカウントでシングルサインオン（SSO）させて運用負荷とリスクを下げたいところです。

ところが実際の Fireflies.ai には、SAML 向けのいわゆる「SSO 設定画面」がなく、代わりに OIDC/OAuth 形式のサインオンしか提供されていません。「これでは SSO にならないのでは？」と不安になる方もいるでしょう。

結論から言うと、Fireflies.ai が提供している OIDC/OAuth の認証連携を使うだけで、実質的な SSO を実現できます。SAML 専用メニューがなくても問題はありません。その理由を、用語整理から具体的な設定方法、運用のベストプラクティスまで順序立てて解説します。

日程Fit。無料・登録不要。「いつ空いてる？」を、ひとつのリンクで。リンクを送って、○△×でかんたん日程調整。無料で日程を作る。
目次

用語の整理：SSO と OAuth 2.0 / OpenID Connect の関係

まずは、「SSO」「OAuth 2.0」「OpenID Connect」の位置づけを整理します。ここが曖昧だと設計も運用もモヤモヤしたままになってしまいます。

項目役割ポイント
SSO（シングルサインオン）一度のサインインで複数のアプリを横断利用できる体験そのもの技術仕様ではなく「目的・結果」の言葉。SAML でも OIDC でも実現可能
OAuth 2.0権限委譲の仕組み。「どのアプリが、どの範囲のデータにアクセスしてよいか」を制御認可プロトコル。ユーザーの「ログインそのもの」を定義しているわけではない
OpenID Connect（OIDC）OAuth 2.0 の上に「ユーザー認証」機能をのせた ID 連携標準ID トークンを用いて「誰がログインしたか」をアプリに伝える

ここで押さえておきたいのは、SSO はプロトコル名ではなく「ログイン体験」を指す概念だという点です。SAML を使っても OIDC を使っても、「一度のサインインで複数サービスに入れる」状態を作れれば、それは立派な SSO です。

したがって、Fireflies.ai が OIDC/OAuth に対応しているなら、その連携を Azure（Microsoft Entra ID）と組み合わせることで SSO 体験をつくれる、というのが本記事の基本スタンスになります。

登場人物の役割：IdP / アプリ / ユーザー

Fireflies.ai と Microsoft Entra ID を結びつけるときに登場する「役者」を整理しておくと、後の設定が理解しやすくなります。

役割具体的なサービス何をしているか
IdP（アイデンティティ プロバイダー）Microsoft Entra ID（旧 Azure AD）ユーザーの ID 管理、パスワードや MFA、条件付きアクセスなどを一元管理
クライアントアプリ（Relying Party）Fireflies.ai「この人は誰か？」を IdP に尋ね、返ってきたトークンを信じてログインさせる
エンドユーザー社内の利用者ブラウザやモバイルから Fireflies.ai を利用。実際には Entra ID にサインインしている

構造としては、「Fireflies.ai は Entra ID を信頼するクライアントアプリ」という位置付けです。ユーザーが Fireflies.ai にログインする時、実際にパスワードを握っているのは Entra ID であり、Fireflies.ai はパスワードを知らないままトークンだけを受け取って処理します。

なぜ Fireflies.ai は SAML ではなく OIDC/OAuth を採用しているのか

「SSO といえば SAML」というイメージを持つ方は今でも多くいますが、近年の SaaS やモバイルアプリでは、OIDC/OAuth が事実上の標準になりつつあります。その背景は次のような点にあります。

  • モバイル / SPA との親和性が高い：SAML はブラウザ + サーバー前提の設計で、モバイルアプリや SPA（シングルページアプリケーション）との相性があまりよくありません。OIDC はこの点を意識して作られています。
  • API 連携前提の設計：Fireflies.ai はカレンダーや会議ツールなど様々な API と連携して動きます。OAuth 2.0 ベースであれば、認可トークンをそのまま API 呼び出しにも流用でき、設計がシンプルになります。
  • セキュリティ機能の拡張がしやすい：PKCE や Proof of Possession といった新しい保護機構が取り込みやすく、クラウド時代の要請に応じて進化し続けています。

そのため、Fireflies.ai に「SAML の SSO メニューがない」のは、ネガティブな意味ではなく、よりモダンな OIDC/OAuth に集中しているデザインと捉えると理解しやすくなります。

「OIDC/OAuth しかないけど SSO になるの？」という疑問への回答

ここがこの記事の肝です。「SAML ではなく OIDC/OAuth でログインしているのに、SSO と呼んでいいのか？」という疑問に対し、はっきりとした答えを出しておきます。

  • SSO = 技術方式ではなく「一度のログインで複数サービスを使える状態」
  • Microsoft Entra ID を共通 IdP として、Office 365 や Teams、他の SaaS と同じアカウントで Fireflies.ai にログインできる
  • ユーザー視点では「会社のアカウントでログインボタンを押しただけで入れる」＝ SSO 体験になっている

つまり、Fireflies.ai が SAML をサポートしていなくても、Microsoft Entra ID を OIDC IdP として使えば十分に SSO を実現できます。システム的なラベルよりも、ユーザーにとっての体験を優先して判断するのがポイントです。

Fireflies.ai と Microsoft Entra ID を連携する前に確認しておきたいこと

具体的な設定に入る前に、事前にチェックしておくべき項目を整理します。

  • Fireflies.ai のプラン：
    SSO/OIDC 連携が利用可能な有料プランかどうかを確認します（Free プランでは制限がある場合があります）。
  • 管理者権限：
    Microsoft Entra ID 側でアプリ登録・権限付与を行える全体管理者または同等のロールが必要です。
  • テナントの種類：
    検証用のサンドボックス環境がある場合、本番前にそちらで動作確認を行うと安全です。
  • ユーザーのアカウント体系：
    社内では UPN（[email protected]）がそのままメールアドレスとして使われているか、別名なのかなど、基本的なユーザー情報を整理しておきましょう。
事前確認項目確認内容影響
Fireflies.ai プランOIDC 連携機能の有無プラン変更が必要な場合は導入スケジュールに影響
Entra ID 管理者権限アプリ登録・権限同意ができるロールか権限不足だと設定途中で行き詰まる
ユーザー属性email / UPN / displayName の扱いFireflies.ai のユーザー紐付け方式に影響

Microsoft Entra ID 側の設定手順（詳細解説）

ここからは、Microsoft Entra 管理センターでの設定手順をもう少し丁寧に掘り下げていきます。画面名称や配置はバージョンによって多少変わる可能性がありますが、大枠の流れは変わりません。

アプリの登録

  1. Microsoft Entra 管理センターに管理者権限でサインインします。
  2. 「アプリの登録」メニューから「新規登録」を選びます。
  3. アプリ名に「Fireflies.ai Integration」などわかりやすい名称を入力します。
  4. サポートされているアカウントの種類として、通常は「この組織ディレクトリ内のアカウントのみ」を選択します（社内専用の場合）。
  5. 登録後、アプリのアプリケーション（クライアント）ID と ディレクトリ（テナント）ID が表示されるので、これを控えておきます。

リダイレクト URI の設定と認証フロー

Fireflies.ai 側のドキュメントで指定されているリダイレクト URI（例：https://app.fireflies.ai/auth/callback）を、Entra ID 側に登録します。

  1. 登録したアプリの「認証」メニューを開きます。
  2. 「プラットフォームの追加」から「Web」を選択します。
  3. リダイレクト URI の欄に https://app.fireflies.ai/auth/callback を追加します。
  4. 「許可されている OAuth 2.0 フロー」で、認可コードフロー（Authorization Code） を有効にします。必要に応じて PKCE を必須にします。

Fireflies.ai の画面側で別のコールバック URL や追加のポストバック URL が表示されている場合は、それらも同様にリダイレクト URI として加えておきます。

クライアントシークレットの発行

  1. アプリの「証明書とシークレット」メニューを開きます。
  2. 「新しいクライアント シークレット」をクリックし、説明と有効期限（例：6か月、12か月、24か月）を設定します。
  3. 生成されたシークレットの 値 をその場で必ず控えます。画面を離れると二度と表示されません。

クライアントシークレットは、Fireflies.ai と Entra ID の間で共有するパスワードのようなものです。外部に漏れないよう、パスワード管理ツールや Key Vault 等で厳重に保管しましょう。

API 権限（スコープ）の付与

Fireflies.ai のログインに最低限必要なスコープは、一般的には次のとおりです。

  • openid
  • profile
  • email

アプリの「API のアクセス許可」から、これらのオープン ID 関連スコープを追加し、管理者の同意を与えます。

  1. 「API のアクセス許可」→「アクセス許可の追加」をクリック。
  2. 「Microsoft Graph」または「Microsoft ID プラットフォーム」から openid, profile, email を選択。
  3. 「管理者の同意を与えます」ボタンからテナント全体への同意を実行。

この操作により、ユーザーが Fireflies.ai にサインインするとき、個々のユーザーが毎回「このアプリにアクセスを許可しますか？」というダイアログを見ることなくスムーズに利用できるようになります。

OIDC エンドポイント情報の確認

最後に、Fireflies.ai に渡すための OIDC エンドポイント情報を確認します。具体的には次の値です。

  • 認証エンドポイント（Authorization Endpoint）
  • トークンエンドポイント（Token Endpoint）
  • Issuer（発行者）

典型的には次のような URL になります（{tenant} はテナント ID またはドメイン）。

認証エンドポイント:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize

トークンエンドポイント:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

Issuer:
https://login.microsoftonline.com/{tenant}/v2.0

これらの値を Fireflies.ai 側の OIDC 設定画面にコピーして利用します。

Fireflies.ai 側の OIDC/OAuth 設定のポイント

次は Fireflies.ai の管理画面で行う設定です。画面名やレイアウトは変更される可能性がありますが、一般的な OIDC クライアント設定として、少なくとも次の項目を入力するイメージになります。

項目設定内容の例補足
Client IDEntra ID で発行されたアプリケーション（クライアント）IDGUID 形式の ID
Client SecretEntra ID で生成したクライアントシークレット有効期限に注意
Authorization URLhttps://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorizeテナント ID 部分の入力ミスに注意
Token URLhttps://login.microsoftonline.com/{tenant}/oauth2/v2.0/tokenAuthorization と同じバージョンを利用
Issuerhttps://login.microsoftonline.com/{tenant}/v2.0トークン検証に使用
Scopesopenid profile email必要に応じて追加スコープを付与
Redirect URIhttps://app.fireflies.ai/auth/callback など Fireflies.ai が指定する値Entra ID 側と完全一致させる

多くの場合、「ログイン方法」や「SSO 設定」「OAuth / OIDC 設定」のようなメニューから上記の値を入力する形式になります。実際の画面ラベルは変わる可能性があるため、Fireflies.ai の公式ドキュメントや UI の説明に従ってください。

実際のサインオンフローをイメージする

ここまでの設定が完了すると、Fireflies.ai へのログインは次のようなフローで動作します。

  1. ユーザーが Fireflies.ai のログイン画面で「Sign in with Microsoft」などのボタンをクリックする。
  2. ブラウザは Microsoft Entra ID（login.microsoftonline.com）の認証エンドポイントにリダイレクトされる。
  3. ユーザーがまだ Entra ID にサインインしていなければ、ID/パスワードや MFA が求められる。
  4. サインイン済みであれば、パスワード入力なしでそのまま認証が通る（ここが SSO 体験）。
  5. Entra ID は ID トークンとアクセストークンを Fireflies.ai に返す。
  6. Fireflies.ai は ID トークンの署名や発行者、期限を検証し、ユーザー情報（sub, email, name など）から自社ユーザーアカウントに紐付けてセッションを発行する。

この流れの中で、ユーザーのパスワードは Fireflies.ai に渡されることはありません。Fireflies.ai は「Entra ID が発行した署名付きトークン」を信頼してログインさせているだけです。これが IdP 連携によるモダンな認証の基本パターンです。

SAML SSO と OIDC SSO の違いを比較する

「結局どちらを採用すべきか」「既存の SAML 連携とどう整理するか」を考える上で、SAML と OIDC の違いをざっくり把握しておきましょう。

観点SAMLOpenID Connect（OIDC）
位置づけ主に Web SSO 用の XML ベース規格OAuth 2.0 上の ID 連携規格（JSON/JWT ベース）
トークン形式XML SAML アサーションJWT（JSON Web Token）形式の ID トークン
モバイル / SPA との相性あまり良くない良好。ネイティブアプリや SPA を想定
API 連携別途 OAuth 等を組み合わせて実装アクセストークンで API を直接呼び出しやすい
セキュリティ拡張既存実装が多くレガシー構成も残りがちPKCE や PoP トークン等新しい機能を取り込みやすい
構成管理メタデータ XML の交換・証明書更新が必要エンドポイント URL とクライアントシークレット中心で管理しやすい

既に社内で SAML による SSO を多数構成している場合でも、新規採用サービスでは OIDC/OAuth を優先し、徐々にモダンな構成へ移行していくという方針が取りやすくなります。Fireflies.ai はその一例として位置づけるとよいでしょう。

よくあるトラブルと対処方法

実際の運用でよく遭遇するエラーと、その原因・対処方法をまとめます。エラーコードやメッセージは英語の場合が多いので、発生したエラーをそのまま検索すると追加情報が見つかる場合もあります。

症状主な原因対処方法
「redirect_uri_mismatch」や類似のリダイレクト URI エラーEntra ID に登録したリダイレクト URI と、Fireflies.ai 側で使っている URI が 1 文字でも違うスキーム（https/https）、末尾スラッシュ、サブドメインなどを含めて完全一致しているか確認
invalid_client エラーClient ID / Secret の誤り、またはシークレット期限切れEntra ID 側で新しいクライアントシークレットを発行し、Fireflies.ai 側に再設定する
サインイン画面が表示されるが「アクセス拒否」になる必要なスコープに管理者同意が付与されていない、またはユーザーに割り当てがされていないopenid profile email への管理者同意を再実行し、対象ユーザー・グループの割り当てを確認
一部のユーザーだけログインできないメールアドレスや UPN の形式が他ユーザーと異なる、属性マッピングの問題当該ユーザーの属性（メール、UPN）を確認し、Fireflies.ai 側のアカウントとの紐付けルールを見直す
会議への参加はできるが、ノートが正しいユーザーに紐付かないFireflies.ai 内部のユーザー管理と IdP の属性がずれているFireflies.ai のユーザー管理画面でメールアドレスの統一、招待方法を整理する

セキュリティ・運用ベストプラクティス

SSO 連携は「一度設定すれば終わり」ではなく、長期的な運用とセキュリティが重要です。Fireflies.ai と Microsoft Entra ID を組み合わせる場合、次のようなポイントを意識すると安心です。

  • HTTPS の徹底
    リダイレクト URI は本番環境では必ず HTTPS を用い、HTTP を許可しない構成にします。
  • クライアントシークレットの定期更新
    有効期限が近づく前にローテーション手順を用意し、シークレットを更新してもサービス停止が起きないよう、作業手順をドキュメント化しておきます。
  • 最小権限の原則
    Fireflies.ai に付与するスコープは、本当に必要なものだけに絞ります。不要な API 権限は付与しないことが重要です。
  • 条件付きアクセスや MFA の活用
    Fireflies.ai へのアクセスも他のクラウドサービスと同様に、場所・デバイス・リスクレベルに応じた条件付きアクセスや MFA を適用することで、社外からの不正利用を防ぎます。
  • 監査ログの定期確認
    Microsoft Entra ID のサインインログや監査ログから、Fireflies.ai へのアクセス状況を定期的にチェックし、異常なパターン（深夜帯・海外 IP など）がないかを確認します。

SSO 体験をユーザーに届けるための運用上の工夫

せっかく OIDC 連携を設定しても、ユーザーがその存在を知らなかったり、別のログイン方法を使ってしまうと「SSO になっていない」状態が続いてしまいます。次のような運用上の工夫も検討しましょう。

  • 社内ポータルやブックマークの統一
    社内ポータルやスタートページから Fireflies.ai のリンクを掲載する際、「Microsoft でサインイン」など OIDC 連携を利用するログインパスを明示します。
  • 重複アカウントの整理
    個人の Gmail などで既に Fireflies.ai を利用していたユーザーがいる場合、会社アカウントへの移行手順を示し、業務データを社内管理アカウントに集約します。
  • ヘルプページ・FAQ の整備
    「初回ログイン手順」や「よくあるエラーと対処方法」を社内 Wiki 等にまとめておくと、問い合わせ対応の負荷を減らせます。
  • ロールアウト計画
    全社展開の前に、一部のチームでパイロット導入を行い、エラーや要望を拾ってから広げるとスムーズです。

他の SaaS と一緒に考える「SSO 戦略」の中での Fireflies.ai の位置づけ

Fireflies.ai 単体で設定を考えるのではなく、社内の SaaS 全体を見渡して「今後の SSO 戦略」を整理しておくと、長期的な運用が楽になります。

  • 今後新しく採用する SaaS では OIDC/OAuth 連携を優先し、SAML はレガシー移行期間中の位置付けにする。
  • Microsoft Entra ID を「すべての SaaS への入り口」として明確に定義し、例外を極力作らない。
  • Fireflies.ai のように会議録・議事録を扱うサービスは、情報漏えいリスクが高いため、特に IdP でのアクセス制御（MFA・条件付きアクセス）を厳格に適用する。

こうした方針をあらかじめ決めておくことで、Fireflies.ai に限らず、今後増えていくクラウドサービスをスムーズに統合しやすくなります。

まとめ：Fireflies.ai の OIDC/OAuth 連携で「実質 SSO」を実現する

最後に、本記事のポイントを整理します。

  • SSO は「技術名」ではなく「一度のサインインで複数アプリを使える体験」のことであり、SAML だけが SSO ではない。
  • Fireflies.ai は OIDC/OAuth に対応しているため、Microsoft Entra ID を IdP として連携すれば十分に SSO 体験を提供できる。
  • Entra ID 側では、「アプリ登録」「リダイレクト URI 設定」「クライアントシークレット発行」「スコープ付与と管理者同意」「OIDC エンドポイントの取得」が主な作業になる。
  • Fireflies.ai 側では、Client ID / Secret、Authorization URL、Token URL、Issuer、Scopes、Redirect URI を正しく入力する。
  • リダイレクト URI の不一致やシークレット期限切れ、スコープ不足がトラブルの典型パターンなので、チェックリスト化しておくと安心。
  • HTTPS の徹底、シークレットのローテーション、条件付きアクセスや MFA、監査ログの活用など、セキュリティ・運用面のベストプラクティスも合わせて取り入れる。

これらを押さえておけば、ユーザーは「会社の Microsoft アカウントで一度サインインするだけで Fireflies.ai を含む複数のクラウドサービスにシームレスにアクセスできる」実質的な SSO 環境を手にすることができます。SAML メニューがないことに不安を感じていた方も、OIDC/OAuth を前提としたモダンな SSO の流れとして、前向きに Fireflies.ai を組み込んでいきましょう。

Azure
OpenID Connect SSO Azure AD Microsoft Entra ID OAuth2.0 Fireflies.ai

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次