AI以前のシステム移行を、AI思考で振り返る（OMS内製化）

目次
はじめに
プロジェクト概要
- Order Management System (社内通称:OMS) について
- OMSサンセットプロジェクトについて
プロジェクトにおける役割と実施内容
当時のフローと現行フローの比較
プロジェクト成功の知見と、AI時代に新たに見えてきた課題
- リスクとなるレビュー
- 新人教育への影響
おわりに

はじめに

こんにちは、コアシステムエンジニアリング(CSE)部門配送ドメイングループの安見です。普段はモノタロウの物流を支える配送システムの開発・運用に携わっています。

今回は、2025年8月に完了した大規模パッケージ内製化プロジェクト（社内通称：OMSサンセットプロジェクト）を題材に、少し趣向を変えた紹介をしたいと思います。このプロジェクトで実際にやってきたことをそのまま書くと、現在のAI活用フローとの差分が大きく、どう記事にすべきか悩みました。そこで今回は、「もし現行のAI活用フローがあの当時すでに整っていたら、このプロジェクトはどう進んでいただろうか」という想像＋実際の振り返りとして紹介します。あくまで実際にやったことではなく、現行フローに当てはめた話である点にはご注意ください。
加えて、AI時代に新たに見えてきた課題についても少し共有したいと思います。なお、AI使いのプロフェッショナル向けの記事ではなく、1企業社員としてのユースケースなので、その点はご了承ください（代わりにAIの業務活用に自信がない方にもわかりやすく書いたつもりです...!）。
では、まずプロジェクトの概要をざっくり説明します。

プロジェクト概要

まずは、実際に内製化した外部システムについて紹介いたします。

Order Management System (社内通称:OMS) について

モノタロウでは、注文管理業務全般を高度化するパッケージ製品を導入し、そのうち出荷方法を最適に決定できる注文引当の機能を活用していました。ここで高度な引当とは、ある商品が出荷できる倉庫候補が複数あった場合に配送費が最適となるように商品を出荷する倉庫を決めることです。例えば、近い拠点から出せば当然配送料は安くなりますし、同じ注文の商品は同じ倉庫から出したほうが一つの箱にまとめることができるので安くなります。こういったいくつかの要素の中で配送費をできるだけ抑える倉庫で出荷することを目指します。

OMSサンセットプロジェクトについて

OMSサンセットプロジェクトはこの高度な引当システムを内製化する（戻す）プロジェクトです。なお、内製化といっても一から作ったわけではなく、
①当初、受注に対する在庫引当は自社開発の引当ロジックによって処理されていた。
→②業務拡大・機能拡充に伴い、最適な引当を実現できるOMSを導入し、引当処理をパッケージ側に移行した。(2018末ごろ～2022/03)
→③色々な判断の下(※)、再度の内製化を決定。OMSにのみ存在していた機能を自社引当システムへ取り込む改修を実施し、引当処理を再び自社システムへ戻した。(2024/09～2025/08)

※ なぜ内製化に踏み切ったのか: 引当領域はモノタロウにとってビジネス差別化の要であるため、パッケージ製品に対して多くのカスタマイズを施す必要があった。その結果、運用面での課題が生じ、ビジネスの迅速な変化に対応しきれない場面も出てきた。また、外部環境・内部環境の変化により、OMS導入により実現できた主要機能が内製化できそうなこと、内製化による機能低下が生むコスト影響も許容範囲に抑えられる見込みがあった。

本日紹介する内容はこの③の内容となります。

プロジェクトにおける役割と実施内容

このプロジェクトにおいて、私は主に機能要件の各工程（設計、実装、テストなど）を担当しました。詳細は省略しますが、以下のタスクに取り組みました。

直送引当の高度化: 以前のシステムにはなかった機能の実装。
引当ロジックの最適化: 既存の倉庫決定ロジックの見直しと改善。
分析・シミュレーション: 移行による影響範囲の調査。

当時のフローと現行フローの比較

それでは、当時実際に行っていたフローを現行フローと比べながら紹介したいと思います。
私は一般基幹開発エンジニアですが、その私の現行のフローでも、かなり楽になったのがわかるかと思います。
また執筆時点(2026/03/09)の話なので、記事公開時点ではさらに状況が変わっている可能性もあります（それぐらい進化がはやい...）。

準備・調査

当時

