§ 07 Blog
クラウドに出せない情報を、AIで扱いたかった話
はじめに
ChatGPT が登場してから3年。今や「AI を使う」ことは、特別なことではなくなりました。文章を要約させたり、メールを下書きさせたり、コードを書かせたり。多くの人が日常的に AI に頼るようになっています。
でも、ふと立ち止まって考えてみてください。
「その情報、本当にクラウドに送って大丈夫?」
例えば、職場で行われる1on1の記録。社員から寄せられた相談の内容。健康診断のフォローアップメモ。誰かが「最近眠れない」と漏らした言葉。
こうした情報は、誰のものでしょうか。送信した瞬間、それは外部のサーバーに保管されます。サービス提供者の利用規約で「学習には使いません」と書かれていても、保管されているという事実は変わりません。万が一のことを想像したとき、リスクをゼロにはできない。
私たちのチームでも、こうしたデータを扱う場面が増えました。AIに任せれば確実に楽になる業務がある一方で、「これは外には出せない」というブレーキも強く働きます。
そこで始めたのが、自分たちの手元で完結する AI、いわゆるローカル AI の導入でした。
この記事は、その試行錯誤の記録です。技術的な詳細は省きつつ、何を考え、どう判断し、どこでつまずいたかを、できるだけ正直に書きます。同じ悩みを持つ方の参考になれば嬉しいです。
なぜ「ローカル」なのか
最初に、なぜわざわざ手間をかけてローカルで AI を動かそうとしたのか、その理由を整理します。
1. 個人情報・機密情報をクラウドに送りたくない
これが最大の理由です。相談記録には個人を特定できる情報や、ときに生命に関わる兆候も含まれます。こうしたデータを社外のサーバーに送ることは、いくら便利でも避けるべきだと判断しました。
2. 通信トラブルやサービス停止に左右されたくない
クラウドサービスは、提供側の都合で止まることがあります。実際、過去にも大規模な障害で半日業務が止まった経験があります。「使いたいときに使えない」リスクを下げたい。
3. 利用ルールが変わるリスクから守る
外部サービスの料金体系や利用規約は、ある日突然変更されることがあります。業務に深く組み込んだ後で「無料枠が縮小されました」「機能制限されました」となると、現場が困ります。ローカルなら、自分たちでコントロールできます。
4. データの所有権が明確になる
社内サーバーで処理すれば、データは社内に留まります。「うちのデータはうちのもの」という当たり前のことを、当たり前にできる。これは想像以上に大きいメリットです。
最初の構想 ―「各人のPCにAIを入れる」発想
ローカルAIを実現する最初の発想は、シンプルでした。
「みんなのパソコンに AI のソフトを入れて、それぞれが手元で使えばいい」
「個人で使う ChatGPT」のような感覚で、各自のパソコンの中に AI が常駐し、ネットに繋がなくても動く。理想的な絵に見えました。
ところが、調べていくと現実が見えてきます。
AI モデルは小さくない
賢い AI ほどファイルサイズが大きく、メモリも食います。一般的な業務用ノートPCで動かせるのは、それなりに軽量化された AI に限られます。性能を取るか、軽さを取るか。トレードオフが避けられません。
「自分で AI を作る」のは現実的でない
ニュースなどで「○○社が独自の AI を開発」と聞くと、自分たちも作れそうな気がしますが、これは大企業がスーパーコンピューターで数ヶ月かけてやっと作れるレベルの作業。個人や小規模チームでゼロから作るのは不可能でした。
幸いなことに、世の中には**「無料で使ってください」と公開されている AI モデル**が多数あります。Meta が公開している Llama、Alibaba の Qwen、Google の Gemma、日本語に強い Sarashina など。これらを利用するのが現実的な道です。
「作る」ではなく「使う」が正解だと、ここで方針が定まりました。
突きつけられた現実 ― 業務端末の制限
軽量モデルと相性のいいツールを使えば、業務用ノートPCでも何とか動かせそうだ。そう思って準備を進めていたとき、根本的な問題に気づきます。
そもそも、業務用のパソコンに勝手にソフトをインストールできない。
多くの組織では、情報セキュリティの観点から、社員が独自にアプリを入れることを制限しています。これは情報漏洩対策として正しい運用です。でも、「便利な AI を使いたい」という個人の希望と、「未承認のソフトは入れない」という組織のルールが、ここで衝突します。
つまり、自分のパソコンで動くものを作っても、それを他の人に配ることができない。配れないなら、個人ツールにしかなりません。
ここで、最初の発想を捨てる必要がありました。
発想の転換 ― 「1台のサーバーで、みんなが使う」
そこで思いついたのが、サーバー型の構成です。
これまでの発想は「みんなのパソコンに AI を入れる」でしたが、新しい発想は逆。
「社内のサーバーに AI を1つ置いて、みんながブラウザでアクセスする」
この方式なら、
- 各人のパソコンには何もインストールしなくていい
- ブラウザを開いて URL にアクセスするだけ
- 情報セキュリティ部門の承認は「サーバー1台分」だけで済む
- アップデートも1か所だけで完結
- データは社内ネットワーク内で完結し、外に出ない
要するに、社内向けの「専用 ChatGPT」を自分たちで運用するイメージです。これなら制約をクリアしつつ、AI の便利さを享受できる。
しかも、サーバーは PC よりずっと高性能なので、より賢い AI モデルを動かせます。「各人の PC に合わせて性能を妥協する」必要がなくなるのは、想像以上に大きなメリットでした。
既にあった味方 ― オープンソースの活用
方針が決まれば、あとは実装です。ここで、思わぬ発見がありました。
調べていくうちに、社内サーバーで AI アプリを構築するためのオープンソースツールが既に存在することを知りました。それも、かなり完成度の高いものが。
このツールを使えば、
- 複数の AI モデルを切り替えて使える
- ファイル(Excel、PDF、Word)を読み込ませて処理できる
- 会話形式のチャットアプリも、定型処理のワークフローも作れる
- ブラウザベースの UI も最初から用意されている
ゼロから作るより、こうした基盤を活用する方が圧倒的に速い。「車輪の再発明をしない」というやつです。
実は、このツールは半年以上前に別の検証目的でインストールしてあり、長く眠っていました。今回の用途にこれほどぴったり合うとは、当時は思っていませんでした。過去の試行錯誤が、思わぬ形で活きることもあるんですね。
試行錯誤と、現実のトラブル
セットアップは順調に進み、複数のモデルを試せる環境が整いました。
日本語の機微を捉えるのが得意なモデル 表形式データの解釈が得意なモデル 汎用的にバランスがいいモデル 軽量で動作が速いモデル
同じ質問を投げて出力を比べると、それぞれ個性があります。用途に応じて使い分けられるのは、ローカル運用ならではの自由度です。
ダミーデータ(架空の相談記録)で動作確認も済み、「これは業務で使える」という手応えを得ました。
ところが、構成を整理し直したタイミングで、トラブルが発生します。
作り込んだ設定が、すべて消えてしまった。
バージョンアップに伴う互換性の問題で、データベースの状態が崩れたのです。半日かけて積み上げたものが、一瞬で霧散しました。
落ち込みかけましたが、冷静に考えると、まだ本格運用前の検証段階。失ったのは「設定」であって、「学び」ではない。再構築には30分もかからない。だったら、サクッとやり直す方が早い。
**この経験から得た最大の教訓は、「定期バックアップは絶対に必要」**ということ。本番運用の前にこのトラブルに遭えてよかった、と今では思っています。
次のフェーズ ― 自分たち向けにカスタマイズ
ベースの環境が動くようになったら、次は「自分たちのもの」として愛着が湧くように整える段階です。
- 自社のロゴをヘッダーに追加
- 自社のブランドカラーを反映
- 不要な機能を非表示にして、業務に必要なものだけが見える状態に
- 業務に合わせたチャットボットや、定型処理のワークフローを構築
ここで活躍するのが、AI 自身を使った開発支援ツール。コードを書く作業を AI と対話しながら進められるので、本職のエンジニアではない自分でも、ある程度のカスタマイズが手の届く範囲に入ってきます。
「AI を使うアプリを、AI に手伝ってもらいながら作る」という、ちょっと不思議な構図ですが、これが今の開発の現実です。
ローカル AI の「現実」
ここまで読んで、「結局、ChatGPT みたいな性能は出るの?」と気になっている方もいると思います。
正直に書きます。
最新の ChatGPT(GPT-5)や Claude のような最先端の品質は出ません。
私たちが扱っているのは、無料で公開されているモデルなので、商用最先端と肩を並べることはできません。これは事実です。
ただし、
「2年前の ChatGPT」級の品質は普通に出ます。
業務における 8〜9割の用途は、これで十分カバーできます。要約、抽出、分類、下書き作成、表データの解釈、コード支援。こうしたタスクで「もう一段の賢さが欲しい」と感じる場面は、思ったより少ないのです。
しかも、それを 無料・無制限・外部送信なし で使える。この組み合わせは、業務の現場では非常に強力です。
「最先端じゃない」を「実用には十分」と読み替えられるかどうか。それが、ローカル AI を選ぶか選ばないかの分かれ目だと思います。
この経験から学んだこと
今回のプロジェクトを通じて、いくつかの大切な気づきがありました。
1. 制約は、ときに良い設計の起点になる
「業務端末にインストールできない」という制約に直面したからこそ、サーバー型という発想にたどり着きました。制約があるおかげで、より筋のいい構造が見つかることがあります。
2. 「個人で使えるか」と「組織で使えるか」は別問題
一人で完結する話なら何でもできますが、それを他の人にも使ってもらおうとした瞬間、考えるべきことが一気に増えます。配布、運用、セキュリティ、保守。最初から「組織のもの」として設計するのが、結局は近道です。
3. 完璧を目指さない
「もっといいモデルが出るかも」「もっといい方法があるかも」と検討を続けると、永遠に動き出せません。まず動かす。動かしてから直す。 これがすべてだと、毎度のことながら痛感します。
4. AI は道具、判断するのは人間
特に機密性の高い情報を扱う場面では、AI の出力をそのまま信じて行動するのは危険です。AI は補助、人間が最終判断する。この役割分担を崩さない設計こそ、現場で使える AI を作るカギだと思います。
おわりに
「クラウドに出せない情報を、AI で扱いたい」
最初の素朴な願いから始まったこの取り組みは、想像以上に多くの判断と試行錯誤を伴いました。それでも、ようやく**「自分たちの手元で、自分たちのデータを、AI で活用する」**という形が見えてきました。
ローカル AI は、最先端ではないかもしれません。万能でもありません。でも、**「外に出せない情報があっても、AI の恩恵を諦めなくていい」**という選択肢を、現場に届けられる。これは、決して小さなことではないと思っています。
同じような悩みを持っている方、まずは小さく始めてみてください。完璧な計画より、不格好でも動くものから始めた方が、必ず景色が変わります。