AI コンピューター on 向叔の手帳

Vera Rubin の 10 倍 / メガワットあたりの Tokens は、AI の価格を引き下げるのか？

Wed, 22 Jul 2026 21:13:54 +0800

NVIDIA が DeepSeek-R1 推論について発表したベンダーのベンチマークによれば、Vera Rubin NVL72 は 1 メガワットあたりのトークン数において、比較対象の GB200 NVL72 の 10 倍の性能を示すという。これはラック規模システムでの比較であり、単一 GPU に関する結論ではない。

この数字が大きすぎて、誰もが次の文を推測したくなる。同じ1メガワットで10倍の作業ができるなら、AIはすぐに値下がりするはずだ、と。

方向性としては概ね正しいと思うが、結論を急ぎすぎている。

まずこの「10倍」を本来のテスト枠組みに戻そう。これは NVIDIA が、DeepSeek-R1 の推論ワークロード、ラックスケール NVL72 同士のベンダー間ベンチマークとして提示したものである。つまり電力制約のあるシナリオにおいて、1 メガワットあたりでいくつの Tokens を出せるかを示しているに過ぎず、すべてのモデルが10倍速いとか、100万トークンあたりの総コストが90%減ったとは主張していない。現実の運用コストにその指標を換算するには、公表されている資料だけでは不十分である。学習、長コンテキスト、低コンカレンシー、小さなバッチサイズ、異なる精度、異なるサービス品質目標によって、別の数字が出てくる可能性がある。

ただし、この指標は依然として重要です。電力アクセス、液冷、またはデータセンター納入に制約があるプロジェクトでは、同じ電力枠でより多くの推論を実行できれば、拡張のたびに変電所やデータセンターを待つ必要はありません。

問題は、電気料金が原価表の中の一行に過ぎないということです。

Vera Rubin NVL72 を 1 セット導入するということは、古いラック内のカードを入れ替えるだけでは終わりではありません。新しい GPU、相互接続、スイッチネットワーク、液冷、配備エンジニアリングがすべて設備投資に組み込まれます。サービスプロバイダーはさらに、減価償却期間、資金調達コスト、ソフトウェア移行、フォールトトレランス、そして利用率にも対応しなければなりません。マシンが遊んでいる状態では、たとえ 1 メガワットあたりのスループットがいかに見栄え良く見えても、それが自動的に安価な Token にはなりません。

サービスプロバイダーの単位サービスコストを以下のように簡略化します：

$$ \text{トークン単位コスト} \approx \frac{\text{減価償却 + 電力 + データセンター回線 + 運用保守}}{\text{実際に販売された Tokens}} $$

これは変数間の関係を簡略化した枠組みであり、公表資料から算出した TCO ではありません。这里的分母は実際に販売された Tokens であり、設備の理論的スループットではありません。

每メガワット Tokens の基準が直接的に改善するのは、単位電力で支えられる推論能力であり、Token あたりの電力投入を低下させる可能性があります。需要と稼働率が伴って初めて、実際の販売量の増加によって単位サービスコストが改善されます。

新システムの設備投資、減価償却、展開コストは上昇する可能性もあります。ネットワーク、ストレージ、キューイング、スケジューリングも制約要因となり得ます。システムは単一の GPU で動作しているわけではないからです。

最初に起きるのは値下げとは限らない。事業者は新しい余剰容量を、より長いコンテキスト、より速い応答、より高い同時実行性、あるいは元々キュー待ちだった企業の需要を受け止めるために使うかもしれず、開発者にとっては価値があるが、価格表はすぐには変わらない可能性がある。

実際の価格低下が実現するのは、新しいラックがサンプルプロジェクトから複製可能なデータセンター構成へと移行し、利用率も引き上がったときである。その時になって初めて、クラウド事業者やモデル企業、推論サービス事業者が効率向上分を顧客に還元するかどうかは、競争状況次第となる。さらに難しいのは需要の問題である。推論の低価格化が即座に10倍の呼び出し量を誘発すれば、業界全体が得られるのは一人ひとりのコスト低下ではなく、総支出の増大とデータセンターの増加かもしれない。

AIインフラはデフレと拡張の両方を同時に生み出します。1回の生成はより省電力になる可能性があり、ユーザーはより良いモデル能力を得られる可能性がありますが、サービスプロバイダーは新しい能力が新たな用途を引き出すため、より多くのデータセンターを建設する可能性があります。

したがって、Vera Rubin の10倍という数値は、値下げを通知する通達というよりも、値下げへのチケットのようなものです。電力に制約のあるシナリオにおける推論能力を向上させ、サービス提供者にも値下げの余地を残します。その余地を最終的に誰が手に取るのかは、ハードウェアの価格設定、減価償却、データセンターの利用率、そして競争次第です。

ユーザーは最終的に「API がすぐに10倍安くなるか」といった点にこだわらなくてよい。観察する価値があるのは、もっと素朴な2つのシグナルである。同じ予算で、より速く、より長く、より信頼性の高い推論を安定的に買えるかどうか、そして供給が増えてきたとき、サービス事業者が効率性のどれだけを損益計算書に残し、どれだけを価格表に反映するか。前者はまず製品機能の形で現れるかもしれない。後者が現れるかどうか、そして現れる時期は、依然として供給、利用率、競争次第である。

参考資料

写作附记

元のプロンプト

NVIDIA Vera Rubin が全面量産に入り、Spectrum-6 ネットワークと NVL72 のエネルギー効率が 10 倍に向上。DeepSeek R1 の推論テストでは、Vera Rubin NVL72 のトークン処理量がワットあたり GB200 NVL72 比で 10 倍に向上したことが示されています。大規模に出回るようになれば、AI の価格を下げられるようになるのでしょうか。エネルギー効率の明確な向上が見られる一方で、ハードウェアへの投資は大幅に増加しています。

コードモデルにいくつかのコードアンカーを与える

Sun, 05 Jul 2026 23:04:15 +0800

エンコーディングモデルに要件を書くとき、私はますます、リポジトリで検索できる名前をいくつか添える傾向があります。関数名、コンポーネント名、CSSクラス名、あるいはインターフェースパスなど。これらの言葉がなければ、モデルが対応できないわけではありませんが、たいていはまず「この文章はどのコードに対応するのか」を推測する時間を一回費やすことになります。

例えば、次のように書きます。

ログインボタンの無効化状態を調整し、送信中に繰り返しクリックされないようにし、スタイルもグレーにする。

人間はページ全体の印象から「ログインボタン」がどこにあるかを理解できるが、コーディングモデルは数十個のボタン、複数のログインエントリーポイント、コンポーネント・状態管理・スタイルファイルに散らばった実装に直面する可能性がある。まず自然言語の「ログインボタン」をリポジトリ内の具体的なシンボルにマッピングし、その上でイベント処理・状態変数・CSS のどれを修正すべきかを判断しなければならない。

要件を以下のように変更すると、検索範囲はかなり小さくなります。

LoginForm の handleSubmit における送信状態を調整します。送信中は .login-submit を無効化し、重複リクエストを防ぎます。既存のエラー表示の動作は変更しません。受け入れ基準: リクエストが完了していない状態で再度クリックしても 2 件目のリクエストは送信されず、ボタンは無効化されたスタイルになります。また、リクエスト完了後は元の状態に戻ります。

ここで本当に役立つのはプロンプトが長くなることではなく、コード上に落とせるアンカーが数枚増えることである。

モデルが予測中、エージェントはまずコードを探す

現在の主流大規模言語モデルは、通常、入力をトークンに分割し、既存の文脈に基づいて後続のトークンを段階的に予測します。Transformer の自己注意機構により、シーケンス内のトークン同士が関連付けられるようになります。大規模な事前学習とそれに続くアラインメントを経ることで、モデルは指示に従い、コードを解釈し、修正案を生成することができるようになります。しかし、「文脈に基づいて生成できる」ということと、「現在のあなたのリポジトリ内のログインボタンの配置を自然に把握している」ということは同義ではありません。

コーディングエージェントにはもう一つの層があります。ファイル検索、テキスト検索、読み取り、テストツールを呼び出して、リポジトリから関連コードをモデルのコンテキストに取り込みます。関数名 handleSubmit やクラス名 .login-submit はこの段階で二重の役割を果たします。

第一の層は検索アンカーです。自然言語における「ログインボタン」は、文言、コメント、テスト、複数のコンポーネントと一致する可能性があります。正確なシンボルはテキスト検索ツールに直接渡すことができ、定義や参照、関連するテストを素早く見つけることができます。関連のないファイルを少し読む手間を省くことで、時間とトークンを節約できるだけでなく、無関係なコードが判断を妨げるのも軽減されます。

第二の層は意味的な制約です。handleSubmit は変更が送信ロジックに関連することを示唆し、.login-submit は視覚的状態を特定のセレクタに限定し、LoginForm はコンポーネントの境界を提供します。これらが一体となって、「そもそもどのボタンなのか、状態はどの層に置くべきなのか」という曖昧さを減らします。モデルは依然として確率的に生成していますが、選択可能な解釈が減り、次のステップが正しいコードパスに沿って展開しやすくなります。

だからこそ、私はこの書き方を「プロンプトのテクニック」ではなく「座標を提供する」と呼びたいのです。座標はモデルだけでなく、モデル外部のツールチェーンにも役立ってくれます。別のコーディングモデルに置き換えたとしても、リポジトリの検索が必要である限り、これらの座標は価値を持ち続けます。

優れた要件は単なるキーワードの羅列ではない

シンボル名だけでは不十分です。以下のような記述は検索しやすいものの、何に変更すべきか分かりません。

LoginForm、handleSubmit、.login-submit を最適化してください。

私が現在よく使っている書き方には、4種類の情報が含まれています。

情報	役割	例
コードアンカー	検索範囲を絞り込む	`LoginForm`、`handleSubmit`、`.login-submit`
目標とする挙動	変更後に何が起こるかを説明する	送信中は重複リクエストを禁止する
保持する項目	隣接する挙動の偶発的な変更を防ぐ	既存のエラー表示を変更しない
受入条件	実装とテストの終了点を提供する	2 回目のクリックではリクエストを送信せず、リクエスト終了後に復旧する

ファイルパスやテスト名、インターフェース名、エラーメッセージもアンカーとして機能します。自分が確認した、識別性の高い名前を優先し、具体的に見せるためにすべての関連シンボルを詰め込む必要はありません。通常、一二つのエントリ関数や一つのコンポーネント、スタイル名で、エージェントが検索を始めるには十分です。その他の呼び出し関係は、エージェントにコードから検証させるべきであり、要件作成者が記憶から補完するべきではありません。

誤った座標にも警戒が必要です。関数の名称が変更されていたり、クラス名が複数の場所で再利用されていたり、あるいは要件が実際には別のページを指しているような場合、精密だが間違ったキーワードは、モデルをより速く誤った方向へと導いてしまいます。安全な表現としては、「名称が変更されている可能性があるため、まず検索して確認してください」という一文を追加するか、ページの動作と表示されるテキストの両方を提供して、エージェントに相互検証させるといった方法が挙げられます。

したがって、より実用的な結論は「要件にキーワードを多く詰め込む」ことではなく、人のページに対する印象をリポジトリで检索可能な座標に翻訳し、さらに行動と受け入れ条件によって修正結果を制約することである。前者はコードを探すコストを減らし、後者は誤ったコードを書く余地を減らす。この両方が同時に存在して初めて、コーディングモデルの効率向上はより安定したものとなる。

参考資料

写作附记

元のプロンプト

大規模モデルでコーディングの要件を書く際に、関連する関数名やフロントエンドに関連するスタイル名などのキーワードを含めると、モデルの効率が向上します。LLMの原理を少し説明し、現在の 대규모モデルの原則を解説し、なぜこのようにする方がより優れているのかについて説明します。

ここでは「関数名やスタイル名を覚えればコーディング効率が上がる」という現場の判断をそのまま残しつつ、言語モデルによる生成とコーディングエージェントによる検索の違いを補足しました。Transformer の完全なチュートリアル、モデルの世代間比較、汎化的なプロンプト一覧は省いており、仕組みの説明が本来扱いたいエンジニアリング上の論点から目を逸らさないようにしました。

Hermes の検索が不安定：SearXNG のアウトバウンドを Mihomo に任せる

Sun, 21 Jun 2026 20:33:01 +0800

Hermes を SearXNG に接続すると、表面上は検索の問題を本機内に回収したように見えます：SEARXNG_URL=http://localhost:8888。しかし、国内サーバー（中華圏のサーバー）で実際に詰まりやすいのは Hermes から SearXNG への通信ではなく、SearXNG が独自に Google、DuckDuckGo、Brave、Startpage といった検索ソースへアクセスする部分です。

最終的に、私はリンクを3層に分割しました。Hermes はローカルの SearXNG にのみアクセスし、SearXNG は設定内で HTTP/HTTPS のアウトバウンドリクエストを明示的に Mihomo に委ね、Mihomo が単独でサブスクリプション、ヘルスチェック、ノードの自動選択を担当します。この方法のメリットは「設定がかっこいい」ことではなく、問題発生時に階層ごとに確認できる点です。Hermes がローカル検索にリクエストを送ったか、SearXNG が JSON を返したか、Mihomo に利用可能なノードがあるか、そしてサブスクリプション自体の解析に失敗していないか。

全体のフローは次のとおりです。

Hermes Agent
  -> http://localhost:8888
  -> SearXNG
  -> http://mihomo:7890
  -> Mihomo が利用可能なノードを自動選択
  -> 海外の検索エンジン

ホストマシンでローカルポートのみを公開する：

127.0.0.1:8888  -> SearXNG
127.0.0.1:7897  -> Mihomo 混合プロキシ、デバッグ用
127.0.0.1:9097  -> Mihomo コントローラー、ローカル管理用

SearXNG と Mihomo は同じ Docker ネットワーク内にいるため、SearXNG はホストマシンの 127.0.0.1:7897 にアクセスせず、コンテナ名でアクセスします。

http://mihomo:7890

SearXNG で最も見落とされやすい 2 箇所

Hermes が SearXNG を呼び出す際に JSON をリクエストします。SearXNG 公式 Search API ドキュメントにも明記されている通り、format パラメータを使用できるかどうかは settings.yml の search.formats で有効化されているかどうかに依存します。有効化されていないフォーマットをリクエストすると 403 が返されます。したがって、デフォルトの HTML だけを残しておくわけにはいきません。

search:
  safe_search: 0
  autocomplete: ""
  formats:
    - html
    - json

2つ目はプロキシです。Docker の環境変数やシステムレベルの http_proxy がアプリケーション層で安定的に継承されると過信しないでください。SearXNG のリクエストは独自に行われるため、最も直接的な方法は outgoing.proxies に明示的に記述することです。

outgoing:
  request_timeout: 15.0
  max_request_timeout: 40.0
  extra_proxy_timeout: 10
  proxies:
    "http://": "http://mihomo:7890"
    "https://": "http://mihomo:7890"

SearXNG のデフォルト設定例では all://: という書き方が見られるため、自然に間違った設定項目ではないことが分かります。ただし、私が今回使用した環境では、all://: は期待通りにマッチせず、最終的に落ち着いたのは http:// と https:// を分けて記述する方法でした。記事内でこの境界を保持しているのは、ある一度の実測結果をすべてのバージョンにおける確定的な結論のように書いてしまわないためです。

完全な SearXNG の主要な設定は以下のように圧縮できます。

use_default_settings: true

general:
  instance_name: "Hermes SearXNG"

search:
  safe_search: 0
  autocomplete: ""
  formats:
    - html
    - json

server:
  secret_key: "请替换成随机密钥"
  limiter: false
  image_proxy: true
  bind_address: "0.0.0.0"

valkey:
  url: valkey://valkey:6379/0

outgoing:
  request_timeout: 15.0
  max_request_timeout: 40.0
  extra_proxy_timeout: 10
  proxies:
    "http://": "http://mihomo:7890"
    "https://": "http://mihomo:7890"

engines:
  - name: bing
    disabled: false
    shortcut: bi

  - name: bing news
    disabled: false
    shortcut: bin

  - name: google
    disabled: false
    shortcut: go
    timeout: 8.0

  - name: brave
    disabled: false
    shortcut: br
    timeout: 8.0

  - name: duckduckgo
    disabled: false
    shortcut: ddg
    timeout: 8.0

  - name: startpage
    disabled: false
    shortcut: sp
    timeout: 8.0

  - name: wikipedia
    disabled: false
    shortcut: wp

  - name: arxiv
    disabled: false
    shortcut: arx

  - name: sogou
    disabled: true

  - name: 360search
    disabled: true

ui:
  static_use_hash: true

ここでちょっとした落とし穴があります：SearXNG のデフォルトエンジン設定では、Bing ニュースの name は bing news であり、engine が bing_news です。use_default_settings: true の場合、engines は name でマージおよび上書きされるため、ここでは name: bing news と記述し、name: bing_news とは記述しないでください。

Mihoma がやることはただ1つ：SearXNG に安定した出口を与えること

Mihomo はサーバー全体を引き継ぐ必要はなく、Docker をグローバルにプロキシ経由にする必要もありません。mixed port を 1 つだけ開いて、同じ Docker ネットワーク内の SearXNG がアクセスできるようにします:

mixed-port: 7890
allow-lan: true
bind-address: '*'
mode: rule
log-level: info
ipv6: false

external-controller: 0.0.0.0:9090
secret: "请替换成随机密钥"

profile:
  store-selected: true
  store-fake-ip: true

proxy-providers:
  sub:
    type: http
    url: "你的订阅地址"
    interval: 3600
    path: ./proxy_providers/sub.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000
      lazy: false
      expected-status: 204

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - sub
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: false
    expected-status: 204

  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
    use:
      - sub

rules:
  - MATCH,PROXY

この設定の意味はとても限定的です：購読は 3600 秒ごとに更新され、ノードは 300 秒ごとにヘルスチェックを行い、AUTO は url-test でレイテンシに基づいてノードを選択し、すべてのトラフィックは最終的に PROXY にマッチします。新しい設定が最初に起動されたとき、PROXY リストの最初にあるのは AUTO です。今後、コントロールパネルでノードを手動で切り替えた場合、store-selected: true が選択を保持するため、「デフォルトで AUTO を通る」とは限りなくなります。

また、サブスクリプション形式にも注意が必要です。proxy-providers は provider 形式、あるいは Mihomo が provider として解析できるサブスクリプションに適しています。サービス事業者によっては、完全な Clash 設定を返すものもあれば、ノードリストを返すものもあります。ログに解析失敗のエラーが出た場合、SearXNG を疑うのではなく、まずサービス事業者の管理画面で Clash Meta、Mihomo、Proxy Provider 形式に切り替えてください。

MOD スクリプト

このスクリプトは、SearXNG を /opt/searxng に配置済みのマシンを対象としています。既存の docker-compose.yml と searxng/settings.yml をバックアップし、本機にあらかじめ用意されている metacubex/mihomo イメージをそのまま利用し、SearXNG、Valkey、Mihomo を同じ compose プロジェクトにまとめます。

このスクリプトはMihomoのイメージを自動的にプルしません。SearXNGとValkeyについても、ローカルに対応するイメージがない場合、docker compose upが起動できるかどうかは、ローカルのイメージとネットワーク環境によって異なります。完全にオフラインの環境では、3つのイメージを事前にすべて用意しておいてください。

sudo bash -s <<'EOF'
set -euo pipefail

APP_DIR="/opt/searxng"
COMPOSE_FILE="$APP_DIR/docker-compose.yml"
SETTINGS_FILE="$APP_DIR/searxng/settings.yml"
MIHOMO_DIR="$APP_DIR/mihomo"

if [ ! -f "$COMPOSE_FILE" ]; then
  echo "$COMPOSE_FILE が見つかりません。SearXNG が /opt/searxng にデプロイされているか確認してください"
  exit 1
fi

if [ ! -f "$SETTINGS_FILE" ]; then
  echo "$SETTINGS_FILE が見つかりません。SearXNG settings.yml のパスを確認してください"
  exit 1
fi

if docker image inspect metacubex/mihomo:latest >/dev/null 2>&1; then
  MIHOMO_IMAGE="metacubex/mihomo:latest"
else
  MIHOMO_IMAGE="$(docker images --format '{{.Repository}}:{{.Tag}}' \
    | awk -F: '$1=="metacubex/mihomo" && $2!="<none>" {print; exit}')"
fi

if [ -z "${MIHOMO_IMAGE:-}" ]; then
  echo "利用可能なローカル metacubex/mihomo イメージが検出されませんでした。"
  echo "先に確認してください：docker images | grep -i mihomo"
  exit 1
fi

echo "ローカル Mihomo イメージを検出しました：$MIHOMO_IMAGE"

LOCAL_MIHOMO_IMAGE="searxng-mihomo-local:latest"
docker tag "$MIHOMO_IMAGE" "$LOCAL_MIHOMO_IMAGE"

printf "Clash/Mihomo の購読 URL を入力してください: " > /dev/tty
IFS= read -r -s SUB_URL < /dev/tty
printf "\n" > /dev/tty

if [ -z "$SUB_URL" ]; then
  echo "購読 URL が空のため、終了します。"
  exit 1
fi

mkdir -p "$MIHOMO_DIR/proxy_providers"
chmod 700 "$MIHOMO_DIR"

TS="$(date +%Y%m%d-%H%M%S)"

cp -a "$COMPOSE_FILE" "$COMPOSE_FILE.bak.$TS"
cp -a "$SETTINGS_FILE" "$SETTINGS_FILE.bak.$TS"

echo "バックアップを作成しました："
echo "  $COMPOSE_FILE.bak.$TS"
echo "  $SETTINGS_FILE.bak.$TS"

MIHOMO_SECRET="$(openssl rand -hex 16)"

cat > "$MIHOMO_DIR/config.yaml" <<YAML
mixed-port: 7890
allow-lan: true
bind-address: '*'
mode: rule
log-level: info
ipv6: false

external-controller: 0.0.0.0:9090
secret: "$MIHOMO_SECRET"

profile:
  store-selected: true
  store-fake-ip: true

proxy-providers:
  sub:
    type: http
    url: "$SUB_URL"
    interval: 3600
    path: ./proxy_providers/sub.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000
      lazy: false
      expected-status: 204

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - sub
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: false
    expected-status: 204

  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
    use:
      - sub

rules:
  - MATCH,PROXY
YAML

chmod 600 "$MIHOMO_DIR/config.yaml"

OLD_SECRET="$(grep -E '^[[:space:]]*secret_key:' "$SETTINGS_FILE" | head -n1 | sed -E "s/.*secret_key:[[:space:]]*['\"]?([^'\"]+)['\"]?.*/\1/" || true)"

if [ -z "$OLD_SECRET" ] || [ "$OLD_SECRET" = "secret_key:" ]; then
  OLD_SECRET="$(openssl rand -hex 32)"
fi

cat > "$SETTINGS_FILE" <<YAML
use_default_settings: true

general:
  instance_name: "Hermes SearXNG"

search:
  safe_search: 0
  autocomplete: ""
  formats:
    - html
    - json

server:
  secret_key: "$OLD_SECRET"
  limiter: yml:ro
      - searxng-cache:/var/cache/searxng:rw
    depends_on:
      - valkey
      - mihomo
    networks:
      - searxng-net
    logging:
      driver: json-file
      options:
        max-size: "2m"
        max-file: "3"

  valkey:
    image: docker.io/valkey/valkey:8-alpine
    container_name: searxng-valkey
    restart: unless-stopped
    command: valkey-server --save 30 1 --loglevel warning
    volumes:
      - valkey-data:/data
    networks:
      - searxng-net
    logging:
      driver: json-file
      options:
        max-size: "2m"
        max-file: "3"

  mihomo:
    image: $LOCAL_MIHOMO_IMAGE
    container_name: searxng-mihomo
    restart: unless-stopped
    command: ["-d", "/root/.config/mihomo"]
    ports:
      - "127.0.0.1:7897:7890"
      - "127.0.0.1:9097:9090"
    volumes:
      - ./mihomo:/root/.config/mihomo
    networks:
      - searxng-net
    logging:
      driver: json-file
      options:
        max-size: "2m"
        max-file: "3"

networks:
  searxng-net:

volumes:
  searxng-cache:
  valkey-data:
YAML

cd "$APP_DIR"

if docker compose version >/dev/null 2>&1; then
  DC="docker compose"
elif command -v docker-compose >/dev/null 2>&1; then
  DC="docker-compose"
else
  echo "docker compose / docker-compose が見つかりません"
  exit 1
fi

echo
echo "サービスを開始しています..."
$DC up -d --no-build

echo
echo "サービスの起動を待機しています..."
sleep 12

echo
echo "コンテナーの状態:"
$DC ps

echo
echo "Mihomo の最新ログ:"
$DC logs --tail=80 mihomo || true

echo
echo "Mihomo ローカルプロキシーポート 127.0.0.1:7897 をテストしています:"
curl -I -sS --max-time 25 --proxy http://127.0.0.1:7897 https://www.gstatic.com/generate_204 || true

echo
echo
echo "SearXNG JSON 検索をテストしています:"
curl -sS --max-time 50 "http://127.0.0.1:8888/search?q=openai%20gpt&format=json" \
  | python3 -c 'import sys,json; d=json.load(sys.stdin); print("OK:", len(d.get("results", [])), "results")' || true

echo
echo "完了しました。"
echo "Hermes は引き続き次の設定を使用します: SEARXNG_URL=http://localhost:8888"
echo "SearXNG 送信プロキシー: searxng -> http://mihomo:7890"
echo "Mihomo ローカルデバッグプロキシー: http://127.0.0.1:7897"
echo "Mihomo 制御ポート: http://127.0.0.1:9097"
echo "Mihomo 設定ファイル: $MIHOMO_DIR/config.yaml"
EOF

Hermes は検索エントリのみを保持する

Hermes 側は Mihomo について知る必要はありません。必要なのは、ローカルマシンに SearXNG があるということだけです。

nano ~/.hermes/.env

書き込み：

SEARXNG_URL=http://localhost:8888

次に、~/.hermes/config.yaml で検索バックエンドを指定します：

web:
  search_backend: "searxng"

Hermes 公式の SearXNG skill をインストールしている場合は、引き続き使用できます。

hermes skills install official/research/searxng-search

もし Hermes がユーザーサービスであれば：

systemctl --user restart hermes
systemctl --user status hermes --no-pager

ここにも境界があります：SearXNG は検索を担当し、ウェブページ本文の抽出は担当しません。Hermes のドキュメントでも search backend と extract backend は分けられています。後で Hermes に検索結果ページの本文を読み込ませたい場合は、web.extract_backend に Firecrawl、Tavily、Exa、Parallel などの抽出ソリューションを別途設定する必要があります。

検証：階層をスキップしないこと

まず Mihomo をテストしてください。すぐに Hermes に問い合わせないでください。

curl -I --proxy http://127.0.0.1:7897 https://www.gstatic.com/generate_204

HTTP ステータスを返せる場合、ホストのデバッグプロキシポートが利用可能であることを示します。次に SearXNG の JSON をテストします。

curl -s --max-time 50 \
  "http://127.0.0.1:8888/search?q=openai%20gpt&format=json" \
  | python3 -c 'import sys,json; d=json.load(sys.stdin); print(len(d.get("results", [])), "results")'

ここで 403 が発生した場合は、まず search.formats に json が含まれているか確認してください。ここでタイムアウトが発生したり結果が空の場合は、SearXNG のログを確認してください。

cd /opt/searxng
docker compose logs -f searxng

次に、Hermes で検索をトリガーするリクエストを送信します。

OpenAI GPT の最新情報をインターネットで検索し、ソースリンクを列挙してください。

ログに /search?...format=json が表示されている場合、Hermes がローカルの SearXNG を呼び出していることを示しています。次に Mihomo を確認します。

cd /opt/searxng
docker compose logs -f mihomo

サブスクリプションの更新、provider、health check、AUTO といった情報に注目してください。 Mihomo がサブスクリプションを解析できていなければ、SearXNG をどれだけ正しく設定しても意味がありません。

省いてはいけない境界線いくつか

まず、ポートをパブリックネットワークに公開しないでください。本記事の compose はローカルホストのみにバインドしています：

ports:
  - "127.0.0.1:8888:8080"
  - "127.0.0.1:7897:7890"
  - "127.0.0.1:9097:9090"

「変更しないでください：」のように変更しないでください。

0.0.0.0:8888:8080
0.0.0.0:7897:7890
0.0.0.0:9097:9090

そうでない場合、検索サービス、プロキシポート、および Mihomo のコントロールポートは、いずれもパブリックネットワークから悪用されるリスクがあります。external-controller: 0.0.0.0:9090 はコンテナ内でのリッスンであり、外部からアクセスできるかどうかを実際に決定するのは compose のポートバインディングです。

第二に、Google や Startpage が頻繁にタイムアウトする場合、すぐにリンク構成全体を否定的に見直さないでください。まず Bing、Brave、DuckDuckGo、Wikipedia、arXiv などをそのまま残しておき、Mihomo のサブスクリプションとヘルスチェックが安定してから、验证码やタイムアウトを引き起こしやすいエンジンを有効にしてください。

第三に、スクリプトのロールバックポイントが明確である点です。

cd /opt/searxng

cp docker-compose.yml.bak.あなたのタイムスタンプ docker-compose.yml
cp searxng/settings.yml.bak.あなたのタイムスタンプ searxng/settings.yml

docker compose up -d

私はサーバー全体にグローバルプロキシを適用するよりも、このように役割を分割するアプローチを好みます。グローバルプロキシの問題は影響範囲が広すぎることであり、障害が発生した際に、それがシステム環境、Docker、アプリケーション設定、それともプロキシノード自体が原因なのかを判断するのが難しくなります。Hermes、SearXNG、Mihomo はそれぞれ一つの役割だけを担うため、トラブルシューティング時にはむしろ楽になります。

参考資料

写作附记

この文章では、元の素材の中で最も実用的な部分を保持しています。具体的には、階層化アーキテクチャ、SearXNG JSON、明示的な outgoing proxy、Mihomo の provider とヘルスチェック、Docker Compose、Hermes 設定、検証コマンド、よくある質問、そしてロールバックです。削減したのは繰り返しの説明や、誤解を招きやすい絶対的な表現です。たとえば all://: は汎用的に無効な設定ではなく、この環境では期待どおりにマッチしなかっただけです。

また、設定名を1か所修正しました：SearXNG の Bing ニュースエンジンは name: bing news と記述する必要があります。name: bing_news と書くと、デフォルトのエンジン名と一致しないため、通常のスペルミスよりもリスクが高くなります。

元のプロンプト

ユーザーは、「中国国内サーバーへの Hermes + SearXNG + Mihomo デプロイ：Hermes 検索をプロキシ経由にし、利用可能なノードを自動選択させる」と題した完全なデプロイ資料を提供し、整理・分析して記事に誤りがないことを確認した上で、ブログ執筆スキルを呼び出して記事にまとめるよう求めています。

資料には、背景、目標アーキテクチャ、なぜシステムプロキシを使用しないのか、SearXNG settings.yml、Mihomo config.yaml、Docker Compose、改造スクリプト、Hermes 設定、検証フロー、よくある質問、ロールバック方法、最終的な効果が含まれています。

Loop engineering 的人物を checkpoint に移動する

Sun, 14 Jun 2026 07:35:00 +0800

昨日 MiniMax のオフライン開発者会議に参加して、戻ってきてからずっと頭から離れない言葉がある：loop engineering。

简单说，就是把"提示词—模型输出—反馈"做成一个闭环，让模型自己改 prompt、自己改自己。

筆者の理解では、これは要するに「プロンプト → モデルの出力 → フィードバック」という闭环を作り、モデル自身がプロンプトを改め、自らを改善していく仕組みのことである。

但它真正让人不安的地方在于：当 loop 足够长、反馈足够稠密，模型就开始越过"工具"那条线，开始自己决定要解决的问题、自己判断完成的标准。

しかし本当に不安を感じさせる点は、loop が十分に長く、フィードバックが十分に密になると、モデルが「ツール」という一線を越えてしまい、自らが解決すべき問題を決め、自らが完成の基準を判断し始めることだ。

记得大会上有个工程师打了个比方说：“以前我们养的是宠物，loop engineering 养的是同事。”

最初はエージェントを何ラウンドか回すだけだと思っていた。この理解はあまりにも浅はかだった。本当に行き詰まったのは、AI がコードを書く速度がもはや人間がコードをレビューする速度を大幅に超えてしまっているということで、もし人間の関与が「すべてのステップを確認し、すべてのステップで判断する」レベルにとどまっているなら、最終的に生産性は人間の確認速度によって制限されてしまう。

これは、私が最近 Codex を使って感じたこととつながる。以前その目標に関する記事を書いた時、私がより注目していたのは「完了条件」という事柄だった。何が目標で、どこに境界線があり、何で検証し、いつ完了とみなすのか。

以下は補足です。最初の文「この文章は CC BY-NC-SA 4.0 のライセンスで公開されています。」のような前置きや、結論段落の「この方向が正しいと確信している理由は、まだこれからです。」も訳した方がよろしいですか？必要であれば、追加で翻訳いたします。

大会が終わって改めて振り返ると、goal は loop engineering の中の小さくはあるが非常に重要な一部分に過ぎない。gole は、単一のタスクが人間から繰り返し指示されなくても前に進めるようにするためのものだ。さらに大きな問題は、どのタスクをループに任せるべきか、どのチェックポイントを人間に残すべきか、どの判断を事前にシステムに書き込んでおくべきか、どの責任を AI に押し付けるべきではないのか、ということだ。

今の私が最も契合するシナリオは二つあると感じています。

ひとつはパフォーマンス最適化です。これはもともと指標があり、できれば自動再テストも備えています。エージェントに「インターフェースの P95 をいくつまで下げる」「ファーストビューを何ミリ秒に抑える」「バンドルサイズを何 KB まで削減する」「回帰テストは失敗させてはいけない」と伝えます。エージェントは変更するたびにベンチマーク・プロファイリング・負荷テストを毎回実行し、目標に達しなければボトルネックの探索を続けます。ここで人の価値は毎回どの行を修正したかを確認することではなく、まず受入可能な指標を提示し、そのうえで重要な節目で「この最適化が業務セマンティクスを変えていないか」を判断することにあります。

もう一つは UI のリファクタリングです。その前提として、明確なデザイン案が必要となります。理想的には 1:1 で忠実に再現できることが望ましいです。デザイン案がない場合、人は「このマージンがおかしい」「この色が違和感ある」「このインタラクションは違う」といった瑣末な判断に常に引き戻されてしまいます。デザイン案があれば、AI のループはスクリーンショット、DOM、スタイル、視覚的な差分を中心に収束させることができます。人はすべての CSS 調整につき従う必要はありませんが、最終的な UI には責任を持つべきです。

これら 2 つのシナリオに共通しているのは、検収物が「もっとうまくやってほしい」のような一言ではないということです。パフォーマンス最適化には数値があり、UI リファクタリングにはデザインがあります。ループが機能するのは、AI がより従順だからではなく、タスク自体に比較可能な目標があるからです。

Multica は共同作業ボードのようなものです

会場では、オープンソース界隈の人々からプロジェクトの紹介を受けることもあり、その中で Multica はなかなか興味深いものでした。帰って調べてみたところ、これは新しい单体（单体）的コーディングエージェントではなく、Claude Code、Codex、GitHub Copilot CLI、OpenCode、Gemini、Kimi、Cursor Agent などのツールを同じタスク協調レイヤーに接続するものだと分かりました。

その README では、agent を teammate として記述しています。issue を割り当てられたり、blocker を報告したり、ステータスを更新したり、カンバンやコメント、タスクのライフサイクルに登場したりします。ドキュメントではさらに具体的に、agent は workspace の一級メンバーであり、issue を assign でき、コメントで発言でき、@ でメンションされ、agent を作成するときには背後にある AI coding tool を選択でき、instructions、model、環境変数、CLI 引数、可視性、並行制限を設定できると説明されています。

これにより、「どのモデルを使うか」がプロンプトの中での一時的な選択から、チームコラボレーションにおける役割の設定へと変わります。

この仕組みの最も興味深い点は、「マルチエージェント」という言葉そのものではなく、異なるエージェントに異なる役割を割り当てられることだ。例えば、あるエージェントには安価なモデルを使って反復的な修正を担当させ、別のもっと強力なモデルを使うエージェントにはアーキテクチャの判断を担当させ、さらに別のエージェントにはレビューだけを行わせてコードは変更させない。こうしてSquadのような仕組みを組み合わせ、リーダーエージェントがissueの内容に応じてタスクを適切なメンバーにルーティングするのである。

私は Multica を最初から最後まで完全に動かしたわけではないので、ここでは公開されている資料で照合できるサンプルとして扱うしかない。ただ、この設計の方向性は loop engineering と同じ種類の問題であり、1 つの AI にすべてを任せるのではなく、タスク・役割・モデル・レビュー・状態遷移を同じループの中に組み込むというものである。

企業が実際にAIによるコーディング導入を検討する場合、この違いは非常に重要である。

現在はモデルごとに価格も能力の境界も異なっています。すべてのタスクに最も高額なクローズドソースモデルを使うと、コストを必ずしもちません。すべてのタスクに安いモデルを使うと、手戻り作業やレビュー漏れによってコストが後段に移転する可能性があります。より現実的な方法は階層化することです。リスクが低く、反復的で、境界がはっきりしている作業はまず安いモデルに任せます。重要な変更、アーキテクチャの取捨選択、最終レビューは、より高性能なモデルや人に残します。

クローズドソースの高性能モデルがレビュー担当として使われるのは、私は良い位置取りだと思います。レビューは単に「文法ミスを見つける」だけではなく、要件が歪められていないか、境界を越えていないか、テストが表面しかカバーしていないか、コミットメッセージがリスクを隠していないかを確認する必要があります。このようなタスクにはより高い判断力が求められますが、実装段階ほど呼び出し頻度は高くないかもしれず、コストの計算もより受け入れやすくなります。

人手の関与が少ないことは、人が責任を負わないということではない

円卓会議であった意見に私も共感する点がある：コードはAIが書くが、コードを提出するのは人間である。

この言葉は責任を問うリマインダーのように聞こえるが、実はプロセス設計の原則でもある。AI はコードを書いたり、修正したり、テストを実行したり、PR の説明を生成したり、さらには別のモデルに先にレビューさせることもできる。しかし、最終的にコードをメインブランチにマージする人は、「これは AI が書いたもので、自分には関係ない」とは言えない。

