物流業界では、EC 市場の急拡大、販売チャネルの多様化、商品ライフサイクルの短期化が同時に進み、サプライチェーン全体の最適化が重要な経営課題になっています。欠品や過剰在庫は、売上機会の損失やコスト増加に直結します。だからこそ、リアルタイムな可視化とデータに基づく意思決定が欠かせません。 こうした課題に応えるのが、日本通運株式会社（以下「日本通運」）が開発・提供する AI 搭載型物流 Web アプリ「DCX（Digital Commerce Transformation）」です。AWS 上に構築された DCX は、在庫管理を中心にモノの流れの情報をつなぎ、データの可視化と AI による予測分析で、サプライチェーン全体の最適化を支援します。 本ブログでは、DCX の概要、AWS を活用したアーキテクチャ、そして最新の AI 機能を紹介します。内容は、2026 年 6 月に開催された AWS Summit Japan 2026 のブース展示をもとにしています。 DCX とは DCX は、日本通運が提供する SaaS 型の物流ソリューションです。在庫管理システム（WMS）として在庫や入出荷を管理し、受注から配送までの工程をリアルタイムで分析・可視化します。 高度な WMS 機能を実装 : アイテム別の入出庫履歴、日々の在庫数量、出荷先ごとの追跡番号などを一元管理。CSV や API によるデータ連携で、お客様のシステムとも簡単につなげることが可能 リアルタイム可視化と多角的な分析 : 受注から配送までの工程をつなぎ、出荷可能な在庫数量や作業進捗をリアルタイムで可視化。売上エリアの傾向や滞留在庫の推移など、さまざまな切り口で分析可能 AI による出荷予測と意思決定支援 : 時系列予測基盤モデル「Chronos-2」による出荷予測で在庫戦略の立案を支援し、Amazon Bedrock AgentCore を活用した対話型 AI で物流データからの迅速な意思決定を支援 導入しやすいサービス体系 : 物流業務を委託する「アウトソーシングサービス」と、お客様自身で在庫管理を行う「クラウドサービス」の 2 種類を提供。初期費用はかからず月額制で利用でき、契約後 2 週間で立ち上げが可能 日本通運が培ってきた「フィジカルなオペレーション」と、最新の「デジタル技術」。この 2 つを融合させ、新たなロジスティクスの価値を届けるのが DCX です。自社 EC を運営する D2C 事業者や販売チャネルの多い企業、物流センターを短期間・低コストで立ち上げたい企業に最適なサービスといえます。AWS 上に構築された DCX は、高い拡張性と安定性を備え、AI による先進的なサービスを提供しています。 DCX のアーキテクチャ — AWS 上での構築 DCX は、在庫管理や受注・出荷を担う DCX 本体と、顧客向け分析基盤「Business Insight」（以下、BI）の 2 つのアプリケーションで構成されています。オプションサービスとして提供される BI では、需要の偏りや在庫の滞留状況を可視化・分析できます。 DCX 本体 — ECS/Fargate によるコンテナ構成 図 1: DCX のアーキテクチャ。 DCX 本体は、 Amazon Elastic Container Service （Amazon ECS）と AWS Fargate 上でコンテナとして稼働しています。以前の運用基盤は Amazon EC2 でした。Fargate への移行とあわせてオートスケールを導入したことで、EC2 運用時に欠かせなかったサーバー台数（キャパシティ）の考慮が不要になりました。さらに、リクエストの増大に合わせてコンテナを増やすスケールアウトも容易になり、繁忙期でも快適なパフォーマンスを維持できています。 Business Insight — Redshift Serverless のデータを分析 図 2: Business Insight のアーキテクチャ。フロントエンドを Vercel でホストし、API を ECS/Fargate 上で提供する構成。 BI も、DCX 本体と同じく ECS/Fargate 上で稼働しています。分析では大量のデータにアクセスするため、接続先には Amazon Redshift Serverless を選びました。 パイプラインファーストの開発体制 図 3: CI/CD パイプラインの構成。GitHub へのプッシュを起点に、ビルド、ECR へのイメージ登録、ECS または Lambda へのデプロイまでを自動化し、結果を Slack に通知する。 開発効率を高めるため、DCX はパイプラインファーストの開発体制を採用し、デプロイを自動化・効率化しています。新しい機能をタイムリーにリリースできるようになり、ユーザー体験の継続的な向上につながっています。 パイプラインは AWS CodePipeline 、 AWS CodeBuild 、 AWS CodeDeploy などの AWS サービスを組み合わせて構築しました。インフラ管理には Terraform を導入し、Infrastructure as Code も実現しています。 データ統合 — Amazon Redshift Serverless と Zero-ETL 図 4: データ統合の構成。DCX と周辺アプリケーションの Aurora PostgreSQL のデータを Zero-ETL 統合で Redshift Serverless に集約し、Business Insight から参照する。 DCX では、日々の倉庫管理業務で使うデータベースと、分析で使うデータベースを分けています。そのため、BI が大規模なクエリを実行しても、ほかの業務には影響しません。 分析用データベースに採用したのは Amazon Redshift Serverless です。データ分析は負荷の変動が大きく、ピークのタイミングも予測しにくいものです。サーバーレスを採用したことで、この課題を解決しながら、コストの最適化も実現しています。 一般に、業務システムから分析システムへデータを移すには、ETL パイプラインの開発と維持が大きな負担になります。DCX は Aurora の Zero-ETL 統合 を採用し、Aurora に蓄積された業務データを Redshift Serverless へ自動で複製することで、この負担を大幅に減らしました。 AI 機能の実装 — Chronos-2 と Amazon Bedrock AgentCore DCX が提供する AI 機能は 2 つ。時系列予測モデルによる出荷予測と、自然言語による問い合わせへの自動応答です。欠品や過剰在庫を防ぐ在庫計画をすばやく立てられるうえ、複雑な操作なしに、滞留在庫の把握から改善策の検討まで進められます。 出荷予測 — Chronos-2 の活用 図 5: 個別 SKU の出荷予測画面。ロケーションと SKU ごとに、実績値と将来の予測値を下位（P30）・中位（P50）・上位（P70）の 3 つの分位点で表示する。 DCX の出荷予測を支えるのは、Amazon Science が開発・公開した時系列予測基盤モデル「 Chronos-2 」です。主な特長は次のとおりです。 ゼロショット予測 : 対象データでモデルの学習を行わなくても予測が可能 Transformer ベースのアーキテクチャ : 生成 AI と同じ Transformer 技術を時系列予測に応用 さまざまな環境で実行可能 : 仮想サーバやコンテナで実行でき、自社のアプリに組み込みやすい（ DCX では ECS で実行） 誰でも使えるオープンモデル : オープンモデルとして公開されており、誰でも無償で利用可能 Chronos-2 の導入により、1 アイテムあたり 1〜2 時間かかっていた予測の算出時間は約 5 分に短縮されました。複数アイテムの一括予測にも対応し、日別・週別・月別で最大半年先まで予測できます。実際の出荷実績と照合すれば、PDCA サイクルを回しながら予測の精度を高めていくことも可能です。 AI チャットによるデータ分析 — Amazon Bedrock AgentCore の活用 図 6: BI LLM Chat の画面。「最も滞留している商品を教えてください」という質問に対し、在庫数と在庫評価額のランキングと、在庫圧縮施策の提案を回答している。 Business Insight には、自然言語で物流データに問いかけられる「BI LLM Chat」を搭載しています。 図 7: BI LLM Chat の構成。 BI LLM Chat は、各エージェントが協調してタスクを遂行するマルチエージェント構成です。Amazon Redshift Serverless に蓄積された在庫・出荷などのデータや、S3 に格納された各種ドキュメントを参照し、ユーザーの問い合わせに回答します。ドキュメントの参照に使うのは Amazon Bedrock Managed Knowledge Base 。ユーザーとの過去の会話は、AgentCore Memory による長期記憶の機構で保持しています。 実装には AgentCore ハーネス を利用しました。AgentCore ハーネスなら、プログラムコードを書かずに AI エージェントを構築・運用できます。しかも、メモリやツール連携、オブザーバビリティなど AgentCore が提供する機能をそのまま活用できます。DCX では、こうして高品質な AI エージェントを短期間で開発し、新しい機能をすぐにユーザーへ届けられるようになりました。 今後の展望 日本通運は今後も、AI をはじめとするデジタル技術を DCX に積極的に取り入れていきます。国内外の拠点に蓄積される物流データと NX グループのグローバルな知見を活かし、お客様の物流現場の効率化と品質向上、そしてサプライチェーンにおける新たな価値の創造を支援していく方針です。 まとめ 本記事では、日本通運の DCX において、AWS の各種サービスがどのように利用されているのかを紹介しました。サーバーレスや CI/CD によって高度な開発・運用体制を確立し、AI やデータ分析技術によって付加価値の高いサービスを利用者に提供し続けています。これらは工夫次第で、どのような業種・企業規模でも取り入れられるアプローチです。みなさまのビジネスにも、ぜひ AWS の先進的なテクノロジーを積極的に活用してみてください。

