strategy-review

戦略レビュー

戦略文書に厳しい検証を加え、現実に直面して破綻する前に弱点を見つけます。主な目的は、文章の質を評価したり、書式を確認したりすることではありません。戦略を実行段階で頓挫させるギャップ、隠れた失敗経路、過小評価されたリスクを見つけることです。このレビューを乗り越えた戦略は、現実の世界に持ち込んでも生き残る可能性が大きく高まります。

このスキルは、strategy-interview スキルを補完します。strategy-interview は、対話を通じて戦略の 構築 を支援します。一方、strategy-review は、同じカーネルフレームワーク（診断、基本方針、一貫性のある行動）と悪い戦略のフィルターを使い、既存の戦略を厳密かつ批判的に評価します。

一般的なフィードバックとの違い

戦略へのフィードバックは、役に立たない次の二つに大別されます。曖昧な称賛（「とてもよく考えられていますね」）か、表面的な揚げ足取り（「タイムラインを追加してみてはいかがでしょう」）です。どちらも、著者が自分の考えがストレス下で本当に持ちこたえるのかを見極める助けにはなりません。

このレビューでは、一般的なフィードバックにはない三つのことを行います。

1. 構造的な整合性を検証します — 診断から基本方針、一貫性のある行動へと続く論理の連鎖が本当に成り立っているのか、それともその間の「したがって」が、実はひそかに「それに加えて」になっているのかを確認します。
2. 失敗経路を探します — 文書のどこに問題があるかだけでなく、何が欠けているために 現実世界 で何が起こるのかを見つけます。徐々に逸れていくシナリオ、戦略の要となる行動を停滞させる能力のギャップ、誰も想定していなかった競合他社の対応、戦略が存在しないかのように扱っている社内政治上の抵抗などです。
3. 見えない前提を明らかにします — どの戦略も賭けですが、その賭けを明示していない戦略は少なくありません。このレビューでは、著者が明言していない、成否を左右する前提を見つけ、それぞれが誤っている場合のリスクを整理します。

始める前に

references/review-dimensions.md を読んでください。そこには、七つの評価軸とその基準が記載されています。これはレビューの土台です。作業中は常に意識してください。

厳格なゲート（根拠に基づくこと）

これらの手順は、根拠なしに正当化しやすいため、各ゲートには次へ進むための合格条件があります。

1. 評価（ステップ3）。 戦略の入力資料から引用またはセクションを参照した箇所、strategy-notes.md（または同等の資料）への相互参照、あるいは関連する箇所が存在しないことを明記した Missing の注記のうち、少なくとも一つを得るまでは、いずれの評価軸にも Strong、Adequate、Weak を付けないでください。合格条件： 評価したすべての軸について、これらの根拠のいずれかが記録されていること（チャット内、永続状態を使用する場合は dimension-ratings.md 内、または最終レビュー内）。
2. 重大な指摘事項（ステップ5）。 同種の根拠（引用、セクション参照、メモへの相互参照、または明示的な欠如）に結び付かない項目を、重大な指摘事項として挙げないでください。合格条件： 文書またはメモに結び付かない、一般論だけの重大な指摘事項がないこと。
3. 判定用成果物モード。 順序： 文章形式の strategy-review.md を完成させる → その文章から strategy-review.json を作成する → references/judge-artifact-schema.md の検証チェックリストを実行する → チェックリスト（構文解析、必須フィールド、スコアの計算）が合格した後にのみ、JSON を出力または保存する。合格条件： JSON が検証に合格し、文章形式のラベルおよび根拠と一致していること。
4. 永続状態（.beagle/.../reviews/.../ が存在する場合）。 レビューの完了を宣言する前に、review-state.md が存在し、その current_step とレンズ／カーネルのフィールドが、実際に行った作業（ステップ1～5およびディスク上のファイル）と一致していることを確認してください。合格条件： 台帳が実際のステップと入力資料を反映していること。また、dimension-ratings.md または kernel-extraction.md を作成した場合、最終的な strategy-review.md がそれらの内容と矛盾していないこと。

補完的なレビューの視点