会社で求められるのは、誰がキーボードで文字を打ったかではなく、誰が結果に責任を持つかだ。あなたが提出したということは、今回の変更のビジネスセマンティクス、リスク境界、テストのエビデンス、ロールバック計画に対して責任を持つ意思があるということだ。AI の関与が深いほど、この点を曖昧にしてはならない。

つまり、loop engineering は人をプロセスから完全に排除するものではありません。むしろ、人の配置を再構築するようなものです。

タスク開始前に、人間が目標、境界、受け入れ基準を明確にする。
ループ実行中、システムとエージェントが反復的な試行、テスト、修正、状態同期を自ら処理する。
重要な節目では、人間が証拠、差異、リスクを確認し、AI の出力を逐行で追わない。
コードを提出する際、結果に対する責任は人間が負い、AI を免責の理由にしない。

だからこそ私は、goal、性能指標、デザイン稿、Multica という、一見ばらばらのものを結びつけているのです。これらはすべて、人の判断を前倒しにし、外在化し、構造化しています。人の関与は少なくなりますが、関わるポイントはより重要になります。

この件をうまくやらないと、別の形の非効率になってしまう。AI が多くを生み出すが、人間がレビューしきれず、最終的にチームは「何となく大丈夫そう」という感覚でコードをマージする。問題が起きた後、その責任を AI に押し付ける。それはエンジニアリング化されたとは言えず、単に混乱の生産者を変えただけにすぎない。

本当に追いかける価値のあるループとは、AI にずっと書き続けさせることではなく、書く・直す・テストする・レビューするという各ラウンドを、同じ受入チェックリストに立ち返らせることなのだ。人の仕事は「書いているのを見張る」ことから、「何が良しとされるかを定義し、エビデンスが十分かを確認し、提出物に責任を持つ」ことへと変わる。loop engineering という言葉がずっと私の心に留まっているのは、たぶんこの点なのだ。

参考資料

写作附记

元のプロンプト

$blog-writer 昨日、Minimaxのオフライン開発者会議に参加したのですが、ずっと頭から離れなかったものがあり、それは「loop engineering」です。最近は codex を使ってコード開発をしていますが、goal も使うのが好きで、goal に関する記事を書いたこともあります。2 つのユースケースを発見しましたが、最も契合するのは次の 2 つです。1 つはパフォーマンス最適化で、要求したパフォーマンス指標を直接出力してくれること。もう 1 つは UI リファクタリングで、デザイン案を提供すれば 1:1 で復元してくれることです。冒頭に述べた loop engineering に戻ると、AI 時代のプログラミングでは、AI の生産性は人間を遥かに超えているため、人間のレビュー速度では AI の出力速度にまったく追いつけません。しかし、現在の vibe coding では、多くの意思決定に依然として人間の関与が必要です。人間の関与が増えると、全体的なフローを完全に自動化することが難しくなります。loop engineering の理念は、まさに人間の関与の度合いを下げることにあります。また、オープンソースコミュニティの人々が自らのプロジェクトを宣伝するのにも遭遇しましたが、その中で特に興味深いプロジェクトが一つありました。それは Multica です。関連情報を調べて、簡単に紹介してみてください。彼の設計理念を除いて、最も興味深い点は、与えられたモデルごとに異なるアイデンティティを付与することで、各社の大規模モデルを効果的に活用できることです。結局のところ、現在モデルの価格はさまざまで、ソース非公開のモデルにレビューを行わせるというのは良いアプローチです。会社における AI コードの導入について、ラウンドテーブルのディスカッションで一致していた見解もあります。コードは AI が書きますが、コードを提出するのは人間であり、提出するコードに対して責任を負う必要があります。これはあなたの責任感や、物事に取り組む姿勢を示すものです。AI が書いたものだから、自分とは関係がないとは言えません。

執筆思路の要約

2026-06-13 に MiniMax のオフライン開発者会議に参加するという現場のきっかけを保持し、それをカンファレンスのレポートに膨らませることはしない。
主軸を「人の参与位置がどう変わるか」に収斂させ、loop engineering、goal、Multica、そして会社の責任を逐一説明することはしない。
Multica のパートは公開資料で裏付けられる能力のみを記述し、「クローズドソースのモデルを審査に用いる」という点は著者の判断として明示する。
具体的なモデルの価格、会社の管理制度、コードレビューのフローに関する展開は抑え、記事がワークフローの観察から管理制度の提言に脱線するのを避ける。

Codex がインターフェースを書くのに失敗したあと、ChatGPT に UI を描かせる

Sun, 14 Jun 2026 05:14:22 +0800

最初は単にフロントエンドの整備が後回しになっているだけだと思っていました。strategy_studio のビジネスロジックは着実に前へ進んでおり、行情同期、PostgreSQL、非同期バックテスト、レポートの DB 格納、リサーチワークベンチへと次々と接続されていきましたが、ページは「機能を先に乗せ、 UI は後で清算する」ような状態に見えてきました。Codex に UI を破壊的に再構築させようとしたとき、初めて問題がはっきりと表面化しました。プロンプトをどれだけ強く書いても、界面は古い枠の中でコンポーネントを挪動させているだけのように見えました。

Codex を使ってコードを改善するのは、今回が初めてではありません。バックエンドのロジック、API 連携、テスト修正、レポート生成といったタスクは、ふだんからそのままゴールだけ放り込んで、ファイルを読ませ、コードを修正させ、検証を走らせ、コミットさせています。問題になったのはフロントエンドのリファクタリングです。今回は UI のデザイン案を先に作らず、しかも事前に業務の土台を先に組み上げてしまいました。一度でも旧 UI が存在すると、モデルに見えるのは要件だけではありません。既存のコンポーネント、既存のルーティング、既存のスタイル、そしていくつかの歴史的な慣性までもが見える状態になります。

私の最初の反応もとても普通でした：プロンプトを追加し続ける。破壊的な再構成を許可し、UIとインタラクションのロジックを再設計し、要素を詰め込みすぎず、24インチと32インチのモニターに対応し、コア機能に焦点を絞り、保守的にならない。一つ一つの文は単体で見ればどれも正しいのですが、全部合わせてもまだ何かが足りません：最終的に一体どうあるべきか、ということです。

つまずくのはボタンの色ではない

strategy_studio はボタンが 2、3 個しかない小さなツールではありません。README では、すでに中国語を優先した戦略研究プラットフォームとして位置付けられています。Next.js のフロントエンド、FastAPI の API、PostgreSQL、Worker、Scheduler、Yahoo 同期パイプラインが一緒に動作します。さらにフロントエンドの README は、ページを 1 つのリサーチワークベンチへと集約しています。サンプル準備、実験構成、タスク追跡、結果レビュー、テンプレート管理、そしてレポート詳細と運用・保守のエントリポイントです。

このプロジェクトにおけるフロントエンドの問題は、表面上は「十分に美しくない」というものですが、実際には情報の秩序が定まっていないことにあります。ユーザーはまず相場を見るのか、それともまずバックテストのタスクを見るのか。レポートの詳細画面では、曲線、指標、入力パラメータ、再実行ボタンのうちどれがより重要なのか。トップページはナビゲーションのページなのか、それともワークスペースなのか。大画面では要素を隙間なく敷き詰めるのか、それとも余白を持たせるのか。

これらの判断は文章だけで説明されているため、Codex は「既存ページの中で少し最適化する」という解釈を容易にしてしまいます。コンポーネントの変更、余白の調整、色の変更などを行いますが、それでも古い構造に沿って作業を進めます。破壊的なリファクタリングを許可するだけでは不十分です。なぜなら、破壊的なリファクタリングが解決するのは「コードを大幅に変更できるかどうか」という問題であり、「検証可能なビジュアル目標が存在するかどうか」という問題ではないからです。

日中に一度出かけたのですが、夜になって急に思いつきました。Codex に UI を推測させるのはやめよう。まずは ChatGPT の Web 上で UI デザイン案を描き出して、その画像を Codex に渡して再現させよう。

当時使っていたプロンプトはとても直接的でした：

https://github.com/ttf248/strategy_studio 現在のプロジェクトのフロントエンドコードを分析し、業務ロジックを理解した上で、プロのUIデザイナー・インタラクションデザイナーとして、フロントエンドページを設計し直してください。各ページごとに個別に画像を作成し、24インチ・32インチのディスプレイに対応させ、要素を必要以上に詰め込みすぎず、ユーザーが中核機能に集中して使いやすいようにしてください。

このステップで出た効果は、Codex で形容詞を積み重ね続けるよりもずっと安定している。Codex にはまず可視的な目標が与えられる。ページをどう並べるか、モジュール比率をどう分けるか、ビジュアルセンターの配置、余白のおおよその目安といったものだ。その後の Codex が取り組むタスクは、「審美眼を頼りに再設計する」ことから「図に基づいて業務を理解しコードを復元する」へと変わる。

配色も先に素材にしよう

初稿の図でレイアウトの問題は解決しましたが、デフォルトの配色が依然として通常のバックエンドシステムらしい青と白であり、私の美的感覚にはあまり合っていません。ここで「青と白が好きじゃない、もっと落ち着いた配色にして」とそのまま Codex に投げてしまうと、本質的にはまた推測させることになります。

これが最初の青と白のカラーリングバージョンです。ページ構造を示すことはできていますが、まだ普通の管理画面の雰囲気です。

その後、私はやり方を変えました。まず ChatGPT のウェブ版で配色の方向性について話し合い、ベースカラー、アクセントカラー、カードの階層、そして研究ツールらしい雰囲気について明確に伝えました。その上で、画像モデルにその方向性に従って意図を示してもらいました。これは正式な Figma ではなく、完全なデザインシステムでもありませんが、フロントエンドの再構築で最もずれやすい要素を固定するには十分です。

最終的に手にしたのは「大きく網羅した1枚のホームページ」ではなく、ページごとに分かれたデザイン原稿です。ホームページ、行情研究、バックテスト実験、レポートセンター、レポート詳細、ストラテジーテンプレート、運行保守。 この分割方法が非常に重要 です。strategy_studio のフロントエンドはマーケティングページではなく研究ツールです。ホームページ、行情ページ、レポート詳細ページが担う閲覧タスクはそれぞれ異なるため、すべてを同じカードグリッドに詰め込むことはできません。

図が描けたことで、Codexの役割が明確になります。CodexはゼロからUIデザイナーを務めるのではなく、既存のビジネスロジックを読み、コンポーネントを分解し、レイアウトを調整し、インタラクション状態を揃え、lint/buildを実行し、そして旧フロントエンドを設計稿に近い目標状態にリファクタリングします。

単なる「ウェブ版の方が賢い」ではない

その後、公式資料をもう少し調べてみたが、この件を「異なるチャネルの ChatGPT の知能レベルが異なる」や「Codex を直接使用すると機能が制限される」と解釈できるかどうかを確認したかった。この説明はあまりにも粗い。

OpenAI による Codex CLI の説明は、ローカルのターミナルで動作する coding agent に関するものです。現在のディレクトリにあるコードを読んだり、変更したり、コマンドを実行したりできます。Codex web は、クラウド環境でコードタスクを処理します。OpenAI が Codex agent loop について語るとき、重視しているのは「モデルがすべてを凭空に生み出す」ことではなく、モデルの推論、文脈管理、ツール呼び出し、ファイルの読み書き、コマンド実行が一体となってソフトウェアタスクを構成するという点です。

ChatGPT Images は別のエントリーポイントです。OpenAI Help における Images in ChatGPT の説明によると、ユーザーは会話内で画像を作成および編集したり、モックアップやクリエイティブなビジュアルを作成したりできます。この製品の形態は、納品物がコードではなく画像であるため、ビジュアル目標をまず探索するのに本質的により適しています。

したがって、今回の違いは「どちらがより賢いか」ではなく、タスクの形態が異なるという点にあります。「UIの再設計」を直接 Codex に任せると、コードリポジトリの視点で考えます。どのファイルを修正すべきか、どのコンポーネントを壊してはいけないか、どうすればビルドを通すことができるかを考えます。同じビジネスコンテキストをまず ChatGPT Images に渡すと、抽象的な美的感覚と情報の階層をまず見える目標画像に圧縮します。

これはまた、後になって Codex がむしろ使いやすくなる理由を説明している。設計ドキュメントが Codex を回避したのではなく、設計ドキュメントが Codex にコンテキストと受け入れ基準を補完したのである。公式の Codex prompting ドキュメントも、Codex に関連ファイル、画像、明確な完了基準を提供することを強調している。図がない場合、「要素を密集させすぎないでください」は単なる形容詞に過ぎないが、図があって初めて、それは再現可能なレイアウト制約となる。

よりスムーズなリンク

これ以降は、この種フロントエンドのリファクタリングを3つのパートに分割することにします。

第一段階は、まずビジュアル探索から始めます。ChatGPT の Web 版にリポジトリを読ませ、業務を理解させ、ページごとに画像を生成させ、色使い、密度、大画面対応、ビジュアル階層といった点を中心に繰り返し調整します。この段階で生み出される成果物はコードではなく、目標となる画像です。

第二段階では、目標画像とエンジニアリング上の制約を Codex に渡します。プロンプトは「UI を再設計してください」で止めてはいけません。代わりに、どの画像を目標とするか、どのビジネスロジックを壊してはならないか、どのページが破壊的な再構築を許可されているか、どのテストとビルドが通らなければならないかを明確に記述する必要があります。

第三段落ではエンジニアリングによる復元に入ります。ここで初めて Codex にゴールモードや連続タスクモードを使わせるのに適しています。まずフロントエンドの構造を読み取り、次にページごとに分割して実装します。各ページが完了したら検証を実行し、最後にインタラクションとレスポンシブ対応を一括して確認します。

以前は「プロンプトをもっと強く書くこと」を解決策だと考えがちでした。今振り返ると、フロントエンドのリファクタリングにおいて本当に有効なのは強引さではなく、不足している中間成果物を補うことだと分かります。UI デザインがない場合、破壊的なリファクタリングは単に分解を広げるだけに過ぎません。UI デザインがあって初めて、破壊的なリファクタリングには正しい方向性が生まれます。

このフローは strategy_studio にしか使えないわけではない。すでにビジネスロジックはあるものの、フロントエンドをずっと後付けで継ぎ足してきたような個人プロジェクトなら、どれでも同じ要領で進められる。まず画像モデルに UI のゴールを描かせ、次に Codex にそのゴールをコードに変換させる。各モデルが互いに代替し合うのではなく、それぞれ得意な工程を担当するという形だ。

参考資料

写作附记

元のプロンプト

$blog-writer 日常的に codex を使って ChatGPT モデルを调用しコードを書いているが、オープンソースプロジェクト https://github.com/ttf248/strategy_studio を開発する際、当初は UI モックアップを作成せず、直接ビジネスロジックの開発を行っていた。そのためフロントエンドの UI が計画されておらず、codex 内で直接プロンプトを書いてみた。「破壊的なリファクタリングを許可し、UI とインタラクションロジックを再設計してください」と指示したが、調整してもなかなか良い結果が得られなかった。この時点ではまだ codex の問題を疑っていなかった。昼間外出した夜、ふと閃いた。「Web 版で image2 を呼び出して UI デザイン案をいくつか生成し、それを codex に渡して goal モデルで復元開発してもらえばいいのでは？」と。早速試してみたところ、全く問題なく進められた。使用したプロンプトはこちら: https://github.com/ttf248/strategy_studio プロジェクトのフロントエンドコードを解析し、ビジネスロジックを理解したうえで、プロの UI デザイナー、インタラクションデザイナーとして、フロントエンドページを一式再設計してください。各ページごとに個別に画像を出力し、24 インチと 32 インチのディスプレイに対応させ、要素が密集しすぎないようにして、ユーザーがコア機能に集中しやすくしてください。これでかなり良い結果が得られたが、デフォルトの配色（よくある青と白の組み合わせ）が自分の好みには合わなかった。そこでさらに調整した。まず Web 上で適切な配色をいくつか相談し、image にその配色でデモ画像を生成させる。次にその配色方案と先ほどのプロンプトを組み合わせることで、以下を得ることができた: https://github.com/ttf248/strategy_studio/tree/main/ui。書いた内容が多いので、整理して一篇の記事にまとめてほしい。分からない点があれば、自分でネット検索して調べてください。提供した https://github.com/ttf248/strategy_studio/tree/main/ui には画像がたくさんあるので、適当に 2 枚ほど選んでブログに貼り付けてください。

執筆思路の概要

この書き直しでは、原文の判断と材料をそのまま保ちながら、冒頭部分を「まずは完全な答えを示す」から「フロントエンドのリファクタリングで行き詰まった現場に入る」に変更している。記事は汎用的なモデル評価を省き、今回のワークフローで実際に効果があった転換、つまり視覚的な目標をあまずグラフ化し、それから Codex にエンジニアリングの復元を行わせる、という点だけを記述している。

Codex goalは、完了基準をタスク自体に委ねること

Wed, 27 May 2026 20:11:41 +0800

/goal は、「agent にしばらく動作を続けさせる」という命令だと誤解されやすいです。

これは当然、その表象にすぎません。Codexに目標を与えるだけで、その目標を中心に継続的に推し進めることができ、一度の回答で止まるわけではありません。しかし、真に注目すべき点は「長く稼働できること」ではなく、「何が完了と見なされるか（終了条件）」という概念を一時的なリマインダーからタスク自体の一部へと昇華させた点です。

通常のプロンプト（prompt）は、次に何をすべきかを述べています。それに対し、goal は、エージェントに対して『受入チェックリスト』を渡しているようなものです：目標が何か、境界線（スコープ）はどこか、どの検証項目を通過する必要があるか、そして作業完了のために満たすべき条件とは何か、といった要素を定義しています。

目標は「次へ（または続行）ボタン」ではありません

コマンドの形式（命令形）だけを見ると、/goal は「完了するまで続ける」という概念を強化したようなものに非常に似ています。しかし、このように捉えすぎると、議論が脱線してしまいます。

長期間のタスクで最も厄介な点は、モデル自身が継続を望むかどうかという点ではなく、各ラウンド終了後に、誰が（またはどの仕組みが）継続すべきかを判断する点です。

これらの停点は必ずしも間違っているわけではありませんが、人の受け入れ基準とは異なる場合がよくあります。

目標が解決すべきことは、このことです。すなわち、受入基準（または「判定基準」）を事前に明確に記述し、それによって以降のすべてのラウンドで判断ができるようにすることです。

一般的な目標の例は以下の通りです。

/goal フロントエンドを Next.js に移行する手伝いをしてください。

その問題は短いことではなく、停止条件がないことです。Codexは数ページの移動ができたり、ついでにコンポーネントをリファクタリングしたりでき、さらに追加すべきだと考えるものを継続的に追記し続けることもできます。

より使える書き方は次のようになります。

/goal 注文の管理画面を React Router から Next.js App Router へ移行する。
ログインページ、注文リスト、注文詳細、および購入（または決済）ページの見栄えは旧バージョンと一致させる必要がある。
API契約とデータベーススキーマは変更しないこと。
ページ群が完成するたびに、npm run build、npm test、およびPlaywrightの重要パスを実行すること。
これらの検証すべてが通った場合のみ完了とする。

この追加部分は、単なる余談ではなく、4つのコントロールプレーン（制御面）に関するものです：

要素	作用
目標	最終的にどのような結果であるか
境界	手動では対応できないインターフェース、データ、ファイル、または動作は何か
検証	それが本当に完了したことを証明するための証拠は何か
停止条件	どのような条件を満たした後に停止できるか

「目標」を高くするのは、これら4つのことです。

なぜ長時間実行できるのか

Codex は、一度の回答が引き伸ばされたからではなく、goal の下で継続的に推進することができます。

実際の作業方法は、むしろサイクルに近いです。すなわち、計画し、実行し、ツールの結果を観察し、修正を行い、続けるかどうかを決定する、というプロセスです。ビルド失敗、テスト失敗、スクリーンショットの不一致、リンティングエラー、評価サンプルが通らないといった事象はすべて、タスクを次のサイクルに戻します。

「検証方法」が目標に記載されている場合、エージェントは直感や推測だけで「完了したはずだ」とは述べられません。必ず証拠を得る必要があります。証拠が得られない場合は調査を継続し、証拠に問題がある場合は修正を続けなければなりません。すべての証拠が通過して初めて、「完了」と認める資格があります。

これが、goal が移行（マイグレーション）、リファクタリング、バッチ校正、プロンプト評価、長尺のデバッグといったタスクに適している理由です。これらの共通の特徴は、一度で完結しない点、そして完成に主観的な判断だけでは頼れない点にあります。

逆に、このような目標は非常に危険です：

/goal より高度なプロダクトプランを考案する

境界がなく、検証もされず、かつ停止条件もない。エージェントは長時間動作するかもしれませんが、「長い時間動くこと」が「有用であること」を意味するわけではありません。最低限、何組のソリューションを出力するのか、どのような制約を網羅しているのか、どの基準で絞り込むのか、そしていつ停止するのかを明確に記述する必要があります。

Claude Codeも同じことを処理しています

Claude Code にも /goal があり、公式ドキュメントの説明の方がより直接的です。ユーザーが「完了条件」（completion condition）を設定すると、Claude はその条件が満たされるまでターンをまたいで継続的に作業します。

『Claude Code』のドキュメントには、各ラウンド終了時に完了条件が満たされているかを確認し、もし条件を満たしていない場合は次のラウンドへ進むと記されています。この点が非常に重要であるのは、「継続」という判断をモデル自身の主観的な結論付けのプロセスから切り離し、外部の追加的な条件判定（ロジック）としているためです。

両社の具体的な実装詳細が無理に同一である必要はありませんが、方向性は一致しています。すなわち、エージェントは「次の指令を実行する」という段階から、「検証可能な目標を中心に継続的に推進していく」という段階へと移行し始めているということです。

簡単に分類すると：

この表において、goal の役割は非常に明確です。それはフックの代替ではなく、記憶（メモリ）の代替でもありません。それが管理しているのは、「今回のタスクをどの程度まで達成すれば完了とみなせるか」という点です。

Good goals should be written like acceptance criteria

今から、一つのゴールを四行に分けて記述します。

目標：最終的にどのようなユーザーに見える結果が出なければならないか。
範囲：どのファイル、インターフェース、データ、視覚的要素、または動作を変更してはならないか。
検証：どのようなコマンド、テスト、スクリーンショット、評価、または手動チェックを証拠として使用するか。
停止条件：すべてが満たされたときに停止するもの。どの権限、事実、製品判断に遭遇したときに一時停止するか。

これは普通のプロンプトとは大きく違います。

通常のプロンプトは次のアクション（行動）のようなものであり、ゴール（目標）は完成の基準（クオリティ）のようなものです。それは人間をプロセスから排除するのではなく、人間の判断を事前に組み込むものになります。あなたは、「これはまだ完了ではない」と都度指摘する必要がなくなり、「何をもって完了とするか」という条件を最初から守らなければならない制約として記述できるようになるのです。

ですから、エージェントに自主的に動かしてもらいたいほど、目標はより狭く（限定的に）設定する必要があります。

プロセスへの注視を減らそうとすればするほど、検証（バリデーション）はより具体的・現実的に記述する必要があります。

逸脱（暴走）を最も避けたいからこそ、境界線を明確に定義することが重要だ。

「goal」が真に注目すべき点は、ここです。単にコマンドが増えることでも、どれだけ長く動作するかという点でもありません。むしろ、ターミナルエージェントが、「完了の判断を下す主体は誰か」という問題を表舞台に引き上げてきた点にあります。

参考文献

執筆に関する補足

元のプロンプト

$blog-writer codexが新しくリリースしたgoalコマンドの詳細について、動作原理は何か、なぜ長時間の処理が継続するのか、そして公式が提供する具体的な事例を解説してください。Claude Codeに同様の命名規則はあるか？また、ついでに、最近リリースの2つのターミナルで、便利でおすすめな機能をいくつかピックアップして表としてまとめてください。

執筆のアイデア概要

原文の主要な判断点を維持する：goal の核となるのは、コマンド名ではなく、完了条件である。
元のプロンプトで要求されていた Claude Code の比較とターミナル機能の表を補完する。
「公式ドキュメントの再述」は排除し、実用的な goal の記述方法に重点を置く。

ChatGPTが公開された後、NVIDIAのデータセンター向けGPUはどのように進化するでしょうか？

Fri, 15 May 2026 19:58:51 +0800

まず、時期を明確にしましょう。ChatGPTの公開研究プレビュー版は、2023年ではなく、2022年11月30日にリリースされました。[1]

この時期以降、NVIDIAのデータセンターGPUのメインラインは非常に明確です。Ampereが終息し、Hopperに引き継がれ、Hopperは大容量メモリを刷新し、そしてBlackwellが重心を「単一カードでの高密度計算能力」から、「推論スループット、消費電力、システム全体レベルの相互接続性」へと移していくという流れです。対照的に、中国向け特別仕様ラインは別の物語があります。A800、H800、H20といったものは、本質的には米国の輸出規制の制約の下で作られた

本稿では、2本の線のみを統計しています。

グローバルデータセンター向けのトレーニング／推論メインライン：比較基準としてA100、H100、H200、B200、B300。
中国向け特別供給ライン：A800、H800、H20。

L4、L40、L40S、L2といったものは本文に組み込んでいません。それらが重要でないわけではなく、むしろこれらはビデオ推論、一般推論、グラフィックス、仮想化という用途ラインがメインであり、A100/H100/H200/B200のような大規模モデルトレーニングの主軸と混ざってしまうと、価格や性能の指標が混乱してしまうからです。

まずメインラインを見る

結論から述べます。2022年11月30日以降の発表ペースで見ると、H100が生成AI爆発初期の真の起点となり、H200は「メモリ不足」を補うための刷新的なカードであり、B200こそが真の意味でのプラットフォームレベルの世代交代であり、B300はBlackwellを推論（Inference）および思考（Reasoning）の時代へとさらに押し進めたと言えます。

モデル名	リリース日	アーキテクチャ	メモリ容量	メモリ帯域幅	インターコネクト	公式性能指標
A100 80GB	2020-11、対照ベースラインとして	Ampere	80GB HBM2e	2.039 TB/s	NVLink 600 GB/s	BF16/FP16 Tensor Core 312 TFLOPS，INT8 624 TOPS [2]
H100 SXM	2022-03-22	Hopper	80GB HBM3	3.35 TB/s	NVLink 900 GB/s	BF16/FP16 1,979 TFLOPS，FP8 3,958 TFLOPS；DGX H100 シングルシステムで 32 PFLOPS FP8、DGX A100 から 6 倍向上 [3][4]
H200 SXM	2023-11-13	Hopper 改良版	141GB HBM3e	4.8 TB/s	NVLink 900 GB/s	公式が強調しているのはコア演算能力の倍増ではなく、Llama2 70B 推論で 1.9 倍、GPT-3 175B 推論で 1.6 倍の向上；H100 に対する相対的なメリットはより大

ここで最も誤解しやすい点は、H200が「演算能力を暴力的に倍にしたカード」ではないということです。むしろHopper世代のための補習（キャッチアップ）のようなものです。大規模モデルの訓練と推論が超長コンテキスト、巨大なKVキャッシュ、MoE、そしてより大きなバッチサイズという段階に入ると、ボトルネックはもはや単純なBF16のピーク性能ではなく、VRAM容量とVRAM帯域幅になるからです。H200はこの弱点を補完しました。

真の世代的な飛躍はBlackwellにあります。Blackwellが売っているのは単なる単体のカードではなく、一連のプラットフォーム能力：新しい精度、インターコネクト、システム全体レベルの帯域幅、推論コスト、消費電力効率、ラックスケールでの組織方式といったもの全般です。これが、多くの資料がB200について語る際に、単体カードの指標がH100ほど一目で理解しにくい理由であり、なぜならNVIDIAのナラティブ（物語上の焦点）が、「この

中国限定ラインを再確認

中国専用ラインは個別に検討する必要があります。なぜなら、その目的が世界のフラッグシップ製品を打ち破ることではなく、輸出規制のレッドラインを下回りながら、商用利用可能性を可能な限り保持することにあるからです。

このラインで最も覚えておくべき一文は、「A800とH800は『相互接続を減らす』ものであり、H20は『計算能力すらも抑え込まなければならない』ものである」ということです。

そのため、誰かが単にVRAMの数字だけを見て、「H20はH800より新しいから、もっと高性能だ」と判断するのは誤りです。H20の96GB HBM3と4.0 TB/sの帯域幅は悪くありませんが、それが登場する前提条件は、より厳しい輸出規制を満たすことです。その商業的な目的は、まず「売れること」、次に「可能な限り使いこなせること」なのです。

前世代と比較して、具体的にどれだけアップグレードされたのか

計算方法から説明します：

\[
\text{アップグレード率}=\frac{\text{次世代指標}-\text{前世代指標}}{\text{前世代指標}}
\]

ただし、この数式は定義（スコープ）が統一された指標にのみ適しています。メモリ（VRAM）、メモリ帯域幅、NVLinkの帯域幅は直接計算が可能です。一方で、プラットフォームレベルの推論コストやシステム全体の処理能力（スループット）といった要素は、シングルカードのTFLOPSのような単一基準には無理に当てはめることはできません。

世界の主要動向

読み進めていくと、ある法則があることに気がつきます。

H100は、単一カードのテンソル演算能力を飛躍的に引き上げた世代です。
H200は、VRAM（ビデオメモリ）を補強した世代です。
B200は、「トレーニング用カード」を「AIファクトリーのインフラストラクチャ」へと変貌させた世代です。
B300は、Blackwellをより明確に推論および大規模な推論の領域へ押し進めた世代です。

中国特別供給ライン

世代	直感的印象はアップグレードに見えるが、実際には分けて考える必要がある	私の考察
A800 -> H800	ローカルHBM帯域幅だけを見ると、A100からH100レベルまでは、約+64%の世代的な進歩と理解できる	しかし、根幹となる制約は依然としてインターコネクト

それゆえに、「各世代でどれだけ総合的に向上するか」という形で記述するのは、中国の特注ラインには適さないのです。このラインは元来コンプライアンス上の制約を伴っており、設計目標が技術的な最適さではなく、ルールによる制約の下での商業的な実現可能性にあるからです。

販売価格は一体どれくらい上がったのか

この部分は誤った情報が書き込まれやすい箇所です。NVIDIAはデータセンターGPUの単体MSRPをほとんど公開していないため、一般的に利用できる情報は以下の通りです：

DGXシステムの価格、またはサードパーティによるシステムの実売価格（提示価格）。
中国向け特別仕様カードのチャネルからの見積もり価格。
メディア、証券会社、またはサプライチェーンからの情報。

そのため、ここでは「公開で追跡可能な価格サンプル」のみを提供し、一見すると完璧だが実際には算出基準が混乱した公式の価格表を偽造することはしません。

デバイス	公開価格サンプル	前世代との比較の解釈
DGX H100	2022-03-22 发布時官方起售价 1

したがって、「全体の販売価格はどの程度上がったのか」という点で、2つの結論をご報告します。

第一に、世界のフラッグシップ主力製品は確かに上昇しており、その上昇幅もさほど小さいものではありません。公開で比較可能なサンプルを見る限り、DGX B200は、同時期にリストされているDGX H100と比較して、およそ40％から50％高価になっています。[19]

第二に、中国の特別供給ラインは一律に価格が上昇しているわけではなく、「後から出るカードの方が安価」という状況が発生する可能性があります。H20の8枚カードサーバーの公開見積もりは、H800の8枚カードサーバーよりも約30%低い水準ですが、これは良心の問題ではなく、性能能力がさらに圧縮されたためです。[17]

まとめ

ChatGPTが公開された以降のNVIDIAデータセンター用GPUの変化を一言にまとめると、私の判断は〜です。

H100 は生成AIが爆発した時点でのスタートの引き金であり、H200 はメモリ志向の延命措置です。B200 こそが AI ファクトリー時代における真のプラットフォーム世代交代であり、B300 は推論（reasoning）時代に向けて明確に道筋をつけ始めています。中国向け特別供給ラインは全く別のロジックに基づいています。それはフラッグシップを追いかけるのではなく、ルールの隙間で可能な限り利用可能性を維持することを目指しているのです。

この2つの要素は混同しないでください。混ぜて見ると、「新しいカードのVRAMが大きいから、世代がより優れている」「価格が低いから、コストパフォーマンスが高い」といった、大きな差はないものの、方向性自体を間違えた結論を導き出しやすいです。

参考資料

執筆注記

元のプロンプト

ChatGPTのリリース以降、Nvidiaが発表したGPUモデルとそれに対応する性能パラメーターをまとめてください。前世代と比較してどれくらいアップグレードされたか、また全体的な価格はどの程度上昇しているかを知りたいです。データセンターで使用されるGPUが必要で、中国向けの特別版も含めてください。

ライティング（執筆）の構成案要約

拡張ブレーンストーミング

| 方向 | 正文への採用可否 | 対応理由 | | — |

AIがコードを書き始めたけど、新人は何でスキルアップすればいいの？

Mon, 27 Apr 2026 23:18:36 +0800

ここ数ヶ月、ClaudeやCodexといったツールを使ってコードを書いている中で、最も強く感じているのは、「プログラマーが不要になる」ということではなくて、以前は新人に練習課題として出していたような作業まで、AIがすでに叩き台（ドラフト）を生成してくれることだ。

スキャフォールドの作成、いくつかのテストの追加、ついでに小さな機能を修正する…という操作を続けていくと、その速度があまりにも速くて、なんとも言えない「意難平」な気分になる。

私のような卒業から10年が経過した人間にとって、正直なところ、これは主に効率化の問題です。なぜなら、どこを信じてよいか、どこを信用してはいけないか、そして表面上は動作しているように見えても、実は後に罠（落とし穴）がある場所などを概ね把握しているからです。しかし、新卒者にとっては、この問題はそれほど簡単ではありません。AIは単に数時間の肉体労働を奪ってくるだけでなく、「初心者がどうやって無知から熟練へとなるか」という確立された道筋そのものを圧縮してしまっているようなものです。これが私が改めて書きたいと考えている点でもあります。

本当に淘汰されたのは、プログラマーではなく、「スマホの技能大会（モバイルスキル）」だった

以前のチームには、技術的な難易度は高くないものの、新人にとって非常に適した種類のタスクが常にあります。例えば、ページ修正、インターフェース（API）連携、CRUD機能の実装、エッジケースのバグ修正、ログを追跡しながら一つずつデバッグを行うといった作業です。タスク自体は大規模ではありませんが、「文法を書ける」だけの段階の人を、「実際のシステム全体がどう動いているか」を理解できるレベルまで育て上げることができます。

現在、このような仕事はAIに最も早く飲み込まれる傾向があります。

米国労働統計局（BLS）が2025年版の職業展望において、非常に興味深い対照的な指摘をしています。

一方では、ソフトウェア開発やテストといった職種は今後10年間も成長し続けると述べる一方で、「コンピュータープログラマー」という、より「コードの記述・実行」に重点を置いた職種については減少傾向にあるとし、多くの定型的な（反復的な）プログラミング作業が継続的に自動化されるだろうと明確に記しています。

この変化は極めて重要です。

ソフトウェア業界から人がいなくなるという意味ではありません。というのも、「ただタスクを受けてコードを書くだけ」という価値が、ますます薄くなっているからです。企業は当然、コスト計算をします。AIにまずドラフトを作成させ、その後経験豊富な人材に仕上げ（磨き上げ）てもらえるのであれば、なぜこれまでのように多くのジュニアポジションを配置して時間をかけて育成する必要があるのでしょうか。

だからこそ怖いのは、必ずしも人員削減ではないのかもしれない。むしろ、人が補充されなくなることだ。道（チャンス）自体はまだそこにあるものの、幅が狭くなってしまったということだ。

なぜベテランほどAIの恩恵を受けやすいのか

この件、ちょっと矛盾している気がしますね。一見すると、AIが生成したコードでも、新卒のエンジニアより優れているとは限りません。しかし、真にAIを使いこなせるプロは、多くの場合、何らかの失敗（落とし穴）を経験してきたベテランなのです。

理由は複雑ではありません。

まず、ベテランは、「動くように見える」ことと「実際に本番環境で機能する」ことは別物だと知っています。Anthropicは、2026年1月のEconomic Indexにおいて、ソフトウェア開発を個別に分析した結果、このようなリクエストは高度に体系化されているものの、タスク成功率は約61%に留まることが判明しました。また、ほとんどのシナリオでは、一度AIに任せて終わりではなく、往復での反復的なやり取りが必要

第二に、ベテランには「コードのセンス」というものがある。この言葉は少し玄妙だが、非常に実効性がある。インターフェースをこう分割すべきか、例外処理をこのように飲み込むべきか、テストが単にCIをごまかすだけではないか、リファクタリングによって来週分の落とし穴まで先に埋めてしまうのではないか。AIも今では間違いを犯すのだが、その多くは構文ミスではなく、方向性の誤りや抽象化の誤り、境界の誤りだ。古法でのプログラミングを経験したことがない人は、正直なところ、こうした誤りを識別するのがより難しい。

つまり、AI時代において最も価値があるのは、タイピングの速さではなく、判断力なのです。

新人が道がないのではなく、古い道が存在しなくなっただけのことだ

新しい分野に参入した人が、完全に機会を失うとは思えません。世界経済フォーラム（WEF）は、2025年1月のレポートにおいても、ソフトウェアおよびアプリケーション開発者を成長が著しい職種として位置づけています。また、米国労働統計局のソフトウェア開発職に関する長期的な展望も依然として増加傾向にあります。これは、需要が突然消滅したわけではないことを示しています。

しかし、参入方法が確実に変わった。

以前の標準的なキャリアパスは、まず実務を通じて苦労を重ね、書きながら学習し、経験を積んで感覚（フィーリング）を磨き出すというものでした。しかし現代では、企業はあなたが入社したらすぐに2つのことを期待する傾向がより強くなっています。

まず、AIを「答え」としてではなく、「ツール（道具）」として扱うことが大切です。問題点を明確に言語化したり、要件を細かく分解したりして、まずは利用できる草稿を出してもらうといった対応ができる必要があります。

もう一つの点は、それ（コードなど）をレビューできる能力です。単に「これは間違っている」と言うだけでなく、どこが間違いなのか、なぜ間違いなのか、そしてプロジェクトのコンテキストに合わせてどのように修正すべきかを理解していることです。

