L57：自動化/効率化の設計書テンプレ（要件→例外→ログ→監査）（TRAINING ONLY／流用禁止）

【重要：本レッスンは訓練専用】

• このレッスンで作る内容（設計書・テンプレ・チェック表・ログ項目定義等）は訓練専用です。通常業務でそのまま使用することは禁止します。
• 就業中に本番用を作る場合は、訓練中の作成物をコピペして使わず、必要情報を取り直し、別途の検収（レビュー/承認）を経て本番版を新規に作成してください。
• 本レッスンでは実データ・個人情報・未公開情報・契約条件の具体・実運用の自動実行は扱いません（ダミーのみ／設計のみ）。

本レッスンでは、「自動化/効率化」を実装（コード）ではなく、運用できる設計（設計書）として定義する練習をします。
自動化は、作って終わりではなく、要件→例外→ログ→監査が揃って初めて事故を減らし、引継ぎ可能になります。
L57では、ダミー業務を1つ選び、自動化/効率化の設計書テンプレ（v0.1）を作り、ダミーケースで検証ログ（擬似テスト）→差戻し→v0.2改善まで行います。

このページの使い方

1レッスン＝1LP（1ページ）です。上から順に当日の時間割に沿って進めてください。
各項目の冒頭に EC事業部／文房具カフェ事業部・準備室 の実施時間を併記しています。
※本レッスンはダミーのみで行います（実運用の自動実行、顧客への送信、実システム連携、実データ処理はしない）。

このレッスンの狙い（到達状態）

• 自動化/効率化を「アイデア」ではなく「設計書」として説明できる（要件/範囲/例外/ログ/監査）
• 自動化の入力→処理→出力→例外→記録を、表で再現可能に書ける
• 事故の温床（推測で埋める／個人情報混入／勝手に送信／確約）を止める設計（人の確認・停止条件）にできる
• ログ（何を残すか）と監査（どう確認するか）を定義し、説明責任に耐える形にできる
• 訓練成果物を本番に持ち込まないための移行メモ（Handoff Memo）を書ける

受講ルール（共通）

• 実データ禁止：顧客情報、実在の注文/出荷、実SKU、実価格、実在取引先、未公開企画の具体は入力しない
• 通常業務をしない：訓練日は講義・演習・レビュー・理解度確認に専念する
• 成果物の流用禁止：訓練中に作成した設計書・テンプレ・チェック表は通常業務でそのまま使用しない
• 実装しない：APIキー、RPA、GAS、Webhook等の実運用の自動実行は行わない（設計のみ）
• 命令系統の具体化をしない：役割は「実務担当」「レビュー担当」「承認担当」など抽象ロールで表現する
• 相互レビュー2件以上：前日までの他者成果物に2件以上コメント（本ページのレビュー観点を使用）

今日の目標（できる範囲でOK）

受講者の理解度・進捗にはばらつきがある前提で、以下は「推奨の目標」です。
全部を完成させる必要はありません。今日いちばん伸ばしたいところを選んで進めてください。

• 目標A（基礎）：TRN-OU02 設計書ヘッダ（目的/範囲/対象外/入力/出力/停止条件）を v0.1 で作る
• 目標B（標準）：フロー表（Step表）と要件表（Must/Should/MustNot）を作り、曖昧語を消す
• 目標C（発展）：例外表＋ログ項目定義（スキーマ）＋監査チェックリストを作る
• 目標D（運用接続）：ダミーケースで擬似テスト（3ケース以上）を行い、検証ログ→差戻し→v0.2改善を1回以上回す

自動化/効率化の基本（結論：設計書がない自動化は事故る）

自動化が失敗しやすい理由（訓練で潰す）

• 目的が曖昧：速くしたいのか、ミスを減らしたいのか、誰の何を減らしたいのか不明
• 対象外が書けていない：例外が全部のせになり、現場が混乱する
• 入力が汚い：欠損・表記ゆれ・条件不足を想定せずに止まる／誤動作する
• ログがない：何が起きたか追えず、改善できない
• 監査（確認）設計がない：誤送信・誤判定・情報管理違反が発見できない

設計書に最低限必要な4点セット

• 要件：何を自動化し、何を自動化しないか（範囲/対象外）
• 例外：想定外を想定内に落とす（停止/相談/代替）
• ログ：後から追える（いつ/何/どう判断/結果）
• 監査：誤動作・情報管理違反を見つける（点検/サンプリング/承認）

標準テンプレ（TRN-OU02：自動化/効率化 設計書 v0.1）

A) 設計書ヘッダ（v0.1）