カーネルの評価（診断、指針となる方針、一貫性のある行動）が常にレビューの土台になります。戦略文書の内容に応じて、追加の4つの視点を読み込みます。**無理に適用しないでください。**ほとんどのレビューで使うのは1つか2つで、使わない場合もあります。視点を読み込むのは、必須チェックリストとしてではなく、文書の内容がその条件に該当する場合です。

各視点は新たな項目を追加するのではなく、既存の7つのディメンションを掘り下げます。視点によってギャップが明らかになった場合、その指摘は該当するディメンションに分類します。ギャップを見つけたのが視点であり、そのギャップが位置するのがディメンションです。

視点	読み込む条件	加えるもの	主なディメンション
マッキンゼーの7S（実行の整合性）	戦略の実現に、組織の変更（新しい構造、プロセス、文化的変革、部門横断的な連携）が必要な場合	構造、システム、共通の価値観、スタイル、スタッフ、スキルにわたる整合性が戦略に考慮されているかを確認します。最もよくあるギャップは、戦略は方向転換するものの、組織がそれに追随すると想定していることです。	ディメンション3、ディメンション6
バランス・スコアカード（目標の変換）	成功の基準が一面的（通常は財務のみ）であるか、曖昧な場合	財務、顧客、プロセス、学習の各観点で成功を測定できるかを確認します。財務指標は遅行指標です。収益に問題が表れる前に兆候を示す先行指標が戦略には必要です。	ディメンション7
ポーターのファイブフォース（競争圧力の監査）	診断で、競争環境（市場での位置付け、価格競争、新規参入、代替のリスク）を扱っている場合	直接的な競争だけでなく、競争環境全体を診断できているかを確認します。多くの戦略では、1つの競争要因を診断する一方で、ほかの要因を無視しています。	ディメンション1
方針管理（Hoshin Kanri）（戦略の展開）	複数の組織階層が関わり、経営陣の意図からチームの実行へと行動を展開する必要がある場合	戦略から業務へと移る過程でも行動が維持されるかを確認します。戦略は変換の段階で頓挫します。組織の各階層で、内容が少しずつ損なわれていきます。	ディメンション3

視点の選択はステップ2（カーネルの読み取りと抽出）の間に行います。カーネルの要素を特定したら、各視点の適用条件を念頭で確認します。該当する視点について references/review-lenses.md を読み込み、その視点の検証質問をステップ3のディメンション評価に織り込みます。

レビュアーは、ギャップを見つけるために視点の考え方を活用します。ユーザーに講釈するために視点の用語を使うのではありません。「戦略は方向転換していますが、現在の組織構造が新しいアプローチを支えられるかどうかには触れていません」という指摘は、7Sを踏まえたものです。ユーザーがそれをマッキンゼーのフレームワークに由来すると知る必要はありません。

レビューワークフロー

ステップ1 — 文書を集める

レビューしたいものをユーザーに尋ねます。一般的な入力は次のとおりです。

• strategy-draft.md + strategy-notes.md — strategy-interview で作成された2つのファイルです。メモファイルには前提、未解決の質問、検討の経緯が含まれているため、レビューの質が大幅に高まります。片方しか提供されていない場合は、必ず両方を尋ねてください。
• 単独の戦略文書 — 戦略をうたう文書であれば、どのようなものでも構いません。Google ドキュメントから貼り付けた内容、PDF、スライド資料の要約、Markdown ファイルなどが考えられます。
• スライド資料または概要資料 — 戦略上の主張を抽出して評価します。スライドのデザインは批評しないでください。

文書が何を意図しているのか（戦略、計画、ビジョン、目標など）が曖昧な場合は、その点を明確にします。「これは戦略というより目標文書のようです。達成したいことは書かれていますが、その方法に関する考え方が示されていません。このままレビューしますか。それとも、まず不足している戦略要素を特定しますか？」

ユーザーに文書の提供を求める前に、作業ディレクトリに既存の戦略ファイルがないか確認してください。以前の strategy-interview セッションで作成済みの可能性があります。

