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

フォーム作成ツールで申請業務を電子化

高田晃太郎
フォーム作成ツールで申請業務を電子化

申請フローの電子化で処理リードタイムが30〜60%短縮するという報告は珍しくありません。¹紙やExcel、メール添付に依存した承認プロセスは、人手転記と待ち行列を生み、ボトルネックとして可視化されにくいからです。²一般に、フォーム作成ツールを中核にWebhookで基幹へ接続し、承認の自動ルーティングと監査ログを標準化するだけでも、平均処理時間の短縮や入力ミスの減少が期待できます。¹²エンジニアリングの観点では、低コードのUIを採用しつつ、信頼できるイベント駆動の裏側を用意する設計が鍵になります。³ここでは、SSO、スキーマ、ワークフロー、監査、インテグレーションを含めた全体像を、実装可能なコードとともに解説します。

フォーム作成ツール選定と全体アーキテクチャ

フォーム作成ツールという言葉から、単純なWebフォームを思い浮かべるかもしれません。しかし企業の申請業務に適用するなら、UIの作りやすさだけでなく、アイデンティティ、データ保持、拡張性、可観測性の観点で評価する必要があります。中核となる要件は、SAMLやOIDCによるSSO（シングルサインオン）、SCIM（アカウントの自動プロビジョニング）、Webhook署名検証と再送、APIレートとスロットリングの明示、ファイルアップロードのマルウェアスキャン、WCAG 2.1相当のアクセシビリティ、多言語、データレジデンシ（データ保存地域）、そして詳細な監査ログです。⁴⁵⁶⁷これらが揃うと、フォームツールは表示と入力に特化し、裏側はイベント駆動のワークフロー基盤として疎結合な設計を保てます。³¹⁰

現実的な導入では、フォームツールをフロント、イベントインテークを中間層、永続化と業務システム連携をバックエンドに配置します。ユーザーはSSOでフォームに入場し、入力データは署名付きWebhookでインテークAPIへ到達します。そこで検証と正規化を行い、ストレージへ一次永続化し、審査・承認のルーティングはキューを介して非同期に処理します。Slackやメールは通知チャネルとして横に控え、PDF保管やDLP、保全要件があればアーカイブへ複製します。この構成により、ピークトラフィックの吸収、重複投稿の抑制、再送時の冪等性（同じイベントを重複処理しない性質）、そして監査の単一経路が実現できます。⁸

なお、ツール固有のビルダー体験は重要ですが、企業要件で差が出るのはAPI・Webhook・認証・監査の四点です。社内の統制要件が厳しいほど、UIの便利さよりも拡張点の健全さがROIに直結します。ゼロから自作する選択肢は確かに自由度が高い一方で、メンテナンスとアクセシビリティ、マルチデバイス対応、バリデーションUIの作り込みに工数が走りがちです。フォーム作成ツールを核に据え、ガバナンスを担保する中間層を設ける方が、導入初期から価値を出しやすいのが一般的な傾向です。

検証で見えた性能上の勘所

ある構成例では、フォームツールからのWebhookをNode.jsランタイムのインテークAPIで受け、JSON正規化と冪等性チェック、キュー投入、即時ACK（受領確認）というパイプラインに整理します。k6やautocannonといった負荷試験ツールで、p95（95パーセンタイル）を数百ミリ秒台に収めることを設計目標にすると、ユーザー体験とツール側の再送制御が安定します。重い処理は必ず非同期に逃がすというシンプルな原則が効きます。⁹スループットを上げる余地は、JSONスキーマ検証のJITコンパイル、署名検証の定数時間化、キュー送信のバッチ化、そして観測のためのログ現量削減にあります。

SSO・認可・監査の設計と実装

社内申請の本質は誰が何をいつ承認したかの真正性です。フォーム作成ツール側でSSOを有効化し、属性マッピングで所属や役職をクレームに乗せると、テンプレート単位のRBACに接続できます。⁴バックエンドでは、受信したイベントにIDトークンのクレームを添付し続け、承認アクションと一緒に監査ストアへ書き込みます。データの整合性を守るため、すべての状態遷移はイベントとして付番され、再生可能であることが望ましい設計です。³

import express from 'express';
import session from 'express-session';
import passport from 'passport';
import { Strategy as OIDCStrategy } from 'passport-openidconnect';