これは困りましたね。「コードレビューができる能力」というのは、本来数年間の仕事経験を積んで身につくものなのに、今は練習する機会が減っているのに、かえって新人にこの能力を早く持っていることを求められている。どう言えばいいか、まるでゲームの初心者村が取り壊されたのに、ボスは目の前で待っているような状況です。

今後の展望

私の現在の判断は比較的単純です。

AI は熟練者の生産性を向上させ続けると同時に、初級職における最も標準化しやすく、細分化しやすい業務部分を圧縮し続けるでしょう。この二つの事象は矛盾することなく、同時に発生する可能性が高いです。ILO は 2025 年 5 月の報告書で非常に抑制的な見解を示しており、生成AIは単に仕事全体を一気に消滅させるというよりは、タスク構造そのものを変えるものだとしています。問題なのは、タスク構造が変わると、最も先に廃止されがちなのが、本来新人育成のために設計されていた低リスクの業務であるということです。

したがって、次に希少価値が高まるのは、「最もコードが書ける人」ではなく、基本的な能力を持ち、AIを使いこなすことができ、さらにビジネスと品質に対して責任を持てる人物です。

経験者にとって、これはより鋭いシャベルを一つ加えたようなものであり、疲れはするものの、効率が格段に上がりました。しかし、新人にとっての問題は、AIを使えるかどうかではなく、最初からAIに頼って書いた場合、いつが質の高い文章で、いつが本気でデタラメ（嘘）を書いているのかを誰が教えてくれるのかという点なのです。

この答えは、今のところ学校でもAIでも提供できません。結局は自分で補完していく必要性が高いでしょう。「門が閉まったわけではないけれど、より入るのが難しくなってきましたね。」

参考資料

作成上の注記

元のプロンプト

AIプログラミングに関するいくつかの考察です。新卒の学生は、コーディング能力がClaudeやCodexには及ばないのは間違いないでしょう。ベテランにとってはAIが効率性を高めてくれますが、同時にAIによって企業側がジュニアプログラマーのポジションを大幅に削減するという事態も生じました。私は卒業から十年が経ち、初心者から熟練者へと成長する道のりを経験してきました。これから新しく業界に入ってくる人たちはどうなっていくのでしょうか？私たち年配の世代は「古き良き」コーディング手法を経験してきたため、簡単に言えば、現在の段階にあるAIが書いたコードが良いものなのか悪いものなのかを見分けることができます。畢竟（ひんこう）今のAIはまだ間違いをするからです。

執筆の考え方（または論旨）の要約

主張の軸を「AIが圧縮しているのは、新参者の練習機会であり、ソフトウェア業界全体ではない」とする点に置く。
前半部では、ベテラン層がなぜAIの恩恵をより大きく受けるのかを述べた後、それが

聯通に引っ越してから、アメリカのノードが急にそれほど良くなくなった。

Thu, 16 Apr 2026 01:56:14 +0800

最近引っ越したため、自宅のブロードバンドを電信から聯通に変更しました。普段ドラマを見たりゲームをしたりする分には、特に何も感じませんが、先日資料をダウンロードしようとして、癖でアメリカノードに切り替えたところ、どうやっても速度が上がらず、私は少し呆然としました。

この件は後になって理解できました。以前は、アメリカのデータセンターの帯域幅が十分与えられているから、アメリカのノードは元々より強力だとずっと思っていました。今見ると、その認識は半分しか正しくありません。アメリカのサーバーのリソースが豊富であることは一つの側面ですが、国内でどの回線を使うか、国際出口をどう通すか、戻りの経路でより良いバックボーンを利用できているか、というのがもう一つの側面です。以前は中国電信を使っていたので露呈しなかった問題が、ユニコムに替わってからは全て明らかになりました。

平常では本当に見つけにくい

このような差異は、普段は気づかれやすいものです。

ドラマを見る場合は動画プラットフォーム独自のスケジューリングが使われることが多く、クロスボーダー帯域を常に最大に引き出す必要はありません。ゲームの場合は遅延の揺らぎやノードの安定性がより重要で、実際に大容量ファイルのダウンロードや高帯域幅での継続的な実行になると、回線が適切かどうかが一目瞭然になります。

そのため、今となってはダウンロード速度こそが最も正直な測定だと感じています。普段はすべて正常だと感じるかもしれませんが、それはこの道が本当に広いということではなく、単に限界まで走らせていないだけなのかもしれません。

かつてアメリカのノードはフル稼働できたので、アメリカのデータセンターだけが優れているわけではない

中国电信が独自に公開している資料によると、ChinaNet は同社のメインの広域網であり、CN2 (AS4809) は低遅延と高品質を強調した次世代のグローバルバックボーンネットワークで、国際的な品質をより重視するビジネス向けです。この件は多くの人が聞いたことがあり、普段空港の業者はこれをセールスポイントとしてよく使います。

そのため、以前は電気通信のブロードバンドを利用していて、アメリカノードに切り替えるだけでダウンロード速度を上げることができましたが、今振り返ると、「アメリカが生まれつき速い」というよりは、「アメリカのデータセンターリソース＋ノードの上流回線＋電気通信側の国際ルーティング」がたまたま重なっただけだと思います。回線が電気通信にとって好都合な方向に当たると、体感は本当に良くなりますね。

率直に言って、以前のスピードは、ノード全体が強いというよりは、私がちょうど有利な側に立っていただけだと思います。

中国聯通は国際回線がないわけではないが、以前と同じルートとは限らない

しかし、この件を単に「中国電信網への依存」と理解することはできません。

中国聯通独自の国際ネットワークもそれなりに大きい。联通の国際公式サイトには明確に記載されており、そのバックボーン網である AS4837 は世界中に 400以上の PoP を持ち、さらに品質の高いキャパシティを担う AS9929 も持っている。カバレッジで見ると、シンガポール、台湾、アメリカといった地点には自前で展開している。

しかし、問題はここにあります。「国際回線がある」ことと、「今購入したプロキシノードがたまたまこのキャリアにフレンドリーである」ことは、別物なのです。

家庭のブロードバンドユーザーが真に感じるのは、キャリアが海外リソースを持っているかどうかだけではなく、以下の点も含まれます。

お客様のローカルキャリアはどちらですか
プロキシサービスプロバイダーが購入するアップストリームはどちらの帰り回線に傾いていますか
ノードの往路と復路は同じ種類の最適化ですか
ピーク時に混雑はありますか
このリンクは中国电信寄りですか、それともユニコムや移動体通信寄りですか

多くの米国のノードについて、以前は中国電信（China Telecom）を使っていた時は回線が満杯になるほど使えたのですが、聯通（China Unicom）に替えてからは駄目になりました。私はこれを「これらのノードの回線構成自体が、元々中国電信寄りのものなのだ」と理解する方がしっくりきます。以前はそう思わなかったのは、自分自身が中国電信を使っていたからかもしれません。

なぜシンガポールと台湾が逆に順調なのか

これもかなり面白いですね。

聯通に乗り換えた後、アメリカのノードはダメになりましたが、シンガポールと台湾はかなり快適になりました。この変化の方が、「アメリカのノードの速度低下」よりも問題をよく示しています。

私の理解では、アジア方面は元々より近く、経路が短く、地域間の相互接続も密です。联通（China Unicom）自身がシンガポールと台湾の両方にネットワークリソースとPoPを持っているため、このような状況で代理サービスプロバイダーがアジアのノード上でよりスムーズな地域パスを提供すれば、ダウンロード速度は自然と出しやすくなります。

これはシンガポールや台湾のデータセンターがアメリカより優れていることを意味するわけでもなく、すべてのブロードバンド接続でアジアノードを選ぶべきだという意味でもありません。むしろ、現在お使いのブロードバンド回線とこれらのリージョンノードとの相性が高いということのようです。

どう言えばいいか、ノードの強さは、単にデータセンターの場所だけでは決まらない。結局は、自宅からの道のりがあなたを認めてくれるかどうかを見なす必要があるんだよ。

この件で、私のこれまでの認識が修正されました

私の以前の考えはかなり単純でした。アメリカのデータセンターは大きく、ブロードバンドのリソースが豊富なので、資料をダウンロードする際はアメリカのノードを選ぶのが基本で、間違えることはないと考えていました。

今のところ、この判断はあまりに大雑把です。

より正確な言い方としては、

アメリカのノードが満杯かどうかは、単にアメリカのデータセンターだけを見ているわけではなく、あなたの家のブロードバンドがどのバックボーンネットワークに接続されているかにも左右されます。

電信ユーザーが快適に使える回線でも、ユニコムに変わると必ずしもそうとはいかない。逆にユニコムの下の方がスムーズなシンガポールや台湾も、「アジアのノードが急に強くなった」わけではなく、単に回線がようやくしっくりきただけだ。

そのため、今後プロキシやノードを選ぶ際は、アメリカに固執することは少なくなるでしょう。まず自分の回線がどのようなものか、次にサービス提供者がどの回線に重点を置いているかを見る方が、「データセンターがアメリカにあるかアジアにあるか」よりも重要になります。

あー、こういう差は、普段ドラマを見たりゲームをしたりしているだけではなかなか気づきにくいですね。実際に大きなファイルを扱うとなると、回線（帯域）の実力が一気に表れちゃいますね。

参考資料

作成上の注記

元のプロンプト

プロンプト：中国本土で代理ソフトウェアを使い、科学的にインターネットに接続する方法を試したところ、中国電信と聯通のブロードバンドの違いに気づきました。普段ドラマを見たりゲームをしたりするだけでは、その違いはほとんど分かりません。資料をダウンロードすることがたまにあるのですが、アメリカのノードを選ぶことが多く、そちらのノードだとダウンロード速度がほぼ最大まで出ます。これは以前の認識とも一致しており、アメリカのデータセンターのサーバーは十分なブロードバンドリソースを提供していると感じていました。最近引っ越しをして聯通の回線に切り替えたところ問題に気づきました。アメリカのノードではダウンロード速度が出なくなりました。シンガポールや台湾に切り替えるとかなり良くなりました。これは中国のブロードバンドのバックボーンネットワーク、つまりCN2高速バックボーンネットワークがすべて電信のものなので、聯通は電信の回線を借りているという関係に関係しているのだと思います。

ライティングのアイデア概要

「引っ越しで回線を変えて初めて違いに気づいた」というリアルなトリガーポイントは維持し、記事を単なるネットワークの科学解説にしない。
コアとなる判断基準は「ノードの速さだけでなく、国内回線と国際ルーティングも見る必要がある」という点を維持する。
CN2、中国光通信（Unicom）の国際バックボーン、および海外PoPについて補足的な検証を行い、「中国光通信は電信網に完全に依存している」という記述をより正確な表現に修正する。
シンガポールや台湾が速い点については、「地域パスが短い」「回線マッチング度が高い」といった形で説明し、絶対的な法則として断定しない。
構成としては、まず体感（実体験）から書き始め、次にその理由を解説し、最後に「今後どのようにノードを選ぶべきか」という結論に落とし込む。

アーキテクチャが変わったので、HermesとOpenClawのトークンの消費方法は違います。

Thu, 16 Apr 2026 01:13:53 +0800

昨日書いた《HermesをOpenClawの代替品と見なすのは危険かもしれない》を書き終えた後、私は周りのドキュメントを巡回しました。巡るほど、この二つのものの違いを見るには、機能だけを見ているだけでは不十分で、トークンがどのように消費されるかを見る方が、より直接的だと感じました。

私の判断は、まずここに置きます。

OpenClaw はデフォルトで長期的にオンラインのワークベンチのようなものであり、多くのアイデンティティ、ルール、ワークスペースファイル、メッセージ面制約などが自然に各対話フローに引き継がれるため、ベースラインは通常重くなります。一方、Hermes は明らかに抑制的で、多くのコンテキストはオンデマンドで発見され、オンデマンドで注入されます。システムプロンプトも意図的に安定したプレフィックスを維持しており、デフォルトではトークンを抑えやすいです。

もちろん、これはHermesが必ずしもより節約できるという意味ではありません。memory provider、skills、sub-agent、長いツール出力をすべて有効にすると、同じように大量のトークンを消費します。しかし、率直に言って、これら2つのアーキテクチャは、初日から異なる方法でトークンを消費しています。

OpenClaw はなぜデフォルトでより重いのか

OpenClaw の設計ロジックは、元々「軽いエージェントを一つ出して、ちょっとおしゃべりする」というものではなく、「まず長期的に存在するエージェントのワークステーションを構築する」というものです。この点は公式の workspace ドキュメントに非常に明確に書かれています。

AGENTS.md、SOUL.md、USER.md はセッションごとにロードされます。IDENTITY.md、TOOLS.md、HEARTBEAT.md、BOOT.md、MEMORY.md といったファイルも、同じワークスペース内で巡回します。ドキュメントはさらには、HEARTBEAT.md は非常に短く保つよう注意喚起し、トークン消費を避けるように促しています。このような注意喚起自体が、OpenClaw が自身のデフォルトのコンテキストが比較的厚いことを明確に示しています。

しかし、一つ明確にしておくべき点があります。OpenClaw はすべてを無条件で全文常駐させるわけではありません。公式のトークンドキュメントには、skills をシステムプロンプトに組み込む場合、デフォルトでは単なるメタデータであり、具体的な説明は必要に応じて read する必要があると明記されています。したがって、問題は「節約ができない」ことではなく、「デフォルトで持っていく土台自体が元々大きい」ということです。

この件は実は理解しにくいものではありません。OpenClaw が解決しようとしているのは、「長期的なオンライン状態」と「複数のメッセージ面での存在感」です。

Telegram、Discord、Slack、WhatsAppといった複数の場所に同時に存在し、アイデンティティ、ルーティング、境界線、委任（delegate）を伴いながら活動させる場合、多くのルールは後から付け足すものであってはなりません。それはまず自分自身が何者であるか、どのように話すべきか、誰に向き合っているのか、現在のワークスペースの制約は何か、スキルをどこから取得するのか、どの記憶を持ち運ぶべきで、どの記憶を持ち運んではいけないのかを知る必要があります。

そのため、OpenClaw のトークン消費は、より固定のオーバーヘッドが大きい傾向があります。

メッセージを送信するたびに、単にモデルに一文を話しかけているのではなく、すでに完成された「アシスタント環境」全体を呼び出しています。この環境は使いやすいのですが、その代償としてベースとなるプロンプトがより厚くなり、たとえ今回のターンで直接使われなくても、多くのコンテキストがそこに保持されることになります。

Hermes はなぜより抑制的に見えるのか

Hermes の件ですが、ドキュメントの中で最も興味深い点は、常に2つのことを強調している点です。それは「オンデマンドローディング」と「プロンプトキャッシュの保持」です。

まずコンテキストファイルをチェックしてください。Hermesはセッション開始時に、現在の作業ディレクトリでヒットした種類のプロジェクトコンテキストのみをロードします。AGENTS.mdやCLAUDE.md、.cursorrulesなどは「最初に見つかったものが採用される（first match wins）」ため、すべてが一度に読み込まれるわけではありません。さらに重要なのは、サブディレクトリ内のAGENTS.mdは起動時にすべて読み込まれるのではなく、実際にそのディレクトリに移動し、そのファイルを読み込み、そのパスに到達したときに、段階的に発見され、段階的に注入されるということです。

公式ドキュメントでは、この設計の利点が明確に書かれています：

システムプロンプトの肥大化なし
プロンプトキャッシュの保持

この味はOpenClawとは全然違いますね。Hermesが言っているように、システムプロンプトは長すぎない方がいいし、後回しにできるコンテキストは後回しにして、関連するタイミングでのみ出現するものなら、最初のラウンドで詰め込みすぎない方がいいですよ。

skills も同じ考え方です。Hermes の skills ドキュメントには、プログレッシブ・ディスクロージャー（段階的開示）が明確に書かれており、目的はトークン使用量の最小化です。言い換えれば、skill はデフォルトで全文常駐するのではなく、モデルにまず軽量なインデックスを見せ、本当に必要なときだけ具体的な内容を展開させるということです。

データマイニング
ディープラーニング
ニューラルネットワーク

そして、その記憶システムも組み合わせ型に偏っています。公式ドキュメントでは組み込みメモリが厳しく制限されており、MEMORY.md は約 800 トークン、USER.md は約 500 トークンで、合計すると固定のコンテキストウィンドウは約 1300 トークンになります。SOUL.md は固定のアイデンティティであり、USER.md とメモリはシステムプロンプトに含まれますが、セッション検索やメモリプロバイダー、Honchoなどはより外部レイヤーのようなものです。この構造自体がプロンプトを自然に短くするわけではありませんが、コスト管理がしやすいデフォルトの姿勢を提供しています。

そのため、アーキテクチャの観点から見ると、私はHermesを「デフォルトでは控えめだが、徐々に重みを増していく」と分類する方が気が進みます。

これは誰がより進んでいるかではなく、どこにコストをかけるかである

多くの比較記事は、トークン消費を単一の結論として記述する傾向がありますが、これは適切ではないと思います。

OpenClaw が重いのは、設計が悪いからではありません。むしろ、意図的に多くのものを前置しているのです。長期オンラインで、クロスプラットフォームで、パーソナリティを持ち、ワークスペースとルーティングを備えたアシスタントを求めるなら、これらのコンテキストにはいずれコストがかかります。単にデフォルトのパスでこれらを一式揃えているだけです。

Hermes はより抑制的ですが、それがないわけではありません。長い SOUL.md やプロジェクトの AGENTS.md、複数のスキル、MCP、メモリプロバイダー、サブエージェント、長いツール出力などを重ねると、トークンはやはり速く消費されます。特にツールの結果自体が非常に長い場合や、複雑なコードベース内を何度も検索させる場合は、アーキテクチャ名だけで節約できるわけではありません。

したがって、より正確な言い方は以下の通りです。

OpenClaw は、コストを「アシスタント環境の常駐」に前倒しします。

Hermes はコストを「必要な時に能力を展開する」ことに後置します。

これら二つのアプローチに絶対的な優劣はありませんが、請求書の構造が全く異なります。

本当に差がつくのは、システムプロンプトだけではない

他にも、見落とされがちな細かい点があります。

第一に、Hermes は context files の部分を安定したプレフィックスにするように設計されています。サブディレクトリの hint は、関連するツールの結果に追加されるものであり、すべてのプロジェクトコンテキストを system prompt に絶えず流し込むわけではありません。このアプローチはトークンを節約するだけでなく、本質的にはプロバイダーのプロンプトキャッシュのためのスペースを確保しているとも言えます。

第二に、Hermes の execute_code のようなツールは、設計上、スクリプトが最終的に print() で出力した結果のみをモデルに返すように設計されており、途中の RPC ツール呼び出しの結果がすべてコンテキストに入るわけではありません。複雑なフローの場合、この構造により、無意味なツールのノイズを大幅に削減できます。

OpenClaw のワークスペースの哲学は、「家財道具を全部持っていく」というものに近いです。たとえ個々のファイルが短くても、種類が多い、人格レイヤーが多い、ルールレイヤーが多い、スキルや記憶の階層が多いだけで、基本的なコンテキストは少しずつ厚みを増していきます。この厚みはバグではなく、製品としての取捨選択によるものです。

第四に、両側がサブエージェントの処理を行うことも、総勘定書に影響を与えます。Hermes の多くの設計はローカルなコンテキストとローカルな実行を強調していますが、OpenClaw は複数のエージェントのアイデンティティ、ルーティング、委任といった組織能力をより重視しています。一方はコンテキストを切り替えるようなものであり、もう一方は存在関係を組織するようなものです。最終的にトークン料金に落とし込むと、形状は当然異なります。

本当に計算するなら、口先だけではダメだ

長期的に使うつもりなら、誰かが「こっちの方が節約になる」と言っても鵜呑みにせず、ツールが出したデータを見てください。

OpenClaw の公式ドキュメントには、/context detail や /usage tokens のようなコマンドがあり、ドキュメントでもセッション開始時にどのファイルが注入されるか通知してくれます。これはベースディスクがどれだけ分厚いかを見るのに非常に適しています。

Hermes の件ですが、公式ドキュメントの Honcho や関連する機能において、トークンバジェット、スキルプログレッシブディスクロージャー、コンテキストファイル注入の方法といった手がかりが提供されています。これらは hermes insights、セッションストレージ、および実際のプロバイダーの請求書と合わせて確認できます。

要するに、アーキテクチャは「どう使うか」しか決められず、「どれだけ使うか」までは決めてくれない。実際に請求額を決めるのは、君が書いた SOUL.md の長さ、詰め込んだ記憶の量、開いたスキル数、ツールの出力をどれだけ取り込めたか、そしてモデル自体の価格だ。

結局、私はこの側に立つ

デフォルトのアーキテクチャだけを見て、極端な設定は考慮に入れなければ、私はやはり Hermes の方がトークンの消費を比較的抑制された範囲に抑えやすいと考えています。

より強力だからではなく、プロンプト設計の段階から「無意味な永続コンテキストの膨張」を回避し続けているからです。OpenClawはそれとは対照的で、多少多く持っていくことを厭わずとも、その長期オンラインアシスタントとしてのアイデンティティ、ワークスペース、メッセージングインターフェースの境界が崩れないことを保証します。

そのため、トークンコストを特に気にする場合や、ワークフローが主にローカル、CLI、コードリポジトリ、スキル蓄積といったシナリオで発生する場合は、Hermesのアプローチの方が一般的に扱いやすいでしょう。

もしあなたが、様々なメッセージの場に本当に常駐する長期アシスタントを求めているのであれば、OpenClawはトークンを多めに使う方が、むしろ正常な対価だと思います。まるで人間のように常にオンラインでありながら、毎回使い捨ての小さなツールであるかのような軽さを要求することはできませんから。

ああ、結局この件はまた元の問題に戻ってきましたね。

あなたはオンラインアシスタントを育てているのか、それともローカルエージェントコアを育てているのか。これを明確にすれば、トークン計算はそれほど難しく感じなくなるはずだ。

参考資料

作成上の注記

元のプロンプト

プロンプト：Hermes と OpenClaw について、両者のトークン消費状況に関する記事をもう一つ書いてください。アーキテクチャが異なるため、消費量も当然異なります。

ライティングのアイデア概要

前回の記事の判断を引き継ぎつつ、論点をトークン消費に絞り込み、全体的なアーキテクチャ比較は繰り返さない。
「どちらが省」といった空論ではなく、両者のデフォルトのコンテキストアセンブリ方法を重点的に比較する。
Hermes はプログレッシブディスカバリー（段階的開示）、オンデマンドでの発見、およびプロンプトキャッシュの保持に焦点を当てる。
OpenClaw はワークスペース常駐ファイル、長期オンラインアシスタント環境、固定オーバーヘッドに焦点を当てる。
結びではユーザーが提示した核心的な判断は維持しつつも、「実際の請求書を見るなら、公式の usage/context ツールと実際のプロバイダーの課金体系を考慮する必要がある」という現実的な注意喚起を補足する。

Hermes を OpenClaw の代替品として見ると、最初は偏りがあるかもしれません。

Wed, 15 Apr 2026 23:52:20 +0800

この二日間、HermesとOpenClawのドキュメントを何度も読み返しましたが、読むほどに、多くの人がこれら2つのプロジェクトを一緒にして比較していますが、実は最初から比較の軸がずれていると感じました。

もちろん、これらはすべて「パーソナルAIアシスタント」を構築しています。メッセージの受信、モデルの呼び出し、ツールの実行、そしてある程度のコンテキスト保持が可能です。Hermesはさらにはhermes claw migrateという専用コマンドまで用意しており、OpenClawユーザーの一団を受け入れることを明白に知っているようです。

しかし、端的に言えば、Hermes は OpenClaw のスキン変更版ではなく、OpenClaw もメッセージ入力口がいくつか増えたエージェントフレームワークではありません。一方は Gateway から外側へ伸びていき、もう一方は AIAgent から外側へ伸びています。この違いを先に理解しないと、後でアーキテクチャや設計思想、エコシステムについて話しても、どんどん話が混乱していきます。

それらは最初から一つのものになるつもりではなかった

OpenClaw の公式ドキュメントでは Gateway を非常に早い位置に置いています。その定義は非常に直接的です。長期実行される Gateway がすべてのメッセージ面を保持し、コントロール面クライアント、Web UI、Node デバイスがすべてこの Gateway に WebSocket 経由で接続します。さらに、ホスト上にはコアなメッセージ接続を管理する Gateway は一つしかなく、WhatsApp のようなセッションも明確にそれが独占します。

これはどういう意味ですか？それは、OpenClaw の世界観が「まずエージェントがあり、それにいくつかのインターフェースを接続する」というものではなく、「まず常駐の通信および制御プレーンがあり、その中にエージェントランタイム、セッション、スキル、デリゲート、サブエージェントなどをすべて編成する」ということです。

Hermes はこの味ではない。そのアーキテクチャ図は最初から非常に明確で、CLI、Gateway、ACP、Batch Runner、API Server、Python Library といったエントリポイントがすべて同じ AIAgent コアに集約されている。セッションストレージは SQLite + FTS5 であり、ツールバックエンド、プロバイダー解決、プロンプトビルダーはすべてこのコアを中心に構成されている。

そのため、骨格から見ると、OpenClaw は「常駐型のパーソナルアシスタントシステム」に近く、Hermes は「エージェントランタイムプラットフォーム」に近く、メッセージ入力は単なるその延長面の一つに過ぎません。

Gatewayを主役にしたものと、Agentを主役にしたもの

このアーキテクチャの違いは、最終的に利用体験の違いに直結します。

OpenClaw の強みは、「多くのチャネルで長期的にオンラインで存在し、アイデンティティと境界を持ち、ルーティング可能なアシスタントをどう持つか」という点に非常に力を入れていることです。デフォルトの DM ペアリング、セキュリティポリシー、チャネル/アカウント/ピアごとのルーティング、マルチエージェントバインディング、デリゲートモードがあり、さらには「誰になりすまして発言するか、どの口座で受信するか、どのグループに出現するか」といった組織レベルの問題までドキュメント化されています。

言い換えれば、OpenClaw がまず解決したいのは存在性の問題です。このエージェントは、まず本物の人間か、あるいは真の組織アシスタントのように振る舞い、Telegram、Discord、Slack、WhatsApp、Signal、WebChatといったプラットフォーム上で生きている必要があります。その後に、コードを書けるかどうか、タスクをディスパッチできるかどうかを議論するのです。

Hermes の重点は「能力の蓄積」にあります。もちろん Gateway もあり、Telegram、Discord、Slack、WhatsApp などのプラットフォームにも接続できますが、公式な説明の中で最も前面に出ている単語は、ルーティングやアカウントではなく、persistent memory、skills、MCP、sub-agents、toolsets、さらには batch processing、trajectory export、RL training です。

ここが重要です。Hermes が解決すべき中心的な問題は、「いかに多くのメッセージングプラットフォームに AI を接続するか」ということではなく、「このエージェント自身が段階的にスキルや記憶、再利用可能な能力を育み、さらには訓練データや実験として使えるようにすること」なのです。

そのため、私はこのように要約するのがより良いと思います：

OpenClaw はコミュニケーションファーストのパーソナルアシスタントシステムです。

Hermes は agent-core-first のセルフホスト型エージェントプラットフォームです。

記憶、スキル、そして拡張の方法も、一つの味ではない

多くの人が「これら2つともskill、memory、pluginをサポートしているのでは？」と言うでしょう。その通り、どちらもサポートしています。しかし、焦点が違います。

OpenClaw のエージェントランタイムにおいて、ワークスペースは非常に重い概念です。AGENTS.md、SOUL.md、TOOLS.md、BOOTSTRAP.md、IDENTITY.md、USER.md といったファイル群は、新しいセッションの最初のラウンドで直接コンテキストに注入されます。スキル（技能）のロードにも一連の優先順位があり、ワークスペース内のもの、プロジェクト内のもの、個人ディレクトリ内のもの、~/.openclaw/skills 内のもの、バンドルされたもののすべてが積み重なります。本質的には、「ペルソナ + ルール + ワークスペース + チャネル」を統合した長期的なアシスタント環境を構築しているのです。

Hermes のスキルシステムは明らかに「手続き的記憶」に偏っています。公式ドキュメントには、skills はオンデマンドの知識ドキュメントであり、プログレッシブディスクロージャーを採用し、agentskills.io のオープン標準に対応しており、すべて ~/.hermes/skills/ 以下に統一して配置され、さらにエージェント自身がスキルを修正・削除できると明記されています。これは単に「アシスタントに説明書を数冊渡す」という感じではなく、「実行したことを再利用可能な能力ブロックとして蓄積する」という感覚です。

記憶も同じです。Hermes には控えめな MEMORY.md と USER.md が組み込まれており、これに SQLite + FTS5 のセッション検索と、さらに 8 種類のメモリプロバイダーを外付けしています。この設計は非常に興味深く、最初から「長期的な人格環境」を厚く記述するのではなく、短期記憶、検索式回想、外付けの長期記憶を分離している点です。

OpenClaw は記憶がないわけでもなく、サブエージェント、マルチエージェント、デリゲートといった高度な能力を持たないわけでもありません。むしろ、それらは十分に備わっています。しかし、ドキュメントの構造とデフォルトの思考モデルから見ると、それは継続的にオンラインのアシスタントワークスペースを運営しているように見えます。一方、Hermes は絶えず進化するエージェント能力グラフを運営しているように見えます。

エコシステムはなぜ離れていくのか

エコシステムに関しては、表面的にはすべて「オープンソース＋拡張可能」に見えますが、実際には分岐が非常に明確です。

OpenClaw のエコシステムはより広く、外部接続レイヤーに重点を置いています。公式プラグインでは、channels、model providers、tools、skills、speech、web fetch、web search、memory を拡張でき、コミュニティプラグインや ClawHub も「より多くのプラットフォーム」「より多くのアカウント」「より多くのワークフロー」への接続を目指しています。さらには、.codex-plugin、.claude-plugin、.cursor-plugin のようなバンドル形式との互換性も明言しています。この動きは非常に賢く、要するに他社のエコシステムの「殻」を先に取り込み、入口（エントランス）を大きくしようとしているのです。

OpenClaw のドキュメントを再確認すると、sub-agent、delegate、組織エージェント、thread binding、DM pairing、group mention などについて非常に詳細に記述されていることがわかります。これは単なるシングルマシンプレイヤーの遊び場ではなく、真に長期的に動作するエージェントオペレーティングシステムになることを目指していることを示しています。

Hermes のエコシステムは、「コア機能の外部接続」という側面が強いです。Python プラグインシステムがあり、メモリプロバイダープラグインがあり、コンテキストエンジンプラグインがあり、MCP サーバーへの接続もあり、さらに Skills Hub や agentskills.io のようなオープンなスキル標準があります。これに加えて、バッチランナー、トラジェクトリエクスポート、Atropos といったトレーニング関連のインターフェースがあるため、Hermes のエコシステムは自然と二種類のユーザー層を引きつけます。

一方は、それを個人のエージェントとして使う人です。

もう一つの分類は、それを研究、トレーニング、実験、ワークフローの基盤として利用する人々です。

この2種類のユーザーのニーズは大きく異なりますが、Hermesのアーキテクチャはどちらもカバーできます。そのため、HermesのエコシステムはOpenClawのように「チャネル数」や「メッセージの存在感」で先行して広がるわけではないと感じるかもしれませんが、私はむしろ、エージェント基盤（agent substrate）におけるその潜在力の方が大きいと感じています。

さらに興味深い詳細があります。Hermesの公式READMEにはhermes claw migrateだけでなく、コミュニティプロジェクトであるHermesClawも掲載されており、これを使うことで同じWeChatアカウント上でHermes AgentとOpenClawを同時に実行できます。このシグナルは非常に明白です。Hermesは自分とOpenClawが関係ないふりをしているのではなく、ユーザーの移行パスが存在することを認め、さらにそのパスを製品化して提供しているのです。

私の最終的な判断

もしあなたが「本当にメッセージングレイヤー上で動作する個人アシスタントシステム」を求めているのであれば、アカウント、チャネル、ルーティング、デリゲート、組織境界、常時オンライン、強力なコントロールプレーンが必要なのであれば、OpenClawの道筋の方がより完全であり、成熟した通信基盤に近いです。

もしあなたが「使うほど自分専用のワークステーションのように馴染むエージェントコア」を求めていて、スキル蓄積、メモリの組み合わせ、MCP、プラグイン、サブエージェント、学習データ、そしてその後の可塑性を重視するなら、Hermesの方が使いやすいでしょう。

ですから、「Hermes は OpenClaw に取って代われるか？」といった単純な質問はもうしないでください。その質問の仕方が少々粗雑です。

より正確な聞き方は以下の通りです。

メッセージングネットワーク内に存在するAIアシスタントを求めているのか、それともローカルのワークフローやエージェントランタイムに組み込まれるAIプラットフォームを求めているのでしょうか？

これをしっかり理解すれば、選択はそれほど迷いませんよ。

参考資料

作成上の注記

元のプロンプト

プロンプト：HermesとOpenClawの違い、アーキテクチャ上の違い、設計思想上の違い、エコシステムの違い

ライティングのアイデア概要

「代替品比較」というよくある質問形式は外し、「二つのプロジェクトの中心がどこにあるのか」というメインラインに直接絞る。
アーキテクチャ部分は、コミュニティによる二次的なまとめではなく、公式ドキュメントのメインエントリとコアコンポーネントを優先して参照する。
設計理念の部分では、抽象的な価値判断は行わず、Gateway、Agent Core、memory、skill、delegateといった具体的な設計に落とし込む。
エコシステム部分は、星マークや人気度、コミュニティでの憶測合戦はせず、拡張の方向性に重点を置く。
事実確認は、2026年4月15日時点で公開されている公式リポジトリと公式ドキュメントを基準とする。

AI はデモの作成が速く、修正作業も本当に速いです。

Fri, 10 Apr 2026 15:39:51 +0800

最近AIを使ってC++の小規模なプロジェクトを立ち上げたんだけど、一番「やられる」瞬間は、それがコードを書いてくれないことじゃなくて、たった3分でそれっぽくディレクトリツリーを組み立ててくれて、ついでにサードパーティライブラリをいくつか突っ込んで、デモが本当に動く時なんだよね。問題もそこにある。新しく導入したライブラリが具体的に何に対応しているのか、コンパイルのパスはどうなるのか、どこに境界線があるのか、まだ把握できていないのに、後で手戻りが発生するのはほぼ避けられない。

最近、AIプログラミングで最も怖いのはモデルの賢さではなく、最初からやりすぎなところだと感じています。特にC++のような、しっかりしたフレームワーク（脚手架）に頼れない言語の場合、手順を一つ間違えるだけで、コンパイル、リンク、ライブラリのバージョン、ディレクトリ構造など、後でいくつもの手間が増えてしまいます。

この件について、私自身の結論は非常に明確です。AI は、初期設計や依存関係の決定をすべて肩代わりするのではなく、急速に推進力のあるペアプログラマーとして適しています。GitHub のドキュメントでは、最初はより簡単なタスクから始めるよう推奨しており、エージェントにバグ修正、ドキュメント作成、テスト、技術的負債といった境界がより明確な作業を先にこなしてもらうべきだと述べています。一方、Anthropic の Plan Mode のドキュメントは、むしろ複雑な変更に対する保険のようなものであり、「まずコードを読み、計画を立ててから、修正するかどうかを決める」という流れです。両者の主張は完全に一致しているわけではありませんが、指し示す方向性は似ています。最初から最も難しく、最も混沌としていて、依存関係が最も多い塊をすべてAIに丸投げするのは避けるべきです。

そのため、この記事では大量の仕様を語るのではなく、すぐに手を動かせる小さなケーススタディを提供します。任意の空のC++リポジトリがあれば、これに従って作業できます。

AIじゃないからダメなのではなく、最初の一手が貪欲すぎるからだ

人工知能のプロジェクト、特にC++の場合、多くの時は非常に原始的な方法になりがちです。

まずは main.cpp から最小実行可能なバージョンを始める
まずコンパイルのリンクを通す
その後、どのライブラリを導入するか決める
一歩進むごとにビルドできることを保証する
ビジネスの輪郭が見えてから、リファクタリングを開始する

この方法は遅く見えるかもしれませんが、実際は非常に安定しています。なぜなら、どのステップで何を得たのか、そして問題がどのステップから生じているのかをすべて知っているからです。

AI はこのリズムを崩しやすいです。一気に「完璧に手伝ってくれる」のが好きなんです：

設定ファイルもついでに用意したよ
ログモジュールもついでに取り出したよ
エラーコード、ユーティリティクラス、ディレクトリ構造もまとめて整理したよ
サードパーティライブラリの組み込み方法も、代わりに選んでおいたよ

結果として、デモは完成しているように見えても、あなたのメンタルモデルは空っぽである。その後、ライブラリの能力境界とあなたが考えていることに少しでも食い違いがあると、手直しが必要なのは一点ではなく、連続したものになってしまう。

まずは小さなプロジェクトで練習する

個人的には、練習に最適だと思うのは、非常に小さなログスキャンツールを作ることです。名前は適当でいいですが、例えば logscan のようなものです。

それはただ一つのことをします。あるディレクトリ内のログファイルをスキャンし、error と warn の数を数え、その結果を出力するだけです。この問題はそれほど大きくありませんが、C++の小規模プロジェクトで最も一般的ないくつかの部分をすべて通るのにちょうど良いものです：

main と引数エントリポイント
出力フォーマット化
ログ
設定ファイル
ビジネスモジュールの分割

重要なのは問題がどれだけ高度かではなく、分解の方法です。

これを4つのステップに分割し、各ステップではAIが現在の小さな一歩のみを行うようにします。

ステップ1：まず出力を準備する

最初のステップは、ログや設定には触れず、抽象化を考えないことです。

2つのことをする：

最低限の main.cpp を作成する
fmt をインポートし、スキャンしたディレクトリと統計結果を出力する

fmt の公式ドキュメントには、非常に明確な CMake の使い方が記載されています。そこには fmt::fmt と fmt::fmt-header-only という2つのターゲットがあり、ドキュメントではコンパイル版をより推奨していると明記されており、その理由は単純で、ビルド時間がより親切だからです。CMake の FetchContent のドキュメントも新しいプロジェクトの開始に非常に適しています。なぜなら、これはビルド段階になってから一時的にダウンロードするのではなく、configure 段階で依存関係を読み込むからです。

このステップでは、依存戦略を固定し、AIに自由に発揮させません。

FetchContent を統一する
または find_package を統一する
いざという時に vcpkg、いざという時に add_subdirectory、そしてまた手動でヘッダーファイルをコピーするのはやめてほしい

