生成AI活用 実践講座診断士のための「診断→提案→伴走」4日間

資料室

中小企業診断士のためのAI活用 失敗事例集

この事例集について

5つの分類

分類件数どんな失敗か
1. 信用を失う失敗5件顧問先に出した資料そのものが間違っていた
2. 守秘義務にかかわる失敗5件入れてはいけない情報が、入ってはいけない場所に入った
3. 法令にかかわる失敗5件士業の名前で出す資料・助言が、規制や業務範囲に触れうる内容になった
4. 仕事が増える失敗5件AIに任せたつもりが、確認・やり直しでかえって時間を食った
5. 顧問先との関係が壊れる失敗5件資料の中身は間違っていなくても、伝え方・進め方で信頼を損なった

合計25事例。

1. 信用を失う失敗

事例1：AI検索の「見え方」を、実測せずに書いた

何が起きたか ある診断士が、顧問先の生成AI検索での見え方を診断レポートに書いた。AI検索プローブ表を作る際、質問だけでなく回答欄までAIに埋めさせ、その内容を「実際にAIがこう答える」として確認せずレポートに転記した。提出後、経営者が自分のスマートフォンで同じ質問を生成AIに打ち込んだところ、レポートに書かれた内容と実際の回答が一致しなかった。

なぜ起きたか AIに「質問と回答をセットで作らせた」ことが原因である。回答欄をAIに埋めさせると、それは実測ではなくAI自身の予測になる。診断士がこの違いを区別せず、予測結果を実測結果として扱ったことが唯一の原因である。

どうすれば防げたか AI検索プローブ表を作るプロンプト（diagnosis-02）は、回答欄を空のままにして質問だけを作らせる設計になっている。この設計を守り、回答欄は診断士自身が生成AIの画面に打ち込んで埋める。「AIに、AI自身がどう答えるかを予想させない」という一点を守るだけで防げる。

関連するコマ：D2-1

事例2：決算書の科目名をAIが揃え直し、数字がズレて見えた

何が起きたか ある診断士が、顧問先の3期分の決算書をAIに読み込ませて推移表を作らせた。決算書ごとに科目名の表記が微妙に異なっていたが、AIはこれを「同じ科目」として自動的に一つにまとめて集計した。できあがった推移表を検算せずに提出したところ、経営者から「この科目、去年の決算書にはこの数字は無いはずだ」と指摘を受けた。

なぜ起きたか 決算書の書式は会社によって違うことがある。AIが科目名を独自に正規化（表記の違うものを同じ扱いにまとめること）してしまい、本来別の性質の数字が合算された。診断士がその正規化の過程を確認しなかったことが原因である。

どうすれば防げたか 決算書の数字を扱う指示には「科目名は資料に書かれている表記のまま使い、似た科目名を勝手に統合しない」という条件を必ず入れる。出力後は、各年度の数字がどの元資料の言葉から来ているかを1つずつ突き合わせる。

関連するコマ：D2-1

事例3：別の顧問先の名前が資料に残ったまま渡した

何が起きたか 複数の顧問先を掛け持ちしているある診断士が、提案書のテンプレートを流用して別の顧問先向けの資料を作らせた。本文の大半は書き換わっていたが、見出しの1か所に前の顧問先の社名が残ったまま提出してしまった。

なぜ起きたか テンプレートの置き換え漏れを、提出前に機械的に検査する工程を挟まなかったことが原因である。AIは指示された本文は書き換えるが、見出しやファイル名まで漏れなく置き換えたかどうかを、指示しない限り自分から検査しない。

どうすれば防げたか 渡す直前の最後の確認として、他社の会社名・数字が紛れ込んでいないかを機械的に検査するプロンプト（quality-03）を通す。これは資料の中身が正しいかどうかではなく、取り違え・置き換え漏れの有無だけを検査する専用の工程であり、内容の検査とは別に必ず1回通す。

関連するコマ：D2-3、D3-3、D4-1

事例4：資料の数字が新旧で食い違ったまま出た

何が起きたか ある診断士が、支援先フォルダに残っていた初回ヒアリングの売上見込みと、その後届いた実際の決算資料の数字が食い違っていることに気づかないまま、AIにフォルダ全体を要約させた。AIは新旧どちらかの数字を選んで要約に採用し、診断士もそれを検算せずに診断レポートへ転記した。

