kickflow Cowork連携で稟議承認フローを自動化する

kickflowとCoworkを組み合わせると何ができるか

kickflowは、申請と承認のワークフローをクラウドで扱うSaaSです。公式のMCPサーバーをClaude Desktopに登録すると、Coworkから自然言語の指示だけで稟議チケットの一覧・要約・催促を頼めます。

承認そのものを自動化する話ではありません。確認と連絡の手間を減らす使い方が中心です。承認・却下のような書き込み操作をどこまで任せるかは、kickflow側の権限とCoworkの承認モードの二重で線を引きます。

前提条件

はじめる前に、次の4点を用意します。

• Node.js v22.18.0以上(kickflowのMCPサーバーはnpx経由で起動するローカルサーバーです)
• kickflowのアクセストークン(アクセストークン設定画面から発行するPersonal Access Tokenが基本です。種類の違いは後述します)
• Claude Desktopアプリ
• kickflow側で、そのトークンの持ち主がAPIを呼び出せる権限を持っていること

kickflow APIの権限はRBAC(役割ベースのアクセス制御)で決まり、トークンの持ち主が持つ権限と一致します。権限のないAPIを呼ぶと403 Forbiddenが返ります。Claudeに渡す権限は、持ち主のユーザーが画面で使える範囲が上限です。

ステップ1: kickflowのMCPサーバーをClaude Desktopに接続する

kickflowのMCPサーバーは@kickflow/mcp-serverというnpmパッケージで配布されています。機能ごとのツールはなく、3つの汎用ツールでkickflow APIのすべての機能を呼ぶ設計です。

Claude Desktopの設定ファイルclaude_desktop_config.jsonに、以下のようなサーバー定義を追記します。

{
  "mcpServers": {
    "kickflow": {
      "command": "npx",
      "args": ["-y", "@kickflow/mcp-server"],
      "env": {
        "KICKFLOW_ACCESS_TOKEN": "your-kickflow-access-token"
      }
    }
  }
}

Windowsではcommandをcmd、argsを["/c", "npx", "-y", "@kickflow/mcp-server"]にします。保存してClaude Desktopを再起動すると、kickflowのツールが読み込まれます。

接続先の既定はhttps://api.kickflow.comで、環境変数KICKFLOW_API_BASE_URLで変えられます。通常は触る必要がありません。

Coworkから届く経路

claude_desktop_config.jsonのサーバーは、Desktopのチャットと、Codeタブのローカルセッションに読み込まれます。Coworkタブでは、スキル・プラグイン・コネクターが「Customize」の設定から供給されます。この設定ファイルの内容がCoworkにも出るかは、接続後に画面で確かめるのが確実です。

Coworkのセッションはクラウドで動き、ローカルのファイルやアプリにはClaude Desktopを経由して触れます。ローカルのMCPサーバーについては、2つのページの書き方が少し違います。

どちらの書き方でも、kickflowのローカルサーバーを使う指示は、PCでClaude Desktopが起動している状態が前提です。スマホやWebからタスクを投げて反応がないときは、まずPC側のアプリが開いているかを見ます。

2026年10月6日から、ProとMaxのプランでは新しいCoworkタスクがクラウドで実行され、Settings > Generalの「Only on your computer」は削除されます。すでにPC上で始めたタスクはそのまま残ります。Pro・Maxで、これまでローカル実行だったkickflow連携のタスクは、新規作成分から経路が変わります。設定を済ませたら、読み取りだけの短い指示を1回流し、kickflowのツールが呼ばれるかを見てから運用に入ります。

ステップ2: Coworkの承認モードを稟議業務向けに選ぶ

接続できたら、承認モードを決めます。Coworkには3つのモードがあり、モードセレクターからいつでも切り替えられます。

新しいClaudeの画面(「Chat」「Cowork」の切り替えがない画面)では、権限の設定が「Auto」と「Manual」(既定)の2択になります。Skipに相当する選択肢はありません。