もし練習用のプロジェクトであれば、私はAIにこのように制約をかけます：

アーキテクチャを一度に最適化しないでください。
現在の目標はこのステップのみであり、プロジェクトは常にコンパイル可能でなければなりません。

このステップでは以下の3点のみを行います：
1. ルートの CMakeLists.txt に fmt を導入する
2. main.cpp で渡されたディレクトリとスキャン結果を fmt で出力する
3. 既存のターゲット名とディレクトリ構造を維持し、ログ、設定、テストフレームワークは追加しない

まず修正リストを提示し、その後コードを提示してください。
完了したら、ビルドコマンドと期待される出力を提示してください。

ここに重要な詳細があります。AIは、制約がない場合、「ついでにこれもやった」ということを加点要素として扱いがちです。今回のラウンドでは範囲を超えてはいけないと明確に伝える必要があります。

ステップ2、ログのアップロード

まずステップとして、コードが書けて、動いて、出力も綺麗になったら、spdlogを追加する。

spdlog の公式 README は、実際何ができるかを非常に分かりやすく記述しています。コンソールログだけでなく、通常のファイル、ローテーションファイル、日付ごとの分割、さらにはバックトレースリングバッファまで対応できます。問題はここです。機能が多すぎると、AI は興奮しすぎてしまい、まるで初版でカラーコンソール、ローテーションログ、日付アーカイブ、グローバルロガーファクトリを全部盛り込みたがるのです。

不要です。

このステップでは、コンソールログを出すか、せいぜい最もシンプルなファイルログを追加するだけです。なぜなら、ここで本当に学ぶべきことは、「どうやってロギングシステムを完全に設計するか」ではなく、以下の3点だからです。

ロガーの初期化はどこで行うべきか
ビジネスロジック内でどのようにロガーを取得するか
エラー発生時と通常出力時のログの役割分担はどうすべきか

もし最初から rotating_file_sink や daily_file_sink を使うと、「機能がとても充実した」ロギングモジュールを手に入れたように感じますが、実際にはローテーションや日付ごとの分割が必要なのか、それともデバッグ段階でターミナルに出力するだけで十分なのか、自分自身がまだ分かっていないかもしれません。

要するに、ログファクトリをいかに美しく描くかよりも、まずspdlog::info()の使い方を理解することがより重要です。

ステップ3、設定ファイルに触れる

設定ファイルの部分は、AIによって大規模なプロジェクトになりやすいです。

私は、それが「最強」だからというよりは、新しいプロジェクトの初期段階に適しているから、toml++ のようなシンプルなライブラリで練習したいと思っています。それ自体が C++17 のヘッダーオンリーな TOML パーサーであり、README に記載されている例も非常に短く、toml::parse_file("configuration.toml") で直接読み込めます。さらに重要なのは、単一ヘッダーファイル形式が本当に手間いらずなことです。公式の説明文もとても面白いのですが、シングルヘッダーのソリューションは「toml.hpp をソースツリーに放り込むだけ」で、「第二の手順はありません」。

このステップでは「設定センター」は行わず、以下の3つのフィールドを読み込んでください：

スキャンディレクトリ
キーワードリスト
出力はファイルに書き込むか

そしてそれらを非常に薄い AppConfig 構造体に詰め込みます。

それで十分です。

多くの手戻りは、実はここから生じているんです。設定を起動時に一度読み込むのか、実行時にホットアップデートするのか。ローカルのCLI専用なのか、それとも将来的にサービスプロセスで再利用するのか、ご自身でまだ明確に考えていない。AIはすでにあなたのために5、6層も処理してくれました。後から方向性を変更すると、これまで積み上げてきた「完璧な設計」がすべて重荷になってしまいますよ。

ステップ4：ビジネスモジュールの分解

例えば、fmt、spdlog、toml++ などはすべて自分で公式ドキュメントを一度確認し、実際に動作テストを行った上で、AIにモジュール分割を手伝ってもらう、といった具合です。

この時分解すると、心に余裕ができます。

通常、私は以下のようなファイルを収集します：

main.cpp はアセンブリのみを担当する
app_config.{h,cpp} は設定の読み取りのみを担当する
logger.{h,cpp} はログの初期化のみを担当する
log_scanner.{h,cpp} に業務ロジックを配置する

注意点として、この段階になってから分割するものであり、最初から分割するわけではありません。最初のステップで目次をきれいに並べることは、多くの場合、視覚的に心地よいだけであり、認知的な明確さが増すわけではありません。

本当に役立つのは、複雑な規範ではない

インターネット上には、AIのコーディング規約が非常に複雑なものが多くて、十数項目、数十項目とあって、見るだけで疲れますね。私が今残したものは、実はたった3つだけなので、これで十分だと思います。

第1条、まず「ライブラリカード」を作成します。

サードパーティライブラリを準備するたびに、私はまずAIに以下の4つの質問だけを回答するようにしてもらいます。

このライブラリは何の問題を解決しますか
公式版はどこまでサポートしていますか
今回はどの機能の 1 つか 2 つに絞って使いたいと思っています
ビルド、デプロイ、実行にどのような制約をもたらしますか

このカードが分からない場合は、とりあえず受けないでください。

第2条、一度にAIを一つのチェックポイントだけに通す。

例えば、このラウンドではこれだけを完了させることを許可する：

コーディングできる
実行できる
期待される出力を確認できる

同じラウンドで「ついでにディレクトリをリファクタリングする」「ついでに設定クラスを追加する」「ついでに例外処理の仕組みも統一する」といったことをするのはやめてください。C++プロジェクトでは、「ついで」というものが、問題の原因箇所を汚染しやすくなります。

第3条、各ラウンドでロールバックポイントを残すこと。

コミットしなくても、以下の質問に答えられる必要があります。

このステップで具体的に何が変わったのか
間違っていた場合、どこを削除する必要があるか
一つ前のステップに戻した場合、プロジェクトはまだ編集可能か

気づくと、この考え方は実は手動での開発と非常によく似ています。違いは、以前は自分でコードを書いていたのに対し、今はAIが暴走しないように見張っているという点だけです。

より実戦的なAIの活用方法

この一連のものを本当に習得したいなら、3周連続でやることをお勧めします。

第1ラウンドは、AIにfmtの補完だけを任せて、残りは自分でCMakeの設定と出力コードを読み直してください。

第2ラウンドは、AIにspdlogのみを扱わせてください。コンソールログにするかファイルログにするかは自分で決めてください。両方同時に使うのは禁止です。

第3ラウンドは、AIにtoml++の受け渡しのみをさせ、設定項目は自分で決め、AIに将来のニーズを推測させることは禁止とする。

この3周を終えると、AIプログラミングに対する感覚が大きく変わるでしょう。前は「どうしてこんなにたくさん生成してくれるんだ」という感じだったのが、徐々に「次のステップをどれくらい小さくすれば最も効率的か」という視点になるようになります。

これが今のAIプログラミングで最も価値のある能力だと思います。

デモを出すわけではない。

むしろ、一つのプロジェクトを確実に前進させる。

正直なところ、このやり方は目新しくなく、むしろ古臭いかもしれません。しかし、古い方法は再作業に強い傾向があります。特にC++のような言語では、AIに少し任せる部分を減らして、自分で確認する部分を増やすと、後が本当に楽になります。そうしないと、3分で飛び立っても、3時間かけてやり直すのは自分自身ですからね。

参考資料

作成上の注記

元のプロンプト

プロンプト：人間がプロジェクトを構築する際、C++のようにフレームワークを使わない言語の場合、まずmainからロジックを展開していく「骨格」を作り、徐々に設定ファイル、ログモジュール、反復的なビジネスモジュールなどを追加していくのが良いと思います。私の習慣としては、毎回コンパイルが通ることを確認し、段階的にリファクタリングを進めることです。最初から最適解である必要はありません。AIによるプログラミングは、今や多くのケースで工程を飛ばしたり、初期の思考が不足したりしがちです。特に新しいサードパーティライブラリを導入する場合、AIはすぐにデモを出せますが、私が新しく導入したサードパーティライブラリの詳細な仕様やサポートする機能が不明確なため、関連ロジックの作り直し（手戻り）率は人間による開発よりも明らかに高くなります。学べるような良い実例はありませんか？インターネット上には複雑なAIプログラミング規約はたくさんあると知っていますが、私はもっとシンプルで、すぐに適用できるものが欲しいです。

ライティングのアイデア概要

トピックを tooling レーンに絞り、AI がワークフローを変えた後、どこが楽になり、逆にどこが不自然になったかを重点的に書く。
一般的な規範リストではなく、C++ の小規模プロジェクトの段階的な練習事例に変更する。
ユーザーが「main から始め、各ステップでコンパイルでき、徐々にリファクタリングできる」という核となる判断を維持し、これを記事全体のメインラインとする。
Anthropic、GitHub、CMake、fmt、spdlog、toml++ の一次資料を補完し、ツールの機能や依存方法について憶測するのを避ける。
記事の構成は fmt -> spdlog -> toml++ -> モジュール分割 の順に進め、意図的に AI に一度で全てを解決させないようにする。

VS CodeでC++を扱う際は、CMakeとGDB Printerを忘れないように。

Thu, 09 Apr 2026 19:21:36 +0800

以前VS CodeでC++をデバッグするとき、設定は基本的にlaunch.jsonに留まっていて、せいぜいGDBの行を追加する程度でした。 programを埋めて、gdbを埋めて、ブレークポイントを設定する。それで終わり？毎回デバッグ前にターミナルで手動でcmake --buildしないといけませんでした。さらに面倒なのは、カスタム価格、契約、注文タイプなどでブレークポイントを打った後、VS Codeのデバッグウィンドウには内部フィールドが大量に表示されるだけで、データ自体は正しいのですが、人間が理解できる言葉になっていない点です。この件がおかしいと思う点は、以前見たチュートリアルもlaunch.jsonまでしか触れていなかったことです。最近AIに新しいプロジェクトの設定を依頼したところ、なんと自動でpreLaunchTaskとgdb_printers.pyを追加してくれたので、「VS CodeでC++をデバッグするって、ただGDBを起動させるだけじゃないんだな」と気づきました。デバッグ前にCMakeのコンパイルを自動実行できるし、ブレークポイントで停止した後に、GDBにPythonスクリプトをロードさせて、ビジネスロジックの型を自分が見やすい形に整形させられるんです。正直なところ、これは何かの「裏ワザ」というわけではありません。しかし、C++の日常的なデバッグにおける非常に面倒な2つの空白部分――起動前のビルドとブレークポイント後の変数表示――を完璧に埋めてくれたのです。

以前只配了一半

多くのチュートリアルにある .vscode/launch.json は、大体このような内容です：

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug with GDB",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/build/debug/bin/vscode_cpp_debug_demo",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${workspaceFolder}",
      "MIMode": "gdb",
      "miDebuggerPath": "/usr/bin/gdb",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        }
      ]
    }
  ]
}

この部分は間違っているとは言えません。 VS Code の公式の C++ サンプルでも、同様の構造が使われています：type に cppdbg を使い、MIMode に gdb を使い、setupCommands で pretty-printing を有効にしています。しかし、決定的に欠けている動作があります。 F5 を押すと、それは program が指す実行ファイルを起動します。問題は、そのファイルが今まさにコンパイルされたものかどうかです？もしそうでなければ、前回ビルドした古いプログラムをデバッグしてしまいます。私も以前、よくこんな馬鹿なことをしていました。コードを変更し、ブレークポイントも設定したのに、しばらく動かしてみたら動作がおかしいことに気づき、最後に「ああ、さっき再コンパイルするのを忘れていた」と思い出す、ということがありました。

preLaunchTask こそがそのフックである

VS Code の Tasks は、本質的に外部コマンドをエディタに組み込む仕組みです。コンパイル、テスト、パッケージングといった作業は、以前はターミナルで手動で行う必要がありましたが、今では .vscode/tasks.json に記述できます。そして launch.json の中の preLaunchTask が、そのラベルを使って該当するタスクを探し出します。最小限の CMake プロジェクトを例に挙げると、このように配置できます：

.
├── .vscode/
│   ├── launch.json
│   └── tasks.json
├── CMakeLists.txt
├── src/
│   └── main.cpp
└── tools/
    └── gdb_printers.py

CMakeLists.txt はまず、これだけ記述します：

cmake_minimum_required(VERSION 3.16)

project(vscode_cpp_debug_demo LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)

add_executable(vscode_cpp_debug_demo
    src/main.cpp
)

次に、.vscode/tasks.json です：

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "cmake: configure debug",
      "type": "process",
      "command": "cmake",
      "args": [
        "-S", "${workspaceFolder}",
        "-B", "${workspaceFolder}/build/debug",
        "-DCMAKE_BUILD_TYPE=Debug"
      ],
      "problemMatcher": []
    },
    {
      "label": "cmake: build debug",
      "type": "process",
      "command": "cmake",
      "args": [
        "--build", "${workspaceFolder}/build/debug",
        "--parallel"
      ],
      "dependsOn": ["cmake: configure debug"],
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "problemMatcher": ["$gcc"]
    }
  ]
}

ここの cmake --build に注目してください。 CMake の公式なビルドのエントリーポイントは、この形式です：cmake --build <dir>。これは、Make や Ninja、MSBuild といった背後のネイティブビルドツールを呼び出します。つまり、VS Code はあなたのプロジェクトが make を実行すべきなのか ninja を実行すべきなのかを知る必要がないのです。そのことは CMake に任せているわけです。

F5 の前に、まずコンパイルする

その後、.vscode/launch.json に戻り、preLaunchTask を追記してください：

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "CMake Debug with GDB",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/build/debug/bin/vscode_cpp_debug_demo",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${workspaceFolder}",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "miDebuggerPath": "/usr/bin/gdb",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        }
      ],
      "preLaunchTask": "cmake: build debug"
    }
  ]
}

ここが重要です：

"preLaunchTask": "cmake: build debug"

F5 を押す流れは以下のようになります：

launch.json
  -> preLaunchTask
    -> tasks.json: cmake: build debug
      -> dependsOn: cmake: configure debug
        -> cmake -S ... -B ...
      -> cmake --build ...
  -> gdb が最新の program を起動する

Windows + MinGW の場合、program は .exe 付きのパスに変更する必要がある可能性が高く、miDebuggerPath も自身の gdb.exe を指すようにする必要があります。 Visual Studio Generator のような複数の設定を生成するジェネレータの場合は、ビルド引数に通常 --config Debug を追加する必要があります。しかし、基本的な流れは変わりません。デバッグする前に VS Code に一度ビルドタスクを実行させてください。自分で記憶に頼るのはやめましょう。

もう一つの課題点：カスタム型の可読性

コンパイルリンクを繋げるだけでは不十分です。 C++コードで少し業務的な型をラップするだけで、VS Codeの左側の変数ウィンドウがすぐに見づらくなります。例えば、以下の例を見てください。

src/main.cpp:

#include <cstdint>
#include <cstdio>
#include <string_view>
#include <vector>

namespace market {

struct Price {
    std::int64_t raw{};

    static Price from_double(double value) {
        return Price{static_cast<std::int64_t>(value * 10000)};
    }

    double to_double() const {
        return static_cast<double>(raw) / 10000.0;
    }
};

struct Instrument {
    char symbol[16]{};
    Price last;
};

Instrument make_instrument(std::string_view symbol, double price) {
    Instrument instrument;
    std::snprintf(instrument.symbol, sizeof(instrument.symbol), "%s", symbol.data());
    instrument.last = Price::from_double(price);
    return instrument;
}

} // namespace market

int main() {
    std::vector<market::Instrument> watchlist{
        market::make_instrument("IF2406", 3578.6),
        market::make_instrument("IH2406", 2468.2),
    };

    market::Price limit = market::Price::from_double(3600.5);

    // ここでブレークポイントを置き、watchlistとlimitを観察する。
    return watchlist.empty() || limit.raw == 0;
}

market::Price は業務上「価格」です。しかし、デバッガがデフォルトで見せるのは以下のようになるかもしれません：

limit = {raw = 36005000}

その通り、データは正しいです。しかし、私の頭の中では、この 36005000 を手動で 3600.5000 に変換しなければなりません。もしプロジェクト内に Price、Quantity、OrderId、Instrument、AlgoState などが山ほどある場合、デバッグウィンドウはすぐに構造体の墓場になってしまいます。このときこそ GDB の pretty-printer が必要になります。 GDB の公式マニュアルには非常に明確に書かれています。それは、Pythonコードを使って値をpretty-printするための仕組みを提供しており、この仕組みはMI（Machine Interface）とコマンドラインの両方に適用できるということです。 VS CodeのC++デバッグがまさに GDB/MI という経路を通っています。

ビジネスタイプ用のPython表示層の作成

tools/gdb_printers.py を新規作成します：

import gdb
import gdb.printing


class PricePrinter:
    def __init__(self, val):
        self.val = val

    def to_string(self):
        raw = int(self.val["raw"])
        return f"{raw / 10000.0:.4f}"


class InstrumentPrinter:
    def __init__(self, val):
        self.val = val

    def to_string(self):
        symbol = self.val["symbol"].string()
        price_raw = int(self.val["last"]["raw"])
        price = price_raw / 10000.0
        return f"{symbol} last={price:.4f}"


def build_pretty_printer():
    printer = gdb.printing.RegexpCollectionPrettyPrinter("market")
    printer.add_printer("Price", "^market::Price$", PricePrinter)
    printer.add_printer("Instrument", "^market::Instrument$", InstrumentPrinter)
    return printer


gdb.printing.register_pretty_printer(
    gdb.current_objfile(),
    build_pretty_printer(),
    replace=True,
)

次に、launch.json の setupCommands にこれをソースとして読み込ませます：

"setupCommands": [
  {
    "description": "gdbのプリティプリンティングを有効化",
    "text": "-enable-pretty-printing",
    "ignoreFailures": true
  },
  {
    "description": "プロジェクトのプリティプリンターをロード",
    "text": "-interpreter-exec console \"source ${workspaceFolder}/tools/gdb_printers.py\"",
    "ignoreFailures": false
  }
]

F5 を再実行します。この後、デバッグウィンドウを見ると、Price の表示は以下に近くなるはずです：

limit = 3600.5000

Instrument もまた、単なる配列や構造体から、よりビジネスに近いものになります：

IF2406 last=3578.6000

ここで「近い」と言っているのは意図的です。なぜなら、プリティプリンターはコンパイラ、型名、実際のフィールドレイアウトと一致させる必要があるからです。もしあなたのビジネスタイプの中に std::vector や std::array、スマートポインタなどがネストされている場合、Pythonスクリプトからアクセスするフィールドはさらに深い呼び出しが必要になるかもしれません。一つのスクリプトですべてをカバーできると期待しないでください。しかし、考え方はしっかりしています。「デバッグ時に人間が見たい姿」を、独立したPythonの表示ロジックとして記述するのです。

launch.json を全てだと思ってはいけない

この設定群を見ると、少なくとも3層あると感じます。 .vscode/launch.json は「デバッガをどう起動するか」を担当します。 .vscode/tasks.json は「デバッガを起動する前に、まずプロジェクトをビルドする」を担当します。 tools/gdb_printers.py は「ブレークポイントで止まった後、変数を人間が理解できる形で表示する」を担当します。以前は最初の層だけを設定していました。動くものの、非常に素っ気ないものでした。本当に快適な C++ デバッグというのは、「まずターミナルでコンパイルしてから、戻ってきて F5 を押して、変数ウィンドウでフィールドの意味を頭の中で計算する」というものであってはいけないはずです。より快適なフローは、F5 を押すと VS Code が自動的に CMake を実行し、GDB がプロジェクトの Python printer を自動ロードし、ブレークポイントで停止した際に、デバッグウィンドウが直接ビジネス言語で表示してくれることです。今回 AI にプロジェクトの設定をしてもらったことで、最も価値があったのは、どれだけ C++ コードを生成したかということではありませんでした。むしろ、これらの古いツール間の「接着剤」の部分を補ってくれた点です。以前から CMake や GDB が分からないわけではありませんでした。ただ、その中間にあるいくつかのフック（接続部分）を設定していなかっただけなのです。

参考資料

作成上の注記

元のプロンプト

プロンプト：$blog-writer vscode で C++ を開発する際、以前見たチュートリアルは、launch.json 内の gdb デバッグ情報の設定のみで、preLaunchTask の設定に触れていませんでした。CMake のコンパイルを自動的にトリガーできる機能があれば、これは AI が新しいプロジェクトを設定する上で非常に役立つものです。もしコードにカスタムデータ型が多く含まれていて、VS Code のデバッグウィンドウで直接表示できない場合でも、Python スクリプトを導入して前処理を行うことで、それらも表示できるようになります。上記の内容について、すべて実際のコード例を提供してください。

ライティングの骨子まとめ

メインテーマを「これまで launch.json の設定だけだったが、実際にはデバッグ前のビルドとデバッグ時の表示という2層の接着剤（仕組み）が欠けていた」ことに置く。
ユーザーから提供されたトリガーポイントは維持する：AI が新しいプロジェクトを設定する際に、preLaunchTask で CMake のコンパイルが自動的にトリガーされることを発見した点。
コード例は最小限の CMake プロジェクトで構成し、CMakeLists.txt、tasks.json、launch.json、C++ のカスタム型、および GDB Python pretty-printer を含める。
事実確認は VS Code、CMake、GDB の公式ドキュメントを最優先とし、本文ではドキュメント全体を翻訳せず、このデバッグフローに関連する事実のみを残す。
pretty-printer に関しては、型名、標準ライブラリの実装、フィールドレイアウトなどが Python スクリプトに影響を与える点について注意喚起を行う。プロジェクト内では自身の型に合わせて修正が必要である旨を明記する。

フォルダの階層構造に名前空間を重ねる、これは一体何と呼ばれますか？

Thu, 09 Apr 2026 02:31:07 +0800

最近アルゴリズムサービスを書いていて、twap や vwap のようなモジュールをいくつか展開したところ、またこの古い問題に直面しました。

C++ でクラス名に頼ってセマンティクスを無理やり押し付けると、名前はすぐに制御不能になります。TwapOrderManager、VwapOrderManager、AlgoOrderManager のようなものは、書き進めているうちに「自分の構造が手に負えないことはわかっているけど、とりあえずプレフィックスを付け足しておこう」という感じになってしまいます。端的に言えば、フォルダで階層分けをして、さらに namespace を一つ追加するのは、コードの潔癖症なのではなく、C++ に Java のようなネイティブな package システムがないことによる空隙を埋めているのです。

結論から言うと

もし最も近いソフトウェア工学の用語を探さなければならないとしたら、私は以下の2つの言葉が最も適切だと思います。

モジュール化（modularization）
名前空間管理（namespace management）

もう少し具体的に言うと、このようなディレクトリ構成は、しばしば以下のようなことを行っています。

機能ごとのパッケージング / ドメインごとのパッケージング、つまり一般にいう package by feature
ビジネス境界が非常に明確な場合は、バウンデッドコンテキストの要素も含まれます。

つまり、これは単一の標準的な訳語を持つ小さな概念というよりも、いくつかの設計原則が積み重なったもののようなものです。

これは事前に解決している、というよりは「見栄え」の問題ではない

多くの人は namespace を見ると、まず名前の衝突を避けることを思い浮かべます。これはもちろん正しいです。C++ の標準ライブラリにおける namespace は、本来大規模なプロジェクトでの名前の衝突を防ぐために存在します cppreference。しかし、実際のビジネスコードにおいては、その価値はそれだけにとどまりません。

ディレクトリ構造と namespace が整列されることで、クラス名が上位のセマンティクス（意味）を繰り返す必要がなくなります。

例えば、以前は以下のように書くことが多かったかもしれません：

class TwapOrderManager;
class TwapScheduleEngine;
class VwapOrderManager;
class VwapScheduleEngine;

ディレクトリと名前空間を使うように変更すると、より自然な書き方は通常以下のようになります：

namespace algo::twap {
class OrderManager;
class ScheduleEngine;
}

namespace algo::vwap {
class OrderManager;
class ScheduleEngine;
}

これにより、冗長な接頭辞がなくなり、かえってセマンティクスが明確になります。「それがどのコンテキストに属するか」という情報がクラス名の中に詰め込まれるのではなく、ディレクトリ構造と namespace に委ねられるようになるからです。

したがって、このアプローチの本質は、**「名前からコンテキスト情報を抽出し、構造（ディレクトリや名前空間）に担わせる」**ことなのです。

これはむしろ「機能（特性）ごとにパッケージ化する」に近い

もしあなたのディレクトリが以下のように長い場合：

strategy/
  twap/
    order_manager.h
    schedule_engine.h
    slicer.h
  vwap/
    order_manager.h
    schedule_engine.h
    slicer.h

あなたはもはや従来の「技術層ごとにパッケージ化する」ことをしているわけではありません。

伝統的な分け方は、むしろ以下のようになります：

models/
services/
utils/
controllers/

この分け方は初期段階では整然として見えますが、ビジネスロジックが増えてくると、service ディレクトリはゴミ集積所のようになってしまいます。ある機能に関連するクラスが異なるディレクトリに散らばり、コードを読むたびに頭の中が飛び回ります。

一方、twap や vwap のような分け方は、「機能（フィーチャー）ごとにパッケージ化する (package by feature)」という考え方に近いです。つまり、あるディレクトリはまず「このビジネス領域は何をするのか？」に答え、その中にそのビジネスに必要なオブジェクトやフローを配置していくイメージです。Javaの世界ではこの言い方がより一般的ですが、C++においても同様に成立します。ただし、それを支えているのはネイティブな package ではなく、「ディレクトリ + 名前空間 (namespace) + ヘッダーファイルの境界」になります。

端的に言えば、あなたはコードを「見た目（構造）で組織するのではなく、変更の理由（振る舞い）によってコードを組織している」のです。

一歩遡ると、それは高凝集・低結合ということになる

ソフトウェア工学でよく耳にする「高凝集、低結合」という言葉は、まさにこのような場所に当てはまります。

twap の下のオブジェクト同士が頻繁に協調して動作する場合、それらは物理的にも近く配置し、名前空間も近接させるべきです。vwap もこれと似ていますが、全く同じわけではないので、独立した境界を持たせるべきです。このようにすることで、いくつかの直接的な利点があります：

同じモジュール内のクラス名を短くできる
モジュール間の依存関係が視覚的に把握しやすくなる
リファクタリングの際、変更が他の場所に波及するかどうかを判断しやすくなる
将来的に特定の機能を独立したライブラリとして切り出す際のコストも低くなる

これが、多くの成熟したプロジェクトが最終的に「ディレクトリ境界 + 名前空間境界 + コンパイル境界」が可能な限り一致する形になる理由です。QuickFIX のようなプロジェクトを見ても、同様の考え方が見られます。型や拡張ポイントは、長いクラスプレフィックスに頼って強制的に区別するのではなく、できるだけ明確な名前空間の下に配置されています QuickFIX GitHub。

いつまた足りなくなるのか

しかし、この件を神格化する必要はありません。

フォルダの階層化にさらにnamespaceを適用したとしても、それはあなたがモジュール化の方向に進んでいることを示すだけであり、アーキテクチャが自動的に良くなるわけではありません。よくある落とし穴も明白です：

ディレクトリと名前空間が一致していない

ディレクトリは twap/ なのに、コードの中にはバラバラに配置されたグローバルクラスや、namespace common があちこちに散らばっていて、これは基本的に無駄です。

モジュール境界は偽の境界である

表面上には twap や vwap があるが、実際にはお互いに #include しており、共通ロジックは自由に透過し、結局ただファイルを移動させただけで、結合度は全く下がっていない。

`common` ディレクトリが肥大化する

これが最もよくあるケースです。多くのプロジェクトは最初はきれいに分割されているのに、後になると面倒になり始め、「common」「base」「util」などに物を放り込みがちになります。その結果、最終的には真に安定した抽象概念が蓄積されるどころか、誰でも触れてしまい、誰もが依存してしまう巨大な穴（負債）ができてしまいます。

構造はレイヤーごとに分け、ビジネスロジックごとには分けない

もしあなたのディレクトリが常に api、service、dao、model のようになっている場合、多くのビジネス概念に適切な「家」が存在しません。クラス名は必然的にどんどん長くなり、本来構造で表現すべきものをすべて名前に詰め込むことになります。

それって結局何と呼ぶべきか

チーム内でコミュニケーションする場合、私は3つのレベルに分けて話せると思います：

人間言葉で伝えたいだけなら：ディレクトリと名前空間に基づいてモジュール化する
よりエンジニアリングっぽく言いたいなら：機能（フィーチャー）ごとにパッケージを分ける方法で、階層的な名前空間を組み合わせる
もしこの境界がすでにビジネスのセマンティクスに強く結びついている場合：バウンデッドコンテキスト（Bounded Context）の匂いがするモジュール分割

私自身は2番目に傾いています。なぜなら、それがあなたが説明しているシナリオに最も近いからです。

あなたが言っているのはC++の文法的なテクニックでも、単なる命名規則でもなく、もっと本質的なことをやろうとしているのです：構造を使ってセマンティクスを担わせ、名前を本来の意味に戻すこと。

クラス名が短くなり、ファイル名も短くなることで、コードを読む際に最初に目に入るのは、ディレクトリの責務、命名の責務、実装の責務をすべてごちゃ混ぜにしたTwapOrderManagerImplのようなものではなく、コンテキストが明確なtwap::OrderManagerのようなオブジェクトになります。

そうなることで、ようやくJavaでパッケージ構造が成熟した後のような感覚になるのです。

最後のまとめ

したがって、ソフトウェア工学には当然対応する概念はありますが、唯一の正解というわけではありません。

より大きな視点で見れば、「モジュール化」と呼ばれます。コードの構成という観点からは「機能ごとのパッケージング」、さらにネームスペース管理が加わります。ドメイン境界という観点から見ると、それはある種のバウンデッドコンテキストの意味合いも持ちます。

どう言えばいいでしょうか、このようなプラクティスの最も価値のある点は、「名前がきれいに整った」ことではなく、ついに超長いプレフィックスに頼って構造的な欠如を補わなくてよくなった、という点なのです。

参考資料

作成上の注記

元のプロンプト

プロンプト：コーディング開発において、C++の良いプラクティスの一つは、フォルダで階層化し、各クラスに名前空間（namespace）を適用することです。これはJavaのパッケージのようなもので、ファイル名やクラス名に含まれる冗長な内容を効果的に減らすことができます。quickfixという古典的なプロジェクトがありますが、最近開発したアルゴリズムサービスでも同様のデザインを使用しました。TWAPやVWAPなど、多くの機能モジュールが似ています。ソフトウェア工学において、これに特化した概念はありますか？

ライティングの思考プロセス要約

アルゴリズムサービスにおける twap や vwap の実際のモジュールトリガーポイントから切り込み、まず判断を明確にする。
問題を単一の名詞として無理に説明するのではなく、モジュール化、名前空間管理、特性ごとのパッケージ分けといった、より正確な階層に分解した。
QuickFIX と Java パッケージの対応関係を残し、C++ がディレクトリと名前空間に頼って構造的な意味（セマンティクス）を補うことが多いことを説明するために用いた。
「重複名の回避」といった表層的な説明に留まるのではなく、「構造を用いて意味を担わせる」点に重点を置いた。
後続の展開が容易になるよう、namespace、package by feature、bounded context に関する参考リンクを追加した。

Googleが今回Gemma 4を公開した（3）

Wed, 08 Apr 2026 23:56:20 +0800

今回フォーラムを巡回していて、一番印象に残ったのは、「またランキングを出した」というところではなく、「VRAMが足りないから、パラメータがどれだけ大きくても無駄だ」という、かなり生易しい（陳腐な）一言でした。

以前は「モデルが遅い」ことを計算能力の問題だと捉えがちでした。しかし、後になってよく気づいたのは、多くのケースでGPUの計算能力が足りないのではなく、データが適切な場所に留まらないことが原因だということです。メモリのパスが少し変わるだけで、トークン速度は少し落ちるというレベルではなく、直接落ちてしまいます。

前2の記事で、前提となる問題は全て網羅しました。第1回ではリリースとライセンスについて、第2回では3060 12GBでなぜまず26B A4Bを見るのかについて解説しました。そして、今回の記事では、速度が具体的にどのように落ちていくのかだけを扱います。

VRAM不足、慢のはちょっとの問題ではない

推論というプロセスを分解して見ると、特に重要なのが以下の2点です。

モデルの重み（モデルウェイト）
KVキャッシュ重みはモデルそのものを決定し、KVキャッシュはこれまでの文脈の状態を記録します。コンテキストが長くなるほど、KVキャッシュは大きくなります。この2つが安定してGPUのVRAM内に収まっていれば、トークンを生成する際も基本的に高帯域幅なVRAM内でのデータ読み出し、計算、結果書き戻しが行われるため、速度は通常期待できます。本当に厄介なのは、VRAMに乗り切らない場合です。一度容量オーバーになると、推論フレームワークは譲歩せざるを得ません：
一部の重みをシステムメモリに配置する
あるいは一部のKVキャッシュをシステムメモリに配置する
あるいはCPUとGPU間でデータを頻繁に行き来させるこの状況では問題は「少し計算量が増えた」というレベルではなく、「トークンを一つ出すたびにデータ待ちが発生する」というレベルになります。

なぜ急落（断崖）が発生するのか、線形に遅くなるわけではない

この罠に初めて遭遇した多くの人は、「モデルが $14\text{B}$ から $31\text{B}$ になったら、2倍以上遅くなるから、我慢できる範囲だ」と直感的に考えます。

しかし、現実はそうではありません。

真の境界線はパラメータが2倍になることではなく、ワークセットがVRAM（ビデオメモリ）の境界を越えたかどうかです。

まだ越えていない場合、モデルが大きくなることで遅くなるのは、通常予測可能な範囲内です。

一度それを超えると、システムの状態が根本的に変わります：

それまでは「VRAM内でのクローズドループ」だった
今や「VRAM + メインメモリ + バスによるデータ転送」になる

経路が変わるだけで、コストは全く異なります。特にデコード（生成）の段階では、元々トークンを一つずつ順に進んでいき、バッチサイズもそれほど大きくないため、この時最も怖いのは、すべてのトークンに対してデバイスをまたいでデータを待つ必要があることです。

そのため、非常に典型的な現象を目にすることがあります：

モデルが動かないわけではない
GPUも完全に遊んでいるわけではない
しかし、トークン/秒（token/s）の数値が非常に悪い

これが皆が言う「断崖」です。モデルが突然賢さを失ったのではなく、メモリのデータ経路が突然非効率的になったのです。

「26B A4B」がローカルプレイヤーにとってより親切な理由

この点も、なぜ私が前回の記事で一貫して「26B A4B」を重視してきたのかを説明しています。当然ながら総パラメータ数は小さいわけではありませんが、実際にトークンごとにアクティブになるのは約「3.8B」程度です。これは、類似のデプロイメント条件下において、計算リソースやVRAMへの負荷が、密な（dense）大規模モデルよりも管理しやすい場合が多いことを意味します。これも魔法ではありません。もしコンテキストを長くしすぎたり、量子化やフレームワークのサポートが不十分だと、これでも苦労します。ただ、最初からVRAMを使い切ってしまうような密なモデルと比較すると、「26B A4B」は、一般消費者向けのグラフィックカードにとってより現実的な選択肢という側面があります。ですから、多くのケースで「31B」が弱いのではなく、ローカルマシンが誰と長期的に付き合うのに適しているか、という問題なのです。

Mac が「爆発しにくい」理由

Mac の最も異なる点は、モデルではなくメモリ構造にあります。 Apple silicon はユニファイドメモリを採用しています。CPU と GPU が同じメモリプールを共有するため、専用GPU搭載機のように、片方がVRAM、もう片方がメインメモリで、間にバスを介してデータを移動させるという構造ではありません。この構造の最大の利点は、専用GPU搭載機では「VRAMにそもそも収まらない」モデルでも、Mac 上では別の状態になることです：

必ずしも速くはないが
まずは格納できる可能性が高いということです。つまり、Mac は最初から非常に硬い「VRAMの壁」にぶつかりにくいのです。これが、多くの人が Mac がローカルでの大規模言語モデル（LLM）において特に適していると感じる理由です。それは、「まずワークセット全体を同じメモリプールに詰め込めるか否か」という問題を解決してくれるからです。

しかし、ユニファイドメモリが高速を保証するわけではない

この部分は分けて考える必要があります。ユニファイドメモリは何を解決したのか？

専用GPUメモリとメインメモリの物理的な分離の問題を解決した
小容量のVRAMでは直接搭載できなかった多くのモデルに対応できるようになった
非常に煩雑な、デバイス間でのデータの往復移動の問題を解決したしかし、何が解決されていないのか？
大規模モデルの推論を「大量のメモリ読み出し」から別のものに変えていない
大規模モデルが突然帯域幅を消費しなくなるわけではない
すべての推論フレームワークが自動的にCUDAのような成熟したエコシステムを持つわけではないしたがって、Macの快適さとNVIDIAの大容量VRAMカードの速さは、同じものではありません。 Macはむしろ以下のようなものです：
機械が静かであること
総メモリが大きいこと
統一されていること
これまで搭載できなかった多くのモデルを、とりあえず動かすことができるようになったこと NVIDIAの大容量VRAMカードはむしろ以下のようなものです：
エコシステムが成熟していること
CUDAツールチェーンが完全であること
モデルとキャッシュをGPU内に留め込むことができれば、速度を上げやすいこと

なぜスピードを求めるのか、結局はNVIDIAのVRAM容量が重要になる

これは感情的な判断ではなく、ローカルにデプロイする過程で容易にたどり着く現実的な結論です。もしあなたが以下のようなものを追求しているなら：

ローカルアシスタントの常駐化
多回の長文対話
長いコンテキストウィンドウ
より高いトークン/秒 (token/s)
待ち時間を極力減らすことそれらの場合、結局はVRAM容量の大きなNVIDIA製GPUが重要になります。なぜなら、あなたが真に購入しているのは、モデルとキャッシュをできるだけ安定してGPU上に保持する能力だからです。 Macももちろん当てはまりますが、こちらは別の種類の要求に適しています：
大きなモデルを一度に搭載したい
速度は平均的でも良いが、ドライバや周辺機器の設定で手間をかけたくない
全体的な体験、消費電力、騒音を重視するこれら二つのアプローチはいずれも合理的ですが、解決しようとしている問題点が異なります。

