エンジニアのためのSlack/Teamsテキスト術｜要点が1秒で伝わるログ・メンション作法

こんにちは、もっちです。

「チャットで急ぎの障害報告や質問を送ったのに、返信が遅くて作業が進まない……」
「ログを貼り付けて相談したら、先輩から『何が言いたいのか見づらい』と怒られてしまった……」

SlackやMicrosoft Teamsが現場のインフラとなった今、このような悩みを抱える若手・中堅エンジニアは非常に多いです。

メールのマナーは研修で教わることがあっても、「チャットツール特有のテキスト作法」を体系的に教わる機会はほぼありません。

そのため、メールのような長い時候の挨拶を書いてしまったり、逆に数十行のシステムログをプレーンテキストでベタ貼りして画面を埋め尽くしてしまったりする「チャット事故」が後を絶ちません。

チャットの真の目的は「非同期コミュニケーションの速度最大化」です。

相手が画面を開いた「最初の1秒」で要点と次のアクションを瞬時に理解させる書き方ができると、自分自身の作業スピードはもちろん、チームからの信頼も劇的に上がります。

今回は、インフラ現場の最前線で即実践できる「要点が1秒で伝わるチャットテキスト術」を徹底解説します。

なぜエンジニアのチャットは「1秒」で伝わる必要があるのか？

チャットの流速とシニアエンジニアの「割り込みコスト」

チャットはメールと異なり、複数のプロジェクトや障害対応チャンネルが常に猛スピードで流れています。

特に判断権限を持つリーダーやシニアエンジニアは、1日に何十、何百件ものメンションを受け取っています。そんな中、スクロールしないと要点が見えない長文や、何をしてほしいのか分からないメッセージが届くとどうなるでしょうか？

「読むのにエネルギーがいるから、後で手が空いた時に見よう」と判断され、あなたの依頼は後回しにされます。

また、メンションを送る行為は、相手の現在の集中を中断させる「割り込み」です。

相手の認知的負荷（コンテキストスイッチのコスト）を最小化する配慮こそが、結果として自分の仕事の完了速度を早める最短ルートになります。

チャットテキストの3原則

チャットでテキストを送信する際は、常に以下の3原則を意識してください。

1. 先頭に結論とアクション（「報告なのか」「確認なのか」「緊急対応なのか」）
2. スキャンできる構造（箇条書き・ラベル・太字で、流し読みでも頭に入る）
3. 1画面（スクロール不要）に収める（詳細なログや補足情報はスレッドへ逃がす）

【基本構文】一目で状況を伝える「冒頭ブラケット×箇条書き」

冒頭ブラケット（【】）で「通知バナー」の時点でアクションを促す

メッセージの1行目には、必ず【】（隅付き括弧）で要件の種別を明記します。

PCの右下やスマートフォンの通知バナーには冒頭の20〜30文字程度しか表示されません。この冒頭にタグがあるだけで、相手は開くべきかどうかの優先度を0.5秒で判断できます。

タグ	意味と使い分け	相手に求めるアクション
【至急】	サービス障害、セキュリティ検知など	即座にメッセージを開いて確認・判断してほしい
【依頼】	レビュー、設定作業、承認など	期限までに手を動かしてほしい（期限必須）
【相談】	設計判断、エラーの切り分け方針など	アドバイスや方向性の指示がほしい
【報告】	定期メンテナンス完了、進捗連絡	内容を認知してほしい（返信はリアクションスタンプでOK）
【確認】	設定値のダブルチェック、仕様の確認	事実関係の合否を回答してほしい
【共有】	ナレッジ共有、参考情報の展開	参考情報として目を通してほしい（返信不要）

箇条書きは「項目名（ラベル）＋値」にする

箇条書きを使う際、単に「・」で文章を書き連ねるだけでは不十分です。視線が流れても要点が飛び込んでくるよう、「【ラベル】：内容」の形式で構造化しましょう。

❌ Bad例（読むのに労力がかかり、後回しにされる）

お疲れ様です。先ほどステージング環境のWebサーバーをメンテナンス手順書に沿って再起動したのですが、DBからの応答が返ってこなくなってしまっていて疎通が取れません。現在原因を調査中ですが、本日夕方の結合テストに影響が出る可能性があるので、一旦15時までに復旧するか判断したいです。確認いただけますでしょうか。

⭕ Good例（1秒で状況と求められるアクションが把握できる）

【相談】ステージングWebサーバー再起動後のDB疎通エラーについて

@佐藤さん

ステージングWeb再起動後、DBへの接続エラーが発生しています。切り戻し判断のご相談です。

