Claudeで目標設定と評価コメントを下書きする手順 — OKRとMBO

評価シーズンに上司が困るのは、メモはあるのに文章にならないことです。箇条書きの断片から目標記述と評価コメントを起こす作業は、人事評価システムがなくてもClaudeのProjectsだけで進められます。必要なのは、評価基準と過去の目標をまとめたプロジェクトと、書き方を固定する指示文の2つです。ここでは、OKRとMBOのどちらの会社でも使える下書きの手順を扱います。

この方法が向く会社と向かない会社

前提は、目標も評価も社内の表計算やドキュメントで管理していることです。LatticeのようなコネクタでClaudeが自動収集できる環境なら、LatticeとClaudeで人事評価ドラフトと1on1準備を進める方法のほうが手間は少なく済みます。

こちらは手作業版です。材料は自分で用意し、Claudeには文章化と整形だけを任せます。

3つ目は見落としやすい点です。基準がなければClaudeは一般論で埋めるしかなく、自社の等級や職務に合わない文章が出ます。

評価用プロジェクトを作る

Projectsは、独自のチャット履歴とナレッジベースを持つ独立した作業スペースです。無料アカウントを含む全ユーザーが使えます。無料アカウントで作れるプロジェクトは最大5つです。

ナレッジに入れる3種類の資料

プロジェクトのナレッジベースにアップロードした資料は、そのプロジェクト内の全チャットで文脈として使われます。評価用には次の3種類を入れます。

1. 評価基準表: 等級ごとの期待行動、評価の段階(S/A/Bなど)の定義
2. 前期の目標と結果: 部下ごとの目標記述と達成度のメモ
3. 書き方の見本: 自社で「良い」とされた評価コメントを匿名化して数件

見本は数件にとどめます。

ファイル名は内容が分かる形にします。RAGを扱う公式ヘルプでも、わかりやすいファイル名と、関連資料をまとめて置くことが挙がっています。たとえば 評価基準_2026下期.md や 目標_営業チーム_前期.md です。

ナレッジが増えてコンテキストの上限に近づくと、有料プラン(Pro / Max / Team / Enterprise)ではRAGモードに自動で切り替わります。容量は最大10倍に広がりますが、Claudeは全文を読むのでなく検索で必要な箇所を取り出す動きになります。評価基準のように「全文を毎回踏まえてほしい」資料は、検索で一部しか拾われないと基準の一部が抜けた状態で下書きされかねません。量を絞って全文投入の範囲に収めるほうが安全です。RAGモードに入った後も、依頼文でファイル名を指定すれば検索の的を絞れます。ナレッジが減って上限を下回れば、全文投入に戻ることもあります。仕組みの違いはClaude ProjectsのRAG検索の仕組みと全文投入との違いで詳しく扱っています。

プロジェクト指示に書き方を固定する

ナレッジとは別に、プロジェクト指示(Set project instructions)を設定できます。この指示はプロジェクト内の全チャットに効きます。ここに、書式と禁止事項を置きます。

指示文の一例です。自社の制度に合わせて書き換えて使います。

あなたは評価面談の準備を手伝うアシスタントです。
ナレッジの「評価基準」に書かれた等級・段階の定義だけを根拠にします。
基準に無い言葉で能力や人柄を評価しません。
 
目標を書くときは、次の形式で出力します。
- 目標(1文。SMART形式を意識し、期限と数値を入れる)
- 測定方法(何をどう数えるか)
- 前提・依存(他部門や予算の条件)
数値が入力メモに無い場合は、推測せず「要確認」と書きます。
 
評価コメントを書くときは、次の形式で出力します。
- 事実(いつ・何を・どうしたか。メモにある内容のみ)
- 影響(その行動で何が変わったか)
- 次期への期待(1つに絞る)
「積極的」「頑張った」のような形容だけの文は書きません。

この指示の要点は「要確認」の逃げ道です。メモにない数値をClaudeが補うと、もっともらしい評価コメントが事実と乖離します。空欄を空欄のまま返させることで、上司が確認すべき箇所が見えます。

なお、チャット間で文脈は引き継がれません。あるチャットで決めたことは、ナレッジや指示に書き込まない限り別のチャットには届きません。決めた運用ルールは指示文に追記します。

目標設定: 箇条書きメモをSMART形式に直す

上司が書いたメモを、そのままチャットに貼ります。整っていなくて構いません。

対象: 営業2課 佐藤さん(仮名)
メモ:
- 新規開拓を今期の柱にしたい
- 前期は既存顧客の更新が中心で、新規は年3件
- 商談数を増やしたいが、上期は繁忙で動けない
- 下期にセミナー経由のリードを試したい
形式: OKRで。Objective1つ、Key Result3つ。

OKRなら、Objectiveは定性的な到達点、Key Resultは測定可能な結果に分けます。MBOなら、指示を「目標項目・達成基準・期限・ウェイト」に変えるだけです。

メモには「新規を増やしたい」とあるだけで、目標値がありません。先ほどの指示があれば、Key Resultの数値欄は「要確認」になって返ってきます。上司はここで数字を決めて、もう一度貼り直します。

手順を1回で終わらせない

目標は1往復で完成させる想定にしないほうがうまくいきます。次の順で回します。

1. メモから叩き台を出させる
2. 「要確認」の箇所を上司が埋める
3. 「この目標は基準表の等級Bの期待行動に対して低すぎないか」と確認させる
4. 本人との面談後に、合意内容で最終版を作る

