プロジェクト進捗報告書テンプレート：週次フォーマットと記入例 — リキャップから報告書が自然にまとまる仕組み（2026）

プロジェクトの進捗報告書は、日々の作業に関わっていない人に、プロジェクトの現在地を伝える短い定型のページです。順調かどうか、前回の報告から何が変わったか、何がうまくいかなくなりそうか、読み手に何の判断を求めているか、を書きます。ほとんどのプロジェクトでは週次など決まった頻度で書き、毎回同じ形のページにします。読み手はゼロから読むのではなく、今週と先週を比べられます。

このガイドでは、まず書き方そのものを説明します。フォーマット、コピーして使えるテンプレート、記入例、チームリーダーが上長に出す短い週次版です。そのあとで、報告書だけで足りる場合とそれでも進捗会議を開く価値がある場合、すでに使っているツールのどこで報告書を書くのか、会議とページのあいだで何が起きているのかを扱います。報告書で一番大変なのは、書くことそのものではないからです。大変なのは書く前の30分、つまりリーダーが1週間分の通話やチャットを見返して、実際に何が合意されたのかを調べる時間です。

プロジェクト進捗報告書とは、そして何ではないか

プロジェクトの周りには4種類の文書があり、報告書はその中でも他と混同されやすいものです。

リキャップは会議ごと、報告書はすべての会議をまたいだ週ごとのものです。スタンドアップは、ブロッカーを取り除ける人に問題を届けます。報告書は、そのブロッカーが期日を脅かしているかどうかを、離れた場所にいる人に伝えます。意思決定ログは「なぜ」を残します。報告書が伝えるのは、決定がなされたこと、またはまだ必要なことだけです。報告書が書きにくいなら、原因はほぼ必ず上流にあります。その週の会議が結果の記録を残さなかったため、リーダーが金曜の午後に記憶から再構成しているのです。

週次フォーマット：6つのブロック、1ページ

毎週読まれる報告書は、1画面に収まり、いつも同じ形でなければなりません。次の6つのブロックをこの順に並べます。

1. ヘッダー。 プロジェクト名、報告期間、作成者、次回報告の日付。読み手はまず期間を探します。期間のない報告書は、「いつから」のない主張の羅列です。
2. 全体ステータスを1行で。 緑・黄・赤、あるいは順調・リスクあり・遅延のいずれかと、理由を述べる1文を添えます。色は下のブロックの要約であり、印象で決めるものではありません。リスクのブロックにサプライヤーが2週間遅れたと書いてあるなら、この行を緑にはできません。
3. 前回報告からの進捗。 完了したことを3〜6行で、作業内容ではなく成果として書きます。「チェックアウトフローをクライアントがレビュー中」は事実です。「チェックアウトに取り組んだ」は事実ではありません。
4. 次期。 次回報告までにチームが完了を約束することを、担当者つきで書きます。このブロックが、来週の進捗ブロックと照合される基準になります。
5. リスク、課題、必要な判断。 リスクはこれから起こりうること、課題はすでに起きたことです。各行には、何が、期日や予算にどう影響するか、担当者、読み手に何をしてほしいかを書きます。「なし、情報共有のみ」も含みます。必要な判断は独立した行にし、プロジェクトがその答えを必要とする期日を添えます。
6. 未完了のアクション。 この期間のどの会議から出たものでも、まだ終わっていないアクションを、担当者と期日つきで並べ、期限を過ぎたものには印をつけます。ほとんどの報告書が省くブロックですが、読み手がブロック2の色が正直かどうかを判断するのに使うのがこれです。

載せないほうがよいものが3つあります。やり取りの再現（誰が何を言ったか）、作業ログ（時間数や開催した通話の回数）、そして読み手が行動に移せない情報です。報告書は4分しか使わない人のためのものです。どの行も「これを知って、読み手は何を変えるのか」という問いに耐えるべきです。

プロジェクト進捗報告書テンプレート

ドキュメント、チャンネルへのメッセージ、キャンバスなどにコピーして使ってください。角括弧はプレースホルダーです。

