<h2 id="h8d027c8ed3">はじめに</h2>株式会社Azitでエンジニアリングマネージャーをしている岩瀬です。 私たちは物流・SCM領域に特化したAIソリューションを提供しており、2025年9月に需給予測プラットフォーム「ForecastX」をリリースしました。プラットフォームの開発と並行して、ForecastXに搭載する個社別の予測モデルについて、開発手法の確立に取り組んでいます。 今回は、ECサイトの需給予測モデル開発プロジェクトについて振り返ってみたいと思います。 このプロジェクトでは、Claude Codeを中心としたAIツールを活用して開発を進めました。結果として目標は達成できたものの、途中で大きな失敗を経験し、多くの学びを得ることができました。特に、開発における落とし穴や、より良い開発手法について考える良い機会となりました。 需給予測やデータサイエンス領域でのAI活用開発を検討されている方に、実際の体験談として参考にしていただければと思います。

<h2 id="h3af4d147a9">プロジェクト概要</h2><h3 id="h84e47269a9">お客様の課題</h3>今回のお客様はECサイトを運営されており、自社商品の需給予測に課題を抱えていました。 既存の予測方法：<ul><li>1週間ごとに、過去7日間の平均販売数×30日間で需要を予測</li><li>その結果を人が確認して手作業で補正</li></ul>抱えている問題：<ul><li>毎週5名の担当者が各3時間、合計15-20時間を予測作業に費やしている</li><li>過剰在庫や欠品が頻繁に発生している</li></ul><h3 id="hc3c727994d">開発目標と条件</h3>私たちの開発目標は、毎週の予測にかかる工数を大幅に削減し、既存の予測よりも精度を向上させることで、間接的に過剰在庫や欠品の発生を抑制することでした。 開発条件：<ul><li>予測期間：30日間</li><li>予測単位：SKU単位（商品よりも細かい単位）</li><li>出力：販売数上位500SKUの予測</li><li>重視する需要変動要因：季節性イベント、販促期間</li><li>開発手法：Claude Codeを用いたバイブコーディング</li></ul>このプロジェクトは社内検証も兼ねており、ジュニアや非エンジニアでもAIを活用した開発ができるかを検証する目的もありました。

<h2 id="h5868b42986">Phase1での試行錯誤と失敗</h2><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/f14cb80bb1784aeb960fdb7b3c436b9c/Phase1%E3%81%A6%E3%82%99%E3%81%AE%E8%A9%A6%E8%A1%8C%E9%8C%AF%E8%AA%A4%E3%81%A8%E5%A4%B1%E6%95%97.png?w=800&amp;h=533" alt=""><h3 id="h201a830600">初期のアプローチ</h3>Phase1では、以下の前提で開発をスタートしました。 技術的前提：<ul><li>予測手法はProphet（Meta社製）を使用</li><li>イベントの影響はパラメータで指定</li><li>予測精度を測る指標はRMSEを採用</li></ul>開発手法：<ul><li>Claude Codeを使ったバイブコーディング</li><li>その場その場で思いついた指示を口語で出す</li><li>明確な開発計画なし</li></ul><h3 id="hf58b5ccdcd">一見良好だった結果</h3>Phase1の結果は、表面的には非常に良好でした。販売数上位500SKUのうち大多数でRMSEの値が5以下という指標上の精度を示し、予測処理も数分で完了するようになりました。当初は「うまくいった」と感じていました。<h3 id="hc02df7f74c">問題の発覚と衝撃</h3>しかし、問題が明らかになったのは、お客様からの指摘でした。 「実際の販売数と予測数に大きな乖離があるのですが...」 この言葉を聞いた時の衝撃は今でも忘れられません。改めて結果を確認すると、確かに予測と販売実績の誤差は、私たちのスクリプトによる予測とお客様による予測で、それほど差がありませんでした。RMSEの数値は良いのに、実際のビジネス要求には応えられていなかったのです。<h3 id="h5368c834ab">根本原因の分析</h3>お客様の指摘を受けて原因を深掘りした結果、複数の根本的な問題が明らかになりました。 1. 予測手法の選択ミス Prophetは毎日安定して売れている商品で、1〜2年程度の販売実績がある場合に威力を発揮します。しかし、お客様の商品は間欠需要（販売実績が0の日が続く）が主体でした。つまり、商品の販売パターンがProphetの前提条件に合っていなかったのです。 2. 指標選択の問題 RMSEは販売数量が少ないと数値が低く出やすく、「精度が良い」と誤認しやすい構造的な問題を抱えています。私たちは技術的な指標に満足してしまい、実際のビジネス要求との乖離に気づけませんでした。 3. データの理解不足 カテゴリ情報が不完全で、販売終了した商品のデータも正確ではない可能性があり、1SKUあたりのデータ履歴も想定より少なかったのです。 4. 開発手法の問題 バイブコーディングによる計画性のない開発により、全体設計が欠如し、不要な機能や使われない関数が大量に生成されました。スクリプトの品質も悪く、調整による変動なのかバグによる変動なのか判断できない状況でした。<h3 id="hdd9987ed50">バイブコーディングの限界</h3>この失敗を通じて、バイブコーディングの限界も明確になりました。 お客様の指摘を受けてから修正を試みましたが、バイブコーディングで作られたコードでは適切な修正ができませんでした。パラメータ調整を試みても思ったように予測値が変化せず、全体で予測値が狂っていくような状況でした。また、予測値について抑制や補正の機能を追加しようとしたところ、使われていない関数を修正したことで動作しなくなるなど、適切に調整できない、修正箇所がわからないといった状態に陥りました。 実装方針の一貫性がなく、デバッグやメンテナンスが困難になっていたのです。何より問題だったのは、「動くものができた」という達成感に満足してしまい、本質的な問題への気づきが遅れたことです。

<h2 id="hf5eb1f57a4">Phase2での改善と学び</h2><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/733c6f527aed438d88ce3c7a9bea5643/Phase2%E3%81%A6%E3%82%99%E3%81%AE%E6%94%B9%E5%96%84%E3%81%A8%E5%AD%A6%E3%81%B2%E3%82%99.png?w=800&amp;h=533" alt=""><h3 id="hd2d1af3a14">アプローチの根本的見直し</h3>Phase2では、Phase1の失敗を踏まえて抜本的に改善しました。 技術的改善：<ul><li>予測手法をProphetに固定しない</li><li>予測精度はCVRMSEと予測と実績の絶対誤差で評価</li><li>販売実績データの特徴から4つのグループに分類し、それぞれに最適な予測手法を適用</li></ul>使用手法：<ul><li>MSTL+ETS</li><li>Croston法</li><li>Prophet</li></ul>販売パターンを解析し、間欠需要、新商品、在庫制約、多重季節性などの特徴に応じて手法を使い分けるアプローチに変更しました。<h3 id="hd695bd9d12">計画的な開発プロセスの導入</h3>開発手法においても大きな改善を行いました。バイブコーディングから脱却し、計画的な開発プロセスを導入しました。 計画的な開発プロセス：<ol><li>事前の開発計画策定</li><li>簡易設計書の作成</li><li>実装前の認識合わせ</li><li>コードレビューの実施</li><li>リファクタリングの組み込み</li></ol>AIツールの効果的な活用：<ul><li>Claude Code：実装作業</li><li>ChatGPT：コードレビュー</li></ul><h3 id="h62ab4e6eec">レビューフローの確立</h3>効率的なレビューフローも確立しました。 レビューフロー：<ol><li>ChatGPTにコードや出力を渡してレビューを実施</li><li>レビュー内容をマークダウンファイルに出力</li><li>Claude Codeで読み込み、レビュー内容について質問を生成</li><li>質問をChatGPTに渡して質疑応答</li><li>Claude Codeで実装方法を検討</li><li>開発計画にタスクを追加</li><li>修正や調整の実施</li></ol>このフローにより、AIツール間での知識共有と品質向上を実現できました。<h3 id="h863c82052d">データドリブンな改善</h3>技術面では、様々な補正機能を追加しました。 補正機能の追加：<ul><li>カテゴリ情報による傾向補正</li><li>イベント影響度の期間とカテゴリ別調整</li><li>異常値の抑制機能</li><li>イベント専用品の期間外除外</li></ul>データ品質の向上：<ul><li>学習対象を販売数上位1000SKUに拡大</li><li>直近販売実績による対象絞り込み</li><li>終売データと販売実績の整合性確認</li><li>出力を予測数上位500SKUに変更</li></ul><h2 id="hfbdae7ba67">開発結果と成果</h2>Phase2での改善により、大きな成果を得ることができました。 精度面での成果：<ul><li>CVRMSEと絶対誤差ともに、お客様の予測手法を上回る結果</li><li>5つの重要イベント全期間で、お客様の予測より誤差を削減</li><li>予測の当たり外れとSKUの特徴に相関が見られるように</li></ul>運用面での成果：<ul><li>販売数上位1000SKUの学習と予測数上位500SKUの出力を約6分で完了</li><li>パラメータ調整で期待通りに結果が変わるように</li><li>大きな外れを抑制しつつ予測精度を底上げ</li></ul>開発プロセスの改善：<ul><li>再現可能で保守しやすいコード</li><li>明確な設計思想と実装方針</li><li>効率的なレビューサイクル</li></ul>

<h2 id="h68c92673e9">需給予測モデル開発で学んだ教訓</h2><img src="https://images.microcms-assets.io/assets/d4e25007543940f0849c6e5f6c46811d/263d23766c0345cdaabd934a52a361e8/%E9%9C%80%E7%B5%A6%E4%BA%88%E6%B8%AC%E3%83%A2%E3%83%86%E3%82%99%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%A6%E3%82%99%E5%AD%A6%E3%82%93%E3%81%9F%E3%82%99%E6%95%99%E8%A8%93.png?w=600&amp;h=600" alt=""> このプロジェクトを通じて得た教訓をまとめます。<h3 id="h98c8528915">1. データ理解の重要性</h3>最も重要な学びは、モデル開発前にデータを十分に精査するフェーズが必要だということです。データの物量だけでなく、質（完全性）と予測単位での状態把握が重要であることを痛感しました。 今回のプロジェクトでは、履歴が長くても安定した販売実績のないデータの予測は難しいということも学びました。間欠需要に対する要因分析（偶然売れたのか、セールによるものか）や、外部要因（賞味期限、セール情報）の整備が必要です。<h3 id="h9489050ea4">2. 指標選択の重要性</h3>技術的な指標と業務要求の乖離に注意が必要であることも大きな学びでした。「精度が良い」という状態について、顧客との共通認識を持つことが重要です。 RMSEのような技術的な指標だけでなく、ビジネス要求に直結する指標を選択することの重要性を学びました。顧客の解決したい問題から逆算した指標設定、現行手法との比較による目標値設定、見切り条件の事前合意が必要です。<h3 id="h6641aae22d">3. 計画的開発手法の必要性</h3>バイブコーディングでは品質確保が困難であることも明確になりました。一般的なプロジェクト管理手法を導入することで、開発効率と品質が大幅に向上することを実感しました。 特に、販売実績データの状態から逆算して予測手法を選択することや、予測手法だけではなく傾向から係数で補正をかけることは、調整がしやすく非常に有効でした。<h3 id="h49fa0fb52e">4. AIツールの適切な活用</h3>AIツールは非常に強力ですが、適切な制御と組み合わせが重要であることも学びました。複数AIツールの役割分担、構造化されたレビューフロー、開発記録の体系化により、AIの能力を最大限に活用できることがわかりました。 特に、開発の記録をテキストで残すことは、AIとの継続的な協働において非常に重要です。AIには人のような記憶がないため、人がやる以上にドキュメントを残すことが必要であることを実感しました。

