正しいけど読みたくなかった

メールとWebの幅を整えたあと、今度は文章の硬さが気になりました。表示は読みやすくなったのに、何件か続けて読むと同じ語尾が繰り返されます。

「確認できます」「把握できます」「可能です」「重要です」。一文ずつ見れば間違いではありません。しかし、毎朝読む日報として並ぶと、公式情報を別の言葉へ置き換えただけのように見えました。「嬉しい点は」「困る点は」という型も、内容より先にテンプレートが見えてしまいます。

ニュースの意味は分かるのに、自分の作業との距離が遠い。正確さを保ったまま、もう少し身近に読める文章へ直す必要がありました。

AIっぽさが出ていた原因

最初は語尾を数個禁止すれば直ると思いました。ところが、「確認できます」を避けても、「運用を進めやすくなります」「選択肢が増えます」のような別の定型文へ置き換わります。

原因は単語だけではありませんでした。ニュースごとに同じ役割の項目を同じ順で生成するため、指示が曖昧だと文章まで同じ型へ寄ります。元の公式ニュースが硬いほど、その言葉をなぞった説明にもなりやすくなりました。

一方で、人らしく見せるために根拠のない感想を足すのも違います。日報には事実と自分の見方の両方が必要ですが、その境界は残さなければなりません。ここは言葉を柔らかくするだけではなく、何をどの欄へ書くかの設計から見直しました。

目指した文章の距離感

目標にしたのは、同じチームのAWSエンジニアが朝会前に「今朝はこれを見ておくとよさそうです」とまとめてくれた距離感です。

知識を見せる文章ではなく、初心者でも意味を追える短い文章。結論を押し付けず、気になる点があれば自分で原文へ進める文章です。読み終えたときに、ニュースを全部覚えていなくても、小さな気づきが一つ残れば十分だと考えました。

この基準を決めたことで、「正しい日本語か」だけでなく、「朝に同僚からこの言い方で渡されたら読みたいか」を見られるようになりました。

プロンプトで変えたこと

openai.mjs の生成指示には、同じチームのエンジニアとして、朝会前に読む人へ書くことを明記しました。知識を誇る言い方を避け、初心者にも伝わる短い文にします。各項目は1〜3文、スマートフォンで3〜5行程度を目安にし、同じ言い回しを続けないようにしました。

「できます」「となります」「可能です」「把握できます」「確認できます」「重要です」「推奨されます」は、繰り返しやすい表現として極力避ける指示にしています。ただし、単純な禁止語置換ではありません。ニュースの事実と、そこから受けた印象を分け、感想は根拠のある範囲で1〜2文に抑えました。

項目名も、機械的な分類に見えないように変えました。

  • 👍 ここが嬉しい
  • ⚠️ 気になるところ
  • 🤔 自分ならこう見る

英語の原題は出典として残し、表示側では日本語要約の最初の一文を主見出しに使います。これは翻訳済みの題名を装うためではなく、最初に日本語で要点へ入れるようにするためです。

Before / After

文章調整では、意味を変えずに距離感がどう変わるかを比べました。次はそのときに使った比較例です。

Before

高カーディナリティな監視データを扱う際、ワークスペースの上限を意識した設計を進めやすくなります。

After

メトリクス数が多い環境でも、少し余裕を持って設計できそうです。今まで上限を気にしていた人には、地味に助かる更新ですね。

「設計を進めやすい」で終えず、誰に関係する更新かを短く足しました。

もう一つは、セキュリティ情報の例です。

Before

公式の重要なセキュリティ情報として、確認すべき論点を早期に把握できます。

After

対象のライブラリを使っているなら、一度見ておきたい内容です。今すぐ影響がなくても、アップデート状況だけは確認しておくと安心です。

こちらも重要性を断定するだけでなく、対象なら何を見ればよいかへつなげました。これらは文章のトーンを比べるための例で、現在のDRY RUN出力からニュース本文をそのまま引用したものではありません。

Structured Outputsと文章品質は別問題

日報の生成にはStructured Outputsを使い、決めたJSON Schemaに合う形で受け取ります。必須項目、配列の数、文字列の長さ、URLや日付の形式を検証してからHTMLへ進むため、項目の欠落や構造崩れを見つけるには役立ちます。

ただし、Schemaに合格した文章が読みやすいとは限りません。「確認できます」が何度続いたか、同じニュースで似た感想を繰り返していないかまでは、現在のJSON Schemaは判断しません。

Dailyのテストは現在17件あります。モデル設定の統一、Schemaとハッシュ、重複URL、タイトル表示、HTMLエスケープ、Webのレスポンシブ構造、メールの600pxレイアウト、メールのスナップショット、DRY RUN、冪等性などを確認しています。Web側を変えたときにメールのスナップショットが意図せず変われば検出できます。

一方で、AIらしい定型表現だけを検出する専用テストはまだありません。core.mjs の禁止内容チェックは、認証情報や非公開情報を出さないためのもので、文体検査ではありません。プロンプト、構造テスト、実際に読む確認は、別の層として扱う必要がありました。

今回ハマったポイント

起きたのは、禁止した表現を減らしても、別の定型表現へ置き換わって硬さが残ったことでした。最初は語尾の一覧が足りないと考え、避けたい言葉を増やそうとしました。

生成結果を項目ごとに見比べると、原因は語尾だけでなく、毎回同じ観点を同じ調子で説明していたことでした。そこで、読み手との関係、文の長さ、事実と感想の境界、感想の役割までプロンプトへ加えました。表示見出しも「嬉しい点」「困る点」から、会話に近い言葉へ変更しました。

次回からは特定の禁止語だけを数えず、複数ニュースを続けて読みます。同じ語尾、同じ結論、根拠のない感想が続いていないかを確認し、Schema合格と文章品質を分けて記録します。

今回の学び

AIっぽさは、派手な言葉よりも同じ安全な言い回しが続くところに現れました。禁止語を足すだけではなく、誰が誰へ、どの場面で話す文章なのかを決めた方が調整しやすくなります。

それでも、プロンプトだけで毎回自然な文章になるわけではありません。ニュースが硬ければ出力も硬くなり、同じ入力なら似た表現が出ることもあります。構造は自動で守り、文体は出力を並べて読む。この二つを混ぜないことが、毎朝読む文章を育てるうえで大切でした。

次回は、Scheduler、Lambda、S3、CloudFront、SESがどこでつながり、どこから別の役割になるのかを構成図で整理します。