APIドキュメント用プロンプトが解決するのは、エンドポイントが完成したのにドキュメント作成が後回しになる問題です。コードはすでに動いているのに、呼び出し側はソースを読んでパラメータを推測するしかなく、連携のたびに型、必須かどうか、エラーコードを聞き直すことになります。下のプロンプトをコピーし、エンドポイントコードまたは定義を貼って、読者と出力形式を入れれば、AI が用途、パラメータ表、リクエスト例、レスポンス例、エラーコード説明を、呼び出し側が実際に調べる順番で出力します。項目を確認すれば、そのまま渡せます。
このプロンプトが向いている場面
すでにコードがあり、ドキュメントだけが足りないエンドポイントに向いています。フロントエンドや外部パートナーへの引き渡し前のバックエンドエンドポイント、古いプロジェクトのドキュメント補完、新人が引き継ぐ前に一群のエンドポイントの入出力把握する場合です。業務ルールまで肩代わりはできません。コードに明記されていない検証ロジック、権限要件、制限値は、疑問点として挙げるだけで、創作はさせません。項目がまだ頻繁に変わるなら、まずパラメータ表だけを生成し、項目が固まってからサンプルを足すと、書いたそばから古くなる事態を避けられます。
そのままコピーできるプロンプト本文
あなたはAPIドキュメントの編集者です。私が貼るエンドポイントコードまたは定義をもとに、呼び出し側がそのまま連携作業を進められるドキュメントを書いてください。
エンドポイントコードまたは定義：{{エンドポイントコード}}
想定読者：{{読者}}
認証方式：{{認証方式}}
ベースアドレスの説明：{{ベースアドレス}}
出力の条件：
1. 最初に、このエンドポイントが何をするものか、いつ呼ぶのかを2文で書く。コードの言い換えはしない。
2. 次にパラメータ表を作る。各パラメータについて、名前、場所（パス、クエリ、ヘッダー、ボディ）、型、必須かどうか、意味を書く。コードから読み取れない意味は「要確認」とし、推測しない。
3. 完全なリクエスト例と成功時のレスポンス例を1つずつ示す。項目名と型はコードと完全に一致させ、サンプル値は伏せた架空のデータにする。
4. エラーコード説明を分けて書く。コードが実際に投げるエラーだけを列挙し、発生条件と呼び出し側の対処を書く。コードにないエラーコードは足さない。
5. 最後に疑問点リストを作る。コードに明記されていない検証ルール、権限要件、境界ケースを1項目ずつ挙げ、私が確認してから本文に入れる。置き換える変数の入れ方
- エンドポイントコード：関数名だけではなく、処理関数、ルート定義、関連するリクエストとレスポンスの構造体まで貼る。文脈が揃うほど、パラメータ表の「要確認」は減る。
- 想定読者：社内フロントエンド、外部パートナー、新入社員のバックエンドのどれかを書く。読者が違えば、サンプルの詳しさも業務用語の説明の要否も大きく変わる。
- 認証方式：トークン、署名、ゲートウェイでの一括認証のいずれかを明記する。認証がない場合は空欄にせず「なし」と書き、AI に認証の説明を勝手に補わせない。
- ベースアドレス：テスト環境と本番環境の区別など、環境の説明だけを書く。本物のキーや認証情報をプロンプトに入れない。
初稿を受け取ったら確認すべき三つの点
第一に、項目を一つずつコードと照合する。AI は任意パラメータを必須と書いたり、コードにない項目をサンプルに足したりすることがあるため、パラメータ表は構造体と一言一句見比べる。第二に、エラーコードが親切に補われすぎていないかを見る。コード内を検索しても出てこないエラーコードやステータスは、エラー説明ではなく疑問点リストへ移す。第三に、サンプルのデータをきちんと伏せる。電話番号、メールアドレス、注文番号は明らかに架空の値に替え、連携時に使った実データをドキュメントに残さない。
エンドポイントをまとめて補完するときは、1回に1エンドポイントずつ生成すると項目の書き方がぶれない。10エンドポイントを一度に貼ると、パラメータ表同士が混ざりやすい。逆の使い方もできる。連携時にパラメータが合わないと言われたら、まずデバッグ用プロンプト：エラーとコードを貼れば、根本原因まで一回でたどり着くでドキュメントの誤りか呼び出しの誤りかを切り分け、それからこのページを直す。