<h2 id="h9be0c3393d">おわりに</h2>今回のプロジェクトは、技術的な成果だけでなく、AI開発の新しい可能性と課題を見出す貴重な経験となりました。失敗から学んだ教訓を活かし、より効率的で質の高いAIを活用した開発手法を確立していきたいと考えています。 AIを活用した開発は、従来の開発手法とは異なる新しいスキルセットや考え方が求められる一方で、適切にアプローチすれば従来では困難だった速度と質での開発が可能になります。 私たちAzitでは、この経験を踏まえてForecastXをはじめとする製品開発を進めており、AI活用開発の手法をさらに洗練させていく予定です。AIを活用した開発に興味のある方、一緒に新しい開発手法を模索していきたい方は、ぜひお気軽にお声がけください。 最後まで読んでいただき、ありがとうございました。

AIデータサイエンティスト

AIを活用した需給予測モデル開発で学んだこと

Iwase Takeshi

Azitを卒業し、別の場所で挑戦を続ける“ex Azit”の仲間たちに、Azit代表の吉兼が話を聞くインタビュー企画「ex Azit」。第二弾に登場していただくのは、株式会社HRBrain 取締役CFOの作井 英陽さんです。 投資銀行でキャリアを重ね、2018年にAzitへ。財務担当執行役員／コーポレート本部長として、会社の成長に伴走しながら資金調達とコーポレート体制をけん引した作井英陽さん。その後JDSCやHRBrainの取締役も務めた彼に、Azit時代に培った視座と、今なお印象に残る「Love」の意味を聞きました。

<h2 id="h5c4d85c8fd">PROFILE</h2>作井 英陽さん 東京大学経済学部卒。2013年よりUBS及びメリルリンチにおいて投資銀行業務に従事。2018年より株式会社Azitにて財務担当役員。2020年より株式会社JDSCの取締役CFOとして創業2期目から6年間のIPO前後の経営を担い、ソフトバンク、SCSK、ダイキン工業、中部電力といった大手企業との戦略的な資本業務提携や、複数のM&amp;Aの実行等を通じて、企業価値向上に貢献。経済産業省 スタートアップ・ファイナンス研究会の理事を務める等、未上場からグロースの資本市場の活性化にも尽力。2025年より株式会社HRBrain取締役CFOに就任し、現在に至る。

<h2 id="h86933b02c2">参画の決め手は『人』。カルチャーのシンクロが背中を押した最終面接</h2>ー 本日はよろしくお願いします。まずは、当時Azitでどのようなことをされていたか教えてください。 もともと投資銀行にいて、2018年にAzitに入社しました。初めての事業会社でしたね。Azitでは、コーポレートマネジメントと資金調達や財務戦略などを統括していました。 当時のAzitは配車プラットフォーム「CREW」のトラクションがものすごい勢いで伸びていた時期です。それこそ、JDSCが年間で追っていたような30〜40%のグロースが、月次で叩き出されているような驚異的な時期でしたね。そういったKPIを前提に、ファイナンスにトライしていました。 ー あの成長は、まさにtoCならではでしたよね。当時、まだまだ経営体制が整っていない中、CFOは最も大事なポジションだと定義して採用活動を行っていました。ちょうど、現共同代表の山口や他CXO候補者の方々が内定していたくらいの時期ですね。CREWは、特にファイナンスが難しい事業で、この領域は海外の事例を見ても、資金調達力が事業成否を左右していることは確かでした。資金調達専任の人が必要だと思っていたし、周りからもCFOにいい人が入ると良いね、という言葉を言われていました。半年以上探してたくさんの方にお会いしてきたのですが、その中で、作井さんに会ったときに、すごく誠実さを感じたのを覚えています。 ある意味、金融出身の人ならではの「色」というのはありますからね。 ー そうなんです。どちらが良い悪いではなくて、Azitは結構価値観やカルチャーを大事にしているのですが、金融業界の方々とは考え方や大事にするポイントが少し異なり、フィット感の高い方を見つけるのに苦労していました…。当時の僕たちとお話をしてくださる方って、それこそスタートアップへの関心が高い、感度の高い方ではあったと思うんです。それだけでなく、人格者でもある作井さんにお会いして、「この人にオファーしたい」と素直に思いましたね。 それは嬉しいね。自分自身のやりたかったこととしては、もちろんスタートアップというものに憧れていたこともあるし、当時世界にはUberやDiDi、Grabなどがある中で、Azitは日本発として立ち上げて、Eight Roadsなどからも資金を受けている段階。ただ、まだ20〜30人くらいの規模で、ここからシリーズBに突き進むようなフェーズは、自分のようなファイナンシャルな目線からみても面白いと感じました。そして何よりもやっぱり、人が魅力的だと思ったので、入社を決めました。 ー 最終面接のあと、メンバー5人くらいに面談をしてもらったのを覚えています。 そうそう。その時驚いたのは、示し合わせていてもできないようなシンクロ率を発揮していたこと。組織やカルチャー、人に対することを、同じような言葉選びや表現をしていたのが、当時の自分から見るとすごく良かったんですよね。 ー 当時から、示し合わせてはいないけど、皆が同じ方向を向いている組織ではありましたよね。 あと、入社してすぐの合宿も印象的でした。熱さも含めて、いわゆるスタートアップの合宿らしくて良かったですね。その後組織は何倍にも拡大していきましたが、大きくなってもリファラル率が高かったし、今もすごく参考にさせてもらっている最終面接のやり方なんかも、変な人が入らない仕組みがしっかりと存在していて、組織の成長に大事なことが備わっているな、と感じました。 ー 最終面接のやり方は、僕自身のこだわりでもあります。（詳しくは<a style="color:#1155cc" href="https://love-from.azit.co.jp/article/99rrad0xu" target="_blank" rel="noopener noreferrer">こちらの記事</a>でご紹介しています） 僕自身、Azitのときは組織作りに比重を置きすぎたと思って、実はその後の選択では逆張りしてみたんですが、やっぱり上場後に人がたくさん辞めたりしたことも含めて、組織カルチャーへの投資は大事だなと改めて思わされましたね。 ー 組織作りって、なかなかROIで考えにくいですもんね。 少し語弊があるかもしれませんが、バランスの取れた組織を作るのってすごく大変で。ある意味、ぬるい組織を作るのは簡単なんですよね。事業成果を出すために軍隊的な組織を作るのも簡単。そうではなく、事業成果にコミットしつつ心理的安全性も保てるようなバランスの取れた盤石な組織、いつかは成功させてみたいですね。

<h2 id="he75d2bc01c">資金調達、VALUEの再定義。Azitで学んだこととは</h2>ー Azitで印象的だった出来事はありますか？ 資金調達に関してはきつかったですよね。結果というよりは、プロセスのキツさがありました。 でも、印象的だったのは、Azitのメンバーが当時もすごく前向きだったことです。どんな状況でも心が折れないというか、前を向いてやり切る気持ちがありましたよね。 正直、僕個人に関して言うと、当時ピボットに関しては覚悟が足りていなかった部分があったと思います。ライドシェアを前提に大きなファイナンスで動き続けてしまったし、今考えるともっと違ったプランも提示していくべきだったな、と思う所はありますね。それもあって、JDSCでは圧倒的なコンサバファイナンスだったのですが（笑） ー たしかに、あんなにしんどいファイナンスはなかったですが、ある意味では、あんなに楽しいファイナンスもなかったとは思うんです。もちろんそれは「funny」ではないのですが。映画を見ているような迫力のファイナンスという意味では印象的でしたし、体験価値も高かったと思うんですよね。 それはそうだね。あと印象的だったのは、バリューの再定義のプロジェクトをやったときのこと。当時のバリューを定義するとき『Love』という単語について、深く話し合った記憶があって。 Loveって、日本人の多くは少し遠慮しちゃうというか、ちょっとまっすぐ捉えられない恥ずかしくも思ってしまう単語だと思うんですよね。でもAzitの皆は当時もそして今も、その単語を違和感なく使える。経営陣がその雰囲気を体現していて、それが僕は好きだった所です。自分はちょっと気恥ずかしさを感じてしまうので（笑） ー まあ、普通ちょっと恥ずかしいというのも理解しています（笑） でも、それを「ちょっと恥ずかしいよ」って言える心理的安全性もAzitにはあるよね。それがやっぱりめちゃくちゃ強い部分だと思うし、誰かが入社したとき、その人がDay1から安心して活躍できる組織のOSだと思うんです。 このオウンドメディアのタイトルもLove from Azitで「あぁ、あのVALUEが残っているんだ」と思うと安心しました。 ー 今のVALUEも『Love &amp; Respect』なんですけど、たしかにその頃から変えたんでしたっけ。 当時『Respect For All』だったのを変えたんだよね。吉兼がこだわってたのが印象的で。社会に対する自分たちが大切にしていることとして真剣に語っていて、そこがAzitらしいなと当時から思っていました。 そういうハートウォーミングな部分と、一方で今のスタートアップ業界で見ても遜色ないレベルのメンバーたちが、かなりの強度で毎日を過ごしていて。もちろんマーケットやタイミングで結果は変わってしまいますが、ハードにやりつつマネジメント陣も平気でいじられたりするような温かい雰囲気って、実はすごく作るのが難しいんですよね。逃げずにやり切るスタンスも含めて。それがAzitで印象的でした。<h2 id="h964cf142be">泥臭さとプロダクト開発の両輪。そしてその先へ</h2>ー 現在の成長された作井さんとして、Azitの経営に対してアップデートできる要素を考えるとしたらどういう所でしょうか。 今のAzitがやっているような物流・サプライチェーン領域に入っていくという選択はとても良いなと思っています。エンプラの方々、特にマネジメント層のそこへの危機意識ってすごく高いですし。モダンなUIでその領域のシステム開発ができる人たちってなかなかいなくて、だからこそJDSCのようなAI系のコンサル開発企業も重宝していただけるわけですが、Azitもその領域のチャンスは多分にありますよね。 もし何か提言するとしたら「もっと泥臭く覚悟を決めてやってもいいんじゃないか」ということでしょうか。例えば、システム開発領域なんかも。現状コンサルをやっている企業には、なかなかAzitのようなテックスタックがある企業はないですし、そこにはまだスペースがあるはずだと思います。 ー ありがとうございます。たしかにですね。ちょうど最近需給予測のプロダクト（<a style="color:#1155cc" href="https://azit.co.jp/news/kUdXzGqa" target="_blank" rel="noopener noreferrer">Azit、生成AIを活用し低価格・短期間で導入できる需給予測プラットフォーム『ForecastX』を正式リリース</a>）を出したのですが、それによって対象企業はかなり広がりました。物流だけでなく、製造業や流通業の方にもアプローチすることができるようになり、よりセールスの力を活かしやすくなりましたね。 また、需給予測をした後のS＆OPの業務、例えば在庫管理や発注管理、生産量を決めるなどのプロセスにExcelを使っているような企業の方が、DXしたいというお話をいただいたりもします。どこまでをプラットフォームで解決して、どこまでをカスタマイズして解決していくかを決めていかなくてはいけないフェーズにありますよね。

ー これからAzitに興味を持ってくれる方へ、メッセージをお願いします。 Azitの魅力は大きく2つあると思っています。1つはマーケットですね。物流・サプライチェーンという領域、特に日本でいうと、全産業を並べてもマーケットサイズがかなり大きいし、労働人口の減少がクリティカルに響いてしまう分野でもあるのですが、それをモダンな技術を駆使して解決できる手法があるかというと、まだ多くはありません。例えば、ヘルスケアや通信領域などは各企業の中にもそういった部分に長けている人材も多いですが、物流領域はそうではないので、スタートアップとしてジョインして大きな解くべき課題に対して自分たちがどれだけ求められているかっていうマッチが高い領域なので、そういうマーケットに身をおいた方が成長する機会が多いだろうと思うんですよね。 2つ目は『人』です。スタートアップに飛び込むからには、一緒に働く人から大事なものを学んだほうが良いと思っています。Azitにいるメンバーは、本当の意味でスタートアップらしいというか、諦めない素質や胆力があって「この仮説がだめならこっちをやる」という、スタートアップらしい事業作り、スタートアップ作りの真髄は、皆から学べると思います。 どちらも大切ですが、特に後者はかけがえのないものだと思います。僕自身もAzitで強く学ばせてもらったところですし。 ー ありがとうございます。教科書的な意思決定の下支えとなる地盤のようなものですよね。 まさに。『ハードに働く』とかは、プロフェッショナルファームでも事業会社でも経験している人はしていると思うし、もしそういうハードワークができる人はもちろんぜひやったら良いと思うんですけど、それだけじゃない、真の意味で試されるときってあると思っていて。そういう局面を体験できるのって良いと思うんですよ。それは、決して心が追い詰められるような意味ではなくて。Azitって、その緊張感と楽しさと温かさ、それこそLoveのような気持ちを持って働いている人たちがいるから、きっと安心して学べるはずです。 聞き手：吉兼周優　編集：坂井華子

