はじめに
GMOコネクトの永田です。
「engineer to delegate to」というシリーズで、Claude に大きめの仕事をまるごと委ねた話を何本か書いてきました（Java のメジャーアップを1日で、消えたドキュメントの環境再現を、など）。反応はうれしいのですが、ほぼ毎回こう言われます。「そのときの prompt、全部ちょうだい」
気持ちはわかります😇
私も人の成果を見たら同じことを言いますし、プロンプト全文公開の記事も自分で何本か出しています。そのうえで正直に書くと、その prompt をそのまま別の人・別の案件に貼っても、たぶん同じ成果は出ません。 コピペで再現するものではないんです。
この記事は、ある案件（受領したソースから AI に設計書一式を起こしてもらう仕事）をふり返り、「prompt をほしがる人がよく持っている2つの誤解」を解きほぐして、「では何が効いていたのか」を整理する記録です。否定ではなく、「ほしいのはそこじゃなくて、たぶんこっちですよ」という翻訳のつもりです。
シリーズの「何を任せたか」の一歩手前、「なぜ任せられたのか」を、Anthropic の AI Fluency Framework（4Ds）で整理します。先に言うと、これは AI 固有の話ではなく、人に仕事を頼むときにも効く汎用的な話です。案件の具体は伏せ、「FE/BE が分離した受託 Web」とだけ捉えてください（ドメインを伏せても通じること自体が、今日の主題でもあります）。
先にまとめ
結論：成果を決めるのは prompt の文面ではなく、依頼する側の「解像度」と「判断」。これは AI でも人でも同じです。
| よくある誤解 | 実際に効いていたもの |
|---|---|
| ① プロンプトの文面が成果の「本体」だ | プロンプトは作業の "足跡"。本体は依頼する側の頭の中にある ToBe（完成形）と判断基準 |
| ② うまく書く "呪文" のテクニックがある | 効くのは言い回しではなく「何を・なぜ」。とくに Why（背景・理由）を一緒に渡せているか |
- 起こした設計書は11ファイル、AI への指示は53回、期間は実質2日ほど
- 拠り所は Anthropic の「AI Fluency Framework（4Ds）」。prompt はそのうち Description（説明）の "一部" にすぎません
- Anthropic 自身も Opus 4.7 のベストプラクティスで、Claude を「a capable engineer you're delegating to（委任する相手の有能なエンジニア）」と表現しています
何をしたのか（背景）
顧客から「ソースコードはあるが設計書がほとんどない。運用保守のために全体像を把握できる資料がほしい」という相談を受けました。設計意図そのものは推測になるので踏み込まず、ソースから確実に読み取れる範囲で、システムアーキテクチャ・API 仕様（OpenAPI）・API ごとのシーケンス図・ER 図・画面一覧・設定構成あたりを、運用保守で使えるレベルまで起こす、という方針です。
これを Claude Opus に委ねました。たしかに速かったです。だから冒頭の「prompt ちょうだい」につながるわけですが、ここから先が本題です。
誤解1: プロンプトの文面が「本体」だ
いちばん多い誤解です。「良い成果が出た＝良いプロンプトがあった」と考えて、文面そのものをほしがるパターンです。
でも実際には、プロンプトは先に書いた "設計図" ではなく、考えながら進んだ結果として残った "足跡" でした。
これは Zenn の Kenichi 氏の記事「解像度が低いのに、プロンプトなど書けるわけがない。」で言われていることがそのままで、自分の中に「何を "良い" とするか」の基準（＝解像度）がなければ、AI はそれっぽい平均点を返してきます。完璧なプロンプトを先に書こうとする発想自体が逆で、解像度の高いゴールが先にあって、そこへ近づける過程でプロンプトが積み上がっていきます。
今回でいうと、最初の依頼の時点で「何を作るか」がかなり具体的に決まっていました。作る設計書の一覧だけでなく、「どのドキュメントを何の "おおもと"（正）とするか」という役割分担まで頭の中にありました。同じ情報を複数のドキュメントに重複させず、「この情報はここを見れば確実」という置き場所を一つに決める、という意味です。
- この一覧表は OpenAPI の description に全部書けるはず。別表で持つと二重メンテになる
- ER 図は関連だけ図にする。各項目の詳細はテーブル定義（DDL）に任せて、図には持たない
- この情報は俯瞰の本編ではなく別紙へ。最初に読む人が迷子になるので
こういう「どこに何を書き、どこには書かないか」を依頼する側が握っていたから、AI は個々のドキュメントを "全体の一部" として埋められました。ここが曖昧なまま個別に頼むと、ドキュメント同士が重複・矛盾して、結局メンテ不能になります。これは AI に限った話ではなく、複数人に章を分担して書かせるときに起きることと同じです。
プロンプトの文面だけ渡しても、この「完成形の解像度」は付いてきません。だからコピペでは再現しないわけです。
誤解2: うまく書く "呪文" があるはずだ
昔の「プロンプトエンジニアリング」のイメージで、特別な言い回しや記号の並べ方で出力が劇的に変わる、と思っている人もいます。現在の Claude Opus に対しては、これはむしろ逆効果になりがちです。一字一句を真似ることに意味はありません。
効いていたのは言い回しではなく、「何を・どの粒度で・なぜ」という中身です。とくに効果が大きかったのが、指示に毎回「なぜそうしたいか（背景・理由）」を添えていたことでした。
たとえば、こういう書き方です（業務名は伏せた抽象表現にしています）。
- 「別表は作らないでほしい。二重メンテになるので。どれを "おおもと" にするかを意識して」
- 「シーケンス図の登場人物（アクター）を全図で統一して。関連しないアクターも明示したいから」
- 「単純な登録・参照・更新・削除はシーケンス図を省いていい。ただし "なぜ省いたか" を書いて。記載漏れなのか意図的なのかを後から区別したいので」
「何をしてほしいか（What）」だけでなく「なぜか（Why）」を渡すと、AI は指示の意図に沿って、指定していない部分まで自分で補ってくれます。方向がずれても自己修正が効くので、レビューの往復が減ります。これは丁寧な言い回しとは別物で、判断の前提を共有しているかどうかの違いです。
そして、Why を渡すというのも AI 固有のコツではありません。チームメンバーに仕事を頼むときと同じで、背景と理由を伝えるほど、期待に近いものが返ってきます。
4Ds で整理すると腑に落ちる
ここまでの話は、Anthropic の AI Fluency Framework（4Ds）にきれいに乗ります。AI とうまく協働する力を4つに分けたもので、Rick Dakan・Joseph Feller 両教授（Ringling College / University College Cork）が提唱し、Anthropic と協働して公開しているものです。
| D | 意味 | この案件での中身 |
|---|---|---|
| Delegation（委任） | 何を任せ、何を任せないか | 大量のソース読解と下書き生成は AI へ。「どこまで詳しく書くか」の線引きは人が決めた |
| Description（説明） | ゴールを的確に伝える（プロンプトはここ） | ToBe・制約・原則、そして「なぜそうしたいか」を毎回添えた |
| Discernment（見極め） | 出力の良し悪しを判断する | 「あるべき設計」との差分を違和感として拾い、ソースで裏取りした |
| Diligence（責任） | 使い方と結果に責任を持つ | 受領ソースは非公開（private）リポジトリで管理、推測は断定せず「要確認」に隔離した |
注目したいのは、プロンプトが関わるのは Description の "一部" でしかないことです。「4つの能力のうち1つの、そのまた一部」くらいの位置づけです。残りの大半は、正しい仕事を選び（Delegation）、出力を見極め（Discernment）、責任を持って使う（Diligence）が占めます。
「プロンプトの巧拙が成果を決める」という発想自体が、このフレームの上では的を外している、ということになります。
見落とされがちな Discernment（見極め）── レビューに必要な知識を、任せる前に把握する
4つの中でいちばん手数が多かったのが Discernment（見極め）でした。「その業務（ドメイン）を知らないと、AI の出力の良し悪しなんて判断できないのでは?」とよく聞かれます。
ここは今回のケースで言うと、2種類の知識を分けると整理できます。(a) 一般的な Web（FE/BE 分離）の設計として妥当か（データの持ち方・認証・連携など、業務に依存しない "型" の知識）と、(b) その特定業務の仕様として妥当か（いわゆるドメイン知識）です。
今回作ったのは「運用保守で全体像をつかむための設計書」なので、求められた品質は (a) で足り、(b) は不要でした。私はこの案件の業務もソースも事前に知りませんでしたが、それでもレビューできたのは (b) ではなく (a) ──「FE/BE 分離の Web ならこうあるはず」という "あるべき姿" の引き出しでズレに気づけたからです。たとえば「子テーブルが2つの親の両方に外部キーを持つのは意図的?」「OIDC で結ばれるのは利用者と認証基盤ではなく、認証する側（IdP）と利用する側（RP）の間では?」といった、構造レベルの「おや?」です。
ここで強調したいのは、今回の案件では、(a) は "あれば便利" ではなく必須だったことです。「ドメインを知らなくても判断できた」のではなく「(a) という別の知識で判断していた」が実態で、これがなければレビューそのものが成り立ちません。
そして、ここがいちばん持ち帰ってほしい点です。AI に任せる前に「その出力をレビューするのに、どんな知識・スキルが要るか」を見立てておくこと自体が大事です。今回なら「(a) は要る、(b) は要らない」と分かっていました。これが見えていないと、出てきたものを見極められず、"それっぽいけれど妥当でない成果物" をそのまま受け取ってしまいます。これも AI に限らず、人に仕事を任せるときの「上がってきたものを、誰がどんな知識でレビューするのか?」と同じ問いです。
Anthropic 自身が「委任する相手」と言っている
これは私の主観ではなく、モデルの作り手も同じことを言っています。Anthropic の「Best practices for using Claude Opus 4.7 with Claude Code」には、こうあります。
treat Claude more like a capable engineer you're delegating to than a pair programmer you're guiding line by line
（1行ずつ指示するペアプログラマーとしてではなく、仕事を任せられる有能なエンジニアとして扱う）
さらに、良いタスクの渡し方として、こう書かれています。
task descriptions that incorporate intent, constraints, acceptance criteria, and relevant file locations
（意図・制約・受け入れ基準・関連ファイルの場所を盛り込む）
intent（意図）＝ToBe、constraints（制約）＝制約・原則、acceptance criteria（受け入れ基準）＝出力を判断する基準。今回やっていたことと、ほぼそのまま一致します。AI は "委任する相手" であって、呪文を唱える対象ではない——これを作り手自身が明言している、というのが何よりの裏付けだと思っています。
余談：これ、たぶん新しい知見じゃないんです
書いていて気づいたのですが、この「AI で新しいことをやったように見えて、効いていたのは昔ながらの原則だった」という構造は、前回の記事と同じでした。
前回、E2E 回帰試験を Claude に振った話（「Claude に E2E 回帰試験を振ったら呼び戻され続けた話 ── "段取り八分" を地で行く現場ノウハウ」）を書いたのですが、そこでの結論も「効いていたのは 段取り八分 で、AI だから必要になったものではなかった」でした。試験項目を後から追跡できるようにしておくこと、テストデータの整備、自動化する範囲の線引き——どれも古典的な QA（品質管理）の標準的な準備項目で、新しく参画したメンバーがスムーズにテストするための段取りと、ほぼ同じだったという話です。
今回も構造はまったく同じです。設計書を AI に起こさせて効いていたのは、委任の作法（何を任せ・どう伝え・どう見極めるか）と、設計レビューの勘でした。どちらも AI が登場するより前から、開発の現場にあったものです。
委任については、そもそも古典があります。元 Intel CEO のアンドリュー・グローブは『HIGH OUTPUT MANAGEMENT』(1983) で「フォロー（モニタリング）を伴わない委譲は "放棄" だ（delegation without follow-through is abdication）」と書いています。任せきりにせず、上がってきたものを見極め、結果には自分が責任を持つ。今回 Discernment（見極め）と Diligence（責任）と呼んでいたものは、40 年前から言われているマネジメントの基本そのものでした。AI のために生まれた話ではありません。
新しいのは道具（AI）のほうで、効く原則のほうは古い。むしろ AI が "それっぽい成果" を速く大量に出せるようになったぶん、こういう「昔からある基本」の価値が上がっている、というのが正直な実感です。
「プロンプトちょうだい」への、いまの私の返し方
そんなわけで、最近は「プロンプトちょうだい」と言われたら、こう返すようにしています。
「ログ自体は付録としてお見せします。でも、コピーして効くのはそこじゃないんです。 盗んでほしいのは、この4つの判断のほうです」と。
- 完成形（ToBe）を、"だいたいこんな感じ" ではなく具体的に描けているか（成果物の全体像と、その中で何がどれの "おおもと" になるか、まで）
- 指示に「なぜそうしたいか（背景・理由）」を添えているか（What だけでなく Why を渡せているか）
- 出てきたものを見極めるのに必要な知識・観点が何かを把握し、それを自分やチームが持っているか
- 任せきりにせず、上がってきたものを確かめ、結果に責任を持てているか（不確かなものを "確実" と混ぜない、受領物・機密の扱いも含む）
プロンプトをコピーしても経験はコピーできません。だから本当に渡したい・育てたいのは、プロンプト集ではなく「依頼する側の解像度と判断」そのものなんです。
まとめ
- プロンプトは成果の "本体" ではなく "足跡"。本体は依頼する側の ToBe と判断基準で、コピペでは移らない
- 効くのは言い回しではなく「何を・なぜ」。とくに Why（背景・理由）を渡せているか
- 出力を見極めるのに要る知識を、任せる前に見立てておく。今回は「一般的な Web 設計として妥当か（(a)）」で足り、「業務仕様として妥当か（(b)＝ドメイン知識）」は不要だった
- 4Ds で見ると、prompt は Description（説明）の一部にすぎず、Delegation（委任）・Discernment（見極め）・Diligence（責任）のほうが効いている
- これらは AI 固有のコツではなく、人に仕事を委ねるときの勘所と同じ。AI がそれっぽい成果を速く大量に出せるようになったぶん、「あるべき設計を知っている人」の価値はむしろ上がる
コピペできるのは prompt まで。経験と判断はコピーできません。横展開で本当に渡したい・育てたいのは、そこです。
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、
幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。