AI活用術

公開後の記事を確認するために使ったAI Toolが、実際には存在しない誤字や誤変換を報告してきた話。確認そのものにAIを使うときに気をつけたいポイントを紹介します。

AIの見落としを踏まえてRuleを追加した直後、次の記事で早速同じ種類の見落としが再発した話。『またミスった』で終わらせず、Rule自体の構造を疑い直した経緯を紹介します。

TitleもCategoryも合っているのに、本文だけ古いまま公開されていたり、SEO欄だけ違う文字列が入っていたりした話。『ほぼ合っている』ときこそ生データで確認する理由を紹介します。

『4つのファイルで開発の迷子を防ぐ』運用を実際に2週間ほど続けてみたら、同じ型の綻びが3回連続で見つかった話。ルールを書くだけでは足りなかった理由を紹介します。

いつもは数十秒で終わるはずのテストを、AIが80分以上待ち続けていた話。指摘して初めて分かった原因と、通知だけに頼る危うさを紹介します。

自動テストは全部パスしていたのに、実際にゲームをプレイしていて『あれ、おかしいな』と気づいた不具合の話。原因調査から、元の設計意図を壊さない直し方までを実例で紹介します。

AIが『前と同じ方針でいい』と即答した提案を、そのまま受け入れずもう一度理由を聞き直したら、結論が変わった話。同じ日にもう1件あった前提の訂正も合わせて紹介します。

将来の機能のために仕込んでおいた仕組みが、一度も使われないまま審査の書類作成で初めて負債として発覚した話。安全に削除するまでの判断と確認の手順を実例から紹介します。

『対応不要』と結論づけた報告書の一言が引っかかり、審査提出済みのAppの画像に実際に問題が写り込んでいることを発見した話。AIとの並行作業で、報告の要約だけでなく中身まで読む大切さを実例から紹介します。

たった1日で4回、自分の一言でAIの見落としが発覚した実話。実装漏れや計算バグの発見・修正の過程と、『なぜ直したか』を記録するルールが生まれるまでの経緯をそのまま紹介します。