【2026年最新】GooseでAIエージェントを無料構築する5ステップ完全ガイド

「Claude CodeやCursorに月数千円払っているけど、本当にこれでいいのか？」と思ったことはないだろうか。

Block（旧Square）が開発し、現在はLinux FoundationのAgentic AI Foundation（AAIF）が管理するオープンソースAIエージェント「Goose」は、GitHubで46,000以上のスターを集めながら完全無料で使えるローカル動作エージェントだ。インストールから自律タスク実行まで15分もあれば動かせる。

本記事では、GooseをゼロからセットアップしてRecipes・サブエージェント・MCP連携まで活用するための5ステップ完全ガイドを解説する。Gooseが向いているケースと向いていないケースも正直に書くので、導入判断の材料としてほしい。

Gooseとは何か——Block製OSSエージェントの全体像

Gooseは「コード補完ツール」ではなく、「オンマシン自律エージェント」と位置づけられている。ファイルの作成・編集・テスト実行・依存関係のインストール・APIの呼び出しまで、人間が承認を与えた範囲内で自律的にタスクを完遂する。

📊 関連比較：主要12ツールを料金・コンテキストウィンドウ・OSS度・用途の4軸で横並びにした【2026年最新】AIエージェントツール完全比較12選｜用途・料金・選び方ガイドも併せて参照してください。

開発元のBlockは、決済サービス「Square」や仮想通貨ウォレット「Cash App」を手掛けるJack Dorsey創業の企業だ。2024年末に「codename goose」としてOSS化され、2025年12月にLinux FoundationのAAIFに移管された。同時にAnthropicのMCPとOpenAIのAGENTS.mdも同財団に参加しており、AIエージェント業界の共通インフラを作る動きの中核プロジェクトである（参照：Block Open Source Blog、参照日: 2026-06-04）。

Gooseの5つの特徴

1. 完全無料・Apache 2.0ライセンス：LLMのAPI利用料のみで使える。サブスクリプション不要
2. 25以上のLLMプロバイダー対応：Anthropic、OpenAI、Google、Ollama、Mistral、Azure、Bedrock、OpenRouterなど。完全なBYOM（Bring Your Own Model）
3. MCP経由で3,000以上のツール連携：GitHub、Jira、Slack、Google Drive、データベースなど。MCPサーバーが増えるたびに自動的にGooseの能力も拡張される
4. Recipes機能：複雑なマルチステップワークフローをYAMLで定義し、チーム内で共有・CI/CDに組み込める
5. 並列サブエージェント：独立したワークスペースで複数タスクを同時処理できる

最新版の状況（2026年6月時点）

2026年6月3日時点の最新バージョンはv1.37.0。GitHubスター数は46,400超、フォーク数4,800超で、400名以上のコントリビューターが活発に開発を続けている（参照：aaif-goose/goose on GitHub、参照日: 2026-06-04）。

Step 1: インストール——3つの方法から選ぶ

Gooseには「CLI版」「デスクトップアプリ版」「Homebrew版」の3つのインストール方法がある。用途に応じて使い分けよう。

インストール方法1: CLIスクリプト（最速・推奨）

ターミナルから1コマンドでインストールできる。macOS・Linux・Windows（WSL経由）対応。

# インストール（macOS/Linux）
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# インストール確認
goose --version
# goose v1.37.0

# 初回セットアップ
goose configure

goose configureを実行するとインタラクティブなウィザードが起動し、LLMプロバイダーの選択とAPIキーの設定ができる。

インストール方法2: Homebrew（macOS向け）

# Homebrewで最新安定版をインストール
brew install block/tap/goose

# アップデート
brew upgrade block/tap/goose

インストール方法3: デスクトップアプリ

GUIでGooseを使いたい場合は、GitHub Releasesページから最新版のデスクトップアプリをダウンロードする。macOS（Intel/M系）、Windows、Linuxに対応。初回起動時にプロバイダー設定のウィザードが表示される。

動作確認：最初のGooseセッション

# 新しいセッションを開始
goose session

# セッション内でタスクを指示（例）
# あなた: "src/ディレクトリをスキャンして、未使用のimport文をすべて削除したPythonファイル一覧を作成してください"

