AIプロジェクトの週次レポート設計｜3色信号ダッシュボード・リスク先行報告・経営層が5分で判断できるステータスレポートの書き方【2026年版】

経営層が5分で判断できるステータスレポートの書き方

プロジェクトの週次報告を「作業ログの羅列」にしていませんか。経営層や責任者が知りたいのは「何をやったか」ではなく、「プロジェクトは大丈夫か」「意思決定が必要か」「リスクは何か」の3点です。

報告で大切なのは、対象期間を明記し、計画に対する進捗・見通し・リスクを確認して伝えることです。英国政府の公開標準GovS 002の7.5節も、報告の対象日・期間、計画の達成見通し、リスク・課題、必要な判断の提示を求めています。本記事の定例報告でも、変化の有無と確認時点を明記しましょう。

本記事では、AIプロジェクトの週次レポートを、3色信号（RAG）ダッシュボードで経営層に伝える設計手法を解説します。

3色信号（RAG）ステータスの定義

色	意味	アクション
🟢 Green	計画通り。リスクなし	報告のみ（意思決定不要）
🟡 Amber	リスクあるが管理可能	注意喚起＋対策案の共有
🔴 Red	計画から逸脱。即座に対処必要	エスカレーション＋意思決定依頼

QCDごとのRAG判定基準

カテゴリ	Green	Amber	Red
Q（品質）	AI精度目標を達成	精度未達だが改善余地あり	技術的に実装困難、セキュリティ基準未達
C（コスト）	予算内	予算超過見込みだが回収可能	予算消化済み、来期予算獲得困難
D（納期）	マイルストーン達成	遅延傾向だがリカバリ可能	リリース日に間に合わない、欠員発生

週次レポートの5セクション構成

セクション1：サマリー（30秒で読める）

■ 全体ステータス：🟡 Amber（開発は計画通り、デプロイ承認に遅延リスクあり）
■ 今週の成果：予定していた開発タスクの実装完了
■ 来週の予定：VM検証テスト、最終報告書ドラフト
■ 意思決定事項：なし
■ リスク：顧客環境へのデプロイ承認遅延の可能性、効果測定開始の後ろ倒し（詳細はセクション4・5）

最初のセクションだけで「大丈夫か」が判断できるようにします。詳細はセクション2以降に記載。

セクション2：マイルストーン進捗

Phase 1（要件定義）    ████████████ 100% ✅ 完了
Phase 2（開発）        ████████░░░░  70% 🟢 予定通り
Phase 3（テスト）      ░░░░░░░░░░░░   0% ── 未着手
Phase 4（最終報告）    ░░░░░░░░░░░░   0% ── 未着手

セクション3：今週の成果と来週の予定

【今週の成果】
・プルリクエスト複数件のマージ完了
・主要機能のフロントエンド／バックエンド実装完了
・検証テストの大部分が通過

【来週の予定】
・残項目の検証（ローカル環境で実施）
・最終報告書ドラフト作成
・デプロイ準備

セクション4：リスクと課題

【リスク】
🟡 顧客環境へのデプロイ承認プロセスに時間を要する可能性あり
  → 影響：本格運用開始が遅延する見込み
    → 対策：顧客担当者と承認スケジュールを確認中

【課題】
・入力値検証の実装方針に検討事項あり
  → 影響：納品後の対応で問題ないレベル

セクション5：相談・意思決定事項

■ 意思決定が必要な事項
  → 今週はなし

■ 情報共有
    → 顧客都合により一部作業が停止中のため、効果測定の開始時期を後ろ倒し

「無」を報告する技術

最も重要なのは、「何もない」を報告することです。

毎日の定点報告テンプレート

進捗：予定通り（◯/△/×）
リスク：なし
次アクション：本日○○を実施

週次の定点報告テンプレート

進捗：今週の達成 / 残タスク
リスク：来週の懸念
次アクション：来週のToDo

「何もありません」と書く場合も、上長が「どの時点で、何を確認したか」を把握できるようにします。上のテンプレートで進捗・リスク・次アクションを点検し、前回からの変更がない項目も確認した結果として記載してください。

報告の頻度設計

場	頻度	内容	対象者
チャット	毎日	3行の定点報告	チーム全体
週次定例	週1回	5セクション構成レポート	PM + チーム
月次報告	月1回	マイルストーン＋KPI＋予算	責任者 + 経営層
ステコミ	四半期	問題ないことの確認	役員

AIによるレポート自動生成

AIで自動化できる部分

• 成果の自動収集：Git履歴、PRマージ、チケットクローズからAIが今週の成果を自動抽出
• マイルストーン進捗の計算：タスク完了率からフェーズ別進捗を自動算出
• リスクの定型フォーマット化：課題管理表からリスク→影響→対策の形式に自動変換

人間が書くべき部分

• RAG判定：「この状況はGreenかAmberか」はビジネス判断
• 意思決定事項：何を経営層に判断してもらいたいかは人間が考える
• コンテキストの補足：数字には表れない「空気感」の伝達

レポートのアンチパターン

アンチパターン	問題	改善
作業ログの羅列	「何をやったか」は分かるが「大丈夫か」は分からない	サマリーにRAGステータスを冒頭配置
良いニュースだけ報告	リスクが隠され、発覚時にはリカバリ不可	リスクは「小さいうちに」報告する文化
詳細すぎる技術報告	経営層が読めない	技術詳細は付録に移動、サマリーはビジネス言語
報告頻度が不定期	「聞かないと出てこない」状態	曜日・時間を固定（毎週金曜17時等）

定例会議との連動設計

週次レポートは、定例会議のアジェンダと連動させます。レポートを事前共有し、会議では意思決定が必要な事項のみ議論します。

定例会議アジェンダ（30分）
1. RAGステータス確認（2分）— レポートのサマリーを確認
2. リスク・課題の議論（10分）— AmberまたはRedの項目のみ
3. 意思決定事項（10分）— 相談セクションの項目を決定
4. 次週の計画確認（5分）
5. その他（3分）

まとめ：週次レポート設計チェックリスト

項目	チェック
RAGステータス	QCD各カテゴリのRAG判定基準が定義されているか
サマリー	30秒で「大丈夫か」が判断できるか
マイルストーン	視覚的な進捗バーが含まれているか
リスク	リスク→影響→対策の3点セットで記載されているか
意思決定	経営層に判断してもらいたい事項が明記されているか
「無」の報告	「問題なし」も明示的に報告しているか
頻度	日次/週次/月次/四半期の4層で設計されているか
AI活用	成果収集・進捗計算がAIで自動化されているか

週次レポートは「義務」ではなく「信頼獲得の武器」です。経営層が5分で判断できるレポートを毎週出し続けることで、「このチームは任せておける」という安心感を積み上げてください。

関連記事

• プロジェクト設計テンプレート
• リスクマネジメント
• 週次レポート設計
• 見積もり技術

PMOコンサルティングのご相談はrenueまで。