Gemma 4 に戻る、私の最終判断

今回、Gemma 4 は、ローカルでオープンソースのモデルが、より真剣にハードウェアについて議論すべき段階に入ったと感じさせられました。しかし、モデルが強くなっても、物理法則まで緩むわけではありません。どれだけ強力な 31B でも、VRAM が不足すれば速度は落ちます。どんなに現実的な 26B A4B でも、コンテキストが長すぎれば負荷がかかります。 Mac のユニファイドメモリは快適ですが、それは単に「とりあえず動かす」のが容易になるだけであり、大容量の VRAM を持つ CUDA カードの速度を無償で提供してくれるわけではありません。そのため、結局やはりこの地味な結論になります：

速度を求めるなら、最優先は NVIDIA の大容量 VRAM です。
万全を期すなら、Mac のユニファイドメモリは確かに快適です。
3060 12GB のようなマシンで長期的に遊ぶのであれば、常に巨大なモデル（dense model）ばかりを気にするのではなく、26B A4B のようなアプローチの方が現実的です。この一連の記事は、ここまでで締めくくりとします。

参考資料

作成上の注記

元のプロンプト

$blog-writer Googleが1年ぶりにGemma4モデルをリリースしました。いつものように、ローカルデプロイメントを試します。使用するのはアップグレードされていないデスクトップPCに搭載されている3060 12GB NVIDIAグラフィックボードです。今回は初出陣でしたが、以前よく使っていたGemma3のアップグレード版が見つかりませんでした。しかし、類似のバージョンであるGemmaE4bというものがあるので、まずこれを検索して紹介してください。今回リリースされた全モデルについて、含まれる略語アルファベットがそれぞれ何を意味するのかを説明し、さらにオンライン上のGemma4に関する評価を検索してください。重要な点として、今回のGoogleによる更新でモデルのプロトコルが変更され、利用時の制限が緩和されました。最大の驚きは、私がよく使うテスト問題です。「C++コードを書いて、コンソールに五芒星を出力しなさい」というものでした。昨年の小規模パラメータのオープンソースモデルではこの問題をクリアできませんでしたが、Googleはこの回で成功させました。最初の回答は私の予想を完全に超えており、私の意図（トラップ）を理解していました。コンソールへの五芒星の出力は非常に厄介なため、直接アスキーアートとして文字列をハードコーディングし、コンソールに出力しました。これが原文です：「純粋なテキストのコンソール（Console）で数学的なロジックだけで正確な幾何学的構造を持つ五芒星を描画するのは非常に複雑である（座標変換やピクセル充填が関わるため）。最も古典的で視覚効果が高い方法は、アスキーアート（文字芸術）を使用することである。私が計算を強制的に要求した後も、それは成功しました。数学的な計算を通じて、五芒星を描画したのです。」以前はローカルでの翻訳タスクにGemma4をよく使用していました。現在のブログの多くの過去の記事の多言語版がこのようにして作られています。ローカルテストに使用したのは：gemma-4-26b-a4bモデルで、31bバージョンは本当に遅すぎます。しかし、レビューを見ると31bの効果は非常に良く、ランキングの成績も優れています。同時にフォーラムを閲覧し、私は「VRAMが不足している場合、モデルパラメータを上げると、生成トークンの速度が急激に低下する」ということに気づきました。なぜそうなるのか説明してください。Macではこの問題は発生しません。ユニファイドメモリを使用しているため、技術的な理由を説明してください。また、速度が必要な場合は、やはりNVIDIAのVRAM大容量グラフィックボードが必要です。Macのソリューションはバックアップにはなりますが、速度が出ません。今回の内容は多岐にわたるので、シリーズ記事に分割すべきか評価してください。

ライティングの骨子まとめ

第3編では、「なぜスピードが落ちるのか」と「Macが速さ＝ではない理由」の2つの論点のみを残し、前2編の内容への回帰的な説明は行わない。
まずVRAM（ビデオメモリ）の限界について述べ、次に非線形な速度低下について述べることで、前回版よりも論理の流れがスムーズになる。
MacとNVIDIAをそれぞれ異なる側面から語り分け、一方は「安定性重視」、もう一方は「速度重視」という形で対比させる。
結論ではハードウェアの判断のみに留め、シリーズ分割の理由付けは繰り返さない。

Googleが今回Gemma 4を公開した（2）

Wed, 08 Apr 2026 23:52:20 +0800

ランキングだけを見ると、一番心が動くのは間違いなく 31B です。しかし、実際にマシンを前にすると、やはりアップグレードされていない RTX 3060 12GB の方が、判断はすぐに変わります。どう言えばいいか、ローカルにデプロイするということは、最後に一番派手なものが勝つのではなく、長く一緒にいられそうなものを選ぶことなんです。私にとっては、今回まず試す価値があるのは 31B ではなく、26B A4B です。

前回の記事 GoogleがGemma 4を公開した件（一）：急いでローカルに動かす前に、モデル名とプロトコルを理解すべきでは、リリースとプロトコルについて説明しました。今回の記事ではローカルでの体験そのものに焦点を当てています。最後の記事では GoogleがGemma 4を公開した件（三）：VRAM不足でなぜ急落するのか、Macはなぜバックアップになり得るのに速くないのかを続けます。

なぜ先に「26B A4B」を試すのか

理由は実はかなり現実的、つまりハードウェアの制約によるものです。「31B」はもちろん強力で、公式ランキングやコミュニティからの初期フィードバックも非常に高いです。しかし、それを「RTX 3060 12GB」のようなマシンに載せると、問題はすぐに「どれだけ強いか」から「待つ価値があるか」へと変わってきます。モデルやキャッシュがシステムメモリに退避してしまうと、速度が急激に落ちてしまうことがあり、この件については第3弾で詳しく解説します。「26B A4B」は違います。総パラメータ数は「25.2B」ですが、実際にトークンごとにアクティブになるのは約「3.8B」程度です。平たく言えば、これは今回のGemma 4の中で、「ローカルユーザー向けに特別に用意された」モデルと言えます。ですから、もしあなたのマシンが私と同じような、コンシューマーグレードの古いグラボであるなら、判断はシンプルになります：

ランキングを見たいだけなら、「31B」を試す
本格的に長期でローカルに使いたいなら、まず「26B A4B」から始める

五芒星の問題、今回はついに誰かが私が罠を仕掛けていることに気づいた

私自身がずっと持っている、かなり原始的なテスト問題があります。モデルに C++ コードを書いて、コンソールに五芒星を出力させるというものです。

この問題は冗談のように見えますが、実際には結構厄介です。なぜなら、多くのモデルはこれを純粋な数学的な描画問題だと誤解し、座標系や三角関数、ループ処理などを持ち出してきてしまい、最終的にテキストコンソール上に、全く見づらい文字の塊を出力してしまうからです。

去年の小規模パラメータのオープンソースモデルの多くが、この点でつまずきました。

しかし、今回 Gemma 4 の最初の反応は、逆に私を驚かせました。すぐに理解したふりをするのではなく、制約条件を先に認識し、以下の判断を出してくれたのです：

純粋なテキストコンソール（Console）上で、正確な幾何学的構造を持つ五芒星を数学的なロジックだけで描画するのは非常に複雑です（座標変換やピクセル充填が関わってきます）。最も古典的で視覚的に効果的な方法は、ASCII Art（文字アート）を使用することです。

五芒星の問題、今回はついに誰かが私が仕掛けた罠を理解してくれた

端的に言うと、まず問題の背後にある環境的な制約を理解した点だ。コンソールはキャンバスではなく、文字グリッドもピクセルグリッドではない。先に「どうすれば安定して五芒星を出力できるか」を考え抜いてから、数学的な描画について語るべきだった。

そして、最初のバージョンではいきなりハードコーディングされた五芒星の文字列を提示した。この行動は非常に的確だ。推論を見せるためではなく、まず問題を正しく解くことを優先した。

さらに驚いたのは、それがさらに進んでいくことだった

単にASCIIアートで止まっていただけなら、この問題はトラップを認識したとしか言えない。私が高く評価したのは、その後も数学的な計算を要求し続けた際にも、それが失敗せず、むしろ幾何学的な関係性を文字のグリッド上にマッピングし、最終的に五芒星を算出した点だ。これは「コードを書ける」ということではなく、この問題が実際には二層構造になっていることを理解している証拠だと考える。

第一層：コンソール上で最も確実な答えは何か
第二層：もし計算をしなければならない場合、どのように幾何学の問題を文字のグリッド上に落とし込むか以前の多くのローカル小規模モデルは、最初から第二層に飛びつき、結局第一層ができていないことが多かった。Gemma 4 は今回、逆の手順を踏み、まず境界線を見極め、それからどう解くかを決定した。私はこの点の方が、単体のベンチマークスコアよりも価値があると思う。

今回のコーディング能力の向上は、「賢くなった」だけではない

この五角星の問題が使いやすいのは、単に文法を問うものではないからです。本当に試しているのは以下の点です：

出力環境を先に理解できるか
直感的な解法が不適切であることを認められるか
「最適な表示効果」と「ユーザーによる強制計算要求」の間を切り替えられるかこのような問題を正しく解けるということは、モデルが単にコードスニペットを補完するだけでなく、現実の制約を処理できる開発アシスタントらしくなり始めたことを示しています。だからこそ、私にとって Gemma 4 の第一印象は、去年の小規模パラメータのオープンソースモデル群よりも格段に良いのです。昨年の多くのモデルは、チャットができる、補完できる、なんとかこなせるレベルでしたが、このような少し境界線を感じさせる問題に直面すると、脆さが露呈しがちでした。今回、Googleはこの弱点を少なくとも補ってくれました。

この一文を翻訳すると、「Gemma 4 が全面的に引き継ぐ」と単純には言えない

あなたが以前指摘した点は非常に重要です。これまでローカルで翻訳を行う際によく Gemma を利用していましたよね。

この件は、Gemma 4 になると、実はそれほど直線的ではありません。なぜなら、Google は 2026 年 2 月に単独で TranslateGemma をリリースし、しかもそれは Gemma 3 のアーキテクチャをベースにしているからです。

これはどういう意味か？ということです。もしあなたがすでにローカルでの翻訳パイプラインを確立していて動いているなら、短期間で全てを Gemma 4 に切り替える必要はないかもしれません。特に、目的が非常に限定的で、単に安定した多言語変換だけを求めるシナリオにおいては、専用の翻訳モデルには依然として価値があります。

しかし、もしあなたが求めているのが、翻訳、質問応答、コード、一般的なテキストタスクなど、複数の用途を可能な限りカバーできるローカルモデルセットであるならば、26B A4B のようなより万能なアプローチの方がスムーズでしょう。

これが最も特化しているわけではないかもしれませんが、「とりあえず動く、十分なメインストリームモデルが欲しい」という現実的な選択肢に近いと言えます。

なぜ第2回で「31B」を褒め続けたくないのか

「31B」がダメだからというわけではない。むしろ、良すぎるからこそ、注意が逸れやすいのだ。ずっと「31B」のベンチマークスコアばかり見ていると、「強力なモデルは本当にすごい」という記事になりがちだ。しかし、ローカル環境で最も怖いのは、そういった謳い文句である。なぜなら、あなたが毎日使い続けるかどうかを決定するのは、ランキングではなく、以下の点だからだ：

起動が遅すぎないか
回答速度が著しく落ちないか
長いコンテキストを扱うとすぐに体験を台無しにしないか
自分自身のマシンで本当に支えられるか「3060 12GB」のようなマシンでは、これらの現実的な問題の方が、ランキングよりもずっと重要だ。そのため、第2回の締めくくりはシンプルにした。「31B」は見る価値があるが、「26B A4B」は使う価値がある。ローカルユーザーにとって、この二つの文は全くの別物なのだ。

私のローカルでの第一印象

今回の実測感触を一言でまとめると、それは以下の通りです。 Gemma 4 はついにシーンを考慮できるローカルモデルになり始めた。特に 26B A4B がそうですね。これはベンチマーク表を飾るためのモデルというよりは、古いマシンやコンシューマー向けのグラフィックボード、ローカルでの長期利用といった現実的な制約の下では、かえって真の主力選択肢のように感じられます。少なくとも今回の五角星テストに関しては、Googleは合格点を超えました。

参考資料

作成上の注記

元のプロンプト

$blog-writer Googleが1年ぶりにGemma4モデルをリリースしました。いつものように、ローカルでのデプロイを試します。使用するのはアップグレードされていないデスクトップPCに搭載されている3060 12GBのNVIDIAグラフィックボードです。今回は初出陣でしたが、以前よく使っていたGemma3のアップグレード版が見つかりませんでした。しかし、類似のバージョンであるGemmaE4bというものがあるので、まずこれを検索して紹介してください。今回リリースされた全モデルについて、含まれる略語アルファベットがそれぞれ何を意味するのかを説明し、さらにオンライン上のGemma4に関するレビューを検索してください。重要な点として、今回のGoogleの更新によりモデルのプロトコルが変更され、利用時の制限が緩和されました。最大の驚きは、私がよく使うテスト問題です。「C++コードを書いて、コンソールに五芒星を出力しなさい」というものです。去年の小規模パラメータのオープンソースモデルではこの問題をクリアできませんでしたが、Googleはこの回で成功させました。最初の回答は私の予想を完全に超えており、私の意図（トラップ）を理解していました。コンソールに出力する五芒星は非常に面倒なので、直接アスキーアート形式の文字列としてハードコーディングし、コンソールに直接出力しました。原文は以下の通りです：「純粋なテキストのコンソール（Console）で数学的なロジックだけで正確な幾何学的構造を持つ五芒星を描画するのは非常に複雑であるため（座標変換やピクセル充填が関わる）、最も古典的で視覚効果が高い方法はASCII Art（文字アート）を使用することです。私が計算を強制的に要求した後も、それは成功しました。数学的な計算を通じて、五芒星を描画することができました。」以前はローカルでの翻訳タスクにGemma4をよく使っていました。現在ブログにある多くの過去の記事の多言語版がこのようにして作られています。ローカルテストに使用したのは：gemma-4-26b-a4bモデルで、31bバージョンは本当に遅すぎます。しかし、レビューを見ると31bの効果は非常に良く、ランキングの成績も優れています。またフォーラムを閲覧していて気づいたのですが、VRAMが不足している場合、モデルパラメータを上げると生成トークンの速度が急激に低下します。この理由を説明してください。Macではこのような問題が発生しないのはなぜですか？ユニファイドメモリを使用する技術的な理由を説明してください。さらに、速度が必要な場合は、やはりNVIDIAの大容量VRAM搭載グラフィックボードが必要です。Macのソリューションはバックアップとしては機能しますが、速度が出ません。今回の内容は多岐にわたるので、シリーズ記事に分割すべきか評価してください。

ライティングの骨子要約

第2編はローカル体験のみに留め、第1編の総括や第3編のVRAM原理の説明は行わない。
まず「なぜ先に 26B A4B を実行するのか」という明確な判断を提示し、その後で五芒星テストを展開する。
五芒星の問題が主軸となるのは、ベンチマークスコアよりもコーディングシナリオにおける限界点をよりよく示せるからである。
翻訳タスクは独立したセクションとして扱い、Gemma 4 が全ての旧プロセスを線形的に引き継いでいるという印象を避ける。

Googleが今回Gemma 4を公開した（1）

Wed, 08 Apr 2026 23:48:20 +0800

初日に私がやりたかったことはとてもシンプルでした。Gemma 3 に対応するアップグレード版を見つけて、まずダウンロードして動かしてみることです。しかし、全体をざっと見ていくと、少し戸惑いを覚えました。以前慣れていた 4B / 12B / 27B という命名規則がなくなり、代わりに E4B、26B A4B、31B といったものが現れたのです。どう言えばいいか、今回Googleが真に変わったのは、単にモデルのサイズだけではなく、「この一連のモデルをどう理解すべきか」という部分まで変わってしまったからです。

この記事群は3つの記事に分けて書きました。現在の記事では、リリース情報、モデル名、プロトコルを明確に説明します。次の記事では Googleが今回Gemma 4を公開した（2）：RTX 3060 12GBでローカル実行してみた、真の現実的なのは26B A4B を書きます。そして最後の記事では Googleが今回Gemma 4を公開した（3）：VRAM不足でなぜ急落するのか、Macはなぜバックアップになり得るのに速くないのかで締めくくります。

まず、今回具体的に何がリリースされたのかを明確にしましょう

昨年の Gemma 3 は 2025年3月12日にリリースされ、今回の Gemma 4 は 2026年4月2日と、確かに約1年空いています。しかし、今回は「27Bの次は何だろう」という考え方で探すのはやめましょう。公式が提示した主要な4つのサイズは、もはや単に総パラメータ数で区分けされているわけではありません。 | E2B | Dense | 2.3B effective，5.1B 含 embeddings，128K context | デバイス側、超軽量ローカル |

今回、結局何を発行したのかを明確にする

モデル名	構造	主要な数値	代表的なユースケース
`E4B`	Dense	有効パラメータ 4.5B、埋め込み込み含む 8B、コンテキスト長 128K	元の 4B の小型モデルをメインラインとして展開

今回到底发布了什么说清楚

モデル名	構造	主要な数値	代表的なユースケース
`26B A4B`	MoE	合計 25.2B、アクティブ約 3.8B、コンテキスト 256K	コンシューマー向けGPU、ローカルデプロイメント、品質と速度の両立

まず、今回具体的に何を出したのかを明確にする

モデル名	構造	主要な数値	代表的なユースケース
`31B`	Dense	30.7B dense、256K context	最高性能の追求、ランキングでの優位性、より安定した品質

今回、結局何を出したのかを明確にする

表面だけを見ると、今回のネーミングはより混乱していると感じるかもしれません。しかし実際は混乱しているのではなく、Googleが意図的に3つの異なるアプローチに分割しているのです：

小規模モデル・デバイス側向けに E2B / E4B を提供
ローカルプレイヤー路線として 26B A4B を提供
品質と上限を重視した路線として 31B を提供これが、多くの人が最初に「以前の馴染んだアップグレードパスが途切れた」と感じる理由です。アップグレード版を提供していないわけではなく、Googleはもはや総パラメータ数という単一の次元だけで製品を売りたいわけではないのです。

「E」と「A」は今回、装飾文字ではありません

このモデル名の中で、最も誤解を招きやすいのが E4B と A4B です。 E2B や E4B に含まれる E は、公式では effective parameters（実効パラメータ）を指します。これら2つのモデルは Per-Layer Embeddings を使用しているため、総パラメータ数と真の有効パラメータ数が同じ基準ではありません。平たく言えば、Googleは「これは過去のような『単なる 4B の密なモデル』ではない」と注意喚起しています。一方、26B A4B に含まれる A は active parameters（アクティブパラメータ）を指します。総容量は 25.2B ですが、各トークンで実際に活性化するのは約 3.8B です。これがMoE（Mixture of Experts）の鍵であり、モデル全体のサイズは大きいものの、実行時に実際に計算に参加する部分はかなり小さいということです。そのため、この2つの名前はどちらも「4B」を含んでいますが、その意味合いは全く異なります。

E4B は小規模モデルのメインラインです。
26B A4B は大規模なMoEであり、ローカル推論時には「アクティブな規模が約 4B 程度」というイメージに近いです。この命名規則は当初は確かに不自然ですが、過去のものよりも実際のデプロイ体験により近くなっています。

以前 Gemma 3 を使っていた場合、今回どういう対応関係で探せばいいか

私が思うに、この世代で最も誤解しやすいのは、これを Gemma 3 の線形なアップグレードだと捉えてしまう点です。

使用する習慣から考えると、だいたい以下のように理解できます：

これまで 4B で軽いタスクを動かしていた人は、まずは E4B を見てください。
これまで 27B でモデルの限界値を見ていた人は、今度は 31B を見てください。
これまでコンシューマー向けのグラボで「十分強力だけど、完全に動かせなくなるほどではない」というバランス点を探していた人は、重点的に 26B A4B を見てください。

この部分を先に整理しておかないと、後からローカルにデプロイする際に非常に迷いやすいです。「いつものアップグレード版がないな」と文句を言いながら、実際自分に合っているモデルを見逃してしまう可能性があります。

今回最も価値のあるアップデートは、実はパラメータではない

今回「ようやく腑に落ちた」と感じさせたのは、ランキングではなくプロトコル（ライセンス）でした。以前のバージョンの Gemma の利用規約が全く使えないわけではありませんが、ずっとどこか引っかかる部分がありました。特に以下のようなことを気にされている場合：

再配布
蒸留や二次加工を行う
モデルを自社の製品ラインに組み込む
商用展開を行うといった場合、常にライセンス条項内の通知（notice）、下流利用の制限、付帯する契約などをどう処理すべきかを確認する必要がありました。 Gemma 4 が今回直接 Apache 2.0 に変更されたことで、状況が非常にクリアになりました。核となるメッセージは極めて明確です：
商用利用が可能である
改変が可能である
再配布が可能である義務は主に、ライセンス、通知（notice）、改変の説明といったオープンソースの世界で馴染み深いものに留まるというものです。つまり、Googleが今回単にモデルをオープンソースにしたのではなく、「皆が安心して使えるかどうか」という点まで含めて整備してくれたのです。

コミュニティからの初期評価は、基本的に2つのラインに集約される

最初の週の口コミだけを見ると、大まかに2つの声があります。

1つ目のラインは、「31B は確かに実力がある」というものです。公式が発表したスコアは非常に強力です。Arena AI のテキストランキングでは、31B がリリースされた時点でオープンソースモデルの上位にランクインし、LiveCodeBench v6 でも Gemma 3 27B よりかなり向上しています。多くの人が最初に抱く感想は、「このサイズでこれだけの性能が出せるのは、期待を上回っている」というものです。

2つ目のラインは、「26B A4B はローカルユーザーのための生命線のようなものだ」というものです。一見して最も華やかなフラッグシップモデルというわけではありませんが、非常に現実的です。特にデータセンターではなく、コンシューマー向けのグラフィックボードやワークステーション、さらには古いマシンで動かす場合、ローカルでの体験はむしろこのラインに落ち着きやすいのです。

もちろん、最初の口コミには非常に現実的な前提があります。それはエコシステムがまだ追いついている最中だということです。テンプレート、量子化、推論フレームワーク、フロントエンドツールなど、多くのものがまだ完全に追いついていません。そのため、現段階で目にするレビューは、以下の2つのレイヤーに分けて見るのが最善です。

モデル本体: 今回は確かに大きな進歩があった
ローカル体験: 今後もツールの成熟度に影響され続けるだろう

第1回の結論について

単に今回のGoogleが何を発表したのかを知りたいだけであれば、一言で十分です。「Gemma 4」は、「小さいものから大きいものまで並べる密度の高いモデル」という古い考え方ではなく、デバイス側、ローカルデプロイ、品質の上限という3つの道を分離しました。「E4B」、「26B A4B」、「31B」と名前は奇妙ですが、背後にあるのは非常に現実的なデプロイメントの分業です。しかし、もし私に今回の最大の変化は何だと尋ねられたら、やはりこの判断になります。パラメータでも、ベンチマークスコアでもなく、Googleがようやく「Gemma 4」を皆がより安心して使えるオープンソースライセンスに組み込んだことです。この一歩こそが、表の数字以上に重要です。次の記事では、発表会の論調は語らず、直接ローカルマシンに戻ります。やはりアップグレードされていない「RTX 3060 12GB」を使い、なぜ私が最初に注目したのは「31B」ではなく「26B A4B」だったのか、という点です。

参考資料

作成上の注記

元のプロンプト

$blog-writer Googleが1年ぶりにGemma4モデルをリリースしました。いつものように、ローカルでのデプロイを試します。使用するのはアップグレードされていないデスクトップPCに搭載されている3060 12GBのNVIDIAグラフィックボードです。今回は初出陣でしたが、以前よく使っていたGemma3のアップグレード版が見つかりませんでした。しかし、類似のバージョンであるGemmaE4bというものがあるので、まずこれを検索して紹介してください。今回リリースされた全モデルについて、含まれる略語アルファベットがそれぞれ何を意味するのかを説明し、さらにオンライン上のGemma4に関するレビューを検索してください。重要な点として、今回のGoogleによる更新でモデルのプロトコルが変更され、利用時の制限が緩和されました。最大の驚きは、私がよく使うテスト問題です。「C++コードを書いて、コンソールに五芒星を出力しなさい」というものです。昨年の小規模パラメータのオープンソースモデルではこの問題をクリアできませんでしたが、Googleはこの回で成功させました。最初の回答は私の予想を完全に超えており、私の意図した「罠」を理解していました。コンソールでの五芒星の出力は非常に厄介なので、直接アスキーアート（文字）としてハードコーディングし、コンソールに直接出力しました。原文は以下の通りです：「純粋なテキストのコンソール（Console）で数学的なロジックだけで正確な幾何学的構造を持つ五芒星を描画するのは非常に複雑であるため（座標変換やピクセル充填が関わる）、最も古典的で視覚効果が高い方法はアスキーアート（文字芸術）を使用することです。」私が計算を強制的に要求した後も、それは成功しました。数学的な計算を通じて、五芒星を描画することに成功したのです。以前はローカルでの翻訳タスクにGemma4をよく使っていました。現在ブログにある多くの過去の記事の多言語版がこのようにして作られています。ローカルテストに使用したのは：gemma-4-26b-a4bモデルで、31bバージョンは本当に遅すぎます。しかし、レビューを見ると31bの効果は非常に良く、ランキングの成績も優れています。同時にフォーラムを閲覧し、私は「VRAMが不足している場合、モデルパラメータを上げると、生成トークンの速度が急激に低下する」ということに気づきました。なぜそうなるのか説明してください。Macではこの問題は発生しません。統一メモリを使用しているため、技術的な理由を説明してください。また、もし速度が必要な場合は、やはりNVIDIAのVRAM大容量のグラフィックボードが必要です。Macのソリューションはバックアップにはなりますが、速度が出ません。今回の内容は多岐にわたるので、シリーズ記事に分割すべきか評価してください。

ライティングの骨子まとめ

第1の記事では、「今回具体的に何がリリースされたのか」と「プロトコルがなぜ重要なのか」を明確に伝えることに専念し、ローカル体験に関する話題は取り上げないようにする。
モデルラインナップの説明は、まずモデル群を分解してからアルファベットの意味を説明するという順序にし、前回のバージョンよりも論理的な流れを重視する。
プロトコルに関する部分は、「今回緩和されたのはパラメータではなく、利用制限である」という判断軸を維持する。
コミュニティの評価については、まとめに留め、ローカル体験に関する記述は過度に盛り込まないようにする。

AIがブログを書くという件は、結局エンジニアリングにする必要がある（三）

Fri, 03 Apr 2026 21:06:02 +0800

倉庫の構成を一周確認した結果、逆に確信したことがあります。このシステムは、単体のモデルがどれだけ強力かではなく、どのレイヤーにコストを負わせるべきか、という点にかかっているということです。

最も明白なシグナルは、現在有効な published.runtime.json が依然として 2026年4月2日に生成された minimax-m2 であることです。しかし、2026年4月3日16:38の 5f17088 は、blog-style-suite のデフォルトプロバイダーをローカルの LM Studio 内の gemma-4-26b-a4b に切り替えています。これは一見すると前後で矛盾しているように見えますが、実はそうではありません。むしろ、このパイプラインに分業が始まったことを示しています。

この記事群はここまでで、最初の2本で境界線を描きました。第1回では、blog-writer がなぜ生まれたのかを語り、第2回では、blog-style-suite がどのようにスタイル学習とトークンコストを分離したのかを語りました。そして最後のこの記事では、最も現実的な問題に焦点を当てます。ローカルモデル、オンラインモデル、Minimax は、結局どのワークステーションに置くべきなのか、という点です。

スタイルデータでのトレーニングは、すべてのステップでオンラインモデルを焼く価値はない

スタイルデータというものは、真剣に取り組むと、トークンがすぐに現実的な問題になります。やりたいかどうかではなく、役割分担をしないと、このシステム全体が長く動きません。以前最も陥りがちだった誤解は、一つのオンラインモデルにすべての作業を任せてしまうことでした。

過去記事のクロール
スクリーニングの実施
分類を行う
スコアリング
サンプルの抽出
スタイルの調整（トーン合わせ）
そして最後に原稿を書くこのように行う最大の問題は、「モデルが十分強力でない」ことではなく、すべてのステップで同じコストを消費してしまうことです。今振り返ると、真に合理的なアプローチは逆から考えるべきです。どのステップはオンラインで行う必要があるのか、どのステップは可能な限りローカル化すべきなのか、さらにはモデルに任せるべきではないステップがあるのか、という点です。この境界線が不明確なままだと、どれだけ強力なモデルを導入しても、結局は本来前処理で対応できたはずの作業を繰り返すだけになってしまいます。

ローカルモデルは「汚い作業」「重労働」、そして「試行錯誤の繰り返し」に適している

私は今や、ローカルモデルを本番環境における「体力層（ワークホース）」として定義するようになりつつあります。必ずしも最強である必要はなく、毎回最も洗練されているわけでもありませんが、以下のタスクを担うのに特に適しています：

何度も実行する構築プロセス
スタイルデータの複数ラウンドにわたる圧縮実験
設定変更後の再スキャン
既存の構造に対する低リスクな再計算これらの作業には共通点があります。それは単発で価値が極めて高いことではなく、繰り返し実行する必要がある、試行錯誤を許容できる、そしてできれば毎回高額なコストを払う必要がないという点です。現在、scripts/blog-style-suite/config.json は lm-studio-gemma4 に切り替わっており、これ自体が判断が変わっていることを示しています。ローカルの gemma がオンラインモデルより必ずしも強いわけではなく、むしろ本番環境のこのパイプラインは、「実行可能か」「頻繁に実行できるか」「繰り返し変更できるか」を優先し始めたのです。これは、私が以前書いた弱モデルに無理に高度なタスクを割り当てないと同じ論理に基づいています。ローカルモデルが複雑な記事全体をゼロから書き上げるのに適しているとは限りませんが、**「汚い作業」「重労働」「バッチ処理」**を受け持つには非常に適しています。スタイルデータの前処理は、元々このようなタスクに近いです。

オンラインモデルは「仕上げ」に向いており、「全てをこなす」のには向かない

ローカルモデルがプロダクション側に向いているからといって、オンラインモデルに価値がないわけではありません。オンラインモデルが真価を発揮するのは、まさに最後の「仕上げ（クロージング）」の部分です。例えば：

最新の情報に基づいて事実を補完する
より大きなコンテキストの中で論証を整理する
ネットワーク接続による検証が必要な時間的制約のある情報を処理する
すでに準備された構造化されたスタイルアセットを、公開できる記事に仕上げるこれらの動作は、表現の質、事実の統合、コンテキスト理解といった要求が高いため、オンラインモデルがここに配置される方が価値が高いのです。つまり、強力なモデルはまるで総組立ラインの最後の工程のようなものです。前工程まで手を広げられるわけではありませんが、最初から最後まで全てを処理させると、コスト構造がすぐに崩れてしまいます。これが、blog-writer が設計上、投稿済みデータである published.runtime.json のみを読み取り、原稿作成時にプロバイダーを切り替えたり、スイートディレクトリ全体を再走査したりしない理由です。消費側（クライアント側）が軽いほど、より強力なモデルに記事の「仕上げ」に集中してもらうのが最適なのです。

Minimax の意味は、単にプロバイダーを増やしただけではない

多くの人は「Minimax」を見ると、「またモデルを一つ追加しただけか」と最初に思いがちです。

しかし、そうは思いません。

Minimax が真に価値があるのは、「複数のプロバイダーからの出力を、単一の公開契約（スキーマ）で消費できる道筋を作った」点にあります。

2026年4月2日 10:18 の 9f15199 で blog-style-suite がマルチモデル構成に変更され、出力がプロバイダーごとに分離されました。その後も README やランタイムの構造では、常に一つのことを強調しています。それは、スイートは多くの結果を生成できるが、実際に有効なのは人間が選んだ published.runtime.json だけだということです。

この境界線（バウンダリー）が非常に重要です。

なぜなら、一度この境界が明確になると、Minimax の役割は「執筆プロセスに組み込まれなければならないもの」から、以下のようなものへと変わるからです。

本番環境での比較に参加できる
ランタイム版を生成するために使える
ローカルモデルの成果物と横断的に比較できる
最終的に人間がどのバージョンを公開するかを決定する

これにより、プロバイダーは「システムへの依存」から「交換可能な部品」へと変わりました。

これが、このエンジニアリングスタックにおける Minimax の最も興味深い意義だと私は感じています。それは、エンドツーエンドの全工程を支配するために存在するのではなく、「このリンク（プロセス）がインターフェースをきれいに受け止めているかどうかを検証する」ために存在しているのです。

真の役割分担は、モデルの強さによるのではなく、タスクの種類によるべき

私は今、非常に古風だが実用的な分類法をより支持しています。

ルールとハード制約

ローカルスクリプトに任せる。 scanner.py、write_post.py、write_post_series.py のような決定論的なツールで解決できることは、モデルに混ぜ込ませないこと。

スタイルデータ生成

ローカルモデルまたはコストの低いプロバイダーを優先します。ここでの最も重要なのは、単発の出力が最も華やかであることではなく、再現性、試行錯誤可能性、キャッシュ可能性です。

最終原稿作成と事実の締めくくり

より長いコンテキストの統合、表現の収束、およびインターネットからの事実補完に適したモデルに任せる。このレイヤーこそが、オンラインモデルにお金をかける価値がある場所だ。このように分解すると、以前は悩んでいた問題も実はそれほど複雑ではないことがわかる。毎日「どのモデルが最強なのか」を議論する必要はなく、「このタスクはどのレイヤーに属するか」と尋ねるだけでよいのだ。

結局、最も価値があるのはモデルではなく境界が明確なことである

第3編はここまでとさせていただきます。 blog-writer と blog-style-suite という一連のものは、進化する過程で、誰を接続したか、誰に入れ替えたか、どのプロバイダーを試したかといった点よりも、最も価値があるのは境界が徐々に明確になってきたことです。

blog-writer は消費側を担当
blog-style-suite は生成側を担当
published.runtime.json が公開の場所である
ローカルモデルは繰り返し実行する面倒な作業や重い作業に適している
オンラインモデルは最後の仕上げに適している
Minimax のようなオンラインプロバイダーは、システムの中枢というよりも交換可能な部品のようなものだ。境界が明確になると、ワークフロー全体がスムーズになる。一つのモデルパッケージだけで全てを解決できると期待したり、全てのステップを最も高価なレイヤーに積み重ねたりすることはなくなる。結局のところ、これはモデルを選ぶように見えて、実際には異なる種類のタスクに作業場所を割り当てているだけなのだ。端的に言えば、単一の点が強いのはもちろん良いことだ。しかし、長期的に見ると、境界が明確であることは、単一の点よりも強く、より重要であることが多い。

参考資料

リポジトリコミット：9f1519967981c5eef7bd1eb407b0406ac542ebd0
リポジトリコミット：5f17088391ee858b88fc50df884bc0103ff0b3c1
リポジトリファイル：scripts/blog-style-suite/config.json
有効なランタイム：.agents/data/blog-writing/published.runtime.json
関連旧記事：重度AIプログラミングの日々
関連旧記事：結局は国産モデルに戻る
関連旧記事：弱モデルに無理な強活を適用しない

作成上の注記

元のプロンプト

$blog-writer 今回の内容は多いため、シリーズ記事に分割しました。昨年も多くの原稿が大規模言語モデルによって書かれました。その時は、自分でアウトラインや質問リストを作成し、AIに原稿を生成させ、内容をローカルのmdドキュメントにコピーし、ヘッダー情報、タグ情報などを記入して投稿するという流れでした。最近はCodexを多く使用し、Codexのインターネット検索能力が非常に強力だと気づきました。そこで、これらの作業を自動化するスキルを作成できないかと考えたのが、skill blog-writerの初稿です。さらに、AIに以前の記事のスタイルを学習させたいと考えたため、blog-writerの実行時にトークンを大量に消費するという問題が発生しました。その後、私はblog-writerに対して複数のバージョンの最適化を行いました。データモジュールとデータ生成モジュールに分割したのですが、元々のデータ生成モジュールは独立したスキルとして存在していました。書き進めるうちに、Pythonプロジェクトとしてまとめた方がより適していることに気づき、それがblog-style-suiteの誕生につながりました。さらに、スタイルデータの学習もトークンを消費することが多いため、ローカルの大規模言語モデルを使用することにしました。ローカルの大規模言語モデルとオンライン版の違いを比較したいと考えたため、minimaxとも連携させました。blog-style-suiteとblog-writerの進化の歴史は、gitのコミット履歴から分析できます。ついでに、ローカルのblog-writerやblog-style-suiteのコードを基にして、設計思想（どのようにトークン節約を実現したか、データ構造をどう設計したか、核となる設計思想）について説明することも可能です。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。

ライティングの骨子まとめ

第3編では、アーキテクチャの説明を繰り返すのではなく、「モデルの役割分担」という現実的な問題に焦点を当てて締めくくる。
冒頭で、現在のリポジトリにある published.runtime.json が minimax-m2 や config.json からローカルの gemma4 に切り替わっているという事実を直接提示し、前置きを減らす。
重要なのは、誰がより優れているかを証明することではなく、なぜ異なるタスクを異なるコストレイヤーに割り当てるべきなのかを説明することである。
Minimax を「交換可能なプロバイダー」の位置で語るのは、その意義をモデルのベンチマークリストではなく、エンジニアリングの境界線に引き戻すためである。
最後に、「単一の最高性能よりも明確な境界線の方が重要である」という全体的な判断に戻り、一連の記事を締めくくる。

AIがブログを書くという件は、結局エンジニアリングにする必要がある（2）

Fri, 03 Apr 2026 21:02:02 +0800

トークンが十分にある場合、最も手っ取り早い方法は非常に粗暴ですが、過去の記事をそのままモデルに投入し、自分で学ばせることです。

問題は、この方法はたまに1記事書くのには適していますが、繰り返し書くのには適さないということです。もしブログ執筆を長期的なワークフローとして真剣に取り組むのであれば、「生データ（歴史的な文章）」というアプローチは、すぐに「高コストで散漫」になってしまいます。

