Jicoo MCP Serverで何ができる？予約操作と会議データ取得の権限設計・接続手順

導入

一言で言うと、Jicoo MCP ServerはAIクライアントから、Jicooの予約操作と会議データ取得を自然言語で呼び出すための接続口です。

この記事を読むと、次の3点を判断できます。

• MCP経由で扱える予約操作と会議データの範囲
• OAuthで何を許可し、何を許可しないかという権限設計の考え方
• 自社のAIクライアントと契約条件で接続できるかを確かめる手順

いま起きている変化は、「日程調整のAI化」が構想から実装の段階に入ったことですね。Jicooは2026年5月15日にMCPサーバーの公開を告知しました。開発者向け資料（Jicoo Developer Portal「Jicoo MCP Serverの使い方」、2026年10月13日更新）には、予約の作成・更新・日程変更・取消しと、文字起こし・リキャップ取得のツールが掲載されています。

一方で、開発者や情シスの方が最初に抱く問いは、機能の多さではないはずです。

「AIに、どのチームの、どの予約を、どこまで触らせてよいのか」

本記事はこの問いを中心に組み立てます。記載内容は2026年10月19日時点の公開資料に基づきます。実アカウントでの接続・認可・操作の成功を保証するものではありません。

手作業の運用と、MCPを使った運用の違い

ある情シス担当者の場面を想像してみてください。

営業部から「AIアシスタントに商談の日程変更を任せたい」と相談が来ます。しかし変更依頼は、Slack、メール、口頭とばらばらに届きます。担当者はカレンダーを開き、予約管理画面で該当予約を探し、日程を変え、関係者に連絡します。議事録も別のツールで探します。

一件ずつなら小さな作業です。ただ、商談が重なる月末には「どの予約を誰が変えたのか」が追えなくなります。現場は悲鳴を上げているはずです。そこに「AIに任せたい」という声が加わると、情シスは権限の不安から判断を止めてしまいがちですね。

転機になるのは、読み取りから始めて、書き込みは人が承認するという段階設計に切り替えた瞬間だと考えます。

観点	手作業中心の運用	MCPを使った運用
予約の検索	管理画面で条件を指定して探す	「来週の〇〇社の予約を一覧して」と依頼する
日程変更	画面操作と個別連絡	AIが変更案を提示し、人が承認後に実行する
会議内容の確認	録画や議事録を別ツールで探す	予約に紐づく文字起こし・リキャップを取得する
権限の把握	担当者の記憶に依存しがち	OAuthで許可した範囲を記録して管理する

疲弊の原因は、作業量そのものよりも「誰が何をしたか分からない」状態にあることが多いです。権限を設計してから任せることで、AI活用とチームの心理的安全性を両立できます。

外部ツールとの連携全般は連携カテゴリでも整理しています。

連携前の確認事項

Jicoo MCP Serverの概要

まず、似た言葉を切り分けておきます。

• MCP Server：AIクライアントが呼び出せるツール群を公開する仕組みです。JicooではStreamable HTTPで接続します。
• OAuth接続：JicooのMCP接続は、公開資料によるとOAuth 2.1とDynamic Client Registration（DCR）を使います。MCP接続に固定のAPIキーは使えません。
• REST API：APIキーを使う従来型の連携です。MCPとは別の提供形態として整理してください。

REST APIを使った連携の考え方はAPIタグの記事一覧が参考になります。

できる操作一覧

開発者資料（2026年10月13日更新）に掲載されている、本記事の対象ツールは次のとおりです。

目的	MCPツール	押さえておきたい点
予約を調べる	getBookings、getBooking	一覧取得と個別詳細の取得は別ツールです
予約を作成する	createBooking	書き込み操作です
予約を更新する	updateBooking	日程変更とは別ツールです
日程を変更する	rescheduleBooking	参加者への影響が大きい操作です
予約を取り消す	cancelBooking	資料上はホストとしての取消しと説明されています
予約に紐づく会議データを読む	getBookingTranscripts、getBookingRecaps、getBookingRecordings	文字起こし・リキャップ・録画フィールドを区別します
リキャップから会議データを読む	listRecaps、getRecap、getRecapTranscript、getRecapRecording	recaps.readが必要とされています

