PMのAI活用は、文章生成より“論点の状態管理”に効いた

はじめに

どうも、りょーやです。

PMとして業務を進めるなかで、AIをさまざまな場面で使っています。

最初は、AIに期待していたことはわりと普通でした。

文章を整えてもらう、長い議事録を要約してもらう、調べものを手伝ってもらう。そういう使い方が中心になると思っていました。

もちろん、それらも便利です。

ただ、実際に使い続けてみると、私にとって一番大きかったのは、文章を作ることそのものではありませんでした。

むしろ効果を感じたのは、判断する前に、頭の中で散らばっている情報を一緒に並べ直してくれることでした。

PMをしていると、会議の前に「あれ、これはどこまで決まっていたんだっけ」「この話は今出すべきなんだっけ」「相手はこの論点をどう受け取るだろう」と考える時間がよくあります。

ひとつひとつは小さな確認です。

ただ、それが積み重なると、かなり頭を使います。

本記事では、AIを「文章を書く道具」としてではなく、プロジェクトの文脈を整理し、判断材料を整える支援役として使ってみた実践について紹介します。

PM業務で重いのは、判断前の文脈整理

PMの仕事は、最終的には判断の連続です。

ただ、実際にしんどいのは、判断そのものだけではありません。

判断する前に、頭の中でいろいろな情報をつなぎ直す時間があります。

前回の打ち合わせでは何が決まったのか。

その後、Slack や Asana で何が動いたのか。

相手はどの論点に慎重なのか。

こちらは何を先に出すべきなのか。

今この話をすると、話が広がりすぎないか。

こうしたことを、会議の前に一人で思い出しながら整理している時間があります。

PMをやっている方であれば、似たような感覚があるかもしれません。

「何を話すか」よりも、「どこから話すか」「何を今日は話さないか」を考える方が難しい場面です。

AIを使っていて効果を感じたのは、この部分でした。

頭の中だけで抱えていた文脈整理を、AIに一度外へ出してもらえるようになったのです。

作ったもの：プロジェクト文脈を扱う二層構造

AIにプロジェクトの文脈を踏まえてもらうために、文脈を二層で持たせるようにしました。

とはいえ、最初からきれいに設計できていたわけではありません。

使っていくうちに、「これは毎回変わる情報だな」「これは判断軸として残しておいた方がよいな」と分かれていきました。

結果的に、次の二つに整理されました。

一つは、構造化サマリーのような静的な文脈です。

もう一つは、Slack や Asana などから取得する動的な文脈です。

静的な文脈には、会議の決定事項や論点の変化、判断の背景を残します。

動的な文脈では、日々のやり取りや最新の温度感を拾います。

この二つを分けたことで、AIに渡す情報が少し整理しやすくなりました。

静的な文脈：判断軸込みの構造化サマリー

打ち合わせや重要なやり取りがあるたびに、内容を構造化したサマリーとして残しています。

これは、単なる議事録ではありません。

事実だけでなく、次の判断に使うための観点も含めています。

骨子としては、次のような形です。

# ○○プロジェクト 定例会 構造化サマリー

- 日時
- 参加者
- 会議の位置づけ

## エグゼクティブサマリー
## 確定事項
## 未決事項
## グレー論点
## 前回からの構造変化
## 主要な引用
## 次に確認すること

特に重要なのは、前回からの構造変化です。

プロジェクトは、毎回ゼロから始まるわけではありません。

前回までは重要だった論点が、今回で一旦置かれることもあります。

逆に、小さな発言が次回以降の重要な論点になることもあります。

その変化をAIに渡すことで、AIの回答が一般論に流れにくくなります。

動的な文脈：最新状況のキャッチアップ

一方で、構造化サマリーだけでは最新状況に追いつけません。

プロジェクトは、Slack のスレッド、Asana のコメント、Box 上の資料更新などで少しずつ動いていきます。

そのため、AIとの会話の最初に、最新状況を確認するようにしています。

ここで大事なのは、チャンネルやタスクの表面だけを見るのではなく、スレッドやコメントの中まで確認することです。

結論や温度感は、表の投稿ではなく、その後のやり取りの中で動いていることが多いからです。

静的な文脈で判断軸を持たせ、動的な文脈で最新の動きを拾う。

