FLARES LLC

Technical document

共有メモリとモデルルーターで設計するAIエージェント基盤

すべての仕事を最上位モデルへ送れば品質は安定しやすい一方、費用と利用枠を早く消費します。反対に、安価で利用量の大きいモデルへ一律に寄せると、難問での手戻りと、送ってはいけない情報の越境が起きます。先にデータ境界を確定し、その内側で共有メモリとモデルルーターを使うことが、品質、費用、使用可能量を同時に扱う前提です。
AI開発 / エージェント基盤約17分公開日 2026年8月8日更新日 2026年8月8日
共有メモリを中心に通常処理と難問処理を安全に振り分けるAIモデルルーターのイラスト

Summary

この文書の要点

  • 共有メモリは会話全文の保管庫ではなく、目的、状態、根拠、未確認事項を版付きで受け渡す作業台として設計します。
  • データ分類はモデル選択より先に決定し、秘匿区分の本文はLunaにもGLMにも渡さず、承認済みのSol経路へ固定します。
  • 公開情報を使う定型・大量処理はGLM、通常の振り分け判断はLuna、複雑な設計・反証・最終統合はSolという役割に分けます。
  • 費用だけでなく、品質、待ち時間、利用枠、再試行、越境拒否、fallback理由を監査し、ルーティングの妥当性を継続的に検証します。

モデルを増やす前に、判断順序を固定します

複数モデルを使う基盤では、モデル名の一覧より判断の順序が重要です。最初に入力と参照先の機密度を分類し、次に利用を許可できるproviderを絞り、その後で難易度、費用、待ち時間、残り枠を比較します。費用を先に見ると、安いモデルへ送信した後で秘匿情報に気付くという、取り消せない失敗が起きます。

本稿では、Lunaをルーティング判断、GLMを公開情報中心の大量処理、Solを難問と承認済み秘匿処理の担当として扱います。ただし、これはモデル名を権限そのものにする設計ではありません。実際の許可はprovider、契約、処理地域、保存期間、学習利用、監査可否を束ねたポリシーで決めます。

共有メモリ同期という呼称も、特定の製品名や案件名ではなく、複数エージェントが版付きの作業状態を受け渡す一般化した方式を指します。会話履歴を無制限に共有するのではなく、次の担当が独立検証を始めるために必要な最小情報だけを同期します。

  • 第1段階: データ分類と送信可否を決める。
  • 第2段階: 許可されたproviderの中から難易度と費用で候補を選ぶ。
  • 第3段階: 残り枠、待ち時間、障害状態を見て実行先を確定する。
  • 不明な入力は安い経路へ推測で流さず、秘匿側へ倒すか人へ戻す。

共有メモリは結論ではなく、検証可能な状態を渡します

エージェント間の共有メモリへ会話全文、添付、取得したファイル、tool結果をそのまま保存すると、利便性と同時に漏えい範囲も広がります。共有するのはtask ID、目的、現在状態、担当、判断の要約、根拠への参照、検証結果、未確認事項、機密度ラベルを基本にします。秘密本文は元の保管場所へ残し、共有メモリには権限検査付きの参照だけを置きます。

更新にはversionとexpectedVersionを持つcompare-and-swapを使います。二つのエージェントが同じ版から更新した場合、片方を409相当の競合として止め、最新状態を読み直してから統合します。last-write-winsでは、ルーティング理由、秘匿ラベル、未解決の検証が古い値で消える可能性があります。

各項目にはsource、createdAt、expiresAt、classification、allowedProvidersを付けます。AIが生成した要約はverified=falseで保存し、別のエージェントや人が実データを確認するまで事実扱いしません。期限切れの結果を新しいタスクへ自動注入しないことも、誤った長期記憶を避けるために必要です。

  • 本文ではなく、状態、要約、参照、検証結果を同期する。
  • 版競合を黙って解消せず、読み直しと統合を要求する。
  • 機密度と許可providerを共有状態の必須項目にする。
  • AI生成の記憶へ出典、検証状態、期限を付ける。
共有メモリの一般化例
{
  "taskId": "architecture-review",
  "version": 12,
  "state": "needs_deep_review",
  "classification": "confidential",
  "allowedProviders": ["approved-sol-route"],
  "decisionSummary": "境界条件の反証が必要",
  "evidenceRefs": ["artifact://review-input/42"],
  "verified": false,
  "expiresAt": "2026-08-09T00:00:00Z"
}