3番目のように、基準表に照らして点検させるのがナレッジを入れた利点です。ただし判定を任せるわけではありません。Claudeの指摘は、上司が見直す観点として使います。

評価コメント: 事実メモを行動ベースの文章にする

評価コメントは、期中に書きためた事実メモから起こします。日付つきの短いメモが理想です。

対象: 営業2課 佐藤さん(仮名) 評価期間: 下期
事実メモ:
- 10月 セミナー企画を自発的に提案。参加者42名
- 11月 参加者のうち商談化8件。うち受注2件
- 1月 引き継ぎ資料が遅れ、後任が1週間止まった
評価段階の案: A

指示文どおりなら、返ってくる構成は「事実・影響・次期への期待」の3部です。ここで確認するのは次の点です。

• 事実の欄に、メモにない出来事が混ざっていないか
• ネガティブな事実(1月の引き継ぎ)が落ちていないか
• 評価段階の理由が、基準表の言葉と一致しているか

2つ目が特に重要です。良い話だけで組み立てると、評価段階との整合が取れなくなります。「都合の悪い事実も入れて」と一言添えるか、指示文に「メモにある改善点は必ず反映する」と書いておきます。

トーンを本人向けと人事向けで分ける

同じ事実でも、本人に渡すフィードバックと、人事や上長に出す根拠メモでは書き方が変わります。同じチャットで「本人向けに、事実は同じままトーンを柔らかく」と続けて依頼します。事実の欄は変えず、表現だけが変わっているかを見比べるのが確認のコツです。

共有範囲と機微情報の扱い

評価は社内でも特に慎重に扱う情報です。共有の挙動は、プランと管理者の設定で変わります。

公開で作った場合も、「Share」ボタンの一般アクセスで「Only people invited」に切り替えられます。共有すると相手にメール通知が届き、権限レベルも書かれます。

Can viewとCan editの範囲

Can editの範囲は、公式ページで書き方が揃っていません。プロジェクトの概要ページは「メンバーの追加・削除」まで含め、作成手順のページは「メンバー設定の更新」までです。

アクセスの削除も、作成手順のページはプロジェクト作成者の操作として書き、共有設定のページはCan editの人にもできるとしています。評価資料では、Can editを渡した相手が共有先まで変えうる前提で、渡す人を絞ります。

共有できないとき、グループで共有したいとき

状況ごとの切り分けは次のとおりです。

• 共有ボタンから新しい相手を足せない: オーナーがプロジェクト共有をオフにしています。共有をオフにすると公開プロジェクトもオフになり、すでにある共有はそのまま残ります。組織側の設定はClaude組織のプロジェクト公開を無効化する方法で確認できます
• 「Everyone at組織名」が選べない: オーナーが公開プロジェクトだけを無効にしている場合があります。この場合、作成時も作成後も組織全体への共有は使えません
• 人事部門など決まった集団に渡したい: Enterpriseプランではグループへの共有(ベータ)があり、グループに後から入った人は自動でアクセスでき、抜けた人は失います。グループ側で「Share resources with this group」を管理者が有効にしている必要があり、アクセス変更の反映には最大5分かかります

氏名を仮名にして貼る、対象者を個人名でなく等級や職種で扱う、といった運用も併用できます。Claude側の設定だけでなく、社内の個人情報取り扱いルールに沿うかどうかを先に確認します。

期が終わったプロジェクトはアーカイブできます。ただしアーカイブしても共有相手や権限は消えません。アクセスを外すには、共有設定でメンバーを削除します。また、アーカイブ済みプロジェクトは削除できないので、消す場合は先にアーカイブを解除します。

つまずきやすい点

指示を書いたのに書式が崩れる

指示はプロジェクト内のチャットで効きます。プロジェクトの外で始めたチャットには適用されません。標準のチャットを、あとからプロジェクトへ移すこともできます。

別の部下の情報が混ざる

ナレッジに全員分を入れると、チャットで対象者を指定し忘れたときに取り違えが起きます。チャットの冒頭に必ず「対象: ○○さん」と書き、1人1チャットで進めます。

プロジェクト単位のメモリが気になる

TeamとEnterpriseでメモリを有効にしている場合、プロジェクトごとに別のメモリが持たれ、プロジェクト外のチャットとは分かれます。無関係なチャットが混ざったときは、チャットをプロジェクトから外して整理できます。評価の話を記憶に残したくないチャットは、「+」メニューの「Memory」を最初のメッセージの前にオフにできます。この方法で始めたチャットは、プロジェクトのメモリを使わず、追加もしません。

基準が古い

評価基準を改定したのに、ナレッジのファイルが前期のままだと、古い基準で下書きされます。改定のたびにファイルを差し替えます。

指示の置き場所を使い分ける

書式のルールはプロジェクト指示に、個人の好みの文体はアカウント側のパーソナライズに置く、といった分け方もできます。両者の違いはClaudeパーソナライズ機能の使い分け方にまとめています。評価用の指示を個人設定に混ぜると、ほかの仕事のチャットにまで影響するので、プロジェクト側に閉じておくのが無難です。

まとめ

評価の判断は上司が持ち、Claudeには基準に沿った下書きと「要確認」の洗い出しを任せる。この分担が手順の核です。下書きは、書く時間を減らすための材料にとどまります。360度評価の匿名コメントを前処理する手順は360度評価の自由記述を要約するClaude Code手順にあります。

共有は非公開から始め、必要な相手にだけCan viewで広げる順が無難です。