Diary of a Perpetual Student

Perpetual Student: A person who remains at university far beyond the normal period

GoReleaserをgoreleaser-action経由で使うか、go tool経由で使うか

様々な環境(OS・CPUアーキテクチャ)向けのインストールパッケージやDockerイメージを提供しなければならない、例えばCLIツールのようなものをGo言語で作るとき、多くの人がGoReleaserを利用しているでしょう。

goreleaser.com

GoReleaserは動作検証のために手元で動かすこともありつつ、ほとんどのユースケースではGitHub ActionsなどのCIツール上で動かすでしょう。(リリースが手動の場合には手元で動かすのがメインの人もいるかもしれませんね。)

GitHub Actions上でGoReleaserを利用するとき、ドキュメントに従うとgoreleaser/goreleaser-actionというaction経由でGoReleaserをインストール・起動することになります。

一方、Go 1.24でgo.modにtoolディレクティブが追加されたことで、generate.goファイルを利用していたワークアラウンドに代わって、開発に利用するGo製ツールを管理できるようになりました。これでGoReleaserもgoのToolsの管理下に入れて呼び出す選択肢も浮上しました。

このエントリではGitHub Actions上でGoReleaserを利用する2つの手法を比較します。

goreleaser-action経由で使う

ドキュメント通りに以下のようなGitHub Actionsのワークフロー定義を構築するだけです。

jobs:
  goreleaser:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0
      - uses: actions/setup-go@v5
      - name: Run GoReleaser
        uses: goreleaser/goreleaser-action@v6
        with:
          version: '~> v2'
          args: release --clean

メリットは、公式で案内されている手法で安心感があることです。コンパイル済みのバイナリを持ってくるので、セットアップにかかる時間も比較的高速です。

デメリットは、利用するGoReleaserのバージョンの宣言がGitHub Actions側に寄ることです。CIで利用しているGoReleaserのバージョンと手元のバージョンを仕組みで揃えるのが厳しくなります。

go tool経由で使う

go.modのtoolディレクティブに以下のように記述します。GoReleaserは現在v2なのでメジャーバージョンの指定も必要なことに注意してください。

tool github.com/goreleaser/goreleaser/v2

go toolコマンド経由でGoReleaserを呼び出せます。

$ go tool goreleaser --version
  ____       ____      _
 / ___| ___ |  _ \ ___| | ___  __ _ ___  ___ _ __
| |  _ / _ \| |_) / _ \ |/ _ \/ _` / __|/ _ \ '__|
| |_| | (_) |  _ <  __/ |  __/ (_| \__ \  __/ |
 \____|\___/|_| \_\___|_|\___|\__,_|___/\___|_|
goreleaser: Release engineering, simplified.
https://goreleaser.com

GitVersion:    v2.12.7
GitCommit:     unknown
GitTreeState:  unknown
BuildDate:     unknown
BuiltBy:       unknown
GoVersion:     go1.25.3
Compiler:      gc
ModuleSum:     h1:C2EgMDSQQvFpaZwA4L7JuopZzrvvNuVvdHA52AyCT0M=
Platform:      darwin/arm64

あとは、CIで実際に利用したいGoReleaserの(go toolを経由した)コマンド呼び出しを、GitHub Actionsのワークフロー定義に入れていきます。

jobs:
  goreleaser:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0
      - uses: actions/setup-go@v5
      - name: Run GoReleaser
        run: go tool goreleaser release --clean

メリットは、GitHub Actionsでも手元でも同じGoReleaserのバージョンに揃えられることです。

GoReleaserは2024年にメジャーバージョンがv2となり、このタイミングで破壊的な変更が入っています。また、現在も継続的に開発が続けられており、新たな設定が利用可能になったり、元々使えていた設定が非推奨になったりする変化があります。GoReleaserのバージョンをgo.modで宣言・集約的に管理できることには一定の価値があります。

また、GitHub Actionsに依存しないやり方なので、GitLabなど他のCIツールでも同じように利用できるはずです。

デメリットは、CI環境でのGoReleaserインストールが遅いことです。setup-go actionのキャッシュがツールのバイナリにも効くと期待していたのですが、そうではなさそうです。GitHub Actions上で実行したところ、installフェーズに1分30秒ぐらいかかりました。

さらにもう一つ致命的なデメリットがあります。go.modのtoolディレクティブで管理しているツールのgo.modに書かれているgoディレクティブは、自分たちのモジュールのgo.modにも影響を及ぼします。例えば、元々の自分たちのgo.modにgo 1.24と書かれていても、現時点で最新のGoReleaser v2を依存に加えてしまうとgo 1.25.1に勝手に上げられてしまいます。

これは、バイナリを提供しつつライブラリとしての機能も果たすようなプロジェクトで特に困ります。なぜなら、そのモジュールに依存したソースコードをビルド可能なGoのバージョンが引き上げられてしまうからです。Go言語では直近2つのメジャーリリースがサポートされていますが、先ほどの例だと、そのモジュールはサポート下のGo 1.24の環境では利用できなくなるということです。

go.modのセマンティクスとしては、goディレクティブはコンパイル可能な最低限のバージョン、toolchainディレクティブは推奨されるツールチェーンバージョンを表します。しかし、ツール提供だけを目的としたモジュールではこの区別をせず、単にgoディレクティブを最新に近いバージョンに設定していることがあります。GoReleaserもその一つです。setup-go actionでgo-version-fileにgo.modを指定するとgoディレクティブを読んでバージョンを決める機能があることもこの状況を助長していると感じています。

所感

特にこだわりがなければ、公式が案内しているgoreleaser-actionを利用するやり方が無難で良いと思います。

CIが多少遅くてもよく、ビルド可能なGoバージョンの下限が上がっても構わないなら、手元でもCIでも同じGoReleaserを使えるというメリットを取って、go tool経由で利用するのもアリかもしれません。

tools.goを利用したツール管理の慣習をgo.modのtoolディレクティブに置き換えるツールとその実装

Go言語のtools.goを利用したツール管理の慣習を、go.modのtoolディレクティブに置き換えるツールを作ったのでご紹介します。

前提知識

Go言語にはGoで書かれたバイナリをインストールできるgo installコマンドという仕組みがあります。golangci-lintなど開発に利用するCLIツールをバージョン固定して各開発環境でインストールさせるために、ビルドタグをつけたtools.goというファイルを作ってblack importし、go.modの依存管理に加えるというハックがありました*1

//go:build tools

package tools

import (
    _ "golang.org/x/tools/cmd/stringer"
)

github.com

Go 1.24からはgo.modにtoolディレクティブが登場しました。これにより、ハックに頼らずGo Modulesで正式に開発ツールを管理できるようになりました。

go.dev

先ほどのtools.goの例を置き換えるとすると、go.modに以下のようにtoolディレクティブの記述をすることになります。

 module sample
 
 go 1.24.0
 
+tool golang.org/x/tools/cmd/stringer

 require golang.org/x/tools v0.37.0

 require (
    golang.org/x/mod v0.28.0 // indirect
    golang.org/x/sync v0.17.0 // indirect
    golang.org/x/sys v0.36.0 // indirect
    golang.org/x/telemetry v0.0.0-20250908211612-aef8a434d053 // indirect
 )

また、登録したツールはgo tool stringerのような形で呼び出すことができ、バージョン管理とは別にインストールのためにgo installしていたのは不要になります。

tools.goからtoolディレクティブへの置き換えを自動化

以下のようなXのポストを見かけました。

この置き換えはそこまで大変なものではないのですが、自動化するツールがあったら面白いだろうなと思って作ってみました。なお、私は世の中に他のソリューションがあるかどうかを確認していません。

github.com

使い方としては、まずはgo-tools-migratorをgo installで導入してください*2

go install github.com/Arthur1/go-tools-migrator/cmd/go-tools-migrator@latest

go.modとtools.goがあるフォルダで、以下のようにコマンドを呼び出すと、tools.goの中身を見て、必要なものをgo.modのtoolディレクティブに追加してくれます。また、不要になったtools.goは削除します。

$ go-tools-migrator
✅ Succeeded to migrate.

ファイルが別の場所にある場合など、発展的な使い方をしたい人は以下のヘルプを見てください。

$ go-tools-migrator -h
Usage: go-tools-migrator [flags]

go-tools-migrator: a CLI tool that replaces tools management via tools.go with go.mod tool directive.

Flags:
  -h, --help                        Show context-sensitive help.
  -v, --version                     Print version and quit
      --dryrun                      Output the contents of the new go.mod without modifying existing files.
      --tools-go-file="tools.go"    tools.go file path (default: tools.go)
      --go-mod-file="go.mod"        go.mod file path (default: go.mod)

実装

まずはtools.goを読んで静的解析し、importしているものを取り出します。

📄 internal/gotool/gotool.go#L49-L70

import文の静的解析については以前もこのブログで取り上げています。

blog.arthur1.dev

ちゃんと実装するなら、importしているものが単なるpackageでなく実行可能なprogramなのかを判定できたら堅牢になるかもしれません。golang.org/x/tools/go/packagesを使ってpackage名を取得して、それがmainだったら実行可能である、という判定ができそうな気がしますが、未実装です。

次に、go.modを読んで、足りないtoolディレクティブを足していきます。go.modの構文を守って書き込む時にはどうしたらいいかというと、golang.org/x/mod/modfileという便利packageがあるので使います。

📄 internal/gotool/gotool.go#L72-L88

読み込んだgo.modをmodfile.File構造体に変換して、用意されているAPIを使ってgo.modを編集していきます。toolディレクティブの内容を追加するFile.AddTool関数は、すでに存在するものを再度渡しても何も起こらないとドキュメントに書いてあるので、細かいことを考えずにtools.goから得た依存関係を順にAddToolに渡すだけで良いです。

AddToolなどを呼んでも元のgo.modファイルが直接編集されるわけではありません。File.Formatを呼ぶことで、編集後のgo.modの内容を[]byte型で得ることができます。

あとは、go.modファイルの中身をFormatで得た新たなgo.modの内容に置き換えられれば良いです。しかし、go.modをtruncateした後にファイルの書き込みに失敗するとgo.modの内容が失われてしまいます。そこで、シェルの>リダイレクトのような操作をatomicに行えるライブラリを利用しています。

github.com

📄 internal/gotool/gotool.go#L31-L43

他にも、Immutable Releaseを採用したり、CI周りでこだわっていたりするので、本体の実装以外のコードも眺めてみてください。

最後に宣伝

2025-10-31(金)、弊社でGo言語の勉強会やるのでぜひいらしてください。公募LT枠もありますよ〜。

connpass.com

*1:ビルドタグ名もファイル名もパッケージ名も本質的にはなんでも良いはずなのですが、慣習として多くの人がこういう命名をしているという事実はあったはずです。go.devのWikiにも載っていた手法ですし。

*2:もちろんtoolディレクティブで導入してもらっても構いません。

大吉祥寺.pm 2025でマイクの話をして、ナイトパーティーでDJをしました

大吉祥寺.pm 2025

大吉祥寺.pm 2025に「【実演版】カンファレンス登壇者・スタッフにこそ知ってほしいマイクの使い方」という発表で登壇しました。ほぼ同タイトルのエントリを過去に書いていて、この内容を実演を交えて紹介するという内容です。

blog.arthur1.dev

実はプロポーザル形式で採択されたのPHP Conference Japan 2023ぶりでした。この話は然るべきところに出せば通るという自信はあったので、切り札をついに切ってしまったという気持ちです。

実演版ということで資料だけ見ても微妙かもしれないですが、置いておきます。

speakerdeck.com

LTの5分という制約のもとで実演するにあたって、手が足りないと感じたため、前夜祭でデロ(@dero1to)さんにお声がけし、実演の助手をやってもらいました。「機内安全ビデオみたいで面白い」と予想外に笑いをとれたのが良かったです。

嬉しかったことは、自分の発表の直後に発表したなってぃ(@natty_natty254)さんが早速完璧な形で実践されていたことです。その他の技術も合わさってとても聞き取りやすい発表になっていました。

また、Xやブログなどで、発表を見ていただいた多くの方に言及してもらっているのを観測しています。ありがとうございます。まだ全部追えてないので、一つ一つゆっくり確認させていただきます。

嬉しくなかったことは、クロージングのベストLT賞の発表のときに、マイクを叩かれてしまったことです。マイクを叩かないでと話した自分が選ばれないことを察してしまったので。まあ自分だけ時間が別枠だったのでそもそも選外だったかもしれませんね。

ベストスピーカー賞の投票は、ふわり(@Fuwari_WE)さんの「ChatGPT、Gemini、Claude は、なぜ似たようなUIを採用しているのか?」にしました。理由は、ELIZA効果・手続き的公正など私の知らない話が一番出てきて、なおかつその知識を仕事にすぐ活かせそうと思ったからです。

speakerdeck.com

きちぴーナイトパーティー 2025

前回はお客さんとして行きましたが、今回はDJとして出演できました。嬉しい!!!

このブログでは紹介してなかったですが、実は最近DJ機材を一通り揃えて家で練習できるようにしていました。

当初はMichael FortunatiのGive Me UpとBananaramaのI Heard a Rumorがめっちゃ似てるというのがテーマの原義ユーロビートMixをやろうとしたんですが、準備不足につき断念(これはまた別の機会に)。以前にSMTP++ #17や会社の年度末パーティでDJしたときに組んだ、80年代J-POPを中心としたセットリストを組み替えて流しました。

1. Give Me Up / BaBe 2. 心よ原始に戻れ~2012Version~ / 宮村優子 3. ビバナミダ / 岡村靖幸 4. 中央フリーウェイ / YOASOBI cheers 松任谷由実 5. OUTSIDER / 東京ゲゲゲイ 6. 淋しい熱帯魚 / ClariS 7. 君は1000% / SUPER★DRAGON 8. シャクシャイン / 水曜日のカンパネラ

最後のシャクシャインだけは予定していたプレイリストに入れていなかったんですが、思ったより尺が余ったので、BPMとキーが合う曲としてその場で突っ込んだのでした。

深夜帯だったので人が減っていたり、残ってる人にも疲れが見えたりしていましたところでしたが、そこから自分なりにうまく盛り上げられたな〜と自己評価しています。

最後に

個人主催の技術勉強会が発展して300人が集まるカンファレンスに!本当にすごい話です。id:magnoliak さん、スタッフの皆さま、そのほか関係した全ての皆さま、ありがとうございました!!

楽しい週末を過ごせ、さらに新しい出会い・交流の輪を広げられたことに非常に満足しました。またどこかでお会いしましょう〜〜

OpenTelemetry Collectorで教師なし異常検知ができるIsolation Forest Processor

OpenTelemetry Collector Contrib v0.132.0のリリースノートを眺めていたところ、面白そうなProcessorがalphaステータスで出ていたのでご紹介します。その名もIsolation Forest Processor。

github.com

Isolation Forestというのは二分木を用いた異常検知アルゴリズムで、多数のデータを入力しても計算量やメモリ使用量を小さく抑えられることが特徴のようです。大量で多次元なデータを扱うオブザーバビリティデータの処理に向いていそうな特性ですね。

en.wikipedia.org

Isolation Forest Processorは、テレメトリーを受け取った上で異常検知を行い、その結果を2つの属性として付与します。anomaly.is_anomaly属性は異常かどうかを表すboolean、anomaly.isolation_score属性は分離度を表すスコアです。なお、この属性名はconfigで変えることもできます。メトリックはもちろん、トレースやログにも対応しています。

試しに以下のようなconfigを書き、 トレースのパイプラインにこのProcessorを組み込んでみました。

processors:
  isolationforest:
    features:
      # スパン名とスパンの所要時間を特徴量とする
      traces: [operation.name, duration]
    training_window: 1h
    update_frequency: 1m
    min_samples: 500
    contamination_rate: 0.05

そして、普段は100msほどで処理が終わるものの、3%の確率で異常に所要時間が長くなるようなトレースを送ってみました。

すると、以下のようにanomaly属性が付与されたトレースデータが生成・投稿されました。

異常ではないと判定されたスパン

異常だと判定されたスパン。処理に7秒ほどかかっている

今回はたまたまうまく行った例を拾ってきましたが、精度についてはなんとも言えないところでした。少なくともサンプル数や異常度の期待値といったハイパーパラメータの調整を結構頑張る必要がありそうです。

お手軽に異常検知を試してみたい方はIsolation Forest Processorを試してみてはいかがでしょうか。

SRE NEXT 2025でOpenTelemetryセマンティック規約の紹介をしました

SRE NEXT 2025でOpenTelemetryセマンティック規約の紹介をしました

SRE NEXT 2025では、私が所属しているMackerel(株式会社はてな)がGold Sponsorとして協賛しておりました。その関係で、スポンサーセッションの登壇者として今回のSRE NEXTに参加することになりました。SREの哲学をenabledされたアプリケーションエンジニアとしてSRE NEXTに登壇するのは夢だったので、ちょっと違った形ではあるものの叶ったことになります。

今回は「OpenTelemetryセマンティック規約の恩恵とMackerel APMにおける活用例」という題で発表をしました。

speakerdeck.com

OpenTelemetryで様々なレイヤーでオブザーバビリティデータやその転送の標準化が行われる中、そのうちの一つであるセマンティック規約(Semantic Conventions)を取り上げて、その概観と役割について説明しました。また、セマンティック規約の役割として、意味の合意により実際のテレメトリーデータとオブザーバビリティバックエンドを繋ぐ目的があり、その結果としてMackerelのAPMではテレメトリーに付与された属性の意味を活かして特化した分析表示ができますという話をしました。

実はセマンティック規約は私がOpenTelemetryでかなり好きなものの一つであり、本ブログでもいくつかエントリを書いています。

blog.arthur1.dev

blog.arthur1.dev

スポンサーセッションという位置付けなんですが、プロダクトの宣伝マックスになってもなあという気持ちがありました。そこで、OpenTelemetryの知識が身に付き、その延長で自然とMackerelのAPMについて見てもらえるようなストーリーで作りました。国内でもなかなか他に事例がないオブザーバビリティプラットフォーム開発の裏側を紹介することで純粋な技術の教養欲を満たすこと、業務で使える知識を持ち帰ってもらうこと、プロダクトの認知を広めること、の3点をうまく両立できたんじゃないかなあと思っています。

以下のように私のセッションに言及いただき、想定した通りの反応を頂けてよかったです。

www.wantedly.com

とはいえ、前のセッションが押していた関係もあってかタイムテーブルが乱れてしまい、遅れを取り戻すために予定より2分ほど短い登壇になった関係で、自分がかなりテンパってしまいました。その結果、伝わりづらい、あるいはバランスの悪い発表になってしまったかもしれません。これは自分の力量不足なので場慣れしたいものですね。

登壇者としては、何より多くの方に発表を聞いていただけたことがとても嬉しかったです。現地やオンラインでいらしてくれた皆さま、ありがとうございます。Ask the Speakerも誰も来ないんじゃないかとヒヤヒヤしてましたが、来ていただいて安心しました。懇親会やその後のn次会(n = 2, 3, 4)でもたくさん交流ができ、新たな出会いもたくさんありました。

心残りなのは、2年間続けてきたSRE NEXTの当日スタッフに参加できなかったこと、Day 1のアンカンファレンスに参加できなかったことです。今回は他の予定が2つバッティングしてしまったため、そもそも参加すら怪しいという状況だったので見送っていました。登壇スケジュールに関して便宜を図っていただき、なんとか全予定を両立しフルではないもののSRE NEXTに参加できました。ありがとうございました。

改めて、SRE NEXT 2025に参加できてよかったと思いました。スタッフの皆さん、ありがとうございました。SRE NEXT 2026も何らかの形で関われたらと思いますので、よろしくお願いします。

【PJCS2025 4-3 Drop😭】不利なリザードンexにもワンチャン作ったびっくりサーフゴーexデッキのふりかえり

こんにちは。Arthurです。

CL2025大阪で優先招待出場権をいただいた*1ので、念願のポケモンジャパンチャンピオンシップス2025カードゲーム部門に出場しました。

キービジュアルに合わせてミュウツーのTシャツを着ていきました

使用したのはサーフゴーexデッキです。結果はDay 1で4-3ドロップ(735位/2500人)という不甲斐ない結果に終わってしまったのですが、本エントリにて振り返っていこうと思います。

デッキリストと戦略

デッキリスト

リストはリリー(@lily_pcg)さんに頂いたものをそのまま使用しました。いつもオンラインコーチング*2でお世話になってます。私が仕事人間で常時環境を追い続けていくことが困難なので、知識を補完してもらっています。

デッキコード: FFbkbv-tPozqh-FVvvbk

採用/不採用カードの特徴は以下の通りです:

  • スボミー採用
  • マシマシラ採用
  • エースキャンセラーのゲノセクト採用
  • ロケット団のびっくりボム採用
  • ロケット団の監視塔2枚採用
  • ピクニックバスケット採用
  • フトゥー博士のシナリオ2枚採用
  • ハッサムライン不採用
  • ワザマシン:エヴォリューション不採用

サーフゴーexデッキを選択した理由

今環境では以下のデッキの存在感があると感じました:

  • タケルライコex/オーガポンみどりのめんex
  • オーロンゲex/ユキメノコ
  • ドラパルトex
  • サーナイトex/マシマシラ

特に、PJCS1週間前に開催されたEUICにて、有名プレイヤーであるTord Reklev選手がドラパルトexデッキを使用してTOP4に残った*3ことから、カーストボムを採用しないドラパルトexの使用が増えると予想しました。また、同じようにそれを見越したプレイヤーが、オーロンゲexやサーナイトexといったマシマシラを有効活用できドラパルトexに有利に立てるデッキを使用すると考えました。

以上の理由から、これらに有利な構築で臨めるサーフゴーexデッキを選択しました。タケルライコexに対しても、こちら側が1ターン目にサイド2枚のポケモンを出さないことで、先に2-2-2のサイドレースを仕掛けられることなどから五分以上はあると捉えていました。

デッキの性質上メタビートやバクフーンには基本勝てないですが、10回戦中2回当たる分には良くて、他の対面で全部勝てばDay 2に上がれるので割り切りました。リザードンもかなり厳しいですが、後述するプランにより勝てないことはないぐらいのつもりでいました。

なお、サーフゴーexデッキは手札が多くなる(取りうる選択肢が指数関数的に増える)こと、いくら途中まで順調でも最後にグッズロックにより負け確になる落とし穴が存在していることなどにより、個人的は苦手なデッキと思っていました。また、ゲノセクトex/ふうせんを採用している都合上、PTCGLで練習できないことも向かい風でした。

それでも、直前に参加した小規模な自主大会で全勝優勝できたことから、自信を持ってPJCSに持っていけると判断しました。自信を持てないままふわふわと一貫性のないプレイをし続けると良い結果も出ないしメンタルも最悪なので、ポジティブな気持ちで握れるかというのも大事な価値基準です。

タケルライコexデッキ対面について

先にサイド1枚取らせて、後攻2ターン目にこちらがサイド2枚のポケモンを取れば2-2-2で進めることができます。多くの場合先2ではスピンロトムなどの非エクポケモンが前にいるため、カウンターキャッチャーORボスの指令が必要となります。

先にサイド2枚取られると基本負けなので、後1でゲノセクトexは置きたくないです。相手がタケルライコexに手張りしていない状況(次にオーリム/アカマツ要求でボスの指令が打てない)で、かつむずむずかふんが言えるなら出してもいいでしょう。エースキャンセラーでもいいんですが、ポケモンキャッチャーで泣きを見ないといいですね。とはいえエースキャンセラーは普通に強いです。

キチキギスexはコライドンやチヲハウハネで2-1交換されてしまいこちらの要求が増えるので、最後までなるべく出さないようにしましょう。

ドラパルトexデッキ対面について

エネルギーテンポを失わせると非常に楽に勝てます。序盤のボスでエネルギーがついているドロンチを倒せると嬉しいですし、ネオアッパーエネルギーを止められるエースキャンセラーが非常に強力です。

あとはサーフゴーが倒れないようにマシマシラとピクニックバスケット、フトゥーで回復しながら倒していけばドラパルトexの強みを活かさせないまま勝つことができます。

エネルギーが足りなくてHP320のドラパルトexをワンパンできないときには、マシマシラ・びっくりボムを活用して倒したり、あるいはどうせ集めたエネルギーがナンジャモで消えてしまうならと300点だけ当てておくのもなくはないと思います。相手のフトゥー(Tordドラパには2枚採用)が裏目になりますが、そこまでにエネルギーテンポを失わせるプレイが通せていると、「ここでフトゥーを打つとファントムダイブできないけど大丈夫ですか?」という状態になることがあります。

サーフゴーは素の合計でだいたい1000点ぐらいは与えられるデッキ(ゴールドラッシュに使えるエネルギー7枚+スーエネとタンカで回収できるエネルギー17枚で計1200点分。ここからサイド落ちなど考えてざっくり1000点*4)です。仮にフトゥーで300点のダメージが無駄になったとすると、250(キチキギスex)+50(スボミー)+100(ドロンチ)+350(ドラパルトex)=750点のサイドプランならギリギリセーフって感じです。マシマシラを有効活用できたりスーエネが4枚使える場合にはなんとかなるし、後のスーエネで4枚エネを拾うために序盤に多めにトラッシュしているとその分厳しくなります。

オーロンゲexデッキ対面について

デヴォリューションでサーフゴーが全滅するのがわかりやすい負け筋です。コレクレーを全部サーフゴーに乗せすぎないことが一つの解決策になります。ただ、相手の盤面にダメカンがたくさん残っている場合、アドレナブレイン3回でコレクレーがいなくなってしまった上にデヴォされたら終了です。とはいえ、フトゥー・ピクニックバスケット・マシマシラを活用する、ユキメノコをボスで取ることを意識すれば、こうなるケースを回避できるはずです。

グッズロックでスーエネが止まるのが怖くて相手のスボミーに構いたく気持ちはわかりますが、アドレナブレインでいつでも取れるサイドと思ってしばらく放置しておくのが良いと思います。オーロンゲexデッキは意外とベンチカツカツで、スボミーを残しておくと相手のできることが減ります。

基本ですが、こちらのマシマシラのアドレナブレインでダメージを移すときには、このターンに倒す相手に乗せましょう。必要エネルギーが減りますし、相手の盤面のダメカンを増やすとマシマシラの餌になってしまいます。

ガチグマアカツキexの採用が見られるので、サイドが2-2の展開になってしまったら、監視塔+ナンジャモで勝負しましょう。

リザードンexデッキ対面について

サイド1枚のポケモンであるイーユイがこちらのサーフゴーをワンパンして1-2交換となるのがかなり厳しいです。

先にサイドを3枚取って3-6に持ち込めると、こちら側が必要なターンは2ターン/相手側が必要なターンは3ターンになり、理論上はこちらが先に勝ちます。サイド枚数が奇数なのでイーユイを挟まれても問題なく、2回連続イーユイ/リザードンが走ってきて奇数進行になってしまうときに備えて裏呼びが1回できれば良いことになります。

対して、サイド4-6から相手のイーユイにサーフゴーを取られて4-4になる展開だと、以後ナンジャモで手札干渉される中で、HPの大きな(=エネルギー要求が高い)ポケモンを裏呼び込みで倒すのを2回連続やらなければ負けてしまうので望みがかなり薄いです。もちろん、サイド4枚時のバーニングダークは240点なのでイーユイを一旦放置して準備することは1ターンだけ可能に見えます。しかし、リザードン側がまけんきハチマキ・マキシマムベルトを採用していたり、カーストボムラインを採用していたり、グッズロックされたりするとこれも通りません。サイド2枚のポケモンを置かれないプレイをされてしまった場合には必要ターン数が増えて負け確定です。また、4-4時点でイーユイに構った場合にはサイドが3-4になり、以降はリザードンがサーフゴーをワンパンしてくるので、相手の方が2-2-2で早くサイドを取り切ってしまいます。

さて、どうやって先にサイドを3枚取るかという話ですが、リザードンデッキにはピィやスボミーといったHP30のポケモンが採用されています。ここにあらかじめスボミーむずむずかふんの10点を当てておき、ロケット団のびっくりボムと、必要に応じてマシマシラのアドレナブレインを使用することで、ピィ/スボミーと前に出てきたポケモンで一気にサイド2枚取り進めるターンを作ることができます。リザードンの展開速度的にこれ以外でサイド1枚を取ることができる(典型的にはボスの指令でピジョン/リザードを取る)ので、トータル3枚というわけです。

ほかにも、こちらがサイドを取らないでいるまま、リザードンにサーフゴーをワンパンできない火力で殴ってもらい、そのダメカンを元手にアドレナブレイン込みでサイドを一気に複数枚取りすることもできるでしょう。リザードンexがHP330(50×6+30)、ピジョットexがHP280(50×5+30)なので、50の倍数でダメージが乗るゴールドラッシュでギリギリまでダメージを与えておくと、アドレナブレイン1回でちょうど倒せます。

2つ目のルートにはターンの隙があり、NAICシニア優勝のリザードンデッキ*5のようにマシマシラやピクニックバスケットが採用されている場合には容易に破綻します。前者のパターンにおいては、ピクニックバスケットがグッズロックで使えません。また、マシマシラがいて10点動かされても、動かされた先がサーフゴー(コレクレー)なら、そのポケモンを正面にしてびっくりボムチャレンジすれば30点一箇所に集まるので、問題になることは少ないでしょう。

バチュルバレットデッキ対面について

こちらは2-2-2を通し、相手の2-2-2を防ぐ攻防プレイをすることになります。相手の方がバチュチャージ分1ターン遅く動くのですが、ボスが引けない場合にサイド1のバチュルを取らされる展開になりこちらが遅れてアドが消えます。基本的には相手のサイド2枚取れる能力を持つ、エネルギーがついたポケモンを狙っていくことになります。サイド2枚取らせることを許せないターンを1ターン作れればその分猶予があるので、バチュルを取って5-6を経由しても全然大丈夫です。

サーフゴーデッキだと相手に知られると、だいたいピカチュウexにエネルギーが集まることが多いと思います。ピカチュウexに対してはびっくりボムと必要に応じてマシマシラを使うことで特性を貫通することができます。このエネを有効に使わせないまま倒せると良いですね。

びっくりボムが当たった方がお得かどうかは実は状況によります。相手がサーフゴーをワンパンし続ける展開のときにはマシマシラを用意するエネルギーテンポが間に合わないことがあり、その場合には表が出て欲しいです。裏が出た場合にはマシマシラが必要(=ごっつぁんプリファイのリスクを負う)になりますが、アドレナブレインを2回に分けて行うことでピカチュウexを2回突破する権利を得ます。

テツノカイナexにエネルギーが集まった場合にはコレクレーが残らないようにサーフゴーに乗りましょう。ハンド干渉は多くないので乗りやすいと思います。また、ごっつぁんプリファイされないポケモンで盤面を揃えられた場合には、エネルギーが集まってるからといって怖がらずにテツノカイナex以外のポケモンを取りましょう。シビビール型の場合により有益なポケモンにエネルギーがつかないようにしたり、単純につりざおで返されないようにしたりする目的です。だいたい相手はブーエナ未来を張ったり序盤の展開でラティアスを置いたりするので、テツノカイナにつけてしまったエネルギーをトラッシュに送るのは困難です。

ミライドンexにエネルギーが集まった場合には、こちらのゲノセクトex/キチキギスexが標的となっています。ミライドンexを取るか、ゲノセクトex/キチキギスexをフトゥーでどけるか、あるいはエースキャンセラーで少しでも裏呼び回答を減らすかしましょう。終盤は相手のガチグマアカツキexでも同様のことが言えます。こちらに関しては監視塔でカバーできることがあります。

バチュルを避けずに5-6から始まった場合、サイド3枚の状態からゼクロムexがサーフゴーexをワンパンすることも頭に入れておくと良いでしょう。逆にバチュルを避けた場合は、バングル+デンチュラ210点でキチキギスexが飛んでしまうので、できる限り出さないようにしましょう。

ミラー対面について

先にサイド2枚のポケモンを出して取られてしまった方が負けるゲームです。まずはスボミーとマシマシラで頑張りましょう。

ハッサム採用型と異なりエースキャンセラーに枠を割けているのがミラーでも強いです。

リグレーとの向き合い方

鋼エネルギーがちょっとずらすされて足りなくなりそうな場合には、フトゥーとスーエネ(ORタンカ)を同じタイミングで打つと良いと思います。リグレーを採用するコントロール寄りのデッキにはおそらくスボミーも採用されており、後回しにしているとグッズロックされて回収不可能になってしまいます。

エクストラでコントロール系統デッキに対してグズマを使用した瞬間に即バトルサーチャーで回収するプレイに馴染みがある方には分かっていただきやすいと思います。

戦績と対戦ログ

サマリー

Day 1 予選 4-3

  • vs リザードンex/ピジョットex 先攻 ●
  • vs ドラパルトex/ブリジュラスex 後攻 ◯
  • vs ドラパルトex/ネイティオ 先攻 ●
  • vs ヒビキのバクフーン/ピジョットex 後攻 ◯
  • vs ドラパルトex 先攻 ◯
  • vs ドラパルトex/バシャーモex 先攻 ◯
  • vs ブリジュラスex/マシマシラ 後攻 ●

対戦ログ

1回戦 vs リザードンex/ピジョットex 先攻 ●

じゃんけん負けで先攻。しかし相手は後攻でサポートなし。前イーユイ後ろピィで番が帰ってきた。このときハイパーボールでピクニックバスケットがトラッシュに行ったので相手に先に殴らせてもよかったが、この時点でヒトカゲを置けていない相手をずっと待つのもしんどいので、早期3-6ルートを目指すことにした。

サーフゴーでイーユイを取り5-6。返しにポッポ2匹ヒトカゲ2匹が準備された上にピィが前に出てきたので、ピィにむずむずかふんを打つ。

ポッポはピジョンに進化し、またもピィがにぎにぎドロー。ここでびっくりボム+マシマシラでピィを取りつつ、ボスピジョンできればかなり勝てそう!しかし、ボスは引けなかったので、ピィと前にでてきたポッポを取って3-6。大地の器がサイド落ちしていたため、悪エネルギーを持ってくるためにエネルギー転送PROを消費。このときトラッシュにエネルギーを最低限しか送らなかったのが結構なプレミとなる。あとこの番に暗号マニアが引けていたら山上を固定できたのだが引けず。

ここでハンド干渉されリザードンexが立ち、サーフゴーexを倒して3-4。ここからはサーフゴーがワンパンされるので、次の番はなんとしてもサイド1枚以上を取らなければならない。しかし、ボスも引けずエネルギーも引けずということで要求を満たせずにここで負け確定盤面に。トラッシュをエネルギーに送らなかった分山には大量のエネルギーがあったが、それでも手札に2枚しかエネルギーがなかったのでスーエネ引けてても結局リザードンワンパンは足りなかったというオチ。ボーナスコインで多くドローするために逃げ権を使ってしまい、フトゥーも引けなかったので、サイコトリップでお茶を濁すこともできず。そのまま4枚取られて負け。

結果は負けてしまったが、不利対面に対して考えていたプランをちゃんと通せてよかったと思った。

2回戦 vs ドラパルトex/ブリジュラスex 後攻 ◯

相手がまともにサポートを引けておらず、ドラメシヤ・ドロンチ・ジュラルドンを取って行ったら種切れ確定だったのか相手が投了した。

5分ぐらいで終わったので会場を探検してた。

3回戦 vs ドラパルトex/ネイティオ 先攻 ●

じゃんけん負けて先攻。むずむずで止まったものの、ボス2エネドロンチ取りで快調のスタート。

しかし、アンフェア後の手札の噛み合わせがずっと悪く、フトゥーで時間を稼ぐことしかできなかった。というか、どこかで暗号マニアの上下を間違えたのが激烈に刺さった。

残りサイド4-2で残り時間が1分半。先攻を取らされたのでおそらく自分の番はもう帰ってこず、ほぼほぼ両負けOR相手の勝ちという状態に。一応少しでも時間を残してもう1ターン作ろうと甘いプレイをしてサイド2-2にした結果、ガチグマで負け。まあオポネント関係ないし両負けで気まずくなるよりはよかったのかなあ。

4回戦 vs ヒビキのバクフーン/ピジョットex 後攻 ◯

崖の初戦でド不利デッキと当たって絶望。そういえばCL大阪でも崖でミライドン踏んでたなあ。

とりあえず後1むずむずかふんして止まるのを祈ったら、なんとサポなしで止まった。

後2でボスの指令でピジョンを取ってスタート。ここから相手がハイパーボールで動き出す。

前のヒノアラシも取ってサイド4-6に。このあと相手がたびのきずなを使うが対象なし。これはヒビキの冒険が2枚サイドに落ちているかもしれない。サーフゴー相手には2枚で打点は足りるものの、単純にポケモンとエネルギーを持って来れるのが強いので3枚目も持ってくる価値がありそうだった。バクフーンがサーフゴーを倒してサイド4-4に。

このバクフーンを倒して3-4、次にサーフゴーが倒されて3-2になる見込みなので、暗号マニアの解読でナンジャモとスーパーエネルギー回収を山上に仕込んでおく。また、アタッカーとしてマシマシラを準備しはじめる。

実際に3-2になった上にスイレンのお世話でバクフーンラインを手札に持たれ、サイドからヒビキの冒険を引いてそうという状態。監視塔(ポッポがいたのでアメ+ピジョットex対策)を貼りナンジャモで手札干渉。バクフーンを倒して2-2。要求はアメ+バクフーン+エネルギー。シークレットボックスを使われないようエースキャンセラーも準備済み。

ここで相手が殴れずにポッポを差し出してパスしてきたので、このポッポをマシマシラのサイコトリップで取って1-2。裏呼び要求を追加できた。

次のターンも相手が殴れなかったので、こちらがサイドを取り切って勝利。

5回戦 vs ドラパルトex 先攻 ◯

じゃんけん負けて先攻。相手がキチキギスex前でデッキがよく分からんという状態だったがドラパルトだった。当然グッズロックされ続ける。

これが刺さりゲノセクトexが置けず、おつかいループでエネルギーを集め続ける。しかし相手も相手でエネルギーが全然貼れない。そのうちサーフゴーexを単体で引いたのでむずむずの打点を受けないように進化しておきつつ倒す。返しでスボミーがまたやってくる。

先に相手がドラパルトexに乗ってエネルギーを1つつけ、むずむずかふんしたタイミングでようやくゲノセクトexを引きゲームスタート。おつかいで貯めたぶんと合わせてボスの指令ドラパルトexで300点与える。さすがにグッズロック下で350点は無理だし、モタモタしてるとせっかく集めたエネルギーがナンジャモされそうだったので勝負に出た。

返しでエネ手張り+ファントムダイブを受けるが、マシマシラを出してドラパルトexに30点動かしてきぜつさせサイド3-6。そこで相手がラティアスexを出してきたので、ここにまた200刻む。キチキギスがいるので刻むつもりはそんなになかったが、エネルギーが足りなかった。さらに盤面にエネルギーがなくなった状態でエースキャンセラー発動。これで次のターンはファントムダイブされない。

ふうせんを2枚見せてしまったことをいいことに相手はゲノセクトexをカウキャで呼びナンジャモで準備のターン。返しにドローを進めるも逃がせるカードを引かないのでパス。ファントムダイブをゲノセクトexとサーフゴーexに受け、サイドが3-4に。

そのあともキチキギスexまで使ったのに逃げ札を引けず、ペパーを打ったら3枚目のふうせんがサイド落ちという事実に気づく。キチキギスex置く前にネストボール使って山見ておけば気づけたけど、ナンジャモ的には山シャッフルしたくなくて我慢していた。これでは次にカウンターキャッチャーとルチャブルで負けてしまう。仕方ないのでアドレナブレインでラティアスexを取ってサイド2/3に賭けたらふうせんを引けたので、前のドラパルトexを取って勝ち。

結果は勝ちだったけど色々怪しい試合だった。

6回戦 vs ドラパルトex/バシャーモex 先攻 ◯

じゃんけん負けて先攻。相手は後攻サポートなしで事故。

そのまま先2で前のアチャモ取って、先3ボスドロンチ、先4ドラメシヤまで行って残りサイド3-6。

このあとはリバーサルエネルギーがついた非エクバシャーモがゲノセクトexを取って3-4。そのバシャーモを取って2-4。

バシャーモexがサーフゴーexを取って2-2。バシャーモexを倒して勝利。

7回戦 vs ブリジュラスex/マシマシラ 後攻 ●

初期手札はマシマシラ・キチキギスex・エネ2枚・フトゥー・ボス・ピクニックバスケット。マシマシラ置きスタート。コレクレー置けない!!

相手は先1ゼイユイキリンコでぶん回って、次確定でジュラルドンが殴れる状態。関係なかったけどスボミーケアまでされた。

後1トップは暗号マニアでギリギリセーフなのか?仕方なく種切れ負け回避のためにキチキギスexを置き、暗号マニアでペパーをセットして終了。先2で当然のようにボスでキチキギスexが飛ぶ。

マシマシラを壁にしてペパーポフィンでコレクレー2枚を並べ、ボスでエネルギーがついてないジュラルドンを呼ぶ。返しにそのジュラルドンも3エネついたブリジュラスになり、テツノツツミハイパーブロアーでコレクレーきぜつ。このまま1回もサーフゴーに乗れず種切れで終了。

有利対面だったのにあっけない最後でした。初めてエヴォリューション不採用が仇となりました。

思い出

今回はブラックボルト・ホワイトフレア発売直後だったので、そのイメージのネイルで臨みました。

1戦目終了後にポケモンカードYouTuberのじゅん(@jun_youtube_)さんに席を特定され話しかけてもらいました。いつも配信見てるので超嬉しかったです。文句なしにPJCS一番の収穫です。

www.youtube.com

他にも、CL大阪で戦ったプレイヤーや、一般観覧に来た人など数多くの人と交流できました。SNSでも多くの方に応援いただきました。全ての出会いに感謝。

反省は生大の形

まとめと謝辞

リリーさんに「後攻とれることを祈っております」と言ってもらったんですが、余裕で先攻取らされまくりましたね。とはいえ先攻でもちゃんと勝てたのでそこまで気にしてないです。

PJCSには初めて参加しましたが、おかげさまで寂しくなく過ごすことができましたし、デッキ選択に悔いもなく、結果だけが心残りというところで終わることができました。対戦ログを読んで分かる通り、まだまだプレイミスがあるので、自覚できている分伸び代があるということにします。

改めて、一緒にプレイしていただいたり、応援いただいたり、私には見えていない世界を教えてくれたりするみなさまのおかげで2025シーズン頑張れました。ありがとうございました。

自分にとって2025年シーズンは終了してしまいましたが、来シーズンもスタンダード/エクストラレギュレーション両方で諦めずに続けていくので、応援よろしくお願いします。WCS行くぞ!!!!

*1:https://blog.arthur1.dev/entry/2024/12/25/130000

*2:https://note.com/lilypcg/n/nd90c3781a723

*3:https://limitlesstcg.com/decks/list/18499

*4:という理屈をつけてますが、サーフゴーがぜんこくずかんNo. 1000であることに関連させてなくもないです

*5:https://limitlesstcg.com/decks/list/18809

Googleスライドのデフォルトページサイズは実は小さいので、解像度を上げる設定をすると良い

まとめ

  • Googleスライドやそのテンプレートを作る人は、ページ設定から解像度を上げよう
  • そうすると、Speaker Deckにアップロードするときなどに画像や文字の品質が上がる

本編

Googleスライドを新しく作成するとき、自然とアスペクト比が16:9の設定になっているかと思いますが、これが実際にどのぐらいのサイズなのかを気にしたことはありますか?

そもそも、Googleスライドの縦横サイズは、ファイルメニューの中にある「ページ設定」で確認・変更することができます。

デフォルトだと以下の通り「ワイドスクリーン(16:9)」になっているのですが、ここから「カスタム」に変えて単位も変えてみると、「ワイドスクリーン(16:9)」というのは960*540pxであることがわかります。現代でもデフォルトがFull HDになっているわけではないのです。

画面に映してスライドショーをする分にはこの設定で問題なく鮮明に描画できているはずです。しかし、PDFや画像としてエクスポートしたり、エクスポートしたPDFをSpeaker Deckなどのスライド共有サイトにアップロードしたりする際には支障が起きます。

デフォルトの設定でGoogleスライドからエクスポートしたPDFをSpeaker Deckにアップロードし、その後再び編集画面に行くと、以下のような表示がされていることがわかります。

スライドデータの解像度が足りず、変換の品質が下がってしまう可能性がある旨が書かれています。Googleスライド上の解像度である960*540pxよりもっと小さなサイズとして表示されている理屈はあまりわかりませんが、いずれにせよスライドの大きさが足りていないということです。

元のファイルの解像度が低いと、スライド内の画像の品質が落ちてしまうことがあります。また、Speaker Deckではフォント部分も画像のように変換する処理を行っているので、文字も同様に荒くなってしまったり、周囲のノイズが増えてしまったりすることがあります。

比較用のサンプルデータを用意してみました。デフォルトのサイズでPDFエクスポートしたものと、ページ設定を1920*1080pxにしてエクスポートしたものをどちらもSpeaker Deckにアップロードしました。

speakerdeck.com speakerdeck.com

遠目ではあんまり違いがわからないですが、頑張って拡大してみると、微妙〜〜に左側のデフォルト設定の方がギザギザ感が強い箇所があったり、ノイズが多い部分があったりします。もっと良いサンプルが作れたら違いが一目で分かったかもしれないです。

ページ設定を1920*1080pxにしてエクスポートしたPDFをアップロードしたときには、先ほどのようにYour deck is less than 1000px wide.と注意されていません。

技術イベントで登壇し資料を共有する人や、デザイナーとしてスライドのテンプレートを作る人は、ぜひGoogleスライドのページ設定を確認してみてください。見やすい・読みやすい資料を提供して、読者の没入感を高めましょう。