【TRN-OU02 自動化/効率化 設計書ヘッダ（v0.1：訓練専用）】
名称：
版：v0.1
状態：DRAFT / REVIEW / FINAL（訓練用）
目的（1〜2行）：
背景（なぜ必要？）：
範囲（やること）：
対象外（やらないこと）：
前提（訓練専用・実データ禁止・実行しない等）：
関係者ロール（抽象）：
- 実務担当：
- レビュー担当：
- 承認担当：
入力（Input：ダミー）：
出力（Output：ダミー）：
トリガー（いつ動く想定？※訓練では実行しない）：
停止条件（要相談条件）：
成功条件（KPI/判定）：
リスク（情報管理/誤送信/権利/法務/品質/工数）：
ログ方針（残す/残さない）：
監査方針（誰が/いつ/何を見る）：
更新履歴：
- v0.1：初版

B) 要件表（Must/Should/MustNot）

C) フロー表（Step表：設計の本体）

D) 例外表（停止/相談/代替）

E) ログ項目定義（スキーマ：項目だけでOK）

【TRN-OU02 ログ項目定義（v0.1：訓練専用）】
run_id（実行ID：架空）：
timestamp：
input_case_id（ダミーケースID）：
actor_role（抽象）：
decision（OK/差戻し/要相談/停止）：
decision_reason（根拠：観点）：
output_id（出力ID：架空）：
exception_id（E-xx：なければ空）：
change_note（v0.1→v0.2で何を直した？）：
next_action：

F) 監査チェックリスト（サンプリング前提）

G) 品質ゲート（設計書の差戻し基準）

ダミー業務（設計対象：易→中→難）

以下から1つ選び、設計書を作ります（すべて教育訓練用ダミー）。
ポイント：ここで作るのは実装ではなく、運用設計（設計書）です。

OU-57A（易）：入力チェック→エラー一覧化（ダミー）

目的：スプレッドシート（ダミー）の入力ミスを減らす。
流れ（想定）：入力→形式チェック→エラー行を一覧化→修正依頼文（社内向け下書き）を作る。
禁止：実在の顧客情報、実注文番号の入力。自動送信はしない。

OU-57B（中）：一次返信の下書き生成フロー設計（ダミー）

目的：問い合わせ一次返信の「下書き」作成を効率化し、禁止表現混入を減らす。
流れ（想定）：カテゴリ判定→テンプレ選択→質問（最大3つ）→禁止事項チェック→下書き生成→レビュー待ち。
禁止：顧客への自動送信、返金確約、原因断定、個人情報の要求。

OU-57C（難）：KPI異常検知→改善メモ生成（ダミー）

目的：週次KPIの異常検知と改善仮説の整理を効率化する。
流れ（想定）：ダミーKPI入力→異常検知ルール適用→影響の仮説→改善メモ出力→週次会議の議題化（案）。
禁止：実売上・実在庫の投入。断定（原因確定）をしない。

ChatGPTに投げるプロンプト（コピペ用）

1) 設計書ヘッダ＋要件表を作る

【L57 プロンプト①：設計書ヘッダ＋要件（v0.1）】

前提（安全）：

* 訓練用ダミー。実データ・個人情報・契約条件・未公開情報は扱わない。
* 訓練で作った成果物は通常業務で流用禁止。本番は訓練外で新規作成＋検収。
* 実装はしない（自動実行・自動送信はしない）。

入力：

* 選んだダミー業務（OU-57A/B/Cのどれか）を貼る

出力形式（必須）：

1. TRN-OU02 設計書ヘッダ（v0.1）
2. 要件表（Must/Should/MustNot：各3つ以上）
3. 停止条件（要相談条件：3つ以上）

2) フロー表（Step表）に落とす

【L57 プロンプト②：フロー表（Step表）】

前提：

* ダミー前提。実装ではなく設計（手順）を書く。
* 各Stepに「入力/出力/チェック/例外/ログ」を置く。

入力：

* 設計書ヘッダ＋要件表（v0.1）
* 想定粒度：7〜15ステップ

出力形式（必須）：

* フロー表（列：Step/処理/担当/入力/出力/チェック/例外/記録）

3) 例外表＋ログ項目定義を作る

【L57 プロンプト③：例外＋ログ（v0.1）】

前提：

* 不明は推測しない（停止条件へ）。
* 例外は「検知→一次対応→停止条件→記録」まで揃える。

入力：

* フロー表（Step表）

出力形式：

1. 例外表（例外ID/例外/検知/一次対応/要相談条件/記録） ※6本以上
2. ログ項目定義（run_id〜next_action） ※必要なら項目追加

4) 監査チェックリスト＋品質ゲート＋擬似テストケースを作る

【L57 プロンプト④：監査＋品質ゲート＋擬似テスト】

入力：

* 設計書（ヘッダ/要件/フロー/例外/ログ）

出力：

1. 監査チェックリスト（事前/実行想定/事後）
2. 品質ゲート（OK/差戻し/要相談の基準）
3. ダミーの擬似テストケース（3〜5ケース）

   * case_id、入力、期待結果、想定例外、判定観点

