本記事は Zenn で公開した実測記事の Qiita 版です (筆者本人による転載・一部再構成)。

「あの案件、進捗どうなってる?」

今日も何度か口にしました。もう数える気にならないくらい、毎週繰り返してきた言葉です。抱えている案件が5件でも50件でも、この一言に追われた経験のある方は多いはずです。案件シートが更新されず、確認と催促に時間が溶けているなら、AI に任せられる部分があります。

もう一つ、口癖になっていた言葉があります。「案件一覧、更新しておいてください」。朝礼で週に2〜3回は言っていました。言えば少しは埋まります。でも、続きません。数日たつとシートはまた止まり、私は「進捗どうなってる?」に戻る。この繰り返しでした。

この記事は、約50案件を掛け持ちする受託開発の責任者が、この「催促と状況把握」を Claude に任せた記録です。道具は Claude Code (Sonnet)・Slack (Bot Token 連携)・Google スプレッドシート (サービスアカウント方式)。cron で定期実行しています。2026年7月に作り、同じ月に本番へ展開しました。

先に断っておくと、稼働時間の変化の数字は体感の概算です (AI の判定精度だけは、練習用データで実測しています)。その前提で、何をどう変えたら何が起きたかを書きます。

この記事で組んだ仕組みで使っているプロンプト4本の全文、スプレッドシートの列構成、cron の設定は、note の実践パッケージ (¥1,480〜) に実物のまま置いています。記事だけでも組めるように書いていますので、設定を写してそのまま動かしたい方向けです。

私の仕事は、いつから「聞き取り」になったのか

PM歴は20年を超えましたが、「約50件を同時に見る」という状況には、正直まだ慣れきれていません。

案件を俯瞰する道具は、昔からずっと同じでした。案件管理シートです。各案件のステータス、リスク、次のマイルストーンを書いてもらう、あれです。

でも、何度呼びかけても、シートは止まりました。

理由は単純です。担当者にとって、シートへの記入は本業の合間に挟む「もう一つの仕事」でしかありません。しかも書く粒度が人によってバラバラです。一行で済ませる人もいれば、経緯を延々と書く人もいる。

結果、私が実際にやっていたのはこうです。シートとにらめっこして、足りない情報を頭の中で補い、担当者を捕まえて「あれどうなった?」と聞く。

たとえば (ダミー例です)、B案件には「設計フェーズ順調」としか書かれていない。でも設計のどこまで終わっているのかは、誰かに聞かないと分からない。約50件のうち何件かは、常にこの状態でした。担当者を捕まえるにも、相手が打ち合わせ中なら待つしかない。1件あたりは数分でも、50件分積み重なると馬鹿になりません。

ざっくり振り返ると、週の稼働の7割ほどが、この「シートとにらめっこ + 催促 + 状況把握」に溶けていました。約50件を把握して「意思決定」する仕事のはずが、実態は約50件分の「聞き取り」だったのです。

同じチームの別のPMに聞いても、返ってくる答えは同じでした。「シートは書いてもらえない、でも聞かないと分からない」

「読む・探す・聞く」を自分の手でやっている限り、これは変わりません。そこでこの3つを、まるごと Claude に渡してみることにしました。作った仕組みは3つです。

仕組み1: 何が足りないかをAIが判定し、名指しで聞く

最初に変えたのは「催促」です。

案件シートは、更新されている案件とされていない案件が混ざった状態です。ここに AI を通し、「この案件の状態を判断するには、何の情報が足りないか」を都度判定させるようにしました。判定の土台は PMBOK (プロジェクトマネジメントの世界標準としてよく参照される知識体系) です。

実際に使っている判定プロンプトから、冒頭と判定基準の部分をそのまま抜粋します (全文は末尾で紹介する note に載せています)。

あなたは PMO の情報監査担当です。渡された案件一覧を読み、各案件について
「課の責任者が次の一手を決めるために不足・矛盾している情報」を判定し、
担当者への質問を作ってください。

## ステップ2: 不足・矛盾を判定する
- スケジュール: 期日が空欄でないか。期日を過ぎているのに状況の記載と矛盾していないか
- コミュニケーション (鮮度): 案件状況の署名日付が古くないか (2週間以上前は停滞とみなす)
- リスク: 開発・総合テスト工程の案件にリスク・懸念の記載があるか
- 資源・体制: 副担当が空欄になっていないか
- 内容の質: 案件状況が一言だけで、次の一手を判断できる材料がないケース
基準は常に「この記載だけで、責任者がこの案件の次の一手を決められるか」です。

ポイントは最後の1行です。「シートが更新されているか」ではなく、「この記載だけで責任者が次の一手を決められるか」を判定基準にする。これだけで、AI の質問が実務の感覚にぐっと寄ります。

この判定がどこまで当てになるかは、本番投入前に練習用のダミー案件20件で確かめました。わざと不足・矛盾を仕込んで、AI がどこまで見つけるかのテストです。