Lunaは本文を読む前の二段目ルーターにします

Lunaへ生のpromptを渡してから『どのモデルへ送るか』を考えさせると、ルーター自身が秘匿情報の送信先になります。そこで第一段階は決定的なローカル処理にします。入力欄、添付、参照先、tool権限、共有メモリを走査し、データ分類とprovider allowlistを確定します。秘匿または判定不能ならLunaを迂回し、承認済み経路へ固定します。

Lunaが受け取るのは、公開可能な要約、言語、入出力形式、変更予定ファイル数、依存関係の広さ、必要なtool、試行回数、テスト範囲、期限といったrouting metadataです。Lunaは通常処理、GLM向け大量処理、Sol向け難問、人への確認の候補を返します。最終決定はコード化されたpolicy engineが行い、モデル出力だけでallowlistを拡張しません。

難易度は『文章が長い』だけでは測れません。認可、migration、並行更新、金銭計算、外部公開、rollback不能、複数システムの契約変更は、入力が短くても高リスクです。反対に、大量の公開文書の分類や定型変換はtoken量が大きくても、独立検証を用意できればGLMへ向きます。

ルーティング順序の擬似コード
const classification = classifyLocally(input, references);
const allowed = providerPolicy[classification];

if (classification === "unknown") return requireHumanReview();
if (allowed.equals(["approved-sol-route"])) return routeToSol();

const metadata = buildSanitizedRoutingMetadata(input);
const suggestion = await lunaSuggest(metadata);

return enforcePolicy({
  suggestion,
  allowedProviders: allowed,
  remainingQuota,
  riskSignals,
});

GLMの低い単価と大きい利用枠は、大量処理へ使います

2026年8月8日に確認した公式情報では、GLMの通常API料金はGLM-4.7が入力100万tokenあたり0.60米ドル、出力2.20米ドル、GLM-5.1が入力1.40米ドル、出力4.40米ドルです。同時点のGPT-5.6 Solは入力5米ドル、出力30米ドル、Lunaは入力1米ドル、出力6米ドルです。単純なtoken単価だけでも差は大きく、公開情報の分類、候補生成、定型変換、独立に採点できる反復処理ではGLMを使う意味があります。

Coding Planの公称上限は、Liteが5時間あたり約80 prompt・週約400、Proが約400・約2,000、Maxが約1,600・約8,000です。公式説明では一つのpromptが15〜20回のmodel callに相当する目安も示されています。ただし、上限は推定値で、混雑、モデル、タスクの複雑さ、利用規約により変わります。ルーターは固定値を埋め込まず、利用量APIまたは管理画面の値を運用設定として取り込みます。

注意すべきなのは、Coding Planの枠が汎用API用途ではなく、公式に対応したcoding tool内の個人利用へ限定されていることです。自作SaaSのバックエンドからこの枠を呼ぶ設計には転用できません。対応外用途では通常APIを使い、契約、rate limit、再販売制限を別に確認します。安価で大きい枠ほど、利用条件をアーキテクチャの前提に含める必要があります。

  • GLM向き: 公開情報、大量、定型、再実行可能、機械的に採点できる処理。
  • Luna向き: 秘密を除いたrouting metadataの分類と通常の補助判断。
  • Sol向き: 複雑な設計、反証、権限、移行、不可逆な判断。
  • 料金と枠は確認日を持つ設定値にし、記事やコードの定数へ固定しない。

Solへ上げる条件を、失敗後ではなく事前に定義します

Solへの委譲を『GLMが失敗したら考える』だけにすると、再試行に費用と時間を使い、誤った変更が共有メモリへ残ります。認証・認可、データ消失、migration、分散更新、複数provider間の整合、契約変更、rollback不能、公開前の最終判断は、最初から難問としてSolへ送ります。

通常タスクでも、同じテストが二回失敗した、Lunaの難易度判定が高い、影響範囲が途中で広がった、前提が共有メモリと実コードで食い違う、信頼できる採点器がない場合はSolへ昇格します。token数やファイル数だけでなく、失敗時の損失と検証可能性を判断軸にします。

