発注がクソなら記事もクソになる
AI協働開発における指示の重要性

今日も元気に記事を全面書き直し！

皆さん、こんにちは。今日もAIとの協働開発で盛大に迷走した筆者です。

今回は「セッション管理の記事を書いて」という一見シンプルな依頼から始まった、壮大な記事改訂の旅をご紹介します。最終的に 3回も全面書き直し になった、この貴重な失敗体験から学んだことをシェアします。

発注の変遷 - どこで道を間違えたのか

第1弾：「セッション管理について書いて」

最初の発注はこれだけでした。AIは真面目に、開発における一般的なセッション管理の重要性について記事を書いてくれました。

# セッション管理で混乱を防ぐ
開発作業における記録の重要性について...

悪くない記事でしたが、何か物足りない...そう、具体性 がなかったんです。

第2弾：「実例を入れて」

「もっと具体的な例を入れて」と追加指示。AIは頑張って架空の例を作ってくれました。

例：Session-1でユーザー認証機能を実装し、
Session-2でデータベース設計を...

でも待てよ、これじゃ読者に響かない。そこで...

第3弾：「実際の失敗例を使って」

「今日の実際の失敗（DAILY_REPORTの矛盾）を使って書き直して」

ここでようやく、読者が「あるある！」と共感できる記事になりました。でも、この時点で既に 3時間経過。最初から明確に指示していれば15分で終わったはずです。

なぜこうなったのか - 発注者の3つの失敗

1. 目的が不明確だった

❌ 悪い例：「セッション管理について書いて」

✅ 良い例：「開発者がセッション記録の重要性を実感できる、失敗談を交えた実践的な記事を書いて」

2. 読者像が曖昧だった

記事の対象読者を明確にしていなかったため、一般論になってしまいました。

• 誰に向けて書くのか？（開発者？PM？）
• どんな問題を解決したいのか？
• 読後にどんな行動を取ってほしいのか？

3. 段階的な修正という罠

小出しに修正を依頼すると、AIは前の文脈に引きずられます。結果、パッチワークのような不自然な記事になりがちです。

AIとの協働開発 - 5つのベストプラクティス

1. 最初に全体像を示す

記事の目的：〇〇
読者：〇〇
トーン：〇〇
具体例：〇〇

2. 参考資料は最初に全部渡す

後から「あ、これも使って」は混乱の元。関連ファイルは最初にすべて共有しましょう。

3. 期待する成果物を具体的に

「良い記事」ではなく「失敗談を交えた、開発者が共感できる実践的な記事」のように具体的に。

4. フィードバックは建設的に

❌ 「なんか違う」
✅ 「技術的な説明が多いので、もっと体験談を中心に」

5. 失敗を恐れない（でも同じ失敗は避ける）

今回の失敗も、この記事のネタになりました。失敗は成功の母、でも 同じ失敗を繰り返すのはただのアホ です。

結論：クソな発注からは学びが生まれる

今回の経験から学んだこと：

1. 明確な指示 = 品質の高い成果物
2. 段階的修正より、最初から仕切り直し
3. 失敗を記録し、パターンを見つける

AIは非常に優秀ですが、魔法使いではありません。良い成果物を得るには、良い発注が必要です。

そして何より、失敗を恐れず、そこから学ぶ姿勢が大切。今日も元気に失敗して、明日はもっと上手く発注できるようになりましょう！

---

おまけ：今回の記事作成プロセス

1. 初回発注：5分
2. 書き直し1回目：30分
3. 書き直し2回目：45分
4. 書き直し3回目：60分
5. この反省記事：15分（最初から明確だったから）

教訓：最初の5分をケチると、後で2時間無駄にする。