# セッションを名前付きで保存
goose session --name "refactoring-2026-06"

# 保存したセッションを再開
goose session --resume "refactoring-2026-06"

Step 2: プロバイダー設定——どのLLMを使うか決める

Gooseの真価は「自分のAPIキーを使って好きなLLMを接続できる」点にある。設定ファイルは ~/.config/goose/config.yaml に保存される。

基本設定ファイル（config.yaml）

# ~/.config/goose/config.yaml

# デフォルトプロバイダー設定
GOOSE_PROVIDER: anthropic
GOOSE_MODEL: claude-sonnet-4-5

# 利用可能なプロバイダー例:
# anthropic, openai, google, ollama, mistral, openrouter

# 会話履歴の最大トークン数（コスト管理）
max_tokens: 8192

# ツール呼び出しのタイムアウト（秒）
tool_timeout: 120

Anthropic（Claude）を使う場合

# 環境変数でAPIキーを設定
export ANTHROPIC_API_KEY="your-anthropic-api-key"

# または .zshrc / .bashrc に永続化
echo 'export ANTHROPIC_API_KEY="your-anthropic-api-key"' >> ~/.zshrc
source ~/.zshrc

# セッション起動時にプロバイダーを指定
goose session --provider anthropic --model claude-opus-4-5

Ollama（ローカルLLM）を使う場合

インターネット接続なし・プロンプトを外部に送らないローカル環境での実行も可能だ。

# Ollamaのインストール（別途必要）
curl -fsSL https://ollama.ai/install.sh | sh

# モデルのダウンロード（例：llama3.3）
ollama pull llama3.3:latest

# GooseでOllamaを使う
export OLLAMA_HOST="http://localhost:11434"
goose session --provider ollama --model llama3.3:latest

カスタムプロバイダー（社内APIエンドポイント等）

社内に立てたOpenAI互換エンドポイントや、Azure OpenAIを使う場合はカスタムプロバイダー設定を使う。

// ~/.config/goose/custom_providers/corp_api.json
{
  "name": "corp_api",
  "engine": "openai",
  "display_name": "Corporate LLM Gateway",
  "api_key_env": "CORP_API_KEY",
  "base_url": "https://llm-gateway.example.com/v1/chat/completions",
  "models": [
    {"name": "gpt-4o", "context_limit": 128000},
    {"name": "gpt-4o-mini", "context_limit": 128000}
  ],
  "headers": {
    "x-origin-client-id": "goose-dev"
  },
  "supports_streaming": true,
  "requires_auth": true
}

# カスタムプロバイダーを使ってセッション開始
export CORP_API_KEY="your-corp-api-key"
goose session --provider corp_api --model gpt-4o

Step 3: MCP拡張機能の追加——3,000のツールをGooseに接続する

Gooseの最大の強みはMCP（Model Context Protocol）を通じた拡張性だ。MCPサーバーが増えるたびにGooseが使えるツールも自動的に増える。2026年6月時点でMCPサーバーのレジストリには3,000以上のエントリがある（参照：PulseMCP、参照日: 2026-06-04）。

基本的なMCPサーバーの追加方法

# インタラクティブウィザードで追加
goose configure
# → "Add Extension (MCP Server)" を選択

# または直接 config.yaml に記述
# ~/.config/goose/config.yaml

# ~/.config/goose/config.yaml（MCP設定を追加）
extensions:
  # GitHub MCP（PRレビュー・Issue管理）
  - name: github
    type: stdio
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"

  # Filesystem（ファイル操作強化）
  - name: filesystem
    type: builtin

  # Developer（コード実行・シェル操作）
  - name: developer
    type: builtin

  # Google Drive（ドキュメント読み取り）
  - name: gdrive
    type: stdio
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-gdrive"]

組み込み拡張機能（builtin）の一覧

Gooseには以下の組み込み拡張機能がデフォルトで含まれている。

拡張機能名	機能概要	主な用途
developer	コード実行・シェルコマンド・ファイル編集	開発タスク全般
filesystem	ファイルシステムの読み書き・検索	ファイル操作
computercontroller	スクリーンショット・クリック・キー入力	GUI自動化
memory	会話コンテキストの長期保存	継続作業
jetbrains	JetBrains IDEとの連携	IntelliJ/PyCharm統合
todo	タスクリスト管理	複数ステップタスク管理

