お客様：NECソリューションイノベータ株式会社 第三トランスポート・サービスソリューション統括部
ディレクター：飯嶋 勇人 様
シニアプロフェッショナル：牧野 友昭 様
業種：ITソリューション・システムインテグレーション
テーマ：生成AI（RAG・AWS Bedrock）× 実践型人材育成研修
提供サービス：Dify／AWS Bedrockを活用したケーススタディ型研修プログラム
※取材はFDX株式会社の旧社名（アローサル・テクノロジー株式会社）時代に実施しました。
はじめに
AWSサーバレスの設計・開発で豊富な実績を持つNECソリューションイノベータ様。しかし、生成AIの急速な進化の中で、「提案依頼が来ても他部署に応援を依頼せざるを得なかった」という切実な課題に直面していました。
本記事では、同社がFDX（旧アローサル・テクノロジー）の実践型研修プログラムを通じて、いかにして生成AIを「知識」から「実践力」へと転換したのか。研修の背景から成果、そしてSIerとしての今後の展望まで、その全貌をお届けします。
01. 背景 — 「案件を見送るだけ」という危機感
提案依頼が来ても、他部署に応援を依頼せざるを得なかった
NECソリューションイノベータ様は、主に自動車メーカー向けに、AWSサーバレスサービスを活用したシステム設計・開発を手がけています。その中で生成AIの活用はコーディング補助やトラブルシュート時の調査など、狭い範囲にとどまっていました。
そうした中、転機となったのは顧客からの生成AIに関する提案依頼でした。RAGやAIエージェントの構築といった依頼が届き始めたものの、対応できる人材がおらず、案件を見送らざるを得ない状況が続いていたのです。
提案依頼が来ても対応できない。そこが一番大きかったです。どうやるんだ、というイメージがまずなかったですし、想像ができないからこそ人材育成しようもなくて。案件の取りこぼしが非常にもったいなかった、というのもありますね。
— NECソリューションイノベータ様
当時は、AWS Bedrockに関する技術情報や導入事例がAzure系サービスと比較して限定的であり、市場においても対応可能なエンジニアはまだ少数でした。こうした状況を踏まえ、単なる生成AIの知識習得ではなく、顧客業務への実装を見据えたケーススタディ型の学習を通じて、実践的なノウハウを蓄積する必要がありました。
お客様業務への適用ができるようになれば、おのずと社内業務への活用にも繋がるノウハウが身につくと判断しました。
— NECソリューションイノベータ様
顧客の現場でも高まるAIへの期待
背景には、顧客である自動車メーカー側の変化もありました。自動車業界ではSDV（Software Defined Vehicle）化が進展し、ソフトウェア起因の不具合対応や継続的なアップデート対応など、従来とは異なる品質管理コストが増加しています。こうした中、品質部門では、品質コスト削減や業務効率化に向けて、AIを活用したデータ分析・異常検知への期待が高まっていました。
お客様が「AIオリエンテッドでやってるよ」という企画を立てたりする。そういうところに寄り添っていかないと、仕事がないぞっていう危機感を持ってやってます。
— NECソリューションイノベータ様
顧客企業では、生成AIやDX領域への大規模投資が進み、市場そのものが急速に拡大していました。こうした成長領域において顧客ニーズへ迅速に対応していくためにも、生成AIに関する技術力や提案力の強化が急務となっていたのです。
02. パートナー選定 — 「寄り添う姿勢」が決め手に
研修パートナーの選定にあたっては、4社ほどを比較検討されたといいます。そのうち3社はパートナー経由の紹介で、パッケージ型の提案が中心。カスタマイズの余地が限られていました。
御社だったら寄り添ってくれたっていうのがあるんですよね。他の会社はパッケージがあって、そこからずらすことは厳しいですって。割と融通が利いて、腰が軽く、ぜひお付き合いしたいなと思った次第です。
— NECソリューションイノベータ様
研修の目標は明確でした。「お客様の業務に生成AIを適用していくプロジェクトを、自組織メンバーがリーディングできるようになること」。単なる技術習得ではなく、実務でリードできる人材を育てることがゴールでした。
03. 研修の実施 — Dify×Bedrockで「動くもの」を作る
研修は、DifyとAWS Bedrockを組み合わせ、参加メンバーが実際の現場課題をテーマに取り組むケーススタディ型で実施されました。座学で終わるのではなく、実際に手を動かして「動くもの」を作ることに重点が置かれました。
「こんなに簡単に」という驚き、そしてその先の問い
Difyを初めて触るメンバーからは、「こんなに簡単にフローが作成できるのか」という驚きの声が多く上がりました。視覚的にワークフローを組める点も理解しやすいと好評でした。
一方で、その簡便さが新たな問いを生みました。顧客も同様のツールを使える以上、「エンジニアとしてどこに価値を出すのか」という根本的な問いです。
生成AIを使うところって、全体の中のツール的な部分だと思うんですよ。特定の箇所に閉じて、例えばより安く作るとか、そこは競えないので、全体のコーディネートができて、その中で生成AIを活用した部分がどういう姿であるべきかというところで勝負していかないといけない。
— NECソリューションイノベータ様
生成AIそのものは、システム全体の一部を担う技術に過ぎません。単に「生成AIを使って安く開発する」といった部分最適の競争では、今後差別化は難しくなるでしょう。重要なのは、業務全体やシステム全体を俯瞰した上で、生成AIをどこに、どのような形で組み込むべきかを設計・提案できることだと考えています。
ハンズオンで見えた「手応え」と「次の課題」
ハンズオンでは、各メンバーが実際の現場課題をテーマに取り組みました。短期間であり機能面での課題は残ったものの、課題解決のためのAIツールを実際に動かすところまで到達できたことが大きな手応えとなりました。
課題解決のためのAIツールを実際に動かすところまで到達できた点は大きな手応えでした。
— NECソリューションイノベータ様
同時に、実際の案件に適用する際の「次の課題」も明確になりました。トークン量の問題、速度・性能のチューニング、生成AIではなく別のツールを呼び出してトークンを節約するといった技術的な深化ポイントです。
本当に案件に適用しようと思ったときに、例えば性能とかトークンの量の問題とか、そこまで入り込んでいるわけではないので、そこはまだまだ課題があると思っています。
— NECソリューションイノベータ様
技術進化のスピードへの実感
研修を通じて強く感じられたのは、生成AI領域の技術進化の速さでした。ノーコードでAIアプリを開発できるDifyを活用した研修を行っていた頃から、短期間のうちにAgent SDKが登場。サブエージェントや業務オートメーションなど、活用できる技術やアプローチが次々と拡大していきました。
体系立ててやることが難しいなと思ってたので、いったん突破口じゃないですけど「やってみる」っていうところは行けたのかなと思いました。
— NECソリューションイノベータ様
「何が最適なのかを判断できる人はほとんどいない」という現実の中で、まずは手を動かして体験するという研修のアプローチが、変化の第一歩となりました。
04. 実感された変化 — 「明らかに知識が違う」
顧客との会話の質が変わった
研修後、案件数自体が劇的に増えたわけではありません。顧客側も「やりたい」と言っても案件化までは至らないケースもあります。しかし、確実に変化はありました。それは、顧客との会話の質そのものが変わったということです。
1年前の状態と比べて、明らかに知識が違うんですよね。お客様の言ってることに対して、「こうやればできそうだな」とか、「どこがネックになりそうか」っていうイメージができる勘所もある。そこまでいったら大体進められそうな感じです。
— NECソリューションイノベータ様
実際に、NECグループ内から届いた生成AI案件の相談に対して、以前であれば見送るしかなかった案件に、能動的にアプローチできる状態へと変わっています。「うちでできますよ」と言えるようになったことが具体例として挙げられました。
「便利ツール」ではなく「必須のもの」へ
AIの捉え方も大きく変わりました。研修前は「便利なツール」程度の認識だったものが、今では「形はどうあれ、技術としては取り組まなきゃいけない必須のもの」という認識に変化しています。
便利ツールっていうよりはもう必須のもので。まずは試せたっていうのが一番大きいかなと思う。
— NECソリューションイノベータ様
同時に、様々なプロセスにおいて「AI活用を前提としたらどう変えられるか」という思考が組織内に芽生え始めています。従来よりもさらに危機感を持つようになったという声もあり、それ自体が組織の意識変化の証です。
05. 生成AI時代に残る「人」の役割
「優秀なアシスタント」という捉え方
インタビューを通じて印象的だったのは、AIと人間の役割分担に対するバランスの取れた視点です。「生成AIを使わない」という選択肢は現実的ではない。しかし、AIに任せっぱなしでもない。その中間にこそ、エンジニアの新しい価値があるという認識です。
生成AIを使わないという選択肢は現実的ではありません。感覚としては「優秀なアシスタントを得た」という捉え方で、むしろ人が担える役割は広がったと感じています。
— NECソリューションイノベータ様
「許可」を押し続けるリスクと責任
ただし、AIは万能ではありません。同じ思考を繰り返したり、期待した結果が得られないこともあります。そのときに運用者へエスカレーションする判断基準 — そこにはやはり「人間の感性」が必要だといいます。
実際の開発現場でも、AIアシスタントが提案する操作を「許可、許可」と承認し続ける人が出てくる問題が指摘されました。中身を理解した上で承認しているのか — そのガードレールの設計こそが、エンジニアの責任であるという議論です。
VS Code上でCopilotを使っていても、勝手にCLIを叩いてくれるわけですよね。許可、許可ってやる人が出てくる。中身わかってて許可してるのかどうかって人が理想ですよね。たまに「それ駄目」っていうものの許可を求めることもあったりするんで。
— NECソリューションイノベータ様
生成AIが内包するリスクをどの工程で検知し、どう人が介在するかを設計すること — それこそがエンジニアの新しい価値であるという認識が、研修を通じて組織全体に共有されました。これは、最近注目される「ハーネスエンジニアリング」、すなわちAIをいかに制御し、安全に活用するかという考え方にも通じるものです。
06. SIerのジレンマ — 工数商売とAI効率化の狭間で
インタビューの中で特に印象的だったのは、SIerとしての構造的なジレンマについての率直な議論です。AIで開発を効率化すればするほど、工数ベースの売上が減るという矛盾です。
効率化すればするほど既存事業のパイが減ってしまう。そこが難しいんですよね。お客様には納得を持っていただく費用感を提示する必要があり、試行錯誤をしている状況です。
— NECソリューションイノベータ様
生成AIによって開発効率が向上する一方で、従来の工数型ビジネスモデルとのバランスは大きな課題になっています。効率化そのものは進められるものの、顧客への提供においては、品質や運用体制、価値提供のあり方も含めて慎重に見極める必要があります。
これは多くのSIerが直面する共通の課題です。ウォーターフォール型の大規模案件がボリュームゾーンである一方、工数商売のモデルが前提となっているため、AIによる効率化がそのまま売上減に繋がる構造です。
さらに、ジュニアメンバーをアサインできる現場が減ってきているという課題も指摘されました。AIによる自動化が進めば、単純な開発作業だけでは顧客に価値を認めてもらえなくなる可能性があります。
FDE — エンジニアの新しい役割像
このジレンマの突破口として話題に上がったのが、FDE（Forward Deployed Engineer）という概念です。米国Palantir社が提唱し、OpenAIも採用するこの役割は、「顧客の業務に入り込みながら、エンジニアが自ら課題を発見し、その場で解決策を構築する」というものです。
FDEって言葉、本日初めて聞いたんですけど、考えてることは一緒だったなと思いました。結局、今の我々ってお客様から課題を聞いてるんです。本当はその中に入って、課題自身を見つける必要があるなと思っていて。
— NECソリューションイノベータ様
ただし、大企業ならではの現実もあります。FDE型は規模を稼ぎにくく、組織のビジネスモデルとの整合が必要です。「上流から入って、ここは今まで通りウォーターフォールでやろうとか、分けて提案して、説得しながら進める」という現実的なアプローチが語られていました。
07. 今後の展望 — 「プロセスごと見直す」発想へ
「部分的なAI化」ではなく、プロセス全体の再設計
研修後の展望として、設計以降の工程における生成AI活用を当たり前にしつつ、提案・上流フェーズもアップデートしていきたいと語ります。そのビジョンは、「既存プロセスの一部をAIで置き換える」という発想を超えています。
今の既存のプロセスがあって、この部分をAIで自動化します、ではなくて。一連の流れに生成AIを使うと、そもそもプロセスが変わるよねと。そこを目指したいんですよ。
— NECソリューションイノベータ様
現時点では、各工程における確認作業の網羅性チェックや、ソースコードから設計書をリバースエンジニアリングして更新するなど、生成AIの活用が徐々に進み始めています。しかし、現場ではこうした取り組みに対しても「まだ本格的な活用とは言えない」という謙虚な声が聞かれました。その背景には、生成AI活用をさらに高度化していきたいという強い意欲が窺えます。
「課題を聞く側」から「見つける側」へ
もう一つの大きな変化は、「課題を聞く側」から「課題を見つける側」への転換意識です。これまでは顧客から要件が出来上がってから入り、それを実現することに特化していました。しかし、今後は顧客の業務に入り込み、自ら課題を発見して提案に繋げるスタイルを目指しています。
他の業界の事例もちょっと小まめに届けてもらって、一つでも引っかかれば新しいビジネスが生まれるなって。せっかくの出会いなので、そういうことに繋げていきたいと思いました。
— NECソリューションイノベータ様
研修を通じて得たノウハウと、他業界のユースケース情報を掛け合わせることで、顧客の潜在課題を探り当てる — そういった「上流からの課題発掘」型の役割を、研修で得た武器を活かして実践していく構えです。
まとめ
導入のポイント
- 顧客からの生成AI提案依頼に応えきれず、案件を見送るしかなかった危機感が導入のきっかけ
- 4社比較の中、「パッケージ型」ではなく現場課題に寄り添う柔軟な研修を選択
- Dify×AWS Bedrockで「動くもの」を作る体験が、実務での自信に直結
- 研修後、顧客との会話の質が変化。「うちでできますよ」と能動的にアプローチ可能に
- AIを「優秀なアシスタント」と捉え、人が担うリスク管理・制御設計の重要性を共有
- SIerの工数商売とAI効率化のジレンマに向き合い、上流からの課題発掘型への転換を模索
- 「部分的なAI化」ではなく、プロセス全体の再設計という発想転換が生まれた
「案件を見送るだけ」から「うちでできますよ」と言える組織へ — NECソリューションイノベータ様の変革は、「実践型」の研修が組織の意識と行動をどう変えるかを示す好例です。そしてその変化は、研修で学んだ技術だけでなく、SIerとしてのビジネスモデルやエンジニアの役割といった、より深いレベルの問いへと広がっています。
FDXでは、お客様の現場課題に寄り添いながら、生成AIを「知識」から「実践力」へと変える研修プログラムを提供しています。お気軽にご相談ください。
よくある質問
Q1. どのような研修プログラムを実施しましたか？
DifyとAWS Bedrockを組み合わせたケーススタディ型の研修です。AI基礎、需要形成・顧客提案、要求／要件定義、AI構築・データ整備、運用保守、まとめ・総括の6ステップで構成し、参加メンバーが実際の現場課題をテーマに「動くもの」を作ることに重点を置きました。
Q2. 研修を導入したきっかけは何ですか？
顧客から生成AIに関する提案依頼（RAGやAIエージェントの構築など）が届き始めた一方で、自組織で対応できる人材が不足していたことです。AWS Bedrockの技術情報や対応可能なエンジニアが市場でもまだ少なく、実践的なノウハウを蓄積する必要がありました。
Q3. 研修パートナーはどのように選ばれましたか？
4社ほどを比較検討されました。パッケージ型でカスタマイズの余地が限られる提案が多い中、現場課題に合わせて内容を柔軟に調整できる「寄り添う姿勢」が決め手になったと伺っています。
Q4. 研修後にどのような変化がありましたか？
案件数が劇的に増えたわけではありませんが、顧客との会話の質が変わりました。顧客の要望に対して実現方法やネックになりそうな点をイメージできるようになり、NECグループ内から届いた生成AI案件の相談にも能動的にアプローチできる状態になっています。
Q5. 研修後に見えてきた課題はありますか？
実案件への適用に向けては、トークン量や速度・性能のチューニングといった技術的な深化が次の課題です。加えて、AI効率化と工数ベースのビジネスモデルをどう両立させるかというSIer特有のジレンマにも向き合っています。
※FDXの研修プログラムについては研修プログラムをご覧ください。