技術記事

「自分の知識や経験を持ったAIを作りたい」という相談が増えています。

過去の資料や文章をAIに読み込ませれば、自分の代わりに考えてくれるのではないかと考えるのは自然ですが、実際に作ってみると資料を大量に渡すだけでは「自分専用AI」にはなりません。

今回micomiaでは、アプリ・システム開発の相談を受けたときに、必要な情報をヒアリングし、技術を選び、要件を整理し、概算見積まで支援するローカルLLMの試作としてmicomia株式会社の代表 畑井駿佑のAIを開発しました。

学習データとして使ったのは、noteの公開記事152本と下書き73本、合計225本に加え、これまで実際に発行した40件以上の見積書です。

この記事では、完成した機能を紹介するだけではなく、4Bモデルで会話が破綻したこと、34KBのプロンプトで指示が埋もれたこと、LLMに見積を計算させて数字が合わなくなったことなど、開発中に詰まった点を中心にまとめています。

1.上流工程を支援する「畑井駿佑AI」

アプリ・システム開発の受託では、案件が違っても上流工程で確認する内容には共通点があります。

• 誰が使うのか

• どのような課題を解決したいのか

• 最初のリリースに何が必要か

• Web、iOS、Androidのどこで提供するのか

• AIを使う必要があるのか

• 管理画面や外部サービスとの連携が必要か

• 予算と希望時期はどの程度か

今回の試作では、ユーザーが作りたいサービスについて自由に入力すると、AIが不足している情報を一問ずつ確認します。情報が揃った段階で、MVPの機能、技術構成、要件、概算見積を整理する流れにしました。

ただし今回のAIモデルの役割はAIだけで受注判断や最終見積を確定するものではなく、あくまで人が行う上流工程の抜け漏れを減らし、最初の整理を速くするための支援としています。

2.「判断のやり方」を再現する

最初に決めたのは、畑井自身の口調を真似るチャットボットにはせず経験による判断をLLMで代行できるようにしようということです。

口調を真似るだけですとおもちゃになっていまうのでそれはそれで興味深かったのですが今回はそこまでしないことにしました。

再現したいのは、次のような判断です。

• 次に何を質問するべきか

• MVPでは何を残し、何を後回しにするべきか

• AIを使うべきか、従来のプログラムで十分か

• Flutter、React、Firebaseなどをどう選ぶか

• 見積の桁感をどのように考えるか

• 顧客へ確認せず、勝手に決めてはいけないことは何か

このあたりについては経験によって培っているので言語化しないと人に対しても教えるのが難しいです。そのため今回は商談の録画データなども観ながら作成しました。

3.自分専用AIでは、データを役割ごとに分ける

自分のAIを作ろうとすると、最初に「過去の文章を全部学習させる」という発想になりがちですが、全部入れるとやりたいことを実行するために役に立たないデータを覚えてしまいます。

今回の構成では、情報を次のように分けました。

LLMに向いているのは、曖昧な相談文を読み取り、次に確認すべきことを考え、自然な言葉で返すことです。

一方、金額計算や出力形式、質問数の上限など、毎回同じ結果にならなければ困る処理は通常のプログラムに向いています。

今開発プログラムはここまで処理を担当し、ユーザー入力を解析したりユーザーに合わせて文章を出力する部分はLLMが担うなど細かな役割分担を設計しています。

4.用意した学習データをそのまま入れなかった理由

今回使った素材は、noteの公開記事152本と下書き73本、過去の見積書40件以上です。

ただし、これらをそのまま一つの巨大なプロンプトへ貼り付けたわけではありません。

まず、見積書から共通する機能を抽出し、認証、会員管理、決済、通知、チャット、管理画面などの単位で価格レンジを整理しました。これがマスタデータです。

次に、noteの記事から、畑井が案件を判断するときに繰り返し使っているビジネスや開発の考え方を抽出しました。最終的には、MVP、技術選定、UI/UX、品質、予算、納期など9カテゴリの判断原則に整理しています。

