
AIにコードを書かせていて、
「なんか思っていたのと違うな」と感じたことはありませんか?
このズレの原因の多くは伝達不足です。
しかし、具体的に指示を出しても、返ってくる物には多少のズレが出てしまいます。
そこで今回使ってみたのが 「grill-me」
実装に入る前に、AIの側から「この論点、どうする?」と質問攻めにしてくる、少し変わったSKILLです。
grill-me とは
普通のSKILLは「作業を代わりにやってくれる」方向のものがほとんどですが、
grill-me はその真逆で、まずは何も作らず、ひたすら質問を投げかけてきます。
仕様や方針についての問いに一つずつ答えていくことで、
AIに「何をどう作るのか」を正しく理解してもらい、実装のズレを未然に防ぐことができます。
こちらは Matt Pocock 氏が公開している SKILL のひとつです。
中身を見ると分かりますが、書かれている指示はとても短いです。
それでも実際に使ってみると、こちらが見落としていた細部まで仕様や設計をしっかり詰められることに気づきます。
実際に詰められてみた
題材は「詰めどころなんてあるの?」と思われそうな、カウンター付きボタンです。
与えた指示はこちらです。
/grill-me
C# でカウンター付きボタンに紐づけるメソッドを作ってください。前提
- 言語は C#
- UI フレームワークは MAUI
- メソッドはボタンのクリックイベントに紐づけて呼び出す仕様
- 呼び出すたびにカウント値を 1 加算する
- 初期値は 0
- 上限は 100
- 上限に達すると、ボタンは無効化される
早速、一問目の質問が来ました。
質問:「上限は 100、上限に達すると無効化」の境界をどう解釈しますか?
- 100を表示して無効化
- 99で止めて無効化
推奨:1
理由:「上限は 100」を素直に読むと、100 は到達可能な値で、その値において無効化される(= 100 が画面に表示される最大値)と解釈するのが自然。
これは、「上限」が到達可能な最大値なのか、それとも超えてはいけない境界値なのか、という曖昧さを突いた質問でした。
プロンプトを丁寧に書いても、言葉の曖昧性によって生まれるズレもありますよね。
続いての質問です。
質問:アプリの再起動をまたいでもカウントを保持するか?
- アプリ起動毎に0リセット
- アプリ生涯で計100回
推奨:1
理由:Preferences 等での永続化に触れていないため、スコープ外と判断するのが自然。
今回は、カウンターを作るだけだったので、そこまで想定していませんでした。
こういった想定外の質問が出てくるのも良いですね。
他にも、状態をどこに持たせるか、上限・初期値をハードコードにするか引数で渡すか...など、たかがカウンターで6問ほど質問されました。
ひととおり答えると、それらをすべて反映した実装方針が、迷いどころなくまとまって返ってきます。
あとはAIに実装させるだけです。
題材がカウンターなので結果は省きますが、想像どおりのものが出力されました。
メリット・デメリット
使ってみて感じたメリットとデメリットをまとめます。
メリット
- 伝え忘れだけでなく、想定していなかった論点まで作業前に洗い出せるので、実装後の手戻りが減る
- 選択肢と推奨を与えてくれるので、考えがまとまっていなくても選びながら仕様や設計を固められる
- ゼロから機能を考えるとき壁打ち相手として優秀
デメリット
- 質問に全部答えるまで、それなりに時間がかかる
- やり取りが続くぶん、トークンを消費する
感想
今回紹介したSKILLを実際の業務でも使ってみたのですが、
小さな機能一つに合計15問ほど質問されて正直なところ骨が折れました。
(プロンプトが曖昧だったのかもしれませんが...)
ただ、質問を終えたあとに返ってくるコードは、
こちらが思い描いたとおりのもので、修正や手戻りはほとんどありませんでした。
手戻りは、変更箇所や影響範囲を再確認する分、最初に実装するよりコストが大きくなりがちです。
そのため、先に仕様を丁寧に固めて一発で理想の実装ができるのは、個人的にかなり価値があると感じました。
この記事を読んで、ぜひ皆さんも試してみていただけると嬉しいです。
おわりに
KENTEMでは、様々な拠点でエンジニアを大募集しています! 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp