0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

Goose Recipes 実践 — YAMLでAIエージェントの定型作業を自動化しCI/CDで回す

0
Posted at

はじめに

AI エージェントに同じ作業を毎回ゼロから指示していませんか。「このリポジトリの依存を監査して」「リリースノートを生成して」といった定型タスクは、プロンプトを書き直すたびに微妙にブレますし、チームで共有するのも面倒です。

Goose は Block が開発し、2025 年に Apache 2.0 で OSS 化したターミナル/デスクトップ両対応の AI エージェントです。本記事では、Goose の Recipes 機能にフォーカスします。Recipes は、エージェントへの指示・使うツール・パラメータをまとめた 再利用可能な YAML ワークフロー で、コマンド 1 つで実行でき、チーム共有や CI/CD への組み込みもできます。

この記事で学べること

  • Goose CLI のセットアップとプロバイダ設定
  • 動いているセッションから Recipe を生成する方法（/recipe）
  • Recipe YAML を手書きするためのスキーマの読み方
  • パラメータ化（--params）してテンプレートとして使い回す方法
  • sub_recipes で複数タスクを並列実行する方法
  • GitHub Actions で Recipe を CI として回す方法

対象読者

  • AI エージェントの定型作業を再利用・標準化したいエンジニア
  • Claude Code や Codex CLI 以外の OSS エージェントの選択肢を探している方

前提環境

  • OS: macOS / Linux（Windows は PowerShell スクリプトあり）
  • LLM プロバイダの API キー（Anthropic / OpenAI / Google など）
  • 確認に使ったバージョン: Goose CLI（stable チャネル・2026 年 6 月時点）

TL;DR

  • Recipe は「指示・ツール・パラメータ」を 1 ファイルにまとめた ポータブルな YAML ワークフロー。
  • 動いているセッションから /recipe で生成でき、ゼロから書く必要はない。
  • 実行は goose run --recipe foo.yaml、値の差し込みは --params key=value。
  • {{ variable }} のテンプレート変数でパラメータを本文に埋め込める。
  • sub_recipes で Lead エージェントが Worker を並列起動でき、バッチ処理に向く。
  • response で構造化 JSON を返せるので、CI/CD で結果を機械的に扱える。

なぜ今 Goose の Recipes なのか

Goose は 2025 年 12 月、Linux Foundation 傘下に新設された Agentic AI Foundation（AAIF） へ、Anthropic の Model Context Protocol（MCP）や OpenAI の AGENTS.md とともに寄贈が発表されました1。その後 2026 年 4 月にリポジトリも block/goose から aaif-goose/goose へ正式移管されています。特定ベンダーに縛られない中立なガバナンス下に入ったことで、長期的に使うツールとしての安心感が増しました。

Goose 自体は MCP をネイティブに扱えるエージェントで、その入門は別記事で扱っています。本記事はその一歩先、「一度作ったワークフローをどう資産化するか」 という観点で Recipes を掘り下げます。

セットアップ

1. CLI のインストール

macOS / Linux では公式のインストールスクリプトを実行します2。

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

対話的なセットアップをスキップしたい場合は CONFIGURE=false を渡します。

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | CONFIGURE=false bash

2. プロバイダの設定

LLM プロバイダと API キーを設定します。

goose configure

「Configure Providers」を選び、プロバイダ（Anthropic / OpenAI など）と API キーを入力します。キーチェーンを使いたくない環境では、環境変数で渡すこともできます。

export OPENAI_API_KEY=your_api_key

3. 動作確認

対話セッションを開始してみます。

goose session

セッションが立ち上がり、自然言語で指示を出せれば準備完了です。

Recipe を作る — まずはセッションから生成する

Recipe をゼロから YAML で書くこともできますが、最初は 動いているセッションから生成する のが手軽です。通常どおりセッションで一連の作業をこなしたあと、セッション内で次のスラッシュコマンドを実行します。

/recipe

これでセッション履歴をもとに recipe.yaml が生成されます3。生成された YAML は次のような形をしています。

version: "1.0.0"
title: "Dependency Audit"
description: "プロジェクトの依存関係を監査し、既知の脆弱性を報告する"
instructions: |
  カレントディレクトリの依存ファイルを解析し、
  既知の脆弱性と古いバージョンを一覧化してください。
prompt: "依存関係の監査レポートを Markdown で出力してください"

title と description は必須、instructions（エージェントへの指示）または prompt（ヘッドレス実行時の最初の指示）のどちらか一方が必須です。

Recipe を実行する

生成・保存した Recipe は、コマンド 1 つで実行できます。

goose run --recipe recipe.yaml

ヘッドレス（非対話）で走るため、シェルスクリプトや cron からも呼べます。これだけで「依存監査」を毎回同じ手順で再現できるようになります。

パラメータでテンプレート化する

Recipe の真価は パラメータ化 にあります。parameters でプレースホルダを定義し、本文では {{ variable }} 記法で参照します。

version: "1.0.0"
title: "Trip Planner"
description: "目的地と日数を指定して旅程を作成する"
instructions: "{{ destination }} への {{ duration }} 日間の旅程を作成してください"

parameters:
  - key: destination
    input_type: string
    requirement: required
    description: "目的地"
  - key: duration
    input_type: number
    requirement: optional
    default: "7"
    description: "旅行日数"

実行時に --params で値を渡します（複数指定するときはフラグを繰り返します）。

goose run --recipe trip.yaml --params destination=Africa --params duration=14

