Media > AI活用ユースケース > 営業 > 植木の生産・卸の会社が、造園業者からの「日陰に強い、高さ二メートル、常緑」のような言い方で圃場の在庫の樹木を OpenSearch で引き、候補と出荷の可否を出す

植木の生産・卸の会社が、造園業者からの「日陰に強い、高さ二メートル、常緑」のような言い方で圃場の在庫の樹木を OpenSearch で引き、候補と出荷の可否を出す

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

造園業者から届く「日陰に強い、高さ二メートル、常緑」のような相談を、樹種の性質・樹高・幹周・枝張・株立・本数に読み替え、圃場の在庫を探します。候補は樹種ごとにまとめ、根巻きの済みや掘り取りの時期など出荷の可否の記録を添えます。

サマリー
生成AI
Azure OpenAI Service/ChatGPT/Claude
AIサービス
Azure AI/Google Vertex AI/OpenSearch
対象業界
その他/建設/自治体
対象部門
営業
対象業務
問い合わせ対応/情報検索
主な課題
問い合わせが多い/属人化している/情報が見つからない
AIで行う処理
検索(RAG)
主な効果
対応スピード向上/検索時間短縮/機会損失防止
導入難易度
★★★☆☆
実装レベル
本格構成
費用感
RAG・個別開発(大)
人間の確認
条件付き
現在工数
90h/月
AI導入後
30h/月
想定削減
67%
年間削減
720h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 営業の担当が相談を受け、樹種か性質、樹高・幹周・枝張、株立か単幹か、本数、時期をメモする
  2. 性質で聞かれたものは、樹種の台帳から合いそうな樹種を挙げる
  3. 挙げた樹種ごとに在庫の表を引き、規格の合うロットを圃場ごとに探す
  4. ロットの根回し・根巻きの済み、コンテナか地植えかを見て、出荷できそうかを確かめる
  5. 掘り取りの時期の目安に入っているか、圃場の責任者に電話で聞く
  6. 候補の樹種と圃場と本数を造園業者に返す
導入後(After)
  1. 人営業の担当が相談の文か電話のメモを画面に貼り、検索のボタンを押す
  2. 自動生成AIが相談から、樹種・性質の言葉・樹高・幹周・枝張・株立・本数・時期・公共工事かを書かれたまま取り出し、性質を決められた区分から選ぶ
  3. 自動Lambda が規格の言い方を数にそろえ、規格の読み方(最低値か目安か)に応じて数の幅を作る
  4. 自動OpenSearch が樹種の性質と規格と時期で絞り、樹種ごとにまとめて、各樹種の合うロットを返す
  5. 自動Lambda がロットの根巻きの済み・掘り取りの時期の記録から、出荷の可否の印を作る
  6. 自動生成AIが候補を記録のまま並べ、聞き返す項目を書いた返事の下書きを作る
  7. 人営業の担当が候補と出荷の可否を確かめ、必要なら圃場の責任者に聞いて返事を送る
各工程の詳しい説明を読む
  1. 営業の担当が相談を受け、樹種か性質、樹高・幹周・枝張、株立か単幹か、本数、時期をメモする
  2. 性質で聞かれたものは、樹種の台帳から合いそうな樹種を挙げる
  3. 挙げた樹種ごとに在庫の表を引き、規格の合うロットを圃場ごとに探す
  4. ロットの根回し・根巻きの済み、コンテナか地植えかを見て、出荷できそうかを確かめる
  5. 掘り取りの時期の目安に入っているか、圃場の責任者に電話で聞く
  6. 候補の樹種と圃場と本数を造園業者に返す

(a)どの圃場にあるかが記憶頼み。 3番目は、圃場を回っている担当にしかすぐにはできません。在庫の表は樹種ごとに何十行もあり、規格で並べ直して探すうちに電話が鳴ります。

(b)規格の読み方を取り違える。 1番目で、「高さ二メートル」が「2メートル以上」なのか「2メートルくらい」なのかが分かりません。公共工事の植栽では規格の寸法は最低値で、2.0メートル未満の木は納められません。 庭の相談の「くらい」と同じに扱うと、検品で戻されます。