const app = express();
app.use(session({ secret: process.env.SESSION_SECRET!, resave: false, saveUninitialized: false }));
app.use(passport.initialize());
app.use(passport.session());

passport.use(new OIDCStrategy({
  issuer: process.env.OIDC_ISSUER!,
  authorizationURL: process.env.OIDC_AUTH_URL!,
  tokenURL: process.env.OIDC_TOKEN_URL!,
  userInfoURL: process.env.OIDC_USERINFO_URL!,
  clientID: process.env.OIDC_CLIENT_ID!,
  clientSecret: process.env.OIDC_CLIENT_SECRET!,
  callbackURL: '/auth/callback',
  scope: 'openid profile email'
}, (issuer, sub, profile, jwtClaims, accessToken, refreshToken, done) => {
  const roles = jwtClaims['roles'] || [];
  const dept = jwtClaims['department'] || 'unknown';
  return done(null, { sub, email: profile.emails?.[0]?.value, roles, dept });
}));

passport.serializeUser((user, done) => done(null, user));
passport.deserializeUser((obj, done) => done(null, obj as any));

app.get('/auth/login', passport.authenticate('openidconnect'));
app.get('/auth/callback', passport.authenticate('openidconnect', { failureRedirect: '/error' }), (req, res) => {
  res.redirect('/');
});

app.listen(3000);

この例ではOIDCでユーザーの役割や部署を引き出し、後続の承認ルールに渡せる状態をつくります。フォームの表示はツール側に任せつつ、承認の実行主体は必ずSSOのクレームと結合することで、監査時に一貫した証跡を提示できます。⁴

Webhookの署名検証と冪等性

多くのフォームツールはHMAC（共有鍵ベースのハッシュ署名）やJWSでペイロード署名を提供します。⁷検証に失敗したイベントは必ず拒否し、成功時はイベントIDで冪等に処理します。⁸再送はネットワーク上の現実なので、設計で受け止める姿勢が重要です。⁹

import crypto from 'crypto';
import express, { Request, Response } from 'express';
import { Kafka } from 'kafkajs';

const app = express();
app.use(express.json({ type: 'application/json' }));

const kafka = new Kafka({ clientId: 'forms-intake', brokers: [process.env.KAFKA_BROKER!] });
const producer = kafka.producer();
await producer.connect();

function verifySignature(raw: string, signature: string, secret: string) {
  const hmac = crypto.createHmac('sha256', secret).update(raw).digest('hex');
  return crypto.timingSafeEqual(Buffer.from(hmac), Buffer.from(signature));
}

const seen = new Set<string>();

app.post('/webhook/forms', async (req: Request, res: Response) => {
  try {
    const raw = JSON.stringify(req.body);
    const sig = req.header('X-Signature') || '';
    if (!verifySignature(raw, sig, process.env.WEBHOOK_SECRET!)) return res.status(401).end();

    const eventId = req.body.event_id as string;
    if (seen.has(eventId)) return res.status(200).json({ status: 'duplicate' });
    seen.add(eventId);

    await producer.send({ topic: 'forms.submitted', messages: [{ key: eventId, value: raw }] });
    return res.status(202).json({ status: 'accepted' });
  } catch (e) {
    console.error(e);
    return res.status(500).json({ error: 'internal_error' });
  }
});

app.listen(8080);

ここで重要なのは、署名検証をタイミングセーフに行い、ACKを速やかに返すことです。⁷重い処理はKafkaやSQSなどのメッセージブローカへ逃がし、消費側でリトライとデッドレタリング（DLQ）を設計します。¹³

スキーマ設計、承認ワークフロー、可観測性

フォームというUIは変化が速い一方で、台帳というデータは長く生きます。スキーマは必須項目を正規化カラムに、フォーム固有の可変項目はJSONB（PostgreSQLのJSON列）に収めるハイブリッドが現実的です。承認ワークフローは状態遷移をイベントとして記録し、どの入力と誰の意思で変わったかが再演可能であることが理想です。³メトリクスは入力から承認までのリードタイム、再申請率、差し戻し理由のトップ、そして停止中のキュー長を可視化すると、改善の焦点が定まります。

import { PrismaClient, Prisma } from '@prisma/client';

const prisma = new PrismaClient();

export const submissionModel: Prisma.SubmissionCreateInput = {
  // 型の例示用。実際にはマイグレーションで定義
};

