業務委託の作業報告書の書き方｜フリーランスエンジニアの記載項目とテンプレート

業務委託の作業報告書とは

業務委託の作業報告書は、委託元に対して受託者の稼働・作業実績を記録して提出する書類です。契約書に報告義務が明記されているケースと、慣習として提出しているケースの両方があります。

作業報告書・稼働報告書・工数報告書の違い

呼び方が混在しやすいので整理しておきます。実務では厳密な区別なく使われることが多いものの、以下のニュアンスがあります。

本記事では、フリーランスエンジニアの実務で最も汎用性の高い「作業報告書」を軸に、稼働時間と作業内容の両方を1枚に収める書式を扱います。

提出は法的義務か

委任契約（準委任を含む）では、民法644条・645条により受任者に善管注意義務と報告義務があり、委任者からの請求があれば経過や結果を報告する必要があります。ただし「毎月末に定型書式で提出する」という運用そのものは民法が定めるものではなく、契約書や案件の運用ルールに従って決まるのが実務です。

請負契約について、民法上は委任契約のような一般的な報告義務規定はありません。ただし契約書で進捗報告義務を定めるのが実務上は一般的で、その場合は定められた頻度・粒度に従います。

参考: e-Gov 民法

作業報告書と関連書類の役割分担

作業報告書は請求書とセットで使う場面が多いため、混同を避ける整理が要ります。作成の流れとしては、月末に作業報告書で稼働実績を確定させ、その内容に基づいて請求書を発行します。検収と請求の時系列は「検収・請求のタイミングと入金トラブル回避」で整理しています。

ミニFAQ

Q. エージェント経由の準委任だが、作業報告書は必要？

A. ほとんどのエージェントで所定のフォーマット（勤怠表・稼働報告書）の提出が必須です。指定書式がある場合はそれに従い、自作の作業報告書を追加で出す必要は基本的にありません。

Q. 契約書に「報告義務」の記載がなくても提出したほうがよい？

A. 準委任なら民法上の報告義務があり、提出しておくのが安全です。請負でも「稼働の証跡」として月次で残しておくと、後日のトラブル対応で役立ちます。

準委任と請負で作業報告書の内容はどう変わる

契約類型で報告の中心がずれるため、書式を分けるか、同じ書式内で強弱を変える必要があります。契約類型の詳しい違いは「準委任契約と請負契約の違い」を参照してください。

準委任契約：稼働時間ベース

準委任は「業務の遂行」に対して報酬が発生する契約です。時間精算型（月額固定＋精算幅など）の案件では稼働時間の実績が支払根拠になるため、以下を中心に書きます。固定月額で精算幅がない案件、日額精算・時給精算の案件など、報酬設計は複数あるため、契約書の報酬条項で該当形態を確認します。

• 日別の稼働時間（開始・終了・休憩・実働）

• 月次の稼働時間合計

• 精算幅（140-180h等）に対する超過・控除の判定

• 稼働時間内で実施した作業内容

精算幅（140-180hといった上下限）の考え方は「準委任の精算幅とは」で解説しています。

請負契約：成果物・進捗ベース

請負は「成果物の完成」に対して報酬が発生する契約です。稼働時間ではなく、以下を中心に書きます。

• 対象成果物（機能・ドキュメント・納品物）

• 進捗率（完了／進行中／未着手）

• マイルストーンごとの達成状況

• 発生した課題・仕様変更の記録

工数の予定と実績の対比は「工数見積もりのやり方」の枠組みが使えます。

直請け／エージェント経由でも書式は変わる

契約類型に加えて、契約の入り口でも書式が変わります。特にエージェント経由は所定フォーマットが指定されるケースが大半です。

作業報告書に必須の7つの記載項目

汎用テンプレートを自作する場合は、以下の7項目を漏らさないようにします。

① 表紙情報（宛先・報告期間・報告者）

• 委託元の会社名・部署・担当者名

• 報告者（自分）の氏名・屋号

• 報告日（作成日）

