この記事について
この記事は、RPA(UiPath)開発を行う中で
「実装前の設計段階で毎回悩むポイント」について、
一問一答形式で整理した個人向け設計ナレッジベースです。
- 正解を示すというより「考え方の引き出し」を増やす目的
- 実務・保守・再実行を強く意識
- 思い出したら随時追記・更新する前提
設計で迷ったときに どこでも参照できる自分用の判断基準集 として運用します。
用語整理（本記事の前提）
📖 本記事で扱う再実行／再試行関連の用語
本記事では、再実行／再試行を扱うための「用語」を先に定義する。
重要：ここで定義する用語は私自身のオリジナルであり、既存のシステム開発・IT用語とは関係がありません（一般的な定義に依存せず、本記事内の説明のために便宜上名付けています）。
基本方針
- 同じ「再実行／再試行」でも、粒度が違うと意味が変わる
- 本記事では混乱を避けるため、あえて用語を固定して使う
- 以降のQ/Aは、ここで定義した用語を前提に読む
用語（粒度別）
1) プロセスレベル（RPA全体）
- 再実行：RPAが停止・異常終了したあとに、RPAをもう一度起動して実行すること
- 途中再開（チェックポイント再開）：再実行時に、途中状態（チェックポイント）から処理を再開すること
2) 明細・業務レベル（データ処理単位）
- スキップ：エラーになった明細を一旦飛ばし、後続明細の処理を継続すること
- 再試行（明細再試行）：全明細を一巡した後、ロボエラー明細だけを再度処理すること
- ロボエラー許容回数：一巡の中で「ロボエラー起因によるスキップを何件まで許容するか」という上限
- 業務エラー異常検知ライン：一巡の中で「業務エラー起因によるスキップが何回発生したら異常発生していると判断するか」という上限
- 再試行回数：再試行（明細再試行）を何回まで繰り返すかという上限
3) アクションレベル（操作単位）
- アクションリトライ：クリック／入力／待機などの操作単位で、短く少回数だけリトライすること
4) エラー定義（本記事内の便宜上の定義）
- ロボエラー：画面操作のズレ／UI崩れ／待機不足／ネットワーク不調など、RPA実装・環境起因の想定外エラー
- 業務エラー：業務ルール上の不備やデータ不整合など、入力・前提・業務条件起因の想定内エラー（例：必須項目不足、対象外データ、ステータス不一致）
例／ルール
- 「再実行」「途中再開」「再試行」「アクションリトライ」を混同しない（粒度が違うため）
- 「ロボエラー許容回数」「業務エラー異常検知ライン」「再試行回数」は別物として設計する
- 以降のQ/Aは、ここでの定義に従って用語を使う
設計で迷わないための一問一答集
🔁 再実行／再試行設計
🧩 Q. 再実行設計で「最初から」と「途中再開」をどう選ぶか？
A. 処理の重さと再実行コストを基準に、「捨ててよい処理」かどうかで判断する。
基本方針
- 再実行設計は「再開できるか」ではなく「捨てても問題ないか」で考える
- チェックポイントや成果物判定は常に正解ではなく、コストがある設計である
- 処理が軽い場合は、あえて再開設計を持たない方が安全でシンプルなことも多い
再実行設計の大分類
再実行設計は、最上位では次の2パターンに分けられる。
パターン1：毎回最初から実行する（Stateless 再実行）
- 再実行時は、前回の処理結果をすべて捨てて最初から実行する
- チェックポイントや途中状態は保持しない
適するケース
- 処理内容が軽い（ファイル操作のみ／画面操作がほぼない）
- 全体処理時間が短い（目安：5分以内）
- 再実行回数が多くても負担にならない
- 成果物や中間状態を判定する設計コストの方が高い
設計上の考え方
- 「途中再開できない」のではなく「途中再開する必要がない」
- 異常終了しても「もう一度回せばよい」状態を作る
パターン2：チェックポイント／成果物を判定して途中再開する（Stateful 再実行）
- 再実行時に、前回の処理状況を判定して途中から再開する
- 成果物や処理済み状態を前提に処理を進める
適するケース
- 処理内容が重い（画面操作／明細ごとの繰り返し処理）
- 全体処理時間が長い（目安：10分以上）
- 再実行時に「最初から」は現実的でない
- システム登録など最初から実行したときに二重処理のリスクがある
- 人手・時間コストを減らしたい
設計上の考え方
- 再実行は「やり直し」ではなく「復旧」
- 途中再開できることで、再実行が業務上許容される
判断基準としてのチェック観点
- このRPAは異常終了したとき、最初から実行しても許容されるか？
- 再実行時に前回の処理を捨てることで、業務的な問題は起きないか？
- チェックポイント設計のコストは、再実行による時間損失より小さいか？
- 将来的に処理が重くなる可能性はあるか？
例／ルール
- 処理が軽い・短い場合は無理に途中再開を作らない
- 処理が重い・長い・登録系の場合は途中再開を前提に設計する
- 「途中再開できる」ことより「どこまでなら捨ててよいか」を明確にする
※ 途中再開を選んだ場合には、
「誰が・いつ・どう判断して途中再開するか」という別の設計課題が生まれる。
（これは次のQで扱う）
🧩 Q. 途中再開してよいかを、具体的にどう判定するべきか？
A. 「途中再開しても安全」と言える状態を、成果物・進捗・前提条件の3点で機械的に判定する。
このQの位置づけ
このQは、「途中再開を使ってよい」という設計判断が既にされた前提で、実行時にRPAが何を根拠に「途中再開してよい」と判断するかを整理する。
「途中再開を使うかどうか」の是非は前段のQで扱い、本Qでは Yes / No を分ける判定条件を明確にする。
基本方針
- 「途中再開できそう」では判定しない
- 途中再開しても業務結果が変わらないと言える根拠を持つ
- 1つでも判定不能な項目があれば、途中再開しない
判定① 成果物・中間物が「揃っていて、正しい」と言えるか
- 必要な成果物がすべて存在するか
- ファイルが存在するだけでなく、内容が妥当か（件数／サイズ／最終更新日時）
- 「途中で止まったファイル」が混じっていないか
NG例
- ファイルはあるが中身が途中
- 0バイトや異常サイズ
- 最終工程の成果物が欠けている
判定② どこまで処理したかを一意に特定できるか
- 再開地点が曖昧でないか
- 「途中」の定義が設計で固定されているか
- チェックポイントは工程単位・成果物単位で区切られているか
例
- 悪い例：「B処理の途中」
- 良い例：「A成果物が確定し、B未着手」
判定③ 再実行時の前提条件が、前回と同一と言えるか
- 以下が前回実行時と変わっていないか（ユーザー入力／インプットファイル／対象期間・条件）
- 同一と言える根拠を持っているか（ファイル名／サイズ／更新日時／必要に応じてハッシュ）
前提条件が変わった可能性がある時点で、途中再開は原則NG。
判定④ 二重処理が起きても業務的に問題ないか
- 再開地点以降で、同じ処理が二度走る可能性はあるか
- その場合にデータが壊れないか／業務的な不整合が起きないか
- 冪等性が確保されているか、または吸収できる設計か
判定⑤ 途中再開の意思決定は、仕様として定義されているか
- RPAが独断で途中再開を選んでいないか
- 判断は以下のいずれかに置かれているか
- ユーザー判断
- 設定（ファイル／パラメーター）
- 事前合意された自動判定ルール
- 「判断不能時の扱い」が明示されているか
判定結果の扱い（設計ルール）
- すべての判定を満たす → 途中再開してよい
- 1つでも満たさない／判断不能 → 最初から実行、または停止に倒す
重要：「途中再開できるかどうか」を曖昧にしたまま実行しない。
例／ルール
- 成果物が存在しても、整合性が確認できなければ途中再開しない
- 前提条件（入力・対象期間）が変わった可能性があれば途中再開しない
- チェックポイントが曖昧な処理は、途中再開の対象にしない
- 判断不能時は、必ず安全側に倒す
補足
- 途中再開の判定は、実装の工夫ではなく 判定条件の設計が9割である
🧩 Q. 途中再開が必要でも、実行中にユーザーへ「最初から／途中から」を選ばせられないときはどうする？
A. 判断をUIに置かず、設定・自動判定へ“外部化”して無人で進められる形にする。
基本方針：意思決定の置き場所は「柔軟性」ではなく「運用の現実」で決める
- 「ユーザーに選ばせる」は万能ではなく、選ばせられるタイミングがあることが前提
- 実行から対話（ポップアップ）までの待ち時間が長いと、ユーザーは待てず現実的でない
- 途中再開の意思決定は、UI / 設定 / 自動判定のどこかに置くものと割り切る
意思決定を置く3つの選択肢（UI／設定／自動）
1) UIで選ばせる（対話式）
- 実行時にポップアップ等で「最初から／途中から」を選択させる
-
向いているケース
- 実行開始直後に確認できる（待ち時間が短い）
- 利用者が常にPC前にいる前提
- 例外対応が多く、その都度判断が必要
-
弱点
- 実行から対話まで時間が空くと待てない
- 無人運転にできない（止まる）
2) 設定で切り替える（外部スイッチ）
- 設定ファイル／パラメータで「途中再開を許可」「強制的に最初から」などを切り替える
-
向いているケース
- 実行中にユーザーを待たせたくない（無人で通したい）
- ただし業務上、時々は「最初からにしたい」事情がある
- 運用担当者が事前に切り替えられる
-
強み
- UI不要で無人実行しつつ、例外時だけ人が介入できる
- 「判断」をRPAの外に出すことで、仕様が明確になる
-
注意点
- いつ誰が切り替えるか、運用ルールを決める必要がある
3) 条件で自動決定する（自動判定）
- 成果物、チェックポイント、入力同一性などからRPAが自動で判断する
-
向いているケース
- 判断基準を機械的に定義できる（曖昧さが少ない）
- 無人運転を徹底したい
-
強み
- 最も運用負担が少ない（人の判断が不要）
-
注意点
- 判断条件が甘いと事故を起こす（誤って途中再開してしまう）
- 判断できないときにどうするか（最初から／停止／通知）の設計が必要
実務でのおすすめ（迷ったときの型）
- 基本は自動判定を目指す（運用負担が最小）
- 自動判定が難しい・例外がある場合は設定スイッチを用意する（無人実行と柔軟性の両立）
- UI対話は「待てる設計」のときだけ採用する（実行開始直後に聞ける場合など）
例／ルール
- 実行から対話までの待ち時間が長いなら、UI対話は採用しない
- 途中再開の判断を自動判定できる場合でも、必要なら「強制的に最初から」実行できるよう設定（逃げ道）を残す
- 途中再開の誤判定が致命傷になり得る業務では、途中再開処理を実装しない（安全側（最初から or 停止）に倒す）
🧩 Q. 再実行時に入力（ユーザー入力・インプットファイル）が変更／差し替えされた場合、RPAはどう振る舞うべきか？
A. 入力が変わった可能性がある状態で、RPAが勝手に処理を進めない設計にする（＝結果が知らないうちに変わる／やり直し意図が潰れる事故を防ぐ）。
この問いに至った背景
- ユーザーが誤って実行したためにRPAを中断し「入力を差し替えてやり直したい」と思うことがある
- 再実行までの間にユーザーが意図せず入力が差し替わり、知らないうちに結果が変わる事故を防ぎたい
- どちらも「入力が変わったのにRPAが勝手に進む／勝手に判断する」ことで起きる
基本方針
- 入力変更は「前提が崩れた状態（イレギュラー）」として扱う
- 入力が変わった可能性がある状態では、RPAが黙って続行しない
- 「止める／最初から／途中再開」の選択は、必ず 意思決定の置き場所（合意ルール／設定／ユーザー判断）を設計として明示する
整理：なぜ入力変更を放置すると事故になるか
- 入力が変わること自体が問題ではなく、ユーザーが気づかないまま処理が進み、結果が変わることが問題
- もう一つの問題は、ユーザーが意図して差し替えたのに、その意図（やり直し）が潰れること
最初に確認するべきこと（設計の分岐点）
再実行時に、入力（ユーザー入力・インプットファイル）を再参照する設計か？
- Yes → 入力変更は致命的になり得るため、原則として勝手に進めない
- No → 入力変更の影響は受けない可能性がある一方、ユーザーが意図して差し替えた入力を RPAが受け付けない設計 になるリスクもある（＝「やり直したい」意図が潰れる可能性）
入力変更を検知したときの “原則的な振る舞い”
1) RPAが勝手に判断して続行しない
- 「入力が変わった可能性がある」時点で、処理を進めない（黙って続行しない）
- ここで必要なのは「正しい自動判断」ではなく、意思決定をどこに返すかを決めること
2) 進め方の意思決定は、次のいずれかに置く
- ユーザー判断（UIで選ばせる）
- 設定ファイル（外部スイッチで事前に切り替える）
- 事前合意されたルールで自動決定する（合意が取れている場合のみ）
重要：「続行」も「最初からやり直す」もどちらもRPAが独断で決めないよう設計する
例／ルール
- 再実行時に入力を参照する設計なら、入力変更時は原則として判断を返す（勝手に進めない）
- 成果物や中間ファイルの状況だけ見て「入力変更を無視して続行」はしない。（やり直し意図を潰す可能性があるため）
- 進め方の判断（停止／新規実行／途中再開）は、ユーザー判断・設定・合意ルールのいずれかに必ず置く
補足：「最初から実行」を選択した場合は、途中再開の前提となる作業フォルダや中間ファイルが残ったままだと誤判定・誤動作の原因になる。
そのため、処理途中のファイル類（作業フォルダ／中間成果物／チェック用ファイル等）はRPAが自動的に退避（例：Work_Archive_日時）し、クリーンな状態から新規実行できるように設計する。
🧩 Q. 再実行時にインプットファイルが前回と同一かどうか、どう検知するべきか？
A. 初回実行時のインプット情報を記録し、再実行時に比較することで「同一入力」と言える根拠を持つ。
このQの位置付け
このQは、再実行時にインプットファイルが差し替わっていることをどう検知するかという、実装寄りの設計課題を扱う。
入力が変更された場合にどう振る舞うか（停止／新規実行など）は、別のQで扱う。
インプットファイル同一性の検知方法（実装寄り）
初回実行時（新規実行時）に記録しておく情報
- ファイル名
- ファイルサイズ
- 更新日時
- （必要に応じてハッシュ値）
これらを 作業フォルダ に記録しておく。
再実行時の判定方法
- 現在のインプットファイルと、前回記録した情報を比較する
- いずれかが異なれば「前回と同一ではない」と判断する
ファイルサイズが小さい場合の代替案
- インプットファイル自体を作業フォルダにコピーして保持する
- 再実行時は、そのコピーと現在のインプットを比較し、差し替えを判断する
検知できなかった場合の扱い（設計判断）
- 同一性を判断できない場合は、途中再開を行わない
- 新規実行／停止などの振る舞いは、別の設計判断として切り出す
例／ルール
- インプットあり・再実行ありの設計なら、必ず同一性を検知する
- 同一性が検知できない状態で途中再開しない
- インプットファイルは、ファイル名・ファイルサイズ・更新日時（必要に応じてハッシュ値）で比較する
- ファイルサイズが小さい場合は、作業フォルダにコピーして再実行時に比較するのも有効
🧩 Q. RPAにおける「再実行」「再試行」は何種類あるか？
A. 粒度と責任の異なる3種類があり、仕様書に書くべきものと書くべきでないものがある。
基本方針：RPAにおける「再実行／再試行」は 3層構造 で考えるのが最も分かりやすい
- 「再実行／再試行」という言葉は一見同じでも、対象粒度・実行者・目的が異なるため同じ用語でまとめると混乱する
- 仕様書（設計書）に書くべきかどうかは、ユーザーの判断・運用に影響するかで決める
- 「RPA全体の復旧」と「明細単位の成功率向上」と「動作単位の堅牢化」を分けて整理する
① RPA自体の再実行（プロセスレベル）
- 対象粒度：RPAプロセス全体
- 実行者：人間（オペレーター／利用者）
- 目的：異常終了・停止からの復旧（業務を再開させる）
- 典型トリガー：想定外エラー、環境エラー、強制停止、外部システム停止など
-
設計ポイント
- 再実行時の開始位置：最初から／チェックポイントから／成果物存在判定から
- 停止条件・復旧手順・再開条件を明示する
-
仕様書記載：◎（必須）
※運用手順・停止条件・再開条件は必ず合意しておく
② RPA内部での再試行（明細・業務単位）
- 対象粒度：明細／レコード／業務単位（繰り返し処理の1単位）
- 実行者：RPA（自動）
- 目的：成功率向上（一時的失敗を吸収して完了率を上げる）
- 典型トリガー：画面操作ミス、タイミングずれ、UI不安定、軽微な例外
-
設計ポイント
- 「一巡後に失敗明細だけ再処理する」などの再試行戦略を持つ
- 再試行回数、再試行のタイミング、再試行後も失敗した場合の扱い（スキップ／停止／通知）を決める
- 用語を分離し、①と同じ「再実行」として書かない（例：自動再処理／明細再処理／再試行）
-
仕様書記載：◎（重要）
※ユーザーの運用・期待値に直結するため、必ず言葉を分けて記述する
③ アクションリトライ（アクション・技術単位）
- 対象粒度：クリック／入力／待機などの1動作（実装の最小単位）
- 実行者：RPA（内部実装）
- 目的：技術的堅牢性（UIの揺らぎ吸収、タイムアウト対策）
- 典型例：Retry Scope、Wait＋Clickの繰り返し、一定時間待って再クリック
-
設計ポイント
- 基本は実装の中で完結し、業務仕様ではない
- ただし「最大◯回までトライして失敗扱い」等、業務判断に影響する制限がある場合は仕様に触れる価値がある
-
仕様書記載：×（原則不要）
※実装品質の範囲で吸収し、ユーザー合意が必要な事項だけ表に出す
3分類を整理した対応表（設計視点）
| 分類 | 対象粒度 | 実行者 | 目的 | 仕様書記載 |
|---|---|---|---|---|
| ① RPA自体の再実行 | プロセス全体 | 人 | 復旧 | ◎ 必須 |
| ② RPA内部での再試行 | 明細・業務 | RPA | 成功率向上 | ◎ 重要 |
| ③ アクションリトライ | アクション | RPA | 技術安定性 | × 原則不要 |
🧩 Q. 明細単位の処理中、エラー発生時には、その時点でRPAを止めてしまっても問題ないか？
A. 原則は「止めない」。止めてよいのは“前提が崩れた”ときだけ。明細単位のエラーは検知してスキップし、後続を進められる設計にする。
基本方針
- エラー＝即停止にすると、1件の例外明細が“永久停止ポイント”になり、再実行しても同じ箇所で必ず止まる
- エラーはまず 「明細の失敗」か「RPA全体の前提崩壊」か を分類する
- 明細単位の失敗はスキップ可能にする（ログ・退避・再試行対象化などで回復手段を残す）
- 全体前提が崩れた場合のみ停止する（続行しても事故・不整合が増えるため）
まず整理：エラーの“種類”を分ける（止める／止めないの分岐点）
① 明細単位のエラー（止めない設計が基本）
- 入力不備（必須項目が空、形式不正）
- 業務ルール違反（対象外、受付不可、期間外）
- 対象データの欠損（参照先が存在しない、キー不一致）
考え方
- 「その明細は処理できない」が正解のことがある
- だからRPAは 例外明細を検知して、後続明細へ進む べき
② 全体前提の崩壊（止める設計が基本）
- ログイン不能／権限不足
- システム停止・メンテナンス・接続断
- 画面構造が崩れて操作不能（想定外UI、アプリ異常）
- 入力データが壊れている（全体的に列ズレ、ファイル破損）
考え方
- 続けても成功率が上がらず、事故・二重処理・不整合が増える
- だから 停止して人に判断を返す のが安全
即停止設計の致命的な問題（なぜ危険か）
- 1件の例外明細があるだけで、RPAは毎回そこで止まる
- 再実行しても同じ箇所で止まり、手作業で明細を除外しない限り前に進めない
- 結果として、再実行・再試行・途中再開といった 回復設計が機能しなくなる
例／ルール
- “明細エラー”は 検知してスキップ（ログに理由・対象キー・画面証跡を残す）
- スキップした明細は 再試行対象に回す／エラー一覧に積む／手作業へ引き渡す など、設計で出口を用意する
- “全体前提崩壊”は 全体停止（安全側）に倒し、通知して人が原因を解消する
- 迷う場合は「止める／止めない」を気合で決めず、分類ルール（停止条件）を仕様として合意する
この設計判断から派生する設計観点
- スキップは「何件まで」許容してよいか？（＝エラー許容回数）
- 再試行は「何回まで」意味があるか？（＝再試行回数）
- 全明細エラーのような状況で、再試行は意味があるのか？（＝前提崩壊の検知）
🧩 Q. 明細単位の処理中、ロボエラーのスキップは「何件まで」許容してよいか？（＝ロボエラー許容回数）
A. 無限に許容しない。上限は「固定値＋割合」の二段で決め、超えたら“前提崩壊”として安全側（停止）に倒す。
定義：ロボエラー許容回数とは
- 本Qでいうロボエラー許容回数とは、一巡の中で「ロボエラー起因のスキップ」を何件まで許容するかを示す上限。
※ここで扱うのはロボエラーのみ（例：UI崩れ／待機不足／ネットワーク不調／環境起因の想定外）。
※業務エラー（入力不備・対象外・業務ルール起因）は別概念であり、本Qではカウント対象にしない。
（→業務エラー側の上限＝業務エラー異常検知ラインは別のQで扱う）
基本方針：スキップは「継続のための工夫」だが、「正常の証明」ではない
- スキップは例外明細を隔離して全体を前に進めるための手段
- ただしスキップが増えるほど、処理結果の信頼性／原因切り分け可能性が落ちる
- したがって「スキップは有限」という前提で、ロボエラー許容回数（上限）を設計で持つ
整理：ロボエラースキップ上限を決める理由
-
無限スキップにすると「何かおかしい」状態でも最後まで走ってしまい、
- 事故（誤更新・誤出力）
- 原因不明（ログが散らかる）
- 復旧不能（どこまで信じてよいか分からない）
- 一方で即停止だけに倒すと、例外1件で全体が止まり、例外明細を手作業で除外しない限り業務再開ができない
設計の結論：上限は「固定値＋割合」で決めるのが最も破綻しにくい
1) 固定値の上限（最低限の“現実ライン”）
- 目安：数件（例：3件程度）
- 意味：
- たまたま起きた画面・環境の揺らぎ
- 偶発的な不具合
2) 割合の上限（前提崩壊を検知する“安全装置”）
- 目安：全件数の 5〜10% 程度
- 意味：
- 一定割合を超えた時点で「偶発」ではなく
- 環境／仕様／運用前提が崩れている可能性が高いと判断するため
具体的な決め方（テンプレ）
- 上限は「次のどちらか先に達したら発動」
- 固定値（例：3件）
- 割合（例：全件の10%）
- 例：全件100件なら「3件 or 10件」のどちらか先
- 例：全件20件なら「3件 or 2件（10%）」のように割合側が先に来ることもある
上限に達したときの“原則的な振る舞い”
- ここで大事なのは「スキップし続ける」ことではなく、前提崩壊として扱うこと
- 原則は安全側（停止／打ち切り）に倒す（どれにするかは業務合意で決める）
- 完全停止（以降の処理を打ち切って終了）
- （必要なら）停止＋通知（調査・復旧・再実行へ誘導）
※推奨は完全停止
上限到達＝異常状態であるため、再開にあたっては詳細調査が必要となる。
また再実行に際しては、端末再起動や不要なファイル・システムのクローズなど、環境をリフレッシュした上での再実行が想定されるため、そのままの状態で一時停止して再開する価値が薄い。
例／ルール
- ロボエラー明細をスキップして継続する設計なら、必ずロボエラー許容回数（上限）を持つ
- 上限は「固定値＋割合」で決めると、件数規模が変わっても破綻しにくい
- “上限到達”は正常系ではなく、前提崩壊のシグナルとして扱う
- 迷う場合は安全側（完全停止）に倒す
この設計判断から派生する設計観点
- スキップしたロボエラー明細をいつ・どの条件で再処理するか（＝再試行の設計）
- 再試行は何回まで意味があるか（＝再試行回数）
- 「ロボエラーが多い」をどうやって前提崩壊として確定するか
- 業務エラーが続く場合でも、業務継続のためにスキップしてよいのか／どこで異常扱いにするのか（＝業務エラー異常検知ライン）
🧩 Q. 明細単位の処理中、業務エラーが続く場合でも、業務継続のためにスキップしてよいか？（＝業務エラー異常検知ライン）
A. 原則スキップしてよい。ただし「放置して走り切る」のではなく、“異常検知ライン”を超えたら前提崩壊として安全側に倒す。
このQの位置付け（前段Qとの対）
- 前段Q：ロボエラー許容回数＝「想定外（環境・実装起因）のエラーが多発したら止める」
- 本Q：業務エラー異常検知ライン＝「想定内（業務ルール起因）のエラーが“多すぎる”なら止める」
業務エラーは“想定内”なので、1件で止めると運用が詰む。
ただし“多すぎる”のは投入ミス・前提崩壊のサインになり得る。
背景：なぜ業務エラーでも「上限」が必要か
- 業務エラーは「その明細が処理対象外」「条件不一致」「必須項目不足」など、一定割合で発生しうる
- だから業務継続のためにはスキップが必要
- しかし、業務エラーが続くと次の事故が起きる
- 入力（インプット）ミスでほぼ全件が対象外なのに最後まで走る
- 「処理できた件数が少ない」ことに気づかず成果物だけが残ってしまう
- ログが大量に出て原因切り分け不能になる
基本方針
- 業務エラーは「スキップして継続」が基本（＝運用を止めないため）
- ただし、業務エラーが一定回数を超えたら「例外混入」ではなく「前提崩壊（投入ミス／条件設定ミス）」として扱う
- 「業務エラー＝想定内」でも、“多発”は想定外の状態になり得る
設計の結論：業務エラー異常検知ラインは “固定値＋割合” が破綻しにくい
1) 固定値（最低限の現実ライン）
- 目安：数件（例：3件〜）
- 意味：
- たまたま混じる対象外データ
- イレギュラーな契約・例外ルール
2) 割合（前提崩壊の検知ライン）
- 目安：全件の 10〜30% 程度（業務特性で調整）
- 意味：
- エラーが一定割合を超える＝「このインプットや抽出条件がそもそもおかしい」可能性が高い
- “処理対象がほとんど無い日”があり得る業務なら、割合は緩める／別判定にする
ロボエラーより業務エラーの方が発生しやすいので、
ロボエラー許容回数よりも「緩め」に設計するのが基本。
上限に達したときの“原則的な振る舞い”
- ここで大事なのは「スキップし続ける」ことではなく、前提崩壊として扱うこと
- 原則は次のいずれか（どれにするかは業務合意で決める）
- 完全停止（推奨）：投入ミス・抽出条件ミスの可能性が高いので打ち切る
- 一時停止：通知して人に判断を返す（ただし再開は難しくなりがち）
例／ルール
- 業務エラーは「想定内」なのでスキップして継続する設計に寄せる
- ただし、業務エラー異常検知ラインを必ず持つ（放置して走り切らない）
- ロボエラー許容回数と混ぜない（別カウンタ・別上限）
- “業務エラーが多い”は、業務例外ではなく前提崩壊のシグナルになり得る
この設計判断から派生する設計観点
- 業務エラーが多いとき、処理結果が0件でも成功扱いにしてよい条件は何か？
- 業務エラーをスキップした場合、ユーザーへの通知粒度（全件／サマリ／一覧出力）はどうするか？
- 「業務エラー」としてスキップしているが、実は仕様変更や画面変更が原因のケースをどう見抜くか？（業務エラーに見えるロボエラー）
🧩 Q. 再試行は「何回まで」意味があるのか？（＝再試行回数）
A. 原則は 1～2回まで。それ以上は再試行ではなく、実装や前提を疑うべき。
基本方針
- 再試行は 一時的な不具合の成功率を少し上げるための仕組み
- 恒久的な失敗や業務上の問題を解決するものではない
- 回数を増やしても成功しない場合、原因は再試行の外にある
なぜ 1～2回が上限なのか
- 再試行が想定しているのは以下のような 一過性のロボエラー
- 画面操作のタイミングずれ
- UI描画の揺らぎ
- ネットワークや通信の一時不調
- 同じ明細が 1～2回連続で失敗する場合
- 一時的な問題ではなく
- 画面操作の実装ミス・前提条件の崩れ の可能性が高い
- それ以上の再試行は
- 成功率向上ではなく
- 設計不備を回数で隠す行為 になりやすい
再試行で扱うエラー／扱わないエラー
ロボエラー（再試行の対象）
- 一時的な画面操作失敗
- UI不安定・遷移失敗
- 通信・タイミング起因のエラー
- → 再試行で成功する可能性がある
業務エラー（再試行の対象外）
- 入力値不正
- 業務ルール違反
- 業務的に処理できない明細
- → 再試行しても結果は変わらない
※ 業務エラーを再試行で救おうとしないことが重要
設計上の結論
- 再試行回数は 有限（1～2回） に固定する
- それ以上失敗する場合は
- 再試行を増やすのではなく
- 画面操作の実装・前提条件・設計そのものを見直す
この設計判断から派生する設計観点
- 業務エラーとロボエラーは、どの時点でどう切り分けるか？
- 再試行はどのタイミングで行うべきか？
- 再試行が尽きた明細は、停止・スキップ・再実行のどれに渡すべきか？
🧩 Q. 再試行は「いつ行う」のが最も安全か？（即時 vs 一巡後）
A. 原則は「一巡後」。
再試行は成功率を上げるための設計だが、その過程で失敗の記録を上書きしないことが重要だから。
※ 再試行の目的はあくまで「成功率の向上」。
ただし、再試行によって「一度起きた失敗の証跡を消してはいけない」という制約が、設計上きわめて重要。
この問いに至る背景
- ロボエラー発生時、すぐに再試行すれば成功するケースは確かに存在する
- 一方で即時再試行により、
- 失敗の記録が上書きされる
- 何が起きたのか分からなくなる
- 後から原因説明ができなくなる
- 「いつ再試行するか」は、成功率だけでなく「失敗をどう残すか」も含めた設計判断になる
基本方針
- 再試行は「失敗をなかったことにする仕組み」ではない
- 再試行を行う前に、その失敗が確定した事実として記録されている状態を作る
- そのため、原則は 全明細を一巡した後に再試行する
即時再試行が抱える構造的な問題
- エラー発生直後に再試行すると、
- 明細結果が上書きされる
- エラー詳細が消える／成功結果に置き換わる
- 結果として、
- 「一度失敗した事実」
- 「いつ・なぜ失敗したか」
- これは原因調査・ユーザー説明・障害報告・次回改善をすべて難しくする
一巡後再試行がもたらすメリット
- ロボエラー発生時点で、
- スクリーンショット
- エラーテキスト
- 明細結果（エラー内容）
- 明細結果一覧を、
- 再試行前にバックアップ
- ロボエラー明細のみを対象に再処理
- 再試行は
- 第一ラウンドの失敗を残したまま
- 第二ラウンドとして再挑戦する
設計上の結論
- 再試行は成功率を上げるための仕組み
- しかし失敗の履歴を消してよい仕組みではない
- 失敗の記録を守る設計を取るなら、一巡後再試行が最も安全
- 即時再試行は、アクションリトライなど操作単位で完結する範囲に閉じ込める
例／ルール
- ロボエラー発生時は即時再試行せず、明細をスキップする
- エラー証跡（スクリーンショット／ログ／明細結果）は必ず保存する
- 再試行は全明細一巡後に、ロボエラー明細だけを対象に行う
- 再試行前には、明細結果一覧を別名でバックアップする
この設計判断から派生する設計観点
- 再試行は何回まで意味があるか（＝再試行回数）
- 再試行しても成功しない場合、どこで打ち切るか
- 再試行前後で「結果の正」とは何かをどう定義するか
✒️ ログ設計
🧩 Q. ログはどこまで残すべきか？（保持期間・量・削除）
A. 「業務上の必要期間だけ」残す。ログも成果物も“無限保存”しない前提で、保持期間と管理責任（誰が消すか）を運用として決める。
基本方針：ログは「残すもの」ではなく「運用で管理するもの」
- ログは増え続けるため、放置すると 容量・検索性・保守性が必ず破綻する
- したがって「どこまで残すか」は設計ではなく 運用ルール（保持期間）として決める
- 「残す／消す」を曖昧にせず、最初に 削除・退避の責任者を決める
整理：ログの“価値”がある期間はいつまでか？
- ログが役に立つのは主に次の期間
- 当日〜数日：異常時の原因調査・リカバリ
- 月次・締め：照合・監査・問い合わせ対応
- トラブルの再発防止：再現と改善の材料
- 逆に、一定期間を過ぎると
- 参照されない
- 保管コストだけ増える
- “大量のログで事故が埋もれる”
設計の結論：保持期間は「業務の必要性」で決める
- 目安は以下のどれに当てはまるかで決める
- 短期（例：7〜30日）：日次処理、問い合わせが短期で収束する業務
- 中期（例：1〜3か月）：月次締め・照合作業が絡む業務
- 長期（例：6か月〜）：監査・規制・証跡要件がある業務
- 「何日残すべきか」は万人共通ではなく、業務合意で決めるのが正しい
重要：ログの削除・退避を “RPAにやらせない” という選択肢
- ログや成果物の削除・退避は、業務処理とは別の責務になりやすい
- RPAに自動削除させると、次のリスクが出る
- 事故調査中に証跡が消える
- 「消えた／残ってない」を巡って責任が曖昧になる
- そのため運用としては、
- RPAは業務処理だけを行う
- 成果物・ログの管理（退避／削除）は人が行う
例／ルール（運用設計として決める項目）
- ログ保持期間：◯日（or ◯か月）
- 保管場所：ローカル／共有フォルダ／サーバー（どこが正か）
- 退避方法：手動（運用担当者）／定期運用作業（別ジョブ）
- 削除責任：誰が・いつ・どの手順で行うか（チェックを残す）
- 例外：重大障害時は「この期間は消さない」ルールを用意する
この設計判断から派生する設計観点
- ログと成果物・エラーファイルの役割分担はどうするか？
- ログに「ステータス」をどこまで持たせるか？（結果一覧との二重化）
- ログをどこに出すべきか？（ローカル／Orchestrator／共有）
🧩 Q. ログは「誰が」「いつ」見る前提で設計するべきか？
A. ユーザーは見ない前提でよい。ログは「保守・開発担当者が、異常時や調査時に見る」前提で設計する。
基本方針：ログの読者を明確にする
- ログ設計の最初に決めるべきことは 「誰が読むか」
- ログの主な読者：保守担当者／開発担当者
- ログを見ない前提の人：業務ユーザー（利用者）
なぜユーザーはログを見なくてよいのか
- ユーザーが知りたいのは、処理が終わったか／成功したか／成果物が正しいか
- それらは 成果物・結果一覧 で判断できるように設計する
- ログまで見せると、専門知識が必要になり、誤解や問い合わせ増加の原因になり得る
結論：ユーザー向けの情報は 「成果物」に集約し、ログは保守・開発向けに割り切る。
ログを見るのは「いつ」か？
- 異常終了したとき
- ロボエラーが多発したとき
- 原因調査・再発防止を行うとき
- 問い合わせ・監査対応が必要になったとき
→ ログは 通常運用中に常時見られるものではない 前提で設計する。
だからログはこう設計する
- 正常時：どこまで進んだかが追える程度で十分
- 異常時：分岐の結果／失敗した工程／明細番号（個人情報を含まない識別子）が分かればよい
注意点：ログに何を書いてはいけないか
- 個人が特定できる情報（氏名／口座番号／顧客ID など）
- 業務データの生値
→ 明細番号や管理番号など、ログ専用の識別子を用意して紐付ける。
例／ルール
- ログは 保守・開発担当者が異常時に状況を再構築できることを目的に設計する
- ユーザー向け説明はログではなく 成果物・結果一覧で行う
- ログは「見せる前提」にしないことで、情報過多・誤解・セキュリティ事故を防ぎやすい
この設計判断から派生する設計観点
- ログと成果物の役割分担はどう設計するか？
- ログにステータスをどこまで持たせるべきか？
- ログ出力先（ローカル／Orchestrator）をどう選ぶか？
🧩 Q. ログと成果物（結果一覧）でステータスを二重に持ってよいか？
A. 持ってよい。むしろ「復旧性」と「監査性」を上げるために、二重化は合理的な設計になり得る。
基本方針：ステータスの二重化は“冗長”ではなく“保険”
- 成果物（結果一覧）は ユーザーが業務判断するための一次情報
- ログは 保守・開発が原因調査や復旧判断をするための一次情報
- 両者の役割が違うため、同じステータスを持っても
「重複」ではなく目的の異なる記録になる
二重に持つべき理由（設計的メリット）
1) 成果物が正しく残らない可能性への備え
- 処理自体は成功していても、
- 成果物への書き込み前に異常終了した
- ファイルロック・保存失敗が起きた
- このときログにステータスが残っていれば、
- どこまで処理が進んでいたか
- 再実行・途中再開が可能か
また、結果一覧が残らなかった場合にログ上のステータスから結果一覧を復元することができる
2) 人為的な成果物変更への備え
- 結果一覧はユーザーが開いて確認・加工する前提のファイルであり、
- 手作業での修正
- 行の削除
- 上書き保存事故
- ログはユーザーが触らない前提のため、
事実としての処理経緯を保持する最後の拠り所になる
ログと成果物の内容が食い違う状態は設計ミスではなく、現実の運用上必ず起こり得る事象である。
二重化するときの注意点（破綻ポイント）
1) 「どちらを事実として扱うか」を設計で決めておく
- 基本ルール：
- 成果物＝ユーザー向けの最終結果
- ログ＝保守向けの経緯・証跡
- 両者が一致しない場合に、
- 再実行判断
- 復旧判断
2) ログに個人情報を出さない
- ログは外部（Orchestrator等）に出力される可能性がある
- 明細Noなどの 識別子ベースで紐付ける
3) 粒度を揃える
- 工程単位 × 明細単位で十分
- 詳細はエラーファイル・スクリーンショットに委ねる
例／ルール
- 成果物とログに同じステータスを持ってよい（役割が違う）
- 両者が一致しない可能性を前提に設計する
- 再実行・復旧判断は「どちらを基準にするか」を決めておく
- ログは識別子ベースで出力する
この設計判断から派生する設計観点
- 結果一覧は いつのタイミングで確定させるべきか？
- ログ・成果物・エラーファイルの 役割分担はどう設計するか？
- 再実行時、どの情報を 事実として引き継ぐか？
🧩 Q. RPAのログはどのタイミングで出力するべきか？（どこに入れるか？）
A. 「分岐が確定した瞬間」「進捗が意味を持つ区切り」「ステータスが更新された瞬間」に出す。
基本方針
- ログは「逐一出すもの」ではない
- 後から処理を再構成できる“判断点”だけを記録する
- 「ログを見てもどこまで進んだか分からない」状態を避ける
ログを出すべき代表的なタイミング
1) 大きな分岐が確定した瞬間
- 成功／失敗
- 継続／停止
- スキップ／対象外
→ どちらに進んだか分かるログを必ず残す
2) 長い処理の“進捗が意味を持つ区切り”
- ログイン完了
- 初期化完了
- ファイル出力完了
- 全明細処理 開始／終了
→ 「ここまでは来ている」ことが分かる区切りで出す
3) 明細単位処理の開始・確定ポイント
- 明細処理開始（必要な場合）
- 明細処理確定（成功／業務エラー／ロボエラー／スキップ）
→ 明細Noと結果が1行で追えることを重視
4) 明細の「工程ステータスが更新された瞬間」（明細単位ログ）
- 長いRPAでは、明細ごとに
- 工程別ステータス（処理A／処理B／出力など）
- 総合ステータス（最終結果）
- ログは 工程ステータスを更新したタイミングで出すのが最も追いやすい
狙い
- どの工程までは成功していたか
- どの工程で業務エラー／ロボエラーになったか
をログ単体で判断できるようにする
イメージ
- 処理A 完了 → 成功ログ
- 処理B 失敗 → ロボエラーログ
- 明細総合結果確定 → スキップ／エラーログ
※ 工程名自体が情報を持つため、補足は原則不要
出し過ぎないための設計ルール
- 工程ログは 完了時のみが基本
- 画面遷移・クリック単位では出さない
- 調査に使わないログは最初から出さない
例／ルール
- ログは「後から判断できるか」で出力位置を決める
- 明細ログは 工程ステータス更新時＋総合確定時
- 結果一覧（成果物）と同じ粒度でログを出すと、二重化の意味が生きる
- 迷ったら「ここでログが無いと困るか？」で判断する
この設計から派生する設計観点
- ログと成果物でステータスを二重に持ってよいか？
- ログは誰が・いつ見る前提で設計するべきか？
- ログを再実行・再試行判断にどう使うか？
✅ 設計前チェックリスト
🧩 Q. RPA業務設計で「実行不能・イレギュラー事象」を見落とさないために何を確認すべきか？
A. 実行不能になり得る条件と、そのときの「停止／スキップ／継続」の判断基準を、チェックリストとして設計時に合意しておく。
基本方針
- ユーザーは「通常ケース」しか想像できない前提で、実行不能や例外の可能性を質問として引き出す
- 「できないなら止める」ではなく、処理単位で止める／スキップする／継続する選択肢を設計する
- 停止条件は運用で揉めやすいため、設計時点で合意し、ログ・通知まで含めて決めておく
チェックリスト（Excelに貼り付けて利用可能）
※必要に応じて表全体を選択してコピーし、Excelにそのまま貼り付けてチェックシートとして利用できます。
| カテゴリ | チェック項目 | 補足 | 確認結果 | メモ |
|---|---|---|---|---|
| 実行可否の前提チェック | この業務処理は常に実行可能か？ | |||
| 実行可否の前提チェック | 実行できない期間・時間帯・条件は存在するか？ | 例：メンテナンス、締め処理期間、受付停止期間など | ||
| 実行可否の前提チェック | 実行不可の理由は「システム都合」か？ | 例：メンテナンス、締め処理、権限・ロックなど | ||
| 実行可否の前提チェック | 実行不可の理由は「業務ルール都合」か？ | 例：受付停止、締切後不可、申請期間外など | ||
| 実行可否の前提チェック | 実行不可は事前に判定できるか？ | 日付・時間／ステータス／外部システム状態 など | ||
| 部分不能時の扱いチェック（重要） | この処理ができない場合、RPA全体を止める必要があるか？ | 部分停止／スキップで代替できないか検討する | ||
| 部分不能時の扱いチェック（重要） | 他の処理は継続してよいか？ | |||
| 部分不能時の扱いチェック（重要） | 処理単位でスキップして問題ないか？ | |||
| 部分不能時の扱いチェック（重要） | スキップした場合、後続処理に影響はあるか？ | 依存関係（入力データ、集計、通知など）を確認 | ||
| 停止条件の明確化 | RPAを全体停止すべき条件は何か？ | 「止めるべき」条件を明文化する | ||
| 停止条件の明確化 | 処理単位で停止／スキップを判断する条件は何か？ | どの処理を止めるか（部分停止）を定義する | ||
| 停止条件の明確化 | 「安全側で止める」以外の選択肢はあるか？ | 停止／部分停止／スキップ／継続＋通知 を検討 | ||
| ユーザー判断が必要なポイント | 実行不可時の業務上の正解は何か？ | 何もしない／スキップして後続のみ実行／手作業に切り替える | ||
| ユーザー判断が必要なポイント | 実行不可時に誰が判断すべきか？ | RPAが自動判断／ユーザー判断（通知のみ） | ||
| ユーザー判断が必要なポイント | この判断は設計時に合意できているか？ | 曖昧なら運用で必ず揉めるため合意する | ||
| 通知・ログ設計 | 実行不可・スキップ時に通知は必要か？ | 必要／不要、毎回／初回のみ | ||
| 通知・ログ設計 | ログには何を残すべきか？ | 実行不可の理由／対象処理／スキップした事実 | ||
| 再実行・復旧観点 | 実行不可期間が明けたら自動で再実行すべきか？ | 自動／手動、実行タイミング、通知の有無 | ||
| 再実行・復旧観点 | スキップした処理は後追い実行が必要か？ | 後追いが必要なら対象の特定方法も決める | ||
| 再実行・復旧観点 | 再実行時に二重処理のリスクはないか？ | 冪等性、重複防止、成果物の存在判定など |
「安全側で止める」とは
- 「安全側で止める」とは、判断に迷った場合に 取り返しのつかない処理（更新・確定・送信など）を行わない 選択をすること
- 「安全側」＝「何もしない」とは限らない
- 全体停止：処理を一切行わず終了する
- 部分停止：危険な処理だけ止め、参照・取得・ログ出力などは継続する
- スキップ＋通知：対象処理は飛ばし、理由と対象を通知・ログに残す
- 「安全側」を全停止に固定すると、「一部ができないだけで全体が止まる」設計になりやすい
チェックリストの狙い
- ユーザーが想像しづらい「実行不能・例外」を、設計時点で質問として引き出す
- 「止める／スキップする／継続する」を処理単位で設計し、全体停止を最小化する
- 運用開始後に揉めやすい停止条件を、合意・通知・ログまで含めて事前に固定化する
🧩 Q. 外部ファイルを扱う前に確認すべきことは？
A. 外部ファイルは前提を信用せず、構造・命名・内容・運用の観点で事前に確認する。
基本方針
- ダウンロードファイルやユーザー提供ファイルは 常に想定外を含むものとして扱う
- 実装前に「何を前提にしてよいか／よくないか」を明文化する
- チェック項目は Yes / No で答えられる形 にしておく
チェックリスト（Excelに貼り付けて利用可能）
※必要に応じて表全体を選択してコピーし、Excelにそのまま貼り付けてチェックシートとして利用できます。
| カテゴリ | チェック項目 | 補足（判断例） | 確認結果 | メモ |
|---|---|---|---|---|
| ファイル名チェック | ダウンロード時のファイル名は固定か／可変か | |||
| ファイル名チェック | 日付や連番が付くか | |||
| ファイル名チェック | 拡張子はなにか（.xlsx / .csv） | |||
| ファイル名チェック | 同名ファイルが既に存在した場合どうするか | 上書き / 別名保存 / エラー | ||
| ファイル名チェック | ファイル名だけで一意に判定できるか | 日付＋連番で十分 / フォルダ分けが必要 | ||
| Excel・CSVの構成チェック | 列名が重複していないか | 重複したまま扱う / 一意にして列名で操作できるようにする | ||
| Excel・CSVの構成チェック | 必須列が存在するか | |||
| Excel・CSVの構成チェック | 列順は固定か（列名参照可能か） | |||
| Excel・CSVの構成チェック | 型・形式（数値 / 日付 / 文字）が想定通りか | |||
| Excel・CSVの構成チェック | 不要な列が含まれていても問題ないか | 想定外列は無視 / エラー | ||
| シート（Excel特有） | シート数は固定か／可変か | |||
| シート（Excel特有） | シート名は固定か／可変か | |||
| シート（Excel特有） | 対象シートの判定基準 | 名前 / 位置 / 含まれる表 | ||
| シート（Excel特有） | 非表示シートはあるか | 無視 / 対象に含める | ||
| シート（Excel特有） | 複数シートに同一形式のデータがある可能性 | 全シート処理 / 1シートのみ | ||
| 内容（データの健全性） | 0件はあり得るか | |||
| 内容（データの健全性） | ヘッダのみは許容するか | |||
| 内容（データの健全性） | 主キー（業務キー）は何か | 1列 / 複合キー / 値が存在しない可能性 | ||
| 内容（データの健全性） | 重複行・キー重複は許容するか | |||
| 文字コード・区切り（CSV特有） | 文字コード（UTF-8 / Shift_JIS） | |||
| 文字コード・区切り（CSV特有） | 区切り文字（, / \t） | |||
| 文字コード・区切り（CSV特有） | ダブルクォートを含むか | |||
| 運用（再実行・手戻り） | 途中で落ちたら何が残るか | |||
| 運用（再実行・手戻り） | 同じファイルで再処理してよいか／再取得するか | |||
| 運用（再実行・手戻り） | エラー時は「停止」か「スキップ」か | |||
| 運用（再実行・手戻り） | エラー時のファイルの置き場所 | その場に残す / エラーフォルダに退避 / 名前を変える |
📁 ファイル操作設計
🧩 Q. 中間ファイルの名前に、期間や条件を含めるべきか？
A. 人が読む必要がない中間物であれば、期間や条件を名前に含める必要はない。期間や条件は、実行日時や処理ルールなどの再現可能なコンテキストで管理する。
基本方針
- 命名は「誰が読むか」で決める
- 人が読む成果物 → 意味が分かる名前にする
- ロボットが扱う中間物 → 単純で一貫した名前にする
- 再現可能な情報（実行日時・ルールで一意に決まる条件）は、ファイル名やパラメータに重複保持しない
- 条件分岐は、できるだけ後段（加工・抽出）に寄せる
例/ルール
状況
- ある業務システムから、日次で「取引一覧CSV」をダウンロードする処理を作成した
- 実行タイミングによって、ダウンロード対象期間が変わる仕様だった
- 月初実行：前月分（前月1日〜末日）
- 月中実行：当月分（当月1日〜当日）
当初の設計案
- 取得期間が異なるため、ファイル名で区別しようと考えた
- 前月取引.csv
- 当月取引.csv
設計を見直したきっかけ
- 実行日時（実行日・実行月）は、ログや実行フォルダに残るため再現可能である
- 取引データには取引日が含まれており、後工程で期間を絞り込めると分かった
- このCSVはユーザーが直接確認するファイルではなく、後続ロボット処理の入力としてのみ使われる中間ファイルだった
最終的な設計
- ダウンロード時のファイル名は統一する（例：取引.csv）
- 実行条件（月初／月中）は、実行日時フォルダや実行ログから判断できるためファイル名には含めない
- 後工程の抽出処理で、必要に応じて当月分／前月分を切り分けた成果物を作成する
得られた結果
- ファイル名のバリエーションが増えず、パラメータ管理が単純になった
- 実行条件が増えても、命名規則を変更せずに対応しやすくなった
- 中間ファイルの役割が明確になり、設計の見通しが良くなった
🧩 Q. ファイルをテンプレートベースにコピーして、中身にデータを出力したい場合の設計は？
A. テンプレートと完成版を明確に分け、「完成判定」を設計に組み込む。
基本方針
- テンプレート用ファイルと完成版ファイルは必ず別名にする
- 処理が「完了したかどうか」は完成版ファイルの存在で判断する
ファイル命名ルール例
-
テンプレート
Output_Template.xlsx -
完成版
Output.xlsx
完成判定の考え方
- 処理が正常に完了したかどうかは
完成版ファイルが存在するかどうかで判断する
vb.net
File.Exists("C:\Output\Output.xlsx")
-
完成版が存在する
→ 既に処理済み（再実行時はスキップ可能） -
存在しない
→ 未完了、または途中失敗と判断する
ファイル作成手順（再実行前提）
-
テンプレートファイルをコピーする
（この時点ではファイル名はテンプレート名のまま） -
出力するデータを作成する
-
コピーしたテンプレートファイルにデータを貼り付けて保存する
-
テンプレート名のファイルを完成版ファイル名にリネームする
この設計のメリット
-
途中で処理が落ちても
→ 完成版ファイルは作成されない -
再実行時に
→ 完成版ファイルの有無だけを見れば判断できる -
中間状態のファイルを
→ 「完成」と誤認しない
「完成したかどうか」を最後のリネーム操作に集約する設計
設計上の重要な考え方
ファイルコピーやデータ貼り付けは
失敗する可能性がある処理
リネームは
「全てが成功した後」にのみ行う最終処理
そのため、
完成版ファイル名を付ける行為そのものを
「処理完了の証」として扱う
という設計にする。
🧩 Q. 列名重複があるデータは「列名参照」と「列位置参照」どちらで扱うべきか？
A. 原則は列名で扱える形に正規化（列名一意化）する。ただし、利用列が少数で列順が安定している場合は、ヘッダーを読まず列位置で扱う設計も有効。
基本方針
- 列名で操作したい → 列名の重複を解消して読み取る（列名一意化して列名参照を可能にする）
- 使う列が1〜2列だけ → 先頭行をヘッダーとして読まず、列位置（何列目）で扱う
例/ルール
列名参照（推奨）
- 列名が重複している場合は、読み取り前後のどこかで列名を一意化し、以降の処理は列名で統一する
- 列順の入れ替えや列追加が起きても壊れにくく、変更検知がしやすい
列位置参照（条件付きで有効）
- 利用列が少数（例：1〜2列）で、列順が安定している（または固定化できる）場合に採用する
- 先頭行はヘッダーとして読み込まず、1行目はスキップしてデータ行のみを処理する
- 対象列は「何列目か」をパラメーターシートに持ち、実装側はパラメーター参照で列を特定する
適用条件（設計決定前に必ず確認）
- 列順が変わる可能性があるか？
- ヘッダー名が信頼できるか？
- 将来、使う列が増える可能性があるか？
- データ提供元の仕様変更頻度は？