# Anthropic、METRの限定チームに従業員同等アクセス

> AnthropicがMETRの限定チームに内部アクセスと公表権を付与。共有の例外と独立性の条件を確認する。Eilikoの脆弱性、Forumの検証型開発、ExecuTorchのCortex-M対応、Muse Spark Openの配置条件、GitHubのコード走査・修正支援の正式提供も追う。

Canonical URL: https://labs.eastbraver.com/digest/ai-digest-20261016
Published: 2026-10-16T06:30:00+09:00
Category: ai-digest
Tags: anthropic, governance, safety, robotics, ai-agent, evaluation, software-engineering, multimodal, llm-inference, model-ops

Anthropicが、METRの6人の評価者に従業員に近い内部アクセスを提供し、同社の承認なしで分析を公表できる制度を明らかにした。アクセスの広さだけでなく、共有しない情報と例外、公表時の削除要求の範囲が要点になる。

本号ではこの制度に加え、Eiliko関連サービスの会話閲覧と遠隔改変、MetaのForum開発における検証と人間承認を取り上げる。ExecuTorchのマイクロコントローラー対応、Muse Spark Openの配置・利用条件、GitHubのコード走査・修正支援は、それぞれ別の導入判断として読む。（[Anthropicの発表](https://www.anthropic.com/news/an-update-on-independent-evaluators) / [Eilikoの報道](https://www.theverge.com/tech/1010727/eiliko-robot-hack-energize-lab) / [Forumの開発報告](https://engineering.fb.com/2026/10/15/ml-applications/how-meta-built-forum-ai-native-engineering/) / [ExecuTorchの発表](https://pytorch.org/blog/bringing-executorch-to-arm-cortex-m-cpus/) / [Muse Spark Openの発表](https://research.meta.ai/blog/muse-spark-open) / [GitHubの発表](https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability/)）

## Anthropic、METRの限定チームに従業員同等のアクセスを付与

Anthropicは、非営利評価機関METRの限定されたチームに「従業員同等のアクセス」の提供を開始した。対象のMETR職員は6人で、社用ハードウェア、オフィス、社内ツールとシステムを、Anthropicのリスク評価チームとおおむね同じ範囲で利用できる。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)）

顧客データや弁護士・依頼者間の秘匿情報、モデル構造の情報などは、通常の共有から除かれる。ただしモデル構造の情報は、リスク評価との関連が高い場合、明示的な社内承認を得て共有する方針も脚注に示されている。法的拘束力のある契約を結んだ少人数のチームに限る取り組みで、他のMETR職員はその業務から隔離され、社内に常駐する評価者にはAnthropicのセキュリティ基準が適用される。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)）

METRはリスク水準、インシデント、実務慣行の分析を公表でき、Anthropicは公表自体を拒否できない。Anthropicが削除を求められるのは事前に定めた限定区分の情報であり、METRは削除内容を明かさない範囲で、その削除が妥当だったかについて見解を示せる。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)）

Anthropicが掲げる評価者の独立性は、評価対象企業の株式を保有せず、財務面でも運営面でも同社に依存しないことを条件とする。今回のMETR方式は、開発中の3段階制度の第3段階に位置づけられ、従業員同等のアクセスと、第2段階に近い公表権を組み合わせる。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)）

> [!CAUTION] 確認できていない点
> 適用されるセキュリティ基準と契約条項の詳細は、発表本文では示されていない。アクセスを認める制度の説明と、個別の情報を共有する際の承認手順は分けて確認したい。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)）

**比較表: 評価者向けアクセス制度の第1段階と第3段階**

3段階制度の両端では、評価者が得る情報の範囲と、企業の承認なしに結果を公表できるかが異なる。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)）

| 観点 | 第1段階 | 第3段階（METR方式） |
| --- | --- | --- |
| 情報アクセス | 対象を絞ったリスク調査について、Anthropicがアクセス範囲を決める。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)） | 従業員同等のアクセスを認める。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)） |
| 公表権 | 結果の公表にはAnthropicの承認が必要となる。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)） | 第2段階に近い公表権を持ち、Anthropicの承認なしで公表できる。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)） |

