会社情報
採用情報
お問い合わせ
Article

ドラッグ&ドロップで作る社内ワークフローシステム

高田晃太郎
ドラッグ&ドロップで作る社内ワークフローシステム

社内申請や承認の25〜40%が依然としてメール・表計算で運用され、担当者の手作業がボトルネックになっているという調査結果は珍しくありません¹。公開データでも、ナレッジワーカーの一日のうち最大20%が情報探索や待ち時間に費やされ²、承認プロセスの遅延が売上機会を直接的に削ることが示唆されています。現場ヒアリングや簡易ログ分析でも、シンプルな経費精算であっても関与者は複数人（3〜5人程度）に及び、数回の往復が発生しがちです。こうした摩擦は「ちゃんと作るまでは面倒だが、作れば高速」というシステム化のジレンマに回収されがちです。だからといって、すべてをスクラッチで実装するのも現実的ではありません。ここで有効なのがドラッグ&ドロップで作るワークフローシステム（ノーコード/ローコードによる社内ワークフロー自動化）です。現場が自分の言葉で流れを組み、IT側はガードレールと運用を標準化する。両者の速度と安全性を同時に満たす設計と実装を、具体的なコードと指標で解説します。

なぜドラッグ&ドロップなのか──現場の速度とITの統制を両立する設計原則

ドラッグ&ドロップで流れを組む利点は、ビジュアル編集の手軽さそのものではありません。なお、業務プロセスの可視化に関してはBPMN（Business Process Model and Notation。業務フロー図の国際標準表記）が広く用いられています³。重要なのは、ノードとエッジで表現されたプロセスを形式化したDSL（ドメイン固有言語：対象領域に特化した記述言語）に落とし込むことで、検証、バージョニング、監査、デプロイを自動化できる点にあります⁴⁵。つまり見た目の自由度を与えつつ、実体は厳密なデータ構造として扱うことで、現場のスピードとITのガバナンスを両立させるわけです。設計の出発点は、ユースケースの80%を占める汎用ノードを特定し、入出力スキーマと副作用の種類を標準化することです。典型的にはトリガー、条件分岐、承認、人手タスク、Webhook（外部HTTP連携）、データ変換、外部SaaS連携、エスカレーション（期限切れ時の通知）、タイマーといった要素に収まります。これらを再利用可能なコンポーネントとして用意し、ノード間のデータ受け渡しを型安全にすることで、動作保証と可観測性を担保できます。

もう一つの鍵はリリース単位の明確化です。ビルダーで編集中のドラフトは即時に反映せず、検証と承認を経たスナップショットのみが実行環境に出るよう、下書き、リリース候補、本番の三層に分離します。この運用設計だけでも、変更に伴う事故リスクの低減が期待できます。さらに、テナントや部門ごとの差分設定はポリシーとして外出しし、フロー定義と設定の漂流を防ぐと移行や監査が容易になります。

アーキテクチャ全体像とデータモデリング

フロントエンドはReactなどでキャンバスとプロパティパネルを提供し、編集結果をJSON DSLにシリアライズします。バックエンドはDSLを検証し、バージョン管理とデプロイを担当します。実行エンジンは信頼できるワークフローランタイム、たとえばTemporal（耐障害性のあるワークフローエンジン）などのプラットフォームを採用すると、人手タスクやリトライ、長期実行に強くなります。データベースはPostgreSQLに永続化し、イベントはKafkaやRedis Streams（いずれもイベントストリーミング/メッセージング基盤）で非同期連携すると堅牢です。以下のような型定義に揃えておくと、編集と実行の責務分離が明確になります⁵。

// Code 1: DSLの型定義（TypeScript + Zod）
// DSL: ドラッグ&ドロップで組んだフローを厳密なJSONスキーマで表現する
import { z } from 'zod';

export const NodeType = z.enum([
  'trigger', 'condition', 'approval', 'task', 'webhook', 'transform', 'timer', 'escalation'
]);

