本文へ移動
技術を、自社の仕事に。
判断と実行を助けるメディア

記事を検索

Chat APIでMarkdownのまま投稿 通知ボットの書式変換を減らす

目次 · 7項目

社内の通知ボットや、生成AIに書かせた要約をGoogle Chatへ投稿する仕組みでは、元の文章がMarkdownで書かれていることがあります。GitHubの通知、議事録の要約、AIの回答などです。一方、Google Chatのメッセージには独自の書式記法があり、Markdownとは別物です。これまでは、投稿の前にMarkdownをChatの記法へ置き換える処理を自分で書くか、書式をあきらめて素の文字で送るかのどちらかでした。

Chat APIのメッセージに、本文(text)をどの記法で解釈するかを指定する項目 markupSyntax が加わっています。値に MARKUP_SYNTAX_MARKDOWN を指定すると、本文をMarkdownとして扱わせられます。Chat APIのリリースノートでは2026年8月7日に一般提供(GA)とされ、10月16日には、アプリごとの既定の記法をGoogle Cloudコンソールで選べるようになりました。本記事では、2026年10月19日にChat APIのリリースノート、書式のガイド(Format messages)、リファレンス、Discovery文書(revision 20261013)、Python用・Node.js用のクライアントライブラリを直接開いて確認した内容を整理します。資料調査と編集部の提案で、認証情報がないため実際の投稿は行っていません。コード例は型定義に対する型チェックだけを通しています。

加わった項目は2か所

1つ目は、送るときの項目です。メッセージ本体(Message)の markupSyntax で、リファレンスの説明は「Specifies how the server interprets the message text field content.」(本文 text の中身をサーバーがどう解釈するか)です。値は3つあります。

  • MARKUP_SYNTAX_CHAT: Google Chatの記法(「Uses Google Chat’s markup syntax.」)
  • MARKUP_SYNTAX_MARKDOWN: Markdown。「based on the CommonMark specification, with additional extensions」(CommonMarkの仕様をもとに、独自の拡張を加えたもの)
  • MARKUP_SYNTAX_UNSPECIFIED: 未指定

2つ目は、読み出すときの指定です。spaces.messages.get・spaces.messages.list・spaces.messages.search に同じ名前の markupSyntax があり、こちらは「Specifies the desired output syntax for the Chat message formatted_text field.」、つまり応答の formattedText(書式の情報を記号で付けた本文)をどちらの記法で返すかの指定です。

Chat APIのmarkupSyntaxの2つの使い道を示す図。送るときはspaces.messages.createでtextとmarkupSyntax: MARKUP_SYNTAX_MARKDOWNを指定し、本文をMarkdownとして解釈させる。読むときはget・list・searchのmarkupSyntaxで、formattedTextを返す記法を選ぶ。メッセージの上限は32,000バイト。指定しないときはアプリの設定に従い、既存のアプリの既定はChatの記法

いつから使えるか

Chat APIのリリースノートには、2つの告知が載っています。

  • 2026年8月7日: 一般提供(Generally Available)。「By specifying the markupSyntax field as MARKUP_SYNTAX_MARKDOWN when creating a message using the Chat API, the body text is parsed using standard Markdown formatting.」(メッセージの作成で MARKUP_SYNTAX_MARKDOWN を指定すると、本文が標準のMarkdownとして解釈される)
  • 2026年10月16日: アプリごとの既定の記法(Markup syntax)を、Google CloudコンソールのChat APIの設定ページで選べるようになりました。告知では、この日から展開を始め、数日で完了する見込みとされています。個々のAPIの要求で markupSyntax を指定すれば、既定より優先されます

クライアントライブラリに同梱された定義でも、時期はほぼ一致します(公開日はUTC)。Python用の google-api-python-client は2.199.0(8月20日公開、Chatの定義はrevision 20260809)から MARKUP_SYNTAX_MARKDOWN が入り、2.198.0(6月25日公開)にはありません。Node.js用の @googleapis/chat は、46.0.0(8月3日公開)から型定義に入っています。

