noto

AIへ細かな修正を繰り返しても品質が安定しないとき、指示を増やす前に問題の構造を見直す方法を、アプリアイコンの実例と5つの切替基準で紹介します。

『ルールは誰が・いつ実行するかまで決めないと定着しない』という記事を書いた直後、自分の運用ルールにも同じ穴が見つかった話。AIの口約束に実行力が無いという事実も紹介します。

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

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

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

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

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

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

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

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