こんにちは！フロントエンドエンジニアのY.Kです。

新卒で入社してから早くも1年が経ち、少し驚いています。

私はこの約半年間、AIエージェント（特にClaude）を活用してきました。その中で、フロントエンドの設計に特化したSkillを作成するうえで気づいたことを、これからまとめていこうと思います。

初めに
初めてのSkill作成
気づき
Skillの改善
まとめ
おわりに

初めに

弊社では今年初めごろから、Claudeに関する情報交換や活用が活発に行われてきました。

そこで私はフロントエンドの設計に興味があり、Claudeの活用方法を見出したいという思いもあったため、フロントエンドの設計を一緒に考えてくれるSkillを作ることにしました。

当時の自分には、フロントエンドの設計に対して明確な思想がありませんでした。「なんとなく良さそう」という感覚はあっても、それを言語化・抽象化することができていなかったのです。 Skillを作るというテーマがあれば、半ば強制的にでも言語化・抽象化できるのではないかという期待もあり、実際に取り組んでみることにしました。

初めてのSkill作成

Skillの作成

Skillを作成するにあたって、最初は以下の方法で進めました。

プロジェクトではContainer/Presentationalパターンを採用しているため、まずClaudeにその内容を調べさせる。
Claude Codeでリポジトリを読み込ませる。
実際のコードから読み取れる設計を言語化させる。
プロジェクトの内容と明確に異なる部分については、自分の手で修正する。

この手順で、ひとまず動作するSkillが完成したため、実際に普段のプロジェクト業務で使ってみることにしました。

Skillを使った設計

作成したSkillを使ってClaudeと壁打ちした結果、とあるコンポーネントの設計は以下のようになりました。

異なるドメインの要素でも、見た目が同じであれば同一コンポーネント内で完結させる。
ドメインが異なるため型で入力・出力を厳密に定義する。
同一コンポーネント内で型とロジックでふるまい制御する。

この時点では、型とロジックで完全に制御し、異なるドメインであっても同一のコンポーネントから呼び出しているため、 見た目が統一され、壊れにくく、壊されにくい設計が実現できていると考えていました。

PRレビューで、、、

しかし、この設計をもとに実装を行ったところ、PRレビューで次のようなコメントをもらいました。

「別々のドメインであれば、それぞれにContainerを用意した方がきれいな設計ですよ。」

私はここで行った設計はあくまで

Claudeが推論した“よさそうな設計”であって、プロジェクトとしてよいとされる設計や、チームメンバーがよいと感じる設計ではない

ことにはじめて気づきました。

気づき

このレビューを受けた後、実際にチームメンバーに「どのような設計が好まれるのか」を直接聞いてみました。すると、次のような言葉が返ってきました。

「壊れにくい設計よりも、壊しやすい設計の方がいいと思う。」

ここで言っている壊しやすい設計というのは、壊れやすい（バグが発生しやすい）設計とは明確に異なります。壊しやすい設計は、開発の過程で行うスクラップ＆ビルドをやりやすくするための設計です。これは、私が関わっているプロジェクトがリリースされたばかりで変更頻度が高く、変更容易性を重視しているためです。

こうした前提や思想は、Claudeが調べたContainer/Presentationalパターンの中にも、当時の自分の中にもありませんでした。もちろん、Claudeとの壁打ちが完全に無駄だったとは思っていませんし、行った実装がすべて間違っていたとも考えていません。

しかし今回の経験を通じて重要だと感じたのは、チームメンバーの思想を理解したうえで、いかに自分の設計思想をブラッシュアップしていくかだという点です。生成AIが十分に台頭してきた時代だからこそ、新人エンジニアはこの思想（コンテキスト）を自らの中に確立するために、先輩エンジニアに直接話を聞くことが重要だと感じました。

Skillの改善

この気づきとチームメンバーから得られた設計思想をもとにSkillを以下の手順で再構築することにしました。

チームメンバーから得られた思想を言語化・抽象化する。
それらの情報をClaudeに渡し、Claudeが扱いやすい形に変換させる。
変換された内容のうち、得られた情報や思想と異なる点を修正する。

以前と明確に異なる点は、与えるべき思想（コンテキスト）が明確に自分の中にあることです。

