## はじめに

前回の記事「[Claude Codeで始めるISSUE駆動開発](https://sterfield.co.jp/blog/claude-code-issue/)」を公開したのが2025年12月でした。それから約4ヶ月、自分の開発環境は当時とはかなり違うものになっています。特にIDEをほぼ開かなくなったのが、一番の変化でした。

本記事では、12月時点の環境からどのように変わったのか、そのきっかけとなったツール導入や運用の変化を振り返ります。

## 12月時点の環境

前回記事を書いた頃の開発環境は、以下のようなものでした。

- エディタ：Visual Studio Code（以下、VSCode）
- AI：Claude Code（VSCode拡張機能）

VSCodeの中ですべてが完結していました。Claude Codeは拡張機能としてサイドパネルに常駐し、指示はそこで出す。コードはエディタで読み書きする。GitHub ISSUEの読み書きやgit操作も含めて、日々の開発はほぼこの一画面で回せていました。IDEが作業の中心だった、という言い方がしっくりきます。

## 今の環境

現在の環境は、以下のようになっています。

- エディタ：[Zed](https://zed.dev/)（たまに開く程度）
- AI：Claude Code CLI、[cmux](https://cmux.com/ja)で複数セッションを同時起動
- Markdownプレビュー：[mo](https://github.com/k1LoW/mo)、もしくはPRを作ってGitHub上で確認

作業の中心はターミナルに移りました。

Claude Codeにタスクを渡したら、あとはエージェントが動きます。コードを確認したくなったときだけZedを開いて眺める程度で、編集することはほぼありません。このブログ記事の執筆も同じ流れで、プレビューはターミナルからmoを叩くか、PRを作ってGitHub上で確認するのが基本です。

## 何が変わったのか

12月時点でも、Claude Codeを使って一通りの開発は回せていました。VSCodeを開き、拡張機能を通じてClaude Codeに指示し、一つの作業を一つずつ進める。それで十分機能していたのです。

そこから変わったのは、複数の作業を同時に走らせられるようになったことです。きっかけは主に2つありました。

### 1. cmuxによる複数セッションの並走

1つめは、[cmux](https://cmux.com/ja)の導入です。

cmuxは、Claude Codeをはじめとするコーディングエージェントを複数同時に実行・管理するためのデスクトップアプリケーションです。各セッションを独立したタブとして扱い、それぞれのエージェントの状態を一目で把握できます。現時点ではmacOSのみの対応です。

画面には常に4〜5個のClaude Codeが並んでおり、それぞれ別のリポジトリ、別の機能、別のバグを担当しています。一つにバグ修正を頼み、別のセッションにリファクタを投げ、さらに別のセッションでドキュメントを書かせる。どれかが考えている間に、どれかが実装を終えている。以前なら順番にこなしていた作業が、いくつもの並列レーンで同時に進んでいく感覚は、これまでの開発体験にはなかったものです。

![cmuxで複数のClaude Codeセッションを並走させている様子](https://cont.sterfield.co.jp/uploads/cmux_parallel_sessions_83c193db65.png)

### 2. git worktreeを使ったPRレビュースキルの整備

2つめは、git worktreeを活用してPRをレビューするためのClaude Codeのスキルを整備したことです。

worktreeで別ディレクトリにPRブランチをチェックアウトし、そのディレクトリ上でClaude Codeを立ち上げてレビューを進める、という仕組みです。これを整えたことで、メインの作業ツリーで別ISSUEの開発を進めながら、同じリポジトリのPRレビューも並行して走らせることができるようになりました。

worktreeを使わずにブランチを切り替えてしまうと、進行中の作業が一時的に止まってしまいます。worktreeを前提にすることで、作業の文脈を切らずにレビューだけを別トラックで走らせられるようになりました。

### IDEの立ち位置の変化

この2つが組み合わさったことで、同一リポジトリ内の複数作業はもちろん、別リポジトリの作業までも並行できるようになりました。そうなると、作業の中心は自然とターミナルに寄っていきます。

VSCodeはもともと「書く・読む・実行する」のすべてをこなす場所でしたが、今はZedに乗り換えた上で「読む」しかしていません。しかも常時開いているわけでもなく、必要なときだけ立ち上げるスタイルです。

もちろん人間側のボトルネックはあります。5つのPRが同時に上がってくれば、レビューするのは自分ひとりです。それでも「手が足りないから諦める」が減り、「やりたいことを同時に走らせてみる」が選択肢に入ってきたのは大きな変化でした。一人で開発しているのに、まるで小さなチームを抱えているような気分になります。

## まとめ

「AIをIDEの中で使う」から「AIを中心に置いてIDEを脇に置く」へ。構造の逆転が起きたというのが、この4ヶ月の一番の実感です。ツール選びの軸も「書きやすさ」から「エージェントとの並走のしやすさ」に変わりました。

cmuxによる複数セッションの並走、git worktreeを活用したレビュースキルの整備。どちらも派手な話ではありませんが、組み合わせることで「一人で複数のエージェントを指揮する」開発スタイルが現実のものになりました。

Claude Codeを日常的に使っている方は、ぜひcmuxやworktreeとの組み合わせも試してみてください。開発の体験が一段変わると思います。

large_eyecatch.jpg

medium_eyecatch.jpg

small_eyecatch.jpg

thumbnail_eyecatch.jpg

eyecatch.jpg

AIエージェントを中心に据えた開発環境への移行

## はじめに
エンジニアにとって、デザインツールは「見るもの」であって「操るもの」ではありませんでした。しかし、**Claude Code**の登場でその境界が壊れようとしています。  
  
今回は、AIネイティブなデザインツール **<a href="https://www.pencil.dev/" target="_blank" rel="noopener noreferrer">Pencil</a>** と、定番の **<a href="https://figma.com" target="_blank" rel="noopener noreferrer">Figma</a>** をClaude Code経由で連携させ、実際のUIコンポーネントを移植・比較検証した記録をシェアします。  

---

## 1. なぜ「Pencil」なのか？
Figmaは登場から安定な人気を誇っており、エンジニアやデザイナーに広く利用されています。  
しかし、エンジニアがAI（LLM）を使ってデザインを自動生成・修正しようとしたり、デザインをHTMLなどのプログラムコードに変換しようとすると、Figmaの複雑なデータ構造が壁になることがあります。  

そこで注目したのが**Pencil**です。  
* **JSONベース:** デザインがコード（.penファイル）として管理できる。
* **Git親和性:** デザインの差分が**git diff**で見える。
* **Claude Code連携:** CLIから「このボタンを赤くして」でデザインファイルが直接書き換わる。

今回は、Figmaで作成したUIをPencilに移植する検証と、FigmaとPencilそれぞれからHTML/CSSへの変換精度を比較してみました。  

---

## 2. 【検証】FigmaからPencilへの「移植」実験
実際に、Figmaで作成した「かえるさん」の投稿リストUIを、Claude Codeを使ってPencilへ移植してみました。  
今回は、デスクトップ版のFigmaを使用し、MCPサーバ経由でデータを取り込む方法を選択しました。  
PencilはVisual Studio Codeの拡張機能版を利用しました。  
詳しいインストール方法やセットアップは<a href="https://www.pencil.dev/downloads" target="_blank" rel="noopener noreferrer">公式ドキュメント</a>を参照してください。  

### Figmaでの事前準備

FigmaのMCPサーバでClaude Codeに情報を取り込む際は、Figmaデスクトップアプリを利用します。  
このとき、Claude Codeに渡すリンクは**DEV Mode用のリンク**を使用してください。デザイン共有用のリンクよりも正確なCSSプロパティを取得できます。  
また、移行したい画像は、Figma上でエクスポートの設定をしておくと、Pencilへの画像の移植がスムーズになります。  
  
| ⭕️ | ❌ |
| :---: | :---: |
| DEV Mode 用のリンク | デザイン共有用のリンク | 
| ![DEV Mode 用のリンク](https://cont.sterfield.co.jp/uploads/figma_dev_mode_link_de1a34f2f1.png) | ![デザイン共有用のリンク](https://cont.sterfield.co.jp/uploads/figma_design_link_5cbfb1ad90.png) | 
  
### 比較結果
| 項目 | 元のFigma | 移植後のPencil |
| :--- | :--- | :--- |
| **レイアウト** | オートレイアウトで緻密に構築 | ほぼ完璧に構造を再現 |
| **画像** | 縦長のカスタムクロップ | アスペクト比が微妙に変化 |
| **パーツ** | 星評価、ハート、トグル | 意図を汲み取って配置済み |
| **余白感** | デザイナーによる微調整 | 少し詰まった「AI翻訳」感 |
| **インタラクション** | ⭕️ | ❌ |
| **スクリーンショット** | ![crop-on-figma.png](https://cont.sterfield.co.jp/uploads/crop_on_figma_0881c65190.png) | ![pencil-on-vs-code.png](https://cont.sterfield.co.jp/uploads/pencil_on_vs_code_6979519cdd.png) |

### 判明したClaude Codeの挙動
検証の結果、Claude Codeは単にAPIでデータをコピーしているのではないことが分かりました。  
  
![VS Code 上の Pencil](https://cont.sterfield.co.jp/uploads/pencil_on_vs_code_6979519cdd.png)
1. **MCPで構造（Metadata）を取得:** レイヤー名から「これはリスト」「これはボタン」と意味を理解。  
2. **Visionで詳細を補完:** スクリーンショットを画像解析し、色や形状のディテールを「見たまま」再現。  
3. **ハイブリッド生成:** 構造と見た目を統合して.penファイルを書き出す。  

---

## 3. FigmaとPencilのHTML/CSS変換精度比較
次に、FigmaとPencilそれぞれからHTML/CSSへの変換精度を比較してみました。  

| 元のFigmaデザイン | FigmaからHTML | PencilからHTML | Pencil + FigmaからHTML
| :---: | :---: | :---: | :---: |
| <a href="https://cont.sterfield.co.jp/uploads/figma_bcbbdf37b7.png" target="_blank"><img src="https://cont.sterfield.co.jp/uploads/figma_bcbbdf37b7.png" alt="元のFigmaデザイン" width="240"></a>  | <a href="https://cont.sterfield.co.jp/uploads/figma_to_html_5749440802.png" target="_blank"><img src="https://cont.sterfield.co.jp/uploads/figma_to_html_5749440802.png" alt="Figmaからの変換結果の拡大" width="240"></a>   | <a href="https://cont.sterfield.co.jp/uploads/pencil_to_html_eb04d40093.png" target="_blank"><img src="https://cont.sterfield.co.jp/uploads/pencil_to_html_eb04d40093.png" alt="Pencilからの変換結果の拡大" width="240"></a>   | <a href="https://cont.sterfield.co.jp/uploads/pencil_to_html_with_figma_a9fe9e5dd9.png" target="_blank"><img src="https://cont.sterfield.co.jp/uploads/pencil_to_html_with_figma_a9fe9e5dd9.png" alt="PencilとFigmaのデータを参照して仕上げた結果の拡大" width="240"></a>   |

- **FigmaからHTML**  
   インタラクションなどの動きは再現できた反面、細かいレイアウトやスタイルの崩れが目立ちました。  
- **PencilからHTML**  
  Figmaからの変換に比べてレイアウトの崩れが少なく、忠実度が高い結果となりました。ただし、細かいスタイルの再現にはまだ課題が残ります。  
- **Pencilからの変換後、Figmaのデータも参照して仕上げた結果**  
  Figmaからの変換に比べてレイアウトの崩れが少なく、忠実度が高い結果となりました。ただし、細かいスタイルの再現にはまだ課題が残ります。  

---

## 4. Figmaに慣れている筆者が感じたリアルな所感
実際に使ってみて感じた、正直な感想です。  

### 気になったところ：エディタとしての使いづらさ
Figmaに慣れすぎた体には、Pencilのエディタはまだ「手が縛られている」感覚があります。  
* **画像のクロップ制限:** 自由なトリミングが難しい。
* **絶対配置（Absolute）の不在:** Flexbox的な制約が強く、自由な重ね合わせに苦労する。
* **操作感:** Figmaほどの滑らかなキャンバス操作には及ばない。

### いいと思ったところ：AIエージェントとの「共鳴」
驚いたのは、別スレッドで「階層を整理したFigmaデータ」を渡した際、Claude Codeが**ローカルにある既存のPencilファイルに自律的に気づき、それをベースに改修を始めた**ことです。

これは、AIが単なる「変換ツール」ではなく、コンテキストを共有する「開発パートナー」として機能していることを示唆しています。Figmaが「デザインの完成図」なら、Pencilは「AIが理解・編集しやすい中間設計図」として機能し、Claude Codeがその間を繋ぐハブになる。この体験は、これまでのデザインワークフローにはなかった新感覚のものです。

---

## 5. 考察: 「Figma → Pencil → HTML」がうまくいった理由

今回の検証で最も興味深かったのは、**直接Figmaからコードを生成するよりも、一度Pencilを介した方が最終的なHTML/CSSの精度が高まった**という点です。

その理由を考察します。

1. **AIにとっての「解像度」の最適化**:
   Figmaの生データはノードの詳細情報が多すぎて、AIがコード化する際に「どこを重視すべきか」の判断が難しくなります。一度Pencilに変換することで、デザインがAIにとって理解しやすいセマンティックな構造に整理（正規化）されます。
2. **Dev Modeがもたらす「設計図」の精度**:
   FigmaをDev Modeに設定することで、Claude Codeは単なる「見た目」だけでなく、CSSプロパティとしての数値を正確に把握します。これにより、Pencilへの移植精度が劇的に向上し、結果としてそこから出力されるコードも堅牢になります。
3. **インタラクションのハイブリッド補完**:
   Pencilが苦手とする「動的な挙動」については、Claude CodeがFigmaのコンテキストを再度参照することで補完できます。これは、Git管理可能なPencilの「堅実さ」と、Figmaの「表現力」のいいとこ取りです。

---

## 6. まとめ

今回の検証を経て出した結論は、 **「エンジニアが主導するプロジェクトにおいて、PencilはFigmaをIDE（開発環境）へ繋ぐ橋渡し役」** として活躍しそうということです。 
  
確かに、エディタとしての使い勝手はまだFigmaに及びません。しかし、以下のようなワークフローが組めるようになった価値はとても大きいと感じます。  
  
1. **デザイナー**がFigmaで「正解」を作る。
2. **エンジニア**がClaude Codeを使って、Figma（Dev Mode）からPencil（.pen）へ高精度に翻訳する。
3. **AIエージェント**がその .pen ファイルをGitで管理しつつ、HTML/CSSへと落とし込む。
  
AIの進化は著しく、この記事を書いた1ヶ月後にはFigmaデータからHTML/CSSへの直接変換で何の問題もなくなっている可能性もありますが、  
色々な可能性を探して、試していき、新しい発見があったら共有していきたいと思います。  

## 参考
- <a href="https://code.claude.com/docs/ja/overview" target="_blank" rel="noopener noreferrer">Claude Code Docs</a>
- <a href="https://www.pencil.dev/" target="_blank" rel="noopener noreferrer">Pencil</a>
- <a href="https://figma.com" target="_blank" rel="noopener noreferrer">Figma</a>

定番デザインツールのFigmaと注目のAIネイティブなデザインツールPencilのClaude Code連携を検証してみました

## はじめに

Anthropicが提供するCLIベースのAIコーディングエージェント「Claude Code」を使った開発ワークフローをご紹介します。

Claude Codeの特徴は、ターミナル上で動作し、GitHubのISSUEやPRと直接連携できる点です。これにより、ISSUEを起点とした開発フローを非常にスムーズに進めることができます。

## Claude Codeとは

[Claude Code](https://docs.anthropic.com/ja/docs/claude-code/overview)は、Anthropicが提供するCLIベースのAIコーディングエージェントです。ターミナルから自然言語で指示を出すだけで、コードの生成・修正からGit操作まで一連の開発作業を自律的に進めてくれます。

Claude Codeの基本的な使い方やインストール方法については、[前回の記事「Claude有料版を初めて使う開発者向けガイド」](/blog/blog-32/)で詳しく解説していますので、そちらをご覧ください。

本記事では、Claude Codeの中でも特に強力なGitHub連携機能を活用した「ISSUE駆動開発」のワークフローに焦点を当てて紹介します。

## ISSUE駆動開発とは

ISSUE駆動開発は、ISSUEを起点として開発を進める手法です。GitHubやGitLabなど、ISSUEトラッカーを持つサービスで実践できます。すべての作業がISSUEに紐づくため、以下のようなメリットがあります。

- トレーサビリティ: なぜその変更が行われたかが明確
- チーム連携: 作業状況の可視化と共有が容易
- 品質管理: レビューとテストのプロセスが明確

## Claude CodeによるISSUE駆動開発ワークフロー

Claude Codeを使うと、ISSUE駆動開発が驚くほどスムーズになります。以下に実際のワークフローを紹介します。

Claude CodeはCLAUDE.mdという設定ファイルでカスタマイズできます。今回のワークフローでは、CLAUDE.mdという設定ファイルに「ISSUEのURLが提供された場合はghコマンドで内容を確認する」といった指示を記述しておく必要があります。

### 1. ISSUEの確認と計画立案

```
> #123のISSUEに対応してください
```

このように指示すると、Claude Codeは以下を自動で行います。

1. `gh issue view 123` でISSUEの内容を取得
2. 要件を分析し、TODOリストを作成
3. 仕様や設計に不足があれば指摘し、見直しを促す
4. 作業計画を提示して確認を求める

ここで重要なのは、AIとの議論を通じて明確になった仕様や設計をISSUE側に反映させることです。これにより、ISSUEが単なるタスク管理ではなく、ISSUEが開発の意図や設計の背景を記録した、生きた仕様書として機能するようになります。

### 2. ブランチ作成と実装

計画が承認されると、Claude Codeは以下のワークフローを実行します。

1. フィーチャーブランチを作成（例: dev/123_add-user-validation）
2. 必要なファイルを特定し、コードを実装
3. 動作確認やテストを実行
4. 問題があれば修正を繰り返す

### 3. PRの作成とレビュー依頼

実装が完了すると、Claude Codeは変更内容をまとめたPRを自動作成します。

```
> PRを作成してください
```

PRには以下が自動で含まれます。

- 変更内容のサマリー
- テスト計画
- 関連するISSUEへのリンク

## やってみた所感

実際に3ヶ月間、このワークフローで開発を続けてきました。その中で得られた気づきを共有します。

### 既存プロジェクトへの導入のしやすさ

最も大きなメリットは、今まで使っていたGitHub ISSUEをそのまま活用できる点です。新しいツールやフローを導入する際、既存の運用を変える必要があると導入コストが跳ね上がりますが、Claude CodeはGitHubのISSUEを直接読み込んで内容を理解するため、既存のプロジェクト管理をそのまま維持できます。

この3ヶ月間、ほぼ全ての実装作業をClaude Codeに任せることができています。ISSUEを起点にした開発フローが確立されていれば、導入は驚くほどスムーズです。

### AIを信じて任せることの重要性

運用を続ける中で気づいたのは、細かくやり方を指示しすぎない方がAIの能力を発揮してくれるということです。

最初は「このファイルを開いて」「この関数を修正して」と細かく指示を出していましたが、それではAIの自律性を活かせません。「#123のISSUEに対応して」とだけ伝え、計画立案から任せる方が、結果的に質の高いアウトプットが得られます。人間が想定していなかったより良いアプローチを提案してくれることも少なくありません。

### 伴走スタイルがベストプラクティス

一方で完全に自律させるのではなく、あくまでも「伴走」というスタンスを維持することをおすすめします。

AIに複数のタスクを並列で任せたり、完全に放置して自律的に進めさせることも技術的には可能です。しかし、そうすると人間側のレビュー工数が一気に増え、かえって非効率になります。1つのタスクをAIと一緒に進め、要所要所で確認しながら進める「伴走スタイル」が、現時点ではベストプラクティスだと感じています。

「人間がISSUEを作成し、AIが実装する」という一方通行の役割分担ではなく、ISSUEを軸に人間とAIが協働しながら開発を進める。これがClaude Codeを活用したISSUE駆動開発の醍醐味だと感じています。

## まとめ

Claude Codeを使ったISSUE駆動開発は、開発ワークフローを大きく効率化する可能性を秘めています。特に、ISSUEの確認からPR作成までの一連の流れをAIがサポートしてくれることで、開発者はより本質的な設計や問題解決に集中できます。

設定ファイルを活用すれば、チームのコーディング規約やワークフローをClaude Codeに教え込むことも可能です。これにより、チーム全体で一貫した開発スタイルを維持しながら、AIの力を借りることができます。

AIコーディングエージェントはまだ発展途上ですが、開発者の強力なパートナーとなる未来は確実に近づいています。皆さんもぜひ、Claude Codeを使ったISSUE駆動開発を体験してみてください。

Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧 - タグ: #Code

2026/04/17

2026/03/13

2025/12/26