// Prisma schema 例
/*
model Submission {
  id           String   @id @default(cuid())
  formKey      String   @index
  applicantId  String   @index
  status       String   @default("PENDING") @index
  payload      Json
  createdAt    DateTime @default(now())
  updatedAt    DateTime @updatedAt
  audit        Audit[]
}

model Audit {
  id           String   @id @default(cuid())
  submissionId String
  actorId      String
  action       String
  diff         Json
  createdAt    DateTime @default(now())
  Submission   Submission @relation(fields: [submissionId], references: [id])
}
*/

監査の粒度は、誰が、どのフィールドを、どの値からどの値へ変更したか、そしてその根拠となる承認コメントや添付が結び付けられていることが望ましいです。差分はアプリケーション層で計算し、監査ストアにイベントとして積み上げます。集計はあくまで投影で行い、原本は不変のログとして守るのが安全です。

通知と人の介在を設計に埋め込む

承認者の行動を促すには、情報の量とタイミングが決定的です。Slackでのメンション通知は強い効果を持ちますが、ノイズが増えると逆効果です。優先度とSLAに応じて通知チャネルと頻度を制御し、スヌーズや委任の経路を設けます。併せて、失敗時はユーザーにとって意味のある再送や差し戻し提案ができるよう、エラーの分類を丁寧に定義します。

import { WebClient } from '@slack/web-api';
import pRetry from 'p-retry';

const slack = new WebClient(process.env.SLACK_TOKEN);

export async function notifyApproval(channel: string, text: string) {
  return pRetry(async () => {
    const res = await slack.chat.postMessage({ channel, text });
    if (!res.ok) throw new Error('slack_failed');
    return res;
  }, { retries: 3, minTimeout: 300, maxTimeout: 1200 });
}

ネットワーク越しの通知は必ず失敗します。再試行とバックオフ、冪等なメッセージIDを前提にした設計が、現場の体験を守ります。⁹

PDF保管、法令対応、TCO/ROIの現実解

電子帳簿保存法や内部統制の観点では、一定の申請はPDF化と長期保管が求められます。¹¹フォームの見た目と異なる様式で保管して混乱を生まないよう、申請時のスナップショットをテンプレートに差し込み、タイムスタンプとダイジェストを添えて固定化します。改ざん検知にはハッシュの保管場所をアプリ外に分け、必要に応じてオブジェクトストレージの不変化ポリシーを用います。¹²

import puppeteer from 'puppeteer';
import crypto from 'crypto';
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';

const s3 = new S3Client({});

export async function archivePdf(html: string, key: string) {
  const browser = await puppeteer.launch({ args: ['--no-sandbox'] });
  try {
    const page = await browser.newPage();
    await page.setContent(html, { waitUntil: 'networkidle0' });
    const pdf = await page.pdf({ format: 'A4' });
    const digest = crypto.createHash('sha256').update(pdf).digest('hex');
    await s3.send(new PutObjectCommand({ Bucket: process.env.ARCHIVE_BUCKET!, Key: key, Body: pdf, Metadata: { sha256: digest } }));
    return { key, digest };
  } finally {
    await browser.close();
  }
}

この処理はCPU時間を使うため、同期パスから切り離し、ワーカーで行います。費用対効果の観点では、フォーム作成ツールのエンタープライズライセンスとイベント基盤・ストレージ・監査の運用費を合算し、自作フルスタックとの比較で人月換算の保守費を必ず入れてください。一般には、導入初期はツール採用の方が総コストを圧縮しやすく、運用・拡張フェーズでは要件の変動性と内部知見の蓄積次第で逆転することもあります。共通して言えるのは、承認ロジックや監査はどの選択肢でも自分たちの責任で持つ設計にした方が、ベンダーロックインを避けられるということです。

インフラの最小構成とベンチ結果

インテークAPIは軽量なランタイムで良く、キューとストレージ、監査DB、可観測性スタックを横に並べます。SQSやKafka、CloudWatchやOpenTelemetryに対応したスタックを選び、マネージドを優先すると運用の見通しがよくなります。以下はSQSキューとDLQの宣言例で、WebhookのACKを安定化させる基本線です。¹³

terraform {
  required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } }
}
provider "aws" { region = var.region }

