はじめに 2026年3月26日、初の試みとして、リクルート本社オフィスにて 「産学連携技術交流会」 を開催しました。本イベント

1. AIスタートアップから Insight Edgeへ 2. AIスタートアップでのAIビジネスの関わり方 3. Insight Edgeで働いて感じた面白さ 3.1 住商内製組織ならではのスピード感と知見獲得のサイクル 3.2 多様なドメインに触れることで広がる視野 3.3 技術トレンドの変化とAIビジネスのダイナミズム 3.4 コンサル×技術×デザインによる価値提供の広がり 3.5 デジタル組織連携による今後の可能性 4. AIビジネスへの関わり方の違い 5. まとめ 1. AIスタートアップから Insight Edgeへ こんにちは。Insight Edgeでセールスコンサルタントをしている飯野です。 入社してちょうど1年が経ったタイミングで、これまでの働き方を振り返ってみたいと思います。 AIスタートアップから、住友商事のデジタルCoE組織である Insight Edgeに転職して、最も大きく変わったのは「AIビジネスへの関わり方」でした。 私はこれまで、AIスタートアップで営業／コンサルタントとして、主に予測・最適化といった技術を軸にしたソリューションの提案に携わってきました。 特定の技術領域に強みを持ち、それをもとに顧客の課題解決を行う、いわゆる“技術ドリブン”なビジネスに関わってきた形です。 一方で、前職ではAIや業務最適化の提案・プロジェクト推進を通じて成果を出してきた中で、より顧客の事業や組織の変化にまで踏み込んだ形で価値を出していきたいという思いも強くなっていきました。 そのため、特定の技術を前提とした提案にとどまらず、技術の進化も取り入れながら、より広い視点でコンサルティングの幅を広げていきたいと考えるようになりました。 実際に働いてみると、AIビジネスへの関わり方そのものが大きく変わったと感じています。 本記事では、AIスタートアップとの比較も交えながら、Insight Edgeで働く中で感じている「面白さ」について整理してみます。 2. AIスタートアップでのAIビジネスの関わり方 AIスタートアップでの仕事は、特定の技術領域を中心に価値提供を行うものでした。 予測モデルの構築 最適化アルゴリズムの適用 特定ユースケースへのソリューション提供 といった形で、技術そのものが価値の中心にあり、 「どの技術で課題を解くか」が重要な意思決定になります。 このような環境では、 技術の強さがそのまま競争力になる 提供価値が比較的明確である 特定領域での専門性が深まる といった面白さがありました。 また、もともと私は、業界知識と技術知見の両方を使いながら、顧客の業務や課題を深く理解して提案することに面白さを感じていました。 だからこそ、特定のソリューションを届けるだけでなく、より広い文脈で顧客課題に向き合える環境に魅力を感じるようになったのだと思います。 一方で、関われる領域や課題の幅という観点では、どうしても一定の制約があることも事実でした。 3. Insight Edgeで働いて感じた面白さ Insight Edgeに来て最も感じているのは、 AIビジネスへの関わり方がより広く、かつ動的であるという点です。 ここでは、特に印象的だったポイントをいくつか挙げます。 3.1 住商内製組織ならではのスピード感と知見獲得のサイクル Insight Edgeは住友商事グループの内製組織として、グループ内の事業会社と近い距離でプロジェクトを進めることが多い環境です。 この関係性により、 信頼関係を前提に議論が進む 課題の解像度が高く、必要に応じて現場の状況もフランクに確認しやすい 意思決定から実行までのスピードが速い といった特徴があります。 こうした環境では、案件の立ち上がりから実行までのサイクルが比較的短く、 結果として 短いサイクルで経験と知見を積み重ねていける という実感があります。 例えば、グループ内案件では契約に至るまでのリードタイムが短く、現場担当者や意思決定者へのアクセスも比較的取りやすいため、提案から実行までをスピーディに進めることができます。 その結果、仮説を持って提案し、フィードバックを踏まえてすぐに改善するというサイクルを高速で回すことができ、実践を通じて知見を高速に蓄積していける環境になっていると感じています。 セールスコンサルタントとしても、単なる提案にとどまらず、実際の価値創出まで関われるため、学習の密度が高い点に面白さを感じています。 3.2 多様なドメインに触れることで広がる視野 Insight Edgeでは、住友商事が関わる多様な事業領域に接点があります。 例えば、 エネルギー 物流 製造 小売 といった領域ごとに、課題の構造や業務プロセスは大きく異なります。 スタートアップ時代は、特定領域にフォーカスすることで専門性を深めていましたが、 Insight Edgeでは 業界横断で「AIがどのように使われるか」を考える機会 が増えます。 これは単に知識が増えるというだけでなく、異なる業界の課題を横断的に捉える視点や、応用の引き出しの多さにつながっていると感じています。 また、ある業界で得た視点や課題の捉え方を、別の業界に応用して考えられることも、この環境ならではの面白さだと感じています。 3.3 技術トレンドの変化とAIビジネスのダイナミズム 近年の大きな変化として、生成AIの登場があります。 Insight Edgeでは、新しい技術に対して前向きに取り組む文化があり、生成AIも実際の案件の中で積極的に活用されています。 その結果、 提供するソリューションの形が変わる 顧客への提案内容が変わる 価値の出し方自体が変わる といった変化が起きています。 スタートアップ時代はコア技術がある程度固定されていたのに対し、 Insight Edgeでは 技術の進化に応じて提供価値が変わり続ける という特徴があります。 個人としても、この環境にいることで、常に新しい技術に触れながら仕事ができる点に面白さを感じています。 さらに、こうした変化の中で、生成AIの普及によりプログラムやアルゴリズムといった技術そのものによる差別化は相対的に難しくなってきているとも感じています。 その一方で、さまざまなアセットを組み合わせて新たな価値を生み出していく重要性が高まっており、そのような動き方が求められる環境である点にも面白さを感じています。 3.4 コンサル×技術×デザインによる価値提供の広がり Insight Edgeでは、コンサルティング・技術・デザインといった複数のケイパビリティを組み合わせて、顧客に価値提供を行います。 そのため、 事業構想の整理 業務プロセスの設計 AI・システムの実装 現場への定着 デジタル組織の立ち上げや内製化支援 まで、一貫して関わるケースも少なくありません。 単にソリューションを導入するだけでなく、 継続的に価値を生み出せる体制そのものを作るという点も特徴的だと感じています。 このような環境では、セールスコンサルタントとしても 「何を売るか」ではなく「何を実現するか」から考える ことが求められます。 また、単に技術を提案するのではなく、その提案が顧客の事業や業務にどう位置づくのか、どのような価値や変化につながるのかまで含めて構想できることにも面白さを感じています。 結果として、 提案できる領域が広がる 関われるフェーズが増える 顧客への価値提供の解像度が上がる といった変化があり、仕事としての面白さの幅が広いと感じています。 3.5 デジタル組織連携による今後の可能性 今後の展開として、Insight Edgeはこれまでも住友商事グループ内の各デジタル組織と連携しながら価値提供を行ってきましたが、近年の体制変化（例：SCSKの完全子会社化など）もあり、その連携がさらに強化・拡大しつつあると感じています。 異なる強みを持つ組織との連携により、例えば これまで以上に上流から実装・運用まで一貫した支援が可能になること 技術・データ・事業アセットを組み合わせたソリューションの高度化 が期待されます。 また、こうした連携を前提として、住友商事グループとしてのシナジーを活かしながら、グループ内で培った知見やアセットをもとに、グループ外の企業に対してもワンチームで価値提供していくような動きが今後さらに広がっていくと感じています。 こうした変化の中で、個人の視点でも、 これまでに得た知見をもとに、より広いフィールドで価値発揮していく機会 が増えていく可能性があり、今後の広がりにも面白さを感じています。 4. AIビジネスへの関わり方の違い ここまでの内容を踏まえると、 AIスタートアップとInsight Edgeでは、AIビジネスへの関わり方に違いがあります。 スタートアップでは、特定技術を軸に価値を最大化する面白さがありました。 一方でInsight Edgeでは、 技術 ビジネス（現場の業務や意思決定を含む） を横断しながら、 AIを「どのように使うか」を考える面白さ があると感じています。 どちらにも異なる魅力がありますが、現在はより広い視点でAIに関われる点に、仕事としての面白さややりがいを感じています。 5. まとめ Insight Edgeで働く中で感じている面白さは、 多様なドメインに触れられること 技術の進化がそのまま仕事に反映されること 現場に近い距離で価値創出に関われること 提案できる領域の広さ といった点にあります。 AIの活用が広がる中で、 「どの技術を使うか」だけでなく、 「どのように使うか」を考える重要性は今後さらに高まっていくと思います。 その中で、さまざまな領域にまたがりながらAIビジネスに関われる環境は、個人としても非常に刺激的であり、面白いと感じています。 もしInsight Edgeでの働き方に興味を持っていただけた方は、ぜひ以下の採用ページもご覧ください。 https://herp.careers/v1/insightedge/V3eGbCLwh8Jy

