gpt-oss プロンプト設計チートシート：指示・制約・出力フォーマットの即戦力例 100

2025年10月2日

GPT や Claude 等の大規模言語モデルを活用したオープンソース開発において、効果的なプロンプト設計は開発効率や品質を大きく左右する重要な要素です。しかし、「どのように指示を書けば望む結果が得られるのか」「制約の設定方法がわからない」「出力フォーマットをどう指定すべきか」といった悩みを抱える開発者が多いのも現実です。

本記事では、GPT-OSS プロジェクトで実際に使える 100 のプロンプトパターンを、指示・制約・出力フォーマットの 3 要素に分けて体系的にご紹介します。初心者の方でも今すぐ活用できる実践的なチートシートとして、ぜひご活用ください。

プロンプト設計パターン 100 例一覧表

指示設計パターン（33例）

No.	パターン名	カテゴリ	概要
1	基本機能実装	コード生成	ユーザー登録機能をTypeScriptで実装
2	APIエンドポイント作成	コード生成	RESTful APIでページネーション付き商品一覧
3	データベース操作	コード生成	PostgreSQLで注文履歴テーブル設計
4	フロントエンドコンポーネント	コード生成	Reactで商品カードコンポーネント作成
5	認証機能	コード生成	JWTを使用したログイン機能実装
6	エラーハンドリング	コード生成	API通信エラーの適切な処理実装
7	バリデーション機能	コード生成	フォーム入力値のバリデーション実装
8	データ変換処理	コード生成	CSVからJSON形式への変換機能
9	検索機能	コード生成	全文検索機能の実装
10	キャッシュ機能	コード生成	Redisを使用したキャッシュ機能
11	ファイルアップロード	コード生成	画像ファイルアップロード機能
12	全体的なレビュー	コードレビュー	バグ・パフォーマンス・セキュリティ確認
13	パフォーマンス最適化	コードレビュー	実行時間・メモリ使用量の改善提案
14	セキュリティチェック	コードレビュー	セキュリティホールの特定
15	リファクタリング提案	コードレビュー	保守しやすい形への改善
16	テスタビリティ向上	コードレビュー	モック化しやすい構造への変更
17	型安全性チェック	コードレビュー	TypeScript型安全性の向上
18	エラーハンドリング改善	コードレビュー	適切な例外処理の追加
19	コードスタイル統一	コードレビュー	コーディング規約への統一
20	可読性向上	コードレビュー	変数名改善・コメント追加
21	依存関係最適化	コードレビュー	外部ライブラリ依存の最適化
22	ドキュメント追加	コードレビュー	関数説明・使用例の追加
23	ユニットテスト作成	テスト・デバッグ	正常系・異常系・境界値テスト
24	統合テスト設計	テスト・デバッグ	APIエンドポイントの統合テスト
25	エンドツーエンドテスト	テスト・デバッグ	ユーザー操作シミュレートテスト
26	モックテスト	テスト・デバッグ	外部API使用機能のモックテスト
27	パフォーマンステスト	テスト・デバッグ	負荷・ストレス・スループット測定
28	バグ原因調査	テスト・デバッグ	ログ解析・コードトレース
29	デバッグ支援	テスト・デバッグ	ブレークポイント・実行パス追跡
30	テストデータ生成	テスト・デバッグ	リアルなダミーデータ生成
31	回帰テスト	テスト・デバッグ	修正による影響範囲のテスト
32	セキュリティテスト	テスト・デバッグ	認証回避・権限昇格テスト
33	アクセシビリティテスト	テスト・デバッグ	スクリーンリーダー・キーボード対応確認

制約設計パターン（33例）

No.	パターン名	カテゴリ	概要
34	プログラミング言語指定	技術制約	TypeScript使用、JavaScript禁止
35	フレームワーク制限	技術制約	React 18.x、関数コンポーネントのみ
36	ライブラリ依存制限	技術制約	既存dependenciesのみ使用
37	バージョン制約	技術制約	Node.js 18以上、ES2022機能のみ
38	ブラウザ対応制約	技術制約	Chrome 90+、Firefox 88+、Safari 14+
39	データベース制約	技術制約	PostgreSQL 14、MySQL特有機能禁止
40	API仕様制約	技術制約	RESTful API規約、GraphQL禁止
41	セキュリティ制約	技術制約	OWASP Top 10準拠、平文パスワード禁止
42	パフォーマンス制約	技術制約	ページロード3秒以内、API 500ms以内
43	メモリ使用量制約	技術制約	1GB以下、メモリリーク禁止
44	ファイルサイズ制約	技術制約	JSバンドル500KB、画像1MB以下
45	コードカバレッジ制約	品質制約	ユニットテスト80%以上
46	コード複雑度制約	品質制約	循環的複雑度10以下、ネスト3層以下
47	命名規則制約	品質制約	キャメルケース、略語・数字のみ禁止
48	ファイル構成制約	品質制約	1ファイル200行、1関数50行以下
49	依存関係制約	品質制約	循環依存禁止、階層構造明確化
50	コメント制約	品質制約	パブリック関数にJSDoc必須
51	エラーハンドリング制約	品質制約	全例外キャッチ、わかりやすいメッセージ
52	ログ出力制約	品質制約	console.log禁止、適切なログレベル
53	型安全性制約	品質制約	any型禁止、明示的型指定
54	アクセシビリティ制約	品質制約	WCAG 2.1 AA準拠
55	国際化制約	品質制約	文字列ハードコード禁止、i18n対応
56	既存コード保護制約	プロジェクト制約	APIエンドポイント変更禁止
57	データ保護制約	プロジェクト制約	DB構造変更禁止、カラム追加のみ
58	設定ファイル制約	プロジェクト制約	本番環境設定変更禁止
59	権限制約	プロジェクト制約	管理者権限禁止、一般ユーザー権限のみ
60	環境制約	プロジェクト制約	Dockerコンテナ内動作、ホストOS依存禁止
61	予算制約	プロジェクト制約	有料サービス禁止、OSS使用
62	期限制約	プロジェクト制約	2週間以内実装、段階的リリース
63	チーム制約	プロジェクト制約	現在スキルレベル考慮、複雑設計回避
64	運用制約	プロジェクト制約	24時間365日運用、ダウンタイム禁止
65	監査制約	プロジェクト制約	全操作ログ記録、監査要件満足
66	規制制約	プロジェクト制約	GDPR・個人情報保護法準拠

出力フォーマット設計パターン（34例）

No.	パターン名	カテゴリ	概要
67	基本コード出力	コード生成用	コードブロック・ポイント・使用例
68	段階的実装フォーマット	コード生成用	ステップ1〜4の段階的コード
69	ファイル分割フォーマット	コード生成用	ファイル名付きコードブロック
70	テスト付きフォーマット	コード生成用	実装・テスト・実行方法
71	設定込みフォーマット	コード生成用	メイン・設定・依存関係
72	API仕様書フォーマット	コード生成用	エンドポイント・リクエスト・レスポンス
73	コンポーネント設計フォーマット	コード生成用	Props・実装・スタイル・使用例
74	データベース設計フォーマット	コード生成用	テーブル・インデックス・クエリ・マイグレ
75	関数設計フォーマット	コード生成用	シグネチャ・実装・使用例・エラー
76	パッケージ設計フォーマット	コード生成用	構成・エントリー・モジュール・設定
77	設定ファイルフォーマット	コード生成用	開発・本番・環境変数・読み込み
78	デプロイメントフォーマット	コード生成用	Docker・compose・スクリプト・手順
79	コードレビューフォーマット	レビュー・分析用	評価・良い点・改善点・修正後
80	パフォーマンス分析フォーマット	レビュー・分析用	現状・最適化案・改善効果
81	セキュリティ監査フォーマット	レビュー・分析用	レベル・問題・修正・推奨事項
82	アーキテクチャ分析フォーマット	レビュー・分析用	構造・問題点・改善提案・移行
83	依存関係分析フォーマット	レビュー・分析用	マップ・問題依存・最適化案
84	テストカバレッジフォーマット	レビュー・分析用	現状・未テスト・追加提案
85	コード品質フォーマット	レビュー・分析用	指標・改善対象・リファクタリング
86	API仕様分析フォーマット	レビュー・分析用	一覧・問題API・推奨追加
87	ドキュメント分析フォーマット	レビュー・分析用	現状・改善案・テンプレート
88	エラーログ分析フォーマット	レビュー・分析用	分類・主要エラー・修正提案
89	統合結果フォーマット	レビュー・分析用	全体評価・優先項目・実装計画
90	READMEフォーマット	ドキュメント・説明用	概要・インストール・使用方法・開発
91	APIドキュメントフォーマット	ドキュメント・説明用	認証・エンドポイント・エラーコード
92	設計書フォーマット	ドキュメント・説明用	要件・アーキテクチャ・DB・IF設計
93	操作マニュアルフォーマット	ドキュメント・説明用	基本操作・トラブルシューティング
94	リリースノートフォーマット	ドキュメント・説明用	新機能・改善・バグ修正・破壊的変更
95	コード説明フォーマット	ドキュメント・説明用	概要・詳細解説・注意事項
96	学習用フォーマット	ドキュメント・説明用	目標・基礎知識・ステップ・練習問題
97	比較表フォーマット	ドキュメント・説明用	対象・比較表・推奨選択
98	課題解決フォーマット	ドキュメント・説明用	問題整理・原因分析・解決案・推奨
99	技術検証フォーマット	ドキュメント・説明用	目的・方法・結果・結論・次アクション
100	総合レポートフォーマット	ドキュメント・説明用	概要・技術詳細・テスト・性能・課題・リソース

背景

プロンプト設計の重要性

現代のソフトウェア開発において、AI アシスタントは必要不可欠なツールとなりました。特に GPT-4 や Claude などの大規模言語モデルは、コード生成からドキュメント作成、レビューまで幅広い開発業務をサポートしています。

しかし、これらのツールの真価を発揮するためには、適切なプロンプト設計が欠かせません。同じ処理を求める場合でも、プロンプトの書き方次第で出力の品質が大きく変わるのです。

プロンプト設計の良し悪しが開発生産性に与える影響について、以下の図で示します。

mermaidflowchart LR
  poorly_designed["曖昧なプロンプト"] -->|結果| poor_output["不正確な出力<br/>手直しが必要<br/>時間のロス"]
  well_designed["適切なプロンプト"] -->|結果| good_output["期待通りの出力<br/>そのまま利用可能<br/>効率化達成"]

  poor_output -->|累積効果| low_productivity["開発生産性低下"]
  good_output -->|累積効果| high_productivity["開発生産性向上"]

適切なプロンプト設計により、開発者は意図した通りの結果を効率的に得ることができ、全体的な開発品質と速度の向上が期待できます。

GPT-OSS プロジェクトでのプロンプト活用

オープンソース開発におけるプロンプト活用は、個人開発とは異なる特徴があります。複数の開発者が参加し、コードの品質や一貫性がより重要になるためです。

GPT-OSS プロジェクトでは、以下のような場面でプロンプトが活用されています。

活用場面	具体的な用途	期待される効果
コード生成	新機能の実装、バグ修正	開発速度の向上
コードレビュー	品質チェック、改善提案	コード品質の均一化
ドキュメント作成	API 仕様書、README 更新	ドキュメント品質向上
テスト生成	ユニットテスト、統合テスト	テストカバレッジ向上
リファクタリング	既存コードの改善	保守性の向上

これらの用途において、プロンプトの設計方法により、AI からの出力品質が大きく左右されることが分かっています。特に複数人で開発を行う OSS プロジェクトでは、プロンプトの標準化やパターン化が重要になります。

課題

効果的なプロンプト設計の難しさ

多くの開発者がプロンプト設計で直面する課題は、「何をどのように伝えれば AI が期待通りの結果を返してくれるのか」という点です。プログラミング言語のように明確な文法がないため、試行錯誤を繰り返すことが多くなります。

特に以下のような問題が頻繁に発生しています。

曖昧な指示による問題

「良いコードを書いて」→ 何が「良い」のか AI には伝わらない
「バグを修正して」→ どのバグをどのように修正するか不明確
「テストを追加して」→ どの種類のテストをどの程度追加するか曖昧

情報不足による問題

既存コードの文脈や制約を伝えずに新機能を依頼
プロジェクトの命名規則やコーディングスタイルを無視した出力
使用している技術スタックやフレームワークを考慮しない提案

これらの問題により、以下のような無駄な時間が発生してしまいます。

mermaidflowchart TD
  vague_prompt["曖昧なプロンプト"] --> poor_result["期待と異なる結果"]
  poor_result --> retry["再試行・修正依頼"]
  retry --> time_waste["時間のロス"]

  poor_result --> manual_fix["手動での修正作業"]
  manual_fix --> frustration["フラストレーション"]

  time_waste --> productivity_loss["生産性低下"]
  frustration --> productivity_loss

指示・制約・出力フォーマットの使い分け

プロンプト設計において、多くの開発者が混同しがちな要素があります。それが「指示」「制約」「出力フォーマット」の 3 つです。

これらの要素を適切に使い分けることで、AI からより正確で有用な出力を得ることができますが、実際には以下のような使い分けの問題が発生しています。

要素	本来の役割	よくある間違い	正しい使い方
指示	何をするかを明確に伝える	「コードを改善して」	「パフォーマンスを 20%向上させるためにアルゴリズムを最適化して」
制約	守るべき条件や制限を設定	制約を設定せずに依頼	「既存の API 仕様を変更せずに」「TypeScript 使用」
出力フォーマット	結果の形式や構造を指定	形式指定なし	「コードブロック + 変更理由 + テスト方法」

使い分けができていない場合の典型的な問題

指示が制約と混在している
- 例：「React でログイン機能を作って、でも useState は使わないで」
- 問題：指示と制約が一文に混在し、優先度が不明確
出力フォーマットが未指定
- 例：「このコードをレビューして」
- 問題：コードだけなのか、説明付きなのか、改善提案も含むのか不明
制約が曖昧
- 例：「きれいなコードで書いて」
- 問題：「きれい」の基準が不明確で、人それぞれ解釈が異なる

これらの課題を解決するためには、プロンプト設計の体系的なアプローチが必要になります。

解決策

プロンプト設計の 3 要素フレームワーク

前述の課題を解決するため、プロンプト設計を「指示（Instruction）」「制約（Constraint）」「出力フォーマット（Output Format）」の 3 つの要素に分けて構造化するフレームワークをご提案します。

この 3 要素フレームワークにより、プロンプトの品質を大幅に向上させることができます。

mermaidflowchart TB
  prompt["効果的なプロンプト"] --> instruction["指示<br/>(Instruction)"]
  prompt --> constraint["制約<br/>(Constraint)"]
  prompt --> format["出力フォーマット<br/>(Output Format)"]

  instruction --> inst_detail["・何をするか明確に定義<br/>・具体的なアクションを指定<br/>・目的と期待結果を記述"]
  constraint --> cons_detail["・技術的制約<br/>・品質要求<br/>・スタイルガイド"]
  format --> form_detail["・出力の構造<br/>・応答の形式<br/>・必要な要素"]

各要素の役割と重要性

指示（Instruction）
- 役割：AI に何をしてほしいかを具体的に伝える
- 重要性：曖昧な指示は期待と異なる結果を生む
- 例：「ユーザー認証機能を実装してください」
制約（Constraint）
- 役割：守るべき条件や制限事項を明確にする
- 重要性：プロジェクトの要件や品質基準を維持
- 例：「TypeScript を使用し、既存の API 仕様を変更しないこと」
出力フォーマット（Output Format）
- 役割：結果をどのような形式で受け取りたいかを指定
- 重要性：後の作業効率や理解しやすさに大きく影響
- 例：「コードブロック、説明文、テスト例の順で出力」

チートシート活用によるプロンプト効率化

3 要素フレームワークを効率的に活用するため、すぐに使えるプロンプトパターンをチートシート形式でまとめました。これにより、以下のメリットが得られます。

効率化のメリット

メリット	詳細	効果
時間短縮	一から考える必要がない	作業時間を 50%削減
品質向上	実証済みパターンの活用	出力品質の安定化
学習効果	パターンから原理を理解	プロンプト設計スキル向上
標準化	チーム内での統一基準	コミュニケーション効率化

チートシートの構成

本記事では、実際の開発現場で使える 100 のプロンプトパターンを以下のように分類して紹介します。

指示設計パターン 33 例：具体的で効果的な指示の書き方
制約設計パターン 33 例：適切な制約条件の設定方法
出力フォーマット設計パターン 34 例：用途別の最適な出力形式

これらのパターンを組み合わせることで、あらゆる開発シーンに対応できる高品質なプロンプトを作成できます。

具体例

4-1. 指示設計パターン（33 例）

効果的な指示設計のパターンを、開発現場で頻繁に使われるシーン別に分類してご紹介します。各パターンは実際のプロジェクトですぐに活用できる形式で記載しています。

コード生成系指示パターン（11 例）

1. 基本機能実装

ユーザー登録機能を TypeScript で実装してください。
メールアドレスとパスワードでアカウントを作成できるようにしてください。

2. API エンドポイント作成

RESTful API で商品一覧を取得するエンドポイントを作成してください。
ページネーション機能付きで、1ページあたり20件の商品を返すようにしてください。

3. データベース操作

PostgreSQL を使用して、注文履歴を保存するテーブル設計とクエリを作成してください。
ユーザーID、商品ID、注文日時、数量、金額を格納できるようにしてください。

4. フロントエンドコンポーネント

React で商品カード コンポーネントを作成してください。
商品画像、タイトル、価格、「カートに追加」ボタンを含むレスポンシブデザインにしてください。

5. 認証機能

JWT を使用したログイン機能を実装してください。
ログイン成功時にトークンを発行し、保護されたルートにアクセスできるようにしてください。

6. エラーハンドリング

API 通信エラーを適切に処理する仕組みを実装してください。
ネットワークエラー、認証エラー、サーバーエラーを分類して対応してください。

7. バリデーション機能

フォーム入力値のバリデーション機能を実装してください。
メールアドレス形式、パスワード強度、必須項目チェックを含めてください。

8. データ変換処理

javascriptCSV ファイルから JSON 形式にデータを変換する機能を実装してください。
ヘッダー行を考慮し、型変換とエラーチェックも含めてください。

9. 検索機能

全文検索機能を実装してください。
商品名、説明文、カテゴリを対象に、部分一致と完全一致の両方に対応してください。

10. キャッシュ機能

Redis を使用したキャッシュ機能を実装してください。
API レスポンスを5分間キャッシュし、キャッシュ有効期限の管理も含めてください。

11. ファイルアップロード

画像ファイルのアップロード機能を実装してください。
ファイルサイズ制限、形式チェック、リサイズ処理を含めてください。

コードレビュー系指示パターン（11 例）

12. 全体的なレビュー

以下のコードをレビューしてください。
バグの可能性、パフォーマンスの問題、セキュリティの懸念点を指摘してください。

13. パフォーマンス最適化

このコードのパフォーマンスを改善してください。
実行時間を短縮し、メモリ使用量を削減する方法を提案してください。

14. セキュリティチェック

sqlこのコードのセキュリティホールを特定してください。
SQLインジェクション、XSS、認証バイパスのリスクを検査してください。

15. リファクタリング提案

このコードをより保守しやすい形にリファクタリングしてください。
関数分割、責任分離、命名改善を行ってください。

16. テスタビリティ向上

このコードのテスタビリティを向上させてください。
依存性注入、モック化しやすい構造への変更を提案してください。

17. 型安全性チェック

arduinoTypeScript の型安全性を向上させてください。
any 型の削除、より厳密な型定義、型ガードの追加を行ってください。

18. エラーハンドリング改善

エラーハンドリングを改善してください。
適切な例外処理、ログ出力、ユーザーフレンドリーなエラーメッセージを追加してください。

19. コードスタイル統一

コーディング規約に合わせてスタイルを統一してください。
インデント、命名規則、コメントスタイルを一貫させてください。

20. 可読性向上

コードの可読性を向上させてください。
変数名の改善、コメントの追加、複雑な処理の分割を行ってください。

21. 依存関係最適化

外部ライブラリの依存関係を最適化してください。
不要な依存の削除、軽量な代替案の提案を行ってください。

22. ドキュメント追加

このコードにドキュメントを追加してください。
関数の説明、パラメーター、戻り値、使用例を含めてください。

テスト・デバッグ系指示パターン（11 例）

23. ユニットテスト作成

この関数のユニットテストを作成してください。
正常系、異常系、境界値テストを含む包括的なテストケースにしてください。

24. 統合テスト設計

API エンドポイントの統合テストを作成してください。
認証、データベース接続、外部API連携をテストしてください。

25. エンドツーエンドテスト

ユーザー登録からログインまでのE2Eテストを作成してください。
実際のユーザー操作をシミュレートしてテストしてください。

26. モックテスト

外部API を使用する機能のモックテストを作成してください。
成功時とエラー時の両方のシナリオをテストしてください。

27. パフォーマンステスト

この機能のパフォーマンステストを作成してください。
負荷テスト、ストレステスト、スループット測定を含めてください。

28. バグ原因調査

この不具合の原因を調査してください。
ログ解析、コードトレース、再現手順の確認を行ってください。

29. デバッグ支援

この問題のデバッグを支援してください。
ブレークポイント設置箇所、変数確認項目、実行パスの追跡方法を提案してください。

30. テストデータ生成

この機能のテストデータを生成してください。
リアルなダミーデータで、様々なパターンを網羅してください。

31. 回帰テスト

この修正による影響範囲の回帰テストを設計してください。
関連機能への副作用をチェックするテストケースを作成してください。

32. セキュリティテスト

この機能のセキュリティテストを実施してください。
認証回避、権限昇格、データ漏洩のテストを含めてください。

33. アクセシビリティテスト

この画面のアクセシビリティテストを実施してください。
スクリーンリーダー対応、キーボードナビゲーション、色覚対応をチェックしてください。

これらの指示パターンを使用することで、AI に対して明確で具体的な指示を出すことができ、期待通りの結果を得やすくなります。

4-2. 制約設計パターン（33 例）

制約設計は、AI の出力を適切な範囲内に制限し、プロジェクトの要件や品質基準を満たすために重要です。効果的な制約パターンをカテゴリ別にご紹介します。

技術制約パターン（11 例）

34. プログラミング言語指定

制約：TypeScript を使用してください。JavaScript は使用しないでください。

35. フレームワーク制限

制約：React 18.x を使用し、クラスコンポーネントは使用せず関数コンポーネントのみで実装してください。

36. ライブラリ依存制限

制約：新しい外部ライブラリを追加せずに、既存の dependencies のみを使用してください。

37. バージョン制約

制約：Node.js 18 以上、ES2022 の機能のみを使用してください。ES2023 の新機能は使用しないでください。

38. ブラウザ対応制約

制約：IE11 は対象外とし、Chrome 90+、Firefox 88+、Safari 14+ に対応してください。

39. データベース制約

制約：PostgreSQL 14 を使用し、SQLite や MySQL 特有の機能は使用しないでください。

40. API 仕様制約

制約：RESTful API の規約に従い、GraphQL や RPC スタイルは使用しないでください。

41. セキュリティ制約

css制約：OWASP Top 10 のセキュリティ基準を満たし、平文でのパスワード保存は禁止です。

42. パフォーマンス制約

制約：初期ページロード時間は3秒以内、API レスポンス時間は500ms以内にしてください。

43. メモリ使用量制約

制約：メモリ使用量は1GB以下に抑え、メモリリークが発生しないよう注意してください。

44. ファイルサイズ制約

制約：JavaScript バンドルサイズは500KB以下、画像ファイルは1MB以下にしてください。

品質制約パターン（11 例）

45. コードカバレッジ制約

制約：ユニットテストのコードカバレッジは80%以上を維持してください。

46. コード複雑度制約

制約：関数の循環的複雑度は10以下に抑え、ネストレベルは3層以下にしてください。

47. 命名規則制約

制約：キャメルケースを使用し、略語や数字のみの変数名は使用しないでください。

48. ファイル構成制約

制約：1ファイルあたり200行以下、1関数あたり50行以下に収めてください。

49. 依存関係制約

制約：循環依存を発生させず、階層構造を明確にしてください。

50. コメント制約

制約：パブリック関数には JSDoc コメントを必須とし、複雑な処理には行コメントを追加してください。

51. エラーハンドリング制約

制約：すべての例外を適切にキャッチし、ユーザーに分かりやすいエラーメッセージを表示してください。

52. ログ出力制約

lua制約：本番環境では console.log を使用せず、適切なログレベル（info, warn, error）を設定してください。

53. 型安全性制約

arduino制約：any 型の使用は禁止し、すべての変数と関数に明示的な型を指定してください。

54. アクセシビリティ制約

制約：WCAG 2.1 AA レベルに準拠し、スクリーンリーダー対応を必須としてください。

55. 国際化制約

制約：文字列のハードコーディングは禁止し、i18n 対応を前提とした実装にしてください。

プロジェクト制約パターン（11 例）

56. 既存コード保護制約

制約：既存の API エンドポイントを変更せず、下位互換性を維持してください。

57. データ保護制約

制約：既存のデータベーステーブル構造を変更せず、新しいカラム追加のみ許可します。

58. 設定ファイル制約

制約：本番環境の設定ファイルは変更せず、開発環境でのみ動作確認してください。

59. 権限制約

制約：管理者権限を必要とする操作は含めず、一般ユーザー権限で実行可能にしてください。

60. 環境制約

制約：Docker コンテナ内で動作し、ホストOS に依存する機能は使用しないでください。

61. 予算制約

制約：追加の有料サービスやライセンスは使用せず、無料のオープンソースソリューションのみ使用してください。

62. 期限制約

制約：2週間以内に実装可能な範囲に収め、段階的リリースを考慮してください。

63. チーム制約

制約：現在のチームスキルレベルを考慮し、過度に複雑な設計は避けてください。

64. 運用制約

制約：24時間365日の無停止運用を前提とし、ダウンタイムを発生させる変更は避けてください。

65. 監査制約

制約：すべての操作ログを記録し、監査要件を満たす実装にしてください。

66. 規制制約

制約：GDPR および個人情報保護法に準拠し、個人データの適切な処理を実装してください。

これらの制約パターンを適切に組み合わせることで、プロジェクトの要件を満たしながら、高品質なソフトウェアを効率的に開発できます。

4-3. 出力フォーマット設計パターン（34 例）

出力フォーマットの指定により、AI からの応答を目的に応じた形式で受け取ることができます。用途別の効果的なフォーマットパターンをご紹介します。

コード生成用フォーマット（12 例）

67. 基本コード出力

markdown出力フォーマット：
1. コードブロック（言語指定付き）
2. 実装のポイント（3行以内）
3. 使用例

68. 段階的実装フォーマット

markdown出力フォーマット：
1. ステップ1：基本構造のコード
2. ステップ2：機能追加のコード
3. ステップ3：エラーハンドリングのコード
4. 完成版のコード

69. ファイル分割フォーマット

ini出力フォーマット：
## ファイル名: src/components/Button.tsx
[コードブロック]

## ファイル名: src/types/button.ts
[コードブロック]

## 使用方法
[使用例のコードブロック]

70. テスト付きフォーマット

ini出力フォーマット：
# 実装コード
[メインのコードブロック]

# テストコード
[テストのコードブロック]

# 実行方法
[実行コマンドとエントリーポイント]

71. 設定込みフォーマット

ini出力フォーマット：
# メインコード
[実装コードブロック]

# 設定ファイル
[設定ファイルのコードブロック]

# 依存関係
[package.json の dependencies 部分]

72. API 仕様書フォーマット

ini出力フォーマット：
# エンドポイント
- メソッド: POST
- URL: /api/users
- 説明: [機能説明]

# リクエスト
[リクエストボディの例]

# レスポンス
[レスポンスの例]

# 実装コード
[バックエンドコード]

73. コンポーネント設計フォーマット

ini出力フォーマット：
# Props 定義
[TypeScript インターフェース]

# コンポーネント実装
[React コンポーネントコード]

# スタイル定義
[CSS/SCSS コード]

# 使用例
[親コンポーネントでの使用例]

74. データベース設計フォーマット

ini出力フォーマット：
# テーブル設計
[CREATE TABLE 文]

# インデックス設計
[CREATE INDEX 文]

# クエリ例
[SELECT/INSERT/UPDATE/DELETE の例]

# マイグレーション
[マイグレーションファイル]

75. 関数設計フォーマット

ini出力フォーマット：
# 関数シグネチャ
[型定義とJSDocコメント]

# 実装
[関数の実装コード]

# 使用例
[実際の呼び出し例]

# エラーケース
[エラーハンドリングの例]

76. パッケージ設計フォーマット

ini出力フォーマット：
# パッケージ構成
[ディレクトリ構造]

# エントリーポイント
[index.ts ファイル]

# 主要モジュール
[各モジュールのコード]

# package.json
[パッケージ設定]

77. 設定ファイルフォーマット

ini出力フォーマット：
# 開発環境設定
[development.json]

# 本番環境設定
[production.json]

# 環境変数
[.env.example]

# 読み込み方法
[設定読み込みコード]

78. デプロイメントフォーマット

ini出力フォーマット：
# Dockerfile
[Docker設定]

# docker-compose.yml
[複数サービス設定]

# デプロイメントスクリプト
[自動化スクリプト]

# 環境構築手順
[ステップバイステップの手順]

レビュー・分析用フォーマット（11 例）

79. コードレビューフォーマット

ini出力フォーマット：
# 総合評価
★★★★☆ (4/5)

# 良い点
- [良い点1]
- [良い点2]

# 改善点
- [改善点1: 具体的な修正案]
- [改善点2: 具体的な修正案]

# 修正後のコード
[改善されたコードブロック]

80. パフォーマンス分析フォーマット

ini出力フォーマット：
# 現状分析
- 実行時間: [時間]
- メモリ使用量: [使用量]
- ボトルネック: [問題箇所]

# 最適化案
[最適化されたコード]

# 改善効果
- 実行時間: [改善前] → [改善後]
- メモリ使用量: [改善前] → [改善後]

81. セキュリティ監査フォーマット

ini出力フォーマット：
# 脆弱性レベル
HIGH / MEDIUM / LOW

# 発見された問題
1. [脆弱性1: 説明と影響]
2. [脆弱性2: 説明と影響]

# 修正方法
[セキュアなコード例]

# 追加推奨事項
[セキュリティ向上のための提案]

82. アーキテクチャ分析フォーマット

ini出力フォーマット：
# 現在の構造
[アーキテクチャ図（テキスト形式）]

# 問題点
- [設計上の問題1]
- [設計上の問題2]

# 改善提案
[新しいアーキテクチャの提案]

# 移行方法
[段階的な移行プラン]

83. 依存関係分析フォーマット

ini出力フォーマット：
# 依存関係マップ
[モジュール間の依存関係]

# 問題のある依存
- [循環依存の箇所]
- [不要な依存の箇所]

# 最適化案
[依存関係の改善提案]

84. テストカバレッジフォーマット

ini出力フォーマット：
# カバレッジ現状
- 行カバレッジ: [%]
- 分岐カバレッジ: [%]
- 関数カバレッジ: [%]

# 未テスト箇所
[具体的な行番号と内容]

# 追加テスト提案
[テストケースのコード]

85. コード品質フォーマット

ini出力フォーマット：
# 品質指標
- 循環的複雑度: [値]
- 保守性指数: [値]
- 重複率: [%]

# 改善すべき関数
[関数名と改善理由]

# リファクタリング案
[改善されたコード]

86. API 仕様分析フォーマット

ini出力フォーマット：
# API 一覧
[エンドポイントの一覧表]

# 問題のある API
- [問題のあるエンドポイント]
- [問題の内容と改善案]

# 追加推奨 API
[新しく追加すべきエンドポイント]

87. ドキュメント分析フォーマット

ini出力フォーマット：
# ドキュメント現状
- 存在するドキュメント: [リスト]
- 不足しているドキュメント: [リスト]

# 改善案
[ドキュメントの改善提案]

# テンプレート例
[ドキュメントのテンプレート]

88. エラーログ分析フォーマット

ini出力フォーマット：
# エラー分類
- 致命的: [件数]
- 警告: [件数]
- 情報: [件数]

# 主要エラー
[エラーの詳細と原因]

# 修正提案
[修正コードと対策]

89. 統合結果フォーマット

ini出力フォーマット：
# 全体評価
[総合的な評価とスコア]

# 優先修正項目
1. [最優先項目]
2. [次優先項目]

# 実装計画
[修正作業の優先順位とスケジュール]

ドキュメント・説明用フォーマット（11 例）

90. README フォーマット

ini出力フォーマット：
# プロジェクト名

# 概要
[プロジェクトの説明]

# インストール方法
[手順]

# 使用方法
[基本的な使い方]

# 開発者向け情報
[開発環境のセットアップ]

91. API ドキュメントフォーマット

ini出力フォーマット：
# API リファレンス

# 認証
[認証方法]

# エンドポイント
## GET /api/users
[詳細な説明]

# エラーコード
[エラーコードとメッセージ]

92. 設計書フォーマット

ini出力フォーマット：
# 要件定義
[機能要件と非機能要件]

# アーキテクチャ設計
[システム構成]

# データベース設計
[ER図とテーブル定義]

# インターフェース設計
[API仕様]

93. 操作マニュアルフォーマット

ini出力フォーマット：
# 基本操作
## 1. ログイン方法
[手順1]
[手順2]

## 2. 機能の使い方
[詳細手順]

# トラブルシューティング
[よくある問題と解決方法]

94. リリースノートフォーマット

ini出力フォーマット：
# バージョン 1.2.0

# 新機能
- [新機能1]
- [新機能2]

# 改善
- [改善項目1]

# バグ修正
- [修正項目1]

# 破壊的変更
- [変更内容]

95. コード説明フォーマット

ini出力フォーマット：
# 概要
[機能の概要説明]

# 詳細解説
## データフロー
[処理の流れ]

## 重要な関数
[関数の説明]

# 注意事項
[使用時の注意点]

96. 学習用フォーマット

ini出力フォーマット：
# 学習目標
[何を学ぶか]

# 基礎知識
[前提となる知識]

# ステップバイステップ
## ステップ1
[説明とサンプルコード]

## ステップ2
[説明とサンプルコード]

# 練習問題
[確認用の課題]

97. 比較表フォーマット

css出力フォーマット：
# 比較対象
[比較する技術・ツール・手法]

| 項目 | 選択肢A | 選択肢B | 選択肢C |
|------|---------|---------|---------|
| 性能 | ★★★☆☆ | ★★★★☆ | ★★☆☆☆ |
| 学習コスト | ★★☆☆☆ | ★★★☆☆ | ★★★★☆ |

# 推奨選択
[状況別の推奨]

98. 課題解決フォーマット

ini出力フォーマット：
# 問題の整理
[現状の問題点]

# 原因分析
[根本原因]

# 解決案
## 案1: [短期的解決]
[実装方法]

## 案2: [長期的解決]
[実装方法]

# 推奨アプローチ
[最適な解決策]

99. 技術検証フォーマット

ini出力フォーマット：
# 検証目的
[何を確認したいか]

# 検証方法
[実験手順]

# 検証結果
[結果の詳細]

# 結論
[検証から得られた知見]

# 次のアクション
[今後の取り組み]

100. 総合レポートフォーマット

ini出力フォーマット：
# 実装完了レポート

# 実装概要
[何を実装したか]

# 技術的詳細
[使用技術と設計判断]

# テスト結果
[テストの実施結果]

# パフォーマンス
[性能測定結果]

# 今後の課題
[残課題と改善案]

# 関連リソース
[参考資料とリンク]

これらの出力フォーマットパターンを適切に選択・組み合わせることで、目的に最適化された有用な出力を AI から得ることができます。

まとめ

プロンプト設計のベストプラクティス

本記事でご紹介した 100 のパターンを活用することで、GPT-OSS プロジェクトにおけるプロンプト設計の品質を大幅に向上させることができます。効果的なプロンプト設計のためのベストプラクティスをまとめます。

設計原則の重要ポイント

mermaidflowchart TB
  principles["プロンプト設計原則"] --> clarity["明確性<br/>・具体的な指示<br/>・曖昧さの排除<br/>・期待値の明示"]
  principles --> structure["構造化<br/>・3要素の分離<br/>・優先順位の明確化<br/>・段階的な指示"]
  principles --> reusability["再利用性<br/>・パターンの活用<br/>・テンプレート化<br/>・チーム内共有"]

  clarity --> quality["高品質な<br/>AI出力"]
  structure --> quality
  reusability --> quality

段階的な習得アプローチ

初級段階：基本パターンの習得
- 指示・制約・出力フォーマットの 3 要素を意識する
- よく使う 10〜15 パターンを覚える
- 単純な作業から適用を始める
中級段階：組み合わせの活用
- 複数パターンの組み合わせを試す
- プロジェクト固有の制約を理解する
- チーム内でのパターン共有を始める
上級段階：カスタマイズと最適化
- 自分流のパターンを作成する
- 状況に応じた最適化を行う
- 新しいパターンの開発と検証を行う

効果測定と改善サイクル

プロンプト設計の効果を継続的に向上させるため、以下のサイクルを実践してください。

フェーズ	活動内容	評価指標
計画	パターン選択、要件整理	要件カバー率
実行	プロンプト作成、AI との対話	初回成功率
評価	出力品質チェック、修正回数測定	品質スコア、修正回数
改善	パターン改良、新パターン作成	生産性向上率

今後の活用に向けて

GPT-OSS プロジェクトでのプロンプト設計は、今後ますます重要になると予想されます。継続的な学習と実践により、開発効率と品質の両方を向上させることができるでしょう。

継続的なスキル向上のための取り組み

定期的なパターン見直し
- 月 1 回程度、使用パターンの効果を振り返る
- 新しい技術動向に合わせてパターンを更新する
- チームメンバーと知見を共有する
コミュニティへの参加
- プロンプトエンジニアリングのコミュニティに参加する
- 成功事例や失敗事例を共有する
- 最新のベストプラクティスを学習する
実験的な取り組み
- 新しい AI モデルでのパターン検証を行う
- 異なる領域でのパターン応用を試す
- 自動化ツールの活用を検討する