最近、ローカルAIをただの「チャット相手」ではなく、実際に仕事をする一般職員のように使えないかを試しています。
きっかけは、高性能PCについて考えていたことでした。
せっかく高いPCを買うなら、ゲームや動画生成だけに使うのではなく、寝ている間や別の作業をしている間にもAIが働く「生産設備」にできないか。
そこで始めたのが、僕の中で勝手に呼んでいる**「N猫AI会社」構想**です。
今回はその最初の実験として、
ローカルAIに大量の事業アイデアを考えさせ、そのアイデアをさらにローカルAI自身に監査させる
ところまでやってみました。
結果から書くと、
- 約1200個のアイデアを生成
- 有効データ1196件を監査
- B候補462件まで絞り込み
- 人間が1200案を全部読む作業は回避
というところまで進みました。
ただし、最初からうまくいったわけではありません。
むしろ今回かなり面白かったのは、AIに仕事を任せる時にどこで事故が起きるのかが見えてきたことでした。
今回使った環境
今回の実験では、クラウドのAI APIではなくローカル環境を使っています。
主な構成は以下です。
- GPU：RTX 3080
- Ollama
- ローカルLLM：Qwen3:8b
- Python
- Windows環境
基本的には、PCの中だけで大量処理を行います。
僕の中では役割を、
- ローカルAI：一般職員
- Python：集計・検品・処理ライン
- GPT：設計や判断をする参謀
- 僕：最終判断をする人
というイメージで分けています。
重要なのは、何でも高性能なAIに直接やらせるのではなく、大量の手数仕事はローカル側へ移すことです。
まず30分、AIにアイデアを出し続けてもらった
最初に試したのはシンプルです。
Qwen3:8bに事業・サービス・コンテンツなどのアイデアを大量生成してもらいました。
短時間のPoCでしたが、最終的には約1200案まで生成。
ここだけ見ると、
「ローカルAIすごい。放っておけばアイデアが無限に増えるじゃん」
となります。
ところが、すぐ問題が発覚しました。
「1200件生成した」と表示されても、本当に1200件あるとは限らない
最初の実装では、
「AIに10件要求したから10件成功」
のような扱いをしていました。
しかし実際のLLM出力では、
- 途中で文章が切れる
- 必須項目がない
- JSON構造が壊れる
- 指定した件数より少ない
といったことが普通に起きます。
つまり、
要求した件数と、正常なデータとして保存できた件数は別
です。
これは当たり前と言えば当たり前なのですが、大量自動処理になるとかなり重要でした。
そこで、
- 構造チェック
- 必須項目チェック
- retry
- failedデータの隔離
を追加。
「AIが何か返したら成功」ではなく、プログラム側の検品を通過して初めて成功という仕組みに変更しました。
この考え方は、その後の工程でもかなり重要になっています。
次は1200案をAI自身に監査させる
1200個アイデアがあっても、僕が全部読むなら自動生成した意味が半分なくなってしまいます。
そこで次に作ったのが、ローカルAIによる一次監査ラインです。
各アイデアをQwenに読ませ、複数の評価軸でチェックします。
ただ、ここでも最初から安定したわけではありませんでした。
監査器は何度も修正することになります。
失敗1：複雑なJSONを要求すると崩れる
最初は一度の呼び出しで複数案をまとめて評価させようとしました。
ところが、
- 1件しか返ってこない
- 配列構造が壊れる
- 必須項目が抜ける
などが発生。
そこで処理を単純化し、
1アイデア＝1回のAI呼び出し
へ変更しました。
速度だけを見ると遠回りに見えます。
しかし大量処理では、多少遅くても確実に再開できる仕組みの方が結果的に強いと感じています。
失敗2：AIに合計点まで計算させると矛盾する
監査では複数項目を採点しています。
ところがAIに、
- 各項目の点数
- 合計点
- 最終ランク
まで全部返させると、
「合計26点なのに判定B」
のような矛盾が発生しました。
そこで役割を変更。
AIには各評価項目の判断だけを担当させ、
- 合計点
- ランク判定
- 件数集計
などはPythonで計算することにしました。
これは今回かなり大きな学びでした。
AIが得意なことと、普通のプログラムが得意なことを分けた方がいい。
文章を読んで意味を判断する部分はAI。
足し算や条件分岐、件数管理はPython。
何でもAIにやらせる必要はありません。
失敗3：プロンプト内の例に採点が引っ張られる
採点用のJSON例として、各項目に「1点」を入れたサンプルを置いていた時期がありました。
すると実際の採点まで低得点側へ引っ張られる傾向が出ました。
LLMにとって、こちらが単なる形式例として書いた数字も、判断材料になってしまうことがあります。
そこで具体的な採点値を例から取り除きました。
さらに、
- 3点＝普通
- 4点＝明確な根拠が必要
- 5点＝例外的
というように評価基準も厳格化しました。
単にAIへ「厳しく評価して」と言うだけでは足りず、出力分布そのものを見る必要があることも分かりました。
成功率だけ見てもダメだった
監査プログラムがエラーなく100件処理できた。
一見すると成功です。
でも、もし100件全部が同じような点数なら、監査器としてはあまり役に立ちません。
そこで、
- A/B/C/Dの分布
- 平均点
- 最小値
- 最大値
なども確認するようにしました。
最終的な1196件では、
- A：0件
- B：462件
- C：733件
- REVIEW_FAILED：1件
となりました。
平均点は19.98点。
最低18点、最高23点です。
正直、この結果から分かるのは、ローカルAIだけで細かい順位を付けるところまではまだ難しいということでもあります。
18〜23点にかなり密集しました。
しかし今回はそれで十分です。
1200案を人間が全部読む前に、
少なくとも次に見るべき候補群を462件まで減らす
ことが目的だからです。
906件目で止まった
全1196件の本番監査中、別の問題も発生しました。
906件まで処理したところで停止。
原因はシンプルで、
1件失敗しただけで、バッチ全体が止まる設計
になっていたことでした。
1200件規模を処理するなら、これはかなり危険です。
例えば1190件まで正常に終わって、1191件目の1個がおかしいだけで全部止まる。
長時間自律稼働させたいAI工場としては使えません。
そこで、
- checkpoint
- resume
- 1件失敗時の継続
- REVIEW_FAILEDへの隔離
を実装しました。
その結果、906件までの処理結果を再利用し、最終的に1196件まで完走。
失敗した1件だけを別枠へ隔離できました。
大量AI処理で重要だったのは「賢さ」より「工場設計」
今回やってみて、かなり印象が変わりました。
最初は、
「もっと賢いAIを使えば全部うまくいくのでは？」
と思いがちです。
でも実際には、モデルの賢さだけでは大量処理は安定しません。
重要だったのは、
- 出力を検品する
- 壊れたデータを成功扱いしない
- retryする
- 失敗データだけ隔離する
- checkpointを残す
- 中断しても再開できる
- 計算処理はPythonへ任せる
- 少数件で試してから本番へ進む
といった、かなり地味な仕組みでした。
人間の会社でも、優秀な社員が一人いるだけでは仕事は回りません。
手順、チェック、台帳、例外処理が必要です。
AIも同じなのかもしれません。
本番前に「2件→5件→100件→全件」で試す
今回かなり失敗したので、今後は大量処理をいきなり本番投入しないことにしました。
基本は、
- 2件
- 5件
- 50〜100件
- 全件
と段階的に増やします。
少量で、
- JSONが正常か
- 判定がおかしくないか
- retryできるか
- checkpointから復帰できるか
を確認。
それから本番へ進みます。
AIは高速ですが、間違った仕組みも高速で大量生産できます。
だからこそ、自動化するほど最初の小さな検証が重要だと思います。
現在は1200案から462候補まで絞り込んだ
今回の第一段階はここで終了。
最終的には、
約1200案を生成
↓
1196案を正常データとして監査
↓
B候補462案を抽出
というところまでローカル環境で処理できました。
もちろん462案でもまだ多いです。
次はこの462案について、
- 同じような案をまとめる
- 重複を潰す
- 類似アイデアをクラスタ化する
- 各クラスタの代表案を作る
という第二段階へ進みます。
ここでも、いきなり人間が462件を読むのではなく、まずローカルAIに「一般職員」として整理してもらう予定です。
最終的には「AIが働くPC」にしたい
今作りたいのは、単発のアイデア生成ツールではありません。
例えばPCを起動して処理を開始したら、
AIがアイデアを作る
↓
別工程が検品する
↓
AIが一次監査する
↓
Pythonが候補を整理する
↓
さらにAIが類似案をまとめる
↓
最後に人間へ有望案だけ提出する
という、小さなAI工場です。
僕自身が1200件読むのではなく、人間は最後の重要な判断だけする。
そこまで持っていけるなら、高性能PCは単なる趣味の機械ではなく「生産設備」として見られるようになります。
まだ実験途中ですが、今回だけでもかなり面白いところまで来ました。
次は462候補をどこまで自動で圧縮できるのか試してみます。
成功しても失敗しても、また記録していく予定です。