日本最大級の自治体における防災ドキュメント基盤 ── 約6,000万円規模・3年契約の案件で、数千ページの文書に対する「類似検索」をどの技術で実現すべきか。専任アーキテクトを雇うほどではない、でも社内だけでは決め切れない。この隙間を埋める形で、株式会社ミズナラは Leach 生成AI顧問を活用しました。CTO 小田 将之 様、CEO 木下 祐馬 様にお話を伺います。

「弁護士のように時間チャージで技術顧問をやってくれる人って、市場にほとんどいないんです」── 株式会社ミズナラ CTO 小田 将之 様
※本記事で紹介する防災領域の取り組みには、ミズナラの前身体制で行われたプロジェクトを含みます。本文中の約6,000万円規模という記載は、当該取り組み全体（インフラを含む）の規模感を示したものであり、Leach の顧問料や保守契約の金額を指すものではありません。公開上の配慮から、顧客名や一部の固有情報は伏せて記載しています。
支援サマリー



- 約6,000万円：日本最大級の自治体における防災領域案件の規模感（3年契約・インフラ含む）
- 7候補→1案：MySQL全文検索／Aurora PostgreSQL＋pgVectorなど、コスト・運用負荷・要件適合で比較
- 保守工数ほぼゼロ：公開から約1年、類似検索は社内で日常的に利用。運用は落ち着いたまま
- PDF1本で完結：「これ以上お願いするのが申し訳ない」と発注時間を残したまま設計確定


本事例でご活用いただいたサービスについて詳しくはLeach 生成AI顧問をご覧ください。
企業プロフィール





小田 将之 様｜株式会社ミズナラ CTO

木下 祐馬 様｜株式会社ミズナラ CEO


1. ミズナラとは ── 大規模ドキュメントを扱うための土台をつくる
ミズナラは、大規模なドキュメントをどう管理し、どう編集し、どう発信しやすくするかをテーマに取り組んでいる会社です。自社では、大規模ドキュメント管理を見据えた「Wordless」や、AI時代のオフィスツール「OffiStill」を研究開発しています。

現実の業務文書は Markdown だけでは完結しません。表データや図、引用関係を含めて「業務に耐える粒度」で扱える仕組みが要るんです。今回の案件も、その延長線上にありました。

少人数のチームで、受託と自社プロダクトの R&D を並行しています。だからこそ、全部を自前で抱え込むのではなく、要所だけ外部の強い人に入ってもらうという発想を重視していました。Leach さんにお願いしたのも、まさにその文脈です。

2. 導入前の課題 ── 類似検索は必要だが、仕様書と予算の制約で技術が決め切れない



相談対象は、日本最大級の自治体における防災ドキュメント基盤でした。約6,000万円規模・3年契約の案件で、大量のPDFや画像からOCRでテキスト化した情報を蓄積し、Web上で検索・閲覧できるようにするものです。既存のデータベースは MySQL、全文検索も MySQL でまかなっていました。

一番大きかったのは、「似た記述を探したい」要件はあるのに、どの技術を選ぶべきか社内だけでは決め切れなかったことです。既存の MySQL 全文検索では表現力に限界がある。かといって、その先の正解が見えていなかった。

依頼した時点では、正直「似たようなドキュメントを探せる仕組みがほしい」というかなりふわっとした相談でした。そこに対して冨永さんから「それならベクトル検索が候補になります」と提案をもらった。ミズナラ単体では、そこにたどり着けていなかったんです。

自治体案件ならではの「達成率100%必達」という制約
検索機能だけを見れば選択肢はいくつもあります。でも、自治体案件では「仕様書に書いた以上は、きちんと動かして達成率を落とさない」ことが絶対なんです。途中でもっといいアイデアが浮かんでも、仕様書にないことをやればガントチャートが崩れ、達成率が落ち、補助金が打ち切られかねない。

だからガントチャートはバッファを積んで組み、年次ごとの達成率を100%に近づけることを最優先します。その制約のなかで、類似検索という新しい要素を入れないといけなかった。「良い技術」ではなく「制約に収まる技術」を選び切れるかどうかが勝負でした。

