コラム

実践編第7回：毎回貼るだけ：ブログリスク低減テンプレ（前提文書＋NGスキャン）【行政書士×開業×AI】

2026年2月25日

Q：行政書士のブログ文書をAIで速く作ると、断定・誇大・成果保証のような"危ない表現"が混ざりそうで不安です。毎回の安全チェックを仕組みにできますか？
A：多くの場合、冒頭に貼る「固定前提文書」と、本文を対象にした「NG表現スキャン」をセットにすると、運用のばらつきやリスクを減らしやすくなります。さらにGAS（Apps Script）で"貼る→スキャン→チェック項目追記"まで半自動にすると、確認の抜けを減らしやすくなります。ただし最終判断（根拠確認、守秘、対外表現の安全性）は必ず人が行います。この回ではテンプレ一式とコピペ用プロンプト、編集手順まで作れます。

ブログは"速さ"より、事故リスクを減らす運用が先に効きます。開業直後は特に、発信が増えるほど確認が抜けやすくなります。そこで第7回は、毎回コピペで機能する固定前提文書と、危ない表現だけを拾うNGスキャンを「リスクを減らすための工夫」として持つ方法をまとめます。まずは"動く最小構成"から始め、必要に応じて辞書や自動化を育てていきます。速くするほど確認が重要、を前提に進めます。

0 事故らないための前提整理（入力ルール・匿名化・辞書の使い分け）

この回で作る「安全装置」一式（固定前提文書＋NGスキャン＋チェック表）

この回の成果物は、次の3点セットです（いずれも「絶対に安全にする」ではなく、リスクを減らすための仕組みです）。

固定前提文書：ブログ文書の冒頭に毎回貼る「前提の固定」
NG表現スキャン：断定・誇大・成果保証・誤認リスクの抽出＋言い換え案
公開前チェック項目：AIを使うほど必要になる、人の最終確認の観点を固定化

AIは便利ですが万能ではありません。特に「言い切りの回避」「結果を保証しているように受け取られるおそれのある表現の回避」は、AI任せだと抜けることがあります。速くするほど確認が重要です。

つまずきポイント： 最初から"全部自動"にすると止まりやすいです。まずは「固定前提文書＋スキャン＋チェック項目」を回し、あとから自動化を足すのが安全側です。

入力しない情報の線引き（個人情報・案件特定情報・機微情報）と匿名化ルール

AIに貼り付けるのは「公開してよい前提の情報」に限ります。次の情報は入力しない運用にします。

依頼者の氏名、住所、連絡先、会社名などの固有名詞
相談経緯が特定できる日時・場所・出来事の詳細
未公開の契約条件、金額、交渉内容など機微情報
画像・PDFのスクリーンショット（特定情報が混ざりやすい）

匿名化ルール（コピペ用）

固有名詞→[依頼者]、[法人]、[地域]、[業務分野] に置換
日付→[時期]（例：2026年2月→「2026年初頭」）
数値→レンジ化（例：3件→「数件」）
事例は「実在の個別案件」と分かる情報を落とし、一般化した説明に寄せる

補足（より安全側）： 住所・勤務先・家族構成など、単体では弱くても組合せで個人が特定され得る情報も削ります。相談者の同意なく、相談内容を推測できる形で掲載しません。

つまずきポイント： 「一般化したつもりでも、地域＋時期＋出来事の組合せで特定される」 ことがあります。迷ったら削る、が安全側です。

辞書（Gems／NotebookLM等）に入れるもの・入れないもの（運用の境界線）

辞書化は便利ですが、入れる情報を間違えると事故の近道になります。

入れるもの（おすすめ）

事務所の固定方針（対応範囲、対応姿勢、言い回しの好み）
よく使う注意書き・免責の定型
NG表現辞書（「必ず」「100%」など）
公開済みの自社ブログ文書（自社の言い回し統一に使う）

入れないもの（原則）

個別案件の固有情報、未公開の依頼者情報、機微情報

つまずきポイント： 辞書に"良さそうな情報"を何でも入れると、後で消せない負債になります。辞書は「公開済み」「一般化できる」「繰り返し使う」から始めると安定します。

1 ハック① 毎回貼る「固定前提文書」を用意する

コピペ用：冒頭に貼る固定前提文書（テンプレ本体）

