はじめに
前回までで、Claudeの仕組みや設計思想について整理してきました。
これまでは主に概念や特徴の理解が中心でしたが、
今回は一歩踏み込んで「実際にどう使うと精度が変わるのか」という点について学びました。
生成AIは自然言語でもある程度のアウトプットを返してくれますが、プロンプトの書き方によってその質や安定性が大きく変わると言われています。
また、AIが普及することによって「非エンジニアですら誰でもある程度のものが作れるようになる中で、エンジニアとしてどのような価値を発揮していくべきか」という点についても、個人的に考える部分でもありました。
そこで今回は、
- そのままの自然言語で指示した場合
- マークダウンで構造化した場合
- 役割を与えた場合
といったパターンで実際に比較しながら、
プロンプト設計による違いを整理していきます。
また、その結果を踏まえて、今後の業務への活かし方についても考えてみます。
プロンプトの考え方
プロンプトとは、AIに対して与える指示や入力のことです。
生成AIは自然言語でもある程度のアウトプットを返してくれますが、
実際に活用していく上では、どのように伝えるかによって結果が大きく変わると感じました。
今回の内容では、特に以下の点が重要だと考えています。
- マークダウンなどを用いて構造化すること
- 役割を与えることで出力の方向性を明確にすること
- 曖昧な表現を避け、具体的に指示すること
これらを踏まえ、実際にプロンプトの書き方によってどのような違いが出るのかを検証していきます。
検証してみた
同じ内容に対してプロンプトの書き方を変えることで、
どのようにアウトプットが変わるのかを検証してみました。
検証条件
今回の検証は、Claude（Web版）を使用して行っています。
すべて同一のモデル・環境で実行し、プロンプトの書き方のみを変更して比較しています。会話の履歴が影響を及ぼと考え、検証パターンごとに「新規会話チャット」を行い実行しています。
また再現性の確認のため、３回ずつ実施してみました。
※なお、Claude CodeやClaude Coworkなど他のサービスでは挙動が異なる可能性がありますが、今回はあくまで「プロンプトの書き方による違い」に焦点を当てています。
また、④の過剰な役割付与については、役割表現そのものの影響を見るため、要件・技術制約は③と同条件で統一しています。
評価観点
あくまで主観での評価にはなりますが、以下の観点で評価してみました。
- 機能の充足度
- UIの品質
- 出力の再現性
① そのまま実行
プロンプト
TODOアプリをHTMLで作ってください。タスクを追加したり、削除したり、完了にしたりできるものです。
実行結果
 |
 |
 |
評価
| 評価軸 | 結果 | コメント |
|---|---|---|
| 機能の充足度 | ◎ | 3機能は揃っている |
| UIの品質 | △ | 最低限のスタイルはあるが、見づらい。装飾は少ない。 |
| 出力の再現性 | ⚪︎ | デザインが大きくブレることはない |
自然言語のみでも動くものは作れるが、最低限のデザインで、プロンプトによる差異はそこまでない。しかしプロダクション用途には向かないと思われる。
② マークダウンで構造化
プロンプト
# 要件
WebブラウザのみでHTMLとして動作するTODOアプリを作成してください。
## 機能
- タスクの追加（テキスト入力＋ボタンまたはEnterキー）
- タスクの削除
- タスクの完了状態の切り替え
## 技術
- HTML / CSS / JavaScript のみ（外部ライブラリ不使用）
- 単一ファイル（index.html）
## 制約
- スタイルはファイル内の<style>タグで記述
- ロジックはファイル内の<script>タグで記述
実行結果
 |
 |
 |