**EastBraverの見立て:** 制度の核心はアクセスの広さだけでなく、公表拒否を認めず、削除要求を限定区分に絞った点にある。評価の独立性は、公開権と、評価対象への財務・運営上の非依存を合わせて判断する必要がある。（[出典1](https://www.anthropic.com/news/an-update-on-independent-evaluators)）

- 出典: [Anthropic](https://www.anthropic.com/news/an-update-on-independent-evaluators)（公式情報、2026-10-16 02:20 JST公開）

## Eiliko関連サービスで約1,300万件の会話閲覧と遠隔改変の実演

The Vergeによると、研究者Sammy Azdoufalは、Energize Labのサービスに保存された利用者の会話約1,300万件を閲覧でき、稼働中とみられるロボット玩具68,000台にアクセスできた。米国では31,000件超のプロフィールが子どものものだった。これらは同紙が報じた規模であり、以下の脆弱性ごとの検証台数を表すものではない。（[出典1](https://www.theverge.com/tech/1010727/eiliko-robot-hack-energize-lab)）

サービスは会話を読み取り、氏名、年齢、誕生日、職業、家族、友人、ペット、人物像を含むプロフィールを作成していたとThe Vergeは報じた。メールアドレス、IPアドレス、全文検索可能な会話履歴も保存され、一部の子どもの写真と短い音声録音は公開Webアドレスに置かれていた。写真はEiliko本体ではなく、カメラを備えた大型姉妹機から得たとみられるものだった。（[出典1](https://www.theverge.com/tech/1010727/eiliko-robot-hack-energize-lab)）

Azdoufalは遠隔地からThe Verge記者所有のEilikoの[メモリー](/guides/memory)を改変し、LLMの応答を乗っ取る実演をした。全ロボットの人格を同時に改変できるとの説明はAzdoufalの主張であり、記事中で実演された対象は記者所有機だった。（[出典1](https://www.theverge.com/tech/1010727/eiliko-robot-hack-energize-lab)）

AHA!の一次アドバイザリは、Eilik・EilikO、AI Station、関連アプリとクラウドサービスを対象に9件のCVEを公表した。調査対象には、`station-middleware`のDockerイメージ1.6.5～1.8.2、ロボットファームウェア`v2.1_20260617182218_release`、Androidアプリ3.0.0、Windowsアプリ3.1.2が含まれる。一部のホスト型サービスとAI Stationファームウェアには公開版番号がない。（[一次アドバイザリ](https://takeonme.org/cves/multiple-energizelab-eilik-eiliko-platform-vulnerabilities/)）

攻撃条件は脆弱性ごとに異なる。CVE-2026-105038のAIモデル管理・切り替えには認証が不要で、CVE-2026-105037のサーバー上のファイル読み取りには低権限の登録アカウントが必要となる。AI Stationの既定認証情報など、近隣ネットワークやローカルアクセスが関わる経路もある。利用者ごとの[認証と認可](/guides/ai-identity-authorization)を欠くクラウドAPIの問題と、端末側の問題を一括りにしないことが重要だ。（[一次アドバイザリ](https://takeonme.org/cves/multiple-energizelab-eilik-eiliko-platform-vulnerabilities/)）

> [!CAUTION] 修正状況の時点
> アドバイザリにある9月14日の再検証では、遠隔から検証可能な44件中42件が未修正だった。これは9月の調査記録であり、10月15日の公開時点に全件を再検証した結果ではない。公開時点の修正版や、提案された対策の適用状況は、この資料だけでは確認できない。（[一次アドバイザリ](https://takeonme.org/cves/multiple-energizelab-eilik-eiliko-platform-vulnerabilities/)）

**EastBraverの見立て:** 本件は、保存データの機密性と端末の挙動改変を別々の影響として評価すべき事案である。会話やプロフィールを次の応答へ戻す機能では、保存先を守るだけでなく、誰が内容を読み書きできるかも確認する必要がある。（[報道](https://www.theverge.com/tech/1010727/eiliko-robot-hack-energize-lab) / [一次アドバイザリ](https://takeonme.org/cves/multiple-energizelab-eilik-eiliko-platform-vulnerabilities/)）

- 出典: [The Verge](https://www.theverge.com/tech/1010727/eiliko-robot-hack-energize-lab)（二次報道、2026-10-15 20:00 JST公開） / [AHA!](https://takeonme.org/cves/multiple-energizelab-eilik-eiliko-platform-vulnerabilities/)（一次脆弱性アドバイザリ、2026-10-15 20:00 JST公開）

## MetaのForum開発、AIエージェントを反復と検証に組み込む

Meta Engineeringによると、少人数チームがゼロから開発したForumは、8週間でFacebook Groupsの主要機能と同等の状態に達した。AIが定型的な実装の多くを担い、エンジニアはアーキテクチャ、製品判断、品質に注力した。（[出典1](https://engineering.fb.com/2026/10/15/ml-applications/how-meta-built-forum-ai-native-engineering/)）

目標としたのは、エージェントが計画、実装、ビルド、テスト、修正を反復し、人間がその反復を監督するhuman-on-the-loop方式である。エンジニアは目標設定、監視、介入、承認、品質責任を担う。ただし完成済みの全面自律方式ではなく、現時点では一部工程だけが自律化され、他工程では反復ごとにエンジニアが関与する。（[出典1](https://engineering.fb.com/2026/10/15/ml-applications/how-meta-built-forum-ai-native-engineering/)）

反復には、プロジェクト共通の指示を持つRules、慣行を手順化するSkills、複数処理をつなぐCommandsを組み込み、ビルド、単体テスト、UI仕様との一致を判定する。完了条件はコンパイルではなく、自動テストと視覚チェックの通過であり、レビューにはビルド結果、テスト結果、記録済み検証セッションを添付する。出荷には引き続きエンジニアの承認が必要である。（[出典1](https://engineering.fb.com/2026/10/15/ml-applications/how-meta-built-forum-ai-native-engineering/)）

初期試作とエージェント生成実験には、ビルド単位の分離を採用した。本番と同じコードベース、フレームワーク、デザインシステムを共有する別ビルドのサンドボックスを設け、プラグイン／ソケット構成によって試作コードを本番ビルドからコンパイル時に除外した。これは本番ビルドへの混入を防ぐ方式であり、生成コードのファイルアクセスや通信を制限する[実行環境の隔離](/guides/sandbox)とは、確認すべき対象が異なる。（[出典1](https://engineering.fb.com/2026/10/15/ml-applications/how-meta-built-forum-ai-native-engineering/)）

主な失敗は、エージェントがアプリ内の現在位置を見失い、別画面を編集したり画面座標を推測したりすることだった。Meta Engineeringによると、シミュレーターの表示階層、画面要素、対象ビューへの経路を直接確認できるツールを与えると、誤った編集は大幅に減った。また、実利用を模した反復可能なストレス試験では、エージェントがメモリ問題の再現、修正提案、検証まで行い、修正によってメモリ使用量とページフォールトが大きく減った。（[出典1](https://engineering.fb.com/2026/10/15/ml-applications/how-meta-built-forum-ai-native-engineering/)）

> [!CAUTION] 確認できていない点
> 最終出荷に人間の承認が必要なことは明記されている。一方、エージェントが利用できる認証情報、書き込み先、ネットワーク接続先や、個々の操作で承認を求める条件は、開発報告では具体化されていない。（[出典1](https://engineering.fb.com/2026/10/15/ml-applications/how-meta-built-forum-ai-native-engineering/)）

**EastBraverの見立て:** この事例の判断軸は、AIによる実装量だけではなく、反復内の合否信号とレビュー証跡を一体で設計できるかにある。[操作権限](/guides/ai-identity-authorization)の設計と最終承認の責任は分けて捉える必要がある。8週間という開発期間や品質改善はMetaの自己報告であり、別の開発環境でも同じ成果が得られることを示す比較実験ではない。（[出典1](https://engineering.fb.com/2026/10/15/ml-applications/how-meta-built-forum-ai-native-engineering/)）

- 出典: [Meta Engineering](https://engineering.fb.com/2026/10/15/ml-applications/how-meta-built-forum-ai-native-engineering/)（公式情報、2026-10-16 04:00 JST）

## ExecuTorchがArm Cortex-MのCPU推論に対応

PyTorchは、ベータ段階のExecuTorch Cortex-MバックエンドによるCPU推論の導入手順と測定結果を公開した。従来からのEthos-U NPU対応に加え、Arm Cortex-MのCPUだけでもPyTorchモデルを実行する経路を提供する。学習済みモデルのエクスポート、量子化、対象機器向け変換を同じツール群で行い、別フレームワークの形式へ変換する工程を省く。（[発表](https://pytorch.org/blog/bringing-executorch-to-arm-cortex-m-cpus/) / [ベータ版の対応範囲](https://docs.pytorch.org/executorch/main/backends/arm-cortex-m/arm-cortex-m-overview.html)）

バックエンドは、対応する量子化演算をArm CMSIS-NNの最適化済み実装などへ置き換える。Scalar、DSP、MVE／Heliumの各命令セットに対応し、対象CPUと命令セットはコンパイル時に指定する。Ethos-Uと併用する場合も、CPU側の演算がバックエンドの量子化・データ配置・形状の条件を満たす必要があり、条件外はExecuTorchの汎用カーネルで処理する。（[出典1](https://pytorch.org/blog/bringing-executorch-to-arm-cortex-m-cpus/)）

開発側は、MLPerf Tinyの5モデル中4モデルを、Alif Ensemble E8の単一Cortex-M55コア、400 MHz、NPU不使用で測定した。INT8量子化した4モデルは、推論時間がいずれも21.450 ms以下、ピークRAMが90 KiB未満だった。小型機器への配置を検討する際の参考値になるが、用途に応じた演算の対応状況と実機のメモリ配置を確認する必要がある。（[出典1](https://pytorch.org/blog/bringing-executorch-to-arm-cortex-m-cpus/)）

> [!CAUTION] 評価と対応範囲
> 数値は開発側の測定で、公式のMLPerf Tiny提出結果ではない。任意のPyTorchモデルが同じ容量・速度で動くことは意味しない。CMSIS-NNに既にあるfp32・fp16 MVEカーネルを本バックエンドから利用する対応や、Attention演算・レイヤー正規化などの対応拡大は、今後の計画として記載されている。未対応演算を汎用fp32カーネルで実行する既存の処理とは区別したい。（[発表](https://pytorch.org/blog/bringing-executorch-to-arm-cortex-m-cpus/) / [対応範囲](https://docs.pytorch.org/executorch/main/backends/arm-cortex-m/arm-cortex-m-overview.html)）

**EastBraverの見立て:** 変更の価値は、CPUとNPUのどちらを使うかにかかわらず、PyTorchから機器への変換経路をそろえられる点にある。採用時はモデル全体のパラメータ数より、実際に使う演算が最適化経路へ載るか、対象ボードのRAMとフラッシュに収まるかを先に確かめたい。（[出典1](https://pytorch.org/blog/bringing-executorch-to-arm-cortex-m-cpus/)）

- 出典: [PyTorch](https://pytorch.org/blog/bringing-executorch-to-arm-cortex-m-cpus/)（公式情報、2026-10-15 23:40 JST公開）

## MetaのMuse Spark Openは量子化方式ごとに配置条件を確認

Muse Spark Openは、テキスト、画像、音声、動画を入力してテキストを出力するMetaのオープンウェイトモデルである。総パラメータは約8,160億、トークン当たりの有効パラメータは約420億、コンテキスト長は最大1,048,576トークン。Metaは、コードベースの読解、コード生成・デバッグ、[ツール呼び出し](/guides/tool)を伴うAIエージェント向けに学習したモデルだと説明している。（[Metaの発表](https://research.meta.ai/blog/muse-spark-open) / [Hugging Faceの技術解説](https://huggingface.co/blog/meta-muse-spark-open)）

Mixture-of-Experts（MoE）は、複数の部分ネットワークであるエキスパートから、入力に応じて一部を選んで計算する構成である。Muse Spark Openでは各MoE層の256個からトークンごとに8個を選択する。トークン当たりの計算規模は約420億パラメータ相当でも、配置時には選ばれなかった分も含めた重みの保存容量が必要で、実際のメモリ使用量は量子化方式やコンテキスト長によって変わる。（[出典1](https://huggingface.co/blog/meta-muse-spark-open)）

同シリーズのMuse Glimmerが小型の全結合型（Dense）モデルなのに対し、Muse Spark Openは各層のDenseフィードフォワード網をMoEブロックに置き換えた大型モデルである。Hugging Face記事は、動画内の音声も処理できる点をGlimmerからの強化としている。ただし、モデルが受け付ける入力と、各推論エンジンが現在扱える入力は同じとは限らない。（[出典1](https://huggingface.co/blog/meta-muse-spark-open)）

BF16チェックポイントはsafetensors形式で約1.5 TB。Hugging Faceが示すTransformersの実行例は、H200を各8基備えた4ノード、テンソル並列度32を使う。一方、同記事にはNVIDIA Blackwell向けのNVFP4版をB200ノードで動かす例があり、MetaはMLXによるM5 Ultra Mac Studio 2台でのローカル実行も紹介している。これらは方式ごとの実行例であり、GPU構成を一律の最低要件と読むべきではない。（[Hugging Faceの技術解説](https://huggingface.co/blog/meta-muse-spark-open) / [Metaの発表](https://research.meta.ai/blog/muse-spark-open)）

> [!CAUTION] 利用と評価の条件
> 重みは、商用利用に制限を設けたMuse Model Licenseで提供される。オープンウェイトを無条件の利用許可と解釈せず、導入前に用途と契約条件を確認したい。比較評価の方法は公開されているが、Metaによる評価と第三者の結果、他社の自己報告が混在するため、数値の出所と実行条件を分けて読む必要がある。（[ライセンスを説明する公式発表](https://research.meta.ai/blog/muse-spark-open) / [評価方法](https://research.meta.ai/static/muse-spark-open-evaluation-methodology)）

**EastBraverの見立て:** 導入可否は、トークン当たり約420億という計算規模だけでは決まらない。全重みとKVキャッシュを配置する容量、量子化による品質差、必要な入力形式への対応を、使う推論エンジンと機器の組み合わせで確認する必要がある。（[出典1](https://huggingface.co/blog/meta-muse-spark-open)）

- 出典: [Meta Superintelligence Labs](https://research.meta.ai/blog/muse-spark-open)（公式情報、原文日付2026-10-15） / [Hugging Face](https://huggingface.co/blog/meta-muse-spark-open)（公式技術解説、原文日付2026-10-15）

## GitHubが検証付き修正支援とPR向けAI Scanを正式提供

GitHubは、コード走査のアラートをCopilotに割り当て、修正案の作成と検証を反復させるAgentic autofixを正式提供した。Copilotは関連ファイルを調べ、CodeQLを再実行してアラートの解消を検証したうえで、レビュー用のドラフトPRを開く。対象は既定ブランチ上のアラートで、最大25件を一つのPRにまとめて修正できる。（[Agentic autofixの発表](https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability/)）

発表時の対象は、GitHub Enterprise CloudでGitHub Code SecurityまたはGitHub Advanced Securityを契約する顧客。企業管理者による許可と組織・リポジトリ側の有効化に加え、Copilotの請求方法の設定が必要となる。利用時はCode SecurityのAI CreditsとGitHub Actionsの実行時間を消費するため、従来の単発の修正案生成と費用条件を分けて確認したい。（[Agentic autofixの発表](https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability/)）

同日、PRの変更を調べるAI Scanも正式提供された。CodeQLを補完し、PHP、Shell／Bash、TerraformのHCL、Dockerfileなども対象にする。公開リポジトリで利用でき、組織所有の非公開・内部リポジトリではCode SecurityまたはAdvanced Securityが必要となる。Copilotライセンスは不要だが、Code SecurityのAI Creditsを消費する。（[AI Scanの発表](https://github.blog/changelog/2026-10-15-ai-scan-for-pull-requests-generally-available/)）

> [!CAUTION] 検出とマージ判断は別
> AI Scanの指摘は助言であり、コード走査チェックを失敗させず、ルールセットでマージを止める条件にもできない。フォーク由来とDependabot作成のPRは対象外となる。また、Agentic autofixも、カスタムCodeQLクエリー、`security-extended`、第三者ツールのアラートでは修正を検証できない。生成した変更のレビューとテストは引き続き必要だ。（[AI Scanの発表](https://github.blog/changelog/2026-10-15-ai-scan-for-pull-requests-generally-available/) / [autofixの仕様](https://docs.github.com/enterprise-cloud@latest/code-security/concepts/code-scanning/autofix-for-code-scanning)）

**EastBraverの見立て:** PRに新しい問題を見つけるAI Scanと、既存アラートを修正してドラフトPRへ運ぶAgentic autofixは、入口も成果物も異なる。導入時は両者を一つの自動承認機能とみなさず、検出範囲、検証できないアラート、費用、マージ前の人間の判断を分けて設計する必要がある。（[Agentic autofixの発表](https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability/) / [AI Scanの発表](https://github.blog/changelog/2026-10-15-ai-scan-for-pull-requests-generally-available/)）

- 出典: [GitHub Agentic autofix](https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability/)（公式情報、2026-10-15 22:49 JST公開） / [GitHub AI Scan](https://github.blog/changelog/2026-10-15-ai-scan-for-pull-requests-generally-available/)（公式情報、2026-10-16 00:04 JST公開）

## ほかの確認済みの更新

本文と同じ方法で根拠を確認した更新を、要点だけ短くまとめる。

- **NVIDIA Nemotron 3.5 Super VLが専門エージェント向けの視覚理解を統合**：推論、ツール利用、テキスト・画像・文書・動画の理解を組み合わせるオープンウェイトモデル。NVIDIAは、コーディング、ウェブ調査、文書からの情報抽出、サイバーセキュリティなどを想定用途として挙げる。利用を検討する際は、公開されたチェックポイントと推論環境の対応を確認したい。（[NVIDIAの発表](https://developer.nvidia.com/blog/nvidia-nemotron-3-5-super-vl-powers-specialized-agents-with-multimodal-reasoning/)）
- **Muse Spark OpenをSageMaker JumpStartで提供**：BF16版とNVFP4量子化版を、自社のAWSアカウント内のSageMaker AIエンドポイントへ配置できる。提供開始時のリージョンは米国東部のバージニア北部とオハイオ。導入前にライセンスへの同意と必要なインスタンスのサービスクォータを確認したい。（[AWSの発表](https://aws.amazon.com/blogs/machine-learning/metas-muse-spark-open-now-available-in-amazon-sagemaker-jumpstart/)）
- **Granite Switch 4.1が会話・判断・音声を単一エンドポイントに統合**：IBMは8B／30Bモデルに汎用判断と安全性判断のaLoRA、文字起こし用エンコーダーを組み込む構成を紹介した。aLoRAは基盤モデルのKVキャッシュを再利用し、呼び出し側が`adapter_name`を指定するとチャットテンプレートが制御トークンを挿入する。音声は英語の文字起こしをLLMへ渡す段階構成で、音声エンコーダーとLLMの共同学習は行っていない。音声対応を多言語の直接理解と取り違えず、対象言語と選択方式を確認したい。（[IBM Graniteの発表](https://huggingface.co/blog/ibm-granite/granite-switch-4-1) / [公式モデルカード](https://huggingface.co/ibm-granite/granite-switch-4.1-8b)）
- **Perplexityがエージェント実行基盤SPACEを公開**：Computerを支えるサンドボックス基盤をApache-2.0で公開した。FirecrackerのmicroVMでLinux環境を分離し、HTTP APIでコード実行や一時停止・再開を扱う。公開されたローカル導入手順はKVMを利用できるLinux x86_64向けで、macOS上では直接実行できない。開発用の認証情報を使う構成を本番へ持ち込まないことも確認点となる。（[Perplexityの発表](https://www.perplexity.ai/hub/blog/open-sourcing-space) / [公式リポジトリ](https://github.com/perplexityai/SPACE) / [導入条件](https://github.com/perplexityai/SPACE/blob/main/docs/installation.md)）