弁護士のように時間チャージで相談できる技術顧問は、市場にほぼ存在しない ── 株式会社ミズナラ 導入事例

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

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

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

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

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

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

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

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

冨永さんは AIIT（産業技術大学院大学）つながりで知っていて、アーキテクトとしての評判が良く、AWS の知見も深い。AWS 全12冠の実績もあります。相談当時はまだ生成AIが今ほど発達する前で、インフラのベストプラクティスをネット検索で探すのにも限界があった頃です。そこを埋めてくれる相手として、ほぼ一択でした。

小田様: 実際に相談してみて良かったのは、技術の正解を提示するだけでなく、どの軸で選ぶべきかという判断基準まで一緒に並べてくれたことです。Slack での返答も早く、論点が溜まりません。

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

小田様: 良かったのは、各選択肢について、今の規模でのコスト感まで試算してもらえたことです。サーバコストには上限があって、それを超えたら即アウト。専任のインフラ担当もいないので、運用の重さまで含めて判断できたのは大きかったです。

OpenSearch のような選択肢もありましたが、今回はそこまで重い仕組みは要らない。「強い技術」ではなく「今回の制約に合う技術」を選べたのが価値でした。

小田様: 納品された PDF は、正直それだけで十分すぎると感じました。時間の上限を決めてお願いしていたのですが、残りの時間を無理に消化してもらう必要がないと思ったくらいです。「これ以上お願いするのが申し訳ない」という感覚でした。

小田様: 実際に進めてみると、検証と立ち上げはかなりスムーズでした。特に助かったのは、pgVector のインストールと初期化の罠。Docker と Aurora で「いつ、どう入れるか」は意外と迷う論点なんですが、事前に相談していたので詰まらずに済みました。

小田様: こういうところは、実装できるかどうかより「どう組み込むのが自然か」を相談できるのが助かりました。検索だけでなく、アーキテクチャ全体の相談相手になってもらえた感覚です。

小田様: 類似検索は派手な機能ではないですが、数千ページの中から必要な箇所を自然な粒度で引けるというニーズにはきっちり効いています。編集や確認を行うメンバーが、必要なときに検索して使う。地に足のついた使われ方です。

公開から約1年、運用はかなり落ち着いていて、保守工数はほぼかかっていない状態が続いています。ドキュメント更新の頻度もそこまで高くないので、現在は「静かに回り続けている」フェーズです。

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

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

木下様: 現場で抱えている課題を「AIで解決しましょう」と言われても、実際にはそこで止まってしまう人が多いと思います。AIが候補を出してくれても、その中で何を採るべきか判断するには、やはり相談相手が必要です。

特に深いドメイン知識や細かな制約条件は、Web上に十分な情報があるわけではありません。適切なコンテキストを拾って、現場に合う判断に落とせる人の価値は、AIが賢くなっても変わらないと感じています。

小田様: そもそも、時間チャージで技術顧問を頼める相手って、市場にほとんどいないんです。必要な期間だけ、必要な論点だけ相談できる形は、特に中小規模の開発チームにとって現実的な選択肢です。

雇用するより安いコストで、超優秀な人の知見を得られる。しかも月額5万円〜と価格感も読みやすく、短期で始められる。ビジネスモデルとしても、間違いなく良いと思います。

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

木下様: 冨永さんは NAIST（奈良先端科学技術大学院大学）つながりの縁でもあります。NAIST 出身のエンジニアはみんな本当に優秀で、つながりでいろんなことが広がっています。

小田様: 社会に出てから、その優秀さを改めて実感しています。今回の品質も、その延長線上にあるんだろうと思います。

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