AIに丸投げしたら8つ失敗した話｜非エンジニアの奮闘記録

これは目を覆いたくなるような失敗談だ。

目的はシンプルで、328MBのPDFを200MB以下に圧縮してNotebookLMに入れることだった。
スクリプトは完成した。ただし、やり方はほぼ全部間違っていた。

同じ鉄を踏まないためにも記録に残そうと思う。

この記事では、その失敗から逆算した8項目のチェックリストをまとめる。
3つは本文で詳しく解剖する。残り5つは付録でまとめて確認できるようにした。

まとめ

この記事はベストプラクティス通りの開発記録ではない。
「こうやったら失敗した」という観察記録だ。
コードは配布しない。手順の再現性も保証しない。
同じ失敗をした人の参考になれば、それで十分だ。

失敗までの経緯

Claudeに「PDF圧縮ツール作って」程度の粒度で丸投げをした。

筆者の成功体験として、PDFのサムネイルをコンタクトシート風にレイアウトするミニアプリ。２つ以上のPDFをただ結合するだけのミニアプリ。Illustrator上で特定の動きをさせるスクリプトなど、ちょこちょこAIによるコーディングを行っていた。

そのため、今回も簡単に作れるだろうと思い込み、気軽にClaudeに頼んだ。ただ、PDFの圧縮には落とし穴がいくつも用意されていた。

失敗の大本｜カスタム指示・プロジェクト指示への盲信

カスタム指示やプロジェクト指示には「最適かどうかを疑え」「巨人の肩に乗れ」「車輪の再発明をするな」と書いていた。
それでも機能しなかった理由は単純で、
カスタム指示は1回の入力に対して1回しか判断しないからだ。

ツールを作ってと投げた瞬間、AIは作り始める。
「ライブラリを比較したか」という問いが挟まる余地はない。
判断のトリガーを自分が引いていなかった。
カスタム指示は判断を代行しない。判断のきっかけを与えるだけだ。

AI開発失敗①｜プロジェクト外で始めた

最初の判断ミスは、素のチャット画面で始めたことだった。

Claudeにはプロジェクト機能があり、プロジェクト内で作業すると
設定ファイルやナレッジが自動で読み込まれる。
素のチャット画面ではそれが起きない。

「巨人の肩に乗れ」と書いたナレッジも、
「ライブラリは比較してから選べ」というチェックリストも、
どちらも読まれなかった。

AI開発失敗②｜ライブラリ比較を省略した

「PythonでPDFを圧縮したい」とClaudeに投げると、
最初に出てきたのがpypdfだっため、そのまま使い始めた。

pypdfはPDFの読み書きには便利なライブラリだが、
画像を直接書き換えるAPIに制約がある。
この壁に何度もぶつかり、その都度同じライブラリの中で
回避策を探し続けた。

これは出力圧と関係した「AIの慣性」と言う別の問題も内包している。
そのことは別の記事で述べたい。

一度決まった方向を変えるには、明示的なトリガーが必要だ。「3回詰まったらライブラリごと見直す」という指示を最初から入れておけば違った展開になっていたかもしれない。

AI開発失敗③｜動作確認を数値で見なかった

圧縮ツールが動いて、ファイルが出力された。
しかしファイルサイズは変わっていなかった。

処理はスキップされていたが、エラーも出なかったし、
ログも正常に見えた。

「動いている」と「正しく動いている」は別だ。

丸投げでも完成する理由

それでも、動くものができた。ライブラリ選定を失敗して、UIから作り始めて、1セッションで全部やって、それでも完成した。

なぜか。 具体的な問題があったからだ。

「PDF圧縮ツールを作りたい」という抽象的な目標ではなく、「この328MBの発掘調査報告書をNotebookLMに入れたい」という具体的な問題があった。

実際のPDFを渡して「縮まない」という事実があった。 具体的な問題があると、AIは診断できる。診断できると、原因が特定できる。原因が特定できると、次の一手が出る。

抽象的な目標に丸投げしても汎用的なコードが出てくるだけだ。具体的な問題に丸投げすると、その問題に特化した解決策が生まれる。

這々の体でも完成したのは、ベストプラクティスを踏んでいたからではない。問題が具体的だったからだ。

結び

完成したのは圧縮ツールだけではなかった。

8つの失敗が、8項目のチェックリストになった。
失敗は記録すると資産になる。次に同じことをやるとき、
同じ場所で同じ時間を失わないために使える。

あなたがAIとコードを書いて一番時間を失った場所はどこだろうか。
設計か、検証か、ライブラリ選定か。それとも別の場所だろうか。

こんな記事も書いてます。良ければお読みください。

FAQ

Q. AIにコード生成を頼む前に最初に決めるべきことは？
A. 仕様・成功条件・検証方法の3つだ。コード生成前にこれを決めるだけで、迷走の大半は減る。

Q. カスタム指示だけで開発品質は上がる？
A. 上がるが万能ではない。カスタム指示は判断を代行しない。判断のトリガーを引くのは自分自身になる。

Q. ライブラリ比較はどの程度やれば十分？
A. 最低2〜3候補を比較したい。後から変えると、それまでの実装が無駄になることが多い。

付録：ベストプラクティスと今回の比較

$$
\begin{array}{|l|l|c|}
\hline
\text{ベストプラクティス} & \text{今回やったこと} & \text{結果} \cr
\hline
\text{仕様書を先に作る} & \text{丸投げで即実装} & \text{❌} \cr
\hline
\text{小さく分割して反復} & \text{1セッションで全部} & \text{❌} \cr
\hline
\text{コンテキストを明示的に渡す} & \text{ライブラリ選定の文脈なし} & \text{△} \cr
\hline
\text{出力を評価・検証する} & \text{設計の検証がなかった} & \text{△} \cr
\hline
\end{array}
$$

次回から気をつけること（詳しくは別記事で）

プロジェクト内で作業する（素チャット禁止）

今回はナレッジなしで始めた。チェックリストも巨人の肩の話も、全部置いてきた状態でスタートしている。

ライブラリは3候補比較してから選ぶ

pypdfを即採用した結果、pymupdfという最適解を見落とした。最初に比較していれば到達までの時間が大幅に短縮できた。

対象データのフォーマットを先に診断する

PDFの中身を調べずに実装を始めたため、CCITTFaxDecode・JPXDecode・JBIG2・CMYKと問題が連鎖して出てきた。最初の10分で診断スクリプトを書けばよかった。

UIは最後に乗せる（ロジック単体テストが先）

UIを先に作ったせいで「動いているように見えるが圧縮されていない」状態が長く続いた。ファイルサイズを数値で確認するステップが最初からあれば早期に発見できた。

3回詰まったらライブラリごと見直す

AIの慣性が働く。一度pypdfで始まると「pypdfの中で解決する」方向に進み続ける。3回というトリガーを設けることで強制的に立ち止まれる。

セッションはタスク単位で分ける

診断・実装・デバッグを1セッションでやり続けた結果、レートリミットに何度も引っかかった。会話履歴の蓄積が一番重い。

bashの出力は絞る

診断スクリプトで全ページの詳細を出力し続けたためコンテキストが膨らんだ。printを絞るだけで同じ情報量を半分のトークンで得られる。

動作確認は数値で行う

「動いている」と「正しく動いている」は別物だ。今回は圧縮されていない状態が長く続いた。before/afterのファイルサイズを毎回確認するだけでいい。

出典

• Addy Osmani「AI-Assisted Development Workflow」（2025）

• Andrej Karpathy「Context Engineering」（2025）

• Thoughtworks「Vibe & Verify」（2026）