(c)同じ樹種のロットが一覧を埋める。 在庫の表を性質で絞ると、シマトネリコの20ロットが並んでほかの樹種が見えなくなります。造園業者に「ほかに何がありますか」と聞かれて、もう一度引き直します。

(d)出荷の可否の確かめに時間がかかる。 5番目で圃場の責任者に電話し、つながらなければ折り返しを待ちます。1件15分のうち、待つ時間が少なくありません。

  1. 【人】 営業の担当が相談の文か電話のメモを画面に貼り、検索のボタンを押す
  2. 【自動】 生成AIが相談から、樹種・性質の言葉・樹高・幹周・枝張・株立・本数・時期・公共工事かを書かれたまま取り出し、性質を決められた区分から選ぶ
  3. 【自動】 Lambda が規格の言い方を数にそろえ、規格の読み方(最低値か目安か)に応じて数の幅を作る
  4. 【自動】 OpenSearch が樹種の性質と規格と時期で絞り、樹種ごとにまとめて、各樹種の合うロットを返す
  5. 【自動】 Lambda がロットの根巻きの済み・掘り取りの時期の記録から、出荷の可否の印を作る
  6. 【自動】 生成AIが候補を記録のまま並べ、聞き返す項目を書いた返事の下書きを作る
  7. 【人】 営業の担当が候補と出荷の可否を確かめ、必要なら圃場の責任者に聞いて返事を送る

3番目で規格の読み方を分けるのが、この構成の分かれ目です。 公共工事の相談なら H2.0 は2.0メートル以上、庭の相談なら2メートル前後、と読み方を Lambda で決めます。読み方が書かれていなければ、推し量らずに聞き返します。

7番目で圃場の責任者に聞くのは、記録で出荷できそうでも、木の状態は記録より新しいからです。 台風の後の傾き、病気の出始めは、測り直しまで記録に入りません。記録で絞った候補だけを聞けば、電話は短くなります。

02今回想定するシステム構成

構成図
圃場の在庫の表(ロット:圃場・区画・樹種・樹高・幹周・枝張・株立数・本数・根巻きの済み・コンテナ)
樹種の台帳(常緑か落葉か・日陰への強さ・掘り取りの時期の目安)
   ▼【トリガー】毎晩の取り込み(測り直し・出荷・根巻きの記録)
AWS Lambda ── 規格を数に、樹種の台帳の性質と掘り取りの時期をロットに付ける
   ▼
Amazon OpenSearch Service
   │   ロットの索引:樹種の番号(keyword)・樹種名(kuromoji)・性質の区分
   │                 樹高・幹周・枝張・株立数・本数・掘り取りの時期(date_range)
   ▼【人】営業の担当が相談を貼る
AWS Lambda
   ├──▶ Claude(Amazon Bedrock)── 相談を条件に読み替える
   ├──▶ 規格の幅を作る ──▶ OpenSearch ── 樹種ごとにまとめて引く(collapse+inner_hits)
   ├──▶ 出荷の可否の印を作る
   ├──▶ Claude(Amazon Bedrock)── 候補を記録のまま並べた下書き
   ▼
営業の画面 ──【人】確かめて、圃場に聞き、返事を送る
役割想定する製品代替候補
検索基盤Amazon OpenSearch Service(collapse、inner_hits、date_range、kuromoji)Azure AI Search、Vertex AI Search(Agent Search)
生成AIClaude(Amazon Bedrock の Converse API、構造化出力)Azure OpenAI(Microsoft Foundry)、OpenAI API
連携AWS Lambda(取り込み、規格のそろえ、規格の幅と出荷の可否の印の作成、検索の呼び出し)AWS Step Functions
保管Amazon S3(取り込みの写し、相談と候補と下書きの記録)社内のファイルサーバー

圃場の在庫の表と樹種の台帳には、この構成から書き込みません。 出荷の引き当ては、営業の担当と圃場の責任者がいつもの表で行います。

