AIエージェントの権限設計は新人研修みたいに始める

AIエージェントを仕事に入れるとき、私がいちばん迷ったのは「どこまで自動で進めてよいか」だった。記事生成、画像生成、WordPress公開、noteミラーのように工程がつながるほど、便利さと事故の近さが同時に増える。

ログを見返すと、私は毎回似た場所で止まっていた。本文は作れる。画像も作れる。公開APIも使える。でも、外部へ出る操作、認証が絡む操作、会社情報や個人情報が混じる可能性がある操作だけは、同じ自動化の中でも扱いを変えないと危ない。そこで今回は、AIエージェントの権限を「新人に仕事を渡す時の研修」として設計し直した。

Webで補足すると、この方向は単なる気分ではなかった。Google CloudはAIエージェントを、ユーザーの代わりに目標へ向かってタスクを進める仕組みとして説明している。OpenAIのAgents SDKも、エージェントは計画し、ツールを呼び、状態を持って複数ステップの作業を進めるものだとしている。つまり、チャットの返答だけではなく、実際の作業を動かす前提で考える必要がある。

だから私の運用では、AIエージェントを「何でも任せる相手」ではなく、「読める仕事から始め、書ける仕事へ広げ、外部に出る仕事だけ別ゲートにする相手」として扱うことにした。

迷ったのは自動化の速度ではなく境界だった

最初は、1本の記事を公開するまでの作業をできるだけ短くしたかった。ネタ棚から候補を選び、本文を作り、画像を2枚そろえ、WordPressへ公開し、成功したらnoteへ無料ミラーを作る。この流れ自体は合理的だ。

ただ、全部を同じ強さで自動化すると、止めるべき場所が見えにくくなる。本文の誤字と、会社情報の混入と、外部投稿の失敗は、同じ「エラー」ではない。前者は修正して続行できる。後者は、その候補を止めるべき理由になる。

ここを分けないと、エージェントに任せるほど判断が雑になる。私は今回、工程を速くする前に、次の3段階へ分けた。

読むだけの作業
ローカルに作る作業
外部へ公開する作業

読むだけなら広めに任せられる。ローカル作成も、秘密情報チェックや品質ゲートを通せば進めやすい。外部公開だけは別で、公開前にタイトル、本文、画像、参照元、秘密情報リスクを見る。この分け方にすると、AIエージェントの便利さを残したまま、事故の起点をかなり減らせる。

公式情報から見えた共通点

OpenAIのエージェント安全ガイドでは、MCPのようなツールを使う時は、ユーザーが操作を確認できる承認を残すこと、入力にはガードレールを入れることが説明されている。これは、私のブログ運用で言えば「外部公開、送信、共有、投稿は別扱いにする」というルールに近い。

AnthropicはClaude Codeのauto modeについて、毎回の承認が多すぎると承認疲れが起きる一方、全部の権限確認を飛ばすのは危ないと説明している。この話も、かなり実感がある。承認が多すぎると人間は流れで押してしまう。逆に、承認を全部なくすと、取り返しのつかない操作まで同じ勢いで通ってしまう。

Claude Codeの製品ページにも、ファイル変更やコマンド実行の前に明示的な承認を求めるという説明がある。ここから分かるのは、エージェント活用で大事なのは「AIを信用するかどうか」ではなく、「どの種類の操作に、どの種類の確認を置くか」だということだ。

私の毎日投稿でも同じだった。記事本文の表現不足は修正で回復できる。画像プロンプトが弱ければ簡単にして再生成できる。だが、会社情報が混じった記事、認証が壊れた状態での公開、同じ記事の重複投稿は、回復ではなく停止の対象にする。

新人研修として権限を渡す

AIエージェントの権限設計を、新人研修に置き換えると分かりやすい。

初日にいきなり全アカウントの投稿権限を渡す人はいない。まずは資料を読んでもらい、次に下書きを作ってもらい、レビューを受けてから一部の定型作業を任せる。ミスが起きやすい操作は、チェックリストを作る。外部へ出る操作は、先輩や責任者が見る。

AIエージェントも同じでよい。最初から「完全自動で全部やる」ではなく、次の順番で渡す。