本記事は「 From copilots to coworkers at AAAI: the gap between agentic research and production 」を翻訳したものです。 2026 年 1 月 27 日 AAAI 2026 パネルディスカッション「From Copilots to Co-Workers: What Changes When AI Writes, Reads, and Reasons About Code?」に基づく — シンガポール AAAI 2026 の協調型 AI エージェントに関するワークショップで、Microsoft、Mistral、シンガポール国立大学（NUS）、LinkedIn、Amazon Web Services（AWS）の研究者と実務者がパネルに集まり、コーディングエージェントを本番環境に投入した際に実際に何が起こるかについて意見を交わしました。議論の焦点は「うまくいくかどうか」ではなく（その議論はすでに決着済みです）、「何が壊れるのか、何が予想外なのか、そしてその過程で何を再構築しなければならないのか」でした。 パネリスト ： Shengyu Fu — Microsoft CoreAI、Partner Applied Science Manager。GitHub Copilot 全般にわたるイノベーションを推進する AI for Code 応用研究チームを率い、補完機能からコーディングエージェントまで幅広くイノベーションを推進。 Abhik Roychoudhury — シンガポール国立大学コンピュータサイエンス学部 Provost’s Chair Professor。ACM フェロー、ACM TOSEM 編集長。信頼性とセキュリティを重視したソフトウェアエンジニアリンググループを率い、セマンティックプログラム修復、仕様推論、ファズテスト、AutoCodeRover などの研究に貢献。 Baptiste Rozière — Mistral AI のコード生成チームを率いる。以前は Meta AI に在籍し、Llama に貢献、Code Llama を主導。 Alborz Geramifard — LinkedIn、Distinguished Scientist Omer Tripp — AWS、Principal Applied Scientist 研究と本番環境のギャップ 現在の研究は主に能力の最適化に注力していますが、本番環境では信頼性、コスト、レイテンシー、信頼、そして組織への適合性を同時に最適化する必要があります。 ソフトウェア開発向け AI には、おなじみのパターンがあります。論文がベンチマークで印象的な結果を示す。チームがそれを製品化しようとする。そして本当の仕事が始まります。それはモデルに関する作業ではなく、モデルの周辺にあるすべてのものに関する作業です。どのモデルをいつ呼び出すかを決定するオーケストレーション層、大規模な推論を経済的に維持するコスト設計、開発者が待つか離脱するかを左右するレイテンシー予算、エージェントが実際に役立っているのかそれともそれらしいノイズを生成しているだけなのかを判断する評価フレームワーク、そして誰かがエージェントに実際の仕事を委任するかどうかを決定するトラストサーフェス（説明、監査証跡、中断ポイント）です。 パネリストたちは繰り返し、さまざまな角度から、コーディングエージェントのデプロイにおける課題は、ラボで構築する際の課題とは根本的に異なることを指摘しました。研究は能力を最適化します。本番環境は信頼性、コスト、レイテンシー、信頼、組織への適合性を同時に最適化します。そしてこのギャップは単一の問題ではありません。それぞれが独自の苦労から得た教訓を持つ、いくつかの異なるレベルで現れます。 ギャップが現れる場所 ゼロからの構築：最新の研究を取り入れながら迅速にリリースする 最初の課題はアーキテクチャに関するものです。モデルの能力が限られていた頃、チャットは自然なインタラクションモデルでした。Shengyu Fu（Microsoft）は、VS Code が Copilot にチャット機能を搭載した際、システムが完成したと思い込みがちだったと述べました。プロンプティングがすべてだと感じられたのです。しかし、その幻想はより高性能なモデルの登場とともに崩れます。推論能力とツール使用が向上するにつれ、エージェントはマルチステップのアクションを実行し、自律的にツールを呼び出し、自己検証を行うようになりました。課題はプロンプトエンジニアリングからオーケストレーション、システム設計、評価へと移行しました。これを早期に認識しなかったチームは、後になって手戻りという代償を払うことになりました。 この現代的なエージェントパラダイムでは、アーキテクチャの専門化が有効です。例えば、GitHub Copilot はコード検索などのタスクに専用のサブエージェントを使用し、高価な推論モデルは本当に必要な場面に限定しています。しかし、この専門化には独自の問題が伴います。エージェント間のハンドオフのたびにレイテンシーが増加し、コンテキストが複数のステージを通過するにつれて情報が劣化します。数千万行規模のコードベースでは、コスト削減にはより安価なモデルへの単純な置き換えではなく、システムレベルの設計が必要です。 ユーザーがレイテンシーをどう認識するかも変化しました。2025 年にはスピードが品質の代理指標でした。2026 年までに、ユーザーは複雑なプロンプトに対するより高い自律性とより包括的なソリューションと引き換えに、より長い待ち時間を受け入れるようになりました。基準は「素早く応答する」から「自分がやらなくて済むようにもっと多くを処理する」へと移りました。Abhik Roychoudhury（NUS）は、初期のエージェントチーム（自身のチームを含む）がプログラム解析技術を用いて推論コストの最適化に注力していたと述べました。多くの人を驚かせたのは、組織の準備態勢がコストを上回る制約要因として急速に浮上したことです。3 年前の International Conference of Software Engineering（ICSE）では、多くの企業が LLM を自社のコードに触れさせることは絶対にないと断言していました。しかし、開発者が生産性の向上を実感すると、その姿勢は一変しました。コストよりも意欲が重要であり、適切な足場があれば、より高い品質をより低いコストで実現できると Abhik は付け加えました。 主なポイント：研究は能力を提供しますが、本番環境ではコスト、レイテンシー、品質のバランスを取るアーキテクチャが求められます。そして、そのアーキテクチャこそが実際のエンジニアリングの大部分を占める場所です。 学習と評価：エージェントをより自律的にする ギャップの 2 つ目のレベルは、エージェントが実際に優れているかどうかを知り、時間とともに改善していくことに関するものです。 強化学習は自然な選択だが、アルゴリズムの壁よりもインフラの壁に先にぶつかる。 強化学習は、環境内でアクションを実行するコーディングエージェントの訓練に最適なアプローチであるはずです。しかし実際には、最も困難な問題はエンジニアリングの問題です。Alborz は、エージェントの訓練を完全に強化学習駆動の問題として扱った LinkedIn の経験を述べました。GPU/CPU の利用率がシステム上の課題となりました。ビルドと実行は CPU 負荷が高く、GPU 中心の訓練クラスターとの不均衡が生じます。モデルの並列訓練中にトラジェクトリを収集することで、調整の複雑さが増しました。単純な報酬シグナルは報酬ハッキングを招きました。エージェントは成功したように見せるためにテストを削除することを学習したのです。 さらに、スケーリングを実現するために、LinkedIn は各ポッドをクリーンな状態の仮想マシンとして使用しました。各ステップで完全な git チェックアウトを行う初期設計ではシステムが飽和しました。キャッシュと厳格なアーティファクト管理が不可欠になりました。大規模運用では、約 800 の問題をそれぞれ複数回実行し、オンラインでトラジェクトリを生成しました。Shengyu も Microsoft での同様の経験を述べました。エージェント型強化学習は、長いトラジェクトリと繰り返しのモデル呼び出しにより、補完のための強化学習よりもはるかに困難です。Baptiste も、Mistral で同じパターンが見られたことを確認しました。強化学習環境は事前学習クラスターよりもはるかに多くの CPU を必要とします。 3 つの組織すべてのコンセンサスは次のとおりです。スケーラブルな強化学習環境は、エージェント型 AI に欠けているインフラ層です。現時点では、これはアルゴリズムのフロンティアではなく、エンジニアリング上の制約です。 評価ベンチマークは飽和し、現実から乖離している。 SWE-Bench は 2025 年に評価の主流でしたが、2026 年までに開発者が実際にエージェントを使用する方法と構造的に乖離するようになりました。Alborz は、ベンチマークは通常単一のリポジトリで動作するが、実際の作業は複数のリポジトリにまたがると指摘しました。Abhik は、ほとんどのベンチマークがコードの記述を測定する一方で、コードの読解、意図の理解、影響の分析も同様に重要でありながらほとんど測定されていないと強調しました。Baptiste は、正確性だけではエージェントを差別化できず、指示への追従性と汎化能力が少なくとも同程度に重要だと付け加えました。Omer は、実験室の設定ではなく本番環境の条件に最適化すべきだと主張しました。各企業はプロプライエタリなコードで内部ベンチマークを構築していますが、エージェント評価の共有基準はまだ存在せず、GitHub Copilot のようなデプロイ済みシステムでは、エージェント型ワークロードにはまだクリーンな定量的シグナルがありません。 主なポイント：評価と訓練インフラが 2 つの欠けている層です。ベンチマークは単一リポジトリの正確性を超えて、コード読解、マルチリポジトリワークフロー、指示への追従性を捉える必要があります。スケーラブルな強化学習環境は欠けている訓練層であり、試みたすべてのチームがアルゴリズムの壁ではなく同じエンジニアリングの壁にぶつかっています。 エージェントは単独で動作しない：人間とエージェント間インタラクションの役割 3 つ目のレベルは、エージェントの周辺で何が起こるか、つまり人間がエージェントとどのようにインタラクションし、信頼がどのように構築され、人間の役割がどう変化するかについてです。 レイテンシーと監査可能性が製品を定義する。 Omer は 2 種類のレイテンシーを明確に区別しました。オートコンプリートのレイテンシー（入力中に AI が次の行を提案する際の遅延）は、既存のフローに収まるため、合理的な範囲内であれば許容されます。委任のレイテンシーは根本的に異なります。エージェントにタスク全体を渡し、複数のステップにわたって自律的に作業させる場合、もはやエージェントと並行して入力しているのではなく、ただ待っているだけです。その待ち時間は直ちに監査可能性と結びつきます。ユーザーはエージェントが何をしているのか、行き詰まっていないか、中断できるかを知りたがります。これらの問いが、システムが信頼できると感じられるか不透明に感じられるかを決定します。 品質は正確性だけではない。 Abhik は、あまり注目されていない 2 つの次元で品質を再定義しました。第一に、シグナル対ノイズ比：エージェントは開発者の注意を妨げていないか、それともフィルタリングに労力を要するノイズを生成しているか？10 個の提案のうち 1 つしか有用でないエージェントは、各提案が技術的に正しくても、隠れたコストが発生しています。第二に、説明可能性：エージェントは予想外の判断を正当化できるか？推論が読み取れるものであれば、驚くべき振る舞いも許容されます。この枠組みでは、品質は信頼は切り離せません。 検証は実用的な中間地点に落ち着く。 形式検証はほとんどのシステムにとってまだ手の届かないものです。パネルは実用的な代替案に収束しました。仕様駆動開発（生成されたコードから仕様を抽出し、人間が実装を再確認する必要をなくす）、プロパティベーステスト（モデルはこれらの生成に適しており、実行可能な説明として機能する）、そして AI 支援コードレビュー（AI で AI をガードレールし、人間がビジネスロジックに集中できるようにする）です。 人間の役割は変化しているが、消滅してはいない。 聴衆からの質問が、よくある不安を捉えていました。エージェントがコードの大部分を書くようになったとき、ジュニア開発者はどのように成長すべきか？新たに求められるスキルセットは以下を中心としています。コードの読解とレビュー（書くことよりも重要）、委任（何を自動化し、何に人間の判断が必要かを見極める）、テストと検証（開発者の役割の中心に移行）、そして曖昧さの解消（仕様が不完全な場合に人間が接着剤の役割を果たし続ける）。NUS はすでにこれらの原則に基づいたカリキュラムを構築しています。Alborz の言葉を借りれば、もし自分が学生なら、曖昧さの解消に全力を注ぐだろう、と。そのスキルは抽象化が変わっても価値を持ち続けます。 主なポイント：信頼こそが製品であり、それは監査可能性、シグナル対ノイズの規律、説明可能性によって構築されます。人間の役割は、コードを書くことから、判断し、委任し、エージェントにはできないことを解決することへと移行します。 チームがこれらの課題にどう取り組んでいるかの事例 パネルは純粋に理論的なものではありませんでした。研究と本番環境のギャップを埋めるために、チームがどのように取り組んでいるかについて、いくつかの具体的な事例が紹介されました。 GitHub Copilot のアーキテクチャ専門化。 すべてを 1 つの高価なモデルに通すのではなく、Copilot はコード検索などのタスクに専用のサブエージェントを使用し、強力な推論モデルは複雑な問題に限定しています。これにより、モデルの置き換えではなくシステム設計を通じて、より高い品質をより低いコストで実現しています。 LinkedIn の強化学習インフラ。 大規模な強化学習によるエージェント訓練のために、LinkedIn は各ポッドをクリーンな状態の VM として使用し、積極的なキャッシュとアーティファクト管理を備えた環境を構築しました。各ステップで完全な git チェックアウトを行う初期設計ではスケールできませんでした。最終的なシステムは約 800 の問題でオンラインのトラジェクトリ生成を実行しました。これはアルゴリズムの改善に先立つ、大規模なインフラ投資でした。 Mistral のコンピュートリバランス。 Baptiste のチームは、コードエージェント向けの強化学習環境が事前学習クラスターの設計想定をはるかに超える CPU を必要とすることを発見しました。これをアルゴリズムの問題ではなくインフラの問題として認識したことが、重要な洞察でした。 NUS のカリキュラム再設計。 Abhik のチームは、新しい現実を反映したカリキュラムを構築しています。コード読解をコアスキルとして、エージェントへの委任をコンピテンシーとして、テストを中心に据え、責任ある AI エージェントの使用を必須としています。 ジャッジキャリブレーションのためのペアワイズ比較。 Alborz は、「このコードはあのコードより優れている」というスタイルのデータセット構築を提案しました。作成コストが比較的低く、絶対的な校正が困難な場合でも、ジャッジが信頼性の高い相対ランキングを学習するのに十分です。 AI が AI をレビューする。 Microsoft の Shengyu のチームは、AI 支援コードレビューに取り組む先駆者の一つです。コードレビューエージェントが仕様、要約、意図された動作、テストを使用して一貫性をチェックします。目標は、人間がビジネスロジックに集中し、AI が構造的な検証を担当することです。 現在注目していること：今後の研究の方向性 パネルでは、活発に取り組まれているものの解決にはほど遠い、いくつかのテーマが浮上しました。 スケーラブルな強化学習環境。 これは最も強いコンセンサスポイントでした。エージェント型コーディングに RL を試みたすべてのチームが、同じインフラの壁にぶつかっています。複数のリポジトリ、実際のビルドシステム、現実的な実行環境など、現実世界の多様性を反映した環境を強化学習訓練に必要なスケールで構築することが、欠けている層です。 メタ評価：ジャッジを評価する。 AI ジャッジがコード変更にスコアを付ける場合、そのスコアが信頼できるとどうやって分かるのでしょうか？説明が信頼の次の層として提案されています。システムは信頼性の高いスコアと高品質なコメントの両方を生成し、信頼度の閾値を超えた場合の自動李r−すを実現可能にすべきです。しかし、その信頼性を確立することこそが困難な部分です。 生成されたコードからの仕様抽出。 長期的な目標は、生成されたコードから直接意図を復元し、人間が実装を再確認する必要をなくすことです。これは仕様駆動開発を影響分析（変更がコードベース全体にどのように伝播するかの理解）と結びつけます。 修復ではなく再生成。 コードを安価に再生成できるなら、なぜメンテナンスするのか？これはソフトウェアの寿命、後方互換性、技術的負債についての考え方に深い影響を与える挑戦的なアイデアです。 共有評価基準。 各企業はプロプライエタリなコードで内部ベンチマークを構築していますが、コミュニティにはエージェント型システムを評価するための共有基準がありません。公開ベンチマークは飽和しており、それに代わるものは指示への追従性、汎化能力、コード読解、マルチリポジトリワークフローを捉える必要があります。 カスタマイズ可能なジャッジ。 コードレビューにおいて、組織ごとに重視する点は異なります。重大度、スタイル、順序、見た目の問題など。画一的なジャッジは大規模には機能しません。今後の道筋は、組織のコンテキストに合わせて調整可能なジャッジを必要とします。