・【事象】：Web01からDB01への疎通不可（Error: Connection refused）

・【影響】：本日16:00開始予定の結合テストに遅延リスクあり

・【現状】：DB側のリスナーステータスを確認中（10分以内に判明予定）

・【相談事項】：15:00時点で解消しない場合、スナップショットから切り戻してよいか

お手すきの際にスレッドにて方針をご指示いただけますでしょうか。

Good例のようにラベル化されていれば、リーダーは移動中のスマホ画面でも「15:00に切り戻しの可否をジャッジすればいいんだな」と瞬時に理解できます。

【画面テロ防止】Slack/Teamsでのログ・コード貼り付け作法

インフラエンジニアのチャットで最も周囲に嫌がられるのが、「ログのベタ貼り（スクロールテロ）」です。

なぜプレーンテキストのログベタ貼りはNGなのか？

ターミナルの出力やエラーログ（/var/log/messages や catalina.out など）を装飾なしでそのまま貼り付けると、現場では以下のトラブルが起きます。

• タイムラインの破壊：数十行〜数百行のログで画面が埋まり、前後の会話やアラート通知がすべて吹き飛ぶ
• 可読性の崩壊：プロポーショナルフォント（可変幅フォント）で表示され、スペースやインデント、桁がずれてエラー箇所が読めない
• モバイル閲覧者の悲劇：休日や移動中にオンコール対応しているシニアが、スマホ画面を延々と親指でスクロールさせられる

コードブロックとスニペットの使い分けルール

ログやコマンドを貼る際は、行数や用途に応じてツールごとの機能を厳密に使い分けます。

【ログ貼り付けの使い分け基準】
・1〜2行のコマンド/パラメータ名 → インラインコード（ `コマンド` ）
・3〜10行のエラー抜粋/設定差分   → コードブロック（ ``` で囲む）
・数十行以上のログ/設定ファイル全体 → スニペット作成 または ファイル添付（スレッド内）

1. Slackの場合

• インラインコード：バッククォート1つ（ ` ）で囲む（例：systemctl restart nginx）。
• コードブロック：バッククォート3つ（ “` ）で囲む。
• スニペット機能：メッセージ入力欄の「＋」アイコンから「コードまたはテキストのスニペットを作成」を選択。折りたたまれて表示され、シンタックスハイライトも適用されます。

2. Teamsの場合

• インラインコード：バッククォート1つ（ ` ）で囲む。
• コードスニペット：メッセージ下の書式バーにある「コード（</>）」をクリックし、言語を選択して貼り付ける。

現場の鉄則：

親メッセージには「エラーの核心部分（3〜5行程度）」だけをコードブロックで載せ、完全なログファイルは「親メッセージのスレッド（返信）にスニペットまたは.logファイルとして添付する」のが最もスマートな作法です。

ログ共有時の「3大必須セット」

「エラーが出ました。どうすればいいですか？」とログだけを放り投げるのはNGです。ログを共有するときは、必ず次の3要素を添えてください。

1. 実行したコマンドと発生時刻（例：本日14:30に /usr/local/bin/deploy.sh を手動実行）
2. 該当のエラー箇所（どこを見るべきか）（例：ログ末尾の Connection refused 付近）
3. 想定していた期待値と現在の仮説（例：本来はコンテナが起動する想定。ポート80が別プロセスに掴まれていると推測）

【通知疲れを防ぐ】@channel・個人メンションの適切な使い分け

メンション（通知）の飛ばし方一つで、相手に与えるストレスと返信速度は劇的に変わります。

全体メンション（@channel / @here）の狼少年化リスク

Slackの @channel や @here、Teamsの @team や @channel などの全体メンションは、そのチャンネルにいる全員の作業を強制中断させます。

これが日常的な業務連絡や低レベルのアラートで頻発すると、メンバーは「通知麻痺（どうせ自分には関係ない）」を起こし、本当に重要な緊急連絡すら読まれなくなります。

全体メンションは、サービス全面停止などの「重大インシデント」や「全社的な緊急告知」以外では原則封印しましょう。

誰がボールを持つかを一瞬で示す「主担当」と「cc」の明記術

関係者が複数人いる場合、全員にメンションを付けると「誰がボールを持っているのか（誰が返信・対応すべきなのか）」が曖昧になり、お見合い状態になって放置されます。

チャットでもメールのように「主担当」と「cc」を明確に書き分けるのが有効です。

@鈴木さん（作業対応のご相談）
cc: @田中さん @佐藤さん（情報共有のみ・確認任意です）

【依頼】ファイアウォール設定変更に伴う疎通確認
...