まずは「毎回貼るだけ」の固定前提文書を用意します。ここがブレると、スキャンしてもリスクが減りにくくなります。

【前提（固定）】
本稿は一般情報として作成しています。個別事情の結論は断定しません。
根拠が必要な箇所、要件判断が絡む箇所は「要確認」と明示します。
誇大表現・成果保証・断定を避け、「一般的には」「場合によっては」等で安全側に寄せます。
最終的な判断（法的判断・要件判断・対外表現の安全性・守秘/個人情報の扱い）は人が行います。
公開前に「公開前チェック項目」を付けます。

使いどころ： 制度解説、手続の流れ、報酬の考え方、実績・クチコミ紹介など、ほぼ全てのブログ文書

入力時の注意（匿名化）： 固定前提文書は"固定"なので、依頼者情報や具体事例は混ぜません。

NG例（やりがちな悪い入力）： 「【前提】A社（実名）の案件について一般情報として作成」 → 固定前提文書に固有名詞を混ぜると、守秘・特定のリスクが上がります。

使いどころ：どの種類のブログ文書にも効く"固定"の考え方

固定前提文書が効く理由は、「本文の出来に依存しない前提の固定」になるからです。AIで作る文書は回ごとに揺れますが、固定前提文書が毎回同じであれば、最低限の安全側の姿勢を外しにくくなります。

つまずきポイント： 固定前提文書を"記事ごとに最適化"し始めると、固定でなくなります。固定は固定のままにし、調整は本文側で行うほうが運用が安定します。

つまずきポイント：前提文書が長くなりすぎる問題と短縮のコツ

短縮の目安は「5行前後」です。削る優先順位は次の順がおすすめです。

残す： 一般情報／断定しない／要確認明示／最終判断は人／公開前チェック
削る： 細かな例外の列挙（例外は本文側、または公開前チェック項目に逃がす）

つまずきポイント： 前提文書が長いほど読まれません。長くなりそうなら「公開前チェック項目」に分離し、固定前提文書は短く保ちます。

2 ハック② 「断定／誇大／成果保証」だけを自動スキャンする

危ない表現のカテゴリ分け（断定・誇大・成果保証・誤認リスク）

スキャン対象をカテゴリで固定すると、迷いが減ります。 ※本稿では便宜上「成果保証」と表現しますが、意図としては「結果を保証しているように受け取られるおそれのある表現」を指します。

断定： 必ず、絶対、〜に違いない
誇大： 日本一、最強、どこよりも、完全に、地域No.1
成果保証： 必ず通る、100%解決、確実に取れる
誤認リスク： 条件を省いて一般化、例外を落として断言、格安・最安を根拠なしに示す

つまずきポイント： AIは読みやすさのために強い言い回しを提案しがちです。読みやすさより、まず安全側です。

コピペ用：危ない表現スキャン用プロンプト（抽出＋言い換え案）

長いブログ文書では一度に「全文修正」まで要求すると出力が膨らみやすいです。そこで、①スキャン（軽量）→②全文反映（必要なときだけ） の2段階にします。

コピペ用プロンプト①（軽量：スキャン＋言い換え案＋要確認）

あなたは行政書士事務所の編集チェック担当です。
次の【ブログ文書】を対象に、「断定／誇大／成果保証／誤認リスク」をスキャンしてください。
法的助言ではなく一般的な情報提供として整え、個別案件の結論は示さないでください。

# 最重要方針
- 不確かな箇所・根拠が必要な箇所は推測せず「要確認」と明示する
- 実績・クチコミ・数値は、結果を保証しているように受け取られるおそれがないよう前提（期間・対象・分母・同意）を添える提案をする
- 固有名詞・具体的な日時・住所など、個人が特定され得る情報は使わない（入力に含まれている前提であっても、出力には出さない）

# 出力形式（最大20件、重要度順）
1) 危ない表現の候補
- 抜粋（前後1文まで）
- リスク分類（断定/誇大/成果保証/誤認リスク）
- なぜ危ないか（1行）
- 安全側の言い換え案（1〜2案）
2) 「要確認」一覧（根拠・前提が不足している箇所）

---【ブログ文書】---
（ここに本文を貼り付け）

コピペ用プロンプト②（必要時：指摘を反映した全文）

