AI エージェント連携 (MCP)

MCP (Model Context Protocol) は、AI アシスタントを外部サービスに接続するための標準規格です。 raxel は公式 MCP サーバーを内蔵しており、Claude などの MCP 対応 AI から、 アプリのレコード閲覧・作成・更新、コメント投稿、ワークフローのステータス変更を安全に行えます。

たとえば「報告受付アプリ」を作っておけば、あなたのチームの AI エージェントが報告を読み取り、 対応し、結果を記録してステータスを進める — という運用を、コードを書かずに構築できます。

2 つの接続方法

AI クライアントの種類に応じて、接続方法は 2 つあります。

API トークン接続: 2 種類のトークン

API トークンは 2 種類あり、目的で使い分けます。

「AI にアプリを作らせて、そのまま運用させる」場合は、AI エージェント連携トークンの発行時に「データの操作」を許可します。そのトークンで作成したアプリのレコードを、 同じ接続のまま操作できます (アプリごとに API トークンを発行し直す必要はありません)。 既存のアプリを操作させたい場合は、発行時または発行後に「対象アプリ」へ追加します。 アプリ API トークンは、外部システム連携のように「1 つのアプリだけを渡したい」場合に使います。

準備: API トークンの発行

認証にはアプリの API トークンを使います。 接続したいアプリの設定 → 「API トークン」から発行してください (発行には再認証が必要です)。 AI に許可したい操作に応じて権限を選びます:

• 閲覧のみ — レコード・コメントの読み取り、集計、ワークフロー状態の確認
• 閲覧 + 書き込み — 上記に加えて、レコード作成・更新、コメント投稿、ステータス変更

トークン発行画面では「閲覧」「書き込み」「削除」を個別に選べますが、AI 連携には必ず「閲覧」を含めてください。 フィールド構成を取得するツール (get_app_overview) が閲覧権限を必要とするため、 「書き込み」だけのトークンでは AI がどの項目に何を書けばよいか分からず、実質的に何もできません (項目名を把握したうえで REST API から書き込むだけであれば、「書き込み」だけのトークンでも使えます)。

トークンはアプリ単位です。AI が扱えるのはそのアプリだけで、他のアプリ・メンバー管理・アプリ設定には一切アクセスできません。 トークンはいつでも失効でき、最終使用日時も確認できます。

接続方法

MCP サーバーの URL は次のとおりです (お使いのサブドメインに読み替えてください):

https://<あなたのサブドメイン>.raxel.jp/api/mcp

認証は HTTP ヘッダーで API トークンを渡します。Authorization: Bearer <トークン> と X-API-Token: <トークン> のどちらでも使えます。

Claude Code から接続する

claude mcp add raxel \
  --transport http \
  https://<サブドメイン>.raxel.jp/api/mcp \
  --header "Authorization: Bearer <APIトークン>"

接続後は「アプリの概要を見せて」「未対応のレコードを一覧して」「この 3 件を対応済みにして」のように、 自然言語で指示するだけで AI がツールを呼び出します。

claude.ai (Web 画面) から接続する — OAuth

claude.ai のコネクタ機能のように OAuth を前提とするクライアントは、トークンの貼り付けではなく画面での許可で接続します。手順:

1. claude.ai の「コネクタを追加」(カスタムコネクタ) で、上記のサーバー URL (/api/mcp) を登録します
2. 接続を開始するとブラウザで raxel が開きます (未ログインの場合はログイン後に続行)
3. 許可画面で、この接続に許可する操作を選びます — 「特定アプリのレコード操作」(対象アプリと閲覧のみ / 閲覧と書き込み)、「アプリの新規作成」(アプリ作成権限を持つ場合のみ)、または「特定アプリの管理」(対象アプリの設定編集。後述の「AI によるアプリの作り込み」を参照)。 確認のため再認証 (パスワード等) が必要です
4. 許可すると自動でクライアントに戻り、接続完了です

• OAuth 接続は許可したユーザー本人の権限の範囲でのみ動作します (管理者が発行する共有トークンと違い、本人のアクセス権を超えられません)
• 許可した接続は個人設定の「接続済みの AI」でいつでも確認・解除できます。解除は即時に反映されます
• 接続がユーザー個人の権限に紐づくため、退職・権限変更にも自動で追従します

その他の MCP クライアント

Streamable HTTP transport に対応した MCP クライアントであれば接続できます。 認証ヘッダーを設定できるクライアントは「サーバー URL + API トークン」、 OAuth (Dynamic Client Registration + PKCE) に対応したクライアントは「サーバー URL のみ」で接続できます。

使えるツール (レコード操作)

