はじめに (対象読者・この記事でわかること)

本記事は、Office365 のアカウントを用いて BizRobo (旧名 Kapow) にログインしようとしてエラーが出る企業の IT 担当者や RPA 開発者を対象としています。
具体的には、以下のポイントが理解でき、実際にログイン障害を解消できるようになります。

  • Office365 と BizRobo の認証フローの全体像
  • 「認証に失敗しました」や「ユーザーが見つかりません」といったエラーメッセージの意味
  • Azure AD と BizRobo の連携設定のチェック項目
  • 実際に問題を切り分け、設定を修正する手順

本記事を書いた背景は、社内で同様の障害が頻発し、都度問い合わせを受けることが多く、自己解決できる情報が散在している点に悩んでいたためです。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。

  • Office365（Azure AD）におけるユーザー管理とアプリケーション登録の基本
  • BizRobo（Kapow） のインストール・管理画面の操作
  • 基本的なネットワーク概念（プロキシ、ファイアウォール）

BizRobo(Kapow) と Office365 の認証概要

BizRobo は、従来は独自認証方式を採用していましたが、2023 年以降のバージョンから Azure AD（Office365）とのシングルサインオン（SSO）に対応しています。
この連携は以下の流れで行われます。

  1. Azure AD でアプリ登録
    - 「エンタープライズ アプリケーション」として BizRobo を登録し、リダイレクト URI を指定。
  2. BizRobo 側で SSO 設定
    - 「認証」メニューで Azure AD のテナント ID、クライアント ID、クライアント シークレットを入力。
  3. ユーザー属性マッピング
    - Azure AD の「ユーザー属性」→「メールアドレス」を BizRobo のユーザー名として使用。

この認証構成が正しく行われていないと、Office365 アカウントでのログインが失敗します。特に「テナント ID の誤り」や「リダイレクト URI の不一致」などが典型的です。

ログイン障害の具体的な対策手順

以下では、典型的な障害シーン別に手順を示します。実際に Azure ポータルと BizRobo の管理画面を操作しながら確認してください。

ステップ1：Azure AD 側の設定確認

  1. Azure ポータルにサインイン
    portal.azure.com に管理者アカウントでログイン。

  2. エンタープライズ アプリケーションの一覧から BizRobo を選択
    - 「シングルサインオン」タブを開き、SAML が選択されているか確認。

  3. 基本情報のチェック
    - テナント ID（Directory (tenant) ID）
    - クライアント ID（Application (client) ID）
    - リダイレクト URI が BizRobo のドキュメント通り https://<your-bizrobo-host>/sso/acs になっているか

  4. 証明書とシークレット
    - 「証明書とシークレット」タブで有効期限が切れていないクライアントシークレットを確認。期限切れの場合は新規作成し、期限は最低でも 12 か月は設定。

  5. ユーザー & グループの割り当て
    - BizRobo にアクセスを許可したユーザーが 「割り当て済み」 になっているか。
    - 必要に応じて 「全員」 ではなく 「ユーザー」 単位で割り当てを行う。

ステップ2：BizRobo 側の SSO 設定確認

  1. BizRobo 管理コンソールに管理者権限でログイン
    URL 例: https://<your-bizrobo-host>/admin

  2. 「設定」→「認証」メニューへ
    - 「認証方式」欄で 「Azure AD (SAML)」 が選択されていること。

  3. Azure AD から取得した情報の入力
    - テナント ID、クライアント ID、クライアントシークレットを正確にコピーペースト。
    - 「リダイレクト URI」は自動で設定される場合が多いが、手動で上書きしても OK。

  4. 属性マッピング
    - 「NameID」→ メールアドレス (userPrincipalName) が正しく設定されているか。
    - 追加属性（例: department）が必要なら、Azure AD 側で 「アプリケーション属性」 に追加し、BizRobo 側でも受信設定を行う。

  5. テスト認証
    - 「テスト」ボタン（または「接続テスト」）を実行し、「認証成功」 と表示されるか確認。

ステップ3：ネットワーク・プロキシ設定のチェック

  1. ファイアウォールやプロキシで Azure AD のエンドポイントがブロックされていないか
    - 必要なエンドポイントは login.microsoftonline.com、graph.microsoft.com、*.login.microsoftonline.com など。

  2. TLS/SSL 証明書の有効性
    - BizRobo が使用している証明書ストアに、Microsoft の根証明書が含まれているか。自社プロキシで SSL インターセプトしている場合は、証明書を BizRobo にインポートする必要があります。

  3. 時間同期
    - サーバーの時計が NTP で正確に同期されていないと、SAML のタイムスタンプ検証で失敗するケースがあります。

ハマった点やエラー解決

エラーメッセージ 主な原因 解決策
Authentication failed クライアントシークレットが無効/期限切れ Azure AD で新しいシークレットを発行し、BizRobo に再設定
User not found Azure AD の属性マッピングが userPrincipalName ではなく mail に設定されている 属性マッピングを userPrincipalName に統一
Invalid audience BizRobo 側の Entity ID が Azure AD の Identifier (SP Entity ID) と不一致 BizRobo の SAML 設定で Entity ID を Azure AD の値に合わせる
SSL handshake failure 社内プロキシで MITM 証明書が使用され、BizRobo が信頼しない プロキシ証明書を BizRobo の信頼ストアにインポート
Clock skew too large サーバー時刻がずれている NTP サービスで時刻を同期

解決策の総合フロー

  1. Azure AD のアプリ設定を最新化（テナント ID・クライアント ID・シークレット）
  2. BizRobo 側に正確に情報を反映（認証方式＝SAML、属性マッピング）
  3. ネットワークと証明書、時刻をチェック
  4. テスト認証で成功を確認 → 以降はユーザーが Office365 アカウントで通常通りログイン可能

上記を順に実施すれば、ほとんどの「Office365 アカウントで BizRobo にログインできない」ケースは解消できます。

まとめ

本記事では、Office365（Azure AD）と BizRobo(Kapow) の SSO 連携における典型的な障害と、その原因解析・解決手順を詳しく解説しました。

  • Azure AD 側のアプリ登録情報（テナント ID・クライアント ID・シークレット） が正しく設定されているかをまず確認。
  • BizRobo の SAML 設定と属性マッピング を Azure AD に合わせることで認証エラーが解消。
  • ネットワーク環境・証明書・サーバー時刻 の整合性が不備だと、SAML の検証で失敗する点に注意。

これらを実施することで、ユーザーは Office365 アカウントだけでシームレスに BizRobo にログインでき、業務効率化が加速します。次回は、同様の SSO 環境を モバイルアプリ に拡張する方法や、条件付きアクセスポリシー の活用例について取り上げる予定です。

参考資料