Coded Chords - Tech

ターミナルのフォントを整える(2026年版)

2026-09-07T13:04:27+09:00

Table of Contents</summary> </details>

ターミナルの欧文フォントには、以前の記事</a>で書いたとおり Berkeley Mono</a> を使い続けています。ただしBerkeley Monoは日本語のグリフを持たないため、日本語は別のフォントにフォールバックさせる必要があります。このフォールバックの設定を、思いつきで書くのではなく実測して組み直しました。</p> </span>

WezTerm のフォント設定の最終構成</h2>

結論を先に書くと、欧文がBerkeley Mono、全角が更紗ゴシック、アイコンがSymbols Nerd Font Monoという 3段構成に落ち着きました。全角文字がちょうど2セルに収まり、①</code> のような文字がセルからはみ出さず、太字と斜体のすべての組み合わせが合成ではなく実フェイスで描かれる状態です。</p>

役割</th> フォント</th> 指定</th></tr></thead>

欧文</td> Berkeley Mono（静的版）</td> セル幅 0.600 em</td></tr>

全角</td> 更紗ゴシック（Sarasa Term J）</td> scale = 1.2</code></td></tr>

アイコン</td>

Symbols Nerd Font Mono 3.5.1</td>

指定なし</td></tr> </tbody></table>

font_size</code> は20.0です。ターミナルは文字を等幅のマス目に並べて表示します。欧文1文字がマス目1つ、日本語1文字はマス目2つにちょうど収まらないと表示が崩れるため、サイズは自由に選べません。20.0はその条件を満たす値です。詳しくは後述します。</p>

文字の送り幅をどう測ったか</h2>
ターミナルのフォント設定は、見た目で判断すると微妙なズレを見逃します。
そこで2つの道具で数値を取りました。測る対象は送り幅、
つまり1文字を描いたあと次の文字の位置までカーソルが進む距離です。</p>
ひとつはfontToolsです。フォントファイルそのものを読み、hmtx</code> テーブルから
送り幅を取り出します。フォントと文字を並べて一度に測りました。</p>
from</span> fontTools</span>.</span>ttLib</span> import</span> TTFont</span></span>
from</span> pathlib</span> import</span> Path</span></span>
</span>
# ttc は fontNumber でフェイスを選ぶ。220 は Sarasa Term J Regular</span></span>
FONTS</span> =</span> [</span></span>
    (</span>"Berkeley Mono Regular"</span>,</span> "BerkeleyMono-Regular.otf"</span>,</span> 0</span>),</span></span>
    (</span>"Sarasa Term J Regular"</span>,</span> "Sarasa-SuperTTC.ttc"</span>,</span> 220</span>),</span></span>
]</span></span>
CHARS</span> =</span> [(</span>"A"</span>,</span> 0x</span>41</span>), (</span>"あ"</span>,</span> 0x</span>3042</span>), (</span>"①"</span>,</span> 0x</span>2460</span>)]</span></span>
</span>
for</span> label</span>,</span> name</span>,</span> index</span> in</span> FONTS</span>:</span></span>
    f</span> =</span> TTFont</span>(</span>Path</span>.</span>home</span>()</span> /</span> "Library/Fonts"</span> /</span> name</span>,</span> fontNumber</span>=</span>index</span>,</span> lazy</span>=</span>True</span>)</span></span>
    upem</span> =</span> f</span>[</span>"</span>head</span>"</span>].</span>unitsPerEm</span></span>
    cmap</span> =</span> f</span>.</span>getBestCmap</span>()</span></span>
    cols</span> =</span> []</span></span>
    for</span> char</span>,</span> cp</span> in</span> CHARS</span>:</span></span>
        gid</span> =</span> cmap</span>.</span>get</span>(</span>cp</span>)</span></span>
        adv</span> =</span> f</span>"</span>{</span>f</span>[</span>'</span>hmtx</span>'</span>][</span>gid</span>][</span>0</span>]</span> /</span> upem</span>:.3f</span>}</span> em"</span> if</span> gid</span> else</span> "-"</span></span>
        cols</span>.</span>append</span>(</span>f</span>"</span>{</span>char</span>} {</span>adv</span>:>8</span>}</span>"</span>)</span></span>
    print</span>(</span>f</span>"</span>{</span>label</span>:24</span>}</span>"</span> +</span> "  "</span>.</span>join</span>(</span>cols</span>))</span></span></code></pre>Berkeley Mono Regular   A 0.600 em  あ        -  ①        -</span></span>
Sarasa Term J Regular   A 0.500 em  あ 1.000 em  ① 0.500 em</span></span></code></pre>
emは文字サイズを1とした単位なので、この値はフォントサイズに左右されない設計値です。
Berkeley Monoは 'A' を0.600 emで送り、日本語のグリフは持ちません。
更紗ゴシックは半角が0.500 em、全角が1.000 emで、①</code> は半角側です。
2つのフォントは幅の基準そのものが違う、というのがここで分かります。</p>
もうひとつはWezTerm自身の ls-fonts</code> です。こちらは「設定を与えたときに実際にどのファイルの
どのフェイスが選ばれ、送り幅がいくつになるか」を返します。--codepoints</code> には
調べたい文字をUnicodeのコードポイントで渡します。41</code> はU+0041の 'A'、
3042</code> はU+3042、ひらがなの「あ」です。ここで読み込む test.lua</code> は、
Berkeley Monoと更紗ゴシックを並べただけの素の設定です。</p>
wezterm</span> --config-file ./test.lua ls-fonts --codepoints 41,3042</span></span></code></pre>0 A  \u{41}   x_adv=12 cells=1 wezterm.font("Berkeley Mono", ...)</span></span>
1 あ \u{3042} x_adv=20 cells=2 wezterm.font("Sarasa Term J", ...)</span></span></code></pre>
上記の結果から次のことがわかります。</p>
'A' はBerkeley Monoから取られ、送り幅を表す x_adv</code> は12ピクセル、占める幅は cells=1</code> で1セルです。ここから1セルの幅が12ピクセルだと実測で分かります。「あ」は更紗ゴシックから取られ、cells=2</code> は2セルを占めるべき文字だというWezTermの判定です。2セルなら24ピクセル必要なのに、x_adv</code> は20ピクセルしかありません。4ピクセル足りない状態です。この4ピクセルをどう埋めるかが次節の話になります。ここがズレたままだと日本語混じりの表や罫線が崩れます。</p>
フォントファイルの設計値と、WezTermが実際に採用する値は一致しないことがあるため、
この2つを突き合わせる必要がありました。</p>
全角を正確に2セルへ</h2>
更紗ゴシックは半角0.500 em、全角1.000 emという厳密なグリッドを持っています。
一方Berkeley Monoのセル幅は0.600 emです。セルの幅はBerkeley Monoに合わせるため、
全角が収まるべき2セルは1.200 emになります。更紗ゴシックの全角は1.000 emなので、
そのまま並べると0.200 em足りません。</p>
WezTermの scale</code> は、フォールバックさせるフォントを何倍で描くかを指定します。
0.500 × 1.2 = 0.600なので、scale = 1.2</code> にすれば更紗ゴシックの半角がBerkeleyのセル幅と一致し、
全角はその2倍になります。総当たりで確認しました。</p>
scale</th> セル幅</th> あ</code>（要24）</th> ①</code>（要12）</th></tr></thead>

1.1</td> 12</td> 22</td> 11</td></tr>
1.15</td> 12</td> 23</td> 12</td></tr>
1.2</td> 12</td> 24</strong></td> 12</strong></td></tr>
1.25</td> 12</td> 25</td> 13</td></tr>
</tbody></table>
ここで厄介なのが、WezTermがセル幅を整数に丸めることです。
0.600 × font_size</code> が整数から離れると、丸めの誤差でグリッドが崩れます。
font_size</code> を振って確かめたところ、成立するサイズは限られていました。</p>
font_size</th> セル幅</th> あ</code></th> ①</code></th> 判定</th></tr></thead>

16.0</td> 10</td> 19</td> 10</td> 全角が1px不足</td></tr>
18.0</td> 11</td> 22</td> 11</td> ぴったり</td></tr>
19.0</td> 11</td> 23</td> 12</td> 1px超過</td></tr>
20.0</td> 12</td> 24</td> 12</td> ぴったり</td></tr>
21.0</td> 13</td> 25</td> 13</td> 全角が1px不足</td></tr>
22.0</td> 13</td> 26</td> 13</td> ぴったり</td></tr>
24.0</td> 14</td> 29</td> 15</td> 1px超過</td></tr>
</tbody></table>
font_size = 20.0</code> を選んでいるのはこのためです。18.0と22.0も使えますが、
21.0や24.0に動かすと桁がずれます。⌘+ と ⌘− でサイズを変える運用をしていると
崩れる場面があるので、この事情は設定ファイルにコメントとして残しました。</p>
Ambiguous 幅と漢字カバレッジ</h2>
日本語フォントなら何でもよいわけではありません。決定的なのはEast Asian Ambiguous、
つまり半角と全角のどちらとも解釈しうる文字の扱いです。
①②③</code>、◆</code>、※</code> あたりが該当します。</p>
Ambiguousは、UnicodeのEast Asian Widthプロパティで A</code> に分類される文字です。
狭幅と広幅のどちらにも解決されうる、という分類までがUnicodeの担当で、
どちらに倒すかを決めるのは端末です。WezTermには
treat_east_asian_ambiguous_width_as_wide</code> という設定があります。既定は false</code>、
つまり1セルとして数えます。したがって「半角が正しい」のではなく、
端末の数え方とフォントの字幅が一致していることが要件になります。
端末が1セルと数えているのに字が2セル分あると、隣にはみ出すだけでは済みません。
カーソルの桁数は1のまま進むので、以降の再描画で端末が消したつもりの位置と
実際に塗られた位置が1桁ずれ、消し残りや行の崩れになります。</p>
では全角側に倒せばよいかというと、こちらも通りません。
Ambiguousに含まれるのは丸数字や記号だけではないからです。
罫線の ─│┌</code>、矢印の →</code>、°</code> や ±</code>、ギリシャ文字とキリル文字、
そしてNerd Fontのアイコンやpowerlineの区切りにも、ここに属するものが多くあります。
これらの多くがUnicodeの私用領域を使っており、私用領域は E000..F8FF</code> が丸ごとAmbiguousだからです。
treat_east_asian_ambiguous_width_as_wide = true</code> を指定すると、これらは一斉に2セル幅へ変わります。
プロンプトの区切りとアイコン、tree</code> や gh</code> の引く枠線まで、横幅は倍になります。
①</code> を正しく出すためにプロンプトと罫線を組み直すのは割に合わないので、半角側に倒します。
コードポイント範囲ごとに幅を指定する cell_widths</code> を使えば私用領域だけを全角へ固定できますが、
これはnightlyビルド限定の設定で、手元の安定版20240203-110809-5046fc22は受け付けませんでした。
Vimの ambiwidth=double</code> に代表される全角前提の設定は、日本語環境では長く標準でした。
常時目に入る文字の中身がこれだけ変わった今は、半角側のほうが破綻は少なくなっています。</p>
macOS標準のヒラギノ角ゴシックは、これらを全角で設計しています。
手元の構成で測ると、セル幅12に対して送り幅は13.75でした。
25パーセントはみ出して隣の文字と干渉します。しかもこれは scale</code> を振っても変わりませんでした。</p>
更紗ゴシック（Sarasa Term J）は、Ambiguousを半角として設計した系統です。
①</code> と ◆</code> はどちらも0.500 emで、scale = 1.2</code> を掛けてちょうど1セルに収まります。
同じ更紗ゴシックでも "Mono" 系統はAmbiguousが全角なので、ターミナルには "Term" を選ぶ必要があります。</p>
漢字のカバレッジも測りました。ここは数え方に注意が必要です。</p>
フォント</th> JIS X 0208</th> JIS X 0213</th> Unicode CJK統合漢字</th></tr></thead>

