AIとの意思決定、本当に効いたこと

課題
1. この記事でわかること
解決できたこと
本文

課題

AIに「どうしますか」と選択肢を出してもらって決める、という進め方はよくやる。ただ、選択肢を並べるだけで良い決定になるわけじゃない。何を並べれば意味があるのか、いまいち分からないまま進めていた。

この記事でわかること

選択肢を並べる以外に、意思決定の質を左右していた要素
選ばなかった案の記録や、決定後の前提変更にどう向き合うか

解決できたこと

選択肢を並べること自体より効いていた要素——不採用案の記録、自分からの逆提案、実装中の前提の見直し——を、実際に起きた4つの意思決定の場面から見えるようにする。

本文

「選択肢を出す」だけでは、実は半分しか意味がない

自分がAIと一緒に、パズルを中心にした5本のシンプルなアプリを個人開発していて、ここまで何度も「AIが選択肢を出す→自分が選ぶ」という決め方をしてきた。ただ振り返ってみると、選択肢を並べたこと自体より、そのあとの扱い方の方が効いていた場面が多い。

ここで紹介する4つの場面は、以前に書いた「作業を中断してもすぐ再開できるようにする記録の工夫」の話と、実は同じ期間（2026年7月28日〜29日）の記録から拾っている。同じ日々の記録でも、見る視点を変えると別の学びが出てくる、という実験でもある。

実例1: 採用した案より、不採用にした案の記録の方が後で役に立った話

5本のアプリを比較した上で、最初にストアに出す1本と、その改善内容を決める場面があった。「Block Puzzleを最有力候補にして、詰み救済策を追加してから出す」という案を選んだんだけど、この時、選ばなかった案（反応速度テスト先行リリース・Water Sortのレベル拡充後リリース・Number Mergeの現状リリース）もそのまま記録に残していた。

改善スコープの決定でも同じで、「Revive（復活）＋Undo（元に戻す）」を選んだ一方、「Reviveだけ」「Revive+Undo+Hintのフルセット」「救済策を増やさず広告頻度だけ見直す」という他の案も、選ばなかった理由（Hintは新規アルゴリズムが必要でスコープが大きくなる、等）とセットで残した。

採用した案だけ書き残すと、後から「なぜこれにしたんだっけ」を思い出せない。不採用案とその理由まで一緒に残しておくと、後になって状況が変わったときに「じゃあ、あの時見送った案を今なら選べるか」を判断しやすくなる。

実例2: AIの提案より、自分の逆提案の方が良かった話

ある機能の見直しで、AIが「こういう仕様にすればどうか」という対応方針を提案してきたことがあった。ただ、それに対して自分から「単純にパラメータを増やすだけじゃなくて、アプリを再開するとき、続きからやるか新しく始めるかを毎回本人に確認する方式にしたらどうか」という、まったく別の逆提案を返した。

この逆提案の方が明らかに良い設計だったので、そのまま採用して実装した。ここで気づいたのは、「AIが選択肢を出して、自分が選ぶ」という流れは一方通行じゃないということ。AIの提案がベストとは限らないし、自分側から出てくる別の案の方が刺さることもある。選択肢は「出す側」と「選ぶ側」が固定される必要はない。

実例3: 決めたあとも、実装中に前提が変わったら直していい話

詰み救済機能を実装するとき、当初は「広告表示のイベントにパラメータを付けて、リワード広告とインタースティシャル広告を区別する」という方針でチケットを起票していた。ただ実際に実装を始めて既存のコードを確認したところ、別のアプリ（Water Sort）では既に「イベント自体を分ける」という方式で区別していることが分かった。

新しく決めた方針より、既に動いている規則に合わせる方が筋が良いと判断して、その場で当初案を修正した。決定は一度固まったら終わりじゃなく、実装している最中に前提（今回は「既存の使い分け規則」）が分かったら、そこで直していい。むしろ直さない方が、後から不整合の元になる。