Platform Engineering部 Engineering Officeの北林です。開発生産性向上のための基盤作りや生成AIの推進、技術広報などを担当しています。
生成AIの推進では、Claude、ChatGPT、Geminiといった生成AIサービスやn8nなどの自動化基盤の導入・運用に関わっています。こうしたツールの運用に日々触れるなかで、技術広報の活動にもこれらを活かせるのではないかと考えました。
GENDAでは「GENDA Creators Blog」を運営しています。メンバーが個人のブログで発信した記事を、本人の許可を得た上で集約し、GENDAの社員がどんな技術に興味を持っており、どのようなスキルを有しているのかを社外にも知ってもらうための場です。会社として改めて記事を書いてもらうのではなく、個人の発信をそのまま届ける形を取っています。
この仕組みには、二つの相反する課題があります。個人には「もっと気軽に書いてほしい」ということと、それを集約するGENDA Creators Blogという見せ方の場合は会社としての「リスクを見逃したくない」ということです。
これらの課題に対して、書き手側にはAIを活用した執筆サポートツールを提供し、裏側では公開後に自動でレビューが走る仕組みをn8nで構築しました。本記事では、その設計思想と実装、そして運用から見えてきたことを紹介します。
なぜ「公開後チェック」なのか
GENDA Creators Blogは、メンバー個人がそれぞれのブログで発信した記事を、本人の許可を得て集約しています。会社が記事の内容を事前に承認するのではなく、個人の自由な発信をそのまま届けることに価値がある。GENDAにどのような社員がいるのかを知ってもらえる場にする。事前の承認フローを挟むことは、その思想と相容れません。
私たちは、メンバーひとりひとりのプロフェッショナルとしてのリテラシーを深く信頼しています。社内には情報発信に関するガイドラインが整備されており、それを共通の指針として自律的に発信できる土壌があるからです。
だからこそ、「品質管理の仕組みは書く側から見えない場所に置きたい」と考えました。
これはチェックを放棄するということではなく、自由な発信文化を守り抜くために、テクノロジーと人の目による多層的なセーフティネットを「裏側」に構築するという思想です。具体的には、Gemにより書き手の心理的ハードルを下げ、公開後は自動レビューシステムがリスクを検知し、必要に応じてEngineering Officeが対話を引き継ぐという体制をとっています。
ガイドラインという前提を共有した上で、万が一のリスクを裏側で即座にフォローする。この「攻め（発信支援）」と「守り（リスク管理）」を分離した形こそが今の我々にはあっていると考えています。
今回構築した仕組みは、RSSフィードを短い間隔で定期的にチェックし、新しい記事が公開されたらAIが自動でレビューを行い、結果をSlackに通知するというものです。
ポイントは既存の執筆・公開のフローには一切手を加えていないことです。
- どのツールで書いても、どのサービスで公開しても関係ない。RSSフィードがあればすべて対象になる
- 執筆者には事前に仕組みの存在を周知しつつも、実作業においては追加の手間や意識を必要としない。
- 公開までのステップが増えない
なお、テックブログの記事自体がGitHubで管理されている場合など、運用するツールに指定があれば最適な方法は都度変わっていくでしょう。
書き手を支える仕組み―Gemによる執筆サポート
一方で、書き手が「これで大丈夫かな」と不安になる場面はあります。そこで、任意で使えるAIベースの執筆サポートツールも用意しています。
Google GeminiのGem機能を使い、GENDA固有のガイドラインを組み込んだ「アーティクル・チューナー」を社内に展開しています。記事の原稿を渡すと、以下の四つの観点でチューニング提案を返してくれます。
- ブランド・理念: GENDAの理念やブランドに沿った表現になっているか
- 炎上リスク・社会的配慮: SNSで切り取られた場合のリスク、差別的に読まれうる表現がないか
- ビジネス・信頼性: 他社への配慮があるか、誇大表現が含まれていないか
- 構成・品質: 読み手にとって分かりにくい記事になっていないか
使いたい人が使いたいときに使える。義務にはしない。あくまで「書き手側の安心材料」として機能させています。
全体の流れを整理すると、以下の通りです。
Gemが書き手のハードルを下げる役割、自動レビューがリスクを見逃さない役割。この二つで「もっと書いてほしい」と「リスクは見逃したくない」の両方をカバーしています。もちろん、これらに加えて部署内で相互レビューを行うこともあります。以降では、自動レビューシステムについて詳しく紹介します。なお、Claude Codeが社内でもデファクトスタンダードになりつつあるため、今後はこの事前レビューをSkillsに載せ替えていくことも検討中です。
自動レビューシステムの全体像
n8nのワークフローとして実装しています。RSSの取得からAI呼び出し、Slack通知までを一つのワークフローで完結できること、ノードの追加・修正が容易であることが選定理由です。
全体の流れは以下の通りです。
記事本文の取得は2段階で行っています。まず、取得したHTMLからナビゲーションやヘッダー、フッターなどの不要部分を機械的に除去します。さまざまなブログサービスに対応しつつ、AIに渡すデータのノイズを減らすための前処理です。その上で、残ったHTMLをgpt-5-nanoでMarkdown形式に変換してからレビュー用のAIに渡しています。HTMLをそのまま渡すよりも、本文や見出し、コードブロックが整理された状態の方が、判定が安定します。
状態管理にはGoogle Sheetsを利用しています。チェック済みの記事URLをシートに記録し、RSSフィードと照合することで重複処理を防いでいます。専用のデータベースを立てるほどの規模ではないため、運用者が直接確認・修正できるスプレッドシートの方が実用的でした。
| 役割 | 技術 |
|---|---|
| ワークフロー管理 | n8n |
| 記事本文の取得 | n8n Codeノード（HTML整形）+ gpt-5-nano（Markdown変換） |
| AI判定 | OpenAI API（gpt-5-nano/Structured Output） |
| 状態管理 | Google Sheets |
| 通知 | Slack API |
リスク検出や分類のようなタスクは軽量なモデルでも十分な精度が出るため、gpt-5-nanoを採用しています。1記事あたりの処理時間は約3分程度、コストは$0.01以下です。軽量なモデルを使うので検出の網を意図的に狭く設計し、引っかかったものは人間が見る。この「AIは拾う、人間が判断する」という役割分担が、現時点では最も信頼できる形だと考えています。
Structured Outputによる出力の安定化
二つのAIエージェントの出力は、いずれもJSON Schemaで構造化しています。OpenAIのStructured Outputを使うことで、通常の成功応答ではスキーマに適合し、フィールドの型や値をenumで制約できます。
Critical Risk Checkerの出力スキーマは以下の通りです。
{
"status": "ALERT | SAFE",
"alerts": [
{
"type": "機密情報 | 法令違反 | 差別・ヘイト | 労働環境リスク | 不用意な表現",
"severity": "critical | high",
"quote": "該当箇所の抜粋",
"reason": "なぜ問題なのか"
}
]
}
statusはALERTかSAFEの二値、typeは五つの検出カテゴリ、severityはcriticalかhighのいずれかです。フィールドの値域をenumで制約することで、後続の分岐処理が安定します。quoteで該当箇所を抜き出し、reasonで理由を添える構造にすることで、人間が判断するための材料も定型化されます。
Quality Feedback Agentの出力スキーマは以下の通りです。
{
"good_points": [
{
"category": "技術的価値 | 説明力 | 構成 | チャレンジ | 読者配慮",
"point": "具体的な良い点の説明",
"quote": "該当箇所の抜粋"
}
],
"suggestions": [
{
"type": "追加提案 | 補足提案 | 表現提案",
"content": "ポジティブな提案内容"
}
],
"summary": "記事の全体的な印象"
}
good_pointsは2〜4個、suggestionsは0〜3個という個数の目安もプロンプトで指示しています。フィードバックの分量がばらつかないようにすることで、Slackメッセージのフォーマットが安定し、受け取る側にとっても読みやすい出力になります。
二つのAIエージェントに分けた設計判断
初期バージョンでは、一つのAIに「リスクチェックとフィードバックを両方やってほしい」と指示していました。しかし運用してみると、問題が見えてきました。
それは、判定のブレです。一つのAIに相反する評価軸を同時に持たせると、互いに干渉して判定がブレやすくなりました。「良い点を挙げてからリスクを指摘してほしい」と指示すると、ポジティブな文脈に引っ張られてリスクの検出漏れが起きる。逆にリスク検出を厳しく設定すると、フィードバック全体のトーンまで厳しくなってしまいます。
そこで、役割を完全に分離しました。
- Critical Risk Checker: リスク検出だけに集中する。判定は
ALERTかSAFEの二値 - Quality Feedback Agent: 良い点と改善のヒントだけを返す。判定には一切関与しない
判定を二値にしているのには理由があります。初期の設計では三段階の判定を試しましたが、中間の判定にAIが過剰に吸着し、ほとんどの記事で警告が出る状態でした。検出カテゴリを「本当に即座の確認が必要なもの」に絞り込み、判定を二値にしたことで、ALERTが出たときの信頼性が上がりました。
なお、品質フィードバックは執筆者に直接届くものではなく、Slackに流れた結果をEngineering Officeが確認する形で活用しています。エージェントを分離した主な目的は判定のブレ防止ですが、この副産物としての品質フィードバックが運用上どう機能しているかは後述します。
Slack上ではこのように見えます。
リスク検出プロンプトの設計
Critical Risk Checkerのプロンプトは、六つの層で構成しています。
- Role定義: 何者として振る舞うか
- 検出カテゴリ: 何を検出するか
- 除外リスト: 何を検出しないか
- 判定原則: どういう基準で判定するか
- Few-shot Examples: 境界線の具体例
- 出力スキーマ: どんな形式で返すか
試行錯誤の結果、この順番に落ち着きました。検出対象を定義する前にRoleを明示することで、後続の指示がすべて「門番」としての文脈で解釈されるようにしています。除外リストを検出カテゴリの直後に置いているのは、「ここまでは検出、ここからは範囲外」という境界を近接させて判定のブレを抑えるためです。
以下、各層のポイントを紹介します。
Role定義: 「門番」と「事後チェック」
プロンプトの冒頭で、このAIの役割を二つの軸で定義しています。
一つは「企業リスク管理の門番であり、検出のみを担当する」こと。最終判断は人間が行うという前提を、プロンプトの最初に置いています。
もう一つは「これは事後チェックである」という前提です。記事は既に公開済みのため、「公開の是非」や「公開を止めるべき」という表現ではなく、「確認が必要」「修正を検討」という表現で出力するよう指示しています。この前提を最初に与えることで、検出時の出力トーンが適切に調整されます。
五つの検出カテゴリ
検出するリスクは以下の五つに分類しています。
- 機密情報
- 法令違反
- 差別・ヘイト
- 労働環境リスク
- 不用意な表現
各カテゴリには、検出すべきパターンを具体的に列挙しています。例えば「不用意な表現」では、属性に基づくステレオタイプや、「誤解を恐れずに言うと」「毒舌ですが」のような「危険な予防線」も検出対象としています。属性に基づく能力の限定は書き手に悪意がなくても切り取られやすく、こうした予防線も免罪符になりません。
「検出しないもの」を明示する
プロンプト設計で最も重視したのは、「何を検出しないか」を明確にすることです。
- 技術的な不正確さ: 技術レビューの範疇であり、このシステムの対象外
- 「常識」「誰でもできる」程度の配慮不足: 表現の好みの範疇
- 根拠や出典の欠如: 編集方針の範疇
- トーンの改善提案: Quality Feedback Agentの担当
AIに「リスクを見つけてほしい」とだけ指示すると、検出範囲が際限なく広がります。技術的な間違いも、出典の不足も、すべてが「リスク」として報告される。その結果、毎回大量のWARNINGが出て、本当に対処すべきものが埋もれてしまいます。検出範囲を意図的に絞ることで、ALERTが出たときの信頼性を高めるのが狙いです。
除外リストにはもう一つの機能があります。それは、二つのエージェントの責務境界を明確にすることです。「トーンの改善提案はQuality Feedback Agentの担当」とCritical Risk Checker側のプロンプトに書くことで、リスク検出が品質フィードバック領域に踏み込むことを防いでいます。
「意図」ではなく「見え方」で判定する
プロンプトに明記している判定原則が二つあります。
- 書き手の意図は考慮しない。分かりやすさのためにあえて使った表現であっても、文字面で問題があれば検出する
- 前後の文脈は考慮しない。SNSで一文だけ切り取られたときにどう見えるかで判定する
これは厳しい基準に見えるかもしれません。しかし、個人の記事であっても、企業名と紐づいた状態になると、純粋な個人の発信とは異なる文脈で読まれることがあります。SNSで一文だけ切り取られたとき、前後の文脈が正確に伝わる保証はありません。「記事を全部読めば分かる」が通用しない場面があるということです。だからこそ、AIには「切り取られた一文だけを見たとき、問題がないか」という基準で検出させています。
その代わりに、最終判断は必ず人間が行います。AIの役割は「気づかせる」ことに限定しています。例えば記事の公開設定を切り替えたりするような、記事の公開を止める権限はAIには持たせていません。
Few-shot Examplesで境界線を伝える
判定原則をテキストで説明するだけでは、AIに検出の境界線は十分に伝わりません。プロンプトには4パターン以上のFew-shot Examplesを含めています。
// ALERT例: 認証情報らしき文字列の検出
{
"status": "ALERT",
"alerts": [{
"type": "機密情報",
"severity": "critical",
"quote": "prod_token_7f3a9c...",
"reason": "本番環境の認証情報らしき文字列。実際のトークンや秘密情報である可能性があり、漏洩リスクが高いため確認が必要"
}]
}
// SAFE例: 難易度に言及しているだけで、人を貶めていない
{
"status": "SAFE",
"alerts": []
}
Few-shotで見せているのは「この表現はALERT/SAFE」という正解ラベルだけではありません。reasonフィールドに「なぜ問題なのか」の説明を含めることで、AIが判定の一貫性を保ちやすくなるようにしています。
Exampleでは、機密情報の検出や攻撃的批判、SAFEケースなど複数のカテゴリをカバーしており、カテゴリごとに検出の温度感を示しています。
運用して見えてきたこと
2026年2月の導入以降、約20件の記事に対してこの仕組みを運用しています。そのうちALERTが出たのは4〜5件です。例えば、記事内の写真に対して肖像権の確認を求める検出や、コード例に含まれる環境変数の参照をAPIキーの露出として検出するケースがありました。いずれも確認した上で「問題なし」と判断しています。
やや過剰な検出ではありますが、「見逃すよりは拾う」という設計方針通りの動きです。対処が必要なALERTはまだ発生しておらず、事前の承認フローなしでも運用上の問題は起きていません。
ただ、この仕組みの価値は「ALERTが出たときに対処する」ことだけではありません。すべての記事に対して自動でレビューが走り、その結果がSlackに流れること自体に意味があります。技術広報の担当者が公開された記事に目を通す「きっかけ」としても強く機能しているのです。品質フィードバックの内容を見て「この記事にはこういう良さがあるんだ」と気づくこともあり、自動レビューが記事を読む習慣づくりのツールとしても役立っています。
おわりに
この仕組みは、GENDA Creators Blogが「個人の発信を集約する」形態だからこそ選んだ設計です。メディアの目的や運用体制によって、最適なチェックフローは変わります。今回のケースでは、書き手の体験に手を加えずに裏側で品質管理を実現することが最も重要でした。日頃からn8nやAIサービスの運用に触れていたことで、こうした「仕組みで解決する」発想に自然とたどり着けたのだと思います。
モデルの性能が上がり続けるなかで、いずれは「人間の確認を経ずにAIが判断する」という選択肢も現実的になるかもしれません。ただ最終的にその判断を下すのもまた人間の仕事なので、今はまだこの形がちょうどいいと感じています。
付録: プロンプトの骨格
検出パターンやFew-shot Examplesは各企業の状況・考え方に依存する内容を多く含むため、それぞれでプロンプトを構築する必要があります。ここでは、その際のヒントになるよう、本文で解説した設計思想に基づくプロンプトの骨格を掲載します。自社の文脈に合わせて肉付けしてください。特にFew-shot Examplesは、自社で過去に問題になった表現や業界特有のリスクパターンを含めると検出精度が上がります。
Critical Risk Checker
Role
[門番としての役割定義]
[事後チェックである前提と、出力トーンの指示]
検出対象
1. [カテゴリ名]
[検出すべきパターンを具体的に列挙]
2〜5. [同様に各カテゴリを定義]
検出しないもの
[対象外とするものを明示し、他エージェントとの責務境界を定義]
判定原則
[「意図ではなく見え方で判定する」等の原則を記述]
Few-shot Examples
[ALERT/SAFEの境界線を示す具体例を4パターン以上]
[reasonフィールドに「なぜ問題なのか」を含める]
出力スキーマ
[JSON Schemaによる構造化出力の定義]
Quality Feedback Agent
Role
[建設的なレビュアーとしての役割定義]
[判定（ALERT/SAFE）には関与しないことを明記]
Good Points
[評価観点のカテゴリを定義し、個数の目安を指示]
改善提案
[ポジティブな提案のみ。否定的・命令的な表現を避ける指示]
サマリー
[記事全体の印象を簡潔にまとめる指示]
出力スキーマ
[JSON Schemaによる構造化出力の定義]
Discussion