Sarasa Term J</td> 100 %</td> 100 %</td> 100 %</td></tr>
ヒラギノ角ゴ Sans W3</td> 100 %</td> 85.3 %</td> 51.3 %</td></tr>
</tbody></table>
ヒラギノの51.3パーセントという数字は一見すると低く見えますが、
UnicodeのCJK統合漢字ブロックは日本語・簡体字・繁体字・韓国・ベトナムの漢字を
すべて含む集合なので、日本語フォントの評価軸としては適切ではありません。
PythonのShift_JISコーデックで判定したところ、ヒラギノに無い1万225字のうち
JIS X 0208に含まれるものは0字でした。常用漢字と人名用漢字は完全にカバーしています。</p>
なおmacOS全体では、標準フォントを合わせるとCJK統合漢字を100パーセント表示できます。
ただし日本語フォントに無い字はHiragino Sans GB（簡体字）やHeiti TC（繁体字）に落ちるため、
表示はされても字形が中国字体になります。更紗ゴシックを使うと、この落下自体が起きません。</p>
Nerd Font はシンボル専用フォントで足りる</h2>
以前はNerd Fontのアイコンを、パッチ済みの日本語フォントから取っていました。
しかしアイコンのためだけに日本語フォントを1本抱えるのは無駄です。
nerd-fonts</a> には
シンボルだけを収録したフォントがあり、Homebrewから入ります。</p>
brew</span> install --cask font-symbols-only-nerd-font</span></span></code></pre>
実はWezTermにはSymbols Nerd Font Monoが同梱されていて、
何もしなくてもフォールバック連鎖の末尾に入っています。
アイコンの解決先を29点サンプリングしたところ、23点が内蔵フォントで解決し、
Powerlineの区切りはWezTerm自身が描画していました。
豆腐になったのは U+E6B5</code> と U+EC1E</code> の2点だけです。</p>
つまり多くの場合は内蔵で足ります。それでも単体版を入れたのは、
内蔵版が古いビルドで上記2点が欠けていたためです。
インストール版がCoreText経由で優先されることと、欠けていた2字が埋まることは確認しました。</p>
更紗ゴシックとは</h2>
更紗ゴシックはRenzhi Li（Belleve Invis）氏によるOFL-1.1のフォントです。
Iosevka</a> の作者でもあります。</p>
中身を知っておくと判断しやすくなります。フォントファイルの著作権表記はこうなっています。</p>
Copyright (c) 2015-2025, Renzhi Li (aka. Belleve Invis, belleve@typeof.net).</span></span>
Portions Copyright (c) 2016 The Inter Project Authors.</span></span>
Portions Copyright (c) 2014-2021 Adobe Systems Incorporated.</span></span>
Portions Copyright (c) 2012 Google Inc.</span></span></code></pre>
Adobeが源ノ角ゴシック（Source Han Sans）、GoogleがNoto Sans CJKです。
つまり更紗ゴシックの漢字とかなは源ノ角ゴシックそのもので、
作者の仕事はIosevkaの欧文と合成し、半角と全角を厳密に1:2のグリッドへ再設計することでした。
今回の構成では欧文をBerkeley Monoが担当するので、更紗ゴシックは実質的に
「ターミナル用に幅を再設計した源ノ角ゴシック」として働いています。</p>
この再設計は、源ノ角ゴシックをそのまま使わない理由でもあります。両者を実測しました。</p>
文字</th> 源ノ角ゴシック JP</th> 更紗ゴシック Term J</th></tr></thead>

①</code> ◆</code> ※</code></td> 1.000 em</td> 0.500 em</td></tr>
─</code> →</code></td> 1.000 em</td> 0.500 em</td></tr>
°</code></td> 0.370 em</td> 0.500 em</td></tr>
α</code></td> 0.625 em</td> 0.500 em</td></tr>
あ</code> 漢</code></td> 1.000 em</td> 1.000 em</td></tr>
</tbody></table>
源ノ角ゴシックはAmbiguousを全角に置き、°</code> や α</code> は字ごとの固有幅を持ちます。
一般の文書組版としては妥当ですが、前述のAmbiguousの条件は満たしません。
更紗ゴシックのTerm系統はこれらをすべて0.500 emへ揃えています。
かなと漢字の字形が同じでも、ターミナルで使えるかどうかはこの一点で分かれます。</p>
Iosevka自体もコード用のフォントとしては高く評価されています。文字幅が狭いので、老眼にはつらいのですが多くの情報を表示できるので好まれているようです。</p>
"J" は日本語字形を意味します。同じ更紗ゴシックでもSCを選ぶと漢字が中国字形になるため、
日本語環境ではJを選ぶ必要があります。</p>
ウェイトは5段（200 / 300 / 400 / 600 / 700）で、それぞれにイタリックがあり、
合計10面すべてが実フェイスです。nameID 1では
Sarasa Term J Light</code> のように枝番のファミリ名に分かれていますが、
nameID 16のタイポグラフィックファミリは10面とも Sarasa Term J</code> で共通なので、
ファミリ名は変えずに weight</code> を指定するだけで切り替わります。
日本語フォントにイタリックがあるのは珍しく、ヒラギノはW0からW9まで10段のウェイトを持ちながら
イタリックを1面も持ちません。ターミナルでは斜体をコメントの表示に使うので、ここは実用差になります。</p>
供給元について書いておくと、フォントは実行ファイルではなく、
ネットワークアクセスとテレメトリのいずれも持ちません。理論上の懸念はTrueTypeのヒンティング命令ですが、
更紗ゴシックのヒンティングはttfautohintによる自動生成で、
macOSのCoreTextはフォント解析をサンドボックス下で行います。
GitHub Releasesから手動でダウンロードするとチェックサムの検証がないため、
Homebrewのcask経由に切り替えました。</p>
brew</span> install --cask font-sarasa-gothic</span></span></code></pre>
ライセンスはOFL-1.1で、撤回できません。一度入手したものを後から使えなくされることは
原理的にないという点は、単一ベンダーの商用フォントより安心できる部分です。</p>
WezTerm の設定</h2>
設定の該当部分です。font_rules</code> は指定したフォントで丸ごと置き換わる仕様なので、
太字と斜体でも同じ3段を組み直す必要があります。ここを怠ると、
太字の日本語やアイコンがフォールバックから外れます。</p>
local function</span> font_stack</span>(</span>weight</span>,</span> italic</span>)</span></span>
 return</span> wezterm.</span>font_with_fallback</span>({</span></span>
  { family</span> =</span> "Berkeley Mono"</span>, weight</span> =</span> weight, style</span> =</span> italic</span> and</span> "Oblique" </span>or</span> "Normal" </span>},</span></span>
  -- Sarasa は Oblique を持たず Italic</span></span>
  { family</span> =</span> "Sarasa Term J"</span>, weight</span> =</span> weight, style</span> =</span> italic</span> and</span> "Italic" </span>or</span> "Normal"</span>, scale</span> =</span> 1.2</span> },</span></span>
  { family</span> =</span> "Symbols Nerd Font Mono" </span>},</span></span>
 })</span></span>
end</span></span>
</span>
config.font</span> =</span> font_stack</span>(</span>400</span>, </span>false</span>)</span></span>
</span>
config.bold_brightens_ansi_colors</span> =</span> true</span></span>
config.font_rules</span> =</span> {</span></span>
 { intensity</span> =</span> "Bold"</span>, font</span> =</span> font_stack</span>(</span>700</span>, </span>false</span>) },</span></span>
 { italic</span> =</span> true</span>, font</span> =</span> font_stack</span>(</span>400</span>, </span>true</span>) },</span></span>
 { italic</span> =</span> true</span>, intensity</span> =</span> "Bold"</span>, font</span> =</span> font_stack</span>(</span>700</span>, </span>true</span>) },</span></span>
}</span></span></code></pre>
font_size = 20.0</code> は別のテーブルで設定しています。
なぜこの値なのか、なぜ scale</code> が1.2なのかは、忘れた頃に自分を助けるので
実測値ごとコメントとして設定ファイルに残しました。</p>
まとめ</h2>
設定の結果、送り幅を検証すると次のようになります。</p>
A      x_adv=12  cells=1   1セルぴったり</span></span>
あ 漢  x_adv=24  cells=2   2セルぴったり</span></span>
① ◆   x_adv=12  cells=1   1セルぴったり</span></span></code></pre>
日本語混じりの表や罫線が崩れなくなり、①</code> のような記号が隣の文字と重ならなくなりました。太字と斜体は、欧文がBerkeley Monoの設計どおりのOblique、和文が更紗ゴシックの実イタリックで描かれます。合成は発生していません。アイコンのために日本語フォントを抱える必要もなくなりました。</p>
この記事の原稿をエディタで開いた画面です。日本語と欧文が混ざっても、文字がマス目からはみ出さずに並んでいます。</p>


日本語と欧文が混在する原稿をWezTermで表示した画面</figcaption>
</figure>
和文を1.2倍で描いているため日本語が欧文よりやや大きく見えますが、個人的にはこちらの方が読みやすく感じています。また欧文がまとまって見えるので、コード交じりの文章も見やすくなりました。</p>
References</h2>


    
Berkeley Graphics</a>. "Berkeley Mono Typeface"</li>
Sarasa Gothic</a>. 「更紗ゴシック」</li>
Nerd Fonts</a>. "Iconic font aggregator"</li>
WezTerm</a>. "Font Configuration"</li>
Adobe Type Tools</a>. "Source Han Sans"</li>
</ul>

</div>



Google Cloud Generative AI Leader（GAIL）認定を4時間の学習で取得する
2026-09-01T14:32:10+09:00



Table of Contents</summary>

</details>
</span>


