EmDashの日本語編集と予約公開｜実画面で確認した注意点

こんにちは。Osukeラーニング、運営者の「osuke」です。

EmDashで日本語の記事を書き、予約した時刻に公開できるか。既存の本人限定リモートサイトで、ダミー原稿を使って確認しました。日本語の保存・手動公開・修正公開は確認できました。初回の予約試験は未実行でしたが、その後Cron未設定を確認し、一時追加した再検証では手動公開なしで管理画面の公開状態への切替を確認しました。再認証後には閲覧側のタイトルと本文も照合しました。さらに、Cronの実行確認後に未来の21時05分へ予約した追加試験では、指定した分のうちに本文へ切り替わることを確認しています。秒単位で時刻ぴったりに公開される保証とは区別しています。

2026年11月8日のEmDash v1.3.1で見た実画面を載せ、確認できた操作と未検証の条件を記録します。スクリーンショットは個人情報を含む周辺を撮影範囲から外しています。

記事のポイント

• 日本語入力と画面・コンテンツ言語の違い
• 下書き保存と公開後の変更の反映
• 日本時間の予約登録と時刻後の確認結果
• 原稿担当・公開担当・掲載画像の確認票

EmDashの日本語編集で確認したこと

最初に検証条件と、保存・公開で見えた画面を確認します。

管理画面は日本語と英語が混在する

管理画面を開いて最初に確認したのは、普段の記事更新で使う言葉です。今回のEmDash v1.3.1では、「保存」「予約公開」「メディア」などは日本語で表示される一方、「Title」「Content」「Publish now」などは英語でした。メニューが日本語だからといって、すべての確認画面も日本語になるとは限りません。

日本語で原稿を書きたい人は、文字を入力できることと、操作の意味を読み取れることを別に確認すると判断しやすくなります。例えば保存しただけで読者向けの表示が変わるのか、確認ダイアログの「Publish changes」が何を実行するのかは、ボタンの見た目だけでは把握しづらいところです。今回の試験では、一つずつ操作して、画面の状態と閲覧ページを見比べました。

初回試験で作成したのは「日本語編集と予約公開の検証」というダミー原稿1件です。Cloudflare上に以前作った本人限定のサイトを使い、既存の管理者で操作しました。日常の原稿や顧客情報を入れずに試したため、入力した内容をそのまま掲載例に使えます。記事で示すスクリーンショットは、メールアドレスやアカウント欄を撮影範囲から外しています。

運用を引き継ぐ場合は、英語の操作名に日本語の意味を添えたメモがあると便利です。今回ならSave相当の「保存」、Publish nowの「今すぐ公開」、Publish changesの「変更を公開」、Remove scheduleの「予約を解除」を並べます。表示名を暗記するより、実行前と実行後にどの状態を確認するかを書いておきます。

この結果は、今回の版と構成で見えた画面の記録です。現在の公式資料と画面が異なる場合は、導入済みの版を確かめてから読み替えてください。管理画面の言語を変える設定は今回変更していません。日本語だけで迷わず操作できるかは、担当者が使う機能でも確認する余地があります。

日本語本文とコンテンツ言語は別に扱う

本文を日本語で入力できることと、サイトのコンテンツ言語の設定は別の話です。今回のダミー原稿では、日本語のタイトルと本文を保存した後も、右側のContent language欄は「English EN」でした。その表示を日本語に変更せず、保存と公開の動作を確認しています。

一方、閲覧ページには日本語本文が表示されましたが、公開日の表示は「November 8, 2026」でした。本文の言語、管理画面の言語、日付などテーマ側の表示を分けて確かめると、「日本語で書けたので日本語サイトの準備が全部整った」と判断するのを避けられます。今回の画像で見える英語の表示も、その違いを示しています。

公式のi18nガイドは、翻訳された記事を言語ごとのコンテンツとして扱う仕組みを説明しています。管理画面の表示が日本語になることや、本文を日本語で書くことと、その仕組みの設定はそれぞれ確認が必要です。今回の検証では多言語の設定、言語別URL、翻訳記事の追加を実施していません。

例えば日本語だけのブログなら、まず記事の本文と日付、ナビゲーションなど、読者に見える箇所を確認します。英語版も公開する予定があるなら、元の記事と翻訳記事がどのように結び付くか、各言語で公開状態が独立しているかも確認項目になります。公式の説明を読んだだけで、手元のテーマや設定が対応済みと扱わないようにします。

原稿担当者には、Content language欄をどう扱うかも運営側から伝えます。どの値を選ぶかをその場の推測に任せると、本文の言語と違うメタ情報を付ける可能性があります。設定が未確定なら変更前に管理者へ確認し、今回のようなダミー記事で閲覧結果を比べると、直すべき項目を挙げられます。

参照資料はEmDash公式のi18nガイドです。

下書きを保存して再表示する

ダミー原稿には、日本語タイトル、本文3段落、抜粋を入力しました。本文には句読点の「、。」と、括弧の「（テスト）」を含めています。保存後に記事の編集画面へ移り、同じ文字と段落が残っていることを確認しました。スラッグは識別しやすい英字にしています。

入力中にはタイトルから生成されたスラッグに文字が追加されてしまったため、保存前に識別名の欄を見直して置き換えました。今回の観測から分かるのは、タイトルだけを入力して後は任せるより、保存前にURLの一部も見る必要があるということです。日本語スラッグ自体の可否や、別の入力方法で同じことが起きるかは試していません。

保存後は右側にDraft versionと、サイトには表示されない旨の説明が出ました。ここで確かめるのは、本文が残っていることと、公開されていないことの二つです。文章が保存されたように見えても、別の画面へ移って戻ると未保存だったという事態を見分けるため、操作後の画面表示も記録します。

実務で最初に試す原稿は、秘密を含まない短い文章にすると確認しやすくなります。例えば「これは検証専用の原稿です」と書いた上で、改行、句読点、リンクなど、日常的に使う要素を少しずつ入れます。一度に長い記事や大量の画像を移すと、どの操作で問題が起きたかを追う工数が増えます。

今回確認したのは短い文章と抜粋です。縦書き、ルビ、長い表、特殊な装飾、大量画像などの表示は確認していません。普段使う書式がある場合は、その書式を含む小さな原稿で別途確認します。スクリーンショットにも確認対象を明記しておくと、後から見た人が未検証の機能まで使えると思い込まずに済みます。

予約画面で日本時間を確認する

予約公開は、保存済みの原稿から「予約公開」を開いて試しました。表示されたダイアログではカレンダーで日付を選び、HourとMinuteの欄へ時刻を入れられます。下部にはAsia/Tokyo（JST）と明示されていました。今回は2026年11月8日18時37分を指定しています。

入力した日時はダイアログだけでなく、保存後の画面でも確認しました。公開欄にはFirst publicationと「Scheduled for 2026/11/08 18:37（JST）」が表示され、Change scheduleとRemove scheduleも出ています。予約の登録を確かめるときは、入力欄から離れた後にも同じ日時が見えるかを見ます。

タイムゾーンが表示されていても、担当者同士で予定を伝えるときは日付と時刻を省略しない方が確実です。「今夜」「朝9時」だけでは、別の日に引き継いだり、異なる地域から作業したりすると解釈がずれます。予定表には年月日、時分、Asia/Tokyoのようなタイムゾーン名を一緒に書きます。

予約する直前には、原稿が確定しているかも見直します。例えばイベント案内なら、開始時刻や会場が未確定のまま本文だけ保存されていることがあります。予約時刻の入力は、その内容を読者に見せる判断でもあるため、原稿の確認担当と時刻の確認担当を決めておきます。一人で運営するときも、二つの確認欄を別に残せます。

今回の表示だけから、ほかの端末やサイトでも同じタイムゾーンになるとは言えません。担当者が実際に使う画面で表示を見てください。希望する地域と違う場合は、設定を推測で変更する前に、現在の構成や担当範囲を確認します。予約ボタンを押した後に日時を読み直す手順を、普段の公開前チェックにも入れられます。

予約状態と閲覧ページを照合する

予約を保存できても、それだけでは自動公開が動いたことは分かりません。今回の検証では、予約時刻前に閲覧ページの一覧を開き、以前の記事1本だけが出ていることを確認しました。次に指定時刻を過ぎてから一覧を再読み込みし、ダミー記事が現れるかを見ています。