アプリの API トークン、または OAuth の「特定アプリのレコード操作」で使えるツールです。 アプリの新規作成は次の節、アプリ設定の作り込みはさらにその次の節を参照してください。

list_users が返すのは id と表示名だけです (メールアドレス・権限・在籍状況は返しません)。 見える範囲は画面の「ユーザー選択」と同じで、トークンを発行した利用者が選べる相手に限られます。 利用者選択フィールドに値を書くときや、担当者を指名するときの id を得るために使います。

ツールはトークンの権限に応じて出し分けられます。「読み取り」だけを付けたトークンでは書き込み系・削除系のツールがそもそも AI に見えません。 削除を任せたくない場合はトークンに「削除」を付けないでください (削除ツールが必要になったら、トークンを発行し直します)。

なお、OAuth (サーバー URL だけで接続する方式) では削除の権限が発行されません。 削除ツールを使えるのは、アプリ設定で「削除」を付けて発行した API トークンで接続した場合だけです。

削除はゴミ箱への移動 (論理削除) で、アプリのゴミ箱から復元できます。 他のアプリから参照されているレコードは既定で削除されず、参照元の一覧が返ります。 参照を無視して削除することもできますが、その場合は参照が外れ、 ルックアップの設定によっては参照している側のレコードの値が空になります(この操作は元に戻せません — 空になった参照元の値はゴミ箱から復元できません)。 AI がうっかり実行しないよう、参照している件数を AI に申告させ、 一致した場合だけ実行する仕組みにしてあります。

AI によるアプリ生成 (AI エージェント連携トークン)

ここまでのツールは「既存アプリのレコード操作」でした。これとは別に、AI に新しいアプリそのものを作らせることもできます。 「顧客からの問い合わせを受け付けるアプリを作って。件名・内容・優先度・対応状況が欲しい」のように指示すると、 AI がフィールド構成とビューを設計してアプリを作成します。

1. トークンの発行 — システム管理 → 「AI エージェント連携」から トークンを発行します (管理者のみ、再認証が必要)。 追加許可を付けない場合、このトークンでできるのは新しいアプリの作成だけです (レコードの操作・設定の編集を任せる場合は、この画面で「データの操作」「設定編集」を選びます)
2. 接続 — アプリのトークンと同じ URL (/api/mcp) に、 発行した AI エージェント連携トークンで接続します。接続すると create_app ツールが使えるようになります
3. 作成と確認・公開 — AI が作成したアプリはドラフト (非公開) 状態で作られます。 内容を確認・調整してから公開します。公開は画面の「公開する」ボタンでも、 AI に publish_app を呼ばせても構いません (どちらも同じ処理・同じ権限です)

参考: AI が create_app に渡すアプリ定義のイメージ (実際は AI が自動で組み立てます):

{
  "name": "問い合わせ受付",
  "icon": "📮",
  "sections": [
    {
      "label": "基本情報",
      "fields": [
        { "code": "title", "label": "件名", "type": "text", "required": true },
        { "code": "detail", "label": "内容", "type": "multi_line_text" },
        { "code": "priority", "label": "優先度", "type": "dropdown",
          "settings": { "options": [
            { "value": "high", "label": "高" },
            { "value": "low", "label": "低" }
          ] } }
      ]
    }
  ],
  "defaultView": { "name": "すべて", "columns": ["title", "priority"] },
  "views": [
    { "type": "kanban", "name": "優先度ボード", "config": { "groupField": "priority" } }
  ]
}

