0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

話題の「grill-me」をCodexで試してみた ~AIが実装前に徹底的に要件を確認してくれるSkill~

0
Posted at

はじめに

少し前になりますが、話題になっていた「grill-me」をCodexで試してみました。

grill-meは簡単に言うと、

実装を始める前に、AIが要件を徹底的に確認してくれるSkill

です。

AIに開発を依頼すると、

  • AIが勝手に前提を補完する
  • 思っていたものと違うものができる
  • 修正を何度も繰り返す

ということがあります。

私も普段は「まず作ってもらって、あとで修正する」という使い方になることが多いのですが、grill-meは真逆です。

まず質問。
とにかく質問。

今回は実際にgrill-meを試して、その比較としてPlanモードも試しました。その内容を紹介します。

grill-meとは

以下で公開されているSkillです。

記述はいたってシンプルです。

---
name: grill-me
description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
---

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time.

If a question can be answered by exploring the codebase, explore the codebase instead.

日本語に翻訳すると、次の通りです。

---
名前: グリルミー
説明: ユーザーが計画や設計について徹底的に質問し、共通理解に達するまで、意思決定ツリーの各分岐を一つずつ解決していきます。ユーザーが計画のストレステストをしたい場合、設計について徹底的に質問されたい場合、または「グリルミー」と発言した場合に使用します。
---
この計画のあらゆる側面について、共通理解に達するまで徹底的に質問してください。設計ツリーの各分岐をたどり、意思決定間の依存関係を一つずつ解決していきます。各質問に対して、推奨する回答を提示してください。

質問は一つずつ順番に行ってください。

コードベースを調べることで回答できる質問の場合は、コードベースを調べてください。

難しい言葉ですが、共通理解に達するまで徹底的に質問してくるというのがポイントです。
言い換えると、出来上がったものが思っていたものと違ったというのを避けるために隅から隅まで徹底的に質問してくる、というものです。

実際にgrill-meを試す

Skillの配置

空の作業フォルダ(プロジェクトフォルダ)を作成し、そこにSKILL.mdを以下のように配置します。

.codex/skills/grill-me/SKILL.md

今回試したお題

今回はシンプルに、

架空の小さなカフェの紹介ページを作る

という内容で試してみました。

私はほぼ何も決めていない状態で依頼しています。


grill-meのやり取り

実際に試してみました。そのやり取りを以下に載せます。

grill-me: 架空の小さなカフェの紹介ページを1枚作りたいです。
雰囲気、メニュー、営業時間、場所、予約導線を載せます。
ブランド感、ページ構成、色、写真や画像の扱い、レスポンシブ対応をしてください。

最初の質問です。
このカフェは、誰に一番来てほしい店として設計しますか?

推奨回答: 「近所で落ち着いて過ごしたい20代後半から40代の人。ひとりで読書や作業をしたい人、週末に友人と軽くお茶したい人を主対象にする」

理由: 小さなカフェの1ページ紹介では、ターゲットを広くしすぎると雰囲気・写真・色・メニュー・予約導線がぼやけます。まず「静かに過ごせる日常使いのカフェ」に寄せると、ページ構成も作りやすいです。

この推奨回答で進めますか?それとも、別の客層にしますか?

この推奨回答で進めます

次の質問です。

このカフェの雰囲気は、どの方向に寄せますか?

推奨回答: 「静かで明るい、木の質感があるミニマルなカフェ。手仕事感は少しあるが、雑貨屋風やレトロ喫茶には寄せすぎない」

理由: 主対象が「ひとりで読書や作業をしたい人」と「週末に友人と軽くお茶したい人」なので、落ち着きと清潔感の両方が必要です。木目、自然光、余白、控えめな色を軸にすると、静的ページでも雰囲気が伝わりやすいです。

この方向で進めますか?それとも、もう少し「かわいい」「高級」「レトロ」「にぎやか」などに寄せますか?

推奨回答で進めます

次の質問です。

このページを、どのディレクトリに作成する想定にしますか?

推奨回答: 「現在の作業ディレクトリ直下に cafe-kohaku/ を作り、その中に index.html、styles.css、script.js、必要なら assets/ を置く」

理由: 既存ファイルと混ざらず、後でagentが実装・確認・削除・移動しやすいです。静的ページとして独立しているので、フォルダ単位で扱える構成が合います。

この推奨回答で進めますか?それとも、既存プロジェクト内の特定ディレクトリに入れますか?

推奨回答で進めます

次の質問です。

予約フォームには、どの入力項目を置きますか?

推奨回答: 「お名前、人数、希望日、希望時間、連絡先、ひとこと欄の6項目にする。送信ボタンを押すと、実送信せずに『予約内容の確認デモを表示しました』という短いメッセージを出す」

理由: カフェ予約として自然な項目に絞れていて、見た目だけのフォームでも実用的な導線として成立します。項目を増やしすぎないので、スマホでも重くなりません。

この推奨回答で進めますか?それとも、電話番号必須、メール必須、席タイプ、アレルギー、用途なども入れますか?

推奨回答で進めます

次の質問です。

予約フォームの位置は、ページ下部だけにしますか?それとも上部からもすぐ飛べるようにしますか?

推奨回答: 「フォーム本体はページ下部に置き、ヘッダーとヒーローに『席を予約する』ボタンを置いてフォームへアンカー移動できるようにする」

理由: ページの流れは雰囲気から理解してもらいつつ、予約したい人はすぐ動けます。1ページ構成ではアンカー導線が軽くて扱いやすいです。

この推奨回答で進めますか?それとも、フォームを中盤に置く、固定ボタンを出す、予約ボタンを控えめにするなどにしますか?

推奨回答で進めます

次の質問です。

Instagram導線は、どの見せ方にしますか?

推奨回答: 「ページ末尾に『季節のメニューと営業変更はInstagramで』という短い案内を置き、架空の @kissakohaku へのボタンを表示する。ヘッダーにも小さなリンクを置く」

理由: SNSフォローは副導線なので、目立たせすぎず、でも営業情報の確認先として意味を持たせるのが自然です。

この推奨回答で進めますか?それとも、Instagram投稿風のカードを並べる、SNSをもっと大きく見せる、XやFacebookも入れるなどにしますか?

推奨回答で進めます

次の質問です。

実装時の画像は、実際に生成して assets/ に置きますか?それとも、CSSの装飾と写真風プレースホルダーで表現しますか?

推奨回答: 「AI生成画像を使わず、CSSグラデーションや図形、写真風のプレースホルダーで純喫茶らしい雰囲気を作る。ヒーローとメニューカードには“写真枠”として成立するビジュアルを実装する」

理由: 今回はスキルの試験と軽めの静的ページ作成が目的なので、画像生成まで入れると工程が増えます。CSSだけなら index.html / styles.css / script.js で完結し、agentがすぐ実装・確認できます。

この推奨回答で進めますか?それとも、AI生成画像まで含めますか?

推奨回答で進めます

次の質問です。

最後に、実装後の確認基準をどうしますか?

推奨回答: 「PC幅とスマホ幅で表示確認し、1ページ内にヒーロー、雰囲気、メニュー、営業時間・場所、予約フォーム、Instagram導線がすべてあることを確認する。予約フォームのボタン押下でデモメッセージが出ることも確認する」

理由: このお題では本番連携より、構成・見た目・レスポンシブ・導線が成立していることが重要です。確認基準を先に決めると、agent作業の完了条件が明確になります。

この推奨回答で進めますか?それとも、アクセシビリティ、印刷、 Lighthouse、複数ブラウザ確認なども含めますか?

推奨回答で進めます

要件は十分に固まりました。最後の確認です。

この内容で、agentによる実装に進めてよいですか?

推奨回答: 「はい。現在の作業ディレクトリ直下に cafe-kohaku/ を作り、index.html、styles.css、script.js で静的ページを実装してください」

確定した内容は以下です。

架空カフェ名: 喫茶こはく
対象: 近所で落ち着いて過ごしたい20代後半から40代
雰囲気: 純喫茶寄り、静かな時間と定番メニュー
主目的: 来店・予約、Instagramは副導線
構成: ヒーロー、店の雰囲気、定番メニュー、営業時間・場所、予約フォーム、Instagram導線
メニュー: ネルドリップ珈琲、厚切り小倉トースト、固めプリン、ナポリタン
営業情報: 9:00-19:00、水曜定休、東京都杉並区西荻南3丁目、駅徒歩4分
色: 深い緑、琥珀色、クリーム、濃い木目ブラウン
フォント: 見出しはクラシックな明朝系、本文は読みやすいゴシック系
画像: AI生成なし。CSS装飾と写真風プレースホルダーで表現
予約フォーム: 見た目だけ。お名前、人数、希望日、希望時間、連絡先、ひとこと欄
動作: 送信ボタンでデモメッセージを表示
レスポンシブ: PC幅とスマホ幅で確認
この推奨回答で実装に進めますか?

推奨回答で実装に進めます

実装しました。静的ページは index.html、スタイルは styles.css、フォームのデモ動作は script.js にあります。

内容は、合意した「喫茶こはく」の1ページ構成で、ヒーロー、雰囲気、定番メニュー、営業時間・場所、見た目だけの予約フォーム、Instagram導線まで入れています。画像ファイルは使わず、CSSで純喫茶風の店内・メニュー・地図風ビジュアルを作っています。

検証は、HTML/CSS/JSの要件チェックとUTF-8文字列確認まで通しました。Playwrightはこの環境に入っていなかったため、実ブラウザのスクリーンショット確認は未実施です。HTMLはそのまま D:\codex\grill-me\cafe-kohaku\index.html をブラウザで開けます。

以上のやりとりで「架空の小さなカフェの紹介ページ」が作成されました。
作成されたファイルは以下です。

cafe-kohaku/
  index.html
  styles.css
  script.js

今回は、この環境にPlaywrightは入っていなかったため、実ブラウザの確認はしてくれませんでした。
Playwrightを入れておくと確認してもらえそうです。

比較としてplanモードで試してみる

grill-meの効果を確認してみるため、planモードで試してみます。
新規のフォルダを作成して試しました。

架空の小さなカフェの紹介ページを1枚作りたいです。
雰囲気、メニュー、営業時間、場所、予約導線を載せます。
ブランド感、ページ構成、色、写真や画像の扱い、レスポンシブ対応をしてください。

まず現在のワークスペースを確認して、既存のアプリ構成や使えるフレームワークがあるかを見ます。そのうえで、ページの仕様として決めるべきブランド方向だけ質問します。

ワークスペースは空なので、既存フレームワークに合わせる制約はありません。1枚ページとしては静的HTML/CSS/JSで作るのが最小で、画像は架空カフェに合う生成ビジュアルを使う前提で計画できます。

カフェのブランド感はどれに寄せますか?

静かな路地裏

予約ボタンの動作はどれにしますか?

フォーム表示

写真や画像の扱いはどれにしますか?

CSS中心

架空カフェ紹介ページ制作計画

Summary

  • 空のワークスペースに、静的な1枚ページとして架空カフェ「路地裏珈琲 灯」を制作する。
  • ブランド方向は「静かな路地裏」。落ち着いた大人向け、余白多め、低彩度、読みやすい日本語UIにする。
  • 画像はCSS中心で構成し、写真素材なしでも雰囲気が出るように、紙質・影・線・店内の抽象背景をCSSで表現する。
  • 予約導線はページ内フォーム表示。送信は実送信せず、入力後に確認メッセージを出すデモ仕様にする。

Key Changes

  • index.html を作成し、以下の構成にする。
    • ファーストビュー: 店名、短い紹介文、営業時間の要約、予約ボタン
    • 雰囲気: 路地裏・静けさ・少人数席を伝える本文
    • メニュー: コーヒー、焼き菓子、軽食の3カテゴリ
    • 営業時間: 曜日別または簡潔な週次表示
    • 場所: 架空住所、アクセス文、地図風のCSSパネル
    • 予約: 日時、人数、名前、連絡先を入力するフォーム
  • styles.css を作成し、レスポンシブ対応を入れる。
    • PCは横幅を活かした2カラム箇所を含む構成
    • モバイルは1カラム、CTAとフォームを押しやすいサイズに調整
    • 色は墨色、生成り、深い緑、真鍮系アクセントを使い、単色テーマにならないようにする
  • script.js を作成し、予約フォームの簡単な動作を入れる。
    • 必須項目の空欄チェック
    • 送信時に「予約リクエストを受け付けました」というページ内メッセージを表示
    • 実際の外部送信、DB保存、メール送信は行わない

