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

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

• このレッスンで作る内容（設計書・フロー・テンプレ・チェック表・文面等）は訓練専用です。通常業務でそのまま使用することは禁止します。
• 就業中に本番用を作る場合は、訓練中の作成物をコピペして使わず、必要情報を取り直し、別途の検収（レビュー/承認）を経て新規作成してください。
• 本レッスンは設計（仕様）までです。実装・設定・連携（API/スクリプト/自動送信/外部ツール接続）は行いません。
• 実データ・個人情報・認証情報（ID/パスワード/APIキー）・未公開情報・契約条件の具体は扱いません（ダミーのみ）。

本レッスンでは、AI/ツールを使った「自動化・効率化」を、思いつき実装ではなく事故らない設計書として書く練習をします。
自動化の失敗は、実装の前に要件（何を/何をしない）、例外（止める条件）、ログ（追える証跡）、監査（説明可能性）を決めていないことから始まります。
L56では「動くもの」を作るのではなく、訓練用の自動化設計パック（設計書／フロー／例外／ログ／テスト計画／移行メモ）を作ります。

このページの使い方

1レッスン＝1LP（1ページ）です。上から順に当日の時間割に沿って進めてください。
各項目の冒頭に EC事業部／文房具カフェ事業部・準備室 の実施時間を併記しています。
※本レッスンはダミーのみで行います（受注処理・顧客対応・発注・交渉・投稿・送信などの実務は実施しない）。

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

• 「自動化」を要件→例外→ログ→監査の順に設計できる
• 自動化の範囲（やる/やらない）を明確にし、危険な自動化を避けられる
• 例外（想定外）を停止条件（要相談）として定義し、事故を止められる
• ログ設計（何を残すか）を定義し、後から説明できる状態にできる
• 訓練成果物を本番に持ち込まないための移行メモ（Handoff Memo）を書ける

受講ルール（共通）

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

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

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

• 目標A（基礎）：TRN-AUT01 設計書ヘッダ（目的/範囲/やらないこと/安全前提）を v0.1 で作る
• 目標B（標準）：フロー（Step表）を7〜15ステップで作り、入力/出力/チェックを揃える
• 目標C（発展）：例外表＋ログ設計＋テスト計画を作り、2サイクル（差戻し→修正）を回す
• 目標D（運用接続）：Handoff Memo を書き、就業中に本番用を新規に作り直すための不足情報・検収観点を整理する

基本：自動化は「実装」より「設計」が8割

自動化で最初に決める順番（結論）

1. 要件：何を自動化する？何をしない？（範囲・対象外）
2. 例外：何が起きたら止める？誰に相談する？（停止条件）
3. ログ：後から追える最小の記録は何？（証跡）
4. 監査：説明可能か？再現できるか？（責任/根拠/改変履歴）

よくある事故パターン（訓練で潰す）

• 要件が曖昧なまま「自動でいい感じに」→誤作動しても止められない
• 例外がない（現場任せ）→困ったときに人が燃える
• ログがない（何をしたか追えない）→原因調査できず再発する
• 監査設計がない（説明できない）→承認されない/不信になる
• 訓練成果物を本番に流用→通常業務との混同・情報管理事故

自動化してよい/しない（訓練用の判断表）

標準テンプレ（TRAINING ONLY／流用禁止）

A) TRN-AUT01 自動化/効率化 設計書（v0.1）

【TRN-AUT01 自動化/効率化 設計書（v0.1：訓練専用／流用禁止）】

Design-ID：TRN-AUT01
版：v0.1
状態：DRAFT / REVIEW / FINAL / DEPRECATED
対象部門（ダミー）：ALL / EC / CF / PR / ACC
テーマ（ダミー）：AUT-56A/B/C（下から選ぶ）

1. 目的（1〜2行）：

* 何を早く/正確に/安全にする？

2. 範囲（やる/やらない）：

* やる：
* やらない（対象外）：
* 実装しない（本レッスンの制約）：設定/連携/自動送信/スクリプトは行わない

3. 役割（抽象ロール）：

