INDEX
はじめに
お疲れ様です。みんみんです。
入社して1年。配属されてからの毎日は、新しいツールの連続でした。
フロントエンドエンジニアの仕事というと、VS Code でコードを書いて、ターミナルで git push して、ブラウザで動作確認します。
そんなイメージを持たれている方も多いと思います。私自身、入社前はそう想像していました。
実際に配属されてみると、半分は合っていて、半分は違いました。
違っていたのは「ターミナルでコマンドを叩く」部分です。
Git のブランチ作成、コードレビュー、タスクの前さばき——こうした作業は今、ほぼすべて Claude Code 経由で実行しています。
これは「AI に仕事を丸投げしている」という話ではありません。
やるべき作業をより正確に、より速く実行するためにフローを設計した結果、Claude Code がそのハブになったという話です。
1日の流れ
- Claude Code を起動
- 当日タスクを確認
/branchでブランチ作成、コード実装/commitでコミット & プッシュ、その前に自動的に/reviewでセルフレビュー- MR を作成
VS Code を開くのは実装のステップのみです。
それ以外の開発オペレーションは Claude Code に集約しています。
Git コマンドを直接叩くことはほとんどなくなりました。
なぜそうなったか
理由は3つあります。
ブランチを切るたびに
git checkout main → git pull → git checkout -b ... と叩きます。コミットのたびに
git add → git commit -m → git push と叩きます。毎日同じことを手で打っている時間は、積み上げると馬鹿にできません。
ブランチ名の typo、コミット前の
git pull 忘れ、push 先の設定間違い。手動オペレーションにはミスがつきものです。特に急いでいるときほどミスは起きます。
コードを書いている最中に「あ、コミットしなきゃ」と手を止めて Git コマンドを打ち、「あ、ブランチ名なんだっけ」とタスクを確認しに行きます。
この切り替えが、集中力を削ります。
これらを解決するために、繰り返す作業を定型化して Claude Code に任せる方法を模索しました。その答えが「スキルファイル」です。
スキルファイルという仕組み
スキルファイルとは、業務フローを Markdown で定義したファイルです。
Claude Code はこのファイルを読み込んで、書かれた手順通りに対話形式でタスクを実行します。
考え方はシンプルです。
手順書を AI が読む → AI がコマンドを叩く
手順書のフォーマットが Markdown になっただけで、やっていることは同じです。
違うのは、実行の正確さと速度です。
スキルファイルの基本構造はこうなっています。
# スキル名
## Workflow
### Step 1: 最初の手順
何をするか、どう判断するかを記述する。
### Step 2: 次の手順
条件分岐がある場合はここに書く。
### Step 3: 完了条件
何をもって完了とするかを明記する。
スキルの配置場所：グローバルとプロジェクト
スキルファイルには、置き場所によって2つのスコープがあります。
~/.claude/skills/ に配置。すべてのプロジェクトから参照できる。
<project>/.claude/skills/ に配置。そのプロジェクト内でのみ有効。
この2層構造がポイントです。
Git オペレーションのようなどこでも使う作業はグローバル、チーム固有のルールや社内ツール連携のようなそのプロジェクト専用の作業はプロジェクトスコープに置きます。
使い分けることで、スキルファイルが肥大化せず、メンテナンスもしやすくなります。
グローバルスキル：汎用的な開発オペレーション
どのプロジェクトでも共通して使える、汎用的なスキル群です。
| /branch | チケット番号を入力すると、リポジトリの選択 → 未コミット変更の確認 → ブランチ名の候補生成 → main の最新化 → ブランチ作成まで、一連の流れが対話形式で進みます。 |
|---|---|
| /commit | 変更差分の確認、コミットメッセージの自動生成、push まで一気に実行します。 |
| /review | ローカルの差分、または MR の URL を渡すと、変更内容を分析してレビューを返します。言語ごとに専用のチェック項目を用意しており、対象ファイルに応じて観点が切り替わる設計にしています。 |
| /task:new | 朝一で実行し、前回チェック以降に追加されたタスクを洗い出します。その日対応すべきタスクがあるかを素早く確認する使い方です。 |
| /task:brief | タスク番号を渡すと、依頼内容・対象ページ・期限・注意点を整理して表示します。 |
プロジェクトスキル：そのチーム専用の業務ツール
プロジェクト直下の .claude/skills/ に置くスキルは、そのチーム・そのプロジェクトの事情に特化した処理を閉じ込めるのに向いています。
スキルファイルは Markdown + シェルコマンドで構成されるため、curl や独自 CLI を組み合わせるだけで、チーム専用の業務ツールになります。
| プロジェクト固有のページ / コンポーネント雛形生成 | そのプロジェクトの共通ヘッダー・フッター・SCSS 読み込みを含む新規ページやコンポーネントのベースファイル一式を生成 |
|---|---|
| プロジェクトの SEO / 構造化データチェック | 会社情報、E-E-A-T 対応など、そのプロジェクトの SEO 要件に沿った構造化データの検証 |
MCP — 外部ツールとの接続
Claude Code の拡張性を支えているのが MCP(Model Context Protocol)です。
外部ツールを Claude Code に接続し、ターミナルから直接操作できるようにする仕組みです。
Figma MCP
Figma のデザインデータに Claude Code からアクセスできます。
デザインファイルの URL を渡すと、コンポーネントの構造、カラーコード、余白の値などを取得して、そのまま実装の参考にできます。
Figma の画面と VS Code を行き来しながら数値を目視で拾う作業が、コマンド一つで完結します。
Chrome DevTools MCP
Chrome のブラウザ操作を Claude Code 経由で実行できます。
スクリーンショットの取得、DOM の検査、コンソールログの確認、ネットワークリクエストの一覧取得などが、ターミナルから可能になります。
実務では、実装後の表示確認やレイアウト崩れの調査に使っています。
「このページの特定要素のフォントサイズを教えて」と聞けば、Chrome を操作して値を返してくれます。
Lighthouse によるパフォーマンス監査もコマンドから実行できるので、品質チェックのハードルが下がりました。
Playwright — MCP と CLI の両方で使う
Playwright は E2E テスト用のブラウザ自動化フレームワークです。
MCP 経由と、素の CLI(npx playwright)の両方を使い分けています。
MCP 経由での使い方
Claude Code から自然言語で Playwright を操作します。
「このフォームに値を入れて送信、遷移先が正しいか確認して」といった指示で、その場で動作を検証できます。
テストコードを書くほどでもないアドホックな確認に向いています。
CLI での使い方
npx playwright codegen— ブラウザ操作を記録し、テストコードの骨格を自動生成npx playwright test— テストを実行npx playwright test --ui— UI モードで対話的にデバッグ
こちらはテストを資産として積み上げる用途です。MR 前のクリティカルフロー(ログイン、フォーム送信、決済画面の遷移)をテストコード化しておけば、次回以降は1コマンドでリグレッションチェックができます。
3つのブラウザ操作ツールの使い分け
Chrome DevTools MCP と Playwright(MCP / CLI)は機能が重なる部分もありますが、用途で使い分けます。
| Chrome DevTools MCP | 今目の前の画面を検査する(値の取得、一回限りの確認) |
|---|---|
| Playwright MCP | 自然言語で操作を再現する(アドホックな動作確認) |
| Playwright CLI | 操作をテストコードとして残す(繰り返し実行する資産) |
MCP の考え方
Figma も Chrome DevTools も Playwright も、それぞれ単体では既存のツールです。MCP が変えたのは、それらを Claude Code という一つのインターフェースから操作できるという点です。デザインの確認もブラウザの検証もテストの実行もターミナルから離れずに済みます。ツールを切り替えるコストが消えることで、作業の流れが途切れなくなりました。
Claude Code が向いていないこと
万能ではありません。正直に書きます。
| 実機での体感確認 | 実際のスマホでのタッチ操作の感触、アニメーションの滑らかさ、読み込みの体感速度など、自分の手と目で触らないと判断できない領域 |
|---|---|
| 人との相談 | 仕様の曖昧な部分、優先度の判断、「これどう思います？」という問いかけは、先輩やチームメンバーに聞くべき |
| 事実の検証 | AI は自信を持って間違えることがあります。公式ドキュメントや実際の動作との照合は必ず自分でやる |
特に最後の点は重要です。AI の出力を鵜呑みにせず、自分の目で確認する習慣がなければ、ツールに振り回されるだけです。
まとめ
1年目で学んだのは、個々のツールの使い方ではなく「フローを設計する」という考え方でした。
Git もレビューもそれ単体では便利なコマンドに過ぎません。しかし、それらを一連のフローとして Markdown に定義し、Claude Code をハブにして実行することで、作業に追われる時間が減り、設計や品質を考える時間が増えました。
「ツールを覚える」時代から「フローを設計する」時代になりました。
1年目のエンジニアでも、自分の仕事の進め方を自分で設計できます。
それが、この1年で一番大きな学びでした。
