IT運用・インフラへの質問と回答

質問文（版 5）

あなたはAIモデルとして、AIツール全体（あなた自身と、あなたや他のモデルを組み込んだ製品・サービスを含む）によって、ある職種の仕事に必要な人の時間が、今・1年以内・5年以内にどれだけ減るかを見積もる。日本の読者向けの職業情報サイトに、あなたの回答がそのまま、あなたのモデル名と回答日付きで掲載される。読者はこの職種で働く人で、自分の仕事のどこがどれだけ変わるかを知りたい。

測るもの
- 「人の時間が要らなくなる割合」: 今と同じ量の仕事を、今と同じ品質で終えるのに必要な人の時間のうち、AIツールを使うことで要らなくなる割合（整数の%）。AIの結果を人が確認・手直し・承認する時間は、人の時間として残す。例: 100分かかっていた仕事が、AIの結果を5分確認するだけになれば95%。
- 「今」は今あるAIツールを、この職種の職場が十分に使った場合の値。まだ使っていない職場が多いことは、この値を下げる理由にしない。「1年以内」「5年以内」はその時点であると見込むツールを十分に使った場合の値。
- 仕事の量（需要）の増減はこの割合に入れない。別の問いで答える。
- 業務ごとに、仕事時間に占める比重（全業務の合計を100）と、その業務で人の時間が要らなくなる割合を出す。職種全体の割合は比重で重みづけした合計にする。業務の数で割る計算はしない。

見立ての立て方
- 人に残るとする部分にも、AIに移るとする部分にも、同じ基準で理由を書く。理由の種類は両側とも「技術」「制度・契約」「費用」「相手の受け入れ」の4つ。人に残る側なら、技術が足りない／制度や契約が人を求める／AIに任せると高くつく／顧客や相手が人を求める。AIに移る側なら、技術が足りている／制度や契約が妨げない／AIに任せると安い／顧客や相手が受け入れる。
- どちらの見立てにも、それが崩れる条件を書く。人に残るとした部分がAIに移る条件と、AIに移るとした部分が人に残る条件の両方を書く。
- 人が最終的な責任を負うことは、それだけでは人の時間がどれだけ要るかを決めない。責任を負うために、誰が何をどれだけ確かめるかで見積もる。逆に、AIが成果物を出せることは、それだけでは人の時間がなくなることを意味しない。確認・手直し・例外への対応にかかる時間を数える。
- 業務の中で人に残る部分は、次の5つの層で示す。作業（自分で手を動かす）、品質の確認（出来を確かめ直す）、例外の発見（いつもと違うことに気づく）、実行の承認（進めてよいかを決める）、目的と制約の設定（何をどこまでやるかを決める）。並びに順序や難易度の意味はない。どの層も人に残ることがあり、どの層もAIに移ることがある。残る層には、その層に人の時間がはっきり残るものだけを挙げる（5つ全部が残るのは、本当にそうである業務だけ）。その層で人が何をするかは、要点の文に書く。
- 根拠は下の資料と、あなたが知っている今のAIツールの機能、あなたが見込む今後の進歩。今できることと将来の見込みを分け、業務ごとに確信の度合い（高・中・低）を添える。人に残る時間が少ないという答えも、ほとんど変わらないという答えも認める。仕事の量の見立ては「不明」でもよい。
- 言い切れるところは言い切り、根拠の弱いところは弱いと書く。確信の度合いは項目で示し、「推定である」「統計値ではない」のような断り書きは文章に書かない（掲載時にあなたの見立てとして示す）。
- 研究や統計の数字、企業が公表した効果の数字を引用しない。人名を挙げない。ツールや製品の名前は挙げてよいが、企業の意図や方針を推測しない。
- 文章は日本語。業務を指すときは、番号や記号ではなく業務の内容を書く（読者は番号付きの一覧を見ない）。
- この会話にある情報と、あなた自身の知識だけで答える。ウェブを検索しない。過去の会話、保存された記憶、他のAIモデルの回答を参照しない。
- 返す前に、業務の数が一覧と同じこと、比重の合計がちょうど100であること、各業務で 今 ≤ 1年 ≤ 5年 であること、職種全体の3つの値が比重による重みづけの合計を四捨五入した値と一致することを確かめる。
- JSONだけを返す。