* 実務担当：
* レビュー担当：
* 承認担当：
* 要相談窓口（抽象）：

4. 入力（Input：ダミー）：

* 入力ソース（例：ダミー問い合わせログ、ダミー在庫表、ダミー企画書）
* 必須項目：
* 欠損の扱い：要確認（推測しない）

5. 出力（Output：ダミー）：

* 出力先（例：ダミー台帳、ダミー通知文、ダミー分類タグ）
* 出力形式（固定）：

6. 安全・禁止事項（必須）：

* 実データ/個人情報/認証情報/未公開具体：入力禁止
* 断定/確約/法務断言：禁止
* 自動送信・対外送付：禁止（設計のみ）
* 不明は「要確認」に分離（推測禁止）

7. 停止条件（要相談：最低3つ）：

* （例）個人情報が混入した疑い
* （例）法務/権利/契約に触れそう
* （例）誤送信の可能性がある/影響範囲が大きい

8. 成功条件（検証可能に）：

* 何ができたらOKか（例：分類一致率/差戻し率/処理時間 など：ダミーでOK）
* 測り方（ダミー）：

9. 依存・前提（ダミー）：

* 依存：入力の整備、定義、レビュー時間
* 前提：用語定義、禁止事項、停止条件

B) フロー（Step表：7〜15ステップ）

C) 例外表（想定外を想定内にする）

D) ログ設計（項目定義：最小）

【TRN-AUT01 ログ設計（v0.1：訓練専用）】
Log-ID：
日付：
Design-ID / 版：
Case-ID（ダミー）：
実施者（抽象）：
入力の状態（OK/不足/要相談）：
処理結果（OK/差戻し/要相談/保留）：
適用した例外（E-xx）：
チェック結果（どの観点でOK？）：
出力の要点（ダミー）：
差戻し理由（具体）：
次アクション：
メモ：

E) テスト計画（v0.1：訓練用）

【TRN-AUT01 テスト計画（v0.1：訓練専用／実装しない）】

1. テスト方針：

* 目的：誤作動の芽を設計段階で潰す
* 方法：ダミーケースで「OK/差戻し/要相談」を判定できるか確認

2. テストケース（最低6本）：

* TC-01：正常（必須揃い）
* TC-02：必須欠損（E-01）
* TC-03：曖昧入力（推測しないで要確認へ）
* TC-04：禁止事項混入（確約/断定/対外送信の示唆）
* TC-05：個人情報混入の疑い（要相談で停止）
* TC-06：法務/権利/契約に触れそう（要相談で停止）

3. 合格基準（品質ゲート）：

* OK：必須チェックOK、禁止事項ゼロ、ログが残る
* 差戻し：手順抜け/チェック抜け/曖昧語/推測埋め/ログ不足
* 要相談：個人情報・法務/権利・誤送信の恐れ・影響大

4. 改善ログ（v+0.1）：

* 何を/なぜ/どう変える？

F) 品質ゲート（OK/差戻し/要相談）

G) Handoff Memo（移行メモ：本番は訓練外で新規作成）

【TRN-AUT01 Handoff Memo（v0.1：訓練専用／流用禁止）】

目的：

* 就業中に本番用を作る際に「何が不足か」「何を検収すべきか」を整理する（コピペ移行は禁止）

本番化に必要な不足情報（要確認）：

* 入力データの定義（実フィールド名/欠損率/例外の種類）：
* 出力先の要件（誰が見る/期限/形式/責任）：
* 承認フロー（レビュー/承認/監査）：
* ログ保管（期間/アクセス権）：

検収観点（最低5つ）：

1. 範囲（やらないことが明確）
2. 停止条件（要相談で止められる）
3. 誤送信・法務/権利リスクが潰れている
4. ログが追える（再現可能）
5. 例外時の責任分界（誰が判断するか：抽象ロール）

注意：

* 訓練成果物は通常業務で使用禁止。就業中に「本番用」を新規作成する。

ChatGPTに投げるプロンプト（コピペ用：訓練専用）