Step 4: Recipesの作成——チームで共有できるワークフローを定義する

RecipesはGoose最大のキラー機能だ。「複雑な手順を毎回説明する」のではなく、YAML形式でワークフローを定義しておけば、チームメンバーが1コマンドで同じ処理を実行できる。CI/CDパイプラインへの組み込みも可能だ。

Recipesの基本構造

# recipes/code-review.yaml
version: 1.0.0
title: "PRコードレビュー自動化"
description: "GitHubのPRを取得し、セキュリティ・品質・パフォーマンスの観点でレビューします"

# 使用する拡張機能（MCPサーバー）
extensions:
  - type: builtin
    name: developer
  - type: stdio
    name: github
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"

# パラメーター（実行時に渡す変数）
parameters:
  - key: pr_number
    input_type: string
    requirement: required
    description: "レビューするPR番号（例: 123）"
  - key: repo
    input_type: string
    requirement: required
    description: "リポジトリ名（例: myorg/myapp）"
  - key: focus
    input_type: string
    requirement: optional
    default: "security,performance,maintainability"
    description: "レビューの重点項目"

# 実行指示（Gooseへのシステムプロンプト）
instructions: |
  あなたはシニアソフトウェアエンジニアです。
  提供されたPRを以下の観点でレビューしてください：
  - セキュリティ脆弱性（SQLインジェクション・XSS・認証不備など）
  - パフォーマンス問題（N+1クエリ・メモリリーク・不要なループ）
  - コード品質（命名・コメント・テストカバレッジ）
  - 各問題には severity（critical/major/minor）を付けてください

  フォーカス領域: {{focus}}

# 初期プロンプト
prompt: |
  リポジトリ {{repo}} のPR #{{pr_number}} をレビューしてください。
  変更差分を取得し、上記の観点で問題点を特定して、
  Markdownのレビューレポートを作成してください。

# Recipeの実行
goose run --recipe ./recipes/code-review.yaml 
  --params pr_number=456,repo=myorg/myapp,focus=security

週次開発レポート生成Recipe（実践例）

実際に私たちが使っているRecipeの例を紹介する。GitHubのマージ済みPR一覧とLinearのタスク完了履歴を取得し、Notionに週次サマリーを自動作成するワークフローだ（週45分かかっていた作業が5分に短縮された）。

# recipes/weekly-report.yaml
version: 1.0.0
title: "週次開発レポート生成"
description: "GitHub + Linear → Notionへの週次サマリー自動生成"

extensions:
  - type: builtin
    name: developer
  - type: stdio
    name: github
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"
  - type: stdio
    name: linear
    cmd: npx
    args: ["-y", "mcp-linear"]
    env:
      LINEAR_API_KEY: "${LINEAR_API_KEY}"
  - type: stdio
    name: notion
    cmd: npx
    args: ["-y", "@notionhq/notion-mcp-server"]
    env:
      NOTION_API_KEY: "${NOTION_API_KEY}"

parameters:
  - key: week_start
    input_type: string
    requirement: required
    description: "週の開始日（YYYY-MM-DD形式）"
  - key: team
    input_type: string
    requirement: optional
    default: "all"
    description: "対象チーム名"

instructions: |
  週次レポートを生成するAIアシスタントです。
  指定期間のデータを収集し、経営陣向けの簡潔なサマリーを作成します。

prompt: |
  {{week_start}} から始まる1週間の開発レポートを作成してください。
  1. GitHubからmerge済みのPR一覧を取得（チーム: {{team}}）
  2. Linearから完了したタスクを取得
  3. 技術的ハイライト・完了機能・ブロッカーをまとめる
  4. Notionの「週次レポート」データベースに新しいページを作成して内容を投稿する

Step 5: 並列サブエージェントで処理を高速化する

Gooseはサブエージェントを使って複数のタスクを並列実行できる。これは2026年のアップデートで強化された機能で、大規模なコードベースのリファクタリングやマルチリポジトリの同時作業で特に効果が大きい。