　プロジェクトに参画して始めにやったことは、ひたすらコードリーディングでした。このプロジェクトに参画するまでは既存の引当システムは読んだことも修正したこともない状態であったため、現状を把握することが肝要でした。ここで全体の流れを把握した上で設計を行えたことは、個人的にはかなりよかったと思っています。特に機能追加する上で修正範囲は局所的ではなく各所に及んだため、このフェーズがなければ全体としてうまく動くか自分の中で納得して設計することはできなかったと感じました。（おかげで少なくとも設計でちゃぶ台返しレベルの手戻りはなく、大きなシステムトラブルも起こらなかったです）

今なら

　当時は自分でコードをほぼ全量読んで理解するしかなかった（仕様書もなかったため）のですが、今ならまずClaude Code(※)に現行ソースを投げて、全体の処理フローを報告してもらいます。主要なロジックの流れ、依存関係、データの入出力の構造などを把握するのが目的で、やりたいことは当時と変わりません。変わるのは「自分がコードを読んで理解する」から「AIが読んだ結果を人間がレビューする」に変わる点です。全量を読み込む必要はなく、AIの報告を叩き台にして、自分の中でザックリとした設計の方向性を思い描けるくらいの理解が得られれば十分と考えています。モノタロウはBigQueryにテーブルの情報やデータがあるのでbqコマンドを許可しておけば、開発中に直接本番に接続することもなくテーブルとの関連も検索してくれ、十分に精度が高い調査結果が得られます。

数日～1週間以上かけていたものが1日で設計に十分な理解を得られるようになったと思っています（理解度的には全量読んだ方がもちろん高いですが、設計に十分なレベルという意味で）。

※ Claude Code: 今AIコーディングを席巻しているagentic codingツール。自然言語での問いかけに対して、コードを実際に書いて実装するところまでを自動でやってくれる。調査タスクや設計タスクも適切にコードリーディングしながら行ってくれる。
https://code.claude.com/docs/ja/overview

設計

当時

直送引当の高度化や引当ロジックの最適化を実現するための基本設計を行いました。既存のロジックが複雑だったため、既存の仕様を崩さないように追加機能を実装するのは大変で、初めの概算工数見積もりで出した工数よりスケジュールが伸びてしまいました。この工程では、本当に問題ないかを現行ロジックと照らし合わせながら、精緻に設計を行いました。レビューも多くの有識者を集めて、何度もレビュー会を開催して問題ないことを確認しました。その後の詳細設計以降は基本設計の情報を使いながら、メソッド単位などの細かい分割レベルで都度都度AIにコードに起こさせたりしながら行っていました。

今なら

当時は設計書を精緻に作り込み、有識者レビューを何度も重ねることで品質を担保していましたが、今ならそのアプローチは変わります。現行は仕様駆動開発(※1)が主で、弊グループではOpenSpec（※2）を使っているので、調査フェーズで得た情報や既存ドキュメントをかき集めてAIに投げ、仕様書・設計書をまず一緒に作成していきます。

ここまでは割と雑にやりますが、出てきたアウトプットは”そこそこ”真剣に見ます。”そこそこ”と書いたのは、当時のように現行ロジックと照らし合わせながら完全無欠なものを作ろうとはしないからです。担保すべきことは後続のテストで担保すればよいというスタンスに変わってきています。

弊チームのtechリードの「80%ぐらいあってそうだったら承認してる」という金言が印象的で、私自身もこのマインドセットに共感するようになりました。無論、最終成果物の品質には責任を持ちます。重要なことは、この時点で完璧にしようとすることは効率を大きく落とす点と品質の担保は後の工程で可能ということだと思っています。

なお、文章で伝わっているのか微妙なので補足すると、当時と今で工数的には数倍以上（もっと？）の差が出ていると思います。

※1 仕様駆動開発
設計・開発の前段階である仕様作成もAIと協業して行って開発するスタイル。
そもそもAI以前もすべてのシステムが仕様駆動であり仕様駆動開発なはずだが、現在はAIと協業して仕様を作成して開発する流れが一般的にそう呼ばれている。

※2 OpenSpec
AI エージェントと一緒に仕様書から作成する仕様駆動開発のためのフレームワーク
https://github.com/Fission-AI/OpenSpec

実装・テスト

当時

何人かの実装者とすり合わせながら、詳細設計書をもとにコーディング＆テストしていただきました。私自身もロジックのコア部分である倉庫決定ロジックの実装を担当しました。主にAIのタブ補完機能を駆使しながら、想定より複雑になってしまった設計の実装を懸命に行っていました。テストコードのテストケースをタブ補完＆チャットで書かせていくのが楽で、有難かったのを覚えています（なつかしい。補足しておくとClineなどのcoding agentもすでに市民権を得てきている時期ではありました。過渡期であった点、現在と比べたAI性能の問題、システムがレガシーであった点などでタブ補完よりうまく使いこなせなかったため、タブ補完とチャットを主に活用していました）。