1) 設計書ヘッダ（要件）を作る

【L56 プロンプト①：自動化設計書ヘッダ（TRN-AUT01 v0.1）】

前提（安全）：

* 教育訓練用ダミー。実データ・個人情報・認証情報・未公開具体は扱わない。
* 本レッスンは設計のみ。実装/設定/自動送信はしない。
* 不明は推測で埋めず「要確認」に分離する。

入力（ダミーテーマ）：

* AUT-56A / AUT-56B / AUT-56C のいずれか（下に記載）

出力形式（必須）：

* TRN-AUT01 設計書（v0.1）の 1)〜9) を埋める
* 停止条件（要相談）を最低3つ
* 禁止事項を必ず明記

2) フロー（Step表：7〜15ステップ）を作る

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

前提：

* 役割は抽象（実務担当/レビュー担当/承認担当）。
* 各Stepに「入力/出力/チェック/例外/ログ」を必ず書く。
* 推測で埋めない（要確認にする）。

入力：

* TRN-AUT01 設計書ヘッダ（v0.1）
* ダミーケース（Case-ID：下の例を使用）

出力形式（必須）：

* Step表（列：Step/作業/担当/入力/出力/チェック/例外/ログ/所要目安/メモ）

3) 例外表＋ログ設計＋品質ゲートを作る

【L56 プロンプト③：例外・ログ・品質ゲート】

前提：

* 不明は推測しない。危険なら要相談で停止。
* 「OK/差戻し/要相談」を明確に。

入力：

* Step表

出力形式：

1. 例外表（例外ID/例外/検知/一次対応/要相談条件/記録）
2. ログ設計（項目定義：最小）
3. 品質ゲート（OK/差戻し/要相談の基準と次アクション）

4) テスト計画（壊し方）を作る

【L56 プロンプト④：テスト計画（v0.1）】

入力：

* TRN-AUT01 設計書（v0.1）
* Step表
* 例外表

出力：

* テストケース最低6本（正常/欠損/曖昧/禁止事項/個人情報疑い/法務権利疑い）
* 合格基準（品質ゲートに接続）
* 改善点（設計の弱い箇所トップ3）

5) 自己評価（新人が回せるか）

【L56 プロンプト⑤：自己評価】

入力：

* あなたの TRN-AUT01 設計パック（ヘッダ/Step/例外/ログ/テスト）

出力：

* 迷う点トップ5（どこが曖昧？）
* 事故りそうな点トップ3（停止条件/ログ/例外不足）
* 改善案（v0.2で直すなら：差分で）

ダミーテーマ（自動化アイデア：訓練用）

以下から1つ選ぶ（または同等レベルの自作ダミーでも可）。実装はしません。

AUT-56A（易）：ダミー問い合わせの「一次分類」設計

目的：問い合わせログ（ダミー）をカテゴリ分類し、次アクションの叩きを作る設計を標準化したい。
入力：ダミー問い合わせ（本文・注文情報は出さない）
出力：カテゴリ（配送/欠品/返品/初期不良/その他）＋要確認質問（最大3つ）＋要相談判定
禁止：返金確約、原因断定、個人情報要求、対外送信（設計のみ）

AUT-56B（中）：ダミー在庫の「異常検知→通知」設計

目的：ダミー在庫表から異常（過不足/滞留/誤登録疑い）を検知し、通知文（ダミー）を作る設計を標準化したい。
入力：ダミー在庫表（SKU名は架空、数値も架空）
出力：異常フラグ、一次対応、通知文（社内向けダミー）
禁止：実SKU・実数値、外部送信、断定（原因推測禁止）

AUT-56C（難）：ダミー企画書の「差戻しポイント抽出」設計

目的：ダミー企画書をレビュー観点でチェックし、差戻しコメントの下書きを作る設計を標準化したい。
入力：ダミー企画書（固有名詞なし、数値は架空）
出力：不足/矛盾/要確認の抽出、差戻し指示（どこ/どう/完了条件）
禁止：権利・契約・法務の断言、実案件の混入

ダミーケース（そのまま使ってOK）

