海外のRedditコミュニティで、ある投稿が話題になっていました。
タイトルは「Claudeについて、もっと早く知っておきたかった10のこと」。
多くのいいねを集めた人気投稿です。
そして、コメント欄では有志のユーザーがさらに実践的なテクニックを共有しています。
本記事では、その投稿の内容をまとめます。
さらに、コメント欄で評価の高かった補足テクニックも紹介します。
Claudeに限らず、他の生成AIにも応用できる考え方が多く含まれていました。
1. 「わからないなら、わからないと答えて」と先に伝える
Claudeに質問する前に、ひと言添えてみる。
「もし答えがわからなければ、わからないと正直に言ってください」と。
たったこれだけで、いわゆるハルシネーション（もっともらしい嘘）が減るそうです。
AIは沈黙を嫌います。
そして、空白を埋めたがる傾向があります。
だからこそ、こちらから「空白のままでもいい」と許可を与える指示が効きやすいのでしょう。
2. 気の利いた一言よりも、丁寧に書いたシステムプロンプト
短くてキャッチーな一文プロンプトに頼りたくなる。
その気持ちは誰にでもあります。
しかし、長いプロンプトのほうが結果は良くなるようです。
背景や前提条件をきちんと書いたほうが、精度の高い回答を引き出せるとのこと。
近道を探すよりも、最初に手間をかける。
そのほうが、トータルでは早く目的地にたどり着けるという話です。
3. ファイルは貼り付けず、添付する
長いテキストを丸ごとチャット欄にペーストする人は多いものです。
ところが、Claudeは添付されたファイルの中身もきちんと読み取ってくれます。
数千字を超える資料を扱うとき、ファイルとして渡したほうが文脈を把握しやすくなります。
さらに、コンテキストウィンドウの圧迫も避けられます。
4. 「10点満点で書いて」は意味がない
「クオリティを最大限上げてください」「100点の出来で」といった指示。
これらは抽象的すぎて機能しません。
代わりに、求める成果物の具体的な評価基準を伝えるべきだといいます。
たとえば文章を書くなら、以下のような判断軸を分解して提示する。
- 想定読者
- トーン
- 想定される反論
- 避けたい表現
- 文字数の目安
こうした具体的な指示によって、はじめて再現性のある品質が手に入ります。
5. 自分のアイデアを公開する前に、Claudeに批評させる
SNSの投稿、提案書、企画書、プレゼン資料。
世に出す前に一度、Claudeに問いかけてみる。
「ここの弱点はどこか」「読み手はどう反論しそうか」と。
すると、自分一人では気づかなかった穴が見つかることがあります。
投稿してから後悔するより、ずっと建設的な使い方です。
6. モバイルアプリの音声入力は、想像以上に便利
歩いているとき。
運転中。
家事の合間。
そうした場面でモバイルアプリに思いついたことを話しかけてみる。
すると、Claudeが整理された文章にまとめ直してくれます。
頭の中でぼんやりしていたアイデアが、文字として残せる形になる。
この感覚は新鮮です。
タイピングよりも素早く、思考のスナップショットを残せます。
7. カスタムスタイルは、地味だが効く
claude.aiにはカスタムスタイル機能があります。
この機能では、自分の好みのトーンや文章の長さを保存できます。
さらに、説明の粒度なども指定可能です。
毎回同じ前置きをプロンプトに書き連ねる必要がなくなる。
結果として、作業時間が短縮されます。
設定するのに数分しかかかりません。
コミュニティでは「無料で手に入る生産性向上策」と表現されていました。
8. 「5歳児に説明するように」より「懐疑的な相手に説明するように」
物事をやさしく解説してもらうとき、よく使われるフレーズがあります。
「Explain like I’m 5（5歳児にもわかるように）」です。
しかし、この投稿では別のフレーズが推奨されていました。
「Explain like I’m skeptical（懐疑的な相手にもわかるように）」というものです。
5歳児向けの説明はやさしい。
ただし、論点が抜け落ちがちです。
一方、懐疑的な相手を想定するとどうなるか。
AIは前提条件、根拠、反論への備えまで含めた説明を組み立てます。
理解の深さが、まったく変わってきます。
9. デバッグはエラー文を先に、コードを後に
プログラミングの質問で、つい長いコードから貼り付けてしまう人は多いはず。
しかし、順序を変えたほうが診断の精度が上がるそうです。
エラーメッセージを先に提示し、その後にコードを示す。
理由はシンプル。
AIに「これから何を探すべきか」を最初に伝えられるからです。
先に問題点を共有することで、コードの読み方そのものが変わります。
10. 平凡なアウトプットは、平凡なプロンプトの結果
これは投稿のラストを飾った、少し辛口な指摘でした。
「Claudeのアウトプットがありきたりに感じるなら、それはあなたのプロンプトがありきたりだからだ」
道具の責任にする前に、自分の指示を見直してみる。
耳の痛い言葉です。
しかし、もっとも本質的なアドバイスかもしれません。
コメント欄から：さらに役立つ補完テクニック
ここからは、コメント欄で多くの支持を集めた補足テクニックを紹介します。
作業の前に、Claudeから質問させる
ダントツで支持を集めていたのが、このテクニックでした。
「作業を始める前に、私への質問はありますか？」とClaudeに先に聞かせる。
すると、Claudeはこちらが想定していなかった論点を指摘してくれます。
あいまいになっていた条件も、最初に明確になります。
後から大きな手戻りが発生するリスクを、最初の段階で潰せる。
それが大きな利点です。
なお、カスタム設定にこの一文を入れているユーザーが多くいました。
「やって」ではなく「評価して」
Claude Code利用者からの実践的なアドバイスです。
「XYZをやってください」と指示する代わりに、「XYZをやることについて評価してください」と問いかける。
すると、思いつかなかった選択肢が返ってきます。
さらに、潜在的なリスクや別アプローチの提案も得られます。
場合によっては、「やらないほうがいい」という結論に至ることさえあるそうです。
同調しすぎるClaudeに、あえて反論させる
LLMは承認に飢えています。
だから、ユーザーの意見に同調しがちです。
しかし、その性質を放置するとどうなるか。
明らかにおかしい主張にも「おっしゃる通りです」と返してくる場面が出てきます。
そこで、先に伝えておく。
「正当な懸念があるなら遠慮なく反論してください。
ただし、揚げ足取りはしないでください」と。
このひと言で、Claudeはイエスマンから議論相手に変わります。
複雑な案件には「段階的な計画」を作らせる
機能の大きな追加。複雑なシステム設計。
こうした案件を扱うとき、依頼の仕方で結果が変わります。
「Xを計画して」と曖昧に頼むよりも、「包括的な、フェーズごとの計画を立ててください」と明示するほうが良いそうです。
トークン消費は増えます。
しかし、複雑な作業ではこの方法に勝るものは少ないという声が多く見られました。
もう一人の開発者がいる体で、批評させる
Claude CodeとCodexを併用しているユーザーが共有してくれた工夫です。
それぞれに対して、もう一方を「私の開発者」と呼んで言及する。
すると、両者とも「私の開発者」のコードを批判的に見直してくれます。
お互いを切磋琢磨させる構図が、自然に生まれるわけです。
まとめ
10項目の元投稿と、コメント欄からの補完テクニックを見てきました。
全体に共通する姿勢があります。
Claudeを「魔法のボタン」ではなく「管理が必要な共同作業者」として扱うこと。
質問させる。
評価させる。
計画を立てさせる。
批評させる。
AIに対して受け身になるのではなく、こちらから役割を設計していく。
これが上手い使い手の共通点だったように思います。
もう一つ印象的なコメントがありました。
「AI革命の本当の利点は、エンジニアに『効果的で明確なコミュニケーション』を教えてくれることかもしれない」
たしかに、AIに伝わるように書くスキル。
これは人間相手のコミュニケーションにもそのまま生きます。
道具を磨く過程で、自分自身も磨かれていく。
そんな副次的な効果まで含めて、AIとの付き合い方を考えていきたいですね。
