stakeholder-summary

ステークホルダー向け要約

案件のコンテキスト

案件のコンテキスト。 実務レベルのCLAUDE.mdにある## Matter workspacesを確認してください。Enabledが✗（社内ユーザーのデフォルト）の場合、この段落の残りはスキップしてください。スキルは実務レベルのコンテキストを使用し、案件関連の仕組みは表に出ません。有効になっていて、アクティブな案件がない場合は、「どの案件についてですか？ /commercial-legal:matter-workspace switch <slug>を実行するか、practice-levelと入力してください。」と尋ねてください。案件固有のコンテキストと上書き設定を確認するため、アクティブな案件のmatter.mdを読み込んでください。出力は案件フォルダー~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/に保存してください。Cross-matter contextがonでない限り、別の案件のファイルを読んではいけません。

---

送付先の確認

出力を作成する前に、送付先を確認してください。ユーザーが送付先（チャンネル、配布リスト、取引相手、「全員」など）を指定した場合、特権保護の対象範囲内かどうかを尋ねてください。公開チャンネル、全社向けリスト、取引相手や相手方弁護士、ベンダー、クライアント（成果物の場合）に共有すると、保護が放棄されます。送付先が保護対象の範囲外と思われる場合は、そのことを伝え、（a）法務部門専用の特権保護対象版、（b）より広いチャンネル向けに情報を削除した版、または（c）両方を提供してください。特権保護の見出しを付けただけで、その見出しでは保護されない場所への貼り付けを黙って支援してはいけません。このプラグインのCLAUDE.mdにある正式な## Shared guardrails → Destination checkを参照してください。

目的

この契約を依頼した事業部門の担当者が求めているのは、法的メモではありません。知りたいのは、署名してよいか、注意すべき点は何か、何をすべきかです。このスキルは、完了したレビューをそのための要約にまとめます。

どちら側か？

元のレビュー・メモは、売り手側または買い手側のいずれかのプレイブックに基づいて作成されています。その視点を引き継いでください。買い手側の要約では、「何を得るのか、何を譲ることに合意したのか」を事業部門の担当者に伝えます。売り手側の要約では、「何を販売するのか、どのような責任を負うのか」を伝えます。レビューがどちら側の視点で行われたか（レビュー・メモの冒頭に記載されているはずです）を確認し、それに合った語り口にしてください。メモから明らかでない場合は、要約する前に弁護士に確認してください。

読者に合わせた調整

~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → ## House style → ステークホルダー向け要約の読者と、要約の長さを確認してください。指定がない場合は、調達担当者または部門長を想定し、最大2段落、法律用語を使わないことをデフォルトとしてください。

読者によって必要な要約は異なります。

読者	関心があること	関心がないこと
調達担当者	価格、更新の仕組み、承認ルート	責任上限の構成
部門長（予算責任者）	自分のチームが利用できるか、問題が起きた場合の対応、費用	補償の範囲
財務部門	総保有コスト、更新価格のリスク、貸借対照表に計上されないコミットメント	準拠法
セキュリティ／IT	データの取り扱い、再委託先、SOC 2、データの保管場所	その他すべて
経営幹部のスポンサー	当社の評判を損なうことがないか、法務が障害になっていないか	詳細

文脈から対象者が明らかでない場合は、誰向けの要約かを尋ねてください。

要約

長さの上限 — 厳守

要約は次の構成にします。

• 1段落で結論と契約の概要を説明します（商業条件を平易な言葉で）
• 1段落で注意点を説明します。つまり、今伝えなければ後でステークホルダーが驚くような点です
• ステークホルダーが実際に行う必要のあることを2～3項目のチェックリストにします（最大3項目。4つ目を入れたい場合は、最初の3項目を十分に絞り込めていません）
• 承認時期を1行で締めくくります

合計200語未満。 それを超える場合は、ステークホルダーに不要な詳細を含めています。詳細はメモを見れば分かります。これは、ステークホルダーが返信する前に目を通すための要約です。

締めの文に3つ目の段落が必要な場合は、チェックリストに含めてください。締めの文を4つ目のブロックに膨らませないでください。

引用の範囲 — 厳守

