COLOPL Tech Blog

※2026/03/03 ご指摘をいただいたので追記・修正しました

今回実装するカスタムルールは、Job クラス (ShouldQueue を implements したクラス) のプロパティの型が、以下のいずれかの条件を満たすかチェックします。

null
スカラー型 (bool, int, float, string)
array (array のネスト含む)
enum
(SerializesModels trait を使用している場合は) Model

これにより、Closure や CarbonInterface などをはじめとするオブジェクトなど、シリアライズ時に危険性がある型使った場合に、静的解析で機械的に検知できます。

実装のポイント

カスタムルールの実装にあたっていくつかポイントがあったため、そちらをご紹介します。

先に最終的なソースコードを見たい場合はこちら。

1. `InClassNode` の活用

PHPではクラスのプロパティの定義方法は2種類あります。通常のプロパティ宣言と、コンストラクタでのプロパティ昇格です。それぞれAST上では異なるノードとして表現されます。

	ノード
通常のプロパティ	`Node\PropertyItem`
プロパティ昇格	`Node\Param` (`isPromoted() = true`)

異なるノードそれぞれに対するカスタムルールを書くこともできます。ただ、今回作成するカスタムルールではプロパティの型さえ分かれば良く、どちらの方法で定義されているかを区別する必要はありません。

こういう時は InClassNode と ClassReflection を組み合わせることで、ソースコード上の記述位置を問わず、クラスが持つプロパティを一貫してチェックするルールを記述できます。

<?php

class JobOnlyPrimitiveOrQueueablePropertiesRule implements Rule
{
    /**
     * @inheritDoc
     */
    public function getNodeType(): string
    {
        return InClassNode::class;
    }

    /**
     * @inheritDoc
     */
    public function processNode(Node $node, Scope $scope): array
    {
        // 対象のクラスのリフレクションが取得できる！
        // getNodeType() が Stmt\Class_ だとまだクラスの解析が終わっていないので、ここで $scope->getClassReflection() は取得できずにnullになってしまう
        $classReflection = $scope->getClassReflection();

        // ShouldQueue インターフェースを実装しているかチェック
        if ($classReflection === null || !$classReflection->implementsInterface(ShouldQueue::class)) {
            return [];
        }

        // 通常のプロパティも、コンストラクタのプロパティ昇格も一括で取得できる
        $properties = $classReflection->getNativeReflection()->getProperties();

        // TODO: $properties のチェック処理
    }
}

2. 再帰的な型判定

プロパティの型は、配列のネストや Union 型 (例: int|Carbon) が含まれる場合があります。そのため、以下のように再帰的にチェックします。

<?php

function isAllowedType(Type $type): bool
{
    // 1. まず Null を型から取り除く（Nullable をシンプルに扱うため）
    $type = TypeCombinator::removeNull($type);

    // 元が null のみだった場合は NeverType(BottomType) になるので許可
    if ($type instanceof NeverType) {
        return true;
    }

    // 2. 配列（またはそのUnion）の判定
    // removeNull したおかげで、`array|null` も安全にここでキャッチできます
    if ($type->isArray()->yes()) {
        return $this->isAllowedType($type->getIterableValueType());
    }

    // 3. スカラー、またはEnumの判定
    // `int|string` のような同種のUnionであっても、yes() が true になります
    if ($type->isScalar()->yes() || $type->isEnum()->yes()) {
        return true;
    }

    // 4. 異種の複合型（例: `int|array` や `string|QueueableEntity`）のフォールバック処理
    // instanceof UnionType を避け、PHPStan公式の安全な分解ユーティリティを使います
    $types = TypeUtils::flattenTypes($type);
    if (count($types) > 1) {
        foreach ($types as $innerType) {
            if (!$this->isAllowedType($innerType)) {
                return false;
            }
        }
        return true;
    }

    return false;
}

再帰処理により、array<int, string> や array<Model> のようなネストされた型も正しく検証できます。

3. `SerializesModels` trait の判定

Laravel の SerializesModels trait を使用している場合は、Eloquent Model のシリアライズが安全に行われます。

SerializesModels trait は、安全に Model クラスをシリアライズする手法です。モデルの全プロパティをシリアライズするのではなく、モデルのクラス名やIDなどの識別情報のみをシリアライズし、デシリアライズ時はDBから再度モデルを取得します。これによりシリアライズに起因する問題や、Job のキューイング中に Model が変更されて古い状態のまま処理されてしまうリスクを軽減できます。ただし、キュー投入から実行までの間に Model 自体が削除されたり、前提としている状態から大きく変化した場合の扱いについては、引き続き注意が必要です。

SerializesModels trait を使用しているかは $classReflection から容易に判定できます。

<?php

$classReflection = $scope->getClassReflection();
$allowQueueable = $classReflection->hasTraitUse(SerializesModels::class);

4. 外部パッケージの除外

Illuminate\ の以下のプロパティは静的解析の対象から除外します。

これによって Illuminate\Queue\InteractsWithQueue や Illuminate\Bus\Queueable などの trait によって追加されるプロパティは検証対象から除外します³。

<?php

$declaringClassName = $property->getDeclaringClass()->getName();
// 依存パッケージ側はチェックしない
if (str_starts_with($declaringClassName, 'Illuminate\\')) {
    continue;
}

最終的なソースコード

以上を踏まえて、最終的なソースコードはこのような形になります。

<?php

declare(strict_types=1);

namespace CustomPHPStan\Rules\Jobs;

use Illuminate\Contracts\Queue\QueueableCollection;
use Illuminate\Contracts\Queue\QueueableEntity;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\SerializesModels;
use PhpParser\Node;
use PHPStan\Analyser\Scope;
use PHPStan\Node\InClassNode;
use PHPStan\Rules\Rule;
use PHPStan\Rules\RuleErrorBuilder;
use PHPStan\Type\ObjectType;
use PHPStan\Type\Type;
use PHPStan\Type\UnionType;
use PHPStan\Type\VerbosityLevel;

/**
 * @implements Rule<InClassNode>
 */
class JobOnlyPrimitiveOrQueueablePropertiesRule implements Rule
{
    /** @var list<ObjectType>|null */
    private ?array $queueableObjectTypes = null;

    /**
     * @inheritDoc
     */
    public function getNodeType(): string
    {
        // Stmt\Class_ だとまだクラスの解析が終わっていないので、$scope->getClassReflection() が取得できずにnullになってしまう
        return InClassNode::class;
    }

    /**
     * @inheritDoc
     */
    public function processNode(Node $node, Scope $scope): array
    {
        $classReflection = $scope->getClassReflection();

        // ShouldQueue インターフェースを実装しているかチェック
        if ($classReflection === null || !$classReflection->implementsInterface(ShouldQueue::class)) {
            return [];
        }

        $allowQueueable = $classReflection->hasTraitUse(SerializesModels::class);

        $errors = [];
        $properties = $classReflection->getNativeReflection()->getProperties();

        foreach ($properties as $property) {
            // staticプロパティはシリアライズ対象外なのでスキップ
            if ($property->isStatic()) {
                continue;
            }

            $declaringClassName = $property->getDeclaringClass()->getName();
            // 依存パッケージ側はチェックしない
            if (str_starts_with($declaringClassName, 'Illuminate\\')) {
                continue;
            }

            $type = $property->getType();
            if ($type === null) {
                $errors[] = RuleErrorBuilder::message(
                    "Property \${$property->getName()} in job class should have a type declaration.",
                )->identifier('job.propertyMissingType')->build();
                continue;
            }

            // プロパティの型指定チェック
            $phpstanType = $classReflection->getNativeProperty($property->getName())->getReadableType();
            if (!$this->isAllowedType($phpstanType, $allowQueueable)) {
                if ($allowQueueable) {
                    $errors[] = RuleErrorBuilder::message(
                        "Property \${$property->getName()} in job class should be a primitive type, QueueableCollection, or QueueableEntity. Found: {$phpstanType->describe(VerbosityLevel::typeOnly())}",
                    )->identifier('job.propertyType')->build();
                } elseif ($this->isQueueableType($phpstanType)) {
                    $errors[] = RuleErrorBuilder::message(
                        "Property \${$property->getName()} in job class should be a primitive type or use SerializesModels trait. Found: {$phpstanType->describe(VerbosityLevel::typeOnly())}",
                    )->identifier('job.propertyType')->build();
                } else {
                    $errors[] = RuleErrorBuilder::message(
                        "Property \${$property->getName()} in job class should be a primitive type. Found: {$phpstanType->describe(VerbosityLevel::typeOnly())}",
                    )->identifier('job.propertyType')->build();
                }
            }
        }

        return $errors;
    }

    /**
     * $type が許可された型かどうかを判定
     *
     * @param bool $allowQueueable Queueableな型を許容するか
     */
    private function isAllowedType(Type $type, bool $allowQueueable): bool
    {
        // 1. まず Null を型から取り除く（Nullable をシンプルに扱うため）
        $type = TypeCombinator::removeNull($type);

        // 元が null のみだった場合は NeverType(BottomType) になるので許可
        if ($type instanceof NeverType) {
            return true;
        }

        // 2. 配列（またはそのUnion）の判定
        // removeNull したおかげで、`array|null` も安全にここでキャッチできます
        if ($type->isArray()->yes()) {
            return $this->isAllowedType($type->getIterableValueType(), $allowQueueable);
        }

        // 3. スカラー、またはEnumの判定
        // `int|string` のような同種のUnionであっても、yes() が true になります
        if ($type->isScalar()->yes() || $type->isEnum()->yes()) {
            return true;
        }

        // 4. Queueableなオブジェクトの判定
        if ($allowQueueable && $this->isQueueableType($type)) {
            return true;
        }

        // 5. 異種の複合型（例: `int|array` や `string|QueueableEntity`）のフォールバック処理
        // instanceof UnionType を避け、PHPStan公式の安全な分解ユーティリティを使います
        $types = TypeUtils::flattenTypes($type);
        if (count($types) > 1) {
            foreach ($types as $innerType) {
                if (!$this->isAllowedType($innerType, $allowQueueable)) {
                    return false;
                }
            }
            return true;
        }

        return false;
    }

    /**
     * Queueableな型かを判定
     */
    private function isQueueableType(Type $type): bool
    {
        if ($type->isObject()->no()) {
            return false;
        }

        if ($this->queueableObjectTypes === null) {
            $this->queueableObjectTypes = [
                new ObjectType(QueueableCollection::class),
                new ObjectType(QueueableEntity::class),
            ];
        }
        foreach ($this->queueableObjectTypes as $queueableObjectType) {
            if ($queueableObjectType->isSuperTypeOf($type)->yes()) {
                return true;
            }
        }
        return false;
    }
}

テスト

PHPStan\Testing\RuleTestCase クラスを継承して、カスタムルールに対するテストコードを書くことができます。

<?php

declare(strict_types=1);

namespace Tests\CustomPHPStan\Rules;

use CustomPHPStan\Rules\Jobs\JobOnlyPrimitiveOrQueueablePropertiesRule;
use PHPStan\Rules\Rule;
use PHPStan\Testing\RuleTestCase;

/**
 * @extends RuleTestCase<JobOnlyPrimitiveOrQueueablePropertiesRule>
 */
class JobOnlyPrimitiveOrQueueablePropertiesRuleTest extends RuleTestCase
{
    protected function getRule(): Rule
    {
        return new JobOnlyPrimitiveOrQueueablePropertiesRule();
    }

    public function testRule(): void
    {
        $this->analyse([__DIR__ . '/data/job-only-primitive-or-queueable-properties-args.php'], [
            [
                'Property $noTypeHint in job class should have a type declaration.',
                8,
            ],
            [
                'Property $carbon in job class should be a primitive type. Found: Illuminate\Support\Carbon|null',
                8,
            ],
            // ...
            [
                'Property $model in job class should be a primitive type or use SerializesModels trait. Found: Illuminate\Database\Eloquent\Model',
                249,
            ],
        ]);
    }
}

// tests/CustomPHPStan/Rules/data/job-only-primitive-or-queueable-properties-args.php

<?php

declare(strict_types=1);

use Carbon\CarbonInterface;
use Illuminate\Support\Carbon;

class TestJob implements \Illuminate\Contracts\Queue\ShouldQueue
{
    public $noTypeHint;

    public function __construct(
        public Carbon $carbon,
    ) {
    }
}

// ShouldQueue を implement していないならオブジェクトをプロパティに持ってもOK
class NotShouldQueue
{
    public function __construct(
        private Carbon $carbon,
    ) {
    }
}

// SerializesModels trait を使っていないモデルを持つジョブはNG
class NotSerializesModelJob implements \Illuminate\Contracts\Queue\ShouldQueue
{
    public function __construct(
        public \Illuminate\Database\Eloquent\Model $model,
    ) {
    }
}

// SerializesModels trait を使っているモデルを持つジョブはOK
class SerializesModelJob implements \Illuminate\Contracts\Queue\ShouldQueue
{
    use \Illuminate\Queue\SerializesModels;

    /**
     * @template TModel of \Illuminate\Database\Eloquent\Model
     * @param TModel $model
     * @param \Illuminate\Database\Eloquent\Collection<int, TModel> $models
     */
    public function __construct(
        public \Illuminate\Database\Eloquent\Model $model,
        public \Illuminate\Database\Eloquent\Collection $models,
    ) {
    }
}

PHPStan へのカスタムルール組み込み

このカスタムルールを組み込むことで、Pull Request の段階でCIから問題を検知できます。

# phpstan.neon
rules:
    - CustomPHPStan\Rules\JobOnlyPrimitiveOrQueueablePropertiesRule

カスタムルール適用後の実行結果

<?php

namespace App\Jobs;

use Carbon\CarbonInterface;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;

class HogeJob implements ShouldQueue
{
    use Dispatchable;
    use InteractsWithQueue;
    use Queueable;

    private function __construct(
        private readonly CarbonInterface $triggeredAt,
    ) {
    }

