利益:
- AI サポートにより、ミッション要件から概念的な航空機/宇宙船のサイジングまでのトレードオフ研究を加速する機能
- 構成されたプロンプトを使用して要件の作成、トレーサビリティおよび一貫性の管理を実行する機能
- AI が提案した設計ポイントと物理ベースの手計算を相互検証することで、不合理な出力を排除する機能
飛行機や宇宙船は、製図板の上ではなく、要件のリストから生まれます。 「これだけの荷重をこの範囲まで、この速度で、このコストで運ぶ」という一文が、後世に残るデザインの種となるのです。このシードから初期形状を抽出するプロセスが概念設計（車両の大まかなサイズ、重量、形状を最初に決定する設計の初期段階）です。ここで行われる決定は安価ですが、その影響は最も高くつきます。概念的な選択を 1 つ間違えると、何百万ドルもの詳細な設計が無駄になる可能性があります。
この単元では、人工知能 (AI) を使用して、概念的設計の 3 つの負担を軽減します。つまり、あいまいなタスク要求を測定可能な要件に変換すること、要件間のトレーサビリティと一貫性を維持すること、競合する設計オプション間のトレードオフ分析を加速することです。ただし、最初から重要な原則を説明しましょう。AI が提案するすべてのサイズと重量の推定値は、必ず物理ベースの手計算によって相互検証されます。 AI はブレインストーミングと会計のパートナーです。サイズの決定権はありません。
概念: 要件: ツールが満たさなければならない単一の検証可能なステートメント。トレーサビリティ: 各要件がどこから来たのか、どのような設計/テストで満たされたのかを示す一連の記録。トレードスペース: 変更可能な設計変数によって作成されるすべてのオプションのセット。 MTOW：最大離陸重量（最大離陸重量）、車両が離陸できる最大の質量。
タスクのニーズから要件まで: ステップバイステップ
優れた要件には、単一性 (1 つのことを述べている)、測定可能 (数値と単位を含む)、検証可能 (確認方法が明らかである) という 3 つの性質があります。 「航空機は速くなければならない」ということは要件ではありません。 「航空機は海面で口径対気速度（KCAS）250ノットを達成しなければならない」ことが要件となっている。
最初のステップは、利害関係者の要求を収集し、AI を使用してそれらを抽出して要件草案を作成することです。 2 番目のステップは、各要件を測定可能にすることです。各曖昧な形容詞 (「軽量」、「耐久性」、「効率的」) を指標としきい値に置き換えます。 3 番目のステップは、要件間の矛盾を探すことです。航続距離と積載量はしばしば互いに競合しますが、AI はこれらの矛盾をすぐに表面化します。 4 番目のステップは、トレーサビリティ マトリックスを確立することです。つまり、どのトップレベルのタスク目標がどのサブ要件につながるかを表にまとめます。
概念的な寸法設定の面では、AI は既知の工学関係 (重量分率、推力対重量比、翼荷重) を呼び出し、最初の計算チェーンを確立できます。たとえば、旅客機の場合、燃料重量割合はブレゲ距離方程式を使用して推定でき、空重量割合は統計関係を使用して推定できます。ただし、このチェーンの各リンクは手計算によって確認されます。
ヒント: 要件を記述するときは、AI に「各あいまいな形容詞を指標、単位、検証方法に置き換える」というタスクを明示的に与えます。 「ユーザーフレンドリー」などの検証不可能なステートメントを「測定可能にする」と言う場合、モデルはより規律正しく機能します。
トレードオフ分析の構成
トレードオフ分析の中心は、共通の基準を持つ複数の候補構成を並べることです。古典的なツールは加重決定マトリックスです。基準に重要度の重みが与えられ、各候補が各基準でスコアリングされ、加重合計が計算されます。 AI はこのマトリックスをすぐに構築しますが、2 つの落とし穴に注意してください。重みは主観的なエンジニアリングの判断 (AI に任せられない) であり、スコアは物理的な正当化 (作り上げられたものではない) に基づく必要があります。
基準（重量）
構成。 A：ハイウィング
構成。 B: 低翼
構成。 C：カナード
範囲、km (0.30)
1200
1350
1250
車両重量、kg (0.25)
640
610
690
生産コスト (0.20)
中程度
低い
高い
安定性 (0.15)
高い
中程度
中程度
メンテナンスの容易さ (0.10)
高い
中程度
低い
AI にこのテーブルを作成させることができます。ただし、射程距離と重量の数値は独立した予備計算から得られる必要があり、「安定性: 高い」などの定性的なスコアも正当化される必要があります。 AI の能力は、10 個の異なる構成を数分で表にし、センチメント分析 (重みが変化するとランキングがどのように変化するか) を実行できることです。
弱いプロンプト / 強いプロンプト
弱いプロンプト:
練習機を設計しています。最適な構成を教えてください。
強力なプロンプト:
役割: あなたは概念的な航空機設計コンサルタントです。背景: 複座練習機に関する予備的なトレードオフ研究 (値は代表的なもの): 目標航続距離 ~1000 km、巡航速度 ~55 m/s、ペイロード ~220 kg、低生産コスト優先。タスク:1) 3 つの候補構成 (翼の位置、エンジンのタイプ) を提案します。2) 各候補を比較する表を作成します: 航続距離、推定空重量、生産コスト、安定性。3) 数値推定に使用し、関係と仮定を書きます。制約: 重量推定で使用した統計的関係を述べます。書き込みユニット。最終的な決定を下すのではなく、候補を提出してください。私は自分自身で検討し、最終決定を下します。
コピー可能なプロンプトテンプレート
テンプレート 1 — タスクのニーズを測定可能な要件に変換します。
以下の利害関係者の要求を、測定可能かつ検証可能な単一の要件に変換します。要件ごとに、メトリクス、単位、しきい値、および提案される検証方法（分析/テスト/デモ）。曖昧な形容詞（「軽い」、「速い」）を具体的な数字に変換します。不明な点がある場合は、どのような情報が必要かを尋ねてください。リクエスト: [ここにリスト]
テンプレート 2 — トレーサビリティ マトリックスと競合スクリーニング:
この要件のリストを使用して、次のことを行います。 (a) 各要件を高レベルのタスク目標にリンクするトレーサビリティ テーブルを作成します。 (b) 矛盾する要件または困難な要件のペアをマークします (例: 航続距離とペイロード)。 (c) 欠落している要件または検証できない要件をリストします。結果をテーブルにします。要件: [ここにリスト]
テンプレート 3 — 重み付き決定行列のセットアップ:
次の候補構成の重み付け決定マトリックス フレームワークを構築します。基準行と候補列を作成します。体重の欄は空白のままにしておきます（体重を入力します）。各セルに入力するスコアの物理的な正当性を別のメモで説明します。でっちあげの数字は書かず、推測した箇所に「推測」と記入してください。候補者: [...] 基準: [...]
テンプレート 4 — 概念的な寸法のクロスチェック:
次のプレサイジング結果を個別に確認します:MTOW、翼面積、推力。 (a) 翼面荷重 (W/S) を計算し、指定された航空機クラスの一般的な範囲と比較します。 (b) 推力重量比 (T/W) を計算し、それを標準範囲と比較します。 (c) 値が標準範囲外であり、エラーの可能性があることを示す場合は警告します。すべての単位を明示的に記述します。入力: [MTOW、S、T 値]
ミニケース
ケース 1 — 相反するニーズの早期発見。 UAV プロジェクトでは、関係者は「少なくとも 8 時間の飛行時間」と「最大 12 kg の総質量」の両方を望んでいます。 2 つの要件を定量化し、エネルギー予算を大まかに計算することにより、AI は、一般的なバッテリー エネルギー密度 (約 200 Wh/kg) で 8 時間の飛行にはバッテリーだけで 6 ～ 7 kg が必要であることを示しました。これは、積載量と構造を考慮すると、12 kg の予算には収まりません。詳細な設計が始まる前に矛盾について議論されます。教訓: 要件を数値に変換すると、隠れた矛盾が早期に明らかになります。
ケース 2 — 感度分析により決定が変わります。あるチームは 3 つの翼構成を比較します。初期重みを設定します。 B が勝ちます (加重スコア 0.82 対 0.79)。 AI は「コストの重みを 0.20 から 0.10 に減らすとどうなるか」と尋ねられます。このシナリオでは、範囲が前面に出てきて、Config. A がリードします (0.84 対 0.80)。チームは、その決定がコストの優先度に対してどの程度敏感であるかを確認し、関係者との重みを明確にします。教訓: 重要なのは単一のスコアではなく、ランキングの安定性です。
ケース 3 — 重量推定における注文エラー。 AIは関係から軽飛行機の空重量を95kgと出す。この技術者は、同様のクラスの二人乗り航空機の空重量は通常 350 ～ 500 kg の範囲にあると回想しています。 95kgは体力的に無理です。確認すると、AIが関係に誤って係数を適用していたことがわかり、修正されています。教訓: 各重み推定値は、クラスの既知の範囲と桁違いに比較されます。
よくある間違い
- 曖昧な要求を受け入れます。メトリクスと単位が含まれていない要件は検証できません。 「軽いほうがいい」というのは願望であって、必須ではない。
- AIに重みを選択させる。意思決定マトリックスにおける基準の重みは、主観的なエンジニアリングと利害関係者の判断です。 AI に任せると、決定は無視されたままになります。
- 正当な理由なくポイントを受け取ること。 「安定性: 高」のような定性的スコアに物理的な根拠がない場合、マトリックスは推測の派手なリストになります。
- 重量/サイズの推定値は確認していません。統計的相関関係は大まかな推定値です。クラス範囲との比較なしに詳細設計には持ち込まれません。
- トレーサビリティは後回しにします。要件がどこから来たのかが記録されていない場合、変更が将来どのような決定に影響するかは誰にもわかりません。
要約すると
概念設計は、最も安価だが最も効果的な意思決定が行われる段階です。 AI は、曖昧なリクエストを測定可能な要件に変換し、トレーサビリティと競合をスキャンし、トレードオフ テーブル間で複数の構成を比較する強力なアクセラレータです。ただし、基準の重みは人間の判断であり、数値予測は物理ベースの手計算とクラス間隔によって検証され、最終的な構成の決定はエンジニアに委ねられます。 AI が候補者を生成します。決まらない。
アプリケーションタスク
選択した航空機または宇宙船の高レベルのミッション目標を 3 つ書きます。 AI を使用して、これらを少なくとも 6 つの測定可能な要件に変換し、トレーサビリティ テーブルを設定します。次に、3 つの候補構成に対して重み付けされた決定マトリックスを作成します。重みは自分で決めてください。最後に、AI が独自の手計算とクラス範囲で与えた重量/サイズの推定値を確認します。矛盾が見つかった要件のペアを少なくとも 1 つ報告します。
チェックリスト
- [ ] 私は各要件を単一、測定可能、検証可能にしました。
- [ ] 曖昧な形容詞をメートル、単位、しきい値に置き換えました。
- [ ] トレーサビリティ テーブルを設定し、矛盾する要件にマークを付けました。
- [ ] 決定行列の重みを自分で決定しました (AI ではありません)。
- [ ] 私はマトリックスのスコアが物理的な正当化によるものであると考えました。
- [ ] クラス間隔と手計算を使用して、重量とサイズの推定値を検証しました。