AIプロンプト詳細
実際のビジネス課題をより速く解決するために設計された、すぐに使える実践的なAIプロンプト。明確なステップ、実証済みのフレームワーク、即実行可能なアクションを含みます。
AIシステム要件&アーキテクチャ・スコープ・クラリファイア
技術的なパターンを選択したりコードを書いたりする前に、システム要件、スコープの境界、およびアーキテクチャ上のニーズを明確にします。

解決する課題
実際の要件が明確になる前に、チームがパターン、ツール、またはインフラの選択に飛びついてしまうため、多くのアーキテクチャ上の決定が誤った方向へ進んでしまいます。このプロンプトは、ユーザーがまず実際のシステムスコープ、ユーザーニーズ、技術的制約、および非機能要件を定義するのを助け、アーキテクチャ上の決定をより合理的なものにします。
要件優先のアーキテクチャ・フレーミング
技術的なパターンやインフラの選択が設計を歪め始める前に、システムが実際に何をしなければならないかを明確にします。
非機能要件のマッピング
早い段階でアーキテクチャの決定を形作るべきパフォーマンス、信頼性、スケーラビリティ、およびメンテナンス性のプレッシャーを表面化させます。
スコープ境界の定義
最初のアーキテクチャ計画に含まれるべきものと、外に留めるべきものを定義することで、早い段階での過剰設計を防ぎます。
AIプロンプト手順
シニア・ソフトウェアアーキテクトおよびシステム設計ストラテジストとして行動してください。
あなたのタスクは、実際の要件、システムのスコープ、ユーザーニーズ、技術的制約、およびアーキテクチャ上の圧力を特定することにより、曖昧な製品またはプラットフォームのアイデアをより明確なアーキテクチャ計画ブリーフに変換することです。
コンテキスト:
システムが実際に何をサポートする必要があるかを理解する前に、チームがパターン、インフラ、またはサービスの分解を選択し始めると、アーキテクチャは通常高価になります。どのようなシステムが構築されているのか、何を行わなければならないのか、どのような制約が重要なのか、そして現在どのようなアーキテクチャの複雑さが正当化されるのかを明確にするための構造化された方法が必要です。出力は、開発者、創業者、または技術チームが、曖昧なシステム思考から、より根拠のあるアーキテクチャ上の意思決定空間へと移行するのを助ける必要があります。
入力:
1. 製品またはアプリケーションのアイデア
2. ターゲットユーザーまたは主なアクター
3. コアユースケースまたはワークフロー
4. 予想されるスケール(判明している場合)
5. 技術的制約(例:チーム規模、予算、デリバリー速度、コンプライアンスのニーズ、レガシーシステム、統合)
6. 主な懸念事項または不明な点
出力要件:
セクション 1 — システムの核となる目的
システムが実際に何のために存在するのかを明確にする。
セクション 2 — 機能要件
最も重要な製品またはワークフローの要件を要約する。
セクション 3 — 非機能要件
信頼性、パフォーマンス、スケーラビリティ、セキュリティ、可用性、またはメンテナンス性のニーズを説明する。
セクション 4 — スコープの境界
最初のアーキテクチャ計画の中に含まれるものと、外に留めておくべきものを定義する。
セクション 5 — アーキテクチャ上のプレッシャーポイント
アーキテクチャの選択を左右する主要な要因を特定する。
セクション 6 — 初期のアーキテクチャ・フレーミング
次の技術的な決定を導くことができる簡潔なアーキテクチャ計画ブリーフを提示する。
ルール:
- アーキテクチャパターンを推奨する前に要件を明確にする
- 理論的な設計の完璧さではなく、実用的なシステムのニーズに焦点を当てる
- 初期段階の計画とチームのアライメントに有用な出力を保つ
- 入力が完全であるかのように振る舞うのではなく、不確実性を表面化させる
期待される成果
機能要件、非機能要件、スコープの境界、アーキテクチャ上のプレッシャーポイント、および設計のベースにしやすい初期のシステムフレーミングを備えた、構造化されたアーキテクチャ計画ブリーフ。
実装ステップ
システムアイデアをビジネスおよび技術的な言葉で説明する
製品のアイデア、主要なユーザー、予想されるワークフロー、および速度、コスト、チーム規模、コンプライアンスなどの重要な制約を入力します。これにより、プロンプトはアーキテクチャが実際にサポートする必要があるものを特定するのに十分なコンテキストを得ることができます。
4–6 分アーキテクチャ計画ブリーフを生成する
ChatGPT、Gemini、またはClaudeでプロンプトを実行し、マイクロサービスやサーバーレスといった特定のパターンを議論する前に、機能要件、非機能要件、およびアーキテクチャ上のプレッシャーポイントを注意深く確認してください。
6–10 分出力を次の設計議論のアライメントに使用する
最終的なアーキテクチャブリーフを、技術計画、ホワイトボーディング、またはプロトタイプの決定のための共有された出発点として扱い、システムが前提ではなく要件に基づいて設計されるようにします。
5–10 分






