社内のあらゆるリクエストを受けるオペレーション担当者のためのスタックです。値引きの例外、ツールのアクセス付与、ベンダー登録、人員計画の変更、契約の依頼などが対象です。現状、これらは Slack の DM で届き、親指を立てた絵文字で承認され、誰が承認したかの記録が残りません。選択肢は、リクエストの種類ごとに業種特化型ツールを買うか、すべてをまとめて扱う受付・承認の窓口を 1 つ構築するかです。このページは構築する道を扱い、1 つの設計ルールに立脚しています。リクエストのステータスを変更するのは n8n だけです。 Notion がそれを保存し、Slack が承認者を特定した形で決定を記録し、Retool がオペレーターに全体を見渡す 1 つの画面を提供します。
各ツールの役割と連携
Slack は入口であり、意思決定の場です。 依頼者が別のツールを開くことはありません。リクエストは n8n の webhook に送信する Slack Workflow Builder のフォームから始まるか、ワークスペース外の人向けには n8n Form Trigger の URL から始まります。承認は n8n の Slack ノードの Send and Wait for Response 操作（応答タイプは Approval）で Slack に戻ってきます。Capture Who Responded を有効にするとボタンが Slack ネイティブのインタラクティブボタンになり、承認者はブラウザのページではなく Slack 内のワンクリックで判断できます。Restrict Who Can Approve はボタンを指定したユーザーに限定し、それ以外の人がクリックすると「権限がありません」という非公開の通知が届き、workflow は待機を続けます。ノードの出力には、判断結果、タイムスタンプ、回答者の ID・名前・ユーザー名・メールアドレスが含まれます。この記録こそ、絵文字による運用には一度もなかった監査証跡です。
n8n はステートマシンです。 リクエストの種類ごとに 1 つの workflow を用意します。入力を検証し、承認レベルを計算し（15% を超える値引きは財務へ、それ以下は営業マネージャーへ）、Notion にレコードを作成し、承認依頼を送り、待機し、決定を書き戻し、後続のアクションを実行し（CRM のフィールド更新、Okta グループへのユーザー追加、ERP へのベンダー登録）、依頼者のスレッドに返信します。n8n の課金はステップ単位ではなく実行単位なので、12 ステップの承認フローは、どれだけ長く待機しても 1 回の実行です。この課金方式こそ、オーケストレーションをタスク課金のツールではなくここに置く理由です。
Notion は記録システムです。 リクエストの系統ごとに Notion のデータベースを 1 つ用意し、ステータス、依頼者、承認者、レベル、決定日時、承認メッセージの Slack パーマリンクをプロパティとして持たせます。各リクエストの種類は同じワークスペース内の SOP ページにリンクするため、依頼者に適用されるルールと、その適用記録が隣り合って残ります。依頼者は Slack のスレッドでステータスを確認できるので、Notion の中で作業する必要があるのはオペレーションチームだけです。
Retool はオペレーターのコンソールです。 リクエストの種類が 3 つを超えると、オペレーション担当者にはすべてを横断する 1 つのキューが必要になります。SLA に対する経過時間、担当変更、一括却下、再オープン、そして他システムのコンテキストを同じ画面に並べる機能です（値引きリクエストの横に顧客の請求履歴、アクセスリクエストの横に従業員の現在の所属グループ）。Retool は REST API 経由で Notion を読み取り、他のシステムは直接読み取ります。書き込みは n8n の webhook を呼び出す形でのみ行い、Notion には決して直接書き込みません。これにより n8n が唯一の書き込み元であり続けます。
受け渡しの順序は次のとおりです。
- 依頼者がフォームを送信 → n8n の実行が開始 → ステータス
Submittedで Notion にレコードが作成される。 - n8n がレベルを計算 → 承認者に Slack の承認メッセージが送られる → Notion のステータスがメッセージのパーマリンク付きで
Pending approvalになる。 - 承認者が Approve をクリック → n8n が回答者の情報とともに再開 → Notion に承認者と決定日時が記録される → 後続のアクションが実行される → 依頼者のスレッドに結果が届く。
- 承認期限が切れる → n8n がタイムアウト分岐で再開 → 代理承認者に通知 → Notion のステータスが
Escalatedになる。 - オペレーターが Retool で担当変更または再オープン → Retool が n8n の webhook を呼び出す → n8n が Notion に書き込み、Slack に投稿する。
この組み合わせを選ぶ理由
すべてを支える理由は、書き込み元が 1 つであることです。リクエスト処理が破綻するのは、ステータスが食い違う 3 か所に分散しているときです。Slack のスレッドでは承認済み、トラッカーでは保留中、CRM のフィールドは一度も変更されていない、という状態です。このスタックではステータスの変更がちょうど 1 つのレイヤーでのみ起こり、すべての変更は開いて再実行できる n8n の実行記録になり、すべての判断には絵文字ではなく Slack のユーザー ID が付きます。依頼者は Slack から出ないため、注意力の面でもライセンスの面でも負担がありません。そしてオペレーション担当者は、新しいリクエストの種類を追加するたびに、ベンダーを 1 社増やすのではなく、n8n の workflow と Notion のデータベースを 1 つずつ増やすだけです。
コストの実態
Slack と Notion はすでに契約済みである前提です。追加コストはオペレーションチームのライセンスと、構築に使う 2 つのツールです。定価は 2026-09-12 に確認しました。
- Slack：Pro は年払いで 1 ユーザーあたり月 $7.25（月払いは $8.75）、Business+ は $15（月払いは $18）です。このスタックでの追加コストは $0 です。Workflow Builder の条件分岐には有料プランが必要です。
- n8n Cloud：Starter は年払いで月 €20、実行数 2,500 回。Pro は月 €50、実行数 10,000 回で workflow の履歴機能が付きます。Vendr によると n8n の契約額の中央値は年 $700 で、これは Pro に相当します。
- Notion：Business は年払いで 1 メンバーあたり月 $20（月払いは $24）です。未契約の場合、オペレーション用のライセンス 1〜2 人分で年 $240〜$480 です。
- Retool：Free はユーザー 5 人まで、workflow の実行 500 回までをカバーします。Team は年払いでビルダー 1 人あたり月 $10、社内ユーザー 1 人あたり月 $5 です。ビルダー 1 人あたり $50、社内ユーザー 1 人あたり $15 の Business から、監査ログ、権限管理、カスタム SSO が使えるようになります。
3 つの構成を、いずれも定価ベースの推定値で示します。
- 最小構成（Retool Free、n8n Starter）：追加で年 約 €240。
- 標準構成（ビルダー 1 人とユーザー 4 人の Retool Team を月 $30、n8n Pro、Notion のライセンス 2 人分）：年 約 $1,500〜$1,600。
- ガバナンス構成（ビルダー 1 人とユーザー 4 人の Retool Business を月 $110、n8n Pro、Notion のライセンス 2 人分）：年 約 $2,500。
コストの崖は n8n の Business プランです。SSO と Git ベースの環境は月 €667 かかり、セルフホスティングへの移行が必要になります。セキュリティ部門がオーケストレーション層に SSO を求める場合、ほかの費用を足す前の時点でスタックは年 €8,000 を超えます。
隠れたコストは構築時間です。私たちの推定では、最初のリクエストの種類に 3〜5 日（Slack アプリ、signing secret、Notion のスキーマ、最初の workflow、コンソール画面）、その後は種類を 1 つ追加するごとに約 1 日、運用維持に月 2〜4 時間かかります。
適合ルール
このスタックが正しい選択になるのは次の場合です。
- 従業員 100〜1,000 人の企業で、1〜2 人が社内リクエストを担当している
- リクエストが 3 種類以上あり、件数が月 50〜500 件
- ほとんどのリクエストが、自社で管理するシステムへの書き込みで完了する（CRM のフィールド、ID 管理のグループ、HRIS のレコード）
- チームに JSON を読め、SQL を書け、失敗した HTTP ノードをデバッグできる人がいる
- 会社がすでに Slack と Notion で業務を回している
このスタックが誤った選択になるのは次の場合です。
- リクエストが SLA、資産記録、ナレッジベースを伴う IT チケットである場合。Jira Service Management を購入してください。Free はエージェント 3 人まで $0、Standard はエージェント 1 人あたり月 $20 で、依頼者は無料です。このスタックを構築する理由はソフトウェア費用ではなく、業務への適合です。
- 件数が月 20 件程度未満で、承認者が 1 人、後続の書き込みがない場合。Slack Workflow Builder だけで対応できます。
- 契約の依頼が大半を占める場合。これには CLM の受付、レッドライン、リポジトリが必要です。1 人 Legal Ops スタックを参照してください。
- チームに n8n の workflow を保守できる人がいない場合。最初のサイレントな障害が、誰も止まっていると気づかないリクエストになります。
よくあるバリエーション
リクエストの種類が 3 つ以下のうちは Retool を外します。 ステータスでグループ化した Notion のボードビューは、オペレーター 1 人なら十分に使えるコンソールです。追加の判断基準：リクエストと同じ画面に別システムのデータが必要になったとき、または複数の種類をまたぐ一括操作が必要になったときに Retool を導入します。
依頼者が Slack の外で自分のレコードを閲覧・編集する必要がある場合は、Notion を Airtable に置き換えます。 Airtable Interfaces を使えば、ベース全体を渡さずに依頼者ごとに絞り込んだビューを提供できます。置き換えの判断基準：リクエストのレコードが、一度送信して待つものではなく、依頼者が数日かけて作業するもの（ベンダー登録のチェックリストなど）である場合に Airtable を選びます。
ビルダーが JSON を読めず、どのフローも 5 ステップ程度に収まる場合は、n8n を Zapier に置き換えます。 Zapier は各ステップを 1 タスクとして数えるため、月 300 件のリクエストを処理する 12 ステップの承認フローは 3,600 タスクになり、n8n の 300 回の実行と比べて大きな差になります。置き換えの判断基準：フローが短く、ビルダーが非エンジニアで、セルフホスティングの要件がないことです。
このスタックが置き換えないもの
- IT サービス管理。 資産台帳、インシデント管理、SLA レポートはサービスデスクの領域です。
- CLM。 このスタックは契約の依頼をルーティングしますが、レッドライン、締結済み契約の保管、義務の追跡は行いません。
- ID ガバナンス。 アクセス付与の申請と承認はできますが、四半期ごとのアクセスレビューや認証は実施しません。
- 購買と支出管理。 ここでの承認は発注書を発行せず、資金も動かしません。
- 改ざんできない監査ログ。 Notion のページ履歴と n8n の実行ログは編集可能で、保存期間にも上限があります。監査人が改ざん検知可能な承認証跡を求める場合は、各判断をオペレーションチームが編集できないストレージにエクスポートしてください。
注意点
- Notion の data sources モデルは古い連携を壊します。 Notion API 2025-09-03 はデータベースを data sources に分割し、旧 API で構築された連携は複数のソースを持つデータベースで失敗します。対策：Data Source リソースを備えた現行の n8n の Notion ノードで構築し、リクエスト用の各データベースを単一の data source に保ち、Notion のスキーマを変更したら必ずテスト送信をやり直してください。
- Slack での承認には公開された HTTPS エンドポイントが必要です。 Slack はボタンのクリックを
https://<your-n8n-instance>/webhook-waiting-slackに送信するため、VPN の内側にある n8n には届きません。対策：n8n Cloud を使うか、そのパスだけを公開し、Slack アプリの signing secret を認証情報に貼り付けてください。そうしないと、すべてのクリックが署名なしとして拒否されます。 - 応答のない承認は、指定しない限り永遠に待ち続けます。 対策：send-and-wait のステップで Limit Wait Time を設定し（48 時間、After Time Interval）、タイムアウト分岐を代理承認者と
Escalatedステータスにつなげてください。 - Notion のレート制限はデータの一括移行を止めます。 接続ごとの上限は Free と Plus で毎分 180 リクエスト、Business と Enterprise で毎分 600 リクエストで、さらにワークスペース全体で共有される上限があり、超過分は HTTP 429 を返します。対策：すべての Notion ノードで試行間の待機を設定した Retry On Fail を有効にし、一括移行は業務時間外にバッチで実行してください。
- リッチテキストのプロパティは 2,000 文字が上限です。 長い理由をプロパティに貼り付けると書き込みが失敗します。対策：プロパティは 1 行の要約に使い、全文はページ本文のブロックとして追加してください。
- 2 つ目の書き込み元は、気づかないうちにステータスを分岐させます。 誰かが Retool を Notion に直接つないだ日から、コンソールと承認フローの内容が食い違い始めます。対策：Retool にはコンテンツの読み取り権限のみを持つ Notion のインテグレーショントークンを渡し、すべての書き込みを n8n の webhook 経由にしてください。