AIエージェントに仕事を任せられる場面が増えてきました。調査、要約、コード修正、ドキュメント整理、ブログの下書き作成。ここまでは、個人の作業でもかなり使いやすくなっています。
一方で、実際に運用しようとすると、最後に少し怖くなる場面があります。メールを送る、WordPress記事を公開する、SNSに投稿する、ファイルを削除する、権限を変える、課金が発生する処理を実行する。こうした操作までAIに任せてよいのか、という問題です。
結論から言うと、AIエージェントにはまず「戻せる作業」から任せるのが現実的です。調査メモを作る、下書きを作る、差分を提案する、チェックリストを整える。こうした作業はAIの得意分野です。しかし、送信、公開、削除、外部共有のように、実行したあとで取り消しにくい操作は、人間の確認を残したほうが安全です。
この記事では、半農エンジニアラボのWordPress運用を例にしながら、AIエージェントに「送信・公開」を任せる前に作っておきたい安全チェックリストを整理します。AIを怖がって使わないためではなく、安心して使い続けるための線引きです。
AIエージェントは便利だが、実行権限を持つと性質が変わる
ChatGPTやCodexのようなAIを、相談相手や文章作成の補助として使うだけなら、失敗の多くは画面上で止まります。間違った要約が出たら読み直せばよいですし、変な文章が出たら直せばよい。コード案がよくなければ、採用しなければ済みます。
ところが、AIエージェントが実行権限を持つと話が変わります。ファイルを書き換える、APIを呼ぶ、WordPressに保存する、Slackやメールに投稿する、GitHubでPRを作る。こうなると、AIの出力は単なる案ではなく、外部の状態を変える操作になります。
もちろん、これは悪いことではありません。むしろ、実行まで進められるからこそ、AIエージェントは実務で役に立ちます。ただし、実行できるからといって、すべてを任せてよいわけではありません。人間側が「ここまでは任せる」「ここからは確認する」という境界を作らないと、便利さと危うさが同じ場所に集まってしまいます。
OpenAIのCodex Automationsは、定期的な作業をバックグラウンドで実行し、結果を確認するための仕組みとして使えます。たとえば毎朝のブログ調査、記事案の整理、参考URLの収集には向いています。一方で、このブログでは、WordPress公開やX投稿は自動実行しないルールにしています。便利な自動化ほど、最後の一線を決めておく必要があります。
最初に分けるべきは「戻せる作業」と「戻しにくい作業」
AIエージェントの安全設計では、作業を難しさだけで分けるよりも、「戻せるかどうか」で分けるほうが実用的です。
戻せる作業には、調査メモの作成、記事構成案の作成、ローカルファイルへの下書き保存、テスト用ブランチでのコード修正、PR案の作成などがあります。これらは失敗しても、削除したり、直したり、採用しなかったりできます。
戻しにくい作業には、公開済み記事の投稿、SNS投稿、メール送信、顧客への連絡、ファイル削除、本番DB更新、課金操作、権限変更、外部共有などがあります。これらは、あとから修正できたとしても、すでに相手に届いていたり、検索エンジンに拾われていたり、ログが残っていたりします。
AIに任せる作業を考えるときは、まずこの2種類に分けます。AIが得意そうかどうかより先に、失敗したときに戻せるかを見ます。戻せるなら、小さく試してよい。戻しにくいなら、DryRunや人間承認を挟む。これだけでも、かなり事故を減らしやすくなります。
危ない操作は「公開・送信・削除・課金・権限変更・外部共有」
AIエージェントに任せる前に、特に注意したい操作を6つに分けておきます。
1. 公開
WordPressの記事公開、予約投稿、商品ページ公開、ドキュメント公開などです。公開は、単にデータを保存する操作とは違います。読者、検索エンジン、SNS、顧客に向けて情報を出す行為です。半農エンジニアラボでは、WordPressへの保存は下書きまでにし、投稿ステータスは必ずdraftにするルールを置いています。
2. 送信
メール、Slack、問い合わせ返信、SNS投稿などです。送信は相手がいるため、誤送信のダメージが大きくなります。文面が少し違うだけなら修正できますが、相手に届いた事実は消せません。AIには文案作成まで任せ、人間が送信する形が扱いやすいです。
3. 削除
ファイル削除、投稿削除、DBレコード削除などです。バックアップがあれば戻せることもありますが、削除は復旧コストが高くなりがちです。AIに整理を依頼する場合でも、いきなり削除させず、「削除候補の一覧を作る」までに止めるのが安全です。
4. 課金
API利用、広告出稿、クラウドリソース作成、有料プラン変更などです。AIが作業効率化のために便利な設定を提案しても、料金が発生する操作は人間が確認すべきです。特にクラウドやAPIは、少額に見えても継続課金や従量課金につながります。
5. 権限変更
ユーザー招待、管理者権限付与、公開範囲変更、APIキー発行などです。権限は一度広げると、どこまで影響するか見えにくくなります。AIに設定手順を調べてもらうのはよいですが、権限付与そのものは人間が確認したほうがよいです。
6. 外部共有
Google Drive、GitHub、Slack、Notion、顧客向け資料などの共有です。リンクを知っている人なら見られる設定になっていないか、社外秘の内容が含まれていないか、共有先が正しいか。AIだけに任せるには確認点が多い操作です。
AIエージェント用の安全チェックリスト
ここからは、実際に使えるチェックリストとして整理します。半農エンジニアラボの運用では、これをWordPress、X、Threads、Codex作業に当てはめています。
実行前チェック
- この作業は、失敗しても戻せるか。
- 外部の人に届く操作ではないか。
- 公開、送信、削除、課金、権限変更、外部共有を含んでいないか。
- 秘密情報、顧客情報、APIキー、パスワードを扱っていないか。
- AIが使ってよいファイル、触ってはいけないファイルが明確か。
- 完了条件と確認方法が書かれているか。
実行中チェック
- AIが予定外の範囲まで変更しようとしていないか。
- エラーが出たときに、同じ処理を何度も繰り返していないか。
- 実行ログや変更内容をあとから確認できるか。
- ネットワーク、認証、権限エラーが出た場合に止まる設計になっているか。
実行後チェック
- 保存先、投稿ステータス、ファイル名、URLが意図通りか。
- 本文やコードが途中で切れていないか。
- 公開状態になっていないか。
- タグ、カテゴリ、抜粋などのメタ情報が適切か。
- 人間が確認すべき点が残っているか。
このチェックリストは、AIを疑うためのものではありません。むしろ、AIを仕事の流れに入れるための土台です。AIが毎回違う判断をしないように、先にルールを置いておく。これが、AIエージェント時代の作業設計だと感じています。
SE視点では、本番環境と秘密情報を特に分ける
SEとしてAIエージェントを使う場合、ブログ以上に気をつけたいのが本番環境と秘密情報です。
たとえば、ローカルのテストデータを直す作業と、本番DBを更新する作業はまったく別物です。開発用ブランチでコードを修正する作業と、本番デプロイを実行する作業も違います。AIがコマンドを実行できる環境では、この違いをプロンプトやルールに書いておかないと、思わぬ操作につながる可能性があります。
秘密情報も同じです。APIキー、WordPressのApplication Password、クラウドの認証情報、顧客情報は、リポジトリに直書きしない。AIの回答にも出さない。必要な場合は、.envや環境変数、CI/CDのSecret機能で扱う。この基本ルールを先に決めておくことが大事です。
AIエージェントは、指示されたことを進めようとします。だからこそ、「秘密情報は表示しない」「.envはコミットしない」「認証エラーが出たら止める」というように、止まる条件も明示しておく必要があります。
小さく始めるなら、調査メモと下書き作成から
AIエージェントを安全に試すなら、最初から送信や公開を任せる必要はありません。むしろ、最初は地味な作業ほど向いています。
たとえば、毎朝のAIニュース調査、参考URLの整理、記事案の比較、既存記事との重複確認、下書き本文の作成、X投稿文案の作成。このあたりは、失敗しても人間が確認して直せます。しかも、毎回の手間が大きいので、AIに任せる効果も出やすいです。
半農エンジニアラボでは、7:00と12:00の調査タスクを分けています。7:00は記事案作成、12:00は別切り口での調査。記事本文作成とWordPress下書き保存は、人間がチャットで依頼した場合だけ実行します。この分け方にすると、日次運用は進みますが、勝手に公開されることはありません。
AIエージェント導入で大事なのは、一気に全部を任せることではなく、安心して任せられる範囲を少しずつ広げることです。
AIに書くべき依頼文の例
安全な運用をしたいときは、AIへの依頼文にも禁止事項を入れます。たとえば、次のような形です。
目的：
この記事案をもとに、WordPress用の下書き本文を作成してください。
やってよいこと：
- 参考URLを確認して本文を作る
- drafts/配下にHTML本文を保存する
- WordPressにdraftとして下書き保存する
やらないこと：
- publish、future、privateを使わない
- 公開しない
- 予約投稿しない
- Xに投稿しない
- 秘密情報を本文やログに出さない
止めて相談する条件：
- WordPress認証に失敗した場合
- 下書き保存できたか確信が持てない場合
- 情報源が不足している場合
- 法務、税金、医療、農薬など高リスク判断が必要な場合
ポイントは、「やってほしいこと」だけでなく「やらないこと」と「止める条件」を書くことです。AIエージェントは、前に進む力があります。その力を安全に使うには、止まる場所も設計しておく必要があります。
完璧な安全策ではなく、毎回確認できる仕組みにする
ここまでチェックリストを整理してきましたが、これで事故を完全に防げるわけではありません。AIツールの仕様は変わりますし、WordPressやSNSのAPI仕様も変わります。人間側のプロンプトが曖昧になることもあります。
だからこそ、完璧な安全策を一度作って終わりにするより、毎回確認できる仕組みにするほうが現実的です。下書き保存後にステータスを確認する。公開操作を行っていないことを報告に含める。X投稿は実行していないと明記する。エラーが出たら重複作成せず、既存下書きを確認する。
こうした運用は少し面倒に見えます。でも、ブログ運用や副業のように長く続ける作業では、安心して繰り返せることのほうが大事です。AIエージェントを使うたびに不安になる運用では、結局続きません。
まとめ：AIを信頼する前に、失敗しても戻れる設計を作る
AIエージェントは、これからますます実行できることが増えていくはずです。調査、執筆、コード修正だけでなく、外部サービスとの連携、投稿、共有、更新まで担える場面が増えるでしょう。
そのときに大事なのは、AIを全面的に信じるか、まったく使わないかではありません。どこまで任せるか、どこで止めるか、何を人間が確認するかを決めておくことです。
まずは戻せる作業から任せる。公開、送信、削除、課金、権限変更、外部共有は人間確認を残す。WordPressならdraft固定、SNSなら文案まで、Threadsならドライランを挟む。こうした地味なルールが、AIエージェントを日常の仕事に入れるための土台になります。
半農エンジニアラボでも、AIに任せる範囲は少しずつ広げています。ただし、公開責任だけは人間側に残す。この距離感が、今のところいちばん現実的で、長く続けやすいAI活用だと感じています。