なぜ起きたか 複数ファイルを横断して読ませる際に、「数字が食い違う場合は、食い違い自体を報告し、勝手にどちらかを採用しない」という条件を指示に含めなかったことが原因である。この条件がないと、AIは古い資料と新しい資料のどちらかを、根拠のないまま選んでしまう。

どうすれば防げたか フォルダ全体を要約させるプロンプト（knowledge-01）には、この条件があらかじめ組み込まれている。この型を外さずに使い、出力に「食い違い」の報告が出てきたら、必ずどちらが正しいかを診断士自身が確認してから次の工程に進む。

関連するコマ：D1-3

事例5：存在しない「業界平均」を根拠に低評価と書いた

何が起きたか ある診断士が、顧問先の経営指標を同業他社と比較する資料を作らせた際、業界平均データの出典を自分で用意せず、AIに「この業種の業界平均を教えて」と聞いてそのまま使った。できあがった比較表を「業界平均より収益性が低い」という表現で診断レポートに載せたが、後で経営者側の顧問税理士から、その業界平均の出典を尋ねられ、答えられなかった。

なぜ起きたか 業界平均データをAIの一般知識に頼ったことが原因である。AIは、出典を明示できない数値でも、それらしい体裁で提示してしまうことがある。

どうすれば防げたか 業界平均・同業比較を扱うプロンプト（finance-03）は、業界平均データを診断士自身が出典（中小企業実態基本調査、TKC経営指標など）とともに指定する設計になっている。出典を自分で用意できないデータは、比較に使わないという原則を徹底する。

関連するコマ：D2-2

2. 守秘義務にかかわる失敗

事例6：オンライン面談中の画面共有に、別の顧問先フォルダが映り込んだ

何が起きたか ある診断士が、オンライン面談中に自分の作業画面を共有した際、バックグラウンドで開いたままだった別の顧問先のフォルダ名が、ウインドウの切り替えの瞬間に映り込んだ。相手はそれに気づいて指摘し、その場で謝罪する事態になった。

なぜ起きたか 画面共有前に、共有する範囲を絞り込む・不要なウインドウを閉じるという確認を省略したことが原因である。AIの操作そのものではなく、画面共有という周辺作業の準備不足によって起きた。

どうすれば防げたか 面談で画面共有をする前に、共有するウインドウ・タブだけを開いた状態にし、他の顧問先のフォルダやチャット画面をすべて閉じてから接続する。仕組みで自動的に防げるものではなく、面談前のチェックとして習慣化する。

関連するコマ：D1-2

事例7：非公表の決算数値を、設定未確認のままAIに貼り付けた

何が起きたか ある診断士が、契約したばかりのAIサービスの初期設定（入力内容が学習に利用されるかどうか）を確認しないまま、顧問先の非公表の決算数値をチャット欄に貼り付けて分析を依頼した。後になって、そのサービスの初期設定では入力内容が学習に利用されうる状態だったことに気づいた。

なぜ起きたか AIサービスごとに初期設定が異なり、しかも仕様が変わり続けることを確認しないまま使い始めたことが原因である。「便利そうだから」という理由だけで、設定確認という一手間を飛ばしてしまった。

どうすれば防げたか 新しいAIサービスを契約したら、機微な情報を入力する前に、必ず学習利用のオプトアウト設定・保存期間・管理者設定を確認する。この確認は一度した内容を覚えておくのではなく、契約時点の公式情報をそのつど確認する習慣にする。

関連するコマ：D1-2

事例8：バックアップのつもりでアップロードした資料が、削除しても残った

何が起きたか ある診断士が、作業中のファイルを紛失しないようにという善意から、顧問先の資料が入ったフォルダをそのままGit（変更履歴を記録する仕組み）にアップロードした。後で機密情報が含まれていることに気づきファイルを削除したが、履歴には過去のアップロード内容が残ったままだった。

なぜ起きたか 「削除すれば消える」という思い込みで、Gitの履歴の仕組みを理解しないままアップロードしたことが原因である。共有先やサービス側に複製が残る操作は、後から取り消せない。