単体テストはテストコードで補完していましたが、結合テストは数百ケースにも及ぶテストを何人かで手分けして手動でやっていました。（そのときのシステムには結合テストをコードで行うような仕組みがなく、作成するのも難しかったため）

今なら

当時はAIをタブ補完として使いながら自分が実装を書く形でしたが、今なら実装そのものをAgentに任せる形に変わります。設計のアウトプットとしていくつかのタスクにすでに分割されているはずなので、それを並列的にgit worktree(※1)などを使いAgentに開発させていきます。1〜3並列程度で作業するイメージです。レビューにもAIを使い、そのAIレビューを踏まえて人間がレビューします。

もっと多並列で動かしている方もいるのですが、レビューや他作業の差し込みがボトルネックになり、それ以上増やしても私は処理しきれなかったです。コンテキストの切り替えコストは人間側にも存在するので、並列数はその人の作業スタイルや案件のスコープによって変わってくると思います。
また、繰り返し使う操作や手順はSkill化（※2）しておき、都度Agentに説明し直すコストを省くことも重要です。Skillsの整備を行うことでチームの開発速度の底上げが可能なため、弊チームでは積極的にSkill化とその共有を行っています。実際に全社共有用のmarketplace(※3)と私が所属している引当チーム共有用のmarketplaceがgitのリポジトリで管理されており、それぞれ利用可能な状況になっています。

結合テストに関しては、結合テスト基盤＆コードをAIで作成してしまうか、それが難しい場合でもテストケースの洗い出しや手順書の作成をAIに任せることで、当時のような何人かで手分けして手動でこなすスタイルは変わらなくとも、準備コストは大きく下げられると思います。少なくとも、数百ケースのテスト項目を人間が一から考えていた部分はAIが肩代わりできます。

※1 git worktree
同じリポジトリ内で複数のブランチを管理したい場合に使う、もともとgitにあるコマンド
https://git-scm.com/docs/git-worktree
今だとgit worktreeでググるとAI活用の文脈で色々出てくる。

※2 Skills
Skillは「再利用可能なプロンプトのテンプレート」です。
よく使う指示や手順をあらかじめSkillとして登録しておくと、次回以降は短いコマンド一発で同じ操作を呼び出せます。
あるいは、description:に書いた条件と一致する文章をAIが判断して自動で実行します。
https://code.claude.com/docs/ja/skills
↑Claude CodeのSkillsのリンクですが、他のAIツールでも存在します

※3 marketplace
Claude Codeにはプラグイン（Skills・Agents・Hooks・MCPサーバなど）をカタログとして配布・共有できるmarketplaceという仕組みがあります。
実態はgitリポジトリで、チームや組織単位で作成でき、メンバーは `/plugin marketplace add org/repo` で追加するだけで登録されているSkill等が使えるようになります。https://code.claude.com/docs/en/plugin-marketplaces

シミュレーション・分析

当時

シミュレーションは一回行うのに一日がかりで大変でした。さらに、それを各設定で何度も行う必要があり、より一層苦悩しました。また分析に関しても、引当データの仕様がやたらややこしい＆ドキュメントもあまり整理されておらず、量も多い上に配送費が自動で出るようなものでもなかったため、この分析にかなり時間を吸われました。結果が明らかにおかしい場合もあり、その場合は設定を見直して、やり直したりすることも多々ありました。この部分でプロジェクトのバッファをかなり食ってしまっていました。

今なら

シミュレーションの実行そのものは、当時と変わらず人間が手を動かす部分として残ると思います。実行方法に様々な制約があったり、処理の待ち時間があったりするためで、ここはAIに任せるには今でも難易度が高いです。

一方、当時かなりの時間を吸われていた分析は大きく変わります。引当結果はすべてBigQueryに保存されているので、MCPサーバ（※）を使うなりbqコマンドを叩かせるなりしてAIに分析をさせます。「この設定での倉庫×地域別の引当比率を出して」といったリクエストを自然言語で投げるだけで、クエリを書いて結果を整形してくれます。当時は仕様の複雑さやドキュメント不足に苦しめられましたが、その文脈理解もAIが補ってくれる部分が大きいと思います。

さらにそれをSkill化しておけば、次回以降は同じ分析を素早く再現・比較できます。当時プロジェクトのバッファを食い潰した一因がこのフェーズだっただけに、この改善のインパクトは特に大きいと感じています。

実際に最近の問い合わせ調査で似たようなことをやった例が下記です

