診断レポートに仕上げ、自分で落とす

このコマで何ができるようになるか

• ここまで作ってきた実測データ・AI検索プローブ表・7軸スコア表を、支援先に提出できる1本のレポートにまとめられるようになります。
• 経営者が最初の1枚だけを読んで意思決定できる構成を設計できるようになります。
• 「このレポートが測っていないもの」を明記し、実測の限界を誠実に示せるようになります。
• 提出する前にAIに別人格で批評させ、自分の成果物を一度落としてから出す、という手順を身につけます。

なぜこれが必要なのか

実測データも、AI検索プローブの結果も、7軸スコアも、それぞれは断片的な材料に過ぎません。バラバラのままでは、支援先の経営者に渡しても、何から読めばよいのか、結局何が言いたいのかが伝わりません。これらを1本のレポートに組み立て直し、最初の1枚で全体像が伝わる形にする工程こそが、診断士の専門性が最も表れる部分です。

このレポートには、診断士自身の名前が乗ります。中に誤った数字や、根拠のない断定が1つでも残っていれば、それは単なる誤字脱字の問題では済みません。支援先の意思決定を誤った方向に導くおそれがあり、診断士自身の信頼にも関わります。だからこそ、書き上げて終わりにせず、提出する前に検査する工程をセットにしておく必要があります。この検査の型は、Day3で作る提案書でも同じ手順を使います。

押さえる考え方

経営者が「最初の1枚」で意思決定できる並べ方

診断レポートは、①最初の1枚（サマリー）②現状の実測結果③競合との比較④課題（重要な順）⑤改善アクション（すぐできること・時間がかかること）⑥根拠データ（出典つき）という6つの部分で構成します。この中でも最初の1枚がもっとも重要です。湘南精密工業（演習用の架空企業）の中村社長のように、打ち合わせの時間が夕方以降しか取れず、Web・ITの専門知識を前提にできない経営者を想定すると、最初の1枚だけで「何が問題で、次に何をすべきか」が伝わっている必要があります。詳しい説明は、後続のページに送ります。

すべての数字に出典をつける

レポートに載せる数字には、どのファイルの、いつ取得したデータかという出典を添えます。出典のない数字は、あとから支援先や第三者に問われたときに、根拠を示せなくなります。ここまでのコマで積み上げてきた「出典を残す」という習慣が、レポートという最終的な成果物の中で初めて意味を持ちます。

効果を断定しない

「この施策をすれば、問い合わせは増えます」と言い切る書き方は避けます。景品表示法の観点からも、診断士の名前で出す資料としても、成果を保証するような書き方は避けるべき対象です。代わりに、「問い合わせが増える見込みがあります。根拠は〜」のように、見込みとその根拠をセットで書きます。この言い換えは、単なる言葉づかいの問題ではなく、この先ずっと使う専門職としての作法です。

「このレポートが測っていないもの」を必ず書く

このレポートは、実測できた範囲の中では正確です。しかし、実測できなかった範囲——アクセス解析のようなログインが必要なデータ、支援先の内部の営業プロセス、顧客の生の声など——については、何も語っていません。レポートの末尾に「このレポートが測っていないもの」という項目を必ず設け、実測の外側にある部分を明記します。これは弱さの告白ではなく、次に何を確認すべきかを示す誠実な線引きです。この一文があることで、支援先は「このレポートで分かること」と「まだ分かっていないこと」を区別して受け取れるようになり、D3以降で扱う戦略立案への期待値も適切に保てます。

出す前に、AIに別人格で批評させ、自分で一度落とす

レポートを作った直後は、書いた本人も、AIも「よくできた」という前提で読んでしまいがちです。ここで有効なのが、同じAIに、作成者ではなく批判する側という別人格を与えて読み直させる方法です。出典の有無、出典と元データの一致、根拠の弱い断定、支援先の資料にない情報の混入、誇大な表現——この5点を検査させます。指摘が1つでも見つかれば、その時点でこのレポートは「まだ提出できる状態ではない」と自分で一度判定します。合格を急がず、一度落としてから直すという順番を守ることが、結果的に提出までの近道になります。問題が見つからなければ「問題なし」とだけ書かせ、無理に指摘を作らせないことも大切です。指摘を無理に作られてしまうと、本当に直すべき箇所が埋もれてしまいます。