検証項目	結果
仕込んだ不足・矛盾	15件
検出できた不足・矛盾	15件 (見逃しゼロ)
問題のない案件	5件
うち「念のため確認」が出た案件	3件
質問対象になった案件	計18件

見逃しゼロと引き換えに過剰検知を許す、安全側に倒した挙動です。同じ20件で独立に2回実行して、検出も過剰検知も2回とも同じ案件でした。なお、生成 AI の出力は毎回同じとは限りません。この2回の一致は再現性の保証ではなく、参考値です。

質問は AI が Slack で担当者に直接送ります。「進捗どうですか」のような曖昧な聞き方はさせません。たとえば (ダミー例です)「A案件、先週完了予定だったテスト工程の状況を教えてください」のように、シートの記載から何が欠けているかを名指しで聞きます。

質問の「深さ」は案件の重要度で変えています。全案件に重い質問を投げると、答える側の負担が大きすぎるからです。金額が大きい・工程が終盤・危ないシグナルが出ている案件には一歩踏み込んだ質問まで (例: 遅延している案件なら、後続工程への影響はどうか)。軽い案件には「期日だけ教えてください」の1問だけ。質問のコストを、案件の重みと釣り合わせる設計です。

担当者が Slack で返信すると、AI がその回答を評価します。十分ならシートへ反映して終わり。足りなければ、AI が足りない点を名指しして聞き直します。回答から担当者が行き詰まっている様子が見えるときは、次の一手の候補 (相手に期限を切った依頼、私へのエスカレーションなど) を添えて返します。詰問ではなく、伴走に寄せたかったからです。

これで、催促していたのは私ではなく仕組みになりました。ただ、集まった情報を毎朝さばく仕事は、まだ私に残っています。次はそこです。

仕組み2: 毎朝AIが全件に目を通し、危ない案件を先に並べる

毎朝、AI が約50件の案件シートを全部スキャンします。出てくるのは「危ない案件のリスト」「それぞれの状況」「推奨されるアクション」の3点セットです。

これはあくまで一次トレース (最初の下読み) で、最終判断は私がします。AI の報告を見て、本当に危ないのか、どこから手をつけるべきかを考え、決めた内容はまたシートに記録します。

朝の仕事は、「約50件を一件ずつ開いて読む」から「AI が挙げた危ない案件から先に読む」に変わりました。全部を平等に読んでいた時間が、危ない場所に集中する時間になったということです。

正直に言うと、最初にこの朝の報告を受け取ったときは半信半疑でした。約50件を機械的にスキャンして、本当に「危ない」の解像度が出せるのか。でも数日回してみて、自分が経験的に「これ危ないかも」と感じていた案件がリストの上位に上がってきたときは、素直にほっとしました。

仕組み3: 「今どこを見るべきか」が一目で分かる地図を作る

3つ目は可視化です。

情報が集まり、毎朝の下読みが届くようになっても、まだ足りないものがありました。全体を一枚で見渡せる場所です。それがないと、「いま、どの案件に自分の時間を使うべきか」を考えるたびに、シートを開き直して記憶を継ぎ足すことになります。

そこで、約50案件の状態を一目で把握するためのダッシュボードを自動生成するようにしました。危険度順の並び、期日超過や「質問が放置されている」ことを示すバッジ、案件ごとの「私のネクストアクション」。誰かに見せるための資料というより、自分が次に何を見るかを決めるための地図です。

検証は40件構成の環境で行いましたが、本番 (約50件) でも傾向は変わりませんでした。

結果 — 体感で週稼働の7割が3割に

3つの仕組みを回した結果、「シートとにらめっこ + 催促 + 状況把握」に溶けていた週の稼働は、7割から3割まで落ちた実感があります。

一番大きな変化は、時間の使い道です。「読む・聞く・探す」という一次作業が減った分、本来やるべき仕事——意思決定と、案件を動かすためのコミュニケーション——に軸足を移せました。危ない案件の対応方針を決める。判断に迷っているメンバーと話す。顧客との調整に先手を打つ。7割が3割になった中身は、この「本来の仕事への引っ越し」です。約50件を見る仕事の総量が減ったわけではありません。仕事の重心が移ったのです。

もう1つの変化は、案件一覧の「情報充足率」です。「その記載だけで次の一手を決められる案件」の割合を、私は勝手にこう呼んでいます。以前はざっくり4件に1件、25%くらいでした。「情報が足りているかどうか」を判断すること自体、全案件の記載を私が自分の目で読まないとできない仕事だったからです。全部読み、足りない箇所を見つけては、朝礼での催促や個別の直接確認で埋める。この「全部読む → 足りない所を探す → 催促する」が丸ごと AI に移り、いまは85%くらいまで上がった実感があります。

メンバー側の受け止めは、心配していたよりずっと滑らかでした。「来た質問に答えるだけ」という手軽さと、普段使っている Slack に届くという入口の低さで、特別な教育なしに回り始めています。

