お使いのAIから、インフラ設計を呼び出す

対応しているクラウド/オンプレミスのプロバイダと、それぞれのカテゴリ・サービス数を返す。最初の方向づけに使う。

サービスカタログを検索し、構成モデルで使える型ID(例: aws.network.vpc)を調べる。型IDは推測せず必ずここで確認する。

サービス型IDの詳細(既定プロパティ・設定できる項目と選択肢・配置制約・接続制約)を返す。リソースを追加する前にこれで設定項目を確認する。

定番構成のテンプレート一覧を返す。create_design の template に渡すIDを調べる。

構成モデルを新規作成する。template を指定するとその定番構成から、省略すると空の構成から始まる。

リソースの追加・接続・設定変更などをまとめて適用し、更新後のモデルと各操作の結果・検証結果を返す。同じ呼び出しの中で作ったリソースを参照するには、add に ref を付けて後続の操作で "$ref名" と書く。

構成モデルを検証し、配置制約違反・接続制約違反・設定漏れなどをエラー/警告として返す。

セキュリティ/信頼性/運用/コストの観点で構成を診断し、0〜100のスコアと改善提案を返す。検証(validate_design)が「不正」を見るのに対し、こちらは「改善余地」を指摘する。

各クラウドが公表している公称SLAを接続グラフに沿って直列合成し、システム全体の理論可用性・年間想定停止時間・単一障害点を算出する。目標可用性(99.9%〜99.99%)に届かせるための変更点、届かない場合は上限を決めている層も返す。SLAが公表されていない/カタログ未登録のサービスは計算に含めず列挙する。数値は推測せず公表値のみを使う。

想定トラフィック(同時ユーザー数・操作頻度・ピーク倍率)を接続グラフに沿って伝搬させ、各層に到達するリクエスト数・帯域・使用率・必要台数を算出する。「同時1万人だとどこが最初に詰まるか」に答える。処理能力は各リソースの capacityRps プロパティ(利用者が設定した値)のみを使い、未設定なら使用率は出さない(機種ごとの性能値には公表値が無く、推測すると根拠にならないため)。1リクエストあたりの呼び出し回数やキャッシュヒット率は接続の rpsMultiplier で表す。

構成モデルから月額の概算費用(USD/JPY)を算出する。単価が確定できないリソースは金額に含めず、理由つきで excluded に列挙する。静的な単価テーブルによる概算であり契約単価は反映しない。

「どこを直せばいくら変わるか」を差額つきで提案する。過剰なサイジングの是正(削減)と、可用性の改善(投資)の両方を返す。差額は提案どおりにモデルを直して見積もり直した実際の差であり、別計算ではない。一般論(「RIで最大◯%削減」等)は出さず、この構成で金額を算出できるものだけを提案する。

構成モデルから構築工数(人日)と費用(円)を、設計/構築/試験の工程別に概算する。

複数の構成案を横並びで比較する。月額・構築工数・理論可用性・単一障害点・診断スコア・構成の違い(サービス種別ごとの台数)を返す。「松竹梅の3案を比べて選定理由を書く」ような用途向け。各指標は個別の分析結果をそのまま並べたもので、比較のための別計算はしない。

構成モデルからTerraform(HCL)を生成する。プロバイダはモデルの内容から自動判別する(AWS/Azure/GCP)。AMI・認証情報など環境依存の箇所は TODO コメントで示される。

構成モデルを別のクラウド(AWS / Azure / GCP)へ変換した新しい model を返す。種別が対応するサービスへ型を置換し、主要なコストドライバ(VMサイズ・台数・ストレージ量)を引き継ぐ。変換先に同種サービスが無いものは dropped に理由つきで報告する。返した model はそのまま estimate_cost / diagnose_design / generate_terraform に渡せる(「このAWS構成をAzureにしたら?」が1往復で分かる)。オンプレ/ハイブリッド構成は変換対象外。概算比較の用途で、厳密なパラメータ移行ではない。

接続と宛先の種別から、送信元×宛先×ポート×プロトコル×用途の通信要件マトリクスを導出する。SG/NSG/ファイアウォール設計やファイアウォール申請の前段になるSI帳票。ポート等はサービス種別からの推定を含むため、確定値ではなくドラフトとして提示する。

この構成で実現できる非機能水準(IPA非機能要求グレードの大項目=可用性/性能・拡張性/運用・保守性/移行性/セキュリティ/システム環境)を逆生成する。検証・診断が「問題」を出すのと対に、達成済みの水準を「非機能要件確認表」として整理する。構成から導出できない項目(運用時間・移行方式等)は記入欄(input=true)として残す — 推測で断定しない。

要求(ヒアリング項目)→ 設計での実現(構成から導出した非機能水準)→ 確認する試験(試験ID)の対応表を組み立てる。ISO/品質監査で要求される定番帳票。**対応が見つからない欄は埋めずに状態で示す** — 「試験なし」(設計はあるが試験項目が無い)、「要記入」(構成からは追跡できずヒアリング回答が要る)。追跡できない箇所を炙り出すのが目的なので、欠落を埋めて良く見せないこと。試験IDは試験仕様書(UT/IT)と一致する。

構成モデルと構築工数から、工程別・依存順の構築タスク一覧(WBS)を生成する。人日は estimate_effort と同じ前提から積み上げる(工数見積とセットで提案の計画パートになる)。

構築WBSを暦へ落とし、着手日・完了予定日・マイルストーン・クリティカルチェーンを含む概算スケジュールを生成する。「いくら(見積)」「何人日(工数)」に対する「いつできる?」の答えで、提案一式の計画パートになる。所要期間 = ⌈工数 ÷ 稼働率⌉(稼働日)で、先行作業を満たしたタスクから空いた要員へ順に割り付ける(同時並行は要員数が上限。プロジェクト管理は全期間並行で枠外)。土日と指定した非稼働日は数えない。**要員のスキル差・休暇・並行案件・顧客レビュー待ちは織り込まない概算**なので、確定した計画として提示しないこと。

構成モデルから工程別明細+税込合計の御見積書データを生成する。小計は構築工数(estimate_effort)の合計に一致する。金額はドラフトの概算で、実際の見積は自社の単価・条件で確定すること。

見積・可用性の根拠になっている参照データ(クラウド単価・公称SLA・データ転送単価)の取得時点と、そこからの経過月数・鮮度(fresh/aging/stale)を返す。構成モデルは不要。古い単価で作った見積を顧客に出すのを防ぐための確認用。stale のものは最新の公表値を確認してから提出すること。

Azureの公式価格API(Retail Prices)に接続し、見積に使っている静的単価テーブルと突き合わせて差分を返す。対象は仮想マシン・PostgreSQL Flexible Server・Cache for Redis・App Service・VPN Gateway・Azure Firewall・Bastion・Application Gateway。構成モデルは不要で、ネットワークに接続する。**この呼び出しで見積の金額は変わらない** — 返るのは「どの単価行を直すべきか」の一覧で、実際の更新は人が確認して行う。AWS/Google Cloudおよび一部のAzureサービスは自動照合できず、その理由も併せて返す。

構成モデルを既知のアンチパターン(暗号化無効・パブリックアクセス・公開サブネットのDB・データストアの公開入口からの直結・IMDSv1・WAF不在・監査ログ無効 等)で決定的に検査する(AI不要)。import_terraform で取り込んだ実機モデルにもそのままかけられる(現行環境の点検)。各点検項目を pass/fail/na で返し、観点別集計と姿勢グレード(A〜E)を出す。構成モデルから判定できる範囲に限られ、実行環境のIAMポリシー・OS設定・アプリの脆弱性は対象外。

セキュリティ点検(scan_security と同じ決定的検査)の結果を、CIS Benchmarks / PCI DSS v4.0 / ISMS(ISO 27001) / NIST CSF 2.0 の管制項目へ写像し、○(満たす)/ ×(満たさない)/ △(要確認)で返す。「この構成でPCI DSSは通るか?」に設計段階で答えるためのもの。**構成モデルから判定できる技術的統制のみが対象**で、運用・組織・物理統制や実行環境の設定は「要確認」になる。**正式な準拠性の判定ではなく、設計段階のセルフチェック(参考)**である旨を必ず添えて提示すること。

設計(あるべき姿)と実機の構成モデルを突き合わせ、ずれ(ドリフト)を検出する。典型的な使い方は、import_terraform で実機のTerraformを取り込み、その model を actual に、設計の model を desired に渡すこと。リソースはID(一致しない)ではなく種別×名前で対応づけ、「設計にあるが実機に無い(未実装)」「実機にあるが設計に無い(野良リソース)」「両方にあるがプロパティが違う(設定差)」を返す。推測でドリフトを作らない — 片方にしか値が無いプロパティは照合対象外にする。

