本ブログは 2026 年 5 月 20 日に公開された AWS Blog “ Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows ” を翻訳したものです。 エージェントには主体性 (agency) があります。状況に適応し、問題を解決するための複数の方法を見つけ出します。この自律性は、セキュリティ上の根本的な課題を生み出します。エージェントの中核にある大規模言語モデル (LLM) は非決定論的であり、その判断を事前に予測したり保証したりすることはできません。LLM はハルシネーションを起こし、有害なアクションを完全な確信を持って生成してしまうことがあります。また、プロンプトインジェクション攻撃に対して脆弱です。この攻撃では、攻撃者がツールの応答やユーザー入力を通じて悪意のあるコマンドを注入します。LLM はコマンドとデータを確実には区別できません。LLM にとっては、すべてが単なるトークンにすぎないからです。こうした理由から、多層防御を実現するには、セキュリティの観点から LLM を信頼できないアクターとして扱う必要があります。 ここで重要なのは、LLM が外部の世界に直接影響を与えることはできないという点です。LLM は、その出力に基づいてツールを呼び出すオーケストレーターを経由する必要があります。制御を適用すべきなのは、まさにこのポイントです。この境界で必要なのは認可、つまり各ツール呼び出しを許可すべきかどうか、またどのような条件で許可すべきかの判断です。オンライン小売業者のカスタマーサービスエージェントを例に考えてみましょう。適切な制御がなければ、このエージェントは認められた上限を超える返金を処理したり、除外すべき製品カテゴリに割引を適用したり、ある顧客のセッションを処理している最中に別の顧客のデータを参照したりする可能性があります。 エージェントのツールへのアクセスを制御すれば、エージェントが自由に動作できる安全境界 (safety envelope) を確立できます。これは、一般的ではあるものの十分とはいえない次の 2 つのアプローチとは異なります。 ハードコードされたワークフローを作成すると不確実性はなくなりますが、それだけでは、エージェントの頭脳として LLM を使用する意味がなくなります。LLM のインターフェイスを備えた従来型のアプリケーションを構築したことになるからです。さらに、このように制限したとしても、いずれかのステップで LLM の出力を使用すれば、同じリスクが生じる可能性があります。内容が十分に把握されているワークフローには有用な手法ですが、適応が求められるエージェントには十分ではありません。 ヒューマンインザループ (Human-in-the-loop) は重要な操作のセーフティネットとなり、今後も一定の役割を果たし続けます。しかし、これを主要な制御メカニズムとして頼ると、自律性が犠牲になり、承認疲れにつながる可能性があります。 必要なのは、安全かつ自律的なエージェントです。そのためには、エージェントとツールの外部に配置された、監査可能で決定論的な適用レイヤーが必要です。なぜ外部なのでしょうか？信頼できないのは LLM の計画そのものであり、LLM に自身の制約を適用する責任を負わせることはできないからです。システムプロンプトやトレーニング時のアライメントなど、LLM レイヤーでの制御は、プロンプトインジェクションやハルシネーションによって回避される可能性があります。エージェントやツールのコードにハードコードされたチェックはより堅牢ですが、大規模になると監査や管理が難しくなります。特に、セキュリティロジックが多数のツールやサービスに分散している場合はなおさらです。エージェントとツールの両方の外部で認可を一元化すれば、LLM が回避できない単一のチェックポイントを設けられます。このチェックポイントは監査可能であり、アプリケーションコードとは独立して検証できます。 そこで役立つのが AgentCore Policy です。 Amazon Bedrock AgentCore Gateway は、エージェントと、エージェントが呼び出すリモートツールとの間に配置されます。Policy を Gateway に関連付けると、デフォルトですべてがブロックされます。ポリシーは、どのツール呼び出しをどのような条件で許可するかを指定することで、この境界を選択的に開放します。このポリシーの適用対象は、Gateway を経由するすべてのツールトラフィックです。このアプローチをスケールさせるには、エージェントの動作について推論するよりも、ポリシーについて推論する方が容易である必要があります。 AgentCore で使用するポリシーは Cedar で記述します。Cedar は AWS が開発したオープンソースの認可ポリシー言語で、2025 年 12 月に Cloud Native Computing Foundation (CNCF) に参加しました 。Cedar は、まさにこうした特性を備えるように設計されています。認可に特化して構築されており、人間が読みやすく、自動推論を使用して機械で分析できます。これにより、企業はポリシーの定義と適用を AI エージェントにまで拡張できます。 Amazon Bedrock AgentCore における Cedar の活用方法 Amazon Bedrock AgentCore は、エージェントを大規模にデプロイおよび管理するためのインフラストラクチャを提供します。これには、エージェントをホストするための AgentCore Runtime 、Model Context Protocol (MCP) を使用してエージェントがツールに接続する方法を管理するための AgentCore Gateway 、そして AgentCore Policy が含まれます。Policy は、AgentCore Gateway を経由するすべてのエージェントトラフィックをインターセプトし、ツールへのアクセスを許可する前に、ポリシーエンジンで定義されたポリシーに照らして各リクエストを評価します。このポリシーレイヤーを支えているのが Cedar です。 AgentCore Policy は、AgentCore Gateway のワークフロー内の複数の段階で、Cedar とその数学的分析機能を使用します。Cedar 認可エンジンはポリシーの評価時に使用され、 Cedar Analysis はポリシーの作成時とコントロールプレーンで使用されます。 ポリシー作成 : 開発者は、Cedar ポリシーを直接記述することも、自然言語で記述して ニューロシンボリック AI のフィードバックループで Cedar に変換することもできます。ニューロシンボリック AI は、機械学習の柔軟性と、自動推論の証明可能な正しさを組み合わせたものです。LLM が自然言語からポリシーを生成し、Cedar Analysis がシンボリックかつ数学的な推論を使用してそれらを検証します。次の図は、このワークフローを示しています。 図 1: Cedar ポリシー生成のワークフロー 管理者は、エージェントがどの MCP ツールをどのような条件で呼び出せるかを自然言語で指定します。次に、ニューロシンボリックなフィードバックループがこの記述を Cedar ポリシーとして形式化します。仕組みは次のとおりです。まず、LLM が自然言語を Cedar ポリシーに変換します。次に、これらのポリシーに対して 2 段階の検証が実行されます。第 1 段階では、AgentCore Policy が Cedar の スキーマジェネレーター を使用します。このジェネレーターは MCP ツールの説明を受け取り、Cedar スキーマを生成します。Cedar はこのスキーマに照らしてポリシーを検証します。これにより、ポリシーが有効なツールとパラメータを参照していることを確認するとともに、さまざまな種類のランタイムエラーをまとめて排除できます。検証に合格すると、第 2 段階で Cedar Analysis が実行されます。Cedar Analysis は各ポリシーを数式としてエンコードし、すべてを許可または拒否するポリシーや、成立し得ない条件を含むポリシーなどの問題を検出します。こうした数学的証明によって、自然言語の記述から Cedar ポリシーへの変換プロセスで生じたエラーが特定され、修正の方向性が示されます。 ニューロシンボリックなフィードバックループにより、生成されるポリシーの精度が大幅に向上します。これは、ニューラルアプローチとシンボリックアプローチを組み合わせることの威力を示しています。LLM は自然言語からの創造的な変換を担い、自動推論は厳密な検証を担います。 コントロールプレーン : ポリシーを AgentCore Gateway にアタッチする際、Cedar Analysis はポリシーセット全体を包括的に分析します。ポリシーを個別に分析するのではなく、ポリシーどうしがどのように相互作用するか、またそれらを組み合わせた場合の効果を調べます。この分析により、競合するポリシーや冗長なポリシーなどの潜在的な論理エラーが特定され、ポリシーセットが意図しない認可結果を生み出すかどうかが検出されます。Cedar Analysis がこれらのエラーを検出すると、操作は失敗して問題の説明が返されるため、ポリシー作成者は修正して再試行できます。チェックの例については、「 ポリシー検証のための形式的分析 」セクションを参照してください。 MCP ツール呼び出しへのポリシー適用 : AgentCore Gateway に送信されるエージェントの各ツールリクエストは、Cedar ポリシーに照らして評価され、指定された引数による MCP ツール呼び出しを許可すべきかどうかが判断されます。これにより、安全境界を形成しつつ、エージェントが業務を遂行するために必要な経路を開放します。 MCP ツールのフィルタリング : Cedar は、ツール呼び出しが発生する前の段階で機能する追加の保護レイヤーも実現します。エージェントがツール一覧の取得コマンドを発行すると、AgentCore Gateway は Cedar の 部分評価 機能を使用して、現在のポリシーセットのもとで常に拒否されるアクションを判断します。それらのアクションは、ツール一覧のレスポンスから除外されます。エージェントとその基盤となる LLM がそれらのツールアクションを目にすることはないため、ある種類のリスクを完全に排除できます。エージェントと LLM は、存在を知らないツールを呼び出そうとすることができないからです。これは Cedar の部分評価がもたらす直接的なメリットです。実際のツール呼び出しの試行を待たなくても、特定のツールアクションに到達できないことをシステムが判断できます。 なぜ Cedar なのか: 分析可能性が大規模環境での安全性を実現する 自然言語は、セキュリティが重要なインフラストラクチャで使用するにはあいまいすぎます。一方、Python などの汎用プログラミング言語は非常に表現力が高いものの、分析が困難すぎます。意図しない副作用や停止性の問題が生じる可能性があり、理解するのも難しい場合があります。 Cedar は、ループやステートフルな操作を排除することでこれらの問題を回避しています。そのため、一般的なケースではポリシー評価が O(n) 時間で終了します。このように実行時間に上限があるため、エージェントはユーザーエクスペリエンスやワークフローの効率を損なうことなく認可の判断を行えます。 Cedar は読みやすい言語です。規制コンプライアンスやセキュリティ監査では、人間が理解して検証できるポリシーが求められます。Cedar ポリシーは構造化された自然言語のように読めるため、セキュリティチーム、コンプライアンス担当者、ビジネスステークホルダーにとっても理解しやすくなっています。 // Only allow bulk discounts for premium customers with sufficient quantity permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ApplyBulkDiscount", resource ) when { principal.hasTag("customer_tier") && principal.getTag("customer_tier") == "Platinum" && context.input.orderQuantity >= 50 } unless { context.input .productTypes .containsAny ( ["limited_edition", "seasonal_specials"] ) }; 技術的なバックグラウンドを持たない監査担当者でも、このポリシーは理解できます。「50 個以上注文するプラチナ顧客には大量購入割引を許可する。ただし、限定版または季節限定の特別製品は除く」という意味です。 unless 句によって例外が明確になります。これは、ビジネスルールを自然言語で表現する際の一般的な書き方と同じです。この 1 つのポリシーが、2 つの異なるデータソースを制約している点に注目してください。顧客ティアは JSON Web Token (JWT) のクレームから取得されるため、LLM によるハルシネーションや改ざんの影響を受けません。一方、注文数量や製品タイプなどのツール入力は、LLM のツール呼び出しに由来します。Cedar ポリシーはこれらの入力を許可された値のみに制約するため、LLM が予期しない引数を生成した場合でも、ポリシーの適用レイヤーによって決定論的に拒否されます。 Cedar が適切な選択肢である理由は、高速で、読みやすく、自動推論によって 分析可能 だからです。この分析可能性があるからこそ、Cedar ポリシーとして表現されたエージェントの安全境界について推論できるのです。エージェンティックシステムが成長するにつれて、ツールの数も増えていきます。適切な管理ツールがなければ、ポリシー管理は手に負えなくなります。ポリシーが競合したり、セキュリティ上のギャップが生じたり、意図しない認可結果が生まれたりする可能性があります。 このセクションの残りの部分では、Cedar の分析可能性が、決定論的かつ数学的に健全な分析によって、この課題にどのように直接対処するかを見ていきます。Cedar の分析は大規模なポリシーセット全体にわたって競合や論理エラーを確実に検出できるため、ニューロシンボリック AI によるスケーラブルなポリシー管理が可能になります。 ポリシー検証のための形式的分析 Cedar ポリシーは、 シンボリックエンコーダーを通じて 数式にエンコードし、自動推論の手法で分析できます。これにより、AgentCore Policy は、ポリシーの作成時をはじめとするさまざまな場面で、高度なポリシー検証機能を提供できます。AgentCore Policy はポリシーの作成時やアタッチ時にこの分析を使用して、競合するポリシーや冗長なポリシーなどの論理エラーの可能性を検出します。ポリシー比較を含むポリシー分析は、オープンソースの CLI ツール として利用できます。ここからは、これらのチェックの具体例をいくつか見ていきましょう。 ポリシーの論理エラーの検出 : Cedar Analysis は、ポリシーに含まれる論理エラーを検出できます。例えば、次のポリシーには矛盾する制約があるため、どのリクエストも許可できません。顧客ティアが同時にゴールドとプラチナの両方になることはあり得ないからです。本来は || を使う意図でしたが、誤って && が使われています。このような間違いは、ポリシーを作成する人間と AI システムのどちらにも起こり得ます。 // This policy cannot allow any requests due to logical errors permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ProcessRefund", resource ) when { principal.hasTag("customer_tier") && principal.getTag("customer_tier") == "Gold" && principal.getTag("customer_tier") == "Platinum" } unless { context.input.refundAmount > 1000 }; 同様に、Cedar Analysis は、特定のアクションを常に許可するポリシーも検出できます。このようなポリシーは、通常、許可範囲が広すぎることを示しています。例えば、次のポリシーはすべての ApplyBulkDiscount リクエストを許可します。どのような注文数量であっても、100 以上か 100 未満のいずれかに該当するからです。 // This policy allows all ApplyBulkDiscount requests permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ApplyBulkDiscount", resource ) when { context.input.orderQuantity >= 100 || context.input.orderQuantity < 100 || (principal.hasTag("customer_tier") && principal.getTag("customer_tier") == "Platinum") }; このような論理エラーを人間が見つけるのは容易ではなく、パターンマッチングで検出することもできません。数学的分析による形式的な厳密さが必要であり、それこそが Cedar Analysis の役割です。 ポリシーの競合の検出 : Cedar Analysis は、ポリシーセット全体を分析して、個々のポリシー間の不整合を検出することもできます。 // These policies conflict - Analysis will detect the subtle issue permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ProcessRefund", resource ) when { principal.hasTag("customer_tier") && principal.getTag("customer_tier") == "Gold" && context.input.refundAmount < 100 }; forbid ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ProcessRefund", resource ) when { principal.hasTag("customer_tier") && ["Gold", "Platinum"].contains(principal.getTag("customer_tier")) && context.input.refundAmount < 500 }; permit ポリシーはゴールド顧客に対して 100 USD 未満の返金処理を許可していますが、forbid ポリシーはゴールド顧客 (およびプラチナ顧客) による 500 USD 未満の返金処理をブロックしています。Cedar では forbid が permit より優先されるため、permit ポリシーがあるにもかかわらず、forbid ポリシーによってゴールド顧客の返金はすべてブロックされます。 ポリシー変更の比較 : ポリシーを更新する際、Cedar Analysis は変更による正確な影響を判断することもできます。unless 句に対する次の更新を考えてみましょう ( + の付いた行は追加された行、 - の付いた行は削除された行です)。更新後は、 ApplyBulkDiscount がブロックされるのは、数量が 200 を超え、 かつ 製品タイプが limited_edition の場合のみです。 permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ProcessRefund", resource ) when { context.input.refundAmount < 500 }; permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ApplyBulkDiscount", resource ) when { context.input.orderQuantity >= 50 } unless { - context.input.productTypes.containsAny(["limited_edition"]) + context.input.productTypes.containsAny(["limited_edition"]) && + context.input.orderQuantity > 200 }; 一見すると、unless 句に条件を追加すれば、制限がより厳しくなるように思えるかもしれません。しかし、実際にはその逆です。unless が適用される範囲が狭まるため、permit が対象とするリクエストは増えることになります。例えば、 limited_edition 製品を 73 個注文した場合、更新前はブロックされていましたが、更新後は許可されます。Cedar Analysis はこれを自動的に検出し、元のポリシーセットと更新後のポリシーセットの許可範囲の違いを示す次の表を生成します。 プリンシパルタイプ アクション リソースタイプ ステータス OAuthUser ProcessRefund Gateway 同等 (Equivalent) OAuthUser ApplyBulkDiscount Gateway 許可範囲が拡大 (More permissive) この分析結果から、更新後のポリシーは ProcessRefund リクエストについては以前とまったく同じ範囲を許可する一方で、 ApplyBulkDiscount リクエストについてはより多くを許可することがわかります。 エージェントが自律的に動作し、現実世界に影響を与える可能性がある場合、このような形式的検証の機能は不可欠です。組織には、ポリシーが意図したとおりに動作するという数学的な確実性が必要です。 信頼性の高いガバナンスを実現する決定論的な動作 確率的な AI モデルとは異なり、エンタープライズセキュリティには決定論的な保証が必要です。Cedar ポリシーは、評価順序やシステムの状態にかかわらず、同一のリクエストに対して常に同じ認可の判断を下します。Cedar の 「デフォルトで拒否する」「forbid が優先される」「評価順序に依存しない」 というセマンティクスは、予測可能な動作の確保に役立ちます。 // Policy evaluation order does not affect the authorization decision permit( principal, action == AgentCore::Action::"ProcessRefund", resource ) when { context.input.refundAmount < 500 }; forbid( principal, action == AgentCore::Action::"ProcessRefund", resource ) when { context.input.orderDate.offset(duration("90d")) < context.system.now }; permit ポリシーと forbid ポリシーのどちらが先に評価されても、500 USD を超える返金リクエストは常に拒否され、注文日から 90 日を過ぎて行われる返金も拒否されます。この予測可能性があるからこそ、企業は安心してエージェントのガバナンスを行えます。 ポリシーから本番環境へ AgentCore Policy と Cedar を選択すれば、組織は、エージェントが正しく動作することをただ期待するのではなく、数学的に推論できるポリシーを備えた自律型エージェントをデプロイできます。Cedar は表現力、可読性、形式的検証を兼ね備えているため、動作に必要な柔軟性と、セキュリティチームが求める確実性の両方を備えたエージェントを設計できます。 自動推論 は、アクセスポリシーを検証する AWS IAM Access Analyzer から、 ネットワーク設定 の証明可能なセキュリティに至るまで、AWS 全体で既にその価値を実証しています。同じ手法をエージェンティック AI に適用するのは自然な流れです。エージェントが担う責任が大きくなるにつれて、数学的な根拠に基づく保証の必要性は高まる一方です。この記事で説明したニューロシンボリックなアプローチは、LLM の柔軟性と自動推論の厳密さを組み合わせたものです。このアプローチは、検証が自律性と歩調を合わせて進むことで、エージェントがより自律的であると同時に、より信頼できる存在になる未来を示しています。 詳細情報 Policy は現在、 Amazon Bedrock AgentCore Gateway の一部として利用できます。Cedar とその機能の詳細については、 Cedar ウェブサイト にアクセスするか、 Cedar プレイグラウンド をお試しください。また、Cedar コミュニティには Slack から参加できます。 Amazon Bedrock AgentCore Gateway の Policy の詳細については、 AWS ドキュメント を参照するか、 AgentCore Gateway コンソール をご確認ください。 Liana Hadarean Liana は AWS の Principal Applied Scientist です。Amazon Q の Java セキュリティディテクターを支えるコード分析ツールの開発に携わり、現在は Cedar ポリシー言語のコントリビューターを務めています。 Jean-Baptiste Tristan Jean-Baptiste は AWS Agentic AI の Senior Principal Applied Scientist で、ニューロシンボリック AI とエージェントの安全性に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

