社員が書いた目標設定シートを、測れる書き方か・期限があるかの観点で校正し、書き直しの例を本人と上司に返す

処理の起点を決める

フォームの送信を起点にします。 回答のスプレッドシートに、フォーム送信時のインストール型トリガーを1つ置きます。提出のたびに1回動き、その1人分を点検します。

毎日まとめて処理する形にはしません。 中途入社の社員は入社した週に目標を書くことが多く、上司との面談の記憶が新しいうちに書き直しの例が届くほうが、出し直しが早く終わります。 1日待つだけで、上司が出張に入って面談が1週間延びることがあります。

出し直しも同じトリガーで受けます。 フォームに「初回の提出／出し直し」の設問を置き、出し直しのときは前の回の点検結果を引いて、直った目標と、まだ直っていない目標を区別して一覧に出します。

送信時のトリガーは、何らかの理由で失敗することがあります。 失敗した実行はメールで通知されますが、取りこぼしを防ぐために、毎朝1回、時間主導型のトリガーで「回答はあるのに点検の一覧に無い」行を探して処理し直します。

入力データを集める

AIに渡すのは、目標の文と、職種・等級と、書き方の基準だけです。 氏名や社員番号は渡しません。目標の文の中に顧客名や案件名が書かれていることがあるため、第13章で扱いを決めます。

書き方の基準のシートが、この構成の質を決めます。 「〜に努める」「〜を強化する」「〜を推進する」「〜に貢献する」のような、期末に判定できない語の一覧と、職種ごとの良い書き方の例を3〜5個ずつ用意します。この一覧は人事の3名で1つにそろえます。 第3章の（a）の、担当者ごとの差をなくすのはこの一覧です。

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

フォーム送信時のトリガーは、イベントの情報として、設問の名前と値の組（namedValues）と、シートに並んだ順の値（values）を渡してきます。 1人分の回答はこれで取れるので、回答のシートを読み直す必要はありません。

社員の一覧は、社員番号で引きます。 氏名で引くと、同姓同名や旧姓で引けない社員が出ます。社員番号が一覧に無い場合は、中途入社の登録がまだ済んでいない可能性が高いので、点検はせずに人事へ知らせます。

AIへ渡す前に整形する

1. 目標の数の確認 … 3〜5個の範囲かを数えます。範囲外なら「目標の数」として一覧に出します
2. ウェイトの合計の確認 … 合計が100％かを計算します。AIには計算させません
3. 期限の日付の確認 … 期限の欄が日付として読めるか、評価期間の中にあるかを確かめます。「期末」「随時」などの文字は、規則で「日付ではない」と印を付けます
4. 空欄の確認 … 「達成の基準」が空の目標は、AIに渡す前に印を付けます
5. あいまいな語の確認 … 基準のシートの語の一覧と照らし、該当する語に印を付けます
6. 固有名の置き換え … 社員の一覧にある氏名と一致する文字列を「（社員）」に置き換えます

2番目と3番目をAIに任せないのが、この構成の決まりです。 ウェイトの合計を生成AIに足させると、まれに合わない計算をします。数えれば分かることを、判断の仕組みに通しません。

5番目の印は、AIの判定と別に持ちます。 一覧の語があっても、文全体として測れる書き方になっていることがあります（「品質を強化するため、障害件数を月〔　〕件以下にする」など）。印があるかどうかと、直すべきかどうかは別で、後者はAIに判定させます。

AIに処理させる

させるのは、目標ごとに4つの観点で判定し、直す理由を書き、書き直しの例を作ることです。

書き直しの例は、元の目標の意図を変えずに、測れる形にした1文です。 数値・日付・割合の具体的な値は「〔　〕」の空欄にし、何を数えるのか（件数か、割合か、日数か）だけを示します。

2行目がいちばん起きやすい失敗です。 「書き直しの例を作って」とだけ頼むと、AIは親切に「前年比110％」「月5件」と具体的な数字を入れます。その数字に根拠はありませんが、例として示されると、本人も上司もそこから話を始めてしまいます。

指示内容を固定する

あなたは人事部で、社員が書いた目標設定シートの「書き方」を点検する立場です。
目標の中身の良し悪しや、水準の高さは判断しません。
期末に本人と上司が「達成したかどうか」を同じ物差しで判断できる書き方に
なっているかだけを見てください。

【入力】
- 職種と等級
- 目標ごとの「目標の内容」「達成の基準」「期限」
- 前処理の結果（期限が日付として読めたか、あいまいな語の印）
- 会社の書き方の基準と、職種ごとの良い書き方の例

【目標ごとに判定する観点】
1. measurable … 達成の基準に、数・割合・回数・日数・完成した状態のどれかがあるか
2. has_deadline … いつまでかが書かれているか
3. own_action … 本人が何をするかが書かれているか
4. vague_words … 期末に判定できない語が、達成の基準の中心になっていないか
それぞれ ok / needs_fix / unclear で答えてください。

【厳守事項】
- 書き直しの例では、数値・日付・割合・件数の具体的な値を書かないでください。
  必ず「〔　〕」の空欄にしてください。何を数えるか（件数、割合など）は書いてください。
- 目標の意図を変えないでください。元の目標にない業務を足さないでください。
- 目標の水準が高い・低いと書かないでください。
- 目標を増やす・減らす・入れ替える提案をしないでください。
- ウェイトの合計や日付の計算はしないでください。前処理の結果を使ってください。
- 本人の能力・姿勢・意欲について書かないでください。
- 直す理由は、どの語・どの欄のどこが問題かを具体的に1〜2文で書いてください。
- すべての観点が ok の目標には、書き直しの例を書かないでください。
- 判断がつかないときは unclear とし、理由に何が分からないかを書いてください。