最初にザックリとやることを伝える（色々カラム情報とか載ってるので塗りつぶしてます。monotaroNoは注文コードのことです）

↓その後、ごにょごにょ補足したりして
いい感じの結果が返ってきた（途中のクエリとかは自分で問題なさそうなこと確認済み）

そのままSkill化してもらい、次からはコマンド叩けば一発で出してくれるように（実際はclaude codeで配布されてるskill-creatorとか使った方がいいと思います...!）

※ MCP
MCPはModel Context Protocolの略で、AIと外部ツール・サービスをつなぐ標準的なインターフェースです。
簡単に言うと「AIがBigQuery（外部ツール）を直接操作できる」「AIがDatadog（外部ツール）のログを直接検索できる」といったことを実現する仕組みです。
MCPにしなくてもターミナル上で操作を許可すれば可能なことはあるので、割と使い分けではあると思います。
https://modelcontextprotocol.io/docs/getting-started/intro

経過観察・運用

当時

引当結果の分析を行うために定常的に使うクエリを考えて、Googleスプレッドシートのデータコネクタ機能を使用してモニタリングできるようにしていました。また、引当結果の問い合わせがあった場合はBigQuery上にシステムのtrace_logをアップロードしていたため、それを見てその引当になった理由を回答していました。なお、プロジェクト自体は幸い大きなシステムトラブルや想定外の配送費増加はなかったのですが、そういったシステムトラブルがあった場合は急ぎエラーログや引当結果を追って、現行コードの確認を行いながら原因を調査していたと思われます。

今なら

経過観察のモニタリング自体は、当時と同様にスプシのデータコネクタにまとめる形が引き続き便利だと思います。変わるのはその準備コストで、モニタリング用のクエリはAIに書かせることで楽になります。当時は仕様の複雑さもあってクエリを考えるのに時間がかかっていましたが、今ならザックリとした指示で叩き台を作ってもらい、確認・調整するだけで済みます。
問い合わせに関しては、前述同様Skill化してしまえば調査＆回答で楽をできます（あるいは定型的な問い合わせが多ければbot化してもよいと思います。下記記事参考) tech-blog.monotaro.com

また、当時はトラブル時にエラーログを自分で追いながら原因調査をしていましたが、今ならまずAIに投げます。Datadog等のMCPサーバを使えば、ログの検索から原因の分析・報告まで一気通貫でAIにさせることができます。幸いトラブルがなかったとはいえ、もし発生していた場合の調査コストを考えると、この違いは大きいです。

プロジェクト成功の知見と、AI時代に新たに見えてきた課題

今回のOMSサンセットプロジェクトは特に大きなトラブルもなく達成することができました。
懸念されていた配送費の爆増といった事態も起きず（これには物流部門の協力も大きく寄与しています）、無事にシステムを切り替えることができました。

AIが本格導入される以前の取り組みだったため、コード解析の「つらみ」はあったものの、その中で得られた知見を振り返って現在の運用と照らし合わせると、AI時代には異なる性質の課題が見えてきました。

リスクとなるレビュー

AIがものすごい速度でコーディングを行うようになり、AIが書いたコードを従来と同じ粒度で精緻にレビューしようとすると、そこがボトルネックとなってしまい、次々にレビュー待ちのPRが積み上がり、開発が詰まります。

前述の「80%ぐらいあってそうだったら承認してる」はまさにこの文脈です。テストで品質を担保し、レビューでは設計やロジックの意図の正しさに集中する。全行チェックから、ポイントチェックへ。このマインドシフトができないと、AI時代の開発速度を活かしきれないなと考えています。

（ただ、この辺のレビューすべき点、そうでない点はまだ明確に自分の中で腹落ちできていないです。現状の所感ではAIの打ち筋は正確に動作する一方で局所最適に向かいやすい傾向があるとは感じています）

それでもレビュー待ちはボトルネックになりがちで、AIレビューを一次フィルタとして活用することである程度は緩和できますが、最終的に人間が判断する部分は残ります。ここをどう効率化するか、あるいはレビューの基準自体を見直すかは、まだ試行錯誤中です。

新人教育への影響

AIが調査も実装も肩代わりしてくれる環境は効率的ですが、「自分でコードを読んで理解する」経験が減るという側面があります。

私自身は当時コードを全量読んだことで深い理解が得られましたが、今の新人が同じプロセスを踏む機会は少なくなりました。AIの報告をレビューする力は、そもそも自分で読んだ経験がないと身につかないのでは？という懸念があります。「AIを使いこなせる」と「技術力がある」は別の能力で、後者の育成をどうするかはチームとして考える必要がある課題です。