export const NodeSchema = z.object({
  id: z.string().uuid(),
  type: NodeType,
  name: z.string().min(1),
  inputs: z.record(z.any()).optional(),
  outputs: z.record(z.any()).optional(),
  config: z.record(z.any())
});

export const EdgeSchema = z.object({
  id: z.string().uuid(),
  from: z.string().uuid(),
  to: z.string().uuid(),
  condition: z.string().optional()
});

export const WorkflowSchema = z.object({
  id: z.string().uuid(),
  name: z.string().min(1),
  version: z.number().int().nonnegative(),
  nodes: z.array(NodeSchema).min(1),
  edges: z.array(EdgeSchema),
  createdBy: z.string(),
  createdAt: z.string(),
});

export type Workflow = z.infer<typeof WorkflowSchema>;

ノードの副作用は抽象化レイヤーで吸収し、実ランタイム側のアクティビティにマッピングします。これによりビルダーはSaaS連携やHTTP呼び出しの詳細を知る必要がなく、トークン管理やタイムアウト、リトライなどの横断的関心事を一元化できます。

バージョニングと環境昇格

編集されたドラフトはサーバー側で型検証、静的到達性チェック（開始点から各ノードに道が通っているかの検査）、未接続ノード検出、データマッピングの検証を行い、問題なければリリース候補に昇格させます。ステージングでの合成テストをパスした版のみが本番へ昇格し、既存インスタンスは旧版で完走、新規だけ新版へ、というカナリア移行（段階的切替）を原則にします。承認フロー自体も組織のワークフローで運用すると、ポリシーの可視化が進みます。SSO（シングルサインオン）とRBAC（ロールベースアクセス制御）で操作権限を細分化し、作成、編集、承認、デプロイ、ロールバックのアクション単位で監査ログを記録しておくと、後追い調査に強い基盤になります。

実装リファレンス──React + Node.js + Temporal + PostgreSQL

ここからは、中規模組織での内製を想定した実装の骨子を示します。UIはReactとdnd-kitでキャンバスを構築し、バックエンドはExpressでDSL検証とデプロイを提供、実行はTemporalのTypeScript SDKに任せ、PostgreSQLに定義と監査を永続化します。いずれもコンテナ化し、CI/CDで型チェックと統合テストを強制すると品質が安定します。

キャンバス実装（React + dnd-kit）

ドラッグ&ドロップの最小例です。ノードのドロップ時にDSLへの反映と即時検証を行い、エラーはプロパティパネルに集約します。

// Code 2: Reactキャンバス（@dnd-kit/core）
// dnd-kit: React向けの軽量なドラッグ&ドロップライブラリ
import React, { useState } from 'react';
import { DndContext, useDroppable, DragEndEvent } from '@dnd-kit/core';
import { v4 as uuid } from 'uuid';
import { WorkflowSchema } from './dsl';

export function Canvas() {
  const [workflow, setWorkflow] = useState({ id: uuid(), name: 'New', version: 0, nodes: [], edges: [], createdBy: 'user', createdAt: new Date().toISOString()});

  const { setNodeRef } = useDroppable({ id: 'canvas' });

  const onDragEnd = (e: DragEndEvent) => {
    if (e.over?.id !== 'canvas') return;
    const type = e.active.data.current?.type;
    const node = { id: uuid(), type, name: `${type}-${Date.now()}`, config: {}, inputs: {}, outputs: {} };
    const next = { ...workflow, nodes: [...workflow.nodes, node] };
    const parsed = WorkflowSchema.safeParse(next);
    if (!parsed.success) {
      // 検証エラーをUIに表示
      console.error(parsed.error);
      return;
    }
    setWorkflow(next);
  };

  return (
    <DndContext onDragEnd={onDragEnd}>
      <div ref={setNodeRef} style={{ width: '100%', height: 600, border: '1px dashed #999' }}>
        {workflow.nodes.map(n => (
          <div key={n.id} style={{ position: 'absolute', left: Math.random()*600, top: Math.random()*400, padding: 8, background: '#fff', border: '1px solid #ddd' }}>
            {n.name}
          </div>
        ))}
      </div>
    </DndContext>
  );
}