• アプリ定義が不正な場合はエラー詳細が返り、AI が自分で修正して再試行します (壊れた定義がそのまま作られることはありません)
• 作成できるフィールド・ビューの種類は、画面から作れるものと同じです。ただし範囲フィールドだけは create_app では作れません (作成後の設定が要るため)。範囲フィールドを含むアプリは、まず別の型か項目なしで作り、その後 update_form と apply_form で範囲フィールドを追加します
• 同じフィールドコードを 2 つ渡すとエラー (400) になります — どのコードが重複しているか、 そのコードを使っているフィールドが何本あるかが応答に入るので、片方のコードを変えて送り直してください。 なおコードは比較の前に正規化されます (前後の空白を落とす / 半角英数は小文字化 /camelCase・ハイフン・空白は _ に統一)。 そのため taskStatus と task_status のように送った時点では違って見えるコードも重複扱いになります
• フィールドの設定 (settings) に、その型で使えないキーを入れるとエラー (400) になります — 応答にその型で指定できるキーの一覧が入り、綴り違いが疑われる場合は「もしかして」の候補も付きます。 知らないキーが黙って保存され、設定したつもりの機能が無効のまま動く事故を防ぐためです
• フォームは作成と同時に本番へ反映されます (create_app_from_blueprint と同じ扱い)。ただしアプリ自体はドラフト (非公開) 状態なので、レコードの追加・閲覧を始めるには公開が必要です (画面の「公開する」ボタン、または AI からは publish_app)
• 不要になったアプリは delete_app でゴミ箱へ移動できます。最初の呼び出しでは削除されず、残っているレコード件数・参照しているアプリ・止まるデータパイプラインが返るので、それを確認してから件数を添えて再送する形です (復元は画面のゴミ箱から)
• このトークンでできるのは作成のみです。作成後の作り込み (フォーム・ワークフロー等) を AI に任せたい場合は、発行時に設定編集を追加許可してください (後述の「AI によるアプリの作り込み」を参照)。それ以外は画面 (または raxel 組み込みの AI 生成) で行います
• レコード操作も同じ接続でできます — 発行時 (または発行後の変更) に「データの操作」を許可すると、 このトークンの対象アプリに対して create_record /list_records などが使えるようになります。 対象アプリは既定で「このトークンで作成したアプリ」で、既存アプリは管理画面から追加できます。 レコード系ツールは appId を必須の引数に取り、対象外のアプリを指定すると拒否されます。そのアプリが参照している他のアプリ (ルックアップの参照先・集計の集計元・転記アクションの転記先) も対象アプリに入っている必要があります — 参照先の値はレコードの読み書きでそのまま出入りするためで、入っていない場合は「参照先を対象に追加してください」というエラーになります。 実際にできることはトークンを発行した人がそのアプリに対して今持っている権限の範囲に限られ、権限を失えばその時点で使えなくなります。 なお OAuth 接続 (claude.ai のコネクタ等) にはこの拡張は及びません — レコード操作は許可画面で選んだ「特定アプリのレコード操作」の範囲だけです
• 複数のアプリをまとめて作らせたい場合は、create_app の任意引数 componentId で「パッケージ」に紐づけられます (次項「AI によるアプリのグループ管理」を参照)

AI によるアプリのグループ管理 (パッケージ)

複数のアプリ・パイプライン・ポータル等をひとまとめに追跡・管理する仕組みがパッケージです (画面での使い方はアプリストア・パッケージマニュアルの 「導入済みパッケージ」を参照)。AI エージェント連携トークン、または OAuth の 「アプリの新規作成」で接続した AI にも、この管理を任せられます。

• 「パッケージ管理」は独立した許可単位 — フォーム・ワークフロー等の設定編集 (前項) とは別の capability で、AI エージェント連携トークンの発行時、または OAuth「アプリの新規作成」の許可画面で 追加で選びます。契約内のすべてのアプリ等が対象になり (特定アプリだけに絞ることはできません)、 「特定アプリの管理」(OAuth app_manage) では選択できません
• 許可すると、AI は create_app の componentId 引数で新しいアプリをパッケージに所属させたり、以下のツールでパッケージ自体を操作したりできます
• 所属に失敗しても (指定した componentId が存在しない、対象パッケージを操作する権限がない等)、 アプリの作成自体は成功します。create_app の応答の componentAttached (true/false) で所属できたかどうかを確認してください

add_to_component でアプリを追加する場合は、 (管理者またはパッケージ作成者本人) かつ 対象アプリの管理権限の 両方が必要です。アプリ以外 (パイプライン・ポータル・ポータルウィジェット・グループ・スペース) を追加する場合は 管理者限定です (パッケージ作成者であっても、対象がアプリでなければ追加できません)。remove_from_component は対象の種類によらず、 管理者またはパッケージ作成者本人が実行できます。

AI によるアプリの作り込み (設定ツール)

アプリを作った後の「作り込み」— フォームのフィールド構成、ワークフロー、条件付き書式、入力ルール、通知、権限、ビュー、帳票、転記アクション、 公開フォーム、公開ビュー、スケジュール起票、残高設定 — についても、許可した範囲内で AI に任せられます。対話的に「この項目を必須にして」「承認ステータスを追加して」のように 指示しながら、アプリを育てていく使い方を想定しています。

