1. はじめに：AIに「全部やらせる」限界を感じていませんか？

「コードを書かせるな、教えてもらえ」Matt Webbの言葉から学ぶ、実務に効くプロンプトエンジニアリング実践ガイドの概念図

「生成AI（人工知能）を使って業務を効率化しよう！」

そう意気込んでChatGPTなどのAIツールを導入したものの、いざ実務で使ってみると、期待していたほどの成果が出ずにモヤモヤした経験はないでしょうか。

例えば、プログラミングや複雑な書類作成、データ分析などで「こういうコードを書いて」「この業務を代わりにやって」とAIに一括で指示を出してみたとします。最初のうちは「一瞬で出力されてすごい！」と感動するかもしれません。しかし、実務が複雑になればなるほど、次のような壁に突き当たります。

  • 出力されたコードや文章が、自分のプロジェクトの仕様に合っていない
  • 不具合（バグ）が発生したとき、AIが作ったものなので自分で修正・デバッグできない
  • AIに修正を頼むと、別の場所が壊れて余計に時間がかかる
  • 結局、AIの出力をチェックして直すのに自分の手でゼロから書く以上の時間がかかってしまう

AIに作業を丸投げし、自動で完璧な成果物を出してもらおうとするアプローチは、一見すると効率的に見えますが、実務の現場ではしばしば行き詰まってしまいます。

では、AI時代において実務の生産性を本当の意味で高めるには、AIとどのように向き合えばよいのでしょうか。

その強力なヒントとなるのが、著名なデザイナーでありテクノロジーの観察者でもあるMatt Webb（マット・ウェブ）氏の言葉です。彼は、自身のプロジェクトで複雑な計算処理（回転処理）を実装する必要が生じた際、ChatGPTにコードを丸投げして書かせるのではなく、「自分を教育させるための指導者」として利用しました。

本記事では、このMatt Webb氏のアプローチを出発点として、AIに対する適切な指示文の設計技術である**「プロンプトエンジニアリング」**を、単なる「指示のテンプレート集」ではなく、「実務で成果を出し、自身のスキルも高めるための対話設計・運用ガイド」として分かりやすく解説します。

2. Matt Webbの言葉が示す、生成AIの「本当の価値」

まずは、本記事のベースとなるMatt Webb氏の言葉（Simon Willison氏のブログにて引用された内容）を振り返ってみましょう。

“After I released version 1.0, I figured I would have to do the rotations myself. So I sat down with ChatGPT and I didn’t get it to write the code, but I got it to educate me. With a patient, interactive tutor, I was able to finally do what…” （バージョン1.0をリリースした後、自分で回転処理を行わなければならないと悟りました。そこでChatGPTに向き合い、コードを書かせるのではなく、自分を教育させました。根気強く対話的な家庭教師のおかげで、ついに自分でやり遂げることができたのです）

※なお、引用元記事に掲載されているMatt Webb氏の具体的な開発プロダクトの全貌や、実装されたコードの完全な詳細については一次情報内にすべてが記載されていないため未確認ですが、ここで彼が語っている「AIの使い方」の本質は極めて明確です。

このエピソードは、私たちがAIを利用する際の発想を根本から変えてくれます。

「作業の代行者」から「対話型の優秀な家庭教師」へ

多くの人はAIを「指示通りに作業をこなす代行者」として使おうとします。しかし、複雑な業務や専門知識が求められるタスクにおいては、AIに成果物を直接作らせるよりも、**「自分自身の理解を深めるための家庭教師（チューター）」**として使うほうが、結果的に早く、高品質な成果にたどり着くことがあります。

AIは、どれだけ質問しても嫌な顔をせず、こちらの理解度に合わせて何度でも説明を変えてくれる「極めて根気強い存在」です。自分が理解していないコードや文章をそのまま業務に採用するのは大きなリスクを伴いますが、AIとの対話を通じて「仕組み」を理解し、自分の手で最終的な成果物を構築できれば、保守や応用も容易になります。

プロンプトエンジニアリングの再定義

ここで重要になるのがプロンプトエンジニアリングです。

プロンプトエンジニアリングとは、一般的には「AIから望む出力を引き出すための指示文（プロンプト）を作成・工夫する技術」を指します。

しかし、実務において価値を生むプロンプトエンジニアリングとは、単に「○○のコードを書いてください」という一発回答を求めるための魔法の言葉を探すことではありません。**「AIを自分の学習・思考のパートナーとして機能させるための対話設計技術」**こそが、実務で求められるプロンプトエンジニアリングの本質です。

