Skip to content
Published on

Complete Guide to Japanese Business Email and Report Writing: Mastering Keigo and Professional Expressions

Authors
  • Name
    Twitter
Japanese Business Email Guide

Introduction

For engineers working at Japanese IT companies, the ability to write business documents in Japanese is just as critical as coding skills. No matter how strong your technical abilities are, if you cannot use keigo (honorific language) properly in business emails or if your report format does not conform to Japanese business conventions, you risk being perceived as unprofessional.

Japanese workplace culture is built on the communication principle known as Ho-Ren-So (報告・連絡・相談). Ho (報告/Report) means communicating progress and results to your supervisor. Ren (連絡/Inform) means sharing necessary information with relevant parties. So (相談/Consult) means seeking advice on matters requiring judgment. These three pillars form the foundation of email and report writing.

This guide systematically covers the basic structure of business emails, the keigo system and its proper application, situational email templates (requests, reports, apologies), technical report and progress report writing methods, and common mistakes with a practical checklist.

Basic Structure of Business Emails

Japanese business emails follow a strict prescribed format. Omitting any component or changing the order can give an impression of rudeness.

The 7 Essential Email Components

OrderComponentJapaneseDescription
1Subject件名(けんめい)Convey the purpose at a glance with category brackets
2Recipient宛名(あてな)Company + Department + Name + 様
3Greeting挨拶(あいさつ)External: お世話になっております / Internal: お疲れ様です
4Self-introduction名乗り(なのり)State your affiliation and name
5Body本文(ほんぶん)Conclusion-first (結論ファースト) principle
6Closing結び(むすび)よろしくお願いいたします, etc.
7Signature署名(しょめい)Company, department, name, contact info

Subject Line (件名) Writing Principles

The subject line should allow the reader to immediately grasp the purpose and urgency of the email. In Japan, it is standard practice to use square brackets to indicate the category.