現行構成と変更後の設計を突き合わせ、ITILの変更管理で求められる4点 — 変更内容・影響範囲・作業手順・切り戻し手順 — を組み立てる。典型的な使い方は、import_iac で現行環境を取り込みその model を current に、変更後の設計を planned に渡すこと。リソースはID(一致しない)ではなく種別×名前で対応づける。作業手順は「追加 → 経路を開放 → 設定変更 → 旧経路を閉塞 → 削除」の順(先に削除すると戻せないため)、切り戻し手順はその逆順。**影響範囲は変更対象そのものと接続グラフで直接つながる相手(1ホップ)まで**で、2ホップ以上の波及やアプリ内部の依存は含まない。**変更理由・実施日時・変更区分・承認者・切り戻し判断基準は構成から導けないので空欄(manualFields)で返す** — 推測で埋めないこと。

保護対象のデータ量(構成モデルの storageGb / sizeGb / diskGb × 台数)を積み上げ、必要バックアップストレージ容量と、バックアップがウィンドウ(例: 夜間8時間)に収まるかを判定する。**「夜間に終わらない」は稼働後に発覚する定番事故**で、データ量÷帯域の掛け算1つで設計段階に潰せる。容量は 方式(毎回フル / フル+増分 / フル+差分)× 世代数 × 日次変化率 から算出し、計算式を返すので検算できる。**帯域(bandwidth_mbps)が未設定ならウィンドウ判定を返さない** — 回線速度に公表値は無く、推測して「収まる」と言えば根拠のない保証になるため(サイジングで capacityRps 未設定なら使用率を出さないのと同じ)。**圧縮・重複排除は既定で見込まない**(残存率1・安全側)。データ量が読めないリソースは excluded に理由つきで返す。

アラームごとに「発報 → 確認手順 → 一次対応 → エスカレーション」を並べた障害対応ランブックを生成する。**重大度と影響範囲は接続グラフから機械的に算出**する(停止時に到達不能になるリソース数)ので、「このDBが落ちると全断」を人が判断しなくて済む。**ただしデータを保持する層(データベース・ストレージ・仮想化基盤)は到達不能数によらず重大度の下限を「高」にする** — 末端のDBは下流を止めないので到達不能数は1件だが、停止すればデータが使えず業務は止まるため。確認手順・一次対応はサービス種別ごとの標準手順に、構成から分かる復旧方式(単一障害点か / 複数台構成か / マネージドサービスか、バックアップの有無)を組み合わせたドラフト。**連絡先・エスカレーション先は構成モデルに無い情報なので空欄(manualFields)で返す** — 推測で埋めないこと。**監視サービスが構成に無ければ excluded で指摘する**(ランブックがあってもアラームが上がらなければ発動しない)。

構成モデルから構築手順書を生成する。設計書 → 構築手順書の転記は日本のSIの定番の二度手間で、**設定値の転記と順序の整理**は構成から機械的に出せる。**順序は親子関係だけから決めている**(入れ物→中身、接続は両端の作成後)ので、新しい依存関係を発明していない。**設定値は図面にある値だけを転記する** — 既定値では埋めないので、空欄は設計で未確定という意味。**コンソールの画面手順とCLIコマンドは生成しない。** 画面名もCLIオプションも提供側の変更で変わり検証手段が無いため、「この順にコマンドを叩け」の形で出すと実行時に失敗する。**IaCで構築するなら generate_terraform を使うよう案内すること。****手順の件数は工数ではない**(工数は estimate_effort、日程は generate_schedule)。実施者・実施日時・アカウント・命名規則・切り戻し判断基準は構成から導けないため manualFields に空欄で返す。

構成のOS・DBエンジンバージョン・ランタイム・Kubernetesバージョン・インスタンス世代を、**ベンダー/コミュニティが公表しているサポート終了日**と突き合わせて、サポート終了 / EOL間近(残り1年以内) / 期限内 / 前世代 / データ未収録 に分類する。**「データ未収録」は問題が無いという意味ではなく判定していないという意味**なので、未収録を「問題なし」として要約しないこと(RHEL・Debian・AKS・GKE・Azure/GCPのインスタンス世代は未収録)。**前世代インスタンスはEOLではない** — AWSは「前世代も引き続き完全にサポートされる」と明記しているため、サポート終了と同列に扱わないこと。**マネージドサービスの終了日は上流(PostgreSQL/Oracle等)の公表値で判定している** — RDS/Cloud SQL/Azure Database は上流EOL後も**有償の延長サポート**で稼働できる場合があり日付が一致しない。一次スクリーニングとして扱い、正式な期限は各クラウドの発表を確認するよう伝えること。評価時点(as_of)を省略すると実行時の日付を使う。出典は docs/09_lifecycle.md。

