ソフトウェア開発への質問と回答

質問文（版 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-1252）

この職種の業務（米国 O*NET の業務記述の日本語訳）:
1. システムの能力と要件を分析するため、データを保存・取得・加工する
2. 利用者のニーズと要件を分析し、期間と費用の中で設計できるかを判断する
3. 新しいシステムの導入や、既存システムの変更を分析・計画する
4. 仕様・作業・進捗について、報告書や連絡文を作る
5. 既存のソフトウェアを修正し、不具合を直し、性能を上げる
6. 顧客や他部署と、進捗・提案・技術的な課題を相談する
7. ソフトウェアのシステムを設計・開発・修正する
8. テストや検証の手順、プログラミング、文書化を進める
9. プログラマーや技術者の作業を監督する

この職種で使われているAIツール（各社の公式ページの説明。判断材料の一部）:
- Claude Code（Anthropic）: 端末やエディタから、バグ修正・テスト・リファクタリングなどの開発作業をAIエージェントが進める。
- Codex（OpenAI）: コードの読み解き、機能の追加、レビュー、不具合の修正をAIが行う。端末、エディタの拡張、クラウドで使える。
- Cursor（Anysphere）: デスクトップアプリや端末から、開発作業をAIエージェントに任せられる。複数のエージェントを並行して動かせる。
- GitHub Copilot（GitHub）: 書いているコードの補完、質問への回答、複数ファイルにまたがる変更、プルリクエストのレビューをAIが行う。

問い
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": 6, "now": 30, "year1": 45, "year5": 65, "human_layers": ["品質の確認", "目的と制約の設定"], "blockers": ["制度・契約", "技術"], "enablers": ["技術", "費用"], "outlook": "データの取得・加工・集計はエージェントが実行し、人は問いの設定と結果の妥当性確認に残る。データ基盤への接続権限と検証環境がそろえば確認も薄くなる。本番データの扱いが規程で人に限られるなら作業も人に残る。", "confidence": "中"}, {"no": 2, "weight": 8, "now": 15, "year1": 25, "year5": 40, "human_layers": ["例外の発見", "実行の承認", "目的と制約の設定"], "blockers": ["相手の受け入れ", "技術"], "enablers": ["技術", "費用"], "outlook": "要件の整理案や工数の見積もり案はAIが出し、人は利用者との対話で前提を確かめ、期間と費用の判断を行う。過去案件の記録が構造化され見積もりの精度が示されれば判断もAIに寄る。利用者が人の対話を求め続けるなら整理案の確認も厚く残る。", "confidence": "中"}, {"no": 3, "weight": 8, "now": 15, "year1": 25, "year5": 40, "human_layers": ["例外の発見", "実行の承認", "目的と制約の設定"], "blockers": ["制度・契約", "相手の受け入れ"], "enablers": ["技術", "費用"], "outlook": "影響範囲の洗い出しや移行手順案はAIが作り、人は組織間の調整と実行の承認に残る。コードと運用情報を一体で読めるエージェントが普及すれば調整案まで任せられる。変更管理の規程が人の承認を細かく求めれば確認時間は減らない。", "confidence": "中"}, {"no": 4, "weight": 7, "now": 45, "year1": 55, "year5": 70, "human_layers": ["品質の確認"], "blockers": ["相手の受け入れ"], "enablers": ["技術", "費用", "相手の受け入れ"], "outlook": "進捗や仕様の文書はコードと作業履歴からAIが生成し、人は内容の確認と相手に合わせた調整に残る。作業記録が自動で集まる環境では確認も短くなる。誤った内容が契約上の問題になる相手向け文書では人の精読が残る。", "confidence": "高"}, {"no": 5, "weight": 22, "now": 35, "year1": 50, "year5": 65, "human_layers": ["品質の確認", "例外の発見", "実行の承認"], "blockers": ["技術", "制度・契約"], "enablers": ["技術", "費用"], "outlook": "再現・原因特定・修正案・テストまでエージェントが進め、人は修正の採否と本番への影響判断に残る。本番環境の観測データに直接触れられれば採否判断も薄くなる。古い基盤や再現困難な障害では人が手を動かす時間が残る。", "confidence": "中"}, {"no": 6, "weight": 10, "now": 10, "year1": 15, "year5": 25, "human_layers": ["例外の発見", "実行の承認", "目的と制約の設定"], "blockers": ["相手の受け入れ", "制度・契約"], "enablers": ["技術"], "outlook": "相談の下準備や論点の整理はAIが担うが、合意形成と利害調整は人に残る。相手側もAIを介して論点を詰める慣行が広がれば打合せ自体が減る。技術的な責任の所在を相手が人に求める限り、人の対話時間は減らない。", "confidence": "中"}, {"no": 7, "weight": 24, "now": 35, "year1": 50, "year5": 65, "human_layers": ["品質の確認", "例外の発見", "目的と制約の設定"], "blockers": ["技術", "制度・契約"], "enablers": ["技術", "費用"], "outlook": "実装の大半はエージェントが担い、人は設計の方向付け、出来の確認、例外の発見に残る。大規模コードで設計判断の一貫性を保てるモデルが出れば設計も寄る。秘匿性の高いコードを外部モデルに渡せない契約なら作業が人に残る。", "confidence": "中"}, {"no": 8, "weight": 10, "now": 50, "year1": 60, "year5": 75, "human_layers": ["品質の確認", "目的と制約の設定"], "blockers": ["制度・契約", "技術"], "enablers": ["技術", "費用"], "outlook": "テストコードと検証手順、文書の生成はほぼAIに移り、人は何を検証すべきかの基準設定と結果の確認に残る。要件から検証基準を導く精度が上がれば基準設定も寄る。安全規格が人による検証記録を求める分野では作業が人に残る。", "confidence": "高"}, {"no": 9, "weight": 5, "now": 10, "year1": 15, "year5": 25, "human_layers": ["例外の発見", "実行の承認", "目的と制約の設定"], "blockers": ["制度・契約", "相手の受け入れ"], "enablers": ["技術"], "outlook": "進捗把握や作業の振り分け案はAIが出すが、人の育成と評価、優先順位の最終判断は人に残る。エージェントの作業が主で人の作業が減れば監督対象自体が変わり時間は縮む。組織が人の管理責任を求める限り承認の時間は残る。", "confidence": "低"}], "share_now": 30, "share_year1": 42, "share_year5": 56, "reason": "設計・開発・修正と既存ソフトの修正・不具合対応の「作業」層の大半がコーディングエージェント（Claude Code、Codex、Cursor、GitHub Copilot）に移り、テスト・文書・報告の作成も生成に寄る。人に残るのは要件の判断、相手との調整、修正の採否と承認、出来の確認で、確認時間を人の時間として数えるため半分強にとどまる。", "demand": "ほぼ同じ", "demand_reason": "一人あたりの生産量が上がる分、同じ仕事に要る人数は減るが、開発費用が下がることで着手される案件が増え、保守対象のソフトも増える。両者が打ち消し合い、総量は大きく変わらないと見る。経験の浅い層の需要は減り、設計と判断を担う層に偏る。", "remains": "設計・開発では目的と制約の設定、出来の確認、例外の発見が残り、顧客との相談では合意形成が、修正では本番への影響を見た採否の承認が残る。理由は、相手が人の説明と責任を求めることと、本番環境や秘匿コードに関する契約上の制約。大規模コードで設計の一貫性を保てるモデルと、観測データに直接触れる権限がそろえばこれらも縮む。", "who": "総人数は大きく変わらないが、実装を主に担う経験の浅い開発者の枠は減り、一人が複数のエージェントの成果を確認し、設計と採否を判断する構成になる。チームは小さくなり、経験者の比率が上がる。経験の浅い層は、エージェントの出力の確認と検証を通じて育つ経路に移る。", "skills": "エージェントに作業を任せるための課題の切り分けと指示の書き方、生成されたコードを短時間で読み、設計の整合や抜けを見つける力、検証基準を要件から導く力、本番環境と事業への影響を判断する力、顧客や他部署と合意を作る力。"}

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": 8,
      "now": 55,
      "year1": 68,
      "year5": 85,
      "human_layers": [
        "品質の確認",
        "例外の発見",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "データ処理と集計はAIに移り、人は要件に合う測定かを確かめるが、意味と収集条件を検証できれば確認も減る。欠測や偏った利用履歴があれば、動く処理でも人が設計し直す。",
      "confidence": "中"
    },
    {
      "no": 2,
      "weight": 12,
      "now": 25,
      "year1": 38,
      "year5": 58,
      "human_layers": [
        "作業",
        "品質の確認",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術",
        "相手の受け入れ"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "要件整理と実現案はAIが助け、人は利用者の目的と制約を聞くが、実際の利用で検証できれば検討も減る。曖昧な要望や組織の利害が残れば、仕様の作成から人が調整する。",
      "confidence": "低"
    },
    {
      "no": 3,
      "weight": 10,
      "now": 30,
      "year1": 42,
      "year5": 65,
      "human_layers": [
        "品質の確認",
        "実行の承認",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術",
        "相手の受け入れ"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "導入と変更の計画案はAIが作り、人は依存関係と移行条件を確認するが、実環境を再現できれば計画確認も縮む。旧システムの暗黙の仕様があれば、標準的な変更にも人の調査が残る。",
      "confidence": "中"
    },
    {
      "no": 4,
      "weight": 5,
      "now": 60,
      "year1": 72,
      "year5": 90,
      "human_layers": [
        "品質の確認",
        "実行の承認"
      ],
      "blockers": [
        "技術",
        "相手の受け入れ"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "仕様と進捗の報告はAIに移り、人は実態と相手への説明を確かめるが、成果物と状態を照合できれば編集も減る。未完了を完了と扱ったり重要な課題を落としたりすれば、文案も人が修正する。",
      "confidence": "中"
    },
    {
      "no": 5,
      "weight": 15,
      "now": 45,
      "year1": 58,
      "year5": 80,
      "human_layers": [
        "品質の確認",
        "例外の発見",
        "実行の承認"
      ],
      "blockers": [
        "技術"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "修正案と再現テストはAIが進め、人は原因と影響を確かめるが、利用条件を十分に検証できれば確認も減る。局所的な修正が別の機能を壊す場合は、原因調査から人が関わる。",
      "confidence": "中"
    },
    {
      "no": 6,
      "weight": 10,
      "now": 20,
      "year1": 30,
      "year5": 48,
      "human_layers": [
        "作業",
        "実行の承認",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術",
        "相手の受け入れ"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "論点整理と説明案はAIが助け、人は費用、納期、品質の合意を作るが、制約を共有して選べれば協議も減る。部門ごとの目的が違う場合は、定例の報告にも人の調整が必要になる。",
      "confidence": "低"
    },
    {
      "no": 7,
      "weight": 20,
      "now": 40,
      "year1": 52,
      "year5": 75,
      "human_layers": [
        "品質の確認",
        "実行の承認",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "設計案と実装はAIに移り、人は構成と保守性を判断するが、性能や安全性を検証できれば設計確認も縮む。要件の抜けや長期の運用負担を捉えられなければ、実装の前提から人が見直す。",
      "confidence": "中"
    },
    {
      "no": 8,
      "weight": 15,
      "now": 45,
      "year1": 58,
      "year5": 80,
      "human_layers": [
        "品質の確認",
        "例外の発見",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "テスト実行と文書化はAIに移り、人は検証の不足を調べるが、未知の利用条件まで評価できれば確認も減る。実装と同じ誤解をテストが引き継げば、合格していても人が検証方法を作り直す。",
      "confidence": "中"
    },
    {
      "no": 9,
      "weight": 5,
      "now": 20,
      "year1": 32,
      "year5": 50,
      "human_layers": [
        "作業",
        "品質の確認",
        "例外の発見",
        "目的と制約の設定"
      ],
      "blockers": [
        "技術",
        "相手の受け入れ"
      ],
      "enablers": [
        "技術",
        "費用"
      ],
      "outlook": "進捗把握とレビュー案はAIが助け、人は担当の負担と品質を確認するが、実際の成果を評価できれば管理も減る。見かけの進捗や難しい課題の滞留を捉えられなければ、日常の監督にも人が関わる。",
      "confidence": "低"
    }
  ],
  "share_now": 38,
  "share_year1": 50,
  "share_year5": 71,
  "reason": "現在はコードの読解、定型実装、修正案、テストと文書化で作業時間が減る。1年では変更と検証がつながり、5年では条件の明確な機能をまとめて開発しやすくなる。人には要件の具体化、構成の判断、検証方法の点検、関係者との合意が残る。生成したコード量やテストの合格数では時間削減を測らず、レビュー、統合後の不具合、利用環境での評価に使う時間を含めて見積もる。",
  "demand": "増える",
  "demand_reason": "開発費が下がり、小規模な業務や個別の用途でもソフトウェアを作りやすくなる。既存システムの変更と保守も増えるとみるが、利用者の課題や運用能力が制約になる。作る機能の増加が開発者の人数へ同じ割合でつながるとは限らない。",
  "remains": "曖昧な要求を具体化し、設計で何を優先するかを決める仕事が残る。人は既存環境との整合、性能、安全性、運用の負担を確かめ、テストそのものの不足を見つける。顧客と費用や納期を調整し、障害時に復旧の順番を選ぶ役割も続く。利用条件を再現して独立に検証でき、変更を確実に戻せるなら、レビューや承認に使う時間もさらに減る。",
  "who": "開発需要が増えるため、職種全体の人数が減るとは限らないが、指示された実装だけを担う役割は縮む。一人が要件から運用まで扱う範囲が広がり、設計、検証、障害対応に強い人の比重が上がる。若手は生成コードを受け取るだけでなく、不具合を再現し、既存コードとの関係を調べて直す経験が必要になる。変更の量が増えるほど、確認に使う時間の配分が重要になる。",
  "skills": "要件を検証可能な形にし、期待する動作と壊してはいけない条件を明確にする力が要る。AIの変更では依存関係と設計上の選択を理解し、テストの合格だけでなく実際の利用で品質を確かめる。障害を再現して原因を絞り、修正の影響を検証する力も重要になる。後から変更できる構造と記録を整え、費用、品質、納期の選択を関係者へ説明することが求められる。"
}