この教材の位置づけ

この教材は、ChatGPTの機能一覧ではありません。

「ChatGPTは質問に答えるだけのものではなく、資料を読み、整理し、文章を作り、比較し、チェックし、成果物にしていく作業相手なんだ」

これを、普段チャットしか使っていない3人に腹落ちさせるための研修台本です。

受講者は3人。

教材は、この3人のどれかに寄せません。同じ機能を、3つの現場に翻訳して見せるのがこの研修の基本形です。

研修の3つの合言葉

1. まずは画面で見せる — 説明より先に動かす。
2. 自分の仕事や勉強に置き換えさせる — 見せた直後に「あなたなら何を入れる？」と必ず振る。
3. 最後はAIにチェックさせる。ただし人間が確認する — この2つはセットで、片方だけでは教えない。

教材フォーマット（HTML化前提）

• ## が1項目 = 1ページ。
• ### が各ページ内の固定セクション（全項目で同じ13個・同じ順番・同じ文言）。
• 見出し文言は全項目で完全に揃えてあるので、## 単位で切ればそのままページ分割できます。

固定セクションは以下の13個です。

1. この項目で教えたいこと
2. 講師の考え方を反映した説明
3. 普通のチャットだけの場合との違い
4. 研修での実演
5. サンプル問題
6. 社労士での活かし方
7. 医学部生での活かし方
8. システムエンジニアでの活かし方
9. そのまま使えるプロンプト
10. 組み合わせるとよいフレームワーク
11. 失敗しやすい使い方
12. 最後の確認
13. 到達目標

研修全体のストーリー

ストーリーの骨格

この研修は、次の1本の線で通します。

「チャットに聞く」から「Workで作る」へ。 材料を渡す → 場所を決める → 読ませる → 作らせる → 比べる → チェックさせる → 人が確認して出す。

30項目はバラバラの機能紹介ではなく、この1本の線のどこかに置かれています。研修中は毎回「今、この線のどこをやっているか」を口に出してください。

第0幕：ここで一発かます（開始5分）

研修の冒頭で、説明を一切せずに、いちばん難しいPDFを読ませて要約させます。

• 社労士なら、障害年金の認定基準や通達のPDF。
• 医学部生なら、英語論文か診療ガイドラインのPDF。
• SEなら、100ページ級の仕様書。

受講者が「自分では読む気にならない資料」を選ぶのが肝です。ここで「これはすごい」と体感させられたら、残り全部が入ります。逆にここで「へえ」で終わると、あとは全部座学になります。この5分に研修の成否がかかっています。

かます時のセリフ：

「今から、あなたが一番読みたくない資料を読ませます。何も設定しません。ただ投げ込むだけです。」

第1幕：作業場を作る（項目1〜6）

一発かましたあとで、「じゃあこれ、毎回ゼロから貼るんですか？」という疑問が必ず出ます。そこでProjectsに入ります。

フォルダーイコールProject。 これ以上の説明はいりません。数学は数学のフォルダー、理科は理科のフォルダー。障害年金のAさんはAさんのフォルダー。同じことです。

さらに、1つのフォルダーの中でも会話は分けます。調査、作成、チェックの3つに分ける。 これが第1幕のゴールです。

第2幕：材料を読ませる（項目7〜10）

作業場ができたら、材料を放り込みます。ファイル一覧、PDF・Word、Excel・CSV、画像・スクショ。

ここは全部実演で見せるパートです。特にファイル一覧をExcelにする実演と、レシート画像を家計簿風の表にする実演は、受講者3人全員が「明日それやる」と言うタイプの実演なので必ず入れます。

第3幕：比べる・組み立てる（項目11〜14）

材料が読めたら、次は判断です。

ChatGPT・Claude・Geminiに同じ質問をして、回答を比較し、いいとこ取りして最高の資料を作る。変更前後の資料を比較して、意味が変わったところを見つけさせる。そこからチェックリストと手順書に落とす。

この幕で、受講者は「AIは答えを出す機械」から「複数の案を出させて自分が選ぶための道具」に認識が変わります。

第4幕：外とつなぐ（項目15〜19）

社内・手元の資料だけでは足りない時、外を見に行かせます。

ここで教える癖は1つだけ。「Webを検索して」「公式情報を確認して」と明示する。 黙っていると、AIは頭の中の記憶で答えます。年金の制度も、診療ガイドラインも、ライブラリのバージョンも、記憶で答えられたら事故です。

第5幕：成果物にする（項目20〜24）

読んで、比べて、外も見た。ここでようやく成果物を作ります。

編集スペース（Canvasという言葉は古いので研修では使いません）、メール文、PowerPoint、図（Mermaid）、そして自分専用の管理画面。「チャットの返事」ではなく「ファイルと画面」が出てくる、というのがこの幕の驚きです。

第6幕：仕事を分解して回す（項目25〜27）

大きい仕事を、GitHub Issue風のタスクに割る。それを段階的な自動化チェーンにする。そして最後に、

「あれ、これ毎回同じことやってません？」 「じゃあSkillにしましょう」

Skillsは最初に説明しません。 さんざん手作業をやらせた後で出すから効きます。最初に出すと「便利な機能その27」になって終わります。

第7幕：安全に使う（項目28〜30）

個人情報・機密情報、外部ツールの権限と承認、モデル選択と利用枠。

ここは研修の最後ですが、いちばん時間を取ってください。 社労士は障害年金の顧客情報、医学部生は患者症例、SEは本番接続情報を扱います。3人とも「入れてはいけないもの」を持っている人たちです。

第8幕：仕上げのフレームワーク（全項目に分散＋最後に総まとめ）

Grill me、Sanity check、What am I missing?、Edge cases、Make it actionable、Fill the gaps、Misread test、Smoke test。

この8つは最後にまとめて教えるだけでなく、各項目の中に組み込んであります。 研修中に何度も出てくるので、最後には「またこれか」になっているのが理想です。合言葉はこれです。

最後はAIにチェックさせる。ただし人間が確認する。

30項目をどの順番で教えるとよいか

推奨順序（項目番号は本文の番号）

順序で絶対に守ること

• 項目8（PDF読解）を最初に持ってくる。 番号順に1から始めると、いきなり画面説明になって熱が入りません。
• 項目27（Skill creator）を最後の方に置く。 手作業を繰り返させた後でないと価値が伝わりません。
• 項目16・18（Web検索・公式情報確認）は早めに前倒しする。 「AIは記憶で答えることがある」という警戒心は、早く持たせるほど後の事故が減ります。
• 項目28〜30は必ず研修内でやる。 「時間が余ったら」にすると必ず飛びます。

時間配分の目安（1日6時間の場合）

フレームワーク早見表

各項目の「組み合わせるとよいフレームワーク」で使う8個です。研修では、この表をA4に印刷して受講者の手元に置いてください。

使い分けの一言： Grill meは「殴らせる」。Sanity checkは「変じゃないか見せる」。What am I missing?は「作る前」。Edge casesは「例外」。Make it actionableは「動く形に」。Fill the gapsは「AIに聞かせる」。Misread testは「読み手の目」。Smoke testは「出す直前」。

ChatGPT Workの使い方

この項目で教えたいこと

ChatGPT Workは「賢いチャット」ではなく、成果物を作る作業場である、ということ。

チャットは会話が流れていく場所です。Workは、材料（ファイル）を置いて、ルールを貼って、作業を分けて、成果物を出す場所です。机の上に資料を広げて作業している状態そのものだと理解させます。

講師の考え方を反映した説明

研修ではこう言ってください。

「これは検索窓じゃないです。作業場です。 机があって、書類が置けて、『この案件ではこのルールで作業して』と貼り紙ができる。 皆さんが今まで使っていたチャットは、机のない立ち話でした。」

そして、いきなり実演に入ります。まずは画面で見せる。 説明が3分を超えたら負けだと思ってください。

順番も重要です。この項目は研修の2番目にやります。1番目は項目08のPDF読解で一発かます。かました直後に「今のは作業場でやりました」と種明かしをする、この流れで教えます。

普通のチャットだけの場合との違い

研修での実演

1. 何も説明せず、受講者に「一番読みたくない資料」を1つ出させる。
2. その場でWorkに投げ込み、「これを3ページで要約して」とだけ打つ。
3. 出てきた要約を読み上げる。ここで沈黙を作る。
4. 「今、私は設定を何もしていません」と言う。
5. そこで初めて画面を指して、「ここが作業場です。ここが材料置き場、ここがルール、ここが会話です」と3か所だけ指す。
6. 同じ資料をチャット（新規会話）に貼って、同じ質問をする。違いを並べて見せる。

指すのは3か所だけ。 画面の全ボタンを説明した瞬間に、受講者の目が死にます。

サンプル問題

手元にある「読むのが面倒な資料」を1つ選び、Workに入れて次の指示だけ出してください。 「この資料を、初めて読む人向けに3ページ分の要約にしてください。」

出てきた要約を見て、自分が読むより速かったか、遅かったかを口で言ってください。

社労士での活かし方

障害年金の1件を「作業場ごと」立ち上げます。診断書、病歴就労状況等申立書の下書き、受診状況等証明書、参考にする認定基準を1か所に置き、そこで請求書類一式を組み立てる。案件が終わるまで机はそのまま残ります。

医学部生での活かし方

1科目・1試験を作業場にします。講義スライド、配布資料、過去問、自分のまとめノートを置いて、そこで「試験対策資料」を作っていく。試験が終わるまで机はそのまま。次の科目は別の机。

システムエンジニアでの活かし方

1案件・1機能を作業場にします。仕様書、既存設計書、画面キャプチャ、質問リストを置いて、そこで理解メモ・タスク一覧・確認事項リストを作る。レビュー指摘が来たら同じ机に追加する。

そのまま使えるプロンプト

この作業場には、私が今扱っている案件の資料を置いています。
まず、置いてある資料の中身を確認して、次の3つを出してください。

1. この資料は何の資料か（1行ずつ）
2. 私がこれから作ろうとしている成果物として考えられるもの
3. 作業を始める前に、私に確認しておきたいこと（最大3つ）

組み合わせるとよいフレームワーク

Make it actionable — 作業場を作っただけで満足させないため。

Make it actionable. この作業場の資料をもとに、私が明日すぐ実行できる手順、
準備物、チェックリストにしてください。

Smoke test — 作業場の初期設定が最低限使える状態かの確認。

この作業場の設定をスモークテストしてください。細かい改善ではなく、
最低限使えるかを確認してください。資料の不足、ルールの矛盾、
私が次に何をすればよいかを確認してください。

失敗しやすい使い方

• 全部の会話をWorkに持ち込む。 「今日の天気」まで作業場に入れると、机の上がゴミだらけになります（判断基準は項目02）。
• 資料を置いただけで指示を出さない。 置いただけでは何も起きません。作業場は勝手に働きません。
• 最初にボタンを全部説明する。 講師がやりがちな最大の失敗です。3か所だけ指す。
• 社内・顧客の生データをいきなり置く。 何を置いてよいかは項目28を先に決めてから。

最後の確認

• 出てきた要約・成果物を、元の資料と1か所だけ突き合わせる（数字か固有名詞を1つ）。
• 「作業場に置いた資料以外の知識で書いた部分はどこですか」と聞いて、AI自身に線を引かせる。
• そのうえで、人間が読む。 読まずに出さない。

到達目標

• 「Workは作業場である」と自分の言葉で他人に説明できる。
• 自分の案件を1つ選び、作業場を1つ立ち上げられる。
• チャットとWorkの出力の違いを、自分の資料で1回体験している。

Work向き・普通のチャット向きの判断

この項目で教えたいこと

全部をWorkに持ち込まない。 作業場は、成果物を作る時に使うもので、思いつきの質問には重すぎます。

この線引きを最初に教えておかないと、受講者は「とりあえずProjectを作る人」になり、机が20個できて、どこに何があるか分からなくなって、結局チャットに戻ります。

講師の考え方を反映した説明

判断基準は1つだけ教えます。

「成果物が残るか？」

残るならWork。残らないならチャット。

「この英単語なんだっけ」は残らない。だからチャット。 「この案件の書類一式を作る」は残る。だからWork。

もう1つ、補助の質問。

「同じ資料をもう一度使うか？」 使うならWork。1回きりならチャット。

この2つで9割さばけます。迷ったらチャットで始めて、続きそうならWorkに引っ越す、と教えます。先に完璧に分類させない。

普通のチャットだけの場合との違い

チャットしか知らない人は、そもそも「使い分ける」という発想がありません。全部を1本の会話に入れて、3日後に「あの話どこいった」となります。

判断を教えるということは、「捨てていい会話」と「育てる会話」を分ける習慣を教えるということです。

研修での実演

1. ホワイトボード（または画面）に2列作る：「チャット」「Work」。
2. 講師が10個のお題を読み上げ、受講者に「どっち？」と即答させる。 - 「メールの英語表現を1つ確認したい」→ チャット - 「Aさんの障害年金請求書類一式を作る」→ Work - 「今日の会議の議事録を清書して、来月も同じ形式で使う」→ Work - 「この漢字の読み方」→ チャット - 「循環器の試験対策を3週間分作る」→ Work - 「この関数の書き方だけ知りたい」→ チャット - 「この仕様書を読んでタスクに割る」→ Work - 「昼ごはんのおすすめ」→ チャット - 「毎月の請求データを同じ形式で集計する」→ Work - 「英単語の意味」→ チャット
3. 間違えたものだけ、なぜそう判断したかを言わせる。

この実演は3分で終わります。 短いのが正解です。

サンプル問題

直近1週間に自分がやった作業を5つ書き出してください。 それぞれ「チャット向き」「Work向き」に分け、Work向きに分類したものについては、 作業場の名前を1つ考えてください。

社労士での活かし方

• チャット：「傷病手当金の支給期間って何か月でしたっけ」（※ただし制度の確認は項目18に従い、必ず公式で裏取り）
• Work：「Aさんの障害基礎年金の請求一式」「事務所の顧客対応テンプレート整備」

顧客名が出てくる作業は、ほぼWork側です。かつ、そこで個人情報の扱いルール（項目28）が必要になります。

医学部生での活かし方

• チャット：「この略語の正式名称は」
• Work：「循環器の定期試験対策」「臨床実習前のOSCE準備」「レポート1本の作成」

科目が変わったら机も変わる、と覚えさせます（項目04）。

システムエンジニアでの活かし方

• チャット：「この正規表現の意味」「このエラーメッセージの一般的な原因」
• Work：「◯◯システム改修案件」「移行手順書の作成」「障害報告書の作成」

チケット1枚以上の重さがあるならWork、というのがSEには一番通じる言い方です。

そのまま使えるプロンプト

これから私がやろうとしている作業を説明します。
この作業を、

A. 使い捨てのチャットでやるべきか
B. 資料を置いて継続する作業場（Project）でやるべきか

を判断して、理由を1行で答えてください。
Bの場合は、作業場の名前の案を3つ出してください。

【作業内容】
（ここに書く）

組み合わせるとよいフレームワーク

Sanity check — 自分の分け方が変ではないかを見てもらう。

Sanity check. 私が作った「チャット向き／Work向き」の分類に、
常識的な矛盾、前提ミス、抜け、読んだときの違和感がないか確認してください。

What am I missing? — 分類そのものより、作業場を作る前の準備漏れを潰す。

What am I missing? この作業を作業場で進める計画で、見落としている情報、
確認事項、リスク、準備物を挙げてください。

失敗しやすい使い方

• 何でもProjectを作る。 机が増えすぎて管理不能になります。
• 逆に、何でもチャットで済ませる。 同じ資料を毎回貼り直すことになり、結局手間が増えます。
• 最初に完璧な分類表を作ろうとする。 使いながら直せばよい、と伝えてください。
• 判断をAIに丸投げして自分で考えない。 判断基準は人間側に残す。

最後の確認

• 作った作業場の数を数える。5個を超えたら一度見直す。
• 1か月使っていない作業場は、閉じるか統合する。
• 「これ、チャットで十分だったな」というものを1つ見つけて口に出す。

到達目標

• 「成果物が残るか」で即座に判断できる。
• 自分の作業を5つ、迷わず振り分けられる。
• 作業場を作りすぎない意識を持っている。

Projects

この項目で教えたいこと

Projectは、フォルダーです。 それ以上でもそれ以下でもありません。

技術的な説明を一切せず、この一言で通します。「Projectとは、会話とファイルとカスタム指示をまとめる論理的なコンテナで……」と説明した瞬間に、受講者の顔が曇ります。

講師の考え方を反映した説明

研修での言い方は、これで固定します。

「フォルダーイコールProject。」

パソコンにフォルダー作りますよね。あれと同じです。 中に資料を入れて、その中で作業する。それだけです。

違うのは1つだけ。このフォルダーは中身を読んでくれる。

そして、パソコンのフォルダーとの対応表を1枚見せます。

「フォルダーは中身を読んでくれる」 — この一言が、この項目の全部です。

普通のチャットだけの場合との違い

チャットは、資料を貼るたびに「初めまして」から始まります。Projectは、フォルダーを開いた時点で中身を知っている状態から始まります。

具体的には、チャットで20ページのPDFを毎回貼っていた人が、貼らなくてよくなります。 これは体感で分かるので、実演で見せます。

研修での実演

1. Projectを1つ作る。名前を付けるところを見せる（名前は具体的に：×「仕事」、○「Aさん_障害厚生年金_2026」）。
2. ファイルを3つ入れる。
3. 1本目の会話で「このフォルダーに何が入っているか教えて」と聞く。
4. 2本目の新しい会話を同じProjectの中で開き、いきなり「1つ目の資料の要点を5行で」と聞く。ファイルを貼っていないのに答えることを見せる。
5. Projectの外（普通のチャット）で同じことを聞く。答えられないことを見せる。

4と5の対比が、この実演の全てです。 ここを飛ばさないでください。

サンプル問題

自分の作業場を1つ作り、次の3つをやってください。

1. Projectに具体的な名前を付ける（案件名・科目名・日付を入れる）
2. 関係する資料を3つ入れる
3. 新しい会話を1本開いて、資料を貼らずに「入っている資料の一覧と、それぞれ1行の説明」を出させる

社労士での活かし方

顧客1人につき1フォルダー。中に診断書、申立書の下書き、受診状況等証明書、ヒアリングメモ、参考にする認定基準を入れる。

フォルダー名は「顧客名_請求内容_年」の形にすると、あとで探せます。ただし、顧客の実名をフォルダー名に入れるかどうかは項目28のルールで先に決めてください。 匿名ID（A様、案件番号）で運用するのが安全です。

医学部生での活かし方

科目ごとに1フォルダー。数学は数学、理科は理科。 医学部なら、循環器は循環器、呼吸器は呼吸器。

中に講義スライド、配布プリント、自分のノート、過去問を入れる。試験が終わったら、そのフォルダーは「復習用」としてそのまま残しておけます。国試の時に効いてきます。

システムエンジニアでの活かし方

案件ごと、あるいは機能ごとに1フォルダー。仕様書、設計書、画面キャプチャ、既存コードの抜粋、議事録を入れる。

リポジトリ1つ＝Project1つ、と考えると分かりやすいですが、大きい案件なら「機能単位」に割ってください（項目04）。

そのまま使えるプロンプト

このフォルダー（Project）に入っている資料を全部確認して、次を出してください。

1. ファイル名 / 種類 / 1行の内容説明 の表
2. この資料群から作れそうな成果物の候補（3つまで）
3. このフォルダーに足りていないと思われる資料

組み合わせるとよいフレームワーク

Make it actionable — フォルダーを作って終わりにしない。

Make it actionable. このフォルダーの資料をもとに、明日すぐ実行できる
作業手順、準備物、チェックリストにしてください。

Edge cases — フォルダー分けが破綻するパターンを先に知る。

Edge cases. このフォルダー分けのルールがうまく当てはまらない例外ケースを挙げ、
それぞれの対処方法も出してください。

失敗しやすい使い方

• フォルダー名が「仕事」「勉強」。 3個作った時点で判別不能になります。
• 資料を入れずにProjectだけ作る。 空のフォルダーは何もしてくれません。
• 古い資料を入れっぱなしにする。 差し替えたら古い版は消すか、明示的に「旧版」と分かる名前にする。これは項目12（変更前後比較）で効いてきます。
• 1つのフォルダーに全案件を突っ込む。 項目04で潰します。

最後の確認

• フォルダー名を見て、3か月後の自分が中身を思い出せるかを確かめる。
• 「入っている資料の一覧」を出させて、意図しないファイルが混ざっていないか目視する。
• 個人情報・機密情報が入っていないか、項目28のルールで確認する。

到達目標

• 「フォルダーイコールProject」と即答できる。
• 具体的な名前でProjectを1つ作れる。
• 新しい会話を開いても資料が引き継がれることを、自分の目で確認している。

1仕事1Project

この項目で教えたいこと

1つの仕事に、1つのフォルダー。 混ぜない。

これは技術の話ではなく、運用の話です。混ぜると、AIが前の案件の情報を引きずってきます。社労士なら他の顧客の情報、医学部生なら別科目の知識、SEなら別システムの仕様。これは事故です。

講師の考え方を反映した説明

「数学は数学のフォルダー、理科は理科のフォルダー。 数学のフォルダーに理科のプリントを入れたら、どうなりますか。 AIは、混ざったまま考えます。

障害年金のAさんのフォルダーにBさんの診断書が入っていたら、 Aさんの申立書にBさんの症状が混ざる可能性があります。 これは『AIが間違えた』ではなく、『机を片付けなかった』です。」

この「机を片付けなかった」という言い方が、この項目のキモです。責任の所在を人間側に置きます。

普通のチャットだけの場合との違い

チャットでは、1本の会話に全部を貼り込むので、混ざるのが前提でした。「さっきの話は忘れて」と書いて、忘れてくれることを祈る状態です。

1仕事1Projectにすると、忘れさせる必要がなくなります。 そもそも別の机なので。

研修での実演

1. わざと「混ざったProject」を用意しておく。案件Aの資料と案件Bの資料を1つのフォルダーに入れておく。
2. そこで「Aさんの状況を要約して」と聞く。Bさんの情報が混ざった出力を見せる（うまく混ざらない場合は「両方の資料を踏まえて」と誘導して見せる）。
3. 受講者に「今の、何が起きましたか」と聞く。
4. Projectを分けて、同じ質問をする。混ざらないことを見せる。
5. 「AIが悪いのではなく、机が汚かった」と締める。

サンプル問題

自分の作業を3つ挙げて、それぞれにフォルダーを作ってください。 そのうえで、次を自分で答えてください。

• この3つのフォルダーに、両方に入りそうな資料はありますか？
• あるなら、それはどちらに置きますか？置く理由は？

（答えは「両方に置く」でも構いません。ただしなぜそうしたかを言えることが条件です）

社労士での活かし方

顧客1人＝1フォルダーが基本です。同じ顧客でも、障害年金請求と就業規則作成は別フォルダーにします。参照する制度も、書類の様式も、必要な情報も全然違うからです。

一方で、「認定基準・通達の参照用フォルダー」は案件横断で1つ作っておくと便利です。案件フォルダーは分ける、参考資料フォルダーは共通、という2階建てを教えてください。

医学部生での活かし方

科目ごとに1フォルダー。さらに、大きい科目は「試験対策」「レポート」「実習」で分けます。

やってはいけないのは「医学部」という1個のフォルダーです。3年分の資料が入って、循環器を聞いたのに解剖学の話が混ざります。

システムエンジニアでの活かし方

