「ブログ、そろそろ書かないとな」と思い続けて、もう半年が経っていた。
SEOで問い合わせを増やしたい。競合のサイトを見るたびに焦る。でも、現場対応・スタッフ管理・経理・営業と毎日が回っていて、ブログを書く時間は最後まで確保できない。
外注も検討しました。でも見積もりを取ったら月8万円。「うちの会社の言葉で書いてもらえるのか」という不安もあって、結局決断できなかった。AIライティングツールも試しましたが、「使う人」がいないと動かない。ツールだけが増えていく。
この状況、思い当たる方はいませんか。
私はホテル清掃の会社(株式会社Clears)を経営しています。エンジニアではありません。それでも今、誰も動かさなくてもスケジュールどおりに記事が自動で公開され続けています。
ただ、このシステムを作る前に一つ、徹底的に調べたことがあります。それが「AIに業務を任せるとき、何がリスクになるか」でした。
まず知っておくべきこと:AIに渡した情報はどこへ行くのか
2023年3月、Samsungのエンジニアが社内の機密ソースコードをChatGPTに貼り付けて修正を依頼し、情報漏洩が発覚しました。3人が懲戒処分となり、Samsungはその後AIの社内利用を全面禁止しています。
これは「うっかり」の話ではありません。ChatGPTのブラウザ版では、入力した内容がAIの学習データとして使われる設定がデフォルトになっていた時期があります(現在はオプトアウト可能)。一方、API経由で構築したシステムでは、デフォルトで学習に使用されません。同じ「ChatGPT」「Claude」でも、ブラウザで直接使う場合とAPI経由でシステムを構築する場合ではデータの扱いがまったく異なります。
経産省・総務省は2025年3月に「AI事業者ガイドライン」を公開し、企業に対してAI利用時の個人情報・企業秘密の保護を明示的に求めています。同年6月には日本初のAI法が成立し、9月に全面施行されました。「AIを便利に使う」だけでは、経営責任として不十分な時代になっています。
日本の中小企業でAIを組織として導入しているのはまだ約12%にとどまります。障壁の一つとして「セキュリティへの不安」を挙げる企業は31%に上ります。不安があるから使わない、ではなく、不安の正体を知った上で設計する。それが今求められている経営判断だと私は考えています。
「AIを使う」ではなく「AIを採用する」という発想
リスクを把握した上で、私が選んだのは「使わない」ではなく「設計して使う」でした。発想の起点は、「社員を採用するときと同じように考えたらどうか」でした。役職・専門領域・判断基準・発言ルール・問題が起きたときの行動指針。新入社員に最初から全部の権限を渡す会社はありません。AIも同じです。