resource "aws_sqs_queue" "forms" {
  name                      = "forms-submissions"
  visibility_timeout_seconds = 30
  message_retention_seconds  = 1209600
  redrive_policy            = jsonencode({ deadLetterTargetArn = aws_sqs_queue.forms_dlq.arn, maxReceiveCount = 5 })
}

resource "aws_sqs_queue" "forms_dlq" {
  name = "forms-submissions-dlq"
}

小〜中規模のトラフィックであれば、インテークAPIは汎用の仮想マシンやコンテナの中小サイズでも十分に捌けることが多く、p95を数百ミリ秒台に置くとキュー滞留の抑制に効きます。最も効く最適化は、JSONスキーマをAjvで事前コンパイルし、ストレージ入出力をバッチ化する点です。I/O待ちがボトルネックになりやすいため、同期パスでの外部呼び出しは極力排し、観測は非同期に送ると全体のスループットが伸びます。

品質とセキュリティを担保する実装の勘所

品質の中心は入力検証、例外処理、観測、そしてテストの自動化です。フォームツール側のバリデーションに頼り切らず、バックエンドでもスキーマ検証を行い、危険な入力は静かに拒否します。セキュリティではCSRFよりもWebhookの検証とファイル取り扱いが注意点で、マルウェアスキャンとサイズ制限、コンテンツタイプの厳格化を徹底します。可観測性はリクエストIDとイベントIDの二系統を全ログで結び、分散トレースでボトルネックを特定します。テストはテンプレート別のゴールデンデータを用意し、回帰を早く検知できると安全です。

import Ajv, { JSONSchemaType } from 'ajv';
import addFormats from 'ajv-formats';

const ajv = new Ajv({ removeAdditional: 'all', allErrors: true });
addFormats(ajv);

type Payload = { amount: number; costCenter: string; note?: string };

const schema: JSONSchemaType<Payload> = {
  type: 'object',
  properties: {
    amount: { type: 'number', minimum: 0, maximum: 10000000 },
    costCenter: { type: 'string', pattern: '^[A-Z]{3}-[0-9]{4}$' },
    note: { type: 'string', nullable: true, maxLength: 500 }
  },
  required: ['amount', 'costCenter'],
  additionalProperties: false
};

export const validate = ajv.compile(schema);

検証を通過したデータのみを永続化し、失敗時は人が理解できるメッセージを返します。外部API連携は必ずタイムアウトと回数制限を持たせ、失敗は業務影響の小さいタイミングで自動再試行します。承認ステップでは、同時更新と二重承認の防止が事故を減らします。

import { Kafka } from 'kafkajs';

const kafka = new Kafka({ clientId: 'approvals', brokers: [process.env.KAFKA_BROKER!] });
const consumer = kafka.consumer({ groupId: 'approver-workers' });

await consumer.connect();
await consumer.subscribe({ topic: 'forms.submitted', fromBeginning: false });

await consumer.run({
  eachMessage: async ({ message }) => {
    try {
      const evt = JSON.parse(message.value!.toString());
      // ここでビジネスルール適用、承認者の選定
      // 次トピックへエミット
    } catch (e) {
      // 失敗はロギングしつつDLQへ転送
    }
  }
});

このワーカー層はビジネスロジックの中心です。ルールは外だしできる形式にして、コード変更なしで閾値やルーティングを調整できると、現場の改善スピードが上がります。ルールエンジンを導入するか、JSONベースの簡易DSLで十分かは、申請の種類と数、ガバナンスの強度で決めると良いでしょう。

ナレッジ移転と運用標準

システムは作って終わりではありません。フォーム定義のレビュー基準、承認ルートの命名規則、監査ログの検索手順、問い合わせのSLA、そして退職や異動に伴う権限移譲のランブックを、短いドキュメントにまとめます。運用開始後の最初の四週間で、差し戻し率や処理時間のトレンドを週次で見直し、テンプレートのUI修正やルートの簡素化に即応します。改善はフォームとルールの両輪で行い、数値目標をおくとチームの足並みが揃います。

導入ステップとビジネス効果の見積もり

現場で確実に成果を出すためには、対象範囲の切り方が重要です。最初は高頻度だが非クリティカルな申請を選び、API・SSO・監査の横断基盤を先に整えます。その上でフォームテンプレートを二つだけ作り、承認ルートのパターンを一つに絞って反復し、指標を毎週確認します。目安としてp95を数百ミリ秒台、キュー滞留をゼロ付近に保てれば、添付ファイルやPDF保管、基幹連携の難度が高いテンプレートへ広げます。社内のレジリエンスを育てる観点では、リカバリードリルを一度は実施し、Webhook停止やキューバックアップ、ストレージ障害からの復旧手順を合わせて磨いておくと安心です。