案件単位、または機能単位。判断基準は「リリース単位で分ける」です。同じリリースに乗るものは同じフォルダー、別リリースなら別フォルダー。

さらに、「本番調査」と「新規開発」は絶対に混ぜないでください。前者には障害情報、後者には仕様の理想像が入っており、混ざると事実と願望が混ざります。

そのまま使えるプロンプト

これから3つの作業を説明します。
これらを、いくつのフォルダー（Project）に分けるべきか提案してください。

出してほしいもの：
1. 推奨するフォルダー構成（名前付き）
2. なぜその分け方か（1つにつき1行）
3. どちらに入れるか迷う資料と、その置き場所の推奨

【作業1】（ここに書く）
【作業2】（ここに書く）
【作業3】（ここに書く）

組み合わせるとよいフレームワーク

Sanity check — 分け方が常識的に破綻していないか。

Sanity check. このフォルダーの分け方に、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。

Edge cases — 分類しきれない資料を先に洗い出す。

Edge cases. このフォルダー分けのルールが当てはまらない資料や状況を挙げ、
それぞれの対処方法も出してください。

失敗しやすい使い方

• 「とりあえず全部入れておこう」。 一番よくある事故の元です。
• フォルダーを分けたのに、会話の中で他案件の話を持ち出す。 机を分けても、口で混ぜたら同じです。
• 細かく分けすぎる。 1タスク1フォルダーにすると、今度は探せなくなります。目安はリリース／案件／科目の単位。
• 参考資料まで案件ごとに複製する。 更新漏れが出ます。参照用は1つにまとめる。

最後の確認

• 各フォルダーで「このフォルダーに入っている資料を一覧にして」と聞き、他案件の資料が紛れていないかを目視する。
• 混ざりを見つけたら、削除ではなく移動する（消すと後で困ります）。
• 顧客名・患者情報・システム名など、混ざると重大なものを優先的に確認する。

到達目標

• 1仕事1フォルダーの原則を、理由付きで説明できる。
• 自分の作業を3つ、適切な粒度で分けられる。
• 混ざった時に「AIのせい」ではなく「机の管理」と考えられる。

Project instructions

この項目で教えたいこと

Project instructionsは、そのフォルダーの中でChatGPTに毎回守ってほしいルールです。

「貼り紙」と説明します。机の前の壁に貼ってある紙で、そのフォルダーで作業するときは毎回それを読んでから始める。それだけのものです。

講師の考え方を反映した説明

「新しいアルバイトが来るたびに、同じ説明を毎回するの、面倒ですよね。 だから壁に紙を貼るんです。 『この案件では、必ず出典を書くこと』 『敬語で書くこと』 『分からないことは推測せず質問すること』

Project instructionsは、この貼り紙です。 フォルダーの中で会話を何本開いても、全部の会話がこの紙を読んでから始まります。」

そして、貼り紙に書くべき内容を4つに絞って教えます。長い貼り紙は誰も読みません（AIも実質そうです）。

1. 立場：あなたは誰として振る舞うか
2. 出力の形：どういう形で出してほしいか
3. やってはいけないこと：推測禁止、断定禁止など
4. 分からない時の動き：質問する／保留にする／人間に振る

普通のチャットだけの場合との違い

チャットでは、毎回の指示の冒頭に「あなたは社会保険労務士として……」と書いていました。書き忘れると口調が変わり、出典が消え、いつの間にか推測で書き始めます。

貼り紙にしておくと、書き忘れが起きません。 これが一番大きい違いです。

研修での実演

1. 貼り紙が空の状態で「この資料を要約して」と聞く。出力を見せる。
2. その場で貼り紙を書く。画面に打ちながら、4項目を声に出して埋める。
3. 新しい会話を開いて、まったく同じ質問をする。
4. 2つの出力を左右に並べて見せる。口調、構成、出典の有無が変わっていることを指差す。

「同じ質問なのに、出力が変わった」 — この驚きが実演のゴールです。

サンプル問題

自分のフォルダーに、次の4行を埋めた貼り紙を書いてください。

1. あなたは（　　　）として回答してください。
2. 回答は（　　　）の形式で出してください。
3. （　　　）は絶対にしないでください。
4. 分からないことは（　　　）してください。

書いたら、新しい会話を1本開いて、同じ質問を貼り紙ありとなしで比べてください。

社労士での活かし方

障害年金のフォルダーなら、貼り紙はこうなります。

あなたは障害年金請求を担当する社会保険労務士の補助者です。

- 認定基準や通達に触れる場合は、必ず「出典（名称・条項）」を併記してください。
- 出典が特定できない場合は、断定せず「要確認」と明記してください。
- 顧客の症状・経過については、資料に書かれていない内容を推測で補わないでください。
- 医学的判断・等級の断定はしないでください。判断が必要な箇所は「社労士確認事項」として一覧にしてください。
- 出力は、そのまま書類に転記できる文体（です・ます、簡潔）でお願いします。

「推測で補わない」「等級を断定しない」 — この2行が、社労士のフォルダーでは最重要です。

医学部生での活かし方

あなたは医学部3年生の学習をサポートする教育担当です。

- 説明は、まず結論、次に理由、最後に「試験で問われる形」の順で書いてください。
- 治療方針や薬剤量については、必ず「必ず最新のガイドライン・添付文書で確認」と注記してください。
- 覚えるべき数値・基準値は、必ず表にしてください。
- 私が理解できていない可能性がある前提知識があれば、先に指摘してください。

システムエンジニアでの活かし方

あなたは本案件の設計・実装を支援するエンジニアです。

- 資料に書かれていない仕様は推測せず、「仕様確認事項」として別枠に出してください。
- コードを出す場合は、前提となるバージョンと動作確認していない旨を明記してください。
- 影響範囲が広い変更は、必ず「影響範囲」の節を付けてください。
- 出力はMarkdown。手順は番号付きリストで書いてください。

そのまま使えるプロンプト

貼り紙そのものをAIに作らせるプロンプトです。

このフォルダーで私が行う作業は次のとおりです。
【作業内容】（ここに書く）
【受講者・読み手】（ここに書く）
【絶対に避けたいこと】（ここに書く）

この作業のために、Project instructions（このフォルダー内で毎回守ってほしいルール）を
書いてください。条件は次のとおりです。

- 400字以内
- 「立場」「出力の形」「禁止事項」「分からない時の動き」の4つを必ず含める
- 曖昧な表現を使わず、判定できる書き方にする

組み合わせるとよいフレームワーク

Grill me — 貼り紙の穴を突かせる。

Grill me. このProject instructionsについて、弱い点、抜け穴、
指示が曖昧で解釈が分かれる点を厳しめに指摘してください。
最後に改善優先度を付けてください。

Misread test — 指示文そのものが誤読されないか。

Misread test. このProject instructionsについて、読み手（AI）が誤解しそうな表現を探してください。
該当箇所、誤解される可能性、修正案を出してください。

失敗しやすい使い方

• 長すぎる貼り紙。 2000字書いても守られません。400字を目安に。
• 抽象的な指示。 「丁寧に」「分かりやすく」は判定できません。「1文60字以内」「見出しを付ける」と書く。
• 矛盾する指示。 「簡潔に」と「詳細に」を両方書くと、どちらも守られません。
• 貼り紙に個人情報を書く。 貼り紙は全会話に効くので、書いた情報も全会話に流れます。項目28を参照。
• 貼り紙を書いたきり見直さない。 使ってみて効いていないルールは削る。

最後の確認

• 貼り紙を書いた後、新しい会話を1本開いて、ルールが効いているか実際に確かめる。
• 「今のあなたが守っているルールを箇条書きにして」と聞いて、意図どおり読まれているか確認する。
• 守られていないルールがあれば、抽象的すぎないかを疑う。

到達目標

• Project instructionsを「貼り紙」と説明できる。
• 4項目（立場・出力の形・禁止事項・分からない時の動き）を400字以内で書ける。
• 貼り紙ありとなしで出力が変わることを、自分の目で確認している。

セッション分け

この項目で教えたいこと

1つのフォルダーの中でも、会話は分ける。

具体的には、調査、作成、チェックの3つに分ける。 これがこの研修の中で、たぶん一番地味で、一番効く教えです。

講師の考え方を反映した説明

「フォルダーは分けましたね。でも、その中で1本の会話に全部やらせると、また混ざります。

調べている途中の情報、書いている途中の文章、直した指摘。 これが1本に入っていると、AIは『さっき自分が書いた文章』を正しいものとして扱い始めます。 自分の答案を自分で採点している状態です。

だから分けます。調査、作成、チェックの3つに分ける。 チェックの会話には、完成した成果物だけを渡します。 どうやって作ったかは教えません。 そのほうが厳しく見てくれます。」

3本の会話の役割はこう固定します。

普通のチャットだけの場合との違い

チャットしか使っていない人は、1本の会話に全部を積み上げます。長くなるほど、AIは自分の過去の発言に引っ張られ、間違いが固定されます。

セッションを分けると、チェックの会話は「初めてこの文書を読む人」の目線になります。これは人間のレビューでも同じ理屈です。書いた人にレビューさせない。

研修での実演

1. 1本の会話で、調査 → 作成 → 「この文章の問題点を指摘して」まで通しでやる。指摘が甘いことを見せる（たいてい「よく書けています」から始まります）。
2. 新しい会話を開き、成果物のテキストだけを貼って、同じく「問題点を指摘して」と聞く。
3. 2つの指摘を並べる。指摘の数と厳しさが違うことを見せる。
4. 「これが、会話を分ける理由です」と締める。

この対比は必ずやってください。 口で説明しても信じてもらえません。

サンプル問題

自分のフォルダーの中に、次の3本の会話を作ってください。

• 01_調査_（テーマ）
• 02_作成_（成果物名）
• 03_チェック_（成果物名）

そして、01で調べたことを自分で要約して02に渡し、02で作ったものを成果物だけ03に渡してください。 03の指摘が、1本で通してやった場合よりも厳しいかを確認してください。

社労士での活かし方

• 01_調査_Aさん_認定基準確認：診断書の内容と認定基準の突き合わせ、要確認事項の洗い出し
• 02_作成_Aさん_申立書ドラフト：調査の結論をもとに病歴就労状況等申立書の下書き
• 03_チェック_Aさん_申立書：完成した申立書だけを渡して、記載漏れ・矛盾・時系列のズレを指摘させる

03には診断書を渡さないのがポイントです。診断書を渡すと「診断書に書いてあるから正しい」と判断してしまい、申立書単体としての読みやすさや矛盾を見てくれません。

医学部生での活かし方

• 01_調査_循環器_心不全の分類整理
• 02_作成_循環器_まとめノート
• 03_チェック_循環器_まとめノート

03では「このノートだけを読んだ学生が、試験で間違える箇所はどこか」と聞きます。作成の経緯を知らない目で見てもらうから意味があります。

システムエンジニアでの活かし方

• 01_調査_◯◯機能_既存仕様の理解
• 02_作成_◯◯機能_設計メモ／タスク一覧
• 03_チェック_◯◯機能_レビュー

03には設計メモだけを渡し、「この設計書だけを読んだ実装担当が詰まる箇所」を挙げさせます。これはそのまま実際のレビュー観点になります。

そのまま使えるプロンプト

02（作成）の冒頭で使う

これから成果物を作ります。
以下は、別の会話で調査した結果の要約です。この内容だけを前提にしてください。
書かれていない事実は推測せず、「要確認」として別枠に出してください。

【調査結果の要約】
（ここに貼る）

【作ってほしい成果物】
（ここに書く）

03（チェック）の冒頭で使う

以下の成果物をレビューしてください。
この成果物がどうやって作られたかは知らない前提で、初めて読む人として見てください。

観点：
1. 事実の矛盾・時系列のズレ
2. 根拠が示されていない断定
3. 読み手が誤解しそうな表現
4. 抜けている必須情報

指摘は「該当箇所 / 問題 / 修正案 / 優先度（高中低）」の表で出してください。

【成果物】
（ここに貼る）

組み合わせるとよいフレームワーク

Make it actionable — 03の指摘を、直す作業に変える。

Make it actionable. この指摘一覧を、明日すぐ実行できる修正手順、
準備物、チェックリストにしてください。

What am I missing? — 01（調査）の締めで使う。

What am I missing? この調査結果で見落としている情報、確認事項、リスク、
準備物を挙げてください。

失敗しやすい使い方

• 1本で全部やる。 これが元の状態です。楽ですが、チェックが機能しません。
• チェックの会話に作成の経緯を貼る。 甘くなります。成果物だけを渡す。
• 会話に名前を付けない。 3日後にどれがどれか分からなくなります。番号付きの命名を徹底する。
• 調査の結論を整理せずに丸ごとコピーして作成に渡す。 要約する過程で、人間が理解します。ここを飛ばすと丸投げになります。

最後の確認

• 03の指摘のうち、自分が納得できないものが1つ以上あるか確認する。全部納得なら、チェックが甘い可能性があります。
• 指摘を反映したあと、もう一度新しい会話で最終チェックをかける。
• 最後は人間が読む。指摘を反映しただけで出さない。

到達目標

• 「調査、作成、チェックの3つに分ける」を即答できる。
• 3本の会話を実際に立てて、成果物を1本通せる。
• 分けた場合とそうでない場合で、指摘の厳しさが違うことを体験している。

ファイル一覧抽出

この項目で教えたいこと

手元のファイルを、一覧の表にする。

地味です。でも、この研修で一番「明日やります」と言われる実演です。フォルダーの中身が分からない、という悩みは3人全員が持っています。

同時にこれは、「ChatGPTは文章を書くだけの機械ではない」と分からせる最初の一撃でもあります。出てくるのが文章ではなく、Excelです。

講師の考え方を反映した説明

「フォルダーの中に、ファイルが47個あります。何が入っているか、分かりますか。

今から、これを一覧表にします。ファイル名だけじゃなくて、中身の1行説明つきで。 そしてExcelで出します。

これ、人がやったら半日です。」

そして、出てきたExcelをその場で開いて見せます。ダウンロードして開くところまで見せる。 「ダウンロードできます」と言うだけでは伝わりません。

普通のチャットだけの場合との違い

チャットでは、ファイル名を手で打ち込んで、1つずつ説明を書いていました。あるいは諦めていました。

Workでは、ファイルを渡せば中身を読んで表にします。しかも、Excelファイルとして出てきます。 画面の文字ではなく、保存できるファイルとして。

研修での実演

1. 10個程度のファイル（PDF、Word、Excel、画像を混ぜる）をProjectに入れる。
2. 「一覧表にして」と指示する（プロンプトは下記）。
3. まず画面上に表が出る。ここで一度止める。
4. 「これをExcelにして」と追加で言う。
5. 出てきたxlsxをダウンロードして、その場で開く。 列が揃っていること、日本語が化けていないことを見せる。
6. 「じゃあこれに『対応要否』の列を足して」と言って、その場で作り直させる。やり直しが一瞬であることを見せるのが6の目的です。

サンプル問題

自分の手元から10個前後のファイルを選んでProjectに入れ、次の列を持つ一覧表をExcelで作ってください。

No / ファイル名 / 種類 / 内容の1行説明 / 日付らしきもの / 自分がやるべきこと

作ったあと、「自分がやるべきこと」の列だけを見て、今週やることを3つ決めてください。

社労士での活かし方

顧客から届いた書類の束を一覧にします。診断書、受診状況等証明書、年金手帳の写し、住民票、戸籍……。

列はこうします。

No / 書類名 / 発行元 / 日付 / 有効期限の有無 / 不足・要再取得 / 提出先

「不足・要再取得」の列があるだけで、これは受付チェックシートになります。 一覧を作ることが目的ではなく、抜けを見つけることが目的だと伝えてください。

医学部生での活かし方

講義資料の山を一覧にします。

No / ファイル名 / 科目 / 講義回 / 主なテーマ / 過去問との関連 / 未読・既読

さらに、「試験範囲はここからここまで」と伝えると、範囲内のファイルだけに絞った一覧が作れます。試験2週間前にこれをやると、何を読んでいないかが一瞬で分かります。

システムエンジニアでの活かし方

受領資料の一覧化。

No / ファイル名 / 種類（要件/設計/画面/DB/運用） / バージョン / 最終更新日 / 対応する機能 / レビュー要否

これはそのまま受領資料台帳になります。「もらった資料がこれで全部か」を先方に確認する時の添付資料にもなります。

そのまま使えるプロンプト

このフォルダーに入っているファイルを全部確認して、一覧表を作ってください。

列は次のとおりです。
No / ファイル名 / 種類 / 内容の1行説明（40字以内） / 日付らしき情報 / 私がやるべきこと

条件：
- 中身が読めなかったファイルは「読取不可」と明記してください
- 推測で内容を書かず、読めた範囲だけで書いてください
- まず画面に表で出してください

そのうえで、この表をExcelファイルにして出力してください。
1行目は見出し行、列幅は内容に合わせて調整してください。

組み合わせるとよいフレームワーク

Sanity check — 一覧に変なところがないか。

Sanity check. この一覧表に、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。
特に、日付の並び、種類の分類、同じ資料の重複を見てください。

Edge cases — 分類しきれないファイルを炙り出す。

Edge cases. この分類ルールがうまく当てはまらないファイルを挙げ、
それぞれどう扱うべきかも出してください。

失敗しやすい使い方

• ファイル数が多すぎて途中で切れているのに気づかない。 「全部で何件ありましたか」と必ず聞き返す。
• 読めなかったファイルを黙って飛ばされる。 プロンプトに「読取不可と明記」を必ず入れる。
• 中身を推測で書かれる。 画像だけのPDFなどで起きます。「読めた範囲だけ」と明示する。
• 顧客名・患者名をそのまま列に出す。 項目28のルールを先に決めておく。
• 出てきたExcelを開かずに信用する。 必ず開いて、行数を数える。

最後の確認

• 行数を数える。 入れたファイル数と一致するか。ここが一番よくズレます。
• 読取不可のファイルが何件あるかを確認し、それらは自分で開く。
• 1行だけ選んで、実際のファイルを開いて説明が合っているか突き合わせる。

到達目標

• 自分のファイル群を一覧のExcelにできる。
• 「読取不可」の扱いを指示できる。
• 出てきた一覧の行数を、自分で検算する習慣がある。

PDF・Word資料の読解

この項目で教えたいこと

ここで一発かます。 この項目は研修の一番最初にやります。

教えたいのは機能ではなく、「自分では読む気にならなかった資料が、10分で使える形になる」という体感です。理屈は後でいい。まず殴る。

講師の考え方を反映した説明

説明の前に、実演から入ります。セリフはこれです。

「今から、皆さんが一番読みたくない資料を読ませます。 何も設定しません。ただ投げ込むだけです。」

そして、3ページくらいの要約資料にさせます。1ページでは薄すぎて「まあ要約だよね」で終わります。3ページあると「資料として使える」に変わります。ここが分かれ目です。

出てきたら、こう聞きます。

「これ、自分で読んで書いたら何時間かかりますか？」

答えを言わせてから、次に進みます。

普通のチャットだけの場合との違い

チャットにPDFを貼っても要約はできます。違いは3つあります。

1. 資料が残る。 明日また別の角度で聞ける。
2. 貼り紙（Project instructions）が効く。 「出典を必ず書く」「推測しない」が毎回守られる。
3. 複数の資料をまたげる。 「この3つの資料で言っていることが食い違う箇所は？」が聞ける。

3番目は、チャットではまず無理です。実演で見せてください。

研修での実演

1. 受講者に「一番読みたくない資料」を出させる（事前に用意させておく）。
2. Projectに入れて、説明ゼロで「3ページ分の要約資料にして」と打つ。
3. 出力を読み上げる。沈黙を作る。
4. 追加で「この資料で、読み手が誤解しやすい箇所は？」と聞く。
5. さらに「この資料に書かれていないが、実務で必要になる情報は？」と聞く。
6. ここで初めて「今のがWorkです」と言って、項目01に接続する。

4と5が本命です。 要約だけなら他でもできます。「書かれていないことを聞ける」ことが驚きです。

サンプル問題

自分の一番重い資料を1つ選び、次の3段階でやってください。

1. 3ページ分の要約資料を作らせる
2. 「この資料の中で、読み手が誤解しやすい箇所」を挙げさせる
3. 「この資料に書かれていないが、実務／学習で必要になる情報」を挙げさせる

3で出てきたものを見て、自分が次に調べるべきことを1つ決めてください。

社労士での活かし方

障害年金の認定基準、通達、疑義照会の回答集。分量が多く、条文の言い回しが硬い資料が対象です。

要約させたうえで、必ずこう聞きます。

「この基準を、実際の請求で判断が分かれそうな箇所はどこですか」

さらに、診断書のPDFを読ませて「記載が不足している欄」「日付の整合が取れていない箇所」を挙げさせるのが実務直結の使い方です。ただし等級の判断そのものは絶対にAIにさせない（貼り紙で禁止する。項目05参照）。

医学部生での活かし方

英語論文、診療ガイドライン、分厚い講義スライド。

要約に加えて、次の2つが効きます。

• 「この内容から、試験で問われる形式の問題を10問作って、解説も付けて」
• 「この論文の限界（limitations）と、それが結論にどう影響するかを説明して」

2つ目は、レポートや抄読会でそのまま使えます。ただし臨床判断の根拠として使わない、必ず一次資料に当たる、を最初に釘刺ししてください（項目18）。

システムエンジニアでの活かし方

100ページの要件定義書、他社が書いた設計書、古い運用手順書。

• 「この仕様書を、実装担当が最初に読むべき順序で3ページに要約して」
• 「この仕様書で、仕様が曖昧なまま書かれている箇所を全部挙げて」
• 「この仕様書と、こちらの設計書で矛盾している箇所は？」

2つ目と3つ目が本命です。曖昧箇所の抽出は、そのまま質問票になります。

そのまま使えるプロンプト

添付した資料を読んで、A4で3ページ相当の要約資料を作ってください。

構成：
1. この資料は何か（3行）
2. 全体像（見出し単位の構造）
3. 重要ポイント（10個以内、それぞれ2〜3行）
4. 数値・期限・条件など、間違えると困る情報の一覧（表）
5. この資料だけでは判断できないこと・要確認事項

条件：
- 資料に書かれていないことは書かないでください
- 推測が混じる場合は「※推測」と明記してください
- 元資料のページ番号や見出しが分かる場合は併記してください

組み合わせるとよいフレームワーク

Grill me — できた要約資料を叩く。

Grill me. この要約資料について、弱い点、反論されそうな点、説明不足、
確認不足を厳しめに指摘してください。最後に改善優先度を付けてください。

Misread test — 要約が原文と違う意味に読めないか。

Misread test. この要約について、読み手が誤解しそうな表現を探してください。
該当箇所、誤解される可能性、修正案を出してください。
特に、原文より断定的になっている箇所を優先して指摘してください。

Fill the gaps — 資料だけでは足りない情報を炙り出す。

Fill the gaps. この要約資料を実務で使える形に完成させるために足りない情報を
1問ずつ質問してください。各質問に、なぜ必要か、推奨回答例も付けてください。
最大5問でお願いします。

失敗しやすい使い方

• 要約を原文の代わりにする。 これが最大の事故です。要約は地図であって、現地ではありません。
• 「※推測」の指示を入れずに使う。 推測が事実の顔をして混ざります。
• スキャンPDF（画像のみ）を渡して、読めていないことに気づかない。 「この資料の何ページ目まで読めましたか」と必ず確認する。
• 長い資料を1回で全部やらせようとする。 章ごとに分けたほうが精度が上がります。
• 顧客の診断書・患者情報をそのまま投入する。 項目28を先に。