この二層構造にすることで、AIが「過去の経緯」と「いま起きていること」をつなげて考えやすくなりました。

AIに担わせた役割は、文章生成ではなく論点状態の整理

使っていて特に助かったのが、論点の状態を分けることでした。

PM業務では、論点を「決まった」「決まっていない」の二つだけで扱うと、少し乱暴になることがあります。

実際のプロジェクトでは、もっと曖昧な状態があります。

たとえば、ある論点について社内で整理していたときに、

「相手は優先度を下げるとは言ったけれど、やめるとは言っていないよね」

という話が出たことがありました。

この指摘は、自分の中でもかなりしっくりきました。

たしかに、その論点は終わったわけではありません。

ただ、今すぐ詰める話でもありません。

相手が明示的に判断したわけではないので、こちらが勝手に「なくなった話」として扱うのも違います。

こういう論点を、私は便宜上 グレー論点 と呼ぶようにしました。

グレー論点は、未決事項とは少し違います。

未決事項は、いずれ決めるべきことです。

グレー論点は、まず「相手がどう考えているのか」を確認する必要があるものです。

この分類をAIにも持たせることで、会議準備がかなり楽になりました。

単に「次回の議題を考えて」と頼むのではなく、次のように依頼できます。

決定済み、未決、グレー、一旦置く論点に分けて、次回確認すべき順番を整理してください。

これだけで、AIの返し方が変わります。

議題を並べるだけではなく、「これは確認」「これは保留」「これは今は出さない方がよい」といった扱いの違いまで考えやすくなります。

会議準備が「思い出す作業」ではなくなった

一番変化を感じたのは、会議準備です。

以前は、打ち合わせ前に過去のメモを見返し、Slack を読み、Asana を確認し、前回から何が変わったのかを思い出していました。

もちろん、PMとして必要な作業です。

正直なところ、毎回それなりの時間を要します。

会議に出る前から、すでに頭の中で何度も会議をしているような感覚があります。

AIに文脈を持たせてからは、この準備の入り口が変わりました。

まずAIに、過去のサマリーと直近の動きを踏まえて、次のように整理してもらいます。

AIが出してきた整理は、もちろんそのまま使うわけではありません。

「これは違う」

「これは今回扱う」

「これは相手の温度感を見てからにする」

と、自分で直します。

ただ、ゼロから思い出すのではなく、叩き台を見ながら考えられるだけで、かなり楽になります。

AIが会議設計を決めるわけではありません。

でも、PMが頭の中でやっていた論点の並べ替えを、一度外に出してくれる。

この感覚が、私にはかなり合っていました。

メッセージの言い回し調整は、副次的な効果だった

もちろん、メッセージの言い回しを整える場面でもAIは役に立ちます。

たとえば、相手に資料の所在を案内するメッセージを作成していたとき、AIが「お渡し済みでして」という表現を出してきたことがありました。

一見すると、丁寧な表現です。

ただ、私は少し引っかかりました。

「済み」という言い方は、相手が確認していないことを指摘しているように読めるかもしれない。

こちらにその意図がなくても、相手によっては少し責められているように感じるかもしれない。

そう思ってAIに伝えると、「格納しております」のように、相手の行動を評価するニュアンスを含まない表現に直してきました。

これは単なる言い換えではありません。

自分がなんとなく感じた違和感を、AIとのやり取りの中で言語化できたことが大きかったです。

PM業務では、この「なんとなく引っかかる」が意外と重要です。

まだ言葉になっていない違和感を放置すると、あとでコミュニケーションのズレになることがあります。

AIは、その違和感を一緒に言葉にする相手としても使えます。

蓄積した文脈ファイルを、判断材料として再利用する

この運用を約3か月続けた結果、プロジェクトに関する文脈ファイルは48本になりました。

最初から48本作ろうと思っていたわけではありません。

打ち合わせのたびにサマリーを残し、資料を読み解いたメモを残し、次回の判断材料を整理していたら、気づけばそのくらいになっていました。

内容は、定例会の構造化サマリーだけではありません。

進行台本、受領資料の分析メモ、判断材料として整理した論点集、過去のやり取りから抽出した注意点なども含まれています。

ここまで増えると、ただ保管しているだけでは使いづらくなります。