3. 実務で活かすプロンプトエンジニアリングの導入・設計・運用ステップ

ここからは、Matt Webb氏のような「AIを指導者として活用し、実務で確実に成果を出す」ためのプロンプトエンジニアリングの実践ステップを、「導入」「設計」「運用」の3つの段階に分けて解説します。

[導入フェーズ]
 マインドセットの転換（丸投げから対話へ）
   ↓
[設計フェーズ]
 教育型プロンプトのパターン化と作成
   ↓
[運用フェーズ]
 チームでの共有・ナレッジ化と継続改善

ステップ1：導入フェーズ（意識とマインドセットの転換）

まず行うべきは、個人やチーム全体での「AIに対する意識の転換」です。

AIを導入する際、「自動化によって人間の作業をゼロにする」ことばかりを目指すと、AIが間違えたときの対応ができなくなります。導入フェーズでは、AIの役割を以下の表のように再定義しましょう。

従来の捉え方（丸投げ型） 実務で成果が出る捉え方（教導・共創型）
AIに成果物を直接作らせる 成果物を作るための「知識と手順」をAIから学ぶ
一発の指示で100点の回答を求める 何度もやり取り（対話）して理解を深める
出力結果をそのまま鵜呑みにして使う 仕組みを理解した上で人間が最終チェック・修正する
わからない所はAIに誤魔化してもらう わからない理由をAIと一緒に言語化する

このマインドセットを共有することが、プロンプトエンジニアリングを実務に定着させるための第一歩となります。

ステップ2：設計フェーズ（教育的プロンプトの設計パターン）

AIを「優秀な指導者」に変身させるための具体例を紹介します。指示文（プロンプト）を設計する際は、AIに「答え」を出させるのではなく、「答えにたどり着くための解説」を求めます。

以下に、実務で今すぐ使える3つの設計パターンを挙げます。

パターンA：ステップ・バイ・ステップ解説法（段階的な理解）

一度に大量の解説をさせると、人間側の理解が追いつかなくなります。「段階を踏んで教える」ように指示します。

【プロンプト例】 あなたは経験豊富なシニアエンジニア（教育係）です。 論文や技術文書に出てくる「回転行列を用いた3D座標変換」について、数学が苦手な私にも分かるように説明してください。

【制約条件】

  1. 最初から完成したコードを出さないでください。
  2. まずは日常的な例え話を使って、概念のイメージを説明してください。
  3. 私が「理解できました、次へ進んでください」と返信したら、次のステップ（数式の解説）に進んでください。

このように制約を設けることで、AIが一気に答えを出力してしまうのを防ぎ、自分のペースで理解を進めることができます。

パターンB：ソクラテス式問いかけ法（対話による思考の深掘り）

AIに質問させることで、自分の曖昧な理解や要件の抜け漏れに気づく手法です。

【プロンプト例】 私は現在、新規Webサービスのデータベース設計をしようとしています。 私にいきなり答えを提示するのではなく、適切な質問を1つずつ投げかけて、私自身が最適な設計にたどり着けるように誘導（コーチング）してください。

まず、私が最初に考えるべきことに関する1つ目の質問をしてください。

このプロンプトを使うと、AIは「想定されるユーザー数はどれくらいですか？」「更新頻度が高いデータはどれですか？」といった問いを投げかけてくれます。これに答えていく過程で、自分自身の頭の中が整理されていきます。

パターンC：コード＋行解説（コードの分解解読）

どうしてもコードを生成してもらう必要がある場合でも、単にコードを出すのではなく「一行ごとの意味」をセットで解説させます。

【プロンプト例】 以下の処理を行うPythonプログラムを作成してください。 ただし、コードを提示するだけでなく、各行が「何をしているのか」「なぜその処理が必要なのか」を初心者に教える丁寧なコメント（注釈）をコード内と本文に記載してください。

ステップ3：運用フェーズ（チーム共有とプロンプトの仕組み化）