<h2 id="hda492ffe51">採用情報</h2>Azitでは、各職種で採用を行っております。詳細は、以下のページをご覧ください。 <a style="color:#1155cc" href="https://herp.careers/v1/azitinc" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc</a>

【ex Azit】Love & Respectがつなぐ組織。HRBrain取締役作井さんが語る、Azitの軌跡。

Love from Azit 編集部

Azitは今年9月、需給予測プラットフォーム「ForecastX」をリリースしました。今回のインタビューは、COO 山口が読者視点に立ち、ForecastX誕生の背景から今後成し遂げたいこと、組織についてなど、さまざまな面をCEO 吉兼に質問していきます。 ForecastXプレスリリース：<a style="color:#000000" href="https://azit.co.jp/news/kUdXzGqa" target="_blank" rel="noopener noreferrer">https://azit.co.jp/news/kUdXzGqa</a>

<h2 id="h7e982eb72b">上流から変えていく。Azitが今参入する理由</h2>ー 今日はよろしくお願いします。Azitではもともと物流支援のDeliveryXを展開してきましたが、生成AIの盛り上がりもあり、需給予測プラットフォームのForecastXを始める意思決定をしたと思います。需給予測やサプライチェーンマネジメントの領域に、なぜ“今”、スタートアップであるAzitが参入することに価値があると考えたのか、聞かせてください。 2年ほど前から生成AIが盛り上がり、これからの時代、各社が生成AIによって変革できる領域に注力し、ビジネスモデルも変わっていくのだろうと感じていました。 Azitでは以前から物流・サプライチェーン領域をやるという方針は出していたものの、当初はラストワンマイルや配送の領域にフォーカスしていました。しかし、その領域に限ってしまうと、生成AIによる変革の余地はそれほど大きくないのでは、という感覚もあり、特に物流・サプライチェーンという市場は、日本に限らず世界的にも労働者が不足していく中で、顕著にAIに代替されていくプロセスが進むと感じました。 そうした前提から、ラストワンマイルだけにフォーカスするよりも、物流・サプライチェーン × エンタープライズ企業に注力すべきだと判断しました。というのも、日本の物流やサプライチェーンは、8割方を大企業が作っている市場です。そうした大企業が抱える課題に生成AIによる大きな変革を重ねる。そのためには、アルゴリズムや数学的な処理だけでなく、生成AIならではの対話的な解決の仕方や、AIエージェントになったときに本当に便利なものは何かという発想も必要です。こうしたことを昨年末ごろから考え始め、今年に入って事業化しました。 なぜ「需給予測」なのかは、AIエージェントを作っていくという観点と、大企業の課題を解決していく観点の2つがあります。まずAIエージェントの観点で言うと、エージェントはどんなデータを取り込み、何を学習していくのかが非常に重要です。ラストワンマイル配送は、文字通り最後の部分です。しかし、物流・サプライチェーン全体で見ると、例えば、どれくらいの需要があるか、それに対してどんな販促活動をし、どれくらいの売上を作りたいのか、という上流の設計があり、その結果として「これくらい売るならこれくらい在庫が必要」「これくらい仕入れなければならない」「これくらい製造しなければならない」という流れを経て、最後に物流のプロセスに入っていきます。大きな倉庫からディストリビューションセンターを経て、私たちの自宅や店舗に届く。この長いプロセスの中で、いちばん最初にあるのが「どれくらい需要があるのか」というデータです。このデータが起点になり、すべての在庫や物流網の設計が決まっていきます。 人手不足の中でAIにより自動化してほしい部分は、どれくらい在庫や発注が必要で、どれくらい物流を動かさなければならないのか。そういった需給予測の意思決定の部分だと思います。企業活動の裏方であるサプライチェーンの意思決定を効率化し、少ない人手でも意思決定できるようにすることが、今後ますます重要になると考えました。 同時に、大企業にとってビジネスインパクトも大きい。大企業ともなると、年商の数％単位で在庫ロスや物流コストのロスが発生し、その損害は大きなものになります。だからこそ、ラストワンマイル配送に絞るより、課題意識も財務インパクトもより大きい領域に挑むべきと考えました。私たちのケイパビリティとも合致しますし、大企業の課題解決を進めるために、需給予測のデータが集まってくるプラットフォームにしよう、という発想でスタートしたのがForecastXです。

ー なるほど。サプライチェーン領域というのは非常に広く、外部の方からも「他にもプレイヤーがたくさんいますよね」「競合はどこですか」等とよく聞かれます。私たちがサプライチェーンマネジメントに取り組む際、まず向き合う市場はどこだとイメージしていますか。 需給予測というフィールドは基本的にSMB向けではなく、エンタープライズ向けの領域だと考えています。というのも、全国に何万店舗もあるコンビニ、何千店舗もあるドラッグストアの需要予測と、1店舗展開の小売店の需要予測では、財務インパクトが大きく違いますから。大きい会社ほど、投資しやすい領域ですよね。 そういった領域を、これまではSIerが中心となり、初期コストに億単位のコストが必要なケースや、運用コストもまた年間億単位であるケースが多くありました。それでも、年商が何百億、何千億、何兆規模の会社にとっては、年間数億を払って10億円以上のロスが減るなら価値があると考えられ、投資として成立していました。 ここ5〜10年、特にコロナ以降海外では、Palantirを筆頭にエンタープライズを攻略するスタートアップが出てきましたが、日本国内ではまだそのレベルの企業が少ないと思っています。今のAzitの立ち位置は、国内のエンタープライズ企業に対して、SIerとコンペティションをしている状態です。 こういう時の戦い方としては、データを取り、モデルを学習させるという本質的な強みづくりに加え、スタートアップならではの“急成長する装置”が必要だと考えています。例えば、Pairsが立ち上げ期にFacebook広告を徹底的に活用し、安価にユーザー獲得をすることで一気に伸びましたよね。AirbnbもCraigslistをうまく使って初期ユーザーを獲得しました。そうした“最初の成長装置”は、スタートアップに不可欠だと思っています。 現在のB2Bエンタープライズセールスでそれを実現するアービトラージは、生成AIを用いることで「これまでなかった商品の作り方」ができる点にあると考えています。実際、ForecastX開始後に取引先となってくださった企業様や商談中の企業様が私たちを評価してくれる理由の一つが「何億円もかけず、段階的かつ小さなサイズで始められる」という点です。 大企業の責任者の目線では、いきなり何億もかけてサプライチェーン全体を改善するのは怖いことでしょう。例え実績のあるSIerであっても、自社で本当に成功するか100％の確信は持ちづらい。そこで私たちは、例えば「1モデルの構築に3000万円・半年かかる」という市場相場に対して「300万〜500万円でミニマムな予測モデルを構築できる」という提案が可能です。これは、サプライチェーンを段階的に改革したい企業にとって、非常に取り組みやすいと考えています。 これを実現するために、生成AIを予測モデル開発体制に活用し、以前よりも早く・安く・個社ごとに開発できるようになっているのが大きいですね。もちろん「AIがエンジニアに置き換わる」世界になるとは思っていません。エンジニアやデータサイエンティストは今後も絶対に必要ですが、生成AIによって彼らがより生産的に、半分以下のコストで成果を出せるようになる。その生産性向上によって、小さなパッケージから提案できるようになっています。生成AIを活用した開発体制を最速で構築し、最先端のAIを取捨選択して実装できるのは、スタートアップだからこそ可能であると考えています。 ー これからForecastXを知っていただき、検討してくださる企業も出てくると思います。その中で、スタートアップとして掲げるべき大きなビジョン、ForecastXを通じて目指すことを教えてください。 Azitでやりたいことは、創業時から変わっていません。「日本の課題解決がしたい」「日本だからこそ作れるサービスを作りたい」これに尽きるんですよね。これは、決して日本国内の市場に限定したいという話ではありません。はじめにやっていたB2C事業のCREWでも、海外ライドシェアとは違う“日本ならではの体験”にこだわってきました。B2Bでも同じです。日本のサプライチェーンマネジメントは極めてExcelドリブンなんですよね。各社に“秘伝のExcelファイル”があったり“マクロ”で運用されていて、週次発注の1万行のうち1行間違えただけで数百万円のロスになることすらあるのが実情です。 こうした「日本企業特有の課題感」にフィットするソリューションを作ることができれば、海外スタートアップや大手SIerとも違う立ち位置を取れると考えています。日本社会全体がインフレでコストが上がり続ける中、最終価格を10円でも下げられるような構造を生み出せたら、それは社会貢献にもなります。サプライチェーン領域は国内だけでも何十兆円規模の市場。そこで大企業の課題を解くこと自体が、大きなミッションになっていると考えています。 合わせて、マルチプロダクトでの展開も考えています。需要予測はサプライチェーンプロセスの最初に位置するデータです。それを起点に、販売計画、在庫最適化、発注最適化、生産DX…と、順番に下っていく。その各プロセスを改善できるプロダクト群をつくっていきたいと考えています。それらのデータが適切に連携され、システムとしてもAIが取り込める構造にする。そういったことに取り組んでいきたいです。 つまり、私たちが挑戦しているのは、物流・サプライチェーン全体の変革。需要予測は、その起点となるデータです。来年には在庫や生産計画などの領域に関するプロダクトも展開していく計画です。実際、現在お話ししている企業様からも、そういった要望は強く感じています。 ー そうですね。製造やサプライチェーンマネジメントは、世界的に共通する重要なマネジメント概念です。日本は1980年代に「ものづくり大国」として世界的競争力を有するようになりましたが、いまはその競争力が失われつつあります。紙やExcelからの脱却が遅れ、労働人口が減り、地政学的リスクでサプライチェーンが分断される中で、日本は特有の課題を抱えています。しかし、そこに取り組むことは日本にとって良いだけでなく、世界に通ずるサービスを生むチャンスでもありますよね。生成AIという外部要因が、僕たちにそのチャンスを与えてくれた。だからこそ、足元の課題に真摯に向き合いつつ、視野を広げれば久々に「日本から世界だ」と胸を張って言える市場だと思っています。

