小規模法人でAIを使うときの承認ルール|下書き・公開・送信を分ける

小規模法人でAIを使うときの承認ルール|下書き・公開・送信を分けるの説明用イラスト

こんにちは、こめすけです。僕は少人数の法人で、AIを開発、調査、文章作成、Webサイトの改善に使っています。

仕事を任せる範囲が広がると、「どこまで進めてよいか」も具体的に伝える必要があります。文章の下書き、サイトの修正案、公開、メール送信、契約や支払いは、それぞれ影響が違うからです。

僕のブログ改善では、実際の経験や公開する数字について確認を挟んできました。営業管理表の整備では、一次確認と二次確認の欄を追加しました。この記事では、そうした作業をもとに、AIの作業完了と、人の承認を分ける考え方を整理します。

全社の仕事を自律的に実行するシステムを完成させた話ではありません。実際に行った整備と、これから取り入れられる運用例を分けて紹介します。

「文章ができた」と「公開してよい」は別の状態

AIが自然な文章を作っても、その内容を会社や個人の名前で公開してよいかは別です。

僕の場合、会社名を出さないこと、架空の体験を書かないこと、スクリーンショットの個人情報をマスクすることなどを、ブログ改善の条件にしています。これらは文章の読みやすさとは別に確認する項目です。

たとえば、企画書の下書きに「制作時間を半分にしました」と書かれていても、実測していなければ成果にはできません。計画を、実施済みの取り組みとして書くこともできません。

下書き完成の段階では、まだ事実、公開範囲、宛先や掲載先の確認が残っていると考える方が、判断を分けやすくなります。

実際の作業でも、確認する段階を分けた

営業管理表では、送信結果と返信を分けるだけでなく、一次確認と二次確認の欄を追加しました。候補の整理ができたことと、送信可否の確認が終わったことを同じ状態にしないためです。

また、ブログでは、実際に読んだ本かどうか、公開してよい実績かどうかなど、本人の確認が必要な情報があります。外部の公式情報を調べても、本人がそのサービスを使ったかどうかまでは確認できません。

この違いを踏まえ、AIへ依頼するときは「調べて下書きを作る」「本人確認が必要な部分を分ける」「許可された範囲だけ公開する」という段階を、依頼内容に含めるようにしています。

小規模法人で使える、作業を三つに分ける例

次の表は、今回の経験から整理した導入時の運用例です。すべての作業で同じ権限設定を実装済み、という意味ではありません。

区分作業の例終了時に残すもの
準備調査、整理、文章や資料の下書き根拠と未確認事項
変更許可したページ修正、表の整備変更前後と確認結果
対外的な実行公開、送信、契約・支払いなど対象・内容・必要な承認

公開や送信も、事前に内容と範囲を具体的に許可できる場合はあります。ただし、「改善して」と頼んだことを、未承認の情報公開や、契約・支払いまで許可したことにしないようにします。

データの削除、権限変更、秘密情報を含む処理も、通常の文章整理とは分けて扱います。使っているサービスの権限や確認手順に合わせて、実行してよい境界を決めてください。

承認を求めるなら、判断に必要な情報を一緒に出す

「進めてよいですか」だけでは、何が実行されるのか分かりません。AIへ承認依頼の出し方まで指定するときは、次のような項目を含められます。

実行すること:
対象ページ・宛先・サービス:
公開・送信する内容:
今回変更しないもの:
未確認の事実や条件:
変更後の確認方法:
戻す場合の方法:

たとえばブログなら、記事のタイトル、公開する数字、実名や画像の扱い、公開と下書きのどちらかを確認します。営業メールなら、対象、最終文面、営業可否、過去の拒否記録などを確認します。

この一覧は、確認を増やすためというより、判断に必要な情報が足りないまま実行しないためのものです。個人情報や機密資料は、承認依頼のメモ自体にも不用意に転載しないようにします。

変更履歴とハンドオフを、次の作業に使える形で残す

このブログの整備では、変更点や引き継ぎをMarkdownファイルへ残すようにしています。会話の中に「直しました」とだけ残っていると、後でどのページをどう変えたか確認しにくいためです。

記録では、「実施した」「確認した」「未確認」を分けます。AIの報告に書かれているだけのことと、実際の公開画面や管理画面で確認したことも区別します。

読者が自分の運用に取り入れるなら、次の項目から始められます。

  • 変更した日と対象。
  • 変更の目的と、変更前の状態。
  • 実際に変更した内容。
  • 公開画面などで確認した結果。
  • まだ確認していないこと。
  • 次に必要な作業と、確認が必要な人。

記録があるからバックアップが不要になるわけではありません。内容の履歴と、サイトのファイル・データを復元する仕組みは別です。

チェック欄だけでなく、「止める条件」を決めておく

承認欄を追加しても、確認の基準が曖昧なら形だけになってしまいます。導入時には、何が見つかったら進めないかも決めておきます。

例として、体験の裏付けがない、公開許可のない情報が含まれる、宛先が確かめられない、利用条件が不明、変更を戻せない、といった状態があります。

作業の目的が記事数や送信数を増やすことでも、確認できないものまで完成扱いにしないことが重要です。「下書きとして残す」「質問する」「実行を止める」も、次の行動として記録できます。

最初は一つの業務で、完了条件を言葉にする

今すぐ始めるなら、AIへ頼んでいる仕事を一つ選び、「何ができたら作業完了か」と「どこから先は人の判断か」を書き出してみてください。

ブログなら下書き・事実確認・公開、会社サイトなら修正案・変更・表示確認、営業準備なら候補整理・文面確認・送信、といった分け方ができます。

具体的な作業例は、AIを使ったブログ運営の実録、営業管理表の整備記録、会社ホームページの改修記録をご覧ください。

※実際の整備記録から運用例を整理した記事です。AIを無人で常時実行する仕組みや、その効果を検証した記録ではありません。AIで構成を補助し、実施済みと提案を分けて編集しています。

導入前の回答確認については、架空サンプルと固定回答で判定コードを確かめたAI PoCの6問評価を作った記録にまとめています。