オマカセ：見せてくれ
← 全記事具体的に反応できるものが手元にあるまで、自分が何を求めているかわからないことがあります。Claudeがその前に選択を求めてくると、作業を進めるためだけに好みを作り上げてしまいがちです。うまくいくこともあります。しかし、実在しなかった答えを巡って空回りを生むこともあります。
そのためにオマカセを作りました。アイデアはシンプルです。方向性の選択に行き詰まっているなら、Claudeが具体的なバリアントを構築し、本物の反応対象を与えます。トレードオフの箇条書きでも、長所と短所について整然とした段落でもなく。実際に見て、使って、評価できる実装を。
UHFで盲目の男性がルービックキューブを解くシーンがあります。これはそんな感じです。Claudeがキューブをいじります。私は色が合っているかどうかを告げます。パーツがどう合わさるべきかわからなくても、目の前のものが間違った形をしているときは大抵わかります。
一つの小さな例でその価値が明確になりました。
カレンダービューをCLIアプリに追加していました。大きな製品上の決断ではありませんでした。「カレンダービューがあるべき」と感じるほど簡単なはずの機能でしたが、実際には持っていないビジュアルの好みがあるふりをしていることに気づいた段階で、そうでもなくなります。アジェンダにすべきか？ 囲まれた週ビューか？ カウント付きの月グリッドか？ 基準を作り上げることに一時間費やして、その結果を正当化することにさらに何時間も費やしかねませんでした。
代わりに私は言いました：omakase it。
Claudeが3つの異なるアプローチを並列で構築しました。今日と明日のラベル付きシンプルな時系列アジェンダ。より強い視覚的グルーピングを持つ囲まれた週ビュー。ドリルダウン付きASCII月カレンダー。それぞれ、スケッチではなく本物の候補として感じられるほど十分に構築されていました。
それらを見た瞬間、意見が結晶化しました。
アジェンダビューが正しかったのです。週ビューは賢いが騒がしかった。月グリッドは楽しかったが、カウントだけでは有用ではありませんでした。タスク名が必要でした。これらの判断はどれも、事前に書き下せる形では存在していませんでした。反応できる何かができて初めて明らかになりました。
これがオマカセのコアバリューです：意思決定をアウトソーシングするのではなく、意思決定を判読可能にすることです。
最初の選択が壊れるとき
常に使っています。同じ機能で複数回使うこともよくあります。macOSのドットファイルビューアーを構築していて、エディタがSVGプレビューとどう関係すべきかで必要以上に時間を費やしました。実装が不可能だから行き詰まっていたのではありませんでした。現在のアプローチが擁護できるほど近く、満足できないほど間違っているから行き詰まっていたのです。オマカセが2つのクリーンなアーキテクチャオプションを与え、私はその形に反応し、一つを選び、空回りが止まりました。
そのプロジェクトのもう一つの例は、エディタに行番号を追加することでした。
Variant A — NSTextView subclass (LineNumberTextView.swift)
- Subclasses NSTextView, draws gutter in draw(_:) override
- Uses textContainerInset + manual text container sizing to avoid the invisible text bug
- Provides scrollableLineNumberTextView() static factory
- Simplest integration - swap one line in EditorView's makeNSView()
Variant B — NSRulerView (LineNumberRulerView.swift)
- Subclasses NSRulerView, draws in drawHashMarksAndLabels(in:)
- Static installation / pinned to the scroll view
- Minimal integration: add one line after scroll view creation
- Apple's recommended approach for gutter content
Variant C — Side-by-side NSView (LineNumberGutterView.swift)
- Standalone NSView, syncs via scroll view bounds notification
- Not integrated into scroll view internals → adds a composition layer
- Most isolation: doesn't touch text view internals at all
My take: B is the cleanest — one-line integration, uses Apple's built-in infrastructure
行番号への3つのアプローチ。私はこれの約30%しか理解できませんでした。それで問題ありませんでした。
はっきり言います：私はSwiftを知りません。NSTextViewサブクラスとNSRulerViewとスタンドアロンのガターNSViewの違いが何であるかまったくわかりません。Claudeが単純に選択を求めていたなら、私は当て推量していたでしょう。
しかしオマカセは私にテクノロジーを評価するよう求めませんでした。3つの動作するバージョンを見せて、どれが正しいと感じるかを尋ねました。
オマカセはオプションを評価し、NSRulerViewパスを推薦しました。書面上では最もクリーンな統合でした。接続するのに一行。テキストビューの内部への最小限の侵入。私はそれを選びました。
そして壊れました。
以前の試みを悩ませていたウォッシュアウトレンダリングバグのために、エディタのテキストがほぼ見えなくなりました。通常のワークフローでは、そのような種類の失敗はすぐに最初に戻らせかねません。アーキテクチャ上の問題を再開し、方向性への自信を失い、代替案を再発見することに時間を燃やします。
しかし代替案はすでにそこにありました。
代わりにスタンドアロンのガタービューを入れ替えました。スクロールビューの内部の脆弱さを避け、クリーンにビルドされ、出荷されました。劇的なリセットなし。リアーキテクチャのスパイラルなし。間違いのコストは、空間がすでに探索されていたために下がっていました。
これがパターンの過小評価された部分です。オマカセは推薦された答えが正しいときだけ有用なのではありません。最初の選択が間違いだった爆発半径を下げるから有用なのです。複数の実行可能なパスを見た後は、ピボットが失敗ではなく選択圧力のように感じられ始めます。
実際にどう使われているか
チーム全体で、人々は異なる理由でこれを使います。感情が本物の不確実性のこともあります：I literally do not know. Omakase. It better be cool. 単純な決断疲れのこともあります：Omakase. I do not want to make this call right now. 勝ち取った信頼のこともあります：I think you have this. Use the omakase. 異なるきっかけ、同じメカニズム。何かを見せてくれ。私に反応させてくれ。それから決める。
この言葉が重要です。なぜなら「見てわかる」はよく曖昧さや回避として捉えられるからです。時々そうです。しかし時々それは、判断がどのように機能するかの正確な説明です。いくつかの好みは対象が存在するまで潜在的です。存在した瞬間に、選択は明確になります。
試してみる
オマカセはClaude CodeのTest Kitchenプラグインの一部です。
/plugin marketplace add 2389-research/claude-plugins
/plugin install test-kitchen