結果は、指定時刻を過ぎても一覧にダミー記事が出ず、管理画面にも予約日時が残っていました。その後18時39分の手動公開へ進む前まで、自動公開の成功を確認できませんでした。途中に操作の中断もあり、指定した秒に到達したかを精密に測った試験ではありません。この環境の予約結果として、その観測範囲を記録します。

追加調査で、検証用WorkerにCron Triggerが設定されていないことを確認しました。初回構築記録にもCronを無効化した記載がありました。一方、配置済みコードにはscheduledハンドラが接続されていたため、コードを変更せず、検証中だけ毎分実行のCronを1件追加しています。公式ガイドが必要とする実行設定が初回試験では欠けていた、というのが確認できた構成上の原因です。

同日夜の再検証では、保存済みのダミー記事を19時14分JSTに予約し、Cronを19時23〜24分頃に確定保存しました。手動の公開ボタンは押さず、19時32分に管理画面が「Live version」へ切り替わったことを確認しています。表示されたPublication dateは19時14分のままでしたが、これは予定日時であり、実際に19時14分に公開されたという意味ではありません。その後、Accessの本人再認証を終えた20時47分に、閲覧ページにも同じダミー記事のタイトルと本文が表示されることを照合しました。管理画面も公開状態のままで、予約表示は残っていません。この回ではCronの詳細な実行ログは取得できませんでした。また、Cron保存より前の日時を予約した試験だったため、未来の予定時刻で動くかは次の追加試験で確認しました。

Cron反映後の未来予約を検証

予定時刻の動作を切り分けるため、同じダミー記事を下書きへ戻し、毎分実行のCronを一時的に設定しました。今回は保存表示だけで判断せず、リアルタイムログに20時59分20秒・21時00分20秒のCron実行が「Ok」で記録されたことを確認してから、未来の21時05分JSTへ予約しています。21時01分には管理画面でScheduled for 21:05を確認でき、予約までの間に手動の公開操作は行っていません。

閲覧ページは21時04分57秒までの確認で未表示でした。指定時刻を過ぎた21時05分12秒の確認でもPage not foundでしたが、21時05分28〜29秒の再読み込みではダミーのタイトルと本文が表示されました。したがって、今回の単発試験では「指定した21時05分の分に公開された」と判断できます。一方、21時05分00秒ちょうどの表示を確認した結果ではありません。

Cloudflareのログでは、21時05分20秒のCron実行がOkとなり、同じ実行から「Published 1 scheduled item(s)」も取得できました。このメッセージの記録時刻は21時05分34秒でしたが、本文はそれより前の確認で見えていました。処理完了のログ時刻を、そのままデータベース上の公開時刻と読み替えないことが大切です。秒単位の正確な公開時刻は今回の画面観測だけでは確定できません。

検証終了後は、このCronを削除して変更を確定保存し、再読み込み後にも未設定であることを確認しました。今回の再検証ではコードの変更・再配置は行っていません。無料Workersプランを維持し、R2の利用画面でも確認時点で課金使用量なしと表示されていました。表示の反映には遅れがあり得るため、将来の費用まで保証するものではありません。現在はCronがないため、この検証サイトへ新たに予約しても、定期実行による自動公開は継続しません。

公開が確認できないときは、同じ記事を作り直す前に、管理画面で予約が残っているか、閲覧側に別の記事ができていないかを確認します。複数の記事を作ると、どれが本来の原稿かを見分けにくくなります。今回は同じダミー原稿を使い、予約を解除してから手動公開の検証を続けました。

運用で予約を使いたい人は、本番の告知を預ける前に、保護された検証場所で実際の切替まで確認する必要があります。登録済みの表示と、閲覧ページに出た結果を別々に記録し、公開が遅れたときの連絡先と対応担当も決めます。今回の成功した手動公開を、自動公開の成功として読み替えないよう注意してください。

参照資料はEmDash公式のCloudflare配置・予約公開の説明です。

EmDashの予約公開を運用する確認票

予定と実際の結果を照合し、普段の記事更新で使える確認票にまとめます。

予約した日時と結果を記録する

今回の記録を振り返ると、予約の登録、時刻後の状態、予約解除、手動公開という四つの段階があります。まず18時37分JSTの予約を保存し、指定時刻後も予約が残っていることを確認しました。その後Remove scheduleを実行し、Draft versionと「予約なし」の表示を確かめています。