• 領域ごとの許可制 (capability) — フォーム・ワークフロー・条件付き書式・入力ルール・通知・権限・ビュー・帳票・転記アクション・ 公開フォーム・公開ビュー・スケジュール起票・残高設定の 13 領域は、それぞれ個別に許可します。許可していない領域のツールは AI 側のツール一覧に表示されず、 呼び出しても実行できません。ただし「存在するが権限が無い」ことは分かるようにしてあります —tools/list の応答にunavailableTools (提供されていないツールの名前と必要な capability) が入るので、 AI は「この製品にその機能が無い」のか「自分のトークンに権限が無い」のかを区別でき、利用者に何を発行し直せばよいか伝えられます
• 許可するタイミング — OAuth の「特定アプリの管理」を選んだとき (許可画面のチェックボックス)、 または「アプリの新規作成」を選んだとき・AI エージェント連携トークンを発行するとき (どちらも追加で任意選択) に、 許可する領域を選びます。後からの変更は、接続を解除して選び直してください
• フォームの反映は 2 段階 / 項目の削除だけ関門つき — フォームの変更はいったん下書きに保存され、 本番への反映は別のツール (apply_form) で行います。項目の追加・変更だけなら AI がそのまま反映できますが、 既存項目 (またはテーブルの子項目) が消える反映は、消える件数を AI が申告しない限り実行されません。 申告が無い / 件数が違う場合は反映せずに差し止め、「何が消えるか」「値が失われるレコード件数」 「消える項目を参照している主な設定」を AI に返します (画面の確認ダイアログと同じ内容です)。 なお反映すると、フォームのテストモードで作ったテストレコードは画面から反映したときと同様に破棄されます ワークフロー・条件付き書式・入力ルール・通知・権限・ビュー・帳票・転記アクションの変更は保存と同時に反映されます。 下書きの段階でうっかり項目を落としてしまった場合も、反映する前なら元に戻せます — get_form が落ちた項目 (droppedFromDraft) を返すので、AI はそれをそのまま下書きへ戻せます
• フィールドの設定キーは型ごとに決まっている — フォーム設定ツール (update_form) と アプリ作成 (create_app / create_app_from_blueprint) は、 その型に無い設定キーを送ると保存せずに差し止め、応答に「指定できないキー」 「綴りの近い正しいキー」「その型で指定できるキーの一覧」を返します。以前は知らないキーが黙って保存され、 get_form で読み返しても間違いに気付けなかったため、設定したつもりで効いていない状態 (例: 二重予約防止の判定単位のキー名を間違えて、アプリ全体で重複禁止になっている) が 運用に入るまで分からない、という事故が起きうる形でした。 なお、以前の仕様で既に保存されてしまった不明なキーは、そのまま送り返す限り差し止めません (無関係な変更まで保存できなくなるのを避けるため)。 キー名だけでなく値も検証されます — 保存できても実行時に黙って無視される値 (日付項目の既定値の語彙外の文字列、選択肢に無い既定値、ビュー絞り込みの日付として読めない値) や、 関連レコード集計の集計元アプリに存在しない項目への参照 (紐づけキー・絞り込み条件・集計対象) は、下書きの時点で理由と正しい形を添えて差し止めます
• 範囲フィールドと二重予約防止は update_form から設定する — 範囲フィールド (range) は create_app では作れず、update_form + apply_form で追加します。設定キーはbaseType (日付・日時・時刻・数値。作成後は変更不可)、preventOverlap (重複を禁止する)、overlapScopeFieldCodes (重複を判定する単位。フィールドコードの配列で最大 3 件) です。 単位を省略するとアプリ全体で 1 グループ = どの会議室でも同じ時間帯を取れない、という設定になります (範囲フィールドの解説も参照)
• ビューは一覧・カレンダー・カンバン・ガント・グラフの 5 種 — ビュー設定ツールが作成・編集できるのはこの 5 種です。 クロス集計・マトリクス・カード・リソースタイムラインは AI からは読み取り専用で、 画面のビュー設定から作成してください。これらのビューが AI の操作で消えることはありません(置き換えの対象から外れています)
• ガントの自動配置は AI からは有効にできない — 自動配置 (CPM) とプロジェクト開始日は、 有効にすると横棒をドラッグするたびに依存する他のレコードの日付もまとめて更新されるため、 画面のビュー設定から人が有効にする項目です。既に有効になっているビューを AI が編集しても、 この設定は維持されます
• 帳票は「AI が作れる内容だけでできているもの」が対象 — 帳票設定ツールはテキスト・フィールド・表・ 罫線・囲み枠・QR/バーコード・グラフ・レコードの添付画像を配置できますが、アップロードした画像やテンプレート PDF を使っている帳票、ページ送りルール・複数ページを使っている帳票、 要素をグループ化・ロックしている帳票、ラベル面付け (まとめ印刷) を使っている帳票は読み取り専用です。それらは画面の帳票設定から編集してください (置き換えの対象から外れているので、AI の操作で消えることはありません)
• ロゴなどの画像は AI では貼れない — AI はファイルをアップロードできないため、 固定の画像を帳票に貼るのは画面の帳票設定からになります (レコードの添付ファイルフィールドの写真を出す要素は AI からも配置できます)
• 転記アクションの転記先は「この接続が管理しているアプリ」だけ — 転記アクション (レコードを別のアプリへ写す設定) は別アプリへ行を書き込む経路になるため、転記先に指定できるのは その接続で管理しているアプリに限られます。加えて、操作した本人がその転記先アプリの管理者である 必要があります。管理対象外のアプリを指している既存の転記アクションは読み取り専用になり、AI の操作で消えることはありません
• 上書き (upsert) の一致キーは慎重に — 転記アクションには「一致キーが同じレコードが あれば上書きする」モードがあります。キーに使えるフィールドの型 (複数値になる型は不可、 ユーザー選択などは単一選択のみ) はサーバーが検証しますが、「そのキーで対象が一意に決まるか」 はサーバーには判断できません。日付だけをキーにすると別の人のレコードを上書きしうるため、 AI が一意でないキーを 1 つだけ指定した場合は応答に警告を返します
• 自分を狙って対象にしている権限行は変更不可 — 権限設定ツールで、操作した本人 (トークン発行者・OAuth 許可者) を直接対象とする行や、本人が所属するグループ・組織の行を 追加・変更・削除しようとすると拒否されます。応答にはどの行が原因かが入ります。 自分の権限を変えたい場合は画面から行ってください
• 全員向けの権限行は「変更内容を書き写せば」変更できる — 「全員に付いている既定の閲覧・追加・編集・削除を絞る」のは本来やるべき作業なので塞いでいません。 ただし全員向けの行は本人にも効くため、confirmSelfPermissionChange にその行の変更前 → 変更後を書き写した場合だけ通ります (現在値を読まないと書けません)。 アプリ権限・レコード権限・フィールド権限の 3 種類で同じ扱いです
• レコード権限の「はじめての構築」は書き写しで通せる — レコード権限は「どのルールにも一致しなければ既定で許可」のため、ルールが 1 つも無い状態からの 新規構築は既定を狭める方向にしか働きません。そのため「登録した本人だけが見られる」のような構成 (作成者ルール + 全員向けの不許可ルール) も、書き写しの申告つきで AI から設定できます (自分の userId を直接指定する行だけは常に画面から)。2 回目以降の変更は上の扱いに戻ります

