EmDashのAI連携｜任せる前の権限確認と注意点

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

記事の冒頭を一段落だけ直したい。AIに頼めば早そうですが、連携時に「コンテンツへの書き込み」を求められると、公開中の記事まで変わらないか気になります。EmDashでは、AIに与えるスコープと接続する人の役割を組み合わせて、操作の可否を判断します。

この記事はEmDashの公式資料をもとにした調査記事です。実際のサイトへの接続、認証、記事の編集・公開は検証していません。後半の依頼文と差分は、委任の境界を考えるための架空例です。

記事のポイント

• 資料検索とサイト操作の違い
• 読取・編集・公開・管理設定の分け方
• ロール・スコープ・本人の承認範囲の照合方法
• 記事1件を対象にした依頼文と差分確認票

EmDashのAI連携を任せる前提

先に決めるのは、AIに答えを調べてほしいのか、サイトの状態を変えてほしいのかです。作業の目的から逆算すると、同意画面で確認すべき項目を絞れます。

資料検索とサイト操作を分ける

EmDashの公式ガイドは、公開ドキュメントを参照するDocs MCPと、特定のサイトで操作するSite MCPを分けています。「公開予約の考え方を調べたい」段階なら、公式ドキュメントを読むだけでも進められます。

「うちの下書きの見出しを確認したい」になると、対象はサイト内の情報です。さらに「その見出しを保存して」まで依頼すると、サイトの状態が変わります。似た言い方でも、必要な権限と確認事項は変わります。

Xには、短い指示でサイトと管理画面をまたぐ更新をしたという投稿者の紹介がありました。別の投稿では、AI連携とプラグインの隔離範囲への関心が見られました。どこまで委任できるかは、投稿者の体験から推測せず、公式の操作と権限の対応を確認します。 EmDash公式のAI連携ガイド、利用者の公開投稿、AI連携と隔離への関心を示す公開投稿

例えば、公式資料を調べるときの質問は「予約公開とは何か」「利用者の役割はどこに説明されているか」などです。調査の回答にサイト名や記事IDが必要かを考えると、資料検索だけで足りるか判断できます。質問が途中で運営中のサイト固有の話に移ったら、その時点で依頼を切り分けます。

読取と下書き編集の対象を決める

「読取だけなら問題ない」と思ったときは、何を読めるかまで確認します。MCPの公式リファレンスでは、content:read は記事のほか、分類やメニューなどにも対応します。非公開コンテンツを読める範囲は利用者の役割にも左右されます。 EmDash公式のMCP Serverリファレンス

例えば、下書き「春の展示案内」の冒頭を整える依頼なら、その段落と公開してよい前提だけを手元で抜き出せます。AIに修正案を出してもらい、人が原稿へ反映する形なら、サイトへの接続を決める前に文章の良し悪しを判断できます。

サイト内を読ませる理由がある場合は、記事の識別情報、所有者、現在の状態を控えます。同名の公開記事と下書きが並んでいると、タイトルだけで依頼したときに対象を取り違えやすくなります。

読ませたい情報と、読める可能性がある情報を並べてください。欲しい情報が本文1段落でも、サイト上では同じ権限で他の下書きや分類などに触れられる場合があります。原稿に顧客名や社内向けメモが混ざっているなら、その箇所を除いた抜粋を使う判断もできます。抜粋で意味が通じるかは、段落の前後にどの事実が必要かを見て決めます。

作業が継続的な棚卸しなら、必要な対象を「今月公開した記事のタイトルとURL」のように限定して考えます。一度きりの推敲と、毎週の情報取得では、接続に見合う理由が異なります。接続前に結果の見本を1行書くと、欲しい項目と無関係な項目を整理しやすくなります。

公開と管理設定を別に扱う

下書きを保存する判断と、読者に見せる判断には別々の確認が要ります。本文の表現が直っていても、公開日、予約時刻、リンク先、公開前の最終確認が残っていることがあります。

公式リファレンスの content:write は、記事の更新に加え、公開・予約・削除などの操作にも使われます。管理設定には別の settings:manage があり、管理者の役割が求められます。各操作の条件はリファレンスの該当項目で照合します。

例えば公開前の展示案内なら、原稿を整える担当と、開催情報が確定したと判断する担当を分けます。一人で運営する場合も、「修正の確認」と「公開の確認」を別の時点で行えば、未確定の案内を公開する判断を減らせます。

下書き作業で見落としやすいのは、本文を直すつもりが、記事のURLやナビゲーションにまで話が及ぶ場面です。例えば、展示案内の見出しを直した後に「一覧メニューにも追加すると便利です」と提案されても、作業票にメニュー変更を追加するまでは提案として扱います。管理設定を変更するときは、記事一件の担当が判断できる範囲か、サイト全体を管理する人の判断が必要かを確認します。