ステップ 2 — カーネルを読み取り、抽出する

文書全体を読みます。カーネルを構成する以下の3つの要素を特定します（該当する記述がない場合は、そのことを記録します）。

1. 診断 — 文書では、実際に何が起きていると述べていますか？課題は明確に示されていますか？
2. 基本方針 — どのような全体的アプローチが選ばれていますか？進む方向を選択していますか？
3. 一貫性のある行動 — 方針を実行する具体的なステップは何ですか？それらは互いに補強し合っていますか？

文書で異なる用語（OKR、柱、戦略上の優先事項、イニシアチブなど）が使われている場合は、その概念をカーネルに当てはめます。無理に用語を置き換えるのではなく、ラベルの背後にある考え方を評価してください。基本方針として機能する「戦略上の優先事項」は、基本方針として評価します。

以下の点にも注目します。

• 補完的なインタビューレンズ（全体像のマッピング、選択のカスケード、価値革新）が適用されているかどうか。適用されている場合は、ステップ 3 のインタビューレンズ監査でどれを使ったかを記録します。
• 明示されている対象範囲と期間
• 想定読者
• 列挙されている前提（または、前提が著しく欠けていること）

ステップ 3 — 7つの評価軸で評価する

references/review-dimensions.md にある各評価軸を順に検討します。それぞれについて、次の手順を踏みます。

1. 評価する — この評価軸について、文書は何が優れていて、何が不十分ですか？
2. 根拠を示す — 具体的な記述を引用するか、該当箇所を示します。根拠のない主張はしないでください。
3. 評価を付ける — ステップ 2 が「厳格な基準 → 評価」を満たした後にのみ評価（強い／十分／弱い／該当なし）を付けます（評価ラベルより先に記録を根拠として示します）。
4. 提案する — 評価が「弱い」または「該当なし」の場合、著者が具体的に何をすべきかを示します。「診断を改善する」ではなく、「診断では『市場の変化』を課題として挙げていますが、どのような変化なのか、またそれがこの企業にとってなぜ重要なのかが特定されていません。より良い内容にするには、機会または脅威を生む構造的な変化を1つか2つ特定するとよいでしょう」のように記述します。

7つの評価軸（概要。詳細は参考資料を参照）：

#	評価軸	中心となる問い
1	診断の質	実際の課題を、誤りだと判定できるだけの具体性をもって示していますか？
2	基本方針の強さ	選択肢を排除する、実質的な選択をしていますか？
3	行動の一貫性	行動は互いに補強し合い、方針を実行していますか？
4	カーネルの論理的連鎖	診断 → 方針 → 行動の論理的なつながりは成り立っていますか？
5	悪い戦略のパターン	ランペルトが挙げる4つの特徴（および追加のアンチパターン）が見られますか？
6	前提の明示	戦略の成否を左右する前提は特定され、検証可能になっていますか？
7	具体性と反証可能性	12か月後に、この戦略が成功したか失敗したかを判断できますか？

ステップ 3b — インタビューレンズの監査（インタビューレンズが文書に含まれている場合）

戦略文書または付属のメモに、インタビュー中にランドスケープマッピング（Wardley）、戦略的選択のカスケード（Playing to Win）、または価値革新（Blue Ocean）のレンズが適用されたことを示す根拠がある場合、それらのレンズによる知見が実際に戦略に反映されたかどうかを監査します。各レンズの詳細な監査基準については、references/interview-lens-audit.md を読み込んでください。

監査では、各レンズについて次の2点を確認します。

1. 忠実性 — レンズ固有の知見が草案に引き継がれたか、それとも削除または弱められたか。
2. 影響 — レンズの知見がカーネル（診断、基本方針、一貫性のある行動）を実際に明確にしたか、それとも認識されただけで飾りにとどまったか。

所見は該当する次元の下に記録します（通常、ランドスケープは次元 1、カスケードは次元 2～3、価値革新は次元 1～4）。また、メモにあるインタビューレンズの知見が草案で削除または弱められている場合は、それも指摘します。こうした知見には、文書の推敲中に薄められてしまった、最も鋭い洞察が含まれていることがよくあります。