大切だったのは、AIへ渡す前に、人間が自分の判断を一度言語化したことです。

過去の文章には、結論だけでなく、そのときの案件固有の事情や前提も含まれています。AIがそれらを一般原則と誤解すると、別の案件にも同じ判断を当てはめてしまいます。
そこで、原文は経験を参照するための情報として残し、常に守ってほしい判断だけを別の短いルールに分けました。

なお、実際の顧客資料や見積を利用する場合は、顧客名、担当者名、連絡先、案件固有の秘密情報などをそのまま混ぜない設計が必要です。
自分専用AIであっても、データを用途別に分離し、アクセス権限とログの扱いを決める必要があります。

5.RAG、プロンプト、コードの役割を分ける

今回の試作は、すべてを一つの技術で解決できません。
大きく分けると、次の構成です。

1. ユーザーが相談内容を入力する

2. サーバーが会話履歴と現在のヒアリング状況を整理する

3. 必要な判断原則、関連する過去情報、技術メモを組み合わせる

4. ローカルLLMが次の質問または提案を生成する

5. サーバーが質問数、出力形式、見積計算を検証する

6. 問題がなければチャットUIへ表示する

ここでいうRAGは、保存している全資料を毎回渡すことではありません。ユーザーの相談に関係する情報を検索し、そのとき必要な範囲だけLLMへ渡す仕組みです。

判断原則のように毎回必要な短い情報はシステムプロンプトへ入れます。過去の記事や案件情報のように量が多いものは、必要になったときだけ参照します。計算や形式チェックはLLMの外で処理します。

自社データを使ったAIについては、以前の記事でRAGとファインチューニングを実際に比較しています。知識の更新や出典提示が必要な場合は、まずRAGを検討する方が設計しやすいと考えています。

関連記事：【社長の知識をAIに】園芸の知識を学習したAIを開発しました。

6.フォーム型で作り、チャット型へ変更した

最初に作ったのは、必要な機能をフォームで選ぶと見積が組み上がるツールでした。

入力が決まっているため、動作は安定します。見積ツールとして考えるなら、フォーム型の方が正確です。

しかし、実際に触ってもらうと「会話しながら決めるものではないんですね」と言われました。上流工程では、相談者自身も最初から必要な機能を理解しているとは限りません。話しながら目的を整理し、不要な機能を削り、必要な条件を見つけていくことに価値があります。

そこで、ブラウザ上で自由に会話できるチャットUIへ作り直しました。裏側では、マスタデータと判断原則を使っています。

7.機密情報を扱うため、ローカルLLMを選んだ

クラウドの生成AI APIを使えば、より高性能なモデルを比較的簡単に利用できます。
それでも今回は、案件情報や見積という機密性の高い情報を扱う前提から、ローカルLLMで試作しました。

実行環境にはOllamaを利用しています。モデルを手元のPCへダウンロードし、ローカルで推論用のAPIを立ち上げることができます。

ただし、「ローカルで動く＝自動的に安全」ではありません。

• 会話ログをどこへ保存するか

• PCやストレージを暗号化しているか

• 誰がモデルとデータへアクセスできるか

• バックアップへ機密情報が複製されないか

• 利用するモデルのライセンスが用途に合っているか

こうした点は別途確認する必要があります。
また、機密情報を外部へ送れない要件がない場合は、クラウドAPIの方が導入・運用コストを抑えられるケースもあります。
ローカルLLMは目的ではなく、データの性質から選ぶことが多いので安さとかその辺りのメリットは小規模な利用ではあまりありません。

8.4Bから8B、14Bへ変えて分かったモデルの差

最初は、手元にあった4Bクラスの小さなモデルで動かしました。
しかし、実際の会話はまったく安定しません。