バックエンドの検証・公開API（Express + PostgreSQL）

APIはバージョン付きで保存し、公開時にトランザクションで一貫性を確保します。検証失敗時は400、保存時の競合は409を返します。クエリはインデックス設計と行レベルセキュリティで堅牢にします。

// Code 3: Express API（バリデーションと公開）
import express from 'express';
import { Pool } from 'pg';
import { z } from 'zod';
import { WorkflowSchema } from './dsl';

const app = express();
app.use(express.json());
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

app.post('/workflows/:id/release', async (req, res) => {
  try {
    const draft = WorkflowSchema.parse(req.body);
    if (draft.id !== req.params.id) return res.status(400).json({ message: 'ID mismatch' });

    const client = await pool.connect();
    try {
      await client.query('BEGIN');
      const { rows } = await client.query('SELECT version FROM workflows WHERE id=$1 FOR UPDATE', [draft.id]);
      const current = rows[0]?.version ?? -1;
      if (draft.version !== current + 1) {
        await client.query('ROLLBACK');
        return res.status(409).json({ message: 'Version conflict' });
      }
      await client.query(
        'INSERT INTO workflow_versions(id, version, body, released_by) VALUES($1,$2,$3,$4)',
        [draft.id, draft.version, JSON.stringify(draft), req.header('X-User')]
      );
      await client.query('UPDATE workflows SET version=$1 WHERE id=$2', [draft.version, draft.id]);
      await client.query('COMMIT');
      return res.status(201).json({ ok: true });
    } catch (e) {
      await client.query('ROLLBACK');
      console.error(e);
      return res.status(500).json({ message: 'Internal error' });
    } finally {
      client.release();
    }
  } catch (e) {
    return res.status(400).json({ message: 'Validation failed', detail: e instanceof Error ? e.message : e });
  }
});

app.listen(3000, () => console.log('API on :3000'));

実行ランタイム（Temporal TypeScript SDK）

長期実行やリトライ、タイムアウト管理をエンジンに委ねると、ビルダーはビジネスロジックに集中できます。承認待ちの人手タスクもシグナル（外部イベントを受け取る仕組み）で表現でき、停止や再開が容易です。

// Code 4: Temporalワークフローとアクティビティ
// workflow.ts
import { proxyActivities } from '@temporalio/workflow';
import type * as activities from './activities';

const { httpCall, waitApproval } = proxyActivities<typeof activities>({
  startToCloseTimeout: '5 minutes',
  retry: { maximumAttempts: 3 }
});

export interface ExecutionContext { data: Record<string, any>; }

export async function runWorkflow(ctx: ExecutionContext) {
  // 条件分岐・Webhook呼び出し
  const resp = await httpCall({ url: 'https://api.example.com', method: 'POST', body: ctx.data });
  if (resp.status >= 400) throw new Error('Webhook failed');

  // 人手承認（シグナルで承認/否認を受け取る想定）
  const approved = await waitApproval({ timeoutMs: 3 * 24 * 60 * 60 * 1000 });
  if (!approved) throw new Error('Approval timeout');

  return { ok: true };
}

// activities.ts
import fetch from 'node-fetch';

export async function httpCall({ url, method, body }: any) {
  const r = await fetch(url, { method, body: JSON.stringify(body), headers: { 'Content-Type': 'application/json' }});
  return { status: r.status };
}

export async function waitApproval({ timeoutMs }: { timeoutMs: number }) {
  // シグナルを待つ実装（省略）。期限超過でfalseを返す
  return true;
}

可観測性の標準装備（OpenTelemetry）