どうすれば防げたか 顧問先の資料をアップロードする前に、それが後から取り消せない操作かどうかを必ず確認する。Git連携を使う場合は、機密情報を含むフォルダをアップロード対象から除外する設定を、使い始める前に済ませておく。

関連するコマ：D1-2

事例9：マスキングすれば安全だと思い、パスワードをそのまま渡した

何が起きたか ある診断士が、顧問先のクラウドサービスの設定についてAIに相談する際、会社名や個人名はマスキング（伏せ字化）したうえで、ログイン用のパスワードとAPIキーの値だけはそのまま貼り付けて質問した。「社名を隠したから大丈夫」という判断だった。

なぜ起きたか 情報の機密性を「社名や数字を隠せば下がる」という一般則で捉え、認証情報が持つ性質の違いを理解していなかったことが原因である。認証情報はマスキングの有無にかかわらず、値そのものが機密の本体であり、一部を隠すという発想が成立しない。

どうすれば防げたか 認証情報（パスワード・APIキー・トークン等）は、他の情報とは別枠のルールとして扱う。設定について相談したい場合でも、共有してよいのはエラーメッセージの内容・設定項目の名前・実施した手順までとし、値そのものは入力しないと決めておく。

関連するコマ：D1-2

事例10：フォルダの分離を誤り、複数の顧問先情報が同じ場所でAIに読まれた

何が起きたか ある診断士が、複数の顧問先の資料を1つの共通フォルダにまとめて保存していた。ある顧問先向けの作業でAIにフォルダ全体を読み込ませたところ、意図せず別の顧問先の資料まで一緒に読み込まれ、出力の中に無関係な顧問先の情報が混ざって出てきた。

なぜ起きたか 顧問先ごとにフォルダを分離するという最初の設計を怠ったことが原因である。AIは指定された範囲を読みに行くため、フォルダの区切りが甘いと、複数の顧問先の情報を同時に読み込んでしまう。

どうすれば防げたか 支援先ごとに独立したフォルダを作り、AIへの指示では対象の顧問先フォルダだけを名指しして読ませる。「支援先フォルダをまたいで読まない」というルールを、CLAUDE.mdのような常設の指示書にあらかじめ書いておく。

関連するコマ：D1-2、D1-3

3. 法令にかかわる失敗

事例11：誇張された実績表現を含む記事を、確認せず公開直前まで進めた

何が起きたか ある診断士が、顧問先の記事をAIに作成させた際、AIが顧問先の資料にない「業界最速」「満足度No.1」といった表現を補って書いた。誇大表現を検査するプロンプトを通す工程を省略し、その内容のまま顧問先に「このまま公開して大丈夫です」と伝えてしまった。

なぜ起きたか AIが作った文章を、事実に基づく記述と一般論・誇張の記述に分けて確認する工程を省略したことが原因である。AIは指示すれば断定的な効果表現や最上級表現もそれらしく書いてしまう性質があり、これをチェックせずに通すと危険な表現がそのまま残る。

どうすれば防げたか 記事・LP・広告文を作らせたら、誇大表現・法令リスクを検査するプロンプト（quality-02）を必ず1回通す。この検査は「該当箇所／なぜ問題になりうるか／言い換え案」を出す設計であり、指摘の有無にかかわらず人間の目でも最終確認する。

関連するコマ：D4-1

事例12：提案書で施策の効果を断定的に書いた

何が起きたか ある診断士が、提案書の「打ち手」の章で、AIが作成した文案をほぼそのまま使い、「この施策を実施すれば売上が向上します」という言い切りの表現を残したまま経営者に提出した。

なぜ起きたか 「効果を断定しない」という言い換えのルールを、診断レポートでは意識していたが、提案書の文章を作る際には同じ注意を払わなかったことが原因である。資料の種類が変わると、同じ注意点でも抜け落ちやすい。

どうすれば防げたか 提案書ドラフトを作るプロンプト（strategy-04）には「成果を保証する表現を使わない」という条件が含まれている。この条件は診断レポート・提案書・広告文など、成果物の種類を問わず毎回適用し、「見込みがあります。根拠は〜」という言い方に統一する。

関連するコマ：D3-3

事例13：AIの「言い換え」を、法的に問題ないという意味だと受け取った

何が起きたか ある診断士が、誇大表現の検査プロンプトを通したところ、AIが該当箇所について「〜にあたる可能性がある」という指摘を出した。その後、診断士が「では問題ないという理解でよいか」と聞き返したところ、AIが「大丈夫です」と言い切る形で返答し、診断士はそれを根拠に修正せずそのまま進めてしまった。

なぜ起きたか AIに法的な結論を断定させない、という運用の原則を、検査の1回目だけでなく、その後のやり取り全体で守らなかったことが原因である。AIは会話の流れの中で、断定的な言い方に引きずられて返答することがある。

どうすれば防げたか AIの返答が言い切りの形になっていたら、それ自体を疑う。法的な論点は最終的に診断士本人と、必要に応じて専門家（弁護士など）が判断するという役割分担を、会話のどの段階でも崩さない。

関連するコマ：D4-1

事例14：事業承継の論点を、法的な結論として経営者に伝えてしまった

何が起きたか ある診断士が、事業承継のヒアリング内容をAIに整理させた際、遺留分（相続人に最低限保証される取り分）や株式評価に関する論点について、AIが出した説明を「こうすればよい」という結論として理解し、経営者にそのまま助言してしまった。

なぜ起きたか 論点整理と法的な結論を区別せずに受け取ったことが原因である。相続・税務・法務に関わる論点は、AIに整理させてよい範囲と、専門家の判断が必要な範囲が異なる。

どうすれば防げたか 事業承継の論点整理プロンプト（succession-01）は、法的な結論を断定せず、論点として挙げるだけにする設計になっている。この設計のとおり、AIの出力は「確認すべき論点のリスト」として扱い、税理士・弁護士へつなぐ前提で使う。

関連するコマ：D2-1

事例15：補助金申請書類の作成を、AIにそのまま代行させた

何が起きたか ある診断士が、顧問先向けに補助金の公募要領を読み解いた後、そのままの勢いでAIに申請書類の下書きを作らせ、ほぼ手を加えずに顧問先へ提出用として渡してしまった。

なぜ起きたか 公募要領の「読み解き」と、申請書類の「作成代行」を同じ作業の延長として扱ってしまったことが原因である。申請書類の作成代行は、業務の性質によっては行政書士法の規制対象になりうる。

どうすれば防げたか 公募要領を読み解くプロンプト（office-02）は、要領の読み解きに限定する前提で設計されている。診断士としてどこまでを担ってよい業務かを、着手前に自分の資格の業務範囲に照らして確認し、申請書類の作成そのものは専門家（行政書士等）につなぐか、範囲を明確にしたうえで対応する。

関連するコマ：D3-1

4. 仕事が増える失敗

事例16：検算せずに出した数字が後で崩れ、全部やり直した

何が起きたか ある診断士が、7軸スコア表の採点結果を検算せずに提出した。経営者から「この点数はどの数字を見て付けたのか」と1つずつ質問され、答えられない項目が複数あった。持ち帰って検算したところ根拠のずれている項目が見つかり、結局スコア表全体を作り直すことになった。

なぜ起きたか 「AIが作った表だから、体裁が整っていれば大丈夫」という思い込みで、検算の工程を省いたことが原因である。検算にかかる時間を惜しんだ結果、その何倍もの時間をやり直しに使うことになった。

どうすれば防げたか 出典突合・配点整合・ゆれ確認という3つの検算手順を、時間が無くても配点の高い軸だけは必ず行う。検査の1手間は、やり直しの手間より確実に少ない。

関連するコマ：D2-2

事例17：手順書に自分の判断まで書き込み、AIが毎回勝手に決めてしまった

何が起きたか ある診断士が、定型業務をAIに任せられる手順書に変える際、「支援先の優先度が高いと判断したら」というように、本来は自分が下すべき判断まで手順書に含めてしまった。結果、AIが実行のたびに独自の基準で優先度を判定し、診断士の意図と違う順番で作業が進んでしまい、そのつど手直しが必要になった。