最後の確認

• 数字を3つ選んで、原文と突き合わせる。 日付、金額、期限が最も間違えやすい。
• 「この要約で、原文にない表現を使った箇所はどこですか」と聞いて、自己申告させる。
• 判断・等級・診断・仕様確定に関わる部分は、必ず原文と人間の目で確認する。

到達目標

• 重い資料を3ページの要約資料にできる。
• 「書かれていないこと」を聞き出せる。
• 要約を原文の代わりにしてはいけない、と言える。

Excel・CSV分析 / Data Analysis

この項目で教えたいこと

表を渡して、集計させる。 しかも、関数を書かずに。

そして教えたい実感は「AIが計算してくれる」ではなく、「条件を日本語で言えば集計できる」です。Excelの関数を覚えていない人ほど効きます。

講師の指定どおり、サンプル問題は2つの条件に当てはまるものの合計を必ずやらせます。SUMIFSを知らない人でも一発で出せる、という体験が刺さります。

講師の考え方を反映した説明

「Excelで『東京都の、4月の、金額の合計』を出そうと思ったら、何を書きますか。 SUMIFS？ ピボット？ フィルタして手で足す？

ここでは、こう書きます。 『都道府県が東京都で、月が4月の行の、金額の合計を出して』

これだけです。しかも、計算した後のExcelファイルが出てきます。」

そして必ず付け加えます。

「ただし、合計が合っているかは自分で確かめてください。 1件だけフィルタして、目で足す。それだけで十分です。」

「AIに計算させて、人間が検算する」 — この形を最初に教えます。

普通のチャットだけの場合との違い

チャットに表を貼ると、AIは文章として読んで、頭の中で足そうとします。行数が増えると間違えます。

Data Analysis（コードを書いて計算する機能）が動く環境では、実際にプログラムで計算します。行数が多いほど差が出ます。 実演では、あえて1000行以上のCSVを使ってください。

研修での実演

1. 1000行以上のCSVをProjectに入れる（列：日付、都道府県、担当者、区分、金額）。
2. まず「この表の列と行数、各列の型を教えて」と聞く。中身の確認から入るのを見せる。
3. 「都道府県が東京都で、区分がAの行の金額合計を出して」と聞く。
4. その場でExcelを開いてフィルタし、手で検算する。 ここが実演の山場です。
5. 「じゃあ都道府県別・区分別のクロス集計表を作って、Excelで出して」と言う。
6. 出てきたExcelを開く。

4を飛ばさないでください。 検算を見せることが、この項目の教育目的の半分です。

サンプル問題

自分の手元にある表（なければ配布したサンプル）を使って、次を出してください。

1. 行数と列の一覧
2. 2つの条件に当てはまる行の、金額の合計 （例：「区分がAで、かつ日付が4月の行の合計」）
3. その集計結果を、Excelファイルで出力

そして最後に、2の答えをExcelのフィルタで自分で検算してください。 合っていましたか？合っていなかったら、何が原因でしたか？

社労士での活かし方

• 顧問先の給与データから「等級がBで、かつ入社1年未満の従業員」の人数と支給合計
• 障害年金の相談記録から「請求種別が事後重症で、かつ精神の傷病」の件数を月別に集計
• 保険料の月次データで、前月比が一定以上動いた行だけ抽出

列名を日本語のまま渡せるのが実務では大きいです。ただし、氏名・基礎年金番号などは項目28に従って必ずマスキングしてから入れます。

医学部生での活かし方

• 過去問の正誤記録から「循環器で、かつ2回以上間違えた問題」を抽出
• 実習の症例記録から診療科別・疾患別の件数を集計
• 論文の付表データを読ませて、群間の差を表にまとめさせる

自己採点データを「分野 × 正答率」のクロス集計にすると、弱点が一目で出ます。 これは受講者本人が一番驚くやつです。

システムエンジニアでの活かし方

• 障害チケットのCSVから「重要度が高で、かつ未解決」の件数を担当者別に集計
• アクセスログから、ステータスコードが5xxで、かつ特定時間帯のリクエスト数
• テスト結果一覧から、失敗ケースを機能別に集計してExcelで出す

ログ解析をワンライナーで書く前に、まずここで見当を付ける、という使い方が現実的です。

そのまま使えるプロンプト

添付した表を分析してください。

【ステップ1】まず、次を確認して報告してください。
- 行数、列名の一覧、各列のデータ型
- 空欄・異常値がある列
- 日付の書式が揃っていない箇所

【ステップ2】次の集計を行ってください。
条件1：（例）区分 が A
条件2：（例）日付 が 2026年4月
求めるもの：金額 の合計

【ステップ3】結果を次の形で出してください。
- 該当行数
- 合計値
- 計算に使った条件（私が検算できるように明記）

【ステップ4】上記をExcelファイルで出力してください。
（1シート目：集計結果、2シート目：該当した行の一覧）

ステップ1を必ず入れてください。 いきなり集計させると、空欄や表記ゆれを黙って無視されます。

組み合わせるとよいフレームワーク

Sanity check — 集計結果が常識的にあり得るか。

Sanity check. この集計結果に、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。
特に、合計と内訳の一致、件数の妥当性、単位の扱いを見てください。

Edge cases — データ側の例外を洗う。

Edge cases. この集計方法がうまく当てはまらないデータの例外ケース
（空欄、表記ゆれ、重複行、単位違い、日付の書式違いなど）を挙げ、
それぞれの対処方法も出してください。

Smoke test — 出したExcelが使える状態か。

このExcelファイルをスモークテストしてください。細かい改善ではなく、
最低限使えるかを確認してください。必須情報の抜け、矛盾、日付・金額の不整合、
読み手が次に何をすればよいか、人間が確認すべき点を確認してください。

失敗しやすい使い方

• 検算しない。 これが一番の事故。必ず1件は手で確かめる。
• 表記ゆれを無視する。 「東京都」と「東京」が別物として集計されます。ステップ1で必ず確認。
• 合計だけ見て件数を見ない。 該当行数を必ず出させる。件数がおかしければ条件が間違っています。
• 単位を確認しない。 千円単位と円単位が混ざった表は普通にあります。
• 個人情報つきの生データをそのまま入れる。 氏名列は削るかID化する（項目28）。

最後の確認

• 該当行数と合計をセットで確認する。 片方だけでは検算になりません。
• Excelのフィルタで1条件だけ掛けて、件数のオーダーが合っているか見る。
• 「この集計で無視したデータ（空欄・異常値）はありますか」と聞いて、自己申告させる。

到達目標

• 2条件の合計を、日本語の指示だけで出せる。
• 集計前にデータの状態を確認する手順が身についている。
• 出た数字を必ず自分で検算する。

画像・スクショ読解

この項目で教えたいこと

紙とスクショを、そのままデータにできる。

レシート、手書きメモ、画面キャプチャ、紙の書類の写真。今まで「打ち直すしかなかったもの」が、表になります。

講師の指定どおり、実演はレシート画像 → 家計簿風の表でやります。これは受講者3人とも自分の生活で試せるので、研修後の定着率が全然違います。

講師の考え方を反映した説明

「レシート、財布に溜まってますよね。 これ、写真を撮って投げるだけで、日付・店名・品目・金額の表になります。

家計簿の話をしているんじゃありません。 紙を打ち直す作業が、全部これで置き換わるという話です。

診断書の写し、講義の板書、エラー画面のスクショ。全部同じです。」

そして必ず釘を刺します。

「ただし、読み間違えます。 特に手書きと、かすれた数字。 だから最後は人間が確認します。金額は特に。」

普通のチャットだけの場合との違い

チャットに画像を貼って「何が書いてある？」と聞くのは、多くの人がやったことがあります。違いは、構造化して、ファイルにするところです。

「読める」で終わらせず、「表にする」「Excelにする」「次の作業に渡す」まで持っていく。これがWorkでの使い方です。

研修での実演

1. レシートを3〜5枚、その場で写真に撮って投げる（講師の財布から出すと空気が良くなります）。
2. 「日付／店名／品目／金額／カテゴリ の表にして」と指示。
3. 出てきた表を見て、1枚のレシートと突き合わせて金額を確認する。 ここで1つくらい間違いが見つかると最高の教材になります。
4. 「読み取りに自信がない箇所に印を付けて」と追加で言う。自信度を出させるのを見せる。
5. 「これをExcelにして、カテゴリ別合計も出して」と言う。
6. 次に、エラー画面のスクショや講義スライドの写真を投げて、同じことができると見せる。

4は必ず入れてください。 「AIは自分の不確かさを申告できる」と知っているかどうかで、使い方の安全性が変わります。

サンプル問題

手元のレシートを5枚、写真に撮って読ませてください。

1. 日付 / 店名 / 品目 / 金額 / カテゴリ の表にする
2. 読み取りに自信がない箇所に「※要確認」を付けさせる
3. カテゴリ別の合計を出す
4. Excelで出力する

そのうえで、「※要確認」が付いた箇所を自分の目で確かめてください。 何件、実際に間違っていましたか？

社労士での活かし方

• 顧客から送られてきた書類の写真を、受付一覧の表にする
• 手書きのヒアリングメモを写真に撮って、テキストに起こす
• 年金事務所からの通知書の写真から、日付・種別・期限を抽出して期限管理表にする

期限の抽出が特に効きます。ただし、診断書や個人情報が写った画像をそのまま入れてよいかは項目28で必ず先に決めてください。 氏名部分を隠して撮る運用にするのが現実的です。

医学部生での活かし方

• 板書・スライドの写真から、覚えるべき数値・分類を表にする
• 紙の過去問を撮って、選択肢ごとの解説を作らせる
• 検査値の一覧表の写真から、基準値の表を作る

さらに、図表（グラフ、シェーマ）の写真を読ませて「この図が示していることを3行で」と聞くのが、試験前に効きます。ただし患者情報が写った画像は絶対に入れない（項目28）。

システムエンジニアでの活かし方

• エラー画面のスクショから、エラーメッセージと状況を整理させる
• 画面設計の紙資料の写真から、項目一覧（項目名・型・必須／任意）の表を作る
• ホワイトボードの議論写真から、決定事項とTODOを抽出する

ホワイトボード → TODO一覧は、会議直後にやると効果絶大です。項目25（タスク分解）につながります。

そのまま使えるプロンプト

添付した画像を読み取って、表にしてください。

列：日付 / 店名（発行元） / 品目・内容 / 金額 / カテゴリ / 読み取り信頼度

条件：
- 読み取れなかった箇所は空欄にし、推測で埋めないでください
- 数字がかすれている、手書きで判読が難しいなど、自信がない箇所は
  信頼度の列に「低（要確認）」と書いてください
- 画像1枚につき何行になったかを最後に報告してください

そのうえで、カテゴリ別の合計を出し、全体をExcelファイルにしてください。

組み合わせるとよいフレームワーク

Sanity check — 読み取り結果の常識的なおかしさを見る。

Sanity check. この読み取り結果に、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。
特に、日付の妥当性、金額の桁、合計と明細の一致を見てください。

Edge cases — 読めないパターンを先に知る。

Edge cases. この画像読み取りの手順がうまく当てはまらないケース
（手書き、感熱紙のかすれ、斜め撮影、複数レシートの重なり、外国語など）を挙げ、
それぞれの対処方法も出してください。

失敗しやすい使い方

• 金額を検算しない。 桁の読み間違いは普通に起きます。合計だけでも必ず確認。
• 「推測で埋めるな」を指示しない。 読めない文字を、それらしい文字で埋められます。
• 斜め・暗い・影ありの写真を渡す。 撮り直したほうが速いです。研修で「撮り方」も一度見せてください。
• 個人情報が写ったまま投入する。 診断書、患者名、社員名簿。項目28を先に。
• 画像1枚に情報を詰め込みすぎる。 レシート10枚を1枚の写真にすると精度が落ちます。

最後の確認

• 合計金額を電卓で1回確認する。 これだけで大半の事故が防げます。
• 「信頼度：低」が付いた行を全部、元画像で確認する。
• 行数を数える。レシート5枚なのに3枚分しかない、はよくあります。

到達目標

• レシート・スクショを構造化した表にできる。
• 「推測で埋めない」「自信のない箇所を申告させる」を指示できる。
• 金額・日付を人間が検算する習慣がある。

複数回答の比較

この項目で教えたいこと

ChatGPT、Claude、Geminiに同じ質問をして、回答を比較し、いいとこ取りして最高の資料を作る。

この項目のゴールは、受講者の頭を「AIは答えを出す機械」から「AIは案を出す機械で、選ぶのは自分」に切り替えることです。研修全体でいちばん認識が変わる項目かもしれません。

講師の考え方を反映した説明

「同じ質問を、3つのAIに投げます。 答えが違います。当たり前です。

大事なのはここからです。 どれが正しいかを選ぶんじゃありません。いいとこ取りをするんです。

Aの構成が良い。Bの具体例が良い。Cが指摘したリスクは他の2つが落としている。 これを1つにまとめて、3つのどれよりも良い資料を作る。 これが人間の仕事です。」

そして、もう1つ重要なことを言います。

「答えが割れた箇所は、要注意ポイントです。 AIが3つとも同じことを言うところは、たぶん安全。 割れたところは、人間が確認すべきところです。」

「割れた箇所＝要確認箇所」 — これがこの項目で一番持って帰ってほしい考え方です。

普通のチャットだけの場合との違い

チャットしか使っていない人は、最初に出てきた答えをそのまま使います。それが唯一の答えに見えるからです。

3つ並べると、「これは1つの案でしかない」ということが視覚的に分かります。理屈で説明するより、並べて見せるほうが100倍速いです。

研修での実演

1. 同じ質問を3つのAIに投げる。画面を3つ並べる（またはスクショを3枚並べる）。
2. 出力を3つとも1つの会話に貼り込み、比較表を作らせる。
3. 「3つとも一致している点」「割れている点」を分けさせる。ここで止めて、割れている点を指差す。
4. 「割れた箇所は、どちらが正しいか調べてください」と言って、Web検索（項目16）と公式確認（項目18）につなぐ。
5. 最後に「3つを統合した決定版」を作らせる。
6. できた決定版に Grill me をかける。 統合しただけで満足させない。

サンプル問題

自分の仕事・勉強に関する質問を1つ決めて、ChatGPT・Claude・Geminiの3つに同じ文面で投げてください。

1. 3つの回答を1つの会話に貼り、比較表を作らせる
2. 「一致点」と「相違点」を分けさせる
3. 相違点について、自分でどれが正しいか調べる
4. 調べた結果を踏まえて、統合版を作らせる

最後に：3つのうち1つだけ使っていたら、どんな見落としがありましたか？

社労士での活かし方

制度の解釈、書類の書き方、実務上の運用について3つに聞きます。

注意：制度の内容そのものは、AI3つが一致していても正しいとは限りません。 3つとも同じ古い情報を持っている可能性があります。ここは必ず日本年金機構・厚生労働省の一次情報で確認します（項目18）。

比較が本当に効くのは、文章表現です。病歴就労状況等申立書の書き方を3つに書かせて、「日常生活の困難さが最も具体的に伝わる表現」を選んで組み合わせる。これは強力です。

医学部生での活かし方

• 「この疾患の鑑別診断の考え方を教えて」を3つに聞き、挙がった鑑別疾患を集合として統合する
• 「この概念の説明」を3つに聞き、一番自分に分かりやすかった説明を採用する

鑑別疾患は「和集合」で取るのがコツです。1つだけだと落ちます。ただし、臨床的判断は必ず教科書・ガイドラインで裏取り（項目18）。

システムエンジニアでの活かし方

• 設計方針を3つに聞いて、それぞれのトレードオフを表にする
• 同じコードを3つにレビューさせて、指摘の和集合を取る
• 障害の原因候補を3つに挙げさせて、共通して挙がったものから調べる

レビュー指摘は和集合、原因候補は積集合から。 この使い分けが実務的です。

そのまま使えるプロンプト

同じ質問を3つのAIに投げた結果を貼ります。
次の順で分析してください。

1. 比較表（観点 / A / B / C）を作る
2. 3つとも一致している内容を挙げる
3. 割れている内容を挙げ、それぞれ「なぜ割れたと考えられるか」を書く
4. 割れている内容のうち、私が自分で確認すべきものを優先度付きで挙げる
5. 3つのいいところを取って統合した決定版を作る
   （どの部分をどのAIから採ったか分かるように注記してください）

【A の回答】
（貼る）
【B の回答】
（貼る）
【C の回答】
（貼る）

組み合わせるとよいフレームワーク

Grill me — 統合した決定版を叩く。統合物は「良いとこ取りしたから完璧」と錯覚しがちです。

Grill me. この統合版について、弱い点、反論されそうな点、説明不足、
確認不足を厳しめに指摘してください。
特に、3つの回答をつなぎ合わせたことで生じた論理の飛躍を見てください。
最後に改善優先度を付けてください。

What am I missing? — 3つとも落としている論点を探す。

What am I missing? 3つのAIの回答すべてに共通して欠けている論点、
確認事項、リスク、準備物を挙げてください。

失敗しやすい使い方

• 多数決で決める。 3つのうち2つが同じでも、その2つが同じ誤りを持っている可能性があります。
• 一致した箇所を無条件に信じる。 特に制度・法令・医学情報は、一致していても古い可能性があります。
• 統合版に Grill me をかけない。 つなぎ目に論理の飛躍が入ります。
• 質問文を微妙に変えて投げる。 比較にならなくなります。完全に同じ文面で投げること。
• 顧客情報・患者情報を3社のAIに配る。 情報が3か所に散ります。項目28の観点で最も危険な使い方です。

最後の確認

• 割れた箇所が何件あって、そのうち何件を自分で確認したかを数える。
• 統合版の中で「どのAIから採ったか分からない部分」がないか確認する。
• 制度・医学・仕様に関わる部分は、AIの一致ではなく一次情報で確認する。

到達目標

• 同じ質問を複数のAIに投げて比較表を作れる。
• 「割れた箇所＝人間が確認すべき箇所」と言える。
• 統合版に必ず Grill me をかける習慣がある。

変更前後比較

この項目で教えたいこと

変更前と変更後の資料を並べて、何が変わったかを出させる。

ただし、教えたいのは「差分が出る」ことではありません。「意味が変わったところ」と「細かい変更」を分けさせることです。

差分ツールは文字の違いしか見ません。AIは、「この変更で意味が変わったか」を判定できます。ここが決定的な違いです。

講師の考え方を反映した説明

「就業規則の改定前と改定後。仕様書のv1とv2。ガイドラインの2020年版と2025年版。 全部、『どこが変わったか』を人が目で追ってますよね。

ここでは、こう出させます。

1. 意味が変わったところ 2. 細かい変更（表現・体裁だけ） 3. 注意点（変更の影響が他に及ぶところ）

この3つに分けるのが肝です。 文字が10か所変わっていても、意味が変わったのは1か所、ということがよくあります。 逆に、1文字しか変わっていないのに意味が反転していることもあります。『できる』が『できない』になっている、とか。」

普通のチャットだけの場合との違い

チャットで「違いを教えて」と聞くと、羅列が返ってきます。100個の差分が並んで、結局全部読むことになります。

分類させることで、読むべき箇所が3個に絞られます。これが違いです。指示の書き方一つで、使えるかどうかが変わる、という良い例でもあります。

研修での実演

1. 変更前・変更後の2つの資料をProjectに入れる。
2. まず「違いを教えて」とだけ聞く。羅列が出てくるのを見せる。「これ、読みます？」と聞く。
3. 次に、3分類を指定したプロンプト（下記）で聞き直す。
4. 出てきた「意味が変わったところ」を、元資料で確認する。
5. わざと1か所、意味が反転する変更を仕込んでおく（「〜できる」→「〜できない」など）。それを検出できているか見せる。
6. 検出できなかった場合も、それはそれで教材になります。「だから最後は人間が確認する」。

サンプル問題

自分の手元にある「改定前・改定後」の資料ペアを1組用意して、次を出させてください。

1. 意味が変わったところ（重要度付き）
2. 細かい変更（表現・体裁のみ）
3. 注意点（この変更が他の箇所・他の書類に影響するところ）

そのうえで、1の全件を元資料で自分で確認してください。 AIが「意味が変わった」と判定したもののうち、実際にはそうでなかったものはありましたか？

社労士での活かし方

• 就業規則の改定前・改定後の比較（意味が変わった条文の抽出）
• 認定基準・通達の改正前後の比較
• 顧客に送った書類の第1稿と第2稿の比較（顧客が勝手に直した箇所の検出）

3つ目が実務では地味に効きます。 「顧客が返してきた版で、どこを直したか」を出させると、見落としが防げます。

そして、「この変更が他の書類に影響する箇所」を出させるのが本命です。就業規則を変えたら賃金規程も直さないといけない、というやつです。

医学部生での活かし方

• ガイドラインの旧版・新版の比較（推奨度が変わった項目の抽出）
• 自分のまとめノートの改訂前後（何を書き足して、何を消したか）
• 教科書の版違いの比較

ガイドライン比較では、「推奨グレードが変わった項目」だけを抽出させます。試験でも臨床でも、変わったところが問われます。

システムエンジニアでの活かし方

• 仕様書v1とv2の比較（機能追加・削除・条件変更の分類）
• 設定ファイルの変更前後（意味のある変更 vs フォーマット整形）
• APIドキュメントのバージョン間比較（破壊的変更の抽出）

「破壊的変更かどうか」を判定させるのが最も価値の高い使い方です。差分ツールでは絶対に出せません。

そのまま使えるプロンプト

2つの資料（変更前・変更後）を比較してください。
単なる差分の羅列ではなく、次の3つに分類してください。

【1. 意味が変わったところ】
- 該当箇所（変更前 → 変更後）
- 何がどう変わったか
- 重要度（高／中／低）
- この変更で影響を受ける人・作業

【2. 細かい変更】
表現・体裁・語順など、意味が変わらない変更をまとめて件数と傾向だけ書いてください。

【3. 注意点】
- この変更が、他の箇所や他の資料と矛盾を生む可能性がある箇所
- 変更に伴って、あわせて直すべきもの

条件：
- 「〜できる」が「〜できない」になるような、1文字でも意味が反転する変更は
  必ず【1】に入れて、最優先で報告してください
- 判断に迷った変更は【1】に入れて「判断迷い」と付記してください

最後の2条件が重要です。 迷ったら重要側に倒す、という指示を必ず入れてください。

組み合わせるとよいフレームワーク

Misread test — 変更後の文が誤読されないか。

Misread test. 変更後の資料について、読み手が誤解しそうな表現を探してください。
該当箇所、誤解される可能性、修正案を出してください。
特に、変更したことで前後の文脈と食い違った箇所を優先してください。

Edge cases — 変更が当てはまらないケース。

Edge cases. 今回の変更内容がうまく当てはまらない例外ケース
（経過措置が必要なケース、既存の運用と衝突するケースなど）を挙げ、
それぞれの対処方法も出してください。

Sanity check — 変更全体の整合性。

Sanity check. 変更後の資料全体に、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。
特に、変更した箇所と変更していない箇所の間の矛盾を見てください。

失敗しやすい使い方

• 「違いを教えて」とだけ聞く。 羅列が出て、結局読みません。必ず3分類を指定する。
• 長い資料を丸ごと2つ投げる。 章ごとに分けたほうが精度が上がります。
• 「意味が変わった」の判定を鵜呑みにする。 見落としも誤検出もあります。全件確認する。
• 変更前の資料が最新版だと思い込んでいる。 そもそもどちらが新しいか、日付で確認する。
• PDFのレイアウトが違うだけで「変更」と判定される。 元がPDFの場合はテキスト化してから比べるほうが安定します。