2025年5月からGoogleが提供している Google Cloud Generative AI Leader（GAIL）</a></strong> (以下、GAILと記載)を受験し合格できました。
試験対策で資料をまとめたので、公開致します。</p>
1週間ほど前にAWS Certified Generative AI Developer - Professional (AIP-C01)を取得した後、思いつきでGAILの受験を申込んだものです。学習時間は準備期間を含めて4時間程度でした。</p>
GAILとはどういう試験か</h2>
GAILは2025年5月14日に提供が始まった認定です。Google Cloudの認定体系ではCloud Digital Leaderと同じ基礎レベルに置かれていて、前提となる資格や実務経験は必要ありません。</p>
問われるのは、生成AIをビジネスにどう使うかという戦略と判断です。設定手順やコードは出題されません。求められる製品知識も、要件に対してどの製品を選ぶかというビジネスレベルの深さにとどまります。</p>
項目</th> 内容</th></tr></thead>

出題数</td> 50〜60問</td></tr>
出題形式</td> 多肢選択式（択一のみ）</td></tr>
試験時間</td> 90分</td></tr>
受験料</td> 99 USD（税別）</td></tr>
提供言語</td> 英語、日本語、スペイン語、ポルトガル語</td></tr>
実施形式</td> オンライン監督付き または テストセンター</td></tr>
前提条件</td> なし</td></tr>
有効期間</td> 3年</td></tr>
</tbody></table>
出題形式は択一選択問題だけです。正解を2つ以上すべて選ぶ複数選択問題はありません。並べ替えやマッチングの形式もないので、解答操作に慣れておく手間がかかりません。AIP-C01には複数選択問題がありましたから、この点はGAILのほうが素直です。</p>
出題範囲は4つのセクションに分かれています。</p>
セクション</th> 配点</th></tr></thead>

1. 生成AIの基礎</td> 約30%</td></tr>
2. Google Cloud の生成AI製品</td> 約35%</td></tr>
3. 生成AIモデル出力を改善する手法</td> 約20%</td></tr>
4. 生成AIソリューションを成功に導くビジネス戦略</td> 約15%</td></tr>
</tbody></table>
基礎と生成AI製品で65%を占めます。生成AIの一般的な概念を押さえたうえで、要件からGoogle Cloudの製品を引けるかどうかが得点の中心です。</p>
学習で一番戸惑ったのは製品名でした。例えば、Vertex AIはGemini Enterprise Agent Platformに、Vertex AI SearchはAgent Searchに改称され、試験ガイドは現行の名称で書かれています。一方で公式模擬試験はVertex AIのまま出題されていました。本番でどちらの名称が使われるか分からないので、一応両方を覚えておくようにしました。</p>
私のプロフィール</h2>
読者が自分との距離を測れるように、私の前提を書いておきます。</p>
私は元AWSコンサルタントです。Associateレベルの3つの認定を持ち(内2つはExpireしています)、数年の実務経験があります。</p>
生成AIはClaude Codeを常用しており、Anthropic、OpenAI、Google Cloud、VoyageなどのAPIを使用するツールは書いています。
AWS Certified Generative AI Developer - Professional (AIP-C01)を取得したばかりです。</p>
Google Cloudに関しては2024年にGoogle Cloud Digital Leaderを取得した程度で、AWSと比較するとほぼ使用していません。</p>
使った教材と学習の進め方</h2>
教材は公式のものだけです。使ったのは次の3つでした。</p>

公式試験ガイド</a>（PDF、英語）</li>
公式模擬試験（Googleフォームで提供される。日本語版もあり、認定ページからたどれる）</li>
Google Cloudの製品ドキュメント</li>
</ul>
やったことは単純で、試験ガイドと模擬試験を通して引っかかった製品を公式ドキュメントで確認し、その内容をClaude Codeに渡してAsciiDocのノートに積み上げただけです。AIP-C01のとき</a>と同じやり方です。</p>
そこに、Google Cloudの製品とAWSのサービスの対応を追記しました。
下表のように並べておくと、AWS側の知識をそのまま流用できます。私のようにAWSから来る人にとっては、製品名を単体で覚えるより速い方法だと思います。</p>


ノートの付録に置いたGCP↔AWS対比表（抜粋）</figcaption>
</figure>
まとめたノートはGitHubで公開しています。PDFとHTMLをReleasesに置いてあります。</p>

</iframe>



    </div>
    
        個人の学習ノートです</strong>
        私が自分の理解を整理するために書いたものであり、Google LLC が作成・監修・承認したものではありません。記載内容の正確性は保証しません。判断に使う前に、公式の試験ガイドと製品ドキュメントで一次情報を確認してください。</p>

    </div>
</div>

学習時間はノートをまとめる時間を含めて4時間程度です。試験前に一度読み返しました。</p>
試験当日と結果</h2>
会場はテストセンターです。試験時間は90分で、私が受けた回の問題数は45問でした。公式には50〜60問と案内されているので、回によって振れ幅があるようです。実際にかかったのは見直しと終了後アンケートを含めて15分程度でした。</p>
提出すると画面に暫定の合否が表示されるようです。
私はそれに気付かないまま終了操作を進めてしまいました。うっかり見過ごしやすいので、最後の画面は落ち着いて読んでください。正式な結果はGoogle Cloud側の確認を経て、7〜10日で確定します。</p>
数日は待つものと諦めていたのですが、Credlyから試験終了の30分後にはバッジが確認できました。</p>
出るのは合否だけで、AWSのようなスコアもセクション別の評価もありません。</p>
誰にとって価値のある認定か</h2>
体感では、エンジニアであれば半日程度の学習で余裕を持って取れます。生成AIを日常的に触っている人なら、実質的に覚えるのはGoogle Cloudの製品名と、それぞれがどの要件に対応するかの対応表だけです。</p>
そのうえで、この認定が向いているのは、生成AIの導入を企画したり予算を通したりする側の人です。技術者と会話するための共通語彙を短時間で揃えられます。逆に、実装する側のエンジニアがGoogle Cloudでの生成AI開発力を示す材料にはなりません。</p>
生成AIに特化したGoogle Cloudの認定は、これまでGAILだけでした。ここが2026年9月に変わります。Professional Agentic Architect</a></strong> のベータ登録が9月3日に始まります。Google Cloud上で自律的なエージェントのワークフローを設計・運用する技術者向けの認定で、Pearson配信の約80問・3時間の多肢選択試験に加えて、Google Skills上のハンズオンラボの両方に合格する必要があります。ベータの受験料は120 USD、提供言語は英語のみ、有効期間は1年です。</p>
現役のエンジニアであれば、GAILではなくこちらを狙う価値があります。</p>
まとめ</h2>

学習は、公式試験ガイド、公式模擬試験、製品ドキュメントで足りる</li>
得点の中心は、要件からGoogle Cloudの製品を引けるかどうかである</li>
製品名は改称の途上にある。新旧を対にして覚えておく</li>
AWS経験者は、AWSのサービスとの対応表を作るのが速い</li>
実装する側のエンジニアは、ベータ版でもProfessional Agentic Architectにチャレンジすべき。生成AIがあるいま、英語はハードルではない</li>
</ul>
思いつきで申し込んだ試験でしたが、Google Cloudの生成AI製品を要件から引ける形で一度整理できたのは収穫です。AWSとGoogle Cloudで、同じ課題に対する解き方の並びがきれいに対応することも確認できます。</p>
生成AIの主導権を握っているのは米国のプラットフォーマーで、日本のベンダーにはありません。案件の基盤がAWSになるかGoogle Cloudになるか、あるいはOpenAIのAPIを直接叩くことになるかは、エンジニアの側では選べず、プロジェクトごとに変わります。ひとつを深く知っているだけでは足りません。どれが来ても要件から製品を引ける程度には、それぞれを知っておくことが、これからは効いてくると思います。</p>
References</h2>


    
Google Cloud</a>. 「Generative AI Leader 認定資格」</li>
Google Cloud</a>. 「Generative AI Leader Certification exam guide」</li>
Google Cloud</a>. 「Generative AI Leader Certification（学習パス）」</li>
Google</a>. 「Become a certified Generative AI Leader with a first-of-its-kind credential from Google Cloud」</li>
Google Cloud</a>. 「Google Cloud 認定資格に関するよくある質問」</li>
Google Cloud</a>. 「Professional Agentic Architect Certification」</li>
</ul>

</div>



タグ付けは「分類させるな、幻覚させろ！」
2026-09-01T09:16:50+09:00



Table of Contents</summary>

</details>
</span>
Doug Turnbull氏の"Don't classify. Hallucinate!</a>"という記事を読んで、
同じようにClaude Codeによるブログ記事のタグ提案を改善できないかと検討してみました。</p>


"Don't classify. Hallucinate!"の主旨</h2>

この記事の主旨は、LLMに物事を特定のTaxonomyに分類させる際、
事前に用意した大量の選択肢をLLMに渡して直接選ばせるのではなく、
あえてLLMにカテゴリ名を自由に生成（ハルシネーション）させます。
それを埋め込み（Embedding）の類似度計算で正規カテゴリにマッピングする手法の提案です。</p>
従来の「500個ある選択肢の中から選べ」という方式では、
選択肢の一覧を毎回プロンプトやスキーマに載せてモデルへ送る必要があり、
その分だけトークンを消費します。</p>
この記事の方式では、次の2ステップを取ります。</p>

ステップ1（LLMに生成させる）</dt>
正規のカテゴリ一覧を渡さず、「このクエリに合いそうな分類名を自由に考えて作って」とLLMに頼む（例：「茶色のコーヒーテーブル」に対して、LLMが独自に Furniture</code> Living Room</code> Tables</code> Coffee</code> と回答）</dd>
ステップ2（ベクトルの類似度で変換する）</dt>
LLMが適当に作った分類名の埋め込み（Embedding）ベクトルと、あらかじめ計算しておいた「本物の正規カテゴリ一覧」のベクトルとの類似度（内積など）を計算し、最も近い正規カテゴリに割り当てる。</dd>
</dl>
メリットは、次の2点でしょう。</p>

低コスト・高速。毎回大量のカテゴリリストをプロンプトやスキーマに含めて送信する必要がない</li>
安価な小型モデルの活用。高度で高価なモデルを使わずとも、軽量な小型LLMでも十分に機能する</li>
</ul>
これまでのタグ提案ロジック</h2>
これまでは、このブログでは次のようなロジックでClaude Codeにタグを提案させていました。</p>

予めタグセットを作成し、各タグを持つ記事全てのベクター値を算出し正規化した値をそのタグのベクター値として保管する</li>
提案時は記事内容からベクター値を算出し、タグセットのベクター値と最も近いタグを提案する</li>
</ul>
このタグごとのベクター値は、そのタグが付いた記事すべての重心にあたります。「このブログで Cloud</code> と呼んでいるのは、だいたいこういう内容の記事だ」という実績の平均です。</p>
素直な作りですが、2つの制約がありました。</p>

