TL;DR — この記事の要点
- AIが強いのは「制作（資料・コード）」「集計・分類・検算・診断」「ローコード＋ブラウザでの公開」
- こけるのは「本番システムへの自動デプロイ」「認証情報の壁」「無人スケジュール実行の前提崩れ」
- 失敗の主因は技術力ではなく、権限・セキュリティ・運用の前提。AIの賢さでは超えられない
- 成功した運用に共通するのは『送信・公開・確定は人が承認』というガード
棚卸しをしました。アレンジが社内でAIに実務を任せた38件のセッションを、成功も失敗もそのまま並べて見返した記録です。
うまくいった話だけ書くつもりはありません。こけた話のほうが、次に活きるからです。AIで何ができて、何がまだ無理なのか。その境界線は、賢いプロンプトの話ではなく、もっと地味な「権限・セキュリティ・運用」の話でした。
まず結論：境界線はここにある
BOUNDARY — 38 sessions reviewed
✓ 効く ：制作（資料/コード）・集計/分類・検算・診断・ローコード公開
! こける：本番への自動反映・認証情報・無人実行の前提崩れ
→ 効いた設計：送信/公開/確定は人が承認するガード
AIが効いた領域
1. 制作：資料・コード・クリエイティブ
ここが一番安定しています。ブランドのトーンを定義しておけば、品質を保ったまま量産できる。
- 経営者向けのAI研修資料を、図解・話法・試算まで含めて24枚通しで作成
- 体験後クロージング用のスライドと、入会率を上げる戦略デッキを2系統制作
- 広告の修正絵コンテを、現状の動画フレームを加工してビジュアル付きパネルで納品
- 調査レポートを、コードでブランド準拠のスライド14枚として自動生成
2. 集計・分類・検算・診断
「人が目視で照合していた作業」をAIに渡すと速くて正確でした。
- ジムのカレンダーから84日分の来店履歴を集計し、退会予備軍を週次でSlackに自動通知（退会者リストと突合して誤検知を除外）
- 全社員分の給与計算（固定給・固定残業の超過・交通費）を検算し、要確認点だけを抽出
- メール配信ツールのレポートを読み、「開封率が高い」の正体が到達数の少なさによる見かけ値だと見抜く（後述の配信事故）
- 受信メールを請求書／領収書／入金／要対応に自動分類しラベル付け
3. ローコード＋ブラウザで「作って・公開して・実機確認」まで
ノーコード基盤（Lovable等）とブラウザ操作を組み合わせると、一気通貫で動きました。
- 保護者向けの来店診断アプリを8項目改修して公開、実機で入会フローまで確認
- ECの商品ページを、根拠のない数値表現を消して景表法リスクを避けた表現に直して公開
- 自社サイトをAIクローラーに本文が届く形へ最適化し、本番公開
AIがこけた領域
ここからが本題です。止まった原因には、はっきりとパターンがありました。
失敗類型①：本番システムへの「自動反映」で壁に当たる
作るのはできる。でも本番に差し込む段で止まる。
- WordPressサイトへの構造化データ注入が、サーバーのセキュリティ（WAF）に弾かれて自動反映できず、修正コードを手渡しに
- 広告計測タグの自動公開を、本番の生きた計測を壊すリスクを避けて断念し、手順書を渡して人の手に委ねた
- アプリの自動ビルドは組めたが、署名鍵（キーストア）のパスワード失念と認証情報未作成で提出できず
失敗類型②：外部プラットフォームの障害・制約
こちらが万全でも、相手側で止まる。
- AI動画生成が、生成側のバックエンド障害で4本とも生成失敗→自動返金。代替ツールへ手作業で移すところで中断
- メール配信が、無料プランの日次300通上限で250通中227通が未送信＝実質的な配信事故。根本解は有料化のみ
失敗類型③：無人スケジュール実行の「前提崩れ」
自動で定期実行するタスクほど、地味な前提で転びます。
- 資金繰りモデルの更新タスクが、別セッションで作ったファイルに到達できず失敗（無人タスクは毎回まっさらで起動するのに、参照先が固定されていなかった）
- 勤怠チェックが、対象サービスにログインしていない状態で起動して中断（無人実行とログインセッションが分離している）
失敗類型④：本文の外にあるデータは取れない
- 請求書の金額が添付PDFやダウンロード先に隠れているため、メール本文からは取得できず「要確認」止まり
正直に書く：人的な誤認もあった
AIのせいにできない、こちら側の勘違いも記録しておきます。
- 「Notionに施策トラッカーを作った」という記憶が事実と違い、実際は別ツールで管理していた
- 広告が「0リード」だと思っていたが、別のイベント名で計測済みだった（診断して判明）
- ジムのアプリ改修と分析タスクを混同していて、前提のすり合わせに時間を使った
前提が違うと、AIは正確に「間違った作業」を量産します。最初の認識合わせが、成否の半分でした。
効いた設計：最後の一線は人が握る
うまく定着した運用に共通していたのは、賢いAIではなく、地味なガードでした。
| 工程 | 担当 |
|---|---|
| 下書き作成・要約・一次案 | AI |
| データ集計・分類・検算・診断 | AI |
| お金を動かす／外部に送る | 人 |
| 公開する／確定する | 人 |
メールは下書きまで、給与は閲覧して検算まで、広告は手順書まで。送信・公開・確定のボタンは人が押す。後戻りできない操作ほど、AIに自制させる設計が効きました。
AIは便利。でも、何を判断し何を実行するかは人が握る。
まとめ：境界線の引き方
- 任せる：制作（資料・コード）、集計・分類・検算・診断、ローコードでの制作〜公開検証
- 設計して任せる：定型業務の自動化（参照先を固定し、ログイン依存をなくす）
- 人が握る：本番への反映、認証情報、お金・送信・公開・確定の最終実行
- 最初にやる：前提の認識合わせ（ここを飛ばすと全部ずれる）
38回やって分かったのは、AIの限界はたいてい「賢さ」ではなく「権限と運用」にあるということでした。だから次も、完成度60%で出して、現場で動かしながら境界線を引き直します。
現場ログでは、こうした実験を毎日続けています。うまくいった話も、こけた話も、そのまま残します。
FAQ
よくある質問
AIは結局どこまで実務を任せられますか？
成果物の生成（資料・コード・分析）と、データの集計・分類・検算・診断は高い精度で任せられます。一方、本番システムへの自動反映や、署名鍵・認証情報・最終承認が絡む工程は人間が握る前提で設計すべきです。
うまくいかなかった原因はAIの性能不足ですか？
ほとんど違います。止まった原因の大半は、外部サービスのセキュリティ（WAF）、無料プランの送信上限、ログインセッション切れ、認証情報の受け渡しなど、AIの賢さとは無関係の『環境と権限の壁』でした。
自動化（無人で動かす）の注意点は？
無人タスクは毎回まっさらな状態で起動するため、別の作業で作ったファイルや前回の文脈に依存すると失敗します。参照先を固定し、ログイン状態に依存しない設計にすることが安定運用の条件です。
AIに任せるとき、人間は何を残すべきですか？
お金を動かす・外部に送る・公開する・確定する、の4つです。アレンジでは下書き作成や閲覧までをAIに任せ、最後の実行ボタンは必ず人が押す運用にしています。