オープンロジを支える技術（2025年版）
OPENLOGI Advent Calendar 2025 最後の投稿です。
株式会社オープンロジは2013年12月25日が創業日なのでちょうど本日で創業12年目という節目を迎えることになりました。
今があるのもひとえに、ここまで関わってくれた多くの方々（お客様、パートナーの皆様、株主の皆様、過去および現在の全てのメンバー）のおかげです。
そんな感謝の気持ちを携えながら、今年も締めくくりとして年内に実施された技術的な取り組みの中から、主要なものを３つご紹介したいと思います。
昨年のエントリー
今年の主なアップデート
- AI活用の本格化と組織への定着
- モジュラー型アーキテクチャへの段階的移行
- スケーラビリティ強化：引当処理と在庫同期の再設計
1. AI活用の本格化と組織への定着
昨年の記事では「個人的に手放せないもの」という言及程度で留まっていましたが、今年に入ってAIの急激な進化に伴い社内での活用も本格化しました。
エンジニア全員が自由に利用できる環境を用意したことで自発的な活用が進み、効率的なツールなどが次々と生まれてきています。
AIを本質的な作業に集中するための高性能なアシスタントと位置付け、 エンジニアが「How（どう作るか）」から、「Why（なぜ作るか）」「What（何を作るか）」というより本質的な問いに集中できるような環境づくりに取り組んでいます。
体制面：個人の活用から組織的な取り組みへ
単にツールを入れるだけでなく、組織としてAIを使いこなすための体制づくりに踏み込みました。
- エンジニア向けAI活用予算の確保
- GitHub Copilotに加え、Claude Code、Codex、Gemini CLIなど、開発者が最適なツールを試せる環境を会社がバックアップ
- AI 活用推進体制の構築
- AI Enabling Team の設立
- AI活用の定着と加速をミッションとし、各チームが自律的にAIを活用できるよう伴走する横断的な専門家チーム
- 各チームにAI推進担当者の配置
- 各チームに推進役を置くことで、現場の課題に即したAI活用を牽引
- AI Enabling Team の設立
全社的な取り組みについては以下の記事で詳しく紹介しています。
主な活用事例：運用業務支援エージェント
- Slack 上での問い合わせや質問に対して、AIが自律的に調査し回答する Bot
- はじめは特定の開発チームの自発的な取り組みから生まれたツールですが、その有用性は瞬く間に社内で認知され、現在では各複数チームに横展開されなくてはならないレベルで活用されています。
- 作者による記事がありますので、詳しくはそちらをご覧ください。
PoC / 試行錯誤中プロジェクト
それぞれ目下試行錯誤中のプロジェクトですが、詳細についてはきっと来年には記事化されるはずかと思いますのでお楽しみに
- CRE向けの運用業務支援に加えて、対応で得られたナレッジの蓄積も可能なLLM実行環境の構築
- 仕様書からテストコードを自動生成し、QA がレビュー可能なワークフローを経てテストケースとして蓄積・実行する仕組みの構築
- ソースコードから自動で仕様書を生成し、PRレビューを通じて育てていくドキュメント環境の構築
2. モジュラー型アーキテクチャへの段階的移行
これまで Laravel 標準のレイヤー構成を軸に開発を続けてきましたが、コードベースが大規模化するに従ってモジュール単位での構成把握が困難になり、結果として開発効率やコードの保守性に支障が出てきました。加えて AI を業務に組み込む際には、LLM に渡すべき“最小で意味のあるコンテキスト”を意識的に切り出せることが求められます。こうした背景から、チーム境界とコード構造を揃えるモジュラー型アーキテクチャへ、段階的に移行する方針を採りました。
ディレクトリ構成の移行イメージ
[before]
app/Http/Controllers/{DOMAIN}/SomethingController.php
app/Jobs/{DOMAIN}/DoSomething.php
app/Services/{DOMAIN}/SomethingService.php
app/Repositories/{DOMAIN}/SomethingRepository.php
↓
[after]
app/{DOMAIN}/Something/
├── Presentation/ (Http/Controllers)
├── Application/ (Jobs/UseCases)
├── Domain/ (Models/Services)
└── Infrastructure/ (Repositories/ExternalApis)
※上記はあくまでイメージであり、実際のディレクトリ構成とは異なります。
現時点では、まだ一部のチームにおいて動き始めているような段階ですが、これは単なるコード整理ではなく、「チームが自律して素早く動ける土台」を作る取り組みとして、来年以降も継続的に進めていく予定です。
3. スケーラビリティ強化：引当処理と在庫同期の再設計
物流プラットフォームにおけるコア機能とも言える「引当処理」と「在庫同期」は、取扱量や外部連携先の増加に伴いピーク時に脆弱に
なりやすい領域であり、実際ボトルネックになってしまうケースも多い部分でした。
今後の成長を見据えた際に、これらの処理のスケーラビリティを強化することは必然であると判断し抜本的な改修に着手しました。
引当処理：注文単位から商品単位へ
従来の引当処理は注文単位で処理を行う方式で実装されていました。具体的には一つの注文を受け取ると、その注文内の全行（SKU／数量）を順次処理して在庫を確保するという流れです。この方式は処理ロジックとしては単純で実装しやすい反面、注文数が増えると同一 SKU に対して冗長なアクセスが発生しやすく、ロック競合の解消に伴うオーバーヘッドが膨らむため、ピーク時のパフォーマンスが著しく低下するという課題がありました。
このビジネス上クリティカルな問題を解決するため、注文単位で逐次処理していた既存ロジックを、注文を横断して商品単位に集約し、さらに非同期で並列処理するよう再設計しました。これにより、処理スループットの向上とロック競合の大幅な削減を目指しました。
とはいえ、結果の正確性が強く求められる処理であるため、冪等性の担保、再試行設計、監視の整備といった信頼性維持の対策を併せて慎重に進める必要があり、難易度の高いチャレンジとなりました。
現在も開発は継続中ですが、新しい引当処理は既に本番環境で稼働を開始しており、現時点で顕著なパフォーマンス改善が確認されています。今後は更なる改善も見込まれており、物量の増減に左右されず安定して運用できる状態の実現を目指していきます。
在庫同期：イベントドリブンへのシフト
定期バッチで EC 側へ在庫数を反映する既存処理において、対象アカウント数や商品数の増加に伴って処理が所定の時間内に収まらなくなり、今後の成長を見据えると運用上耐えられない状況になりつつありました。
そこで私たちは、全件を一括で回すバッチ中心の設計から、更新をイベントとして扱うイベントドリブン方式へと再設計を行いました。具体的には、イベントを一時的に吸収するバッファの導入や取りこぼしを補正するリコンサイル処理の追加、そしてイベント単位での順序・重複耐性を考慮した処理設計により、追従性と回復性を高めることを目指して設計しています。
こちらも引当処理と同じく正確性が求められ難易度の高いチャレンジでしたが、現在は検証を行いながら順次適用を進めているところです。今後よりスケーラブルな基盤の構築に向けて引き続き取り組んでいきます。
主な技術スタック
その他のアップデートあった部分について言及します。
アプリケーション / インフラ
- PHP / Laravel: 来年のメジャーアップデートに向けた準備を継続
- React: React Hooks への段階的移行
- AWS: 仮想サーバOSのアップデート実施。Aurora v3移行プロジェクトも進行中
- Amazon SES: 長年利用した Mailchimp(Mandrill) から移行
開発環境
- MagicPod: E2Eテスト基盤をGhost Inspectorから完全移行
- MCP (Model Context Protocol) サーバー:
- RedmineやGROWI、社内ドキュメントにAIがアクセスするためのMCPサーバを整備。AIアシスタントが社内ナレッジを背景に回答できる環境が整備された。
まとめ
2025年はとにかくAI関連の変化・進化が目覚ましく、社内においてもまずはチャレンジが必要という熱意のもとで取り組みが一気に加速された一年でした。まだ実験段階のものが多いですが、来年にはより実用的かつ革新的な形で活用が進んでいくことになるかと思うので、引き続き注力していきます。
また、長年解消できなかったコア処理のスケーラビリティ課題にも着手し結果を残すことができた点においても、基盤強化の面で大きな一歩を踏み出せた年となりました。
まだまだ解決すべき技術的課題も多くありますが、より本質的なプロダクト課題・ビジネス課題に向き合えるように、現場の実践を大切にしながらこれからも着実に進化を続けていきます。
オープンロジでは、これからの挑戦を一緒に楽しめる仲間を募集しています。興味のある方はぜひお気軽にご連絡ください！