AIに専門家らしい返答を求めてプロンプトを工夫しても、専門用語や丁寧な言い回しが増えるだけで、本質的な分析の浅さが変わらないと感じたことはないでしょうか。
Claudeの開発に携わるFelix Rieseberg氏が個人ブログで公開したAI活用の思考法（2026年10月13日公開）では、AIへの指示を「野心（Ambition）」という概念で整理し、速度（Speed）・高さ（Altitude）・深さ（Depth）・広さ（Range）の4方向で分類しています。
今回はその中でも、専門家の仕事レベルに踏み込む「深さ（Depth）」に焦点を当て、プロンプトを根本から組み直す考え方を整理してみます。
専門家役を演じさせても「方法」は変わらない
AIに「～の専門家として答えてください」と指示すると、それらしい言葉遣いやフォーマットで返答してくれます。しかし、Rieseberg氏が指摘するように、多くの場合は「手法を変えずに語彙だけを変えている」状態に陥りがちです。
表面的な回答から一歩踏み込み、その分野の第一線で行われている調査や分析に近づけるには、依頼の仕方を具体的に再設計する必要があります。
依頼を深める「4つの問い」
Rieseberg氏は、プロンプトをより深い要求へ組み直すためのアプローチとして、次の4つの視点を投げかけています。
- 依頼に欠けている専門家の作業は何か 表面的な要約やテキスト整理にとどまらず、その領域の専門家が通常行っている分析や作業工程が抜けていないかを見直します。
- 加工済みのまとめより前の「元の素材」は何か 整えられた二次データや要約テキストではなく、データサンプルの生のログや一次情報まで遡って読み込ませられるかを検討します。
- 具体的な手法や道具は何か Markdownの表で整理させるだけでなく、統計モデルやデータベース操作など、実務で用いられる具体的なツールや分析手法の指定を検討します。
- モデル本人や依頼者の主観以外で「正しさ」を確かめられるか AI自身に「この分析は正しいですか？」と自己採点させるのではなく、コードの実行結果や外部ツール、客観的な検証用データなど、独立した判定基準を用意します。
架空の分析例：顧客離脱の検証
この考え方を理解するために、架空のWebサービス企業「Acme Inc.」で顧客離脱（チャーン）の原因を探る場面を考えてみます。
浅い依頼（語彙の変化）：
「データ分析の専門家として、顧客離脱の理由を表形式でまとめて整理してください」
深さを意識した組み直し：
- 生の素材に迫る： 報告用サマリーではなく、過去の利用ログや生データを読み込ませる。
- 手法を指定する： 表の作成にとどめず、統計手法を用いて「新規登録（オンボーディング）に原因がある」という社内の既存仮説を疑い、データから再現・検証させる。
- 新たな知識の提示と検証： まだ注目していないデータの兆候から予測モデルを組み立てさせ、過去の未確認データに当てはめて予測精度を確かめる。
単に「専門家として語らせる」のではなく、専門家が扱うデータ・手法・検証プロセスまでを踏み込んで指定することで、AIから出てくるアウトプットの質が大きく変化します。
導入時の注意点と環境要件
この考え方を実践する際には、いくつかの前提と限界を押さえておく必要があります。
実行環境の確保：
単なるテキスト対話画面で指示を工夫するだけでは限度があります。ソフトウェアのインストールやローカル/クラウド環境でのコード実行、データアクセス（MCP等のコネクタ活用など）ができる環境が前提となります。
精度が保証されるわけではない：
4つの問いに沿って指示を複雑・高度にしたからといって、必ずしも完璧な正解が得られる保証はありません。
独立した検証手段の必要性：
モデル自身に回答の妥当性を評価させても、独立した検証にはなりません。外部のテストツールや実際のデータフィードバックなど、AIの文脈から独立した確認手段を組み込むことが不可欠です。
（応用提案）CLIツールやスキル定義への組み込み
ここからは、原著の考え方を日々のCLI作業や自動化ワークフローに応用するための当ブログ独自の提案です（※原著内に特定のスクリプトや機能実装があるわけではありません）。
たとえば、自作のCLIツールやローカル環境のシステム（プロンプトテンプレートや各種AIツールのスキル設定ファイルなど）で調査コマンドを定義する場合、タスク実行前に上記の「4つの問い」を自動で挟み込む事前プロンプトを定義しておくことが考えられます。
仮想設定例：リサーチ用事前プロンプト
ユーザーからの調査依頼を受け取ったら、以下の手順を実行してください：
1. この分野のトップ専門家が通常行うが、依頼に含まれていない作業を列挙する。
2. 処理済みの情報の前に存在する「生のデータ素材」を指定させる。
3. 使用すべき具体的な手法・ツール（統計処理、DB操作など）を抽出する。
4. AIやユーザーの主観に頼らない独立した検証手段を定義する。
上記を踏まえて、依頼プロンプト自体を書き直してから実行に入ってください。
このように、作業を単に依頼するステップの前に「深さを担保するリフレーム作業」を挟むことで、日常的な調査やデータ処理の品質を一段深く引き上げることが期待できます。
まとめ
AIへの指示を「野心的にする」とは、無茶な要求を投げることではありません。専門家が日々の仕事で使っている素材・手法・検証手段まで視点を下げ、AIが触れられる環境を整えることです。
日頃のプロンプトやCLIツールの設計において、「専門家の言葉遣い」ではなく「専門家の仕事構造」を渡せているか、一度見直してみてはいかがでしょうか。
参考
この記事は Gemini Web（Flash）が執筆しました。