最後の確認

• 【1】に挙がった項目は全件、元資料で確認する。 ここは省略できません。
• 「意味が変わった箇所は全部で何件ですか」と数を聞き、自分の感覚と合っているか見る。
• 少なすぎると感じたら、章ごとに分けてもう一度やる。
• 最後は人間が読む。特に「〜できる／できない」「必ず／原則」「以上／未満」。

到達目標

• 変更前後を「意味・細かい・注意点」の3分類で出させられる。
• 意味の反転を最優先で出させる指示が書ける。
• 【1】は全件、人間が確認する習慣がある。

資料からチェックリスト化

この項目で教えたいこと

読んだ資料を、そのまま「使える形」に変える。

要約は読むためのもの。チェックリストは作業するためのものです。この違いを腹落ちさせます。

ポイントは、「判定できる書き方になっているか」です。「適切に記載されていること」はチェックできません。「日付が和暦で記載されていること」はチェックできます。

講師の考え方を反映した説明

「資料を要約しました。読みました。で、次に何をしますか。

要約は読むもの。チェックリストは使うものです。

ただ、AIに『チェックリストにして』と言うと、こういうのが出てきます。 『□ 内容が適切であること』 これ、チェックできますか。できませんよね。

だから、こう指示します。 『各項目は、はい／いいえで判定できる文にしてください』 これ1行を足すだけで、使えるチェックリストになります。」

普通のチャットだけの場合との違い

チャットで作ったチェックリストは、たいてい抽象的です。それは指示が抽象的だからです。

Workでは、元資料が手元にあるので、「資料のどこに書いてあるか」を各項目に付けさせられます。根拠付きのチェックリストは、他人に渡せます。これが大きな違いです。

研修での実演

1. 項目08で要約した資料を使う（同じ資料を使い回すのがコツ。新しい資料を出すと注意が散ります）。
2. まず「チェックリストにして」とだけ聞く。抽象的なリストが出るのを見せる。
3. 「はい／いいえで判定できる文にして、根拠のページも付けて」と指示し直す。
4. 2つを並べて見せる。
5. できたリストを、実際の1件に適用してみせる。 ここで「この項目は判定できない」が必ず1つ出ます。それを直す。
6. 最後に Edge cases をかけて、「このチェックリストが当てはまらないケース」を出させる。

5が実演の山場です。 作って終わりにせず、1回使って壊す。

サンプル問題

項目08で要約した資料をもとに、チェックリストを作ってください。

条件： - 各項目は「はい／いいえ」で判定できる文にする - 各項目に、元資料の根拠箇所を付ける - 「必須」「推奨」を分ける

そのうえで、実際の案件・レポート・成果物を1つ選んで、このチェックリストを最後まで通してください。 判定できなかった項目はいくつありましたか？それはなぜですか？

社労士での活かし方

障害年金の請求書類チェックリストが本命です。

□ 診断書の作成日が、請求日から3か月以内である（はい／いいえ）
□ 病歴就労状況等申立書の期間が、初診日から現在まで途切れなく記載されている
□ 診断書の初診日と、受診状況等証明書の初診日が一致している
□ 日常生活能力の判定欄に、すべて記入がある

「一致している」「途切れがない」のような、突き合わせ型の項目を必ず入れさせてください。ここが一番よく落ちるところです。

顧客対応でも使えます。「初回相談で必ず聞くことリスト」を、過去の相談記録から作らせる。

医学部生での活かし方

• レポート提出前チェックリスト（引用形式、図表番号、字数、参考文献の年）
• 実習前の持ち物・準備チェックリスト
• 試験範囲の理解度チェックリスト（「〜を説明できる」形式にする）

3つ目は、「〜を説明できる（はい／いいえ）」の形にするのがコツです。「〜を理解している」だと自己判定が甘くなります。

システムエンジニアでの活かし方

• 仕様書からテスト観点チェックリストを作る
• リリース前チェックリスト（設定値、バックアップ、切り戻し手順、連絡先）
• コードレビュー観点リスト（プロジェクトの規約資料から生成）

リリース前チェックリストは、必ず「切り戻し手順が書かれているか」を入れさせてください。 ここが抜けているリストが多いです。

そのまま使えるプロンプト

添付の資料をもとに、実務で使えるチェックリストを作ってください。

条件：
- 各項目は「はい／いいえ」で判定できる文にしてください
  （「適切であること」「十分であること」のような判定できない表現は禁止）
- 各項目に、元資料の根拠箇所（見出し・ページ）を付けてください
- 「必須」と「推奨」を分けてください
- 複数の資料をまたいで突き合わせる項目（例：AとBの日付が一致している）を
  必ず含めてください
- 全体を、上から順にやれば終わる順番に並べてください

出力形式：
| No | 区分（必須/推奨） | チェック内容 | 根拠 | 判定 |

組み合わせるとよいフレームワーク

Make it actionable — チェックリストそのものを動く形に。

Make it actionable. このチェックリストを、明日すぐ実行できる手順、
準備物、確認順序に整理してください。
各項目について「誰が」「何を見て」判定するかも明記してください。

What am I missing? — 抜けている観点。

What am I missing? このチェックリストで見落としている確認事項、リスク、
準備物を挙げてください。
特に、ミスが起きた時に影響が大きいのに項目化されていないものを優先してください。

Edge cases — 当てはまらないケース。

Edge cases. このチェックリストがうまく当てはまらない例外ケースを挙げ、
それぞれの対処方法も出してください。

失敗しやすい使い方

• 判定できない項目を放置する。 「適切に」「十分に」「必要に応じて」が出たら書き直させる。
• 項目が多すぎる。 50項目のリストは使われません。必須と推奨を分けるのはこのためです。
• 根拠を付けさせない。 後で「なぜこの項目があるのか」が分からなくなります。
• 一度も使わずに完成とする。 必ず1件通してから確定する。
• チェックリストを作ったことで安心する。 リストは網羅を保証しません。Edge casesをかける。

最後の確認

• 1件、実際に通す。 通せないリストはリストではありません。
• 判定できなかった項目を数え、書き直す。
• 「このリストで見逃す可能性が高いミスは何か」をAIに聞く。
• 重要な案件では、リストを通した後に人間の目でもう一度読む。

到達目標

• 「はい／いいえで判定できる文にする」という指示を必ず入れられる。
• 根拠付きのチェックリストを作れる。
• 作ったリストを1件通して直す習慣がある。

資料から手順書化

この項目で教えたいこと

「自分だけが分かっている作業」を、他人が再現できる形にする。

チェックリストが「確認するもの」なら、手順書は「やるもの」です。判定基準は1つ、「この手順書を初めて見た人が、これだけで完了できるか」。

講師の考え方を反映した説明

「自分の作業を手順書にしてください、と言われたら、みんな書けないんです。 頭では分かっているのに、書くと抜ける。

なぜかというと、自分が無意識にやっていることを書き忘れるからです。

だから、AIに書かせて、AIに突っ込ませます。 『初めてこの手順書を見た人が詰まる箇所はどこですか』 これを聞くと、自分が飛ばしていた前提が出てきます。」

そして、手順書に必ず入れる4つを教えます。

1. 前提（何が揃っていれば始められるか）
2. 手順（番号付き、1手順1動作）
3. 完了条件（何を見たら終わったと言えるか）
4. 失敗した時（詰まったらどうするか）

4を入れるのがポイントです。 ほとんどの手順書には失敗時の記載がありません。

普通のチャットだけの場合との違い

チャットでは「手順書を作って」と言うと、一般論の手順が出てきます。AIが知っている一般的なやり方です。

Workでは、自分の資料をもとに手順書を作らせます。自分の環境、自分の様式、自分の顧客に合った手順書になります。ここが決定的な違いです。

研修での実演

1. 受講者に「自分がいつもやっている作業」を1つ、口で説明させる（3分）。
2. その説明をそのままAIに渡して、手順書にさせる。
3. 出てきた手順書に対して「初めてこの手順書を見た人が詰まる箇所」を聞く。
4. 出てきた指摘を、本人に読ませる。「あ、それ言ってなかった」が必ず出ます。
5. 抜けを埋めて、手順書を作り直す。
6. Smoke test をかけて締める。

4の「あ、それ言ってなかった」を出させるのが、この実演の全部です。

サンプル問題

自分がいつもやっている作業を1つ選び、口で説明した内容をもとに手順書を作らせてください。

1. 前提・手順・完了条件・失敗した時の4部構成にする
2. 「初めて見た人が詰まる箇所」を挙げさせる
3. 抜けを埋めて作り直す

そのうえで、その手順書を他の受講者に渡して、読んでもらってください。 分からないと言われた箇所はどこでしたか？

社労士での活かし方

• 障害年金の初回相談から請求書類提出までの手順書
• 顧客から書類を受領してから不備を返送するまでの手順書
• 事務所の新人に渡す、電子申請の操作手順書

完了条件が特に重要です。 「提出した」ではなく「受付番号を控えて、顧客に受付日を連絡した」まで書く。ここまで書いて初めて他人に渡せます。

失敗時の記載例：「診断書の記載に不備があった場合 → 医療機関への照会文の雛形は◯◯を使い、顧客に事前連絡する」。

医学部生での活かし方

• 実習の手技・検査手順の自分用まとめ
• レポート作成の自分の型（調べる→構成→執筆→引用整理→提出）
• 症例発表の準備手順

臨床手技の手順書は、必ず「実際の指導医の指示・施設のマニュアルが優先」と明記させてください。 AIが作った手順書を臨床でそのまま使うのは危険です。学習用のまとめとして使う、という線引きを教えてください。

システムエンジニアでの活かし方

• 環境構築手順書
• リリース手順書（切り戻し手順を必ずセットで）
• 障害調査の初動手順書

リリース手順書では「失敗した時」が主役です。 「何分待って戻らなければ切り戻す」まで書く。ここまで書いてある手順書は、実は現場にあまりありません。

そのまま使えるプロンプト

以下の作業を、初めてこの作業をする人が一人で完了できる手順書にしてください。

構成：
1. 前提（開始前に揃っている必要があるもの：権限、資料、道具、情報）
2. 手順（番号付き。1手順1動作。各手順に「終わったと分かる目印」を書く）
3. 完了条件（何をもって完了とするか。連絡・記録まで含める）
4. 失敗した時（詰まりやすい箇所と、その時の対処。戻し方も書く）

条件：
- 「適宜」「必要に応じて」「適切に」は使わないでください
- 前提知識を必要とする語には、短い補足を付けてください
- 私の説明に含まれていない情報を推測で補わず、「要確認」として別枠に出してください

【作業の説明】
（ここに書く）

続けてこれを聞きます。

この手順書を初めて見た人が詰まる箇所を、詰まる理由とともに挙げてください。
私が無意識に省略している前提があれば、それも指摘してください。

組み合わせるとよいフレームワーク

Make it actionable — 説明を手順に落とす主力。

Make it actionable. この内容を、明日すぐ実行できる手順、準備物、
チェックリストにしてください。

Edge cases — 手順が通らないケース。

Edge cases. この手順がうまく当てはまらない例外ケースを挙げ、
それぞれの対処方法も出してください。

Misread test — 手順文の誤読。

Misread test. この手順書について、読み手が誤解しそうな表現を探してください。
該当箇所、誤解される可能性、修正案を出してください。
特に、順序・条件分岐・「〜してから」の関係が誤読される箇所を優先してください。

Smoke test — 手順書として最低限成立しているか。

この手順書をスモークテストしてください。細かい改善ではなく、
最低限使えるかを確認してください。必須情報の抜け、矛盾、実行順序、
読み手が次に何をすればよいか、人間が確認すべき点を確認してください。

失敗しやすい使い方

• 「適宜」「必要に応じて」を残す。 これが残っている手順書は他人が使えません。
• 完了条件を書かない。 「終わった」が人によって違う状態になります。
• 失敗時の記載がない。 詰まったら結局作った人に聞くことになり、手順書の意味がなくなります。
• 自分で1回もやらずに配る。 必ず自分で通してから渡す。
• AIが一般論で補った部分を、自分の環境の話だと思い込む。 「要確認」を出させる指示を必ず入れる。

最後の確認

• 自分で1回、手順書だけを見ながらやってみる。 メモを見ない。
• 他人に読ませて「どこが分からないか」を聞く。
• 「失敗した時」の項が空でないか確認する。
• 臨床・本番環境・法定手続きに関わる手順は、必ず正式なマニュアル・指導者の指示が優先と明記する。

到達目標

• 前提・手順・完了条件・失敗時の4部構成で手順書を作れる。
• 「初めて見た人が詰まる箇所」を聞き出せる。
• 自分で1回通してから他人に渡す習慣がある。

Apps / Connectors

この項目で教えたいこと

手元の道具とつなぐと、資料をアップロードする手間がなくなる。

ただし、この項目で本当に教えたいのは便利さではありません。「つなぐ＝そこの情報が読まれる」という事実です。だから、この項目は項目29（権限・承認）とセットで教えます。

講師の考え方を反映した説明

「これまでは、ファイルを手で入れていました。 つないでしまえば、入れなくても読めます。

便利です。便利ですが、ここで一回止まってください。

つなぐということは、そこにあるものが読まれるということです。 ドライブをつなぐなら、そのドライブに何が入っているか、思い出せますか。

だから、つなぐ範囲は最小にします。 全部つなぐんじゃなくて、必要なフォルダーだけ。」

そして、つなぐ前に必ず自問する3つを教えます。

1. そこに何が入っているか、全部言えるか
2. 入っているもののうち、見られて困るものはないか
3. 今回の作業に、本当にその接続が必要か

普通のチャットだけの場合との違い

チャットでは、必要なファイルを1つずつ手で貼っていました。手間ですが、何を渡したかが明確でした。

つなぐと、手間は消えますが、何が読まれたかが見えにくくなります。 便利さと引き換えに、把握が減る。これを正直に伝えてください。「便利です」だけで終わらせないこと。

研修での実演

1. 接続の設定画面を開いて、接続できる先の一覧を見せる（実際につなぐ前に）。
2. 1つ選んで、権限の確認画面を見せる。「何を許可しようとしているか」の文面を声に出して読む。
3. 実際につないで、そこにあるファイルを参照させてみる。
4. 「今、どのファイルを見ましたか」と聞いて、参照元を答えさせる。
5. 接続を解除するところまで見せる。 つなぎっぱなしにしない、という運用を見せることが重要です。
6. 「使い終わったら外す」を口に出して締める。

5を必ずやってください。 つなぐ実演だけして終わる研修が多いですが、外し方を知らないと外しません。

サンプル問題

接続機能の設定画面を開いて、次を確認してください（実際につながなくても構いません）。

1. 自分がつなげる先はどれか
2. それぞれ、どんな権限を求めているか
3. 自分がつないでよいものはどれか、つないではいけないものはどれか

つないではいけないものについては、なぜいけないかを1行で書いてください。

社労士での活かし方

つなげると便利なもの：事務所の業務用ストレージのうち、様式・雛形・参考資料が入っているフォルダーだけ。

つないではいけないもの：顧客の個人情報が入っているフォルダー、給与データ、マイナンバーを含む一切のもの。

現実的な運用は、「参照用フォルダーだけをつなぎ、顧客ファイルは都度手で入れる（かつマスキングする）」です。手間ですが、この手間が事故を防ぎます。

社労士は個人情報保護法上の義務を負う立場なので、事務所としてのルールを先に文書化してから接続してください。

医学部生での活かし方

つなげると便利なもの：自分の講義資料・ノートが入っている個人のクラウドストレージ。カレンダー（実習・試験の予定管理）。

つないではいけないもの：実習で扱った患者情報を含むもの一切。 大学から配布された、外部持ち出し禁止の資料。

大学のポリシーで生成AIへの資料投入が制限されている場合があります。接続する前に、必ず大学の規定を確認するよう伝えてください。

システムエンジニアでの活かし方

つなげると便利なもの：ドキュメント管理ツール、課題管理ツール、社内Wiki（プロジェクト単位で範囲を絞って）。

つないではいけないもの：本番環境の認証情報が置かれた場所、顧客から預かったデータ、ソースコードのうち契約上持ち出し禁止のもの。

接続の可否は、必ず案件の契約・NDAを確認してから。 「技術的にできる」と「契約上できる」は別です。SEには特にこの線引きを強調してください。

そのまま使えるプロンプト

つなぐ前の棚卸しに使います。

これから外部ツールをChatGPTに接続しようとしています。
接続前のリスク確認をしてください。

【接続しようとしているもの】（ここに書く）
【そこに入っているデータの種類】（ここに書く）
【私の立場・扱う情報】（ここに書く）

出してほしいもの：
1. この接続で読まれる可能性がある情報の種類
2. 接続してはいけない可能性があるデータと、その理由
3. 接続範囲を絞るとしたら、どこまでに絞るべきか
4. 接続前に、社内・組織に確認しておくべきこと
5. 接続後に定期的に見直すべきポイント

組み合わせるとよいフレームワーク

What am I missing? — 接続前の確認漏れ。

What am I missing? この外部ツール接続の計画で見落としている情報、
確認事項、リスク、準備物を挙げてください。
特に、組織のルール・契約・法令の観点で確認すべきことを優先してください。

Edge cases — 想定外の読まれ方。

Edge cases. この接続設定がうまく当てはまらない、あるいは想定外の情報が
読まれてしまう可能性があるケースを挙げ、それぞれの対処方法も出してください。

失敗しやすい使い方

• とりあえず全部つなぐ。 最悪の運用です。範囲を絞る。
• 権限の確認画面を読まずにOKを押す。 読み上げる習慣を研修で作る。
• つなぎっぱなしにする。 使い終わったら外す。少なくとも定期的に見直す。
• 組織のルールを確認せずにつなぐ。 社労士は事務所ルール、医学部生は大学規定、SEは契約・NDA。
• 「AIが勝手に見た」と思う。 見られる設定にしたのは自分です。責任は接続した人にあります。

最後の確認

• 接続一覧を開いて、今つながっているものを全部言えるか確認する。
• 言えないものがあれば、外す。
• 参照させたら「どのファイルを参照しましたか」と必ず聞き、想定外のファイルが混ざっていないか見る。
• 組織のルールと照らして、記録を残す（項目29）。

到達目標

• 接続の権限画面を読んでから許可できる。
• 「つないでよいもの・いけないもの」を自分の立場で線引きできる。
• 使い終わったら外す、という運用ができる。

Web検索

この項目で教えたいこと

「Webを検索して」と明示する癖を付ける。

これが、この項目のすべてです。機能の説明はいりません。言い方の癖を1つ植え付けるのが目的です。

黙っていると、AIは自分の記憶（学習した内容）で答えることがあります。制度も、ガイドラインも、ライブラリのバージョンも、記憶で答えられたら困ります。

講師の考え方を反映した説明

「AIは、聞かれたら答えます。 調べたのか、覚えていたことを言っているのか、見た目では分かりません。

だから、毎回言います。 『Webを検索して』 『公式情報を確認して』

この2つを、口癖にしてください。 制度の話、薬の話、バージョンの話。この3つは特に、絶対に言ってください。

覚え方は簡単です。変わるものは、検索させる。」

そして、もう1つ教えます。

「検索させたら、いつ時点の情報かを必ず言わせてください。 『2026年8月時点』と書かせる。書いてなければ聞く。」

普通のチャットだけの場合との違い

チャットで何気なく聞くと、記憶ベースの回答が返ってきます。それらしく、自信を持って返ってきます。だから気づけません。

「Webを検索して」と言うと、検索結果を根拠に答えます。出典が出てくるので、自分で確認できます。この「自分で確認できる状態にする」ことが目的であって、AIを信じるためではありません。

研修での実演

1. 変わりやすいことを1つ、何も指定せずに聞く（例：ある制度の金額、あるライブラリの最新版）。
2. 出てきた答えをメモする。
3. 同じ質問に「Webを検索して、出典URLと情報の日付も付けて」を足して聞き直す。
4. 2つを並べる。違っていたら大成功。同じでも「確認できた」ことに意味があると説明する。
5. さらに「その出典は公式ですか、二次情報ですか」と聞く。項目18につなぐ。
6. 「検索結果に書いてなかったことを、あなたの知識で補いましたか」と聞く。混ざりを自己申告させる。

6は必ず入れてください。 検索させても、足りない部分を記憶で埋めることがあります。

サンプル問題

自分の仕事・勉強に関する「変わりやすい情報」を1つ選んで、次の2回聞いてください。

1回目：普通に聞く 2回目：「Webを検索して、出典URLと情報の日付も付けて」を足して聞く

2つの答えを比べてください。 - 内容は同じでしたか？ - 2回目の出典は、公式のものでしたか？ - もし1回目だけを信じていたら、どうなっていましたか？

社労士での活かし方

必ず検索させるもの： 年金額、保険料率、支給要件、認定基準の改正、様式の変更、提出先。

社会保険の制度は毎年動きます。AIの記憶で答えさせたら事故です。 そして検索させても、必ず日本年金機構・厚生労働省の公式ページで最終確認します（項目18）。

言い方の型：

「Webを検索して、2026年度の◯◯について調べてください。出典は日本年金機構または厚生労働省の公式ページを優先し、URLと更新日を明記してください。公式で確認できなかった項目は『未確認』と書いてください。」

「未確認と書いてください」 — これを入れるかどうかで、実務での安全性が変わります。

医学部生での活かし方

必ず検索させるもの： 診療ガイドラインの最新版、薬剤の適応・用量、感染症の流行状況、国試の出題基準。

ただし、医学生には特に強く言ってください。

「検索した情報も、臨床判断の根拠にはしない。必ず一次資料（ガイドライン本体、添付文書、教科書）に当たる。」

AIの検索は「どこを見ればいいかを探す道具」であって、「答えを得る道具」ではありません。この線引きを、医学部生には最初に刺しておいてください。

システムエンジニアでの活かし方

必ず検索させるもの： ライブラリの最新版とサポート状況、脆弱性情報、APIの仕様変更、非推奨になった機能、OS・ミドルウェアのEOL。

AIの記憶にあるバージョンは古いことが多いです。「このライブラリの最新版は」と聞いて記憶で答えられ、そのまま使うと、非推奨の書き方を採用してしまいます。

言い方の型：

「Webを検索して、◯◯の最新の安定版と、そのリリース日、公式ドキュメントのURLを教えてください。あわせて、直近のメジャーバージョンで削除・非推奨になった機能があれば挙げてください。」

そのまま使えるプロンプト

Webを検索して、次のことを調べてください。

【調べてほしいこと】
（ここに書く）

条件：
- 必ずWeb検索を使ってください。あなたの記憶だけで答えないでください
- 各情報に、出典URLと、そのページの更新日（または情報の時点）を付けてください
- 公式情報（発行元・所管官庁・開発元）を優先してください
- 検索で確認できなかった項目は「未確認」と明記してください
- 検索結果になく、あなたの知識で補った部分があれば「※知識で補足」と明記してください

最後に、「この情報のうち、私が自分で公式サイトで確認すべきもの」を挙げてください。

組み合わせるとよいフレームワーク

Sanity check — 検索結果が常識的におかしくないか。

Sanity check. この検索結果の内容に、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。
特に、複数の出典の間で食い違っている箇所を指摘してください。

What am I missing? — 検索しきれていない論点。

What am I missing? この調べ物で見落としている情報、確認事項、リスク、
準備物を挙げてください。
特に、検索キーワードの選び方で漏れている観点があれば指摘してください。

