こんにちは。InsightEdge（以下、IE）でPMをしている川島です。 この記事ではSIerで基幹系システムのPMを実施していた私が、InsightEdgeに転職して感じたことを書かせて頂きます。大規模SIの経験しかないのにAI・事業会社に踏み出せるか不安なら、この記事を読んで欲しいです。 目次 どうしてこのブログを書くか なぜSIerを離れたか ― 30代中半で感じた違和感 InsightEdgeとはどんな組織か 同じこと ― 環境が変わっても通用したもの 違うこと ― 想像以上のカルチャーギャップ 大規模PMの経験が意外と活きた場面 おわりに 1. どうしてこのブログを書くか 前職はインフラ系SIerで大規模システム構築のPMをやっていました。電力・通信などの基幹系システムの構築を行ってきました。数十社のベンダーと調整しながら、ひとつの障害が社会インフラの停止に直結するような仕事をしてきました。そこからAIを活用した内製開発組織に転職しました。「なんでまた？」とよく聞かれます。この記事はその問いへの、今の自分なりの答えです。 2. なぜsierを離れたか―30代中半で感じた違和感 SIerの中で立場が上がるにつれて、ある矛盾をじわじわと感じるようになりました。組織の目標が「人を抱え続けること」になるほど、クライアントへの提案が「本当に必要なシステム改善」ではなく「次の案件を生むための提案」になっていきます。最初はそれに気づかないふりをしていました。でも30代半ばを過ぎたあたりから、「自分はいったい誰のために仕事をしているんだろう」という問いが、頭から離れなくなってしまいました。SIerという業態を否定したいわけではありません。ただ、立場が上がるほどその構造から抜け出せなくなります。「事業会社のIT組織として、ビジネス起点でシステムを考える側に行きたい」という気持ちが固まっていきました。 問題は「じゃあどの事業会社へ？」です。ここが正直、一番悩みました。特定の業界を選ぶと、前職の経験が活きる場面が偏ります。かといって明確な「やりたい業界」があるわけでもありませんでした。そこで行き着いたのが「総合商社の内製化組織」という選択肢でした。住友商事は金融・流通・エネルギー・メディアなど、幅広い商流とグループ企業を持っています。その内製開発組織であるInsightEdgeなら、特定の業界に縛られることなく、分野を横断して価値を提供できるんじゃないか ――「業界を選ばなかった」結果として、これまで触れてこなかった業務ドメインに次々と関われています。「業界を選ばなくていい事業会社」という逆転の発想が、転職先を決めた理由でした。 3. InsightEdgeとはどんな組織か InsightEdgeは、住友商事グループのDX・内製開発を担う組織です。AIや機械学習・データ分析を使って、グループ各社の業務課題を解くPoC（概念実証）を高速で回し続けることが主な仕事になります。外部SIerへの発注ではなく、内製であることの意味は大きいです。プロジェクトの動機が「次の案件を取る」ではなく「グループ事業の価値を上げる」であること。これが、前職で感じていた矛盾をそのまま解消してくれました。 4. 同じこと ― 環境が変わっても通用したもの 転職して最初に驚いたのは、PMの仕事の骨格が思ったより変わらないことです。ステークホルダー管理の本質はどこでも同じでした。相手が電力会社の設備部門長でも、製造業の経営企画部長でも、「相手が何を求めているか」を正確に把握して、「届けられるもの」との乖離を早期に埋める ―― これはPMの核心として変わりません。数十社を同時調整した経験は、そのまま活きました。 リスクを早めに言語化して共有する習慣も変わりませんでした。インフラ系では「リスクを見落とすことが社会的インシデントに直結する」という文化の中にいたので、潜在リスクを早期に共有することが骨まで染みついています。 PoC環境でも「このモデルの精度が出なかった場合、どこまで巻き戻るか」を事前に言語化しておくのは全く同じPMの仕事です。 「やらないことを決める」スコープ管理も普遍でした。 どちらの世界でも、スコープを守る力が最重要PMスキルのひとつであることは変わりません。 5. 違うこと ― 想像以上のカルチャーギャップ 環境は変わらないと思いきや、文脈の違いは想像を超えていました。 【成功の定義】 前職での成功は「リリース日を守ること」「止まらないこと」でした。 InsightEdgeでは「学びを最大化すること」「次のフェーズに繋げること」が成功です。 モデルの精度が出なかった＝失敗ではなく、「精度が出ないと分かった＝重要な学び」として扱われます。 【失敗の許容】 ここが最もカルチャーショックでした。 インフラ系では「失敗は許されない」が全ての行動原理です。 PoC環境では「失敗から学ぶ」が前提で、失敗を恐れて実験を遅らせる方が問題とされます。頭では分かっていても、長年染みついた「失敗回避」の反射はそう簡単に書き換えられませんでした。 【計画の粒度】 InsightEdgeでは短期間で仮説を回し続けることが基本です。 最初のプロジェクトで丁寧な計画書を持参したら、データサイエンティストに 「試してみないと何も言えませんよ」と静かに返されました。緻密に計画を立てることに価値を感じていた自分の価値観を変えるまで、時間がかかりました。 【業務知識の役割】 前職では、ドメイン知識は自分が主体的に深めるべきものでした。 PoC環境では、業務知識はクライアント側が持つものであり、こちらは「引き出す問い」と「データから示唆を出す技術」を持ち込む側です。「知っている自分」から「引き出す自分」への転換も必要になってきます。 6. 大規模PMの経験が意外と活きた場面 前職の経験が武器になった場面も多くあります。 PoC→本番移行の「谷」を渡れることが、今の自分の最大の強みだと思っています。 PoCが成功して「では本番に組み込もう」となった瞬間、セキュリティ・運用体制・既存システムとの連携という、まさに前職の世界が戻ってきます。 この「谷」を渡り切れずにPoC成果が塩漬けになるケースを、入社後何度も目撃しました。「PoC段階から本番を見据えて設計する」視点は、今では自分のPoC PMとしてのアイデンティティになっています。 複雑なステークホルダー折衝も強みになっています。グループ企業の経営層から現場部門まで利害が複雑に絡み合う構造は、前職の「数十社ベンダー＋複数の発注者部門」に構造が似ています。「誰に何を・いつ・どう伝えるか」のコミュニケーション設計は、そのまま通用しました。 7. おわりに 正直に言うと、転職は「完璧な答えを見つけてから動いた」わけではありません。 「このままSIerにいていいのか」という違和感と、「事業会社に行きたいけどどこへ？」 という迷いを抱えたまま、えいやっと決めた部分が大きいです。その選択は間違っていなかったと思っています。 「業界を選ばなかった」結果として、これまで触れてこなかった業務ドメインに次々と関われており、成長を感じさせてくれています。 PMという仕事の本質は「人と目標をつなぎ、不確実性を前に進む力に変える」ことです。スピードが速くなっても、確実性が下がっても、それは変わりません。大規模SIの経験しかないのにAI・事業会社に踏み出せるか不安なら、この記事を読んでほしいです。

法人ディベロップメント課の S・Sです。 マイナビBiz / LIVING の新規開発・保守運用を行なっております。 今回は、下記のような、私と同じような不安をお持ちの方に向けて、書いています。 「エンジニアの仕事は、いつかAIに取って変わられるのでは?という淡い不安が、実際の業務内でAIエージェント利用が定着化してきて、いよいよ現実味を帯びて焦っている」 「かといって、 実際にAIエージェントの有能さも肌感覚で感じているので、この大波にどのように立ち向かったらいいのかが分からない ...」 はっきり言って、誰しもが、AIエージェントの普及、そしてその先に、どんな未来が来るかが100%分かる人はいないかなと思います。 が、あくまで個人的に、こんな向き合い方をしたらいいのでは？ということをカンタンにまとめて、前向きな気持ちで、今できることを進めていけたらいいなと思っています。 この記事で、 少しでもAI社会におけるキャリアの不安が和ぎ、精神衛生や業務パフォーマンス、あわよくば、その先の未来でも生き抜けるエンジニアに向かって、ナノマイクロレベルにでもなれば幸い です。 今回は、サクッとカンタンめにまとめていますが、さらに概要をつかんでいただくために、1枚絵を用意しましたので、お忙しい方はこちらをチラ見していただけたらと思います。 ここから先は、上記の概要を少しずつ補足していきます。 AIの強み弱み分析 まず、AI との向き合い方を考える上で、そもそも、AIの特徴を理解しなければ、向き合い用がありません。 なので、完璧に見えるAIの強み弱み分析をカンタンにしておきます。 AI の強み ざっくりと下記が、AI の強みかなと思っています。 大量のデータからのパターン発見 認知作業が高速で行える 70点前後のクオリティのアウトプットを高速で出せる 大量のデータからのパターン発見 AI は、渡したデータの文字列や数値、組み合わせ等を高速で処理ができ、パターン発見を高速で行えるのが強みだと思います。 人手で莫大なデータからパターンを見つけるのは至難の技なので、ここはもうAIには到底叶わない領域 ですね。 認知作業が高速で行える 1つ目と被る部分でもありますが、認知作業、つまり、 大量のデータから本質や構造を把握し、整理することが得意 です。 「このコードの資料の内容を要約して」 と依頼すると、あっという間に、本質を抽出して、人間の理解できる形でアウトプットしてもらえた経験は少なくないのかなと思います。 70点前後のクオリティのアウトプットを高速で出せる 主に、前述の2つの強みを駆使して、与えられたデータ、プロンプトを元に、ざっくり70点前後のクオリティのアウトプットが高速に出せます。 人が、 0 → 1 を生み出すのにはものすごいエネルギーと時間を要しますので、AI はここを凌駕してきている のかなと思います。 AI の弱み 境界条件や例外ケースに弱い 生成物の結果に責任を取れない データ、プロンプト依存が大きい 境界条件や例外ケースに弱い 細かい条件分岐や例外ケースを考慮してのアウトプットが苦手な傾向にあります。 人であれば、文脈や背景、ドメイン知識、経験を踏まえて適切に対応できますが、ここは 正確に細かく指示出しをしてあげないと抜け漏れが発生 します。 それでいて、 あたかも完璧なように、振る舞ってくる、かつ、アンカリング効果によって、境界条件や例外ケースを見過ごしたまま、成果物を完成させてしまう懸念 があります。 参考:  アンカリング効果とは？意味や活用シーンをわかりやすく解説 生成物の結果に責任を取れない 当たり前ですが、人が作ろうがAIが作ろうが、 最終成果物の責任は、企業や個人が負います 。 AI に「不具合の責任を取れ！」といった所で、プロンプト上で「申し訳ありませんでした。以後このようなことは....（ごにょごにょ）」という文字列が返ってくるだけですからね。。 データ、プロンプト依存が大きい AI はよく「 増幅器 」と言われることが多いです。 この通りで、インプットするデータの量・質、プロンプトによる指示出しの質に依存します。 つまり、 こちら側から良いインプットをしなければ、出てくる成果物も微妙になってしまう ということですね。 あくまで人が与えるものの質ありき 、ということかと思います。 AI との向き合い方 一言でまとめると、 ・AI の強みは最大限活用して、弱みの部分は、人間の強みを強化して補完するのが良い と考えます。 AI を最大限活用 AI の強みを活用し、下記を主に対応できると良いかなと思います。 大量の情報の整理 パターンで対応できる業務（手作業だと時間かかるもの） 設計書や実装などの叩き台作成 大量の情報の整理 大量の情報整理は、AI の得意領域です。 人が行うとエネルギーも時間も大量に使ってしまうので、AI に任せてしまうのが良さそう です。 与えるデータの質やプロンプトを正確に行いながら、その上で、過不足をチェックし合いながら共創することで良い成果物を出せるかなと思います。 パターンで対応できる業務（手作業だと時間かかるもの） パターン化された業務や作業は、AI は得意です。 ルールや例外、誤作動を防ぐプロンプトで制御しつつ、AI に任せてしまうのが良いかと思います。 設計書や実装などの叩き台作成 AIは、ざっくりと70点のクオリティを高速で出すのが得意です。 なので、 初期段階の設計書や実装の叩き台をお願いする のがいいかなと思います。 その上で、必要に応じてプロンプトで細かな指示出しをしたり、自身で思考・作業を行うことで、70点→ 100点を目指すのが良いかなと思います。 AI に勝る能力開発 AI を活用しつつ、人間として、どう立ち回るかについては、主に下記かなと考えます。 生身の良質な情報を蓄積していく セキュリティ、コンプライアンス/法律、倫理観を向上させる 技術的なアップデート情報のキャッチアップ（これまで通り） 生身の良質な情報を蓄積していく（一番重要） AIに依頼するにも、自らが作業をするにも、 大元のオリジンである「わたし」に、良質なインプットを蓄えるのが重要 だと考えています。 物事の良し悪しや生身で感じる感情や感覚、パターン化できない複雑で曖昧なもの、インターネットには出回っていないような1次情報などなど。 こういったものが、AIには補完できない部分かなと思います。 良し悪しですが、あえて人間としての至らなさや揺らぎがかえって良い成果物や味のあるもの、人間の心に響くものが作れる のではないのかなと思っています。 セキュリティ、コンプライアンス/法律、倫理観を向上させる AIの弱みでも書きましたが、 AIは、責任を取れません 。 一方で、アウトプットの数は増えるし、作業過程の一部をAIに任せてしまうことによるリスクは増えます。 さらに、悪意のある人が、AI を使った脆弱性をついてくるリスクも高まります。 （既に、Claude Mythos（クロード・ミュトス）は、世の中の大量の脆弱性を発見できるようです） それでも、 最終的には、人が責任を取ります。 なので、これまでよりも、さらに、セキュリティやコンプライアンス・法律・倫理観の向上が必要になります。 ここは、技術者としても技術力アップと併せて必須のスキルとして、知識/経験を深めていきたいですね。 技術的なアップデート情報のキャッチアップ（これまで通り） AI で出された成果物を最終確認する人として、 アウトプットが正しいのか、パフォーマンスや保守性を考えて最適なのか、を判断するために、技術的なアップデートは必要 です。 エンジニアには当たり前かもしれませんが、引き続き、いや、これまで以上にアップデートの質を高めていくべきだと考えます。 まとめ AI および、AIエージェントの発達で、アプリケーション開発の効率が劇的に上がっているのは嬉しい反面、セキュリティリスクや人間としての立ち回りについての課題が生まれてきていると感じています。 とはいえ、 悲観しているだけでは何も現状は変わらないので、想像力を働かせ続け、AIの力は借りつつも、人たる能力を高め続けて、AI と共存して良いものを生み出し続けていきたい と思います。 今回は、あくまでサッと思い浮かんだことをまとめてみましたが、もっと広く深く考え続けられるテーマかなと思いますので、日々考え、行動を止めずにいきたいですね。