• 対象期間（例：2026年8月1日〜8月31日）

② 稼働期間と締日

契約書に定められた締日と対象期間を明記します。フリーランスエンジニア向けのエージェント経由案件では月末締めの運用が多い一方、20日締めや15日締めの案件もあります。締日を間違えると請求サイクルが1ヶ月ずれるため、初回作成時は契約書の該当箇所を確認してから記入します。

③ 稼働時間・稼働日数の実績

日別に開始・終了・休憩・実働時間を並べる形式が基本です。月次合計と、精算幅がある場合は上下限との差分も添えます。

④ 作業内容

日別または週別に、担当したタスクを箇条書きします。粒度は「委託元が読んで内容が把握できる」程度が目安です。粒度の設計は次のH2で詳しく扱います。

⑤ 成果物・進捗の状況

該当機能のプルリクエスト番号、ドキュメントのファイル名、レビュー完了の可否など、成果物側の状況を書きます。準委任でも、稼働時間だけでなく「その稼働で何が進んだか」を1〜2行添えると読まれやすくなります。

⑥ 特記事項・課題共有

想定外の対応、仕様変更、稼働時間が精算幅を外れた理由、翌月に持ち越す論点などをまとめます。空欄でも構いませんが、月次のコミュニケーション経路として活用すると継続受注に効きます。

⑦ 署名・押印欄

紙運用なら押印、電子運用なら電子署名または送信メールの記録で代替します。押印を求められないケースも増えているため、契約書か担当者に事前確認します。

ミニFAQ

Q. 記載項目に不足があると請求書は受理されない？

A. エージェント経由では、稼働時間の合意が取れないと請求が翌月ずれになるケースがあります。直請けは委託元次第ですが、稼働時間の記録がないと後日の疑義に対応できません。

稼働時間の書き方（精算幅・端数処理）

時間精算型の準委任案件では稼働時間の書き方が入金額に直結します。以下の3点を契約書と突き合わせて記入します。精算幅がない案件（固定月額・成果報酬など）では、稼働時間の記載はあくまで作業実績の証跡としての位置付けになります。

精算幅の判定を書式に組み込む

精算幅は「140-180h」のように月間稼働時間の下限・上限が設定されている運用で、時間精算型の準委任案件で採用されるケースが多い仕組みです。この範囲に収まれば固定単価、上振れは超過単価×時間、下振れは控除単価×時間で調整されます。作業報告書には月次合計だけでなく、下限との差分・上限との差分を並記すると計算根拠が明確になります。

例：稼働実績175h／精算幅140-180h／控除・超過なし

例：稼働実績195h／精算幅140-180h／超過15h × 超過単価○○○円

端数処理の単位

15分単位・30分単位・1時間単位のいずれで丸めるかは契約書に明記されているのが原則です。記載がなければ着任時に確認します。エージェント経由の準委任案件では15分刻み・切り捨てを採用するケースが多く見られますが、直請けでは事前合意なしに切り上げると認識ズレになります。

休憩時間の扱い

常駐や日次打刻の案件では、昼休憩1時間を稼働時間から控除する運用が多く見られます。フルリモート・裁量運用の案件では固定休憩を置かず実働ベースで記録する形式もあります。ミーティング中の待機・チャット対応・レビュー待ちなど、受動的な時間を稼働に含めるかは案件のルールに従います。曖昧なまま毎月書いていると後日の指摘対象になるため、初月に一度確認します。

このあたりの契約書側の書きぶりは「業務委託契約書の確認ポイント」でチェックリスト化しています。

作業内容の書き方（読まれる粒度）

作業内容欄は「委託元の担当者が10秒で把握できる」ことが目標です。具体的には、日付・対象タスク・進捗結果の3点が1行で読める粒度が目安です。冗長すぎず、抽象的すぎない粒度を狙います。

日別サマリで書く場合

準委任で稼働日数が多い案件では、日別に主要タスクを1〜3行で並べます。

• 8/1（月） ユーザー認証APIの実装レビュー対応／不具合起票2件／定例MTG