注意したいのは、録画フィールドを取得できることと、すべての会議に録画が存在することは別という点です。データが存在しない会議では、当然ながら取得結果も空になり得ます。

また、資料には予約ページの作成・削除、稼働時間設定、Webhook管理などのツールも掲載されています。本記事では扱いませんが、許可範囲を広げると影響が及ぶ操作として把握しておくべきですね。

プランとクライアント条件

• Jicooの料金表では、MCP／AIエージェント連携がIndividual、Team、Business、Enterpriseで「対応」と表示されています。
• 2026年5月15日の公開告知では、無料プランを含む全プランで利用可能とされています。
• 開発者資料では、Webhook配信はTeamプラン以上と記載されています。

ただし、これだけで「すべてのAIクライアントと契約構成で同じ条件で使える」とは言えません。AIクライアント側のプラン・管理者設定・カスタムコネクタの可否は、各クライアントごとに公開時点で要確認です。

OAuthと権限設計

権限設計は、次の4つの問いに分けると整理しやすいです。

1. どのチームを対象にするか：認可時に利用チームを選ぶ旨が、Claude Code向け手順（2026年9月8日更新）に記載されています。
2. 予約を読むだけか：一覧・詳細・空き枠の参照までに留めるか。
3. 予約を書き換えるか：作成・更新・日程変更・取消しのどこまで許すか。
4. 会議データを読むか：文字起こしやリキャップには商談内容や個人情報が含まれ得ます。

スコープ名の表記には注意が必要です。2026年10月13日更新の資料ではbookings.read、bookings.write、recaps.readなどが例示されています。一方、共通セットアップガイドには旧形式の表記が残っています。最新資料を優先し、実際の表記は公開時点で要確認としてください。

さらに大事なのは、scopes_supportedは要求できるスコープの例示であり、その接続で付与済みの権限ではないという点です。Jicooの資料も、実際の付与内容は認可画面で許可した内容によると説明しています。

検証時は、次のような記録表を用意しておくと後から説明しやすくなります。

確認項目	記録する内容
AIクライアント	名称、契約プラン、管理者設定の有無
認可対象	選択したチーム、認可したアカウント
認可画面の表示	表示された権限の文言
付与結果	要求スコープと付与スコープ
実行結果	読み取り・各書き込み操作が成功したか

「何を要求できるか」ではなく、「何が付与され、何を実行できたか」を残す。これが情シスとして説明責任を果たすための最小単位だと考えます。

設定手順（PC）

初回の接続と検証は、PCで行うことをおすすめします。認可画面の確認や記録がしやすいためです。

手順

1. 利用するAIクライアントを決める 公開資料には、Claude、Claude Code、Codex、Gemini CLI向けの手順が掲載されています。社内で許可されているクライアントと契約プランを確認します。

2. クライアント別の接続URLを確認する 共通ガイドではhttps://mcp.jicoo.com/mcpが案内されています。ただしClaude Code向け手順ではhttps://mcp.jicoo.com/のルートURLが指定されています。/mcpではトークン更新に失敗し得るという注意があるためです。

3. AIクライアントにMCPサーバーを追加する クライアントのMCPサーバー（コネクタ）追加設定から、確認したURLを登録します。追加方法の詳細はクライアントごとに異なります。

4. OAuth認可を行う Jicooへのログインを求められたら、利用するアカウントでログインします。対象チームを選び、表示された権限の内容を記録します。継続利用には、offline_accessによる更新トークン取得が案内されています。

5. 読み取りで疎通確認する 「今週の予約を一覧して」のように、getBookingsが呼ばれる依頼から試します。予約が想定どおりのチーム範囲で表示されるかを確認します。