設定ツールの一覧 (capability 名つき)

領域ごとにツールが 2 つ (get_* = 現在の設定の取得、set_* = 全量置換) あります。 トークンに付いていない領域のツールは AI のツール一覧に出ませんが、名前と必要な capability はtools/list のunavailableTools で確認できます。

公開フォーム / 公開ビューを AI から設定する

公開フォームと公開ビューは、 画面だけでなく MCP からも設定できます(settings:public_forms /settings:public_views を付けたトークンが必要です)。 この 2 領域だけは認証なしで社外から到達できる面を作るので、他の設定領域とは別の関門を置いています。

• 作成と公開は 2 手に分かれる — 新規作成のenabled の既定は false です (画面の新規作成モーダルは既定 ON ですが、あちらは人が公開フィールドのチェックリストを見ながら決めています)。 気付かないうちに無防備な公開ページができることはありません
• 公開されるものを書き写して申告する —enabled: true にする呼び出しはconfirmPublicExposure を要求します。 「この呼び出しの後にログイン不要で到達できるもの」を、名前・公開されるフィールドコード・ レコードの範囲 (all = 絞り込み条件が 1 つも無い /filtered)・配信される選択肢まで含めて申告し、サーバーの計算と完全に一致しないと書き込みません。 一致しない場合は 400 とともに正しい申告値そのものが返るので、読めば必ず通せます
• 「どこへ出て行くか」も申告する — 公開フォームに通知先メールアドレスを設定すると、送信された内容と送信者の IP アドレスが、送信のたびにそのアドレスへ転送されます。 外部のアドレスを入れれば、匿名の訪問者が入力した個人情報がそのまま社外へ出続けることになるため、 転送先も confirmPublicExposure のnotifyEmails に書き写す必要があります。 応答の publicExposure[].outbound には、 転送先のほか自動返信・外部ホストのロゴ・アクセス解析・送信後のリダイレクト先など 「データや訪問者が外部へ出る経路」がすべて並ぶので、設定した本人以外にも何が起きるかが分かります
• 自動返信の宛先は訪問者が入力したアドレスだけ — 自動返信メールの宛先に指定できるのは、 そのフォームの入力欄にあるメールアドレス項目に限られます。入力欄に無い項目 (固定値が入る項目など) を 宛先にして、送信内容を第三者へ送る形は作れません
• 選択肢は「レコードとは別の漏れ口」です — ドロップダウンなどの選択肢はフィールドの定義であってレコードではないため、公開ビューの絞り込み条件では隠せません。 「社内限定の案件名が選択肢に並んでいる」ようなフィールドを公開すると、その名前がそのまま社外へ配信されます。 そのため選択肢は申告対象に含めてあり (fieldOptions)、公開する前に必ず AI の目を通ります。 社外に出せない選択肢がある場合は、その項目を公開対象から外すか、選択肢そのものを整理してください
• フィールドの定義は必要な分だけ配信されます — 公開ページに返すのは、 その項目を描くのに要る表示・入力の設定だけです。計算式、ユーザー選択の候補にした利用者の氏名、 ルックアップ・集計・関連レコードの参照先、AI 生成の指示文は公開ページには出ません
• AI が触れないもの — 公開 URL の token / slug、パスワード保護 (設定も解除もできません)、 意匠 (配色・ロゴ・テーマ)、送信後のリダイレクト先、アクセス解析 ID は MCP からは扱えません。 人が画面で掛けた保護を AI が外すことはありません
• 下書きのアプリは公開できない — アプリが下書き (未公開) の間はenabled: true にできません (enabled: false で設定だけ先に保存しておくことは可能です)。 公開中のアプリをメンテナンス中に切り替えると、既に公開している URL の配信も止まります
• 公開をやめたことは応答で確認できる — 応答のpublicExposure が空配列になり、 「認証なしで到達できるものはありません」と返るので、画面を見に行かなくても止まったことが分かります