<h2 id="h5d495d685f">人の力で築かれた日本の物流に、AIで“第二の進化”を。</h2>ー 読者の方のために“リープフロッグ現象”について少しお話させてください。リープフロッグ現象は、簡単に言うと「これまでなかったものを、1段階目を飛ばして一気に2段階目以上に進化する」こと。これが国単位で起きた例が、中国です。中国はVHSを経ずに、いきなりDVD・Blu-rayへと進化しました。そして、ガラケーがないところから、いきなりスマートフォンへ。私が中国にいた頃、連絡手段は電話とSMSだけでしたが、気づけば皆がiPhoneを持つようになっていました。全員が新しいテクノロジーを一斉に使い始めたことで“ネイティブ世代”が一気に生まれ、そこからTikTokのような世界的サービスが生まれていきました。 アメリカでは最先端技術と資本が西海岸を中心に集まり、常に新しいサービスが生まれています。一方、日本は1980年代に偉大な先人たちが郵便や宅配のような超精密な物流インフラを築き上げ、それはPCやインターネットが出てきても変わりませんでした。そうした“人の力に依存した高精度インフラ”を持つ国だから、今こそ生成AIで一気にジャンプアップできるチャンスがあると思っています。 Excelは、悪く言ってしまうと“紙をデジタルにした”ツールです。人が頑張って計算していたことを早くしただけ。しかし生成AIを使えば、人間が計算しきれない部分を一気に塗り替えられます。「DXで管理を効率化」といったレベルから「AIネイティブ」なレイヤーへと、一気にジャンプできる。そして、生成AIネイティブのサービスを使う企業が増えれば、そのプロバイダーは大量のユースケースをもとにサービスを磨き、世界トップレベルに成長していく。結果として、Azitが挑戦しているサプライチェーンマネジメントの分野は、今の日本だからこそ世界で戦えるチャンスのある市場であり、長年の課題を一気に解決できる可能性があると考えています。

ー 組織の話も少し。今後DeliveryXやForecastXに限らずサービスが拡大して大きくなっていくと思いますが、生成AIが進化して変わっていくということも踏まえ、どのようなマインドで働くことで私たちが達成したいことを成し遂げられると考えていますか？ まず、会社としては、半分SaaS、半分SIの「ハイブリッド型」になると考えています。AIネイティブなSaaSをつくるのがメインのソリューションですが、セールス、カスタマーサクセス、エンジニア中心のプロダクト開発が連動し、成果にコミットする文化を全チームで共有することが重要です。 ただ、すべてがSaaSで解決できるわけではありません。需要予測モデルは、産業や会社、商品やエリアによって動きがまったく異なります。なので、個社ごとに最適化してつくっていくプロジェクトも必要です。また、サプライチェーン領域はDXが進んでいない企業も多く、例えば「秘伝のマクロが残っていて、このマクロを作った人が辞めたら、誰も触れない」というケースなんかがあったりします。 そのため、単にSaaSを導入するだけでなく、周辺の仕組みも見直し、ワークフローから一緒に変えていく必要があります。ビジネスサイドとエンジニアリングサイドの両方で課題解決できる“プロフェッショナルサービス”チームは欠かせません。日本でも最近、このタイプの職種は増えていますが、Azitはまさにそうした組織を構築できていて、この拡大を目指しています。 DeliveryXで培った知見を活かしつつ、今はForecastXに注力するフェーズです。DeliveryX導入企業にも、別のサプライチェーン課題を横展開していきます。そのため、これからAzitに入る人の中心業務は、ForecastX関連になると考えています。ビジネスサイドは、企業ごとに異なる課題を理解し、何億・何十億というビジネスインパクトをどう導入・実現するかを設計する。エンジニアやデータサイエンティストは、現場になじむシステムをつくりながらAIで解ける部分を最大化する。プロフェッショナルサービスチームは、課題の定義から導入設計までを一緒に考える。そんな組織を作りたいと思っています。 ー 最後に、ForecastXについて伝えたいことはありますか。 まず伝えたいのは、この市場は本当に熱いです、ということですね。AIを使ったソフトウェア開発のスピードはとにかく早い。以前なら1週間かかっていたUI修正が、その日の夜にはもう反映される。デザイナーやエンジニアが徹夜することなく、翌日には最新のデモを見せられます。チーム全体の生産性が上がり、フィードバックがすぐ返ってくる。つくる側も届ける側も、純粋に楽しいですよね。この変化の時代に関われるのは、面白いことだと思っています。

<h2 id="h1afe451c43">さいごに</h2>インタビュー後に筆者から「今のAzitとForecastXは何合目くらいにいるでしょうか？」と質問したところ、「何合目というよりは、“今エベレストを見つけ、その登り方が分かった”ような感覚です。」と、ワクワクするような回答をしてくれた2人。 これからのAzit、ForecastXにご期待ください！ Azitでは、各職種で募集を行っております。気になっていただける方は、下記の採用ページをご覧ください。 <a href="https://herp.careers/v1/azitinc" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc</a>

需給予測プラットフォーム開始の意思決定。Azitの「ForecastX」が目指す景色とは

Azitを卒業し、別の場所で挑戦を続ける“ex Azit”の仲間たちに、Azit代表の吉兼が話を聞くインタビュー企画「ex Azit」。第一弾は株式会社shizai代表の鈴木暢之さんをお迎えしています。 後編では現在経営されているshizaiでの組織作り、Azitカルチャーへの想い、そして、これからAzitにジョインする人へのメッセージを伺いました。 ▶前編はこちら <a href="https://love-from.azit.co.jp/article/99rrad0xu" target="_blank" rel="noopener noreferrer">【ex Azit】前編 | Azitを経て起業を選択。shizai代表鈴木さんが振り返るAzitの創業期</a>

<h2 id="h5c4d85c8fd">PROFILE</h2>株式会社shizai 代表取締役　鈴木 暢之（すずき のぶゆき）さん 新卒で株式会社電通に入社。国内/海外のエンタープライズクライアントの事業支援を担い、2016年末に退職。2017年よりライドシェアプラットフォーム「CREW」を運営する株式会社Azitに初期メンバーとしてジョイン。事業開発、オペレーション、CS、PR、コーポレート、採用/組織戦略等、プロダクト開発以外の領域全体を統括する経営メンバーとして活動後、2020年3月に退職。2020年10月に株式会社shizaiを創業。

<h2 id="h0d075aea15">“しんどさ”を楽しさと熱に変えるカルチャー</h2>ー shizaiとAzitで、組織づくりの観点で違いはありますか？ 「事業成長の過程で辞めてしまう人がいることは、一定仕方ないこと」と思えるようになったことですね。Azitは仲が良く、続ける人が多いカルチャーだったなと思っています。しかし、実際自分が経営していくとなると、どうしてもフェーズの変化の中で、個々人と組織があわなくなる局面も出てくるんですよね。 会社と本人の矢印を合わせたいとは思っていても、ライフステージの変化などで本人の方向が変わっていくこともある。そのときに、モチベーションが半減してしまっている人に残ってもらうより100%の力で取り組んでくれるメンバーで純度高く事業に向き合えている方が、結果的にチームとしてはワークする確率が高いと思っています。 もちろん採用した人には辞めてほしくないし、ずっと一緒にやっていきたいという気持ちはあります。ただ、以前よりは「その人自身の選択を尊重する」という考え方に明確にシフトしました。

ー 卒業した立場としてAzitに対して「こうなっていったら面白い」と思うことはありますか？ 良い意味で「変わらないでいてほしい」と思っています、特にカルチャーは。Azitって、いつどんなときも「ここからっす！」って言ってる会社だなと思っていて（笑）そういう空気感を持つ人たちが、最終的に勝つんじゃないかと思ってるし、僕自身もそうありたいと思っています。しんどいときに、なぜかテンション高く楽しんでる人がいる。そういう組織の強さを感じるし、見ているだけで元気をもらえるんですよね。 僕自身も、Azitにいたことで性格が変わった部分があると思っていて。もともとは、物事を頭で考えて「メリットはA、デメリットはB…」みたいに整理するタイプだったんです。でもAzitにいたことで、「わからないけど、とりあえずやってみるか！」みたいなマインドに変わっていった実感があります。 ー たしかに、僕は「考えすぎですよ」って人生で一番言った相手が、ノブ（鈴木さん）だった気がします（笑） 真顔で言えた年齢でしたからね（笑）組織については「変わらないでほしい」が本音です。事業に関しては、どちらかというと「堅く当たりそうなマーケットを狙う」会社ではなくて、「いろいろやっていたら、ひとつ大きく跳ねた」みたいな会社だと思っているので、今後もどかんと突き抜けてほしいですね。 ー 嬉しい言葉です。もちろん積み上げるべところは積み上げながらも、突破口を突き抜けていきたいですよね。 吉兼って、創業してから今まで、ずっと打席に立ち続けてきたと思うんですよ。10年もそれを続けている人って、かなり稀有だと思っていて。本当にすごいことだと思います。だからこそ、「ここからっす！」って本気で言える仲間じゃないと、その環境には向かないとも思うんですよね。

<h2 id="h82e9a3fb31">広がるキャリア。Azitの“その先”</h2>ー 今、Azitに入ることのメリットって何だと思いますか？ Azitは「人材の種類×年齢」みたいなマトリクスにおいて、かなりケイパビリティが高い会社だと思っています。たとえば「大企業出身×20代」とか「スタートアップ経験者×30代」とか、どういうバックグラウンドの人でも、適切なアサインをする感覚がAzitにはあるんですよね。 スタートアップに挑戦したいけど、「自分に合うか分からない」「入ってみたらミスマッチだった」みたいな話って、世の中にはよくあると思うんです。 でもAzitの場合は、そうならないようなアサインの妙がある。このくらいのボールを投げたらこの人はできるだろう、みたいな勘所に長けていて。だから、最初からミスマッチが起きることが無い気がします。そもそもミスマッチが起きそうな人は採用しないという判断も含めて、きちんとしていて。だからこそ、入社する人には最初から発射台が用意されていて、すごくいいなと思います。

ー ありがとうございます。そう感じてもらえていたなら嬉しいですね。 あと、Azitは、辞めた後の選択肢も広くなる会社だと思っていて。長く定着する人もいれば、起業する人もいる。もちろん辞めることを前提に働くわけではないけれど、「辞めたあとにも選択肢が広がる会社」だと思っています。 キャリアという意味でもすごく可能性が広いし、「人に優しい会社」という印象も強いですね。やっぱり、アサインが上手なんですよね。お互いがんばりましょう。

聞き手：吉兼周優　編集：坂井華子

<h2 id="hda492ffe51">採用情報</h2>Azitでは、各職種で採用を行っております。詳細は、以下のページをご覧ください。 <a href="https://herp.careers/v1/azitinc" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc</a>

【ex Azit】後編｜変わらない熱量、広がる選択肢。Azitがくれた“人に向き合う力”

Azitを卒業し、別の場所で挑戦を続ける“ex Azit”の仲間たちに、Azit代表の吉兼が話を聞くインタビュー企画「ex Azit」。第一弾は株式会社shizai代表の鈴木暢之さんをお迎えしています。 Azitの2人目の社員としてCREWの立ち上げ期を支え、その後起業して現在に至る鈴木さんに、当時のお話を伺いました。

<h2 id="hf0b532ce16">入社して最初の仕事は「自分の雇用契約書を作ること」</h2>ー 今日はよろしくお願いします。まずは自己紹介と、当時Azitでどのようなことをされていたかを教えてください。 株式会社shizai 代表の鈴木です。今日はよろしくお願いします。キャリアとしては、新卒で電通に入社し、2017年にAzitへジョインしました。社員として2人目の入社で、創業期から組織の成長過程まで携わり、2020年に退職。その後shizaiを創業し、代表を務めています。 Azitでは、最初はいわゆる何でも屋さん的なゼロイチポジションでしたね。ちなみに最初の仕事は「自分の雇用契約書を作る」ことでした（笑） ー 今考えると、当時は前職の業務とかけ離れたことをお願いしていましたね… そうそう。皆に得意な所をやってもらい、それ以外の部分を僕が拾っていくような感じでしたね。その後、組織が拡張してきたタイミングで、渉外領域をメインに担当しました。「会社の外のことは任せてね」というスタンスで、特にリーガルに軸足を置きながら動いていました。吉兼と一緒に組織作りにも取り組んでいましたね。 ー そうでしたね。その後、shizaiを創業したきっかけを教えてください。 もともと起業や経営には興味があったのですが、正直、当時は「これがやりたい！」という明確な事業はなかったんです。ちょうど退職のタイミングで本格的にコロナ禍に入り、その影響下だからこそ伸びそうな事業を20〜30個ほど考えました。その中でEC領域の伸びを感じていたことや、電通時代に印刷業・ものづくりに近い領域にいた肌感覚もあり、「まずはやってみよう」と創業に踏み切りました。