サブエージェントの基本的な呼び出し方

セッション内でGooseに対して「並列でやって」と指示すると、Gooseは自動的に独立したサブエージェントを生成する。以下は明示的に並列実行を指示するプロンプト例だ。

# セッション開始
goose session

# 並列タスクの指示例
# "以下の3つのタスクを並列で実行してください：
#  1. src/api/ディレクトリの全Pythonファイルをスキャンして、
#     型アノテーションが不足している関数の一覧を作成する
#  2. tests/ディレクトリのカバレッジレポートを生成する
#  3. requirements.txtの依存ライブラリの脆弱性チェックを実行する"

複数セッションの並列起動（上級者向け）

CLI版では複数のセッションを別ターミナルから並列起動して、独立したタスクを同時処理できる。

# ターミナル1: バックエンドのリファクタリング
goose session --name "refactor-backend" <<'EOF'
src/api/ ディレクトリの全エンドポイントをFlaskからFastAPIに移行してください。
型アノテーションを追加し、pytestのテストケースも更新してください。
EOF

# ターミナル2: フロントエンドの型チェック修正（別タスク）
goose session --name "fix-typescript" <<'EOF'
frontend/src/ 内のTypeScriptエラーをすべて修正してください。
tsc --noEmit を実行してエラー一覧を取得し、順番に修正してください。
EOF

# 両セッションの完了を確認
goose session list

エラーハンドリング：GooseはツールエラーをLLMに返す

Gooseのアーキテクチャでは、ToolUseとToolResultの両方が Result<T, AgentError> として扱われる。ツール呼び出しがエラーを返すと、そのエラーメッセージをLLMに見せて自己修正を促す仕組みになっている（参照：DEV Community – Goose SRE Agent、参照日: 2026-06-04）。

# エラー時の自動リトライを確認するセッション例
goose session

# GooseはこういったエラーをLLMに渡して自己修正する：
# [Tool Error] bash: pytest: command not found
# → LLMは自動的に `pip install pytest` を実行して再試行する

# [Tool Error] FileNotFoundError: config.json not found
# → LLMは自動的にファイルを作成するか、別のパスを探す

# タイムアウト設定（長時間タスク向け）
# config.yaml の tool_timeout を調整する
# tool_timeout: 300  # 5分に延長

Gooseを他のエージェントと正直に比較する

Gooseが万能かというと、そうではない。他のツールと比較した実際の強み・弱みを整理する。

比較項目	Goose	Claude Code	Cline	Aider	Continue.dev
価格	無料（API料金のみ）	$20/月〜	無料（API料金のみ）	無料（API料金のみ）	無料（API料金のみ）
動作環境	デスクトップアプリ・CLI	ターミナル（CLI）	VS Code拡張	CLI	VS Code/JetBrains拡張
LLM対応	25以上（BYOM完全対応）	Claude系のみ	15以上（BYOM対応）	多数（BYOM対応）	多数（BYOM対応）
MCP統合	70以上の公式拡張・3,000以上のサーバー	MCP対応（限定的）	MCP対応・コスト追跡付き	なし（Git統合中心）	MCP対応
Recipes/ワークフロー	YAML定義・CI/CD連携可	なし	なし	なし	なし
IDE統合	スタンドアロン（JetBrains拡張あり）	ターミナル	VS Code完全統合	ターミナル	VS Code/JetBrains完全統合
コーディング精度	使用モデル依存（Claude使用時は高い）	非常に高い（Claude最適化）	高い	高い（Git-based）	中〜高（補完特化）
ローカル実行	Ollama経由で完全ローカル可	不可	ローカル対応	ローカル対応	ローカル対応
SWE-Bench性能	低い（3-10%・デフォルト設定時）	高い（Claude Opus 4: 80.8%）	中（使用モデル依存）	中（使用モデル依存）	補完特化のため非該当
並列サブエージェント	対応（2026年強化）	非対応	非対応	非対応	非対応

GooseはどんなケースでClaude Codeより優位か