予約を認める場合は、時刻だけでなくタイムゾーンと最終確認の期限も別の欄に残します。「金曜の朝」のような相対的な表現では、複数人で作業すると解釈がずれるためです。判断が揃わない場合は、本文の案だけを確定して予約は保留できます。

ロールとスコープを照合する

ロールは、接続する利用者がサイト内で担う役割です。スコープは、接続するアプリにどの種類の操作を認めるかを示します。公式ガイドでは、OAuthの同意画面にアプリが要求するスコープが表示され、操作には利用者のロールの制約も適用されます。

例えばContributorは自分の下書きを扱い、Authorには自分の記事を公開できる権限があります。同じ書き込みスコープが表示されても、利用者のロール、記事の所有関係、操作によって判断は変わります。

接続の可否を決めるときは、技術的に可能なことを確認した上で、人が今回許可する範囲を記録します。「この段落のみ」を条件にしたい場合、スコープの名称から段落単位の制限を読み取ることはできません。

同意画面で初めから選択されている項目があっても、接続前に自分の目的と突き合わせます。例えば、資料検索の予定だったのに個別サイトの書き込みを求められた場合は、いったん戻って参照先を確認します。あとから役割が変わった場合も、前回と同じ依頼文だけを根拠に同じ扱いを続けず、現在の条件で判断し直します。

依頼文だけで権限を保証しない

「公開しないでください」と依頼文に書くと、人が希望する作業範囲は明確になります。公開操作そのものが技術的に許されるかは、EmDash側の権限判定で決まります。

例えば、対象が下書きで、依頼文にも下書きを維持するよう書いたとしても、同意画面に広い書き込み権限が表示されたら、接続する利点と影響を改めて判断します。

要望と技術的な権限の間に差があり、その差を引き受けられない場合は、AIには手元の文章の修正案までを依頼し、保存は人が行います。提案の速さを活かしながら、サイトへの変更を人の確認に残せます。

「この依頼のとおりなら安心」と感じたら、依頼が誤って解釈された場合の影響を一つ挙げます。例えば公開中の記事が書き換わると、元に戻す前に読者へ新しい文章が表示される可能性があります。変更案を返す運用なら、文章の誤解は原稿の段階で見つけられます。

逆に、毎回人が転記すると手間がかかる作業もあります。その場合は、反復する対象と頻度、許容できる操作、確認にかかる時間を書き出します。広い書き込みを渡すか迷うときは、数分短縮できる作業と、取り違えが発生した際に調査が必要な範囲を同じ票に並べると判断できます。

EmDashのAI連携の確認票

ここからは、架空の下書き「春の展示案内」を例にします。依頼を出す前に、対象と停止条件を記入し、保存を認める場合は差分を確認します。

対象記事と許可範囲を書き出す

依頼を「展示案内を改善して」と書くと、冒頭の言い回しだけを直すのか、タイトルや日程を変更するのかが曖昧です。対象の状態と変更してよい箇所を先に書き出します。

この例では、記事1件、現在は下書き、対象は冒頭1段落、作業は変更案の提示です。タイトル、日程、予約、公開状態は維持する条件に入れます。元の段落は比較できる形で手元に残します。

本文に未発表の日程が含まれているなら、そもそも連携先へ渡してよいかも考えます。案内文の表現だけを整えたい場合は、日付を伏せた例文で提案を受けても目的を達成できます。

作業票は最初から細かく作り込む必要はありません。例えば見出しの案が欲しいだけなら、対象の見出し、読者、変更の理由を1行ずつ書けば、必要な情報が揃います。記事の識別情報は、後で保存する場合に人が照合できるよう、同名記事を区別できる形式で手元に残します。

元の文章を残すときは、どの時点で取ったかも書いておきます。共同編集で文章が変わった後に、古い案をそのまま反映すると、別の担当者が直した内容を消してしまう可能性があるためです。元の文を取得した時刻と、実際に確認した時刻を並べると、比較をやり直すべきか判断できます。

作業が途中で広がりそうなら、「日程の確認は別件」「リンク先の変更は次の承認」と書いておきます。依頼が増えても、最初の判断がどこまで有効かを追えます。

架空の依頼文で境界を確かめる

依頼文には、何を返してほしいかと、迷ったらどこで止まるかを書きます。返答を差分の形にそろえておくと、人は元の文と提案を見比べられます。

例えば、日程が決まっていない案内文に、AIが具体的な開催日を付け足すと、読みやすくても事実が変わります。「日程を補わない」「対象が曖昧なら確認する」と条件に入れると、レビューの観点も明確になります。

この例の成果物は修正案です。後からサイトに保存する段階では、保存先と状態、誰が承認したかを改めて確認します。

