NID 管理職層向け生成AI基礎研修 NID 管理職層向け生成AI基礎研修本研修は、現場でツールを操作する研修ではありません。生成AIとAIエージェントが SI・受託開発・運用保守の事業にどう効いてくるかを把握し、管理職として投資・人材・評価の判断材料を持ち帰っていただくことを狙いとしています。録画とあわせて、本資料単体でも読み返せるよう構成しています。
研修当日にお預かりしたご質問と、事例に関するご指摘を受けて、内容を追加しました。追加した箇所には、本文中に 追加 の印と青い枠を付けています。当日ご説明した内容はそのまま残していますので、追加分だけを読み返す形でもお使いいただけます。
| 追加した箇所 | 内容 | 追加の理由 |
|---|---|---|
| BRIEFING 03.1 | 日本企業の現在地（PwC 6カ国比較調査） | 導入率ではなく、効果と財務貢献で差がついている状況を先にお示しするため |
| BRIEFING 03.3 | 貴社の事業構成に重ねた事例（システム開発／システムマネジメントの区分別） | 大手SIerの全社数値だけでは、自部門に引き寄せて読みにくいとのご指摘を受けたため |
| BRIEFING 03.4 | 削減した時間を何に使ったか（3社の事例） | 効率化の先にある時間の使い道について、当日ご質問をいただいたため |
| BRIEFING 03.5 | 収益モデルへの向き合い方（富士通の方針表明） | 工数削減が売上減につながる懸念について、業界の動きをお示しするため |
| BRIEFING 07 | 研修後にいただいたご質問への回答（Q1〜Q3） | 当日のチャットと質疑でお預かりした3件のご質問にお答えするため |
手を動かす演習はありません。考えながら聞いていただくスタイルです。到達状態は、自部門での生成AI活用の打ち手と判断の軸を言語化できることです。
| パート | 内容 | 配分 |
|---|---|---|
| 1 | イントロダクション（狙いと、持ち帰っていただきたい問いの共有） | [5min] |
| 2 | 生成AI及びエージェントの全体像と最新動向 | [20min] |
| 3 | 他社事例から考える生成AIによるインパクト | [15min] |
| 4 | ガバナンス・リスクとの向き合い方 | [15min] |
| 5 | AIエージェント時代の管理職に求められる役割・推進スタンス | [20min] |
| 6 | Q&A・クロージング | [15min] |
| 合計（[90min]・10:00〜11:30） | [90min] |
(1) 自部門でどこから始めるか、(2) 効果を何で測るか、(3) 人の役割をどう移していくか。この三つに自分の言葉で答えられる状態が、今日のゴールです。
本文中の数値や事例には出典リンクを付けています。社内で検討材料として共有される際は、リンク先の一次情報もあわせてご確認ください。数値は出典公表時点のものです。研修は [90min]（10:00〜11:30）を通しで実施し、最後にクロージングと質疑を [15min] 設けています。
似た言葉が飛び交う領域なので、管理職同士で話すときに齟齬が出ない程度に用語を整理します。細部の技術はエンジニアに任せて構いません。判断に効く違いだけを押さえてください。
大量の文章を学習し、続きや回答を確率的に生成する仕組み。ChatGPT や Claude の中核です。学習時点までの知識しか持ちません。
社内文書やマニュアルを検索し、その内容を根拠にLLMが回答する構成。学習に含まれない自社固有の情報を扱えます。
目標を渡すと、手順の分解・ツール実行・結果確認・やり直しまでをある程度自走する仕組み。回答だけでなく作業を進めます。
エージェントが社内システムやファイル、チケット管理などの外部ツールへ安全につながるための標準的な接続口です。
従来のチャット型生成AIは「聞いたら答える」までで、人が結果を見て次の指示を出す前提でした。AIエージェントは「やっておいて」に対して、複数の手順を自分で組み立てて実行まで進める点が大きく異なります。この違いが現場の働き方に直接効きます。管理職としては、自部門のどの作業が「任せられる作業」かを見極める視点が要るという観点があります。
注目していただきたいのは、導入したかどうかではなく、効果を実感できているかで差が開き始めているという点です。PwC の調査では、活用推進が一定水準に達した一方で効果が期待を下回る企業が増え、二極化が進んでいるという見方が示されています。先行して使いこなせる組織と、入れただけで止まる組織に分かれていくという観点があります。
「使えるツールを配ったか」ではなく「現場の業務プロセスに組み込めたか」で成果が決まる、という観点があります。配布の先にある運用設計こそ管理職の関与どころです。
研修当日にご説明した内容に、貴社の事業構成にあわせた事例と、削減した時間の使い道の事例を追加しました。数値は各社・各報道の公表時点のものです。
PwCが2026年6月10日に公表した6カ国比較調査の数値です。導入率では差がついていないのに、効果と財務貢献で大きく開いています。つまり分かれ目は、ツールを入れたかどうかではなく、業務のどこに組み込み、何の指標で測ったかにあるという見方ができます。
「他社はまだ使っていない」という前提は、すでに成り立ちません。一方で「使えば成果が出る」も成り立ちません。差がついているのは、その間にある業務プロセスへの組み込みだ、という観点があります。
| 企業 | 取り組み | 公表されている効果・目標 |
|---|---|---|
| NTTデータ | SIプロジェクトへの全工程展開。2025年度に約500プロジェクトへ適用 | 開発工程全体で20%の生産性向上を目標。2027年度は適用比率50%へ広げ40%（最大70%）を掲げる。AIと生産性向上へ2026年までに1000億円規模の投資を表明 |
| 日立製作所 | プログラミング・単体テスト工程での適用を本格化 | 2024年度の適用効果は50億円。2027年度に1000億円を目標 |
| 富士通 | 国内総プロジェクト約2万件への面的展開 | 約3割で活用済み、2025年度末に5〜6割へ拡大する計画 |
| SCSK | 提案・設計ドキュメント作成への適用 | 顧客向け提案作成の工数を約40%削減 |
4社に共通するのは、一部の先進案件で試すのではなく、適用比率や効果額を経営指標として置き、案件全体へ広げている点です。規模は異なっても、指標を先に決めてから広げるという順番は参考になるという観点があります。
貴社は、金融・保険、公共・社会インフラ、カーエレクトロニクス等を対象とするシステム開発事業と、運輸・通信、官公庁・団体、建築・製造等を対象とするシステムマネジメント事業を主たる事業とされていると公表されています。この2つの区分に沿って、関係の深い事例を整理しました。
| 事業・領域 | 関係する事例 | 効きどころ |
|---|---|---|
| システム開発 金融・保険 | 三菱UFJ銀行は、事務・営業への生成AI導入で労働時間の削減効果が月22万時間以上に相当するとの試算を公表（2023年11月、行員約4万人が対象、稟議書作成や社内文書のドラフトが中心） | 発注者側で「書く仕事」の削減が進むと、次に来るのは基幹側の刷新と連携の需要です。作る側にとっては、案件の性質が変わる論点になります |
| システム開発 公共・社会インフラ | 老朽化してブラックボックス化した現行システムの解析に生成AIを充てる動きが指摘されています | 長期保守案件での仕様掘り起こしは、属人化の解消と直結します |
| システム開発 カーエレクトロニクス | SDV（ソフトウェア定義車両）に向けたオープンソース基盤の整備が進み、ハードウェアに依存しない開発環境で車両開発期間の短縮が図られています | 車載領域はソフトの比重が上がる方向です。AIで単価が下がる話と、ソフト需要が増える話は同時に起きます |
| システムマネジメント 運用保守・MSP | KDDIアイレットのMSPは、24時間365日のクラウド監視において、セキュリティ通報対応の自動化から着手。「人がシステムを管理する」状態から「システムがシステムを管理し、本当に必要な時だけ人が介入する」状態への転換を掲げています | 運用の能動化は、人月を積む運用から、仕組みで支える運用への転換に直結します |
KDDIアイレットの取り組みで参考になるのは、進め方です。自然言語でAIに指示して作らせる方式から、要件定義と設計を先にドキュメント化してからAIに実装させる方式（スペック駆動開発）へ切り替えています。仕様が文書として残り、モジュール単位で分担でき、テスト基準が明確になるため、属人化を避けられるという整理です。運用方針としては「8割の定型作業を自動化し、2割の例外処理に人を割り当てる」という考え方を示しています。
研修当日にご質問をいただいた論点です。効率化そのものより、空いた時間の行き先を先に決めているかどうかで、成果の見え方が変わります。時間は放っておくと目減りし、「忙しさが少し減った」で終わることがあります。
KDDIアイレットは、MSPメンバーの位置づけを「オペレーターから、新しい価値を創出するエンジニアへ」と定義し直しました。監視・一次対応に充てていた時間を、自動化の仕組みを自分たちで設計・実装する側へ移しています。運用担当が要件整理から実装・テストまでを経験する体制です。
フォーティエンスコンサルティング（NTTデータグループ）は、過去の優れた提案書・商談記録・成約事例をAIに学習させ、営業活動の各プロセスで活用しています。創出した時間を件数の増加だけでなく提案の質の向上にも充て、年間約3.5億円規模の経済効果を公表しています。
パナソニックコネクトは全社員約1.2万人に社内向けAIを展開し、1年間で18.6万時間の労働時間削減を公表しています。1日あたりの利用回数は想定の5倍にあたる約5,800回に達したとされ、日常業務への定着が数値で確認できる例です。
削減した時間を「顧客との対話」「新規提案」「スキルアップ」のどれに充てるかを、あらかじめルールとして設計しておくことが要るという指摘があります。逆に、使い道を決めないまま効率化だけを進めると、投資対効果が説明できなくなるおそれがあります。何の時間を、どこへ移すのか。ここを決めるのが管理職の関与どころだと考えます。
工数が減ることが、そのまま売上の減少につながるのではないか。研修当日にいただいたご質問と同じ論点が、業界全体でも議論されています。
2026年5月に公表された「中長期経営ビジョン2035」において、時田隆仁社長は「人月をベースにした対価のいただき方では、これ以上の成長は見込めない」と述べたと報じられています。工数を売る形から、提供した価値で対価を得る形へ、大手が公に舵を切り始めている状況です。
生成AI時代の受託事業が取りうる形として、高速受託型、アセット提供型、運用伴走型、内製化支援型、業務代行高度化型という5つの類型に整理する見方が示されています。いずれも、投入人数ではなく提供した成果で対価を得る方向に共通点があります。詳細な考え方は、本資料末尾の「ご質問への回答」で扱います。
使わないことのリスクと、使うことのリスクの両方があります。管理職に必要なのは、リスクをゼロにすることではなく、許容できる範囲を決めて現場が安心して使える線引きを与えることだ、という観点があります。
| 論点 | 何が起きうるか | 管理職の打ち手 |
|---|---|---|
| 情報漏えい | 顧客情報やソースコードを外部サービスへ入力し、学習や第三者閲覧のリスクが生じる | 業務利用してよいサービスと、入力してよい情報の分類を社内ルールで明示する |
| 出力品質・誤り | もっともらしいが誤った回答やコードを、無検証で成果物に取り込む | レビューを通す工程を残し、最終責任は人にあることを運用に組み込む |
| 著作権・ライセンス | 生成物が他者の権利を侵害する、またはライセンス条件に抵触する | 納品物への利用範囲を契約・社内基準で確認する流れを設ける |
| 過度な依存 | 若手が考える前にAIへ丸投げし、判断力が育たない | AIに任せる作業と、人が考える作業を意図的に分ける運用にする |
受託・SI事業では、預かった顧客の情報やコードをどこまでAIに入力してよいかが、自社判断だけで決められない場合があります。契約や顧客の社内規定で生成AI利用の可否が定められていることがあるため、案件ごとに確認する流れを持っておくことが安全だ、という観点があります。MSPの運用保守でも、監視ログや構成情報の取り扱いは同様に注意が要ります。
一律禁止は現場の工夫を止め、隠れて使う温床にもなりかねません。使ってよい範囲を具体的に示すほうが、結果として統制が効くという観点があります。何を入れてよいかの判断基準を現場に渡すことが管理職の仕事だと考えます。
ここが本研修の中心です。投資判断・人材アサイン・部下との向き合い方の三つに分けて、明日から考える材料を整理します。いずれも正解を配るのではなく、判断の軸を持ち帰っていただく趣旨です。
ツールのライセンス費用だけを見て高い安いを判断すると、本質を外すという観点があります。効果が出るかどうかは、現場の業務にどれだけ組み込めたかで決まるため、導入後の運用設計・教育・ルール整備までを投資の対象として見るのが妥当だと考えます。
一事業・一工程に絞って試し、提案工数や開発工数といった測れる指標で効果を見るところから始める進め方があります。
SCSKの提案工数約40%削減や日立の工程効果のように、自社でも測れる指標を先に決めておくと投資の継続判断がぶれません。
ライセンス費に加え、教育・ルール整備・レビュー工程の負荷も含めて投資対効果を見る観点があります。
エージェントが定型的な実装やテストを巻き取っていくと、人に求められる比重は、要件を言葉にする力・AIの出力を評価する力・顧客と握る力へ移っていくという観点があります。アサインの設計も、稼働時間を埋める発想から、付加価値の高い工程に人を寄せる発想へ変えていく余地があります。
各事業に旗振り役を置き、現場の試行と横展開をつなぐ役割を担わせる進め方があります。
AIに作らせて終わりではなく、出力の良し悪しを判断できる人を増やすことが、品質を守る鍵になるという観点があります。
運用保守ではSREのように、人がAIと協調する体制を設計する役割が重みを増していくという観点があります。
現場には、仕事がなくなるのではという不安と、使ってみたいという期待が同居しています。管理職が示すべきは、AIで人を減らすのではなく、AIに任せた分だけ付加価値の高い仕事へ移ってもらうという方針だ、という観点があります。評価のものさしも、こなした作業量から、AIをどう使い成果と品質をどう高めたかへ寄せていく余地があります。
自部門の業務のうち、提案・設計・テスト・運用報告など、AIで工数を測れそうな箇所を一つ選び、小さく試す。その結果を見て投資と人の配置を決める。この順番が現実的だと考えます。
本研修で持ち帰っていただきたいのは、三つの問いです。自部門でどこから始めるか、効果を何で測るか、人の役割をどう移していくか。この三つに自分の言葉で答えられる状態が、今日のゴールです。
エージェントは「答える」から「作業を進める」へ。効果は導入の有無ではなく業務への組込みで決まるという観点があります。
国内大手はSI・受託・運用の全工程へ投資中。提案工数削減・工程効果・運用の能動化が効きどころです。
投資は運用まで含めて測り、人は付加価値工程へ寄せ、評価は使い方と品質へ。線引きと方針を示すのが管理職の仕事です。
質疑では、投資対効果・セキュリティ・雇用への影響・導入の順序・ベンダー選定・部下の評価など、判断に迷う論点を遠慮なくお寄せください。本資料は録画とあわせて読み返せるよう構成しています。
当日のチャットと質疑でいただいたご質問に、あらためて回答します。いずれも一つの正解がある問いではありませんので、判断の材料としてお読みください。
顧客はAI駆動開発によりコスト効果を期待することが大きいかと思いますが、どう付加価値を理解させるかが難しいと考えます（当社に取っては売上減となる）。そのあたりの対応へのヒントを伺いたいです。
まず前提を整理します。この問題は営業の説明の巧拙ではなく、対価の取り方の構造から生じています。「工数×単価」で対価を得ている限り、生産性が上がるほど請求できる工数は減ります。つまり、生産性向上と収益が構造的に逆を向きます。ここを動かさずに付加価値だけを説明しようとすると、どうしても苦しくなるという見方ができます。
大手も同じ論点に直面しています。2026年5月に公表された富士通の「中長期経営ビジョン2035」では、時田隆仁社長が「人月をベースにした対価のいただき方では、これ以上の成長は見込めない」と述べたと報じられています。業界全体で、工数を売る形から価値で対価を得る形への移行が議論されている段階です。
そのうえで、打ち手を4つに整理しました。すべてを一度に行う必要はなく、着手しやすいものから試す進め方が現実的だと考えます。
成果物と期間を固定した価格で請け、生産性向上の果実を自社に残す形です。「10人月かかる仕事を3人月で終わらせ、固定価格で請求する」という考え方が示されています。既存顧客の既存案件で価格体系を変えるのは難しいため、新規案件や新規領域から試す進め方が現実的です。
生成AI時代の受託事業の形として、高速受託型・アセット提供型・運用伴走型・内製化支援型・業務代行高度化型という5つの類型が挙げられています。開発だけを切り出して売る形から、運用や内製化支援まで含めて継続的に関与する形へ広げると、単発の工数減が売上に直結しにくくなります。
同じ金額でリードタイムが半分になるなら、顧客にとっては市場投入が早まる価値があります。単価の議論に入る前に、期間短縮が顧客の事業にもたらす効果を先に置くと、話の土俵が変わります。値引きの根拠ではなく、前倒しの価値として提示する形です。
発注者側でもAI活用は進みます。三菱UFJ銀行は事務・営業への生成AI導入で月22万時間以上の削減効果を試算し、公表しています（2023年11月時点）。こうした取り組みを支えるシステムの構築・連携・運用は新しい需要になります。既存案件の工数が減る一方で、AIを組み込む案件が増える構図です。
削減できた工数を全額そのまま値引きに回すと、投資の原資が残りません。効果を顧客と分け合う前提で、削減分の扱いを契約前に握っておく進め方があります。あわせて、何をもって効果とするかの指標（提案までの日数、リードタイム、障害件数など）を先に合意しておくと、後から「安くなったはず」という議論になりにくくなります。
正直に申し上げると、この転換は短期間では終わりません。既存の商流と見積り慣行があるためです。まずは一案件・一領域で価格の取り方を変えて実績を作り、その結果を持って横展開する順番が、現実的だと考えます。
実システム開発経験の浅い若手社員が、現状でのAI駆動開発の効果は薄いと思いますが、AI駆動開発がメインになった場合の若手開発者のシステム開発スキルを上げていく方法はないのか？なにかヒントがあれば教えてください。
ご懸念のとおりで、放っておくと若手のスキル形成は弱くなります。原因は能力ではなく学習過程にあります。生成AIが開発者の「つまずき」を消してしまうため、スキル形成に不可欠だった、問題と格闘する時間が失われるという指摘があります。詰まらずに動くものができてしまうと、なぜ動くのかを考える機会が生まれません。
一方で、AIを禁止する対処は勧めにくいところです。隠れて使う状態を作るだけで、指導の機会がかえって失われます。使わせたうえで、説明責任を負わせる方向が現実的だと考えます。
| 介在するポイント | 具体的なやり方 |
|---|---|
| 意図的な難しさを混ぜる | タスクを割り当てる際に、AIがすぐ答えを出せない要素を意識的に入れます。既存システムとの整合、性能要件、業務の例外処理など、文脈を読まないと解けない部分を残す形です |
| レビューで言語化させる | コードレビューの場で「なぜこの実装なのか」を本人の言葉で説明させます。AIが書いたかどうかは問わず、説明できるかどうかを問う運用にすると、理解の有無が表に出ます |
| 振り返りを定例化する | 1対1の面談で、どの場面でAIを使い、どこを自分で判断したかを振り返ります。使い方のパターンが本人の中で整理され、再現できるようになります |
教育の軸そのものも動いています。「書き方（How）」を教える形から、「考え方（Why）」と「評価（What）」を教える形へ移りつつあるという整理が示されています。実装を書けることより、出てきた実装が妥当かを判断できることの比重が上がる、という見立てです。
KDDIアイレットのMSPでは、自然言語で指示して作らせる方式から、要件定義と設計を先にドキュメント化してAIに実装させる方式（スペック駆動開発）へ切り替えています。仕様が文書として残り、テスト基準が明確になるため属人化を避けられるという整理です。この進め方は、若手にとっては「何を作るのかを先に言語化する」訓練になります。あわせて同社は、運用メンバー自身が要件整理から実装・テストまでの開発プロセス全体をチームで経験する体制を取っています。役割を一段上げることが、そのまま育成になっている例だと読めます。
スキルを上げたいなら、評価する対象を変える必要があるという観点があります。書いた量ではなく、AIをどう使い、出力をどう評価し、品質をどう担保したかを見る形です。評価が旧来のままだと、現場は「早く終わらせること」に最適化してしまい、考える時間が削られます。
AIを活用して効果を出している企業と、そうでない企業の二極化が進んでいるというお話がありました。効果を出せる組織と、そうでない組織を分ける要素は何だと思いますか。私は、以下の2点は重要な要素の一部だと考えています。（1）AIを活用しての改善目標が、事業目標とどれだけ強く関係しているか（2）データの標準化と、プロセスの見える化・標準化がどれだけ進んでいるか。この考えについてどう思われますか。
結論から申し上げると、2点とも調査データで裏づけられており、分岐点の中核を突いていると考えます。順にご説明します。
PwCが2026年6月10日に公表した6カ国比較調査の数値です。導入率では差がついていないのに、効果と財務貢献で開いている状況が読み取れます。
| ご指摘の要素 | 調査からの裏づけ |
|---|---|
| （1）改善目標と事業目標の連動 | 同調査では、効果が期待を上回る企業と下回る企業の分岐点は、生成AIを既存業務の効率化にとどめるか、事業変革の中核に据えるかにあるとされています。ご指摘のとおり、事業目標との距離が効果の差に表れていると読めます |
| （2）データとプロセスの標準化 | ビジョン起点で業務やデータが先に整えられることが効果創出の前提であるとして、AI Readinessの重要性が指摘されています。整っていない状態でツールだけ入れても、効果に変わりにくいという整理です |
そのうえで、同じ調査から読み取れる要素を2つ補足させてください。ご指摘の2点と組み合わせると、判断材料が増えると考えます。
効果を大きく出している企業では、経営に近い位置に推進体制が置かれ、業務プロセスへ正式に組み込まれている傾向が示されています。現場の有志による活動にとどまるか、意思決定に近い場所で旗が振られているかの差だと読めます。
効果を財務的還元まで接続できた日本企業が40%にとどまる点は、効果が出ていないというより、測って説明する仕組みがないことを示している可能性があります。何をもって効果とするかを先に決めておくと、投資の継続判断がぶれにくくなるという観点があります。
貴社のように顧客の情報やコードを預かる事業では、もう一つ分岐点があると考えます。入力してよい情報の線引きが先に決まっているかどうかです。線引きが曖昧なままだと、現場は安全側に倒して使わなくなるか、判断のないまま使うかのどちらかに寄ります。ルールを整えること自体が、活用の前提条件になるという見方ができます。