この一連の記事では、主軸が移りました。前回の記事 AIによるブログ執筆は、結局エンジニアリングにする必要がある（1）：blog-writerがなぜ生まれてきたかでは、消費側（コンテンツの利用側）の自動化について取り上げました。この記事からは生産側、つまりスタイルデータがどのように生成され、どのように圧縮され、どうすればトークンを無駄に燃焼させないかという点について語ります。次の記事では AIによるブログ執筆は、結局エンジニアリングにする必要がある（3）：ローカルモデル、オンラインモデル、そしてMinimaxの役割分担を続けます。

最初の一番自然な発想は、過去の記事をそのまま与えることだ

この道筋は本当に自然すぎる。モデルにあなたの書き方を学ばせたいのなら、最も直感的な方法はもちろん、古い記事を餌として与えることだ。できれば、過去のブログの中で自分自身に一番近いと感じるものを詰め込んで、自分で要約させるのがベストだ。一度きりのタスクを見る限りでは、これを行っても問題はない。むしろ多くのケースで効果は良い。コンテキストが十分長く、モデルが十分に強力で、過去の記事が十分にあれば、スタイルを習得することは確かに可能だ。しかし、問題は「この記事を書き上げられるか」ではなく、「次の記事、その次の記事も、これを繰り返さなければならないのか」ということなのだ。毎回古い記事のバッチを再投入することは、いくつかの非常に現実的な副作用をもたらす：

同じ材料が繰り返しコンテキストを占有する
トークン消費量が執筆回数にほぼ線形に増加する
モデルが見るノイズが増えすぎ、真に有用なシグナルが逆に希釈されてしまう
執筆という動作とスタイル維持という動作が完全に結びつき、どちらも軽々しくできなくなるつまり、トークンが潤沢な時は、生で与えるのはもちろん可能だ。しかし、工学的な観点から常にこのようにすることはできないのだ。

これがデータモジュールとデータ生成モジュールを分離しなければならない理由です

後になって考えたところ、核心は一言に尽きます。「消費側」と「生産側」を分けることです。

blog-writer が担当しているのは消費側です。これは、すでに公開されたランタイムを読み取り、固定の契約に従って記事を書き出すだけです。

一方、スタイルデータのスキャン、フィルタリング、スコアリング、圧縮、プロバイダー比較などは、別の生産側のパイプラインに置かれるべきでした。つまり、後から作られた blog-style-suite のようなものです。

gitの履歴を見れば、この転換は非常に明確です。

2026年4月1日 21:47 のコミット 84a06b5 で、元の blog-style-maintainer スキルがリポジトリレベルのCLIツールに置き換えられたことが明記されています。この動きは物事を物語っています。なぜなら、scan/build/rebuild があり、出力ディレクトリがあり、リカバリ機構がある時点で、それはもはや単なる「スキル」ではなく、通常のPythonプロジェクトのように見えてくるからです。

さらに2026年4月1日 23:05 のコミット 9e92b8e では、blog-style-suite が scanner.py、builder.py、compressor.py といったモジュールに分割され続けました。この段階に至ると、考え方はすでに非常に工学的なものになっています。

scanner.py: ディスクから記事をスキャンし、構造化された特徴を抽出する役割
builder.py: スコアリング、選別、キャッシュ、ランタイムアセンブリの役割
compressor.py: モデルが関与するいくつかの圧縮ステップを担当する

これは、単にスーパープロンプトを一段書くというアプローチとは、全く異なる考え方なのです。

トークンを節約するのは、玄学ではなく前処理とバッチ化によるもの

このエンジニアリングセットで真に価値があるのは、2026年4月2日19:41のbc4b950だと思います。

あのコミットは非常に率直なことを述べていました。AIの呼び出し回数が約「2000回」から、各プロバイダーで最大「5回」に直接削減されたのです。

どうやって達成したのか？それは「プロンプトをより賢くする」のではなく、事前に処理すべきものを前もって実行することによるものです。

現在のblog-style-suiteのフローは非常に明確になりました：

scanフェーズは純粋にヒューリスティックであり、AI呼び出しは0回。
buildフェーズではまずヒューリスティックなスコアリングを行い、これもAI呼び出しは0回です。
その後、technical / finance / essay / toolingの4つのレーンそれぞれで1回のバッチ選別とラベリングを行います。
最後に作者スタイルの圧縮を1回行います。

これを計算すると、コールドスタートでも最大5回の呼び出しに抑えられます。

さらに重要なのは、この5回が各記事に分散しているのではなく、すでに前処理された高価値な要約材料に集中している点です。

これが前処理が真にトークンを節約する部分です。単に数文字を減らすのではなく、「記事ごとに呼び出す」から「フェーズごとに集中的に呼び出す」というパラダイムシフトなのです。

その後は、キャッシュも整備されました。 builder.pyにはレーンのバッチフィンガープリントがあり、プロバイダーのチェックポイント復元機能があり、さらにローカルモデルのコンテキストのためにreview_pool_per_lane = 12のような縮小化が行われています。少しデータを変更しただけで、パイプライン全体を再実行する必要がありません。

こうした設計は一見派手ではありませんが、一つ一つが非常に実用的です。なぜなら、それらはすべて「同じトークン群を二度と無駄に燃焼させない」という問題を解決しているからです。

現在のデータ構造は、本質的に真に有用なシグナルを圧縮しているものだ

この構造を分解すれば、データ構造も整理されるだろう。私は今、これを3層として理解する方がより良いと感じている。

第1層：`scan.json`

これは共有の原料です。ここには、記事のパス、タイトル、日付、カテゴリ、タグ、冒頭段落、クロージングスタブ、見出し、スクリーニング結果、レーン分類といった構造化されたシグナルが格納されています。これは blog-writer に直接渡されるものではなく、生産側でさらに加工するためのものです。

第2層：`{provider}.source.json`

これはプロバイダーレベルのチェックポイントです。共有された原料に加え、スコアリング結果、レーン選択、フィンガープリント、キャッシュステータスといった中間状態が追加されています。つまり、「加工過程の中間製品」のようなものであり、復元可能、再利用可能、中断して再開できる点が重要です。

第3層：`{provider}.runtime.json` と `published.runtime.json`

これが消費側が真に気にする完成品です。ここには以下のものが保持されています：

author_style
lanes
samples
writer_guide つまり、元々大量にあった過去の記事群を、そのまま利用できるランタイムスタイルアセットとして圧縮したものになります。特に published.runtime.json という公開用のファイルが重要です。blog-writer はこのファイルのみを読み取り、content/post を再スキャンしたり、suite ディレクトリ内の全プロバイダーの完全なイメージを気にする必要がなくなります。この境界線が引かれることで、消費側は軽量化します。執筆モデルが見るのは、もはや原始的な古い記事の山ではなく、すでに前処理された高密度のシグナルとなるのです。

すべてのことをモデルにさせるべきではない

最近、このエンジニアリングにおいて最も正しい判断は、「モデルを多く追加すること」ではなく、「モデルに任せるべきでないこともモデルに投げ渡さないこと」だと感じています。

以下のようなことは、ローカルルールで処理する方が適しています：

frontmatter の解析
冒頭段落の抽出
見出し（headings）の抽出
本人/転載/モデルによる署名の判断
blockquote の比率チェック
 や埋め込みプロンプト、本文の長さといったハードルルールでのフィルタリング

これらの作業をモデルにやらせることは不可能というわけではなく、単に無駄です。

モデルがより適しているのは、曖昧さやトレードオフを含む部分です。例えば、「あるレーンの中でどの記事が現在の論調をよりよく代表しているか」、あるいは「高評価の記事から著者のスタイルタグを抽出する」といった作業です。

そのため、blog-style-suite が真に価値があるのは、「トークンを節約できる」という点だけではなく、人間、ルール、モデルのそれぞれが担当すべき役割を再定義した点にあるのです。

前処理はトークンを節約するためではなく、執筆作業を持続可能にするためである

第2回の結論について、もっと直接的に伝えたい。トークンが潤沢な時は、過去の記事をそのまま使うのはもちろん問題ない。むしろ、本当に1〜2本だけ書くなら、頭を使う量が少ないかもしれない。しかし、このことを長期的なワークフローにしたいと思うなら、前処理は選択肢ではなくなる。なぜなら、前処理をしないと、執筆モデルは毎回古い素材を見直さなければならず、スタイルの維持と記事生成が常に混ざり合ってしまうからだ。 blog-style-suite の意味するところは、このごちゃ混ぜになっているものを分解することにある。システムに見せるためでも、プロジェクト名を増やすためでもなく、blog-writer が軽快に、安定して、「執筆」という一つの動作だけに集中できるようにするためなのだ。ここまで来ると、次のステップの問題は自然とついてくる。すでに生成側が独立した以上、このコストをどのモデルに負わせるべきなのか？ローカルモデル、オンラインモデル、Minimax はそれぞれどの工程に立つべきなのか？この件については、次回の記事 AIでブログを書くという行為は、結局エンジニアリングにする必要がある（三）：ローカルモデル、オンラインモデル、そして Minimax の役割分担で触れることにする。

参考資料

リポジトリコミット：84a06b5dc743f2e9bc6e788d53496a1261bc63ae
リポジトリコミット：9e92b8e6a15d03e6392aff7f3b2dcb0992fe5043
リポジトリコミット：bc4b950cbb13e37d1fdb16a9d23325cfefa6f90e
リポジトリファイル：scripts/blog-style-suite/README.md
リポジトリファイル：scripts/blog-style-suite/style_pipeline/scanner.py
リポジトリファイル：scripts/blog-style-suite/style_pipeline/builder.py
リポジトリファイル：scripts/blog-style-suite/style_pipeline/compressor.py
有効なランタイム：.agents/data/blog-writing/published.runtime.json

作成上の注記

元のプロンプト

$blog-writer 今回の内容は多いため、シリーズ記事に分割しました。昨年も多くの原稿が大規模言語モデルによって書かれました。その際は、自分でアウトラインや質問リストを作成し、AIに原稿を生成させ、内容をローカルのmdドキュメントにコピーし、ヘッダー情報、タグ情報などを記入して投稿するという流れでした。最近はCodexを多く使用し、Codexのインターネット検索能力が非常に強力だと気づいたため、これらの作業を自動化するskillを作成できないかと考えました。これがskill blog-writerの初稿の誕生につながりました。また、AIに以前の記事のスタイルを学習させたいと考えたため、blog-writerの実行時にトークンを大量に消費するという問題が発生しました。その後、私はblog-writerに対して複数のバージョンの最適化を行いました。データモジュールとデータ生成モジュールに分割したのですが、元々のデータ生成モジュールは独立したskillでした。書き進めるうちに、Pythonプロジェクトとしてまとめた方がより適していることに気づき、それがblog-style-suiteの誕生につながりました。さらに、スタイルデータの学習もトークンを消費することが多いと感じたため、ローカルの大規模言語モデルを使用することにしました。ローカルの大規模言語モデルとオンライン版の違いを比較したいと考え、minimaxを組み込みました。blog-style-suiteとblog-writerの進化の歴史は、gitのコミット履歴から分析できます。ついでに、ローカルのblog-writerやblog-style-suiteのコードを基にして、設計思想（どのようにトークン節約を実現したか、データ構造をどう設計したか、核となる設計思想）について説明することができます。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。

ライティングの骨子（要約）

本稿では、執筆という行為からデータエンジニアリングへと焦点を移し、「なぜモジュール化する必要があるのか」という核心的な問いに答えることを目指した。
冒頭で「生きた歴史の記事をそのまま使える」と認めることで、後続の分割理由に説得力を持たせている。
scan.json、source.json、runtime.json の三層構造を重点的に展開し、単なるアーキテクチャの説明に留まらないようにした。
bc4b950 を中間地点の転換点として配置した。なぜなら、「約2000回から5回へ」という変化が前処理の価値を最も明確に示すためである。
最後に、消費側と生産側を再分離し、次回の記事で扱うモデルの役割分担への布石を打った。

AIがブログを書くという件、結局は工学的なものにする必要がある（1）

Fri, 03 Apr 2026 20:58:02 +0800

昨年、多くの AI に関する記事を書きました。あの頃の最も手間のかかるプロセスは、まず自分でアウトラインや問題リストを整理し、大規模言語モデルに本文を出力させてもらい、その後その内容をローカルの md ドキュメントにコピー＆ペーストし、フロントマター、タグ、カテゴリ、タイトルなどを補完してから公開するというものでした。このプロセスが使えないわけではありませんが、非常に面倒です。本当に時間がかかるのは本文ではなく、本文の外側の繰り返しの作業です。特に最近 Codex を使いすぎてからは、その不自然さがより強く感じられます。それはリポジトリを読み込めるし、ファイルを編集でき、資料を補完できるだけでなく、記事を直接ディレクトリに書き込むこともできます。もし私がまだ手動でコピー＆ペーストを繰り返していると、まるで人間がツールの足を縛っているような気分になります。

この一連の記事は、実は一つのことを伝えたいのです。AI によるブログ執筆は、単なるプロンプト一つに頼るだけでは限界が来ています。今回の記事ではまず blog-writer がなぜ生まれてきたのかを説明します。次の記事では AIによるブログ執筆という事柄は、結局エンジニアリングとしてやる必要がある（2）：blog-style-suite でスタイル学習とトークンコストをどう分離するかを続けます。そして最終回は AIによるブログ執筆という事柄は、結局エンジニアリングとしてやる必要がある（3）：ローカルモデル、オンラインモデル、Minimax は最後にどう分業するかで締めくくります。

本当に面倒なのは、原稿を書くことではなく、あの一連の機械的な動作だ

初期のワークフローは、端的に言えば外部委託されたパイプラインのようだった。私自身がまず問題を明確にするか、あるいは大まかなアウトラインを立てる。モデルが本文を骨子として展開する。その後、人間が戻ってきて残りの公開作業を補完する。

ローカルの md にコピーする
title、date、slug を補完する
タグとカテゴリを入力する
 を補完する