    public function handle(): void
    {
        // ...

 ------ --------------------------------------------------------------------
  Line   app/Jobs/HogeJob.php
 ------ --------------------------------------------------------------------
  13     Property $triggeredAt in job class should be a primitive type.
         Found: Carbon\CarbonInterface
         🪪  job.propertyType
 ------ --------------------------------------------------------------------

無事にシリアライズ時に危険性がある Job を検出できるようになりましたね！

まとめ

今回ご紹介した PHPStan カスタムルールを導入することによって、シリアライズで危険性がある実装があった際に、自動検知する仕組みが導入できました。

この仕組みを応用することで、Job 以外でも同様な検知を仕組み化できます。例えば Redis にシリアライズ化してオブジェクトキャッシュを保存していたりする場合に、オブジェクトがあったら検知するといったことも可能です。

PHPStan のカスタムルールは最初は書き方が分からなくてとっつきにくい印象ですが、うまく使うとチェックを仕組み化できるため、かなり便利です。

ぜひ皆さんもカスタムルールを活用してみてください！

ColoplTechについて

Why Is instanceof *Type Wrong and Getting Deprecated?↩
Job の場合は、Model に関してはそもそも SerializesModels trait を use して、Model インスタンスはシリアライズしないようにするのが適切です。↩
厳密には既存のジョブに対して新規で trait を use したり外すと、 unserialize() に失敗し ErrorException が発生する可能性があります。今回ご紹介する方法では検知が困難なため、検知対象外としています。↩

PHPStanのカスタムルールの作り方 - ASTを理解してプロジェクト固有の検査を実装する

2026-02-12T11:30:00+09:00

こんにちは。バックエンドエンジニアの平野です。

前回の記事では、運用中のタイトルに静的解析を導入してコード品質を継続的に改善した話を紹介しました。

今回はPHPStanの機能のひとつである、ユーザー独自の静的解析ルールを定義できる「カスタムルール」の作り方を解説します。

カスタムルールとは

PHPの静的解析ツールであるPHPStanには、標準のルールセットに加えてユーザー独自の解析ルールを定義できる機能があります。 phpstan.org

カスタムルールを使うことで、以下のような要件をコードレビューではなく自動チェックで検出できるようになります。

特定の関数の使用を禁止したい
クラス名に一定の命名規則を持たせたい
依存関係に一定の制約を持たせたい

カスタムルールを作成するメリット

カスタムルールを導入することで、プロジェクトの開発効率とコード品質を向上できます。

プロジェクトのビジネスロジックに特化したルールを定義すれば、標準ルールでは検知できない特有のバグや問題を検出できます。特定のデザインパターンの違反やAPI使用規約の遵守、データベースアクセスパターンの制約なども自動チェックの対象にできます。

また、命名規則や禁止パターンのチェックを自動化すれば、コードレビューの負担を軽減でき、レビュアーはビジネスロジックの妥当性やアーキテクチャ設計といった、より重要な論点に集中できます。

プロジェクトやチーム固有のコーディング規約が自動チェックされることで、新規メンバーのオンボーディングもスムーズになり、コードベース全体の一貫した品質維持にもつながります。

PHPStanの動作原理

カスタムルールを作成するために、まずPHPStanがどのようにコードを解析しているかを理解します。

PHPStanは内部でPHPの構文解析器を使用し、プログラムをAST（抽象構文木）という中間表現に変換してコードを解析しています。

ASTとは

ASTとはプログラムにおける演算子や変数、キーワードを木構造で表現したものです。

例えば、nikic/PHP-ParserはPHPのプログラムをASTに変換するパーサーで、PHPStanの内部でも使用されています。このパーサーを使って1+2という演算を変換してみます。

<?php

use PhpParser\ParserFactory;

$parser = (new ParserFactory)->create(ParserFactory::PREFER_PHP7);
$ast = $parser->parse('<?php 1+2 ?>');

出力は以下のようになります。

[
  PhpParser\Node\Stmt\Expression {
    +expr: PhpParser\Node\Expr\BinaryOp\Plus {
      +left: PhpParser\Node\Scalar\LNumber {
        +value: 1,
      },
      +right: PhpParser\Node\Scalar\LNumber {
        +value: 2,
      },
    },
  },
]

入れ子構造の結果が得られました。

ノードの操作

各ノードは子ノードへの参照をプロパティとして持っているため、以下のようにアクセスできます。

<?php 

$ast[0]->expr->left->value;    // 1

この構造を視覚的に表現すると以下のようになります。

$ast[0]
  └─ expr (Expr\BinaryOp\Plus)
      ├─ left (Scalar\LNumber)
      │   └─ value: 1
      └─ right (Scalar\LNumber)
          └─ value: 2

演算式全体のノードを根として、+演算子の子ノード、さらにその下に左右のスカラー値のノードが連なる木構造になっています。

一部のノードは自身の型に関する情報も持っており、型の妥当性チェックに利用できます。

<?php 

$ast[0]->expr->getType();        // Expr_BinaryOp_Plus
$ast[0]->expr->left->getType();  // Scalar_LNumber

より複雑な例

次に、プロパティとアクセサを持つ簡単なクラスを変換してみます。

<?php 

$code = <<<'CODE'
<?php

class Foo
{
    private int $bar;

    public function getBar(): int
    {
        return $this->bar;
    }

    public function setBar(int $value): void
    {
        $this->bar = $value;
    }
}
CODE;

$ast = $parser->parse($code);

変換結果は少し長いので中間要素を抜き出すと以下のようになります。

[
  PhpParser\Node\Stmt\Class_ {
    +name: PhpParser\Node\Identifier {
      +name: "Foo",
    },
    +stmts: [
      PhpParser\Node\Stmt\Property {},
      PhpParser\Node\Stmt\ClassMethod {},
      PhpParser\Node\Stmt\ClassMethod {},
    ],
    +attrGroups: [],
    +namespacedName: null,
    +flags: 0,
    +extends: null,
    +implements: [],
  },
]

根にクラス宣言のノードStmt\Class_があり、nameとstmtsに以下の子ノードが連なっています。

クラスの識別子 Identifier
プロパティ Stmt\Property
クラスメソッド Stmt\ClassMethod（2つ）

さらにそれぞれの要素を見ていくと以下のような構成になっています。

<?php 

$ast[0]->name->name;                          // "Foo"

$ast[0]->stmts[0]->props[0]->name->name;     // "bar"
$ast[0]->stmts[1]->name->name;               // "getBar"
$ast[0]->stmts[1]->returnType->name;         // "int"
$ast[0]->stmts[2]->params[0]->type->name;    // "int"

$ast[0] (Stmt\Class_)
  ├─ name (Identifier)
  │   └─ name: "Foo"
  └─ stmts (array)
      ├─ [0] (Stmt\Property)
      │   └─ props[0]
      │       └─ name: "bar"
      ├─ [1] (Stmt\ClassMethod)
      │   ├─ name: "getBar"
      │   └─ returnType
      │       └─ name: "int"
      └─ [2] (Stmt\ClassMethod)
          ├─ name: "setBar"
          └─ params[0]
              └─ type
                  └─ name: "int"

クラス定義のノードを根として、クラス名、プロパティ、メソッドが階層的に配置されています。各メソッドはさらに戻り値の型や引数の型情報を持っています。

PHPStanはこのようなASTを探索してコードを解析しており、カスタムルールもこのデータ構造に基づいて実装します。

カスタムルールの作成方法

実際にカスタムルールを作成する手順を見ていきます。

1. ルールクラスの作成

PHPStanが提供するPHPStan\Rules\Ruleインターフェースを実装したクラスを作成します。

<?php

declare(strict_types=1);

namespace Namespace\To\RuleFile;

use PhpParser\Node;
use PHPStan\Rules\Rule;
use PHPStan\Analyser\Scope;

class SampleCustomRule implements Rule
{
    public function getNodeType(): string {}

    public function processNode(Node $node, Scope $scope): array {}
}

2. 設定ファイルへの登録

phpstan.neonのrulesブロックに作成したカスタムルールの名前空間を追加します。

rules:
    - Namespace\To\RuleFile\SampleCustomRule

これで次回の実行時から追加ルールが適用されます。

3. getNodeType()の実装

getNodeType()は、このルールがどのタイプのノードに対して適用されるかを宣言するメソッドです。

PHPStanはASTを探索する際、すべてのノードをこのメソッドで指定した型と照合し、マッチしたノードのみを後述するprocessNode()に渡します。

戻り値にはPhpParser\Nodeのサブクラスのクラス名（class-string）を指定します。

<?php 

// 演算子のノードのみを対象とする場合
public function getNodeType(): string
{
    return BinaryOp::class;
}

// メソッド呼び出しのノードのみを対象とする場合
public function getNodeType(): string
{
    return MethodCall::class;
}

例えばBinaryOp::classを指定すると、コード中の+、-、*、/などの演算子ノードだけがprocessNode()に渡され、変数やメソッド呼び出しなどは無視されます。

4. processNode()の実装

processNode()は実際の解析処理を定義するメソッドです。getNodeType()でマッチしたノードに対して実行されます。

Nodeパラメータの活用

第1引数の$nodeは、getNodeType()で指定した型にマッチしたノードです。ノードタイプに応じた様々なプロパティを持っており、コードの詳細な情報にアクセスできます。

<?php 

// 二項演算子ノード（BinaryOp）の場合
$node->left;   // 左辺のノード
$node->right;  // 右辺のノード

// メソッド呼び出しノード（MethodCall）の場合
$node->var;    // メソッドが呼ばれるオブジェクト
$node->name;   // メソッド名
$node->args;   // 引数のリスト

// クラスノード（Class_）の場合
$node->name;       // クラス名
$node->extends;    // 継承元クラス
$node->implements; // 実装するインターフェース
$node->stmts;      // クラス内の実装（メソッドやプロパティ）

戻り値の形式

processNode()の戻り値はIdentifierRuleErrorの配列です。ルール違反を検出した場合はRuleErrorBuilderでエラーを構築し、問題がなければ空配列を返します。

<?php 

use PHPStan\Rules\RuleErrorBuilder;

/**
 * ゼロ除算の検査
 */
public function processNode(Node $node, Scope $scope): array
{
    // ノードが除算演算子かつ右辺が数値の0ならエラーを返す
    if ($node instanceof Node\Expr\BinaryOp\Div
        && $node->right instanceof Node\Scalar\LNumber
        && $node->right->value === 0) {
        return [
            RuleErrorBuilder::message('zero division error')
                ->identifier('custom.zeroDivision')
                ->build()
        ];
    }
    // 問題ない場合は空配列を返す
    return [];
}

RuleErrorBuilderのmessage()でエラーメッセージを設定し、identifier()でエラーの識別子を指定します。識別子はエラーの分類や抑制設定に使用されます。

Scopeの活用

第2引数の$scopeは、ノード単体では取得できない文脈の情報を提供します。

Scopeの役割

Scopeオブジェクトは、現在解析中のコードのスコープに関する情報を保持しています。具体的には以下のような情報にアクセスできます。

現在のクラスやメソッドの情報
変数や式の型情報
名前空間の情報
利用可能な関数やクラスの情報

Scopeの主な機能

1. 型情報の取得

PHPStanの型推論エンジンによって計算された、ノードの式が持つ型を取得できます。

<?php 

// 式の型を取得
$type = $scope->getType($node->var);

// 型をチェック
if ($type->isObject()->yes()) {
    $classNames = $type->getObjectClassNames();  // クラス名を取得
}

2. クラス情報の取得

現在のスコープが属するクラスの情報を取得できます。

<?php 

// 現在のクラスのリフレクション情報を取得
$classReflection = $scope->getClassReflection();
if ($classReflection !== null) {
    $className = $classReflection->getName();           // クラス名
    $parentClass = $classReflection->getParentClass();  // 親クラス
    $interfaces = $classReflection->getInterfaces();    // 実装インターフェース
}

3. メソッド情報の取得

現在のスコープが属するメソッドの情報を取得できます。

<?php 

// 現在のメソッド名を取得
$methodReflection = $scope->getFunction();
if ($methodReflection !== null) {
    $methodName = $methodReflection->getName();
}

4. 変数の型チェック

スコープ内で定義された変数の型を確認できます。

<?php 

// 変数が定義されているかチェック
if ($scope->hasVariableType('variableName')->yes()) {
    $variableType = $scope->getVariableType('variableName');
}

Scopeの実践例

メソッド呼び出し元の実装クラスを取得する例です。

<?php 

// メソッド呼び出しノードの場合
// $node: Node\Expr\MethodCall

$calledOnType = $scope->getType($node->var);
if ($calledOnType->isObject()->yes()) {
    $classNames = $calledOnType->getObjectClassNames();
    // $classNamesには実際のクラス名が入る
}

$node->varだけでは変数名しか分かりませんが、$scope->getType()を使うことで、その変数の実際の型（クラス名）を解決できます。

ノード別の実装例

ここからは、ノードごとのユースケースと実装例を紹介します。

変数と代入（Node\Expr\Variable, Node\Expr\Assign）

変数名の命名規則をチェックする例です。

<?php 

public function getNodeType(): string
{
    return Node\Expr\Variable::class;
}

public function processNode(Node $node, Scope $scope): array
{
    if (is_string($node->name) && preg_match('/^[a-z][a-zA-Z0-9]*$/', $node->name) !== 1) {
        return [
            RuleErrorBuilder::message("変数名はキャメルケースで記述してください: \${$node->name}")
                ->identifier('custom.variable.camelCase')
                ->build()
        ];
    }
    return [];
}

演算子（Node\Expr\BinaryOp）

浮動小数点数を含む演算で誤差の可能性を警告する例です。

<?php 

public function getNodeType(): string
{
    return Node\Expr\BinaryOp::class;
}

public function processNode(Node $node, Scope $scope): array
{
    if (($node instanceof BinaryOp\Plus
        || $node instanceof BinaryOp\Minus
        || $node instanceof BinaryOp\Mul
        || $node instanceof BinaryOp\Div
        || $node instanceof BinaryOp\Mod
        || $node instanceof BinaryOp\Pow
    ) && (
        $scope->getType($node->right)->isFloat()->yes()
        || $scope->getType($node->left)->isFloat()->yes()
    )) {
        return [
            RuleErrorBuilder::message('浮動小数点数を含む演算です。誤差の可能性があります')
                ->identifier('custom.float.arithmetic')
                ->build()
        ];
    }
    return [];
}

インスタンス化（Node\Expr\New_）

Singletonパターンのクラスが直接インスタンス化されていないかチェックする例です。

<?php 

public function getNodeType(): string
{
    return Node\Expr\New_::class;
}

public function processNode(Node $node, Scope $scope): array
{
    // Singletonを名前に含むクラスがnewされていないか
    if ($node->class instanceof Name) {
        // クラス名のみを取得（名前空間を除く）
        $className = $node->class->getLast();
        if (str_contains($className, 'Singleton')) {
            return [
                RuleErrorBuilder::message('このクラスのインスタンス化は禁止されています')
                    ->identifier('custom.singleton.new')
                    ->build()
            ];
        }
    }
    return [];
}

メソッド呼び出し（Node\Expr\MethodCall, Node\Expr\StaticCall）

PHPDocの@deprecatedタグが付けられたメソッドの使用を検出する例です。非推奨APIを段階的に廃止する際に有用です。

<?php 

public function getNodeType(): string
{
    return Node\Expr\MethodCall::class;
}

public function processNode(Node $node, Scope $scope): array
{
    if (!$node->name instanceof Node\Identifier) {
        return [];
    }

    $calledOnType = $scope->getType($node->var);

    if (!$calledOnType->isObject()->yes()) {
        return [];
    }

    $methodName = $node->name->toString();

    // メソッドの型情報を取得
    if ($calledOnType->hasMethod($methodName)->yes()) {
        $methodReflection = $calledOnType->getMethod($methodName, $scope);

        // PHPDocから@deprecatedタグをチェック
        $docComment = $methodReflection->getDocComment();
        if ($docComment !== null && str_contains($docComment, '@deprecated')) {
            $classNames = $calledOnType->getObjectClassNames();
            return [
                RuleErrorBuilder::message(sprintf(
                    "非推奨メソッド %s::%s() が使用されています",
                    $classNames[0],
                    $methodName,
                ))
                    ->identifier('custom.method.deprecated')
                    ->build()
            ];
        }
    }

    return [];
}

可変関数（$func()のような形式）の使用を検出する例です。

<?php 

public function getNodeType(): string
{
    return Node\Expr\FuncCall::class;
}

public function processNode(Node $node, Scope $scope): array
{
    // 関数名が変数の場合（可変関数）
    if ($node->name instanceof Node\Expr\Variable) {
        return [
            RuleErrorBuilder::message('可変関数の使用は推奨されません。静的解析が困難になります')
                ->identifier('custom.function.variable')
                ->build()
        ];
    }

    return [];
}

関数呼び出し（Node\Expr\FuncCall）

危険な関数の使用を検出する例です。セキュリティ上のリスクがある関数を禁止することで、脆弱性の混入を防げます。

<?php 

public function getNodeType(): string
{
    return Node\Expr\FuncCall::class;
}

public function processNode(Node $node, Scope $scope): array
{
    if ($node->name instanceof Name) {
        $functionName = $node->name->toString();

        // セキュリティリスクのある関数リスト
        $dangerousFunctions = [
            'exec' => 'コマンドインジェクションのリスクがあります',
            'shell_exec' => 'コマンドインジェクションのリスクがあります',
            'system' => 'コマンドインジェクションのリスクがあります',
            'passthru' => 'コマンドインジェクションのリスクがあります',
        ];

        if (isset($dangerousFunctions[$functionName])) {
            return [
                RuleErrorBuilder::message(sprintf(
                    "危険な関数 %s() の使用は禁止されています: %s",
                    $functionName,
                    $dangerousFunctions[$functionName]
                ))
                    ->identifier('custom.function.dangerous')
                    ->build()
            ];
        }
    }
    return [];
}

クラス定義（Node\Stmt\Class_）

クラス名の命名規則をチェックする例です。

<?php 

public function getNodeType(): string
{
    return Node\Stmt\Class_::class;
}

public function processNode(Node $node, Scope $scope): array
{
    if ($node->name !== null) {
        $className = $node->name->toString();

        // クラス名がPascalCaseになっているかチェック
        if (preg_match('/^[A-Z][a-zA-Z0-9]*$/', $className) !== 1) {
            return [
                RuleErrorBuilder::message("クラス名はPascalCaseで記述してください: {$className}")
                    ->identifier('custom.class.pascalCase')
                    ->build()
            ];
        }
    }
    return [];
}

制御構文（Node\Stmt\If, Node\Stmt\Switch）

switch(true)のようなアンチパターンを検出する例です。

<?php 

public function getNodeType(): string
{
    return Node\Stmt\Switch_::class;
}

public function processNode(Node $node, Scope $scope): array
{
    // switch(true)のようなcaseでブール式を評価させるケースの検出
    if ($node->cond instanceof Node\Expr\ConstFetch
        && $node->cond->name->toString() === 'true') {
        return [
            RuleErrorBuilder::message('switch(true)の使用は推奨されません。if-elseifを使用してください')
                ->identifier('custom.switch.true')
                ->build()
        ];
    }
    return [];
}

例外処理（Node\Stmt\TryCatch）

空のcatchブロックを検出する例です。

<?php 

public function getNodeType(): string
{
    return Node\Stmt\TryCatch::class;
}

public function processNode(Node $node, Scope $scope): array
{
    foreach ($node->catches as $catch) {
        if (count($catch->stmts) === 0) {
            return [
                RuleErrorBuilder::message('空のcatchブロックは避けてください。最低限ログ出力を行ってください')
                    ->identifier('custom.catch.empty')
                    ->build()
            ];
        }
    }
    return [];
}

カスタムルール実装のポイント

ここまでの実装例を踏まえて、ポイントをまとめます。

1. ノードタイプの選択

検出したいパターンに最も近いノードタイプをgetNodeType()で指定します。メソッド呼び出しならMethodCall、クラス定義ならClass_というように、対象を絞ることで不要なノードの処理をスキップできます。

2. Scopeを活用した型解決

ノード単体では変数名やメソッド名しか分かりませんが、Scopeを使うことで実際の型情報を解決でき、より高度なチェックが可能になります。

3. 段階的な条件チェック

instanceofによる型チェックと早期リターンを活用することで、コードの可読性と安全性を保てます。

4. 分かりやすいエラーメッセージ

エラーメッセージには、何が問題でどうすれば良いかを明確に記載することで、開発者が素早く修正できます。

これらの実装例はプロジェクトの要件に合わせてカスタマイズできます。

Rectorへの応用

PHPStanがコードの問題を検出するツールであるのに対し、Rectorはコードを自動的に書き換えるリファクタリングツールです。RectorもPHPStanと同様にASTを使用してコードを解析・変更するため、カスタムルールで学んだASTの知識をそのまま活用できます。

Rectorの既定ルールの紹介

Rectorには、PHPのバージョンアップやコードの近代化に役立つ既定ルールが多数用意されています。いくつか紹介します。

1. PHPバージョンアップ対応

PHP 7.4から8.0への移行時に、nullセーフ演算子を自動で適用するNullsafeOperatorRectorです。

<?php 

// rector.php
use Rector\Php80\Rector\If_\NullsafeOperatorRector;

$rectorConfig->rule(NullsafeOperatorRector::class);

<?php 

// Before
$country = null;
if ($session !== null) {
    $user = $session->user;
    if ($user !== null) {
        $address = $user->getAddress();
        if ($address !== null) {
            $country = $address->country;
        }
    }
}

// After (Rector適用後)
$country = $session?->user?->getAddress()?->country;

2. 条件文のリファクタリング

三項演算子を簡潔なnull合体演算子に置き換えるTernaryToNullCoalescingRectorです。

<?php 

// rector.php
use Rector\Php70\Rector\Ternary\TernaryToNullCoalescingRector;

$rectorConfig->rule(TernaryToNullCoalescingRector::class);

<?php 

// Before
$name = isset($user['name']) ? $user['name'] : 'Guest';

// After (Rector適用後)
$name = $user['name'] ?? 'Guest';

3. declare文の自動追加

全てのPHPファイルにdeclare(strict_types=1)を自動で追加するDeclareStrictTypesRectorです。

<?php 

// rector.php
use Rector\TypeDeclaration\Rector\StmtsAwareInterface\DeclareStrictTypesRector;

$rectorConfig->rule(DeclareStrictTypesRector::class);

<?php

// Before
namespace App;

// After (Rector適用後)
<?php

declare(strict_types=1);

namespace App;

4. 名前空間の整理

完全修飾名（FQCN）を使っている箇所をuse文に集約する機能です。これは個別のルールではなく、Rectorの設定メソッド importNames() で有効化します。

<?php 

// rector.php
$rectorConfig->importNames();

<?php 

// Before
public function process(): \App\Service\UserService
{
    return new \App\Service\UserService();
}

// After (Rector適用後)
use App\Service\UserService;

public function process(): UserService
{
    return new UserService();
}

これらの既定ルールを使うだけでも、コードの品質向上や保守性の改善に貢献します。

Rectorのカスタムルール例

既定ルールに加えて、プロジェクト固有のルールも作成できます。古いメソッドを新しいメソッドに自動置換するルールの例です。

<?php 

use PhpParser\Node;
use PhpParser\Node\Expr\MethodCall;
use PhpParser\Node\Identifier;
use Rector\Rector\AbstractRector;
use Symplify\RuleDocGenerator\ValueObject\RuleDefinition;

final class RenameOldMethodRector extends AbstractRector
{
    public function getRuleDefinition(): RuleDefinition
    {
        return new RuleDefinition('Rename oldMethod to newMethod', []);
    }

    public function getNodeTypes(): array
    {
        return [MethodCall::class];
    }

    public function refactor(Node $node): ?Node
    {
        if (!$node instanceof MethodCall) {
            return null;
        }

        if (!$this->isName($node->name, 'oldMethod')) {
            return null;
        }

        $node->name = new Identifier('newMethod');
        return $node;
    }
}

PHPStanのprocessNode()が問題を検出してエラーメッセージを返すのに対し、Rectorのrefactor()はノードを書き換えて返すことで、実際にコードを変更します。

まとめ

PHPStanのカスタムルールは、標準のルールだけではカバーできない、プロジェクト固有の検査要件に対応できる強力な機能です。

カスタムルールの有用性

本記事では、ASTの基本的な概念からカスタムルールの実践的な作成方法まで解説しました。

ASTの仕組みを理解すれば、変数の命名規則チェックから複雑な依存関係の検証まで、プロジェクトの要件に合わせた多様なルールを実装できます。NodeとScopeを組み合わせることで、ノードの構造だけでなく型情報やクラス情報を用いた高度な解析も可能です。

実務での活用ポイント

カスタムルールを実務で活用する際のポイントは以下の通りです。

1. 段階的な導入

最初からすべての要件を満たす必要はありません。まずは命名規則チェックなどの簡単なルールから始めて、徐々に拡張していくのが効果的です。

2. チームでのルール共有

カスタムルールはチーム全体で合意を取ることが重要です。ルールの意図や背景をドキュメント化し、機械的にチェックする部分と人間が判断する部分を明確に分けることで、レビュー時間を短縮しつつ品質を保てます。

3. 継続的な改善

プロジェクトの成長に合わせてルールも進化させていく必要があります。誤検知が多いルールは改善し、新たな課題が見つかれば新しいルールを追加することで、コードベースの品質を継続的に向上できます。

発展的な活用

カスタムルールで学んだASTの知識は、Rectorなど他のPHPツールにも応用できます。静的解析とコード変換を組み合わせることで、「問題を検出する」だけでなく「問題を自動で修正する」という、一歩進んだコード品質管理が実現できます。

最後に

ぜひプロジェクトの要件に合わせたカスタムルールを作成し、コードベースの品質向上に役立ててください。

参考資料

PHPStan - PHP Static Analysis Tool
PHPStan Custom Rules
nikic/PHP-Parser - PHPのASTパーサー
Rector - Instant Upgrades and Automated Refactoring

ColoplTechについて

k6 + Cursor の負荷試験がとても手軽だった件

2025-11-04T11:00:00+09:00

こんにちは、バックエンドエンジニアの岡村です。

新サービス「FANPARK」をリリースするにあたり、負荷試験を実施しました。今回は負荷試験ツールとしてk6を採用し、その手軽さに驚いたので、この経験を共有させていただきます。特に、AIエージェント（Cursor）がほとんどの作業を代行してくれたことで、負荷試験の実施が非常にスムーズに進みました。

背景

「FANPARK」は、位置ゲーのノウハウを活用してライブの待ち時間を遊び時間に変える新サービスです。10月に開催されたファッションと音楽が交差するスペシャルイベント「ZOZOFES」に導入しました。会場であるKアリーナは2万人のキャパシティを有しており、来場が一番多くなるのは開場時間周辺ということで、それなりの負荷が予想される状況でした。

今回のサービスはWebサービスとして実装しており、フロントエンド側はNext.js、バックエンドはLaravelで構築されています。ゲームタイトルの負荷試験を行う際は、弊社のゲーム基盤に最適化された内製ツール(Go言語)を使用していますが、今回は比較的シンプルなWebサービスであるため、より一般的な負荷試験ツールでの実施を検討しました。

k6について簡単な説明

k6は、JavaScriptでスクリプトを記述できる軽量な負荷試験ツールです。データ可視化ツールでお馴染みのGrafana Labsが開発とメンテナンスを行っています。従来の負荷試験ツールと比較して、以下の特徴があります。

JavaScriptで記述できるため、フロントエンド開発者にとって馴染みのある言語でテストスクリプトを書ける
単一のバイナリファイルで動作し、インストールが簡単
HTTPリクエスト、WebSocket、gRPCなど様々なプロトコルに対応した豊富な機能
時間経過に応じて負荷を段階的に増減させる設定が可能
レスポンス時間、スループット、エラー率などの詳細な統計情報を提供

k6を選んだ理由

負荷試験ツールの選定において、次の理由からk6を選択しました。

JavaScriptでシナリオが書けるため、フロントエンドのコードをある程度流用して負荷試験が可能
Webサービスに特化した負荷試験ツールとして適している
「FANPARK」がWebサービスとして比較的シンプルだったことも後押し

これらの理由から、k6が今回の負荷試験に最適なツールであると判断しました。

k6の導入と設定

インストール

k6のインストールは非常にシンプルでした。macOS + Homebrew 環境では以下のコマンドだけでインストールできます

brew install k6

テストスクリプトの作成

まずはドキュメント通りに雛形を作成し、簡単なシナリオをCursorに書いてもらいました。

# scenario.jsという名前で雛形を作成
k6 new scenario.js

実際に作成したk6 スクリプトの例を以下に示します。

import http from 'k6/http';
import { check, sleep } from 'k6';

export let options = {
  vus: 1, // 1ユーザーで実行
  duration: '30s', // 30秒間実行
};

export default function () {
  // ユーザー登録APIの呼び出し
  let response = http.post('https://api.example.com/user/register', {
    name: 'Test User',
    email: `test${Math.random()}@example.com`,
  });

  check(response, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });

  sleep(1);
}

シナリオの作成

雛形での動作確認が済んだ後は、下記の流れでシナリオを作成しました。

フロントエンド側に実装していた通信基盤周りのコード流用し、Cursorに「k6で負荷試験をしたいので書き換えて」と指示
バックエンド側にE2Eテストを実装していたため、Cursorに「テスト参考にk6の形式でシナリオを書いて」と指示
その後、生成されたコードを見渡して細かい調整をする

AIがサクサクと実装を進めてくれたおかげで、初めて触るk6でもつまづくことがなく非常に助かりました。k6のモジュール(通信部分などにはk6/httpなど)を使用してシナリオを書く必要がありますが、AIがいい感じに実装してくれました。比較的馴染みのあるJavaScriptの実装という点もあり、個人的には生成結果を読みやすかったのも良かったです。

負荷試験の実施

負荷パターン

負荷試験は段階的に実施しました。

初めは簡単なシナリオ、1ユーザーでのシナリオ、次に50人でのシナリオを試す
その後、50人の負荷を5分間、その後100人の負荷を5分間、最後に200人の負荷を5分間、というように段階的に負荷を上げていくシナリオを作成
段階的に負荷を本番想定にしていく

結果と発見

負荷試験の結果、以下のようなことが分かりました。

特別な環境を用意することなく、ローカルPCでも十分な内容の負荷試験を実施できた
負荷試験の結果をいい感じにまとめてくれる
- そのままAIに投げれば要約してくれるので、認知負荷が低い
- 次にすべきこともAIが提案してくれる
時系列のグラフも出力する設定もあって便利
- Cloud RunやCloud SQLのメトリクスを見れば間に合うので、今回は本格的には使用しなかった

k6の負荷試験では以下のような詳細な指標が自動的に出力されます。これらの指標から、レスポンス時間の分布、スループット、エラー率などが一目で分かります。

# 負荷試験の実行
k6 run scenario.js