評価
| 評価軸 | 結果 | コメント |
|---|---|---|
| 機能の充足度 | ◎ | 指定した3機能がすべて過不足なく実装された |
| UIの品質 | ⚪︎ | 機能に対して適切なスタイルが当たっているしオシャレ |
| 出力の再現性 | ⚪︎ | ある程度近い品質・構成の出力が得られた |
要件・機能・制約を構造化することで、①より出力が安定し意図した結果に近づく。「こんなアプリあるなぁ」という感想。プロダクトとして使用できそう。
③ 役割付与
プロンプト
あなたはWebアプリ開発のフロントエンドエンジニアです。
以下の要件でTODOアプリをHTMLで作成してください。
# 要件
- タスクの追加（Enterキーまたはボタン）
- タスクの削除
- タスクの完了状態の切り替え
# 技術
- HTML / CSS / JavaScript のみ（単一ファイル）
コードは保守しやすい構造で記述してください。
実行結果
 |
 |
 |
評価
| 評価軸 | 結果 | コメント |
|---|---|---|
| 機能の充足度 | ◎ | 3機能が確実に実装されている |
| UIの品質 | ◎ | ②と同等かそれ以上。見やすく、実用的なUIになりそう |
| 出力の再現性 | ◎ | 色やデザインは変わるが、HTML構造など骨格が安定していた |
適切な役割付与は②の効果に加え、専門性を持たせることで出力の水準が上がった印象。
④ 過剰な役割付与
プロンプト
あなたは世界最高のエンジニアであり、天才的なUIデザイナーでもあります。誰も見たことのない革新的なTODOアプリをHTMLで作ってください。
以下の要件でTODOアプリをHTMLで作成してください。
# 要件
- タスクの追加（Enterキーまたはボタン）
- タスクの削除
- タスクの完了状態の切り替え
# 技術
- HTML / CSS / JavaScript のみ（単一ファイル）
コードは保守しやすい構造で記述してください。
実行結果
 |
 |
 |
評価
| 評価軸 | 結果 | コメント |
|---|---|---|
| 機能の充足度 | ◎ | 3機能が確実に実装されている |
| UIの品質 | △ | スタイリッシュにはなったが、タスクの確認が少ししにくい |
| 出力の再現性 | ⚪︎ | 安定しているが、やや解釈の幅が出る印象 |
見た目がカッコ良くはなったが、実用には少し向かない印象でした。
比較して分かったこと
| パターン | 機能の充足度 | UIの品質 | 出力の再現性 | 総評 |
|---|---|---|---|---|
| ① 自然言語のみ | ◎ | △ | ⚪︎ | 動作はするが実用性は低い |
| ② マークダウン構造化 | ◎ | ⚪︎ | ⚪︎ | 安定して実用的な出力 |
| ③ 役割付与 | ◎ | ◎ | ◎ | 専門性が加わりさらに良い |
| ④ 過剰な役割付与 | ◎ | △ | ⚪︎ | 見た目は変わるが実用性低下 |
自然言語でも動くものは生成されますが、UIや実用性には差が見られました。
特にマークダウンで構造化することで、要件に沿った安定した出力になりやすい傾向がありました。
また、役割付与については、今回は「フロントエンドエンジニア」という設定で検証しましたが、
「営業アシスタント」や「テストのプロフェッショナル」といった例も効果的であるそうで、
専門性を持たせることでより適切なアウトプットが得られるとのことでした。
一方で「世界一の〇〇」といった過度な表現は曖昧さを生み、かえって精度を下げる可能性があるという話もあり、今回の検証でも実用性の低下という形で確認できました。
ただ、この点について実際のところはさまざまな解釈はあるそうです。この分野は日々常識が変化しているため、継続的に情報を追っていく必要があると感じています。
まとめ
今回の検証から、AIの出力品質は「どう伝えるか」に大きく依存すると感じました。
構造化や適切な役割付与によって、品質と再現性が向上することが確認できました。
一方で、曖昧な指示や過剰な表現は、出力のブレや実用性低下につながる可能性があります。
なお、今回はシンプルな仕様かつ少数回の検証のため差が限定的な部分もありましたが、
より複雑な要件では差が広がると考えています。
また、エンジニアの価値という観点では、インフラ周りの知識も重要になるという話もあり、
この点については今後あらためて整理していきたいと思います。
今回の結果から、AI活用においては「伝え方の設計」が重要であると感じました。
引き続き実践を通じて、プロンプト設計の精度を高めていきたいと思います。