指定したリソースを停止させたとき、接続グラフ上で到達不能になる範囲を算出する。「このリソースが落ちたらどこまで止まるか」に構成から答える。resource_names を省略すると、**経路上の各リソースを1つずつ停止させた影響ランキング**(どこが一番危ないか)だけを返す。**複数台のリソースは層ごと停止として扱う** — モデルは複数台を1リソース+台数で持つため、「2台のうち1台だけ停止」という縮退状態は表現できない(その旨が notes に入る)。**通信経路を持たないリソース(監視・認証・バックアップ等)は評価対象外**として out_of_scope に理由つきで返す — 影響ゼロと数えてはいけない。アプリ内部の依存や縮退運転での性能低下は含まない。

障害シナリオ別(インスタンス障害 / AZ障害 / データ破損・誤削除 / リージョン障害)に、この構成で達成できるRTO(復旧時間)とRPO(データ損失)を導出する。**冗長化(可用性)と復旧(バックアップ)は別物**で、マルチAZ構成でもデータ破損・誤削除は防げない(壊れたデータが正常系にも複製される)。シナリオを分けて示すこと自体がこの表の目的なので、「マルチAZだから大丈夫」と要約しないこと。リストア時間は データ量 ÷ 帯域 で算出する(size_backup と同じ入力)。**フェイルオーバー・手動再作成・DR切替の所要時間は数値化しない** — サービスごとの公表値はカタログ未収録、手順の所要は運用体制次第で、数字を入れると「30分で復旧します」という架空の約束になる。**達成可否は目標(target_rto_hours / target_rpo_hours)が指定されたときだけ判定する**。

設計書に散らばる時刻情報 — 構築のマイルストーン・工程・計画メンテナンスの窓・バックアップ実行・証明書やライセンスの期限 — を1つの運用カレンダーにまとめ、iCal(.ics)としても返す。**架空の運用を作らないこと**が前提: メンテナンスウィンドウ・バックアップ時刻・各種期限は構成モデルにもIaCにも存在しない情報なので、`model.operations` に登録された値だけを出す。未登録のものは `excluded` に**理由つきで**返すので、そこを埋めるようユーザーに促すこと(勝手に「毎週日曜2時」などと決めない — それは納品物に載る架空の運用約束になる)。日付はJST。繰り返し予定の起点は構築スケジュールの完了日(運用開始日)。

既存のIaCまたはAzure実環境のインベントリから構成モデルを作る。Terraform(.tf / terraform.tfstate / `terraform show -json` / .tf.json)とCloudFormation(YAML / JSON、SAMを含む)、ARMテンプレート(Azure)、Pulumi(`pulumi stack export` の状態JSON。AWS/GCP)、Azure実環境インベントリ(`az resource list` / `az graph query`)・AWS実環境インベントリ(`aws resourcegroupstaggingapi get-resources`。describe-instances / describe-vpcs / describe-subnets / describe-volumes / describe-db-instances / describe-cache-clusters / describe-load-balancers / list-functions の出力や、それらを束ねたJSON配列も可 — プロパティとVPC/サブネット配置まで復元)・GCP実環境インベントリ(`gcloud asset search-all-resources` / `gcloud asset list --content-type=resource`。後者はプロパティ・ネットワーク配置まで復元)を受け付け、形式は内容から自動判別する。BicepはARMへビルド(bicep build)してから渡すこと。稼働中の環境を図面化して、そのまま見積・可用性・サイジング・設計書・ドリフト検知・セキュリティ点検へ流すための入口。変数(var.*)で書かれた値は確定できないため取り込まず、対応するサービスが無い型は skipped に理由つきで返す(推測で補完しない)。接続はセキュリティグループの受信ルールから復元する(インベントリからは接続を復元しない)。

Architectlyに保存されている自分の図面の一覧(ID・名前・更新日時)を返す。get_design に渡すIDを調べる。

保存済み図面の構成モデルを読み込む。返ってきた model は他のツール(見積・診断・Terraform生成など)にそのまま渡せる。

構成モデルをArchitectlyに保存する。design_id を指定すると**その図面を上書き**し、省略すると新規作成する。上書きは利用者の設計を壊しうるため、実行前に何をどう変えるか利用者に伝えること。書き込みスコープのトークンが必要。