運用・障害対応学習記事全11節Operate
稼働・業務結果・費用の3分類で、運用項目と確認頻度を一覧にする
この記事で身につくこと技術的な稼働だけでなく、処理結果や利用状況、費用を確認する理由を説明でき、運用項目ごとに「何を見る・なぜ見る・正常／異常の区別・誰が・異常ならどこへ」を言える。
記事内目次（19項目）
この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。異常の目安・費用の数値は、すべて教材上の仮定です。この記事は運用項目の一覧を作るもので、実際に定期確認（監視）を行った実績はありません。
この記事は何の話か。11-04で運用担当へ引き渡した後、「サーバーが動いているか」だけでなく、業務の結果（提出・承認件数など）や費用も含めて、稼働・業務結果・費用の3分類で運用項目と確認頻度を一覧にする話です。
なぜ必要か。サーバーが動いていても、承認が滞っていたり、想定外の費用が発生していたりすれば、業務としては問題です。技術的な稼働だけでなく、業務結果・費用も確認する必要があります。
この記事を読むとできるようになること。
- 技術的な稼働だけでなく、処理結果や利用状況、費用を確認する理由を説明できる
- 題材アプリの運用項目と確認頻度、確認者を一覧に書ける
- 人が定期確認する項目と、通知に任せる項目を、運用担当の負担から判断できる
- 運用項目ごとに「何を見るか・なぜ見るか・正常と異常をどう区別するか・誰が見るか・異常ならどの記事の手順へ進むか」を言える
- AIに確認結果の整理を任せるとき、何を渡し、何を人が判断するかを言える
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（3分類と、稼働だけでは足りない理由）→第4節（判断すること）→第6節の運用項目・確認頻度一覧→第9節。ここまでで、何を、どの頻度で、誰が見るかが分かります。
- 作って確かめる：上に加えて第5.1〜5.3節（項目ごとに、何を見る・なぜ見る・正常／異常の区別・異常時の導線）→第5.4節（AIに整理を任せる場合の注意）→第7節（確かめたこと・確かめていないこと）。
- 設計判断を深める：上に加えて第8節（人が定期確認する項目と通知に任せる項目、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、11-04で引き渡した題材アプリについて、稼働・業務結果・費用の3分類で運用項目を洗い出し、確認方法・頻度・担当・異常の目安を一覧にすることです。
11-04では引渡しまでを扱いましたが、引渡し後に何を、どのくらいの頻度で確認するかはまだ決めていませんでした。この記事では、それを決めます。
この記事を読み終えると、次のものが手元にできます。
- 運用項目・確認頻度一覧（項目、分類、確認方法、頻度、担当、異常の目安）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
稼働
一言でいうと、アプリが技術的に動いているかどうかです（サーバーが応答するか、エラーが出ていないかなど）。
業務結果
一言でいうと、アプリを使った結果、業務がどう進んでいるかです（提出・承認の件数、滞留している依頼の件数など）。
これがないと、「サーバーは動いている」ことだけを確認して満足してしまい、業務が実際にうまく回っているかどうかを見落とす可能性があります。
読む順路：引渡し記録は11-04、評価指標は01-03、健全性確認は11-02、失敗ログは08-04が該当します。この記事の運用項目一覧は、12-02（異常を検知し影響を判断する）の検知の元、13-01（改善要望と優先順位を整理する）の判断材料になります。
3. 理解する：技術的な稼働だけでは足りない理由
3.1 稼働・業務結果・費用の3分類
| 分類 | 内容 |
|---|---|
| 稼働 | アプリが技術的に動いているか（サーバーの応答、エラーの有無） |
| 業務結果 | 業務がどう進んでいるか（提出・承認件数、滞留している依頼の件数） |
| 費用 | アプリの利用にかかる費用 |
3.2 よくある誤解
「サーバーが動いていれば運用は順調」。01-03で決めた指標（「承認したはずが記録がない」という申告の件数など）が示すとおり、技術的な稼働と業務結果は別のことです。サーバーが動いていても、承認が滞っていれば業務上は問題です。
「費用は契約時に決まるので、運用中は確認しなくてよい」。従量課金など、利用状況によって費用が変わる契約の場合、運用中の確認が必要です（この記事では技術選定が未確定のため、架空の仮定として扱います）。
「一覧を作れば監視していることになる」。一覧は「何を見るか」を決めるものです。実際に見て、正常か異常かを判断し、異常なら次の手順へ進んで、はじめて監視です。この記事では一覧を作るところまでで、実際の定期確認は行っていません（第7節）。
「AIに記録を渡して要約させれば、確認は済む」。AIの要約は「何が起きたか」の整理には使えますが、「異常か」「止めるか」の判断は人が行います。渡す記録に秘密情報・個人情報が混ざっていないことも人が確かめます（第5.4節）。
4. 判断すること
運用項目を決めるときに人が判断することは、次の5つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| 何を見るか（項目） | 稼働・業務結果・費用の3分類から、この題材アプリで実際に取れる記録（健全性確認、失敗ログ、履歴データ、申告、費用明細）に対応づける。取れない記録を項目にしても見られない | 可（運用で見落としが分かれば足す。13-01） | 「サーバーが動いている」だけを見て、承認の滞留や記録漏れを見落とす |
| 正常と異常をどう区別するか（目安） | 目安が無いと、見た人ごとに判断が変わる。目安は仮定でよいが、仮定と明記する | 可（この記事の数値はすべて架空の仮定。運用の実績で見直す） | 異常を「様子見」で流す、または正常を異常として騒ぐ |
| 誰が、どの頻度で見るか | 運用担当（総務の担当者1名、架空）の負担に収まる頻度にする。頻度が高すぎると続かず、低すぎると気づくのが遅れる | 可（架空の体制で仮置き） | 誰も見ていない項目が生まれる |
| 異常ならどこへ進むか（導線） | 見つけた人が次に何をするかが決まっていないと、確認が記録で終わる。申告・失敗ログは12-02、配置起因は11-04、改善は13-01 | 不可。導線の無い項目は「監視しているつもり」になる | 異常を見つけても放置される |
| 人が見るか、通知に任せるか、AIに整理を任せるか | 明確な基準で判定できる項目は通知に任せられる（第8.1節）。AIには記録の整理を任せられるが判断は任せない（第5.4節） | 可（この記事では通知もAIも実装せず、方針だけ決める） | 通知が無いのに「通知に任せた」つもりで誰も見ない。AIの要約を判断の代わりにする |
勝手に決めてはいけないこと：異常の目安の数値（件数など）を、確認済みの事実として書きません。教材上の仮定です。01-03で「初版で扱わない」とした指標（利用者の満足度アンケートなど）を、この記事で運用項目に含めません。この記事で実際に定期確認を行ったかのように書きません。
AIに任せる範囲：記録（失敗ログ、履歴データ、健全性確認の出力）の集計と要約、前回との差分の整理、一覧の下書きはAIに任せられます。任せてはいけないのは、正常／異常の判断、止める・戻す・報告するの判断、異常の目安の決定、そしてAIに渡す記録に秘密情報・個人情報が無いことの確認です。
5. 作って確かめる：運用項目一覧を作る
項目ごとに「何を見るか・なぜ見るか・正常／異常の区別・誰が・異常ならどこへ」を決めます。確認方法の欄にある健全性確認・失敗ログ・履歴データは、それぞれ11-02・08-04・08-02の演習で実際に動いたものですが、この記事でそれらを定期的に実行した実績はありません（第7節）。異常の目安はすべて架空の仮定です。
5.1 稼働の項目
| 項目 | 何を見るか | なぜ見るか | 正常 | 異常（架空の目安） | 誰が | 異常ならどこへ |
|---|---|---|---|---|---|---|
| サーバーの応答 | 11-02の健全性確認と同様の確認コマンドを実行し、5項目の判定 | 動いていなければ他の項目を見る意味がない | 5項目すべて「一致」 | 「不一致」がある、または応答しない状態が続く | 運用担当（架空） | コードの項目の不一致→11-04の切戻し判断。データの項目の不一致→12-02の初動 |
| エラーの発生 | 08-04の失敗ログ（practice-fail-log.json に相当）の件数と、前回からの増分 | 部分失敗は利用者に「成功」に見えることがあり、ログでしか気づけない | 増分0件 | 1日に3件以上（架空の仮定）、または同じ依頼で繰り返す | 運用担当（架空） | 12-02の初動（事実確認→切り分け） |
5.2 業務結果の項目
| 項目 | 何を見るか | なぜ見るか | 正常 | 異常（架空の目安） | 誰が | 異常ならどこへ |
|---|---|---|---|---|---|---|
| 日ごとの提出・承認件数 | 履歴データから、日付ごとに操作の種類（提出・承認・差戻し）を集計 | 業務が回っているかは件数の傾向でしか分からない | 前週と同じ程度の増減 | 極端な増減（架空の仮定。例：提出が続くのに承認が0件） | 運用担当（架空） | 承認が止まっている→承認者・割当の確認（10-03の割当変更）。件数が0→稼働の項目を確認 |
| 提出済みのまま一定期間承認されない依頼の件数 | 状態が「提出済み」で、提出日から一定期間（架空の仮定：3営業日）を超えた依頼を数える | 滞留は利用者からは見えにくく、業務の遅れになる | 0件 | 1件以上（架空の仮定） | 運用担当（架空） | 承認者本人へ連絡、不在なら割当変更（10-03）。繰り返すなら13-01の改善要望へ |
| 「承認したはずが記録がない」という申告の件数 | 01-03の指標と同じ。総務課長（架空）への申告を記録する | 記録漏れは業務の信頼に直接関わり、失敗ログに出ないこともある | 0件 | 申告が1件でもあれば異常として扱う | 総務課長（架空） | 12-02の初動手順（申告の入口） |
5.3 費用の項目
| 項目 | 何を見るか | なぜ見るか | 正常 | 異常（架空の目安） | 誰が | 異常ならどこへ |
|---|---|---|---|---|---|---|
| 利用費用 | 契約している接続先の費用明細（架空の仮定。03-03の技術選定が未確定のため具体的な金額は未定） | 従量課金なら利用状況で変わり、想定外の費用が業務上の問題になる | 想定の範囲内 | 想定を超える（金額は未確定） | 運用担当（架空） | 総務課長（架空）へ報告。原因が利用量なら13-01、契約なら03-03の見直し |
5.4 AIに確認結果の整理を任せる場合の注意
定期確認で集まる記録（失敗ログ、履歴データの集計、健全性確認の出力）の整理はAIに任せられます。この記事ではAIに実際に頼んではいませんが、頼むときの決まりを先に定めます。
| 項目 | 内容 |
|---|---|
| 渡してよいもの | 失敗ログ（対象ID・操作者・時刻・種別・状況の説明。08-04で秘密情報を残さない設計にしたもの）、履歴データの集計結果（件数）、健全性確認の出力 |
| 渡す前に人が確かめること | 秘密情報・個人情報（依頼の本文、連絡先、接続先）が混ざっていないこと（06-04）。03-01のデータ持出しの制約に反しないこと |
| 任せてよいこと | 件数の集計、前回との差分の整理、「どの依頼で何が起きたか」の一覧化、一覧の下書き |
| 任せてはいけないこと | 正常／異常の判断、止める・戻す・報告するの判断、異常の目安の変更。AIの要約に「異常なし」とあっても、人が元の記録を見て判断する |
| 記録に残すこと | AIに渡したもの、AIの整理結果、人の判断。AIの整理結果を「確認結果」として単独で残さない |
6. 実行結果（運用項目・確認頻度一覧）
| 項目 | 分類 | 確認方法 | 頻度 | 担当 | 異常の目安（架空の仮定） |
|---|---|---|---|---|---|
| サーバーの応答 | 稼働 | 確認コマンドの実行 | 毎日1回 | 運用担当（架空） | 応答しない状態が続く場合 |
| エラーの発生 | 稼働 | 失敗ログの件数確認 | 毎日1回 | 運用担当（架空） | 1日に3件以上（架空の仮定） |
| 日ごとの提出・承認件数 | 業務結果 | 履歴データの集計 | 週1回 | 運用担当（架空） | 極端な増減（架空の仮定） |
| 提出済みのまま一定期間承認されない依頼の件数 | 業務結果 | 状態と提出日の確認 | 週1回 | 運用担当（架空） | 3営業日を超える依頼が1件以上（架空の仮定） |
| 「承認したはずが記録がない」という申告の件数 | 業務結果 | 総務課長への申告記録 | 発生都度 | 総務課長（架空） | 申告が1件でもあれば12-02の初動手順へ |
| 利用費用 | 費用 | 契約先の費用明細の確認 | 月1回 | 運用担当（架空） | 想定を超える場合（金額は未確定） |
7. 確認結果
実行環境：本節は文書によるまとめであり、コードの実行は伴いません。作成日：2026-09-20、項目の展開：2026-09-21。この記事で実際に定期確認（監視）を行った実績はありません。
完了条件との照合：
| 完了条件 | 確認結果 |
|---|---|
| 稼働・業務結果・費用の3分類がある | 第6節の表に記載 |
| 各項目に頻度と担当がある | 第6節の表に記載 |
| 各項目に「何を見る・なぜ見る・正常／異常・異常ならどこへ」がある | 第5.1〜5.3節の表に記載 |
| 異常の目安が架空の仮定として書かれている | 第5節・第6節の表に記載（すべて架空の仮定と明記） |
| 異常時の導線が、実在する記事・手順を指している | 12-02（初動）、11-04（切戻し）、10-03（割当変更）、13-01（改善要望） |
| AIに整理を任せる場合の渡すもの・任せないことが決まっている | 第5.4節に記載 |
この記事で確かめたこと：運用項目が、この題材アプリで実際に取れる記録（11-02の健全性確認、08-04の失敗ログ、08-02の履歴データ、01-03の申告）に対応づいていること。異常時の導線が実在する手順を指していること。
この記事で確かめていないこと：
| 範囲 | 理由 | どこで確かめるか |
|---|---|---|
| 実際に定期確認を行い、異常の目安が妥当か | 運用未実施。目安はすべて架空の仮定 | 実際の運用開始後、13-01で見直す |
| 通知の仕組み | 未実装（第8.1節） | 実装後に12-02の入口として |
| AIに整理を任せた場合の実際の結果 | この記事ではAIに頼んでいない | 実際の運用で第5.4節の決まりに従って試す |
| 費用の具体的な金額 | 技術選定が未確定 | 03-03の確定後 |
| 見落としている確認項目 | 実際に運用してみて分かるもの | 運用開始後 |
残る制限：この記事の運用項目一覧は、実際に運用してみて分かる項目（見落としている確認項目など）を反映したものではありません。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 人が定期確認する項目と、通知に任せる項目
| 区分 | 項目 | 理由 |
|---|---|---|
| 人が定期確認する | 日ごとの提出・承認件数、利用費用 | 頻度が低く（週1回・月1回）、傾向を見る必要があるため人が確認する |
| 通知に任せられる | サーバーの応答、提出済みのまま一定期間承認されない依頼 | 明確な基準（応答しない、3営業日超過）があるため、基準を超えたら自動的に知らせる仕組みに任せられる可能性がある（この記事では実装せず、12-02で検知の入口として扱う） |
運用担当の負担を考えると、明確な基準で判定できる項目は通知に任せ、傾向を見る必要がある項目だけを人が定期確認する、という分担が考えられます。ただし、この記事では通知の仕組み自体は実装しておらず、12-02で「記録・通知・申告」という3つの入口の1つとして扱います。通知が実装されるまでは、「通知に任せられる」項目も人が定期確認します（実装していない通知に任せたつもりにならない）。
8.2 適用限界
この一覧は、架空企業「みらい業務サービス」の小規模な運用体制（運用担当1名、架空）を前提にした一例です。利用者や依頼の件数が増えた場合、頻度・担当・目安は見直しが必要です。異常の目安の数値は運用の実績で置き換えます。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 運用項目・確認頻度一覧ひな形（項目、分類、確認方法、頻度、担当、異常の目安） | templates/12-01-operations-items_template.md | templates/12-01-operations-items_example.md |
自分の業務に使うときの手順は次のとおりです。
- 稼働・業務結果・費用の3分類で、確認すべき項目を洗い出す
- 各項目の確認方法・頻度・担当を決める
- 異常の目安を決める（架空の想定であれば明記する）
- 人が定期確認する項目と、通知に任せられる項目を分け、通知が無い間は人が見る
- 異常を見つけたときに進む手順（初動・切戻し・割当変更・改善要望）を項目ごとに決める
- AIに整理を任せるなら、渡すもの・渡す前の確認・任せないことを決める
10. 次工程への受渡し
次へ渡すもの：運用項目・確認頻度一覧。
次工程での使われ方：12-02（異常を検知し影響を判断する）では、この一覧の項目（失敗ログ、申告）を検知の入口にします。11-04の切戻しは、稼働の項目でコードの不一致が出たときの導線です。13-01（改善要望と優先順位を整理する）では、この一覧の確認結果を改善判断の材料にします。
前工程へ戻る条件：業務結果の項目が01-03の指標と食い違う場合は、01-03に戻って確認します。確認方法が11-02の健全性確認・08-04の失敗ログと食い違う場合は、それぞれの記事に戻ります。
11. 根拠と更新情報
- この記事の会社・人物・データはすべて架空の設定です。
- 業務結果の指標は01-03、引渡し内容は11-04、健全性確認は11-02、失敗ログは08-04、履歴データは08-02に基づきます。
- 2026-09-21（Phase 5B-2C2）：運用項目ごとに「何を見る・なぜ見る・正常／異常の区別・誰が・異常ならどこへ」を第5節に展開し、AIに整理を任せる場合の注意（第5.4節）と、通知が無い間は人が見る方針（第8.1節）を追加した。3分類・頻度・担当・異常の目安は変えていない。実際の定期確認は行っていない。
- 制作の来歴：本文はClaude Codeが作成しました。人（ユーザー）による実読・内容確認、実際の運用は未実施です。
- 未確認事項：実際の定期確認（監視）の実施、異常の目安の妥当性、通知の仕組み、AIに整理を任せた場合の結果、費用の具体的な金額は、この記事の時点では確認していません。