タグを1つ足すだけで、タグセット全体のベクター値を計算し直す必要がある

重心は記事から作るため、タグセットを編集するたびに全388記事を埋め込み直すことになる。1回あたり542Kトークン、7秒かかる</li>
</ul>
</li>
記事が0件のタグを推薦できない

平均を取る相手がないので、ベクター値は空になる。そのタグが付くまで推薦されず、推薦されないから記事も付かない、という循環に陥る</li>
</ul>
</li>
</ul>
タグ提案の新ロジック</h2>
Doug Turnbull氏の記事をヒントに以下のように変更しました。</p>

タグセットのベクター値の算出で全記事をインプットにすることは廃し、タグ名だけのベクター値を算出し保存する</li>
提案時は記事内容からClaude Codeに自由に5つの単語を発想させ、連結したものでベクター値を算出する</li>
算出したベクター値ともっとも近似のタグを提案する</li>
</ul>
5語にしたのは、1語よりも記事の内容を的確に言い表せるためです。
5語はスペースで連結し、1本のベクターとして扱います。</p>
タグセットは data/tagset.toml</code> で定義しています。
第1層と第2層、そして第2層がどの第1層に属するかを手で書きます。</p>
[[</span>layer1</span>]]</span></span>
name</span> =</span> "Tech"</span></span>
description</span> =</span> "ソフトウェア、クラウド、AI、開発ツールなど技術全般。"</span></span>
</span>
[[</span>layer2</span>]]</span></span>
name</span> =</span> "Cloud"</span></span>
parent</span> =</span> "Tech"</span></span>
description</span> =</span> "クラウドコンピューティング全般。インフラとマネージドサービス。"</span></span></code></pre>
ベクター値は data/tag-vectors.json</code> に書き出します。
こちらはスクリプトが生成するので、手では編集しません。</p>
{</span></span>
  "</span>schema_version</span>":</span> 2</span>,</span></span>
  "</span>model</span>":</span> "voyage-4"</span>,</span></span>
  "</span>dim</span>":</span> 1024</span>,</span></span>
  "</span>input_type</span>":</span> "document"</span>,</span></span>
  "</span>vector_source</span>":</span> "tag_name"</span>,</span></span>
  "</span>normalized</span>":</span> true</span>,</span></span>
  "</span>updated</span>":</span> "2026-08-31"</span>,</span></span>
  "</span>tags</span>": {</span></span>
    "</span>Cloud</span>": {</span></span>
      "</span>article_count</span>":</span> 18</span>,</span></span>
      "</span>vector</span>": [</span>0.0185</span>,</span> -0.0438</span>,</span> -0.0912</span>,</span> 0.0109</span>]</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
vector</code> は実際には1024個の要素を持つ配列です。上記は抜粋のため省略しています。
article_count</code> は記事数を数えているだけで、ベクター値には使いません。
旧ロジックではこの記事群からベクター値を作っていましたが、
新ロジックでは name</code> の Cloud</code> という文字列だけを埋め込んでいます。</p>
Claude自体はベクターの埋め込みに対応していないので、Voyage APIを使用しています。
Anthropicの公式ドキュメントにも
"Anthropic does not offer its own embedding model" と明記されており、
そこから案内されている事業者がVoyage AIです。</p>
選定にあたっては、OpenAIとGoogleも含めて比較しました。
決め手になったのはコストです。
voyage-4</code> の単価は1Mトークンあたり0.06ドルで、最安ではありません。
OpenAIの text-embedding-3-small</code> は0.02ドルですから、単価だけ見れば3倍です。
それでもVoyageを選んだのは、全アカウントに200Mトークンの無料枠が付くためです。
個人ブログの規模では、この枠を使い切ることはまずありません。
単価差が実質的に効かないので、無料枠のある事業者が有利になります。</p>
もう1つは、1024次元で精度が出ることです。
ベクターの一覧はリポジトリに置くため、次元数がそのままファイルサイズになります。</p>
候補のモデルをこのブログの全記事で実際に動かして比較しました。
OpenAIの text-embedding-3-large</code> は3072次元でなければ最高精度に届かず、
1024次元に落とすと精度が下がります。
ファイルを3倍に膨らませるか精度を落とすかの二択になるわけです。
Voyageは1024次元のままその水準を保つので、この二択を迫られずに済みます。</p>
以上から、モデルは voyage-4</code>、出力次元は1024としました。</p>
なぜタグ名だけで照合できるのか？</h2>
上記のロジックでは記事内容自体は全くベクター化に含まれていません。
なぜ、Cloud</code> や Security</code> といった数語の文字列に、
記事の内容と突き合わせられるだけの情報があるのでしょうか。</p>
成立するのは、埋め込みモデルがモデル提供者による事前学習で一般的な言語知識を持っているからです。
モデルはWikipediaや書籍、Web上の膨大なテキストを読み込んで、
「どの語がどの語と、どういう文脈で一緒に使われやすいか」を学習しています。
その結果、モデルの内部には意味の近い語が近い座標に並ぶベクトル空間が予めできあがっています。
巨大な連想類語辞典を、モデル自身があらかじめ持っているようなものです。</p>
たとえば Cloud</code> という文字列を渡すだけで、モデルは
「空に浮かぶ雲」だけでなく「ITのクラウドインフラ」という意味合いを含む座標を返します。
記事から発想した infrastructure</code> や serverless</code> といった語も、同じ空間の近い位置に来ます。
このブログで Cloud</code> タグが過去どう使われてきたかをモデルが知らなくても、
世間一般でそれらが近い概念であるという知識だけで照合できます。</p>
裏を返せば、モデルが知っているのは世間一般の語義です。
旧ロジックのベクター値は、そのタグが付いた記事の重心でした。
「このブログで Cloud</code> と呼んでいるのはこういう記事だ」という実績です。
タグの意味の拠り所を、このブログでの使われ方から世間一般の語義へ移したことになります。</p>
旧ロジックでは、タグの使い方と一般的な語義が食い違ったまま補正されません。
新ロジックでは、タグが世間一般で指す意味に沿って提案されます。従って、タグから想定される記事の内容が読者と噛み合わないということが防げます。</p>
新ロジックの精度検証</h2>
3つの期間の記事で実測しました。精度は既存のタグと一致している率です。</p>
期間</th> 記事数</th> 提案が1位</th> 上位3位以内</th></tr></thead>

2026年3〜5月</td> 73</td> 71.2%</td> 89.0%</td></tr>
2026年4〜6月</td> 61</td> 75.4%</td> 93.4%</td></tr>
直近（5月末〜8月末）</td> 50</td> 76.0%</td> 88.0%</td></tr>
</tbody></table>
既存タグは上記で説明したとおり独自にセットしていたので、読者から見て必ずしも適切であったとは限りません。
ただ、新ロジックでも7割以上は既存と同じタグが提案されます。タグ付けの振るまいは大きく変わらず、精度としては合格点としました。</p>
この精度を保ったまま、旧ロジックの2つの制約が外れました。</p>

タグセットのベクター値を計算し直すコストが消えた

記事を読まずタグ名だけを埋め込むため、36タグを配列で1リクエストに投入できる。16トークン、1秒未満で終わる。旧ロジックは388記事を9リクエストに分けて542Kトークン・7秒かかっていた</li>
</ul>
</li>
記事が0件のタグを推薦できるようになった

タグ名さえあればベクター値を持てるため、新しく作ったタグをその日から推薦候補にできる</li>
</ul>
</li>
</ul>
まとめ</h2>
「分類させるな、幻覚させろ」というタイトルには驚きました。
しかし中身は、仮想の回答文書（Hypothetical Document）を生成してベクトル検索するHyDE（Hypothetical Document Embeddings）を、分類タスクに応用したものです。
分類タスクで問題になるのは、雑多な対象の表現（今回は「記事」）とTaxonomy（今回はタグ一覧）の構造的なギャップです。記事本文とタグ名を直接ベクトル比較しても、きれいには重なりません。</p>
以前はこのギャップをTaxonomy側で埋めていました。コストをかけてタグごとに記事をベクター化し、Taxonomyを記事の表現に寄せていたわけです。今回のアイデアは逆転の発想で、対象のほうをTaxonomyに合わせます。</p>
新ロジックに変更してタグセットの維持が格段にやりやすくなりました。
また独自のタグ付けをしていた部分は、少し読者側に寄り添えたかと思います。</p>
タグ体系は注意深く練り直す必要がありました。</p>

独自の使い分けは排除する。Movie</code>（自身で制作した動画）と Films</code>（観賞した映画）を使い分けていたが、一般には同義である</li>
Insight</code>（洞察）のような抽象的な概念は避ける。タグ付けが安定しない</li>
</ul>
このロジックはタグ自動アサインではなく、あくまでタグ提案として扱っています。
そのまま使うか書き換えるかは、これまでどおり筆者の裁量で決めます。</p>
原記事は小型で安価なモデルが使えるという利点も挙げていましたが、
今回はそこまで手を付けていません。
このスキルはメインセッションで動くため、そのセッションのモデルがそのまま使われます。
キーワードを選ぶ工程だけをサブエージェントに切り出し、
そのモデルをHaikuに指定すれば、この利点も取り込めるはずです。</p>
References</h2>


    
Doug's search blog and newsletter</a>. 「Don't classify. Hallucinate!」</li>
Anthropic</a>. 「Embeddings」</li>
Voyage AI</a>. 「Text Embeddings」</li>
</ul>

</div>



ブログの画像形式をAVIFに移行
2026-08-29T17:07:36+09:00



Table of Contents</summary>

</details>
</span>
このブログのカバー画像の出力をWebPからAVIFに切り替えました。
切り替えるにあたって、記事内の画像をすべて変換したらどれくらい軽くなるのかを実際に測り、
どの画像をどの形式で持つのかを決め直しています。その過程をまとめます。</p>
画像フォーマット AVIFとは</h2>
AVIFは、Alliance for Open Media（AOMedia）が策定した静止画フォーマットです。AOMediaは2015年9月1日に発足しました。設立メンバーはAmazon、Cisco、Google、Intel、Microsoft、Mozilla、Netflixの7社で、発足時のプレスリリースには「相互運用可能でオープン」「ロイヤリティフリー」「Web向けに最適化」といった目標が並んでいます。Googleは当時の状況を「web video innovation was too slow and too closed」と表現していました。</p>
その成果が動画コーデックのAV1です。2018年3月28日にビットストリーム仕様が公開され、同年6月25日に検証済みの1.0.0が出ました。</p>
静止画フォーマットには、動画コーデックのイントラフレーム符号化をそのまま流用するという系譜があります。WebPはVP8から、HEICはHEVCから作られました。AV1に同じことをしたのがAVIFです。仕様1.0.0は2019年2月19日に公開され、最新版は2025年10月16日の1.2.0です。</p>
器にはHEIFを使います。HEICと同じISO Base Media File Format系のコンテナで、中身の符号化だけをHEVCからAV1に差し替えた格好です。HEICと決定的に違うのは、特許ライセンスの交渉なしで使える点です。</p>
フォーマットとしての特徴は次のとおりです。</p>

JPEGやWebPより高い圧縮効率を持つ</li>
12bitまでの色深度、HDR、広色域を扱える</li>
アルファチャンネル、可逆圧縮、アニメーション、プログレッシブデコードに対応する</li>
仕様と実装がともにロイヤリティフリーである</li>
</ul>


    Can I useはWeb技術のブラウザ対応状況をまとめたサイト</p>

</aside>

ブラウザ側の対応は、Chrome 85、Firefox 93、Safari 16（iOS）およびSafari 16.4（macOS）、Edge 121からです。最後発のEdgeが2024年1月に対応したことで主要ブラウザが出揃い、Can I use</a>の集計では対応率が約95%に達しています。個人ブログで使うぶんには、もう待つ理由はありません。</p>
一方で、使う前に知っておいたほうがよい癖もあります。</p>

エンコードが遅い。avifenc</code>の-s</code>（speed）は0が最も遅く、10に近づくほど速くなる</li>
既定のクロマサブサンプリングは4:2:0で、細い色付きの線や文字が崩れる</li>
可逆圧縮ではWebPに大きく負ける</li>
ブラウザ以外の取得元、たとえばSNSのクローラーは対応状況が読めない</li>
小さい画像ではヘッダの分が効いて、かえって大きくなることがある</li>
</ul>
後半の3つはこのブログの運用にそのまま効いてきました。以降の節で実測値とともに見ていきます。</p>
AVIF移行の検証</h2>
確かめたいことは3つあります。ブログ全体を移行するとどれだけ軽くなるのか、写真をどの品質値で変換すればよいのか、そして図版にもAVIFを使ってよいのかです。このブログの実データで順に測っていきます。</p>
検証の前提と対象</h3>
一括変換の対象は、記事で使用している画像すべてです。avifenc -q 60 -y 420 -s 6</code>で変換し、変換前後の合計バイト数を比べています。対象は678枚でしたが、このうち2枚は変換できていません。95フレームのアニメーションWebPが1枚と、697フレームのアニメーションGIFが1枚です。AVIF自体はアニメーションを表現できますが、avifenc</code>が受け付けるのは静止画だけだからです。残る677枚が集計対象になります。</p>
既存のWebPがすでに非可逆圧縮を通ったファイルである点には注意が必要です。今回はそれをPNGに展開してからAVIFに再エンコードしているので、原本から直接AVIFにする場合とは条件が違います。以降の数字は「いま置き換えたらどうなるか」の目安として見てください。</p>
画質はSSIMULACRA2という知覚品質指標で測ります。CloudinaryのJon Sneyers氏が作った指標で、スコア90が「visually lossless」、70が「high quality（アーティファクトは知覚できるが不快ではない）」、50が「medium quality」という目安が示されています。</p>
ブログ全体でどれだけ削減できるか</h3>
区分</th> 枚数</th> 変換前</th> AVIF (q=60)</th> 削減率</th></tr></thead>

本文画像</td> 169</td> 38.9 MB</td> 14.4 MB</td> 63.0%</td></tr>
カバー画像</td> 128</td> 21.2 MB</td> 10.6 MB</td> 49.9%</td></tr>
OGP画像</td> 380</td> 7.9 MB</td> 5.6 MB</td> 28.6%</td></tr>
合計</td> 677</td> 68.0 MB</td> 30.6 MB</td> 54.9%</td></tr>
</tbody></table>
全体では55%減という結果です。
OGP画像で削減率が低いのは文字中心のシンプルな画像であるためでしょう。</p>
元の形式ごとに分けると次のようになります。</p>
元の形式</th> 枚数</th> 変換前</th> AVIF (q=60)</th> 削減率</th></tr></thead>

WebP</td> 634</td> 41.1 MB</td> 24.1 MB</td> 41.4%</td></tr>
JPEG</td> 36</td> 24.4 MB</td> 6.3 MB</td> 74.1%</td></tr>
PNG</td> 7</td> 2.5 MB</td> 0.2 MB</td> 90.6%</td></tr>
</tbody></table>
JPEGとPNGの削減率が高いのは、枚数が少ないうえに1枚あたりが大きいファイルに偏っているためです。すでにWebPになっている634枚での4割減が、実際の移行で期待できる水準に近い数字だと考えています。</p>
一方で、677枚のうち40枚はAVIFのほうが大きくなりました。最大で1.66倍です。内訳は本文画像が32枚、カバー画像が8枚で、本文画像の多くは図版やスクリーンショットでした。写真とそれ以外を同じ設定で扱うのは無理がある、ということがここに出ています。</p>
写真をどの品質値で変換するか</h3>
このブログのAI生成カバー1枚と写真3枚を使い、品質値を振りながらスコアを測りました。比較対象は移行前まで使っていたcwebp -q 80</code>です。写真3枚は保存済みのJPEGを基準画像にしているので、この表が見ているのはAVIFとWebPの再エンコード分だけです。</p>
設定</th> AI生成カバー</th> 写真A</th> 写真B</th> 写真C</th></tr></thead>

AVIF q=54</td> 65.4</td> 63.4</td> 71.4</td> 64.8</td></tr>
AVIF q=56</td> 67.9</td> 67.0</td> 73.6</td> 66.8</td></tr>
AVIF q=58</td> 69.0</td> 68.5</td> 74.6</td> 67.7</td></tr>
AVIF q=60</td> 71.5</td> 71.5</td> 76.2</td> 69.5</td></tr>
AVIF q=62</td> 72.6</td> 72.9</td> 76.9</td> 70.3</td></tr>
cwebp -q 80</td> 74.4</td> 77.1</td> 72.3</td> 69.2</td></tr>
</tbody></table>
q=58以下では4枚とも70を割ります。q=60にすると3枚が70を超え、残る1枚も69.5とほぼ境界です。つまり60は、SSIMULACRA2の「高品質」の目安に乗る最小の設定ということになります。</p>
同じ4枚のファイルサイズは次のとおりです。</p>
設定</th> AI生成カバー</th> 写真A</th> 写真B</th> 写真C</th></tr></thead>

AVIF q=60</td> 138.2 KB</td> 414.5 KB</td> 107.3 KB</td> 160.9 KB</td></tr>
cwebp -q 80</td> 181.3 KB</td> 618.5 KB</td> 132.8 KB</td> 199.0 KB</td></tr>
削減率</td> 23.8%</td> 33.0%</td> 19.2%</td> 19.1%</td></tr>
</tbody></table>
スコアはcwebp -q 80</code>と同程度で、ファイルは2割から3割小さくなりました。見た目を落とさずに軽くするという目的には、これで足ります。</p>
図版にAVIFを使えるか</h3>
変換して大きくなった40枚の多くは図版やスクリーンショットでした。図版でAVIFがどう振る舞うのかを、2つの角度から測ります。</p>
1つ目はクロマサブサンプリングです。AVIFの既定である4:2:0は色差の解像度を半分に落とすため、細い色付きの線が崩れます。1927×864の構成図で測ると次のようになりました。</p>
設定</th> サイズ</th> SSIMULACRA2</th></tr></thead>

AVIF q=60 (4:2:0)</td> 39.8 KB</td> 76.4</td></tr>
AVIF q=90 (4:2:0)</td> 61.5 KB</td> 77.5</td></tr>
AVIF q=60 (4:4:4)</td> 40.3 KB</td> 87.7</td></tr>
cwebp -q 90</td> 122.5 KB</td> 76.2</td></tr>
cwebp -lossless</td> 42.1 KB</td> 劣化なし</td></tr>
</tbody></table>
4:2:0のままだと、品質値を90まで上げてもスコアは77台で頭打ちになります。-y 444</code>にすれば87.7まで戻りますが、それでも非可逆であることに変わりはありません。そして可逆WebPは42.1 KBで、AVIF q=60の39.8 KBとほとんど変わらないサイズに収まっています。同じ容量で劣化なしにできるのですから、図版で非可逆を選ぶ理由がありません。</p>
2つ目は可逆圧縮どうしの比較です。図版やスクリーンショット6枚をcwebp -lossless</code>とavifenc --lossless</code>の両方で圧縮しました。</p>
画像</th> 内容</th> cwebp -lossless</th> avifenc --lossless</th> 倍率</th></tr></thead>

flow.png</td> 構成図</td> 42.1 KB</td> 222.0 KB</td> 5.27倍</td></tr>
covid19-graph1.png</td> グラフ</td> 10.0 KB</td> 36.4 KB</td> 3.64倍</td></tr>
covid19-graph2.png</td> グラフ</td> 11.0 KB</td> 48.7 KB</td> 4.44倍</td></tr>
badge.png</td> バッジ</td> 11.4 KB</td> 25.7 KB</td> 2.26倍</td></tr>
decibel-spotify-preset.png</td> スクリーンショット</td> 15.4 KB</td> 38.2 KB</td> 2.48倍</td></tr>
postcard.png</td> イラスト</td> 23.7 KB</td> 153.0 KB</td> 6.46倍</td></tr>
</tbody></table>
このブログの図版で試した範囲では、AVIFの可逆圧縮はWebPの2.3倍から6.5倍になりました。可逆で残したい画像にAVIFを使う意味はありません。</p>
まとめ：画像形式の使い分け方針</h2>
検証の結果、このブログでは画像の性質で2つに分けると決めました。</p>

写真やAI生成のイラストは非可逆のAVIFを使用</li>
図版やスクリーンショットは可逆のWebPを使用</li>
適用するのは新規記事のみ、既存記事のファイルは移行しない</li>
</ul>
写真とAI生成のカバー画像は次のコマンドで変換します。</p>
avifenc</span> -q</span> 60</span> -y</span> 420</span> -s</span> 6</span> --ignore-exif --ignore-xmp input.png output.avif</span></span></code></pre>
-y 420</code>はクロマサブサンプリング、-s 6</code>はエンコード速度の指定です。--ignore-exif --ignore-xmp</code>はExifとXMPのメタデータを出力に含めません。</p>
図版やスクリーンショットは、WebPの可逆圧縮を使います。</p>
cwebp</span> -lossless -z</span> 9</span> -exact input.png -o output.webp</span></span></code></pre>
-z 9</code>は可逆プリセットの圧縮レベルを最大にする指定、-exact</code>は透明部分のRGB値を保持する指定です。</p>
OGP画像（social_media_card</code>）はWebPのまま据え置きます。ブラウザではなくSNSのクローラーが取得する画像なので、対応状況が読めない形式に変えるリスクのほうが、数MBの節約より大きいと判断しました。npm run ogp</code>で自動化しているので、出力は現状維持することにしました。</p>
まとめると、このブログの使い分けは次の3つになります。</p>
用途</th> 形式</th> コマンド</th></tr></thead>

写真、AI生成のカバー画像</td> AVIF（非可逆）</td> avifenc -q 60 -y 420 -s 6 --ignore-exif --ignore-xmp in.png out.avif</code></td></tr>
図版、グラフ、スクリーンショット</td> WebP（可逆）</td> cwebp -lossless -z 9 -exact in.png -o out.webp</code></td></tr>
OGP画像</td> WebP</td> npm run ogp</code></td></tr>
</tbody></table>
冒頭のカバー画像も、この方針で作った最初のAVIFです。1536×864で41.9 KBに収まりました。</p>
References</h2>


    
Alliance for Open Media</a>. "Alliance for Open Media Established to Deliver Next-Generation Open Media Formats"</li>
AOMediaCodec</a>. "AV1 Image File Format (AVIF)"</li>
Can I use</a>. "AVIF image format"</li>
Cloudinary</a>. "SSIMULACRA 2 - Structural SIMilarity Unveiling Local And Compression Related Artifacts"</li>
</ul>

</div>



AWS Certified Generative AI Developer - Professional (AIP-C01) を3週間・20時間の学習で取得する
2026-08-26T04:32:16+09:00



Table of Contents</summary>

</details>
</span>


2026年8月25日に AWS Certified Generative AI Developer - Professional (AIP-C01)</strong> を受験し、合格ライン750点のところ、辛くも779点で合格できました。</p>
私は元AWSコンサルタントで、学習期間は8月3日から受験日までの3週間、学習時間は準備期間を含めて体感で20時間程度でした。準備ではClaude CodeとMulmoClaudeを活用しました。</p>
この試験は2026年3月に始まったばかりで、日本語の受験記がほとんど見当たらないと思うのでこの記事をまとめました。
受験を迷っている人が知りたいであろう、次の3点を中心にまとめました。</p>

どんな試験なのか</li>
何をどれだけやれば合格ラインに届くのか</li>
教材に何が使えるのか</li>
</ol>
AIP-C01 とはどういう試験か</h2>
正式名称はAWS Certified Generative AI Developer - Professional(以下、AIP-C01と記載)、試験コードはAIP-C01です。基盤モデル（FM: Foundation Model）をアプリケーションや業務ワークフローに組み込む能力を問う、Professionalレベルの認定です。</p>
項目</th> 内容</th></tr></thead>

問題数</td> 採点対象65問 ＋ 未採点10問 ＝ 75問</td></tr>
試験時間</td> 180分</td></tr>
合格ライン</td> 100〜1000点のスケールドスコアで750点</td></tr>
出題形式</td> 択一選択問題、複数選択問題</td></tr>
受験料</td> 44,000円（税込）</td></tr>
提供言語</td> 英語、日本語、韓国語、中国語（簡体字）</td></tr>
</tbody></table>
受験料は44,000円（税込）です。AWSの受験料は認定レベルごとに決まっていて、AIP-C01はProfessionalレベルなので最も高い価格帯にあたります。
ただし、この試験を受けようと思う方は他のAWS認定を持っている方が多いと思います。
以前の受験で付与される50%の割引バウチャー特典を持っている場合があるので、
AWS 認定アカウントの「特典」ページを必ずチェック</strong>しましょう。</p>
まず押さえておくべきは、出題形式が択一選択問題と複数選択問題の2種類しかない</strong>ことです。
択一選択問題は正解1つと誤答3つ、複数選択問題は5つ以上の選択肢から正解を2つ以上すべて選ぶ形式です。近年の他のAWS試験に見られる並べ替えやマッチングの形式はありません。解答操作そのものに慣れる必要がなく、対策は選択肢を読み比べる練習に集中できます。</p>
次に、公式の試験ガイドで、次のものは試験では求められない領域</strong>として挙げられており、学習の必要はありません。</p>

モデルの開発と訓練</li>
高度な機械学習技法</li>
データエンジニアリングとフィーチャーエンジニアリング</li>
</ul>
機械学習そのものの理解を問う試験ではありません。既存の基盤モデルをどう組み合わせ、どう本番環境に載せるかという開発者側の判断が問われます。</p>
出題範囲は5つのコンテンツ分野に分かれています。</p>
コンテンツ分野</th> 配点</th></tr></thead>

1. 基盤モデルの統合、データ管理、コンプライアンス</td> 31%</td></tr>
2. 実装と統合</td> 26%</td></tr>
3. AI の安全性、セキュリティ、ガバナンス</td> 20%</td></tr>
4. GenAI アプリケーションの運用効率と最適化</td> 12%</td></tr>
5. テスト、検証、トラブルシューティング</td> 11%</td></tr>
</tbody></table>
出題される75問のうち10問は採点されません。
これは今後の出題候補を評価するための問題で、試験中にどれが採点対象外なのかは分かりません。採点されるのは残る65問です。</p>
65問で750/1000点が合格ラインです。
配点は難易度の差を統計的に補正され算出されるので、「65問中これだけ正解すれば合格」という逆算はできません。</p>
私のプロフィール</h2>
読者が自分との距離を測れるように、私の前提を書いておきます。</p>
私は元AWSコンサルタントです。Associateレベルの3つの認定を持ち(内2つはExpireしています)、数年の実務経験があります。
AWSのサービス構成や、IAMやVPCといった土台の部分については、あらためて学び直す必要のない状態から始めています。</p>
生成AI側については、Claude Codeを日常的に使っていて、Claude APIを使った小さなコードを今も書いています。APIの使い方やトークンの扱い、プロンプトの組み立てといった部分は、業務ではなく手元の道具として触ってきました。</p>
Amazon Bedrockについては、現役時代にデモをいくつか作りました。ただし直近2年は必要性がなく、キャッチアップしていません。Bedrock Knowledge BasesやBedrock Agents、Guardrailsといった、この2年で増えた機能群は初見に近い状態でした。</p>
つまり、AWSの土台は持っているが、AWSの生成AI周辺のサービス知識は空白という状態からのスタートです。</p>
使った教材とまとめ資料づくり</h2>
最初に、 Whizlabsの「AWS Certified Generative AI Developer - Professional (AIP-C01) Certification Training」を購入しました。試験対策問題と、用意されたシナリオを実際のAWS環境で構築するLabsが含まれています。7,585円で購入しました。AIP-C01が始まった直後の2026年3月に購入しました。Whizlabsを選択したのはたまたまです。
現在はUdemyなど日本語で模擬試験を提供するサービスが多数あるので、そちらを推奨します。</p>
ただし、買っただけで満足し4ヶ月以上放置していました。</p>
8月に入って学習を始めて最初に手を付けたのは、公式のサンプル問題です。
試験ガイドに付属する無料のサンプル問題と、AWS Skill Builderで提供されている公式模試の両方を解きました。試験の要点はサービスの機能でなく「要件に対して最適なサービス構成を選べる」ことが問われるというのが理解できます。</p>
次にまとめ資料の作成</strong>です。
Whizlabsを進めながら、引っかかった箇所をAWSの公式ドキュメントで確認し、その内容をClaude Codeに渡してAsciiDocのドキュメントに積み上げていきました。最終的に約100ページになりました。</p>


Claude Code に積み上げさせたまとめ資料の目次</figcaption>
</figure>
やっていることは単純で、公式ドキュメントを読んで理解した内容を、自分が後で引ける形に整えているだけです。IAMの最小権限やクロスアカウント構成のように、AWSの一般知識とBedrock固有の事情が混ざる領域ではこの整理が効きました。</p>
この資料作成でほぼ知識は整理できたので、資料自体は一読して読み返していません。</p>
MulmoClaude に学習環境を作らせる</h2>
MulmoClaudeで自分用の模擬問題集を作りました。
MulmoClaude</a> はあの中島聡氏が開発しているClaude Codeのマルチモーダルクライアントです。
独自の模擬問題集を作った理由は、Whizlabsが英語ベースなので日本語版が欲しかったのと、独自にまとめたナレッジも折り込みたかったからです。</p>
Whizlabsをベースにしていますが、まとめ資料や公式ドキュメントから解説を加えています。
設問は本番と同じシナリオ形式にして、選択肢もすべて技術的には成立するものを並べる形にしました。</p>


自作した模擬問題集の演習画面</figcaption>
</figure>
回答するごとに、その正誤を履歴を記録しています。</p>
更にMulmoClaude上で進捗ダッシュボードを用意して、ドメイン別の進捗と、概念別にどこで落としているかを見えるようにしました。</p>


ドメイン別の習得状況と出題形式別の内訳を表示する進捗ダッシュボード</figcaption>
</figure>
「直近2回連続で正解したら習得」としました。初見の設問に対する最初の解答は、当てずっぽうで当たっている可能性が排除できないからです。この定義にすると、まぐれ当たりの問題が習得済みに紛れ込まなくなり、繰り返すべき問題だけが残ります。
間違えた問題を中心に5周ほど回しました。</p>
私の場合、MulmoClaudeで環境を作ること自体が学習のモチベーションになりました。ただし効率で言えば、既存の模擬試験を買ったほうがよいと思います。回答履歴の管理や弱点対応、メモの書き込み、AIによるその場での質疑応答などは、多くのサービスですでに備えています。</p>
詰め方としては、弱点である問題に絞っていくアプローチが効きました。周回を重ねるほど残る問題が減り、後半ほど1周が短くなります。進んでいる実感が出るので、最後まで続けられました。</p>
AIP-C01の選択肢には癖がある</h2>
学習する中で気付いた選択肢の癖をまとめておきます。誤答を消去していく手がかりとして個人的には役立ちました。</p>


    </div>
    
        本番の出題傾向ではありません</strong>
        私が公式模試やWhizlabsから学習する中で気付いた傾向であって、本番の出題傾向ではありません。</p>

    </div>
</div>


リトライやスロットリング対策の文脈で「指数バックオフ（exponential backoff）」を含む選択肢が出てきたら、正解である確率が高い。AWSが公式に推奨するリトライ戦略であり、対比として置かれる固定間隔リトライや無制限リトライは設計として明確に劣るためだと理解している</li>
Amazon Kendraは、誤答側の選択肢である可能性が高い。エンタープライズ検索のサービスであって、Bedrock Knowledge BasesでRAG（Retrieval-Augmented Generation）を組む構成が用意されている以上、生成AIアプリケーションの検索層としては選ばれにくい位置にある</li>
ファインチューニングも、誤答側である可能性が高い。RAGやプロンプトエンジニアリングで満たせる要件に対して、過剰な手段として置かれることが多い。データ準備の重さと運用コストが、要件に見合わない形で設問に埋め込まれている</li>
固定長チャンキング（fixed-size chunking）は、常に品質劣化の原因側として扱われていた。意味の切れ目を無視して機械的に区切るため、検索の精度が落ちる側の選択肢になる</li>
最も多く登場したサービスはAWS Step Functionsである。生成AIのアプリケーションでも、複数ステップのオーケストレーションや人間の承認を挟むワークフローの受け皿として顔を出す</li>
</ul>
これらを暗記のリストとして使うでなく、なぜその選択肢が誤答側に置かれるのかを言語化しておくことに意味があります。
初見の設問でも同じ判断ができるようになります。</p>
試験当日とスコア</h2>
会場はテストセンターです。試験時間は180分ですが、実際にかかったのは見直しと終了後アンケートを含めて60分程度でした。分からない問題を粘っても答えが出るわけではないので、決めたら次に進むという解き方をしています。</p>
体感の内訳を正直に書きます。模擬問題で身に付けた知識をそのまま応用できたのが約4割。自分の知識も使って論理的に導き出せたが確信は持てなかったのが約2割。残る約4割は、ほぼ勘です。</p>
結果は合格、スコアは779点でした。合格ラインの750点から29点差です。4割を勘で答えたという体感と、この点差は整合していると思います。</p>
セクション別の評価は次のとおりでした。</p>


    合否は合計スコアだけで決まり、セクションごとの合格ラインは存在しません。</p>

</aside>

コンテンツ分野</th> 配点</th> 評価</th></tr></thead>

1. 基盤モデルの統合、データ管理、コンプライアンス</td> 31%</td> コンピテンシーを満たしている</td></tr>
2. 実装と統合</td> 26%</td> コンピテンシーを満たしている</td></tr>
3. AI の安全性、セキュリティ、ガバナンス</td> 20%</td> コンピテンシーを満たしている</td></tr>
4. GenAI アプリケーションの運用効率と最適化</td> 12%</td> 改善が必要</td></tr>
5. テスト、検証、トラブルシューティング</td> 11%</td> 改善が必要</td></tr>
</tbody></table>
学習期間が短かったので配点の多い上位3つドメインにフォーカスしたので、ある意味狙い通りでした。</p>
まとめ</h2>
8月3日から受験日までの3週間、集中して取り組んだように見えるかもしれませんが、実際には大半の時間が
スプラトゥーン レイダース</a>
の無限食堂に溶けていました。勉強そのものに充てたのは、体感で20時間程度です。</p>
試験対策の要点をまとめると、次の5点です。</p>

割引バウチャー特典は必ずチェック</li>
AWSの基本的な知識(AWS Certified Solutions Architect – Associateレベル)は前提として必要</li>
知識の整理にはLLMを活用</li>
模擬試験で知識を整理し、試験形式に馴れておく</li>
上位3コンテンツ分野にフォーカスして学習</li>
</ul>
AWSを離れたたった2年の期間で生成AIを活用したシステムの典型的なアーキテクチャーがここまで整理され、クラウドプラットフォームではそれを支えるサービスラインナップがここまで充実し具現化していることが、個人的には驚きでした。
AWS自身が、生成AIを活用したアーキテクチャーのベストプラクティスを説明するものとして
"AWS Well-Architected Generative AI Lens</a>"と言うドキュメントを公開しています。試験には必須ではありませんが、現役の方はぜひ目を通しましょう。</p>
生成AIをどうやってシステムに組み込むのかと悩んでいた時代は過去のものですね。</p>
References</h2>


    
AWS</a>. 「AWS Certified Generative AI Developer - Professional (AIP-C01) 試験ガイド」</li>
AWS</a>. 「AWS Certified Generative AI Developer - Professional」</li>
AWS Skill Builder</a>. 「AWS Certified Generative AI Developer - Professional Official Practice Question Set」</li>
Credly</a>. 「AWS Certified Generative AI Developer - Professional（デジタルバッジ）」</li>
Whizlabs</a>. 「AWS Certified Generative AI Developer - Professional (AIP-C01) Certification Training」</li>
</ul>

</div>



Cloudflare OS - OSでなく生成AIエージェントで実現するLong-Tail業務アプリ基盤
2026-08-19T00:00:00+00:00



Table of Contents</summary>

</details>
2026年8月5日、CloudflareがAIワークスペース「Cloudflare OS」をApache-2.0ライセンスで公開しました。翌日にはHacker Newsのフロントページに載り、GitHubのリポジトリ</a>のスターは公開初日に3,900、8月19日時点では8,500を超えています。</p>
"OS"という名前を見て、私はまずLinuxやWindowsの系譜を想像しました。しかし発表内容を読むと、これは伝統的な意味でのOSではありません。Cloudflareが自社の全社員向けに作って運用してきた社内AIワークスペースを、丸ごと公開したものです。名前の大きさと中身のあいだにある落差が、この製品を考える上での出発点になります。</p>
Cloudflare OSとは何か？</h2>
Cloudflare OSが何かを語る前に、まず下回りから見ていきましょう。この製品を実装しているのは、既存のCloudflare製品の束ね直しです。Workers、Durable Objects、Access、AI Gateway、R2に、ツール接続のMCPとRPCのCap'n Webが加わります。新しいインフラを作ったわけではありません。</p>
役割で並べ替えると、計算資源、状態の保持、認証、AIモデルへの接続、ストレージ、そしてツール接続という並びになります。これは2026年にエージェント基盤を名乗る製品であればどこも持っている組み合わせで、この層に「OS」と名乗る根拠はありません。インフラとして見る限り、ここにあるのは典型的な生成AIエージェント基盤</strong>です。</p>
Cloudflareは、生成AIエージェント基盤としての機能を3つに分けて説明しています。</p>
構成要素</th> 内容</th></tr></thead>

Agent Workspace</td> ブラウザのチャットUI。非エンジニアの利用も想定している</td></tr>
セキュリティとガバナンスの層</td> 外部へはGatekeeper経由でしか届かない。権限はcapabilityで渡し、アクセスは記録する</td></tr>
Gadget</td> 成果物1つごとに、エージェントが専用のソフトウェアを書いて動かす</td></tr>
</tbody></table>
Gadgetは一から作らせるほかに、既存のGadgetのコードを雛形にして作れます。この雛形はBlueprintと呼ばれ、標準では3つが同梱されています。</p>

workspace-docs: ドキュメント</li>
workspace-sheets: スプレッドシート</li>
workspace-slides: スライド</li>
</ul>
事務作業の最低限だけが置かれていて、あとは各自で増やす、という構えです。自作したGadgetも、中身のデータは渡さずコードだけをBlueprintにして配れます。</p>
ここで各自が増やすものとして想定されているのが、long-tailの業務です。1件あたりの規模は小さいものの種類がとにかく多く、IT部門に頼むほどではないけれど手元では面倒、という類の作業を指します。特定のチームだけが使う集計表、月に数回しか動かさない進捗の一覧、部署内で回している申請の受付といったものです。数が多すぎて基幹システムには載らず、これまでExcelやAccessが引き受けてきた領域でもあります。</p>
まとめると、Cloudflare OSは、利用社員が自らチャットで指示して成果物と個々の成果物専用のGadgetを構築できる生成AIエージェント基盤です。アプリごとに資源を割り当てて互いに隔離し、外部との入出力を仲介するという役回りを見れば、比喩として「OS」は的外れとも言い切れませんが、基本的には各社のエージェント基盤と大きく変わりません。</p>
ドキュメント単位に閉じるという設計</h2>
ドキュメント単位の隔離</strong>が、設計方針の中でもっとも目を引く部分です。アプリの実体であるGadgetは、ドキュメント1つにつきDurable Objectのインスタンスが1つ割り当てられ、専用のWorkerとSQLiteストレージを持ちます。ブラウザ側ではiframeに閉じ込められ、CSPのconnect-src 'none'</code>によってネットワークへの到達そのものが断たれます。外に出たければGatekeeperを通すしかなく、そのGatekeeperが認証情報を握ってスコープを絞った操作だけを許す、という構造です。</p>
この作りが効くのは、中身が検証されていないコードを前提にできるからです。Gadgetを書くのはエンジニアではなく、非エンジニアの指示を受けたAIで、レビューやテストは通っていません。不具合があっても、そのGadgetは外部へ接続する手段を持たず、隣のドキュメントのデータにも手が届きません。悪意のある指示が埋め込まれたファイルを読んでしまった場合も同じです。社内システムに届くのは、Gatekeeperを通ったあらかじめ絞られた操作だけです。さらに生成物を他人へ共有する段になると、元になったデータへの権限を相手が持っているかどうかが、あらためて確認されます。Cloudflare自身、非エンジニアが安心して好きに触れることを設計目標として挙げています。</p>
Cloudflare OSを主導したKenton Vardaは公開時に、これは10年前の自分のスタートアップSandstorm.ioのリメイクだと述べています。10年前この構想が広まらなかった理由は2つあります。対応アプリが足りなかったことと、インスタンスごとにコンテナを立てる実行基盤が重すぎたことでした。10年を経て、ミリ秒起動するWorkersが前者の重さを解き、生成AIが「対応アプリを人が移植する」という前提そのものを消しました。エージェントがその場でアプリを書くのであれば、アプリストアを埋める必要はありません。</p>
つまりCloudflare OSの中核にある思想は、生成AIブームの産物ではなく、条件が揃うのを10年待っていた設計です。</p>
OSSだがCloudflare前提</h2>
「OSSで公開」「セルフホスト可能」と聞くと、自社データセンターに閉じた運用を思い浮かべるかもしれません。しかしCloudflare OSのセルフホストとは、Cloudflareのネットワーク上にある自社アカウントへデプロイすることを指します。実行基盤は必ずCloudflare</strong>です。OSSであることは、中身が透明で、自由に改変でき、UIに縛られないという意味です。インフラからの独立を意味するわけではありません。</p>
これがOSSであるCloudflare OSのマネタイズの源泉だと考えています。Cloudflare自身が明言しているわけではありませんが、razor-and-blades、つまり本体を無料で配りそれが消費する下回りで課金する構図です。課金ポイントは、Workersの実行、Durable Objects、Workers AIとAI Gateway、R2、そしてAccessやZero Trustのシートに分散しています。
OSSは自社クラウドの消費を増やすための入口だという見立てです。ダッシュボードに統合されたマネージド版も予告されています。</p>
この構造は、AWS上に同じものを自作した場合と経済モデルとしては変わりません。自分のアプリを他社クラウドに載せて従量課金される、ロックインの形も同じです。ただし専有リソースをあらかじめ確保する方式とは違い、Cloudflareはサーバーレスのマルチテナントです。もっとも、完全に使った分だけというわけでもありません。Gadgetの実体であるDurable Objectsは、メモリ上で起きているあいだwall-clockで課金され、リクエストが来ていなくても料金が発生します。</p>
2026年は「エージェント基盤に名前を付ける」年だった</h2>
Cloudflare OSを「生成AIエージェント基盤」とすると、この分野ではCloudflareはむしろ後発です。
ハイパースケーラー3社は数か月から半年先行して、同種の基盤を投入しています。</p>
企業</th> 基盤の名前</th> 時期</th> 性格</th></tr></thead>

AWS</td> Bedrock AgentCore</td> 2025年10月13日 GA</td> Runtime、Gateway、Memory、Identity、Observabilityの部品群</td></tr>
Google</td> Gemini Enterprise Agent Platform</td> 2026年4月22日 Next '26</td> Vertex AIの後継。Workspaceと密結合し、サンドボックス実行とA2A</td></tr>
Microsoft</td> Microsoft IQとFoundry Agent Service</td> 2026年6月2日 Build 2026</td> Work IQなど4層のコンテキスト層。M365エコシステムに密結合</td></tr>
Cloudflare</td> Cloudflare OS</td> 2026年8月5日 OSS公開</td> 社内で運用済みの完成ツールをApache-2.0で配布</td></tr>
</tbody></table>
各社に共通するのは、エージェント基盤に固有の名前を付けてブランド化したことと、ツール接続の共通土台としてMCPを採用したことです。</p>
Cloudflare OSが他社と違うのは2点です。</p>

非エンジニアによるエージェント利用が前提:</strong> 他社の基盤は、エージェントを組むのがエンジニアであることを暗黙の前提にしている。Cloudflare OSは逆で、レビューやテストを通っていないコードが動く前提に立つ。成果物1つごとに隔離し、ネットワークを最初から断ち、認証情報をコードに渡さないのは、そのためである</li>
企業での提供方法:</strong> 他社が出しているのはIT部門が組み合わせてエージェントを作るための構成要素だが、Cloudflare OSは自社の全社員が数か月使ってきた完成品がそのまま、しかもApache-2.0で出てくる</li>
</ol>
機能として「AWSでは同じことができない」わけではありません。IAMとAgentCoreのIdentityやGatewayを組み合わせれば、同等のことは実現できます。違うのは、それを誰かが組み上げなくても最初からそうなっている点です。</p>
これは"OS"ではなく、業務アプリの器である</h2>
では、Cloudflare OSで実際に何が作られているのか。ドキュメント、スライド、スプレッドシート、ちょっとした集計、小さな社内アプリ、定型作業のワークフローです。</p>
エンタープライズITで「アプリケーション」と言えば、通常は基幹系を指します。ERP、会計、受発注、在庫、勘定系。トランザクションの整合性が求められ、可用性のSLAがあり、監査に耐える必要があります。壊れれば業務が止まるもの、いわゆるsystems of recordです。Cloudflare OSが生成するものは、そこには届きません。OA用途、systems of engagement、long-tailのシャドーITといった領域です。</p>
つまり本物の業務システムはGatekeeperの向こう側にあり、Cloudflare OS自身はその前段に立つフロントであり糊の層です。"an open platform for agents, apps, and work"という名乗り、とりわけ"OS"と"apps"という語の選び方は、実態より大きく見せています。</p>
もっとも、名前が大げさであることと、カテゴリとして無価値であることは別の話です。ここからが本題になります。</p>
KintoneとMulmoClaudeと同じ家系</h2>
Cloudflare OSを理解するのに一番近い補助線は、他社のエージェント基盤よりもKintoneではないかと思いました。軽量な業務アプリを部品から組む、という核心が一致しています。部品のライブラリがあり、アプリの器があり、そこに近年は生成AIによるアプリ生成が加わる。この構図は両者で同じです。</p>
そして私が愛用している</a>MulmoClaudeも非常に近い系統にあると思います。</p>
三者の違いは、生成の主体と、想定するスコープです。</p>
ツール</th> 誰が組むか</th> 中心にあるもの</th></tr></thead>

Kintone</td> 人間がノーコードで組む</td> チーム、構造化DB、ワークフロー</td></tr>
Cloudflare OS</td> エージェントが実コード込みで生成</td> 企業全体、ガバナンス付きの共有</td></tr>
MulmoClaude</td> エージェントが対話から生成</td> 個人のワークスペース、成果物</td></tr>
</tbody></table>
long-tailやengagementの層に向けたAIアプリ基盤は、どこも同じ形に収束しつつあります。Cloudflare OSが特別なのではなく、ノーコードによる市民開発が生成AIを得たときに行き着く先が、たまたまこの形だったということでしょう。</p>
この見立ては、"OS"という名前への違和感を少し和らげてもくれます。Kintoneは基幹系ではありませんが、正当な業務アプリのカテゴリとして市民権を得ています。</p>
ただし過大評価は禁物です。できるのは軽いlong-tailだけで、複雑な業務ロジックや厳密な整合性が要る場面では手が止まります。生成AIのアプリ生成も同じで、動く小物はすぐ出てきますが、保守、データの一貫性、権限設計、エッジケースの処理には結局人手が要ります。「作れる」と「運用に耐える」のあいだは、思っているより広いままです。</p>
本質は「IT部門に頼むほどでもない雑務を、その場で楽にする」道具であって、革命ではなく時短だと捉えるのが妥当だと思います。</p>
EUCの亡霊、あるいは誰がこれを維持するのか</h2>
そして、この家系のツールには必ず突き当たる問題があります。作った業務アプリを、誰がどう維持するのかという問題です。</p>
かつてエンドユーザーコンピューティング(EUC)が抱えた病理は、よく知られています。</p>
病理</th> 内容</th></tr></thead>

属人化</td> 作った本人しか仕様を知らない。ドキュメントはなく、異動や退職でブラックボックスになる</td></tr>
野良アプリの増殖</td> IT部門が把握しないアプリが社内に散らばり、棚卸しも統制も効かなくなる</td></tr>
塩漬けとデータの人質化</td> 改修できないまま動かし続け、データが特定のアプリに囲い込まれる</td></tr>
</tbody></table>
構造的な皮肉は、ノーコードが「作る敷居」を下げても「保守する敷居」は下げないことです。素人が速く大量に、保守できないものを量産できるぶん、事態はむしろ悪化しえます。1990年代から2000年代の「Excelマクロ地獄」「Accessデータベース地獄」が語られたときと、道具が変わっただけで病理は変わっていません。</p>
Kintoneには監査ログや、管理者が1人しかいないアプリを洗い出すガバナンス機能があり、統制の側には手が打たれています。しかし棚卸しができることと、そのアプリを引き継げることは別です。作った人が異動すれば、なぜその形にしたのかは失われます。作る敷居を下げた分だけ、この保守の問題はより広く組織に行き渡ります。
MulmoClaudeはそもそも個人利用を想定しており、使い捨て前提なので、この病理は当てはまりません。</p>
では、Cloudflare OSはこの病理にどのように手を当てているのでしょう。</p>
先に見たドキュメント単位の隔離とGatekeeperは、セキュリティの話であると同時に、EUCの統制のメカニズムでもあります。</p>
Excelマクロが厄介だったのは、そのファイルが誰のPCにあるのか誰も知らず、埋め込まれた接続情報が作者の退職後も生き続け、データそのものがファイルの中に囲い込まれていたからでした。Cloudflare OSでは、アプリはGadgetとして基盤の上に載り、社内システムへの経路はGatekeeperに一本化され、どのアプリがどのデータを見たかは記録に残ります。少なくともIT部門が棚卸しをする手段はある、という点で、ファイルサーバーに散らばったマクロとは事情が違います。</p>
認証情報をアプリに持たせない設計も、ここで効いてきます。作った本人の権限が失効すればアプリの持つcapabilityも一緒に失効するので、退職者の作ったものが基幹システムを叩き続ける事態は起きにくくなります。放置されたGadgetは、危険なまま動き続けるのではなく、単に無力になるわけです。データが元のシステム側に残り、アプリはその上に載る窓でしかない点も、人質化を弱めます。かつてのEUCで実際に事故になったのは、この「勝手に外へ手を伸ばす」部分でした。そこは確かに塞がっています。</p>
手当てが届いているのは、統制と被害半径の側です。残るもう半分、つまり中身を誰が理解しているのかという問題には、この設計は何もしません。そして生成AIが加わると、ここはもう一段悪くなりかねません。Cloudflare OSのように非エンジニアが使うことを前提にした設計では、そもそもコードを読む人がいません。属人化を通り越して無人化です。保守の観点だけを見れば、これは退化とも言えます。</p>
Cloudflare OSがこの点をどう設計しているのでしょうか。
GatekeeperとcapabilityはCloudflare OSが既存の社内システムとどう連携するかをよく統制します。しかし、生まれたアプリを3年後に誰が直すのかは統制してくれません。</p>
答えは設計そのものに書かれています。成果物1つごとに独立したGadgetを与えるということは、共通のコードベースが存在しないということです。Blueprintから作ったGadgetにも、後から元の修正を反映する仕組みはありません。これらを維持する前提は置かれていません。MulmoClaude同様、個人の中で完結し使い捨てるものとして設計されていると考えます。</p>
課題は、組織が使い捨てと理解して使うかどうかだけです。</p>
References</h2>


    
Cloudflare Blog</a>. "Cloudflare OS: an open platform for agents, apps, and work"</li>
Cloudflare</a>. "Cloudflare OS Is the First AI Workspace Built Around How Companies Actually Work"</li>
GitHub</a>. "cloudflare/cloudflare-os"</li>
AWS</a>. "Amazon Bedrock AgentCore is now generally available"</li>
Google Cloud Blog</a>. "The new Gemini Enterprise: one platform for agent development"</li>
Microsoft Azure Blog</a>. "Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases"</li>
Kenton Varda (X)</a>. "This is a remake of Sandstorm.io, my startup from 10 years ago"</li>
</ul>

</div>



MulmoTerminalのような通知をWezTermとClaude Codeで実現する
2026-08-12T07:48:08+09:00



Table of Contents</summary>

</details>
はじめに</h2>
中島聡氏らが開発しているMulmoTerminal</a>を少し使ってみました。複数のAIエージェントをブラウザ上のターミナルに並べ、各エージェントの状態を一目で分かるようにしたツールです。私はClaude Codeしか使っていないので全体としてはピンと来ませんでしたが、この状態表示の部分だけは便利だと感じました。</p>
そこで、私が普段使用しているWezTermの画面分割とClaude Codeで同じような通知を可能とする仕組みを作ってみました。</p>


タブラインに表示されたClaude Codeの状態</figcaption>
</figure>
WezTermのタブラインの先頭にClaude Codeのステータス表示を追加し、入力待ちやタスクが完了した場合にClaude Codeのペインが明滅するようになりました。</p>
この仕組みを claude-state</strong> と名付けました。以降はこの呼び名で説明します。スクリプトやキャッシュディレクトリは wezterm-claude-state</code> という名前で置いているため、本文に出てくるパスはその形になります。</p>
claude-stateの仕組み</h2>
claude-stateは、Claude CodeとWezTermの間に状態ファイルを1枚挟んだだけの単純な仕組みです。Claude Code側のフックが現在の状態を書き込み、WezTerm側のLuaがそれを読んでタブラインに表示します。</p>