Autoでは、ブロックが続くとClaudeは1ステップごとに許可を求める状態に戻ります。安全性の確認の分だけ、Autoは他のモードより使用量を多く消費します。定期実行を増やすときは、使用量の減り方も合わせて見ておきます。

ここで厄介なのが、kickflowのMCPサーバーがツールを3つしか持たないことです。call_apiが一覧取得にも承認にも使われるため、ツール単位の権限では「読み取りだけ通す」という分け方ができません。コネクターのツール権限には「Always allow」「Needs approval」「Blocked」の3段階があります。discover_apisとget_api_infoは常に許可しても、call_apiは書き込みの可能性を含む前提で扱うことになります。

後戻りしにくい操作を含みうるタスクはManually approveが無難です。ファイルの完全削除はどのモードでも確認が入りますが、この保護はファイルの削除に限られ、kickflowのチケット操作には及びません。モードの挙動自体は接続先を問わず共通なので、詳しくはCowork自動承認モードの解説を参照してください。

承認操作はAPIにある

kickflowのREST APIには、承認に関するエラーコードが定義されています。次の承認者の指名が足りないときはassignment_required_before_approveです。フォームの入力が足りないときはinput_required_before_approveです。どちらも422です。承認がAPIの操作に含まれていることが分かります。

Claudeに承認を任せる場合も、承認者としてアサインされたユーザーとして実行する必要があります。アサインされていないと403のuser_not_assignedが返ります。権限の線は、Coworkのモードより先にkickflow側が引いています。

ステップ3: 稟議チケットを確認・要約・通知するワークフロー例

具体的な指示の例です。

• 「承認待ちのkickflowチケットを一覧して、金額が50万円を超えるものだけ要約して」
• 「経理部門宛ての稟議チケットのうち、3営業日以上動きがないものを教えて」
• 「今週作成されたチケットをカテゴリ別に集計して」

READMEの使用例は、次の順序でツールを呼ぶ形になっています。

利用者がoperationIdを指定する必要はなく、自然言語で頼めば足ります。ただし、絞り込みの条件はREST APIの仕様に従います。たとえばlistTicketsにqueryParamsとしてpageとperPageを渡せます。perPageの既定は25件で、上限は100件です。

絞り込みで400 Bad Requestになるときは、次の2点を疑います。どちらもkickflowのトラブルシューティングに載っている原因です。

• 日時で絞るcreatedAtStartなどは、URLエンコードしたISO 8601形式で指定する(+09:00は%2B09%3A00になる)
• ステータスのような配列はstatus[]=in_progress&status[]=completedの形で指定する。カンマ区切りは認識されない

レスポンスの日時はすべてJSTで、ミリ秒までのISO 8601形式です。「今週」の集計は、この日時を基準にします。

大量取得とレート制限

REST APIは、リクエスト元のIPアドレスごとに毎分30回までです。超えると429のrate_limitedが返り、レスポンスのRateLimit-Remainingヘッダーで残り回数が分かります。チケットを1件ずつ辿る指示は回数を使い切りやすいので、perPageを上げて一覧でまとめて取る指示にします。

定期実行とプロンプトインジェクションの注意点

滞留チケットの確認を毎朝自動実行する運用には、確認しておきたい点が3つあります。

1つ目は、スケジュールタスクの実行場所です。スケジュールタスクはリモートで動き、PCがスリープでもClaude Desktopを閉じていても実行されます。一方、ローカルのファイルやアプリが必要なタスクはローカルでしか動かず、PC上のファイルを使うタスクはデスクトップアプリが開いている必要があります。先の比較のとおり、kickflowのようなローカルMCPサーバーを使うスケジュールタスクも、PCでデスクトップアプリが開いている必要があります。

先にスケジュールの画面で「Run a task on demand」(手動実行)を試し、kickflowのツールが呼ばれることを見てから頻度を決めます。設定の手順はCoworkスケジュールタスクの設定にまとまっています。