送るときのコード

アプリの認証で、生成AIの要約をスペースに投稿する例です。Node.js用の @googleapis/chat 51.2.0 の型定義に対して、TypeScriptの型チェックを通しています。

import { chat_v1 } from '@googleapis/chat';

// 綴りを間違えても型チェックで気づけないため、定数にしておく
const MARKDOWN = 'MARKUP_SYNTAX_MARKDOWN';

// 生成AIの要約(Markdown)を、記号のまま出さずにスペースへ投稿する
export async function postSummary(chat: chat_v1.Chat, space: string, markdown: string) {
  const res = await chat.spaces.messages.create({
    parent: space, // 例: 'spaces/AAAAxxxx'
    requestBody: {
      text: markdown,
      markupSyntax: MARKDOWN,
    },
  });
  return res.data.name;
}

注意したい点が3つあります。1つ目は型です。@googleapis/chat の型定義では markupSyntax?: string | null; で、決まった値の一覧にはなっていません。'MARKUP_SYNTAX_MARKDWON' のような綴りの間違いも型チェックを通ってしまいます。上の例のように定数にまとめておくと、間違いを1か所で直せます。

2つ目は大きさです。メッセージの作成のリファレンスには「The maximum message size, including the message contents, is 32,000 bytes.」とあります。生成AIの長い出力をそのまま流す仕組みでは、文字数ではなくバイト数で上限を確かめます。日本語はUTF-8で1文字3バイトになることが多いため、1万字前後で上限に近づきます。

3つ目は、メンションやカスタム絵文字の書き方です。書式のガイドの対応表では、Markdownで送る場合のメンションは <chat-user data-user="users/{user}">(またはメールアドレスを使う <chat-user data-email="…">)、カスタム絵文字は <chat-emoji …> の形です。Chatの記法の <users/{user}> を組み立てている既存の処理は、Markdownに切り替えるときに見直してください。リンクも、Chatの記法の <https://example.com|表示する文字> から、Markdownの [表示する文字](https://example.com) に変わります。

読み出すときに使う

既存のメッセージをMarkdownの形で取り出したい場面もあります。Chatの会話をドキュメントやナレッジベースへ移すとき、あるいは生成AIに過去のやり取りを渡すときです。

// 既存のメッセージを読み、書式をMarkdownの形で受け取る
export async function readAsMarkdown(chat: chat_v1.Chat, name: string) {
  const res = await chat.spaces.messages.get({
    name,
    markupSyntax: MARKDOWN,
  });
  return res.data.formattedText ?? res.data.text ?? '';
}

formattedText については、リファレンスとDiscovery文書に「This field might not capture all formatting visible in the UI」(画面に見えているすべての書式を表すとは限らない)と書かれています。説明に挙がっているのは、太字・斜体・取り消し線・等幅・箇条書き・引用、メンション(<users/{user}>)、リンク(<{url}|{rendered_text}>)、カスタム絵文字(:{emoji_name}:)です。表や画像のような要素が残る前提で移行の仕組みを組まないでください。メッセージの検索(spaces.messages.search)と組み合わせる場合の条件は、Chat APIのメッセージ検索とピン留めの記事で整理しています。

指定しないときの扱いと、試して確かめたいこと

書式のガイドには、markupSyntax を指定しない要求の扱いが、呼び出し方ごとに書かれています。

呼び出し方指定しないときの記法
Chat APIの設定ページで構成したChatアプリ設定ページで選んだ記法。新しく作ったアプリはMarkdown、既存のアプリは互換性のためChatの記法が既定
Chatアプリの構成を保存していないCloudプロジェクトMARKUP_SYNTAX_MARKDOWN
受信WebhookMARKUP_SYNTAX_CHAT

