ClaudeでOOUIをSkill化！UI生成の構造を劇的に変える実践手法

• 事実と背景：Claude CodeにOOUI設計原則をAgent Skillとして与え、生成UIの構造変化を比較検証。
• 技術的変革：Skillありではメニューがオブジェクト起点になり、モーダルを排除したモードレスな画面構造へ進化。
• 現場への影響：AIへの曖昧な指示を脱却し、設計原則を共通言語としたコードレビューとプロンプト調整が可能に。

深夜のリリース直前、クライアントやPMから「なんかこの画面、使いにくいから直して」と抽象的なフィードバックを投げつけられ、絶望した経験は誰にでもあるだろう。「もっと直感的に」「いい感じに」という曖昧な言葉は、開発現場においてデッドロックを引き起こす最悪のインプットである。我々エンジニアは、どこをどう直すべきかを論理的に説明できず、場当たり的な修正パッチを当ててはスパゲッティコードを量産していく。この不毛なループは、AI駆動開発が主流となった現代においても、形を変えて牙を剥いている。

昨今、Claude CodeなどのAIエージェントを活用すれば、プロンプト1行から一瞬で画面のプロトタイプが生成されるようになった。そのスピード感は極めて魅力的だが、生成されたUIのクオリティには大きなバラつきがある。なぜAIは、機能要件を満たしているにもかかわらず、どこか使いにくい「タスク指向」の画面を作ってしまうのか。その原因は、我々が与える要件定義そのものにある。要件が「アップロード、検索、削除、アクセス権設定ができること」のように機能（動詞）の箇条書きで定義されるため、AIは素直にその動詞に対応するボタンやメニューを画面最上部に並べてしまうのだ。これが、ユーザーに特定の操作手順を強制し、迷いを生じさせる『タスク指向UI』の罠である。

この課題を突破する鍵が、ソシオメディアの上野学氏らが提唱する『オブジェクト指向UI（OOUI）』の設計思想だ。ユーザーがまず「もの（名詞）」を選択し、次に「やること（動詞）」を選択する。この現実世界の直感的な操作順序をUIに落とし込むことで、画面遷移は劇的にシンプルになり、ユーザーの認知負荷は下がる。しかし、この優れた設計原則を、どうやってAIエージェントに理解させ、自律的に実行させるべきか。単に「使いやすいUIにして」と頼むだけでは、AIは再び感覚的な迷路に迷い込むだけである。我々には、設計理論をAIが解釈可能な「共通言語」へと昇華させるアプローチが求められている。

抽象的な設計原則をそのままAIに渡しても、LLMは都合よく解釈してしまい、期待通りのコードは出力されない。そこで、株式会社エムニの黒川氏が試みたのが、OOUIの原則をClaude Codeの「Agent Skill」として構造化し、実行可能な「手順（アルゴリズム）」として定義するアプローチである。具体的には、SKILL.mdというファイルに、UIを書き始める前に必ず踏むべきステップを記述した。LLMは抽象論よりも、順番の決まったプロセスのほうが圧倒的に従いやすいという特性を突いた、極めて合理的なハックである。

定義された手順は以下の通りだ。まず要件から「オブジェクト（名詞）」を抽出し、動詞は一旦脇に置く。次に、オブジェクトごとに「コレクションビュー（一覧）」と「シングルビュー（詳細）」の2つのビューを決定する。そして、一覧から詳細、詳細から関連オブジェクトへとナビゲーションを繋ぎ、アクション（編集や削除など）は対象を選択した後に提示する。最後に「モードレス（作業の順番を強制しない）」であることを確認し、レイアウトは一番最後に決める。この厳格なプロセスをAIに強制することで、動詞起点での画面生成を根本から防ぐのである。

このアプローチの有効性を検証するため、2026年9月25日、Claude Code 2.1.282（モデル：Claude Opus 5.5）を用いて、同一のプロンプトからUIを生成する比較実験が行われた。お題は、複数のオブジェクト（文書、分類、利用者グループ）が絡み合う「社内文書検索システム（RAG）の管理画面」である。検証の厳密性を担保するため、生成されたHTMLとスクリーンショットは、条件を伏せた状態で別セッションのClaude 2体（モデル：Fable 5.1）にブラインド採点させるという、徹底した評価体制が敷かれた。以下に、その採点基準と結果のサマリーを示す。

