AIにコードを書かせる前に投げるべき、プロジェクト監査と整備の実務プロンプト50選

割引あり

ITコンサルお姉さん

2026年7月2日 02:48

新しい高性能AIモデルが出ると、
まず「何を聞けば性能が分かるか」を考える人が多いと思います。

文章を書かせる。企画を出させる。コードを書かせる。難しい質問を投げる。ただ、実務で一番差が出るのはそこではありません。

高性能AIに最初にやらせるべきなのは、派手な生成ではなく、
手元のプロジェクトをどこまで正確に読めるか、どこまで安全に整えられるかの確認です。

特にローカルの開発プロジェクトでは、AIにいきなり修正させると危ない場面が多いです。

READMEが古い
`.env.example` がない
起動コマンドが人によって違う
テストがない
CIがない
依存関係が古い
秘密情報の扱いが曖昧
仕様がコードの中にしかない
AIに守らせる作業ルールがない

この状態で「直して」と頼むと、AIはそれっぽく前に進みます。
でも、既存仕様を壊したり、不要な依存関係を足したり、テストなしで大きく書き換えたりすることがあります。

AIの性能が上がるほど、出力は速くなります。
だからこそ、最初に必要なのは「強いプロンプト」ではなく、安全に作業させる順番です。

このnoteは、その順番をそのまま使える形にしたものです。

このnoteで得られるもの

このnoteには、ローカルプロジェクトをAIで整備するための実務プロンプトを50本まとめています。

目的は、AIにコードを書かせることではありません。

目的は、プロジェクトを次の状態に近づけることです。

・初見の人でもREADMEを読めば動かせる
・環境変数の不足で詰まらない
・起動、テスト、ビルドのコマンドが整理されている
・lint、format、typecheck、CIの不足が分かる
・秘密情報や依存関係リスクを確認できる
・AIが勝手に仕様変更しないためのルールがあ
・障害時、リリース時、引き継ぎ時に見るべき資料がある

つまり、AIを「作業者」として使う前に、プロジェクトを任せても壊れにくい状態にするためのプロンプト集です。

まずは手元のプロジェクトを渡して、次の3本を使ってください。

・#01 プロジェクト総合監査
・#36 コード修正前の安全・制約プロンプト
・#49 最終点検プロンプト

向いている人

このnoteは、次のような人に向いています。

・新しいAIモデルを実務で試したい
・個人開発のリポジトリが散らかってきた
・副業や受託で、他人のコードを触ることがある
・READMEや環境構築を後回しにしている
・AIにコード修正を頼む前に事故を減らしたい
・プロジェクトを将来の自分や他人に引き継げる状態にしたい
・Claude Code、Codex、CursorなどのAIコーディング環境を使っている

逆に、AIに全部自動で作らせる魔法の指示を探している人には向きません。

このnoteは、AIを過信するためのものではなく、AIを安全に使うための作業設計です。

なぜ「プロンプト50選」だけでは足りないのか

プロンプト集は世の中にたくさんあります。

ただ、実務で使うとすぐ分かります。
プロンプト単体が強くても、使う順番を間違えると効果が出ません。

たとえば、READMEが壊れている状態でCIを入れようとしても、前提が曖昧です。
環境変数が整理されていない状態でテストを書かせても、再現性がありません。
AI作業ルールがない状態でリファクタリングを頼むと、変更範囲が広がりすぎます。

だから、このnoteではプロンプトを次の流れで並べています。

まず全体を監査する
READMEと環境構築を整える
コマンドを標準化する
テスト、lint、CIを整える
セキュリティと秘密情報を確認する
AI作業ルールを作る
設計、運用、引き継ぎを整える
最後にもう一度点検する

この順番にすると、AIがいきなり実装へ突っ走る前に、現状把握と安全な変更単位を作れます。

まずは、下のプロンプトだけでも試してみてください。

新しいAIモデルの実務力を見るなら、最初はこれで十分です。
コードを書けるかどうかより、前提を読み取れるか、リスクを分けられるか、次の作業順を現実的に出せるかが分かります。

#01 プロジェクト総合監査プロンプト

このローカルプロジェクト全体を確認し、第三者が安全に開発・保守・引き継ぎできる状態にするための現状整理をしてください。

目的:
- このプロジェクトが何をするものか推定する
- 技術スタックを特定する
- 実行方法、テスト方法、ビルド方法を把握する
- 不足している設定、ドキュメント、運用ルールを洗い出す
- 重大な保守リスクとセキュリティリスクを分けて整理する

確認観点:
1. ディレクトリ構成
2. 主要ファイル
3. 使用言語、フレームワーク、ライブラリ
4. パッケージマネージャー
5. 実行コマンド
6. テストコマンド
7. ビルドコマンド
8. 環境変数
9. 設定ファイル
10. CI/CDの有無
11. READMEの正確性
12. 保守上のリスク
13. セキュリティ上のリスク
14. 改善優先度

制約:
- 既存仕様を勝手に確定しない
- 不明点は「要確認」と明記する
- 破壊的変更は提案に留める
- 実行していないコマンドは、実行済みのように書かない
- 秘密情報が見つかった場合は値を出さず、種類と場所だけ説明する

出力形式:
- 概要
- 現状把握
- 重大リスク
- 優先度つき改善案
- すぐ確認すべきコマンド
- 修正・作成すべきファイル一覧
- 次に依頼すべきAIプロンプト

この1本を投げるだけでも、プロジェクトの見え方はかなり変わります。

うまく動くと、AIは次のようなことを返してくるはずです。

・このプロジェクトが何をするものか
・どの技術で作られているか
・どのコマンドで動かすべきか
・READMEに何が足りないか
・`.env.example` が必要か
・CIやテストが足りているか
・セキュリティ上どこを確認すべきか
・次に何を頼むべきか

ここまで出せるモデルなら、実務投入の入口には立てます。

ただし、この1本はあくまで入口です。
ここから先は、出てきた課題を順番に潰す必要があります。

有料部分に入っているもの

有料部分では、総合監査の後にそのまま使える実務プロンプトを50本分まとめています(1本は無料として提示済)

単に「プロンプトを並べた」だけではありません。
どの場面で使うか、何を出力させるか、AIに何を禁止するかまで入れています。

収録内容は以下です。

1. プロジェクトを読む

プロジェクト総合監査
仕様整理
アーキテクチャレビュー
技術的負債の棚卸し
不要ファイル・不要コード整理

2. 動く状態にする

ローカル環境整備
`.env.example` 作成
Docker / Dev Container化
コマンド標準化
README改善

3. 壊れにくくする

lint / format / typecheck
GitHub Actions
テスト戦略
最小テストセット
実装後レビュー

4. 事故を防ぐ

秘密情報チェック
依存関係監査
認証・認可レビュー
DB設計レビュー
migration運用

5. AIに安全に作業させる

AGENTS.md作成
PROJECT_CONTEXT.md作成
AI作業ルール
コード修正前の安全制約
AI引き継ぎプロンプト

6. 運用できる状態にする

リリース手順
CHANGELOG
ログ設計
エラーハンドリング
監視・Observability
障害対応
障害報告書

7. チームや顧客に説明できる状態にする

PRテンプレート
Issueテンプレート
管理表・台帳
課題・リスク棚卸し
週次報告
顧客説明
意思決定者向け整理

8. 最後に仕上げる

優先順位つき依頼リスト
万能プロンプト
最終点検プロンプト
最初から最後まで任せる統合プロンプト

どう使うのが一番いいか

おすすめは、全部を一気に投げることではありません。

まずはこの順番です。
①総合監査：全体像とリスクを掴む
②README / `.env.example`：初見でも動く状態にする
③コマンド標準化：起動・テスト・ビルドを揃える
④テスト / lint / CI：変更時の安全性を作る
⑤セキュリティ監査：共有・公開前の事故を防ぐ
⑥Claude.md / AGENTS.md：AIに作業前提を渡す
⑦リファクタリング計画：小さい変更単位に分ける
⑧運用・障害対応：保守できる状態にする
⑨引き継ぎ資料：次の人が迷わない状態にする
⑩最終点検：本当に引き継げるか確認する

この順で進めると、AIの出力がかなり安定します。

逆に、最初から「全部直して」と頼むと、変更範囲が広がりすぎます。
AIが強くなるほど、そのリスクも大きくなります。

購入すると何が変わるか

このnoteの価値は、プロンプトを50本持てることだけではありません。

毎回、AIにこう説明し直す必要がなくなります。

まず全体を見て
既存仕様は壊さないで
秘密情報は出さないで
大規模変更はしないで
変更対象を分けて
テスト観点も出して
READMEに何を書くべきか考えて
CIとローカルコマンドも揃えて
最後に引き継ぎできるか確認して

これを毎回その場で書くのは面倒です。
しかも、急いでいると抜けます。

有料部分では、この抜けやすい指示を用途別に分けてあります。

必要な場面で必要なプロンプトを貼るだけで、AIへの依頼がかなり安定します。

購入前に判断してほしいこと

買わなくても、無料サンプルの総合監査プロンプトだけでかなり使えます。

まずはそれを手元のプロジェクトに投げてみてください。

その結果、

次に何を頼めばいいか分からない
READMEや環境構築まで整えたい
セキュリティやCIまで見たい
AI作業ルールを作りたい
プロジェクトを引き継げる状態にしたい

と思ったら、有料部分が役に立ちます。

逆に、単発でコードを1箇所だけ直したい場合は、このnoteは少し広すぎるかもしれません。

このnoteは、目の前の1修正ではなく、AIでプロジェクト全体を安全に扱うための型が欲しい人向けです。

ここから先には、実務でそのまま使えるプロンプト49本を収録しています。

各プロンプトは、次の形でそろえています。

使うタイミング
何を確認させるか
AIに守らせる制約
出力形式
次に使うべきプロンプト

高性能AIを使うときに重要なのは、AIに「何でもできる前提」で投げないことです。

まず現状を読ませる。次に制約を渡す。
そのうえで、小さい単位で改善させる。

この順番を守るだけで、AIの出力はかなり実務寄りになります。

以下、49本です(1本は無料部分で提示済)

収録一覧

ここから先は

15,021字

ログイン

ここまで読んでいただき、ありがとうございます。記事が少しでも現場の判断や報告、資料作成の助けになったら、チップで応援してもらえるとうれしいです。いただいた応援は、次の記事や実務テンプレ作成の励みにします。