上司が1on1のたびに残すメモを要約して部下ごとの話題・困りごと・約束の記録にし、次の1on1の前に前回からの続きを確かめる

処理の起点を決める

起点は2つあります。 1つは、上司が1on1のメモをフォームから送ったとき。もう1つは、毎朝7時の定時の処理で、カレンダーで翌日に1on1の予定がある部下を探したときです。

1つ目は、1on1の直後に動かします。 記憶が新しいうちに要約を見れば、「これは部下が言ったこと」「これは決まっていない」と直すのに1分もかかりません。1週間後に要約を見ても、何が正しいかを上司自身が思い出せません。

2つ目を前日の朝にしているのは、当日の朝では間に合わないことがあるためです。 上司の約束が終わっていないと分かったとき、前日なら1on1までに片づけられます。 当日の直前に知っても、「まだです」と言うしかありません。

メモを送らなかった1on1も拾います。カレンダーに1on1の予定があったのに、その日のうちにフォームの送信が無ければ、翌朝に上司へ「メモが未送信」と知らせます。 記録が抜けると、次の一枚に前回の続きが出ません。

入力データを集める

質を決めるのは、2つ目です。 終わっていない約束を一緒に渡さないと、今回のメモの「資料送った」が、どの約束の完了なのかを照らせません。 約束の一覧が積み上がっていくことが、この構成のいちばんの価値です。

話題の区分は、細かくしすぎないでください。 区分が10を超えると、同じ話題が回ごとに違う区分に入り、部下ごとの話題の推移が読めなくなります。 5つ前後にして、迷ったら「その他」に入れさせます。

「健康・家庭」の区分は、あえて作りません。 そうした話題は、区分ではなく「慎重に扱う話題」の印で扱います（後述）。

データの取得方法を決める

フォームの回答は、フォームに紐づけたスプレッドシートに1行ずつ入ります。Google Apps Script は、送信された行から部下の名前を取り、記録の約束の一覧から、その部下の終わっていない約束を取り出します。

部下の名前は、フォームの選択肢から選ばせます。 自由に入力させると、「田中」「田中さん」「たなか」で別の人の記録になります。選択肢は、上司ごとの部下の一覧から作ります。

前回より前のメモ全文は渡しません。 渡すのは、終わっていない約束と前回の次回の続きだけです。半年分のメモを毎回渡すと、昔の話題を今回の話題として要約に混ぜます。 推移は記録の側で見ます。

AIへ渡す前に整形する

1. メモが空でないかの確認 … メモが数文字しかないときは、要約せずに「メモが短い」と上司に返します
2. 部下の名前の確認 … 選択肢にない名前、異動した部下の名前のときは止めます
3. 同じ1on1の二重送信の確認 … 同じ部下・同じ日付の送信が2回あれば、2回目を追記として扱います
4. 部下以外の個人名の扱い … メモに出てくる他の社員の名前は、そのまま渡します。伏せ字にすると、誰との関係の話かが分からなくなるためです。その代わり、記録は上司本人しか開けない設定にします
5. 約束の一覧の上限 … 終わっていない約束が20件を超える部下は、古いものから上司に整理を促し、渡すのは新しい20件にします

4番目は迷うところです。 伏せ字にすれば外部へ渡す情報は減りますが、「Aさんとのレビューのやり方が合わない」の「Aさん」が消えると、要約は「同僚との関係」としか書けません。 次の1on1で上司が思い出す手がかりが無くなります。本記事では、記録へのアクセスを絞ることで扱い、名前は残す設計にしています。

5番目の上限を超える部下がいたら、それ自体が知らせです。 約束が片づかないまま積み上がっているということで、要約の工夫より、約束の仕方を見直したほうが早く終わります。

AIに処理させる

させるのは、走り書きを決まった欄に分けることと、終わっていない約束との照合だけです。

右端の列が大事です。 分からないものを分からないと返させます。走り書きを補って「それらしい要約」にされると、上司自身が自分のメモと違う記憶を持つことになります。

1行目と2行目がいちばん起きやすい失敗です。 「最近 残業多め 眠い」というメモを渡すと、何も言わなければ「負荷が高く、疲労が見られる」と書きます。それはメモではなく、AIの解釈です。 記録に残るのは「残業が多いと話した」までにします。

指示内容を固定する

あなたは上司が書いた1on1のメモを、上司自身が次の1on1で使う記録に
整理する担当です。メモに書かれていることだけを整理してください。
書かれていないことを補ったり、解釈したりしないでください。

【分ける欄】
話題（区分は【話題の区分】から選ぶ）／困りごと／約束／決まったこと／次回の続き

【厳守事項】
- 約束は「誰が」「何を」「いつまでに」に分け、owner を manager（上司）
  か member（部下）にしてください。どちらか分からなければ unknown に
  してください。期日が書かれていなければ空にしてください。
- 話しただけか決まったことか分からない記載は、決まったことに入れず、
  status を「検討中」にしてください。
- 部下の評価、意欲・能力・適性の判断、気持ちや体調の推測を書かないで
  ください。「疲れているようだ」「前向きだ」のような言葉を使わないで
  ください。メモの言葉をできるだけそのまま使ってください。