参考資料を整理する
どのディレクトリに配置するかを決定するこの一連の作業は、一つ一つのステップを見れば難しくはないが、繋げると非常に面倒だ。面倒なのは技術的な難しさではなく、それらがすべて機械的であるにもかかわらず、やらざるを得ない点にある。だからこそ、私は後になって、「[コマンドラインベースのAIコーディングインタラクション](/ja/p/command-line-ai-coding-interaction/）」のような変化は、単に「入り口が変わった」だけではないと感じるようになった。AIがリポジトリ内で直接ファイルの読み書きができるようになった今、ブログ執筆がまだ「本文をローカルドキュメントにコピーする」レベルに留まっているとしたら、ワークフロー全体がすでに時代遅れになっているのだ。

blog-writer 最初の価値は文体ではなく、契約を固定化すること

blog-writer の最も初期のノードは、2026年4月1日17:00の 991536a です。gitコミット履歴を見ると、このバージョンではすでに SKILL.md、write_post.py、そして一連の初期のスタイル資料が組み込まれています。

しかし、後から振り返ってみると、このドラフトの最も価値のある点は「AI が私の文体を学んだ」ことではなく、執筆の契約を固定化したことです。

「契約を固定化する」とはどういうことか？

入力には最低限、アウトラインとファクトアンカー（事実の錨点）が必要であること
出力は必ず完全なMarkdown形式であり、未完成品であってはならないこと
frontmatter は人手に頼ることはできないこと
記事はチャットウィンドウ内に留まるのではなく、直接 content/post に配置されること

この点は非常に重要です。なぜなら、プロンプト自体が不安定だからです。「以前のように書いて」と今日言っても、それはトーンが少し似ていると解釈されるかもしれません。明日もう一度同じことを言っても、表面的な構文しか学べないかもしれません。しかし、それが Skill として書かれると、ルールは「その場での即興」から「固定された工程」へと変わります。

後続のいくつかのノードも、実質的にこの契約を補強し続けています。

2026年4月2日22:54の 8eb735a では、著者フィールド、執筆に関する注記、元のプロンプトなどが固定されました。この段階に至ると、ブログ記事の完成は単に「本文が書き終われば完了」ではなくなり、メタ情報、トレーサビリティ（追跡可能性）、公開される注記までが標準化されたのです。

したがって、blog-writer の最初の価値は、モデルをより文章を書くのが上手に見せかけることではなく、執筆という行為自体に、再現可能な境界線を持たせたことなのです。

シリーズ形式は、実は執筆の契約をさらに一歩進めたもの

単発の記事で安定して書けるようになると、次の問題がすぐに浮上します。あるテーマは、そもそも一つの記事に詰め込むのが適していません。無理に詰め込もうとすると、結局は情報量が多すぎてメインの筋が散漫になり、どの点も深く掘り下げきれない長文になってしまいがちです。これが、2026年4月2日 23:55 の 1a5604e が重要だった理由です。あの時、シリーズ形式と write_post_series.py をまとめて追加しました。記事間は relref で繋ぎ、一括書き込みの際に統一的に置換するようにしたのです。これは単なるファイル生成スクリプトの小さなアップグレードに見えますが、実際はそうではありません。それは一つのことを示しています。執筆の工程化は、「この一篇をどう生成するか」だけを考える段階から、「この一連のコンテンツをどう安定して配置し、順序をどう保証し、サイト内で相互にリンクさせるか」という視点に移ってきたということです。翌日の2026年4月3日 09:29 の 04dccb9 は、この件をさらに一歩進めました。シリーズ記事のタイムスタンプが分単位で増加し、もはや共通の時間を使用しないようにしたのです。この変更は非常に小さいものですが、エンジニアリング的な深みがあります。なぜなら、Hugoのリストページ、前後の記事リンク、シリーズの順序といった「実際の問題」を解決しているからです。端的に言えば、シリーズ形式というのは、格好良く見せるためではなく、「複数の記事をまとめて公開する」という作業が、もはや手動でのフォローアップに頼らなくて済むようにするためなのです。

しかし、単一のスキルだけでは、後でトークン制限にぶつかることになる

問題はここにあります。文体学習を真剣に行い始めると、blog-writer のコンテキストがすぐに肥大化します。ただ書くだけでなく、以前あなたのように書くことも期待するわけです。最も自然な方法は、過去の記事も一気に詰め込むことです。これなら、一度だけは実行できます。しかし、たまに記事を書くだけではなく、長期的なワークフローにしたいと思うと、すぐに問題が発生します：

トークン消費量が高い
毎回同じ古い記事を繰り返し与えることになる
モデルの注意力が古い材料によって希釈される
原稿執筆とスタイル維持が絡み合い、どちらも容易ではないここから、私はblog-writerは、すべてを任せる側（生成側）というよりは、消費する側として使う方が適していることに気づき始めました。原稿執筆という動作は、できるだけ軽く、直接的に、そしてできれば公開されたバージョンのみを参照するようにすべきです。一方、スタイルデータの生成方法、選別方法、圧縮方法は、別の生産側のパイプラインの問題なのです。この判断が、私を次のステップへと導き、それがAIでブログを書くという件は、結局エンジニアリングにする必要がある（2）：blog-style-suiteでスタイル学習とトークンコストをどう分離するかへと繋がりました。

まずプロセスを安定させてから、スタイルやモデルについて語る資格が生まれる

今振り返ると、blog-writer が生まれたのは、私が突然ブログライティングアシスタントを作りたいと思ったからではない。むしろ、これまでのワークフロー自体が、新しい働き方に合わなくなってきたことが原因だ。 Codex のようなツールがインターネットに接続して資料を補完できたり、リポジトリ内での読み書きができたり、スクリプトを直接呼び出せるようになった場合、「ブログを書く」という行為は「本文をローカルドキュメントにコピーする」という段階で止まっているべきではない。この部分を自動化しなければ、かえって全体のプロセスの中で最も非効率な工程になってしまう。そのため、最初の記事の結論はここまでとする。 blog-writer が最初に解決したのは、文体ではなく、公開作業における反復的な手作業だった。このレイヤー（層）という契約がなければ、後からトークンやデータ構造、ローカルモデルについて語っても、実際には根拠がない。

参考資料

リポジトリコミット：991536a237d04aba7c44dec501b3d98c644040c8
リポジトリコミット：8eb735aa8448c97deb2af1ea46b86772008fa9e3
リポジトリコミット：1a5604e7e6ce0a13f260fcbb8c2c1d964cdd0892
リポジトリコミット：04dccb98c55a6ea3b81408012b33a6219cf8ab77
リポジトリファイル：.agents/skills/blog-writer/SKILL.md
リポジトリファイル：.agents/skills/blog-writer/scripts/write_post.py
リポジトリファイル：.agents/skills/blog-writer/scripts/write_post_series.py

作成上の注記

元のプロンプト

$blog-writer 今回の内容は多いため、シリーズ記事に分割しました。昨年も多くの原稿が大規模言語モデルによって書かれました。その時は、自分でアウトラインや質問リストを作成し、AIに原稿を生成させ、内容をローカルのmdドキュメントにコピーし、ヘッダー情報、タグ情報などを記入して投稿するという流れでした。最近はCodexを多く使用し、Codexのインターネット検索能力が非常に強力だと気づきました。そこで、これらの作業を自動化するスキルを作成できないかと考えたのが、skill blog-writer の初稿です。さらに、AIに以前の記事のスタイルを学習させたいと考えたため、blog-writerの実行時にトークンを大量に消費するという問題が発生しました。その後、私はblog-writerに対して複数のバージョンの最適化を行いました。データモジュールとデータ生成モジュールに分割したのですが、元々のデータ生成モジュールは独立したスキルでした。書き進めるうちに、Pythonプロジェクトとしてまとめた方がより適していることに気づき、それが blog-style-suite の誕生につながりました。さらに、スタイルデータの学習もトークンを消費することが多いと感じたため、ローカルの大規模言語モデルを使用することにしました。ローカルの大規模言語モデルとオンライン版の違いを比較したいと考え、minimaxとも連携させました。blog-style-suite と blog-writer の進化の歴史は、gitのコミット履歴から分析できます。ついでに、ローカルの blog-writer および blog-style-suite のコードを基にして、設計思想や、どのようにトークン節約を実現したか、データ構造はどう設計したか、といった核となる設計思想について説明することができます。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。

ライティングのアイデア概要

最初の記事はワークフローのトリガーポイントに焦点を当て、トークンとモデルの役割分担を急ぎすぎず、3つの記事でメインテーマを奪い合うのを避ける。
「本文自体は難しくないが、公開前後の一連の機械的な作業が面倒である」という判断を重点的に残した。
991536a、8eb735a、1a5604e、04dccb9 などのノードを通じて、「プロセスを契約化する」ことを実際のGitの進化に落とし込む。
シリーズ形式はこの記事で取り上げることで、ブログ執筆が単発の記事生成から一連の成果物（セット）へと移行したことを示すためである。
最後に意図的に問題をトークンウォールに引きつけ、次の記事でのデータエンジニアリングと前処理のための布石とする。

Skill は新しいプロンプトではなく、エージェントに職種マニュアルを提供するものです。

Thu, 02 Apr 2026 22:43:16 +0800

この数日、AIプログラミングについて見てきましたが、さっきまでみんながMCPの話をしていて、次の瞬間にはまたSkillの話をしています。この言葉を初めて目にする人は、本能的にこれをまた新しいプロトコルか、あるいは高度なプロンプトだと捉えがちです。

私の判断は非常にシンプルで、SkillはMCPの座を奪いに来たものではなく、むしろエージェントに職種マニュアルのようなものを提供している感じです。MCPが解決するのは「エージェントが外部世界と接続できるか」という点であり、Skillが解決するのは「接続した後、どのような手順で確実にタスクを遂行するか」という点です。これらは代替関係ではなく、むしろ前後関係に近いです。

端的に言えば、MCPはエージェントに手足を与え、Skillはエージェントが勝手に動かないようにするためのものです。

Skill とは一体何なのか

最も分かりやすい言葉で説明するなら、こう言います。ベテラン社員の頭の中にある熟練したやり方を、再利用可能で、トリガーでき、実際に実行できるマニュアルとしてまとめたものが Skill です。

OpenAI の公式ドキュメントの定義も非常に直接的です。Skill は特定のタスクに向けた能力パッケージの一種であり、指示（プロンプト）、参考資料、そしてオプションのスクリプトを格納できます。目的はモデルを「より賢くする」ことではなく、ある種のタスクにおいて固定されたワークフローに従って安定的に出力をさせることです。

何に最も近いか？

通常のプロンプトとは異なり、一度話して終わりではないからです。
MCP とも異なります。なぜなら、ツールやデータソースを接続する責任を持たないからです。
また、AGENTS.md のようなものでもないからです。全リポジトリで通用するルールではないからです。

むしろ、専門の SOP（標準作業手順書）や、職種マニュアルのようなものです。

例えば：

GitHub PR のコメントを処理する場合：まずどのコメントを処理すべきかを確認し、次にユーザーにどのコメントを処理するか尋ね、コードを修正し、最後に結果をフィードバックする。
CI の失敗を調査する場合：まず GitHub Actions のログを取得し、次に失敗した部分を抽出して要約し、修復計画を立て、承認されてから作業に取り掛かる。
ブログ記事を書く場合：まず固定の文体でタイトルを生成し、次に事実情報を補完し、さらにフロントマター（メタデータ）を追加し、最後に公開する。

これらの事柄に共通しているのは、「モデルがどう回答すべきか知らない」ということではなく、「モデルのやり方が毎回異なり、逸脱しやすい」という点です。ここで Skill の価値が出てくるのです。

Skill と MCP、結局どこが違うのか

これは実際のワークフローに当てはめて見ないと分かりにくいので、単なる説明だけでは誤解を招きやすいです。

MCP はインターフェース層のようなものです。

公式における MCP の定義は、「AI アプリケーションを外部システムに接続するためのオープンスタンダード」です。ファイル、ローカルデータベース、検索エンジン、デザイン稿、サードパーティサービスなど、これらすべてを MCP を通じて取り込むことができます。つまり、これが解決しているのは「取り込み（コネクション）」の部分です。

一方、Skill はプロセス層のようなものです。

OpenAI の Agent Skills ドキュメントには明確に書かれていますが、Skill は再利用可能なワークフローを記述するためのフォーマットです。一つの Skill には最低限 SKILL.md が必要で、さらに scripts/、references/、assets/ を含めることができます。Codex はまずその name と description を読み込み、実際に使用する必要があると判断した場合にのみ、完全な説明をコンテキストにロードします。これが公式が言う「プログレッシブ・ディスクロージャー（段階的開示）」です。

したがって、両者の役割分担は非常に明確です。

MCP: 能力を取り込む（コネクションする）
Skill: 行う手順の順序を定める

非常に分かりやすい例で言うと、「Figma からコードへの変換」のような作業です。もしエージェントがデザイン稿自体を読み取れていない場合、まず補うべきなのは MCP です。しかし、すでにデザイン稿を読み取れるようになったのに、毎回バラバラにコーディングしてしまう（今日はコンポーネントから書き始め、明日はページ分割から始め、明後日にはビジュアルチェックを忘れる）という状況であれば、補うべきは Skill なのです。

スキルの開発方法

これは思ったほど重くありません。 OpenAIの公式推奨では、まず組み込みの$skill-creatorを使用し、トリガー条件、範囲、スクリプトが必要かどうかといった骨格部分を構築してもらうことです。デフォルトではinstruction-only（指示のみ）が優先されるため、焦ってスクリプトを書くのではなく、まずは説明を明確にすることが重要です。手動で記述する場合でも、最小限の構造は非常にシンプルです：

my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/

この中で真に必要なのはSKILL.mdだけです。そして、このファイルには最低限2つのメタデータが必要です：

---
name: skill-name
description: Explain exactly when this skill should and should not trigger.
---

私が考えるに、Skillを開発する上で最も重要なのは以下のステップです。

1. 「繰り返し現れるバイアス」を探す

すべてのタスクが Skill にする価値があるわけではありません。エージェントに単発で作業をさせるだけであれば、通常のプロンプトで十分です。真に Skill として抽出するのに適しているのは、通常以下のようなケースです：

同じことを何度も繰り返して指示している場合
エージェントには能力があるはずなのに、実行順序がいつも変わってしまう場合
間違いが発生する箇所が毎回似ている場合つまり、「能力不足」なのではなく、「手順（ノウハウ）が安定していない」ということです。

2. `description` をトリガー条件として記述し、宣伝文句にしないこと

このステップは非常に重要です。公式ドキュメントでは、Codex がどの Skill を暗黙的に呼び出すかについて、description に大きく依存すると強調しています。「これはとても便利なスキルだ」といった表現ではなく、「いつ使うべきか、いつ使ってはいけないか」を記述してください。例えば、gh-fix-ci の公式スキルの説明は非常に明確です：「ユーザーが GitHub PR チェックの失敗をデバッグまたは修正してほしい場合に使用する」というものです。重要なのは、ログを確認し、失敗の原因を要約し、修正計画を提示することであり、そして明示的な承認を得てから実行することです。これを見るだけで、その境界線がどこにあるかがわかります。

3. 説明で対応できるなら、まずスクリプト化しない

OpenAIのドキュメントでも非常に実用的なアドバイスをしています。明確な決定論的動作や外部ツールが必要でない限りは、いきなりスクリプトにするのではなく、まずは説明（プロンプト）を使うべきです。なぜか？スクリプトが増えれば増えるほど、メンテナンスコストが上がってくるからです。多くのSkillは、最初は単に手順を明確に説明するだけで十分です：

何から始めるか
次に何をするか
出力形式はどうするか
どのような状況でユーザーに確認を求めるべきかこれだけでも大半の問題は解決します。あるステップが非常に安定していて、非常に機械的で、自動化に適している場合にのみ、scripts/に落とし込むようにしましょう。

4. 資料、テンプレート、リソースを分離する

Skill は書き進めるうちに、非常に長い説明文になりがちです。そんな時は分割すべきです。

SKILL.md はルールと手順を担当する
references/ には背景ドキュメントや参照資料を置く
assets/ にはテンプレート、アイコン、サンプルを置く
scripts/ には安定して実行できるアクションを置くこのようにすることで、2つの利点があります。第一に、メインファイルが肥大化しすぎるのを防げます。第二に、モデルが必要なときだけ詳細を読み込む形になり、「プログレッシブ・ディスクロージャー（段階的開示）」という考え方に沿えます。

5. ローカルで先に使い、プロジェクトをまたいで配布する

公式ドキュメントでもこの点は明確に分けられています。もしご自身の現在のリポジトリでのみ使用するのであれば、.agents/skills/ に配置するだけで十分です。Codex はリポジトリ、ユーザー、システムなどの場所からスキルディレクトリをスキャンします。しかし、この仕組みが単一のリポジトリだけでなく複数の場所で使えることに気づいた場合や、複数のスキルをまとめてパッケージ化して配布したい場合は、skill folderの層に留まらず、plugin を検討すべきです。OpenAI公式ドキュメントの記述も非常に明確で、Skill はワークフローそのものであり、真にインストールおよび配布に適した単位は plugin です。

スキルが適しているシナリオ

Skill は多ければ良いというものではなく、以下の種類のタスクに最も適しています。

高頻度で繰り返すタスク

毎週行う、そして毎回手順がほぼ同じもの。例えば：

PRレビューコメントの処理
ブログ記事の執筆とフロントマターの追記
CI失敗の調査
リリース前のチェックこのような作業は、モデルができないことよりも、毎回説明し直さなければならないことが一番面倒です。

固定フローのタスク

ある事柄には、生まれながらにして順序があるものがあります。例えば問題の調査をする場合、まずログを確認し、次に範囲を絞り込み、それから計画を立て、そして修正するという流れになります。このような場面では、Skill が特に適しています。なぜなら、順番を固定できるため、モデルがその場しのぎで対応するのを減らせるからです。

専門的な文脈に紐づける必要があるタスク

手順が固定されているだけでなく、強い制約を伴うタスクもあります。例えば：

公式ドキュメントのみを参照すること
特定のレビュー形式で出力しなければならないこと
チーム内の既存の用語を保持しなければならないこと
特定のリポジトリの記述または開発規約を遵守しなければならないことこのような作業は、毎回プロンプトに頼って一時的に指示を出すだけでは、漏れが生じやすいです。

ツールとプロセスを併用するタスク

このシナリオは特に典型的なものです。単に「GitHubに接続する」だけで終わるのではなく、接続した後も、何らかの方法でログを確認し、問題を分類し、修正が必要かどうかを判断し、最後にどのようにフィードバックするかという一連の作業が必要です。つまり、外部接続と内部プロセスが組み合わさって機能しなければなりません。このような場合、しばしば MCP + Skill が組み合わさって登場します。

スキルとして実装する必要がないシナリオ

逆に、どこまでを「スキル」とするのかを明確に伝える必要があります。そうしないと、何でもかんでもSkillにしようとしてしまいがちです。

一回限りの気軽なタスク

ユーザーが一時的に質問する場合、通常のプロンプトで十分なことが多いです。

あなたが望んでいるのは「外部システムへの接続」だけだ

その場合は、Skill ではなく MCP を優先的に検討してください。

リポジトリ全体の長期的な振る舞いを制約したい場合

これは Skill の仕事というよりは、AGENTS.md の仕事に近いです。したがって、簡単にまとめると以下のようになります：

接続が不足している場合、MCP を使う
プロセスが不足している場合、Skill を使う
グローバルなルールが不足している場合、AGENTS.md を使う

代表的な事例をいくつか

概念をどれだけ説明しても、実際の事例を見る方が良いです。

1. `roll-dice`：最小限の入門ケース

このケースはOpenAI公式のAgent Skillsドキュメントからのものです。非常に小さく、ディレクトリ内にはほとんどSKILL.mdしかなく、エージェントがユーザーからサイコロを振るよう要求された際に、PowerShellの乱数コマンドを呼び出すようにします。なぜこの例が良いのか？それはSkillの最も核となる骨格を直接示しているからです：

明確なトリガー条件がある
明確な実行方法がある
明確な境界線があるこれは、Skillが必ずしも大きくなくて良いことを示しています。あることが繰り返し発生し、モデルに無作為な振る舞いをさせたくない場合、それをSkillとして実装できるということです。

2. `gh-address-comments`：GitHub コメント処理のワークフロー例

このケースは、OpenAI 公式の openai/skills リポジトリから来ました。目的は「GitHubに接続する」ことではなく、「現在のブランチのPRのコメントを処理する」という一連のプロセスを固定化することです。公式バージョンでの手順が非常に典型的です：

まずghが認証済みか確認する
次に、現在のPRのコメントとレビュースレッドを取得する
これらのコメントに番号を振り、要約する
ユーザーにどのコメントを処理するか明確に選択させる
その後で初めて処理を開始するこの例は、Skill の価値を特に示しています。多くのエンジニアリングタスクにおいて、難しさは「モデルがGitHubとは何かを知っているか」という点ではなく、「正しい順序で物事を処理できるか」という点にあります。gh-address-comments が解決しているのは、まさにこのような順序の問題です。

3. `gh-fix-ci`：CI 失敗のエンジニアリングケースの調査

これも openai/skills リポジトリ内の公式スキルです。これは別の非常に典型的なエンジニアリングタスクを対象としています。それは、PR のチェックが失敗したとき、「直すべきか」「どう直すか」というものです。この Skill で定義されているワークフローも非常に代表的です：

まず gh のログイン状態を確認する
現在の PR を見つける
GitHub Actions の失敗したチェックとログを取得する
失敗した部分を抽出する
まず修正計画を立てる
承認を得てから実行するこれは、「CI がなぜ失敗したか見て」という単なるプロンプトでは安定して対応できないシナリオです。なぜなら、権限、ログ、外部ツール、承認の境界線、実行順序など、これらすべてを定義する必要があるからです。

4. リポジトリ固有のスキル：チーム独自のノウハウを蓄積する

公式なサンプル例以外で、私が考える Skill のより大きな価値は、実はプライベートリポジトリ内にあります。例えば、目の前のブログリポジトリにある blog-writer は、本質的には非常に典型的な repo-scoped skill です。これは「モデルに中国語の書き方を学ばせる」ことを担当しているのではなく、このリポジトリで既に固定された文体、構造、ファクトチェック、出力パス、データ保存形式などをワークフローとして記述したものです。このような Skill は、最も現実的な価値を持つことが多いです。なぜなら、すべての人に向けられているわけではなく、「あなたはこのリポジトリで、どのような種類の作業が繰り返し発生し、かつ逸脱しやすいか」という点に特化して解決するものだからです。

実際に「Skill」を使うべき時

そこで、最後に最も実用的な問題に戻ります。いつ真剣に Skill を作るべきでしょうか？私の答えは以下の通りです。それは、問題がもはや「モデルの能力不足」ではなく、「毎回同じ行動が安定しない」と感じたときです。この段階でプロンプトを積み重ねても、得られる利益は通常低くなる一方です。今日一文追加し、明日また一文追加するうちに、プロンプトはまるで出来事の羅列になり、モデルはやはりミスを犯します。むしろ、それを Skill として整理し、トリガー条件、手順、境界線、スクリプト、資料などを分けて管理する方が、効果が安定しやすく、再利用性も高まります。 MCP は外部世界と接続し、Skill は内部のノウハウを固定化します。前者は「できるかどうか」を解決し、後者は「どうすれば安定してできるか」を解決します。これが私が今理解している Skill です。それは新しいプロンプトでも、新しいプロトコルでもありません。むしろ、エージェントに職種マニュアルを渡すようなものです。

参考資料

作成上の注記

元のプロンプト

プロンプト：AI大規模言語モデルによるプログラミングについて、まずMCPが登場し、次にSkillが登場しました。平易な言葉で、Skillが何か、どのようにSkillを開発するか、どのようなシナリオに適しているか、それぞれ具体的な代表的な事例を挙げて説明してください。

ライティングの骨子まとめ

「MCP と Skill の概念レビュー」として繰り返し書くのではなく、重点を Skill の役割と使用範囲に置いた。
「職種マニュアル」「特定作業手順書（SOP）」といった平易な比喩を用いて、抽象的な定義を実際のワークフローに落とし込んだ。
開発部分は公式ドキュメントの実構造に沿って記述し、description、progressive disclosure、instruction-only といった重要な点を保持した。
ケーススタディは可能な限り公式ソースを選定し、それぞれ公式ドキュメント内の roll-dice、および openai/skills リポジトリ内の gh-address-comments と gh-fix-ci を使用した。
最後に、読者が読み終えた後も混同しないよう、MCP、Skill、AGENTS.md の三者の境界線を改めて整理した。

弱いモデルに無理に強いものを適用しない

Thu, 02 Apr 2026 22:05:00 +0800

最近、いくつかの端的な作業を MiniMax やローカルモデルに移行させているが、使うほど「最強モデル」という基準で物事を測るのは違うと感じるようになった。

私の判断は非常にシンプルだ。弱いモデルに無理に難しいタスクを割り当ててはいけない。「MiniMax」のようなモデルは、能力が劣っているのは事実だが、複雑なコーディング、長尺の推論、曖昧な要件の分解といった作業には確かに物足りない。しかし、データクレンジング、ドキュメント作成、提案資料の検索といったタスクであれば、これらは十分にこなせる。同じロジックで、ローカルの12Bクラスのモデルも同様だ。翻訳、フォーマットの書き直し、バッチ処理でのクレンジングなど、むしろそちらが本来適している場所なのだ。

端的に言えば、モデルに価値がないのではなく、単に間違った場所に配置されているだけだ。

本当の問題は、モデルがどれだけ強力かではなく、どれだけ「生きている」かである

多くの人が大規模言語モデルについて話すとき、頭の中では最も難しいタスクを思い浮かべがちです。

複雑なエンジニアリングを単独で書くこと
システム全体を一度に分解すること
長いコンテキスト内での複数ターンにわたる推論の処理
検索しながら計画し、実行するこれらはもちろん重要です。しかし、現実の業務で机の上に積み重なっているものの多くは、このような作業ではありません。むしろ多いのは以下の類です：
一連の汚れたフィールドをクリーンアップすること
ばらばらの資料を読みやすいドキュメントに整理すること
長文を要約、FAQ、アウトラインに変更すること
中文と英文が混在する内容を統一フォーマットにすること
複数のウェブページから資料を探し出し、ついでに提案書の草稿としてまとめることこのようなタスクで最も必要なのは、「モデルが天才のように考える」ことではなく、以下の3点です：
指示追従性が極端すぎないこと（常識的であること）
出力構造が可能な限り安定していること
コストが十分に低く、何度も使いたくなるほど低いことだからこそ、私は弱いモデルは役に立たないのではなく、単にフラッグシップモデルと同じ戦場に持ち出せないだけだと考えているのです。

MiniMax が真に得意なこと

まず MiniMax についてです。

公式は MiniMax-M2.5 の位置づけを非常に高く設定しており、プレスリリースやオープンプラットフォームのドキュメントでは、プログラミング、ツール呼び出し、検索、オフィス生産性といったシナリオに重点を置いています。さらには速度と価格の優位性を強調しています。これらの主張を完全に信じられないわけではありませんが、私はそれを分解して見る方が好みです。

私にとって、MiniMax が真に使いやすいのは、「最も複雑な開発タスク」ではなく、以下の点です：

データクレンジング

データクレンジングと一口に言っても、半構造化テキストの肉体労働です。

名称の統一
フィールドのマッピング
外れ値のアノテーション
分類ラベル付け
表形式フィールドの補完このような作業が最も恐れるのは、モデルが「愚か」なことではなく、フォーマットが不安定であったり、出力が拡散したりすることです。モデルが JSON、表、固定テンプレートに従って結果を出力できれば、実は十分な場合が多いです。高性能なモデルももちろん可能ですが、最も高価なモデルをフィールドクレンジングに使うのは、多くの場合費用対効果が悪いです。

ドキュメント作成

ドキュメント作成は面倒くさい、難しいわけではない。インターフェースが変わる、プロセスが変わる、フィールドが変更される、といったたびに説明書を修正しなければならない。この過程には、モデルに高い創造性が求められるというよりは、むしろ余計なことをして元の明確な情報を曖昧にしてしまわないように注意することが重要だ。 MiniMax はこのような作業において、想像以上に信頼できることが多い。特にコンテキスト（文脈）を準備しておけば、真のエンジニアというよりも、実務ができるドキュメントアシスタントのような存在になる。

方案資料検索

公式側も検索やツール呼び出しを推進しているので、この方向性は問題ありません。多くの場合、私たちが求めているのはモデルに「空から答えを思いつかせる」ことではなく、ウェブページ、ドキュメント、お知らせ、資料などをまず探し出してきて、それから整理してもらうことです。このようなシナリオでは、MiniMax のような安価なモデルの価値が非常に高くなります。なぜなら、検索、要約、統合といった作業は元々頻繁に行う雑務だからです。したがって、私の実際の見解は以下の通りです：MiniMax がダメなのではなく、むしろ生産パイプラインの中での「汚い仕事」「面倒な仕事」「繰り返しの仕事」に向いているということです。雑用をさせるなら、合格点であることが多いですが、すべてを包括的に担当させようとすると、がっかりする確率が高くなります。

ローカルの12Bモデルは、持ち帰るのに最も適したタスクがある

さらに下を見ると、ローカルデプロイメントは基本的に同じロジックです。多くの人が「ローカルモデル」と言うと、どうしても一つの疑問が浮かびます。「クラウド上のフラッグシップに取って代われるのか？」と。しかし、この質問自体が最初から偏っていると思います。ローカルの12B程度のモデルが持つ真の価値は、「自分も最強クラスのタスクをこなせることを証明する」ことではなく、安定していて、反復的で、機密性が高く、利益率は低いが頻度の高い作業を持ち帰ることなのです。

翻訳

これはローカルモデルにとって得意なシナリオの一つです。 Qwen2.5 の公式ブログでも明記されているように、長文生成、構造化データ理解、JSON 出力などが強化されており、さらに29以上の言語をサポートしています。この組み合わせは、翻訳、バイリンガルでの書き直し、フォーマットの統一、専門用語の標準化といった作業に本質的に適しています。技術ドキュメント、フィールドの説明、製品紹介、インターフェースコメントなどは、構造が安定しており、専門用語が固定されていることが多いため、ローカルモデルが最もエレガントに翻訳できるとは限りませんが、通常は十分な品質です。

データクレンジング

ここがローカルモデルが特に現実味を帯びている点です。多くの表、ドキュメント、業務資料は、クラウドにアップロードしたくないものがあります。特に内部データ、顧客情報、議事録、未完成の提案書などは、プライバシーや権限が関わるため、ローカルで実行する方がずっと安心できます。このような状況において、ローカルの「12B」程度のモデルの意義は、「どれだけ賢いか」ではなく、「自分のマシン上で動作し、こうした面倒な作業を安定してこなせるか」という点にあります。

固定フォーマットへの書き換え

例えば：

会議議事録を固定テンプレートに整理する
商品タイトルを統一の命名規則にクレンジングする
バグの説明を工單形式に書き直す
中英が混在したテキストを単語バージョンにクレンジングするこのようなタスクは共通の特徴を持っています：ルールが明確、バッチ処理が大きい、繰り返しが多い、単発あたりの価値は高くないが、総量が多いのが面倒。これこそがローカルモデルが最も適している仕事です。

3060 12GB で 12B クラスのモデルを動かせるのか

この件については、もっと現実的に書く方が良いと思います。「動かすことはできるが、あまり期待しすぎないでください。」という感じです。

Google は Gemma 3 の公式ドキュメントで、非常に参考になるVRAM使用量の表を公開しています。Gemma 3 12B を動かすには、おおよそ以下のメモリが必要です：

全精度バージョンをロードする場合：約 20 GB
中程度の量子化バージョンをロードする場合：約 12.2 GB
より低いVRAM使用量のバージョンをロードする場合：約 8.7 GB

公式はまた、これがモデルのロードに必要なメモリ量のみであり、プロンプトや実行時の追加オーバーヘッドは含まれていないと注意喚起しています。

この一文が非常に重要です。

これはどういう意味か？ 3060 12GB のようなグラボで 12B クラスのモデルを動かすことが不可能だということではなく、前提条件があるということです。その前提とは通常以下の通りです：

量子化されたバージョンを使用していること
コンテキスト（プロンプト）を長すぎないようにすること
タスクが複雑すぎないこと
速度が平均的、あるいは遅くても許容できること

もしあなたがこれらの前提を受け入れる意思があるなら、ローカルで 12B クラスのモデルを動かすことは確かに可能です。少なくとも翻訳、要約、表のクレンジング、固定フォーマットへの変換といったタスクであれば、大げさな要求ではありません。

また、Qwen2.5-14B-Instruct-GGUF の公式リポジトリ自体が複数の量子化形式を提供しており、これはすでに考え方を非常に明確に示しています。このクラスのモデルは、本来ローカル推論のエコシステムを念頭に置いて適応されているのです。

したがって、私の結論は一貫して「3060 12GB が 12B モデルを楽々こなせる」というものではなく、むしろ： **「このようなモデルを動かすことはできるが、期待値が低く、反復性が高く、プライバシーが重要な作業に向いている」**ということです。

安価なモデルとローカルモデルを使うことで節約できるのはAPI費用だけではない

この件について話している人の多くは、まず「お金を節約できる」という反応をします。もちろん、お金の節約は重要です。しかし、私が思うより大きな価値は、以前は面倒だと避けていた雑務を、思い切って外部に委託できるようになることです。以前なら、数百件のデータクレンジングのために専用のスクリプトを書くことはなかったかもしれませんし、数十ページの日英資料のフォーマット統一のために手作業で少しずつ修正することもなかったでしょう。また、一時的な提案書のために資料を集める際も、ウェブページを一つ一つ読み込んで整理することさえなかったはずです。しかし、今は違います。コストが十分に低く、ハードルが十分に低い限り、「やる価値がない」と思われていたこれらの作業が一気に「やる価値がある」ものになります。あなたは「やるべきか？」と悩むのではなく、まず安価なモデルやローカルモデルに実行させるだけです。これが私が目にする最も現実的な変化です。強力なモデルは難題に取り組むことに専念し、弱いモデルは雑務をこなし、ローカルモデルが最終的な保証とバッチ処理を担当する。このように役割分担することで、ワークフロー全体がスムーズになるのです。

まとめ

だから最後に言いたいのは、一つのモデルで全てを解決しようと考えすぎるなということです。 MiniMax のようなモデルは、能力が弱いという点はあるものの、使い物になりません。これを複雑なエンジニアリング、曖昧な要件定義、多段階の推論にぶつけても、当然ながらがっかりさせられるでしょう。しかし、データクレンジング、ドキュメント作成、ソリューション資料の検索といった作業に使えば、かえって非常に扱いやすいことが多いです。ローカルで動作する 12B 程度のモデルも同じです。これらは「もうクラウド上のフラッグシップは必要ない」と証明するためではなく、安定していて、反復的で、機密性が高く、バッチ処理の大きいタスクを、地道に自分自身のマシン上に持ち帰るためにあるのです。つまり、苦手なことを弱いモデルにやらせてはいけないということです。適切な場所（用途）に置けば、それ自体が現実的な価値を持つわけです。

参考資料

作成上の注記

元のプロンプト

minimax の大規模言語モデルは、能力が弱いのは弱いが、データクレンジング作業やドキュメント作成、提案資料の検索などを行う分には問題ない。同じロジックで、ローカルに大規模言語モデルをデプロイし、翻訳などの作業やデータクレンジング作業を行うのも良い。モデルのパラメータ数は12b程度で、ローカルの3060 12GBのグラフィックボードでも動かせるはずだ。

ライティングの思考プロセス要約

「弱いモデルに無理なタスクを割り当てない」という核となる判断は維持し、モデルランキング比較としては記述しませんでした。
MiniMax の部分は、公式が定義するプログラミング、検索、オフィス作業といった用途に基づき、その判断をデータクレンジング、ドキュメント作成、資料検索といった現実的なタスクに落とし込みました。
ローカルモデルの部分では、公式ソースから Qwen2.5 と Gemma 3 の2つを選択しました。一方は多言語対応と構造化出力をサポートし、もう一方は 12B パラメータとVRAM使用量を考慮したものです。
3060 12GB に関する記述は、「帯域幅はあるが、あまり期待しすぎないでほしい」というニュアンスを意図的に含め、量子化推論を絶対的な結論として扱わないようにしました。
最後に、強力なモデル、弱いモデル、ローカルモデルという分類を用いて締めくくり、メインの論旨に焦点を絞りました。

低価格API中継地点の終着点：3月の大規模言語モデル体験と不可能性の三角形

Mon, 30 Mar 2026 20:00:00 +0800

3月を通して、私は様々な大規模言語モデル（LLM）APIのトランジットポイント間を行き来して試していました。

安さについては、確かに安いものでした。月にあまりお金をかけずに、ChatGPT、Claude、Geminiといった海外のモデルをすべて触ることができ、表面上は非常にコストパフォーマンスの高い解決策を見つけたように思えました。しかし、実際に使ってみるうちに、この道筋が最初から「品質、安定性、費用対効果」という不可能な三角形から逃れられないと感じるようになりました。これら三つが同時に成立するのは難しいのです。

先週末には、この件はほぼ白日の下に晒されました。2026年3月28日から2026年3月29日までの二日間で、ChatGPT関連のチャネルの風控（リスク管理）が明らかに厳しくなり、Claudeも同様でした。以前はなんとか使えていた低価格なトランジットサービスも突然不安定になったり、完全に機能しなくなったりしました。私にとっては、これは低価格APIトランジットモデルの段階的な終焉を告げるものとなりました。

中継ステーションとは何か

まず概念を明確にしましょう。いわゆるAPI中継ステーションは、本質的にモデルベンダーが公式に提供するサービスではなく、ユーザーと上流のモデルの間にある「転送層」のようなものです。リクエストを中継ステーションに送り、中継ステーションが代わりにOpenAIやAnthropicなどの他のモデルサービスプロバイダーにリクエストを転送し、最後に結果をあなたに返します。ユーザーの視点から見ると、それはより安価で、より「柔軟な」統一のエントリーポイントのようです。技術的およびビジネスモデルの観点からは、上流のリソースを再パッケージ化し、再配布しているようなものです。このようなサービスがこれまで利用され続けている理由は非常にシンプルです。

価格が安い
利用開始のハードルが低い
モデルの種類が多い
国内ユーザーにとって、登録、支払い、ネットワーク環境に関する手間を省けるしかし、問題もまさにこの点にあります。これは公式な経路ではないため、多くの利便性は、安定したライセンスに基づいているのではなく、「余分な層を追加している」ことに本質的に基づいています。

彼らは通常どのように機能しますか

プラットフォームによってアプローチは異なりますが、一般的なパターンはいくつかの種類に大別されます。

1. 主要な二次ディストリビューション（再販）

一部のプラットフォームは、本質的に自社のアップストリームAPIキーを統一して転送し、そのクレジットをダウンストリームユーザーに分割して提供しています。購入しているのは、OpenAIやAnthropicが直接販売するプランではなく、彼らが提供する一層目のパッケージです。このモデルの問題点は、アップストリームのキーが制限されたり、クレジットが上限に達したり、ポリシーが調整されたりすると、ダウンストリームでの体験が即座に不安定になることです。

2. アカウントプールのローテーション

業界でよく使われる「号池」とは、アカウントリソースをプール化して管理することを指します。プラットフォームが複数のアカウントを集約し、リクエストに応じて順番に呼び出すことで、クォータ（割り当て枠）の負荷や不正検知のリスクを分散させます。ここでの「号池」は、モデルベンダーの公式な専門用語ではなく、より俗語的で裏話的な表現です。これは製品の機能性そのものよりも、リソースのスケジューリング方法に重点を置いています。どのプールの規模が大きいかによって、短期的に安定しているように見えますが、上流側から一斉にクリーンアップ（監視・制限）が始まると、この安定性はあっという間に失われることがあります。

3. リバースエンジニアリングによるラッパー化（逆アセンブル）

もう一つの手法として、本質的には公開されている標準の公式APIを利用するのではなく、ウェブページやクライアント側のリクエスト方法を調査し、その呼び出しプロセスを「あたかもAPIであるかのように」再構築してユーザーに提供する方法があります。この「リバース（逆行）」という言葉は、簡単に言えば、公式が用意した入り口から入るのではなく、裏口や窓、さらにはパイプラインなどからシステム間の通信方法を理解し、自分自身でラッパー層を設けるということです。この手法の弱点も非常に明白です。今日使えるからといって、明日も使えるとは限りません。ページの構造、認証方式、デバイス検証、行動ポリシーなどが少し変わるだけで、エンドツーエンドの処理全体が機能しなくなる可能性があります。

3月の実体験について

この3月度の集中的な体験を経て、私が最も感じたのは「安いから良い」という感覚ではなく、「不確実性を継続的に我慢しなければならない」ということです。

同じ要求であっても、今日のある中継地点（プロバイダー）ではうまく答えられるのに、明日になると知能が落ち始めることがあります。午前中は安定して出力できるのに、夜になるとエラーが出たり、タイムアウトしたり、コンテキストが失われたりします。自分がモデルの能力を買っていると思いがちですが、実際には多くの場面で絶えず変動する「確率的なサービス」を購入しているにすぎません。

一時的にモデルを試したり、軽い質疑応答を行うだけであれば、この変動は我慢できます。しかし、それを実際のワークフローに組み込むと、問題が非常に明白になります。

品質が不安定で、出力レベルが高低差がある
安定性に欠け、タイムアウトやエラー、途切れが発生しやすい
コンテキストの連続性が低く、長時間のタスクでの体験が悪い
プラットフォームを上流（プロバイダー）に切り替えると、モデルの個性やスタイルが漂流する
同じ時間を費やして問題を調査しても、目に見えないコストは低いわけではない

つまり、安価な中継地点の最大の問題点は、「安くない」ということではなく、本来公式プラットフォームが負うべき「確実性」を、ユーザー自身に再転嫁させている点です。

表面上は費用を節約しているように見えますが、実際には時間、精神力、そしてワークフローの予測可能性というコストを多く払っているのです。

なぜ私はそれが不可能性の三角形に入り込むと言ったのか

最近繰り返し使ってみて、このような中継サービスは必然的に「不可能性の三角形」に陥ると感じています。

品質

品質を高く保つためには、実際に利用可能なアップストリームモデルの確保、十分なクレジット枠の確保、そしてできるだけ少ないサンプリングやダウングレードが不可欠です。このこと自体が安くはありません。

安定性

安定性を高めるためには、より多くのリスク管理、アカウントの損失、ネットワークの変動、レート制限、バックアップ回線などを処理する必要があり、さらにはより複雑なスケジューリングやフォールバック機構を自前で構築する必要があります。これらはすべてコストになります。

お得な価格設定について

最初の2つのことをしっかりと固めれば、価格をこれ以上低く抑え続けることは不可能になります。長期にわたって超低価格を維持できる場合、それはコストが真に解決されていないだけであり、単に先送りされたか、あるいは将来の何らかの集団的な失敗に分散されていることを示していることがよくあります。そのため、多くの仲介業者は「高い費用対効果」を実現しているように見えますが、実際には脆い均衡を保っているだけであることが多いです。平穏な時には成立しますが、上流側のリスク管理が厳しくなると、この均衡は容易に崩壊します。

先週末は、ほぼ明牌だった

私に「もうこれ以上深入りするのはやめよう」と決意させたのは、2026-03-28 から 2026-03-29 のこのローテーションでした。

私自身の体感では、ChatGPT関連のチャネルがその二日間で非常に顕著な集中絞り込みを見せ、Claude側のリスク管理も同時に強化されていました。以前は、回線を変えたり、モデルを変えたり、プランを変えたりすることで「なんとか使える」状態を保つことができましたが、それが突然通用しなくなりました。

ここでは、「業界全体が完全に死んだ」といった断定的な表現は避けたいと思っています。結局のところ、自分たちにはまだ別のチャネルがあると言う人は必ずいるからです。しかし、一般ユーザーの実用価値という観点から見ると、低価格なAPI中継ルートというのは、少なくとも私がこれ以上時間を費やす価値はないと感じています。

「安い」ということは、「タスクを安定して完了できる」という前提があって初めて意味を持ちます。基本的な信頼性すら維持できなくなれば、安さというのは単なる錯覚になってしまいます。

なぜこのパターンは元々脆弱なのか

表面だけを見ると、メーカーが「意図的に利用を制限している」ように感じられるかもしれません。しかし、深く考えてみると、実はこうしたパターン自体が非常に脆い土台の上に成り立っているのです。

OpenAIやAnthropicといった企業は、そもそも「二次的なグレーな再販」というロジックで製品を設計したわけではありません。公式の利用規約には、APIキーの売買・譲渡、制限の回避、リバースエンジニアリング、保護措置の迂回などについて、明確な制限が設けられています。OpenAIのサービス規約では、「APIキーの売買または譲渡」「レート制限や保護措置の回避」「使用制限の回避」を禁止行為として明記していますし、Anthropicの商用利用規約も、違反利用、不正アクセス、サービス乱用に対する制約空間を明確に留保しています。

言い換えれば、これらの仲介業者は、公式が推奨するエコシステムの中でイノベーションを起こしているのではなく、公式なガバナンスの隙間を縫って生き延びようとしているだけです。モデル提供元が真剣に清掃（対策）を始めた場合、このパターンは自然と最初に打撃を受ける運命にあります。

さらに、非常に現実的な背景があります。多くの海外のモデルサービスには、もともと地域、支払い、アカウントシステム上の障壁が存在します。公式がサポートする地域が限られているため、多くのユーザーが門前払いとなり、それが仲介（中継）需要を生み出しています。しかし、需要があるからといって、そのパターンが盤石であるとは限りません。それは単に、「グレーな代替案」に市場があることを示しているだけであり、長期的な確実性を持っているわけではないのです。

最終的な結論

色々試した結果、今の私の結論はかえってシンプルになりました。 codex の方がコストパフォーマンスが高いと感じています。少なくとも私自身の使用経験からすると、本番環境に導入する用途にはこちらの方が適しています。国内で大規模なアカウント停止のフィードバックをあまり聞かないこと、そして全体的な心理的負担も低い点も理由の一つです。もちろん、codex に制約がないわけではありません。5時間の制限や週ごとの制限は存在しますし、今使うときには、以前のように無計画に何でも質問したり、すべてを任せきりにしたりすることはなくなりました。多くの問題については、まず頭の中で一度シミュレーションしたり、自分で分解してから、今回のクレジットを使うかどうかを判断するようになりました。こう考えると、制限というのは必ずしも悪いことばかりではありません。客観的に見て、人間に再び思考プロセスに参加することを強制し、問題を整理させ、判断させ、取捨選択させることを強いるためであり、すべての思考を外部に丸投げすることを防いでくれます。以前も書きましたが、モデルが少し「賢くない」ことは、必ずしも悪いことではなく、むしろ利用者に基本的な思考強度を維持するよう促してくれるからです。今振り返ってみても、この判断は依然として正しいと思います。 Claude は現時点では考慮していません。能力が低いわけではありません。それどころか、非常に強力です。しかし、個人での正規購入であってもアカウント停止の不確実性が残っている以上、今の段階でメインのソリューションとするには適さないと考えています。国内のモデルについては、引き続き様子を見ることにします。まだ長期的に深くコミットできる段階ではないからです。そのため、結局は非常に素朴な選択に戻りました。ChatGPT Plus を購入し、とりあえず使いながら、大規模言語モデル業界が今後どのように進化していくのかを見守る、という形です。多くの場面で、一番安いプランが必ずしも一番お金がかからないわけではなく、一番気が楽な（ストレスの少ない）プランこそが真のコストパフォーマンスを秘めているのです。

参考リンク

OpenAI 対応地域：https://help.openai.com/en/articles/5347006-which-countries-and-territories-are-supported-by-openai
OpenAI サービス規約：https://openai.com/policies/services-agreement/
Anthropic 商用利用規約：https://www.anthropic.com/legal/commercial-terms

深層解析：C++ における `static lambda` が引き起こすメモリリークとキャッシュ汚染

Mon, 16 Mar 2026 20:18:18 +0800

本記事では、C++開発における unordered_map::find がヒットした後にオブジェクトフィールドが一致しないという奇妙な現象を分析しています。原因は、関数内部で static lambda を定義し、参照キャプチャによってローカル変数を捕捉することです。これにより、最初の呼び出し後には幽霊参照が発生し、その後の呼び出しで未定義動作（UB）を引き起こし、キャッシュデータを汚染します。この問題を解決するには、明示的なパラメータの渡しを介して暗黙のキャプチャを置き換え、ライフサイクルの管理を標準化し、Sanitizerツールを使用することを推奨します。

高性能な行情サービスや分散型キャッシュを構築する際に、プログラマーはしばしば「異変」に遭遇します。それは、Keyを使用して std::unordered_map からオブジェクトを明確に見つけ出すにもかかわらず、その内部フィールドを読み取ると、別のKeyのデータになっているという現象です。この「身分誤認」は、隠れたC++の罠を指しています：**static lambdaとライフサイクルキャプチャの競合による未定義動作（UB）**です。

故障パターン：「長久保存」の短寿命引用

パフォーマンスを最適化する際、一部の開発者は関数内で static lambda を定義してクロージャー作成のオーバーヘッドを削減することがあります。しかし、暗黙的なキャプチャによる参照捕獲 [&] と組み合わせると、爆発的な問題が発生します：

void UpdateCache(std::unordered_map<std::string, Tick>& cache, Tick& current_input) {
    // 危険：static は lambda のライフサイクルをプロセスレベルまで延長する
    // [&] はスタック上のローカル参照 current_input をキャプチャする
    static auto patch_func = [&](auto it) {
        it->second.price = current_input.price; // 2回目実行時、この参照は無効になっている
    };

    auto it = cache.find(current_input.symbol);
    if (it != cache.end()) {
        patch_func(it);
    }
}

技術原理の剖析

ライフサイクルズのずれ: static 変数はプログラムがその行に到達した際に初期化され、プロセス全体で一度だけ実行されます。つまり、patch_func 内でキャプチャされた current_input の参照は、最初の呼び出し時にスタックフレーム上のメモリのアドレスに固定されます。
幽霊参照 (Dangling Reference): 最初の UpdateCache が完了すると、元のスタックフレームが破棄されます。その結果、patch_func はすでに無効になったアドレスを読み書きしようとします。
隠れたメモリ汚染: スタック空間は繰り返し使用されるため、そのアドレスには新しいビジネスデータが格納されている可能性があります。この場合、データを書き込むことで、現在の Key の Value を更新しているように見えますが、実際には「ランダム」なメモリ領域で不正な書き込み操作が行われています。これが、find の Key が A であり、読み取った Value フィールドが B である理由を説明しています。

ソリューションとエンジニアリングプラクティス

1. 隐式捕获消除，改用显式参数传递

最稳妥的方法是让 Lambda 保持“无状态”（Stateless），将所有依赖的对象通过参数传递。

// 推荐做法：无状态 lambda，显式传递 src
auto patch = [&](auto it, const Tick& src) {
    it->second.price = src.price;
};
patch(it, current_input);

2. 静的修飾閉包の慎重な使用

関数内部で、閉包がローカル変数をキャプチャしていない限り、static を使用しない方が良いです。現代のコンパイラは非 static lambda の最適化に非常に優れており、盲目的に static を使用しても得られるパフォーマンス向上はほとんど無視できる程度でありながら、大きな安全リスクをもたらします。

3. 強化学制と動的検出

主張チェック: 更新ロジック後に、assert(it->first == it->second.symbol)を追加し、開発段階で「同一性不一致」の問題を捕捉します。
ツール支援: テスト環境で ASan (AddressSanitizer) と UBSan (UndefinedBehaviorSanitizer) を有効にします。これらのツールは、無効なスタックメモリへのアクセスを正確に検出し、直ちにエラーを報告します。

結論

C++ における「テーブル参照エラー」はしばしば表象に過ぎず、その裏にある真相はメモリ管理契約の違反である。キー検索が正しくても、値が信頼できるとは限らない。特に、静的変数、グローバル変数、長寿命なコールバック関数などの長寿命オブジェクトを扱う際には、それらが捕捉している参照がスタックフレームの破棄によって失われていないか常に注意する必要がある。

wrk と JMeter の負荷テスト (またはパフォーマンス測定)

Fri, 19 Dec 2025 01:14:49 +0800

インターネットシステムにおける負荷テストにおいて、しばしば対照的なスタイルを持つ2つのツールに遭遇します。1つは極めて軽量で、最大限の帯域幅を追求するwrkであり、もう1つは機能が豊富で、実際のビジネスフローをシミュレートするJMeterです。

提示：コアなアイデアを整理し、科普記事を作成：HTTP 負荷テストツール、wrk vs Jmeter の違いについて、私が知っていること、wrk は 1 つのスレッドで複数の接続を行うテストに偏っており、Jmeter はより短接続モードに重点を置いており、設定によって長接続モードにも調整可能です。

コアアーキテクチャ：マルチスレッド vs イベント駆動

これは両者のパフォーマンス差の根本的な原因です。

1. JMeter: 伝統的な「一人一岗」制 (Thread-per-Request)

JMeter は Java で開発されており、古典的な マルチスレッドモデル を採用しています。

ロジック: 各コンカレントユーザー（Virtual User）は、JVM 内の物理的なスレッドに対応します。
コスト: スレッドは非常に高価なリソースです。同時数があっという間に数千に達すると、コンテキストスイッチング (Context Switch) とメモリ消費がテストマシン自体を著しく遅延させ、「ロードマシンがサーバーを押し倒す前に、自分自身が崩壊する」といった現象を引き起こします。

2. wrk：現代的な「多面手」制 (イベント駆動型)

wrk は C 言語で記述されており、コアとなるロジックは Redis と同じ ae イベントループフレームワークを利用しています（epoll/kqueue を使用）。

ロジック: wrk は各接続ごとにスレッドを作成しません。代わりに、極少数のスレッド (通常は CPU コア数に相当) のみ起動し、それぞれのスレッド内部でノンブロッキング I/O を通じて成千もの接続を同時に管理します。
利点: これが「一つのスレッドで複数の接続」という表現です。スレッド切り替えのオーバーヘッドを大幅に削減し、単一マシンで百万レベルの RPS (リクエスト毎秒) を実現できます。

连接モデル：短接続と長接続

ご指摘の接続パターンについて、より詳細な情報をご提供します。

1. JMeter の「重」と「軽」

JMeter はデフォルトで、実際のユーザーの行動をシミュレートする傾向があります。

短接続への偏り： デフォルト設定では、JMeter の古いバージョンや特定の構成によっては、積極的に接続を再利用せず、多数の TCP 握手が発生することがあります。
調整可能性： 「KeepAlive」を HTTP Request 中にチェックボックスで選択するか、user.properties ファイルで接続プールパラメータを調整することで、長接続を有効化できます。しかし、たとえ長接続を有効化したとしても、スレッドモデルの制限により、数十万レベルの同時長接続を維持することは困難です。

2. wrk の「快」と「狠」

wrk が設計されたのは、HTTP Keep-Alive の性能をテストするためです。

長接続戦略： wrk はテスト開始時に指定した接続数を確立（-c オプションを使用）し、テスト中に可能な限りこれらの接続を再利用します。
適用場面： Nginx やゲートウェイ（Gateway）、高負荷 API が極端な長接続ストレス下でスループットの限界をテストするのに非常に適しています。

比較表

特性	wrk	Apache JMeter
開発言語	C/Lua (スクリプト)	Java (GUI)

比較表

特性	wrk	Apache JMeter
並行モデル	イベント駆動 (epoll/kqueue)	マルチスレッド (ユーザーあたりスレッド)

比較表

特性	wrk	Apache JMeter
リソース消費	極低、単機スループット巨大	比較的高い、大規模同時接続には分散クラスタが必要

比較表

特性	wrk	Apache JMeter
ビジネス複雑度	低い。主に単一URLに焦点を当てている	極めて高い。複数ステップスクリプト、アサーション、エクストラクターをサポート

比較表

特性	wrk	Apache JMeter
テストシナリオ	静的API負荷テスト、容量評価	複雑なビジネス連携の負荷テスト、機能回帰テスト

深層比較表

特性	wrk	Apache JMeter
レポート機能	テキストのみの要約	非常に豊富、各種グラフやHTMLレポートをサポート

まとめ：どちらを選ぶべきか？

これらのツールは代替関係ではなく、補完関係にある：

選ぶワーク

サーバーの最大スループット (RPS) をテストしたい。
テスト対象は単一の API または静的リソース。
最小限のテストサーバーで最大のトラフィックを発生させたい。
Lua スクリプトを使ってリクエストをカスタマイズする経験がある。

JMeter を選択する

複雑なビジネスフロー（例：ログイン → 商品検索 → 購入 → 決済）をシミュレートする必要がある。
レスポンスタイム分布、エラー率などの詳細な指標を観察するための可視化されたインターフェースが必要である。
テストでは動的パラメータ（例：前のインタフェースから取得したトークンを次のインタフェースに渡す）を処理する必要がある。
チームはコマンドラインよりもグラフィカルツールに慣れている。

パスキーの仕組みと今後の展望について解説

Thu, 04 Dec 2025 22:14:06 +0800

背景説明、騰訊のCNBプラットフォームは微信ログインのみをサポートしており、通常のメールアカウント方式は提供されていません。その結果、グループ内で毎日何人かがあれこれ文句を言っていますし、見ていて本当に困ります。騰訊のプロダクトマネージャーが妥協案としてパスキーログインを導入しました。

毎日、私たちは危険な行為を繰り返しています：パスワードを入力することです。複雑なルール（大文字、小文字、特殊記号、数字）があっても、データ漏洩、フィッシング詐欺、そして「パスワードを忘れてしまった」という悩みが誰一人として解消されません。

テクノロジー大手（Apple, Google, Microsoft）とFIDOアライアンスが最終的な解決策を提供しました：**パスキー（通行鍵）**です。それは単にパスワードの「代替」ではなく、完全にパスワードを「消滅」させるものです。

ログインプロセスは、パスワードの検証から、現在使用しているデバイスの信頼性を検証することへと変更されました。

パスキーの仕組みの詳細、管理における利用方法、関連情報を整理し、インターネット公開用の記事を作成

パスキーとは？

簡単に言うと、パスキーはデバイスに保存されているデジタル証明書です。 従来の「ユーザー名 + パスワード」の代わりになります。Passkeyに対応しているウェブサイト（Google、GitHub、Adobeなど）にログインする際、文字を入力する必要がなく、顔認証（Face ID）、指紋（Touch ID）、またはデバイスPINコードで確認するだけで、瞬時にログインできます。

主な違い： パスワードは覚えている文字列（盗まれたり、推測されたり、忘れたりしやすい）であり、パスキーは所有している資産（暗号化された鍵がデバイスのハードウェアに保存されている）です。

パスキーの仕組み：非対称暗号化

パスキーの裏側には、WebAuthn 標準と FIDO2 プロトコルがあります。理解するためには、公開鍵暗号 (Public Key Cryptography) について知っておく必要があります。

パスキーを「鍵」と「錠」のペアだと想像してみてください：

秘密鍵 (Private Key)：
- どこに保存されますか？ 自分のデバイス（iPhone のセキュアエンクレーブ、PC の TPM モジュール、パスワードマネージャーなど）に安全に保存されます。
- 特性： 極めて機密性が高く、絶対にサーバーに送信されず、デバイスから離れることもありません。
- 役割： それはあなたの「電子署名ペン」です。
公開鍵 (Public Key)：
- どこに保存されますか？ ウェブサイト/アプリのサーバーにアップロードされ、保存されます。
- 特性： 公開されており、機密性はありません。
- 役割： それはあなたの署名を検証する「現行機」です。

ログイン手順の詳細（ハンドシェイク）

Passkey を使用してログインする際、巧妙な「チャレンジ-レスポンス」メカニズムが実行されます。

ログインの開始: あなたが「ログイン」をクリックすると、ウェブサイトサーバーはあなたのデバイスにランダムな数学の問題 (Challenge) を送信します。
ローカルでの検証: 携帯電話/コンピューターにプロンプトが表示され、生体認証（顔認証/指紋）でロック解除を求められます。
- 注記: このステップは単にデバイスが秘密鍵を使用することを許可するものであり、生体情報はアップロードされません。
デジタル署名: ロック解除が成功すると、デバイスは秘密鍵を使用してその数学の問題に「署名」を行い、署名結果をサーバーに送信します。
サーバーでの検証: サーバーは、あなたが以前に保存した公開鍵を使用してこの署名を検証します。署名が有効であれば、サーバーは「検証済みのユーザーが秘密鍵を持っていることを確認」し、ログインを許可します。

パスキーがなぜパスワードよりも安全なのか？

パスキーは、従来のパスワードが抱える3つの主要な問題点（死すべき問題）を解決します：

完全な免疫「フィッシング攻撃」（Anti-Phishing）

これはPasskeyの最も強力な機能です。Passkeyプロトコルにおいて、**オリジンバインディング（Origin Binding）**が強制的に含まれています。

シナリオ： ハッカーが偽のg00gle.comを作成してあなたをだますログインを試みます。
結果： ユーザーエージェントとシステムは、現在のドメインがPasskey登録されたドメインgoogle.comと一致しないことを検出し、認証の開始を拒否します。パスワードを入力する機会すらありません。

サーバー漏洩も無意味

たとえハッカーがGoogleのサーバーを侵入し、すべてのデータベースを盗んでも、彼らが手に入れるのは単なる公開鍵だけです。

公開鍵は秘密鍵を導き出すために使用できません。ハッカーが公開鍵を持っていることは、まるで鍵を持っていることと同じですが、開錠するための鍵（秘密鍵）があなたの携帯電話の中にあり、したがってあなたのアカウントにログインできないということです。

「弱いパスワード」は存在しない

ユーザーは、「123456」のような弱いパスワードを設定する必要がなく、鍵はアルゴリズムによって生成される強力な暗号化データで構成されているためです。

パスキーが「ログイン管理」を変えるとは

これまで、1Password、LastPass、Chromeブラウザなどで長い文字列を記録に頼ってきました。しかし、今、「ログイン管理」は根本的に変化しています。

クロスデバイス同期 (Passkey Sync)

初期のハードウェアキー (例: YubiKey) は紛失しやすいものです。現在の Passkey はクラウド同期に対応しています：

Apple エコシステム: iCloud キーチェーンとの同期を通じて。iPhone で作成した Passkey が Mac 上で自動的に利用可能になります。
Google エコシステム: Google パスワードマネージャーとの Android および Chrome の同期。
サードパーティ管理ツール: 1Password、Dashlane など、多くのツールが Passkey を完全にサポートしています。これにより、Windows PC で iPhone に保存されている Passkey を使用してログインできるようになります (エコシステムの横断)。

クロスデバイス認証 (QRコードによる)

もし、ネットカフェのPC（Windows）でログインしたいが、あなたのPasskeyがiPhoneにある場合、どうすればいいでしょうか？

ウェブページから「別のデバイスでログイン」を選択します。
画面にQRコード（FIDO Cross-Device Flow）が表示されます。
iPhoneのカメラでQRコードをスキャンします。
携帯電話がBluetoothを通じてPCと近距離接続（現場であることを証明）し、生体認証を行います。
PCでのログインが成功します。

「秘密の管理」から「信頼の管理」へ

将来のログイン管理は、個々の明文パスワードを確認するのではなく、信頼されたデバイスを管理することになります。

あなたは次のように確認できます：「私のGitHubアカウントには、iPhoneとMacBookが関連付けられています。」
携帯電話を紛失してしまった場合でも、サーバー側（またはクラウドアカウント）でそのデバイスの公開鍵へのアクセス権を無効にするだけで済みます。

表格比較：パスワード vs. パスキー

维度	従来のパスワード (Passwords)	通行キー (Passkeys)
記憶負担	高 (複雑な文字を覚える必要がある)	無 (覚えなくてもよい)

表格比較：パスワード vs. パスキー

维度	従来のパスワード (Passwords)	通行キー (Passkeys)
フィッシングリスク	極高 (騙されて入力してしまう可能性が非常に高い)	ゼロ (ドメインに強制的に紐付けられるため)

表格比較：パスワード vs. パスキー

维度	従来のパスワード (Passwords)	通行キー (Passkeys)
サーバー漏洩	危険（撞列/密変更が必要）	安全（公開鍵の漏洩は影響なし）

表格比較：パスワード vs. パスキー

维度	従来のパスワード (Passwords)	通行キー (Passkeys)
ログイン体験	遅い (入力またはコピー＆ペースト)	速い (ワンクリック生体認証)

表格比較：パスワード vs. パスキー

维度	従来のパスワード (Passwords)	通行キー (Passkeys)
依存性	大脑またはパスブックへの依存	デバイス（スマートフォン/コンピューター）への依存

現状の課題と未来

Passkey は非常に素晴らしいですが、普及には時間がかかります：

プラットフォームの壁: 標準は統一されていますが、Apple、Google、Microsoft がそれぞれのエコシステム内で最もスムーズな体験を提供し、Android 携帯を iPad とペアするなど、クロスエコシステムの移行は可能ですが、わずかな摩擦があります。
デバイスへの依存: 信頼できるすべてのデバイスを紛失し、クラウドバックアップがない場合、アカウントの復元は困難です（通常、リカバリーコードが必要です）。
旧システムとの互換性: 多くの古いウェブサイトや社内ネットワークが WebAuthn 標準をサポートしていません。

まとめ

パスキーはパスワードのアップグレード版ではなく、インターネット認証の一種である根本的な再構築です。現代デバイスの生体認証能力と公開鍵暗号技術を活用し、セキュリティを金融レベルまで向上させると同時に、ユーザーエクスペリエンスを極限まで簡素化します。

一般ユーザーにとって、サポートされているプラットフォーム（Google, Apple, Microsoft, Amazon など）でパスキーをできるだけ早く有効にすることは、個人情報のデジタルセキュリティの投資として最も価値の高いものとなります。

AIは「鈍化」しているのか？パラメータ精度と推論コストの駆け引きを解明

Thu, 04 Dec 2025 21:58:09 +0800

最近、様々なプログラミング大規模言語モデルの交流圏に浸り、モデルの知能低下（モジュール降智）が最も多く言及される問題となっている。

ローカルデスクトップPCへのデプロイメントは、量子化されたモデルであり、まさに知能低下後のバージョンである。
vibe coding が非常に人気があるため、現在の大規模言語モデルが出力するコンテンツの中で、コードが最も価値のある産物である可能性はないか？

今回のプロンプトは一度最適化され、ちょうどモデルの知能低下を解消したタイミングだった。大規模言語モデルからの回答は、プロンプトの最適化、より詳細なタスク計画、より明確な出力要件であった。

この問題に対する適切なプロンプト：現在、多くの大手企業が大規模言語モデルサービスを提供しており、ユーザーからモデルの知能低下に関するフィードバックが見られることがある。専門的な観点からは、パラメータの精度、推論コストを考慮して記事を作成する。科普文として、長すぎないようにする。最適化されたバージョン：

あなたは経験豊富なAI業界技術専門誌作家です。あなたの目標は、一般読者向けでありながら内容が専門的な中国語の科普記事を書くことです。

以下の手順で考え、作成してください。
1. 大纲の策定：まず、明確な3段構成の記事大綱（例：導入、精度分析、コストとアーキテクチャ分析、結論）を作成してください。
2. 内容への焦点を当てる：文章は、ユーザーが指摘する「知能低下」現象を深く分かりやすく説明し、コアな分析ポイントは**パラメータの精度（量子化）** と **推論の運用コスト** を中心に展開する必要があります。
3. 文字数とフォーマット：最終的な記事の長さは600字以内である必要があります。明確な`##`タイトルを使用して段落を区切り、**太字**で本文中の重要な専門用語（例：量子化、MoE、FP16）を強調してください。

はじめに

論理を明確にし、科普的な要件を満たすため、以下の構造を策定しました。

導入: ユーザーが認識する現実を確認し、核心となる矛盾—大規模なユーザー基盤の背景下で、サービスプロバイダーは「知的能力の頂点」と「サービスの可用性」の間でバランスを取る必要がある—を引き出します。
精度分析（コアポイント1）: パラメータと精度の関係を説明します。FP16と量子化（INT8/INT4）を比較し、「画像の圧縮」の類比を用いて、精度が低下するとロジックが劣化する理由を示します。
コストとアーキテクチャ（コアポイント2）: 推論コストを分析します。MoEアーキテクチャとスパースアクティベーションメカニズムを紹介し、費用削減と高速化のためにモデルが「怠惰」になる方法を説明します。
結論: このような「知的能力の低下」は、商業化普及の不可避な道筋（三途の川）であるとまとめます。

本文

最近、多くのユーザーから大規模言語モデルが以前ほど「賢く」なくなったというフィードバックがありました：論理が単純化され、指示の遵守が悪化し、場合によっては意味不明な発言（無駄話）まで発生します。これはすべて錯覚だけではありません。技術的な観点からは、この「知能低下」現象は、大手企業が膨大なユーザーに対処するために、推論コストとサービス速度のバランスを取るための技術的な妥協であると考えられます。

精度「縮水」：4Kから720Pへの代償

大規模モデルの「知能」は、主に数千億個のパラメータに格納されています。理想的な状態においては、これらのパラメータが高精度の FP16（16ビット浮動小数点数）形式で動作し、極微細な意味の違いを捉えることができます。しかし、このような高精度は、膨大なVRAM（ビデオメモリ）の占有と、遅い計算速度をもたらします。

数億人のユーザーがスムーズに利用できるようにするため、サービスプロバイダーは一般的に量子化（Quantization）技術を採用しています。これは、パラメータの精度を FP16 から INT8 甚至 INT4 に圧縮する手段です。

これは、4K高精細映画を720Pストリーミングに圧縮するようなものです。剧情（大まかなロジック）は変わっていませんが、画面の詳細（微細な論理的関連性、複雑な指示の実行詳細）が失われます。このような「有損圧縮」により、モデルが複雑なタスクを処理する際の表現力が低下し、ユーザーに「変に賢くなった感じ」を与えることになります。

コスト圧迫：脳を「部分的に休ませる」

精度だけでなく、推論の運用コストがもう一つの重要な要素です。AI に質問をするたびに、サーバーは膨大な行列演算を実行し、電気代とハードウェアの劣化は驚くほど大きくなります。

コストを下げるために、現代の大規模モデルでは、MoE（Mixture of Experts、混合専門家モデル）アーキテクチャが広く採用されています。従来のモデルが毎回すべてのニューロンを活性化するのとは異なり、MoE は 疎な活性化戦略を採用し、あなたの質問に対して、システムは関連する「専門家」ネットワークの一部分だけを呼び覚まし、残りは休眠状態に保ちます。

これは計算量を大幅に削減しますが、ルーティングアルゴリズム（Router）が負荷分散や演算コストの節約のために、あなたの複雑な数学的問題を「文学的専門家」に割り当てるか、速度のために専門家の呼び出し数を犠牲にする場合、出力品質は変動し、低下する可能性があります。

結論

したがって、「降智」と呼ばれる現象は、AIが研究室から大規模な商用化へと移行する際の必然的な痛みを伴うものです。パラメータ精度における抑制とモデルアーキテクチャの最適化は、誰もがAIを使いこなせるように、メーカーが「絶対的な知能」と「コスト効率」の間で模索している微妙なバランスです。

Cloudflareが世界的なネットワーク障害を引き起こし、X（旧Twitter）、ChatGPTなどの主要ウェブサイトがダウン。株価は大幅に下落しました。

Tue, 18 Nov 2025 22:34:02 +0800

このサイトのメインドメインはGitHub Pages、ブログのサブドメインはVercel加速で運用していましたが、バックエンド管理ページが古臭くて退却しました。本来静かに育っていた水面下での記事ですが、ブログ界隈のグループ内の情報が絶えず流れ込み、これは通常では非常に静かな状態です。開いてみたらCFがダウンしており、多くのブロガーさんのサイトが開けなくなっていました。

インターネットインフラとしての基本的な問題であり、故障がこれほど長く続いているべきではありません。株価の大暴落は予想外でした。

Cloudflareの障害により、多くの知名ウェブサイトにアクセスできず、事前に株価下落、関連情報を整理し、記事を作成

2025年11月18日（火）発表 — 本日（11月18日）、米国株式市場のオープン前に、主要なグローバルインターネットインフラストラクチャサービスプロバイダーであるCloudflareが大規模なネットワーク障害に見舞われ、数千ものそのサービスの依存している著名なウェブサイトやアプリケーションがダウンまたはアクセス困難になりました。

この事態を受け、Cloudflare（ニューヨーク証券取引所：NET）の株価はオープン前の取引中に下落しました。

🌍 世界規模での障害が、主要サービスを次々と「ダウン」させる

この障害は火曜早朝（米国東部時間午前7時頃、協定世界時刻午後11時48分頃）に発生し始めました。世界各地のユーザーから、X (旧Twitter)、OpenAI (ChatGPT) の人工知能サービス、Spotify の音楽ストリーミングサービス、League of Legends および Valorant などのゲームプラットフォーム、BitMEX や DefiLlama などの暗号通貨取引所など、多数の人気サービスへのアクセスができないとの報告がありました。これらのウェブサイトにアクセスしようとしたユーザーは、一般的に「500 Internal Server Error」（サーバー内部エラー）というメッセージが表示されました。Cloudflare はインターネットの「仲介者」として、世界数百万のウェブサイトにコンテンツ配信 (CDN) および DDoS 対策サービスを提供しており、そのネットワーク内のわずかな「不安定さ」が瞬く間に世界規模での連鎖反応を引き起こしました。

📉 市場反応は迅速、(NET) 盤前株価下落

インターネットの重要なインフラストラクチャの一つであるCloudflareサービスの安定性は投資家の関心を強く惹いていた。

故障消息が伝わった後、資本市場は迅速に反応した。Cloudflare (NYSE: NET) の株式は火曜日の盤前取引において顕著な売り圧力となった。金融データによると、株価は約 3.5%～4% 下落し、前回の取引日（11月17日）の約202.25米ドルからの閉場価格から、一時195米ドル付近まで下落した。

これは投資家が今回のサービス中断の深刻さと、それが会社名誉や短期収益に与える可能性のある影響に対する懸念を反映したものだ。

🛠️ 公式声明：已定位问题，正在修复

Cloudflare 官方迅速在其系统状态页面上确认了这一事件。公司于北京时间今天下午（2023年11月18日 13:09 UTC）更新状态称：

“问题已经确定，正在实施修复。”

🛠️ 公式声明：问题已定位，正在修复

Cloudflare 的报告表明，此次事件被定性为“全球ネットワークに問題が発生”（Gukan netwāku ni mondai ga hassei）——“全球网络遇到问题”，并伴随“広範な500エラー”（Kōhan no 500 ērā) ——“大范围500错误”。