樹種名を引くには、形態素解析と文字の正規化が要ります。 AWS の公式ページでは、OpenSearch Service のドメインには Japanese(kuromoji)と ICU の解析のプラグインが全ドメインに含まれるとされています。「シマトネリコ」「しまとねりこ」「シマトネリコ」は ICU でそろえ、別名(「トネリコ」と呼ぶ業者もいる)は樹種の台帳の別名の欄から引けるようにします。

03どうやって実装するのか

Step1

処理の起点を決める

起点は2つあります。毎晩の在庫の取り込みと、営業の担当の検索のボタンです。

取り込みは、圃場の在庫の表から測り直し・出荷・根巻きの記録の変化を書き出して、索引を更新します。索引の本数は「あるか無いか」の目安にだけ使い、返事に書く本数は在庫の表で取り直します。 日中に別の営業が引き当てていることがあるからです。

検索のボタンは、営業の担当が相談を貼るか電話のメモを打ち込んだ後に押します。図面の植栽の一覧がFAXで届いたものは、担当者が樹種と規格を打ち込みます。 樹種の台帳の性質は、営業と圃場の責任者が年に数回見直し、見直した樹種のロットだけを入れ直します。

Step2

入力データを集める

データ中身取得元
相談造園業者の言葉のままの本文、または電話のメモ営業が貼る・打ち込む
ロットロットの番号、圃場、区画、樹種の番号、樹高(H)・幹周(C)・枝張(W)、株立数、本数、測った日圃場の在庫の表
出荷の記録根回し・根巻きの済み、コンテナか地植えか、掘り取りの予定圃場の在庫の表
樹種の台帳樹種の番号、樹種名と別名、常緑か落葉か、日陰への強さ(自社の三段階)、掘り取りの時期の目安自社の樹種の台帳
性質の区分の表「日陰に強い」「北側でも」を shade_tolerant、「葉が落ちない」を evergreen に、などの対応営業で作る表

質を決めるのは、ロットの規格の測り方です。 大分県の共通仕様書が引く国土交通省の公共用緑化樹木等品質寸法規格基準(案)の用語の定義では、樹高(H)は樹冠の頂端から根鉢の上端までの垂直高で一部の突出した枝は含まない、幹周(C)は根鉢の上端より1.2m上りの位置の周長、枝張(W)は四方面に伸長した枝の幅で長短がある場合は最長と最短の平均とされています。圃場の担当がこの定義で測っていれば、公共工事の検品と同じ物差しで在庫を引けます。

株立の木は、株立数と、所要の樹高に達している幹の数で見ます。 同じ定義では、2本立は1本が所要の樹高に達し、他は所要の樹高の70%以上に達していること、3本立以上は過半数が所要の樹高に達し、他は70%以上とされています。ロットには最も高い幹の樹高だけでなく、所要の樹高に達している幹の数を持たせます。

Step3

データの取得方法を決める

取るものどこからどう取るか
性質の合う樹種のロットロットの索引filter の term(evergreen・shade_tolerant)
規格の合うロットロットの索引filter の range(height_m・girth_m・spread_m)
掘り取りの時期が出荷の月を含むロットロットの索引filter の range(dig_window。date_range、relation は contains)
樹種ごとのまとまりロットの索引collapse(species_code)
樹種ごとの合うロットロットの索引collapse の inner_hits(size を指定。既定は3)

ここで大事なのが collapse です。 OpenSearch の公式のドキュメントでは、collapse は指定した項目の値ごとに上位の1件だけを返し、その項目は keyword か数値の型で、doc values が有効で、文書ごとに値が1つでなければならないとされています。樹種名ではなく、樹種の番号(keyword)でまとめます。 樹種名は別名や表記のゆれで同じ樹種が別の値になるからです。

GET /lots/_search
{
  "size": 8,
  "_source": ["lot_no", "field", "block", "species_code", "species_name",
              "height_m", "girth_m", "spread_m", "stems", "qty", "rootball"],
  "query": { "bool": { "filter": [
    { "term":  { "evergreen": true } },
    { "term":  { "shade_tolerant": true } },
    { "range": { "height_m": { "gte": 2.0 } } },
    { "range": { "qty": { "gte": 1 } } },
    { "range": { "dig_window": { "gte": "2026-11-01", "lte": "2026-11-30",
                                 "relation": "contains" } } } ] } },
  "collapse": {
    "field": "species_code",
    "inner_hits": { "name": "lots", "size": 5,
                    "sort": [ { "height_m": "asc" } ] } },
  "sort": [ { "species_code": "asc" } ]
}

