データ分析への質問と回答

質問文（版 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だけを返す。

職種: データ分析（米国の職業分類では データサイエンティスト、SOC 15-2051）

この職種の業務（米国 O*NET の業務記述の日本語訳）:
1. 研究の結果に影響しうる関係・傾向・要因を見つける
2. 統計ソフトで大規模なデータを分析・加工・処理する
3. 専用ソフトで、分析結果を伝えるグラフや図を作る
4. 予測の精度を保つため、モデルを検証し、作り直す
5. 数理モデルやデータ分析の結果を、経営陣や利用者に口頭や文書で発表する

この職種で使われているAIツール（各社の公式ページの説明。判断材料の一部）:
- Databricks Genie（Databricks）: 組織のデータについて自然言語で質問し、答えを得るAI。AI/BIダッシュボードを見る場所も兼ねる。
- Snowflake Cortex Analyst（Snowflake）: Snowflake のデータに、業務の利用者が自然言語で質問して答えを得る。質問からSQLを作る。
- Tableau Agent（Salesforce（Tableau））: ワークブックやデータソースにつなぎ、自然言語の指示でデータの分析を進めてグラフを作る。

問い
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年）: ほぼ同じ。分析が安くなれば求められる分析の数は増えるが、定型の問い合わせは業務部門が自然言語ツールで自ら済ませるようになり、専門職に回る量は減る。両者が相殺し、全体の量は大きく変わらないと見る。ただし分析結果の信頼性を担保する仕事は増えやすい。

{"tasks": [{"no": 1, "weight": 25, "now": 25, "year1": 35, "year5": 50, "human_layers": ["品質の確認", "例外の発見", "目的と制約の設定"], "blockers": ["技術", "相手の受け入れ"], "enablers": ["技術", "費用"], "outlook": "相関の網羅探索や仮説の候補出しはAIに移り、業務上意味のある関係の見極めとデータの癖への気づきは人に残る。AIが社内の背景知識を十分に取り込めば見極めも移る。探索結果の誤りが重い判断に直結する領域では人の確認が増え、移る部分が戻る。", "confidence": "中"}, {"no": 2, "weight": 30, "now": 45, "year1": 55, "year5": 70, "human_layers": ["品質の確認", "例外の発見"], "blockers": ["技術", "制度・契約"], "enablers": ["技術", "費用", "制度・契約"], "outlook": "SQLや加工コードの生成、前処理、定型の集計は自然言語で指示できるツールに移る。データ定義の曖昧さや元データの欠損・異常への気づきと結果の検算は人に残る。メタデータ整備が進みツールが定義を正しく解釈できれば確認も減る。逆にデータ基盤が散在する職場では生成結果の検証が残る。", "confidence": "高"}, {"no": 3, "weight": 10, "now": 50, "year1": 60, "year5": 75, "human_layers": ["品質の確認", "実行の承認"], "blockers": ["技術", "相手の受け入れ"], "enablers": ["技術", "費用", "相手の受け入れ"], "outlook": "指示からのグラフ作成や体裁調整はほぼAIに移る。伝えたい主張に合う見せ方の選択と、誤解を招く表現がないかの確認は人に残る。AIが分析の目的と相手を把握して提案の質が上がれば選択も移る。逆に社内の様式や既存ダッシュボードとの整合が厳しい職場では手直しが残る。", "confidence": "高"}, {"no": 4, "weight": 15, "now": 35, "year1": 45, "year5": 60, "human_layers": ["例外の発見", "実行の承認", "目的と制約の設定"], "blockers": ["技術", "制度・契約"], "enablers": ["技術", "費用"], "outlook": "精度監視、再学習、特徴量の試行はAIと自動化基盤に移る。性能低下の原因がデータか業務の変化かの見極めと、本番に戻してよいかの判断は人に残る。監視から再学習までの基盤が整い、判断基準を明文化できれば承認も移る。逆に説明責任が求められる用途では検証の記録と人の確認が増える。", "confidence": "中"}, {"no": 5, "weight": 20, "now": 20, "year1": 25, "year5": 35, "human_layers": ["作業", "実行の承認", "目的と制約の設定"], "blockers": ["技術", "相手の受け入れ"], "enablers": ["技術", "費用"], "outlook": "資料の下書きや要約はAIに移るが、経営陣への説明、質疑への応答、結果をどう受け止めるかの合意形成は人に残る。相手がAIの説明を直接受け入れ、質疑もAIで済むようになれば移る。逆に分析結果が組織の方針を左右するほど、説明する人の立ち会いが求められ、移る部分が戻る。", "confidence": "中"}], "share_now": 34, "share_year1": 43, "share_year5": 57, "reason": "最も大きいのは大規模データの加工・集計で、作業の層が自然言語からSQLを作る問い合わせツールに移る。グラフ作成の作業も自然言語で指示する可視化ツールに移る。関係や要因の探索は作業と一部の品質確認がコード生成と分析エージェントに移る。モデル検証の作業は監視・再学習の自動基盤に移る。発表は下書きが文書生成に移り、説明と承認は人に残る。", "demand": "ほぼ同じ", "demand_reason": "分析が安くなれば求められる分析の数は増えるが、定型の問い合わせは業務部門が自然言語ツールで自ら済ませるようになり、専門職に回る量は減る。両者が相殺し、全体の量は大きく変わらないと見る。ただし分析結果の信頼性を担保する仕事は増えやすい。", "remains": "経営判断に直結する問いの設定、データの癖や異常への気づき、モデルを本番に戻す承認、経営陣への説明と質疑が残る。理由は、業務の背景知識と組織内の合意形成を今のAIが十分に扱えず、分析の誤りの責任を人が確かめる形で負うため。AIが社内の文書や会話から背景を取り込み、相手がAIの説明を直接受け入れるようになれば、説明と問いの設定も移り、残るのは承認と例外対応に絞られる。", "who": "仕事の量がほぼ同じでも、一人がこなせる分析が増えるため、人数は緩やかに減るか横ばい。集計やグラフ作成を主に担っていた若手の枠が縮み、業務を理解して問いを立て、結果を説明できる中堅以上の比重が高まる。経験の浅い人が定型作業で育つ道が細くなり、少人数でAIを使って幅広く担う構成になる。業務部門側で分析を担う人は増える。", "skills": "AIが出したSQLやコード、統計の結果を素早く検算し、誤りを見抜く力。データの定義や収集の経緯を把握し、ツールが誤解しそうな点を先回りして整える力。経営の問いを分析可能な形に翻訳し、結果の限界を含めて意思決定者に説明する力。モデルの監視と再学習の基盤を設計し、承認の基準を明文化する力。業務部門がツールで自ら分析できるよう教え、データの統治を担う力。"}

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": 25,
      "now": 30,
      "year1": 42,
      "year5": 62,
      "human_layers": [
        "品質の確認",
        "例外の発見",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "関係や傾向の探索はAIに移り、人は測定と因果の仮説を点検するが、実験や外部条件で検証できれば探索判断も減る。交絡や欠測が隠れていれば、見つけた関係も人が調べ直す。",
      "confidence": "中"
    },
    {
      "no": 2,
      "weight": 25,
      "now": 55,
      "year1": 68,
      "year5": 85,
      "human_layers": [
        "品質の確認",
        "例外の発見"
      ],
      "blockers": [
        "技術"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "加工コードと定型分析はAIが作り、人は定義と結合の誤りを確かめるが、データの意味まで検証できれば確認も減る。形式が整っていても収集条件が違えば、処理手順を人が組み直す。",
      "confidence": "中"
    },
    {
      "no": 3,
      "weight": 10,
      "now": 65,
      "year1": 78,
      "year5": 90,
      "human_layers": [
        "品質の確認",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術",
        "相手の受け入れ"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "グラフの作成はAIに移り、人は比較の目的と誤解のない表現を選ぶが、読者の理解を評価できれば選定も縮む。軸や集計単位が意味を歪める場合は、自動で作った図も人が修正する。",
      "confidence": "中"
    },
    {
      "no": 4,
      "weight": 25,
      "now": 35,
      "year1": 48,
      "year5": 68,
      "human_layers": [
        "品質の確認",
        "例外の発見",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "評価実行と再学習はAIに移り、人は検証条件と変化を点検するが、未知の環境での劣化を捉えられれば監視も減る。データ漏えいや分布の変化を検知できなければ、通常の検証から人が見直す。",
      "confidence": "低"
    },
    {
      "no": 5,
      "weight": 15,
      "now": 40,
      "year1": 52,
      "year5": 72,
      "human_layers": [
        "作業",
        "品質の確認",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術",
        "相手の受け入れ"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "説明資料の下書きはAIが作り、人は意思決定に必要な論点を選ぶが、利用者の制約と理解を確かめられれば説明も減る。分析結果が現場の意味とずれるなら、資料作成の前提から人が調整する。",
      "confidence": "中"
    }
  ],
  "share_now": 43,
  "share_year1": 55,
  "share_year5": 74,
  "reason": "現在は自然言語からのSQL作成、データ加工、グラフ作成で作業時間が減る。1年では分析の手順と報告がつながり、5年では検証の実行と再学習の一部までAIが扱う。人には問いの設定、収集条件の確認、因果の取り違えやデータ漏えいの発見が残る。コードが動き指標が良くても利用環境で正しいとは限らず、検証方法と結果の意味を確かめる時間を多く残した。",
  "demand": "増える",
  "demand_reason": "分析にかかる費用が下がり、小さな部門や日常の判断でも分析を使いやすくなる。作る予測や比較の数は増えるとみるが、定型の問い合わせは利用者が直接行える。専門職への依頼は、難しい検証と判断支援に寄る。",
  "remains": "何を測り、どの比較で判断するかを定める仕事が残る。人は収集条件、欠測、交絡、検証への情報混入を調べ、良い結果が実際の利用でも成り立つかを確かめる。経営や現場が何を変えられるかを聞き、分析を行動へ結びつける役割も続く。データの意味と環境変化を自動で検証でき、利用者が結果の条件を理解して使えるなら、確認と説明の時間は減る。",
  "who": "分析需要が増えるため、職種全体の人数が減るとは限らないが、定型の集計と図表作成だけを担う役割は縮む。一人が分析から検証、運用まで扱う範囲が広がり、実験設計や事業理解に強い人の比重が上がる。若手は生成コードを動かすだけでなく、元データの異常を追い、誤った結論を修正する経験が必要になる。難しい検証に使う時間を確保できる体制が重要になる。",
  "skills": "問いを測定と検証の設計へ落とし、データの意味を業務の現場に確認する力が要る。AIが作ったSQLや分析では、母集団、結合、欠測、比較条件を点検する。予測の評価では情報混入と環境変化を調べ、精度以外の費用や影響も確かめる。結果の成立条件を説明し、追加の実験が必要か、使える範囲を限定すべきかを判断する力が求められる。"
}