へつほつを始めます — Local AIを「動く」から「仕事になる」へ

ローカルAIについて調べると、モデルのパラメータ数、必要メモリ、生成速度といった情報は数多く見つかります。一方で、そのAIが実際の仕事を最後まで完了できるのか、途中でどれだけ人の修正が必要なのか、今の端末で十分なのかまで判断できる情報は、まだ多くありません。

へつほつは、ローカルAIを単に「動かす」ことではなく、「仕事になるか」を確かめるためのメディアです。成功した結果だけでなく、失敗、再試行、人の介入、時間、メモリ、電力、費用まで記録し、試す・使い続ける・機材を選ぶための判断材料へ変えていきます。

一つの万能AIではなく、小さな能力が協調する

へつほつには、継続して検証したい一つの仮説があります。

文章整理、検索、分類、コード修正、端末操作など、特定の仕事に適した小さなAI能力が一つの端末内で協調する。端末内のオーケストレーターが仕事を分解して適切な能力へ振り分け、ローカルだけでは品質や処理能力が足りない場合に、高性能なクラウドAIへ処理を委ねる。そのようなローカルとクラウドの協調型構成が、今後広がるのではないかという仮説です。

本稿では、この狭い役割に最適化された端末内AI能力を、便宜上「マイクロローカルAI」と呼びます。これは一般に確立した用語ではなく、独立した小型モデルだけを意味するものでもありません。共通の基盤モデルへ読み込む用途別アダプター、特定の機能を呼び出すモデル、従来型のプログラムやツール、専門サブエージェントも含めて考えます。

この構成で大切なのは、「どのモデルが一番賢いか」だけではありません。

• どの仕事をローカルへ任せられるか
• 仕事をどの能力へ振り分けるか
• モデル、アダプター、ツールが文脈を失わず連携できるか
• 失敗を検知し、再試行またはクラウドへ安全に切り替えられるか
• プライバシー、待ち時間、電力、費用をどう両立するか
• 日常作業と複数のAI処理を、同じ端末で安定して維持できるか

これは未来の断定ではありません。へつほつが、実測によって支持または修正していく中核仮説です。

構成要素は、すでに現れ始めている

仮説全体が実現したとはいえませんが、その構成要素は公式発表や研究の中ですでに確認できます。

AppleのFoundation Models技術報告では、約30億パラメータのオンデバイスモデルと、Private Cloud Computeで動くサーバーモデルが説明されています。Appleは別の記事で、用途別のアダプターを必要に応じて読み込み、切り替える構成も公開しています。また、端末で扱えない要求に大きなモデルを使うPrivate Cloud Computeは、ローカルとクラウドを役割で分ける実例です。

Googleは、端末上の小型言語モデルでRAG、マルチモーダル処理、機能呼び出しを行う仕組みをGoogle AI Edgeで紹介しています。Microsoft Researchも、小型のオーケストレーターが計画を立て、ツールや専門サブエージェントへ仕事を委ねるMagenticLiteを公開しました。

要求ごとに強いモデルと弱いモデルを選び、品質と費用の両立を目指す考え方は、RouteLLMのようなルーティング研究でも扱われています。

これらは、へつほつの仮説を証明するものではありません。ただし、専門化、端末内のツール利用、オーケストレーション、ローカルとクラウドの振り分けが、今から検証する価値のある対象だとはいえます。

AIの答えより、確かめられる仕事を見る

AIがもっともらしい答えを出すことと、その答えを人が正しいと確認できることは同じではありません。新しい候補を見つける「発見」、なぜそうなるかを捉える「理解」、同じ条件で正しさを確かめる「検証」は、分けて考える必要があります。

そこでへつほつは、AIの自己評価や文章の自然さだけを成果にしません。コードならテストを通過したか、資料検索なら根拠箇所へ戻れるか、端末操作なら意図した状態になったかを確認します。完全な自動判定が難しい仕事では、人が確認した項目と、そのために使った時間を残します。

重要なのは「人を一切介さないこと」ではなく、任せられる範囲と、確認しなければならない境界が見えることです。詳しい評価の考え方は、Coding Agentを「仕事になるか」で測ると検証方法で公開しています。

最初に検証する三つの用途

1. ローカルCoding Agent

既存のリポジトリを読み、修正し、テストし、失敗から回復できるかを検証します。生成速度だけでなく、仕事の完了率、意図しない変更、人の修正時間を測ります。

2. Private Knowledge AI

個人文書や業務資料を外部へ送らず、検索、要約、分類、RAGに利用できるかを検証します。回答だけでなく、引用元へ戻れること、資料の更新、バックアップ、権限の境界も対象にします。

3. 常時稼働するローカルAIサーバー

複数の端末やエージェントから使えるローカルAIを、無理なく常時稼働させられるかを検証します。性能に加え、電力、騒音、ネットワーク、障害復旧、安全なリモート利用まで扱います。

へつほつが記録すること

検証では、少なくとも次の項目を残します。

• 仕事の完了条件と、成果物の確認方法
• 失敗理由、再試行回数、人が介入した回数と時間
• 完了までの総時間と、待ち時間
• ピークメモリ、ストレージ、電力などの運用条件
• モデル、ランタイム、ハードウェア、コンテキスト、バージョン
• ローカル、クラウド、併用時の完了タスク当たり総費用
• 実測値、公式仕様、推定値の区別

測定前に高価な構成を勧めることはしません。たとえばMacのメモリも、モデルを読み込める最小容量、普段のアプリと併用できる実用容量、将来の余裕を分けて考えます。詳しくはMacのメモリ選びをモデルサイズだけで決めないをご覧ください。

買わなくてよい条件も書く

へつほつはアフィリエイト収益で運営しますが、報酬額を評価や掲載順位の根拠にはしません。実測と推定を分け、使っていない商品をレビュー済みとは表現せず、成功例だけでなく失敗と限界も残します。

比較の結論には、合う人だけでなく、合わない人や買わなくてよい条件も書きます。短期的に商品を多く売ることより、読者が検証結果を信頼し、必要なときにへつほつへ戻れることの方が、長期的な運営にも重要だと考えるからです。広告との関係は広告掲載方針で確認できます。

最初の実測では、手元のMacを使い、ローカルCoding Agentが実際のリポジトリでどこまで仕事を完了できるかを測ります。その後、メモリとコンテキストの限界、ローカルとクラウドの総費用、ランタイムによる違いへ範囲を広げます。

ローカルAIの未来を断定するのではなく、変化するモデルとハードウェアを同じ条件で測り、何が端末内で可能になり、何をクラウドへ任せるべきかを記録する。それが、へつほつを始める目的です。