コラム
実践編 第7回：毎回貼るだけ：ブログリスク低減テンプレ（前提文書＋NGスキャン）【行政書士×開業×AI】
Q：行政書士のブログ文書をAIで速く作ると、断定・誇大・成果保証のような"危ない表現"が混ざりそうで不安です。毎回の安全チェックを仕組みにできま…
<p><strong>Q：行政書士のブログ文書をAIで速く作ると、断定・誇大・成果保証のような"危ない表現"が混ざりそうで不安です。毎回の安全チェックを仕組みにできますか？</strong><br />
<strong>A：</strong>多くの場合、冒頭に貼る「固定前提文書」と、本文を対象にした「NG表現スキャン」をセットにすると、運用のばらつきやリスクを減らしやすくなります。さらにGAS（Apps Script）で"貼る→スキャン→チェック項目追記"まで半自動にすると、確認の抜けを減らしやすくなります。ただし最終判断（根拠確認、守秘、対外表現の安全性）は必ず人が行います。この回ではテンプレ一式とコピペ用プロンプト、編集手順まで作れます。</p>
<hr />
<p>ブログは"速さ"より、事故リスクを減らす運用が先に効きます。開業直後は特に、発信が増えるほど確認が抜けやすくなります。そこで第7回は、毎回コピペで機能する固定前提文書と、危ない表現だけを拾うNGスキャンを「リスクを減らすための工夫」として持つ方法をまとめます。まずは"動く最小構成"から始め、必要に応じて辞書や自動化を育てていきます。速くするほど確認が重要、を前提に進めます。</p>
<hr />
<h2>0 事故らないための前提整理（入力ルール・匿名化・辞書の使い分け）</h2>
<h3>この回で作る「安全装置」一式（固定前提文書＋NGスキャン＋チェック表）</h3>
<p>この回の成果物は、次の3点セットです（いずれも「絶対に安全にする」ではなく、リスクを減らすための仕組みです）。</p>
<ul>
<li><strong>固定前提文書</strong>：ブログ文書の冒頭に毎回貼る「前提の固定」</li>
<li><strong>NG表現スキャン</strong>：断定・誇大・成果保証・誤認リスクの抽出＋言い換え案</li>
<li><strong>公開前チェック項目</strong>：AIを使うほど必要になる、人の最終確認の観点を固定化</li>
</ul>
<p>AIは便利ですが万能ではありません。特に「言い切りの回避」「結果を保証しているように受け取られるおそれのある表現の回避」は、AI任せだと抜けることがあります。速くするほど確認が重要です。</p>
<blockquote>
<p><strong>つまずきポイント：</strong> 最初から"全部自動"にすると止まりやすいです。まずは「固定前提文書＋スキャン＋チェック項目」を回し、あとから自動化を足すのが安全側です。</p>
</blockquote>
<hr />
<h3>入力しない情報の線引き（個人情報・案件特定情報・機微情報）と匿名化ルール</h3>
<p>AIに貼り付けるのは「公開してよい前提の情報」に限ります。次の情報は入力しない運用にします。</p>
<ul>
<li>依頼者の氏名、住所、連絡先、会社名などの固有名詞</li>
<li>相談経緯が特定できる日時・場所・出来事の詳細</li>
<li>未公開の契約条件、金額、交渉内容など機微情報</li>
<li>画像・PDFのスクリーンショット（特定情報が混ざりやすい）</li>
</ul>
<p><strong>匿名化ルール（コピペ用）</strong></p>
<ul>
<li>固有名詞→<code>[依頼者]</code>、<code>[法人]</code>、<code>[地域]</code>、<code>[業務分野]</code> に置換</li>
<li>日付→<code>[時期]</code>（例：2026年2月→「2026年初頭」）</li>
<li>数値→レンジ化（例：3件→「数件」）</li>
<li>事例は「実在の個別案件」と分かる情報を落とし、一般化した説明に寄せる</li>
</ul>
<blockquote>
<p><strong>補足（より安全側）：</strong> 住所・勤務先・家族構成など、単体では弱くても組合せで個人が特定され得る情報も削ります。相談者の同意なく、相談内容を推測できる形で掲載しません。</p>
</blockquote>
<blockquote>
<p><strong>つまずきポイント：</strong> <strong>「一般化したつもりでも、地域＋時期＋出来事の組合せで特定される」</strong> ことがあります。迷ったら削る、が安全側です。</p>
</blockquote>
<hr />
<h3>辞書（Gems／NotebookLM等）に入れるもの・入れないもの（運用の境界線）</h3>
<p>辞書化は便利ですが、入れる情報を間違えると事故の近道になります。</p>
<p><strong>入れるもの（おすすめ）</strong></p>
<ul>
<li>事務所の固定方針（対応範囲、対応姿勢、言い回しの好み）</li>
<li>よく使う注意書き・免責の定型</li>
<li>NG表現辞書（「必ず」「100%」など）</li>
<li>公開済みの自社ブログ文書（自社の言い回し統一に使う）</li>
</ul>
<p><strong>入れないもの（原則）</strong></p>
<ul>
<li>個別案件の固有情報、未公開の依頼者情報、機微情報</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> 辞書に"良さそうな情報"を何でも入れると、後で消せない負債になります。辞書は「公開済み」「一般化できる」「繰り返し使う」から始めると安定します。</p>
</blockquote>
<hr />
<h2>1 ハック① 毎回貼る「固定前提文書」を用意する</h2>
<h3>コピペ用：冒頭に貼る固定前提文書（テンプレ本体）</h3>
<p>まずは「毎回貼るだけ」の固定前提文書を用意します。ここがブレると、スキャンしてもリスクが減りにくくなります。</p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td>【前提（固定）】<br />
本稿は一般情報として作成しています。個別事情の結論は断定しません。<br />
根拠が必要な箇所、要件判断が絡む箇所は「要確認」と明示します。<br />
誇大表現・成果保証・断定を避け、「一般的には」「場合によっては」等で安全側に寄せます。<br />
最終的な判断（法的判断・要件判断・対外表現の安全性・守秘/個人情報の扱い）は人が行います。<br />
公開前に「公開前チェック項目」を付けます。<br />
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 制度解説、手続の流れ、報酬の考え方、実績・クチコミ紹介など、ほぼ全てのブログ文書</p>
<p><strong>入力時の注意（匿名化）：</strong> 固定前提文書は"固定"なので、依頼者情報や具体事例は混ぜません。</p>
<p><strong>NG例（やりがちな悪い入力）：</strong> 「【前提】A社（実名）の案件について一般情報として作成」 → 固定前提文書に固有名詞を混ぜると、守秘・特定のリスクが上がります。</p>
<hr />
<h3>使いどころ：どの種類のブログ文書にも効く"固定"の考え方</h3>
<p>固定前提文書が効く理由は、「本文の出来に依存しない前提の固定」になるからです。AIで作る文書は回ごとに揺れますが、固定前提文書が毎回同じであれば、最低限の安全側の姿勢を外しにくくなります。</p>
<blockquote>
<p><strong>つまずきポイント：</strong> 固定前提文書を"記事ごとに最適化"し始めると、固定でなくなります。固定は固定のままにし、調整は本文側で行うほうが運用が安定します。</p>
</blockquote>
<hr />
<h3>つまずきポイント：前提文書が長くなりすぎる問題と短縮のコツ</h3>
<p>短縮の目安は「5行前後」です。削る優先順位は次の順がおすすめです。</p>
<ul>
<li><strong>残す：</strong> 一般情報／断定しない／要確認明示／最終判断は人／公開前チェック</li>
<li><strong>削る：</strong> 細かな例外の列挙（例外は本文側、または公開前チェック項目に逃がす）</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> 前提文書が長いほど読まれません。長くなりそうなら「公開前チェック項目」に分離し、固定前提文書は短く保ちます。</p>
</blockquote>
<hr />
<h2>2 ハック② 「断定／誇大／成果保証」だけを自動スキャンする</h2>
<h3>危ない表現のカテゴリ分け（断定・誇大・成果保証・誤認リスク）</h3>
<p>スキャン対象をカテゴリで固定すると、迷いが減ります。 ※本稿では便宜上「成果保証」と表現しますが、意図としては「結果を保証しているように受け取られるおそれのある表現」を指します。</p>
<ul>
<li><strong>断定：</strong> 必ず、絶対、〜に違いない</li>
<li><strong>誇大：</strong> 日本一、最強、どこよりも、完全に、地域No.1</li>
<li><strong>成果保証：</strong> 必ず通る、100%解決、確実に取れる</li>
<li><strong>誤認リスク：</strong> 条件を省いて一般化、例外を落として断言、格安・最安を根拠なしに示す</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> AIは読みやすさのために強い言い回しを提案しがちです。読みやすさより、まず安全側です。</p>
</blockquote>
<hr />
<h3>コピペ用：危ない表現スキャン用プロンプト（抽出＋言い換え案）</h3>
<p>長いブログ文書では一度に「全文修正」まで要求すると出力が膨らみやすいです。そこで、<strong>①スキャン（軽量）→②全文反映（必要なときだけ）</strong> の2段階にします。</p>
<p><strong>コピペ用プロンプト①（軽量：スキャン＋言い換え案＋要確認）</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td>
<p>あなたは行政書士事務所の編集チェック担当です。<br />
次の【ブログ文書】を対象に、「断定／誇大／成果保証／誤認リスク」をスキャンしてください。<br />
法的助言ではなく一般的な情報提供として整え、個別案件の結論は示さないでください。</p>
<p># 最重要方針<br />
- 不確かな箇所・根拠が必要な箇所は推測せず「要確認」と明示する<br />
- 実績・クチコミ・数値は、結果を保証しているように受け取られるおそれがないよう前提（期間・対象・分母・同意）を添える提案をする<br />
- 固有名詞・具体的な日時・住所など、個人が特定され得る情報は使わない（入力に含まれている前提であっても、出力には出さない）</p>
<p># 出力形式（最大20件、重要度順）<br />
1) 危ない表現の候補<br />
- 抜粋（前後1文まで）<br />
- リスク分類（断定/誇大/成果保証/誤認リスク）<br />
- なぜ危ないか（1行）<br />
- 安全側の言い換え案（1〜2案）<br />
2) 「要確認」一覧（根拠・前提が不足している箇所）</p>
<p>---【ブログ文書】---<br />
（ここに本文を貼り付け）</p>
</td>
</tr>
</tbody>
</table>
<p><strong>コピペ用プロンプト②（必要時：指摘を反映した全文）</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td>
<p>上の指摘（危ない表現と要確認）を反映し、【ブログ文書】を全文で再作成してください。</p>
<p># 条件<br />
- 冒頭に固定前提文書を残す<br />
- 末尾に「公開前チェック項目」を10個付ける<br />
- 個別事情の結論は断定しない<br />
- 根拠が必要な箇所は「要確認」を明示する<br />
- 実績・クチコミ・数値は、前提（期間・対象・分母・同意）を添え、結果保証に見えないようにする<br />
- 固有名詞・具体的な日時・住所など、個人が特定され得る情報は出力しない</p>
<p>---【ブログ文書】---<br />
（ここに本文を貼り付け）</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 公開前の最終チェック、または公開後のリライト時（過去ブログ文書の棚卸し）</p>
<p><strong>入力時の注意（匿名化）：</strong> 貼り付け前に、固有名詞や相談経緯が混ざっていないか目視します。</p>
<p><strong>NG例（やりがちな悪い入力）：</strong> 「A社（実名）の許可が必ず通った手順をそのまま貼ります。担当者名は○○です。」 → 案件特定・個人情報・結果保証に見える表現が混ざり危険です。一般化・匿名化が必要です。</p>
<hr />
<h3>つまずきポイント：言い換えが"弱すぎる／強すぎる"ときの調整方法（追いプロンプト）</h3>
<p>AIの言い換えが極端なときは、追いプロンプトで軸を戻します。</p>
<pre>
<code>上の指摘を踏まえて再編集してください。
</code></pre>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td># 条件<br />
- 訴求（読者メリット）は残す。ただし結果保証に見える語は使わない<br />
- 条件・前提が必要な箇所は「一般的には」「場合によっては」「要確認」で安全側に寄せる<br />
- 修正後の【ブログ文書】を全文で出す（冒頭の固定前提文書と末尾の公開前チェック項目も含める）<br />
- 相談導線（問い合わせ等）を入れる場合は、できること／できないことをセットで書く</td>
</tr>
</tbody>
</table>
<blockquote>
<p><strong>つまずきポイント：</strong> 追いプロンプトを足しすぎると、指示が衝突してブレます。迷ったら「訴求は残す／結果保証に見える表現は避ける／要確認を付ける」の3点に戻すと整います。</p>
</blockquote>
<hr />
<h2>3 仕組み化：GASで「貼る→スキャン→チェック」を半自動にする</h2>
<h3>構成案：Googleドキュメント／スプレッドシートでの運用フロー（PC前提）</h3>
<p>おすすめは次のどちらかです。</p>
<p><strong>A案（軽い）：Googleドキュメント1本で完結</strong></p>
<ul>
<li>冒頭に固定前提文書</li>
<li>スクリプトでNG辞書を走査→末尾に結果とチェック項目を追記</li>
</ul>
<p><strong>B案（育つ）：スプレッドシートでNG辞書を管理＋ドキュメントで執筆</strong></p>
<ul>
<li>NG表現、カテゴリ、言い換え方針を辞書化</li>
<li>チェック結果が資産として積み上がる</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> 最初からB案を作り込むと、辞書設計で止まりがちです。まずA案で回し、NG辞書が増えてきたらB案へ移すほうが安全側です。</p>
</blockquote>
<hr />
<h3>PC手順：GASの基本配置（スキャン実行・結果の出力先・ログ）</h3>
<p>ここではA案（ドキュメント完結）を例にします。UI表示名は更新される可能性があります。</p>
<p><strong>PC手順</strong></p>
<ol>
<li>Googleドキュメントで「ブログ文書テンプレ」用の文書を新規作成します</li>
<li>冒頭に「固定前提文書」を貼ります（前章のテンプレ）</li>
<li>メニューから <strong>拡張機能 → Apps Script</strong> を開きます（表示名は環境で異なる場合があります）</li>
<li>下のコードを貼り付けて保存します</li>
<li>文書を再読み込みします</li>
<li>上部メニューに追加された <strong>「ブログ安全チェック」→「NGスキャンを実行」</strong> をクリックします</li>
</ol>
<blockquote>
<p><strong>つまずきポイント（回避策）：</strong> 初回実行時は権限許可が必要です。許可画面が出ない・進まない場合は、文書の再読み込み、別ブラウザ、別Googleアカウントの誤ログイン確認を行うと解消することがあります（環境差があります）。また、GASには実行時間や呼び出し回数などの制限があり、仕様変更・制限値の見直しがあり得ます。動かない場合は、最新の公式情報も確認してください。</p>
</blockquote>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td>
<p>/**<br />
* ブログ安全チェック（冪等版）<br />
* - 既存レポートを消してから再生成（結果の増殖を防止）<br />
* - 段落番号＋抜粋つきでヒットを列挙<br />
* - 例外（除外）ルールに対応<br />
* - ヒットが多すぎる場合は打ち切り（暴発防止）<br />
*/<br />
const REPORT_MARKER = '===BLOG_SAFETY_REPORT_START===';</p>
<p>function onOpen() {<br />
DocumentApp.getUi()<br />
.createMenu('ブログ安全チェック')<br />
.addItem('NGスキャンを実行', 'scanNg')<br />
.addToUi();<br />
}</p>
<p>function scanNg() {<br />
const ui = DocumentApp.getUi();<br />
try {<br />
const doc = DocumentApp.getActiveDocument();<br />
const body = doc.getBody();</p>
<p> // 1) 既存レポート削除（冪等）<br />
removeOldReport_(body);</p>
<p> // 2) NG辞書（最小例。運用で増やす）<br />
// word: 検知語, cat: 分類, suggest: 修正方針<br />
const ngList = [<br />
{ word: '必ず', cat: '断定', suggest: '「一般的には」「場合によっては」等に寄せ、条件や前提を補う' },<br />
{ word: '絶対', cat: '断定', suggest: '言い切りを避け、条件付き表現にする' },<br />
{ word: '100%', cat: '成果保証', suggest: '結果保証に見えるため避け、前提・範囲・例外を明示（統計は出典も要確認）' },<br />
{ word: '確実', cat: '成果保証', suggest: '「可能性がある」「傾向がある」等に寄せ、要確認を付ける' },<br />
{ word: '日本一', cat: '誇大', suggest: '比較根拠がない限り避け、事実ベースの表現にする' },<br />
{ word: '最強', cat: '誇大', suggest: '根拠が示せない場合は避け、説明対象の範囲を明示する' },<br />
{ word: '地域No.1', cat: '誇大', suggest: '根拠（調査主体・期間・比較対象）なしでは避ける' },<br />
{ word: '最安', cat: '誤認リスク', suggest: '比較条件が必要。根拠がなければ避けるか、条件・範囲を明示' },<br />
{ word: '格安', cat: '誤認リスク', suggest: '価格の前提（範囲・条件）を明示。誤認が出るなら避ける' },<br />
{ word: '最短', cat: '誤認リスク', suggest: '条件（時期・混雑・追加資料）を添えて誤認を避ける' }<br />
];</p>
<p> // 3) 例外（除外）ルール：誤検知を減らす（必要に応じて追加）<br />
// 例：「必ずしも」「100%OFF」など<br />
const excludePatterns = [<br />
/必ずしも/g,<br />
/100%OFF/gi<br />
];</p>
<p> // 4) 本文を段落単位でスキャン<br />
const paras = body.getParagraphs();<br />
const hits = [];<br />
const HIT_LIMIT = 200; // 暴発防止（必要なら運用で調整）</p>
<p> for (let idx = 0; idx < paras.length; idx++) {<br />
const t = paras[idx].getText();<br />
if (!t) continue;</p>
<p> const masked = maskExcluded_(t, excludePatterns);</p>
<p> for (let j = 0; j < ngList.length; j++) {<br />
const item = ngList[j];<br />
const re = new RegExp(escapeRegExp_(item.word), 'g');<br />
let m;<br />
while ((m = re.exec(masked)) !== null) {<br />
hits.push({<br />
cat: item.cat,<br />
word: item.word,<br />
paraNo: idx + 1,<br />
excerpt: excerpt_(t, m.index, item.word.length),<br />
suggest: item.suggest<br />
});<br />
if (hits.length >= HIT_LIMIT) break;<br />
}<br />
if (hits.length >= HIT_LIMIT) break;<br />
}<br />
if (hits.length >= HIT_LIMIT) break;<br />
}</p>
<p> // 5) レポート生成（末尾に追記）<br />
const stamp = Utilities.formatDate(new Date(), Session.getScriptTimeZone(), 'yyyy-MM-dd HH:mm');<br />
const summary = summarize_(hits);</p>
<p> const lines = [];<br />
lines.push(REPORT_MARKER);<br />
lines.push(`【NGスキャン結果】${stamp}`);<br />
lines.push(`- ヒット件数：${hits.length}（断定:${summary.dantei} / 誇大:${summary.kodai} / 成果保証:${summary.seikahosho} / 誤認リスク:${summary.gonin}）`);<br />
lines.push('');</p>
<p> if (!hits.length) {<br />
lines.push('- 該当なし（ただし最終確認は人が実施）');<br />
} else {<br />
const limited = hits.slice(0, 50); // 表示は50件まで（読みやすさ優先）<br />
limited.forEach((h, i) => {<br />
lines.push(`${i + 1}. [${h.cat}] 「${h.word}」 段落${h.paraNo}`);<br />
lines.push(` 抜粋：${h.excerpt}`);<br />
lines.push(` 修正方針：${h.suggest}`);<br />
});<br />
if (hits.length > limited.length) {<br />
lines.push('');<br />
lines.push(`※表示は${limited.length}件までです。ヒットが多い場合は文書を分割してスキャンしてください。`);<br />
}<br />
if (hits.length >= HIT_LIMIT) {<br />
lines.push('');<br />
lines.push('※ヒット件数が多いため途中で打ち切りました。文書を分割して再実行してください。');<br />
}<br />
}</p>
<p> lines.push('');<br />
lines.push('【公開前チェック項目】（毎回ここを確認）');<br />
lines.push('1. 個人情報・案件特定情報・機微情報が含まれていない（組合せで特定され得る情報も含む）');<br />
lines.push('2. 個別事情の結論を断定していない（条件が必要なら明示）');<br />
lines.push('3. 根拠が必要な箇所に「要確認」または根拠メモがある');<br />
lines.push('4. 誇大表現・結果保証に見える語が残っていない');<br />
lines.push('5. 例外や注意点を落として一般化していない');<br />
lines.push('6. 要件・期間・必要書類などが古くなる可能性に配慮している');<br />
lines.push('7. 実績・クチコミは前提（期間・対象・分母・同意）を添えている（加工・創作がある場合はその旨を明示）');<br />
lines.push('8. 読者が誤解しやすい箇所に補足がある');<br />
lines.push('9. 事務所の対応範囲と矛盾がない');<br />
lines.push('10. 最後に免責があり、対外表現として安全側に寄っている');</p>
<p> body.appendParagraph(lines.join('\n'));<br />
ui.alert('NGスキャンが完了しました。末尾に結果を追記しました。');<br />
} catch (e) {<br />
ui.alert(`NGスキャンでエラーが発生しました。\n原因：${e && e.message ? e.message : e}`);<br />
}<br />
}</p>
<p>function removeOldReport_(body) {<br />
const paras = body.getParagraphs();<br />
let markerIndex = -1;<br />
for (let i = 0; i < paras.length; i++) {<br />
if (paras[i].getText().indexOf(REPORT_MARKER) !== -1) {<br />
markerIndex = i;<br />
break;<br />
}<br />
}<br />
if (markerIndex === -1) return;</p>
<p> for (let i = paras.length - 1; i >= markerIndex; i--) {<br />
body.removeChild(paras[i]);<br />
}<br />
}</p>
<p>function maskExcluded_(text, excludePatterns) {<br />
let out = text;<br />
excludePatterns.forEach(re => {<br />
out = out.replace(re, (m) => '□'.repeat(m.length));<br />
});<br />
return out;<br />
}</p>
<p>function escapeRegExp_(s) {<br />
return s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');<br />
}</p>
<p>function excerpt_(text, index, len) {<br />
const start = Math.max(0, index - 20);<br />
const end = Math.min(text.length, index + len + 20);<br />
return text.substring(start, end).replace(/\s+/g, ' ').trim();<br />
}</p>
<p>function summarize_(hits) {<br />
const res = { dantei: 0, kodai: 0, seikahosho: 0, gonin: 0 };<br />
hits.forEach(h => {<br />
if (h.cat === '断定') res.dantei++;<br />
else if (h.cat === '誇大') res.kodai++;<br />
else if (h.cat === '成果保証') res.seikahosho++;<br />
else res.gonin++;<br />
});<br />
return res;<br />
}</p>
</td>
</tr>
</tbody>
</table>
<hr />
<h3>スマホ手順（補足）：閲覧・軽微修正までに絞った運用（画面差分の注意）</h3>
<p>スマホは「実行」より「確認」に寄せると安定します。</p>
<ol>
<li>Googleドキュメントアプリで該当文書を開きます</li>
<li>冒頭に固定前提文書があるか確認します</li>
<li>末尾に「NGスキャン結果」と「公開前チェック項目」が追記されているか確認します</li>
<li>誤字や言い過ぎを軽微修正し、最終確認はPCで行います</li>
</ol>
<blockquote>
<p><strong>つまずきポイント：</strong> スマホはApps Script編集や実行導線がPCと異なり、できる範囲が限られることがあります。PC主導で設計し、スマホは確認中心にするのが無難です。</p>
</blockquote>
<hr />
<h2>4 実績・クチコミ・強みを"安全に"載せる（実績が少ない時期の代替も用意）</h2>
<h3>実績・クチコミの文書で注意すべき表現（結果保証に見えない前提の添え方）</h3>
<p>実績・クチコミは安心材料になり得ます。ただし、次の情報を短く添えると誤認を減らしやすくなります。</p>
<ul>
<li>期間（例：2026年初頭〜）</li>
<li>対象（例：同意が得られた範囲）</li>
<li>分母（例：全件ではなく一部の紹介）</li>
<li>結果保証ではない旨（固定前提文書で担保）</li>
</ul>
<p>加えて、守秘・個人情報の観点で次も明示すると安全側になります。</p>
<ul>
<li>同意を得た事例のみ掲載する</li>
<li>ケース紹介は事実の範囲に限定する</li>
<li>フィクション・加工がある場合は、その旨を明示する</li>
</ul>
<p><strong>言い回し例（安全側）</strong></p>
<ul>
<li>×「必ず許可が取れます」</li>
<li>○「一般的にはこの流れで進みますが、個別事情で変わるため要確認です」</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> 「良い話だけ」だと誤認誘発に寄ることがあります。前提（期間・対象・分母・同意）を添えるだけでも、受け取られ方が変わります。</p>
</blockquote>
<hr />
<h3>実績が少ない場合の代替安心材料（経歴・学び・専門テーマ・活動の蓄積）</h3>
<p>開業前後で実績が少ない・ないのは珍しくありません。その場合は、実績以外の安心材料を積み上げます。</p>
<ul>
<li><strong>学び：</strong> 研修・講座・勉強会（一般化して記載）</li>
<li><strong>専門テーマ：</strong> 取り扱い予定の分野、調査・整理の蓄積</li>
<li><strong>地域性：</strong> 地域の制度・窓口・実務の導線理解</li>
<li><strong>活動：</strong> ブログ更新の継続、FAQの整備、用語集の作成</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> 安心材料を増やそうとして誇大表現に寄りがちです。NGスキャンの対象に含め、強い語が出たら条件・前提を足して安全側に寄せます。</p>
</blockquote>
<hr />
<h3>強みが分からない場合：AI壁打ちで整理・言語化する手順（最終決定は人）</h3>
<p>「強みが分からない」はよく起こります。AIは整理と候補出しには役立ちますが、採否は人が握ります。</p>
<p><strong>手順（PC）</strong></p>
<ol>
<li>経歴・経験・得意を箇条書きで出します（特定情報は入れない）</li>
<li>AIに「強み候補」と「読者メリット」を出させます</li>
<li>違和感があるものを落とし、言い回しを自分の言葉に寄せます</li>
<li>固定前提文書＋NGスキャンを通します</li>
</ol>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td>
<p>次のメモから、行政書士事務所としての「強み候補」を3〜5個に整理してください。<br />
- 誇大表現や結果保証に見える表現は避ける<br />
- 強みは「読者メリット（何が助かるか）」まで一文で示す<br />
- 最後に、強みをブログ文書に載せるときの注意点を5つ出す</p>
<p>---メモ---<br />
（匿名化したメモを貼る）</p>
</td>
</tr>
</tbody>
</table>
<blockquote>
<p><strong>つまずきポイント：</strong> AIが「刺さる表現」を優先して強めに言いがちです。強みは盛ることではなく、継続できる説明に寄せます。</p>
</blockquote>
<hr />
<h2>5 公開前チェック：速くするほど確認が重要（人が担う最終判断）</h2>
<h3>公開前チェック項目（事実・根拠・守秘・対外表現の安全性）</h3>
<p>固定前提文書とセットで、毎回これを確認します（10項目例）。</p>
<ol>
<li>個人情報・案件特定情報・機微情報が入っていない（組合せで特定され得る情報も含む）</li>
<li>結論の断定になっていない（条件がある箇所は明示）</li>
<li>根拠が必要な箇所に「要確認」または根拠メモがある</li>
<li>誇大表現・結果保証に見える語がない（スキャン結果も確認）</li>
<li>例外や注意点を落として一般化していない</li>
<li>手続・要件・期間などは古くなる可能性がある旨に配慮している</li>
<li>実績・クチコミは前提（期間・対象・分母・同意）を添えている（加工・創作がある場合は明示）</li>
<li>読者が誤解しやすい箇所に補足がある</li>
<li>事務所の対応範囲と矛盾がない</li>
<li>免責があり、対外表現として安全側に寄っている</li>
</ol>
<blockquote>
<p><strong>つまずきポイント：</strong> チェック項目を"読まずにOKにする"と形骸化します。毎回、最低でも「1・2・3・4」だけは指差し確認する運用にすると効きます。</p>
</blockquote>
<hr />
<h3>NGが出たときの編集ルール（短縮・整形・言い過ぎ回避・導線強化）</h3>
<p>NGが見つかったら、次の順で直すと迷いません。</p>
<ol>
<li><strong>言い切りを外す：</strong> 「〜に違いない」→「一般的には〜」「場合によっては〜」</li>
<li><strong>条件を足す：</strong> 誰にでも当てはまるように見える箇所→条件・前提を一文追加</li>
<li><strong>要確認を付ける：</strong> 根拠が揃わない箇所→「要確認」明示</li>
<li><strong>短縮する：</strong> 長文で誤認を生みやすい→要点だけ残す</li>
<li><strong>導線を整える：</strong> 相談導線は「できること／できないこと」をセットで書く</li>
</ol>
<blockquote>
<p><strong>つまずきポイント：</strong> 修正で訴求が消えたら、追いプロンプトで「訴求は残す／結果保証に見える表現は避ける／要確認を付ける」に戻して再編集すると整います。</p>
</blockquote>
<hr />
<h3>つまずきポイント：AIの指摘が過剰／不足なときの"確認観点"</h3>
<p><strong>過剰（何でもNG扱い）なとき：</strong></p>
<ul>
<li>「一般情報としての説明」と「個別案件の結論」を分けて見直します</li>
<li>"禁止"ではなく"条件を足す"で解決できないか確認します</li>
</ul>
<p><strong>不足（見落とす）なとき：</strong></p>
<ul>
<li>「必ず」「確実」「100%」「最短」「完全」「最強」など強い語を目視でも拾います</li>
<li>実績・クチコミ周りは前提不足がないか、人の目で再確認します</li>
</ul>
<hr />
<h2>6 まとめ（運用を止めずに安全を積み上げる）</h2>
<h3>まとめ：固定前提文書＋NGスキャンでブログ運用が安定する理由</h3>
<p>ブログ運用は、速さより「リスクを減らす仕組み」が先に効きます。毎回貼る固定前提文書で土台を揃え、NGスキャンで危ない表現だけを拾い、公開前チェック項目で人の最終確認を固定化すると、運用のばらつきやリスクを減らしやすくなります。自動化（GAS）は"最後のひと押し"として、止まらない範囲から始めるのが現実的です。</p>
<p>なお、今回の固定前提文書・スキャン用プロンプト・GASコード自体もAIに作成してもらうことは可能です。ただし本番運用では要件定義・テスト・改修の品質管理が重要になるため、"AIに作成してもらい、それを安全に動かす手順"は実践編（応用）で扱います。</p>
<hr />
<h2>免責</h2>
<p>本記事は一般情報であり、個別案件の法的判断・要件判断・対外表現の安全性を保証するものではありません。AI活用は便利ですが、速くするほど確認が重要です。公開可否の最終判断（根拠確認、守秘、個人情報の扱い等）は必ず人が行ってください。また、本稿は行政書士事務所の運用例であり、他業種の広告規制等にそのまま適用できるとは限りません。所属する行政書士会の広告に関する規程・指針等がある場合は、それも確認してください。</p>
<hr />
<h2>HANAWA行政書士事務所</h2>
<p><a href="https://hanawa-office.jp/">HANAWA行政書士事務所公式サイト</a></p>
<p><a href="https://hanawa-office.jp/AI_knowledge/index.php">AI活用学習サイト</a></p>
<p><a href="https://hanawa-office.jp/blog_detail.php?id=482">前の記事：実践編 第6回：NotebookLMで「事務所の独自辞書」を作り、根拠つきの文書下書きを速く作る手順</a></p>
<p> </p>
<strong>A：</strong>多くの場合、冒頭に貼る「固定前提文書」と、本文を対象にした「NG表現スキャン」をセットにすると、運用のばらつきやリスクを減らしやすくなります。さらにGAS（Apps Script）で"貼る→スキャン→チェック項目追記"まで半自動にすると、確認の抜けを減らしやすくなります。ただし最終判断（根拠確認、守秘、対外表現の安全性）は必ず人が行います。この回ではテンプレ一式とコピペ用プロンプト、編集手順まで作れます。</p>
<hr />
<p>ブログは"速さ"より、事故リスクを減らす運用が先に効きます。開業直後は特に、発信が増えるほど確認が抜けやすくなります。そこで第7回は、毎回コピペで機能する固定前提文書と、危ない表現だけを拾うNGスキャンを「リスクを減らすための工夫」として持つ方法をまとめます。まずは"動く最小構成"から始め、必要に応じて辞書や自動化を育てていきます。速くするほど確認が重要、を前提に進めます。</p>
<hr />
<h2>0 事故らないための前提整理（入力ルール・匿名化・辞書の使い分け）</h2>
<h3>この回で作る「安全装置」一式（固定前提文書＋NGスキャン＋チェック表）</h3>
<p>この回の成果物は、次の3点セットです（いずれも「絶対に安全にする」ではなく、リスクを減らすための仕組みです）。</p>
<ul>
<li><strong>固定前提文書</strong>：ブログ文書の冒頭に毎回貼る「前提の固定」</li>
<li><strong>NG表現スキャン</strong>：断定・誇大・成果保証・誤認リスクの抽出＋言い換え案</li>
<li><strong>公開前チェック項目</strong>：AIを使うほど必要になる、人の最終確認の観点を固定化</li>
</ul>
<p>AIは便利ですが万能ではありません。特に「言い切りの回避」「結果を保証しているように受け取られるおそれのある表現の回避」は、AI任せだと抜けることがあります。速くするほど確認が重要です。</p>
<blockquote>
<p><strong>つまずきポイント：</strong> 最初から"全部自動"にすると止まりやすいです。まずは「固定前提文書＋スキャン＋チェック項目」を回し、あとから自動化を足すのが安全側です。</p>
</blockquote>
<hr />
<h3>入力しない情報の線引き（個人情報・案件特定情報・機微情報）と匿名化ルール</h3>
<p>AIに貼り付けるのは「公開してよい前提の情報」に限ります。次の情報は入力しない運用にします。</p>
<ul>
<li>依頼者の氏名、住所、連絡先、会社名などの固有名詞</li>
<li>相談経緯が特定できる日時・場所・出来事の詳細</li>
<li>未公開の契約条件、金額、交渉内容など機微情報</li>
<li>画像・PDFのスクリーンショット（特定情報が混ざりやすい）</li>
</ul>
<p><strong>匿名化ルール（コピペ用）</strong></p>
<ul>
<li>固有名詞→<code>[依頼者]</code>、<code>[法人]</code>、<code>[地域]</code>、<code>[業務分野]</code> に置換</li>
<li>日付→<code>[時期]</code>（例：2026年2月→「2026年初頭」）</li>
<li>数値→レンジ化（例：3件→「数件」）</li>
<li>事例は「実在の個別案件」と分かる情報を落とし、一般化した説明に寄せる</li>
</ul>
<blockquote>
<p><strong>補足（より安全側）：</strong> 住所・勤務先・家族構成など、単体では弱くても組合せで個人が特定され得る情報も削ります。相談者の同意なく、相談内容を推測できる形で掲載しません。</p>
</blockquote>
<blockquote>
<p><strong>つまずきポイント：</strong> <strong>「一般化したつもりでも、地域＋時期＋出来事の組合せで特定される」</strong> ことがあります。迷ったら削る、が安全側です。</p>
</blockquote>
<hr />
<h3>辞書（Gems／NotebookLM等）に入れるもの・入れないもの（運用の境界線）</h3>
<p>辞書化は便利ですが、入れる情報を間違えると事故の近道になります。</p>
<p><strong>入れるもの（おすすめ）</strong></p>
<ul>
<li>事務所の固定方針（対応範囲、対応姿勢、言い回しの好み）</li>
<li>よく使う注意書き・免責の定型</li>
<li>NG表現辞書（「必ず」「100%」など）</li>
<li>公開済みの自社ブログ文書（自社の言い回し統一に使う）</li>
</ul>
<p><strong>入れないもの（原則）</strong></p>
<ul>
<li>個別案件の固有情報、未公開の依頼者情報、機微情報</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> 辞書に"良さそうな情報"を何でも入れると、後で消せない負債になります。辞書は「公開済み」「一般化できる」「繰り返し使う」から始めると安定します。</p>
</blockquote>
<hr />
<h2>1 ハック① 毎回貼る「固定前提文書」を用意する</h2>
<h3>コピペ用：冒頭に貼る固定前提文書（テンプレ本体）</h3>
<p>まずは「毎回貼るだけ」の固定前提文書を用意します。ここがブレると、スキャンしてもリスクが減りにくくなります。</p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td>【前提（固定）】<br />
本稿は一般情報として作成しています。個別事情の結論は断定しません。<br />
根拠が必要な箇所、要件判断が絡む箇所は「要確認」と明示します。<br />
誇大表現・成果保証・断定を避け、「一般的には」「場合によっては」等で安全側に寄せます。<br />
最終的な判断（法的判断・要件判断・対外表現の安全性・守秘/個人情報の扱い）は人が行います。<br />
公開前に「公開前チェック項目」を付けます。<br />
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 制度解説、手続の流れ、報酬の考え方、実績・クチコミ紹介など、ほぼ全てのブログ文書</p>
<p><strong>入力時の注意（匿名化）：</strong> 固定前提文書は"固定"なので、依頼者情報や具体事例は混ぜません。</p>
<p><strong>NG例（やりがちな悪い入力）：</strong> 「【前提】A社（実名）の案件について一般情報として作成」 → 固定前提文書に固有名詞を混ぜると、守秘・特定のリスクが上がります。</p>
<hr />
<h3>使いどころ：どの種類のブログ文書にも効く"固定"の考え方</h3>
<p>固定前提文書が効く理由は、「本文の出来に依存しない前提の固定」になるからです。AIで作る文書は回ごとに揺れますが、固定前提文書が毎回同じであれば、最低限の安全側の姿勢を外しにくくなります。</p>
<blockquote>
<p><strong>つまずきポイント：</strong> 固定前提文書を"記事ごとに最適化"し始めると、固定でなくなります。固定は固定のままにし、調整は本文側で行うほうが運用が安定します。</p>
</blockquote>
<hr />
<h3>つまずきポイント：前提文書が長くなりすぎる問題と短縮のコツ</h3>
<p>短縮の目安は「5行前後」です。削る優先順位は次の順がおすすめです。</p>
<ul>
<li><strong>残す：</strong> 一般情報／断定しない／要確認明示／最終判断は人／公開前チェック</li>
<li><strong>削る：</strong> 細かな例外の列挙（例外は本文側、または公開前チェック項目に逃がす）</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> 前提文書が長いほど読まれません。長くなりそうなら「公開前チェック項目」に分離し、固定前提文書は短く保ちます。</p>
</blockquote>
<hr />
<h2>2 ハック② 「断定／誇大／成果保証」だけを自動スキャンする</h2>
<h3>危ない表現のカテゴリ分け（断定・誇大・成果保証・誤認リスク）</h3>
<p>スキャン対象をカテゴリで固定すると、迷いが減ります。 ※本稿では便宜上「成果保証」と表現しますが、意図としては「結果を保証しているように受け取られるおそれのある表現」を指します。</p>
<ul>
<li><strong>断定：</strong> 必ず、絶対、〜に違いない</li>
<li><strong>誇大：</strong> 日本一、最強、どこよりも、完全に、地域No.1</li>
<li><strong>成果保証：</strong> 必ず通る、100%解決、確実に取れる</li>
<li><strong>誤認リスク：</strong> 条件を省いて一般化、例外を落として断言、格安・最安を根拠なしに示す</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> AIは読みやすさのために強い言い回しを提案しがちです。読みやすさより、まず安全側です。</p>
</blockquote>
<hr />
<h3>コピペ用：危ない表現スキャン用プロンプト（抽出＋言い換え案）</h3>
<p>長いブログ文書では一度に「全文修正」まで要求すると出力が膨らみやすいです。そこで、<strong>①スキャン（軽量）→②全文反映（必要なときだけ）</strong> の2段階にします。</p>
<p><strong>コピペ用プロンプト①（軽量：スキャン＋言い換え案＋要確認）</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td>
<p>あなたは行政書士事務所の編集チェック担当です。<br />
次の【ブログ文書】を対象に、「断定／誇大／成果保証／誤認リスク」をスキャンしてください。<br />
法的助言ではなく一般的な情報提供として整え、個別案件の結論は示さないでください。</p>
<p># 最重要方針<br />
- 不確かな箇所・根拠が必要な箇所は推測せず「要確認」と明示する<br />
- 実績・クチコミ・数値は、結果を保証しているように受け取られるおそれがないよう前提（期間・対象・分母・同意）を添える提案をする<br />
- 固有名詞・具体的な日時・住所など、個人が特定され得る情報は使わない（入力に含まれている前提であっても、出力には出さない）</p>
<p># 出力形式（最大20件、重要度順）<br />
1) 危ない表現の候補<br />
- 抜粋（前後1文まで）<br />
- リスク分類（断定/誇大/成果保証/誤認リスク）<br />
- なぜ危ないか（1行）<br />
- 安全側の言い換え案（1〜2案）<br />
2) 「要確認」一覧（根拠・前提が不足している箇所）</p>
<p>---【ブログ文書】---<br />
（ここに本文を貼り付け）</p>
</td>
</tr>
</tbody>
</table>
<p><strong>コピペ用プロンプト②（必要時：指摘を反映した全文）</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td>
<p>上の指摘（危ない表現と要確認）を反映し、【ブログ文書】を全文で再作成してください。</p>
<p># 条件<br />
- 冒頭に固定前提文書を残す<br />
- 末尾に「公開前チェック項目」を10個付ける<br />
- 個別事情の結論は断定しない<br />
- 根拠が必要な箇所は「要確認」を明示する<br />
- 実績・クチコミ・数値は、前提（期間・対象・分母・同意）を添え、結果保証に見えないようにする<br />
- 固有名詞・具体的な日時・住所など、個人が特定され得る情報は出力しない</p>
<p>---【ブログ文書】---<br />
（ここに本文を貼り付け）</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 公開前の最終チェック、または公開後のリライト時（過去ブログ文書の棚卸し）</p>
<p><strong>入力時の注意（匿名化）：</strong> 貼り付け前に、固有名詞や相談経緯が混ざっていないか目視します。</p>
<p><strong>NG例（やりがちな悪い入力）：</strong> 「A社（実名）の許可が必ず通った手順をそのまま貼ります。担当者名は○○です。」 → 案件特定・個人情報・結果保証に見える表現が混ざり危険です。一般化・匿名化が必要です。</p>
<hr />
<h3>つまずきポイント：言い換えが"弱すぎる／強すぎる"ときの調整方法（追いプロンプト）</h3>
<p>AIの言い換えが極端なときは、追いプロンプトで軸を戻します。</p>
<pre>
<code>上の指摘を踏まえて再編集してください。
</code></pre>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td># 条件<br />
- 訴求（読者メリット）は残す。ただし結果保証に見える語は使わない<br />
- 条件・前提が必要な箇所は「一般的には」「場合によっては」「要確認」で安全側に寄せる<br />
- 修正後の【ブログ文書】を全文で出す（冒頭の固定前提文書と末尾の公開前チェック項目も含める）<br />
- 相談導線（問い合わせ等）を入れる場合は、できること／できないことをセットで書く</td>
</tr>
</tbody>
</table>
<blockquote>
<p><strong>つまずきポイント：</strong> 追いプロンプトを足しすぎると、指示が衝突してブレます。迷ったら「訴求は残す／結果保証に見える表現は避ける／要確認を付ける」の3点に戻すと整います。</p>
</blockquote>
<hr />
<h2>3 仕組み化：GASで「貼る→スキャン→チェック」を半自動にする</h2>
<h3>構成案：Googleドキュメント／スプレッドシートでの運用フロー（PC前提）</h3>
<p>おすすめは次のどちらかです。</p>
<p><strong>A案（軽い）：Googleドキュメント1本で完結</strong></p>
<ul>
<li>冒頭に固定前提文書</li>
<li>スクリプトでNG辞書を走査→末尾に結果とチェック項目を追記</li>
</ul>
<p><strong>B案（育つ）：スプレッドシートでNG辞書を管理＋ドキュメントで執筆</strong></p>
<ul>
<li>NG表現、カテゴリ、言い換え方針を辞書化</li>
<li>チェック結果が資産として積み上がる</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> 最初からB案を作り込むと、辞書設計で止まりがちです。まずA案で回し、NG辞書が増えてきたらB案へ移すほうが安全側です。</p>
</blockquote>
<hr />
<h3>PC手順：GASの基本配置（スキャン実行・結果の出力先・ログ）</h3>
<p>ここではA案（ドキュメント完結）を例にします。UI表示名は更新される可能性があります。</p>
<p><strong>PC手順</strong></p>
<ol>
<li>Googleドキュメントで「ブログ文書テンプレ」用の文書を新規作成します</li>
<li>冒頭に「固定前提文書」を貼ります（前章のテンプレ）</li>
<li>メニューから <strong>拡張機能 → Apps Script</strong> を開きます（表示名は環境で異なる場合があります）</li>
<li>下のコードを貼り付けて保存します</li>
<li>文書を再読み込みします</li>
<li>上部メニューに追加された <strong>「ブログ安全チェック」→「NGスキャンを実行」</strong> をクリックします</li>
</ol>
<blockquote>
<p><strong>つまずきポイント（回避策）：</strong> 初回実行時は権限許可が必要です。許可画面が出ない・進まない場合は、文書の再読み込み、別ブラウザ、別Googleアカウントの誤ログイン確認を行うと解消することがあります（環境差があります）。また、GASには実行時間や呼び出し回数などの制限があり、仕様変更・制限値の見直しがあり得ます。動かない場合は、最新の公式情報も確認してください。</p>
</blockquote>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td>
<p>/**<br />
* ブログ安全チェック（冪等版）<br />
* - 既存レポートを消してから再生成（結果の増殖を防止）<br />
* - 段落番号＋抜粋つきでヒットを列挙<br />
* - 例外（除外）ルールに対応<br />
* - ヒットが多すぎる場合は打ち切り（暴発防止）<br />
*/<br />
const REPORT_MARKER = '===BLOG_SAFETY_REPORT_START===';</p>
<p>function onOpen() {<br />
DocumentApp.getUi()<br />
.createMenu('ブログ安全チェック')<br />
.addItem('NGスキャンを実行', 'scanNg')<br />
.addToUi();<br />
}</p>
<p>function scanNg() {<br />
const ui = DocumentApp.getUi();<br />
try {<br />
const doc = DocumentApp.getActiveDocument();<br />
const body = doc.getBody();</p>
<p> // 1) 既存レポート削除（冪等）<br />
removeOldReport_(body);</p>
<p> // 2) NG辞書（最小例。運用で増やす）<br />
// word: 検知語, cat: 分類, suggest: 修正方針<br />
const ngList = [<br />
{ word: '必ず', cat: '断定', suggest: '「一般的には」「場合によっては」等に寄せ、条件や前提を補う' },<br />
{ word: '絶対', cat: '断定', suggest: '言い切りを避け、条件付き表現にする' },<br />
{ word: '100%', cat: '成果保証', suggest: '結果保証に見えるため避け、前提・範囲・例外を明示（統計は出典も要確認）' },<br />
{ word: '確実', cat: '成果保証', suggest: '「可能性がある」「傾向がある」等に寄せ、要確認を付ける' },<br />
{ word: '日本一', cat: '誇大', suggest: '比較根拠がない限り避け、事実ベースの表現にする' },<br />
{ word: '最強', cat: '誇大', suggest: '根拠が示せない場合は避け、説明対象の範囲を明示する' },<br />
{ word: '地域No.1', cat: '誇大', suggest: '根拠（調査主体・期間・比較対象）なしでは避ける' },<br />
{ word: '最安', cat: '誤認リスク', suggest: '比較条件が必要。根拠がなければ避けるか、条件・範囲を明示' },<br />
{ word: '格安', cat: '誤認リスク', suggest: '価格の前提（範囲・条件）を明示。誤認が出るなら避ける' },<br />
{ word: '最短', cat: '誤認リスク', suggest: '条件（時期・混雑・追加資料）を添えて誤認を避ける' }<br />
];</p>
<p> // 3) 例外（除外）ルール：誤検知を減らす（必要に応じて追加）<br />
// 例：「必ずしも」「100%OFF」など<br />
const excludePatterns = [<br />
/必ずしも/g,<br />
/100%OFF/gi<br />
];</p>
<p> // 4) 本文を段落単位でスキャン<br />
const paras = body.getParagraphs();<br />
const hits = [];<br />
const HIT_LIMIT = 200; // 暴発防止（必要なら運用で調整）</p>
<p> for (let idx = 0; idx < paras.length; idx++) {<br />
const t = paras[idx].getText();<br />
if (!t) continue;</p>
<p> const masked = maskExcluded_(t, excludePatterns);</p>
<p> for (let j = 0; j < ngList.length; j++) {<br />
const item = ngList[j];<br />
const re = new RegExp(escapeRegExp_(item.word), 'g');<br />
let m;<br />
while ((m = re.exec(masked)) !== null) {<br />
hits.push({<br />
cat: item.cat,<br />
word: item.word,<br />
paraNo: idx + 1,<br />
excerpt: excerpt_(t, m.index, item.word.length),<br />
suggest: item.suggest<br />
});<br />
if (hits.length >= HIT_LIMIT) break;<br />
}<br />
if (hits.length >= HIT_LIMIT) break;<br />
}<br />
if (hits.length >= HIT_LIMIT) break;<br />
}</p>
<p> // 5) レポート生成（末尾に追記）<br />
const stamp = Utilities.formatDate(new Date(), Session.getScriptTimeZone(), 'yyyy-MM-dd HH:mm');<br />
const summary = summarize_(hits);</p>
<p> const lines = [];<br />
lines.push(REPORT_MARKER);<br />
lines.push(`【NGスキャン結果】${stamp}`);<br />
lines.push(`- ヒット件数：${hits.length}（断定:${summary.dantei} / 誇大:${summary.kodai} / 成果保証:${summary.seikahosho} / 誤認リスク:${summary.gonin}）`);<br />
lines.push('');</p>
<p> if (!hits.length) {<br />
lines.push('- 該当なし（ただし最終確認は人が実施）');<br />
} else {<br />
const limited = hits.slice(0, 50); // 表示は50件まで（読みやすさ優先）<br />
limited.forEach((h, i) => {<br />
lines.push(`${i + 1}. [${h.cat}] 「${h.word}」 段落${h.paraNo}`);<br />
lines.push(` 抜粋：${h.excerpt}`);<br />
lines.push(` 修正方針：${h.suggest}`);<br />
});<br />
if (hits.length > limited.length) {<br />
lines.push('');<br />
lines.push(`※表示は${limited.length}件までです。ヒットが多い場合は文書を分割してスキャンしてください。`);<br />
}<br />
if (hits.length >= HIT_LIMIT) {<br />
lines.push('');<br />
lines.push('※ヒット件数が多いため途中で打ち切りました。文書を分割して再実行してください。');<br />
}<br />
}</p>
<p> lines.push('');<br />
lines.push('【公開前チェック項目】（毎回ここを確認）');<br />
lines.push('1. 個人情報・案件特定情報・機微情報が含まれていない（組合せで特定され得る情報も含む）');<br />
lines.push('2. 個別事情の結論を断定していない（条件が必要なら明示）');<br />
lines.push('3. 根拠が必要な箇所に「要確認」または根拠メモがある');<br />
lines.push('4. 誇大表現・結果保証に見える語が残っていない');<br />
lines.push('5. 例外や注意点を落として一般化していない');<br />
lines.push('6. 要件・期間・必要書類などが古くなる可能性に配慮している');<br />
lines.push('7. 実績・クチコミは前提（期間・対象・分母・同意）を添えている（加工・創作がある場合はその旨を明示）');<br />
lines.push('8. 読者が誤解しやすい箇所に補足がある');<br />
lines.push('9. 事務所の対応範囲と矛盾がない');<br />
lines.push('10. 最後に免責があり、対外表現として安全側に寄っている');</p>
<p> body.appendParagraph(lines.join('\n'));<br />
ui.alert('NGスキャンが完了しました。末尾に結果を追記しました。');<br />
} catch (e) {<br />
ui.alert(`NGスキャンでエラーが発生しました。\n原因：${e && e.message ? e.message : e}`);<br />
}<br />
}</p>
<p>function removeOldReport_(body) {<br />
const paras = body.getParagraphs();<br />
let markerIndex = -1;<br />
for (let i = 0; i < paras.length; i++) {<br />
if (paras[i].getText().indexOf(REPORT_MARKER) !== -1) {<br />
markerIndex = i;<br />
break;<br />
}<br />
}<br />
if (markerIndex === -1) return;</p>
<p> for (let i = paras.length - 1; i >= markerIndex; i--) {<br />
body.removeChild(paras[i]);<br />
}<br />
}</p>
<p>function maskExcluded_(text, excludePatterns) {<br />
let out = text;<br />
excludePatterns.forEach(re => {<br />
out = out.replace(re, (m) => '□'.repeat(m.length));<br />
});<br />
return out;<br />
}</p>
<p>function escapeRegExp_(s) {<br />
return s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');<br />
}</p>
<p>function excerpt_(text, index, len) {<br />
const start = Math.max(0, index - 20);<br />
const end = Math.min(text.length, index + len + 20);<br />
return text.substring(start, end).replace(/\s+/g, ' ').trim();<br />
}</p>
<p>function summarize_(hits) {<br />
const res = { dantei: 0, kodai: 0, seikahosho: 0, gonin: 0 };<br />
hits.forEach(h => {<br />
if (h.cat === '断定') res.dantei++;<br />
else if (h.cat === '誇大') res.kodai++;<br />
else if (h.cat === '成果保証') res.seikahosho++;<br />
else res.gonin++;<br />
});<br />
return res;<br />
}</p>
</td>
</tr>
</tbody>
</table>
<hr />
<h3>スマホ手順（補足）：閲覧・軽微修正までに絞った運用（画面差分の注意）</h3>
<p>スマホは「実行」より「確認」に寄せると安定します。</p>
<ol>
<li>Googleドキュメントアプリで該当文書を開きます</li>
<li>冒頭に固定前提文書があるか確認します</li>
<li>末尾に「NGスキャン結果」と「公開前チェック項目」が追記されているか確認します</li>
<li>誤字や言い過ぎを軽微修正し、最終確認はPCで行います</li>
</ol>
<blockquote>
<p><strong>つまずきポイント：</strong> スマホはApps Script編集や実行導線がPCと異なり、できる範囲が限られることがあります。PC主導で設計し、スマホは確認中心にするのが無難です。</p>
</blockquote>
<hr />
<h2>4 実績・クチコミ・強みを"安全に"載せる（実績が少ない時期の代替も用意）</h2>
<h3>実績・クチコミの文書で注意すべき表現（結果保証に見えない前提の添え方）</h3>
<p>実績・クチコミは安心材料になり得ます。ただし、次の情報を短く添えると誤認を減らしやすくなります。</p>
<ul>
<li>期間（例：2026年初頭〜）</li>
<li>対象（例：同意が得られた範囲）</li>
<li>分母（例：全件ではなく一部の紹介）</li>
<li>結果保証ではない旨（固定前提文書で担保）</li>
</ul>
<p>加えて、守秘・個人情報の観点で次も明示すると安全側になります。</p>
<ul>
<li>同意を得た事例のみ掲載する</li>
<li>ケース紹介は事実の範囲に限定する</li>
<li>フィクション・加工がある場合は、その旨を明示する</li>
</ul>
<p><strong>言い回し例（安全側）</strong></p>
<ul>
<li>×「必ず許可が取れます」</li>
<li>○「一般的にはこの流れで進みますが、個別事情で変わるため要確認です」</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> 「良い話だけ」だと誤認誘発に寄ることがあります。前提（期間・対象・分母・同意）を添えるだけでも、受け取られ方が変わります。</p>
</blockquote>
<hr />
<h3>実績が少ない場合の代替安心材料（経歴・学び・専門テーマ・活動の蓄積）</h3>
<p>開業前後で実績が少ない・ないのは珍しくありません。その場合は、実績以外の安心材料を積み上げます。</p>
<ul>
<li><strong>学び：</strong> 研修・講座・勉強会（一般化して記載）</li>
<li><strong>専門テーマ：</strong> 取り扱い予定の分野、調査・整理の蓄積</li>
<li><strong>地域性：</strong> 地域の制度・窓口・実務の導線理解</li>
<li><strong>活動：</strong> ブログ更新の継続、FAQの整備、用語集の作成</li>
</ul>
<blockquote>
<p><strong>つまずきポイント：</strong> 安心材料を増やそうとして誇大表現に寄りがちです。NGスキャンの対象に含め、強い語が出たら条件・前提を足して安全側に寄せます。</p>
</blockquote>
<hr />
<h3>強みが分からない場合：AI壁打ちで整理・言語化する手順（最終決定は人）</h3>
<p>「強みが分からない」はよく起こります。AIは整理と候補出しには役立ちますが、採否は人が握ります。</p>
<p><strong>手順（PC）</strong></p>
<ol>
<li>経歴・経験・得意を箇条書きで出します（特定情報は入れない）</li>
<li>AIに「強み候補」と「読者メリット」を出させます</li>
<li>違和感があるものを落とし、言い回しを自分の言葉に寄せます</li>
<li>固定前提文書＋NGスキャンを通します</li>
</ol>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0;">
<tbody>
<tr>
<td>
<p>次のメモから、行政書士事務所としての「強み候補」を3〜5個に整理してください。<br />
- 誇大表現や結果保証に見える表現は避ける<br />
- 強みは「読者メリット（何が助かるか）」まで一文で示す<br />
- 最後に、強みをブログ文書に載せるときの注意点を5つ出す</p>
<p>---メモ---<br />
（匿名化したメモを貼る）</p>
</td>
</tr>
</tbody>
</table>
<blockquote>
<p><strong>つまずきポイント：</strong> AIが「刺さる表現」を優先して強めに言いがちです。強みは盛ることではなく、継続できる説明に寄せます。</p>
</blockquote>
<hr />
<h2>5 公開前チェック：速くするほど確認が重要（人が担う最終判断）</h2>
<h3>公開前チェック項目（事実・根拠・守秘・対外表現の安全性）</h3>
<p>固定前提文書とセットで、毎回これを確認します（10項目例）。</p>
<ol>
<li>個人情報・案件特定情報・機微情報が入っていない（組合せで特定され得る情報も含む）</li>
<li>結論の断定になっていない（条件がある箇所は明示）</li>
<li>根拠が必要な箇所に「要確認」または根拠メモがある</li>
<li>誇大表現・結果保証に見える語がない（スキャン結果も確認）</li>
<li>例外や注意点を落として一般化していない</li>
<li>手続・要件・期間などは古くなる可能性がある旨に配慮している</li>
<li>実績・クチコミは前提（期間・対象・分母・同意）を添えている（加工・創作がある場合は明示）</li>
<li>読者が誤解しやすい箇所に補足がある</li>
<li>事務所の対応範囲と矛盾がない</li>
<li>免責があり、対外表現として安全側に寄っている</li>
</ol>
<blockquote>
<p><strong>つまずきポイント：</strong> チェック項目を"読まずにOKにする"と形骸化します。毎回、最低でも「1・2・3・4」だけは指差し確認する運用にすると効きます。</p>
</blockquote>
<hr />
<h3>NGが出たときの編集ルール（短縮・整形・言い過ぎ回避・導線強化）</h3>
<p>NGが見つかったら、次の順で直すと迷いません。</p>
<ol>
<li><strong>言い切りを外す：</strong> 「〜に違いない」→「一般的には〜」「場合によっては〜」</li>
<li><strong>条件を足す：</strong> 誰にでも当てはまるように見える箇所→条件・前提を一文追加</li>
<li><strong>要確認を付ける：</strong> 根拠が揃わない箇所→「要確認」明示</li>
<li><strong>短縮する：</strong> 長文で誤認を生みやすい→要点だけ残す</li>
<li><strong>導線を整える：</strong> 相談導線は「できること／できないこと」をセットで書く</li>
</ol>
<blockquote>
<p><strong>つまずきポイント：</strong> 修正で訴求が消えたら、追いプロンプトで「訴求は残す／結果保証に見える表現は避ける／要確認を付ける」に戻して再編集すると整います。</p>
</blockquote>
<hr />
<h3>つまずきポイント：AIの指摘が過剰／不足なときの"確認観点"</h3>
<p><strong>過剰（何でもNG扱い）なとき：</strong></p>
<ul>
<li>「一般情報としての説明」と「個別案件の結論」を分けて見直します</li>
<li>"禁止"ではなく"条件を足す"で解決できないか確認します</li>
</ul>
<p><strong>不足（見落とす）なとき：</strong></p>
<ul>
<li>「必ず」「確実」「100%」「最短」「完全」「最強」など強い語を目視でも拾います</li>
<li>実績・クチコミ周りは前提不足がないか、人の目で再確認します</li>
</ul>
<hr />
<h2>6 まとめ（運用を止めずに安全を積み上げる）</h2>
<h3>まとめ：固定前提文書＋NGスキャンでブログ運用が安定する理由</h3>
<p>ブログ運用は、速さより「リスクを減らす仕組み」が先に効きます。毎回貼る固定前提文書で土台を揃え、NGスキャンで危ない表現だけを拾い、公開前チェック項目で人の最終確認を固定化すると、運用のばらつきやリスクを減らしやすくなります。自動化（GAS）は"最後のひと押し"として、止まらない範囲から始めるのが現実的です。</p>
<p>なお、今回の固定前提文書・スキャン用プロンプト・GASコード自体もAIに作成してもらうことは可能です。ただし本番運用では要件定義・テスト・改修の品質管理が重要になるため、"AIに作成してもらい、それを安全に動かす手順"は実践編（応用）で扱います。</p>
<hr />
<h2>免責</h2>
<p>本記事は一般情報であり、個別案件の法的判断・要件判断・対外表現の安全性を保証するものではありません。AI活用は便利ですが、速くするほど確認が重要です。公開可否の最終判断（根拠確認、守秘、個人情報の扱い等）は必ず人が行ってください。また、本稿は行政書士事務所の運用例であり、他業種の広告規制等にそのまま適用できるとは限りません。所属する行政書士会の広告に関する規程・指針等がある場合は、それも確認してください。</p>
<hr />
<h2>HANAWA行政書士事務所</h2>
<p><a href="https://hanawa-office.jp/">HANAWA行政書士事務所公式サイト</a></p>
<p><a href="https://hanawa-office.jp/AI_knowledge/index.php">AI活用学習サイト</a></p>
<p><a href="https://hanawa-office.jp/blog_detail.php?id=482">前の記事：実践編 第6回：NotebookLMで「事務所の独自辞書」を作り、根拠つきの文書下書きを速く作る手順</a></p>
<p> </p>