READMEをAIで作るプロンプト｜抜け漏れを防ぐコピペ用テンプレート
このプロンプトは、ソフトウェアや社内ツールのREADMEをAIで下書きするためのものです。コードは書けても説明文をまとめるのが難しい人や、READMEの項目漏れを減らしたい開発者に向いています。
結論から言えば、AIには「READMEを書いて」と頼むだけでは不十分です。読者、利用目的、実行環境、導入手順、確認済みの事実、不明点の扱いまで指定すると、公開前に直しやすいMarkdownが得られます。
この記事で分かることは次のとおりです。
- コピペして使えるREADME作成プロンプト
- 入力時に変更する項目と固定する条件
- 曖昧な指示が失敗しやすい理由
- READMEの内容を安定させる確認手順
- 新規作成と既存README改善への応用方法
このプロンプトで作れるREADME
初見の読者が「何のプロジェクトか」「どう始めるか」を判断できるREADMEを作ることが狙いです。
GitHubの公式ドキュメントでは、READMEに含める代表的な情報として、プロジェクトの用途、役立つ理由、開始方法、ヘルプの入手先、保守・貢献者などが挙げられています。つまり、READMEは機能一覧ではなく、利用開始までの案内役です。
このテンプレートは、たとえば次の場面で使えます。
- GitHubで公開するライブラリやCLIツール
- 社内で共有する業務自動化スクリプト
- Webアプリのローカル開発手順
- APIやSDKの導入ガイド
- 個人開発プロジェクトの引き継ぎ資料
出力形式は、そのまま README.md に移しやすいMarkdownです。見出し、箇条書き、コマンド例、リンクを分けて生成させます。
コピペ用README作成プロンプト
以下をコピーし、{} で囲んだ部分を書き換えてください。分からない項目は推測で埋めず、不明 と入力します。
あなたは、開発者向けドキュメントを編集するテクニカルライターです。
以下の情報をもとに、プロジェクトのREADMEを日本語で作成してください。
# 目的
初めてリポジトリを訪れた読者が、プロジェクトの用途を理解し、導入して、基本操作を試せるREADMEにする。
# 想定読者
{例：Pythonの基本操作ができる社内開発者}
# プロジェクト情報
- プロジェクト名：{プロジェクト名}
- 概要：{何をするプロジェクトか}
- 解決する課題：{誰のどんな問題を解決するか}
- 主な機能：
- {機能1}
- {機能2}
- {機能3}
- 対応環境：{OS、言語、ランタイム、必要なバージョン}
- 前提条件：{必要なアカウント、外部サービス、ツールなど}
- インストール手順：{実際に確認した手順}
- 基本的な使い方：{実行コマンドと期待する結果}
- 設定項目：{環境変数や設定ファイル。秘密情報の実値は書かない}
- ディレクトリ構成：{説明が必要な主要フォルダ}
- テスト方法：{テストコマンドと前提条件}
- よくある問題：{既知のエラーと対処法}
- ライセンス：{ライセンス名または未定}
- 問い合わせ先：{Issue、社内窓口、連絡方法など}
- 補足資料：{関連ドキュメントへの相対パスまたはURL}
# 出力する見出し
1. プロジェクト名
2. 概要
3. 主な機能
4. 必要要件
5. インストール
6. 使い方
7. 設定
8. ディレクトリ構成
9. テスト
10. トラブルシューティング
11. 関連ドキュメント
12. ライセンス
13. 問い合わせ
# 制約
- Markdownで出力する
- README本文だけを出力し、前置きや解説は付けない
- コマンドは言語名付きのコードブロックにする
- 入力情報にないコマンド、URL、バージョン、機能、実行結果を創作しない
- 不明な情報は推測せず「要確認」と明記する
- 不要な見出しは、内容を捏造せず省略候補として末尾に示す
- 同じ説明を複数の見出しで繰り返さない
- 秘密鍵、トークン、パスワードの実値を出力しない
- リポジトリ内のファイルへは、可能な限り相対リンクを使う
# 最終確認
本文の後に、公開前に人が確認すべき項目を「要確認事項」として箇条書きで示す。
特に、コマンド、対応バージョン、環境変数、リンク、ライセンスを確認する。
入力時に変える部分
AIの文章力より、渡す事実の具体性がREADMEの品質を左右します。 特に次の項目は省略せずに入力してください。
読者と到達点
「開発者向け」だけでは幅が広すぎます。読者が何を知っていて、READMEを読んだあと何ができればよいかを書きます。
- 曖昧：エンジニア向け
- 具体的：Pythonは使えるがDockerは初めての社内開発者向け
- 到達点：ローカル環境でサンプルCSVを変換し、出力ファイルを確認できる
実行環境と確認済みコマンド
OS、言語、ランタイム、パッケージ管理ツールのバージョンを渡します。インストールやテストのコマンドは、実際に成功したものだけを入力してください。
たとえば Python 3.x ではなく、プロジェクト側で保証している範囲が分かるなら Python 3.12 や Python 3.11以上 とします。保証範囲が未確認なら、AIに決めさせず「要確認」とします。
固定しておく条件
プロジェクトが変わっても、次の指示は残すのがおすすめです。
- 未提供の機能や手順を創作しない
- 不明点を「要確認」として分離する
- 秘密情報の実値を書かない
- コマンドをコードブロックで示す
- 公開前の確認項目を最後に出す
NG例と改善例
README作成で失敗しやすい原因は、入力不足をAIの推測で補わせることです。
NG例
このPythonプロジェクトのREADMEを書いてください。
初心者にも分かりやすく、詳しく説明してください。
この指示では、AIにプロジェクトのファイルや実行環境が共有されていません。「詳しく」という条件も、必要な項目や文章量を決める基準になりません。その結果、存在しないインストールコマンドや一般的すぎる説明が混ざる恐れがあります。
改善例
社内の経理担当者がCSVを月次集計するPython CLIのREADMEを作成してください。
読者はターミナル操作に不慣れです。
確認済みの事実：
- Python 3.12で動作確認済み
- インストール：python -m pip install -r requirements.txt
- 実行：python -m sales_summary input.csv --output summary.csv
- 入力CSVには date、department、amount 列が必要
- Windowsでの動作は未確認
Markdownで、概要、必要要件、インストール、入力形式、実行例、出力、よくあるエラーの順に書いてください。
未確認事項は推測せず「要確認」と表示してください。
改善点は明確です。誰が使うのか、何を処理するのか、どのコマンドが確認済みか、何が未確認かを分離しています。AIは文章を整える役に集中でき、事実を作る必要がありません。
出力を安定させる3つのコツ
READMEは一度で完成させるより、事実確認を挟んで段階的に整えるほうが安全です。
1. 先に不足情報を質問させる
情報が少ない場合は、生成前に次の一文を加えます。
READMEを作成する前に、内容の正確性に必要な不足情報を最大7問まで質問してください。
回答できない項目は未確認として扱ってください。
質問数に上限を設けると、作業が止まりにくくなります。
2. 文章より先に構成を確認する
規模の大きなプロジェクトでは、いきなり本文を書かせず、見出し案だけを出させます。
まずREADMEの見出し構成と、各見出しに必要な入力情報だけを箇条書きで出してください。本文はまだ書かないでください。
不要なセクションを削り、足りない項目を追加してから本文生成へ進めます。これにより、長いREADMEを丸ごと修正する手間を減らせます。
3. 「事実」と「表現」を別々に確認する
最終確認では、読みやすさだけでなく事実の裏付けを点検します。
- コマンドを新しい環境で実行できるか
- 必須バージョンと動作確認済みバージョンが一致しているか
- 環境変数名に誤りがないか
- 相対リンクの参照先が存在するか
- サンプル出力が実際の結果と合っているか
- ライセンス表記がリポジトリ内のファイルと一致するか
GitHubでは、リポジトリ内の別ファイルを示すときに相対リンクを使えます。ブランチに応じてリンク先が変換され、クローンした環境でも参照しやすいため、固定された絶対URLを並べるより保守しやすくなります。
ここがポイント: AIが作ったREADMEは完成品ではなく、確認済みの事実を読みやすい順番へ並べる下書きです。実行コマンドとバージョンは、必ず人が再確認します。
活用例：新規作成だけでなく改善にも使う
同じ考え方は、既存READMEの点検にも使えます。
既存READMEの不足を洗い出す
README本文を貼り付け、書き直す前に不足だけを抽出させます。
以下のREADMEを、初めて利用する開発者の視点で点検してください。
[README本文]
{ここに既存READMEを貼り付ける}
次の形式で出力してください。
- 不足している情報
- 古い可能性がある情報
- 手順どおりに進めない箇所
- 重複している説明
- 秘密情報や安全上の懸念
本文はまだ書き換えず、各指摘について確認方法を1つ示してください。
この指示なら、AIが勝手に全面改稿する前に、修正範囲を人が判断できます。
READMEを読者別に分ける
一般利用者と開発参加者で必要な情報が異なる場合は、READMEへすべて詰め込みません。
- README：概要、導入、基本操作
CONTRIBUTING.md：開発参加、ブランチ、レビュー手順docs/：詳細設定、設計、運用手順- Issueや窓口：質問、不具合報告
AIには「詳細情報を削除する」のではなく、「READMEに要約を残し、適切な文書への相対リンクを提案する」と指示します。短さだけを優先せず、読者が次の情報へ移動できる状態を保つことが重要です。
公開前チェックリスト
最後に、次の項目を人が確認してください。
- [ ] 冒頭だけでプロジェクトの用途が分かる
- [ ] 想定読者と前提知識が明確になっている
- [ ] インストールと基本操作を別の環境でも再現できる
- [ ] コマンド、バージョン、ファイル名に架空の情報がない
- [ ] 環境変数の名前は示し、秘密情報の実値は載せていない
- [ ] リンクと画像が正しく表示される
- [ ] 未確認事項が断定表現に変わっていない
- [ ] ライセンスと問い合わせ先が実態に合っている
最初に改善すべきなのは文章の美しさではありません。新しい利用者が、記載されたコマンドだけで最初の成功まで進めるかを確認してください。進めない箇所があれば、そこが次にAIへ渡すべき具体的な修正材料です。