📨 5か所で同じ記号が残っていた——送る側には完成品に見えて、受け取る側には壊れて届いていた

お弁当を渡す前に、フタを閉める手前で一度中を確認したとします。

「よし、きれいにできた」と思って、フタを閉めました。

でも受け取った側が開けたとき、中身が全部ずれていたら——。

確認した「自分の視点」と、届いた「相手の視点」は、ずれることがあります。

あなたは今こうなっていませんか？

• 自動化した仕組みが「動いている」ことは確認しているが、届いた側の見た目を確認していない
• 設定した日に自分の画面で確認して、それで終わりにしている
• 通知やメッセージの見た目を、受け取り側の環境でテストしていない
• 「エラーが出ていないなら問題ない」と判断している

先に結論を言います。

送り手の画面で完成に見えても、受け取り手の画面では壊れて表示されていることがあります。

私自身、5か所のSlack自動通知すべてが、3週間以上その状態で届き続けていました。

この記事では、私がどこでミスをしていたか、なぜ3週間気づかなかったか、そしてどう直したかを書きます。

通知は届いていた。でも、見出しは記号のままだった

自動化の仕組みを作ったきっかけ

Slackへの自動通知を作ったのは、手動で連絡を送る手間をなくすためでした。

「これが終わったら通知が欲しい」という場面が、少しずつ増えてきた時期があります。

作業のたびにSlackを開いて、文章を打って、送る。この繰り返しが地味に積み重なっていました。

なのでその動作を自動化しようと、仕組みを組み始めました。

最初は1つだけ作り、うまく動いたので少しずつ増やしていきました。

気づけば5か所になっていました。通知の見た目を整えたくて、見出しには太字を使いました。

設定の書き方は ＊見出しのテキスト＊ という形です。

Slackで太字にするときの一般的な書き方で、ごく普通の方法です。

最初に組んだ日、手元のパソコンで動作確認をしました。

見出しが太字に見えたので、「よし、完成」と判断しました。

そのまま本番で動かし始めました。確認はその1回で終わりにしていました。

受け取った側の画面で見たもの

数週間後、受け取り側のアカウントで通知を確認する機会がありました。そのとき初めて、現実を知りました。

見出しが太字ではなく、こうなっていました——「＊見出しのテキスト＊」。

アスタリスクが記号として残ったまま、文字に直接貼り付いて表示されていたのです。

太字にしたつもりが、記号が2つついた普通のテキストでした。「もしかして他の通知も？」

と思い、残り4か所を確認しました。

5か所すべて、同じ状態でした。

一番古いものは、設定してから3週間以上が経っていました。

つまり3週間以上、記号付きの見出しが届き続けていたことになります。

「完成した」と確信して動かし続けていたものが、ずっと壊れたままだったのです。

しばらく言葉が出ませんでした。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順

Slackの太字という仕組みを噛み砕いて説明します

「＊」で囲むと太字になる——という話の前提

Slackで文字を太字にするには、文字の前後に「＊」を1つずつ付けます。

これはマークダウンと呼ばれる記法の一部です。

難しいことを言っているように聞こえますが、要は「決まった記号で囲めば装飾が付く」というルールです。

＊見出し＊ と書けば太字で表示され、`コード` と書けばコード書式になります。

英語や半角の数字、半角スペースの隣にアスタリスクがある場合は、Slackが「太字の印」として正しく認識します。

問題は、日本語の全角文字が直接隣にある場合です。

ここで挙動が変わります。

全角文字とアスタリスクが隣り合うと、何が起きるか

Slackがアスタリスクを「太字の印だ」と判断するには、前後に「区切り」が必要です。

英字や数字、半角スペースなどがあれば、Slackはそこを自然な境界として読めます。

でも全角の日本語文字がアスタリスクに直接隣り合っている場合、Slackはその境界を見つけられません。

結果として「これは単なる記号だ」と判断し、アスタリスクをそのまま文字として表示します。

＊全角の文字＊ という入力が、＊全角の文字＊ としてそのまま画面に出てきます。

これは英語圏のツールが、日本語の文字体系を前提に設計されていないことで起きる問題です。

英語なら *Hello* と書けばきれいに太字になります。日本語では同じ感覚は通じません。

Slackを日常的に使っている方でも、この挙動を知らない方は多いと思います。

私も問題が起きるまでまったく知りませんでした。

設定画面のプレビューと実際の受信側が違うことがある

Slackの設定画面でメッセージを入力すると、リアルタイムでプレビューが表示されることがあります。

私がその日「完成した」と思ったのは、このプレビューの画面でした。

プレビューでは見出しが太字に表示されていました。なので正しく設定できたと判断しました。

でもSlackでは、設定画面のプレビューと実際の受信側で表示が異なる場合があります。

プレビューが「見やすいように補助してくれる表示機能」であり、受信側の実際の表示と一致しないことがあるのです。

この仕様を知らなかったことが、最初の確認で気づけなかった直接の原因の1つです。

設定したら必ず受け取り側のアカウントで実際に確認する——これが根本的な答えです。

なぜ3週間気づかなかったのか

送り手の画面では、ずっと太字に見えていた

