こんにちは、ログラスの松岡(@little_hand_s)です
3行まとめ
- AIをコード生成や文章校正に使ってますか？実はプロジェクト計画のレビューにも使えます
- 見落としやリスクを指摘してくれて、叩き台でスムーズに改善案を考えられます
- 小さく始めて、徐々に精度を上げていくことができます
AIの意外な使い道：プロジェクト計画のレビュー
最近は、コード生成や文章の校正にAIを使う人が増えています。
でも、「プロジェクト計画のレビュー」には使ったことがない方が多いのではないでしょうか？
実は、プロジェクト計画のレビューにもAIが使えます。私自身、AIレビューを取り入れることで見落としに気づき、対策を検討できました。その結果、「これで行ける」と確信を持てるようになりました。
ログラスにおける事例
ログラスでは目標設定にOKRを使っていて、私はAI活用推進チームのOKRを立てていました。
週次プランニングの中で
「OKRはこれで、残りは◯週間。今週の作業予定はこれだけど、足りない点を教えて」
とAIに依頼したところ、非常に的確な指摘を得られました。
特に驚いたのは、コンテキスト情報を細かく説明しなくても、概要レベルの情報だけで的確な指摘をしてくれた点です。OKRや作業計画へのリンクを貼っただけで、ほぼ上記ぐらいのプロンプトでした。
プロジェクトの背景や技術スタックを詳細に説明しなくても、
- OKRと計画の整合性の不一致、見落としているタスクの指摘
- リスクが高い箇所の指摘
- 具体的な改善案
などを提示してくれました。
一人で考えていると「まあこれで大丈夫だろう」と思ってしまう計画も、AIの客観的な視点を加えることで、見落としに気づけるため、目標達成の可能性が上がります。
なぜ少ない情報でも意味のある指摘ができるのか？
目標と計画の整合性を確認するのは、結構骨の折れる作業です。
一方、AIはロジカルな整合性チェックが得意なため、概要レベルの情報だけでも意味のある指摘をしてくれます。
私の体感では、ブログ執筆のような「テキスト単体の良し悪しのレビュー」よりも、今回のような「目標と計画の整合性チェック」の方が、AIは少ない情報で的確な指摘をしてくれるように思います。
もちろん、利用する情報が増えるほど精度は上がります。最初は小さく始めて、徐々に情報を足していくのがおすすめです。
それでは、実際にどうやってAIレビューを行うか、説明していきます。
3ステップで始める
1. 目標やプロジェクト計画を書く
目標、スケジュール、今週やることなどを言語化します。
週次プランニング、スプリント計画、リリース計画、どの粒度でも使えます。
フォーマットはまずは箇条書きでもOKです。小さく初めて、AIのレビュー結果をみながら調整していきましょう。
2. AIにレビューを依頼
テキストでAIに情報を渡します。ChatGPTでも、Claude CodeやCursorなどのコーディングツールでもOKです。
プロンプト例：(カッコ内は適宜埋めてください)
今週の計画をレビューして見落としや改善点を指摘し、改善案を作ってください。
OKR: (URL/ファイルパス)
残りスプリント数： (数値)
今週の計画: (URL/ファイルパス)
URLで参照できない場合は直接内容をコピペして下さい。
最初は概要レベルでも十分ですが、使っていく中でレビューして欲しい観点や参照して欲しいドキュメントなどを追加していくと、精度が上がります。一度チューニングしたプロンプトは、その後も使い回せます。
3. AIの指摘を元に改善
AIから見落としやリスクを指摘、具体的な改善案の叩き台をもとに案を再検討します。
必要に応じて追加で依頼（例：「このスケジュール、もっと現実的にできる？」）すれば、対話的に案を改善できます。
開発計画以外にも、営業計画、マーケティング施策、イベント企画など、様々なプロジェクト計画に応用できます。
サンプルストーリー
イメージを掴んでいただくために、サンプルストーリーで紹介します。
以下は「新機能リリース」という開発プロジェクトのシナリオで作成したサンプルですが、実際にこれに近い指摘をしてくれていました。
背景のプロジェクト状況
「ユーザー通知機能を6週間でリリース」という開発プロジェクト。
3週目冒頭の計画レビューで、残り4週間のスケジュールをAIにレビューしてもらった、というシナリオです。
立てた計画はこちら：
- 3週目: 未読バッジの実装、全機能完了
- 4週目: テスト（単体・結合・UIテスト）
- 5週目: バグ修正、デザイン微調整
- 6週目: リリース準備、本番リリース
一見、問題なさそうに見えます。
しかし、AIにレビューを依頼したところ、2つの問題を指摘されました。
問題1：テストが4週目に集中していてリスクが高い
AIからこのようなコメントが返されました。
🚨問題点：
もしバグが大量に見つかったら、5週目だけでは修正しきれない可能性があります。改善案：
- 3週目：実装と並行でテスト（できた部分から順次テスト）
- 4週目：残りのテスト＋バグ修正
- 5週目：クローズドβ（社内公開）で大きなバグを早期発見
- 6週目：最終調整＋本番リリース
テストを前倒しして段階的に進めることで、バグを早期発見できます。クローズドβで社内メンバーに先行公開すれば、本番リリース前にリスクを分散できます。
なるほど、確かにテストを前倒しすればリスクは減りそうです。
ただ、よく考えると「3週目から実装と並行でテスト」は、実装で手一杯なのに現実的ではない気がします。
そこで、さらにプロンプトを入力しました。
3週目は実装に集中したいです。テストは4週目からにして、リスクを減らす別の方法を提案してください
すると、AIは改善案を返してきました。
改善案（調整後）：
- 3週目：実装に集中
- 4週目：テスト開始（単体・結合）＋優先度高のバグ修正
- 5週目：クローズドβ（社内公開）＋軽微なバグ修正
- 6週目：最終調整＋本番リリース
優先度付きでバグ修正を進めることで、致命的な問題を早期に対処できます。
これなら現実的です。4週目で致命的なバグを集中的に対応し、5週目で社内公開しながら軽微なバグを修正する流れは合理的です。
問題2：リリース準備が6週目に集中していて余裕がない
また、問題1と同時にAIからこのようなコメントが返されていました。
🚨問題点：
リリースノート、ヘルプページ、サポート共有など、6週目にまとめて対応するのは厳しい可能性があります。改善案：
- 3週目後半から並行で進める
- リリースノート下書き
- ヘルプページ下書き
- 4週目：サポート共有
- 5週目：リリース時のトラブル対応手順の確認
- 6週目は「リリースボタンを押すだけ」の状態に
リリース準備を並行で進めることで、6週目の負担を減らせます。
確かに並行で進めれば余裕ができそうです。
ただ、「3週目後半から」は実装が終わっていないのにリリースノートを書けるのか疑問です。
そこで、さらに相談してみました：
リリース準備を始めるタイミングをもっと遅くして、現実的なスケジュールにして欲しい
すると、AIは改善案を返してきました
改善案（調整後）：
- 4週目から並行で進める（1-2時間ずつでOK）
- リリースノート下書き
- ヘルプページ下書き
- 5週目：サポート共有、リリース時のトラブル対応手順の確認
- 6週目は「リリースボタンを押すだけ」の状態に
実装内容が固まった4週目から、週1-2時間ずつ進めることで、6週目の負担を減らせます。
これなら現実的です。リリース週に慌てて準備するのではなく、並行で少しずつ進めることで、予期せぬトラブルにも対応できます。
改善後のプラン
AIとのやり取りを経て、最終的にこうなりました：
- 3週目: 未読バッジ実装 + デザインレビュー
- 4週目: テスト開始＋優先度高のバグ修正 + リリースノート下書き
- 5週目: クローズドβ（社内公開）＋軽微なバグ修正 + サポート共有
- 6週目: 最終確認 + 本番リリース
バグ修正の優先度付けで4週目に致命的なバグを集中的に対応。クローズドβでリスクを分散。リリース準備を並行で進めたことで6週目に余裕ができました。
AIレビューの価値
プロジェクト計画でAIレビューを使う価値を、改めて整理します。
1. 見落としやリスクを指摘してくれる
一人で計画を立てていると、「まあこれで大丈夫だろう」と思ってしまいがちです。特に、計画作成は骨の折れる作業なので、細かいチェックまで手が回らないことも多いです。
AIの客観的な視点を加えることで、見落としているタスクや潜在的なリスクに気づけます。
レビューして欲しい観点や参照して欲しいドキュメントなどを追加すれば、精度を高めていくこともできます。
2. 叩き台を作ってくれることで思考が加速する
AIは指摘するだけでなく、同時に改善案の叩き台の作成を依頼することが可能です。
叩き台がない場合:
「リリース準備の具体的なスケジュール...1週目は何する？2週目は？前後関係を考慮すると…」
→このようにゼロから考えるのは地味に時間がかかって疲れるため、精度向上にエネルギーを使えないことがあります。
叩き台がある場合:
「1週目はこれ、2週目はこれ、3週目はこれ」という提案を見る
→ 「これはいいな」「この部分は変えよう」と出てきた案をもとに改善を考えることができます。
ただし、叩き台はあくまで叩き台です。AIの提案がすべて正しいわけではないので、最終的には自分たちの頭で考えることが大切です。
それでも、ゼロから考えるより圧倒的に労力は下がりますし、浮いた労力を検討に使えるため、結果的に精度も上がります。
まとめ
AIはコード生成だけではなく、プロジェクト計画のレビューにも使えます。
見落としやリスクを指摘してくれて、叩き台で思考が加速する。
これにより、目標達成の可能性が上がります。
ぜひ、試してみてください！
書籍の紹介
本記事ではAIを活用したプロジェクト計画のレビューについて解説しましたが、「プロジェクトを成功させるための設計・モデリング」についてより体系的に学びたい方向けに、筆者はドメイン駆動設計（DDD）に関する書籍も出版しています。
プロジェクトの全体像を整理し、システムとして実装していく際の「理想形」を理解することで、AIレビューで得た指摘をより効果的に活かせます。
①基礎的な概念や考え方を学びたい方は
初めてDDDを学ぶ方、もしくは実際に着手して難しさにぶつかっている方向けの書籍です。
特に第2章「モデリングから実装まで」では、プロジェクトの目的を明確にし、それを実装に落とし込む具体的な手法を解説しています。
②実際のコードを見ながら実践したい方は
実践にあたって頻出の疑問に対して、トピックごとに詳しく解説した書籍です。
特に第2章「モデリング」では、具体的なモデリング手法と実装への落とし込み方を解説しており、プロジェクト計画を整理する際の参考にしてもらえると思います。
また、筆者は X（旧Twitter）でアジャイル・DDD・AI駆動開発に関する情報を発信しています。よろしければフォローいただけると嬉しいです。
Discussion