2025年のぼくの戦い方(プロンプト文の書き方含む)[技術者用]

Agenda

• 前書き

• 結論

• 内容
  ①技術者としての戦い方
  ②−１ 誤解されている? コーディングする上でのプロンプトの書き方

  1. 必要以上に情報を削る指示
  2. 過度な制約のかけ方
  3. 意図があいまいな評価基準
  4. 禁止表現で想定外の抑制
  5. 余計な事柄は書かないでください
  6. 抽象的すぎる要求
  7. 逆に詳細すぎる指示で本質を見失う
  8. 例だけを与えて定義を与えない
  9. 質問の順序や重要度が不明確
  10. 背景・目的の省略
  11. 「〇〇風に」だけの曖昧なスタイル指定
  12. 禁止事項だけで代替案を示さない
  13. 回答範囲を曖昧に制限

  ②−２ プロンプト自動作成法

  1. OpenAI Platformにアクセス+createをクリック
  2. Configure クリック
  3. ペンマーククリック
  4. プロンプト文の作成依頼のための要望をペンマーク記載欄に書く

前書き

某企業の森田です。
もうひっきりなしに新しいLLM,エージェントなど出てきていますね。当たり前のようにプロンプトを書いて文章、画像、動画、コードなどを生成して利用しているかと思います。今日は、ぼくがコーディングをする上で、個人的に気をつけているプロンプトの書き方について2025年版を書こうと思っています。

エンジニア職として日々LLMと向き合って試行錯誤をしている中、『こういう風に書いたら意図しないものが来る』など発見があり、それらをまとめたものになります。

そしてプロンプト文の書き方の前の技術者としての振る舞い、ぼくなりの戦い方です。何かの参考になれたら幸いです。

結論

・LLM無料枠使って時短しよう
・プロンプト文って奥深いですね。ぼくが普段コーディングするときだけ気をつけているポイントは13個
・プロンプト文作成が不安ならChatGPTのPlatformを使うといいよ

内容

①技術者としての戦い方
②−１ コーディングする上でのプロンプトの書き方
②−２ プロンプト自動作成法

①技術者としての戦い方

パラレルで様々なLLMを並行して動作

• Geminiに質問して回答を待ちながら（最近はDeepResearchができるようになりましたね）（ただ彼にコーディング依頼をするのは、余り私は好きではありません。親切心がClaudeよりも劣っていると感じるためです。）

• Manusにスクレイピングを必要とする調査をさせ（彼は特に画面把握が上手いのでスクレイピングなどの操作に長けているので、そういった調査が必要な場合に担当してもらっています。この使い分けが重要です。）

• ChatGPTのDeepResearchで界隈の周辺情報を調査させながら（必ずエビデンスのURLを併記するよう指示します）

• Gensparkのエージェントでも周辺調査を開始します（別の視点観点からの調査）

• Perplexityでも並行して関連調査開始(コストや商用利用可能か操作性、改変可能かなどの観点表をもとに主にコモディティ化されているサービスやAPIについて彼には問うことが多いです)