- 健康状態、病気、通院、家族の事情、ハラスメントの申告と読める記載は、
  中身を要約に書かず、sensitive_topics に「話題の種類」だけを入れて
  ください（例：「体調について」）。
- 【終わっていない約束】のうち、今回のメモで終わったとはっきり読める
  ものだけを completion_candidates に入れ、根拠にしたメモの文を写して
  ください。確かでなければ入れないでください。
- 上司への助言や、次に聞くべきことの提案を書かないでください。
  次回の続きは、メモに「次回」「続き」「また聞く」などと書かれたものだけ
  にしてください。

【今回のメモ】{memo}
【終わっていない約束】{open_promises}
【前回の次回の続き】{last_followups}
【話題の区分】{topic_categories}

「メモの言葉をできるだけそのまま使う」を入れないと、要約が上司の言葉でなくなります。 上司が自分で書いた走り書きなので、本人が読んで思い出せる言葉であることが、整ったきれいな文より大事です。

健康や家庭の扱いを明記するのは、何も言わなければ親切に整理して書くからです。 「通院のため木曜は早退したい」を、そのまま「困りごと」に1行で書きます。記録の一覧で他の話題と並ぶと、上司以外が見たときの影響が大きくなります。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "member": "",
  "date": "",
  "topics": [ { "category": "", "summary": "" } ],
  "concerns": [ { "text": "", "speaker": "member | manager | unknown" } ],
  "promises": [
    { "owner": "manager | member | unknown", "what": "", "due": "", "source": "" }
  ],
  "decisions": [ { "text": "", "status": "決定 | 検討中" } ],
  "next_followups": [],
  "completion_candidates": [ { "promise_id": "", "evidence": "" } ],
  "sensitive_topics": []
}

1つ目の理由は、約束を一覧に機械的に積み上げられることです。 promises の1件ずつを約束の一覧の1行にし、状態を「未完了」で始めます。上司が完了を確定するまで、次の1on1の前日の一枚に出続けます。

2つ目は、owner で上司の約束を先に並べられることです。 前日の一枚は、次の並びで作ります。

6行目は、日付だけを出します。 一枚はメールで届くので、中身はメールに載せず、上司が記録のファイルの原文を開いて見ます。

3つ目は、completion_candidates で「終わった」をAIに確定させずに済むことです。 候補として上司に見せ、上司がチェックを入れたものだけを完了にします。evidence に根拠の文を写させるので、上司は自分のメモのどの一文で判断されたかを見られます。

半自動化では、このJSONの形を Structured Outputs で固定します。 owner に決めていない値が入らないので、並べ替えが崩れません。ただし、owner が正しく付いているかは別の話で、そこは上司が要約を見るときに直します。

システムへ連携する

人事システムや評価のシステムへは、つなぎません。 1on1の記録を評価の材料にしない運用にするためで、つながっていなければ、使われる心配も、使われていると思われる心配もありません。

送り先は上司本人だけです。 部下の側へ要約を送る機能は、この構成には入れません。部下に共有するかどうかは、上司が要約を見たうえで決めることにします。

人が確認する

上司が確かめるのは、次の4つです。 1on1の直後に、要約を見て直します。

1. 約束の owner … 誰の約束かが逆になっていないか。ここが逆だと、前日の一枚で上司の約束が後ろに回ります
2. 決まったことと検討中 … 話しただけのことが「決定」になっていないか
3. 完了の候補 … 本当に終わったか。部下が受け取ったかまで確かめてからチェックを入れます
4. 評価や推測の言葉が入っていないか … 「前向き」「疲れている」のような言葉があれば、メモの言葉に戻します

4番目を省かないでください。 指示文で禁じていても、メモの言葉そのものが評価に近いことがあります（「やる気なさそう」と上司が書いた場合）。その場合は要約ではなく、上司のメモの書き方の問題です。人事部の手引で、メモに書かないことを示します。

目標は、1件あたりの上司の作業を5分にすることです。 内訳はフォームへの入力と要約の確認で、前日の一枚を読む時間を含みます。確認を翌日以降に回すと、直すべき箇所を上司自身が思い出せなくなります。 1on1の直後の数分で確かめる運用を、手引に書いておきます。

例外に対処する

5行目は、この構成の外に出すものです。 ハラスメントの申告や不調の訴えは、記録の要約ではなく社内の決まった手順で扱うべき相談です。印を付けるのは、上司が「記録しただけ」で終わらせないためです。

記録を残す

• フォームの回答（メモの原文）と送信日時
• 返ってきたJSONの全文と、上司が直した後の要約
• 約束の一覧（作られた日、期日、完了にした日、完了にした人）
• 上司が要約を直した箇所 … owner の付け替え、決定と検討中の付け替え、言葉の戻し
• 前日の一枚を送った日時と送り先
• sensitive_topics が付いた回の日付（中身は原文にだけ残す）

記録はすべて、上司ごとのファイルに置きます。 人事部が集計で見るのは、1on1の実施回数、メモの未送信の回数、約束の件数と完了までの日数だけです。中身の文は集計に出しません。

上司が要約を直した記録は、指示文を直す材料です。 owner の付け替えが多ければ、メモの書き方（「私：」「本人：」を頭に付ける）を手引で示すほうが効きます。