既存の通知ボットは、何もしなければChatの記法のまま動き続けます。一方で、設定ページの既定をMarkdownに切り替えると、そのアプリが markupSyntax を付けずに送っているすべての投稿の解釈が変わります。*太字* のようにChatの記法で書いた投稿は、Markdownでは斜体として解釈されます。既定を変えるより、Markdownで送る要求にだけ markupSyntax を明示するほうが、影響の範囲を絞れます。

公式資料からは読み取れず、投稿の仕組みに組み込む前にテスト用のスペースで確かめたい点もあります。

  1. 見出しと表の表示: ガイドの対応表に載っているのは、太字・斜体・取り消し線・等幅・コードブロック・箇条書き・入れ子の箇条書き・番号付きの箇条書き(Markdownのみ)・引用・リンク・メンション・カスタム絵文字・引用元の表示(citation。Markdownのみで、デベロッパープレビュー)です。見出しや表がどう表示されるかは載っていません
  2. 受信Webhookで指定を変えられるか: Webhookの既定がChatの記法であることは書かれていますが、Webhookの要求で markupSyntax を指定して切り替えられるかは書かれていません
  3. 更新のとき: 10月16日の告知には、作成・更新・読み出しの要求で markupSyntax を指定できるとあります。一方、spaces.messages.update・patch のリファレンスで更新できる項目(updateMask)として挙がっているのは text・attachment・cards などで、markup_syntax は挙がっていません。Markdownで投稿したメッセージの本文を後から直すときの扱いは、実際に確かめてください

確かめるときは、見出し・太字・箇条書き・コードブロック・表・リンクを1つずつ含む短い文章を用意し、MARKUP_SYNTAX_MARKDOWN と MARKUP_SYNTAX_CHAT の2通りで投稿して、表示と formattedText を比べると違いが分かりやすくなります。

まとめ

Markdownの文章をChatへ流す仕組みを持っているなら、まず自前の変換処理がどこにあるかを確認し、テスト用のスペースで markupSyntax: 'MARKUP_SYNTAX_MARKDOWN' を指定した投稿と比べてみてください。変換処理を減らせるかどうかは、自社で使っている書式が期待どおりに表示されるかで判断できます。スペースの作成から自動化する場合は、スペースを自動作成するときの二重作成の防ぎ方も参考になります。投稿したユーザーの情報をあわせて扱うなら、送信者のメールアドレスを取得する条件も確認しておくと設計がぶれません。

2026年10月19日に、Chat APIのリリースノート、書式のガイド(Format messages)、Chat APIの設定のガイド(Configure the Google Chat API)、リファレンス(spaces.messages のリソース・get・create・search)、Discovery文書(chat v1、revision 20261013)、google-api-python-client 2.198.0・2.199.0に同梱の定義とPyPIの公開日時、npmの @googleapis/chat 45.0.0・46.0.0・51.2.0の型定義と公開日時を直接取得して確認しました(資料調査)。コード例は @googleapis/chat 51.2.0に対してTypeScriptの型チェックを通したものです。認証情報がないためAPIの呼び出しは行っておらず、実際の表示、見出しや表の扱い、Webhookでの指定、更新時の扱いは未確認です。

Google Chatへの通知の仕組みづくりや、生成AIとGoogle Workspaceをつなぐ社内ツールの設計は、グリームハブのIT・Google Workspace 無料相談で承っています。投稿の量や扱う情報によって構成が変わるため、お問い合わせからご相談ください。

参考資料

この記事を共有XFacebook
鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

この記事のテーマを、自社の次の一歩へ

自社に合う、Workspaceの進め方を。

移行するデータ、共有ルール、管理体制を整理し、導入から日々の運用までの進め方を考えます。

  • 移行と初期設定
  • 共有・権限の整理
  • 管理体制
Workspaceの導入・運用を相談する

構想段階からご相談いただけます。この記事の情報を相談フォームに引き継ぎます。

最新記事をメールで受け取る