         /\      Grafana   /‾‾/
    /\  /  \     |\  __   /  /
   /  \/    \    | |/ /  /   ‾‾\
  /          \   |   (  |  (‾)  |
 / __________ \  |_|\_\  \_____/

     execution: local
        script: scenario.js
        output: -

     scenarios: (100.00%) 1 scenario, 10 max VUs, 1m0s max duration (incl. graceful stop):
              * default: 10 looping VUs for 30s (gracefulStop: 30s)



  █ TOTAL RESULTS

    HTTP
    http_req_duration..............: avg=171.56ms min=166.75ms med=171.36ms max=181.49ms p(90)=174.05ms p(95)=174.91ms
      { expected_response:true }...: avg=171.56ms min=166.75ms med=171.36ms max=181.49ms p(90)=174.05ms p(95)=174.91ms
    http_req_failed................: 0.00%  0 out of 250
    http_reqs......................: 250    8.243623/s

    EXECUTION
    iteration_duration.............: avg=1.21s    min=1.16s    med=1.17s    max=2.11s    p(90)=1.17s    p(95)=1.18s
    iterations.....................: 250    8.243623/s
    vus............................: 10     min=10       max=10
    vus_max........................: 10     min=10       max=10

    NETWORK
    data_received..................: 850 kB 28 kB/s
    data_sent......................: 19 kB  609 B/s




running (0m30.3s), 00/10 VUs, 250 complete and 0 interrupted iterations
default ✓ [======================================] 10 VUs  30s

注意点

負荷試験の実施において、以下の点に注意が必要でした。

AIに閾値設定を任せると、想定より緩い設定になる場合があるため注意が必要
- 例えば、latency 5s (めっちゃ遅い!) を許容する設定を提案されることがありました
AIが生成したコードや試験結果の要約は、正しさを検証しつつ利用する必要
- 生成されたコードはブラックボックスとして扱うのでなく、動作原理をなるべく理解しましょう
- 試験結果はインスタンス側のメトリクスを見るなどし、多角的に正しい負荷をかけられていることを確認しましょう

AIエージェント駆動開発の効果

k6とAIエージェント（Cursor）を組み合わせることで、負荷試験の実施が格段に効率化されました。

従来の負荷試験ツール導入では、新しいツールの仕様やAPIを理解する時間、ゼロからテストスクリプトを書く時間、エラー修正や動作確認の時間、そして出力された数値の解釈と改善点の特定など、多くの工程が必要でした。

今回のAIエージェント活用では、これらの工程が効率的に短縮されました。k6の詳細な仕様を覚える必要がなく、AIがk6の構文に準拠したコードを生成してくれます。既存のE2Eテストを参考に、数分でk6 スクリプトを生成でき、エラー発生時もAIが原因と解決策を提案してくれます。負荷試験結果の要約と改善提案も自動化され、開発効率が格段に向上しました。

ただし、 AIエージェントのことを100%信じるのは危険です。 あくまで最短距離へ導くためのツールとして使うのにはとても良いツールですが、生成されたコードや提案された設定は必ず検証が必要です。AIエージェントはk6のことを上手に生成できるようなので、そのような使い方に合っているように感じました。

おわりに

今後のWebサービス開発でも、要件に応じてk6での負荷試験を積極的に検討していきたいと考えています。

k6は負荷試験ツールとして非常に手軽で、特にJavaScriptで書ける点とAIとの相性の良さが印象的でした。シュッと試験したい際にはとても有用なツールだと思います。

より複雑なサービスでの活用については今後検証していきたいと考えています。

今後もk6を活用して、より良いサービスを提供していきたいと思います。

ColoplTechについて

また、コロプラではゲームや基盤開発のバックエンド・インフラエンジニアを積極採用中です！
興味を持っていただいた方はぜひお気軽にご連絡ください。

Tencent Global Digital Ecosystem Summit 2025 参加レポート

2025-10-29T11:00:00+09:00

こんにちは、エンジニアの岡村です。

2025年9月、Tencentからご招待いただき、Tencent Global Digital Ecosystem Summit 2025に参加してきました。このイベントは、Tencentの最新技術や製品、ソリューションが包括的に紹介される年次戦略イベントで、今年で6回目の開催を迎えました。コロプラからは、CIOの菅井と私の2名で参加。私にとっては初海外・初出張という貴重な経験となりました。深圳という都市の魅力、華強北での熱烈なセールス体験、そしてAIコンパニオンの実装事例など、3日間で得られた濃密な体験についてご紹介します。

Tencent Global Digital Ecosystem Summit とは

Tencent Global Digital Ecosystem Summitは、中国・深圳に本社を置くTencentが主催する年次戦略イベントです。AIやクラウドコンピューティングを中心とした最新技術の動向や、金融、ゲーム、製造、医療など様々な業界のデジタル変革について、世界中の企業や専門家が集まって議論する国際的なイベントです。Tencentは「Baidu, Alibaba, Tencent」の頭文字から成る「BAT」の一角を担う世界的なIT・ネットサービス企業で、WeChatやTencent Cloudなどのサービスで知られています。

会場である深圳（Shenzhen）は、中国の経済特区として発展し、現在では世界有数のイノベーション都市として知られています。非常にキャッシュレス化が進んでおり、AI音声アシスタントやスマートシティシステムなど高度なデジタル技術が人々の生活に浸透しています。最新のテクノロジーが日常的に活用されている様子を目にでき、デジタル変革の最前線を体験できました。

1日目：Tencent Cloud International Gala Dinner

イベント初日は、Tencent Cloud International Gala Dinnerからスタートしました。Tencent Cloud の導入を検討もしくは活用している国内の企業の方々との交流ができました。

中にはゲーム業界の方々もおり、「日本ゲーム業界で一致団結してグローバルに戦っていきたいよね」という熱い話を聞く機会がありました。組織や業界全体など大きな視点での議論に参加する機会があり、自分の知識や経験の幅を広げる必要性を感じました。異業種の方々との会話では、Tencent Cloudの導入事例など、具体的な質問をすることでさらに学びを深められる機会でした。

プログラムの中にはTencent Cloudの活用を特に推進した企業への表彰式がありました。数々の日本企業も表彰されており、日本でこれほどTencent Cloudが活用されているのは意外でした。導入時には丁寧なサポートがあるとお聞きしたので、それが要因の一つかもしれません。

2日目：AIワークショップとメインイベント

2日目は、AIワークショップから始まりました。特に印象的だったのは、「Game for Peace (PUBGの中国版) 」というゲームにAIコンパニオンを実装した事例についてでした。

AIコンパニオンとは一緒に仲間として遊んでくれたり、アドバイスをしてくれる存在のことです。マイクを使ったユーザーがより楽しんでゲームをプレイしている傾向がある中、使ったことのないユーザー向けにAIコンパニオンという選択肢を増やしたとのことでした。実際にリリース後、マイクの継続的な使用率が向上し、ユーザーからのポジティブな評判も多いようです。

AIコンパニオンの技術的な実装についてもお聞きしました。記憶領域をいくつか(期間毎など)に分けて管理することで、より効率的にコンテキストを扱える仕組みになっています。

AIコンパニオンと違和感のないコミュニケーションを実装する際には、ユーザーの入力の解釈、コンパニオンを操作するコマンドの理解、ゲームオブジェクトの理解、発話内容の決定、ゲームのフィールドに合うような音声の合成など、さまざまな工程が存在します。これらは単一の万能モデルではなく、音声処理、自然言語理解、環境認識、戦術判断といった各機能に特化した複数のモデルが連携することで実現しているとのことでした。

また、絶対に間違えてはいけない情報（イベントの報酬内容など）は決定論的なロジックにフォワードさせているというのも興味深い点でした。RAGの構築方法も重要で、キャラ設定だけで(中国語で)小説がかけるくらいの量があるらしいです！

Tencent Global Digital Ecosystem Summit で見てきたもの

メインイベントでは、Tencent Cloudを用いた各種ソリューションの展示と公演が行われました。展示会場を2つ貸切して開催されており、カンファレンスも盛況でした（中国語での進行だったので理解はできませんでしたが、会場の熱気は十分に感じることができました）。

特に印象的だった展示の一つが、マクドナルドとの連携事例でした。カーナビにAIAgentを組み込んで音声でモバイルオーダー、決済、目的地設定ができるシステムで、実際にデモンストレーションを見ることができました。

また、Tencent RTCを用いたロボット操作の展示もありました。クレーンゲームを遠隔操作するデモで、リクエストが処理されて戻ってくるまでで合計300msという高速なレスポンス速度を実感できました。

車とドローンの展示も印象的で、中国の車はネットカフェのような状態になっていました。冷蔵庫、カラオケ、高級な皮が貼ってあるシートなど、もう安さでは売れないからラグジュアリーさで差別化を図っているという話を聞き、中国市場の変化を感じることができました。

華強北（Huaqiangbei）見学

メインイベントの合間には、深圳の華強北地区を訪れました。華強北は「中国電子第一街」として知られる世界最大規模の電子部品市場です。

あらゆる種類の電子部品やガジェット、スマートフォン部品、ドローン、AIチップなどが並んでいました。迅速かつ低コストなサプライチェーンが特徴で、試作品のアイデアから完成品までをわずか数日で実現できるとのことです。

有名ブランドの模倣品（山寨（サンザイ）と呼ぶらしい）もたくさん安く販売されていましたが、見た目や機能は一見ほぼ変わらないクオリティに見えました。また、値切り交渉が活発に行われる雑多な雰囲気で、秋葉原や中野のカオスな部分を濃縮したような場所でした。「このAIマウスがすごいから買って！」CIOの菅井が熱烈なセールスを受ける様子も見ることができ、現地の活気を肌で感じました。

3日目：Tencent本社見学

最終日は、Tencentの本社を見学しました。一つの企業でこれほど巨大なビルを建てていることだけでも驚きでしたが、さらに「ペンギン島」というTencentの本社を中心に据えた人工島を建設予定だという話を聞いたときは、その規模感に畏怖の念を覚えました。

本社内では、教育、交通、通信、医療、決済、データセンター、建設、オートメーション、エンタメなど数々の事業領域への貢献を展示していました。中国国内のデジタル産業のほとんどに関わっているような勢いで、その影響力の大きさを実感しました。

Tencentの企業文化や技術開発の取り組みについて詳しく説明を受け、大規模な技術組織がどのようにイノベーションを生み出しているかを学びました。

学びと今後の展望

今回の参加を通じて、多くの学びと気づきを得ることができました。

今回の参加で得た知見を、コロプラの各事業に活かしていきたいと考えています。特にAIコンパニオンの実装事例は、今後のゲーム開発において非常に参考になるものでした。単一のLLMのみを用いるのではなく、複数モデルを併用するアプローチや記憶領域の工夫など、実用的かつ合理的で、誰もが楽しめるAI実装のヒントを今後の開発に活かしていきたいと思います。

また、国内の技術動向はもちろん、グローバルな視点での技術戦略についても継続的に学習を深めていきたいと思います。今後もこのような国際的なイベントに積極的に参加し、世界の技術動向を把握することで、コロプラの技術力向上に貢献していきたいと考えています。

おわりに

Tencent Global Digital Ecosystem Summit 2025への参加は、私にとって非常に貴重な経験となりました。初海外・初出張という個人的な体験も含めて、多くの学びと気づきを得ることができました。

華強北での熱烈なセールス体験、AIコンパニオンの実装詳細、そして深圳の活気ある街並みなど、すべてが新鮮で刺激的な体験でした。

コロプラでは、最新のテクノロジーと独創的なアイデアで新しい体験を追求し、人々の日常をより楽しく、より素晴らしくしていくことを目指しています。今回の経験で得た知見を活かし、今後もこの目標に向けて取り組んでいきたいと思います。

最後に、このような貴重な機会を提供していただいた関係者の皆様に心より感謝申し上げます。

ColoplTechについて

Claude Codeのプラグイン機能で社内向けプラグインマーケットプレイスを作った

2025-10-17T11:00:00+09:00

こんにちは、エンジニアの山田（@yamadashy）です。

Claude Codeにプラグイン機能が追加されたので、実際に触ってみるために社内向けのプラグインマーケットプレイスを作ってみました。この記事では、プラグイン機能の概要と、実際に作ってみてわかったことを共有します。

Claude Codeのプラグイン機能とは

2025年10月10日、Claude Codeにプラグイン機能がリリースされました。

Today we’re introducing Claude Code Plugins in public beta.

Plugins allow you to install and share curated collections of slash commands, agents, MCP servers, and hooks directly within Claude Code. pic.twitter.com/pF50UJ5zOo
— Claude (@claudeai) 2025年10月9日

x.com

www.anthropic.com

プラグイン機能を使うことで、Claude Codeのカスタマイズ設定を共有できるようになります。個々のプラグインには、以下のような要素を含めることができます。

カスタムコマンド
エージェント
フック
MCPサーバーの設定

これらを「マーケットプレイス」という単位でまとめて配布する仕組みです。1つのGitHub リポジトリが1つのマーケットプレイスになり、その中に複数のプラグインを含められます。

マーケットプレイス (GitHubリポジトリ)
  ├── プラグイン1 (MCP設定)
  ├── プラグイン2 (カスタムコマンド)
  ├── プラグイン3 (エージェント)
  └── プラグイン4 (フック + コマンド)

この仕組みの良いところは、配布者が好きなプラグインを詰め合わせられる一方で、利用者は必要なものだけを選んでインストールできる点です。マーケットプレイスの追加は一度だけで済み、その後は含まれるプラグインから自由に選択できます。

管理側と利用者の両方にとって使いやすい、Anthropicのセンスが光る設計だと感じています。

社内向けマーケットプレイスを作った理由

プラグイン機能がリリースされたので、「まずやってみる」という姿勢で社内向けマーケットプレイスを作成しました。

コロプラでは社内サービスと連携するMCPサーバーを複数開発してきました。ただ、MCPサーバーを使うには各自が設定ファイルを編集する必要があり、少し手間がかかっていました。プラグイン機能はこうした設定の配布と相性が良いのではないかと考え、まずは社内のMCPをそれぞれプラグインにして詰め込んで社内公開してみました。

社内にはCursor, Claude Code, Copilot Agentなど様々なツールを使っているメンバーがいるため、実際に業務に活用していくのは難しいですが、効率化を図っていく上での選択肢としては検討していきたいなと思っています。

作ったもの

社内向けプラグインマーケットプレイスとして「ccplugins」というリポジトリを作成しました。名前はClaude Code関連ツールの ccusage を参考に命名しています。

このマーケットプレイスでは、社内サービスと連携するMCP プラグインを複数提供しています。

利用者は、以下のようにマーケットプレイスを追加し、

/plugin marketplace add <組織名>/ccplugins

必要なプラグインをインストールします。これだけで、そのMCPが使えるようになります。

/plugin install <プラグイン名>@<組織名>

今回は相性の良さそうなMCPを個別でプラグインにしていますが、フックやサブエージェント、コマンドも追加できるので、今後はより実用的なものを追加していく予定です。

プラグイン マーケットプレイスの作り方

実際に作成したマーケットプレイスの構成は、以下のようになっています。

ccplugins/
├── .claude-plugin/
│   └── marketplace.json
└── plugins/
    ├── mcp-plugin1/
    │   ├── .claude-plugin/
    │   │   └── plugin.json
    │   └── .mcp.json
    ├── mcp-plugin2/
    │   ├── .claude-plugin/
    │   │   └── plugin.json
    │   └── .mcp.json
    └── mcp-plugin3/
        ├── .claude-plugin/
        │   └── plugin.json
        └── .mcp.json

マーケットプレイスのルートには marketplace.json を配置し、利用可能なプラグインのリストを定義します。各プラグインには plugin.json でメタデータを記述し、MCPサーバーの設定は .mcp.json で行います。

詳しい作り方は、公式ドキュメントを参照してください。

実際に使ってみて

手元で使っている分には、/plugin コマンドでインタラクティブにマーケットプレイスやプラグインを操作できるところは体験が良いと感じています。ただ、少しまだ操作部分で不安定な挙動もあります。

社内での展開はこれからですが、プラグイン機能はMCPサーバーの設定だけでなく、カスタムコマンドやエージェント、フックなども追加できます。今後は、より実用的なプラグインを追加していきたいですね。

これから

これまではClaude Codeのカスタマイズ機能をリポジトリ単位での共有しかできませんでしたが、プラグインマーケットプレイスによって、もっと柔軟な組織の単位で共有できるようになりました。

今回作ったマーケットプレイスは社内の共通プラグイン置き場という位置づけですが、今後は各チームやプロジェクトごとに独自のプラグインリポジトリを作る流れになっていくと良いなと考えています。あらゆるセクションで便利な活用や共有がされていくことを期待しています。

ColoplTechについて

CursorなどのAIエージェントのルールをシンボリックリンクで共通化

2025-10-15T11:00:00+09:00

こんにちは、エンジニアの山田 (@yamadashy) です。

皆さんのプロジェクトでは、AIコーディングツールのルール、コマンドをどのように管理していますか？

現在、私たちの周りには Cursor、Claude Code、Codex CLI など、多種多様なAIツールが存在します。コロプラでも、以前こちらの記事でCursorの導入事例を紹介しましたが、今ではエンジニアがそれぞれの好みに合わせてツールを自由に選択する文化が根付いています。

しかし、この自由なツール選択の裏側で、私たちは新たな課題に直面していました。それは、「プロジェクトのルールを各ツールの設定ファイルへ個別に反映させる負担」です。

AIコーディングツール過渡期の今、社内でのツールの統一は現実的ではなく、かといって設定同期のために特別なツールを導入するのも避けたい。そんな状況で、私たちが一つの解決策として見出したのが、「シンボリックリンク」を活用したシンプルなルール共通化の手法でした。

本記事では、特別なツールやコマンドを必要とせず、多様なAIツール間でプロジェクトルールを効率的に共有するための具体的な方法をご紹介します。

基本的な考え方

この手法の基本的な考え方は非常にシンプルです。

まず、プロジェクトの共通ルールを記述したファイル（例: base.md）を .agents/ のような特定のディレクトリに一元的に配置します。そして、各AIツールが参照する設定ファイルのパスには、この base.md へのシンボリックリンクを作成します。

表題通り、これだけです。これで動くのか？と思う方もいらっしゃるかと思いますが、Cursor、Codex CLI、Claude Code、GitHub Copilot Agent Mode で動作を確認しています。 .claude/commands などのコマンドも同様の方法で共通化できます。

この方法により、開発者はツールの違いを意識することなく、常に最新のプロジェクトルールをAIに読み込ませることができます。

ちなみに、共通ディレクトリ名を .agents としているのは、AIエージェントの標準化を目指すコミュニティの動きである AGENTS.md を参考にしています。

具体的な設定方法

具体的には、以下の2つのステップで設定します。

1. 共通ルールファイルの作成

はじめに、プロジェクトのルートディレクトリに .agents/rules/ のようなディレクトリを作成し、そこに共通ルールを記述した base.md を配置します。

このファイルに、CLAUDE.md などで書いたベースのルールを記述します。

Cursorルールの場合、ファイルの先頭に alwaysApply: true のようなFront matterの記述があるので、それも一緒に記述します。これが他のツール（Claude Codeなど）の動作に影響を与えないことも確認済みです。このように、ツール間の差異を吸収しつつ、共通の情報を一元管理できるのがこの手法の強みです。

2. シンボリックリンクの作成

次に、各ツールが参照する設定ファイルの場所へ、先ほど作成した base.md へのシンボリックリンクを作成します。

# for Cursor
ln -s ../../.agents/rules/base.md .cursor/rules/base.mdc

# for Claude Code
ln -s .agents/rules/base.md CLAUDE.md

# for Codex CLI
ln -s .agents/rules/base.md AGENTS.md

# for GitHub Copilot Agent Mode
ln -s ../.agents/rules/base.md .github/copilot-instructions.md

これで、各ツールは同じ base.md ファイルをルールとして読み込むようになります。ルールの更新は base.md を編集するだけで、すべてのツールに即座に反映されます。

また、コマンド機能についても、同様の方法で共通化が可能です。

# 共通のコマンドを配置するディレクトリ
mkdir -p .agents/commands

# for Cursor
ln -s ../.agents/commands .cursor/commands

# for Claude Code
ln -s ../.agents/commands .claude/commands

# Codex CLIなどは現状で非対応

Codex CLI では、現時点でプロジェクト単位のコマンド共有機能がサポートされていませんが、対応されれば同様の手法で共通化が可能でしょう。

社内への展開

この仕組みは、コロプラ社内のPHPプロジェクト雛形である laravel-skeleton に標準で導入されており、誰でもすぐに試せる状態で共有されています。

私自身が関わるプロジェクトでもこの仕組みを運用しており、Claude CodeとCursorを状況に応じて使い分けていたりしますが、ルールのメンテナンスコストが削減され開発者体験の向上にも繋がっていると感じます。

もちろん課題もあり、Cursorのようにルールを複数作成できるようなケースや、ルールからコマンドを呼ぶなど、ツールごとの差異を吸収することは難しいです。

とはいえ、プロジェクトの基本的なルールや構造といった情報は、ツール間で共通している部分がほとんどで、一つの落とし所としてはこの手法が現実的で効果的な解決策だと考えています。

まとめ

ツールの進化が続く現代の開発現場において、プロジェクトの一貫性をいかに保つかは重要な課題です。もし皆さんのチームでも同様の課題に直面しているのであれば、今回紹介した方法が、シンプルながら解決の一助となれば幸いです。

ColoplTechについて

神魔狩りのツクヨミ勉強会を実施しました

2025-09-17T11:00:00+09:00

こんにちは！バックエンドエンジニアのR.Oです。
コロプラでは、新作タイトルリリース後などに新しい技術的な挑戦の紹介や知見の共有を勉強会を通じて行っております。
今回は9月上旬に神魔狩りのツクヨミ社内勉強会が実施されましたので、内容の一部をご紹介いたします。
主にゲームを構成するインフラ環境、ゲーム内でのAIの活用方法、少人数ならではの開発など技術的な取り組みを中心に幅広く紹介していただきました。

神魔狩りのツクヨミとは

本作は2025年5月7日（水）にサービス開始されたローグライクカードゲームで、金子一馬の独自の世界観が描かれています。
特徴的な部分はゲームに画像生成AIが使われているところで、プレイヤーの行動ログを元に自分だけのカードが創り出されます。
プレイしたことのない方はぜひこの機会にやってみてください！
jintsuku.jp

発表内容

1. Cloud Run環境の構築

GKEに代わりCloud Runを採用した背景には、インフラの柔軟性とコスト効率の最適化という目的がありました。アクセス状況に応じてリソースを動的に調整できる従量課金モデルが、本プロジェクトの要件に適していると判断しました。
また、Cloud Runの特徴や変更点のメリットなども紹介していただきました。
最後に今後の展望として、タイトルの規模によってGKE/CloudRunを使い分けることに加え、例えば開発環境のみCloud Runを利用するといった、より柔軟なインフラ構成についても検討を進めていることが語られました。

2. AIのゲーム内活用

本ゲーム内では、画像生成AI、テキスト生成AIが使われていると紹介されました。
画像生成AIの仕組みや開発中の苦難が語られました。
テキスト生成AIの使用しているタイミングはカード創成時で、道中の行動結果の要約を生成AIに渡していることが明かされました。
また、テキスト生成AIを利用する処理はキューに逃がして通信時の負担を減らしていることが紹介されました。

3. 多言語対応

LQAではWOVN.gamesを活用し、テキストの翻訳/調整をしたことが紹介されました。
- CEDECの発表もあるので興味があれば見てみてください。

www.youtube.com

グローバルリリースに向けて、開発者が翻訳を意識せずに開発できる仕組みを構築したことが紹介されました。マスタデータやエラーメッセージなどをスプレッドシートで一元管理することで、翻訳プロセスを開発フローから分離し、迅速な多言語対応を実現したとのことです。

4. 短期間 ∩ 少人数でのリリース

少人数で開発を行っていたため、圧倒的な速度で開発を進めることできたそうです。その中でも品質を保つために、テストのカバレッジ率は高めに設定したという話がありました。
社内で培われた既存の技術資産を有効活用することで、開発効率を最大化したという話もありました。
最後に、クライアントデータや定数を工夫して効率的に管理したという話をしていただきました。

告知

11月21日(金)に開催されるアーキテクチャーカンファレンスで「生成AIが紡ぐ新体験『神魔狩りのツクヨミ』の裏側」というタイトルで発表があります。詳細はこちらでお話いたしますのでぜひご参加ください。
architecture-con.findy-tools.io

終わりに

今回の社内勉強会では、『神魔狩りのツクヨミ』における数々の技術的な挑戦が共有されました。
特に、Cloud Runの採用や生成AIの活用といった新しい取り組みから得られた知見は、コロプラ全体の技術力向上に繋がり、今後のタイトル開発にも大いに活かされていくと思います。
コロプラでは定期的に社内勉強会を開催していますので、次回の記事もお楽しみにお待ち下さい。

ColoplTechについて

超簡単！社内ツール向け Homebrew + GitHub 活用術

2025-09-12T11:00:00+09:00

こんにちは、エンジニアの工藤 @zeriyoshi です。

まえがき: 休職と PHP Conference Japan 2025 について

5月頃からフィジカル面で体調が悪く休職・入院しておりましたが、病気の特定と対処のための服薬治療によって症状が改善し、8月より復職させていただきました。

採択いただいていた PHP Conference Japan 2025 での登壇を辞退することになってしまい、大変ご迷惑をおかけいたしました。スピーカーとしてだけではなく、イベント参加者や運営スタッフなどとして引き続きカンファレンスなどのイベントに積極的に参加し協力していきたいと思っておりますので、今後とも何卒よろしくお願いいたします。

Homebrew

みなさん、 Homebrew は使っていますか？仕事で macOS を使っている人であればほとんどが使っているのではないかと思われます。

Homebrew はコマンドなど実行ファイルを配布するのにとても便利な手段で、例えば私は zsh よりも bash 派なのもあり Homebrew で bash をインストールしてデフォルトシェルに指定したり、 GitHub を操作する gh コマンドなどをインストールして使っています。更新も brew upgrade だけで完了するので、とても便利です。

しかし、社内でツールを配布するとなるとどうでしょうか。仕事のオペレーションに最適化された内製ツールを配布したいとなっても Homebrew ほどシンプルに行える方法はなかなか存在せず、ある人にとっては便利であっても別の人は不要なものもあるわけで、自分が必要なものだけを選んでいれることができ、アップデートも利用者が好きなタイミングで行え、かつ自動化できる Homebrew は開発者体験を効果的に向上してくれます。

Homebrew tap によるリポジトリ追加

Homebrew には tap と呼ばれる外部 git リポジトリ (Formula と呼ばれます) を追加する機能があります。例えば Terraform で有名な HashiCorp も自前のリポジトリを公開しており、 brew tap で追加することで最新の Terraform を導入・更新できるようになります。

Internal, Private リポジトリでの Homebrew tap

Homebrew は internal (組織所属者のみ) や private (権限付与者のみ) のリポジトリの追加にも対応しており、適切に SSH アクセスができれば利用できるようになっています。

しかし、自前で Homebrew の Formula リポジトリを維持管理するのは思っているよりも大変です。具体的には

ツールごとの定義ファイルを Ruby DSL で記述する必要があること
ツールのバージョンアップの度に Ruby DSL の定義も変更する必要があること
Assets にあるバイナリが internal, private なリポジトリだとそのままではダウンロードできず、インストールできないこと

などが挙げられます。特にバイナリのダウンロードができないのが致命的です。

考えられる対応策として、以下のようなものが挙げられます。

Formula リポジトリ自体にツールのバイナリをそのまま配置する

Pros

単一のリポジトリに全てが完結して揃った状態にできる

Cons

git リポジトリが肥大化し、管理が煩雑になる
ツール側から Formula リポジトリを操作しなければならず、権限管理が煩雑
- 最もセキュアな形を取るのなら Formula リポジトリを手動で更新するしかない
  - 手間がかかるため使いづらい可能性

IP アドレス等で接続元制限をかけた Amazon S3 などにバイナリを配置しておく

Pros

比較的シンプルな構造でわかりやすい

Cons

IP アドレスによる制限はモダンでなく管理が煩雑
- リモートワーク時には VPN への接続が必須になり手間
GitHub Actions でビルドした結果を毎回 S3 にアップロードする必要が生じる
- アップロード時の鍵などの共有に課題
- アップロードしたあと Formula の url の向き先をアップロード後のものに更新しなければならない
  - 手動ですると手間がかかる

Homebrew Download Strategy

Homebrew は様々な機能拡張が行えるようになっており、例えばバイナリファイルをダウンロードしたり SHA-256 の検証をしたりするなどの部分をベースクラスを継承したクラスを作成することでカスタマイズできるようになっています。

通常、バイナリのダウンロードは CurlDownloadStrategy を使って行われます。そこで今回はこのクラスを継承し、以下の要件を満たすクラスを独自で実装しました。

org/repository を指定することで必須のフィールドを自動で設定してくれる
対象の org/repository の Release 一覧を取得し、 gh コマンドを用いて draft ではない最新のリリース (SemVer 準拠) を取得する
Release の Assets にある実行バイナリを gh コマンドを用いてダウンロードする

Homebrew はドキュメンテーションがしっかりしており、これらを自身でも読み解きつつ、 Claude Code のアシストも得ながら GitHubGHInternalReleaseDownloadStrategy を作成しました。

ソース: lib/github_gh_internal_release_download_strategy.rb

require 'json'
require 'digest'
require 'tmpdir'
require 'open3'

class GitHubGHInternalReleaseDownloadStrategy < CurlDownloadStrategy
  URL_PATTERN = %r{https://github.com/([^/]+)/([^/]+)/releases/download/([^/]+)/(\S+)}.freeze
  GH_EXECUTABLE_PATHS = [
    "/opt/homebrew/bin/gh",
    "/usr/local/bin/gh",
    "/home/linuxbrew/.linuxbrew/bin/gh"
  ].freeze
  CHECKSUM_FILE_PATTERNS = %w[checksums.txt SHA256SUMS sha256sums.txt checksums.sha256].freeze
  RELEASE_LIMIT = 50
  LATEST_TAG = "latest"
  VERSION_PREFIX = "v"
  SHA256_PATTERN = /^SHA256\s*\((.+?)\)\s*=\s*([a-f0-9]{64})$/i.freeze
  SHA256_ALTERNATE_PATTERN = /^([a-f0-9]{64})\s+\*?(.+)$/i.freeze

  attr_reader :latest_release_info

  def initialize(url, name, version, **meta)
    @meta = meta
    @auto_verify_sha256 = meta.fetch(:auto_verify_sha256, true)
    @original_url = url
    
    parse_github_url(url)
    setup_github_cli
    
    if @tag == LATEST_TAG
      @latest_release_info = fetch_latest_stable_release
      @tag = @latest_release_info[:tag]
      url = build_download_url(@tag)
    end
    
    super(url, name, version, **meta)
    parse_url_components
    
    if @latest_release_info && (version.nil? || version.to_s.empty?)
      @version = Version.new(@latest_release_info[:version])
    end
  end

  class << self
    def get_latest_release_info(repo_url, asset_pattern = nil)
      strategy = new(repo_url, nil, nil, use_latest_release: true, skip_validation: true)
      strategy.get_latest_release_info(asset_pattern)
    end

    def get_latest_version_for_formula(repo)
      gh_command = find_gh_executable
      return nil unless gh_command
      
      releases = fetch_releases(gh_command, repo)
      return nil unless releases
      
      extract_latest_version(releases)
    end

    def get_sha256_for_binary_set(repo, binary_names = {})
      gh_command = find_gh_executable
      return {} unless gh_command
      
      releases = fetch_releases(gh_command, repo)
      return {} unless releases
      
      tag = extract_latest_tag(releases)
      return {} unless tag
      
      checksums = collect_checksums(repo, tag, binary_names, gh_command)
      checksums
    end

    private

    def find_gh_executable
      GH_EXECUTABLE_PATHS.each do |path|
        return path if executable_exists?(path)
      end
      
      system("gh version > /dev/null 2>&1") ? "gh" : nil
    end

    def executable_exists?(path)
      File.exist?(path) && File.executable?(path)
    end

    def fetch_releases(gh_command, repo)
      command = build_release_list_command(gh_command, repo)
      stdout, stderr, status = Open3.capture3(*command)
      return nil unless status.success?
      
      JSON.parse(stdout)
    end

    def build_release_list_command(gh_command, repo)
      [gh_command, "release", "list", "--repo", repo, "--limit", RELEASE_LIMIT.to_s, 
       "--json", "tagName,publishedAt,isPrerelease"]
    end

    def extract_latest_version(releases)
      release = find_latest_stable_release(releases)
      return nil unless release
      
      release["tagName"].gsub(/^#{VERSION_PREFIX}/, "")
    end

    def extract_latest_tag(releases)
      release = find_latest_stable_release(releases)
      release&.dig("tagName")
    end

    def find_latest_stable_release(releases)
      stable_releases = releases.reject { |r| r["isPrerelease"] }
      stable_releases.max_by { |r| parse_version(r["tagName"]) }
    end

    def parse_version(tag)
      cleaned_tag = tag.gsub(/^#{VERSION_PREFIX}/, "")
      Gem::Version.new(cleaned_tag)
    rescue ArgumentError
      Gem::Version.new("0.0.0")
    end

    def collect_checksums(repo, tag, binary_names, gh_command)
      checksums = fetch_checksums_from_file(repo, tag, binary_names)
      
      if checksums.empty?
        checksums = calculate_checksums_directly(repo, tag, binary_names, gh_command)
      end
      
      checksums
    end

    def fetch_checksums_from_file(repo, tag, binary_names)
      checksums = {}
      binary_names.each do |platform, filename|
        sha256 = get_sha256_for_asset(repo, tag, filename)
        checksums[platform] = sha256 if sha256
      end
      checksums
    end

    def calculate_checksums_directly(repo, tag, binary_names, gh_command)
      checksums = {}
      binary_names.each do |platform, filename|
        sha256 = calculate_sha256_by_downloading(repo, tag, filename, gh_command)
        checksums[platform] = sha256 if sha256
      end
      checksums
    end

    def calculate_sha256_by_downloading(repo, tag, filename, gh_command)
      Dir.mktmpdir do |temp_dir|
        command = build_download_command(gh_command, repo, tag, filename, temp_dir)
        stdout, stderr, status = Open3.capture3(*command)
        return nil unless status.success?
        
        downloaded_file = File.join(temp_dir, filename)
        return nil unless File.exist?(downloaded_file)
        
        Digest::SHA256.file(downloaded_file).hexdigest
      end
    end

    def build_download_command(gh_command, repo, tag, filename, dir)
      [gh_command, "release", "download", tag,
       "--repo", repo,
       "--pattern", filename,
       "--dir", dir,
       "--clobber"]
    end

    def get_sha256_for_asset(repo, tag, filename)
      gh_command = find_gh_executable
      return nil unless gh_command
      
      Dir.mktmpdir do |temp_dir|
        checksums_content = download_checksums_file(gh_command, repo, tag, temp_dir)
        return nil unless checksums_content
        
        parse_checksum_for_file(checksums_content, filename)
      end
    end

    def download_checksums_file(gh_command, repo, tag, temp_dir)
      CHECKSUM_FILE_PATTERNS.each do |pattern|
        command = build_download_command(gh_command, repo, tag, pattern, temp_dir)
        stdout, stderr, status = Open3.capture3(*command)
        
        if status.success?
          checksums_file = File.join(temp_dir, pattern)
          return File.read(checksums_file) if File.exist?(checksums_file)
        end
      end
      nil
    end

    def parse_checksum_for_file(content, filename)
      content.each_line do |line|
        line = line.strip
        next if line.empty? || line.start_with?("#")
        
        if line =~ SHA256_PATTERN
          return $2 if $1 == filename
        elsif line =~ SHA256_ALTERNATE_PATTERN
          return $1 if $2 == filename
        end
      end
      nil
    end
  end

  def get_latest_release_info(asset_pattern = nil)
    return @latest_release_info if @latest_release_info
    
    setup_github_cli
    @latest_release_info = fetch_latest_stable_release
    
    if asset_pattern
      @latest_release_info[:assets] = fetch_assets_info(@latest_release_info[:tag], asset_pattern)
    end
    
    @latest_release_info
  end

  private

  def _fetch(url:, resolved_url:, timeout:)
    Dir.mktmpdir do |temp_dir|
      checksums_sha256 = fetch_checksums(temp_dir) if @auto_verify_sha256
      
      download_release_asset(temp_dir)
      
      downloaded_file = File.join(temp_dir, @filename)
      verify_and_move_file(downloaded_file, checksums_sha256)
    end
  end

  def fetch_checksums(temp_dir)
    checksums_content = download_checksums_file(temp_dir)
    return nil unless checksums_content
    
    parse_checksums(checksums_content)
  end

  def download_checksums_file(temp_dir)
    CHECKSUM_FILE_PATTERNS.each do |pattern|
      content = attempt_checksum_download(pattern, temp_dir)
      if content
        ohai "Found checksums file: #{pattern}"
        return content
      end
    end
    nil
  end

  def attempt_checksum_download(pattern, temp_dir)
    command = build_release_download_command(pattern, temp_dir)
    stdout, stderr, status = Open3.capture3(*command)
    
    return nil unless status.success?
    
    checksums_file = File.join(temp_dir, pattern)
    File.exist?(checksums_file) ? File.read(checksums_file) : nil
  end

  def parse_checksums(content)
    checksums = {}
    content.each_line do |line|
      line = line.strip
      next if line.empty? || line.start_with?("#")
      
      filename, sha256 = parse_checksum_line(line)
      checksums[filename] = sha256 if filename && sha256
    end
    checksums
  end

  def parse_checksum_line(line)
    if line =~ SHA256_PATTERN
      [$1, $2]
    elsif line =~ SHA256_ALTERNATE_PATTERN
      [$2, $1]
    else
      [nil, nil]
    end
  end

  def download_release_asset(temp_dir)
    command = build_release_download_command(@filename, temp_dir)
    
    ohai "Downloading #{@filename} from #{@owner}/#{@repo} (tag: #{@tag})..."
    opoo "Using gh at: #{@gh_command}" if Homebrew.verbose?
    
    stdout, stderr, status = Open3.capture3(*command)
    
    unless status.success?
      raise CurlDownloadStrategyError, "Failed to download: #{stderr}"
    end
  end

  def build_release_download_command(pattern, dir)
    [@gh_command, "release", "download", @tag,
     "--repo", "#{@owner}/#{@repo}",
     "--pattern", pattern,
     "--dir", dir,
     "--clobber"]
  end

  def verify_and_move_file(downloaded_file, checksums_sha256)
    unless File.exist?(downloaded_file)
      raise CurlDownloadStrategyError, "Downloaded file not found at expected location"
    end
    
    calculated_sha256 = Digest::SHA256.file(downloaded_file).hexdigest
    
    verify_sha256(calculated_sha256, checksums_sha256) if @auto_verify_sha256
    
    FileUtils.mv(downloaded_file, temporary_path)
    
    @latest_release_info[:sha256] = calculated_sha256 if @latest_release_info
  end

  def verify_sha256(calculated_sha256, checksums_sha256)
    if checksums_sha256
      expected_sha256 = checksums_sha256[@filename]
      if expected_sha256
        verify_checksum_match(calculated_sha256, expected_sha256)
      else
        opoo "No SHA256 found in checksums file for #{@filename}"
      end
    else
      opoo "SHA256 calculated but not verified (no checksums file): #{calculated_sha256}"
    end
  end

  def verify_checksum_match(calculated, expected)
    if calculated.downcase != expected.downcase
      raise CurlDownloadStrategyError, 
            "SHA256 mismatch for #{@filename}\nExpected: #{expected}\nActual: #{calculated}"
    end
    ohai "SHA256 verified: #{calculated}"
  end

  def parse_github_url(url)
    unless url =~ URL_PATTERN
      raise CurlDownloadStrategyError, 'Invalid url pattern for GitHub Release.'
    end
    
    _, @owner, @repo, @tag, @filename = *url.match(URL_PATTERN)
  end

  def parse_url_components
    parse_github_url(@url)
  end

  def build_download_url(tag)
    @original_url.gsub(/\/releases\/download\/#{LATEST_TAG}\//, "/releases/download/#{tag}/")
  end

  def setup_github_cli
    @gh_command = find_gh_command
    validate_gh_authentication
  end

  def find_gh_command
    candidates = build_gh_candidates
    
    candidates.uniq.each do |path|
      if File.exist?(path) && File.executable?(path)
        opoo "Found gh at: #{path}" if Homebrew.verbose?
        return path
      end
    end
    
    return "gh" if system("gh version > /dev/null 2>&1")
    
    raise_gh_not_found_error(candidates)
  end

  def build_gh_candidates
    candidates = []
    
    candidates << "#{HOMEBREW_PREFIX}/bin/gh" if defined?(HOMEBREW_PREFIX)
    candidates.concat(GH_EXECUTABLE_PATHS)
    candidates << "#{ENV["HOMEBREW_PREFIX"]}/bin/gh" if ENV["HOMEBREW_PREFIX"]
    
    which_result = which("gh")
    candidates << which_result if which_result
    
    ENV["PATH"].split(":").each do |path|
      gh_path = File.join(path, "gh")
      candidates << gh_path if File.exist?(gh_path)
    end
    
    candidates
  end

  def raise_gh_not_found_error(candidates)
    raise CurlDownloadStrategyError, <<~EOS
      GitHub CLI (gh) is not installed or not found in expected locations.
      
      Searched locations:
      #{candidates.join("\n  ")}
      
      Please install GitHub CLI with:
        brew install gh
      
      Then authenticate with:
        gh auth login
    EOS
  end

  def validate_gh_authentication
    validate_gh_version
    validate_gh_auth_status
  end

  def validate_gh_version
    stdout, stderr, status = Open3.capture3(@gh_command, "version")
    
    unless status.success?
      raise CurlDownloadStrategyError, <<~EOS
        GitHub CLI (gh) command failed to execute.
        Command: #{@gh_command} version
        Error: #{stderr}
        
        Please ensure GitHub CLI is properly installed:
          brew install gh
      EOS
    end
  end

  def validate_gh_auth_status
    stdout, stderr, status = Open3.capture3(@gh_command, "auth", "status")
    
    unless status.success?
      raise CurlDownloadStrategyError, <<~EOS
        GitHub CLI is not authenticated.
        
        Please authenticate with:
          gh auth login
        
        Error: #{stderr}
      EOS
    end
  end

  def fetch_latest_stable_release
    releases = fetch_all_releases
    latest = find_latest_stable(releases)
    
    unless latest
      raise CurlDownloadStrategyError, "No stable releases found"
    end
    
    build_release_info(latest)
  end

  def fetch_all_releases
    command = [@gh_command, "release", "list", 
               "--repo", "#{@owner}/#{@repo}", 
               "--limit", RELEASE_LIMIT.to_s,
               "--json", "tagName,publishedAt,isPrerelease"]
    
    stdout, stderr, status = Open3.capture3(*command)
    
    unless status.success?
      raise CurlDownloadStrategyError, "Failed to fetch release list: #{stderr}"
    end
    
    JSON.parse(stdout)
  end

  def find_latest_stable(releases)
    stable_releases = releases.reject { |r| r["isPrerelease"] }
    
    stable_releases.max_by do |release|
      tag = release["tagName"].gsub(/^#{VERSION_PREFIX}/, "")
      parse_version_safe(tag)
    end
  end

  def parse_version_safe(tag)
    Gem::Version.new(tag)
  rescue ArgumentError
    Gem::Version.new("0.0.0")
  end

  def build_release_info(release)
    tag = release["tagName"]
    {
      tag: tag,
      version: tag.gsub(/^#{VERSION_PREFIX}/, ""),
      published_at: release["publishedAt"]
    }
  end

  def fetch_assets_info(tag, pattern)
    assets = fetch_release_assets(tag)
    
    case pattern
    when Hash
      match_multiple_assets(assets, pattern)
    when String
      match_single_asset(assets, pattern)
    else
      format_all_assets(assets)
    end
  end

  def fetch_release_assets(tag)
    command = [@gh_command, "release", "view", tag, 
               "--repo", "#{@owner}/#{@repo}", 
               "--json", "assets"]
    
    stdout, stderr, status = Open3.capture3(*command)
    
    unless status.success?
      raise CurlDownloadStrategyError, "Failed to fetch release assets: #{stderr}"
    end
    
    JSON.parse(stdout)["assets"]
  end

  def match_multiple_assets(assets, patterns)
    matching_assets = {}
    
    patterns.each do |key, asset_pattern|
      asset = find_matching_asset(assets, asset_pattern)
      matching_assets[key] = format_asset_info(asset) if asset
    end
    
    matching_assets
  end

  def match_single_asset(assets, pattern)
    asset = find_matching_asset(assets, pattern)
    asset ? format_asset_info(asset) : {}
  end

  def find_matching_asset(assets, pattern)
    assets.find { |asset| File.fnmatch(pattern, asset["name"]) }
  end

  def format_all_assets(assets)
    assets.map { |asset| format_asset_info(asset) }
  end

  def format_asset_info(asset)
    {
      name: asset["name"],
      download_url: asset["browserDownloadUrl"],
      size: asset["size"]
    }
  end
end

また、より簡単に記述できるようにするために Formula も簡素化した継承クラスを作成しました。

ソース: lib/github_gh_internal_formula.rb

require_relative './github_gh_internal_release_download_strategy'

class GitHubGHInternalFormula < Formula
  def self.repo(name)
    @repo_name = name
  end

  def self.binary(basename)
    @binary_basename = basename
  end

  def self.repo_name
    @repo_name || raise(NotImplementedError, "Subclass must define repo_name using 'repo' method")
  end

  def self.binary_basename
    @binary_basename || raise(NotImplementedError, "Subclass must define binary_basename using 'binary' method")
  end

  def self.test_command_args
    ["-v"]
  end

  def self.binary_names
    @binary_names ||= if respond_to?(:custom_binary_names)
      custom_binary_names
    else
      {
        darwin_amd64: "#{binary_basename}-darwin-amd64",
        darwin_arm64: "#{binary_basename}-darwin-arm64",
        linux_amd64: "#{binary_basename}-linux-amd64",
        linux_arm64: "#{binary_basename}-linux-arm64"
      }
    end.freeze
  end

  def self.checksums
    @checksums ||= GitHubGHInternalReleaseDownloadStrategy.get_sha256_for_binary_set(repo_name, binary_names)
  end

  def self.platform_key
    if OS.mac?
      Hardware::CPU.intel? ? :darwin_amd64 : :darwin_arm64
    else
      Hardware::CPU.intel? ? :linux_amd64 : :linux_arm64
    end
  end

  def self.setup_platform_binary
    key = platform_key
    binary_name = binary_names[key]
    url "https://github.com/#{repo_name}/releases/download/latest/#{binary_name}",
        using: GitHubGHInternalReleaseDownloadStrategy
    sha256 checksums[key] if checksums[key]
  end

  def self.inherited(subclass)
    super
    TracePoint.new(:end) do |tp|
      if tp.self == subclass
        tp.disable
        subclass.class_eval do
          homepage "https://github.com/#{subclass.repo_name}"
          latest_version = GitHubGHInternalReleaseDownloadStrategy.get_latest_version_for_formula(subclass.repo_name)
          version latest_version if latest_version
          if subclass.platform_key
            subclass.setup_platform_binary
          end
        end
      end
    end.enable
  end

  def install
    bin.install self.class.binary_names[self.class.platform_key] => self.class.binary_basename
  end

  def test
    system "#{bin}/#{self.class.binary_basename}", *self.class.test_command_args
  end
end

このクラスを用いて以下のように Formula を作成しました。 toilet はコロプラオフィス社内のトイレの空き状況をチェックする自作の ~~くだらない~~ ツールです。

toilet.rb

require_relative './lib/github_gh_internal_formula'

class Toilet < GitHubGHInternalFormula
  desc "COLOPL toilet vacancy checker"
  repo "colopl-indie/toilet"
  binary "toilet"

  def self.test_command_args
    ["--help"]
  end
end

これらを格納した Homebrew tap 用のリポジトリである colopl-indie/homebrew-formulas を作成し、以下のようなディレクトリ構成としました。

.
├── lib
│   ├── github_gh_internal_formula.rb
│   └── github_gh_internal_release_download_strategy.rb
├── README.md
└── toilet.rb

実際の使用方法

この方法では常に gh コマンドを必要とするので、事前に Homebrew で gh コマンドをインストールし、権限のある Organization アカウントでログインしておく必要があります。

セットアップが終わったら後は普通に Homebrew でインストールするだけです。 toilet ならこんな感じです (Homebrew 公式に同名のものがあるとそちらが優先されてしまうので、フルネームでインストールするのを推奨します)

$ brew install colopl-indie/formulas/toilet
~~~ 省略 ~~~
$ toilet --help
     _
    | |
 ___| | COLOPL
(    .'     Toilet
 )  (
COLOPL Toilet Utility v2.0.3

Usage:
  toilet [command]

Available Commands:
  check       Check available restrooms
  completion  Generate the autocompletion script for the specified shell
  help        Help about any command
  watch       Watch availability

Flags:
  -h, --help   help for toilet

Use "toilet [command] --help" for more information about a command.

更新の自動化

ちなみにこの方法では、常に対象となるリポジトリの最新のリリースを取得し利用するため Release さえ適切に行えていればツールのバージョンアップの度に Homebrew リポジトリ側を更新する必要はありません。逆に言えば古いバージョンを入れられないということにはなりますが、まあ社内ツールなのでその時はリリースを削除するだけで大丈夫です。

おまけ: GitHub Actions を用いた Go 製ツールの自動リリース

先ほどの toilet では、 GitHub Actions にて vX.Y.Z でタグが切られており、正式に SemVer の要件を満たした場合に自動的にリリースを作成しバイナリをアップロードするようにしています。 SemVer の要件を満たさない (例: vX.Y.Z-pre 等) 場合は draft としてリリースします。

以下は toilet で自動リリースするための GitHub Actions の定義の例です。

name: Build and Release

on:
  push:
    tags:
      - 'v*'

concurrency:
  group: release-${{ github.ref }}
  cancel-in-progress: false

permissions:
  contents: read

jobs:
  build:
    name: Build binaries
    runs-on: ubuntu-24.04
    strategy:
      matrix:
        goos: [linux, darwin, windows]
        goarch: [amd64, arm64]
    steps:
    - name: Checkout code
      uses: actions/checkout@v5
      with:
        fetch-depth: 0
    - name: Set up Go
      uses: actions/setup-go@v6
      with:
        go-version: stable
        cache: true
    - name: Verify dependencies
      run: |
        go mod verify
        go mod download
    - name: Replace placeholders
      run: |
        sed -i 's#%COLOPL_TOILET_API%#${{ secrets.COLOPL_TOILET_API }}#g' "toilet.go"
        sed -i 's#%COLOPL_TOILET_VERSION%#${{ github.ref_name }}#g' "toilet.go"
    - name: Build binary
      env:
        GOOS: ${{ matrix.goos }}
        GOARCH: ${{ matrix.goarch }}
        CGO_ENABLED: 0
      run: |
        BINARY_NAME="toilet-${{ matrix.goos }}-${{ matrix.goarch }}"
        if test "${{ matrix.goos }}" = "windows"; then
          BINARY_NAME="${BINARY_NAME}.exe"
        fi
        go build -v -ldflags="-s -w" -o "${BINARY_NAME}" "toilet.go"
    - name: Upload artifacts
      uses: actions/upload-artifact@v4
      with:
        name: toilet-${{ matrix.goos }}-${{ matrix.goarch }}
        path: toilet-*
        retention-days: 1
        if-no-files-found: error
  release:
    name: Create Release and Upload Assets
    needs: build
    runs-on: ubuntu-24.04
    permissions:
      contents: write
    steps:
    - name: Checkout code
      uses: actions/checkout@v5
      with:
        fetch-depth: 0
    - name: Download all artifacts
      uses: actions/download-artifact@v5
      with:
        path: artifacts/
    - name: Check if tag follows semantic versioning pattern
      id: check_tag
      run: |
        TAG_NAME="${{ github.ref_name }}"
        if echo "${TAG_NAME}" | grep -qE '^v[0-9]+\.[0-9]+\.[0-9]+$'; then
          echo "draft=false" >> $GITHUB_OUTPUT
        else
          echo "draft=true" >> $GITHUB_OUTPUT
        fi
    - name: Create Release
      id: create_release
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        gh release create "${{ github.ref_name }}" \
          --title "Release ${{ github.ref_name }}" \
          --generate-notes \
          --draft="${{ steps.check_tag.outputs.draft }}"
        sleep 3
        gh release view "${{ github.ref_name }}"
    - name: Upload Release Assets
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        for FILE in artifacts/*/toilet-*; do
          if test -f "${FILE}"; then
            gh release upload "${{ github.ref_name }}" "${FILE}" --clobber
          fi
        done
    - name: Generate and upload checksums
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        cd "artifacts"
        find . -type f -name 'toilet-*' -exec sh -c 'echo "$(sha256sum "$1" | cut -d" " -f1)  $(basename "$1")"' _ {} \; > "checksums.txt"
        gh release upload "${{ github.ref_name }}" "checksums.txt" --clobber

おわりに

この方法により、以下の課題を解決できました。

Internal, Private なツールのリポジトリにおけるバイナリリリースフローの統一
- GitHub の Release 機能を用いて自動的に Homebrew にもそれを反映できる環境に
SHA-256 チェックサムを利用したセキュアなバイナリ配布
GitHub 公式 CLI である gh コマンドのフル活用
- モダンな認証方式でより安全かつ使いやすい仕組みを実現
シンプルな構成による保守コストの低減

最後になりますが、体調不良により各所にご迷惑をおかけし大変申し訳ございませんでした。挽回できるようバリバリ活動していきますので、引き続きよろしくお願いいたします！

おまけのおまけ: `toilet` について

コロプラオフィスにはトイレの空き状況チェックができる環境が用意されており、 toilet は API 経由でそれを参照してチェックしています。もともと社内向けポータルに表示機能があったのですが、エンジニアとしてはコマンドラインの方が使いやすいなと思って移植しました。

コロプラオフィスは現状 5F と 6F のフロアがあるのですが、例えば以下のようにすることで 6F のトイレが空いたら通知してくれます。 macOS なら通知センターにも飛びます。

$ toilet watch --targets=6F
     _
    | |
 ___| | COLOPL
(    .'     Toilet
 )  (   
TOILET AVAILABLE!!!: 6F

あとは単純に状況のチェックもできます

$ toilet check
     _
    | |
 ___| | COLOPL
(    .'     Toilet
 )  (   
Area    Current Status  Empty   Max
6F      Available       3       6
5F      Available       2       8

ColoplTechについて

AIで開発はどう変わる？社内勉強会『AIテックトーク』開催レポート

2025-08-18T11:00:00+09:00

こんにちは！エンジニアの石塚です。普段は人事部でHR Tech領域を担当しつつ、社内のAI活用を推進する活動にも取り組んでいます。

さて、今回はコロプラで定期開催している「AIトーク」シリーズの第3弾として、エンジニア向けの勉強会「AIテックトーク」を開催しました。この記事では、イベントの様子や、そこで共有されたAIによる開発の変化をご紹介します。

全社で加速するAI活用！「AIトーク」シリーズとは？

コロプラでは月に一度、部署や職種の垣根を越えてAIの活用術をカジュアルに語り合う「AIトーク」というイベントを開催しています。「ここでの発見が、誰かのヒントになれば」という想いから始まったこの取り組み。

回を重ねるごとに、社内のあちこちで「あのツール、どう？」「こんな使い方を試してみたよ」といった会話が自然に生まれるようになり、AI活用の輪が着実に広がっています。

これまでの「AIトーク」シリーズ

第1回：AIフラットトーク

職種や役割に関係なく、AIの最新情報をシェアする全社向けイベント。初回は「Google Gemini Advanced」をテーマに盛り上がりました。
第2回：AIカジュトーク

バックオフィス部門での活用事例をカジュアルに共有するイベント。「Gemini Deep Research & NotebookLM」を題材に、人事戦略部のリアルな活用術を紹介しました。
第3回：AIテックトーク

そして今回ご紹介する、エンジニア向けのイベントです。

今回のテーマは「AIコーディングエージェント」

当社のCIO菅井は「あなたの当たり前は誰かの学び」という言葉で情報や学びの共有を促しています。今回の「AIテックトーク」は、まさにその言葉を体現する場となり、登壇したエンジニアたちが、日々の業務で得たリアルな知見や実践的な活用事例を共有してくれました。

イベントテーマ：AIコーディングエージェント

今回のイベントは、日進月歩で進化するAIコーディングツールの最新動向をキャッチアップし、それぞれのツールの特性を理解することで、日々の開発をさらに効率化することを目的として開催されました。

当日は、公募メンバーを含むCIOと4名のエンジニアが登壇。AIコーディングの基本から、少し応用的な技術である「MCP（Model Context Protocol）」まで、それぞれの視点から発表が行われました。

発表構成

オープニングトーク：AIコーディングエージェントの進化と向き合い方（CIO 菅井）
Cursorのすゝめ：AIネイティブなコードエディタを使いこなす（K.Y / インターナルグループ）
Devinで開発を加速！「Vibe Coding」という新しい開発スタイル（石塚 / 経営企画本部人事部）
MCPとは？ AIと社内サービスを繋ぐ接続の仕組み（N.S / インターナルグループ）
AIコーディングエージェントの総括と、これからの歩き方（山田 @yamadashy / CIO室 AIイネーブルメントグループ）

各発表のハイライト

当日は5つのセッションが行われ、どれも非常に内容の濃いものばかり。それぞれのハイライトをご紹介します。

1. オープニングトーク：AIコーディングエージェントの進化と向き合い方

AIコーディングエージェントがいかに凄まじいスピードで進化しているか、そして私たちがどう向き合うべきかについて解説。「みんなで気楽に時代の変化を楽しみましょう」というメッセージで、イベントの幕を開けました。

発表では、AIコーディングエージェントの継続的な進化が強調されました。この4年間で、AIは単なる「コード補完」ツールから、ソフトウェアのベンチマークを人間と同等レベルで解決する「自律型エンジニア」へと発展しました。

特に印象的だったのは、「うまくいかない時は、まっさらな状態からやり直そう」という言葉。AIは複雑なものを修正するより、ゼロから作ることの方が得意であり、この特性を理解することがAIと上手く付き合うコツだと語りました。

2. Cursorのすゝめ：AIネイティブなコードエディタを使いこなす

AIコードエディタ「Cursor」の実践的な活用法が紹介されました。

発表では、Cursorに統合されたAIエージェントが、必要なファイルを自律的に判断して読み書きする仕組みや、タブ補完、Command+Kを使った指示による編集など、その強力かつ直感的な操作が解説されました。

続くライブデモでは、ToDoリストアプリの実装を例に、Cursorへの指示出しからエラー発生時のデバッグフロー（AIへの再指示）までが実演され、参加者は具体的な活用イメージを掴むことができました。

安全性にも話が及び、.cursorignoreによるAIの読み取り範囲の制御や、「User Rules」を用いたルール設定など、セキュアに利用するための重要なポイントが解説されました。

3. Devinで開発を加速！「Vibe Coding」という新しい開発スタイル

自律型AIエージェント「Devin」を活用し、Chrome 拡張機能の社内ツール「くまぱわーあっぷ」の開発を高速化した事例と、新しい開発スタイル「Vibe Coding」について発表しました。

Devinは、タスクの実行からコーディング、インフラ設定までを一貫して担う自律型AIです。Slack連携やWeb UIを通じたタスク管理機能に加え、「Devin Knowledge」によってプロジェクト固有のルールや設計思想を学習させることが可能だと紹介されました。

実際の社内ツール開発では、プロジェクト特有の「お作法」やChrome 拡張機能ならではの制約といった、AIだけでは対処が難しい課題に直面しました。そこで、既存設計の理解には「Devin Knowledge」を、機能移植には関連コードをまとめる「Repomix」を活用するなど、実践的な工夫を凝らした結果、UIや主要機能の大部分をAIに自動生成させることに成功したと報告されました。

発表では、開発スピードの向上というメリットだけでなく、AIを単なる「道具」としてではなく、「プロジェクトメンバーの一員」として根気強く育てていく視点の重要性が共有されました。実際にDevinを用いた新機能追加のデモも成功に終わり、「Vibe Coding」がいかに開発を効率化するかが示されました。

4. MCPとは？ AIと社内サービスを繋ぐ接続の仕組み

AIと各種サービスを連携させるための仕組みである「MCP（Model Context Protocol）」について、デモを交えながら紹介しました。

Playwright MCPを使い、Cursorからの指示一つでテストを自動実行し、その結果をSlackに通知するデモを披露。さらに、チャットで社員名を尋ねるだけで社内システムから情報を取得して回答する「社員情報検索MCP」も紹介され、AIが自然言語を介して複数のサービスを自在に操る様子は、会場から大きな反響を呼びました。

MCPを活用することで、従来は手作業だった情報取得や操作を自動化し、業務効率を改善できると説明。一度設定すればユーザー側での更新が不要になる点や、ローカルPC上で独自のMCPコマンドを作成できる高い拡張性も、その魅力として挙げられました。

デモで紹介された「社員情報検索MCP」は、すでに社内で実際にリリースされています。今後は連携先をさらに拡大し、業務におけるAI活用を一層推進していく方針が共有されました。

5. AIコーディングエージェントの総括と、これからの歩き方

これまでのセッション内容を網羅しつつ、AI駆動開発のリアルな知見と今後の展望について総括が行われました。

GitHub Copilotのような「補助ツール」から、DevinやClaude Codeといった「バックグラウンドエージェント」、さらには「レビュー自動化」や「CLIツール」に至るまで、AIエージェントを体系的に分類。タスクに応じて最適なツールを使い分けることの重要性が解説されました。

実践から得られた活用のコツとして、ルールファイルをシンプルかつ明確に保つことが不可欠だと強調されました。「昨日入社したばかりのメンバーでも理解できる設計」を基準とし、大規模なタスクはAI自身に計画を立てさせ、ステップごとに実行させることが成功の鍵だと紹介されました。

その一方で、実際の開発プロジェクトにおける失敗談も共有されました。古いコードの残骸がAIの動作に悪影響を及ぼし、無限ループに陥るトラブルも。この経験から、コードの定期的な整理やタスク終了後のクリーンアップ、そして最終的な人間によるレビューがいかに重要であるかという教訓が共有されました。

今後の展望として、各プロジェクトに最適化されたルール設計を進め、Claude CodeやGemini CLIの活用を促進していくと述べられました。そして、社内外の情報チャネルを積極的に活用し、エンジニア一人ひとりが主体的にAIと共に成長していく姿勢が求められる、とセッションは締めくくられました。

開催を終えて

今回の「AIテックトーク」は、AIコーディングの最前線で得られた成功体験やリアルな失敗談、そして明日から使える実践的なノウハウが飛び交う、非常に熱量の高い時間となりました。

参加者からは、「各ツールの特性や使い分けがよく分かった」「早速試してみたい！」といった声が多く寄せられ、コロプラ全体のAI活用をさらに加速させる、大きな一歩になったと感じています。

おわりに

AIコーディングエージェントの世界は、急速に進化しています。この大きな波を楽しみながら乗りこなすために、ツールの特性を深く理解し、プロジェクトや自身の開発スタイルに合わせて使い分けることが、これからのエンジニアには欠かせません。

同時に、AIの能力を最大限に引き出すためには、AIが活躍しやすい環境を整える組織的な取り組みも不可欠です。実際に、コロプラでは社員の約8割が業務でAIを活用するまでになっており、AIを「クリエイターの創造性を支える黒子」として位置づけた多面的な支援施策を展開しています。

コロプラでは、今後もこうしたナレッジ共有の場を大切にし、社員一人ひとりがもっと楽しく、もっと創造的に働ける環境を、組織全体でつくっていきます。

pinmark.colopl.co.jp

ColoplTechについて

【クイズ解答・解説公開】PHP Conference Japan 2025に出展させていただきました

2025-07-02T11:00:00+09:00

こんにちは、エンジニアの山田 (@yamadashy) です。

6月28日に大田区産業プラザPiOで開催された「PHP Conference Japan 2025」に出展しました。今年はゴールドスポンサーとして協賛し、ブース出展を通して多くのPHP開発者の皆さんと交流する機会をいただきました。

PHP Conference Japan 2025 について

PHP Conference Japan は有志によるプログラミング言語 PHP にまつわる国内最大規模のカンファレンスで、一年に一度の頻度で開催されている技術系カンファレンスイベントです。

コロプラとしても 2022 年からシルバースポンサーとして協賛させていただいており、今年はゴールドスポンサーとして協賛規模を拡大し、より積極的にPHPコミュニティへ貢献しました。

スポンサーブースの様子

コロプラブースに来ていただいた方に、「コロプラ水」「ステッカー」「クリアファイル」を配布しました。

今年のブースでは、「PHP予想外クイズ」というコンテンツを企画。簡単なものからベテランのPHP開発者でも悩む問題まで5つの問題を用意し、回答いただいた方にはテックブログの二次元バーコード入りのコーヒーをプレゼントしました。

ブースで使うテーブルクロスやロールアップバナーも新調。

PHP予想外クイズの解説

ブースで出題したクイズの内容をご紹介します。皆さんも挑戦してみてください！

PHPのバージョンは8.4です。

問題1（正解率：22％）

次のPHPコードを実行した場合、どのような結果になるでしょうか？

<?php
$arr = [null => 1];
print_r($arr);

選択肢

Array ( [null] => 1 )
Array ( [0] => 1 )
Array ( [] => 1 )
TypeError: Illegal offset type

正解・解説を見る

正解は 3. Array ( [] => 1 )

PHPでは、配列のキーとしてnullを使用すると、自動的に空文字列''に変換されます。これはPHPの型変換の仕様によるものです。

この例では、nullキーが空文字列に変換され、結果としてArray ( [] => 1 )が表示されます。PHPのprint_r関数では、空文字列のキーは[]として表示されます。

参考: PHP: 配列

問題2（正解率 35％）

次のPHPコードを実行した場合、どのような結果になるでしょうか。

<?php
$var = 1 + + 8;
var_dump($var);

選択肢

int(1)
int(9)
int(18)
Parse error: syntax error

正解・解説を見る

正解は 2. int(9)

PHPでは、1 + + 8という式は構文エラーではなく、正常に解析されます。この式は実際には1 + (+8)として解釈されます。

+8の最初の+は単項演算子です。この演算子は値が文字列や論理値の場合はintまたはfloatに変換しますが、すでに数値の場合は実質的に何も変更しません。そのため、+8は単純に8と同じ値になります。

結果として、1 + + 8は1 + 8と同じ計算になり、答えは9となります。

参考: PHP: 演算子の優先順位, PHP: 算術演算子

問題3（正解率：25％）

次のPHPコードを実行した場合、どのような結果になるでしょうか？

<?php
$str = 'z';
$str++;
echo $str;

選択肢

z
aa
{
エラーが発生する

正解・解説を見る

正解は 2. aa

PHPでは文字列をインクリメント演算子（++）で操作できます。文字列の末尾が'z'の場合、次の文字'a'が追加され、元の'z'は'a'に変わります。

参考: PHP: 加算子/減算子

問題4（正解率：33％）

次のPHPコードを実行した場合、どのような結果になるでしょうか？

<?php
$value = 0;
switch ($value) {
    case '':
        echo 'empty string';
        break;
    case false:
        echo 'false';
        break;
    case 0:
        echo 'zero';
        break;
}

選択肢

empty string
false
zero
何も出力されない

正解・解説を見る

正解は 2. false

switch文では緩い比較（==）が使用されます。PHP 8.4では以下の比較結果になります。

0 == '' → false
0 == false → true
0 == 0 → true

switch文では上から順番に比較し、最初にマッチしたcaseが実行されます。

0 == '' は false なのでマッチしない
0 == false は true なのでマッチし、case false: が実行される

そのため、'false'が出力されます。

PHP 8.0以降の重要な変更 PHP 8.0以降では、数値と文字列の比較時の動作が変更されました。数値文字列ではない文字列と数値の比較では、数値を文字列に変換して比較するようになりました。空文字列''は数値文字列ではないため、0 == ''はfalseになります。

参考: PHP: switch, PHP: 型の比較表

問題5（正解率：41％）

次のPHPコードを実行した場合、どのような結果になるでしょうか？

<?php
$a = 28;
$b = 6;
$result = $a | $b;
echo "PHPは今年で{$result}周年！";

選択肢

PHPは今年で22周年！
PHPは今年で28周年！
PHPは今年で30周年！
PHPは今年で34周年！

正解・解説を見る

正解は 3. PHPは今年で30周年！

ビットOR演算（|）を使用しています。

28 = 11100 (2進数)
 6 = 00110 (2進数)
OR = 11110 (2進数) = 30 (10進数)

ビットOR演算では、どちらかのビットが1の場合、結果も1になります。

結果: 11110 = 16 + 8 + 4 + 2 + 0 = 30

ということで、PHPは1995年に誕生し、2025年でちょうど30周年を迎えます！

この問題は一見鬼畜な問題ですが、PHPへの愛があれば解ける問題でしょう。

参考: PHP: ビット演算子

追加問題

カンファレンスでは出題しなかった、解き応えのある問題も特別に用意しました。ぜひ挑戦してみてください！

追加問題1

次のPHPコードを実行した場合、どのような結果になるでしょうか？

<?php
$arr = [0.0 => 0, 0.9 => 1];
print_r($arr);

選択肢

Array ( [0] => 0 [0.9] => 1 )
Array ( [0] => 0 [1] => 1 )
Array ( [0] => 1 )
Array ( [0.9] => 1 )

正解・解説を見る

正解は 3. Array ( [0] => 1 )

PHPでは、配列のキーとして浮動小数点数を使用すると、自動的に整数に変換されます。この変換は「切り捨て」によって行われます。つまり、小数点以下は単純に切り捨てられます。

この例では

0.0は整数0に変換される
0.9も整数0に変換される（小数点以下が切り捨てられる）

同じキー（この場合は0）に対して複数の値が設定された場合、後から設定された値が優先されます。そのため、最終的な配列は[0 => 1]となります。

参考: PHP: 配列

追加問題2

次のPHPコードを実行した場合、どのような結果になるでしょうか？

<?php
$family_emoji = '👨‍👩‍👧‍👦';
echo mb_substr($family_emoji, 0, 1);

（PHPのシンタックスハイライトを有効にすると実際の問題と乖離が発生するので無効にしています）

選択肢

👨‍👩‍👧‍👦（家族の絵文字全体）
👨（男性の絵文字のみ）
空の文字列
エラーが発生する

正解・解説を見る

正解は 2. 👨（男性の絵文字のみ）

複合絵文字「👨‍👩‍👧‍👦」（家族）は、実際には以下の要素で構成されています

👨 (U+1F468) - 男性
U+200D - ゼロ幅接合子
👩 (U+1F469) - 女性
U+200D - ゼロ幅接合子
👧 (U+1F467) - 女の子
U+200D - ゼロ幅接合子
👦 (U+1F466) - 男の子

mb_substr関数は、これらの文字を個別のUnicode文字として扱うため、最初の文字である「👨」（男性）だけを返します。

絵文字を正しく扱うにはgrapheme_substr関数を使用してください。

参考: PHP: mb_substr, PHP: grapheme_substr

追加問題3

次のPHPコードを実行した場合、どのような結果になるでしょうか？

<?php
$arr = [1, 2, 3];
foreach ($arr as &$value) {
    $value = $value * 2;
}
foreach ($arr as $value) {
    // 何もしない
}
print_r($arr);

選択肢

Array ( [0] => 2 [1] => 4 [2] => 6 )
Array ( [0] => 2 [1] => 4 [2] => 4 )
Array ( [0] => 1 [1] => 2 [2] => 3 )
エラーが発生する

正解・解説を見る

正解は 2. Array ( [0] => 2 [1] => 4 [2] => 4 )

この問題が最も予想外な結果に感じられたでしょう。

以下のような流れで $arr は [2, 4, 4] になります。

最初のforeachループでは、&$valueで参照を使用し、各要素を2倍にする
- この時点で$arrは[2, 4, 6]になる
- $valueはまだ$arr[2]への参照を保持している
2番目のforeachループでは、参照を使用せず、各反復で$valueに値が代入される
- 1回目: $value = 2 → $arr[2] = 2（まだ$valueが$arr[2]への参照を保持しているので、$arr[2]が2になる）
- 2回目: $value = 4 → $arr[2] = 4 (参照経由での代入)
- 3回目: $value = 4 → $arr[2] = 4（参照経由での代入だが、$arr[2]が4で$valueも4なので変化なし）
$arr[2]が上書きされ、[2, 4, 4]になる

参考: PHP: foreach

おわりに

今年もPHP Conference Japanに参加して、PHPコミュニティの盛り上がりを肌で感じることができました。ブースに立ち寄ってくださった皆さん、ありがとうございました。

クイズを通じて、PHPの意外な挙動や面白い仕様について知っていただけたでしょうか。普段書いているコードにも、まだまだ知らない発見があることでしょう。

記事でクイズの全問題と解答を紹介しましたので、ぜひ挑戦してみてください。同僚やチームメンバーとも共有して、技術議論のきっかけにしていただければ幸いです。

コロプラはこれからもPHPコミュニティの一員として、技術の発展と交流に貢献していきたいと考えています。

ColoplTechについて

AI駆動開発に向けた取り組み - AI推進組織の発足とCursorの導入

2025-06-25T11:00:00+09:00

こんにちは、CIO の菅井です。

従来から AI 推進を横断的なチーム、プロジェクトごとに取り組んでいましたが、2025年4月1日にAIイネーブルメントグループを立ち上げました。

取り組みの一環として、AI支援型エディタ「Cursor」をエンジニア組織に導入しました。今回は、その背景と導入1週間で見えてきた成果や課題についてご紹介します。

AIイネーブルメントグループの立ち上げ

私たちのミッションは大きく2つあります。

1. AIを使ってできることを増やす

管理職やリードクラスでのAI活用を促進し、組織全体でのAI利用を底上げしています。また、ゲーム開発においては試作品やプロトタイプ作成の効率化を通じて生産性向上を図っています。さらに、AI活用による新しい体験やエンタテインメントの創出にも取り組んでおり、「神魔狩りのツクヨミ」などの事例が生まれています。

2. AIができることを増やす

AIが活用できるデータ領域の拡大に注力しています。これまでアクセスできなかったデータやデータ化されていない情報の可視化を進めており、具体的にはミーティング内容の録音・テキスト化をデフォルト化し、開発過程での作り変えデータの保持も行っています。最終的には、人の介在なしにAIエージェントがデータを取得できる基盤設計を目指しています。

なぜCursorを選んだのか

Cursorは、AIエージェント開発に必要な機能がバランスよく盛り込まれているエディタです。導入の主な理由は以下の通りです。

AIエージェント開発に最適化された機能群
リーズナブルな価格で広く展開が可能

ただし、重要なのは「Cursorを標準化したい」わけではありません。

柔軟な開発環境の選択

基本的な方針は「自分たちが使っているエディタをベースに、AIエージェント機能を活用する」というものです。ルール設定などはチームごとに共通認識を持って進めてもらっています。

PhpStorm + Windsurf プラグイン
VSCode + GitHub Copilot
Cursor
Claude Code

Cursor はあくまでも「AI エージェントによる開発に慣れるための1つのツール」という位置づけです。

導入1週間で見えてきたこと

良かった点

まだ全員が使いこなせているとは言えませんが、一部の方はヘビーに活用しており、数日で500リクエストを使っている方もいます。Cursorを使う上で見えてきた課題や改善点を一つずつ潰しているところです。

導入後、社内Slackの #pj-ai-env-improvement チャンネルへの投稿が活性化しました。複数人開発での考察やPoC、小さな社内ツールでの効率化事例、既存プロジェクトへの適用の試行など、様々な取り組みが共有されるようになりました。

また、Cursorの導入によってAIエージェントへの感度が組織全体で高まっており、企画職で使いこなす方も出てきました。社内の福利厚生で利用できるClaude ProでのClaude Code利用者も増加し、ナレッジ共有が盛んになっています。

課題と対応

セキュリティポリシーの整備やコードベースの取り扱いルールの明確化については、導入前から準備を進めていたため粛々と運用しています。ベストプラクティスをチーム間で共有する仕組みづくりも継続して取り組んでおり、今後は全社への展開計画も策定していく予定です。

引き続き、AI を活用した効率化と新しい体験創出に取り組んでいきます。

ColoplTechについて

ついにきた！Google Cloud Spannerの「事前分割（Pre-splitting）」で大規模トラフィックに備えよう

2025-05-26T11:00:00+09:00

こんにちは、バックエンドエンジニアのごましおです。

Google Cloudは2025年4月28日、Spannerデータベースの新機能「事前分割（Pre-splitting）」の一般提供を開始しました。

事前分割の概要 | Spanner | Google Cloud

この機能は、大規模かつ予測可能なトラフィック増加に備えて、データベースの分割点（split points）を事前に設定することで、パフォーマンスの安定性を確保するためのものです。

今回は、この事前分割機能について検証した結果をご紹介します。

コロプラとSpanner分割の歩み

コロプラでは2018年からSpannerを利用しており、特に新しいゲームのリリースタイミングに合わせて実施しているウォームアップに関しては、このテックブログや勉強会でも発信しております。

そんな我々にとって待望の事前分割機能がついに公式でGAになったということで、早速検証してみました。

Spannerにおける分割(splitting)とは

Spannerは通常、トラフィック変化に応じて自動的にデータを分割（スプリット）または統合（マージ）することで、インスタンス内のリソース全体に負荷を分散します。しかし、製品リリースなどの大規模イベントに備える場合、この自動分割だけでは十分なパフォーマンスを確保できないケースがあります。

事前分割機能の登場以前の手動分割

事前分割機能が登場する以前は、大規模なトラフィック増加に備えるために、手動でSpannerに負荷をかけて分割を促す必要がありました。この手法では、cloudspannerecosystem/gcsb などのツールを使用して、人工的な負荷をかけることでデータの分割を促していました。

しかし、この手動での分割方法には以下のような課題がありました。

時間とコストの問題: 十分な分割を促すためには長時間の負荷試験が必要で、その間のリソース消費によるコストが高くなる
分割数の制御が困難: 負荷をかけても、狙った数の分割数にすることが難しく、結果の予測性が低い
運用の複雑さ: 負荷テストの設定や監視、調整などの運用負担が大きく、エンジニアリングリソースを多く消費してしまう

事前分割機能を適切に活用することで、これらの課題を解決できます。

用語

まず、公式ドキュメントで使用されている用語を整理しておきましょう。

英語	日本語	説明
splits	スプリット	分割された領域のこと
split points	分割点	データを分割する境界となるポイント
splitting	分割	データを分割する処理
Pre-splitting	事前分割	トラフィック増加の前にデータを分割すること
merging	統合	分割されたデータを統合する処理
rebalancing	再調整	データの分布を調整する処理

例: 分割点（split points）を10個作ると、11個のスプリット（splits）が作成されます。

運用上の注意点

事前分割機能を利用するうえで、いくつかの重要な注意点があります。

タイミング

分割ポイントは、予想されるトラフィック増加の 7 日前から 12 時間前までに作成する必要があります。

という記載があります。これに伴い、負荷試験の実施方法やリリース時の準備も従来の手法とは変わってきます。

負荷試験

分割点を作って同日中に試験するのは難しいため、試験前日までに分割点を作成しておくなどの工夫が必要になります。

リリース準備

従来の手法では、スプリット作成のためのウォームアップは製品リリースの2日前に実行することとなっていました。これはGoogle Cloud公式ブログなどでも言及されています。

Cloud Spanner のウォームアップツールとベンチマークツールでアプリケーションのリリースを簡単に | Google Cloud Japan ブログ

これはSpannerのスプリットは負荷がかかっていない状態が続くと内部的に統合(merging)されてしまうため、日を空けすぎるとせっかく作成したスプリットが意味を失ってしまうという事情があったものと考えられます。従来の手法ではリリース日によっては休日作業が必要になってしまっていましたが、事前分割機能を活用することで余裕を持ったリリーススケジュールを設定できるようになります。

パフォーマンスへの一時的な影響

分割は即時には行われません。分割と再調整がトラフィックに対応できない場合、使用可能なコンピューティングリソースとメモリリソースがスプリットによって使い果たされる可能性があります。この場合、Spanner の作業スケジューラがキューに入れるリクエストがさらに増え、レイテンシが増加し、タイムアウトやトランザクションの中止につながる可能性があります。

という記載があります。分割点は作成してすぐに効果のある機能ではなく、作成後にSpanner内部で行われる再調整に時間とリソースが使われる機能です。すでにアクセスが来ている状態で、負荷を軽減するために応急処置的に使える機能ではないということに注意する必要があります。

実際にアクセスが来ているテーブルやインデックスに対してオンラインで分割点を追加すると、スロークエリが発生するなど一時的な性能劣化につながることが確認できました。対象のテーブルやインデックス、およびそのインターリーブ配下のテーブルが影響を受ける可能性があります。

アクセスが来ていないテーブルやインデックスに対する分割点の作成がデータベース全体のパフォーマンスに与える影響については、現時点で結論が出ていないため、本稿では記載を控えさせていただきます。

リソースの管理

テーブル、インデックス、データベースを削除する前に、対応する追加されたすべてのスプリットポイントが期限切れになっていることを確認する必要があります。これを行うには、分割の有効期限を現在の時刻に設定します。これは、インスタンスレベルの割り当てを再利用するために必要です。

という記載があります。負荷試験中はテーブルを再作成することもよくありますが、その際に分割点を忘れずに削除(有効期限を過去に更新)するようなオペレーションにしなければなりません。

実装方法

ここでは公式の手順を参考にしつつ、gcloudコマンドを使用した分割点の作成手順をご紹介します。

分割ポイントを作成、管理する | Spanner | Google Cloud

分割点の作成手順

1. 負荷試験によるスプリット数の見積もり

まず、事前分割なしで想定負荷の試験を数時間程度を目安に実施します。この時点ではスプリットが存在しないため、スロークエリの発生などパフォーマンスが安定しないですが気にしません。CPU使用率が上がりすぎないようにノード（Processing Units）数は調整しましょう。

以下の User テーブルと INDEX を例とします。userId, token はそれぞれ UUID v4 の値が入るとします。

CREATE TABLE User (
  userId STRING(36) NOT NULL PRIMARY KEY,
  token STRING(36),
);

CREATE UNIQUE INDEX User_token_unique ON User(token);

試験実施後、対象テーブルのフルスキャンクエリを発行して実行計画から実行数（Number of executions）を確認します。

SELECT COUNT(*) FROM User@{FORCE_INDEX=_BASE_TABLE};

SELECT COUNT(*) FROM User@{FORCE_INDEX=User_token_unique};

実行計画は Google Cloud Console や gcloud コマンドでも確認できますが、より詳細な情報を確認するには spanner-cli が便利です。これは Google Cloud 公式ではなく、コミュニティによって開発されているオープンソースのコマンドラインツールです。2025/5/21 時点では「Do not use this tool for production databases as the tool is still alpha quality.」という記載があるため、本番環境での使用には注意が必要です。

spanner-cli で確認する場合は EXPLAIN ANALYZE を使用します。なお、spanner-cliでは「Number of executions」ではなく単に「Executions」というカラム名で表示されます。

spanner> EXPLAIN ANALYZE SELECT COUNT(*) FROM User@{FORCE_INDEX=_BASE_TABLE};
+----+---------------------------------------------------------------------------------------------------------+---------------+------------+---------------+
| ID | Query_Execution_Plan                                                                                    | Rows_Returned | Executions | Total_Latency |
+----+---------------------------------------------------------------------------------------------------------+---------------+------------+---------------+
|  0 | Serialize Result (execution_method: Row)                                                                | 1             | 1          | 76.39 msecs   |
|  1 | +- Global Stream Aggregate (execution_method: Row, scalar_aggregate: true)                              | 1             | 1          | 76.39 msecs   |
|  2 |    +- Distributed Union (distribution_table: User, execution_method: Row, split_ranges_aligned: false)  | 0             | 1          | 76.38 msecs   |
|  3 |       +- Local Stream Aggregate (execution_method: Row, scalar_aggregate: true)                         | 0             | 31         | 0.81 msecs    |
|  4 |          +- Local Distributed Union (execution_method: Row)                                             | 0             | 31         | 0.76 msecs    |
|  5 |             +- Table Scan (Full scan: true, Table: User, execution_method: Row, scan_method: Automatic) | 0             | 31         | 0.51 msecs    |
+----+---------------------------------------------------------------------------------------------------------+---------------+------------+---------------+

この実行数がスプリットと深い相関関係にあるそうです。以降この実行数=スプリット数のターゲットとしていきます。

2. 対象テーブルの再作成

事前分割を作成する前に、負荷試験で使ったテーブルやINDEXは再作成（DROP + CREATE）しておきます。

3. インスタンスのノード数を調整する

1ノードにつき分割点を10作るのが推奨されています。例えば、25スプリットが必要な場合は、最低3ノードのインスタンスが必要になります。

4. 分割点を記載したファイルを用意する

今回はUserテーブルとtokenインデックスを31分割するため、それぞれ30個の分割点を作成します。分割点を作成するためのファイルは以下のようになります。

user_splits.txt

TABLE User ('08000000-0000-0000-0000-000000000000')
TABLE User ('11000000-0000-0000-0000-000000000000')
...
TABLE User ('F8000000-0000-0000-0000-000000000000')

token_splits.txt

INDEX User_token_unique ('08000000-0000-0000-0000-000000000000')
INDEX User_token_unique ('11000000-0000-0000-0000-000000000000')
...
INDEX User_token_unique ('F8000000-0000-0000-0000-000000000000')

今回はUUIDのカラムを対象にしているため、UUIDの範囲を31等分するような値を用意します。実際のカラム型とデータ範囲に合わせて用意してください。

5. gcloudコマンドで分割点を作成する

gcloud spanner databases splits add your-database \
  --instance=your-instance \
  --splits-file=user_splits.txt \
  --project=your-project-id

gcloud spanner databases splits add your-database \
  --instance=your-instance \
  --splits-file=token_splits.txt \
  --project=your-project-id

分割点作成に関する上限として、1ノードにつき1分間に10個の分割点までと制限されています。例えば、3ノードに対してUserテーブル用の30個とtokenインデックス用の30個を一度に作成できません。ファイルを2つ用意して個別に実行する必要があります。また、Userテーブル用の30個を作ったら1分間隔を空けてtokenインデックス用の30個を作成する必要があります。

# 1ノードにつき1分間に10個の分割点作成の上限に達した場合
$ gcloud spanner databases splits add your-database \
  --instance=your-instance \
  --splits-file=user_splits.txt \
  --project=your-project-id
ERROR: (gcloud.spanner.databases.splits.add) RESOURCE_EXHAUSTED: Total user split point count processed per minute limit is 30.Total number of splits processed in the last minute was 30, the request contains 30 excessive split points.

6. 分割点を確認する

以下のクエリを実行して作成した分割点を確認できます。

SELECT * FROM SPANNER_SYS.USER_SPLIT_POINTS

7. 実行計画で分割点が使われることを確認する

分割数を見積もるときと同様のフルスキャンクエリを発行して、実行計画から分割点が使われていることを確認します。実行数(Number of executions)が作成した分割数になっていればOKです。

SELECT COUNT(*) FROM User@{FORCE_INDEX=_BASE_TABLE};

SELECT COUNT(*) FROM User@{FORCE_INDEX=User_token_unique};

分割点の削除

分割点を削除するためのAPIは提供されていないため、有効期限を過去に設定するという方法で削除します。

gcloud spanner databases splits add your-database \
  --instance=your-instance \
  --splits-file=user_splits.txt \
  --split-expiration-date=2023-01-01T00:00:00Z \
  --project=your-project-id

gcloud spanner databases splits add your-database \
  --instance=your-instance \
  --splits-file=token_splits.txt \
  --split-expiration-date=2023-01-01T00:00:00Z \
  --project=your-project-id

通常の有効期限設定も同じコマンドで行えます。指定しなかった場合のデフォルトは10日間で、最大で30日後まで指定可能です。

検証結果

ちょうど負荷試験を行っていたプロジェクトがあったため、従来の手法でウォームアップした状態と事前分割機能を用いてウォームアップした状態それぞれで負荷試験を実施してみました。試行回数は多くないですが、従来の手法と比較して事前分割機能を用いたウォームアップでも同等の安定性が得られました。

その他の確認ポイント

1. 分割点作成にかかる時間

分割点の作成自体は数秒で完了し、作成後すぐにスプリットが使われる実行計画になることが確認できました。公式ドキュメントでは作成後に最低12時間空けるよう推奨されており、この間にデータの再配置などが裏側で行われているものと思われます。

2. 分割点が期限切れになったときの挙動

アクセスがある状態で分割点が期限切れになっても、即座にスプリットなしの状態にはなりませんでした。つまり、期限が切れていきなり性能が劣化するということはありません。ドキュメントによれば、管理がユーザーからSpannerに移るだけとのことで、従来のスプリットと同じく負荷に応じて自動的に分割・統合が行われていくと考えられます。

まとめ

Spannerの事前分割機能は、明示的に削除するAPIがないなどオペレーション面でやや不便な点もあるものの、基本的には我々が求めていた機能が提供されたと言える評価でした。負荷試験やリリース前の準備にかかるコストの大幅削減が期待できます。

今回はgcloudコマンドを使って分割点を作成しましたが、クライアントライブラリーでも提供されているため、機能実装することでより使いやすい形で利用できる可能性もあります。

大規模なトラフィック増加を見込むサービスのリリースなどを計画している場合、Spannerの事前分割機能を活用することで、より安定したパフォーマンスの確保が期待できます。

参考資料

事前分割の概要 | Spanner | Google Cloud - 公式ドキュメント
分割ポイントを作成、管理する | Spanner | Google Cloud - 公式ドキュメント
cloudspannerecosystem/gcsb - Spannerの負荷テストツール
Cloud Spanner のウォームアップツールとベンチマークツールでアプリケーションのリリースを簡単に - 事前分割機能が登場する以前のウォームアップに関する情報

ColoplTechについて

Google Cloud Next '25 に参加しました

2025-04-25T11:00:00+09:00

こんにちは、バックエンドエンジニアの山田 (@yamadashy) です。

4/9(水)から4/11(金)にかけて開催されたGoogle Cloud Next '25に参加してきました。

Google Cloud Nextは、Google Cloudに関する最新情報や今後の展望を共有する年次イベントで、今年もラスベガスのMandalay Bay Convention Centerで開催されました。

コロプラからは、薮、駒崎、そして私の3名が参加。昨年に続いて2年目の参加となりました。今年のカンファレンスでは、生成AIを中心とした多くの発表があり、その中から特に印象に残った内容について詳しくご紹介させていただきます。

なお、昨年の参加レポートはこちらで詳しく紹介しています。

Opening Keynote: The new way to cloud

準備

約1ヶ月前には公式サイトのSession Libraryが公開されます。予約が必要なセッションはすぐに埋まるので、興味のあるものをなるはやで予約することをおすすめします。

セッションの種類は以下の通りです。

Keynote（基調講演）
Breakout Session（技術解説や事例紹介の講演）
Hands-on Lab（実際に手を動かすワークショップ）
Developer Meetup（開発者同士の交流会）
Roundtable（少人数のディスカッション形式）

また、現地参加の場合は以下のような準備もしておくと良いと思います。

Roundtableや日本向けのイベントなどは名刺交換なども行うので、十分な枚数の名刺を用意しておく
公式アプリを活用すると、セッション情報や会場マップ、最新のお知らせを確認できて便利
イベント中はセッション以外にも Expo など他の展示もあることを念頭に置いてスケジュールを決める

渡航・スケジュール

海外出張の準備は、昨年の経験を活かして比較的スムーズに進めることができました。ラスベガス行きのフライトは乗り継ぎを含む長時間の旅でしたが、機内では映画を観たりしてリラックスして過ごしました。

今回の全体的な出張スケジュールは以下の通りです。

日付	時刻	場所	内容
4/8（火）	14:27	Las Vegas	ハリー・リード国際空港到着
〃	18:30	Mandalay Bay	Japan Welcome Reception
4/9（水）	終日	Mandalay Bay	Google Cloud Next '25
〃	19:00	Bonito Michoacan Mexican Restaurant	GME Dinner
4/10（木）	終日	Mandalay Bay	Google Cloud Next '25
〃	19:00	アレジアント・スタジアム	Next at Night
4/11（金）	終日	Mandalay Bay	Google Cloud Next '25
〃	19:00	Mandalay Bay	Japan Session & Reception
4/12（土）	08:00	Las Vegas	ハリー・リード国際空港発

イベント前日の4/8(火)にラスベガスに到着。長時間のフライトで疲れは隠せませんでしたが、到着後すぐにJapan Welcome Receptionに参加しました。このイベントには日本からエンジニアだけでなく、営業やマーケティングなど様々な分野・業種の方々が集まっており、普段は接点の少ない方々との交流ができました。エンジニアとも現在話題のGemini 2.5 Proを初め、Cline, Cursor などのコーディングエージェントの話もでき、とても刺激的な時間となりました。

今回の滞在先は Horseshoe Las Vegas でした。会場までは車で10~15分ほどのホテルです。ホテルのロビーには定番のカジノが広がり、エレベータホールからは話題のスフィアも見ることができました。

Google Cloud Next '25 in Las Vegas

今年は世界中から30,000名以上の参加者が集まり、日本からも850名以上が参加しました。300以上のセッション、ハンズオンなどが提供され、展示エリアでは多くのパートナー企業がブースを出展し、最新のソリューションやサービスを紹介していました。

Google Cloud Next 2025 をまとめた記事(英語)が公式で公開されているので、興味のある方はぜひご覧ください。

cloud.google.com

Opening Keynote

カンファレンス初日の朝、Mandalay Bay のメインホールで基調講演が開催されました。
我々は1時間前には会場に到着していましたが、その時点ですでに多くの席が埋まっておりました。次回参加される方は早めの行動をおすすめします。

講演には Google Cloud CEO のトーマス・キュリアン氏と、Google および Alphabet CEO のスンダー・ピチャイ氏が登壇。生でスンダー・ピチャイ氏のスピーチを聞けたのは、オフライン参加ならではの貴重な体験でした。

今回のキーノートでは、やはり生成AI関連の話題が中心でした。エンジニアとして興味深かったのは、マルチエージェントシステム構築を支援する「Agent Development Kit（ADK）」や、エージェント間の通信を可能にする「Agent2Agent Protocol（A2A）」の紹介です。A2A は SNS でも話題になっており、 MCP（Model Context Protocol）と比較されていましたが、A2A はエージェント間の協調動作に特化しており用途や思想が異なるようですね。

講演中には製品の実際のユースケースを用いたデモも多数紹介されました。
たとえば、Vertex AI の「Vertex Media Studio」を使ってテキストから高品質な動画を生成する「Veo 2」や、テキストから音楽を生成できる「Lyria」のデモは、AI の実用性と創造性の可能性を強く感じさせるものでした。

キーノートのアーカイブは以下でご覧いただけます。

www.youtube.com

セッション

Cloud Next では、Google Cloud の製品/サービスの発表の他にも、Google のパートナー企業などが自社のソリューションを紹介するセッションも多数開催されていました。

そのなかでも現地のメンバーが気になったセッションをピックアップしてご紹介します。

What's next for Google Cloud databases in the AI era

Google CloudのデータベースがAI時代にどう進化しているかについて紹介がありました。

特に印象的だったのは、データベースに対する自然言語インターフェースの進化です。BigQueryやSpannerで自然言語クエリが可能になり、例えば「過去30日間の売上トップ10の商品を教えて」のような質問を直接投げかけることができるようになりました。

AlloyDBでは、AIクエリエンジンが導入され、SQL内に自然言語表現を組み込めるようになったほか、ベクトル検索も大幅に最適化されています。標準のPostgresと比較して最大10倍の高速化が実現し、テキストだけでなく画像や動画も含めたマルチモーダル検索が可能になったとのことです。

SQLに精通していないユーザーでもデータにアクセスしやすくなりそうなのは大きな変化だと感じました。特に自然言語でのクエリ機能は、データ分析の敷居を下げ、より多くの人がデータドリブンな意思決定を行える可能性を秘めていますね。一方で、負荷やコストが読めないところは慎重になる必要はありそうです。

Accelerate your code reviews with Gemini Code Assist in GitHub

GitHub上でGemini Code Assistによるコードレビューの自動化が紹介されました。

GitHub マーケットプレイスから導入したGeminiは、プルリクエスト作成時に自動的にレビュアーとして加わり、変更内容の要約・改善提案・マージ準備状況評価を短時間で提供します。/geminiコマンドで特定コードの質問も可能で、.gemini/styleguide.mdファイルで企業独自の規約に合わせたカスタマイズができます。

導入事例では、レビューサイクル短縮や早期バグ発見など顕著な効果が報告され、90%の開発者が生産性向上を実感したとのことです。デモでは実際のプルリクエストでGeminiが行うレビューやアドバイスが示されました。

CodeRabbitやGitHub Copilotなど他のツールとの比較において、レビューの精度や使い心地が気になるところですね。

Build AI agents on Cloud Run

Cloud Run を利用してAIエージェントを構築・実行する方法が紹介されました。

LangChainの共同創設者であるHarrison氏がLangGraphフレームワークについて説明した後、Cloud Runがエージェント実行に最適な理由として、自動スケーリング、使用時のみの課金体系、高い信頼性、ストリーミングのネイティブサポートなどが紹介されました。

最も印象的だったのは、Code Rabbitの事例です。このサービスは、GitHubなどのプラットフォーム上でAIによるコードレビューを自動化しています。特に興味深かったのは、AIがリポジトリをクローンし、影響範囲を把握するためにrip-grepやgrep検索を実行するなど、人間のような探索方法でコードを理解していく点です。アーキテクチャ図や実際のインスタンス数なども共有されており、コードレビューアシスタントの裏側を垣間見れて良いセッションでした。

Maximize the availability and performance of your Cloud SQL workloads

Cloud SQLのEnterprise Editionについて紹介されたセッションでした。

GoogleのカスタムArmベースのプロセッサ（プレビュー、6:14〜）を利用することで、N2に比べて48%ものパフォーマンス向上が見込めるとのことです。

また、「optimize write」（9:57〜）機能についても解説があり、2h 以上にわたるwriteスループットの向上や、98%以下のwriteレイテンシーの実現が強調されていました。

さらに、「Managed Connection pooling」（12:52〜）の紹介もあり、スループットが5倍、レイテンシーも85%改善されるなど、接続管理の効率化による大幅なパフォーマンス向上が示されていました。

Solve real-time AI challenges: Bigtable and BigQuery in Spotify's music recommendation engine

Spotifyの音楽レコメンデーションシステム(8:35〜)では、レイテンシーと新鮮さのトレードオフという課題に直面しています。このセッションでは、Google Cloud Storage, Bigtable, Dataflow, BigQueryなどのGoogle Cloudのデータ分析基盤を活用して、この課題をどのように解決しているかについて、具体的なケーススタディとして解説されました。

Go developers meetup

Go言語ユーザーが集まり、どのようなきっかけでGo言語を使い始めたのか（Kubernetesがきっかけという方が多かったです）などをグループでディスカッションしました。技術的な新しい学びは多くありませんでしたが、さまざまなバックグラウンドを持つ参加者と、Go言語歴や経験について気軽に語り合うことができ、とても楽しい時間となりました。

共通のトピックがあることで、初対面の方とも自然にコミュニケーションが生まれるのが meetup の魅力です。他の開発者と交流したい方には、meetup はぜひおすすめしたいセッションです。

Transform cloud operations and management with generative AI

GoogleCloudコンソールの至るところにAIアシスタンス機能が実装されたことを紹介するセッションでした。ローコードでインフラ構築ができるApplication Design Center、チャットサポートのCloud Assist、コスト最適化をサポートするCloud Hub、アプリケーションのメトリクスやログを横断的に見ることができるApplication Monitoringなどが紹介されました。

GoogleCloudのドキュメントを調べなくても答えてくれるCloud Assistはとても便利にいますぐでも使えそうです。Application Desing Centerは使ってみないと実用できるかはまだわからなさそうでした。Application MonitoringはCloud Traceと統合されて、Google Cloud上にシグナルを流しとけばAIパワーでいい感じに問題特定できるようになったりすると、Observability関係でアプリケーション実装者が気にすることが減り、とても便利になりそうな未来が見えました。

What's new with Memorystore for Valkey

2025/4/2にGAとなったMemoryStore for Valkeyのセッションです。 Valkey Recommended for all new workloadsと言っていたので、もう使うしかありません。 Valkey8.0で7.2に比べて並列処理性能が向上した部分などについても解説していました。

MLBのリアルタイムstatsデータを配信するシステム周辺のValkeyとMemoryStoreの使い方についても聞くことができました。ほぼリードオンリーのトラフィックとはいえ膨大なデータがどのくらい発生してどのように捌いているのか、生々しいデータが聞けて興味深かったです。

ラウンドテーブル

カンファレンス期間中、Google Cloud のスペシャリストと直接対話できるラウンドテーブルに参加しました。少人数制の対話形式で行われたため、普段の技術セッションでは聞けないような具体的な質問もでき、非常に有意義な時間となりました。

Cloud Next 展示エリア

展示エリアでは、Googleのパートナーやソリューションプロバイダーが多数出展していました。

特に印象的だったのは以下のブースです。

Anthropic ブース

Anthropicのブースでは、ClaudeやSDKのハンズオンセッションが実施されていました。残念ながら時間の制約で直接の対話は叶いませんでしたが、日頃からClaudeを活用している身として、開発チームの方々を直接拝見できたことは貴重な経験でした。また、Anthropicのブランドロゴ入りペンを記念品としていただき、カンファレンスの思い出の品として大切にしています。

Datadog ブース

Datadogのブースでは、コロプラで日常的に活用しているDatadogについて、エンジニアの方々と気軽に情報交換をさせていただきました。技術的な詳細まで踏み込むことは叶いませんでしたが、Datadogのエンジニアチームの雰囲気を直接感じられる貴重な機会となりました。また、Datadogのブランドロゴ入りソックスを記念品としていただきました。

コロプラはDatadogに関する記事をいくつか出しているので、興味のある方はぜひご覧ください。

findy-tools.io

Redis ブース

3日目に立ち寄ったRedisブースではルーレットを連続で目押ししてうまく全部止められたら景品がもらえました。私はRedisカーをもらいました。

Google Cloud認定資格ラウンジ

以前、Google Cloud主催の「E.G.G. Japan」というプログラムで、Professional Cloud Developer認定資格を取得しており、認定資格保持者専用のラウンジに入ることができました。

内部は空港のラウンジのような空間で、ソファが配置されており、専用のお菓子やコーヒーを楽しみながらゆったり休憩できました。また、認定資格保持者限定のバッジもいただけました。

「E.G.G. Japan」プログラムの詳細や参加体験については、以下の記事で詳しく紹介しています。

https://cloud.withgoogle.com/next/25?session-details=NXN-001

Cloud Next その他イベント

Next at Night

カンファレンスの2日目には、Allegiant Stadium で開催された Next at Night に参加しました。開演は19:00からで、ラスベガス出身の The Killers をヘッドライナーに、グラミー賞受賞者 Wyclef Jean と新進気鋭のシンガーソングライター Tate Renner が特別出演。技術カンファレンスの参加者限定のコンサートで、リフレッシュするのに最適なイベントでした。

日本語セッションと懇親会

カンファレンス最終日の夕方には、日本人参加者向けに日本語でのおさらいセッションが開催されました。主要な発表内容を日本語で解説してくれるため、英語のセッションで聞き逃した部分を補完することができました。

このセッションで話された内容はこちらのページから資料を確認できます。

https://cloud.google.com/resources/content/intl/ja-jp/nextlv25-jp-recap?hl=ja

セッション後には日本人参加者による懇親会も開催され、普段関わることのない企業の方々とも情報交換できたのは非常に貴重な経験でした。

エンタメ体験

コロプラはエンターテインメントを大切にする会社です。カンファレンス以外の時間もラスベガスのエンターテインメントを存分に楽しみました。

シルクドソレイユ「カー」

世界的に有名なシルク・ドゥ・ソレイユの「カー」を観賞しました。このショーは、垂直に動く巨大なステージを特徴とし、武術とアクロバティックなパフォーマンスが融合した圧巻のエンターテインメントです。

少し印象的だったのは、開演前のパフォーマンスで、おそらく準備運動の一貫かと思われますが、観客の期待感を高める良いアイデアだなと感じました。

スフィア

ラスベガスの新しいランドマークであるスフィアを訪れました。

Google Cloud Next 25の前日には特別な発表会が開催され、1939年公開の名作映画『オズの魔法使(The Wizard of Oz)』をスフィアの16Kスクリーンで上映するプロジェクトが発表されていました。

今回は上映を見れませんでしたが、Keynotesでも紹介されていたこのプロジェクトは、Google Cloudと生成AIを活用して、オリジナルの精神を尊重しつつ前例のない没入型体験を実現していると話されており、来年も参加できればぜひ見に行きたいですね。

HyperX Arena Las Vegas

eスポーツ専用アリーナであるHyperX Arena Las Vegasも訪問しました。プロゲーマーの試合の実況が本格的に行われており、ゲーム会社の社員として非常に興味深い場所でした。

おわりに

Google Cloud Next '25は、最新技術の動向を知るだけでなく、世界中の様々な職種の方々と交流できる、非常に刺激的で学びの多いイベントでした。生成AIやクラウドインフラの進化を肌で感じ、日々の業務や今後のプロジェクトに活かせるヒントがたくさん得られたのは大きな収穫です。

また、現地のブース展示や他社の方々との会話を通じて、ドキュメントや動画だけでは得られないリアルな気づきや、新たな視点にも多く出会えました。こうした偶発的な出会いや体験こそが、オフライン参加の醍醐味だと改めて感じました。

この記事が、Google Cloud Nextへの参加を検討されている方や、クラウド技術に関心をお持ちの方にとって、少しでも参考になれば幸いです。

ColoplTechについて

Findyイベント「次世代DB戦略を支えるNewSQL」に登壇しました

2025-02-21T15:53:02+09:00

こんにちは、バックエンドエンジニアの山田です。

コロプラのPlatform Engineerの尾山が、2024年2月19日(水)に開催された「次世代DB戦略を支えるNewSQL 〜導入企業が語る導入背景と今後の展望〜」にて「Cloud Spanner 導入で実現した快適な開発と運用について」というタイトルで登壇させていただきました。

findy-tools.connpass.com

登壇内容について

登壇では、2017年頃にコロプラが直面していたデータベースの課題から、Cloud Spannerの採用に至った経緯をお話しさせていただきました。 MySQLの複雑化する運用課題に対し、Cloud Spannerという選択がどのようなインパクトをもたらしたのか。また、大規模アクセス時の知見など、実際の運用経験から得られた学びについても共有させていただきました。

より詳細な内容については、ぜひスライドをご覧ください。

speakerdeck.com

また、イベントの模様はアーカイブ動画でもご覧いただけます。

おわりに

コロプラでは、以前にも「Cloud Spanner への挑戦と今」という勉強会を実施するなど、積極的に技術共有を行ってきました。

今後も積極的に各種イベントへの参加や技術共有を続けていきたいと考えております。引き続きご注目いただければ幸いです。

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびXで情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

コロプラの「オンボーディング事例」をFindyイベントで紹介しました

2025-02-06T11:00:00+09:00

こんにちは、バックエンドエンジニアの山田です。

2025年1月15日(水)に開催されたFindyのオンラインイベント「エンジニアがチームで活躍するまでの『オンボーディング事例』～新メンバー側と受け入れ側に学ぶ～」にて、弊社の田中諒（たなりょ）が登壇しましたのでご報告させていただきます。

findy.connpass.com

イベント概要

本イベントは、エンジニアのオンボーディングにおける課題や工夫について、新メンバー側と受け入れ側の両者の視点から知見を共有することを目的として開催されました。特に、以下のような課題に焦点を当てています。

ジョイン前からの高い期待が重圧となり、パフォーマンスの妨げになっていないか
受け入れ側の"お手並み拝見感"が出ていないか
専門的なドメイン知識の効率的な共有方法

登壇内容について

弊社は「コロプラのオンボーディングを採用から語りたい」というテーマで登壇し、バックエンドエンジニア部署におけるオンボーディングの取り組みについて紹介しました。

ゲーム業界がレッドオーシャンと言われる中で、「なぜコロプラが中途採用を積極的に行うのか？」という問いから話は始まります。ただのマンパワー確保ではなく、組織の持続的な成長とイノベーションを生み出すために、社内の「知見共有の活性化」が不可欠であるという考えが根底にあります。新たに加わるエンジニアが、これまでの経験を活かしながらスムーズにチームに馴染み、成果を発揮する。そしてそれを組織的な知見の獲得と活用に繋げていく。それが、私たちのオンボーディングの位置付けです。

この考えのもと、採用プロセスから配属後までの一貫したストーリーを構築しています。「どのような経歴を持つエンジニアが、どのような期待を受けてチームに加わるのか」を現場としっかり共有することで、受け入れ側の課題を最小化し、新メンバーが早期に活躍できる環境づくりを進めています。

具体的な取り組みや施策の詳細については、ぜひこちらの登壇資料をご覧ください。

speakerdeck.com

また、イベントの模様はアーカイブ動画でもご覧いただけます。

おわりに

コロプラでは今後も、エンジニアの成長と組織の発展に関する知見を積極的に発信していく予定です。引き続きご注目いただければ幸いです。

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびXで情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

【資料公開】PHP Conference Japan 2024 に登壇・出展させていただきました

2024-12-24T11:00:00+09:00

こんにちは、 Platform Engineer の工藤です。

12 月 22 日 (日曜) に開催された PHP Conference Japan 2024 にて「怖くない！ゼロから始めるPHP ソースコードコンパイル入門」というタイトルで登壇させていただき、また株式会社コロプラもシルバースポンサーとして出展させていただきました。

PHP Conference Japan について

コロプラとしても 2022 年から協賛させていただいており、 2023 年同様今年もスポンサーブースの出展をさせていただきました。

スポンサーブース出展について

スポンサーブースでは「あなたのAwesome PHPを教えてください！」という企画を実施させていただき、来場いただいた方々に「Awesome」と感じる PHP にまつわるあれこれを投票していただきました！

#phpcon にて「あなたのAwesome PHPを教えてください！」というアンケートを実施させていただきました！

多くの方にブースへお立ち寄りいただき、PHPの開発技術について活発な議論ができました。
貴重なご意見をありがとうございました！ pic.twitter.com/o6aejWcSIW
— COLOPL_Tech (@colopl_tech) 2024年12月22日

ダントツで得票数が多かった Laravel や、地位を確立し普及期に入ったことがわかる PHPStan の得票数、そして何より PHP Conference Japan というイベントへの投票など、国内における PHP の今を知ることができる楽しい企画になったのではないかと思います！

特に出展メンバーの中では PHPUnit のシールがとても規則的に貼られていて、テスタビリティを重視する人達の特性が現れてそう、と話題になったりもしました。

登壇について

コロプラからは Platform Engineer の工藤が「怖くない！ゼロから始めるPHP ソースコードコンパイル入門」という内容で登壇させていただきました。登壇の様子やスライド資料などは以下で確認できます！

緊張から早口になったり等反省すべき点も多々見受けられますが、予想よりも多くの方に見ていただくことができとても有意義なものにしていただけたのではないかと感じております。質疑応答にて PHP をコンパイルすることを目標に C コンパイラを自作している方がいらっしゃったりと、登壇者としてもとても良い刺激を受けることができました！

また、登壇内容については内容や質疑応答への補足を含めた記事を予定しております！

おわりに

コロプラでは、今後も積極的に各種イベントに参加していきたいと考えており、来年は更に積極的なコミュニティへの参加・貢献ができるようもう一歩踏み込んで行きたいと考えております！まだまだ未熟な点も多いですが、今後ともよろしくお願いいたします！

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびXで情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

dd-trace-phpとOpenTelemetry Collectorを使ってDatadogにトレースを送る際のハマりポイントと解決方法

2024-12-16T11:00:00+09:00

こんにちは、LCE(Launch Coordination Engineering)チームとして新作ゲーム開発の支援を行っている駒崎(@dkkoma)です。

コロプラではLaravelアプリケーションの計装にDatadog製のトレーシングライブラリであるdd-trace-phpを利用しています。

今回、新作ゲーム開発プロジェクトのCloudRun環境においてDatadogにトレース情報を送る経路を構築する中でいくつかハマりどころがあったため、その内容と解決方法を解説したいと思い、こちらの記事を書くことにしました。

構成

アプリケーションからDatadogまでの経路はLaravel(dd-trace-php) -> OpenTelemetry Collector(datadogreceiver + otlpexporter) -> Datadog Agent -> Datadogというパターンで構築しています。Datadog AgentがOTLP Receiverを実装しているのとCloudRunのサービス間認証を利用する都合で、OpenTelemetry CollectorからDatadog AgentへはOTLPで送信しています。Datadogに送信する手前でDatadog Agentを使っているのはレアサンプラーやエラーサンプラーなどの機能を使いたいためです。

ハマりポイント1: Spanの名前が期待通り送られない

Datadog上で見えるSpan名が以下のようになってしまっていました。間にOpenTelemetry Collectorを挟まなければクラス名やSQLが表示されるのですが、これではどのSpanが何なのか識別がとても難しいです。

調査の結果、この問題はOpenTelemetry Collectorのtransform processorを使用することで解決できることが分かりました。具体的には、operation.nameとspan.nameに適切な値を設定することで、Datadogが意図しているであろう形式でSpan情報を保持することが可能になります。

  transform:
    error_mode: ignore
    trace_statements:
      - context: span
        statements:
          # ↓の2つの設定で span.kind, span.name がdatadog agent経由と同じになるっぽい
          # 元々は name に laravel.event.handle
          # dd.span.Resource に bootstrapping: Illuminate\Foundation\Bootstrap\LoadEnvironmentVariables などが入ってる
          - set(attributes["operation.name"], name)
          - set(name, attributes["dd.span.Resource"])

ハマりポイント2: エラーメッセージがステータスコードになる

以下のように例外のメッセージが勝手にステータスコードだけになってしまいます。本来ならエラーメッセージと例外の発生箇所がわかるようになっているはずです。

この問題もハマりポイント1と同じく、OpenTelemetry Collectorのtransform processorを使用して対処することができます。具体的には、error.msgフィールドに元のerror.messageの値を保持するよう設定することで、エラーの詳細情報を維持したままDatadogへトレース情報を送信することが可能になりました。

      - context: span
        statements:
          # error.msg にメッセージをいれておかないと変に置換されてしまう
          # exception.message にいれてもよさそうなのだが span.name が exception じゃないからか出来なかった
          # see: https://github.com/DataDog/datadog-agent/blob/a9eac7672a6cf91bec6da77c18313c6f3db4c22d/pkg/trace/api/otlp.go#L619
          - set(attributes["error.msg"], attributes["error.message"])

調査中にわかったこととしては、エラーメッセージをHTTPステータスコードに変換してしまう処理はdatadog-agent用ライブラリ内にあったのですが、opentelemetry-collector-contribのdatadogexporterでもDatadog/datadog-agentのパッケージが使われているために、このようなことになっているようでした。ただ、transform.goを見る限り、exception.messageに入れておけばDatadog用に変換してくれるロジックが実装されているようには見えたのですが、transform processerを使って設定してもダメだったのでdd-trace-phpで作ったSpanを変換することは想定していなさそうです。

所感

そもそも、Datadogの計装ライブラリ(dd-trace-somelang) -> OpenTelemetry Collector -> Datadog Agent -> Datadogというパターンで構成しているケースが探してもあまりなかったので、OpenTelemetry Collectorを使うなら計装ライブラリもOpenTelemetryを使うべしということだったのかもしれません。今回はアプリケーション側をあまり変更したくなかったのでこの構成でやった結果、なかなかハマってしまいました。

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびXで情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

architecture-con.findy-tools.io

【スライド公開】アーキテクチャ Conference 2024 に登壇・出展させていただきました

2024-11-29T11:10:00+09:00

こんにちは。バックエンドエンジニアの仲山です。

先日11月26日（火）に開催されたアーキテクチャ Conference 2024 に登壇させていただきました。この記事ではその報告と共有を書きたいと思います。

イベントについて

アーキテクチャ Conference は、ファインディ株式会社さんが主催する、ソフトウェアエンジニアリングにおけるアーキテクチャに焦点を当てたカンファレンスです。

今回は現地参加のほか、オンラインでの参加も可能となっており、現地だけで800人以上の参加者と、たくさんの企業のブース出展もあり、会場にいて大いに盛り上がりを感じました。すでに来年度の開催も決定しているなど、今とても勢いのあるイベントとなっております。

発表内容について

今回は「大規模トラフィックを支えるゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現するために~」というタイトルで、コロプラの約10年間のアーキテクチャの変遷を振り返りました。過去のアーキテクチャを眺めながら、当時どんな課題があり、その後のアーキテクチャにどのような変化があったのかをお話しさせていただきました。

ゲームサービスのアーキテクチャにあまり馴染みのない方でも、なんとなくコロプラのゲームの裏側がわかってもらえるように構成したつもりなので、まだご覧になられていない方はぜひアーカイブの方もチェックしていただければと思います。

speakerdeck.com

おわりに

初めて参加させていただいたカンファレンスでしたが、大物ゲストの基調講演から始まり、様々な企業の実際の構成や、アーキテクチャに対する考え方などが学べる非常に有意義なイベントでした。次回は羽田で世界を巻き込んだイベントになることが計画されているみたいなので、今後のアーキテクチャ Conference もますます楽しみです。

講演を聴いてくださった皆さん、ブースに足を運んでくれた皆さん、関係各社の方々、ありがとうございました！

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびXで情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

時間変更で開発を支える colopl_timesfhiter

2024-11-18T11:00:00+09:00

こんにちは、 Platform Engineer の工藤です。

突然ですが、 PHP でプロダクトを開発していて、テストやデバッグのために現在時刻を変更したくなることってありませんか？

昨今のフレームワークを利用している場合は Carbon::setTestNow メソッドなどで解決するような簡単な話ですが、運用が長期に渡るシステム (レジェンドプロダクト) においては歴史的経緯により PHP 組み込みの date() 関数や MySQL クエリ内で NOW() 関数を利用してしまっている場合があり、後からロジック的な時間変更機能を導入することは非常に困難な場合があります。

今回はそうした課題に対応するために開発した開発補助用 PHP Extension 、 colopl_timeshifter について紹介します。

※ 開発環境用です、本番環境では絶対に使用しないでください

レジェンドプロダクトと時間変更

最近のフレームワークなどを使っていればそのような機能が最初から提供されているのでそれを使えば良いですが、 10 年前に作成されたレジェンドプロダクトではロジックの中で直接 date() 関数を使っていたりして、なかなかテストしにくい構造になってしまっている場合も多いのではないかと思います。

もちろん地道に直していくのがベストな解決策ではありますが、往々にしてコード量の多いレジェンドプロダクトではなかなか実現が難しい問題があります。

リファクタリングが必要ない低レイヤーでの時間変更手段としては libfaketime を用いて PHP そのものに偽りの現在時刻を指定する方法などが考えられます。

libfaketime は LD_PRELOAD で libc の現在時刻に関わる関数をフックし、 FAKETIME 環境変数で指定された時間に偽るというライブラリです。

$ TZ=Asia/Tokyo date "+%Y-%m-%d %H:%M:%S"
2024-11-14 16:18:07
$ LD_PRELOAD=./libfaketime.so.1 FAKETIME="1994-10-26 11:22:33" TZ=Asia/Tokyo date "+%Y-%m-%d %H:%M:%S"
1994-10-26 11:22:33

or

$ TZ=Asia/Tokyo date "+%Y-%m-%d %H:%M:%S"
2024-11-14 16:25:33
$ TZ=Asia/Tokyo faketime "1994-10-26 11:22:33" date "+%Y-%m-%d %H:%M:%S"
1994-10-26 11:22:33

しかし libfaketime を用いた時間変更はあくまでも環境変数が渡されたプロセスにしか影響しないため、 php-fpm などのプロセスをフォークする環境では変更を適用するのが困難です (clear_env などの適切な設定が必要) 。

また systemd などを利用している場合にも環境変数を引き渡す際に同様の問題が発生し、時間変更を実現する環境を整えるために考慮すべきことが非常に多くなってしまいます。 faketime コマンドを利用する例もありますが、何にせよ複雑です。

また、当該プロジェクトでは MySQL の NOW() 関数を多用しており (やるべきではない) 、 PHP だけを時間変更することができたとしても MySQL 側の時間と食い違うことになってしまう状況で、 MySQL の SET @@session.timestamp を使おうにもフレームワークの ORM を利用していたりしていなかったりするため漏れなく対応するのが困難な状況に陥っていました。

現在は開発環境では同一の仮想マシンやコンテナ上で PHP, HTTP サーバー, MySQL を実行し、 OS の時間変更を用いることで対応していましたが、 SaaS への移行などに伴って今後の運用においてこの方法が通用しなくなる可能性が高く、何らかの対応が必要な状況でした。

そこで、 PHP Extension の仕組みを用いて時間変更を行える拡張機能 colopl_timeshifter を作ることになりました。

`colopl_timeshifter` について

colopl_timeshifter は PHP Extension (PHP 拡張機能) として以下の機能を提供しています。

現在時刻を扱う PHP 組み込み関数に対する時間変更機能
PDO MySQL ドライバでのクエリ実行時、透過的に @@session.timestamp で変更された時刻を設定する機能

次のようなコードで時間変更を行うことができます。

<?php

declare(strict_types=1);

use function Colopl\ColoplTimeShifter\{register_hook, unregister_hook};

/* 今より 3 日前に設定: https://www.php.net/manual/ja/dateinterval.construct.php */
register_hook(new \DateInterval('P3D'));

echo date('Y-m-d H:i:s'), \PHP_EOL;

/* 元に戻す */
unregister_hook();

/* 特定の日時に設定 */
register_hook((new DateTime('1994-10-26 11:22:33'))->diff(new DateTime('now')));

echo date('Y-m-d H:i:s'), \PHP_EOL;

/* 元に戻す */
unregister_hook();

また、接続先のデータベースが MySQL (または互換のあるエンジン) であればクエリに対しても現在時刻をモックすることができます。

<?php

declare(strict_types=1);

use function Colopl\ColoplTimeShifter\{register_hook, unregister_hook};

/* 特定の日時に設定 */
register_hook((new DateTime('1994-10-26 11:22:33'))->diff(new DateTime('now')));

echo (new \PDO('mysql:dbname=testing;host=mysql', 'testing', 'testing'))->query('SELECT NOW() AS `now`;')->fetch()[0], \PHP_EOL;

/* 元に戻す */
unregister_hook();

動作原理

colopl_timeshifter は既存の PHP の関数やメソッドをフックする仕組みで実装されており、実際に PHP Extension として読み込まれた時に以下ように行われます。

PHP の関数定義テーブル (HashMap) CG(function_table) から対象となる関数ポインタを検索
既存の関数ポインタを colopl_timeshifter のグローバル領域に保管
関数ポインタを colopl_timeshifter 側の関数に置き換え

PHP における主な日付関連処理 (ext-date) は著名な PHP 用デバッガである Xdebug の作者でもある Derick Rethans さんの timelib をベースとしています。

timelib は非常に高機能で、日の出 (sunrise) の時刻や日没 (sunset) の時刻を取得したり各国の夏時間に対応していますが、中でも特徴的なものとして 非常に口語的な日時のパースをサポートしている というものがあります。

次の日時指定構文は有効なフォーマットです。

<?php

declare(strict_types=1);

/* 今が 2024-11-14 だとすると結果は 2024-11-18 12:30:15 となる */
echo date('Y-m-d H:i:s', (new \DateTime('next monday 15sec 12pm 30min'))->getTimestamp()), \PHP_EOL;

これは場合によっては直感的に利用できて便利な一方、実際にパースが終わるまで指定されたフォーマットが絶対時刻 (現在時刻に依存しない常に一定の時刻を示す文字列) なのか相対時刻 (現在時刻に対する差分で表される文字列) なのかがわからないという問題を抱えていることになります。

実際にtimelib ではフォーマットのパース実装のために re2c レキサジェネレータが利用されており、その複雑性を伺うことができます。

しかし、現在時刻をモックする colopl_timeshifter にとってこの仕様は非常に厳しいものです。というのも、 渡されたフォーマットが絶対時刻なのか相対時刻なのかを判別することができず、時間変更を適用すべきかしないべきかの判断ができない のです。

timelib の内部実装などを調べてみましたが、やはりパース結果が絶対時刻なのか相対時刻なのかを適切に判別する方法は見当たらず、仕方がないので ごく僅かなウェイトを挟んでパースし、結果が異なっているかどうかで判別する という力技の実装を行うこととなりました。

このウェイトは INI ディレクティブ colopl_timeshifter.usleep_sec で設定することができます。

PDO のフック

では PDO MySQL への時間変更はどのように行っているのでしょうか？

PDO は PHP の汎用データベースドライバ構造で、 Java の世界での JDBC のようなものです。簡単に言うと様々なデータベースを抽象化し、ある程度共通化した仕組みで利用することができるようにするものです。

PDO は内部実装もある程度抽象化されており、 PHP の組み込み関数同様に関数ポインタを用い、構造体にセットする形で行われています。また、この構造体は PHP Extension に対して公開されており、やろうと思えば PHP の組み込み関数同様処理を乗っ取ることができます。

colopl_timeshifter は次のような順序で PDO の MySQL ドライバに対してフックを行います。

INI 設定 colopl_timeshifter.is_hook_pdo_mysql が有効であるかチェック
PDO クラスのコンストラクタ (__construct) の関数ポインタを取得し colopl_timeshifter のグローバル領域に保管
PDO::__construct メソッドの関数ポインタを colopl_timeshifter の関数ポインタに置き換え
コンストラクタ内で現在の PDO ドライバを取得し、ドライバ名が mysql であれば doer と preparer 関数ポインタ (クエリ実行関数) を乗っ取り
doer と preparer 実行時、クエリの先頭に SET @@session.timestamp = <モックした日時>; を付加

幸いにもコロプラのプロジェクトはすべて MySQL でのクエリ実行に PDO を用いているため、この手法で解決することができました。 ext-mysqli を利用しているものがあった場合にはそちらについても対応する必要があるでしょう。

`php-timecop`

どうしても必要になったので colopl_timeshifter を作っていたのですが、途中で KLab の hnw さんによるほぼ同様の PHP Extension php-timecop があったことに気付きました...とはいえ近年の PHP では動作しなかったのと、 PDO のフックも必要だったので結果オーライだと思いたい...

自分が思いつくものの大半をすでにやられている hnw さんはやっぱりすごいなと思いました。勝てない...！

`colopl_timeshifter` について

colopl_timeshifter はオープンソースソフトウェアとしてコロプラの GitHub 上で公開しています。 issue や PR も受け付けています (必ず対応するわけではないですが...) ので、興味があればぜひどうぞ

でも絶対にプロダクション環境では使わないでくださいね！

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびXで情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

PHP Conference Japan 2024 スポンサー協賛・登壇のお知らせ

2024-10-30T11:00:00+09:00

こんにちは。 Platform Engineer の工藤です。

2024 年 12 月 22 日に開催される PHP Conference Japan 2024 に株式会社コロプラとしてシルバースポンサーで協賛させていただきました。また、Platform Engineer の工藤がスピーカーとして登壇させていただきます。

PHP Conference Japan について

PHP Conference Japan は、プログラミング言語 PHP を中心とした国内最大級のカンファレンスイベントです。例年開催されており、今年は 2024 年 12 月 22 日 (日) に大田区産業プラザ PiO にて行われます。

イベントでは多くのプロポーザルの中から採択されたセッションや、スポンサーブースを始めとした様々な出展が行われます。去年に引き続き、コロプラはシルバースポンサーとして協賛させていただくこととなりました！

登壇内容について

プロポーザルを採択いただき、今年も Platform Engineer の工藤が登壇させていただけることとなりました。今回は「怖くない！ゼロから始めるPHP ソースコードコンパイル入門」というタイトルで登壇させていただきます。

fortee.jp

本登壇では PHP をソースコードからビルドする具体的な方法の解説のほか、それによって得られるメリットなどについてお話させていただきます。バグ報告や PHP のデバッグを行う際にも有用な情報となる予定ですので、ぜひ聞きに来ていただけると嬉しいです！

おわりに

PHP Conference Japan は年々盛り上がりを増しつつありますが、参加のハードルは非常に低く保たれている初心者にも優しい技術イベントの一つです。勉強会やカンファレンスは行ったことないけど、 PHP は使っている...という人にこそ、是非とも参加いただきたいと思っております。

参加費は無料で、以下の connpass から事前に参加登録が可能です。イベント後には懇親会も予定されているので、ぜひご参加いただければと思います！

phpcon.connpass.com

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびXで情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

マルチプレイヤーゲームのバックエンドを学べる！｜コロプラ3daysインターンを実施しました

2024-09-03T11:00:00+09:00

こんにちは！バックエンドエンジニアの阿部です。

2024年8月5日〜7日にマルチプレイゲームのリアルタイム技術について知ろう！というタイトルでサーバーサイドエンジニア3daysインターンシップを開催しました。

実施内容

さて、皆様は複数人が参加する形式のゲームで遊んだことはあるでしょうか？

昨今のビデオゲームでは、シューティングゲームやスポーツゲーム、ボードゲームまで様々な形式のゲームがオンラインでリアルタイムに遊ぶことができます。

今回のインターンシップでは、そのようなゲームを遊ぶ上で重要な専用ゲームサーバーについて、その役割の１つである「同期」をテーマにTPS用専用ゲームサーバーの設計から実装までを3日間で行いました。

「同期」と一言で表すと簡単そうに思えます。しかし実際に作ってみると思わぬ落とし穴があったり、普段の REST API 開発とは勝手が違う部分があるために思った以上に苦戦することが多いです。「ステートフルなサーバーならではの双方向の通信」、また、「同期をとるために必要なデータの選定方法」などを課題を通して体験できる形式を採りました。

参加者の方には2人1組のチームで課題に取り組んでいただきました。

講義編:マルチプレイヤーゲームの仕組みとコロプラの専用ゲームサーバー

初日の午前中は課題に取り組む上で必要になる知識を得てもらうため座学を行いました。

オンラインで複数のデバイスが接続して遊ぶゲームは1人向けのゲームとは異なり、それぞれのデバイスが状態を持つためその同期が重要になります。その同期をとるためになぜRESTではなく専用ゲームサーバーなのか、RESTとの役割の違いについて、また、コロプラがこれまで開発してきたマルチプレイヤーゲームを例に、実際にどのような技術を用いてマルチプレイヤーゲームが開発されてきたか、そのときどきでなぜその技術を選択してきたかについても紹介しました。

設計編:リアルタイム通信の設計とクライアントサーバー間のプロトコルの工夫

オンラインゲームを開発していく上で、そのクライアントと専用ゲームサーバーがどのように情報をやりとりするか、受け取った情報をどのように処理するかを設計しておくことは非常に重要です。これにより、実装の分担や手戻りの防止ができ、工数の削減につながります。

ゲームを開始する際に発生するクライアントそれぞれが動作する環境によるズレの待ち合わせや、ゲーム中に発生する様々なイベントについてのアプリケーションプロトコルを設計する課題に取り組み、発表しました。

お題としては正常系を想定して出題しましたが、取り組みの中で途中で切断した場合などの異常系を考慮してくれる方もいて素晴らしいと感じました。

実装編:専用ゲームサーバーの構築とリアルタイム処理の実装体験

2日目の午後からは実装に移りました。

設計編で解答例として用意したアプリケーションプロトコルを元に実装済みのクライアントと連携する専用ゲームサーバーの実装をしました。内製サーバーエンジン”prizm”（COLOPL Tech 勉強会「ゲーム開発におけるリアルタイム通信基盤とKubernetes/Agones」を実施しました！）を用いて実装し、実装をテストやクライアントアプリから確認することで、参加、開始、インゲーム処理、アイテム処理、と課題を追う毎にゲームが完成していくのを体験していただきました。

専用ゲームサーバーはステートフルなのでRESTとは違った特性に初めは戸惑う場面もありましたが、段々とコツを掴んで取り組まれていました。

チャレンジ編:運用に向けた課題への取り組み

3日目の午後には実装編の延長や、クラウド上で展開する際の課題、チート対策についての考察など、各チームで好きな課題に挑戦しました。

どの課題も限られた時間の中で取り組むのは難しいものでしたが、実際に扱われている仕組みに近い部分まで考察されていたり、UXまで考えて実装されていたり、予想を上回る成果物が上げられていて驚かされました。

参加した学生からの感想紹介

「第一にすごく楽しかったです！Go言語の経験が少ないので、最初は非常に不安でしたが、そのような状態からでもかけるように準備されていました。実際に全てのチームがアプリ完成まで終わって、追加の実装まで進んでいました。今回のインターンでは、APIサーバとゲームサーバの違いや、ゲームサーバを使ったバックエンドの実装を理解することが出来ました。」

「リアルタイム通信という自分がこれまでに触れたことの無い技術での開発経験を積むことができ、自身の成長に繋がったと感じました。」

「リアルタイムゲームサーバーの設計と実装を経験できました。様々な方法で機能を設計することができると知り、チームによって色が出たと思います。」

「サーバーサイドのゲームの開発について実際体験することが出来てよかったです！」

最後に

これまでバックエンドのインターンで扱ってきた課題は「RESTやDBを用いて大規模・高負荷なアクセスを如何に捌くか」を体験するようなものでしたが、今回は「ユーザーさまに対してリアルタイムで快適なマルチプレイを届けるために必要な技術」にフォーカスしたものになりました。

このようにコロプラでは様々な技術を駆使してユーザーさまに新しい体験を届けたいと考えています。同じ思いの方がいらっしゃいましたらぜひ一緒に働けたらと思います。ご応募お待ちしております。

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびXで情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

初めての海外出張に行ってきました！【Google Cloud Next ‘24 in Las Vegas】

2024-07-29T11:00:00+09:00

はじめに

こんにちは。バックエンドエンジニアの Y.N. です。

普段は LCE チームの一員として新作開発のお手伝いなどをしています。
（→ LCE については過去の記事があるのでそちらもぜひご覧ください）

最近はブロックチェーンゲーム Brilliantcrypto のリリースへ向けてバタバタしていましたが、無事リリースを迎えることができました。PC の方は、ぜひこの記事を読みながらダウンロードして遊んでみてください！

そんな私ですが、先日入社して初めての海外出張へ行く機会があったので、今回はその様子について共有させていただきます。

出張について

今回の出張は、コロプラが主に利用しているインフラ基盤である Google Cloud が主催するカンファレンス「Cloud Next ‘24」に参加し、最新の動向をキャッチアップすることが目的でした。

Cloud Next ‘24 はアメリカのラスベガスで開催され、コロプラからは私を含めて二人で現地参加する運びとなりました。「海外出張でアメリカに行く」というワードを使う日が来るとは想像しておらず、内心不安もありましたが、日本とは違った空気感が味わえるのかなといった期待もありました。

準備編

出張に行くことが決まると、それに向けていくつか準備を進める必要があります。

初めての海外出張でわからないことがたくさんありましたが、会社の手厚いサポートのおかげで手続きなどに困ることはほとんどありませんでした。バックオフィスの方々に参加するイベントの情報や出発・到着予定時刻などを伝えると、それに基づいて飛行機やホテルの予約、Wifi の手配、社内の稟議申請などたくさんのことを対応してもらえました。サポートしてくださった皆様にとても感謝しています。

また、事務的な手続きとは別に、アメリカに着いてからの行動を事前に計画しておく必要もありました。特にカンファレンスでの立ち回り方については、相談の場を設けて二人で検討し、なるべく個人が別々のセッションに参加することで、情報を広く取り入れられるようにスケジュールを組みました。Cloud Next では事前に Web やアプリからセッションの予約ができるようになっていたので、それぞれのセッションの参加予約をして当日に備えました。

渡航編

今回の全体的な出張スケジュールは以下の通りです。

日付	時刻	場所	行動
4/8（月）	17:00	Tokyo	成田国際空港発
4/8（月）	15:00	Las Vegas	ハリー・リード国際空港到着
4/9（火）	終日	Mandalay Bay	Google Cloud Next ‘24
4/10（水）	終日	Mandalay Bay	Google Cloud Next ‘24
4/11（木）	終日	Mandalay Bay	Google Cloud Next ‘24
4/12（金）	07:00	Las Vegas	ハリー・リード国際空港発
4/13（土）	17:00	Tokyo	成田国際空港到着

イベント前日の夕方にホテルに到着し、三日間のイベントに参加、次の日の早朝の飛行機で帰国しました。東京を出発してラスベガスに到着したら時間が巻き戻っているのですから、不思議な感覚を覚えますね。

ラスベガスにはサンフランシスコを経由して向かったのですが、途中の乗り換え待ちの間、すでに周りには Google Cloud Certified のワッペンがついたリュックを持っている人々が散見され、「プロがたくさん集うイベントなんだなぁ」と改めて感じました。

ラスベガス到着後、空港からホテルまではタクシーで移動しました。タクシーの運転手さんが移動中にトランシーバーでずっと友人らしき人と会話していた様子が「日本ではあまり見ない光景だなぁ」と思って日米の違いを感じたことを覚えています。

今回宿泊したのは、Excalibur Hotel & Casino というカラフルなお城のような見た目が特徴的なホテルでした。受付カウンターの前にはカジノスペースが広がっており、スロットの光と騒音に囲まれた時にラスベガスに来たことを実感しました。

Cloud Next ‘24

次の日からいよいよ Cloud Next ‘24 が始まりました。

会場は金色の建物が印象的なマンダレイ・ベイという施設でした。

建物内には Google らしいカラーの装飾が至る所に施されていて、イベントへの期待感が高まっていきました。

大きなキーノートホールの一角に着席して待つこと数分、ポップな音楽とともに基調講演が始まり、会場が沸き立ちます。Google Cloud CEO のトーマス・クリアン氏をはじめとして、登壇者の方々が堂々と発表している姿を見ると、内容どうこう以前に「すごい仕事をしているなぁ」とそのスケールに圧倒されてしまいました。普段はモニター越しに見ている光景が目の前で起こっているのを見ると、それだけで刺激になりますね。

今回の Cloud Next ‘24 の主な話題はやはり AI でした。新たに Google のフラッグシップモデルの Gemini 1.5 Pro というマルチモーダルのモデルが発表され、Google Cloud の他の様々なプロダクトでも AI 技術をベースとした機能追加が多数発表されました。

個人的には、AI アプリを自然言語で作成する Vertex AI Agent Builder という機能がとても印象的でした。AI というとエンジニアが手作業で細かいパラメータチューニングを頑張る姿を連想してしまうので、1つ良いモデルが出来上がるとそのモデルに自然言語で依頼するだけで望んだ出力が得られるという時代が来ていることに驚きました。

Expo エリアでは多くの企業がブースを出展し、その場で説明や実演を行っていました。特に印象に残ったのは、サッカーの PK を評価し、AI コーチからアドバイスを受けられるブースでした。実際に試してみると、私のスコアは80点の評価をいただきました。個人的には悪くないスコアだなと思いましたが、AI コーチからは「蹴る力が強くなるとより良くなる」とアドバイスをいただいたので、頑張って脚を鍛えようと思いました。

さらに、コロプラが利用しているプロダクトのチームとのミーティングの機会もありました。名刺交換などもさせていただき、少し緊張する場面ではありましたが、気さくに話しかけてもらえたおかげで緊張もほぐれました。日本からもリモートでメンバーが参加してくださり、短い時間でしたが有意義なミーティングになりました。

そのほか、イベント期間中は連日交流会が開催されていたのでそちらに参加し、「（当時まだ日本未発売だった）Apple Vision Pro を試しに来た」や、「英語学習の苦労話」などなどいろいろなお話を聞かせていただきながら楽しい時間を過ごすことができました。交流してくださった皆様どうもありがとうございました。

全てのイベントが終了した後は、少しだけラスベガスを観光しました。3,400億円かけて建設された全面 LED のアリーナである Sphere を見に行くと、ここでも Google Cloud のロゴマークが表示され、その圧倒的なスケールに度肝を抜かれました。

感想

イベント全体を通して、話題は常に生成 AI が中心のように感じました。あまり AI 技術に触れていない自分にとって、漠然とした危機感を覚えるような感覚もありましたが、AI をうまく活用する事例も見れたのでよかったです。イベントでは500以上のセッションが開催されていたらしく、到底全て回り切れるものではありませんでしたが、各社の AI の活用事例や様々なチャレンジについての話を聞いていると、とても良い刺激をもらえました。この経験を糧に、自分でも周りに自信を持って話せる仕事をしていきたいと感じました。

最後に、アメリカの物価は高いですね。イベント期間中はなんだかんだ食事が提供されたので助かりましたが、そうでなかったらと考えると結構ゾッとします。

後日談

海外出張を終えて、社内では「Cloud Next '24 参加レポート」と題して勉強会を実施しました。様々なセッションを聴いて気になった話題や注目機能、行ってきた感想などについての発表を行いました。

実際に Gemini 1.5 Pro を使ったデモなどを発表に組み込んでみたところ、好評のコメントをいただくことができたので、発表に組み込んでみてよかったなと思います。

イベント参加時の注意点

今回 Cloud Next ‘24 に参加してみて、海外出張で大規模カンファレンスに参加する際の失敗ポイントもいくつか発見したので、参考にしてみてください。

◆ セッションの予約システムがある場合は、できるだけ早く予約する

人気のセッションはすぐに満席になる可能性が非常に高いです。せっかく現地に行くのであれば、聴きたいセッションを逃すのは勿体無いので、早めに予約を済ませてしまいましょう。

◆ 基調講演などの巨大ホールで行われるセッションだとしても早めに会場に着くようにする

自分の周りでキーノート会場に入れなかったという声をちらほら聞きました。現地にいるのにモニター越しになってしまうと悲しいので、会場が広い場合も油断せず、早めに会場入りするのが良さそうです。

◆ イベント中はセッション以外にも Expo など他の展示もあることを念頭に置いてスケジュールを決める

予約システムがあると予定を詰めてしまいがちですが、企業ブースの展示も充実しているイベントはそちらを見て回る時間も確保しておけると良いと思いました。

まとめ

今回は初めての海外出張で Cloud Next ‘24 に参加して感じたことや、注意点などについて紹介させていただきました。

今回のイベントのように大規模なカンファレンスは参加するだけでも大きなモチベーションアップに繋がるので、開催場所が海外でもチャンスがあればぜひ参加してみることをおすすめします！この記事がその背中を押す一助になれば幸いです。

最後に、そんな海外出張のチャンスが眠っているコロプラでは、一緒にチャレンジングな仕事をする仲間を募集中です！

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびXで情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

Go Conference 2024 スポンサー協賛のお知らせ

2024-05-09T11:00:00+09:00

こんにちは！バックエンドエンジニアの松永です。サーバー基盤グループのRTPE（Real-Time Platform Engineering）チームに所属し、リアルタイム通信に関わる基盤の開発や各タイトルの開発支援を行っています。

今回、2024年6月8日（土）に開催される Go Conference 2024 にコロプラは Bronze スポンサーとして協賛することが決まりました。そこでこの記事では、 Go Conference 2024 の概要と、コロプラにおける Go の活用について紹介したいと思います。

Go Conference について

Go Conference とは、年に一度開催される Go に関するカンファレンスです。今年は数年ぶりのオフライン開催で、テーマは「一期一会」。オフラインならではのセッションやイベントが企画されているようです。現時点ではまだ企画の詳細は公表されていませんが、順次アナウンスがあるはずなので、最新の情報は公式サイトやXの公式アカウントを確認してみてください。

コロプラにおける Go の活用

コロプラでは Go を活用する場面が増えてきています。その一つが、リアルタイム通信に関わる開発です。

例えば、対戦プレイや協力プレイのようなオンラインマルチプレイを実現するためのゲームサーバーでは、多数のプレイヤーがリアルタイムにゲームサーバーを介してデータをやり取りする必要があります。 Go では並行処理を簡潔に記述できるため、同時に大量のデータを処理するようなゲームサーバーの開発に適しています。また、コンパイル言語ならではの高速な実行速度も、リアルタイム通信を実現する上で大きな利点となります。

また、 Kubernetes のようなインフラや、 Agones や Open Match といった Gaming OSS でも Go が採用されており、コロプラが利用しているこれらのプロダクトとの相性の良さも Go を選ぶ理由の一つになっています。

コロプラのリアルタイム通信基盤や、 Agones や Open Match といった Gaming OSS の利用に興味のある方は、以下の記事も読んでみてください！

今後の Go に関する発信について

今回の Go Conference 2024 には弊チームのメンバーがプロポーザルを提出したのですが、残念ながら採択までには至りませんでした。プロポーザルで提案した内容は今後勉強会や技術ブログを通じて紹介する予定です。コロプラでは今後も Go に関する情報を積極的に発信していきたいと考えています。

おわりに

Go Conference 2024 は、初心者からベテランまで Go を使う全ての人が楽しめるカンファレンスです。参加費は無料で、connpassの申込みページから参加登録が行えるのですが、オフライン参加枠は受付開始早々に上限に達してしまいました。キャンセル待ちができるので、少しでも興味のある方は是非参加を検討してみてください！

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびXで情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

コロプラにバックエンドエンジニアとして入社しました

2024-04-01T11:00:00+09:00

こんにちは！コロプラのバックエンドエンジニアの大宮です。
現在とあるゲームタイトルのバックエンドエンジニアとして仕事をしています。入社して3ヶ月が経とうとしている今、入社エントリーとして、転職活動をしていた当時や、入社してからのコロプラでの経験を振り返り、ゲーム業界未経験のエンジニア目線で感じたことを今回お伝えできればと思っています。

自己紹介

前職は8年程同じ会社でWebシステム開発とAndroidアプリケーションの開発をしていまして、ゲーム開発の経験は全くありませんでした。
Web開発の領域としてはフロントエンド、バックエンド、そしてインフラも触りながら幅広く開発していました。触っていたフレームワークやライブラリも様々で、

バックエンド：SpringFrameworkやLaravel
フロントエンド：Reactメイン
インフラ：AWS

を使って開発することが多かったです。PJによって開発言語から違うことが多かったので、結果的に幅広く経験を積むことができました。

なぜコロプラに転職したか

転職を決意した一番大きな理由は、エンジニアとしてステップアップしたいなと思ったことです。転職することでより多くの刺激を受けて、技術者として成長できればいいなと思いました。
転職活動を始めた頃は転職の軸として「自分のスキルが活かせるか」「成長できそうか」という観点で会社を探していました。

特に業界にこだわりなく活動していましたが、最終的に入社を決めたきっかけは、面接や面談でゲームと技術の話ができたことです。元々ゲームは好きで、ゲームがどんな仕組みで作られているのか、どういった考えでゲーム作りをしていくのかを技術的な面も交えて話ができて一気に興味を持ちました。好きなゲームの質問から始まり、そのゲームのどんなところが好きか、それを実現するには技術的にどういう方法が取れるかを、ディスカッションする形でDB設計の話や通信プロトコルの話をしたのを覚えています。

入社してみて

入社前のコロプラの印象

コロプラという会社について、多くの方がそうだと思うのですが「有名なスマホゲームを開発している会社」という印象が強かったです。特に白猫プロジェクトは自分もプレイしていて、周りの人も結構知っているタイトルでした。
それ以外の印象だと技術ブログなどの記事や動画をみて、技術的な挑戦をたくさんしている会社だなと思ってました。

入社後の印象

仕事をしやすい環境が整っているなというのが第一印象でした。
知見、知識がまとまっていてタイトルを跨いで簡単にアクセスできるのは驚きました。「このタイトルではこの技術をこういう理由で使っています。使い方はこんな感じです。」といった情報がまとまっていてサクッと検索できます。
加えて技術的なトピックについてSlack等で積極的に議論されているなという印象がありますし、書籍も社内のクマ図書館に揃っていて借りられたりします。技術力アップにとてもいい環境だなと思います。

前職とここが違う

良い意味でサーバーエンジニアの業務の範囲を越えてプロジェクトに貢献できます。サーバーエンジニアとしてのタスクをこなしつつ、UIや仕様に対しても色々と意見を言える雰囲気なので、ゲーム作りのプロセスに強く関わっているなという実感があります。

いいと思ったところ

人間関係の面では周りのメンバーはゲーム開発未経験であることを理解して接してくれるので、とてもやりやすいです。
技術的な面では興味のある事柄について情報収集しやすいところがとてもいいなと思います。Slack上にカテゴリ毎に発信するチャンネルが作られていて、面白いサービスが共有されていたり、それを使ってみた結果を載せていたり個人個人がアウトプットしています。自分はよくAIのチャンネルとPHPのチャンネルを目的もなく覗いています。技術書も色々揃っていて借りられる環境がある所も嬉しいです！！

これからについて

ひとまずは業務に慣れることが目標ですが、技術が好きなので将来的にはテックリードを目指していきたいです。
施策の開発担当をこなしつつ、ゲーム業界以外の経験を活かしていけたらなと思っています。

ColoplTechについて

コロプラでは、勉強会やブログを通じてエンジニアの方々に役立つ技術や取り組みを幅広く発信していきます。
connpassおよびX（Twitter）で情報発信していますので、是非メンバー登録とフォローをよろしくお願いいたします。

twitter.com

バックエンドエンジニアの社内LT会を開催しました

2024-01-11T11:00:00+09:00

こんにちは！コロプラのバックエンドエンジニアの山田です。

コロプラでは、社内・社外問わずコミュニケーションや情報共有の強化の一貫として勉強会やLT会を継続して開催しています。

様々なチームが不定期でLT会を開催しており、バックエンドエンジニアを包括する技術基盤本部という大きな組織単位でもLT会を開催しております。

前回開催した際の記事も公開しているので、是非ご覧ください。

LT会のトーク内容

LTの内容は大きくは2つに分けて人数半々で募集しました。

テック・真面目系
エンタメ・ネタ枠

すべてが「テック・真面目系」だと堅苦しく発表・参加ハードルが上がってしまうため「エンタメ・ネタ枠」も用意しています。

1.「Incremental game を布教する」

登壇者　T.U. さん

Cookie Clicker などを代表するいわゆる「放置ゲーム」の歴史とおすすめのゲームの紹介です。

Wikipedia によると 2002 に出た Progress Quest が始まりとされていたりと、案外知らないことが多くて興味深い内容でした。

en.wikipedia.org

2.「モンユニローカライズ裏話」

登壇者　Kevin さん

コロプラがリリースしているゲームの MONSTER UNIVERSE の英語へのローカライズ対応の話になります。

マスターデータやUIなどあらゆる箇所の翻訳が必要になり、単純に英訳するだけでは不適切な場合など様々な課題がでてきますが、それらの課題に対してどう向き合って進めてきたのかをお話されました。

英訳すると長くなりUIに入り切らない場合は、短くしても伝わる言葉に変える
漢字一文字の表現は無理に翻訳せずアイコンにしてしまう
細かいニュアンスの違いなどは ChatGPT に頼る

3.「PHP 予想外シリーズ」

登壇者　尾山貴康さん

PHPのコードで予想外な挙動になるコードをいくつか紹介されています。
普段は書かないであろうコードもありますが、もし書いてしまうとハマりそうな全く予想外の挙動もあって面白い内容でした。

詳しい内容はまた別の記事にて公開したいと思っています。

4.「無料で始めるAI画像生成」

登壇者　山田和毅（私です）

Google Colab を使って無料で Statble Diffusion を始めるという内容です。自宅で個人的に画像生成を色々と試していて、なかなか面白かったのでLTしてみました。
なお、最近はこの用途で使うと警告が出るので今なら課金必須です。

簡単な始め方から、Statable Diffusion Web UI の使い方、プロンプトのコツ、Bing Image Creator などとの比較について話しました。

5.「メンズメイクの始め方」

登壇者　喜田祐介さん

エンタメ枠としてメンズメイクについて初心者向けのおすすめ商品などを紹介されていました。
手軽に始めるならunoやダイソーなどで安く揃えられるようで、私はこのあたりに全然疎くて調べもしない範囲なのでLT会としてはとても良い発表でした。

6. 業務メモのとり方ベストプラクティス

登壇者　西川蒼太郎さん

「業務メモは他人と共有するもの」という考えのもと、様々なメモアプリを試した発表者が Slack のメモアプリとしての素晴らしさや活用方法を紹介しています。

コロプラでは Confluence などの情報共有ツールをいくつか使用していますが、この発表で話されていた「やらないコンフルよりやるSlack」というフレーズはまさにそうだなと思いました。

メモがそのままドキュメントになる

引き継ぎする際はリンクを渡すだけ
何かで困った方がSlackで検索した際に解決の足がかりになる

メモがそのまま進捗共有になる
メモがそのまま質問掲示板になる

通りすがりの有識者が見てアドバイスをくれる

7. 「SMBC の Olive はおトクだから申し込んだらいいと思うよの話」

登壇者　工藤剛さん

SMBCのOliveを使った際の様々なメリットと、始める場合の注意点、クレカ投資 (積立 NISA 含) 、有効な活用方法について話されていました。

三井住友・三菱UFJ の ATM の時間外手数料無料

同行宛だけじゃなく他行あても振込手数料無料
翌月に受けられる特典を 2 つまで (一部重複可) 選べる

コンビニ ATM 手数料無料 (重複可)
V ポイントアッププログラム +1% 還元 (重複可)
ご利用特典 100pt (重複可)
給与受取特典 200pt

これを機に私も Olive 始めました(笑)

終わりに

真面目系からエンタメ枠まで様々な発表があり、自分が普段調べない範囲をさらっと学べてとても良い機会でした。

コロプラでは社内LT会を継続的に開催していますので、次回の記事もお楽しみにお待ち下さい！

ColoplTechについて

ロードバランサー
https://cloud.google.com/load-balancing/docs/application-load-balancer?hl=ja

twitter.com

MIGによるサーバー費用削減：エンジニアによる実践記

2023-12-13T07:00:00+09:00

都内某日、在宅勤務でとあるゲームの運用を行っていた男は
プロジェクトマネージャーから打診を受ける。
　M「サーバー費用はこんなにかかるものなのですか？」

他のプロジェクトと比較してみても、そこまで目立って多いわけではない
ある意味では適正である。
スペックの見直しをしてどのくらい費用が抑えられるのか ─────

その後、男はある疑問を抱えることになる。
「夜間のサーバー維持費はもっと抑えることができるのではないか？」

男は名を田中という、コロプラのバックエンドエンジニアである。

〜プロジェクト MIG〜
　　お急ぎの方は、記事の最後に対応まとめを記載しておりますので、そちらをご覧ください

目標と課題

時は少し遡り
マネージャーからの打診を受けた日、田中は売り上げとサーバー維持費の比率を眺めていた。
　田中「意外と日々の売り上げに対してサーバーの維持費は結構かかってるなぁ」

マネージャーから打診を受けたのち、田中はサーバーのスペックダウンをインフラチームに検討依頼した。
　インフラ「1段階スペック下げても運用上問題ないですね」
　田中「それでは下げて運用しましょう」
とんとん拍子に事は進み、APサーバーのスペックを下げ、当然費用も多少は削減した。

ただ、プロジェクトとしてスペックダウンだけの費用削減効果は
マネージャーが期待していたものよりも少なかった────

もっと費用を下げれないものか、、、頭を抱える田中は様々なデータを確認する
ユーザーリクエストを眺めていた。

16時台がピークになっていて、20時台にも少し上がるいつも通りのグラフだ。
ピークを超え0時付近を境にリクエストは減っていく。
・・・当然だ、ほとんどのユーザーは就寝している。

ふとこの時、日々のタスクの中でサーバーの台数調整は
1日に1回しか行っていないことが引っかかった。
日毎に、16時台のピークを予想して台数を変更しているが
それ以外の時間帯に合わせて台数調整はしていない。

　田中「夜間のサーバー維持費はもっと抑えることができるのではないか？」

もし、0時過ぎた段階で台数を下げ
リクエストが増加してくる前の6時台に台数を元に戻せば、その間の維持費が削減できる。

希望が、見えた ─────

しかし、実際に運用を行おうとすると大きな壁があった。
　ー当然のことながら深夜・早朝に手動で台数調整を行うことは考えられない
　ーそこで、行うとしたらcronにて自動で台数調整を行うことが思い浮かぶのだが
　　　自動で行っている作業にエラーが発生した時どうするのか
　ー深夜・早朝に見守ることになると結局手動で調整するのとほぼ変わらないことになる
どうにもこの方法は絵空事のようだ。

持て余した田中はインフラチームに相談することにする。

　田中「APサーバーの台数を深夜帯（時間はまだ未確定）で削減できないか検討しているのですが
　　　自動でAPサーバーの台数を増減することは可能でしょうか？」
　インフラ「現在利用しているシステムに、カレンダーに登録した時間で
　　　台数を調整する自社製スクリプト[semi-autoscale] がありますので利用できるかもしれません
　　　調査に1ヶ月ほどかかってしまうのでお待ちいただけますか？」

なるほど、そんな便利な機能があるのか！
実現性を帯びた返答に、田中は一も二もなく導入することをお願いした。

1ヶ月後、インフラから返答が届く─────

　インフラ「semi-autoscale では台数を全て決めておかなければならないのに対し、
　　　gcp の managed instance group（MIG）の autoscaling が利用できるかもしれないので
　　　調査していました」

田中は驚愕する。台数に関しては台数指定をするタイミングを設ける必要があるため
ある程度余剰が生じても仕方がないと考えていたからだ。
それが、余剰が極力発生しない形で管理できるとは、、、

→

サーバー台数変動想像図

さらに説明は続く
インフラ「ただし、デプロイ方法が変更になってしまいます
　　新しい方式では、新たにサーバーを作成し本番反映した後に
　　旧サーバーを抜いていくことになり、旧サーバーは全て削除されてしまいます」

ここで従来のデプロイ方法を説明しておく必要がある。

例えば10台サーバーが稼働し、ゲームを運用しているとする。
追加で作成したり、修正したプログラムを稼働しているサーバーに反映するときには

まず2台のサーバーを「ユーザーからアクセスできる環境」から切り離し、
プログラムファイルを更新、再び「ユーザーからアクセスできる環境」に戻す。
この工程を繰り返し、全ての台数分ファイルの更新が完了すれば完了となる。
この方法だと、使用しているサーバー自体は変わらないことになる。

これに対し、新たなデプロイだと
先に新たなサーバーを用意しておき、「ユーザーからアクセスできる環境」に追加した後で
旧サーバーを削除することになる。

この方法だとサーバー自体が新たなものに置き換わってしまう。
新たなデプロイ方法で問題となるのは
　・旧サーバーに保存されているログが削除されてしまうこと
　・それぞれのサーバのキャッシュデータが取り直しになり
　　　一時的に負荷が上がってしまうこと
などが考えられた。
それら全て対応しても費用削減の効果は大きそうだ。

　田中「費用削減効果の方が大きそうなので、その方法で運用を目指しましょう」

インフラと協力し合い、それぞれの問題に対する対応策を考えた。

まず、ログに関して2つの問題への対応である。

1つ目は、アクセスログ・実行ログ・エラーログなど通常確認は行わないが調査などに使用することがあるログの類を避難させること。

　これはサーバーを削除する前にインフラ側でファイルを取得し、GCS(Google Cloud Storage)に保存することで事なきを得た。
ただし、調査の際にはアクセス権限を持っているインフラにデータ取得をお願いすることとなった。

2つ目は、普段確認するエラーログの監視方法の修正。

　展開時だけでなく、MIGがautoscalingを行うタイミング（自動で行われるためタイミングをはかることはできない）でサーバーが切り替わってしまうため、
既存では運用を行っている特定サーバーのエラーログを取得していたロジックを変更し、
エラーログを取得するタイミングで毎回稼働サーバーを検出することで対応する事にした。

次に、キャッシュデータに対しての対応だが

　元々、MIGは急激なアクセス過多に対しては対応しきれないところがあるため
アクセスが集中する時間帯の前に予め台数を増やすスケジュールを組み急激に台数変動が起こらないように予防しておく想定だった。
これに伴い、キャッシュデータに関してはピーク時点で既に作成されているため問題ないという結論に至った。

ちなみにMIGのスケジュール設定では、サーバーの下限台数とその開始時間、継続時間が設定できるようになっている。
例えば普段5,6台で運用しているところ、16時のピークに合わせ台数を36台まで増台しておき、その状態を1時間継続するといった具合だ。

導入と不具合

考えつく問題点を取り除きリリースして問題ないと思われる段階まで進んだ。

2023年1月某日　いよいよMIGを利用しての運用を開始する日が来た。

インフラと連携して作業を行う。
まず、サービスインしていない環境で問題なくデプロイできていることを確認
　そして本番へ─────

ここでデプロイ時に30分程時間がかかることが発覚する。
普段10分程で完了することを考えると3倍かかっていることになる。
不具合が発生した時にすぐに修正ができないのは問題があるため今後の改修課題となった。

それ以外は順調に新たなデプロイでサーバーを追加していく、、
動作している、大丈夫そうだ　そう思った時、、、不具合が発生した。

一部のサーバーにアクセスが集中したらしく、集中したアクセスによりサーバーが落ちる。
落ちたサーバーに割り振られていたアクセスが他のサーバーに再度振り分けられ
他のサーバーにも飛び火していく。

すぐさまサーバー台数を増やし、負荷分散を行い事態の収拾をはかる。
程なくして、負荷が正しく分散され正常に戻っていく。

この時点では原因がわからず、たまたま運悪く調子の悪いサーバーを掴んでしまい
問題が発生したと思っていたが、
2回目にデプロイを行った時にも同様の問題が発生してしまった。
（2回目の際はサーバーダウンが起こる前に台数を増やして事無きを得た）

毎回デプロイを行うと不具合が発生するため、一度MIGでの運用を取りやめ
既存の方法で運用を行うこととなった。

ひとまず直面したサーバー停止の不具合は収束したのだが
重要な課題が残されてしまう形となった。

原因の特定と解決

翌日、調査を行い
一部のサーバーで負荷が上がり、アクセスを処理できなくなったサーバーが停止、再起動を行っている間に
稼働している別のサーバーへアクセスが集中し、また停止するというように
連鎖的にサービスアウトとサービスインを繰り返すようになっていたことが発覚したのだが

インフラでもなぜそのような動作になるのか調べても肝心の理由がわからず
Googleへの問い合わせを行うことになった。

ただ今回の問題に関してはサーバー1台あたりのリクエスト上限を上げる事により解消できるとの提案も受け
このタイミングで再度MIGの運用に切り替えることも検討したが、安全に運用を行うことを重視し、デプロイ時間の短縮を優先し一時見送る事にした。

デプロイ時間の短縮が完了した連絡を受け、2023年3月末頃
再度、本番反映が行われる運びとなる。
デプロイ時間の短縮も行われており、前回よりスムーズに作業が進む。
特に前回のような問題も起こらず、既存のサーバーからMIGサーバーへの移管が行われる。

───── 問題、ないのか？ ─────

今回問題がないのであれば、前回起こった不具合は何が原因だったんだ
そんな疑問を抱きながら、作業は完了を迎える。

結局、特に問題も起こらず導入が完了する。
必要に応じてサーバー台数が増減し、適切な台数に保たれる様をグラフで確認できるようになると、感慨深いものがある。

その後1,2日ほどMIGの最大/最小台数の設定や、適切なスケジュール設定などの
詳細なカスタマイズを行いながら通常運用を行っていく。

このまま何もなく過ごせると思っていた矢先─────

　インフラ
　　「12:00 から何か施策やっていましたか？」

突如寄せられた質問と一緒に、サーバー負荷をグラフ化したスクショが送られてくる。この時、特に大きな施策は行っておらず
　変更があったのはMIGを利用してのサーバー自動増加ぐらいのものだった。

サーバー台数がMIGによって自動で増加され、大きな問題に繋がることなく
　負荷は収まっていったのだが、原因を突き止めるべく議論は続く。

　ーdbへの負荷が12:00過ぎに上がっている
　ーサーバー台数が増えてキャッシュに保存前に
　　　リクエストがきて詰まっていったのではないか
　ー詰まった状態でMIGが自動で台数増やして
　　　さらにキャッシュ保存前のサーバーが増えているのではないか
　ーとすると、増台したサーバーへは
　　　リクエストの振り分けを通常よりも少なめにすれば良いのでは

インフラ
　「リクエストをコントロールできるか週明け調べてみます」

この日は土曜でアラートの収束と今後の方針が決定したことで解散となった。
すぐさま意見交換や合意形成が行え、調査検証に移れることがこの会社の強みだなとひしひしと感じる。

しかし、調査を行う前に幾度かアラートが発生することになった。
MIGが自動的に台数を上げて負荷を下げてくれるため致命傷とまでは行かないまでも、
このまま運用を続けていくのには不安になる。

1週間ほどの間に、何度かアラートが届く状態が続いたところで
どうやら台数を増やしているタイミングではなく、減らしているタイミングで負荷が増大していることに気づく。
原因の特定には未だ至らないが、リクエストの分散を行っているロードバランサーの部分で何やら問題がありそうなことがわかってきた。
Googleへの問い合わせを行うことで何かわかりそうだ。

2日後、インフラから連絡が届く。

インフラ「先ほど先方から回答が届いたのですが、
　　　　　サーバー台数が急に変更される際、均等に配分されるのに２−３分かかるそうで
　　　　　増台/減台関わらず再振り分けが行われるみたいです」

なんと
　リクエスト分配は増台/減台共に時間経過しないと正常に動作しないことがわかった。
増台時に割り振りが偏ることは想像できたのだが、減台するときは均等分配されているものを均等に削除していくものだと思っていたため想定外だった。

長い間わからなかった、リクエストが偏ってしまう謎の原因がようやく特定できたのだった。

本当の導入

原因がわかってしまえば、対処法はすぐに思いついた。
増台を行う際は
　５分以上をかけてスケジュールを分割して目標台数まで上げれば良く、
減台を行う際は
　1度に削除する台数に上限を設け、こちらも数回に分けて削除しておけば良い。

この回答が届いたのが金曜日、即座に対応を行えば週末に間に合う。
スケジュールの見直し、減台数の制御など諸々の設定を無事に行い週末を迎える。

　何も起こらないでくれ─────

結果、減台/増台を繰り返したにもかかわらず、
アラートは発生せず、週末を無事に乗り越えれたのである。

稼働しているサーバー費用の削減をしたい
そんな思いから長い間、取り組んできたMIGの導入がここに完結したのである。
実に構想から10ヶ月程経っての目標達成だった。

あとがき

というわけで、いかがでしたでしょうか？
コロプラバックエンドエンジニア田中でございます。

実際にMIGを導入するにあたって行ったことをまとめると

◆対応まとめ
　・ログが削除されてしまうので、退避方法とエラー確認処理の見直し
　・リクエスト肥大タイミングに向けてのスケジュール調整
　・減台/増台タイミングの分割対応
　・デプロイ処理の変更

といった内容が主になり、
作業的にはインフラ側に対応していただいた作業がメインになるため
今回は運用に至るまでの体験談のように記事を書かせていただきました。

所属プロジェクトでの成果はサーバー費用全体の1割ほどの削減になり、現状でも安定して運用できております。
試行錯誤の大切さ、原因究明の当たりをつけた上で検証/調査を進めていく
他部署との合意形成など、普段行っている業務の一旦を感じ取ってくれたなら幸いです。

MIGを導入以降、日々のサーバー台数調整が無くなった事で他の作業に集中できるようになったり
所属プロジェクトで安定運用ができることがわかった段階で、他のプロジェクトにも続々導入され、結果として複数プロジェクトの費用削減に繋り
自分が想像していたよりも大きな成果が出たのではないかと満足しています。

最後に、エンタメ精神を存分に含んだ文体を公式で掲載していただいた寛大な担当者への感謝と、今回導入させていただいたMIGに関連するリンクをご紹介させていただいて
締めくくりとさせていただきます。
長文、駄文を最後までお読みいただきありがとうございました。

自動スケーリング
https://cloud.google.com/compute/docs/autoscaler?hl=ja#specifications

ColoplTechについて