注： 4つのレビューレンズ（7S、Scorecard、Five Forces、Hoshin Kanri）と3つのインタビューレンズは、異なる目的で使われます。レビューのレンズは、レビュー担当者がギャップを見つけるために適用するツールです。インタビューレンズは、戦略策定の話し合いの中で知見を生み出します。この監査では、その知見が草案に引き継がれたかを確認します。一方をもう一方の代わりに使わないでください。Five Forcesは競争に関する主張を独立して検証できますが、Wardleyマッピングの演習が草案に忠実に反映されたかどうかは検証できません。

ステップ 4 — メモとの照合（利用可能な場合）

strategy-notes.md または同等の推論メモがある場合は、次の点を照合します。

• 未解決の質問：最終版の完成を妨げるべき重大な問題はありますか？
• 前提：草案は、メモで未検証と指摘された前提に依存していますか？依存している場合、そのリスクはどの程度深刻ですか？
• インタビュー中に把握した悪い戦略のパターン：最終版で実際に解消されていますか？それとも、より穏やかな表現で再び入り込んでいますか？
• 思考の変遷：草案は最も鋭い診断を維持していますか？それとも、執筆中に弱められていますか？
• レンズによる知見：ランドスケープマッピング、選択のカスケード、価値革新の分析を行った場合、その知見は実際に草案に反映されていますか？

ステップ 5 — レビューを作成する

ファイルを書き込む前に、ユーザーの意図を確認してください。簡単なフィードバック、チャットだけでの所感、または会話形式で「問題点を指摘して」と頼まれた場合は、調査結果をその場で提示してください。重大な問題点を最初に挙げ、次に主要な失敗経路を示し、その後に推奨事項を述べます。必要であれば、後から完全版のレビューファイルを作成することを提案してください。正式なレビューを求められた場合、または指定がない場合は、書き込む前に出力パスを確認してください。

references/review-template.md に従って strategy-review.md を作成します。構成は次のとおりです。

1. レビューの要約 — この戦略が目指すこと、全体的な評価、最も対応が必要な点を、3～4文で説明します。
2. 強み — うまく機能している点と、その理由を具体的に説明します。著者が維持すべき点を把握できるよう、ここから始めます。
3. 重大な問題点 — 戦略の整合性を最も損なう2～4項目を、深刻度順に示します。戦略を共有したり実行に移したりする前に修正すべき項目です。レビューの中で最も価値の高い部分なので、最初に取り上げます。
4. 各評価軸の評価 — 7つの評価軸について、評価、根拠、推奨事項を示します。重大な問題点を裏付ける詳細情報を提示します。
5. 失敗経路の分析 — 現実の状況でこの戦略がどのように失敗し得るかを分析します。以下の「失敗経路について考える」を参照してください。
6. 前提条件のリスクマップ — 影響度と不確実性に基づいて、重要な前提条件を順位付けします。誤っていた場合に、戦略が完全に破綻するものはどれでしょうか？
7. 観点別の調査結果 — レビューの観点を適用した場合、それらによって中核となる評価軸だけでは見つからなかったどのような点が明らかになったかを示します。観点を適用していない場合、このセクションは省略します。
8. 推奨する次のステップ — ドキュメントを強化するための具体的なアクションを、影響度順に示します。

記憶ではなく成果物をもとにまとめてください。 永続的なレビュー状態がある場合（以下を参照）、会話から再構成するのではなく、それらのファイルを最終レビューの主な情報源として使用してください。全体的な評価と構成の判断を review-composition.md に更新してから、成果物をもとに strategy-review.md を作成します。エージェントがサブエージェントに対応している場合は、ドキュメントの組み立てをサブエージェントに任せてください。構造化されたファイルを新しいコンテキストで読み込むことで、より正確なレビューを作成できます。対応していない場合は、成果物のファイルを直接読み直して自分でまとめてください。出力は同一になります。

ファイルを書き込んだ後、チャットで簡潔に要約します。全体的な評価を一文で述べ、最も重要な指摘を1つ挙げ、推奨する次のアクションを示してください。

