Claude Media
Claude kickflow連携の設定方法とできること
Claude CodeMCPClaude連携チュートリアル

Claude kickflow連携の設定方法とできること

Claudeとkickflowをつなぐと、稟議やチケットの照会・作成を自然言語で頼めます。アクセストークンの発行からMCPサーバーの追加、権限設計の注意点までを手順で確認します。

読了目安 約8分

Claude kickflow連携とは — 何ができるか

kickflowは、稟議申請や複雑な承認ルート設計、組織図管理を扱うクラウド型のワークフローシステムです。申請や承認のフローをシステム上で電子化し、誰の承認待ちで止まっているかを可視化する用途で導入されています。Claude kickflow連携とは、kickflow公式が公開するMCPサーバー(@kickflow/mcp-server)をClaude Codeに接続し、会話からkickflow APIを呼び出せるようにする仕組みです。

接続すると、「チケットIDxxxの申請内容を確認して」「カテゴリの一覧を教えて」のような依頼を、kickflowの管理画面を開かずに処理できます。BacklogのMCPサーバーが機能ごとに個別のツール名を持つのに対し、kickflowのMCPサーバーは3つの汎用ツールでAPI全体を操作する設計になっている点が大きな違いです。この違いは使い勝手だけでなく、後述する権限設計の考え方にも直結します。

kickflowのアクセストークンを発行する

接続にはkickflowのアクセストークンが必要です。発行手順はkickflow公式ヘルプの記事にまとまっており、kickflowの管理画面からトークンを発行します。発行したトークンは環境変数として渡すため、この時点で控えておきます。

MCPサーバーの実行にはNode.js v22.18.0以上が必要です。バージョンが古いと起動に失敗するため、node --version で事前に確認しておくと手戻りがありません。複数のNode.jsバージョンを切り替えて開発している環境では、Claude Codeを起動するシェルで有効になっているバージョンが要件を満たしているかも合わせて確認しておくと安心です。

Claude CodeにkickflowのMCPサーバーを追加する

claude mcp add で追加します。パッケージはnpm経由で配布されており、事前インストールは不要です。コマンドの各オプションの意味やスコープの使い分けはClaude Code MCP設定ガイドにまとまっています。

claude mcp add --transport stdio \
  --env KICKFLOW_ACCESS_TOKEN=your-kickflow-access-token \
  kickflow -- npx -y @kickflow/mcp-server

Windows環境では npx を直接呼び出す代わりに cmd /c でラップする必要があります。公式のJSON設定例でも、OSごとに次のように起動コマンドが分かれています。

OScommandargs
macOS / Linuxcommandnpxargs["-y", "@kickflow/mcp-server"]
Windowscommandcmdargs["/c", "npx", "-y", "@kickflow/mcp-server"]

Claude Desktopなど他のMCPクライアント向けの設定ファイル(claude_desktop_config.json)を流用する場合も、mcpServers オブジェクトの中身は同じ構造です。接続後は claude mcp list で ✔ Connected になっているかを確認します。

接続先を切り替えたい場合(検証環境や独自ドメインを使う場合)は KICKFLOW_API_BASE_URL 環境変数でベースURLを変更できます。既定値は https://api.kickflow.com です。

3つの汎用ツールで稟議・ワークフローを操作する

kickflowのMCPサーバーが公開するツールは discover_apis / get_api_info / call_api の3つだけです。この3つを組み合わせて、kickflow APIの全機能に間接的にアクセスします。

ツール役割
discover_apis役割呼び出せるAPIの一覧とoperationIdを確認する
get_api_info役割指定したoperationIdの必要パラメーターをJSON Schemaで確認する
call_api役割operationIdとパラメーターを指定してAPIを実際に実行する

典型的な流れは、discover_apis で目的のAPI(たとえば getTicket)を見つけ、get_api_info で必要な引数を確認し、call_api で実行する、の3ステップです。Claudeはこの流れを依頼文から自動で組み立てるため、利用者が直接3つのツールを指定する必要はありません。「チケットID 550e8400-e29b-41d4-a716-446655440000 の内容を教えて」と頼むだけで、内部的には getTicket の呼び出しに変換されます。

カテゴリの作成のように入力が必要なAPIでも流れは同じです。「新しいカテゴリ『経費精算』を作って」と頼むと、Claudeはまず get_api_info で createCategory が要求するリクエストボディの形を確認し、{"name": "経費精算"} のようなパラメーターを組み立てたうえで call_api を呼び出します。パラメーターの形式を利用者が事前に知っている必要はなく、依頼文だけで組み立てが完結する点がこの設計の利点です。

なぜ3つの汎用ツールだけで設計されているのか

Backlogのように機能ごとに専用ツールを用意する設計と比べ、kickflowが3つの汎用ツールだけで全機能をカバーする設計を選んでいるのには理由があります。kickflow APIはOpenAPIスキーマとして定義されており、discover_apis と get_api_info はこのスキーマを都度参照して情報を返します。つまり、kickflow側でAPIが追加・変更されても、MCPサーバー自体のコードを更新しなくても新しいAPIをすぐに呼び出せる状態が保たれます。