Caseセット（例）

【Case-01】正常（必須揃い）
- Case-ID：C-56-01
- 状況：必須項目は揃っている（ダミー）
- 注意：禁止事項なし（ダミー）

【Case-02】必須欠損（E-01）

* Case-ID：C-56-02
* 状況：必須が2つ欠損（何が欠けたかは自分で列挙）
* 注意：推測禁止。要確認へ

【Case-03】曖昧入力（要確認へ）

* Case-ID：C-56-03
* 状況：表現が曖昧で判断できない（例：いつ頃、たぶん、だいたい）
* 注意：質問は最大3つ

【Case-04】禁止事項混入（要相談で停止）

* Case-ID：C-56-04
* 状況：確約・断定につながる表現が混ざっている疑い（ダミー）
* 注意：止める基準を適用する

【Case-05】個人情報混入の疑い（要相談で停止）

* Case-ID：C-56-05
* 状況：個人情報らしき記述があると仮定（具体は書かない）
* 注意：作業停止→相談

【Case-06】法務/権利/契約の疑い（要相談で停止）

* Case-ID：C-56-06
* 状況：権利・契約に触れそうな論点があると仮定（具体は書かない）
* 注意：作業停止→相談

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

• 訓練専用の担保：TRAINING ONLY／流用禁止が明記され、実在情報・認証情報が混入していないか
• 範囲：やる/やらないが明確で、実装しない制約が書かれているか
• 停止条件：要相談で止められる条件が具体か（最低3つ）
• フロー：7〜15ステップで、入力/出力/チェック/例外/ログが揃うか
• 例外：検知→一次対応→停止条件→記録が揃うか
• ログ：後から追える最小項目が定義されているか
• テスト：壊し方（禁止事項/欠損/曖昧/要相談）が用意されているか

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

【L56 相互レビューコメント】
対象（設計書/Step表/例外/ログ/テスト/移行メモ）：
版：

1. 良い点（1つ）：

*

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

* OK / 要改善
  改善案：
*

3. 範囲（やる/やらない）と停止条件は明確？

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

4. フロー（入力/出力/チェック/例外/ログ）は回る？

* OK / 要改善
  改善案：
*

5. 例外とログは十分？

* OK / 要改善
  足すべき例外 or ログ項目（1つ）：
*

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

* 

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

目次（クリックで移動）

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

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

【実施時間】

この時間にやること

1. 今日の目標（A/B/C/D）を選ぶ
2. ダミーテーマ（AUT-56A/B/C）を1つ選ぶ
3. 自分の注意点を1行で書く（例：実装しない／推測で埋めない／止める条件を必ず書く）

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

【L56 セルフ棚卸し】
1) 今日選ぶダミーテーマ：
- AUT-56A / AUT-56B / AUT-56C

2. 今日の目標（A/B/C/D）：

*

3. 自分が事故りやすい点（1つ）：

* （例：範囲が広がる／例外を忘れる／ログが薄い／止められない）

4. 今日の目標（1行）：

* 

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

【実施時間】

この時間にやること

• 前日までの他者成果物を2件選び、L56レビュー観点でコメントする
• 「動きそう」より、止められる/追える/説明できるを優先して見る

3) 休憩

【実施時間】

休憩：学習作業なし

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

【実施時間】

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

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

## 直す理由（範囲が曖昧／例外不足／ログ不足／停止条件が弱い／推測が混ざる 等）：

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

* 設計書ヘッダ（範囲/禁止/停止条件）：
* Step表（入力/出力/チェック）：
* 例外表（検知→一次対応→停止→記録）：
* ログ設計（項目）：
* テスト計画（壊し方）：
* Handoff Memo（不足情報・検収観点）：

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

* 

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

【実施時間】

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

講師の口頭説明・質疑応答を挟みながら進めます。
午後は、ダミーテーマで設計書→フロー→例外→ログ→テスト→差戻し→v0.2を回します（実装はしない）。

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