inner_hits を新しく指定しないと、樹種ごとに1ロットしか見えません。 公式のドキュメントでは、まとめた上位の1件は inner_hits で展開でき、inner_hits の返す数の既定は3とされています。樹高の低い順に5ロットを返し、規格の最低値に近い木から並べます。 大きすぎる木は、根鉢も重く運ぶ費用もかかるからです。

件数の数え方にも注意が要ります。 公式のドキュメントでは、collapse は上位の結果だけに効き、応答の総件数はまとめる前の全件で、まとまりの数は示されないとされています。画面には総件数を「合うロットの数」として出し、樹種の数は返ったまとまりを数えて出します。 また、from と size はまとまりに効くので、size: 8 は「8樹種」の意味になります。

掘り取りの時期は date_range の型で持ちます。 公式のドキュメントでは、範囲の型の項目に range で問うとき、relation に contains を指定すると、項目の範囲が問い合わせの範囲をすべて含む文書だけが当たるとされています。出荷したい11月全体が掘り取りの時期に入っているロットだけを当てます。 既定の intersects だと、11月1日だけ掘り取りの時期に入るロットも当たります。

Step4

AIへ渡す前に整形する

  1. 規格を数にそろえる … 在庫の表の「H2.0」「2m」「200」を height_m: 2.0 に、「C0.15」を girth_m: 0.15 にします
  2. 規格の幅を作る … 公共工事の相談なら gte に規格の値を入れ、上は空にします。庭の相談なら社内の目安(樹高±0.3mなど)で gte と lte を作ります
  3. 株立の幹を数える … ロットの測った記録から、所要の樹高に達している幹の数と、70%以上の幹の数を出します
  4. 樹種の台帳の値をロットに付ける … 常緑か落葉か、日陰への強さ、掘り取りの時期を、樹種の番号でロットに写します
  5. 空の値を空のまま持つ … 台帳に日陰への強さが書かれていない樹種は、値を入れずに残します

2番目の読み方が、この構成でいちばん取り違えやすいところです。 大分県の共通仕様書では、設計図書に示す寸法は最低値を示すものとするとされています。公共工事の植栽の H2.0 は「2.0m以上」で、1.9mの木は納められません。庭の相談の「2メートルくらい」を同じに扱うと、ちょうどよい1.9mの木が候補から消えます。 相談に公共工事かどうかが書かれていなければ、聞き返します。

5番目を守らないと、性質の絞り込みが嘘をつきます。 日陰への強さが空の樹種を「強くない」として外すのはまだよく、「強い」と既定の値で埋めると、台帳の誰も確かめていない樹種が日陰の相談に出ます。

Step5

AIに処理させる

AIの仕事は2つです。 相談を探す条件に読み替えることと、候補と出荷の可否を記録のまま並べた返事の下書きを作ることです。

させることさせないこと
樹種・性質の言葉・樹高・幹周・枝張・株立・本数・時期・公共工事かを書かれたまま取り出す書かれていない公共工事か庭かを、言い方から推し量ること
性質の言葉を、性質の区分の一覧から選ぶ樹種の性質を自分の知識で決めること(「この木は日陰に強い」)
候補を記録のまま並べ、出荷の可否の印を写す出荷できると言い切ること、掘り取りの時期を自分で決めること
聞き返すべき項目をまとめるその庭や現場に合うと言うこと、価格を書くこと

樹種の性質を知識で決めさせないのが、この構成でいちばん大事な線です。 生成AIは樹種の一般的な性質を答えられますが、同じ樹種でも、自社の圃場で育てた木がどこまで日陰に耐えるかは、自社の台帳の判断です。 AIの知識で「強い」と書いた木を日陰に植えて枯れれば、生産者の責任として戻ってきます。性質は台帳の値だけを使い、台帳に無ければ「台帳に記載なし」と書かせます。

Step6

指示内容を固定する

