AIモデルの見立て
コンサルティングへの質問と回答
質問文は運営者が固定し、全モデルに同じ文面を使った。回答は受け取ったとおりで、サイトは書き換えていない。取得の条件は各回答の前に記す。
質問文(版 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 13-1111)
この職種の業務(米国 O*NET の業務記述の日本語訳):
1. 問題や手順についての情報を集めて整理する
2. 調査結果を文書にまとめ、新しい制度・手順・組織変更の導入を提言する
3. 集めたデータを分析し、解決策や代わりの進め方を立てる
4. 新しく導入した制度や手順が機能するよう、関係者と協議する
5. 記録の保管・保護・検索のための文書管理の制度を作り、運用し、順守を確かめる
この職種で使われているAIツール(各社の公式ページの説明。判断材料の一部):
- AlphaSense(AlphaSense): 決算資料や調査資料、社内の資料を横断して検索し、調査のエージェントが報告や説明資料を作る。
問い
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
| 業務 | 比重 | 今 | 1年以内 | 5年以内 | 5年後も人に残る層 | 人に残る理由 | AIに移る理由 | 確信 | 要点と崩れる条件 |
|---|---|---|---|---|---|---|---|---|---|
| 問題や手順についての情報を集めて整理する | 25% | 50% | 60% | 75% | 品質の確認、例外の発見 | 技術、相手の受け入れ | 技術、費用、相手の受け入れ | 高 | 公開資料や社内資料の検索・要約・整理は調査エージェントが担い、人は抜けや古い情報の確認と、現場で聞かないと分からない事情の発見に時間を使う。顧客の非公開データや担当者への聞き取りまでAIが直接行えるようになれば残りも移り、機密資料をAIに渡せない契約が増えれば整理も人に戻る。 |
| 調査結果を文書にまとめ、新しい制度・手順・組織変更の導入を提言する | 25% | 35% | 45% | 60% | 品質の確認、実行の承認、目的と制約の設定 | 技術、制度・契約、相手の受け入れ | 技術、費用 | 中 | 下書きや図表の作成はAIが担うが、提言の核心と採否の判断、顧客の事情に合わせた修正は人に残る。顧客がAIの提言をそのまま受け入れる慣行が広がれば残りも移り、AIが作った資料の責任の所在を契約で人に求める動きが強まれば下書きも人の手に戻る。 |
| 集めたデータを分析し、解決策や代わりの進め方を立てる | 25% | 35% | 45% | 60% | 品質の確認、例外の発見、目的と制約の設定 | 技術、相手の受け入れ | 技術、費用、制度・契約 | 中 | 定型の集計や複数案の比較はAIが担い、人は前提の妥当性の確認と、数字に出ない事情の発見、何を解くかの設定に時間を使う。顧客の内部データに直接つながる分析環境が普及すれば残りも移り、データの持ち出し制限で分析をAI環境で行えない顧客が多ければ人に戻る。 |
| 新しく導入した制度や手順が機能するよう、関係者と協議する | 15% | 10% | 15% | 25% | 作業、例外の発見、実行の承認 | 相手の受け入れ、技術 | 技術、費用 | 高 | 議事の準備や記録はAIが担うが、利害の調整と合意づくりは人が顔を合わせて行う部分が大きい。関係者がAIとの対話で合意形成を済ませる慣行が広がれば移り、対面での説明を顧客が条件として求め続ければAIが準備する時間も減らない。 |
| 記録の保管・保護・検索のための文書管理の制度を作り、運用し、順守を確かめる | 10% | 32% | 40% | 62% | 品質の確認、実行の承認、目的と制約の設定 | 制度・契約、技術 | 技術、費用、制度・契約 | 中 | 分類ルールの設計案や順守状況の点検はAIが担い、人は制度の設定と例外の承認に時間を使う。文書管理システムにAIが組み込まれ監査にも通る実績が積まれれば残りも移り、法規制や監査が人による点検の記録を求め続ければ点検も人に残る。 |
{"tasks": [{"no": 1, "weight": 25, "now": 50, "year1": 60, "year5": 75, "human_layers": ["品質の確認", "例外の発見"], "blockers": ["技術", "相手の受け入れ"], "enablers": ["技術", "費用", "相手の受け入れ"], "outlook": "公開資料や社内資料の検索・要約・整理は調査エージェントが担い、人は抜けや古い情報の確認と、現場で聞かないと分からない事情の発見に時間を使う。顧客の非公開データや担当者への聞き取りまでAIが直接行えるようになれば残りも移り、機密資料をAIに渡せない契約が増えれば整理も人に戻る。", "confidence": "高"}, {"no": 2, "weight": 25, "now": 35, "year1": 45, "year5": 60, "human_layers": ["品質の確認", "実行の承認", "目的と制約の設定"], "blockers": ["技術", "制度・契約", "相手の受け入れ"], "enablers": ["技術", "費用"], "outlook": "下書きや図表の作成はAIが担うが、提言の核心と採否の判断、顧客の事情に合わせた修正は人に残る。顧客がAIの提言をそのまま受け入れる慣行が広がれば残りも移り、AIが作った資料の責任の所在を契約で人に求める動きが強まれば下書きも人の手に戻る。", "confidence": "中"}, {"no": 3, "weight": 25, "now": 35, "year1": 45, "year5": 60, "human_layers": ["品質の確認", "例外の発見", "目的と制約の設定"], "blockers": ["技術", "相手の受け入れ"], "enablers": ["技術", "費用", "制度・契約"], "outlook": "定型の集計や複数案の比較はAIが担い、人は前提の妥当性の確認と、数字に出ない事情の発見、何を解くかの設定に時間を使う。顧客の内部データに直接つながる分析環境が普及すれば残りも移り、データの持ち出し制限で分析をAI環境で行えない顧客が多ければ人に戻る。", "confidence": "中"}, {"no": 4, "weight": 15, "now": 10, "year1": 15, "year5": 25, "human_layers": ["作業", "例外の発見", "実行の承認"], "blockers": ["相手の受け入れ", "技術"], "enablers": ["技術", "費用"], "outlook": "議事の準備や記録はAIが担うが、利害の調整と合意づくりは人が顔を合わせて行う部分が大きい。関係者がAIとの対話で合意形成を済ませる慣行が広がれば移り、対面での説明を顧客が条件として求め続ければAIが準備する時間も減らない。", "confidence": "高"}, {"no": 5, "weight": 10, "now": 32, "year1": 40, "year5": 62, "human_layers": ["品質の確認", "実行の承認", "目的と制約の設定"], "blockers": ["制度・契約", "技術"], "enablers": ["技術", "費用", "制度・契約"], "outlook": "分類ルールの設計案や順守状況の点検はAIが担い、人は制度の設定と例外の承認に時間を使う。文書管理システムにAIが組み込まれ監査にも通る実績が積まれれば残りも移り、法規制や監査が人による点検の記録を求め続ければ点検も人に残る。", "confidence": "中"}], "share_now": 35, "share_year1": 44, "share_year5": 59, "reason": "情報収集では作業と初回の整理がAlphaSenseのような調査エージェントや汎用の対話型AIに移る。報告書作成では下書き・図表・体裁の作業が文書生成ツールに、データ分析では集計・可視化・定型モデルの作業がコード生成やノートブック内のAIに移る。文書管理では分類と順守点検の作業が文書管理システム内のAIに移る。関係者との協議は準備と記録だけが移る。", "demand": "ほぼ同じ", "demand_reason": "作業の自動化で一案件あたりの単価は下がるが、AI導入そのものの相談や、組織変更の設計・定着支援の需要が増えて相殺する。顧客が社内でAIを使い自力で分析する範囲が広がれば減る側に振れる。", "remains": "提言の核心と採否の判断、分析の前提の確認、現場でしか分からない事情の発見、関係者との利害調整が残る。理由は、顧客が人の説明と責任の所在を求めることと、非公開情報へAIが直接届かないこと。顧客がAIの提言を直接受け入れ、内部データにAIがつながる契約が普通になれば、この残りも薄くなる。", "who": "仕事の量はほぼ同じで人の時間が約6割減るため、一案件の人数は減り、資料づくりを担っていた若手の比率が下がる。残るのは顧客との関係と判断を担う経験者と、AIの出力を検証できる分析者。若手の育成経路が細るため、小規模チームで早くから顧客対応に出る構成に変わる。", "skills": "AIの調査や分析の結果の前提と抜けを見抜く検証力、問いの設定と制約の明確化、顧客の意思決定者と向き合い合意をつくる対話力、AIの出力を顧客の文脈に合わせて組み替える編集力、データの扱いに関する契約や法規制の知識。"}
GPT-6 Astra
| 業務 | 比重 | 今 | 1年以内 | 5年以内 | 5年後も人に残る層 | 人に残る理由 | AIに移る理由 | 確信 | 要点と崩れる条件 |
|---|---|---|---|---|---|---|---|---|---|
| 問題や手順についての情報を集めて整理する | 25% | 45% | 58% | 75% | 作業、品質の確認、目的と制約の設定 | 技術、相手の受け入れ | 技術、費用 | 中 | 資料の収集と整理はAIに移り、人は問いと現場への聞き取りを担うが、業務の実態を記録から確かめられれば調査も減る。非公式な手順や説明の食い違いがあれば、資料の選別から人が入り直す。 |
| 調査結果を文書にまとめ、新しい制度・手順・組織変更の導入を提言する | 20% | 50% | 62% | 80% | 品質の確認、実行の承認、目的と制約の設定 | 技術、相手の受け入れ | 技術、費用 | 中 | 報告書と提言案はAIが作り、人は実行条件と伝え方を選ぶが、関係者の制約を評価できれば案の選定も減る。見栄えのよい提案が現場で動かない場合は、文章化に回した部分も人が組み直す。 |
| 集めたデータを分析し、解決策や代わりの進め方を立てる | 25% | 40% | 52% | 70% | 品質の確認、例外の発見、目的と制約の設定 | 技術 | 技術、費用 | 中 | 分析と代替案の比較はAIに移り、人は前提と因果を点検するが、介入の効果を検証できれば判断も縮む。欠測や現場の行動変化で前提が崩れれば、自動分析も人が設計し直す。 |
| 新しく導入した制度や手順が機能するよう、関係者と協議する | 20% | 15% | 25% | 42% | 作業、例外の発見、実行の承認、目的と制約の設定 | 技術、相手の受け入れ | 技術、費用 | 低 | 論点整理と進捗確認はAIが助け、人は利害を調整するが、関係者が自動提案を受け入れ実行できれば協議も減る。反発や隠れた負担を把握できなければ、定例の確認にも人の対話が必要になる。 |
| 記録の保管・保護・検索のための文書管理の制度を作り、運用し、順守を確かめる | 10% | 35% | 48% | 70% | 品質の確認、実行の承認、目的と制約の設定 | 技術、制度・契約 | 技術、費用 | 中 | 文書の分類と遵守点検はAIに移り、人は保存規則と権限を決めるが、誤分類や漏えいを検証できれば確認も減る。規則と実際の業務が合わなければ、日常の記録管理にも人が例外対応をする。 |
{
"tasks": [
{
"no": 1,
"weight": 25,
"now": 45,
"year1": 58,
"year5": 75,
"human_layers": [
"作業",
"品質の確認",
"目的と制約の設定"
],
"blockers": [
"技術",
"相手の受け入れ"
],
"enablers": [
"技術",
"費用"
],
"outlook": "資料の収集と整理はAIに移り、人は問いと現場への聞き取りを担うが、業務の実態を記録から確かめられれば調査も減る。非公式な手順や説明の食い違いがあれば、資料の選別から人が入り直す。",
"confidence": "中"
},
{
"no": 2,
"weight": 20,
"now": 50,
"year1": 62,
"year5": 80,
"human_layers": [
"品質の確認",
"実行の承認",
"目的と制約の設定"
],
"blockers": [
"技術",
"相手の受け入れ"
],
"enablers": [
"技術",
"費用"
],
"outlook": "報告書と提言案はAIが作り、人は実行条件と伝え方を選ぶが、関係者の制約を評価できれば案の選定も減る。見栄えのよい提案が現場で動かない場合は、文章化に回した部分も人が組み直す。",
"confidence": "中"
},
{
"no": 3,
"weight": 25,
"now": 40,
"year1": 52,
"year5": 70,
"human_layers": [
"品質の確認",
"例外の発見",
"目的と制約の設定"
],
"blockers": [
"技術"
],
"enablers": [
"技術",
"費用"
],
"outlook": "分析と代替案の比較はAIに移り、人は前提と因果を点検するが、介入の効果を検証できれば判断も縮む。欠測や現場の行動変化で前提が崩れれば、自動分析も人が設計し直す。",
"confidence": "中"
},
{
"no": 4,
"weight": 20,
"now": 15,
"year1": 25,
"year5": 42,
"human_layers": [
"作業",
"例外の発見",
"実行の承認",
"目的と制約の設定"
],
"blockers": [
"技術",
"相手の受け入れ"
],
"enablers": [
"技術",
"費用"
],
"outlook": "論点整理と進捗確認はAIが助け、人は利害を調整するが、関係者が自動提案を受け入れ実行できれば協議も減る。反発や隠れた負担を把握できなければ、定例の確認にも人の対話が必要になる。",
"confidence": "低"
},
{
"no": 5,
"weight": 10,
"now": 35,
"year1": 48,
"year5": 70,
"human_layers": [
"品質の確認",
"実行の承認",
"目的と制約の設定"
],
"blockers": [
"技術",
"制度・契約"
],
"enablers": [
"技術",
"費用"
],
"outlook": "文書の分類と遵守点検はAIに移り、人は保存規則と権限を決めるが、誤分類や漏えいを検証できれば確認も減る。規則と実際の業務が合わなければ、日常の記録管理にも人が例外対応をする。",
"confidence": "中"
}
],
"share_now": 38,
"share_year1": 50,
"share_year5": 68,
"reason": "現在は資料検索、要約、分析の下準備、報告書の下書きで作業が短くなる。1年では社内資料との連携が進み、5年では複数の施策の比較と導入後の点検まで広がる。調査エージェントが資料をまとめても、問題の設定や現場の実態の確認は残る。人は分析の前提を検証し、組織変更の負担と利害を調整するため、提言書の作成時間だけで職種全体の削減率を決めない。",
"demand": "増える",
"demand_reason": "調査と分析の費用が下がり、小規模な改善や継続的な見直しを依頼しやすくなる。AIの導入に伴う業務や文書管理の再設計も増えるとみる。ただし顧客が自分で調べる範囲も広がり、資料作成だけへの外注需要は縮む。",
"remains": "何を問題とするかを決め、記録に表れない現場の事情を調べる仕事が残る。人は分析の品質を点検し、提案によって誰の負担が増えるかを確かめ、実行する組織の合意を作る。導入後に手順が守られない理由を調べ、必要なら提案を修正する役割も続く。業務の実態と利害を把握でき、関係者がAIの提案を直接使って実行できるなら、調査と調整の時間はさらに減る。",
"who": "改善の依頼が増えても、資料を集めて整える担当者は少人数で足りるようになり、一人が複数案件を扱う形が増える。顧客の現場に入り、実行を支えられる人や、分析の前提を検証できる人の比重が上がる。職種全体の人数は需要の伸び次第だが、若手の作業構成は変わる。資料作成だけでなく、聞き取り、仮説の検証、導入後の失敗を調べる経験を早く積む必要がある。",
"skills": "問いを検証可能な形にし、必要な資料と現場の情報を集める力が要る。AIの分析結果を受け取るだけでなく、欠測、比較条件、因果の取り違えを点検し、実行したときの影響を確かめる。関係者の負担と権限を整理し、合意できる手順へ落とす力も重要になる。導入後の指標と現場の声を合わせて、提案を続けるか修正するかを判断し、その理由を説明することが求められる。"
}