• 8/2（火） 認証API修正コミット／統合テストシナリオ作成

週次まとめで書く場合

タスク粒度が細かい案件や、週次レビュー中心の運用では、週単位のサマリが読まれやすいです。

• 第1週（8/1-8/7） 認証API実装完了。統合テスト着手。仕様確認1件を課題として提起

• 第2週（8/8-8/14） 統合テスト継続。エラーハンドリング設計をレビュー通過

タスク・チケットとの紐付け

Jira・Backlog・GitHubのIssue番号を書き添えると、委託元側のトラッキングと突合しやすくなります。「ISSUE-123 認証API実装」のように書式を統一しておくと、後日の集計にも使えます。

書きすぎ・書かなすぎのバランス

書きすぎは負担になり、書かなすぎは根拠不足になります。目安は「委託元の担当者がその月の請求根拠を判断できる最小情報」です。日常の稼働・工数記録の設計は「フリーランスエンジニアの稼働・工数管理」で扱っています。

テンプレートの入手と自作の勘所

一から作らず、既存テンプレを流用して案件ごとに調整するのが実務的です。

無料テンプレートの入手先

• freee「稼働報告書の無料Wordテンプレート」など、会計・人事系サービスが配布している雛形

• Excel／Word／Googleスプレッドシートの3形態が主流

参考: freee 稼働報告書テンプレート

指定フォーマットが提示されていない直請け案件では、これらを起点にして案件ごとに列を追加します。

エージェント指定フォーマットに合わせる場面

エージェント経由は基本的に指定フォーマットに従います。よくあるのは以下のパターンです。

• 勤怠管理サービス（勤怠SaaS）で日別の打刻を入力し、自動で稼働報告書がPDF生成される

• Excelテンプレートに月次稼働を記入し、エージェントに送付

• 委託元のシステムに直接打刻する（併せて請求根拠として月次書類も別送）

自作テンプレの必須列

自作する場合は、以下の列があれば汎用的に使えます。

簡易記入例

自作テンプレの記入イメージは以下の程度で十分です。実案件では日別の稼働時間表と合わせて1〜2枚に収めます。

• 報告期間：2026年8月1日〜8月31日

• 総稼働時間：168h（精算幅140-180h／控除・超過なし）

• 主要タスク：ユーザー認証APIの実装、統合テストシナリオ作成、定例MTG参加

• 成果物：PR#123・#128 マージ済み／統合テストシナリオv1レビュー中

• 特記事項：8/20仕様変更対応（工数影響は精算幅内で吸収）

ミニFAQ

Q. 手書きでよいか、PDFかExcelか？

A. 委託元指定がなければ、承認フローに合わせてPDFまたはExcelを選びます。改ざん防止や確定版の共有を重視するならPDFが無難で、委託元側で再計算・検証が入る運用ならExcelが扱いやすいです。

Q. Excelで送るとき、計算式は残す？

A. 月次合計の集計セルは残して構いませんが、送付前に「値貼り付け」でロックする案件もあります。委託元側の運用に合わせます。

提出タイミングと請求書との関係

作業報告書と請求書は密接に連動します。順序を間違えると入金遅延の原因になります。

月末締めの標準的な流れ

1. 月末最終稼働日に稼働実績を確定

2. 翌営業日〜3営業日以内に作業報告書を送付

3. 委託元またはエージェントの承認を受ける

4. 承認された稼働時間で請求書を発行

5. 契約書に定めた入金サイクル（末日締め翌月末払い等）で入金

作業報告書の承認が遅れると請求書発行がずれ、入金も1ヶ月ずれるリスクがあります。月末〜月初はスピード優先で処理します。

検収との関係

請負案件では「検収通過＝支払条件」となるのが一般的です。作業報告書は検収の一次資料として使われるため、成果物の完成状況は事実ベースで記載します。不確定な進捗を「完了」と書くと、後日の検収差戻しにつながります。

請求書と別書類として送るか同時に送るか