失敗経路を考える

ここは、作成者がほかの手段では得にくい価値を、レビューが最も発揮するところです。戦略をレビューする人の多くは、文書の何が問題かを指摘します。失敗経路の分析では、その文書に書かれていること（または書かれていないこと）が原因で、現実世界で何が起こり得るかを明らかにします。

戦略が失敗するのは、劇的で目に見える危機が原因であることはめったにありません。予測可能で、気づかれにくいパターンを通じて失敗します。

能力のギャップ：成否を左右する行動に、組織が持っておらず、構築コストを過小評価している能力が必要です。「第3四半期までにネイティブモバイルアプリをリリースする」は実行項目のように聞こえます。しかし、チームがネイティブモバイルアプリを開発した経験がなければ、成果物として装った6か月の調査プロジェクトです。

ゆるやかな逸脱：指針となる方針の除外事項を守らせるものがありません。四半期ごとに例外が増えていきます。「エンタープライズは対象外と言ったけれど、この案件は本当に大きい」。1年もすれば、無数の小さなイエスによって、戦略はいつの間にか覆されています。

想定されていない反応：戦略は競争環境が変わらないと想定しています。しかし、競合他社も同じ市場の兆候を読み取っています。戦略の診断が正しければ、ほかの企業も同じような結論に至るでしょう。そうした企業が対応した場合、何が起こるでしょうか。

政治的な拒否権：戦略の実行には、影響力のあるステークホルダーが管轄する何かを止める必要があります。作成者は賛同が得られると思い込んでいるため、戦略文書にはこの点が記されていません。しかし、賛同が得られることはまずありません。

前提の連鎖的な崩壊：重要な前提が一つ崩れ、行動同士が密接に結びついているため、その失敗が連鎖します。市場が予想どおりに成長しないため、ユニットエコノミクスが成り立たず、資金調達の根拠が崩れ、結果として能力を構築できません。

実行のボトルネック：複数の行動が同じ希少なリソース（主要なチーム、特定のリーダー、予算枠など）に依存しているのに、戦略ではそれらが独立しているものとして扱われています。ボトルネックが制約となったとき、作成者はどの行動を延期するか選ばなければなりません。しかし、戦略にはその優先順位の判断に関する指針がありません。

測定手段の欠如：先行指標が定義されていないため、遅行指標（売上、市場シェア）が出るまで、組織は戦略が機能しているか判断できません。その時点では、軌道修正にはもう遅すぎます。

特定した失敗経路ごとに、具体的なシナリオ、発生可能性、戦略が現状どのようにリスクを軽減しているか（多くの場合、何もしていません）、作成者がリスクを低減するためにできることを説明してください。こうした指摘は、作成者の考え方を変えたと最もよく言われるものです。作成者が存在を知っていながら明確にしていなかったリスクを明らかにするからです。

姿勢と調整

敵対的ではなく、率直にする

作成者は、実際に時間をかけて考えています。うまくできている点は認めましょう。悪い知らせを伝える前の前置きとしてではなく、心から認めてください。ただし、構造上の問題については手加減しないでください。誤った診断のまま取締役会に提出される戦略は、率直すぎるレビュアーよりも大きな損害をもたらします。

指摘は個人への批判ではなく、構造に関する観察として表現してください。「診断では市場の動向を扱っていますが、この会社が特に影響を受けやすい理由を特定していません」とし、「診断について十分に考えていません」とは言わないでください。

文書の成熟度に合わせて調整する

• 初期ドラフト／作業中の文書：大きな構造上の問題に焦点を当てます。文章表現や網羅性について細かく指摘する必要はありません。作成者は粗削りだと承知しています。将来性のある点と、最も手を入れる必要がある点を強調してください。
• 最終版に近い／共有直前：より高い基準を設けます。読者からの信頼を損なう可能性がある点は、すべて指摘してください。「概要」セクションが文書全体を正確に表しているか確認します。指針となる方針で掲げた除外事項が、行動項目の中にいつの間にか再び含まれていないか検証します。
• 事後評価／戦略の実行中：前提の検証に焦点を当てます。どの前提を現実に照らして確認できるでしょうか。出来事によってすでに否定された前提があれば指摘してください。

