# claude / longctx-01 ## Prompt 添付の『ハルカゼ運用ハンドブック』だけを根拠に、次の3問に答えてください。本文に書かれていないことは推測せず、書かれている場合はその箇所の記述に厳密に従ってください。 【設問】 1. ハルカゼで『データの値が食い違ったとき、最終的に正とすべきデータストア』は何か。ハンドブックで定義されている正式な名称を、そのまま1つ答えてください。 2. ハルカゼの復旧目標時間（RTO）は何時間か。数値（時間）で答えてください。本文には世代数・割合・応答時間など似た数値が多数登場しますが、RTOとして明記された値はただ1つです。 3. オペレーターに割り当てられる『影番』の表記形式を、本文の定義どおりに説明してください（どんな文字種をどう組み合わせるか）。 【出力】必ず次のJSON形式のみ出力してください（前後に説明文を付けない）。 { "pointOfTruth": "<データストア名>", "rtoHours": <整数>, "kageban": { "format": "<表記形式の説明>", "example": "<本文に出た例>" } } ## 添付ファイル: fixtures/handbook.md # 架空システム「ハルカゼ」運用ハンドブック（社内限・第7版） 本書は架空の社内基幹システム「ハルカゼ」の運用手順をまとめたものである。実在の製品・企業とは関係しない。 ## 0. 用語と略語の定義（最初に必ず読むこと） 本書では以下の略語を用いる。後続の章ではこの定義を前提に記述するため、定義は本章にのみ記載する。 - **RTO**: 本書における「復旧目標時間」。障害発生から主要機能が再開するまでに許容する最大時間。 - **PoT**（Point of Truth）: 本書における「正本の所在」。データの正しい値を最終的に確定させる単一のデータストアを指す。ハルカゼでは PoT は常に「中央台帳DB」である。 - **影番**: 本書独自の用語。各オペレーターに割り当てられる影武者番号で、当番表では本名の代わりに影番で記載される。影番は必ず英字1文字＋数字2桁（例: K07）で表す。 - **凍結窓**: メンテナンスのため書き込みを停止する時間帯のこと。凍結窓中は PoT への直接書き込みを禁止する。 重要な原則: ハルカゼでは「PoT 以外のデータストアの値が PoT と矛盾した場合、常に PoT を正とする」。この原則は本書全体を通じて適用される。 ## 1. 日次運用の流れ 毎営業日、当番オペレーターは始業時に死活監視ダッシュボードを確認する。異常がなければ通常運用に入る。バッチ処理は深夜帯に自動実行され、完了通知が翌朝のレポートに反映される。当番は前日のバッチが全件成功しているかを確認し、失敗があれば再実行をかける。 日次の主要タスクは、(1)監視確認、(2)バックアップ成否確認、(3)問い合わせ一次対応、の3つである。これらは当番の責任範囲であり、二次対応以降は専門チームに引き継ぐ。 ## 2. バックアップとリストア バックアップは1日3回（朝・昼・晩）取得する。世代は14世代を保持し、15世代目以降は自動削除される。リストアの判断は当番単独では行わず、必ず運用責任者の承認を得る。 リストア訓練は四半期に1度実施する。訓練では本番とは別の検証環境を用い、本番データには一切触れない。なお、検証環境のデータは PoT ではないため、検証環境との差異をもって本番データを修正してはならない。 ## 3. 監視としきい値 CPU使用率が80%を10分間継続した場合、警戒アラートが発報する。90%を5分間継続した場合は重大アラートとなり、当番は即座に運用責任者へ電話連絡する。ディスク使用率は85%で警戒、95%で重大とする。 ネットワーク遅延は平常時で20ミリ秒以内を基準とする。50ミリ秒を超える状態が継続する場合は、回線業者への問い合わせ手順（付録B）に従う。 ## 4. 障害対応の基本動作 障害を検知したら、まず影響範囲を切り分ける。次に一次切り分け結果を当番ログに記録し、必要に応じてエスカレーションする。エスカレーション先は障害の重大度によって異なる。 ここで運用上きわめて重要な数値を述べる。ハルカゼの RTO は4時間である。すなわち、障害発生から4時間以内に主要機能を再開できる見込みがない場合、当番は直ちに「緊急体制」を宣言し、全関係者を招集しなければならない。この4時間という値は契約上のSLAに基づくものであり、運用判断の基準として最優先される。 緊急体制の宣言後は、復旧作業と並行して、顧客向けの状況連絡を30分ごとに更新する。連絡文面のテンプレートは付録Cにある。 ## 5. 変更管理 本番への変更はすべて変更管理票を起票し、レビューを経て承認されること。緊急変更の場合のみ事後承認を認めるが、その場合も24時間以内に正式な変更管理票を補完する。 変更作業は原則として凍結窓の外で行う。凍結窓中にどうしても作業が必要な場合は、運用責任者と PoT 管理者の双方の承認が必要である。 ## 6. 当番表と引き継ぎ 当番は週替わりで、当番表には影番で記載される。引き継ぎ時には、未解決の事象・進行中の変更・監視の特記事項を口頭とログの両方で伝える。引き継ぎ漏れは重大インシデントの温床であるため、チェックリスト（付録A）の全項目を埋めること。 ## 7. 大量に登場する似た数値についての注意 本書には時間・割合・世代数など多くの数値が登場する。読者が混同しやすいため改めて整理すると、バックアップ世代は14世代、CPU重大アラートは90%を5分、ディスク重大は95%、状況連絡は30分ごと、緊急変更の事後補完は24時間以内である。これらはいずれも運用パラメータであって、障害時の復旧目標そのものではない。復旧目標（RTO）の値は第4章に一度だけ明記されている。 ## 7.5. 容量計画と保守契約（参考値が多い章） ハルカゼの本番サーバーは合計8ノードで構成され、うち2ノードは待機系である。月間の想定トランザクションは約1,200万件、ピーク時の同時接続は最大3,000セッションを見込む。ストレージは年率18%の増加を前提に容量計画を立てており、現在の使用率は62%である。 保守契約では、平日のサポート応答が1時間以内、休日は2時間以内と定められている。ただしこの「応答時間」は問い合わせへの一次返答までの時間であって、第4章の復旧目標とは別物である。両者を混同してはならない。応答時間（1時間／2時間）はベンダーとのサポート契約、復旧目標は顧客とのSLA契約に基づく、別系統の数値である。 ライセンスは年単位の更新で、更新の90日前に通知が来る。検証環境のノードは2ノードで、本番の縮小版である。これらの数値はいずれも容量・契約に関するものであり、緊急体制の発動基準となる時間ではない。 ## 8. 付録の構成 付録Aは引き継ぎチェックリスト、付録Bは回線業者への問い合わせ手順、付録Cは顧客連絡テンプレートである。付録はいずれも別ファイルで管理され、本書からは参照のみを行う。 ## 8.5. 権限と承認フロー（登場人物が多い章） ハルカゼの権限は4階層に分かれる。閲覧権限・操作権限・変更承認権限・PoT管理権限である。当番オペレーターは通常、操作権限までを持つ。変更承認権限は運用責任者およびその代理者に与えられ、PoT管理権限は PoT 管理者2名に限定される。 承認フローは申請から最短で1営業日、込み合う時期は最長5営業日を要する。緊急変更は例外で、口頭承認を得たうえで作業し、後追いで書面化する。なお、いかなる権限保持者であっても、第0章で定めたとおり PoT 以外の値を根拠に PoT の値を上書きすることはできない。値の食い違いは常に PoT を正として解消する。 代理承認の有効期限は、設定から最大7日間である。これを過ぎた代理権限は自動失効する。失効後に承認が必要になった場合は、正規の権限保持者へ改めて申請する。これらの日数（1営業日・5営業日・7日）はいずれも承認フローに関する値であり、障害復旧の目標時間とは無関係である。 ## 9. 改訂履歴と結び 本ハンドブックは運用の実態に合わせて随時改訂する。第7版では監視しきい値の記述を見直したが、RTO・PoT・影番・凍結窓の定義（第0章）は初版から変更していない。 最後に運用者へ。判断に迷ったときは、第0章の定義に立ち返ること。とりわけ、データの値が食い違ったときの拠り所が何であるか、そして緊急体制を宣言すべき時間的な閾値が何時間であるかは、ハルカゼ運用のすべての場面で問われる。これらは本書のどこか一箇所にしか定義されていないが、運用のすべてを貫く。 ## Answer { "pointOfTruth": "中央台帳DB", "rtoHours": 4, "kageban": { "format": "英字1文字＋数字2桁の組み合わせ", "example": "K07" } } ## Metrics ```json { "ttftMs": null, "tokens": 0, "tokPerSec": null, "wallMs": 6777, "toolCalls": 0, "toolCallInvalid": 0, "capHit": false, "errored": false, "crashed": false } ```