画像やコンテンツを左右にスライド、スクロールするjQuery

<a href="https://path.com/">https://path.com/</a>
こちらのアプリのメニューの動きが心地いいので、
jQueryのプラグインなどを使って再現に挑戦しました。
<a href="https://sterfield.co.jp/demo/ninomiya/02/demo1.html" target="_blank" class="demo">demo</a>
&nbsp;
イージングを、<a href="http://gsgd.co.uk/sandbox/jquery/easing/" target="_blank">jquery.easing</a>のeaseOutBackで。
回転を、<a href="http://www.zachstronaut.com/posts/2009/08/07/jquery-animate-css-rotate-scale.html" target="_blank">jquery-animate-css-rotate-scale.js</a>を使ってみました。
&nbsp;
実際は、回転させてから動くようですが、
今回は逆の動きになってしまいました。
&nbsp;
また次回、近い動きを目指してみます。

Pathのアプリのメニューぽい動きをjQueryで作ってみる1

## はじめに

自社の越境ECマネジメントシステム「Bynd」の紹介サイト（[https://bynd.ne.jp/](https://bynd.ne.jp/)）を公開しました。国内のECサイトの商品データをShopeeなどの海外モールへ自動連携し、一元管理するシステムです（[プレスリリース](https://sterfield.co.jp/news/press_bynd/)）。

サイトの要件は「非エンジニアが自分で文言を直せること」でした。

ここまでならCMSを入れる場面です。WordPressを立てて、管理画面から本文を書き換えてもらう。長年それが定番でした。今回はCMSを入れず、AIで作ったデザインをHTMLにして、静的ファイルのまま配信する構成にしています。

本記事では、その構成とCMSを入れなかった理由、実際に効いた点、そしてどこまでなら通用するのかを書きます。

## 作ったもの

構成は次のとおりです。

![更新フロー](https://cont.sterfield.co.jp/uploads/update_flow_03dc53af0d.png)

- 編集：ブラウザ上のデザインツール（[Claude Design](https://claude.ai/design)）。完成したページの上でテキストをクリックし、書き換えて保存する
- 同期：Claude Codeでデザインツールから最新のHTMLを取得し、GitHubリポジトリへのPR（Pull Request）にする
- 確認：テスト環境に反映して社内で見る。ドメイン自体は公開されているので、前段にBASIC認証を置いた
- 配信：Cloudflare Workers Static Assetsで本番に出す

全30ページで、サーバー側で動くコードはお問い合わせフォームの受け口だけです。残りはすべて、あらかじめ生成されたHTMLを返しています。

編集する人にGitとデプロイは見せていません。ブラウザで文言を直して保存するところまでが編集者の仕事で、そこから先は今のところこちらで引き取っています。

## CMSの仕事を分けて考える

CMSを入れなかったのは、重いから避けたわけではありません。担ってもらう仕事が残らなかったからです。

CMSがやっていることは、大きく3つに分けられます。

- **編集UI**：非エンジニアが本文を書き換えるための画面
- **コンテンツの保管**：書き換えた内容を貯めておく場所と、その履歴
- **配信時のレンダリング**：リクエストが来たときに、保管したデータからHTMLを組み立てる処理

このうち編集UIは、デザインツールが引き受けました。管理画面の入力欄ではなく完成したページの上で文字を触る形なので、直した結果がその場で見えます。

保管はGitリポジトリで足ります。誰がいつ何をどう変えたかを追うなら、CMSのリビジョン機能よりコミット履歴のほうが読みやすい。

残るのは配信時のレンダリングですが、更新のたびにHTMLを作り直してしまえば、リクエストごとに組み立てる必要はありません。

3つとも別の手段で片付いたので、CMSを置く場所がなくなりました。

## 効いたこと

### 変更が差分として見える

いちばん効いたのはこの点です。CMSで非エンジニアに編集権限を渡すのは、本番のデータを直接書き換えてもらうことです。プレビュー機能はありますが、「今回どの文言がどう変わったのか」を公開前に一覧で突き合わせるのは簡単ではありません。おかしな変更が入ったときも、いつ壊れたかを探して、前後のリビジョンを1つずつ開いて見比べることになります。

静的HTMLをGitで管理していると、この確認がPRの差分になります。変更前と変更後が並んで出るので、直したはずのない箇所が一緒に変わっていれば、その場で気付けます。

編集は自由にやってもらったまま、公開の前にだけ門番を置ける。非エンジニアに編集を任せる前提だと、これがそのまま安全装置になっています。

### 保守するものが減る

DBもPHPもプラグインもありません。管理画面のログイン口がないので、そこを守る仕事も発生しません。

CMSを運用していると、本体とプラグインのバージョンアップが定期的に降ってきます。ほとんど更新のないサイトでも、この作業だけは止まりません。今回はその作業自体がなくなりました。

配信はCDNから静的ファイルを返すだけです。アプリケーションサーバーもDBも持たないので、その分の費用もかかりませんし、落ちる場所も減ります。

### テスト環境が本番と同じものになる

テスト環境は、同じ生成物を別の宛先に配っているだけです。コミットされたファイル一式をもう1つのWorkerにデプロイし、前段にBASIC認証を置いて社内向けにしています。DBの複製もコンテンツの同期も要りません。

CMSでステージング環境を作る場合は、コンテンツを含めた複製と、そのあと本番とどう同期するかという問題が付いてきます。しかも複製した時点から、2つの環境のコンテンツは少しずつずれていきます。確認したページと本番に出るページが同じであることは、運用で担保するしかありません。

静的ファイルなら、テスト環境で見たものと同じファイルがそのまま本番に出ます。環境の違いはドメインと認証の有無だけで、中身は一致します。

### 静的配信とフォームを同じ場所に置ける

そもそもCloudflare Workersを選んだのは、[お問い合わせフォーム](https://bynd.ne.jp/contact)があったからです。

サイトを完全な静的ファイルだけで組むと、フォームの送信先を外に探すことになります。外部のフォームサービスを契約するか、別のところにAPIを立てるか。どちらも、サイト本体とは別に管理する対象が1つ増えます。

Workers Static Assetsは、静的アセットの配信とコードを1つのWorkerに同居させられます。GETは静的アセットがそのまま返し、POSTはコード側に届くので、フォームの受け口を同じデプロイ単位で実装できました。CMSを外した結果として動的な処理がゼロになったわけではなく、必要な1本だけを自分で書いた形です。

スパム対策を同じ層で完結できるのも選んだ理由でした。実装側にはhoneypotと入力検証とOrigin検査を入れ、その手前でエンドポイントへのレート制限をかけています。配信しているCDNと同じ場所にこの手段が揃っているので、フォーム1本のために別サービスを増やさずに済みました。攻撃が増えたらCAPTCHAを足す、という拡張も同じ基盤の上でできます。

## 公開までに残る手作業

ここまでの構成では、デザインツールからの同期とデプロイをエンジニアが実行しています。編集だけを非エンジニアに移しても公開のたびに人の手が要るなら、CMSを外した意味は薄くなります。

ただ、残っているこの2つは、どちらも仕組み上どうしても人がやる作業ではありません。

デプロイは、ブランチへのpushをきっかけに動かせます。GitHub ActionsからWorkersにデプロイするだけなので、テスト環境への反映から順に自動化していけます。今は更新の頻度が低く、コマンド1つで足りているので手動のままにしています。

同期のほうも、定期実行のエージェントに任せられます。デザインツール側に変更があれば取得してPRを作るところまでをスケジュール実行にしてしまえば、編集者が保存した時点で差分のPRが立ちます。

そこまで進めても、差分を見て承認する工程は残す前提です。これは自動化し残したのではなく、公開の前に門番を置くために意図して残すものです。人に残るのは中身を見て判断することだけで、手を動かす作業は自動化に寄せていけます。

そして、最後に残るこの承認も、エンジニアでなくてもできます。文言の修正であれば、PRの差分に出るのは変更前後のテキストだけです。自分が直した箇所だけが変わっているかは、直した本人がいちばん正確に判断できます。編集者にGitHubのアカウントを用意し、見る観点を決めておけば、編集から公開までを非エンジニアの手で回せるはずです。

## どこまでなら通用するのか

ここまでの利点は、いくつかの条件が揃って初めて成立します。

**ページが増え続けないこと**が最大の条件です。今回はニュース一覧の各行を外部のプレスリリースや別サイトの記事へのリンクにして、本文ページを持たない設計にしました。だからニュースが増えてもページは増えません。ブログのように記事が積み上がる構成なら、この作り方は選びません。1本増えるたびにデザインツール側でページを作ることになり、それは編集ではなく制作の仕事です。

規模も30ページ程度での判断です。数百ページになると、生成物をまるごとコミットして差分を読む運用が成り立つかは、あらためて考える必要があります。

サーバー側で動く部分は、1本ずつ自分で書くことになります。CMSならプラグインを入れて設定するだけで済んでいたかもしれない部分です。今回はフォームが1本だけだったので実装して終わりましたが、仕様の違うフォームが何本もあるサイトなら、この差は無視できません。

画面のクリックでは直せない箇所も残ります。meta descriptionやOGP、sitemap、リダイレクトの類はエンジニア側の作業です。「非エンジニアがサイトのすべてを更新できる」状態ではありません。

そして、正本を一箇所に固定する規律が要ります。この構成での正本はデザインツール側で、リポジトリのHTMLは同期されてきた結果です。ここでリポジトリのHTMLを直接直すと、次の同期で編集者の知らないうちに上書きされて消えます。CMSなら編集する場所は管理画面しかなく迷う余地がありませんが、こちらは自分で決めて守る必要があります。

## おわりに

CMSを選ぶ理由が「非エンジニアが更新できるようにするため」だけなら、その理由はもう成立しないことがあります。編集UIは、CMS以外のところから持ってこられるようになりました。

判断の分かれ目は、編集UIをどこから調達できるかと、ページが増え続けるかどうかの2点だと思っています。今回はどちらも条件を満たしていたので、CMSを持たない構成を選びました。

large_eyecatch.png

medium_eyecatch.png

small_eyecatch.png

thumbnail_eyecatch.png

eyecatch.png

非エンジニアが更新するサイトを、CMSを入れずに静的HTMLで作った

## はじめに

ここ数年でAIコーディングツールは急速に進化し、開発現場での役割も大きく変わってきています。本記事では、これまでのAI活用の変遷を振り返りつつ、「AIが自律的にコーディングを行う」開発体制を実現するためのアイデアと、それを支える技術・ルールについて紹介します。

## これまでのAIの使い方

### 2025年頃：人間主体、AIはサポート役

この頃のAIは、あくまで人間の開発をサポートする存在でした。

- GitHub Copilot のサジェスト機能でコード補完してもらう
- 分からないことをチャットで質問する

主役はあくまで人間で、AIは「気の利く補助ツール」という位置づけです。コードの大部分は人間が書いており、AIの提案を取捨選択しながら開発を進めていました。

### 2026年〜：AI主体、人間がサポート役

過去記事「[AIエージェントを中心に据えた開発環境への移行](https://sterfield.co.jp/blog/ide-to-ai-agent/)」で紹介したように、Claude Code の活用が進んだことで主従関係が逆転しました。

- コーディングはAIが行い、人間は指示を出すだけ
- ISSUEを渡せば、実装からPR作成までAIが進めてくれる
- 複数のタスクを並列で走らせられるようになり、1スプリントあたりのISSUE消化量が2倍近くに増えた

人間は「コードを書く人」から「AIに指示を出し、成果物を確認する人」に変わりつつあります。

## これから実現したいこと

次のステップとして目指しているのが、**AIが自律的にコーディングを行う**開発体制です。

イメージとしては、AIを1人のプログラマーとしてチームに迎え入れる感覚です。役割分担は次のように考えています。

| 工程           | 担当                 |
| :------------- | :------------------- |
| 設計           | 人間（AIがサポート） |
| コーディング   | **AI**               |
| コードレビュー | 人間（AIがサポート） |
| 結合テスト     | 人間（AIがサポート） |

線引きの考え方はシンプルで、**機械的に検証できる工程はAIに渡せる、実環境での判断や責任を伴う工程は人間に残す**、という基準で工程を仕分けています。

![開発フロー図](https://cont.sterfield.co.jp/uploads/dev_flow_303eb03ad7.png)

人間が設計してISSUEを起票すると、AIがそれを拾って実装し、PRを作成する。人間はレビューと結合テストで品質を確認する。コーディング工程を丸ごとAIに任せることで、人間は設計や検証といった、より判断が求められる仕事に集中できます。

これまでの「人間がAIに指示を出しながら一緒にコーディングする」スタイルとの一番の違いは、**コーディング中に人間が張り付いていなくてもよい**ことです。指示を出して結果を待つのではなく、ISSUEを起票した時点で人間の手を離れ、次に人間が関わるのはPRのレビューから。この間、人間は別の設計やレビューを進められますし、AIも複数のISSUEを並行して処理できます。

## 実現するための技術

### スキルエンジニアリング

スキルエンジニアリングとは、**チームの開発手順や暗黙知を「スキル」としてAIに教え込む**取り組みです。

Claude Code にはスキルという仕組みがあり、定型化された手順をパッケージ化しておけます。人間が明示的に呼び出せるだけでなく、AIが「今のタスクに関係する」と判断すれば自律的に使ってくれるのが強力な点です。例えば次のようなスキルを整備しています。

- ISSUEに書かれた仕様を元に実装し、lintなどの静的解析ツール実行までを一気通貫で行うスキル
- 人間がPRに書き込んだ指摘を読み取り、修正するスキル

ポイントは、毎回プロンプトで細かく指示するのではなく、**一度作り込んだ手順を何度でも再利用できる**ことです。プロンプトの品質が人によってバラつく問題も、スキルとして標準化してしまえば解消できます。

人間のプログラマーに開発マニュアルを渡して教育するのと同じように、AIにもスキルという形で手順を渡す。スキルが充実するほど、AIは「指示待ち」ではなく「手順を知っている状態」で作業できるようになります。

### ループエンジニアリング

ループエンジニアリングとは、**AIが自分で結果を確認し、修正を繰り返せるフィードバックループを設計する**ことです。

AIに自走してもらうには、「実装して終わり」ではなく「実装 → 単体テスト → 失敗したら修正 → 再テスト」というループを自力で回せる環境が必要です。具体的には次のような整備を進めています。

- 単体テストやlint、型チェックをコマンド一発で実行できるようにしておく
- 「単体テストが通るまで修正を繰り返す」という完了条件を明示して指示する
- レビュー指摘への対応も「修正 → 単体テスト → コミット」のループとして定義する

判定基準が機械的にチェックできる形になっていれば、AIは人間の介入なしにループを回し続けられます。逆にここが曖昧だと、AIは中途半端な状態で作業を終えてしまいます。

さらに一歩進めて、「ISSUEが起票されたらAIが自動で着手する」「レビューコメントが付いたら自動で修正に入る」といった、**開発フロー全体を大きなループとして回す**仕組みも構想しています。ここまでできれば、AIは本当の意味で「自走するプログラマー」になります。

### コンテキストエンジニアリング

もうひとつ重要なのが、**AIが判断に必要な情報へ迷わずたどり着ける状態を作る**ことです。

CLAUDE.md にプロジェクトのルールや構成を記述しておく、設計の背景をISSUEに残しておく、ドキュメントを最新に保つ。人間の新メンバーがオンボーディング資料で立ち上がるのと同じで、コンテキストが整理されているほどAIのアウトプットの精度は上がります。

## ルール

技術だけでなく、運用ルールも重要です。AIに任せる範囲が広がるほど、「どこまで任せてよいか」「問題が起きたとき誰が責任を持つか」を明確にしておく必要があります。現時点で決めているルールを3つ紹介します。

### 人間がやること、AIがやることを守る

人間がやらないといけないことを、AIがやってはいけません。

設計・コードレビュー・結合テストは人間の担当です。もちろんAIにサポートしてもらうのは構いませんが、**最終的な確認と判断は必ず人間が行う**。この線引きを守ることで、システムの品質を担保します。

AIの出力をそのまま信じてマージしてしまうと、品質の責任の所在が曖昧になります。「AIが書いたコードでも、承認した人間が責任を持つ」という原則は崩さないようにしたいです。

### 開発環境を人間とAIで分ける

「AIがコーディング中だから人間が動作確認できない…」という事態を防ぎたいので、開発環境は人間とAIで分離します。

- Dockerでコンテナを分ける
- 作業ディレクトリを分ける（git worktree の活用など）
- 同じポートやDBをなるべく共有しない

AIを1人のプログラマーとして扱うなら、環境も1人分用意するのが自然な考え方です。人間のチームでも開発環境を取り合うことはないはずで、AIも例外ではありません。物理的にPCを分けてしまうのもアリかもしれません。

環境が分離されていれば、AIが多少大胆な変更を試しても人間の作業には影響しません。これは「AIに安心して任せられる範囲」を広げることにも繋がります。

### GitHubのユーザーを分ける

次の理由から、人間の意思でコミット・PRを出したのか、AIが自律的にやったのかを判別できるようにしておくべきだと考えています。

- コミット履歴やPR一覧を見れば、AIの成果物だと一目で分かる
- ブランチ保護でレビューを必須にしている場合、自分のアカウントでAIが作ったPRは自分では承認できないが、ユーザーが分かれていればAIのPRを人間がレビュー・承認するフローが自然に成立する

これらを実現するために、AIのコミット・PRは GitHub App 経由で行うことを考えています。トレーサビリティの確保は、AIに権限を渡すうえでの大前提です。

## おわりに

この構想を実現して、より迅速かつ品質の高いサービスを提供していく所存です。

「AIに任せる範囲を広げること」と「人間が品質を担保すること」は、ルールと仕組みさえ整えれば両立できるはずです。これからも目まぐるしく発展するAIに乗り遅れないようにしたいですね。

large_eyecatch.jpg

medium_eyecatch.jpg

small_eyecatch.jpg

thumbnail_eyecatch.jpg

eyecatch.jpg

AIをチームの一員として迎える開発体制の構想

AIのデザインに「軸」を先に渡すと何が変わるのか Claude Design で検証してみました

最近では、Claude Code や ChatGPT などの生成AIを使いながら開発することが当たり前になってきました。

私自身も日々の開発でAIを活用していますが、以前と比べて仕事の進め方が大きく変わったと感じています。

以前は、要件を確認したあと、自分で実装方法を考え、コードを書き、デバッグを行い、最後にレビューを受けるという流れでした。

```
要件確認
　↓
設計
　↓
コードを書く
　↓
デバッグ
　↓
レビュー
```

しかし現在は、まずAIに実装方法を相談し、コードを作成してもらうことが増えました。

その後、AIが作成したコードを確認し、必要に応じて修正やテストを行っています。

```
要件確認
　↓
AIに相談する
　↓
AIがコードを書く
　↓
レビュー
　↓
修正・テスト
```

AIのおかげで、簡単な実装や調査にかかる時間は以前より短くなりました。

一方で、開発者に求められる役割は少しずつ変わってきていると感じています。

## 1. 要件を正しく理解する力

AIは指示された内容をもとにコードを作成します。

そのため、「何を実現したいのか」を自分自身が正しく理解し、AIに分かりやすく伝えることが大切です。

例えば以前は、「ヘッダーを作成してください」のような簡単な指示でも実装を始めることがありました。

しかし現在は、「レスポンシブ対応」「既存コンポーネントを利用する」「デザインに合わせる」など、要件を具体的に伝えることで、より期待に近いコードが返ってくると感じています。

AIを上手に使うためには、最初の指示がとても重要だと感じています。

## 2. AIが書いたコードをレビューし、品質を判断する力

AIが作成したコードは、そのまま使えるとは限りません。

例えば、

* 要件を満たしているか
* プロジェクトのコーディングルールに合っているか
* 読みやすく、保守しやすいコードになっているか
* パフォーマンスやブラウザ対応に問題はないか

などを確認する必要があります。

また、フロントエンドでは、デザインの意図やレスポンシブ対応など、人が確認しないと気づきにくい部分もあります。

実際にAIが作成したコードでは、デザインと細かな余白が異なっていたり、スマートフォン表示でレイアウトが崩れていたりすることもありました。

そのため、以前よりもコードを書く時間よりレビューし、品質を判断する時間の方が長くなったと感じることもあります。

## 3. 最適な方法を選ぶ力

AIは一つの答えだけではなく、複数の実装方法を提案してくれることがあります。

しかし、どの方法が現在のプロジェクトに最も適しているのかを判断するのは開発者です。

「動けばよい」ではなく、「長く運用しやすい実装かどうか」を考えることが大切だと思います。

## まとめ 〜「書く」から「判断する」へ〜

生成AIのおかげで、開発スピードは以前より速くなりました。

しかし、AIはあくまでも開発をサポートするツールです。

AIの登場によって、コードを書く時間は確かに減りました。

一方で、AIが作成したコードを理解し、レビューし、品質を判断する時間は増えています。

私は、フロントエンドエンジニアの仕事は「コードを書くこと」から、「コードを理解し、判断すること」へ少しずつ変わってきていると感じています。

これからのフロントエンド開発では、コードを書く力だけではなく、AIと協力しながら最適な実装を考え、正しく判断する力が、これまで以上に重要になっていくのではないでしょうか。

AI時代、フロントエンド開発で求められる力は変わったのか？

これまで「WEBサイトを作る」といえば、パソコンに向かって黙々とプログラミングコードを書くのが当たり前でした。しかし今、「AIに声で喋りかけて、自分の代わりにWEBサイトを作ってもらう」というSFのような世界が現実になっています。

今回は、シリコンバレーのプロたちも実践している、AIに「動画と音声」で指示を出す究極の効率化テクニック「ビデオハック」について、分かりやすく解説します！

### こんな人向け
- WEBサイトやECサイトをサクッと作りたい人
- AIツールへの「文字入力（プロンプト）」に限界や面倒くささを感じている人
- プログラミング知識ゼロでも、思い通りのデザインを実現したい人
- 業務の生産性を上げて「ラクして早い」を実現したい人
 
# 1. 「テキスト入力」の時代から「話しかける」時代へ
これまでのAIの使い方は、「チャット欄に文字（プロンプト）をタイピングして打ち込む」のが基本でした。 
しかし、テキストによる指示には以下のような課題があります。
- 指示文を考えるのがシンプルに面倒
- 「もっとシュッとさせて」「こういう雰囲気で」というニュアンスを言葉にしづらい
- プログラミングの知識がないと、的確な指示の出し方が分からない

「AIで効率化したいけれど、指示を入力するだけで疲れてしまう」という本末転倒な状況になりがちです。 
そこで今、トレンドセッターたちが注目しているのが、テキストではなく「動画と人間の声（音声）」を使ってAIに直接話しかけるアプローチです。 
最近のAI（ChatGPTやClaudeなど）は、「人間の声のニュアンス」や「画面に映っている映像」を同時に理解するマルチモーダル能力が爆発的に進化しています。 
キーボードを叩くのではなく、普通の人間に話しかけるように喋るだけで、AIが勝手に意図を汲み取ってWEBサイトのデザインからコーディングまでを爆速で終わらせてくれる時代が来ています。 

# 2. 画面を映して喋るだけ！「ビデオハック」の基本手順
この「動画と音声で指示を出す」アプローチを、クリエイターの間では「ビデオハック」と呼んでいます。 
やり方は驚くほどシンプルです。
### ビデオハックの手順
1. 画面を録画する：PCやスマホの録画機能を使って、自分の画面を映す
2. 声で説明する：画面を動かしながら、「ここをもっとこうして！」「ここにバナーを置いて！」と声で喋りながら録画する
3. AIに投げる：録画した動画（またはそのURL）を、そのままAIにアップロードする

これだけで、AIはあなたの「声のトーン」「マウスの動き」「映し出された画面」を分析し、作りたかったWEBサイトの見た目やシステムコードを一瞬で生成してくれます。 
AIを使いこなすために、難しい専門用語やプロンプトを熱心に勉強する必要はありません。AIの進化によって、私たちは普段の「人間の言葉」で指示を出すだけでよくなったのです。 

# 3. 実践！「AIビデオ指示」のおすすめツールと録画の3大原則
「自分もやってみたい！」と思った方向けに、具体的な録画方法と、AIに100%意図を伝えるためのコツを紹介します。

おすすめ録画ツール：Loom（ルーム） 
ビデオハックに最もおすすめなツールが「Loom」です。
### Loom（https://www.loom.com/）
- ブラウザ（Chrome）の拡張機能やスマホアプリから無料で利用可能。
- ボタン1つで「PC画面」と「マイクの音声」を同時に録画。
- 録画終了と同時に共有用URLが自動発行されるのが最大のメリット！！ 

重い動画ファイルをダウンロード・アップロードする手間がなく、URLをChatGPTなどのチャット欄に貼るだけでAIに共有できます。 
※PCやスマホの標準録画機能（MacのQuickTime、Windowsの「Win + G」など）で撮影した動画ファイルを直接AIにアップロードしても問題ありません。

## AIが迷わないための「録画の3大原則」
### ① マウスカーソルを「指差し棒」にする
「ここを直して」「ここにボタンを置いて」と指示するときは、マウスのカーソルを大きく動かして、その場所をぐるぐると囲むように動かしてください。 
AIはカーソルの動きを非常に細かく見ています。言葉足らずでも「直すべき場所」が正確に伝わります。

### ② 参考となるWEBサイトを画面に映しながら喋る
例えばECサイトを作りたいなら、お手本としたい競合他社のサイトを映しながら喋るのが最も効果的です。 
「このサイトの上部メニューが使いやすいので、これと同じ構造にしてください。ただし、ブランドカラーに合わせてオレンジ基調に変えてほしいです」 
このように、お手本をベースに「ここを真似て、ここを変更する」と指示を出すと、AIの生成クオリティが劇的に跳ね上がります。

### ③ 言い間違えても気にせず「独り言」のように喋り続ける
綺麗にプレゼンする必要はまったくありません。 
途中で「あ、やっぱり今のナシで、青に変えてください」「えーっと……」と噛んだり迷ったりしても、AIは完璧に文脈を理解してくれます。友達にボイスメッセージを送る感覚でフランクに喋るのがコツです。 

# 4. WEBビジネスは今後どう変わるか？
この「話しかけるだけで物事が進む」変化は、私たちの仕事のやり方をどう変えていくのでしょうか。
### WEB制作者は「監督（ディレクター）」になる
手を動かして複雑なプログラミングコードを書く作業は、大部分をAIが引き受けてくれるようになります。
これにより、人間側の役割は「アイデアや情熱を言葉にして、AIに指示を出す監督（ディレクター）」へとシフトしていきます。 

# 5. まとめ

テクノロジーの進化により、WEB制作は「一部の専門家だけのもの」から「誰でも言葉一つで扱える身近なもの」へと民主化されています。 
これからのAI時代、無理にプログラミング言語を勉強する必要はありません。 
最も価値を持つのは、頭の中にある「こんなものを作りたい」というアイデアを、自分の声と自分の言葉でアウトプットする「伝える力（言語化力）」です。 
タイピングやPC操作に苦手意識がある人こそ、この「話しかける」ビデオハックの恩恵を最大に受けられます。 
まずはスマホの音声入力から、気軽にAIに話しかけてみましょう。 
驚くほど「ラクして早い」制作の未来が体験できるはずです！！

large_Gemini_Generated_Image_jpoi20jpoi20jpoi.png

medium_Gemini_Generated_Image_jpoi20jpoi20jpoi.png

small_Gemini_Generated_Image_jpoi20jpoi20jpoi.png

thumbnail_Gemini_Generated_Image_jpoi20jpoi20jpoi.png

Gemini_Generated_Image_jpoi20jpoi20jpoi.png

タイピングはもう古い？「AIに話しかけるだけ」でWEBサイトが完成する新しい効率化術

## 目次

1. [はじめに](#はじめに)
2. [Claude Coworkとは何か](#claude-coworkとは何か)
3. [使い始めるための準備](#使い始めるための準備)
4. [セットアップ手順](#セットアップ手順)
5. [コネクタ：Webサービスと安全に連携する](#コネクタwebサービスと安全に連携する)
6. [基本タスク：ファイル・PDF・画像を処理する](#基本タスクファイルpdf画像を処理する)
7. [Dispatch：スマホからPCに仕事を投げる](#dispatchスマホからpcに仕事を投げる)
8. [Scheduled：定期タスクの自動実行](#scheduled定期タスクの自動実行)
9. [まとめ：Coworkで変わる仕事のスタイル](#まとめcoworkで変わる仕事のスタイル)

---

## はじめに

ChatGPTやClaudeのチャットを使っていて、こんなふうに感じたことはありませんか？

- 「毎回同じ作業を頼むのが面倒くさい」
- 「外出中でも、家のPCに作業を任せておけたらいいのに」
- 「ファイルをいちいちアップロードするのがストレス」

その悩みを、**Claude Cowork**が解決します。

Coworkは、Anthropicが発表した**デスクトップAIエージェント**です。チャットで指示を出すだけでClaudeが自律的にファイルを整理したり、ドキュメントを作成したり、Webを調べたりします。「AIとの対話」から「AIに仕事を任せる」へ。そんな新しい使い方を可能にしたのがCoworkです。

---

## 📌 Claude Coworkとは何か

Claude Coworkは、ひと言で言えば**「自分のPCで働くAIアシスタント」**です。

**ChatタブとCoworkの違い：**

```
Chat（ブラウザ・チャットタブ）：「このドキュメントを要約して」→ コピー&ペーストが必要
Cowork（デスクトップ版）：「Downloadsフォルダの請求書PDFをすべてExcelにまとめて」→ 自動でやってくれる
```

CoworkはデスクトップアプリとしてあなたのPCに常駐し、ファイルやアプリに直接アクセスできます。ブラウザやコネクタを通じて、ファイル操作・Web検索・外部サービスへのアクセスを自律的に行います。まるで隣で働く同僚のような存在です。

### Coworkでできること（主な機能）

| カテゴリ | できること |
|---------|-----------|
| **ファイル操作** | フォルダ整理、ファイル名の一括変更、PDF・Excelの処理 |
| **ドキュメント作成** | Wordレポート、Excelシート、スライドの自動生成 |
| **情報収集** | Web検索、調査まとめ、比較レポートの作成 |
| **アプリ操作** | ブラウザ操作、フォーム入力 |
| **スケジュール実行** | 毎朝のメール確認、週次レポートの自動作成 |
| **Dispatch** | スマホからPCのClaudeにタスクを遠隔指示 |

---

## 🚀 使い始めるための準備

### 必要なもの

- **PC**：macOS（Apple Silicon / Intel）または Windows（x64 / arm64）にインストールされたClaude Desktop最新版
- **プラン**：Claude ProまたはMax以上
- **スマホ**：Dispatchを使う場合はClaudeモバイルアプリ（iOS/Android）最新版
- **インターネット接続**：両方のデバイスで常時接続が必要
- **Claude in Chrome（推奨）**：特定のWebページを操作・閲覧するタスクには、ChromeブラウザへのClaude in Chrome拡張機能のインストールが必要です。基本的なWeb検索はCowork単独でも可能ですが、サイトへのログインやページ内容の読み取りなどにはこの拡張機能が必要になります。すべての有料プランで利用可能。

⚠️ **注意**：無料プランではCoworkは使えません。Coworkタブが表示されない場合は  **claude.com/download** からアプリを最新版に更新してください。

📎 公式要件：[Claude Coworkを始める（公式ヘルプ）](https://support.claude.com/ja/articles/13345190-claude-cowork%E3%82%92%E5%A7%8B%E3%82%81%E3%82%8B)

---

## 🛠️ セットアップ手順

### ステップ1：Claude Desktopをインストールする

1. **claude.com/download** にアクセス
2. お使いのOS（macOSまたはWindows）に合ったバージョンをダウンロード
3. インストーラーを実行してアプリを起動
4. Claudeアカウントでサインイン

### ステップ2：Coworkタブを確認する

アプリ上部に **Chat ／ Cowork ／ Code** の3つのタブが表示されます。

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

Coworkタブが表示されていない場合は、アプリを最新版に更新してみてください。

### ステップ3：初めてのタスクを試してみる

準備が完了したら、まずは簡単なタスクから試しましょう。

```
「Downloadsフォルダ内のPDFファイルを『PDFs』というフォルダに移動して、
画像ファイルは『Images』フォルダにまとめてください」
```

Claudeが計画を提示し、実行ログを表示しながら作業を進めます。

**【実際の画面】**
![img_02.png](https://cont.sterfield.co.jp/uploads/img_02_4b33633040.png)

---

## 🔌 コネクタ：Webサービスと安全に連携する

**コネクタ（Connector）** とは、GmailやGoogle DriveなどのWebサービスにCoworkがAPI経由で直接アクセスするための連携機能です。画面を操作する必要がないため、速くて安定しています。

### コネクタとComputer Useの使い分け

| | コネクタ | Computer Use |
|---|---|---|
| **使う場面** | Gmail・Google Drive・Slackなどのクラウドサービス | コネクタがないアプリ・社内システムなど |
| **仕組み** | API経由で直接連携（高速・安定） | 画面を見てクリック・入力（UI操作） |
| **設定** | 「Customize」→「コネクタ」タブからサービスを選んで連携 | Computer Useを別途有効化 |

**基本の考え方**：対応コネクタがあるサービスはコネクタを使い、それ以外にはComputer Useを使います。

### コネクタの設定方法

1. Claude Desktopの左サイドバーにある「Customize」をクリックする

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

2. 「コネクタ」タブから使いたいサービス（例：Gmail）を選び、「+」ボタンを押して連携する

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

3. 連携後はすべてのセッションで自動的に使えるようになります

**対応サービス例**：Gmail・Google Drive・Google Calendar・Slack・GitHubなど

📎 [コネクタを使ってClaudeの機能を拡張する（公式ヘルプ）](https://support.claude.com/ja/articles/11176164-use-connectors-to-extend-claude-s-capabilities)

---

## 📋 基本タスク：ファイル・PDF・画像を処理する

Coworkのチャットに指示するだけで、ファイル操作からドキュメント作成まで幅広く対応します。PC内のファイルを直接指定できるため、いちいちアップロードする手間がありません。

### 活用例

**資料整理の自動化：**

```
「Downloadsフォルダにある請求書PDFを全部確認して、
クライアント名・金額・日付をExcelシートにまとめてください」
```

経費精算や請求書管理が、手動入力なしで完了します。

**PDFや画像の読み取り：**

```
「この契約書PDFの重要なポイントを箇条書きでまとめてください」
「この名刺の画像から名前・会社・連絡先を読み取ってリストにして」
```

PDFの要約・画像内テキストの抽出・表の変換など、幅広い形式に対応しています。

**情報収集＆レポート作成：**

```
「〇〇業界の最新ニュースをWebで調べて、
ポイントをまとめたWordファイルを作成してください」
```

情報収集から資料作成まで、一気通貫で対応します。

---

## 📱 Dispatch：スマホからPCに仕事を投げる

Coworkの中でも特に便利なのが「**Dispatch**（ディスパッチ）」です。

### Dispatchとは？

**外出先のスマホから、自宅・オフィスのPCのClaudeに指示を送れる機能**です。スマホとPCがそれぞれインターネットに接続されていれば使えます。

たとえば通勤電車の中でスマホから「〇〇業界の最新トレンドをWebでリサーチして、Wordファイルにまとめて保存しておいて」と指示するだけで、デスクトップのClaudeが自律的に作業を進めます。会社に着いたときには資料がすでに完成している、そんな使い方ができます。

スマホとデスクトップをまたいで**1つの継続的な会話スレッド**が維持されるので、前の会話の内容を引き継いだまま続きから作業できます。

### Dispatchのセットアップ手順

**PC側（Claude Desktop）:**

1. Coworkタブを開き、左サイドバーの「Dispatch」をクリック
2. 「始める」ボタンをクリック
3. ファイルアクセス許可を有効にし、「スリープしない」設定をオンにする

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

**スマホ側（Claudeモバイルアプリ）:**

1. Claudeアプリを開き、サイドバーの「Dispatch」をタップ
2. PCと同じClaudeアカウントにログインしていれば接続完了

 📖 **参考**：
- [Dispatch in Claude Cowork（公式・英語）](https://claude.com/resources/tutorials/dispatch-in-claude-cowork)
- [Claude Cowork Dispatch のセットアップガイド──QR ペアリング廃止後の最新フロー（Zenn・日本語）](https://zenn.dev/and_dot/articles/e42520784892a2)

設定完了！以降はスマホからメッセージを送るだけで、PCのCoworkが自動でタスクを実行します。

⚠️ **スリープに注意**：ここで言う「スリープ」はPCが省電力モードに入った状態のことで、**画面をオフにするだけであれば問題ありません**。ただし**ノートPCの蓋を閉じるとスリープ扱いになる**ため注意が必要です。タスク実行中にスリープするかアプリを閉じると即停止します。

---

## 🕐 Scheduled：定期タスクの自動実行

### Scheduledとは？

「毎朝〇〇をやって」「毎週月曜に〇〇をまとめて」という定期タスクを自動化する機能です。一度設定すれば、あとはClaudeが繰り返し実行します。

### 使い方

Coworkのチャットに日本語で指示するだけで設定できます：

```
「毎朝9時にGmailを確認して、未読の重要メールを
箇条書きでまとめてデスクトップに保存しておいて」
```

設定後は左サイドバーの「**Scheduled**」から確認・編集・一時停止・削除が可能です。

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

### 実行条件

⚠️ **PCが起動していてClaude Desktopアプリが開いている**間のみ実行されます。スリープ中やアプリが閉じている場合はスキップされますが、**PCが起動してアプリが再度開かれると、スキップされたタスクが自動的に実行されます**。スキップされた実行はタスク履歴と通知で確認できます。

### 活用例

| やりたいこと | 指示の例 |
|------------|---------|
| 毎朝のメール確認 | 「毎朝9時にGmailの未読をまとめてデスクトップに保存して」 |
| 週次レポート | 「毎週月曜の朝にプロジェクトの進捗をまとめて」 |
| 日次情報収集 | 「毎朝〇〇業界のニュースを調べてWordにまとめて」 |

💡 GmailなどはCoworkの **コネクタ（Connector）** で連携するとスムーズです（Computer Use不要）。

📎 [Coworkで定期的なタスクをスケジュール設定する（公式ヘルプ）](https://support.claude.com/ja/articles/13854387-claude-cowork%E3%81%A7%E5%AE%9A%E6%9C%9F%E7%9A%84%E3%81%AA%E3%82%BF%E3%82%B9%E3%82%AF%E3%82%92%E3%82%B9%E3%82%B1%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B)

---

## 🌟 まとめ：Coworkで変わる仕事のスタイル

Claude Coworkは、AIとの関係を「質問する道具」から「仕事を任せる同僚」へと変える画期的なツールです。

**こんな人に特におすすめです：**

- 繰り返し作業が多く、自動化したいと感じている人
- ファイル整理やレポート作成に時間を取られている人
- 移動中や隙間時間にも仕事を進めたい人
- テクニカルな知識なしにAIをもっと活用したい人

まずは簡単なファイル整理から試してみて、徐々に活用範囲を広げていくのがおすすめです。

---

## 参考リンク

- [Claude ダウンロードページ](https://claude.com/download)
- [Claude Coworkを始める（公式ヘルプ）](https://support.claude.com/ja/articles/13345190-claude-cowork%E3%82%92%E5%A7%8B%E3%82%81%E3%82%8B)
- [Coworkのどこからでもタスクを割り当てる（公式ヘルプ）](https://support.claude.com/ja/articles/13947068)
- [コネクタを使ってClaudeの機能を拡張する（公式ヘルプ）](https://support.claude.com/ja/articles/11176164-use-connectors-to-extend-claude-s-capabilities)
- [コンピュータ使用をCoworkで有効にする（公式ヘルプ）](https://support.claude.com/en/articles/14128542)
- [Coworkで定期的なタスクをスケジュール設定する（公式ヘルプ）](https://support.claude.com/ja/articles/13854387-claude-cowork%E3%81%A7%E5%AE%9A%E6%9C%9F%E7%9A%84%E3%81%AA%E3%82%BF%E3%82%B9%E3%82%AF%E3%82%92%E3%82%B9%E3%82%B1%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B)

---

*最終更新：2026年5月 ／ 情報はリサーチプレビュー段階のものを含みます。最新情報はAnthropicの公式サイトをご確認ください。*


Claude Coworkとは？初心者でもわかる完全ガイド【2026年版】

## はじめに

前回の記事「[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との組み合わせも試してみてください。開発の体験が一段変わると思います。

Pathのアプリのメニューぽい動きをjQueryで作ってみる1

Related