ローカルログを読む
公開OKな抽象メモへ変換する
下書きと画像プロンプトを作る
秘密情報と重複を機械的に確認する
画像2枚がそろった時だけ公開処理へ進む
公開後にURL、見出し、画像表示を確認する

この順番なら、途中で止まっても状態が分かる。どこまで終わり、どこで止まったのかが残る。エージェントに任せる範囲を増やすほど、結果だけではなく途中の判断ログが重要になる。

私の運用で変えたこと

今回のブログ自動化では、候補をそのまま信じないようにした。ネタ棚から選んだ候補でも、未確認の固有名詞が前に出すぎる場合は、そのまま公開しない。今日も最初の候補には、公式確認しにくいモデル名更新のような表現が入っていた。そこで、本文の中心を「最新モデル名の話」ではなく、「エージェント権限をどう渡すか」に寄せ直した。

この修正で、記事の読者価値が変わった。単なるニュース風の見出しだと、読者は「それで自分は何をすればいいのか」が分かりにくい。権限設計に寄せると、明日から自分の自動化にも使える。

もう一つ変えたのは、停止条件を「日次ジョブを止める理由」ではなく「その候補をそのまま出さない理由」として扱うことだ。重複、品質不足、Web補足不足、固定テンプレ感があれば、まず本文を直す。だめなら見出しを変える。それでも弱ければ別候補へ切り替える。すぐに全体停止へ持っていかない。

ただし、会社情報、個人情報、認証エラー、画像2枚不足は別だ。これは修正候補ではなく公開停止の対象にする。この線引きを先に決めておくと、毎日運用でも判断がぶれにくい。

すぐ使える権限チェックリスト

自分の作業にAIエージェントを入れるなら、まず次の表で分けるとよい。

作業	任せやすさ	必要なゲート
公開済み情報の要約	高い	参照元の確認
ローカル下書き作成	高い	秘密情報チェック
画像プロンプト作成	高い	画像品質チェック
ファイル編集	中	差分確認
コマンド実行	中	影響範囲の確認
外部公開・送信	低い	直前確認と結果検証
認証・支払い・契約変更	低い	原則手動または明示承認

この表で見ると、全部を同じ「自動化」と呼ぶのは危ない。要約と外部投稿では、失敗した時の影響が違う。影響が違うなら、承認の置き方も変える必要がある。

私が特に効いたと感じたのは、外部公開の前に「ローカルで完了した証拠」をそろえることだった。記事ファイル、画像2枚、参照リンク、秘密情報チェック、重複確認。この5つがそろっていれば、公開処理はかなり落ち着いて進められる。

承認疲れを減らす工夫

承認を増やせば安全になる、とは限らない。毎回同じ確認を何十回も求められると、人間は内容を見なくなる。Anthropicが説明していた承認疲れの話は、個人運用でもそのまま当てはまる。

そこで、私は確認を細かく増やすのではなく、確認の種類を減らすようにした。

読み取りは原則自動
ローカル作成はログを残して自動
外部公開だけ直前ゲート
会社情報、個人情報、認証エラーは即停止
失敗しても取り消しやすい作業は修正で回復

この形なら、人間が見るべき場所が絞られる。毎回すべてを見るのではなく、外へ出る直前と、取り返しにくい操作だけを見る。AIエージェントの速度を残しながら、人間の注意力を温存できる。

小さく始めるなら

明日から試すなら、いきなり投稿や送信を自動化しないほうがいい。最初は、ローカル下書きだけをAIエージェントに任せる。次に、下書きの品質チェックを任せる。さらに、画像プロンプトと参照リンク整理を任せる。

その後で、公開処理をつなぐ。公開処理をつなぐ時も、最初は下書き保存までにする。何度か問題なく回ってから、公開APIへ進める。公開後はURL、見出し、画像表示を確認する。

この順番なら、AIエージェントは怖いものではなくなる。万能な作業者としてではなく、権限を段階的に渡す新人として扱える。できる仕事が増えたら任せる。危ない仕事はゲートを置く。失敗したら、次回の手順に戻す。

私が今回残したいのは、AIエージェント活用の派手な話ではない。毎日続く仕事の中で、どこまで任せ、どこで止め、どこを人間が見るかを先に決めることだ。ここが決まると、AI活用はかなり現実的になる。