予約を外した後はPublish nowを選び、確認ダイアログでも公開操作を確定しました。公開済みの通知が出て、閲覧ページの一覧にダミー記事へのリンクが追加されています。そのリンクから開くと、日本語のタイトル、抜粋、本文3段落が表示されました。管理画面の初公開日時は18時39分でした。

記録するときは、予定した日時と実際に見た日時を同じ欄にまとめないようにします。今回の例で「18時37分公開」とだけ書くと、自動公開したように読めてしまいます。予定時刻は18時37分、確認結果は自動公開未確認、手動公開の表示は18時39分、と並べれば、次に調べるべき工程も分かります。

ダミー原稿を使っても、後に予約が残らないようにします。問題の調査中に原稿が遅れて公開されると、確認済みの状態が変わるためです。今回は予約解除の結果を確認してから次の操作へ進みました。もし解除操作の結果が分からなければ、先に画面を読み直し、状態が確認できるまで別の公開操作を重ねないようにします。

運用票には原稿を特定する情報、予定日時、確認日時、閲覧結果、最後に行った操作を書きます。さらに、確認していない設定やログも未確認欄に残すと、担当が替わっても調査の続きを判断できます。失敗の原因を埋めるために推測を書くより、どこまで観測したかを揃える方が次の作業につながります。

公開後の下書き変更を確認する

手動公開した後、本文に「公開後の追記確認用の一文です。」という段落を追加して保存しました。管理画面にはLive versionに加えてDraft changesが表示され、読者には公開済みの版が見えるという説明が出ました。この状態で閲覧ページを再読み込みすると、追加した一文はまだ出ていませんでした。

次にPublish changesを選び、確認ダイアログで変更の公開を確定しました。公開済みの通知を確認してから閲覧ページを再読み込みすると、追記した日本語の段落が現れました。今回の原稿では、保存と公開の間に確認の区切りを置けることを、編集画面と閲覧画面の両方で観測できました。

この動きを知っておくと、公開中の記事を修正するときの判断がしやすくなります。例えば価格や開催日を直す場合、保存できたという通知だけを見て作業を終えると、閲覧者には古い内容が見え続ける可能性があります。修正後に誰が公開するかを決め、最後に閲覧ページで該当箇所を見る手順を加えます。

逆に、確認前の変更をすぐ見せたくない場合は、公開操作を誰が判断するかが重要です。下書きの状態を見ながら原稿を確認し、変更点が確定したら公開します。今回のテストは管理者1名で行ったため、別の役割に同じボタンが見えるかや、別の担当者が承認した場合の運用は確認していません。

公式のContent Lifecycleでは、リビジョン対応の有無による動作条件も説明されています。今回見えた保存と公開の区切りを、すべてのコレクションやカスタム構成へ一律に当てはめず、自サイトの対象コンテンツで確かめてください。今回の画面写真には、下書き変更の表示と、公開後に追記が見える状態をそれぞれ載せています。

参照資料はEmDash公式のContent Lifecycleです。

役割と所有者の条件を分けて考える

人に原稿を任せるときは、入力できることに加えて、どの記事を編集し、どこまで公開できるかを確認します。現行の管理画面ガイドでは、Authorは自分の記事、Editorは他の人の記事も含めて編集・公開できるという所有関係の違いが説明されています。Adminには設定やユーザーなどの管理操作も含まれます。

今回の実機検証は、すでに登録してある管理者1名で行いました。追加のユーザー招待や役割の変更はしていません。したがって、Contributorで公開できなかった、Editorなら他人の記事を変更できた、といった役割別の実測結果はありません。記事で示せるのは、公式の役割説明と、今回管理者で見えた画面までです。

引継ぎでは、「原稿を直す担当」「内容を確認する担当」「読者に公開する担当」を作業票に記入します。例えば外部ライターが文章を用意し、運営者がリンクや日付を確かめて公開するなら、担当を名前だけでなく作業の範囲で伝えます。権限を与える前には、実際に必要な操作と役割が合っているかを照合します。

公開中の原稿に別の人が手を入れた場合は、最初に見た文章のまま修正を送らないことも重要です。現行資料には編集ロックや古い版への保存を拒否する仕組みの説明がありますが、今回その競合を再現していません。複数人で運用するなら、通知が出たときに最新版を読み直すこと、誰の変更を採用するか決めることを先に共有します。