失敗しやすい使い方

• 検索させたつもりで、させていない。 「Webを検索して」を書き忘れる。これが一番多い。
• 出典を確認しない。 URLが出ていても開かない。1つは必ず開く。
• 二次情報のまとめサイトを鵜呑みにする。 特に制度・医療は危険。項目18へ。
• 情報の日付を確認しない。 3年前の記事が上位に来ていることは普通にあります。
• 検索結果と記憶が混ざったまま使う。 「※知識で補足」の指示を必ず入れる。

最後の確認

• 出典URLを最低1つ開く。 これを省いたら、検索させた意味が半減します。
• 情報の日付を見る。古ければ、より新しいものを探させる。
• 「未確認」と書かれた項目を、自分で確認する。
• 重要な判断に使う情報は、必ず公式で確認する（項目18）。

到達目標

• 「Webを検索して」を毎回書ける。
• 出典URLと情報の日付を出させられる。
• 変わるものは検索させる、が習慣になっている。

Deep Research

この項目で教えたいこと

時間のかかる調査を、まとめて任せる。

普通の検索が「1つ調べる」なら、Deep Researchは「調べて、突き合わせて、まとめる」まで一気にやります。数分〜数十分かかりますが、その間は他のことができます。

教えたいのは「便利」ではなく、「投げ方で結果が決まる」ということです。雑に投げると、雑な調査報告が返ってきます。

講師の考え方を反映した説明

「これは、時間のかかる調べ物を丸ごと任せる機能です。 15分くらい放っておくと、出典付きのレポートが返ってきます。

ただし、丸投げすると丸投げの答えが返ってきます。

だから、投げる前に3つ決めます。 1. 何を判断するための調査か 2. どこまで調べれば十分か（範囲・期間・地域） 3. どういう形で欲しいか（表？比較？時系列？）

この3つを書いてから投げてください。 書くのに5分かかりますが、返ってくるものの質が変わります。」

そして、必ず言い添えます。

「出典が付いていても、出典を開いて確かめるのは人間です。」

普通のチャットだけの場合との違い

チャットで「◯◯について調べて」と聞くと、その場で答えが返ってきます。速いですが、浅い。

Deep Researchは、複数の情報源を横断して、突き合わせて、矛盾も報告してくれます。「調べる」ではなく「調査する」。時間がかかるのは、そういうことをしているからです。

研修での実演

1. わざと雑に投げる。 「障害年金について調べて」など。
2. 結果を待つ間に、次の説明をする（待ち時間を使うのがコツ）。
3. 出てきた結果を見る。「間違ってはいないけど、使えない」ことを確認する。
4. 次に、3点セット（目的・範囲・形式）を書いて投げ直す。
5. 2つの結果を並べる。 分量ではなく、使えるかどうかで比べる。
6. 最後に、出典を1つ開いて、書かれている内容と合っているか確認する実演をする。

6を絶対に飛ばさないでください。 「出典付き＝正しい」という誤解が一番危険です。

サンプル問題

自分の仕事・勉強に関する調査テーマを1つ決めて、次の3点を書いてから投げてください。

1. この調査は、何を判断するために行うのか
2. 調べる範囲（対象、期間、地域、除外するもの）
3. 欲しい成果物の形（比較表／時系列／論点整理／推奨案）

結果が返ってきたら、出典を2つ開いて、書かれている内容と一致しているか確認してください。 一致していなかったものはありましたか？

社労士での活かし方

• 障害年金の特定の傷病について、認定基準・裁決例・実務上の論点を横断的に調査
• 法改正の影響を、複数の情報源から整理
• 顧問先の業種における労務管理の最新動向

裁決例・判例の調査では、必ずこう書きます。

「実際の裁決・判例として存在が確認できるものだけを挙げ、出典（事件番号・裁決年月日・掲載元URL）を明記してください。存在が確認できないものは絶対に挙げないでください。」

AIが判例を創作する事故は実際に起きています。社労士には最優先で伝えてください。

医学部生での活かし方

• ある疾患について、最新のガイドラインと主要な論文を横断して整理
• 診断基準の変遷を時系列でまとめる
• 抄読会用の背景調査

論文の引用では必ずこう書きます。

「実在が確認できる論文だけを挙げ、DOIまたはPubMed IDと掲載誌・発行年を明記してください。確認できないものは挙げないでください。」

そして、挙がった論文は自分でPubMedで検索して実在確認する。 これを課題にしてください。

システムエンジニアでの活かし方

• 技術選定のための比較調査（3つのライブラリ／サービスの機能・ライセンス・保守状況）
• ある脆弱性の影響範囲と対応方法の調査
• 移行事例の調査

技術選定では、「評価軸を先に指定する」のが効きます。

「次の評価軸で比較表を作ってください：ライセンス／直近1年のコミット頻度／メジャーバージョンの更新履歴／日本語ドキュメントの有無／代表的な採用事例／既知の制約。各項目に出典URLを付けてください。」

そのまま使えるプロンプト

以下のテーマについて、詳しく調査してください。

【調査の目的】
私は（　　　）を判断しようとしています。その判断材料が欲しいです。

【調査範囲】
- 対象：
- 期間：（例）直近3年
- 地域・適用範囲：（例）日本国内
- 除外するもの：

【欲しい成果物の形】
（例）比較表 → 論点整理 → 推奨案 → 未確認事項、の順

【必須条件】
- 実在が確認できる情報源だけを使ってください
- 各記述に出典URLと情報の日付を付けてください
- 公式・一次情報を優先し、二次情報を使う場合はその旨を明記してください
- 情報源によって内容が食い違う箇所は、食い違いとして明示してください
- 調べきれなかった点は「未確認」として最後にまとめてください

組み合わせるとよいフレームワーク

Grill me — 調査レポートを叩く。

Grill me. この調査レポートについて、弱い点、反論されそうな点、説明不足、
確認不足を厳しめに指摘してください。
特に、出典が弱い主張、一般論で埋めた箇所、結論が飛躍している箇所を挙げてください。
最後に改善優先度を付けてください。

Fill the gaps — 調査を完成させるために足りないもの。

Fill the gaps. この調査を判断に使える水準に完成させるために足りない情報を
1問ずつ質問してください。各質問に、なぜ必要か、推奨回答例も付けてください。
最大5問でお願いします。

失敗しやすい使い方

• 目的を書かずに投げる。 「◯◯について」だけだと、教科書の目次のようなものが返ってきます。
• 出典を開かない。 これが最大の事故。必ず2つは開く。
• 存在しない判例・論文・規格を鵜呑みにする。 「実在が確認できるものだけ」の指示を必ず入れる。
• 調査結果をそのまま成果物にする。 調査は材料です。成果物は別の会話で作る（項目06）。
• 時間がかかるからと、走らせたまま放置して確認を忘れる。 走らせたらカレンダーに確認予定を入れる。

最後の確認

• 出典を2つ以上開いて、記述と一致するか確認する。
• 判例・論文・規格・製品名など、実在するかを自分で1件検索する。
• 「未確認」欄が空なら疑う。完璧な調査はありません。空なのは、書かせ忘れです。
• 判断に直結する部分は、公式・一次情報で裏を取る（項目18）。

到達目標

• 目的・範囲・形式の3点を書いてから投げられる。
• 「実在が確認できるものだけ」の指示を入れられる。
• 出典を必ず自分で開く習慣がある。

公式情報確認

この項目で教えたいこと

「公式情報を確認して」と言う癖。 そして、最後は自分で公式ページを開くという行動。

項目16とセットですが、あえて別項目にしています。理由は、検索させても二次情報で満足してしまう人が多いからです。ここは分けて、行動として教えます。

講師の考え方を反映した説明

「検索させました。出典も出ました。安心しましたか。

その出典、誰が書いたものですか。

まとめサイト、個人ブログ、3年前の記事。 全部『出典』です。でも、公式ではありません。

だから、もう一言足します。 『公式情報を確認して』

年金なら日本年金機構・厚生労働省。 薬なら添付文書・学会のガイドライン。 技術なら公式ドキュメント・リリースノート。

そして最後に、自分でそのページを開いてください。 AIが読んだと言っても、自分の目で見るまでは確認したことになりません。」

「AIが確認した」は「確認した」ではない。 これを研修で一度、はっきり言い切ってください。

普通のチャットだけの場合との違い

チャットでは、答えが返ってきたら終わりでした。出典という概念すらありませんでした。

ここで教えるのは機能ではなく、仕事の作法です。AIを使うようになると、確認のコストが下がるので、むしろ確認しやすくなります。「どこを見ればいいか」をAIが教えてくれるからです。

研修での実演

1. AIに、ある制度・数値について「Webを検索して」と聞く。
2. 出てきた出典を見る。公式か二次情報かを分類させる。
3. 「公式情報を確認して」と言い直して、公式ページの情報だけで答えさせる。
4. その公式ページを、講師がブラウザで実際に開く。 画面で見せる。
5. AIが言った内容と、公式ページの記載を突き合わせる。
6. 「これが確認です」と言って締める。

4が実演の本体です。 ブラウザを開く動作を見せることに意味があります。

サンプル問題

自分の分野で「間違えたら困る数値・要件」を1つ選んでください。

1. AIに「Webを検索して」で調べさせる
2. 出典が公式か二次情報かを分類させる
3. 「公式情報を確認して」と言い直す
4. 公式ページを自分でブラウザで開いて、記載を確認する

AIの答えと公式ページの記載は、完全に一致していましたか？ 違っていた点があれば、それは何でしたか？

社労士での活かし方

公式とは： 日本年金機構、厚生労働省、e-Gov法令検索、各都道府県労働局。

公式ではない： 社労士の個人ブログ、まとめサイト、AIの記憶、3年前のセミナー資料。

障害年金は、認定基準・様式・添付書類の要件が更新されます。AIの答えを顧客に伝える前に、必ず公式ページを開く。 これを事務所ルールにしてください。

さらに、公式でも判断が分かれる論点は年金事務所への照会が必要です。「公式で確認 → それでも判断できないものは照会」という2段階を教えてください。

医学部生での活かし方

公式（一次資料）とは： 各学会の診療ガイドライン本体、医薬品の添付文書・インタビューフォーム、標準的な教科書、原著論文。

一次資料ではない： 医学系まとめサイト、国試対策サイトの解説、AIの説明、先輩のノート。

医学部生には、この言い方が効きます。

「AIは、どの本のどのページを開けばいいかを教えてくれる道具です。本の代わりではありません。」

レポートや発表で引用するのは、必ず一次資料。AIの出力を引用元にしない。これは学術的な作法の問題でもあります。

システムエンジニアでの活かし方

公式とは： 公式ドキュメント、リリースノート、CHANGELOG、RFC、ベンダーの公式サポート情報、CVEデータベース。

公式ではない： 技術ブログ、Q&Aサイトの回答、AIの記憶。

特に、非推奨・廃止された書き方は、AIの記憶と技術ブログの両方に大量に残っています。公式ドキュメントの該当バージョンのページを開くまでは確定させない。

言い方の型：

「公式ドキュメントの、バージョン◯◯のページを参照して回答してください。該当ページのURLを明記してください。公式に記載がない場合は『公式に記載なし』と書いてください。」

そのまま使えるプロンプト

次のことについて、公式情報を確認して回答してください。

【確認したいこと】
（ここに書く）

【私が公式とみなすもの】
（例）日本年金機構、厚生労働省、e-Gov法令検索
（例）学会の診療ガイドライン本体、医薬品の添付文書
（例）製品の公式ドキュメント、リリースノート

条件：
- 上記の公式情報に記載がある内容だけを回答してください
- 各記述に、公式ページのURLと更新日を付けてください
- 公式に記載が見つからない項目は「公式に記載を確認できず」と明記し、
  推測で補わないでください
- 二次情報しか見つからなかった項目は、その旨を明記してください

最後に、私が自分でブラウザで開いて確認すべきページを、優先順に挙げてください。

最後の1行が、この項目の核心です。 必ず入れてください。

組み合わせるとよいフレームワーク

Sanity check — 公式情報の読み取りに無理がないか。

Sanity check. この公式情報の読み取りに、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。
特に、条文・基準の解釈を広げすぎている箇所を指摘してください。

Smoke test — 確認作業として成立しているか。

この確認作業をスモークテストしてください。細かい改善ではなく、
最低限使えるかを確認してください。必須情報の抜け、矛盾、日付・数値・リンクの不整合、
読み手が次に何をすればよいか、人間が確認すべき点を確認してください。

失敗しやすい使い方

• AIが「公式で確認しました」と言ったのを信じる。 開くまでは確認ではありません。
• 出典が付いていれば公式だと思う。 URLのドメインを見る癖を付ける。
• 公式ページの日付を見ない。 公式でも古いページは残っています。
• 公式に記載がない部分を、AIが埋めたことに気づかない。 「記載を確認できず」の指示を必ず入れる。
• 顧客・患者・上司に、確認前の情報を伝える。 これが一番の事故です。

最後の確認

• 公式ページを1つ以上、自分のブラウザで開く。 これが最後の確認そのものです。
• 開いたページの更新日を見る。
• AIの記述と公式の記載で、言葉が変わっていないか確認する（「原則」が消えている、など）。
• 顧客・患者・チームに伝える情報は、必ず開いてから伝える。

到達目標

• 「公式情報を確認して」を毎回言える。
• 自分の分野の「公式」が何かを列挙できる。
• AIが確認したと言っても、自分で開く。

AIに質問させる

この項目で教えたいこと

丸投げをやめさせる。

そのための方法が「AIに質問させる」です。指示が足りないまま作らせると、AIは足りない部分を推測で埋めます。 推測は、それらしい顔をして混ざります。

だから、作らせる前に質問させる。 これがこの研修の中で、たぶん一番すぐ効くテクニックです。

講師の考え方を反映した説明

「『いい感じの資料を作って』と言うと、いい感じの資料が出てきます。 でも、あなたが欲しかったものではありません。

理由は簡単で、足りない情報をAIが勝手に埋めたからです。

だから、作らせる前にこう言います。 『作る前に、私に質問してください。5問まで。』

すると、AIが聞いてきます。 『誰が読みますか』『いつまでですか』『何ページですか』

この質問に答えているうちに、自分の頭が整理されます。 これが本当の効果です。AIのためじゃなくて、自分のためなんです。」

「AIに質問させると、自分の頭が整理される」 — これがこの項目のメッセージです。

普通のチャットだけの場合との違い

チャットでは、一方通行でした。指示を出す → 出力が返る → 違う → 直させる → また違う。この往復で疲れます。

質問させると、最初の1回で近いものが出ます。 往復の回数が減ります。しかも、質問に答える過程で自分の要件が固まります。

研修での実演

1. わざと雑な指示を出す。「うちの事務所の案内資料を作って」など。
2. 出てきたものを見せる。それっぽいけど使えない、を確認する。
3. どこが推測で埋められたかをAIに自己申告させる。「この出力のうち、私が指定していない情報を推測で補った箇所を挙げて」と聞く。大量に出てきます。
4. 次に「作る前に5問質問して」と付けて投げ直す。
5. 質問に、講師がその場で答える。答えながら「あ、これ決めてなかった」と口に出す。
6. 回答後に作らせる。1回目との差を見せる。

3と5が実演の山場です。 特に3は、受講者が息をのみます。

サンプル問題

自分がAIに作らせたい成果物を1つ決めて、次の2回やってください。

1回目：思いついたまま指示して、作らせる → 「推測で補った箇所」を自己申告させる

2回目：「作る前に、私に5問質問してください」を付けて投げる → 質問に答えてから作らせる

2つを比べて、どちらが自分の意図に近かったかを言ってください。 そして、質問に答えている時に「決めていなかったこと」がいくつありましたか？

社労士での活かし方

顧客への説明資料、事務所案内、就業規則の説明文。

質問させると、こういうことを聞かれます。

• 読み手は誰か（顧客本人／家族／医療機関）
• 相手の前提知識はどれくらいか
• 何を決めてもらうための資料か
• 使ってはいけない専門用語はあるか

障害年金の説明資料は、読み手が本人か家族かで書き方が全然違います。 質問させることで、そこを最初に決められます。

さらに、顧客ヒアリングの前に使えます。「初回相談で聞くべきことを、私に質問する形で挙げて」と頼むと、ヒアリングシートになります。

医学部生での活かし方

レポート、症例発表、勉強計画。

• 「レポートを書く前に、私に5問質問して」
• 「勉強計画を立てる前に、私の現状について5問質問して」

2つ目が特に効きます。「今、何が分かっていて、何が分かっていないか」を答えさせられるので、計画の前に自己分析が終わります。

さらに応用：「私がこの範囲を理解できているか確認するために、私に質問してください。1問ずつ出して、私の答えを採点してください。」 これは口頭試問の練習になります。

システムエンジニアでの活かし方

設計、実装、見積もり、障害調査。

• 「設計案を出す前に、前提について5問質問して」
• 「見積もりを出す前に、不明点を質問して」

要件定義そのものです。 SEにはこう説明すると通じます。「これ、AIに要件ヒアリングをさせているだけです。やっていることは、いつもの仕事と同じです。」

障害調査でも効きます。「原因を推測する前に、私に状況を5問質問してください。」

そのまま使えるプロンプト

これから成果物を作ってもらいます。
ただし、いきなり作らないでください。

まず、この成果物を私の意図どおりに作るために足りない情報を、
1問ずつ質問してください。

- 質問は1回に1問だけ出してください
- 各質問には「なぜそれが必要か」と「推奨する回答例」を付けてください
- 最大5問までにしてください
- 5問終わったら、私の回答をまとめて確認を取ってから作り始めてください

【作りたい成果物】
（ここに書く）

「1回に1問だけ」が重要です。 5問まとめて出されると、人間が雑に答えます。

組み合わせるとよいフレームワーク

Fill the gaps — この項目そのものを支えるフレームワーク。

Fill the gaps. この成果物を完成させるために足りない情報を1問ずつ質問してください。
各質問に、なぜ必要か、推奨回答例も付けてください。最大5問でお願いします。

What am I missing? — 質問が出尽くした後に。

What am I missing? ここまでの回答を踏まえて、この計画で見落としている情報、
確認事項、リスク、準備物を挙げてください。

失敗しやすい使い方

• 質問に雑に答える。 「任せます」と答えたら、丸投げに戻ります。
• 5問まとめて出させる。 1問ずつのほうが、答えの質が上がります。
• 質問されたことに答えられず、そのまま作らせる。 答えられないなら、それが調べるべきことです。
• 質問数を無制限にする。 20問聞かれたら人間が疲れます。5問で区切る。
• 質問フェーズを飛ばして「早く作って」と言う。 結局やり直しになって遅くなります。

最後の確認

• 質問に答えた内容を、自分でもメモに残す。 それが要件定義書になります。
• 「私の回答のうち、曖昧だったものはどれですか」と聞き返す。
• 作らせた後、「私が指定していないのに補った箇所」を必ず自己申告させる。

到達目標

• 「作る前に5問質問して」を口癖にできる。
• 質問に答える過程で、自分の要件を言語化できる。
• 「推測で補った箇所」を自己申告させられる。

編集スペース（Canvas / ライティングボックス）

この項目で教えたいこと

「返事」ではなく「文書」を作る場所がある。

チャットの返事は流れていきます。編集スペースは、文書がそこに残って、部分的に直せる場所です。

なお、研修では「Canvas」という言葉は使いません。 古く感じるうえに、受講者に伝わりません。「編集スペース」「ライティングボックス」と呼びます。

講師の考え方を反映した説明

「今までは、直してほしい時にどうしていましたか。 『3段落目をもっと丁寧に』と言って、全部書き直されて、良かった部分まで変わっていた。 ありますよね。

編集スペースを使うと、直したい部分だけを選んで直せます。 ここだけ短く。ここだけ丁寧に。ここだけ専門用語を減らす。

Wordの画面が横に出てくる、と思ってください。 右側に文書があって、左側で相談しながら直していく。 これが一番近いイメージです。」

用語について、研修ではこう言っておきます。

「機能の名前はCanvasですが、この研修では編集スペースと呼びます。名前より、文書がそこに残るという性質を覚えてください。」

普通のチャットだけの場合との違い

「どれが最新か分からなくなる」 — チャットで長文を扱った人は全員経験しています。ここを突くと共感が取れます。

研修での実演

1. チャットで長文を作り、「3段落目だけ直して」と頼む。全部書き直されるのを見せる（うまくいってしまった場合は、2〜3回直させると必ず崩れます）。
2. 編集スペースに切り替える。文書が右側に出るのを見せる。
3. 3段落目だけを選択して、「ここをもっと具体的に」と指示する。そこだけ変わるのを見せる。
4. 「全体の長さを2割減らして」と指示して、全体編集もできることを見せる。
5. 一度直した後、元に戻す操作も見せる。
6. 完成した文書を、そのままコピーして使えることを見せる。

1と3の対比です。 それ以外は付け足しです。

サンプル問題

自分が実際に書く必要のある文書を1つ選び、編集スペースで作ってください。

1. まず全体を作らせる
2. 一番気に入らない段落だけを選んで、直す指示を出す
3. 「全体を2割短く」と指示する
4. 完成版に Misread test をかける

部分だけ直った時、他の段落は変わっていませんでしたか？

社労士での活かし方

• 病歴就労状況等申立書の文章を、段落ごとに練る
• 顧客向けの説明文書を、専門用語の多い段落だけ易しくする
• 事務所の案内文、契約書の説明パートの推敲

申立書の推敲が本命です。 日常生活の困難さを書く段落は、何度も練り直します。編集スペースなら、その段落だけを10回直せます。

ただし、事実関係は資料に基づいていること。 表現を練るのはよいが、事実を盛るのは絶対に禁止です。ここは研修で強く言ってください。

医学部生での活かし方

• レポートの本文を、セクション単位で推敲
• 症例発表の原稿を、時間に合わせて削る
• 自分のまとめノートを、章ごとに書き直す

「全体を◯字に収めて」が効きます。レポートの字数制限、発表の持ち時間。削る作業は人間がやると苦しいですが、ここは得意分野です。

ただし、削った結果、必要な条件が落ちていないかは必ず自分で確認してください。医学的な記述は、削ると意味が変わることがあります。

システムエンジニアでの活かし方

• 設計書・障害報告書を、セクション単位で推敲
• READMEやドキュメントを段階的に整える
• 顧客向け報告書の、技術的すぎる段落だけを易しくする

障害報告書は、この機能の独壇場です。 「原因」の段落だけ書き直す、「再発防止策」だけ具体的にする、という作業が何度も発生します。

そのまま使えるプロンプト

文書を作る時

次の文書を編集スペースで作成してください。

【文書の種類】
【読み手】
【目的】（読んだ人に何をしてほしいか）
【分量】（　　　）字程度
【入れる要素】
【使ってはいけない表現・用語】

作成後、私が部分ごとに修正を指示します。
指示した部分以外は変更しないでください。

部分修正の時

選択した部分だけを修正してください。
それ以外の箇所は、一切変更しないでください。

修正の方向：（例）専門用語を減らし、初めて読む人でも分かる表現にする
文字数：現状と同程度

「それ以外は変更しないでください」を毎回入れてください。 これが効きます。

組み合わせるとよいフレームワーク

Misread test — 文書を出す前の必須チェック。

Misread test. この文章について、読み手が誤解しそうな表現を探してください。
該当箇所、誤解される可能性、修正案を出してください。

Grill me — 文書の中身そのものを叩く。