• 自動化は「止められる設計」が先（停止条件がない自動化はやらない）
• 例外は「現場対応」ではなく仕様（検知→一次対応→停止→記録）にする
• ログは改善の燃料であり監査の命（最小項目でも必ず定義）
• 訓練成果物は本番に持ち込まない：移行メモで「新規作成」に接続する

5-2. 事故を止める3点セット

• 範囲：やらないこと（対象外）を先に書く
• 停止条件：危険なら止めて相談（要相談）
• ログ：何をしたか、なぜそう判断したかを残す

6) 昼休憩

【実施時間】

昼休憩：学習作業なし

7) 個人演習①：設計書ヘッダ → フロー（Step表）

【実施時間】

演習①のやり方（必須）

1. ダミーテーマ（AUT-56A/B/C）を1つ選ぶ
2. プロンプト①で設計書ヘッダ（v0.1）を作る
3. プロンプト②でStep表（7〜15ステップ）に落とす
4. 曖昧語が残ったら、その場で「定義」「条件」「要確認」に修正する

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

【L56 演習① 提出】
ダミーテーマ：
目標（A/B/C/D）：

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

(2) Step表（7〜15ステップ）：

* 

8) 休憩

【実施時間】

休憩：学習作業なし

9) 個人演習②：例外・ログ・テスト計画 → 差戻し → v0.2

【実施時間】

演習②のやり方（必須）

1. プロンプト③で例外表＋ログ設計＋品質ゲートを作る
2. プロンプト④でテスト計画（壊し方）を作る（最低6本）
3. 相互レビューまたは自己評価（プロンプト⑤）で差戻し点を出し、v0.2に直す（差分を残す）
4. 目標Dの人は、Handoff Memo を書く（本番は訓練外で新規作成）

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

【L56 演習② 提出】
ダミーテーマ：

## (1) 例外表（v0.1→v0.2）：

## (2) ログ設計（v0.1→v0.2）：

## (3) テスト計画（v0.1）：

## (4) 品質ゲート（OK/差戻し/要相談）：

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

* 何を/なぜ/どう変えた？

(6) 任意：Handoff Memo（本番は訓練外で新規作成）：

* 

10) 休憩

【実施時間】

休憩：学習作業なし

11) 復習：共有できる形に整形（訓練用）

【実施時間】

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

【L56 最終チェック】
- 実データ・個人情報・認証情報を使っていない（ダミーのみ）
- 通常業務の代替をしていない（送信/設定/実装をしていない）
- 範囲（やる/やらない）が明確
- 停止条件（要相談）が最低3つある
- Step表が7〜15で、入力/出力/チェック/例外/ログがある
- 例外表があり、検知→一次対応→停止→記録が揃う
- ログ項目が定義され、後から追える
- テスト計画（壊し方）が最低6本ある
- 訓練成果物を本番に流用しない（Handoff Memo があると尚良）

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

【実施時間】

提出先（参考）

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

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

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

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

*
*
*

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

* 今日選んだ目標（A/B/C/D）：
* ダミーテーマ（AUT-56A/B/C）：
* 設計書ヘッダ：作成/更新（v0.1→v0.2 など）：
* Step表：作成（ステップ数）：
* 例外表：作成/更新（E-xx 何本？）：
* ログ設計：作成（項目数）：
* テスト計画：作成（TC 何本？）：
* 差戻し→修正：実施（何サイクル？）：
* Handoff Memo：作成/更新（不足情報・検収観点）：

3. 一番工夫した点（1つ）
   -（例：停止条件を具体化した／ログを最小にした／範囲を狭めた 等）
   理由：

*

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

*

## 理由：

5. 質問（最低1つ）

* 

（参考）このレッスンで特に守ること（まとめ）

• 自動化は要件→例外→ログ→監査の順に設計する
• 危険なら止める（要相談の停止条件を先に書く）
• ログ（証跡）がない自動化は作らない（最小項目で良い）
• 本レッスンは設計のみ：実装・設定・自動送信はしない
• 訓練成果物は通常業務で流用禁止（本番は就業中に新規作成＋検収）

ページ先頭へ戻る