エージェント経由では「作業報告書＝月内に承認、請求書＝翌月頭に発行」の2段構えが多いです。直請けでは、作業報告書と請求書を同時に送付することもあります。運用に決まりがなければ、初月にどちらのパターンかを担当者に確認しておきます。

ケース別解説

新規参画1ヶ月目の初回作成

初月は締日・稼働時間の丸め方・提出先の3点を契約書と着任時のオリエンで固めます。フォーマット未指定なら、次月以降も同じ様式で運用できる自作テンプレを作っておくと運用が楽になります。着任前後の全体的な流れは「フリーランス案件参画までの流れ」で解説しています。

エージェント経由で精算表が指定されているケース

エージェントの勤怠管理サービスに日次打刻し、月次で自動生成される稼働報告書を承認する運用が主流です。休憩・打刻漏れは月中にリカバリしないと、月末に稼働時間が過小報告されます。

直請けでフォーマット指定がないケース

自作テンプレを提示し、初月に「この様式で毎月提出します」と合意を取っておくと、以降の作成が楽になります。委託元側で受け入れ書式に指定があれば従います。

複数案件を掛け持ちしているケース

案件ごとに書式・締日・端数処理が異なるため、案件別にテンプレートを分けて保管します。稼働時間帯の交渉や案件重複の整理は「業務委託の稼働条件交渉」に詳しくまとめています。

作業報告書でよくある失敗と対策

稼働時間の集計ミス

日別実働の合計が月次合計と一致しないケースは頻出です。表計算ソフトのSUMだけに頼らず、送付前に手計算で1回チェックします。精算幅の判定を間違えると超過分の入金漏れが発生します。

「打ち合わせ」「その他」の粒度が粗すぎる

「その他」「対応」だけでは請求根拠として弱いため、対応内容を最低1語添えます。「打ち合わせ（要件確認）」「対応（不具合調査）」といった粒度でも十分です。

成果物の完了/未完了が曖昧

「実装済み」「レビュー中」「レビュー完了」「マージ済み」を混在させず、案件で用語を統一します。プルリクエスト番号を書き添えると誤解が減ります。

契約書の報告義務と食い違う

契約書で「週次報告」と定められているのに月次でしか出していない、といったズレは、委託元の内部統制や契約管理の確認時に問題化しやすいです。契約書の該当条項を月初に確認するのが安全です。

記載項目チェックリスト

送付前に以下を1つずつ確認します。

このチェックリストを稼働時間の判断と組み合わせると、時給換算の妥当性も確認できます。自分の月次稼働と単価が市場感覚から外れていないか気になる方は、無料のフリーランスエンジニア単価診断で目安を確認できます。単価を体系的に上げる考え方は「フリーランスエンジニアの単価相場と単価の上げ方」で整理しています。

まとめ

業務委託の作業報告書は「稼働の記録」と「請求の裏付け」を両立させる書類です。準委任は稼働時間、請負は成果物という中心を外さずに、7つの必須項目を漏らさず記載すれば、初参画でも通用する書式が作れます。

要点を整理します。

• 契約類型（準委任／請負）で報告の中心が変わる

• 必須は表紙情報・稼働期間・稼働時間・作業内容・成果物・特記事項・署名の7項目

• 稼働時間は精算幅・端数処理・休憩の3点を契約書と一致させる

• 作業内容は「担当者が10秒で把握できる」粒度で書く

• 月末締めの流れでは、作業報告書→承認→請求書の順を崩さない

• エージェント経由は指定フォーマット、直請けは自作テンプレを初月合意で運用

次のステップとしては、初回の作業報告書を作る前に、契約書の締日・精算幅・報告頻度の3点を確認します。契約書側の確認観点は「業務委託契約書の確認ポイント」に、請求書の発行手順は「フリーランスエンジニアの請求書の書き方」にまとめています。案件参画の全体的な流れをまだ整理していない方は「フリーランス案件参画までの流れ」もあわせて確認しておくと、初月の運用がスムーズです。