SWE-Benchのスコアだけ見るとGooseのデフォルト設定は低い。ただし、これは「Gooseをどのモデルで動かすか」によって大きく変わる。GooseにClaude Opus 4を乗せれば精度はClaude Codeと同等になる。Gooseが優位なのは以下のケースだ：

• 複数ツールをまたぐワークフロー自動化：GitHub + Jira + Slack + DBをまたぐ処理はGooseのMCP連携が圧倒的に優位
• チームで再現性の高いタスクを共有したい：RecipesをGitリポジトリに入れてチームで管理できる
• コストを最小化したい：月額固定費なしで、APIコストだけ払う
• プロンプトや出力を外部に出したくない：Ollama経由でローカルLLMを使えば完全にオフライン
• IDE以外のアプリケーション自動化：computercontroller拡張でGUI操作も自動化できる

よくある失敗パターンと回避策

失敗パターン1：MCPサーバーが起動しない

GooseのMCP拡張でよくある問題は「npxコマンドが見つからない」「Node.jsのバージョンが古い」というエラーだ。

# NG：よくあるエラー
# [Extension Error] Error: spawn npx ENOENT
# → Node.jsとnpmがインストールされていない

# OK：Node.jsのインストールと確認
node --version  # v18.0.0以上が必要
npm --version   # v8.0.0以上が必要

# もしくはnvmで最新版をインストール
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
nvm install --lts
nvm use --lts

# MCP拡張のデバッグ
goose configure --debug
# → 拡張機能の起動ログが表示される

失敗パターン2：config.yamlのパスを間違える

GooseのOSごとの設定ファイルパスを間違えると、設定が反映されない。

# OSごとの正しい設定ファイルパス
# macOS / Linux:
~/.config/goose/config.yaml

# Windows:
%APPDATA%Blockgooseconfigconfig.yaml

# カスタムプロバイダーの格納先
# macOS / Linux:
~/.config/goose/custom_providers/

# Windows:
%APPDATA%Blockgooseconfigcustom_providers

# 設定が正しく読み込まれているか確認
goose configure --list-providers

失敗パターン3：Recipeのパラメーターが渡されない

Recipeのパラメーター名と --params で渡す名前を一致させないと、デフォルト値が使われたり実行エラーになる。

# NG：パラメーター名の不一致
goose run --recipe code-review.yaml --params prNumber=456
# → pr_numberではなくprNumberを渡しているため、必須パラメーターが欠けているエラー

# OK：YAMLで定義したkeyと完全一致させる
# Recipe内: key: pr_number
goose run --recipe code-review.yaml --params pr_number=456,repo=myorg/myapp

# 複数パラメーターはカンマ区切り
goose run --recipe weekly-report.yaml 
  --params week_start=2026-06-01,team=backend

失敗パターン4：ローカルLLMのメモリ不足でクラッシュ

Ollamaでローカルモデルを動かす場合、70Bパラメーター以上のモデルには48GB以上のRAMが必要になる。

# NG：大きすぎるモデルを選択してOOM
ollama pull llama3.3:70b  # 70Bモデルは約40GBのVRAM/RAM必要

# OK：マシンスペックに合ったモデルを選ぶ目安
# 8GB RAM:  phi3:3.8b, gemma2:2b
# 16GB RAM: llama3.2:8b, mistral:7b
# 32GB RAM: llama3.1:13b, codestral:22b
# 48GB RAM: llama3.3:70b, qwen2.5:72b

# モデルのサイズ確認
ollama list

# GooseでOllama使用時の推奨設定
goose session --provider ollama --model llama3.2:8b

本番運用のためのセキュリティと運用設計

Gooseをチームで使う場合、セキュリティ設計は事前に決めておく必要がある。

プロンプトインジェクション対策

GooseはWebから情報を取得して処理することがある。悪意ある入力がエージェントの行動を変えるプロンプトインジェクション対策として、Gooseには承認フローの設定がある。

# ~/.config/goose/config.yaml

# 破壊的なコマンドの実行前に確認を求める
safety:
  require_approval_for:
    - "rm -rf"
    - "DROP TABLE"
    - "git push --force"
    - "kubectl delete"

# 外部ネットワーク接続を許可しないプロファイル（ローカル開発専用）
network:
  allow_external: false  # trueにすると外部APIへのアクセスを許可