1回目(相談の読み替え)の指示です。

あなたは植木の生産・卸の会社で、造園業者からの在庫の相談を整理する立場です。
【相談】から、圃場の在庫を探すための条件を取り出してください。

【取り出すもの】
- species_raw: 樹種名。書かれたまま。無ければ空
- trait_words: 性質の言葉。書かれたまま(「日陰に強い」「常緑」など)
- traits: trait_words を【性質の区分】から選んだもの
- height_raw / girth_raw / spread_raw: 樹高・幹周・枝張の言い方。書かれたまま
- stems_raw: 株立か単幹か、株立数。書かれたまま
- quantity: 本数。書かれたまま
- ship_month_raw: 出荷・植栽の時期。書かれたまま
- project_type: public(公共工事)/ private(庭・民間)/ unknown
- missing: 書かれていない項目の名前

【厳守事項】
- 公共工事か庭かが書かれていなければ project_type を unknown にしてください。
- 規格の数を直さないでください。単位も書かれたまま写してください。
- 樹種名から性質を補わないでください。traits は trait_words からだけ選んでください。
- 施主・現場の名前は写さないでください。

【性質の区分】{trait_list}
【相談】{inquiry_text}

2回目(返事の下書き)の指示です。

あなたは植木の生産・卸の会社で、造園業者への返事の下書きを作る立場です。
【候補】は樹種ごとにまとめたロットの記録と、出荷の可否の印です。

【書き方】
- 樹種ごとに、樹種名と、台帳の性質(常緑か落葉か、日陰への強さ)を記録のまま書いてください。
  台帳に値が無いものは「台帳に記載なし」と書いてください。
- ロットごとに、圃場・樹高・幹周・枝張・株立数・本数を記録のまま書いてください。
- 出荷の可否の印は、文言を変えずに写してください。
- 最後に「木の状態は圃場で確かめてからお返事します」と添えてください。

【厳守事項】
- 樹種の性質を、台帳に無いことまで書かないでください。
- 「出荷できます」「この現場に合います」と書かないでください。
- 価格・値引き・運賃を書かないでください。記録に無い数字を書かないでください。

【相談の条件】{conditions}
【候補】{candidates}

「台帳に記載なし」と書かせる一文が要ります。 指示しないと、AIは空の欄を一般的な知識で埋め、台帳に無い性質を、台帳の言葉のように書きます。

Step7

出力形式を固定する

Bedrock の Converse API の outputConfig.textFormat に JSON スキーマを渡し、2回目は次の形で受け取ります。

{
  "inquiry_no": "",
  "conditions": { "traits": [""], "height_from": "", "height_to": "",
                  "project_type": "public | private | unknown", "ship_month": "" },
  "species": [
    { "species_code": "", "species_name": "",
      "traits_listed": { "evergreen": "yes | no | not_listed",
                         "shade": "strong | medium | weak | not_listed" },
      "lots": [ { "lot_no": "", "field": "", "listed": "",
                  "ship_flag": "ready | in_window | out_of_window | check_field" } ] } ],
  "ask_back": [""],
  "draft": ""
}

AWS の公式ページでは、outputConfig.textFormat に JSON スキーマを渡すと応答がスキーマに沿い、enum が使えます。すべての object に additionalProperties: false が要り、数値の minimum・maximum には対応していません。 規格の数は文字のまま写させ、数の照合は Lambda で行います。

1つ目の理由は、traits_listed を台帳と照合できることです。 下書きの性質の値が、その樹種の台帳の値と同じかを Lambda で確かめます。台帳が空の樹種に strong が入っていれば、下書きを出さずに作り直します。

2つ目は、ship_flag で出荷の可否を先に見られることです。 印は Lambda が記録から作ります。

ship_flag作り方
readyコンテナ、または根巻き済みで、掘り取りの時期に入っている
in_window地植えで根巻きはまだだが、掘り取りの時期に入っている
out_of_window掘り取りの時期の外
check_field測った日が古い、または根回しの記録が無い
Step8

システムへ連携する

