みんなのクラフト基地
子ども専用マイクラサーバーの公開サイトを見る
閉域AI
ローカルLLM
ログ解析
Minecraft
事例の概要
みんなのクラフト基地は、地域の子どもたちが安心して遊べるように設計された子ども専用のマイクラサーバーです。運営上の課題は、チャットログ、ブロック操作ログ、入退室ログを確認したい一方で、子どもの発言や行動履歴を外部クラウドAIへそのまま送れないことでした。
運営団体は、特定非営利活動法人デジタルこどもBASE（東京都認証NPO法人、法人番号 5010805003266、所在地 東京都大田区中央3-3-3）です。個人が運営する有志サーバーや海外の商用サーバーではなく、東京都認証のNPO法人が、子どもの安全な学び・遊びの場として責任を持って運用しています。
そこで、ログはサーバー側に保持したまま、閉域環境のローカルLLMで要確認の兆候を抽出する構成を採りました。暴言、個人情報のうっかり共有、なりすまし疑い、性的表現、荒らし行為などを機械的に拾い上げ、最終判断は大人スタッフがログと文脈を確認します。AIは処分を決める仕組みではなく、運営者が早く気づくための補助として使っています。
- 対象サービス
- みんなのクラフト基地（子ども専用マイクラサーバー）
- 運営団体
- 特定非営利活動法人デジタルこどもBASE（東京都認証NPO法人、法人番号 5010805003266）
- 課題
- 子どもの発言や行動ログを外部クラウドAIへ送らず、安全確認に活用すること
- 実施内容
- ログ保存、ログ前処理、定時処理、自然文解析を小さく分けた閉域AIの見守り運用
- 運用ポイント
- AIの判定で処分を自動化せず、要確認ログをスタッフ確認につなげること
導入前の課題 外部AIにログを貼れない
チャットログには、本名、学校名、住所、電話番号、SNS ID、家庭の事情など、本人が意図せず書いてしまう情報が混ざる可能性があります。子ども向けサービスでは、ログ確認を効率化したい場合でも、「便利だから」と外部クラウドAIに全文を貼り付ける運用は選びにくい状況でした。
学習利用されない設定を選んだとしても、外部送信、保存期間、管理者権限、契約、監査ログ、削除対応、国外移転などの説明責任は残ります。本件では、ログを外部クラウドAIへ送らず、閉じた環境で解析することを前提条件にしました。
外部クラウドAIにログを貼る場合
- チャット本文が外部サービスへ送信される
- 個人情報・プライバシー情報が混ざる可能性がある
- 利用規約、保存期間、管理者権限、監査対応を確認し続ける必要がある
- API利用量に応じて費用が変動する
閉域AI・ローカルLLMで読む場合
- サーバーログを外部クラウドAIへ送らない
- 処理場所とログ保管場所を自分たちで説明しやすい
- リアルタイム検知、日次集計、事後検索を同じログ基盤で組める
- 従量課金APIを使わず、予算化しやすい
導入後の運用 何を確認しているか
公開されている安全対策では、チャットログ、ブロック操作ログ、入退室ログを保存し、暴言、個人情報の共有、建築破壊、盗難などのトラブル時に事実確認できる体制を説明しています。閉域AIは、そのログから要確認の候補を整理し、運営者の確認作業につなげます。
チャットのリスク検知
暴言、煽り、差別的な発言、性的表現、個人情報のうっかり共有、外部SNSや個別DMへの誘導など、子ども同士の短い会話で見落としやすい兆候を拾います。
操作ログの確認補助
ブロック破壊、盗難、荒らし、なりすまし疑いなど、チャットだけでは判断できない行動ログと組み合わせて確認します。
復旧・保護者対応の材料化
トラブル時に「いつ、誰が、何をしたか」を確認し、必要に応じて建築物やワールドの復旧、保護者への連絡につなげます。
日次サマリーと運用改善
定時処理で前日分のログを整理し、要確認ログ、よくあるトラブル、ルール説明の不足箇所を確認しやすくします。人間の確認時間を安全運営に集中させるための運用です。
ログを起点に、確認の粒度を変えられる
閉域AIの利点は、AIモデルそのものだけではありません。サーバーにログが残っていれば、リアルタイム検知、数分ごとの集計、日次レポート、週次傾向分析、過去ログの再解析まで、運用に合わせて確認単位を変えられます。
外部SaaSの画面に合わせて仕事をするのではなく、既存サーバーのログを起点に、必要な形へ加工して確認する。ここが、閉域AIを「AIチャット画面」ではなく「業務インフラ」として見るポイントです。
1
リアルタイム検知
ログ追跡やイベント通知で、危険度の高い発言・行動を早めに拾う。
2
日次バッチ
定時処理とログ前処理で前日分を整形し、自然文解析で要確認ポイントを抽出する。
3
人間の確認
AIの判定だけで処分せず、スタッフがログと文脈を確認して対応を決める。
4
再分析・改善
ルール変更や検知条件の見直し後、過去ログを再解析して運用を改善する。
導入構成 すべてをLLMに任せない
このバックエンドは、巨大なAIアプリを一つ作る設計ではありません。ログ取得、ログ前処理、音声認識、自然文解析、通知、日次集計を小さく分け、それぞれを疎結合に組み合わせています。
LLMは自然文の判断や要約が得意ですが、ログの切り出し、ファイル移動、定時実行、形式変換のような処理までLLMに任せる必要はありません。定型処理、音声認識、意味判断の役割を分けることで、壊れにくく、差し替えやすく、低メンテナンスな構成になります。
構成の考え方
- ログはサーバー内で保存し、外部クラウドAIへ送信しない
- 定時処理、ログ前処理、通知処理を小さく分けて管理する
- 音声がある場合は文字起こししてから解析する
- 自然文解析は分類、要約、要確認ポイントの抽出に使う
- 最後の判断は人間が行い、AIは運用者の目を増やす役割にする
企業ログ活用にも展開できる条件
子ども向けマイクラサーバーという題材は特殊に見えます。しかし、構造は企業のログ活用にも近いものです。ログがあり、個人情報や機密情報が混ざる可能性があり、外部クラウドAIへ送れず、人間だけでは確認しきれない。こうした条件では、閉域AIの考え方を横展開できます。
| 業務データ |
外に出しにくい理由 |
閉域AIでできること |
| 社内チャット・ヘルプデスク履歴 |
顧客名、社員情報、未公開案件、認証情報が混ざる |
炎上兆候、情報漏洩リスク、FAQ化できる問い合わせを抽出 |
| 通話録音・商談録音 |
顧客の声、契約前情報、クレーム、個人情報が含まれる |
文字起こしした内容を、要約、分類、応対品質確認、検索に使う |
| 製造・設備ログ |
生産条件、品質データ、技術ノウハウが営業秘密に当たる |
異常傾向、点検メモ、過去トラブルとの類似性を分析 |
| 金融・医療・士業の文書 |
守秘義務、規制、監査、委託先管理の説明責任が重い |
閉域内で要約、検索、レビュー補助を行い、ログを監査証跡として残す |
費用面の見通しを立てやすい
ログ監視や音声解析は、利用量が読みづらい領域です。参加者が増える、チャットが増える、通話が増える、ログ保存期間が伸びる。従量課金APIに依存すると、使えば使うほど費用が読みにくくなります。
閉域AIは、サーバー、GPU、ストレージ、運用費を中心に考えられるため、予算化しやすい構造です。処理量が増えればハードウェア増強は必要ですが、トークン課金やAPI課金のように毎月の利用量で大きくぶれる設計を避けやすくなります。