リクエストからアクティビティまでのトレースが一本で追えると、失敗時の原因特定が劇的に速くなります⁶。メトリクスはSLI/SLO（サービスレベル指標/目標）と合わせて定義し、レイテンシ、エラー率、スループットをダッシュボード化します⁷。

// Code 5: OpenTelemetry（Node.js）ベーシック設定
// OpenTelemetry: 分散トレーシング/メトリクスの標準的な計測基盤
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({ url: process.env.OTLP_URL }),
  instrumentations: [getNodeAutoInstrumentations()]
});

sdk.start().then(() => console.log('OTel started'));
process.on('SIGTERM', () => sdk.shutdown());

ベンチマークと容量計画

ベンチマークは機能完成後ではなく、最初の疎結合な道筋ができた段階で実施すると意思決定が速くなります。以下はAPI公開のP95レイテンシを測る最小スクリプトです（k6は負荷試験ツール）。運用目安として、例えば500RPSでのP95が45〜70ms、エラー率0.1%未満を合格ラインとし、CPU65%超でスケールアウトする方針を設定しておくと扱いやすいでしょう。

// Code 6: k6での簡易負荷試験
import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  vus: 50,
  duration: '60s',
  thresholds: {
    http_req_failed: ['rate<0.001'],
    http_req_duration: ['p(95)<70']
  }
};

export default function () {
  const url = 'https://api.local/workflows/123/release';
  const payload = JSON.stringify(__ENV.PAYLOAD);
  const params = { headers: { 'Content-Type': 'application/json', 'X-User': 'tester' } };
  http.post(url, payload, params);
  sleep(0.01);
}

実測は環境に依存しますが、PostgreSQLのWAL設定（書き込みログ）、接続プール、JSONB列への適切なインデックス、Temporalワーカーの同時実行数調整が主要なレバーになります。詳細なパーティショニング設計についてはPostgreSQLパーティショニング実践ガイドを参照してください。

運用・ガバナンス・セキュリティ──「作れてしまう」ことへのガードレール

現場が自走できると、同じようなフローが乱立しやすくなります。これを防ぐにはテンプレート、ポリシー、レビューの三層で制御します。テンプレートは部門横断で再利用可能な最小構成を用意し、ポリシーはレートリミットや外部通信ドメインの許可リスト、データ保持期間、個人情報の取り扱いレベルといった境界をコード化します。レビューはGitのプルリクのようにリリース候補に対して実施すると、責任と透明性が担保されます。監査ログには誰がいつ、何を、どの環境に反映したかを完全に記録し、後から不可逆に改ざん検知できるようハッシュ化して保管します。

アイデンティティはOIDCベースのSSOで集約し（OIDC: OpenID Connect）、グループと属性ベースのアクセス制御を併用して、フロー単位の編集、実行、監査の役割を分離します。データは作成時暗号化、転送時TLSはもちろん、WebhookのシークレットやOAuthトークンはKMS・Vaultに格納します。可観測性は先述のOpenTelemetryにメトリクスを加え、P95レイテンシ、エラー率、スループット、承認待ち滞留時間、エスカレーション率をダッシュボード化すると、経営に説明可能な運用指標になります⁷。ガイドラインの詳細はSLI/SLO設計と運用の基本を参考にしてください。

移行とローンチの現実解

既存の表計算やグループウェアからの移行は、完全置換ではなくサンドボックス並走を基本戦略にするとトラブルが減ります。最頻出の3つのフロー（例：経費精算、稟議、入社オンボーディング）を先に再現し、関係者に触ってもらいながら、入力項目と通知設計をすり合わせます。旧運用との二重入力期間は最短二週間を目安にし、差異をログで収集してテンプレートを磨き込みます。これにより、テンプレートとポリシーが現場の共通言語となり、以降の水平展開が加速度的に進みます。変更管理は週次の変更諮問ボードで扱い、リリースは定時ウィンドウにまとめると影響範囲の可視化が容易です。