2つ目は申請者の自由記述欄です。稟議チケットの申請理由やコメント欄には、Claudeへの指示のように読める文言が紛れ込む可能性があります。これはkickflow固有の弱点ではなく、外部の文章をClaudeが読むタスク全般に共通するリスク(プロンプトインジェクション)です。Coworkは外部コンテンツの指示混入を検出する分類器を備えていますが、リスクはゼロになりません。

3つ目は、取り消しにくい操作の扱いです。Coworkの安全利用ガイドは、機微なファイルへのアクセス、代理でのメッセージ送信、購入、取り消しにくい操作をスケジュールに入れないよう求めています。稟議の承認・却下はその典型です。まずは要約や集計のような低リスクな確認作業から始めます。結果は左サイドバーの「Scheduled」ページで見直し、使わないタスクは一時停止か削除にします。

連携用のトークンと権限をどう絞るか

プロンプトインジェクションの被害は、Claudeが持つ権限の広さで決まります。kickflowのトークンは2種類あり、権限の広さがまったく違います。

kickflowのREST APIの案内は、Personal Access Tokenを使う場合も、トークンを発行するアカウントには必要最小限の権限だけを付けるよう勧めています。通常の社員アカウントとは別に、連携に必要な権限だけを持つ連携専用のユーザーを用意する案もあります。

稟議の確認だけをClaudeに頼むなら、閲覧に必要な権限のユーザーでトークンを発行します。承認権限を持つアカウントのトークンを渡さなければ、承認の誤操作はCowork側のモード以前にkickflow側で止まります。MCPサーバーのREADMEにはトークンの種類の指定がないため、KICKFLOW_ACCESS_TOKENにはPersonal Access Tokenを入れる構成が無難な選択肢です。

よくあるつまずき

kickflow APIのエラーは、HTTPステータスとコードの組で出ます。Claudeがエラー文をそのまま返してきたら、次の表で原因の見当を付けられます。

書き込み系の操作が504で返ったときは、再実行する前にチケットの状態を読み取りで確かめます。処理が完了している場合に、同じ操作を重ねてしまうのを避けるためです。

• デスクトップアプリがオフラインで反応がない: ローカルMCPサーバーはClaude Desktopアプリ経由でしか呼び出せません。PC側でアプリが起動しているかを見ます。
• call_apiが存在しないoperationIdでエラーになる: discover_apisで一覧を取得し直し、get_api_infoでスキーマを見てから呼び出します。
• endpoint_not_found(404)が返る: URLが正しくてもHTTPメソッドの誤りで出ることがあります。
• 設定を変えたのに反映されない: claude_desktop_config.jsonを編集した後は、Claude Desktopアプリの再起動が必要です。

まとめ

読み取り中心の稟議確認は、連携専用ユーザーのPersonal Access Tokenと、Manually approveまたはAutomatically approveの組み合わせで始められます。承認・却下の実行は、kickflow側の権限と人の最終確認に残す設計が、プロンプトインジェクションへの備えとして堅い選択肢です。接続の考え方は他のMCPツールでも共通です。接続先の一覧はClaude CoworkのConnectors一覧、設定ファイルの書き方はClaude Desktop MCP設定ガイドを参照してください。

よくある質問

kickflowのMCPサーバーはClaude Codeでも使えますか

DesktopアプリのCodeタブなら使えます。claude_desktop_config.jsonのサーバーは、Codeタブのローカルセッションにも読み込まれます。単体のClaude Code CLIはこのファイルを読みません。macOSとWSLでは、claude mcp add-from-claude-desktopでDesktopのサーバーを~/.claude.jsonに取り込めます。

ローカルMCPサーバーを入れて安全ですか

ローカルMCPサーバーは、起動したPC上のプログラムと同じ権限で動きます。kickflowが配布する@kickflow/mcp-serverのように、出どころのはっきりしたサーバーを選ぶのが基本です。詳しくはMCPセキュリティガイドを参照してください。