[プロジェクト名] — 進捗報告書 [期間（例：10月20日〜24日）]
作成者： [氏名] · 送付日： [日付] · 次回報告： [日付]
全体：[順調 / リスクあり / 遅延] — [理由を述べる1文]

前回報告からの完了事項
– [成果を事実として] — [担当者]
– [成果] — [担当者]
– [成果] — [担当者]

次期（[次回報告日]まで）
– [成果物] — [担当者]
– [成果物] — [担当者]

リスクと課題
– [リスクまたは課題] — 影響：[期日 / 予算 / スコープ] — 担当：[氏名] — 依頼：[期日までに必要な判断 / 情報共有]

必要な判断
– [検討中の選択肢を添えた問い] — [日付]までに必要 — 判断者：[氏名]

未完了のアクション
– [タスク] — [担当者] — 期日 [日付] — [未完了 / [日付]から期限超過]
– [タスク] — [担当者] — 期日 [日付] — [未完了]

順序には意図があります。最初の3行だけ読むスポンサーは、色とその理由がわかります。最後まで読む人は、その色を説明するアクションまで得られます。見出しは毎週同じにしてください。このフォーマットの価値は比較できることにあります。

例：週次進捗報告書の記入例

小規模なソフトウェアプロジェクトで、2言語のチーム、クライアントが毎週月曜に報告書を読むケースです。

受注ポータル v2 — 進捗報告書 10月20〜24日
作成者： Mateusz · 送付日： 10月24日 · 次回報告： 10月31日
全体：リスクあり — 決済プロバイダーのサンドボックスが4日遅れて到着。統合テストが10月29日までに通った場合のみ、ローンチ日を維持できます。

前回報告からの完了事項
– チェックアウトフローをクライアントがレビュー中、コメント2件が未解決 — Ana
– ERP からの商品インポートがステージングで毎晩稼働 — Priya
– スペイン語とルーマニア語の UI 文言が完了、フランス語は80% — Luca

次期（10月31日まで）
– プロバイダーのサンドボックスで決済統合テスト — Priya
– チェックアウトのクライアント承認 — Ana
– フランス語の文言を完了し、3言語すべてのレビューを終える — Luca

リスクと課題
– 決済サンドボックスの遅延（課題） — 影響：テストが10月29日までに通れば11月7日のローンチを維持、通らなければ11月14日 — 担当：Priya — 依頼：情報共有、判断は下記
– クライアントのレビュー所要時間（リスク） — 影響：1回のレビューに3日かかる。3回目のレビューになると承認がテスト期間を過ぎる — 担当：Ana — 依頼：クライアントにコメントを1回にまとめてもらう

必要な判断
– 10月29日にテストが失敗した場合：決済ありで11月14日にローンチするか、請求書払いのみで11月7日にローンチして、カード決済は後から追加するか — 10月30日までに必要 — 判断者：クライアント

未完了のアクション
– プロバイダーに IP 許可リストを送る — Priya — 期日 10月21日 — 10月21日から期限超過
– ホスティングパートナーとカットオーバーの時間帯を確認する — Mateusz — 期日 10月28日 — 未完了
– チェックアウトの2件のコメントに返信する — Ana — 期日 10月27日 — 未完了

この例が何を書いていないかに注目してください。開いた会議の回数も、誰が話したかも、かけた時間数もありません。読み手は、期日が危ないことを1行で、自分が何を判断するのかを1ブロックで知ることができます。

チームリーダー向けの週次報告テンプレート

チームリーダーが自分の上長に出す週次報告は、プロジェクト報告書の短い親戚です。読み手は1人で、たいてい2分もかけられません。知りたいのは、チームはコミットメントどおりか、何が妨げになっているか、自分に何を求めているか、の3点です。チャットメッセージに収まる4つのブロックで足ります。

チーム [名前] — [日付]の週
ステータス： [順調 / リスクあり] — [1行]
完了： [2〜3件の成果、それぞれに名前]
妨げになっていること： [1〜2件のブロッカー、それぞれ誰なら解消できるか]
お願いしたいこと： [1件の判断またはリソース、期日つき] — または「今週はなし」