個人でプロンプトエンジニアリングのコツを掴んだら、それを組織やチームの運用に組み込んでいきます。

  1. 効果のあったプロンプトの共有（プロンプトリポジトリの作成）

    • 業務で役立った「教え方指示文」をドキュメントツール（Notionや社内Wikiなど）に集積します。
    • 「このプロンプトを使うと、難しい公式ドキュメントが10分で理解できるようになる」といったノウハウをチームで共有します。

  2. 「対話ログ」をナレッジとして残す

    • AIとのやり取りそのものが、貴重な学習ログ（マニュアル）になります。
    • 解決した課題について「AIにどのように問いかけ、どう理解して解決したか」のプロセスを共有することで、他のメンバーの教育コストを大幅に削減できます。

  3. レビュープロセスの標準化

    • AIのサポートを受けて作成した成果物（コードや文書）をチームでレビューする際、「AIからどのように説明を受け、自分がどう理解して実装したか」を説明させるルールを作ります。これにより、AIの出力をそのまま貼り付けただけの質の低い成果物が混入するのを防ぎます。

4. 実施時の注意点と限界

AIを指導者として活用するプロンプトエンジニアリングは非常に強力ですが、実践にあたってはいくつかの重要な注意点があります。

① AIの「ハルシネーション（嘘）」に注意する

生成AIには、実在しない事実や間違った計算結果を、あたかも正しいかのように堂々と語ってしまう現象があります。これを専門用語で**ハルシネーション（嘘の出力）**と呼びます。

AIが親切で熱心な家庭教師に見えたとしても、その解説自体が間違っている可能性は常に存在します。

  • 重要な公式、ライブラリの仕様、法的な解釈などは、必ず信頼できる一次情報（公式ドキュメントや専門書）でダブルチェック（事実確認）を行ってください。
  • AIの解説は「理解のきっかけ（アタリをつける作業）」として使い、最終的な正確性の担保は人間が行う必要があります。

② 機密情報・個人情報の入力に関するセキュリティリスク

AIとの対話に夢中になるあまり、社内の機密データや個人情報をそのままプロンプトに入力してしまうリスクがあります。

  • 入力したデータがAIの再学習に使用されない設定（オプトアウト設定やエンタープライズ版の利用）がなされているか確認してください。
  • 企業で利用する場合は、セキュリティガイドラインを制定し、マスキング（具体的な個人名や固有のIDを伏字にすること）を行った上でAIに入力するルールを徹底しましょう。

③ 一次情報における未確認事項について

本記事はSimon Willison氏のブログ記事に掲載されたMatt Webb氏の引用文をベースに構成しています。

なお、Matt Webb氏が当時開発していたアプリケーションの具体的な仕様、具体的なコードの行数、利用したChatGPTのモデル（GPT-3.5なのかGPT-4なのか等）、および開発にかかった正確な期間などの詳細情報については、一次情報（参照URL）内に記載されていないため未確認です。実務に適用する際は、特定の手法やツールに依存せず、汎用的な「対話設計」のアプローチとして取り入れることを推奨します。

5. まとめ：AI時代の「プロンプトエンジニアリング」の本質

今回は、Matt Webb氏の「AIにコードを書かせるのではなく、自分を教育させた」というエピソードを切り口に、実務で使えるプロンプトエンジニアリングの導入・設計・運用ガイドをお届けしました。

本記事のポイントをまとめます。

  1. 丸投げからの脱却：AIに成果物を直接作らせる「作業代行」から、仕組みを理解するための「対話型家庭教師」へと役割を変える。
  2. プロンプトエンジニアリングの本質：魔法の言葉を探すことではなく、自分の思考や理解を深めるための「対話と問いかけの設計」を行うこと。
  3. 段階的なアプローチ：AIに一気に答えを出させず、ステップ・バイ・ステップやソクラテス式の問いかけを用いて、自分の手で成果物を作れる状態を目指す。
  4. 人間の検証責任：AIのハルシネーション（嘘）に留意し、最終的な確認と責任は常に人間が持つ。

AIにすべてを任せて作らせた成果物は、一見すると早く完成したように見えますが、トラブルが起きたときに誰も対応できないという脆弱さを抱えます。一方で、AIを最高のチューターとして使い倒し、自分自身のスキルを高めながら作り上げた成果物は、極めて堅牢で応用が利きます。

「AIに作らせる」から「AIに教えてもらい、自分で作る」へ。

この意識の変化とプロンプトエンジニアリングの工夫こそが、これからの時代に個人と組織の生産性を飛躍的に高める鍵となります。まずは今日の業務から、「私にわかりやすく教えて」という一言をAIに投げかけることから始めてみてはください。

参考資料