6. トークン更新を確認する 公開資料ではアクセストークンの有効期間は1時間とされています。Claude Code向け手順の提案どおり、70分以上経過後に再度ツールを呼び出し、再認可なしで動くかを確かめます。

7. テスト用チームで書き込みを検証する 本番の予約は使いません。作成→取得→更新／日程変更→取消しの順に、一つずつ明示承認しながら試します。

実務的には、手順5の時点で「見えてはいけない予約が見えていないか」を確認するのが最も重要です。ここで範囲が想定と違えば、書き込み検証に進む前に認可をやり直せます。

設定手順（スマホ）

スマホでの利用は、PCで検証を終えた後の「確認・承認の端末」として位置づけるのが現実的だと考えます。

手順

1. 利用するAIクライアントのモバイル対応を確認する カスタムMCPサーバーをモバイルアプリから追加・利用できるかは、クライアントによって異なります。公開時点で要確認です。

2. PCで追加した接続がモバイルで使えるか確認する 同じアカウントでモバイルアプリにログインし、Jicooのツールが呼び出せるかを確かめます。

3. 認可を求められた場合は画面の内容を確認する モバイルブラウザで認可画面が開く場合があります。小さな画面ではチーム選択や権限の文言を見落としやすいので、PCで記録した内容と一致するかを確認します。

4. まずは読み取り用途に限定する 移動中に「次の商談の予約詳細を出して」と確認する用途から始めます。

5. 書き込みは承認ステップを省略しない 日程変更や取消しをスマホで実行する場合も、日時・タイムゾーン・参加者のプレビューを確認してから承認します。

現場感としては、スマホで一番価値が出るのは「移動中に次の商談の予約と前回のリキャップをすぐ確認できる」という場面ですね。書き込みよりも、確認の速さが体験を変えます。

連携後の運用例

段階導入の考え方

Jicooの公式解説（2026年9月7日）では、「空き枠・予約の参照→人の確認を挟む予約操作→管理操作」という段階導入が提案されています。これは導入実績ではなく運用例ですが、権限設計とよく噛み合う考え方です。

段階	AIに任せること	人が担うこと
1. 参照	予約一覧・詳細、会議データの取得	結果の正しさを確認
2. 承認付き操作	作成・更新・日程変更の案を作る	内容を確認して承認
3. 管理操作	対象を限定した定型作業	範囲と結果の定期点検

書き込み操作の安全策

予約の書き込みは、相手方にも影響します。次の流れを推奨します。

1. 候補を表示するだけで止める AIには、まず変更案を出させます。
2. プレビューを再表示する 日時、タイムゾーン、参加者、担当者を確認します。海外の相手とはタイムゾーンのずれが起きやすいです。
3. 担当者が明示的に承認する 「この内容で変更してよいですか」に人が答えてから実行します。
4. 実行結果を照合する 予約ID、対象者、変更後の状態、通知の有無を確認します。
5. 取消しは別枠で確認する cancelBookingは作成や更新とは別の確認対象にします。取り消した予約の復旧手順も事前に決めておきます。

MCPの仕様でも、ツール実行を人が拒否できる関与と確認UIが推奨されています。ただし、プレビューや承認の仕組みがJicooと全AIクライアントで標準実装されているとは限りません。これは推奨する運用設計として、チームのルールに落とし込んでください。

応用：会議データと日程変更をつなぐ

ツールなしでは手間がかかる応用例を一つ紹介します。

1. getBookingsで、今週の特定顧客との予約を一覧します。
2. getBookingRecapsで、前回の商談リキャップを取得します。
3. リキャップから「次回までの宿題」と「次回の想定日程」をAIに要約させます。
4. 次回予約の日程変更案を作らせ、担当者が承認してからrescheduleBookingを実行します。

さらに、listRecapsとgetRecapを使うと、予約ページ経由ではなくカレンダーから直接作成した予定のリキャップも対象になると説明されています。予約起点とリキャップ起点の2系統を使い分けると、会議データの取りこぼしを減らせますね。

