製品
Whitelabel Network ✅HAI Engine ✅Matchmaking ⚠️Social ✅Marketplace ⚠️Calendar ⚠️Campaigns ✅Wallet & Token 🔵Super App 🔵Community Credit 🔵
ソリューション
中小企業 & 小売コミュニティ & 協同組合エンタープライズ・マルチロケーション政府 & NGOAIビルダー
会社情報
私たちについて私たちとは私たちの歩み変更履歴Architectureブログ
エンタープライズ
サインインネットワークを作成 →
ホーム/ブログ
inclusion · multilingual · low-connectivity

デザインによる包摂：低速回線でも動く AI

多言語、マルチモーダル、低接続性のために設計——大都市の高速回線だけのためではない。包摂は設計上の制約であり、マーケティング文句ではない。

著者 Everythink Studio team2 分で読了

設計による包摂：低速接続でも動く AI

ほとんどの AI 製品は、大都市の高速回線上で構築されベンチマークされている。それはサンプリングの問題であり、ヴィジョン声明ではない――システムを設計する人々と、そのシステムに快適にアクセスできる人々は、同じ狭い接続性プロファイルを共有している。私たちは包摂を、アーキテクチャが満たさなければならない設計制約として扱い、ローンチ後に印刷するスローガンとしては扱わない。この投稿は、それが実践において何を意味するかを示す：デフォルトで多言語、デフォルトでマルチモーダル、そして接続が遅いまたは断続的なときにも動き続けるように構築されている。

これはまた、私たちが 7 つの locale で公開する最初のマーケティングブログ投稿である――英語、スペイン語、ポルトガル語、中国語、日本語、ドイツ語、フランス語。ブログそのものが証拠であり、主張ではない。✅ Production。

The Honest Architect ― ポイント

  • 包摂はアーキテクチャ上の制約である：メカニズム（small-model パス、text-first フォールバック、地理空間ルーティング）を名指し、その成熟度状態をラベル付けする。
  • 2026 年、MIT News は Devavrat Shah の、現実世界の意思決定に「限られた計算資源を使う」AI に関する仕事を報じた――システムを低速接続で動かすのと同じ制約である（MIT News, 2026）。
  • HAI 会話エンジンは 2016 年から本番稼働している；それが残りすべてがその上に構成される基盤である。
  • 多言語とマルチモーダルは後からボルトオンされた機能ではない。それらは、システムがアクセス可能であるために取らなければならない形そのものである。

なぜ包摂はマーケティングコピーではなくアーキテクチャに属するのか？

2026 年、MIT News は「Helping AI models to meet the real world」の中で、MIT の Devavrat Shah 教授のグループが「限られた計算資源を使った秒刻みの意思決定」を扱う方法を設計していると報じた(MIT News, 2026)。その枠組みは私たちが保つものだ：資源予算が有限のとき、アーキテクチャは選択しなければならず、その選択が包摂の決定である。バナーで後から足せるものではない。

[UNIQUE INSIGHT] 標準的な AI 製品は中央値の買い手に最適化されている――高速・定額の接続、最近のデバイス、一つの言語、一つのモダリティ（テキスト）。包摂とは、その中央値を設計の中心として拒んだときに得られるものだ。この制約がエンジニアリングを駆動する：より小さなモデルパス、text-first フォールバック、正しい部屋を見つけるためにメガバイトのクライアントバンドルを送らないルーティング層。Everythink では、空間がルータである――network → community → room――要求は、何かが応答する前に正しいポリゴンに着地する。そのメカニズムが、キャッチフレーズではなく、貧弱な接続でも製品をアクセス可能にするものだ。

The Honest Architect のラベルはここで重要だ。HAI 会話エンジンは ✅ Production、2016 年から稼働中。Social、Campaigns、Whitelabel Network は ✅ Production。Matchmaking、Marketplace、Calendar は ⚠️ Partial。Wallet & Token、Super App、Community Credit は 🔵 Roadmap。私たちは、包摂的に見せるために状態を昇格させない。構築されていない能力は主張されない。

