記事一覧

テクノロジー · July 21, 2026 · 約9分

データアナリストのプロンプトエンジニアリング:数字を疑う

データアナリストのプロンプトエンジニアリングは厳密な指標の定義と、結果が照合に耐えるまで疑い続ける規律です。数字こそがリスクである理由を解説します。

Jakir Patel 著 · Founder, Hanzomon

共有

「AI生成アセスメント:2026年版 完全ガイド」の一部

テクノロジー
目次

データアナリストにとって、AIセッションのアウトプットは数字であり、その数字は資料に貼り付けられて意思決定になります。これはデータアナリストのプロンプトエンジニアリングに特有の形でリスクを高めます。失敗のパターンは醜いコードではなく、密かに辻褄の合わないもっともらしい数値です。アナリストを採用するなら、これはAI生成クエリが午後の時間を節約するか誤った事実を役員会に届けるかを決めるスキルです。これは職種別プロンプトエンジニアリングシリーズのアナリスト編であり、AI Sandboxが候補者の実際の判断力について最も明確に示すものの一つです。

AI SandboxではアナリストがAIツールを使って実際の問いに取り組み、シグナルは指標を厳密に定義し、データが裏付けない数字を疑えるかどうかです。

アナリストにとってリスクが異なる理由

エンジニアのAIミスは通常自己告知します。ビルドが壊れ、テストが失敗し、リンターが警告します。アナリストのミスは逆のことをします。返金を二重カウントするクエリは、きれいで自信に満ちた数字を、正しい単位でフォーマットされた形で返します。どこも間違ったように見えません。ダッシュボードに流れ込み、スライドに、戦略の会話になり、エラーはすでに信頼している数字と照合した人によってのみ捕捉されます。この非対称性が、AIツールを持つアナリストにとってプロンプトエンジニアリングがより重要になる全理由です。ツールは答えを生み出すコストをほぼゼロに下げながら、誤った答えのコストはまったく変えません。

だからこそ、採用すべきスキルはチャットウィンドウの流暢さではありません。AI生成の数値をすべて信頼を得なければならない主張として扱う習慣です。その習慣は優れた分析実践と区別がつきません。AIはそれをスキップしやすくしただけです。成長するアナリストはスキップを拒む人たちです。

数字はクエリより長く生き残る

アナリストがラップトップを閉じた後に起こることを考えてみましょう。SQLは捨てられますが、数字は捨てられません。役員報告書の一行になり、OKRの目標値になり、アラートルールの閾値になります。6週間後、誰もどの純収益の定義がそれを生み出したかを覚えておらず、議論を解決するクエリとっくに消えています。だからこそ、アナリストの規律は一時的な習慣であってはなりません。軌跡を残す種類の習慣でなければなりません。プロンプトで定義を述べ、モデルに前提を記録させ、公開前に照合することは、すべて推論を生き残らせる方法です。アナリストを採用するとき、実際には彼らが残す数字の耐久性を採用しています。

良いプロンプトは厳密な定義である

分析業務での幻覚(ハルシネーション)の削減は、巧みな言い回しではなく具体性と境界線に帰着します。「月別売上を出して」という曖昧な依頼は、モデルに定義を選ばせることになり、曖昧さがある場合は毎回もっともらしく誤った定義を選びます。優れたアナリストは指標、除外条件、信頼できる情報源(source of truth)をプロンプトに書き込み、推測するのではなく反論するよう明示的に許可を与えます。これがアナリストの席におけるAI fluencyです。プロンプトと分析上の厳密さは同じ行為です。報告しようとしている数字が実際に何を意味するかを完全に述べるよう、機械への指示を書くよりも自分自身に強制しています。

定義こそが本当の作業

すべての分析上の議論は、数値的な衣を纏った定義上の議論です。チャーンしたアカウントとは解約したものですか、支払いを停止したものですか、それとも使用閾値を下回ったものですか?「アクティブユーザー」とはログインしたことですか、アクションを取ったことですか、それとも意味のあるアクションを取ったことですか?AIはあなたの代わりにこれらを解決できません。未明示のまま残すと暗黙的に解決します。プロンプトに定義を記載することは官僚主義ではありません。あなたとステークホルダーがずっと異なることを意味していたことを発見する瞬間です。

具体例

月別純売上を求めてみましょう。弱いバージョンはそこで止まります。強いバージョンは「純」を定義し、除外条件を明記し、どのタイムスタンプを月として数えるかを指定し、見つからないものを作り上げるのではなく報告するようモデルに指示します。そして、実際に重要なのはここです。アナリストは、その結果が画面を離れる前に、すでに信頼している数字と照らし合わせて妥当性を確認します。

Prompt
## TASK
Write SQL: net revenue by calendar month for 2025.

## DEFINITIONS
- net revenue = gross - refunds
- Exclude internal test accounts (email domain @acme-internal.com)
- "Month" = orders.completed_at, not created_at