数か月続けても読みやすくなる決まりが2つあります。1つ目は、「お願いしたいこと」をうっかり空欄にしないことです。「今週はなし」と書けば、マネージャーは沈黙が意図的なものだとわかります。2つ目は、「完了」に人の名前を挙げることです。週次報告は、日々の仕事を見ていない人に、リーダーがチームの仕事を見えるようにする場でもあります。チームがすでに名前つきのブロッカーを扱う日次のスタンドアップを行っているなら、「妨げになっていること」は金曜時点でまだ残っているブロッカーの写しになります。

週次報告は、週次の進捗会議が担っていたことの大半、つまり情報の伝達を置き換えます。置き換えられないものについては、次に説明します。

進捗会議がそれでも必要なとき

進捗会議は報告書の生版です。各自がリーダーやスポンサーに、その場で、全員の時間を使って現状を伝えます。書面の報告書があるなら、会議が正当化されるのは、ページでは役目を果たせないときだけです。次の4つの場合があります。

• トレードオフのある判断。 報告書は選択肢を示せますが、交渉まではできません。「必要な判断」に、2人のステークホルダーが何を譲れるかで答えが変わる項目があるなら、2人が同席する30分のほうが、2週間の全員返信より早く決着します。
• 期日が動くとき。 遅れがページだけで受け入れられることはまれです。それに伴って何が動くか、つまりスコープ、予算、別プロジェクトの開始といった話し合いは会議で行い、報告書はその事前資料になります。
• リスクが閾値を超えたとき。 リスクが課題に変わった週には、その結果に責任を持つ人たちが、月曜に読むのではなく、リーダーから直接聞いて質問する必要があります。
• 新しいステークホルダー。 過去6回の報告書を読んでいない人には、プロジェクトの全体像をつかむためのセッションが1回必要です。その後はページで足ります。

進捗会議は、報告書を読み上げる場ではありません。議題がすべて「Xからの報告」なら、会議は中止してページを送ってください。どの定例会議が時間を使う価値があるかは、ミーティングケイデンスのガイドで扱っています。会議を開くなら報告書を土台に進めます。リスクと判断のブロックが議題になり、効果的な会議は、それらの項目に「決定済み」「未解決」「保留」の印をつけて終わります。異なる言語を話すステークホルダーがいる場合、会議そのものの進め方には3つの選択肢があります。人間の通訳（その設定方法は Zoom の通訳のガイドで紹介しています）、プラットフォーム標準の字幕、参加者ごとに翻訳するスペースです。一度書けば済む報告書は、これとは別の問題です。

すでに使っているツールのどこで報告書を書くか

主要なプラットフォームはどれも、会議のあとに進捗報告書の材料になるものを残しますが、それぞれ止まる地点が違います。以下は各ベンダー自身のページに記載された動作のみで、各ページを確認した月を添えています。

どのツールにも共通することが2つあります。会議が残すのは会議ごとに1つの文書で、会議で使われた一つの言語で書かれていること。そして、先週のネクストステップが実行されたかどうかは文書にはわからず、リーダーが「完了」と書く前に自分で確認しに行くことです。プラットフォームのライブ字幕、つまり通話中に Teams や Google Meet が画面に表示するものは、あとに残る文書を変えません。ノートテイカーも同じ種類で、もう一歩先にいるだけです。Otter.ai の代替で比較しているツールは会議ごとに要約を書きますが、1か月分の会議にまたがる報告書は、やはり別のページになります。

リキャップから報告書が自然にまとまる仕組み