ミズナラが当時抱えていた論点は、次の3つに集約されます。
- 「似た文書を探したい」という要望を、どの技術で実現するかが見えていなかった。ミズナラ側ではベクトル検索という選択肢にたどり着けておらず、Leach 側から意味検索の方向性を提案。
- 検索精度だけでなく、運用負荷・予算上限・説明責任を同時に成立させる必要があった。専任のインフラ担当がいないため、Serverless 前提で無理なく回せる構成にしたい。
- 仕様書と納期を崩せない。新規要素を入れるにしても、達成率と納期に響かない設計でなければ採用できない。



3. Leachを選んだ理由 ── 雇用ではなく、数十時間の設計支援が欲しかった



実装そのものより、設計とアーキテクチャの壁打ち相手が欲しかったからです。フルタイムで採用するほどではない。でも数十時間だけでも実力のあるアーキテクトに入ってもらえたら、全体が一気に前に進む感覚がありました。

冨永さんは AIIT（産業技術大学院大学）つながりで知っていて、アーキテクトとしての評判が良く、AWS の知見も深い。AWS 全12冠の実績もあります。相談当時はまだ生成AIが今ほど発達する前で、インフラのベストプラクティスをネット検索で探すのにも限界があった頃です。そこを埋めてくれる相手として、ほぼ一択でした。
実際に相談してみて良かったのは、技術の正解を提示するだけでなく、どの軸で選ぶべきかという判断基準まで一緒に並べてくれたことです。Slack での返答も早く、論点が溜まりません。

もう一つ大きかったのは、プロジェクトのコスト内に収まること。約6,000万円規模と言っても、専任アーキテクトを雇うのは現実的ではない。だからこそ「設計だけを必要な時間分だけ頼める」形がちょうど良かったんです。

ミズナラが求めていたのは、開発を丸ごと委託することではありません。必要だったのは、次の役割に限定された支援でした。

- 技術選定の比較軸を、今回の制約に合わせて整理する
- コスト感と運用負荷を、導入前に試算する
- 実装で踏みがちな落とし穴（罠ポイント）を先出しする


この「設計だけを切り出して頼みたい」というニーズに、Leach の生成AI顧問が噛み合いました。
4. 支援内容 ── 7候補の比較と「罠ポイント」の先出し



Leach が主に支援したのは、類似検索の方式選定です。最初の「似たようなドキュメントを探したい」というふわっとした相談に対して、まずベクトル検索を提案。そのうえで、7つの候補を並べ、コスト・運用負荷・要件適合の3軸で比較しました。

有力案として整理されたのは PostgreSQL + pgVector。さらに Aurora PostgreSQL と RDS for PostgreSQL の両方を並べ、どちらを採るかの判断基準まで提示しています。最終的には、既存 MySQL が Aurora Serverless v2 で動いていたこと・コスト感・移行のしやすさを踏まえ、Aurora Serverless v2 を中心に進める方針で着地しました。

良かったのは、各選択肢について、今の規模でのコスト感まで試算してもらえたことです。サーバコストには上限があって、それを超えたら即アウト。専任のインフラ担当もいないので、運用の重さまで含めて判断できたのは大きかったです。OpenSearch のような選択肢もありましたが、今回はそこまで重い仕組みは要らない。「強い技術」ではなく「今回の制約に合う技術」を選べたのが価値でした。





「設計と罠ポイントさえ事前にわかっていれば、今の時代、実装はまあできる。そこを整理してもらえたのが大変助かった」── 株式会社ミズナラ CTO 小田 将之 様
納品された PDF は、正直それだけで十分すぎると感じました。時間の上限を決めてお願いしていたのですが、残りの時間を無理に消化してもらう必要がないと思ったくらいです。「これ以上お願いするのが申し訳ない」という感覚でした。

さらに Leach は、比較表だけでなく、実装で実際にハマりやすい論点を事前に共有しました。pgVector の導入タイミング、初期化の順序、Docker 環境と Aurora 環境での差分、そして CloudFront キャッシュの運用設計まで。単なる技術調査ではなく、「実装でつまずく場所まで先回りする」支援になっていました。

5. 運用1年後の今 ── 検索は定着し、保守はほぼ発生していない
pgVector 導入時のつまずきどころを事前に回避
実際に進めてみると、検証と立ち上げはかなりスムーズでした。特に助かったのは、pgVector のインストールと初期化の罠。Docker と Aurora で「いつ、どう入れるか」は意外と迷う論点なんですが、事前に相談していたので詰まらずに済みました。

CloudFront の手動運用を CI/CD に組み込む



支援は検索基盤だけにとどまりませんでした。デプロイ後の CloudFront キャッシュ削除についても、運用改善の提案が行われています。