ブラインド採点の結果は、構造面において「Skillあり」が10点満点を獲得し、「Skillなし」の8点を上回る結果となった。しかし、この数値の差以上に、生成されたUIの「アーキテクチャの思想」に決定的な違いが現れた点に、我々エンジニアは注目すべきである。最も顕著な差が出たのは、左側のメインメニュー（サイドバー）の切り口と、詳細画面のインタラクション設計（モードレス性）の2点であった。

「Skillなし」で生成された画面は、メニューが「文書一覧」「文書検索」「アクセス権」と、プロンプトに書かれた機能（動詞）の単位で分かれていた。さらに、文書のタイトルをクリックすると、画面全体を覆うモーダルダイアログが開き、背後の一覧操作がロックされた。これは、一つの作業を終わらせるまで他の作業を許さない、典型的な「タスク指向（モーダル）」の設計である。一方、「Skillあり」の画面では、メニューが「文書」「利用者グループ」というオブジェクト（名詞）の単位に整理されていた。そして、文書を選択すると、一覧の横にスプリットビュー形式で詳細が開き、詳細を開いたまま別の一覧を自由にクリックして表示を切り替えられる「モードレス」な構造が実現していた。Skillに記述した「オブジェクトを抽出する」「モードレスを確認する」という手順が、AIの出力コードの骨組みを完全に見直させた証拠である。

しかし、ジャーナリストとしての冷徹な視点を交えるならば、この結果を「OOUI Skillの完全勝利」と盲信するのは早計である。プロンプトで指定した7つの機能の実装数や、特定のタスクを完了するまでの手数（どちらも3手）には差がなかった。それどころか、「Skillあり」の画面には、JavaScriptのバグによる「nullnullnull」という不具合表示が発生していた。つまり、Agent SkillはUIの『設計思想（構造）』を正す強力な矯正ギブスにはなるが、コードの『実装精度（バグの有無）』や『機能の豊富さ』までを自動的に引き上げる魔法の杖ではない、という残酷な事実を示している。AIに設計思想を吹き込むことと、デバッグや肉付けを行うことは、全く別のフェーズとして捉えるべきなのだ。

今回の検証から我々が学ぶべきは、「すべてのUIをOOUIに改宗せよ」という極端な教条主義ではない。手順が固定された一本道のウィザードや、1回限りの設定画面など、タスク指向のほうが適しているユースケースも確実に存在する。重要なのは、管理画面やダッシュボードのように、ユーザーが探索的にデータを扱い、複数のオブジェクトを行き来する画面において、AIが安易に「使いにくいタスク指向の罠」に陥っていないかを監視し、コントロールする術を身につけることだ。

AIが生成したUIをレビューする際、あるいはプロンプトを調整する際、我々は以下の「3つの問い」を自分自身とAIに投げかけるべきである。

• 問い1：最初の画面に並んでいるのは「やること（動詞）」のボタンではなく、「もの（名詞）」の一覧か？
• 問い2：対象を1つ選んだ後に、初めてその属性やアクション（編集・削除など）が表示される流れになっているか？
• 問い3：作業の途中で、ユーザーが自由に別の対象へ移動できるか？（モーダルやウィザードで画面がロックされていないか？）

AIエージェントが1秒で数千行のコードを吐き出す時代において、エンジニアが「コードの書き手」としてしか価値を提供できないのであれば、そのキャリアは早晩デッドロックに陥るだろう。我々に求められているのは、コードを書く腕力ではなく、設計の「良し悪し」を論理的に言語化し、AIに正しい制約（Skill）を与えて導く「アーキテクトとしての審美眼」である。あなたのチームのAIエージェントは、今日も使いにくい『動詞起点』の画面を量産してはいないだろうか。その画面を救えるのは、設計原則という武器を手にした、あなた自身の言語化能力だけである。