戦略を書き直さない

レビューでは問題を指摘し、修正を提案します。代替となる戦略は作成しません。診断が根本的に間違っている場合は、そう伝えて理由を説明してください。ただし、ユーザー自身が考え直す必要があります（できれば strategy-interview スキルを使ってください）。レビュー担当者が戦略を書き直すのは、著者の代わりに考えることになり、著者が戦略を自分のものとして受け止められなくなります。

例外：文書に要素が欠けている場合（診断がまったくない、または除外事項が明記されていない場合）は、著者が不足点を理解できるよう、参考例であることを明記したうえで、適切な内容の具体例を提示してください。

異なるフレームワークを尊重する

文書が OKR、V2MOM、SWOT、ポーターのファイブフォース、その他のフレームワークを使っている場合は、形式ではなく、考え方を評価してください。核となる問いは常に同じです。診断、方向性の選択、一貫性のある行動が示されているでしょうか。これらは別のラベルのもとに記載されている場合があります。用語を押しつけるのではなく、概念を対応づけてください。

「この V2MOM には方法と障害はあるが、どの障害が最も重要かという診断がない」といった、実際の構造的な不足を指摘してください。「代わりにカーネル形式を使うべき」といった、フレームワークの置き換えを求めてはいけません。

ソースの扱い

文書が市場、競合他社、トレンドについて主張している場合：

• どの主張に出典があり、どの主張が根拠を示さずに述べられているかを明記してください。
• 検証済みのデータではなく、一般通念に基づいているように思われる市場に関する主張を指摘してください。
• レビューが検証できない外部情報に依存している場合は、その旨を伝えてください。「この診断は [X] という主張に基づいています。これを検証することはできませんが、誤っていれば戦略全体が変わります。」

バリアント：進行中の strategy-interview のレビュー

ユーザーがインタビューの途中にいる場合（strategy-notes.md はあるものの strategy-draft.md がない、またはドラフトに [PROVISIONAL] と記されている場合）：

1. 現時点で存在するものをレビューしてください。ドラフトがまとまる前でも、メモには思考が記録されています。
2. まとまりつつあるカーネルの、最も強い要素と最も弱い要素に焦点を当ててください。
3. 最終決定の前に、ユーザーが厳しく検証すべき質問を提案してください。
4. 完全なレビューではなく、最も重要な所見を 3～5 件まとめた「インタビュー途中のチェック」を作成してください。

バリアント：比較レビュー

ユーザーが 2 つの戦略文書（競合する提案、変更前後のバージョン、異なるチームの戦略など）を提示した場合：

1. まず、それぞれを 7 つの評価軸で個別にレビューしてください。
2. 次に比較してください。診断のどこが一致しているでしょうか。どこが異なるでしょうか。どちらがより具体的で、一貫性があり、反証可能でしょうか。
3. 構造の質に明確な差がある場合を除き、勝者を決めないでください。2 つの戦略が同じくらい厳密でありながら意見が異なることもあります。それはレビュー担当者ではなく、意思決定者が判断することです。

レビュー状態の維持

長いレビューや複雑なレビューでは、忠実さが損なわれることがあります。根拠の引用先がずれたり、各評価軸の評価が文書ではなく記憶に基づいたり、最終レビューが元資料の裏付け以上に断定的になったりします。必要に応じて、.beagle/ ディレクトリに作業状態を維持してください。

開始するタイミング

次のいずれかに該当する場合は、ディレクトリを作成してください。

• 入力文書が約 2,000 語を超える、または複数のファイルにまたがる。
• 比較レビューである（戦略文書が 2 つ以上）。
• 戦略がほぼ最終版である、または関係者に共有される予定である。
• 2 つ以上のレビュー観点が適用される。
• 出典付きの市場に関する主張が含まれており、個別に追跡する必要がある。

ディレクトリの場所

