AIGithubChatwork

「サイトを更新しました」では伝わらない——更新内容を「クライアントの言葉」に翻訳する仕組み

「サイトを更新しました」の一言では何も伝わらない

開発会社やパートナーに Web サイトの保守を頼んでいると、ときどきこんな連絡が届きます。

「v1.2.3 をリリースしました。CSS の調整とコンポーネントのリファクタリングです」

——読み流すしかないという事業者は多いと思います。何が変わったのか自分のサイトにとって何が嬉しいのかも、これではわかりません。

確認しに行く時間もない。「とりあえず動いていれば OK」で済ませる。そしてせっかくの改善が「気づかれないまま」過ぎていく。

これはサイトを直す側にとっても良くない状態です。手を動かして良くしているのに、伝わっていなければ「ちゃんと面倒を見てもらえている」という安心にも信頼の積み上げにもなりません。

伴走しているクライアントとのやりとりでまさにこの課題にぶつかりました。更新の連絡を毎回手で書き直すのは続かない。かといって開発側で出てくる文章をそのまま送ると相手にとっては暗号と変わらない。

そこで作ったのがサイト更新の通知を「クライアントの言葉」に自動で翻訳する仕組みです。

リリース通知 翻訳フロー

仕組みの全体像——「直す」と「伝える」をつなぐ

サイトを直すと開発の現場では自動的に「変更点リスト」のような文章が生成されます。たとえば「ご利用ガイドのセクション改善と設定ファイルの修正」「リリースノート自動要約機能の追加」といった開発側の作業内容を並べた箇条書きです。

これがそのままクライアントに送られるとほぼ伝わりません。

ここに AI を一段挟みます。技術用語を取り除いて「何が嬉しくなったか」に書き直す役割です。先ほどの 2 行はAI を通すと「ご利用ガイドのページがより見やすくなりました」「サイト更新のお知らせがより分かりやすい表現になりました」という形に変わります。

同じ内容ですが受け取った側が「なるほど」と思える言葉になっています。

この翻訳されたお知らせがクライアントが日常的に使っているチャットツールに自動で届く。サイトを直すたびに毎回必ず流れる。手で書く必要はない。これが今回作った仕組みです。

なぜ AI に翻訳させるのか——手で書くと続かない

最初は「毎回手で書けばいい」と思っていました。1 件あたり数分の作業です。

でも続きません。

リリースは月に何度もあります。小さな修正も含めれば年間で数十件。そのたびに「クライアント向けの言葉」に書き直す手間が発生する。忙しい日や深夜のリリースのあとにはつい省略してしまう。

「省略されるかもしれない仕事」を人の意志に頼ってはいけないというのが運用してみての結論でした。仕組みに載せれば忙しくても深夜でも毎回必ず同じ品質で届きます。

AI への指示にはいくつかのルールを書き込みました。

  • 技術用語(CSS、コンポーネント、リファクタリングなど)は使わない
  • 「何が変わったか」「どう良くなったか」を説明する
  • 各項目は 1〜2 文で簡潔に
  • 開発者向けの内部的な変更は「内部改善を行いました」の一行にまとめる

このルールがあるからAI が出してくる文章はだいたい安定して「読める日本語」になります。完璧ではないけれど人が手で書き直すよりずっと続く。

どこに届けるか——「見に行く」ではなく「届く」場所に

翻訳されたお知らせをどこに届けるかも悩みました。

メールにすると受信ボックスに埋もれます。専用のダッシュボードを作ってもログインしてくれません。「何かあったときだけ見に来てください」は実際には機能しません。

選んだのはクライアントが日常的に使っているチャットツールでした。すでに業務連絡で毎日開いている場所にサイト更新のお知らせも流す。

新しい場所を覚えてもらう必要がない。通知のために何かをインストールする必要もない。「気づこうとしなくても気づける」状態にする。これは問い合わせフォームの受け皿をチャットツールに流したときと同じ考え方です。

通知の本文はサービス名・バージョン・要約・詳細ページへのリンクの 4 点に絞りました。スマホでチャットを開いた瞬間に要点が読み切れる長さです。

「止まらないこと」を最優先に設計する

仕組み化で一番こわいのは「動いているはず」が「実は止まっていた」になることです。

たとえば AI の窓口が一時的に混雑していて応答が返ってこなかったとき。仕組みがそこで止まるとクライアントへの通知も止まります。サイトは更新されているのにお知らせだけが届かない。気づかなければそのまま放置される。

これを避けるためにもし AI の翻訳が失敗したら翻訳前の元の文章をそのまま流す設計にしました。技術用語が残ったままでも何も届かないよりはいい。「翻訳の質」より「通知が止まらないこと」を優先したという判断です。

仕組みはうまくいくときの想定だけでなく「うまくいかなかったとき何が起きるか」を決めておくと長く使えます。

「直すこと」と「伝えること」は別の仕事

サイトを直す技術と直したことを伝える文章は本来まったく別の仕事です。手を動かす人の頭の中には「何を直したか」しか残っていない。それを「何が良くなったか」に書き直すにはもう一度クライアントの目線に立ち戻る必要があります。

このスイッチを毎回人がやるのは負担が大きい。だから仕組みの中に組み込んでしまう。AI に翻訳の役割を任せて人は「中身を見直す」だけに集中する。

サイトを直すたびにその変化が「届く言葉」でクライアントに流れていく。これは派手な機能ではありませんが伴走しているという実感を一番ささやかに伝えられる仕組みだと考えています。

「直しておきました」だけで終わらせない。何が変わって何が良くなったのかを相手に届く形で残していく。Web サイトのパートナーとの関係はこういう小さな積み重ねで作られていくものだと思っています。

Tags

W e b

相談する
相談する