「起きるはずのことが起きていない」に気づく仕組みを組む

ここまでの設定は、どれも何かが起きたことに反応する仕組みでした — レコードが作られた、ステータスが変わった、条件に当てはまった。 ところが現場の困りごとの多くは逆側にあります。 「返却予定日を過ぎているのに、返却の記録が無いことに誰も気づかない」 「点検の予定日が来たのに、点検レコードがそもそも起きていない」 「付与した残日数の期限が切れたのに、残ったままになっている」。レコードが 1 件も無いので、何のきっかけにもなりません。 こうした要望に対して、一覧ビューを作って人が毎朝見に行く運用しか組めない、という形になりがちです。

この面も AI に任せられます。次の 3 つは「いつ・誰について、何かが存在するはずか」という 同じ考え方を共有していて、気づく → 起票する → 期限で消すまでを一続きに組めます。

• 「いつ・誰について」の決め方は 3 通り — 暦の規則 (毎日 / 毎週◯曜 / 毎月◯日 / 毎年◯月◯日)、 起算日からの周期 (契約日の 12 か月後、以後 12 か月ごと)、 別のアプリに登録済みの日付 (シフト表の予定日)。 このうち周期の起算日に「別のアプリ」を指せるのは未登録チェックだけで、 スケジュール起票の起算日は設定しているアプリ自身のレコードに限ります (起票で別のアプリの日付を使いたい場合は「登録済みの日付」の方を選びます)。 「誰について」は利用者・組織・グループのほか、 別のアプリのレコードを母集団にすることもできます (例: 貸出中の備品ごとに 1 件あるはず)
• 期限つき残高の失効は、残高設定だけを直せば追従します — 期限を設定した残高は、 失効ぶんを差し引くレコードを自動で作る起票ルールを 1 本ぶん従えます。そのルールはget_scheduled_rules では読み取り専用 (owned_by_balance_setting) で返り、 AI が直接書き換えることはできません。正本は残高設定側なので、二重に管理して食い違う状態を作りません
• スケジュール起票と残高設定はコースによって制限されます — ライトコースでは 新規作成と、停止中のものの再開ができません (すでに動いているものはそのまま続き、確認・停止・削除は行えます)。 制限に当たった場合は、その理由が応答に入るので、AI は「自分の入力が悪い」と誤解せずに利用者へ伝えられます
• くわしい考え方と画面からの設定は通知・スケジュール起票・残高設定の各マニュアルを参照してください

本番データを汚さずに動作確認する (テストレコード)

AI が組んだ設定 (ルックアップのコピー、関連レコード集計、入力ルール、フィールド権限など) が本当に効くかは、 レコードを 1 件通してみないと分かりません。そのために、本番データに混ざらないテストレコードを MCP から作成・照会できます。