つなぎ先方式内容
圃場の在庫の表・樹種の台帳毎晩の書き出し、本数の取り直し(読み取りのみ)ロットの索引の元、返事の本数
Amazon OpenSearch ServiceLambda からの登録・検索ロットの索引
Amazon BedrockConverse API(Claude)読み替えと下書き
営業の画面社内の画面相談の貼り付け、樹種ごとの候補と出荷の可否、下書き

圃場の責任者への確かめは、営業の画面から候補のロットの一覧を送る形にします。 電話で口頭で伝えるより、どのロットを聞いているかが取り違えなく伝わります。 返事は責任者が一覧に書き込み、営業がそれを見て造園業者に返します。

Step9

人が確認する

  1. 読み替えを見る … 規格の数と、公共工事か庭かが相談のとおりかを確かめます
  2. 規格の読み方を確かめる … project_type が unknown の相談は、造園業者に聞いてから候補を選びます
  3. 性質の記録を見る … 「台帳に記載なし」の樹種は、圃場の責任者に聞いてから勧めます
  4. 出荷の可否を圃場に聞く … in_window と check_field のロットは、責任者に木の状態を確かめます
  5. 下書きを直して返す … 価格と運賃は営業が書き足します

4番目を省かないでください。 記録で in_window でも、根回しをしていない大きな木は掘り取りの後に傷むことがあります。出荷して植えた後に枯れれば、植え替えの手間は造園業者に、信用は生産者に返ってきます。

Step10

例外に対処する

起きること対応
公共工事か庭かが書かれていない規格の幅を作らずに聞き返す。急ぎなら両方の読み方の候補を分けて並べる
性質の言葉が区分に読み替えられないtraits を空にし、trait_words を画面に出して営業が選ぶ
候補が0件規格の条件を外した件数と、出荷の時期の条件を外した件数を示す
本数が1ロットで足りない同じ樹種の別の圃場のロットを足し合わせて並べ、規格のばらつきを示す
測った日が古いロットだけが合うcheck_field にして、圃場で測り直してから返す
掘り取りの時期の外候補から外さず out_of_window と出し、次の時期を示す
構造化出力が返らない樹種ごとの候補と出荷の可否の印だけを出し、下書きは営業が書く

4行目は、公共工事の植栽で多い相談です。 10本の注文に、第2圃場の6本と第4圃場の4本を合わせると、同じ規格でも枝張や樹形がそろわないことがあります。 樹高と枝張の幅を並べて示し、そろうかは造園業者が決めます。

Step11

記録を残す

  • 相談ごとの、相談の文(施主と現場の名前を伏せたもの)、1回目の JSON、営業が直した箇所
  • 検索の条件と、樹種ごとの候補のロット、2回目の JSON と照合の結果
  • 圃場の責任者の返事と、実際に出荷したロット、出荷しなかった理由
  • 樹種の台帳の性質を見直した日と、見直した担当

3つ目は、出荷の可否の印の作り方を見直す材料になります。 in_window の印でも圃場で断られることが多い樹種があれば、掘り取りの時期の目安か、根回しの記録の付け方を直します。

04実装レベルの3段階

最小構成:手元のAIサービスで相談を読み替え、表計算の在庫を性質と規格で絞る / 相談の整理
半自動化:上記+OpenSearch にロットの索引を作り、樹種ごとにまとめて引けるようにする / 候補の検索
本格構成:上記+規格の読み方の切り替え、出荷の可否の印、返事の下書きと照合 / 相談から下書きまで