Solが返した結果も自動的な正解ではありません。最終diff、テスト、静的検査、権限、migration dry-run、rollback手順を実データで確認します。高性能モデルへの委譲は、検証を省く理由ではなく、より難しい論点へ計算資源を集中するための手段です。

  • 事前昇格: 権限、移行、不可逆操作、複数境界、損失が大きい処理。
  • 途中昇格: 反復失敗、影響範囲の拡大、前提不一致、採点不能。
  • 完了条件: モデルの自己申告ではなく、差分と検証結果で判定する。

秘匿情報はprovider境界の手前で止めます

安全性をモデル提供元の国籍だけで判断すると、同じprovider内の契約差、保存期間、処理地域、学習利用、管理者権限、監査機能を見落とします。実装ではproviderごとにapprovedClassifications、retention、trainingUse、processingRegions、toolPermissions、contractVersionを登録し、秘匿区分を許可していない経路へは送信関数そのものが失敗するようにします。

分類対象は利用者のpromptだけではありません。system・developer指示、共有メモリ、添付、Git差分、環境変数、tool結果、検索結果、過去turnの要約、エラーログにも秘密が入り得ます。router inputを作る直前にすべてを結合して走査し、秘密候補が一つでも残る場合はfail-closedにします。

redactionは補助策です。秘密値をローカルのtokenへ置換し、復元表を外部へ出さない方式は定型処理に使えますが、文章の文脈、ファイル名、顧客固有のデータ構造だけで主体を推測できる場合があります。安全な要約を作れない入力は、GLMやLunaへ薄めて送るのではなく、承認済みSol経路またはローカル処理へ残します。

  • public: provider allowlist内で費用と品質を比較できる。
  • internal: 匿名化と内容検査を通した限定経路だけに許可する。
  • confidential: 組織が承認したSol経路またはローカル処理へ固定する。
  • restricted / unknown: 自動送信せず、人の確認へ戻す。

一回の実行を、分類・選択・検証・記録に分けます

実行開始時にtask envelopeを作り、入力のhash、classification、許可provider、予算、期限、必要tool、期待する検証を記録します。ローカル分類を通過した後、秘匿を含まない場合だけLunaへrouting metadataを渡し、policy engineが候補を確定します。

GLMへ送る処理には、出力schema、最大token、timeout、再試行回数、採点器を必須にします。たとえば公開文書の分類なら、JSON Schemaに従うこと、許可label以外を返さないこと、同じ入力への再現性、抽出元の引用位置を検査できます。品質ゲートを通らない結果は共有メモリのverifiedを進めません。

Solへ送る場合は、難問の理由と、GLMやLunaが確認済みの事実を区別して渡します。最終結果にはroute、model、policyVersion、classification、入力hash、token、費用見積もり、待ち時間、fallback、検証結果を付けます。生の秘匿本文を監査ログへ複製しないことも重要です。

枠切れと障害では、安全な方向へfallbackします

GLMの利用枠が減った時、公開情報の定型処理ならqueueへ戻す、別の許可済み低コストAPIへ切り替える、期限が近いものだけSolへ上げる、という選択ができます。ただし、GLMへ許可したからといって、障害時に任意providerへ送ってよいわけではありません。fallback先も同じclassificationのallowlist内で選びます。

Lunaがtimeoutした場合は、簡単な規則でGLMまたはSolへ推測転送せず、risk signalとclassificationから決定的な既定経路を選びます。低リスクの公開処理はGLM、高リスクまたは不明はSolか人へ戻す、といった順序です。router障害が情報境界の迂回路にならないようにします。

一部成功にも注意が必要です。十件中八件をGLMで処理し、二件をSolへ送る時は、task単位ではなくitem単位のrouteと検証状態を持ちます。全体を成功として閉じると、未処理項目や異なる品質基準が共有メモリから見えなくなります。

  • quota不足: 低優先度を待機させ、許可済み経路だけで再配分する。
  • router障害: classificationとriskから決定的な既定経路を使う。
  • model障害: timeout、retry上限、circuit breakerをprovider別に持つ。
  • 部分成功: itemごとのroute、検証、再開位置を保存する。

費用削減だけでなく、誤配と手戻りを観測します

モデルルーターの成果を『Solの使用量が減った』だけで測ると、GLMの修正をSolがやり直す費用や、利用者の待ち時間を見落とします。route別の初回合格率、Solへの昇格率、再試行token、p50・p95待ち時間、人による差し戻し、境界拒否件数を同じ画面で追います。