では、なぜ100%にならないのか。メッセージを後回しにするメンバーは、少なからずいるからです。残りの15%はこの「放置」です。放置はゼロにはなりません。その代わり、放置が毎朝ダッシュボードに「放置」として見えます。私の仕事は「50件に催促して回る」から「放置された数件に声をかける」に変わりました。

	導入前	導入後
週稼働に占める「シートとにらめっこ + 催促 + 状況把握」	7割	3割
案件一覧の情報充足率	約25%	約85%
充足のために私がやること	朝礼での催促 + 個別の直接確認	放置された案件への声かけだけ

数字はいずれも体感の概算です (冒頭に書いた前提のとおり)。

「月次の定例会議で確認しているから十分では」と思う方もいるかもしれません。私も以前はそう考えていました。ただ月次では、約50件のうち急変した案件に気づくのが早くて数週間後になります。この仕組みを入れてからは、危ない兆候を毎朝の単位で拾えるようになりました。定例会議はそのまま残して、会議に出す前の「下読み」の頻度が上がった、というのが正確なところです。

限界: それでも「放置」は残る

ここまで良いことばかり書きましたが、この仕組みは万能ではありません。

いま実際に起きているのは「放置」です。

放置は残る (現実): 質問に答えるだけとはいえ、メッセージを後回しにするメンバーは少なからずいます。私の運用では、2日返信がなければ自動でリマインド、2回リマインドしても動かなければ私に上がってくる、という段階を仕組みに入れました。放置を見えるようにして、私の次のアクションに変えるのが現実解だと思っています
質問の的外れ (まだ仮説): シートの記載だけでは読み取れない事情とずれた質問をしてしまう可能性。担当者にしか分からない背景、書かれていない社内政治のようなものは、AI には見えません
判定基準の穴 (まだ仮説): PMBOK の観点を土台にしても、案件固有の事情まではカバーしきれません。観点表そのものを定期的に見直す必要が出てくるはずです

仮説の2つは、実際に起きたら一般化せず、そのままこの章に追記していくつもりです。

顧客情報の扱いについて

顧客の案件情報を AI に渡すことに、契約上・情報管理上の懸念がないかは案件ごとに確認しています。機微な情報は要約前にマスキングするルールを設けています。

だからこそ、最終判断は人間に残しています。この考え方は、以前書いた別の記事でも扱いました (関連記事は末尾に載せています)。AI がどれだけ網羅的でも、「これは重大だ」という最後の一線は、まだ人間の仕事です。AI が担うのは「気づく」ところまで。「決める」のはいまも私です。

それでも、この仕組みを手放す気にはなれません。失敗は起きます。ただ、それは「人間が催促し、人間が全件読む」という以前のやり方でも起きていたことです。違うのは、失敗に気づける速さと、直す場所が観点表やプロンプトという「形のあるもの」になったことです。的外れな質問は観点表を直せば減らせます。放置はリマインドの段階設計で受け止められます。失敗が「属人的な反省」から「仕組みの改善点」に変わったことが、この仕組みの一番の価値かもしれません。

明日からやるなら

まず「催促」と「状況把握」を分けて考える。両方を一度に AI へ渡す前に、どちらが先に効くかを見極める
質問の観点と深さをあらかじめ決めておく。PMBOK のような既存の知識体系を土台にし、重い案件ほど踏み込む
AI の報告は「一次トレース」であって「最終判断」ではないと最初に決めておく。意思決定は人間に残す
可視化は「見せるため」ではなく「自分が判断するため」に作る

私の仕事は、「探す・聞く・読む」から「決める」に重心が移りました。そして、あの「あの案件、進捗どうなってる?」を、私はもうほとんど口にしていません。

「ここまで読めば自分でも組めそう」と思われたかもしれません。実際、腕のある方なら組めるはずです。分かれ目は腕ではなく、回り道にかける時間です。cron で回すと PATH が通らず claude コマンドだけが見つからない。Google スプレッドシート連携では、サービスアカウントの権限設定をひとつ飛ばしただけで「開けません」と止まる。こういう、記事にはならない小さなつまずきが続きます。

その回り道を飛ばしたい方向けに、note の実践パッケージ (¥1,480〜) を用意しました。中身は、実際に使っているプロンプト4本の全文・動くコード一式・セットアップ手順・練習用ダミー案件20件です。この種のつまずきをひとつ自力で調べて潰す時間と比べて、安い買い物だと思えた方はどうぞ。

音声で聞き流したい方向けに、同じ内容の動画版 (スライド+AI音声・13分) もあります。https://www.youtube.com/watch?v=lygkxDneDRo

関連記事: 設計書レビューをAIに頼んだら検出率0%だった — 3役割に分けて86%にした頼み方

🔍 moname_ai — Claude を本業で使い倒した実測記録を書いています。続きは Bluesky (@moname-ai.bsky.social) で。

この検証の続き: 実測で見つかった点検項目を、月 2 回ほどのメールで配信しています。登録すると、社内文書を AI に読ませる前の点検シートをその場で受け取れます。「自社の文書で実際どこまで測れるのか知りたい」という相談の窓口も、届いた 1 通目のメールでご案内しています → 登録はこちら