半自動化で、1件15分が9分程度になります。 樹種の洗い出しと圃場ごとのロットの探し出しはほぼなくなりますが、出荷の可否の確かめと返事を書く作業が残ります。本格構成で5分になり、この段階が本記事の想定です。 段階を飛ばさないでください。 半自動化を1か月使うと、どの性質の言葉が区分に読み替えられなかったか、どのロットの測った日が古いかが残ります。台帳と在庫の表を直してから本格構成に進むほうが、候補と出荷の可否が確かになります。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
4 名
月間件数
360 件
1件あたり現在時間
15 分
1件あたり導入後時間
5 分
現在  360件 × 15分 ÷ 60 = 90 時間/月
導入後 360件 × 5分 ÷ 60 = 30 時間/月
月間削減時間
60h
削減率
67%
年間削減時間
720h
年間金額換算(時間単価2,600円)
187万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 圃場を何か所も持ち、数百の樹種を規格ごとのロットで管理している植木の生産・卸の会社。造園業者から樹種の性質と規格で「何かないか」という相談が毎月数百件届き、どの圃場のどの区画に合う木があるかを、圃場を回っている担当の記憶に頼っている場合。樹種ごとの性質(常緑か落葉か、日陰への強さなど)を自社の台帳にまとめている、またはまとめられる場合。AWS を使える担当か委託先がいる場合。
向いていない
  1. 圃場が1か所で、営業の担当が全部の木を見て回れる場合。在庫が「樹種と本数」だけで、規格(樹高・幹周・枝張)や区画の記録が無い場合(先にロットの記録を整えます)。相談の大半が樹種と規格の指定で、性質の言葉で探す相談がほとんど無い場合。なお、その庭や現場に合う木かの判断、掘り取りと出荷ができるかの最終の判断、価格の約束は、この構成では代替できません。台帳と在庫の記録から候補を探し、出荷の可否の記録を並べるまでです。

07最小構成で試す方法

  1. 先月の相談から30件を選ぶ(性質の言葉で来たもの、公共工事の規格の相談、複数の圃場を合わせたものを混ぜる)
  2. それぞれについて、実際に返した樹種と圃場、出荷したロットを書き出す
  3. 在庫の表を表計算に書き出し、樹種の台帳から常緑か落葉か、日陰への強さ、掘り取りの時期の列を足す
  4. 30件の相談を手元のAIサービスに貼り、「樹種・性質の言葉・樹高・幹周・枝張・株立・本数・時期・公共工事かを書かれたまま取り出してください。樹種名から性質を補わず、公共工事か分からなければ不明としてください」と指示する
  5. 取り出した条件で表計算を絞り、樹種ごとに並べ直して、実際に返した樹種と圃場が見つかるかを見る
  6. 当時候補に挙がらなかった圃場に、合うロットがあったかを見る

6番目で見つかったロットが、この構成で取り戻せる注文です。 回っている担当の少ない圃場のロットが多く見つかれば、記憶に頼らない在庫の引き方の効き目がそのまま見えます。

出てきた内容判断
当時の樹種と圃場が見つかり、挙がらなかったロットもあったOpenSearch の索引に進む
性質を補った・公共工事かを推し量った指示の書き方で直る。構成は有効
ロットに規格や測った日の記録が無いものが多い在庫の表の整備が先

08実装時につまずきやすいポイント

問題対策
同じ樹種のロットが一覧を埋める樹種の番号で collapse し、inner_hits でロットを展開する
collapse の要求が通らないまとめる項目は keyword か数値で、文書ごとに値が1つ。樹種名ではなく番号でまとめる
樹種ごとに3ロットしか見えないinner_hits の size の既定は3。見せたい数を指定する
総件数を樹種の数として出す総件数はまとめる前の全件。樹種の数は返ったまとまりを数える
掘り取りの時期に一部だけ入るロットが当たるrelation を contains にする(既定は intersects)
公共工事の規格を「くらい」で引く公共工事なら最低値。読み方が分からなければ聞き返す
台帳に無い性質をAIが書く「台帳に記載なし」と書かせ、台帳の値と照合する

上の4行は、collapse にまつわる失敗です。 どれも検索は動いていて、画面の数や並びが少しずつずれる形で出ます。 第8章の30件で、樹種の数とロットの数を在庫の表と見比べてください。