AIに任せる作業がある場合は、利用者の役割に加え、接続に渡す権限や今回承認した範囲も確認します。その話は別記事のAI連携の権限確認票で詳しく扱っています。人同士の原稿確認にAIの自動操作を混ぜる場合も、誰が最終的に公開を決めるのかを明確にしておきます。

参照資料はEmDash公式の管理画面・役割の説明です。

参照資料はAI連携を任せる前の権限確認です。

スクリーンショットの個人情報を点検する

作業画面を記事に載せるときは、編集している本文だけでなく、画面の周囲にも注意が必要です。今回の管理画面には、投稿者欄にメールアドレスが表示されました。閲覧ページの下部にも、ログイン中のコメント欄にアカウント情報が出ていました。閲覧ページだから個人情報がないと考えて撮影するのは避けたいところです。

今回は、原稿の入力欄、言語欄、予約のダイアログ、公開状態、閲覧本文という範囲をそれぞれ切り出して撮影しました。ブラウザのアドレス欄、プロフィール、投稿者欄、コメント欄を含む全画面の画像を先に作る方法は使わず、必要な内容だけを撮影範囲に指定しています。

撮影後には、画像を実際に開いてメール、氏名、アカウント、認証に使う文字列、管理画面のURLが写っていないかを見直しました。今回の掲載画像に残っているスラッグはダミー原稿の識別名です。画像ファイル名や代替テキストにも本人のメールや管理URLを入れず、読者が確認すべき操作だけを説明します。

例として、予約画面を見せたいなら、カレンダー、時刻、タイムゾーン、確定ボタンが分かれば操作の理解につながります。アカウント全体の設定画面や認証の画面は、この説明には不要です。本文の公開例なら、タイトルから最終段落までを見せ、コメント欄や通知が出る位置まで範囲を広げないようにします。

画像の中に判断しづらい小さな文字があったら、そのまま掲載するより、撮り直せる範囲を考えます。画像ごとに何を示すために必要かを決めると、不要な周辺情報を減らせます。作業を見せる記事でも、本文の説明と画像の範囲が一致していれば、個人情報を載せずに読者の理解を助けられます。

EmDashの日本語運用を始める前の注意点

今回の実機確認では、日本語の短い原稿を保存し、手動で公開し、公開後の下書き変更を反映できました。予約公開は、初回の未実行に加え、Cron未設定の調査と一時追加後の再検証まで行っています。再検証では手動公開なしで管理画面が公開状態へ切り替わり、再認証後には閲覧側のタイトルと本文も照合できました。さらに、Cronが動いていることを確認してから未来の時刻を予約した試験では、21時05分の分に閲覧本文への切替を確認しました。ただし、00秒ちょうどの公開や長期運用の安定性まで保証した結果ではありません。

日常の更新を始めるなら、まず秘密を含まない原稿1件で、入力、保存、再表示、公開、修正保存、変更公開の順に状態を見ます。今回の画面のように英語が混在している場合は、操作名と意味をメモします。本文を日本語で書けても、日付の表示やコンテンツ言語が希望と一致するかは別途確かめます。

予約を使う場合は、登録した日時と時刻後の閲覧結果まで確認します。今回のように公開を確認できなかった場合、同じ原稿を複製したり、設定を推測で変えたりする前に、版、予定日時、構成、状態を記録します。配置を担当する人に渡せる情報を揃えれば、公開を急ぐ場合の手動対応と、予約実行の調査を個別に判断できます。

今回の検証環境は、以前用意したCloudflareの無料構成を使い、本人限定のAccess保護下で確認しています。小さな原稿1件の結果から、無制限の無料運用、大量アクセスへの耐性、一般公開の安全性を実証したとは言えません。今回、クラウドのプラン変更や新しい契約、PCへのインストールは行っていません。

記事の画面写真は2026年11月8日のv1.3.1で見えた状態です。現行の公式資料には追加の仕様や操作説明が含まれるため、実際に使う版の画面と照合してください。最初の導入判断には、保存できるかだけでなく、公開担当が確認を終えられるか、予約が動かなかったときに対応できるかも含めて考えられます。

参照資料はEmDash公式のコンテンツ編集ガイドです。