特化はシステムをより包摂的にするのか、それとも逆なのか？

よくある反論はこうだ：低接続性向けに特化すれば、全員にとってより悪いシステムを構築することになる。数学は逆を示している。2026 年、Dharma-AI のエッセイ「Why Specialization Is Inevitable」は Wolpert と Macready の 1997 年の no-free-lunch 定理を歩み、「アルゴリズムは対象問題にうまくフィットすることで勝つ」と結論し、「普遍的な一般性は理論上の概念だが、実用上は神話である」とした(Dharma-AI, Hugging Face, 2026)。

[ORIGINAL DATA] 私たちは同じ直感を 21 報の学術論文シリーズで形式化した。Theorem 3 は、ある属性はそのメカニズムが実装され測定されているときにのみ保証されると述べる。包摂はその種の属性だ：低接続メカニズムが構築され観測されたときにのみ保証される。背後にメカニズムのない包摂の主張は、Theorem 3 によれば保証ではなくマーケティングだ。私たちが指すメカニズムは、トポロジールータと、エンジンが 2016 年から使ってきた小フットプリントのモデルパスである。

特化とは、貧弱な接続のための別個の「ライト」製品を構築することを意味しない。一つの製品がこの制約によって形作られることを意味する。MIT の記事が言うように、「より狭い焦点はより鋭い技術をもたらすが、それは十分に広く、とても価値がある」(MIT News, 2026)。その狭さこそが包摂の源泉だ。Shah の研究室は、テキストと画像だけでなくテーブルデータと時系列データの上に構築する――それが現実世界の意思決定の形だからだ。私たちの類似物は地理空間ポリゴンである――部屋が文脈の単位であり、そこへのルーティングは安い。

多言語 AI は英語の先で本当に動くのか？

2026 年、IBM Granite は「Granite Embedding Multilingual R2」をリリースした。Apache-2.0 の埋め込みファミリで、200 以上の言語をカバーし、52 でチューニングされ、MTEB Multilingual Retrieval ベンチマークで「100M 未満のオープン多言語 embedder をすべて打ち負かす」97M パラメータのコンパクトモデルを含む(IBM Granite, Hugging Face, 2026)。この投稿が名指すトレードオフは、すべての多言語システムがぶつかるものだ：「広い言語カバーは通常モデルサイズを犠牲にし、小さなモデルは通常言語を犠牲にする。」97M のコンパクトモデルは包摂の産物である――311M や 3B のモデルが動かないところで動く。

同じ月、Technology Innovation Institute は「Introducing Falcon-H1-Arabic」を発表した。3B、7B、34B パラメータのハイブリッド Mamba-Transformer ファミリで、アラビア語、英語、多言語コンテンツにわたって約 3000 億トークンで訓練された(TII, Hugging Face, 2026)。包摂にとって重要な細部は方言だ：現代標準アラビア語はエジプト、レバント、湾岸、マグレブと共存し、「それぞれが独自の語彙と文法構造を持つ。」MSA だけを扱うモデルはアラビア語話者を包摂するのではない――形式的なレジスターを包摂するのだ。

[PERSONAL EXPERIENCE] 私たちはこのブログに同じ決定を下した。それは一つのマニフェストから 7 つの locale で公開される――en、es、pt、zh、ja、de、fr――hreflang alternates と locale ごとの slug を伴う。英語ルートはプレフィックスなし；他の 6 つはプレフィックス付き。ビルドは locale ごとに静的だ。それは英語製品の上に後から加えられた翻訳機能ではない。それはルーティング層で多言語である製品だ。システムがあなたの言語であなたに届かなければ、モデルが内部的に何言語を理解しようと、あなたを包摂していない。

マルチモーダルはテキスト単独では加えられない何を加えるのか？