InterMIND は、プロジェクトがチャンネルの中で進むコミュニケーションのスペースなので、報告書の素材には自然な置き場所があります。チャンネルでの会議はどれも、要約、決定事項、担当者と期日つきのアクションアイテムからなるリキャップで終わります。リキャップは会議そのものから作られ、メール、チャンネル内のメッセージ、カレンダーイベントのリンクとして届きます。サインインしているメンバーは誰でも、リキャップを自分の言語で読めます。記録は読み手ごとに翻訳されるもので、たまたまその会議で使われた言語で一度だけ書かれるのではありません。その周りのチャンネルのチャットも、各メンバーが自分の言語で書きます。どのメンバーもリキャップを編集でき、編集のたびに作成者と改訂履歴が残り、チャンネルには過去のすべてのセッションのリキャップが残ります。そのため「前回報告からの完了事項」は、再構成ではなく、その週のリキャップをスクロールして拾う作業になります。

アクションアイテムはステータスを持ち運びます。項目は、未着手、完了、または理由つきの未完了として表示されます。チームステータスページをオンにしている組織では、次のリキャップが書かれるときに、以前のセッションの未完了の項目が判定されます。終わったと報告された項目は完了に、話題には出たが終わらなかった項目は会議での言葉による理由つきで未完了に、誰も触れなかった項目は未着手のままになります。これはテンプレートの「未完了のアクション」ブロックにあたり、リーダーではなく会議が管理してくれます。

報告書の残りの部分は、チームステータスページから得られます。直近7日、28日、90日のいずれかを対象にした1つのページに、組織のタスク、問題、重要で緊急なこと、関わる金額が一覧され、すべての行に根拠となったリキャップからの原文引用がついています。タスクは誰かが閉じるまで残り、4週間動きがなければ停滞と表示されます。リーダーが書くのは、推移の行と色、つまり判断の部分だけです。会議がすでに埋めたページの上に書きます。同じページは、接続したアシスタントからも読めます。Claude、ChatGPT、Copilot、Gemini で仕事をしているリーダーは、その週の未完了のタスクと問題を尋ねれば、引用つきの行を受け取れます。チームステータスページは有料プランのプレビュー機能です。組織の管理者がアルファ版の利用条件に同意したうえで、Settings → Advanced からオンにします（各機能の説明はプレビュー機能のページにあります）。

報告書を記録システムに届ける必要がある場合は、ホストが任意のアドレス、たとえば CRM やプロジェクトトラッカーの受信用メールボックスにリキャップのコピーを追加できます。そのアドレスを一度だけ確認すると、その会議またはチャンネルのすべてのリキャップがそこにも送られます。仕組みはすべての会議リキャップのコピーをメールで CRM に届けるで説明しています。同じリキャップは Webhook や Zapier のトリガーとしても届くので、自分でトラッカーに投稿するチームにも使えます。

リキャップを見るべきクライアント側のステークホルダーは、メールでチャンネルに招待され、無料アカウントで参加して、自分の言語で読みます。チャンネルの外部参加者に、ホストの費用はかかりません。1回の会議のゲストは、アカウントなし、無料で、リンクから参加します。スマートフォンでもブラウザからでも参加でき、会議をその場で自分の言語で聞けます。ゲストには、あとから見られる記録はありません。アカウントは無料で、記録に届くようにするのがアカウントです。ホストがスペースを用意し、有料プランでは直近28日間にアクティブだったメンバーの分だけを支払います。静かになったメンバーも、費用なしでアクセスを保てます。

• 完全なリキャップを開く — あなたのリキャップを書くのと同じコードで描画された、実際の記録です。
• ライブデモを試す — 登録不要。話すと、聞き手ごとに翻訳された会議が聞こえます。

技術としての報告書は、どのツールでも生き残ります。プロジェクトが順調かどうか、そしてその理由を言うのは、結局人だからです。生き残らなくてよいのは、金曜の30分です。1週間分の通話を、一つの言語のまま見返して、何が合意され、誰かがそれを実行したのかを調べる時間は、もう要りません。

FAQ

プロジェクト進捗報告書とは何ですか？

決まった頻度、たいていは毎週送る短い定型のページで、日々の作業に関わっていない人に、プロジェクトの現在地を伝えます。内容は、理由つきの全体ステータス1行、前回報告から完了したこと、次回までに予定していること、期日や予算への影響つきのリスクと課題、読み手に求める判断、そして担当者と期日つきでまだ終わっていないアクションです。毎回同じページなので、読み手はゼロから読むのではなく、週ごとに比べられます。