はじめに 楽楽販売を担当している梶です。 運用の知識をAIから引ける（AIが検索して参照できる）ようにして、開発フローの概要設計に運用影響の確認を組み込むところまで来たので、その経緯を書きます。最初から全体を設計していたわけではなく、気づきのたびに一段ずつ足してきた記録です。 運用への影響は、できるだけ設計の段階で拾っておきたいと考えています。サービスを利用するお客様の業務を止めないため、そして、そのための運用を無理なく続けるためです。 「運用のことは、あの人に聞かないと分からない」という状況に心当たりのある開発者や運用担当の方に、読んでいただけたらうれしいです。 はじめに 設計の段階で、運用影響に気づくきっかけが限られていた 段階1：Markdown化とMCPサーバ 段階2：AIに先に引かせる案内文 段階3：概要設計の確認工程 よさそうだが、測りづらい 概要設計で運用影響を確認するスキル 1か月の評価期間 これから おわりに 設計の段階で、運用影響に気づくきっかけが限られていた 楽楽販売は長く提供しているサービスで、運用手順や「この作業ではここに気をつける」といった判断の知識が積み重なっています。その知識は、長く在籍しているメンバーや運用を担当しているメンバーに集まっていました。資料自体は存在していても、どこに何があるかを知っている人は限られていました。 そのため、設計時に運用への影響を考慮できるかどうかは、次のような条件で決まっていました。 運用を担当しているメンバーが、意図的にレビューに入る 開発を担当するメンバーが、似た過去事例を知っている 案件の性質から「運用に聞いておいた方がよさそう」と感じる どれにも当てはまらない案件では、運用影響は設計の段階では表に出にくく、後の工程で運用に詳しいメンバーが拾っていました。気づくのが遅いほど、取れる対応も限られます。設計の段階であればアプリ側で解消できたかもしれないものも、後の工程では、運用手順やインフラのジョブで吸収するほうがその時点では負担が小さい、という判断になることがありました。 また、気にした方がよいと感じていても、何を確認すればよいかの手がかりがないので、質問も具体的にしにくい状態でした。 段階1：Markdown化とMCPサーバ 普段の業務でClaude CodeやCodexを使う中で、「AIがこれだけちゃんとやってくれるなら、AIから引けるようにさえすればなんとかなるんじゃないか」と考えたのが出発点でした。 最初は、手元にあった運用手順やルール、参照表などの資料をClaude CodeでMarkdownに変換し、それを検索できるMCP（Model Context Protocol）サーバを社内に立てました。AIエージェントはMCPサーバを通して文書を検索し、その結果を読んで回答や作業に使います。いわゆるRAG（検索拡張生成）の構成です。 資料は、運用系のものをあまり選別せずにまとめて入れました。試しに聞いてみると関連する文書がきちんと当たり、これだけ当たるなら使えそうだと感じました。 正直に言うと、この時点ではそれ以上のことは考えていませんでした。長期的な計画があったわけではありません。 段階2：AIに先に引かせる案内文 引ける状態はできましたが、それだけでは足りないと考えるようになりました。 運用作業をしているメンバーには、日々の作業の中で「これはどうだったか」と気づくきっかけがあり、分からなければ調べたり聞いたりする発想にもなりやすいと思います。一方で、運用作業に触れる機会が少ない開発メンバーは、ツールが使える状態であっても、「ここで運用ナレッジを引こう」と判断するきっかけがありません。使うかどうかの判断を人に任せたままでは、知らない人には届かないと考えました。 そこで、人が判断しなくてもAIが先にナレッジを引きにいくように、MCPサーバがAIに渡す案内文を書き換えました。以下は実際の案内文を簡略化したものです（名称の一部を変えています）。 書き換え前： Search operations guides, rules, and references. Use search results to identify relevant documents, then read the matched document for executable procedures. 書き換え後： You are connected to the operations knowledge base — the authoritative source for operational procedures (guides), fixed rules, and reference tables. When a question touches any topic below, search here FIRST, then read the matched document, before answering from memory or local code/grep. Topics covered: - guides (procedures): release, rollback, recovery, migration, ... - rules (criteria & conditions): release, approval, security, oss, ... - references (tables & lookup): scheduled-job, maintenance, interface, ... まず、いつ、何より先に調べるかを書きました。書き換え前は検索の使い方を説明しているだけで、どんな話題のときに使うのか、手元の記憶やコード検索とどちらを先に使うのかは書いていませんでした。書き換え後は、目次にある話題に触れたら、記憶やコード検索で答える前にまずここを調べる、と順番まで指定しています。 あわせて、トピックの目次を文書のタグから自動生成して載せました。AIにとって「何が載っているか」が分からないと、引くべき場面を判断できません。目次は文書を追加するたびに自動で更新されるので、手で保守する必要がありません。 この案内文は、AIのセッションが始まるたびにコンテキストへ載ります。利用者が運用ナレッジの存在を知らなくても、関連しそうな話題ならAIの側から先に引きにいくように促せます。 インフラチームから相談を受けたときには、この仕組みが効いていると感じました。相談内容が書かれたスプレッドシートのリンクに「この件相談したい」とだけ添えてClaude Codeに渡したところ、指示していない運用ナレッジも自分から引き、まさに議論したかった論点を挙げてくれました。もっとも、もとの相談が具体的に書かれていたことも大きかったと思います。 段階3：概要設計の確認工程 よさそうだが、測りづらい 「知らなくても引ける」状態に近づき、定性的にはよい取り組みだと言えるようになりました。一方で、成果として示しにくいことに、私自身モヤモヤしていました。AIがタスクの途中で引く仕組みなので、利用者本人も「使った」という実感を持ちにくいのです。 そんなときに、周囲に相談していた中で「開発フローに組み込んではどうか」という話が出ました。使われないツールでは意味がないので、使われる場面が自然に生まれるのを待つのはやめて、確認する場面を工程として置く方向で検討を進めました。 概要設計で運用影響を確認するスキル そこで、概要設計の段階で設計内容と運用ナレッジを突き合わせ、運用影響を洗い出すClaude Codeのスキルを作りました。作る中でつまずいたのが、検索の当て方です。 最初は設計書の差分やDDLをそのまま検索にかけていましたが、当たるべき文書に当たらず「該当なし」になることがありました。設計書の言葉と、運用手順書に書かれている言葉が違うからです。そこで、変更点をいったん「何をしようとしているか」という自然文に起こし、運用文書に書かれていそうな言葉で検索するようにしました。 出力にも決まりを設けました。 該当がなかったときは「運用影響なし」ではなく「現時点で該当なし」と書く。ナレッジに載っている範囲との突き合わせであって、運用全体の網羅的な確認ではないため 出すのはあくまで提案で、採否は設計者が判断する 1か月の評価期間 いきなり必須にはせず、約1か月の評価期間を設けました。合格の基準は結果を見る前に決めて固定し、自分の案件だけでなく、チームメンバーが実際に書いた概要設計で試してもらいました。試用の中では、設計者が見落としていた運用の観点を拾えたケースもありました。 その結果を受けて、2026年9月下旬から、概要設計のチェックリストに「運用への影響を考慮したか」という項目を加えました。運用ナレッジとの突き合わせには、このスキルを使うよう添えています。 これから 今のチェックは、設計の「入口」での確認です。今後は、受入テストや結合テストといった「出口」のタイミングでも運用影響を確認し、その判断の結果を証跡として残せるようにしたいと考えています。 あわせて、運用側として「ここは運用レビューを必須にする」という線引きを定義することも次の課題です。この線が曖昧だと、結局は確認や相談が有識者に集まってしまいます。 おわりに 有識者への依存を減らしたいのは、お客様の業務を止めないための運用を、無理なく続けるためです。 同じように「運用のことはあの人に聞かないと」という状況にいる方は、まずは手元の運用資料をAIから引けるようにしてみてはいかがでしょうか。数本だと当たり外れが分かりにくいのですが、まとめて入れると「使えそうか」の手応えがつかみやすいと思います。 最後までお読みいただき、ありがとうございました。