• 使い方 — create_record /list_records にisTest: true を付けます。 アプリの作り込みを許可した接続 (フォーム設定の capability を持つ AI エージェント連携トークン) と、アプリ管理者の接続で使えます
• 本番と混ざりません — テストレコードは通常のレコード一覧・集計・関連レコード集計に 現れず、重複禁止や二重予約防止の判定も消費しません。照会はlist_records に isTest: true を付けたときだけ返ります
• ルックアップの動作確認もできます — テストレコードのルックアップは、参照先アプリのテストレコードを優先して解決します (見つからなければ本番のレコードで解決)。 マスタ + 明細の構成なら、マスタ側にテストレコードを 1 件作り、明細側のテストレコードから そのキーを参照する、という一連の動作確認が本番データを 1 件も作らずに行えます
• 関連レコード集計も確かめられます — テストレコードの集計値はテストレコードの子だけを数えます (ルックアップと同じ世界分離。 本番の集計値にテストが混ざることもありません)。マスタ側にテスト親、集計元に テストの子を数件作れば、件数・合計が実際に増えることを確認できます
• 「その人にはどう見えるか」も確かめられます — preview_record_as に 利用者 id を渡すと、その人の資格でテストレコードを開いたときの姿 (見える値・ 見えないフィールドと理由・開けるかどうか) を返します。権限設定の検証を 「拒否されることの確認」だけでなく肯定形の証拠で行えます
• テストレコードで確かめられないもの — 通知・リマインダー・ スケジュール起票はテストレコードでは発火しません。ただし乾式実行ファミリーで「動いたら何が起きるか」をテスト標本に対して 評価できます: preview_reminders (リマインダー) / preview_scheduled_rules (スケジュール起票 — いつ・どの主体に・どんなデータで起票されるか) / preview_absence_check (未登録チェック — 誰が未登録と判定され、誰に届くか) / preview_action (転記アクション — ボタンを押したら何が作られるか) / preview_print_layout (帳票 — 紙からはみ出す要素・空欄になる差し込み)。 いずれも通知・レコード・台帳は作られません。実際の発報だけは、 納品後に本番レコード 1 件 + get_notification_deliveries で確認してください。 その際、自分の操作による自分宛ての通知は作られないため、 書き込みと宛先が同一人物にならないように受け入れ試験を組んでください
• 後始末は自動です — フォームを本番に反映する (apply_form) と、そのアプリの テストレコードは画面のテストモードと同様に一括破棄されます (破棄される件数は反映の確認応答に入ります)。 設定を直して同じ標本で再検証を続けたい場合は、apply_form に keepTestRecords: true を付けると破棄せず残せます (残した標本は項目削除の値掃除を 本番レコードと同様に受けるため、反映後もフォーム定義と整合したままです)

どのアプリを触れるか

つまり、すでに運用中の既存アプリの設定を AI に触らせられるのは「特定アプリの管理」で 本人が明示的に選んだ場合だけです。共有して使う AI エージェント連携トークンでは、そのトークン自身が作ったアプリ 以外は編集できません。

この「触れるアプリ」の範囲は、書き込む先だけでなく読み取る先にも効きます。前項の 3 つの設定は他のアプリを指せる数少ない設定で、 起票先 (レコードを作る先)・起算日の参照元・発生日の参照元・対象者の参照元の 4 か所がそれに当たります。 いずれも範囲外のアプリを指定すると拒否されます。

書き込みだけを止めて読み取りを許す、という扱いにはしていません。 「アプリ B に 15 日のレコードがありません」という通知はB の中身についての情報だからです。 アプリ A だけを任せたトークンが、通知を経由して B のレコードの有無を知れる状態を作りません。

• 範囲外を指している既存の設定は、消えずに読み取り専用で見えます — 人が画面で作ったルールが範囲外のアプリを参照している場合、そのルールはeditable: false と理由つきで返り、 全量置換の対象から外れます (AI が送らなくても消えませんし、送ると差し止められます)。 そのとき、範囲外のアプリを指している部分 (起票先や発生の定義) は応答から伏せられます —アプリの id も名前も出ません。「読めない範囲の設定がここにある」ことだけが伝わります
• 範囲を広げる手順はトークンの種類で違います — 複数アプリを扱えるトークン (システム管理 → 「AI エージェント連携」で発行したもの) なら、管理者が同じ画面で そのトークンの「対象アプリ」に追加すれば広がります。一方、1 つのアプリ専用の接続 (claude.ai のコネクタなどで「特定アプリの管理」を選んだもの) には 対象アプリを増やす口がありません — 扱いたいアプリを選び直して改めて連携を許可する(認可画面をやり直して新しい接続を作る) か、複数アプリを扱えるトークンを管理者に発行してもらってください
• 拒否されたときの応答にも、何を拒んだか・いま指定できるアプリの一覧 (名前と id)・ 誰が何をすれば広がるかが入ります。AI はそれを読んで「これは自分では直せない、人に頼む作業だ」と 判断できるので、当てずっぽうの再試行を繰り返さずに済みます

設定ツール一覧

すべての更新ツールは全量置換です — 送った内容がその設定全体を置き換えます。 各ツールの説明に「必ず先に対応する get_* で現在の内容を取得し、それに変更を加えた全体を送る」ことを 明記してあり、AI はそれを読んだうえで呼び出します。利用者が毎回指示する必要はありません。

