AIの特性から考えるより良いAIの活用法
はじめに
今回は、先日参加した「非エンジニア大歓迎！「使えるAI」体験会｜YOSHINANI」で登壇した内容について、少し詳細に書いていこうと思います。
イベントについてはこちら↓
登壇資料はこちら↓
AI活用を最適化するための3つの視点
AIツールや大規模言語モデル（LLM）が身近な存在になり、業務や開発の中で積極的に利用する人も増えてきました。
ただ、その一方で「思ったような答えが返ってこない」「結局自分で直すことになる」そんな体験をしている人も多いのではないでしょうか。
今回はLLMの特性と、それを踏まえたより良いプロンプトの考え方についてまとめていきます。
この記事で紹介する特徴は以下の3つとなります。
- LLMは意味を理解しているのではなく、確率的に次の token を予測している
- LLMは複数の意図や目的が混ざった依頼を処理するのが苦手
- LLMは抽象的なルールより、具体的な例示や評価基準によって出力が安定する
1. LLMは「確率的な言語生成モデル」である
LLMは文章を理解し推論しているように見えますが、実際には与えられたコンテキストの次に出現する確率の高い token を逐次生成しているだけです。
GPT・LLaMA・Gemini・Claudeなどはいずれも、基盤は auto-regressive language model であり、内部には以下の性質があります。
- 意味論的解釈より統計的連続性を優先する
- 文脈情報は
attention構造で保持するが、意図を理解する概念は存在しない - 曖昧な入力は曖昧な分布を返す（確率分布が収束しない）
そのため、依頼内容に不足している情報、曖昧な表現、想定外の揺らぎが存在すると、モデルは最もありそうな答えを返すだけになります。
これにより、LLMはあたかも真実かのように嘘を言う場合があります。
この特性を踏まえて、曖昧な依頼を避け、事実・意図・制約を明示したコンテキストを与えることで、出力の精度が向上します。
特に下記の4つを明確にしたプロンプトを与えることで出力の精度が高まります。
- 目的: 何のために出力したいか
- 対象: 誰に向けての出力か
- 制約条件: 文字数、禁止事項などの制約
- 出力形式: 回答の構造やテンプレートなど
これらを明示することで、モデル内部の確率探索空間が狭まり、回答が収束しやすくなります。
実際の出力は下記のような差があります。
今回は、「Reactってよく聞くけど、結局何なの？それって使う理由あるの？」と感じている人が、Reactって何なんだろうとAIに聞いたとした時の例を比べてみました。
悪い例
入力
Reactについて教えてください
出力
もちろん！Reactについてわかりやすく説明します。
難しければ例を使って噛み砕いていきますので、遠慮なく質問してください😊
🔷 Reactとは？
React（リアクト）は、ユーザーインターフェース（UI）を作るためのJavaScriptライブラリです。
Facebook（現Meta）が開発し、今ではWebアプリ開発で最も人気のある技術の一つです。
🔷 Reactの特徴
| 特徴 | 内容 |
|---|---|
| 🧩 コンポーネント思考 | UIを小さな部品（コンポーネント）に分けて作る |
| ⚡ 仮想DOM（Virtual DOM） | 必要な部分だけ更新し、高速表示を実現 |
| 🔁 再利用性が高い | 同じコンポーネントを何度でも使える |
| 🔍 状態管理が簡単 |
useState などで UI とデータを同期しやすい |
| 🌍 大規模開発向け | 多くの企業で採用されている |
🔷 Reactでできること
- Webアプリ（Twitter、YouTubeのような動的サイト）
- 管理画面（ダッシュボード）
- SPA（Single Page Application）
→ ページ遷移しても全体リロードされないアプリ
🔷 簡単なReactコード例
これはボタンを押すとカウントアップするコンポーネントです👇
import { useState } from "react";
function App() {
const [count, setCount] = useState(0);
return (
<div>
<h1>カウント: {count}</h1>
<button onClick={() => setCount(count + 1)}>増やす</button>
</div>
);
}
export default App;
🔷 Reactに出てくる重要用語
| 用語 | 意味 |
|---|---|
| コンポーネント | UIの部品（例：ボタン、ヘッダー） |
| Props | コンポーネント間で渡すデータ |
| State | 変化するデータ（クリック数など） |
| Hook | Reactの機能を使う方法（例：useState, useEffect） |
🔷 Reactを学ぶおすすめロードマップ
- HTML / CSS / JavaScriptの基礎
- Node.js & npm
- React基礎（JSX / Component / Props / State）
- Hooks（useState / useEffect）
- React Router
- 状態管理（Context API、Redux、Zustandなど）
🔷 Reactが使われている身近なサービス
- Netflix
- Airbnb
- Amazonの一部UI
⭐ まとめ
Reactは「再利用できる部品（コンポーネント）」でユーザーインターフェースを作るJavaScriptライブラリで、動きのある高機能なWebアプリ作成に最適な技術です。
興味あれば、次は👇
📌「Reactの環境構築」
📌「Next.jsとの違い」
📌「ReactでTodoアプリを作る」
なども説明できます。
続けますか？😊
良い例
入力
Reactについて説明してください。
- 対象：プログラミング初心者
- 目的：技術選定の概要理解
- 条件：専門用語は可能な限り避ける
- 文字数：150文字以内
- 形式：箇条書き
出力
- Web画面を作るための仕組み
- 必要な部分だけ更新できるため、動きが軽い
- いろいろな場面で使われており、情報やサンプルが多い
- 他の仕組みと組み合わせやすく、柔軟に開発できる
このように、目的や対象、条件等を書くことで知りたい部分の情報をうまく得ることができます。
2. LLMは「タスク分解思考を内蔵していない」
人間は複雑な依頼を受けたとき、無意識に次のような思考プロセスを踏みます。
- 依頼の目的や優先順位を整理する
- 前提条件や制約を読み取る
- 情報の粒度や構成を決める
- 必要な内容を埋めて仕上げる
つまり、人間は「まずどう進めるか」を設計したあとに作業へ進みます。
一方で、LLMはこのような段取りやタスク分解を自律的に行うことができません。
LLMは入力文全体を一度に最適化しようとするため、複数の意図・条件・目的が混ざった依頼では、どれを優先すべきか判断できず、内容がブレたり浅くなったりします。
これが、いわゆる 「丸投げプロンプトが失敗しやすい理由」 です。
これを踏まえて、LLMにタスク分解を期待するのではなく、こちらが段階的に指示する設計に切り替えることで精度が安定します。
ポイントは次の3つです。
-
依頼を分割する
- 一度にまとめず、小さく渡す
-
途中の出力を確認しながら進める
- 一方通行ではなく対話形式
-
考え方や手順も一緒に出力させる
- 答えだけではなく過程を出力させる
これにより、LLMは誤解や推測による迷走を避け、意図に沿ったアウトプットに近づきます。
実際の出力は下記のような差があります。
悪い例
入力
ReactについてNext.jsとの違いや採用企業の事例をまとめつつ、初心者にわかりやすく、専門家視点の技術的のメリデメもいれて説明してください。 また、経営層にも刺さるような言い回しで説得力を出してほしいです。 文字数はできれば短めで、できるだけ丁寧な表現にしてください。
出力
以下、ご要望の通り、React と Next.js の違いや、それぞれを採用している企業事例を交えつつ、「技術的メリット／デメリット」と「経営視点での刺さりどころ」を、初心者にもわかりやすく、かつやや専門家視点で整理してみます。
🔹 Reactとは／Next.jsとは
- React は、ウェブアプリやサイトの「画面(UI)」をつくるための ライブラリ です。いわば「表示部品の集め方・描画ルール」を提供するもので、ルーティングやデータ取得、サーバーとの連携などは自分で設計・実装します。(Kinsta®)
- Next.js は、React をベースに、画面描画だけでなく「サーバー側処理」「ルーティング」「ビルド／配信最適化」などを含めた フルスタック向けフレームワーク です。つまり、React だけでは自前で作る必要のある部分を、Next.js が標準でサポートします。(ギョーテン)
✅ 採用企業の事例 — 実績ある信頼のスタック
React を使っている企業
- Netflix、Facebook、Shopify、Airbnb など、多数の大手企業が React を UI 層に採用しています。(Technext)
Next.js を使っている企業／サービス
- Next.js を採用する代表例として、Nike、Netflix（特に求人サイト等）、TikTok、Twitch、Hulu、Spotify などがあり、グローバルな大規模サービスで実績があります。(naturaily.com)
- また、Next.js を使っている企業は 2025 年時点で「数千〜数万」規模にのぼる —— ある調査では約 17,921 社が「Verified」で Next.js を使用とされており、業界・規模を問わず広く採用されています。(Landbase Data)
これらの導入実績は、「技術的に信頼され選ばれてきたスタックである」という強い裏付けになります。
🛠 技術的メリット／デメリット（専門家目線で）
| 技術観点 | React の強み / 弱み | Next.js の強み / 弱み |
|---|---|---|
| 役割の明確さ / 拡張性 | UI に特化 → 軽量で柔軟。必要な機能だけを自分で選べる。 | UI + ルーティング + サーバー処理 +最適化まで包括 → “枠組みありき” で効率的。構成が固まりやすい。 |
| 初期設定・構成コスト | 全体の構成はほぼ “白紙” → 自由だが設計と実装が必要。 | “ゼロコンフィグ”で始められる → 導入・立ち上げが速く、ミスも起きにくい。(ギョーテン) |
| 表示性能 / ユーザー体験 | CSR（クライアント側レンダリング）では、初回ロードが遅く SEOにも弱い。大規模には課題。(コーディングの外注・代行ならコーディングアライブ) | SSR／SSG／ISR など使い分け可能 → 初回ロード高速、SEO に強く、UX に好影響。(naturaily.com) |
| 開発スピードと保守性 | 自由だが、設計思想を統一しないとコードベースが混沌化しやすい。 | 標準機能が整っており、チーム開発・保守性・拡張性に優れる。特に中〜大規模に有利。 |
| 柔軟性・カスタマイズ性 | “必要なものだけ”の柔軟構成が可能。軽量な SPA に最適。 | フレームワークの枠にある程度縛られる → カスタマイズ性は React 単体に比べ限定されやすい。 |
―― 要するに、「シンプルで自由」 を求めるなら React、「速く、安定的に、拡張しやすく」 を求めるなら Next.js、という棲み分けが現実的です。
なお、最近の研究（2025年）では、Next.js を使った設計で “モジュールごとの描画と遅延 Hydration（インタラクティブ処理の後回し）” を組むことで、さらにパフォーマンスと使いやすさを両立しやすい、という報告もあります。(arXiv)
📈 経営／ビジネス視点で「刺さる」理由
- 市場実績と先行導入実例が豊富 — Nike や Netflix、Spotify など大手でも採用されており、技術の信頼性や将来性は明白。これだけの企業が選ぶ時点で、技術リスクは相当抑えられている。
- ユーザー体験と SEO／パフォーマンスの両立 — Next.js を使えば初回表示の高速化、SEO強化、安定したレスポンスという “ビジネスに直結する価値” を得られる。特に EC やメディア、集客型サービスではコンバージョン改善や離脱防止につながる。
- 開発・運用コストの最適化 — Next.js のようなフルスタック型を使えば、設計〜実装〜運用までの工数を削減でき、チームやリソースの効率化につながる。中長期的には保守コストも安定する。
- 拡張性と将来への柔軟性 — サービスが成長してページ数が増えたり、複雑化したりしても、Next.js の構造であればスケールさせやすい。新機能追加や多言語対応、モバイル対応などにも強い。
―― 経営層から見れば、「単なる技術選定」の話ではなく、「将来のビジネス成長と収益性、顧客体験の支えになるプラットフォーム選び」という文脈で語れる、ということです。
🎯 結論／おすすめの使い分け
- 軽量な SPA や、単機能のツール、社内ツール、プロトタイプ などを作るなら → React 単体。
- 集客・SEO 重視、コンテンツ量が多いサービス、成長フェーズのWebサービス、EC／メディア／SaaS など では → Next.js。
もし「これから何を使うか」を決めるなら、特に「長く続くサービス」なら Next.js をおすすめします。理由は、「最初から堅牢／高速／保守性が高いプラットフォームを採用することで、後から手戻り・性能問題に悩まされづらい」からです。
もしよければ、 日本企業での React / Next.js 導入事例 も探して紹介できます。
（グローバルだけでなく、国内での採用状況を見ると、導入のハードルやメリットがさらにイメージしやすいためです。）
良い例
入力1
Reactの概要を、プログラミング初心者向けに100文字以内で説明してください。
条件：専門用語は可能な限り避ける。
出力1
Reactは、画面を部品ごとに作れるしくみで、同じ部分をくり返し使えるため、アプリ作りが楽になる道具です。
入力2
次にReactとNext.jsの違いを、エンジニア向けに表形式で比較してください。
比較軸：SSR / 学習コスト / ユースケース / 採用企業例
出力2
| 項目 | React | Next.js |
|---|---|---|
| SSR (Server Side Rendering) | 標準ではサポートなし。CSRが基本。SSRは外部ライブラリや自作で対応。 | 標準サポート。SSR / SSG / ISR など柔軟に選択可能。 |
| 学習コスト | 低〜中。コンポーネント思考とHooksが理解できれば使える。 | 中〜高。React知識に加え、ルーティング、SSR概念、API Routes、App Router など習得が必要。 |
| ユースケース | SPA・UIコンポーネント開発・既存Webへの部分導入。 | SEOが必要なWebアプリ・ECサイト・ブログ・BtoCサービス全般。 |
| 採用企業例 | Meta、Netflix、Airbnb（UI部分）、Shopify など | Vercel、Notion、LINE、SmartHR、メルカリ（Web版）など |
入力3
最後に、経営層向けに「Reactを採用する意義」を100文字以内でまとめてください。
条件：採用メリットと事業影響の観点で書く。
出力3
Reactは開発効率と保守性を高め、開発スピードと品質を両立。変化に強いプロダクト開発を可能にする。
この違いは、LLMが依頼文全体を一度に最適化しようとする性質にあります。
悪い例では優先順位が曖昧なため探索空間が広がり、回答が分散します。
一方、良い例では意図・対象・形式・制約が段階的に与えられているため、
モデルの推論範囲が収束し、安定した出力が得られます。
3. LLMは「ルールよりパターン模倣に強い」
LLMは論理的なルールに従うより、既存の文章パターンを模倣することが得意です。
これは学習過程で膨大なテキストを読み込み、文体・語彙・構造・リズムといった形式的特徴を統計的に再現する能力が発達しているためです。
そのため、抽象的な条件よりも、 「こう書いて」ではなく「これを真似して」 と言われたほうが精度が安定します。
なので、LLMに「意図を推測させる」のではなく、模倣対象と評価基準を与えることで、再現性と品質が向上します。
効果的な方法は次の3つです。
-
例文を渡す
a. 文章のパターンを提示する -
基準・トーン・制約を指定する
b. 評価軸を固定する -
改善ループを作る
c. 自己レビュー → 書き直し
この流れにより、LLMは模倣対象・ゴール・改善方向を理解し、出力がブレなくなります。
今回の例では、メールの文章を渡してみようと思います。
例のメール文章
先日のミーティングありがとうございました。話した内容ですが、結論としては今のところ進め方に大きな問題はないと思っています。ただ、一部まだ判断できてない点がいくつかあるので、そこは引き続き検討が必要かなと思っています。それと、共有した資料ですが、少し修正してから改めて送ります。まだ書ききれていない部分があるので、もう少し整理してからで大丈夫でしょうか？あと、次回のミーティングの日程ですが、来週前半だと調整しやすいので、都合が良い日があれば教えてください。時間は前回と同じくらいで問題ないと思っています。
悪い例
入力
文章を丁寧にしてください。
出力
以下、丁寧な表現に整えた文章です。
先日はミーティングのお時間をいただき、誠にありがとうございました。
お話しした内容につきまして、現時点では大きな問題なく進められていると考えております。ただし、一部まだ判断が難しい点がございますので、引き続き検討が必要かと思っております。
また、共有いたしました資料につきましては、修正を加えた上で改めてお送りいたします。まだ整理し切れていない部分がございますので、もう少しお時間をいただけますと幸いです。
さらに、次回ミーティングの日程についてですが、来週前半ですと比較的調整しやすい状況です。ご都合の良い日程がございましたら、ご連絡いただけますでしょうか。なお、所要時間は前回と同程度を予定しております。
どうぞよろしくお願いいたします。
必要であれば、社外向け・上司向け・カジュアル寄りなどにさらに調整も可能ですので、お申し付けください。
良い例
入力1
以下の文章の問題点を3つ挙げてください。
出力1
以下の文章には伝わりにくさやビジネス文書として改善できる点があり、主に以下の3点が問題点として挙げられます。
①文章が長く、要点が整理されていない
文がひとつながりで続いており、内容（結論・依頼・共有事項）が混在しています。読者が重要な部分を把握しにくく、ビジネス文書としてメリハリに欠けています。
②依頼内容が曖昧
「大丈夫でしょうか？」「教えてください」など依頼の締め方はあるものの、具体的な期限や回答方法が示されていません。
読む側は「いつまでに返答すればいいのか？」が判断しづらい状態です。
③表現に曖昧さが多く、意図がぼやけている
「大きな問題はないと思っています」「まだ判断できてない」「整理してから」など、断定を避けた曖昧な表現が多く、受け手に不安や判断の余地を与えてしまっています。
ビジネス文章では、必要に応じて明確な表現を使うほうが望ましいです。
必要であれば、この文章をビジネスメール向けに改善した例文も作成できます。
入力2
次に、問題点を踏まえて書き直してください。
条件：丁寧なトーン・300文字以内・専門用語は避ける。
出力2
以下、条件を踏まえて書き直した文章です。（約190文字）
先日はミーティングのお時間をいただき、ありがとうございました。現時点では進め方に大きな問題はないと考えております。ただ、一部まだ検討が必要な点がありますので、内容を確認し次第ご連絡いたします。共有資料については修正後に改めてお送りします。
また、次回ミーティングは来週前半で調整できればと思います。ご都合の良い日時を教えていただけますと幸いです。
入力3
最後に、書き直した理由を一文で説明してください。
出力3
読み手が内容をすぐ理解できるよう、要点を整理し依頼事項や意図を明確にしたためです。
改善ループ
出力3で、自分の修正したい意図とずれている場合には、さらに改善を依頼することができます。
また、修正理由を今後使うスタイルガイドとして整理させることで、今後はそれをテンプレートとして扱うことができます。
このように、「ゼロから考えさせる」より「模倣＋調整させる」ほうが圧倒的に精度が安定します。
まとめ
LLMは特性が理解できれば安定して成果を出せるツールです。
- LLMは「理解しないまま確率で答える」
- 複雑な依頼は「分解しながら渡す」
- 模倣可能な例と基準で「改善ループ」を設計する
この3つを押さえれることで、精度は格段に上がります。
Discussion