2026 年、Hume AI は「Introducing Real World VoiceEQ」を発表した。40 以上の音声モデルと 15 以上の次元にわたる 100 万件以上の人間評価から構築されたベンチマークである(Hume AI, Hugging Face, 2026)。その中心的な発見は、別の声域での包摂論だ：「従来のベンチマークは現実世界のパフォーマンスをますます過大評価する」、なぜならモデルは「訛りのある発話、重なる話者、感情、背景ノイズ、より長い会話」でまだ苦戦するからだ。クリーンなスタジオ音声でよいスコアを出す音声モデルは、包摂的な音声モデルではない。それはスタジオのための音声モデルだ。

マルチモーダルが包摂の制約である理由は二つある。第一、発話は最も帯域の狭いテキストである：農産物市場、診療所、配送ルートで発話された一文は、キーボードが運ばない意味を運び、システムの言語で打たない――あるいは全く打たない――人々のために働く。第二、画像と地理は、散文が安くエンコードできない文脈を運ぶ。Everythink のトポロジーは、まさに細いパイプ上のモバイルデバイスが重いラウンドトリップなしでサーバーに自分の位置を伝えられるように、PostGIS 全体幾何ではなく geohash プレフィックスでルーティングする。

VoiceEQ の「音声モデルは実際に聞くことより話すことが上手くなった」という発見は警告だ。マルチモーダルはデフォルトで包摂的ではない；詐欺チェックでためらった「…はい…」を見逃す音声モデルは、ユーザーが誰かを決めたモデルである。設計による包摂とは、ためらいの「はい」、訛りの「はい」、ノイズの「はい」のために構築し、そうしていることを測ることだ。HAI エンジンの room-aware コンテキストは ✅ Production；より広い音声面は ⚠️ Partial で、まだ私たちが望むほど測られていない。

高速回線だけでなく低速接続のためにどう構築するか？

2026 年、MIT News は中核の設計問題について Devavrat Shah を引用した：「わずかな資源で、かなりの重作業をしなければならない」(MIT News, 2026)。これが、工学的制約として述べられた低接続の問題だ。私たちのスタックでのアーキテクチャ上の答えは具体的で、形容詞のものは一つもない。

第一、描画より先にルーティングせよ。トポロジールータはサーバー上で network → community → room を解決し、クライアントはすべてのメニューではなく要求したスライスを受け取る。第二、small-model パスを優先せよ。IBM Granite の 97M 多言語 embedder を生んだ同じ直感は、ラウンドトリップ予算がきついときにフロンティア汎用モデルより小さく特化したレスポンダを選ぶ直感である。第三、クライアントバンドルを正直に保て。設定がコードに取って代わり、組織は新しい依存ではなく設定一つでモジュールをオンにする。第四、グレースフルに劣化させよ。音声面が通らなければテキスト面が通る。地図がタイルできなければ geohash がまだルーティングする。

これらは機能ではない。制約が形に反転されたものだ。honest-architect の動きは、現実のものをラベル付けすることだ。HAI エンジン、Social、Campaigns、Whitelabel Network は ✅ Production。Matchmaking、Marketplace、Calendar は ⚠️ Partial――今日有用だが完成していない。Wallet & Token、Super App、Community Credit は 🔵 Roadmap、pre-revenue、Howey レビューに服し、構築済みとは記述しないものだ。包摂は、まだライブでない機能から成熟度を借りてはならない。

包摂はエンジニアリングを鋭くする制約である

包摂を厚意として枠付ける誘いがある――プラットフォームが、より少なく持つユーザーのためにする何かとして。証拠は逆を指す。Dharma-AI のエッセイは「ある与えられた領域で最も顕著な成果を上げるシステムは、最も狭くそれに集中するシステムである」と記す(Dharma-AI, Hugging Face, 2026)。低速接続をサーブすることを強いる制約は、重さを落とし、正しいモダリティを選び、正しい部屋へルーティングし、一つではなく七つの言語で出荷することを強いるのと同じ制約だ。