Grill me. この文書について、弱い点、反論されそうな点、説明不足、
確認不足を厳しめに指摘してください。最後に改善優先度を付けてください。

失敗しやすい使い方

• 「それ以外は変更しないで」を書かない。 直したくない部分まで変わります。
• 直しすぎて、元のほうが良かったことに気づく。 途中版をどこかに残しておく。
• AIの文体に引っ張られる。 自分の文章として出すなら、最後は自分の言葉に直す。
• 事実を盛る。 表現の推敲と、事実の改変は違います。特に申立書・報告書。
• 完成後にチェックをかけない。 必ず Misread test を通す。

最後の確認

• 通しで1回、声に出して読む。 部分修正を重ねると、つなぎ目が不自然になります。
• 直した段落と、その前後の段落の論理がつながっているか確認する。
• 事実・数値・固有名詞が、推敲の過程で変わっていないか確認する。
• 最後は人間が読む。 これは全項目共通ですが、文書は特に。

到達目標

• 編集スペースで文書を作り、部分だけ修正できる。
• 「それ以外は変更しないでください」を書ける。
• 完成後に Misread test をかける習慣がある。

メール文作成

この項目で教えたいこと

メールは、書くより「誤解されないか確かめる」ほうが大事。

メール文をAIに書かせること自体は、誰でも思いつきます。この研修で教えたいのは、その先です。

送る前に Misread test をかける。 これ1つを持ち帰らせます。

講師の考え方を反映した説明

「メールを書かせるのは簡単です。でも、それだけだと『AIっぽいメール』が出てきます。

本当に価値があるのはここです。

『このメール、相手にどう読まれますか』

送る前に、読み手の目で読ませる。 『この一文は、催促に読めます』 『この表現は、責任を認めたと取られる可能性があります』

これ、人間が一番失敗するところです。 特に、急いでいる時。怒っている時。謝っている時。」

そして、メール作成の3点セットを教えます。

1. 相手との関係（初めて／継続／目上／トラブル中）
2. 相手にしてほしい行動（返信？承認？日程調整？何もしなくていい？）
3. 書いてはいけないこと（約束できないこと、確定していないこと）

3が抜けたメールが事故ります。

普通のチャットだけの場合との違い

チャットでメールを書かせると、無難な文が出ます。それをそのまま送って、微妙に空気を外す。よくあることです。

Workでは、過去のやり取りや関連資料を置いておけるので、文脈に合ったメールになります。さらに、貼り紙（項目05）に自分の文体ルールを書いておけば、毎回同じトーンになります。

研修での実演

1. 少し厄介な状況を設定する（納期遅延の連絡、書類不備の指摘、断りの返信）。
2. 普通に「メールを書いて」と頼む。出てきたものを読む。
3. Misread test をかける。 「相手にどう読まれるか」を出させる。
4. 出てきた指摘を読み上げる。「これ、確かに嫌味に読めますね」が出たら成功。
5. 指摘を反映して書き直す。
6. さらに「このメールを受け取った相手が、次にどう動くと思いますか」と聞く。行動が想定どおりか確認する。

6は隠れた本命です。 メールの目的は「相手を動かすこと」なので。

サンプル問題

自分が今週送る必要のあるメールを1つ選び、次をやってください。

1. 相手との関係、相手にしてほしい行動、書いてはいけないことを先に書く
2. メール文を作らせる
3. Misread test をかける
4. 「このメールを受け取った相手が次にどう動くか」を予想させる
5. 予想が自分の意図と違っていたら、書き直す

3で出てきた指摘のうち、自分では気づいていなかったものは何件ありましたか？

社労士での活かし方

• 顧客への書類不備の連絡（責めているように読まれないことが最重要）
• 医療機関への診断書記載に関する照会文
• 年金事務所への確認依頼

書類不備の連絡は、この項目の最重要ユースケースです。事実を伝えるだけのつもりが、顧客には「怒られた」と伝わることがあります。

必ず入れる指示：

「相手を責める調子にならないようにしてください。不備の原因を相手に帰属させる表現を避け、次に何をすればよいかが明確に伝わるようにしてください。」

医療機関への照会文では、「診断の内容に意見を述べない」を厳守します。これも貼り紙に書いておくとよいです。

医学部生での活かし方

• 教授・指導医へのメール（アポイント、質問、欠席連絡）
• 実習先への連絡
• 研究室訪問の依頼メール

医学部生には、「目上の相手への初めてのメール」を練習させてください。ここは失敗の代償が大きく、かつ経験が少ない領域です。

必ず入れる指示：

「学生から教員への初回のメールとして、失礼がなく、要件が3行以内で分かる構成にしてください。相手の時間を取らせない配慮を含めてください。」

システムエンジニアでの活かし方

• 障害発生時の一次連絡（確定していないことを書かないのが最重要）
• 仕様確認の質問メール
• スケジュール変更の相談

障害連絡では、これを必ず指示します。

「現時点で確定している事実と、調査中の事項を明確に分けてください。原因について確定していない推測を、断定的に書かないでください。」

「調査中」と「原因は◯◯です」を混ぜたメールは、後で必ず問題になります。 SEには実感があるはずです。

そのまま使えるプロンプト

次の状況でメールを書いてください。

【相手】（立場・関係性・これまでのやり取り）
【状況】
【相手にしてほしいこと】
【絶対に書いてはいけないこと】（例：確定していない原因、約束できない期日）
【トーン】（例：丁寧だが簡潔。謝罪しすぎない）
【分量】（　　　）行程度

条件：
- 件名も作ってください
- 用件が最初の3行で分かる構成にしてください
- 相手が次にすべきことを、明確に1つ書いてください

続けて必ずこれをかけます。

Misread test. このメールについて、読み手が誤解しそうな表現を探してください。
該当箇所、誤解される可能性、修正案を出してください。
特に、次の観点で見てください。
- 責めている / 催促している / 嫌味に読める箇所
- こちらが約束したと受け取られかねない箇所
- 相手が何をすればよいか分からなくなる箇所

そのうえで、このメールを受け取った相手が次にどう行動すると予想されるか教えてください。

組み合わせるとよいフレームワーク

Misread test — この項目の主役。上記のとおり。

Sanity check — 事実関係と前提の確認。

Sanity check. このメールの内容に、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。
特に、日付・期限・金額・固有名詞の整合を見てください。

失敗しやすい使い方

• Misread test をかけずに送る。 この項目の存在意義がなくなります。
• 確定していないことを断定で書く。 特に障害連絡・不備連絡。
• AIっぽい定型文をそのまま送る。 相手が読めば分かります。最後は自分の言葉に直す。
• 顧客名・患者名・個人情報を入れたまま作らせる。 「◯◯様」で作らせて、送る直前に自分で置き換える（項目28）。
• 長いメールを作らせる。 「3行で用件が分かる」を指定しないと、必ず長くなります。

最後の確認

• Misread test の指摘を全部読む。 反映するかは自分で決めてよいが、読まずに送らない。
• 日付・期限・金額・宛名を、目視で確認する。
• 添付ファイルの有無と中身を確認する。
• 送信前に1回、声に出して読む。

到達目標

• 相手・目的・禁止事項の3点を書いてからメールを作らせられる。
• 送信前に必ず Misread test をかける。
• 確定していないことを断定させない指示が書ける。

PowerPoint資料作成

この項目で教えたいこと

成果物が「ファイル」として出てくる。

チャットしか使っていない人にとって、これは驚きです。「文章が出てくる」と思っていたら、pptxがダウンロードできる。

ただし、この項目で本当に教えたいのは、「構成を先に決めさせる」ことです。いきなりスライドを作らせると、20枚の中身のないスライドが出てきます。

講師の考え方を反映した説明

「資料を作って、と言うと、スライドが出てきます。ファイルで。 ここまでは、たぶん想像より驚きます。

でも、そのままでは使えません。

順番があります。 1. まず、伝えたいことを1行で決める 2. 次に、構成（各スライドの見出しと、そこで言うこと1行）を作らせる 3. 構成をこちらが直す 4. それからスライドにする

3を飛ばすから、使えない資料が出てくるんです。 構成のチェックは、人間の仕事です。」

そして、スライド作成の鉄則を1つ。

「1スライド1メッセージ。 これをプロンプトに書いてください。書かないと、詰め込まれます。」

普通のチャットだけの場合との違い

チャットでは、スライドの「案」がテキストで出るだけでした。それを見ながら、自分でPowerPointを開いて作っていました。

Workでは、pptxファイルが出てきます。 開いて、直して、使えます。作業時間が変わるのはここです。

さらに、Projectに置いた資料をもとに作らせられるので、中身が自分の案件の話になります。 これが一番大きい。

研修での実演

1. Projectに入れてある資料（項目08で読ませたPDFなど）を使う。
2. まず「この資料をもとに、10枚の構成案を作って。各スライドの見出しと、そこで言うこと1行だけ」と頼む。
3. 構成案をその場で直す。 「これは要らない」「この順番を入れ替える」と口に出しながら直す。この作業を見せるのが実演の本体です。
4. 直した構成をもとに、pptxを作らせる。
5. ダウンロードして、その場で開く。 文字化けしていないか、はみ出していないか確認する。
6. 「じゃあ、この3枚目に図を入れて」など、部分的な作り直しを見せる。

サンプル問題

Projectに入れた資料をもとに、8〜12枚のスライドを作ってください。

1. 先に構成案だけを出させる（見出し＋1行）
2. 構成案を自分で直す（削る・順番を変える・足す）
3. 直した構成でpptxを作らせる
4. ダウンロードして開き、崩れていないか確認する

2で、いくつ削りましたか？ 削れなかった場合、それはなぜですか？

社労士での活かし方

• 顧客向けの障害年金制度の説明資料
• 顧問先向けの法改正セミナー資料
• 事務所紹介・サービス説明資料

顧客向け説明資料では、必ずこう指定します。

「専門用語を使う場合は、必ずスライド内に一言の説明を付けてください。制度の数値・要件については、出典（機関名と確認日）をスライドの下部に入れてください。」

出典をスライドに入れるのは、社労士の資料では必須です。そして、その数値は自分で公式確認します（項目18）。

医学部生での活かし方

• 症例発表・抄読会のスライド
• 勉強会での説明資料
• 研究発表のドラフト

抄読会なら、Projectに論文PDFを入れて構成案から作れます。ただし、図表は必ず原著から正しく引用すること。AIに図の内容を説明させることはできても、図そのものの扱いは自分で行います。

指定に入れるとよい条件：

「1スライド1メッセージ。発表時間◯分に収まる枚数にしてください。各スライドに、口頭で話す内容をノート欄用に3行で書いてください。」

ノート欄まで作らせるのは、発表練習に直結します。

システムエンジニアでの活かし方

• 設計レビュー資料
• 障害報告資料（経緯・原因・影響・対策）
• 顧客向けの進捗報告

障害報告資料は構成が決まっているので、AIとの相性が非常に良いです。

「構成は次で固定：1.概要 / 2.影響範囲 / 3.時系列 / 4.原因 / 5.暫定対応 / 6.恒久対策 / 7.再発防止 / 8.今後の予定。確定していない事項は『調査中』と明記し、推測を断定的に書かないでください。」

そのまま使えるプロンプト

ステップ1：構成案

このフォルダーの資料をもとに、プレゼン資料の構成案を作ってください。
まだスライドは作らないでください。

【聞き手】
【目的】（聞き手に何を持ち帰ってほしいか）
【時間】（　　　）分
【この資料で一番伝えたいこと】（1行で）

出してほしいもの：
- スライド番号 / 見出し / そのスライドで言うこと（1行）だけの一覧
- 1スライド1メッセージにしてください
- 想定枚数は時間から逆算してください

ステップ2：スライド化

上の構成案（私が修正したもの）どおりに、PowerPointファイルを作ってください。

条件：
- 1スライド1メッセージ
- 1スライドの文字数は箇条書き5行以内
- フォントサイズは会議室の後ろから読める大きさ
- 数値・固有名詞は、フォルダーの資料に書かれているものだけを使ってください
- 資料に根拠がない内容は入れず、必要なら「要確認」のスライドにまとめてください
- 各スライドのノート欄に、話す内容を3行で書いてください

組み合わせるとよいフレームワーク

Grill me — 構成案の段階でかけるのが効果的。

Grill me. このプレゼン構成案について、弱い点、反論されそうな点、説明不足、
確認不足を厳しめに指摘してください。
特に、聞き手から出そうな質問で、この構成では答えられないものを挙げてください。
最後に改善優先度を付けてください。

Make it actionable — 聞き手が動く資料にする。

Make it actionable. この資料を聞いた人が、明日すぐ実行できる手順、
準備物、チェックリストが分かる形にしてください。
最後のスライドに入れる内容として提案してください。

失敗しやすい使い方

• いきなりスライドを作らせる。 中身のない20枚が出ます。必ず構成案から。
• 構成案を直さずに通す。 人間が構成を見るのが、この作業の価値です。
• 枚数を指定しない。 時間に対して多すぎる資料になります。
• 資料にない数値をAIが入れる。 「フォルダーの資料に書かれているものだけ」を必ず指定。
• ダウンロードして開かない。 崩れていることがあります。必ず開く。

最後の確認

• 必ず開いて、全ページをスクロールする。 文字のはみ出し、文字化け、空スライド。
• 数値・固有名詞を、元資料と突き合わせる。
• 「このスライドの中で、資料に根拠がない記述はどれですか」と聞いて、自己申告させる。
• 発表するなら、時間を計って1回通す。

到達目標

• 構成案 → 人間が修正 → スライド化、の順で作れる。
• 「1スライド1メッセージ」を指定できる。
• 出てきたファイルを必ず開いて確認する。

Mermaid / Diagram

この項目で教えたいこと

文章で読むと分からないものが、図にすると一瞬で分かる。

そして、図はAIが得意です。 手順、フロー、関係、時系列。文章で書いてある資料を、図に変換させます。

もう1つ教えたいことがあります。図にすると、矛盾が見える。 文章では気づかなかった「この分岐、どこにも行き着かない」が、図にすると一目で分かります。

講師の考え方を反映した説明

「20ページの手順書を読んで、全体像が分かりますか。分かりませんよね。

図にします。

図にすると、おかしいところが見えます。 『この条件で分岐した後、片方の行き先が書いてない』 『この手順、どこからも呼ばれていない』

文章のままだと、絶対に気づきません。 図は、理解のためだけじゃなくて、検査のためでもあります。」

そして、扱いやすい図の種類を3つに絞って教えます。最初から10種類教えると混乱します。

普通のチャットだけの場合との違い

チャットでは、図を頼んでも文字で説明されるか、テキストの記号で描かれた読みにくいものが出ていました。

Mermaidという記法で書かせると、そのまま図としてレンダリングされます。 そして、その記法はテキストなので、直すのが簡単です。「この分岐を足して」と言えば、図が更新されます。

研修での実演

1. 手順が書かれた文章資料（項目14で作った手順書でよい）を用意する。
2. 「これをMermaidのフローチャートにして」と頼む。
3. 図が表示されるのを見せる。
4. 図を見て、おかしいところを一緒に探す。 たいてい1つ見つかります。
5. 「ここの分岐、失敗した場合の行き先がないですね」と指摘して、元の文章に戻る。文章の抜けを図で見つけたという体験をさせる。
6. 図を直させ、その修正を元の手順書にも反映させる。

5が実演の山場です。 図が綺麗に出ることではなく、抜けが見つかることを見せてください。

サンプル問題

自分の手元にある「手順が書かれた文章」を1つ選んで、次をやってください。

1. Mermaidのフローチャートにさせる
2. 図を見て、おかしいところ・抜けているところを自分で探す
3. AIにも「この図の中で、行き先が定義されていない分岐、到達できない要素」を挙げさせる
4. 見つかった抜けを、元の文章にも反映する

文章では気づかなかった抜けが、いくつ見つかりましたか？

社労士での活かし方

• 障害年金の請求フロー（初診日の特定 → 書類収集 → 作成 → 提出 → 決定 → 不服申立て）を図にする
• 顧客説明用に、「あなたの場合はこのルートです」と示す図を作る
• 事務所内の業務フロー図

顧客説明用の図が特に強力です。障害年金の手続きは、文章で説明されても顧客には分かりません。図で「今ここです」と示せると、問い合わせが減ります。

さらに、判断分岐を図にすると、自分の理解の曖昧さが露出します。 「この条件に当てはまらない場合はどうなるんだっけ」が出てきたら、それは調べるべきことです（項目18へ）。

医学部生での活かし方

• 疾患の病態生理をフローチャートにする
• 鑑別診断のアルゴリズムを図にする
• 代謝経路・シグナル伝達の関係図

病態生理の図は、暗記ではなく理解につながります。「Aが起きるとBが起き、その結果Cになる」を図にすると、記憶に残ります。

ただし、AIが作った医学的な図は必ず教科書・ガイドラインと突き合わせてください。 因果関係が単純化されすぎたり、間違っていたりします。図は自分の理解の整理に使い、正しさの根拠にはしない。

システムエンジニアでの活かし方

• 処理フロー、状態遷移図
• システム間の連携シーケンス図
• 障害発生時の時系列図
• データの流れ（どこからどこへ、何が渡るか）

SEには、「仕様書を図にして、矛盾を探す」という使い方が一番刺さります。「この状態からこの状態への遷移が定義されていない」は、レビューでの重要指摘そのものです。

障害報告書の時系列図も強力です。「いつ何が起きたか」を図にすると、報告書の説得力が変わります。

そのまま使えるプロンプト

以下の内容を、Mermaid記法の図にしてください。

【図にするもの】
（ここに資料の内容を貼るか、フォルダーの資料を指定）

【図の種類】
（フローチャート／シーケンス図／時系列 のいずれか。迷ったら提案してください）

条件：
- 元の資料に書かれている内容だけで作ってください
- 資料に書かれていない分岐・手順を推測で補わないでください
- 補わないと図がつながらない箇所は、図の中に「※資料に記載なし」と明示してください

図を出したあと、次を報告してください。
1. 行き先が定義されていない分岐
2. どこからも到達できない要素
3. 元資料が曖昧で、図にする時に判断に迷った箇所

最後の3項目が本命です。 図を描かせることより、この報告が価値です。

組み合わせるとよいフレームワーク

Edge cases — 図に現れない例外。

Edge cases. このフローがうまく当てはまらない例外ケースを挙げ、
それぞれの対処方法も出してください。
図に追加すべき分岐があれば、その形も提案してください。

Misread test — 図の誤読。

Misread test. この図について、読み手が誤解しそうな箇所を探してください。
該当箇所、誤解される可能性、修正案を出してください。
特に、矢印の向き、条件の書き方、並列と順次の区別を見てください。

失敗しやすい使い方

• 図が出たことに満足して、中身を検査しない。 図の価値は検査にあります。
• AIに分岐を推測で埋めさせる。 「※資料に記載なし」の指示を必ず入れる。
• 図が大きくなりすぎる。 30要素を超えたら分割する。読めない図は無意味です。
• 医学的・法的な因果関係の図を、そのまま正しいと信じる。 必ず一次資料で確認。
• 図だけを渡して説明した気になる。 図には注釈が必要です。

最後の確認

• 図を目で追って、全部の線をたどる。 行き止まりがないか。
• 「行き先が定義されていない分岐」の報告を必ず読む。
• 元資料と突き合わせて、資料にない要素が図に混ざっていないか確認する。
• 顧客・患者・チームに見せる図は、専門家（自分）が中身を保証してから出す。

到達目標

• 文章資料をフローチャート・シーケンス図にできる。
• 「行き先のない分岐」「到達できない要素」を報告させられる。
• 図を検査の道具として使える。

自分専用の管理画面

この項目で教えたいこと

成果物が「文書」を超えて「画面」になる。

一覧表、進捗管理、チェック状況。これをHTMLの1ファイルにして、ブラウザで開けるようにします。ExcelでもWordでもない、自分専用の小さな画面です。

教えたいのは、「アプリが作れる」ではありません。「自分の仕事の形に合わせた道具が、その場で作れる」という感覚です。

講師の考え方を反映した説明

「Excelで管理表を作りますよね。 でも、Excelって、見るために開くには重いし、人に渡すと崩れる。

ここでは、HTMLファイルを1個作ります。 ダブルクリックしたらブラウザで開いて、案件の一覧が出て、絞り込みができて、 チェックを付けられる。

これ、自分の仕事の形に合わせて作れます。 既製品に自分を合わせるんじゃなくて、自分に道具を合わせる。

難しいことはしません。『こういう画面が欲しい』と言うだけです。」

そして、必ず制約を伝えます。

「ただし、これは自分用の小さな道具です。 顧客データを入れるものではありません。チームで共有して更新するものでもありません。 見て把握するための画面、と割り切ってください。」

普通のチャットだけの場合との違い

チャットでは、HTMLのコードがテキストで出てくるだけでした。それをどうすればいいか分からず、そのままでした。

Workでは、ファイルとして出てきて、ダウンロードして開けます。 そして、Projectに置いた資料の中身をそのまま画面に流し込めます。ここが決定的に違います。

研修での実演

1. 項目07で作ったファイル一覧、または項目13で作ったチェックリストを使う。
2. 「これを、ブラウザで開ける1ファイルのHTML管理画面にして」と頼む（プロンプトは下記）。
3. ダウンロードして、ダブルクリックで開く。 ここで受講者がざわつきます。
4. 絞り込み、並び替え、チェックを実際に操作してみせる。
5. 「じゃあ、期限が近いものを赤くして」と追加で言う。その場で作り直されて、また開く。
6. 「これは自分用です」と制約を言って締める。

3と5が実演の山場です。 特に5の「言うだけで変わる」を見せてください。

サンプル問題

自分の管理したいものを1つ選んで、HTML管理画面を作ってください。

例：案件一覧／課題一覧／勉強の進捗／読むべき資料の一覧

1. 一覧が表示される
2. 絞り込みか並び替えができる
3. 状態（未着手／進行中／完了）が色で分かる
4. 1ファイルだけで動く（他のファイルを必要としない）

作ったら開いて、自分が毎日見たいと思うかを確認してください。 思わないなら、何が足りませんか？

社労士での活かし方

• 案件進捗ボード（顧客ID・請求種別・現在の工程・次のアクション・期限）
• 書類の受領チェック画面（項目13のチェックリストを画面化）
• 期限管理画面（提出期限が近い順に赤くなる）

期限管理画面が一番実用的です。障害年金は期限のある手続きが多く、Excelで管理していると開かなくなります。ブラウザで常に開いておけるのが強みです。

ただし、顧客の氏名・生年月日・基礎年金番号は入れないでください。 案件IDと工程だけで管理する。中身が必要な時は、自分の手元の資料を見る。この運用にすれば、ファイルが流出しても被害が限定されます（項目28）。

医学部生での活かし方

• 試験勉強の進捗画面（科目・範囲・理解度・最終確認日）
• 講義資料の既読管理
• 過去問の正答率ダッシュボード

理解度を色で表示する画面が効きます。赤（分かっていない）が並んでいるのを毎日見ると、動きます。

項目09で作った「分野 × 正答率」の集計をそのまま画面にすると、弱点が視覚化されます。

システムエンジニアでの活かし方

• タスクボード（項目25のIssue風タスクをそのまま画面に）
• 確認事項・質問事項の管理画面（回答待ちが分かる）
• リリースチェック画面

SEには「作れるのは知っているが、作る時間がなかったもの」として響きます。5分でできるのがポイントです。

そのまま使えるプロンプト

次の内容を管理するための、自分専用のHTML管理画面を作ってください。