会議前の準備にかかっていた細かな探し物が消え、商談そのもの、つまりコア業務に集中できる。この体験こそが価値です。会議運用の工夫は会議タグの記事でも紹介しています。

失敗時の対処

症状	考えられる原因	対処
接続直後に401が返る	未認証の状態	公開資料上、未認証接続時の401は認可フローの起点です。クライアントの認可手順を進めてください
約1時間後にツールが使えなくなる	アクセストークンの期限切れ、更新トークン未取得	offline_accessを含めて再認可します。Claude Codeでは接続URLがルートになっているか確認します
リキャップ系ツールが使えない	旧接続でrecaps.readが付与されていない	公開資料の案内どおり、クライアントから再接続します
想定した予約が表示されない	認可時に別チームを選択した	接続を解除し、対象チームを選び直して再認可します
文字起こし・録画が取得できない	その会議にデータが存在しない	Jicoo上でデータの有無を確認します。予約IDとrecapIdの取り違えも確認します
書き込み操作が失敗する	書き込み権限が付与されていない、対象外の予約	付与スコープの記録を確認し、必要なら認可をやり直します
誤って予約を変更・取消しした	承認ステップの省略	Jicooの予約管理画面で状態を確認し、相手方への連絡要否を判断します

誤操作が起きたときに個人を責めると、チームの雰囲気が悪くなり、AI活用そのものが止まってしまいます。誤操作は「承認ステップのどこが抜けたか」というプロセスの問題として振り返る。それが心理的安全性を保つ運用だと考えます。

なお、AIクライアントごとのエラー表示やログの見方は異なります。詳細は各クライアントの公開資料で要確認です。

組み合わせて運用を最適化する

MCPは万能の自動化基盤ではありません。人が対話で判断する業務に向いています。定型の処理は、ほかの仕組みと役割分担すると運用が安定しますね。

仕組み	向いている用途
MCP Server	対話的な予約確認、承認付きの変更、会議データの要約
REST API	決まった条件での定期処理、自社システムへの連携
Webhook	予約発生時の通知や後続処理
Slack通知	チームへの予約状況の共有
カレンダー・Web会議連携	ダブルブッキング防止、会議URLの自動発行

組み合わせのポイントは次の3つです。

• 予約の土台はJicooの標準機能で固める：Googleカレンダー／Outlook連携や、Zoom・Google Meet・Teamsの会議URL自動発行は、MCP以前の前提です。
• 担当者の割り当てはラウンドロビンに任せる：AIに担当者を選ばせるより、ルールで決まる仕組みの方が説明しやすいです。
• 変更の可視化は通知で補う：MCP経由の操作がSlack通知やWebhookの対象になるかは公開時点で要確認です。検証時に合わせて確認してください。

AI活用の全体像はAIタグの記事、予約運用の基本は予約タグの記事にまとめています。

今後の見立てとしては、MCP対応そのものは国内の業務SaaSでも珍しくなくなっていくと考えます。差がつくのは、「どこまで任せ、どこで人が止めるか」を説明できる組織かどうかではないでしょうか。

まとめ

• Jicoo MCP Serverでは、予約の参照・作成・更新・日程変更・取消しと、文字起こし・リキャップ・録画フィールドの取得ツールが公開資料に掲載されています（2026年10月19日時点）。
• 接続はStreamable HTTPとOAuth 2.1＋DCRです。固定APIキーは使えず、REST APIとは別物として扱います。
• 接続URLやスコープ表記は資料間で差があります。クライアント別に確認し、付与結果と実行結果を記録します。
• 権限は「チーム」「予約の読み取り」「予約の書き込み」「会議データ」の4層に分けて考えます。
• 書き込みは、プレビューと人の承認を挟む運用で守ります。

次の一歩としては、テスト用チームで読み取り専用の疎通確認を一度行い、付与された権限を記録することから始めてみてください。そこで見えた範囲が、社内でAIに任せる業務を決める土台になります。

ほかの連携ノウハウはブログでも随時紹介しています。