このように冒頭に役割を添えるだけで、メンションされた鈴木さんは「自分が対応すべきタスクだ」と即座に理解でき、ccのメンバーは「目を通すだけでOK」と判断できます。

時間外・休日のメンション配慮

インフラ業務では夜間作業や休日待機がありますが、通常勤務のメンバーに対して時間外にメンションを飛ばす際はマナーが必要です。

• 送信予約機能を活用する：SlackやTeamsの「送信スケジュール（送信予約）」機能を使い、翌営業日の始業時刻（9:00など）に届くようセットする。
• 即時送信が必要な場合の免責文：
  • ※業務時間外のため、返信は翌営業日で構いません。
  • ※緊急対応ではないため、月曜日の朝にご確認ください。といった一文をメッセージの冒頭に添えておくのが、現場で信頼される大人の作法です。

【コピペで即実践】インフラ現場向けシチュエーション別テンプレート

明日からそのまま現場で使える実用テンプレートをまとめました。用途に合わせてコピー＆ペーストしてご活用ください。

テンプレート1：【至急】障害・アラート一次報告（エスカレーション）

【至急確認】Web01 サーバーHTTP応答遅延の件
@infra-lead
cc: @oncall-members

Web01にてHTTPレスポンス遅延のアラートを検知しました。一次切り分けの確認と対応方針のご指示をお願いします。

・【検知時刻】：14:15頃
・【対象機器】：Webサーバー01（10.20.1.11）
・【影響範囲】：会員マイページへのアクセスが一部タイムアウト（504 Gateway Timeout）
・【暫定処置】：ロードバランサーからWeb01を一時切り離し済み（Web02単系でサービス継続中）
・【エラーログ抜粋】：
2026/10/21 14:15:22 [error] 1024 worker_connections are not enough while connecting to upstream

・【次のアクション案】：worker_connectionsのパラメータ引き上げとNginx再起動を実施して良いかご判断をお願いします。
※詳細ログおよびリソース監視グラフはスレッドに添付します。

テンプレート2：【依頼】スクリプト・設定変更のレビュー依頼

【依頼】日次バックアップ用Bashスクリプトのコードレビュー
@山田さん
cc: @鈴木さん（参考共有）

日次バックアップ自動化スクリプトの改修が完了しました。
ステージング環境での動作検証が完了しましたので、コードレビューをお願いいたします。

・【対象PR/ファイル】：[GitLab/GitHubへのリンクURL]
・【修正内容】：S3アップロード失敗時のリトライ処理（最大3回）の追加
・【確認観点】：エラーハンドリングの記述およびログ出力レベルの妥当性
・【希望期日】：10/23(金) 15:00まで

ご不明点や修正点があれば本スレッドにてご指摘ください。よろしくお願いいたします。

テンプレート3：【相談】技術トラブル・原因調査の相談（スレッド運用の徹底）

【相談】Ansibleによるパッケージ更新タスク停止のエラーについて
@高橋さん

お疲れ様です。Ansibleプレイブックの挙動についてご相談させてください。

・【背景】：検証環境のRHELパッケージ一括更新プレイブックを実行中
・【困っていること】：特定のタスク（yum update）で処理がハングアップする
・【試したこと】：
 1. 対象サーバーで手動の yum update を実行 → 正常終了
 2. ansible.cfg の timeout 値を300秒に延長 → 変化なし
・【ご相談内容】：ansible_become 周りの権限昇格設定に問題がないかアドバイスをいただきたいです

※実行コマンドおよびプレイブックの差分内容は本スレッドに記載します。

まとめ：チャットの読みやすさは「エンジニアの信頼」そのもの

チャットコミュニケーションにおいて重要なのは、過度にかしこまった敬語を使うことではありません。

「相手の読解コストを最小化し、チーム全体の作業速度を最大化すること」です。

1. 冒頭の【】タグでメッセージの目的を瞬時に伝える
2. ラベル付きの箇条書きで情報を構造化する
3. ログはベタ貼りせず、要約抜粋＋スレッド添付で画面を汚さない
4. メンションは主担当とccを明確にしてボールを曖昧にしない

この4つを意識するだけで、チャット越しのやり取りは見違えるほどスムーズになり、周囲からのレビューや指示出しのスピードも劇的に向上します。

テキストで要点を整理して伝える力は、チャットだけでなく「障害報告書」「パラメータシート」「運用設計書」などのドキュメント作成能力にも直結します。

実務でそのまま使えるインフラ設計書や運用手順書のテンプレート・書き方の型については、以下の関連記事でも詳しく紹介していますので、ぜひあわせて参考にしてみてください。