たとえば、「植物診断アプリを作りたい」という相談に対して、最初は「誰が使いますか？」と聞くことはできます。
ところが「植物を育てている人です」と答えると、急に園芸の一般的なアドバイスを始め、アプリ開発のヒアリングから外れてしまいました。その後、同じ質問を何度も繰り返すこともありました。

プロンプトを調整しても十分には改善しなかったため、日本語性能を重視してSwallow系の8Bモデルへ変更しました。すると、脱線と質問の繰り返しはかなり減りました。最終的には、より推論が安定した14Bクラスのモデルまで上げています。

今回の条件では、モデルを大きくしたことで、会話履歴、判断原則、参照情報を同時に扱う安定性が上がりました。ただし、すべての4Bモデルが使えないという意味ではありません。用途、量子化、プロンプト、与える情報量によって結果は変わります。

小さいモデルは動作が軽く、必要なメモリも少ないという利点があります。
決まった分類や短い文章の整形であれば、小さいモデルで十分な場合もあります。一方、複数ターンのヒアリングと実務判断を同時に行わせる場合は、モデルの指示追従性と推論の安定性が土台になります。

9.実装で詰まった5つのこと

9-1. 知識をプロンプトへ全部入れると、重要な指示が埋もれる

最初は、マスターデータと判断原則の全文（合計約34KB）をシステムプロンプトへ入れていました。

情報量は増えましたが、回答は良くなりませんでした。

「質問は一度に一つ」といった重要な指示が大量の知識に埋もれ、守られにくくなっていました。

そこで、常に必要な判断だけを約9KBのダイジェストへ圧縮しました。結果として詳しい情報は必要な場面で参照する構成に変えたところ、指示が通りやすくなりました。

コンテキスト上限に収まることと、モデルがすべての情報を同じ精度で使えることは別です。「入るから入れる」のではなく、「今の判断に必要か」で選ぶ必要があります。

9-2. 見積の計算をLLMへ任せると、明細と合計が合わない

LLMに見積書を作らせると、各明細の金額は自然でも、小計や合計が一致しないことがありました。

そこで、LLMには必要な機能と明細行を出させ、小計、消費税、合計はアプリ側で明細から再計算する設計にしました。LLMが合計を書いても、その値は信用せず、コード側の計算結果を採用します。

さらに本番運用を考えるなら、LLMには金額そのものではなくマスタデータの機能IDと数量を返させ、単価の取得と計算をすべてサーバー側で行う方が安全です。

9-3. 「一問ずつ聞く」は、プロンプトだけでは守られない

システムプロンプトに「質問は一度に一つ」と書いても、モデルは複数の質問を並べることがあります。

そこで、サーバー側で回答を解析し、質問が複数含まれている場合は最初の一問だけを表示する処理を加えました。

AIへ指示するだけでなく、守らなければユーザー体験が崩れる制約はコードでも担保するなど出力を制御する知識が求められます。

9-4. モデルが持つ技術知識は更新されない

「画像診断はどう実装するべきか」と質問したところ、古い前提に基づき、現在の主要なマルチモーダルAIを考慮しない提案が返ってきました。

モデルが持つ知識は学習時点で止まっています。AI、クラウド、OS、ストア審査、ライブラリなど、変化が速い情報をモデルの記憶だけに頼るのは大変危険だと思いました。

そこで、最新の技術情報は更新可能な技術メモとして分離し、必要なときに参照させる構成にしました。変化する事実は覚えさせず、外から更新できるようにする方が運用しやすくなります。

9-5. 正しそうな文章と、正しい判断は別である

回答が自然だと、それだけで正しいように見えます。しかし、上流工程では質問の抜け、不要な機能の追加、技術選定の偏り、見積の漏れが実害につながります。

そのため、試作を評価するときは文章の自然さだけでなく、実案件をもとにした確認項目を用意する必要があります。

• 必須の質問を漏らしていないか

• すでに回答されたことを再度聞いていないか

