AIに丸投げして逆に時間がかかった失敗
「AIに任せれば速い」は半分ウソだった。 自動化を本気で組んできた実践者の視点から。丸投げで詰まったパターン8つ。
事例01｜推定ロス：30〜60分
GitHub Actionsのワークフロー修正を丸投げ → リポジトリを間違えて適用
何を頼んだか 「このエラーを直して」とコードをそのまま貼った。
どこで詰まったか 2リポジトリ（threads-affiliate-reporter / threads-rakuten-bot）を並行管理しているのに、どちらのファイルを直すべきか指定しなかった。片方に反映したつもりが、もう一方のロジックだった。
なぜ失敗するか AIは「文脈から最もありそうな答え」を出す。複数の候補がある場合、黙って片方を選ぶ。「どちらか聞いてくれ」とはならない。
次回こうすれば防げた 冒頭に「対象：threads-affiliate-reporter の .github/workflows/post.yml」と1行書くだけで防げた。ファイルパスを明示する習慣をつける。複数リポジトリを扱うときは、作業開始前に「今回触るのはどのリポジトリか」を宣言してから依頼する。
事例02｜推定ロス：45分〜
投稿生成プロンプトの改善を一気に頼んだ → 禁止フレーズが混入
何を頼んだか 「もっと読まれる文章にリライトして」と一括依頼。
どこで詰まったか 禁止フレーズリストをその会話に渡していなかったため、アウトな表現が生成物に混入。承認フロー（14列のGoogleスプレッドシート）で引っかかるまで気づかなかった。
なぜ失敗するか AIは「読まれる文章」を最大化しようとする。制約を知らなければ、効果的だと判断した表現を何でも使う。「察してくれる」は期待できない。
次回こうすれば防げた 依頼文の最後に「※禁止フレーズリストを添付します」と書いてリストを貼る。プロジェクト機能のナレッジベースに禁止リストを常駐させておけば、この手間自体がなくなる。「いい感じに」と頼むときほど制約を先に渡す、を鉄則にする。
事例03｜推定ロス：1〜2時間
Amazonアフィリエイトのリダイレクト設計を一発で作らせようとした → セキュリティ要件が後出しになり全面書き直し
何を頼んだか WordPressクッションページ＋X投稿の自動化フローをまとめて設計依頼。
どこで詰まったか 最初にHMAC署名・GitHub Secrets・WAFといったセキュリティ要件を伝えていなかった。動くコードができてから「セキュリティも考えて」と追加したため、アーキテクチャから再設計になった。
なぜ失敗するか AIは指定されていない要件を「不要」と判断する。後から追加すると、すでに書いたコードの前提が崩れて全面修正になる。機能要件だけ先に固まって、非機能要件が後回しになるのはAI利用あるあるの罠。
次回こうすれば防げた 設計依頼の前に「制約シート」を1枚作る習慣をつける。「セキュリティ要件：HMAC署名必須、秘匿情報はGitHub Secrets管理、WAF設定あり」を箇条書きで渡してから「この制約の中で設計して」と頼む。機能の話をする前に、してはいけないことを全部出し切る。
事例04｜推定ロス：20〜40分
Supabase（pgvector）のナレッジベース設計を「いい感じに」と依頼 → APIコストが想定の3倍に
何を頼んだか ナレッジベースの検索ロジック設計。
どこで詰まったか 「APIコストを抑える」という大前提（Claude Haiku使用・コンテキスト取得を絞る）を伝えずに設計させたため、出てきた実装がフルコンテキスト取得の重い構成だった。動作確認後にコスト試算して初めて気づいた。
なぜ失敗するか AIはコスト感覚を持っていない。制約がなければ「完全に動く最善策」を出す。それが月数万円のAPIコストを生む設計でも、AIには関係ない話。
次回こうすれば防げた 「予算・コスト上限・使用モデル」を最初の一文に入れる。「Claude Haiku前提、1リクエストあたりのトークンを500以下に抑える設計で」と書くだけで出力の方向が変わる。コスト最適化は機能要件ではなく制約として伝える。
事例05｜推定ロス：30〜50分
長文の構成案を一度に全部作らせた → 方向性がズレていて最初からやり直し
何を頼んだか 「このテーマでThreads投稿10本分の構成案を作って」と一括依頼。
どこで詰まったか 10本全部出てきてから「なんか違う」と気づいた。1本目の時点でズレを確認していれば、残り9本の修正コストはゼロだった。
なぜ失敗するか AIは指示通りに最後まで走る。途中で「これで合ってますか？」とは止まらない。大量依頼ほど、最初の確認コストを省いたツケが大きくなる。
次回こうすれば防げた 「まず1本だけ出して。方向性を確認してからまとめて依頼する」と分割する。大量生成は「1本確認→OK→残り一括」の2ステップにする。10分の確認で1時間の修正を防げる。
事例06｜推定ロス：20〜30分
エラーメッセージだけ貼って「直して」と頼んだ → 的外れな修正案が返ってきた
何を頼んだか GitHub ActionsのYAMLエラーログをそのままコピペして「修正して」。
どこで詰まったか エラーは貼ったが、該当ファイルの全体像を渡していなかった。AIは断片から推測して修正案を出したが、実際のファイル構成と合わず適用できなかった。
なぜ失敗するか AIはエラーだけ見ても「どんなコードがそこにあるか」を知らない。知らないまま答えようとするので、ありそうな修正案を作る。それが実態と合わないことが多い。
次回こうすれば防げた エラーログ＋該当ファイルのコード全文＋「何をしようとしていたか」の3点セットで渡す。この3つが揃って初めてAIは正確に診断できる。エラーだけ貼るのはレントゲンなしで症状だけ伝えるようなもの。
事例07｜推定ロス：40〜60分
「ユーザーに刺さる投稿」を丸投げしたら、ターゲットがズレた文章が出てきた
何を頼んだか 「私のアカウント○○○○のフォロワーに刺さるThreads投稿を作って」。
どこで詰まったか 「AI×副業×ビジネス実践者」というアカウントのポジショニングをその会話で渡していなかった。出てきたのは汎用的なビジネス系投稿で、アカウントの色が全く出ていなかった。
なぜ失敗するか 「刺さる」の定義はアカウントごとに違う。AIにとって「刺さる投稿」はネット上の平均的な人気投稿を参考にした汎用コンテンツになる。ターゲット情報なしに「刺さる」は作れない。
次回こうすれば防げた 「このアカウントの読者は30代・副業に興味あり・AIツールを試し始めた段階・共感よりも再現性を求めている」のようなペルソナを先に渡す。プロジェクトのナレッジベースにペルソナ定義を常駐させておけば毎回不要になる。
事例08｜推定ロス：15〜30分
「前回と同じ形式で」と頼んだら、全然違う形式で出てきた
何を頼んだか 「さっきと同じフォーマットでもう1本作って」。
どこで詰まったか AIは会話をまたいだ記憶を持たない。同じ会話内でも、長くなると初期の出力を「忘れる」。「さっきの形式」が伝わっていなかった。
なぜ失敗するか 「さっきと同じ」はAIにとって最も曖昧な指示のひとつ。何が「同じ」なのかを明示しないと、毎回解釈がブレる。
次回こうすれば防げた 「前回と同じ」ではなく、フォーマットそのものをテンプレとして貼り直す。または「以下のフォーマットで：【フック】【本文3行】【CTA】」のように構造を文字で書く。良かった出力はテンプレ化してナレッジベースに保存しておく。
全事例に共通するパターン
丸投げで失敗するのは「何をしてほしいか」ではなく「何をしてはいけないか・何を優先するか・誰向けか」を渡していないとき。
AIは制約がないと最大限に動こうとする。コストも、セキュリティも、ターゲットも、フォーマットも——全部「指定がなければ自分で判断する」。その判断が自分の意図とズレたとき、丸投げは失敗になる。
AIへの依頼で最初に渡すべき3点
対象（どのファイル・どのアカウント・どの文脈か）
制約（やってはいけないこと・コスト上限・必須要件）
確認ポイント（全部作る前に1つ確認させる）