5) 設計書が「運用できるか」を自己評価させる（v0.2の改善点）

【L57 プロンプト⑤：自己評価（v0.2案）】

入力：

* あなたのTRN-OU02設計書（v0.1）

出力：

* 曖昧な点トップ5（「何が不明か」まで）
* 追加すべき例外トップ3
* ログで不足している項目トップ3
* v0.2の変更点（差分：何を・なぜ・どう直す）

相互レビュー観点（L57専用）

• 訓練専用の担保：TRAINING ONLY／流用禁止が明記され、実在情報が混入していないか
• 目的・範囲・対象外：やる/やらないが明確で、事故りやすい対象外が書けているか
• 停止条件：要相談（止める条件）が具体で、推測で進めない設計になっているか
• フロー表：入力/出力/チェック/例外/ログが揃い、7〜15ステップの粒度で追えるか
• 例外表：検知→一次対応→停止条件→記録まで揃い、例外が不足していないか
• ログ・監査：判断根拠が追えるか（後から説明できるか）

レビューコメントテンプレ（コピペ用）

【L57 相互レビューコメント】
対象（設計書/フロー/例外/ログ/監査）：
版：

1. 良い点（1つ）：

*

2. 訓練専用の担保（流用禁止・実在情報なし）はOK？

* OK / 要改善
  懸念（あれば）：
*

3. 目的・範囲・対象外は明確？

* OK / 要改善
  曖昧な点（1つ）：
*

4. 停止条件（要相談条件）は具体？

* OK / 要改善
  追加したい停止条件（1つ）：
*

5. 例外＋ログ＋監査は揃っている？

* OK / 要改善
  足りない要素（1つ）：
*

6. 次の一手（v0.2で直すなら）：
   *

本日の流れ（タイムライン）

目次（クリックで移動）

1. 出席・当日選択カリキュラムの内容確認
2. 時間差相互評価（2件以上コメント）
3. 休憩
4. 自分への受領レビュー確認・改善方針メモ
5. L57 レクチャー本編（講師説明・質疑込み）
6. 昼休憩
7. 個人演習①：設計書ヘッダ＋要件＋フロー（v0.1）
8. 休憩
9. 個人演習②：例外＋ログ＋監査＋擬似テスト→v0.2
10. 休憩
11. 復習：共有できる形に整形（できた範囲でOK）
12. 質問・コメント・感想の提出（指定スレッド）

1) 出席・当日選択カリキュラムの内容確認

【実施時間】

この時間にやること

1. 今日の目標（A〜D）を確認（できる範囲でOK）
2. ダミー業務（OU-57A/B/C）を1つ選ぶ
3. 自分の注意点を1行で書く（例：停止条件を曖昧にしない／ログを必ず定義する 等）

セルフ棚卸し（コピペ用）

【L57 セルフ棚卸し】
1) 今日使うダミー業務ID（OU-57A/B/C）：
-

2. 自分が弱い点（1つ）：

* （例：範囲の切り分け／例外設計／ログ設計／監査観点）

3. 今日の目標（1行）：
   *

2) 時間差相互評価（前日までの他者成果物に2件以上コメント）

【実施時間】

この時間にやること

• 前日までの他者成果物を2件選び、L57レビュー観点でコメントする
• 「自動化の良さ」ではなく、事故を止められる設計か（停止条件/例外/ログ/監査）を見る

3) 休憩

【実施時間】

休憩：学習作業なし

4) 自分への受領レビュー確認・改善方針メモ（講師レビュー含む）

【実施時間】

改善方針メモ（コピペ用）

【L57 改善方針メモ】
受領した指摘の要点（最大3つ）：
1)
2)
3)

## 直す理由（範囲/対象外が曖昧／例外不足／ログ不足／監査不足／停止条件が弱い 等）：

直し方（どこを改善する？）：

* 設計書ヘッダ（目的/範囲/対象外/停止条件）：
* 要件表（Must/Should/MustNot）：
* フロー表（入力/出力/チェック/例外/ログ）：
* 例外表：
* ログ項目定義：
* 監査チェックリスト：
* 品質ゲート：

今日の最優先ルール（1行）：

* 

5) 当日選択カリキュラム実施：L57レクチャー本編（講師説明・質疑込み）

【実施時間】

ここからが「読む／聞く」パート

講師の口頭説明・質疑応答を挟みながら進めます。
午後は、ダミー業務を使って設計書（要件→例外→ログ→監査）を作り、擬似テストで差戻し→v0.2改善まで通しで行います。

5-1. L57で一番大事なこと（今日の結論）

