何が起きたか:Claude Codeの責任者が「プロンプトエンジニアリングはさほど重要ではない」と語った
Search Engine Journalの記事(見出し:「Head Of Anthropic’s Claude Code Says Prompt Engineering Not That Important(AnthropicのClaude Code責任者、プロンプトエンジニアリングはさほど重要ではないと語る)」)は、Y CombinatorのDiana Hu氏が、AnthropicでClaude Codeの作成者であり責任者であるBoris Cherny氏にインタビューした内容を伝えています。記事によれば、Cherny氏はClaude Codeが一般に理解されているよりも高い能力を持っていると述べ、プロンプトエンジニアリングは大部分において重要ではないと語ったとされています。
さらに記事は、Claudeは「考えすぎ(overthinking)」を必要としないため、Claude Codeのユーザーは、XやLinkedInのAIインフルエンサーのフォローを外したほうがよいとCherny氏が示唆した、とも伝えています。かなり踏み込んだ言い方ですが、この発言の背景には、Cherny氏が繰り返し強調していた「モデルの実力は多くの人が想定しているより上にある」という認識があります。
その例として記事が紹介しているのが、Anthropic社内でバイラルになったという実験です。あるエンジニアがClaudeに、OpenCV(Open Source Computer Vision Library。画像処理と機械学習向けに数千のリアルタイム画像処理アルゴリズムを収めたオープンソースライブラリ)へのアクセスを与え、絵を描くよう指示したところ、Claudeは実際に描いてみせたといいます。記事はこれを「まったく予期されていなかった能力」だとしています。この逸話の趣旨は、Claude Codeが持つ能力は「プロンプトエンジニアリング」の必要性をはるかに超えている、というメッセージを伝えることにあったと記事は整理しています。
詳細①:重要なのは「少し難しすぎる課題」と「検証(verification)の手段」
インタビューでDiana Hu氏は、モデルの潜在能力を引き出すプロセスであるmodel elicitation(モデル・エリシテーション)について質問しています。記事に掲載された質問は、要旨としては「その大きな研究領域がmodel elicitationですよね。モデルのあらゆる能力を見つけ出し、正しいことをするよう頼むのがうまくなること。人はどうすればそれがうまくなるのか。プロンプトエンジニアリングはまだ多く必要なのか、それとも変わりつつあるのか」というものです。
これに対するCherny氏の答えを、記事は次のように引用しています。「1年ほど前、最も人気のある求人のひとつがプロンプトエンジニアだったのを覚えている。それがやがて変わって、コンテキストエンジニアのようなものになったと思う。こうした波のようなものがあって、来ては去っていくのだと思う(“I remember like a year ago, one of the most popular job openings was prompt engineer. And then it kind of changed and then I think it became like context engineer. So there’s these kind of waves of it, I think these will kind of like come and go.”)」。
そのうえで、Cherny氏は今問われているスキルをこう定義しています。「最近のスキルはプロンプトエンジニアリングというよりも、少し難しすぎるように思える課題をどうやってClaudeに与えるか、そして作業の途中でClaudeが自分の成果を検証できるようにするにはどうすればよいか、を考えることにある(“I think the skill nowadays is less about prompt engineering and more about figuring out how do you give Claude a hard task that seems a little bit too hard? And then how do you make it possible for Claude to verify its work along the way?”)」。
そして決定的な一文が続きます。「そして検証こそ、人々がおおむね正しくできていない、単独で最も重要なことだと思う(“And the verification, I think, is probably the single most important thing that people do not get right, largely.”)」。つまり記事が伝えているのは、指示文を磨く作業の比重が下がったという話であって、AIに何を渡すかがどうでもよくなったという話ではありません。渡すべきものの中身が「巧妙な言い回し」から「難しい課題＋成果を確かめる手段」へ移った、という主張です。
詳細②:ElectronアプリをSwiftへ書き換えさせた実例と、その指示文
この主張を裏づける実例として、記事はCherny氏が語った具体的な作業を紹介しています。Cherny氏はClaude Tag(Slack内でエージェントとして動作するClaude)にMacの仮想マシンへのアクセスを与え、複雑なプログラミング課題を与えました。その課題とは、Claudeのデスクトップアプリを、オープンソースのElectronフレームワークから、Appleのネイティブなプログラミング言語であるSwiftへ書き換えるというものです。記事は、Cherny氏が使ったのは指示や制約を考えすぎない、単純で率直なプロンプトだったと説明しています。
実際の指示は次のように語られています。「それで私はこう言った。さて、やってほしいのはElectronアプリをSwiftで書き直すことだ。Mac仮想マシンでElectronアプリを実行し、スクリーンショットを撮り、それからピクセル単位でSwift版と比較してほしい。終わるまで止まるな(“I want you to rewrite the Electron app in Swift. I want you to run the Electron app in the Mac virtual machine, screenshot it, and then look pixel by pixel, compare it to the Swift version. Don’t stop until you’re done.”)」。
注目したいのは、この指示の大半が「どう書くか」ではなく「どうやって自分の成果を確かめるか」に費やされている点です。仮想マシンで動かす、スクリーンショットを撮る、ピクセル単位で比較する。これらはすべて、モデルが自分の出力が正しいかどうかを自力で判定するための仕組みです。Cherny氏自身も続けてこう述べています。「これはまさに、モデルが今日それをやれる例のひとつだ。ただやらせればよく、凝った仕掛けは必要ない。/goalも要らないし、/loopも要らない。それらは助けにはなる。しかし本当に必要なのは、モデルに課題を与え、行き詰まらないように成果を検証する手段を与えることだけで、あとはただ進んでいく(“So this is really one of those examples where the model can do it today, you just have to let it do it, and you don’t need the fancy stuff. You don’t need /goal, you don’t need /loop. These help. But really all you need is give the model the task, give it a way to verify the output of its work so it doesn’t get stuck, and it’ll just go.”)」。
記事はおまけとして、この作業中にClaudeが自ら社内にSlackチャンネルを作り、数分ごとに進捗のスクリーンショットを投稿して、いわば実況中継(live blog)を始めたというエピソードも伝えています。インタビュアーのHu氏は、これほど複雑なプログラミング課題が単純なプロンプトで達成されたことに驚きを示した、と記事は記しています。
背景:「上位1%」になる方法と、ベテランほど陥る「過剰仕様」
Hu氏は続けて、Anthropicの利用者がどうすればClaude Codeをより使いこなせるようになるのかを尋ねています。質問は「ここで上位1%のClaudeユーザーになれる人を分けているものは何か。どうすれば人はBorisのようにClaudeを使えるようになるのか(“What is separating the people here that can become the top 1% Claude users? How can people learn to use Claude like Boris?”)」というものでした。
Cherny氏の答えは、まず情報源の選び方から入ります。「たぶん、LinkedInのインフルエンサーの言うことを聞かないこと。Twitterを読まないこと(“Maybe like, don’t listen to the LinkedIn influencers. Don’t listen to, don’t read Twitter.”)」。理由として挙げられているのは、「誰もが『ひとつの奇妙な裏技』のようなものを探しているが、そんなものは存在しない、そういうものは何もない(“everyone’s looking for like the one weird trick to do it. That doesn’t exist, there’s nothing like that.”)」という認識です。
では何をすべきか。Cherny氏は手順としてこう述べています。「モデルの動き方としては、経験的にアプローチしなければならない。難しすぎる課題を与えなければならない。自分がその作業をやるとしたらそうするのと同じように、成果を検証する道具を与えなければならない。どこで詰まるかを見て、それを直さなければならない。よりよいプロンプトで直すか、スキルで直すか、あるいはモデルに文脈が足りないのならMCPを与えて必要な文脈を引き込めるようにするか。だいたいそれだけだ」。記事は、この「経験的に(empirically)」という言葉について、経験を通じて、そして物事がどう運ぶかを観察することによって、という意味だと補足しています。
Hu氏が「単純に聞こえる」と反応したのに対し、Cherny氏は「人々は少し考えすぎる傾向があると思う(“people tend to overthink it a little bit”)」と応じ、過剰な作り込みこそが失敗の型だと続けます。「人々は過剰に作り込む傾向があると思う。多くの点で、過去にシステムを作ってきたときはそうするしかなかったからだ。だから、何年も、何十年もコードを書いてきたエンジニアを見ていると、これは本当に、本当によくある失敗パターンで、過剰に仕様化しようとし、過度に具体的であろうとし、自分がやったであろうやり方とまったく同じやり方でモデルに作業をさせようとする。そしてそれは、モデルの動き方ではない(“this is a really, really common failure mode, is trying to over-specify, and it’s trying to be overly specific, and get the model to do the task exactly the way that you would have done it. And that’s just not the way the model works.”)」。
そのうえでCherny氏は「多くの人がこれを学びほぐしつつあると思うし、それは旅のようなものだ。これを同僚に接するように扱うにはどうすればよいかを見つける旅だ。今のモデルはそのくらいの知能水準にあると思う」と締めています。記事末尾のTakeaways(要点)としてまとめられているのは、次の6点です。
- プロンプトエンジニアリングは、Claudeに明確な指示と成果を検証する手段を与えることに比べれば重要度が低い
- Claudeは、多くの「プロンプトエンジニアリング」の小技がもはや不要な水準まで進歩している
- Claude Codeは、多くのユーザーが認識しているよりも多くのことができる
- Claude Codeにはもっと難しい課題で挑ませること
- 試してみて、どう運ぶかを見ることは有用でありうる
- プロンプトを考えすぎないこと
実務への影響:SEO・コンテンツ担当者はこの発言をどう読むか
ここから先は記事本文に書かれている内容ではなく、Scale Basics編集部による一般的な実務上の解釈です。Cherny氏の発言はコーディング用途のClaude Codeについてのものであり、コンテンツ制作やSEO業務にそのまま当てはまると断定できるものではありません。そのうえで、読み替えられる論点は3つあると考えます。
第一に、社内で「効くプロンプト集」を作る工数の一部を、AIに渡す材料の整備へ振り向ける余地があります。Cherny氏が挙げた修正手段のうちプロンプトの改善は3つのうち1つに過ぎず、残りは手順(スキル)の整備と、足りない文脈を取りに行ける経路(MCP)の用意でした。コンテンツ制作に置き換えれば、指示文の言い回しよりも、自社の実測データ、過去記事の在庫、表記ルール、想定読者の定義といった材料が揃っているかが成果を左右する、という話になります。
第二に、そして最も重要なのが検証です。Swiftの例では、スクリーンショットを撮ってピクセル単位で比較するという明確な正解判定が指示に組み込まれていました。コンテンツ制作でこれに相当するのは、出力を人が読んで何となく良し悪しを決めることではなく、機械的に判定できる基準を用意することです。記事中の数値が一次情報と一致しているか、出典URLが実在して本文の主張と対応しているか、指定した構成や文字数の条件を満たしているか。こうした判定が自動で回らなければ、AI側は自分がどこで間違えたのかを知る手段を持ちません。
第三に、渡す課題の難易度です。実務では、AIに任せる範囲を最初から小さく切り分けすぎて、結局は人が全体を組み立て直しているケースが少なくありません。過剰な仕様化がベテランほど陥りやすい失敗パターンだというCherny氏の指摘は、長く手作業で品質を担保してきたコンテンツ制作の現場にも当てはまる可能性があります。
今日からできる確認手順
この章もソースの記事には書かれていない、Scale Basics編集部による実務上の補足です。Cherny氏が述べた考え方を、自社の運用に当てはめて点検するための手順として読んでください。
- 直近1か月でAIに出した指示を3件抜き出し、指示文の分量と、一緒に渡した一次情報(自社データ、既存記事、規定類)の分量を比べる。指示文ばかりが長く、材料が薄いなら比重の掛け方を見直す余地があります。
- その3件について、出力が正しいと判断した根拠を書き出す。担当者の目視だけが根拠になっているなら、検証の仕組みが存在しない状態です。
- その判定のうち、機械が回せる形に置き換えられるものを洗い出す。数値と一次情報の突き合わせ、リンク切れの確認、表記ゆれの検出、禁止表現の混入チェックなどは自動化しやすい領域です。
- いつもより一段難しい課題を1件だけ試す。範囲を狭めた作業依頼ではなく、成果物の完成条件と検証手段を渡したうえで、まとまった単位で任せてみる形です。
- 詰まった箇所を記録し、指示文の改善で直すのか、手順として明文化するのか、参照できるデータを増やすのかに分類する。Cherny氏が挙げた3つの修正手段に対応する切り分けです。
所感
ここからは記事本文にはない、Scale Basics編集部の見解です。この話題は「プロンプトエンジニアリングはもう不要になった」という要約だけが広まりやすい形をしています。しかし原文を読むと、Cherny氏は指示の質そのものを否定してはいません。詰まった箇所を直す手段として「よりよいプロンプト(better prompting)」を最初に挙げていますし、Swiftの例で使われた指示も、短いながら達成条件と検証方法を明確に含んだものでした。無くなったと言われているのは、モデルの挙動を無理やり誘導するための小技であって、何をどう頼むかを考える仕事そのものではない、と読むのが妥当だと考えます。
SEO業界の文脈で言えば、価値の置き場所が「プロンプト集の切り売り」から「材料と検証手順の整備」へ動いたという話に近いと感じます。裏技を集めることに投じた時間はモデルが世代交代するたびに目減りしますが、自社の一次データを整理し、品質の合否を機械が判定できる形に落とし込んだ資産は、どのモデルを使っても効き続けます。
一方で、受け取り方には留保も必要です。これはAnthropicの当事者が自社製品について語った内容であり、第三者による検証結果ではありません。また語られている作業はコーディングであって、正解の判定が比較的はっきりしている領域です。コンテンツの良し悪しはピクセル単位の比較のようには判定できないため、「検証の手段を渡す」という原則をどう具体化するかは各社が設計するしかなく、そこを詰めないまま難しい課題だけを丸投げすれば、確認できない成果物が積み上がることになります。原則は参考になりますが、自社の検証基準づくりは省略できない、というのが編集部の見方です。
まとめ
・AnthropicでClaude Codeの作成者であり責任者を務めるBoris Cherny氏が、Y CombinatorのDiana Hu氏のインタビューで、プロンプトエンジニアリングは大部分において重要ではないと語ったと、Search Engine Journal(Roger Montti氏、2026年7月30日付)が報じた
・Cherny氏は代わりに、少し難しすぎるように思える課題をClaudeに与えることと、作業の途中でClaudeが自分の成果を検証できるようにすることを挙げ、検証こそ人々がおおむね正しくできていない単独で最も重要なことだと述べている
・実例として、Slack内でエージェントとして動作するClaude TagにMac仮想マシンへのアクセスを与え、ClaudeデスクトップアプリをElectronからSwiftへ書き換えさせた作業が紹介された。指示は仮想マシンで実行し、スクリーンショットを撮り、ピクセル単位で比較し、終わるまで止まるなという単純なものだった
・上位1%のユーザーになる方法としてCherny氏が挙げたのは、インフルエンサーの発信を追わず経験的にアプローチすること、詰まった箇所をよりよいプロンプト・スキル・MCPのいずれかで直すことであり、ベテランほど陥る失敗パターンとして過剰な仕様化を挙げている
・SEO・コンテンツ実務への読み替えとしては、指示文を磨く工数の一部を、渡す材料の整備と、機械的に合否を判定できる検証基準づくりへ振り向ける形が考えられる(この読み替えはScale Basics編集部の解釈)
よくある質問
Q1: 「プロンプトエンジニアリングはもう不要になった」ということですか?
記事が伝えているのは、プロンプトエンジニアリングの重要度が相対的に下がったという主張であって、指示の中身がどうでもよくなったという話ではありません。Cherny氏は、モデルが詰まった箇所を直す手段として「よりよいプロンプト」を最初に挙げていますし、実例として紹介されたSwift書き換えの指示も、達成条件と検証方法を明確に含んだものでした。記事のTakeawaysでも「プロンプトエンジニアリングは、Claudeに明確な指示と成果を検証する手段を与えることに比べれば重要度が低い」という比較の形で整理されています。不要になったと表現されているのは、モデルの挙動を誘導するための小技の類です。
Q2: Cherny氏が最も重要だと述べたのは具体的に何ですか?
検証(verification)です。Cherny氏は「最近のスキルはプロンプトエンジニアリングというよりも、少し難しすぎるように思える課題をどうやってClaudeに与えるか、そして作業の途中でClaudeが自分の成果を検証できるようにするにはどうすればよいかを考えることにある」と述べたうえで、「そして検証こそ、人々がおおむね正しくできていない、単独で最も重要なことだと思う」と語ったと記事は伝えています。実例として挙がったElectronからSwiftへの書き換えでは、仮想マシンでアプリを実行してスクリーンショットを撮り、ピクセル単位で比較するという、モデル自身が正誤を判定できる手段が指示に組み込まれていました。
Q3: SEOやコンテンツ制作でAIを使う場合、具体的に何から変えればよいですか?
記事はコーディング用途のClaude Codeについての内容で、コンテンツ制作向けの推奨事項は書かれていないため、以下はScale Basics編集部による一般的な実務上の補足です。まず、出力の合否を担当者の目視だけで決めていないかを点検し、機械的に判定できる基準へ置き換えられる部分を洗い出すことをおすすめします。記事中の数値が一次情報と一致しているか、出典URLが実在して本文の主張と対応しているか、表記ルールや構成の条件を満たしているかといった項目は自動チェックに乗せやすい領域です。そのうえで、指示文を磨く工数の一部を、自社の実測データや既存記事、用語規定といった「渡す材料」の整備に振り向けると、AIが自力で軌道修正できる余地が広がります。
出典:Head Of Anthropic’s Claude Code Says Prompt Engineering Not That Important(Search Engine Journal、Roger Montti氏、2026年7月30日)https://www.searchenginejournal.com/head-of-anthropics-claude-code-says-prompt-engineering-not-that-important/584286/