契約条項を引用する場合（要約、「注意点」の段落、チェックリストのいずれであっても）、省略した形ではなく、条件文全体を引用してください。「注文書に明示的な定めがある場合を除き、プロモーション価格または一回限りの価格が設定されたサブスクリプションは、更新時に通常価格に戻る」という条項は、「更新時に通常価格に戻る」とは意味が異なります。省略すると条件が抜け落ち、条項の内容を誤って伝えることになります。

条件文全体を引用すると要約の長さ制限を超える場合は、途中で省略せず、言い換えてください。「プロモーション価格の場合、更新時に通常価格に戻る」は適切な言い換えですが、「更新時に通常価格に戻る」は適切ではありません。例外を原則であるかのように伝えてしまうためです。

形式

~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md の ## Outputs にある成果物ヘッダーを先頭に付けてください（ユーザーの役割によって異なります。「## Who's using this」を参照）。

[WORK-PRODUCT HEADER — per plugin config ## Outputs]


**[Counterparty] [Agreement type]** — [READY TO SIGN | NEEDS CHANGES | BLOCKED]

[One paragraph: what this agreement does, in business terms. Not "Master Services
Agreement for the provision of cloud-based analytics" — "this is the contract
for the dashboard tool the marketing team wants."]

[One paragraph: what the stakeholder needs to know. The catch, if there is one.
The thing that will surprise them later if nobody tells them now. E.g., "Heads
up: this auto-renews every year and we have to cancel 60 days out. I've added
it to the tracker but you should know." Or: "Clean agreement, no surprises,
cleared to sign."]



**Verify tracker entries before asserting them.** Before the summary says "I've added it to the tracker" (or any equivalent — "it's in the tracker," "tracked," "set a reminder"), verify that `renewal-tracker` has been run for this contract. Check the outputs folder or the matter folder for a `renewal-tracker` output that names this counterparty / agreement. If there isn't one:

- Either run `renewal-tracker` for this contract first, then write the summary.
- Or write the summary without asserting the tracker entry, and include an action item: "Add to renewal tracker — not yet done."

Claiming a tracker entry exists when it does not is worse than omitting the reassurance. The stakeholder then trusts the reminder that will never fire. If the truthful statement is "tracked," the skill runs the tracker. If it's "you should add this to your calendar — I haven't logged it," say that.

**What you need to do:**
- [ ] [Action item, if any — "confirm the team is okay with data living in EU"
  or "nothing — I'll route for signature"]

**Approval:** [who's approving and expected timing]

翻訳する内容

法務上の指摘	ビジネス向けの説明
「責任上限は12か月分の料金」	「相手が何か損害を与えた場合、回収できるのは、相手に支払った1年分の金額が上限です。」
「任意解除不可」	「署名すると契約期間全体にわたって拘束され、使わなくなっても自由に解約できません。」
「60日前通知による自動更新」	「毎年自動更新されます。解約するには、更新日の2か月前までに相手に通知する必要があります。」
「知的財産権侵害に関する補償なし」	「このツールが特許を侵害しているとして誰かに訴えられても、ベンダーは当社を守る責任を負いません。」
「再委託先一覧が非開示」	「ベンダーを通じて、他のどの会社が当社のデータにアクセスするのか分かりません。」
「契約終了から30日以内にデータを削除」	「解約すると、相手は1か月以内に当社のデータを削除します。必要なものはそれまでにエクスポートしてください。」
「SLA クレジットは月額料金の10％が上限」	「サービスが停止しても、返ってくるのは少額のクレジットです。業務に生じた停止コストは補填されません。」

含めてはいけないもの

• 条項番号
• 引用符で囲んだ定義語
• 「補償」という言葉（「相手が当社を守る」／「当社が相手を守る」と表現してください）
• 「これにかかわらず」という言葉
• 色付きドットを使ったリスクマトリックス（関係者から以前に明確な要望があった場合を除く）
• 法的助言ではないという但し書き — 送信者が誰かは関係者も分かっています

レビューで問題が見つかった場合

レビューで🔴または🟠の問題が見つかった場合も、要約は2段落にしてください。ただし、2段落目では「何に異議を唱え、なぜそうするのか」を説明します。

[WORK-PRODUCT HEADER — per plugin config ## Outputs]


**[Counterparty] [Agreement type]** — NEEDS CHANGES

[What it is, one paragraph.]

We're going back to them on [N] things before this is ready. The main one:
[the critical issue in plain English — "they want the right to use our data
to improve their product, which means our competitors' instance gets smarter
from our data"]. We've asked them to strike it. [Realistic assessment: "They'll
probably agree" / "This might be a sticking point — will keep you posted."]

**What you need to do:**
- [ ] Nothing yet — I'll let you know when it's back from them.
  OR
- [ ] [Business decision they need to make: "If they won't budge on X, are you
  okay with Y, or do we walk?"]

引き継ぎ

vendor-agreement-review / saas-msa-review から： これらのスキルは完全なメモを作成します。このスキルはそのメモを読み、要約します。契約を再レビューせず、レビュー結果を読んでください。

関係者への共有： ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md に記載されたチャネルを使用してください。Slack の場合は150語以内にしてください。メールの場合は、上記の形式をそのまま使用できます。

エスカレーションの突合

上流のレビューは、複数の対象へ振り分けるプロデューサーです。異なる指摘事項について、5つのエスカレーション先（副法務顧問、CISO、プライバシー担当責任者、CFO、事業オーナー）を指定できます。escalation-flagger は一度に1つの指摘事項を振り分けます。突合のステップがなければ、副法務顧問にはメモが届いても、残り4人の承認者には届きません。

要約を作成する前に、上流のレビューメモを読み、エスカレーションを数えます。

1. レビューで指定されたエスカレーション先を数えます。 レビューの末尾にある振り分け／エスカレーションのブロック、または各指摘事項の「[X] へエスカレーション」タグを確認します。承認者名で重複を除きます。同じレビュアーが2つの指摘事項で指定されていても、1人として数えます。
2. 実際に振り分けられたエスカレーションを数えます。 レビューフォルダー（または案件フォルダー）で、レビュー作成後に escalation-flagger が作成した escalation-*.md の下書きを確認します。各下書きには承認者が1人記載されています。
3. 突き合わせます。 承認者が N 人指定され、下書きが M 件ある場合、（N − M）件のエスカレーションが未振り分けです。

要約には、キャッチ段落の下、チェックリストの上に、短い突合ブロックを含めます。

**Escalation status:** [M] of [N] escalation targets routed. The following have not been routed and require action:
- [Approver name] — [one line on the finding that named them]
- [Approver name] — [one line]

N 人全員への振り分けが済んでいる場合：

**Escalation status:** [N] of [N] escalation targets routed.

上流レビューでエスカレーションが見つからなかった場合は、このブロックを省略します。

関係者が名前を知らないという理由で、指定された承認者を突合から除外してはいけません。 事業関係者は、プライバシー担当責任者やCISOが誰なのか知らないことがよくあります。突合は社内向けのもので、要約を送る弁護士に、すべての振り分けが完了しているかを伝えるものです。関係者向けの要約を簡潔に保つ必要がある場合は、突合を「振り分け状況」フッターや添付メモに記載してもかまいません。ただし、必ず含めてください。振り分けが完了していないのに、完了したと思わせる要約は、要約がないよりも悪いものです。

語数制限の例外。 エスカレーションの突合ブロックは、200語の上限の対象外です。要約本文では引き続き語数制限を守ってください。突合は物語ではなく、事務的な確認事項です。

escalation-flagger の下書きがない場合。 上流レビューで承認者が指定されているのに、フォルダーに下書きがない場合は、M = 0 として扱います。突合ブロックには、N 人全員を未振り分けとして記載します。それが指摘事項です。

文体について

関係者が法務について覚えているのは2つです。仕事の妨げになったか、そして説明がわかりやすかったか。このスキルは、法務の説明をわかりやすくするためのものです。ファイルに綴じるメモを書くようではなく、聡明な同僚にコーヒーを飲みながら説明するように書いてください。

率直に言って「問題ありません。署名してください」で済むなら、そう伝えてください。念入りに見せるために、問題のないレビューを3段落に膨らませないでください。