## はじめに

先日公開された「[AIエージェントを中心に据えた開発環境への移行](https://sterfield.co.jp/blog/ide-to-ai-agent/)」は、エンジニアがIDEからAIエージェントへ作業の中心を移した話でした。同じ構造の転換を、自分はエンジニアではない立場で進めてきました。

**時代が大きく変わるという危機感と、この技術が業務のかたちをどこまで変えるのか、自分の手で確かめたいという衝動から、自分で業務環境の中心にAIエージェントを据え直してきました**。Claudeを中心に据えた直近1ヶ月で、景色は大きく変わっています。誰かに導入されたのではなく、自ら設計し、試し、組み替えてきたプロセスです。

**AIエージェント活用はもう、エンジニアの世界だけの話ではなくなっている**——と、自分の手を動かしながら感じています。

本記事は、この1ヶ月で何を考え、何を組んだかの共有です。

## 以前の業務環境

半年ほど前の業務環境は、おおむね以下のようなものでした。

- コミュニケーション:Gmail、Google Chat、Chatwork、Teams、Slack
- 案件管理:Backlog(4スペース)、GitHub
- スケジュール:Googleカレンダー
- AI:ChatGPTやGeminiをブラウザから日常的に活用(メール下書き、議事録要約、モックアップHTML、提案書の構成まで)

毎朝、ブラウザを開けばGmail、Google Chat、Chatwork、Teams、Slack、Backlog、GitHub、カレンダーのタブが20も30も並んでいました。そこからChatworkの100を超えるルームのうち動いているものを流し見て、Backlogの4スペースを横断して新着コメントを拾い、カレンダーで当日の予定を確認する。

情報を**集める作業**と、集めた情報をもとに**判断する作業**が、完全に同じ人間(=自分)に重なっていました。AIの出番は多かったのですが、業務の外側にいて、用事があるときに呼び出す外注のような位置づけでした。

## 今の業務環境

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

- 作業の中心:ターミナル上のClaude Code、Claudeデスクトップアプリ、Cowork、Claude in Chrome
- CLAUDE.mdに会社文脈・担当案件・業務プロトコルを事前に添えている
- 役割別エージェントを3体制で運用(.claude/agents/ 配下に定義)
- 業務アプリはブラウザで開くだけでなく、ターミナルから取れるものは取る(GitHubはgh CLI経由など)

朝、PCを立ち上げて「おはよう」と打つと、昨日以降に動いたメール、Chatworkの動き、BacklogとGitHubの新着、カレンダーの予定、判断が必要な論点が、ひとつのブリーフィングとして返ってきます。

情報を**集める作業**そのものが、業務から消えました。

![スクリーンショット-2026-04-23-12-25-22-png-1542×1662--04-23-2026_01_52_PM.png](https://cont.sterfield.co.jp/uploads/2026_04_23_12_25_22_png_1542_1662_04_23_2026_01_52_PM_1038e4decf.png)

同じ構造は、朝のブリーフィング以外の領域にも広がっています。

たとえば提案書づくり。業界リサーチや先方の公開情報の読み込み、競合との差別化の整理、構成のたたき台、スライドのドラフトまで、AIが先回りで組み立てます。自分は要件や論点の解像度を上げる壁打ち相手として回り、何度も応酬を重ねて提案の輪郭を整える、という進め方になりました。最終成果物に至るまでの試行回数は、以前とは比較にならないくらい増えています。

かかる時間そのものは、意外にも劇的には減っていません。ただし、**使っている脳がまったく違う**というのが一番の実感です。手でゼロから資料を作っていた時代は、構成を考える脳・文字を打つ脳・体裁を整える脳が一度に動いていました。今は、方針を示す脳・論点を足す脳・最後に判断する脳だけが残っています。**作業の実行者から、判断と編集の責任者へ**と、自分の役割が移ったような感覚です。時間ではなく、疲れ方と発想の出方が変わりました。

社内の案件引き継ぎ書も同じです。関連するBacklog、Chatwork、Gmail、GitHub上のやりとりや関連ドキュメントをAIに読み込ませたうえで、事実ベースのドラフトを組み立てさせています。人間の記憶や印象で書いた引き継ぎ書より、データから再構築されたほうが明らかに精度が高く、抜け漏れも減りました。

## AIにはまだできないこと

人間の残された仕事のうち、大きなもののひとつが、**ドキュメントに残らない暗黙知を最後に添えて仕上げる**作業です。案件ごとの特殊事情、現場の温度感、その場でしか判断できない機微——こうした情報はどんなドキュメントにも書ききれません。事前に添えた文脈と、その場で添える暗黙知。両方あって初めて、AIが自分の代わりに考えてくれる状態に近づきます。

この延長で、情報の残し方そのものも意識するようになりました。たとえばオンライン会議では、アクションアイテムが決まった瞬間にあえて大きめの声で復唱しています。参加者への明確な共有でもありますが、AIが文字起こしから議事録を組み立てる際に、重要ポイントが確実に拾われるようにするための工夫です。日常の所作のなかに、**AIが後から読み取れる形で情報を残す**という意識が混ざるようになりました。

## 何が変わったのか

半年前の時点でも、ChatGPTやGeminiは一日に何度も呼び出して使っていました。下書きや要約はもちろん、モックアップHTMLの生成や提案書の構成まで任せていて、それで一通りの業務は回せていたのです。

そこから変わったのは、業務のなかでAIを**呼ぶ**立ち位置から、業務のなかにAIが**組み込まれている**立ち位置への移行でした。

### AI活用の4つの階層

この変化は、AI活用の階層として整理するとわかりやすくなります。自分の実感では、AI活用にはおおむね以下の4段階があります。

- **レベル1:代替** — 人の作業を置き換える(要約、翻訳、下書き)
- **レベル2:比較検討** — 複数案を出させて選ぶ、壁打ち相手として使う
- **レベル3:思考の外部化** — 自社の文脈や判断基準を事前に渡した上で、AIとの応酬を重ねながら使う
- **レベル4:業務の再設計** — レベル3のAIを特定業務の専任としてフローに組み込む

半年前の自分はレベル1〜2を行き来していました。今はレベル3〜4にいる、という整理になります。

レベル2から上に進むために必要だったのは、技術や知識ではなく、2つのことでした。

ひとつは、**AIに渡す文脈を整えること**。「どのツールが一番いいか」「どのプロンプトが効くか」といった議論は、それ自体は自然で、自分も通ってきた道です。ただ、そこだけで時間を使っていると、レベル2の内側で留まりやすい。自分の業務・判断軸・自社の事情をAIに渡す準備を始めた瞬間から、景色が変わります。

もうひとつが、**圧倒的な試行回数**です。ひとつのアウトプットに対して、20回、30回と応酬を重ねる。「一度で正解が出る」ことをAIに期待している間は、どれだけ高性能なモデルを使ってもレベル2の内側から出られません。試行回数を前提にした瞬間に、AIとのやりとりは「正解を引く」作業ではなく「正解をつくる」作業に変わります。この切り替えが、階層をひとつ上げます。

ただし、レベル3からレベル4に進む段階では、**最低限のIT的な感覚**がまったく不要かといえば、それは嘘になります。たとえば、使っている業務ツールにAPIがあるかどうかを調べ、「APIがあるならAIに情報を取って来てもらえそう」「ないなら別の手を考える必要がある」と判断できる感覚です。高度な技術知識は要りませんが、こうした**ツールとツールが繋がる仕組みの見当**がつくと、設計の幅が明らかに広がります。

むしろエンジニアでない立場からだと、最初にぶつかるのはこの**接続点**ではないかと感じています。文脈を整えるところまでは自力でできても、AIをどの業務ツールに、どう繋ぐかの絵が描けない。ここは独学でもある程度は進めますが、身近にいるエンジニアと組んで小さな仕組みを一つ作ってみるのが、一番早い抜け方だと思います。大がかりなことを学ぶ必要はなく、「Claude CodeがGmailを読める状態を一度作る」くらいから十分です。

ここから先は、自分がレベル3〜4にどう登ったかを順に書きます。

### 1. CLAUDE.mdによる文脈の事前装填(レベル3への移行)

1つめは、CLAUDE.mdに自分と会社の文脈を添えるようにしたことです。

役職、事業、担当案件、パートナー企業、定例会議、ツール構成、Gmailのラベル体系、勤務パターン——これらの前提を、Claude Codeが毎回参照できる状態にしました。

この作業は、技術の話というより、**自分の業務を客観視して、AIに渡す文脈を整える作業**でした。普段は無意識にやっていることを、AIが使える形で整理する必要があります。

やってみてわかったのは、これをやる前と後では、同じ質問に対するAIの返答がまるで別物になるということでした。「この案件、どう進めますか」という一言で、クライアントの背景・過去の経緯・社内の担当者・判断基準まで踏まえた回答が返ってくる。文脈を毎回ゼロから伝える必要がなくなる。

出力の精度は、**AIの性能ではなく、どれだけの文脈を渡せているかで決まる**。これが一番大きな発見でした。

文脈は、業務情報だけではありません。Claudeには個人設定という、すべての会話に共通で適用される設定欄があります。自分はここに、たった一文だけ書いています——**「嘘はつくな。出来なかったら出来ないといえ」**。

![スクリーンショット 2026-04-24 15.22.41.png](https://cont.sterfield.co.jp/uploads/2026_04_24_15_22_41_87061cffef.png)

たった一文ですが、これがよく効きます。知らないことを知ったかぶりで埋めてこない。推測で架空の情報を生成しない。「その情報は持っていません、確認させてください」と正直に返してくる。業務パートナーとして一緒に仕事をするうえで、この一文があるかないかで信頼の置き方がまったく変わります。この記事も、事実と推測が混ざらないまま書き上がったのは、この設定のおかげが大きいと感じています。

### 2. 役割別エージェントによる業務分業(レベル4への移行)

2つめは、ひとつのAIに全部を頼むのではなく、役割ごとにエージェントを分けたことです。

現在は3体制で運用しています。情報を**集める方角**を担うCompass(羅針盤)、課題の**解に向かう方角**を担うSolver(解決者)、判断の**拠り所**を担うAnchor(錨)。それぞれ起動ワードで呼び分けます。

この3体制に至るまでに、何度か編成を組み替えました。最初は「資料作成担当」「レポート担当」「コーチ担当」のように**機能名**で分けていましたが、しばらく回すうちに、機能名だと依頼する側が「今どれを呼ぶべきか」を毎回考える必要が出てきて、かえって思考のリズムを止めることに気づきました。

Compass / Solver / Anchor という抽象語に切り替えたのは、「どこに向かわせるか」という**方角**で分けたほうが、依頼する自分の思考が先に整理されるからです。「今から自分はCompassで情報を集めに行く」「今はAnchorで判断の拠り所がほしい」——どのエージェントを呼ぶかを選ぶ瞬間が、そのまま**今から自分は何をしようとしているのか**の宣言になります。

エージェントの命名は、AIに仕事を振るためのラベルではなく、**自分の業務モードを切り替えるスイッチだった**、というのが今の実感です。

### 3. 業務アプリの立ち位置の変化

この2つが組み合わさった結果、業務アプリ(Gmail、Chatwork、Backlog、GitHub、カレンダー)を**自分から巡回する時間**が大きく減りました。業務アプリ自体は今でも日中ずっと開いていて、個別のやりとりやリアルタイムの反応は直接見ています。変わったのは、「まず自分が巡回して情報を集める」という**入口の役割**がAI側に移ったこと。業務アプリは、情報を能動的に取りに行く場所から、必要に応じて直接触れる場所へと、位置づけが変わりました。

範囲は業務アプリだけにとどまりません。Web、社内ドキュメント、過去のやりとり——**AIはすでに外部脳と接続された状態**で待っています。自分でブラウザを開いて検索して、タブを行き来して、コピペで集めて、という手作業を踏まなくても、「この件について必要な情報を集めて」と一言渡せば、ガッと集まってくる。調べる時間と、集めたものを使って考える時間の境目がなくなりました。

判断する人間は自分ひとりですし、最終承認も自分のところで止まります。それでも「情報を集めるのに午前中を使う」が消え、「集めた情報を判断する」と「判断したものを実行する」に時間を寄せられるようになったのは、大きな変化でした。

ここまでClaude系のツールを中心に書いていますが、使っているAIはClaudeだけではありません。用途に応じてGemini(とくにGems)もGensparkも使っています。レベル3の「文脈を事前に渡す」という工夫は、ClaudeのCLAUDE.mdでもGeminiのGemsでも、本質的に同じことが実現できます。自分にとって本質は、どのAIを使うかではなく、**業務の前にAIを先回りさせる構造**が作れているかどうかです。ツールは数ヶ月単位で入れ替わりますが、**この構造はツールを超えて残ります**。

## まとめ

**「AIを業務アプリのなかで使う」から「AIを中心に置いて業務アプリを脇に置く」へ**。開発環境で起きた構造の逆転は、業務環境でも同じ形で起きるというのが、この1ヶ月の一番の実感でした。

特別な技術は必要ありませんでした。必要だったのは、自分の業務と判断軸を整理してAIに渡すこと、書ききれない暗黙知を都度添えること、そして**「正解をつくる」ための圧倒的な試行回数を惜しまないこと**——エンジニアでない立場でも、十分に踏める道です。ツールもClaudeに限った話ではなく、GeminiのGemsで同じ階層までは行けます。

そして何より、**自分がこの時代の仕事の仕方を、心から楽しんでいます**。朝、ターミナルに「おはよう」と打つところから始まる一日。自分の手が届く範囲がどんどん広がっていく感覚。業務の中心を動かしにいく過程そのものが、面白くて仕方ありません。この面白さが伝われば、この記事は十分に役目を果たしたと思っています。

large_eyecatch-03-terminal.png

medium_eyecatch-03-terminal.png

small_eyecatch-03-terminal.png

thumbnail_eyecatch-03-terminal.png

eyecatch-03-terminal.png

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

## はじめに

前回の記事「[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駆動開発を体験してみてください。

large_eyecatch.png

medium_eyecatch.png

small_eyecatch.png

thumbnail_eyecatch.png

eyecatch.png

Claude Codeで始めるISSUE駆動開発

## 目次
1. <a href="#section1">Claudeとは</a>
2. <a href="#section2">有料版の使用制限と効率的な使い方</a>
3. <a href="#section3">Claudeの3つの使い方とその違い</a>
4. <a href="#section4">質問の仕方のコツ</a>
5. <a href="#section5">セッション管理</a>
6. <a href="#section6">Gitとの連携</a>
7. <a href="#section7">初心者が気をつけること</a>

---
<a id="section1"></a>
## 1. Claudeとは

### 1.1 Claudeの基本

**Claude**は、米国Anthropic社が開発した高性能AIアシスタントです。

**開発元:** Anthropic社（OpenAIの元メンバーが創業）  
**初公開:** 2023年3月  
**最新モデル:** Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5

### 1.2 なぜ開発者にClaudeなのか？

| 特徴 | 説明 |
|------|------|
| **高精度なコード生成** | Python, JavaScript, PHP, Java, C++など多言語対応 |
| **日本語対応** | 日本語コメントやドキュメント生成が得意 |
| **コードレビュー** | セキュリティやパフォーマンスの指摘が優秀 |

---
<a id="section2"></a>
## 2. 有料版の使用制限と効率的な使い方

### 2.1 ⚠️ 重要: 有料版 = 無制限ではない

多くの方が誤解していますが、**Claude Pro/Maxプランでも使用回数に制限があります。**

```
❌ 誤解: 「有料版なら使い放題！」
✅ 正解: 「有料版でも5時間ごとに制限がある」
```

### 2.2 使用制限の詳細

#### リセットサイクルと目安

| プラン | リセット周期 | 目安の使用回数 |
|--------|--------------|---------------|
| Free | 5時間ごと | 10〜20回程度 |
| Pro | 5時間ごと | 50〜100回程度（Freeの約5倍） |
| Max 5x | 5時間ごと | 250〜500回程度（Proの5倍） |
| Max 20x | 5時間ごと | 1000〜2000回程度（Proの20倍） |

※実際の使用回数は、メッセージの長さや複雑さによって変動します。

#### 制限に達するとどうなる？

制限に達すると、以下のメッセージが表示されます：

```
⚠️ You've reached your usage limit for Claude Sonnet.
Your limit will reset in 6 hours and 23 minutes.
```

**対処法:**
- 制限がリセットされるまで待つ
- 軽量モデル（Haiku）に切り替える
- 上位プランへのアップグレードを検討

### 2.3 使用回数に影響する要因

**メッセージの長さ** - 短いメッセージ（「バグを修正して」）は少ないカウント、長いメッセージは多いカウント

**会話の長さ（履歴）** - Claudeは毎回、全履歴を読み込むため、メッセージ数が増えるほど使用回数が増加

**複数ファイルの添付** - テキストのみ < PDF複数 + 画像2枚など

**使用モデル** - Haiku < Sonnet < Opus の順で使用回数が増加

| モデル | 使用回数への影響 | 性能 | 推奨用途 |
|--------|-----------------|------|----------|
| Claude Haiku 4.5 | 小（1x） | 軽量・高速 | 簡単なタスク |
| Claude Sonnet 4.5 | 標準（2〜3x） | バランス型 | 通常の開発作業 |
| Claude Opus 4 | 大（5x） | 最高性能 | 複雑なタスク |

### 2.4 制限を効率的に使うコツ

**✅ 推奨する使い方**

新しいチャットを頻繁に作成（30分〜1時間、20〜30メッセージごと）、必要最小限の情報のみ提供、軽量モデル（Haiku）を活用、複数の質問をまとめる。

**まとめて質問の例:**
```
❌ 1つずつ質問（3回のやり取り）
「この関数の名前は？」→「引数は？」→「戻り値は？」

✅ まとめて質問（1回のやり取り）
「この関数について: 1. 関数名 2. 引数 3. 戻り値」
```

**❌ 避けるべき使い方**
- 1つのチャットを延々と続ける
- 不要なファイルを大量にアップロード
- Opusモデルを簡単なタスクで多用

---
<a id="section3"></a>
## 3. Claudeの3つの使い方とその違い

Claudeには、用途に応じて3つの使い方があります。

### 3.1 Claude.ai（Webブラウザ版）

**アクセス:** https://claude.ai | **環境:** Webブラウザ | **推奨:** 初心者向け

✅ **メリット:** インストール不要、ファイルアップロード対応、Artifacts機能でコードをプレビュー、自動保存

❌ **デメリット:** プロジェクト全体の解析には不向き、ファイルの自動編集はできない

**向いている作業:** コードレビュー、ドキュメント作成、バグ修正、API仕様確認、テストコード生成

### 3.2 Claude Code（コマンドライン版）

**環境:** ターミナル（Mac / Linux / Windows）| **対応OS:** Mac ✅、Linux ✅、Windows ✅（WSL経由）

**インストール:**

公式のインストール方法は以下を参照してください：
- 公式ドキュメント: https://docs.anthropic.com/claude/docs/claude-code

インストール後のログイン:
```bash
claude login
```

✅ **メリット:** プロジェクト全体を解析可能、複数ファイルの自動編集、ファイル操作、Git連携が便利

❌ **デメリット:** ターミナル操作の知識が必要、ビジュアルプレビューがない

### 3.3 VS Code拡張機能

**環境:** Visual Studio Code | **対応OS:** Windows / Mac / Linux

✅ **メリット:** エディタ内で直接操作、プロジェクト全体の解析、Claude Codeと同等の機能

❌ **デメリット:** 初回セットアップが必要

### 3.4 3つのツール比較

| 項目 | Claude.ai | Claude Code | VS Code拡張 |
|:---|:---:|:---:|:---:|
| **初心者向け** | ✅ 最も簡単 | △ やや難しい | △ 中程度 |
| **複数ファイル自動編集** | ❌ 手動のみ | ✅ 完全対応 | △ 部分的 |
| **プロジェクト全体解析** | △ 手動確認必要 | ✅ 完全対応 | △ 部分的 |
| **セットアップ** | ✅ 不要 | △ インストール必要 | △ APIキー設定必要 |

---
<a id="section4"></a>
## 4. 質問の仕方のコツ

### 4.1 効果的な質問の4つの原則

**原則1: 具体的に**
```
❌ 「ログイン機能を作って」
✅ 「Symfony 6.3でJWT認証を使ったログイン機能を作ってください
   - メールアドレス・パスワード認証、トークン有効期限24時間」
```

**原則2: コンテキストを提供**
```
❌ 「エラーが出ます」
✅ 「[エラーメッセージ] が出ています。[発生状況] です」
```

**原則3: 期待する出力を明示**
```
❌ 「この関数を説明して」
✅ 「この関数について: 1. 目的 2. 引数 3. 戻り値 4. 使用例」
```

**原則4: 制約を明示**
```
❌ 「データベース設計を提案して」
✅ 「MySQL 8.0、想定データ量100万件、多言語対応(日本語・英語・中国語)で」
```

---
<a id="section5"></a>
## 5. セッション管理

Claudeは毎回、会話の全履歴を読み込むため、メッセージ数が増えるとレスポンスが遅くなります。

**新規チャット作成のタイミング:**
- 30分〜1時間経過した
- 20〜30回のやり取りをした
- 話題が変わった

**Claude Codeのコマンド:**

| コマンド | 用途 |
|--------|------|
| `/compact` | 履歴を圧縮。同じプロジェクト内で継続する時 |
| `/clear` | 履歴を完全削除。別プロジェクトに移る時 |

---
<a id="section6"></a>
## 6. Gitとの連携

Claudeを使うと、Git関連の作業が効率的になります。以下は、各作業がどのツールで実行でき、難易度がどのくらいかを示した表です。

| 作業内容 | Claude.ai | Claude Code | 難易度 | 説明 |
|---------|-----------|------------|--------|------|
| **コミットメッセージ生成** | ✅ 可能 | ✅ 可能 | 易しい | diffやコード変更を貼り付けて実行 |
| **git diff の解析** | ✅ 可能 | ✅ 可能 | 易しい | 変更内容を確認・説明してもらう |
| **コードレビュー** | ✅ 可能 | ✅ 可能 | 易しい | 該当コードを貼り付けて指摘を受ける |
| **コンフリクト解決** | ⚠️ 手動確認が必要 | ✅ 自動編集対応 | 中程度 | Claude Codeなら効率的 |
| **PR説明文生成** | ✅ 可能 | ✅ 可能 | 易しい | 内容を説明してもらう |
| **リファクタリング** | ⚠️ 手動編集が必要 | ✅ 複数ファイル自動編集 | 中程度 | Claude Codeなら効率的 |

### 6.1 Claude Codeで便利な使い方

Claude Codeを使う際、シェルエイリアスを設定すると、よく使うコマンドが短縮できます。

**~/.zshrc または ~/.bashrc に追加:**

```bash
# クイックレビュー
alias ccr='claude "このコードをレビューして、改善点を指摘してください"'

# バグ修正
alias ccf='claude "このコードのバグを見つけて、修正してください"'

# テスト生成
alias cct='claude "このコードのユニットテストを生成してください"'

# コミットメッセージ生成
alias ccm='git diff --cached | claude "上記の変更に対して、わかりやすいコミットメッセージを1行で生成してください"'
```

**使い方の例:**

```bash
# コードをレビュー
ccr app/services/UserService.php

# バグを修正
ccf app/controllers/AuthController.php

# テストを自動生成
cct tests/UserServiceTest.php
```

---
<a id="section7"></a>
## 7. 初心者が気をつけること

### 7.1 よくある失敗パターン

| パターン | 対策 |
|---------|------|
| 情報詰め込みすぎ | 必要な部分だけを厳選 |
| チャットの長期使用 | 30分〜1時間で新規作成 |
| 生成コードの無検証使用 | 必ずコードレビュー |
| 機密情報の入力 | 環境変数使用、ダミーデータで質問 |

### 7.2 コストを抑えるコツ

1. 軽量モデル（Haiku）の活用
2. 複数の質問をまとめる
3. 20〜30メッセージごとに新規チャット作成
4. 該当部分のみを抜粋（ファイル全体不要）

**重要:** Claudeはあくまでツール。生成されたコードは必ずレビューし、最終判断は開発者であるあなたが行ってください。

**更新情報:** このブログは2025年12月時点での情報です。仕様変更の可能性があるため、最新情報は公式ドキュメントで確認してください。

| 項目 | URL |
|------|-----|
| プラン・制限 | https://support.anthropic.com/ja/ |
| API | https://docs.anthropic.com |
| Claude Code | https://docs.anthropic.com/claude/docs/claude-code |
---

## 参考リンク

- [Claude公式サイト](https://claude.ai)
- [Claude API ドキュメント](https://docs.anthropic.com)

large_claude-eyecatch.jpg

medium_claude-eyecatch.jpg

small_claude-eyecatch.jpg

thumbnail_claude-eyecatch.jpg

claude-eyecatch.jpg

Claude有料版を初めて使う開発者向けガイド

近年、生成AIの技術は急速に進化し、様々な業務に活用されています。これはITの開発現場でも同様で生成AIにプログラムを書いてもらい、業務の効率化に繋げる動きがあります。
  
生成AIと言えば、ChatGPTを使用する話しはよく聞きますが、同じくよく話題に上がる生成AIとして、Claude AIの名前もよく聞きます。Claude AIは、一度に扱える文字数も多い話を聞き、WEBページ全体などの文字数が多いコンテンツも作成できるか、また精度はどの程度なのか実験しました。  
  
Claude AI  
https://claude.ai/new  
  
参考：  
https://mijinko.co.jp/media/chatgpt-claude-difference/

## Claude AIとは  
  
Claude AIは、Anthropic（アンソロピック）というAI研究団体によって開発されました。こちらは、ChatGPT で有名なOpenAI社に所属していた元社員が2021年に立ち上げた企業です。同社のやり方に異を唱え、退社後に設立しました。倫理的なAI開発に強いこだわりを持ち、ユーザーの意図を深く理解し、安全で信頼性の高い対話を提供することを目指しています。

回答内容も、ユーザーの意図をより正確に理解し、適切な応答を生成するために設計されています。  
  
## 実験内容

Claude AIの能力を検証するために、弊社で運営するコンペナビのLP「自治体向け動画コンテスト主催サポート」を最近のトレンドであるBENTO UIの形にする実験をしました。  
  
コンペナビ:  
https://compe.sterfield.jp  
  
コンペナビLP:自治体向け動画コンテスト主催サポート  
https://compe.sterfield.jp/lp_jichitai  
  
また、弊社開発のWEBサイトなので、詳細なデータは手元にありますが、一般の視聴者と同じように通常の閲覧、および右クリックの「ソースの表示」だけで得られる情報のみを使用しました。これは技術者抜きでどんな物が作れるのか試したかったからです。

### 実験1：URLを使ってコーディング依頼
  
先ず、はじめにURLを指定して作る事を試してみました。  
  
「（コンペナビLPのURLを記載）のページをBENTO UIに作り変えてください。そのためのコードを書いてください。」
と依頼してみました。すると、返答の返答がありました。 

> 申し訳ありませんが、私はURLを開いたりウェブページの内容を直接確認したりすることはできません。そのため、指定されたページの具体的な内容を見ることができず、正確なBENTO UIへの変換を行うことは難しいです。  
> しかし、BENTO UIの一般的な構造に基づいて、自治体向けのランディングページをイメージしたBENTO UIのテンプレートを提案することはできます。以下に、そのためのHTMLとCSSのコードを示します。  
  
この返答から、Claude AIは直接URLを開くことができず、具体的にページ内容を確認できないことが分かりました。そして実際に生成されたコードをブラウザでレンダリングしてみたら、以下のようになりました。

 ![](https://cont.sterfield.co.jp/uploads/img_202450830_1_ca709c375b.png) 

生成されたコードは、BENTO UIの基本構造を備えており、また、設定されているMETA情報を理解している様でした。

### 実験2：HTMLファイルを使ったコーディング依頼

Claude AIはChatGPT と違い、こちらがアップロードしたファイルに応じて返答を求めることができます。なので、コンペナビのLPで右クリックして「ソースの表示」でLPのHTMLをコピーしてHTMLファイルを作成しました。

 ![](https://cont.sterfield.co.jp/uploads/img_202450830_2_7ad24841f0.png) 

そして、このHTMLファイルをアップロードし、「今 pasteしたHTMLをBENTO UIに変えてください。なるべく元のデザインの要素 色合いを取り入れてBENTO UIにしてほしい」と指示を出しました。  
  
すると以下のページを作ってくれました。  
 
 ![](https://cont.sterfield.co.jp/uploads/img_202450830_2_2_7ba57ca19f.png) 
    
HTMLファイルを元に、より具体的なレイアウトを作成してくれました。もちろん細部の作りこみは必要になりますが、元のデザインの要素をしっかり認識した上で作成されているのが十分に分かります。  
  
### 実験3：詳細な修正指示を出してみる  
  
さらに、以下の修正指示を出してみました。  
  
>・元のサイトはスクロールするとMOVIEなど動くテキストがありますが、これらも再現してください。  
  
>・コンテスト事例紹介は各企業のロゴがスクロールする構造です。ロゴ（画像）の代わりに、100pxの赤いdivをいくつか用意してスクロールする構造にしてください。  
  
>・ヘッダーのメニューの項目はハンバーガーアイコン（3本の線のアイコン）を押すと表示・非表示に切り替える構造にしてください。
  
と3点の修正指示をしてみました。  
すると以下のページが生成されました。  

 ![](https://cont.sterfield.co.jp/uploads/img_202450830_3_adc40b1594.png)   
  
静止画なので分かりにくいですが、今回はHTML、CSSだけでなくJavaScriptも生成され、実際にスクロールに応じてテキストが動いて出現するなどのアクションも再現されました。ただ、残念ながらスクロールについては意図した通りに作成されませんでした。
  
また、驚いたことにスマホのレイアウトになった際のハンバーアイコン(メニューの収納)の仕掛けも作成してくれました。  
  
 ![](https://cont.sterfield.co.jp/uploads/img3_2_d3744cd143.png) 
  
### 実験4：画像を指定して配置してみる  
  
次に元のサイトから使用している画像を抜き出して、実際に配置できるか試してみました。

 ![](https://cont.sterfield.co.jp/uploads/img_202450830_4_685f06a92d.png) 

HTMLと同様に画像をアップロードして、  
  
> 今！自治体による動画コンテストが人気！の箇所で    
> - １募集で、 s1_1.png  
> - ２撮影＆投稿で s1_2.png  
> - ３受賞で s1_3.png  
>
> の画像を入れてください。  
  
と指示してみました。すると、  
  
改善コードが生成されました。
  
 ![](https://cont.sterfield.co.jp/uploads/img_202450830_4_2_de3c195a71.png) 
  
また、コードの生成と合わせてサイズを調整する方法も教えてくれました。もっと細かく指示してクオリティを上げることもできそうです。

## まとめ
Claude AIは無料プランでは1日に対話できる回数が少なく、上記の作業も数日間を要しました。そのため本格的に業務に使うとなると有料プランに入る必要があると感じました。しかし、この欠点を除けばかなり便利なツールだと思います。単純に制作のスピードが上がりそうですが、技術者が不在でもかなり精度の高い物が作れそうです。  
  
生成AIの登場により、エンジニア、非エンジニアの垣根がなくなりつつあり、AIを使う頻度はこれから一層増すでしょう。最近では「プロンプトエンジニア」という言葉まで聞くようになりました。  
これからの時代、AIを使いこなす技術も必須のスキルと言えそうなので学んでいきます。

medium_img_202450830__title.png

small_img_202450830__title.png

thumbnail_img_202450830__title.png

img_202450830__title.png

Claude AIを使ったBENTO UI変換実験レポート：非技術者もWEBページを作れる時代になるのか検証してみた

Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧 - タグ: #Claude

2026/04/24

2026/04/17

2026/03/13

2025/12/26

2025/12/12

2024/08/30