## RULES
- If a column I named does not exist, tell me. Do not guess a name.
- Return the query, then list every assumption you made
  • 優れた例:指標、除外条件、信頼できる情報源を明示し、前提を求め、アウトプットの妥当性を確認し、データが裏付けない数字を疑う。
  • 弱い例:もっともらしいクエリを受け入れ、密かに返金を二重カウントした数字を報告し、誰かが下流で気づくまで気づかない。

クエリを生成した後に、モデルに作成したすべての前提を列挙するよう必ず求めてください。そのリストこそが、数字になる前に誤読された定義が表れる場所です。前提を読むアナリストは自分の画面でエラーを捕捉します。結果だけを読むアナリストは、もし捕捉するとしても会議の場で捕捉します。

優れたアナリストが注意を向ける場所

優れたアナリストがAI課題に取り組む様子を見ると、興味深い瞬間はプロンプトを入力するときではありません。アウトプットで一時停止するときです。結果が返ってきて、クエリはきれいに見えます。しかし、数字をコピーする代わりに立ち止まり、それがおよそ期待したサイズかどうかを問います。桁違いの数字はその一時停止で捕捉されます。疑わしく丸い数字も、前四半期から間違った方向に動いた数字も同様です。ここでドメイン知識とAI fluencyが融合します。ツールが答えを生み出しましたが、いつ疑うべきかを知るのは、すでにビジネスの粗いモデルを頭の中に持つアナリストだけです。プロンプトが問いを設定し、懐疑心が答えを部屋から出すことを許可するかどうかを決めます。

また、ジュニアとシニアのアナリストが最も見えやすく分岐する場所でもあります。ジュニアアナリストはクリーンなクエリがエラーなく実行されたためそれを信頼する傾向があります。シニアは「実行された」と「正しい」を完全に別の主張として扱い、2番目に注意を向けます。AIはその差を広げました。きれいだが間違ったクエリを簡単に生み出しながら、それが間違っていることに気づくことに対しては何もしないからです。

実際に効果のあるベストプラクティス

  • 聞く前に定義する。指標の定義、除外条件、時間粒度をプロンプトに記載する。曖昧さが誤った数字の生まれる場所であり、プロンプトはそれを解決するかモデルに不適切な形で解決させるかを選ぶ場所です。
  • 「わかりません」と言う許可を与える。「データが不十分です」や「その列は存在しません」と応答するよう指示する。拒否が許可された答えである場合、モデルの幻覚は大幅に減ります。
  • 前提を求める。前提を列挙させる。そこで誤読された定義が報告される数字になる前に見えます。
  • すべてのアウトプットをすでに信頼している数字と照合する。照合しない数字は丸め誤差ではなく、発見です。
  • 信頼できる情報源を保持する。プロモデルが便利なものに自由に結合できないよう、正規のテーブル、ビュー、または指標レイヤーをプロンプトに明示する。

アナリストのコア習慣はクエリを書くことではありません。答えが照合に耐えるまで信頼を拒否することです。自信に満ちているが誤解を招く集計値に疑問を呈する候補者は、10のクエリを生成して一つも確認しない候補者よりも価値があります。

よくある失敗パターン

  • 曖昧な指標:定義のない「売上」。モデルが定義を静かに選び、あなたはそれを知らずにその選択を引き継ぎます。
  • クエリがきれいに見えるため数字を信頼する。誤った定義でのきれいなSQLはやはり誤った答えです。きれいなコードがそれを危険にする理由そのものです。
  • 既知の良い数字と照合しないため、ミスが事実として届き、ステークホルダーの直感がスライドに異議を唱えるときにのみ表面化します。
  • モデルに検証できない列や結合を作り上げさせ、アナリストが想定する意味とは異なるデータについて報告する。

これらはいずれも珍しいことではありません。分析が常に間違ってきた通常のパターンが加速しているだけです。違いは速度です。AIツールはもっともらしく誤った答えを数秒で生み出せるため、残る唯一の保護はアナリストがそれを疑う規律です。その規律は面接の会話でスクリーニングできる性格特性ではありません。作業習慣であり、作業習慣を観察する唯一の正直な方法は作業を見ることです。

プロンプトはステークホルダーとの会話が行われる場所

定義をプロンプトに書き込む2番目の静かな利点があります。本来行われるべきだったステークホルダーとの会話を強制することです。プロダクトマネジャーが「今四半期のチャンネル別コンバージョン」を求めるとき、それをAIツールにそのまま転送するアナリストは最も重要なステップをスキップしました。どのコンバージョンイベントがカウントされますか?「今四半期」は財政年度ですか暦年ですか?チャンネルはファーストタッチですかラストタッチですか?プロンプトを書くことはその問いが避けられなくなる瞬間です。なぜならモデルが答えを必要とし、アナリストが提供しなければならないからです。優れたアナリストはそれをリクエスト者の代わりに推測するのではなく戻って確認するプロンプトとして扱います。