Before

デプロイのたびに CloudFront の管理画面に入り、手作業でキャッシュ削除ボタンを押していた

After

CodePipeline の Deploy ステージ後段に Invalidate ステージを追加し、aws cloudfront create-invalidation を自動実行する構成を整理
こういうところは、実装できるかどうかより「どう組み込むのが自然か」を相談できるのが助かりました。検索だけでなく、アーキテクチャ全体の相談相手になってもらえた感覚です。
1年経っても、必要な人が必要な分だけ検索している



類似検索は派手な機能ではないですが、数千ページの中から必要な箇所を自然な粒度で引けるというニーズにはきっちり効いています。編集や確認を行うメンバーが、必要なときに検索して使う。地に足のついた使われ方です。
公開から約1年、運用はかなり落ち着いていて、保守工数はほぼかかっていない状態が続いています。ドキュメント更新の頻度もそこまで高くないので、現在は「静かに回り続けている」フェーズです。

同じように設計判断で迷っている方へ



「雇うほどじゃないが、独力で決めるには重い」── 中小規模の開発チームで頻出するこの局面に、Leach 生成AI顧問は月額5万円～、まず1ヶ月お試しから入れます。
詳細を見る
6. 生成AI時代でも、意思決定には相談相手がいる
今回のインタビューで印象的だったのは、ミズナラが Leach を「実装代行」ではなく、制約条件を踏まえて選択肢を絞り切ってくれる相談相手として評価していたことです。

相談当時は、今ほど生成AIが発達する前でした。ネット検索でベストプラクティスを集めるのが精一杯で、自分たちの制約に合わせて判断する部分は、人に頼るしかなかったんです。

そして今、生成AIが発達して技術の選択肢はむしろ増えました。でも、選択肢が増えるほど、どれを選ぶべきかは難しくなる。AIの答えを鵜呑みにしても、既存プロジェクトの制約に合うとは限らない。ベストプラクティスを知っているだけでは足りなくて、今すでに動いているプロジェクトの制約条件を拾って判断できる人が必要です。そこはAIだけではまだ難しい。

現場で抱えている課題を「AIで解決しましょう」と言われても、実際にはそこで止まってしまう人が多いと思います。AIが候補を出してくれても、その中で何を採るべきか判断するには、やはり相談相手が必要です。特に深いドメイン知識や細かな制約条件は、Web上に十分な情報があるわけではありません。適切なコンテキストを拾って、現場に合う判断に落とせる人の価値は、AIが賢くなっても変わらないと感じています。

そもそも、時間チャージで技術顧問を頼める相手って、市場にほとんどいないんです。必要な期間だけ、必要な論点だけ相談できる形は、特に中小規模の開発チームにとって現実的な選択肢です。雇用するより安いコストで、超優秀な人の知見を得られる。しかも月額5万円～と価格感も読みやすく、短期で始められる。ビジネスモデルとしても、間違いなく良いと思います。


7. 今後の展望 ── 良い関係を続けながら次の挑戦へ
今回の案件で終わりではなく、今後も良好な関係を続けながら、新しい相談があれば一緒に進めたいと思っています。生成AIの進化で選択肢はさらに増えるので、なおさら設計の壁打ち相手は重要になります。

冨永さんは NAIST（奈良先端科学技術大学院大学）つながりの縁でもあります。NAIST 出身のエンジニアはみんな本当に優秀で、つながりでいろんなことが広がっています。社会に出てから、その優秀さを改めて実感しています。今回の品質も、その延長線上にあるんだろうと思います。

技術的な悩みを抱えている企業は、まず相談してみるのがいいと思います。優秀なアーキテクトと壁打ちできる価値がわかる人には、かなり刺さるサービスです。雇用するより軽く、でも必要なタイミングでは深く入ってもらえる。そのバランスが良かったです。

生成AIの時代になっても、プロジェクトを前に進めるのは「もっともらしい答え」ではなく、制約に合った意思決定です。ミズナラの事例は、実装を外注しなくても、設計と判断を外部の強い専門家に補ってもらうだけで成果が大きく変わることを示しています。

弁護士のように時間チャージで相談できる技術顧問 ── 月額5万円～／まず1ヶ月お試しOK／本契約は最短3ヶ月～／Slack で即時相談／必要なら実装・受託開発までそのまま

詳細を見る