ROIとビジネス効果──時間の可視化が投資判断を変える

ワークフロー内製（ローコード/ノーコード活用含む）の投資判断は、体感ではなく定量で語るほど周囲の合意形成が速くなります。ROIは単純化すれば、削減時間×件数×人件費単価からランタイムと保守費を差し引いたものです。例えば月1,000件の申請で一件あたり12分短縮、平均人件費が時給3,500円なら、毎月約70時間、245,000円相当の削減になります。ここに承認リードタイム短縮による機会損失の回収、ミス削減による再作業コストの低下、監査対応の短縮を加えると、初期の内製コストは半年から一年で回収できる可能性が高まります。また、Forresterの調査では、ワークフロー自動化の投資回収期間が3〜5カ月と報告された事例もあります¹。さらに、統一されたフロー定義がナレッジとして残り、新任者の立ち上がりや属人化の解消に効いてきます。

運用開始後は、プロセスマイニング（実行ログからプロセスの実態を可視化）の視点でボトルネックを特定すると改善が続きます。滞留時間の分布、エスカレーション率、再申請率といったKPIを月次でレビューし、テンプレートとポリシーを継続的にアップデートします。これにより、単なる自動化ではなく、組織の学習を加速するシステムとして定着します。

よくある落とし穴と回避策

失敗の多くは「何でもできるUI」を目指してしまうことから始まります。キャンバスは自由に見えても、実体は厳密なDSLであるべきで、制約が品質を守ります⁴。もう一つは、外部SaaSのAPI変化に引きずられて壊れるケースです。これを避けるにはアダプター層を設け、フローから見えるインターフェースを安定化させることが重要です。最後に、パフォーマンスはデータベース設計に強く依存します。イベントや監査は書き込み頻度が高くなるため、ホットパスを分離したスキーマと、古いデータのアーカイブ戦略でI/Oを制御します。

まとめ──現場のスピードを統制の中に取り戻す

ドラッグ&ドロップのワークフローは、楽に見せるための仕掛けではありません。現場が理解できる表現でプロセスを組み立て、その裏側を型とガードレールで固めることで、初めて速度と安全性が両立します。設計ではDSL、バージョニング、環境昇格、監査の四点に重点を置き、実装ではReactキャンバス、検証API、堅牢な実行エンジン、可観測性を最初から組み込みます。運用ではテンプレートとポリシーで拡散を防ぎ、KPIで改善を回す仕組みを整えます。あなたの組織で、明日からどの三つのフローをテンプレート化し、二週間の並走で検証しますか。まずは最頻出を小さく速く作り、数値で効果を確かめてください。その先に、社内ワークフロー自動化（承認フローのデジタル化）が継続的な業務改善と効率化につながる姿が見えてきます。

参考文献

  1. Forrester Study Finds Big Savings in Workflow Automation. CMSWire. https://www.cmswire.com/cms/information-management/forrester-study-finds-big-savings-in-workflow-automation-027724.php
  2. McKinsey Global Institute. The social economy: Unlocking value and productivity through social technologies. 2012. https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/the-social-economy
  3. IBM. What is BPMN? https://www.ibm.com/think/topics/bpmn
  4. A survey/resource on Domain-Specific Languages. arXiv:1409.2377. https://arxiv.org/abs/1409.2377
  5. Several workflow languages have been proposed… Software & Systems Modeling (SoSyM), 2025. https://link.springer.com/article/10.1007/s10270-025-01308-y
  6. OpenTelemetry. Observability primer: Distributed tracing. https://opentelemetry.io/bn/docs/concepts/observability-primer/#:~:text=Distributed%20tracing%20lets%20you%20observe
  7. OpenTelemetry. Observability primer: Metrics and SLI/SLO. https://opentelemetry.io/bn/docs/concepts/observability-primer/#:~:text=infrastructure%20or%20application,relate%20to%20OpenTelemetry%2C%20see%20Metrics