【管理したいもの】
【表示したい項目】（列）
【欲しい操作】
- （例）状態での絞り込み
- （例）期限順の並び替え
- （例）チェックを付けられる

【見た目の条件】
- 期限が近いもの、未対応のものが色で分かる
- 1画面で全体が把握できる

【技術条件】
- HTML1ファイルだけで動作すること（外部ファイルを読み込まない）
- ブラウザでダブルクリックして開けること
- スマホでも見られるように、画面幅に合わせて崩れないこと
- データは、ファイル内に直接書き込む形にしてください

【データ】
（ここに一覧を貼るか、フォルダーの資料を指定）

注意：個人情報は入れません。IDと状態だけで管理します。

組み合わせるとよいフレームワーク

Make it actionable — 画面が行動につながるか。

Make it actionable. この管理画面を見た私が、明日すぐ実行できる手順、
準備物、チェックリストが分かるようにしてください。
画面上で「次にやること」が分かる表示を提案してください。

Smoke test — 画面が最低限使えるか。

この管理画面をスモークテストしてください。細かい改善ではなく、
最低限使えるかを確認してください。必須情報の抜け、矛盾、
日付・件名の不整合、操作の分かりにくさ、
私が次に何をすればよいかが分かるかを確認してください。

失敗しやすい使い方

• 凝りすぎる。 5分で作れるものが価値です。1日かけたら本末転倒。
• 個人情報を入れる。 HTMLファイルは平文です。顧客名・患者情報は絶対に入れない。
• チームで共有して更新しようとする。 更新がバラバラになります。それは別の道具の仕事です。
• 作ったきり開かない。 毎日開かない画面は、作った意味がありません。開く習慣とセットで作る。
• 外部ファイルを読み込む作りにする。 ダブルクリックで動かなくなります。1ファイル完結を必ず指定。

最後の確認

• 実際に開いて、全部の操作を触る。 絞り込み、並び替え、チェック。
• スマホでも開いてみる。
• 個人情報が入っていないか、ファイルを開いて中身を検索する。
• 1週間後にまだ開いているか。開いていなければ、作り直すか捨てる。

到達目標

• 自分の管理したいものを、1ファイルのHTML画面にできる。
• 「1ファイル完結」「個人情報を入れない」を指定できる。
• 作った画面を実際に毎日開いている。

GitHub Issue風タスク分解

この項目で教えたいこと

大きい仕事を、着手できる大きさに割る。

GitHubを使わなくても構いません。Issue風の形だけを借ります。1つのタスクが、次の要素を持つ形です。

• タイトル（動詞で終わる）
• やること（本文）
• 完了条件（どうなったら終わりか）
• 依存（何が終わってから着手できるか）
• 見積もり

この形にすると、「なんとなく大きい仕事」が「今日やる1個」になります。

講師の考え方を反映した説明

「『Aさんの障害年金の請求をやる』 これ、タスクですか。タスクじゃないです。プロジェクトです。

こういうのを抱えていると、着手できません。大きすぎるから。

だから割ります。GitHubのIssueみたいな形に。

GitHubを使わなくていいです。形だけ借ります。 大事なのは、1個が今日終わるサイズになっているかです。

そして必ず完了条件を書く。 『診断書を依頼する』じゃなくて、『診断書の依頼書を医療機関に送付し、送付日を記録する』。 どうなったら終わりかが書いてないタスクは、終わりません。」

普通のチャットだけの場合との違い

チャットで「タスクに分けて」と言うと、箇条書きが出ます。でも、粒度がバラバラで、依存関係もなく、完了条件もありません。

形式を指定することで、使えるタスクになります。そして、Projectに資料が置いてあるので、実際の資料に基づいたタスクが出ます。一般論の「要件定義をする」ではなく、「この仕様書の第3章の曖昧箇所5点を、先方に質問する」が出ます。

研修での実演

1. 受講者に「今抱えている一番大きい仕事」を1つ言わせる。
2. まず「タスクに分けて」とだけ言う。粒度バラバラの箇条書きが出るのを見せる。
3. 次に、Issue形式を指定して投げ直す（プロンプトは下記）。
4. 出てきたタスクを見て、「これ、今日終わりますか？」と1個ずつ聞く。終わらないものは、さらに割らせる。
5. 依存関係を出させて、今日着手できるものだけを抜き出す。
6. 「今日やるのはこれです」と1個を指差して終わる。

6が実演のゴールです。 分解が目的ではなく、今日の1個を決めるのが目的です。

サンプル問題

今抱えている一番大きい仕事を1つ選んで、Issue形式に分解してください。

各タスクに必ず含めるもの： - タイトル（動詞で終わる） - やること - 完了条件（何を見たら完了と言えるか） - 依存（何が終わってから着手できるか） - 見積もり時間

そのうえで： 1. 半日で終わらないタスクを、さらに割ってください 2. 今日すぐ着手できるタスクを1つ選んでください

それは何ですか？今日やりますか？

社労士での活かし方

「Aさんの障害基礎年金の請求」を分解します。

#1 初診日を特定する
  やること：ヒアリング記録と受診歴から初診日候補を洗い出し、証明可能性を判定
  完了条件：初診日候補と、それぞれの証明方法をまとめた表ができている
  依存：なし
  見積もり：2時間

#2 受診状況等証明書の取得を医療機関に依頼する
  完了条件：依頼書を送付し、送付日と担当者名を記録済み
  依存：#1

#3 診断書の作成を主治医に依頼する
  完了条件：依頼書・記載要領を渡し、回収予定日を確認済み
  依存：#1

依存関係を出すと、「#1が終わらないと何も進まない」ことが見えます。これが分解の価値です。

医学部生での活かし方

「循環器の試験対策」を分解します。

#1 試験範囲を確定する
  完了条件：シラバスと講義資料を突き合わせ、範囲の一覧表ができている
  見積もり：1時間

#2 過去問を解いて、弱点分野を特定する
  完了条件：分野別の正答率表ができ、正答率60%未満の分野が抽出されている
  依存：#1

#3 弱点分野のまとめノートを作る
  完了条件：抽出された分野それぞれについて、A4 1枚のまとめができている
  依存：#2

「勉強する」を「◯◯ができている」に変えるのがポイントです。学習は完了条件が曖昧になりがちなので、この効果が大きい。

システムエンジニアでの活かし方

本来のIssueそのものなので、一番自然に使えます。

#1 仕様書第3章の曖昧箇所を洗い出す
  完了条件：曖昧箇所の一覧と、先方への質問文ができている
  見積もり：3時間

#2 既存テーブル定義と新規要件の差分を整理する
  完了条件：追加・変更が必要なカラムの一覧ができている
  依存：#1

さらに、出てきたタスクをそのままIssue管理ツールに貼れる形式（Markdown）で出させると、転記の手間もなくなります。

そのまま使えるプロンプト

次の仕事を、GitHubのIssueのような形式でタスクに分解してください。

【仕事の内容】
（ここに書く。フォルダーの資料を参照してよい）

【分解の条件】
- 1タスクは、半日（4時間）以内で終わるサイズにしてください
- 各タスクに次を必ず含めてください
  - タイトル（動詞で終わる。例：「〜を作成する」「〜を確認する」）
  - やること（3行以内）
  - 完了条件（何を見たら完了と言えるか。具体物で書く）
  - 依存（先に終わっている必要があるタスク番号）
  - 見積もり時間
- 資料に書かれていない前提で作ったタスクには「※前提要確認」と付けてください

【出してほしい追加情報】
1. 依存関係の図（Mermaidのフローチャート）
2. 今日すぐ着手できるタスク（依存がないもの）
3. このタスク一覧で抜けている可能性がある作業

組み合わせるとよいフレームワーク

Make it actionable — この項目の主役。

Make it actionable. このタスク一覧を、明日すぐ実行できる手順、
準備物、チェックリストにしてください。
今日着手する1つを選んで、その最初の30分で何をするかまで書いてください。

What am I missing? — 抜けているタスク。

What am I missing? このタスク一覧で見落としている作業、確認事項、リスク、
準備物を挙げてください。
特に、他人・他部署・外部機関に依頼が必要で、待ち時間が発生するものを
優先して挙げてください。

Edge cases — 想定どおりに進まないケース。

Edge cases. このタスク計画がうまく進まない例外ケース
（依頼先から返答が来ない、資料が揃わない、前提が覆るなど）を挙げ、
それぞれの対処方法も出してください。

失敗しやすい使い方

• 完了条件を書かせない。 タスクが終わりません。最重要。
• 粒度がバラバラのまま使う。 「半日以内」を必ず指定し、超えるものは割り直す。
• 依存関係を出させない。 待ち時間のあるタスク（他人への依頼）を後回しにして詰みます。
• 分解して満足する。 分解は手段です。今日の1個を決めるまでやる。
• AIが推測で作ったタスクを、自分の案件の実態だと思い込む。 「※前提要確認」を必ず出させる。

最後の確認

• 全タスクに完了条件があるか目視する。 抜けているものは書き直す。
• 依頼・待ちが発生するタスクを最優先に並べ替える。 これは人間の判断です。
• 「今日着手する1つ」を決めて、実際に着手する。
• 1週間後に見直して、粒度が適切だったか振り返る。

到達目標

• 大きい仕事をIssue形式に分解できる。
• 全タスクに完了条件を書かせられる。
• 分解の最後に「今日の1個」を決められる。

段階的な自動化チェーン

この項目で教えたいこと

割ったタスクを、つなげる。 ただし、一気につながない。

「資料を読む → 要点を出す → 表にする → チェックリストにする → 報告文にする」。この流れを1回のプロンプトでやらせると、途中で崩れます。

だから、1段階ずつ確定させながらつなぐ。 これが「段階的」の意味です。

講師の考え方を反映した説明

「ここまでやってきたことを、並べてみてください。 読ませて、表にして、比べて、チェックリストにして、報告文にした。

これ、毎回同じ順番でやってませんか。

だったら、つなげます。 ただし、一気につなぐと事故ります。

1段階目が間違っていたら、2段階目以降は全部間違ったまま進みます。 しかも、それらしい顔をして出てきます。

だから、1段階ずつ確定させます。 『ステップ1が終わったら、私に確認を取ってからステップ2に進んでください』 この一言を、必ず入れてください。

人間が確認するポイントを、チェーンの中に埋め込むんです。」

これが項目29（Human-in-the-loop）の入口にもなっています。

普通のチャットだけの場合との違い

チャットでは、毎回ゼロから指示していました。同じ作業を来月もやるとき、また同じことを打ちます。

チェーンにすると、手順が固定されます。 手順が固定されると、品質が安定します。そして、固定された手順は、次の項目27でSkillにできます。

チェーン → Skill、という流れで教えてください。 ここが研修終盤の設計です。

研修での実演

1. ここまでの研修でやった作業を、ホワイトボードに並べる。「読む → 表にする → チェックする → 報告文」。
2. 「これ、毎回やってますよね」と確認する。
3. わざと一気に投げる。 全部を1つのプロンプトに書いて実行する。
4. 出てきたものを検査する。途中で品質が落ちていることを見せる（後半ほど雑になります）。
5. 次に、段階分けして、各段階で確認を取る形で実行する。
6. 2つの結果を比べる。
7. 「この形、毎回使いますよね」と言って、項目27のSkillに接続する。

7の伏線が重要です。 ここでSkillの話を「ちらつかせる」だけにして、次の項目で回収します。

サンプル問題

自分が繰り返しやっている作業を1つ選んで、3〜5段階のチェーンにしてください。

1. 各段階の「入力」と「出力」を書く
2. 各段階の後に、人間が確認するポイントを1つずつ決める
3. 実際に、1段階ずつ確認しながら通す

どの段階で、一番修正が必要でしたか？ そこが、あなたの作業で一番人間の判断が必要な場所です。

社労士での活かし方

障害年金の請求書類作成チェーン：

ステップ1：受領書類の一覧化と不備チェック（項目07・13）
  → 人間確認：不備の判定が妥当か

ステップ2：診断書と申立書の整合確認（項目12）
  → 人間確認：初診日・傷病名・時系列の一致を目視

ステップ3：申立書ドラフトの作成（項目20）
  → 人間確認：事実に基づいているか。盛っていないか

ステップ4：提出前チェックリストの適用（項目13）
  → 人間確認：全項目を自分で判定

ステップ5：顧客への説明文の作成（項目21）
  → 人間確認：Misread test の結果を確認

ステップ2と3の後の人間確認は、絶対に省略できません。 ここを飛ばす運用は作らないでください。

医学部生での活かし方

試験対策チェーン：

ステップ1：講義資料の一覧化と範囲の確定（項目07）
  → 人間確認：範囲が合っているか（シラバスと照合）

ステップ2：範囲ごとの要点整理（項目08）
  → 人間確認：教科書と食い違っていないか

ステップ3：過去問の正答率集計と弱点抽出（項目09）
  → 人間確認：集計が合っているか

ステップ4：弱点分野のまとめノート作成（項目20）
  → 人間確認：一次資料と突き合わせ

ステップ5：確認問題の作成と自己採点（項目19の応用）
  → 人間確認：解説が正しいか

ステップ2と4の後の一次資料確認は必須です。 医学情報は、AIの出力をそのまま覚えると危険です。

システムエンジニアでの活かし方

仕様理解から着手までのチェーン：

ステップ1：受領資料の一覧化（項目07）
  → 人間確認：資料の抜けがないか

ステップ2：仕様書の要約と曖昧箇所の抽出（項目08）
  → 人間確認：曖昧箇所の判定が妥当か

ステップ3：既存仕様との差分整理（項目12）
  → 人間確認：破壊的変更の判定を目視

ステップ4：タスク分解（項目25）
  → 人間確認：粒度と依存関係

ステップ5：確認事項の質問票作成（項目21）
  → 人間確認：先方に出せる文面か

そのまま使えるプロンプト

これから、複数のステップからなる作業をお願いします。
ただし、一度に全部やらないでください。

【全体の流れ】
ステップ1：（　　　）
ステップ2：（　　　）
ステップ3：（　　　）
ステップ4：（　　　）

【進め方のルール】
- 1つのステップが終わったら、そこで止まってください
- 止まったら、次を報告してください
  1. そのステップの成果物
  2. 判断に迷った点
  3. 私に確認してほしいこと
- 私が「次へ」と言うまで、次のステップに進まないでください
- 前のステップの成果物を、次のステップで勝手に修正しないでください

では、ステップ1から始めてください。

「私が『次へ』と言うまで進まないでください」 — この1行が、この項目の核心です。

組み合わせるとよいフレームワーク

Edge cases — チェーンが途中で壊れるケース。

Edge cases. このチェーンがうまく機能しない例外ケース
（入力データの形式が違う、前のステップの出力が不完全、想定外の内容が含まれるなど）を挙げ、
それぞれの対処方法も出してください。

Smoke test — チェーン全体が成立しているか。

このチェーン全体をスモークテストしてください。細かい改善ではなく、
最低限使えるかを確認してください。ステップ間の受け渡しの抜け、矛盾、
実行順序、人間が確認すべき点がどこかを確認してください。

What am I missing? — チェーン設計時に。

What am I missing? この作業チェーンで見落としているステップ、確認事項、
リスク、準備物を挙げてください。
特に、人間が確認しないと危険な箇所を優先して挙げてください。

失敗しやすい使い方

• 一気に全部投げる。 後半の品質が落ちます。しかも気づきません。
• 人間確認ポイントを決めない。 チェーンの意味の半分がなくなります。
• 途中の成果物を確認せずに次へ進む。 1段階目の誤りが最後まで残ります。
• チェーンが長すぎる。 5段階までを目安に。長いなら分ける。
• 前段階の成果物を、次の段階で勝手に直される。 「修正しないでください」を必ず入れる。

最後の確認

• 各段階の成果物を、それぞれ保存する。 後から「どこで間違えたか」を追えるように。
• 人間確認ポイントで、実際に止まって確認したかを振り返る。「次へ」を連打していないか。
• チェーン全体を通した後、最初の入力と最後の出力を突き合わせる。 途中で意味が変わっていないか。

到達目標

• 自分の繰り返し作業を3〜5段階のチェーンにできる。
• 各段階の後に人間確認ポイントを埋め込める。
• 「私が次へと言うまで進まないでください」を書ける。

Skill creator

この項目で教えたいこと

「これ、毎回やってますよね」

この一言のために、ここまでの26項目があります。

Skillは、繰り返し使う指示のかたまりを、名前を付けて保存しておく仕組みです。呼び出せば、毎回同じ手順で同じ品質の作業をします。

この項目は、絶対に最初にやらないでください。 さんざん手作業をさせた後だから効きます。

講師の考え方を反映した説明

研修のこの時点で、こう言います。

「今日、何回同じことをしましたか。

資料を読ませて、要点を出させて、表にして、チェックリストにして。 毎回、同じプロンプトを打ってましたよね。

それ、保存できます。

名前を付けて、『◯◯やって』と言えば、その手順で動きます。 今日皆さんが打っていたプロンプトが、そのままSkillの中身になります。

だから、最初にこれを教えなかったんです。 中身がない状態でSkillを作っても、何を保存すればいいか分からないから。」

そして、Skillにすべきものの判定基準を1つだけ教えます。

「3回やったら、Skillにする。」

1回では分からない。2回では偶然かもしれない。3回やったら、それは定型作業です。

普通のチャットだけの場合との違い

チャットでは、良いプロンプトを作っても、次の日には見つかりません。メモ帳に貼っておいた人もいるでしょうが、探すのが面倒で結局打ち直していました。

Skillにすると、呼び出すだけになります。しかも、手順が固定されるので、忙しい日でも品質が落ちません。 ここが本当の価値です。疲れている時ほど効きます。

研修での実演

1. 今日の研修で受講者が実際に打ったプロンプトを、画面に並べる。
2. 「同じものを何回打ちましたか」と聞く。
3. その中から1つ選んで、Skillにする過程を見せる。 - 名前を決める - いつ使うかを書く - 手順を書く - 入力に必要なものを書く - 出力の形を書く
4. 実際に呼び出して動かす。
5. 動かした結果を見て、足りない指示を追加して更新する。 1回で完成しないことを見せる。
6. 「最初に教えなかった理由が分かりましたか」と聞いて締める。

5が重要です。 Skillは育てるもので、一発で完成しません。

サンプル問題

今日の研修で3回以上使ったプロンプトを1つ選んで、Skillにしてください。

Skillに書くもの： 1. 名前（何をするものか一目で分かる名前） 2. いつ使うか（どういう時に呼び出すか） 3. 手順（ステップごとに） 4. 必要な入力（呼び出す時に渡すもの） 5. 出力の形 6. やってはいけないこと（推測禁止、個人情報の扱いなど）

作ったら、実際に呼び出して1回動かしてください。 足りなかった指示は何でしたか？

社労士での活かし方

Skillにすべきもの：

• 受領書類チェック：書類一式を渡すと、不備一覧を出す
• 申立書ドラフト生成：ヒアリング内容を渡すと、決まった構成で下書きを作る
• 顧客説明文の生成：制度名と顧客の状況を渡すと、専門用語を使わない説明文を作る

受領書類チェックが一番効きます。 案件ごとに毎回やる作業で、抜けが許されない作業だからです。

Skillに必ず書く「やってはいけないこと」：

- 等級の判定・見込みを述べないこと
- 資料に書かれていない事実を推測で補わないこと
- 制度の数値・要件は、必ず「公式で要確認」と付記すること
- 顧客の氏名・生年月日・基礎年金番号を出力に含めないこと

医学部生での活かし方

Skillにすべきもの：

• 講義資料まとめ：スライドを渡すと、決まった形式（結論→理由→試験で問われる形）でまとめる
• 確認問題生成：範囲を渡すと、10問＋解説を作る
• 論文要約：論文を渡すと、目的・方法・結果・限界の形で要約する

「やってはいけないこと」：

- 治療方針・薬剤量について、必ず「最新のガイドライン・添付文書で確認」と付記すること
- 実在が確認できない文献を挙げないこと
- 患者情報を含む内容は扱わないこと

システムエンジニアでの活かし方

Skillにすべきもの：

• 仕様書レビュー：仕様書を渡すと、曖昧箇所・矛盾・抜けを決まった形式で出す
• 障害報告書生成：時系列メモを渡すと、決まった章立てで報告書を作る
• タスク分解：機能要件を渡すと、Issue形式に分解する

「やってはいけないこと」：

- 確定していない原因を断定的に書かないこと
- 動作確認していないコードに、確認済みと書かないこと
- 顧客名・システム名・接続情報を出力に含めないこと

そのまま使えるプロンプト

Skillの中身をAIに作らせるプロンプトです。

これから、私が繰り返し使っている作業をSkillにしたいです。
以下は、私が実際に使っているプロンプトと、その使い方です。

【実際に使っているプロンプト】
（ここに貼る）

【この作業をする場面】
（ここに書く）

【うまくいかなかったこと・毎回追加で指示していること】
（ここに書く）

これをもとに、Skillの中身を作ってください。次を含めてください。

1. 名前（何をするものか一目で分かる短い名前）
2. 使う場面（どういう時に呼び出すか。判定できる書き方で）
3. 必要な入力（呼び出す時に渡すもの。不足している場合はどうするか）
4. 手順（ステップごと。人間の確認が必要な箇所を明記）
5. 出力の形（項目・順序・形式を固定）
6. やってはいけないこと（推測禁止、個人情報、断定表現など）
7. 最後の確認（人間が確認すべきこと）

条件：
- 曖昧な表現（適切に、必要に応じて）は使わないでください
- 私が毎回追加で指示していることは、必ずSkillの中に組み込んでください

組み合わせるとよいフレームワーク

Fill the gaps — Skillの穴を埋める。

Fill the gaps. このSkillを完成させるために足りない情報を1問ずつ質問してください。
各質問に、なぜ必要か、推奨回答例も付けてください。最大5問でお願いします。

Smoke test — Skillが動く状態か。

このSkillをスモークテストしてください。細かい改善ではなく、
最低限使えるかを確認してください。入力が不足した場合の動作、手順の抜け、
出力形式の矛盾、人間が確認すべき点が明記されているかを確認してください。

Grill me — Skillの設計を叩く。

Grill me. このSkillについて、弱い点、想定外の入力で壊れる点、
指示が曖昧で解釈が分かれる点を厳しめに指摘してください。
最後に改善優先度を付けてください。

失敗しやすい使い方

• やる前にSkillを作る。 中身がないSkillができます。3回やってから。
• 一発で完成させようとする。 使いながら育てるものです。
• 「やってはいけないこと」を書かない。 ここが抜けたSkillは、事故を量産します。
• 人間の確認ポイントを書かない。 自動化したつもりが、確認なしで流れます。
• 個人情報の扱いを書かない。 Skillは繰り返し使われるので、穴があると繰り返し事故ります。
• Skillを作りすぎる。 使わないSkillが並ぶと、探せなくなります。

最後の確認

• 実際に1回呼び出して動かす。 動かないSkillは作った意味がありません。
• 入力が足りない状態で呼び出してみる。きちんと質問してくるかを確認する。
• 「やってはいけないこと」が守られているか、出力を見て確認する。
• 1か月使って、追加した指示があればSkillに反映する。

到達目標

• 3回やった作業をSkillにできる。
• Skillに「やってはいけないこと」と「人間の確認ポイント」を書ける。
• Skillは育てるものだと理解している。

個人情報・機密情報・入れてはいけない情報

この項目で教えたいこと

入れてはいけないものを、入れない。

この研修で一番時間を取るべき項目です。受講者3人は、全員「入れてはいけないもの」を日常的に扱っています。