だから私たちはこの投稿を 7 つの locale で、2016 年から稼働するエンジンの上で、各能力をその現実の状態にラベル付けして公開する。設計による包摂は私たちが取る立場ではない。私たちが保つ制約だ。

よくある質問

Everythink において「設計による包摂」は実際に何を意味するか？

それは、包摂がマーケティングの一行ではなくアーキテクチャ上の制約であることを意味する。HAI エンジンは 2016 年から本番稼働し、network → community → room トポロジーでルーティングし、このブログを 7 つの locale（en/es/pt/zh/ja/de/fr）で公開している――✅ Production。ある属性はそのメカニズムが構築され測定されたときにのみ保証される（Theorem 3、私たちの 21 報シリーズ）。

多言語ブログは本当に 7 つの言語すべてでライブか？

英語ルートはプレフィックスなし（/blog）；他の 6 つはプレフィックス付き（/es/blog、など）で、hreflang alternates と locale ごとに静的に生成される slug を伴う。✅ Production。いくつかの投稿はまだ執筆中だ；harness、ルーティング、SEO 層はライブである。Partial や Roadmap の項目を Production に昇格させない。

低接続設計は高速接続の誰かにどう影響するか？

彼らを傷つけない――彼らがすでに支払っていた重さを取り除く。応答する前に正しい部屋へルーティングすることはより小さなペイロードを意味する。フロンティア汎用モデルより小さな特化モデルを選ぶことはより速いラウンドトリップを意味する。2026 年、IBM Granite の 97M 多言語 embedder は MTEB Multilingual Retrieval で 100M 未満のすべてのオープンモデルを打ち負かした(IBM Granite, Hugging Face, 2026)。より小さいものは、フィットするとき、単によりよい。

なぜマルチモーダルか？テキストで十分ではないか？

テキストは、システムの言語で流暢に打て、それを描画するデバイスの上にいる人々には十分だ。2026 年、Hume AI の Real World VoiceEQ ベンチマークは、100 万件以上の人間評価から構築され、「音声モデルは実際に聞くことより話すことが上手くなった」し、まだ「訛りのある発話、重なる話者、感情、背景ノイズで苦戦する」と見出した(Hume AI, Hugging Face, 2026)。発話と画像はテキストが落とす文脈を運び、テキストが排除するユーザーに届く。

wallet、token、community-credit のレイヤーはこれの一部か？

いいえ。Wallet & Token、Super App、Community Credit は 🔵 Roadmap、pre-revenue で、Howey 分析に服する。それらはライブではなく、包摂機能として記述されない。設計による包摂は、今日 ✅ Production または ⚠️ Partial であるエンジン、トポロジー、多言語およびマルチモーダル面を指す。ここには金融・投資・法的助言は一切ない。

結論

設計による包摂とは、高速回線の中央値を設計の中心として拒む規律である。それは、描画より先にルーティングするトポロジー、遅いラウンドトリップに合う small-model パス、一つのマニフェストから 7 つの locale で公開する多言語 harness、そしてためらいの「はい」を聞くマルチモーダル面として現れる。それぞれはメカニズムであり、それぞれはその現実の成熟度状態を帯びる――✅ Production、⚠️ Partial、または 🔵 Roadmap。そのラベル付けが誠実さのコミットメントである：ある属性はそのメカニズムが実装され測定されたときにのみ保証される。

プラットフォーム――そしてその誠実さ――を自ら確かめたいなら、デモを予約するか、エンジンの背後にある21 academic papersを読んでほしい。

Sources

関連

自らの主張を証明するエンジンの上に、あなたの世界を築く。

2016 年から稼働し続けるエンジンの上に、あなた自身のネットワークを作る——あるいは 21 本の論文を書いたチームに話しかける。

ネットワークを作る →デモを予約する