設定した後も、私は通知を何度か確認していました。

でも確認していたのは、通知が「送られていること」でした。

受け取り側の画面で「どう表示されているか」は、1回も確認していませんでした。

送り手の画面で通知の内容を見ると、そこでは正しく太字が表示されていました。

「動いている」「見た目もきれい」という確認が、毎回そこで終わっていました。

受け取り側の画面に切り替えて確認するという発想が、完全に抜けていました。

「自分が作ったものだから問題ないはず」という感覚が、確認の精度を甘くしていたのだと思います。

誰も指摘してくれなかった理由

受け取る側から何も言ってこなかったことも、気づけなかった理由の1つです。

記号が付いた見出しは、確かに少し奇妙に見えたかもしれません。

でも通知の内容そのものは読めています。「届いていない」という状態ではないのです。

エラーが出ていない。内容は読める。

この2条件が揃っているとき、人は何かがおかしいと感じにくくなります。

受け取る側も「これはこういうものか」と思って流してしまうことがあります。

3週間という時間は、誰からの指摘もなく、自分も確認しなかった期間でした。

この問題は、受け取り側の画面を自分で見に行かない限り、永遠に気づかなかった可能性があります。

「エラーが出ていない」は「正しい」の証明ではない

エラーログには何も残っていませんでした。通知の配信記録も正常でした。

機能の観点では、何もおかしいことは起きていません。

でも品質の観点では、見出しが3週間ずっと壊れたままでした。

この2つは別の話です。機能が動いていることと、品質が保たれていることは、別に確認する必要があります。

自動化の仕組みを作ると、「動いているか」の確認は比較的簡単にできます。

でも「正しく届いているか」の確認は、意識して行わないとすっぽり抜けます。

この差が、3週間を作りました。

広告の現場でやっていたことを、自分のツールにはやっていなかった

受け手の環境で確認する、は当たり前の手順だった

以前、広告やWebコンテンツを作る仕事に関わっていたことがあります。

その環境では、「受け手の環境で確認する」は基本中の基本でした。

バナー広告を作れば、スマホでもPCでも確認しました。

メールを配信する前には、テスト送信して実際に届いた画面を見ることが必須でした。

ChromeとSafariで見え方が違う、スマホとPCでレイアウトが崩れる——こういうことが起きる前提で動いていました。

「作り手の画面でよく見える」だけでは品質チェックになりません。

「受け取る側の環境で正しく見える」まで確認して、初めて完成です。

その基準を、仕事を通じて当然のものとして身につけていました。

自分のツールには、同じ基準を使っていなかった

でも自分のために作る自動化ツールには、その基準を適用していませんでした。

「他人向けではなく自分向けだから」という気持ちが、どこかにあったのかもしれません。

設定した日に手元で確認して、「動いた」と判断して終わりにしていました。

受け取る側の画面で確認するという1ステップが、完全に抜けていたのです。

仕事で他者向けに作るものには品質基準を当てているのに、自分向けには省いていました。

これは正直に言って、迂闊な話でした（笑）。

「まさか自分のツールで、こんな初歩的なことが起きているわけがない」という思い込みが、確認の目を曇らせていました。

自動化するからこそ、最初の確認を丁寧にやる必要がある

自動化の仕組みは、一度作ると長期間動き続けます。設定した日から何週間、何か月と稼働するものです。

だからこそ、最初に正しく確認することが重要です。

間違った状態で1日動けば1日、1週間動けば1週間、ずっとその状態が続きます。

気づくのが遅れるほど、修正されるまでの期間が長くなります。

「自動化したから安心」ではなく「自動化したから最初の確認が大事」というのが正しい見方です。

手動の場合は毎回目で確認が入ります。自動化してしまうと、その確認の機会が消えます。

だからこそ意識した確認が必要になるのです。

5か所すべてに同じミスが入っていた理由

テンプレートをコピーして使い回していた

5か所の自動通知を作るとき、最初に作った1つのテンプレートをコピーして使いました。

同じような形式の通知が複数必要だったので、効率を優先してそうしました。

この方法自体は間違っていません。よく使われる合理的なやり方です。

ただ、元のテンプレートにミスが含まれている場合、コピーしたものすべてにそのミスが引き継がれます。

今回はまさにその状態で、アスタリスクと全角文字の問題が5か所すべてに伝播していました。

テンプレートの品質は、複製の回数に比例して影響が広がります。

テンプレートを複製するときは、元を十分に検証してから行う必要があります。

1か所気づいたとき、残りをまとめて確認する

今回、1か所で問題に気づいたとき、すぐに残り4か所を確認しました。

同じ構造を使っているものは、同じ問題を持っている可能性が高いからです。

修正は5か所まとめて行い、かかった時間は5分もかかりませんでした。

3週間以上気づかなかったのに、直すのは5分——この落差が、なんとも言えない気持ちになります。

早く気づいていれば、作ってから数日以内に直っていた問題です。

1か所の問題は、よく似た構造の他の場所にも潜んでいることがあります。

「ここだけ直す」ではなく「同じ構造を全部確認する」——この習慣が、同じミスを重ねない上で大切です。

構造を統一するリスクを理解する

