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

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

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

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

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

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

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

</code></pre><p><br></p>

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

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

<p><strong>実装コード例</strong></p><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><p><br></p>

<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><p><br></p>

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

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

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

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

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

Sogame Masato

<p>株式会社 Azit CTOの <a href="https://twitter.com/Pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a> です.<br>今回は、CREW Expressプロダクトの各領域で採用している技術スタックをご紹介します。<br></p><h2 id="hebc0f8471a">APIサーバー</h2><ul><li>Rails 6.1.x</li><li>Ruby 3.1.x</li></ul><p>を利用しています。<br>サービスの開発当初は、WebフロントエンドもReactのコンポーネントをERBに乗せる形で提供していましたがフロントエンドの開発の生産性等を鑑みて、フロントエンドを切り話してAPIサーバーとしての機能提供に集中しています。<br>APIのスキーマはOpenAPIで定義しており、<a href="https://github.com/interagent/committee" target="_blank" rel="noopener noreferrer">commitee</a>で実装と定義の一致の検証をすると共に、Webフロントエンド側でAPIクライアントの自動生成に利用しています。<br>開発のプラクティスとしてTDDとDDDを採用しており、<a href="https://love-from.azit.co.jp/article/ddd" target="_blank" rel="noopener noreferrer">事業ドメインの整理の段階から戦略DDDに取りくんでいます</a><br>また、Rails上でドメイン構造を整理しつつ、<strong>静的型付けのある言語でより開発の信頼性や安定性を向上させるためにコアドメインを段階的にGoに移行することを計画しています。</strong></p><h2 id="h3d909c6d1f">Webフロントエンド</h2><p>クライアントさんから利用していただく管理画面、弊社内のオペレータがカスタマーサポートの業務として利用する社内管理画面の開発では、ビジネスの変化に追従しつつ柔軟なUXを提供しやすいように</p><ul><li>Next.js</li><li>TypeScript</li></ul><p>を採用しています。<br>状態管理等にはRecoilとContextを利用しており、APIとの通信はOpenAPIからクライアントを自動生成し、SWRでラップしています。<br>CSSは、CSS ModuleとCSS in JSを併用していましたが、CSS in JSに寄せていく方針に決定して、新規コンポーネントはCSS in JSで書くと共に既存のコンポーネントの移行も進めています。</p><h2 id="h054fab72d6">モバイル</h2><p>配達パートナーから利用されるモバイルアプリケーションはAndroid, iOS両プラットフォームともにネイティブアプリで、Kotlin, Swift 100%でそれぞれ開発しています。<br>Android向けアプリはマルチモジュールのMVVMになっており、新規機能開発の際には既存の画面等もJetpack Composeでリライトを進めています。<br><br>iOS向けアプリはクリーンアーキテクチャ型のマルチバンドル構成で、UIのレイヤーではVIPERアーキテクチャを採用しており、新規機能開発の際には既存の画面をSwiftUIにリライトして開発しています。<br>VIPERアーキテクチャの採用判断はSwiftUIの登場する以前に判断したため、SwiftUIを前提に考えるとMVVMの方が適合しやすいため移行も検討しています。<br><br>Flutter等のクロスプラットフォームフレームワークの導入も開発初期に検討しましたが、サービス開発の時点でネイティブの専門性の高いメンバーが揃っていたこと、当時のフレームワークの知見の量や安定性とアプリケーションに求められる非機能要件などをふまえてネイティブで開発をする判断をしました。</p><h2 id="hb3c83ebaaa">最適化エンジン</h2><p><br></p>

<p>CREW Expressでは、クライアントさんの配達リクエストをより少ない人数や稼動時間で効率よく配送するための各種最適化を提供する事で、クライアントさんのオペレーションや金銭的なコストを低下させる事を価値として提供しています。<br>そのような最適化を実施するエンジンはRustで記述しており、インフラはAWS Lambdaに乗せて最適化したい配送の問題定義をPOSTしてやると、最適化をした結果を返すようなプライベートAPIを公開しています。<br>APIのスキーマはOpenAPIで定義し、仕様の変更があると自動生成したクライアントコードがAPIサーバー側のリポジトリにPRとして発行されるようにしています。</p><h2 id="h1fc02ea273">インフラ</h2><p>インフラは全てAWS上に構築しており、スケールしやすい技術選定をすることで運用コストを下げるために、ECS Fargate, ElastiCache, Amazon Aurora, Amazon Lambda等を積極的に利用しています。</p><h3 id="hdc2da36b1a">位置情報管理</h3><p>AWS Automotive@Loft 第一回 モビリティサービスで登壇させていただいた時の資料:</p>

<p>配達パートナーの位置情報を記録する事でディスパッチの最適化に利用していますが、位置情報を稼動中の多くの配達パートナーの端末から受信して記録していくことが必要になります。<br>このシステムは、多くのトラフィックを受ける事になるためWriteに対してスケールする必要があり、またクライアントからの配達リクエストの量が増えた時にReadに対してもスケールが求められます。<br>そのような要件の位置情報の管理基盤を構築するにあたって、なるべく金銭的にも運用コスト的にも低コストで実現できる事を期待し、<br>Writeのスケールのために配達パートナーアプリからの書き込みの窓口にAmazon Kinesis Data Streamsを使用し、<br>位置情報の保存にはAmazon Location Serviceを利用しUberの<a href="https://h3geo.org/" target="_blank" rel="noopener noreferrer">H3</a>を利用してハッシュキーをつくってDynamoDBに索引をつくる事で高速な絞り込みを実現しています。</p><h3 id="hda9ca5f26d">構成管理</h3><p>構成管理にはTerraformを利用しています。<br>CI/CDにはGitHub Actionsを利用しており、PRを送るとfmtのチェックやvalidate、tflintの実行等の各チェックと共に、<a href="https://github.com/suzuki-shunsuke/tfcmt" target="_blank" rel="noopener noreferrer">tfcmt</a>でplanの結果がコメントされたり、マージされたら自動的にapplyされ結果がそのPRに投稿されるようにしており、GitHub上で構成の管理やレビューが完了するようにしています。</p><h2 id="h5e24d1c553">ログ分析・サーバー監視</h2><p>アプリケーションでエラーが発生してしまっている時の予兆にすばやく気がつき、その要因特定や解決をすばやく実施する事ができるよう、ログの集積・分析やAPMにはDataDogを利用しており、エラー発生時の要因分析、5xx系エラーの量の監視や外形監視等を実施しています。<br>また、アプリケーションレベルでのエラーの管理にはSentryを利用していて、新規のエラーが発生した場合にSlackに流れるようにして開発中やリリース後に即座に気がついて対応が可能なようにしています。</p><h2 id="ha214098e44">まとめ</h2><p>今回はCREW Expressプロダクトの各領域で採用している技術を紹介いたしました。<br>CREW Expressでは各領域毎に独立して最適な技術選定が可能となるように分離しながら日々改善を進めており、CREW Expressの技術的な改善を推進してくださる方を募集しています。<br>少しでも御興味をもってくださったら、是非お気軽に話を聞きにきてください!</p>

CREW Expressプロダクトの各領域で採用している技術スタックをご紹介します。