最後の2行は、規格と性質の読み方の失敗です。 どちらも、生産者の側で決めるべきことを、相談の言い方やAIの知識で決めてしまうことから起きます。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 造園業者からの相談(施主、現場、工期、植栽の図面)、圃場の在庫と樹種の台帳です。相談には、施主の家の場所や工事の予定が書かれていることがあります。

  1. 施主と現場の情報を外す … 施主の名前、現場の住所、造園業者の担当者の名前は、Claude に渡す前に伏せます。どこでいつ工事があるかは、造園業者と施主にとって外に出したくない情報です
  2. 性質を言い切らない … 樹種の性質は自社の台帳の値だけを使い、その庭に合うかは造園業者が決めます
  3. 出荷を約束しない … 出荷の可否は記録の印までにし、出荷できるかは圃場の責任者が木を見て決めます
  4. 価格は扱わない … 取引先ごとの価格は索引に入れず、下書きにも書かせません
  5. 台帳の手入れの担当を決める … 誤った性質が台帳に入ると、合わない木が根拠つきで出ます。見直すときは営業と圃場の責任者の2人で確かめます
  6. 索引への接続を限る … OpenSearch のドメインには、Lambda と営業の担当だけが接続できるようにします

誤りが起きた場合のリスクは、規格の読み方を取り違えて検品で戻されること、台帳に無い性質で木を勧めること、掘り取りに向かない木を出荷することの3つです。 規格の読み方の切り替え、台帳との照合、出荷の可否の印と圃場の確かめの3つで防ぎます。

10まず何から始めるか

1週目:在庫の表と台帳を見る

ロットを書き出し、規格と測った日が空のロットを数えます。樹種の台帳の常緑か落葉か、日陰への強さ、掘り取りの時期の欄が空の樹種を数えます。

2週目:30件で試す

第8章のとおり、先月の相談30件で、当時の樹種と圃場が見つかるか、挙がらなかったロットがあったかを見ます。樹種名から性質を補っていないか、公共工事かを推し量っていないかを最優先で見ます。

3週目:区分と読み方を決める

性質の区分の一覧を作り、庭の相談での規格の目安の幅を決めます。圃場の担当の測り方を、規格の定義にそろえます。

4週目:索引を作る

OpenSearch にロットの索引を作り、樹種ごとにまとめて引けるようにします。この時点では、出荷の可否の印と下書きは使いません。

2か月目: 規格の読み方の切り替え、掘り取りの時期の date_range、出荷の可否の印、下書きと照合を足します。3か月目以降: 候補から出荷できた割合、検品で戻された件数、「台帳に記載なし」で出た樹種の数を毎月数えます。回っている担当がいない日にも、樹種ごとの候補と出荷の可否がその日のうちに返せた時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-27/最終更新:2026-10-27
確認した内容情報源確認日
樹木が国土交通省の公共用緑化樹木等品質寸法規格基準(案)に適合したもの等とされ、設計図書に示す寸法は最低値を示すこと。樹高(H)が樹冠の頂端から根鉢の上端までの垂直高で一部の突出した枝を含まないこと、幹周(C)が根鉢の上端より1.2m上りの位置の周長であること、枝張(W)が四方面に伸長した枝の幅で長短がある場合は最長と最短の平均であること。株立の2本立・3本立以上の樹高と株立数の関係大分県: 公園緑地工事の共通仕様書 第2章 植栽2026-10-27
collapse が項目の値ごとに上位の1件を返し、項目が keyword か数値で doc values が有効、文書ごとに値が1つでなければならないこと。inner_hits で展開できること。総件数がまとめる前の全件で、まとまりの数は示されないこと。from と size がまとまりに効くことOpenSearch: Collapse search results2026-10-27
inner_hits の size の既定が3で、sort を指定できることOpenSearch: Retrieve inner hits2026-10-27
date_range などの範囲の型があること。範囲の型の項目に range で問うとき relation に intersects(既定)・contains・within を使えることOpenSearch: Range field types2026-10-27
OpenSearch Service のドメインに Japanese(kuromoji)と ICU の解析のプラグインが全ドメインに含まれることAWS: Plugins by engine version in Amazon OpenSearch Service2026-10-27
Converse API の outputConfig.textFormat で JSON スキーマに沿った出力が得られ、enum が使えること。additionalProperties: false が要ること。数値の minimum・maximum に対応しないことAWS: Structured outputs(Amazon Bedrock)2026-10-27

その庭や現場に合う木か、掘り取りと出荷ができるか、価格は、営業の担当・圃場の責任者・造園業者が判断してください。 本記事は上記のページで確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-2013)についてのご相談はこちらから。

AI活用について相談する
目次