前回の EP.14 では、手元の Mac で を動かす方法をまとめました。今回はその先、「で、何をさせるのか」です。アイアンマンのジャービスのような、常にそこにいて暮らしを支えてくれる相手。あの絵を現実の部品に分解すると、どこまでが今日組めて、どこからがまだ届かないのかがはっきりします。
執筆時点（2026 年 9 月）の情報です。モデルの世代交代は数ヶ月単位で起きるので、バージョン番号よりも「選び方」の方を持ち帰ってください。gpt-oss の仕様は 公式モデルカード を出典としています。
1. ジャービスを 4 つに分解する
「ジャービスが欲しい」を実装可能な単位に割ると、次の 4 つになります。この 4 つは難易度がまったく違うというのが出発点です。
| 要素 | 中身 | いまの状況 |
|---|---|---|
| ① 常にいる | 常時起動していて、呼べばすぐ応じる | 組める。常時起動サーバと で成立する |
| ② 自分を知っている | 予定・住所・家族構成・過去のやりとりを踏まえる | 組める。ただし記憶の設計が要る |
| ③ 行動する | 調べるだけでなく、家電を操作し予定を入れる | 組める。 で外に手を伸ばす |
| ④ 先回りする | 言われる前に気づいて、適切な時に割り込む | ここが本丸。部分的にしかできない |
映画のジャービスが魅力的なのは、ほぼ全部が ④ だからです。呼ばれてから答えるのではなく、状況を見て先に口を開く。逆に言えば、①〜③ はもう手元の機材で組めるということでもあります。まず ①〜③ で「使える道具」を作り、④ は小さく限定して足していく。これが現実的な順序です。
2. いま手元で動くモデル ── gpt-oss を中心に
エージェントの「脳」にあたる部分です。2025 年 8 月に OpenAI が をオープンウェイトで公開したことで、ローカル運用の選択肢が一段変わりました。Apache 2.0 という素直なライセンスで、商用利用にも使えます。
| gpt-oss-20b | gpt-oss-120b | |
|---|---|---|
| 総パラメータ | 21B | 117B |
| 1トークンあたりの活性 | 3.6B（） | 5.1B（MoE） |
| 動作の目安 | 16GB のメモリに収まる | 80GB GPU 1 枚に収まる |
| ライセンス | Apache 2.0 | Apache 2.0 |
| 位置づけ | 手元・低遅延用途 | 本番・高推論用途 |
ジャービス用途で効いてくる特徴が 3 つあります。 を最初から想定して訓練されていること、推論の深さを 3 段階（low / medium / high）で切り替えられること、そして を丸ごと返すことです。1 つ目は「行動できる」ための必須条件。2 つ目は「雑談は速く、判断はじっくり」を 1 つのモデルで両立させられるという意味で、常時起動の相手として素直に効きます。
# 20b（メモリ 16GB 以上が目安）ollama pull gpt-oss:20bollama run gpt-oss:20b
# 推論の深さは system プロンプトで 3 段階に指定する# Reasoning: low 速い。呼びかけ・雑談・定型の応答# Reasoning: medium 既定# Reasoning: high じっくり。判断や見積もりを任せるときollama run gpt-oss:20b "Reasoning: high
この家計簿から、先月と比べて増えた費目を3つ挙げて理由の仮説も添えて"
# 大きい方。Mac なら大容量メモリ構成の Mac Studio クラス向けollama pull gpt-oss:120bgpt-oss 以外にも Qwen / Llama / Gemma / Mistral / DeepSeek といった有力なオープンウェイトのファミリーがあり、数ヶ月ごとに世代が入れ替わります。この記事で特定のバージョン番号を並べても、読む頃には古い。持ち帰るべきは順序です。①手持ちのメモリに載るサイズに絞る → ②ライセンスが用途に合うものだけ残す → ③自分の実データ 30 件で 2 つを比べて勝った方を採る。ベンチマークの順位表ではなく、自分の仕事で判断してください。
3. 具体例カタログ：暮らし
ここからが本題です。「賢いこと」ではなく「毎日発生して、面倒で、外に出したくないこと」に当てるのがコツです。派手さはないが、確実に効く例を挙げます。
| やること | 何が嬉しいか | 必要な部品 |
|---|---|---|
| 冷蔵庫の写真から献立 | 残り物の写真を撮ると、作れるものを提案。買い物の口実が減る | 画像入力 + |
| 朝の 30 秒ブリーフィング | 天気・予定・ゴミの日・在庫切れを 1 段落で読み上げる | 定期実行 + |
| 家の状態を聞く / 操作する | 「寝室暑い？」で温度を答え、必要なら冷房を入れる | + |
| 紙の書類の仕分け | 学校のプリント・保険・行政の封筒を撮ると要点と締切を抽出 | 画像入力 + 抽出プロンプト |
| 子どもの宿題の相棒 | 答えではなくヒントを出す役。会話ログを外に出さずに済む | LLM + 役割プロンプト |
| 離れて暮らす親の見守り | 生活リズムの逸脱だけを通知。映像は外に出さない | センサー + 定期判定 |
この一覧に共通するのは、どれも「外に出したくない情報」を扱っていることです。家の中の温度、子どもの学習内容、親の生活パターン、家計。クラウドに投げても動きはしますが、投げなくて済むなら投げない方がいい類の情報ばかりです。ローカル LLM の価値が最も素直に出るのがこの領域です。
4. 具体例カタログ：仕事
業務側は「件数が多くて単純」に寄せると効きます。難しい判断はクラウドに残す、という EP.14 の分担がそのまま当てはまります。
| やること | 何が嬉しいか | 備考 |
|---|---|---|
| 会議録の要約と宿題抽出 | 録音をその場で文字起こしし、決定事項と担当を並べる | もローカルで完結できる |
| 受領書類の分類とリネーム | 請求書・見積・契約を判別して命名規則どおりに保存 | 件数が出るほど効く |
| 問い合わせの一次仕分け | 緊急度と担当部署を推定して振り分ける | 最終判断は人が持つ |
| 社内文書の検索窓口 | 「経費精算の締切は？」に社内規程を根拠付きで答える | と の設計が要る |
| コードレビューの下読み | PR に対して観点の抜けを指摘。人のレビュー前の掃除役 | 指摘の採否は人が決める |
| ログからの異常抽出 | 大量ログを夜通し読ませて、翌朝に候補だけ受け取る | 従量課金だと高くつく典型 |
「毎週発生していて」「1 回あたり 10 分以内で」「間違えても取り返しがつく」。この 3 つを満たす仕事から始めてください。逆に、月 1 回しか起きない仕事や、間違えると顧客に影響する仕事を最初の題材にすると、評価もできないまま体感だけで判断することになり、たいてい頓挫します。
5. 実例を深掘り：食材の在庫を人手ゼロで回す
暮らしの例のなかで、設計の面白さと難しさが両方詰まっているのが食材まわりです。「買った → 在庫 → 献立 → 作った → 減った → 足りない → 買う」という輪を、どこまで人間の操作なしで回せるか。1 つの設計例として掘り下げます。
まず輪の形を見ます。一周すると自分に戻る構造なので、どこか 1 箇所でも人手を必要とすると、そこで輪が止まります。止まる場所を先に特定するのが設計の勘所です。
- ① 入荷: ネットスーパーの注文確定メール / レシート撮影から、品目と数量を取り込む
- ② 在庫: 在庫表に加算し、賞味期限の推定を添える
- ③ 提案: 在庫と期限から献立を出す。期限が近いものを使い切る向きに寄せる
- ④ 記録: 実際に作ったものを記録する（ここが最大の難所）
- ⑤ 消費推定: レシピの標準分量から、減った量を差し引く
- ⑥ 補充: 定番品が閾値を割ったら買い物リストへ積む → ① に戻る
| ステップ | 人間の操作 | 実現手段 | 誤差の出方 |
|---|---|---|---|
| ① 入荷（ネットスーパー） | ゼロ | 注文確定メールを定期的に読んで品目を抽出 | 小。表記ゆれのみ |
| ① 入荷（実店舗） | 撮る 1 回 | レシートを して品目化 | 中。商品名が略記される |
| ② 在庫更新 | ゼロ | ① の結果を加算 | 小 |
| ③ 献立提案 | ゼロ（見るだけ） | 在庫と期限を渡して提案させる | — |
| ④ 調理記録 | 一言だけ | 提案した献立に「作った / 作らなかった」を返す | 大。記録し忘れが出る |
| ⑤ 消費推定 | ゼロ | レシピの分量 × 人数で減算 | 大。誤差の主犯 |
| ⑥ 補充提案 | 承認 1 回 | 閾値割れを買い物リストへ | 小 |
この輪で最大の落とし穴は、在庫数を正確に保とうとすることです。⑤ の消費推定は必ずズレます。醤油を何 ml 使ったかは誰も測らないし、作らなかった日・外食した日・人にあげた日が抜ける。誤差は一方向に累積し、数週間で信用できない数字になります。正確さを目指すと結局その差を人間が埋めることになり、輪が止まります。
そこで目的を置き換えます。「在庫を正確に知る」ではなく、「期限が近いものを使い切らせる」。こう定義し直すと、多少の誤差は許容できます。キャベツが 800g なのか 600g なのかは献立の質を変えませんが、「あと 2 日で切れる」は変えます。数量は曖昧でよく、期限にだけ精度を持たせる。これが実務的な落としどころです。
from datetime import date, timedelta
# 在庫は「正確な数量」ではなく「だいたいの量 + 期限」で持つPANTRY = [ {"name": "鶏もも肉", "qty_g": 500, "expires": date(2026, 9, 3)}, {"name": "キャベツ", "qty_g": 800, "expires": date(2026, 9, 8)}, {"name": "卵", "qty_g": 360, "expires": date(2026, 9, 14)},]
def urgent(pantry, within_days=3): """期限が近い順に、使い切ってほしいものを返す""" limit = date.today() + timedelta(days=within_days) return sorted( (i for i in pantry if i["expires"] <= limit), key=lambda i: i["expires"], )
def consume(pantry, used_g): """レシピの標準分量で減らす。推定値なので下限は 0 で止める""" for item in pantry: if item["name"] in used_g: item["qty_g"] = max(0, item["qty_g"] - used_g[item["name"]]) return pantry
# 提案時は「期限が近いもの」だけを渡せば、献立は自然にそちらへ寄るhint = "、".join(f"{i['name']}(~{i['expires']})" for i in urgent(PANTRY))print(f"優先して使い切る: {hint}")
# 「作った」と返ってきたら、レシピの分量で差し引く（あくまで推定）consume(PANTRY, {"鶏もも肉": 300, "キャベツ": 200})人間の操作を減らす技は 3 つです。どれも「頑張って記録する」の逆を行きます。
- 入口をメールに寄せる: ネットスーパーの注文確定メールは、品目・数量・日付が揃った実質的な構造化データです。買い物のたびに人間が何もしなくていい入口はここしかない。実店舗のレシートは撮る操作が要るので、日常の主戦場はネットスーパー側に置く
- 記録を「入力」ではなく「確認」に変える: 人間に献立を記録させようとすると続きません。提案した側から「これ作った？」と聞く形にすれば、返すのは一言で済む。入力欄を作らないのが肝心
- 定期的に棚卸しでリセットする: 誤差の累積は原理的に消せないので、月に 1 回だけ冷蔵庫を見て在庫表を上書きする。誤差を減らす努力より、リセットする運用を用意する方が安上がりです
⑥ の補充は、切らすと困る定番（米・卵・調味料・常備菜の材料）だけを閾値監視するのが実用的です。全品目を追って買い物リストを作らせると、精度の低い推定に基づく提案が大量に出て、結局すべて人間が検算することになります。監視対象を 10〜20 品目に絞ると、提案が信用できる水準に収まります。
この輪が回り始めると、「今日何作る」を考える回数が目に見えて減ります。派手な機能ではありませんが、毎日発生して、面倒で、外に出したくない情報（家族の食事の記録と購買履歴）を扱うという意味で、ローカル LLM の価値がそのまま出る題材です。
6. 最小構成の組み方
ジャービス的なものを組むときの部品は、結局この 4 つに落ち着きます。それぞれ差し替え可能な独立部品として組むのが後々効きます。
- 耳: 検知 + 。 系をローカルで動かせば音声は外に出ない
- 脳: gpt-oss などのローカル LLM。推論の深さを用途で切り替える
- 記憶: 短期は会話履歴、長期はファイルか検索可能な索引。全部を に詰めない
- 手: か 経由で、家電・カレンダー・ファイルへ手を伸ばす
- 口: 。ここの が体感を最も左右する
記憶の設計だけは最初に決めておくことをおすすめします。会話履歴を延々と積むと を食い潰して破綻するので、「毎回渡す短い事実（家族構成・住所・好み）」と「必要なときだけ引く長期記憶」を分けます。前者はただのテキストファイルで十分です。
7. 最小実装：家の状態を見て答えさせる
「行動する」の核心は です。ここで大事なのは、モデルは「この関数を呼びたい」と言うだけで、実際に実行するのはこちら側だということ。この境界が、後述する権限管理の掛けどころになります。
import json
from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
TOOLS = [ { "type": "function", "function": { "name": "get_home_state", "description": "指定した部屋の温度・湿度・在室状況を返す", "parameters": { "type": "object", "properties": { "room": {"type": "string", "description": "部屋名（例: 寝室）"}, }, "required": ["room"], }, }, }]
def get_home_state(room: str) -> dict: # 実際は Home Assistant の REST API を叩く。ここでは読み取り専用に限定している return {"room": room, "temp_c": 28.4, "humidity": 61, "occupied": False}
messages = [{"role": "user", "content": "寝室、寝る前に冷やしておいたほうがいい？"}]
resp = client.chat.completions.create( model="gpt-oss:20b", messages=messages, tools=TOOLS)msg = resp.choices[0].message
if msg.tool_calls: messages.append(msg) for call in msg.tool_calls: args = json.loads(call.function.arguments) # ここが権限の境界。許可した関数以外は絶対に呼ばせない result = get_home_state(**args) messages.append( { "role": "tool", "tool_call_id": call.id, "content": json.dumps(result, ensure_ascii=False), } ) resp = client.chat.completions.create( model="gpt-oss:20b", messages=messages, tools=TOOLS )
print(resp.choices[0].message.content)「④ 先回りする」への最初の一歩は、実は定期実行です。話しかけられるのを待つのをやめて、決まった時刻に自分から状況を見に行く。それだけで体感は大きく変わります。
# crontab -e# 毎朝 6:30 に、天気・予定・在庫を見て「1段落だけ」書かせて読み上げる30 6 * * * /usr/local/bin/morning-brief.sh >> ~/jarvis/brief.log 2>&1
# morning-brief.sh の骨格#!/usr/bin/env bashset -euo pipefail
CONTEXT="$(fetch-weather.sh; fetch-calendar.sh; fetch-pantry.sh)"
echo "$CONTEXT" | ollama run gpt-oss:20b "Reasoning: low
以下は今日の状況です。行動が変わる情報だけを1段落で。何もなければ「特にありません」とだけ返してください。" | say -v Kyoko先回り型のアシスタントで一番うるさいのは、毎回律儀に何か言ってくることです。プロンプトに「何もなければ黙る」を明示的に許可しておくと、通知の価値が保たれます。黙れないアシスタントは、2 週間で切られます。
8. まだ届かないこと
夢の話をした以上、届いていない部分も正直に書きます。ここを知らずに始めると、期待値の差で必ず失望します。
- 本当の意味での先回り: 「言われる前に気づく」は、いまのところ人間が条件を決めて仕込んだ範囲でしか起きない。状況の異常さを自分で定義することはできない
- 割り込みの間合い: 「いま言うべきか」の判断が苦手。有用な情報でも、タイミングを外すと邪魔にしかならない
- 長期の一貫性: 数ヶ月にわたる文脈を保ち続けるのは、記憶設計を作り込んでもまだ難しい
- 失敗の自覚: 間違えたことに自分で気づいて訂正する力は弱い。人が結果を見る前提を外せない
- 手元モデルの推論力: 込み入った判断はクラウドのフロンティアモデルに一段譲る。難所は投げる設計にしておく
つまり現時点で作れるのは、「よくできた執事」ではなく「気の利く道具」です。それでも、家の温度を聞けば答え、朝に要点だけ言い、書類を仕分けてくれる相手が外に何も送らずに手元にいるというのは、数年前には無かった状況です。
9. 落とし穴
- 権限を一括で渡す: 読み取りと書き込みを分け、鍵・給湯・決済など取り返しのつかない操作は最初から渡さない。エージェントの事故は「できてしまった」ことで起きる
- の経路を作る: メールや Web を読ませる構成にした瞬間、外部の文章がそのまま指示になり得る。読ませる情報と従わせる指示は経路を分ける
- をそのまま表示する: gpt-oss は思考過程を丸ごと返すが、利用者に見せる想定のものではない。表示するなら整形するか、最終的な回答だけを出す
- を無視して直接叩く: gpt-oss はこの形式で入出力しないと正しく動かない。 経由なら裏で処理されるが、自前実装なら要対応
- の遅延を後回しにする: 応答の質より、喋り出すまでの待ちの方が体感を殺す。先に測って部品を選ぶ
- 常時録音してしまう: 検知までは本格処理しない作りにする。家族の同意も設計のうち
- 評価なしで生活に入れる: 30 件でいいので同じ入力を人とモデルで比べる。合わないまま暮らしに入れると、不信だけが残る
10. ふくふくの進め方
「AI で何かしたいが、何から手をつけるか決まらない」というご相談には、まず業務の棚卸しから入っています。毎週発生していて、10 分以内で、間違えても取り返しがつく仕事を一緒に洗い出し、そこにローカルとクラウドのどちらを当てるかを切り分ける。機材の話はその後です。順番を逆にすると、たいてい high spec な置き物ができあがります。
11. ここまでのまとめ
- ジャービスは ①常にいる ②自分を知っている ③行動する ④先回りする に分解できる。①〜③ は今日組める
- gpt-oss-20b は 16GB のメモリで動く（Apache 2.0）。ツール呼び出し前提で訓練され、推論の深さを 3 段階で切替できる
- モデルはバージョンでなく選び方で持つ。載るサイズ → ライセンス → 自分の実データ 30 件で比較
- 題材は 「毎週発生・10分以内・間違えても平気」 から選ぶ
- 推定が絡む輪は「正確さ」を捨てる。食材在庫なら数量は曖昧でよく、期限にだけ精度を持たせる。記録は「入力」ではなく「確認」に変える
- 部品は 耳・脳・記憶・手・口。差し替え可能に組み、記憶設計だけ先に決める
- 先回りの第一歩は定期実行。ただし「何もなければ黙る」を許可しておく
- 権限は用途ごとに切る。取り返しのつかない操作は最初から渡さない
映画のジャービスにはまだ遠いとしても、「外に何も送らずに、毎日少しずつ楽になる」道具はもう手元で組めます。次回 EP.16 では、この記事で「選び方だけ持ち帰ってください」と書いた部分を正面から扱います。オープンウェイトモデルの系譜を年表で整理し、ファミリーごとの特徴・ライセンス・開発元の所在まで踏み込んだ選定ガイドです。その先は、Home Assistant と繋いで家を操作する構成、Whisper をローカルで動かす音声入力、長期記憶の持たせ方などを、読者リアクションに応じて随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。