• GPTsのConsensus,Paper Interpreter, WebサイトのConneted Paperで研究領域の資料集め(前回の最新技術の調べ方(備忘録)を参照

• Gensparkを休ませません、エージェントで資料を作るための事前資料を作らせます

• (すんなり解決策を見出せないやばい案件の時、超難題ケースは一旦整理して戻ります)

• ManusやGemini、Gensparkエージェント、ChatGPT(DeepResearh)で得た情報をもとに、コーディングを開始するためのプロンプトを考えていきます。（今日の掘り下げる内容2つ目として以下に詳細を記載します）

• ManusとGensparkくんたちは資料作成も得意なため、今までのを再度まとめていきます(このフェーズでは事前資料のためMarkdown形式で十分)

• 出来上がったプロンプトをClaude(今だとOpus4.1)に投げてコーディングを開始します（ここのフェーズは資料にまとまらないくらい様々なことを結構一緒に考えて完成させていくイメージで、場合によってはClaudeを３タブ程開いて調べつつ並行して進めていきます）

• 最後に各種まとまった資料とClaudeの結果をSkyworkで最終資料として作成しています

部下が5,6人くらいいる感じです。それはスーパー多機能スペシャルガンです。（有料のはありますが、ほぼ無料枠のため限度超えると竹ヤリ兵に戻ります）

大丈夫だと思いますが念のため以下も

• アップロード時は、固有名詞などは伏せ字で
• 社内機密情報などは使わない(Geminiの設定など気をつけてくださいね)
• Deepseekはあからさまに学習ネタにすること明示していますし個人開発にしか私は使いません
• コードのライセンス要確認
• LLM使う時は、エビデンスURLを併記する指示与えてファクトチェック必須

②−１ 誤解されている？コーディングする上でのプロンプトの書き方

巷で出回っている噂を鵜呑みにしてプロンプト文に入れると、実は品質の下がった回答が来ていることがあります。一見正しそうで実は危険なプロンプト作成の落とし穴があり、それらに注意して書いていくことが大前提になります。

1. 必要以上に情報を削る指示

間違いやすい書き方：「簡潔に答えてください」

危険理由：本来必要な条件や背景が省かれ、答えが不完全になる

安全な書き方：「簡潔にまとめつつ、必要な条件や前提は必ず残してください」

2. 過度な制約のかけ方

間違いやすい書き方：「絶対に〇〇という単語を使わないでください」

危険理由：必要な用語まで排除してしまい、意味や精度が落ちる

安全な書き方：「〇〇という単語は極力避けつつ、意味が変わらない範囲で言い換えてください」

3. 意図があいまいな評価基準

間違いやすい書き方：「正しい情報だけ答えてください」

危険理由：「正しい」の基準がモデルに不明確 → 情報量不足や不正確な出力

安全な書き方：「正確性を最優先し、根拠や出典も添えてください。不明確な場合はそう明記してください」

4. 禁止表現で想定外の抑制

間違いやすい書き方：「推測はしないでください」

危険理由：文脈的に必要な推論や背景説明まで消える

安全な書き方：「事実と推測を明確に区別して提示してください」

5. 余計な事柄は書かないでください

間違いやすい書き方：「余計な事柄は書かないでください」

危険理由：「余計かどうか」の判断がモデル任せになり、必要な情報まで削除される恐れ

安全な書き方：「出力後に余分な情報は私が判断して省きますので、関連しそうなことはすべて提示してください」　脆弱性対応などの本当に細かな対応の取捨選択など含め、一様にしてこの一言を加えて任せていると大概漏れが発生します。使用する権限の自己への付与や内容確認をするなどのコマンドレベルであれば放っておけばいいだけです。冗長であれば後で消しましょう。

6. 抽象的すぎる要求

間違いやすい書き方：「わかりやすく説明してください」

危険理由：想定する理解レベルがずれてしまう

安全な書き方：「中学生にもわかるように説明してください」や「技術者向けの専門的説明にしてください」など具体化

7. 逆に詳細すぎる指示で本質を見失う

間違いやすい書き方：「3段落で各段落5文ずつ、語尾は『です』で…」

危険理由：本来の目的である内容の正確さや網羅性が犠牲になる

安全な書き方：「全体で読みやすく、必要な情報をもれなく含めてください」

8. 例だけを与えて定義を与えない

間違いやすい書き方：「こんな感じで答えて」＋例文だけ

危険理由：例の意図や制約が正しく伝わらず、誤った模倣をする

安全な書き方：例＋背景やルールを明記

9. 質問の順序や重要度が不明確

間違いやすい書き方：「〇〇と△△について説明してください」

危険理由：どちらを優先するかわからず、片方が省略される可能性

安全な書き方：「まず〇〇、次に△△の順で説明してください」

10. 背景・目的の省略

間違いやすい書き方：「〇〇について文章を作ってください」

危険理由：用途や読者層に合わない文体や内容になる

安全な書き方：「社外向けプレゼン用に、〇〇について説明してください」

11. 「〇〇風に」だけの曖昧なスタイル指定

間違いやすい書き方：「ビジネスメール風に」

危険理由：国や業種によってビジネスメールの基準が異なる

安全な書き方：「日本国内の取引先向け、フォーマルなビジネスメールとして」

12. 禁止事項だけで代替案を示さない

間違いやすい書き方：「専門用語を使わないでください」

危険理由：正確さを犠牲にしてしまう

安全な書き方：「専門用語は避け、必要な場合は括弧で簡単に説明してください」

13. 回答範囲を曖昧に制限

間違いやすい書き方：「最新情報だけ答えてください」

危険理由：「最新」の定義が不明で情報が削られる

安全な書き方：「2025年8月時点での最新情報に基づいて回答してください」

②−２ プロンプト自動作成法

そして、ここまで書いておきながら、実はプロンプトもこっちで作れるので使っていますという情報です。

1. OpenAI Platformにアクセス

+createをクリック

2. Configure クリック

3. ペンマーククリック

4. プロンプト文の作成依頼のための要望をペンマーク記載欄に書く

例：

以下の要件を前提に、コードを記述してください。

1. ビジネス目的・成果物定義

案件名：電子部品工場向け「不良解析支援アプリ＋RAGナレッジアシスタント」

背景：不良率上昇時の原因特定に時間がかかり、ライン停止コストが増大（時間当たり損失 120万円）

目標KPI：①平均原因特定時間（MTTD）を 12時間→3時間、②月次不良率 1.8%→1.2%、③現場問合せの一次応答自動化 40%以上

スコープ：現場ダッシュボード、原因候補提示、是正措置の推奨、ナレッジRAG検索、週次レポート自動生成

納期：6か月（α：2か月、β：4か月、GA：6か月）

2. ユーザー/UX要件

主要ユーザー：製造現場の班長（PC/大型サイネージ）、品質保証（PC/タブレット）、生産技術（PC）

アクセシビリティ：工場現場の高照度・手袋利用を想定し、コントラスト比 4.5:1 以上、32px 以上のクリック領域

ローカライズ：日本語メイン、英語切替あり、タイムゾーン JST

重要フロー：ライン選択→不良傾向確認→RAGで対策検索→是正計画作成→承認→効果検証

3. 機能要件（FR）

ダッシュボード：P95 2秒以内で日次/週次/月次の不良率と上位不良カテゴリを可視化

アラート：閾値逸脱時にSlack/MS Teamsへ通知（閾値はライン別に設定可）

原因候補提示：似た傾向の過去事例 Top3 と、推奨是正措置案

RAG検索：SOP、過去是正報告書、ベンダー仕様書、工程条件表から権限内で横断検索

レポート自動生成：週次の不良サマリ（PDF/Markdown）

監査ログ：検索クエリ、参照文書、採用した対策を証跡化

API 一例：GET /api/v1/defects?line=xx&period=last_7d、POST /api/v1/capa（是正措置登録）

4. 非機能要件（NFR）

性能：P95 応答 1.5s、P99 2.5s、RAG回答は 5s 以内

可用性：SLA 99.95%、RTO 2h、RPO 15m、DR は同一国別リージョン

観測性：構造化ログ、メトリクス（CPU/メモリ/QPS/Queue 深さ）、分散トレーシング、重要な SLO 破綻でPagerDuty通知

プライバシー/法令：機微個人情報なし、工場データは国内保管、越境なし、監査対応のため操作履歴保持 3 年

5. データ要件

ソース：IoT ゲートウェイ（OPC-UA 経由の工程データ）、品質検査 CSV、SOP/PDF、是正報告（Word/Excel）

スキーマ例：defects(line_id, model_id, defect_code, timestamp, lot_no, temp, humidity, operator_id)

品質：時刻同期（NTP）、欠損補間は 1 分粒度まで、それ以上は欠損として扱い

保持：原データ 2 年、集計 5 年、RAG 索引用埋め込みは 90 日ごとに再生成

バックアップ：日次スナップショット、月1回復元訓練

6. アーキテクチャ/技術選定

フロント：Next.js + TypeScript、デザインシステムは社内DS

サーバ：Python FastAPI、ジョブは Celery（または Cloud Tasks）

メッセージング：Pub/Sub（非同期パイプ）

キャッシュ：Redis（セッション/クエリキャッシュ）

依存：Slack/Teams Webhook、社内SOP SharePoint、PDFテキスト抽出（Tesseract/EasyOCR）

7. 実行基盤/インフラ

クラウド：GCP、リージョン：東京（asia-northeast1）、DR：大阪

コンテナ/K8s：GKE Autopilot、イングレスは Cloud Load Balancing、CDN は Cloud CDN

ストレージ/DB：Cloud SQL（PostgreSQL 15, HA）、GCS、BigQuery（集計/解析）

ベクトルDB：pgvector（初期）→ 規模次第で Vertex Matching Engine 検討

ネットワーク：専用VPNで工場と閉域接続、Egress は特定宛先のみ許可

8. セキュリティ/IAM

認証：OIDC（Azure AD）、MFA 必須、パスキー推奨

認可：RBAC（現場/品証/技術/管理者）、行単位のデータフィルタリング

秘密管理：GCP Secret Manager、KMS で鍵管理、90日ローテーション

脅威モデル：注入・XSS・CSRF・IDOR・SSRF 対策、WAF 導入、SBOM 生成・依存脆弱性スキャン

9. 開発プロセス/品質保証

ブランチ：Trunk-Based、PR 必須、Conventional Commits

コード規約：PEP8/Black、ESLint/Prettier

テスト：単体>統合>E2E>負荷、最低カバレッジ 80%、プロパティテストを要点に導入

レビュー基準：APIの破壊的変更禁止、公開スキーマはADR必須

10. CI/CD & リリース

CI：GitHub Actions（ビルド・テスト・SAST・依存スキャン）

CD：Blue-Green（Argo Rollouts 可）、DBマイグレーションは事前 dry-run

ロールバック：直前安定版に自動切替（ヘルスチェック失敗時）

11. 運用/サポート

監視：Cloud Monitoring + Prometheus、SLI/SLO ダッシュボード整備

当番：平日日中は社内 SRE、時間外はオンコール

Runbook：RAG 不調時/埋め込み遅延/パイプ詰まり/閾値調整の手順化

12. ドキュメント/ナレッジ

必須ドキュメント：ADR、OpenAPI、ERD、シーケンス図、運用手順、障害対応手順、ユーザーガイド

Onboarding：30分で環境構築可能な手順（Devcontainer/Makefile）

13. 依存・ライセンス/法務

OSS ポリシー：MIT/Apache2.0 優先、GPL 系は要承認

外部資産：アイコン/フォントは商用可のもの、クレジット表記方針明記

契約：SaaS/API の SLA≥99.9%、DPA 締結

14. ガバナンス/変更管理

重要変更は CAB 承認、重大な機能フラグは監査ログ必須

DORA 指標（デプロイ頻度/変更リードタイム/失敗率/復旧時間）を月次レビュー

15. 体制/スキル/コミュニティ

体制：PM 1、TechLead 1、FE 2、BE 2、Data 1、SRE 1、QA 1

スキル前提：TypeScript/React、Python/FastAPI、SQL、K8s 基本知識

エコシステム：日本語情報が多い技術を優先

16. コスト/予算（FinOps）

初年度上限：開発 1800万円、月次運用 40万円以内

コスト管理：リソースタグ/プロジェクト分割、予算アラート、予約/オートスケール活用

コスト目標：RAG 一回答あたり 1.5円以下（平均）

17. リスク/制約

制約：工場ネットワークは定期メンテで停止あり、越境通信不可

リスク：ベンダーロックイン、人員の属人化、データ品質ばらつき

緩和策：抽象化層、標準化手順、データ品質スコアリングと可視化

18. AI/LLM/MLOps特有

目的：現場向け「是正措置」候補文の提示と根拠提示、ナレッジ横断検索

モデル：日本語強化の GPT 系 or Claude 系 API 利用（社外API利用時はプロンプト/応答を匿名化）

コンテキスト/RAG：SOP・是正報告・ベンダー仕様・工程条件表を対象、分割 512–1024 tokens、メタデータは工程/ライン/不良コード/日付

ガードレール：プロンプト注入対策、権限制御つき検索、出典ハイライト必須、幻覚率と忠実度の回帰テスト

評価：自動評価（Faithfulness, Context Utilization, Answer Relevance）＋人手評価（月1回）

再学習/更新：SOP更新時の増分取り込み、埋め込み再生成は週次

監視：回答時間、引用率、無回答率、危険提示率（リスク文言）を可視化

出力要件

以上をすべて含むこと。

逐次質問ではなく、依頼にそのまま使える完成済みプロンプト文を 1 回で生成すること。

プロンプトの先頭に「目的/前提」、続けて「依頼内容」「受け入れ基準」「注意事項（セキュリティ/法務）」を明示し、最後に「想定 API/画面一覧（概要）」を短く添えてください。

長さ目安：1500–2500字。
」

固定指定（最優先）
1) 技術スタック

