ソフトウェア開発者である私がアプリ開発時に考えているデザインのことのまとめです(2025 年版)。
「Design」は「設計」という意味だと思いますが、日本語で「デザイン」というとグラフィックデザインという印象があり、見た目に関する話を意味することが多いと思います。
今回のお話もアプリケーションの見た目に関するお話になります。
「アプリケーションのデザイン」とは、ビジネスの要件があり、そのビジネスのためにデータ等を人の認知を通してどのように見せて体験してもらうのか、と考えています。
良いデザインとは
私は「融けるデザイン」という本が好きなのですが、この本の言葉を借りると「自己帰属感の高い」ものが良いデザインと捉えることができます。
例えば PC のキーボードとマウス、初心者を除けば多くの人は手元を見なくても自由自在に「自分の体の一部」かのように使いこなせるのはないでしょうか。これは非常に高い自己帰属感です。ここには書きませんが「融けるデザイン」では、実験を通して自己帰属感の確認をしています。
鉄道会社か何かのスタッフの映像だったと思いますが、古めかしい質素な UI を高速に打鍵して処理を進めている映像を見たことがあります。私は内容を知らないので正確な評価はできませんが、高い生産性が出せているのであればそれは良いデザインなのでしょう。
何が言いたいかというと、「かっこいい」とか「クール」とかと「良いデザイン」は必ずしも一致するものではないということです。両立することもあるかもしれませんし、両立しないこともあるかもしれません。そもそも何が「かっこいい」かは人によって異なり、極端な話で園児と老人とでは「かっこよさ」は異なるでしょう。
逆に、「今が良ければ変える必要はない」という話でもなく、経営側の目指すものがあってシステムを変えようとしているのかもしれません。その場合、その業務単独の話ではなくもっと広い視点での最適を目指しています。
前述したように、デザインより先に「ビジネス」があるので、ビジネスを後押しできなければクールであっても意味がないし、今が良くても先々の変化・成長を見据えて変化させようとしているのかもしれません。何のためのデザインなのかが大事です。
UI デザインの歴史
昔の Windows のアプリや、iPhone においても iOS7 以前まではスキューモフィズムのデザインが主流でした。
Windows8(2012 年)、iOS7(2013 年)からフラットデザインが登場。Android5(2014 年）からマテリアルデザインが登場し、現在では多くのアプリケーションで採用されています。
スキューモフィズムは現実世界を模したデザインであるため、人々にとって非常に認知しやすいデザインです。ボタンがボタンだと一目でわかります。ただし、デメリットとして作成に非常に手間がかかります。また、現実にあるものであれば良いのですが、デジタルの世界では現実にない抽象度の高いものもありますので表現が難しいことがあるはずです。
フラットデザインが登場し、デメリットは解消されたものの、今度はボタンがボタンだと判別つかないデザインも登場してきました。フラットデザインに近いものの、影をつけることで前後関係を表現し、高い抽象度も表現可能なまま認知しやすいデザインへと変わってきました。
この話で重要なのは「認知」です。
時代が変われば認知も変わります。デジタルが身近になかった時代はリアルな質感が認知しやすかったし、デジタルが身近な最近はリアルな質感はなくても認知できます。
今まで見たこともないようなデザインは認知できないかもしれません。そういった挑戦はプロのデザイナーの領分であり、開発側の人間としては挑戦はせずに「よくあるデザイン」を理解して使うべきだと考えています。
カラーリング
適当に色を決めない
色はなんらかのカラーシステムから選んだ方が無難です。
もちろん、コーポレートカラーなど決まっている色はあると思いますが、それ以外は適当に色を選ぶのではなく、例えば以下のような tailwondcss の Colors から色を選んだほうが良いです。
引用：https://tailwindcss.com/docs/colors
また、複数の色を選ぶ場合、色のトーンは統一した方が良いです。
例えば 500 の Red を使うことにしたのであれば、Yellow や Green も 500 を選びます。
以下は 500 の色を選んでいるなかで 1 個だけ 400 の緑が混ざっています。
微妙な差なのでわかりづらいかもしれませんが、500 で統一した方が全体として統一感がないでしょうか。
色の使い所を決める
ベースカラー、アクセントカラー、サブカラーなどを決めます。
Material Design3 だと Primary / Secondary / Tertiary ですが、ここでは細かい議論はなしで、メインで使い回す大事な色を２〜3 色決めるということです。
アプリにおいては背景色やボタンの色などですね。アクセントカラーとサブカラーは補色の関係であることもあります。
使用する割合は男性のスーツ姿のイメージが良いかもしれません。
ジャケットがベースカラー、ネクタイがアクセントカラー、シャツがサブカラーです。
アプリにおいては以下のような色が必要になります。
- 背景色
- 文字色
- ボタンなど（通常、ホバー、押下、フォーカス、非活性）
- タブ、セグメントボタンなど（選択、非選択）
- 入力フォーム（通常、フォーカス、エラー、非活性、プレースホルダーの色）
- などなど
ダークテーマ対応するならホワイト・ダークの 2 系統の色を決める必要があります。
背景が白、文字が黒というのがベーシックだと思いますが、真っ白（0xffffff）と真っ黒（0x000000）ではなく若干くすんだ白、グレーがかった黒の方が目に優しくオシャレ感がでます。
例えば先ほど tailwindcss の画面でも文字色は真っ白ではなく少しグレーになってます。
（下記画像の Color の値が文字色で、RGB 値にすると「#d1d5dc」になります）
ここではどんな時にどんな色を採用すべきかという議論はしません。多くの場合、コーポレートカラーなど従うべき色があるため一概に言えないためです。また国が変われば色のイメージも変わってしまいます。例えば「ピンク」というと日本ではセクシーなニュアンスも込められることがありますが、それは日本だけです。
コントラストに配慮する
先ほどの画像は Chrome の開発者機能の表示ですが「13.67」という数字がありました。
これは文字と背景のコントラスト比です。
W3C の Web アクセシビリティのガイドラインに、最低でも 4.5:1 以上のコントラスト比となることを推奨されています。
引用：https://waic.jp/translations/WCAG21/#contrast-minimum
コントラスト比が 4.5 以上、7.0 以上となる色がどんな色になるのかは、Chrome の開発者機能でチェック対象の要素の Color スタイルから確認ができます。
コントラスがはっきりしていれば、色覚特性がある方にもわかりやすい色使いになります。
視覚特性も Chrome の開発者機能でエミュレート可能です。
例えば、ここで「Protanopia(no red)」を選択すると、先ほどの tailwindcss の画面は以下のようになります。
視覚特性への配慮も大切ですが、コントラスト比がはっきりしていればどのような場合であっても見やすくなると思いますので、まずはコントラスト比を気をつけるべきです。
タイポグラフィ
文字のことですね。
文字にはざっくり、「セリフ or サンセリフ」「モノスペース or プロポーショナル」があります。
セリフとサンセリフ
セリフ / サンセリフは、ざっくりは明朝体かゴシック体かということです。
歴史的には明朝体から始まり、デザイン性や低解像度での視認性の高さからゴシック体も広まり、最近ではデジタルではゴシック体を見かけることの方が多いと思います。印刷物では明朝体の方が多いかもしれません。
モノスペースとプロポーショナル
モノスペースは等幅と言った方がわかりやすいかと思います。プロポーショナルは「MS P ゴシック」の「P」部分のことですが（最近の若い子は「MS P ゴシック」を知らないかもしれませんが）、文字ごとに横幅が調整されたものです。
下の画像でいうと、上がプロポーショナルで下が等幅です。わかりやすい部分として「I」の横幅が違うのがわかると思います。
多くの場合はプロポーショナルフォントを使うでしょう。
ただし、テキストだけで数字の表組みを表示するような場合は等幅フォントを使わないと位置がズレて読みづらくなるかもしれません。
しかし、日本語のフォントはプロポーショナルでも等幅で表示されます。横幅が変わるのは英数字のみです。
私はプロのデザイナーではないので偉そうに言うことはできませんが、ポスターなどのデザインでは 1 文字 1 文字の文字間（カーニング）を手作業で細かく調整しています。そこまでの調整は普通の人にはできませんが CSS でも自動カーニングの機能があります。詳しくは以下の ICS MEDIA さんの記事を参照してください。
また、横の幅だけでなく縦の幅（line-height）もデザインでは重要な設定です。美しさは余白から生まれると言っても過言ではないです。
今この記事を書いている Zenn の記事編集画面では line-height は 1.8 です（ちなみに閲覧画面の場合は 1.9）。letter-spacing も設定されており、Zenn の美しさと心地良さはこういった細かな設定からきているのかもしれません。
適切なフォントを設定する
以下はすべてゴシックですが、さまざまなフォントがあります。
プラットフォームごとに使えるフォントは違うため適切に選択する必要があります。
Web であれば ICS MEDIA さんが適切な font-family の設定を検証してくれています。
スマホアプリの場合、font-family のように「優先度の高い使用可能なフォントを使う」という便利な機能はないのでより注意深く対応する必要があります。使えるフォントがない場合はシステムフォントが採用されるので何も表示されないというようなことはないですが。
iOS では SF Pro（San Francisco）やヒラギノ、Android では Noto Sans や Roboto が使えることが多いです。iOS で Noto Sans を使う場合、アプリ内にフォントファイルを埋め込んで使うことになりますが、日本語（Noto Sans JP）も含めてしまうとファイルサイズが大きくなるため、使うウェイトを絞ったり必要な文字だけに絞るなどの対応を検討した方が良いです。
また、デザイナーから Figma 等でデザインを受け取ってアプリ開発をすることも多いかと思いますが、基本的には 1 個のフォント、例えばヒラギノなどでデザインが作られます。ヒラギノで作られている場合、Android ではヒラギノは表示できないので、何のフォントを使うべきか確認する必要があります。フォントが変わると文字幅や改行位置が変わり、デザイン崩れや文字切れの原因になるため注意が必要です。
日本語の改行位置も気になることもあると思います。英語であれば単語間に空白があるため自動で良い感じに改行してくれますが日本語の場合は単語の途中で改行されてしまいます。そういった問題に対応しているライブラリもあるため必要であれば導入を検討してみても良いかもしれません。
レイアウト
余白を作る
（デザイン苦手な）エンジニアが画面を作ったときに綺麗に見えないのは余白が原因です。それぐらい余白は重要です。
CSS フレームワークや簡単に Web 画面を作れる仕組みを使った時になんだか綺麗に見えるのは余白が設定されているからです。以下は Material Design3 の Lists の Spec です。多くの場合、余白は 4px または 8px の倍数になってます。なぜそうなっているかは、「有名アプリがそうしてた」「1.5 倍、2 倍、3 倍などの DPI の考慮が計算しやすい」「ディスプレイ解像度の規格が 8 で割り切れる」など理由っぽいものは思いつきますが、「なんとなく美しいから」以外の理由はよくわからないです。
引用：https://m3.material.io/components/lists/specs
試しに先ほどの Material Design3 に設定されている Padding の設定を削除すると、これぐらい見た目が変わります。こういった設定が事前にされているので、なんらかのフレームワークを使うと綺麗に見えるようになっています。
詳しくない方のために解説すると、CSS の世界では Padding と Margin という余白に関する設定があります。その関係は以下のようなものです。
サイズを揃える
ボタンやタグ / ラベルなどが並ぶ場合、できれば横幅を揃えた方が綺麗です。
パターンを決める
多くのアプリではトップ画面、一覧画面、詳細画面というような形で画面が分類できると思いますが、画面レイアウトのパターンは統一した方が良いです。
例えば、部署の一覧画面、社員の一覧画面でそれぞれ表示する項目は異なるとは思いますが、画面配置は似たような形にすると思います。画面パターンを決め、全体として一貫性のある画面レイアウトにしておくとユーザーもわかりやすいだけでなく、開発もやりやすくなりますし、ステークホルダーとの要件決めでも無駄な議論が減ります。
情報の構造を考慮する
情報の構造を考慮した意味のある位置関係、画面遷移を考える必要があります。
例えば、サイドメニューとヘッダー、メインコンテンツ、フッターの関係について考えます。
ログインした人がいて（ヘッダー）、その人が実行可能なメニューがあり（サイドメニュー）、選んだコンテンツが表示されます（メインコンテンツ）。
下記図では左側はそのような関係性が表現できていますが、右側はそうなっていません。「言語化できないけど違和感がある」というような場合、情報の構造どおりのレイアウトになっていないのかもしれません。
情報には上下の親子関係、並列の兄弟の関係などあります。そういった情報の関係性や意味のまとまりを余白で表現することで視覚的にもわかりやすくなります。
レスポンシブを考える
要件にあわせたサイズを考慮します。
デスクトップのシェア率や導入先の環境を考慮して基準となる画面サイズを決めます。スマホの場合は iPhone SE を基準にすることが多いです（もう iPhone SE 第一世代の考慮は不要なことが多いと思いますが、第一世代とそれ以降とで解像度が異なるので注意です）。
レスポンシブの考慮で困りやすいのは表と文字切れです。
表での悩みを減らす簡単な対応はカード形式にすることです。
文字の横幅が足りなかった時の対応も考慮が必要です。
折り返すのか、省略表示をするのか、横幅に合わせてフィットさせるのか、方針を決める必要があります。
省略表示をした場合、PC であればマウスオーバーで省略された内容を表示することが可能ですがスマホでは不可能なので注意が必要です。またフィットさせる場合、何も考えずにフィットさせると横幅が余った場合に逆に拡大表示になるので注意です（例：スマホは自然だけど iPad で表示すると拡大表示になる）。
性能を考える
アプリでは多くの画面で、表示項目を Web API を通じて取得して表示します。表示対象が現状のシステム設計にとって無理のない内容となっているか気にする必要があります。場合によってはデータの都合により DB に複雑なクエリを投げないと取得できないかもしれません。要件として許されるのならば、そういった項目は一覧画面では表示せずに、見る頻度の少ない詳細画面でだけ表示するなど、画面構成を見直した方が良いかもしれません。
また表示するデータ量が大量な場合、表示性能に問題がでるかもしれません。例えば Table タグの場合、すべての行を考慮した上で列幅を調整するため、行数が多いと性能問題がでる可能性があります。ただ、最近では多くのフレームワーク、プラットフォームで表示を仮想化することができるので適切に実装していれば問題は起きづらくはなっています。
微妙な位置の調整に悩んだら
黄金比や白銀比の値を使って位置を調整してみると良いかもしれません。
以下は個人的に作ったアプリの画面ですが、黄金螺旋を乗せるとこんな感じでした。何も考えずに作った画面でしたが、「がめんをタップしてください」の高さ方向は良い感じにも見えますね。横方向についてはもう少し中央寄りの方が美しかったかもしれません。
画像
画像には多くの画像フォーマットがあります。適材適所で使うべきです。
| フォーマット | 解説 |
|---|---|
| AVIF | めちゃ軽くて綺麗。エンコードに時間がかかるのとフォールバックが必要なことがあります。 |
| WebP | AVIF の次の選択肢。最近はだいたい使えます。 |
| JPEG | 上記が使えない場合の選択肢。 |
| PNG | 透過が使いたい場合や幾何学模様などシャープな画像など。写真で PNG を使うと重たいので避けたい。 |
| GIF | GIF アニメを使いたい場合。256 色しか使えないので写真のようなものには不向き。 |
| SVG | ベクター形式のため拡大縮小しても綺麗。アイコンに使うことが多い。 |
ICS MEDIA さんに詳しい記事があります。
個人的には JPEG の仕組みを初めて学び、フーリエ変換と人の特性を考えた仕組みに感銘を覚えました。JPEG 以外にもさまざまなメディアファイルの圧縮技術に使われています。また仕組みがわかるとなぜシャープな画像ではブロックノイズが出てしまうのかというのも理解できるようになります。
画像は軽い方が良い
画像が重たいと表示速度やアプリサイズ、通信帯域に影響を与えます。
表示が遅いとユーザーが離れる可能性があります。
ファイルが重たいと通信帯域を圧迫し、ユーザー目線ではサーバーに繋がりにくくなったり、運営側目線では課金に跳ねてきます（CDN を間に入れることが多いとは思いますが）。
ワーディング
ユーザーに寄り添った言葉を使う
何が起きるのか、ユーザーが想像できる言葉を使うべきです。
言葉が不親切だと「これを押したら取り返しのつかないことになるのでは？」と想像してしまうユーザーはいます。
例えば注文ボタンがあったとき、それを押すと「注文が確定するのか」「まだ注文は確定しないのか」が老若男女問わず判断できる言葉が必要です。
また、要件にもよりますが使いたくなるような言葉を使った方が良いと思っています。
登録したデータを表示するような画面でまだデータがないときに「データがありません」と表示するよりは、「最初の XXX を登録しましょう」というようなポジティブな言い回しを使った方がユーザーは気持ちが良いかもしれません。
わかりやすい言葉を使う
なんでもかんでも漢字に変換すれば良いというわけではありません。
公用文作成の考え方（建議） で、ひらがなの使用を推奨する漢字の説明がされています。
難しい漢字を使いたくなることもありますが、そこはあえて、ひらがなを使います（「敢えて」も漢字は避ける）。
先ほどのリンクには記載はないですが、「お客様」も「お客さま」と記述することも多いですね。
インタラクション
心地良い反応は大事です。ユーザーの操作に対して反応するようにしましょう。
例えばクリックできる場所はマウスオーバーやクリックで反応しないとユーザーは不安になります。
特にスマホの場合はマウスがないので、よりわかりやすい「押せる感」「押した感」が必要です。
tailwindcss の例ですが、ping アニメーションで「押してくれー」というアピールができます（押せる感）。
引用：https://tailwindcss.com/docs/animation#adding-a-pulse-animation
同じ tailwindcss の例ですが、押して処理を開始をしたら処理中の表示をしないと、ユーザーは押せたのかが不安になります（押した感）。
スマホの場合はバイブの機能もあるので、ユーザーの操作に反応して少しだけ振動させてあげるのも良いですね。
インタラクションや言葉の使い方など、細かな配慮は Nintendo Switch の開発の話もとても面白いです（参考サイト）。
音や画面遷移もこだわって作り込んでいることがわかります。見習いたいものですね。
UI 部品ごとのデザイン
実際の開発にあたっては UI 部品を 1 個 1 個デザインしていく必要があります。
ここでは特に語りませんが、Material Design3 の Components の一覧を見ると、どういう UI 部品が必要となるのかイメージが掴めると思います。
開発においては UI を部品化し、すべての画面で同じ部品を使いまわすことで、画面ごとのデザインや機能の乖離をなくしたり、生産性の向上を図ります。
引用：https://m3.material.io/components
その他に開発時に考慮が必要なもの
ズーム設定の考慮
主にスマホですが、OS のズーム設定に従うのか、無視するのか。
もちろん従うのがベストですが要件と開発コストとの折り合いになります。
OS 固有の考慮
OS 固有のためカスタマイズ不可なこともあります。
例えば OS 機能で表示するダイアログですね。
もちろんダイアログ自体を自作することも可能ですが、権限関係のダイアログの見た目はカスタマイズできません（文言もカスタマイズできたり、できなかったりです）。
カスタマイズできる箇所とできない箇所を考慮してデザインを決める必要があります。
トランジションについて
いきなり切り替わるのか、右からスライドインするのか、下から上がってくるのか、など。
静的なデザインのやりとりでは伝わらない部分のため、事前に確認する必要があります。
スプラッシュスクリーンについて
スマホアプリを起動した直後に表示される画面のことです。
Android12 以降はホームアイコンがスプラッシュ画面にそのまま表示される動きが標準になっています。そのため普通に作ると iOS/Android で同じ見せ方にはできないので、それぞれのデザインについて確認が必要です。
OSS ライセンスページについて
デザイナーがいるプロジェクトでも画面デザインが用意されていないことがあるので、そういうときは開発側から確認した方が良いです。
1 個 1 個手作業で対応すると漏れが発生するのでビルド時に自動生成される仕組みを考えて導入した方が良いです。
デザインのブレ
Figma等でデザインを受け取って開発をする場合、基本的にはカラーリングやスペーシングなどのデザインガイドと各画面のデザインを受け取ると思います。それをそのまま実装へと反映したいところですが、デザイナー側もミスすることはあります。デザインガイドにない色や余白が登場してくることもあるので、そのまま実装に反映するのではなく意図されたデザインなのか確認しましょう。デザインガイドにないデザインがあると、画面固有の個別実装になるためコードの複雑さが増してしまいます。思考停止でデザインを受け入れるのではなく、開発側としてちゃんと確認をしましょう。
ねらいは何で、誰が何のために使うのか
何がしたいのか、誰が使うのかを意識する必要があります。
例えば「天気アプリ」を作る場合、ユーザーは天気を知りたいのでしょうか？
多くの場合、ユーザーは「傘が必要かどうか」「洗濯物を干せるかどうか」を知るために天気アプリを使います。
そう思うと、何を画面に表示するべきかもちょっと変わってくる気がしませんか？
誰が使うのかも重要です。要件を出す人とアプリを使う人が違う場合、要件が必ずしも真実とは限りません。
例えば DX 推進のような文脈では、推進する部署の人と会話しますが実際に使うのは別の業務部門です。実際の業務に耐えれるのかどうかは実際に業務をしている人に聞かないとわかりません。また、逆に業務をしている人に聞いても、変化を望まないのであれば「何も変えないことがベスト」という回答にしかならないかもしれません。
何がしたいのか、誰が使うのかを意識し、想像をしてヒアリングをして、モノづくりを進めていきます。「僕が考えた最高のデザイン」ではダメなんです。
ビジュアルの方向性を考える
以下は個人的に作ったゲームですが「可愛い＆POP」を意識して色の選定やトランジションを作っています。
以下は個人的に作った子供が参加しているダンスチームのポスターの一部分なのですが、ブレークダンスの起源の 1 つに「ギャングの抗争」があるところから、「社会への反発」というテーマ設定でポスター全体をデザインしました。
プロのデザイナーではないですし拙い事例で恐縮ですが、デザインの軸を決めると悩みが減ります。デザイナーがいないようなプロジェクトの場合は、自分のなかで何か軸を設定すると良いかもしれません。
凡人には１からデザインを考えるのは至難の業のため、インスピレーションをもらいたくなります。
デザインのアイデア共有サイトを見る
Pinterest や Dribbble のようなサイトを見るのも良いかもしれません。
私の場合、前述のダンスのポスターを作るにあたってはアイデアを収集してから取り組んでます。
デザインシステムを見る
デザインシステムを公開している会社・組織もいますので、見ると参考になると思います。
例えばデジタル庁はデザインシステムを公開しています。
ちなみに最近の私の例だと、入力フォームの「必須」という文字はラベルの前と後ろのどちらに書くべきか迷ったのでデジタル庁のデザインシステムを見てました。
引用：https://www.digital.go.jp/policies/servicedesign/designsystem
既存のアプリを知る
UI Pocket のようなサイトを見ることで既存のアプリのデザインを知ることができます。
AI を利用する
デザインを作ってもらう
Figma の AI 機能を使えばプロンプトからデザインを作ってくれます。
残念ながら「Web アプリ」はデザイン対象にはないのですが、Web サイトとスマホアプリのデザインは作ってくれます。
以下は最近はよく見かけるような ChatGPT っぽいチャット UI ですが、これもプロンプトで作ってくれます。
アプリ全体の生成は難しくても部品として流用できるものを作ってくれることがあるので、1 からお絵描きする必要がなくなるので生産性があがります。
ちなみに見た目に関する生成 AI への指示（プロンプト）は、AI に作ってもらった方が良いです。画像や動画、UI などを作る場合は自分でプロンプトを作らずに、ChatGPT 等にイメージを伝えてプロンプトを作ってもらった方が良いです。個人的な感覚ですが、映像関係の方や小説家など、視覚情報を言語化できる人でないと十分なプロンプトを作るのは難しいのではないかと思っています。
プロトタイピングをしてもらう
他にも v0 や Firebase Studio などアプリのプロトタイピングをしてくれるサービスがあるので、そういったサービスを使ってみてインスピレーションを得ることもできます。
プロトタイピングをする
チャットで切り貼りでも良いですし、Claude Code/Gemini CLI のようなツールでも良いですし、自分でプロトタイプをとりあえず作ってみてから考えてみても良いと思います。
自分の場合、雑な指示で画面を作ってもらうときは Claude が一番良いです。GPT や Gemini で作っても、画面は Claude にお願いすることが多いです。Claude 感があるし、最終的には手作業で見栄えの修正をすることが多いですが、それでも 1 から手で作るよりは断然楽です。
（ただし、この記事を書いている時点では GPT-5 はまだ十分に試していません。この記事の途中に例として添付しているHTMLの画像は GPT-5 で作っており、以前より綺麗な気はしてますがまだよくわかっていません。）
引用：クラウドの日本語 TTS をいろいろ試すで作った画面のプロト
これはただの妄想なのですが、AI Readable なデザインというのも今後はでてくるかもしれません。
AI が読みやすければ AI のアウトプットも良くなるでしょうし、Token の消費が少なくなってエコになります。
情報収集的な使い方だけでなく、AI にテストしてもらう、評価してもらうなどといったタスクにおいても導入のしやすいアプリの作りというのが今後でてくるかもしれませんね。
本記事はデスクトップアプリ、スマホアプリ、Web アプリの開発経験からまとめた内容になっています。アプリ開発以外はしていないので Web サイトや、本業のデザイナーの方の感覚とは違う部分あるかもしれませんが、なにかの参考になれば幸いです。
過去に書いた記事を再整理し、最近の変化を追加したものになります。
Views: 0