2026年6月4日、 経済産業省 と 国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が実施する Generative AI Accelerator Challenge (GENIAC) の一環として実施している基盤モデル開発支援事業の 第4期における採択事業者 のキックオフが行われました。今回 AWS は NVIDIA B200 Tensor Core GPU を搭載する Amazon EC2 P6-B200 インスタンス ( p6-b200.48xlarge )、NVIDIA H200 Tensor Core GPU を搭載する Amazon EC2 P5en インスタンス ( p5en.48xlarge )、NVIDIA H100 Tensor Core GPU を搭載する Amazon EC2 P5 インスタンス ( p5.48xlarge , p5.4xlarge ) 等の学習・推論に必要な仮想サーバーを提供します。 AWS は、 GENIAC バーチャルチーム を中心に、以下の支援を提供します: 計算資源 : Amazon EC2 P6-B200, P5en, P5 インスタンスの提供 技術支援 : AWS Solutions Architect (SA) を中心としたメンバーにより、コンピュート (EC2)・ネットワーク ( Elastic Fabric Adapter (EFA) )・ストレージ ( Amazon FSx for Lustre および Amazon S3 ) で構成される分散学習環境の AWS ParallelCluster  を活用した構築・管理の支援 開発者コミュニティ支援 : 海外モデルプロバイダーの開発メンバーとの交流イベントによる最先端の開発動向調査や海外視察、国内の機械学習エンジニア同士の交流による知見共有をはじめとした Meetup の実施 事業化支援 : GENIAC を通じて開発された基盤モデル・生成 AI アプリケーションの Amazon Bedrock Marketplace 、 AWS Marketplace の活用による go-to-market (GTM) 支援、利用企業との AWS 主催イベントを通じたマッチング機会の提供 これらは、経済産業省商務情報政策局情報処理基盤産業室、NEDO、ボストン コンサルティング グループ (BCG)、および AWS パートナーであるクラスメソッド株式会社と密に連携のうえで提供されます。 採択事業者 採択事業者のうち AWS を利用する事業者は以下です (現時点で承諾が得られたもののみをアルファベット・五十音順で掲載): 株式会社ABEJA Direava株式会社 株式会社DubGuild 株式会社Preferred Networks 株式会社メルカリ ONESTRUCTION株式会社 Sansan株式会社 株式会社Spectee 採択事業者からコメントを頂きました 株式会社ABEJAは、GENIAC第一期から継続して、LLMの社会実装への貢献を目的に、LLMおよび周辺技術の社会実装に取り組んでまいりました。 第四期では間違いが許されないミッションクリティカル事業への利活用を目的に、LLMおよび領域特化型のAIエージェントの研究開発に取り組みます。その上で、株式会社IDOM様と連携し、自動車整備領域における利活用を実証します。 AWS様の大規模な計算資源および技術支援を活用することで、過去事例など複数の情報ソースから必要な情報を自律的に検索・参照するToolUse能力、多様なデータを用いて論理的・段階的に解答を導き出す多段推論能力の強化を進めてまいります。 このたび新たに開発する技術は、実店舗で「Human in the Loop」の元、運用することを予定しています。精度を継続的に向上させながら、自動車整備領域における人手不足、属人化、技術の高度化による生産性低下といった課題の解決に貢献してまいります。 — 株式会社ABEJA 執行役員 木下 正文 氏   弊社はGENIACサイクル4において、外科手術における「未来予測AI基盤モデル」の開発に注力します。 サイクル3に引き続き、Amazon EC2 P5インスタンスや、大規模分散学習を支える最先端のインフラを継続して活用できることに深く感謝しております。AWS様の強力なサポートのもと、最先端AIの力で一歩先の医療現場を支えるソリューションの開発を加速させてまいります。 — Direava株式会社 CTO 斎藤 洸輔 氏   DubGuildは、大規模な音声インタラクションモデルの研究開発に取り組んでいます。 GENIACプロジェクトでは、B200 GPUを搭載したAWSのP6-B200インスタンスを活用し、30B級の大規模音声言語モデルの開発を進めてまいります。 本取り組みにあたり、Generative AI Innovation Centerをはじめ、AWSの皆様より多大なるご支援を賜っておりますこと、心より感謝申し上げます。 — 株式会社DubGuild CEO 大嵜匡俊 氏   株式会社メルカリは、GENIACプロジェクト4期目において、”Generative Retrieval技術を用いた二次流通市場向け高精度検索・推薦基盤モデルの開発”に取り組みます。Amazon EC2 P5インスタンスを活用し、大規模な学習を行います。AI自身が商品を丸暗記して探す次世代検索モデルによって、世界中の誰もが欲しい物にすぐに出会える最高の買い物体験を目指します。 — 株式会社メルカリ 研究開発組織R4D 所長 小堀 訓成 氏   AWS様には第3期に続き、第4期も引き続き支援いただきありがとうございます。 ONESTRUCTIONは本事業において、建設×AIをテーマに、建設ドメイン知識のAIエージェントへの統合と、それによる3次元設計（BIM）のAIによる自律化を目指します。 AWSの圧倒的なレジリエンスと信頼性に加え、とりわけGenAI Innovation Centerのチームによる世界水準の知見によるバックアップにより、建設業界のAI-Powerdを実現させます、ご期待ください。 — ONESTRUCTION株式会社 AI戦略ユニット Manager 日高 洸陽 氏   防災・危機管理分野からは初の採択となる今回、Specteeは独自の災害データとAI技術を基盤に、危機事象をリアルタイムに抽出する災害検知LLMと、ユーザー固有のBCP等を踏まえて行動を示唆する危機管理AIエージェントの開発に取り組みます。学習には Amazon EC2 P5 インスタンス、データ管理には Amazon S3 を活用し、AWS様のバーチャルチームによる技術支援のもと、人命に関わる領域に求められる高い精度と安定性の実現を目指します。日本発の次世代防災・危機管理基盤として、グローバル展開を見据えて開発を加速してまいります。 — 株式会社Spectee 取締役CRDO 加藤 奈々 氏 まとめ AWS では日本のお客様に対し、2023年の AWS LLM 開発支援プログラム にはじまり、グローバルの Generative AI Accelerator や AWS ジャパン生成 AI 実用化推進プログラム といった取り組みを通して生成 AI ワークロードを支援しています。GENIAC においても 第2期 、 第3期 に続き、第4期でも引き続き採択事業者の皆様と伴走し、これまで蓄積してきた知見を活かして日本の生成 AI 基盤モデル開発力の向上に貢献できれば幸いです。