完成品を扱う小売企業は、今日のダイナミックな市場において、利益率を守りながら競争力のある価格を維持するという高まる圧力に直面しています。従来の価格モニタリング手法は、ベンダーごとに異なる製品識別方法や、デジタルプラットフォーム上に存在する膨大な量の価格データを扱う際には力不足です。 複数チャネルで完成品を販売する小売企業は、自社の価格モデルについて十分な情報に基づいた意思決定を行うために、競合の価格戦略を包括的に可視化する必要があります。こうした企業は一般に、時間がかかり、ミスが起きやすく、競争上のポジショニングに必要なリアルタイムのインサイトを提供できない手作業の価格モニタリングプロセスに苦労しています。 自動化された価格追跡機能がなければ、こうした組織は、市場の変化により迅速に対応できる競合にマーケットシェアを奪われるリスクを抱えます。 本ブログ記事では、SAP のマテリアルマスターデータ抽出と生成AIを組み合わせ、SAP 小売業のお客様向けに最適化されたスマートで自動化された価格モニタリングシステムを構築するソリューションをご紹介します。このシステムが SAP から製品情報を取得し、AI エージェントを送り出してオンラインマーケットプレイスの価格やお客様のセンチメントをスキャンし、その結果を SAP に戻してアクションにつなげる仕組みを、最小限の手作業でどのように実現するかをご覧いただけます。アーキテクチャを順を追って説明し、Amazon Bedrock Agents と AWS のサービスがどのようにエージェント型ワークフローを支えるかを解説するとともに、統合・コスト・実装に関する実践的な考慮事項を共有します。これにより、皆さまの組織でこのアプローチを評価できるようになります。 ビジネス価値: 本ソリューションは、価格インテリジェンスの向上と市場対応の迅速化を通じて、小売企業に具体的なメリットをもたらします。組織は一般に、リアルタイムの競合データによって実現される、より優れた価格意思決定を通じて利益率の改善を実感します。システムが自動化されていることで手作業のモニタリング負荷が軽減され、価格担当チームはデータ収集ではなく戦略的な分析に集中できるようになります。 さらに、価格トレンドや地域ごとの差異を特定できる本システムの能力により、小売業者はプロモーション戦略や在庫管理の意思決定を最適化でき、在庫回転率の向上と値下げの削減につながります。 アーキテクチャ: 主要コンポーネント&nbsp; SAP データと AWS の接続&nbsp; エージェントが SAP データを扱えるようにするには、まずそのデータを AWS へ、セキュアかつ SAP のライセンスおよびガバナンスのルールに沿った形で取り込む必要があります。そのための現代的な方法が SAP Business Data Cloud (SAP BDC) であり、SAP データをあちこちにコピーすることなく AWS と共有します。 SAP SAPPHIRE 2026 において、 SAP と AWS は SAP BDC Connect for Amazon Athena を発表しました 。これは SAP Business Data Cloud と Amazon Athena の間の双方向・ゼロコピー統合です。データを抽出して複製するのではなく、チームはセマンティックにリッチな SAP データ製品をその場で、ほぼリアルタイムにクエリできます。データは本来のビジネス上の意味を保持し、SAP のガバナンスに準拠したまま、エージェントがスキャンや分析を行えるように Amazon S3 バケットに配置することも可能です。 このフローは、SAP BDC のデータファブリックである SAP Datasphere を経由して実行されます。ここから、非SAPデータおよびSAPデータをライブで Amazon Athena にフェデレーション（コピーなし）したり、大規模データセットの下流処理のために保存されたコピーが必要な場合には Amazon S3 に書き込んだりできます。 その他の SAP データ抽出オプションとして、OData/CDS ビューを用いた AWS Glue、パートナーツール (BryteFlow、Theobald、Qlik)、SAP ネイティブの SLT/Data Services などがあり、SAP データの抽出が必要なシナリオで利用できます。AWS の SAP Data Integration Guidance および SAP BDC と AWS データソースの統合 をご参照ください。 エージェント型ワークフロー エージェント型ワークフローは、Amazon ECS Fargate を使用してコンテナ化された AI エージェントをデプロイし、Amazon Bedrock の基盤モデルを用いて複数のオンラインマーケットプレイス上の製品価格を自律的に分析します。 ワークフローはどのように動作するのでしょうか。 ステップ 1: BDC データ抽出 ステップ 2: EAN コードと説明を含む製品 CSV ファイルが SapLake S3 バケットにアップロードされ、価格モニタリングワークフローがトリガーされます。 ワークフローの起動 製品情報を含む CSV ファイルが Amazon S3 にアップロードされると、Amazon EventBridge が AWS Step Functions ワークフローをトリガーします。Step Functions のステートマシンが、データ抽出から結果集約まで、価格モニタリングプロセス全体をオーケストレーションします。S3 でのトリガー設定に関する追加情報はこちらをご参照ください。 タスクのディスパッチ ステップ 3: Lambda 関数 (search-and-dispatch.py) が CSV ファイルを処理し、各製品についてインターネット検索を実行し、マーケットプレイス分析のための ECS タスクをディスパッチします。 AWS Step Functions は Map ステート を使用して複数の製品を同時に処理します。マーケットプレイスのレート制限を尊重するため、同時実行数は3エージェントに制御されています。各製品は、対象マーケットプレイスの URL、製品 EAN コード、説明、実行トラッキング ID などの特定の環境変数を伴う個別の ECS Fargate タスクをトリガーします。 エージェントの実行 ステップ 4: ECS Fargate タスクは、Amazon Bedrock と MCP サーバーを使用してコンテナ化された Strands Agents を実行し、複数のオンラインマーケットプレイス上の製品価格を分析します。 各 ECS タスクは、最適なコストパフォーマンスを実現する ARM64 アーキテクチャ上で、2GB メモリと 1 vCPU で構成されたコンテナ化 AI エージェントを実行します。エージェントは Claude、Titan、Nova を含む Amazon Bedrock の基盤 モデルにアクセスでき、包括的なマーケットプレイス分析のために10分の実行タイムアウトが設定されています。 Amazon Strands SDK が AI の推論をオーケストレーションし、Model Context Protocol サーバーが Bedrock モデルと Playwright によるブラウザ自動化を橋渡しします。このアーキテクチャにより、エージェントは異なるマーケットプレイスのレイアウトにわたる複数ステップのナビゲーション戦略を計画し、動的なコンテンツやアンチボット対策に自動的に適応し、複雑なウェブ操作全体を通じてコンテキストを維持しながら AI モデルを用いて価格要素を特定できます。 ステップ 5: エージェントワークフローは、Strands のプランニングと Playwright 実行のための MCP ツールを組み合わせ、従来のウェブスクレイピングを、現代の e コマースプラットフォームの複雑さと変動性に対応できるインテリジェントで適応的な市場調査へと変革します。 ステップ 6: 各エージェントは、リアルタイムのトラッキングと中間処理ステータスの更新のために、価格分析結果を DynamoDB に保存します。 ステップ 7: Lambda 関数 (aggregate-results.py) が、DynamoDB からのすべてのエージェント結果を包括的な価格レポートに統合します。 ステップ 8: 集約された価格分析および市場インテリジェンスレポートは、さらなる分析と SAP 統合のために S3 に保存されます。 インテリジェントな分析プロセス AI エージェントは高度な分析を実行します。 ウェブナビゲーション: ブラウザ自動化が動的コンテンツを処理します 製品マッチング: Bedrock の基盤モデルが EAN コードと説明を用いて一致する製品を特定します 価格抽出: さまざまなマーケットプレイス形式から価格情報を抽出します センチメント分析: 基盤モデルがお客様のレビューや市場でのポジショニングを分析します 結果の保存: 構造化データが信頼度スコアとともに Amazon DynamoDB に書き込まれます エラー処理とレジリエンス このワークフローには、一時的な障害に対するエクスポネンシャルバックオフを伴う自動リトライロジックが含まれています。失敗したタスクは詳細なエラーコンテキストとともにログに記録され、部分的な結果は デバッグとリカバリのために DynamoDB に保持されます。 ステップ 9: さらなる分析のために、Cloud Connector を使用して SAP に統合し戻します。 Cloud Connector を用いた BTP Integration Suite この統合では、AWS サービスと SAP システムをセキュアに接続する主要な手段として、SAP Business Technology Platform (BTP) の Integration Suite を活用します。SAP Cloud Connector はセキュアなリバースプロキシとして機能し、オンプレミスまたはクラウドの SAP システムが、内部システムをインターネットに直接さらすことなく SAP BTP 上のクラウドアプリケーションと通信できるようにします。このアプローチにより、AWS と SAP 環境間のシームレスなデータフローを実現しつつ、セキュリティ境界を維持します。 価格分析が完了して結果が S3 に保存されると、BTP Integration Suite は事前構成された統合フローを通じてデータ取得プロセスをオーケストレーションします。これらのフローは、保存された認証情報を用いて AWS に認証し、S3 から価格分析データを取得し、SAP で利用できる適切な形式に変換します。続いて Integration Suite は、SAP システム内のマテリアルマスターレコード、価格条件、その他の関連するビジネスオブジェクトを更新し、リアルタイムの市場インテリジェンスに基づくデータドリブンな価格意思決定を可能にします。 Cloud Connector は、BTP とオンプレミス SAP システムの間に暗号化されたトンネルを確立することで、すべての通信のセキュリティを確保します。一方、Integration Suite は信頼性の高いデータ処理のための監視、エラー処理、リトライ機構を提供します。このアーキテクチャにより、組織は既存の SAP セキュリティポリシーを維持しながら、クラウドベースの AI 機能の恩恵を受けることができます。 代替アプローチとして、組織は EventBridge 通知と ABAP SDK for AWS を組み合わせた直接統合を実装できます。これは、よりシンプルなデプロイシナリオ向けに、SAP システム内でネイティブな AWS サービス統合を直接提供します。 ABAP SDK アプローチの主な利点: ネイティブ統合: カスタムの HTTP 処理や JSON パースライブラリが不要 自動認証: SDK が AWS Signature V4 認証を自動的に処理 エラー処理: 組み込みの AWS エラー処理とリトライ機構 コードの簡素化: カスタム HTTP 呼び出しと比較して統合コードを約70%削減 SAP サポート: SAP により公式にサポートされ、将来のリリースとの互換性を確保 更新されたアーキテクチャの利点 依存関係の削減: カスタム REST クライアントや JSON ライブラリが不要 パフォーマンスの向上: ネイティブ SDK による最適化された AWS API 呼び出し メンテナンスの容易化: 標準的な SAP 開発パターン セキュリティの強化: SDK が SAP のセキュアストアを通じて認証情報を管理 このアプローチは統合を標準的な ABAP 開発タスクへと変え、オブジェクト指向 ABAP プログラミングに精通した SAP 開発者であれば誰でも扱えるようにします。 実装のベストプラクティス&nbsp; エラー処理&nbsp; SAP 接続に対する堅牢なエラー処理を実装する ウェブサイトの構造変更を適切に処理する エージェントの障害を監視・ログ記録する パフォーマンス最適化 頻繁にアクセスするデータにはキャッシュを使用する エージェントの並列処理を実装する コンプライアンスと倫理 robots.txt とクローリングポリシーを尊重する リクエスト間に適切な遅延を設ける 公開されている情報のみを保存する 実装のベストプラクティス エラー処理 堅牢なエラー処理は、信頼性の高い価格モニタリングシステムの基盤を成すものであり、特に複数の外部システムを統合する際の複雑さを考えると重要です。SAP 接続エラーは、ネットワークタイムアウト、認証失敗、システムメンテナンスウィンドウなどにより発生する可能性があり、障害を防ぐためにバックオフリトライ機構やサーキットブレーカーパターンの実装が必要となります。ウェブサイトの構造変更もまた重要な課題です。e コマースプラットフォームは頻繁にレイアウトや HTML 構造を更新するため、従来のウェブスクレイピング手法が機能しなくなる可能性があります。本ソリューションは、固定的な CSS セレクターや XPath 式に依存するのではなく、コンテンツをセマンティックに理解することで構造変更に適応できる生成AIモデルを活用することで、この課題に対処します。エージェント障害の包括的なログ記録と監視により、問題の迅速な特定が可能になり、システム最適化のための貴重なインサイトが得られます。また、自動アラートにより、重大な障害が運用チームの迅速な対応を受けられるようにします。 パフォーマンス最適化&nbsp; 効果的なパフォーマンス最適化は、システムコストとユーザーエクスペリエンスの双方に直接影響するため、本番環境へのデプロイには不可欠です。製品カタログやマーケットプレイスのレイアウトなど、頻繁にアクセスするデータをキャッシュすることで、冗長な API 呼び出しを削減し、応答時間を改善するとともに、繰り返しのデータ取得操作に伴うコストを最小化できます。このアプローチは、変更頻度は低いものの価格分析ワークフロー中に繰り返しアクセスされる SAP マテリアルマスターデータにおいて特に有効です。エージェントの並列処理は、複数の製品を異なるマーケットプレイスにわたって同時に分析できるようにすることでスループットを最大化し、包括的な価格モニタリングサイクルに必要な総時間を大幅に短縮します。制御された同時実行アプローチは、対象ウェブサイトへの過負荷を防ぎつつリソース利用を最適化し、製品カタログの拡大に応じてシステムが効率的にスケールできるようにします。 コンプライアンスと倫理&nbsp; 倫理的なウェブスクレイピングの実践は、組織と対象ウェブサイトの双方を保護しつつ、持続可能な長期運用を確保します。robots.txt ファイルやクローリングポリシーを尊重することは、良好なデジタルシチズンシップを示すとともに、IP ブロックやマーケットプレイス運営者からの法的な問題のリスクを低減します。リクエスト間に適切な遅延を設けることで、対象サーバーへの過負荷を防ぎ、人間のブラウジングパターンを模倣することで、データ収集活動を妨げかねないアンチボット対策を発動させる可能性を減らします。公開されている情報のみを保存することで、データ保護規制へのコンプライアンスを確保し、倫理的な境界を維持するとともに、ストレージコストの削減とデータガバナンス要件の簡素化にもつながります。これらの実践は、マーケットプレイスパートナーとの信頼を築き、将来の API パートナーシップやデータ共有契約の基盤を形成します。 コストに関する考慮事項 この SAP 価格モニタリングソリューションを実装するには、次の主要なコスト要因を考慮する必要があります。 主なコスト要素: コンピューティング時間 (ECS Fargate の vCPU およびメモリ時間) 関数の呼び出し回数と実行時間 (Lambda の GB 秒) ワークフローの実行とステート遷移 (Step Functions) データストレージと API リクエスト (DynamoDB および S3) データ抽出と処理 (AWS Glue) システムアーキテクチャの前提: 月間1,000件の CSV ファイルアップロード (ワークフロー実行1回につき1件) マーケットプレイス分析用の10,000件の ECS Fargate タスク (各10分、1 vCPU、2GB ARM64) 2,000回の Lambda 関数呼び出し (ワークフローごとに search-and-dispatch + aggregate-results) 平均15回のステート遷移を伴う1,000件の Step Functions 実行 CSV ファイルを処理する1,000件の AWS Glue ETL ジョブ (各5分、1 DPU) 月間50,000件の DynamoDB 書き込みリクエストと25,000件の読み取りリクエスト 月間15,000件の API リクエストを伴う5GB の S3 ストレージ 月間11,000件の EventBridge カスタムイベント 詳細なコスト内訳 (無料利用枠なし): Amazon ECS Fargate の料金は こちら に記載されています。ARM64 アーキテクチャの場合: vCPU 時間あたり $0.03238、GB 時間あたり $0.00356。月間10,000件のタスク が各10分実行される場合: 1,666.67 vCPU 時間と 3,333.33 GB 時間 = 月額 $65.83。 AWS Lambda の料金は こちら に記載されています。月間2,000回の呼び出しと30,000 GB 秒 = 月額 $0.50。 AWS Step Functions の料金は こちら に記載されています。1,000回の実行 × 15回の遷移 = 15,000回の遷移 = 月額 $0.38。 Amazon DynamoDB の料金は こちら に記載されています。月間50,000件の書き込みと25,000件の読み取り = 月額 $0.07。 Amazon S3 の料金は こちら に記載されています。5GB のストレージと15,000件の API リクエスト (10,000 PUT、5,000 GET) = 月額 $0.12。 AWS Glue の料金は こちら に記載されています。各5分実行の1,000件の抽出ジョブ (月間83.33 DPU 時間) と仮定 = 月額 $36.67。 Amazon EventBridge の料金は こちら に記載されています。月間11,000件のイベント (1,000件のワークフロー + 10,000件のタスク完了) = 月額 $0.01。 月額総コストの見積もり 1,000件のワークフロー実行にわたって10,000件の URL を処理する場合: ECS Fargate (ARM64) = $65.83 Lambda 関数 = $0.50 Step Functions = $0.38 DynamoDB = $0.07 S3 ストレージ = $0.12 AWS Glue = $36.67 EventBridge = $0.01 推定月額総コスト = $103.58 コスト最適化のオプション Fargate Spot インスタンス: 最大70%の割引により、Fargate コストを約 $19.75 に削減 リザーブドキャパシティ: DynamoDB やその他のサービスでリザーブド料金を提供 S3 Intelligent-Tiering: アクセス頻度の低いデータの自動コスト最適化 Glue ジョブの最適化: DPU 割り当てとジョブ実行時間の適正化 Fargate Spot 料金を利用した場合: 月額合計 $57.50 まとめ 本システムは、複数のオンラインマーケットプレイスにわたる完成品の包括的な価格モニタリング、価格変動の自動トレンド分析、比較可能な製品のインテリジェントな特定を提供し、お客様のセンチメントデータと価格の有効性を相関付けることで、より深い市場インサイトを提供します。 このインテリジェンスにより、小売業界の SAP のお客様は、データドリブンな価格意思決定を行い、競争上の脅威に迅速に対応し、ますますダイナミックになる小売環境において市場でのポジションを維持できるようになります。 Strands Agents と AWS のサービスは、インテリジェントな価格モニタリングシステムを構築するための強力なプラットフォームを提供します。SAP データ抽出とエージェント型 AI 機能を組み合わせることで、組織は市場でのポジショニングや競争力のある価格戦略に関する貴重なインサイトを得ることができます。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