上の指摘（危ない表現と要確認）を反映し、【ブログ文書】を全文で再作成してください。

# 条件
- 冒頭に固定前提文書を残す
- 末尾に「公開前チェック項目」を10個付ける
- 個別事情の結論は断定しない
- 根拠が必要な箇所は「要確認」を明示する
- 実績・クチコミ・数値は、前提（期間・対象・分母・同意）を添え、結果保証に見えないようにする
- 固有名詞・具体的な日時・住所など、個人が特定され得る情報は出力しない

---【ブログ文書】---
（ここに本文を貼り付け）

使いどころ： 公開前の最終チェック、または公開後のリライト時（過去ブログ文書の棚卸し）

入力時の注意（匿名化）： 貼り付け前に、固有名詞や相談経緯が混ざっていないか目視します。

NG例（やりがちな悪い入力）： 「A社（実名）の許可が必ず通った手順をそのまま貼ります。担当者名は○○です。」 → 案件特定・個人情報・結果保証に見える表現が混ざり危険です。一般化・匿名化が必要です。

つまずきポイント：言い換えが"弱すぎる／強すぎる"ときの調整方法（追いプロンプト）

AIの言い換えが極端なときは、追いプロンプトで軸を戻します。

上の指摘を踏まえて再編集してください。

# 条件
- 訴求（読者メリット）は残す。ただし結果保証に見える語は使わない
- 条件・前提が必要な箇所は「一般的には」「場合によっては」「要確認」で安全側に寄せる
- 修正後の【ブログ文書】を全文で出す（冒頭の固定前提文書と末尾の公開前チェック項目も含める）
- 相談導線（問い合わせ等）を入れる場合は、できること／できないことをセットで書く

つまずきポイント： 追いプロンプトを足しすぎると、指示が衝突してブレます。迷ったら「訴求は残す／結果保証に見える表現は避ける／要確認を付ける」の3点に戻すと整います。

3 仕組み化：GASで「貼る→スキャン→チェック」を半自動にする

構成案：Googleドキュメント／スプレッドシートでの運用フロー（PC前提）

おすすめは次のどちらかです。

A案（軽い）：Googleドキュメント1本で完結

冒頭に固定前提文書
スクリプトでNG辞書を走査→末尾に結果とチェック項目を追記

B案（育つ）：スプレッドシートでNG辞書を管理＋ドキュメントで執筆

NG表現、カテゴリ、言い換え方針を辞書化
チェック結果が資産として積み上がる

つまずきポイント： 最初からB案を作り込むと、辞書設計で止まりがちです。まずA案で回し、NG辞書が増えてきたらB案へ移すほうが安全側です。

PC手順：GASの基本配置（スキャン実行・結果の出力先・ログ）

ここではA案（ドキュメント完結）を例にします。UI表示名は更新される可能性があります。

PC手順

Googleドキュメントで「ブログ文書テンプレ」用の文書を新規作成します
冒頭に「固定前提文書」を貼ります（前章のテンプレ）
メニューから 拡張機能 → Apps Script を開きます（表示名は環境で異なる場合があります）
下のコードを貼り付けて保存します
文書を再読み込みします
上部メニューに追加された 「ブログ安全チェック」→「NGスキャンを実行」 をクリックします

つまずきポイント（回避策）： 初回実行時は権限許可が必要です。許可画面が出ない・進まない場合は、文書の再読み込み、別ブラウザ、別Googleアカウントの誤ログイン確認を行うと解消することがあります（環境差があります）。また、GASには実行時間や呼び出し回数などの制限があり、仕様変更・制限値の見直しがあり得ます。動かない場合は、最新の公式情報も確認してください。

/**
* ブログ安全チェック（冪等版）
* - 既存レポートを消してから再生成（結果の増殖を防止）
* - 段落番号＋抜粋つきでヒットを列挙
* - 例外（除外）ルールに対応
* - ヒットが多すぎる場合は打ち切り（暴発防止）
*/
const REPORT_MARKER = '===BLOG_SAFETY_REPORT_START===';

function onOpen() {
DocumentApp.getUi()
.createMenu('ブログ安全チェック')
.addItem('NGスキャンを実行', 'scanNg')
.addToUi();
}

