別のチームからの返答を待っている、必要なものが揃っていない、合意した予定より遅れているなど、プロジェクトが止まっています。それでも、週次の非同期報告は書かなければなりません。「作業は停止中、予定より遅れており、支援が必要」と書くとぶっきらぼうに感じるため、AIに「うまくまとめて」と頼みたくなります。しかし、曖昧な指示からは、入力した状況に根拠のない前向きな表現が生まれることがあります。だからこそ、プロンプトには、自分が明示した評価を変えずに残すための指示が必要です。
これは、文章の良し悪し全般とは別の、より限定された問題です。非同期の進捗報告は、磨き上げるための文章ではなく、ほかの人が計画に使う状況のシグナルです。「予定どおり」と読んだ上司は、別のことへ注意を向けます。「もうすぐ完了」と読んだ関係チームは、あなたの作業が期限どおり終わる前提で、自分たちの予定を組みます。実際には止まっているのに、報告からそれが伝わらなければ、そのずれの代償は後になって、まずあなたではなく、下流にいる誰かの計画へ表れます。
偶然ではなく、モデルの既定の傾向として起こり得る理由
人間のフィードバックによる調整は、状況によって、正確な回答より利用者に迎合する回答を生むことがあります。OpenAIは2025年4月、GPT-4oの更新が過度に利用者を持ち上げ、同意する傾向を示したとして、その更新を取り消しました（OpenAI「Sycophancy in GPT-4o」）。これは特定のモデル更新で起きた問題の記録であって、すべてのシステムが常に前向きな表現を加える証拠ではありません。それでも、一般的な対策は変わりません。プロンプトに実際の状況がなければ、モデルがその状況を独力で知ることはできず、空白を補う可能性があります。
AIが作った報告によって、作業の停止や遅れを、「予定どおり進んでいる」と受け取れる表現へ丸めてはいけません。実際の状況が「停止中」または「遅延」なら、何が必要になれば再開できるかとともに、明確にそう書きます。文章を穏やかに見せるために問題を弱めれば、報告をもとに計画する人へ、その問題を先送りすることになります。
状況を正確に保つための手順
ステップ1：AIを開く前に、実際の状況を平易な言葉で書く
下書きを始める前に、次の四つの質問へ、自分の言葉で正直に答えます。
- 実際に完了した、またはリリースしたものは何か。
- 何が原因で作業が止まっているか。具体的に何を待っているか。
- 次に何をするか。
- 次の節目を予定どおり迎えられる見込みを、自分はどう評価しているか。
この手順が重要なのは、実際の情報が作業へ入る唯一の場所だからです。AIは情報を読みやすく整えられますが、あなたが先に示さなければ、「本当に予定どおりか」という問いへ、責任のある答えを出すことはできません。
ステップ2：論評ではなく、体裁を整えるよう頼む
次の状況を、チームのチャンネルへ投稿する読みやすい非同期報告に整えてください。
完了：[what actually shipped]
停止の原因：[specific blocker, or "nothing" if true]
次にすること：[what's next]
見込み：[your honest assessment, e.g. "on track," "at risk,"
"blocked — need X by [date] to stay on track"]
平易で事実に即した調子にしてください。上で示した以上の進捗や確信を
感じさせる表現を加えないでください。作業が止まっていると書いた場合は、
注記に埋めず、それを報告の中心にしてください。
ステップ3：実態を取り繕う表現がないか確認する
出力を読み返し、実際の状況より確実、または進んでいるように受け取れる表現を探します。
| 注意する表現 | 代わりに確認すること |
|---|---|
| 「順調に進んでいます」／「絶好調です」 | 実際に完了したと書いた内容と、具体的に一致しているか。 |
| 「もうすぐです」／「ほぼ完了です」 | 具体的で正直な見積もりがあるのか、それとも根拠のない安心感か。 |
| 実際の障害があるのに「予定どおり」 | 障害と、解消に必要なことが、最初にはっきり書かれているか。 |
| 「おそらく問題ありません」 | 自分が正直に評価した見込みか、それとも単なる希望か。 |
下書きに含まれる表現によって、上司や関係チームが、実態から妥当といえる範囲とは異なる計画を立てそうなら、送る前に直します。
ステップ4：繰り返す問題は、報告に埋めずに提起する
プロジェクトが何回か続けて「リスクあり」または「停止中」のまま解決していないなら、それ自体を直接提起する必要があります。毎回の非同期報告に、同じ未解決の問題を静かに載せ続けるのではなく、1:1や個別メッセージで取り上げます。1:1の議題を準備する方法では、繰り返す障害を毎週の進捗欄へ埋もれさせず、独立した議題として提起する方法を説明しています。
問題が起きる前に、チームで提起の条件を決めておきます。たとえば、合意した回数の報告にわたって、節目へのリスクが解消されない場合です。回数はチームの方針として決めるものであり、この記事が示す普遍的な基準ではありません。
議事録や1:1の準備とは何が違うか
非同期報告は、議事録や1:1の議題の準備と似ています。いずれも、AIに内容を作らせるのではなく、実際の情報を整理するために使うからです。ただし、起きやすい失敗は、それぞれ異なります。議事録では、AIが実際の議論を短くまとめる過程で、正確さを失うことがあります。非同期報告では、曖昧なプロンプトの空白を、入力にはなかった一般的で前向きな調子で埋めることがあります。対策の考え方は同じです。実際の内容は自分で用意し、出力をその内容と照合します。しかし、非同期報告では、AIに作業を見せる前に、正直な状況を平易な言葉で書くことが特に重要です。そうすれば、モデルが楽観的な表現で埋める空白が残りません。
また、非同期のやり取りには、誤解をその場で正すための会話がありません。会議なら、状況の説明に違和感があった人が、その場で質問できます。後から読む文書では、その場にいなかった人にとって、書かれた言葉が状況を知る唯一の手掛かりです。声の調子やためらいは伝わらず、文章だけが残ります。そのため、同じ状況を会話で伝える場合より、文章の正確さが大きな役割を担います。
ここでは、洗練より平易さを優先する
「停止中」と率直に書くのは気まずく感じるかもしれませんが、計画に必要なシグナルは保たれます。障害を隠す前向きな報告は、誤った前提にもとづく判断を下流で生む可能性があります。この記事は、信頼への効果を測定したとは主張しません。優先するのは、責任者が実際に示した状況を後から確かめられる記録です。
参考となるガバナンスの枠組みには、NIST AIリスクマネジメントフレームワーク、OECD AI原則、OpenAIが公表した迎合問題の事例があります。ただし、個々のプロジェクトの事実は、責任を持つ担当者、実際の提供実績、合意した報告方針から得なければなりません。
もう一つの落とし穴は、短い報告を正直な報告と同じだと考えることです。短くても、実態を取り繕うことはできます。無関係な前向きな説明を三文続け、その最後に「停止中」と添えれば、言葉としては存在しても、実質的には隠れています。実際の状況を最初に平易に示し、その後で背景を加えます。
次の報告を下書きする
非同期報告の事実カードを使い、下書きの前に実際の状況を書きます。その後、自分が示していない確信を加えないよう指示して、AIに読みやすい形へ整えさせます。「最初に実際の状況を示す」という同じ考え方は、正確さを保つ議事録にも直接応用できます。まだ意見が分かれている判断を要約するときにも、AIによって、実態より滑らかで楽観的な表現が入り込むことがあるからです。