-- Good Subject Examples --
【ご依頼】APIレビューのお願い(PR #1234)
  → [Request] API Review Request (PR #1234)
【ご報告】本番環境デプロイ完了のご連絡
  → [Report] Production Deployment Completion Notice
【ご相談】マイクロサービス移行スケジュールについて
  → [Consultation] Regarding Microservice Migration Schedule
【緊急】本番DBレプリケーション障害について
  → [Urgent] Production DB Replication Failure

-- Bad Subject Examples --
お疲れ様です          → Content is unclear
ご連絡                → No specificity at all
確認お願いします       → What needs to be confirmed is unclear

Greeting Expressions by Context

SituationGreetingNotes
External (clients, partners)いつもお世話になっておりますMost standard external greeting
External (first contact)初めてご連絡させていただきますUsed for first-time contact
Internal (general)お疲れ様ですDefault internal email greeting
Internal (morning)おはようございますSuitable for the first email of the morning
External (long time)ご無沙汰しておりますWhen resuming contact after a long gap
Emergency夜分遅くに失礼いたしますFor late-night urgent communications

Basic Email Template

件名:【カテゴリ】用件を簡潔に
Subject: [Category] Purpose stated concisely

○○株式会社
△△部 □□様

いつもお世話になっております。
(Thank you for your continued support.)
株式会社ABC 開発部のキムと申します。
(I am Kim from the Development Department of ABC Corp.)

本日は、~についてご連絡いたしました。
(I am writing to you today regarding ~.)

(本文:結論を先に、理由・詳細を後に記載)
(Body: State conclusion first, then reasons/details)

お忙しいところ恐れ入りますが、
(I apologize for troubling you during your busy schedule,)
ご確認のほどよろしくお願いいたします。
(I would appreciate your confirmation.)

--------------------
株式会社ABC 開発部
キム ヨンジュ
TEL: 03-XXXX-XXXX
Email: kim@abc-corp.co.jp
--------------------

The Keigo System and IT Workplace Application

Japanese honorific language (keigo/敬語) is divided into three main categories. In IT workplaces, you need to adjust the keigo level appropriately depending on whether the communication is internal or external, and whether the recipient is a superior or a colleague.

Keigo Three-Category Comparison

CategoryJapaneseFunctionBase FormKeigo FormIT Workplace Example
Respectful尊敬語(そんけいご)Elevates the other person's actions見るご覧になる資料をご覧になりましたか (Have you reviewed the document?)
Humble謙譲語(けんじょうご)Lowers your own actions見る拝見する資料を拝見しました (I have reviewed the document)
Polite丁寧語(ていねいご)Makes the overall sentence polite~だ~です/~ます問題ないです (There is no problem)

Common Keigo Conversions for IT Work

Base VerbRespectful (for others)Humble (for yourself)Usage Example
言う (say)おっしゃる申す/申し上げる部長がおっしゃった通り (As the manager said)
する (do)なさるいたすご確認いたします (I will confirm)
行く (go)いらっしゃる参る/伺う明日伺います (I will visit tomorrow)
知る (know)ご存じ存じる/存じ上げるご存じでしょうか (Are you aware?)
もらう (receive)-いただくご確認いただけますか (Could you confirm?)
思う (think)-存じる問題ないと存じます (I believe there is no problem)

Cushion Expressions (クッション言葉)

In Japanese business emails, it is customary to insert a softening expression before getting to the main point, showing consideration for the recipient.

JapaneseEnglishUsage Situation
お忙しいところ恐れ入りますがI apologize for troubling you during your busy scheduleBefore a request
お手数をおかけしますがI am sorry for the inconvenienceBefore requesting a task
差し支えなければIf it would not cause any troubleConditional requests
恐縮ですがI am sorry to imposeWhen imposing a burden
ご多忙中とは存じますがI understand you are very busyHighly formal requests
突然のご連絡で恐れ入りますがI apologize for the sudden contactUnannounced communications

Request Emails (依頼メール)

Request emails are the most frequently written type of email in IT work. They are used for code review requests, environment setup requests, schedule coordination, and more.

Key Principles for Request Emails

  1. Conclusion first: State what you are requesting in the first sentence
  2. Specify the deadline: Always include いつまでに (by when)
  3. Explain the background: Briefly explain why this request is needed
  4. Use cushion expressions: Insert consideration phrases before the main request

Code Review Request Email Example

件名:【ご依頼】認証モジュールコードレビューのお願い(PR #2847)
Subject: [Request] Authentication Module Code Review (PR #2847)

開発部 田中リーダー

お疲れ様です。開発2課のキムです。
(Hello. This is Kim from Development Team 2.)

認証モジュールのリファクタリングについて、
コードレビューをお願いしたくご連絡いたしました。
(I am writing to request a code review for the authentication module refactoring.)

■ 対象PR: #2847(認証フロー改善)
  Target PR: #2847 (Authentication flow improvement)
■ 変更概要:
  Change summary:
  - OAuth2.0認証フローの共通化
    (Standardization of OAuth2.0 authentication flow)
  - トークンリフレッシュロジックの修正
    (Token refresh logic fix)
  - ユニットテスト追加(カバレッジ85%→92%)
    (Added unit tests, coverage 85% to 92%)
■ レビュー期限: 3月15日(金)まで
  Review deadline: By Friday, March 15

お忙しいところ恐れ入りますが、
ご確認のほどよろしくお願いいたします。
(I apologize for troubling you during your busy schedule.
I would appreciate your review.)

Report Emails (報告メール)

Report emails communicate the progress or completion of tasks to supervisors or stakeholders. In Japan, late reporting is viewed very negatively.

Key Principles for Report Emails

  1. Conclusion first: State the result (success/failure/in-progress) first
  2. 5W1H: Clearly specify when, who, what, where, why, and how
  3. Include numbers: Provide specific figures and data wherever possible
  4. Next steps: Always include future action plans

Deployment Completion Report Email

件名:【ご報告】決済サービスv2 本番デプロイ完了
Subject: [Report] Payment Service v2 Production Deployment Complete

開発部 山田部長

お疲れ様です。開発2課のキムです。
決済サービスv2の本番デプロイが完了しましたのでご報告いたします。
(I am reporting that the production deployment of Payment Service v2
has been completed.)

■ デプロイ概要 (Deployment Overview)
  - 日時: 2026年3月13日 02:00~03:15(JST)
  - 対象: 決済サービスv2.1.0
  - 作業者: キム、佐藤

■ 結果: 正常完了 (Result: Completed Successfully)
  - 全ヘルスチェック: OK
  - レスポンスタイム: 平均120ms(目標150ms以下)
    (Response time: avg 120ms, target under 150ms)
  - エラー率: 0.01%(許容範囲内)
    (Error rate: 0.01%, within acceptable range)

■ 確認事項 (Confirmed Items)
  - ロールバック手順は確保済み
    (Rollback procedure is secured)
  - 24時間監視体制を継続中
    (24-hour monitoring continues)

■ 今後の対応 (Next Steps)
  - 3月14日: ピーク時間帯のパフォーマンス確認
  - 3月17日: 旧バージョンの完全廃止

以上、ご報告いたします。

Apology and Incident Report Emails (謝罪・障害報告メール)

When system incidents occur in IT, swift and accurate incident reporting is essential. Apology emails require particular care with keigo usage.

Key Principles for Incident Reports

  1. Report immediately: Send the first report as soon as possible after detecting the incident
  2. Specify impact scope: Which services and which users are affected
  3. Current status: Clearly state whether the issue is being addressed or has been resolved
  4. Root cause and countermeasures: Include root cause analysis and prevention measures (in the follow-up report)
  5. Sincere apology: Use specific, meaningful apology expressions

System Incident Initial Report

件名:【緊急・障害報告】決済APIタイムアウト発生中
Subject: [Urgent/Incident] Payment API Timeout in Progress

関係者各位
(To all concerned parties)

お疲れ様です。SREチームのキムです。
取り急ぎ、障害発生についてご報告いたします。
(This is Kim from the SRE team.
I am sending this urgent report regarding an incident.)

■ 障害概要 (Incident Overview)
  - 発生日時: 2026年3月13日 14:30(JST)
  - 事象: 決済API応答タイムアウト(30秒超過)
    (Payment API response timeout, exceeding 30 seconds)
  - 影響範囲: 全ユーザーの決済処理
    (Impact: All user payment processing)
  - 重要度: Critical

■ 現在の状況 (Current Status)
  - 原因調査中(DBコネクションプール枯渇の疑い)
    (Investigating cause; suspected DB connection pool exhaustion)
  - 暫定対応としてコネクション数を増加中
    (Increasing connection count as interim measure)

■ 今後の見通し (Outlook)
  - 15:30までに暫定復旧予定

多大なるご迷惑をおかけしておりますこと、
深くお詫び申し上げます。
(We sincerely apologize for the significant inconvenience.)

Apology Expression Formality Levels

FormalityExpressionWhen to Use
Standard申し訳ありませんGeneral internal apology
Formal申し訳ございませんTo internal superiors
High formal深くお詫び申し上げますTo external clients
Highest formal心よりお詫び申し上げますMajor incidents affecting clients
Written formal多大なるご迷惑をおかけし、誠に申し訳ございませんでしたOfficial incident reports

Technical Report Writing (技術報告書)

Technical reports require a more structured format than emails. Japanese IT companies use a consistent format and appropriate keigo even in technical reports.

Technical Report Basic Structure

【技術報告書】(Technical Report)

タイトル: マイクロサービスアーキテクチャ移行に関する技術報告
(Title: Technical Report on Microservice Architecture Migration)
作成日: 2026年3月13日
作成者: 開発2課 キム ヨンジュ
承認者: 開発部 山田部長

1. 目的 (Purpose)
   本報告書は、モノリシックアーキテクチャからマイクロサービスへの
   移行プロジェクトの技術的評価結果を報告するものである。
   (This report presents the technical evaluation results of the
   migration project from monolithic to microservice architecture.)

2. 背景 (Background)
   現行システムのスケーラビリティ課題に対応するため、
   2025年Q4よりアーキテクチャ移行を検討してきた。

3. 調査・検証内容 (Investigation and Verification)
   3.1 サービス分割方針の検討
       (Service decomposition strategy review)
   3.2 通信方式の比較検証
       (Communication method comparison: gRPC vs REST vs MQ)
   3.3 データ管理戦略
       (Data management strategy)

4. 検証結果 (Results)
   4.1 パフォーマンス
       - レスポンスタイム: 平均150ms → 80ms(47%改善)
       - スループット: 1,000rps → 3,500rps(250%改善)
   4.2 課題
       - 分散トランザクション管理の複雑性
       - サービス間通信のデバッグ困難

5. 結論と提言 (Conclusion and Recommendations)
   移行は技術的に実現可能と判断する。
   ただし、段階的移行(ストラングラーパターン)を推奨する。

以上

Common Expressions in Technical Reports

Japanese ExpressionEnglish MeaningUsage
~について報告するTo report on ~Stating report purpose
~と判断するTo conclude that ~Presenting conclusions
~を推奨するTo recommend ~Making recommendations
~の結果、~であったAs a result of ~, it was ~Describing test results
今後の課題としてAs a future challengeMentioning remaining issues
~を検討した結果As a result of examining ~Explaining analysis process
段階的に実施するTo implement in phasesDescribing plans

Progress Reports (進捗報告)

Weekly or daily progress reports are a crucial form of communication at Japanese IT companies. The key is clearly conveying the current status, completion rate, risks, and next actions.

Weekly Progress Report Template

件名:【週次報告】決済サービスv2 開発進捗(3月第2週)
Subject: [Weekly Report] Payment Service v2 Dev Progress (Week 2 of March)

開発部 山田部長

お疲れ様です。開発2課のキムです。
3月第2週の開発進捗をご報告いたします。
(I am reporting the development progress for the second week of March.)

■ 全体進捗: 68%(前週比 +12%)
  Overall Progress: 68% (+12% from previous week)

■ 今週の実績 (This Week's Achievements)
  1. 認証フローのリファクタリング完了
  2. 決済APIのユニットテスト作成
  3. ステージング環境での結合テスト着手

■ 各タスク進捗 (Task Progress)

  Task                        Status     Progress
  ──────────────────────────────────────────
  Auth flow improvement       Complete    100%
  Payment API development     In progress  85%
  Integration testing         In progress  30%
  Documentation               Not started   0%

■ 課題・リスク (Issues and Risks)
  - DB connection instability in integration test environment
    → Requested investigation from infra team (response by 3/14)

■ 来週の予定 (Next Week's Plan)
  1. Complete payment API development
  2. Execute and complete integration testing
  3. Begin documentation

■ 相談事項 (Consultation)
  リリース日を3月28日から3月31日に変更したく、
  ご相談させていただけますでしょうか。
  (I would like to discuss changing the release date
  from March 28 to March 31.)

以上、ご確認のほどよろしくお願いいたします。

Daily Standup Report Expressions

JapaneseEnglishContext
昨日はAPIの単体テストを実施しましたYesterday I ran the API unit testsWhat you did yesterday
本日は結合テストに着手する予定ですToday I plan to start integration testingWhat you will do today
現在ブロッカーはありませんThere are no blockers at the momentNo impediments
DB接続の問題でブロックされていますI am blocked by a DB connection issueReporting an impediment
予定通り進んでおりますThings are proceeding as plannedSmooth progress
少し遅れが出ておりますThere is a slight delayReporting delay

Common Mistakes and Improvements

Here are frequent mistakes that non-native engineers make in Japanese business emails and reports.

IncorrectCorrectExplanation
ご苦労様ですお疲れ様ですご苦労様 is only used by superiors toward subordinates
了解しました承知いたしました了解 is used between equals or toward subordinates
すみません申し訳ございませんすみません is too casual for business
参考になりました勉強になりました勉強になりました is appropriate toward superiors
なるほどですねおっしゃる通りですなるほど can be considered rude in business

Structural Mistakes

ProblemWrong ApproachCorrect ApproachExplanation
Conclusion at the endExplain details first, request lastState request first, details afterConclusion-first principle
Ambiguous subject確認しました (who confirmed?)田中さんにご確認いただきましたMake the subject clear
Double honorificsご覧になられましたかご覧になりましたかAvoid stacking respectful forms
Excessive humilityさせていただいてもよろしいでしょうかさせていただけますかOver-humbling is inefficient

Email and Report Writing Checklist

Email Checklist

  • Subject line clearly states the category and purpose
  • Recipient's company, department, and name are correct
  • Appropriate greeting expression used (internal vs. external)
  • Conclusion is positioned at the beginning of the body
  • Deadline is clearly stated
  • Cushion expressions are appropriately used
  • Keigo is correctly applied (no double honorifics)
  • Signature is included
  • If attachments were mentioned, they are actually attached
  • CC/BCC recipients are appropriate

Report Checklist

  • Report title accurately reflects the content
  • Date, author, and approver are stated
  • Purpose is clearly described
  • Facts and opinions are separated
  • Specific numbers and data are included
  • Conclusions and recommendations follow logically
  • Future schedule is included
  • No typos or keigo errors

References