今のチームは6人(全員AI)です。
- 編集長-AI:戦略統括・最終判断。投稿の「GO」を出せる唯一のAI
- SEO-AI:キーワード選定・検索データ分析。数字なき発言は却下
- ライター-AI:記事執筆。媒体ごとに文体を書き分ける
- 企画-AI:テーマ発案・トレンド調査。前例踏襲に意図的に異を唱える役
- クリエイティブ-AI:画像・サムネイル方針の決定
- マスター-AI:投稿実行・議論の収束・進行管理
「なんでもできるAI」は「何をするか分からないAI」でもある
2024年に発覚した事例では、Slack上のAI機能が攻撃者の仕掛けた「隠し命令」をユーザーの指示と誤認し、社内情報を外部に送信するという攻撃が確認されています。外部から受け取った文章に命令文を埋め込み、AIに実行させる「プロンプトインジェクション」と呼ばれる手法です。
この種の攻撃に「AIに気をつけさせる」という対策は機能しません。AIは文脈を読む機械であり、「これは悪意ある命令だ」と判断する機能を持ちません。有効な対策は、AIが読める情報の範囲を構造的に絞ること、そして各AIに「自分の役割の外に出ない」ルールを設定することです。
制御には2種類ある:コードで止めるものと、プロンプトで誘導するもの
AIエージェントの安全設計を考えるとき、制御には根本的に異なる2種類があります。コードレベルで物理的に止めるものと、プロンプトで「そうしないように」誘導するものです。この2つは信頼性がまったく違います。
プロンプトへの指示は、LLMの出力傾向を変えますが、100%従わせることはできません。セキュリティの国際基準を定めるOWASP(Open Web Application Security Project)のLLMリスク指針でも「プロンプトベースの自己防衛は確実ではない」と明記されています。このシステムはその区別を意識して設計しています。
コードレベルで止めている制御
承認フォーマットの文字列マッチ
投稿処理のGO判断は、特定の文字列をプログラムが検出したときだけ実行されます。これはAIへの「お願い」ではなく、コードに書かれた条件分岐です。AIが文脈を読み違えて曖昧な返答をしても、その文字列が含まれなければシステムは動きません。最も重要な判断をAIの解釈に依存させていません。
二重投稿防止・タイムアウト
同じ時間帯に投稿が完了している場合、次の実行はコードレベルでスキップされます。処理が一定時間を超えた場合も自動で停止し、Slackに警告を出します。これらもプロンプトへの指示ではなく、プログラムとして実装しています。
プロンプトで誘導している制御と、その穴を塞ぐ人間側の仕組み
コンテンツ安全ルール
競合他社の実名批判・著作物の無断引用・未確認情報の断定などを全AIに禁止ルールとして設定しています。ただしこれはプロンプトへの指示であり、LLMが100%従うとは言えません。2025年の研究では同系統モデル同士のレビューはエラーを見逃しやすいことも確認されています。
この穴を塞ぐために、公開後の記事を定期的に人間がサンプル確認しています。全件を毎回見るのではなく、問題が起きやすいパターンを把握した上で重点的に確認します。問題が見つかればシステム側のルールに反映します。プロンプトの限界をゼロにすることはできませんが、人間のフィードバックループで継続的に精度を上げる設計にしています。
最低2ラウンドのレビューとブロッカー制度
記事が生成されても1回目のラウンドでは承認できない設計になっています。「数値の裏付けがない」「特定の視点しか入っていない」などの条件を1つでも満たす場合は承認をブロックします。ラウンドを重ねることでAI単独では見落としやすい問題を減らしています。
ただしここでも正直に言うと、AIが複数回レビューしても最終的には人間の目が最も信頼できます。そのため、GA4とSearch Consoleのデータを定期的に確認し、記事のパフォーマンスが落ちていないかを数値で監視しています。品質劣化はAIへの指示だけでは検知できません。数値として現れてから人間が判断する仕組みが必要です。
安易に真似してほしくない理由
ここまで読んで「自分でも作れそう」と思った方に、正直に伝えておきたいことがあります。
ハルシネーションは止められない
AIは存在しない統計、誤った引用、架空の固有名詞を自信満々に出力することがあります。2024〜2025年のAI関連インシデントは前年比21%増加しています。「生成→即公開」にすると、誤情報が自社名義で公開され続けます。
著作権侵害の責任は利用者が負う
日本の著作権法上、AIが生成したコンテンツが既存の著作物と酷似していた場合、責任はAIを使った会社・個人が負います。「AIが書いたので知りませんでした」は免責になりません。
「設定したら放置」は品質を静かに殺す
自動化システムは監視がなければ誰にも気づかれないまま劣化します。AIモデルのアップデートで出力の傾向が変わる、接続が切れてサイレント停止する。定期的な確認なしに放置すると、投稿が続いているように見えて誰も読まない記事を量産する状態になります。
APIキーの管理が甘いと想定外の被害が出る
SlackのトークンやAIサービスのAPIキーをソースコードに直接書いたりチームで共有したりすることは危険です。漏洩すると第三者があなたの名義で動作したり、高額請求が来たりします。このシステムではエージェントごとに認証情報を分離管理し、ソースコードには書かない設計にしています。
画像はすべて自社PCの中で完結させている
記事に使う画像は、外部サービスを使わず自分のパソコンの中でAIに生成させています。理由は2つあります。
1つはコスト。クラウドの画像生成サービスは枚数ごとに課金されます。継続的に記事を出し続けるにはランニングコストが無視できない。ローカルで動かせば何枚生成しても追加費用はゼロです。
もう1つは情報管理。ローカルで動かすAIは、入力したプロンプトも生成された画像も一切外部サーバーへ送信されません。クラウドサービスは「送信されたデータをどう扱うか」がサービスごとに異なります。金融・医療・官公庁がローカルAIを選ぶ理由の一つはここにあります。社内の人物や施設が関わる素材を扱う場合、この違いは無視できません。特定の人物や雰囲気を一貫して使い回せることも、ローカル生成の利点です。

導入前後の変化
| 導入前 | 導入後 | |
|---|---|---|
| 月間記事数 | 0〜2本(時間があるときだけ) | スケジュールどおりに自動公開 |
| 記事作成の工数 | 月30時間以上 | ほぼゼロ |
| 画像コスト | 外部サービスで都度課金 | ゼロ(ローカル生成) |
| 外注費 | 見積もり月8万円(未実施) | 不要 |
| 投稿の継続性 | 気が向いたとき | スケジュール通りに自動稼働 |
数字以上に変わったのは「続けられるようになった」という事実です。人間が書く場合、モチベーションや繁忙期の波に左右される。AIチームは疲れないし、言い訳もしません。
エンジニアより経営者の方が、たぶん得意なこと
途中で詰まったことも何度もあります。AIが想定外の動きをするバグ、処理が競合して次が動かなくなる問題、外部サービスとの接続が突然切れる問題。そのたびに記録を読んで、原因を特定して、直しました。
「人に仕事を任せる設計をする」「コードで止めるべきものとプロンプトで誘導するものを区別する」「AIでは補えない部分を人間がどう補うかを決める」という感覚は、経営者の方が自然に持っていると思います。エンジニアは「どう作るか」が得意。経営者は「どう動かすか・どこで人間が関わるか」が得意。AIを活用する上では、後者の方が本質に近い気がしています。
AIを使った業務改善について詳しく聞きたい方、「うちの会社でもできるか?」と気になった方は、お気軽にご連絡ください。
AIコンサル会社ではないからこそ、経営者×中小企業の目線でお話しできると思っています。同じように試行錯誤している方と気軽につながれたら幸いです。
※AIコンサル等は弊社の事業ではない為費用をいただいて何かを実施する予定はございません、あくまで同様の悩みがある経営者の方の参考になればと思います。
セミナー・勉強会のご相談もお待ちしています。