長期インターンの大学生が書く日報を週ごとに要約し、取り組み・つまずき・評価の手がかりを、受け入れ部署には毎週、採用担当には使ってよい範囲でだけ渡す

処理の起点を決める

毎週金曜の17時に、タイマーで動かします。 日報は毎日届きますが、要約は1週間分をまとめて作ります。1日ごとに要約すると、月曜のつまずきが火曜に解けたかどうかを、同じ要約の中で確かめられません。

金曜の17時にしているのは、メンターが週末の前に読み、月曜の1on1に間に合わせるためです。 金曜に勤務の無い学生は、その週の最後の勤務日までの日報で作ります。

もう1つの起点は、メンターの交代です。 採用担当がメンターを付け替えたときに、その学生の配属からの「未解決」の履歴と直近4週の要約を、新しいメンターに1回だけ届けます。 過去の日報を数十日分さかのぼって読む代わりです。

入力データを集める

質を決めるのは、いちばん下の配属の目標です。 目標が無いと、要約は日報の「今日やったこと」を並べ直すだけになります。目標があれば、「目標のうち、今週どれに取り組んだか」と書けます。

前の週の「未解決」を入れるのは、つまずきを週で区切らないためです。 先週の金曜に未解決だったものが、今週の日報で解けたと書かれていれば「解決」、何も書かれていなければ「2週続けて記載なし」として先頭に出します。

学生IDで渡し、氏名と大学名はAIに渡しません。 要約に氏名は要りません。メンターへ届けるときに、プログラムの側で学生IDを氏名に戻します。

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

日報は、フォームの回答が保存される SharePoint のリストから、Microsoft Graph の API で読む構成を想定します。

プログラムの区分は、学生ごとに採用担当が入力します。 入力する値は、「作らない」「作る（期間：〇月〇日〜）」の2つだけにし、作ってよいかの判断の根拠（どのタイプの取組として整理したか、募集要項に何を書いたか）は、採用担当が別の欄に書きます。

区分の判断を、この構成の中で自動化しません。 「基本的考え方」は、タイプ3の要件として、実施期間の半分を超える日数を職場での就業体験に充てること、職場の社員が指導しフィードバックを行うこと、汎用的能力活用型は5日間以上・専門活用型は2週間以上の期間、学部3・4年ないし修士1・2年の長期休暇期間に実施すること、募集要項等に、採用活動開始以降に限り学生情報を活用する旨などを記載して公表することを挙げています。学期中に週2〜3日働く長期インターンが、これらに当たるかはプログラムごとに確かめるもので、日報からは決まりません。

AIへ渡す前に整形する

1. 日報の集約 … 学生ごとに、その週の日報を日付の順に並べます。勤務の無い日は空にせず、「勤務なし」と明示します
2. 未解決の持ち越し … 前の週の要約から「未解決」の項目を取り、最初に書かれた日付とともに入力に足します
3. 要約に入れない記載の印付け … 体調、通院、家庭の事情、学業の成績や履修の事情に関する語の一覧で日報を見て、該当する文に印を付け、AIへ渡す前に「（個人的な事情の記載あり）」に置き換えます。 置き換えたことはメンター向けの要約に1行だけ出します
4. 氏名・大学名の置き換え … 学生IDに置き換えます。日報の中の他の社員の氏名も役割名（メンター、チームリーダー）に置き換えます
5. 区分の判定 … プログラムの区分の設定を引き、その週が「作ってよい期間」に入っているかを判定します。入っていなければ、採用担当向けの欄を作らない指示に切り替えます
6. 日報の欠けの確認 … 勤務の日なのに日報が無い日を数えます。2日以上欠けている週は、要約の冒頭に出し、メンターに声かけを促します

3番目は、学生を守るための前処理です。 日報の「困ったこと」には、「体調が悪く集中できなかった」「試験が近くて時間が取れない」と書かれることがあります。こうした記載は、メンターが直接本人と話すべきことで、要約の材料にも、採用担当の記録にも入れません。 置き換えたことだけを伝え、メンターが元の日報を開いて読むかを決めます。

AIに処理させる

させるのは、1週間分の日報を、決まった4つの欄に分けて要約し、各項目に根拠の日報の日付と文を付けることだけです。

2つ目の欄が、この要約の主役です。 「解けた記載の有無」は、後の日付の日報に、そのつまずきが解けた・分かったと書かれているかで決めます。書かれていなければ、解けていても「解けた記載なし」です。推測で「解決したと思われる」と書かせません。

2行目は、日報の長さの違いへの対処です。 たくさん書く学生ほど取り組みも観察も多く出ます。書く量の差を、仕事ぶりの差として読ませないために、比較を一切させません。

指示内容を固定する

あなたは、長期インターンの学生を受け入れる部署のメンターを手伝う立場です。
1人の学生の1週間分の日報を、決まった4つの欄に要約してください。

【4つの欄】
1. 取り組んだこと：配属の目標のどれに取り組んだか。目標に当たらないものは「その他」
2. 未解決のつまずき：日報に書かれたつまずきのうち、後の日付の日報に
   「解けた」「分かった」等の記載が無いもの。前の週からの持ち越しを含める
3. 次の週に確かめたいこと：2の項目と「明日やること」から、メンターが確かめるとよい点
4. 観察の記録：日報に書かれた具体的な行動。日付と、日報の文をそのまま引用する

