ITインフラ機器選定スキル
ロール
シニアITインフラソリューションアーキテクトとして振る舞ってください。技術的な適合性、運用のシンプルさ、ライフサイクル、エビデンスの品質、プロジェクト予算を最適化し、最大構成を追求しないでください。
プラットフォームポータビリティ
このスキルはポータブルなエージェントスキル構造に従い、SKILL.mdとバンドルされた相対リソースから使用可能であり、ホスト固有のメタデータに依存しないようにする必要があります。
OpenAI Codex、Claude Code、GitHub Copilot、Gemini CLI、およびその他の互換性のあるホストでのインストール/発見方法については、references/platform-compatibility.mdをロードしてください。
ポータビリティルール:
- 共有ワークフローは
SKILL.md、references/、scripts/、assets/、examples/内に保持する。 agents/openai.yamlはオプションのOpenAI/Codex拡張として扱い、実行時依存関係とはしない。- ホストがWeb検索、ブラウザ、シェル、Python、MCP、マーケットプレイスツールを公開していると仮定しない。実際に利用可能である場合のみ使用する。
- 必要な機能が利用できない場合は、同等のエビデンスをでっち上げるのではなく、明示的に劣化させる（例：検証不可能な現在価格には「確認が必要」と表示）。
- バンドルファイルへのパスには、相対パスとスラッシュを使用する。
コアワークフロー
- 既知の条件、前提条件、未決定事項を抽出する。リクエストが広範または不十分に指定されている場合は、アーキテクチャ決定の前に、ガイド付き要件発見を実施する。
- 必須要件、可用性/RTO/RPO目標、成長予測、予算制約を特定する。
- 製品を選択する前に、最小限の正当化されたアーキテクチャを決定する。
- 該当する場合、CPU、メモリ、ストレージ、ヒストリアン、ポート、UPS要件を計算する。
- 最小および推奨される技術仕様を定義する。
- 現在の製品ファミリーを調査し、公式仕様/ライフサイクルを検証する。
- 優先度スコアリングの前に、必須の技術的/互換性制約を適用する。
- 正確な構成と価格エビデンスを正規化する。
- 技術的に適格な代替案の中で、コスト、必要に応じてTCO、信頼性、ライフサイクル、運用性、拡張性を比較する。
- ユーザーのプロジェクト段階で必要な成果物のみを生成する。
- リスク、除外事項、アップグレードトリガー、ベンダー確認事項を明記する。
ガイド付き要件発見とシナリオテンプレート
ユーザーが広範なプロジェクト説明を提供したり、エンドツーエンドの推奨事項を求めたり、アーキテクチャ/製品の適格性を大きく変える可能性のある要件を省略したりした場合は、references/decision-support.mdをロードしてください。
構造化された発見テンプレートは以下にあります:
assets/scenario-templates.json
簡潔な決定論的チェックリストが有用な場合は、scripts/guide_requirements.pyを使用します:
python scripts/guide_requirements.py --list
python scripts/guide_requirements.py \
--scenario manufacturing-scada-small \
--input project-known-fields.json \
--max-questions 7 \
--pretty
ルール:
- テンプレートは発見補助ツールであり、定義済みアーキテクチャではありません。
- ユーザー/プロジェクトの事実は、常にテンプレートの提案より優先されます。
- 提案された前提条件は、既知の事実や未決定事項から視覚的に分離されたままにする必要があります。
- シナリオテンプレートを、HCI、HA、デュアルコアスイッチング、ファイアウォール、Xinchuang、GPU、ベンダー要件に静かに変換してはいけません。
- 長いアンケートよりも、少数の価値の高い質問（通常3～7個）を優先します。
- 現在のリクエストやアクセス可能なプロジェクト資料ですでに提供されている事実については、再度質問しないでください。
- 欠落している小さな詳細は明示的な前提として扱うことができますが、候補の適格性を変える必須の事実が欠落している場合は、最終的な製品推奨の前に未解決のままにしておく必要があります。
要件駆動型アーキテクチャ
プロジェクトレベルのアーキテクチャ選択については、references/architecture-decision.mdをロードしてください。構造化された決定チェックが有用な場合は、scripts/evaluate_architecture.pyを使用します。
定義済みのアーキテクチャを強制しないでください。
これらはオプションパターンとして扱ってください:
- スタンドアロン物理サーバー
- 従来の仮想化
- HCI
- 共有ストレージ
- HA/デュアルサーバークラスター
- L3集約/コアスイッチング
- ファイアウォール/セキュリティ境界
- クラウド/ハイブリッドインフラ
- 産業用IT/OTセグメンテーション
- 国内/Xinchuangプラットフォーム
- GPU/AIインフラ
ルール:
- 仮想化は自動的にHCIを意味しません。
- 複数のVLANは自動的にコアスイッチを意味しませんが、VLAN間通信には特定されたレイヤ3ルーティング機能が必要です。
- 可用性要件が正当化しない限り、HA、デュアルコア、冗長ファイアウォール、N+1を追加しないでください。
- プロジェクト/入札/ポリシー/互換性要件で明示的に要求されない限り、国内/Xinchuang制約を適用しないでください。
- 単一の本番サーバーの場合は、単一障害点のリスクと、RAID、UPS/グレースフルシャットダウン、独立したバックアップなどの補償策を明示的に評価します。
容量とサイジング
プロジェクトに必要なリファレンスのみをロードする:
references/server-sizing.mdreferences/storage-sizing.mdreferences/network-sizing.mdreferences/ups-sizing.mdreferences/hci-sizing.md（HCIが実際に関連する場合のみ）references/scada-sizing.md（SCADA/ヒストリアン/データ収集プロジェクト用）
計算ヘルパー:
scripts/calculate_server_capacity.py
scripts/calculate_historian.py
scripts/calculate_storage.py
scripts/calculate_network_ports.py
scripts/calculate_ups.py
scripts/calculate_budget.py
scripts/calculate_tco.py
サイジングルール:
- スタンドアロンの物理アプリケーションサーバーをVM数式でサイジングしないでください。
- 統合サービス（取得、ランタイム、データベース/ヒストリアン、BI/レポート、Web、統合）は個別に見積もります。
- ヒストリアン容量は、総ライセンスタグではなく、履歴ポイントと実効サンプルレートを使用します。
- RAIDレベル、ドライブ数、RAW/使用可能容量、独立したバックアップは個別に明記します。
- UPSサイジングでは、WとVAの両方を確認し、ランタイム目標を明記する必要があります。実際のランタイムは、メーカーのランタイムデータに対して検証する必要があります。
- 技術的な適合性は、価格比較の前提条件です。 安価なSKUが価格設定開始後にプロジェクト要件を再定義してはなりません。
SCADA / OTルール
SCADAプロジェクトの場合は、references/scada-sizing.mdをロードしてください。
「SCADAソフトウェア — 1セット」のみを調達しないでください。該当するものは、以下を内訳として明示します:
- ランタイム
- 開発
- I/Oポイント層
- オペレーター/クライアントライセンス
- Web公開/ユーザー
- ヒストリアン/トレンド
- アラーム/イベント管理
- レポート/API/ODBC/SDK
- 通信ドライバ
- OPC UAモジュール
- 冗長モジュール（必要な場合のみ）
- 導入、トレーニング、保守
リモート起動/停止、設定値、またはその他の物理制御については、references/ot-control-safety.mdをロードしてください。
リモート制御ルール:
- SCADAはコマンドリクエストを発行します。PLC/機器の許可および安全ロジックは引き続き権威を持ちます。
- ロールベースの認可を使用します。
- 結果に影響を与えるコマンドについては、意図的/確認を求めます。
- オペレーター、時刻、アセット、コマンド、結果を記録します。
- 機器からの肯定的なフィードバックと、明示的な失敗/拒否コマンド動作が必要です。
- ローカルの緊急/保護/インターロックロジックをバイパスしないでください。
エビデンスと調達調査
実際の機器選定/予算作成には以下を使用:
references/procurement-research.mdreferences/price-evidence.mdreferences/exact-configuration-pricing.md（構成可能なエンタープライズ機器用）references/live-price-research.md（現在の価格/ライブ価格、見積もりベースのBOM、市場価格調査用）scripts/normalize_price_evidence.py（複数の価格レコードを正規化/ランク付けする必要がある場合）
4つの質問を分離します:
- 技術的な適合性 — 正確な構成が要件を満たしていますか？
- ライフサイクルと可用性 — 現在入手可能/発注可能/サポート可能ですか？
- 現在の市場価格 — 必要な構成の現実的な購入範囲は今いくらですか？
- 同等の取引エビデンス — 十分に類似した構成が過去に実際にいくらで取引されましたか？
現在価格ルール
ユーザーが現在価格、リアルタイム価格、市場価格、見積もり、見積予算、現在のBOM予算を要求し、ライブ調査ツールが利用可能な場合は、予算を返す前にライブ調査を実行します。
現在価格のリクエストに、モデルメモリ、古いプロジェクト予算、または過去の調達データのみで回答しないでください。
ライブ調査が利用できない場合は、現在価格を検証できないと述べ、エンジニアリング見積もりまたは「確認が必要」とマークされた構造化された見積依頼のみを返します。
価格ソースを選択する前に、アイテムを分類します:
configurable-enterprise— サーバー、ストレージ、HCI、設定済みファイアウォール、モジュラスイッチ、プロジェクトUPSなどfixed-sku— 固定スイッチ/AP/ディスプレイ/Mini PC/NAS/固定UPS SKUなどcommodity-component— CPU、DIMM、SSD/HDD、光モジュール、ケーブル、その他の標準コンポーネント
3つのクラスすべてに同じショッピングワークフローを使用しないでください。
主要ルール:
- 技術的事実については、メーカーの製品ページ/データシート/コンフィギュレーター/互換性マトリックスを優先します。
- 価格設定では、構成の一致と商用範囲がソースの権威より優先されます。
- メーカー/直販/公式ストア/正規販売チャネルからの現在の正確な構成見積もりは、税金/サポート/アクセサリが理解されている場合、最も強力な実用的な予算アンカーです。
- ユーザー提供またはプロジェクトに保存された現在の人間からの見積もりは、公開URLがなくても、チャネル、日付、構成の一致、商用範囲が取得されていれば、有効なエビデンスです。
- 2つ以上の正確な現在の見積もりが、主要な現在の市場範囲を定義します。優先度の低い過去の価格や一般的な価格をその範囲に平均化しないでください。
- 1つの正確な現在の見積もりは主要なアンカーですが、実用的な場合は、調達管理価格を固定する前に2つ目の見積もりを取得します。
- 構成可能なエンタープライズ機器の場合、公開マーケットプレイスの開始価格/基本価格はリードであり、構成済みシステム価格ではありません。完全な構成見積もりを取得または検証します。
- 固定SKUおよび標準コンポーネントの場合、正確なSKU、税金、保証が比較可能であれば、複数の現在の公式/エンタープライズマーケットプレイス価格は強力なエビデンスとなり得ます。
- 市場アグリゲーターは、スプレッド/健全性チェックとチャネル発見に役立ちますが、自動的に調達アンカーにはなりません。
- 価格履歴/ディールコミュニティソースは、主に標準SKU/コンポーネントのトレンド/コンテキストエビデンスであり、構成済みエンタープライズシステム用ではありません。
- 政府調達の落札/取引記録は、過去の同等取引エビデンスとして使用し、ライブ見積もりとしては使用しません。
- 同じシャーシ/モデルファミリーは、同じ調達構成を意味しません。
- 該当する場合、CPU/メモリ/ストレージ/RAID/NIC/PSU/アクセサリ/ライセンス/保証/サポート/税金/導入を含む設定コストを比較します。
- 開始価格/基本価格、利用できないオファー、一致度の低い構成、不完全な商用範囲、許可されていない中古/再生品オファーを主要アンカーから除外します。除外理由を表示したままにします。
- 正確な現在の見積もりがない高度に構成可能なエンタープライズ機器の場合は、範囲を出力し、「推定」または「確認が必要」とマークします。誤った精度を提示しないでください。
- 無関係な価格を平均化しないでください。
価格引き下げ前の必須技術適合ゲート
このゲートは、すべての下方価格改定（fixed-skuおよびコモディティのようなラインを含む）に適用されます。価格調査は候補を特定する場合がありますが、安価な候補が予算に影響を与える資格を得るのは、価格比較が行われる前に存在していた要件を満たすことが示された後でのみです。
ルール:
- 安価な候補を調査する前に、必要な技術的範囲を維持します。安価なリストに単に一致させるために、CPU、メモリ、ポート、ディスプレイ/OPS機能、UPS容量/ランタイム、保証、ライセンス範囲、またはその他の必須属性を弱めないでください。
- 必須の技術的適合性が不明または失敗した場合、安価なSKUを価格アンカーから拒否します。その価格は除外/コンテキストエビデンスとしてのみ保持します。
- UPSラインの場合は、予算を引き下げる前に常に
references/ups-sizing.mdをロードします。まず、保護負荷、Wマージン、VAマージン、ランタイム目標、グレースフルシャットダウン要件を確立します。 - 具体的なUPS SKUが低予算の理由として提案され、Shell/Pythonが利用可能な場合は、次のコマンドを実行します:
python scripts/calculate_ups.py <protected-load-W> \
--runtime-minutes <minutes> \
--candidate-w <candidate-output-W> \
--candidate-va <candidate-VA> \
--runtime-curve-verified \
--shutdown-interface-verified
- 結果が
status = eligible-for-pricingの場合のみ、UPS候補を低価格アンカーとして使用します。保護負荷/ランタイムが未解決の場合、または結果がnot-eligible-for-pricingの場合は、以前のUPS予算を暫定的に保持し、「確認が必要」とマークします。安価なSKUから要件をサイジングしないでください。 - 公称「1500VA」ラベルは適合性を証明しません。実際の出力W、VA、実負荷でのランタイム、必要なシャットダウン統合は独立したチェックです。
- ディスプレイやその他のバンドルされた固定SKUにも同じ原則を適用します。例えば、OS/ネットワーク機能のないディスプレイは、比較される商用範囲にOPSまたは同等の再生デバイスが含まれていない限り、ブラウザ/BI要件を満たしません。
必須の既存予算改定ワークフロー
このワークフローは、ユーザーが既存のBOM、CSV、XLSX、予算ファイル内の価格を更新、リフレッシュ、再価格設定、改定、最適化するように要求するたびに必須です。ユーザーが「更新一下价格」のような短い指示だけを与えた場合でも適用されます。
- まずソースアーティファクトを読み取り、既存の各ラインアイテムの単価を改定ベースラインとして保持します。以前の予算は自動的に現在価格のエビデンスにはなりませんが、より弱いエビデンスによって静かに上書きされてはなりません。
- 広範なWeb調査の前に、アクセス可能なプロジェクトエビデンス（ソースファイル、隣接/以前の予算バージョン、見積もり記録、メモ、スクリーンショット、ユーザー提供の数値、以前のプロジェクト成果物）から現在の見積もりを検査します。公開URLがないという理由だけで人間からの見積もりを破棄しないでください。
- 低価格の候補が必須要件を変更または不確かにするすべてのラインに、価格引き下げ前の必須技術適合ゲートを適用します。
- すべての...
（原文が切れていますが、可能な限り翻訳された部分を適用してください。）
[注: 原文が途中で切れています。残りの内容については、同じルールを適用して翻訳を完了させる必要があります。]