返答を受け取ったら、指示が守られたかを元の段落に照らします。例えば「会場の詳細を確認してください」という元の文を「会場の地図をダウンロードしてください」に直す提案があったら、地図をダウンロードできるかは別の事実確認が必要です。表現の改善と、新しい内容の追加を分けて読みます。

同じ型を別の記事に使うときは、許可する動詞を作業に合わせて書き換えます。「確認する」「案を返す」「保存する」「公開する」の違いを文中で揃えると、返答に求める結果が明確になります。許可した範囲を越える便利そうな提案が返ってきたら、別の作業として必要性を判断できます。

担当が交代する場合は、この依頼文と回答の両方を残し、変更理由も渡します。回答だけを見ると、最初から日程などの条件を変更できたように読めることがあるためです。

保存前後の差分と状態を記録する

修正案を見たら、本文の差分と記事の状態を別々に確認します。読みやすくなった文章でも、日程を確定させたり、予定にない告知を追加したりしていれば、判断を戻します。

架空例では「会場の地図」を最初に見るという順番だけを明確にします。会場そのものや日時、公開状態は維持します。差分確認時に対象が公開済みへ変わっていた場合は、下書きに対する承認をそのまま使わず、担当者と確認します。

保存を人が行う場合も、反映後に実際の記事を開き直して、想定した段落と状態を確認します。下の表の「確認点」は将来の照合欄であり、サイト上で保存を検証した結果は含みません。

差分を承認した時点と、実際に保存する時点が離れたら、最新の原稿を開き直します。例えば別の担当者が元の文を変更していた場合は、以前の差分をそのまま当てず、最新の文を使って確認し直します。作業票には「比較した版」と「保存後に見た版」を分けて書きます。

保存結果が分からないときは、先に記事を再表示して該当箇所を確認します。処理の成否が不明なまま同じ依頼を繰り返すと、変更履歴を追いにくくなります。状態が確認できなければ、その点を未確認として担当へ引き継ぎます。

担当と中止条件を先に決める

作業が止まるときに誰が確認するかを決めておくと、担当が替わっても承認の範囲が伝わります。編集担当が文章を確認し、公開担当が公開時期と公開範囲を確認する形が一例です。

中止条件は、実際に見分けられる状態にします。例えば、同名の記事が2件ある、開いた記事が公開済みになっている、要求スコープが想定より広い、の3つです。どれかに当てはまったら保存の判断を保留します。

すでに保存したものをどう保全するかは、担当と合わせて決めておきます。元の本文、確認時の状態、変更日時があると、差分を説明しやすくなります。 EmDashの保全を考えるための関連記事

一人で担当する場合は、編集作業と公開判断の間に小さな確認の区切りを設けられます。例えば文章が整った時点で「編集確認済み」と記入し、案内情報が確定してから「公開承認済み」と記入します。翌日に作業を再開しても、どちらの判断が済んだかが分かります。

チームの場合は、たまたま作業チャットを見た人が進めてよいのかも決めておきます。担当が不在なら「案の提示まで」など、その場で続けられる作業を指定します。判断を引き継ぐ際には、変更したい箇所と、止まった理由を一緒に伝えると、新しい担当が最初から調べ直す手間を減らせます。

例えばスコープに想定外の項目があったら、項目名と本来の作業目的を残します。連携を再検討する人が、何を比べて止めたかを把握できます。

EmDashのAI連携を判断する基準

今日の目的が「冒頭を読みやすくする」なら、公開できる情報だけを使い、案の作成と比較から始められます。サイト内を参照する必要が出たときに、読取の対象と見せてよい範囲を確認します。

保存を委任する必要がある場合は、対象記事と状態、利用者のロール、要求スコープ、本人の承認、停止条件を照合します。公開・予約まで委任する場合は、誰が読者への公開を決めるかも記録します。

プラグインを導入する判断もあるなら、そちらは種類や実行環境の違いを別途確認します。AI連携の同意画面は、今回接続するアプリと任せる操作に絞って判断します。 EmDashプラグインの選び方

どこから始めるか迷ったら、架空例と同じように、影響範囲を言葉にできる作業を選びます。比較対象は、手元の文章から提案を受ける方法と、個別サイトに接続する方法です。前者で目的を満たせるかを確かめ、接続の理由がある場合だけ、公式資料と同意画面を照合します。

運用が変わったら、確認票も作り直します。例えば最初は文章の提案だけだった作業を、後から定期的な予約公開に広げるなら、担当、時刻、確認方法が新たに必要です。一度承認した連携でも、そのときの依頼に対する判断と、次の作業への承認を記録上で分けます。

今すぐ書ける項目が対象と状態だけなら、まずそこまで埋めれば十分です。未記入の箇所は、接続前に公式資料や担当者に確認する項目として使えます。