はじめに こんにちは。2026年4月にInsight Edge（以下、IE）へデータサイエンティストとして新卒入社した田中です。 本記事を執筆している2026年9月時点で、入社から約5か月が経ちました。新卒データサイエンティスト（DS）の2期生として、新卒研修から最初の案件への参画までを経験する中で、入社前には見えていなかったIEの特徴が少しずつ分かってきました。本記事では、実際に働いて感じたことを新卒の視点からお伝えします。 IEへの新卒入社を検討している学生の方はもちろん、商社グループでデータサイエンティストとして働くことに興味がある方にとっても、本記事が参考になれば幸いです。 目次 1. 自己紹介とIEを知ったきっかけ 1.1 大学での研究 1.2 IEを知ったきっかけ 2. 新卒でInsight Edgeに入社した理由 2.1 幅広い事業領域と少数チームの機動力 2.2 メンターから感じた高い技術力と温かい人柄 2.3 学び続けながら柔軟に働ける環境 3. 入社して初めて分かった3つのこと 3.1 分野横断の研修と早期の案件配属 3.2 オフィスで実感した住友商事との距離の近さ 3.3 案件外の活動を通じた学びと交流 4. まとめ 1. 自己紹介とIEを知ったきっかけ まずは自己紹介として、学生時代のバックグラウンドとIEを知ったきっかけについて紹介します。 1.1 大学での研究 大学時代は、経営工学を専攻しており、さまざまな産業領域のテキスト・表・画像・動画データから知識抽出をすることに焦点を当てた研究分野と、自動運転を中心とする強化学習の応用研究の両方を専門とする研究室に所属していました。当時は25人ほどいた学生のうち6〜7割が留学生で、ミーティングは常に英語で行われる国際色豊かな環境でした。 修士の頃は、産総研との共同研究として、スポーツの試合から収集したプレーデータや映像をもとに、テキスト速報や実況・解説を生成する応用研究に取り組んでいました。 1.2 IEを知ったきっかけ IEを知ったきっかけは、修士1年の夏に受講した大学のデータサイエンス講義です。毎回異なる企業が登壇し、さまざまなデジタル活用事例を紹介する講義でした。ある回にIEの社員が登壇し、そこで初めてIEを知りました。 講義では、IEが住友商事グループ内のDX推進を担っている会社であることが紹介されていました。また、案件としては商社ならではの幅広い産業分野を扱い、その中でPoCからプロダクト開発までを内製の少人数のチームで進めていることも知りました。 講義を通じて、私はIEに次のような魅力を感じました。 さまざまな事業領域に触れられそうで、面白そう 海外案件に関わり、研究室で英語を使ってきた経験も生かせそう 優秀な技術者と働きながら、若いうちから裁量を持って成長できそう いずれも自分の就職活動の軸と合っていたため、講義の最後に案内されたインターンシップへの応募を決めました。 その後、面接を経て、2024年夏の1か月間のインターンシップに参加しました。このインターンシップは、講義だけでは分からなかったIEの詳しい仕事内容や組織体制などを、より深く知る機会になりました。その内容については次の章で詳しく説明していきます。 また、インターンシップで取り組んだ内容は、 こちらの記事 で紹介していますので、興味のある方はぜひこちらもご覧ください。 2. 新卒でInsight Edgeに入社した理由 本章では、インターンシップでの経験を踏まえた、私がIEへの入社を決めた理由について、3つ紹介します。 2.1 幅広い事業領域と少数チームの機動力 IEは住友商事グループの内製的なパートナーとして、コーポレートや、グループ内の事業会社の方々と目標を共有しながらプロジェクトに取り組みます。案件によっては、提示された要件を実装するだけでなく、課題がまだ明確になっていない段階から議論し、PoCや開発、現場での活用まで継続して関わります。IEがデータやAIに関する知見を提供する一方で、クライアントからは業務や事業について学び、双方の知見を持ち寄って解決策を考えられることに、内製パートナーならではの健全な関係性を感じました。 また、住友商事グループには多様な事業会社があり、海外案件を含むさまざまな業界の事業や課題に触れられることも魅力でした。IEは、住友商事グループの幅広い事業基盤をフィールドとしつつ、比較的少人数でのプロジェクトを進めます。新しい技術を積極的に取り入れ、まずは自分たちで検証してみるという姿勢が根付いており、成長環境として理想的だと感じていました。 2.2 メンターから感じた高い技術力と温かい人柄 インターンシップでは、3人の方にメンターとしてご指導いただきました。皆さんが豊富な経験と高い技術力を備えながらも、新しい技術に強い好奇心と探究心を持ち、学んだことを楽しみながら仕事に生かそうとする姿勢を持っていたことが印象に残っています。経験を積んだ後も学び続ける方々と働ける環境は、技術者として成長していくうえで非常に魅力的だと感じました。 加えて、私の話や疑問へ耳を傾け、気さくに応じてくださった姿も印象的でした。入社後に活躍できるか、不安を持つ新卒もいると思いますが、私の場合は、「IEであれば大丈夫」と思えたことも入社を決めた理由の1つです。 2.3 学び続けながら柔軟に働ける環境 働く環境や制度の充実も、IEへの入社を決めた理由の1つです。例えば、業務時間の一部を自己研鑽や勉強会に充てられる制度があります。目の前の案件に必要な知識だけでなく、自分が興味を持った技術を試し、将来の仕事につなげる時間も用意されています。そこに、社員の継続的な成長を大切にする姿勢を感じました。 また、業務内容やチームの状況に応じて、テレワークやサテライトオフィスを利用できる点にも魅力を感じました。私自身は出社派で、対面で働くことから得られるものも大きいと感じています。一方、その日の業務や生活に合わせて働く場所を選べる点は、ライフステージが変化しても働き続けるうえで大きな魅力だと思いました。 IEに入社してから、「いろいろな選択肢があった中で、なぜ新卒でIEに入社したの？」と聞かれることがあります。私にとっては 大企業グループの幅広い事業にパートナーとして関われること 技術力と人間的な魅力を備えた社員の方々と働けること 新しい技術を学びながら柔軟に働けること の3つが、私がIEへの入社を決めた大きな理由でした。以上が本章のまとめです。 3. 入社して初めて分かった3つのこと 夏季インターンシップ後に本選考を経て、内定をいただきました。その後、自ら志願し、修士2年の4月から約6か月間、内定者インターンシップに参加しました。途中で1か月の研究留学を挟みましたが、このインターンシップでは音声対話型マルチエージェントに関する調査に主に取り組みました。この内容に興味がある方は、ぜひ こちらの記事 をご覧ください。 2つのインターンシップを通じてIEへの理解は深まりましたが、それでも、入社して初めて分かったことがいくつかありました。ここからは、新卒研修や最初の案件への参画を通じて特に強く感じたことを、3つに分けて紹介します。 3.1 分野横断の研修と早期の案件配属 研修 入社後の最初の2か月間は、新卒研修として座学とアプリ開発に取り組みました。開発したアプリの詳細は割愛しますが、アプリ開発研修では1つのアプリを企画から開発まで形にしました。参加者は私一人だったため、データサイエンティスト（DS）だけでなく、エンジニア（ENG）やプロジェクトマネージャー（PM）の業務も体験しました。各職種に求められる基礎知識と、プロジェクトにおける役割を学べるように設計された研修でした。 新卒研修で体験したPM・ENG・DSの役割（筆者作成） この研修で特に良いと感じたのは、アプリ開発の進捗に合わせて、その時点で必要となる技術を座学で学べるようなスケジュールが組まれていたことです。座学で得た知識をすぐにアプリ開発で試せるため、知識を学ぶだけで終わらず、実践を通して理解を深めることができました。 この座学研修で学んだ内容を、DS・ENG・PM・その他の分野に分けると、次のようになります。 分野 座学研修で学んだ分野 DS ・データ前処理・後処理 ・時系列分析 ・画像処理 ・統計 ・数理最適化 ENG ・エンジニア心構え ・データベースモデリング ・オブザーバビリティ ・Webを支える技術（TCP/IP） ・ソフトウェアテスト ・AIコーディング ・生成AI概論 ・GitHub/Gitワークフロー ・IaC・CI/CD ・UI/UX ・良い設計・良いコード ・セキュリティ PM ・プロジェクトマネジメント ・開発プロセス その他 ・テクニカルライティング ・スライド作成技術 研修を通じ実感したことは、DSに求められるのは、与えられたデータを分析してモデルを作ることだけではないということでした。IEのプロジェクトでは、エンジニアチーム内のPM・ENG・DSがそれぞれの専門性を持ち寄ります。PMの視点を知ることは、プロジェクトでのヒアリングや課題整理、検証計画について、技術者の立場から意見を出す際に役立ちます。また、ENGの視点を知ることで、PoC後の本番開発を見据えてコードやインフラを整備したり、PMが整理した要件を開発へつなげたりしやすくなります。 生成AIをはじめとするツールによって、技術の調査やコーディングの進め方は変わりつつあります。だからこそ、これからのDSには自分の専門領域だけに閉じない姿勢が必要で、PMやENGの仕事も自分ごととして捉え、プロジェクト全体を前に進める力がより重要になると私は考えています。分野を横断して学ぶこの研修は、私にとって、将来どのようなDSを目指したいかを考えるきっかけを与えてくれました。 案件配属 5月に研修を終え、6月から実際のプロジェクトチームに参画しました。私が配属されたチームは比較的少人数で、新卒の私にも早い段階からタスクを任せていただき、議論の中で意見を求められました。たとえばMVP開発の方針提案を検討する場面では、対象モデルの仕様を調査し、その内容をチームに報告した上で、推奨する活用方針などを提案しました。指示された作業をこなすだけでなく、研修や学生時代に学んだことをプロジェクトに生かし、技術者の一人として自分の考えをチームに伝えることが期待されている点は、入社前の想像以上に印象的でした。 早い段階からタスクを任せていただきながら、一方で分からないことや判断に迷うことがあれば、いつでもメンターに相談できる環境が整っていました。案件への配属後も、案件について相談する機会や、仕事の進め方・今後伸ばしたいスキルについて話す機会が設けられています。 このサポート体制には、現在も大きく助けられています。うまくできた点は評価していただき、改善すべき点は具体的に指摘していただけます。そのため、これまでの経験を振り返り、学びを次にどう生かすかを考える力を日々鍛えることができています。一人の新人にきちんと向き合い、成長を支えてくれる方々がいることは、IEの良さだと感じています。 3.2 オフィスで実感した住友商事との距離の近さ 私は新卒DSの2期生ということもあり、入社前は、IE社内で同世代とのつながりをどの程度持てるのかは、少し気になっていたポイントでした。実際に入社してみると、1つ上の先輩方が優しく接してくださったので安心しました。 また、オフィスの同じフロアには、住友商事の複数のデジタル関連部門が集まっています。そこで働く新卒社員の方々に自分から声をかけ、一緒にランチへ行くなど、会社や部署の枠を越えて交流できました。IE社内に限らず、住友商事グループまで視野を広げて同世代とのつながりを持てることは、入社前には想像していませんでした。 交流の中では、互いの仕事や担当領域について話すこともあります。そうした会話を通じて、住友商事の方々がどのような視点で事業やデジタル活用を捉えているのかを知ることができます。一方で、私から技術的な考え方を伝えることもあり、それぞれの立場や専門性を生かした意見交換ができています。将来同じプロジェクトに関わる際も、こうした日頃の関係が連携のしやすさにつながると感じています。 「住友商事グループと近い距離で働く」という言葉を、入社前は主に仕事上の関係として捉えていました。実際には同じフロアで働き、日常的に会話できる環境があります。そのため、同じグループの仲間として働いていることをより実感できました。 3.3 案件外の活動を通じた学びと交流 IEには、担当案件以外にも、業務時間内の自己研鑽や、社員同士で交流するための活動があります。 私が実際に参加している学習活動には、次のようなものがあります。 勉強会 ：業務時間の10％を目安に自己研鑽へ充てる取り組みがあり、執筆時点では、私は先輩社員と一緒に統計の勉強をしています。疑問点を相談し、考え方を共有しながら学べることに、一人で勉強する場合にはない良さを感じています。 DSチームのLT会 ：DSチームのメンバーが最近学んだ技術や試したことを、短い発表形式で共有する会です。自分の担当案件だけを追っていると触れにくい技術も知ることができ、継続的なキャッチアップの機会になっています。 海外グループとの技術交流会 ：私は有志として、住友商事グループの海外拠点で働く方々と英語で技術情報を交換する会に参加しています。海外での技術活用や異なる考え方に触れられるだけでなく、実際に英語で技術について議論する経験にもなっています。これは将来、海外案件に参加するための良い練習だと感じており、積極的に参加しています。 このように、基礎をじっくり学ぶ機会、新しい技術を社内で共有する機会、海外の方々から異なる視点を得る機会など、案件外でも自分を高める機会がたくさんあります。こんなにたくさん学びの機会があるとは入社前は知りませんでした。 また、技術に関する活動だけでなく、部活動やシャッフルランチなど、社員同士の交流を目的とした取り組みもあります。仕事の性質上、少人数のチームで案件を進め、テレワークも利用できる環境では、担当案件が異なる社員との接点が少なくなることもあります。そのため、こうしたイベントが会話のきっかけとなり、案件や職種を越えて、社内にどのような経験や専門性を持つ人がいるのかを知ることができます。 入社前は、勉強会や社内活動を、それぞれ独立した制度のように捉えていました。しかし実際には、技術を学ぶ場であると同時に、普段は一緒に仕事をしない人とつながる入り口にもなっています。用意された機会を自分から活用することで、学べる範囲も、相談できる相手も国内外へ広げていけることが、入社して分かったIEの特徴の1つです。 4. まとめ 入社前の私は、IEに対して「住友商事グループの幅広い事業に関われる」「優秀な技術者と働ける」「新しい技術に挑戦できる」という印象を持っていました。入社して5か月が経った今、その印象は大きく変わっていません。一方で、実際にIEの一社員として働いたからこそ、それぞれの魅力をより具体的に理解できるようになりました。 分野横断の研修を経て、早い段階から案件に入り、新卒でも一人の技術者として意見を求められること。その一方で、メンターをはじめ、困ったときに相談できる方々がいること。住友商事のデジタル関連部門と同じフロアで働き、会社の枠を越えて日常的に交流できること。そして、案件外にも技術を学び、人とつながるための機会が用意されていること。これらは、入社前には十分に想像できていなかったIEの姿でした。 IEは私にとって、データサイエンスの専門性を深めるだけでなく、他職種やグループ内会社の方々と協力しながら、技術を企業価値につなげる経験を積める環境だと感じています。一方で、こうした環境を生かすためには、自分から学び、周囲に働きかける姿勢も必要です。入社からまだ5か月で、私自身も学ぶことばかりですが、これから1つずつ経験を積んでいきたいと思います。 本記事が、IEへの新卒入社や、商社グループでデータサイエンティストとして働くことに興味を持つ方にとって、少しでも参考になれば幸いです。 Insight Edgeでは、新卒採用に加えてインターンシップの募集も行っています。少しでも興味を持っていただけた方は、ぜひ 新卒採用、インターンシップ募集ページ をご覧ください。