• 自動化は設計書が本体（要件/対象外/停止条件がないと事故る）
• 例外は現場任せにしない（止める/相談/代替を決める）
• ログがない自動化は改善できない（判断根拠を残す）
• 監査がないと誤動作に気づけない（サンプリングで良いので点検設計を入れる）

5-2. 人の確認（Human in the Loop）を入れる基準

• 顧客・対外に影響するものは必ず下書き止まり（自動送信しない）
• 情報管理/権利/契約/法務に触れそうなら停止→要相談
• 入力が不足している場合は推測しない（質問化して止める）

6) 昼休憩

【実施時間】

昼休憩：学習作業なし

7) 個人演習①：設計書ヘッダ＋要件＋フロー（v0.1）

【実施時間】

演習①のやり方（必須）

1. ダミー業務（OU-57A/B/C）を1つ選ぶ
2. プロンプト①で設計書ヘッダ＋要件表を作る（v0.1）
3. プロンプト②でフロー表（7〜15ステップ）に落とす
4. 曖昧語（適宜/いい感じ/なるべく）が出たら、条件/定義/停止に置換する

提出用フォーマット（演習①：コピペ用）

【L57 演習① 提出】
ダミー業務ID：

## (1) 設計書ヘッダ（v0.1）：

## (2) 要件表（Must/Should/MustNot）：

(3) フロー表（7〜15ステップ）：

* 

8) 休憩

【実施時間】

休憩：学習作業なし

9) 個人演習②：例外＋ログ＋監査＋擬似テスト→v0.2

【実施時間】

演習②のやり方（必須）

1. プロンプト③で例外表（6本以上）＋ログ項目定義を作る
2. プロンプト④で監査チェックリスト＋品質ゲート＋擬似テストケース（3〜5）を作る
3. 擬似テストを回し、検証ログを残す（OK/差戻し/要相談）
4. プロンプト⑤で自己評価し、v0.2として差分（何を・なぜ・どう）を1回以上反映する

検証ログ（コピペ用）

【L57 検証ログ（v0.1：訓練専用）】
run_id：
対象設計書：TRN-OU02（版：v0.1→v0.2）
ダミー業務ID：

テストケース：

* case_id：
  入力（ダミー）：
  期待結果：
  実結果：
  判定（OK/差戻し/要相談）：
  根拠（観点）：
  修正（どこ/どう/完了条件）：
  次アクション：

改善ログ（v0.2差分）：

* 変更理由：
* 変更内容：
* 影響範囲：

提出用フォーマット（演習②：コピペ用）

【L57 演習② 提出】
ダミー業務ID：

## (1) 例外表（v0.1→v0.2 できた範囲で）：

## (2) ログ項目定義（v0.1）：

## (3) 監査チェックリスト＋品質ゲート：

## (4) 検証ログ（3ケース以上が目安／できた範囲でOK）：

(5) v0.2の変更点（差分：何を・なぜ・どう直した？）：

* 

10) 休憩

【実施時間】

休憩：学習作業なし

11) 復習：共有できる形に整形（できた範囲でOK）

【実施時間】

最終チェック（コピペ用）

【L57 最終チェック】
- 実データを使っていない（ダミーのみ）
- 通常業務の代替をしていない（実運用の自動実行・顧客送信をしていない）
- 訓練成果物は流用禁止が明記されている
- 目的/範囲/対象外/停止条件がある
- 要件（Must/Should/MustNot）がある
- フロー表に入力/出力/チェック/例外/ログがある
- 例外表（検知→一次対応→停止条件→記録）がある
- ログ項目定義がある（判断根拠が追える）
- 監査チェックリストがある（点検の設計がある）
- 品質ゲート（OK/差戻し/要相談）が明確（曖昧語なし）

12) 講師への質問・コメント・感想の提出（指定スレッド）

【実施時間】

提出先（参考）

EC事業部・文房具カフェ事業部：ChatWork の指定スレッド／準備室：Slack の指定スレッド

提出テンプレ（コピペ用）

【L57 提出（本人レポート）】

1. 今日の学習内容（要約：3行）

*
*
*

2. 今日進めたこと（TRAINING ONLY：流用禁止）

* 選んだダミー業務ID（OU-57A/B/C）：
* 設計書（TRN-OU02）：v0.1→v0.2（できた範囲で）：
* 要件（Must/Should/MustNot）：作成/更新：
* 停止条件（要相談条件）：設定（何個？）：
* 例外表：作成（何本？）：
* ログ項目定義：作成/更新：
* 監査チェックリスト：作成/更新：
* 擬似テスト：実施（何ケース？）：
* 差戻しで直した点（1つ以上）：

3. 一番工夫した点（1つ）
   -（例：対象外を明確化した／停止条件を具体化した／ログで根拠が追えるようにした 等）
   理由：

*

4. 次に改善したい点（1つ）

*

理由：
*

5. 質問（最低1つ）
   *

ページ先頭へ戻る