そのうえで、既存の項目が失われる更新はサーバーが一度差し止めます。送信内容から既存の項目 (フォームのフィールド、ワークフローのステータスや遷移、通知ルール、権限の対象など) が欠けている場合、 または項目数が減っている場合に、何がいくつ消えるのかを応答で返して保存を止めます。意図した削除であれば AI がその件数を添えて送り直し、意図しない部分送信であれば AI はその時点で気付いて現在の内容を取得し 直します。設定をまるごと失う事故は、AI の遵守ではなくこの仕組みで防いでいます。

なお、項目数が変わらない全面的な差し替え (例: 3 件のルールを別の 3 件に入れ替える) は「消えた」ではなく 「書き換えた」として扱われ、差し止めの対象にはなりません。設定変更の履歴は アプリの設定変更履歴に残るため、誰がいつ何を変えたかは後から確認できます。

アプリを設定ごと 1 回で作る (create_app_from_blueprint)

「アプリの新規作成」に加えて設定編集も許可した接続では、create_app_from_blueprint が使えます。アプリ定義 (フィールド・フォーム) と、ワークフロー・ビュー・権限・通知・転記アクション・ 帳票・入力ルール・条件付き書式をまとめて 1 回で作れるツールです。中身は上記の設定ツールを 依存順に呼んでいるだけなので、検証・削除の差し止め・設定変更履歴はすべて同じように働きます。

• 新規作成専用です。既存アプリには使えません — 設定はすべて全量置換なので、既存アプリに一括適用すると書かなかった設定がアプリ全体の規模で消えてしまうためです。既存アプリの設定変更は個別の設定ツールで行います
• 途中で失敗しても、そこで止まりません。アプリ本体の作成に失敗したときだけ中断します。設定の適用は 1 つ失敗しても残りを続け、どの設定が成功し・どれが失敗したかを応答で返します。失敗した設定は、作られたアプリに対して個別の設定ツールで当て直せば収束します
• フォームは本番に反映されます (設定がフィールドを参照できる必要があるため)。ただしアプリ自体はドラフト (非公開) 状態のままなので、レコードの追加・閲覧を始めるには公開が必要です (画面の「公開する」ボタン、または AI からは publish_app)
• アプリ作成時に自動で作られる権限行 (作成者の管理者行・Everyone 行) はそのまま維持され、AI が指定した行はその後ろに追加されます。自分を狙って対象にしている権限行 (直接の指定・所属グループ・所属組織) の変更は従来どおり画面からの操作専用です

search_docs (マニュアル検索)

raxel のマニュアルをキーワード検索するツールです。許可設定に関わらずすべての接続で常に使えます(読み取り専用・LLM 呼び出しなし)。「この機能はどう設定するのか分からない」場面で、AI が設計・実装の前に 自分で調べるために使います。

権限とセキュリティ

• すべての操作は REST API と同じ認可 (トークン権限・レコード権限・フィールド権限・ワークフローの遷移ルール) とレート制限のもとで実行されます。MCP だから緩くなることはありません
• トークン発行者がアプリへのアクセス権を失うと、そのトークンも使えなくなります
• アプリ設定の編集は、上記「AI によるアプリの作り込み」で明示的に許可した領域・アプリに限られます。メンバー・スペース管理、アプリ API トークンの発行は MCP からは一切できません (画面での操作専用)
• アプリの公開 (publish_app) と削除 (delete_app) は、AI エージェント連携トークンが自分で作成した (または管理を許可された) アプリに対してのみ行えます。画面の操作と同じ処理・同じ権限で、実行時にトークン発行者がそのアプリの管理者であることも確認されます。削除はゴミ箱への移動で、実行前に影響件数を確認する関門があります (復元は画面のゴミ箱から)
• トークンは AI ツールの設定ファイルに保存されます。共有端末では取り扱いに注意し、不要になったら失効してください

トラブルシューティング

運用のヒント

1. AI にはまず get_app_overview を呼ばせて、フィールド構成を把握させます (公式サーバーの案内文にも組み込み済みなので、通常は自動で行われます)
2. ドロップダウン等の選択肢フィールドは内部値で保存されています。AI への指示では「選択肢のラベル」で話して問題ありません — 対応表を AI が自分で解決します
3. ステータス変更は「実行可能な遷移」の制約に従います。ワークフローの遷移ルールで AI に許可する操作範囲を設計できます (例: 完了への遷移は人間のみに制限)
4. まずは「閲覧のみ」トークンで試し、運用が固まってから書き込みを許可するのが安全です
5. 設定ツール (フォーム・ワークフロー等) も同様に、まず必要な領域だけを許可し、対話しながら少しずつ範囲を広げるのが安全です