監査ログにはrouting decision、policyVersion、classification、許可候補、選択理由、fallback理由、入力hash、token、概算費用、検証結果を残します。prompt本文、秘密値、添付内容は保存せず、必要ならアクセス制御された元データへの参照を使います。ログ基盤自体を新しい漏えい先にしないためです。

モデルや料金、利用規約が変わった時はpolicyVersionを更新し、少量のshadow routingで比較します。同じ公開タスクを候補モデルへ送り、品質、費用、時間を測っても、本番結果は一つだけ採用します。秘匿タスクをshadow検証へ複製してはいけません。

  • 効率: token単価、総token、再試行を含む完了あたり費用。
  • 品質: 初回合格率、昇格率、差し戻し、未検証項目。
  • 速度: queue時間、model時間、検証時間、p95。
  • 安全: 越境拒否、unknown分類、allowlist違反、監査欠落。

正常系より、境界を破ろうとする検証を重視します

単体テストでは、public、internal、confidential、restricted、unknownの各入力が期待するallowlistになることを確認します。promptだけでなく、添付、tool結果、共有メモリ、履歴要約に秘密を埋め、LunaやGLMの送信関数が一度も呼ばれないことをspyで検証します。

ルーティングでは、Lunaがallowlist外のGLMを提案してもpolicy engineが拒否すること、GLM枠切れで秘匿入力が別providerへ流れないこと、Solへの昇格理由が記録されることを確認します。共有メモリでは同一versionへの競合更新、期限切れ、verified=falseの扱いを検証します。

E2Eではproviderをmockし、送信直前のenvelopeを検査します。秘密候補を含むpayloadを受け取ったmockはテストを即時失敗させます。最後に、本番と同じpolicy bundleのhashがデプロイ済みであること、監査ログへ本文が残らないこと、kill switchで外部providerを停止できることをsmoke testします。

  • 秘密がprompt以外へ混入しても、許可外providerを呼ばない。
  • Lunaの提案はpolicyを上書きできない。
  • quota不足、timeout、部分成功でもclassificationを保持する。
  • policy変更、model変更、fallback変更を監査可能にする。

この設計にも、分類誤りと運用費用が残ります

ローカル分類器は完全ではありません。未知の秘密形式、画像内の文字、暗号化済み添付、toolが後から取得する情報は見落とす可能性があります。unknownを許可側へ倒さず、画像OCR、archive展開、参照先検査、toolごとの出力分類を段階的に加える必要があります。

共有メモリの要約を小さくしすぎると、Solが前提を再調査して費用が増えます。大きくしすぎると、古い情報と秘密が残ります。実際の昇格率と再調査時間を測り、task種別ごとにschemaとTTLを調整します。万能な一つの記憶形式を目指さない方が運用しやすくなります。

GLMの料金と利用枠、SolとLunaの特性、providerの契約条件は変わります。したがって、モデル名をソースコードの分岐へ散らさず、capability、classification、cost、quota、healthを設定として管理します。本稿の数値は2026年8月8日の確認値であり、導入時には公式情報を再確認します。

持ち帰る判断軸は、安さより先に境界を置くことです

共有メモリとモデルルーターの目的は、すべてのモデルへ同じ情報を見せることではありません。必要最小限の状態を版付きで渡し、データ分類に応じて見せてよいモデルを先に絞ることです。その内側でLunaに振り分けを補助させ、GLMの低い単価と大きい利用枠を大量処理へ使い、Solの計算資源を難問へ集中させます。

安全性は『特定モデルを信じる』という宣言ではなく、provider allowlist、ローカル分類、fail-closed、復元表の分離、送信直前検査、監査、境界テストで作ります。モデル名が変わっても、この順序なら同じ設計判断を再利用できます。

最初の適用対象には、公開文書の分類や定型変換のように、秘密を含まず機械的に採点できる仕事が向きます。そこで完了あたり費用、初回合格率、Sol昇格率、境界拒否を測り、秘匿処理へ範囲を広げる前にルーター自体の信頼性を確認します。

Technical documents

技術文書を増やしていきます。

AI、クラウド、業務アプリ開発、要件定義、運用設計に関する考え方を、今後も文書として整理します。

技術文書一覧へ