function scanNg() {
const ui = DocumentApp.getUi();
try {
const doc = DocumentApp.getActiveDocument();
const body = doc.getBody();

// 1) 既存レポート削除（冪等）
removeOldReport_(body);

// 2) NG辞書（最小例。運用で増やす）
// word: 検知語, cat: 分類, suggest: 修正方針
const ngList = [
{ word: '必ず', cat: '断定', suggest: '「一般的には」「場合によっては」等に寄せ、条件や前提を補う' },
{ word: '絶対', cat: '断定', suggest: '言い切りを避け、条件付き表現にする' },
{ word: '100%', cat: '成果保証', suggest: '結果保証に見えるため避け、前提・範囲・例外を明示（統計は出典も要確認）' },
{ word: '確実', cat: '成果保証', suggest: '「可能性がある」「傾向がある」等に寄せ、要確認を付ける' },
{ word: '日本一', cat: '誇大', suggest: '比較根拠がない限り避け、事実ベースの表現にする' },
{ word: '最強', cat: '誇大', suggest: '根拠が示せない場合は避け、説明対象の範囲を明示する' },
{ word: '地域No.1', cat: '誇大', suggest: '根拠（調査主体・期間・比較対象）なしでは避ける' },
{ word: '最安', cat: '誤認リスク', suggest: '比較条件が必要。根拠がなければ避けるか、条件・範囲を明示' },
{ word: '格安', cat: '誤認リスク', suggest: '価格の前提（範囲・条件）を明示。誤認が出るなら避ける' },
{ word: '最短', cat: '誤認リスク', suggest: '条件（時期・混雑・追加資料）を添えて誤認を避ける' }
];

// 3) 例外（除外）ルール：誤検知を減らす（必要に応じて追加）
// 例：「必ずしも」「100%OFF」など
const excludePatterns = [
/必ずしも/g,
/100%OFF/gi
];

// 4) 本文を段落単位でスキャン
const paras = body.getParagraphs();
const hits = [];
const HIT_LIMIT = 200; // 暴発防止（必要なら運用で調整）

for (let idx = 0; idx < paras.length; idx++) {
const t = paras[idx].getText();
if (!t) continue;

const masked = maskExcluded_(t, excludePatterns);

for (let j = 0; j < ngList.length; j++) {
const item = ngList[j];
const re = new RegExp(escapeRegExp_(item.word), 'g');
let m;
while ((m = re.exec(masked)) !== null) {
hits.push({
cat: item.cat,
word: item.word,
paraNo: idx + 1,
excerpt: excerpt_(t, m.index, item.word.length),
suggest: item.suggest
});
if (hits.length >= HIT_LIMIT) break;
}
if (hits.length >= HIT_LIMIT) break;
}
if (hits.length >= HIT_LIMIT) break;
}

// 5) レポート生成（末尾に追記）
const stamp = Utilities.formatDate(new Date(), Session.getScriptTimeZone(), 'yyyy-MM-dd HH:mm');
const summary = summarize_(hits);

if (!hits.length) {
lines.push('- 該当なし（ただし最終確認は人が実施）');
} else {
const limited = hits.slice(0, 50); // 表示は50件まで（読みやすさ優先）
limited.forEach((h, i) => {
lines.push(`${i + 1}. [${h.cat}] 「${h.word}」段落${h.paraNo}`);
lines.push(` 抜粋：${h.excerpt}`);
lines.push(` 修正方針：${h.suggest}`);
});
if (hits.length > limited.length) {
lines.push('');
lines.push(`※表示は${limited.length}件までです。ヒットが多い場合は文書を分割してスキャンしてください。`);
}
if (hits.length >= HIT_LIMIT) {
lines.push('');
lines.push('※ヒット件数が多いため途中で打ち切りました。文書を分割して再実行してください。');
}
}

lines.push('');
lines.push('【公開前チェック項目】（毎回ここを確認）');
lines.push('1. 個人情報・案件特定情報・機微情報が含まれていない（組合せで特定され得る情報も含む）');
lines.push('2. 個別事情の結論を断定していない（条件が必要なら明示）');
lines.push('3. 根拠が必要な箇所に「要確認」または根拠メモがある');
lines.push('4. 誇大表現・結果保証に見える語が残っていない');
lines.push('5. 例外や注意点を落として一般化していない');
lines.push('6. 要件・期間・必要書類などが古くなる可能性に配慮している');
lines.push('7. 実績・クチコミは前提（期間・対象・分母・同意）を添えている（加工・創作がある場合はその旨を明示）');
lines.push('8. 読者が誤解しやすい箇所に補足がある');
lines.push('9. 事務所の対応範囲と矛盾がない');
lines.push('10. 最後に免責があり、対外表現として安全側に寄っている');

body.appendParagraph(lines.join('\n'));
ui.alert('NGスキャンが完了しました。末尾に結果を追記しました。');
} catch (e) {
ui.alert(`NGスキャンでエラーが発生しました。\n原因：${e && e.message ? e.message : e}`);
}
}