シークレット管理

APIキーをconfig.yamlに直接書かない。環境変数または1Passwordなどのシークレット管理ツールと連携させる。

# NG：APIキーをconfig.yamlに直書き
# ANTHROPIC_API_KEY: sk-ant-xxxx  ← Gitにコミットされるリスク

# OK：環境変数経由で管理
export ANTHROPIC_API_KEY="$(op read 'op://vault/anthropic/api-key')"
export GITHUB_TOKEN="$(op read 'op://vault/github/token')"

# .envファイルを使う場合は .gitignore に必ず追加
echo ".env" >> .gitignore

チームへの導入：Recipesをリポジトリで管理する

# チームリポジトリ構造の例
myproject/
├── .goose/
│   ├── config.yaml        # プロジェクト固有のGoose設定
│   └── recipes/
│       ├── code-review.yaml
│       ├── weekly-report.yaml
│       ├── deploy-check.yaml
│       └── security-scan.yaml
├── src/
└── README.md

# プロジェクトのGoose設定を使ってセッション開始
cd myproject
goose session --config .goose/config.yaml

Gooseが本当に向いているケース・向いていないケース

ここまで実践的な内容を解説してきたが、Gooseが万能ではないことも正直に伝えておく。

Gooseが強いケース

• 複数ツールをまたぐ定型ワークフロー：GitHub・Slack・Notion・Jiraをまたぐ週次レポートや障害対応フローは、RecipesとMCPの組み合わせで一番効果が出る
• コストを抑えながらエージェントを試したい：月額固定費なし。Claude Sonnetを使っても1日10タスク程度なら数百円以下
• 社内のプロプライエタリモデルや社内APIを使いたい：カスタムプロバイダー機能で社内LLMゲートウェイに接続できる
• プロンプトや出力をクラウドに送りたくない：Ollama経由の完全ローカル実行が可能
• チームでエージェントワークフローを共有・標準化したい：RecipesをGitで管理してCI/CDに組み込める

Gooseが向いていないケース

• VS Code/IntelliJに完全統合されたコード補完が欲しい：IDE内補完はClineやContinue.devの方が優れている
• すぐに最高品質のコーディングをしたい：Anthropic最適化されたClaude Codeの方が単純なコーディングタスクは速くて精度が高い（SWE-Bench 80.8% vs Gooseデフォルト3-10%）
• GitのコンテキストをAIに深く理解させたい：Aiderはgit diffやgit logを深く統合しているため、リポジトリ全体の変更履歴ベースの作業に向いている
• ローカルマシンスペックが低い（16GB RAM未満）：Ollama経由のローカルLLMは16GB未満では品質が出ない。その場合はクラウドAPIを使うことになり、Gooseを選ぶメリットが減る

まとめ：今日から始める3つのアクション

GooseはClaude Codeの完全な代替ではないが、「複数ツールをまたぐワークフロー自動化」と「チームでのRecipes共有」の領域では圧倒的に優れている。月額固定費なしで試せるので、まず動かしてみることを強く勧める。

1. 今日：インストールして最初のセッションを動かす
   curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash && goose configure でインストールし、1つのタスクを自動化してみる
2. 今週中：チームの定型タスクを1つRecipeにする
   週次レポート・PR通知・デプロイ確認など、毎週やっていることをRecipes化して goose run 1コマンドで実行できるようにする
3. 今月中：MCPサーバーを1つ追加して連携を拡張する
   GitHub・Jira・Slack・Notionのいずれか使っているツールのMCPサーバーを追加し、ツールをまたいだ自動化を実現する

参考・出典

• aaif-goose/goose — GitHub公式リポジトリ（参照日: 2026-06-04）
• Goose公式ドキュメント（参照日: 2026-06-04）
• Goose Documentation（Mintlify）（参照日: 2026-06-04）
• Block Open Source — codename gooseの紹介（参照日: 2026-06-04）
• Goose vs Claude Code — MCP Extensions & Setup Guide 2026（参照日: 2026-06-04）
• Goose vs Claude Code — Techbuddies Studio（参照日: 2026-06-04）

---