週次の進捗報告書には何を含めるべきですか？

6つのブロックです。報告期間つきのヘッダー、理由つきの全体ステータス1行、作業ではなく成果として書く前回報告からの進捗、担当者つきの次期のコミットメント、それぞれ影響と依頼を添えたリスク・課題・必要な判断、そして担当者と期日つきのすべての未完了アクション（期限超過のものには印をつける）です。やり取りの再現、作業時間、読み手が行動に移せないことは省きます。

プロジェクト進捗報告書はどう書きますか？

前回の報告書から始めます。その「次期」ブロックが今週のチェックリストで、未完了のアクションは完了したか、まだ未完了かのどちらかです。次に、その週の会議リキャップを見て、何が決まり、何が追加されたかを拾います。ステータスの行は、色が事実と合うように、リスクのブロックのあとで最後に書きます。毎週同じ日に、同じ宛先に送り、見出しは報告ごとに変えないでください。

進捗報告書と進捗会議の違いは何ですか？

進捗報告書は書かれて非同期に読まれます。進捗会議は同じ情報をその場で伝えるもので、その場にいる全員の時間を使います。報告書があるなら、会議が正当化されるのはページでは役目を果たせないときです。つまり、ステークホルダー間のトレードオフを伴う判断、動いている期日、課題に変わったばかりのリスク、プロジェクトの全体像を一度つかむ必要がある新しいステークホルダーです。議題が「各自からの報告」の会議は、報告書の読み上げにすぎません。

チームリーダー向けの週次報告テンプレートは、プロジェクト進捗報告書と違いますか？

より短く、1人の読み手に宛てています。チームリーダーが上長に出す週次報告は、4つのブロックで3つの問いに答えます。1行のステータス、チームが完了したこと（名前つき）、妨げになっていることと誰なら解消できるか、上長に何をいつまでにお願いしたいか、です。チャットメッセージに収まります。プロジェクト進捗報告書はより長く、期間と複数のステークホルダーにまたがり、プロジェクトのすべての会議にわたるリスク、判断、未完了のアクションを載せます。

プロジェクト進捗報告書はどのくらいの頻度で送るべきですか？

ほとんどのプロジェクトでは毎週です。遅れが1週間以内に見つかるくらい頻繁で、毎回の報告に新しい内容があるくらいには間隔が空いています。長く安定していて判断の少ないプロジェクトには隔週が向いています。日次の報告はローンチ週やインシデントのためのもので、別の、より短い文書です。頻度がどうであれ、曜日と宛先は変えないでください。毎週違う日に届く報告書は、シリーズとして読まれません。

進捗報告書はクライアントにも送るべきですか？

はい。クライアントがプロジェクトの費用を負担していて、報告書の中に判断を下すのがクライアントである項目があるなら送ります。「必要な判断」ブロックは、クライアントのために書くものです。可能であれば、クライアント向けと社内向けに分けず、全員に向けて1つの報告書を書いてください。2版ある報告書は内容がずれていき、社内版が事実上の本物になります。共有する報告書に載せないのは、チームの内部事情、たとえば個人の評価や交渉中の見積もりで、これらはリーダー自身のメモに書くべきものです。

出典：Microsoft — Microsoft Teams で会議メモを取る、Microsoft — Microsoft Teams のリキャップ、Zoom — AI Companion による会議サマリーの利用、Google Meet — Google Meet の「Take notes for me」、Google Workspace Updates — 「Take notes for me」が次のステップを提案、Slack — 会議アジェンダテンプレート（キャンバス）。Microsoft のメモ、Google Meet のメモ、Slack のページは2026年10月に、Google の次のステップの発表は2026年9月に、Microsoft のリキャップと Zoom の会議サマリーのページは2026年8月に確認しました。ベンダーはプラン、機能、対応言語を随時変更します。最新の状況は各社のページでご確認ください。