まとめ

今回の取り組みを通じて、成長するためには自分の中でしっかりとした思想（コンテキスト）を確立する必要があり、Skillを作ることはそのきっかけになりえると感じました。

生成AIで実装速度が上がった分、チームメンバーの思想を理解することに時間を割くべきだと感じました。

最後に作成したSkillの一部を公開します。注意事項として、これはあくまで私が所属しているプロジェクトや、私自身にとって良いとされる思想（コンテキスト）をもとにしたものです。そのため、そのまま利用しても必ずしも良い設計になるとは限りません。むしろ重要なのは、この内容をそのまま適用することではなく、自分のプロジェクトやチームに合った形でコンテキストを定義し、それをもとにSkillを構築することだと考えています。本記事が、AIを活用した設計の進め方や、自身の設計思想を言語化するきっかけになれば幸いです。

---
name: architecture
description: コンポーネントの設計・リファクタリングを議論するスキル。
新規作成時だけでなく「このコードをどう整理する？」「責務が混ざっているから分けたい」「リファクタの方針を決めたい」といった既存コードの設計見直しにも使う。
「どう設計する？」「何に分割すべき？」「Server/Client どっちにすべき？」といった質問全般に対応。
コンポーネントの責務・props・状態管理・依存関係を整理して設計方針を一緒に考えたいときに積極的に使うこと。
「構造どう思う？」「この設計どう思う？」「コンポーネントの構造を見て」など、コンポーネントの構造・設計に対して意見や評価を求める問いかけでも必ず使うこと。
---

# architecture

「とりあえず作る」ではなく「なぜこう設計するか」を言語化しながら、コンポーネントの構造を一緒に考える。

## ワークフロー

スキル発動後、以下の順序で進める:

1. **対象を把握する**: ユーザーの質問が「新規設計」か「既存コードの見直し」かを判断する
2. **コードを読む**: 既存コードがあれば Read ツールで必ず読む。読んでいないコードへの言及は禁止
3. **要件を整理する**: データの出どころ・インタラクションの有無・変更頻度を確認する
4. **選択肢を複数提示する**: 設計案は1つではなく「複数案 + 推奨案 + トレードオフ」を出す

## 核心的メッセージ

**破壊しやすいコンポーネント設計を行う**: 共通化は最低限に、責務を明確に、変更の影響範囲を小さく保つ。仕様変更に柔軟に対応するための設計原則。

**深さ方向（先細り）— 末端は受け取るだけでいい、自分で考えてはならない**: 木の幹は根元が最も太く、穂先に向かうほど細くなる—　
コンポーネントツリーも同じで、根元に近いほどロジックは太く、穂先は「描画するだけ」が理想だ。細い穂先に降ろしてはいけないのは「このデータは何か」を判断するロジック。
`item.type === 'task' ? <TaskCard> : <FileCard>` のような種類の分岐は、太い幹が持つロジックだ。
一方、`isSelected ? colorA : colorB` のような表示状態の分岐は穂先でも正当——それはデータの種類ではなく、見た目の判断だ。フックに抽出したロジックは、そのフックを呼ぶ枝の太さに属する。

**幅方向（枝分かれ）— 独立した枝は、互いを知らないから美しい**: 
幹がある高さで枝分かれするように、ある階層のコンポーネントが複数の子ツリーへとロジックを分配するとき、木は枝分かれする。
それぞれの枝は独立したサブツリーを形成し、自分のサブツリーだけを責任範囲とする。枝が独立しているかの証明はシンプルだ——
「互いを知らないこと」。片方の枝がもう片方の状態を受け取り始めたとき、それはもう独立した枝ではない。共有されるべきロジックがまだ枝に残ったままのサインだ。

**判断ロジックには必ず名前をつけろ**: 裸のifはコードではなく謎かけだ。レビュワーは条件を読み解いて、文脈を想像して、やっと意図に辿り着く。名前をつけた瞬間、その旅が消える。

**ドメインが違えば型が同じでも別定義**: 実装が同一でもドメインが違うなら別の型として定義する。型は実装の都合ではなく、概念の境界を表すものだ。同じ実装でもドメインが違えば、それは別物。