テンプレートを探す
1本ずつ探すより、使う場面や構成の層でまとまったセットから選ぶほうが早いことがあります。
セットから選ぶ
キットをすべて見る →SQL Server パラメータシート（SQL Server 2022）
SQL Server 2022 のパラメータシート。Windows環境にほぼ必ずあります。既定値のまま動いてしまうため、問題が出るのは負荷が上がってからか、障害が起きてからです。★核は2枚です。（1）バックアップ・復旧設計 … 完全復旧モデルなのにトランザクションログのバックアップを取っていないと、ログが増え続けてディスクが枯渇し、データベースが止まります。新規データベースは雛形（model）を引き継いで既定で完全復旧モデルになるため、意識せずにこの状態になります。（2）インスタンス設定 … メモリ・並列度・tempdb・自動拡張の既定値は、そのままだと性能が出ない・OSを圧迫する・拡張のたびに止まる、という形で効いてきます。★照合順序はインストール時に決まり、後から変えるにはシステムデータベースの再構築が必要です。導入前に確定させてください。★記入例は Windows Server パラメータシートの業務アプリサーバーに同居する構成にしてあります。
VDI パラメータシート（仮想デスクトップ基盤）
VDI（仮想デスクトップ基盤）のパラメータシート。製品には依存しません（何を使っても決めることは同じです）。★核は3枚です。（1）同時利用と資源 … VDI の事故は「足りない」ではなく「同時に集まる」で起きます。台数分の資源を用意しても、朝9時に全員が一斉にログオンすると入れません。平均で設計すると必ず失敗します。しかも遅いだけで止まらないので、基盤の問題だと気づかれにくいのが厄介です。（2）利用者データ … 仮想デスクトップは作り直す前提のものが多く、どこに置いたものが残るかを決めていないと、作り直した瞬間に利用者のデータが消えます。「デスクトップに置いてあったのに」は、消えてから分かります。（3）接続と切断 … 画面を閉じただけでは終わりません。切断後の扱いを決めていないとセッションが残り続けて資源を食い、翌朝に入れなくなります。★既定値は製品と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
VLAN管理表
VLAN IDの付番規約から作るVLAN管理表。VLAN IDとセグメントの重複、規格範囲外のID、用途の記入漏れは自動で赤くなります。「どの機器にどのVLANを作るか」の収容マトリクスと、リンクごとの許可VLAN・ネイティブVLANを書くトランク設計を同梱し、「VLANは作ったがトランクに載せていない」「両端のネイティブVLANが違う」という現地で最も多い2つの詰まりを設計側で潰します。IPアドレス管理表と対で使えます。
Webサーバー パラメータシート（IIS / Apache / nginx）
Webサーバーの主要3製品を1枚にまとめています。設定項目の「概念」は共通で名前と書き方だけが違うため、3製品のパラメータ名を並記する対応表の形にしました。使う製品の列だけを埋めてください。★核は3枚です。（1）サイトとTLS設計 … 名前で振り分けたとき、★どの名前にも一致しなかった要求がどこへ行くかが製品ごとに決まっています。Apache は最初に定義した VirtualHost、nginx は default_server（指定が無ければ最初の server ブロック）、IIS はホスト名なしのバインドが受けます。受け皿を明示しないと、IPアドレスで直接叩いただけで内部向けのサイトが見えます。名前で分けているのに証明書が1枚しか無いと、別サイトの証明書が返ります。（2）ログとクライアントIP … ロードバランサの配下では★アクセスログの送信元が全部LBのアドレスになります。元のIPを渡してもらい受け側で記録する設定が要りますが、★無条件に信頼すると利用者が自由に偽装できます。信頼する送信元をLBのアドレスだけに限定してください。（3）公開範囲設計 … 既定のままだと余計なものが見えます。索引ファイルが無いディレクトリの一覧、置き忘れた .bak、詳細なエラーページ、製品名と版数。「置かない」が第一ですが、置かれる前提で塞ぐ設計にします。
Windows Server パラメータシート（Windows Server 2022）
台数で言えば最も多いOS。汎用のパラメータシートでは「ホスト名」「IPアドレス」で終わってしまい、実際に事故になる設定が落ちます。★核は「ファイアウォール設計」シートです。Windowsファイアウォールにはプロファイルが3つあり（ドメイン／プライベート／パブリック）、規則は選んだプロファイルでしか効きません。さらにプロファイルは NLA が自動判定するため、起動時にドメインコントローラーへ到達できないとパブリックに落ち、ドメインの規則が効かなくなります。「ここからは繋がるのに、あそこからは繋がらない」の大半がこれです。★共通設計の「更新と再起動」では、再起動をいつ行うかを設計として決めさせています。無期限に延ばすと更新は当たったことにならず、既定のままだと業務時間中に再起動します。★既定値は版と累積更新で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
YAMAHA RTX パラメータシート（RTX1300/RTX1220）
国内の中小〜中堅で最も普及している拠点ルーター向け。コマンド体系が他社と大きく違うため、汎用のパラメータシートでは書けません。★核は「フィルタ設計」シートです。RTX の secure filter は列挙した順に評価され、フィルタ番号の大小では決まりません。番号を振り直しても評価順は変わらず、逆に列挙の順序を入れ替えると挙動が変わります。★確認コマンド集と、この機種で実際に起きる失敗を集めた「投入時の注意」を同梱しました。記入例は主回線＋IPsec VPN バックアップの拠点ルーター構成です。
vSphere パラメータシート（ESXi 8 / vCenter 8）
VMware vSphere（ESXi 8 / vCenter 8）のパラメータシート。国内の中小〜中堅で最も普及している仮想化基盤です。汎用のパラメータシートではホスト名と管理IP程度しか書けず、実際に事故になる設定が落ちます。★核は「ネットワーク設計」シートです。チーミングとフェイルオーバー順序はポートグループごとにvSwitchの設定を上書きできるため、上書きの有無を表に持たないと、vSwitch側を直したときに一部のポートグループだけ挙動が変わります。VLANの付け方（ポートグループに付ける／物理側をアクセスポートにする／4095でゲストに渡す）と物理側のチャネル方式の組み合わせも、ここで固定します。★もう一つの核は「vCenter・クラスタ」シートです。分離応答・アドミッション制御・再起動の優先度・EVC は、既定のままにすると「障害のときだけ」問題が出ます。★既定値は版とライセンスで変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
サイジング設計書
「メモリ64GB」と書いてあるが、なぜ64GBなのかが誰にも分からない——これが最も多い型です。現行の実測値から必要量を数式で積み上げます（実測 →（1+成長率)^目標年数 → ピーク係数 → 目標使用率で割る）。前提を1つ直せば必要量が右端まで自動で追従します。機器割当シートでは必要量をサイジング計算から自動転記し、余裕率と**片系停止時の使用率**を出します——N+1は1台落ちたら残りが全負荷を受けるので、総搭載量だけを見ていると片系停止時の不足に気づけません。運用開始後に実測と突き合わせる見直し記録つき。
サーバー本体 パラメータシート（BIOS/UEFI・RAID・ファームウェア）
サーバー本体（BIOS/UEFI・RAID・ファームウェア）のパラメータシート。富士通 PRIMERGY（iRMC）／Lenovo ThinkSystem（XCC）／NEC Express5800（EXPRESSSCOPE エンジン）などを想定していますが、★ベンダー非依存で書いています。呼び名が違うだけで、設定する項目と踏む失敗は同じだからです。Dell PowerEdge・HPE ProLiant でも同じ考え方で使えます。★既存の iDRAC シート・iLO シートとの分担 … あちらは管理コントローラ側（アクセス・ライセンス・アラート）、こちらは本体側（起動方式・アレイ・ファームウェア）です。★核は3枚です。（1）ブート設計 … 起動方式（UEFIかどうか）とセキュアブートは、★OSを入れた後で変えると起動しなくなります。最初に決めるしかありません。起動の順序は、保守で挿した媒体から立ち上がる事故につながります。（2）RAID（アレイ）設計 … ★構成は後から変えられません。作り直しはデータ消去なので、運用開始後は実質できません。さらに★書き込みキャッシュを守る部品（電池・コンデンサ）が寿命で切れると、キャッシュが自動で無効になって性能が落ちます。設定を何も変えていないのに急に遅くなるので、原因にたどり着きにくい項目です。（3）ファームウェア設計 … ★最新が正解ではありません。仮想化基盤やストレージ側が「この版」と指定する対応表があり、単体で最新にすると外れます。
スイッチ パラメータシート（Cisco以外 / アライド・HPE・エクストリーム ほか）
アライド・HPE・エクストリームなど Cisco以外 のスイッチのパラメータシートです。★ベンダー非依存で書き、★Catalyst と考え方が違うところに寄せてあります。★核は3枚です。（1）VLANとタグ設計 … ★Cisco は「ポートの型（access / trunk）を選ぶ」ですが、多くの機種は「VLANごとに untagged / tagged でポートを入れる」書き方です。考え方が根本的に違うので、Cisco の感覚で読むと設定の意味を取り違えます。表に「Cisco での言い方」の列を持たせて、頭の中を移せるようにしました。★上位で管理VLANを通し忘れると管理に入れなくなり、復旧は現地作業になります。（2）ループ防止設計 … ★ループを作ると、そのVLANの通信が全部止まります。1本繋いだ瞬間に起きて、抜くまで戻りません。エッジポートの設定を飛ばすと「ケーブルを挿してもすぐ繋がらない」になります。（3）他ベンダーとの相互接続 … ★リンク集約の方式・タグの解釈・ループ防止の方式・MTU が揃っていないと、繋がらないか不安定になります。MTU の食い違いは「小さい通信は通るのに大きいのが落ちる」形で出ます。★Cisco Catalyst シートとの分担は、あちらが Catalyst 固有のコマンドで書いた1機種のシート、こちらがそれ以外の機種です。記入例は同じ案件で、Cisco のコアスイッチに別ベンダーのフロアスイッチを増設する構成にしました（相互接続の核が実例として効くため）。
セキュリティ設計書
セキュリティ設計が効かなくなる最大の原因は、★対策から書き始めることです。「FWを入れる」「多要素認証を入れる」と製品と機能を並べても、何の脅威に対してかが書かれていないと、効いていない対策に金を払い、効くべき脅威が抜けます。本書は 守る対象（情報資産）→ 脅威 → 対策 の順でしか書けない構成にしました。脅威と対策の対応表が中核で、対策を打ってなお残るものは★残存リスクとして「受容した人・理由・見直し時期」つきで残します。対策ごとに「効かなくなる条件」を書かせる対策一覧、信頼境界の定義、インシデント時の判断基準と報告先つき。
ソフトウェアLB パラメータシート（nginx / HAProxy）
nginx / HAProxy でロードバランサを作るときのパラメータシートです。★装置を買わない選択肢なので、装置側の2本（BIG-IP・A10 Thunder）とは核が違います。★核は3枚です。（1）ヘルスチェック設計 … ★nginx の無償版には能動的なヘルスチェックがありません（NGINX Plus の機能）。無償版で使えるのは受動的な確認だけで、max_fails（既定1回）と fail_timeout（既定10秒）により、★実際の利用者のリクエストが失敗しないと「落ちた」と分かりません。つまり最初の何人かは必ずエラーになります。HAProxy は無償版でも能動的に確認できるので、★製品を選ぶ段階で効く違いです。（2）設定の反映と冗長 … 設定はテキストなので★1つの誤字で全サービスが落ちます。必ず検査してから反映してください。再読み込みと再起動を取り違えると既存の接続が切れます。そして★装置と違って筐体のHAが無く、冗長は自分で組むことになります。監視の経路が1本だと両方が現用になり、同じIPが2つ存在します。（3）OSと資源設計 … ★装置ではないのでOS側の上限が効きます。同時接続数はLBの設定だけ上げても増えず、バックエンドへ出る送信元ポートが枯渇すると「途中から繋がらない」形で出ます。★能動的な確認の可否は nginx 公式ドキュメントで裏を取っています。
ゾーニング設計表（SAN）
FC構成では必須の設計表。ゾーニングを間違えると、見えるはずのLUNが見えないか、見えてはいけないサーバから見えます（後者は気づかないまま運用に入ります）。WWPNは桁数（16進16桁）と重複を数式で検査し、外れた行は赤くなります。★ホスト1台あたりのパス本数は「HBAのポート数 × 同じファブリックにいるターゲットのポート数」です（記入例は 2×2＝4本）。ゾーンが1つ欠けると3本になりますが業務は動いてしまうので、適用記録に「パス本数の確認」を独立した行として入れてあります——★「見えている」ではなく本数を数えてください。エイリアスを先に定義してゾーンをエイリアスで組む構成にしてあるので、HBA交換のたびに全ゾーンを書き換える必要がありません。1イニシエータ1ターゲットのゾーニングを標準にし、適用記録で「保存して有効化したか・検証したか」まで残します。
バックアップソフト パラメータシート（Veeam / Arcserve 等）
Veeam・Arcserve などバックアップ製品の設定値を書くパラメータシートです。★核は3枚です。（1）保持・世代設計 … 「14世代」が何日前まで戻れるかは方式で変わります。世代は回数であって日数ではありません。増分は前の復元ポイントに依存するため、連鎖の途中が壊れるとそこから先が戻せません。そして最大の問題は、保持を短くしても・復元ポイントが消えても、「戻したいとき」まで誰も気づかないことです。（2）リポジトリ設計 … 保存先は数ではなく「何に耐えるか」で数えます。同じ拠点・同じ認証で入れる先を2つ用意しても、耐えられる事象は増えません。（3）整合性とリストア … ★ジョブが「成功」でも整合性が取れているとは限りません。整合性の処理に失敗しても、警告のままバックアップが完了することがあります。★製品ごとに画面も用語も違うため、確証のない既定値・挙動は「要確認」と明記しています。★既存の「バックアップ・リストア設計/手順書」が「何を・どこまで戻すか」を決める文書なのに対し、こちらは「それを製品にどう設定するか」を書く側です。RPO/RTOをこのシートで決め直さないでください。
ブロックストレージ パラメータシート（Dell・HPE・富士通 ほか）
Dell PowerStore・Unity、HPE Nimble・Alletra、富士通 ETERNUS などを想定していますが、★ベンダー非依存で書いています。呼び名が違うだけで、設定する項目と踏む失敗は同じだからです。NetApp ONTAP は別シートで、どちらを採用するかの選択になります。★記入例はSANの鎖として繋いであります（サーバー本体 → HBA → FCスイッチのゾーニング → ストレージのホストマッピング → 仮想化基盤のデータストア）。★核は3枚です。（1）ホストマッピング設計 … ★ゾーニングで見えるようにしても、ストレージ側で割り当てなければ見えません。「ゾーンは通っているのに見えない」の正体で、見えるまでに2段階あります。そして★共有前提でないOSに同じボリュームを複数台から見せるとデータが壊れます。動かないのではなく壊れるので取り返しがつきません。（2）マルチパス設計 … ★冗長のはずが片パスで動いている、が構築直後から起きます。マルチパスの仕組みを入れていないと同じボリュームが複数のディスクとして見え、パスの本数は数えないと分かりません。（3）プールと容量設計 … ★プールが満杯になると、そのプール上の全ボリュームが書けなくなります。都度確保では割り当ての合計が物理容量を超えても作れてしまいます。
ポート結線表・配線表
設計書ではなく、現地作業の指示書としてそのまま使える結線表。両端の機器とポートを書けば、ケーブルに貼るラベル表記が数式で出ます。ポート一覧は機器ごとに全ポートを展開する方式で、空きポートが行として見えるため増設のたびに現地で数える必要がありません。規格ごとの最大距離とコネクタをまとめたメディア早見表つき。
メール基盤 パラメータシート（メール・グループウェア）
ドメインとしてのメール基盤（送信ドメイン認証・経路・受信の保護）のパラメータシートです。★サービスに依存しない書き方にしています。クラウドでもオンプレでも踏む失敗は同じだからです。★核は3枚です。（1）送信ドメイン認証設計 … ★SPF は1つのドメインに1レコードしか置けません。複数あると評価が失敗して全部が通らなくなります。サービスの案内どおりに「TXTレコードを追加」してしまい、2つ目ができる事故が多い項目です。★DNSを引く回数にも上限（10）があり、include を重ねると超えて失敗します。空振りする参照にも上限（2）があります。そして★DMARC は「SPFが通っている」だけでは成立しません（ドメインが揃っている必要があります）。（2）経路と送信元設計 … ★抜けるのは人が読むメールではありません。業務システムの通知・監視の通知・複合機からの送信・外部サービスです。★届かないことに、障害のときまで気づけません。（3）受信と保護設計 … ★外から来た自ドメインの差出人を止めます。最も使われる手口です。★SPFの規格値は RFC 7208 で裏を取っています。★Microsoft 365 シートはテナント側（条件付きアクセス・外部共有）で、メールの基礎には触れていません。
ラック搭載図（1U単位）
1U単位のマス目で前面・背面を描くラック搭載図。空きUがマスとして見えるので、増設のたびに現地でUを数える必要がありません。ラックごとに使用U・空きU・重量・消費電力を自動集計し、ラックの上限（U数・耐荷重・電源容量）を超えると赤くなります。PDUのコンセント割当を全展開する電源系統シートつき。搭載してから「入らない・重量が超える・電源が足りない」と分かるのが一番まずく、その場では何もできません。
基本設計書（方式と方針の型）
「基本設計＝方式と方針、詳細設計＝具体的な値」の線引きを章構成で体現。設定値はパラメータシートに書き、本書には書かないことで二重管理を防ぎます。
店舗展開 標準構成書（多店舗）
多店舗（小売・飲食・サービス）の店舗展開で使う標準構成書。★これまでの文書は「1つのシステムを作る」前提でしたが、店舗展開は同じものを何十回も作るのが仕事で、失敗の形もそこから来ます。★核は3枚です。（1）標準構成 … 店舗展開の値打ちは「速く開ける」ことではなく「どの店も同じにする」ことです。1店だけ違う機器・違う設定にすると、その1店のために手順が枝分かれし、以降の全店の作業がその分だけ重くなります。例外を認めるならいつまでの例外かを書いてください。書かない例外は永久に残ります。（2）開店までの逆算 … 開店日は動かせません。回線の手配が最も長いので、そこから逆算します。前から積むと必ず溢れます。（3）現地対応 … 開店後の店舗に技術者は居ません。店員が電話越しにできることしか復旧手段になりません。「見に行けば分かる」は100店舗になると成り立ちません。
構成図テンプレート（作図ルール＋部品集）
雛形・記法ルール・アイコン部品集のセット。新設＝赤枠／撤去＝グレーアウトなど更改案件の描き分けを標準化します。Visio不要、PPT標準図形のみ。
構成管理・自動化 パラメータシート（Ansible / Terraform）
Ansible / Terraform で構築を自動化するときのパラメータシート。オンプレのインフラ屋に向けて、コードで作ること自体ではなく**コードで作った後に何が起きるか**を書いています。★核は3枚です。（1）差異と状態 … 緊急対応では必ず手で直されます。それは止められないので、戻す手順と期限を先に決めておかないと、コードと現物が静かにずれます。ずれていても普段は誰も困らず、困るのは作り直すときで、そのときには手遅れです。Terraform の状態ファイルは「コードと現物の対応表」で事実上の本体です。失うと作った資源を管理できなくなります（変えることも消すこともできません）。（2）適用の作法 … 適用の前に何が変わるかを見て、適用の後にもう一度流します。属性によっては変更できず「消してから作り直し」になるため、見ずに流すと本番が止まります。「1回目は通るが2回目で壊れる」は本番で初めて出るので、構築時に必ず2回流します。（3）設定時の注意 … この分野で実際に起きる24の失敗と、その回避手順。★項目名の（A）は Ansible、（T）は Terraform 固有です。★既定値は製品と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
機器一覧（ハードウェア台帳）
機器IDを全シート共通のキーにしたハードウェア台帳。保守契約とEOS/EOSLの期限が近い行・過ぎた行は自動で色が付き、更改の検討漏れを防ぎます。U数・重量・消費電力はラック単位で自動集計され、ラック搭載図と電源設計の入力になります。光モジュールやディスクなど、保守がモジュール単位で発生する部材の台帳つき。
監視基盤 パラメータシート（製品非依存）
監視基盤（Prometheus / Grafana / Zabbix ほか）のパラメータシート。監視の仕組みそのものをどう組むかを決めます。製品には依存しません（何を使っても決めることは同じです）。ここから先は Prometheus / Grafana / Zabbix などを想定しています）。★「監視項目一覧」が何を監視するかの表なのに対し、本書は仕組みの側です。監視項目一覧に書いた項目を、この基盤で実際に見られるようにします。★核は3枚です。（1）監視の監視 … 最も重い枚です。監視基盤が止まっても、止まったことを知らせる相手が居ません。「アラートが来ない」は「異常が無い」ではなく「監視が死んでいる」かもしれません。静かなほど安心に見えるので、気づくまでに何日もかかります。（2）保存と容量 … 時系列のデータは増え続けます。保存期間を決めていないとディスクが尽き、ある日突然この基盤自体が落ちます。しかも「過去のデータが要る」と気づくのは障害の後です。（3）通知の設計 … 設定しただけで、実際に届くか試していない例が多くあります。抑制（メンテナンス中の停止）を解除し忘れると、以降ずっと黙ります。★既定値は製品と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。