これで「14 日間のアフリカ旅程」が生成されます3。値を変えるだけで、同じ Recipe を別の文脈で何度でも使い回せます。

パラメータの定義項目

parameters の各エントリで指定できる主な項目は次のとおりです4。

項目 説明
key パラメータの識別子（{{ key }} で参照）
input_type string / number / boolean / date / file / select
requirement required / optional / user_prompt（実行時に対話入力）
description 用途の説明
default デフォルト値（optional のとき必須）
options select のときの選択肢

input_type: select を使うと、出力フォーマットなどを選択式にできます。

  - key: output_format
    input_type: select
    requirement: required
    description: "出力フォーマット"
    options:
      - json
      - markdown
      - csv

ツール（extensions）とモデル（settings）を固定する

Recipe には、使う MCP 拡張やモデル設定も同梱できます。これにより「この作業はこのツールとこのモデルで」という構成ごと共有できます。

extensions:
  - type: stdio
    name: codesearch
    cmd: uvx
    args:
      - mcp_codesearch@latest
    timeout: 300
    description: "コード検索ツール"

settings:
  goose_provider: "anthropic"
  goose_model: "claude-sonnet-4-20250514"
  temperature: 0.7
  max_turns: 50

extensions は Recipe 実行時に自動で読み込まれるため、利用者が手元で MCP サーバーを設定する手間が省けます。

sub_recipes で並列ワークフローを組む

大きなタスクは sub_recipes で分割できます。親（Lead）の Recipe が子（Worker）の Recipe を呼び出し、それぞれ独立したワーカープロセスで 並列実行 できます4。バッチ処理や、複数対象への同一処理に向いています。

version: "1.0.0"
title: "Multi-Repo Auditor"
description: "複数リポジトリを並列で監査する"
prompt: "各リポジトリの監査を sub_recipe で実行し、結果を集約してください"

sub_recipes:
  - name: audit_repo
    path: ./audit-repo.yaml
    values:
      repo: "service-a"

子 Recipe 側では、受け取ったパラメータを {{ repo }} のように本文で参照できます。Lead が複数の Worker を同時に走らせるため、対象数が増えても完了までの時間を抑えられます。

sub_recipes の並列実行は、それぞれが独立したプロセスで動きます。共有リソース（同じファイルへの書き込みなど）が競合しないよう、子タスクの出力先は分けておくと安全です。

CI/CD で Recipe を回す

Recipe はヘッドレスで実行できるので、GitHub Actions に組み込めば「定型作業の自動化」をそのまま CI 化できます。次は依存監査 Recipe を毎日回す例です。

name: Daily Dependency Audit

on:
  schedule:
    - cron: "0 0 * * *"
  workflow_dispatch:

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install goose
        run: |
          curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \
            | CONFIGURE=false bash
      - name: Run recipe
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          ~/.local/bin/goose run --recipe .goose/recipes/audit.yaml

API キーは Actions の Secrets に登録し、環境変数で渡します。CONFIGURE=false で対話セットアップを抑止するのがポイントです。

インストール先のパスは環境によって変わります。goose が PATH に通らない場合は、ジョブ内で which goose を確認するか、絶対パスで呼び出してください。

結果を構造化して扱う（response / retry）

CI で結果を機械的に判定したいときは、response で JSON スキーマ を指定すると、エージェントの出力を構造化された JSON で受け取れます4。

response:
  json_schema:
    type: object
    properties:
      findings:
        type: array
        items:
          type: string
      severity:
        type: string
    required:
      - findings

また retry を使えば、出力が条件を満たさないときに自動リトライをかけられます。

retry:
  max_retries: 2
  timeout_seconds: 30
  checks:
    - type: shell
      command: "test -f output.json"

checks のシェルコマンドが成功するまで（上限回数まで）リトライするため、「ファイルが生成されていなければやり直す」といった検証付き実行が書けます。

ハマりポイント

instructions と prompt の使い分け

instructions はエージェントの振る舞いを定義するシステム指示、prompt はヘッドレス実行時に投げる最初のメッセージという位置づけです。対話で使うなら instructions、goose run で一発実行するなら prompt を中心に設計すると意図どおり動きやすいです。最低どちらか一方は必須なので、空のまま保存しないよう注意します。

optional パラメータには default が要る

requirement: optional のパラメータに default を付け忘れると、値が解決できずに実行が止まることがあります。任意にするなら必ずデフォルト値を添えます。

リポジトリ名の移行

block/goose 由来の古い URL を参照しているスクリプトやブックマークは、aaif-goose/goose に向け直しておくと、リリース取得などで詰まりません。

まとめ

  • Goose の Recipe は、AI エージェントの定型作業を YAML 1 ファイル に固めて再利用・共有・CI 化するための仕組みです。
  • まずは /recipe でセッションから生成し、parameters と {{ variable }} でテンプレート化するのが実践的な入り口です。
  • sub_recipes の並列実行と response の構造化出力を使えば、単発の便利コマンドから一歩進んで、チームの自動化パイプラインの部品にできます。

「毎回同じことを AI に頼んでいる」と感じたら、その指示を Recipe に切り出すところから始めてみてください。

参考リンク

  1. Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)（MCP・goose・AGENTS.md の寄贈を発表） ↩

  2. goose Installation ↩

  3. goose Recipes Guide および Recipes Tutorial ↩ ↩2

  4. Recipe Reference Guide ↩ ↩2 ↩3

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?