複数の場所に同じ書き方を使っているとき、問題が横展開しやすい場面があります。

たとえば複数の自動メールに同じテンプレートを使っている場合などです。

複数の自動投稿に同じ文章フォーマットを使っている場合も同様です。

構造を統一すれば効率が上がる一方で、問題も統一されて広がるリスクがあります。

「1か所確認できたから全部OK」ではなく、「1か所に問題があったから全部確認」というルールを持っておくと安心です。

今回のような状態を早く発見できます。

「幅ゼロの空白」という1文字で直った話

幅ゼロの空白とは何か

修正に使ったのは「幅ゼロの空白」という特殊な文字です。

専門的にはゼロ幅スペース（Zero Width Space）と呼ばれ、Unicodeでは U+200B という番号が付いています。

動作はシンプルです。「画面には何も表示されないが、文字列の境界として機能する文字」です。

普通のスペース（半角スペース）は、画面に空白として表示されます。

幅ゼロの空白は、目には何も見えません。でもコンピュータ側には「ここに境界がある」という情報として伝わります。

Slackはこの境界を読み取って、アスタリスクを「太字の印」として認識します。

全角文字とアスタリスクの間にこの文字を1つ挟むことで、太字が正しく表示されるようになります。

この文字はキーボードから直接打てません。

専用のサイトや文字コード表からコピーするか、開発環境では \u200B として埋め込む方法があります。

実際にどう直したか

修正の手順はシンプルでした。まず、幅ゼロの空白の文字を手元にコピーできる状態にしておきます。

次に、全角文字とアスタリスクが直接隣り合っている箇所を探します。

今回のケースでは ＊見出しのテキスト＊ という形が問題でした。

アスタリスクと全角文字の間、それぞれに幅ゼロの空白を1文字ずつ入れます。

人の目には何も変わりませんが、コンピュータにはアスタリスクの前後に境界があると伝わります。

修正後、受け取り側のアカウントで実際に確認しました。ちゃんと太字になっていました。

今回は、修正した後に必ず受け取り側の画面で確認してから「完成」にしました。

当たり前のことを、ようやく当たり前にやれた——そんな感覚でした。

幅ゼロの空白を使うときの注意点

この解決策を使う上で、1つだけ気をつけることがあります。

幅ゼロの空白は画面に見えないので、「入れたつもりだけど入っていない」という状態が起きやすいです。

また、コピーした文字を間違えて通常のスペースにしてしまうと、見出しの前後に不自然な空白ができます。

修正後は必ず、受け取り側の画面で実際に表示を確認してください。

見た目が変わっていなければ、幅ゼロの空白が正しく入っていない可能性があります。

逆に余分なスペースがあれば、通常のスペースが混入しています。

修正の後に確認する——この習慣が、今回の教訓の中でいちばん大切なことです。

自動化した後こそ、受け取り側の画面を見に行く

「動いている」と「正しく届いている」は別の話

自動化の仕組みが「動いている」ことと、「正しく届いている」ことは、別のことです。エラーが出ていない。

通知が届いた。誰からも指摘がない。

この3つが揃っていても、品質が保たれているとは言えません。

機能は問題なく動いていても、品質は壊れたままということがあります。

今回の3週間は、まさにその状態でした。動いていて、届いていて、指摘もなかった——でも壊れていました。

自動化した仕組みこそ、定期的に受け取り側の目で確認することが必要です。

手動で送る場合は、毎回自分の目を通します。送った後に不自然な見た目があれば、その場で気づけます。

でも自動化すると、その確認の機会が消えます。

意識して確認しに行かない限り、問題は静かに積み重なります。

確認する習慣を持つための具体的な方法

受け取り側の確認を習慣にするための方法を、いくつか紹介します。

まず、仕組みを作った直後に、受け取り側のアカウントまたは別のデバイスで実際に確認します。

設定画面のプレビューではなく、実際に届いたものを開いて確認することが大切です。

次に、週に1回など定期的なタイミングで、主要な自動通知の受け取り側表示を確認します。

特に日本語を含む書式付きのテキストは、定期確認の対象に入れておくと安心です。

また、大きな変更を加えたとき——テンプレートを更新したときや設定を移行したとき——は必ず受け取り側で確認します。

変更前に動いていたものが、変更後も同じように動いているとは限りません。

今日できる1つのこと

もし自動通知やメッセージの仕組みを設定しているなら、今日1回、受け取り側の画面を確認してみてください。

設定してから数週間以上経っているなら、特に確認する価値があります。

確認の手順はシンプルです。受け取り側のアカウントまたはデバイスで、実際に届いた通知を開きます。

送り手の画面ではなく、受け取り手の画面で見たとき、意図通りに表示されているかを確認します。

記号が残っていたり、見た目がおかしかったりしたら、そこが改善できるポイントです。

私が5か所で3週間以上気づかなかったのは、この確認を1度もしていなかったからです。

今日1回確認するだけで、同じ状態を早めに発見できます。

送る側には完成品に見えていても、受け取る側には壊れて届いていることがあります。

その差を埋めるのは、受け取り側の目で確認するという、シンプルな1歩です。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順