そこで、AIにこれらのファイルを確認させ、プロジェクトのフェーズ、主要論点、転換点ごとに再整理させました。

返ってきたのは、単なるファイル一覧ではありませんでした。

• どの時期に何が主要論点だったか
• どの会議が転換点だったか
• どの論点が継続して残っているか
• どの判断が後続の議論に影響しているか
• 引き継ぎ時に確認すべきファイルはどれか

これを見たとき、単に「ファイルが整理された」というより、プロジェクトの地図を作り直してもらった感覚がありました。

過去ログが、次の判断に使える材料に変わったのです。

AIに文脈を持たせる際の注意点

一方で、うまくいったことばかりではありません。

AIに文脈を持たせる運用には、注意点もあります。

特に怖いのは、文脈が古くなることだけではありません。

文脈は、更新の過程で静かに誤ることがあります。

実際に、プロンプト自体の自己メンテナンスをAIに任せる運用を試した際、事実と異なる記述が紛れ込んだことがありました。

別のメンバーの行動から得た学びが、更新の過程で誤った経緯として書き換えられていたのです。

見つけたときは、少しひやっとしました。

文章としては自然に読めます。

だからこそ危険でした。

もし人間が確認しなければ、その誤った前提が「正しい文脈」として残り、その後の相談に影響していた可能性があります。

この経験から、AIに渡す文脈は「蓄積すればよいもの」ではなく、定期的に確認・更新する管理対象として扱う必要があると考えるようになりました。

実務で利用するための運用ルール

AIをPM業務に組み込む際には、便利さだけでなく、責任分界と運用ルールを明確にする必要があります。

私の場合、次のようなルールを意識しています。

AIは、判断材料を整理するうえでは有効です。

一方で、最終的な判断、合意形成、対外的な発信は人間が担う必要があります。

便利だからこそ、どこまでAIに任せるのか、どこから先は人間が責任を持つのかを明確にする必要があります。

AIに任せる範囲、人間が持つ範囲

私の中では、AIと人間の分担を次のように整理しています。

AIはPMの代わりに判断するものではありません。

ただし、判断材料を揃えるところまでは、かなり有効に活用できます。

この分担が、PM業務では現実的でした。

真似するなら、最初に用意するもの

同じような使い方を試すなら、最初から完璧なプロンプトを作る必要はありません。

まずは、次の情報をAIに渡せる状態にするだけでも十分です。

# プロジェクト文脈メモ

## プロジェクトの目的
## 現在のフェーズ
## 関係者と主な関心
## 決定済みのこと
## 未決のこと
## グレー論点
## 避けたい言い方・踏み越えたくない線
## AIに任せること
## 人間が必ず判断すること

ポイントは、きれいなドキュメントを作ることではありません。

AIが判断材料を整理できるように、プロジェクトの文脈を構造化して渡すことです。

使っていくうちに、必要な分類は増えていきます。

私の場合も、グレー論点や前回からの構造変化は、最初からあったわけではありません。

運用しながら、PMとして必要な観点を足していきました。

まとめ

AIをPM業務で使ってみて感じたのは、AIはPMの判断を代替するものではないということです。

少なくとも、私はそう使いたいとは思っていません。

一方で、判断に至る前の工程にはかなり有効に使えます。

過去の経緯を整理する。

前提の変化を確認する。

未決論点を分類する。

相手の受け取り方を仮説化する。

選択肢とトレードオフを並べる。

文脈ファイルを棚卸しする。

こうした作業をAIに任せることで、PMはより落ち着いて判断できる状態を作れます。

重要なのは、AIに判断を渡すことではありません。

判断材料を揃えるところまでをAIに任せ、最後は自分で引き受けることです。

自分なら本当にこう言えるか。

この判断を自分の責任で持てるか。

相手との関係性を踏まえて、この出し方でよいか。

この確認を通らないものは、どれだけ自然な文章でも採用しません。

AIを使うことで、PMの仕事が軽くなる部分はあります。

ただ、それは責任が軽くなるという意味ではありません。

むしろ、判断材料を早く、広く、構造的に並べられるからこそ、最後に自分が何を選ぶのかがよりはっきりします。

AI活用で重要なのは、判断を手放すことではなく、判断に至るまでのプロセスを設計することです。

PM業務においても、この考え方は今後さらに重要になると考えています。