AIが書いたショートケースは、なぜ「惜しい」のか
～AIが学び、ヒトが気づく。ショートケースづくりの舞台裏～
PMI日本支部 関西ブランチ PM実践研究会
PMI日本支部 関西ブランチ プロジェクトマネジメント実践研究会では、ショートケースメソッドを用いた実践ワークショップを長く続けてきました。10数行のリアルなプロジェクト場面を読み、参加者全員で「どこが懸念か」「では何をするか」を検討する、疑似体験型のワークショップです。参加者が自分の現場の苦労を持ち寄り、互いの実践知を交換できる場として、研究会の活動のなかでも最も高い評価をいただいてきました。
この記事では、そのショートケースを「どうやって作っているのか」という舞台裏をご紹介します。とくに、2025年から本格的に取り入れた生成AIとの協働で見えてきたことを、なるべく具体的にお伝えしたいと思います。
舞台裏は、決して華やかではなかった
ワークショップで配られるショートケースは、たった10数行です。しかし、その10数行が完成するまでに、研究会のメンバーは50時間を超える作業を積み上げてきました。リードタイムはおよそ4週間。夜間や週末の作業が常態化していました。
経験者へのインタビュー、文字起こしの読み込み、数千字の素描づくり、そしてことばを一つひとつ紡ぎ出すようなレビューの繰り返し。作るだけで精一杯で、カイゼンや新しいネタの開発にまで手が回らない。結果として、学習者に届けるスピードにも質の向上にも限界が見えていました。
そこで生成AIを作成プロセスに組み込みました。効果は明確で、インタビューの文字起こしからケース原稿の土台が立ち上がるまでの時間は、劇的に短くなりました。
ところが、出てきた原稿を読んだメンバーの第一声は、称賛ではありませんでした。
「よく書けている。でも、惜しい」
「惜しさ」の正体を、7ケース分ほどいてみた
この「惜しい」という感覚は何なのか。研究会では、AIが生成した7本のショートケースに対して、ベテランPM実践者2名によるHITL（Human-in-the-Loop）レビューを実施しました。
やり方はシンプルです。AIが本文を一文ずつのチャンクに分割し、表の形にする。AI自身が「ここは自信がない」「原文で確認できていない」と思う箇所に指摘マークを付ける。そのうえで、レビュアーが1行ずつコメントを書き込んでいく。
集まったコメントから抽出された気づきは、31件にのぼりました。並べて分類していくと、バラバラに見えた指摘が、5つの癖にきれいに収斂していきました。
AIに文章を書かせたことがある方なら、おそらく見覚えのある「あるある」だと思います。
1. 盛りすぎ
| インタビュー原文 | 「きっと間違いなく失敗するよねって言われてて。」（当時、周囲から言われた言葉としての報告） |
| AI生成 | 周囲は「きっと間違いなく失敗する」と見ていた |
| レビュー後 | 周囲は「たぶん失敗するよね」と見ていた |
AIは、報告調の「って言われてて」という揺らぎを取り払い、断定形の強いセリフに変えていました。原文にない強度が足されている。教材としては、読者の解釈の余地がそのぶん削られます。
2. 断定
| インタビュー原文 | 当時を知る技術者は、退職や異動で社内に散らばっていた |
| AI生成 | 当時を知る技術者がすでに社内にいない |
| レビュー後 | 当時を知る技術者が散逸している |
「散逸している」と「いない」は、まったく違う状態です。前者ならば探しにいくという選択肢が残りますが、後者ではその道が閉じてしまいます。AIは全称命題に寄せて断定しがちで、その一語が読者の前提を壊してしまいます。
3. 因果の補完
| インタビュー原文 | 「工程を並行化した」「設計の遅れが発生した」（順に語られた2つの事実） |
| AI生成 | 工程の並行化が設計遅れを招き、品質の手戻りが発生した |
| レビュー後 | 工程の並行化と、設計フェーズでの遅れの発生 |
語り手は2つの事実を順に述べただけで、因果関係には触れていません。AIはそこに「が招き」という接続を勝手に補いました。この一語で、本来は読者が考えるべき因果が、あらかじめ答えとして書かれてしまいます。
4. 説明過多
| インタビュー原文 | 品質強化試験の実施回数、追加で要した時間とコストまで詳細に語られた |
| AI生成 | （語られた数値を漏らさず拾い、結末まで書ききった） |
| レビュー後 | 本件は複数の手戻りが発生する事態となった |
インタビューでは、失敗の顛末が具体的な数字とともに語られました。AIはそれを几帳面にすべて拾いました。しかし教材として全部書いてしまうと、それは答え合わせです。状況設定で止めるからこそ、参加者は議論を始められます。
5. 時点の無視
| インタビュー原文 | 「最初は項目を全部洗い出した。後で見直したら数分の1にできた」（要旨） |
| AI生成 | 計画時点で試験項目は◯◯件あり、すべて実施する計画とした |
| レビュー後 | 計画時点では試験項目を網羅的に洗い出していた |
事後に判明した数値を、計画時点に立っている主人公が知っているかのように書いてしまう。これをやると、ケースの主人公はもはや悩む必要がなくなり、意思決定を追体験するという教材の前提そのものが無効になります。
5つに共通していたのは「補完」だった
並べてみると、5つの傾向はすべて同じ方向を向いていました。
| 症状 | AIの心の声 | 教材としての帰結 |
|---|---|---|
| 盛りすぎ | 表現を強める | 議論の余地を失う |
| 断定 | 全体化する | 前提が壊れる |
| 因果の補完 | 勝手に繋ぐ | 思考を放棄させる |
| 説明過多 | 結末を書く | 余白を失う |
| 時点の無視 | 未来を持ち込む | 意思決定が無効になる |
どれも「足りないところを埋めよう」とする動きです。AIは補完がとても得意で、しかも上手にやります。文章として読めば、AI版のほうが整っていることさえあります。
一方、ショートケースは「余白」によって教材としての価値を保っています。書かれていないから参加者は考え、書かれていないから議論が生まれる。埋めることが得意なAIと、埋めないことに価値がある教材。この構図が「惜しい」の正体でした。
いちばん面白かったのは、ヒト側に起きたこと
ここからが、この取り組みでもっとも示唆深かった部分です。
レビューを重ねるうちに、変わっていったのはAIの出力だけではありませんでした。AIの原稿を直しながら、メンバー自身が「良いショートケースとは何か」を、これまでになく明確に言語化しはじめたのです。
象徴的だったのが、あるルールをめぐる一連の議論でした。
レビューの初期段階で、研究会は「本文の末尾を問いかけで終わらせない」というルールを設けました。読者に特定の行動を示唆したり、解釈を誘導したりしてはいけない。考えるのは読者の仕事だから、という理由です。このルールに従って、AIが7本すべての末尾に付けていた問いかけを削除しました。
ところが後日、あるケースの最終稿をメンバーが仕上げたとき、末尾にはこう書かれていました。
PMであるあなたは、この状況でどのようにプロジェクトを進めていくか
削除したはずの問いかけが、ヒトの手で戻ってきたのです。
ここで議論になったのは「ルールを破ったのか」ではなく、「そもそも、あのルールは何を禁じていたのか」でした。行き着いた結論は、禁じるべきは特定の行動を示唆する表現であって、読者が考え始める起点としての問いかけはむしろ必要だ、というものでした。「行動の示唆」と「思考を促す問い」は違う。この境界は、AIの原稿を直すという作業を通してはじめて、はっきりと言語化されました。
似たことは他にも起きました。たとえば、AIが「原文に裏付けがない」として曖昧化した数値が、最終稿で復活したケースがあります。学習者が懸念点として議論するために、その具体性はどうしても要る。ファクトへの厳密さよりも教育上の意義を優先する、という判断です。逆に、失敗の原因を直接指し示す記述は、あえて曖昧に戻されました。答え合わせになってしまうからです。
「数値や状況の具体性は残す。失敗要因の直接的な指摘は曖昧にする」。長年ショートケースを作ってきたメンバーが、頭のなかで無意識にやっていた使い分けです。それが、AIの原稿にコメントを付けるという行為を経て、はじめて他人に説明できる言葉になりました。
AIにレビューを入れているつもりが、実は自分たちの暗黙知を掘り出していた。 これが、今回いちばん面白かったところです。
気づきを、書き戻す
もっとも、気づいて終わりでは次も同じ苦労を繰り返します。研究会では、31件の気づきを性質ごとに3層に分け、AIエージェントのスキルファイルに書き戻しました。
| 層 | 参照されるタイミング | 内容の例 |
|---|---|---|
| 設計判断 | ケースの骨格を決めるとき | ケースの時点をどこに置くか、行動判断型か教訓型か、タイトルの主題と副題 |
| 表現ガイドライン | 本文を書くとき | 抽象表現を避ける、原文のトーンに忠実に、時制と文の区切り、ファクトの照合 |
| 禁止ルール | 全工程で違反チェック | 行動示唆の禁止、全称命題の禁止、時点整合性、結果と原因の直接記述の禁止、価値判断副詞の禁止 |
設計するとき、書くとき、検証するときで、参照すべきルールは違います。すべてを1か所に積み上げると、かえって使われません。AIの処理の流れに沿って、必要なタイミングで必要なルールが手元にある構造にしました。
効果は、次のケース生成ではっきり出ました。以前は毎回指摘していた「社内で誰も」のような全称命題や、その時点では知り得ない数値の混入が、初稿の段階でほとんど出てこなくなったのです。
そして重要なのは、このスキルファイルが組織の資産になるということです。ベテランの頭のなかにしかなかった判断基準が、読めるファイルとして残る。新しいメンバーが加わったとき、これまでは背中を見て覚えるしかなかったものを、最初から手渡せます。
AIが学び、ヒトが気づく
一連のプロセスを俯瞰すると、こういう循環になっています。
AIがケースを生成する。AIが自分で品質チェックをかけ、自信のない箇所に指摘マークを付ける。ヒトがそのマークを手がかりにレビューし、AIには見えないずれを見つける。そのずれから学びを抽出し、ルールとしてAIのスキルに組み込む。次の生成で、同じ種類の間違いが減る。
この循環のなかで、AIは確かに学びます。しかしそれ以上に、ヒトのほうが自分たちの判断基準に気づいていきます。わたしたちはこれを共修サイクルと呼んでいます。
分業ではありません。AIに丸投げすれば骨格が崩れ、ヒトが全部抱えれば50時間に戻ります。AIが足場を組み、ヒトがその足場を駆け上がる。駆け上がる過程で気づいたことを、足場のほうに組み込み直す。この往復が回りはじめると、ショートケースづくりは「重い作業」から「発見のある作業」に変わりました。
これは、ショートケースだけの話でしょうか
最後にひとつ、問いを置かせてください。
AIが見せた5つの傾向は、ショートケース特有の現象ではありません。盛りすぎ、断定、因果の補完、説明過多、時点の無視。これらは、AIが文章を書くときに一般的に起きることです。
議事録をAIにまとめさせたとき、発言されていない因果が「〜のため」という接続でつながっていないでしょうか。進捗報告をAIに下書きさせたとき、その時点では判明していない見通しが、あたかも既知の事実のように書かれていないでしょうか。提案書のドラフトで、原資料にない「必ず」「大幅に」が足されていないでしょうか。
わたしたちがふだんAIに任せている文書のすべてに、同じ「補完」が起きている可能性があります。5つの傾向を頭の隅に置くだけで、AIの出力を見る目は変わります。そして、その違和感を言葉にして書き戻す仕組みを持てば、それは組織の学習になります。
一緒に共修しませんか
PM実践研究会は、プロジェクト成功率の向上とプロジェクト・マネジャーの実践力強化を目的に、2007年に設立されました。IT、製造業、エンジニアリングなど多様な業界出身のメンバーが「学ぶ・創る・伝える」の三つの軸で活動しています。ショートケースの開発は、そのなかの「創る」にあたる活動です。
そして、この活動には皆さまの経験が欠かせません。ショートケースの源泉は、実際のプロジェクトで苦労された方のインタビューだからです。AIがどれだけ賢くなっても、現場で起きたことを語れるのは経験した方だけです。
プロジェクト経験を語っていただけるかたを、常時募集しています。
事前アンケートのご記入と、1時間程度のインタビュー（オンライン・オフラインどちらも可）にご協力いただける方は、ぜひご連絡ください。あなたの苦労が、次の誰かの成功ストーリーの起点になります。
ワークショップへのご参加もお待ちしています。実践から学び、創り、ジュニアからシニアへとつながりを紡ぐ場に、ぜひ足を運んでみてください。
PM実践研究会の見学・参加を希望される方はこちらから
https://www.pmi-japan.org/page-943/