【職種と等級】{role}
【書き方の基準と良い例】{guideline}
【目標】{goals}
【前処理の結果】{precheck}

「〔　〕の空欄にする」を明記しても、例の中に数字が入ることがあります。 「月〔　〕件以上、うち新規を3社」のように、空欄と数字が混ざる形です。そのためスクリプトの側でも、書き直しの例の中に数字があれば一覧で目立たせます。 指示とスクリプトの両方で止めます。

「すべて ok の目標には例を書かない」も大事です。 書かせると、問題の無い目標まで言い回しを変えた例が返り、本人は「直せと言われた」と受け取ります。 直す必要のない目標には何も返しません。

出力形式を固定する

次の形のJSONで受け取ります。 Responses API の構造化出力で、text.format に json_schema の型、strict を true にしてスキーマを渡します。厳密モードでは、すべてのオブジェクトに additionalProperties: false を付け、すべての欄を required に並べます。

{
  "goals": [
    {
      "goal_index": 1,
      "measurable": "ok | needs_fix | unclear",
      "has_deadline": "ok | needs_fix | unclear",
      "own_action": "ok | needs_fix | unclear",
      "vague_words": "ok | needs_fix | unclear",
      "reason": "",
      "rewrite_example": ""
    }
  ],
  "overall_comment": ""
}

rewrite_example は、すべての観点が ok の目標では空の文字列にします。overall_comment は、本人あてのメールの冒頭に置く1〜2文です。

1つ目の理由は、観点ごとの判定を数えられることです。 「measurable が needs_fix の目標が多い職種」が分かれば、その職種の良い書き方の例を基準のシートに足す、という改善ができます。自由文の講評では数えられません。

2つ目は、rewrite_example を機械的に確かめられることです。 欄が分かれていれば、スクリプトはその欄だけを見て、半角・全角の数字が含まれていないかを確かめられます。

3つ目は、メールの下書きをスクリプトが組み立てられることです。 needs_fix の目標だけを並べ、理由と書き直しの例を差し込みます。文面の型は人事が決め、AIが埋めるのは目標ごとの部分だけです。 担当者ごとに文面の調子が変わることもなくなります。

モデルが要求を断った場合、応答にはスキーマの形ではなく断りの内容が入ります。 スクリプトは応答の中身の種類を見て、断りであれば点検の一覧に「AIの点検なし」として出し、人事の担当者が読みます。

システムへ連携する

UrlFetchApp.fetch() は、method に post、contentType に JSON、headers に API キー、payload に要求の本文を入れて呼びます。muteHttpExceptions を true にすると、失敗の応答でも例外を投げずに応答を返します。 状態コードを見て、翌朝の処理し直しに回すかを決めます。

API キーはコードに書かず、スクリプト プロパティに置きます。 スクリプト プロパティはスクリプトのすべての利用者で共有されます。スクリプトの編集権限は、評価制度の担当者に限ります。

GmailApp.createDraft() は、宛先・件名・本文に加えて、cc や name、replyTo を取ります。cc に上司のアドレスを入れ、replyTo を評価制度の担当の共用アドレスにします。 本人からの質問が、送った担当者個人ではなく共用の窓口に届きます。

人が確認する

人事の担当者が見るのは、点検の一覧の1行と、Gmail の下書きです。 シートの全文を読み直すのは、判定に unclear がある場合だけです。

1. 規則の結果を見る … ウェイトの合計、目標の数、期限の日付。ここで外れていれば、AIの判定より先に本人へ直しを頼みます
2. needs_fix の目標と書き直しの例を読む … 例が元の意図から外れていないか、数字が入っていないかを見ます
3. unclear の目標を読む … 職種によっては、研究開発の目標のように数で表しにくいものがあります。状態で書けば十分な場合は、そのまま通します
4. 下書きを整えて送る … 言い回しを直し、上司との関係で配慮が要るものは一文足します
5. 送ったことを一覧に記録する … 送った日と、直しを頼んだ観点の数を残します

2番目で例を読むのは、意図のずれを見つけるためです。 「新人の育成を担う」を「新人の〔　〕名が独り立ちする」と直すのは書き方の改善ですが、育成の対象が新人だけなのか、チーム全体なのかは、本人にしか分かりません。 人事が見て迷うものは、「例です。意図と違えば上司とご相談ください」と添えます。

目標は、1件あたり5分です。 直しの無いシートは一覧で確かめて受付の下書きを送るだけで、直しのあるシートでも、書き直しの例ができているので書く時間はほとんどかかりません。

例外に対処する

上から2行目までは、社員の一覧の整備の問題です。 中途入社や異動の直後は、人事システムから一覧への反映が遅れることがあります。目標の提出のほうが先に来るので、一覧の更新の頻度を上げるほうが効きます。

記録を残す

• 提出された目標の文（固有名を置き換える前と後）
• 規則の結果（目標の数、ウェイトの合計、期限の日付の判定）と、そのときの評価期間
• AIに渡した要求と、返ってきたJSONの全文
• 人事の担当者が送った文面と、AIの下書きとの違い
• 出し直しの回数と、観点ごとに直ったかどうか
• 職種ごとの、観点別の needs_fix の件数

4つ目は、指示を直す材料になります。 担当者が毎回同じ言い回しを書き換えているなら、その言い回しを文面の型か指示に入れます。

5つ目と6つ目は、制度の側を見直す材料になります。 特定の職種で measurable の needs_fix が続くなら、その職種に合った良い書き方の例が足りていません。書き方の研修や、シートの欄の説明文を直すきっかけになります。

目標設定シートは人事評価に関わる記録です。 点検の一覧とログの閲覧は、評価制度の担当者に限ります。保存の期間は、評価の記録の保存の規程に合わせます。