Using the WebUI — external service connections
Any way of connecting that is not listed here does not exist. Headings quote the screen's own wording.
What is not here is in one of the other files:
conversations, the input box, and sign-in: references/webui.md;
documents, files, tables, memory, channels, and apps: references/webui-workspace.md;
editing a file in place (「編集」): references/webui-file-edit.md;
SIROE pages, blocks, and boards: references/webui-siroe.md;
settings, administration, models, and triggers: references/webui-settings.md;
the office (/office): references/webui-office.md;
the meetings (/meetings): references/webui-meetings.md;
the calendar (/calendar): references/webui-calendar.md.
The 3 tabs of /settings/connections
External service connections (the 「コネクタ」 screen in the sidebar). There are 3 tabs — 「コネクタ」 (pick from the catalog and connect), 「API 連携」 (connect by entering credentials yourself), and 「外部の AI から使う」 (copy the connection URL for operating Samurai App from Claude / ChatGPT). The 「コネクタ」 tab is for connections to external services (MCP), and connecting requires a browser. Inside the tab, entries are split in 2 by origin: 「連携基盤経由」 is the long tail via the connection platform (Composio), and 「直接繋ぐ」 is a small set that connects directly to each vendor's official remote MCP (freee / マネーフォワード クラウド会計 / Misoca / LegalBrain エージェント / 駅すぱあと API / Oracle Autonomous Database). Of these, only 駅すぱあと API is not connected by signing in — after adding it, an admin enters the 駅すぱあと API access key (アクセスキー) into that connection's 「認証情報」 (the header name is pre-filled). Until the key is entered, using it from a conversation gives an authentication error. 駅すぱあと API cannot be added from a conversation's candidate card (the presser cannot enter the key) — an admin adds it here. Oracle Autonomous Database asks for the database when added — pressing its 「追加」 opens a field for the database's MCP URL or its OCID (the region is read from the OCID). One connection is made per database, so the card never shows 「追加済み」 and more databases can be added. Connecting signs in with the database user name and password. The database's MCP server must be enabled beforehand, and it cannot be reached through an access control list or a private endpoint. It cannot be added from a conversation's candidate card either (the card has no field for the database) — an admin adds it here; once it exists, members can link their own account from the card. Admins can disable / re-enable each connection from its 「⋯」 menu — a disabled connection stays in the list, greyed out, showing 「管理者によって無効化されています」; while disabled it cannot be used from conversations and no new connection can be started (re-enabling keeps the credentials). To delete, use 「この接続を削除」 in the same 「⋯」 menu. 「名前を変更」 in the same menu (admins only) changes the name shown on the card; the connection name used in grants and operation scopes stays the same. With 2 or more connections, a search box (「接続を検索」) sits above the cards — typing narrows the list to connections whose name contains the text; the summary above it still counts all of them. In the 「API 連携」 tab, under 「OAuth で API に繋ぐ」, admins and managers register integration apps and can later fix them with 「編集」 in the app row's 「⋯」 menu (「登録を削除」 is there too; it asks for confirmation, since every account connected through that app is disconnected). Each app row has one 「連携する」 menu to connect: 「自分のアカウントで連携」, 「<グループ名> で連携」 for each of your groups not yet connected, and 「テナント共通で連携」 (admins and managers) (the reference name cannot be changed; adding scopes afterwards is also done here). Added scopes cannot be used until each already-connected row is re-authorized with 「認可し直す」 — rows not yet re-authorized show 「追加されたスコープが未認可です」. You can also connect from a conversation — when the AI needs an admin-registered OAuth app you have not connected yet, it appears in the conversation's 「連携できるサービス」 section (above connector candidates such as Gmail). Pressing 「連携」 authorizes in a small window, then the conversation continues automatically. It connects the presser's own account; company-wide connections are still made here by an admin or manager. Fill in 「説明」 when registering (up to 200 characters) — what the app is for and which API it calls helps the AI choose between apps, e.g. one per department. Fill in 「トークンの失効エンドポイント」 if the service publishes one (the token revocation URL in its developer documentation, RFC 7009) — then disconnecting a row with 「解除」, and deleting the workspace, also revokes the authorization on the service's side. Left empty, the authorization stays on the service until you revoke it there. 「認可サーバーの issuer」 is optional — fill it in only if the service returns iss with the authorization result (RFC 9207). Once filled, a result without iss or with a different value is refused, so a service that does not return iss can no longer be connected. The value must match the issuer the service publishes exactly, including whether it ends with 「/」 — https://accounts.google.com/ and https://accounts.google.com are different values.
Adding a connector with your company's own OAuth client (自社の OAuth クライアント)
By default a 連携基盤経由 connector signs in through the connection platform's shared OAuth app (「標準連携アプリ」). An admin can instead add it with the company's own OAuth client (its own client_id / client_secret). In the 「コネクタ」 tab, pressing a connector's 「追加」 opens a menu to choose how to add it: 「標準連携アプリで追加」 or 「自社の OAuth クライアントで追加」, each with a one-line hint under it. Which to choose: 標準連携アプリ needs no preparation and connects at once, but the service's API rate limits and quota are shared with every other company using it — so a busy moment elsewhere can make calls fail with "too many requests" (HTTP 429 — seen with Google services on schedules at the top of the hour). Choose 自社の OAuth クライアント when that happens, when the service has no 標準連携アプリ, or when you want to decide the scopes yourself; the cost is creating an OAuth client on the service's side, registering the redirect URI, and managing that client. If neither reason applies, 標準連携アプリ is the one to pick. A connector with no 標準連携アプリ (e.g. Shopify) shows 「〇〇 には標準連携アプリがありません」, and its 「追加」 menu has only 「自社の OAuth クライアントで追加」. The form opens in place of the connector list (「戻る」 returns to the list) and asks for the fields the service requires (client ID, client secret, and so on; pick the method if there are several). An optional field such as 「Scopes」 left empty uses the service's default (shown as the field's example). What you type replaces the default rather than adding to it, so to request an extra scope, press the field's 「例を使う」 button to put the default in, then append the new one (comma separated) — typing only the new scope narrows the connection to that one. The form also shows 「〇〇 側に登録するリダイレクト URI」 (https://backend.composio.dev/api/v1/auth-apps/add) — register that URI in the OAuth client on the service's side before connecting. After adding, each person presses 「連携」 as usual. The same entry appears on a conversation's candidate card, but only while no connection for that service exists yet; members see it greyed out with the reason (only an admin can create a new connection). Once the connection exists, the card only offers 「連携」 — the client is fixed per connection, so switching an existing connection between the shared app and your own client means deleting it and adding it again. Each 連携基盤経由 connection's card says which it uses: 「標準連携アプリ」 or 「自社の OAuth クライアント」, each with an ⓘ — the first explains the shared rate limits, the second the company's own quota and scopes, and both say that switching to the other means deleting the connection and adding it again. On the latter, an admin can replace the secret, client ID, or scopes with 「認証情報を差し替え」 there. The form shows the current client ID and scopes. Some settings cannot be shown again (e.g. 「Microsoft cloud environment」 for Microsoft services): the field is empty with 「設定済み(変えるときだけ入力)」, and leaving it empty keeps the current value. The client secret is never shown again (Samurai App does not store it — it is kept by the connection platform), so re-enter it every time you replace. Deleting the connection also deletes the registered client. If connecting fails because the service rejects your client (Microsoft shows only "401" / invalid_client), the result page says 「連携先が自社の OAuth クライアントを受け付けませんでした」: replace the client secret with 「認証情報を差し替え」 and connect again. For Microsoft services, enter the secret's 「値」 (Value) from 「証明書とシークレット」, not the 「シークレット ID」 — the form says so under the Client secret field — and check it has not expired.
SAP Concur
Admins and managers connect by entering Concur's Client ID / Client Secret / Company ID / Company Request Token (the Company Request Token is issued on the Concur side and expires after 24 hours). What can be done from chat can be read even before connecting, by opening 「チャットからできること」 in the same section — it is listed in two groups: 「見る」 (your own expense report list, contents, and line items; expense policies and expense types; which Concur user you act as) and 「入力・提出する」 (enter a quick expense, create an empty expense report, submit a report for approval; by default a confirmation appears before execution). After connecting, each person presses 「自分の Concur アカウントを確認する」 once — this links them to the Concur user whose login ID matches their email address, and from chat they can act only as that user. People who have not confirmed cannot use Concur from chat (if the email address they signed in with is unverified, the confirmation itself fails). The connection expires after about 6 months of non-use, and a warning appears once fewer than 14 days remain. Disconnecting goes through a confirmation dialog — it discards the company token and also clears every member's identity confirmation (after reconnecting, each person confirms again). Disconnecting also asks Concur to revoke Samurai App's authorization on the Concur side. Reconnecting with a different Company ID without disconnecting also clears identity confirmations.
SmartHR
Admins and managers connect by entering the environment (本番 / サンドボックス), the subdomain (the start of the SmartHR URL), and an access token (issued in SmartHR under 「共通設定 → 外部システム連携 → アクセストークン」). The token never expires, so no warning appears. If the token's 「アクセス制限ルール」 restricts IP addresses, the connection fails. Chat can read only up to the company's employee directory (search employees, view one person, list departments, employment types, and offices), and registering, updating, and inviting employees and creating departments are limited to admins and managers (by default a confirmation appears before execution). Salary, withholding tax, My Number, family, bank account, pension number, and residence card information cannot be read or written from chat. Each person presses 「自分の SmartHR アカウントを確認する」 once — this links them to the SmartHR user with the same email address; people not registered as employees in SmartHR cannot confirm and cannot use SmartHR from chat. Disconnecting, as with Concur, goes through a confirmation dialog and clears everyone's identity confirmation (the token itself is deleted in SmartHR's admin screen). Reconnecting with a different subdomain also clears identity confirmations.
HRMOS勤怠
Admins and managers connect by entering the company string (the per-company string at the end of the HRMOS勤怠 login URL) and the Secret Key of an API KEY issued in the HRMOS勤怠 admin screen. Tokens are reissued from the stored Secret Key, so no expiry warning appears. What can be done from chat is listed in 「チャットからできること」 in 3 groups — 「自分の勤怠を見る」 (anyone: your own monthly attendance and totals of actual working hours, overtime, and late-night hours; punch history; remaining leave; lists of work categories, departments, employment types, locations, and leave types), 「打刻・修正する」 (your own records only: clock-in, clock-out, and break punches use the current time only; past times are handled by correcting the clock-in/out and break times for your own day; by default a confirmation appears before execution), and 「全社の勤怠を見る」 (admins and managers only: employee list, company-wide or other employees' monthly attendance, company-wide attendance for a given day, monthly reports, other employees' remaining leave). Punching or correcting for other employees, applying for or approving month-end closing, year-end adjustment documents, and punch location information cannot be handled from chat. Each person presses 「自分の HRMOS勤怠 アカウントを確認する」 once — this links them to the HRMOS勤怠 employee with the same email address; people who have not confirmed cannot use HRMOS勤怠 from chat. Disconnecting goes through a confirmation dialog and clears everyone's identity confirmation (the API KEY itself is deleted in the HRMOS勤怠 admin screen). Reconnecting with a different company string also clears identity confirmations
LegalOn
Unlike the other SaaS, admins and managers only choose the region to use and enable it (no company-level key is entered). To use it from chat, each person issues their own API credential in LegalOn under [個人設定] → [API連携] and registers their own on this screen. If the credential expires or is revoked, reissue it the same way and register again. The contracts a person can view and write are exactly those allowed by their permissions in LegalOn, and there is no way to act with someone else's permissions.
スマレジ
Admins and managers connect by entering the environment (本番 / サンドボックス), contract ID (契約 ID), Client ID, and Client Secret (the values from the app in スマレジ・デベロッパーズ). If pos.transactions:read and pos.staffs:read are not enabled in the app's 「スコープ」, the missing names are shown and the connection fails. Tokens are re-fetched on expiry, so no warning appears. The only thing it can do is view provisional sales (仮販売) (list by period, store, and status; the line items of one record; period up to 31 days), and confirmed people can read all stores under the contract. Cost prices, member information, and staff names are not shown, and nothing can be registered or cancelled. Each person presses 「自分のスマレジアカウントを確認する」 once — this links them to the staff member with the same email address; people without such a staff record, and suspended staff, cannot confirm. Disconnecting, and reconnecting with a different contract ID or environment, also clears identity confirmations
ジョブカン経費精算
Admins and managers connect by entering an API token issued in the ジョブカン経費精算 admin screen. The token never expires, so no warning appears. Chat can read your own requests (申請書) (status, line items, approval progress, and comments for expense reimbursement, payment requests, general, and EC purchase requests) and lists of forms, groups, positions, projects, and business partners; admins and managers can search everyone's requests by applicant, group, project, period, and status. The user list and registering/updating master data (projects, business partners, groups, positions) are limited to admins and managers (by default a confirmation appears before execution). Requests cannot be created, approved, or sent back from chat (the Jobcan API has no endpoint for it, so do it in the Jobcan screen). Bank account information and users' special notes cannot be read or written. Each person presses 「自分のジョブカンアカウントを確認する」 once — this links them to the Jobcan user with the same email address; users without a staff code cannot confirm. Disconnecting goes through a confirmation dialog and also clears every member's identity confirmation. Every reconnection clears identity confirmations for everyone — because the token alone cannot identify the company.
クラウドサイン
The same two-step setup as LegalOn. Admins and managers enable it by entering the environment (本番 / サンドボックス) and their own client ID — the client ID entered here is not saved; it is used only to check that the connection works and which team it belongs to. To use it from chat, each person issues their own under [アカウント] → [クライアント ID] in クラウドサイン and registers it on this screen. Registration succeeds only when the email address of the クラウドサイン user tied to that client ID matches the email address you are signed in with (with an unverified email address, registration itself fails). A client ID for a different team is also refused. Accounts using the multi-department management feature (複数部署管理機能) cannot connect. From chat you can only view the list of your own documents and the team's documents, a document's contents (recipients, status, and files), and document information (counterparty, execution date, contract period, cancellation notice deadline, auto-renewal, control number, transaction amount), and update that document information. Sending, reminding, rejecting, or cancelling documents, and creating or downloading documents or files, cannot be done. Listing the team's documents requires document management permission on the クラウドサイン side. 「クライアント ID の登録を削除する」 removes your own. Disconnecting goes through a confirmation dialog and discards the client IDs deposited by all members (after reconnecting, each person registers again).
カオナビ
Admins and managers connect by entering the Consumer Key and Consumer Secret issued in カオナビ under 「管理者機能トップ → 公開API v2 情報 → 認証情報」. What chat can reach is limited to the resources and sheets selected under that credential's 「操作対象」 (all off by default; sheets can be selected one by one, so turn off in カオナビ any sheet you do not want read). Identity confirmation needs access to 「ユーザー情報」, so leaving it off causes the connection to be refused. Chat can read the company's member directory and the enabled sheets (search members, view one person, the department tree, the list and contents of sheets, basic information fields, and the progress of registrations/updates), and registering and updating members and updating sheets or adding records are limited to admins and managers (by default a confirmation appears before execution). Gender, date of birth, and age cannot be read from chat. Registrations and updates are processed later on the カオナビ side, so at the time you only know they were accepted; they are complete once you check the progress. Each person presses 「自分のカオナビのアカウントを確認する」 once — this links them to the カオナビ user with the same email address, and only people registered as users who can log in to カオナビ and who are tied to a member can use it. Disconnecting goes through a confirmation dialog and clears everyone's identity confirmation (the credential itself is deleted in カオナビ's admin functions). Reconnecting with a different Consumer Key also clears identity confirmations
Sansan
As with LegalOn, admins and managers enable it, then each person registers their own API key (Sansan's top-right menu → [設定] → [API キー]; needs API permission from the Sansan admin). Chat can only read business cards, persons, tags, and contacts, within their Sansan permissions. A revoked key drops the registration. Disconnecting discards everyone's keys.
The accounts listed on a connector card
Each card lists the accounts (credentials) under that connection. They are ordered: your own personal account first, then shared ones (テナント共通 / group), then other members' personal accounts — so your own row is always at the top. A row's name is free text; the first one is named for you (or 「テナント共通」 / the group name) without asking. Rename it later from the row's 「⋯」 → 「名前を変更」 — a field opens under the row, and 「保存」 applies it. The name is what tells two accounts of the same service apart (「経理の私」 / 「営業の自分」), and renaming does not disconnect anything, so no re-authorization is needed. The same name cannot be used twice within one 公開範囲 (「この公開範囲には同じ名前の認証情報が既にあります」); a different 公開範囲 may reuse it. Whoever may delete a row may rename it — your own personal account is yours, and テナント共通 is an admin's or whoever added it.
Sharing a company-wide account with everyone (/settings/connections)
The same 3 steps are folded under 「テナント共通のアカウントをみんなで使うには」 in the screen's 「コネクタ」 tab. If even one step is missing, it is silently not used.
- Anyone, members included, presses 「アカウントを追加」 on the connector card, picks 「テナント共通のアカウントを追加」, and connects the company account with 「接続する」
- Under that account, whoever added it (or an admin) uses 「付与」 to add who may use it (role / group / user) and a tool pattern.
After choosing the type, multiple targets can be selected, and one grant is created per selection. Users are searched and selected by name or email (IDs are not typed).
Without a grant, even admins cannot use it. Roles match exactly and do not include higher roles — for everyone, choose the group 「テナント全体」 (grants are created for all 3 roles: admin, manager, and member).
If a grant for the same target and same tool pattern already exists, that one is not created.
The tool pattern
mcp__<接続名>__*covers every operation of that connection;*can only be written at the end (prefix match). An expiry is optional; if left blank it never expires (the list shows 「無期限」; past grants show 「期限切れ」). Grants cannot be deleted; stop them with 「失効する」 (to keep a record of who was allowed what) - The granted person selects the company-wide account under 「実行に使う認証情報」 in 「操作の設定」. It is not used until selected (the card shows 「実行に使うアカウントが未選択のため、この接続は使われません。」)