だからこそ最強のアナリストはしばしばプロンプトと明確化の問いを同じ息で生み出します。モデルに渡す仕様は、ほぼそのまま、依頼した人と確認すべき仕様です。このツールは、ステップを真剣に書くことで、人々がかつてスキップしていたステップをスキップできないものに静かに変えました。リクエストをそのまま貼り付けるのではなく、データに触れる前に曖昧な依頼を反射的に絞り込む候補者は、まず誤った数字が生み出されることを防ぐ正確な本能を見せています。

プロンプトで解決された曖昧さはステークホルダーと共に解決された曖昧さです。「コンバージョン = 完了したチェックアウト、暦四半期、ラストタッチチャンネル」とリクエストに書くアナリストは、その同じ動作で、リクエスト者が偶然に任せていたと気づいていなかった3つの決定を浮き彫りにしました。

AI fluencyはピラーであり後付けではない

5ピラーモデルでは、AI fluencyは認知、ドメイン、状況判断、行動能力と並んで位置し、いずれかを置き換えるものではありません。アナリストにとってこれが重要なのは、ドメイン判断力なしのAI fluencyは役に立たないどころか悪化させるからです。誤った答えをより速く、より自信を持って生み出します。二重カウントされた返金を捕捉するアナリストは、純収益がおよそどれくらいのはずかをすでに知っているからできます。ツールがその本能を与えたのではなく、それを持つことをより価値あるものにしました。だからこそ、これをAI fluencyを独立したピラーとして評価するものとして扱い、良いアナリストがすでに必要とするドメインスキルの上でスコアリングします。決してその代わりではありません。

評価の方法

プロンプトトリビアクイズではテストできません。AIを取り上げることもテストできません——それはもはや誰もそのようにこなさない課題を測定するだけです。ツールを使えた状態で現実的な分析課題を候補者に与え、指標を定義するかどうか、誤解を招く集計値を捕捉するかどうか、実際に耐えられる数字の後ろに立てるかどうかを観察します——これがAI Sandboxアセスメントの機能です。完全なデータアナリストアセスメントがカバーする内容、ソフトウェアエンジニアの兄弟職種との違い、そしてこれがAI採用の正直なテストである理由をご覧ください。

最良のアナリストはAIの答えを、驚くべき数字と同様に扱います。照合されるまで有罪です。その本能こそが——プロンプトの言い回しではなく——誤った数字を役員会から遠ざけるものです。
Prompt engineeringData analysisAI fluencyAI Sandbox
J

執筆者

Jakir Patel · Founder, Hanzomon

Building H-Evaluate — AI-native, quality-gated hiring assessments. Writes about assessment engineering, hiring integrity and compliance-first AI.

実践に移す

いま読んだ内容を採用の意思決定に変えるための、評価・職務別ガイド・計算ツール。

よくある質問

データアナリストにとってプロンプトエンジニアリングが特に重要な理由は?

アナリストのアウトプットは誰かが意思決定に使う数字だからです。モデルがわずかに誤った定義でクエリを書き、アナリストがそれを捕捉しなければ、そのミスは事実として届きます。プロンプティングスキルと分析的判断力は同じ筋肉です。指標を厳密に定義し、すでに信頼している数字と照合するまで結果を疑い続けること。

AIモデルが列や数字を作り上げるのを防ぐ方法は?

定義、信頼できる情報源、境界線をプロンプトに記載し、推測するのではなく「その列は存在しません」や「データが不十分です」と言えるよう明示的に許可します。そのアウトプットをすでに信頼している数字と照合し、どこかに送る前に確認します。拒否は許可されなければなりません。照合は交渉の余地がありません。誤った定義でのきれいなクエリはやはり誤った答えです。

弱い分析プロンプトと強い分析プロンプトの違いは何か?

弱いプロンプトは「月別売上」を求め、モデルに定義を選ばせます——もっともらしく、しばしば誤った定義を選びます。強いプロンプトは指標、除外条件、時間粒度、信頼できる情報源をリクエストに書き込み、モデルに前提を列挙させ、見つからないものへのフラグを許可します。仕様が作業を担い、言い回しは担いません。

データアナリスト職のプロンプトエンジニアリングを評価するにはどうすればよいか?

AI Sandboxで現実的な分析課題を使います。本物の問い、現実に近いデータ、AIツールが使える状態です。シグナルは候補者が指標と除外条件を明示するかどうか、自信に満ちているが誤解を招く集計値を捕捉するかどうか、最終的な数字が精査に耐えるかどうかです——プロンプトのテクニックを知っているかどうかではありません。構文クイズは重要な判断力を何も測定しません。

AI fluencyはアナリストのSQL・統計スキルを置き換えるか?

いいえ。その上に乗るものです。アナリストは正しい集計値がどのようなものかを知る必要があります——それこそが誤った集計値を捕捉できる理由です。AI fluencyはツールを厳密な定義に向けてアウトプットを疑う能力であり、それは根底にあるドメイン判断力がすでにある場合にのみ機能します。弱い基礎は自信に満ちた、気づかれないエラーをより速く生み出します。

関連記事

あなたの求人票で試す

アーリーアクセスのウェイトリストに登録し、実際の求人でH-Evaluateがアセスメントを生成する様子をご覧ください。

あなたの求人票で試す