amiiby
ぬにょす(挨拶)。
私は頻繁に AI に画面や文言の相談やお願いをします。「こういう風にするのはどう？」「こういう風にできないかな？」などと、かなり曖昧な言い方で。
すると、だいたい「これでどうでしょう」という提案が返ってくるわけですが。まぁ私も横着なもので、その提案をロクに読まず、あるいは読んでみてなんだかよく分からんぞと思いつつ。「じゃ、それで」と返してしまうわけですよ。
居酒屋で「今日のおすすめは？」と聞いて、説明を聞いたもののなんの料理かどんな味かもよく分からんまま、まぁおすすめだしねと「じゃ、それで」と言ってしまう。それと同じですわ。
それで案の定、あれ？ 思ってたのと違うな、となるわけです。分かってる。分かってるんだけど、かといって自分のイメージを正確に言語化して AI に伝えるというのは非常に難しい。言語化ではなく画像化するのはもっと難しい。
そんな折に見たのがこの動画。Omarchy 関連でたまたま観たのか、ちょっと経緯は忘れてしまいましたが、この動画の中で「3つ出して、1つ選ぶ」という話が出てくるんですわ。
Rails作者DHHが描くプログラミングの未来。AI時代にLinuxデスクトップが勝つ理由。Omarchyとは何か。omarchy公式サイトhttps://omarchy.org/何かと話題のDHH。彼の極端な主張が覇権を取る日は来るのだろうか。中国アリババはOmarchyに出資しAI NativeなOS搭載端末開発が噂されてもいます。ちなみに2026年の10月のKaigi on RailsでDHHが来日予定、またOmarch...www.youtube.com
これだ。と言うことで、AI に3つの案を1枚のページに並べさせて選ぶ、というのをスキルにしました。
yorozuya/.agents/skills/pick-three at main · miyabi-satoh/yorozuya複数の Claude Code セッションを手元で運用するための skill 集. Contribute to miyabi-satoh/yorozuya development by creating an account on GitHub.github.com
出てくるページ
出てくるページを模式図にすると、こんな形です。
Claude Code では、このページをアーティファクト（claude.ai に置かれる、自分だけが見られるページ）として出させています。気に入った案を選んで、理由を一言書いて「この案で決める」を押すと、AI がそれを読み取って作業を続けてくれます。
スキルの手順
スキルの手順部分を抜粋します。全部で8ステップです。
1. 何を選んでもらうのかを1文で決める（例:「削除の確認ダイアログで、使われているテンプレートの警告をどこに出すか」）。ページの見出しにする。
2. プロジェクトの決めごとに、同じ種類の判断が既に書かれていないかを見る。書かれていれば、3案を作らずにそれに従う。
3. 違いのはっきりした3案を作る。1つは一般的な形（よく知られたアプリの作法）にし、残りの2つは方針を変える。
4. 案の見せ方は、作る手間の安い方を選ぶ。
- 目安として、新しい画面は静的な HTML で再現する（動くコードがまだ無い）。
- 今ある画面の手直しは、実物を3通りに直してスクリーンショットを撮る（データや状態の作りが既にあり、HTML で作り直すと手間がかかるうえ実物とずれる）。撮るのはブラウザの自動操作（Playwright など）で。
- 文言だけの判断は、実際の画面の文脈（前後の項目・ボタン）に置いた形で見せる。文言だけを並べると、画面での読まれ方が分からない。
5. 3案を横に並べ（狭い画面では縦）、それぞれに短い名前と、ほかの案との違い・損得を1〜2行で添える。推奨を1つ示す。
6. ページを出し、返答の末尾で、ページを見て選んでほしいことを伝えてターンを終える。
7. 選ばれた案と理由を読み、その案で作業を続ける。理由が推奨と違えば、何を重く見たのかを読み取って、残りの作業にも当てる。
8. 選ばれた案と理由を、プロジェクトの決めごとに書く。ざっくり、作る前（1〜2）、案を作る（3〜5）、選んだ後（6〜8）の3つに分かれます。
作る前に、決めごとを見る（1〜2）
まず、何を選ぶのかを1文にさせます。これがページの見出しになります。
で、いきなり案を作らせるのではなく、プロジェクトの決めごとのファイル（UI の決まりや用語の表）に、同じ種類の判断が書かれていないかを先に見させる。書かれていれば、3案は作らずにそれに従います。一度決めたことを何度も聞かれるのは面倒なので。
案を作る（3〜5）
3案のうち1つは一般的な形（よく知られたアプリの作法）にして、残りの2案は方針を変えさせます。脳トレや間違い探しみたいな、よく見ないと違いが分からない、なんてことにならないよう「違いのはっきりした」という一言を含めています。
見た目で違いを捉えて、直感で「これがいい」を選ぶためのものなので、なるべく実物に近い形で比べたい。とはいえ、作る手間は抑えたい。ということで、静的な HTML のモックや実物を直したスクショでもいいよ、という安く済ませるための選択肢を与えています。
選んだ後（6〜8）
ページを出したら、AI はそこでいったん止まって、こちらが選ぶのを待ちます。アーティファクトにしたときの作りは、手順とは別の「出力」の節に書いています。
- Claude Code で Artifact ツールが使えるなら、アーティファクトとして出す。選んだ案と一言の理由を残す欄を置き、結果は `db` の機能に残して `ArtifactData` で読む。db はアーティファクトに持たせられる小さなデータベースで、ArtifactData は AI がそれを読み書きする道具です。ページで選んだ結果を、AI が直接読みに来ます。
最後に、選んだ案と理由を、プロジェクトの決めごとのファイルに書き足してもらいます。こうすることで、その後の実装における羅針盤となり、もし未来の私が大きく舵を切るような相談・依頼をしたときには「決めごとと違いますよ？」と考え直す機会を与えてくれます。
ちなみに、Claude はルールや決まりをかなり厳密に守ろうとします。あくまで体感で、ちゃんとした根拠はないですが、「そもそものルールや決まりがおかしい」という考えは持っていないようです。
なので、私はあえて「決めごと自体を組み直す」ことも選択肢の一つとするよう、AGENTS.md で指示しています。
- 案を縛る既存の決めごと（設計書・ADR・指示ファイルの決まり）は、前提にしていた状況が今も続いているかを先に確かめる。崩れていれば、例外を足す案でなく、決めごと自体を組み直す案を出す。組み直しは方針の変更なので、書き換えるのはユーザーに確かめてから。やらせないこと
手順とは別に、「やらないこと」も書いています。
- 見た目に出ない設計（データの持ち方・同期の方式・API の形など）でページを作る — 見ても差が分からない。3案を損得の表で比べ、推奨を添えて返す。
- 一般的な形が1つに決まっているもの（よくある入力欄・定番の確認ダイアログなど）で3案を作る — 1案と拠り所で足りる。
- 細部だけが違う3案を出す — 差が見えず選べない。配置・構成・語の選び方など、方針の違う3つにする。
- 案を作る前に、拠り所を飛ばす — 案はどれも拠り所（よく知られたアプリの作法・プロジェクトの既存の画面・用語の決めごと）に沿わせる。利用者の指示ファイルや skill に UI の好みや拠り所が書いてあれば、それにも沿わせる。なんでもかんでも3案出されたら、それはそれで疲れるので(´･_･`)
呼び出しは m 一文字
スキルの説明（AI がいつ使うかを決める欄）には、こう書いています。
description: 見た目で選ぶ判断を、3つの案を1枚のページに並べてユーザーに選んでもらう手順。画面の配置・ダイアログの形・文言や言い回し・問題文の書き方・グラフの見せ方など、見て差が分かる判断で一般的な形が1つに決まらないとき、こちらの提案にユーザーがほかの案も見たいと返したときに使う。指示ファイルのほうには、こう。
- 画面・文言・見せ方のように見て差が分かる判断で、一般的な形が1つに決まらないときと、提案に `m` が返ったときは、`pick-three` skill で3つの案を並べて選んでもらう。m は、前に書いた一文字の返事のひとつで、「もっと詳しく」の意味です。
AI の提案に m を返したときは、「ほかの案も見たい」と読ませています。1案で出てきて、なんか違うな、と思ったら m を一発。3案のページが出てきます。
まとめ
それこそ Vibe Coding が代表的ですが、AI を使った開発では、実装のみならず設計も AI に頼ることが多いです。そして、ほとんどの場合は「まかせた」「よきにはからえ」というスタンスでうまくいきます。
ただ、自分がこだわりたいところ・理屈ではなく感覚で好き嫌いが分かれるところなんかは、AI の「おまかせ」が「期待はずれ」になりやすい。
まぁ、あれですよ。複数の業者から見積もりを取れ、みたいな。比較検討することで、やっぱり当初の案が一番いいなとか、逆に「その発想はなかったけど、アリだな」とか。一手間増えるけど、何も考えずに即決するより得られるものは多いですよ。
でわでわ。