手を動かす手順

1. これまで作った実測データ・AI検索プローブ表・7軸スコア表の3点を、フォルダの中で確認します。保存場所がばらばらであれば、この時点で 02_診断/ にまとめます。
2. プロンプト集の「診断レポートを1本仕上げる」（diagnosis-04）を使い、6章構成でレポートの通し原稿を作成させます。読む人（湘南精密工業 代表 中村健一様、Web・ITの専門知識はない前提）を指示に含めます。
3. 原稿の末尾に「このレポートが測っていないもの」の項目を追加させます。アクセス解析のような未実施の実測、ヒアリングでは拾えていない情報を具体的に列挙させます。
4. できあがった原稿から「最初の1枚」だけを取り出し、演習相手に読んでもらいます。それだけで「何が問題で、次に何をすべきか」が伝わるかを確認してもらいます。
5. プロンプト集の「作った資料の数字と事実を検算する」（quality-01）を使い、今作ったレポートを検査させます。「批判する側の立場で読んでください」という指示を、確認事項として指示に含めます。
6. 検査結果の表（該当箇所／何が問題か／どう直すか）を確認し、指摘された箇所を1つずつ原稿に反映します。「問題なし」と出た項目も、そのまま記録に残します。指摘が1件でもあれば、この時点でレポートを「まだ提出できない状態」として扱い、直してから次に進みます。
7. 効果を断定する表現が残っていないか、自分の目でもう一度、原稿全体を通して読みます。
8. 04_成果物/ に保存します。
9. 完成したレポートを演習相手と交換し、「自分が中村社長だったら、この1枚で何をすべきか分かるか」という視点で読んでもらいます。

つまずきやすいところ

• 情報を詰め込みすぎて「最初の1枚」が2枚、3枚になってしまう：経営者が最初に読むのはこの1枚だけという制約を先に決めてから書き直します。詳細は後続のページに送ります。
• 改善アクションが「全部やりましょう」になってしまう：月10万円程度までという予算感（湘南精密工業のヒアリングで出た、正式合意ではない目安の数字）を思い出し、すぐできることと時間がかかることの粗い仕分けにとどめます。優先順位の本格的な設計はDay3で扱います。
• quality-01の検査を、レポートを作ったのと同じ流れの中で軽く流してしまう：「批判する側の立場で」という一文が指示に入っているかを確認します。同じAIでも、立場を変えると指摘の質が変わります。
• 検査で「問題なし」ばかり返ってきて、本当に検査になっているか不安になる：出典が実測データと一致しているかを、少なくとも数か所は自分の目でも照合します。AIの「問題なし」を最終判定にはしません。
• 60分で仕上げようとして時間が足りなくなる：まず6章の見出しと各章1文の結論だけを先に確定させ、肉付けは残り時間で行います。
• 「測っていないもの」の欄が空白か、当たり障りのない一言で終わってしまう：アクセス解析・営業プロセス・顧客の生の声など、実測データ.md に載っていない情報を具体的に挙げます。「特にありません」で済ませないようにします。

このコマが終わったときの状態

• 実測データ・AI検索プローブ表・7軸スコア表を統合し、6章構成のレポートを1本作成した
• 最初の1枚だけで、経営者が「何が問題で、次に何をすべきか」を理解できる状態になっている
• 「このレポートが測っていないもの」を具体的に書いた
• すべての数字に出典（ファイル名・取得日）が添えられている
• 効果を断定する表現がないことを、自分の目で確認した
• 批判する側の立場でAIに検査させ、指摘事項を反映した、または「問題なし」を記録した