フレーミング効果とは?新人エンジニア向けに「伝え方で判断が変わる心理」をUI/UX・報告・提案に活かす方法を解説
こんにちは。ゆうせいです。
今回は、行動経済学や心理学でよく出てくる「フレーミング効果」について、新人エンジニア向けに解説します。
フレーミング効果とは、簡単に言うと「同じ内容でも、伝え方や見せ方によって、人の受け取り方や判断が変わる心理効果」です。
たとえば、次の2つを見てください。
成功率90% 失敗率10%
意味としてはかなり近いですよね。
しかし、「成功率90%」と言われると安心しやすく、「失敗率10%」と言われると少し不安になりやすいです。
同じ事実でも、どの角度から伝えるかによって印象が変わります。
新人エンジニアにとって、フレーミング効果はかなり実務で役立ちます。
UI/UX設計、エラーメッセージ、進捗報告、障害報告、コードレビュー、顧客説明、資料作成など、あらゆる場面で「どう伝えるか」が重要になるからです。
フレーミング効果とは何か
フレーミング効果とは、人が情報を判断するとき、内容そのものだけでなく「どのような枠組みで提示されたか」に影響される現象です。
フレームとは、額縁や枠のことです。
同じ写真でも、明るい白い額縁に入れるのと、重厚な黒い額縁に入れるのでは、印象が変わりますよね。
情報も同じです。
同じデータでも、どの言葉で表現するか、どの順番で見せるか、何と比較するかによって、相手の感じ方が変わります。
| 同じ内容 | 前向きな見せ方 | 不安を感じやすい見せ方 |
|---|---|---|
| 10人中9人が成功 | 成功率90% | 失敗率10% |
| 作業の7割が完了 | 70%完了しています | まだ30%残っています |
| バグが3件ある | 重大バグは0件、軽微な修正が3件です | まだバグが3件あります |
| レビューコメントが10件ある | 改善ポイントが10件明確になりました | 10件も指摘されました |
ポイントは、事実を変えているわけではない点です。
フレーミング効果は、事実の「切り取り方」や「表現の仕方」によって判断が変わる、という話です。
新人エンジニア向けにたとえると
エンジニア向けにたとえるなら、フレーミング効果は「同じレスポンスデータでも、表示画面によってユーザーの印象が変わる」ようなものです。
たとえば、APIから次のような結果が返ってきたとします。
全体:100件 完了:80件 未完了:20件
画面では、次のように表現できます。
80件完了しました
または、次のようにも表現できます。
20件が未完了です
どちらも同じデータをもとにしています。
しかし、前者は進んでいる印象を与え、後者は残り作業に注意を向けさせます。
つまり、フレーミングは「どこに注目してもらうか」を決める設計でもあります。
なぜフレーミング効果が起きるのか
人間は、すべての情報を完全に中立に処理しているわけではありません。
情報が多い中で、すばやく判断する必要があります。
そのため、言葉の印象、比較対象、最初に見た情報、損得の見せ方に影響されます。
たとえば、次の2つの説明を比べてみましょう。
この変更により、表示速度が20%改善します。 この変更をしない場合、表示速度改善の機会を失います。
どちらも改善の話です。
しかし、1つ目は「得られる利益」に注目しています。
2つ目は「失う機会」に注目しています。
人は、得よりも損に強く反応しやすい傾向があります。
そのため、後者のほうが行動を促しやすい場面もあります。
ただし、不安をあおりすぎると信頼を失います。
伝え方は力です。だからこそ丁寧に使いましょう!
フレーミング効果とプロスペクト理論の関係
フレーミング効果は、プロスペクト理論と関係が深いです。
プロスペクト理論とは、人は利益と損失を同じようには感じず、特に損失に強く反応しやすいという考え方です。
フレーミング効果では、同じ内容でも「利益として見せるか」「損失として見せるか」で判断が変わります。
| 表現 | 注目する点 | 受け取りやすい印象 |
|---|---|---|
| 成功率90% | 成功 | 安心、前向き |
| 失敗率10% | 失敗 | 不安、慎重 |
| 80%完了 | 進捗 | 順調 |
| 20%未完了 | 残作業 | 注意が必要 |
| 年間12時間削減できます | 得られる効果 | 導入価値がある |
| 年間12時間を失い続けます | 放置する損失 | 改善しないリスクを感じる |
利益フレームは、前向きな印象を作りやすいです。
損失フレームは、危機感や行動の必要性を伝えやすいです。
どちらが正しいというより、目的に応じて使い分けることが大切です。
UI/UXでの応用1:ボタンの文言
フレーミング効果は、UIのボタン文言に強く関係します。
UIとは、User Interfaceの略で、ユーザーが操作する画面やボタンなどの部分です。
同じ操作でも、ボタン名によってユーザーの受け取り方が変わります。
| 分かりにくいボタン | 分かりやすいボタン | 理由 |
|---|---|---|
| 実行 | 保存する | 何が起きるか分かる |
| 処理 | 申請を送信する | 操作結果が明確 |
| OK | 削除する | 重要操作の意味が伝わる |
| 次へ | 入力内容を確認する | 次の画面の目的が分かる |
ユーザーは、ボタンを押す前に「押したら何が起きるのか」を知りたいです。
ボタン名が曖昧だと、不安になります。
新人エンジニアは、ボタンを作るときに「ユーザーが結果を想像できる文言か?」を確認してください。
ボタン名で迷わせるな!
UI/UXでの応用2:エラーメッセージ
エラーメッセージでも、フレーミング効果は大きく働きます。
悪いエラーメッセージは、ユーザーを責めているように見えます。
良いエラーメッセージは、ユーザーを次の行動へ案内します。
| 悪いフレーミング | 良いフレーミング | 違い |
|---|---|---|
| 入力値が不正です | メールアドレスを入力してください | 直す場所が分かる |
| パスワードが間違っています | パスワードは8文字以上で入力してください | 条件が分かる |
| 処理に失敗しました | 通信に失敗しました。時間をおいて再度お試しください | 次の行動が分かる |
| 権限がありません | この操作には管理者権限が必要です | 理由が分かる |
同じエラーでも、ユーザーに与える印象は変わります。
「あなたが悪い」と見える表現ではなく、「次にこうすれば進めます」と伝える表現にしましょう。
エラー文は、ユーザーを止める壁ではありません。
次へ進むための案内板です。
UI/UXでの応用3:確認画面
削除、公開、購入、申請などの重要操作では、フレーミングがとても重要です。
たとえば、削除確認で次のように表示されたらどうでしょうか。
本当に実行しますか?
何が起きるのか分かりにくいですよね。
改善するなら、次のようにします。
「営業資料_2026.pdf」を削除します。 削除後30日以内であればゴミ箱から復元できます。
この表現なら、削除対象と復元可否が分かります。
| 確認画面で伝えるべきこと | 例 |
|---|---|
| 何をするのか | ファイルを削除します |
| 対象は何か | 営業資料_2026.pdf |
| 取り消せるか | 30日以内なら復元できます |
| 次に何が起きるか | ゴミ箱へ移動します |
確認画面は、不安をあおる場所ではありません。
ユーザーが納得して判断できるようにする場所です。
UI/UXでの応用4:進捗表示
進捗表示でも、フレーミング効果が働きます。
たとえば、同じ状態でも次の2つでは印象が違います。
80%完了しました 残り20%です
80%完了は、順調さを感じさせます。
残り20%は、残作業に注意を向けさせます。
どちらが良いかは、場面によります。
| 場面 | 向いている表現 | 理由 |
|---|---|---|
| ユーザー登録 | あと1ステップで完了です | 最後まで進めやすい |
| プロジェクト進捗 | 全10件中7件完了、残り3件です | 進捗と残作業の両方が分かる |
| 障害対応 | 影響範囲は確認済み、復旧作業中です | 状況と次の動きが伝わる |
| 研修課題 | 5問中4問完了、あと1問です | 達成感と残りが分かる |
進捗表示では、ユーザーや関係者が「安心したい」のか、「残作業を把握したい」のかを考えましょう。
報告での応用1:進捗報告
新人エンジニアが仕事で最初につまずきやすいのが、進捗報告です。
同じ状況でも、伝え方で相手の受け取り方が変わります。
たとえば、次の報告を見てください。
まだ終わっていません。
この報告だけだと、相手は不安になります。
何が終わっていないのか、どこまで進んでいるのか、いつ終わるのかが分からないからです。
改善例です。
ログイン画面の実装は完了しています。 現在は未入力時のエラーメッセージ表示を修正中です。 残作業はテスト2件で、本日17時までに確認予定です。
こちらのほうが、状況を判断しやすいですよね。
| 不安になりやすい報告 | 判断しやすい報告 |
|---|---|
| 遅れています | 実装は完了し、テストで1件エラーが出ています |
| まだ確認中です | 原因候補を3つ確認し、現在2つ目を検証中です |
| バグがあります | 重大度高は0件、表示崩れが2件残っています |
| たぶん大丈夫です | 正常系3件、異常系2件のテストは完了しています |
報告では、相手が判断できる情報を出してください。
「頑張っています」だけでは足りません。
事実、残作業、見通しを伝えましょう!
報告での応用2:障害報告
障害報告では、フレーミングが特に重要です。
不安をあおりすぎてもいけません。
かといって、問題を小さく見せすぎてもいけません。
大切なのは、正確で、判断しやすく、次の行動が分かる報告です。
悪い例です。
大変です。システムでエラーが出ています。
この報告では、相手は何をすればよいか分かりません。
改善例です。
現在、注文登録画面で500エラーが発生しています。 影響範囲は注文登録機能のみで、商品閲覧とログインは利用可能です。 発生時刻は10:15頃です。 直近のリリース差分とアプリケーションログを確認中です。 15分後に一次調査結果を共有します。
かなり判断しやすくなりました。
| 障害報告で伝える情報 | 内容 |
|---|---|
| 何が起きているか | 注文登録画面で500エラー |
| 影響範囲 | 注文登録のみ、ログインは利用可能 |
| 発生時刻 | 10:15頃 |
| 現在の対応 | ログとリリース差分を確認中 |
| 次の報告予定 | 15分後に共有 |
障害報告では、落ち着いて伝えるフレームが大切です。
焦りをそのまま送るな。状況を整理して送れ!
コードレビューでの応用
コードレビューでも、フレーミング効果は大きく関係します。
同じ指摘でも、言い方によって相手の受け取り方が変わります。
| きつく見える表現 | 受け取りやすい表現 |
|---|---|
| この書き方はダメです | この処理はService側に移すと責務が分かりやすくなりそうです |
| なぜこうしたんですか? | 実装意図を確認したいです。どのような理由でこの方法にしましたか? |
| 前にも言いましたよね | 前回の内容とつなげて、今回も同じ観点で確認しましょう |
| 読みにくいです | 変数名を具体的にすると、処理の目的が伝わりやすくなります |
レビューは、相手を責める場ではありません。
コードを良くするための対話です。
新人エンジニアがレビューを受ける側の場合も、フレーミングを意識すると楽になります。
10件も指摘された
↓
改善ポイントが10件明確になった
このように受け止め方を変えると、行動しやすくなります。
もちろん、レビューの言い方が厳しすぎる場合は、チームとして改善が必要です。
顧客説明での応用
顧客説明でも、フレーミング効果は重要です。
たとえば、システム導入を提案するとき、単に機能を説明するだけでは伝わりません。
顧客は「導入すると何が良くなるのか」「導入しないと何が続くのか」を知りたいのです。
| 機能中心の説明 | 価値が伝わる説明 |
|---|---|
| 承認ワークフロー機能があります | 申請状況が見える化され、確認漏れを減らせます |
| CSV出力できます | 月次集計に必要なデータをすぐ取り出せます |
| 通知機能があります | 対応漏れに早く気づけます |
| 権限管理できます | 担当者ごとに見せる情報を制御できます |
顧客は、機能そのものではなく、業務がどう変わるかを知りたいです。
機能を語るな。価値を語れ!
ただし、メリットだけを強調しすぎるのも危険です。
導入時の負担、移行リスク、運用上の注意も正直に伝えましょう。
学習での応用
フレーミング効果は、新人エンジニア自身の学習にも使えます。
学習中は、エラー、レビュー指摘、理解不足に何度も出会います。
そのたびに「自分はダメだ」と受け止めると、学習がつらくなります。
少しフレーミングを変えてみましょう。
| つらくなるフレーム | 成長につながるフレーム |
|---|---|
| エラーが出た | 原因を教えてくれるログが出た |
| レビューで指摘された | 実務の考え方を学ぶ材料が増えた |
| 質問してしまった | 詰まりを解消して前に進めた |
| 理解が遅い | 今は基礎を作っている段階 |
| 作り直しになった | より良い設計を学べた |
無理にポジティブになる必要はありません。
ただし、自分を責めるフレームばかり使うと、行動が止まります。
学習しやすいフレームに変えて、次の一手を決めましょう。
フレーミング効果を使うときの注意点
フレーミング効果は便利ですが、使い方を間違えると危険です。
事実を隠したり、都合の良い部分だけ見せたりすると、信頼を失います。
| 悪い使い方 | 問題点 |
|---|---|
| 成功率だけを見せてリスクを隠す | 判断に必要な情報が不足する |
| 不安をあおって購入させる | ユーザーの信頼を失う |
| 残課題を小さく見せる | 後で大きな問題になる |
| 都合の良い数字だけ使う | 説明の透明性が下がる |
| 事実より印象操作を優先する | 長期的な信用を失う |
良いフレーミングは、相手が正しく判断するための助けです。
悪いフレーミングは、相手を誤った判断へ誘導する操作です。
伝え方を工夫することと、事実をねじ曲げることは違います。
誠実に使いましょう。
良いフレーミングを作る手順
新人エンジニアがフレーミングを実務で使うなら、次の手順がおすすめです。
| 手順 | 内容 |
|---|---|
| 1 | まず事実を整理する |
| 2 | 相手が何を判断したいか考える |
| 3 | 不安を減らす情報を入れる |
| 4 | 次の行動が分かる表現にする |
| 5 | リスクや残課題も隠さない |
たとえば、進捗報告なら次の型が使えます。
完了したこと: ログイン画面の表示と入力フォームの実装は完了しました。 残っていること: 未入力時のエラーメッセージ表示を修正中です。 リスク: エラーメッセージの表示位置でCSS調整が必要になる可能性があります。 次の行動: 本日17時までに修正し、テスト結果を共有します。
この型なら、相手は状況を理解しやすくなります。
新人エンジニアが明日から使えるチェックリスト
報告、画面文言、エラーメッセージを書くときは、次のチェックリストを使ってみてください。
事実を正確に書いているか 相手が判断したいことに答えているか 不安だけをあおっていないか 良い点だけでなくリスクも伝えているか 次に何をすればよいか分かるか 専門用語を使いすぎていないか ボタン名やメッセージは具体的か 数字は文脈と一緒に伝えているか 相手を責める表現になっていないか 誠実な伝え方になっているか
特に大切なのは、「次に何をすればよいか分かるか」です。
良いフレーミングは、相手の次の行動を助けます。
フレーミング効果のメリット
フレーミング効果を理解すると、次のメリットがあります。
| メリット | 説明 |
|---|---|
| 報告が分かりやすくなる | 相手が状況を判断しやすくなる |
| UI/UXが改善する | ユーザーが迷わず操作しやすくなる |
| エラー文が親切になる | ユーザーが次の行動を取りやすくなる |
| レビューが建設的になる | 相手が受け取りやすい指摘ができる |
| 顧客説明が伝わりやすくなる | 機能ではなく価値を伝えられる |
エンジニアは、コードを書く力だけでなく、伝える力も必要です。
フレーミング効果を知ると、伝える力が少しずつ鍛えられます。
フレーミング効果のデメリットと注意点
一方で、注意点もあります。
| 注意点 | 説明 |
|---|---|
| 印象操作になりやすい | 都合の良い面だけ見せると信頼を失う |
| リスクを隠すと危険 | 正しい判断ができなくなる |
| 相手によって受け取り方が違う | 同じ表現でも人によって感じ方が変わる |
| 数字だけでは伝わらない | 文脈や影響範囲も必要 |
| 短期的な説得に偏ると危険 | 長期的な信頼を損なう可能性がある |
フレーミング効果は、相手を動かすためだけに使うものではありません。
相手が正しく理解し、納得して判断できるように使うものです。
まとめ
フレーミング効果とは、同じ内容でも、伝え方や見せ方によって人の受け取り方や判断が変わる心理効果です。
新人エンジニアにとっては、UI/UX、エラーメッセージ、進捗報告、障害報告、コードレビュー、顧客説明に役立つ実務的な考え方です。
| 項目 | 内容 |
|---|---|
| 効果名 | フレーミング効果 |
| 意味 | 同じ情報でも、見せ方や伝え方で判断が変わる |
| 代表例 | 成功率90%と失敗率10%では印象が変わる |
| 実務での活用 | UI文言、エラー文、報告、レビュー、顧客説明 |
| 注意点 | 事実を隠さず、相手の判断を助けるために使う |
一言でまとめるなら、フレーミング効果は「情報は中身だけでなく、伝え方でも意味が変わる」という考え方です。
新人エンジニアは、画面や報告で次の流れを意識してください。
事実を整理する ↓ 相手が何を判断したいか考える ↓ 分かりやすい言葉にする ↓ 不安を減らす情報を加える ↓ 次の行動を示す ↓ リスクや残課題も正直に伝える
フレーミングは、うまく使えば人を助けます。
雑に使えば、人を誤解させます。
だから、誠実に使いましょう。
今後の学習では、フレーミング効果に加えて、プロスペクト理論、損失回避、ナッジ、認知バイアス、認知負荷、UI/UX心理学、ユーザビリティテスト、ビジネスコミュニケーションを順番に学ぶとよいです。まずは明日の進捗報告で、「まだ終わっていません」ではなく、「完了したこと」「残っていること」「次の行動」を分けて伝えるところから始めてみましょう!
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール


