AIでプログラマーはなくなる？生成AI時代の転職・90日対策

「AIに触れる仕事」と「仕事がなくなる予測」を分ける

ILOは、AI曝露指標を、職業内の作業をAIが代替・変換し得る程度を測る早期シグナルとして扱っています。一方で、曝露の高さだけから雇用減少、賃金、生産性、学び直しの必要量を予測できないとも説明しています。指標は技術的な可能性を示しますが、採用停止や解雇の確率ではありません。

2025年のILO・NASK共同研究でも、多くの職業は作業の一部に人の入力が残るため、全面的な置換より仕事の変化が起こりやすいと整理されています。ソフトウェア開発のようなデジタル化された専門職も影響範囲に入りますが、「エンジニア全員が同じ時期に不要になる」という結論ではありません。

自分の将来を考える時は、職種別の刺激的な確率ではなく、所属企業で実際に起きた変化を記録します。採用人数、案件の工程、レビュー人数、納期、単価、担当範囲のどれが変わったか。噂と求人見出しではなく、現在の業務と転職市場の事実を三か月ごとに確認します。

• AI曝露: 技術的に作業が変わり得る度合い
• 雇用予測: 需要・費用・制度・導入速度まで必要
• 社内の事実: 人数・工程・品質責任・納期の変化
• 市場の事実: 求人で求める工程と入社後の責任

仕事を「作成・検証・意思決定」の三層へ分ける

一日の仕事を職種名ではなく作業単位で書き出します。第一層は作成です。コードのたたき台、SQL、テストデータ、説明文、会議要約、調査候補の列挙などが入ります。入力形式と完成形が明確で、失敗しても本番へ直結しない小さな作業ほどAIを試しやすくなります。

第二層は検証です。既存仕様との一致、境界値、権限、性能、ログ、依存関係、セキュリティ、ライセンス、顧客固有ルールを確認します。AIが下書きを作れても、何を根拠に正しいと判断するかは別の仕事です。テスト実施だけでなく、確認観点を選び、失敗時の影響範囲を絞る経験を残します。

第三層は意思決定と責任です。要件の優先順位、設計案の採否、個人情報を含むデータの利用、本番反映、障害時の切り戻し、顧客への説明を誰が承認するかを確認します。「人にしかできない」と思い込まず、現在の契約と組織で誰が結果へ責任を持つかを成果物ごとに書きます。

• 作成: 下書き・分類・候補生成・変換
• 検証: 仕様・テスト・品質・安全性との照合
• 意思決定: 優先順位・採否・本番・説明責任
• 棚卸し: 各層の時間と自分が単独で持つ範囲

減りやすい作業を、作業名ではなく四条件で見つける

変わりやすいのは「コーディング」「テスト」のような工程名そのものではありません。入力がそろっている、出力形式が固定されている、正しさを機械的に照合できる、失敗時の影響を限定できる、という四条件がそろう作業です。同じ実装でも、仕様どおりの変換と、複数部署の制約から仕様を決める仕事では条件が違います。

SESの現場なら、定型帳票の修正、既知パターンのテストケース下書き、ログの一次分類、既存コードの説明、手順書の形式統一から変わる可能性があります。ただし、顧客情報を外部へ送れない、検証環境がない、誤りの責任が大きい案件では、技術的に可能でも利用できません。

「今の作業が減る」ことを、自分の価値がゼロになることと結びつけないでください。減った時間をどの上流工程へ移せるかを決めます。仕様差分の確認、テスト観点の設計、レビュー、運用データの分析、利用部門への確認など、現在の案件で隣接する責任を一つ引き取ります。

• 入力データと指示がそろっている
• 期待する出力形式が固定されている
• 正しさを自動または短時間で照合できる
• 誤りの影響を検証環境内へ限定できる
• 空いた時間を移す次の責任が決まっている

AI利用実績は、速さより入力・検証・運用を残す

職務経歴書へ「ChatGPT、Copilotを活用」と書くだけでは、採用側は任せられる範囲を判断できません。対象業務、利用前の問題、AIへ渡した入力、人が確認した項目、採用しない条件、導入後の変化を一続きで書きます。ツール名が変わっても再現できる設計を主語にします。

最初の実績は、失敗しても顧客や本番へ影響しない一作業で作ります。たとえばテスト観点の下書きなら、既存仕様から候補を生成し、担当者が境界値・権限・異常系を追加し、採用した観点と見送った理由を残します。生成物をそのまま成果物にせず、根拠資料へ戻れる状態にします。

時間短縮を成果にする場合は、対象件数、測定期間、比較条件を残します。測っていない削減率は作りません。数字が取れなければ、確認項目の統一、参照元リンクの付与、レビュー前の不足検出、引き継ぎ可能なテンプレートなど、観察できる変化を記録します。

• 対象: 誰のどの作業を変えたか
• 入力: 何を渡し、何を渡さなかったか
• 検証: 仕様・テスト・原文のどれと照合したか
• 境界: 使わない条件と最終承認者
• 変化: 測れた時間・品質・再現性

機密・個人情報・誤出力を「自己責任」で処理しない

経済産業省のAI事業者ガイドライン第1.2版は、AIを提供・利用する主体がリスクに応じて取り組むための考え方とチェック項目を示しています。個人で便利だから使うことと、会社の顧客データ、ソースコード、障害情報を外部サービスへ入力してよいことは別です。所属会社と客先の規程、契約、利用環境を優先します。

利用前に、入力データの機密区分、保存・学習利用の扱い、アクセス権、出力の利用目的、ログの保存、問題時の連絡先を確認します。「固有名詞を消したから安全」と決めず、コードやデータの組合せから対象を推測できないかも見ます。許可された社内環境がない場合は、公開情報か自作データで検証します。

安全性を確認した経験もエンジニアの実績です。利用可否を一人で決めず、情報システム、セキュリティ、法務、案件責任者と確認した項目をテンプレート化します。使わない判断、対象を限定した判断、出力を破棄した判断を含めて、リスクと便益を説明できる状態にします。

• 会社・客先が許可した環境か
• 入力データの機密区分と契約上の制約
• 保存・学習利用・アクセス権・削除方法
• 誤出力時の影響範囲と停止手順
• 利用可否の承認者と記録

学ぶ技術はツール名でなく、次に持つ責任から選ぶ

IPAのデジタルスキル標準ver.2.0は、ソフトウェアエンジニアだけでなく、ビジネスアーキテクト、データサイエンティスト、データマネジメント、サイバーセキュリティなど複数の役割を示し、AI実装・運用に関するスキルも追加しています。全分野を同時に学ぶ必要はありません。現在の仕事で次に持てる責任を一つ選びます。

実装中心なら、要件から受入条件を作る、AI機能の評価データを整える、出力品質を監視する、障害時に切り戻すなど隣の責任を選べます。テスト中心なら、観点設計とリスクベースの優先順位。運用中心なら、ログ設計、変更管理、インシデント後の再発防止。PMOなら、意思決定と依存関係を成果物へ残す仕事です。

講座や資格を選ぶ前に、求人10件で共通して求められる成果物を確認します。学習だけで終わらず、公開可能な自作データで小さな検証を作るか、現職で許可された範囲の改善を担当します。「学んだ技術」ではなく、「誰の判断を何で支えたか」を面接で説明できる状態を完成条件にします。

• 要件・受入条件・評価指標を作る
• データ品質・権限・利用ルールを整える
• AI出力の評価・監視・停止を設計する
• セキュリティと障害時の責任分界を決める
• 利用後の業務変化を測る

90日で「現職に残る・役割を変える・転職する」を判定する

最初の30日で、一週間の作業を作成・検証・意思決定へ分け、時間と担当範囲を記録します。AIで減りそうな作業だけでなく、現在自分が持つ検証と責任を職務経歴書へ書きます。許可された範囲で、小さな一作業について入力・検証・利用しない条件を設計します。

31〜60日で、上司や案件責任者へ、空いた時間で引き取りたい責任を一つ相談します。同時に狙う求人10件を見て、入社後90日に任される工程、AI利用環境、レビュー体制、データ・セキュリティ責任、評価条件を確認します。会社名や「AI積極活用」だけでなく、成果物と承認範囲で比べます。

61〜90日で三つの選択肢を同じ表にします。現職で責任を増やせる時期、案件変更で増える工程、転職先で任される仕事、年収内訳、失う条件です。不安だけで応募を急がず、現職に残る期限も曖昧にしません。転職支援を使う場合は同じ経歴と質問を二社へ渡し、対象条件と求人の選定理由を比較してください。

• 0〜30日: 作業三層と現在の証拠を棚卸し
• 31〜60日: 小さなAI改善と隣の責任を担当
• 31〜60日: 求人10件を成果物・承認・評価で比較
• 61〜90日: 現職・案件変更・転職を同じ条件で判定
• 相談先: 年齢・経験・勤務地の対象条件を先に照合

職務経歴書の変換例

ツール名や速さではなく、対象、入力制限、検証、採用判断、再利用できる手順まで書きます。

行動前チェックリスト

• AI曝露の数字を失業確率として扱っていない
• 一週間の仕事を作成・検証・意思決定へ分けた
• 変わりやすい作業を四条件で確認した
• 会社・客先が許可したデータと環境だけを使った
• 出力の照合先、利用しない条件、承認者を決めた
• 測定できない時短や品質効果を作っていない
• 現在の仕事で次に増やす責任を一つ決めた
• 現職・案件変更・転職を同じ90日表で比べた