はじめに 3rd partyチームのマネージャー 松下です。 本記事では、私が所属している3rd partyチームを紹介します。 このチームでは、RevCommのプロダクト「MiiTel」において、Salesforce・HubSpot・Slackなどといった外部システムをつなぐ機能を中心に開発しています。 私たちのチームは、今年1月に組織され、以後2名の体制です。 少人数のチームではありますが、アプリケーションとクラウドインフラの両方について、開発から保守運用、監視や障害対応、技術的負債への解消といった幅広い領域を担当しています。 そのため、単に「どう実装するか」だけではなく、どうすれば少人数でも安定して開発を続けられるか、問題が起きたときに素早く切り分けられるか、といったことを日々考えながら開発しています。 この記事では、2名という少人数のチームでどのように開発に向き合っているのか、普段の業務で重視している考え方と併せ紹介します。 担当を固定しない 2名のチームであるため、「この領域はこの人しか分からない」という状態はできるだけ避けるようにしています。得意分野や詳しい領域はそれぞれありますが、実装、レビュー、インフラ、障害調査などを完全に分担して担当することはしていません。 影響範囲が広いものや複雑な変更の場合は、実装前に設計を相談し、早期のリスクの低減を図っています。障害や問い合わせがあった場合も、状況に応じて2名で調査します。少人数のチームでは、個人の生産性を最大化すること以上に、チーム全体として止まらない状態を作ることを重視しています。 現状、障害対応やオンコールも基本的には私たち2名で担っています。ただし、2名だけで全てを抱えているわけではなく、必要な場面では他チームや組織に支援を要請できる体制になっています。 その上で、日常的な対応や改善は自分たちの判断で進められる裁量があります。業務フローの改善や体制の構築自体に、自分たちで主体的に関わっていけるのは、この規模のチームならではの面白さです。 実装だけでなく、運用できることを重視する 生成AIの登場によって、動くコードを作成すること自体のハードルは大きく下がりました。一方で、生成されたコードがそのまま本番運用に耐えられるとは限りません。正常系だけを見れば問題なく動いていても、実際の運用ではさまざまな状況が発生します。 たとえば、以下のような点です。 外部サービスがタイムアウトしたときにどうなるか 同じ処理が再実行されても問題ないか 想定外のデータが渡されたときにどのように振る舞うか 障害が発生したときにログから影響範囲の特定や原因を追えるか リリース後にレスポンスタイムや処理負荷が悪化していないか こうした観点を生成AIへのプロンプトや開発環境のハーネスに組み込むことで、補うことはできます。しかし、新規の設計や機能において、あらかじめすべての観点を用意しておくことは困難です。 そのため、私たちは生成されたコードが「動くか」だけではなく、異常時にどう振る舞うべきかを設計段階で考え、コードレビューでも確認することを重視しています。 また、リリース後も、本番環境のデータ量やアクセスパターンなど様々な要因により、パフォーマンスの低下が引き起こされる可能性があります。そのため、監視やログを通じてリリース後の状態も確認し、改善につなげます。 生成AIによって実装の速度は上げられるようになりましたが、そのコードを安心して運用できる状態にすることは、現時点では引き続きエンジニアの重要な仕事だと考えています。 技術選定や既存の設計にも踏み込む 前述の通り、少人数のチームであるからこそ、決められた仕様を実装するだけではなく、既存の設計の見直しや技術選定の段階から関わる機会も多くあります。 新しい機能を作る際には、既存の構成をそのまま踏襲するのではなく、要件や運用を踏まえて、どのような構成が適しているかを考えます。たとえば、同期処理にするのか非同期処理にするのか、既存の仕組みを拡張するのか新しく作るのか、どこまでマネージドサービスを利用するのか、といった判断も開発の一部です。 もちろん、自由に技術を選べるという意味ではありません。既存システムとの整合性や運用コスト、チームで継続して保守できるかまで含めて判断します。 実装方法だけではなく、どう作るのがよいかを考えるところから関われるのは、今のチームの特徴の一つです。 どんな人と一緒に働きたいか このチームでの働き方が向いているのは、次のような方だと考えています。 アプリケーション・インフラ・運用設計・障害対応まで幅広く関わりたい方 設計や技術選定の段階から意見を出したい方 自分の裁量やチームへの影響を実感しながら働きたい方 逆に、担当領域を明確に分けて専門性を深めたい方や、決められた仕様を正確に設計実装することを重視したい方には、今のチームのスタイルは合わない可能性があります。 おわりに まだ小さなチームだからこそ、開発の進め方や技術的な判断に、一人ひとりの考えが反映されやすい環境です。これからチームを大きくしていく中でも、より良い設計や運用、開発の進め方を自分たちで考えていけるチームにしていきたいと思っています。 この記事を読んで、こうした環境で一緒に開発してみたいと感じてもらえたらうれしいです。 バックエンドエンジニアの採用情報