Design Details

  • ブランド表現:
    • 店名: 路地裏珈琲 灯
    • コピー例: 静かな路地の奥で、湯気と余白を味わう。
    • 装飾は控えめにし、細い罫線、淡い紙色、落ち着いた影で雰囲気を作る。
  • 画像・写真の扱い:
    • 実写真や生成画像は使わず、CSSの背景、グラデーション、疑似的な看板・窓・メニューカードで表現する。
    • 地図も外部埋め込みではなく、CSSで簡易的な路地図風パネルを作る。
  • レスポンシブ:
    • 768px未満で完全1カラム化。
    • ナビ、CTA、メニューカード、フォームはモバイルで横スクロールや文字詰まりが出ないよう固定幅を避ける。
    • ヒーローの高さは画面を占有しすぎず、次セクションが少し見える構成にする。

Test Plan

  • ブラウザで index.html を開き、PC幅とモバイル幅で表示を確認する。
  • 確認項目:
    • 主要テキストが重ならない
    • 予約フォームが入力・送信できる
    • 必須項目エラーが表示される
    • CTAから予約セクションへ自然に移動できる
    • モバイルで横スクロールが発生しない
  • 実装後、必要ならローカルブラウザでスクリーンショット確認を行う。

Assumptions

  • ワークスペースは空なので、フレームワークは導入せず静的HTML/CSS/JSで作る。
  • カフェ名、住所、メニュー、営業時間は架空の内容をこちらで具体化する。
  • 予約はデモ導線であり、実際の送信先やバックエンド連携は含めない。
プランを実施する

実装しました。静的ページとして以下を追加しています。

  • index.html
  • styles.css
  • script.js

確認用の一時サーバーは http://127.0.0.1:4173/ で開けます。通常ブラウザなら index.html を直接開いても動きます。

検証済み:

  • 日本語表示、主要セクション、CSS中心のビジュアル表示
  • 840px幅相当で横スクロールなし
  • 予約フォームの必須エラー表示
  • 入力後の受付メッセージ表示
  • タブレット幅でヘッダーが不自然に縦長になる問題を修正済み

以上のやりとりで「架空の小さなカフェの紹介ページ」が作成されました。
作業フォルダに直接以下のファイルが作成されました。

index.html
styles.css
script.js

grill-meとplanモードを比較して分かったこと

実際に試してみると、grill-meとplanモードは似ているようで違うことが分かりました。

grill-meは、とにかく質問を重ねながら要件を固めていきます。

今回も、

  • 誰向けのカフェか
  • どんな雰囲気にするか
  • 予約フォームはどうするか
  • Instagramはどう扱うか

などを一つずつ確認してきました。

しかも、ただ質問するだけではなく、推奨回答とその理由まで提示してくれます。

そのため、「何を決めればよいのか」が分かりやすく、要件が曖昧な状態でも整理しながら進められます。

一方のplanモードは、必要最低限の質問だけして、すぐに実装計画の作成へ進みます。

細かい部分はAIが補完しながら進めるため、短時間で実装まで進めたい場合に向いています。

今回の結果を見ると、

  • 要件がまだ曖昧 → grill-me
  • 要件はだいたい決まっている → planモード

という使い分けが良さそうです。

個人的には、まずgrill-meで要件を整理し、その後にplanモードやagentで実装する流れが使いやすいと感じました。

まとめ

今回は話題になっていたgrill-meをCodexで試してみました。

最初は「質問をたくさんするSkill」という印象でしたが、実際には要件の抜け漏れを防ぎ、AIとの認識合わせを手伝ってくれるSkillだと感じました。

普段は、

とりあえず作る → 修正する

という流れで進めることも多いと思います。

それでも問題ない場合はありますが、作りたいものが曖昧で要件をはっきり出来ないときは、最初にgrill-meを使って要件を整理しておくと後の手戻りを減らせそうです。

「AIに思っていたものと違うものを作られた」という経験がある方は、一度試してみる価値があると思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?