はじめに
こんにちは。株式会社FLINTERSの小林です。
最近、エンジニアとして無意識に行っている判断プロセスを明文化し、AIプロンプトで共有するという試みを進めています。これは言わば「寿司職人のシャリの握り方を観察して寿司ロボットのアームを作る」ような作業です。
今回はフロントエンドの開発経験で身につけたUI/UXの「なんとなく」の判断や「直感的な」アプローチを、具体的な手順として言語化し、AIが実行可能な形に落とし込むことで、フロントエンドに明るくない開発者でもその知見を活用できるようにしています。
この記事では、その取り組みの一例としてUI設計作業における専門性をAIプロンプトで共有する例について、Claude Codeを使った実際のUI開発事例を交えながら紹介します。
実際の思考プロセスを振り返り・分析し、AIプロンプトとして再現可能な支援ツール群をClaude Codeで構築した過程をお伝えします。
設計アプローチを明文化する
要望を元にUI設計を行なった開発案件を通して、フロントエンジニアとして無意識に行っていた判断プロセスを詳細に振り返り・分析しました。これは「寿司職人のシャリの握り方を分解して理解する」のと同じアプローチです。
実際の開発事例
UI要望：
「親であるチェックボックスのラベルをマウスホバーした際、子の関係であるチェックボックス群が表示されるUIを実装したい」
前提条件：
- 実際にその通りにしてほしいという要望ではなく、「実現したいのはこういう感じ」というニュアンス
- 画面はグラフ表示機能におけるフィルター設定であり、チェックボックスで選択した要素がグラフ表示に反映される
設計時の思考プロセス
この案件を振り返った結果、以下の4つのステップで直感的かつ体系的に作業を進めていました：
ステップ1：要望で実現したい価値を理解する
UI要望と通常のUIパターンとして、常時、子のチェックボックスを表示する場合を比較し、その違いから「UIをシンプルに保ちたい」というのが要望価値と理解。
要望元にも確認し、実際にホバーで表示すること自体のこだわりはないと判明。
ステップ2：代替案の検討
一般的なUIの方が堅実なユーザビリティとなるため、ドロップダウンを選定した。
ただし通常のドロップダウンは1つしか選択できないので、複数選択可能とするようにした。
ステップ3：ユースケース目線での課題がないか調査
UI単体としては問題ないが、画面単位でユースケース観点で見たときに問題がないか確認。
確認の結果、今回のチェックボックスはグラフ表示対象の属性を選択する画面であるが、
ドロップダウンにすると選択状態が隠れてしまい、今のグラフ表示が「何を選択した結果なのか」が分からない課題を発見。
これにより、グラフをスクリーンショットで共有した際に、受け手が表示条件を理解できない問題が生じる。
ステップ4：最終的な調整
ドロップダウンで選択した項目をバッジ表示（選択済み項目を小さなタグ形式で表示）することで「UIのシンプルさ」と「選択状態の可視化」を両立（OSSのReact Select※ドロップダウンのOSSライブラリ を参考）
実際に作ったもの
上記のプロセスを経て、最終的に以下のUIを実装しました：
実装のポイント：
- ドロップダウン形式で子チェックボックス群を格納
- 選択済み項目をバッジで表示し、選択状態を可視化
- シンプルなUIを保ちつつ、選択中の条件が一目で分かる設計
専門性の属人化という課題
この判断プロセスには、以下の属人化課題がありました：
- 専門性の言語化困難：UI/UXの「なんとなく良い」判断の根拠が説明しづらい
- 分野間の知識格差：フロントエンドに明るくない開発者では同等の判断ができない
- 知見継承の困難：フロントエンド特有の思考パターンを他分野の開発者に共有できない
- プロジェクト効率の低下：フロントエンジニアが不在だと UI設計の品質が下がる
これらは、寿司職人の「塩梅」や「目利き」が他の料理人に伝えにくいのと同じ構造的な問題です。
専門性をAIプロンプトで共有するアプローチ
上記で明文化したこの思考プロセスを、AIプロンプトとして共有可能な形にする仕組みを構築しました。今回はClaude Codeのスラッシュコマンドやサブエージェントを活用して実装しています。これは「寿司職人のシャリの握り方を寿司ロボットのアームで再現する」のと同じアプローチです。
基本方針
専門知識の分解と再構築：
- 振り返り： 実際の判断プロセスを詳細に言語化
- 分析： 各ステップで何を考え、どう判断していたかを明文化
- 再現： その思考パターンをAIが実行可能な形に変換
人間とAIの最適な役割分担：
- AI担当： パターン認識、情報収集、網羅的分析、過去事例検索
- 人間担当： 創造的推察、文脈理解、最終判断、顧客との対話
設計思想：
完全自動化ではなく、「この思考プロセスを誰でも実行できる形にする」協働型アプローチ
設計の思考プロセスを共有するためのAIプロンプト群
1. 要望価値の理解支援コマンド
再現対象： 要望により実現したい価値の理解プロセス
# .claude/commands/ui-intent.md
---
description: UI要望の価値理解
---
提案されたUI: $ARGUMENTS
以下を実行してください：
1. 提案されたUIパターンの特徴を整理
2. 一般的な類似UIパターンを5つ調査・提示
3. 各パターンの違いと狙いを比較表で整理
4. 要望により実現したい価値やこだわりポイントを理解して提示
5. 比較根拠となる具体的な評価軸を提案
期待効果：
- 調査時間の大幅短縮を期待
- 網羅的なUIパターン調査により検討漏れを防止
2. 代替案検討エージェント
再現対象： 代替案検討プロセス
# .claude/agents/ui-alternative-designer.md
---
name: ui-alternative-designer
description: UI代替案の検討と提案を専門とするエージェント
tools: read, write, web_search
---
あなたは一般的なUI部品から最適な代替案を見つける専門家です。
要望を受け取ったら：
1. 要件を明確な条件として言語化
2. 一般的なUI部品ライブラリから候補を網羅的に検索
3. 実装コスト・UX・アクセシビリティで各候補を評価
4. 推奨案を根拠と共に提示
5. ユーザーの学習コストを考慮した判断基準を説明
期待効果：
- 専門的で一貫した評価基準による代替案選定
- 新人でもベテランと同等レベルの検討が可能
3. 課題予測支援コマンド
再現対象： 課題予測プロセス
# .claude/commands/use-case-check.md
---
description: ユースケース課題チェック
---
実装予定のUI: $ARGUMENTS
以下の観点で潜在的課題を検証：
1. モバイル対応での操作性
2. アクセシビリティ要件
3. 状態管理の複雑さ
4. 他人へのグラフ表示内容の共有シナリオ
5. 類似システムでの既知の課題事例
6. パフォーマンス影響の可能性
期待効果：
- 実装前の課題発見による手戻り防止
- チェック観点の標準化
4. 実績パターン活用エージェント
再現対象： 実績パターン活用プロセス
# .claude/agents/pattern-expert.md
---
name: pattern-expert
description: 過去の実装パターンと成功事例を専門とするエージェント
tools: read, web_search, conversation_search
---
あなたは実装パターンのデータベースとして機能する専門家です。
要求されたら：
1. プロジェクト履歴から類似実装を検索
2. オープンソースライブラリでの実装例を調査
3. 技術ブログ・ドキュメントから成功事例を収集
4. コードサンプルと実装時の注意点を整理
5. 最新技術トレンドとの整合性をチェック
期待効果：
- 過去の成功パターンの効率的な活用
- 実装リスクの大幅削減
これらのツールは必要に応じて組み合わせて使用することで、各プロジェクトの特性に合わせた柔軟な支援が可能になります。
Claude Codeによる開発支援の想定効果
上記のツール群を今回のような案件に適用した場合の想定効果は以下の通りです：
| 項目 | Before（従来の手動プロセス） | After（Claude Code支援による専門知識再現） |
|---|---|---|
| 実行者 | フロントエンドに明るいエンジニアのみ | フロントエンドに明るくない人でも専門的な分析が可能 |
| 調査時間 | 相応の時間が必要（専門知識があっても） | 大幅に短縮（ツール群の組み合わせ実行） |
| 検討品質 | 個人の専門知識に依存、属人的 | 再現性高 |
| 知見継承 | 困難（専門的な暗黙知として蓄積） | コマンド・エージェントとしてチーム資産化 |
期待されるメリット
定量的効果（想定）
- 設計時間の短縮： 大幅な短縮
- 分野間格差の縮小： フロントに明るくない開発者でもフロントエンジニア級の成果物を作成可能
- 知見の蓄積： エージェント・コマンドとして即座に共有・再利用
定性的効果（想定）
- 技術の民主化： フロントの専門知識をチーム内共有
- 継続的改善： 専門知識をコード化することで、さらなる改良が容易
- 組織学習の加速： 分野特有の経験をチーム・組織の共有財産として即座に活用
- チーム教育の革新： フロントエンジニアの思考プロセスを体験しながら学習可能
今後の展望
- 他領域への展開： DB設計、API設計におけるそれぞれの専門家の判断プロセスを観察・再現
- 専門知識データベース構築： 各分野のエキスパートの思考パターンを体系的に収集
- 開発プロジェクトのコンテキストをまとめたナレッジベースと連携： プロジェクト固有の背景情報や制約条件を考慮した判断支援
- 分野間での知見共有： フロントエンド、バックエンド、インフラなどの専門知識を相互活用
- MCPとの連携： Storybook MCPやFigma MCPなどを用いたインタラクティブ可能な状態でのUI部品生成、共有
- 継続的な専門知識の進化： AIとの協働により、従来の専門知識をさらに高度化
- 全社的な技術力底上げ： 各分野の「専門エンジニア」の知見を組織全体で活用
おわりに
今後のAIエージェントによる開発効率化は、単にAIに指示をするだけではなく、「各領域の専門性を明文化し、チーム全体で再現可能にする」ことが重要だと感じています。
今回の試みにより、従来「直感」や「経験」として個人の中に蓄積されていた高度な判断プロセスを観察・分析し、AIと協働することで以下を実現することができるとわかりました：
- 専門知識の明文化：専門エンジニアの思考パターンを具体的な手順として言語化
- 知見の民主化：専門外のエンジニアでも専門級の判断プロセスを実行可能に
- 品質の標準化：分野による知識格差を解消し、安定した成果物を創出
- 継承可能な資産化：各領域の専門知識をチーム・組織の共有財産として蓄積
これは「寿司職人のシャリの握り方を寿司ロボットで再現する」試みと同様に、個人の専門知識をチーム全体で活用できる形にする手法です。
今後のエンジニアリングは、従来の職人的な知識継承から大きく変化していくと考えています。Claude Codeのような技術により、専門家自身が自分の技術を観察・分析してAI支援ツールを作るアプローチが開発効率化の鍵になってくるでしょう。これにより個人の暗黙知を素早くチーム資産に変換できるようになり、このようなアプローチはますます重要になっていくと思います
Discussion