職種: IT運用・インフラ（米国の職業分類では ネットワーク・システム管理者、SOC 15-1244）

この職種の業務（米国 O*NET の業務記述の日本語訳）:
1. ハードウェア・ソフトウェア・ネットワーク・システムの問題を診断して解決し、必要なら故障した部品を交換する
2. ハードウェア、ネットワークソフトウェア、OSを設計・設定・テストする
3. PBX・ボイスメール・電話システムなどの音声サービスと機器を導入し、技術支援を行う
4. データ・ソフトウェア・ハードウェアを守るネットワークのセキュリティ対策を計画・調整・実施する
5. 機器の性能の記録を分析し、修理や交換の必要を判断する
6. システムとネットワークの構成の改善を提案し、それに伴うハードウェアやソフトウェアの要件を決める
7. データのバックアップと災害復旧の作業を行う
8. ハードウェア、システムソフトウェア、アプリケーション、各種の設定を含むネットワークと計算環境を維持・管理する
9. メールのアプリケーションやウイルス対策ソフトを設定・監視・維持する

この職種で使われているAIツール（各社の公式ページの説明。判断材料の一部）:
- Bits AI SRE（Datadog）: アラートが出ると調査を始め、手順書や過去の調査を参照しながら原因の仮説を一つずつ確かめる。
- PagerDuty AI（PagerDuty Advance）（PagerDuty）: 障害対応の担当者を、状況の要約、状況報告の下書き、事後レビューの作成、繰り返しの作業を引き受けるエージェントで支える。

問い
1. 上の一覧のすべての業務について、一覧の順に次を答える。
   a. 比重: この職種の仕事時間に占める割合（整数の%。全業務の合計を100にする）。
   b. 今・1年以内・5年以内に、その業務で人の時間が要らなくなる割合（整数の%。今 ≤ 1年 ≤ 5年）。
   c. 5年後もこの業務で人の時間がはっきり残る層（作業／品質の確認／例外の発見／実行の承認／目的と制約の設定 から。層の名前だけを配列で。何も残らなければ空）。
   d. 5年後も人の時間が残る理由の種類（技術／制度・契約／費用／相手の受け入れ から、当てはまるものすべて。人の時間が残らなければ空）。
   e. 5年後にAIに移る理由の種類（同じ4つから、当てはまるものすべて。何も移らなければ空）。
   f. 5年後の見立ての要点と、それが崩れる条件（150字以内。人に残る部分がAIに移る条件と、AIに移る部分が人に残る条件を1文ずつ）。
   g. 確信の度合い（高／中／低）。
2. 職種全体で人の時間が要らなくなる割合（今・1年以内・5年以内）。1の比重で重みづけした合計を、整数に四捨五入する。
3. 2の理由。どの業務のどの層がAIに移り、どの種類のツールが引き受けるか（200字以内）。
4. 5年で、この職種への仕事の量（需要）はどう変わるか（増える／ほぼ同じ／減る／不明）と、その理由（150字以内）。
5. この職種は5年でどう変わるか。次の3つにそれぞれ答える（各200字以内）。
   a. 何が残るか: 人が担う業務と層。残るとした理由と、それが崩れる条件に触れる。
   b. 誰が残るか: 4の仕事の量の見立てと合わせて、担当者の人数・構成・経験の変化。
   c. 求められる力: 残る人に新たに求められる力。

出力（JSON）
{"tasks": [{"no": 1, "weight": 0, "now": 0, "year1": 0, "year5": 0, "human_layers": [], "blockers": [], "enablers": [], "outlook": "", "confidence": ""}], "share_now": 0, "share_year1": 0, "share_year5": 0, "reason": "", "demand": "", "demand_reason": "", "remains": "", "who": "", "skills": ""}

Claude Fable 5.1

Claude のモデル名の表示は「Claude Fable 5.1」。回答日 2026年10月21日。取得の条件: Claude Code のサブエージェントが回答（アプリではない）。職種ごとに新しい文脈で、入力は質問文のファイル1つだけ。ウェブ検索と他のファイルの読み込みを禁じた。他の職種・他モデル・版4の回答、モックの数値は渡していない。Claude Code の既定のシステム指示とプロジェクトの AGENTS.md が文脈に入る。検査に落ちた回答は新しい文脈で聞き直した（経理・財務と金融専門職の各1回。research/opinions/v5-2026-10-21/rejected/）。

仕事の量（5年）: ほぼ同じ。管理対象のシステムとセキュリティ要件は増え続ける一方、1人あたりの対応範囲は広がる。運用の外注やクラウド移行で社内の人数を減らす企業と、自動化の運用自体に人を置く企業が相殺し、総量は大きく変わらないと見る。

{"tasks": [{"no": 1, "weight": 20, "now": 25, "year1": 35, "year5": 55, "human_layers": ["作業", "例外の発見", "実行の承認"], "blockers": ["技術", "制度・契約"], "enablers": ["技術", "費用"], "outlook": "ログの相関と原因仮説の検証はエージェントに移り、人は部品の物理交換、手順書にない障害への気づき、復旧操作の承認に残る。現地作業が保守契約で外部に移り自動復旧の実績が積めば承認も減る。本番への自動変更を禁じる運用規程が続けば、人の確認時間は減らない。", "confidence": "中"}, {"no": 2, "weight": 12, "now": 25, "year1": 35, "year5": 55, "human_layers": ["品質の確認", "実行の承認", "目的と制約の設定"], "blockers": ["技術", "制度・契約"], "enablers": ["技術", "費用"], "outlook": "設定ファイルやIaCの生成、テスト計画の作成は移り、人は要件の決定と設計の妥当性確認、本番投入の承認に残る。生成した構成を検証環境で自動試験し実績が積めば確認は薄くなる。構成の誤りが停止事故に直結する環境では、人が全行を読む運用が続く。", "confidence": "中"}, {"no": 3, "weight": 4, "now": 15, "year1": 20, "year5": 35, "human_layers": ["作業", "実行の承認"], "blockers": ["技術", "制度・契約"], "enablers": ["技術"], "outlook": "機器の設置と配線、古い電話システム固有の操作は技術的に人に残り、クラウド型の電話なら設定の多くが移る。PBXの撤去とクラウド移行が進めば現地作業そのものが消える。既存機器を使い続ける契約や拠点が多ければ、人の作業は減らない。", "confidence": "低"}, {"no": 4, "weight": 12, "now": 20, "year1": 30, "year5": 50, "human_layers": ["例外の発見", "実行の承認", "目的と制約の設定"], "blockers": ["制度・契約", "相手の受け入れ"], "enablers": ["技術", "費用"], "outlook": "脅威検知の一次判定と対策案の作成は移り、人は方針と許容リスクの決定、見慣れない兆候への気づき、遮断の承認に残る。誤遮断の損失が小さい環境では自動対応の範囲が広がる。監査や取引先が人の判断記録を求める限り、承認は人に残る。", "confidence": "中"}, {"no": 5, "weight": 6, "now": 40, "year1": 50, "year5": 70, "human_layers": ["実行の承認"], "blockers": ["制度・契約"], "enablers": ["技術", "費用"], "outlook": "性能記録の集計、異常の抽出、交換時期の予測は移り、人は予算を伴う交換の承認に残る。予算枠内の交換を自動発注できる契約があれば承認も減る。記録やセンサーの品質が低い現場では、人が現物を見て判断する時間が戻る。", "confidence": "中"}, {"no": 6, "weight": 8, "now": 25, "year1": 35, "year5": 50, "human_layers": ["実行の承認", "目的と制約の設定"], "blockers": ["技術", "相手の受け入れ"], "enablers": ["技術", "費用"], "outlook": "現状分析と改善案の比較、要件一覧の下書きは移り、人は事業上の目的と制約の設定、提案の採否に残る。目的が定型的で費用上限が決まっていれば案の選定まで任せられる。組織の事情や将来計画を文書にできない場合、人が案を練る時間は残る。", "confidence": "中"}, {"no": 7, "weight": 7, "now": 30, "year1": 40, "year5": 60, "human_layers": ["品質の確認", "実行の承認"], "blockers": ["制度・契約", "技術"], "enablers": ["技術", "費用"], "outlook": "バックアップの実行監視、復旧手順の生成、訓練記録の作成は移り、人は復元結果の確認と本番復旧の承認に残る。復元検証を自動で繰り返し成功実績が積めば確認は減る。復旧の失敗が事業停止に直結する場面では、人が結果を直接確かめる手順が続く。", "confidence": "中"}, {"no": 8, "weight": 23, "now": 30, "year1": 40, "year5": 60, "human_layers": ["例外の発見", "実行の承認"], "blockers": ["技術", "制度・契約"], "enablers": ["技術", "費用"], "outlook": "パッチ適用や設定変更の実行、監視と一次対応はエージェントに移り、人は想定外の挙動への気づきと変更の承認に残る。変更失敗時の自動巻き戻しが信頼されれば承認は限られる。自動化に対応しない古い機器やアプリが多い環境では、人の作業が残る。", "confidence": "中"}, {"no": 9, "weight": 8, "now": 35, "year1": 45, "year5": 65, "human_layers": ["例外の発見", "実行の承認"], "blockers": ["相手の受け入れ"], "enablers": ["技術", "費用"], "outlook": "ルール設定、検知結果の確認、更新の適用は移り、人は新手の攻撃への気づきと隔離の承認に残る。クラウド型のメール保護で自動対応が標準になれば承認はほぼ消える。誤検知による業務停止を許容しない部門が多ければ、人の確認は残る。", "confidence": "高"}], "share_now": 27, "share_year1": 37, "share_year5": 56, "reason": "維持・管理と障害対応の作業層、性能記録や検知結果の確認層が、Bits AI SREのような調査エージェント、PagerDuty AIのような障害対応支援、IaCとパッチ管理の自動化に移る。残るのは物理作業、本番変更と遮断の承認、方針と要件の設定で、確認と承認の時間を数えると5年で半分強が要らなくなる。", "demand": "ほぼ同じ", "demand_reason": "管理対象のシステムとセキュリティ要件は増え続ける一方、1人あたりの対応範囲は広がる。運用の外注やクラウド移行で社内の人数を減らす企業と、自動化の運用自体に人を置く企業が相殺し、総量は大きく変わらないと見る。", "remains": "物理機器の交換と配線、本番環境への変更と遮断の承認、セキュリティ方針と構成要件の設定が残る。理由は、遠隔では手が届かない技術の限界と、変更管理や監査が人の判断記録を求める制度にある。保守契約で現地作業が外部に移り、自動変更の巻き戻しが信頼されれば承認も薄くなる。逆に古い機器やアプリが残る環境では作業層が長く残る。", "who": "需要がほぼ同じでも、一次対応と定型作業に当てていた若手の枠は減り、少人数で広い範囲を見る構成に寄る。残るのは、自動化の設計と監督、変更の可否判断、障害時の最終判断ができる経験者で、未経験者が監視や一次対応で育つ入口は狭くなる。", "skills": "エージェントに調査や変更を任せる前提で、手順書と監視を機械が読める形に整える力、IaCやパッチ自動化の設計と検証の力、自動対応の結果を短時間で検証し誤りに気づく力、変更の影響とリスクを説明して承認を取る力が求められる。"}

GPT-6 Astra

ChatGPT のモデル名の表示は「GPT-6 Astra」。回答日 2026年10月21日。取得の条件: Codex のタスク（gpt-6-astra 指定）が回答。ChatGPT アプリの一時チャットではなく、1つのタスク内で35職種をファイル名順に逐次処理（職種ごとの新しい文脈ではない）。そのタスクの文脈には版4の確認、版5草案の批評、Claude の取得記録と回答例の読み取りが含まれ、他モデルの回答を見せないという条件を満たさない。実行時のモデル名は独立に確認されていない。ウェブ検索はしていない。保存後に研究開発と映像・動画制作の「何が残るか」の文章を同じタスクが1語ずつ直した（数値の変更なし。research/opinions/v5-2026-10-21/astra-2026-10-21/corrections.json）。

仕事の量（5年）: 増える。管理するサービス、データ、連携先が増え、監視と復旧の対象も広がるとみる。自動化で小さな環境も管理しやすくなる一方、クラウドへの集約で減る機器管理もある。増える管理対象に対し、必要な人数は同じ割合では増えない。

{
  "tasks": [
    {
      "no": 1,
      "weight": 20,
      "now": 30,
      "year1": 42,
      "year5": 62,
      "human_layers": [
        "作業",
        "品質の確認",
        "例外の発見",
        "実行の承認"
      ],
      "blockers": [
        "技術",
        "費用"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "ログの調査と復旧候補はAIに移り、人は影響と現物を確かめるが、原因と復旧結果を検証できれば判断も減る。複合障害や部品の故障を扱えなければ、定型の復旧にも人が介入する。",
      "confidence": "中"
    },
    {
      "no": 2,
      "weight": 12,
      "now": 40,
      "year1": 52,
      "year5": 72,
      "human_layers": [
        "品質の確認",
        "実行の承認",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "設定案とテストはAIが進め、人は要件と変更の影響を確認するが、実環境を再現して検証できれば確認も縮む。機器固有の挙動や依存関係が抜ければ、設定の作成から人が修正する。",
      "confidence": "中"
    },
    {
      "no": 3,
      "weight": 6,
      "now": 20,
      "year1": 30,
      "year5": 48,
      "human_layers": [
        "作業",
        "品質の確認",
        "例外の発見"
      ],
      "blockers": [
        "技術",
        "費用"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "設定案と問い合わせ対応はAIが助け、人は配線と通話品質を確かめるが、遠隔診断が十分なら現場作業も減る。物理機器や拠点の通信に問題があれば、標準的な導入にも人の対応が要る。",
      "confidence": "中"
    },
    {
      "no": 4,
      "weight": 12,
      "now": 25,
      "year1": 38,
      "year5": 58,
      "human_layers": [
        "品質の確認",
        "例外の発見",
        "実行の承認",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術",
        "制度・契約"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "対策案と設定確認はAIに移り、人は保護対象と許容する影響を決めるが、攻撃と業務の両面を検証できれば判断も減る。誤遮断や未知の攻撃が増えれば、自動対策にも人の点検が戻る。",
      "confidence": "低"
    },
    {
      "no": 5,
      "weight": 8,
      "now": 45,
      "year1": 58,
      "year5": 78,
      "human_layers": [
        "品質の確認",
        "実行の承認"
      ],
      "blockers": [
        "技術",
        "費用"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "性能の監視と交換候補はAIに移り、人は費用と停止の影響を判断するが、故障と需要を予測できれば判断も縮む。機器の劣化や負荷変動を捉えられなければ、記録の分析も人がやり直す。",
      "confidence": "中"
    },
    {
      "no": 6,
      "weight": 10,
      "now": 30,
      "year1": 42,
      "year5": 60,
      "human_layers": [
        "品質の確認",
        "実行の承認",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術",
        "費用",
        "相手の受け入れ"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "構成の比較案はAIが作り、人は予算と運用条件を決めるが、移行の影響を検証できれば設計確認も減る。旧システムの依存や現場の制約が抜ければ、要件整理から人が関わる。",
      "confidence": "中"
    },
    {
      "no": 7,
      "weight": 10,
      "now": 40,
      "year1": 52,
      "year5": 75,
      "human_layers": [
        "品質の確認",
        "例外の発見",
        "実行の承認"
      ],
      "blockers": [
        "技術",
        "制度・契約"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "バックアップ確認と復旧手順はAIに移り、人は復元できるかを確かめるが、隔離環境で実証できれば点検も減る。破損や侵害が複製される場合は、正常に見える保存にも人の検証が必要になる。",
      "confidence": "中"
    },
    {
      "no": 8,
      "weight": 15,
      "now": 40,
      "year1": 52,
      "year5": 75,
      "human_layers": [
        "品質の確認",
        "例外の発見",
        "実行の承認"
      ],
      "blockers": [
        "技術"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "定型の更新と構成監視はAIに移り、人は例外と変更範囲を判断するが、影響を検証し戻せるなら承認も縮む。連鎖障害や設定の食い違いがあれば、通常の保守にも人が入る。",
      "confidence": "中"
    },
    {
      "no": 9,
      "weight": 7,
      "now": 45,
      "year1": 58,
      "year5": 80,
      "human_layers": [
        "品質の確認",
        "例外の発見",
        "実行の承認"
      ],
      "blockers": [
        "技術",
        "制度・契約"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "メールと対策ソフトの監視はAIに移り、人は誤検出と権限を点検するが、利用への影響を確認できれば調整も減る。必要な通信の遮断や侵害の見逃しが増えれば、定型設定も人が修正する。",
      "confidence": "中"
    }
  ],
  "share_now": 35,
  "share_year1": 47,
  "share_year5": 67,
  "reason": "現在はアラートの要約、ログ調査、手順書の参照、設定案の作成で時間が減る。1年では調査と限定的な復旧がつながり、5年では検証可能な保守作業をAIが広く扱う。人には変更の影響の判断、例外の発見、復旧結果の確認、物理機器の交換が残る。処理を実行できることと安全に完了できることを分け、テスト、承認、切り戻しの準備と確認に使う時間を含めて見積もる。",
  "demand": "増える",
  "demand_reason": "管理するサービス、データ、連携先が増え、監視と復旧の対象も広がるとみる。自動化で小さな環境も管理しやすくなる一方、クラウドへの集約で減る機器管理もある。増える管理対象に対し、必要な人数は同じ割合では増えない。",
  "remains": "事業に必要な可用性と保護範囲を決め、変更や復旧の影響を判断する仕事が残る。人は複合障害、構成の食い違い、機器の故障を調べ、AIが示す復旧案を実際の環境で確かめる。正常なバックアップを復元できるかの検証も続く。依存関係が把握され、隔離した試験と確実な切り戻しが使えるなら、確認と承認の時間はさらに減る。",
  "who": "管理対象が増えるため、職種全体の人数が減るとは限らないが、定型監視と手順どおりの保守だけを担う役割は縮む。一人が複数環境を扱い、設計、検証、障害対応に強い人の比重が上がる。若手にはアラートを転送するだけでなく、原因を再現し、復旧後の状態を確かめる経験が必要になる。物理機器や複雑な旧環境を持つ職場では、現場担当を残す必要がある。",
  "skills": "構成と依存関係を把握し、AIに許す操作範囲と人へ戻す条件を設計する力が要る。ログの説明を受け取るだけでなく、仮説を検証し、変更が別の機能を壊さないかを確かめる。復元試験、権限管理、切り戻しの手順を整える力も重要になる。障害時には技術的な原因と事業への影響を分けて伝え、復旧の順番と実行の可否を関係者と決めることが求められる。"
}