なぜ起きたか 「AIに任せてよい作業」と「診断士本人が判断すべきこと」を分けずに手順書を作ったことが原因である。判断を含む手順書は、AIに再現させると診断士の意図とずれる。

どうすれば防げたか 手順書を作るときは「私の判断が必要なところを、AIに任せる側に入れない」という条件を必ず入れる。できあがった手順書は、任せてよい部分だけが自然に切り出されているかを自分の目で確認してから使う。

関連するコマ：D1-3

事例18：施策表が「全部やりましょう」になり、打ち合わせをやり直した

何が起きたか ある診断士が、診断レポートから施策を洗い出す際、効果・確度・工数を採点させたものの、上位に絞り込む工程を省略し、洗い出された施策をすべて並べたまま提案書に載せた。経営者との打ち合わせで「結局何から始めればいいのか」と聞かれ、その場で優先順位を決め直すことになり、追加の打ち合わせが必要になった。

なぜ起きたか 優先順位表の役目が「やらないことを決める」ことにあるという前提を外し、洗い出した施策を絞り込まずにそのまま渡したことが原因である。

どうすれば防げたか 施策に優先順位をつけるプロンプト（strategy-01）を使う際、「全部やる案は出さない。やらないことを決めるための表」という条件を外さない。上位に入らなかった施策は「見送り」と明記したうえで提案する。

関連するコマ：D3-1

事例19：測定方法を曖昧にしたまま進め、結局自分で数え続けることになった

何が起きたか ある診断士が、KPI設計の際に測定方法を「Webサイトのアクセスを見る」という程度の粗さのまま確定させ、顧問先に運用を任せた。実際には顧問先の担当者はどのツールのどの画面を見ればよいのか分からず、結局、毎月診断士が自分でアクセス解析にログインして数字を数える運用になってしまった。

なぜ起きたか 測定方法を「どのツールの、どの画面の、どの数字か」まで具体化しないまま設計を終えたことが原因である。曖昧な測定方法は、支援先が自分で再現できない。

どうすれば防げたか KPI設計のプロンプト（strategy-03）を使う際、測定方法の欄が具体的な画面・数値名まで書かれているかを確認する。支援先が自分で測れる形になっていない場合は、最初の数回だけ診断士が伴走する設計に落とし、無理に「支援先が測る」ことにしない。

関連するコマ：D3-2

事例20：保存場所を決めずに作業し、必要な資料を毎回探す羽目になった

何が起きたか ある診断士が、複数の成果物をそのつどAIに保存させていたが、保存先のルールを決めていなかったため、同じ種類の資料がフォルダのあちこちに分散した。次の面談の準備で必要な資料を探すのに、毎回時間がかかるようになった。

なぜ起きたか フォルダ構成のルール（どの種類の資料をどこに置くか）を最初に決めず、AIに保存を任せきりにしたことが原因である。AIは指示されなければ、保存場所を毎回一貫させるとは限らない。

どうすれば防げたか 支援先フォルダを整える段階で、基本情報・ヒアリング・診断・提案・成果物のように置き場所を先に決め、保存の指示には毎回どのフォルダに置くかを明記する。置き場所に迷ったら、フォルダ内の索引ファイルを確認する運用にする。

関連するコマ：D1-3

5. 顧問先との関係が壊れる失敗

事例21：「診断士の範囲」と「外注の範囲」を曖昧にしたまま受注した

何が起きたか ある診断士が、提案書で戦略立案から実制作までを一括して引き受けるかのような書き方をしたまま受注した。経営者は「頼んだことは全部診断士がやってくれる」と受け取り、Webサイトの細かな修正や広告の入稿作業まで依頼してきた。診断士は当初、戦略立案の工数で見積もっていたため対応しきれず、関係がぎくしゃくした。

なぜ起きたか 提案書の「進め方と体制」の章で、診断士が担う範囲と外注が必要な範囲を明確に分けて書かなかったことが原因である。ここが曖昧なまま受注すると、支援先の期待と診断士の想定が最初からずれる。

どうすれば防げたか 提案書ドラフトを作る段階で、「誰が」「何を」「いつまでに」やるかを明記し、外注が必要な項目には費用に含むか別途かの区別まで付ける。受注前にこの区分を経営者と共有し、合意してから着手する。