Python 3.11 / FastAPI / Uvicorn

PostgreSQL 15 / SQLAlchemy 2.x / Alembic

Redis（任意：キャッシュ/ジョブ用）

Poetry / Ruff / Black / mypy --strict / pytest + coverage

Docker / docker-compose（dev）

GitHub Actions（lint→typecheck→test→build のワークフロー）

2) 生成する“依頼プロンプト文”の必須要素

上記18カテゴリ要件をすべて包含（FR/NFR/運用/セキュリティ/FinOps/RAG など）。

コード実装のガイドライン（フォルダ構成、依存、設定、キー管理、環境変数名）。

**API一覧（エンドポイント/メソッド/入出力/エラーモデル）**を簡潔に列挙。

**DBスキーマ（DDL相当）**とエンティティ関係の要約。

テスト方針（単体/統合/E2E、境界条件、モック/テストデータ）。

観測性（ログ/メトリクス/トレースの最小セット）。

セキュリティ（OIDC前提、最小権限IAM、機密は環境変数orSecret Manager）。

デプロイ/ロールバックの要点。

3) 受け入れ基準

poetry install && poetry run pytest -q が成功すること。

ruff/black/mypy をCIで実行し、失敗しない設定例を提示。

API は /healthz を実装、OpenAPI が /docs で閲覧可能。

サンプル.env（実値は入れない）と Makefile を含める。

4) 出力フォーマット（厳守）

Repository Tree（例）

.
├─ pyproject.toml
├─ README.md
├─ Makefile
├─ docker-compose.yml
├─ Dockerfile
├─ .github/workflows/ci.yml
├─ .env.example
├─ app/
│   ├─ main.py
│   ├─ api/...
│   ├─ core/config.py
│   ├─ db/base.py
│   ├─ models/...
│   ├─ schemas/...
│   └─ services/...
└─ tests/
    ├─ conftest.py
    └─ test_health.py


その後、各ファイルごとに「# path/to/file」ヘッダ → 完全なコードをコードブロックで提示（省略/擬似コード/TODO禁止）。

1レスポンスで収まらない場合は自動的に続きを出力し、全ファイルを出し切る。


5) 参考文献（プロンプトに必ず明記すること）：
- Fielding, Roy T. "Architectural Styles and the Design of Network-based Software Architectures", 2000 （REST API設計の原典）
- PEP 8 – Style Guide for Python Code （Python公式コーディング規約）
- Lewis, Patrick, et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS 2020 （RAGの基本手法）
- Breck, Eric, et al. "The ML Test Score." IEEE BigData 2017 （MLシステム品質保証のチェックリスト）

生成されるプロンプト文には、上記文献名と適用理由を “依頼条件の一部” として必ず書き込むこと

6) 生成スタイル

口調：日本語・丁寧体。

前置き最小、実務者がそのまま使える具体性を優先。

PEP8準拠としてください。
ファイル名・モジュール名は小文字のスネークケース（例：defect_service.py）としてください。
クラスはCapWords、定数はUPPER_CASE、関数・変数はsnake_caseとしてください。

5. 出来上がったプロンプト文を確認

電子部品工場向け「不良解析支援アプリ＋RAGナレッジアシスタント」システム実装依頼

---

【目的／前提】

ライン不良が発生した際に“平均原因特定時間（MTTD）短縮／生産現場対応の自動化”を最大目標とする、電子部品工場に特化した「不良解析支援アプリ ＋ Retrieval-Augmented Generation (RAG)ナレッジアシスタント」のシステム実装を依頼します。  
本アプリは、ダッシュボード・不良原因候補提示・是正措置推奨・工場ナレッジ横断検索（RAG）・レポート自動生成・監査ログ証跡化などを、実運用可能かつ拡張性を持たせた状態で構築します。

本依頼は、以下に示す18分野の業務・技術・非機能要件を全網羅しつつ、下記“固定指定技術スタック”を厳守し、運用現場ですぐPoC/α/β/GAリリース検証が可能な完成度・実行容易性を優先します。  
さらに、REST API設計「Fielding 2000」、Python標準コーディング規約PEP8、RAG実装原則「Lewis+NeurIPS2020」、MLシステム品質基準「Breck+ML Test Score」準拠の構成を要求します。

---

【依頼内容】

- 下記 18カテゴリ全要件（詳細は別紙）を完全に満たすPython 3.11+FastAPI/Uvicorn/PostgreSQL/SQLAlchemy2.x/Alembic/Redis基盤システムの設計・コード実装一式
- 指定のリポジトリツリーに従った全ファイル生成（省略・未実装不可）  
  ┗ .env.example/Makefile/pyproject.toml/CIワークフロー/シードデータ/テスト一式を必ず含めてください
- API+DB+RAGサービス等は拡張可能なDI構成、設定・秘密情報は環境変数分離（.env経由 → GCP Secret Manager/KMSを想定）
- エンドポイント一覧（/api/v1）・DB DDL相当（ERD要約）・CI/CDパイプライン・ガードレール実装（OIDC、RBAC権限判定、エラーハンドリング） を必ず明示
- 観測性（構造化ログ、重要メトリクス、分散トレーシングフック）および追跡性（監査ログ/全操作証跡記録機構）の基本実装
- 東証食全体に対応するユニット/統合/E2Eテスト、特にRAG/AI部分の自動スコア評価
- フォルダ名・ファイル名・クラス名等はPEP8・Pythonコミュニティ標準命名/設計に厳格準拠

---

【受け入れ基準】

- poetry install && poetry run pytest -q で全テストが成功すること
- ruff/black/mypy（--strict）に通りCIが正常終了すること
- API /healthz 実装・OpenAPI schemaが/docs公開・READMEに起動＆接続方法記述あり
- リポジトリルートに .env.example, Makefile, pyproject.toml を含むこと
- 指定フォルダツリー（下記）/ファイル分割を厳守
- セキュリティ/IAM: OIDC（Azure AD）/RBAC/Secrets管理/最小権限の実装
- RAG対策: プロンプト注入防御/権限制御つき検索/引用ハイライト必須
- 設計評価観点：API設計のオープン性（破壊的変更防止・ドキュメント化）、依存明記、3年監査証跡堅牢化
- 参考文献「Fielding 2000」「PEP8」「Lewis+2020」「Breck+2017」いずれも根拠付きでREADME等/ドキュメント中に必ず明記

---

【注意事項（セキュリティ／法務）】

- OIDC/AAD認証、RBAC認可、機密情報はGCP Secret Manager/env変数経由、90日ローテローテ実装
- 操作全ログは3年保持可能な構造化監査証跡として永続化
- IPA・GDPR/JIS寄り工場データ保護、越境通信禁止（国内保管のみ、開発運用IP制限可）
- OSSモジュール/外部API各種MIT/Apache2.0優先（GPL系列利用時はレビューワ必須）
- SaaS/API SLA 99.9%以上、契約/クレジット表記・著作権情報併記

---

【API/画面/DB概要の一覧】

■ API例（OpenAPI自動生成必須）
- GET    /api/v1/defects?line=xx&period=last_7d        …不良実績取得
- POST   /api/v1/capa                                   …是正措置案登録/承認
- GET    /api/v1/rag/search                            …ナレッジ横断全文検索
- POST   /api/v1/login                                 …OIDC認証（トークン発行） 
- GET    /api/v1/reports/weekly                        …週次レポート取得
- GET    /api/v1/auditlogs                             …操作監査履歴
- GET    /healthz                                       …ヘルスチェック

■ 画面イメージ（大項目のみ記載）  
- 現場ダッシュボード（不良/是正傾向・アラート付）
- RAGナレッジ検索＆引用表示（SOP/PDF/報告横断＋出典明示）
- 是正措置プラン作成／承認フロー
- 各種自動PDF・Markdown週報ダウンロード
- 管理（権限・監査・メトリクス）画面

■ DBスキーマ（DDL要約）  
- defects (id, line_id, model_id, defect_code, timestamp, lot_no, temp, humidity, operator_id)
- capa_actions (id, defect_id, proposed_by, approved_by, status, action_detail, created_at)
- rag_sources (id, doc_type, content, line_id, section, metadata, vector_embedding, updated_at)
- audit_logs (id, user_id, operation, resource, timestamp, details)
- users (id, username, role, locale, timezone, is_active)

---

【推奨リポジトリツリー／生成物例】
.
├─ pyproject.toml
├─ README.md
├─ Makefile
├─ docker-compose.yml
├─ Dockerfile
├─ .github/workflows/ci.yml
├─ .env.example
├─ app/
│   ├─ main.py
│   ├─ api/...
│   ├─ core/config.py
│   ├─ db/base.py
│   ├─ models/...
│   ├─ schemas/...
│   └─ services/...
└─ tests/
    ├─ conftest.py
    └─ test_health.py

---  
【必須設計ガイドライン】

- Poetryによるパッケージ・依存管理、Makefile組込による開発環境統一
- core/config.py に各種設定・環境変数一括管理
- テスト: pytestベース、カバレッジ80%以上、プロパティテスト（特にAI/RAG/DB入出力部）明示
- ログ: 標準出力に構造化JSON、分散トレーシングフックはopentelemetry対応
- Docker: dev/test/prod対応分離構成、公式イメージ利用
- CI: GitHub Actionsで「lint（ruff/black）→typecheck（mypy --strict）→test（pytest）→build」ワークフロー
- エラー応答JSON/監査証跡設計（関連ID/ユーザ/操作詳細/タイムスタンプ付き）を共通化
- secrets/.env.exampleには絶対に実値を記述しない
- RBAC設計原則・フィールドレベルデータ制御・OIDC/AAD対応
- RAG部分は分割・転置・権限制御メタデータ設計を厳守（出典ドキュメント/セクション/工程/日時 のメタ付与）

---

【参考文献・適用根拠（一例、必ずREADME等明記すること）】
- Fielding, Roy T. "Architectural Styles and the Design of Network-based Software Architectures", 2000  
  → RESTful API設計/拡張性の骨格指針として全API/モデル構造に適用
- PEP8 – Style Guide for Python Code  
  → 全てのPython実装、命名規約、コード体裁に厳格適用
- Lewis, Patrick, et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS 2020  
  → 工場ナレッジ×RAG横断検索・引用・出典設計/幻覚防除に適用
- Breck, Eric, et al. "The ML Test Score." IEEE BigData 2017  
  → ML/RAG部分の品質担保・自動評価・テスト観点（再現性・忠実度・文脈利用）

---

【レビュー時の総合判定観点】
- 上記要件を全網羅し、設計・運用・法令・性能・運用観測・可監査性・コスト最適性すべてにバランスが取れていること
- 依頼主が即座にCI実行→開発→運用開始可能な水準であること

---

（重要事項の繰り返し：上記は “18要件×運用セキュリティ×FinOps×RAG” 全網羅で、  
技術は Python 3.11/FastAPI/PostgreSQL 15/SQLAlchemy 2.x/Alembic/Poetry/ruff/black/mypy/pytest+coverage/Docker/GitHubActions分野限定、  
リポジトリツリー・API・DB・要求仕様の全てを本文内で明示してください。）

あくまでこのプロンプトの書き方は、コーディングをするときのみに限っています。ただの調査の時などは逆にざっくばらんに様々なやり方を試した方がいい場合もありますし余り気にしていません。色々な結果を見ながら指示を調整してます。

あとがき

何回か書いていくうちに理想とするプロンプトの書きっぷりもわかってくるので、初めから似ている依頼文になっていますが、たとえ異なった形式で書いても効率のいいプロンプトに直してくれるのでこのツールは最短コースのために有用性高いと思っています。

プロンプトについては13例の注意点に気をつけつつ(今でも間違う)、事前調査の結果などからある程度ベストな形が見えてくるので、指定が限定されることの方が多いです。もちろんこの調査の前には、逐次クライアントへのヒアリングをしていかなければならないです。お客様にとっては見えていないリスクが多くあるため、細かい要望を確認することは必須です。（上記例は即興で作っているのでちょっとおかしいかな…）

今日は昼休み投稿チャレンジではないのでゆっくり書けました。
ここまで読んでいただき、ありがとうございました。👋