• インタビューで作成された成果物の場合：.beagle/strategy/<subject-slug>/reviews/<date-or-slug>/ — レビューをインタビューの状態と並べて格納します。
• 単独のレビューの場合：.beagle/strategy-review/<subject-slug>/reviews/<date-or-doc-slug>/ — 同じ対象の再レビューや、根拠を混在させずに v1/v2 文書をレビューできます。

作業ファイル

ファイル	目的	作成されるタイミング
review-state.md	レビュー台帳 — ドキュメントのメタデータ、該当したレンズ、現在のステップ	ディレクトリが存在すれば常に作成
source-evidence.md	出典タグ付きのドキュメントの引用と主張	ドキュメントを読み込んだとき（ステップ 2）
kernel-extraction.md	根拠とともに抽出したカーネル要素	ステップ 2 の後
dimension-ratings.md	ディメンションごとの評価、根拠、評点	ステップ 3 の間
assumption-risk-map.md	影響度 × 不確実性で示した、重要な前提	ステップ 3/4 の間
failure-paths.md	発生可能性と軽減策を示した失敗シナリオ	ディメンション評価の後
lens-notes.md	レンズ固有の調査結果	レンズを使用したとき
review-composition.md	最終レビューの構成案	ステップ 5 の前

根拠のタグ付け（source-evidence.md）

最終レビューが資料の裏付け以上に確信的な印象にならないよう、各項目にタグを付けます。

• doc quote — 戦略ドキュメントからの直接引用とセクション参照。
• reviewer inference — ドキュメントから導き出したもので、直接記載されていない内容。
• unverified assumption — 戦略が依存しているが、ドキュメントでは確認されていない主張。
• source-backed — 出典が引用されている、ドキュメント内の主張。
• notes cross-ref — strategy-notes.md またはインタビュー資料からの調査結果。

- [doc quote] "We will focus exclusively on mid-market SaaS" (Guiding Policy, p.3)
- [reviewer inference] Mid-market focus implies exiting current enterprise contracts. (Dim 2)
- [unverified assumption] TAM estimate of $2B appears unsourced. (Dim 6)
- [source-backed] "Mobile inspection usage grew 68% YoY (Gartner 2025)" (Diagnosis, p.1)
- [notes cross-ref] Interview notes flagged enterprise exit as contested. (Notes)

レビュー状態台帳（review-state.md）

document: [filename(s) being reviewed]
subject: [what the strategy is for]
maturity: [early-draft / near-final / post-hoc]
audience: [who reads the strategy]
current_step: [1-5]
lenses_triggered: [7S, scorecard, five-forces, hoshin-kanri, or none]
kernel_found: [yes / partial / no]
diagnosis_summary: [one sentence]
policy_summary: [one sentence]
critical_findings_count: [number]
top_risk: [one sentence]

オプション：審査用成果物モード

通常のレビューでは、文章形式の成果物（strategy-review.md）を作成します。ユーザーが評価パイプライン、RL ループ、または LLM-as-judge ワークフロー向けの機械可読な出力を明示的に求めた場合は、文章形式の成果物とともに、構造化された JSON 成果物も追加で作成します。

有効にする条件

審査用成果物モードは、ユーザーの表現からその意図が読み取れる場合にのみ有効になります。次のようなフレーズを探します。

• 「機械可読」「構造化出力」「JSON レポート」
• 「LLM judge」「LLM-as-judge」「judge loop」「評価用成果物」
• 「RL loop」「報酬シグナル」「評価パイプライン」
• 「JSON を作成」「審査用成果物」「構造化レビュー」

通常のレビュー、簡単な所感、チャットのみのフィードバックでは有効にしないでください。判断に迷う場合は、「評価パイプライン向けの機械可読な JSON 成果物も作成しますか。それとも文章形式のレビューのみでよいですか？」と尋ねます。

作成されるもの

審査用成果物モードでは、ユーザーが JSON のみを求めていない限り、次の 2 つのファイルを作成します。

1. strategy-review.md — 標準的な文章形式のレビュー（先に作成）
2. strategy-review.json — references/judge-artifact-schema.md に準拠した構造化 JSON