そして、ここで教えたいのは知識ではなく、手が止まる感覚です。「あ、これ入れる前に確認しよう」と一瞬止まる。それが身につけば成功です。

講師の考え方を反映した説明

「便利になりました。だから、ここからが本番です。

皆さんが扱っているもの、思い出してください。

妹は、顧客の病名と生活状況を扱っています。 姪は、患者さんの症例に触れます。 私は、顧客のシステムの中身を見ています。

全部、入れてはいけない可能性があるものです。

大事なのは『絶対に使うな』じゃありません。 『入れる前に、一瞬止まる』ことです。

止まって、3つ考えてください。 1. これは、誰のものか 2. 漏れたら、誰が困るか 3. 入れなくても、この作業はできないか

3が一番大事です。 名前を消しても作業できるなら、消してから入れる。」

普通のチャットだけの場合との違い

チャットでも同じリスクはありました。違うのは、Workでは資料をまとめて置くので、量が増えることです。1ファイルなら気づくものが、20ファイルまとめて入れると見落とします。

さらに、貼り紙（項目05）に書いた情報は全会話に流れます。 便利さと引き換えに、影響範囲が広がります。ここを正直に伝えてください。

研修での実演

1. わざと危ない資料を用意する（架空の顧客名・生年月日・基礎年金番号が入った書類の見本）。
2. 「これを入れます」と言って、手を止める。 「待って。何が入ってますか」と受講者に聞く。
3. 入っている情報を1つずつ挙げさせる。
4. 「この作業に、名前は必要ですか」と聞く。必要ないことに気づかせる。
5. マスキングした版を作って、それを入れる。作業が問題なくできることを見せる。
6. 「これが習慣です」と締める。

4が実演の核心です。 「入れないとできない」と思い込んでいることが、実はほとんど不要だと気づかせます。

サンプル問題

自分が普段扱っている資料を1つ思い浮かべて、次に答えてください。

1. その資料に入っている情報を、種類ごとに全部挙げる
2. そのうち、AIに入れなくても作業ができるものに印を付ける
3. 印を付けたものを消した「マスキング版」の作り方を決める
4. 自分のルールを3行で書く（何は入れない、何は加工して入れる、何は入れてよい）

書いた3行を、他の受講者に読み上げてください。

社労士での活かし方

絶対に入れない： 氏名、生年月日、住所、基礎年金番号、マイナンバー、健康保険証番号、電話番号、家族の氏名、勤務先名、医療機関名と担当医師名の組み合わせ。

加工して入れる： 病名・症状・生活状況（→ 個人が特定できない形に。氏名は「A様」、日付は「初診日から◯年後」など相対表現に）。

入れてよい： 制度の一般的な内容、様式の記入方法、文章表現の相談。

社労士としての注意： 社会保険労務士法上の守秘義務、および個人情報保護法上の義務があります。事務所として、AIに何を入れてよいかの規程を文書で作ってから運用してください。 「なんとなく気をつける」では、事故が起きた時に説明できません。

顧客への説明も検討事項です。業務でAIを使うことを、契約書や重要事項説明でどう扱うか。これは研修で結論を出さなくてよいですが、宿題として持ち帰らせてください。

医学部生での活かし方

絶対に入れない： 患者の氏名、ID、生年月日、入院日、検査日、住所、勤務先、家族構成、症例の詳細（組み合わせると特定できる）、実習先で見聞きしたこと。

医学生には、これを強調してください。

「症例は、名前を消しても特定されます。 珍しい疾患、特徴的な経過、日付、施設名。組み合わせると、その人だと分かります。 実習で見た症例は、AIに入れない。 これは徹底してください。」

入れてよい： 教科書的な内容、公開されているガイドライン、講義資料（大学の規定を確認したうえで）、自分のノート。

大学の規定を必ず確認することも伝えてください。生成AIの利用について、大学がルールを定めている場合があります。

システムエンジニアでの活かし方

絶対に入れない： 接続情報（ホスト名、ID、パスワード、APIキー、証明書）、本番データ、顧客の実データ、顧客名・システム名が特定できる情報、契約上の秘密情報、他社から預かったソースコード。

加工して入れる： コード（変数名・ホスト名を汎用化）、ログ（IPアドレス・個人情報をマスク）、設計書（固有名詞を伏せる）。

SEへの注意： 契約・NDAで生成AIの利用が制限されている場合があります。 技術的にできるかではなく、契約上できるかを先に確認する。ここは特に強く言ってください。

さらに実務的な注意：APIキーを1回でも入れたら、そのキーは廃棄して作り直す。 「入れちゃったけど大丈夫かな」ではなく、機械的にローテーションする。これを習慣にしてください。

そのまま使えるプロンプト

入れる前のセルフチェックに使います。この確認自体には、本物の情報を貼らないでください。

これからAIに渡そうとしている資料の「種類」を説明します。
実際の中身は貼りません。

【資料の種類】（例：障害年金の診断書の写し）
【私の立場】（例：社会保険労務士）
【やりたい作業】（例：記載漏れのチェック）

次を出してください。
1. この種類の資料に通常含まれる、機微な情報の一覧
2. そのうち、上記の作業には不要な情報（＝消してよいもの）
3. 消した場合に作業が成立しなくなる情報と、その代替手段
   （例：氏名を「A様」に置換、実日付を相対日数に変換）
4. この資料を扱う際に、私の立場で確認すべき法令・規程・契約上の論点
5. マスキング手順のチェックリスト

組み合わせるとよいフレームワーク

Edge cases — 想定外の漏れ方。

Edge cases. このマスキングルールがうまく当てはまらないケース
（氏名を消しても特定できてしまう、画像に情報が残る、ファイル名に個人名が入っている、
ファイルのプロパティに作成者名が残っているなど）を挙げ、
それぞれの対処方法も出してください。

What am I missing? — ルールの抜け。

What am I missing? この情報の取り扱いルールで見落としている情報、確認事項、
リスク、準備物を挙げてください。
特に、法令・所属組織の規程・契約の観点で確認すべきことを優先してください。

Sanity check — ルールの妥当性。

Sanity check. この情報取り扱いルールに、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。
厳しすぎて業務が回らない箇所、逆に緩すぎる箇所の両方を指摘してください。

失敗しやすい使い方

• ファイル名に個人名が入っている。 中身をマスキングしても、ファイル名で漏れます。盲点です。
• 画像の隅に情報が写っている。 診断書の写真の端、スクショの通知バー、ブラウザのタブ名。
• ファイルのプロパティに作成者名・組織名が残っている。 WordやExcelでよくあります。
• 「これくらいなら」と例外を作る。 例外は増えます。ルールは1つにする。
• 急いでいる時に確認を飛ばす。 事故はここで起きます。急いでいる時ほど止まる。
• 一度入れたものは取り消せないと理解していない。入れる前が全てです。

最後の確認

• 入れる前に、ファイル名を見る。
• 画像は、隅から隅まで見る。
• 資料のプロパティ（作成者、会社名）を確認する。
• 自分のルール3行を、毎回思い出す。
• 迷ったら、入れない。 迷った時点で、入れない理由が十分あります。

到達目標

• 自分の分野で「絶対に入れないもの」を即座に列挙できる。
• マスキングして作業する方法を持っている。
• 入れる前に一瞬手が止まる習慣がある。

外部ツール権限設定・承認・Human-in-the-loop

この項目で教えたいこと

AIが「実行できる」範囲を、自分で決める。

読むだけなのか、書き換えられるのか、送信できるのか。ここを理解せずに権限を渡すと、取り返しがつかないことが起きます。

そして、この研修全体を貫く合言葉の後半、「ただし人間が確認する」を、仕組みとして教える項目です。気合いではなく、手順に埋め込みます。

講師の考え方を反映した説明

「ここまでは、AIが作ったものを人間が見て、人間が実行していました。 安全です。間に人間がいるから。

権限を渡すと、AIが直接実行できるようになります。便利です。 でも、間に人間がいなくなります。

だから、順番を守ってください。

1. まず読むだけ（Read）で使う 2. 慣れたら、書き込みを許可する。ただし承認を必須にする 3. 承認なしの自動実行は、取り返しがつく操作だけ

そして、取り返しがつかない操作には、絶対に権限を渡さないでください。 送信、削除、支払い、提出。この4つは人間がボタンを押す。」

そして、Human-in-the-loopの正しい形を教えます。

「『確認しますか？』と聞かれて『はい』を押すのは、確認ではありません。

確認とは、何が起きるかを読んで、判断することです。 だから、AIには『実行前に、何をするかを具体的に列挙してから聞いてください』と言います。 列挙されたものを読んでから、はいを押す。 これが確認です。」

普通のチャットだけの場合との違い

チャットでは、AIは提案するだけでした。実行するのは人間です。安全でしたが、手間もかかりました。

権限を渡すと、手間が減ります。同時に、間違いも自動で実行されます。 このトレードオフを、正直に説明してください。「便利になります」だけで終わらせないこと。

研修での実演

1. 権限設定の画面を開いて、「読み取り」と「書き込み」の違いを指差して見せる。
2. 読み取りだけの状態で、何ができて何ができないかを実際に試す。
3. 書き込み権限を付けて、承認を求められる場面を見せる。
4. 承認画面を、声に出して読み上げる。 「今、何をしようとしているか」を全員で読む。
5. わざと「望ましくない操作」を承認画面まで持っていき、そこで却下する。 却下できることを見せる。
6. 権限を外すところまで見せる。

5が実演の山場です。 「止められる」という体験が、安心して使うために必要です。

サンプル問題

自分が使っている（または使いたい）外部連携について、次を整理してください。

操作	取り返しがつくか	AIに任せてよいか	承認が必要か
読み取り
新規作成
更新・上書き
削除
送信・提出

そのうえで、「絶対にAIに任せない操作」を3つ決めて、書き出してください。

社労士での活かし方

絶対に人間が実行する： 電子申請の提出、顧客へのメール送信、書類の郵送、料金の請求。

読み取りだけなら検討可： 様式・参考資料の参照、自分のメモの読み取り。

障害年金の請求書類の提出は、一度提出すると取り消せません。 ここは絶対に人間がボタンを押す。研修で明言してください。

Human-in-the-loopの型：

「提出用の書類一式を準備してください。ただし、提出は行わないでください。 提出前に、次を一覧で報告してください：提出する書類名、宛先、記載した内容の要点、 私が最終確認すべき箇所。私が確認した後、提出は私が行います。」

医学部生での活かし方

学生が権限を渡す場面は多くありませんが、カレンダー、メール、クラウドストレージで発生します。

絶対に人間が実行する： 教員・実習先へのメール送信、提出物のアップロード、履修登録。

特にメールの自動送信は設定しないでください。 相手が教員・医療機関なので、誤送信の影響が大きすぎます。

そして、医学生には将来を見据えてこう言っておいてください。

「臨床の場では、AIの出力をそのまま実行することは絶対にありません。 必ず指導医の確認を経る。今のうちから、その順番を体に入れておいてください。」

システムエンジニアでの活かし方

SEが一番リスクの高い領域です。

絶対に権限を渡さない： 本番環境への接続、デプロイ、DBの更新・削除、課金が発生する操作、顧客への送信。

承認付きで検討可： 開発環境でのファイル操作、課題管理ツールへのコメント追加、ドキュメントの下書き作成。

読み取りのみなら比較的安全： ドキュメント参照、コードの読み取り（契約上問題なければ）。

実務的な鉄則：

「取り返しがつく操作か」で線を引く。 ファイルの新規作成は取り返しがつく。上書きは条件付き。削除はつかない。 削除と送信とデプロイは、人間が押す。

さらに、操作ログを残す設定にしておくこと。何が実行されたか後から追えないと、事故の調査ができません。

そのまま使えるプロンプト

権限を渡す前の設計

外部ツールとの連携で、AIに操作権限を渡すか検討しています。

【ツール】
【そこで行いたい操作】
【私の立場・扱う情報】

次を出してください。
1. その操作を「取り返しがつく／条件付き／取り返しがつかない」に分類
2. 読み取りのみで実現できる範囲はどこまでか
3. 承認を必須にすべき操作
4. 絶対に権限を渡すべきでない操作と、その理由
5. 権限を渡す場合に、事前に設定・記録しておくべきこと
6. 事故が起きた場合に備えて、準備しておくべきこと

実行させる時（Human-in-the-loopの型）

この作業を進めてください。ただし、次のルールを厳守してください。

- 外部への送信、ファイルの上書き・削除、提出、購入に該当する操作は
  絶対に実行しないでください
- それらが必要になった時点で止まり、次を報告してください
  1. これから何をしようとしているか（対象・件数・内容を具体的に）
  2. 実行した場合に元に戻せるか
  3. 私が確認すべき点
- 私が明示的に「実行してよい」と言うまで、実行しないでください
- 実行してよいと言っていない操作を「ついでに」実行しないでください

「ついでに実行しない」 — この一言を入れてください。

組み合わせるとよいフレームワーク

Edge cases — 承認の網をすり抜けるケース。

Edge cases. この承認ルールがうまく当てはまらないケース
（複数の操作がまとめて実行される、間接的に外部へ影響が出る、
承認済みの操作が繰り返し実行されるなど）を挙げ、
それぞれの対処方法も出してください。

Smoke test — 承認の仕組みが機能するか。

この権限・承認の設計をスモークテストしてください。細かい改善ではなく、
最低限安全に使えるかを確認してください。承認なしで実行されうる操作、
取り返しのつかない操作の扱い、人間が確認すべき点が明確かを確認してください。

What am I missing? — 設計の抜け。

What am I missing? この権限設定の計画で見落としているリスク、確認事項、
準備物を挙げてください。
特に、事故が起きた後の対応（気づく方法、戻す方法、報告先）について
準備が足りていない点を指摘してください。

失敗しやすい使い方

• とりあえず全権限を渡す。 最悪です。読み取りから始める。
• 承認画面を読まずに「はい」を押す。 承認の意味がなくなります。
• 「ついでに」実行される操作に気づかない。 明示的に禁止する。
• 削除・送信・提出の権限を渡す。 これは人間の仕事です。
• ログを残さない。 何が起きたか分からなくなります。
• 一度設定した権限を見直さない。 定期的に棚卸しする。
• 組織のルールを確認せずに設定する。 事務所規程、大学規定、契約・NDA。

最後の確認

• 今、どのツールにどの権限を渡しているか、全部言えるか。 言えないものは外す。
• 承認画面が出た時、書いてある内容を最後まで読んだか。
• 取り返しのつかない操作を、自分の手で実行したか。
• 実行された操作のログを、定期的に見返す。
• 迷ったら、権限を渡さない。

到達目標

• 読み取り／書き込み／実行の違いを説明できる。
• 「取り返しがつくか」で権限の線を引ける。
• 承認は読んでから押す、が習慣になっている。

モデル選択・利用枠確認

この項目で教えたいこと

明日から自分で回せるようにする。

研修中は講師の環境で動きます。受講者が自分で使い始めたとき、最初に詰まるのがここです。「重い作業をしたら止まった」「なんか答えが雑になった」。

足回りを整えて、研修を終わります。

講師の考え方を反映した説明

「最後は地味な話です。でも、これを知らないと明日詰まります。

1. モデルは、作業によって使い分ける。 速いモデルと、じっくり考えるモデルがあります。 要約や整理は速いモデル。判断や設計はじっくり考えるモデル。 迷ったら、重要な作業ほど、じっくり考えるほうを選ぶ。

2. 利用枠には上限がある。 使いすぎると制限がかかります。だから、重い作業は、枠に余裕がある時にやる。

3. 答えが急に雑になったら、疑う。 モデルが変わっているか、会話が長くなりすぎているか。 長くなった会話は、新しい会話に移す。 これは項目06のセッション分けと同じ話です。」

そして、締めの一言を用意しておいてください。

「今日教えたことは、全部道具の話です。 道具が使えるようになっても、判断するのは皆さんです。 最後はAIにチェックさせる。ただし人間が確認する。 これだけ覚えて帰ってください。」

普通のチャットだけの場合との違い

チャットしか使っていない人は、モデルを意識していません。デフォルトのまま使っています。

Workで重い作業をするようになると、選択が結果を変えます。 100ページのPDFを読ませる時と、メールの一文を直す時では、必要なものが違います。

研修での実演

1. モデル選択の画面を開いて、選べるものを見せる。
2. 同じ質問を、速いモデルとじっくり考えるモデルの両方に投げる。時間と内容の違いを見せる。
3. 利用状況・残り枠が確認できる場所を見せる。
4. 長くなった会話で、出力が雑になる例を見せる（研修中に長くなった会話があれば、それを使う）。
5. その会話の要点だけを持って、新しい会話を立てる。回復するのを見せる。
6. 「困ったら、新しい会話。これが一番効きます」と締める。

サンプル問題

自分の環境で、次を確認してください。

1. 選べるモデルは何があるか。それぞれ、どういう作業向きと書かれているか
2. 自分の利用枠と、現在の使用状況はどこで見られるか
3. 同じ質問を2つのモデルに投げて、違いを確認する

そのうえで、自分の作業を3つ挙げて、それぞれどちらのモデルを使うか決めてください。

社労士での活かし方

• じっくり考えるモデル： 認定基準の解釈、申立書の構成検討、複雑な事例の整理、複数資料の突き合わせ
• 速いモデル： 文章の推敲、書類一覧の作成、メール文の下書き、用語の言い換え

判断が絡むものは、じっくり考えるほう。 障害年金は判断の積み重ねなので、重要な局面ではケチらないでください。

利用枠については、繁忙期（決算期、算定基礎の時期）に枠を使い切らないよう、計画的に。重い調査は余裕のある時期に。

医学部生での活かし方

• じっくり考えるモデル： 病態生理の理解、鑑別診断の整理、論文の批判的吟味、難しい概念の説明
• 速いモデル： 用語の確認、まとめノートの整形、暗記カードの作成、スケジュール調整

試験直前に枠を使い切らないでください。 一番使いたい時に使えなくなります。日常的に少しずつ使い、直前は仕上げに集中する配分を。

システムエンジニアでの活かし方

• じっくり考えるモデル： 設計の検討、複雑なコードの読解、障害原因の分析、トレードオフの整理
• 速いモデル： コードの整形、ドキュメントの下書き、コマンドの確認、命名の相談

障害対応中は、じっくり考えるモデル。 速さより正確さが要る場面です。

そして、長時間の作業では会話を分ける。 項目06のセッション分けは、品質面だけでなく、この意味でも効きます。

そのまま使えるプロンプト

作業に応じた選択をAIに相談するプロンプトです。

これから行う作業について、どの設定で進めるべきか相談させてください。

【作業内容】
【扱うデータ量】（例：100ページのPDF 3本）
【求める精度】（例：顧客に出す資料なので高精度が必要）
【締め切り】

次を教えてください。
1. この作業は、速度重視と精度重視のどちらが向いているか
2. 一度にやるべきか、分割すべきか。分割するならどう分けるか
3. 会話を分けるべきポイント
4. 途中で出力の質が落ちた場合の対処法

会話が長くなった時の引き継ぎプロンプトも用意しておくと便利です。

この会話が長くなってきたので、新しい会話に移ります。
引き継ぎのために、次をまとめてください。

1. これまでに確定した事実・決定事項
2. 現在の成果物の状態
3. 未解決の課題と、次にやること
4. 新しい会話の冒頭に貼るべき前提情報

新しい会話にそのまま貼れる形で出力してください。

この引き継ぎプロンプトは、実務で一番使うかもしれません。 研修の配布物に必ず入れてください。

組み合わせるとよいフレームワーク

Sanity check — 出力の質が落ちていないかの確認。

Sanity check. この会話のこれまでの内容に、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。
特に、会話の前半と後半で言っていることが食い違っている箇所を指摘してください。

Make it actionable — 明日からの運用に落とす。

Make it actionable. 私の作業内容をもとに、モデルの使い分けと会話の分け方について、
明日すぐ実行できる運用ルール、準備物、チェックリストにしてください。

失敗しやすい使い方

• 常にデフォルトのまま使う。 重要な判断も、速いモデルでやってしまいます。
• 長い会話を延々と続ける。 品質が落ちます。分ける。
• 枠を使い切ってから慌てる。 締め切り前に限って起きます。
• 出力が雑になったことに気づかない。 「なんか違う」と思ったら、まず新しい会話に移す。
• モデルの違いを試さない。 一度比べれば分かります。研修で必ず1回やらせる。

最後の確認

• 重要な成果物を作った時、どの設定で作ったかを覚えているか。
• 出力が雑になったと感じたら、新しい会話でやり直す。
• 締め切り前に、利用状況を確認する。
• 最後は人間が確認する。 どのモデルを使っても、これは変わりません。

到達目標

• 作業に応じてモデルを選べる。
• 利用枠の確認場所を知っている。
• 長くなった会話を、引き継いで新しい会話に移せる。

研修の締め：8つのフレームワークの使い分け

30項目を通して、8つのフレームワークが何度も出てきました。最後に、成果物を出す前の型として1枚にまとめます。

成果物の段階別・フレームワーク適用表

研修の最後にやること：フルコース

受講者が今日作った成果物を1つ選び、この順で全部かけます。

【1】Grill me. この成果物について、弱い点、反論されそうな点、説明不足、
確認不足を厳しめに指摘してください。最後に改善優先度を付けてください。

【2】Sanity check. この内容に、常識的な矛盾、前提ミス、抜け、
読んだときの違和感がないか確認してください。

【3】What am I missing? この計画で見落としている情報、確認事項、リスク、
準備物を挙げてください。

【4】Edge cases. この手順や説明がうまく当てはまらない例外ケースを挙げ、
それぞれの対処方法も出してください。

【5】Misread test. この文章について、読み手が誤解しそうな表現を探してください。
該当箇所、誤解される可能性、修正案を出してください。

【6】Fill the gaps. この成果物を完成させるために足りない情報を1問ずつ質問してください。
各質問に、なぜ必要か、推奨回答例も付けてください。最大5問でお願いします。

【7】Make it actionable. この内容を、明日すぐ実行できる手順、準備物、
チェックリストにしてください。

【8】この成果物をスモークテストしてください。細かい改善ではなく、
最低限使えるかを確認してください。必須情報の抜け、矛盾、日付・金額・名前・リンクの不整合、
実行順序、読み手が次に何をすればよいか、人間が確認すべき点を確認してください。

実演のポイント： 8つ全部かけると、指摘が大量に出ます。受講者は圧倒されます。そこでこう言ってください。

「全部直す必要はありません。 どれを直して、どれを直さないかを決めるのが、皆さんの仕事です。

AIは指摘します。判断はしません。 最後はAIにチェックさせる。ただし人間が確認する。 今日、これだけ持って帰ってください。」

研修後の1週間の宿題

最後の確認表

講師へ：この教材を使う前に確認してほしいこと

1. 機能名は、研修当日の画面で最終確認してください。 ChatGPTの機能名・画面構成は更新が速く、この教材の表記と実際のUIがずれる可能性があります。教材の中身（何を見せるか、何を腹落ちさせるか）は変わりませんが、ボタンの名前は当日の画面が正です。
2. 第0幕で使うPDFは、事前に3人分用意してください。 受講者本人に選ばせると、当日「手元にない」で崩れます。
3. 項目28（個人情報）だけは、時間が押しても削らないでください。 ここを削ると、研修そのものがリスクになります。
4. 各項目の実演は、対比を見せる構造になっています。 片方だけ見せると効果が半減します。時間がない項目は、実演ごと飛ばすほうがましです。