アニメーションやフォーム周りなど、「どこまでJavaScriptで実現できるか」の境界線が見えず、不安になるデザイナーさんは多いはずです。
この境界線があいまいだと、見積もりのブレや後からの仕様変更につながります。
この記事では、JavaScriptの「できること・できないこと」の境界線をわかりやすくお話しします。
クライアントとの打ち合わせで、「これは画面内でできる範囲なので大丈夫です」と自信を持って言えるようになるための、やさしい入門ガイドです。
1. クライアント打ち合わせで“答えられない焦り”が起きる理由
（１）「これ実装できますよね？」と突然ふられる瞬間
クライアントとの打ち合わせ中、何気ない流れで「ユーザーがスクロールしたら商品がふわっと出てくる感じ、できますか？」と聞かれたことありませんか？
頭では「アニメーションだからJSなのかな？」と思いつつ、確信が持てず笑顔でごまかす—このシーン、デザイナーさんからよく聞きます。
その場で返せないと、「技術に弱いと思われたらどうしよう…」と不安が一気に膨らんでしまうんですよね。
（２）判断できないのは“スキル不足”ではなく“情報構造を知らないだけ”
多くのデザイナーさんは「自分が勉強不足なんだ」と思い込みがちですが、実際にはそうではありません。
そもそも JavaScript が どこで動いているのか（ブラウザなのかサーバーなのか）という前提が説明されないまま、いきなり “JSでできる／できない” を判断しろと言われても無理があります。
技術を知らないのではなく、「地図を渡されていない」状態なんです。
（３）デザイナーとコーダーの“イメージのズレ”はこうして生まれる
よくある会話の例を一つ挙げます。
デザイナー：
「お問い合わせフォームを送信したら自動返信メールも欲しいんですけど、JSでできますか？」
コーダー：
「JSだけだとメール送れないんですよ…。サーバーが必要で…」
この時、デザイナーさんは“画面で何か起こっている＝全部JSの仕事”というイメージを持っています。
一方コーダーは、“ブラウザでできることとサーバーでできることは別物”という前提で会話しています。
この前提の違いが、誤解のはじまりなのです。
（４）焦りの正体は「知らないこと」よりも「聞けない空気」
打ち合わせ中に「それ、JSでできるんですか？」と聞き返すのは勇気が要ります。しかも相手がクライアントだと、さらにハードルが上がります。
✅ 場の空気が止まってしまうのが怖い
✅ “この人に任せて大丈夫かな”と思われたくない
✅ そもそも質問するための基礎知識がない
このような状態で冷静に判断するのは難しいことです。
（５）だからこそ、まずは“正しい地図”を手に入れることが先
焦りをなくす最初の一歩は、「JSってそもそもどこで動いていて、何ができて何ができないのか」を正しく捉えることです。
細かいコードを書く必要なんてありません。
どこまでがブラウザで完結し、どこから先はサーバーが必要なのか—この境界線を知るだけで、クライアントとの会話は一気にラクになります。
2. まずはここだけ！JavaScriptの“役割”をデザイナー向けに超シンプルに整理する
（１）JavaScriptは“ブラウザの中で動くプログラム”
JavaScriptと聞くと「プログラミング＝難しい」という印象が先に立ちますよね。
でも、デザイナーさんがまず理解すべき本質はもっとシンプルです。
JavaScriptはブラウザの中で動くプログラムです。
デザインデータ（HTMLやCSS）が読み込まれるとき、同時にJavaScriptもブラウザに渡され、そこで実行される仕組みになっています。
この“ブラウザの中だけで動く”という前提を理解すると、できること・できないことが一気に明確になります。
（２）「ブラウザが単独でできること」と「サーバーがいないとできないこと」の境界線
ここが、デザイナーさんがもっともつまずきやすい部分です。
打ち合わせ中に判断が難しくなるのは、この境界線が見えていないからなんです。
ブラウザは、言い換えると“1人で動くアプリ”のような存在です。ブラウザだけで完結する動作はJavaScriptで実行できます。
でも、外部のデータを取りに行ったり、メールを送信したりする場合は、ブラウザ単独では完結せず、サーバーが必要になります。
ここが非常に大事なポイントです。
（３）表示の流れをかんたんに整理すると「なるほど！」となる
専門用語を使わずに、ウェブページが表示される流れを整理すると次のようになります。
ブラウザがサーバーに「ページちょうだい」とリクエストを送る↓サーバーが HTML・CSS・画像・JS などのセットを返す↓ブラウザがそれらを組み立ててページを表示する↓ページを表示すると同時に JS も実行される
つまり、JavaScriptはページが読み込まれたあと、ブラウザの中で勝手に動き始めるわけです。
だからこそ、画面内でのアニメーションやポップアップなどは、ブラウザ側で完結するためJavaScriptで十分対応できます。
（４）なぜフォーム送信やメール送信は“JSだけ”ではできないのか
これはデザイナーさんがもっとも誤解しやすいポイントです。
「フォームを送信する＝画面上の操作だからJSの担当」と考えがちですが、実際には違います。
フォーム送信後に
✅ メールを送る
✅ データを保存する
✅ スプレッドシートに記録する
といった動作を行うには、ブラウザではなくサーバーが動く必要があります。
ブラウザはあくまで「画面の中の動き」しか担当していないため、外の世界へメールを送ることはできません。
言い換えると、JavaScriptは“手紙を書く”ことはできますが、“ポストに投函する”ことはできないんですね。
（５）「この動作はブラウザ内で完結している？」と考えるだけで技術判断がラクになる
JSを理解するコツは、“難しいコードの意味を理解すること”ではありません。
もっと簡単で、“この動作はブラウザの中だけで完結している？”と考えることです。
✅ 画面内の見た目が変わる
✅ 動きやアニメーションがある
✅ ユーザーの操作に反応する
これらはブラウザ内で完結しているのでJSが担当できます。
✅ メールを送る
✅ データを保存する
✅ 外部サービスとやり取りする
これらはブラウザでは完結しないためサーバーの仕事です。
この境界線を知るだけで、クライアントからの要望に対して「これはJSでできそう／これはサーバー側の担当」と、打ち合わせの場でも冷静に判断できるようになります。
3. LPでよくある“JSでできること”を実例で理解する
（１）「画面の中だけで完結する動き」は基本的にすべてJSでできる
JavaScriptはブラウザの中で動くプログラムなので、ページの中で「見た目が変わる」「動く」「切り替わる」といった挙動はほぼすべてJSが担当できます。
特にLP制作では、ユーザーの視線を導くために“ちょっとした動き”が多く使われますよね。
実はその多くがJavaScriptで実現できます。
ここを押さえておくと、クライアントからの要望に対して自信を持って判断しやすくなります。
（２）アニメーション：スクロールしたらふわっと出る、ゆっくり動く
LPで一番よく使われるのが、スクロールに合わせて要素を表示したり動かしたりするアニメーションです。
クライアント：
「この商品、スクロールしたらフワッと表示させたいんですよね」
デザイナー：
「（これはJSでできるはず…！）」
この“画面内だけで完結する動き”はJSで問題なく実現可能です。CSSアニメーションと組み合わせて使われることも多く、コーダーから見ても難易度は比較的低めです。
（３）スライダー・カルーセル：画像が自動で横に流れる
商品紹介やレビューなどでよくある「画像が自動で流れる」スライダー機能。
これはJavaScriptの定番中の定番です。
ライブラリ（Swiperなど）を使うことも多いため、コーダーとしては実装イメージが明確です。
デザイナーさんとしては、「スライダーはJSでできる」という前提だけ押さえておくだけでも、制作の見積もりや構成案が作りやすくなります。
（４）タブ切り替え：クリックすると内容が入れ替わるUI
「サービス内容」「料金」「FAQ」など、情報が切り替わるタブUI。
これもJSで実現できます。
ユーザーがタブをクリック↓JSが“表示するブロック／非表示にするブロック”を切り替える
という流れで処理されます。
画面内で完結するため、サーバーとの通信は不要です。
ただし、タブの数が多いとコーダー側は構造を工夫する必要があるため、制作前に共有しておくとスムーズです。
（５）モーダル・ポップアップ：クリックするとウィンドウが開く動作
LPでは、よく「詳しく見る」や「期間限定クーポン」などをモーダルで表示することがあります。
これももちろんJavaScriptの守備範囲です。
よくある勘違いは、デザイナーさんが「画面が暗くなって、真ん中にボックスが出るだけだから簡単ですよね？」と思い、コーダーは「スマホ対応があるので少し調整が必要…」と考えているケースです。
モーダルはJSでできることは確かですが、「簡単に見えるけれどスマホでは複雑」という裏側だけ知っておくと、コミュニケーションがスムーズになります。
（６）カウントダウンタイマー：締切までの時間を動的に表示する
期間限定キャンペーンでよく使われる「あと◯日◯時間◯分」というタイマー。
これもJavaScriptで簡単に実現できます。
画面内で時間を計算して表示するだけなので、サーバー通信は不要です。
クライアントからの要望としても非常に多い機能なので、「カウントダウンはJSでできます」と覚えておくと打ち合わせがラクになります。
（７）フォーム入力チェック：未入力や誤入力を画面上で検知する
「メールアドレスが正しくありません」「必須項目が未入力です」
こうした表示もJavaScriptの役割です。
ただし、ここで誤解が起きがちなのが、“入力チェックはJSでできるが、フォーム送信やメール送信はJSだけではできない”という点です。
（８）「ユーザーの操作に反応して何かが変わる」ものはほとんどJS
まとめると、LP制作で登場する“動き”の多くは、ブラウザの中だけで完結する＝JSで実現可能ということです。
✅ ふわっとアニメーション
✅ スクロールエフェクト
✅ スライダー
✅ タブ切り替え
✅ ポップアップ
✅ カウントダウン
✅ フォームの入力チェック
これらはすべてJavaScriptで対応できます。
しかし、逆にブラウザを超えて「外の世界」とやり取りする必要があるものはJSだけではできません。
次は、その“できないこと”を具体例とともに整理していきます。
4. “JSだけではできないこと”：フォーム送信・メール送信・データ保存など
（１）「画面の外に出る処理」はすべてサーバーの担当
ここからは、読者の方がもっとも誤解しやすい領域に入ります。
JavaScriptは“ブラウザの中だけで動く”という性質があるため、ブラウザの外に対して何か働きかける処理は一切できません。
言い換えると、画面の中で起きる動き＝JSでできる画面の外で起きる処理＝サーバーが必要というシンプルな構造です。
この前提を押さえるだけで、受注前の技術判断が驚くほどラクになります。
（２）フォーム送信はJSだけでは完結しない
LP制作で最もズレが起きやすいのが「お問い合わせフォーム」です。
例えば、クライアントとの会話でよくあるのがこんな流れ。
クライアント：
「フォーム送信したら自動返信メール来ますよね？」
デザイナー：
「（画面の操作だしJSかな…？）」
実はここが大きな勘違いポイントです。
フォーム送信 → メール送信 → データ保存
これらはすべて、ブラウザの外で起きる処理です。
ブラウザ単独ではメールを送ることも、データを蓄積することもできません。
JSができるのは、あくまで
✅ 入力内容にエラーがないかチェックする
✅ エラー表示を出す
✅ 画面上でフォームを操作しやすくする
ここまでです。
“送信そのもの”はサーバー側の仕事なのです。
（３）メール送信はブラウザからできない：なぜ外部に発信できないのか
なぜJSでメール送信ができないのか？
それはブラウザがセキュリティ上、“勝手に外へ情報を送らない仕組み”で作られているからです。
もしブラウザからメールが送れたら、
✅ 勝手にスパムを送られる
✅ 情報が漏れる
✅ 悪用されやすくなる
など大きな問題が生まれてしまいますよね？
だからこそ、メール送信は必ずサーバー（PHP・Google Apps Script・外部サービスなど）が担当するように決まっています。
「メール送信は絶対にJSだけではできない」
この一点を覚えておくだけで、打ち合わせで迷うことが大きく減ります。
（４）データ保存・データ取得：サーバーや外部サービスが必要
以下のような動作もJavaScriptだけではできません。
✅ ユーザー情報をデータベースに保存
✅ スプレッドシートに記録
✅ 商品の在庫数を取得
✅ 会員情報の読み込み
✅ サイトにログイン機能をつける
✅ サイトにショッピング機能をつける
これらはすべて“外の世界”にあるデータとやり取りするため、ブラウザ単独では処理不可能です。
JSはあくまで“操作のきっかけになるだけ”で、実際の処理はサーバーや外部APIが行います。
（５）「JSでできない」というより「JSだけでは完結しない」という考え方
デザイナーさんが覚えるべき大事な視点は、“できない”のではなく、ブラウザでは完結しない処理はJSの外で行われるという構造です。
例えば、
✅ フォーム送信 → JSは画面側、サーバーが送信処理
✅ 会員情報照会→ JSは操作の受付、データはサーバーから取得
✅ メール送信→ JSはボタン押下のトリガー、メール処理はサーバー
このように、JSは“操作の受付係”、サーバーは“外の世界とやり取りする係”として働いています。
両者の役割が違うだけで、どちらが優れているという話ではありません。
（６）デザイナーとコーダーの会話のズレはここから生まれる
ここで少し、よくある会話のズレを見てみます。
デザイナー：
「フォーム送信したら、CSVで管理画面にも保存できますか？」
コーダー：
「JSだけでは無理ですよ。保存先の仕組みが必要なので…」
デザイナーさんからすると“画面上の動き”も“メール送信”も“データ保存”もすべて同じ“フォームの一連の流れ”に見えます。
一方コーダーは、“画面の中で完結するところ”と“外の世界の処理”を完全に分けて考えています。
この視点の違いが、技術コミュニケーションのすれ違いにつながるのです。
（７）判断のコツは「ブラウザの外に出ているか？」を自分に問うこと
まとめると、JSだけではできないことは一つの共通点があります。
それは、“ブラウザの外”へ情報を送る or 外部から情報を取ってくる処理ということ。
✅ メールを送る
✅ データを保存する
✅ データを取得する
✅ 外部サービスと連携する
これらはすべてサーバーの仕事です。
「この動作、ブラウザの外に出ている？」
この質問を自分にしてみるだけで、受注前の判断はグッとラクになります。
次は、こうした誤解がどうして生まれるのか、デザイナーさんとコーダーの会話例を使ってさらにクリアにしていきます。
5. よくある要望をデザイナーとコーダーの“ズレ”で見る：短い対話形式で理解する
（１）ケース1：フォーム送信の“全部がJS”だと思ってしまう例
デザイナー：
「お問い合わせフォーム、送信したら自動返信メールが飛んで、管理シートにも保存できますよね？」
コーダー：
「送信や保存はJSだけではできないんですよ。サーバー側の処理になります」
デザイナー（心の声）：
「え…画面から入力しているのに？なんで？」
ここで起きているズレは、“画面で起きていること＝全部JSの範囲” と考えてしまう点。
コーダーからすると、フォーム送信後は「外の世界の処理」なのでサーバーの担当という当たり前の前提がありますが、デザイナーさんはその境界線が見えていないため“全部つながっているように見える”のです。
（２）ケース2：カウントダウンが“サーバー連携しないと動かない”と思ってしまう例
クライアント：
「締切までのカウントダウン、ページ内に表示できます？」
デザイナー：
「（こんな動的なもの、サーバー必要なのかな？）」
コーダー：
「大丈夫ですよ。これはJSだけでできます」
ここでは逆のズレが起きています。
「数字が動く＝外部とやり取りしている？」と誤解しやすいのですが、カウントダウンはブラウザ内で時間を計算するだけなのでJSで十分です。
（３）ケース3：“簡単そう”に見えるUIが、実は構造的に複雑な例
デザイナー：
「このポップアップ、真ん中に出るだけなのでサクッとできますよね？」
コーダー：
「PCとスマホで位置やスクロールの処理も変わるので、少し調整が必要かもです」
ポップアップはJSでできる範囲ですが、“できる”と“簡単”は別問題 という認識のズレが発生しています。
デザイナーさんは見た目ベースで判断し、コーダーは実装構造ベースで判断するため、このすれ違いがよく起こります。
（４）ケース4：“API連携＝JSだけでいける”と思ってしまう例
クライアント：
「このデータ、外部サービスから自動で取得できます？」
デザイナー：
「（JSで読み込めばいいのかな…？」
コーダー：
「外部サービスの仕様によりますが、サーバー経由が必要かもしれません」
外部データの取得は、
✅ JSで直接取得できるパターン
✅ サーバー経由でないと取得できないパターン
があり、デザイナー視点では見分けにくい部分です。
ここでズレが起きるのは当然で、専門知識の差ではなく、“役割の違いを知らされていないまま会話している”だけなのです。
（５）ケース5：アニメーションは“全部動画っぽいもの”と思いがちな例
デザイナー：
「このロゴ、スクロールしたらふわっと回転して縮んで…ってできます？」
コーダー：
「できます！JSとCSSの組み合わせでいけます」
デザイナー（心の声）：
「動画みたいだけど、コードでできるんだ…！」
アニメーションは“動画処理”と思われがちですが、実際にはブラウザ内の動きなのでほとんどJSで対応可能です。
ここはズレというより、“知らないだけで損している領域”といえます。
（６）ズレが起きるのは「デザイナーのせい」ではなく“構造が見えないから”
どの例も、
✅ デザイナーさんのスキル不足
✅ コーダーの説明不足
ではありません。
そもそも「ブラウザでできること」「サーバーが必要なこと」が見えない状態で話しているので、すれ違うのは当然なのです。
だからこそ、構造を知るだけで打ち合わせが一気にラクになります。
次は、このズレをなくし、技術判断をスムーズにするための「相談方法」と「聞き方のテンプレート」をお伝えします。
6. 受注前に迷ったらどう聞けばいい？技術判断をラクにする“相談テンプレート”
（１）デザイナーが“全部を判断する必要はない”という前提
まず大前提として、デザイナーさんがすべての技術判断を自力で行う必要はありません。
むしろ、「一部だけ判断できて、残りは相談できればOK」 というスタンスで十分です。
JSでできる範囲・できない範囲が少し見えるようになったとしても、案件ごとに仕様や外部サービスの都合で変わるポイントは必ず出てきます。
だからこそ、相談する力がプロとしての安心感につながります。
（２）相談のコツは「できるか？」ではなく「条件」を伝えること
デザイナーさんがよくやりがちな相談は、「これJSでできますか？」というシンプルな質問です。
これは悪くはないのですが、コーダーからすると“判断材料が足りない”状態になりがちです。
そこで、次のように“前提条件”を付けて伝えると、コーダーは一気に回答しやすくなります。
デザイナー：
「ユーザーがボタンを押したら、画面内だけで○○が動くイメージです。外部との連携は予定していません。これはJSでいけますか？」
このように、「画面内で完結するのか／外部と連携するのか」という情報を添えるだけで、コミュニケーションがスムーズになります。
（３）デザイナーとコーダーの会話テンプレート：そのまま使える形で紹介
ここからは、実務でそのまま使える相談テンプレートをお渡しします。
このとおりに話すだけで技術コミュニケーションの精度が上がります。
✅ テンプレート1：
できる範囲を確認したいとき
「クライアントから○○の要望がありました。画面内の動きで完結するイメージですが、JSだけで実装できそうですか？」
✅ テンプレート2：
実装の難易度を知りたいとき
「見た目としてはシンプルですが、実装の難易度や気をつける点があれば教えてください。」
✅ テンプレート3：
外部連携が絡むか判断したいとき
「この動きはブラウザの中で完結しますか？それともサーバーや外部サービスとの連携が必要になりそうですか？」
✅ テンプレート4：
納期や工数への影響を確認したいとき
「この機能を入れる場合、工数や納期にどれくらい影響しますか？クライアントに説明したいので大まかな目安だけ知りたいです。」
✅ テンプレート5：
複数の案のどれが最適か知りたいとき
「デザインとしてはA案とB案があります。実装しやすさや運用のしやすさも含めて、どちらが現実的だと思いますか？」
（４）相談するときは“恥ずかしさ”より“情報共有”が圧倒的に大事
多くのデザイナーさんが相談をためらう理由は、「こんな基本的なことを聞いてもいいのかな…」という気持ちです。
でもコーダー側の本音はむしろ「早めに共有してくれたほうが助かる」 です。
✅ 要件のズレが少なくなる
✅ 不必要な工数が減る
✅ 無理な仕様を事前に避けられる
✅ 代替案を一緒に考えられる
相談が早ければ早いほど、双方が楽になります。
（５）専属の相談パートナーがいると、打ち合わせの安心感が変わる
相談テンプレートはとても有効ですが、さらに理想的なのは「すぐ相談できるコーダーの存在」です。
これがいるだけで、
✅ 打ち合わせ中の判断が怖くなくなる
✅ 仕様の見落としがなくなる
✅ 見積もりの精度が上がる
✅ “技術に強いデザイナー”として信頼される
という、デザイナーさんとしての立ち位置が一段引き上がります。
もちろん、この記事を読んで仕組みを理解するだけでも十分動けるようになりますが、“迷ったら相談できる”という状況は、想像以上に心の負担を軽くしてくれます。
（６）相談する力は“技術力”と同じくらい重要なスキル
JSの理解が深まると、不思議と相談しやすくなります。
なぜなら、「ここまではブラウザ内の動き」「ここから先は外部処理」という境界線が見えるようになるからです。
境界がわかると、“どこで迷っているのか”を正確に言語化できるデザイナーになり、コーダーとの連携力が抜群に上がります。
次は、この記事全体を振り返りつつ、「今日からどう動けば技術判断に強いデザイナーになれるか」をシンプルにまとめてお伝えします。
7. まとめ：“判断できるデザイナー”になるために
（１）「ブラウザ内でできること」と「外部とつながる必要があること」を区別できれば十分
この記事で一番大切にしてほしいのは、JavaScriptはブラウザの中で動くというシンプルな前提です。
ここを理解できると、「これはJSでできそう」「これは外部の仕組みが必要そう」という判断が自然とできるようになります。
最初から難しいプログラミング知識を覚える必要はありません。
“境界線”が見えるだけで、技術判断の不安は一気に軽くなります。
（２）クライアントとの打ち合わせが怖くなくなる未来
JSの仕組みを少し理解できるだけで、打ち合わせ中にこんな変化が起きます。
✅ 要望を聞いた瞬間に、ある程度の実現性をイメージできる
✅ コーダーに丸投げではなく、前提条件を添えて相談できる
✅ 見積もりのブレが減り、クライアントとの信頼が上がる
“技術に詳しいデザイナー”という印象は、ほんの小さな知識の積み重ねで作られます。
（３）コーダーとの連携がスムーズになり、お互いの負担が減る
デザイナーさんがJSの範囲を理解できるようになると、コーダーとの会話のズレが驚くほど減ります。
✅ 画面内で完結する動きなのか
✅ 外部と通信する必要があるのか
✅ 代替案が必要なのか
こういったポイントを共有できるだけで、制作フローが軽やかになり、余計な工数や手戻りが大幅に減ります。
（４）相談力という“もう1つの技術スキル”を大切にしてほしい
技術に強いデザイナー＝全部できる人、ではありません。
技術に強いデザイナー＝どこで迷っているかを言語化し、適切に相談できる人です。
相談力が身につくと、
✅ 受注前の不安
✅ 技術的な曖昧さ
✅ クライアントとの説明責任
これらが自然と軽くなります。
そして何より、「ひとりで抱え込まなくていい」という安心感が生まれます。
（５）今日からできる小さな一歩
技術に強いデザイナーになるために、特別な勉強は必要ありません。
まずはこの記事で出てきた考え方を、次の案件から少しずつ実践してみてください。
✅ 画面内で完結するかどうかを考えてみる
✅ 迷ったらコーダーに前提条件付きで相談する
✅ 外部と連携しそうなら早めに共有する
この習慣が身につくだけで、あなたの技術判断は確実に強くなります。
（６）あなたの制作がもっと“安心して進められる”未来へ
JavaScriptは難しそうに見えて、デザイナーさんが知るべきポイントは実はとてもシンプルです。
境界線を知り、相談力を身につければ、案件はもっとスムーズに、もっと安心して進められるようになります。
この記事が、その第一歩になれば嬉しいです。