function removeOldReport_(body) {
const paras = body.getParagraphs();
let markerIndex = -1;
for (let i = 0; i < paras.length; i++) {
if (paras[i].getText().indexOf(REPORT_MARKER) !== -1) {
markerIndex = i;
break;
}
}
if (markerIndex === -1) return;

for (let i = paras.length - 1; i >= markerIndex; i--) {
body.removeChild(paras[i]);
}
}

function maskExcluded_(text, excludePatterns) {
let out = text;
excludePatterns.forEach(re => {
out = out.replace(re, (m) => '□'.repeat(m.length));
});
return out;
}

function escapeRegExp_(s) {
return s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
}

function excerpt_(text, index, len) {
const start = Math.max(0, index - 20);
const end = Math.min(text.length, index + len + 20);
return text.substring(start, end).replace(/\s+/g, ' ').trim();
}

スマホ手順（補足）：閲覧・軽微修正までに絞った運用（画面差分の注意）

スマホは「実行」より「確認」に寄せると安定します。

Googleドキュメントアプリで該当文書を開きます
冒頭に固定前提文書があるか確認します
末尾に「NGスキャン結果」と「公開前チェック項目」が追記されているか確認します
誤字や言い過ぎを軽微修正し、最終確認はPCで行います

つまずきポイント： スマホはApps Script編集や実行導線がPCと異なり、できる範囲が限られることがあります。PC主導で設計し、スマホは確認中心にするのが無難です。

4 実績・クチコミ・強みを"安全に"載せる（実績が少ない時期の代替も用意）

実績・クチコミの文書で注意すべき表現（結果保証に見えない前提の添え方）

実績・クチコミは安心材料になり得ます。ただし、次の情報を短く添えると誤認を減らしやすくなります。

期間（例：2026年初頭〜）
対象（例：同意が得られた範囲）
分母（例：全件ではなく一部の紹介）
結果保証ではない旨（固定前提文書で担保）

加えて、守秘・個人情報の観点で次も明示すると安全側になります。

同意を得た事例のみ掲載する
ケース紹介は事実の範囲に限定する
フィクション・加工がある場合は、その旨を明示する

言い回し例（安全側）

×「必ず許可が取れます」
○「一般的にはこの流れで進みますが、個別事情で変わるため要確認です」

つまずきポイント： 「良い話だけ」だと誤認誘発に寄ることがあります。前提（期間・対象・分母・同意）を添えるだけでも、受け取られ方が変わります。

実績が少ない場合の代替安心材料（経歴・学び・専門テーマ・活動の蓄積）

開業前後で実績が少ない・ないのは珍しくありません。その場合は、実績以外の安心材料を積み上げます。

学び： 研修・講座・勉強会（一般化して記載）
専門テーマ： 取り扱い予定の分野、調査・整理の蓄積
地域性： 地域の制度・窓口・実務の導線理解
活動： ブログ更新の継続、FAQの整備、用語集の作成

つまずきポイント： 安心材料を増やそうとして誇大表現に寄りがちです。NGスキャンの対象に含め、強い語が出たら条件・前提を足して安全側に寄せます。

強みが分からない場合：AI壁打ちで整理・言語化する手順（最終決定は人）

「強みが分からない」はよく起こります。AIは整理と候補出しには役立ちますが、採否は人が握ります。

手順（PC）

経歴・経験・得意を箇条書きで出します（特定情報は入れない）
AIに「強み候補」と「読者メリット」を出させます
違和感があるものを落とし、言い回しを自分の言葉に寄せます
固定前提文書＋NGスキャンを通します

