データ補正自動化システム企画の背景
どんなに完璧なシステムを作ろうとしても、
アップデートを重ねている生きているシステムなら、
なんだかんだでデータ補正は必要になりますよね。
- システムだけでは制御しきれないデータ不整合
- その不整合を直すための補正作業
- リリース時などのイレギュラー対応
皆様は、こういったデータ補正をどのように行っていますか？
ちょっと気になるように結論の画像を先に貼っておきます。
Kintone → S3 → EventBridge → SQS FIFO → Step Functions → Fargate(Java) → Kintone
手動SQL実行の怖さ
ざっくりですが、
私の部署では下記フローでデータ補正を行なっています。
1. 申請者がクエリを書いて依頼
2. 実行者がレビュー
3. 二人で確認してから実行（Rollback→Commit）
ただ、実行部分は手動です。どんなに気をつけていても...
1. SSMSを開いて本番DBに接続
2. SELECTで対象データを確認
3. 二人で確認「OK、これで合ってるね」
4. UPDATEを実行... ドキドキ...
5. 「あ、WHERE句コピーし忘れた」 ← 全件UPDATE
最後の行、笑えないですよね。二人で確認しても、実行時のミスは防げません。
時にはシステム障害も起こるものです。
実際に起きうるリスクを表にまとめてみました。
| リスク | 発生確率 | 影響度 |
|---|---|---|
| WHERE句の書き忘れ | 中 | 致命的 |
| 本番/検証環境の取り違え | 中 | 致命的 |
| トランザクション忘れ | 高 | 大 |
| 作業ログも手動でしか残せない | 確実 | 中 |
| 誰が何をしたか不明 | 確実 | 中 |
皆様の現場でも、ヒヤリハットはあるのではないでしょうか。
工数問題も深刻
単純なUPDATE 1件でも、二人体制でちゃんとやると意外と時間がかかります。
【申請者】
1. 依頼内容の確認・ヒアリング 20分
2. 対象データの調査（SELECT） 15分
3. SQL文の作成 10分
4. 実行者への依頼 5分
【実行者】
5. レビュー・確認 15分
6. 申請者と一緒に最終確認 10分
7. 本番接続・実行 10分
8. 実行結果の確認・報告 5分
─────────────────────────────────────
合計: 約1.5時間（申請者 + 実行者の合計工数）
1日に30件あったら？ → 組織全体的に考えたら最低45時間は消えます
しかも、実行者は「他の人の依頼で手を止められる」ストレスがあります。
解決策：既存の運用フローをシステム化
手動実行の問題点
ペア作業の仕組みがあっても、実行が手動だと以下の問題が残ります。
- 確認したはずなのにWHERE句を忘れて実行してしまう
- 検証環境で確認したつもりが本番だった
- 実行ログが残らない（誰が何を実行したか後から追えない）
- 二人で確認する工数がかかる
ポイント
「申請→承認→ドライラン→実行」の流れはそのまま、実行部分だけを自動化する
これを実現するために、Kintone + AWSの構成を選びました。
なぜKintoneとAWSか？
データ補正自動化の実現方法は色々あります。
専用ツールを導入する、内製でWebアプリを作る...選択肢を挙げればキリがありません。
ただ、新しいツールを導入すると、契約・学習・運用のコストがかかります。
そこで、社内ですでに利用中の外部製品を活用することにしました。
| 製品 | 社内での利用状況 |
|---|---|
| Kintone | ワークフローツールとして導入済み |
| AWS | S3、Lambdaなどすでに全チームで利用中 |
追加の契約や環境構築なしで始められるのが大きなメリットです。
自動化後の流れ
Kintoneのワークフロー機能を使って、以下の流れを目指しました。
ポイントはドライラン（試し実行）の仕組みです。
いきなりCommitせず、まずRollbackで結果を確認してから本実行します。
a. テンプレートクエリの場合
📥 事業部メンバーの申請（実行時間指定可）
⬇
👤 事業部承認者 + 上長の承認①
⬇
♻️ Rollback実行・結果通知 ← ドライラン
⬇
👤 事業部承認者 + 上長の承認②（結果確認）
⬇
✅ Commit実行・結果通知 ← 本実行
b. 自由クエリの場合
📥 開発メンバーの申請（実行時間・優先度指定）
⬇
👤 開発承認者の承認①
⬇
♻️ Rollback実行・結果通知 ← ドライラン
⬇
👤 開発承認者の承認②（結果確認）
⬇
✅ Commit実行・結果通知 ← 本実行
この仕組みにより、「実行してみたら想定と違った」を防げます。
Rollbackで結果を見て、問題なければCommit。問題があれば差し戻し。
実は手動実行でも同じルール（Rollback→Commit）で運用しています。
ただ、手動だとこのフローを守るのも人の意識次第になってしまいます。
システム化することで、ドライランを必ず通る仕組みにできるのがポイントです。
2種類のクエリパターンを用意
データ補正には、定型的なものとイレギュラーなものがあります。
そこで、2種類のパターンを用意しました。
パターン1: テンプレートクエリ（定型業務向け）
よくある補正パターンをテンプレート化しました。
ポイント：
- Kintoneはパラメータを渡すだけ
- SQLファイルはバッチサーバー側でGit管理
- 新しいテンプレート追加時は、改修不要でSQLファイルを追加するだけ
- 1時間に1回まとめて実行（Kintone API節約のため）
-- マスタ登録用テンプレート
-- パラメータ: CategoryID, ItemID, Rate
-- 実行前確認（Confirm Query）
SELECT * FROM ItemMapping
WHERE CategoryID = CAST(JSON_VALUE('{{.Parameters}}', '$.CategoryID') AS INT)
-- 本処理
INSERT INTO ItemMapping (CategoryID, ItemID, Rate)
VALUES (
CAST(JSON_VALUE('{{.Parameters}}', '$.CategoryID') AS INT),
CAST(JSON_VALUE('{{.Parameters}}', '$.ItemID') AS INT),
CAST(JSON_VALUE('{{.Parameters}}', '$.Rate') AS DECIMAL(5,2))
)
-- 実行後確認（Confirm Query）
SELECT * FROM ItemMapping
WHERE CategoryID = CAST(JSON_VALUE('{{.Parameters}}', '$.CategoryID') AS INT)
Kintone側では、こんなJSONを入力するだけです。
{
"CategoryID": "123",
"ItemID": "456",
"Rate": "0.15"
}
パラメータを入れるだけで、安全にSQLが実行されます。
WHERE句を書き忘れる心配もありません。
パターン2: 自由クエリ（イレギュラー対応向け）
テンプレート化できない補正用には、自由クエリを用意しました。
ポイント：
- Kintone申請時にSQL文を直接記載
-
rollback/commitはバッチ側で制御（クエリには書かない）
→ 手動運用でのトランザクション開きっぱなしリスクを解消 - 実行時間の指定が可能（指定時間より前には実行されない）
- 実行優先度も指定可能
- 緊急時はタスクスケジューラから即時実行も可能
-- カスタムSQL実行用テンプレート
{{.CustomSQL}}
Kintone側では、SQL文そのものを入力します。
{
"customSQL": "UPDATE Users SET Status = 'ACTIVE' WHERE UserCode = 'USR001' AND Status = 'PENDING'"
}
こちらは承認フローでしっかりレビューしてもらう運用です。
2つのパターンの使い分け
| 項目 | テンプレートクエリ | 自由クエリ |
|---|---|---|
| 用途 | 定型業務（マスタ登録等） | イレギュラー・リリース対応 |
| 入力 | パラメータのみ | SQL文そのもの |
| 安全性 | 高（SQL固定） | 中（レビュー必須） |
| 柔軟性 | 低 | 高 |
| 承認 | 簡易 | 厳格 |
期待される効果
このシステムで、以下の改善が期待できます。
Before（手動SQL実行）:
├── WHERE句忘れのリスク → After: テンプレートで防止
├── 環境取り違えリスク → After: 設定で制御
├── 作業ログなし → After: 全履歴DB記録
├── 誰が何をしたか不明 → After: Kintoneで追跡可能
├── 承認なしで実行可能 → After: ワークフロー必須
└── 工数: 1件1時間〜 → After: 申請5分、あとは自動
AWS構成の検討
Kintone + AWSで実現するにあたり、いくつかの構成案を検討しました。
構成検討にあたり下記２つの条件がありまして
・着手可能な開発メンバーは私１人
・リリース後には他のチームに運用を引き継ぐ
案1: EKS + SQS + Java
他部署で稼働中の構成をそのまま採用する案です。
Kintone → S3 → SQS → EKS (Java Pod / CronJob)
案2: Lambda + Java
サーバーレスでシンプルに。
案3: Step Functions + Fargate + Java
AWSマネージドサービスを最大限活用する案です。
結論から言うと、案3を採用しました。
その理由を説明します。
なぜEKS案を見送ったか
他部署と同じ構成なら、ノウハウも共有できて良さそうですよね。
しかし、よく検討した結果、見送ることにしました。
構成図
┌─────────┐ ┌─────────┐ ┌─────────────────────┐
│ Kintone │ ──→ │ S3 │ ──→ │ SQS │
└─────────┘ └─────────┘ └─────────────────────┘
│
↓
┌─────────────────────┐
│ EKS │
│ ┌───────────────┐ │
│ │ Java Pod │ │
│ │ (CronJob) │ │
│ └───────────────┘ │
└─────────────────────┘
問題点1: Kubernetes知識の引き継ぎが必要
EKSを運用するには、以下の知識が必要です。
- Pod、Deployment、Service、CronJob
- kubectl操作
- マニフェストファイル（YAML地獄）
- リソース管理（requests/limits）
また、下記のようなYAMLを理解・保守する必要があります。
apiVersion: batch/v1
kind: CronJob
metadata:
name: data-update-job
spec:
schedule: "*/5 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: batch
image: xxx.dkr.ecr.ap-northeast-1.amazonaws.com/batch:latest
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: "500m"
restartPolicy: OnFailure
これではK8sの知識が必要になってしまいます。
このままリリースしては、きっと保守対応が属人化してしまい、
全部署からの運用変更依頼に追われる身になってしまいます。
問題点2: 開発工数が大きい
| フェーズ | 工数 |
|---|---|
| 設計 | 5人日 |
| インフラ構築（EKS/SQS/CI/CD） | 10人日 |
| Java実装 | 35〜45人日 |
| テスト | 10〜15人日 |
| 移行 | 5人日 |
| 合計 | 65〜80人日（3〜4ヶ月） |
さすがに重いです。１人ではきついです。
問題点3: 自前実装が多い
EKS案でも、以下は全て自前実装が必要です。
| 機能 | 実装方法 |
|---|---|
| キュー管理 | SQS + 自前ポーリング |
| 排他制御 | 自前実装 |
| リトライ | 自前実装 |
| ワークフロー管理 | なし（コードで制御） |
インフラは既存流用できても、コードは全部書き直しです。
結局、コードも仕組みも複雑なままでは、誰も引き継いでくれません。
なぜLambdaを見送ったか
次に検討したのがLambdaです。
サーバーレスでシンプル、良さそうですよね。
15分タイムアウト問題
Lambdaの最大実行時間は15分です。
データ補正の運用についていろんなチームにヒアリングしましたが、
あるチームから
「重いクエリは20分以上かかるものも...」
はい、終了です。
コスト比較も意外な結果に
「Lambdaは安い」というイメージがありますが、
実際に試算してみると意外な結果になりました。
前提条件
- 1回の処理: 平均10分
- 1日の実行回数: 50回
- メモリ: 1GB
Lambda
月間実行時間 = 10分 × 50回 × 30日 = 15,000分 = 250時間
Lambdaコスト = 250時間 × 60秒 × $0.0000166667/GB-秒 × 1GB
≒ $15/月 (約2,250円)
※ただし15分超えたら動かない
Fargate（タスク実行時のみ課金）
月間実行時間 = 250時間
Fargateコスト(0.25vCPU, 0.5GB) ≒ $7〜10/月 (約1,000〜1,500円)
※タイムアウトなし
Fargateの方が安くて制限もないという結果でした。
Lambdaの方が安いパターンは一瞬で実行終了するコードに限る話でした。
採用案：95%ノーコード構成
そこでたどり着いたのが、Step Functions + Fargate + Java の構成です。
アーキテクチャ
Kintone
│
↓ (JavaScript カスタマイズ - 既存流用)
┌─────┐
│ S3 │ ← ノーコード（既存）
└─────┘
↓
┌─────────────┐
│ EventBridge │ ← ノーコード（S3イベント→SQSへルーティング）
└─────────────┘
↓
┌───────────┐
│ SQS FIFO │ ← ノーコード（排他制御・二重実行防止が自動）
└───────────┘
↓
┌─────────────────┐
│ Step Functions │ ← ローコード（Workflow Studio GUIで設計）
└─────────────────┘
↓
┌─────────────┐
│ Fargate │ ← 設定はノーコード
│ ┌─────────┐ │
│ │ Java │ │ ← コード（ここだけ！）
│ └─────────┘ │
└─────────────┘
│
↓
Kintone (結果通知)
なぜ「95%ノーコード」と言えるのか
各レイヤーの設定方法を見てみましょう。
| レイヤー | 設定方法 | 備考 |
|---|---|---|
| S3 | ノーコード | ファイル保存 |
| EventBridge | ノーコード | イベント検知・ルーティング |
| SQS FIFO | ノーコード | 排他制御・順序保証が自動 |
| Step Functions | GUI設定 | リトライ・分岐がGUIで設定可能 |
| Fargate（設定） | ノーコード | コンテナ実行環境 |
| Java（処理） | コード | ビジネスロジックのみ |
コードを書くのはJavaのビジネスロジック部分（約500行）だけです。
排他制御、リトライ、キュー管理...これらは全てAWSに任せられます。
95%ノーコード案のメリット
この構成の良いところをご紹介します。
メリット1: 排他制御がAWS任せ
排他制御を自前で実装しようとすると、DBロックやステータス管理など数百行のコードが必要になります。
この構成では、SQS FIFOが自動で排他制御してくれます。
SQS FIFOの機能:
├── Visibility Timeout → 処理中は他から見えない
├── FIFO順序保証 → MessageGroupIdで制御
├── 重複排除 → 5分間の重複を自動排除
└── 全部コンソールでポチポチ設定するだけ
コードを書かずに、設定画面のポチポチで済みます。
メリット2: リトライがGUI設定
リトライ処理を自前で実装すると、エラー判定やカウント管理が必要になります。
Step Functionsでは、こんな設定をGUIで入れるだけです。
{
"Retry": [
{
"ErrorEquals": ["States.ALL"],
"IntervalSeconds": 3,
"MaxAttempts": 3,
"BackoffRate": 2
}
]
}
しかもこれ、Workflow StudioでGUIポチポチで設定できます。
メリット3: ワークフローが可視化される
Step Functionsでは、処理の流れが視覚的に見えます。
┌─────────┐
│ 開始 │
└────┬────┘
↓
┌─────────┐
│ SQSから │
│ 取得 │
└────┬────┘
↓
┌─────────┐
│ Fargate │ ← 実行状況がリアルタイムで見える
│ 実行 │
└────┬────┘
↓
┌─────────┐ ┌─────────┐
│ 成功？ │ ──→ │ リトライ │
└────┬────┘ └─────────┘
↓
┌─────────┐
│ 完了 │
└─────────┘
エラーが起きたとき、どこで失敗したかわかりやすいです。
これは障害対応のときに非常に助かります。
メリット4: コード量が少ない
排他制御、リトライ、キュー管理...これらをAWSに任せることで、
Javaで書くのはSQL実行ロジックだけになります。
コード量が少なければ、保守も引き継ぎも楽になりますよね。
Javaで実装する部分（5%のみ）
Javaで書くのは、純粋なSQL実行ロジックだけです。
Javaで実装する処理:
├── S3からファイル取得
├── ファイル名パース（メタデータ抽出）
├── SQLテンプレート処理
├── DB実行（Rollback/Commit制御）
└── Kintone通知
排他制御、リトライ、キュー管理はコードに書きません。
全てAWSに任せます。
だからこそ、約500行程度のシンプルなコードで済みます。（Claude予測）
工数・コスト比較
最後に、各案の比較をまとめます。
開発工数
| 案 | 工数 | 引き継ぎ（属人化回避） |
|---|---|---|
| EKS + SQS + Java | 65〜80人日 | 大変 |
| 95%ノーコード案 | 25〜32人日 | 簡単 |
月額コスト（1日平均35件処理の場合）
| 項目 | EKS案 | 95%ノーコード案 |
|---|---|---|
| コントロールプレーン | 約$73（EKS固定費） | $0 |
| コンピュート | 〜数千円 | 〜数百円（Fargate） |
| キュー・イベント | 〜数十円（SQS） | 〜数十円（SQS+Step Functions） |
| その他 | 〜数百円 | 〜数十円 |
| 合計 | 〜1.5万円 | 〜数百円 |
EKSはコントロールプレーンだけで月$73（約1万円）かかります。
95%ノーコード案は実行時間のみ課金なので、この規模だと数百円で済みます。
機能比較
| 機能 | EKS案 | 95%ノーコード案 |
|---|---|---|
| 排他制御 | 自前実装 | SQS自動 |
| リトライ | 自前実装 | GUI設定 |
| キュー管理 | SQS+自前 | SQS自動 |
| ワークフロー可視化 | なし | あり |
| タイムアウト | なし | なし |
| K8s知識 | 必要 | 不要 |
| 保守対象コード | Java 3,000行 | Java 500行 |
まとめ
本記事では、手動SQL実行の課題を解決するための「95%ノーコード」構成についてお話しました。
この構成のポイント
課題: 手動SQL実行のリスク・工数
├── WHERE句忘れ、環境取り違え...
├── 作業ログなし、誰が何をしたか不明
└── 二人体制でも1件1時間以上かかる
解決策: Kintone + AWS（95%ノーコード構成）
├── 既存の申請→承認フローはそのまま
├── 実行部分だけを自動化
├── ドライラン（Rollback→Commit）で安全に
└── 排他制御・リトライはAWSに任せる
この構成から得た学び
-
既存資産を活用する
- 新しいツールを導入するより、すでに使っているものを活かす
- Kintone + AWSの組み合わせで追加コストを抑えられる
-
AWSマネージドサービスは「コードを書かない」選択肢
- 排他制御、リトライ、キュー管理...全部AWSに任せられる
- 自前実装を減らすことで保守範囲を狭められる
-
GUI設定だから属人化しない
- Step FunctionsもSQSもコンソールでポチポチ設定
- 特定の言語やフレームワークの知識がなくても引き継げる
- 「この人しか触れない」がなくなる
-
K8sは強力だが、必要ないなら使わない
- 学習コスト・運用コストを考慮すると、Fargateで十分なケースも多い
現在、この95%ノーコード構成の実装に向けて準備を進めています。
実装が完了したら、また続編を書きたいと思います。
皆様の現場でも、似たような課題を抱えているかもしれません。
本記事が何かの参考になれば幸いです。
最後までお読みいただき、ありがとうございました。