公式ドキュメントから読み取れるChatGPT/Claudeのプラクティス
tristarChatGPTやClaudeのドキュメントを改めてみてみたら「こんな風に使うと良い」という情報が結構まとまっていて、両者に共通していたりする部分もあって驚いた。
共通するポイントをまとめてみたいと思ったのと、
長いドキュメントの一部に書かれている中から自分にとって重要と思ったものをまとめてみたいと思ったので書いていく。
tristarChatGPT, Claudeに共通しているポイント
tristar- 構造化したデータの表現はXMLが好まれる。(特に長いコンテキストの場面で)
JSONも認識されるが、XMLと比較すると成績が悪く、エスケープ処理が必要などのオーバーヘッドがある。 - データを区切るデリミタはMarkDownから始めるのが良い。XMLも良いが、デリミタに何を使うかはケースバイケースで、何が「より目立つか」で決める必要がある。XMLばかりの入力データの中でデリミタとしてXMLを使っても効果は薄れてしまう。
https://cookbook.openai.com/examples/gpt4-1_prompting_guide#delimiters
Claudeの場合はXMLのタグについて一部指示されている。例えば、<thinking>タグを使うことで拡張思考モードの拡張思考ブロックに影響を与えるプロンプトを記述できる。
tristar20Kトークン以上など長いドキュメントを含める場合、冒頭やユーザーのクエリなどの前に挿入することでパフォーマンスが向上する。
ChatGPT(GPT-4.1?)の場合、出来れば冒頭と末尾の両方に含める。片方だけにする場合は先頭に追加した方が良い。
tristar「最初はシンプルな指示で始めて、動作を確認し必要に応じ指示を追加していくのが良い」
このコメントは色々なところで記述されている。
例えばClaude Code
A common mistake is adding extensive content without iterating on its effectiveness. Take time to experiment and determine what produces the best instruction following from the model.
GPT-4.1のRecommended Workflow
Start with an overall “Response Rules” or “Instructions” section with high-level guidance and bullet points.
If you’d like to change a more specific behavior, add a section to specify more details for that category, like # Sample Phrases.
If there are specific steps you’d like the model to follow in its workflow, add an ordered list and instruct the model to follow these steps.
Chat-GPTのGeneral Promptの推奨
# Role and Objective
# Instructions
## Sub-categories for more detailed instructions
# Reasoning Steps
# Output Format
# Examples
## Example 1
# Context
# Final instructions and prompt to think step by step
ClaudeのExtendedThinking
tristarClaude全般
tristar長いドキュメントを扱う場合、最初に関連する部分をClaude自身に引用させると、ノイズとなる残りの部分をカットするのに役立つ。
tristarClaudeに何かを依頼する時は、Claude自身はユーザーと比較して新人のようにコンテキスト、スタイル、ガイドラインの知識がない状態でタスクに取り組むため、何を求めているか正確に説明するほど反応が良くなる。
※Claudeの内容を、タスクに関するコンテキストを持っていない他の同僚に見せた時混乱すると思われる場合、Claudeも同じように混乱する可能性が高い。
渡すべきコンテキストとしては
- タスクの結果は何に使う予定か
- タスクの結果は誰が見るのか
- タスク全体のワークフローと、今その中のどの部分にあたるのか
- タスクが完了した時とはどう見える時か
また、何をしてほしいかをなるべく具体的に記述することも重要。
例えば、出力結果としてコードだけが欲しい時は、そのように指示するべき。
指示は箇条書きや番号付きリストで与えられると、Claudeがその通りにタスクを進めやすい。
tristar特に複雑なタスクでは、多様性があり関連性の高い3-5程度の実例が含まれていると良いパフォーマンスが得られる。
(例えば出力が構造化されており決まった形式である場合)
例は以下のようなXMLで書くことも挙げられている
<examples>
<example>xxxx</example>
</examples>
tristarここに来て「Extended Thinking固有」の事項も出てきたので、それは別スレッドに書く。
tristarGPT4.1
tristarGPT-4.1はreasoning modelではないものの、ユーザーはモデルに対し明示的なステップバイステップのプランを生成させることが出来る。
（"声に出して考える"）
SWE-bench Verifiedで使用した実際のプロンプトが紹介されていて、かなり長い内容になっている。
冒頭に以下のようなメッセージが含まれていて、積極的に「考える」ことを指示している。
Your thinking should be thorough and so it's fine if it's very long. You can think step by step before and after each action you decide to take.
You MUST iterate and keep going until the problem is solved.
Only terminate your turn when you are sure that the problem is solved.
Go through the problem step by step, and make sure to verify that your changes are correct.
NEVER end your turn without having solved the problem, and when you say you are
going to make a tool call, make sure you ACTUALLY make the tool call, instead of ending your turn.
作業の進め方についても大まかに指示するのではなく細かく指示している。
tristarGPT-4.1はユーザーの指示に従うことに長けているので、出力フォーマットを指定したり避けるべき事項を指定するといったことがより正確にできるようになっているが、忠実に従う分だけ「何を行い何を行わないべきか」指示する必要がある。
そういう意味で、既存のモデル用に最適化されたプロンプトはそのままでは4.1では使えないかもしれない。(これまでほど強くは暗黙的な意図を推論しないので)
tristar推奨されるワークフローとして以下が挙げられており、他のモデルと同様、シンプルに始めて、結果を見ながら調整することが推奨されている
- ハイレベルな視点でのガイダンス、箇条書きから始める
- 特定の挙動を細かく指示したい場合は、MarkDownの見出しなどを設けて詳細を記述する
- モデルに従わせたいステップがある場合、番号付きリストで記述する
- これでも意図通りの結果を得られない場合
- 指示に衝突や不足がないか確認する。衝突がある場合、GPT-4.1は「プロンプトの末尾にある方」を優先する傾向がある
- 期待する結果についての例を追加し、重要な動作を示している部分がルール中でも引用することを確認する
- 「全部大文字」のような強調は通常使う必要がない。これらを使用した場合、GPT-4.1は過度に重視する可能性がある
※サンプルコードの作成やルールの衝突チェックといった作業はAI搭載のエディターが役に立つ
tristarChatGPT全般
tristar- モデルが常に特定の行動をとるように指示することは、時に悪い影響を引き起こす。
- 例えば「あなたはユーザーにレスポンスを返す前にツールを呼び出さなければならない」ような指示を出すと、ツール呼び出しにハルシネーションが含まれたりnullが渡されるといったことが起きる。
対策として、「情報が不足している場合、ユーザーに情報の提供を求めてください」のような指示を含めることで避けることが出来る
- 例えば「あなたはユーザーにレスポンスを返す前にツールを呼び出さなければならない」ような指示を出すと、ツール呼び出しにハルシネーションが含まれたりnullが渡されるといったことが起きる。
- サンプルの文章(フレーズ)を用意した時、モデルはそのサンプルをそのまま使ってしまうことがある。必要に応じてサンプルをカスタマイズすることを指示する必要がある
- 特に指示がない限り、一部のモデルは余分な説明を用意することがある。こういったことを抑止する指示や出力の例を示すことで軽減することが出来る。
tristar特定のケースでは、モデルが非常に長い繰り返しを伴う出力を行うことに抵抗することを観察している。(数百の要素を1つずつ解析するなど)
このようなふるまいが必要な場合、全て出力することを強く指示したり、要件を分割、またはより簡潔なアプローチを検討する。
tristarプロンプトの開始点として以下が推奨とされている。
# Role and Objective
# Instructions
## Sub-categories for more detailed instructions
# Reasoning Steps
# Output Format
# Examples
## Example 1
# Context
# Final instructions and prompt to think step by step
tristarClaude Extended Thinking固有
tristarExtended Thinkingではハイレベルな視点での指示がステップバイステップな指示よりも上手く機能する。
こうすることで、人間によるプロセスの定義よりもモデルの創造性が上回るかもしれない。
雑に指定するのでもなく、以下のように考えることを促したり、うまく行かなかったときどうするか指示するといったことが書かれている。
Please think about this math problem thoroughly and in great detail.
Consider multiple approaches and show your complete reasoning.
Try different methods if your first approach doesn't work.
それでも、Claudeは必要に応じステップバイステップな指示も必要に応じ実行することも出来る。
推奨としては「より一般化された指示から始めて思考過程を確認し、必要に応じて具体的なステップを追加していく」方法が良いとされている。
tristarExtended Thinkingでは、プロンプト内で<thinking>タグ、<scratchpad>タグを利用して思考の正規パターンを示すことが出来る。
これらは拡張思考ブロックの中で使われるようになる。
Problem 1: What is 15% of 80?
<thinking>
To find 15% of 80:
1. Convert 15% to a decimal: 15% = 0.15
2. Multiply: 0.15 × 80 = 12
</thinking>
The answer is 12.
Now solve this one:
Problem 2: What is 35% of 240?
tristarExtended thinkingは大量のデータやテキストを生成することに長けている。
“Please create an extremely detailed table of…” のような指示を行うことで、包括的なデータセットを作成できる。
tristarモデルに自分自身で結果が正しいか各印するステップを設けることで、エラーを抑止することが出来る。
Extended thinkingの過程でテストを実行させる(※)ように求めることが出来る
※モデル自身がコードを実行、評価することが出来る？その結果を信じて良いか不安な面もあるので、npm run test のようなテストコマンドの実行を求める？
tristar実際にこれらLLMを使う時はGitHub Copilot AgentモードかClaude Codeなどで使う形になるので、こういったエージェントを使う際のプラクティスも把握しておきたい。
ただ、2025-04-25時点だとCopilot Agentモードに関する公式なCookbookやベストプラクティスはまとまっていない...?
ClineやCursorもあるけど、どちらかというとClaudeCodeの方が近いかもしれないと思い、
ClaudeCodeのベストプラクティスも確認してみる。
tristarClaudeCode
tristar- .claude/commands フォルダの下にカスタムのコマンドを作っておくことで繰り返しのタスクをショートカットできる
推奨するワークフロー
- Claudeに関連するファイルのスキャンを命じるが、コードは書き始めないように指示する
- 問題にどう取り組むかプランを立てるように指示する
- "think"という言葉を使うとExtended thinkingを促す
- think < think hard < think harder < ultrathink のような階層がある
- 問題の解決をコードに書くように促す
- コミットしてPRを作成する。このタイミングでCHANGELOGやREADMEを更新するのも良い
https://www.anthropic.com/engineering/claude-code-best-practices#a-explore-plan-code-commit
tristar具体的な指示を行うことで、特に初回のプロンプトでの成功率が上がる。
「最初はシンプルに」と相反するようだけど、たぶん微妙に違う(?)。
- 最初からルールなどでガチガチにして挙動を縛るのはダメで、ハイレベルな視点から大まかな要望を書く
-
Claude can infer intent, but it can't read minds. Specificity leads to better alignment with expectations.とあるので、Claudeが汲み取った意図に誤解が起きにくくなるような指示が求められるのかもしれない。
-
- そうはいっても選択の余地はないくらいにイメージが固まっていたら最初から書く
- 「xxx.tsを参考にyyyを実装して。この機能ではaaaとbbbが出来なければならない。この作業のために外部ライブラリは使わないで欲しい」
tristarauto approveを有効にしていても、積極的に干渉することが出来る。
- Escキーを押して一時停止させる
- Escを2回押して直前のプロンプトに戻り、別の方向性を探る
https://www.anthropic.com/engineering/claude-code-best-practices#e-course-correct-early-and-often
tristar大きなタスクに取り組む時はスクラッチパッドをClaudeCode自身に作り、管理させる
tristarソースコードのツリーを複数作成し、それぞれで別々のタスクを実行させる。
tristarヘッドレスモードを利用し、大規模な分散処理を実行させる。
(調査や分析)
その結果をJSONで出力し、パイプで別のコマンドに渡すことも出来る
tristarClaude4
Claude4も「指示により忠実」に動作するモデルになっているとのこと。
(明記されていないものの、GPT-4.1と同様で、これがエージェント向きの最適化なのかも)
tristar
単に「ダッシュボードを作ってほしい」ではなく、以下のような感じで「どのくらい力を入れるか」を明示的に指定すると効果的とされている。
(何をするかは具体的に書かなくて大丈夫...?)
可能な限り多くの関連機能やインタラクションを含めてください。基本を超えて、完全な機能を備えた実装を作成してください。
また、単に「省略記号は絶対に使わないで」ではなく、「テキストリーダーが発音できず妨げになるので省略記号は使わないで」と理由を添えるのは効果的らしい。
tristar例を挙げる時はユーザーが促進したいと思っている行動と一致し、避けたいと思っている行動が最小限になっていることに気を付ける。
tristar
「回答の散文部分を<smoothly_flowing_prose_paragraphs>タグ内に記述してください」のようにフォーマットを指定する。
プロンプトで使うフォーマットスタイルが出力に影響を与えるので、出力にマークダウンを含めたくない場合、プロンプトからマークダウンを削除すると効果がある。
ツールを使う前に、その結果を慎重に検討して次のステップを決めることを含めると交互思考に導くことが出来る。
ツールの結果を受け取った後、その品質を慎重に検討し、次に進む前に最適な次のステップを決定してください。この新しい情報に基づいて計画し、反復するために思考を使用し、最善の次のアクションを取ってください。
一時ファイルを削除することをプロンプトに含めるのも効果がある。
反復のために一時的な新しいファイル、スクリプト、またはヘルパーファイルを作成した場合は、タスクの最後にこれらのファイルを削除してクリーンアップしてください。