【厳守事項】
- 各項目に、根拠にした日報の日付を付ける。引用は日報の文をそのまま写す。
- 日報に書かれていないことを書かない。「〜と思われる」「〜だろう」と推測しない。
- 解けた記載が無いつまずきは、解けたかどうか分からなくても「未解決」に入れる。
- 学生の能力、性格、適性、意欲を評価する言葉（優秀、積極的、向いている等）を書かない。
- 点数、順位、他の学生との比較を書かない。
- 「（個人的な事情の記載あり）」の部分に触れない。内容を推測しない。
- 学生への振り返りのコメントを書かない。
- recruiter_view_allowed が false のときは、recruiter_notes を空の配列にする。

【配属の目標】{goals}
【前の週の未解決】{carry_over}
【今週の日報】{reports}
【採用担当向けの記録】recruiter_view_allowed = {allowed}

「評価する言葉を書かない」を明記しないと、要約の最後に「積極的に取り組んでいる様子がうかがえます」と足します。 この1文は、日報のどこにも根拠がありません。禁じるのは、日報の文の外で学生を形容することそのものです。

recruiter_view_allowed を指示に入れているのは、二重の守りです。 本来は区分が false の学生について、プログラムの側で採用担当向けの欄を捨てます。指示でも空にさせておけば、プログラムの不具合が1件あっても、採用担当に渡る文そのものがありません。

出力形式を固定する

構造化出力で、次の形に固定します。 公式のページでは、構造化出力は指定した JSON スキーマに従わせる機能で、Chat Completions API では response_format、Responses API では text.format でスキーマを定義し、すべての項目を必須にし、オブジェクトには additionalProperties: false を設定するとされています。

{
  "student_id": "",
  "week": "2026-W41",
  "worked_on": [ { "goal": "", "summary": "", "dates": [""] } ],
  "unresolved": [
    { "issue": "", "first_reported": "", "quote": "", "weeks_open": 1 }
  ],
  "resolved_this_week": [ { "issue": "", "resolved_on": "", "quote": "" } ],
  "check_next_week": [ { "point": "", "based_on": [""] } ],
  "observations": [ { "date": "", "quote": "" } ],
  "recruiter_notes": [ { "date": "", "quote": "" } ],
  "masked_personal_notes": 0,
  "missing_report_days": 0
}

1つ目の理由は、quote をプログラムで照合できることです。 引用が、その日付の日報の文にそのまま含まれるかを確かめ、含まれない項目は要約から外し、外したことをメンター向けの要約に1行出します。 言い換えられた引用は、観察の記録になりません。

2つ目は、unresolved の weeks_open で、持ち越しの長さが見えることです。 2週以上続く未解決は、メンター向けの通知の先頭に出します。

3つ目は、recruiter_notes を観察の記録と別の配列にしていることです。 採用担当向けに渡すのはこの配列だけで、メンター向けの「未解決」や「次に確かめたいこと」は採用担当に渡しません。 つまずきは指導のための情報で、評価の材料ではないからです。

システムへ連携する

採用管理のシステムへは書き込みません。 採用担当の一覧は、採用担当が月に1回メンターと話して確定するための下書きの置き場です。確定した記録だけを、採用担当が手で採用管理のシステムに移します。

日報のリストは読み取りだけです。要約の誤りに気づいても、日報は直しません。 日報は学生が書いたもので、要約の側を直します。

人が確認する

メンターは、毎週の要約を必ず読みます。 そのうえで、次の4つを行います。

1. 未解決のつまずきを、月曜の1on1で本人に確かめる … 解けていれば次の週の日報に書いてもらいます。「解けた」と書く習慣が付くと、要約の精度が上がります
2. 「個人的な事情の記載あり」の学生は、元の日報を開いて読む … 声をかけるかを、メンターが決めます
3. 振り返りの文を自分の言葉で書いて返す … 要約は材料で、文はメンターが書きます
4. 要約の誤りを報告する … 日報に無いことが書かれていた、引用がずれていた場合に、採用担当へ知らせます

採用担当は、月に1回、採用担当の一覧をメンターと読み合わせます。 観察の記録のうち、記録として残すものをメンターと決め、残さないものは一覧から消します。

目標は、100件をならして1件9分です。 メンターが要約を読み、1on1で聞くことを決め、振り返りを書く時間です。未解決が多い週や、個人的な事情の記載がある週は9分を超えます。

例外に対処する

6行目は、要約の仕組みの外で扱います。 ハラスメントや体調の悪化をうかがわせる記載は、要約を待たずに人が対応すべきものです。 語の一覧で印が付いたものは、要約の有無にかかわらず、その日のうちにメンターと採用担当に知らせる設定にしておきます。

記録を残す

• 学生ごと・週ごとの入力（置き換え後の日報、前の週の未解決、目標）と、AIの出力のJSON
• 引用の照合の結果と、外した項目
• その週のプログラムの区分と、採用担当向けの記録を作ったかどうか
• メンターに届けた日時と、メンターが報告した要約の誤り
• 採用担当の一覧に入れた recruiter_notes と、月1回の読み合わせで残したもの・消したもの
• 置き換えた個人的な事情の記載の件数（中身は残さない）

3つ目を残すのは、学生情報を使った範囲を後から説明できるようにするためです。 どの週の、どの学生について、どの区分のもとで採用担当向けの記録を作ったかが、週ごとに分かるようにしておきます。 学生本人から「自分の日報がどう使われたか」を尋ねられたときにも、この記録で答えます。