Cloudflare 表示，他们正在努力缓解此问题，并且已经看到服务开始恢复，但警告称在修复工作继续进行期间，客户可能仍会观察到“正常よりも高いエラー率”（Nōtō yori takai error-ritsu）——“高于正常的错误率”。

截至发稿时，部分网站的访问已开始逐步恢复，但全球ネットワークの遅延とエラー率は依然として高水準にある。我们将持续关注事态的后续发展。

MySQL のギャップロックを理解する：原理から金融レベルの選定まで

Tue, 18 Nov 2025 22:29:25 +0800

システムサービス間のデータ同期において、最近の変更により特定のインターフェースのデータ量が増加し、頻繁に死鎖が発生しました。同僚による調査の結果、間隙ロックが原因であることが判明しました。MySQL の利用は少ないため、記録として残します。

MySQL の間隙ロック、背景、原理、間隙ロックを閉じる方法、閉じた際の注意点；あなたは経験豊富なデータベース DBA として、私の問題に対して拡張的な分析と補足情報を提供してください。幻読とは何ですか？主流の大手企業は RC モードか RR モードを選択しますか？私は金融業界の券商システムを担当しており、あなたはそのようなシステムに最適なソリューションを提案してください。上記の質問を整理し、ドキュメントを作成してください。

MySQL において、特に高負荷環境下では、「ロック」を回避することはできません。ギャップロックは InnoDB エンジンにおける重要な特性ですが、同時にパフォーマンスボトルネックや死鎖の根源となることもあります。

この記事では、ギャップロックの核心、利点・欠点を迅速に整理し、あなた（特に金融業界）に対して明確なアーキテクチャ選定のアドバイスを提供します。

幻読とギャップロックとは何か？

幻読 (Phantom Read): トランザクション中に、例えば ID > 100 の範囲を最初に検索し、10件のデータを取得する。その後、別のトランザクションが ID=101 を挿入してコミットすると、2回目の検索で11件に増加してしまう。この「幻のような」追加されたデータが、その名も「幻読」と呼ばれる。
ギャップロック (Gap Lock): MySQL は RR（可繰り返し読み） 隔離レベル下において、「幻読」の問題を解決するために発明された。行自体をロックするのではなく、データの間の「隙間」をロックする。
- 作用: 他のトランザクションがその「隙間」に INSERT を実行できないように防止する。
- コスト: ロック範囲が広がり、コンカレンシー能力が低下し、死鎖を引き起こす可能性がある。

間隙ロックを「閉じる」方法

最も直接的な方法は、データベースの分離レベルをRR (Repeatable Read) からRC (Read Committed) に降下させることです。

-- 現在のセッションの分離レベルをRCに設定
SET SESSION transaction_isolation = 'READ-COMMITTED';

-- 永続的に変更（my.cnf を修正し、mysqld を再起動する必要があります）
-- [mysqld]
-- transaction-isolation = READ-COMMITTED

⚠️ 关闭の影響（即 RC レベルの特性）

パフォーマンス向上: ギャップロックがなくなるため、ロック粒度が細かくなり、同時スループットが大幅に向上します。
死鎖減少: ほとんどのギャップロックによる死鎖は解消されます。
幻読/不整合な読みが発生する: これは RC レベルの「特性」であり、トランザクション内で二回クエリを実行しても結果が一致しない可能性があります。
【必須要件】ROW形式のBinlogとの併用が必要: RC レベルを使用する場合、必ず binlog_format を ROW に設定する必要があります。そうしないと、ギャップロックの保護がないため、主従レプリケーション中に主従データが不整合になる可能性があります。

主要ベンダーの選択：RC または RR？

回答：ほとんどの主要なインターネット企業は RC (Read Committed) + ROW Binlog モードを選択しています。

理由： インターネットビジネス（例：eコマース、ソーシャル）は、極めて高い同時性を追求します。RR のロックスロットによる頻繁なロック待ちや死鎖に耐えられません。
トレードオフ： データベースレベルでの「読み取り追跡可能」を放棄し、代わりにアプリケーション層でオプティミスティックロック（バージョン番号、CAS など）などの方法を用いて、重要なビジネス（例：在庫、残高）の論理的一貫性を保証します。

金融業界（証券会社）における選択の指針

データの一貫性要件が極めて高い証券会社システムの場合、シナリオ別対応を推奨します：

方案一：コア取引システム（高同時多接続、低遅延）

推奨：RC (Read Committed) + ROW Binlog + アプリケーション層のオプティミスティックロック

シナリオ： 注文撮合、注文、資金決済。
理由： 取引システムの同時アクセス負荷は、秒殺サイトに匹敵する。RR の間隙ロックが性能ボトルネックとなり、深刻なロック競合や死鎖を引き起こすことは、取引システムでは容認できない。
対策： RC を使用して高性能を確保し、アプリケーションコード（例: Java）で UPDATE ... WHERE balance > ? または CAS バージョン番号メカニズムを使用して資金の安全性を保証し、オーバーサブスクリプションを防ぐ。

方案二：清算対帳システム（バッチ処理、高整合性）

推奨：RR (Repeatable Read)

シナリオ: 期末バッチ対帳、レポート生成、日終清算。
理由: バッチ処理タスクは、「絶対的な整合性」のあるデータスナップショット上で実行する必要があります。それは RR レベルが提供する能力を必要とし、統計プロセス全体を通して「幻読」が発生しないことを保証し、最終勘定帳が正確であることを確認します。

まとめ

レベル	メリット	デメリット	適用シナリオ
RR (デフォルト)	幻読を解決し、データの一貫性が高い	并行性が低い、死鎖しやすい（ギャップロック）	レポート、決済、データの一貫性要求が極高く、並行性が少ないシナリオ

まとめ

レベル	メリット	デメリット	適用シナリオ
RC	并行性が高く、死鎖が少ない	ファントム読み、不整合な読みが得られる	高い同時性を持つコアビジネス（例：ECサイト、金融取引）で、ROW Binlogと組み合わせて使用

まとめ

証券会社のコアシステムにおいて、RC + ROW Binlog はパフォーマンスと整合性を両立させる主要なアーキテクチャソリューションですが、データ整合性の保証をアプリケーション層でより多く担うことを要求します。

ローカル開発の苦悩：なぜ `nul` ファイルを削除できないのか？複合型ファイルシステムの問題への解決策

Sat, 08 Nov 2025 16:37:46 +0800

ソフトウェア開発の日常業務において、私たちはしばしば「厄介な小さな問題」に遭遇します。それらは一見単純に見えますが、数時間という貴重な時間を費やしてしまうこともあります。特に、Windows システム上で特定のファイルを削除する（特に開発ツールチェーンによって意図せず生成されたファイル）ことは、「大惨事」の典型的な例です。

私もそのような「地獄級」の問題に遭遇しました。ローカルで開発していた際に、プロジェクト内に莫名其妙に nul という名前のファイルが作成されてしまいました。Windows エクスプローラーや CMD コマンドラインを試しましたが、システムは「ファイルが見つからない」または「削除できません」と表示していました。このファイルはまるで幽霊のように、頑固にもプロジェクトディレクトリに根付いていました。

フェーズ１：標準的な試行と「標準」の無効な解決策

問題に遭遇したとき、私の第一反応は “nul ファイル” です。 なぜ nul ファイルが特殊なのか？ Windows の歴史を知る開発者は、nul が「穴」と呼ばれるものだと知っているかもしれません。Windows (およびそれ以前の DOS) システムでは、NUL、CON、PRN、AUX などの名前は予約されたデバイス名です。NUL は「空デバイス」（Unix/Linux の /dev/null に相当）を表します。 Windows のファイルシステム API が、nul という名前の「ファイル」を操作しようとすると、それは空デバイスを操作しているものとして扱われ、通常のファイル名を操作しようとしているものとは区別されません。したがって、ファイルの削除やリネームなどの標準的なファイル操作はすべて失敗します。 nul ファイルがどのように生成されるのか？ これは通常、クロスプラットフォーム開発ツール（Git、Node.js スクリプト、Python スクリプトなど）の「問題」によるものです。これらのツールは POSIX (Unix 互換) 標準に基づいており、それらから見ると nul は単なるファイル名です。Windows 上で実行される場合、API を直接呼び出すのではなく、この Windows で「消化不良」を起こすようなファイルを生成することがあります。 オンラインで推奨されている「標準的な解決策」 私は迅速にインターネットを検索し、私だけが最初にこの問題に遭遇したわけではないことを知りました。コミュニティはいくつかの「高度な」解決策を提唱していました：

\\.\ 構文の使用: CMD で特別な「長いパス」構文を使用して、Windows の名前チェックを回避します。

del \\.\C:\your\project\path\nul

Git Bash の使用: Git Bash は軽量の Unix 環境を提供し、nul を特殊なデバイスとして扱わないためです。

rm nul

WSL (Windows Subsystem for Linux) の使用: WSL に入って Windows ディスクをマウントし、Linux の rm コマンドを使用してファイルを削除します。

rm /mnt/c/your/project/path/nul

しかし、これらの方法どれも私には効果がありません！ WSL でも Git Bash でも、rm nul を実行しても、「No such file or directory」（ファイルまたはディレクトリが見つかりません）というエラーが発生しました。これは、私が想像していたよりも問題が複雑であることを示唆していました。

フェーズ２：閃光一瞬——それは「多重問題の重ね合わせ」なのか？

nul ファイルが実際に存在する場合、Unixツールはなぜそれを「見つからない」と報告するのか？

私は疑念を抱き始めた：問題は nul ファイル自体だけでなく、その「居場所」、つまり存在するディレクトリにあるのではないか？

そこで私は直ちにGit Bash（これが重要だ、Windowsのエクスプローラーでは異常が表示されない可能性があるから）を開き、nul ファイルが存在する親ディレクトリに移動して、ls -la (すべてのファイル（隠されたファイルを含む）をリストし、詳細情報を表示) を実行した。

そこでついに「盲点」を発見した：

その nul ファイルが保存されているディレクトリは、そのディレクトリ名自体に無効な文字が含まれていた！

フェーズ2：閃きの一瞬——「マルチ問題の重ね合わせ」なのか？

私のケースでは、このディレクトリ名はスペースやピリオド（.）で終わる名前であるか、あるいはWindowsが許可しない特殊文字（?, *, :など）を含むものである可能性があります。これらはすべて、開発ツールがクロスプラットフォーム同期する際に「持ち込まれた荷物」です。

例えば、Git Bashでディレクトリが表示されると "my-app " (末尾のスペースに注意) や "my-app." のようになります。 これが問題の本質です！

問題A： nul という「不正な」ファイルがあります。
問題B： "my-app " という「不正な」ディレクトリがあります。 rm /path/to/"my-app "/nul を実行しようとすると、WindowsシステムとUnixツールが「混乱」します。Windows APIは、この不正な文字を含むパスを正しく解析できないためで、Git BashやWSLは「この不正なディレクトリを見る」ことができますが、内部の nul ファイルにアクセスしようとすると、パス解析の複合的な問題により失敗する可能性があります。

フェーズ3：釜底抽薪——パスを徹底的に排除する

「ファイルパス」と「ファイル名」という二つの問題が特定されたことで、解決策は明確になりました。nul ファイルを削除しようとするのではなく、その「不正な」親ディレクトリを直接削除するのです！

私の最終的な解決手順は以下の通りです。

Git Bashを開く: これが唯一、「見えない」か「処理できない」これらの不正な名前を正しく認識し、操作できるツールです。
問題ディレクトリの親ディレクトリに移動する:
問題ディレクトリの実際の名称を確認する:
「究極の削除」を実行する: rm コマンドの -r (再帰) と -f (強制) オプションを引用符で囲み、使用してそのディレクトリ全体を削除します。

コマンドを実行すると、私を悩ませていた、nul ファイルを含む、本来も不適切な名前のディレクトリが、ついに私のファイルシステムから完全に消去されました。

Keepalived + HAProxy を用いた高可用ロードバランシングの構築

Fri, 19 Sep 2025 09:45:55 +0800

現代インターネットアーキテクチャにおいて、高可用性はシステム設計における重要な検討事項です。本稿では、KeepalivedとHAProxyを使用して高可用なロードバランシングクラスタを構築し、サービスの継続性と信頼性を確保する方法について詳細に解説します。

実際の構成部分が検証されていないため、本文の構成はAIによって作成されています

この画像は「タスク計画」というタイトルで、おそらくタスクのスケジュールやリストを示していると思われます。詳細な翻訳のためには画像の具体的な内容を確認する必要がありますが、一般的な表現として以下のように記述できます。

タスク計画 (Tasukku Keikaku) - 任務計画 (Tanmoku Keikaku)

技術概要

Keepalived の概要

Keepalived は、VRRP（Virtual Router Redundancy Protocol）プロトコルを基盤とした高可用性ソリューションであり、主にサーバーのフェイルオーバーとロードバランシングを実現するために使用されます。

主な特徴：

VRRP プロトコル対応: 仮想IPアドレスの主/備切り替えの実装
健康チェック: サービスの状態を監視し、自動的に故障トランスファーを実行
設定の簡素化: 設定ファイルのみで複雑な高可用性アーキテクチャを実現
軽量: リソース消費量が少なく、性能に優れている

動作原理： Keepalived は、VRRP プロトコルを通じて複数のサーバー間で仮想IPアドレスを共有します。正常時には、主サーバーが仮想IPアドレスを持ちサービスを提供し、主サーバーが故障した場合、備サーバーが自動的に仮想IPアドレスを接管し、サービスの停止を防ぎます。

HAProxy の概要

HAProxy は、高性能なロードバランサーおよびリバースプロキシサーバーであり、高負荷環境で広く利用されています。 主な機能：

ロードバランシング: 複数のロードバランシングアルゴリズムをサポート
ヘルスチェック: バックエンドサーバーの状態をリアルタイムに監視
SSL終端: HTTPS トラフィックの処理をサポート
統計モニタリング: 詳細な実行状態の統計情報を提供 利用シーン：
Web サービスのロードバランシング
データベース接続プーリング
マイクロサービスゲートウェイ
API インターフェースのプロキシ

アーキテクチャ設計

全体アーキテクチャ

                    ┌─────────────────┐
                    │   Client        │
                    └─────────┬───────┘
                              │
                    ┌─────────▼───────┐
                    │  Virtual IP     │
                    │  (VIP)          │
                    └─────────┬───────┘
                              │
              ┌───────────────┼───────────────┐
              │               │               │
    ┌─────────▼───────┐              ┌─────────▼───────┐
    │   HAProxy-1     │              │   HAProxy-2     │
    │  (Master)       │◄────────────►│   (Backup)      │
    │  + Keepalived   │   VRRP       │  + Keepalived   │
    └─────────┬───────┘              └─────────┬───────┘
              │                                │
              └──────────┬─────────────────────┘
                         │
        ┌────────────────┼────────────────┐
        │                │                │
┌───────▼───────┐ ┌──────▼──────┐ ┌───────▼───────┐
│  Web Server 1 │ │ Web Server 2│ │  Web Server 3 │
│   Backend     │ │   Backend   │ │   Backend     │
└───────────────┘ └─────────────┘ └───────────────┘

全体アーキテクチャ

                    ┌─────────────────┐
                    │   クライアント        │
                    └─────────┬───────┘
                              │
                    ┌─────────▼───────┐
                    │  仮想IP (VIP)       │
                    └─────────┬───────┘
                              │
              ┌───────────────┼───────────────┐
              │               │               │
    ┌─────────▼───────┐              ┌─────────▼───────┐
    │   HAProxy-1     │              │   HAProxy-2     │
    │  (マスター)       │◄────────────►│   (バックアップ)      │
    │  + Keepalived   │   VRRP       │  + Keepalived   │
    └─────────┬───────┘              └─────────┬───────┘
              │                                │
              └──────────┬─────────────────────┘
                         │
        ┌────────────────┼────────────────┐
        │                │                │
┌───────▼───────┐ ┌──────▼──────┐ ┌───────▼───────┐
│  Web Server 1 │ │ Web Server 2│ │  Web Server 3 │
│   バックエンド     │ │   バックエンド   │ │   バックエンド     │
└───────────────┘ └─────────────┘ └───────────────┘

コンポーネントの説明

仮想IP (VIP): 顧客がアクセスする統一的なエントリポイント
HAProxy 主備ノード: ロードバランシングサービスを提供し、Keepalivedを使用して高可用性を実現します
バックエンドサーバー: 実際にサービスを提供するWebサーバー

環境準備

サーバ計画

役割	IPアドレス	ホスト名	サービス
HAProxy 主ノード	192.168.1.10	lb-master	HAProxy + Keepalived

サーバ計画

役割	IPアドレス	ホスト名	サービス
HAProxy 備後端	192.168.1.11	lb-backup	HAProxy + Keepalived

サーバー構成

ロール	IPアドレス	ホスト名	サービス
仮想IP	192.168.1.100	-	VIP

サーバー計画

役割	IPアドレス	ホスト名	サービス
Webサーバー1	192.168.1.20	web1	Nginx/Apache

サーバー構成

ロール	IPアドレス	ホスト名	サービス
Webサーバー2	192.168.1.21	web2	Nginx/Apache

サーバー計画

ロール	IPアドレス	ホスト名	サービス
Webサーバー3	192.168.1.22	web3	Nginx/Apache

ソフトウェアのインストール

HAProxy主備サーバに必要ソフトウェアをインストールします：

# CentOS/RHEL
yum install -y haproxy keepalived

# Ubuntu/Debian
apt-get update
apt-get install -y haproxy keepalived

# サービスを起動時に自動開始にする
systemctl enable haproxy keepalived

Keepalived 設定

主ノード設定 (lb-master)

/etc/keepalived/keepalived.conf ファイルを作成します：

! Configuration File for keepalived

global_defs {
    router_id LB_MASTER
    script_user root
    enable_script_security
}

# HAProxyサービスのステータスを確認するスクリプト
vrrp_script chk_haproxy {
    script "/etc/keepalived/check_haproxy.sh"
    interval 2
    weight -2
    fall 3
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword123
    }

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        chk_haproxy
    }

    notify_master "/etc/keepalived/notify.sh master"
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault "/etc/keepalived/notify.sh fault"
}

備中节点配置 (lb-backup)

/etc/keepalived/keepalived.conf ファイルを作成します：

! keepalived の構成ファイル

global_defs {
    router_id LB_BACKUP
    script_user root
    enable_script_security
}

vrrp_script chk_haproxy {
    script "/etc/keepalived/check_haproxy.sh"
    interval 2
    weight -2
    fall 3
    rise 2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mypassword123
    }

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        chk_haproxy
    }

    notify_master "/etc/keepalived/notify.sh master"
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault "/etc/keepalived/notify.sh fault"
}

HAProxy健康チェックスクリプト

/etc/keepalived/check_haproxy.shというHAProxyの健康チェックスクリプトを作成します：

#!/bin/bash

# HAProxyプロセスが実行中か確認
if [ $(ps -C haproxy --no-header | wc -l) -eq 0 ]; then
    # HAProxyを起動を試行
    systemctl start haproxy
    sleep 2

    # 再度チェックし、まだ実行されていない場合は終了
    if [ $(ps -C haproxy --no-header | wc -l) -eq 0 ]; then
        exit 1
    fi
fi

# HAProxyポートがリッスン中か確認
if ! netstat -tuln | grep -q ":80 "; then
    exit 1
fi

exit 0

状態通知スクリプト

/etc/keepalived/notify.sh という状態通知スクリプトを作成します：

#!/bin/bash

TYPE=$1
NAME=$2
STATE=$3

case $STATE in
    "MASTER")
        echo "$(date): Became MASTER" >> /var/log/keepalived-state.log
        ;;
    "BACKUP")
        echo "$(date): Became BACKUP" >> /var/log/keepalived-state.log
        ;;
    "FAULT")
        echo "$(date): Fault detected" >> /var/log/keepalived-state.log
        ;;
    *)
        echo "$(date): Unknown state: $STATE" >> /var/log/keepalived-state.log
        ;;
esac

スクリプトの実行権限を設定します：

chmod +x /etc/keepalived/check_haproxy.sh
chmod +x /etc/keepalived/notify.sh

HAProxy 設定

メイン設定ファイル

主備ノード上で同じHAProxyの設定ファイル /etc/haproxy/haproxy.cfg を作成します：

global
    log 127.0.0.1:514 local0
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

defaults
    mode http
    log global
    option httplog
    option dontlognull
    option log-health-checks
    option forwardfor except 127.0.0.0/8
    option redispatch
    retries 3
    timeout http-request 10s
    timeout queue 1m
    timeout connect 10s
    timeout client 1m
    timeout server 1m
    timeout http-keep-alive 10s
    timeout check 10s
    maxconn 3000

# ページ設定の統計
listen stats
    bind *:8080
    stats enable
    stats uri /stats
    stats realm HAProxy\ Statistics
    stats auth admin:password123
    stats refresh 30s

# 前端設定
frontend web_frontend
    bind *:80
    default_backend web_servers

# 後端サーバー設定
backend web_servers
    balance roundrobin
    option httpchk GET /health
    
    server web1 192.168.1.20:80 check inter 2000 rise 2 fall 3
    server web2 192.168.1.21:80 check inter 2000 rise 2 fall 3
    server web3 192.168.1.22:80 check inter 2000 rise 2 fall 3

設定手順

グローバル設定:

log: 日志設定
chroot: セーフティサンドボックス
stats socket: 管理インターフェース
daemon: バックグラウンド実行 デフォルト設定:
mode http: HTTPモード
balance roundrobin: ラウンドロビンバランシング
option httpchk: HTTPヘルスチェック
timeout: 様々なタイムアウト設定 バックエンドサーバー:
check: ヘルスチェックを有効にする
inter 2000: チェック間隔2秒
rise 2: 連続2回成功した場合に可用とマークする
fall 3: 連続3回失敗した場合に不可用とマークする

サービス開始とテスト

サービスの起動

主節点および副節点上でサービスを起動します：

# HAProxyの起動
systemctl start haproxy
systemctl status haproxy

# Keepalivedの起動
systemctl start keepalived
systemctl status keepalived

VIP認証の確認

仮想IPが正しくバインドされているかを確認します：

# 主ノードでIPアドレスを表示
ip addr show

# 以下の様な出力が表示されるはずです：
# eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
#     inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
#     inet 192.168.1.100/24 scope global secondary eth0:0

機能テスト

1. 負荷分散テスト

# VIPに複数回アクセスし、リクエストの分配状況を監視
for i in {1..10}; do
    curl -s http://192.168.1.100/ | grep "Server"
done

2. フェイルオーバーテスト

# 主ノードでHAProxyサービスを停止する
systemctl stop haproxy

# VIPがバックノードに切り替わるのを監視する
ip addr show

# サービスの正常性を確認する
curl http://192.168.1.100/

3. バックエンドサーバー障害テスト

# 一台のWebサーバーを停止する
# web1サーバーで：
systemctl stop nginx

# HAProxy統計ページを監視する
curl http://192.168.1.100:8080/stats

モニタリングとメンテナンス

ロギング監視

HAProxyログ

# HAProxyログの確認
tail -f /var/log/haproxy.log

# アクセス統計の確認
grep "HTTP/1.1" /var/log/haproxy.log | tail -20

Keepalivedログ

# Keepalivedログの確認
tail -f /var/log/messages | grep keepalived

# 状態変化ログの確認
tail -f /var/log/keepalived-state.log

パフォーマンス監視

統計ページ監視

HAProxyの統計ページへのアクセス: http://192.168.1.100:8080/stats 主要指標:

Session Rate: 会話レート
Session Total: 総会話数
Bytes In/Out: 流量統計
Response Time: 応答時間
Server Status: サーバー状態

コマンドライン監視

# HAProxyプロセスの状態を確認
ps aux | grep haproxy

# ポートのリスニング状態を確認
netstat -tuln | grep -E "(80|8080)"

# 接続数を確認
ss -ant | grep :80 | wc -l

よくあるトラブルシューティング

1. VIPの切り替え不可

問題現象: 主ノード故障後、VIPがバックアップノードに切り替わらない トラブルシューティング手順:

# Keepalived設定を確認
keepalived -t -f /etc/keepalived/keepalived.conf

# VRRP通信を監視
tcpdump -i eth0 vrrp

# ファイアウォール設定を確認
iptables -L | grep vrrp

解決策:

VRRPプロトコル通信が正常であることを確認
ネットワークインターフェースの設定を確認
認証パスワードの一致性を検証

2. 健康チェック失敗

問題現象: バックエンドサーバーが利用不可としてマークされている トラブルシューティング手順:

# 手動で健康チェックを実行
curl -I http://192.168.1.20/health

# HAProxyログを確認
grep "Health check" /var/log/haproxy.log

解決策:

健康チェックURLにアクセス可能であることを確認
チェック間隔と閾値を調整
バックエンドサーバーの状態を確認

3. 負荷分散の不均衡

問題現象: リクエストがバックエンドサーバーに均等に分散されない トラブルシューティング手順:

# 統計ページを確認
curl -s http://192.168.1.100:8080/stats

# アクセスログを分析
awk '{print $6}' /var/log/haproxy.log | sort | uniq -c

解決策:

負荷分散アルゴリズムの設定を確認
サーバーの重み設定を検証
セッション保持の要件を考慮

オプティマイズの提案

1. パフォーマンス最適化

# システムパラメータの調整
echo 'net.core.somaxconn = 65535' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_max_syn_backlog = 65535' >> /etc/sysctl.conf
sysctl -p

# HAProxy設定の最適化
# maxconn値を増やす
# timeoutパラメータを調整する
# 圧縮機能を有効にする

2. セキュリティ強化

# 統計ページへのアクセス制限
# haproxy.cfg に ACL ルールを追加
acl allowed_ips src 192.168.1.0/24
http-request deny if !allowed_ips

# SSL/TLS の有効化
bind *:443 ssl crt /etc/ssl/certs/server.pem
redirect scheme https if !{ ssl_fc }

3. モニタリングとアラート

# 統合監視システム
# Prometheusによる監視設定
# Grafanaダッシュボードの設定
# アラートルールを設定

結論

KeepalivedとHAProxyの組み合わせにより、高可用性を持つロードバランシングクラスタを構築しました。この構成には以下の利点があります。

高可用性: VRRPプロトコルによる自動フェイルオーバーを実現
ロードバランシング: スマートなリクエスト分散により、システム性能を向上
健康チェック: リアルタイムでサービスの状態を監視し、故障ノードを自動的に除外
メンテナンスの容易さ: 設定が簡単で、管理も容易
コスト効率: オープンソースソフトウェアを使用することで、運用コストを削減本番環境へのデプロイ時には、ネットワークセキュリティ、監視アラート、バックアップとリカバリなどの面での整備が必要であり、システムの安定性と信頼性を確保します。