<h2 id="h758b0362c7">Azitだから経験できた創業期の“いろは”</h2>ー 起業にあたって、Azitでの経験で活きたことはありますか？ スタートアップの初期に携われたことで、採用やコーポレートづくり、株主とのコミュニケーションなどを経験できたのは非常に大きかったですね。 よく「創業期はカオス」と言われますが、実際にはやるべきことは明確で、それらを順番に整理して進めていく、というシンプルな構造だと思っています。創業期“あるある”の課題を一度経験していたことは、起業時に大きなアドバンテージになりました。 また、大企業にいた頃は自分で人を採用し、組織によってレバレッジをかけるという経験がなかったので、Azitでそれを体感できたのも良かったです。 ー たしかに、20代で組織づくりを任されることってなかなか無いですよね。 そうですね。大企業では、どちらかというと20代は「プレイヤーとして成果を出す」ことを求められることが多いですから。当時のAzitは、様々な雇用形態の方を含めると100名ほどの組織規模になっていたので「人が増えると一人ではできないことが実現できる」というのを体感できたのは、今の組織計画にも大きく活かされています。 また「Azitで良かった」こともあって。まず、入社当時は全員週6くらい働いてたんですよね。今だとどうなんだろう…というのはもちろんありつつ、自分自身への厳しさの水準を作る土台にはなりました。「売上も利益も出てないから働くしかないじゃん」みたいなことを体現している人たちと一緒に働けたのは、すごく良かったと思っています。マインドとして、すごく良いものが培われたと思っているんですよね。 あと、Azitの最終面接には「人のことを聞く」文化があって、僕もshizaiでも続けています。過去の意思決定の変遷を聞きながら、その人の抽象化された軸を捉えていく。Azitは、“人と向き合うのが上手な会社”だな、と感じていました。

ー 当時のAzitで印象に残っている出来事はありますか？ 色々ありますが、特に印象的だったのは蒲田での合宿ですね。創業者3人と社員2人、計5人だけで2泊3日。「お互いの人生を知る」がテーマで、ほとんど寝ずに朝まで人生について話し込んでいました。当時はそれが「スタートアップらしさ」なのかと思っていましたが、今考えると「Azitらしさ」だったんですけどね（笑） あと、人が人を呼ぶ瞬間に立ち会えた、というのも印象的でした。熱量の高い時期を経て急激に仲間が増えたタイミングがあって。まさに、伸びるってこういうことか、と実感する瞬間でした。 僕はあまりVISIONにこだわるタイプではないのですが。でも、当時その言葉に共感してジョインしてくれる仲間が増えていく様子を見て、シンプルに凄いなと思ったんです。言葉の力を感じた瞬間でした。

<h2 id="hd2ad8167a5">真顔で「世界一の会社を作る」と言い続けていたい</h2>ー 今後の人生で成し遂げたいことはなんですか。 「真顔で“世界一の会社をつくる”と言い続けられる自分でいたい」ということでしょうか。人生は一回だけ。だからこそ、なるべく複雑な課題に挑戦したいんですよね。昔から簡単なことよりも難しいことに取り組むほうが、解く過程に面白さがあると思っていて。そのためには主語を大きくした方が良いんじゃないかなと思っています。「日本」ではなく「世界」とか「地球」「人類」みたいな。そういう大きなことを真顔で言っていきたいですし、今の事業もそうした目線で描けるようにしていきたい気持ちがありますね。常にそう思い続けられるよう、自分自身に期待したいところです。 ー そういった複雑な課題に面白さを感じるのってどういう点なんでしょうね。 僕にとって“唯一性”というのがキーワードです。「自分たちしかやっていない」「自分たちだからできる」とか結構大事で。自分自身がそういう人を格好いいと思って惹かれるし、僕が目立ちたがりだからかもしれませんが（笑） シンプルで簡単な問題だと、トライする人の母数も多いと思っていて。複雑な課題のほうが必然的にトライする人も少ないので、難しいのって良いなって思うんですよね。自分たちしかやっていないと感じられる課題には、価値を感じます。 ー たしかに、当時AzitもCREWを運営していて、日本で自分たちしかやっていないことを感じられましたよね。 本当に。自分たちだけというのが声高に言えたし、大きいことをしようとしてるぞという気持ちもすごく感じられましたね。

ー BtoBって、競合やバジェットという概念がある中で、唯一性というのが難しい部分もあると思うんですよね。だからこそ、会社=法人格の個性が大事ですよね。オリジナルであることの楽しさと、ゲーム的な楽しさが両輪で回っているような。 まさに。今の事業でお客様と向き合ってると、自分たちの唯一性に対する期待のハードルを少し下げても良いのかな、と思う瞬間はありますね。それは、失ったり無くしたりという意味ではなくて。 品質の高いものを提供することで、すごく喜んでいただける。そこには大きな価値があると思っています。だからこそ目先の「唯一性」にこだわるのではなく、目の前にある価値を積み上げていった先に唯一性というゴールがあるのかもしれない、と思ったりもしています。 それが競争優位性なのか、僕の言う“唯一性”というエモいものなのかはわかりませんが（笑）頭で考えすぎると「これって他に人でもできるんじゃない？」とか言えちゃいそうなシーンでも、意外と自分たちだからこその個性を感じられる所があったり。それはBtoBだからこそ感じられる所だし、自分自身を喜ばせるためにも良いかなと思っているんですよね。 ー BtoBに関しては、必ずしもユニークさにこだわらなくても良いのかも、という瞬間はありますよね。 そうですね、連続した先にユニークさがある気もしていますよね。例えばビズリーチさんも最初はビズリーチとしてスカウトを主軸に展開していたと思いますが、いまはビジョナルとして様々な事業を手掛けていたりするわけで。突き詰めた先や、成長の過程でそうなっていくことだってありますよね。 結局、目の前のお客様に愚直に価値を届けることが大事なんだと感じています。 聞き手：吉兼周優　編集：坂井華子 ▶後編へつづく 後編では、shizaiでの組織作りの話、Azitカルチャーへの想い、そしてこれからAzitにジョインする人へのメッセージを伺います。

【ex Azit】前編 | Azitを経て起業を選択。shizai代表鈴木さんが振り返るAzitの創業期