• 顧客の了承なく仕様を追加していないか

• MVPと将来機能を分けられているか

• AIが不要な部分にAIを提案していないか

• 見積明細と合計が一致しているか

自分専用AIを改善するには、「良い回答」の例だけでなく、「してはいけない判断」も評価項目へ入れることが重要です。

10.RAGとファインチューニングのどちらを使うべきか

自分専用AIを作るとき、最初からファインチューニングが必要とは限りません。

今回の試作では、まずRAG、短くした判断原則、決定論的なコードを組み合わせました。

ファインチューニングは有力な手段ですが、元データに含まれる判断が整理されていない状態で学習しても、何を再現したいのかが曖昧なままです。先に評価項目と判断原則を作り、それでもプロンプトやRAGだけでは振る舞いが安定しない場合に検討する方が進めやすいと考えています。

ファインチューニングの基本的な仕組みは、こちらの記事でも解説しています。

関連記事：ファインチューニングとは？仕組み・LoRA・自社データ活用までわかりやすく解説

11.自分専用AIを作るなら、最初は小さな用途に絞る

今回の試作から、自分AIを作る場合は次の順番が現実的だと考えています。

11-1. AIへ任せたい一つの仕事を決める

「自分の代わりになるAI」では範囲が広すぎます。営業相談の初回ヒアリング、社内FAQ、見積の下書き、議事録からのタスク抽出など、一つの仕事へ絞ります。

12-2. 実際の良い事例を集める

過去の文章を量だけで集めるのではなく、その仕事で実際にうまくいった会話、資料、判断を集めます。

12-3. 知識、判断、計算、制約を分ける

更新する知識はRAG、常に使う短い原則はプロンプト、必ず守る処理はコードというように役割を分けます。

12-4. まず触れるUIを作る

精度評価は、モデル単体ではなく実際の利用画面で行います。

要件定義を相談する体験高さも制作時の目標に入っていたため実際に使って評価を行いました。

12-5. 20件程度の評価シナリオを作る

通常の相談だけでなく、情報不足、矛盾した要望、予算不足、対象外の質問なども含めます。同じシナリオをモデルやプロンプトの変更前後で実行すると、改善したのかを比較できます。

12-6. 最後に自動化の範囲を広げる

最初から最終判断まで任せず、下書き、候補提示、人による確認という順番で始めます。誤りの影響が小さいところから自動化する方が、実務へ導入しやすくなります。

13.ローカルLLMはディスク容量も使う

開発途中、複数のモデルをダウンロードして比較していたところ、内蔵SSDの使用率が99%まで上がり、コマンドの出力すら書けなくなりました。

ローカルLLMでは、モデルごとに数GB以上の容量を使うことがあります。
複数モデルを比較する場合は、メモリだけでなくストレージの残量とモデルの管理方法も先に確認しておく必要があります。

14.まとめ｜自分AIは、資料を入れるだけでは作れない

今回作った「畑井駿佑AI」は、note225本と見積40件超を読み込ませただけのチャットボットではありません。

• 判断のやり方を先に言語化する

• 大量の知識は必要なときだけ参照する

• 常に必要な指示は短く保つ

• 計算と必須制約はコードで担保する

• 変化の速い情報は外から更新できるようにする

• 実案件に近いシナリオで判断を評価する

この役割分担を作ることで、初めて実務に近い支援AIになりました。

AI開発というと、モデル選定やファインチューニングが注目されますが、実際に多くの時間を使ったのは、どの判断を再現するのか、どの情報を渡さないのか、どこをAIに任せないのかを決める設計の部分でした。

micomiaでは、自社の資料や専門知識を活用したAI、RAG、ファインチューニング、ローカルLLMを使ったPoCについて、要件整理から設計・開発まで対応しています。「自社の知識をAIで活用したいが、何から始めるべきか分からない」という段階からでもご相談ください。