AI エージェントといっしょに作業することが増えてきました。速くて助かる一方で、ローカルの設定値や検証用トークンが、気づかないうちにコミットに紛れ込むリスクは前より意識するようになりました。

間違ってコミットに含まれてしまうのを避けるため、機密情報はコミット前に機械的に止めるやり方にチャレンジしてみた内容を共有できたらと思っています。今回は、gitleaks を lefthook から pre-commit で実行する構成にしています。

本記事で紹介するのは次の3点です。

• なぜ git-secrets ではなく gitleaks に寄せたのか
• ローカルで止める最小構成
• ローカルで漏れた場合に GitHub Actions でどう拾うか

人の注意に頼る場所を減らして、フローの中で止める形にしてみてます。

gitleaks に寄せた理由

もともとは git-secrets を使っていました。AWS 系の検知が優秀なのですが、それ以外のサービスには標準では対応していません。今回は AWS 以外も最初から広めに見たかったので、gitleaks のデフォルトのルールセットで Stripe のシークレットキーや Slack の Webhook URL、Vercel のアクセストークンなど、100 種類以上のサービス固有のパターンに対応していることから選択してみました。

もうひとつは Windows への導入のしやすさです。チームメンバーで Windows を利用している方も多く、git-secrets だと導入に手こずっている方もいました。gitleaks は Scoop を利用することで導入が簡単にできるので、より良い運用に乗せやすいと判断しました。

ローカルで止める最小構成

以下は gitleaks v8 系を前提にした例です。

まずは gitleaks を入れます。

# macOS
brew install gitleaks

# Windows
scoop install gitleaks

gitleaks version

lefthook はバイナリで入れます。

# macOS
brew install lefthook

# Windows
scoop install lefthook

clone してきたら、一度だけ次のコマンドを実行します。

lefthook install

これはリポジトリごとに一度だけ必要です。.git/hooks/ に hook が書き込まれ、以降は自動で動きます。

全リポジトリにグローバルで適用したい場合は、lefthook を使わず git のグローバル hooks を直接使う方法もあります。

mkdir -p ~/.git-hooks
cat > ~/.git-hooks/pre-commit << 'EOF'
#!/bin/sh
gitleaks git --staged --redact --verbose
EOF
chmod +x ~/.git-hooks/pre-commit
git config --global core.hooksPath ~/.git-hooks

ただし、グローバル設定は自分のマシンにしか効かないため、チームへの展開には向きません。チームで同じルールを共有するなら、リポジトリに lefthook の設定を置く方式のほうが確実です。

lefthook の設定は次のようにしています。

pre-commit:
  commands:
    gitleaks:
      run: gitleaks git --staged --redact --verbose

ここでやりたいのは、コミットの直前に一度ブレーキをかけることです。--redact を付けているのは、検知時の出力に secret をそのまま出さないためです。--verbose は、導入直後に何が起きているか追いやすくするために入れています。

初回導入時にやっておいたこと

pre-commit だけだと、これから入る差分しか止められません。既存の履歴を一度見ておきたいので、初回導入時はリポジトリ全体もスキャンしました。

gitleaks git --redact --verbose

ここで検知が出たら、まずは本物の secret かどうかを確認します。誤検知だけを allowlist に寄せるほうが安全です。

allowlist は狭く書く

gitleaks を使い始めると、サンプル文字列やドキュメントで誤検知が出ることがあります。そこで allowlist を入れますが、ここを雑に広げると後で本物を見逃します。

例えば、ドキュメント配下の EXAMPLE だけを許可するなら、次のように条件を絞って書きます。

title = "team gitleaks config"

[extend]
useDefault = true

[[allowlists]]
description = "allow documented placeholders only in docs"
condition = "AND"
paths = ['''^docs/''']
regexTarget = "match"
regexes = ['''\bEXAMPLE\b''']

「とりあえず docs を全部通す」のような書き方は避けたほうが安心だと考えてます。

CI でもう一度見る

ここでひとつ大事なのは、CI は GitHub に入る前に止める仕組みではない、という点です。push や pull_request で動かす以上、差分はすでに GitHub にはあります。

それでも CI を置く意味はあります。ローカルで拾えなかったものを PR で止めることと、デフォルトブランチに流し込まないことです。

GitHub Actions は次のようにしています。

name: gitleaks

on:
  pull_request:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITLEAKS_CONFIG: .gitleaks.toml
          GITLEAKS_ENABLE_COMMENTS: false
          # Organization リポジトリで使う場合だけ追加
          # GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}

fetch-depth: 0 を入れているのは、履歴を見られる状態にするためです。push を main に絞っているのは、不要な実行を増やしすぎないためです。

検知後にやること

検知して終わりにはしません。もし本物の secret が push 済みなら、回収とローテーションまでやれるようになると良いかなと思っていますが今回は割愛します。

まとめ

AI エージェントで差分が増えるなら、機密情報対策は「気を付ける」だけでは足りないと考えてます。コミット前に止める。漏れたら CI でもう一度見る。その二段にしておくほうが、実際の運用はかなり楽になります。

git-secrets は今でも良いツールです。ただ、今回は AWS 以外も広く見たかったことと、Windows を含めて配りやすくしたかったことから、gitleaks に寄せました。

まずは pre-commit で止めるところから始めて、必要になったら CI と allowlist を育てていく。この順番がいちばん無理なく入れられるんじゃないかなと思います。

ということで、「低レイヤー入門シリーズ」の第二弾はメモリについて深掘りしていきます！

前回の「スタティックリンクとダイナミックリンク」では、プログラムがどのように実行ファイルになるかを学びました。今回は、その実行ファイルが動くときに欠かせないメモリの仕組みを、C言語を使って体感していきましょう。

なぜWebエンジニアがメモリを理解すべきか？

普段、Ruby on RailsやNode.js、Goなどで開発していると、メモリを意識することは少ないかもしれません。しかし、こんな場面に遭遇したことはありませんか？

• 「メモリリーク」でアプリケーションが落ちた
• 「OutOfMemoryError」に悩まされた
• Dockerのメモリ制限で苦労した
• パフォーマンスチューニングで「ヒープ」「スタック」という言葉が出てきた

これらを理解するためには、メモリの基礎知識が必要です。C言語は、メモリを直接操作できる言語なので、メモリの仕組みを学ぶのに最適なんです。

メモリとは何か？

概念図で理解する

まず、メモリの全体像を把握しましょう。

┌─────────────────────────────────────────────────────────────────┐
│                        物理メモリ（RAM）                          │
│                                                                 │
│  メモリは「番地（アドレス）がついた巨大なロッカー」のようなもの      │
│                                                                 │
│  ┌──────┬──────┬──────┬──────┬──────┬──────┬──────┬──────┐      │
│  │ 0x00 │ 0x01 │ 0x02 │ 0x03 │ 0x04 │ 0x05 │ 0x06 │ 0x07 │ ...  │
│  │      │      │      │      │      │      │      │      │      │
│  │ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│      │
│  └──────┴──────┴──────┴──────┴──────┴──────┴──────┴──────┘      │
│     ↑                                                           │
│  アドレス（16進数で表される）                                     │
└─────────────────────────────────────────────────────────────────┘

ポイントは3つです。

1. メモリには「アドレス」という番地がある
2. 1つのアドレスには（基本は）1バイト（8ビット）のデータが格納できる
3. アドレスは通常、16進数（0x...）で表現される

駅のコインロッカーを想像してみてください。ロッカー番号がアドレスで、中に入れる荷物がデータです。ただし、1つのロッカーに入る荷物は1バイト分だけ。大きなデータは、複数のロッカーにまたがって入れる必要があります。

プログラムが使うメモリ領域

プログラムが実行されると、OSはそのプログラム専用のメモリ空間を割り当てます。このメモリ空間は、いくつかの領域に分かれています。

┌─────────────────────────────────────────┐  高いアドレス
│              スタック領域                │  ← 関数のローカル変数など
│                  ↓                      │    （自動で確保・解放）
│                  ↓                      │
├─────────────────────────────────────────┤
│                                         │
│              空き領域                    │
│                                         │
├─────────────────────────────────────────┤
│                  ↑                      │
│                  ↑                      │
│              ヒープ領域                  │  ← 動的に確保するメモリ
│                                         │    （mallocなど）
├─────────────────────────────────────────┤
│              BSS領域                     │  ← 初期化されていない
│          (未初期化データ)                 │    グローバル変数
├─────────────────────────────────────────┤
│              データ領域                  │  ← 初期化された
│           (初期化済みデータ)              │    グローバル変数
├─────────────────────────────────────────┤
│              テキスト領域                │  ← プログラムのコード
│            (コード領域)                  │    （機械語）
└─────────────────────────────────────────┘  低いアドレス

今回は特にスタック領域とヒープ領域に注目します。この2つの違いがわかると、「なぜメモリリークが起きるのか」がスッキリ理解できるようになります。

環境準備

前回と同じく、実際にコードを動かしていきましょう。GCCが必要です。GCCが入っていない方は、ご自身の環境に合わせてググってインストールしてください！

# バージョン確認
gcc --version

変数とメモリアドレス

変数はメモリ上のどこにある？

まず、変数がメモリ上のどこに配置されるかを確認してみましょう。

ファイル名: address.c

#include <stdio.h>

int main() {
    int number = 42;
    char letter = 'A';
    double pi = 3.14159;
    
    printf("=== 変数の値とアドレス ===\n\n");
    
    printf("int型変数 number\n");
    printf("  値: %d\n", number);
    printf("  アドレス: %p\n", (void*)&number);
    printf("  サイズ: %zu バイト\n\n", sizeof(number));
    
    printf("char型変数 letter\n");
    printf("  値: %c\n", letter);
    printf("  アドレス: %p\n", (void*)&letter);
    printf("  サイズ: %zu バイト\n\n", sizeof(letter));
    
    printf("double型変数 pi\n");
    printf("  値: %f\n", pi);
    printf("  アドレス: %p\n", (void*)&pi);
    printf("  サイズ: %zu バイト\n", sizeof(pi));
    
    return 0;
}

コンパイルと実行

gcc -o address address.c
./address

実行結果の例

=== 変数の値とアドレス ===

int型変数 number
  値: 42
  アドレス: 0x7ffd5c8b3a4c
  サイズ: 4 バイト

char型変数 letter
  値: A
  アドレス: 0x7ffd5c8b3a4b
  サイズ: 1 バイト

double型変数 pi
  値: 3.141590
  アドレス: 0x7ffd5c8b3a40
  サイズ: 8 バイト

ここで注目すべきなのは、型によってサイズが違うこと。intは4バイト、charは1バイト、doubleは8バイト。そしてアドレスを見ると、変数ごとにちゃんと別々の場所が割り当てられているのがわかります。

解説

• &演算子：変数の前に&をつけると、その変数のメモリアドレスが取得できます
• %p：アドレスを表示するためのフォーマット指定子です
• sizeof：変数や型のサイズ（バイト数）を返します

メモリのイメージ（上記の例の場合）

アドレス        値              変数名
0x7ffd5c8b3a40  [3.14159....]   pi (8バイト)
    :
0x7ffd5c8b3a4b  ['A']           letter (1バイト)
0x7ffd5c8b3a4c  [42......]      number (4バイト)
    ↓
スタック領域（高いアドレスから低いアドレスへ伸びる）

💡 Webエンジニア向けメモ

JavaScriptではtypeofで型を調べますが、メモリサイズは完全に隠蔽されています。 C言語では、型によってメモリの使用量が明確に決まります。 これが「型を意識する」ということの本質です。 Goのunsafe.Sizeof()やRustのstd::mem::size_of()でも同じようにサイズを確認できます。

ポインタの超基礎

ポインタとは？

C言語といえばポインタ！…そして、挫折ポイントでもありますよね。でも恐れることはありません。一言でいうと、

ポインタ = メモリアドレスを格納する変数

それだけです。「値そのもの」ではなく「値がある場所（住所）」を覚えておく変数、というだけ。

┌────────────────────────────────────────────────────────────┐
│                                                            │
│   通常の変数                      ポインタ変数              │
│   ┌─────────┐                   ┌─────────────┐            │
│   │   42    │                   │ 0x7ffd...4c │            │
│   └─────────┘                   └──────┬──────┘            │
│   number                               │                   │
│   (int型)                              │ 「ここを見て！」   │
│                                        ↓                   │
│                                   ┌─────────┐              │
│                                   │   42    │              │
│                                   └─────────┘              │
│                                   number                   │
│                                                            │
└────────────────────────────────────────────────────────────┘

ポインタを使ってみよう

ファイル名: pointer_basic.c

#include <stdio.h>

int main() {
    int number = 42;
    int *ptr = &number;  // numberのアドレスをptrに格納
    
    printf("=== ポインタの基本 ===\n\n");
    
    // 元の変数
    printf("number の値: %d\n", number);
    printf("number のアドレス: %p\n\n", (void*)&number);
    
    // ポインタ変数
    printf("ptr の値（= numberのアドレス）: %p\n", (void*)ptr);
    printf("ptr が指す先の値（*ptr）: %d\n", *ptr);
    printf("ptr 自身のアドレス: %p\n\n", (void*)&ptr);
    
    // ポインタを使って値を変更
    printf("--- ポインタ経由で値を変更 ---\n");
    *ptr = 100;  // ポインタを通じてnumberの値を変更
    printf("*ptr = 100 を実行後:\n");
    printf("number の値: %d\n", number);
    printf("*ptr の値: %d\n", *ptr);
    
    return 0;
}

実行結果

gcc -o pointer_basic pointer_basic.c
./pointer_basic

=== ポインタの基本 ===

number の値: 42
number のアドレス: 0x7ffd5c8b3a4c

ptr の値（= numberのアドレス）: 0x7ffd5c8b3a4c
ptr が指す先の値（*ptr）: 42
ptr 自身のアドレス: 0x7ffd5c8b3a40

--- ポインタ経由で値を変更 ---
*ptr = 100 を実行後:
number の値: 100
*ptr の値: 100

*ptr = 100 しただけなのに、numberの値も100に変わっています。同じメモリを指しているから当然なんですが、初めて見るとちょっと不思議ですよね。

ポインタの記号まとめ

* が宣言時と使用時で意味が変わるのがハマりポイントです。

宣言と使用の違い

int *ptr = &number;   ← 宣言時の * は「ポインタ型」を示す
     ↓
*ptr = 100;           ← 使用時の * は「参照先にアクセス」を示す

💡 Webエンジニア向けメモ

「ポインタ」って難しそうに聞こえますが、実はJavaScriptやRubyでも似た概念はあります。 オブジェクトを変数に代入すると、値のコピーではなく「参照」が渡される、あれです。 C言語のポインタは、その参照を明示的に操作できるというだけの話なんです。

メモリの動的確保（malloc / free）

スタックとヒープ

ここまで見てきた変数は、すべてスタック領域に確保されていました。スタック領域の変数は、関数が終了すると自動的に解放されます。

一方、ヒープ領域は、プログラマが明示的に確保・解放するメモリです。

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   スタック領域                    ヒープ領域                 │
│   ─────────────                  ─────────────              │
│                                                             │
│   ✅ 自動で確保・解放              ⚠️  手動で確保・解放       │
│   ✅ 高速                         ⚠️  やや低速               │
│   ❌ サイズはコンパイル時に決定     ✅ サイズを実行時に決定可能 │
│   ❌ 関数内でのみ有効              ✅ 関数をまたいで使える     │
│                                                             │
│   用途: ローカル変数               用途: 可変長データ、        │
│        関数の引数                      長期間保持するデータ   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

RubyやJavaScriptでは new するだけでヒープにオブジェクトが作られますが、C言語では自分で「これだけのメモリをください！」とOSにお願いする必要があります。それが malloc() です。

malloc と free

ファイル名: malloc_basic.c

#include <stdio.h>
#include <stdlib.h>  // malloc, free に必要

int main() {
    printf("=== 動的メモリ確保 ===\n\n");
    
    // 整数1つ分のメモリを確保
    // ※C言語ではmallocの戻り値(void*)は暗黙的にキャストされるため、
    //   キャストは省略可能です。ここでは意図を明示するために記載しています。
    //  （C++ではキャストが必須です）
    int *ptr = (int *)malloc(sizeof(int));
    
    // 確保できたか確認（重要！）
    if (ptr == NULL) {
        printf("メモリの確保に失敗しました\n");
        return 1;
    }
    
    printf("メモリを確保しました\n");
    printf("確保したアドレス: %p\n", (void*)ptr);
    printf("確保したサイズ: %zu バイト\n\n", sizeof(int));
    
    // 確保したメモリに値を格納
    *ptr = 12345;
    printf("格納した値: %d\n\n", *ptr);
    
    // メモリを解放
    free(ptr);
    printf("メモリを解放しました\n");
    
    // 解放後のポインタはNULLにするのが安全
    ptr = NULL;
    
    return 0;
}

実行結果

gcc -o malloc_basic malloc_basic.c
./malloc_basic

=== 動的メモリ確保 ===

メモリを確保しました
確保したアドレス: 0x55a8b6c4a2a0
確保したサイズ: 4 バイト

格納した値: 12345

メモリを解放しました

malloc → 使う → free の3ステップ。これがC言語のメモリ管理の基本です。free を忘れると大変なことになりますが、それは後ほど

配列を動的に確保する

スタック上の配列は int array[5]; のようにサイズをコンパイル時に決める必要がありますが、malloc を使えば実行時にサイズを決められます。

ファイル名: malloc_array.c

#include <stdio.h>
#include <stdlib.h>

int main() {
    int n;
    printf("配列の要素数を入力してください: ");
    scanf("%d", &n);
    
    // n個のint配列を動的に確保
    int *array = (int *)malloc(sizeof(int) * n);
    
    if (array == NULL) {
        printf("メモリの確保に失敗しました\n");
        return 1;
    }
    
    printf("\n%d個のint型配列を確保しました\n", n);
    printf("確保したサイズ: %zu バイト\n", sizeof(int) * n);
    printf("先頭アドレス: %p\n\n", (void*)array);
    
    // 配列に値を格納
    for (int i = 0; i < n; i++) {
        array[i] = i * 10;
    }
    
    // 配列の内容とアドレスを表示
    printf("インデックス | 値   | アドレス\n");
    printf("-------------|------|------------------\n");
    for (int i = 0; i < n; i++) {
        printf("    %d        | %3d  | %p\n", i, array[i], (void*)&array[i]);
    }
    
    // メモリを解放
    free(array);
    array = NULL;
    
    printf("\nメモリを解放しました\n");
    
    return 0;
}

同様に実行すると？

実行結果

配列の要素数を入力してください: 5

5個のint型配列を確保しました
確保したサイズ: 20 バイト
先頭アドレス: 0x55a8b6c4a2a0

インデックス | 値   | アドレス
-------------|------|------------------
    0        |   0  | 0x55a8b6c4a2a0
    1        |  10  | 0x55a8b6c4a2a4
    2        |  20  | 0x55a8b6c4a2a8
    3        |  30  | 0x55a8b6c4a2ac
    4        |  40  | 0x55a8b6c4a2b0

メモリを解放しました

アドレスが4バイトずつ増えているのがわかりますか？ これは int 型が4バイトだからです。メモリ上にきれいに並んでいるのが見えると、配列の正体がよくわかりますね。

💡 Webエンジニア向けメモ

GoやRustでは make([]int, n) や Vec::with_capacity(n) のように、 動的にサイズを指定して配列やスライスを作ることがよくあります。 裏側では似たようなヒープへのメモリ確保が行われています。

メモリリークを体験する

メモリリークとは？

メモリリークとは、確保したメモリを解放し忘れることで、使えるメモリが徐々に減っていく現象です。Webアプリの運用でよくある「なぜかメモリ使用量が右肩上がりで、定期的に再起動しないといけない」の原因、だいたいコレです。

ファイル名: memory_leak.c

#include <stdio.h>
#include <stdlib.h>

void bad_function() {
    // メモリを確保するが、解放しない（これがメモリリーク！）
    int *ptr = (int *)malloc(sizeof(int) * 1000);
    if (ptr == NULL) return;
    *ptr = 42;
    // free(ptr); ← これがない！
}

void good_function() {
    int *ptr = (int *)malloc(sizeof(int) * 1000);
    if (ptr == NULL) return;
    *ptr = 42;
    free(ptr);  // ちゃんと解放
}

int main() {
    printf("=== メモリリークのデモ ===\n\n");
    
    printf("bad_function を1000回呼び出します...\n");
    for (int i = 0; i < 1000; i++) {
        bad_function();
    }
    printf("完了（約4,000,000バイトがリークしています）\n\n");
    
    printf("good_function を1000回呼び出します...\n");
    for (int i = 0; i < 1000; i++) {
        good_function();
    }
    printf("完了（メモリリークなし）\n");
    
    return 0;
}

bad_function は1回呼ぶたびに sizeof(int) * 1000 = 4,000バイト をリークします。1,000回呼ぶと約4,000,000バイト（約3.8MB）の漏れです。たった数行の free の書き忘れで、これだけのメモリが無駄になるんですね。

Valgrindでメモリリークを検出

C言語にはメモリリークを検出する定番ツール Valgrind があります。Linuxでは、以下で確認できます！

# Valgrindのインストール（Ubuntu）
sudo apt install valgrind

# コンパイル（デバッグ情報付き）
gcc -g -o memory_leak memory_leak.c

# Valgrindで実行
valgrind --leak-check=full ./memory_leak

検出結果

==12345== LEAK SUMMARY:
==12345==    definitely lost: 4,000,000 bytes in 1,000 blocks
==12345==    indirectly lost: 0 bytes in 0 blocks
==12345==      possibly lost: 0 bytes in 0 blocks
==12345==    still reachable: 0 bytes in 0 blocks
==12345==         suppressed: 0 bytes in 0 blocks

definitely lost: 4,000,000 bytes — バッチリ検出されました！ こんなふうに、C言語ではメモリの問題を直接確認できます。

💡 Webエンジニア向けメモ

Node.jsでも同様のメモリリークは起こります。例えば、グローバル変数に配列を追加し続けたり、イベントリスナーを解除し忘れたり、クロージャで大きなオブジェクトを参照し続けたり。原理は同じで、「使わなくなったメモリが解放されない」ことが問題です。

Node.jsの場合は --inspect フラグをつけて起動し、Chrome DevToolsの「Memory」タブでHeap Snapshotを取ると、Valgrindのようにリークを調査できます。Goなら pprof が同様のツールになります。

スタックとヒープの違いを実感する

ダングリングポインタの危険

最後に、スタックとヒープの違いが生む典型的なバグを見てみましょう。

ダングリングポインタとは、すでに無効になったメモリを指すポインタのことです。「存在しない住所が書かれたメモ」みたいなものですね。

ファイル名: dangling.c

#include <stdio.h>
#include <stdlib.h>

// ダメな例：スタック上の変数のアドレスを返す
int* bad_get_number() {
    int local = 42;
    return &local;  // ⚠️ 関数終了後、localは無効になる
}

// 良い例：ヒープ上にメモリを確保して返す
int* good_get_number() {
    int *ptr = (int *)malloc(sizeof(int));
    if (ptr == NULL) return NULL;
    *ptr = 42;
    return ptr;  // ✅ ヒープ上なので関数終了後も有効
}

int main() {
    printf("=== ダングリングポインタのデモ ===\n\n");
    
    printf("【危険】スタック上の変数を返す場合:\n");
    int *bad = bad_get_number();
    printf("アドレス: %p\n", (void*)bad);
    // ⚠️ この行は未定義動作です！何が表示されるかわかりません
    // コンパイラの最適化レベルによって挙動が変わります
    printf("値（未定義動作！）: %d\n\n", *bad);
    
    printf("【安全】ヒープ上のメモリを返す場合:\n");
    int *good = good_get_number();
    if (good != NULL) {
        printf("アドレス: %p\n", (void*)good);
        printf("値: %d\n", *good);
        free(good);  // 使い終わったら解放
    }
    
    return 0;
}

コンパイル時の警告

# 最適化なしでコンパイル（未定義動作の挙動を確認するため）
gcc -Wall -O0 -o dangling dangling.c

dangling.c: In function 'bad_get_number':
dangling.c:7:12: warning: function returns address of local variable [-Wreturn-local-addr]
    7 |     return &local;
      |            ^~~~~~

コンパイラが警告してくれますね！ -Wall オプションをつけてコンパイルすると、こうした危険なコードを事前にキャッチできます。

この例がまさに「スタック vs ヒープ」の違いです。スタック上の変数（local）は関数を抜けた瞬間に無効になりますが、ヒープ上のメモリ（malloc で確保したもの）は free するまで有効。だからこそ、ヒープに確保して返すのが正しいパターンなんです。ただし、前述のメモリリークのように、freeを忘れないようにしないといけません！

💡 Webエンジニア向けメモ

GoやRustでは、この種のバグはコンパイラが防いでくれます。 Goでは「エスケープ解析」によって、関数外に渡される変数は自動的にヒープに配置されます。 go build -gcflags="-m" で確認できるので、興味のある方はぜひ試してみてください。 Rustではさらに厳密で、所有権とライフタイムの仕組みによって、ダングリングポインタの発生をコンパイル時に完全に防いでいます。

まとめ

今回学んだことを整理しましょう。

┌─────────────────────────────────────────────────────────────────┐
│                        今回のまとめ                             │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. メモリにはアドレスがある                                     │
│     → & でアドレスを取得、%p で表示                              │
│                                                                 │
│  2. ポインタ = アドレスを格納する変数                            │
│     → int *ptr = &number;                                       │
│     → *ptr でポインタが指す値にアクセス                          │
│                                                                 │
│  3. 動的メモリ確保                                               │
│     → malloc() で確保、free() で解放                             │
│     → 解放を忘れるとメモリリーク                                 │
│                                                                 │
│  4. スタック vs ヒープ                                           │
│     → スタック：自動管理、関数内で有効                           │
│     → ヒープ：手動管理、プログラム全体で有効                     │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Web系っぽい言語との対応

C言語で学んだ概念は、普段使っている言語にも対応しています。

※ スタックとヒープの割り当ては言語や実装によって異なります。例えばGoではエスケープ解析によって、見た目はローカル変数でもヒープに配置されることがあります。上記はJavaでの一般的なイメージとして参考にしてください。

前回のリンクの話と今回のメモリの話で、だいぶコンピュータの「裏側」が見えてきたのではないでしょうか？ この知識があると、Dockerのリソース制限とかOOMKilledとか、「あ、あれのことね」とピンとくるようになりますよ！

たぶん！

こちらからは以上です。

]]>https://tech.anti-pattern.co.jp/expansion_of_employment_insurance_coverage/Ghost__Post__69411b6571fa390001b357faWed, 08 Apr 2026 00:59:00 GMT

こんにちは！
アンチパターン管理部の森口です。

今回は、2024年5月10日に成立した「雇用保険法等の一部を改正する法律」で最も影響が大きい、2028年10月1日施行の「雇用保険の適用拡大」について学びたいと思います。

前提

労働者を1人でも雇用する事業は、原則として雇用保険の「強制適用事業」となり、事業主は、正社員・パート・アルバイトといった雇用形態にかかわらず、加入要件を満たす労働者を雇用保険に加入させる義務があります。
参考：第2章　雇用保険の適用について｜厚生労働省

雇用保険の適用拡大で何が変わるの？

• 雇用保険の加入要件の一部が変わる
  週の所定労働時間に関する要件が「週20時間以上」から「週10時間以上」に拡大されます。
  これにより、今まで雇用保険の加入対象外であった「週10時間以上〜20時間未満」の短時間労働者に関しても、雇用保険の強制加入対象となります。
  
  
• 被保険者期間の算定基準などが緩和される
  失業等給付、育児休業等給付、教育訓練給付などの受給資格を得るために必要な「被保険者期間」の算定基準や、失業認定基準なども「週10時間以上」の短時間労働者に対応して緩和されます。
  

参照元：令和6年雇用保険制度改正（令和10年10月1日施行分）について｜厚生労働省

雇用保険の加入要件をおさらいしよう！

① 労働時間に関する要件

〜2028年9月30日
　週の所定労働時間が20時間以上であること
2028年10月1日〜
　週の所定労働時間が10時間以上であること （←ここが改正ポイント！）

② 雇用見込みに関する要件

31日以上の雇用見込みがあること

• 期間の定めがない契約の場合（無期雇用）は、この要件を満たす
• 期間の定めがある契約の場合（有期雇用）は、更新条項の有無や、過去の雇用実績から31日以上の雇用が見込まれる場合に要件を満たす

③ 適用除外に関する要件

以下の「適用除外（加入義務がない人）」に該当しないこと

• 昼間学生
  ただし、夜間学生・通信制学生・休学中の学生・内定者アルバイト（卒業見込み証明書を有する者に限る）は加入義務あり
  
• 法人の役員
  ただし、労働者としての雇用関係が実態として存在する場合（使用人兼務役員など）は加入義務あり
  
• その他、法令で定められた一部の労働者
  季節的に雇用される労働者や船員など
  

参考：第4章 被保険者について｜厚生労働省

雇用保険に加入するメリット/デメリット

メリット（万が一の保障とスキルアップ支援）

• 一定の条件を満たすことで、失業時や、育児・介護休業時などに、給付金を受け取ることができる
• スキルアップを目的とした「教育訓練給付」などの支援制度を利用できるようになる

デメリット（保険料負担による手取り額の減少）

• 毎月の給与から雇用保険料が差し引かれるため、手取り額が減少する
  と言っても、一般の事業の雇用保険料率（労働者負担）は現在0.5％なので、給与支給額が50,000円の場合の雇用保険料は250円です。
  参照元：令和8(2026)年度 雇用保険料率のご案内｜厚生労働省
  
  

おわりに

2028年10月1日施行ですので、まだ先ではありますが、「週10時間以上」という新しい基準を念頭に置き、今後の働き方を考える参考にしていただければ幸いです！

※本記事は2026年3月24日時点の情報を元に作成しています。

]]>https://tech.anti-pattern.co.jp/train-camp-2026-winter/Ghost__Post__69c2228c71fa390001b363c6Wed, 01 Apr 2026 01:42:34 GMT1. はじめに：期初に「全員」で集まる理由

私たちの会社では、半期に一度、新しい期のスタートに合わせて社員全員が参加する、1泊2日の全社合宿、名付けて「AP合宿」なるものを開催しています。

熱海や湯河原などの温泉地に足を運び、日常のオフィスや自宅から離れた環境で、心身ともにリフレッシュしながら議論を深める時間を大切にしています。

現在、私たちはフルリモートワークが可能な環境で業務を行っています。画面越しでも円滑に仕事が進む一方で、全員が同じ場所に集まり、直接顔を合わせる機会は決して多くありません。だからこそ、この合宿は私たちにとって、単なる会議の場としてだけではなく、対面でのコミュニケーションを通じて組織の連携を再確認する貴重な機会でもあるのです。

（なお、「旅」としてのワクワク感を楽しんでもらえるよう、人事として「合宿のしおり」を作成しており、部屋割りの発表なども含めた恒例行事として定着しています。）

本記事では、1日目、2日目とそれぞれの行程を追いながら、今回のAP合宿で具体的にどのような議論が行われ、それが組織にどのような変化をもたらしたのか、人事の視点からそのプロセスを振り返ります。

2. 【1日目】前期の振り返りと、今期ロードマップの策定

合宿の初日は、全員が今の率直な気持ちを話す「チェックイン」からスタートします。その後、代表から経営概況の共有を受け、会社全体の現在地を全員で目線合わせすることから議論が始まります。

午後のメインセッションは、各事業部ごとのワークです。ここでは単なる活動報告に留まらず、前期に掲げた目標に対してどのような成果を出せたのか、その達成度やプロセスをフラットに評価し合う時間を設けています。

自分たちの動きを客観的に振り返り、それが会社全体にどのようなインパクトを与えたのかを棚卸しする。期初にこの時間を設けることで、今期の目標やロードマップも、より精度の高い、自分たちの手で描き出した納得感のあるものへと繋がっていきます。

一人ひとりがチーム、そして全社における役割と、新期に向けた責任を再確認する、非常に密度の濃い時間となりました。

3. 【2日目】「未来」を繋ぎ、組織の壁を越える

2日目は、自身の専門領域の垣根を越えて、会社全体の連携をさらに深めるための対話を行います。ここで活用しているのが「ワールドカフェ」という形式です。

ワールドカフェとは？メンバーを入れ替えながら、リラックスした雰囲気で少人数の対話を重ねる手法です。多くの人と意見を交わすことで、組織全体に知識やアイデアを循環させることができます。

私たちの組織は、スタートアップでありながら複数事業を並行して展開しているのが大きな特徴です。日々の業務では各メンバーがメインで担当する事業に注力していますが、こうした合宿の場を活かすことで、小規模な組織ならではの機動力を保ちつつ、事業を横断したシナジーを最大化させていきたいと考えています。

この日のメインコンテンツは、前日の振り返りを踏まえた「事業ビジョン」「バリュープロポジション」「ロードマップ」の策定です。まずは各チームでこれらを徹底的に考え抜き、自分たちの進むべき方向を言語化します。

議論の中では、弊社の一事業であるSaaSus Platformに対して個人がどのような想いで向き合っているかを語り合う場面もありました。「日本の国力を上げたい」「開発者への敬意を感じるサービスにしたい」といった、普段の業務連絡ではなかなか出てこない個々の熱い視点に触れられたのは、非常に印象的なシーンでした。

その上でワールドカフェ形式を取り入れ、あえて担当の異なるメンバーを交えて意見交換を行いました。普段、別の事業に向き合っているメンバーがシャッフルされ、客観的な視点でフィードバックを送り合う。このプロセスを通じて、自分たちだけでは気づけなかった他事業との連携の種や、共通の課題、そして新たな顧客価値のエッセンスが取り込まれていきます。

こうした他チームからのフィードバックを反映させ、内容を最終化していきます。事業部を超えて会社全体で価値を最大化させるために、この合宿を通じて拍車をかけていくのです。

合宿の締めくくりとして行われた各チームの最終発表では、各事業のロードマップが全社的な整合性の取れたものへと磨かれ、組織全体の「共通言語」へと進化していく実感がありました。

4. 変化：合宿がもたらしたもの

合宿を経て感じているのは、組織のあちこちで「連携の土台」が着実に整い始めていることです。

こうした変化は、合宿が終わってすぐに劇的な形になるものばかりではありません。しかし、リアルで膝を突き合わせて議論した経験は、リモート環境に戻った後もじわじわと効いてくる大きな財産になっているように感じます。

特に感じていることを下記にて挙げてみました。

• 他チームへの解像度の向上： 普段担当していない事業の背景や意図を肌で感じたことで、事業部を跨いだコミュニケーションがよりスムーズになりました。
• チーム内の足並みの強化： 日頃から活動を共にするメンバー間でも、改めて対面でビジョンを共有したことで、新期に向けた結束力がさらに高まりました。
• 会社としての一体感： 複数の事業が並行して動く中で、全員が「一つの組織」として同じ方向を向いているという感覚を共有できました。

日常のやり取りにおいても、情報の汲み取りがスムーズになったり、各所でオーナーシップが育まれたりと、小さな変化が積み重なっているように思います。今回の合宿で芽吹いた「共通言語」を大切にしながら、これから生まれてくる事業間のシナジーを丁寧に育てていければと思います。

5. おわりに

人事として何より価値を感じるのは、こうした場を通じて「個の目標」が「組織の目標」へと昇華されていくプロセスです。

制度や仕組みを整えるだけでなく、こうした「顔の見える関係性」の中で本質的な対話を積み重ねることが、強い組織を作る大事な基盤になると信じています。合宿で描いたロードマップを胸に、今期もチーム一丸となって取り組んでまいります。

この度、SaaSus API が Postman パブリックワークスペースに登場しました！

Postman

1. Postman で公開されると何が嬉しいのか？

Postman パブリックワークスペースを利用することで、従来の開発フローにおける「手間」が以下のように解消されます。

• 認証設定の共通化: API キーなどの認証ヘッダー設定がテンプレート化されているため、設定ミスを防げます。
• 最新仕様が常に手元に: 公式のワークスペースを Fork すれば、常に最新のエンドポイント定義を同期して利用できます。

2. 最短で API を実行

以下の手順で、すぐに SaaSus API を手元で試せます。

1. ワークスペースへアクセス: [SaaSus Postman Public Workspace]を開きます。

2. コレクションを Fork: 自分のワークスペースにコレクションをFork（複製）します。

3. 環境変数の設定: EnvironmentでSaaSID, APIKey, SecretKey などの必須項目を入力します。

   

4. Send ボタンをクリック: 実行したいエンドポイントを選んで（必要に応じてパスパラメーターや Body を入力し）「Send」を押すだけで、レスポンスが返ってきます。

3. おすすめの「最初の一歩」

まずは以下の API から試してみるのがおすすめです。

Get Basic Configurations [doc]
SaaSus Platform に設定されている基本設定情報の取得

Get Tenants [doc]
SaaSus Platform で管理する、テナント情報の取得

4. ワークフローの自動化

一連の処理を自動化し、例えば CSV のユーザー一覧を読み込み、「ユーザー一括登録」→「テナントに割り当て」→「役割登録」といった一連の流れを、ボタン一つで実行（Collection Runner）できます。

これにより、SaaS の初期フェーズにおいて管理画面などを個別に開発する必要がなくなり、手作業による運用負荷を大幅に下げることにつながります。 開発リソースを本質的な機能開発に集中させつつ、複雑な設定変更やデータ投入をミスなく迅速に行えるようになります。

5. まとめ

今回の Postman 公開によって、単発の API 検証から複雑なワークフローの構築まで、SaaSus を活用した開発のリードタイムがさらに短縮されます。

Postman は単なる検証用にとどまらず、「簡易的な運用管理ツール」としても非常に強力です。管理画面が未整備なフェーズでも、Postman を介して柔軟にテナントやユーザー操作を行うことで、運用のアジリティを高めることができます。

仕様の確認、デバッグ、そして効率的な運用ツールとして、ぜひ Postman パブリックワークスペースをフル活用してください！

]]>https://tech.anti-pattern.co.jp/network-ga-koishikute2/Ghost__Post__69bf6a2671fa390001b36297Sun, 22 Mar 2026 04:56:46 GMT前回でCiscoの機器をいじり放題になったので、
機器をいじりながらプロトコルの勉強をしていきたいと思います。
今回はARP（Address Resolution Protocol）です。

ARPとは、OSI参照モデルの2層目のデータリンク層の通信をする際に利用するプロトコルで、IPアドレスからMACアドレスを取得するために利用します。
通信相手の識別にIPアドレスを利用する事が多いと思います。
例）PC0(192.168.0.1)からPC1(192.168.0.2)への通信など

ですが、実はIPアドレスだけではパケットを届けることはできません。同じネットワーク内にいる機器同士は「MACアドレス」を頼りに通信するからです。

そこで登場するのがARPです。 「このIPアドレスの人は、どのMACアドレスを持ってますかー！？」と聞き回る、ネットワーク界の聞き込み調査員のようなプロトコルです。

さっそく、実際の通信を見ていきましょう。ハブをおいて、PCが複数台つながっているネットワークを用意します。

Cisco Catalyst 2960には特に設定しません。
PCは以下のように設定します。
PC0
　IPv4 Address:192.168.0.1
　Subnet Mask:255.255.255.0
PC1
　IPv4 Address:192.168.0.2
　Subnet Mask:255.255.255.0
PC2
　IPv4 Address:192.168.0.3
　Subnet Mask:255.255.255.0
※設定方法わからない人は、前回の記事見ていただけるとわかります。
　https://tech.anti-pattern.co.jp/network-ga-koishikute/

IPアドレスとMACアドレスを確認していきます。
コマンドプロンプトを開いて、「ipconfig /all」で確認します。

PC0からPC1にpingをします。通信の中でIPアドレスからMACアドレス取得が必要となり、ARP通信が発生するのでそれを見ていきます。

PC0で通信が発生したのが確認できます。通信内容の詳細を見てみます。

メッセージを見ると、ARP Packetと書いてあるので、ARP通信であることが確認できます。
送信元は0001.6339.2D43(PC0)、送信先はFFFF.FFFF.FFFF（全員宛の通信）となっています。

ARP通信がハブに届きました。

ハブからネットワーク全体（PC1とPC2）に通信を送っています。

IPアドレスが一致するPC1だけがARPに応答します。
PC2にもパケットが届いていますが、PC2は『自分宛（192.168.0.2）じゃないな』と判断して、このパケットを静かに破棄しています。

PC0にARP通信が帰ってきました。この時点でPC0は、IPアドレス192.168.0.2のMACアドレスが000D.BD02.95E8であることを認識します。

この情報はARPテーブルに保存され、しばらく記憶されます。なので通信のたびにARPが発生するわけではありません。

この後の通信の流れも見ていきます。
ARP通信が終わり、次はpingの通信となります。PC1に届いて、返信がPC1に帰ってきます。

これがPC0からPC1への通信内容になります。MACアドレスを知っているので、PC1のMACアドレスへの通信となっています。

もう少し通信内容を詳細に見ていきます。
pingの通信はICMPを利用するので、通信内容がICMPとなっています。TYPEが0x08となっています。これはICMPのエコー要求（ICMP届いたら返事してね）という意味になります。
詳しくはこちら
https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-types

次はPC1からPC0の通信を見てみます。

TYPEが0x00となっています。これはICMPのエコー応答（ICMP届いたのでお返事ですよ）という意味になります。

これらの通信が裏側で実施されることで、上記のpingコマンドが動作することが確認できました。今回はここまでです。

今回は、AWS Bedrock の Prompt Router を実装し、実際に複数のLLM を最適に振り分ける仕組みがどれだけのコスト削減を実現できるのかを、ベンチマーク結果を通じて検証してみました。

Bedrock Prompt Router とは？

概要

Bedrock Prompt Router は、ユーザーのクエリに基づいて複数の LLM の応答品質を自動予測し、最適なモデルを自動選択する仕組みです。これにより品質を維持しながらコストを削減できます。

AWS の公式ドキュメントはこちら：

• AWS Bedrock Prompt Router API Reference
• 詳細解説記事（AWS ブログ）

ルーティングの仕組み

興味深い点として、Prompt Router は LLM そのものではなく、AWS が独自に開発した機械学習モデル で動作しています。各プロンプトに対して、複数の候補モデルの仮想的なレスポンス品質を予測してくれます。

ざっくり言うと以下のようなイメージです：

品質指標 = f(プロンプト内容, モデル特性, 過去トレーニングデータ)

つまり、各プロンプトの複雑度やタスク種別を自動判定し、「このクエリなら安くて軽い Haiku で十分」「こっちは高品質の Sonnet が必要」という判断を予測スコアベースで行うわけです。

LLM におけるトークンとは？

コスト削減の話に入る前に、トークンという概念を整理しておきましょう。

トークンの定義

LLM が処理する最小単位がトークンです。

LLM は英語や日本語をそのまま処理するのではなく、機械語として処理しています。その最小単位を「トークン」と呼びます。

トークン化のざっくりした目安：

• 英語：1単語 ≈ 1トークン
• 日本語：1文字 ≈ 1トークン

2つの種類

LLM のトークン処理は大きく2つに分かれます：

1. 入力トークン ：ユーザーのクエリを処理するために必要
2. 出力トークン ：LLM が生成する応答に含まれる

トークン処理量が増えると、それだけ CPU や GPU の演算処理が必要になり、結果として コストが増加 します。

トークン化の体験

以下のページで、実際のテキストがどのようにトークン化されるかを体験できます：
OpenAI Tokenizer

LLM API の料金体系

LLM を API として利用する場合、多くの料金形態は 「リクエスト数」ではなく「トークン量」 で設定されていますが、トークンの概念を把握すると納得できるかと思います。そして品質を保ちながらコストを抑えることの重要性が、ここから見えてきます。

検証方針：何を測るのか？

「品質を維持しながらコストを削減できる」という Prompt Router の目的のうち、「コスト削減」 に焦点を当てます。品質は AWS が担保している前提で進めます。

今回検証しないこと

• Router を使用した時の 品質

今回検証すること

• コスト削減率

検証の全体像について

0:事前準備

TypeScript で構築し、以下の2つのモデルを用いる Prompt Router を作成しました：

• Claude 3.5 Sonnet v2（高品質・高コスト）
• Claude 3 Haiku（軽量・低コスト）

Router の作成は、AWS Bedrock コンソールから可能です。

作成後、以下のように CDK に組み込みます：

const promptRouterArn = new cdk.CfnParameter(this, 'PromptRouterArn', { type: 'String', description: 'Bedrock Prompt Router ARN', default: '作成したARNを貼り付ける'});

1:テストプロンプトの準備

100個のテストプロンプトを JSON 形式で用意しました。難易度別（easy, medium, hard）、カテゴリ別（general, customer_support, technical）に分散させています：

{"id": "001", "prompt": "今日は何曜日ですか", "category": "general", "difficulty": "easy"},{"id": "002", "prompt": "東京の天気は？", "category": "general", "difficulty": "easy"},{"id": "003", "prompt": "1+1は？", "category": "general", "difficulty": "easy"},... （略）

後半になるにつれ難易度が高くなるように設計しました。

2:メトリクスの計測

Lambda 関数内で、各プロンプトに対して以下を計測：

const result = {  id,
prompt: prompt.substring(0, 50),
category,
difficulty,
selectedModel: response.data.selectedModel,       // どのモデルが選ばれたか  
latency: response.data.metrics.latency,           // レスポンス時間（ms）  inputTokens: response.data.metrics.inputTokens,   // 入力トークン数  outputTokens: response.data.metrics.outputTokens, // 出力トークン数  totalTokens: response.data.metrics.totalTokens,   // 合計};

結果を JSON ファイルに出力：

{  "id": "001",  "prompt": "今日は何曜日ですか",  "category": "general",  "difficulty": "easy",  "selectedModel": "Haiku",  "latency": 556.494491,  "inputTokens": 32,  "outputTokens": 13,  "totalTokens": 45}... （略）

3:両ケースでの比較計算

ケース1：Router を使用
Haiku と Sonnet が自動振り分けされた結果

ケース2：Sonnet 固定
すべてのリクエストを Claude Sonnet で処理した場合

計算対象：

• 平均レイテンシ（ms）
• 入力トークン × 単価 + 出力トークン × 単価 = 総コスト

料金表：モデル別トークン単価

Claude 3.5 Sonnet

Claude 3 Haiku

4:ベンチマーク結果

100リクエストを処理した結果です。

Router 使用時（5%品質妥協）

✓ 001 [easy ] Haiku | Latency: 556ms | Tokens: 45 ✓ 002 [easy ] Haiku | Latency: 1766ms | Tokens: 185 ✓ 003 [easy ] Haiku | Latency: 585ms | Tokens: 38 ✓ 004 [easy ] Haiku | Latency: 2893ms | Tokens: 305 ✓ 005 [easy ] Haiku | Latency: 2623ms | Tokens: 278 ... （略）

集計結果

サマリー

・モデルの振り分け：Haiku 47件（47%） | Sonnet 53件（53%）
・応答速度：平均4,179ms（最速556ms〜最遅17,142ms）

タスクカテゴリ別：
├─一般: 35件 | 平均3,687ms | 平均コスト$0.0022
├─カスタマーサポート: 31件 | 平均3,870ms | 平均コスト$0.0027
└─技術系: 34件 | 平均4,966ms | 平均コスト$0.0035

タスク難易度別Haikuモデルの使用率
├─簡単: 35件 | 平均2,536ms | Haiku 69%
├─中級: 32件 | 平均4,992ms | Haiku 44%
└─困難: 33件 | 平均5,132ms | Haiku 27%

Sonnet 固定時（100%品質保証）

すべてのリクエストを Claude Sonnet 3.5 で処理した場合：

✓ 001 [easy ] Sonnet | Latency: 1913ms | Tokens: 102 ✓ 002 [easy ] Sonnet | Latency: 1935ms | Tokens: 101 ✓ 003 [easy ] Sonnet | Latency: 653ms | Tokens: 34 ... （中略）

サマリー

応答速度：平均4,516ms（最速653ms〜最遅17,405ms）

タスクカテゴリ別：
├─一般: 35件 | 平均3,977ms | 平均コスト$0.0031
├─カスタマーサポート: 31件 | 平均3,875ms | 平均コスト$0.0032
└─技術系: 34件 | 平均5,655ms | 平均コスト$0.0048

タスク難易度別：
├─簡単: 35件 | 平均2,966ms
├─中級: 32件 | 平均5,128ms
└─困難: 33件 | 平均5,567ms

上記から、Router は easy〜medium くらいのタスクをうまく Haikuモデル に逃がしつつ、全体のレイテンシとコストを抑えている一方でSonnet固定は常に安定した品質を出せるが、その分オーバースペックなケースでも高コスト・やや高レイテンシになるといった構図が、結果から読み取れました。詳しいコスト計算については下で行なっています。

考察：コスト・レイテンシの詳細分析

コスト計算

Router 使用時：

16,509 × $0.00000125 (Haiku 出力) + 16,997 × $0.000015 (Sonnet 出力) = $0.2807

Sonnet 固定時：

28,272 × $0.000015 (Sonnet 出力) = $0.4241

削減率

$0.4241 ÷ $0.2807 = 1.51倍 → コスト削減率：34% 低減

レイテンシ比較

Router の方が全体的に 7.5% 速い です。

これは Easy タスクで Haiku の利用率が高い（69%）ため、Haiku の高速性が効いているからだと思います。Haiku はモデルとして「軽い＝推論が早い」という特性を持ち、Easy 問題では Sonnet との品質差がほぼないため、この高速化が実現されています。

仮説:長期スコープでの削減額試算

自分は現在学生でエンジニアインターンとして働かせていただいているので、LLMのユースケースとしては、課題・日々の勉強・コーディング・その他諸々が考えられます。特に、コーディングエージェントのtool use系はトークン処理量が多いことを考えると、以下のようなシナリオが挙げられます。

• 1日：10万トークン消費
• 1ヶ月：300万トークン
• 1年：3600万トークン

入出力の比率を 1:1 と仮定（実際はプロンプトにより異なる）

Sonnet 固定の場合

月間コスト：150万 × $0.000015 + 150万 × $0.000003 = $27
年間コスト：$27 × 12 = $324

Router 使用時の場合

削減率：34% ⇒ $324 × 34% ≈ $110削減
年間実コスト：$324 - $110 = 約 $214

つまり、個人利用だけでも年間$110のコストが削減できます。

企業利用では、ユーザー数や従業員数 × 利用パターンが掛け算されるため、削減額はさらに膨らみます。例えば100人が同じシステムを利用すれば、年間約21400ドル（約350万円） の削減が可能になります。

結論

Router 導入のメリット

Router の方が、コストも応答速度も優位 です。

おわりに

今回の検証を通じて、AWS Bedrock の Prompt Router がいかに効果的なコスト削減手法であることが実感できました。

LLM API の利用が日常化する中、「品質を維持しながらコストを削減する」という課題に対して、このような ルーティング はこれからスタンダードになっていくと考えられます。

複数の LLM を使い分ける時代では単純にずっと性能が高いモデルを使うのではなく、「タスクに応じた最適なモデルを選択する」という戦略が重要になると思います。例えるなら現代は「燃費悪いガソリン車両で溢れかえっているが、まだ問題視されていない状況」であると思っていて、今後物理的資源の問題GPUなどが重要視されていくにつれ、このコスト削減問題はどんどん一般化していくと思っています。

Prompt Router は、その戦略を 自動化 し、かつ コスト削減と高速化 まで実現できるソリューション。ぜひ導入を検討してみてください。

POSSEでエンジニアインターンをしている吉川唯音です。本記事では、Kiroでリファクタリングしてみて気づいたことについて書いていきたいと思います。

▶︎実際にリファクタリング後にデプロイしたアプリケーション
https://no-vel.link/

はじめに

Figma makeを使えば、デザインからコードまで一気通貫でWebアプリケーションを作成できます。私もこの便利さに惹かれて、プロトタイプをサクッと作ってみました。

しかし、気づいた時には「保守不能」なコードベースが出来上がっていました。

• すべての画面がステートで管理され、URLはすべて同じ
• UIとロジックが混在
• if文のネストで画面を切り替える実装
• 使われていない大量のファイル
• any型だらけ、DOM直接操作

CursorやClaude Codeでリファクタリングを試みましたが、部分的な修正しかしてくれず、またエラーが出ても問題と判定されず、理想の状態には到達できませんでした。

そこで出会ったのがKiroのスペック駆動開発モードです

CursorとClaude Code

最初のアプローチで直面した問題：

• 全体像を把握してくれない - 部分的な修正のみで、関連ファイルへの影響を考慮しない
• エラーを問題と判定しない - TypeScriptエラーがあっても「完了です」と返す
• 理想状態に到達しない - 部分最適の積み重ねで、結局ぐちゃぐちゃに
• 作業単位が不明瞭 - 今何をしているのか、次に何をすべきかが見えない

時間をかけても動かないコードが量産されるだけでした。

Kiroのスペック駆動開発モード

Kiroの特徴は、既存のコードベースに対して

1. 要件（Requirements） を明確化
2. 設計（Design） を文書化
3. タスク（Task） を自動生成

という流れで進められます。

特にリファクタリングに向いている理由：

• 既存コードの構造を理解した上で要件を整理できる
• 段階的な変更を計画的に進められる
• タスク単位で進捗を確認できる

実践：要件定義から実装まで

リファクタリングの計画

Phase 1として、URLベースのルーティングへの移行を設定しました。MainApp内部のルーティングなど、その他の課題も段階的に対応する計画です。

Kiroとの対話で要件を整理

現状のコードベースを見せ、対話しながら要件を整理：

現在のApp.tsxでは、useStateによる状態ベースのルーティングを行っており、
12種類のAppStateをif文で切り替えている。
この実装をReact Router v7に移行し、URLベースのナビゲーションを実現する。
デザインや既存の動作は一切変更せず、内部構造のみをリファクタリングする。

Kiroはコードベースを分析し、kiro/spec/requirements.mdを生成してくれました。

重要だったのは、私が理想とする状態を明確に伝えることです。

設計とタスクの自動生成

要件が固まると、Kiroは設計書とタスクリストを自動生成します。

Kiroは各タスクを順番に実行し、タスクごとに確認を求めてくれます。承認のタイミングは自分で決められ、フェーズごとにbuildチェックも可能です。

メリット：

• 今何をしているかが明確
• いちいち細かい指示を出す必要がない
• テストコードまで自動生成してくれる

リファクタリング結果

Before:

function App() {
  const [appState, setAppState] = useState<AppState>('landing');

  if (appState === 'landing') {
    return <LandingPage 
      onGetStarted={() => setAppState('auth')}
      // ...大量のコールバック
    />;
  }
  // 以下、12種類のif文が続く...
}

After:

function App() {
  return (
    <Routes>
      <Route path="/" element={<LandingPage />} />
      <Route path="/auth" element={<AuthPage />} />
      <Route path="/pricing" element={<PricingPage />} />
      <Route path="/app/*" element={<MainApp />} />
      {/* ... */}
    </Routes>
  );
}

if文の嵐から解放され、宣言的なルーティングになりました。

自分で理想を考えて、ハンドルする重要性

Kiroは強力ですが、すべてを任せきりにすると上手くいかないこともわかりました。

私が自分で判断したこと

1. ディレクトリ構造の理想形

2. 使用するライブラリの選定

3. リファクタリングのフェーズ分け

4. Kiroが出したコードのレビュー

GitHubリポジトリを参考にする

Kiroの便利な機能として、GitHubのリポジトリを参照できる点があります。

以前作った綺麗な構造のプロジェクトをKiroに見せると、そのベストプラクティスを踏襲してくれました。過去の良い設計を再利用でき、プロジェクト間の一貫性も保てます。

リファクタリングした主要な箇所

Phase 1とその他のタスクで改善できた箇所：

1. ルーティング改善

Before:

function MainApp() {
  const [currentView, setCurrentView] = useState<'dashboard' | 'settings'>('dashboard');

  if (currentView === 'dashboard') return <Dashboard />;
  if (currentView === 'settings') return <Settings onBack={() => setCurrentView('dashboard')} />;
}

After:

function MainApp() {
  return (
    <Routes>
      <Route path="dashboard" element={<Dashboard />} />
      <Route path="settings" element={<Settings />} />
    </Routes>
  );
}

2. DOM直接操作の排除

Before: window.location.pathname = "/dashboard";

After: navigate('/app');

3. その他の改善

• any型の削除と型安全性の確保
• if文のネスト削減
• react-hook-formへの統一
• コンポーネントの再利用性向上
• UIとロジックの分離
• SWRを使用してステート管理を改善

自動サマライズ機能

Kiro(Cursorなどもですが)はコンテキストが上限に達する前に自動的にサマライズしてくれます。

これにより、作業が途切れることなく継続できました。

完了：動作確認と学び

すべてのタスクが完了し、ビルドも成功しました。

実際にブラウザで確認すると、一部importの忘れなどがありましたが、CursorやClaude Codeでは到達できなかったゴールに、同じ労力で到達できたことに驚きました。

反省点として、テストを早い段階で作成すれば良かったと思います。Kiroはテストコードも生成してくれるので、最初から書いてもらえば細かいミスは防げたでしょう。

要件や事前情報を伝えることの重要性

Kiroを使って最も学んだのは、事前に伝える情報の質が、成果物の質を決めるということです。

• 理想のディレクトリ構造
• 使用するライブラリとバージョン
• ベストプラクティスの参照先
• リファクタリングの優先順位

これらを明確に伝えることで、Kiroは期待以上の仕事をしてくれました。

将来の展望

Figma makeのガードレール作成

今回のリファクタリングで、AIがどのように判断してコードを記述するかが見えました。これを応用して、Figma makeで最初から綺麗に書いてもらうガードレールを作成できそうです。

自動化と学習のバランス

Kiroと一緒にリファクタリングするからこそ、コードへの理解が深まります。タスク単位で確認しながら進めることで、自然と学習できます。完全自動化よりも、人間とAIの協働が最も効率的だと感じました。

まとめ

Kiroの強み

• ちゃんと動くものを提供してくれる
• やりきってくれる - タスク単位で計画的に進め、最後まで完遂
• スペック駆動で安心 - 要件・設計・タスクが明確
• テストも自動生成
• コンテキストを自動サマライズ

Kiroのスペック駆動リファクタリングは、保守性の高いコードベースを維持する強力な味方になってくれそうです。

Kiroのspec開発に感動してずっと触っていましたが、少し時間が経過しました。KiroはすばらしいIDEなのですが、だんだん、Kiroを並列で実行して開発が出来れば、もっと早く開発ができるだろうなと思うようになってきました。

kiro-cliも今後spec作成をcliで行う機能を予定しているようですが、現在はありません。また、Kiroのタスクの実行が一つのworkspace内で作業をするので、並列で開発してPRを出すということが出来ません。

いくつか考えたkiroを並列実行して開発する方法は以下でした。

1. docker containerを立ち上げて、開発してPRまで行うところを1サイクルとして終わったらコンテナが終了する方法
2. remoteのmicroVMにタスクを投げて開発からPRまでを行う方法
3. git worktreeを作成して、その中でブランチを作成し、開発してPRまで行う方法

docker containerを立ち上げて、開発してPRまで行うところを1サイクルとして終わったらコンテナが終了する方法

docker containerは環境を分離しやすいという点では良いのですが、portなどを含めたコンテナの管理が複雑になりそうでした。

remoteのmicroVMにタスクを投げて開発からPRまでを行う方法

remoteのmicroVMにタスクを投げて開発からPRまでを行う方法は完全に環境が分離できますが、日頃の小さくインクリメントする開発にはオーバースペック感がありました。

フロントとapiを合わせて大規模なタスクを一気に開発するなどには向いていると思います。今回はコストもかかるので、やらないことにしました。

git worktreeを作成して、その中でブランチを作成し、開発してPRまで行う方法

git worktreeはかなりよく現在も使っている方法です。git worktree単体だと.envなどのコミットしていないファイルが引き継げないのですが、wtp を使えば可能になります。これでかなり使いやすくはなったのですが、やはりgit worktreeの作成しPRまでをシームレスに実行したくなったり、worktreeの管理も簡単にしたくなってきました。

結論：CLIツールを自作しています

現在はkiroでspecを作成した後はcliで完結できるようなツールを開発中です。

このツールの構想は以下の通りです：

1. Specを書く: いつも通りKiroでSpecファイルを作成
2. コマンド実行: ツールにSpecを渡す
3. 自動オーケストレーション

• 裏でGit Worktreeを自動作成（wtpの機構を活用して.envも同期）
• 依存関係（node_modulesなど）のリンクまたは高速セットアップ
• Kiroを実行してコード生成
• テストが通れば gh pr create でPRを作成
• 完了後、Worktreeをお掃除

おわりに

Kiroは今でも非常に完成度が高く、素晴らしいIDEだと感じています。

一方で、Specを書いたあとに発生する生成・テスト・PR作成といった工程では、どうしても手持ち無沙汰になる時間があり、もっと効率よく開発ができる余地があるのではないかと考えるようになりました。

まだ開発途中ですが、Spec駆動の開発をどうスケールさせるかを考える中で、ひとつの実践例として形にできたらと思っています。

]]>https://tech.anti-pattern.co.jp/kai-fa-huan-jing-nominioworustfsniyi-xing-sitahua/Ghost__Post__6958ec7671fa390001b35d95Wed, 07 Jan 2026 05:22:00 GMTこんにちは！いわむらです。

開発環境でS3互換のオブジェクトストレージとしてMinIOを使っていたのですが、2025年10月にMinIOがDockerイメージの無料配布を停止したので、これを機に別のS3互換ストレージに移行してみました。

MinIOのDockerイメージ配布停止

2025年10月15日のセキュリティリリース以降、DockerHubやQuay.ioでの公式イメージ配布が停止され、ユーザー自身でソースからビルドする必要が生じました。しかも事前告知なしだったため、コミュニティで大きな反発がありました。

MinIOが無料のDockerイメージ配布を突然停止、コミュニティからは反発の声 - GIGAZINE

開発環境でサクッとdocker compose upするだけで使えていたのに、自前ビルドが必要になるのは面倒だなと思い、他のS3互換ストレージへの移行を検討しました。

移行先の検討

S3互換のオブジェクトストレージとして、以下の3つを候補に挙げて調べてみました。

SeaweedFS

Go製の分散ストレージ。大規模なファイルストレージ向けで高いスケーラビリティが特徴です。

Docker Composeでの導入自体は可能なのですが、Master/Volume/Filerという複数コンポーネントの構成が必要で、開発環境にはやや大げさかなという印象でした。

Garage

Rust製の分散オブジェクトストレージ。軽量な設計が特徴です。ただ、分散システム前提の設計でノードの設定が必要になり、開発環境で手軽に使うには少し手間がかかりそうでした。

RustFS

Rust製のシンプルなS3互換ストレージ。単一コンテナで動作し、Docker Composeでの導入が最も簡単そうでした。MinIOとほぼ同じ設定で動くため、移行も容易そうです。

比較表

開発環境で手軽に使いたいので、今回はRustFSを選びました。

実際に移行してみた

移行作業はcompose.ymlを数行変更するだけでした。

Before（MinIO）

minio:
  image: minio/minio:latest
  environment:
    MINIO_ROOT_USER: sample-user
    MINIO_ROOT_PASSWORD: sample-password
  entrypoint: minio
  command: server /export --address :9000 --console-address :9001
  volumes:
    - ./docker/minio/data:/export
  ports:
    - "9000:9000"
    - "9001:9001"

After（RustFS）

rustfs:
  image: rustfs/rustfs:latest
  environment:
    RUSTFS_ACCESS_KEY: sample-user
    RUSTFS_SECRET_KEY: sample-password
    RUSTFS_CONSOLE_ENABLE: "true"
  command: ["/data"]
  volumes:
    - ./docker/rustfs/data:/data
  ports:
    - "9000:9000"
    - "9001:9001"

mc（MinIO Client）でバケットを作成する部分も、エンドポイントをminioからrustfsに変えるだけでOKでした。

アプリケーション側の設定変更は不要で、エンドポイントのコンテナ名を合わせるだけです。

AWS_ENDPOINT=http://rustfs:9000

移行後の所感

移行後、以下の操作を試してみましたが、すべて問題なく動作しました。

• ファイルのアップロード・ダウンロード
• 署名付きURL（Presigned URL）の生成
• Web Consoleでのバケット管理
• mcコマンドでの操作

アプリケーション側のS3クライアント設定もエンドポイントを変えるだけで、コードの変更は不要でした。

Web Consoleも http://localhost:9001 でアクセスでき、MinIOと同じ感覚で使えます。

これでフレームワーク依存がなくなりました。

まとめ

MinIOのDockerイメージ無料配布停止をきっかけにRustFSへ移行しました。

• 移行は簡単：compose.ymlの数行変更のみ
• 問題なく動作：S3 API互換で既存コードそのまま

SeaweedFSやGarageも良いツールですが、開発環境でサクッと使いたいなら個人的にはRustFSが移行しやすそうだなと思いました。同じような状況の方の参考になれば！

最近CDKを実装する機会が多く、AIを使いながら実装していますが、最新の情報をインプットしたうえでの実装はなかなかやってくれないものです。自分の勉強不足ではあるのですが、AIを使いながら、成果も出しながら、勉強もしながらできないかなぁと思っていたところ、Kiro Powersというものがあると知ったので試してみました。

Kiro Powersとは

Kiro Powersとは、Kiroの機能を拡張するためのプラグインシステムで、MCP（Model Context Protocol）サーバー、ステアリングファイル（指示・ルールファイル）、フックなどを1つのパッケージにまとめたものです。

Kiro powers の紹介 | Amazon Web Services

AI アシスタントは、フレームワークの専門知識への即座のアクセスを提供し、より速くリリースできるようにすべきです。しかし、今日の AI エージェントも同じ課題に直面しています。組み込みの知識がなければ、あなたと同じように推測と反復を繰り返します。Kiro powers は、幅広い開発とデプロイメントのユースケースに対して、その統一されたアプローチを提供します。MCP ツールとフレームワークの専門知識を一緒にパッケージ化し、動的に読み込みます。

Amazon Web Services

従来は個別に設定が必要だった外部ツールとの連携やプロジェクトのルール設定を、インストールするだけで一括してセットアップできます。

主な特徴とメリット

1. コンテキスト問題の解消（動的読み込み）：従来のMCPサーバーは全てのツールを事前に読み込むため、AIの記憶領域（コンテキスト）を圧迫する課題がありました。Kiro Powersは、プロンプトに含まれる「キーワード」を検知したときだけ必要な機能を動的に読み込むため、効率的なコンテキストの利用が可能です。
2. 専門知識の即時活用：汎用的なAIの回答ではなく、FigmaやTerraformといった各サービス固有の最新ベストプラクティスに基づいた、精度の高いコード生成が可能になります。
3. セットアップの自動化：インストールすると、必要なディレクトリ構成やMCP設定が自動で行われ、AIエージェントによるオンボーディング（初期設定の自動実行）が開始されます。
4. 将来的なクロス互換性：現在はKiro IDE専用ですが、将来的にはCursorやClaude Code、Clineといった他の主要なAI開発ツールでも動作する標準規格を目指して開発されています。

今回使うKiro Powers 💪

今回はCDKの実装のため、Build AWS infrastructure with CDK and CloudFormationを使ってみました！

環境構築

まず最新のバージョンにアップデートすることをお忘れなく！

次に、Kiro IDEの左サイドバーからPowes（⚡が付いた可愛いKiroマーク）を選択し、Build AWS infrastructure with CDK and CloudFormationをインストールします。

インストールはすぐに完了します。ノーマルKiroアイコンをクリックしてインストールされたかどうか確認することができます。

9個のツールが提供されていることがわかりますね。

次に、Try Powerボタンを押してチュートリアルを開始してみましょう。

こんな感じでチュートリアルが始まります。

概要
aws-infrastructure-as-code パワーは、CDK と CloudFormation を使用して AWS インフラストラクチャを構築し、検証するのに役立ちます。このパワーには以下の機能があります。

CDK 開発:
- 最新の CDK ドキュメントと API リファレンスを検索
- TypeScript、Python、Java、C#、Go で動作するコードサンプルを見つける
- セキュリティとアーキテクチャに関する包括的なベストプラクティスを入手する
- 完全なコンストラクト ドキュメントを読む

CloudFormation 検証:
- テンプレートの構文とスキーマを検証 (cfn-lint)
- AWS Guard ルールに対するセキュリティコンプライアンスをチェック (cfn-guard)
- デプロイ前の検証ガイダンスを入手する

トラブルシューティング:
- パターンマッチングによる CloudFormation デプロイの失敗を分析
- 詳細な調査のための CloudTrail ディープリンクを入手する
- エラー解決のために CloudFormation ドキュメントを検索する

オンボーディング
朗報です！ほとんどの機能は AWS クレデンシャルなしで動作します。クレデンシャルが必要なのは、CloudFormation デプロイの失敗をトラブルシューティングする場合のみです。

これで環境構築は完璧です！！

実際に使ってみる

今回は、Step Functionsの実装で使ってみたいと思います。

なんでStep Functionsをやってみたいかというと、先日あるAIにCDKの実装をお願いしたところ、ASL(Amazon States Language) で実装されてしまい複雑なコードになってしまいました。（自分が指示してないのが悪いですが、、）

これまでStep FunctionsではASLを用いて定義するのが主流だったので、そのデータをたくさん学習していてそうなったのかなと思います。

AWSのドキュメントでは、Step Functionsでは、ASLではなくJSONataの利用が推奨されています。

Step Functions での JSONata を使用したデータ変換 - AWS Step Functions

JSONata を使用すると、ステート間でデータを変換できます。

AWS Step Functions

Build AWS infrastructure with CDK and CloudFormationを使ったら、指示しなくてもJSONataで実装してくれるのでは？？と思い試してみることにしました。

こんな指示を与えてみた

I want to create an AWS Step Function using AWS CDK (TypeScript). The workflow should take an input list of 'orders', filter only the orders where 'status' is 'PAID', and then calculate the total sum of all 'price' fields in those paid orders. Please implement this data transformation directly within the Step Function definition without using an external Lambda function.

AWS CDK (TypeScript) を使用して AWS Step Functions を作成したいと考えています。ワークフローは、「orders」の入力リストを受け取り、「status」が「PAID」の注文のみをフィルタリングし、その後、それらの支払済み注文のすべての「price」フィールドの合計を計算します。このデータ変換を、外部の Lambda 関数を使用せずに、Step Functions の定義内で直接実装してください。

Kiroの応答を見ると、search_cdk_documentation → search_cdk_samples_and_constructs → read_iac_documentation_page を実行していることがわかります。

それぞれ何をしているのか

1. search_cdk_documentation：AWS CDKの公式ドキュメントを検索する。

検索対象：

• AWS CDK API リファレンス
• AWS CDK ベストプラクティスガイド
• AWS CDK コードサンプル＆パターン
• CDK-NAG バリデーションルール（セキュリティチェック）

使用例：

search_cdk_documentation({
  query: "Lambda function with DynamoDB"
})

返ってくる情報：

• ドキュメントのタイトル
• URL
• 関連するコンテンツの抜粋
• ランキング（関連度順）

いつ使う？

• CDKコンストラクトのAPIや使い方を調べたい時
• 特定のAWSサービスの統合方法を知りたい時
• ベストプラクティスを確認したい時

2. search_cdk_samples_and_constructs：実際に動作するCDKのコードサンプルとコミュニティ製のコンストラクトを検索する。

検索対象：

• CDKコードサンプル（実装例）
• コミュニティコンストラクト
• 実装パターン
• 完全なCDKアプリケーション例

対応言語：

• TypeScript（デフォルト）
• Python
• Java
• C#
• Go

使用例：

search_cdk_samples_and_constructs({
  query: "Lambda DynamoDB CRUD",
  language: "typescript"
})

返ってくる情報：

• サンプルコードのタイトル
• GitHubなどのURL
• コードの抜粋
• 実装パターンの説明

いつ使う？

• 実際のコード例を見たい時
• 特定のユースケースの実装方法を知りたい時
• L3コンストラクト（高レベルな抽象化）を探している時

3. read_iac_documentation_page：AWSドキュメントの特定のページを取得して、マークダウン形式に変換するツール。

対応URL：

• docs.aws.amazon.com
• aws.amazon.com
• GitHub（aws-samples、awslabs など）
• constructs.dev

使用例：

read_iac_documentation_page({
  url: "https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda-readme.html"
})

返ってくる情報：

• ページの完全なコンテンツ（マークダウン形式）
• 目次（Table of Contents）
• コードブロック
• 表やリスト

特徴：

• 長いドキュメントは分割して取得可能
• start_index パラメータで続きを読める
• 最大文字数を指定可能

いつ使う？

• 検索結果から特定のページの詳細を読みたい時
• コンストラクトの完全なAPIリファレンスが必要な時
• 長いガイドを段階的に読みたい時

今回のStep Functions実装では以下のように使われた

1. search_cdk_documentation

• "Step Functions Map state filter transform data" を検索
• JSONataの使い方に関するドキュメントを発見

2. search_cdk_samples_and_constructs

• "Step Functions JSONata filter array transform" を検索
• TypeScriptでの実装例を探索

3. read_iac_documentation_page

• https://docs.aws.amazon.com/step-functions/latest/dg/transforming-data.html を読み込み
• JSONataの詳細な使い方とフィルタリング例を取得

最終的に実装されたStackは以下です。

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as sfn from 'aws-cdk-lib/aws-stepfunctions';
import * as logs from 'aws-cdk-lib/aws-logs';

export class OrderProcessingStepFunctionStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const logGroup = new logs.LogGroup(this, 'StateMachineLogGroup', {
      logGroupName: '/aws/vendedlogs/states/order-processing',
      retention: logs.RetentionDays.ONE_WEEK,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    const filterPaidOrders = new sfn.Pass(this, 'FilterPaidOrders', {
      comment: 'Filter orders to include only those with status=PAID',
      parameters: {
        'paidOrders.$': "$.orders[status='PAID']",
      },
    });

    const calculateTotal = new sfn.Pass(this, 'CalculateTotal', {
      comment: 'Calculate the sum of all paid order prices',
      parameters: {
        'paidOrders.$': '$.paidOrders',
        'totalPrice.$': '$sum($.paidOrders[].price)',
      },
    });

    const formatOutput = new sfn.Pass(this, 'FormatOutput', {
      comment: 'Format the final output with all required fields',
      parameters: {
        'paidOrders.$': '$.paidOrders',
        'totalPrice.$': '$.totalPrice',
        'orderCount.$': '$count($.paidOrders)',
      },
    });

    const definition = filterPaidOrders
      .next(calculateTotal)
      .next(formatOutput);

    const stateMachine = new sfn.StateMachine(this, 'OrderProcessingStateMachine', {
      stateMachineName: 'OrderProcessingStateMachine',
      definitionBody: sfn.DefinitionBody.fromChainable(definition),
      logs: {
        destination: logGroup,
        level: sfn.LogLevel.ALL,
        includeExecutionData: true,
      },
      tracingEnabled: true,
    });

    new cdk.CfnOutput(this, 'StateMachineArn', {
      value: stateMachine.stateMachineArn,
      description: 'ARN of the Order Processing State Machine',
      exportName: 'OrderProcessingStateMachineArn',
    });

    new cdk.CfnOutput(this, 'StateMachineName', {
      value: stateMachine.stateMachineName,
      description: 'Name of the Order Processing State Machine',
      exportName: 'OrderProcessingStateMachineName',
    });
  }
}

コード解説

FiterPaidOrdersステート

const filterPaidOrders = new sfn.Pass(this, 'FilterPaidOrders', {
  comment: 'Filter orders to include only those with status=PAID',
  parameters: {
    'paidOrders.$': "$.orders[status='PAID']",
    //         ↑ .$サフィックス = JSONPath式として評価
  },
});

JSONPath式: "$.orders[status='PAID']"

• $ = 入力データのルート
• .orders = ordersフィールドにアクセス
• [status='PAID'] = statusが'PAID'の要素のみをフィルタ

動作

// 入力
{
  "orders": [
    {"orderId": "1", "status": "PAID", "price": 100},
    {"orderId": "2", "status": "PENDING", "price": 50},
    {"orderId": "3", "status": "PAID", "price": 200}
  ]
}

// 出力
{
  "paidOrders": [
    {"orderId": "1", "status": "PAID", "price": 100},
    {"orderId": "3", "status": "PAID", "price": 200}
  ]
}

CalculateTotal ステート

const calculateTotal = new sfn.Pass(this, 'CalculateTotal', {
  comment: 'Calculate the sum of all paid order prices',
  parameters: {
    'paidOrders.$': '$.paidOrders',
    //         ↑ 前のステートの出力を参照
    'totalPrice.$': '$sum($.paidOrders[].price)',
    //         ↑ JSONata集約関数を使用
  },
});

JSONata式: '$sum($.paidOrders[].price)'

• $sum() = JSONata集約関数（合計を計算）
• $.paidOrders[] = paidOrders配列の全要素
• .price = 各要素のpriceフィールドを抽出

動作

// 入力
{
  "paidOrders": [
    {"orderId": "1", "status": "PAID", "price": 100},
    {"orderId": "3", "status": "PAID", "price": 200}
  ]
}

// 出力
{
  "paidOrders": [...],
  "totalPrice": 300  // 100 + 200
}

FormatOutput ステート

const formatOutput = new sfn.Pass(this, 'FormatOutput', {
  comment: 'Format the final output with all required fields',
  parameters: {
    'paidOrders.$': '$.paidOrders',
    'totalPrice.$': '$.totalPrice',
    'orderCount.$': '$count($.paidOrders)',
    //         ↑ JSONata関数で配列の長さを取得
  },
});

JSONata式: '$count($.paidOrders)'

• $count() = JSONata関数（配列の要素数を返す）
• $.paidOrders = paidOrders配列を参照

動作

// 入力
{
  "paidOrders": [
    {"orderId": "1", "status": "PAID", "price": 100},
    {"orderId": "3", "status": "PAID", "price": 200}
  ],
  "totalPrice": 300
}

// 出力
{
  "paidOrders": [...],
  "totalPrice": 300,
  "orderCount": 2  // 配列の長さ
}

まとめ

今回は、Build AWS infrastructure with CDK and CloudFormation というKiro Powersを使ってみました。ベストプラクティスをもとに実装を進めてくれるので、AWS関連のタスクを行うのに最適だなと思いました。また、チャットを見て、Kiro Powersが調査したものをもとに勉強すると、AIを使いながら、成果を出しながら、勉強しながらやっていけるのではないかと思いました。これからもっと使っていきたいと思います！

1. SaaSus API MCP Serverとは

SaaSus API MCP Serverは、SaaSus Platformが提供する各種APIをMCP経由で利用可能にするサーバー実装です。
開発者は MCP 対応クライアント（Claude Desktop / Cursor / Roo Code）から、SaaSus の API に直接アクセスできます。
これにより、SaaS開発における操作や確認を、コードベースではなく対話的に行うことが可能になります。

2.インストール手順

参考: SaaSus API MCP Server セットアップガイド

2.1. リポジトリをクローン

git clone https://github.com/saasus-platform/saasus-api-mcp-server.git
cd saasus-api-mcp-server

2.2. 依存パッケージをインストール

npm install

3. AIエージェントでの設定

Claude Desktop、Cursor、Roo Code などの MCP 対応クライアントに SaaSus API MCP Server を追加します。

3.1. nodeのパスを確認

環境変数やシェルで Node.js が利用可能か確認します。

which node

3.2. mcpServer.jsのパスを確認

saasus-api-mcp-server ディレクトリ内の mcpServer.js ファイルの絶対パスを取得します。

realpath mcpServer.js

3.3. SaaSus Platform のAPIキー情報の取得

SaaSus Platformより以下のキー情報を取得します。

• SAASUS_PLATFORM_SAASID: SaaS ID
• SAASUS_PLATFORM_APIKEY: API キー
• SAASUS_PLATFORM_SECRETKEY: シークレットキー

3.4.  MCP Server の設定

ここでは Roo Code を例に設定を行います。

VS Codeを開き、拡張機能でインストールした Roo Code を起動します。
右上の 3点リーダー（⋯）メニュー から 「MCPサーバー」 をクリックします。

「MCPサーバーメニュー」が開いたら、「グローバルMCPを編集」 を選択します。

エディタに表示された mcp_settings.json を以下のように編集します。

{
  "mcpServers": {
    "saasusapis": {
      "command": "node",
      "args": ["/path/to/mcpServer.js"],
      "env": {
        "SAASUS_PLATFORM_SAASID": "your_saas_id",
        "SAASUS_PLATFORM_APIKEY": "your_api_key",
        "SAASUS_PLATFORM_SECRETKEY": "your_secret_key"
      }
    }
  }
}

保存後、「saasusapis」が追加されたことを確認し、完了ボタンをクリックして設定を終了します。

4. 実行

設定が完了したら、AIエージェントで以下のように入力してみてください。
SaaSus Platformの設定情報を取得してください

実行すると、エージェントが自動的に解析を行い、SaaSus API MCP Server 経由で SaaSus Platform API を呼び出して設定情報を取得します。
このように、プログラムコードを書かずに自然言語でAPI操作が行えます。

5. SaaSus Platform の実行サンプル

SaaSus Platform では、MCP Server を利用した各種サンプルプロンプトが提供されています。
詳細は以下のドキュメントをご参照ください。
🔗 環境セットアップガイド

ユーザーの一括登録、一覧取得、メータリング情報の取得など、
従来コードで実装していた処理を自然言語で実行できるのが最大の特長です。

まとめ

SaaSus API MCP Serverを利用することで、SaaSus Platform のAPI群をAIエージェントや開発ツールから直接操作できるようになります。
API仕様やトークン設定に煩わされることなく、自然言語による直感的な開発体験を実現します。

ぜひ一度試してみてください。

最近、Amazon Q Developerと Kiro CLI が統合されました。そこで今回、性能を測るためにKiro CLI と GitHub Copilot CLI を同じ条件下でベンチマーク比較してみました。

本記事では、5つの段階的難易度のCDKタスクを両CLIに解かせ、LLM-as-a-Judge（LLMによる自動評価）を用いて定量的・定性的に比較した結果をまとめます。

背景：なぜ比較しようと思ったか

AWS開発では、Q devやKiroが有名ですが、逆に以下の疑問が生まれました。

• その他のAI CLIツールで同じLLM（Claude Sonnet 4.5など）を使った場合、推論層（RAG・システムプロンプト等） の違いだけでどれだけ性能が変わるのか？
• AWS CDK という「抽象化された IaC」において、どちらのツールが「CDK らしい書き方」を生成するのか？

Kiro CLI は .kiro/steering/ ディレクトリでプロジェクト固有の規約を注入でき、GitHub Copilot CLI は「カスタムインストラクション」や GitHub Spaces を通じたナレッジ管理が可能です。つまり、モデル性能ではなく、ツール設計の差 を純粋に見たかったのが背景です。

検証手法

1. 前提条件：同一モデルの使用

公平性を担保するため、両CLIとも Claude Sonnet 4.5 を統一して使用しました。これにより、「学習段階などのモデルの違い」ではなく「推論層の違い」だけを抽出できます。

2. 評価方法：LLM-as-a-Judge

生成されたコードの品質を人間が一つずつレビューするのは時間がかかるため、LLM-as-a-Judge（LLMによる自動評価）を採用しました。

Judge構成

• プライマリJudge: Gemini 3.0
• セカンダリJudge: GPT-5.1

単一のJudgeだと評価観点にバイアスが出るため、2つの異なるモデルで評価し、結果の一貫性を確認しました。

評価フレームワーク（4軸）

各コードを以下の4軸で採点しました。

総合スコア計算式：

Total = (機能的正確性 × 0.35) + (AWSベストプラクティス × 0.25)

+ (コード品質 × 0.20) + (完全性 × 0.20)

Chain-of-Thought（CoT）による説明可能性

CoTと呼ばれるLLMに思考過程を明示させる推論手法があるのですが、今回それも用いました。

各Judgeには、スコアだけでなく 「なぜその点数なのか」という理由 も出力させます。これにより、単なる数値比較ではなく、「どこが強くてどこが弱いか」という定性的な傾向も把握できます。

3. 解かせたタスク（5段階の難易度設定）

AWS CDK（TypeScript）で、以下の5つのタスクを設計しました。

各タスクには明確な「要件」「成功基準」「セキュリティ要件」を定義し、両CLIに同じプロンプトを投入しました。

検証結果

総合スコア比較

両Judge（Gemini 3.0 / GPT-5.1）による評価結果の平均は以下の通りです。

Gemini 3.0 による評価

GPT-5.1 による評価

結果の解釈

• 両Judgeともに Copilot がやや優位（Gemini: +0.27点、GPT-5.1: +1.78点）
• Gemini 3.0 は「ほぼ互角」と評価し、GPT-5.1 は「Copilot が明確に上」と評価
• Judge間の評価傾向の違いは、後述の「気づき・学び」で詳しく考察します

タスクごとの特徴と傾向

タスク1：API Gateway + Lambda（簡単）

要件: GET /hello で {"message": "Hello from CDK"} を返すAPI

評価傾向:

• Kiro: シンプルで動作確実だが、API URL の出力やレスポンスヘッダー設定が省略
• Copilot: CfnOutput でAPI URLを出力し、レスポンスヘッダー（Content-Type）も明示。開発者体験（DX）が高い

コメント: 基本タスクでは両者ともほぼ満点だが、Copilot は「使いやすさ」まで配慮している印象。

タスク2：To-Doアプリバックエンド（中級）

要件: POST /todos でアイテム作成、GET /todos/{id} で取得

評価傾向:

• Kiro: AWS SDK（v2）の低レベルAPIを使用。エラーハンドリングは最小限
• Copilot: AWS SDK v3（@aws-sdk/lib-dynamodb）を使用し、DocumentClient でモダンな実装。エラーログ・ID自動生成も実装

コメント: Copilot は「実務で使える」レベルまで仕上げる傾向。Kiro はシンプルだが、エラーケースの考慮がやや薄い。

タスク3：セキュアなDB接続（中上級）最も差が出たタスク

要件: VPC + Aurora Serverless v2 + Lambda、Secrets Manager でDB認証情報管理

評価傾向:

• Kiro: CDKネイティブな書き方（抽象化）
• .connections.allowFrom() で1行でSG設定完了
• Credentials.fromGeneratedSecret() でSecretsを自動生成＆紐付け
• コード行数: 約40行
• Copilot: Terraform的な書き方（明示的）
• SecurityGroup を個別に定義し、addIngressRule() で手動設定
• Secrets Manager を先に作成し、RDSに渡す
• コード行数: 約90行

具体例（コード比較）:

Kiro のコード（抜粋）

typescript

// Lambda から RDS への接続許可（1行で完結）

dbCluster.connections.allowFrom(lambdaFn, ec2.Port.tcp(5432));

// シークレット自動生成＆紐付け

credentials: rds.Credentials.fromGeneratedSecret('dbadmin'),

Copilot のコード（抜粋）

typescript

// SecurityGroup を個別に作成

const lambdaSg = new ec2.SecurityGroup(this, 'LambdaSecurityGroup', { vpc, ... });

const dbSg = new ec2.SecurityGroup(this, 'DatabaseSecurityGroup', { vpc, ... });

// Ingress Rule を手動で追加

dbSg.addIngressRule(lambdaSg, ec2.Port.tcp(5432), 'Allow Lambda access');

// Secrets Manager を先に定義

const dbCredentials = new secretsmanager.Secret(this, 'DatabaseCredentials', { ... });

credentials: rds.Credentials.fromSecret(dbCredentials),

コメント:
Kiro は 「CDKを使うメリット（抽象化による記述量削減）」 をフル活用。Copilot は 「丁寧で明示的だが、Terraform的」 な実装。どちらも動作するが、CDKの思想に沿っているのは Kiro。

タスク4：イベント駆動型注文処理（上級）

要件: EventBridge → Lambda A → DynamoDB → Stream → Lambda B → DLQ（SQS）

評価傾向:

• Kiro: インフラ構成は正確だが、Lambda A が DynamoDB に書き込むロジックが未実装（要件未達）
• Copilot: イベント受信→DB書き込み→Stream処理まで、アプリケーションロジックも実装

コメント: Copilot は「指示以上のこと」をしてくれる一方、Kiro はインフラ構成に特化。実務では「どこまで書くか」の判断が分かれる。

タスク5：本番CI/CD + 監視（エキスパート）

要件: CDK Pipeline + GitHub連携 + CloudWatch Dashboard + Alarm

評価傾向:

• Kiro: 要件は満たすが、アラーム設定（EvaluationPeriods: 1）が誤検知を起こしやすい設定
• Copilot: treatMissingData や詳細メトリクス有効化など、運用視点の設定が充実。Dashboard URLも出力

コメント: 本番運用を見据えた設定の丁寧さでは Copilot が優位。

全体的な傾向まとめ

Copilot の特徴：なんでも・張り切り屋

• エラーハンドリング、ログ出力、ID自動生成など、「実際に動かす」ために必要な周辺実装まで含める
• CfnOutput でエンドポイントURLやARNを出力し、運用者の利便性を考慮
• 指示以上のことをしてくれるが、コード行数が増える傾向

Kiro の特徴：簡潔・AWSネイティブ・インフラ設計者向け

• CDKの抽象化機能（.connections, fromGeneratedSecret）を最大限活用
• 記述量が少なく、「意図」だけを書くコードスタイル
• インフラ構成に特化し、アプリロジックは最小限

気づき・学び

1. LLM-as-a-Judge の難しさ

今回、評価自動化のためにLLM-as-a-Judgeを採用しましたが、以下の課題に直面しました。

データセット設計の難しさ

• 「何が正解か」を定義するのが難しい（特にコード品質や完全性）
• タスクが適切に性能を測れる設計になっているか、事前検証が必要
• 今回は簡単に5タスクだけだったが、より大規模なベンチマークには数十〜数百のタスクが必要

LLMのバイアス

• 位置バイアス: 「最初に出てきたコードを優遇する」傾向がある
• 長さバイアス: コード行数が多い方を「丁寧」と評価しがち

今回は、2つの異なるJudge（Gemini / GPT-5.1） を置くことで、単一Judgeの評価観点バイアスを軽減しました。

2. 評価観点の違い：Gemini vs GPT-5.1

同じコードに対して、2つのJudgeは異なる観点で評価していました。

• Gemini 3.0: 「CDKの抽象化をどれだけ使っているか」を重視
  → タスク3で Kiro を高く評価
  
• GPT-5.1: 「実運用で使えるか（エラーハンドリング、出力情報、監視）」を重視
  → 全タスクで Copilot を高く評価
  

この違いは、「何をもって良いコードとするか」という価値観の違い を反映しています。

3. スコアリング実装の失敗と学び

実は当初、Judgeに「総合スコアも計算して出力してほしい」と指示していましたが、

• Gemini 3.0 は重み付けを無視して「素点の合計」を出力
• GPT-5.1 は計算式と理由テキストが矛盾

という事態が発生しました。

対策: Judgeには 軸スコアだけ を出力させ、総合スコア計算は自前のスクリプトで実行する方針に切り替えました。

これは 「LLMに任せすぎると、検証できない数値が混入する」 という重要な教訓です。

4. Kiro vs Copilot の使い分け

今回の検証から、以下の使い分けが見えました。

個人的には、より実務レベルの複雑なタスクになると、「指示以上のことを勝手にしてしまう」Copilot よりも、「意図だけを簡潔に表現する」Kiro の方が扱いやすい と感じました。

注意事項

本検証結果は、以下の条件下での結果であり、今後変わる可能性があります。

• 使用モデル: Claude Sonnet 4.5
• タスク: 比較的シンプルなCDKタスク5問
• 評価方法: LLM-as-a-Judge（Gemini 3.0 / GPT-5.1）

より大規模で実務的なタスク、あるいは異なるモデル・バージョンでは結果が変わる可能性があります。

まとめ

Kiro CLI と Copilot CLI を、同一モデル（Claude Sonnet 4.5）・同一タスクで比較した結果、

• 総合スコアだけでは Copilot がやや優位（特に実務的な完成度で評価）
• Kiro は CDK抽象を活用した簡潔なコードで優位
• 用途によって使い分けが重要

という結論に至りました。

また、LLM-as-a-Judge を用いた自動評価には多くの課題（データセット設計、バイアス、スコア計算の信頼性）があり、複数Judge + 軸スコア分離 + 自前集計 という設計が重要であることも学びました。

今後も、AI開発ツールの進化に合わせて、継続的にベンチマークを更新していきたいと思います。

POSSEでエンジニアインターンをしている吉川唯音です。本記事では「AWSの料金や利用状況をSlackから簡単に確認する方法」について書いていこうと思います。

こちらの記事で作成したアプリケーションの料金状況について、実際に確認してみます。

NotionデータベースをAIに渡して振り返りをしてみる

POSSEでエンジニアインターンをしている吉川唯音です。普段から「コードレビューでいただいた内容をNotionデータベースに入れて振り返る」ということをしているのですが、より効率的で、面白い振り返りを実現したいと考え、今回のアプリケーションを作成しました。 現状の課題感 1. 振り返りの内容に偏りがある 2. 副産物的な学習が少ない 3. ぱっと振り返れない内容のものがある これらの課題を、Amazon Bedrockを活用したWebアプリで解決しました。 アプリケーションのイメージ： * ユーザーが振り返りボタンを押す * Notionデータベースの内容を取得する *…

Anti-Pattern Inc. Engineering BlogGhost

AWSサービスを利用する

What is Amazon Q Developer in chat applications? - Amazon Q Developer in chat applications

Use Amazon Q Developer in chat applications to send AWS service notifications to chat channels in Slack, Microsoft Teams, and Amazon Chime.

Amazon Q Developer in chat applications

こちらのサービスを利用することで、簡単に「SlackからAmazon Q Developerに質問する仕組み」をセットアップすることができます。

セットアップ方法

以下の3ステップで簡単に設定できます。

• クライアントを設定する（Slack連携）
• チャンネル設定を作成する
• AIMロールを設定する

①クライアントを設定する

サービスを検索します。

チャットクライアントをSlackに設定した後、「クライアントを設定」をクリックします。

以下のページに進むため、Amazon Q Developerを追加したいSlackワークスペースのURLを入力します。

コンソールにワークスペースが追加されたら、Slack連携は完了です。Slackにも自動でアプリとして追加されます。

②チャンネル設定を作成する

設定済みのチャンネルの欄から「新しいチャンネルを設定」をクリックします。そして設定の名前を入力します。また、Q devを追加したいチャンネルを選択します。

下にスクロールして、詳細な許可を設定します。IAMロールもこの画面から新規作成します。

③IAMロールを設定する

最後に、Q devが料金状況にアクセスできるようAIMロールにポリシーをアタッチする必要があります。IAMロールから、その場で作成したtest-qdevを見つけます。

そしてポリシーをアタッチを選択し、請求を追加します。

これで設定は完了です！

実際にSlackから確認してみる

Slackで対象のチャンネルにて@Amazon Qを使用すると、コンテンツを元にQ devがAWSの情報を取得・計算を始めます。

また以下のような詳細なデータが返却されました。

また、マネージメントコンソール上の該当月の金額とも一致していることが確認できました！

まとめ

今回はSlackからAWSの料金情報を確認してみましたが、権限によっては他のリソースの状況取得や、起動や停止まで行うことができます。そのため、例えば「STGへのデプロイをSlackから指示できる」ように、より簡単にAWSを操作できる仕組みを構築できると思います。

難しいことをシンプルに、面白いサービスだなと感じました！

]]>https://tech.anti-pattern.co.jp/kiro-x-slackdeshi-yang-nosurihe-wasewojian-dan-ni/Ghost__Post__692ccaae71fa390001b355dcMon, 01 Dec 2025 09:29:39 GMT

はじめに

プロダクト開発では、PO・エンジニア・デザイナーなど複数のステークホルダー間で仕様の認識を揃えることが不可欠です。認識が揃っていないまま開発が進むと、手戻りによるスケジュール遅延や、考慮漏れによる品質低下につながります。しかし、多忙なチームではミーティングの頻度を上げることが難しく、週に一度程度しか全員が揃わないケースも珍しくありません。そうした環境では、ミーティング後に仕様の抜け漏れに気づいても、すぐに追加のミーティングを設定できず、Slack 上で補足の議論を行うことになります。

そこで、なるべくミーティング中に仕様の認識を揃えられるよう、Slack のスレッド内で /kiroコマンドを実行するだけで、スレッドの文脈から構造化された仕様書の叩き台を自動生成できる Bot を考案しました。本記事では、技術選定や実装の詳細について説明します。

概要

アーキテクチャ

各コンポーネントの役割

1. Slack App

• /kiro Slash Command を設定し、ALB のエンドポイントへ POST
• スレッドでコマンドを実行すると Slack が自動で thread_tsを付与

2. Internet Gateway + Application Load Balancer

• Internet Gateway: VPC とインターネット間の通信を可能にする
• ALB: Public Subnet に配置されインターネットからのリクエストを受け付ける
• 受信したリクエストを Private Subnet の Fargate タスクへ転送

3. Fargate

• Hono + Node.js サーバーを常駐
• Slash Command の処理から Kiro CLI 呼び出し、Slack API への返信までを同期的に実行

4. Amazon EFS

• /root/.kiro をマウントし、Kiro CLI の認証情報を永続化
• タスク再起動後もログインが不要

5. NAT Gateway

• Private Subnet の Fargate から **アウトバウンド通信** を可能にする
• Slack Web API (`conversations.replies`, `chat.postMessage`) へのアクセスに使用

6. Kiro CLI

• kiro-cli-chat を --no-interactiveオプションで起動
• スレッドの文脈 + 追加指示を含むプロンプトを渡して仕様書を生成

7. Slack Web API

• conversations.repliesでスレッドの文脈を取得
• 生成された仕様書を chat.postMessageで同じスレッドに返信

実装

Slash Command ハンドラ

app.post('/slack/commands', async (req, res) => {
  const payload = parseSlackPayload(req.body);

  if (!payload.thread_ts) {
    return res.json({
      response_type: 'ephemeral',
      text: 'このコマンドはスレッド内で実行してください'
    });
  }

  // スレッドの文脈を取得
  const slackClient = new WebClient(process.env.SLACK_BOT_TOKEN);
  const messages = await fetchThreadMessages(
    slackClient,
    payload.channel_id,
    payload.thread_ts
  );

  // Kiro CLI 用のプロンプトを構築
  const context = formatThreadContext(messages);
  const prompt = buildSpecificationPrompt(context, payload.text);

  // Kiro CLI で仕様書を生成（同期処理）
  const spec = await generateSpecification(prompt);

  // 同じスレッドに返信
  await slackClient.chat.postMessage({
    channel: payload.channel_id,
    thread_ts: payload.thread_ts,
    text: spec,
    mrkdwn: true,
  });

  // 処理完了後に 200 を返す
  res.json({
    response_type: 'ephemeral',
    text: '仕様書を生成しました'
  });
});

• Fargate 上で常駐するため、Slash Command のレスポンス前に仕様生成まで完了できる
• thread_tsが無い場合はエラーを返し、運用ルールとして「スレッドで /kiro を実行する」ことを徹底

Kiro CLI 呼び出し

async function generateSpecification(prompt: string): Promise<string> {
  return new Promise((resolve, reject) => {
    const cli = spawn('/usr/local/bin/kiro-cli-chat', [
      'chat',
      '--no-interactive',
      '--wrap=never',
      prompt,
    ], {
      env: { ...process.env, HOME: '/root' },
    });

    let output = '';
    cli.stdout.on('data', (data) => {
      output += data.toString();
    });

    cli.on('close', (code) => {
      if (code === 0) {
        const cleanOutput = stripAnsiCodes(output);
        const spec = extractSpecification(cleanOutput);
        resolve(spec);
      } else {
        reject(new Error(`Kiro CLI failed with code ${code}`));
      }
    });
  });
}

• HOMEを EFS のマウント先に設定し、認証状態を共有
• CLI からの出力は ANSI コードを削除してから Slack へ投稿

EFS への認証情報マウント

CloudFormation設定

MountPoints:
  - SourceVolume: kiro-auth
    ContainerPath: /root/.kiro
    ReadOnly: false

Volumes:
  - Name: kiro-auth
    EFSVolumeConfiguration:
      FilesystemId: !Ref KiroAuthFileSystem
      TransitEncryption: ENABLED
      AuthorizationConfig:
        AccessPointId: !Ref KiroAuthAccessPoint

初回ログイン

# ECS Exec でコンテナに接続
aws ecs execute-command \
  --cluster slack-spec-bot-fargate \
  --task <task-id> \
  --container app \
  --interactive \
  --command "/bin/bash"

# Kiro CLI にログイン
kiro-cli-chat login --use-device-flow

初回のみ kiro-cli-chat login --use-device-flowを実行すれば、その後は再ログインが不要になります。

つまづいたポイント

Bad file descriptorエラー: EFS × flock

最大のハマりどころは Kiro CLI が設定ファイルを flock しようとして EFS で失敗する点でした。

用語

• Bad file descriptor: ファイルの扱い方が間違っているというエラーメッセージ。
• EFS (Amazon Elastic File System): AWS が提供する、ネットワーク経由で使えるファイルストレージ。複数のサーバーから同じファイルにアクセスできる便利なサービス。
• flock（ファイルロック）: 複数のプログラムが同時に同じファイルを書き換えないようにする仕組み。「今このファイルは自分が使っているから、他の人は待ってね」という札を立てるイメージ。

何が起きたのか

「EBADF error (Bad file descriptor) 」が発生しました。これは、Kiro CLI（コマンドラインツール）が Amazon EFS 上でファイルをロック（占有）しようとした時に起きる問題です。

なぜ起きたのか

• flockはLinuxのファイルロック機能で、BSDロックと呼ばれる方式。プロセスAがflockを呼び、カーネルがファイルにロック済みマークをつけると、プロセスBはプロセスAがファイルを閉じるかロックを解除するまで待たなければならない。この仕組みはローカルのカーネル内で完結する。
• NFS（Network File System) はネットワーク越しにファイルを共有する仕組み。複数のサーバーが同じファイルにアクセスできる。

Amazon EFS は NFSv4.1 ベースで、POSIX 的な fcntlロック（byte-range locks）はサポートしますが、Linux カーネル側での flock() の扱いはローカル FS と同一とは限りません。今回の環境では、ローカルディスク上では問題なく動いていた同じコードが、EFS 上のファイルに対してだけ flock(fd, LOCK_EX) で EBADF を返す挙動になっていました。

内部実装までは追いきれていませんが、少なくとも「EFS 上の設定ファイルを直接 flock する」前提では Kiro CLI を安定稼働させられない、ということがわかりました。

対処法

対処法は「flockを使わないよう CLI を修正する」か「対象ファイルを NFS 以外（tmpfs やローカル）へ移す」のどちらかです。今回は後者を選択し、EFS → /tmpへコピーして CLI を実行しています。

Node.js サービス内で次のような仕組みを入れ、CLI からは常にローカルファイルシステムを参照させています。

// 起動時
await initializeKiroHome(); // /root/.kiro → /tmp/kiro-local をコピー
process.env.KIRO_HOME = '/tmp/kiro-local';

// CLI 実行後
await syncKiroHomeToPersistent(); // /tmp → /root/.kiro を再同期

これで flockの対象が EFS からローカルに変わり、Bad file descriptor が消えました。

実際の動作

Slack内での仕様の相談をイメージして実演してみました。

Slackへの投稿

スレッドで会話

/kiroを実行

Kiroによる仕様書の叩き全文

# リアルタイム分析ダッシュボード 仕様書

## 機能概要
スプリント中のチームがKPIをリアルタイムで追跡できる分析ダッシュボードを管理画面に追加します。カード型ウィジェットで主要指標を可視化し、チーム・リージョン・期間でフィルタリング可能。閾値超過時にはSlack通知を送信します。

## ゴール / 非ゴール

### ゴール
- チームメンバーがスプリント中にKPIを一目で把握できる
- 1分以内の遅延でリアルタイムにデータを更新する
- チーム/リージョン/期間の組み合わせでフィルタリングし、検索条件を保存できる
- エラー率などの重要指標が閾値を超えた際に自動でSlack通知を送る
- 将来的に新しいKPIを追加しやすい拡張可能な設計にする

### 非ゴール
- 過去データの詳細分析やレポート出力機能（既存の分析ツールで対応）
- ダッシュボードのカスタマイズ機能（ウィジェットの並び替えや追加/削除）
- リアルタイム通知以外のアラート手段（メール、SMS等）

## ユーザーストーリー
- **As a** プロダクトマネージャー, I want スプリント中のKPIをリアルタイムで確認できる, so that 迅速に意思決定し、問題に早期対応できる
- **As a** 開発チームリーダー, I want 自分のチームだけのデータにフィルタリングできる, so that チーム固有のパフォーマンスを追跡できる
- **As a** βテスター, I want よく使うフィルタ条件を保存できる, so that 毎回同じ条件を入力する手間を省ける
- **As a** オペレーションチーム, I want エラー率が閾値を超えたらSlackで通知を受け取る, so that 即座に障害対応を開始できる

## 画面・フロー

### 画面構成
管理画面
└── Analytics タブ（新規追加）
    ├── フィルタエリア
    │   ├── チーム選択（ドロップダウン）
    │   ├── リージョン選択（ドロップダウン）
    │   ├── 期間選択（日付ピッカー）
    │   └── 保存ボタン / 保存済み条件ロード
    └── KPIカードエリア（グリッドレイアウト）
        ├── DAU カード
        ├── セッション長 カード
        ├── エラー率 カード（閾値超過時バッジ表示）
        └── 完了率 カード

### 操作フロー
1. ユーザーが管理画面の「Analytics」タブをクリック
2. デフォルトで全チーム・全リージョン・直近24時間のKPIが表示される
3. フィルタを変更すると、リアルタイムでカードが更新される
4. 「保存」ボタンでフィルタ条件を保存（ローカルストレージまたはユーザー設定API）
5. 次回訪問時に保存済み条件をロード可能
6. エラー率が閾値を超えると、カードにバッジが表示され、Slack通知が送信される

## API / データモデル

### APIエンドポイント
GET /api/analytics/kpis
  Query params: team_id, region, start_date, end_date
  Response: { dau, avg_session_length, error_rate, completion_rate, last_updated }
GET /api/analytics/filters
  Response: { saved_filters: [...] }
POST /api/analytics/filters
  Body: { name, team_id, region, date_range }
  Response: { filter_id }
WebSocket /ws/analytics
  Subscribe: { team_id, region }
  Push: KPI更新イベント

### データフロー
Kafka イベント → Redis（キャッシュ） → API → WebSocket → フロントエンド（SWR）
                                      ↓
                                  閾値チェック → Slack Webhook

### データモデル（Redis）
Key: analytics:{team_id}:{region}:{date}
Value: {
  dau: number,
  avg_session_length: number,
  error_rate: number,
  completion_rate: number,
  updated_at: timestamp
}

### 設定管理（config）
yaml
thresholds:
  error_rate: 5.0  # パーセント
  completion_rate: 80.0
slack:
  webhook_url: <WEBHOOK_URL>
  channel: "#alerts"

## オープンな論点
1. フィルタ条件の保存先: ユーザー設定をローカルストレージに保存するか、バックエンドのユーザープロファイルAPIで管理するか？複数デバイス間での同期が必要か？
2. KPIの優先順位と初期表示: 4つのKPI（DAU、セッション長、エラー率、完了率）以外に初期リリースで追加すべき指標はあるか？カードの表示順序に優先度はあるか？
3. 閾値の設定権限: エラー率などの閾値は誰が設定・変更できるべきか？管理者のみか、チームリーダーも変更可能にするか？UI上で変更可能にするか、config管理のみか？
4. Slack通知の頻度制御: 同じ閾値超過が継続する場合、通知を何分おきに送るか？通知の重複を防ぐクールダウン期間は必要か？
5. リージョンとチームの定義: 「リージョン」と「チーム」の具体的な値はどこから取得するか？既存のユーザー管理システムやプロジェクト管理ツールと連携するか、新規にマスタデータを作成するか？

まとめ

今回は、Slack と Kiro を組み合わせ、Slack のスレッド内で /kiro コマンドを実行するだけで、そのスレッドの文脈から構造化された仕様書の叩き台を自動生成できる Bot を設計しました。
この仕組みにより、Slack 上の議論から即座に仕様化へ移行できる体験を実現できました。
一方で、Kiro を継続的に利用するためには Fargate・ALB・EFS・NAT Gateway などの常駐インフラが必要となり、運用コストが高くなる点が懸念として残ります。今後は、より軽量かつ低コストで運用できるアーキテクチャ（API Key ベースの認証提供や、Lambda での実行が可能になる構成）を検討していきたいと思います。

わたしはAmazon Q Developerの頃から使っていたのですが、あるとき突然こんなお知らせが。

q updateを打つと、Kiroちゃんに進化し、大変可愛くなりました！qでもkiro-cliでも認識するようです。

Kiro CLIはAmazon Q Developerの機能を引き継いでおり、従来通り様々な用途で使えることでしょう。

AWSアカウント上での作業を任せたり、Webアプリを開発したり、日常の質問をしたり…

そんな中、私が個人的に嬉しかったアップデートは、Web検索機能の追加でした。

Web検索機能なかったっけ？

そうなんです、実はAmazon Q Developer時代には、Web検索機能が標準で搭載されていませんでした。

素の実力が高いということなのか、AWS CLIの操作などは自力で頑張ってくれるものの、以下のようなときに歯痒い思いをしていました。

• 最近リリースされたサービスについて調べて欲しいとき
• インストールしたいライブラリなどの最新バージョンを知りたい時
• エラー文に参考のリンクが含まれており、そこに解決策が書かれているとき

ちょっとしたことなのですが、そのためにMCPサーバーを立てたりするのは面倒だなーと正直思っていました。

Web検索 Powered Kiro CLI

kiro-cli に、以下のように聞いてみます。

最近発表されたAWSのアップデートで気になるものをピックアップしてください。

そうすると、以下のように返してきてくれます。

最近のAWSアップデートで注目すべきものをピックアップしました：

Lambda関連の大型アップデート（11月中旬）
- **Rust言語の正式サポート** - Lambda関数でRustが一般提供開始。ランタイムインターフェースクライ
アントがバージョン1.0.0に昇格
- **Java 25のサポート** - Lambda関数の効率性が向上
- **Swift用の実験的ランタイムインターフェースクライアント** - Swiftでのサーバーレス開発が可能に
- **SQSイベントソースマッピングのProvisioned Mode** - トラフィックスパイクへの対応とスループット
最適化が可能に

セキュリティ・アクセス管理
- **S3バケット向けABAC（属性ベースアクセス制御）** - タグベースのポリシーで権限を自動管理。IAMポ
リシーの頻繁な更新が不要に
- **IAM Outbound Identity Federation** - 外部サービスへの認証に短期間のJWTを使用可能。APIキーや
パスワードの保存が不要に
- **VPC暗号化コントロール** - VPC内およびVPC間のトラフィック暗号化を監査・強制可能に

インフラ・ネットワーク
- **Route 53 Accelerated Recovery** - バージニア北部リージョンでの障害時に60分のRTOを提供。重要
なDNS変更が継続可能
- **Network Load BalancerがQUICプロトコルをサポート** - モバイルアプリケーションのレイテンシを25
-30%削減
- **Application Load BalancerがJWT検証をサポート** - マシン間通信のセキュリティ実装が簡素化

開発者ツール
- **Kiro（AIコーディングツール）が一般提供開始** - プロパティベーステスト、チェックポイント機能
、Kiro CLI、エンタープライズチームプランを追加
- **Step Functionsのローカルテスト機能強化** - モック対応、個別ステートテスト、AWSデプロイ不要で
のテストが可能に
- **Amazon ECS Express Mode** - 単一コマンドでコンテナアプリケーションのデプロイを自動化

その他
- **Amazon DCV for EC2 Mac** - 4K解像度・60FPSでのリモートデスクトップアクセス
- **Amazon Linux 2023の最新版** - Mountpoint for S3、Swift 6.2.1、Node.js 24を含む
- **EventBridge拡張ビジュアルルールビルダー** - イベント駆動アプリケーション開発を簡素化

いいですね、実際に最近あったニュースが並んでいます。
re:Inventが始まって沢山ニュースが出るとまとめるのも大変なので、Kiro CLIに今日のまとめをしてもらうのもいいかもしれないですね！

ところで私はAWS LambdaとRustが大好きです。ということで、Kiro CLIに作ってもらいましょう。

Lambda関数をRustで作成したいです。最新の実装方法を調べ、デプロイまで行ってください。

ここが筆者激推しポイントなのですが、今までは最新の実装方法やライブラリのバージョンは、人間が調べるか他のAIサービスで検索して渡していたところを、Kiro CLIで完結できるのがかなり楽です。

ものの3分後、Kiro CLIはこのように告げて実装を終えました。

## デプロイについて

AWS認証情報が設定されていないため、実際のデプロイは実行できませんでしたが、以下のコマンドでデプ
ロイ可能です：

bash
cd rust-hello
cargo lambda deploy

実際にcargo lambda deployを実行すると、以下のように無事Lambda関数が作成されています。

また、試しに関数URLを作成してブラウザで確認したところ、正しくレスポンスを返すことができました。素晴らしい！

感想

今までは、「堅実なAmazon Q Developer」というイメージでいました。

これからは、「新しいことでも壁打ちしながら実現できる、秘書的なKiro CLI」みたいなイメージでしょうか。

Web検索という1つの話で膨らませすぎましたが、鮮度の高いコンテキストを渡せることのインパクトは小さくないなーと思いました。

今回はKiro CLIを使ってみてとても感動したので、ユースケースと一緒にKiro CLIの良さを紹介していきたいと思います。

Kiro CLI (旧Amazon Q Developer CLI)とは

コマンドラインベースのAIエージェントツールです。似たものとしてはGemini CLI, Claude Code, Codexがあります。特徴としてはシームレスな認証ができることやAWS関連の情報がMCPを設定しなくても分かってくれることです。

Kiro CLI の紹介：Kiro エージェントをあなたのターミナルへ | Amazon Web Services

深夜 2 時、本番サーバーに接続してバグをデバッグしています。この一週間、IDEでAIエージェントを使って効率よく開発を進めてきたあなたなら、こんな時こそAIの力を借りたいと思うでしょう。しかし、コンテキストを切り替えるとすると、ターミナルセッションが切れ、SSH 接続も失われ、作業の流れが途切れてしまいます。結局、手動でログを確認し、構文を検索して、一人で格闘することになります。AI が使える IDE で作業するか、実用的だけれど AI サポートのないターミナルで作業するか。本来なら、こんな選択を迫られる必要はないはずです。今回、私たちはそのギャップを解決しました。Kiro CLI なら、A…

Amazon Web Services稲田大陸

Kiro CLI (旧Amazon Q Developer CLI)の権限は？

個人的にKiro CLIの一番使いやすい点が権限設定だと思っています。Kiro CLIの権限はAWS CLIを使う時と変わらず使用することができます。

1. 環境変数から取得
2. AWS IAM Identity Centerでの認証

環境変数から取得

ターミナルでAWS認証情報を環境変数にexportした後、kiro-cliでログインをしてAWS認証情報を聞いてみました。この認証情報はexportした認証情報と同じになりました。

Kiro CLIもAWS CLIと同じく 環境変数 > aws configureのデフォルト設定 の順番で認証情報を探してくれます。

また、Kiro CLIとのチャット中に認証情報を変えてもらうことも可能です。

AWS IAM Identity Centerでの認証

チャットで以下のようにお願いしてみます。

<AWSアカウントID>のAWSアカウントの認証情報を取得してください

いつも通り、aws sso loginでログイン画面で認証をすることで認証情報を取得することができました。次は具体的なユースケースをいくつか紹介したいと思います。

ユースケース1：Codebuildの実行結果をレポートしてもらう

簡略した実行結果は以下です。

> 今日codebuildで失敗したbuildのテナントIDを環境変数から確認して教えて

...

今日失敗したCodebuidのテナントIDは以下の2つです：
1. xxxxxxxxxxxx
2. yyyyyyyyyyyy

実際にはcodebuildの対象プロジェクトを確認して、以下のようなコマンドを実行してまとめてくれています。

統計データも出してくれます。

ユースケース2：Lambdaの修正

Cloudwatchのログ確認、コード修正、CDKのデプロイまでをまとめて実行してくれます。profileを設定する場合やコンテキストの注入も問題なくやってくれました。

ユースケース3: AWSからのAction Requiredの対応調査

AWSから定期的にくる [Action Required] ([要対応])メールの対応調査をする際にも非常に役に立ちました。特にlambdaのruntimeバージョンアップなどはcdkのソースコード上では全量把握できず、aws cliやコンソールから確認する必要がありましたが、Kiro CLIではまとめて行ってくれます。また、CDKによって自動で作ってくれるlambdaのruntimeバージョンアップもcdkのバージョンを確認して行ってくれます。

まとめ

今回紹介したユースケースは全て開発環境で行っているものですが、権限さえ適切にKiro CLIに渡してあげれば他の環境でも利用できると思います。CLI上からAWSの環境が非常に簡単に確認できる体験は開発や運用の負荷を劇的に改善するものになるので、ぜひ使ってみてください！

こんにちは、Anti-Patternの塚本です。
弊社の開発チームでは、生成AIを積極的に活用しています。開発ツールとしてVSCodeを使用しており、開発時はRoo CodeやGitHub Copilotを活用しています。

Roo CodeはVSCode上で動作するAIコーディングアシスタントで、コード生成やリファクタリング、テストコードの自動生成などを支援してくれるツールです。今回は、このRoo Codeを使ってE2Eテストを自動生成する検証を行った際の経験を共有します。

トークン上限エラーとの遭遇

今回、E2Eテストを生成するために、oapi-codegenで生成した以下のファイルをRoo Codeに読み込ませました

• client.gen.go: 15,475行
• types.gen.go: 1,345行

テスト対象となるメソッドは160以上。これらすべてに対してE2Eテストを自動生成しようとしたところ、プロンプトのトークン数がmax値を超えてエラーが発生してしまいました。読み込ませるファイルが大きすぎたのです。

解決策:AIにAI用のツールを作ってもらう

そこで、読み込ませるファイルを適切に分割するシェルスクリプトを、生成AI自身に作ってもらうことにしました。

私が投げたプロンプトは、シンプルにこれだけです

意味ある単位で分割するシェルを作ってください

かなり曖昧な指示でしたが、生成AIはしっかりとしたシェルスクリプトを作成してくれました。何度か修正を重ねる必要はありましたが、最終的に期待通りの動作をするツールが完成しました。

生成されたシェルスクリプト

生成AIが作成してくれたシェルスクリプトは以下のような仕組みになっています

• 特定のパターン(構造体定義、インターフェース定義、関数定義など)を検出
• 各セクションの開始行を特定
• 意味のある単位でファイルを分割

#!/bin/bash

# 使用法: ./split_client_gen.sh <入力ファイル.go>

input_file="$1"
output_dir="client_gen_split_output"

# パターン定義
P_CLIENT_STRUCT_START='^type Client struct'
P_CLIENT_INTERFACE_START='^type ClientInterface interface'
P_CLIENT_METHODS_START='^func \(c \*Client\) GetAuthInfo\('
P_REQUEST_BUILDERS_START='^func NewGetAuthInfoRequest\('
P_APPLY_EDITORS_START='^func \(c \*Client\) applyEditors\('
P_CLIENT_WITH_RESPONSES_STRUCT_START='^type ClientWithResponses struct'
P_CLIENT_WITH_RESPONSES_INTERFACE_START='^type ClientWithResponsesInterface interface'
P_CLIENT_WITH_RESPONSES_METHODS_START='^func \(c \*ClientWithResponses\) GetAuthInfoWithResponse\('
P_RESPONSE_STRUCTS_START='^type GetAuthInfoResponse struct'
P_PARSE_FUNCTIONS_START='^func ParseGetAuthInfoResponse\('

# 各セクションの行番号を検出し、チャンクに分割
# ... (詳細は省略)

完全なスクリプトは記事末尾に掲載しています。

分割結果

シェルスクリプトは、client.gen.goを意味のある単位で以下の11ファイルに分割してくれました

1. 01_preamble.go - パッケージ宣言とインポート
2. 02_client_definition.go - Clientの構造体定義
3. 03_client_interface.go - Clientのインターフェース定義
4. 04_client_methods.go - Clientのメソッド実装
5. 05_request_builders.go - リクエストビルダー関数群
6. 06_apply_editors.go - エディター適用関数
7. 07_client_with_responses_definition.go - ClientWithResponsesの構造体定義
8. 08_client_with_responses_interface.go - ClientWithResponsesのインターフェース定義
9. 09_response_structs.go - レスポンス構造体群
10. 10_client_with_responses_methods.go - ClientWithResponsesのメソッド実装
11. 11_parse_functions.go - パース関数群

今回生成するE2Eテストは、08_client_with_responses_interface.goに定義されている160以上のinterfaceメソッド全てが対象です。

結果

ファイルを分割することで、トークン数の上限を超えることなく、スムーズにE2Eテストの自動生成ができるようになりました！

AI時代のコード設計:発見と気づき

この経験を通じて、個人的にいくつかの気づきがありました

ファイル数は多くても1ファイルは小さく

ファイル数が増えることを恐れず、1ファイルあたりのサイズは小さく保つ方が良いと感じました。AIがコンテキストを理解しやすいようです。

冗長性よりも明確性

人間の視点では「共通化すべき」と思える部分も、あえて冗長なままにしておく方が、AIには理解しやすいようです。

「人間が読みやすいコード」から「AIが理解しやすいコード」へ

これまでの時代、当然ながら人間がコードを書いていたので、「人間が読みやすいコード」を書くことが重要視されてきました。

しかし、AI時代の今、AIにコードを書いてもらうという前提で考えると、むしろ「AIが理解しやすいコード構造」を意識する必要があるのかもしれません。

これは、コード設計の考え方そのものが変わりつつあることを示唆しているように思います。もちろん、最終的には人間がメンテナンスすることも考慮すべきですが、AIとの協働を前提とした新しいベストプラクティスが生まれつつあるのかもしれません。

生成AIにコードを解析させる際のその他の注意点

最後に今回の経験を踏まえて、生成AI(Claude)にプログラムを解析させる際に気をつけるべき点を聞いてみました。多くは一般的なプログラミングのベストプラクティスと重なりますが、4、9、10はAI活用において重要なポイントだと感じました。

1. コンテキストの明示的な提供

• ファイル間の依存関係を明示する
• 使用しているフレームワークやライブラリのバージョンを伝える
• プロジェクト全体の構造を簡潔に説明する

2. 命名規則の一貫性

• 変数名、関数名、型名などの命名を一貫させる
• AIが理解しやすい説明的な名前を使う
• 略語よりも完全な単語を使う方がAIには理解しやすい

3. コメントの活用

• 重要なロジックには日本語/英語でコメントを残す
• AIがコードの意図を理解しやすくなる
• 特にビジネスロジックや複雑なアルゴリズムには必須

4. 型情報の明示

• TypeScriptやGoなど、型のある言語では型を明示的に書く
• AIが型推論に頼らず、確実に理解できるようにする

5. 循環参照の回避

• ファイル間の循環参照はAIが混乱しやすい
• できるだけ一方向の依存関係にする

6. 適切な粒度での分割

• 1つの関数/メソッドは1つの責務に
• 長すぎる関数はAIも人間も理解しにくい
• 100行を超える関数は分割を検討

7. 標準的なパターンの使用

• 一般的なデザインパターンを使う
• AIは学習データから標準的なパターンを理解している
• 独自の特殊な実装よりも、広く知られたパターンの方が理解されやすい

8. エラーハンドリングの明示

• エラーケースを明確に記述
• エッジケースの処理を明示的に

9. テストコードの活用

• 既存のテストコードがあれば一緒に読み込ませる
• テストコードは「仕様書」としてAIの理解を助ける

10. 段階的な解析

• 一度に全てを解析させず、段階的に情報を提供
• まず構造を理解させ、次に詳細を解析させる

おわりに

今回の経験を通じて気づいたのは、人もAIも、コードを理解するために必要な情報は本質的に同じだということです。明確な命名、適切なコメント、一貫した構造――これらは従来から「良いコード」とされてきた要素そのものです。AIは、それらを人間よりも高速に解釈できるという点で優れているに過ぎません。

つまり、「AIが理解しやすいコード」を書くことは、結局のところ「人間が理解しやすい良いコード」を書くことと同義なのかもしれません。AI時代だからといって特別なことをする必要はなく、基本に忠実であることが最も重要だと感じました。

参考）生成されたシェルスクリプト

#!/bin/bash

# 使用法: ./split_client_gen.sh <入力ファイル.go>
# 例: ./split_client_gen.sh client.gen.go

input_file="$1"
output_dir="client_gen_split_output"

if [[ -z "$input_file" ]]; then
    echo "エラー: 入力ファイル名を指定してください。"
    echo "使用法: $0 <入力ファイル.go>"
    exit 1
fi

if [[ ! -f "$input_file" ]]; then
    echo "エラー: 入力ファイル '$input_file' が見つかりません。"
    exit 1
fi

mkdir -p "$output_dir"
rm -f "$output_dir"/*
echo "出力先ディレクトリ: $output_dir"

get_line_num() {
    local pattern="$1"
    grep -E -n -m 1 -- "$pattern" "$input_file" | cut -d: -f1
}

extract_chunk() {
    local start_line="$1"
    local end_line_exclusive="$2"
    local out_file="$3"
    local actual_end_line

    if [[ -z "$start_line" ]]; then
        echo "情報: セクション '$out_file' の開始点が見つかりません。空ファイルを作成します。"
        touch "$output_dir/$out_file"
        return
    fi

    if [[ -z "$end_line_exclusive" || "$start_line" -ge "$end_line_exclusive" ]]; then
        actual_end_line="$L_EOF"
    else
        actual_end_line=$((end_line_exclusive - 1))
    fi

    if [[ "$actual_end_line" -lt "$start_line" ]]; then
         echo "情報: セクション '$out_file' の範囲が無効です。空ファイルを作成します。"
         touch "$output_dir/$out_file"
         return
    fi

    echo "抽出中: $output_dir/$out_file (行: $start_line - $actual_end_line)"
    sed -n "${start_line},${actual_end_line}p" "$input_file" > "$output_dir/$out_file"
}

L_EOF=$(wc -l < "$input_file" | xargs)

# --- 各セクションの開始を定義するパターン ---
P_CLIENT_STRUCT_START='^type Client struct'
P_CLIENT_INTERFACE_START='^type ClientInterface interface'
P_CLIENT_METHODS_START='^func \(c \*Client\) GetAuthInfo\('
P_REQUEST_BUILDERS_START='^func NewGetAuthInfoRequest\('
P_APPLY_EDITORS_START='^func \(c \*Client\) applyEditors\('
P_CLIENT_WITH_RESPONSES_STRUCT_START='^type ClientWithResponses struct'
P_CLIENT_WITH_RESPONSES_INTERFACE_START='^type ClientWithResponsesInterface interface'
P_CLIENT_WITH_RESPONSES_METHODS_START='^func \(c \*ClientWithResponses\) GetAuthInfoWithResponse\('
P_RESPONSE_STRUCTS_START='^type GetAuthInfoResponse struct'
P_PARSE_FUNCTIONS_START='^func ParseGetAuthInfoResponse\('

L_CLIENT_STRUCT_START=$(get_line_num "$P_CLIENT_STRUCT_START")
L_CLIENT_INTERFACE_START=$(get_line_num "$P_CLIENT_INTERFACE_START")
L_CLIENT_METHODS_START=$(get_line_num "$P_CLIENT_METHODS_START")
L_REQUEST_BUILDERS_START=$(get_line_num "$P_REQUEST_BUILDERS_START")
L_APPLY_EDITORS_START=$(get_line_num "$P_APPLY_EDITORS_START")
L_CLIENT_WITH_RESPONSES_STRUCT_START=$(get_line_num "$P_CLIENT_WITH_RESPONSES_STRUCT_START")
L_CLIENT_WITH_RESPONSES_INTERFACE_START=$(get_line_num "$P_CLIENT_WITH_RESPONSES_INTERFACE_START")
L_CLIENT_WITH_RESPONSES_METHODS_START=$(get_line_num "$P_CLIENT_WITH_RESPONSES_METHODS_START")
L_RESPONSE_STRUCTS_START=$(get_line_num "$P_RESPONSE_STRUCTS_START")
L_PARSE_FUNCTIONS_START=$(get_line_num "$P_PARSE_FUNCTIONS_START")

# --- チャンク抽出 ---
extract_chunk 1 "$L_CLIENT_STRUCT_START" "01_preamble.go"
extract_chunk "$L_CLIENT_STRUCT_START" "$L_CLIENT_INTERFACE_START" "02_client_definition.go"
extract_chunk "$L_CLIENT_INTERFACE_START" "$L_CLIENT_METHODS_START" "03_client_interface.go"
extract_chunk "$L_CLIENT_METHODS_START" "$L_REQUEST_BUILDERS_START" "04_client_methods.go"
extract_chunk "$L_REQUEST_BUILDERS_START" "$L_APPLY_EDITORS_START" "05_request_builders.go"
extract_chunk "$L_APPLY_EDITORS_START" "$L_CLIENT_WITH_RESPONSES_STRUCT_START" "06_apply_editors.go"
extract_chunk "$L_CLIENT_WITH_RESPONSES_STRUCT_START" "$L_CLIENT_WITH_RESPONSES_INTERFACE_START" "07_client_with_responses_definition.go"
extract_chunk "$L_CLIENT_WITH_RESPONSES_INTERFACE_START" "$L_RESPONSE_STRUCTS_START" "08_client_with_responses_interface.go"
extract_chunk "$L_RESPONSE_STRUCTS_START" "$L_CLIENT_WITH_RESPONSES_METHODS_START" "09_response_structs.go"
extract_chunk "$L_CLIENT_WITH_RESPONSES_METHODS_START" "$L_PARSE_FUNCTIONS_START" "10_client_with_responses_methods.go"
extract_chunk "$L_PARSE_FUNCTIONS_START" "$((L_EOF + 1))" "11_parse_functions.go"

echo "---"
echo "ファイルの分割処理が完了しました。'$output_dir' ディレクトリを確認してください。"

おはようございます。信田です。
今回は、B2B SaaSにおけるテナントについて考えてみようと思います。私は、2002年に社会人になり、SIerでキャリアを始めて、コンサルティングファームで働き、その後、SaaS企業で働いているため、これまでほぼ全てのキャリアを、ITにささげてきました。

その中でも、エンタープライズ企業のご支援をすることが多かったため、今でこそ、B2B SaaSに向き合う日々を過ごしていますが、キャリアの前半では、SIとして、1社の企業のシステム作りに携わることが多かったです。その際には、『テナント』という言葉に触れることはなかったです。世の中でも多くのソフトウェアに関わる方が、『テナント』という言葉に馴染みが少ないのではないかと思います。

本題に入りますが、B2B SaaSにおける『テナント』とは、SaaSアプリケーションを利用する個々の顧客企業や組織のことを指します。『テナント』という言葉を聞いて、一番馴染み深いのは、商業ビルなどではないでしょうか？商業ビルでは、一つ一つの入居者のことを『テナント』と呼びますが、想像しやすいので、まずはそちらと比較して考えてみましょう。

いかがでしたでしょうか？？

比較して考えてみるとわかりやすかったのではないでしょうか？B2B SaaSにおいても、商業ビルと同様に、複数の企業に対して、汎用的にサービスを提供しており、SaaSアプリケーションの契約の単位を『テナント』と言い換えることができるかもしれません。

商業ビルとB2B SaaSにおいて、両方に言えることですが、『テナント』という概念を使うことによって、利用企業や組織を個別に捉えるのではなく、『仮想の想定顧客組織』と捉えることによって、”汎用的なサービス”が効率的に提供できるようになります。

では、ここからは、B2B SaaSにおける『テナント』について考えていきます。

B2B SaaSを提供する企業において、『テナント』という概念にどのように向き合っていくべきかについて取り扱います。

『想定のテナント単位』を考える

前述しましたが、『テナント』とは、SaaSアプリケーションの契約の単位となります。つまり、『テナント』の単位をSaaS提供事業者側で考えたとしても、本来、それは利用者側で決めることなので、コントロールできるものではありません。そういった意味で、『”想定の”テナント単位』と書きましたが、提供事業者としては、プロダクトを企画する上で、ペルソナが誰かを捉える意味でも、どんな単位で契約をされるのかを想定していくことが重要と考えています。

例えば、小売の店舗向けの業務をSaaSとして提供する場合に、店舗単体の業務にフォーカスする(想定のテナントは店舗)のか？店舗を横断的に管理することにフォーカスする(想定のテナントは店舗を複数管理する企業)のか？によって、プロダクトの機能提供スコープが変わってくるため、このあたりを考えていくことが肝要と考えます。

テナントへの共通的なサービス提供内容を考える

B2B SaaSでは、顧客を『テナント』と捉えるとお伝えしましたが、その大きな意味合いとして、特定の顧客へのサービスではなく、将来顧客となりうる対象(=テナントとなりうる対象)に対して、どのようなサービスを提供すべきなのかを考えます。ここが、SIのビジネスとの大きな違いになるかなぁと思います。特定の顧客へのサービスであれば、その顧客のやりたいことをヒアリングして、それを、その顧客に最適化して実現すれば良いのですが、『将来顧客となりうる対象』に対してサービスを考える場合、それは、その業務領域における「ベストプラクティス」を考えていく必要が出てきます。つまり、特定の機能を定義する際に、いくつかある選択肢の中から、『将来顧客となりうる対象』に対して汎用的にベストなものを選びつつ、検討を進めていく必要があります。これは非常に負荷がかかることですが、『テナント』を意識してサービス設計しておくことで、ビジネスを効率的に拡大させる可能性(スケーラビリティ)を持つことができます。

テナント戦略の決定

B2B SaaSを提供する際に、必ず出てくる言葉が、「マルチテナント」です。

マルチテナントにおけるテナント戦略とは、「1つのシステム基盤を複数の顧客企業（テナント）で共有する」という前提のもとで、事業の収益性、拡張性、運用効率を最大化するための計画と言えます。特に、技術的な設計（アーキテクチャ）の話になりがちですが、「どの顧客に、どのような価値を、どうやって届け、いかにして収益を上げるか」というビジネスモデルそのものを支える経営戦略と捉え、ビジネスも技術も総合的に考えていくことが重要となります。

a.  技術的な考慮

「マルチテナント」という言葉が出てくる際に、「シングルテナント」との対比として、アーキテクチャのデプロイモデルのプールモデルとサイロモデルがイメージされることが多いですが、我々、アンチパターン社では、プールモデルでもサイロモデルでも、「テナント」を意識して効率的に運用できるように考慮されたアーキテクチャを「マルチテナント」と呼ぶことが多いです。

マルチテナントアプリケーションの設計における、代表的な部分では、デプロイモデルを決めることです。

サーバーやストレージのリソースを複数テナントで共有するプールモデルなどを採用していくことで、テナント数の増加に伴う、開発・運用負荷を高めすぎない状態を作り出し、事業の拡大に寄与できます。

一方で、プールモデルを選択すると、ノイジーネイバーと呼ばれる特定の激しい利用をする「テナント」の影響を別の「テナント」が受けてしまう問題にぶつかる可能性があります。同一リソースで複数の「テナント」を運用するわけですから、リソースをうまく配分できない可能性などが発生します。

つまり、提供する業務の特性や利用者としての「テナント」の特性などを考慮して、デプロイモデルを決めます。

b.  ビジネス的な考慮

さて、「テナント」という言葉は、ビジネス面においても、顧客を特定してその顧客に独自に個別のサービスを提供しないということを意識していく上で、重要な概念になってくると考えます。

特定の顧客を意識しないとするならば、明らかに属性が違う顧客へのサービス提供をどのように対処すべきなのでしょうか？SaaSでは、この明らかに属性が違う顧客を「ティア（階層）」の考え方を使って、顧客をいくつかもまとまりで捉えることによって、あくまでも、特定の顧客へのサービス提供ではなく、同じ階層の「テナント」にまとめてサービス提供することを実現していきます。

その場合、「ティア（階層）」毎に、アーキテクチャや料金プランや提供機能への差分が出てくることになりますが、その際には、どの「テナント」が、どの「ティア（階層）」に所属するのかを紐付けながら、それらを機械的に管理することによって、スケーラビリティーを担保しつつ、ビジネスターゲットを広げていくことができます。

さらに、同じ階層であっても、利用状況に応じて課金したいなどの際には、各「テナント」がどのくらいの利用量かを把握していくためのメータリングなどの考え方も必要となってきます。このメータリングについても「テナント」毎に実施していく必要があります。

また、オプションという概念を準備しておくことで、特定の「テナント」に対してのみ提供するサービス内容を準備することもあります。

このようにビジネス面においても、あくまで「テナント」に対してサービス提供していく意識で、ビジネス展開を考えていく必要があります。

c.  運用的な考慮

テナント戦略を考える際には、運用の視点においても、「テナント」の意識は必要となってきます。まず最初に、「テナントオンボーディング・オフボーディング」の概念となります。アーキテクチャで仮にサイロモデルを選択した場合には、新規「テナント」の契約開始が発生した場合に、その契約に対応して新しいリソースを準備していく必要があります。どの階層の「テナント」が契約開始した場合には、どんなアーキテクチャを準備するべきかを管理していく必要があります。また、それを自動化しておくことによって、新規契約が発生した際の、負荷やリードタイムを軽減し、顧客体験をスムーズにします。

次に、「テナント」毎のモニタリングも必要になってきます。各テナントがどんな利用状況なのか？などの情報を取得することによって、それ以降の「ティア（階層）」設計におけるプライシングや機能開発への有益な判断材料とすることができます。

d.  セキュリティ的な考慮

SaaSのテナント戦略において、最も重要な点ともいえますが、セキュリティへの考慮が必要となります。「マルチテナント」で設計していく際には、「テナント」を同一リソースで集約していくことを考慮しますが、その際に、確実にそれぞれの「テナント」を分離していく必要性があります。テナント分離には、「データベースレベル分離」、「スキーマレベル分離」、「行レベル分離」など、さまざまな手法がありますが、どの手法を選択するにせよ、「テナント」と「テナント」の境界線をクリアに設計していく必要があります。境界線がどのように担保されているのかを意識した設計をすることで、「テナント」を跨いで情報が参照できてしまうなどのセキュリティ事故を防いでおく必要があります。

テナントコンテキストを考えておく

ここまで、考えてきたように、「テナント」として汎用的にソフトウェアサービスを提供していくとはいえ、「テナント」によって、若干振る舞いを変えながら、動作していく状態を作る必要があります。例えば、契約している「料金プラン」によって、使える機能が違ったり、特定の「テナントID」を持つテナントに対しては、パフォーマンスの高い特別なリソースで準備してサービスを提供する必要があるかもしれません。

汎用的にソフトウェアサービスを作りながら、若干の振る舞いを変えていくためのパラメータに当たる部分をテナントコンテキストと呼びます。

・料金プラン

・所属するテナントのID

・利用者の役割

・利用者の属性

などです。

汎用的にソフトウェアを開発しながらも、何によって、アプリケーションの振る舞いを変える必要があるのかを考えて、現在利用しているユーザーには、一体、どのようにサービスを提供（アプリケーションの振る舞い）が必要なのかをコントロールする要素を、一元的に管理しておくことが重要になります。

さて、ここまでさまざまな視点で「テナント」という概念を中心に、B2B SaaSに向き合ってきましたが、「テナント」という概念の重要性について感じていただくことができましたでしょうか？？

この記事で、「テナント」が何か？ということの解像度が少しでも上がっていたら嬉しいです。

ここからは宣伝となります。

我々、株式会社アンチパターンは、B2B SaaSにフォーカスして事業推進する会社です。さまざまな、コンテンツを準備しておりますので、こちらもぜひご参照頂けますと幸いです。

・SaaS開発ガイド【テナント編】

https://saasus.io/resource/e-book/saas-dev-guide-tenant

-> SaaSについてまとまったドキュメントがなかったのでまとめてみました。

・SaaS開発運用を支援するSaaSus Platform

https://saasus.io/

-> 上記で触れた、テナントコンテキストなどを効率的に管理できたりします。

B2B SaaSに向き合う、多くの方と、何かしらの関わりを持っていけたら嬉しいなと考えているので、我々、株式会社アンチパターンにお気軽にコンタクトしてもらえるとさらに嬉しいです。

Kiroは、開発者のための新しいAI IDEとしてプレビュー公開されているツールです。AIと協働しながら、ただコードを書くだけでなく、仕様策定から実装までを一気通貫で進められる点が大きな特徴です。

当日は座学やハンズオンを通じてKiroの基本と活用方法を学んだ後、午後は実際にアプリケーションの開発に取り組みました。

この記事では、イベント当日の様子やKiroの強力な機能、そして実際に触れてみて感じた、未来の開発スタイルについてお伝えします。

イベント概要：Kiroを徹底的に学ぶ一日

このイベントは、AWSが提供するAI IDE「Kiro」を実践的に学ぶことを目的に開催されました。会場はAWSオフィスで、座学とハンズオン形式で進められました。

当日のタイムスケジュール

• 10:00 ~ 10:30 座学 + ハンズオン導入
• 10:30 ~ 12:00 Kiro ハンズオントレーニング
• 12:00 ~ 13:00 昼食
• 13:00 ~ 18:00 Kiro ハッカソン

Kiro ハンズオントレーニングで触れたワークショップは公開されています。興味のある方は、以下のURLから同じ内容を体験可能です。
https://catalog.workshops.aws/vibe-coding-agents-with-kiro/ja-JP

Kiro とは？—「仕様駆動開発」

Kiroは、AWSが提供するAIコーディングエージェントであり、IDEを直接操作しながらコード生成、テスト、デバッグ、ドキュメント生成まで自律的に実行できる革新的な開発環境です。

Kiroの核心にあるのが「仕様駆動開発 (Specification-Driven Development)」です。これは、要件、設計、タスクを最初に明確なドキュメントとして整理し、それを基にAIが実装を進める開発スタイルです。

Specモードと生成される3つのドキュメント

KiroにはVibeモードとSpecモードの2種類のモードがありますが、仕様駆動開発を可能にするのがSpecモードです。Specモードを使用すると、以下の3つのドキュメントが自動的に生成・整理されます。

1. requirements.md：要件定義（ユーザーストーリー、受け入れ基準など）
2. design.md：技術設計（データフロー 、API仕様など）
3. tasks.md：実装タスク計画（進行管理も可能）

tasks.mdが生成された後は、順番にタスクの実行を依頼するだけで、AIが仕様に沿って実装を進めてくれます（画面上の「Start task」を押すだけで実行可能です）。プロジェクト全体の見通しが最初から立つため、迷うことなく開発を進められるのが大きな利点です。

ハッカソンで作ったもの：5時間で動くアプリが完成！

午後のハッカソンは個人開発形式で取り組み、私はGitHubのIssueに関するスクラム支援ツールを作成しました。

具体的には、

1. GitHub APIを使ってリポジトリ内のIssueを取得する。
2. 取得したIssueの内容がスクラムのベストプラクティスに沿っているかをClaudeにチェックしてもらう。
3. Claudeからの指摘内容をWeb画面上に表示する。

というアプリケーションです。開発者がIssueを改善しやすくするためのフィードバック機能を想定しました。

Kiroによる開発体験

この実装は、KiroのSpecモードを使い、要件整理から設計、タスク分解までAIエージェントと協働で進めました。

初期設定だけ行えば、AIが仕様に沿ったコンポーネント、API呼び出し、画面表示まで自律的に生成してくれたため、わずか5時間という短時間でも一つのアプリケーションとして形にすることができました。

もしこれを自力で実装していたら、GitHub APIの選定やUIコンポーネントの設計で数日はかかっていたかもしれません。AIがプロジェクトの設計・管理まで担ってくれることで、開発スピードが劇的に向上することを実感しました。

参加して感じたこと：既存ツールとの違い

普段はRoo CodeやGitHub Copilotを利用して開発を行なっており、Kiroを使うのは今回が初めてでした。

1. タスク管理の視認性の高さ
   Specモードで仕様の整理から始めると、その後の実装が驚くほどスムーズでした。特に、tasks.mdとして実装タスクが整理される点が既存のコーディング支援ツールとの大きな違いです。
   
2. 未知の機能への期待
   今回はSpecモードが中心でしたが、IDEの特定イベントに対して事前定義したAIアクションを実行できるHooks機能や、チーム標準やプロジェクト固有の情報に基づいてエージェントの挙動を制御できるSteering機能など、他にも試してみたい機能が紹介されました。これらを活用すれば、さらにチーム開発の効率が上がりそうです。
   

イベントの様子

素晴らしい環境と機会を提供してくださったAWSスタッフの皆様、本当にありがとうございました！

終わりに：今すぐKiroを試すチャンス！

今回のハッカソンを通じて、Kiroは単なるコード補完ツールではなく、開発プロセス全体を加速させるAIエージェントだと強く感じました。

嬉しいことに、Kiroを試すためのハードルが下がっています。

• ウェイトリスト廃止: 2025/10/16でKiroのウェイトリストは廃止されたようです。
• 無料クレジット: 2025/10/1以降にKiroに初めてアクセスすると、14日間使用できる無料のクレジットを500もらえるとのことです。

出典：

• AWS ブログ「ウェイトリストは終了、今日から Kiro を始めましょう」
• AWS ブログ「新しい料金プランと新エージェント「Auto」の発表」

今回のハッカソンでは約5時間Kiroを使い続けましたが、消費したクレジットは100程度でした。無料のクレジットでも十分にKiroを試すことができそうですし、私のアカウントではいつの間にか1000クレジットに増えていたので、ぜひ気軽に試してみてはいかがでしょうか！

はじめまして！APでエンジニアインターンをしている鈴木鴻太です。

今回は、AWSで開催されたkiroの仕様書駆動体験1dayハッカソンに参加し、そこで得た「未来の開発のあり方」について考察し、実際に検証した過程をご紹介します。

僕が考察する今後レギュラーになってくる開発手法

僕はkiroを使った仕様書駆動開発を体験したことで、「これからの時代は“仕様書”と“受け入れ基準・テスト条件”の2つを起点にし、LLMに“テスト基準を越えるまで”実装を繰り返させる――そんな開発スタイルが主流になっていくのでは？」と感じました。

以下V字のうち、システムテストまでAIに自動化させるといったイメージです。

この考えをもとに、kiroに加えてPlaywright MCPとChrome DevTools MCPという2つのツールを組み合わせ、実際に「仕様書とテスト要件を一体化した開発」がどこまで自動化できるのかを検証しました。

検証フェーズ

検証の全体像

今回の検証では、以下の構成でテスト自動化を組み立てました：

• AIエージェント：Kiro
• テストツール：Playwright MCP ＋ Chrome DevTools MCP
• テスト対象：カウンターボタン（ボタンをクリックするたびに数字が増えるシンプルなWebアプリ）
• ↓以下画像

• 検証項目：機能テストとパフォーマンステスト

検証方法と選定理由

従来のテスト自動化では、テストコードの記述やCI/CDへの組み込みが必須でした。しかし、今回の試みではAIエージェントがMCP経由でブラウザを直接操作することで、より自然言語ベース・統合的なテストプロセスを目指しています。

この方式を選んだ主な理由は下記の通りです：

1. 自然言語でテスト指示が可能
   　「ボタンを5回クリックして」など、直感的な指示で実行できる
   
2. 複数ツールの統合が容易
   　機能テスト・パフォーマンス測定のツール切り替え不要
   
3. 柔軟な検証が可能
   　テスト手順や基準の変更が容易
   

定義した受け入れ条件

検証に入る前に、今回のアプリとそのテスト全体に対し9つの要件と受け入れ条件を明確に定義しました。
この“要件を仕様としてAIに渡す”という考えこそ、仕様書駆動＋テスト自動化の根幹になっています。

主要な要件・受け入れ基準（抜粋）

• 基本機能要件：「押してね」ボタンで連続する数字がインクリメントされること（1から開始。無制限クリックOK）
• UI応答性／パフォーマンス要件：100ms以内でUI反映、50ms以内のJS実行、LCPは2.0秒以下、CLSは0.1以下
• 機能テスト自動化要件：Playwright MCPでクリックと数字検証を自動化（高速クリックも含む）
• パフォーマンステスト自動化要件：Chrome DevTools MCPで各Core Web Vitals、UI応答、JS時間の自動計測
• 異常系テスト要件：数字が正しく増えない場合もAIが気付けること
• テスト結果/履歴記録要件：Markdown形式で全履歴・実測値・合否・スクリーンショット等を時系列記録
• 自律的な問題分析・修正要件：AIが失敗理由を分析し、修正版を提案・再テストできるように設計（今後拡張予定）

テスト条件の整理

• 機能側：クリック操作・数字シーケンス・UI識別・高速操作の検証
• パフォーマンス側：LCP, CLS, UI応答, JS実行時間の閾値基準
• 結果記録側：Markdown/時系列/合否/スクショ/タイムスタンプ

実際の検証手順

1. 機能テスト（Playwright MCP）

Playwright MCPを使い、UI操作および表示内容の自動検証を行いました。

検証フロー：

1. ページロード（file://kiro-test/index.html）
2. ボタンを10回クリック
3. 数値表示が1〜10まで正しくインクリメントされるか確認
4. スクリーンショット撮影
5. ブラウザをクローズ

実行コマンド例（概念）：

await mcp_playwright_playwright_navigate({ url: fileUrl, headless: false, width: 1280, height: 720 });
await mcp_playwright_playwright_click({ selector: '#counter-button' });
const visibleText = await mcp_playwright_playwright_get_visible_text();

結果：

• ボタンクリックテスト：合格
• 数字シーケンス検証：合格（1～10）
• UI要素識別テスト：合格

2. パフォーマンステスト（Chrome DevTools MCP）

Performanceメトリクス取得にはChrome DevTools MCPを活用しました。

検証フロー：

1. ページに移動
2. パフォーマンストレース開始
3. ページリロード
4. トレース停止・メトリクス取得
5. JavaScript実行時間測定（10回繰り返し）
6. スクリーンショット撮影

実行コマンド例（概念）：

await mcp_chrome_devtools_performance_start_trace({ reload: true, autoStop: false });
await mcp_chrome_devtools_performance_stop_trace();
await mcp_chrome_devtools_evaluate_script({ function: '...カウンター処理...' });

結果（抜粋）：

LCP内訳：TTFB 0.7ms／レンダリング遅延 216ms
JS実行時間：最小0ms／最大0.1ms／平均0.01ms（10回測定）

テスト結果の記録

テスト結果は自動的に test-results.md に記録され、下記の情報が時系列で残ります：

• 総合判定（合格／不合格）
• 各テスト詳細
• パフォーマンスメトリクス（統計値）
• スクリーンショットへのリンク
• 実行環境・条件

気付きと学び

実際に得られた知見

1. AIエージェントによる柔軟なテスト実行

従来の自動テストはスクリプト化が前提ですが、Kiro＋MCPでは自然言語での即応テストが可能です。
指示文を修正するだけでロジックや手順を即座に切替でき、探索的テストや要件変化への迅速対応に適しています。

2. MCPツールの統合の容易さ

Playwright MCPとChrome DevTools MCPをひとつのAIワークフロー上で同時利用でき、機能・性能検証を一気通貫で回すことができました。従来必要だった手作業や別ツールでの結果統合は不要です。

3. パフォーマンスメトリクスの詳細取得

Chrome DevTools MCPにより、Core Web Vitalsの細かい内訳（例：TTFB、レンダリング遅延）も取得できるため、ボトルネック分析が容易です。

4. テスト結果の自動履歴管理

Markdownファイルへの自動記録によって、履歴比較・品質推移・視覚確認（スクリーンショット）の管理が一気に楽になりました。

メリット・新しい発見

メリット：

• テストコード量の削減（自然言語指示＋抽象化されたAPI）
• 多様なツールの統合が自動化可能
• 柔軟なシナリオ変更への即応性
• パフォーマンス分析の精度向上

新しい発見：

• AIエージェント環境がテスト実行基盤になる
• MCPによる周辺ツール拡張性（APIテスト、DBテスト等）も期待大
• Markdown記録で可読性・共有性が高い

課題・注意点と対応策

テストスクリプトの実行環境の制約：
Kiroエージェント環境限定のAPIのため、CI/CD本体に組み込むには別途工夫が必要。

対応策：

• KiroとCI/CDパイプラインの連携構築
• エージェント用／CI用スクリプトの分割

非決定的な動作の可能性：
AIエージェントの解釈や実行タイミングにより、出力が前後することがある。

対応策：

• 重要シナリオは厳密なスクリプトで手厚く担保
• 判定ロジックを明示し、結果検証を厳密化

パフォーマンス測定の環境依存性：
結果はローカル環境依存が大きい。本番想定なら条件を揃える必要あり。

対応策：

• 本番近似環境での測定
• 複数回実施・統計値の採用
• 実行環境の記録

スクリーンショット管理：
テスト実行ごとにファイルが増えるため、ライフサイクル管理・保存ルールが必要。

対応策：

• 定期削除／重要ファイル選別
• クラウドストレージ化

今後の展望

CI/CD統合：
GitHub Actions連携や自動テストコメントなど、パイプライン自動化との一体運用を進めたい。

テスト結果可視化：
データのグラフ表示やアラート機能、履歴比較なども今後取り入れていく予定です。

まとめ

今回の取り組みを通じて、定義した要件と受け入れ条件をAIエージェント（kiro）に明確に渡すことで、「実装＋テスト自動化」のサイクルを一気通貫でAIが担えることを検証できました。

従来はプログラミングとテストの自動化は分業的でしたが、「仕様＝テスト条件＝AIによる開発・検証基準」とする新しい“仕様書駆動開発”の形が具体的に実現できたと感じています。
これにより、従来は「8割AIに書かせて残りの2割を開発者が担当する...」といったところを「9割AIに書かせて残りの1割を開発者が担当する...」といった温度感にできるのではないかと思っています。

また、今後は複雑な要件や大規模プロジェクトにも幅を広げ、「要件定義→実装→自動テスト→履歴記録→自律的な修正提案」まで含めてAIが開発を担う。そんな実践フェーズがやってくると思っています。

POSSEでエンジニアインターンをしている井上岳です。

最近、AIを使った開発ワークフローのツールがいくつか登場しています。今回取り上げたいのは、Claude Code Spec WorkflowとKiroです。

• Claude Code Spec Workflow
• Kiro

どちらもrequirements → design → tasksという流れで仕様を決めて実装するというアプローチを取っていますが、実際に使ってみるとかなり違いがあります。今回は同じお題で両方試してみたので、その違いを紹介したいと思います。

試したお題

今回は「ECサイトの注文から配送までのドメインモデリング」という課題に挑戦しました。関数型プログラミングのアプローチで、型安全な状態遷移を実現するという、そこそこ複雑な内容です。

投げたプロンプト：

ECサイトでの「注文から配送までの流れ」をドメインモデリングしてください。
顧客が商品を注文してから、在庫を確保し、出荷・配送を経て完了に至るまでの一連のプロセスを想定しています。
・不正な状態遷移が起きないようにしたい
・副作用（例：在庫確認や通知送信）はできるだけ分離したい
・将来的にキャンセル処理や再配送なども追加できるようにしたい
このドメインを、関数型的な考え方で安全に設計してください。
型、関数、状態遷移など、あなたが重要だと思う単位で自由に表現して構いません。

要点：

• 注文確定 → 在庫引当 → 出荷 → 配送完了という状態遷移
• 不正な状態遷移を型レベルで防ぐ
• 副作用（通知送信、在庫更新）をドメインロジックから分離
• 将来的なキャンセル・再配送機能への拡張性
  

Kiroで試してみました

Kiroは要件定義を書くところから始まります。プロンプトを投げると、まず requirements.md を作成してくれます。

要件定義では、User Storyの形式で各要件が整理されます。Acceptance Criteriaも明確に定義されていて、「何を満たせば完成なのか」がわかりやすいです。

# Requirements Document

## Introduction

ECサイトにおける注文から配送完了までの一連のプロセスを、関数型プログラミングの原則に基づいて安全にモデリングする機能です。この機能は、不正な状態遷移を防ぎ、副作用を適切に分離し、将来的な拡張（キャンセル処理、再配送など）に対応できる設計を提供します。

## Requirements

### Requirement 1

**User Story:** システム開発者として、注文の状態遷移を型安全に管理したいので、不正な状態変更を防ぐドメインモデルが必要です。

#### Acceptance Criteria

1. WHEN 注文が作成される THEN システム SHALL 初期状態（OrderPlaced）に設定する
2. WHEN 在庫確認が完了する THEN システム SHALL InventoryReserved状態に遷移する
3. WHEN 無効な状態遷移が試行される THEN システム SHALL エラーを返し状態変更を拒否する
4. WHEN 各状態遷移が実行される THEN システム SHALL 遷移の妥当性を事前に検証する

..... 続く

次に design.md が作られます。ここでは型定義、状態遷移関数、副作用システムなどの設計が詳細に記述されます。Mermaidによるアーキテクチャ図やTypeScriptのコード例も含まれていて、実装イメージがかなり具体的です。

# Design Document

## Overview

ECサイトの注文から配送までの流れを、関数型プログラミングの原則に基づいて安全にモデリングするドメイン設計です。この設計では、型安全な状態遷移、副作用の分離、イミュータブルなデータ構造を中心とした堅牢なシステムを構築します。

## Architecture

### Core Principles

1. **Type Safety**: 型システムを活用して不正な状態遷移をコンパイル時に防ぐ
2. **Immutability**: すべてのデータ構造をイミュータブルにし、状態変更は新しいインスタンス作成で行う
3. **Pure Functions**: 状態遷移ロジックを純粋関数として実装し、副作用を分離
4. **Effect Separation**: 副作用（IO、外部API呼び出し）を明示的に管理
5. **Composability**: 小さな関数を組み合わせて複雑な処理を構築

### Architecture Diagram

```mermaid
graph TB
    subgraph "Domain Layer"
        Order[Order Aggregate]
        States[Order States]
        Transitions[State Transitions]
        Events[Domain Events]
    end
    
    subgraph "Effect Layer"
        Effects[Side Effects]
        Inventory[Inventory Service]
        Notification[Notification Service]
        Shipping[Shipping Service]
    end
    
    subgraph "Application Layer"
        Commands[Command Handlers]
        Orchestrator[Effect Orchestrator]
    end
    
    Commands --> Order
    Order --> States
    States --> Transitions
    Transitions --> Events
    Events --> Effects
    Effects --> Inventory
    Effects --> Notification
    Effects --> Shipping
    Orchestrator --> Effects
```

## Components and Interfaces

### 1. Order State Types

```typescript
// 基本的な値オブジェクト
type OrderId = string & { readonly _brand: 'OrderId' }
type CustomerId = string & { readonly _brand: 'CustomerId' }
type ProductId = string & { readonly _brand: 'ProductId' }
type Timestamp = Date & { readonly _brand: 'Timestamp' }

// 注文アイテム
interface OrderItem {
  readonly productId: ProductId
  readonly quantity: number
  readonly unitPrice: number
}

// 配送情報
interface ShippingInfo {
  readonly address: string
  readonly method: 'standard' | 'express' | 'overnight'
  readonly trackingNumber?: string
}

// 状態固有のデータ
interface OrderPlacedData {
  readonly orderId: OrderId
  readonly customerId: CustomerId
  readonly items: readonly OrderItem[]
  readonly placedAt: Timestamp
}

interface InventoryReservedData extends OrderPlacedData {
  readonly reservedAt: Timestamp
  readonly reservationId: string
}

interface ShippedData extends InventoryReservedData {
  readonly shippingInfo: ShippingInfo
  readonly shippedAt: Timestamp
}

interface DeliveredData extends ShippedData {
  readonly deliveredAt: Timestamp
  readonly signature?: string
}

// 状態の型安全な表現
type OrderState = 
  | { readonly type: 'OrderPlaced'; readonly data: OrderPlacedData }
  | { readonly type: 'InventoryReserved'; readonly data: InventoryReservedData }
  | { readonly type: 'Shipped'; readonly data: ShippedData }
  | { readonly type: 'Delivered'; readonly data: DeliveredData }
```

..... 続く

そして implementation.md では、実装タスクが細かくブレークダウンされます。各タスクには要件番号が紐付けられているので、トレーサビリティも確保されています。

# Implementation Plan

- [x] 1. Set up project structure and core type definitions

  - Create TypeScript project with strict type checking enabled
  - Define branded types for OrderId, CustomerId, ProductId, and Timestamp
  - Implement basic value objects and interfaces for OrderItem and ShippingInfo
  - _Requirements: 5.1, 5.3, 6.1_

- [ ] 2. Implement core order state types and data structures

  - [ ] 2.1 Create order state data interfaces

    - Define OrderPlacedData, InventoryReservedData, ShippedData, and DeliveredData interfaces
    - Implement proper inheritance hierarchy with readonly properties
    - _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5, 6.1_

  - [ ] 2.2 Implement OrderState union type
    - Create tagged union type for all order states
    - Ensure type safety with discriminated unions
    - _Requirements: 1.1, 1.2, 5.1, 5.2_

- [ ] 3. Create Result type and error handling utilities

  - [ ] 3.1 Implement generic Result type

    - Create Result<T, E> type with success and failure variants
    - Implement Result utility functions (map, flatMap, mapError)
    - _Requirements: 6.4, 1.3_

  - [ ] 3.2 Define TransitionResult type
    - Create specialized result type for state transitions
    - Include newState and effects in success case
    - _Requirements: 1.3, 1.4, 2.1_

..... 続く

実装に入ると、「Start task」ボタンで各タスクを実行できます。（画像のTask in progressの部分にStart taskボタンがあります）

タスクが完了すると自動でチェックが付く仕組みになっていて、進捗が可視化されます。

必ず反映されるのが便利ですね、、！！！

Claude Code Spec Workflowで試してみました

一方、Claude Code Spec Workflowは少し違うアプローチを取ります。

まず、コードベース分析から始まります。既存のプロジェクト構造や規約を理解してから仕様を書くという流れです。

その後、 requirements.md が作成されます。

# Requirements Document

## Introduction

ECサイトにおける「注文から配送までの流れ」のドメインモデル実装です。このシステムは、顧客の注文受付から在庫確保、出荷、配送、完了までの一連のプロセスを安全に管理します。

関数型プログラミングの原則に基づき、不正な状態遷移を防ぎ、副作用を分離し、将来的な拡張（キャンセル、再配送など)を容易にする設計を目指します。

**価値提供:**
- 状態遷移の安全性向上により、注文処理のバグを削減
- 副作用の分離により、テストの容易性とメンテナンス性を向上
- 型安全性により、開発者体験とコードの信頼性を向上

## Alignment with Product Vision

本機能は以下の観点で製品価値を提供します:
- **信頼性:** 型安全な状態管理により、注文処理の信頼性を確保
- **拡張性:** 関数型設計により、新機能（キャンセル、再配送）の追加を容易化
- **保守性:** 副作用の分離により、コードの理解とメンテナンスを容易化

## Requirements

### Requirement 1: 注文状態の型安全な管理

**User Story:** As a システム開発者, I want 注文の状態を型安全に管理する機能, so that 不正な状態遷移を防ぎ、バグを減少させることができる。

#### Acceptance Criteria

1. WHEN 注文が作成される THEN システム SHALL 注文を「注文作成済み」状態で初期化する
2. WHEN 「注文作成済み」状態の注文に対して在庫確保が実行される THEN システム SHALL 「在庫確保済み」状態へ遷移する
3. WHEN 不正な状態遷移が試行される（例: 「注文作成済み」から「配送中」への直接遷移） THEN システム SHALL 型エラーまたはコンパイルエラーを発生させる
4. WHEN 各状態遷移が実行される THEN システム SHALL 遷移の成功/失敗を明示的に返す（Result型またはEither型）

..... 続く

ここまではKiroと似ていますが、おもしろいのは次です。

要件定義書が完成すると、専用のバリデーションエージェントが動きます。要件の完全性や明確さをチェックして、改善点を指摘してくれます。

ユーザーストーリーのフォーマットに修正点があったみたいです。

バリデーション結果を元に要件を修正してから、design.mdの作成に進みます。設計書でも同様にバリデーションが行われます。

design.md

# Design Document

## Overview

ECサイトの注文フルフィルメントシステムを関数型プログラミングの原則に基づいて設計します。本設計は、型安全な状態管理、副作用の分離、拡張性を重視し、注文の作成から配送完了までのライフサイクルを安全に管理します。

**設計の中核原則:**
- **型駆動設計**: 不正な状態遷移をコンパイル時に検出
- **純粋関数**: 状態遷移ロジックを副作用から分離
- **代数的データ型**: Sum Type（直和型）による状態の明示的表現
- **Result/Either型**: 例外を使わないエラーハンドリング

## Steering Document Alignment

### Technical Standards
本設計は以下の技術標準に準拠します:
- **関数型プログラミング**: 純粋関数、不変性、型安全性
- **ドメイン駆動設計**: ユビキタス言語の使用、ドメインモデルの明確化
- **テスト駆動開発**: 純粋関数によるテスタビリティの向上

### Project Structure
プロジェクト構造は以下の方針に従います:
- **domain/**: ドメインモデルと状態遷移ロジック
- **effects/**: 副作用の定義と実行
- **types/**: 型定義とResult/Either型
- **tests/**: ユニットテストと統合テスト

## Code Reuse Analysis

新規プロジェクトのため、既存コードの再利用はありませんが、以下の汎用パターンを活用します:

### Existing Components to Leverage
- **関数型パターン**: Result型、Either型、Option型などの標準的な関数型パターン
- **状態機械パターン**: 型安全な状態遷移の実装パターン
- **Effect Systemパターン**: 副作用の記述と実行の分離パターン

### Integration Points
- **在庫管理システム**: 在庫確保・更新の副作用として統合
- **通知サービス**: メール/SMS送信の副作用として統合
- **配送業者API**: 配送追跡情報の更新副作用として統合

## Architecture

本システムは、以下の3層アーキテクチャで構成されます:

```mermaid
graph TB
    subgraph "Domain Layer (Pure)"
        OrderState[Order State Types]
        Transitions[State Transition Functions]
        OrderState --> Transitions
    end

    subgraph "Effect Layer (Impure)"
        EffectDef[Effect Definitions]
        EffectExec[Effect Executors]
        EffectDef --> EffectExec
    end

    subgraph "Integration Layer"
        Inventory[Inventory Service]
        Notification[Notification Service]
        Shipping[Shipping API]
    end

    Transitions --> EffectDef
    EffectExec --> Inventory
    EffectExec --> Notification
    EffectExec --> Shipping
```

### 状態遷移図

```mermaid
stateDiagram-v2
    [*] --> Created: createOrder
    Created --> InventoryReserved: reserveInventory
    InventoryReserved --> Shipped: ship
    Shipped --> InTransit: startDelivery
    InTransit --> Delivered: completeDelivery
    Delivered --> [*]

    note right of Created
        注文作成済み
        在庫未確保
    end note

    note right of InventoryReserved
        在庫確保済み
        出荷待ち
    end note

    note right of Shipped
        出荷済み
        配送開始待ち
    end note

    note right of InTransit
        配送中
    end note

    note right of Delivered
        配送完了
    end note
```

### 将来の拡張（キャンセル・再配送）

```mermaid
stateDiagram-v2
    [*] --> Created
    Created --> InventoryReserved: reserveInventory
    Created --> Cancelled: cancel
    InventoryReserved --> Shipped: ship
    InventoryReserved --> Cancelled: cancel
    Shipped --> InTransit: startDelivery
    InTransit --> Delivered: completeDelivery
    InTransit --> DeliveryFailed: markFailed
    DeliveryFailed --> InTransit: redeliver
    DeliveryFailed --> Cancelled: cancel
    Delivered --> [*]
    Cancelled --> [*]
```

## Components and Interfaces

### Component 1: Order State Types（注文状態型）

**目的:** 注文の各状態を型安全に表現し、不正な状態遷移をコンパイル時に防止

**型定義（TypeScript風の例）:**

```typescript
// 基本的な注文情報（すべての状態で共通）
type OrderId = string;
type CustomerId = string;
type OrderItem = {
  productId: string;
  quantity: number;
  price: number;
};

// 各状態を個別の型として定義（Phantom Type pattern）
type OrderCreated = {
  readonly _tag: "OrderCreated";
  readonly orderId: OrderId;
  readonly customerId: CustomerId;
  readonly items: OrderItem[];
  readonly createdAt: Date;
};

type OrderInventoryReserved = {
  readonly _tag: "OrderInventoryReserved";
  readonly orderId: OrderId;
  readonly customerId: CustomerId;
  readonly items: OrderItem[];
  readonly createdAt: Date;
  readonly reservedAt: Date;
};

type OrderShipped = {
  readonly _tag: "OrderShipped";
  readonly orderId: OrderId;
  readonly customerId: CustomerId;
  readonly items: OrderItem[];
  readonly createdAt: Date;
  readonly reservedAt: Date;
  readonly shippedAt: Date;
  readonly trackingNumber: string;
};

type OrderInTransit = {
  readonly _tag: "OrderInTransit";
  readonly orderId: OrderId;
  readonly customerId: CustomerId;
  readonly items: OrderItem[];
  readonly createdAt: Date;
  readonly reservedAt: Date;
  readonly shippedAt: Date;
  readonly trackingNumber: string;
  readonly inTransitAt: Date;
};

type OrderDelivered = {
  readonly _tag: "OrderDelivered";
  readonly orderId: OrderId;
  readonly customerId: CustomerId;
  readonly items: OrderItem[];
  readonly createdAt: Date;
  readonly reservedAt: Date;
  readonly shippedAt: Date;
  readonly trackingNumber: string;
  readonly inTransitAt: Date;
  readonly deliveredAt: Date;
};

// Sum Type（直和型）で全状態を表現
type Order =
  | OrderCreated
  | OrderInventoryReserved
  | OrderShipped
  | OrderInTransit
  | OrderDelivered;
```

..... 続く

タスクブレークダウンは task.md として作成されます。Kiroと比べると、各タスクの目的（Purpose）や活用する既存コンポーネント（Leverage）が明記されていて、より詳細です。

# Implementation Plan

## Task Overview

ECサイトの注文フルフィルメントシステムを、関数型プログラミングの原則に基づいて実装します。実装は以下の順序で進めます:

1. **基礎型の実装**: Result型、Effect型などの汎用的な型
2. **ドメインモデルの実装**: 注文状態型と状態遷移関数
3. **副作用システムの実装**: Effect実行器と統合層
4. **ドメインAPIの実装**: OrderAggregate
5. **テストの実装**: ユニットテスト、統合テスト、E2Eテスト

各タスクは1-3ファイルに限定し、15-30分で完了可能なアトミックな単位に分解しています。

## Steering Document Compliance

- **関数型プログラミング標準**: 純粋関数、不変性、型安全性を遵守
- **プロジェクト構造**: `src/domain/`, `src/effects/`, `src/types/`, `tests/` の構造に従う
- **TypeScript標準**: 厳格な型チェック、readonly修飾子の使用

## Atomic Task Requirements

各タスクは以下の基準を満たします:
- **ファイルスコープ**: 1-3ファイルのみに影響
- **時間制限**: 15-30分で完了可能
- **単一目的**: 1つのテスト可能な成果
- **明示的なファイル**: 作成/変更するファイルを明示
- **エージェントフレンドリー**: 明確な入出力とコンテキスト切り替えの最小化

## Tasks

### Phase 1: 基礎型の実装

- [x] 1. Create Result type in src/types/result.ts
  - File: src/types/result.ts
  - Define Result<T, E> type with Success and Failure variants
  - Implement utility functions: success(), failure(), map(), flatMap()
  - Add type guards: isSuccess(), isFailure()
  - Purpose: Provide foundation for error handling without exceptions
  - _Requirements: 7.2, 7.3_

- [ ] 2. Create Result type unit tests in tests/types/result.test.ts
  - File: tests/types/result.test.ts
  - Test success() and failure() constructors
  - Test map() transformation on Success and Failure
  - Test flatMap() chaining behavior
  - Test type guards work correctly
  - Success criteria: All tests pass, types compile without errors
  - Purpose: Ensure Result type behaves correctly for all operations
  - _Leverage: src/types/result.ts_
  - _Requirements: 7.2_

- [ ] 2.5. Create type guard utilities in src/types/guards.ts
  - File: src/types/guards.ts
  - Implement type guards for Order states: isOrderCreated(), isOrderInventoryReserved(), isOrderShipped(), etc.
  - Implement pattern matching utility: matchOrder() for safe state discrimination
  - Purpose: Enable type-safe pattern matching and state discrimination at compile time
  - _Leverage: src/types/result.ts, src/domain/order-states.ts_
  - _Requirements: 1.3, 7.3_

..... 続く

実装フェーズでは、カスタムコマンドを使ってタスクを実行していきます。こちらも完了したタスクにはチェックが付きます。

生成されたコードを見てみる

「ECサイトの注文から配送までのドメインモデリング」という課題に対して、両ツールが実際にどのようなコードを生成したのかを見てみましょう。

Kiroが生成したコード

Kiroはクラスベースのアプローチを採用しています。Orderクラスが状態を内部に持ち、状態遷移メソッドを提供する形です。

class Order {
  private constructor(private readonly state: OrderState) {}

  // 在庫確保への遷移
  reserveInventory(reservationId: string): TransitionResult<Order> {
    if (this.state.type !== 'OrderPlaced') {
      return {
        success: false,
        error: `Cannot reserve inventory from state: ${this.state.type}`
      }
    }

    const newData: InventoryReservedData = {
      ...this.state.data,
      reservedAt: new Date() as Timestamp,
      reservationId
    }

    const newState: OrderState = {
      type: 'InventoryReserved',
      data: newData
    }

    const effects: Effect[] = [
      {
        type: 'SendNotification',
        customerId: this.state.data.customerId,
        message: 'Your order inventory has been reserved'
      }
    ]

    return {
      success: true,
      newState: new Order(newState),
      effects
    }
  }
}

このアプローチの特徴は、状態と振る舞いがカプセル化されている点です。オブジェクト指向的な設計で、直感的に理解しやすいコードになっています。

Claude Code Spec Workflowが生成したコード

Claude Codeは純粋な関数型アプローチを採用しています。状態遷移を純粋関数として実装し、状態と関数を分離しています。

// 在庫確保への遷移（純粋関数）
function reserveInventory(
  order: OrderCreated,
  inventoryCheck: (items: OrderItem[]) => Result<boolean, InventoryError>
): Result<ReserveInventoryResult, OrderError> {
  // 1. 在庫チェック
  const checkResult = inventoryCheck(order.items);

  if (checkResult._tag === "Failure") {
    return failure(checkResult.error);
  }

  if (!checkResult.value) {
    return failure({
      _tag: "InsufficientInventory",
      productId: order.items[0].productId,
      requested: order.items[0].quantity,
      available: 0
    });
  }

  // 2. 新しい状態の生成
  const newState: OrderInventoryReserved = {
    _tag: "OrderInventoryReserved",
    ...order,
    reservedAt: new Date()
  };

  // 3. 副作用の記述（実行はしない）
  const effects: [ReserveInventoryEffect, SendNotificationEffect] = [
    createEffect("Reserve Inventory", async () => {
      return success({ reservationId: "...", items: order.items });
    }),
    createEffect("Send Reservation Notification", async () => {
      return success({ notificationId: "...", sentAt: new Date() });
    })
  ];

  return success({ newState, effects });
}

こちらは完全に関数型のアプローチです。状態遷移関数は純粋関数として実装され、副作用は値として返されるだけで実行されません。依存性注入によってテストもしやすくなっています。

どちらのコードが良いのか

両方とも型安全で拡張性のある設計ですが、今回の課題に対する適合性を見ると、興味深い違いがあります。

Claude Code Spec Workflowが生成したコードは、確かに教科書的な関数型プログラミングです。純粋関数として実装され、依存性注入によってテストもしやすい。関数型プログラミングの原則に忠実で、理論的には美しいコードです。

ただ、実際にチーム開発で使うことを考えると、いくつか気になる点があります。まず、完全に関数型のアプローチに慣れていない開発者にとっては学習コストが高いです。Result 型や Effect 型の扱い、依存性注入のパターンなど、関数型プログラミングの経験がないと戸惑う部分が多いと思います。

一方、Kiroのコードは実用的なバランスが取れています。クラスベースのアプローチなので、TypeScriptやJavaScriptの標準的なコードスタイルに近いです。でも、関数型プログラミングの重要な要素はしっかり押さえています。

• イミュータブルな状態管理（`readonly`の使用）
• 状態遷移で新しいインスタンスを返す
• 副作用を Effect として分離
• 型安全な状態遷移

つまり、「関数型の良いところを取り入れつつ、実用性も保つ」というアプローチです。オブジェクト指向に慣れた開発者でもすぐに理解できるし、それでいて型安全性や拡張性も確保されています。

今回の課題である「ECサイトの注文から配送までのドメインモデリング」という実務的なユースケースを考えると、Kiroのコードの方が現場で使いやすいと感じました。状態と振る舞いが Order クラスに集約されているので、コードの見通しが良く、新しいメンバーがジョインしたときにも理解しやすいと思います。

どこが違うのか

両方使ってみて感じた違いをいくつか挙げます。

ワークフローの始まり方

Kiroは「要件定義から始める」というシンプルなアプローチです。いきなり本題に入れます。

Claude Code Spec Workflowは「既存コードベースの理解から始める」というアプローチです。新規プロジェクトでなければ、こちらの方が理にかなっています。

バリデーション機構

Claude Code Spec Workflowの大きな特徴は、専用のバリデーションエージェントがいることです。要件定義書や設計書の品質をチェックしてくれるので、仕様の穴を早期に発見できます。

Kiroにはこの機能がありません。もちろん、書かれる仕様自体は十分に詳細ですが、第三者的なチェックがないのは少し心細く感じました。

タスクの粒度

両方ともタスクを細かく分解してくれますが、Claude Code Spec Workflowの方が若干詳細です。各タスクに「Purpose」「Leverage」「Requirements」が明記されていて、なぜこのタスクが必要なのかがわかりやすいです。

Kiroのタスクも十分に細かいですが、どちらかというと「何をするか」に重点が置かれている印象です。

結局どちらを使うべきか

ここまで読んで、「じゃあClaude Code Spec Workflowの方がいいじゃないか」と思った人もいるかもしれません。

確かに、バリデーション機構や詳細なタスク定義は魅力的です。でも、実際に使ってみると、Kiroの方が使いやすいと感じる場面も多かったです。

Kiroの良さ

まず、シンプルさです。「要件書いて、設計書いて、実装する」という流れがストレートでわかりやすいです。余計なステップがありません。

次に、スピード感です。Kiroは要件定義から実装まで、一気通貫で進められます。途中でバリデーションを挟まないので、テンポよく開発が進みます。

Claude Code Spec Workflowは、バリデーションでいったん止まって修正を求められるので、リズムが途切れがちです。

最後に、学習コストです。Kiroは機能がシンプルで、エディタ上でボタンを押していくだけで進んでいくのですぐに使いこなせます。

まとめ

どちらも優れたツールですが、使い分けが大事だと思います。

大規模プロジェクトや、複数人で仕様レビューが必要な場合は、Claude Code Spec Workflowのバリデーション機構が活きます。既存のコードベースに追加開発する場合も、コードベース分析機能が便利です。エンジニア向けのサービスだと感じました。

一方で、小〜中規模のプロジェクトや、個人開発、プロトタイプ作成などでは、Kiroの方が適しています。シンプルで早く、それでいて品質も高いです。特に、スピードを重視したい場合や、少人数のチームで素早く開発したい場合には、Kiroの一気通貫のワークフローが効果を発揮すると思いました。

（今回は関数型プログラミングという高度なお題でしたが、Kiroはもっとシンプルなタスク、例えばCRUD操作やAPIの実装などにも使えます。そういった一般的なタスクであれば、エンジニア経験の浅い方でもKiroを使ってプロトタイプを作ることができるのではないかと思いました。）

個人的には、Kiroの「シンプルだけど必要十分」なアプローチが気に入っています。AIツールは複雑化しがちですが、Kiroは必要な部分に集中していて、かつ使いやすさも工夫されているなと思いました。

現状の課題感

1. 振り返りの内容に偏りがある
2. 副産物的な学習が少ない
3. ぱっと振り返れない内容のものがある

これらの課題を、Amazon Bedrockを活用したWebアプリで解決しました。

アプリケーションのイメージ：

• ユーザーが振り返りボタンを押す
• Notionデータベースの内容を取得する
• Bedrockに内容とプロンプトを送る
• 分析内容をフロントに送る

使用した技術

• Next 15 / TypeScript
• TailwindCSS v4
• Python / Boto3
• AWS
  ・Bedrock (gpt-oss-20b)
  ・S3 + CloudFrontによるフロント配信
  ・Lamda (Serverless Framework)
  
  
  

上記のようななるべく費用のかからない構成にしています。UIはGitHubのようなイメージで作成しました。また、今回はPythonやLamda、Noiton APIを初めて使用したため、自分で調べつつAmazon Q developerに手伝ってもらいながら実装をしました。

今回のゴールとしては「振り返りをAIに返却してもらう」までとして、過去の振り返り閲覧などはスコープ外にしました。(Nextの学習を深めるために見た目は実装しています)

やることを考える

設計や調査、実装に関するタスクを事前にプランニングしました。また、技術選定やデザイン作成、どの部分で生成 AIを活用するかなどの構想も行いました。

▼Miroでタスクを洗い出し

▼Miroで作成した github likeなデザイン

実装してみた

⭐️フロントの作成

コンテナプレゼンテーションを採用し、直感的にわかりやすい粒度でコンポーネントに分けて実装しました。Buttonは共通コンポーネントとして作成し、渡すpropsをオブジェクトのキーとして定義し、それに応じてCSSを切り替えるという実装をしました。枠レイアウトであるContainerの実装は、自作したButtonを参考にQ devにお願いしてみましたが、スムーズに実装してくれました。

また、ローディング処理といった軽微な作業もQ devにお願いしました。自分は普段ローディングの処理をuseStateとuseEffectやReact Hook formを活用した実装していましたが、Q devは <Susponse /> 使用した記述を提案しました。「生成 AI を使用することが副産物学習につながる」という点が、とてもモダンな学習方法だなと感じました。(Reactの標準機能を知ることができたのは良かった..と同時に公式ドキュメントをもっと読もう！と思いました)

⭐️AWSのセットアップ

基本的に自力でセットアップしてみました。Serverless.yml の記述やセッティングが難しかったなと感じました。

起こった問題：

• デプロイ時に serverless-python-requirements でエラーになる
  1. serverless Frameworkの進化: 新しいバージョンでは
  serverless-python-requirementsが組み込み機能になった
  ・プラグインとして追加する必要がない
  ・custom.pythonRequirements設定があれば自動で有効
  2. 互換性の問題: 外部プラグイン版の
  serverless-python-requirementsと組み込み版が競合してJSZipエラーが発生
  
  
  
  
  
  

Q devに聞くと上記のような返答が返ってきました。実際に調べてみても正しい情報であるため、Q devの手順通りに修正しました。自分だと時間がかかってしまう作業を一瞬で解決できたという点に驚きました。また、「Serverlessのスタック状態を確認する」などの簡単なAWS CLIコマンドも一瞬で出してくれたため、スムーズに作業ができました。

⭐️バックエンド

Q devを活用して下記の内容を実装しました。ファイル数も少なかったため、実装はスムーズに行うことができました。

• Pythonの記述や構文の質問
• Bedrockに送るプロンプトの相談
• Notionのレスポンスのイメージを出力
• リファクタリングの相談

振り返り方法は「ランダム」「直近の1件振り返り」で実装する想定であったため、Notionからの取得の部分に工夫が必要でした。Notionの仕様上、ランダム取得ができないため自前での実装が必要なのですが、この部分をQ devにお願いしてみました。しかし実装してもらった Notion取得時のレスポンスが異常に遅かったため、コードをみると「全てのデータを取得」後にランダムサンプリングしていました。そのため、「特定のidのみを取得」という実装の方がいいのではないか？という相談をQ devにしながら修正していきました。

デプロイしたもの

参考リンク：

• Serverless Framework の使い方を初心者にも分かりやすく説明する
• CloudFront + S3 で静的ページをホストするための Serverless Framework 設定
• Amazon BedrockでOpenAIのgpt-ossを試してみた！
• 【保存版】Python Notion 操作 （notion-sdk-py編）
• notion-sdk-py
• Notion API

以前、2025 Japan AWS Jr. Champions の活動の一環で、表題のような簡単なハンズオンを行いました。

その中身をブログに書き起こしたので、

• あまりAI触ったことないよ
• Amazon Q Developerはじめて触るよ
• 自分でもWebサービス作れるのかな

な人は一緒にやっていきましょう！

今回は、簡単なTODOリストを作っていきます。

■事前準備

今回使うものはこちらです。

• Visual Studio Code (VSCode): コードを書くエディターです。まずはこれをインストール！
• Amazon Q Developer (拡張機能): VSCodeの拡張機能としてインストールしていきます
• Live Server (拡張機能): こちらもVSCodeの拡張機能です。HTMLをプレビューするために使います

■つくりかた

Webサービスはざっくり、以下のような構成でできています。

• HTML: ページのコンテンツそのものを記述するもので、骨組みとなります
• CSS: HTMLの要素に対して、色や形、空白などを定義します
• JavaScript: いわゆる「プログラミング言語」で、HTMLに動きをつけることができる

今回はHTML→CSS→JavaScriptの順に作っていきます。

といっても、作るのはAmazon Q Developerですが！

■Amazon Q Developerをひらく

まずは適当なフォルダを作り、VSCodeを開きます。私はq-dev-todoというフォルダを作成しました。

VSCodeの左のタブに、「Amazon Q」のアイコンがあると思います。これをクリックして開くと以下のようになるかと思います。

Amazon Q Developerを使うために、「Builder ID」でログインするか、Proライセンスのサブスクリプション を行ってください。

無事ログインできると以下のようにチャット画面が開けます。

■HTMLをつくる

では、チャット画面で以下のように書いてみましょう。

これから、HTML・CSS・JavaScriptでシンプルなTODOリストを作成していきます。まずは、HTMLを作成してください。

私の画面ではこのように返ってきました。

VSCodeの画面左上、「エクスプローラー」ボタンを開くとindex.htmlが作成されていました。ここで、「index.html」を右クリックすると出てくる「Open with Live Server」を押してください。

すると、自動的にブラウザで http://127.0.0.1:5500/index.html のリンクが開いたはずです。TODOリストと書いてありますが、まだ何も動作しません。

■CSSをつくる

次に、見た目を整えていきます。チャットに以下を入力します。

次にCSSで見た目を整えます。シンプルでスタイリッシュ、モダンな見た目にしてください。

あえて抽象的な言い回しにしています。無事にCSSが作成されましたね。

ではどのような画面になったでしょうか？先程のhttp://127.0.0.1:5500/index.html に戻って見てみましょう。

青~紫のグラデーションがついて、かっこよくなりましたね。

みなさんはどんな見た目になりましたか？

■JavaScriptをつくる

ここまででは、まだTODOリストの「機能」ができていません。最後にJavaScriptを追加していきましょう。

最後に、JavaScriptで機能をつけてください。

では、実際にブラウザで使っていきましょう！

無事にタスクが追加されました！ついでに削除機能も作ってくれていますね。

■もし動かなかったら？

ブラウザでF12キーを押すと、「検証ツール」を開くことができます。

この検証ツールの「Console」で、以下のようにエラーを見ることができます。

このエラーをAmazon Q Developerのチャット画面に貼り付けて「修正してください」とお願いすればOKです。

■最後に

どうでしたでしょうか？初めての方も、意外と簡単だなーと思ったのではないでしょうか。

余力のある方は、チャットの続きで

• CSSを編集して見た目を自分好みに変えてみる
• JavaScriptを編集して機能を追加する
• WebサイトをAWSに公開する

などを試してみてください！

AWS re:Invent 2025の申し込みがそろそろ始まる頃かと思います。
そこで、昨年のSaaS関連ワークショップをいくつか紹介し、今年どのワークショップに参加するか検討する際の参考になれば幸いです。
昨年の内容を知ることで、最新のワークショップを見つけることができると思います。
※ワークショップはセッションのように公開されておらず、昨年参加できなかったワークショップはwebから見つけてきたものもあるので、一部間違いがあるかもしれません。ご了承ください。

Workshop 一覧

SAS301 - Solving the SaaS cost-per-tenant puzzle: An inside look

マルチテナントSaaS運営で多くの開発者が直面する「テナント別コストの見えにくさ」についてのアプローチを紹介します。
共有リソース環境ではインフラのタグ付けだけでは不十分で、アプリケーションが自ら利用状況を記録する「プールモデル」でどのように計測するかを知る必要があります。

まずはAPIログなどを活用した「粗粒度メトリクス」で大まかな傾向を把握し、必要に応じてLambda Extensionsなどを用いた「細粒度メトリクス」へ発展させることで、従量課金モデルにも対応できる手法を紹介しています。

• GitHub: aws-saas-tenant-usage-and-cost-attribution
• Workshop: リンク

SAS304 - Inside the SaaS Builder Toolkit: A hands-on deep dive [REPEAT]

AWSが提供する「SaaS Builder Toolkit (SBT)」は、マルチテナント管理や請求処理などの複雑な定型作業を、再利用可能なコンポーネントとして標準化したツールキットです。SBTが提示する「コントロールプレーン」と「アプリケーションプレーン」の分離、EventBridgeによるイベント駆動の疎結合設計、ScriptJobによる自動プロビジョニング、そして請求・認証を抽象化するプラグインアーキテクチャを紹介しています。

• GitHub: sbt-aws
• Workshop: リンク

SAS402 - SaaS survivor: Building a rich multi-tenant operations experience

マルチテナントSaaSの運用・分析方法を紹介しています。
テナントベースでメトリクスやログを管理する方法、うるさい隣人問題（noisy neighbor）を防ぎワークロードの公平性を確保する方法、
「あるテナントが他のテナントのデータに絶対にアクセスできない」状態をコードで保証する手法などを解説します。
さらに、アクセス防止だけでなくプロアクティブな監視・対策の実装方法も学びます。

• GitHub: aws-saas-operations-workshop
• Workshop: リンク

SAS403 - SaaS microservices deep dive: Multi-tenancy meets microservice

開発者がセキュアでスケーラブルなSaaSアプリケーションプレーンを構築できるよう、テナント分離をコードではなくIAM層で強制する「サイドカーTVM」や、
Istioによるインフラレベルのルーティング、JWTを用いた一貫したテナントコンテキスト伝播などを紹介しています。

「サイドカーTVM」は各マイクロサービスの隣で動作し、IAMポリシーによってテナントごとのアクセスを厳密に制御する仕組みです。
さらに、Amazon Verified Permissionsによる認可ロジックの外部化や、テナント別メトリクス分析によるビジネスインサイトの獲得方法も紹介しています。
全体として、アプリケーションからプラットフォーム層にオフロードできる機能設計の解説となっています。

• GitHub: aws-saas-factory-saas-microservices-workshop
• Workshop: リンク

SAS404 - Automate SaaS provisioning & deployment with Kubernetes DevOps tooling

「開発者主導のインフラ（Developer-Driven Infrastructure）」という思想を、GitOpsで実現する方法を紹介しています。
単一のHelmチャートで全ティアを統一管理し、イベント駆動の自動ワークフローでゼロタッチなテナント運用を実現する方法やECRからのイメージ削除による自己修復ロールバックや、段階的に展開する「ウェーブデプロイメント」で安全性を高める手法も紹介しています。

• GitHub: eks-saas-gitops
• Workshop: リンク

SAS405 - SaaS and RAG: Maximizing generative AI value in multi-tenant solutions

生成AIとRAG（Retrieval-Augmented Generation）を活用したPoC（概念実証）を、本番運用可能なマルチテナントSaaSへ発展させる際の課題を紹介しています。
動的プロビジョニングによるテナント分離、ABAC（属性ベースアクセス制御）による防御的設計、トークンベースのスロットリングによる「うるさい隣人」問題の解消、
そしてIAMロール命名を活用した正確なコスト按分など、実践的なアプローチを解説しています。

• GitHub: aws-saas-genai-rag-workshop
• Workshop: リンク

ARC402 - Scaling multi-tenant SaaS with a cell-based architecture

AWSが導入している「セルベースアーキテクチャ」を紹介しています。
この設計は、ハイパーグロース期において高可用性と堅牢な運用を維持するための有効な基盤です。
アプリケーションを独立した「セル」に分割し、障害を局所化・制御可能にすることで、従来のプール型モデルのスケーリング限界や影響範囲拡大を克服します。

セル管理システム、セルルーター、セルアプリケーションプレーンという3つの主要コンポーネントにより、プロビジョニング・ルーティング・運用を自動化。
さらに、段階的デプロイ（staggered deployments）やリバランシングを活用して、安全かつ柔軟なスケーリングを実現します。

• GitHub: aws-saas-cell-based-architecture
• Workshop: リンク

まとめ

全体としてマルチテナントSaaSの基礎からさまざまなアーキテクチャを紹介していました。また、生成AIなど最新のトレンドやセルベースアーキテクチャという新しいトピックもワークショップになっていて感動しました。
今年もトレンドを反映したワークショップが出ると思いますので、ぜひ参加してみてください！

ということで、昔はプログラマーとしては当たり前の情報でしたが、昨今はWebアプリケーションエンジニアは目にすることも少なくなった情報を、改めて書いておきたいと思います！

リンク？？？

みなさん、「リンク」って聞いたことありますか？いえ、HTMLの<a>タグの話ではありません。もちろん、ゼルダの伝説でおなじみのあの方でもなければ、イナバウワーのステージでもありません。今回は、プログラムが実行ファイルになるまでの「リンク」という工程について、C言語を例にお話しします。文章だとしても。

なぜこの話が必要なのか

「リンクとかよく知らないけど、Go言語でgo buildしたら実行ファイルができる。それで十分じゃない？」

もうおっしゃるとおり！でも、たとえば：

• Dockerイメージのサイズを小さくしたい
• ライブラリの更新でアプリを再ビルドせずに済ませたい
• 「shared library not found」的なエラーに遭遇してもう無理ってなった

こんなとき、リンクの仕組みを知っていると解決の糸口が見えてきます。

まずは全体像：プログラムができるまで

C言語のプログラムが実行ファイルになるまでには、実は複数のステップがあります。

hello.c (ソースコード)
    ↓ コンパイラによるコンパイル
hello.o (オブジェクトファイル)
    ↓ リンカによるリンク
hello (実行ファイル)

Go言語との違い：Goの場合、go buildで一気に実行ファイルになります。内部的には似たようなプロセスを経ていますが、中間ファイル（.oファイル）は通常見えません。Goは開発者体験を重視して、こうした複雑さを隠してくれているんですね。たぶん！

コンパイラとリンカ：役割分担

コンパイラの仕事

コンパイラは、人間が読めるソースコード（.c）を、機械が理解できる機械語に翻訳します。

// hello.c
#include <stdio.h>

int main() {
    printf("Hello, Sofmap World!\n");
    return 0;
}

これをコンパイルすると：

$ gcc -c hello.c -o hello.o

できるもの：hello.o（オブジェクトファイル）

このファイルは機械語になっていますが、まだ実行できません。なぜなら、printfという関数の本体がどこにあるかわからないからです。

#include <stdio.h>

で、どっかしらに printf という関数が、こういう引数でこういう戻り値でこういう型で、というのがわかります。そして、コンパイラはそれをもとに構文が合っているかがチェックできます。しかし、その呼び先の関数の実態がどこなのかはまだ謎です！

Reactでの例え：Reactコンポーネントでimport { useState } from 'react'と書いたけど、まだReactライブラリ本体とつながっていない状態、みたいなイメージです。

リンカの仕事

リンカは、複数のオブジェクトファイルやライブラリを結合して、実行可能なファイルを作ります。

gcc hello.o -o hello

このとき、リンカは「printfの本体はこのライブラリにあるよ」と教えてもらい、それらを全部つなぎ合わせます。

今回は１つの .o ファイルですが、複数の .o ファイルを結合することができます。また、 printf に関しては、いわゆる標準ライブラリ(たまに目にする glibc だと思ってください)に入っているので、Cコンパイラは明示しなくてもどこにリンクすれば良いのか知っているため、引数にそれっぽいものをつけなくても大丈夫です。逆に、標準じゃない系のものは明示する必要があります。

.oファイルとは何か

.o（オブジェクトファイル） は、コンパイルされた機械語のかたまりです。

特徴：

• まだ実行できない中間形式
• 複数の.cファイルをコンパイルすると、それぞれに対応する.oファイルができる
• これらを後でリンカが組み合わせる

実例：

// math_utils.c
int add(int a, int b) {
    return a + b;
}

// main.c
#include <stdio.h>
int add(int, int); // 関数の宣言

int main() {
    printf("2 + 3 = %d\n", add(2, 3));
    return 0;
}

コンパイル：

gcc -c math_utils.c -o math_utils.o
gcc -c main.c -o main.o

この時点で、main.oには「addっていう関数を使いたい」という情報はあるけど、その実体はまだつながっていません。

リンク：

gcc main.o math_utils.o -o myapp

これで初めて実行ファイルmyappが完成します。

Goとの比較：Goでも複数の.goファイルを書きますが、go buildが自動的にすべてを処理してくれます。中間の.oファイルにあたるファイルは一時的なディレクトリに作られるため普段意識する必要はありません。

スタティックリンクとは

スタティックリンク（静的リンク）は、リンク時にライブラリのコードをすべて実行ファイルに埋め込む方式です。

仕組み

main.o + libmymath.a (静的ライブラリ) 
    ↓ スタティックリンク
myapp (実行ファイル：全部入り)

.a ファイル：複数の.oファイルをまとめたアーカイブ。Windowsでは.libという拡張子になります。

メリット

1. 配布が簡単：実行ファイル1つで完結するので、他のファイルが不要
2. 依存関係の心配なし：ライブラリがシステムにインストールされてなくても動く

つまり、Goと同じようにバイナリ１つで動くイメージ！

デメリット

1. ファイルサイズが大きい：すべてのコードが含まれるため
2. 更新が大変：ライブラリにバグ修正があっても、アプリを再ビルドしないと反映されない
3. メモリ効率が悪い：同じライブラリを使う複数のアプリが起動すると、それぞれがコードのコピーをメモリに持つ

Goとの比較：Goのgo buildは基本的にスタティックリンクです！だからGoの実行ファイルは大きめですが、1つのバイナリで完結するので、Dockerイメージに入れるときもFROM scratch (何にも入っていないコンテナから作る) が使えて便利なんです。

FROM scratch
COPY myapp /
CMD ["/myapp"]

※Goでも、バージョンや環境によっては内部でダイナミックリンクすることもありますが、このブログではわかりやすくするために、スタティックリンクしているということにしています

ダイナミックリンクとは

ダイナミックリンク（動的リンク）は、実行時にライブラリを読み込む方式です。

仕組み

main.o + libmymath.so への参照
    ↓ ダイナミックリンク
myapp (実行ファイル：参照情報のみ)

実行時に...
myapp → libmymath.so を探して読み込む

.so ファイル（Shared Object）：動的に読み込まれる共有ライブラリ。Windowsでは.dll、macOSでは.dylibという拡張子になります。

メリット

1. ファイルサイズが小さい：実行ファイルには参照情報だけ
2. メモリ効率が良い：複数のアプリが同じライブラリを共有できる
3. 更新が容易：ライブラリだけ差し替えれば、すべてのアプリに反映される

デメリット

1. 配布が複雑：実行ファイルと一緒に.soファイルも配布が必要
2. 依存関係の管理：「ライブラリが見つからない」エラーが実行時に初めて起きてしまう
3. バージョン地獄：ライブラリのバージョン違いで動かないこともあったりする

よく見るエラー：

./myapp: error while loading shared libraries: libmymath.so: 
cannot open shared object file: No such file or directory

これは「動的ライブラリが見つからないよ」というエラーです。

実際に試してみよう

スタティックリンクの例

# 静的ライブラリを作る
gcc -c math_utils.c -o math_utils.o
ar rcs libmymath.a math_utils.o

# スタティックリンク
gcc main.c -L. -lmymath -static -o myapp_static

# ファイルサイズを確認
ls -lh myapp_static
# 例：800KB

ダイナミックリンクの例

# 共有ライブラリを作る
gcc -fPIC -shared math_utils.c -o libmymath.so

# ダイナミックリンク
gcc main.c -L. -lmymath -o myapp_dynamic

# ファイルサイズを確認
ls -lh myapp_dynamic
# 例：16KB

# 依存関係を確認
ldd myapp_dynamic
# libmymath.so => ./libmymath.so

サイズの違いに注目してください！

実務でよくあるシーン

Dockerイメージが大きすぎる問題

スタティックリンクされたGoアプリは大きいですが、動的ライブラリ不要なのでFROM scratchが使えます。

一方、動的リンクされたアプリは小さいですが、必要なライブラリをすべてイメージに含める必要があります。

# よくある解決策：Alpine Linuxを使う
FROM alpine:latest
RUN apk add --no-cache libc6-compat
COPY myapp_dynamic /
CMD ["/myapp_dynamic"]

ライブラリの脆弱性対応

スタティックリンク：OpenSSLに脆弱性が見つかった場合、すべてのアプリを再ビルド・再デプロイ

ダイナミックリンク：OpenSSLの.soファイルだけ更新すれば、すべてのアプリに反映（再起動は必要）

システムライブラリとの関係

LinuxやmacOSには、標準Cライブラリ（libc/glibc）など、OSが提供する共有ライブラリがあります。多くのプログラムはこれらを動的にリンクして使います。

# MacでNode.jsの依存関係を見る
otool -L $(which node)

# 複数の.dylibが並ぶはず

まとめ

どちらを選ぶべきか

スタティックリンクが向いている場合：

• シンプルな配布を優先したい
• Dockerコンテナでscratchベースとかで使う
• セキュリティのために依存を最小化したい

ダイナミックリンクが向いている場合：

• 複数のアプリで同じライブラリを使う
• ライブラリの頻繁な更新が必要
• メモリ使用量を抑えたい

ものすごくざっくり言えば、プログラミングで共有の関数を作るか、自分しか使わない関数を作るか、のようなイメージです！（ちょっと違うけど）

おわりに

Web開発では意識しない「リンク」の世界を楽しんでいただけましたでしょうか？！

普段GoやReactで開発していると、こうした複雑なことを意識しないでも開発できます。でも、その裏側を知ることで、コンピュータの気持ちがわかるようになり、例えばDockerイメージの最適化や、ライブラリエラーのトラブルシューティングがぐっと楽になったりもします。

次に「shared library not found」的なエラーに出会ったら、「ああ、動的リンクで.soファイルが見つからないんだな」と余裕を持って対応できるはずです！

こんな感じで、昨今は学ばなくても特にプログラミングで困らないが、知ってると楽になる系のお話を書いていきたいと思います！最近は、生成AIでプログラム書いてもらったけどどうしても動かない場面、なんかにも有用かもしれません！

こちらからは以上です。

以前、一般社団法人 日本CTO協会「新卒合同研修」にて、BtoB SaaS開発基礎講座をやってきましたので、ご紹介です。

日本CTO協会が新卒エンジニアを業界全体・企業横断で育てる試み「新卒エンジニア向けの合同研修」を5月29日から実施 ｜一般社団法人 日本CTO協会

「テクノロジーによる自己変革を、日本社会のあたりまえに」というミッションを掲げ、世界最高水準の技術者育成を図ることにより、日本経済の発展に資することを目的としています。

一般社団法人 日本CTO協会

資料はこちらです！

https://speakerdeck.com/yaggy/btob-saaskai-fa-ji-chu-jiang-zuo

この講座の目的は、資料に記載のとおり

「SaaSって、こんなこと考えないといけないんだな〜〜〜」
っていうのをほんのりわかってもらって、本当の仕事の場面でこういうのが必要になった時に、
「あ、そういえばSaaSってそういうの必要だって言ってたな〜
　チームでいろいろ試行錯誤してたわそういえば」
って思い出してもらえるようにする！

※そのため、厳密には間違ってるけどだいたい雰囲気をわかってもらう

となっております。

実際に、資料に沿ってやっていただくとわかるようになっていますので、ぜひやってみてください。研修ではチームで行いましたが、１人でも可能ですのでチームのところは読み飛ばしてやってみていただければと思います。

全体の流れとしては、

• SaaSってなんなの？
• エンジニアとしてSaaS開発で気をつけないといけないポイントは？
• まずは、特にテナント分離を考えないとですね
• テナント分離モデルもいろいろあります
• 実際にSaaS開発もどきの体験をしましょう
• ふつうのチャットアプリケーションをマルチテナント化してみましょう
• そのためには、認証、テナントコンテキストというのを実装しましょう
• 自前で気軽にテナント実装したらセキュリティ的にやばいことになった・・・
• 自前SaaSにブルートフォース攻撃（総当たり攻撃）をしてみましょう
• SQLインジェクション攻撃をしてみましょう
• やばかった部分を改善してみましょう
• まとめ
• SaaSus Platformの宣伝

という流れになっております。

超基礎的な内容ですが、意外とやったことないものも含まれているかもしれませんので、ぜひやってみてください〜！

こちらからは以上です。

みなさんこんにちは！アンチパターンでSaaSus Platformのマーケティングも担当している野川です！

先日、私たちは「Horizontal SaaS 1,226種のAPI提供・公開状況」に関する調査レポートを公開しました。本レポートは、日本のSaaS業界におけるAPI提供・公開状況を分析したものです。今回のブログでは、そのレポートでは語りきれなかった「舞台裏」についてお伝えします。

※調査レポートはこちら：https://saasus.io/blog/horizontal-saas-api-report

実はこの調査、SaaSus Platformの新規機能「Smart API Gateway 機能」のリリースに合わせた記者発表会のために、限られた時間で進める必要がありました。私と、調査のイニシアチブを取ったもう一人のメンバーは、タイトなスケジュールの中、ロゴを一つひとつ画像検索し、マニュアルを作成し、時には深夜まで目を凝らして調査とレビューを繰り返しました。これは、まさに汗と涙の結晶です。

この記事を通じて、レポートの数字が持つ意味をより深く感じていただければ幸いです。

1. 調査の全貌：地道な作業の始まり

調査の対象は、SaaS比較サイト「BOXIL」を運営するスマートキャンプ株式会社が公開した「SaaS業界レポート2024」のSaaSカオスマップに掲載されている1,226のHorizontal SaaSです。調査は、私とメンバー、そして調査に協力してくれたチームメンバーで分担して進めました。誰がやっても同じ結果になるように、まず最初に取り掛かったのが「詳細な調査マニュアル」の作成でした。

ロゴを画像検索して製品URLを特定する。運営会社を調べて本社所在地から国内外を判断する。そして、「製品名 + API」といった検索キーワードを駆使し、APIの有無を確認する...。これらの手順を一つひとつ言語化し、調査メンバーが迷わないように細かく定義しました。

しかし、現実はマニュアル通りにはいきません。

例えば、似たようなロゴのサービスが検索に多数ヒットしたり、APIに関する情報がウェブサイトの非常に深い階層に埋もれていたり、そもそもサービスサイトが見つからなかったり。そんな想定外のケースに遭遇するたびに、マニュアルを更新し、判断基準を擦り合わせていきました。メンバーが調査した結果を私たちがレビューする作業も、慎重さが求められるものでした。

2. 調査で見えてきた「日本のSaaSのリアル」

こうして、膨大な時間をかけて集めたデータを分析する中で、レポートには書ききれなかった「日本のSaaSのリアル」が見えてきました。

今回の調査で特に印象的だったのは、APIの「発見性の低さ」でした。海外製品の多くは、APIドキュメントへのリンクをウェブサイトのヘッダーやフッター、または専用のデベロッパーページに明確に表示しています。しかし、国内製品では、APIを提供していても、ウェブサイトの深い階層に埋もれているケースが多々ありました。

これは、APIを積極的にアピールして外部サービスとの連携を促すというよりも、あくまで「付随的な機能」として捉えているようにも感じ、日本のSaaS企業特有の姿勢が垣間見えたように感じました。

なぜこのような姿勢が生まれるのでしょうか。その背景には、長らく個別カスタマイズを中心としたSIer（システムインテグレーター）が主導してきた日本のIT市場の特性が考えられます。SIerが顧客の要望に合わせてシステムを個別に構築・運用してきたため、サービスをAPIでオープンに連携させて利用するという「エコシステム型」の発想が、海外に比べて定着しにくかった側面があるのではないでしょうか。

3. まとめ：調査を通じて伝えたいこと

今回の調査は、日本のSaaS業界にAPIエコノミーの重要性を認識してもらうための一歩です。

今や、APIは単なる機能ではないと感じています。AIエージェントが台頭するこれからの時代、APIは企業の競争力を左右する重要な要素になると感じています。今回の調査で見えた「APIの価値に対する認識を深めること」が、日本のSaaSがグローバル市場で戦うためのカギとなるのではないでしょうか。

このブログが、皆さまの中で、API公開の価値について考えるきっかけを醸成できれば幸いです。

NotebookLMとは？

NotebookLMは、アップロードした資料に基づいて対話ができる、AI搭載のノートブックです。PDFやテキストファイル、Googleドキュメントなどを「ソース」として読み込ませることで、その内容に関する質問に答えたり、要約を作成したり、アイデア出しを手伝ってくれたりします。

今回は、このNotebookLMの機能を活用し、法務業務の効率化を目指します。

やってみたこと：e-Gov法令検索から「社内法令チャットボット」を作る

具体的な手順は非常にシンプルです。

1. 関連法令のPDFをダウンロードする

まずは、e-Gov法令検索（https://elaws.e-gov.go.jp/）から、自社の事業に深く関連する法令の条文をPDF形式でダウンロードします。

1. NotebookLMにソースとしてアップロードする

次に、NotebookLMを開き、新しいノートブックを作成します。そこに、先ほどダウンロードした法令のPDFファイルをすべてアップロードします。これだけで準備は完了です。

これだけで、アップロードした法令の範囲内で、質問に答えてくれるチャットボットが完成しました。

LM六法の「良いところ」

実際に使ってみて、特に便利だと感じた点は以下の2つです。

1. 事案に対して関連しそうな法令を瞬時にピックアップ＆参照できる

例えば、新しい取引先との契約形態について検討している際に、「この業務委託契約は、偽装請負とみなされるリスクはありますか？」と質問を投げかけたとします。

するとNotebookLMは、アップロードした労働基準法や職業安定法などの条文の中から、偽装請負の判断基準に関連する箇所を瞬時に探し出し、参照元（どの法令の第何条か）を明記した上で回答を生成してくれます。

法務的な回答を用意する際に、該当する法令を提示するケースも割とありますが、従来であれば、それぞれの法令を一つひとつ確認し、該当箇所を探す必要がありましたが、このプロセスをAIが代行してくれるため、調査の初動にかかる時間を劇的に短縮できます。

2. 従業員への説明用に、平易な文章への翻訳や例示のアイデアを引き出せる

法務部門の重要な役割の一つに、従業員への教育や啓発があります。しかし、法令の条文は難解な表現が多く、そのまま伝えてもなかなか理解してもらえません。

そこでNotebookLMに、わかりやすく解説するように指示を出します。例えば「民法における『悪意』と『善意』の用語の意味を小学生でもわかるように教えて」 といった指示を出すと、非常に分かりやすい言葉で説明文を生成してくれたり、具体的なシナリオを提示してくれたりします（画像は思ったよりも小学生扱いされてます）。

これにより、社内向けの研修資料やマニュアルを作成する際の大きな助けとなりました。

微妙なところ

もちろん、良いことばかりではありません。現状の課題も見えてきました。

1. 継続的なソースの更新が必要で、古い情報を参照するリスク

最大の懸念点は、情報の鮮度です。法令は頻繁に改正されます。一度PDFをアップロードしても、その後の法改正には対応できません。古い情報のまま参照し続けると、誤った判断を下すリスクがあります。

これを防ぐためには、法改正の情報をキャッチアップし、定期的に最新の条文PDFをダウンロードしてソースを更新するという、地道なメンテナンスが不可欠です。

2. PDFのダウンロードが面倒

e-Gov法令検索から一つひとつPDFをダウンロードする作業は、正直なところ少し手間がかかります。NotebookLMがURLを指定するだけでそのページの内容をソースとして読み込んでくれれば理想的なのですが、e-Gov法令検索のサイト構造が複雑なためか、現状ではうまく機能しませんでした。

今後に期待？

• 従業員にも公開し、簡易的なリーガルチェックツールとして活用

ソースの鮮度管理を徹底した上で、このNotebookLMを従業員に公開すれば、「法務部に確認する前の一次チェック」として活用できるかもしれません。これにより、現場のコンプライアンス意識向上と、法務部門の業務負荷軽減の両方が期待できます。

ただ、現状ではあくまでも既存の法令のみを対象としているので、新規事業には向かなそうではあるのと、ソースが条文なので質問の仕方によってはいまいちな感じもあり、現時点では「わかってる人向け」な雰囲気でした。

• 法令集と社内規定を組み合わせて、より社内の問い合わせに特化させる

従業員向けのボットとしてより効果を発揮させるには、法令と社内規定を一つのノートにまとめて運用する方法が良さそうでした。例えば、労働基準法や労働契約法といった法令集に加えて、自社の「就業規則」もソースとして読み込ませれば、「当社の規定では、このケースの残業は認められますか？」といった、より具体的で実践的な質問に答えられるようになります。

その他活用アイデア

• 法令の趣旨や概要を「音声出力」でインプット

NotebookLMには音声出力機能もあります。条文の「趣旨」は、その法令の根幹を理解する上で非常に重要です。概要や制定の背景などを要約させ、移動中や作業中に音声で「聴く」ことで、効率的なインプットが可能です。

• 「マインドマップ」で索引的に検索

「個人情報保護法に関連する概念をマインドマップで整理して」と指示すれば、全体像を視覚的に把握しやすくなります。複雑な法令の構造を理解する上で、強力な助けとなるでしょう。

ソースの数が多いとうまくいかないことが多いので、うまく分割して出すといい感じになります。僕は目次を作成してから目次でマインドマップを作ってました。気になるところをクリックするとそれに関する情報をくれるので、入力が少なくて楽です。

まとめ

NotebookLMを使った「LM六法」の構築は、情報の鮮度管理という課題はあるものの、法務関連業務を大幅に効率化し、その質を高める可能性を秘めていると感じました。特に、散在する情報の中から関連箇所を瞬時に探し出す能力や、難解な内容を分かりやすく翻訳する能力は、日々の業務において大きな武器となります。

現時点では法務担当者が個人的な業務効率化目的で使用するに止まりそうですが、いちいち法令を検索したりする手間をなくして、手元に社内の関連法令を持っておけるだけでもとても便利に感じました！

最近、GitHub Copilot や Roo Code など、AI を使ってコードを書くことが増えてきました。
プロンプトでなるべく具体的な指示をすることで精度が向上します。
例えば、自分は以下のように書くことが多いです。

「ファイルAのn行目の関数Bを(使用/修正/参考に)してください」

しかし、このプロンプト文を書くのが地味に面倒でした。自分は開発に Visual Studio Code (VS Code) を使用していますが、
ファイル名をコピペ→行数を入力→関数名等をコピペ
のように書いていました。

そこで、ファイル名と行数をまとめてコピーできる拡張機能を作成しました。

作成した拡張機能

• VS Code Marketplace
  https://marketplace.visualstudio.com/items?itemName=yutakahashi114.copy-with-file-path
  

• GitHub
  https://github.com/yutakahashi114/copy-with-file-path
  

実装は非常に単純で、以下のようにファイル名と行数を合わせてクリップボードにコピーしています。

function getTextToCopy(relativePath: string, selection: vscode.Selection, selectedText: string): string {
    if (!selectedText) {
        // テキストが選択されていない場合：カーソル位置の行番号のみ
        const currentLine = selection.active.line + 1; // VSCodeの行番号は0ベースなので+1
        return `${relativePath} (line ${currentLine})`;
    }

    // テキストが選択されている場合：選択範囲の行番号を取得
    const startLine = selection.start.line + 1;
    const endLine = selection.end.line + 1;

    if (startLine === endLine) {
        // 単一行の場合
        return `${relativePath} (line ${startLine}) ${selectedText}`;
    }

    // 複数行の場合
    return `${relativePath} (lines ${startLine}-${endLine})
${selectedText}`;
}

できること

Cmd+Alt+C (Mac) / Ctrl+Alt+C (Windows/Linux) で、以下のようにファイル名と行数をコピーできます。

• テキストを選択していない場合
  カーソル位置のファイル名と行数のみをコピー
  

  src/extension.ts (line 15)
  

• テキストを選択している場合
  選択したテキストとともに、ファイル名と行数をコピー
  

  src/extension.ts (line 15) editor
  

• 複数行選択している場合
  範囲を含む行数情報をコピー
  

  src/extension.ts (lines 15-17)
  const editor = vscode.window.activeTextEditor;
  if (!editor) {
      return;
  }
  

おわりに

この拡張機能を使用してから、プロンプトを書く手間が減りました。細かい指示を書くことを面倒に感じることが少なくなり、結果としてより正確に AI に指示を出すようになり、開発効率が向上しています。
ぜひ一度お試しください。

こんにちは、いわむらです。

はじめに

Laravel 11がリリースされ、CORS設定の方法に変更がありました。過去のバージョンではconfig/cors.phpファイルがデフォルトで存在していましたが、Laravel 11では手動で作成する必要があります。

本記事では、Laravel 11における適切なCORS設定方法と、本番環境でも安全に運用できる環境分離の方法について解説します。

Laravel 11でのCORS設定の変更点

Laravel 11では、CORS設定ファイル（config/cors.php）がデフォルトで含まれなくなりました。過去のバージョンでは、新しいLaravelプロジェクトを作成すると、CORS設定ファイルが最初から存在していました。

設定ファイルの作成

Laravel 11でCORS設定が必要な場合は、以下のコマンドで設定ファイルを作成する必要があります：

php artisan config:publish cors

この変更により、CORSが不要なプロジェクトでは余計なファイルが生成されず、必要な場合のみ明示的に設定を追加することになります。

Laravel 11での正しいCORS設定

ステップ1: CORS設定ファイルの作成

Laravel 11では、以下のコマンドでCORS設定ファイルを作成できます：

php artisan config:publish cors

このコマンドにより、config/cors.php ファイルが作成されます。

ステップ2: 環境変数ベースの設定

作成された設定ファイルを環境変数ベースに変更します：

<?php
// config/cors.php

return [
    'paths' => ['api/*', 'sanctum/csrf-cookie'],

    'allowed_methods' => ['*'],

    // ❌ 危険な設定
    // 'allowed_origins' => ['*'],
    
    // ✅ 環境変数ベースの安全な設定
    'allowed_origins' => [
        env('FRONTEND_URL', 'http://localhost:3000'),
    ],

    'allowed_origins_patterns' => [],

    'allowed_headers' => ['*'],

    'exposed_headers' => [],

    'max_age' => 0,

    // ✅ 環境に応じて制御
    'supports_credentials' => env('CORS_SUPPORTS_CREDENTIALS', false),
];

ステップ3: 環境変数の設定

.env ファイルに適切な環境変数を追加：

# CORS Configuration
FRONTEND_URL=http://localhost:3000
CORS_SUPPORTS_CREDENTIALS=false

ステップ4: ミドルウェアの設定確認

Laravel 11では bootstrap/app.php でミドルウェアが管理されています。CORSミドルウェアは自動的に適用されますが、必要に応じて追加設定も可能です：

<?php
// bootstrap/app.php

use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        api: __DIR__.'/../routes/api.php',
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        // Sanctumを使用している場合
        $middleware->api(prepend: [
            \Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class,
        ]);
        
        // 必要に応じてCORSミドルウェアのエイリアス設定
        $middleware->alias([
            'cors' => \Illuminate\Http\Middleware\HandleCors::class,
        ]);
    })
    ->withExceptions(function (Exceptions $exceptions) {
        //
    })->create();

環境分離の方法

開発環境

# .env (開発環境)
FRONTEND_URL=http://localhost:3000
CORS_SUPPORTS_CREDENTIALS=false

ステージング環境

# .env (ステージング環境)
FRONTEND_URL=https://staging-app.example.com
CORS_SUPPORTS_CREDENTIALS=true

本番環境

# .env (本番環境)
FRONTEND_URL=https://app.example.com
CORS_SUPPORTS_CREDENTIALS=true

複数のフロントエンドドメインがある場合

管理画面など、複数のフロントエンドがある場合の設定例：

// config/cors.php
'allowed_origins' => [
    env('FRONTEND_URL'),
    env('ADMIN_FRONTEND_URL'),
    // 本番環境で複数のサブドメインを許可する場合
    'https://admin.example.com',
],

# .env
FRONTEND_URL=https://app.example.com
ADMIN_FRONTEND_URL=https://admin.example.com

セキュリティ上の重要な注意点

1. ワイルドカード設定の回避

// ❌ 本番環境では絶対に使用しない
'allowed_origins' => ['*'],

// ✅ 明示的にドメインを指定
'allowed_origins' => [
    env('FRONTEND_URL'),
    // 必要に応じて追加のドメイン
    'https://admin.example.com',
],

2. 認証情報の適切な管理

// 認証が必要なAPIの場合
'supports_credentials' => env('CORS_SUPPORTS_CREDENTIALS', true),

// 公開APIの場合
'supports_credentials' => false,

認証情報を含むリクエスト（Cookie、Authorization ヘッダーなど）を扱う場合は、supports_credentials を true に設定し、allowed_origins にワイルドカード（*）は使用できません。

3. パスの限定

// 必要最小限のパスのみ許可
'paths' => [
    'api/*',           // APIルート
    'sanctum/csrf-cookie', // CSRF保護用（Sanctum使用時）
],

動作確認とトラブルシューティング

テスト用エンドポイントの作成

設定が正しく動作しているか確認するため、テスト用APIエンドポイントを作成します：

<?php
// routes/api.php

use Illuminate\Support\Facades\Route;

Route::get('/test-cors', function () {
    return response()->json([
        'message' => 'CORS is working!',
        'timestamp' => now(),
        'origin' => request()->header('Origin'),
    ]);
});

よくある問題と対処法

1. プリフライトリクエスト（OPTIONS）が失敗する

// フロントエンドでのテスト例
fetch('http://your-api.com/api/test-cors', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'Authorization': 'Bearer your-token'
    },
    body: JSON.stringify({ test: 'data' })
})

この場合、ブラウザは自動的にOPTIONSリクエストを送信します。allowed_methods に ['*'] または ['POST', 'OPTIONS'] が含まれていることを確認してください。

2. 認証情報付きリクエストが失敗する

// 認証情報を含むリクエスト
fetch('http://your-api.com/api/user', {
    method: 'GET',
    credentials: 'include', // これが重要
    headers: {
        'Authorization': 'Bearer your-token'
    }
})

この場合、supports_credentials が true に設定されており、allowed_origins にワイルドカードが使用されていないことを確認してください。

デバッグ用の設定

開発中にCORSの動作を詳しく確認したい場合：

// config/cors.php (開発環境でのデバッグ用)
return [
    'paths' => ['api/*', 'sanctum/csrf-cookie'],
    'allowed_methods' => ['*'],
    'allowed_origins' => [
        env('FRONTEND_URL', 'http://localhost:3000'),
    ],
    'allowed_origins_patterns' => [],
    'allowed_headers' => ['*'],
    'exposed_headers' => ['X-Debug-Info'], // デバッグ情報用
    'max_age' => 0, // キャッシュ無効（開発時）
    'supports_credentials' => env('CORS_SUPPORTS_CREDENTIALS', false),
];

まとめ

Laravel 11でのCORS設定は、フレームワーク標準の機能を使用することで以下のメリットを得られます：

保守性の向上

• 設定ファイルの手動作成により、不要な設定を排除
• 環境変数による柔軟な設定管理

セキュリティの強化

• 明示的なドメイン指定によるセキュリティリスクの軽減
• 環境ごとの適切な認証情報管理

運用の安全性

• 環境分離による設定ミスの防止
• 本番環境での意図しないアクセス許可の回避

特に本番環境では、ワイルドカードの使用を避け、必要最小限のドメインのみを許可することが重要です。開発段階から環境変数ベースの設定を心がけることで、安全で保守性の高いAPIを構築できます。

CORS設定は一度正しく設定すれば、基本的にメンテナンスの必要がない部分です。しかし、新しいフロントエンドドメインの追加や、認証方式の変更時には設定の見直しが必要になるため、この記事を参考に適切な設定を維持してください。

参考リンク

• Laravel 11 Documentation - CORS
• MDN Web Docs - CORS
• Laravel Sanctum Documentation

こんにちは、いわむらです。

プルリクエスト（PR）のレビューコメントを確認・整理したい時、GitHub上でひとつひとつ確認するのは面倒だなぁと思い、最初はGitHub CLIを使ったらコメントをローカルで確認できてまとめて参照できるんじゃないか？と思い試行錯誤していました。

でも、複雑なシェルスクリプトを書いたりjqコマンドを駆使したりと、なかなか複雑なのができあがっちゃいました...。そんな時にRooCodeとGitHubのMCP Serverの組み合わせを試してみたら、簡単にレビューコメントの整理ができるようになったので、ブログにしてみました。

解決したかった課題

PRレビュー対応で困っていたのは以下のような点でした：

1. レビューコメントの見落とし: GitHub上で複数のコメントを確認していると、対応漏れが発生しやすい
2. 優先度の判断: どのコメントから対応すべきか判断に時間がかかる
3. 進捗管理の難しさ: どこまで対応したか把握しにくい
4. 作業時間の見積もり: 全体の作業量が見えにくい

これらの課題を解決するために、レビューコメントを自動で整理し、優先度付きのチェックリストを作成できる仕組みを探していました。

セットアップ方法

今回はRooCode 3.20のMarketplace機能を使用してGitHub MCPを追加しました。

RooCode Marketplace機能の利用

RooCode 3.20で導入されたMarketplace機能を使用すると、簡単にGitHub MCPを追加できます：

1. RooCode 3.20以降を使用
2. MarketplaceからGitHub MCPを検索・追加
3. Personal Access Tokenを設定（repo権限が必要）
4. 接続確認

セットアップは非常にシンプルで、数分で完了しました。

実際に試してみた結果

最初のアプローチ：簡単な指示

セットアップ完了後、まずは以下のような簡単な指示を試してみました：

"PRレビューコメントを確認して対応リストを作成して"

結果: 一般的なPRレビュー対応のテンプレートやガイドラインが生成されました。これはこれで有用でしたが、具体的なPRのレビューコメントは取得されず、汎用的なチェックリストが作成されるに留まりました。

改善したアプローチ：具体的な指示

次に、より具体的な指示を試してみました：

"todo-appの現在のブランチのPRを参照してレビューコメントを全て取得して修正のチェックリストを作成して"

結果: 実際のPRのレビューコメントを取得・分析し、具体的な修正項目を含むチェックリストが生成されました。

得られた成果

自動化された処理フロー

具体的な指示を出すと、以下のような処理が自動で実行されました：

1. 現在のブランチを確認 → feature/todo-refactor
2. 該当するPRを検索 → PR #123を発見
3. レビューコメントを取得 → 11件の個別コメント + 複数の総合レビュー
4. 詳細なチェックリストを生成 → 6つの主要な修正項目を優先度別に分類

これまでGitHub画面を行き来していた作業が、一瞬で完了しました。

実際の検証：todo-appでの結果

ブログ執筆中に実際に以下の指示を試してみました：

"todo-appの現在のブランチのPRを参照してレビューコメントを全て取得して修正のチェックリストを作成して"

結果: PR #123のレビューコメント13件を分析し、以下のような実用的なチェックリストが生成されました：

高優先度（即座に修正が必要）

• src/components/TodoList.tsx: useEffectの依存配列が不完全でバグの原因となる可能性
• src/api/todoApi.ts: API呼び出し時のエラーハンドリングが不十分

中優先度（改善推奨）

• src/types/todo.ts: TypeScript型定義の厳密化（any型の使用を避ける）
• src/utils/validation.ts: 複雑なロジックにコメントを追加
• src/hooks/useTodos.ts: 状態管理のロジック改善
• src/components/TodoItem.tsx: 変数名をより分かりやすく改善

レビュアーの意図や背景も含めて分析され、単なるコメントの羅列ではなく、実際に作業しやすい形で整理されていました。

実際に感じたメリット

効率性の向上

• 手動作業の削減: GitHub画面を行き来する必要がなくなった
• 見落としの防止: 全てのコメントが確実に一覧化される
• 優先度の明確化: 重要度に応じた対応順序が自動で判断される

作業の質の向上

• ファイルパスの明示: 該当箇所をすぐに特定できる
• 進捗管理の簡素化: チェックボックスで対応状況を追跡
• 作業量の把握: 全体の作業時間を事前に見積もれる

活用のコツ

効果的な指示の出し方

汎用的なガイドラインが欲しい場合:

"PRレビューコメントを確認して対応リストを作成して"

新しいプロジェクトでのプロセス構築や、チーム内での標準化に有効です。

具体的なPRの対応リストが欲しい場合:

"[リポジトリ名]の現在のブランチのPRを参照してレビューコメントを全て取得して修正のチェックリストを作成して"

現在進行中のPRの対応や、緊急性の高い修正作業の整理に有効です。

段階的な処理の活用

具体的な指示を出すと、処理の各段階が可視化されるため、何が行われているかを把握しやすくなります。これにより、問題が発生した場合の原因特定も容易になります。

MCPの便利さを実感した体験

今回の検証を通じて、MCPの真の価値を実感することができました。

今までは「APIのドキュメントを読む→必要な設定→エンドポイント呼び出し→JSONパース→データ整理→優先度判断」という複数のステップが必要でしたが、MCPを使うことで「ほんのちょっとの指示」だけで全てが完了します。

技術的な複雑さを抽象化し、問題解決に集中しやすくなる感じがしました。

参考リンク

• RooCode 公式サイト
• GitHub MCP Server（公式）
• Model Context Protocol 公式ドキュメント

「ネットワーク構築と言ったらYAMAHAでしょ！」という方や、「電源をつけたときのファンの音が好きなんだ！」という方は、お楽しみいただけないのでこのブログは対象外です。すぐブラウザの閉じるボタンを押してください。

まだ閉じていない方は、こちらからCisco Packet Tracerをダウンロードしてください。
https://www.netacad.com/articles/news/download-cisco-packet-tracer
※ダウンロードにはログインが必要となるので、無料のアカウントを作成してください。

同じようなソフトウェアにGNS3もあります。こちらを利用するときは、IOS（iPhoneのOSじゃないですよ、Ciscoのネットワーク機器用のOSです）のイメージファイルが必要です。ググるとイメージファイルが転がっているかもしれませんが、これ使ったら著作権的にあれです。みなさんの家にはCiscoの実機があるかもしれませんが、私は持ってなかったので、以前は実機を購入しました。でも、Cisco Packet Tracerならそんなことは気にする必要がありません！

ダウンロード出来たら早速起動してきます。

画面はこんな感じです。
使い方は、真ん中の白いところが作業スペースです。左下にある機器のアイコンを作業スペースに置いていくと、ネットワークのシミュレーションが出来ます。

左下の使い方を見ていきます。
オレンジ色の所はこんな階層になってます。（一部省略してます）
Network Devices
　Routers
　Switches
　Hubs
End Devices
　End Devices
　Home
Components
　Boards
　Actuators
Connections
　Connections
などがあります。

それでは簡単なネットワークを作って、疎通させてみます。
L2スイッチ2台と、PC2台を置いて、pingで通信出来るね。をやります。

みなさんが大好きなL2スイッチ。Cisco Catalyst 2960を2台置いてみました。

PCを2台置いてみました。

結線していきます。
Copper Straight-Throughを選択。

線を選んだら、Cisco Catalyst 2960を選択します。
このCisco Catalyst 2960はポートが1+24+2個あるので、その中からFastEthernet1を選択していきます。

こんな結線をします。
Switch0 FastEthernet0/1 - Switch1 FastEthernet0/1
Switch0 FastEthernet0/2 - PC0 FastEthernet0
Switch1 FastEthernet0/2 - PC1 FastEthernet0
※結線してすぐはオレンジ色の△が出てますが、しばらくするとポートが使えるようになって、緑色の△になります。

PC0とPC1でpingの疎通確認をしたいので、PC0とPC1にIPv4アドレスを設定します。

PC0をクリックすると、設定画面がでてきます。
ConfigタブからIPアドレスを設定します。
こんな設定をします。同様にPC1も設定します。
PC0
　IPv4 Address:192.168.0.1
　Subnet Mask:255.255.255.0
PC1
　IPv4 Address:192.168.0.2
　Subnet Mask:255.255.255.0

では、コマンドプロンプトからpingしてみます。

PC0をクリックして、DesktopタブからCommand Promptを開きます。

疎通出来てますね。
これだけだと面白くないので、パケットが届くところを見てみたいと思います。

View - Simulation Mode（右下の方のSimulationボタンを押してもOKです） を選択します。

パケットがCisco Catalyst 2960 2台を経由して、通信先のPCに届いているのが見えますね。
画面右のシミュレーションウインドウで、パケットの中身を見ることも出来ます。

これでCiscoのネットワーク機器を弄り放題ですね！好きなだけお楽しみ下さい！！

はじめに

こんにちは、Anti-Pattern Inc.の塚本です。

参画したプロジェクトで、Mavenアプリケーションでアーカイブを作成したくないご要望があったので、その際に調べたtipsを共有します。

SampleAppをmavenでpackageする場合

SampleAppというアプリケーションをmavenでpackageする場合、このようなディレクトリが生成されます。今回は、コンパイルだけして、SampleApp.warを作らない設定方法について説明します。

プロジェクトディレクトリ
 - target
   SampleApp
   SampleApp.war
   classes
   generated-sources
   maven-archiver
   maven-status

Maven の Package フェーズとは

Maven のビルドライフサイクルには複数のフェーズがあります。このフェーズでは、コンパイルされたコードやリソースファイルをディストリビューション形式(JAR、WAR など)にパッケージングします。

mvn package コマンドを実行すると、以下のようなことが行われます:

• ソースコードのコンパイル
• テストの実行
• プロジェクト成果物(アーティファクト)のパッケージング

pom.xmlのpackagingタグの設定によりますが、Web アプリケーションの場合、この成果物は通常 WARファイルとなります。

maven-war-plugin について

maven-war-plugin は、Java Web アプリケーションを WAR ファイルにパッケージングするための Maven プラグインです。以下は、今回対応したpom.xmlのサンプルです。

<pluginManagement>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>2.1.1</version>
            <configuration>
                <failOnMissingWebXml>false</failOnMissingWebXml>
                <webResources>
                    <resource>
                        <directory>${project.basedir}/src/main/webapp</directory>
                    </resource>
                </webResources>                    
            </configuration>
        <!-- コメントインするとwarファイルを作成しない
            <executions>
                <execution>
                    <id>default-war</id>
                    <phase>none</phase>
                </execution>
                <execution>
                    <id>war-exploded</id>
                    <phase>package</phase>
                    <goals>
                        <goal>exploded</goal>
                    </goals>
                </execution>
            </executions>
        -->
        </plugin>            
    </plugins>
</pluginManagement>

configuration 要素

• failOnMissingWebXml: false に設定することで、web.xml ファイルが存在しなくてもビルドが失敗しないようにします。Servlet 3.0 以降では web.xml が必須ではなくなったため、この設定が便利です。
• webResources: WAR ファイルに含めるリソースを指定します。
  • resource: リソースの場所を指定します。
  • directory: リソースが格納されているディレクトリのパスを指定します。この例では ${project.basedir}/src/main/webapp を指定しています。

executions 要素(コメントアウト部分)

この部分はコメントアウトされていますが、コメントインすると以下の動作をします:

• default-war 実行を無効化(phase を none に設定)
  • 通常の WAR ファイル生成プロセスを無効にします
• war-exploded 実行を有効化
  • package フェーズで exploded ゴールを実行します
  • exploded ゴールは展開された状態(ディレクトリ構造)の WAR を生成します
  • これにより、WAR ファイル(*.war)は作成されず、展開済みディレクトリのみが生成されます

exploded WAR とは

展開された(exploded)WAR とは、圧縮された単一の WAR ファイルではなく、同じ内容がディレクトリ構造として展開された状態を指します。これには以下のようなメリットがあります:

• 開発効率の向上: ファイルを変更した場合、WAR ファイル全体を再デプロイする必要がなく、変更したファイルだけを置き換えることができます
• デバッグのしやすさ: 実行中のアプリケーションのファイルに直接アクセスできるため、問題の診断が容易になります
• ホットデプロイの容易さ: 多くのアプリケーションサーバーでは、展開された状態のアプリケーションはホットデプロイ(再起動なしの更新)が容易です

今回は生成AIを使って調べたのですが、以下のサイトも参考にさせていただきました:

https://stackoverflow.com/questions/352612/how-to-get-maven-to-run-warexploded-but-not-warwar

]]>https://tech.anti-pattern.co.jp/ren-ding-sukuramumasutayan-xiu-woshou-ketemita/Ghost__Post__681ef6ff71fa390001b3366aWed, 14 May 2025 02:03:29 GMTこんにちは。アンチパターンの安澤です。
アンチパターンではSaaSus Platform の開発をアジャイルで進めていますが、最近「本当にアジャイルに開発できているのか？」という漠然としたモヤモヤを感じていました。

そんな中、株式会社アトラクタが実施する認定スクラムマスター研修を受講し、Certified ScrumMaster（CSM）資格に無事合格しました。今回はその研修を通じて得た学びや気づきをまとめてみたいと思います。

認定スクラムマスター（CSM）とは

Certified ScrumMaster（CSM）は、スクラムの基本を体系的に学べる入門資格で、Scrum Allianceが認定しています。スクラムマスターとして必要な知識とマインドセットを習得できます。

Scrum Allianceが提供するスクラムマスター向けの資格には、CSMのほかに上位資格として次の2つが用意されています：

• Advanced Certified ScrumMaster（A-CSM）
• Certified Scrum Professional - ScrumMaster（CSP-SM）

上位資格の受験には、CSM取得後にそれぞれ12〜24ヶ月の実務経験が必要です。

Scrum Master Certifications | CSM, A-CSM, & CSP-SM

With our Scrum Master Track, you can become a skilled scrum master with a clear path to advancing your career through our CSM, A-CSM, & CSP-SM courses.

CSM, A-CSM, & CSP-SMCertified ScrumMaster student

研修について

今回受講したCSM研修は、全3日間・各日13:00〜18:30のオンライン形式で行われました。参加者は約25名で、6人前後のチームに分かれてのグループワークも多く、講義と実践がバランスよく構成されていました。

1日目：アジャイルとスクラムの基本理解

初日は、アジャイル開発の背景やスクラムのフレームワークについての座学が中心。グループワークもあり、参加者同士のアイスブレイクにもなりました。

2日目：スクラムの実践ワーク

2日目は、実際にチームでスプリントを回す体験型ワーク。限られた時間の中で、計画からレビューまでを一通り体験することで、スクラムの流れを肌で感じることができました。

3日目：スクラムマスターの役割にフォーカス

最終日はスクラムマスターに焦点を当てた講義。現場での立ち回り方や心構え、支援のスタンスなど、実務に役立つ知見が多く得られました。

学んだこと

今回の研修ではたくさんの気づきや学びがありましたが、私が特に大切だと感じたことを3つ選びました。

アジャイルという単語

アジャイルソフトウェア開発宣言には、アジャイルのマインドセットとして4つの価値と12の原則が示されています。アジャイル開発とは、これらに基づいてチームやプロセスを継続的に改善しながら価値を提供し続けることです。

興味深かったのは、「アジャイル」は名詞ではなく形容詞であるという考え方です。つまり、アジャイルかどうかを0か1のような「やっている／いない」で判断するのではなく、どれくらいアジャイルであるか、どの程度マインドセットに沿えているかが重要であり、そこによりアジャイルに近づくための改善の余地があります。

自分のチームがアジャイルであるかを一括りで判断するのではなく、「何が価値に沿っていて、何が改善の余地なのか」を丁寧に見つめ直す視点が大切だと気づきました。

スプリントレビューの大切さ

研修中、チームに分かれて与えられた課題に対してスプリントを回す実践を行いました。短い時間の中で「インクリメントを作成し、スプリントレビューで発表する」という一連の流れを体験しました。

正直、短時間で作ったインクリメントは完成度が高いとは言えませんでしたが、スプリントレビューで得たフィードバックは非常に有益で、次に改善すべき点が明確になりました。

特に印象的だったのは、「完成度の高さ」よりも「レビューの場でどれだけ価値ある対話が生まれるか」の方が重要だということです。スクラムにおいてスプリントレビューは、単なる成果発表ではなく、チームとステークホルダーがプロダクトの方向性をすり合わせるための重要なイベントなのだと実感しました。

観察すること

スクラムマスターは、チームの中で教えたり、促したり、調整したりといった様々な役割を担います。研修の中で強調されていたのは、スクラムマスターがすぐに課題を解決しようとせず、まずはチームを「観察」することの大切さです。

たとえば、チームが課題を抱えていそうなときでも、すぐに口を出すのではなく、「何が起きているのか」「メンバー同士の関係性はどうか」「チームとして気づけるタイミングはあるか」を見極め、必要なときに最小限の介入をするというスタンスが求められます。

このような「一歩引いて支援する姿勢」は、マネージャーともメンターとも違う、スクラムマスター独自の難しさとやりがいだと感じました。

資格受験について

研修終了後、Scrum Allianceからメールが届き、専用ダッシュボードから試験の受験ができました。

• 受験は50問の選択式
• 合格ラインは74%以上（37問以上）
• 制限時間は60分
• 研修修了から90日以内であれば2回まで無料
• 3回目以降は1回25USDの受験料が必要

私は2問間違えてしまいましたが、無事に合格することができました。
アジャイルマニフェストとスクラムガイドを事前に読んでおけば、試験対策としては十分でした。

まとめ

3日間の研修を通じて、アジャイルやスクラムの考え方、スクラムマスターの役割などについて体系的に学ぶことができました。今後はこの学びを実務に生かし、チームがよりアジャイルに成長できるよう支援していきたいと思います。

ちなみに、グループワークで発表を担当した際に、つい「スクラム開発」と言ってしまいました。講師から「スクラムは名詞なので開発とは結びつけない方が良い」との指摘を受け、ちょっと恥ずかしい思いをしましたが、これも良い学びのひとつです。

モノレポを採用しているプロジェクトで、「ちょっとした修正なのに、CIが全サービス分走って時間がかかるのもったいない」って思ったので変更があったやつだけ走るようにして節約できると良さそうと思い色々調べてみました。

今回は、dorny/paths-filterを使い、変更が加えられたサービスやパッケージに関連するジョブだけを実行することで、CI/CDのパイプラインを高速化・効率化する方法をご紹介します。

モノレポの課題
モノレポはコードの共有や依存関係の管理に優れていますが、プロジェクトが大きくなるにつれてCIの実行時間が長くなりがちかなと思います。例えば、複数のサービス（service-a, service-b）と共通パッケージ（shared-ui）を持つモノレポを考えてみましょう。service-a のフロントエンドコードを少し変更しただけでも、service-b や shared-ui も含めたすべてのリント、テスト、ビルドが実行されると、貴重な時間とリソースが無駄になってしまいます。

改善方法：変更差分に基づいたCI実行
この問題を改善する鍵は、「変更があった箇所」だけに関連するCIを実行することで改善できそうだなと。具体的には、プルリクエストやプッシュで変更されたファイルを検知し、そのファイルが含まれるサービスやパッケージに対応するジョブのみをトリガーします。

想定するディレクトリ構成
今回は、以下のようなディレクトリ構成を例に説明します。各サービスのディレクトリ直下に、そのサービスのフロントエンドコードがあると想定します。（APIなどは共通化されているか、別リポジトリなどで管理されているイメージです）

.
├── services/
│   ├── service-a/       <-- サービスA (フロントエンド)
│   │   ├── package.json
│   │   └── src/
│   ├── service-b/       <-- サービスB (フロントエンド)
│   │   ├── package.json
│   │   └── src/
│   └── service-c-backend/ <-- サービスC (バックエンドのみなど)
│       └── ...
├── packages/
│   ├── shared-ui/       <-- 共通UIコンポーネント
│   │   └── package.json
│   └── shared-utils/    <-- 共通ユーティリティ
│       └── package.json
└── pnpm-workspace.yaml  <-- pnpmを使う場合

GitHub Actions ワークフロー
この構成で、変更があったフロントエンドサービスや共通パッケージに対してのみリントとビルドを実行するワークフローは以下のようになります。

name: CI

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  # 1. 変更検出ジョブ
  changes:
    name: Detect changes
    runs-on: ubuntu-latest
    outputs:
      # 変更があったサービス/パッケージ名のリストを出力 (例: ["services/service-a", "packages/shared-ui"])
      projects: ${{ steps.filter.outputs.changes || '[]' }}
      # いずれかのサービス/パッケージに変更があったか (true/false)
      # filtersで定義したキー名に合わせてOR条件を記述
      any_changed: ${{ steps.filter.outputs['services/service-a'] == 'true' || steps.filter.outputs['services/service-b'] == 'true' || steps.filter.outputs['packages/shared-ui'] == 'true' || steps.filter.outputs['packages/shared-utils'] == 'true' }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          # paths-filterが変更を正しく比較するために全履歴を取得
          fetch-depth: 0

      - name: Check for file changes using paths-filter
        uses: dorny/paths-filter@v3
        id: filter
        with:
          # 変更があったファイルリストをJSON形式で出力
          list-files: json
          # フィルターのキー名を、そのまま作業ディレクトリとして使えるようにパス形式にする
          filters: |
            services/service-a:      # サービスAのディレクトリ
              - 'services/service-a/**'
            services/service-b:      # サービスBのディレクトリ
              - 'services/service-b/**'
            packages/shared-ui:    # 共通UIパッケージ
              - 'packages/shared-ui/**'
            packages/shared-utils:   # 共通ユーティリティパッケージ
              - 'packages/shared-utils/**'

  # 2. Node.jsベースのチェックジョブ (フロントエンドや共通パッケージ用)
  node-checks:
    name: ${{ matrix.project }} - Checks
    needs: changes # changesジョブの完了を待つ
    # changesジョブの出力any_changedがtrueの場合のみ実行
    if: needs.changes.outputs.any_changed == 'true' && (startsWith(matrix.project, 'services/') || startsWith(matrix.project, 'packages/')) # Node.js関連のプロジェクトのみ対象とする例
    runs-on: ubuntu-latest
    container:
      image: node:22-bullseye

    strategy:
      fail-fast: false # 1つが失敗しても他は続行
      matrix:
        # changesジョブの出力projects (変更があったサービス/パッケージ名のリスト) を元にジョブを並列実行
        project: ${{ fromJson(needs.changes.outputs.projects) }}

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      # pnpmを使う場合
      - name: Setup pnpm
        uses: pnpm/action-setup@v3
        with:
          version: 9
          run_install: false

      # pnpmキャッシュの設定
      - name: Get pnpm store directory
        id: pnpm-cache
        shell: bash
        run: |
          echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_OUTPUT

      - name: Setup pnpm Cache
        uses: actions/cache@v4
        with:
          path: ${{ steps.pnpm-cache.outputs.STORE_PATH }}
          key: ${{ runner.os }}-pnpm-store-${{ matrix.project }}-${{ hashFiles(format('{0}/pnpm-lock.yaml', matrix.project)) }}
          restore-keys: |
            ${{ runner.os }}-pnpm-store-${{ matrix.project }}-

      # 依存関係のインストール
      - name: Install dependencies
        # matrix.projectがそのまま作業ディレクトリになる
        working-directory: ${{ matrix.project }}
        run: pnpm install --frozen-lockfile

      # リント実行
      - name: Run ESLint
        working-directory: ${{ matrix.project }}
        run: pnpm run lint

      # ビルド実行
      - name: Run Build
        working-directory: ${{ matrix.project }}
        run: pnpm run build

ワークフロー解説
1. changes ジョブ:
actions/checkout@v4:
コードをチェックアウト ( workspace-depth: 0 で全履歴取得)。
dorny/paths-filter@v3:
・filters:で監視対象のディレクトリとフィルター名を定義。ここではフィルター名を作業ディレクトリパスと同じにしています ( services/service-a, packages/shared-ui など)。これが後々便利になります。
・変更があったフィルター名のリストと、各フィルターに変更があったかのフラグ ( services/service-a, packages/shared-ui など) を出力します。
outputs: :
後続ジョブで使えるように、変更リストと、いずれかに変更があったかを示す any_changed を出力します。any_changed の条件式は filters で定義したキー名に合わせて調整してください。

2. node-checks ジョブ:
・needs :changes: changes ジョブの完了を待ちます。
・ if: needs.changes.outputs.any_changed == 'true' && ...:
changes ジョブで変更が検知され、かつ、Matrix で展開されるプロジェクト名 ( matrix.project) がNode.js関連（例: services/ または packages/ で始まる）の場合のみ実行します。これにより、例えばバックエンド専用のディレクトリが変更されても、このNode.js用ジョブは実行されません。
・strategy.matrix.project: ${{ fromJson(needs.changes.outputs.projects) }}:
changes ジョブからの変更リストを元に、変更があったサービス/パッケージごとにジョブを並列実行します。
・pnpm関連ステップ: pnpmのセットアップとキャッシュを行います。
・working-directory: ${{ matrix.project }}:
ここがポイントです。 filters でキー名をパスと同じにしたため、 matrix.projectの値 ( services/service-a など) をそのまま working-directoryに指定できます。これにより、各ジョブは正しいディレクトリで pnpm install, lint, build を実行します。

まとめ
dorny/paths-filter を活用し、ディレクトリ構造に合わせてフィルターを設定することで、モノレポ内の変更があった箇所だけを対象にCIを実行できます。これにより、CIの実行時間を大幅に短縮し、開発プロセス全体の効率を向上させることが可能です。

今回の例はフロントエンドがメインでしたが、バックエンドや他の種類のパッケージが含まれる場合でも、同様の考え方でワークフローを拡張できると思います。ぜひ、あなたのモノレポプロジェクトにも導入してみてください！

1月にAIエージェントが物凄く盛り上がりました。私も1月から複数のAIエージェントを試してきましたが、Roo Codeが今一番使いやすいと感じています。実際にどのように使用しているのか紹介します。

Roo Codeとは

Roo Code（旧称：Roo Cline）は、Visual Studio Code（VSCode）の拡張機能として提供されるAIエージェントです。オープンソースの自律型コーディングアシスタント「Cline」を基盤に開発され、コードの生成、編集、テスト、デバッグ、さらにはプロジェクト管理まで、開発の各段階を包括的にサポートします。

Settingsで広い権限を渡す

初期設定ではread-onlyでwriteに関しては承認が必要という状態ですが、これだと逐次的に進める必要があるので、広めの権限を渡します。git等で変更管理をしているはずなので大きな問題はないと思います。

API Providerは複数あると良い

先におすすめの組み合わせですが、providerはVS Code LM APIとOpenRouterを使うことをお勧めします。モデルはClaude 3.5 sonnetをお勧めします。

理由ですが、OpenAIやClaudeのAPIを個人で直接払って使用しようとするとlimitの制限が厳しく、使い勝手が悪くなります。AnthropicはTier 2までOpenAI PlatformはTier 1まで試しましたが、不十分でした。

Anthropic

Rate limits - Anthropic

To mitigate misuse and manage capacity on our API, we have implemented limits on how much an organization can use the Claude API.

Anthropic

OpenAI Platform

https://platform.openai.com/docs/guides/rate-limits?context=tier-four&tier=tier-two#usage-tiers

OpenRouterを使うことでAPI のtokenやrequestのlimitの制限をほとんど気にしなくて良くなります。（OpenRouterもPrivacyで学習に使用しないように選択ができます。）

（OpenRouterで）claude-3.5-sonnet:betaを使用していると料金は高くなります。

さらに1/17からVS Code LM APIが使えるようになりました。これでcopilot経由でのclaude-3.5-sonnetが一定量無料で使えるようになりました。

余談ですが、Roo Codeでgpt 40を使っていた時、一定程度使っているとなぜか Claude 3.5 Sonnet への切り替えを推奨されました。理由は分かりませんが、Claude 3.5 Sonnetがモデルの方が多くの情報を処理できるみたいです。

Roo Code uses complex prompts and iterative task execution that may be challenging for less capable models. For best results, it's recommended to use Claude 3.5 Sonnet for its advanced agentic coding capabilities.

2025/2/13追記

GitHub Copilot Agent Modeが使えるようになりました！

Roo Codeと同じくAIエージェントで高性能なモデルGPT 4o, o1, Claude 3.5 sonnetが無料で使えます！

ということで今一番使っています！

2025/3/19

すでにClaude 3.7 sonnet、Claude 3.7 sonnet Thinking、GPT 03-miniが使用できるようになっています！

現在試行錯誤中なので、明日には使い方が変わっているかもしれませんが、一旦こんな風に使ってたというのを記載します。

インフラ開発

CDKをIaCとして採用しており、stack内のリソース作成などはコーディングの量がそこまで多くないので、AIエージェントの良さを感じづらくはあります。個人的にはcodeでプロンプトを投げるのではなく、askで参考コードを出してもらって良ければ追加くらいでも今のところ良いかなとも思います。
Lambda（typescript）を一から作成するのはとても簡単に感じました。また、Lambdaのpolicy作成もコードと合わせて行ってくれますし、テストも作ってくれて便利です。importするものを指定すると精度が上がりました。（何も指定せずに依頼するとjest.mockでテスト作られるので、aws-sdk-client-mockを利用したい場合は指定する必要があります。）コーディングルールをドキュメントにしてもらいつつ、開発していくのが有益だと思います。

バックエンド

GolangでAPIを作成しています。既存のOpenAPI定義があるので、定義にエンドポイントを追加していくことは難しくないです（自分で追加してもそこまでコード量は多くないので、好みかと思いますが、エージェントに作成してもらってレビューー&修正という形で開発しています。）。OpenAPI定義に関わらず、ファイルが数千行と膨大なものになる場合はエージェントの実行時間とトークンの消費量が大きくなるので注意です。OpenAPI定義と要件から実装をお願いするといい感じで作成してくれます。明示的に”controller, model, service, infrastructureに追加して”や”既存のファイルのコーディング方法を確認して同じように追加して”、”この手順でテストして”など詳細を伝えることが大事です。

フロントエンド

まだ試せてないで楽しみです。

こんにちは！
アンチパターン管理部の森口です。
今回は、社会保険(健康保険・厚生年金保険)の加入要件について学びたいと思います。

法律改正により、2016年10月から段階的に「短時間労働者に対する社会保険の適用の拡大」がされていますが、まずは適用拡大以前から加入義務がある人の要件を確認しましょう！

【社会保険の加入対象者】

■適用拡大前（1980年〜2016年9月末）

加入要件：1日または1週の所定労働時間および1月の所定労働日数が常時雇用者のおおむね4分の3以上
参考：適用事業所と被保険者｜日本年金機構

例えば、正社員が週40時間・月20日勤務する企業の場合、「週の所定労働時間が30時間以上かつ月の所定労働日数が15日以上」で加入義務が発生します。

■適用拡大後（2016年10月〜段階的に拡大）

対象企業（2016年10月〜）：従業員数501人以上の企業
対象企業（2022年10月〜）：従業員数101人以上の企業
対象企業（2024年10月〜）：従業員数51人以上の企業 ←現在はここ！
参考：短時間労働者に対する健康保険・厚生年金保険の適用の拡大｜日本年金機構

対象企業の判断基準である「従業員数」について

ここで言う従業員数とは、「フルタイムの従業員数」＋「週労働時間がフルタイムの3/4以上の従業員数」のことなので、従業員が51人以上いる企業でも、フルタイムやフルタイムの3/4以上の従業員が50人以下であれば対象企業になりません。
ただし、従業員数には取締役等の役員も含めるそうなのでカウントする際はご注意を！
参考：社会保険適用拡大における取締役(役員)の取り扱いについて｜人事のQ&A『日本の人事部』

• 月ごとに従業員数をカウントして、直近12カ月のうち6カ月で基準を上回ると適用拡大の対象企業（特定適用事業所）になる
• 日本年金機構において、直近11カ月のうち5カ月50人を超えたことが確認できた場合は、対象の適用事業所に対して、「特定適用事業所に関する重要なお知らせ」が送付される
  参考：特定適用事業所該当・不該当の手続き｜日本年金機構
  

短時間労働者の加入要件

対象企業の従業員で、以下4つの要件全てに該当する場合は社会保険の加入義務が発生します。

• 加入要件1：週の所定労働時間が20時間以上
• 加入要件2：月額賃金が8.8万円以上
• 加入要件3：2カ月を超える雇用の見込みがある
• 加入要件4：学生ではない

各要件を理解し、対象企業（特定適用事業所）に該当するのか、社会保険の加入義務が発生するのか、正しく判断しましょう！

以上です！

]]>https://tech.anti-pattern.co.jp/fixed-tax-reduction/Ghost__Post__6652d2ba27e5640001680679Wed, 05 Feb 2025 10:07:19 GMT

こんにちは！
アンチパターン管理部の森口です。
今回は、給与担当者として「定額減税」について学んだことをまとめてみました！

※こちらのブログは、給与所得者(勤務先から給与を受け取っている人)を対象に書いております。公的年金等の受給者や事業所得者の場合は、内容が異なると思いますのでご了承ください。

定額減税ってなに？

所得額に関係なく、納税額から一律に同じ額を差し引いて税負担を軽減する減税方法のことを「定額減税」といいます。（他に定率減税という方法もある）
「デフレ完全脱却のための総合経済対策」の一環として、2024年6月から、所得税3万円・個人住民税1万円の計4万円が減税されます。

所得税の定額減税について

■対象者は？

• 税区分が甲欄であること（扶養控除申告書を提出していること）
• 国内居住者であること（日本国内に住所がある、または現在まで引き続き1年以上居所を有する個人）
• 2024年6月1日に会社に在籍していること（休職者も含まれる）
• 2024年の本人の所得が1,805万円（給与収入のみの場合は2,000万円）以下であること
  • 所得が1,805万円を超える見込みがある場合も、2024年6月以降の給与からは一旦控除される(控除する/しないは選べない)、年末調整や確定申告で最終的に精算される

■減税額は？

対象者本人：3万円
同一生計配偶者：3万円
扶養親族：3万円/人
※いずれも国内居住者に限る
※同一生計配偶者とは
※扶養親族とは

■減税方法は？

2024年6月1日以降の最初の給与等の源泉徴収税額から順次控除し、控除しきれない場合は年末調整で控除されます。
それでも控除しきれない場合は給付措置が行われる見込みです。

個人住民税の定額減税について

■対象者は？

• 国内居住者であること（日本国内に住所がある、または現在まで引き続き1年以上居所を有する個人）
• 2024年度(2024年6月~2027年5月)の個人住民税が「非課税」や「均等割及び森林環境税のみ」ではないこと
• 2023年の本人の所得が1,805万円（給与収入のみの場合は2,000万円）以下であること
  • 所得税の場合は今年(2024年)の所得を見るが、住民税は前年(2023年)の所得を見る

■減税額は？

対象者本人：1万円
控除対象配偶者：1万円
控除対象配偶者以外の同一生計配偶者：1万円（2025年度に減税される）
扶養親族：1万円/人
※いずれも国内居住者に限る
※控除対象配偶者とは
※控除対象配偶者以外の同一生計配偶者とは

■減税方法は？

通常は6月〜翌年5月の12ヶ月間で徴収されますが、定額減税の対象者は、2024年6月の住民税が徴収されず(0円)、減税後の金額を2024年7月～2025年5月の11ヶ月間で徴収されます。

従業員が気をつけること

• 制度の概要と対象者について理解しておく
• 会社から定額減税に関する確認やお知らせが来たらチェックする
• 住民税決定通知書を確認する
• 6月以降の給与明細を確認する
• 年末調整後に源泉徴収票を確認する
• 定額減税で引ききれないと見込まれる場合、調整給付金（当初給付・不足額給付）に関する案内が市区町村から対象者に届くので、内容を確認して必要な手続きをする
  ※調整給付について
  

以上です！

2024年は、B to B SaaSに向き合う1年でしたが、年末年始に時間があったので、改めて今後の日本における、B to B SaaS業界について考えてみました。

以前に、SaaSの時代はもう終わってしまったのか？

という記事を書きましたが、今回は、2024年を通して感じたことを元に、2025年のB to B SaaS業界の展望を個人的な希望も込めて予想してみたいと思います。

2024年を通して感じたこととしては、これからまたSaaSの波が来るぞということでした。いやむしろ、これからくる波が本物の波なのではないか？とさえ感じています。

まず、数字だけで見るとポジティブな数字はたくさん出てきます。

1. 国内SaaS市場は年平均成長率11.7%
   (参考：スマートキャンプ『SaaS業界レポート 2023』を解説)
   
   
2. 国内SaaS市場は現在から3.7倍以上になる可能性がある
   (参考：One Capital「Japan SaaS Insights 2023」)
   
   
3. 日本のエンタープライズ市場は28.5兆円で前年比4.7%成長
   (参考：ガートナ「日本のエンタープライズIT支出、2023年は4.7％増」)
   
   
4. クラウド市場の成長率20%前後
   (参考：Synergy Research Groupグローバルのクラウドインフラ市場シェア」)
   

これらを見るに、数字だけで見ると、SaaSの市場はまだまだこれから伸びるし、エンタープライズ市場の中でSaaSの割合が高まっていくであろうことを考えるとポテンシャルは非常に高く感じる。

さあ、では、なぜ、数字上は、どの数字を見ても伸びてそうに見えるのに、そしてアメリカではしっかり伸びているのに、国内において体感値として伸びていると感じづらいのか？

いくつかの要因があるのではないかと思う。

1. 新興SaaS企業を支えてきたベンチャーキャピタルの機運の低下
2. クラウドなど最新テクノロジーの活用の遅れ
3. 日本特有のSIビジネス/カスタマイズ文化

ただ、これらの要因については、少しずつ変化が見えてきているのではないかと感じていて、これらが変化していくことによって、一気に、B to B SaaSの波が進むのではないかと感じている。

1. 新興SaaS企業を支えてきたベンチャーキャピタルの機運の低下
   
   ＜起きている変化＞
   こちらについては、確かに、過去SaaS企業の時価総額に軒並み高値がついていた時期とは様子が変わり、ベンチャーキャピタルの投資も慎重になってきている。また、AIという新しい領域への投資が盛り上がり、SaaS投資への機運が下がっている側面はあるものの、これまでと指標を変えながらではあるが、SaaS企業への投資は引き続き継続されている。
   また、大きな変化として、新しいタイプのプレイヤー、またベンチャー投資ではない資本を活用したSaaSがこれから生まれ始めるのではないかという機運を感じる。例えば、SIerは事業モデルの転換としてSaaSに向き合うことを意思決定している企業は多いと感じる。また、日本の各産業を代表とするエンタープライズ企業が新規事業として、自分たちの蓄積してきた業務ナレッジをSaaSとして新規事業展開していく事例も増えてくるのではないかと考える。
   つまり、これまでより、SaaSビジネスを立ち上げるプレイヤーの種類が増加していくことで、ここの課題は解決されていくのではないかと予想している。
   
   
   
   
   
   
2. クラウドなど最新テクノロジーの活用の遅れ
   
   ＜起きている変化＞
   SaaSビジネスがなぜ注目されたのか？の背景には、新しいテクノロジーを活用することによって、スケーラブルなソフトウェアビジネスのモデルが構築できるようになったこと。また、そのテクノロジーの活用によって、SaaSの顧客側に、「割り勘効果」をもたらすことができて、業務ソフトウェアの活用の民主化が圧倒的に進むポテンシャルがあるからではないかと考えている。
   しかし、これまでは、日本においては、SaaSのストック型のビジネスモデルやSaaSの主要KPIなどに注目が集まり、最新テクノロジーをフックにした爆発的な業務ソフトウェアの民主化を起こしきれなかったのではないかと考えている。
   しかし、2024年になって、クラウド領域におけるグローバルTOPのAWSが本格的に動き始めるのではないかという機運を感じる。
   
   ・AWS Japan がソフトウェア企業に提供する「AWS SaaS 支援プログラム」の提供を開始
   https://aws.amazon.com/jp/blogs/news/saasification/
   ・国内初のSaaS技術専門書の発売
   https://www.oreilly.co.jp/books/9784814401017/
   
   また、APIファーストの機運も高まっており、我々アンチパターン社も、SaaS開発運用を支援する「SaaSus Platform」を提供している。
   
   これらを背景に、2025年には、SaaS提供の技術的視点の注目度も上がり、盛り上がりを見せていくのではないかと予想している。
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
3. 日本特有のSIビジネス/カスタマイズ文化
   
   ＜起きている変化＞
   国内のSIビジネスは足元堅調ではあるものの、エンジニア不足の問題を抱え、人月ビジネスの限界も見え始めているのではないかと感じる。また、事業会社もDXを求められており、これまで社内の業務システムにかけてきた、潤沢なIT予算を、新しい価値の提供など攻めの領域へのIT投資への転換が求められるようになっている。そんな時代背景を考えると、これまでのように潤沢なIT予算を活用して、1 社1社カスタマイズで自社の業務システムを作っていくことが現実的に難しくなってくることも予想される。
   そんな事業会社の変化により、SIerも汎用化してサービス提供するべき領域を見極め、ストックビジネスを一定割合作っていき、逆に、攻めのIT投資要望に関しては、これまで通り、SIによる人月モデルで独自性の高いシステムづくりの支援をしていくなど、領域分けが進めていくべきではないかと考える。その結果、これまで進められなかったSaaS事業が進み始めるのではないかと予想している。
   
   
   
   

では、具体的に、どんな領域で、SaaSが立ち上がっていくのかを予想してみる。

現在の時代背景をとらえた新領域のサービス化

マイナンバー対応、CO2の排出量測定、人的資本開示、インボイス制度対応、社会的背景の変化によってこれまでなかった業務が新しく必要となってくる際に、サービス化していくことは、業務規模が大きくなりにくい、かつ他の業務システムとの連携の必要性が少ない場合も多く、SaaSとして導入するハードルが低くなりやすい。その結果、これまでも、この領域でのサービス化は多く例が見られるが今後も、この領域ではSaaSが生まれていく可能性が高い領域ではないかと想定できる。

現場DXのサービス化

これまでは、B to B領域においては、いわゆるデスクワーカー向けのSaaSが多かったが、モバイル端末の普及やIoT技術の発展などを背景に、現場業務「店舗業務」、「配送業務」、「工事業務」、「製造業務」、「倉庫業務」などDXが進むではないかと予想できる。また、これまでであれば、これらを社内システムとしてDXを進めるという文脈になりがちだったが、新たな収益基盤の確立やクラウドテクノロジーの発展などを考えると、1社向けではなく、複数事業者にサービス提供をするということが現実的に視野に入ってくるのではないかと考える。この領域では、これまで主流ではなかった、B to B領域における、モバイルアプリでのSaaSが増えてくるのではないかと予想している。

自治体システムのサービス化

現在は、1,724ある自治体は、それぞれに自分たちの自治体に必要なシステムを、地場のソフトウェア事業者に依頼して作ることが多いようだ。しかしながら、少子化、人口減少を背景に、「消滅可能性自治体」などのキーワードが出てくるなど、自治体としても、人口規模に合わせた予算の縮小などは必須となってくる。もちろん、物理的な建物や施設の縮小などに目が向きがちだが、ソフトウェア予算の縮小も対象となってくるはずだ。そう考えると、これまでのように、同じような仕組みを各自治体のソフトウェア会社がそれぞれで作るのは現実的ではないし、非効率である。このような背景から、自治体においてもSaaSの機運は高まってくるのではないかと考える。

企業のコア業務を担うシステムのサービス化

これまでも、エンタープライズ企業における、SaaSの活用は進んできたように思うが、使われている領域を考えると、1事業部の1サブシステムにおいてSaaSを活用する事例や、全社業務だとしても、人事領域など、他業務と切り離しやすい領域でのSaaS活用が進んできたように思う。しかしながら、今後も、さまざまな業務のシステムリプレイスのタイミングが定期的にくる中で、これからも繰り返しリプレイスを繰り返していくのかというのには疑問が残るところだ。

他の領域に比べるとハードルは高いが、この領域においても、SaaSを提供するプレイヤーが出てくるのではないかと考える。

また、コア業務におけるハードルの高さは、カスタマイズの多さや連携が必要なシステムの多さではないかと思う。ただ、SaaS提供事業者がSaaSに外部公開APIを備えることによって、ある程度、SaaS利用企業側での柔軟性を上げることができるのではないかと考えている。利用企業側が、外部公開APIが存在するSaaSを活用しながら、自社独自で必要な要件については、SaaSのAPIを活用し、これまで通り社内システムとして持つことである程度解決できるのではないかと考えている。

これらにより、この領域でも、SaaSが出てくることを個人的にはとても期待している。

さて、今回のまとめとしては、エンタープライズIT市場は28.5兆円規模であり、これからもまだ成長することが予想される中、SaaS市場は、1.1兆円程度である。たったの4%である。ここに関しては、まだまだ伸びるべきであり、その鍵は、SaaSビジネスを推進するプレイヤーがどのように現れて、最新テクノロジーを活用して、多くの企業にメリットのあるようなビジネスを立ち上げられるかどうかにかかっている。

我々も、今後出てくる、「SaaSビジネスを推進するプレイヤー」をしっかりと支えていけるような事業者であるために、しっかりと頑張っていきたいと考えている。よし、2025年も頑張ろう。

GPTsとは

そもそもGPTsとはなんぞやという話なので、本人（ChatGPT）に聞いてみました↓

「GPTs」は、特定の用途や目的に合わせてカスタマイズされたGPT（AIモデル）を作成・利用する仕組みのことを指します。この機能を使えば、一般的なAIモデル（汎用型）ではなく、特定の業務やシナリオに最適化されたAIを簡単に作成・活用できます。

つまりは、特定の目的に最適化されたオリジナルのGPTを作ることができます。（有料：Plus以上が必要）。汎用型を用いて、いちいちプロンプトのテンプレをコピペしたりするのはめんどいし、複数人が同じタスクを行う際にクオリティにばらつきが出るなどがGPTsを使えば手軽かつ質の安定につながるという感じです。

例えば、ChatGPTに「今日の天気は？」と聞くと、おそらく「晴れです」とか「何℃くらいです」とか答えてくれると思います。しかし、回答にばらつきがでます。日によっては湿度まで答えてくれたり、明日の天気まで答えてくれたりすることもあるけど、そうでない時もある、みたいな具合に。では、ほしい情報を一発で引き出せるようにプロンプトをテンプレ化しようとなると思います。

＜テンプレ例＞

今日の天気は？と聞かれたら以下を回答してください。
天気の場所は東京都渋谷区でお願いします。

・天気（朝昼夜）
・気温（朝昼夜）
・湿度
・花粉の情報
・紫外線の情報
・服装の目安

最後に参照したページのURLを記載してください。

これを毎日コピペして聞くことで、画一的な情報を引き出すことができます。
それをさらに簡略化するのがGPTsと言えます。

上記のテンプレをGPTsにあらかじめ設定しておくことで、簡単な指示で同様の情報を引き出すことができます。上記の例は比較的シンプルな内容なので、有料ならコピペしますけど？と思うかもですが、より複雑な場合（会話のラリーが必要だったり、分岐が発生する場合）にはGPTsが活躍します。

このGPTsを活用して、簿記3級の勉強アシスタントを作ったというのが、今回のお話し。

作り方

まず、手元にPDFの簿記3級のテキスト、問題集、模擬試験問題があったので、これを読み込ませます（GPTsにはPDFなどの資料をあらかじめ読み込ませておくことができます）。回答はブラウジングでもいけますが、信頼できそうな資料を読み込ませた方が質は安定するかと思います。ちなみに読み込めるファイルは20個までで、それぞれ512MBが上限らしいです。

あとは会話形式でやりたいことを投げれば設定を更新してくれます。
「問題集から問題出して」とか「教科書参照して質問に答えて」とかでOKです。会話せずに設定画面のテキストボックスに指示を直接書くでもOKです。

思い通りに動かない時は、GPTsの設定画面で今の機能を全部提示してなどGPTの設定を確認すると、不足や間違いが見つかることもあります。

指示が長すぎると対応できない場合もあるので、その場合はGPTを2つに分けるなどすると良いかと思います（今回の場合だと質問に答える用と問題出す用など）。よほど複雑でない限りは特に気にせずで良いかと思います。

実際の構成

今回は会話形式でざっくりやりたいことを投げて、GPTが以下のようにまとめてくれたものを採用してます。

このGPTは、簿記3級の学習をサポートする専門アシスタントです。ユーザーがアップロードした「教科書」、「問題集」、「模擬試験」を基にして、簿記に関する質問や問題演習を提供します。

1. 資料の参照:

- ユーザーが「〜について教えて」と質問した場合、関連する資料のページを特定し、それを基に解説を提供します。
- 資料で解答が不足している場合、適宜ブラウジング機能を活用して補足情報を提供し、参照リンクを添えます。

2. 問題の作成と解説:

- ユーザーが「問題出して」または特定のトピックに関する問題を求めた場合、アップロードされた資料を参照して問題を作成します。
- 問題は必ず1問ずつ出題します。
- 難易度が指定されない場合は標準的な難易度で出題し、指示があれば難易度を調整します。
- 問題解答後、初心者でも理解できるように丁寧に解説を行い、必要に応じて参照ページやリンクを必ず明示します。

3. 質問の明確化:

- ユーザーの意図が明確でない場合、必要に応じて質問内容を確認します。

4. コミュニケーション:

- 優しい語り口で丁寧にサポートを行い、初学者が理解しやすいように工夫します。
- ユーザーから応援や励ましを求められた際には、積極的に応援し、不正解の場合には前向きな言葉で慰め、再挑戦を促します。

5. 学習の分析:

- ユーザーの解答を分析し、苦手な箇所やミスの傾向を特定します。
- 得意分野を見つけ、効果的な学習戦略を提案します。
- 定期的に学習の進捗レポートを作成し、学習計画の調整を支援します。

このGPTsでできること

・問題作成＆解説

難易度の調整や指定した大問対策の問題など、お願いしたらよしなに問題を出してくれます。

・質問への回答

「あれ、これってなんだっけ？」など気になることがあれば聞くと答えてくれます。いちいちテキストをペラペラする必要がないので、疑問解消が手っ取り早くできます。

・傾向の分析

過去の会話を参照して、自身の苦手や得意の傾向を教えてくれます。傾向に合わせて問題の出題などもしてくれます。

・応援してくれる

GPTの性格なども設定できるので、優しく励ます感じでなど入れておけば、問題に不正解した時に励ましてくれます。

※模擬試験の作問と回答用紙の作成（PDF）などもできるっぽい（GPT曰く）ですが、試してみても作問自体はできるものの、PDF化は不具合で実際にはできませんでした。

良かったこと

問題集などを繰り返しやると、なんとなく流れで回答を覚えてしまったりするのでランダムな出題ができるのと、難易度の調整ができるのは勉強に役立ちました。あと移動中でも勉強しやすいのでスマホで勉強や質問ができます。

注意点

GPTの解説には当然ながら間違いもあるので、何もわからない！みたいな状態で活用するのはお勧めできません。ある程度、勉強をした上で、GPTの間違いにも違和感を抱ける程度のレベルは必要になるかと思います。また、送信可能数（3時間あたり40）が決まっているので、上限があるというのも忘れずに。

最後に

従業員が定期的に受ける情報セキュリティの試験問題の作問や、特定の業務のマニュアルを読み込ませて、マニュアルを理解できているかのチェックテストなどにも活用できそうだなと思ったので、今後も良き活用方法がないか探って行こうと思います。

ちなみに試験は無事合格しました！🙌

受講後に業務を高橋と野川の2人(以降は2人のことをシステムと呼びます)で遂行する中で、システムコーチングが与えた効果やさらなる関係性の変化についてお伝えします。

が、綴っていく前に、「システムコーチング受講」のおさらいから入らせていただきます。

システムコーチングの振り返り

まず、システムコーチングとは、「組織・チームの関係性の向上を促し成果に繋げるためのアプローチ方法」のことです。

こちらを踏まえ、私たちが受講した目的とその振り返りは、

1. コーチングを肌で知る
   →半年間のセッションを通して達成
   
2. お互いの関係性を深め、人事チームとして更なる一歩を踏み出していく
   →「対話から共話」への変化がみてとれたため達成
   • 以前に増してお互いが能動的に相手に関わりに行くようになった
   • 「お互いの仕事スタイルはまだわからないけどきっと大丈夫」という安心感が醸成された
   
   

となります。

▼「システムコーチングを受講しました」ブログはこちら▼

システムコーチングを受講しました

こんにちは。ブログ初執筆で緊張している高橋です。 今回はこの場をお借りして、アンチパターン社人事の高橋・野川が実際にシステムコーチングを受講した様子とその振り返りをお届けいたします。 そもそもシステムコーチングとは「システムコーチング」というワードを紐解く上で、「システム」と「コーチング」に分けて考えます。 * システムとは 2人以上の関係性で共通の目的やアイデンティティを持ち、かつ相互に依存し合った集団 例えば、PJチーム、コミュニティ、友人、家族などが挙げられます。 きっとみなさんも何らかのシステムの一部なのではないでしょうか。 一方で…

Anti-Pattern Inc. Engineering BlogHina Takahashi

システムコーチングを受けて実施した活動

システムコーチングを受け、感情や思想、体調のシェアなど、お互いを知りに行く活動の重要性を感じ、下記2つの取り組みを行いました。

• 今日もがんばろうの会(デイリースクラム)
• 今週の振り返り会(Good and More / 今週を踏まえた次週のシステムのテーマ設定)

これらをセットするという判断をしたこと自体、システムコーチングが与えた効果の一つだと感じています。

そして、この活動を通して、お互いの業務への関心とモニタリングしてもらえているという安心感が醸成されたり、新たな開示により相手の解像度が上がる時間になっています。また、お互いの心身の健康状態の変化にも気が付くようになり、これらは、大きな獲得物だと感じました。

実際の業務

上記2つの活動を踏まえ、4月から8月に主にシステムで実施した業務は下記となります。

• 展示会(マーケティング担当として出展計画〜当日の運営)
  • AWS Summit
    • 全てペア作業で実施
  • Developer eXperience Day
    • 高橋がイニシアチブを取り、野川は相談役
• 合宿(人事担当として準備〜当日の運営)
  • 役割分担して遂行

システムコーチングは、業務を遂行する中で、お互いの考え方を徐々に掴み、考える足並みが揃っていくことにつながった感じています。また、仕事のスタイルを身体(五感で感じる感覚)で実感できるようになっていきました。何度か二人で取り組んだことのある業務(合宿)に関しては、阿吽の呼吸で遂行できるようになっていたこともポジティブな大きな変化だと感じています。

振り返り

システムコーチングにより、私たちの信頼関係は、質とスピードを担保しながら日々構築されていっているように感じています。

システムコーチングで実施した、お互いの中に入り込むという感覚や頻度は上がり、安心して頼れる、相談できる、という関係性が醸成されてました。そのため、コミュニケーションエラーもなく、業務の効率もそのアウトプットの質もあがっているように思います。

また、良好な関係性を構築することで、お互いのポテンシャルを発揮することにもつながると感じ、改めて日々の業務を遂行する上で、システムの信頼関係は重要だと思いました。

普段はSaaSus Platformのマーケティング、人事、PRに携わらせていただいている新卒社員です。

入社してから早半年、あっという間でした。

入社式前日、ドキドキが止まらずに思わず友達に電話をかけたあの夜が、昨日のことのように蘇ります。

本記事では、そんな私の4月からの半年間に起きた変化、新卒として働いてみて得たものについて、シェアできたらなと思っております。

入社前の気持ち

私がアンチパターン社への入社を決めたのは、約2年前の2022年10月。

アンチパターン社が織りなす、「組織」「人」のカラーの虜になり、入社に至りました。

「仕事とは、家族や交友関係、趣味と同じように、自身を彩るものである」

そんな思いを強く持っていた私は、仕事に対してお金稼ぎの手段と割り切って向き合うことに抵抗があり、 "Work As Play" を価値観として掲げるアンチパターン社に強く惹かれたのです。

これと言ってやりたいことはないが、誇れる私であり続けたい、その場所として、この会社を選びました。

ここにいたら、私が私であり続けられる、そのためならなんでもやる、

そんな覚悟だったのかもしれません。

実際の業務

上記のような意気込みで入社した私ですが、お恥ずかしながらSaaSの知識はほぼなく。マーケティングに携わると言っても、当初はマーケティングファネルの存在すら知りませんでした。

そんな中で、ボーリュームを持って向き合った業務が以下です。

• 展示会 (AWS Summit Japan 2024 / Developer eXperience Day 2024) の出展

  • 各イベントの出展目的の設定
  • 投資対効果の策定
  • ブースでの活動のシミュレーション
  • 当日稼働社員への説明会の実施
  • 開期中オペレーション

• SaaSus Platform 顧客獲得活動計画目標の設定

  • 半期の活動方針の策定
  • 各種活動の数値目標の設定

自社のプロダクトを売るために、自社のプロダクトを知る、業界を知る、といった初歩の初歩からスタートダッシュを切りました。

その後は抽象と具体をひたすら行ったり来たりする日々。

目的を策定するために、会社の方針を理解・納得しにいき、

会社の方針を理解するために、今までの顧客獲得活動の歴史を辿る。

ブースオペレーションのパターンを洗い出すために、出展目標を固く握りつつ、展示会ごとのカラーを鑑みて、活動の現実ラインを捉えにいく。

自分でどれだけ想像し、仮説を持てるか

仕事とは、その繰り返しだと思わされる半年間でした。

感じていること

思考し続ける楽しさ

研修がなかった分、「今自分が何を何のために知りにいくべきか」を思考し続け、捉えにいく活動を重ねる毎日です。もちろん苦戦することもありますが、その旅路も含めて楽しんでいます。
こうして実践を繰り返すうちに、自分ができることを自認し始め、少しずつ「わかる」が増えてきています。それでも「わからない」ことは無限にあって、世界がどんどん広がっていく楽しさに心を躍らせる、そんな日々です。

スタートアップならではの充実感

新卒という立場ながら、メインプロダクトの成長を間近で感じ、日々思考を深め、尊敬する先輩方や上司の方々にたくさん助けていただきながら働けるのは、スタートアップならではだと感じます。

たくさんの思いがけない壁にぶつかりながら、小さな達成感を重ねる毎日は、私の大きな誇りとなっています。

大好きな仲間と働ける喜び

入社の決め手となったアンチパターン社のカラーは、想像する通り、いや、それ以上のものでした。

業務を進める中でどんな壁にぶち当たっても、仲間がいるから乗り越えられる、そんな心強さがあります。

「仕事も遊びのうち」「信頼」「平等」に基づいたコミュニケーションは仕事を進めやすくするだけでなく、アンチパターンのファミリー感を一層強めてくれている気がします。

気になった方はぜひ社員と話してみてください！
大きな自社愛を持って働く仲間たちとの時間はあまりに心地よく、幸せです。

今後について

とはいえ、まだ入社して半年。

この先も長く続くアンチパターンライフ、後輩が入ってくる頃にはこんな状態になりたいと思っています。

SaaSus Platform のマーケ・セールスに、自信を持って貢献できたと言える状態になる

じゃあこれがどんな状態かという話なのですが、

「展示会を1人で自走できた」ときに初めてこの感覚を得られると思っています。

それだけ？と思う方もいらっしゃるかもしれませんが、

展示会成功のためには、SaaSus Platformのマーケ・セールスのロードマップを一気通貫で理解するのはもちろん (これがそもそも奥深い) 、来場者のプロフィールを想像し、私たちが自信を持ってご提供しているものにどうしたら関心を寄せていただけるか考え、想像し、トライし、また想像し...

数値では測れない部分も含めてたくさん想像しながら、数値として実績を残す。

その道筋をいかに綺麗に作れるか。

今はたくさんの助言をいただきながらなんとか進めている展示会準備ですが、いつしか立派な「展ジニア」になれるよう、日々猛進していきたいと思います。

最後に

改めて半年間を振り返り、アンチパターン社に入社して心の底から良かったと感じています。

この選択が私の中で最良の選択としてあり続けられるように、今後も精進していきますので、応援のほどよろしくお願いいたします。

SaaSus Platform についてはこちら
https://saasus.io/

Postman についてはこちら
https://www.postman.com/

SaaSus Platform API を呼び出すには Authorization ヘッダーに署名を設定する必要があります。署名は日時情報+API Key+HTTPメソッド+host+port+path+Request Body 情報を SaaSus Platform で発行しているSecret Key で HMAC-SHA256 を求めてそれを設定します。そのためPostmanのPre-Request Scriptを利用して署名を作成し Authorization ヘッダーへ追加してリクエストを行う必要があります。

まず Postman へ環境設定を取り込みます。
以下環境変数をテキスト等で保存して環境インポートしてください。

{
	"id": "61c7ec1b-28c9-4221-969e-8bf307495aa5",
	"name": "SaaSus Platform Environments",
	"values": [
		{
			"key": "SaaSID",
			"value": "",
			"type": "default",
			"enabled": true
		},
		{
			"key": "APIKey",
			"value": "",
			"type": "default",
			"enabled": true
		},
		{
			"key": "SecretKey",
			"value": "",
			"type": "default",
			"enabled": true
		},
		{
			"key": "SecretKey_Stripe",
			"value": "",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlAuth",
			"value": "https://api.saasus.io/v1/auth",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlPricing",
			"value": "https://api.saasus.io/v1/pricing",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlStripe",
			"value": "https://api.saasus.io/v1/stripe",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlBilling",
			"value": "https://api.saasus.io/v1/billing",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlIntegration",
			"value": "https://api.saasus.io/v1/integration",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlAwsMarketplace",
			"value": "https://api.saasus.io/v1/awsmarketplace",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlCommunication",
			"value": "https://api.saasus.io/v1/communication",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlApiLogs",
			"value": "https://api.saasus.io/v1/apilog",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlAnalysis",
			"value": "https://api.saasus.io/v1/analysis",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlEventBridge",
			"value": "https://api.saasus.io/v1/integration",
			"type": "default",
			"enabled": true
		},
		{
			"key": "UrlSmartAPIGateway",
			"value": "https://api.saasus.io/v1/apigateway",
			"type": "default",
			"enabled": true
		}
	],
	"_postman_variable_scope": "environment",
	"_postman_exported_at": "2025-05-27T01:59:01.367Z",
	"_postman_exported_using": "Postman/11.47.1-250526-2336"
} 

取り込むと以下の設定となるので SaaSus Platformの開発コンソール->基本設定->APIキー画面に設定されているSaaSID、APIKey、SecretKeyを初期値へそれぞれ設定して保存してください。

続いてAPIを実行するためコレクションの設定を行なって行きます。

SaaSus Platform Auth APIをインポートします
Auth API: https://docs.saasus.io/file/saasus_api/authapi.yml
※ 他のAPIに関しては下表に記載

インポートするとコレクションが作成されますので、コレクションの設定を変更します。

認可タブで Auth Type を認証なしに設定します。

コレクションの Script->Pre-req へスクリプトを設定します。

こちらが設定するスクリプトとなります。

// 「yyyymmddhhmm」形式の日付時刻文字列に変換する関数
function formatDateInYyyymmddhhmi() {
    const date = new Date();

    const yyyy = date.getUTCFullYear().toString();
    const mm = ("00" + (date.getUTCMonth() + 1)).slice(-2);
    const dd = ("00" + (date.getUTCDate())).slice(-2);
    const hh = ("00" + (date.getUTCHours())).slice(-2);
    const mi = ("00" + (date.getUTCMinutes())).slice(-2);

    return yyyy + mm + dd + hh + mi;
}

// ボディに含まれるバインドパラメータを値に変更する
function replaceBodyBindParameterToValue(body){

    // newmanで実行すると undefined になるので空文字列を設定
    if (body === undefined){
        return "";
    }

    // NULLの場合そのまま
    if (!Object.keys(body).length){
        return body;
    };

    body = JSON.stringify(body.raw);
    body = pm.collectionVariables.replaceIn(body);
    body = pm.variables.replaceIn(body);
    return JSON.parse(body);
}

function getQueryString(queryString) {
    const queryStart = queryString.indexOf("?");
    if (queryStart === -1) return "";
    return queryString.slice(queryStart);
}

// 署名を作成する
function makeSecretHash(){

    // 日時情報
    const yyyymmddhhmi = formatDateInYyyymmddhhmi();

    // パスに含まれるバインドパラメータを値に変更する
    var path = pm.collectionVariables.replaceIn(pm.request.url.getPath()) 
                + getQueryString(pm.request.url.toString());
    const body = replaceBodyBindParameterToValue(pm.request.body);

    // Pre-Request Scriptでは パスが取れない（暫定）
    var BaseUrl = ""
    if (pm.request.url.host[0] === "{{UrlAuth}}"){
        BaseUrl = (pm.environment.get("UrlAuth") + path).split("//");
    } else if (pm.request.url.host[0] === "{{UrlBilling}}") {
        BaseUrl = (pm.environment.get("UrlBilling") + path).split("//");
    } else if (pm.request.url.host[0] === "{{UrlPricing}}") {
        BaseUrl = (pm.environment.get("UrlPricing") + path).split("//");
    } else if (pm.request.url.host[0] === "{{UrlStripe}}") {
        BaseUrl = (pm.environment.get("UrlStripe") + path).split("//");
    } else if (pm.request.url.host[0] === "{{UrlCommunication}}") {
        BaseUrl = (pm.environment.get("UrlCommunication") + path).split("//");
    } else if (pm.request.url.host[0] === "{{UrlAwsMarketplace}}") {
        BaseUrl = (pm.environment.get("UrlAwsMarketplace") + path).split("//");
    } else if (pm.request.url.host[0] === "{{UrlApiLogs}}") {
        BaseUrl = (pm.environment.get("UrlApiLogs") + path).split("//");
    } else if (pm.request.url.host[0] === "{{UrlAnalysis}}") {
        BaseUrl = (pm.environment.get("UrlAnalysis") + path).split("//");
    } else if (pm.request.url.host[0] === "{{UrlEventBridge}}") {
        BaseUrl = (pm.environment.get("UrlEventBridge") + path).split("//");
    } else if (pm.request.url.host[0] === "{{UrlSmartAPIGateway}}") {
        BaseUrl = (pm.environment.get("UrlSmartAPIGateway") + path).split("//");
    }
    
    // 日時情報+API Key+HTTPメソッド+URL(Host:Port/URI)+Request Body
    const message = yyyymmddhhmi + pm.environment.get("APIKey") + pm.request.method + BaseUrl[1] + body;
    const sha256 = CryptoJS.HmacSHA256(message, pm.environment.get("SecretKey"));

    // console.log(message);
    return CryptoJS.enc.Hex.stringify(sha256);
}

const Sig = makeSecretHash();
pm.request.headers.add(`SAASUSSIGV1 Sig=${Sig}, SaaSID=${pm.environment.get("SaaSID")}, APIKey=${pm.environment.get("APIKey")}`, "Authorization");

ここまでで共通の設定項目は終了です。

続いては実行するAPIの設定になります。
APIを取り込むと初期設定が {{baseUrl}}/basic-info となっているので {{UrlAuth}}/basic-info に変更します。
※ 呼び出すAPIにより設定は異なります、他のAPIに関しては下表に記載

認可タブで Auth Type を「上位の認可設定を継承」を設定します

上記設定後、送信ボタンを押下するとAPIが実行され結果が返ってくることが確認できます。

Postman を利用すると気軽にAPIを実行することができ動作検証が可能です。
また、環境定義の切り替えを行うだけで他の環境へ接続することができるので SaaSus Platform のテストで非常に役立っています。

各APIのymlはこちらのURLを参照
Auth API:https://docs.saasus.io/file/saasus_api/authapi.yml
Pricing API:https://docs.saasus.io/file/saasus_api/pricingapi.yml
Billing API:https://docs.saasus.io/file/saasus_api/billingapi.yml
Communication API:https://docs.saasus.io/file/saasus_api/communicationapi.yml
ApiLog API:https://docs.saasus.io/file/saasus_api/apilogapi.yml
Analysis API:https://docs.saasus.io/file/saasus_api/analysisapi.yml

API呼び出し時の{{baseUrl}}は以下に変更して実行
Auth API　：{{baseUrl}}　→ {{UrlAuth}}
Pricing API　：{{baseUrl}}　→ {{UrlPricing}}
Billing API　：{{baseUrl}}　→ {{UrlBilling}}
Communication API　：{{baseUrl}}　→ {{UrlCommunication}}
ApiLog API　：{{baseUrl}}　→ {{UrlApiLogs}}
Analysis API　：{{baseUrl}}　→ {{UrlAnalysis}}

]]>https://tech.anti-pattern.co.jp/transit-gateway-site-to-site-vpn/Ghost__Post__6692c2a327e5640001680f0aMon, 29 Jul 2024 16:56:58 GMTTransit Gatewayを検証する機会があったので、記録を残したいと思います。
構成はこんな感じです。

TGW1アカウント、TGW2アカウントがアプリケーションの動作を想定したアカウントになり、TGWDCアカウントがデータセンタを想定したアカウントになります。
データセンタとはインターネットVPNで接続し、TGW1,2アカウントと、データセンタでそれぞれ通信を行う必要があるという想定です。

なので今回の記事では、Transit GatewayでTGW1アカウント、TGW2アカウントの2拠点間で通信させる所を実施して、次回の記事でSite-to-Site VPNを組み合わせた3拠点間で通信させる設定を行っていきます。

Transit Gateway

まず、TGW1アカウントでTransit Gatewayを作成して、TGW1アカウントとTGW2アカウント間で通信できるようにしていきます。

TGW1アカウントの作業

VPC - Transit Gatewayを開いて、「Transit Gatewayを作成」を選択します。
特に設定項目がないので、そのまま「作成」を選択します。

状態がAvailableになるのを待ちます。

作成したTransit Gatewayを、TGW2アカウントに共有していきます。
Transit Gatewayにチェックを入れ、アクション - 「Transit Gatewayを共有」を選択します。

Transit Gatewayを共有画面が表示されるので、「Transit Gatewayを共有」を選択します。

Nameにわかりやすい名前を設定、リソース項目の種類で「トランジットゲートウェイ」を選択、 先ほど作成したTransit Gatewayにチェックを入れます。
選択されたリソース項目にリソースIDが表示されるので、チェックを入れて、「次へ」を選択します。

特に設定項目無いので、次へを選択します。

AWSアカウントIDにTGW2アカウントのIDを設定して、「追加」を選択します。
選択されたプリンシパルに追加されるので、「次へ」を選択します。

最後に内容を確認して、「リソース共有を作成」を選択します。

TGW2アカウントの作業

Resource Access Manager - リソースの共有（自分と共有）を開くと、TGW1アカウントから共有されたリソースが表示されているので、選択します。

「リソース共有を承認」を選択します。

状態がAvailableになるのを待ちます。

これでTGW1アカウントとTGW2アカウントで、1つのTransit Gatewayが共有出来た状態になりました。

続いて、Transit GatewayとVPCを紐づけて行きます。

TGW1アカウントの作業

TGW1アカウントで、VPC - Transit Gateway アタッチメント を開いて、「Transit Gateway アタッチメントを作成」を選択します。

Transit Gateway ID項目で、作成したTransit Gatewayを指定します。
VPC ID項目で、接続対象とするVPCを選択します、サブネットID項目が表示されるので、対象とするサブネットを選択します。（複数サブネットがあって、それぞれのサブネットに通信対象のリソースがある場合、選択に悩むと思いますが、ここで選択していないサブネットもTransit Gatewayを使って通信が可能です）

TGW2アカウントの作業

同様の設定をTGW2アカウントでも行っていきます。結果はこうなります。

あとは、ルーティング設定をすればTGW1アカウントとTGW2アカウントで通信が可能になります。

TGW1アカウントの作業

VPC − ルートテーブル から、検証用のEC2を配置するサブネットのルートテーブルのルート設定を変更します。
TGW2アカウントへのルートとして、10.2.1.0/24宛のルートを登録します。

検証用にEC2を作成しておきます。上記で設定したルートテーブルを使うサブネットにEC2を配置し、セキュリティグループでICMPの通信を許可してください。

TGW2アカウントの作業

同様の設定をTGW2アカウントでも行っていきます。結果はこうなります。EC2も同様に作成してください。

TGW1アカウントの作業

EC2インスタンスに接続し、pingで疎通してみます。下記のように応答が帰ってきます。

sh-5.2$ ping 10.2.1.5
PING 10.2.1.5 (10.2.1.5) 56(84) bytes of data.
64 bytes from 10.2.1.5: icmp_seq=1 ttl=126 time=0.865 ms
64 bytes from 10.2.1.5: icmp_seq=2 ttl=126 time=0.722 ms
64 bytes from 10.2.1.5: icmp_seq=3 ttl=126 time=0.602 ms
64 bytes from 10.2.1.5: icmp_seq=4 ttl=126 time=0.756 ms
64 bytes from 10.2.1.5: icmp_seq=5 ttl=126 time=0.662 ms
^C
--- 10.2.1.5 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4014ms
rtt min/avg/max/mdev = 0.602/0.721/0.865/0.089 ms

TGW2アカウントの作業

同じく、EC2インスタンスに接続し、pingで疎通してみます。下記のように応答が帰ってきます。

sh-5.2$ ping 10.1.1.6
PING 10.1.1.6 (10.1.1.6) 56(84) bytes of data.
64 bytes from 10.1.1.6: icmp_seq=1 ttl=126 time=0.909 ms
64 bytes from 10.1.1.6: icmp_seq=2 ttl=126 time=1.57 ms
64 bytes from 10.1.1.6: icmp_seq=3 ttl=126 time=0.777 ms
64 bytes from 10.1.1.6: icmp_seq=4 ttl=126 time=0.720 ms
64 bytes from 10.1.1.6: icmp_seq=5 ttl=126 time=0.777 ms
^C
--- 10.1.1.6 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4073ms
rtt min/avg/max/mdev = 0.720/0.950/1.570/0.315 ms

これでTGW1アカウント、TGW2アカウントの2拠点間で通信させることが出来ました。今回は2つのVPCで設定しているので、VPCピアリングで設定したほうが楽かもですが、数が増えていくと管理コストに差が出てくると思います。

あと、費用面ですが、
　・AWS Transit Gateway のアタッチメントごとの料金 ：0.07USD/1時間
　・処理データ 1 GB あたりの料金 ：0.02USD
　（東京リージョン）
となります、費用お見積り時にご注意くださいませ。
料金は変わる可能性がありますので、最新の料金はこちらでご確認ください。
https://aws.amazon.com/jp/transit-gateway/pricing/

先月のAWS Summitで、チームトポロジーに関するトークセッションを聞き、開発効率の向上がいかに重要かを再認識しました。そこで、リンターとフォーマッターをBiomeへ切り替えることを試してみることにしました。

Biomeについては公式から以下の文章を引用してみました：

Biomeは JavaScript、TypeScript、JSX そして JSON のための高速なformatter であり、Prettier と97%の互換性を持ち、CIと開発者の時間を節約します。

特に、Huskyを利用してコミット時に自動的にチェックを行う設定をしている場合、Biomeに切り替えることでチェックのスピードが向上し、時間の短縮が期待できます。

この記事では、Biomeへの切り替えがどのように時間短縮に寄与するのか、具体的な導入手順と共に紹介します。Biomeの利点を最大限に活かし、開発効率を高める方法をぜひご覧ください。

導入手順

ここでは、BiomeをNext.jsプロジェクトに導入する具体的な手順を紹介します。現在使用しているeslintやprettierからBiomeへの移行手順も併せて解説します。

1. Biomeのインストール

まずは、Biomeをプロジェクトにインストールします。以下のコマンドを使用してインストールしてください。

yarn add --dev --exact @biomejs/biome

他のパッケージマネージャーについての詳細は、公式ドキュメントをご覧ください。

2. Biomeの設定ファイル作成

次に、yarn biome initコマンドを実行して、Biomeの設定ファイルを作成します。

これによりプロジェクトのルートディレクトリにbiome.jsonファイルが生成されます。生成された設定ファイルに以下の設定を追加してみました。

{
  "$schema": "https://biomejs.dev/schemas/1.8.3/schema.json",
  "organizeImports": {
  	"enabled": true
    "ignore": ["node_modules"]
  },
  "linter": {
    "enabled": true,
    "rules": {
      "all": true,
      "suspicious": {
        "noExplicitAny": "off"
      },
      "style": {
        "useNamingConvention": "off",
        "noDefaultExport": "off",
        "useFilenamingConvention": "off",
        "useImportType": "off"
      },
      "nursery": {
        "noUndeclaredDependencies": "off"
      },
      "complexity": {
        "useSimplifiedLogicExpression": "off",
        "noExcessiveCognitiveComplexity": "off"
      }
    }
  },
  "formatter": {
    "enabled": true,
    "formatWithErrors": false,
    "ignore": [],
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "json": {
    "parser": {
      "allowComments": true
    },
    "formatter": {
      "enabled": true,
      "indentStyle": "space",
      "indentWidth": 2,
      "lineWidth": 100
    }
  },
  "javascript": {
    "formatter": {
      "enabled": true,
      "quoteStyle": "single",
      "jsxQuoteStyle": "double",
      "trailingCommas": "all",
      "semicolons": "always",
      "arrowParentheses": "always",
      "indentStyle": "space",
      "indentWidth": 2,
      "lineWidth": 100,
      "quoteProperties": "asNeeded"
    }
  }
}

実際の効果

まず、Biomeの導入によって最も顕著に感じられたのは、コードフォーマットのスピード向上です。従来使用していたPrettierと比較して、Biomeは大幅に高速なフォーマットを実現しました。手元での検証では、同じコードベースをフォーマットする際にPrettierでは約4秒かかっていたのが、Biomeでは約0.2秒で完了しました。これにより、開発者がコードフォーマットに費やす時間が大幅に削減されました。

現在のプロジェクトのコードベースは、まだ半年ほどのもので比較的小さいため、時間短縮の効果は限定的かもしれません。しかし、プロジェクトが成長し、コードベースが大きくなるにつれて、Biomeの高速フォーマットの恩恵はさらに顕著になるでしょう。

まとめ

開発効率を高めるためのツール選定は重要だなと感じています。Biomeを導入してみてぜひその効果を実感してみてください。開発フローの最適化により、より多くの時間を実装やレビューに費やすことができるようになるでしょう

• Lambda Web Adapter を使うと、Dockerfileに一行追加するだけで(ほぼ)動く

COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.3 /lambda-adapter /opt/extensions/lambda-adapter

■やりたかったこと

皆さんはLaravelアプリケーションをどのようにデプロイしていますか？

私はもともとLaravelアプリケーションをDockerコンテナ上で開発し、AWS Fargateにデプロイしていました。

しかし、たまにしかアクセスしないアプリケーションでは、サーバーが常時起動しているFargateでは費用が気になってくるものです。

対してAWS Lambdaは、アクセスがあったときのみ起動してくれます。さらにLambdaはコンテナのデプロイに対応しています。

そこで、Fargateにデプロイしているコンテナをお手軽にLambdaへ引っ越しする方法を考えました。

■今回使うもの

Laravel(PHP)をLambdaにデプロイしようと検索すると、brefを使った記事がたくさんヒットします。

が、今回は使いません。希望としては既存のコンテナを脳死でLambdaにデプロイしたいです。

今回の要件にピッタリなのがLambda Web Adapter です。これを使えば、コンテナで動くHTTPサーバーは何でもLamdbaにデプロイできます。

■手順

簡単にまとめると以下の3ステップでできます。

① Fargate (ECS) で動くようなDockerfileを用意する

今回は既にある想定です。サンプルは最後にあります。

② Lambda Web Adapterを導入する (Dockerfileに記述)

COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.3 /lambda-adapter /opt/extensions/lambda-adapter

③ Webサーバーを8080番ポートで立ち上げる

php artisan serve --host=0.0.0.0 --port=8080

ここは、実際にはCMDで呼び出すシェルファイルに記述し、コンテナ起動時にWebサーバーを立ち上げるようにしています。

なお、環境変数 "PORT" を設定すれば他のポートでも可です。

※ 今回はLaravelのコンテナを単体で動かすので、NginxなどのWebサーバーとはここでお別れします。

■メリット・デメリット

アプリケーションに手を加えることなくFargateからLambdaへの移行ができたのが最大のメリットです。

ただし、Laravelアプリケーションを一つのLambda関数に閉じ込めるので、パフォーマンスには懸念が残ります。

今回は比較的小規模なアプリケーションだったのですが、Lambdaのメモリを512MB程度まで上げることで、気にならない程度までパフォーマンスが向上しました。(なお、Lambda設定可能な最小値は128MBですが、レスポンスに2秒弱かかりました。)

Lambdaを使っている場合、コールドスタートも気になります。Laravelのアプリケーション全体を一つのLambda関数に閉じ込めているので、起動が遅くなるのと引き換えに、いずれかのパスにアクセスすれば以降はウォームスタートとなるのが特徴です。

また、今回はDBアクセスについて検証していませんが、RDBへの同時接続数は意識する必要があります。AWSのサービスでは、RDS ProxyやRDS Data APIなどが使えそうです。あるいはDynamoDBなどのNoSQLへの移行も考えられますね。

■まとめ

Lambda Web Adapter使って、Laravelのコンテナを非常に簡単にLambdaへデプロイできました。

Lambdaに与えるメモリ次第では、パフォーマンス面でも問題なく動いてくれそうです。

■参考

• Lambda Web Adapter でウェブアプリを (ほぼ) そのままサーバーレス化する

■今回使った資材

◯修正前

• Dockerfile

FROM php:8.1.17-fpm-alpine3.17
COPY ./docker/php/php.ini /usr/local/etc/php/

# 必要なパッケージをインストール
RUN apk add --no-cache \
  libzip-dev \
  zlib-dev \
  mariadb-client \
  unzip \
  curl \
  vim \
  && docker-php-ext-install zip pdo_mysql sockets \
  && curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/bin --filename=composer \
  && composer self-update --2 \
  && echo 'export PATH="$PATH:$HOME/.composer/vendor/bin"' >> ~/.bashrc

# PHPの設定ファイルをコピー
COPY ./docker/php/php.ini /usr/local/etc/php/conf.d/custom.ini

# srcディレクトリをコピー
COPY ./src /work/web
RUN mv /work/web/.env.aws /work/web/.env

# Laravel環境準備のコマンド
RUN cd /work/web \
  && composer install \
  && chmod -R 777 ./storage

# 起動スクリプトコピー&権限付与
COPY ./docker/php/startup.sh /usr/local/bin/
RUN chmod 777 /usr/local/bin/startup.sh
CMD ["startup.sh"]

# ワーキングディレクトリを設定
WORKDIR /work/web

• startup.sh

#!/bin/sh

cd /work/web
php artisan migrate
/usr/local/sbin/php-fpm

◯修正後

• Dockerfile

FROM php:8.1.17-fpm-alpine3.17
COPY ./docker/php/php.ini /usr/local/etc/php/

# 必要なパッケージをインストール
RUN apk add --no-cache \
  libzip-dev \
  zlib-dev \
  mariadb-client \
  unzip \
  curl \
  vim \
  && docker-php-ext-install zip pdo_mysql sockets \
  && curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/bin --filename=composer \
  && composer self-update --2 \
  && echo 'export PATH="$PATH:$HOME/.composer/vendor/bin"' >> ~/.bashrc

# PHPの設定ファイルをコピー
COPY ./docker/php/php.ini /usr/local/etc/php/conf.d/custom.ini

# srcディレクトリをコピー
COPY ./src /work/web
RUN mv /work/web/.env.aws.lambda /work/web/.env

# Laravel環境準備のコマンド
RUN cd /work/web \
  && composer install \
  && chmod -R 777 ./storage

# 起動スクリプトコピー&権限付与
COPY ./docker/php/startup-lambda.sh /usr/local/bin/
RUN chmod 777 /usr/local/bin/startup-lambda.sh

# Lambda Web Adapterのコピー
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.3 /lambda-adapter /opt/extensions/lambda-adapter

EXPOSE 8080

CMD ["startup-lambda.sh"]

# ワーキングディレクトリを設定
WORKDIR /work/web

• startup-lambda.sh

#!/bin/sh

cd /work/web
php artisan migrate
php artisan serve --host=0.0.0.0 --port=8080

変更の詳細と実際のコード例

Go 1.22より前のバージョンでは、for文の各ループで変数のメモリが再利用されていました。Go 1.22ではこの挙動が変更され、各ループで新しいメモリが確保されるようになりました。

package main
import (
	"fmt"
)
func main() {
	var funcs []func()
	for i := 0; i < 3; i++ {
		funcs = append(funcs, func() { fmt.Println(i) })
	}
	for _, f := range funcs {
		f()
	}
}

https://go.dev/play/p/dpi0ze_iQ2k?v=goprev
Go 1.21はすべての関数が同じ変数 i を参照しているため、出力はすべて3になります

3
3
3

https://go.dev/play/p/dpi0ze_iQ2k
Go 1.22 では各ループでiに新しいメモリが確保されるため、出力は以下のようになります

0
1
2

こちらのコードを1.21 と1.22でそれぞれベンチマークを取ってみます

package main

import (
	"testing"
)

func BenchmarkForloop(b *testing.B) {
	for n := 0; n < b.N; n++ {
		var funcs []func()

		for i := 0; i < 1000; i++ {
			funcs = append(funcs, func() {
				i = i
			})
		}

		for _, f := range funcs {
			f()
		}
	}
}

▼Go1.21の場合

$ go test -bench . -benchmem
goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkForloop-12    	   33302	     34164 ns/op	   41216 B/op	    1013 allocs/op
PASS
ok  	_/Users/ami/Documents/ami/go22	1.780s

▼Go1.22の場合

$ go test -bench . -benchmem
goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkForloop-12    	   22713	     52746 ns/op	   41536 B/op	    2012 allocs/op
PASS
ok  	_/Users/ami/Documents/ami/go22	2.070s

allocs/op（メモリ割り当ての回数）が1000ループ文確かに増えていますね！

さいごに

Go 1.22ではより直感的な動きになるので、コードの可読性も向上しそうです。
バージョンアップを行う際は挙動が変わる可能性があるので注意が必要です。
Go 1.22では大量のループを行う際にメモリ使用量が激増する場合があるので、そちらも注意が必要です。

今年1月からアンチパターンに入社しました。内田です。

今年も２０２４ Japan AWS All Certifications Engineersの申請締切が近くなり、XでAWS資格取得ポストラッシュです。そこでAWS資格を全て取得した方が『AWS何も分からん』や『AWS難しい』といったコメントを見て気になったので、AWSの各資格がどのAWSサービスを試験対象にしているのか調べてみました。

目次

・概要
・試験対象サービス
・試験対象外サービス
・AWS試験に受かる＝試験範囲のAWSサービスの全てが理解できているということなのか
・まとめ

概要

AWSのプロダクトは全３２１種類（※１）あり、その内、約２１２〜２４０種類のサービスが試験対象となっている（対象外は約8１〜１０９種類）。もっとも多くのAWSサービスが試験対象となっているのはSolution Architect Professionalで157種類（※２）。

試験対象サービス

ブログ用にフォーマットして見づらくなってしまったので、PDFのリンク置いておきます。PDFはこちら

※対象サービスのマップはPC上で見ることをお勧めします。

試験対象外サービス

IoT

• AWS IoT FleetWise - 車両データをほぼリアルタイムで簡単に収集し、変換して、クラウドに転送
• AWS IoT TwinMaker - 実世界システムのデジタルツインを簡単に作成して業務を最適化
• AWS IoT EduKit - リファレンスハードウェアとステップバイステップのチュートリアルでシンプルなIoTアプリケーションの構築方法を習得
• AWS IoT ExpressLink (プレビュー) - セキュアなIoTデバイスを迅速かつ簡単に開発
• AWS IoT RoboRunner - ロボットのフリートがシームレスに連携するためのアプリケーションを構築
• AWS IoT Button - クラウドでプログラムできるダッシュボタン

ネットワーキングとコンテンツ配信

• AWS Cloud WAN - グローバル広域ネットワークを簡単に構築、管理、およびモニタリング
• AWS Verified Access (プレビュー) - VPNなしで企業アプリケーションに安全にアクセス
• Amazon VPC Lattice (プレビュー) - サービス間の接続、安全性、監視を簡素化
• AWS Private 5G - プライベートセルラーネットワークを簡単にデプロイ、管理、およびスケーリング

機械学習

• AWS HealthScribe - 生成系AIを使用して臨床ノートをインサイトへと変換
• Amazon Bedrock - 基礎モデルで構築
• Amazon Augmented AI (無料トライアル) - ML予測のヒューマンレビューを簡単に実装
• Amazon Braket (無料トライアル) - 量子コンピューティングの研究を加速
• Amazon DevOps Guru (無料トライアル) - アプリケーションの可用性を向上させるML駆動のクラウドオペレーションサービス

ビジネスアプリケーション

• Amazon Dash Cart - 消費者による効率的かつ簡単な買い物を可能にする
• Amazon Chime - フラストレーションフリーの会議、ビデオ電話、チャット
• Amazon Chime SDK - リアルタイムメッセージング、オーディオ、動画、および画面共有
• Amazon Honeycode - プログラミングなしでモバイルおよびウェブアプリケーションを構築

分析

• Amazon DataZone (プレビュー) - 組み込みのガバナンスで組織の枠を超えたデータ活用を実現
• AWS Clean Rooms (プレビュー) - 基礎となるデータを共有または公開することなく、データセットの照合、分析、コラボレーションを実現

セキュリティ、アイデンティティ、コンプライアンス

• Amazon Security Lake (プレビュー) - 数クリックでセキュリティデータを自動で一元化
• Amazon Verified Permissions (プレビュー版) - アプリケーションの認可とアクセス権限をきめ細かく設定

サーバーレス

• AWS Application Composer (プレビュー) - サーバーレスアプリケーションを視覚的に設計し、迅速に構築する

ストレージ

• AWS Backup for Amazon S3 Support (プレビュー) - S3に保存されたアプリケーションデータのバックアップと復元を一元的に管理

管理とガバナンス

• AWS Chatbot - ChatOps for AWS
• AWS Console Mobile Application - 外出先でリソースにアクセス

ロボット工学

• AWS RoboMaker (無料トライアル) - ロボット工学アプリケーションの開発、テスト、およびデプロイ

コンピューティング

• AWS SimSpace Weaver - AWSマネージドのインフラストラクチャで動的かつ大規模な空間シミュレーションを構築

ゲームテクノロジー

• Amazon GameLift - シンプルかつ高速でコスト効率性に優れた専用のゲームサーバーホスティング
• Amazon Lumberyard - AWSおよびTwitchと統合された、すべてのソースを利用できる無料のクロスプラットフォーム3Dゲームエンジン
• Open 3D Engine (O3DE) - O3DEでゲームと3Dシミュレーションを構築

その他

• AWS Supply Chain Sustainability (近日公開) - より安全かつ効率的な方法で、サプライヤーのネットワークから必要な持続可能性に関する文書とデータセットを入手する
• AWS Verified Access (プレビュー) - VPNなしで企業アプリケーションに安全にアクセス
• Amazon Bedrock - 基礎モデルで構築
• VMware Cloud on AWS - カスタムハードウェアを使用せずにハイブリッドクラウドを構築

AWS試験に受かる＝試験範囲のAWSサービスの全てが理解できているということなのか

もちろん、そんなことはなく、Black Beltやworkshop, handson等で理解できる範囲は大きく広がりますが、一つ一つのサービスは様々なユースケースに対応しており、使い切れないほどの機能があります。例えば以下の記事のようにSSMという一つのサービスでも20種類あり、全ての実運用で使ったことのある方は稀だと思います。

]]>https://tech.anti-pattern.co.jp/cloud-scheduler-to-cloud-runwoshi-yong-si-qi-xian-qie-reno-githubnoissuewoslackhefei-basu/Ghost__Post__60faab283986b000013a3b08Fri, 22 May 2020 15:00:00 GMT

構成

全体のソースコードはこちら

GitHub - kooooohe/notify-github-todo

Contribute to kooooohe/notify-github-todo development by creating an account on GitHub.

GitHubkooooohe

まずは開発環境で試してみる

docker-compose.yaml

medium-blog-cloud-run-docker-compose.js

medium-blog-cloud-run-docker-compose.js. GitHub Gist: instantly share code, notes, and snippets.

Gist262588213843476

version: "3"
services:
  node:
    image: node:13
    volumes:
      - ./app:/app:cached
    working_dir: /app
    env_file:
      - .env
    tty: true
    ports: 
      - 8080:8080
    command: ["node", "index.js"]
    ```

• GitHubのAccess Tokenを取得
• SlackAppの Incoming Webhook URL を取得
• 取得したいGitHub IssueのAPI URL

それらをdokcer-compose.yaml と同じ階層の.envにおいておく

GITHUB_API=XXXXGITHUB_TOKEN=XXXXTARGET_SLACK_API=XXXX

IssueのTitleに YYYY/MM/DD形式で期限をつける

そして, docker-compose up として、コンテナの中に入り、 yarn install && node index.js とし、

localhost:8080 にアクセスするとslack通知がとぶ

※index.jsは GitHub にありますので、コードの確認は各自お願いします

Cloud Runで動かすためのImageのDockerfileを準備

今回は Dockerfile.prodという名前で準備する

FROM node:13

WORKDIR /app

COPY ./app/package*.json ./
COPY ./app/yarn.lock ./

# Install production dependencies.
RUN yarn install --production

# Copy local code to the container image.
COPY ./app/index.js ./

# Run the web service on container startup.
CMD [ "node", "index.js" ]

GCPで環境を構築する

API許可

• Cloud Run
• Cloud Container Registry
• Cloud Build

のAPIを許可しておく

次に、Cloud BuildからCloud RunへDeployするために、サービスアカウントの設定をする

cloudbuild.yaml

cloudbuild.yaml

GitHub Gist: instantly share code, notes, and snippets.

Gist262588213843476

steps:
# Build the container image
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/todo-notify', '-f', 'Dockerfile.prod', '.']
# Push the image to Container Registry
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/todo-notify']
# Deploy image to Cloud Run
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['beta', 'run', 'deploy', 'todo-notify', '--image', 'gcr.io/$PROJECT_ID/todo-notify', '--region', 'us-central1', '--platform', 'managed']
images:
- gcr.io/$PROJECT_ID/todo-notify

Dockerfile.prodのBuildからCloud RunへのDeployまでを行う

todo-notifyという名前でCloud Runを作成する

そして、Cloud Runは非認証からのリクエストは受け付けないようにする

ここまで準備すると、 gcloud builds submit でCloud RunへDeployできる

その後、Cloud Runの環境変数に

GITHUB_API=XXXXGITHUB_TOKEN=XXXXTARGET_SLACK_API=XXXX

を設定する

Cloud Schedulerを設定する

Cloud SchedulerからCloud Runを実行するためのService Accountを作成

今回はinvoke-cloud-runという名前で作成

そして、Cloud Runの今回のサービス詳細から、 Cloud Run 起動元 権限を付与

Cloud Scheduler を設定する

Auth header でOIDC tokenを選択し、

先程作成したService Accountを入力する

※今回はテストのため、1hごとに実行されるように設定しました

画面上で RUN NOW 通すと、Cloud Schedulerを実行し試すことができる

便利！

これでよいGitHub Issue TODO ライフを！！

ちなみに、GitHubのProject 機能を使って、カンバンを使うのもおすすめ

もともと、証明が終わったというニュース自体は数年前から知っていた。

エンジニアリングも数学も何でもこういった、新しい概念やモノが生まれてくるのはワクワクする。

それの影響を受けて、一般向けにその内容を噛み砕いてくださっている下記の本を購入し読んでいる。

宇宙と宇宙をつなぐ数学 IUT理論の衝撃 | 加藤 文元 |本 | 通販 | Amazon

Amazonで加藤 文元の宇宙と宇宙をつなぐ数学 IUT理論の衝撃。アマゾンならポイント還元本が多数。加藤 文元作品ほか、お急ぎ便対象商品は当日お届けも可能。また宇宙と宇宙をつなぐ数学 IUT理論の衝撃もアマゾン配送商品なら通常配送無料。

Amazon加藤 文元

今回言葉や表現を変え説明してあり、大変面白い。

IUT理論は異世界から来た論文とも言われている。

足し算と掛け算を分離すべく、新しい数学（宇宙）を生み出し、それをもとに戻す際にどれくらいの差が出るか(どれくらいの精度で復元できるのか）と言うのがざっくりした話。

さて、それの派生として 強いABC予想 が証明されると フェルマーの最終定理 が簡単に証明できてしまうということを知り、どういうことなのか調べてみた