<h2 id="h8d027c8ed3">はじめに</h2>こんにちは、株式会社AzitでCTOを務めている十亀眞怜（そがめまさと）(<a href="https://x.com/Pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a>) です。 私たちは日々、さまざまな業務の効率化に取り組んでいますが、その中でも「住所データの処理」は、多くの企業が直面する共通の課題です。 本記事では、日本の複雑な住所体系において、住所を適切に分割・構造化する作業を、AIを活用して半自動化した取り組みについて紹介します。具体的な実装方法や、実運用で得られた知見を共有します。

<h2 id="hc9565f2c21">日本の住所処理が抱える課題</h2><h3 id="h6b3ee203e3">住所体系の複雑さ</h3>日本の住所は世界的に見ても特殊で複雑な構造を持っています。都道府県、市区町村、町名、丁目、番地、号、建物名など、多層的な要素で構成されており、さらに以下のような課題があります：<ul><li>表記の揺れ（漢字/カタカナ、全角/半角、ハイフンの有無など）</li><li>建物名の多様性（正式名称と通称の混在）</li><li>企業ごとに異なる住所フォーマットの要求</li></ul>実際、<a href="https://www.digital.go.jp/policies/base_registry_address" target="_blank" rel="noopener noreferrer">デジタル庁のベース・レジストリ</a>でも、日本の住所の標準化は重要な課題として取り組まれています。<h3 id="h822009bb2f">Azitにおける具体的な要件</h3>私たちAzitでは、住所データを以下の3つのフィールドに分割する必要がありました：<ol><li>address_line_1: 丁目までの住所（例：東京都港区六本木6丁目）</li><li>address_line_2: 番地以降（例：10-1）</li><li>address_line_3: 建物名・部屋番号（例：六本木ヒルズ森タワー53階）</li></ol>この分割は、システムの都合だけでなく、配送業務やマーケティング分析など、様々な場面で必要となります。 従来の配送依頼の処理では、一件毎にユーザーが入力していたため、上記の3つのフィールドに分割する作業はユーザーが実施してくれていました。 しかし、今回はユーザーの社内独自フォーマットのファイルを弊社側のオペレーションで上記の弊社側の形式に沿ったフィールドに分割したファイルに変換して一括入稿する必要がありました。 そのため、数十〜百件ほどの配送依頼を一回で取り扱う必要が発生し、この変換業務をいかに効率的にするかが重要となりました。<h3 id="h245aa8c8e7">既存ソリューションの限界</h3>当初、Google Maps APIなどの既存サービスの活用を検討しましたが、Google Mapは前述のような複雑な日本の住所には十分には対応できておらず、たとえば番地以下をGoogle Mapではそもそも認識できていなかったりするなど、住所文字列を分割するという観点では利用が困難でした。一方で、Google Maps APIには住所が誤っていてもランドマーク名などが含まれていれば、おおよそ正しい位置を認識できるといった特性があります。 このように住所情報の処理という観点では<ul><li>集合知的なアプローチによって「曖昧ではあるが、柔軟に住所を処理できる」ツール</li><li>厳密なルールやマスターデータによって「厳密な住所を厳密に処理できる」ツール</li></ul>の間のグラデーションで様々なAPIや手段やツールが存在します。 今回のケースでは、厳密に住所を分割したあと弊社のシステムに沿った形式に結合し直すというアプローチも考えられますが 元々の住所が厳密なのかという観点や厳密に住所を分割するためのシステムを構築するコストにたいして今回の対象となる運用においてどの程度の厳密さが求められるのかのバランスを考えた際に、より前者に近い曖昧でも良いので柔軟に住所を処理できる方式を探ることとしました。 事実、本機能の対象となった顧客から送付されるデータの中には丁目や番地などが省略されているが、ランドマークとなるような有名なビル名がふくまれているデータなどが入っており、厳密な住所である前提での正規化などは困難であろうと判断しました。<h3 id="h8249b11277">発想の転換：完璧な自動化から半自動化へ</h3>上記について話し合いを進める中で、チームメンバーから「完全な自動化を実現しなくても、AIで候補を出してもらって、人間がチェックすれば良いのでは？」という提案がありました。 これは音声認識のコーパス作成で同様の手法（TTSで読み上げ→人間がレビュー）でサンプルデータを作った事例からの着想でした。 そこで完璧な自動化を目指すのではなく、「AIが候補を生成し、人間が最終確認する」という現実的なアプローチを検討することにしました。<h3 id="hcf83e1357e"> </h3>

<h2 id="h2ca338e16c">Anthropic Claude APIの活用</h2>様々なAIモデルを検証した結果、Anthropic Claude 4 Sonnetが最も良い結果を出しました。 少し工夫をした点としては、Prefill機能を使った確実なJSON出力の実現です。<h3 id="hcc690ded8a">実装の詳細</h3>プロンプトエンジニアリング 以下が実際に使用したプロンプトです：<pre><code>user_prompt = """あなたは日本国内の住所の文字列を処理するプログラムです。
住所リストの各住所を適切に処理してください。

出力は以下のJSON形式に従ってください:

[
 {
 "original_address": "元々の住所の文字列そのまま",
 "address_line_1": "住所の「丁目まで」の文字列",
 "address_line_2": "住所の「番地以降」の文字列",
 "address_line_3": "住所の「建物名・部屋番号」の文字列"
 },
 ...
]

住所リスト:
{ADDRESS_LIST}"""

# 重要：Prefillで配列の開始を指定
assistant_prefill = "["

</code></pre>

Prefill機能の重要性 Prefillを使わない場合、以下のような問題が発生します：<pre><code>// 望まない出力例1：Markdownのコードブロック
```json
[
 {
 "original_address": "..."
 }
]

// 望まない出力例2：余分な説明文
以下が処理結果です：
[
{
"original_address": "..."
}
]</code></pre>Prefillで <code>[</code> を先に出力させることで、これらの問題を回避し、純粋なJSONのみを取得できます。

実装コード例<pre><code>import anthropic
import json

def build_user_prompt(address_list: list[str]) -&gt; str:
 address_list_str = "\\n".join(f'"{index}. {address}"' for index, address in enumerate(address_list, start=1))
 return f"""
あなたは日本国内の住所の文字列を処理するプログラムです。
住所リストの各住所を適切に処理してください。

出力は以下のJSON形式に従ってください:

[
 {{
 "original_address": "元々の住所の文字列そのまま",
 "address_line_1": "住所の「丁目まで」の文字列",
 "address_line_2": "住所の「番地以降」の文字列",
 "address_line_3": "住所の「建物名・部屋番号」の文字列"
 }},
 ...
]

住所リスト:
{address_list_str}
""".strip()

def split_addresses(address_list: list[str]) -&gt; list[dict]:
 """
 Splits a list of Japanese addresses into structured components.
 
 Args:
 address_list (list[str]): List of addresses to be processed.
 
 Returns:
 list[dict]: List of dictionaries containing structured address components.
 """
 # Build the user prompt
 user_prompt = build_user_prompt(address_list)

 # Initialize the Anthropic client
 client = anthropic.Anthropic(
 api_key=os.environ.get("ANTHROPIC_API_KEY"),
 )

 # Replace placeholders like {{ADDRESS_LIST}} with real values,
 # because the SDK does not support variables.
 message = client.messages.create(
 model="claude-sonnet-4-20250514",
 max_tokens=8192,
 temperature=1,
 messages=[
 {
 "role": "user",
 "content": [
 {
 "type": "text",
 "text": user_prompt,
 }
 ]
 },
 {
 "role": "assistant",
 "content": [
 {
 "type": "text",
 "text": "["
 }
 ]
 }
 ]
 )
 # 結果の先頭に[を結合して、JSONとして処理する
 result_json_str = f"[{message.content[0].text.strip()}"
 result_json = json.loads(result_json_str)
 return result_json

# 使用例
parser = AddressParser(api_key="your-api-key")
addresses = [
 "東京都港区六本木6-10-1 六本木ヒルズ森タワー53階",
 "兵庫県神戸市中央区三宮町1-9-1 センタープラザ東館4階",
 "静岡県浜松市中区砂山町320-2 浜松メイワン8階"
]

results = parser.parse_addresses(addresses)

</code></pre>

<h2 id="hf4217128d1">実際の処理例と結果</h2><h3 id="h1d29343e7a">入力データ(サンプル)</h3><pre><code>1. 東京都港区六本木6-10-1 六本木ヒルズ森タワー53階
2. 兵庫県神戸市中央区三宮町1-9-1 センタープラザ東館4階
3. 静岡県浜松市中区砂山町320-2 浜松メイワン8階
4. 茨城県つくば市吾妻1-9-2 つくばセンタービル3階301号室
5. 長野県松本市中央1-23-1 松本市役所3階

</code></pre><h3 id="hba5a52a911">出力結果</h3><pre><code>[
 {
 "original_address": "東京都港区六本木6-10-1 六本木ヒルズ森タワー53階",
 "address_line_1": "東京都港区六本木",
 "address_line_2": "6-10-1",
 "address_line_3": "六本木ヒルズ森タワー53階"
 },
 {
 "original_address": "茨城県つくば市吾妻1-9-2 つくばセンタービル3階301号室",
 "address_line_1": "茨城県つくば市吾妻",
 "address_line_2": "1-9-2",
 "address_line_3": "つくばセンタービル3階301号室"
 }
 // ... 以下省略
]

</code></pre>

<h3 id="h3e3d3efde9">モデル比較</h3>ベースとなるプロンプトや生成結果の確認はAnthropicのWorkbenchの画面でプロンプトの内容やサンプルと期待する出力を様々なパターンを設定しながら確認しました。 精度がある程度高く、また一方で無用に高度なLLMモデルを選択するのもコスト面や処理実行時間面でももったいないので、いくつかのモデルを比較しました。 Claude 3.5 Sonnetと4 Sonnetを比較した結果：<ul><li>Claude 3.5 Sonnet: 単純に数字が始まったら分割するなど、判断が甘い</li><li>Claude 4 Sonnet: より正確な判断で、日本の住所構造を理解した分割が可能</li></ul>といった所もサンプルのデータからわかり、今回はClaude 4 Sonnetをモデルとして選択することとしました。

<h2 id="hbcad4da9f5">運用での成果と知見</h2>このようにデータを自動的にAIによって自動分割することで、従来は人間が一件ずつチェックして切り貼りが必要だったステップが、人間は目視でレビューをしていくだけで確認が可能になり、大幅に作業時間が短縮されました。 元々の生の住所もレビュー用のデータとして残すことで、ハルシネーションによってまったく異なる住所が出力されてしまっているようなケース(実際には発生していませんが)にも気がつけるようになっています。

<h2 id="h7dabb5418b">今後の展望</h2><h3 id="h661e3f122b">機能拡張の可能性</h3><ul><li>ランドマーク対応: 「東京タワー」「丸の内ビルディング」など、有名建築物の自動補完</li><li>表記揺れの統一: カタカナ/漢字、全角/半角の自動正規化</li><li>エラー検出: 明らかに間違った住所の自動検出とアラート</li></ul><h3 id="h462e03ef05">他業務への横展開</h3>この「AI＋人間レビュー」のアプローチは、住所処理以外にも応用可能です：<ul><li>商品カテゴリの分類</li><li>顧客データのクレンジング</li><li>ドキュメントのメタデータ付与</li></ul><h2 id="ha214098e44">まとめ</h2>日本の複雑な住所体系に対して、生成AIを活用した半自動化アプローチを実装しました。重要なのは、AIを「完璧な自動化ツール」としてではなく、「人間の作業を効率化するアシスタント」として位置づけたことです。 Prefill機能のような技術的なテクニックを活用することで、より確実で実用的なシステムを構築できました。この事例が、同様の課題に直面している方々の参考になれば幸いです。

サーバーサイドエンジニア (Tech Lead)

生成AIを活用した住所分割の半自動化

Sogame Masato

今回のインタビューに登場するのはエンジニアの斉藤。「カオスを楽しみたい」と語る彼の真意に迫りました。

<h2 id="h5c4d85c8fd">PROFILE</h2>斉藤 涼介 広島大学卒業後、新卒で野村総合研究所にエンジニア職で入社。4年勤務後、Uターンで地元福岡に戻り、フリーランスやリモートワークでスタートアップ企業を経験。2025年4月よりAzitに入社。現在は、DeliveryXの開発に従事。

<h2 id="h3df065e5c5">成長を止めないために歩み続けたキャリア</h2>ー まずは、これまでのキャリアを教えてください。 生まれは北九州で、大学は広島大学の工学部です。卒業が近づいた時、就職するか大学院に行くかを迷ったのですが、野村総合研究所（以下、野村総研）のエンジニア職として採用されたため、上京して東京に行くことに決めました。 新卒1年目で結婚して、子どもが生まれました。その後も野村総研で勤務を続け、計4年間ほど働きました。 ー なぜそのタイミングで退職を決めたのでしょうか？ 優秀な人に囲まれた魅力的な職場ではあったのですが、SIerという業界的な特性もあって自分でコードを書く機会が少なくて。実際の開発は国内外のパートナー企業に託し、自分たちはスケジュールやプロジェクトの管理などが中心なんですよね。大きなシステムなのでやりがいはありましたが、実際の開発をしていない自分に対して、本当にエンジニアと名乗って良いのか？とモヤモヤする気持ちを抱えていました。 また、親や友達など頼れる人が近くにいない中での子育てにも限界を感じ、地元の北九州へのUターンを決めました。 ー なるほど。地元ではどういう働き方をしていたのですか？ 北九州って実は結構広くて、自分の地元は北九州の中心地である小倉まで1時間以上かかるような田舎の場所なんです。なので近くにIT企業がなくて。クラウドワークスを利用して、業務委託として自宅からフルリモート開発を行っていました。1年ほど経った時、業務委託を受けていた大阪の会社から正社員として打診をいただいたので、入社することに決めました。入社後もフルリモート勤務のままで開発させて頂けたのでありがたかったですね。 この会社では、社長が要件と仕様を固め、自分が開発・リリースするという二人三脚の小規模体制でした。最初は、ようやくエンジニアらしい開発ができていると充実感を感じて働いていました。ただ、開発フェーズはテストもコードレビューもない完全な1人開発だったので、少しずつチーム開発への憧れが強くなり、2年ほど働いた後に転職することにしました。 ー チーム開発への想いが強かったんですね。 そうですね。次に入ったのは、在庫管理のサービスを提供するスタートアップで、念願のチーム開発ができる環境でした。JiraやSlack、GitHubなどチーム開発ツールを活用しながらチーム開発できたのはすごく楽しかったです。また、実際にお客様の在庫管理の現場に足を運び、自分が開発したプロダクトを使っている所を直接見る機会があったことも、すごくやりがいに繋がりました。 ただ、最初は分からないことだらけの中の開発で、毎日成長を感じることができていたのですが、数年も経つと少しずつ自分の成長が鈍化していくのを感じてきて。ずっと同じプロダクトを開発していると、例えば要件を聞いた段階で「あのファイルをこう修正すれば実現できるな」ということが良い意味でも悪い意味でも大体分かってしまうんですよね。そうすると開発作業が単調作業に感じられてしまい、飽きてしまって。そこから新しい環境に挑戦したいという思いが強くなり、4年ほど働いた後に転職を決めました。 ー 「エンジニアとしての成長」が大きなポイントなんですね。 そうですね。元々エンジニアと言う職種に興味を持ったのも、常に新しい技術を学び続けたいという思いがあったので。あと、もともと性格的に飽きやすいので、開発が単調作業になった瞬間に興味が持てなくなっちゃうんですよね。経験した事のない新しいエラーやバグに揉まれてひいひい言いながら開発するのが好きなんです（笑）。

<h2 id="hf257fc914d">Azitで見つけた“楽しいカオス”</h2>ー Azitへの転職を決めた理由はなんでしたか？ 各企業が自分に対する推定年収を提示してくれる転職サービスを使っていたのですが、そこで提示された年収がAzitが一番高かったからです（笑）。と言うのは半分冗談として、Azitのスタートアップらしい雰囲気が面白そうだなと感じたからです。サービスとしてはまだ未完成だけど、野望はあるしこれから社会を変えていくぞという強い情熱を感じましたし、複数の投資家から出資を受けているという点も魅力を感じました。 ー 実際に入社してみてどう感じていますか？ 想像以上にカオスでびっくりしました（笑）。開発資料も最低限しかないしプログラムコードも整理されておらず古いコードが放置されてたり。ただ、意思決定にスピード感があるし、サービスの未来に対する期待感がある。過去に大きいピボットを経験しているだけあって、組織の柔軟性も感じます。 数ヶ月先の自分がどんな開発をやっているか予測がつかない。それは、リスクもありますが、飽き性で単調作業が苦手な自分にぴったりの職場だと感じてます。あとはセールスが強くて。0から仕事を取ってくる強い熱意があるので、自分もそれに応えて良いプロダクトを開発するぞ、という気持ちにさせてくれます。 ー 現在の業務内容を改めて教えてください。 今は、DeliveryXの開発を主に担当しています。最近では2段階認証やパスワード変更の機能を実装しました。Bizサイドから「こういうことやりたいんだけど、どう思う？」という上段から入って、要件を詰めて、設計して、実装して、リリースまでもっていくという開発の流れを一気通貫で経験できて楽しいですね。 DeliveryXのクライアントは自分も普段からお世話になっているような有名企業も多いので、それもやりがいに繋がっています。

<h2 id="hb1a53d410a">目標はつくらない。だから思ってもなかったところにいける。</h2>ー 今、入社して3ヶ月ほどですよね。特に充実した出来事はありますか？ 日々充実していますが、やはり先ほどお話した2段階認証のプロジェクトは印象的ですね。詳しくは<a style="color:#1155cc" href="https://love-from.azit.co.jp/article/delivery-x-two-step-auth" target="_blank" rel="noopener noreferrer">こちらの記事</a>に書いたのですが、要件定義からリリースまで１ヶ月以上かかりました。普通は新人にはなかなか回ってこない大型案件だったと思います。いわゆる上流工程から自分自身で旗を持って進めていくのはプレッシャーを感じつつも充実していました。 ー 課題解決の「課題」だけ与えられているような状態ですね。 まさに。それが1番楽しいですよね。もちろんそれが嫌だと言う人もいると思いますし、もっと要件を固めてから持ってきてほしいというエンジニアもいると思うんです。なので、あくまでも相性だと思うのですが、少なくとも自分にとっては楽しい働き方です。 ー どんな人がAzitに向いていると感じますか？ やっぱり、カオスを楽しめる人だといいのではないでしょうか。要件が曖昧なこともあるし、毎日状況も変わります。決められた通りに仕事したい人には辛いかもしれませんが、「課題を渡されて、自分で考えて形にしていく」ことが好きな人にとっては、最高の環境だと思います。 ー 先ほど「エンジニアとしての成長」の話がありましたが、今後Azitでどんな成長をしていきたいですか？ 長期の目標を明確に立ててそれに向かうというよりは、目の前の課題を1つずつクリアしていく、その連続の中で自然に成長していくのが自分には向いていると感じています。 野村総研の時、半年ごとに目標シートの記入と提出がありましたが、個人的にそれがあまりしっくり来てなくて。ゴールをイメージしすぎると、仕事がただのすごろくゲームみたいになってしまう気がするんですよね。ある程度のランダム性がある方が面白いと感じます。あまり遠い未来を細かく見すぎないようにしているというか、眼の前のことをしっかり楽しんで着々と実行していくことで、結果的に思ってもみなかったような遠い場所にいけるのかなと。 ー 最後に、これからのAzitに期待することはありますか？ もちろん物流・SCMのプラットフォーマーとして進化し続けることを期待していますが、一方で全く想像もしていない方向へ進化するのもそれはそれでAzitらしくて面白いなと思いますね。この変化の早い時代に適合し続けて欲しいなと思いますし、自分もそれを支えるべく開発し続けていこうと思っています。 インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>Azitではバックエンドエンジニアポジションを募集しています。詳細は、以下の募集ページをご覧ください。 <a style="color:#000000" href="https://herp.careers/v1/azitinc/BuZJNsBg96-u" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/BuZJNsBg96-u</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

“成長”を止めない。カオスを楽しむエンジニアがAzitに来た理由

今回のインタビューに登場するのはEM・AIスペシャリストの岩瀬。新卒で考古学者になった彼がなぜ今Azitにいて、何を思っているのか話を聞いてきました。

<h2 id="h5c4d85c8fd">PROFILE</h2><h4 id="h2f96ba51e5">岩瀬 雄史</h4>大学で考古学を専攻し、卒業後は考古学者として遺跡調査の現場へ。約10年その道を歩んだ後、IT業界へ転身。SIerを経て、2024年10月にAzitに入社。現在はコンサルティング事業部のEMおよびAIスペシャリストとして在籍。

<h2 id="h01955f73c0">考古学者からエンジニアへ、異色のキャリアの真相とは</h2>─ 考古学からITへ、珍しいキャリアですよね。 はい。大学では考古学を専攻し、卒業後にそのまま遺跡調査の仕事をしていました。10年ほど続けた頃、30歳を目前にして「このまま続けていくのか？」と悩み始めたんです。色々と考えた結果、学生時代に考古学とどちらにするか悩んでやめたプログラミングを仕事にしてみようと決めてIT業界に入りました。 ─ 当時、エンジニア以外の業界は検討しなかったんですか？ もちろん、そのまま遺跡調査を続けていくことも考えたりしていました。もし別の会社に行くにしても、例えば博物館で働いたりなど、シミュレーションはしてみました。けど、難しいんですよね。考古学は好きなんですけども、仕事として割り切るのがなんだか辛いな、と思って。そこで、別の業界を考えました。 ─ IT業界は未経験だったということですよね？ そうですね。学生時代から将来考古学で食べていけなくなった時の潰しになればと触れてはいましたが、いわゆる業務経験はなくて。最初に入った会社は小規模で、何でも屋のような雰囲気でした。SES的な業務が主でしたが、所属していた部署はSI寄りのこともやらせてもらいました。 ─ その後、SIerに移ったんですね？ はい。小さな案件で経験を積むうちに、もっと大きなシステムに関わりたいという思いが芽生えてきました。そこで、金融系の大規模プロジェクトを扱うSIerへ転職しました。そこでは、7年ほど働きました。

<h2 id="h78df7a0a3d">想像できる未来は、選ばない</h2>─ Azitに来たきっかけを教えてもらえますか？ 実は当時、次もSIerで探していたんです。でも、「次に何をやるか」が想像できてしまって、あまりワクワクしなかったんですよね。想像がつく同じような毎日が続くだけだったら転職する意味がないのでは、と考えて一度リセットすることにしました。 そこで初めて自社プロダクトを持っている会社やスタートアップに目を向け始めました。その中でAzitと出会い「先が読めない感じ」に惹かれ、入社を決めました。 ─ 先が読めない、が魅力だったんですね（笑） はい。当時の自分は正直、少し考え方も凝り固まってしまっていたと思うんです。新しいことも受け入れられなくなってきている気がして、もう一度柔軟な発想ができるようになりたいと思うようになっていました。 スタートアップって、尖ってる部分もあれば、あまり整っていない部分もあって。そのいびつさが面白そうだなと。SIerだと、プロジェクトやお客様によってバラけると良くないので均一化していく文化がありますが、Azitは、型がないからこそ、自分の考え方ややり方を試せる。ここなら自分自身の幅も広げられると思いました。

<h2 id="hf1b1138cae">アンラーニングの苦しさと楽しさ</h2>─ 前職と比べて異なる業務に対して、チャレンジングだと感じることはありますか。 はい。とにかくプロジェクトの進め方も、仕事の進め方もこれまでとまったく違います。例えば、過去の職場では「それは良くない」と言われて避けていたようなやり方が、まかり通るというと語弊があるのですが、良い意味で型にはまってないからこそ成立する所があって。「こうしなきゃいけない」「プロジェクトはこう進めなきゃいけない」みたいな締め付けがないから、自由にできる楽しさはありますよね。 ─ 大変なことも多いのではないでしょうか。 プロダクト開発をしていても、数ヶ月でやることがコロコロ変わったりしますからね（笑）そんな短期間で変わるということは、今までにはなかったことです。 でも、必要に応じて変わっていけばいいと思っていて。むしろ変えることが推奨されている文化でもありますが、プロジェクトを進めていると「このまま進むと上手くいかないな」と見えている状況もあったりするので、考え方もやり方も違いますが、そうやってどんどん変化を起こしていくことに面白みは感じています。 ─ アンラーニングするのが1番大変だったポイントはありますか？ 大変だったのは、正直にお話すると否定から入ってしまう自分の思考パターンでした。前職では「まず仕様通りに作る」「変更には厳密な理由が必要」といった常識がありました。でも今は、まずやってみて、違ったら変える、という柔軟さが求められる。だから、考え方をアップデートし続ける必要があります。 どうしても「なんでやり通さないの？」みたいな思考が生まれてしまうんですよね（笑）やり通すということの意味と基準が違うということも、大きな学びだと思います。

<h2 id="h6d87a39262">「自分で手を動かせる楽しさ」をもう一度</h2>─ Azitが今後どうなっていったらいいと思いますか？ すごくシンプルですが「普通の会社」にはなってほしくないな、と思っています。この規模、この業界で、こういうメンバーがいるからこそ成り立っている面白さがあると思うんです。ありふれた会社になったら、面白くないなと思ってしまいます。 ─ そのために、必要なことはなんだと思いますか？ 先ほどの話にも近いのですが、新しいことに挑戦する姿勢を持ち続けることだと思います。一度満足してしまって同じやり方をずっと続けていくと、多分そのまま進歩せず枯れていくと思うので。やり方も、考え方もその時その時の状況に合わせて柔軟に変化することが大切かな、と感じています。 そして、年齢や役職に関係なく、意見が言える場を持つことも大切だと考えています。前職で、もともとそういった場があったのが、なくなってしまった途端、組織の風通しが悪くなった経験があるので、特に強く感じますね。 ─ 今、どんな40代を過ごしたいですか？ 20代と30代で培ったものを活かしつつ、新しいことに挑戦していけたら、それが理想だと思います。今、久しぶりにプレイヤーとして自分の手を動かして考えながら仕事をしていますが、それがすごく楽しいんですよね。 今AIを使ってデモを作ったりしてるのも、以前なら恐らく私は誰かに指示を出してスケジュールを管理して、とかそういう仕事になっていたと思うんです。自分で作るというのはなかったと思うんですよね。 ─ 最後に、どんな人と一緒に働きたいですか？ 私は反面教師のようですが…否定から入らず、相手の気持ちや考えをまず受け止められる人がいいのでは、と思います。小さな違和感やアイディアを拾って、育てていける人。Azitはそういう人が活きる場所だと思いますし、そういう人が増えたら、もっと面白くなると思っています。 インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>AzitではAIスペシャリストのポジションを募集しています。詳細は、以下の募集ページをご覧ください。 <a style="color:#1155cc" href="https://herp.careers/v1/azitinc/Xxe4VkvM-6vO" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/Xxe4VkvM-6vO</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

考古学の世界からITへ。「面白い」を追求する岩瀬が今Azitで考えること

Azit CTOの十亀（<a href="https://x.com/Pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a>）です。 DeliveryXでは、バックエンドのRuby on Railsでの開発をモジュラーモノリス構成で行っており、 本記事では、弊社のモジュラーモノリス構成へのRBSの導入にあたってどのような観点から判断を行ったか、 今後行いたい技術的な改善項目などをご紹介いたします。

弊社のDeliveryXでは、物流業界のDXという事業ドメインに向き合うソフトウェアの開発をおこなっており、 WoltやUber Directといった3PLとのAPI連携や、自社の配送網をすでに保有しているクライアント企業内の配送オペレーションの改善のための機能群など 一つのプロダクトのなかでも、ユースケースや利用タイミングが異なっていたり、同じ単語であっても業務フローが異なっている場面が存在するなど、 ソフトウェアとしてもロジックをいかに疎結合でわかりやすい形に保ち続けるかが開発効率の要の一つであり、顧客への迅速なアウトカムの提供のために重要です。 テストのカバレッジを高く保つことを意識したり、ドメイン駆動設計の概念などを取り入れてビジネス観点とソフトウェア内部の距離を近くするなどの活動も行っておりますが 本記事では、　RBSを利用して型チェックの観点から保守性を高めるための活動をご紹介いたします。

<h2 id="h35a3140377">モジュラーモノリスの分割方針とdry-structの活用</h2>DeliveryXでは、ルートディレクトリに <code>packages</code> というディレクトリを切り、 その下に <code>marketplace</code> (3PLネットワークとの接続） であったり、<code>delivery</code> （配達員アサイン後の配送進捗管理）などといった独立したディレクトリを作成し、 各ディレクトリの間はできるかぎり疎結合にできるように努めて構成をしています。 そのなかでの方針の一つとして、パッケージからは <code>usecase</code> という外部公開の用の限定されたインタフェースを腐敗防止層として定義し、 またUseCaseへの引数としては <code>types</code> というネームスペース以下に定義したイミュータブルなオブジェクトおよびIntegerやStringなどに限るようにしています。 そのようなイミュータブルなオブジェクトは例えば、以下のように<a href="https://dry-rb.org/gems/dry-struct/1.6/" target="_blank" rel="noopener noreferrer">dry-struct</a>と<a href="https://dry-rb.org/gems/dry-types/1.7/" target="_blank" rel="noopener noreferrer">dry-types</a>を利用して定義しています: <pre><code>module Marketplace
&nbsp; module Types
&nbsp; &nbsp; class FooBarConfiguration &lt; StructBase
&nbsp; &nbsp; &nbsp; attribute :foo_bar_id, Types::Integer
&nbsp; &nbsp; &nbsp; attribute :maximum_amount, Types::Integer
&nbsp; &nbsp; &nbsp; attribute :maximum_delivery_minutes_limit, Types::Integer
&nbsp; &nbsp; &nbsp; attribute :foo_prioritize_criteria, Types::Symbol.enum(:price_priority, :time_priority)
&nbsp; &nbsp; &nbsp; attribute :bars, Types::Array.of(Bar)
&nbsp; &nbsp; end
&nbsp; end
end</code></pre>(実際には、StrictやParamsやCoercibleなども適宜使い分けます） このように定義しておくことで、このパラメータとして受け取ったあとの処理は、このオブジェクトから取り出したフィールドはIntegerやStringなどであることは実行時に保証されているとして実装をすることができます。 また、ユースケースの返値についても同様にイミュータブルで明確なオブジェクトにしておくことで、ユースケースの返値を受け取る側の処理に対しても安定したインタフェースとして依存することができるようになります。

<h2 id="hc76d192b89">RBS導入の狙いと課題</h2>上記のように進めているdry-structやdry-typesでは主に実行時の型の保証と、インタフェースの明確化によるコードのドキュメントとしての効果を狙って行っています。 そこに加えてRBSを導入することで、静的にチェックできる領域を増やすことでテストのカバレッジの維持と同様にシステム全体の安全性を向上させるとともに、追加の機能開発の際に静的な型検査による影響範囲の検知なども狙いたいと思い、RBS CollectionやSteep、RubyMineでのRBSサポートがより成長してきたことなどを踏まえて正式に積極的に導入をすすようと判断をしました。 また、AzitではGithub CopilotやChatGPT Team、ChatGPT Proの試験導入や、Devinの試験導入などAIによる開発生産性の向上にも会社全体で取り組んでいます。 そのような観点からもAIにとって扱いやすい形として、主要なデータ型やinterfaceを明確な形で与えておきたい・設計したいという意図もあります。

<h2 id="h544f04ea88">dry-structとRBSの併用</h2>当然のことながら、すでに各パッケージのインタフェースとして定義しているdry-structはそのまま活用でき、引き続き実行時の保証という面では非常に役に立っています。 RBSによる静的型検査では、以下のようにuntypedを経由することで、実際には間違った型の値を外部から渡されてしまう可能性が存在するため、 引き続きdry-struct等による実行時の型検査は必要となります。 たとえば、以下のようなコードが書かれてしまっているとします。 <pre><code>class Foo
 def greeting_message
 return "Hello, World!"
 end
end


class Bar
 def add_two(number)
 return number + 2
 end
end


if __FILE__ == $0
 foo = Foo.new
 puts foo.greeting_message


 bar = Bar.new
 puts bar.add_two(foo.greeting_message)
end</code></pre> このとき、Bar側の型シグネチャとして <pre><code>class Bar
 def add_two: (Integer number) -&gt; Integer
end</code></pre> と、Integerを期待していることを明確にしていたとします。 このとき、Fooの型シグネチャが <pre><code>class Foo
 def greeting_message: () -&gt; String
end</code></pre> と定義されていれば、 steepによる検査時に <pre><code>app/sample.rb:18:19: [error] Cannot pass a value of type `::String` as an argument of type `::Integer`
│&nbsp; &nbsp;::String &lt;: ::Integer
│&nbsp; &nbsp; &nbsp;::Object &lt;: ::Integer
│&nbsp; &nbsp; &nbsp; &nbsp;::BasicObject &lt;: ::Integer
│
│ Diagnostic ID: Ruby::ArgumentTypeMismatch
│
└&nbsp; &nbsp;puts bar.add_two(foo.greeting_message)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;~~~~~~~~~~~~~~~~~~~~</code></pre> と、正しくミスが指摘されますが、 <code>greeting_message</code> の返値が <code>untyped</code> と宣言されてしまっている場合は 実行時までこのミスに気がつくことはできません、プログラムが段々と大きくなっていくにつれてどのコードがどこで呼び出されているかを 記憶しておいて人間がミスに気がつくというのは段々と難しくなります、またテストのカバレッジを十分に高く保っていたとしても テストケースに万一の漏れが発生してしまう可能性はありますので、異なるタイプの検査で検知できるのであればそれに超したことはありません。 また今回の場合は、すぐにパラメータがbarメソッド内で利用されているので実行時にも値を渡しているところのすぐ近くでエラーが発生しますが、 もし、barメソッドがもらった引数をまた別の関数に渡して、その関数が..と呼び出しの連鎖が長くなってくると、 実行時のエラーを検知した際に、どこからそのような値が侵入してきてしまったかを把握することは困難になってしまいます。 このような場合にもdry-structで適切にインタフェースを宣言してあれば、想定外の値を渡してしまっていることはユースケースを呼び出すための パラメータを作成した段階で実行エラーとして検出されるようになり、パッケージ内部ではその心配をする必要性が減ります。 このように実行時の動的な型検査によって入り口の段階で型を一定保証することによって、パッケージ内部の型シグネチャではユースケースから連鎖的に呼び出される処理の間で渡される型について静的に型検査を行っておけば内部の呼び出し関係の型にある程度自信を持てるようになります。 このように実際の運用では、実行時の動的な型検査と、静的な型検査の役割の違いはきちんと意識して使い分ける必要があります。

<h2 id="ha3f037a130">RBS-Inlineへの段階的移行とそのメリット</h2>上記のようなメリットもあり、RBSの導入を進めていますが、さらにRBSでの普段の開発をスムーズにするために rbs-inlineについても導入をすすめています。 もともと、チームでRBSを導入をすすめるなかで<ul><li>コードレビューの際に、RBSとRubyコードの一致を確認することが難しい</li><li>手作業による型シグネチャの記述の場合に、RBS側にだけ残ってしまっている場合に検査で発見できない</li></ul>など型シグネチャとRubyコードの両方を同時に編集するなかでのミスも発生していました。 前者についてはRubyMineでの型シグネチャへのジャンプ機能なども進歩してきたためスムーズに行えるようになりました 後者については、リファクタリングの過程でのミスなどによって削除したはずのメソッドを引き続き呼び出してしまっている 処理が存在するものの、型シグネチャの方からの記述の削除漏れも同時に発生してしまうことによって型検査でも検出されなかったりする場面もありました。最終的にはCIでのテストによって発見されるものの、もっと開発者がコードでの機能開発に集中しながら型での恩恵も受けやすくしたいと思っていました。 そんななかで、rbs-inlineを導入することでRubyコード側のコメントと完全に同期した形でRBSが生成することが可能になり 開発者も開発中にわかりやすく、またコードレビューでも無意味に浮いたコメントであれば気がつきやすいのでより導入がしやすくなりました。

<h2 id="h0b42f6d9af">dry-structにも型をつけておく</h2>上記でも触れましたがdry-structで定義してあるオブジェクトにも静的型検査用の型シグネチャをrbs-inlineのコメントとしてつけておく必要があります。 以下では、いくつかのパターンに触れて、紹介しておきます。 まずは、メインであるattribute関連の型付けです<pre><code># frozen_string_literal: true
# rbs_inline: enabled
module Optimization
 module Types
 class FooConfiguration &lt; StructBase
 # @rbs! attr_reader optimization_duration_in_seconds: Integer
 attribute :optimization_duration_in_seconds, Types::Coercible::Integer
 # @rbs! attr_reader vehicle_speed_km_per_hour: Float
 attribute :vehicle_speed_km_per_hour, Types::Coercible::Float
 # @rbs! attr_reader clustering_equal_coordinates_service_jobs: bool
 attribute :clustering_equal_coordinates_service_jobs, Types::Bool
 # @rbs! attr_reader ttl: Time | nil
 attribute? :ttl, Types::Params::Time
 end
 end
end</code></pre> たとえば、このようにdry-structが独自で提供している <code>attribute</code> は当然のことながらrbs-inlineでは認識されないので、 <code>@rbs!</code> という埋め込み構文をコメントとしてつけておくことで、このオブジェクトからInteger型などでアットリビュートを取り出すことができることを表現しています。 また、すこしトリッキーな例としては、 <pre><code># frozen_string_literal: true
# rbs_inline: enabled
module Optimization
 module Types
 # @rbs!
 # type batchAssignmentServiceJobsStatus = "IN_PROGRESS" | "COMPLETED"


 # @rbs skip
 BatchAssignmentServiceJobsStatus = Types::String.enum('IN_PROGRESS', 'COMPLETED')
 end
end</code></pre> このように、dry-struct側では、独自の型を表現として大文字から始まる形で宣言ができるのにたいして、同等の型宣言はRBSでは小文字からしか開始できないことなどの制限もあるため 適宜、もとの記述を　<code>@rbs skip</code> でスキップしてもらい、先程と同様　<code>@rbs!</code> による埋め込みで同様のリテラル型による等価な型シグネチャを出力するなどの工夫も必要になります。

<h2 id="h5c913b2688">rbs_railsを併用した運用方針</h2>また、本記事では紹介しませんでしたが、<code>rbs_rails</code> も併せて導入済みのためRailsの自動生成してくれるアソシエーション系のメソッドなども 適切に型がつくため、より一層開発中にIDEでメソッドの自動補完が適切に行われたり、カラムが空の場合を考慮してメソッドの命名や設計意図をどのように設定するかなど 静的な型検査によってより意識的に設計を考える良い機会になっています。 rbs-inline, rbs_railsを併用して、以下のような配置でRBSファイルを管理しています。

<table border="1">
 <thead>
 <tr>
 <th>対象</th>
 <th>対応方針</th>
 <th>配置先</th>
 </tr>
 </thead>
 <tbody>
 <tr>
 <td>ActiveRecordのメソッド</td>
 <td>rbs_rails に一本化</td>
 <td>sig/rbs_rails/ 以下</td>
 </tr>
 <tr>
 <td>ActiveRecordのカラムへのアクセサ</td>
 <td>rbs_rails に一本化</td>
 <td>sig/rbs_rails/ 以下</td>
 </tr>
 <tr>
 <td>rbs_inline をつけたファイルの sig</td>
 <td>rbs_inline に一本化し、適宜 @rbs! を使う</td>
 <td>各パッケージの sig 以下、 および app/sig 以下</td>
 </tr>
 <tr>
 <td>その他</td>
 <td>可能であれば rbs_inline に段階的に移行していく</td>
 <td>各パッケージの sig 以下、 および app/sig 以下</td>
 </tr>
 </tbody>
</table>

<h2 id="h28b62bc2c0">今後の課題</h2>本記事では、現在DeliveryXの開発で進めているRBSの導入を紹介いたしました。 テストによる試験などと同様に、静的な型チェックを進めることによってよりプロダクトの開発を自信をもって進めることが可能になり、 また、型という目線からプログラムやメソッドの設計を考える機会にもなり、よい設計の指針にもなっています。 今後は <code>steep stats</code> を定期的に報告する仕組みなどを作成し、プロジェクト全体へのRBSの導入率などをチェックできるようにしたいと思っております。

Azitではサーバーサイドエンジニアを募集中です。ご興味をお持ちいただけましたら以下の採用サイトからご応募下さい！

Pick Up!

Hashtags

Latest Articles