関連するコマ：D3-3、D4-1

事例22：良い数字だけを強調した月次報告を続け、実態とのギャップで信頼を失った

何が起きたか ある診断士が、月次レポートで成果が伸び悩んでいる指標を目立たせないよう小さく扱い、良い数字だけを強調する報告を数か月続けた。ある月、経営者が自分で数字を確認したところ、報告されていた印象と実態にギャップがあることに気づき、それまでの報告全体への信頼を失ってしまった。

なぜ起きたか 「支援先に良く見せたい」という心理が、数字の扱い方に無意識に反映されたことが原因である。良い数字と悪い数字を同じ扱いで書くという原則を、報告を重ねるうちに崩してしまった。

どうすれば防げたか 月次レポートを作るプロンプト（monitoring-01）は、良い数字も悪い数字も同じ扱いで書き、取得できなかったデータも隠さない設計になっている。レポートを出す前に、悪い数字が薄められていないかを診断士自身が読み返して確認する工程を、毎回欠かさず行う。

関連するコマ：D4-2

事例23：AIを使っていることを伏せたまま資料を渡し、後で発覚して信頼を落とした

何が起きたか ある診断士が、AIを使って作成した診断レポートを、その旨に触れないまま提出していた。数か月後、経営者が別の場面でAIエージェントの存在を知り、「これまでの資料もAIが作ったものだったのか」と尋ねてきた。診断士が言葉を濁したことで、経営者は「最初から言ってくれればよかったのに、なぜ黙っていたのか」という不信感を持った。

なぜ起きたか AIの利用を隠すこと自体に実務上の必要性がなかったにもかかわらず、伝えるタイミングを決めていなかったことが原因である。専門的な判断・検算・最終確認は診断士自身が行っており、AIは道具として使っているに過ぎないが、その説明を怠ったことで「隠していた」という受け取られ方をした。

どうすれば防げたか AIエージェントをどう使っているか（下書きの作成を効率化する道具であり、検算・最終判断は診断士が行うこと）を、契約や初回の面談の段階で経営者に一言説明しておく。隠す・伏せるという扱いにせず、道具の使い方として先に共有する。

関連するコマ：D1-1

事例24：支援メニューの説明が、成果保証と受け取られる言い方になっていた

何が起きたか ある診断士が、自分の支援メニューを説明する営業文を作らせた際、「このメニューで成果が上がります」という表現をそのまま使った。契約後、期待した成果が出なかった顧問先から「保証されたはずだ」という受け止め方をされ、返金を求められる事態になった。

なぜ起きたか 支援メニューの説明文についても、記事や広告文と同じ検査が必要だという意識が抜けていたことが原因である。営業の場面で使う言葉には、資料作成のときほど慎重な検査をかけていなかった。

どうすれば防げたか 支援メニューを設計するプロンプト（menu-01）は、成果保証を前提としたメニューにしないという条件を含んでいる。営業文・説明文についても、記事や広告文の検査と同じ観点（誇大表現・断定表現）を自分の目で確認してから使う。

関連するコマ：D4-3

事例25：「次へ進む条件」を曖昧にしたまま提案し、段階の移行で揉めた

何が起きたか ある診断士が、予算に応じた3段階の提案をした際、各段階から次の段階へ「進む条件」を「効果が出たら」という主観的な表現のまま提示した。第1段階の終わりに、診断士は「十分な手応えがあった」と判断して次の段階への投資を提案したが、経営者は「まだ効果が出たとは思えない」と感じており、双方の認識が食い違って話が止まってしまった。

なぜ起きたか 「次へ進む条件」を、測れる数字ではなく主観的な言葉のまま確定させたことが原因である。条件が数字になっていないと、達成したかどうかの判断が双方の感覚に依存し、食い違いが起きる。

どうすれば防げたか 段階提案を作るプロンプト（strategy-02）を使う際、各段階の「次へ進む条件」を、問い合わせ件数など測れる数字に必ず置き換える。条件を経営者と事前に共有し、数字で合意しておく。

関連するコマ：D3-1

この事例集の使い方

← 資料室へ戻る