次のメモから、行政書士事務所としての「強み候補」を3〜5個に整理してください。
- 誇大表現や結果保証に見える表現は避ける
- 強みは「読者メリット（何が助かるか）」まで一文で示す
- 最後に、強みをブログ文書に載せるときの注意点を5つ出す

---メモ---
（匿名化したメモを貼る）

つまずきポイント： AIが「刺さる表現」を優先して強めに言いがちです。強みは盛ることではなく、継続できる説明に寄せます。

5 公開前チェック：速くするほど確認が重要（人が担う最終判断）

公開前チェック項目（事実・根拠・守秘・対外表現の安全性）

固定前提文書とセットで、毎回これを確認します（10項目例）。

個人情報・案件特定情報・機微情報が入っていない（組合せで特定され得る情報も含む）
結論の断定になっていない（条件がある箇所は明示）
根拠が必要な箇所に「要確認」または根拠メモがある
誇大表現・結果保証に見える語がない（スキャン結果も確認）
例外や注意点を落として一般化していない
手続・要件・期間などは古くなる可能性がある旨に配慮している
実績・クチコミは前提（期間・対象・分母・同意）を添えている（加工・創作がある場合は明示）
読者が誤解しやすい箇所に補足がある
事務所の対応範囲と矛盾がない
免責があり、対外表現として安全側に寄っている

つまずきポイント： チェック項目を"読まずにOKにする"と形骸化します。毎回、最低でも「1・2・3・4」だけは指差し確認する運用にすると効きます。

NGが出たときの編集ルール（短縮・整形・言い過ぎ回避・導線強化）

NGが見つかったら、次の順で直すと迷いません。

言い切りを外す： 「〜に違いない」→「一般的には〜」「場合によっては〜」
条件を足す： 誰にでも当てはまるように見える箇所→条件・前提を一文追加
要確認を付ける： 根拠が揃わない箇所→「要確認」明示
短縮する： 長文で誤認を生みやすい→要点だけ残す
導線を整える： 相談導線は「できること／できないこと」をセットで書く

つまずきポイント： 修正で訴求が消えたら、追いプロンプトで「訴求は残す／結果保証に見える表現は避ける／要確認を付ける」に戻して再編集すると整います。

つまずきポイント：AIの指摘が過剰／不足なときの"確認観点"

過剰（何でもNG扱い）なとき：

「一般情報としての説明」と「個別案件の結論」を分けて見直します
"禁止"ではなく"条件を足す"で解決できないか確認します

不足（見落とす）なとき：

「必ず」「確実」「100%」「最短」「完全」「最強」など強い語を目視でも拾います
実績・クチコミ周りは前提不足がないか、人の目で再確認します

6 まとめ（運用を止めずに安全を積み上げる）

まとめ：固定前提文書＋NGスキャンでブログ運用が安定する理由

ブログ運用は、速さより「リスクを減らす仕組み」が先に効きます。毎回貼る固定前提文書で土台を揃え、NGスキャンで危ない表現だけを拾い、公開前チェック項目で人の最終確認を固定化すると、運用のばらつきやリスクを減らしやすくなります。自動化（GAS）は"最後のひと押し"として、止まらない範囲から始めるのが現実的です。

なお、今回の固定前提文書・スキャン用プロンプト・GASコード自体もAIに作成してもらうことは可能です。ただし本番運用では要件定義・テスト・改修の品質管理が重要になるため、"AIに作成してもらい、それを安全に動かす手順"は実践編（応用）で扱います。

免責

本記事は一般情報であり、個別案件の法的判断・要件判断・対外表現の安全性を保証するものではありません。AI活用は便利ですが、速くするほど確認が重要です。公開可否の最終判断（根拠確認、守秘、個人情報の扱い等）は必ず人が行ってください。また、本稿は行政書士事務所の運用例であり、他業種の広告規制等にそのまま適用できるとは限りません。所属する行政書士会の広告に関する規程・指針等がある場合は、それも確認してください。

HANAWA行政書士事務所

HANAWA行政書士事務所公式サイト

AI活用学習サイト

前の記事：実践編第6回：NotebookLMで「事務所の独自辞書」を作り、根拠つきの文書下書きを速く作る手順

← 前のページに戻る