ROIの試算では、開発・運用の人件費、ツールのサブスク、観測とストレージの費用、そして教育とナレッジ整備の時間を含めます。導入初年度の投資回収は、紙・Excel・メールの手戻り削減、平均処理時間の短縮、監査対応の短縮、属人化の解消の四項目で見込むのが現実的です。公開事例では、月数千件規模の申請で、申請あたりの人手時間が十数分から一桁分台へ短縮し、再申請率が1桁%から数%に低下する例が報告されています。¹²これが一年間積み重なると、フルタイム換算で数人月規模の余力が生まれ、現場の改善活動に再投資できる見通しが立ちます。

フォーム作成ツールの選定やSSO設計に関する詳細は、社内ID基盤の整備状況に強く依存します。SAMLとOIDCの違いと選び方、SOC2や内部統制の観点、サーバレスでの可用性設計、Slack連携の設計原則、そして低コード投資の費用対効果も参考になります。

最小のコードで最大の統制を

最後に、コードを増やすほど統制が高まるとは限らないという点を強調しておきます。UIはツールに任せ、SSO、監査、イベント駆動の骨格だけを自分たちで担う。この役割分担が、スピードと安全性の両立をもたらします。ベンダー選定ではデモの見栄えより、API仕様の明確さ、Webhookの再送戦略、監査ログの粒度、SLAとデータレジデンシの選択肢を優先して比較すると、後悔が少ないはずです。³

まとめ

申請業務の電子化は、フォーム作成ツールを中心に、SSO、イベント駆動、監査ログという三点を押さえれば、短期間でプロトタイプから本番定着まで見えてきます。導入前に完璧な要件を詰め切るより、二つのテンプレートで指標を見ながら改善する方が、現場に根付きます。今回紹介した署名検証、冪等性、スキーマ、通知、PDF保管の実装は小さく始めて大きく伸ばせる設計で、変更に強いのが特長です。

最小のコードで最大の統制を得るという方針に立てば、エンジニアリングの力はプロセスの本質に集中できます。次に取る一歩として、社内で最も頻度が高いが低リスクの申請を一つ選び、SSOとWebhookだけを通した最小のパイプラインを立ててみてください。p95のレスポンス、差し戻し率、キュー滞留を観測しながら、改善を三週間続ける。その手触りは、数年前の業務アプリ開発とは全く違う速度と確実性を教えてくれるはずです。³

参考文献

  1. ABM Custom Workflow Solutions. Custom workflow solutions save time and errors. https://abmcol.com/custom-workflow-solutions-save-time-and-errors/
  2. Cflow. 7 reasons to adopt paperless workflow. https://www.cflowapps.com/7-reasons-adopt-paperless-workflow/
  3. AWS Compute Blog. Benefits of migrating to event-driven architecture. https://aws.amazon.com/blogs/compute/benefits-of-migrating-to-event-driven-architecture/
  4. OpenID Foundation. OpenID Connect Core 1.0. https://openid.net/specs/openid-connect-core-1_0.html
  5. IETF RFC 7644. System for Cross-domain Identity Management (SCIM): Protocol. https://datatracker.ietf.org/doc/html/rfc7644
  6. W3C. Web Content Accessibility Guidelines (WCAG) 2.1. https://www.w3.org/TR/WCAG21/
  7. PullRequest. Securely signing webhooks: Best practices. https://www.pullrequest.com/blog/securely-signing-webhooks-best-practices-for-your-application/
  8. Hookdeck. Working with webhooks: Implementing idempotency. https://medium.com/hookdeck/working-with-webhooks-implementing-idempotency-fe792f51fba4
  9. Webhooks best practices: Lessons from the trenches. https://medium.com/@xsronhou/webhooks-best-practices-lessons-from-the-trenches-57ade2871b33
  10. MuleSoft Blog. Benefits of event-driven architecture. https://blogs.mulesoft.com/api-integration/benefits-of-event-driven-architecture/
  11. 国税庁. 電子帳簿保存法に関するご案内. https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/dencho/index.htm
  12. AWS Documentation. Amazon S3 Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html