この設計は保守のしやすさと引き換えに、後述の権限制御の粗さを抱えています。個別の操作ごとにツール名を分ける設計(Backlogのような方式)は、権限設定の細かさで勝る一方、API追加のたびにツールを増やすメンテナンスコストがかかります。どちらが優れているというより、サービスの性質に応じたトレードオフと捉えるのが実態に近い理解です。

APIの数が多く、頻繁に追加・変更されるサービスほど、専用ツール型の設計は保守負担が増えやすくなります。汎用ツール型を採用しているMCPサーバーに接続する際は、権限設計を利用者側で補う前提で導入を検討すると、後から想定外の操作に気づいて慌てる事態を避けやすくなります。

call_apiの権限設計で気をつけること

kickflowのツール構成は、Backlogのように get_issue と delete_issue が別々の名前を持つ設計とは異なります。読み取りも書き込みも同じ call_api という1つのツール名を通るため、Claude Codeの権限設定(mcp__kickflow__call_api の許可・確認・拒否)は操作の種類ではなく、ツール全体にしかかかりません。

具体的には、「カテゴリの一覧を見る」ような読み取り操作と、「稟議チケットを新規作成する」ような書き込み操作が、権限ルールの上では区別できません。call_api を一律で許可すると、承認ルートに関わる操作まで確認なしで実行できてしまいます。

権限ルールの書き方や、サーバーごとの許可範囲の決め方はMCPセキュリティガイドで扱っています。同じ考え方はBacklogのMCPサーバーにも当てはまりますが、Backlogは操作ごとにツール名が分かれているため、Claude Backlog連携ではdelete_issueのような個別ツール単位で制御できる違いがあります。

読み取り専用の利用に限定したい場合、call_api そのものを禁止するのではなく ask にとどめておく運用が現実的です。禁止してしまうとkickflowの情報照会もできなくなり、連携の価値が大きく下がります。まずは ask で運用を始め、承認・却下のような重い操作の依頼が実際に来ないか、しばらく実行内容を観察してから allow へ緩めるかどうかを判断する、という段階的な進め方が安全です。

よくあるつまずき

  • Node.jsのバージョンが古くて起動しない: v22.18.0未満では動作要件を満たしません。nvm 等でバージョンを上げてから再実行します
  • Windowsで npx がそのまま失敗する: command に npx を直接指定すると動かないことがあります。cmd 経由で /c npx ... にラップする設定に直します
  • get_api_info で必要なパラメーターが分からない: 先に discover_apis で正しい operationId を確認してから get_api_info を呼ぶ順序を守ります
  • call_api の実行が毎回確認を求めてくる: 権限設定で ask にしている場合の想定どおりの挙動です。読み取り専用の利用が中心なら、ツール自体はallowにしつつ、依頼の内容を都度確認する運用に切り替える選択肢もあります
  • 接続はできるがAPIの実行が失敗する: アクセストークンの権限が対象APIに及んでいない可能性があります。kickflow管理画面でトークンに付与された権限範囲を確認します
  • 社内独自の認証ヘッダーが必要な環境で動かない: KICKFLOW_API_HEADERS にJSON形式で追加ヘッダーを指定できます。リバースプロキシ経由でアクセスする構成などで使います
  • operationId の名前が分かりにくく目的のAPIを探せない: discover_apis の結果には簡単な説明も含まれるため、「チケットに関するAPIを教えて」のように機能名で絞り込む依頼に変えると見つけやすくなります

よくある質問

kickflowの無料プランでも接続できますか

MCPサーバー自体はkickflowのプランを問わず、アクセストークンを発行できるアカウントであれば接続できます。利用できる機能の範囲はkickflow本体の契約プランに依存します。

稟議の承認・却下も自然言語で頼めますか

対応するAPIがkickflow側で公開されていれば、call_api 経由での実行自体は技術的に可能です。アクセストークンにどこまでの権限が紐づくかはkickflow側の設定に依存するため、承認操作を許可するかどうかはトークン発行時の権限範囲とClaude Code側のask設定の両方で管理する形になります。

他のMCPサーバーと同時に使えますか

はい。BacklogやSlackなど他のMCPサーバーと併用し、1つの依頼の中で複数のツールをまたいで処理させることもできます。ツール名が衝突する心配はありません。Claude CodeはMCPサーバーごとにツール名をmcp__kickflow__call_apiのように名前空間化して扱うため、call_apiのような汎用的な名前でも他のMCPサーバーのツールとは区別されます。

Claude Desktopでも同じ設定で使えますか

はい。kickflowのMCPサーバーはClaude Codeに限らず、Claude Desktopなど他のMCPクライアントの mcpServers 設定にも同じ形式で追加できます。

アクセストークンの有効期限はどれくらいですか

トークンの有効期限や失効ポリシーはkickflow側の管理設定に依存します。長期間有効なトークンを発行できる場合でも、退職者や異動者が出たタイミングで棚卸しをして、不要になったトークンを失効させる運用を組み込んでおくと安全です。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →