ユーザーマニュアル・技術ガイド作成
ユーザーマニュアル作成プロンプト
以下の情報をもとにユーザーマニュアルを作成してください：
【システム概要】
{システムの目的や主な機能}
【対象ユーザー】
{マニュアルの対象ユーザーの特性やIT知識レベル}
【主要機能】
{マニュアルで説明すべき主な機能やタスク}
【利用環境】
{推奨ブラウザやデバイスなどの利用環境}
【スクリーンショット情報】
{スクリーンショットが必要な画面の説明（実際の画像は別途用意）}
【出力形式】
- はじめに（マニュアルの目的と対象）
- システム概要
- 利用開始方法（ログイン手順など）
- 機能別の操作手順
- 主要機能1の使い方
- 主要機能2の使い方
- ...
- よくある質問（FAQ）
- トラブルシューティング
- お問い合わせ先
- 用語集
- 索引
技術ガイド作成プロンプト
以下の情報をもとに技術ガイドを作成してください：
【システム概要】
{システムの目的と技術概要}
【対象読者】
{技術ガイドの対象者（開発者、運用者など）とスキルレベル}
【システムアーキテクチャ】
{システムの構成要素と相互関係}
【技術スタック】
{使用している技術、言語、フレームワーク、ライブラリなど}
【環境要件】
{開発環境、テスト環境、本番環境の要件}
【出力形式】
- はじめに（ガイドの目的と対象）
- システムアーキテクチャ概要
- 環境構築手順
- 開発環境のセットアップ
- テスト環境のセットアップ
- 開発ガイドライン
- コーディング規約
- ビルドプロセス
- テスト方法
- API仕様
- エンドポイント一覧
- リクエストレスポンス形式
- 認証方法
- データモデル説明
- デプロイ手順
- 拡張・カスタマイズ方法
- トラブルシューティング
- ベストプラクティス
- よくある質問（FAQ）
- 参考リソース
API仕様書作成プロンプト
以下の情報をもとにAPI仕様書を作成してください：
【API概要】
{APIの目的と主な機能}
【認証方式】
{APIの認証方法（APIキー、OAuth2.0など）}
【エンドポイント情報】
{主要なエンドポイントと機能の概要}
【データ形式】
{リクエストレスポンスのデータ形式（JSON、XMLなど）}
【エラーハンドリング】
{エラーレスポンスの形式とエラーコード体系}
【出力形式】
- API概要
- 目的と機能
- バージョン情報
- ベースURL
- 認証・認可
- 認証方式の詳細
- アクセストークンの取得方法
- 権限スコープ
- エンドポイント一覧
- 各エンドポイントの詳細
- URIパターン
- HTTPメソッド
- 説明
- リクエストパラメータヘッダ
- リクエストボディのスキーマ
- レスポンスのスキーマ
- ステータスコード
- サンプルリクエストレスポンス
- エラーコード一覧と説明
- レート制限と使用制限
- セキュリティ考慮事項
- サンプルコード
- 変更履歴
インストールガイド作成プロンプト
以下の情報をもとにインストールガイドを作成してください：
【ソフトウェアシステム概要】
{インストール対象のソフトウェアシステムの概要}
【対象環境】
{対応OS、必要なハードウェア要件}
【前提条件】
{インストール前に必要な準備、依存ソフトウェアなど}
【インストール方法】
{インストール方法の概要（パッケージマネージャー、手動インストールなど）}
【特記事項】
{インストール時の注意点や既知の問題}
【出力形式】
- はじめに（ガイドの目的と対象）
- システム要件
- ハードウェア要件
- ソフトウェア要件
- ネットワーク要件
- 前提条件
- 事前に必要なソフトウェア
- アカウント権限
- インストール前の準備
- インストール手順
- ステップバイステップの手順
- コマンドやスクリーンショット説明
- 初期設定
- インストール後の検証
- トラブルシューティング
- よくあるエラーと解決方法
- アンインストール手順
- アップグレード手順
- よくある質問（FAQ）
- サポート情報
運用マニュアル作成プロンプト
以下の情報をもとに運用マニュアルを作成してください：
【システム概要】
{運用対象システムの概要と構成}
【対象読者】
{マニュアルの対象者（運用者、管理者など）}
【運用体制】
{運用体制、役割分担}
【運用環境】
{本番環境、検証環境、バックアップ環境など}
【運用要件】
{可用性、バックアップ、監視などの要件}
【出力形式】
- はじめに（マニュアルの目的と対象）
- システム概要
- システム構成図
- コンポーネント説明
- 運用体制
- 役割と責任
- 連絡体制
- 日常運用手順
- 起動・停止手順
- バックアップ・リストア手順
- 定期メンテナンス作業
- 監視運用
- 監視項目と閾値
- アラート対応手順
- 障害対応
- 障害検知の方法
- 初動対応手順
- エスカレーションフロー
- 復旧手順
- 変更管理
- 変更手順
- リリース手順
- ロールバック手順
- セキュリティ運用
- アカウント管理
- セキュリティパッチ適用
- リソース管理
- 運用ツールの使用方法
- 定期的な検証作業
- 報告手順と報告フォーマット
- 付録（コマンドリファレンス、設定ファイル説明など）
トラブルシューティングガイド作成プロンプト
以下の情報をもとにトラブルシューティングガイドを作成してください：
【システム概要】
{トラブルシューティング対象のシステム概要}
【対象読者】
{ガイドの対象者と必要なスキルレベル}
【主な問題カテゴリ】
{よく発生する問題の種類やカテゴリ}
【診断ツール】
{利用可能な診断ツールやログ}
【運用環境】
{システムの運用環境の概要}
【出力形式】
- はじめに（ガイドの目的と使い方）
- トラブルシューティングの基本アプローチ
- 情報収集の方法
- ログの確認方法
- システム状態の確認方法
- ユーザーからの情報収集
- 問題カテゴリ別の対応手順
- 接続問題
- パフォーマンス問題
- 機能障害
- データ不整合
- セキュリティインシデント
- 各問題パターンの詳細
- 症状
- 考えられる原因
- 診断手順
- 解決策
- 予防策
- エスカレーションすべき状況と手順
- よくある質問（FAQ）
- 重要なログメッセージと意味
- 診断ツールの使用方法
- 参考リソースとサポート情報
リリースノート作成プロンプト
以下の情報をもとにリリースノートを作成してください：
【製品システム名】
{製品またはシステムの名称}
【バージョン】
{リリースするバージョン番号}
【リリース日】
{リリース予定日または実際のリリース日}
【変更内容】
{主な変更点、新機能、修正された不具合など}
【互換性情報】
{後方互換性に関する情報、移行時の注意点}
【出力形式】
- リリース概要（新バージョンの主な特徴を簡潔に）
- 新機能
- 各新機能の説明と利点
- 使用方法の簡単な説明
- 改善点
- 既存機能の改善内容
- パフォーマンス改善など
- 修正された不具合
- 主要な修正不具合の説明
- 影響と修正内容
- 既知の問題
- 未解決の問題点
- 回避策（ある場合）
- 非推奨・削除された機能
- 互換性情報
- バージョン間の互換性
- 移行時の注意点
- システム要件の変更
- インストール・アップグレード手順
- 追加リソース（ドキュメント、サポート情報）
- 謝辞
リリース・運用
リリース計画作成プロンプト
以下の情報をもとにリリース計画を作成してください：
【リリース対象】
{リリースする製品システム機能の概要}
【リリーススコープ】
{リリースに含まれる機能や修正の範囲}
【リリース予定日】
{目標とするリリース日}
【関係者】
{リリースに関わるステークホルダーや担当者}
【環境情報】
{リリース対象環境の情報}
【出力形式】
- リリース概要
- リリーススケジュール
- マイルストーンと日程
- クリティカルパス
- リリース前の準備作業
- テスト計画
- リリース判定基準
- 承認プロセス
- リリース作業計画
- 詳細なタスクリスト
- 担当者と役割
- タイムライン
- リスク分析
- 主要リスクと対策
- コンティンジェンシープラン
- リリース後の検証計画
- ロールバック計画
- ロールバックの判断基準
- ロールバック手順
- コミュニケーション計画
- 内部コミュニケーション
- 外部コミュニケーション（顧客向け）
- リリース成功基準
- リリース後のフォローアップ
デプロイ手順書作成プロンプト
以下の情報をもとにデプロイ手順書を作成してください：
【システム概要】
{デプロイ対象のシステムの概要}
【デプロイ環境】
{デプロイ先の環境情報}
【デプロイ内容】
{デプロイする対象（コード、DB変更など）}
【デプロイ方式】
{デプロイの方式（手動、自動、ブルーグリーンなど）}
【前提条件】
{デプロイ前に必要な準備や条件}
【出力形式】
- デプロイ概要
- 目的と範囲
- デプロイ方式の説明
- 準備作業
- 前提条件の確認
- 必要な権限や認証情報
- バックアップ手順
- デプロイ前の確認事項
- チェックリスト
- デプロイ手順
- ステップバイステップの詳細手順
- 実行コマンドやツールの使用方法
- 待機時間や注意点
- デプロイ後の確認
- 動作確認手順
- 監視項目
- 問題発生時の対応
- エラーパターンと対処法
- ロールバック手順
- 報告事項と報告先
- 付録
- リファレンスコマンド
- 設定ファイル情報
障害対応手順書作成プロンプト
以下の情報をもとに障害対応手順書を作成してください：
【システム概要】
{対象システムの概要と構成}
【想定障害】
{想定される主な障害パターン}
【システム監視】
{障害検知のための監視方法}
【対応体制】
{障害対応の体制、役割分担}
【優先度・影響度の基準】
{障害の優先度・影響度を判断する基準}
【出力形式】
- 障害対応の基本方針
- 障害対応体制
- 役割と責任
- 連絡体制図
- エスカレーションフロー
- 障害検知の方法
- 監視アラートの種類と確認方法
- 利用者からの申告対応
- 障害発生時の初動対応
- 初動確認項目
- 初期切り分け手順
- 緊急対応判断基準
- 障害種別ごとの対応手順
- ハードウェア障害
- ネットワーク障害
- アプリケーション障害
- データベース障害
- セキュリティインシデント
- 障害報告の方法
- 一次報告の内容と期限
- 進捗報告の頻度と内容
- 最終報告の内容
- 復旧確認手順
- 事後分析と再発防止
- 原因分析の方法
- 再発防止策の検討方法
- 報告書テンプレート
監視設定プランニングプロンプト
以下の情報をもとにシステム監視設定プランを作成してください：
【システム概要】
{監視対象システムの概要と構成}
【監視要件】
{可用性、性能、セキュリティなどの監視要件}
【運用体制】
{監視・運用体制、対応可能時間など}
【既存ツール】
{利用可能な監視ツールや基盤}
【主要業務】
{システムの主要業務とクリティカル度}
【出力形式】
- 監視方針の概要
- 監視対象コンポーネント
- サーバー（物理仮想）
- ネットワーク機器
- ミドルウェア
- アプリケーション
- データベース
- 外部連携システム
- 監視項目と閾値
- リソース監視（CPU、メモリ、ディスクなど）
- サービス稼働監視
- ログ監視
- トランザクション監視
- エンドユーザー監視
- アラート設計
- 重要度の定義
- 通知方法と通知先
- エスカレーション条件
- 監視ツールの設定内容
- 各ツールの役割と対象
- 監視間隔
- 設定パラメータ
- ダッシュボード設計
- レポート設計
- 監視運用プロセス
- 日常点検項目
- アラート対応フロー
- 定期メンテナンス
- 監視の死角と対策
キャパシティプランニングプロンプト
以下の情報をもとにキャパシティプランを作成してください：
【システム概要】
{対象システムの概要と構成}
【現在のリソース使用状況】
{現在のリソース使用率や性能指標}
【成長予測】
{ユーザー数、トランザクション数などの成長予測}
【性能要件】
{応答時間、処理時間などの性能要件}
【主要コンポーネント】
{主要なハードウェアソフトウェアコンポーネント}
【出力形式】
- キャパシティプランの概要と目的
- 現状分析
- 現在のリソース使用状況
- ボトルネックの特定
- 使用率トレンド
- 需要予測
- 成長予測（ユーザー数、トランザクション数など）
- 季節変動の考慮
- イベント影響の考慮
- キャパシティモデル
- リソース要件の計算方法
- 性能と容量のトレードオフ
- コンポーネント別の計画
- コンピューティングリソース（CPU、メモリ）
- ストレージリソース
- ネットワークリソース
- データベースリソース
- 拡張戦略
- スケールアップ vs スケールアウト
- 自動スケーリングの方針
- リソース最適化施策
- パフォーマンスチューニング
- アーキテクチャ改善
- 投資計画とタイミング
- 監視と見直しプロセス
バックアップ・リカバリ計画プロンプト
以下の情報をもとにバックアップ・リカバリ計画を作成してください：
【システム概要】
{対象システムの概要と構成}
【データ重要度】
{データの重要度分類とRPORTO要件}
【現行バックアップ方式】
{現在のバックアップ方法（ある場合）}
【システム環境】
{オンプレミス、クラウド、ハイブリッドなど}
【運用体制】
{運用担当者の体制、スキルレベルなど}
【出力形式】
- バックアップ・リカバリ計画の概要
- データ分類と保護要件
- データの重要度分類
- 各分類のRPO（目標復旧時点）
- 各分類のRTO（目標復旧時間）
- バックアップ戦略
- バックアップ種類（フル、差分、増分）
- バックアップスケジュール
- バックアップ保持期間
- バックアップ対象
- ファイルシステム
- データベース
- 構成情報
- システム状態
- バックアップ方式と手順
- バックアップツールと設定
- バックアップ実行手順
- 自動化の方針
- リカバリ手順
- シナリオ別のリカバリ手順
- リカバリ検証の方法と頻度
- バックアップメディア管理
- メディアの種類と特性
- メディアローテーション
- オフサイト保管
- 災害復旧対策
- セキュリティ対策
- バックアップデータの暗号化
- アクセス制御
- 監視とレポート
- メンテナンスと見直し
DR（災害復旧）計画プロンプト
以下の情報をもとに災害復旧（DR）計画を作成してください：
【システム概要】
{対象システムの概要と重要度}
【ビジネス要件】
{RTO、RPOなどの復旧目標}
【リスク評価】
{想定される災害やリスク}
【現行システム構成】
{現在のシステム構成と冗長性}
【予算・リソース制約】
{DR計画の予算や利用可能なリソース}
【出力形式】
- 災害復旧計画の概要と目的
- リスク評価
- 想定される災害シナリオ
- 各シナリオの影響度
- 復旧目標
- RTO（目標復旧時間）
- RPO（目標復旧時点）
- 優先復旧順位
- DR戦略
- DRサイト環境の選定
- データレプリケーション方法
- 冗長化方式
- DR環境の設計
- DR環境の構成
- 本番環境とDR環境の違い
- 同期方法
- 復旧手順
- DR発動の判断基準
- 初動対応手順
- 詳細な復旧手順
- 本番環境への切り戻し手順
- DR運用
- 平常時の運用手順
- 監視と維持管理
- 訓練計画
- 役割と責任
- DR発動時の体制
- 各担当者の役割
- コミュニケーション計画
- 訓練と検証
- 訓練の種類と頻度
- 検証方法
- 計画の維持と更新
運用自動化計画プロンプト
以下の情報をもとに運用自動化計画を作成してください：
【システム概要】
{自動化対象のシステム概要}
【現在の運用業務】
{現在手動で行われている運用業務}
【運用課題】
{現在の運用における課題や問題点}
【自動化目標】
{自動化によって達成したい目標}
【技術環境】
{利用可能な技術やツール}
【出力形式】
- 運用自動化の全体方針
- 自動化対象業務の選定
- 自動化の優先度評価
- コスト対効果分析
- 自動化ソリューション設計
- 採用する自動化ツール
- アーキテクチャ設計
- 必要なコンポーネント
- 自動化実装計画
- フェーズ分けとロードマップ
- 各フェーズの詳細タスク
- 成功基準
- CICD導入計画
- パイプライン設計
- 自動テスト戦略
- Infrastructure as Code導入計画
- 対象リソース
- コード管理方針
- 監視・アラート自動化
- 監視自動化の範囲
- 自動対応の設計
- 定常オペレーション自動化
- バッチ処理の自動化
- レポート生成の自動化
- 効果測定方法
- KPI設定
- 測定プロセス
- 移行計画
- 並行運用期間の設計
- 検証プロセス
- リスクと対策
保守・改善
レガシーコード対応
レガシーコード分析プロンプト
以下のレガシーコードを分析し、構造と改善点を特定してください：
【コード内容】
{分析対象のレガシーコード}
【言語・フレームワーク】
{コードの言語とフレームワーク}
【システム背景】
{このコードが担う機能や役割}
【課題認識】
{現状認識している問題点や課題}
【出力形式】
- コード概要分析
- 機能と責務
- アーキテクチャの特定
- 設計パターンの特定
- 問題点の特定
- アンチパターン
- コード品質の問題
- パフォーマンスの問題
- セキュリティの問題
- 保守性の問題
- 依存関係分析
- 外部依存
- 内部モジュール間の依存
- リファクタリング候補
- 優先度の高い改善ポイント
- 中長期的な改善ポイント
- コード理解のためのドキュメント化
- 処理フロー
- データフロー
- 主要なロジックの説明
- 改善アプローチの提案
- 短期的な改善策
- 長期的な刷新策
レガシーコードリファクタリングプロンプト
以下のレガシーコードをリファクタリングしてください：
【レガシーコード】
{リファクタリング対象のコード}
【言語・フレームワーク】
{コードの言語とフレームワーク}
【リファクタリング目標】
{改善したい品質特性（可読性、保守性、パフォーマンスなど）}
【制約条件】
{外部のインターフェースを変更できないなどの制約}
【テスト環境】
{テストの有無、テスト方法など}
【出力形式】
- リファクタリング計画
- 段階的なアプローチ
- リスク低減策
- リファクタリング済みコード
- 変更点の説明
- 実施したリファクタリングパターン
- 改善された点
- コード構造の説明
- クラス関数の責務
- データの流れ
- テスト戦略
- 必要なテストケース
- 既存機能の同一性検証方法
- 改善効果の評価
- コード品質の向上
- パフォーマンスへの影響
- 残存する技術的負債
- 今後の改善提案
テクニカルデット分析プロンプト
以下のシステムプロジェクトのテクニカルデット（技術的負債）を分析してください：
【システムプロジェクト概要】
{システムやプロジェクトの概要}
【技術スタック】
{使用している技術、言語、フレームワークなど}
【開発経緯】
{システムの開発経緯や歴史}
【現状の課題】
{認識している問題や課題}
【成果物】
{コード、設計書、テスト、ドキュメントなどの状況}
【出力形式】
- テクニカルデットの概要
- テクニカルデットの分類
- コード品質の負債
- アーキテクチャの負債
- テストの負債
- ドキュメントの負債
- 知識の負債
- インフラの負債
- 各負債の詳細分析
- 負債の内容
- 発生原因
- 影響範囲
- リスク評価
- テクニカルデットの可視化
- 優先度マトリクス
- 依存関係の図示
- 返済計画の提案
- 短期的な対策
- 中期的な対策
- 長期的な対策
- 返済コストと効果の評価
- 技術的負債の蓄積を防ぐための提案
リバースエンジニアリング
コードからの設計復元プロンプト
以下のコードから設計情報を復元してください：
【対象コード】
{リバースエンジニアリング対象のコード}
【言語・フレームワーク】
{コードの言語とフレームワーク}
【復元目的】
{設計復元の目的（ドキュメント化、機能理解、改修準備など）}
【出力形式】
- システム構造の概要
- モジュールパッケージ構造
- 主要なクラスコンポーネント
- アーキテクチャパターンの特定
- 採用されているアーキテクチャスタイル
- 設計パターンの使用箇所
- 機能フロー
- 主要な処理の流れ
- データの流れ
- クラスモジュール間の関係
- 依存関係
- 継承関係
- コンポジション関係
- インターフェース定義
- 公開APIインターフェース
- 外部システムとの連携ポイント
- データモデル
- エンティティとその関係
- データ構造
- 設計上の特記事項
- 特殊な実装や工夫
- 懸念点
- 復元された設計図（テキストでの表現）
- クラス図
- シーケンス図
- コンポーネント図
ブラックボックス分析プロンプト
以下のブラックボックスシステムを分析し、内部構造や動作を推定してください：
【システム概要】
{分析対象システムの概要と目的}
【観測可能な情報】
{API仕様、入出力例、ログ、外部動作など}
【分析目的】
{分析の目的（互換システム構築、連携機能開発など）}
【制約条件】
{分析における制約（時間、法的制約など）}
【出力形式】
- システム概要の再構築
- 推定される機能セット
- 想定されるユースケース
- 内部構造の推定
- 推定されるコンポーネント
- コンポーネント間の関係
- インターフェース分析
- APIインターフェースの詳細分析
- プロトコルの特徴
- データフォーマット
- データモデルの推定
- エンティティと関係
- データフロー
- 処理ロジックの推定
- 主要な処理フロー
- アルゴリズムの特徴
- 状態遷移
- 設計パターンの推定
- 使用されていると思われるパターン
- アーキテクチャの特徴
- 制限と例外の特定
- エラー処理メカニズム
- 制限値
- テスト戦略の提案
- 検証方法
- エッジケース
- 分析の信頼性評価
- 確度の高い推定
- 不確かな推定
類似システム分析プロンプト
以下の既存システムと類似したシステムの分析と比較を行ってください：
【既存システム情報】
{自社または分析対象となる既存システムの概要}
【類似システム】
{分析対象の類似システムや競合製品}
【分析目的】
{分析の目的（機能比較、改善点発見など）}
【分析観点】
{特に注目すべき観点（UX、機能性、パフォーマンスなど）}
【出力形式】
- 概要比較
- システムの目的と対象ユーザー
- 主要な機能セット
- アーキテクチャの特徴
- 機能比較
- 共通する機能
- 既存システムにない機能
- 類似システムにない機能
- 機能の実装アプローチの違い
- 技術比較
- 使用技術スタック
- アーキテクチャパターン
- インターフェース設計
- データモデル
- ユーザー体験比較
- UIUXの特徴
- ワークフローの違い
- 使いやすさの比較
- パフォーマンス比較
- 応答性
- スケーラビリティ
- リソース効率
- セキュリティ比較
- セキュリティ機能
- リスク対策
- ビジネスモデル比較
- 収益モデル
- 市場アプローチ
- 強み・弱みの分析
- 各システムの優位点
- 各システムの課題点
- 学ぶべき教訓と改善アイデア
モダナイズ（言語変換）
コード移植プロンプト
以下のコードを異なる言語に移植してください：
【元コード】
{移植元のコード}
【元言語】
{移植元のプログラミング言語}
【移植先言語】
{移植先のプログラミング言語}
【移植の目的】
{移植の目的や優先すべき特性}
【制約条件】
{移植における制約や考慮点}
【出力形式】
- 移植後のコード
- 移植アプローチの説明
- 採用した変換戦略
- 特に注意した点
- 言語間の差異への対応
- 構文の違いへの対応
- パラダイムの違いへの対応
- ライブラリAPI差異への対応
- パターン変換の詳細
- クラスオブジェクト構造
- 制御構造
- エラー処理
- 非同期処理
- 同等性の検証方法
- 機能的同等性の確認方法
- エッジケースの考慮
- 最適化の提案
- 移植先言語の特性を活かした改善点
- 追加テストの必要性
モダナイゼーション戦略プロンプト
以下のレガシーシステムのモダナイゼーション戦略を策定してください：
【システム概要】
{モダナイズ対象のシステム概要}
【現行技術スタック】
{現在使用している技術、言語、フレームワークなど}
【問題点】
{現行システムの問題点や課題}
【モダナイズの目的】
{近代化によって達成したい目標}
【制約条件】
{予算、時間、リソース、ビジネス継続性などの制約}
【出力形式】
- モダナイゼーションの全体戦略
- アプローチの選定（リホスト、リファクタ、リプラットフォーム、リアーキテクト）
- フェーズ分けと優先順位
- 技術スタックの選定
- 推奨言語フレームワーク
- クラウドサービスプラットフォーム
- アーキテクチャパターン
- 移行アプローチ
- ビッグバン vs 段階的移行
- ストラングラーパターンの適用
- 並行運用戦略
- モダナイゼーションパターン
- コンポーネント分割戦略
- APIファースト戦略
- データ移行戦略
- ロードマップ
- フェーズごとの目標と成果物
- タイムライン
- マイルストーン
- リスク分析と軽減策
- 技術的リスク
- ビジネスリスク
- スキルギャップ
- 検証と品質保証戦略
- ROI分析
- コスト見積もり
- 期待される効果
- 組織的な考慮事項
- スキル開発戦略
- チーム構成
マイクロサービス移行計画プロンプト
以下のモノリシックシステムをマイクロサービスアーキテクチャに移行する計画を策定してください：
【システム概要】
{現行モノリシックシステムの概要}
【現行アーキテクチャ】
{現在のアーキテクチャ構成と技術スタック}
【課題】
{現行システムの課題や移行の動機}
【ビジネス要件】
{継続性や機能に関するビジネス要件}
【制約条件】
{予算、期間、人的リソースなどの制約}
【出力形式】
- 移行戦略の概要
- ビジョンと目標
- 成功基準
- システム分析
- ドメイン分析
- サービス候補の特定
- 境界づけられたコンテキスト
- サービス分割計画
- マイクロサービスの定義と範囲
- サービス間の依存関係
- APIの設計方針
- データ戦略
- データの分割アプローチ
- 一貫性の確保
- マイグレーション計画
- 移行計画
- フェーズ分け
- ストラングラーパターンの適用方法
- 並行運用戦略
- 技術スタック選定
- 言語とフレームワーク
- コンテナ化戦略
- オーケストレーション
- インフラ計画
- クラウドオンプレミス構成
- CICDパイプライン
- 監視とログ収集
- 運用モデル
- DevOpsアプローチ
- チーム構成
- 責任分担
- リスク分析と対策
- ロードマップとマイルストーン
- 移行後の評価方法
変更の影響調査
コード変更影響分析プロンプト
以下のコード変更による影響範囲を分析してください：
【変更対象コード】
{変更予定のコード箇所}
【変更内容】
{具体的な変更内容}
【システム構成】
{コードが組み込まれているシステムの構成情報}
【コードベース情報】
{依存関係や呼び出し関係など、わかる範囲で}
【出力形式】
- 変更の概要
- 変更の目的と内容
- 修正の種類（バグ修正、機能追加、リファクタリングなど）
- 直接的な影響
- 変更対象の機能・メソッド
- 変更によるインターフェース変更の有無
- 間接的な影響
- 呼び出し元への影響
- 依存コンポーネントへの影響
- 共有リソースへの影響
- データフローへの影響
- 入出力データへの影響
- データ構造への影響
- 非機能面への影響
- パフォーマンスへの影響
- セキュリティへの影響
- 保守性への影響
- テスト範囲の提案
- 単体テストの対象範囲
- 結合テストの対象範囲
- 回帰テストの必要性
- リスク評価
- 変更の複雑さ評価
- 副作用のリスク
- リスク軽減策
- 変更実施計画の提案
- 実施手順
- 検証方法
データベース変更影響分析プロンプト
以下のデータベース変更による影響範囲を分析してください：
【変更内容】
{テーブル構造、インデックス、制約などの変更内容}
【データベース情報】
{データベースの種類、バージョン、サイズなど}
【関連するコード】
{データベースにアクセスするアプリケーションコードの情報}
【依存関係】
{他のテーブルやシステムとの依存関係}
【出力形式】
- 変更の概要
- 変更の目的と内容
- 変更の種類（スキーマ変更、インデックス追加など）
- 直接的な影響
- 変更対象のテーブルオブジェクト
- データ整合性への影響
- 既存データへの影響
- 間接的な影響
- 外部キー制約への影響
- ビュー、ストアドプロシージャへの影響
- ETLプロセスへの影響
- パフォーマンスへの影響
- クエリパフォーマンスへの影響
- インデックス効率への影響
- ロックコンテンションへの影響
- アプリケーション層への影響
- SQLへの影響
- ORMマッピングへの影響
- 参照整合性への影響
- 移行手順
- 変更スクリプト
- データ移行手順
- ロールバック手順
- リスク評価
- 変更の複雑さ評価
- ダウンタイムの見積もり
- データ損失のリスク
- テスト計画
- 検証方法
- テスト環境要件
API変更影響分析プロンプト
以下のAPI変更による影響範囲を分析してください：
【変更内容】
{APIの変更内容（エンドポイント、パラメータ、レスポンスなど）}
【API情報】
{APIの種類、プロトコル、認証方式など}
【利用状況】
{APIの利用者や呼び出し頻度など}
【依存関係】
{他のシステムやサービスとの依存関係}
【出力形式】
- 変更の概要
- 変更の目的と内容
- 変更の種類（破壊的変更かどうか）
- 互換性分析
- 後方互換性の評価
- クライアント側への影響
- 直接的な影響
- 内部システムへの影響
- 外部連携システムへの影響
- インターフェース契約への影響
- 間接的な影響
- 依存するサービスへの影響
- ワークフローへの影響
- エンドユーザーへの影響
- パフォーマンスへの影響
- レスポンス時間への影響
- スループットへの影響
- リソース使用への影響
- セキュリティへの影響
- 認証認可への影響
- データ保護への影響
- ドキュメント・仕様への影響
- バージョニング戦略
- バージョン管理アプローチ
- 移行期間の提案
- 移行計画
- 通知戦略
- 段階的移行の計画
- ロールバック計画
- テスト計画
- 統合テスト計画
- クライアントシミュレーション
チームコミュニケーション
技術レビュー準備プロンプト
以下の情報をもとに技術レビュープレゼンテーションの資料を作成してください：
【レビュー対象】
{レビュー対象のコード、設計、アーキテクチャなど}
【レビューの目的】
{レビューの目的（問題発見、知識共有など）}
【参加者】
{レビュー参加者の役割や技術レベル}
【時間制約】
{レビュー会議の時間的制約}
【重点項目】
{特に重点的にレビューしたい項目や懸念点}
【出力形式】
- レビュー資料の構成
- 導入部分（目的と背景）
- 対象の概要説明
- 設計実装上の重要ポイント
- 技術的な選択肢と決定理由
- 既知の制約や課題
- 質問や議論のポイント
- レビュートピックのリスト
- 各トピックの説明
- トピックの重要度
- 関連する背景情報
- レビュー進行プラン
- タイムテーブル
- 議論の進め方
- 事前準備事項
- 参加者に事前確認してほしいこと
- 必要な資料やツール
- フィードバック収集方法
- フォローアップ計画
技術説明資料作成プロンプト
以下の情報をもとに技術説明資料を作成してください：
【説明対象技術】
{説明したい技術や概念}
【対象者】
{説明対象者の役割や技術レベル}
【説明の目的】
{技術説明の目的（情報共有、意思決定など）}
【時間または分量】
{説明に使える時間や資料の分量の目安}
【具体性レベル】
{概念的な説明か実装詳細までの説明か}
【出力形式】
- 説明資料の構成
- 導入（技術の概要と重要性）
- 背景情報（コンテキスト）
- 主要な概念用語の説明
- 技術の構成要素と機能
- メリットデメリット
- ユースケースと適用例
- 実装導入方法の概要
- 代替技術との比較
- まとめと次のステップ
- 各セクションの詳細内容
- 重要ポイントの説明
- 例示やアナロジー
- 図解の説明（テキストで）
- 質疑応答の想定
- 想定される質問と回答
- 追加リソース
- 参考資料
- 学習リソース
技術選定資料作成プロンプト
以下の情報をもとに技術選定資料を作成してください：
【検討課題】
{解決すべき技術的課題や目的}
【候補技術】
{検討対象となる技術やツールの候補}
【評価基準】
{重視すべき評価項目や基準}
【制約条件】
{予算、スキル、既存システムとの統合など}
【出力形式】
- 課題と目的の整理
- 現状の問題点ニーズ
- 達成すべき目標
- 必須要件と希望要件
- 候補技術の概要
- 各候補の主な特徴
- ユースケースとの適合性
- 評価基準と評価結果
- 機能面の評価
- 非機能面の評価（性能、セキュリティなど）
- コスト評価
- 学習曲線導入難易度
- コミュニティサポート状況
- 将来性持続可能性
- 比較表
- 各候補の評価点
- 長所短所のまとめ
- リスク分析
- 各候補のリスク要因
- リスク軽減策
- 推奨技術と根拠
- 選定結果の提案
- 選定理由の説明
- 導入計画概要
- 導入ステップ
- タイムライン
- 必要なリソース
- 代替オプション
- 次点の候補とその評価
会議ファシリテーションプランプロンプト
以下の情報をもとに技術会議のファシリテーションプランを作成してください：
【会議の目的】
{会議の目的と達成すべき成果}
【参加者】
{参加者の役割、人数、立場}
【議題】
{取り上げるべき議題やトピック}
【時間制約】
{会議の時間的制約}
【背景情報】
{会議の背景や経緯、前提知識}
【出力形式】
- 会議の全体設計
- 目的と期待される成果
- アジェンダ設計
- タイムテーブル
- 議題ごとの進行計画
- 導入方法
- 議論の進め方
- 合意形成に向けたアプローチ
- 時間配分
- ファシリテーション手法
- アイスブレイク案
- 発言の引き出し方
- 議論が停滞した場合の対応
- 対立が生じた場合の調整方法
- 意思決定プロセス
- 決定方法（多数決、合意など）
- 決定事項の記録方法
- 参加者の役割分担
- 書記、タイムキーパーなど
- 事前準備
- 参加者への事前共有事項
- 必要な資料やツール
- 会議後のフォローアップ
- 議事録作成方針
- アクションアイテム管理
- 次回会議への橋渡し
技術調査レポート作成プロンプト
以下の情報をもとに技術調査レポートを作成してください：
【調査対象技術】
{調査対象となる技術や分野}
【調査目的】
{調査の目的や背景}
【調査観点】
{特に注目すべき観点や質問事項}
【対象読者】
{レポートの読者と技術レベル}
【時間または分量】
{レポートの分量の目安}
【出力形式】
- エグゼクティブサマリー
- 主要な発見や結論
- 推奨事項の概要
- 調査の背景と目的
- 調査を行う理由
- 解決すべき課題や疑問
- 調査手法
- 情報源
- 調査アプローチ
- 技術概要
- 基本概念と用語解説
- 歴史的背景
- 現在の状況と採用動向
- 技術の詳細分析
- アーキテクチャ動作原理
- 主要機能と特徴
- 技術的制約と限界
- 実装・導入の考慮点
- 必要なインフラと環境
- 導入コストと工数
- 運用上の考慮点
- 事例研究
- 成功事例
- 失敗事例と教訓
- 比較分析
- 類似技術との比較
- 長所・短所の分析
- 組織への影響
- 必要なスキルと学習コスト
- 既存プロセスへの影響
- リスク分析
- 技術的リスク
- ビジネスリスク
- 結論と提言
- 調査結果のまとめ
- 具体的な提言
- 付録
- 用語集
- 参考文献
技術調査・学習
技術トレンド分析プロンプト
以下の技術分野における最新トレンドと動向を分析してください：
【技術分野】
{分析対象の技術分野（クラウド、AI、Webフロントエンドなど）}
【分析目的】
{分析の目的（技術選定、将来予測、学習計画など）}
【重点領域】
{特に重点的に分析すべき領域}
【応用分野】
{技術の適用を考えている業種や業務}
【出力形式】
- 技術トレンドの概要
- 主要なトレンドと変化の方向性
- 市場動向と普及状況
- 注目すべき個別技術
- 急速に発展している技術
- 衰退しつつある技術
- 新興技術の可能性
- 技術の採用状況
- 大手企業の採用動向
- スタートアップの採用動向
- 業界別の採用傾向
- 企業・コミュニティの動き
- 主要企業の戦略
- オープンソースコミュニティの活動
- 標準化団体の動向
- 技術の成熟度評価
- 実用段階にある技術
- 発展途上の技術
- 実験的段階の技術
- 課題と障壁
- 技術的課題
- 導入障壁
- 社会的・法的課題
- 将来予測
- 短期的見通し（1-2年）
- 中期的見通し（3-5年）
- 組織への示唆
- 投資すべき領域
- スキル開発の方向性
- 戦略的検討事項
技術学習ロードマッププロンプト
以下の情報をもとに技術学習ロードマップを作成してください：
【対象技術スキル】
{学習したい技術やスキル領域}
【現在のレベル】
{現在の知識やスキルレベル}
【目標レベル】
{達成したい知識やスキルレベル}
【時間的制約】
{学習に使える時間や期間の目安}
【学習目的】
{技術を学ぶ目的（業務利用、キャリアアップなど）}
【出力形式】
- 学習目標の明確化
- 短期目標（1-3ヶ月）
- 中期目標（3-6ヶ月）
- 長期目標（6ヶ月以上）
- スキルマップ
- 必須スキル
- 推奨スキル
- 発展的スキル
- 段階的学習計画
- フェーズ1：基礎知識の獲得
- フェーズ2：実践的スキルの習得
- フェーズ3：応用力の向上
- フェーズ4：専門性の確立
- 各フェーズの詳細
- 学習トピック
- 推奨学習リソース（書籍、オンラインコース、ドキュメントなど）
- ハンズオンプロジェクト案
- 習得度の評価方法
- 学習アプローチの提案
- 効果的な学習方法
- 学習の習慣化のコツ
- つまずきやすいポイントとアドバイス
- コミュニティと情報源
- フォローすべき情報源
- 参加すべきコミュニティ
- ネットワーク構築の機会
- 学習の進捗管理
- 進捗確認の方法
- モチベーション維持の工夫
- キャリアパスとの連携
- スキル習得後のキャリア展望
- 次のステップの提案
技術調査計画プロンプト
以下の情報をもとに技術調査計画を作成してください：
【調査対象技術】
{調査対象となる技術や分野}
【調査目的】
{調査の目的（技術選定、導入可能性評価など）}
【調査期間】
{調査に使える期間}
【調査体制】
{調査に携われるリソース（人員、時間など）}
【求める成果物】
{調査結果としてどのようなアウトプットが必要か}
【出力形式】
- 調査計画の概要
- 調査の背景と目的
- 調査範囲と対象
- 期待される成果
- 調査項目の詳細
- 技術概念と基本原理
- 機能と特徴
- ユースケースと適用範囲
- 実装要件と導入コスト
- 運用面の検討事項
- 技術的制約とリスク
- 類似技術との比較
- 調査手法
- 文献調査（技術文書、論文など）
- 事例調査（導入事例、成功失敗分析）
- 実機検証（PoC、プロトタイピング）
- エキスパートインタビュー
- コミュニティ調査
- 調査スケジュール
- フェーズ分け
- タイムライン
- マイルストーン
- 調査体制と役割分担
- 調査担当者と責任範囲
- 外部協力者アドバイザー
- 成果物定義
- 中間レポート
- 最終レポート
- 発表資料
- デモプロトタイプ
- 評価基準
- 技術評価の観点
- 判断基準
- リソース計画
- 必要な環境ツール
- 予算
技術導入ガイドプロンプト
以下の情報をもとに技術導入ガイドを作成してください：
【導入対象技術】
{導入しようとしている技術}
【組織の状況】
{組織の規模、技術レベル、文化など}
【導入目的】
{技術導入の目的や解決したい課題}
【制約条件】
{予算、時間、リソース、既存システムなどの制約}
【出力形式】
- 導入ガイドの概要
- 技術の概要と価値提案
- 導入によって解決される課題
- 期待される効果
- 事前準備
- 組織的準備（体制、権限など）
- 技術的準備（環境、ツールなど）
- スキル準備（トレーニング、採用など）
- 導入アプローチ
- 段階的アプローチの提案
- パイロットプロジェクトの選定基準
- スケールアップ戦略
- 導入ロードマップ
- フェーズ1：計画と準備
- フェーズ2：パイロット実施
- フェーズ3：拡大と統合
- フェーズ4：標準化と最適化
- 各フェーズの詳細なステップ
- 実施事項
- 成功基準
- リスクと対策
- 技術的ガイダンス
- アーキテクチャガイダンス
- 設計・実装ガイドライン
- ベストプラクティス
- 組織変革ガイダンス
- チーム構成と役割
- プロセス変更
- 文化的側面
- 評価とフィードバック
- 導入効果の測定方法
- フィードバックの収集方法
- 継続的改善プロセス
- よくある課題と対策
- 技術的課題
- 組織的課題
- 人的課題
- 成功事例と学び
DevOps・CICD
CICD パイプライン設計プロンプト
以下の情報をもとにCICDパイプラインを設計してください：
【プロジェクト情報】
{プロジェクトの種類、技術スタック}
【開発フロー】
{ブランチ戦略、リリースサイクルなど}
【環境構成】
{開発、テスト、ステージング、本番などの環境情報}
【品質要件】
{コード品質、テスト網羅率などの要件}
【非機能要件】
{パイプラインのパフォーマンス、セキュリティ要件など}
【出力形式】
- CICDパイプラインの全体設計
- パイプラインの概要図（テキストで説明）
- ステージとフローの定義
- ツール選定と構成
- 各ステージの詳細設計
- コードのチェックアウト
- ビルドプロセス
- 静的コード分析
- 単体テスト
- 結合テスト
- セキュリティスキャン
- デプロイメントプロセス
- 環境別の設定
- 開発環境
- テスト環境
- ステージング環境
- 本番環境
- 自動化の範囲
- 完全自動化する部分
- 手動承認が必要な部分
- フィードバックループ
- 通知設定
- レポート生成
- モニタリング連携
- セキュリティ考慮事項
- シークレット管理
- 脆弱性スキャン
- コンプライアンスチェック
- パイプラインの最適化
- パフォーマンス向上策
- コスト効率化
- 実装ガイド
- 設定ファイルのサンプル
- スクリプトの例
- 運用ガイド
- トラブルシューティング
- メンテナンス手順
Infrastructure as Code設計プロンプト
以下の情報をもとにInfrastructure as Code（IaC）を設計してください：
【インフラ要件】
{必要なインフラ構成、リソース}
【環境情報】
{クラウドプロバイダー、リージョン、アカウント構成など}
【アプリケーション要件】
{デプロイするアプリケーションの特性、要件}
【運用要件】
{可用性、セキュリティ、コスト最適化などの要件}
【IaCツール】
{使用するIaCツール（Terraform、CloudFormation、Ansible等）}
【出力形式】
- IaC設計の概要
- 設計方針
- 採用するIaCツールと理由
- 管理対象リソースの範囲
- コード構造設計
- モジュールコンポーネント構成
- 環境分離の方法
- 変数とパラメータ化の方針
- 状態管理の方法
- リソース定義
- ネットワーク構成
- コンピューティングリソース
- ストレージリソース
- データベースリソース
- セキュリティ設定
- モニタリング設定
- パイプラインとの統合
- IaCのCICD
- 検証プロセス
- 承認フロー
- 変更管理
- 変更適用の方法
- ロールバック方法
- ドリフト検出と対応
- セキュリティ考慮事項
- シークレット管理
- 最小権限の原則の適用
- コンプライアンス対応
- 運用考慮事項
- デバッグ方法
- ドキュメント化戦略
- チーム間の協業
- コード例
- 主要リソースの定義例
- モジュール構造の例
- パラメータ化の例
- ベストプラクティス
- 命名規則
- コードレイアウト
- バージョン管理
コンテナ化戦略プロンプト
以下の情報をもとにアプリケーションのコンテナ化戦略を策定してください：
【アプリケーション概要】
{コンテナ化対象のアプリケーション概要}
【技術スタック】
{言語、フレームワーク、データベースなど}
【環境要件】
{開発、テスト、本番環境の要件}
【非機能要件】
{パフォーマンス、スケーラビリティ、セキュリティなど}
【運用体制】
{開発・運用組織の体制、スキルレベル}
【出力形式】
- コンテナ化戦略の概要
- 目的と期待される効果
- アプローチの選定（リファクタリング、リプラットフォームなど）
- コンテナ技術の選定（Docker、Podman等）
- アプリケーション分析
- コンテナ化の適合性評価
- マイクロサービス分割の検討
- 状態管理の方針
- コンテナ設計
- コンテナ構成（サービス分割）
- イメージ設計と最適化
- 環境変数と設定管理
- ボリューム管理
- ネットワーク設計
- オーケストレーション設計
- オーケストレーションツールの選定（Kubernetes、Swarm等）
- クラスタ構成
- デプロイメント戦略
- スケーリング戦略
- CICDパイプライン設計
- イメージビルドプロセス
- テスト自動化
- デプロイメント自動化
- セキュリティ設計
- イメージのセキュリティ対策
- ランタイムセキュリティ
- シークレット管理
- 監視・ロギング設計
- モニタリング戦略
- ログ収集・分析
- アラート設定
- 移行計画
- フェーズ分け
- 検証方法
- ロールバック計画
- 組織的準備
- スキル開発
- 役割と責任の定義
- ワークフロー変更
自動テスト戦略プロンプト
以下の情報をもとに自動テスト戦略を策定してください：
【プロジェクト概要】
{プロジェクトの種類、規模、複雑性}
【技術スタック】
{開発言語、フレームワーク、アーキテクチャ}
【開発プロセス】
{アジャイル、ウォーターフォール、DevOpsなど}
【品質要件】
{品質目標、許容可能なバグレベルなど}
【リソース制約】
{時間、予算、人的リソースの制約}
【出力形式】
- テスト自動化戦略の概要
- 目的と目標
- テストピラミッドの適用方針
- 自動化の範囲と優先順位
- テストレベル別の戦略
- 単体テスト
- 結合テスト
- システムテスト
- 受入テスト
- 非機能テスト
- テスト自動化フレームワークと手法
- ツール選定と理由
- カスタムフレームワークの必要性
- BDDTDDの適用
- テストデータ戦略
- テストデータの生成方法
- データ分離と独立性確保
- 本番データの取り扱い
- テスト環境管理
- 環境の自動プロビジョニング
- 環境の分離と共有方針
- CICDとの統合
- パイプラインでの位置づけ
- 実行タイミングと頻度
- フィードバックループ
- テストメンテナンス戦略
- 保守性を高めるアプローチ
- リファクタリング方針
- 技術的負債の管理
- 品質メトリクスと監視
- テストカバレッジ目標
- テスト実行時間の目標
- 品質ダッシュボード
- テスト組織と役割
- チーム構成
- スキル要件
- 教育・トレーニング計画
- 実装ロードマップ
- 段階的導入計画
- 優先順位と依存関係
- 成功指標と評価方法
カオスエンジニアリング計画プロンプト
以下の情報をもとにカオスエンジニアリング計画を策定してください：
【システム概要】
{対象システムのアーキテクチャと構成}
【耐障害性要件】
{システムの可用性、耐障害性に関する要件}
【運用状況】
{現在の運用状態、過去の障害履歴など}
【リスク許容度】
{実験によるリスクの許容度、影響範囲の制約}
【出力形式】
- カオスエンジニアリングの目的
- 目指すシステム信頼性の向上
- 特定の障害シナリオへの耐性確認
- チームの対応能力向上
- カオス実験の原則と方法論
- 実験設計のフレームワーク
- 仮説の立て方
- 安全な実験範囲の定義
- 実験環境の設計
- 本番環境 vs ステージング環境
- 影響範囲の制限方法
- ロールバック手段
- カオス実験シナリオ
- インフラ障害シナリオ
- サーバー障害
- ネットワーク障害
- ディスク障害
- アプリケーション障害シナリオ
- レイテンシ増加
- エラー率増加
- リソース枯渇
- 依存サービス障害シナリオ
- 外部API障害
- データベース障害
- キャッシュ障害
- 実験実施プロセス
- 事前準備と確認事項
- 実験中のモニタリング
- 実験後の分析と学習
- モニタリングと観測性
- 監視すべきメトリクス
- データ収集方法
- 分析アプローチ
- 組織的準備
- チーム構成と役割
- コミュニケーションプラン
- トレーニング要件
- 自動化と統合
- CICDとの統合
- 定期的な実験の自動化
- リスク管理
- 中止条件（abort conditions）
- エスカレーションプラン
- ロールバック手順
- 導入ロードマップ
- 段階的アプローチ
- 成功指標
運用効率化プランプロンプト
以下の情報をもとにDevOps運用効率化プランを策定してください：
【現状の運用体制】
{現在の開発・運用体制や役割分担}
【問題点・課題】
{現状の開発・運用における問題点や課題}
【使用ツール】
{現在使用している開発・運用ツール}
【目標】
{DevOpsによって達成したい目標}
【制約条件】
{組織的、技術的、予算的な制約}
【出力形式】
- 現状分析
- 開発・運用プロセスの評価
- ボトルネックとその原因
- 自動化可能領域の特定
- コラボレーション上の課題
- 効率化の方向性
- 短期的な改善ポイント
- 中長期的な改善ポイント
- 期待される効果
- プロセス改善
- コードレビュープロセス
- デプロイメントプロセス
- インシデント対応プロセス
- 変更管理プロセス
- 自動化計画
- CICD強化策
- 環境プロビジョニング
- 構成管理の自動化
- テスト自動化
- 監視・アラートの自動化
- ツール選定と統合
- 導入改善すべきツール
- ツール間の統合ポイント
- 使いやすさの向上策
- 組織とカルチャー
- チーム構造の最適化
- コラボレーション強化策
- スキル開発計画
- ナレッジ共有の仕組み
- メトリクスと可視化
- 効率化の測定指標
- 進捗の可視化方法
- フィードバックループ
- 実装ロードマップ
- フェーズ分け
- 優先順位
- マイルストーン
- リスクと対策
- 想定されるリスク
- リスク軽減策