まず文章形式のレビューを作成し、そこから JSON を導出します。これにより、スキーマを埋めるのではなく、慎重な分析からスコアが導き出されます。JSON 内のすべてのディメンションラベル、重要な調査結果、根拠となる引用は、文章形式のレビューと一致している必要があります。

本番用ルール

1. スコアは評価の追加ではなく、評価の投影です。 JSON の各評価項目の評価値は、文章で示されたラベルから直接対応付けます：Strong=4、Adequate=3、Weak=2、Missing=1。中間スコアを作らないでください。
2. すべてのスコアに根拠を引用する必要があります。 各評価項目につき、少なくとも1つの根拠エントリを含め、それぞれに出典情報（doc_quote、reviewer_inference、unverified_assumption、source_backed、notes_cross_ref のいずれか）を付けてください。
3. 文書に記載された事実とレビュアーの推論を区別してください。 出典情報でフィルタリングする下流の利用者が、文書に書かれている内容とレビュアーが導いた結論を区別できるようにしてください。これは評価パイプラインにおいて、最も重要な品質指標です。
4. 7つの評価項目すべてと、5つの不適切な戦略パターンすべてを常に含めてください。 該当しないパターンには detected: false を使用します。これにより、利用者が扱うフィールド数を一定にできます。
5. 文章に記載されている場合は、任意のシグナルも含めます。 スキーマでは、任意のトップレベル strengths 配列、トップレベル recommended_next_steps 配列、review_metadata.review_id 識別子、notes_cross_reference オブジェクト（patterns_that_crept_back と thinking_sharpened_then_softened サブ配列を含む）も受け付けます。文章によるレビューに対応するセクションがあり、さらに notes_cross_reference についてはノートが利用可能な場合、対応する JSON フィールドを出力してください。それ以外の場合は、空の値を含むだけの項目を出力せず、省略してください。
6. ブロッキング対象の指摘は報酬シグナルの条件になります。 集計スコアが少なくとも Adequate であり、かつブロッキング対象としてマークされた指摘がない場合に限り、戦略は合格となります（reward_signal.pass: true）。
7. 出力前に検証してください。 JSON が解析可能であること、必須フィールドが存在すること、スコアがラベルと一致すること、加重合計が算術的に正しいことを確認してください。スキーマリファレンスの検証チェックリストを参照してください。

集計スコアの算出

集計値は、7つの評価項目のスコアを加重して算出した複合値です：

評価項目	重み
診断の品質	20%
指針となるポリシーの強さ	20%
アクションの一貫性	15%
カーネルチェーンの整合性	15%
不適切な戦略パターン	10%
前提の明示	10%
具体性／反証可能性	10%

weighted_total = Σ(score × weight / 100)。範囲：1.0～4.0。集計ラベルは次のとおりです：Strong（≥3.5）、Adequate（≥2.5）、Weak（≥1.5）、Missing（<1.5）。

報酬シグナルは0.0～1.0の範囲に正規化されます：(weighted_total - 1.0) / 3.0。

正本： 正規の重み定義、しきい値テーブル、検証ルールは references/judge-artifact-schema.md に記載されています。これらの値が更新された場合は、両方の箇所を更新してください。

リファレンスファイル

• references/review-dimensions.md — 7つの評価項目と、詳細な基準、例、よくある失敗パターン。
• references/review-lenses.md — 4つの相補的なレビュー視点（7S、スコアカード、ファイブフォース、方針管理）と、適用条件、質問、よくある不足事項。
• references/interview-lens-audit.md — インタビュー視点の調査結果（Wardley、Playing to Win、Blue Ocean）が草案に反映されているかを確認するための監査基準。
• references/review-template.md — 出力ファイル strategy-review.md の正確な構成。
• references/judge-artifact-schema.md — 機械可読な審査成果物の JSON スキーマ。フィールド構造、スコアの対応付け、根拠の出典情報ルール、検証チェックリスト、文章出力との関係を定義します。
• references/pressure-tests.md — よくあるレビューシナリオで期待される動作。スキルの検証に使用します。