<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>npmrundev の記事フィード</title>
        <link>http://izanami.dev/organizations/npmrundev</link>
        <description>npmrundev に関連する記事のRSSフィードです</description>
        <lastBuildDate>Tue, 14 Apr 2026 11:33:27 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>izanami RSS Feed</generator>
        <language>ja</language>
        <image>
            <title>npmrundev の記事フィード</title>
            <url>http://izanami.dev/favicon.ico</url>
            <link>http://izanami.dev/organizations/npmrundev</link>
        </image>
        <copyright>All rights reserved 2026</copyright>
        <item>
            <title><![CDATA[Claude Code で、広告バナー200本を15分で作るえぐい手順（やってみた）]]></title>
            <link>http://izanami.dev/post/33bc0c0f-4210-4f5e-90e5-4ee8efe9ac66</link>
            <guid>http://izanami.dev/post/33bc0c0f-4210-4f5e-90e5-4ee8efe9ac66</guid><dc:creator>commte</dc:creator>
            <pubDate>Sun, 22 Feb 2026 11:47:48 GMT</pubDate>
            <description><![CDATA[前回のポストで紹介した Anthropic マーケチームの手法、「で、実際どうやるの？」って人いそうだから、実際にやってみた

X で毎日 AI 情報を配信してる[コムテ](https://x.com]]></description>
            <content:encoded><![CDATA[前回のポストで紹介した Anthropic マーケチームの手法、「で、実際どうやるの？」って人いそうだから、実際にやってみた

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code テクニックを中心に情報を配信しています

[前回のXポスト](https://x.com/commte/status/2024771301538435201)

Claude Code のサブエージェントで広告コピーを量産して、自作の Figma プラグインでバナーを 20 パターン一気に生成するまでの全手順を書く

結論から言うと、サブエージェント作成からバナー 20 枚生成まで、15 分かからなかった

相当簡単だから、みんなもやってみ？

この記事バージョンアップするから、後で試したい人は、ブクマしておくんやで

ステップ 1 - サブエージェントで広告コピーを CSV 出力

まず  にサブエージェントを 2 つ作った

1 つ目は headline-writer.md（見出し専用）。30 文字以内で広告の見出しだけを生成するエージェント

2 つ目は description-writer.md（説明文専用）。90 文字以内で説明文だけを生成するエージェント

なんで分けるかって言うと、1 つのプロンプトに「見出しも説明文も両方作って」と頼むと、文字数制限を守れなかったり品質が下がったりするんよね。Anthropic のチームも同じ理由で分けてた

サブエージェントの作り方はシンプルで、Markdown ファイルに YAML フロントマターで name、description、tools を書いて、本文にシステムプロンプトを書くだけ

こんな感じ



説明文用も同じ要領で作る。ポイントは出力形式を CSV に指定すること。後で Figma プラグインに食わせるから

そんで Claude Code に以下を指示



2 つのサブエージェントが並列で動いて、数分で見出し 20 本 + 説明文 20 本の CSV が出来上がった

見出しの例

- 「個人開発プロダクトを無料で公開しよう」
- 「あなたの技術、埋もれていませんか？」
- 「SEO最適化済みで検索に強い技術ブログ」

全部 30 文字以内。訴求ポイントもトーン（疑問形、断定形、呼びかけ形）もバラバラに散らしてくれた

ステップ 2 - Figma プラグインを Claude Code で自作

ここが一番「え、そんなことできるの？」ってなるところやね

作り方は簡単よ

Claude Code に以下を指示した



Claude Code が作ってくれたのは 3 つのファイル

1. manifest.json - プラグインの設定ファイル
2. ui.html - CSV をアップロードする画面
3. code.js - テンプレ複製＋テキスト差し替えのロジック

仕組みはこう。Figma の Plugin API を使って、テンプレートフレーム内のテキストノードをフォントサイズで判定する。一番大きいのが見出し、次が説明文。CSV の行数だけテンプレを複製して、テキストを差し替えてグリッド配置する

エンジニアじゃなくても Claude Code がコード全部書いてくれるから、「何を作りたいか」が言語化できれば作れる。自分はコードを 1 行も書いてない

ステップ 3 - テンプレート作成 → バナー量産

まずバナーのテンプレートを 1 つ作った。今回は HTML で作って Claude Code to Figma 機能で送った

Claude Code to Figma は、CC に Figama MCP をインストールするだけ

テンプレートの構成

- 背景（グラデーション）
- ロゴ（izanami）
- 見出しテキスト
- 説明文テキスト
- CTA ボタン（「無料で始める」）
- URL（izanami.dev）

このテンプレが Figma に入ったら、プラグインを起動する

Figma デスクトップアプリで「プラグイン → 開発 → マニフェストからプラグインをインポート」で manifest.json を選択。これでプラグインが読み込まれる

プラグインを起動して、headlines.csv と descriptions.csv をアップロードして「バナーを生成」をクリック

一瞬で 20 パターンのバナーが Figma 上に並んだ

見出しと説明文がそれぞれ違うバリエーションで、テンプレの見た目はそのまま。手作業でコピペしてたら 1 時間以上かかる作業が、ボタン一発で終わった

全体の流れまとめ

1.  にサブエージェント 2 つ作成（2 分）
2. Claude Code で CSV 出力を指示（3 分）
3. Claude Code で Figma プラグインを自作（5 分）
4. テンプレート作成 → Figma に送る（3 分）
5. プラグインで 20 パターン一括生成（1 分）

合計 15 分以内。コードは 1 行も手書きしてない

ポイント

- サブエージェントは  に Markdown を置くだけで作れる
- タスクごとに専門のエージェントを分けるのが品質を上げるコツ
- Figma プラグインの自作はハードル高そうに見えるけど、Claude Code が全部書いてくれる
- CSV の出力形式を最初に決めておくと、プラグインとの連携がスムーズ
- いきなりコードを書かない。まず全体のワークフローを設計してから Claude Code に渡す

感想

もはや、この方法使えば広告関係で困ることはないと思ったね

広告運用じゃなくても、LP のコピー、SNS 投稿画像、メールのバリエーションテストなど、同じ構造で応用できるよな

サブエージェント使って、プラグイン作れって話やね

自分のサービスの広告をこの手法で作ったけど、正直もう手動には戻れないよ

[サブエージェントの公式ドキュメント](https://code.claude.com/docs/en/sub-agents)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Anthropic 社内のマーケティングチームが Claude Code をガチ運用してた話]]></title>
            <link>http://izanami.dev/post/b56cafbc-4d8d-477a-8629-b5ef70282f2b</link>
            <guid>http://izanami.dev/post/b56cafbc-4d8d-477a-8629-b5ef70282f2b</guid><dc:creator>commte</dc:creator>
            <pubDate>Sat, 21 Feb 2026 09:02:47 GMT</pubDate>
            <description><![CDATA[Anthropic が公式ブログで、社内チームが Claude Code をどう使っているかの事例を公開した。中でもグロースマーケティングチームの使い方がえぐい。しかも全部、真似できる

X で毎日 ]]></description>
            <content:encoded><![CDATA[Anthropic が公式ブログで、社内チームが Claude Code をどう使っているかの事例を公開した。中でもグロースマーケティングチームの使い方がえぐい。しかも全部、真似できる

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code テクニックを中心に情報を配信しています

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/6021b7a8-10da-4c6e-9da3-39c245ed9401.png)

再現してみた。Figma プラグインとサブエージェントを作る

2026/02/22。具体的な方法はこちらに書きました！↓

https://izanami.dev/post/33bc0c0f-4210-4f5e-90e5-4ee8efe9ac66

このチームは検索広告、SNS 広告、アプリストア、メールマーケティング、SEO を担当していて、驚くのは「非技術者 1 人のチーム」ということ。エンジニアがいない。Claude Code だけで、普通ならエンジニアリングリソースが必要な仕事を回してる

公式ブログ（英語）
https://claude.com/blog/how-anthropic-teams-use-claude-code

[Xでの資料](https://x.com/robjama/status/2023151595295268939)を参考にした

何をやっているのか、4 つのユースケースを紹介する

ちなみにこの事例が面白いのは、「AI を使ってマーケティングを効率化した」という話じゃなくて、「Claude Code で自分専用の自動化ツールを作った」という話であること。ここが重要

1. Google Ads のクリエイティブ自動生成

数百件の既存広告データ（CSV）をまるごと Claude Code に読ませて、成果が悪い広告を自動で特定する。そこから新しい広告コピーを生成するんだけど、ここが面白い

見出し用（30 文字制限）と説明文用（90 文字制限）で、別々のサブエージェントを用意してる。1 つのプロンプトに全部やらせるんじゃなくて、タスクごとに専門のエージェントを分けてる

これで複数キャンペーン分の広告を数分で生成。手作業だと何時間もかかるやつが、一瞬で終わる

ポイントは「サブエージェントに分ける」という設計判断。1 つのプロンプトで見出しも説明文も全部生成させると品質が下がる。それぞれに専門のエージェントを割り当てることで、文字数制限を守りながら品質を担保してる

2. Figma プラグインで広告を大量生産

SNS 広告の静止画って、基本的に同じデザインの見出しと説明文を差し替えて量産する作業なんよね。これを手動でやると、コピペ地獄になる

そこで Claude Code を使って Figma プラグインを自作した。フレームを自動認識して、見出しと説明文を差し替えることで、最大 100 パターンの広告バリエーションを一気に生成する

数時間のコピペ作業が 1 バッチ 0.5 秒に。クリエイティブの生産量は 10 倍になったらしい

3. Meta Ads の MCP サーバーでキャンペーン分析

Meta Ads API と連携する MCP サーバーを構築して、Claude Desktop アプリ内から直接キャンペーンの成果を確認できるようにした

何がいいかというと、広告管理画面にログインしてタブを切り替えて数字を確認して、みたいな作業が全部なくなる。Claude Desktop を開くだけで、キャンペーンのパフォーマンス、支出、広告効果がまとめて見れる

地味だけど、毎日やる作業の効率化は ROI に直結する

MCP（Model Context Protocol）はまさにこういう使い方のために設計されてる。外部ツールの API を Claude に繋いで、自然言語で操作できるようにする仕組み。広告運用以外でも、Slack、GitHub、データベースなど応用範囲は広い

4. メモリシステムで自己改善する広告テスト

これが一番賢い。広告の A/B テストって、何を試して何が効いたのかを人間が管理し続けるのは限界がある

このチームは Claude Code で簡易メモリシステムを作って、過去の仮説と実験結果を記録するようにした。新しい広告バリエーションを生成するたびに過去のテスト結果を参照して、精度を上げていく仕組み

テストするたびに賢くなるフレームワーク。手動では絶対に追いつけない

なぜこの事例が参考になるのか

よくある「AI で業務効率化しました」系の事例って、大企業のエンジニアチームが何ヶ月もかけて作りましたみたいな話が多い。再現性がない

でもこのチームは非技術者 1 人。Claude Code を使って、自分で Figma プラグインも MCP サーバーも作ってる。つまりコードを書く能力じゃなくて「何を自動化すべきか」を見極める能力が重要だということ

広告運用じゃなくても、同じ発想は使える。営業の提案書作成、カスタマーサポートの定型対応、データの集計レポート。API があって繰り返してる作業なら、全部候補になる

結果

- 広告コピーの作成時間が 2 時間 → 15 分に短縮
- クリエイティブの生産量は 10 倍
- 1 人で、大きなチームと同じ仕事量をこなせるようになった
- 手作業の実行ではなく、戦略設計に時間を使えるようになった

チームが語る 3 つのコツ

1. API があるツールの繰り返し作業を狙う

広告プラットフォーム、デザインツール、分析基盤。API を持ってるツールでの反復作業は、Claude Code による自動化の最有力候補。まずはここから探す

2. タスクごとにサブエージェントを分ける

1 つのプロンプトに全部やらせない。見出しエージェントと説明文エージェントを分けたように、タスクごとに専門のエージェントを作る。デバッグが楽になるし、出力の品質も上がる

3. いきなり Claude Code でコードを書かない

まず Claude .ai でワークフロー全体を設計する。何をどういう順番でやるか、プロンプトの構成はどうするか。全体像を固めてから Claude Code に渡す。一発で完成させようとしないのがコツ

まとめ

エンジニアじゃなくても、Claude Code でここまでできる。「エンジニアリングリソースがない」はもう言い訳にならない時代になってきてる

特に参考になるのは、Figma プラグインや MCP サーバーを「自分で作る」という発想。既存のツールを使うだけじゃなくて、自分の業務に合った自動化ツールを Claude Code で作るという選択肢がある

API がある繰り返し作業を見つけて、サブエージェントで分割して、Claude .ai で設計してから Claude Code に渡す。このフローは広告運用に限らず、どんな業務にも応用できる

自分の業務で「これ毎回同じことやってるな」と思う作業があったら、それが Claude Code で自動化できる最初の候補。エンジニアかどうかは関係ない
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code to Figma を実際に試してみた]]></title>
            <link>http://izanami.dev/post/d2cb475d-38bd-42b1-8ce1-7f381cef543e</link>
            <guid>http://izanami.dev/post/d2cb475d-38bd-42b1-8ce1-7f381cef543e</guid><dc:creator>commte</dc:creator>
            <pubDate>Wed, 18 Feb 2026 20:08:31 GMT</pubDate>
            <description><![CDATA[Figma と Anthropic が公式連携機能「Claude Code to Figma」をリリースした。Claude Code で作った UI をそのまま Figma に編集可能なフレームとして]]></description>
            <content:encoded><![CDATA[Figma と Anthropic が公式連携機能「Claude Code to Figma」をリリースした。Claude Code で作った UI をそのまま Figma に編集可能なフレームとして取り込めるらしい。

本当にできるのか、実際に手を動かして検証してみた

Claude Code to Figma って？

Claude Code で作った UI を、ブラウザからキャプチャして Figma に送信する機能。送られたデータはスクリーンショットではなく、Figma 上で編集可能なデザインフレームとして取り込まれるって感じ

ボタンのサイズ、色、角丸、フォントなどを Figma 上で個別に変更できる状態で届く

localhost でも本番環境でもステージングでもキャプチャ可能で、複数画面の一括キャプチャにも対応してるんよな

Figma Make との連携もできる

[@Emukei](https://x.com/Emukei/status/2024073906110242909)さんに教えてもらったんだけど、Figma Design に取り込んだフレームを右クリックすると「Figma Make に送信する」というメニューが出る

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/19d98477-35af-479c-86b5-90b5713c8d1a.png)

右クリックすると…

Figma Make はプロンプトでデザインを生成・編集できるツール。つまり Claude Code で作った UI を Figma Make でさらにブラッシュアップできる

逆に Make で作ったデザインも、右上のアイコンからコピーして Design に貼り付けられる

セットアップ

Figma MCP サーバーを Claude Code に接続する。リモート MCP サーバーを使えば Figma デスクトップアプリは不要

ターミナルで以下を実行する。でも今、これ不要かも

普通に接続できるっぽいね



これだけで接続完了。Claude Code 内で  コマンドを実行して認証を済ませる

必要な条件はこの3つ

- Claude Code がインストール済み
- Figma アカウント（Dev または Full シート）
- MCP サーバー対応の環境

実際にやってみた

まず Claude Code で簡単な HTML を作った。カード型の UI でボタンが1つあるシンプルな構成



ポイントは head にキャプチャスクリプトを1行追加すること。このスクリプトがブラウザの画面を読み取って、Figma に送信してくれる

次にローカルサーバーで配信。まぁ、適当に



ブラウザでキャプチャ用のパラメータ付き URL を開くと、画面上部にキャプチャツールバーが表示される。「Figma に送信」「画面全体」「要素を選択」などのオプションが並んでいる

キャプチャが完了すると、Figma にファイルが生成される

結果

Figma でファイルを開いてみると、ちゃんと編集可能なフレームになってた

ボタンを選択すると W 320 × H 48 のサイズ情報が表示され、塗りにはグラデーション（6366f1 → 8b5cf6）、角丸は 8px と、元の CSS の値がそのまま反映されている

スクリーンショットを貼り付けたのとは全く違う。レイヤー構造も維持されていて、Container の中に Text、Heading、Paragraph、Button がそれぞれ独立したフレームとして入ってるね

逆方向もいける

Figma に送ったデザインから、逆にコードを生成することもできた

Figma MCP サーバー経由でデザインデータを取得すると、レイヤー構造、色、サイズ、フォント、影などの情報が返ってくる。React + Tailwind CSS のコードとして出力される

つまり、こういう往復ができるんよね

HTML → Figma（Claude Code to Figma）→ React コード（Figma MCP）

デザイナーとエンジニアの間で「Figma のデザインをコードに起こす」「コードの画面をデザインに戻す」が双方向でできるようになった

うまくいかないときは

今回の検証で、キャプチャスクリプトを入れ忘れると送信が pending のまま止まることが分かった

head に以下の1行を追加すれば解決



まぁ、よしなにやってくれってことや

まとめ

検証した結果、Claude Code to Figma は確かに動く。シンプルな UI であれば、コードからデザインへの変換は問題なくできた

手順をまとめると以下の通り

1. Figma MCP サーバーを接続（コマンド1行）
2. Claude Code で UI を作る
3. HTML の head にキャプチャスクリプトを追加
4. ローカルサーバーで配信してブラウザで開く
5. 自動で Figma に送信される

複雑な UI やマルチページのフローについてはまだ試していない。今後検証してみる予定

フロントエンドや個人開発者にとっては嬉しい機能で、Claude Code でプロトタイプを作ってそのまま Figma で仕上げるワークフローが現実的になった
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code のセッション引き継ぎを自動化する]]></title>
            <link>http://izanami.dev/post/3b2789ca-30ee-403f-af43-83e2c7009fb1</link>
            <guid>http://izanami.dev/post/3b2789ca-30ee-403f-af43-83e2c7009fb1</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 16 Feb 2026 14:16:22 GMT</pubDate>
            <description><![CDATA[Claude Code の /handover っていうカスタムスラッシュコマンド、やってみた

セッション終わりに打つだけで、引き継ぎノートを自動生成してくれる

[Zara Zhang (@zar]]></description>
            <content:encoded><![CDATA[Claude Code の /handover っていうカスタムスラッシュコマンド、やってみた

セッション終わりに打つだけで、引き継ぎノートを自動生成してくれる

[Zara Zhang (@zarazhangrui)](https://x.com/zarazhangrui/status/2020992712825241801) さんのポストで知って、自分でも作って試した

何が解決されるのか

最初に断っておくと、これはデフォルトで用意されてるものではない

カスタムスラッシュコマンドなので、後述する方法で作る必要がある

Claude Code はセッションが切れると文脈がリセットされる。CLAUDE .md にプロジェクトのルールは書けるけど、今日どこまでやったか、なぜその設計にしたかは残らないよね

次のセッションで、さっき何やってたっけ？ってなるのを、解決できるかも

/handover の仕組み

.claude/commands/handover .md にカスタムスラッシュコマンドを置く。セッション終了時に /handover と打つだけで、HANDOVER .md がプロジェクトルートに生成される

コマンドの全文。意外と簡単



HANDOVER.md はプロジェクトルートに置くだけだと Claude Code が自動で読むわけじゃない。次のセッションで「HANDOVER.md を読んで」と言うか、CLAUDE.md に一行入れておく必要がある。

例えば、セッション開始時に HANDOVER.md が存在すれば、最初に読み込むこと

この一行を CLAUDE.md に追記する運用。ここが抜けてると「作ったけど次のセッションで読まれない」ってなる人が出そう

CLAUDE .md との違い

ここが一番大事なポイント

- CLAUDE .md → プロジェクト全体のルール（不変）
- HANDOVER .md → 今日の作業の引き継ぎ（毎回更新）

この2つを分けるだけで、セッション跨ぎの精度が変わる。CLAUDE .md に作業ログを書き足していくと膨れ上がるし、ノイズになる。役割を分けるのが正解

そもそも、CLAUDE .md は100行以内に収めたい

試してみた結果

実際にセッション中に何回か /handover を打ってみた

- 毎回ちゃんと上書きされて、最新の状態だけが残る
- 「捨てた選択肢と理由」が地味に一番ありがたい。次のセッションで「それもう検討して却下した」って無駄な議論を防げる
- 「関連ファイル」も便利。セッションが変わると「どのファイル触ってたっけ」ってなりがちだけど、パス一覧があるだけで再開が速い

PreCompact hook で自動化する

ここからが応用編。リプで出てた「pre auto compact hook に仕込む」ってアイデアを実際に試した

Claude Code にはコンテキストウィンドウが溢れそうになったとき、自動で圧縮する仕組みがある。その直前に hook を発火させて HANDOVER .md を生成する

設定は .claude/settings.local.json に書く



スクリプトの例。よしなに作って試してください



/compact を手動で打ったら hook が発火して HANDOVER .md が自動生成された。トリガーが manual か auto かも記録される

注意点として、hook はセッション開始時に読み込まれるので、設定を変えたらセッションを再起動する必要がある

ファイル構成まとめ


]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Codeで、テックリードを作る]]></title>
            <link>http://izanami.dev/post/93c510f4-8669-46c6-a6e8-253171fcbe7d</link>
            <guid>http://izanami.dev/post/93c510f4-8669-46c6-a6e8-253171fcbe7d</guid><dc:creator>commte</dc:creator>
            <pubDate>Fri, 13 Feb 2026 14:14:06 GMT</pubDate>
            <description><![CDATA[Claude Code は使うたびにリセットされる。昨日直したバグも、先週の設計判断も、全部忘れる

人間のテックリードなら、プロジェクトの歴史を知っていて、過去の失敗を踏まえた判断ができる。タスクの]]></description>
            <content:encoded><![CDATA[Claude Code は使うたびにリセットされる。昨日直したバグも、先週の設計判断も、全部忘れる

人間のテックリードなら、プロジェクトの歴史を知っていて、過去の失敗を踏まえた判断ができる。タスクの優先順位を把握していて、チームの編成まで考えてくれる

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code の特殊な使い方 / AI 駆動開発 などを中心に情報を配信しています

Claude Code にも同じことをさせる方法がある。CLAUDE .md に7行書くだけ

仕組み

ファイルを記憶装置として使う

-  - Claude Code が最初に読む設定ファイル。ここに「何を読め」と書く
-  - タスク管理。何が終わっていて、何が残っているか
-  - 過去の失敗と学び。同じバグを二度踏まないためのログ

Claude Code はセッション開始時に CLAUDE .md を自動で読む。そこに「まず todo .md と lessons .md を読め」と書いておけば、毎回プロジェクトの現状を把握してから作業に入る

人間のテックリードが朝会でタスクボードを確認するのと同じ流れ

セットアップ

CLAUDE .md に追記する

tasks/todo.mdtasks/lessons.md[x]

こうしておけば、作業範囲が被らない

2つ目はトークン消費。チームメイトはそれぞれ独立したコンテキストウィンドウを持つ。3人編成にすると単純に3倍近くトークンを使う。速いけど高い。小さいタスクなら1人で十分。チーム編成は「並列でやる意味がある量」のときだけ使うのが現実的

テックリードに必要な3つの能力

テックリードの仕事を分解すると、3つに集約される

1. プロジェクトの歴史を知っていること → todo .md
2. 同じ失敗を繰り返さないこと → lessons .md
3. 適切にタスクを分配すること → チーム編成

この3つをファイルベースで実装するのがこの設定の本質。Claude Code を「毎回ゼロから始まる便利ツール」から「プロジェクトの文脈を持ったテックリード」に変える

使うほど lessons .md が育つ。それがプロジェクト固有の知識ベースになる。人間が抜けても残る、チームの記憶
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Checklist Driven Development（CCDD）]]></title>
            <link>http://izanami.dev/post/1dad3ac1-85a2-4656-94e9-5944023db546</link>
            <guid>http://izanami.dev/post/1dad3ac1-85a2-4656-94e9-5944023db546</guid><dc:creator>commte</dc:creator>
            <pubDate>Tue, 10 Feb 2026 17:37:59 GMT</pubDate>
            <description><![CDATA[Claude Code に  チェック入れさせる方法を使うと、ファイルを記憶装置として使うと開発効率上がる。こんなやつね



タイトルの Claude Checklist Driven Develo]]></description>
            <content:encoded><![CDATA[Claude Code に  チェック入れさせる方法を使うと、ファイルを記憶装置として使うと開発効率上がる。こんなやつね



タイトルの Claude Checklist Driven Development（CCDD）っていうのは、ワイが勝手に作った言葉

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Claude Code / AI 駆動開発 / Claude Code などを中心に情報を配信しています

ファイルを外部メモリにする

この記事は [Tech with Mak 氏の X 投稿](https://x.com/techNmak/status/2018712721538081170)にインスピレーションを受け、[Anthropic 公式ドキュメント](https://code.claude.com/docs)と複数の研究論文を引っ張り出して検証したもの

具体的には以下の 3 つのファイルを軸にする

-  - Claude Code の行動指針と記憶のインデックス
-  - 今やるべきことの計画と進捗管理
-  - 過去の失敗と学びの蓄積

この仕組みの強さは、セッションが切れても記憶が消えないこと。次のセッションで Claude Code が  を読み込んだ瞬間、前回の続きからスムーズに作業を再開できる。まるで優秀な同僚が引き継ぎノートを完璧に残してくれてるような感覚

思いついてた人もいるだろうけど、案外やってる人少なそう

:::info
NeurIPS 2023 で採択された「Reflexion」([2303.11366](https://arxiv.org/abs/2303.11366)) という論文がまさにこのアプローチの理論的裏付けになる。Reflexion は重み更新ではなく言語的フィードバックで強化学習を行うフレームワークで、エージェントがタスクのフィードバックを言語で振り返り、エピソディックメモリバッファに反省テキストを保持して次の試行での意思決定を改善する。やろうとしてるのは、まさにこの Reflexion のアプローチを Claude Code に適用すること
:::

Claude Code には [Auto Memory](https://code.claude.com/docs/en/memory) というビルトインのメモリシステムもあるが、それは後述する

CLAUDE.md

まずはじめに、CLAUDE.md にこれを書く

/tasks/todo.md/tasks/lessons.md

これだけ。Claude Code はセッション開始時に CLAUDE.md を自動で読み込むから、この指示によって必ず  と  を最初に確認するようになる。結果として、前回のセッションの続きからシームレスに作業できる

tasks ディレクトリを作る

コマンドでサクッと



ディレクトリ



tasks/todo.md による計画駆動開発

多くの開発者が Claude Code を使うとき、いきなりコードを書かせ始める。やけどそれだと Claude Code が途中で迷子になりやすい。特に複雑なタスクでは、全体の見通しがないまま部分的な実装を進めてしまい、あとで整合性が取れなくなることがある

 のワークフローはこの問題を根本から解決する



tasks/lessons.md で同じ失敗を繰り返さない

開発で一番もったいないのは、同じバグを何度も踏むこと。人間の開発者なら「あ、これ前にも見たやつや」と気づけるけど、セッションが切れるたびにリセットされる Claude Code にはその記憶がない

 がこの問題を解決する

npx prisma generateany.env.example

このファイルのポイントは、具体的な行動レベルまで落とし込むこと。「型に気をつける」みたいな曖昧な教訓やなくて、「Prisma のスキーマを変更したら必ず  を実行する」のように、Claude Code がそのまま実行できるルールにする

arxiv の「A Survey of Self-Evolving Agents」([2507.21046](https://arxiv.org/abs/2507.21046)) が整理した Plan-Execute-Reflect-Memorize ループそのもの。エージェントが計画し、実行し、結果を振り返り、学びをメモリに保存する。このサイクルを回し続けることで、エージェントはオンジョブで進化していく

Claude Code のビルトイン Auto Memory も活用する

ここまで  と  による手動メモリ管理を見てきたけど、Claude Code には [Auto Memory](https://code.claude.com/docs/en/memory) というビルトインのメモリシステムもある

公式によると、Auto Memory は CLAUDE.md とは根本的に違う。CLAUDE.md は「人間が Claude に向けて書く指示」やけど、Auto Memory は「Claude 自身がセッション中に見つけたパターンや知見を自分で書き留めるメモ帳」。保存先はユーザーのホームディレクトリ配下で、プロジェクトパスのハッシュごとに分かれてる



同じ Git リポジトリ内ならサブディレクトリが違っても 1 つの Auto Memory を共有する。Claude Code 2.1.32 で導入された機能で、セッション中に「Recalled 1 memory, wrote 1 memory」のように自動で読み書きしてくれる

ここで注意したいのは  の 200 行ルール。自動でシステムプロンプトに読み込まれるのは最初の 200 行だけ。やけどこれは Auto Memory 全体の容量制限やない。200 行を超える詳細な内容は  や  みたいなトピックファイルに分けて書いておけば、Claude が必要なときにオンデマンドで読みに行ってくれる。 はあくまでインデックスとして簡潔に保つのがコツ

Auto Memory が自動で記憶してくれる内容はこんな感じ

- プロジェクトパターン（ビルドコマンド、テスト規約、コードスタイル）
- デバッグ知見（トリッキーな問題の解決策、よくあるエラー原因）
- アーキテクチャメモ（重要ファイル、モジュール関係、抽象化）
- ユーザー設定（コミュニケーションスタイル、ワークフロー習慣）

自分から「pnpm を使うことを覚えておいて」「API テストにはローカルの Redis が必要なことをメモリに保存して」と直接指示もできるし、 コマンドでファイルセレクタを開いて直接編集もできる

:::info
Auto Memory はまだ段階的ロールアウト中。まだ見当たらない場合は  を環境変数にセットすれば強制的に有効にできる
:::

わざわざ  ディレクトリに書く理由

じゃあ Auto Memory があるのに、なんでわざわざ  ディレクトリで手動管理するのか

「プロジェクト内に作れるなら共有できるやん？」と思うかもしれないが、ここが紛らわしいポイント。Auto Memory の保存先は  なので、プロジェクトディレクトリ内やなくてユーザーのホームディレクトリ配下。つまり Git の管理外で、チームメンバーとは共有できない構造になってる

一方で  と  はプロジェクトルート直下に置くから、普通に Git で追跡できる。チーム全員の Claude Code が同じ教訓を共有できるし、新メンバーが  した瞬間にプロジェクトの知見が手に入る

もう一つの違いは、Auto Memory は Claude が「自分で判断して」書くもの。何を記憶するかの制御が人間側にない。一方で  ディレクトリは人間が意図的に構造化できる。「この教訓は絶対に忘れるな」「このタスクの順番で進めろ」みたいな強い指示は、手動メモリのほうが確実に伝わる

:::discovery
Auto Memory と手動メモリは排他的やなくて相互補完的。Auto Memory には Claude が自然に拾うプロジェクトの暗黙知を任せて、 ディレクトリには人間が明示的にコントロールしたい計画と教訓を入れる。この使い分けがベストプラクティス
:::

まとめ

Claude Code の生産性を劇的に上げるのに、特別なツールや複雑な設定は要らない。必要なのは 3 つのファイルと、それを中心にしたシンプルなワークフロー

-  で記憶のハブを作る
-  で計画を立ててから実装する
-  で失敗を記録して同じミスを繰り返さない

後は、このあたりも組み合わせるといいね

- Plan Mode で見通しを立ててから着手する
- サブエージェントでコンテキストを守る

ファイルを外部メモリとして使うというシンプルな仕組みが、Claude Code を経験から学び続けるパートナーに変える。セッションが切れても記憶は残るし、チームで共有もできる。そして使えば使うほど、lessons.md が育って、Claude Code の精度が上がっていく
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code の Agent teams を使うべき理由]]></title>
            <link>http://izanami.dev/post/8628a13f-8cff-47d0-a4fa-be8f2a4551c3</link>
            <guid>http://izanami.dev/post/8628a13f-8cff-47d0-a4fa-be8f2a4551c3</guid><dc:creator>commte</dc:creator>
            <pubDate>Sat, 07 Feb 2026 13:55:42 GMT</pubDate>
            <description><![CDATA[Claude Code の Agent teams を試して分かった決定的な違い

複数の Claude が同時に独立して考えて、しかもお互いに直接メッセージをやりとりできる

これが Claude ]]></description>
            <content:encoded><![CDATA[Claude Code の Agent teams を試して分かった決定的な違い

複数の Claude が同時に独立して考えて、しかもお互いに直接メッセージをやりとりできる

これが Claude Code の Agent teams なんやけど、2026 年 2 月上旬に実験的機能として公開され、Opus 4.6 の話題と同時期に注目を集めた機能で、使ってみたらサブエージェントとは全然別物やった

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/b6fce387-b87c-4a68-a2d6-5512ee6392fb.png)

レビューを依頼すると…

バグ調査で複数の仮説を同時に検証させたり、セキュリティ・パフォーマンス・テストの 3 軸で並列レビューさせたり、できることのレベルが一段上がる

コンテキストが汚染されないから、巨大な PR や長期調査でも文脈がぐちゃぐちゃになりにくいし、各チームメイトが独立した視点で考えるから仮説の競合が自然に起きるんよね

X で毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発 / Claude Code などを中心に情報を配信しています

参考リンク

この記事は [Anthropic 公式ドキュメントの Agent teams ガイド](https://code.claude.com/docs/en/agent-teams)と、[Lydia Hallie 氏の投稿](https://x.com/lydiahallie/status/2019469032844587505)（いいね 3,567 件、表示 80.4 万回）にインスピレーションを受けて、実際に試した結果をまとめたもの。[Addy Osmani 氏のブログ記事](https://addyosmani.com/blog/claude-code-agent-teams/)や [Anthropic の公式リリース記事](https://www.anthropic.com/news/claude-opus-4-6)も参照してる

Agent teams とは何か - なぜサブエージェントと違うのか

Agent teams は複数の Claude Code インスタンスが協調して動く仕組みなんやけど、既存のサブエージェントとは根本的に違う

[サブエージェント](https://code.claude.com/docs/en/sub-agents)は「調べて返す部下」やけど、Agent teams は「議論できるチーム」なんよね

具体的には、1 つのセッションがリード（team lead）として全体を統括して、残りのセッションがチームメイト（teammates）として独立して動く

各チームメイトは独自のコンテキストウィンドウを持つから、リードのコンテキストが汚染されることがない

そして決定的なのが、チームメイト同士が直接メッセージをやりとりできる点

サブエージェントはメインエージェントにしか結果を返せなかったけど、Agent teams ではチームメイトが互いに議論したり、意見を戦わせたりできる

これによって、複数の視点から同時に問題にアプローチできるようになった

サブエージェントと Agent teams の比較 - 使い分けの基準

両者の違いを明確にするために、[公式ドキュメントの比較表](https://code.claude.com/docs/en/agent-teamscompare-with-subagents)をベースに整理した

Subagents の特徴

| 項目               | 内容                                             |
| ------------------ | ------------------------------------------------ |
| コンテキスト       | 独自のコンテキストを持つが結果は呼び出し元に返る |
| コミュニケーション | メインエージェントにのみ結果を返す               |
| 作業調整           | メインエージェントが全作業を管理                 |
| 向いてる用途       | 結果だけ必要な集中タスク                         |
| トークンコスト     | 低い（結果がメインコンテキストに要約される）     |

Agent teams の特徴

| 項目               | 内容                                                 |
| ------------------ | ---------------------------------------------------- |
| コンテキスト       | 完全に独立したコンテキストウィンドウ                 |
| コミュニケーション | チームメイト同士が直接メッセージ可能                 |
| 作業調整           | 共有タスクリストで自己調整                           |
| 向いてる用途       | 議論と協調が必要な複雑な作業                         |
| トークンコスト     | 高い（各チームメイトが独立した Claude インスタンス） |

要するに、単純に並列処理したいだけならサブエージェントで十分

でも複数の視点から同時に考えさせて、その結果を議論させたいなら Agent teams を使うべき

例えばバグ調査で「メモリリークの可能性」「非同期処理のタイミング問題」「外部 API の仕様変更」という 3 つの仮説を同時に検証させて、チームメイト同士で議論させながら絞り込むような使い方ができる

アーキテクチャ - 4 つのコンポーネントで動く仕組み

Agent teams は 4 つのコンポーネントで構成されてる

| コンポーネント | 役割                                                           |
| -------------- | -------------------------------------------------------------- |
| Team lead      | メインセッション。チーム作成・チームメイト生成・作業調整を担当 |
| Teammates      | 独立した Claude Code インスタンス。割り当てられたタスクを実行  |
| Task list      | 共有タスクリスト。チームメイトがクレームして完了する           |
| Mailbox        | エージェント間通信システム。メッセージの配信を担当             |

実際のファイルとしては以下の場所に保存される

チーム設定は  に、タスクリストは  に配置される

この仕組みのおかげで、リードは全体の進捗を把握しつつ、各チームメイトは独立して作業できる

タスクリストは  →  →  の 3 段階で管理されて、チームメイトが自分でタスクをクレームして進めていく

タスク間には依存関係も設定できて、依存先が完了するまでブロックされる仕組みになってる。依存タスクが完了すると自動でアンブロックされるから、手動介入は不要

複数のチームメイトが同時にタスクをクレームしようとしても、ファイルロックで競合が防がれるようになってる

リードがいちいち指示しなくても、チームメイトが自律的に動くようになってるのがポイント

有効化方法 - 設定ファイル 1 行で使える

Agent teams は実験的機能やから、環境変数で有効化する必要がある

 に以下を追加するだけ



これだけで準備完了

あとは自然言語で「3 人のチームを作って」と指示すれば、自動的にチームが組まれる

ちなみに自分からチーム作成を頼まなくても、Claude が「このタスクはチームでやった方がいい」と判断したら提案してくれることもある。ただし勝手には作らず、必ず承認を求めてくるから安心

モデルも指定できて、例えば「Sonnet を使ってチームを作って」と言えば、全チームメイトが Sonnet になる

コスト削減したいときは明示的に Haiku を指定するのもあり

表示モードの選択 - tmux か iTerm2 があると捗る

Agent teams には 2 つの表示モードがある

in-process モード はメインターミナル内で全チームメイトが動く形式

 と  でチームメイトを巡回して、直接メッセージを送れる

split panes モード は各チームメイトが独自のペインを持つ形式

tmux か iTerm2 が必要やけど、全員の進捗が同時に見えるから視認性が段違い

公式は iTerm2 を使う場合  で起動するのを推奨してる。 CLI のインストールと、iTerm2 の Settings → General → Magic → Enable Python API の有効化も必要

設定は  で指定できる



CLI フラグで指定することも可能



デフォルトは  で、tmux セッション内なら split panes、そうでなければ in-process になる

:::warning
VS Code の統合ターミナル、Windows Terminal、Ghostty では split panes モードが動かない。これらの環境では in-process モードを使うか、外部ターミナルで tmux を起動する必要がある
:::

チームの作り方と操作方法 - 自然言語でほぼ完結

チームの作成は自然言語で指示するだけ

例えばこんな感じ



これだけで 3 人のチームメイトが生成されて、それぞれの視点でレビューが始まる

チームメイトの数やモデルも自由に指定できる

plan approval を有効にすると、チームメイトに計画承認を要求できる

これによって、勝手に実装が走るのを防げる。チームメイトは read-only の plan mode で作業して、計画ができたらリードに承認リクエストを送る

リードが承認すれば実装フェーズに進むし、却下すればフィードバック付きで差し戻される。リードの判断基準は「テストカバレッジを含む計画のみ承認して」とか「DB スキーマを変更する計画は却下して」みたいにプロンプトで指定できる

特にリスクの高い操作をする場合は、plan approval を使うのが安全

delegate mode は  で有効にできて、リードがコードを一切触らずに指揮だけに専念するモード

大規模な並列作業では、リードが実装に手を出さず全体を見渡す方がうまくいく

直接メッセージ は in-process モードなら  と  でチームメイトを選んで送信できる

 でチームメイトのセッションを直接表示して、 でそのターンに割り込みできる。 でタスクリストの表示/非表示を切り替えられる

split panes モードなら、チームメイトのペインをクリックするだけで直接操作できる

特定のチームメイトに追加指示を出したいときに使う

タスク管理 は共有タスクリストで行われる

リードがタスクを作成して、チームメイトが  状態のタスクをクレームして  にして、完了したら  にマークする

タスクのサイズは 5〜6 個 / チームメイトが目安

小さすぎるとオーバーヘッドが大きくなって、大きすぎるとチェックインなしに長時間作業することになる

シャットダウンとクリーンアップ はリードから指示する

:::warning
クリーンアップの順序はめっちゃ大事。先に全チームメイトをシャットダウンしてから「Clean up the team」を実行する。アクティブなチームメイトが残ってるとクリーンアップが失敗する。チームメイト側からクリーンアップを実行するのも NG で、コンテキストが正しく解決されずリソースが不整合な状態になる可能性がある
:::

シャットダウンはリードから「Ask the researcher teammate to shut down」のように指示する。チームメイトは承認してグレースフルに終了するか、理由を付けて拒否することもできる

シャットダウンが遅い場合があるけど、これはチームメイトが現在のリクエストやツール呼び出しを完了させてから終了するため

Hooks で品質ゲートを設ける - タスク完了前に自動レビュー

Agent teams では 2 つの [Hooks](https://code.claude.com/docs/en/hooks) が使える

TeammateIdle Hook はチームメイトがアイドルになりそうなときに発火する

exit code 2 を返すと、フィードバックを送信して作業を続行させられる

例えば「まだテストが足りない」「ドキュメントを書いてない」といったフィードバックを自動で返せる

TaskCompleted Hook はタスク完了時に発火する

exit code 2 を返すと、完了を阻止してフィードバックを送れる

例えば「テストカバレッジが 80% 未満だから完了させない」みたいなゲートを設けられる

Hooks を使うことで、チームメイトが勝手に終了するのを防いで、品質基準を満たすまで作業を続けさせることができる

設定例はこんな感じ



こうすることで、人間がチェックしなくても自動で品質を担保できる

実践ユースケース 1 - 並列コードレビューで抜け漏れを防ぐ

最も実用的なのが並列コードレビュー

1 人でレビューすると、セキュリティのことを考えてるときにパフォーマンスのことが見えなくなったり、テストカバレッジのことを考えてるときにアクセシビリティのことが抜けたりする

Agent teams を使えば、3 人のチームメイトにそれぞれ専門分野を担当させられる



実際に試したら、セキュリティ担当が「この API エンドポイントに認証チェックがない」と指摘して、パフォーマンス担当が「この SQL クエリが N+1 になってる」と指摘して、テスト担当が「この条件分岐のテストがない」と指摘した

3 つの視点が同時に動くから、抜け漏れが物理的に減る

しかもチームメイト同士が直接メッセージできるから、「この認証チェックを追加するとパフォーマンスに影響ある？」みたいな議論が自然に発生する

これはサブエージェントでは絶対にできなかった

実践ユースケース 2 - 競合仮説による科学的バグ調査

バグ調査で威力を発揮するのが、競合仮説アプローチ

例えば「アプリが 1 メッセージ後に終了する」という報告があったとき、考えられる仮説は複数ある



5 人のチームメイトがそれぞれ異なる仮説を検証して、お互いに議論しながら絞り込んでいく

「メモリリークの可能性」を検証する人、「非同期処理のタイミング問題」を検証する人、「外部 API の仕様変更」を検証する人、「WebSocket の切断」を検証する人、「例外処理の不備」を検証する人

チームメイト同士が「この仮説は再現しなかった」「この仮説は部分的に正しい」と議論して、最終的にコンセンサスが形成される

これは人間のチームが科学的にバグを追い詰めるプロセスと同じなんよね

1 人で全仮説を順番に検証するより、5 人が並列で検証して議論する方が圧倒的に早い

実践ユースケース 3 - CLI ツール設計を多角的に検討

設計段階でも Agent teams は有効

例えば新しい CLI ツールを設計するとき、UX・技術アーキテクチャ・悪魔の代弁者の 3 つの視点から検討させられる



UX 担当は「開発者が普段使ってるワークフローに溶け込むか」を考えて、技術アーキテクチャ担当は「スケールするか」「保守できるか」を考えて、悪魔の代弁者は「本当に必要か」「既存ツールで十分じゃないか」を問い詰める

3 つの視点が同時に動くことで、設計の穴が早期に見つかる

しかもチームメイト同士が議論するから、UX と技術のトレードオフとか、既存ツールとの差別化ポイントとかが自然に浮き彫りになる

[公式ドキュメントのベストプラクティス](https://code.claude.com/docs/en/agent-teamsstart-with-research-and-review)でも「まずはリサーチとレビューから始めろ」と推奨されてて、コードを書かないタスクで慣れるのが良い

ベストプラクティス - チームを効果的に動かすコツ

実際に使ってみて分かったベストプラクティスをまとめる

チームメイトに十分なコンテキストを与える のが最重要

spawn プロンプトに詳細を含めないと、チームメイトが何をすべきか分からなくて迷走する

「セキュリティ担当」だけじゃなくて「セキュリティ担当。特に認証・認可周りと SQL インジェクション・XSS のリスクをチェック」みたいに具体的に指示する

タスクサイズを適切に保つ のも大事

5〜6 タスク / チームメイトが目安で、これより小さいとオーバーヘッドが大きくなって、これより大きいとチェックインなしに長時間作業することになる

リードが勝手に実装し始めないように するのもポイント

リードは指揮に専念すべきで、実装はチームメイトに任せる

もしリードが実装し始めたら「Wait for your teammates」と指示すれば止まる

delegate mode（）を使えば、リードが自動的に指揮専念モードになる

まずはリサーチとレビューから始める のが公式推奨

いきなり並列実装をやるとファイル競合が発生しやすいし、調整コストが高い

並列レビュー、バグ調査、ライブラリ調査、設計検討あたりで慣れてから、並列実装に移行するのが安全

ファイル競合を避ける ために、各チームメイトが異なるファイルを担当するように分ける

同じファイルを複数人で触ると、後から保存した方が勝つから、片方の作業が消える

フロント担当・バック担当・テスト担当みたいに、ファイル単位で分けるのが確実

定期的に進捗確認・軌道修正 するのも忘れずに

完全放置はダメで、たまにチームメイトの進捗を見て「そっちじゃなくてこっちを優先して」みたいな指示を出す

split panes モードなら全員の進捗が同時に見えるから、これがやりやすい

トラブルシューティング - よくある問題と解決法

実際に使ってて遭遇した問題と解決法を並べる

チームメイトが表示されない ときは、 で巡回して探す

split panes モードなら  でセッション一覧を確認する

パーミッション確認が多すぎる ときは、[permission settings](https://code.claude.com/docs/en/permissions) で事前承認しておく

特に  を使うと、全チームメイトもスキップするようになる

ただしセキュリティリスクが上がるから、信頼できるタスクのみで使う

エラーで停止した チームメイトは自動復旧しないから、直接指示するか、新しいチームメイトに置き換える

 でエラーが出たチームメイトを選んで「このエラーを解決して」と指示すれば再開する

リードが早期終了する 問題もある

全タスク完了前に「終わった」と判断して終了することがあるんよね

その場合は「続けて」「まだタスクが残ってる」と指示すれば再開する

孤立 tmux セッション が残ることがある

 で確認して、不要なセッションは  で削除する

タスクステータスが遅延する ことがあって、チームメイトが完了したのにタスクリストが更新されないことがある

その場合はリードから「タスクリストを更新して」と指示すれば同期される

 や  で in-process チームメイトが復元されない のは既知の制限

セッションを再開すると、チームメイトが消えてる

split panes モードでも完全復元は保証されないが、in-process より状況把握はしやすい

長期作業の場合は定期的にチェックポイントを作っておく

制限事項 - 知っておくべき現時点の限界

Agent teams は実験的機能やから、[いくつか制限がある](https://code.claude.com/docs/en/agent-teamslimitations)

1 セッション 1 チームのみ で、複数のチームを同時に動かすことはできない

ネストチーム不可 で、チームメイトがさらにチームを作ることはできない

リードは固定 で、途中でリードを変更することはできない

パーミッションはスポーン時に設定 されて、リードの権限設定を引き継ぐ

スポーン後に個別変更は可能やけど、デフォルトではリードと同じ権限になる

スプリットペインは tmux or iTerm2 必須 で、VS Code の統合ターミナル、Windows Terminal、Ghostty では split panes モードが使えない

 と  で in-process チームメイトが復元されない から、セッション再開時は注意が必要

タスクステータスが遅延する ことがあって、リアルタイムで同期されないことがある

シャットダウンが遅い 場合があって、数秒から場合によっては 10 秒以上かかることがある

これらの制限を理解した上で使えば、十分実用的に動く

トークンコストとパーミッション - 運用で気をつける点

トークンコストはチームメイト数に比例して跳ね上がる

各チームメイトが独立した Claude インスタンスやから、3 人チームなら単純計算で 3 倍のトークンを消費する

ただし実際には、リードのコンテキストが汚染されないから、長期的には効率が良くなることもある

特に巨大な PR や長期調査では、コンテキストがぐちゃぐちゃになって何度もリセットするより、最初からチームで分担した方がトータルコストが低くなる

broadcast は全チームメイトにメッセージを送るから、コストが高い

特定のチームメイトにだけ伝えたいなら message を使う

パーミッションはリードの設定を引き継ぐから、リードで  を使うと、全チームメイトもスキップするようになる

セキュリティリスクが上がるから、信頼できるタスクのみで使う

スポーン後に個別のチームメイトだけパーミッションを変更することも可能やけど、基本的にはリードで事前に設定しておく方が安全

コンテキストと通信 - 各チームメイトが見えるもの

各チームメイトは独自のコンテキストウィンドウを持つ

[CLAUDE.md](https://code.claude.com/docs/en/memory)、[MCP サーバー](https://code.claude.com/docs/en/mcp)、[Skills](https://code.claude.com/docs/en/skills) はロードされるから、リードと同じ設定が使える

ただしリードの会話履歴は引き継がれない

だからチームメイトに十分なコンテキストを与えるには、spawn プロンプトに詳細を含める必要がある

メッセージは自動配信されて、チームメイトが何かを報告したらリードに届く

アイドル通知もあって、チームメイトが何もすることがなくなったらリードに通知が来る

message は 1 対 1 のメッセージで、特定のチームメイトにだけ送られる

broadcast は全チームメイトに送られるから、全員に共有したい情報を伝えるときに使う

ただし broadcast はコストが高いから、必要なときだけ使う

海外での実践事例 - 実際にどう使われてるか

海外の開発者コミュニティでも Agent teams は早速活用されてる

[Addy Osmani 氏のブログ](https://addyosmani.com/blog/claude-code-agent-teams/)によると、6 人の Claude チームで大規模なコードベースをレビューさせた結果、数時間で 13 件の即時修正可能な問題と 22 件の中長期課題を発見したとのこと

さらに極端な事例として、[Anthropic のエンジニアリングブログ](https://www.anthropic.com/engineering/building-c-compiler)では 16 エージェントが約 2,000 セッション、API コスト約 $20,000 をかけて Rust ベースの C コンパイラを一から構築し、10 万行のコードで Linux 6.9 をビルドできるレベルまで到達した事例が紹介されてる

これらの事例から分かるのは、Agent teams はレビューや調査のような「読み中心」のタスクでは即座に実用的やし、実装タスクでもファイル分担さえしっかりすれば大規模プロジェクトにも対応できるということ

ただし、トークンコストは確実に跳ね上がるから、費用対効果を見極めた上で使うのが大事

まとめ - Agent teams を使うべきタイミング

Agent teams は複数の視点から同時にアプローチしたいときに使う

並列コードレビュー、競合仮説によるバグ調査、多角的な設計検討あたりが特に相性良い

サブエージェントは結果だけ返してくれればいいタスク向けで、Agent teams は議論と協調が必要なタスク向け

トークンコストは高いけど、コンテキスト汚染を防げるから、長期的には効率が良くなることも多い

制限はあるけど、並列で探索する価値があるタスクには既に実用レベル

まずはリサーチとレビューから始めて、慣れてきたら並列実装にも使っていくのが良い

リードが指揮に専念して、チームメイトが自律的に動く形を作れれば、開発速度が段違いに上がる
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code スキル自作勢へ！Agent Skills Marketplace に6万超スキル集結]]></title>
            <link>http://izanami.dev/post/93b709b5-06ae-48a0-8489-9f1970c20756</link>
            <guid>http://izanami.dev/post/93b709b5-06ae-48a0-8489-9f1970c20756</guid><dc:creator>commte</dc:creator>
            <pubDate>Fri, 16 Jan 2026 15:19:07 GMT</pubDate>
            <description><![CDATA[Claude Code のスキル、自作する前にここをチェックしてほしい

X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI]]></description>
            <content:encoded><![CDATA[Claude Code のスキル、自作する前にここをチェックしてほしい

X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発 / Claude Code などを中心に情報を配信しています

この記事は [Agent Skills Marketplace](https://skillsmp.com) を実際に触ってみた感想と、なぜこれが Claude Code ユーザーにとって革命的なのかを解説する

なぜ今 Skills Marketplace が注目されてるのか

車輪の再発明をやめられるから

Claude Code を使い始めると、まず直面するのが「スキルってどう作ればいいの？」という壁よね

あ、スキルっていうのは、「こういう仕事をするときは、こう考えて、こう進める」という知識と手順をフォルダ単位で定義する感じやね

公式ドキュメント読んで、SKILL.md の書き方覚えて、試行錯誤しながら自分用のスキルを作っていく。これ自体は楽しいんやけど、実は先人たちがすでに大量のスキルを作って公開してくれてるんよ

[Agent Skills Marketplace](https://skillsmp.com) というサービスがあって、ここに 65,635 個以上のスキルが集約されてる。全部 GitHub のオープンソースで、SKILL.md 標準に準拠してるから、見つけたらすぐに使える

見てみると、我々が自分で作ったスキルよりいいものが揃ってる

それじゃあ、使わせてもらったほうがいいよね？

サードパーティってどうなん？って人もいるけど、

[Anthropic 公式ブログ](https://www.claude.com/blog/building-skills-for-claude-code)でも紹介されてて、LangChain の deepagent-CLI にも統合されてるレベルのサービスなんよね

スキル数の爆発的増加

サイトのトレンドグラフを見ると、2024 年 12 月末から急増してるのがわかる。1 ヶ月で倍以上に増えてて、これはマジでエコシステムが加速してる証拠

なぜこんなに増えてるかというと、Skills の仕組み自体がシンプルやからなんよね。Markdown ファイル 1 つ書くだけでスキルになる

MCP みたいにサーバー立てたりコード書いたりする必要がない。だから参入障壁がめっちゃ低い

カテゴリ別の内訳を見ていこう

Skills Marketplace では 10 個のメインカテゴリに分かれてて、それぞれにサブカテゴリがある。全部見ていくとボリュームあるけど、どこに何があるか把握しておくと探しやすくなるから解説していく

Tools カテゴリ（22,506 スキル）

一番多いのが Tools カテゴリ。開発者が日常的に使うツール系のスキルが集まってる

| サブカテゴリ               | スキル数 |
| -------------------------- | -------- |
| Productivity & Integration | 13,241   |
| Automation Tools           | 6,532    |
| Debugging                  | 4,338    |
| System Administration      | 2,613    |
| IDE Plugins                | 2,277    |
| CLI Tools                  | 552      |
| Domain & DNS Tools         | 136      |

Productivity & Integration が圧倒的に多い。これは Notion、Slack、Google Workspace などの連携スキルがここに入ってるから。自動化系も 6,000 以上あって、定型作業を Claude に任せたい人には宝の山やね

Debugging スキルが 4,338 もあるのは意外やった。エラーメッセージの解析とか、ログの読み方とか、そういう知識がスキルとして共有されてるんよね

Development カテゴリ（19,370 スキル）

開発関連のスキルがここに集約されてる

| サブカテゴリ           | スキル数 |
| ---------------------- | -------- |
| CMS & Platforms        | 7,181    |
| Architecture Patterns  | 5,136    |
| Full Stack             | 3,596    |
| Frontend               | 3,233    |
| Scripting              | 1,974    |
| Game Development       | 1,947    |
| Mobile                 | 1,578    |
| Backend                | 1,303    |
| Package & Distribution | 710      |
| E-commerce Development | 693      |
| Framework Internals    | 579      |

CMS & Platforms が 7,000 超えてるのは、WordPress、Shopify、Strapi などの各 CMS に特化したスキルがあるから。Architecture Patterns も 5,000 以上あって、設計パターンの知識をスキルとして取り込めるのは便利

Frontend と Backend が分かれてるのもいい。React、Vue、Next.js などのフレームワーク別にスキルがあるから、自分のスタックに合わせて選べる

Data & AI カテゴリ（12,997 スキル）

AI 関連のスキルがここ。Claude Code 使ってる人なら特に気になるカテゴリよね

| サブカテゴリ     | スキル数 |
| ---------------- | -------- |
| LLM & AI         | 10,293   |
| Data Analysis    | 1,752    |
| Data Engineering | 1,491    |
| Machine Learning | 1,122    |

LLM & AI が 10,000 超えしてるのはすごい。プロンプトエンジニアリングのベストプラクティスとか、各 LLM の特性を活かした使い方とか、そういう知識がスキルとして共有されてる

Data Analysis と Data Engineering も合わせて 3,000 以上あるから、データ処理のワークフローを強化したい人にはかなり使える

Business カテゴリ（11,543 スキル）

ビジネス系のスキルも結構充実してる

| サブカテゴリ         | スキル数 |
| -------------------- | -------- |
| Project Management   | 7,339    |
| Sales & Marketing    | 4,929    |
| Finance & Investment | 2,564    |
| Health & Fitness     | 2,018    |
| Business Apps        | 557      |
| Real Estate & Legal  | 504      |
| Payment              | 119      |
| E-commerce           | 85       |

Project Management が 7,000 以上あるのは、タスク管理やプロジェクト進行のベストプラクティスがスキルとして共有されてるから。Sales & Marketing も 5,000 近くあって、マーケティング施策のアイデア出しとかに使えそう

Health & Fitness が 2,000 あるのは意外やった。ビジネスカテゴリに入ってるのは、ウェルネス系のビジネス向けってことかな

DevOps カテゴリ（10,839 スキル）

インフラ・運用系のスキルがここ

| サブカテゴリ  | スキル数 |
| ------------- | -------- |
| CI/CD         | 6,015    |
| Git Workflows | 4,781    |
| Cloud         | 1,773    |
| Containers    | 1,186    |
| Monitoring    | 814      |

CI/CD が 6,000 以上あるのはありがたい。GitHub Actions、GitLab CI、CircleCI などの各サービス別にスキルがあるから、自分の環境に合わせて選べる

Git Workflows も 4,781 あって、ブランチ戦略とかコミットメッセージの書き方とか、チーム開発のベストプラクティスがスキルとして取り込める

Testing & Security カテゴリ（7,984 スキル）

テストとセキュリティ関連

| サブカテゴリ | スキル数 |
| ------------ | -------- |
| Testing      | 3,427    |
| Code Quality | 3,097    |
| Security     | 1,727    |

Testing と Code Quality で 6,500 以上。単体テストの書き方とか、コードレビューのポイントとか、品質を上げるための知識がスキルとして共有されてる

Security が 1,727 あるのもいい。OWASP Top 10 とか、セキュアコーディングのベストプラクティスとか、セキュリティの知識は常に最新化が必要やから、コミュニティで共有されてるのはありがたい

Documentation カテゴリ（5,672 スキル）

ドキュメント作成関連

| サブカテゴリ   | スキル数 |
| -------------- | -------- |
| Knowledge Base | 4,376    |
| Technical Docs | 1,733    |
| Education      | 1,650    |

Knowledge Base が 4,000 以上あるのは、社内 Wiki とか FAQ の作成スキルがここに入ってるから。Technical Docs も 1,733 あって、API ドキュメントとか README の書き方のベストプラクティスがスキルとして使える

Content & Media カテゴリ（5,591 スキル）

コンテンツ制作関連

| サブカテゴリ     | スキル数 |
| ---------------- | -------- |
| Content Creation | 2,925    |
| Documents        | 1,935    |
| Design           | 1,297    |
| Media            | 463      |

Content Creation が 2,925 あるから、ブログ記事とか SNS 投稿の作成に使えるスキルが豊富。Design も 1,297 あって、デザインシステムとかブランドガイドラインのスキルがある

Research カテゴリ（2,653 スキル）

研究・学術関連

| サブカテゴリ            | スキル数 |
| ----------------------- | -------- |
| Academic                | 1,543    |
| Scientific Computing    | 640      |
| Computational Chemistry | 601      |
| Bioinformatics          | 496      |
| Lab Tools               | 109      |
| Astronomy & Physics     | 97       |

研究者向けのスキルもあるんよね。Academic が 1,543 あって、論文の書き方とか文献レビューのベストプラクティスがスキルとして共有されてる

Bioinformatics とか Computational Chemistry みたいな専門分野のスキルもあるのは、コミュニティの多様性を感じる

Databases カテゴリ（1,543 スキル）

データベース関連のスキルが 1,543 個。SQL の書き方とか、各データベースの特性を活かしたクエリの最適化とか、そういう知識がスキルとして使える

Skills の仕組みを理解しよう

Skills Marketplace を使いこなすには、Skills 自体の仕組みを理解しておくと良い。ドキュメントページにわかりやすくまとまってるから、そこから抜粋して解説する

Token Efficiency（トークン効率）

Skills は lazy loading を採用してて、トークンとコストを節約できる仕組みになってる

- Claude は最初、スキルの名前と説明だけを見る
- 現在のタスクに関連する場合のみ、全コンテンツをロードする
- 使われないスキルは会話でトークンを消費しない

これがめっちゃ重要で、大量のスキルをインストールしても、必要なときだけロードされるから効率的なんよね

Domain Expertise（専門知識の注入）

Skills は専門知識を注入する複数のアプローチを提供してる

- Professional knowledge injection: ベストプラクティスを SKILL.md に直接記述
- Operational consistency: 毎回安定した品質を確保
- Reference docs: 必要なときにロードされる詳細ドキュメント（references/ に配置）
- Resource files: テンプレートやアセット（assets/ ディレクトリに配置）

これによって、単なる「指示」じゃなくて「専門家の知識」を Claude に取り込めるわけ

Skills と MCP の違いを整理しよう

ここが一番大事な部分かもしれない。Skills と MCP（Model Context Protocol）は根本的に違う問題を解決してる

Skills の特徴

- 知識共有: 経験、ベストプラクティス、ワークフローを共有
- シンプルな Markdown ファイル: 誰でも作成できる
- Progressive loading: トークン効率が良い
- サーバー不要: セットアップの手間がない
- クロスプラットフォーム: Web + Desktop + CLI で動作（ほとんどのスキル）

MCP の特徴

- 機能拡張: API、データベース、ツールへの接続
- コーディングとサーバー設定が必要: 技術的なハードルが高い
- 起動時に全ツール定義をロード: トークン消費が高い
- 外部統合に強力: 実際のシステムと連携できる
- 複雑なセットアップ: 導入コストが高い

:::discovery
Skills と MCP は補完関係にある。知識共有には Skills を使い、機能拡張には MCP を使う。両方を組み合わせると本当の力を発揮する
:::

実際の使い方

Skills Marketplace の使い方は簡単

AI セマンティクス検索で探す

トップページの検索バーに「やりたいこと」を入力するだけ。自然言語で検索できるから、キーワードを考える必要がない

例えば「React コンポーネントのテストを書きたい」と入力すると、関連するスキルがヒットする

カテゴリから探す

カテゴリページ（/categories）から探すのも効率的。自分の目的に合ったカテゴリを選んで、サブカテゴリを絞り込んでいく

全部で 65,000 以上あるから、最初はカテゴリから探す方が見つけやすいかもしれない

人気順でソート

stats ページで人気のスキルを確認できる。多くの人に使われてるスキルは品質が高い傾向にあるから、まずは人気のものから試してみるのもあり

スキルのインストール方法

見つけたスキルをインストールするには、GitHub リポジトリをクローンして、.claude/skills/ ディレクトリに配置するだけ



SKILL.md 標準に準拠してるから、どのスキルも同じ構造になってて扱いやすい

なぜ今 Skills Marketplace が重要なのか

ここまで読んで「へー、便利そうだな」と思ってくれたならうれしい。でも、なぜ「今」これが重要なのかをもう少し掘り下げたい

車輪の再発明を避ける

自分でスキルを一から作る前に、まずは既存のスキルを探すべき。65,000 以上あるから、大抵のユースケースはカバーされてる

見つかったスキルをベースに、自分用にカスタマイズする方が効率的やし、品質も高くなりやすい

公式からの推奨

Anthropic 公式がこのサービスを紹介してるという事実は大きい。信頼性の裏付けになるし、今後もサポートされていく可能性が高い

LangChain の deepagent-CLI にも統合されてるから、エコシステムとしての広がりも期待できる

自分でスキルを作る場合

もちろん、既存のスキルでカバーできないユースケースもある。そういうときは自分でスキルを作ることになる

サイトの UI/UX がめっちゃ開発者向け

Skills Marketplace のサイトデザインも特徴的なんよね。ターミナル風の UI になってて、開発者にとっては親しみやすい

トップページには  みたいなコード風の表示があったり、カテゴリページでは  みたいな見出しになってたりする。遊び心があっていい

検索バーは  というコマンド風のプロンプトになってて、ここにやりたいことを自然言語で入力すると AI が関連スキルを探してくれる

実際に触ってみて感じたこと

ワイが実際にサイトを触ってみて感じたことを正直に書いておく

良かった点

まず検索性が高い。65,000 以上あると探すの大変そうに思えるけど、カテゴリ分けがしっかりしてるから目的のスキルにたどり着きやすい。AI セマンティクス検索も精度が高くて、「こういうことしたい」という曖昧な入力でもちゃんと関連スキルが出てくる

全部 GitHub のオープンソースっていうのも安心感がある。スキルの中身を事前に確認できるし、何か問題があればイシューを立てたりプルリク送ったりできる。クローズドなマーケットプレイスだとこうはいかない

カテゴリの粒度もちょうどいい。大カテゴリが 10 個、サブカテゴリがそれぞれ 4〜11 個くらいで、多すぎず少なすぎず探しやすい

改善してほしい点

スキルの品質にばらつきがあるのは仕方ないけど、もう少しキュレーションがあると助かる。人気順でソートできるとはいえ、品質保証されたスキルをまとめたセクションとかあると初心者には優しいかも

あと日本語対応がまだないから、英語が苦手な人にはちょっとハードルが高い。スキル自体は英語で書かれてることが多いけど、サイトの UI は多言語対応してほしい気持ちはある

おすすめの使い方

ここからは実践的な使い方を紹介する

新しいフレームワークを学ぶとき

例えば React から Vue に乗り換えようとしてるとき、Vue のベストプラクティスを教えてくれるスキルをインストールしておくと、Claude がそのスキルを参照しながらコードを書いてくれる

フレームワークの公式ドキュメントを読むのも大事やけど、実践的なノウハウはスキルから得る方が早いことも多い

チーム開発の標準化

チームで Claude Code を使う場合、同じスキルセットを共有することで出力の一貫性が保たれる。コーディング規約とかコミットメッセージのルールとか、チームのスタンダードをスキルとして定義しておくと便利

Skills Marketplace から見つけたスキルをベースに、チーム独自のカスタマイズを加えるのもあり

専門外の領域に挑戦するとき

普段バックエンドをやってる人がフロントエンドに挑戦するとき、Frontend カテゴリのスキルを入れておくと心強い。逆もまた然り

専門家が作ったスキルを使うことで、その領域のベストプラクティスを自然と取り入れられる

今後の展望

Skills Marketplace は今後さらに成長していくと予想してる

まずスキル数が増え続けるのは確実。12 月末から急増してるトレンドを見ると、コミュニティの勢いは止まらない

Anthropic 公式が紹介してることからも、Skills エコシステム自体がサポートされ続ける可能性は高い。Claude Code のアップデートに合わせて、スキルの仕様も進化していくやろう

MCP との連携も興味深い。現時点では Skills と MCP は別々のものやけど、将来的には両者を組み合わせたワークフローがもっと洗練されていくかもしれない

まとめ

Agent Skills Marketplace は Claude Code ユーザーにとって必須のリソースになりつつある

- 65,635 個以上のオープンソーススキル
- SKILL.md 標準に準拠
- AI セマンティクス検索で探しやすい
- Anthropic 公式も紹介
- Skills と MCP は補完関係

スキルを自作する前に、まずはここをチェックしてみてほしい。先人たちの知恵を借りることで、Claude Code の活用が一気に加速するはず

リンク: [Agent Skills Marketplace](https://skillsmp.com)

参考リンク

- [Agent Skills Marketplace](https://skillsmp.com)
- [Agent Skills Open Specification](https://skillsmp.com/docs)
- [Claude Platform Documentation - Agent Skills Overview](https://docs.anthropic.com/en/docs/claude-code/skills)
- [Equipping agents for the real world - Anthropic Blog](https://www.anthropic.com/news/equipping-agents-for-the-real-world)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Codeの CLAUDE.md、Rules、Skills、Subagents、MCPs使い分け]]></title>
            <link>http://izanami.dev/post/47deb6b9-0965-41e7-b128-12f5937e8748</link>
            <guid>http://izanami.dev/post/47deb6b9-0965-41e7-b128-12f5937e8748</guid><dc:creator>commte</dc:creator>
            <pubDate>Wed, 14 Jan 2026 13:36:34 GMT</pubDate>
            <description><![CDATA[最初にポイントをざっくり書く

CLAUDE .md、Rules、Skills、Subagents、MCPs 。5 つのレイヤーの使い分けの感覚はこれだけ覚えればいい

- どういう思想で働いてほしい]]></description>
            <content:encoded><![CDATA[最初にポイントをざっくり書く

CLAUDE .md、Rules、Skills、Subagents、MCPs 。5 つのレイヤーの使い分けの感覚はこれだけ覚えればいい

- どういう思想で働いてほしいかは CLAUDE .md
- この領域では絶対に守る知識は Rules
- 人（自動もあり）が開始する作業手順は Skills
- 自動で任せたい重い作業は Subagents
- 外部世界と触るなら MCP

Claude Code は「全部ルールを書くほど賢くなる」わけではない
レイヤーを間違えると、むしろ指示を無視し始める

X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発 / Claude Code などを中心に情報を配信しています

この記事は [Mario Ottmann 氏の Claude Code Customization Guide](https://marioottmann.com/articles/claude-code-customization-guide) にインスピレーションを受け、[Anthropic 公式ドキュメント](https://code.claude.com/docs)と論文も引っ張り出して検証したもの

よくある失敗

あるある過ぎて…

- CLAUDE .md に全部詰め込む
- ワークフロー指示を Rules に書く
- レイヤーの役割を理解せず混ぜる

ポイント

段階的に構築すること

1. まず CLAUDE .md で地図を作る
2. 次に Rules で専門知識を固める
3. 繰り返し作業は Skills に切り出す
4. 重くなったら Subagents に任せる
5. 外部と繋ぐ必要が出たら MCPs を使う
6. トリガー発動は、スラッシュコマンド

わからなくなったら

- CLAUDE .md はプロジェクトの地図
- Rules は専門知識
- Skills は繰り返し作業
- Subagents は複雑な自動化
- MCPs は外部ツール連携

コムテは？

ワイ？これで SaaS を１週間くらいで作るよ

1. スラッシュコマンドを多用
2. CLAUDE .md は簡潔に 200 行以内
3. ドメイン知識は Rules
4. MCP は、少なめに
5. Skills は、多くても２つくらい
6. Subagents は必須でない。必要なプロジェクトで

それじゃあ、解説始めるよー

Claude Code のカスタマイズ、CLAUDE .md だけで頑張ってない?

Claude Code を使い始めると、まず CLAUDE .md にあれこれ書き込みたくなるよね

プロジェクトのルール、コーディング規約、よく使うコマンド、全部ここに書いておけば Claude が賢くなるはずやと

やけど、ここで多くの開発者がハマる罠がある。CLAUDE .md に全部詰め込むと、むしろ Claude は指示を無視し始めるんよね

300 行を超えたあたりから、書いたはずのルールを平気でスルーするようになる

これは Claude Code のアーキテクチャを理解していないと起こる問題で、実は Claude Code には 5 つのカスタマイズレイヤーがあって、それぞれに明確な役割がある

このレイヤーを正しく使い分けることで、Claude は「何度言っても覚えない AI」から「プロジェクトを深く理解した相棒」に変わる

arxiv で公開されている研究 [A Systematic Survey of Prompt Engineering in Large Language Models](https://arxiv.org/abs/2402.07927) でも指摘されているけど、プロンプトエンジニアリングにおいて重要なのは「適切な粒度での指示の分離」なんよ。一つの巨大なプロンプトより、役割ごとに分離された複数の指示の方が、LLM はより正確に従う傾向がある

5 つのレイヤーの全体像

まず、Claude Code のカスタマイズは「内部レイヤー」と「外部レイヤー」に分かれる

内部レイヤーは Claude の「脳」を構成する 4 つの要素で、Claude がどう考え、何を知っていて、どう働くかを決める

| レイヤー   | トリガー             | 用途                         |
| ---------- | -------------------- | ---------------------------- |
| CLAUDE .md | 常に読み込み         | プロジェクトの地図、基本設定 |
| Rules      | パスベースまたは常に | ドメイン固有の深い知識       |
| Skills     | ユーザーが起動       | 繰り返しワークフロー         |
| Subagents  | Claude が自動起動    | 複雑な自動タスク             |

外部レイヤーは MCPs で、Claude の「手」として外部ツールに接続する役割を持つ

| レイヤー | トリガー     | 用途                   |
| -------- | ------------ | ---------------------- |
| MCPs     | ツール利用時 | 外部ツールへのアクセス |

この構造を理解すると、使い分けの感覚は実はめっちゃシンプルになる

使い分けの感覚はこれだけ覚えればいい

迷ったときは、この 5 つの問いを順番に考えてみて

- どういう思想で働いてほしいかは CLAUDE .md
- この領域では絶対に守る知識は Rules
- 人が開始する作業手順は Skills
- 自動で任せたい重い作業は Subagents
- 外部世界と触るなら MCPs

arxiv の研究 [RePrompt: Planning by Automatic Prompt Engineering for Large Language Models Agents](https://arxiv.org/abs/2406.11132) では、LLM エージェントの性能は「適切なレイヤーでの指示の配置」に大きく依存することが示されている。中間フィードバックを活用した段階的な最適化が、タスク完了率を大幅に向上させるんよね

CLAUDE .md とは何か

CLAUDE .md は Claude Code の「マスター設定」で、セッションが始まるたびに必ず読み込まれる。公式ドキュメントでは「Memory」とも呼ばれていて、プロジェクト全体に適用される前提知識を置く場所や

配置できる場所は 4 つあって、優先度順に並べるとこうなる

| 種類       | 場所                 | 共有範囲   |
| ---------- | -------------------- | ---------- |
| Enterprise | システムディレクトリ | 組織全体   |
| Project    | ./CLAUDE .md         | チーム全員 |
| User       | /.claude/CLAUDE .md | 自分のみ   |
| Local      | ./CLAUDE.local.md    | 自分のみ   |

Project レベルの CLAUDE .md はリポジトリにコミットして、チームで共有する。User レベルは個人の好みを全プロジェクトに適用する。Local は git にコミットしたくない個人設定を置く場所や

CLAUDE .md に書くべきもの

CLAUDE .md はプロジェクトの「地図」であり「従業員ハンドブック」のようなもの。新入社員が初日に読む資料をイメージすると分かりやすい

具体的には

- フレームワーク規約（Next.js 14 App Router を使う、など）
- コード品質基準（DRY 原則、テストの書き方）
- アクセシビリティ要件
- CI/CD の期待値
- 利用可能な Skills、Rules、Subagents のインデックス

公式ドキュメントによると、CLAUDE .md は 300 行以下が目安。これを超えると Claude がすべてを正確に把握できなくなる傾向がある

CLAUDE .md に書かないべきもの

逆に、CLAUDE .md に書くべきでないものもある

- 深いドメイン知識（Rules に分離）
- ステップバイステップのワークフロー（Skills に分離）
- 特定ファイルパターンにのみ適用されるルール（Rules に分離）

よくある失敗は、CLAUDE .md に設計規約、セキュリティポリシー、データベースパターン、コーディングスタイル、全部を 1 ファイルに詰め込んでしまうこと。そうすると Claude はコンテキストの重要度を判断できなくなって、結果的に指示を無視し始める

CLAUDE .md の実践例

実際のプロジェクトで使われている CLAUDE .md の構造はこんな感じや

/api-design/form-builderauth-patterns.mdapi-client.md

ポイントは「参照先へのリンク」として機能させること。詳細は Rules や Skills に任せて、CLAUDE .md は全体の地図に徹する

CLAUDE .md の import 機能

CLAUDE .md には他のファイルを import する機能がある。 構文を使う



相対パスと絶対パスの両方が使える。特に便利なのは、チームメンバーごとに個別の設定ファイルを読み込ませること



これは CLAUDE.local.md の代替として機能して、複数の git worktree で作業する場合に特に便利や

Rules とは何か

Rules は  ディレクトリに配置する markdown ファイルで、ドメイン固有の深い知識を格納する場所や。CLAUDE .md との決定的な違いは「パスベースのフィルタリング」ができること

Rules のディレクトリ構造



 内のすべての  ファイルは自動的にプロジェクトメモリとして読み込まれる

パスベースのフィルタリング

Rules の真価は「特定のファイルを編集しているときだけ読み込まれる」ことにある。YAML フロントマターで  を指定する



この rule は、データベース関連のファイルを編集しているときだけ Claude のコンテキストに読み込まれる。CSS を編集しているときには読み込まれないから、コンテキストの無駄遣いを防げる

glob パターンの例

| パターン            | マッチするもの                         |
| ------------------- | -------------------------------------- |
|            | 任意ディレクトリの TypeScript ファイル |
|           | src ディレクトリ以下のすべて           |
|               | プロジェクトルートの markdown          |
|  | src 以下の .ts と .tsx                 |

Rules に書くべきもの

Rules は「専門部門のドキュメント」のようなもの。CLAUDE .md が全社共通のハンドブックなら、Rules は各部門の詳細マニュアルや

- フロントエンド
- セキュリティ要件（コード例付き）
- データベースパターン（RLS ポリシー、クエリ最適化）
- フレームワーク固有の詳細（Tailwind v4 のユーティリティマッピング）

Rules の実践例 - フロントエンド

type Props = {}React.FC

このような rule があると、Claude は自動的に HTML をサニタイズし、埋め込み追加時に CSP ヘッダーを更新するようになる

CLAUDE .md と Rules の使い分け

| CLAUDE .md               | Rules                        |
| ------------------------ | ---------------------------- |
| 常に読み込まれる         | パスフィルタ可能             |
| プロジェクト全体の基準   | ドメイン固有の深い知識       |
| クイックリファレンス形式 | 詳細なドキュメント           |
| 単一ファイル             | 複数のフォーカスしたファイル |
| 「ここでの働き方」       | 「X を具体的にどうやるか」   |

研究 [Architecting Resilient LLM Agents](https://arxiv.org/pdf/2509.08646) では、行動を起こす前に完全なステップバイステップの計画を生成することで、推論の質とタスク完了率が向上することが示されている。これは Claude Code の Rules が提供する「コンテキストに応じた詳細な指示」の有効性を裏付けている

Skills とは何か

Skills はスラッシュコマンドとして展開される「繰り返し可能なワークフロー」を定義するもの。公式ドキュメントでは「Agent Skills」と呼ばれていて、Claude が特定のタスクを実行する方法を教える markdown ファイルや

重要なのは、Skills は「モデルが起動する」という点。ユーザーのリクエストが Skill の説明にマッチすると、Claude は自動的にその Skill を適用する

Skills のディレクトリ構造

Skills は 2 つの場所に配置できる

| 場所                | スコープ                         |
| ------------------- | -------------------------------- |
|  | 個人用、全プロジェクトで利用可能 |
|    | プロジェクト用、チームで共有     |

各 Skill はディレクトリで、その中に  と追加のサポートファイルを含む



SKILL .md の構造

SKILL .md は YAML メタデータと Markdown 指示で構成される



 フィールドが特に重要で、Claude はこれを見て「いつこの Skill を使うべきか」を判断する

利用可能なメタデータフィールド

| フィールド     | 必須   | 説明                                        |
| -------------- | ------ | ------------------------------------------- |
| name           | はい   | スキル名（小文字、ハイフン、最大 64 文字）  |
| description    | はい   | 用途と使用タイミング（最大 1024 文字）      |
| allowed-tools  | いいえ | 許可するツール                              |
| model          | いいえ | 使用するモデル                              |
| context        | いいえ |  でサブエージェントコンテキストで実行 |
| hooks          | いいえ | ライフサイクルフック                        |
| user-invocable | いいえ | スラッシュコマンドメニューに表示するか      |

Skills に書くべきもの

Skills は「ユーザーの起動が必要で、実行中にユーザー入力が必要になる可能性があるマルチステップワークフロー」に最適

- アーキテクチャ決定（ユーザー確認が必要）
- コンテンツ生成ワークフロー
- 法的/コンプライアンスページ生成
- デプロイチェックリスト
- コードレビューワークフロー

Skills の実践例 - バックエンドアーキテクチャ



 と入力すると、Claude はこの決定ツリーに沿って一緒に考えてくれる

Skills と Rules の違い

Skills と Rules は似ているように見えるけど、根本的に異なる

| Skills               | Rules                    |
| -------------------- | ------------------------ |
| ユーザーがトリガー   | パスベースで自動読み込み |
| ワークフロー指向     | 知識/コンテキスト指向    |
|   |          |
| マルチステップの手順 | ドメイン固有のルール     |

「Supabase を使うときのルール」は Rules に書く。「どの DB 技術を使うか決める手順」は Skills に書く

Subagents とは何か

Subagents は「専門的な AI アシスタント」で、複雑なマルチステップタスクを自律的に処理する。各 Subagent は独自のコンテキストウィンドウ、カスタムシステムプロンプト、特定のツールアクセス、独立した権限を持つ

Skills との決定的な違いは、Subagents は「Claude が自動的に起動する」こと。タスクが Subagent の説明にマッチすると、Claude はそこに委譲する

ビルトイン Subagents

Claude Code には 3 つのビルトイン Subagent がある

| Subagent        | モデル             | 用途                                 |
| --------------- | ------------------ | ------------------------------------ |
| Explore         | Haiku（高速）      | 読み取り専用のコードベース検索・分析 |
| Plan            | Sonnet             | 実装計画のためのリサーチ             |
| general-purpose | 会話のモデルを継承 | 探索と変更の両方が必要な複雑タスク   |

カスタム Subagents

本当の力はカスタム Subagent を定義することで発揮される。設定で定義しておくと、タスクが説明にマッチしたときに自動的に起動する



これを設定しておくと、「ログイン機能を実装した」と言ったあとに Claude が自動的にセキュリティ監査を実行する

Subagents のディレクトリ構造

| 場所                | スコープ                         |
| ------------------- | -------------------------------- |
|  | 個人用、全プロジェクトで利用可能 |
|    | プロジェクト用、チームで共有     |

Subagents のフロントマター



| フィールド     | 説明                                                   |
| -------------- | ------------------------------------------------------ |
| name           | 一意の識別子                                           |
| description    | いつ委譲するかの説明                                   |
| tools          | 使用可能なツール                                       |
| model          | sonnet, opus, haiku, inherit                           |
| permissionMode | default, acceptEdits, dontAsk, bypassPermissions, plan |
| skills         | 読み込む Skills                                        |
| hooks          | ライフサイクルフック                                   |

Skills と Subagents の使い分け

| Skills                 | Subagents                  |
| ---------------------- | -------------------------- |
| 現在の会話に知識を追加 | 独立したコンテキストで実行 |
| ユーザーが起動         | Claude が自動起動          |
| ガイダンスと標準向け   | 複雑な自律タスク向け       |

「PR レビューのやり方」を教えるなら Skills。「大規模なセキュリティ監査を自動実行」なら Subagents

研究 [Prompt Injection Defense Patterns for LLM Agents](https://arxiv.org/pdf/2506.08837) では、「plan-then-execute」パターンがプロンプトインジェクション攻撃を緩和することが示されている。Subagents はまさにこのパターンを実現していて、信頼できないデータを処理する前に計画を定義し、許可されたツール呼び出しのみを実行する

Subagents の実践例 - コードレビュアー



フォアグラウンドとバックグラウンド実行

Subagents はフォアグラウンド（ブロッキング）またはバックグラウンド（並行）で実行できる

フォアグラウンドは完了するまでメイン会話をブロックする。権限プロンプトや質問はユーザーに渡される

MCPs とは何か

MCPs (Model Context Protocol) は Claude Code を外部ツールやデータソースに接続するオープンソース標準。内部レイヤー 4 つが「Claude の脳」を構成するなら、MCPs は「Claude の手」として外部世界とインタラクトする

GitHub、Slack、データベースなど、コードベース外の何かに触る必要があるなら MCPs の出番や

MCPs でできること

MCPs を接続すると、Claude Code に

- イシュートラッカーから機能を実装: 「JIRA issue ENG-4521 の機能を追加して GitHub に PR を作成」
- モニタリングデータを分析: 「Sentry と Statsig で ENG-4521 機能の使用状況を確認」
- データベースをクエリ: 「PostgreSQL から ENG-4521 機能を使った 10 人のランダムユーザーのメールを取得」
- デザインを統合: 「Slack に投稿された新しい Figma デザインに基づいてメールテンプレートを更新」
- ワークフローを自動化: 「この 10 人のユーザーにフィードバックセッションへの招待メールのドラフトを Gmail で作成」

MCP サーバーの管理



MCP インストールスコープ

| スコープ | 場所                                 | 共有範囲                       |
| -------- | ------------------------------------ | ------------------------------ |
| local    | /.claude.json（プロジェクトパス下） | 自分のみ（現在のプロジェクト） |
| project  | .mcp.json                            | チーム（git コミット）         |
| user     | /.claude.json                       | 自分のみ（全プロジェクト）     |

MCP の実践例 - Sentry でエラー監視



よくある失敗パターン

ここまで各レイヤーを見てきたけど、失敗パターンも押さえておこう

失敗 1: CLAUDE .md に全部詰め込む

CLAUDE .md はクイックリファレンスであって、500 行のドキュメントではない。深いドメイン知識は Rules に分離すべき

失敗 2: ワークフローを Rules に書く

Rules はコンテキストであって、指示ではない。「常に DOMPurify を使う」は rule。「リーガルページを生成するときは X、Y、Z をする」は skill や

失敗 3: パスベースフィルタリングを使わない

データベースルールを CSS 編集時に読み込むのはコンテキストの無駄。paths フロントマターで関連ファイル編集時のみ読み込む

失敗 4: 自律タスクに Skills を使う

実行中にユーザー入力が不要なタスクは、Subagent として Claude が自動起動すべき。Skills はユーザー起動が必要なワークフロー向け

失敗 5: 外部統合を bash コマンドでハックする

外部アクセスを bash コマンドでやろうとするのは脆弱。MCPs が適切なツールインターフェースを提供する

失敗 6: CLAUDE .md をスキップする

CLAUDE .md なしでは、毎セッション同じことを繰り返し説明することになる。「Next.js 14 App Router を使ってることを忘れないで...」

決定フレームワーク - どのレイヤーを使う?

迷ったときは、この質問を順番に聞いてみて

1. プロジェクト全体の基準またはクイックリファレンス?
   → CLAUDE .md（フレームワーク規約、コード品質基準、アクセシビリティ、skills/rules のインデックス）

2. 深いドメイン知識?
   → Rules（デザインシステム、セキュリティ、データベースパターン、RLS ポリシー）

3. トリガーする繰り返しワークフロー?
   → Skills（アーキテクチャ決定、コンテンツ生成、リーガルページ、デプロイチェックリスト）

4. 複雑な自律タスク?
   → Subagents（セキュリティ監査、コードベース探索、大規模リファクタリング、コンテンツ変換）

5. 外部ツールアクセスが必要?
   → MCPs（GitHub、データベース、Slack、CI/CD パイプライン）

実践的な組み合わせ例

フロントエンド開発スタック

- CLAUDE .md: Next.js 規約、React パターン、アクセシビリティ基準
- Rules: design-system.md、tailwind-v4.md
- Skills: /landing-page-builder
- Subagents: Explore（ビルトイン）
- MCPs: 通常不要

バックエンド開発スタック

- CLAUDE .md: Next.js 規約、コード品質、テスト要件
- Rules: database-supabase.md（パスフィルタ）、security.md
- Skills: /backend-architecture
- Subagents: Plan（ビルトイン）、security-auditor（カスタム）
- MCPs: Postgres、GitHub

コンテンツ作成スタック

- CLAUDE .md: コード品質、アクセシビリティ（生成ページ向け）
- Rules: design-system.md（一貫したフォーマット向け）
- Skills: /legal-pages
- Subagents: linkedin-to-mdx-blog（カスタム）
- MCPs: 通常不要

段階的な構築アプローチ

5 つのレイヤーすべてを一度に使う必要はない。段階的に構築していくのがベストプラクティス

ステップ 1: CLAUDE .md で地図を作る

まずはフレームワーク規約、コード品質基準、追加予定のもののインデックスから始める。これが基盤になる



ステップ 2: Rules でドメイン知識を固める

 にデザインシステムとセキュリティ要件を作成。特定コンテキストでのみ重要なルールにはパスフィルタリングを使う

ステップ 3: 繰り返し作業を Skills に切り出す

週に 2-3 回やるワークフローを特定して、 に SKILL.md と追加サポートファイルを含むディレクトリを作成

ステップ 4: 重い作業は Subagents に任せる

作業していて「Claude が自動的に専門エージェントを使えたら便利なのに」と思ったら、カスタム Subagent を設定する

ステップ 5: 外部連携が必要になったら MCPs を追加

外部ツールアクセスが必要になったら、適切な MCP サーバーを設定する

まとめ

Claude Code のカスタマイズは 5 つのレイヤーで構成される

内部レイヤー（Claude の設定）

- CLAUDE .md - プロジェクト全体の基準とクイックリファレンスインデックスを持つマスター設定
- Rules - オプションのパスベースフィルタリングを持つ深いドメイン知識
- Skills - 繰り返しマルチステッププロセスのためのユーザートリガーワークフロー
- Subagents - 必要に応じて Claude が起動する複雑タスク用の自律スペシャリスト

外部レイヤー（外部への橋渡し）

- MCPs - GitHub、データベース、Slack などの外部ツールへの接続

目標は 5 つのレイヤーすべてをどこでも使うことではない。適切な仕事に適切なレイヤーを使うことや

研究 [Agent Security Bench](https://arxiv.org/pdf/2410.02644v3)（ICLR 2025）でも指摘されているように、効果的なシステムプロンプトを書くには専門知識が必要で、それをレイヤー構造で整理することがセキュリティと効率性の両方に寄与する

この使い分けができたとき、Claude Code は本当の力を発揮する

参考リンク

- [Claude Code 公式ドキュメント - Settings](https://code.claude.com/docs/en/settings)
- [Claude Code 公式ドキュメント - Skills](https://code.claude.com/docs/en/skills)
- [Claude Code 公式ドキュメント - Subagents](https://code.claude.com/docs/en/subagents)
- [Claude Code 公式ドキュメント - MCP](https://code.claude.com/docs/en/mcp)
- [Claude Code 公式ドキュメント - Memory](https://code.claude.com/docs/en/memory)
- [元記事: Claude Code Customization Guide](https://marioottmann.com/articles/claude-code-customization-guide)
- [arxiv: A Systematic Survey of Prompt Engineering in LLMs](https://arxiv.org/abs/2402.07927)
- [arxiv: RePrompt: Automatic Prompt Engineering for LLM Agents](https://arxiv.org/abs/2406.11132)
- [arxiv: Architecting Resilient LLM Agents](https://arxiv.org/pdf/2509.08646)
- [arxiv: Prompt Injection Defense Patterns](https://arxiv.org/pdf/2506.08837)
- [arxiv: Agent Security Bench (ICLR 2025)](https://arxiv.org/pdf/2410.02644v3)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[CLAUDE.md や AGENTS.md のベストプラクティスな書き方]]></title>
            <link>http://izanami.dev/post/47b08b5a-6e1c-4fb0-8342-06b8e627450a</link>
            <guid>http://izanami.dev/post/47b08b5a-6e1c-4fb0-8342-06b8e627450a</guid><dc:creator>commte</dc:creator>
            <pubDate>Tue, 13 Jan 2026 23:16:29 GMT</pubDate>
            <description><![CDATA[Claude Code を使っていて、なんか思い通りに動かんなって感じたことない？指示を書いてるはずなのに無視される、毎回同じことを説明し直さなあかん、コードスタイルがバラバラになる

こういう問題の]]></description>
            <content:encoded><![CDATA[Claude Code を使っていて、なんか思い通りに動かんなって感じたことない？指示を書いてるはずなのに無視される、毎回同じことを説明し直さなあかん、コードスタイルがバラバラになる

こういう問題の多くは、実は CLAUDE .md の書き方に原因があったりするんよね

X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発などを中心に情報を配信しています

この記事は HumanLayer のブログ記事「[Writing a good CLAUDE .md](https://www.humanlayer.dev/blog/writing-a-good-claude-md)」をベースに、Anthropic の公式ドキュメントと最新の学術研究を加えて、効果的な CLAUDE .md の書き方を徹底解説していく

CLAUDE .md、Rules、Skills、Subagents、MCPs 。5 つのレイヤーの使い分けについては以下のページで解説しました

https://izanami.dev/post/47deb6b9-0965-41e7-b128-12f5937e8748

５つの原則

Claude Code の CLAUDE .md や AGENTS .md で使えるベストプラクティス

- WHY、WHAT、HOW を定義
- 命令は少なく
- 段階的開示
- リンターをさせるな
- 自動生成は避ける

これがどれほど重要かピンときてない君！

これ、どんな AI コーディングエージェントでも何年でも使える汎用的なコツだよ？

WHY、WHAT、HOW を定義

まず、この３つを必ず書く

WHAT

テックスタック、プロジェクト構造、コードベースの全体像
Claude が最初に迷子にならないための地図を書く

WHY

プロジェクトの目的、各ディレクトリやコンポーネントの役割
なぜこの構成になっているのかを理解させる

HOW

作業の進め方そのものではなく、どうやって正解を検証できるか
テスト、型チェック、ビルドなど、変更の是非を判断する手段を示す

これについては、後述するね

少ないほど良い、を徹底する

- 理想は 300 行未満。HumanLayer の実例は 60 行未満
- 情報を詰め込みすぎると、重要な指示ほど無視されやすくなる

これは好みの問題ではなく、仕様の問題でもある

正直、この記事の方法でいけば SaaS レベルのプロダクトでも 100 行くらいで収まるよ？

それ以上書いちゃう人は、「もうちょっと抽象的に考えろ」ってことやね

CLAUDE .md には「この情報はタスクと無関係かもしれない」という前提付きで渡されるから、汎用性の低い指示が多いと、まとめて relevance なし判定されやすい

それでも収まらないって？

その対処法も後述する

LLM はステートレスという大前提を理解する

まず最初に押さえておきたいのが、LLM の根本的な性質。LLM は状態を持たない関数なんよね

重みは推論時点で凍結されてるから、使ってるうちに学習していくなんてことはない。つまり、セッションごとに完全にリセットされるってこと

HumanLayer のブログでは、この点について明確に述べられてる

LLM がコードベースについて知ってることは、こちらが渡したトークンだけ。Claude Code のようなコーディングエージェントは、明示的にメモリを管理する必要がある。そして CLAUDE .md は、デフォルトでエージェントとのすべての会話に含まれる唯一のファイルなんよね

これには 3 つの重要な意味がある

- コーディングエージェントは各セッションの開始時点でコードベースについて何も知らない
- エージェントには毎回、コードベースについて重要なことを伝える必要がある
- CLAUDE .md がそのための推奨方法

ここをちゃんと理解してないと、CLAUDE .md の設計がブレてしまうんよね

WHY / WHAT / HOW の 3 要素

CLAUDE .md に書くべき内容は、大きく分けて 3 つある。これは HumanLayer のブログでも強調されてるポイント

WHAT（何があるか）

技術スタック、プロジェクト構造、コードベースの全体像を伝える部分。Claude が最初に迷子にならないための地図を書くイメージ

特にモノレポでは重要で、各アプリケーションは何か、共有パッケージは何か、それぞれが何のためにあるのかを明示する。Claude がどこを見れば何があるかを把握できるようにするんよね

例えば、こんな感じで書く

apps/web/apps/api/packages/ui/packages/db/packages/domain/bun run buildbun run testbun run typecheckbun run lint

そして CLAUDE .md には、これらのファイルのリストと各ファイルの簡単な説明を含め、Claude に作業を始める前にどれが関連するか（もしあれば）を判断して読むように指示する

重要なのは「コピーよりポインタを優先する」こと。これらのファイルにコードスニペットを含めないほうがいい。すぐに古くなるから。代わりに、 参照を使って Claude を権威あるコンテキストに向ける

概念的には、これは Claude Skills の意図する動作に非常に似てるけど、スキルは指示よりもツールの使用に焦点を当ててる

Context Engineering という新しいパラダイム

2025 年に入って、「プロンプトエンジニアリング」を超えた「Context Engineering」という概念が注目されてる。arxiv の最新サーベイ論文「A Survey of Context Engineering for Large Language Models」（[arxiv.org/abs/2507.13334](https://arxiv.org/abs/2507.13334)）は、166 ページ、1411 件の引用を含む包括的な研究

この論文によると、LLM が単純な指示に従うシステムから複雑な多面的アプリケーションの中核となる推論エンジンへと進化するにつれて、やり取りの方法も進化する必要がある。「プロンプトエンジニアリング」という用語は基礎的やけど、もはや現代の AI システムが必要とする情報ペイロードの設計、管理、最適化の全範囲を捉えるには不十分

Context Engineering は単純なプロンプト設計を超えて、LLM のための情報ペイロードの体系的な最適化を包括する正式な分野として導入されてる。この論文では、基礎コンポーネント（コンテキスト検索と生成、コンテキスト処理、コンテキスト管理）と、それらを統合するシステム実装（RAG、メモリシステム、ツール統合推論、マルチエージェントシステム）を分析してる

Agentic Context Engineering の登場

さらに最新の研究として、「Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models」（[arxiv.org/abs/2510.04618](https://arxiv.org/abs/2510.04618)）がある

この研究では、ACE（Agentic Context Engineering）というフレームワークを提案してる。コンテキストを「evolving playbooks」（進化するプレイブック）として扱い、生成、リフレクション、キュレーションのモジュラープロセスを通じて戦略を蓄積、洗練、整理する

従来のアプローチには 2 つの問題があった

- brevity bias（簡潔さバイアス）: ドメインの洞察を捨てて簡潔な要約を好む傾向
- context collapse（コンテキスト崩壊）: 繰り返しの書き換えで時間とともに詳細が失われる

ACE はこれらの問題に対処し、エージェントとドメイン固有のベンチマークで +10.6%（エージェント）、+8.6%（金融）の改善を達成してる

この研究は CLAUDE .md の設計にも示唆を与える。静的な指示ファイルではなく、使用を通じて進化していく「プレイブック」としてコンテキストを考えるアプローチが効果的ってこと

Claude はリンターじゃない

CLAUDE .md に入れがちなものの筆頭が、コードスタイルガイドライン。やけど、これは絶対にやめたほうがいい

リンターの仕事を LLM にさせるな

LLM は従来のリンターやフォーマッターに比べて高価で遅い。決定論的なツールを使えるときは常にそっちを使うべき。コードスタイルガイドラインは必然的にたくさんの指示とほとんど無関係なコードスニペットをコンテキストウィンドウに追加し、LLM のパフォーマンスと指示への従い方を低下させ、コンテキストウィンドウを食いつぶす

LLM はコンテキスト内学習者。コードが特定のスタイルガイドラインやパターンに従ってるなら、コードベースのいくつかの検索（または良いリサーチドキュメント）があれば、エージェントは言われなくても既存のコードパターンや規約に従う傾向があるはず

どうしてもやりたいなら、Claude Code の Stop Hook を設定して、フォーマッターとリンターを実行し、エラーを Claude に提示して修正させることを検討してもいい。Claude 自身にフォーマットの問題を見つけさせるな。ボーナスとして、問題を自動修正できるリンター（Biome がおすすめ）を使い、何が安全に自動修正できるかのルールを慎重に調整して、最大の（安全な）カバレッジを得る

コードガイドラインを含み、バージョン管理の変更、または git status などに Claude を向けるスラッシュコマンドを作成することもできる。こうすれば、実装とフォーマットを別々に処理できて、結果として両方でより良い結果が得られる

/init や自動生成を使わない

Claude Code や OpenCode を使った他のハーネスには、CLAUDE .md（または AGENTS.md）を自動生成する方法がある。やけど、これは避けるべき

/init は、余計な情報書いちゃう。もったいない

CLAUDE .md は Claude Code とのすべてのセッションに入るから、ハーネスの最もレバレッジの高いポイントの 1 つ

良くも悪くも、使い方次第で悪いコード 1 行は悪いコード 1 行。悪い実装計画 1 行は、たくさんの悪いコードを生む可能性がある。システムの動作を誤解したリサーチの悪い 1 行は、計画にたくさんの悪い行を生み、結果としてさらに多くの悪いコードを生む可能性がある

やけど CLAUDE .md は、ワークフローのすべてのフェーズとそれによって生成されるすべての成果物に影響する。だから、そこに入るすべての行について非常に慎重に考える時間を取るべき

公式ドキュメントの階層構造

Anthropic の公式ドキュメントによると、Claude Code は 4 つのメモリロケーションを階層構造で提供してる

| メモリタイプ                   | 場所                                                        |
| ------------------------------ | ----------------------------------------------------------- |
| エンタープライズポリシー       | macOS:  |
| プロジェクトメモリ             |  または                 |
| プロジェクトルール             |                                       |
| ユーザーメモリ                 |                                       |
| プロジェクトメモリ（ローカル） |                                          |

階層の上位にあるファイルが優先され、最初に読み込まれる。より具体的なメモリがその上に構築される基盤を提供するってこと。 ファイルは自動的に  に追加されるから、バージョン管理にチェックインすべきでないプライベートなプロジェクト固有の設定に最適

CLAUDE .md のインポート機能

CLAUDE .md ファイルは  構文を使って追加ファイルをインポートできる



相対パスと絶対パスの両方が使える。特に、ユーザーのホームディレクトリのファイルをインポートすることで、リポジトリにチェックインされない個人の指示をチームメンバーが提供できる便利な方法になる

インポートは複数の git worktree でうまく動作する  の代替手段でもある



衝突を避けるため、インポートは Markdown のコードスパンやコードブロック内では評価されない。インポートされたファイルは追加ファイルを再帰的にインポートでき、最大深度は 5 ホップ

モジュラールール（.claude/rules/）の活用

大きなプロジェクトでは、 ディレクトリを使って指示を複数のファイルに整理できる。これにより、チームは 1 つの大きな CLAUDE .md の代わりに、焦点を絞った整理されたルールファイルを維持できる

基本構造



 内のすべての  ファイルは、 と同じ優先度でプロジェクトメモリとして自動的に読み込まれる

パス固有のルール

ルールは YAML フロントマターの  フィールドを使って特定のファイルにスコープできる。これらの条件付きルールは、Claude が指定されたパターンに一致するファイルを操作してるときだけ適用される



 フィールドのないルールは無条件に読み込まれ、すべてのファイルに適用される

glob パターン

 フィールドは標準的な glob パターンをサポートしてる

| パターン               | マッチするもの                                   |
| ---------------------- | ------------------------------------------------ |
|               | 任意のディレクトリのすべての TypeScript ファイル |
|              | src/ ディレクトリ下のすべてのファイル            |
|                  | プロジェクトルートの Markdown ファイル           |
|  | 特定のディレクトリの React コンポーネント        |

複数のパターンを指定することもできる



ブレース展開もサポートされてる



サブディレクトリでの整理

ルールはより良い構造のためにサブディレクトリに整理できる



すべての  ファイルは再帰的に検出される

シンボリックリンク

 ディレクトリはシンボリックリンクをサポートしてて、複数のプロジェクト間で共通のルールを共有できる



.claude/rules/ のベストプラクティス

- ルールは焦点を絞る: 各ファイルは 1 つのトピックをカバーする（例: 、）
- 説明的なファイル名を使う: ファイル名でルールの内容がわかるようにする
- 条件付きルールは控えめに: ルールが本当に特定のファイルタイプに適用される場合のみ paths フロントマターを追加する
- サブディレクトリで整理: 関連するルールをグループ化する（例: 、）

メモリのベストプラクティス

公式ドキュメントでは、以下のベストプラクティスが推奨されてる

- 具体的に書く: 「コードを適切にフォーマットする」より「2 スペースインデントを使用する」のほうがいい
- 構造を使って整理: 各メモリを箇条書きとしてフォーマットし、関連するメモリを説明的な Markdown 見出しの下にグループ化する
- 定期的にレビュー: プロジェクトの進化に合わせてメモリを更新し、Claude が常に最新の情報とコンテキストを使用するようにする

こんなのでいいんだよ CLAUDE .md

ここまでの知見を踏まえて、「こんなのでいいんだよ」的な CLAUDE .md の例を示す

src/app/src/components/src/lib/src/hooks/bun run devbun run buildbun run testbun run lint

この例は約 30 行。WHY/WHAT/HOW が簡潔にまとまってて、詳細は別ファイルへのポインタで参照してる

Claude が無視しにくい CLAUDE .md の書き方

先述の通り、Claude Code は CLAUDE .md の内容を「タスクに関係ない」と判断すると無視する。この挙動を踏まえて、無視されにくい CLAUDE .md を書くコツを整理しよう

普遍的に適用できる情報だけを書く

「データベースマイグレーションの手順」みたいな特定タスクの情報は CLAUDE .md に書かない。そういう情報は  のような別ファイルに分離して、必要なときだけ読ませる

CLAUDE .md には「このプロジェクトは bun を使う」「テストは vitest」みたいな、どんなタスクでも関係する情報だけを書く

指示ではなく事実を書く

「必ず〜してください」「〜は禁止です」みたいな指示形式より、「このプロジェクトでは〜を使ってる」「〜という設計方針がある」みたいな事実形式のほうが無視されにくい

指示が多すぎると、Claude は全体を「うるさいノイズ」として処理してしまう傾向がある

構造化して読みやすくする

箇条書き、見出し、テーブルを使って情報を構造化する。長い文章の塊は読み飛ばされやすい

bun run devbun run buildbun run test

こういう形式なら、Claude は必要な情報をすぐに見つけられる

LLM の注意力に関する研究知見

プロンプトエンジニアリングの研究では、LLM の「注意力」についていくつかの重要な知見が得られてる

先述の通り、LLM は指示がプロンプトの周辺部（最初と最後）にあるものに偏る傾向がある。これは「Lost in the Middle」問題として知られてて、長いコンテキストの中間部分にある情報は見落とされやすい

CLAUDE .md の設計でこれを活かすなら

- 最も重要な情報（プロジェクト概要、主要コマンド）をファイルの最初に置く
- 補足的な情報は後ろに回す
- 中間に長い説明を入れない

また、指示の数が増えると全体の従い方が均一に低下するという研究結果も重要。指示を 10 個から 20 個に増やすと、1 番目の指示も 20 番目の指示も同じように無視されやすくなる。だから「重要な指示だけを残す」んじゃなくて「指示の総数を減らす」ことが大事

AGENTS.md との関係

Claude Code 以外のツール（Cursor、Zed、Codex など）では、CLAUDE .md の代わりに AGENTS.md を使うことが多い。基本的な考え方は同じで、ここで解説したベストプラクティスはそのまま適用できる

ただし、ツールによって AGENTS.md の読み込み方や優先度が異なる場合があるから、使ってるツールのドキュメントも確認しておくとよい

トラブルシューティング

Claude が指示を無視する

- CLAUDE .md が長すぎないか確認（300 行以下が目安）
- 普遍的でない指示が混ざってないか確認
- 指示の総数を減らす
- 重要な情報をファイルの最初に移動

Claude が古い情報を使う

- CLAUDE .md 内のコードスニペットが古くなってないか確認
- コードスニペットを  参照に置き換える
-  コマンドで読み込まれてるファイルを確認

チームメンバー間で挙動が違う

- （個人設定）の内容を確認
-  の内容を確認
-  内のファイルを確認

まとめ

CLAUDE .md を効果的に書くためのポイントをおさらいしよう

1. LLM はステートレス: 毎回「初見」でコードベースを見るという前提を忘れない

2. WHY/WHAT/HOW を定義: プロジェクトの目的、構造、作業方法を簡潔に伝える

3. 指示は少なく: 研究によるとフロンティア LLM でも 150〜200 の指示が限界。Claude Code のシステムプロンプトで約 50 を使ってるから、残りは限られてる

4. 300 行未満を目指す: HumanLayer の実例は 60 行未満。情報を詰め込みすぎると、重要な指示ほど無視されやすくなる

5. 段階的開示: タスク固有の情報は  などに分離し、CLAUDE .md には参照ポイントだけを置く

6. コピーよりポインタ: コードスニペットではなく  で一次情報を指す

7. リンターの仕事をさせない: コードスタイルは Biome などの自動ツールに任せる

8. 自動生成を避ける:  は使わず、手動で慎重に作る。最重要ファイルだから

9. 定期的に見直す: プロジェクトの進化に合わせて更新する

CLAUDE .md が効く理由は、LLM が毎回「初見」でコードを見るから。重要なのは指示を書くことではなく、常に読む価値がある情報だけを残すこと。関係ない指示が増えるほど、全部まとめて無視されやすくなる

だから WHY/WHAT/HOW だけを最小単位で渡し、詳細は別ファイルに逃がす。これはプロンプトではなくコンテキスト設計の話なんよね

参考リンク

- [Writing a good CLAUDE .md | HumanLayer Blog](https://www.humanlayer.dev/blog/writing-a-good-claude-md)
- [Manage Claude's memory - Claude Code Docs](https://code.claude.com/docs/en/memory)
- [The Prompt Report: A Systematic Survey of Prompt Engineering Techniques](https://arxiv.org/abs/2406.06608)
- [A Survey of Context Engineering for Large Language Models](https://arxiv.org/abs/2507.13334)
- [Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models](https://arxiv.org/abs/2510.04618)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Xでフォロワーを増やすアルゴリズムの理解]]></title>
            <link>http://izanami.dev/post/19bec620-2e39-4849-87ae-308b539e0ea3</link>
            <guid>http://izanami.dev/post/19bec620-2e39-4849-87ae-308b539e0ea3</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 12 Jan 2026 17:51:51 GMT</pubDate>
            <description><![CDATA[X で、あなたの嫌いな人が役立つ情報をポストしてたとする

その人をバズらせたくない理由で、いいねせずに、ブックマークだけしたとする。実は、バズに超貢献してるぞ 笑

X のブックマークはアルゴリズム]]></description>
            <content:encoded><![CDATA[X で、あなたの嫌いな人が役立つ情報をポストしてたとする

その人をバズらせたくない理由で、いいねせずに、ブックマークだけしたとする。実は、バズに超貢献してるぞ 笑

X のブックマークはアルゴリズム的に最強級のポジティブシグナルなんだわ。 Grok や解析勢の 2025〜2026 年分析によると

> ・いいね：ベースライン（軽め）
> ・ブックマーク：10x〜15x 相当（保存意欲＝高価値コンテンツ証明）
> ・300 ブックマーク超えでインプレッション 60%ブーストみたいな体感報告多数

ワイのポストも大体いいねよりブックマークが多いけど、軒並み後からじわじわ伸びまくってるから間違いないと思ってる

アルゴは「ユーザーの嫉妬」より 「よい投稿を世に出す」 を優先してるってこと

まぁ、考えたら当たり前の話よね（皮肉）

次に、メインポストに直リンクつけるペナルティについて話そう

X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発 / X ハック情報などを中心に情報を配信しています

X のリンクペナルティ

まずはこれを見て欲しい

https://x.com/commte/status/2010307920110772397

ワイは最近、X でちょっとした実験をやってみた。ほぼ同じ内容の投稿を 2 つ、ほぼ同時刻に出したんよね

- リンク付き
- 引用リポスト形式

内容的にはリンク付きのほうが分かりやすかったはずやけど、結果は予想以上に極端やった

:::discovery
1 時間後のインプレッションを見たら、引用リポストのほうが約 8 倍も多かった。同じ内容、同じタイミング、違うのはリンクの配置だけ
:::

Network and Distributed System Security Symposium（NDSS）で発表された研究とも一致してた

https://arxiv.org/abs/2410.17390

でもこれ、24 時間後にはちょっと変わってきて、差が約 2.8 倍まで縮まったんよね。リンク付きのほうが後から追い上げてきた感じ

![24 時間後](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/83bdd0b4-16ed-493f-8ced-0ce0d6948c45.png)

24 時間後

結論から言うと、X のアルゴリズムは「ユーザーを外に出さない」ことを最優先にしてる。これは体感だけやなくて、実際に学術研究でも裏付けられてる事実なんよ

X アルゴリズム 2026 年 1 月最新トレンド

後は、Grok こんな感じのこと言ってた

- ブックマークは「後で読みたい」最強シグナル → 質重視コンテンツで爆増
- 非 Premium はリンク直貼りほぼアウト → 2026 年 3 月以降、実質ゼロエンゲ報告多数。Premium 必須レベルになってきてる
- 画像 URL はペナルティほぼなし → ネイティブ画像/動画多め + リンクという組み合わせが新しい回避戦術
- 初動 50% ルール → 投稿後 1 時間のエンゲが命。作者リプライを 30 分以内に高品質連投（質問・補足）で会話量爆上げが最強ブースト
- チーズバーガー戦術は継続最強 → リンクなし軸 → 引用で補足リンクが安定王道
- セルフ引用で初動 1.5〜3 倍、24h 後さらに伸び

チーズバーガー戦術については後述する

リンクペナルティ無効化

ほんでこれが今回のキモやな

アカウント信頼度（TweepCred/過去の蓄積）を高めるとリンク付きの初動抑制が緩くなる

- 長時間読まれている
- 外部リンク先で離脱率が低い
- 戻ってくるユーザーが多い

TweepCred（ツィープクレド）っていうのは、X（旧 Twitter）の隠れたアカウント信頼スコア・評判スコア（Reputation Score）のこと

これが、おそらく例外処理に書かれている

2026 年現在もアルゴリズムの根幹に残ってる感があるよね

分かったこと

- 初動はリンクなしが有利
- 時間が経つとリンク付きも徐々に For You に乗る
- リンクペナルティ無効化で猛追

TweepCred（アカウント信頼度）

リンクペナルティ無効化の鍵となる TweepCred について、もう少し詳しく解説しておく

TweepCred は Google の PageRank アルゴリズムをベースにしてて

「誰からフォローされているか」

が大きく影響する。質の高い相互フォローや、影響力のある人からのフォローがあると有利になる

:::info
ちなみに、ワイはフォローされたうえで引用リポストされたら、高確率でフォロー返して、RT も返すときがある。ある程度内容があれば
:::

つまり、君も伸ばしたかったら、ワイをフォローして引用 RT したらええんや（暴論）

話を戻す

Grok 君に聞いたスコアの範囲と閾値はこんな感じ

| スコア   | 状態                                             |
| -------- | ------------------------------------------------ |
| -128     | 新規アカウントのスタート値                       |
| +17 以上 | フィードに表示され始める閾値                     |
| 65 未満  | 投稿のランキング対象が最大 3 件に制限            |
| 65 以上  | 全投稿が評価対象（スレッドや連投もフル活用可能） |
| 100      | 理論上の最大値                                   |

65 未満だと投稿のランキング対象が最大 3 件に制限されるってのが重要。これが「シャドウ ban っぽい」現象の主犯格なんよね。いくら良い投稿しても、スコアが低いと評価すらされない

ワイがフォロワー数 2000 くらいのときに、１個もいいねがつかなかったのは、スコアが低かったのだろうな

TweepCred を高める要因

- 高品質エンゲージメント（ブックマーク、引用、長時間滞在）→ 最強シグナル
- 長期間の良質投稿と一貫性 → 蓄積型なので急に上げるのは難しい
- Premium 加入 → ベース値が有利になる
- 戻り率が高い → 爆上がりする

TweepCred を下げる要因

- フォロー/フォロワー比率の悪さ → FF 比 2:1 以上でペナルティ（フォロー爆撃は致命的）
- ネガティブシグナル
- 外部リンクの多用
- 全大文字や攻撃的な言葉

特に「戻り率が高いと爆上がり」ってのがリンクペナルティ無効化と直結してる。外部リンクに飛んだユーザーが戻ってきてエンゲージメントしてくれると、TweepCred が上がって、リンク付き投稿でもペナルティが緩和されるという好循環が生まれる

学術研究が明らかにした X アルゴリズムの実態

この「リンクペナルティ」は単なる都市伝説やないぞ

2026 年の Network and Distributed System Security Symposium（NDSS）で発表された研究「[Revealing The Secret Power: How Algorithms Can Influence Content Visibility on Twitter/X](https://arxiv.org/abs/2410.17390)」が、これを科学的に証明してる

この研究チームは、4000 万件以上のツイートと 900 万人以上のユーザーのデータを分析したんよね。対象はウクライナ・ロシア紛争と 2024 年米大統領選挙に関する投稿。めっちゃ大規模な調査やね

研究の主要な発見はこれ。X のアルゴリズムは外部リンクを含むツイートの視認性を、最大 8 倍まで低下させてる。しかもこれ、リンク先の信頼性やイデオロギー的立場に関係なく発生するんよ

つまり、権威あるニュースサイトへのリンクでも、個人ブログへのリンクでも、同じようにペナルティを受ける

具体的な数値も出てて、視認性スコアの比較はこんな感じ

| コンテンツタイプ   | 視認性スコア中央値 |
| ------------------ | ------------------ |
| リンクなし         | 0.246              |
| ニュースリンク付き | 0.033              |

約 7.5 倍の差がある

ワイの実験結果とほぼ一致してるやん！

この研究が示唆してることは深刻で、X は情報源の信頼性に関係なく、すべての外部リンクに対してペナルティを適用してる。つまり、質の高いジャーナリズムも、フェイクニュースサイトも、アルゴリズム的には同じ扱いを受けてるってこと

なぜ X はユーザーを外に出したくないのか

ここでソーシャルメディアのビジネスモデルを考えてみよっか

X の収益源は主に広告収入。ユーザーがプラットフォーム上に長く滞在するほど、表示できる広告の数が増える。外部リンクをクリックしてユーザーが離脱すると、その分だけ広告収益機会を失うことになる

[Engagement, User Satisfaction, and the Amplification of Divisive Content on Social Media](https://arxiv.org/abs/2305.16941) によると、ソーシャルメディアプラットフォームは主にエンゲージメントシグナル（クリック数、滞在時間、コメント数など）を使ってフィード順位を決定してる

時系列順のフィードと比較して、エンゲージメントベースのフィードはユーザーリテンションを向上させることが分かってるんよ

つまり、アルゴリズムの目的は「ユーザーをできるだけ長くプラットフォーム上に留めること」。外部リンクはその目的に反するから、ペナルティを受けるのは当然の帰結やね

2022 年にイーロン・マスクが Twitter を買収して X にリブランドしたとき、最初期のアルゴリズム優先事項の一つが「ユーザーをプラットフォーム上に留めること」やった

外部リンクを含む投稿は静かにランクダウンされるようになって、ジャーナリストやライターにとっては地殻変動レベルの変化やった

ただし、2025 年 10 月頃から X はこの方針を見直し始めてるらしい。製品責任者の Nikita Bier が、iOS でリンク体験を改善するテストを行ってると発表してる。リンク付き投稿をより見やすく、エンゲージしやすくする機能らしい。まだテスト段階やけど、将来的にはリンクペナルティが緩和される可能性もあるね

リンクペナルティの具体的な影響度

現在のリンクペナルティは、一般的に 30〜50% のインプレッション減少と言われてる。ただし、これはアカウントの状態や投稿内容によってかなり変動する

ワイの実験では初動 1 時間で 8 倍の差が出たけど、24 時間後には 2.8 倍まで縮まった。これが意味するのは、リンクペナルティには「時間経過による緩和」があるってこと。初動では大きくペナルティを受けるけど、一定のエンゲージメントが蓄積されると、For You タイムラインへの推薦が再開される傾向がある

[Revealing The Secret Power: How Algorithms Can Influence Content Visibility on Twitter/X](https://arxiv.org/html/2410.17390v4) によると、X は特定のアカウントをフラグ付けして問題ありと判断した場合に視認性を制限するけど、外部リンクに関しては「すべてのコンテンツ」が対象になってる。共有される情報の信頼性に関係なく、外部リンクがあるだけでペナルティが発生する

これって考えてみるとめっちゃ雑な実装よね。信頼できるソースへのリンクも、怪しいサイトへのリンクも、同じように扱われるんやから。でも、アルゴリズム的にはリンク先の質を判断するのは難しいから、一律でペナルティを適用するのが最も簡単な実装なんやろな

実験の詳細と再現方法

ワイがやった実験の詳細を共有しておくね。再現したい人の参考になれば

まず投稿内容について。両方のポストで伝えたい情報は完全に同一。文章量もほぼ同じ。違いはリンクの配置だけ。リンク付きポストはメイン投稿にリンクを直接埋め込んだ形式。引用リポストのほうは、まずリンクなしで価値だけを伝えるメイン投稿を出して、それを自分で引用リポストしてリンクを補足した

投稿時刻は数分しか差がない状態で出した。これが重要で、時間帯によってインプレッションの伸び方が全然違うから、できるだけ同条件にしたかったんよね。両方とも夜のゴールデンタイム（20 時頃）に投稿

結果の計測方法としては、1 時間後と 24 時間後にインプレッション数をスクショして記録した。アナリティクスのダッシュボードから直接数字を取得してるから、正確な値

この実験で面白かったのが、内容的にはリンク付きのほうが分かりやすいと思ってたこと。リンク先の情報がすぐに見られるから、ユーザー体験としては良いはず。でもアルゴリズム的には逆評価になる。これがプラットフォームのビジネスロジックとユーザー体験のズレを如実に示してるよね

もう一つ注目すべき点として、フォロワー数やアカウントの影響力によって結果が変わる可能性がある。ワイのアカウントは Premium 認証済みで、ある程度のエンゲージメント履歴がある状態。新規アカウントや非 Premium だと、もっと極端な差が出るかもしれないし、逆にペナルティが緩和されるパターンもあるかもしれない

この実験は n=1 なので、統計的に有意かどうかは言えない。でも、学術研究の結果（最大 8 倍の差）とほぼ一致してるってのは、かなり信頼性を高めてくれる要素やと思う

引用リポストが強い理由

じゃあなんで引用リポストだと初動が爆発的に伸びるのか。これにはいくつかの理由がある

まず、引用リポストはエンゲージメントの質が高いと評価される。[Tweet Archivist の分析](https://www.tweetarchivist.com/how-twitter-algorithm-works-2025)によると、引用リポストは標準的な投稿の約 2 倍のエンゲージメントを獲得する傾向がある。単純なリツイートは「最小限の認知的努力」で行える行動やから、アルゴリズム的には低評価。引用リポストは「ユーザーが自分の視点を追加した」という高品質なエンゲージメントと見なされる

具体的な重み付けとしては、リツイートはベースラインの約 1〜2 倍の価値があるけど、引用リポストやリプライベースのエンゲージメントと比べるとかなり低い。引用リポストは「いいね」の 1.5〜3 倍程度の評価を受けるという情報もある

自己引用リポスト（セルフ引用 RT）について言うと、2025〜2026 年現在、これが「明確にペナルティを受ける」という公式情報や確固たる証拠はない

むしろ逆で、多くの運用者が「セルフ引用はインプレッションを伸ばしやすい」と報告してる

チーズバーガー戦術

特に流行ってるのが「チーズバーガー戦術」と呼ばれる手法。メインの投稿（軸ポスト）を出してから、自己引用で補足や深掘りを追加していく。これで再現性高く伸びてる例が多数報告されてるんよね

実際の運用者の体験談として、「自分で引用リポストしたら 80 インプレッションが 150〜400 に増えた」「軸ポストをセルフ引用したらエンゲージメントが集まって他の投稿も伸びやすくなった」みたいな話がある

しかし、ワイの実験では、どうもセルフ引用は反応が悪い。10 ポスト中、バズるのが 1 回くらい

ひょっとすると、元々インプレッションが少ないアカウントには有効なのかもしれない

作者リプライのアルゴリズムブースト

もう一つ重要なのが、作者リプライ（Author Reply）の特別な重み付け。X のアルゴリズムには「PredictedReplyEngagedByAuthorScoreFeature」という特殊な加重があって、投稿者本人からのリプライは高く評価される

この仕組みを活用した戦略として、投稿後 30 分以内にできるだけ多くのコメントに返信するという手法がある。これで会話スレッドが形成されて、滞在時間（dwell time）も増加する。アルゴリズムは「会話が活発な投稿」を高く評価するから、初動ブーストにつながるんよ

ただし、これは体感だが、この要素が必要だと感じている

- 具体例がある
- 元ポストに関係している
- 反応が多い

Premium（有料）認証のブースト効果もある。投稿者が Premium 認証済みで、閲覧者がその人をフォローしてる場合、ツイートのスコアが 4 倍になる。フォローしてない場合でも 2 倍。これはかなり大きなアドバンテージやね

初動エンゲージメントの速度も重要で、最初の 1 時間のエンゲージメントがトータルスコアの約 50% を占めるとも言われてる

ただし、一つもリプなしでインプレッションが 30 万に到達するポストもあるので、あまり重要だとは思っていない

リンクペナルティを無効化する条件

ここからが本題。リンクペナルティは絶対的なものやなくて、特定の条件を満たすと「例外処理」が働いてペナルティが緩和される

研究と実践から分かってる「無効化条件」はこれ

- 高い滞在時間 → 投稿本文が濃くて、画像や動画が多めで、ユーザーが長時間その投稿を見てる場合、アルゴリズムは「質の高いコンテンツ」と判断する。外部リンクがあっても、投稿自体で十分な価値を提供してれば、ペナルティが軽減される傾向がある
- 外部リンク先の低離脱率 → リンク先に飛んだユーザーがすぐに離脱せず、コンテンツをちゃんと読んでくれてる場合、これはポジティブなシグナルになる。X はリンク先でのユーザー行動もある程度追跡してるみたいで、「神コンテンツ」へのリンクは評価される
- 高い戻りユーザー率 → 外部リンク先に行った後、X に戻ってきて「いいね」や「引用」や「リプライ」をしてくれるユーザーが多い場合、これが最強のポジティブフィードバック。「このリンクは OK、例外扱い」とアルゴリズムが学習してくれる
- アカウント信頼度（TweepCred） → 過去の投稿履歴、エンゲージメント率、フォロワーとの関係性などから算出されるスコア。このスコアが高いアカウントは、リンク付き投稿でも初動抑制が緩くなる

ワイの実験で 24 時間後に差が 2.8 倍まで縮まったのは、まさにこの例外処理が効き始めた証拠やと思う。初動では抑えられても、戻りエンゲージメントが積み重なると、アルゴリズムが「質高いリンク判定」に切り替わって For You 推薦を再開するパターン

Premium 認証の影響

Premium（有料認証）に加入してると、リンク直貼りのペナルティがかなり軽減されるという報告が多い。非 Premium と比較して 2〜4 倍マシになるケースもあるらしい

:::info
Premium のブースト効果

- フォロワーがあなたの投稿を見る場合 → スコア 4 倍
- 非フォロワーが見る場合 → スコア 2 倍
  :::

これは X のビジネスモデルを考えると納得できる。Premium ユーザーは月額料金を払ってるから、広告収益への依存度が低い。だから「ユーザーを外に出さない」というプレッシャーが相対的に弱くなる。あと、Premium ユーザーはボットやスパムの可能性が低いと見なされるから、信頼度ボーナスもある

ただし、Premium だからといってリンクペナルティが完全になくなるわけやない。あくまで「軽減」であって、リンクなし投稿と比較するとまだハンデはある

目的別の最適な投稿戦略

ここまでの分析を踏まえて、目的別の最適戦略をまとめてみる

| 目的                 | おすすめ配置              |
| -------------------- | ------------------------- |
| インプレッション優先 | リンクなし → 引用でリンク |
| トラフィック優先     | メイン直貼り              |
| ハイブリッド         | メイン直貼り + 濃い本文   |

インプレッション・認知・バズ優先 の場合は、リンクなしのメイン投稿を出して、引用リポストまたはリプライでリンクを補足する形式がベスト。初速が最強で、アルゴリズムが「外に出さない」優先でブーストしてくれる。フォロワーを増やしたい人や、ブランド認知を狙う人に向いてる。無効化条件を満たす必要度は低め

トラフィック・PV 最大化 の場合は、メイン投稿にリンク直貼りがベスト。これは意外かもしれんけど、クリックまでの摩擦が最小やから、見た人のクリック率は圧倒的に高くなる。インプレッションが減っても、実際に外部サイトに流れるトラフィック量はこっちのほうが多いケースが大半。ブログや note、商品 LP への導線が本命の人に向いてる。ただし、無効化条件（アカウント信頼度など）を満たしてる必要がある

ハイブリッド（両取り） の場合は、メインにリンク＋説明充実という形式。質が高くて、戻りエンゲージメント（戻ってきて RT やいいね）が多い場合に強い。「リンク先が神」な場合に有効

リプライにリンクを置く手法は、トラフィック目的だと実はあまり効果的やない。なぜかというと、クリックまでのステップが増えるから。ポストを見る → リプライを開く → リンクをクリック、という 3 ステップになる。離脱率が高くて、実際のトラフィック量はメイン直貼りの半分から 3 分の 1 になるケースが大半。「インプレッションは取れたけど、結局誰も来ない」という悲劇が頻発する

逆にインプレッションが抑えられやすい行動

リンクペナルティ以外にも、インプレッションが抑制される行動パターンがある

インプレッションが下がる行動パターン

- 外部リンクをメイン投稿に直貼り（無効化条件を満たしてない場合）
- 低品質・短文リプライの連投
- スパム報告・ブロック・ミュートなどのネガティブシグナル
- 同じような内容の過度な連投
- 1 日のリーチ枠を使い切るような無意味な短文リプライ大量投下

これらと比較すると、自己引用リポストはかなり安全でむしろ有利な部類に入る。セルフ引用が伸びない場合は、引用文が薄い・ただの宣伝になってる、元ポスト自体が弱い、時間帯やフォロワー層との相性が悪い、などが原因の可能性が高い

実践的な Tips

ここからは具体的な実践方法をまとめていく

メイン投稿にリンク直貼りでトラフィックを最大化したい場合。まず投稿本文を超濃くする。価値提供満載で、画像や動画を入れて滞在時間を稼ぐ。次に投稿直後に自分で高品質リプを連投する。質問や補足で会話量を爆上げして、初動ブーストを狙う。そしてリンク先を神レベルに保つ。離脱率が低くて、戻りエンゲージメントが多いコンテンツを用意する

リンクなし＋引用リポストで初動を最大化したい場合。まずリンクなしで価値だけを伝えるメイン投稿を出す。次にリンクは引用リポストかリプ欄で補足する。これで初動の滞在時間＋引用自体のスコア加点の両取りが狙える

チーズバーガー戦術を使う場合。軸ポスト（メイン投稿）を出す → セルフ引用で補足・深掘り → さらにセルフ引用で最新情報や煽り文句を追加。この積み重ねでエンゲージメントを集めて、他の投稿も伸びやすくなる

投稿タイミングも重要。最初の 1 時間のエンゲージメントがトータルスコアの約 50% を占めるから、フォロワーがアクティブな時間帯に投稿することが大事。日本だと、朝 7〜9 時、昼 12〜13 時、夜 20〜22 時あたりがゴールデンタイムと言われてる

アルゴリズムの透明性に関する議論

ここで少し俯瞰的な話をしておきたい。[Revealing The Secret Power: How Algorithms Can Influence Content Visibility on Twitter/X](https://arxiv.org/abs/2410.17390) は、コンテンツ調整と推薦システムの透明性の重要性を強調してる

X のアルゴリズムは 2023 年に一部オープンソース化されたけど、実際に運用されてるアルゴリズムとオープンソース版には差異があると言われてる。また、アルゴリズムは常に更新されてるから、過去の分析が現在も有効とは限らない

研究者たちは、プラットフォームがどのようにコンテンツの可視性を操作してるかを理解するために、継続的な監査が必要やと主張してる。特に、外部リンクへの一律ペナルティは、信頼できるジャーナリズムとフェイクニュースを同じように扱ってしまう問題がある

これは公開言論の完全性に関わる問題で、オンラインプラットフォームへの公平なアクセスを確保するためには、もっと透明性が必要やという議論がある

2025〜2026 年の最新動向

X のアルゴリズムは常に変化してる。最近の動向をいくつか紹介しておく

2025 年 10 月頃から、X はリンク体験を改善するテストを行ってる。これが正式に実装されれば、リンクペナルティが緩和される可能性がある。ただし、まだテスト段階やから、現時点では従来の戦略が有効

Premium 認証の重要性は増してる。Blue Verified のブースト効果は、フォロワーネットワーク内で 4 倍、ネットワーク外で 2 倍というかなり大きな値。トラフィック最大化を目指すなら、Premium 加入は検討に値する

作者リプライの重み付けも重要視されてる。投稿後 30 分以内の自己リプライが初動ブーストに効果的という報告が増えてる

よくある間違いと対策

リンクペナルティを意識しすぎて、逆効果になってるパターンをよく見かける。ここでいくつかの典型的な間違いと対策を紹介しておく

- 「リンクを絶対にメインに置かない」という極端な姿勢 → 確かにインプレッション優先ならリンクなしがベストやけど、トラフィックを流したいならメイン直貼りのほうが実際のクリック数は多くなる。目的を見失わないことが大事
- 「リプライにリンクを置けば万事 OK」という誤解 → リプライにリンクを置くと、確かに初動は伸びやすい。でも、実際にリンクをクリックしてくれる人は激減する。リプライを開くという一手間が加わるから、離脱率がめっちゃ高くなる
- 「引用リポストを連発しすぎる」パターン → セルフ引用は強い武器やけど、同じ投稿を何度も何度も引用してると、スパム判定を受けるリスクがある。適度な頻度で、かつ毎回新しい価値を追加する形でやるのがベスト
- 「短文リプライの連投」 → 作者リプライにはブースト効果があるけど、「いいね！」「ありがとう！」みたいな低品質リプライを大量に連投すると、逆にアカウント全体の評価が下がる
- 「投稿タイミングを無視する」こと → 最初の 1 時間のエンゲージメントがめっちゃ重要やから、フォロワーがアクティブな時間帯に投稿することが必須。深夜や早朝に投稿すると、いくら良いコンテンツでも初動で死んでしまう

他のソーシャルメディアとの比較

リンクペナルティは X だけの話やない。他のプラットフォームでも似たような仕組みがある

| プラットフォーム | リンクへの厳しさ                 |
| ---------------- | -------------------------------- |
| Instagram        | 非常に厳しい（投稿にリンク不可） |
| LinkedIn         | 最近厳しくなってきた             |
| Facebook         | 動画優遇、リンクは最下位         |
| TikTok           | リンク貼る機会自体が限定的       |

Instagram は X 以上にリンクに厳しい。そもそも通常の投稿にリンクを貼れないし、ストーリーズでリンクスタンプを使っても、アルゴリズム的な優遇は受けられない。プロフィールのリンクに誘導するしかないから、「プロフィールのリンクから見てね」みたいな文言がよく使われる

LinkedIn は比較的リンクに寛容と言われてきたけど、最近はペナルティが強化されてるという報告がある。特に外部サイトへのリンクは、同じプラットフォーム内のコンテンツ（LinkedIn 記事や PDF）と比較して不利になるらしい

Facebook も同様で、外部リンクを含む投稿はオーガニックリーチが低下する傾向がある。Facebook の場合は、動画コンテンツが圧倒的に優遇されてて、外部リンクは最下位に近い扱いを受ける

TikTok は別格で、そもそもリンクを貼る機会が限られてる。プロフィールにリンクを置くことはできるけど、投稿内でリンクを促しても、アルゴリズム的なメリットはほぼない

結局のところ、どのプラットフォームも「ユーザーを外に出さない」という方針は共通してる。これはソーシャルメディアのビジネスモデル上、避けられない傾向なんよね。だからこそ、プラットフォームごとの特性を理解して、それぞれに最適化した戦略を取ることが重要

終わりに

X のリンクペナルティは実在するし、研究でも最大 8 倍のインプレッション減少が確認されてる。でも、これは絶対的なものやなくて、条件次第で無効化できる

:::info
再現性のある結論

・外部リンクは単体で投げない
・まずリンクなしで価値だけを伝える
・リンクは引用リポストかリプ欄で補足する
・ただし、トラフィックを沢山流したいならメイン投稿にリンク直貼り一択
:::

リンクペナルティ無効化の条件をおさらいしておくと

- 長時間読まれている
- 外部リンク先で離脱率が低い
- 戻ってくるユーザーが多い
- アカウント信頼度（TweepCred）が高い

もちろん、リンク付きでもバズるときはバズる。何度もバズらせる必要もない。なのでメインポストにリンクをつけることが絶対 NG という話ではない。リンク先が良ければ、アルゴリズムのペナルティを質でカバーできる

結局のところ、「目的に応じた使い分け」がめっちゃ大事ってこと。インプレッション優先なら引用リポスト、トラフィック優先ならリンク直貼り。両方欲しいなら、アカウント信頼度を高めてペナルティを無効化するしかない

X のアルゴリズムは「ユーザーを外に出さない」ことを優先してるけど、出しても戻ってきてくれるなら許してくれる

結局のところ、ハックとか気にせずに、質の高いコンテンツを作って、ユーザーに価値を提供し続けることが、最強の戦略なんよね

参考文献

- [Revealing The Secret Power: How Algorithms Can Influence Content Visibility on Twitter/X](https://arxiv.org/abs/2410.17390) - NDSS 2026
- [Engagement, User Satisfaction, and the Amplification of Divisive Content on Social Media](https://arxiv.org/abs/2305.16941) - arXiv
- [How the Twitter Algorithm Works in 2026: Complete Technical Breakdown](https://www.tweetarchivist.com/how-twitter-algorithm-works-2025) - Tweet Archivist
- [Lower Quantity, Higher Quality: Auditing News Content and User Perceptions on Twitter/X](https://arxiv.org/abs/2406.17097) - arXiv
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[AI コーディングエージェントでデザイン再現精度を上げる 7 つのテクニック]]></title>
            <link>http://izanami.dev/post/bb9d5d5b-0b1d-4d39-a2ba-2a770e116c3d</link>
            <guid>http://izanami.dev/post/bb9d5d5b-0b1d-4d39-a2ba-2a770e116c3d</guid><dc:creator>commte</dc:creator>
            <pubDate>Fri, 09 Jan 2026 11:49:38 GMT</pubDate>
            <description><![CDATA[X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発などを中心に情報を配信しています

AI コーディングエージェン]]></description>
            <content:encoded><![CDATA[X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です。Agentic AI / AI 駆動開発などを中心に情報を配信しています

AI コーディングエージェントっていうのは、コードを自動生成してくれる AI エージェント（自律的に行動してゴールの達成をするシステム）のこと。Cursor、Claude Code、Antigravity、GitHub Copilot あたりが有名やね

デザインを渡せば HTML/CSS を書いてくれるし、「こんな機能作って」って言えばコンポーネントを生成してくれる。人間がやってた「手を動かしてコードを書く」部分を AI が代行してくれるイメージ

AI コーディングエージェントにデザインを渡す時、やり方で精度が全然変わる

Figma のデザインや参考サイトのスクリーンショットを AI コーディングエージェント に渡して「これ実装して」って頼むこと、めっちゃ増えたよね

やけど、同じデザインを渡しても、人によって出てくるコードの精度が全然違う

80 点で妥協する人もいれば、120 点のクオリティまで持っていく人もいる

Figma MCP 使っても綺麗に再現してくれない

その差は「AI への渡し方」と「フィードバックの出し方」にあるんよ

今回は、有料プラン契約して、ガンガン使い込んでるワイが、Antigravity、Claude Code、Cursor など、どの AI コーディングエージェントでも使える「デザイン再現の精度を上げるテクニック」を 7 つ紹介していく

モデルを選択する

ワイが使い分けてる感覚だと、モデルにはこんな傾向がある

| 用途                 | 使ってるモデル                            |
| -------------------- | ----------------------------------------- |
| 設計・アーキテクチャ | Claude Opus 4.5 が考え深くて良い          |
| フロントエンド       | Gemini 3 Flash はデザイン再現率が高い印象 |
| コーディング全般     | Claude Code (Sonnet 4.5) で十分回る       |
| デバッグ             | Claude Opus 4.5 はコンテキスト理解が深い  |
| テスト               | Codex                                     |

画像を切り出すときは、Figma MCP プラグインインストールすればいいし、新たにアイコンや画像を作りたい場合は、Gemini 3 系をメインで使えばいい

個人的には Antigravity + Gemini 3 Flash の組み合わせがフロントエンドに強いと感じてるけど、結局は 1 つのモデルに固執しない。タスクごとに切り替える のが一番いい

それじゃあ、デザインの再現率を上げるテクニックを紹介していくよ

テクニック 1：セクション単位で切り出す

セクションというのは、ページ内の一つのエリアのこと。ヘッダー、ヒーローセクション、コンテンツエリア、フッターなどがセクションになる

コンテンツエリアは、例えばサービスの特徴・料金表・FAQ セクションのこと



デザイン全体のスクリーンショットを一気に渡すのは、実は逆効果やったりする

AI は視覚情報を処理する時、画像全体に均等に注意を払おうとするから、「ここが重要」っていう部分に焦点が合いにくくなる

例えば、ランディングページ全体を渡すと、ヘッダー、ヒーローセクション、機能紹介、フッターすべてが混在して、どこに注力すべきか判断しづらい

それよりも、「このヒーローセクションだけ」「この CTA ボタン周辺だけ」って切り出して渡す方が、圧倒的に精度が上がる

なぜ切り出すと精度が上がるのか

AI の視覚認識には「解像度」みたいな概念があって、情報量が少ないほど細部まで読み取れる

全画面だと「大体こんな感じのレイアウト」っていう粗い認識になるけど、セクション単位だと「この余白は 32px」「このフォントは font-semibold」っていう細かいレベルまで見てくれる

余白のピクセル感、フォントのウエイト、微細なシャドウや角丸の R（半径）まで正確に認識できるようになるんよ

これは研究でも裏付けられてて、[FastVLM の論文](https://arxiv.org/abs/2412.13303)では「画像解像度のスケーリングが VLM の性能向上に不可欠」って言われてる。ただし、高解像度の画像をそのまま渡すとトークン数が増えて非効率になるから、必要な部分だけ切り出すのが効率的なんよね

さらに面白いのが、[VLM のアテンションヘッド研究](https://arxiv.org/abs/2503.06287)で、数千あるアテンションヘッドのうち、たった 3 つで位置特定ができるって分かってる。つまり AI は画像の特定領域に集中する仕組みを持ってるから、こっちがその領域を絞ってあげると精度が上がるってこと

だから、Figma MCP を使う場合も、セクションや UI ごとにリンクを投げると再現率が高くなる

具体例：ヒーローセクションの切り出し

例えば、こんな感じで切り出す

画面全体ではなく、ヒーローセクションの「見出し + サブテキスト + CTA ボタン」だけをトリミングして渡す

そうすると、AI は以下のような細部まで拾ってくれる

- 見出しと本文の行間（line-height）
- ボタンの角丸の数値（rounded-lg なのか rounded-xl なのか）
- ボタンのパディング（px-6 py-3 なのか px-8 py-4 なのか）
- 見出しとボタンの間の余白（gap-4 なのか gap-6 なのか）

全画面で渡すと「とりあえず見出しとボタンを配置しました」で終わるけど、切り出すと「Tailwind の gap-6、rounded-xl、px-8 py-4 で実装しました」っていう具体的なコードが返ってくる

ツールごとの切り出し方

どのツールでも基本は同じやけど、ちょっとした違いがある

写真や画像を渡すときは、Figma MCP を使って書き出してる。Antigravity で難しい場合は、Claude Code を使って書き出す

Antigravity や Claude Code は、画像をアップロードする時に「この部分だけ見て」ってコメントを添えるとさらに精度が上がる

Cursor は、エディタ内でコメントとして「このセクションを参考に」って書いて画像を貼ると、前後のコードと比較しながら生成してくれる

テクニック 2：既存コードとクラス設計を読み込ませる

AI にデザインを渡す時、いきなり「これ作って」って言うよりも、既存のコードを先に読み込ませておくと、サイト全体の統一感を保ったまま実装してくれる

特に、Tailwind CSS や CSS Modules を使ってるプロジェクトだと、クラス名の命名規則やスペーシングのルールが既にあるはずやから、それを学習させることで「このサイトっぽい」コードが出てくる

トーン＆マナーの継承

既存のコンポーネントファイルを読み込ませると、AI は以下のようなパターンを学習する

- クラス名の命名規則（BEM なのか、単純な utility-first なのか）
- スペーシングの基準（gap-4 が標準なのか、gap-6 が標準なのか）
- カラーパレット（primary、secondary、accent の使い分け）
- タイポグラフィ（見出しは text-2xl font-bold が標準なのか、text-3xl font-semibold が標準なのか）

これを事前に渡しておくだけで、新しいセクションを生成する時も「このサイトの文脈に沿った」コードが返ってくる

具体例：既存ボタンのスタイルを継承

例えば、既にこんなボタンコンポーネントがあるとする

${baseClasses} ${variantClasses[variant]}

このコードを読み込ませた状態で、新しい CTA セクションのデザインを渡すと、勝手に  っていうスタイルを継承してくれる

逆に、既存コードを読ませずにいきなり「これ作って」って言うと、 みたいに微妙に違うスタイルで実装されて、後で統一するのが面倒になる

Tailwind の config も読ませる

Tailwind CSS を使ってる場合、 も一緒に読み込ませると、カスタムカラーやスペーシングの設定まで反映してくれる



この config を読ませておけば、AI は勝手に  とか  みたいなカスタムクラスを使ってコードを生成してくれる

テクニック 3：修正指示を反復で伝える

一発で完璧なコードが返ってくることは、まずない

やけど、多くの人がここで諦めてしまう

「だいたい合ってるからいいか」で妥協するんよね

実は、細かい修正指示を何度も出すことで、80 点のコードが 100 点、120 点に化ける

AI は反復フィードバックに強いから、「角丸をもっと小さく」「左寄せに」「間隔を狭めて」みたいな具体的な指示を出すほど、理想形に収束していく

なぜ反復が効くのか

AI は「前回の生成結果」をコンテキストとして保持してるから、修正指示を出すたびに「前回からの差分」を理解して調整してくれる

例えば、最初に生成されたボタンが  だったとして、「もっと小さく」って指示を出すと、 に調整される

さらに「角丸をもっと控えめに」って言うと、 になる

このように、段階的に理想形に近づけていける

これは [Self-Refine の研究](https://arxiv.org/abs/2303.17651)でも証明されてて、反復的なフィードバックと改善によって、タスクパフォーマンスが平均 20% 向上するって結果が出てる。しかも追加の学習データや強化学習なしで、同じ LLM を使って生成 → フィードバック → 改善のループを回すだけでこの効果が得られる

具体例：CTA ボタンの微調整

最初に生成されたコードがこんな感じだとする



やけど、デザインを見ると「もうちょっと小さめで、角丸も控えめ」っていう感じやったとする

そこで、こんな修正指示を出す

「ボタンのパディングを px-6 py-3 に変更して、角丸を rounded-lg にして」

すると、こうなる



さらに、「フォントを font-semibold に変えて、ホバー時に少し明るくして」って追加で指示を出すと、最終的にこうなる



このように、反復で伝えることで、最初の 80 点が 120 点に到達する

諦めずに指示を出し続けることが最強

多くの人が「AI に修正を頼むのは面倒」って思ってるけど、実は自分で手動で修正するよりも速い

AI は「この数値を変えて」っていう指示に対して、瞬時に反映してくれるから、手動で CSS を書き直すよりも圧倒的に速く調整できる

だから、「微調整を諦めず、何度も指示する」ことが、最強のアプローチになる

テクニック 4：インタラクションを言語化する

静止画だけだと、「動き」の部分が伝わらない

ホバー時のアニメーション、クリック時のフィードバック、スクロール時の挙動など、UX に関わる部分は言葉で補足しないと、AI は実装してくれない

例えば、「ホバーした時にふわっと浮き上がる感じ」「クリックした時に少し沈み込む」「スクロールに応じてフェードインする」みたいな表現を添えると、コードに反映しやすくなる

具体例：ホバー時の浮き上がり

例えば、カードコンポーネントにホバー時の浮き上がり効果を付けたいとする

静止画だけだと、AI はこんなコードを生成する



やけど、「ホバー時にふわっと浮き上がる感じ」って添えると、こうなる



 と  が追加されて、ホバー時に浮き上がる効果が実装される

具体例：クリック時の沈み込み

ボタンに「クリックした時に少し沈み込む」っていう効果を付けたい場合も、言葉で伝えるだけで実装される



 が追加されて、クリック時に少し縮む効果が入る

Framer Motion や GSAP の指定も有効

もっと複雑なアニメーションを実装したい場合、「Framer Motion を使って、スクロールに応じてフェードインさせて」みたいに指定すると、ライブラリを使ったコードを生成してくれる



このように、インタラクションを言語化することで、静止画では伝わらない「質感」まで実装できる

テクニック 5：アクセシビリティを意識する

デザインを再現する時、見た目だけ合わせればいいってわけじゃない

スクリーンリーダーでの使い勝手、キーボード操作、フォーカス管理など、アクセシビリティも考慮しないと、プロレベルのコードにはならない

AI に「見た目だけでなく、スクリーンリーダーでの使い勝手も考慮して」って一言添えるだけで、より高品質な HTML 構造を提案してくれる

具体例：ボタンのアクセシビリティ

例えば、アイコンだけのボタンを実装する時、普通に生成すると以下のようになる



やけど、「スクリーンリーダー対応も考慮して」って添えると、こうなる



 が追加されて、スクリーンリーダーでも「メニューを開く」って読み上げられるようになる

フォーカス管理も自動で入る

さらに、「キーボード操作も考慮して」って指示を出すと、フォーカス時のスタイルも追加される



 と  が追加されて、キーボードでフォーカスした時にリングが表示される

セマンティック HTML も提案される

「見出し構造を意識して」って指示を出すと、 の代わりに 、、 みたいなセマンティックタグを使ったコードが返ってくる



このように、アクセシビリティを意識することで、単なる「見た目が合ってるコード」から「プロレベルのコード」に格上げされる

テクニック 6：配色とフォントのルールを明示する

デザインを渡す時、「この色は primary」「このフォントは見出し用」みたいに、デザインシステム的な情報も一緒に伝えると、AI が勝手にルールを守ってくれる

特に、複数のセクションを実装する時、色やフォントが統一されてないと、後で調整するのが面倒になる

具体例：カラーパレットの定義

例えば、こんな感じでカラーパレットを定義して渡す



これを AI に伝えておくと、新しいセクションを生成する時も、勝手に （Primary）や （Secondary）を使ってくれる

フォントのルールも定義する

フォントについても、「見出しは font-bold、本文は font-normal、強調は font-semibold」みたいに伝えておくと、統一感のあるコードが返ってくる



これを伝えておけば、AI は勝手にルールを守ったコードを生成してくれる

テクニック 7：80 点の構造から 120 点に到達する

一発で 100 点を目指すよりも、「80 点の構造」を出した後に、具体的なフィードバックを出す方が、結果的に最速で 120 点のクオリティ（理想以上）に到達する

AI は「ゼロから完璧なものを作る」よりも、「ある程度の形があるものを修正する」方が得意やから、最初は大枠だけ作らせて、後から細部を詰めていくアプローチが効率的

具体例：ヒーローセクションの段階的改善

最初に、「ヒーローセクションを作って」って指示を出す

すると、こんなコードが返ってくる



これで 80 点

ここから、細かい修正指示を出していく

「背景をグラデーションにして、見出しをもっと大きく、ボタンを左寄せに」

すると、こうなる



これで 100 点

さらに、「ボタンにホバー時のアニメーションを付けて、見出しに文字間隔を少し広げて」って追加指示を出すと、最終的にこうなる



これで 120 点

最初から完璧を求めずに、段階的に改善していくことで、理想以上のコードに到達する

なぜ段階的改善が最速なのか

AI は「全体像を一気に理解して完璧なものを作る」よりも、「既にある構造を部分的に修正する」方が得意

最初から完璧を求めると、AI は「全部を一度に考えなきゃいけない」状態になって、逆に精度が落ちる

やけど、「まず大枠を作る → 細部を修正する」っていう流れにすると、AI は一つ一つの修正に集中できるから、結果的に高精度なコードが出来上がる

まとめ

AI にデザインを実装させる時、「ただ渡すだけ」じゃなくて、以下の 7 つのテクニックを使うことで、精度が爆上がりする

どれも「ちょっとした工夫」やけど、これをやるかやらないかで、出てくるコードのクオリティが全然変わる

AI は「完璧なものを一発で作る道具」じゃなくて、「反復的に改善していく道具」として使うのが正解

諦めずに指示を出し続けることで、理想以上のコードに到達できる
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Google が無料公開した Startup Technical Guide AI Agents が神]]></title>
            <link>http://izanami.dev/post/71647237-fc71-496b-8266-dcbb99302fa0</link>
            <guid>http://izanami.dev/post/71647237-fc71-496b-8266-dcbb99302fa0</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 05 Jan 2026 08:57:07 GMT</pubDate>
            <description><![CDATA[これは、Claude Code を使いこなす話ではない

Claude Code という存在が「なぜ成立しているか」を Google が丸ごと無料公開した話だ

それが Startup Technic]]></description>
            <content:encoded><![CDATA[これは、Claude Code を使いこなす話ではない

Claude Code という存在が「なぜ成立しているか」を Google が丸ごと無料公開した話だ

それが Startup Technical Guide: AI Agents である

Google が本気で作った AI エージェントガイド

Google Cloud が公開したこのガイドはマジでヤバい。全 64 ページにわたって、AI エージェントの基礎概念からプロトタイプ、そして本番スケールまでの一気通貫なロードマップが詰め込まれている

https://cloud.google.com/resources/content/building-ai-agents

[PDF 版はこちら](https://services.google.com/fh/files/misc/startuptechnicalguideaiagentsfinal.pdf)

よく分かってないが、まとめてみる

どんな話なの？

Claude Code を使って満足してる人へ。これは「AI エージェントを使う話」ではない

「AI エージェントを、プロダクトとして、労働力として、インフラとして作る話」である

例えば、Claude Code をどう使いこなすか、ではなく

Claude Code という存在をどういう設計思想で成立させているか、それを自分たちでも再現するならどうするか。その答えが、このガイドに書いてある

「今は、Claude Code が完成されていて、それを使いこなすほうが早いって風潮じゃね？」って思った人もいるだろう

しかし、これは 優劣ではなくレイヤーの違いの話なのである

今は Claude Code / Cursor / Devin / Antigravity みたいな 完成済みエージェントを使いこなす方が圧倒的に速い

理由はシンプルで

- 設計が要らない
- 評価も運用も考えなくていい
- 即、作業量が増える
- 学習コストが低い

個人開発者や小規模チームなら「使わない理由がない」フェーズ

なので今の風潮として「まずは Claude Code を使え」は、完全に正解

ただし、このガイドが立っている場所はそこじゃないんよ

この Google ガイドは「Claude Code がなぜ成立しているかの設計図」を説明している

今の多くの人は「エージェントを使って仕事を速くしたい」って思ってる

だが、Google が話しているのは「エージェントを社会インフラとしてどう作るか」

これを問うている

Claude Code が完成されているのは事実だけど万能ではない

- 自社 API に深く触れさせたい
- 業務ルールを厳密に守らせたい
- 監査ログが必須
- 誤動作を定量評価したい
- 顧客向けに提供したい

この瞬間に「使うだけ」では足りなくなる

そのとき初めて「あ、これ Claude Code 的なものを自分たちで作る側の話だな」になる

Google ガイドはその「詰む未来」を前提に書かれている

短期的には
Claude Code を使いこなす方が 100 倍速い

中期的には
Claude Code を部品として扱える人が強い

長期的には
Claude Code 的なエージェントを
自分たちの文脈で再構築できる人・組織が勝つ

今は「完成品を使え」

でも Google は「どうせ次は作る側になるだろ？」
という前提で、未来の設計書を先に配っている

ワイは、「最終的に勝ちたいならこれを読め」という Google のメッセージに思えた

…ってことで、その設計書、具体的に何が書いてあるのか見ていこうや

AI エージェントって結局何なのさ？

まず基本から押さえておこう。AI エージェントってのは、単なるチャットボットとは全然違うよ

一般的に、AI エージェントっていうのは、目標を与えられると、自律的にタスクを実行する AI システムなんよね

Google と Alphabet の CEO である Sundar Pichai は、公式の場でこう定義している。「AI エージェントとは、高度な AI モデルの知性とツールへのアクセスを組み合わせたシステムであり、ユーザーに代わってアクションを実行できる。ただし、ユーザーのコントロール下で」と

従来の LLM アプリケーションは、ユーザーからの入力を受けて出力を返すだけだった。でもエージェントは違う。自分で考えて、ツールを使って、複雑なタスクを自律的にこなしていく

具体的にいうと、エージェントには以下の主要コンポーネントがある

- モデル（推論エンジン）：Gemini などの LLM がエージェントの「脳」として機能する
- ツール：外部 API、データベース、ファイルシステムなどにアクセスする手段
- オーケストレーション：複数のステップを計画・実行する仕組み
- メモリ：過去の会話や状態を記憶して、文脈を維持する能力

エージェントの動作フローはこんな感じだ

- ユーザーがエージェントにプロンプトを送る
- モデルが必要なツールを選択し、リクエストをフォーマットする（Function Calling）
- エージェントフレームワークが選択されたツールを実行する
- モデルがツールの出力を解釈し、ユーザーへの応答を生成する

この「ツールを選んで実行する」ってところがめっちゃ重要で、これがあるからエージェントは複雑なタスクを段階的に処理できる

ReAct ループという思考パターン

エージェントの推論プロセスを理解するには、ReAct（Reasoning and Acting）というフレームワークを知っておく必要がある

ReAct は、エージェントが「考える」と「行動する」を交互に繰り返すパターン。具体的には以下の 3 つのステップをループする

Reason（推論）ステップでは、エージェントが現在のゴールと状態を評価して、次に何をすべきか論理的な仮説を立てる。「ユーザーは天気を知りたがってる。まず位置情報を確認して、それから天気 API を呼び出そう」みたいな感じだ

Act（行動）ステップでは、推論結果に基づいて適切なツールを選択し、必要なパラメータを抽出・フォーマットする。これが Function Calling。例えば「weatherapi を呼び出す。パラメータは location=Tokyo」みたいに具体的なアクションに落とし込む

Observe（観察）ステップでは、ツールの実行結果を受け取って解釈する。「天気 API から『晴れ、25 度』というレスポンスが返ってきた」というように、外部からの情報を取り込むんよ

このループを繰り返すことで、エージェントは複雑なタスクを段階的に処理していく。一回のループで終わることもあれば、何十回もループすることもある。タスクの複雑さによって変わる

重要なのは、このループのどこかで失敗すると、最終的な出力も間違ったものになるってこと。だから AgentOps では、各ステップを個別に評価する仕組みが用意されている

モデル選択が成功のカギを握る

エージェントの「脳」となるモデルの選択は、めっちゃ重要な意思決定だ。Google のガイドでは「最も強力なモデルを選ぶのが正解ではない」と強調している

モデル選択のポイントは、capability（能力）、speed（速度）、cost（コスト）の 3 つのバランスを最適化すること。すべてのモデルはこの 3 つの軸で評価できて、ユースケースに応じて最も効率的なオプションを選ぶのが正解だ

モデルの能力が上がると、コストとレイテンシも上がる傾向がある。よくある失敗は、ユースケースが必要としない能力に過剰投資すること。これは無駄な支出と遅いパフォーマンスにつながる

Google のガイドでは、ユースケース別に推奨モデルが紹介されてる

初期プロトタイピングや大規模タスクには、軽量で低コストなモデルが推奨されている。翻訳や分類みたいな高ボリューム・低レイテンシのタスクには、コスト効率を重視したモデルを選ぶのがポイントだ

高ボリュームで高品質が求められるアプリケーションには、バランスの取れた中間レンジのモデルがいい。品質・コスト・速度のトレードオフをコントロールできる設計になってて、本番アプリケーションに向いてるんよ

複雑な多段階推論やフロンティアコード生成には、高性能な推論モデルを選ぶ。マルチモーダル理解と強力なエージェント・コーディング能力を持つモデルが、こういったタスクには適している

実際のシステムでは、単一のモデルに固定するのではなく、タスクに応じて複数のモデルを使い分けるのが理想的だ。堅牢な認知アーキテクチャでは、複数の専門エージェントがそれぞれ最適なモデルを選択する。重い処理は高性能モデル、軽い処理は軽量モデルって感じで、システム全体のコストとパフォーマンスを最適化できる

グラウンディングが信頼性のカギ

AI エージェントを語る上で絶対に外せないのが「グラウンディング」だ。これは、エージェントの応答を事実に基づかせるための仕組みなんよ

LLM だけだと、いわゆる「ハルシネーション」（事実と異なる内容を自信満々に答える現象）が起きることがある。でもグラウンディングを使えば、エージェントは外部のデータソースから最新の情報を取得して、それに基づいた正確な応答ができるようになる

グラウンディングには主に 2 つの方法がある

まず、Google Search との連携。これを使えば、エージェントはリアルタイムでウェブ上の情報を検索して、最新のデータに基づいた回答ができる。例えば「今日の東京の天気は？」みたいな質問にも正確に答えられるようになる

もう一つは、RAG（Retrieval-Augmented Generation）だ。これは企業の内部ドキュメントやナレッジベースをベクトルデータベースに格納して、関連する情報を検索・参照しながら応答を生成する手法。社内の FAQ やマニュアルを参照して回答するカスタマーサポートエージェントなんかに最適だね

RAG の仕組みを深掘りする

RAG はエンタープライズ向けエージェントで特に重要な技術だから、もう少し詳しく見ていこう

RAG の基本的な流れは以下の通り

まず、ドキュメントの準備。社内の PDF、Word ファイル、Web ページ、データベースなど、参照したい情報源を集める。これらをチャンク（小さな断片）に分割して、埋め込みモデルでベクトル化する

次に、ベクトルデータベースへの格納。ベクトル化されたチャンクを Vertex AI Vector Search や AlloyDB のようなベクトルデータベースに格納する。これによって、意味的に類似したコンテンツを高速に検索できるようになるんよ

そして、クエリ時の検索。ユーザーからの質問が来たら、その質問もベクトル化して、データベースから関連度の高いチャンクを検索する。通常は上位 5〜10 件のチャンクを取得する

最後に、コンテキスト付きの生成。取得したチャンクをプロンプトに含めて、LLM に回答を生成させる。「以下の情報を参考にして回答してください」みたいな形でコンテキストを渡す

RAG を使うと、以下のメリットがある

- 最新の情報に基づいた回答ができる（モデルの学習データに依存しない）
- 社内の機密情報を安全に活用できる（外部に送信しない）
- 回答の根拠を示せる（どのドキュメントから情報を取得したか追跡可能）
- ハルシネーションを大幅に減らせる

Google のガイドでは、Vertex AI Search を使った RAG の実装が推奨されてる。Vertex AI Search は、構造化データ・非構造化データの両方に対応してて、エンタープライズグレードのセキュリティと可観測性が組み込まれている

ツール設計のベストプラクティス

エージェントのツールは、外部世界との接点になるめっちゃ重要なコンポーネントだ。ツールの設計が悪いと、エージェント全体のパフォーマンスが下がる

Google のガイドで紹介されてるツール設計のベストプラクティスを見ていこう

まず、ツールの説明は明確かつ具体的に書くこと。モデルはツールの説明（docstring）を読んで、いつどのツールを使うか判断する。曖昧な説明だと、間違ったツールを選んだり、必要なツールを使わなかったりする

良い説明の例を挙げると



次に、パラメータの型と制約を明確にすること。エージェントは型情報を参考にして、正しい形式で引数を渡す。enum を使って選択肢を制限したり、バリデーションを追加したりすると、エラーを減らせる



エラーハンドリングも重要だ。ツールがエラーを返した場合、エージェントがそのエラーを理解して適切に対処できるように、分かりやすいエラーメッセージを返す必要がある



最後に、べき等性（idempotency）を考慮すること。同じツールを同じ引数で複数回呼び出しても、結果が変わらないように設計するのが理想的だ。エージェントは推論のリトライで同じツールを複数回呼ぶことがあるから、副作用の管理が重要になる

Google Cloud のエコシステムが充実しすぎ

Google Cloud は AI エージェント構築のために、めっちゃ充実したエコシステムを用意している。その中心にあるのが Vertex AI Platform

Vertex AI は、モデルのトレーニングからデプロイ、運用まで一貫して管理できる統合プラットフォームだ。Gemini をはじめとする最先端のモデルにアクセスできるし、ファインチューニングやプロンプトエンジニアリングのツールも揃ってる

そして、エージェント開発の中核となるのが ADK（Agent Development Kit）だ。これについては次のセクションで詳しく解説するけど、コードファーストなアプローチでエージェントを構築できるオープンソースのフレームワークなんよ

他にも以下のツールが用意されてる

- Gemini Code Assist：コーディング作業を効率化する AI アシスタント
- Colab Enterprise：データ分析や機械学習実験のための環境
- Vertex AI Search：エンタープライズ検索とベクトル検索の機能
- Google Agentspace：複数のエージェントを管理・スケーリングするプラットフォーム

これらのツールを組み合わせることで、アイデアからプロトタイプ、そして本番スケールまでスムーズに進められる

ADK（Agent Development Kit）でコードファースト開発

ADK は Google が Cloud NEXT で発表したオープンソースのフレームワークで、エージェント実装を体系化するための中核ツールとして位置づけられている

ADK の特徴は「コードファースト」なアプローチだ。GUI でポチポチ設定するのではなく、Python や TypeScript でエージェントのロジックを直接書いていく。これによって、エンジニアは細かいコントロールができるし、バージョン管理やテストもしやすくなる

ADK の主な特徴を挙げると

まず、モデル非依存だってこと。Gemini に最適化されてるけど、他の LLM も使える設計になってる。将来的にモデルを切り替えたくなっても、大きな変更なしに対応できる

次に、マルチエージェントシステムの設計が簡単ってこと。複数の専門エージェントを階層的に配置して、複雑なタスクを協調して処理させることができる。例えば、「リサーチエージェント」「執筆エージェント」「レビューエージェント」を組み合わせて、コンテンツ制作パイプラインを自動化するみたいなことができるんよ

さらに、開発者ツールが統合されてる。CLI と Developer UI が付属してて、エージェントの実行、ステップごとの検査、デバッグ、定義の可視化まで一通りできる。開発効率がめっちゃ上がるだろうね

言語サポートも充実してきてて、Python、TypeScript v0.2.0、Go v0.3.0 が利用可能だ。チームの技術スタックに合わせて選べるのはありがたいよね

ADK で実際にエージェントを作ってみる

ADK でエージェントを作る基本的なコードを見てみよう。Python での実装例だ



このコードのポイントは 3 つある

まず、@Tool デコレータでツールを定義してる。関数に docstring を付けると、それがツールの説明としてモデルに渡される。モデルはこの説明を読んで、どのツールをいつ使うか判断する

次に、Agent クラスでエージェントを定義してる。モデル、ツール、システムプロンプトを指定するだけで、基本的なエージェントが完成する。めっちゃシンプルだろ

最後に、agent.run() でエージェントを実行してる。内部では ReAct ループが回って、必要に応じてツールが呼び出されるんよ

マルチエージェントシステムの構築例

複数のエージェントを組み合わせた例も見てみよう



SequentialAgent は、エージェントを順番に実行するワークフローだ。researchagent の出力が analysisagent の入力になり、その出力が writeragent の入力になる

並列処理が必要な場合は ParallelAgent を使う。複数の独立したタスクを同時に実行して、結果を統合できる

LoopAgent を使えば、条件が満たされるまで処理を繰り返すこともできる。品質チェック → 修正 → 再チェックみたいなイテレーションに便利だね

Agent Starter Pack で爆速スタート

ADK でエージェントを作る方法は分かったけど、本番環境に持っていくには他にもいろいろ必要だ。CI/CD、テスト環境、モニタリング、ログ収集...これらを一から構築するのはめっちゃ大変

そこで Google が用意してくれたのが Agent Starter Pack だ。GitHub で公開されてて、本番グレードのエージェントを数分で立ち上げられるテンプレート集なんよ

Agent Starter Pack に含まれてるものは以下の通り

- 本番対応のエージェントテンプレート
- pytest ベースのテスト環境（tests/unit/ と tests/integration/）
- GitHub Actions または Cloud Build での CI/CD パイプライン
- OpenTelemetry による可観測性スタック
- BigQuery へのログ転送設定
- Looker Studio ダッシュボードテンプレート
- Vertex AI Agent Engine へのデプロイスクリプト

使い方はめっちゃ簡単で、リポジトリをクローンして、いくつかの設定を変更するだけ。make test でテストを実行して、make deploy でデプロイできる

特に嬉しいのは、AgentOps の 4 層評価フレームワークがすでに組み込まれてること。tests/unit/ でコンポーネントテスト、tests/integration/ で軌跡評価、本番環境でシステムレベルモニタリングが動く。評価の仕組みを一から作る必要がない

Google のガイドでも「プロトタイプから本番へ移行する際は Agent Starter Pack を使え」と強く推奨されてる

ADK でエージェントを定義する基本ステップ

実際に ADK でエージェントを構築する流れを見ていこう

まず、エージェントの役割と目標を明確にする。「このエージェントは何をするのか？」「どんな問題を解決するのか？」をはっきりさせることがスタート地点だ

次に、必要なツールを設計する。エージェントが外部と対話するための「手足」を定義する。例えば、データベースへのクエリ、API の呼び出し、ファイルの読み書きなど、タスクに必要な操作をツールとして実装するんよ

そして、オーケストレーションのロジックを組む。単一のエージェントで完結するのか、複数のエージェントが協調するのか、どんな順序でタスクを実行するのかを決める。ADK には SequentialAgent、ParallelAgent、LoopAgent といったワークフローエージェントも用意されてて、構造化されたプロセスを簡単に実装できる

最後に、メモリとコンテキスト管理を設定する。会話履歴をどこまで保持するか、長期記憶をどう扱うかを決める。Google のガイドでは「Memory Distillation（記憶の蒸留）」という高度なテクニックも紹介されてて、重要な情報を効率的に保持する方法が解説されている

AgentOps で本番環境の信頼性を確保

ここまでは「エージェントをどう作るか」の話だったけど、本当に重要なのは「どう運用するか」だ。Google はこれを「AgentOps」と呼んでる

AgentOps は、DevOps、MLOps、DataOps の原則を AI エージェントの構築・デプロイ・管理に適用した運用方法論だ。非決定的な LLM ベースのシステムを本番環境で安全に運用するための、体系的で自動化された再現可能なフレームワークを提供してくれる

Google のガイドによると、多くのエージェントが本番で失敗する原因は、モデルの性能ではない。「退屈な」運用作業をサボるからだ。AgentOps はその「退屈だけど重要な作業」をフレームワーク化してくれる

堅牢な AgentOps 戦略は開発プロセスを体系化して、ツール、推論能力、基盤モデル全体の信頼性、安全性、パフォーマンスを向上させる継続的なフィードバックループを提供するんよ

AgentOps の 4 層評価フレームワーク

非決定的なエージェントシステムの評価は、現代ソフトウェアエンジニアリングで最も複雑な課題の一つだ。従来のテストは語彙的な正確さ（コードが動くかどうか）に焦点を当てるけど、エージェント評価は 2 つのより難しい問題に対処する必要がある

一つは意味的正確性。エージェントがユーザーの意図を理解して、役立つ回答を提供できてるか？ってこと

もう一つは推論的正確性。エージェントが論理的で効率的なパスを辿って結論に至ったか？ってこと

これらを評価するために、Google は 4 層の評価フレームワークを提案している

Layer 1：コンポーネントレベル評価（決定的ユニットテスト）

この層は、予測可能な非 LLM コンポーネントに焦点を当てる。目的は個々のビルディングブロックの語彙的正確性を検証して、エージェントの失敗が単純なバグに起因しないことを確認することだ

テスト対象は以下の 3 つ

- ツール：有効な入力、無効な入力、エッジケース入力での期待動作
- データ処理：パースとシリアライズ関数の堅牢性
- API 統合：成功、エラー、タイムアウト条件の処理

実装面では、ADK がエージェントのツールを Python 関数（または Java メソッド）として定義するから、これらの関数がコンポーネントレベルテストの直接の対象になる。Agent Starter Pack は標準的な pytest 環境を含むテストインフラを提供してて、tests/unit/ ディレクトリにユニットテストを書いて make test コマンドで実行できる

Layer 2：軌跡評価（手続き的正確性）

これはエージェントの推論プロセスを評価する最も重要な層だ。「軌跡」とは、タスクを完了するためにエージェントが取る Reason、Act、Observe ステップの完全なシーケンスのことだね

目的は ReAct サイクル内の推論正確性を検証すること

テスト対象は以下の 3 つ

- Reason ステップ：エージェントがゴールと現状を正しく評価して、次のステップの論理的仮説を形成できてるか？
- Act ステップ：正しいツールを選択して、そのツールの引数を正しく抽出・フォーマットできてるか？（Tool Selection と Parameter Generation）
- Observe ステップ：ツールの出力を正しく統合して、次の Reason ステップに反映できてるか？

実装面では、ADK のコアランタイムがエージェントの ReAct ループを実行して、Google Cloud Trace と直接統合する。これによって開発者は軌跡全体を可視化して、ツールの入出力を検査して、モデルの思考連鎖をデバッグできる

Agent Starter Pack は軌跡評価を自動化・スケール化してくれる。tests/integration/ ディレクトリに「ゴールデンセット」（期待される ReAct 軌跡を持つプロンプト集）を作成して、自動化された CI/CD パイプラインがすべてのプルリクエストでこれらのテストを実行する。リグレッションを防ぐために、めっちゃ重要な仕組みだね

Layer 3：アウトカム評価（意味的正確性）

この層は、ReAct ループが終了した後の最終的なユーザー向け応答を評価する

目的は最終回答の意味的正確性、事実的正確性、全体的な品質を検証すること

テスト対象は以下の 3 つ

- 事実精度とグラウンディング：回答が Observe ステップで収集した情報に基づいて正確で検証可能か？
- 有用性とトーン：応答がユーザーのニーズに適切なスタイルで完全に対応してるか？
- 完全性：応答に必要な情報がすべて含まれてるか？

実装面では、ADK のツールセットが事実精度検証のカギになる。開発者は専用のツールを作成するか、API を使ってグラウンディング検証ができる。Act ステップ中に呼び出されるこれらのツールは、エージェントの最終回答が取得したコンテキストに裏付けられてるかをプログラム的にチェックして、ハルシネーションに対する定量的な指標を提供する

Agent Starter Pack は Vertex AI の Gen AI 評価サービスと統合してて、LLM-as-judge スコアリングを提供する。組み込みの UI プレイグラウンドには、人間の評価を BigQuery に直接記録するフィードバック機構も含まれてて、高精度な HITL（Human-in-the-Loop）評価ができるようになってるんよ

Layer 4：システムレベルモニタリング（本番環境）

評価はデプロイで終わりではない。エージェントのライブパフォーマンスを継続的に監視することが超重要だ

目的は実環境でのパフォーマンスを追跡して、運用障害や行動のドリフトを検出すること

モニタリング対象は以下の 3 つ

- ツール失敗率、ユーザーフィードバックスコア
- 軌跡メトリクス（例：タスクあたりの ReAct サイクル数）
- エンドツーエンドのレイテンシ

実装面では、本番環境で動作する ADK エージェントが運用データの源になる。すべてのユーザーインタラクションでイベントとトレースを発行する

Agent Starter Pack は本番グレードの可観測性スタックをすぐに使える形で提供してる。OpenTelemetry を自動設定して、BigQuery への Log Router を構成して、Looker Studio ダッシュボードのテンプレートも用意されてる。チームは追加設定なしで、すぐにエージェントのパフォーマンスを追跡して、トレンドを分析して、実データに基づいて問題をデバッグできるんよね

この包括的で実践的なエージェント評価の方法論は、堅牢な AgentOps 戦略の具体的な実装だ。非公式な「バイブテスト」から、体系的で自動化された再現可能なプロセスへとチームを移行させる。評価をコンポーネント、軌跡、アウトカム、システムレベルのモニタリングに分解することで、AgentOps のコアドメインに直接対応できる

セキュリティとガバナンスを忘れずに

AI エージェントは強力だけど、それだけにセキュリティとガバナンスが超重要だ。特にエンタープライズ環境では、ここを軽視すると大問題になる可能性がある

Google のガイドでは、以下のポイントが強調されてる

まず、アクセス制御。エージェントがアクセスできるデータやシステムを最小限に制限する。「最小権限の原則」をエージェントにも適用するってことだね。例えば、カスタマーサポートエージェントには顧客情報の読み取り権限だけを与えて、削除や変更はできないようにする

次に、監査ログ。エージェントのすべての行動を記録して、後から検証できるようにする。「いつ、誰の指示で、何をしたか」を追跡できることが、コンプライアンス上も重要なんよ

そして、入力検証。ユーザーからの入力や外部データを信頼しないこと。プロンプトインジェクション攻撃みたいな悪意あるリクエストを検知・ブロックする仕組みが必要だ

最後に、出力フィルタリング。エージェントの応答に機密情報や不適切な内容が含まれてないかチェックする。意図せず社内情報を漏らしたり、差別的な発言をしたりするリスクを軽減する

これらのセキュリティ対策は、開発の最初から組み込んでおくのがベストだ。後から追加しようとすると、アーキテクチャの変更が必要になって大変なことになるからね

マルチエージェント設計の考え方

複雑なタスクを処理するには、単一のエージェントではなく、複数のエージェントが協調するマルチエージェントシステムが効果的だ

マルチエージェントの基本的なパターンはいくつかある

階層型アーキテクチャでは、「オーケストレーター」エージェントが全体を統括して、専門エージェントにタスクを委任する。例えば、ユーザーからの複雑なリクエストをオーケストレーターが受け取り、「検索エージェント」「分析エージェント」「要約エージェント」にそれぞれサブタスクを割り当てるみたいな感じだ

並列型アーキテクチャでは、独立したエージェントが同時に動いて、それぞれの結果を最後に統合する。処理時間を短縮できるけど、結果の一貫性を保つのが課題になる

パイプライン型アーキテクチャでは、エージェントが順番に処理をして、前のエージェントの出力が次のエージェントの入力になる。品質管理がしやすいけど、どこかで詰まると全体が止まるリスクがある

どのパターンを選ぶかは、タスクの性質とトレードオフの判断によるんよ。Google のガイドでは、コストと性能のバランスを最適化するための考え方も詳しく解説されてる

デプロイの選択肢

ADK で作ったエージェントをどこにデプロイするか、いくつかの選択肢がある

Google が推奨してるのは Vertex AI Agent Engine Runtime だ。これは AI エージェント専用に設計されたフルマネージドサービスで、スケーリングやバージョン管理、モニタリングを自動でやってくれる。運用の手間を最小限にしたいなら、これが一番楽だね

もう少し自由度が欲しいなら、Cloud Run や GKE にコンテナとしてデプロイする方法もある。既存のインフラに組み込みたい場合や、カスタムの設定が必要な場合はこっちが向いてるかもしれない

オンプレミス環境や他のクラウドプロバイダーでも動かせるのが ADK の強みだ。コンテナ化さえすれば、基本的にどこでも動くからね

どの方法を選ぶにしても、AgentOps の原則を守って、テスト → ステージング → 本番という段階的なデプロイを心がけることが大事

Google Agentspace でエージェントを組織全体に展開

複数のエージェントを組織全体で管理・運用するなら、Google Agentspace を検討する価値がある

Agentspace は、エージェントのワークフォースを一元管理するためのプラットフォーム。複数のエージェントを登録して、ユーザーがそれらにアクセスできるようにするハブの役割を果たすんよね

Agentspace の主な機能は以下の通り

エージェントカタログ機能では、組織内で利用可能なエージェントを一覧表示できる。ユーザーは必要なエージェントを簡単に見つけて、すぐに使い始められる

アクセス制御機能では、誰がどのエージェントを使えるかを細かく設定できる。部署ごと、役職ごと、プロジェクトごとにアクセス権を管理できるから、セキュリティとコンプライアンスを維持しながらエージェントを展開できる

統合検索機能では、複数のエージェントを横断して検索できる。ユーザーは「どのエージェントに聞けばいいか」を考えずに、Agentspace に質問するだけで適切なエージェントにルーティングされるんよ

分析ダッシュボード機能では、エージェントの利用状況、パフォーマンス、コストを可視化できる。どのエージェントがよく使われてるか、どこにボトルネックがあるかを把握して、改善につなげられる

Agentspace は特にエンタープライズ環境で威力を発揮する。10 個、100 個とエージェントが増えていくと、管理が複雑になるけど、Agentspace があれば一元的にコントロールできる

コスト最適化の実践的なヒント

AI エージェントの運用コストは、主に LLM の API 呼び出しに依存する。適切に最適化しないと、思わぬ高額請求が来ることもある

Google のガイドで紹介されてるコスト最適化のヒントを見ていこう

まず、モデルの使い分けを徹底すること。これは先ほども触れたけど、めっちゃ重要だ。すべてのタスクに Gemini 3 Pro を使う必要はない。ルーティングやシンプルな判断には Flash-Lite、通常のタスクには Flash、複雑な推論だけ Pro という使い分けで、コストを大幅に削減できる

次に、キャッシュを活用すること。同じような質問に対して毎回 LLM を呼び出す必要はない。よくある質問の回答をキャッシュしたり、検索結果をキャッシュしたりすることで、API 呼び出し回数を減らせるんよ

プロンプトの最適化も効果的だ。長すぎるプロンプトは、入力トークン数を増やしてコストを上げる。必要な情報だけを含めた簡潔なプロンプトを心がけると、レスポンスも速くなって一石二鳥だね

バッチ処理も検討する価値がある。リアルタイム性が必要ないタスクは、まとめて処理することでコストを抑えられることがある。Gemini API にはバッチ処理用のエンドポイントがあって、通常より安い料金で利用できる

最後に、使用量のモニタリングを徹底すること。Agent Starter Pack には BigQuery へのログ転送が組み込まれてるから、どのエージェントがどれだけコストを使ってるかを追跡できる。異常なコスト上昇を早期に検知して、対策を打てるようにしておくのが大事だね

よくある失敗パターンと対策

Google のガイドやコミュニティのフィードバックを基に、エージェント開発でよくある失敗パターンをまとめてみた

失敗パターン 1 は「いきなり複雑なシステムを作ろうとする」こと。最初からマルチエージェント、RAG、複数ツールを組み合わせた巨大システムを作ろうとして、何が問題なのか分からなくなるパターンだ。対策は、まず単一エージェント・単一ツールで動作確認して、徐々に複雑にしていくこと

失敗パターン 2 は「評価を後回しにする」こと。とりあえず動くものを作って、評価は後でやろうとするパターン。でも後から評価の仕組みを入れるのはめっちゃ大変で、結局やらないまま本番に出して問題が起きる。対策は、Agent Starter Pack を使って最初から評価の仕組みを組み込むこと

失敗パターン 3 は「プロンプトに頼りすぎる」こと。システムプロンプトを長々と書いて、エージェントの動作を制御しようとするパターン。でもプロンプトだけでは限界があるし、メンテナンスも大変。対策は、ツールの設計とオーケストレーションのロジックで動作を制御すること

失敗パターン 4 は「エラーハンドリングを軽視する」こと。正常系だけ作って、エラー時の動作を考えてないパターン。本番では様々なエッジケースが発生するから、エージェントがハングしたり、無限ループしたりする。対策は、タイムアウト、リトライ上限、フォールバック応答を設定すること

失敗パターン 5 は「セキュリティを後付けにする」こと。機能を作り込んでから、最後にセキュリティ対策を追加しようとするパターン。でもアーキテクチャに深く関わる部分は、後から変更するのが難しい。対策は、設計段階からセキュリティを考慮すること

これらの失敗パターンを知っておくだけで、だいぶ時間と労力を節約できるはずだ

実践的に始めるためのステップ

ここまで読んで「で、実際に何から始めればいいの？」って思ってる人もいるだろう。Google のガイドに基づいて、実践的なステップを整理してみた

ステップ 1 はユースケースの特定だ。エージェントで解決したい具体的な課題を明確にする。「カスタマーサポートの自動化」「社内ナレッジの検索」「データ分析の補助」など、まずは 1 つに絞るのがコツだね

ステップ 2 は小さく始めること。いきなり複雑なマルチエージェントシステムを作ろうとしない方がいい。単一エージェント、単一ツールから始めて、徐々に機能を追加していく。Google の Agent Starter Pack を使えば、テンプレートから素早くプロトタイプを作れる

ステップ 3 は評価の設計だ。エージェントの成功をどう測るか、最初から決めておく。「応答の正確性」「処理時間」「ユーザー満足度」など、定量的な指標を設定しておくと、改善のサイクルを回しやすいんよ

ステップ 4 は段階的なスケーリングだ。プロトタイプで動作確認ができたら、徐々にユーザーを増やしていく。いきなり全社展開するのではなく、特定のチームやユースケースから始めて、フィードバックを集めながら改善していくのが安全なアプローチだね

ステップ 5 は継続的な改善だ。本番デプロイしたら終わりではない。AgentOps のモニタリングで得られたインサイトを基に、プロンプトの調整、ツールの改善、モデルの更新を継続的に行っていく

2025 年のエージェント開発トレンド

Google のガイドやその他のソースを総合すると、2025 年の AI エージェント開発には 3 つの大きなトレンドがある

1 つ目は「エージェントが仕事を持った」ってこと。実験的なパイロットから、実際のビジネスプロセスへの広範な導入が進んでる。AI エージェントはもはや「面白いデモ」ではなく、「実際に価値を生む労働力」として認識されるようになってきた

2 つ目は「評価がアーキテクチャになった」ってこと。エージェントの評価を後付けでやるのではなく、設計段階から組み込むのが当たり前になってきてる。AgentOps の 4 層フレームワークみたいに、評価可能性を前提としたアーキテクチャが求められるようになったんよね

3 つ目は「信頼がボトルネックになった」ってこと。技術的には動くエージェントを作れても、それを本番環境で使うかどうかはガバナンスの問題になってる。セキュリティ、コンプライアンス、説明責任をクリアできないと、どんなに優秀なエージェントも採用されない

終わりに

このガイドの何がすごいかっていうと、単なる概念説明ではなく、Gemini を活用したスタートアップ向けの実践的な内容になってるってこと

Google Cloud の「Startup Technical Guide: AI Agents」は、AI エージェント開発の決定版ガイドといっていいレベルの内容だった

このガイドの価値は、単なる技術解説ではなく、アイデアからプロトタイプ、そして本番スケールまでの実践的なロードマップを提供してるところにある

特に重要なポイントをまとめると

- AI エージェントは単なるチャットボットではなく、ツールを使って自律的にタスクを遂行するシステムだ
- グラウンディング（Google Search や RAG）で応答の信頼性を高めることが重要
- ADK を使えばコードファーストなアプローチでエージェントを構築できる
- AgentOps の 4 層評価フレームワークで本番環境の信頼性を確保する
- セキュリティとガバナンスは開発の最初から組み込む

少なくとも Google のガイドを見る限り、2025 年はまさに「エージェントの年」になってて、早めに始めた企業が大きなアドバンテージを得てるんよ。Google Cloud のエコシステムは、その第一歩を踏み出すのに最適な環境を提供してくれてる

興味があったら、まずは公式ガイドをダウンロードして読んでみることをオススメする
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[2026 年に押さえておきたい AI トレンド 38 選]]></title>
            <link>http://izanami.dev/post/3f1f4ef3-2246-4b7a-b911-26b1b8980899</link>
            <guid>http://izanami.dev/post/3f1f4ef3-2246-4b7a-b911-26b1b8980899</guid><dc:creator>commte</dc:creator>
            <pubDate>Fri, 02 Jan 2026 14:40:59 GMT</pubDate>
            <description><![CDATA[AI の進化がめちゃくちゃ速い。2024 年は LLM の年、2025 年は「エージェントの年」と言われてた。ほんで 2026 年はどうなるかというと、エージェントが本番環境に入り、実際に ROI を]]></description>
            <content:encoded><![CDATA[AI の進化がめちゃくちゃ速い。2024 年は LLM の年、2025 年は「エージェントの年」と言われてた。ほんで 2026 年はどうなるかというと、エージェントが本番環境に入り、実際に ROI を問われる年になると予測されてる。「2025 年はエージェントを構築する年、2026 年はエージェントを信頼する年」なんて言われてるくらい

X で 毎日 AI 情報を配信してる[コムテ](https://x.com/commte)です
Agentic AI / AI駆動開発などを中心に情報を配信しています

この記事では、2026 年に押さえておきたい AI トレンドを 5 つのカテゴリに分けて解説していく。一言解説だけやと物足りんって人向けに、実務で役立つ深い知識まで踏み込んでいくで

基盤層：AI の土台を理解する

まずは AI の基盤となる概念から。ここを押さえておかんと、応用的な話についていけなくなる

生成 AI（Generative AI）

何かを「作る」AI 全般のことを指す。テキスト、画像、音声、動画、コード、3D モデル...あらゆるコンテンツを生成できる AI の総称やね

従来の AI は「分類」や「予測」が中心やった。犬か猫かを判定する、株価を予測する、みたいな。生成 AI はそこから一歩進んで、新しいコンテンツを創り出せるようになった

代表的なサービスを挙げると

| カテゴリ | サービス例                           |
| -------- | ------------------------------------ |
| テキスト | ChatGPT、Claude、Gemini              |
| 画像     | DALL-E、Midjourney、Stable Diffusion |
| 動画     | Sora、Runway、Pika                   |
| 音声     | ElevenLabs、Suno                     |

生成 AI の中でも、テキストを扱う LLM がエンジニアにとっては一番身近だろう

LLM（Large Language Model）

テキストを扱う巨大 AI モデル。生成 AI の一部であり、コードを書いたり、文章を生成したり、質問に答えたりできる

「Large」って名前がついてるように、パラメータ数が膨大なのが特徴。GPT-5.2 や Claude Opus 4.5 などの最新モデルは、数兆パラメータ規模と言われてる

LLM が賢い理由は、大量のテキストデータで学習してるから。インターネット上のテキスト、書籍、論文など、人類の知識の大部分を学習に使ってる。なので、様々な分野の知識を持ってて、文脈を理解した自然な回答ができるわけよ

エンジニアとして押さえておきたいポイントは以下

- LLM は「次のトークンを予測する」というシンプルな仕組みで動いてる
- 学習データに含まれてない最新情報は知らない（知識のカットオフ）
- 確率的に出力を生成するから、同じ質問でも毎回少し違う回答になる

SLM（Small Language Model）

軽量で高速な小型言語モデル。エッジデバイスやローカル環境でも動作しやすいのが特徴

代表的な SLM

| モデル    | パラメータ数 | 特徴                           |
| --------- | ------------ | ------------------------------ |
| Phi-3     | 3.8B〜14B    | Microsoft 製、コード生成が得意 |
| Gemma 2   | 2B〜27B      | Google 製、オープンソース      |
| Llama 3.2 | 1B〜3B       | Meta 製、軽量版                |

SLM のメリットは

- ローカルで動くからプライバシーが守れる
- API コストがかからん
- レスポンスが速い
- オフラインでも使える

「LLM じゃないと精度が出んやろ」って思うかもしれんけど、特定のタスクに特化させれば SLM でも十分な性能が出る。ファインチューニングと組み合わせると、コスパ最強の AI システムが作れるで

VLM（Vision Language Model）

画像とテキストを両方理解するマルチモーダルモデル。写真を見せて「これ何？」って聞くと答えてくれるやつ

GPT-5.2、Gemini 3 Pro、Claude Opus 4.5 などが代表例。画像を入力として受け取り、テキストで説明したり、画像に基づいた質問に答えたりできる

VLM の活用例

- UI のスクリーンショットからコードを生成
- グラフや図表の内容を解説
- 商品画像から説明文を自動生成
- 手書きメモのデジタル化

よく使われるケースは、エラー画面のスクリーンショットを貼って「このエラー直して」って聞くパターン。テキストでエラーメッセージをコピペするより、画面全体の文脈が伝わるから解決が早いことが多い

MoE（Mixture of Experts）

複数の専門家ネットワークから一部だけを使う効率的なアーキテクチャ。2025 年のフロンティアモデルはほぼこれを採用してる

人間の脳がタスクによって特定の領域だけを活性化させるように、MoE モデルも入力に応じて必要なエキスパートだけを選んで使う。これにより、モデル全体のパラメータ数は巨大でも、推論時の計算コストを抑えられる

Mixtral 8x7B を例にすると

- 総パラメータ数：467 億
- 実際に使うパラメータ：129 億（トークンあたり）
- 8 つのエキスパートのうち 2 つだけを使用

つまり、467 億パラメータの性能を持ちながら、129 億パラメータ相当のコストで動くってこと。めっちゃ効率的やろ

DeepSeek-V3 はさらに進化してて

- 総パラメータ数：2360 億
- アクティブパラメータ：210 億
- 学習コスト：約 560 万ドル（H800 GPU で 278.8 万時間）

NVIDIA によると、MoE モデルは Blackwell NVL72 上で従来比 10 倍の性能向上を達成。トークンあたりのコストは 10 分の 1 になるらしい

トークン

LLM がテキストを処理する単位。単語や文字の断片のこと

「Hello, world!」を GPT のトークナイザーで分割すると、だいたい 4 トークンくらいになる。日本語は 1 文字あたり 1〜3 トークンくらい消費することが多いから、英語より効率が悪い

トークンを意識すべき場面

- API の料金計算（入力トークン + 出力トークン）
- コンテキストウィンドウの管理
- プロンプトの最適化



日本語のテキストを大量に処理するなら、トークン効率を意識した設計が必要。短い指示で済むようにプロンプトを工夫したり、必要最小限の情報だけを渡したりするのがコツや

コンテキストウィンドウ

LLM が一度に処理できるトークンの上限。入力と出力の合計がこの範囲に収まる必要がある

2025 年の主要モデルのコンテキストウィンドウ

| モデル            | コンテキスト長  |
| ----------------- | --------------- |
| Gemini 3 Pro      | 200 万トークン  |
| Claude Sonnet 4.5 | 100 万トークン  |
| GPT-5.2           | 100 万トークン  |
| Llama 4           | 1000 万トークン |

ただし、コンテキストが大きければいいってもんでもない。研究によると、LLM は文脈の最初と最後の情報は取得しやすいけど、中間部分は苦手らしい。200K トークンを謳ってるモデルでも、実際には 130K あたりから性能が急激に落ちることがある

Claude Sonnet 4.5 は例外的に、200K トークン全体で 5% 未満の精度低下しかないと報告されてる。長文処理が必要なら、モデル選びは慎重にした方がええで

推論（Inference）

学習済みモデルが回答を生成するプロセス。ユーザーからの入力を受け取って、適切な出力を返すこと

「学習（Training）」と「推論」は AI の 2 大フェーズ

- 学習：大量のデータからパターンを学ぶ（めっちゃ時間とコストがかかる）
- 推論：学習した知識を使って予測・生成する（リアルタイムで行う）

エンジニアが普段 API を叩いてるのは、すべて推論フェーズ。推論の最適化が、レスポンス速度とコストに直結するから、後述する TTFT やスループットの概念が重要になってくる


ワールドモデル（World Model）

物理世界をシミュレートできる AI モデル。LLM の次に来る技術として 2026 年に注目されてる

LLM はテキストベースで「次のトークンを予測する」仕組みやけど、ワールドモデルは「次に世界で何が起こるか」を予測する。物体がどう動くか、時間経過でどう変化するかを理解できるんや

ワールドモデルとデジタルツインの関係

| 概念           | 説明                                         |
| -------------- | -------------------------------------------- |
| ワールドモデル | 物理世界の動きを予測する AI モデル           |
| デジタルツイン | 物理空間のデジタル複製、リアルタイム同期     |

ワールドモデルの活用例

- 自動運転のシミュレーション
- ロボット制御の事前学習
- 製造ラインの最適化シミュレーション
- 気象予測、災害シミュレーション

LLM ベースのチャットボットには限界がある。テキストだけでは伝わらん情報、例えば「この棚のこの位置に物を置いて」みたいな空間的な指示は苦手や。ワールドモデルはその限界を超える技術として期待されてる

Euronews によると、2026 年は AI が「テキストチャット」から「世界理解」へシフトする年になる可能性があるらしい


精度向上・知識拡張：LLM をもっと賢くする

LLM 単体には限界がある。最新情報を知らない、ハルシネーションを起こす、専門知識が浅い...。ここで紹介する技術で、これらの問題を解決できる

RAG（Retrieval-Augmented Generation）

外部データを検索して LLM に渡す仕組み。LLM の知識不足を補う定番テクニック

RAG の基本的な流れ

1. ユーザーが質問する
2. 質問に関連するドキュメントをベクトル検索で取得
3. 取得したドキュメントと質問を一緒に LLM に渡す
4. LLM がドキュメントを参照しながら回答を生成



2025 年の RAG ベストプラクティス

- ハイブリッド検索：ベクトル検索とキーワード検索を組み合わせる
- クエリリライト：曖昧な質問を検索しやすい形に変換してから検索
- リランキング：検索結果をクロスエンコーダーで再評価
- チャンク戦略：ドキュメントの分割サイズを最適化
- GraphRAG：知識グラフを活用して関係性も考慮（精度 99% という報告も）

RAG は「検索の質がすべてを決める」と言っても過言やない。LLM をどれだけ良いものにしても、検索がダメなら回答もダメになる

ベクトル検索

意味の近さでドキュメントを検索する技術。キーワード一致ではなく、意味的な類似度で検索できる

従来のキーワード検索との違い

| 検索方式   | 「猫の飼い方」で検索                     |
| ---------- | ---------------------------------------- |
| キーワード | 「猫」「飼い方」を含む文書のみヒット     |
| ベクトル   | 「ネコのお世話」「キャットケア」もヒット |

ベクトル検索の仕組み

1. すべてのドキュメントを Embedding（ベクトル）に変換
2. 検索クエリもベクトルに変換
3. コサイン類似度で近いベクトルを見つける
4. 類似度の高い順にドキュメントを返す

代表的なベクトルデータベース

| DB       | 特徴                            |
| -------- | ------------------------------- |
| Pinecone | フルマネージド、スケーラブル    |
| Weaviate | オープンソース、GraphQL 対応    |
| Qdrant   | Rust 製、高速                   |
| Chroma   | Python 向け、シンプル           |
| pgvector | PostgreSQL 拡張、既存 DB と統合 |

Embedding

テキストをベクトル（数値の配列）に変換したもの。意味を数値で表現することで、類似度計算が可能になる

「犬」と「猫」の Embedding は近い値になるし、「犬」と「経済」は離れた値になる。この性質を使って、似た意味のテキストを見つけられる



Embedding モデルの選び方

- 汎用性重視：OpenAI の text-embedding-3-small/large
- 日本語特化：multilingual-e5-large、Japanese Embedding models
- コスパ重視：Sentence Transformers のオープンソースモデル

ドメイン特化の Embedding を使うと、RAG の精度がグッと上がる。汎用モデルで満足できんかったら、ファインチューニングを検討してみてな

ファインチューニング

既存モデルを特定タスク向けに追加学習させること。ベースモデルの能力を引き継ぎつつ、特定の領域に特化させられる

RAG vs ファインチューニング

| 項目     | RAG                        | ファインチューニング       |
| -------- | -------------------------- | -------------------------- |
| 用途     | 最新情報・外部知識の参照   | 特定タスクの精度向上       |
| コスト   | 推論時に検索コスト発生     | 学習時に一度だけコスト発生 |
| 更新     | ドキュメント追加で即時反映 | 再学習が必要               |
| 専門知識 | ドキュメント次第           | モデルに組み込まれる       |

ファインチューニングが向いてるケース

- 特定の書き方・トーンを学ばせたい
- 社内用語や専門用語を理解させたい
- 特定のフォーマットで出力させたい
- レスポンス速度を上げたい（RAG の検索を省略できる）



Grounding

生成された回答に外部データの根拠を与えて、一貫性と正確性を保つ技術

RAG と似てるけど、Grounding はより広い概念。検索だけやなく、API からのリアルタイムデータ、データベースの情報、ユーザーの行動履歴など、あらゆる外部情報を「根拠」として使う

Grounding のメリット

- ハルシネーションの抑制
- 回答の信頼性向上
- ソースの明示が可能
- 最新情報への対応

Google の Vertex AI や Azure OpenAI Service には、Grounding 機能が組み込まれてて、Web 検索結果を自動的に回答の根拠として使える

制御・手法：LLM を思い通りに操る

LLM は賢いけど、そのままやと使いにくい。ここで紹介するテクニックを使えば、LLM を思い通りにコントロールできるようになる

プロンプトエンジニアリング

LLM への指示文を最適化する技術。同じ質問でも、聞き方次第で回答の質が全然変わってくる

基本的なテクニック

- 明確な指示：曖昧さを排除して具体的に指示する
- 役割設定：「あなたは〇〇の専門家です」
- 出力フォーマット指定：「箇条書きで答えて」「JSON で返して」
- ステップバイステップ：「順を追って説明して」



プロンプトの構成要素を意識すると、安定した結果が得られやすい

- Context：背景情報や前提条件
- Instruction：具体的な指示
- Input：処理対象のデータ
- Output format：期待する出力形式

コンテキストエンジニアリング

LLM に渡す情報全体を設計する技術。プロンプトだけやなく、コンテキストウィンドウに何を入れるかを戦略的に考える

2025 年に入って、この概念がめっちゃ重要になってきた。コンテキストウィンドウが巨大化したことで「何でも入れられる」ようになったけど、だからこそ「何を入れるべきか」の設計が大事

考慮すべき要素

- System Prompt：AI の基本的な振る舞い
- ユーザーの過去の発言：会話履歴
- RAG で取得したドキュメント：外部知識
- ツールの実行結果：Function Calling の結果
- メタデータ：現在時刻、ユーザー情報など

コンテキストエンジニアリングのコツ

- 重要な情報は最初か最後に配置（中間は忘れやすい）
- 関連性の低い情報は削除
- トークン数を意識して必要最小限に
- 情報の優先順位を明確に

System Prompt

AI の役割や振る舞いを定義する、ユーザーから見えない基本指示。すべての会話に適用される設定

System Prompt で定義すること

- AI のペルソナ（専門家、アシスタント、キャラクターなど）
- 回答のスタイル（丁寧、カジュアル、簡潔など）
- 禁止事項（特定の話題を避けるなど）
- 出力フォーマットのデフォルト



Temperature

出力のランダム性を制御するパラメータ。0 に近いほど決定的、高いほど創造的な出力になる

| Temperature | 特徴                         | 用途                   |
| ----------- | ---------------------------- | ---------------------- |
| 0           | 最も確率の高いトークンを選択 | コード生成、事実確認   |
| 0.3〜0.7    | バランス型                   | 一般的な会話、文章作成 |
| 1.0         | 確率に応じてランダム選択     | ブレスト、創作         |
| 1.5〜2.0    | かなりランダム               | 実験的な用途           |



Few-shot

例を数個与えて推論させる手法。「こういう入力にはこういう出力を返してね」という具体例を示すことで、LLM の挙動を制御する



Few-shot のメリット

- 複雑な指示を言葉で説明するより伝わりやすい
- 出力フォーマットを正確に守らせやすい
- ドメイン特有の判断基準を示せる

Zero-shot

例なしで推論させる手法。Few-shot の対義語で、事前に例を与えずに直接タスクを指示する



Zero-shot は手軽やけど、複雑なタスクや特殊なフォーマットが必要な場合は Few-shot の方が安定する。まずは Zero-shot で試して、うまくいかんかったら Few-shot に切り替えるのがおすすめ

CoT（Chain of Thought）

思考過程を出力させて精度を上げる手法。「ステップバイステップで考えて」と指示するだけで、推論精度が劇的に向上する



CoT が効果的な場面

- 数学的な計算
- 論理的な推論
- 複数ステップの問題解決
- 意思決定の説明

「Let's think step by step」という魔法の言葉を追加するだけで、複雑な問題の正答率が上がるという研究結果もある

Extended Thinking

LLM に追加の思考ステップや反省時間を与えて推論精度を上げる手法。CoT をさらに発展させた概念

Claude の Extended Thinking モードや、OpenAI の o1 シリーズがこれにあたる。単に思考過程を出力するだけやなく、自分の推論を検証したり、別のアプローチを試したりする時間を与える



Extended Thinking のポイント

- より多くの時間（トークン）を使う分、コストは上がる
- 複雑な推論、コーディング、数学で特に効果的
- 簡単なタスクには不要（オーバースペック）

JSON Mode

LLM の出力を JSON 形式に強制し、構造化された返答を得るためのモード。API 連携やデータ処理に必須の機能



JSON Mode を使うメリット

- パース失敗のリスクがない
- スキーマを指定すれば型も保証できる
- LLM の出力をそのままプログラムで処理できる

システム・応用：AI を自律的に動かす

ここからは 2025 年のホットトピック。AI エージェントとその周辺技術について

Agentic AI

自律的に判断・行動する AI の総称。2025 年のバズワードで、「エージェントの年」と呼ばれる所以

従来の AI は「質問されたら答える」受動的な存在やった。Agentic AI は違う。目標を与えられたら、自分で計画を立て、必要なツールを使い、結果を検証し、目標達成まで自律的に行動する

Gartner の予測によると

- 2028 年までに、日常業務の意思決定の 15% が AI エージェントによって行われる
- 2029 年までに、一般的なカスタマーサービスの問題の 80% が人間の介入なしに解決される

IBM の調査では、開発者の 99% が AI エージェントの探索・開発に取り組んでるらしい

AI エージェント

目標達成まで自律的に行動する AI システム。Agentic AI の具体的な実装形態

AI エージェントの構成要素

- LLM（脳）：思考と意思決定
- ツール（手足）：外部システムとの連携
- メモリ（記憶）：過去の行動と結果の記録
- 計画（戦略）：目標達成へのステップ分解



エージェント設計

AI エージェント全体のシステムを設計する技術。単にエージェントを作るだけやなく、信頼性・スケーラビリティ・安全性を考慮した設計が求められる

エージェント設計で考慮すべき点

- オーケストレーション：複数のステップをどう管理するか
- エラーハンドリング：失敗したときのリカバリー
- 人間の介入：いつ・どのように人間が関与するか
- 監査ログ：エージェントの行動を追跡可能に
- コスト管理：暴走して大量の API を叩かないように

Gartner によると、レガシーシステムとの統合問題で、2027 年までに Agentic AI プロジェクトの 40% 以上が失敗すると予測されてる。設計段階での考慮が重要や

マルチエージェント

複数の AI エージェントが連携してタスクを実行する仕組み。1 つのエージェントでは難しい複雑なタスクも、専門性を持った複数のエージェントが協力することで解決できる

マルチエージェントのパターン

| パターン       | 説明                                             |
| -------------- | ------------------------------------------------ |
| 階層型         | マネージャーエージェントが他のエージェントに指示 |
| 協調型         | 対等なエージェントが議論して結論を出す           |
| パイプライン型 | 一つのエージェントの出力が次の入力に             |
| 競争型         | 複数のエージェントが競い合って最良の結果を選択   |

現状、エージェント同士の内部連携を実現している企業は、パイロット段階で 30%、本格導入段階で 52% らしい

MCP（Model Context Protocol）

AI が外部ツールと統一された方法で連携するためのプロトコル。Anthropic が 2024 年 11 月に発表し、2025 年 12 月に Linux Foundation に寄贈された

MCP が解決する問題

これまで、各 AI に外部ツールを連携させるには、それぞれ独自の方法で実装する必要があった。ファイル読み込み、API 呼び出し、データベース接続...全部バラバラ。MCP はこれを統一規格にした

MCP の特徴

- Language Server Protocol（LSP）のメッセージフローを再利用
- JSON-RPC 2.0 ベース
- Python と TypeScript の公式 SDK（月間 9700 万ダウンロード以上）
- OpenAI、Google、Microsoft、AWS など主要企業が採用



2025 年 11 月のスペック更新で、非同期操作、ステートレス対応、サーバー ID、公式拡張機能が追加された

A2A（Agent2Agent Protocol）

エージェント同士が安全かつ構造化された形で通信するための仕組み。Google が 2025 年 4 月に発表

MCP と A2A の違い

| 項目 | MCP                  | A2A                    |
| ---- | -------------------- | ---------------------- |
| 役割 | AI とツールの連携    | エージェント同士の連携 |
| 例え | プラグインシステム   | ネットワーク層         |
| 対象 | 1 つの AI を賢くする | 複数の AI を協調させる |

A2A の設計原則

- HTTP、SSE、JSON-RPC など既存標準をベース
- エンタープライズグレードの認証・認可
- 長時間タスクのサポート（数時間〜数日かかる深い調査も可）

150 以上の組織がサポートを表明してて、2025 年 6 月には Linux Foundation に寄贈された。バージョン 0.3 で gRPC サポートも追加されてる

Function Calling

LLM が指定された関数や API を安全に実行できるようにする仕組み。LLM 単体ではできない外部操作（Web 検索、データベース操作、API 呼び出しなど）を可能にする

Function Calling のポイント

- LLM は「どの関数をどの引数で呼ぶべきか」を判断するだけ
- 実際の関数実行はアプリケーション側で行う
- 複数の関数を連続で呼ぶことも可能（並列呼び出しもサポート）


物理 AI（Physical AI）

AI がデジタル空間を超えて、物理世界で直接作業する技術。2026 年は AI がスマホやPCの中だけでなく、現実世界に進出する年になる

物理 AI の具体例

- 自動運転車の普及拡大
- 倉庫での自律ロボット
- 建設現場での作業ロボット
- 医療現場での手術支援ロボット
- ヒューマノイド（人型ロボット）

Tesla の Optimus、Figure 01、Boston Dynamics の Atlas など、ヒューマノイドロボットの開発が加速してる。これらは LLM と組み合わせて自然言語で指示を理解し、物理的な作業を実行できる

物理 AI が重要な理由

- 労働力不足の解決
- 危険な作業の自動化
- 24 時間稼働可能
- 人間では難しい精密作業

エンジニアとしては、ロボット制御のための API や、センサーデータの処理、リアルタイム推論の最適化などが求められるスキルになってくるかもしれん


AI for Science（科学研究 AI）

AI が科学研究のプロセスに能動的に参加する技術。論文を要約するだけやなく、仮説を立て、実験を設計し、発見に貢献する

Microsoft Research の Peter Lee によると、2026 年には AI が物理学、化学、生物学の発見プロセスに参画するようになるらしい

AI for Science の活用例

- 仮説の自動生成
- 実験計画の最適化
- 研究論文の自動分析と関連性発見
- シミュレーションによる検証
- 創薬プロセスの加速

AlphaFold がタンパク質構造予測で革命を起こしたように、AI は科学研究の速度を劇的に上げる可能性がある。2024 年のノーベル化学賞は AlphaFold の開発者に授与された

エンジニアとして意識しておきたいのは、科学計算向けのライブラリ（JAX、PyTorch など）や、大規模シミュレーションの知識。AI と科学の融合は、今後ますます重要になってくるで


評価指標・パフォーマンス：AI の性能を測る

AI システムを本番運用するなら、パフォーマンス指標の理解は必須。ここを押さえておかんと、ユーザー体験の最適化ができない

TTFT（Time To First Token）

最初のトークンが返るまでの時間。ストリーミングレスポンスを使う場合、ユーザーが最初の文字を見るまでの待ち時間

TTFT が重要な理由

ユーザーは「応答が始まるまでの時間」を特に長く感じる。全体のレスポンス時間が同じでも、TTFT が短い方が体感速度は速い

TTFT に影響する要素

- モデルのサイズ
- プロンプトの長さ（コンテキスト処理時間）
- サーバーの負荷状況
- ネットワークレイテンシ

目安として、TTFT が 500ms を超えると「遅い」と感じるユーザーが増える

スループット

単位時間あたりの処理トークン数。サーバー側の処理能力を表す指標

スループットの単位

- tokens/second（1 秒あたりのトークン数）
- requests/minute（1 分あたりのリクエスト数）

スループットを上げる方法

- バッチ処理（複数リクエストをまとめて処理）
- モデルの量子化（精度を落として高速化）
- 推論エンジンの最適化（vLLM、TensorRT-LLM など）
- GPU の増設・分散処理

レイテンシ

リクエストからレスポンスまでの遅延時間。エンドツーエンドの応答時間

レイテンシの構成要素

- ネットワーク遅延（クライアント ↔ サーバー）
- キュー待ち時間
- 推論時間（TTFT + トークン生成時間）
- 後処理時間

P50（中央値）、P95（95 パーセンタイル）、P99（99 パーセンタイル）でレイテンシを計測するのが一般的。平均値だけ見てると、外れ値（異常に遅いリクエスト）を見逃すから注意

ストリーミング

トークンを逐次返す方式。全文が生成されるのを待たずに、生成されたトークンをリアルタイムで返す

ストリーミングのメリット

- ユーザーの体感待ち時間が短い
- 長い回答でも途中で確認できる
- 不要な回答を早期に中断できる

デメリット

- JSON パースなど、完全な応答が必要な場合は使いにくい
- クライアント側の実装が複雑になる


合成コンテンツ（Synthetic Content）

AI が生成したコンテンツの総称。2026 年にはオンラインコンテンツの大部分が AI 生成になると予測されてる

Europol の予測によると、2026 年までにオンラインコンテンツの最大 90% が合成的に生成されたものになる可能性があるらしい。これは良い面と悪い面の両方がある

合成コンテンツのポジティブな活用

- マーケティング素材の大量生成
- パーソナライズされたコンテンツ
- 多言語展開の効率化
- クリエイティブの A/B テスト

問題点（AI スロップ）

- 低品質なコンテンツの氾濫
- 誤情報・フェイクニュースの拡散
- 検索結果の汚染
- 著作権・倫理の問題

「AI スロップ」は、AI が大量生産する質の低いコンテンツを指す俗語。2026 年はこの問題が深刻化すると予測されてて、コンテンツの真偽を見極める能力がますます重要になる

エンジニアとしては、AI 生成コンテンツの検出技術や、コンテンツの信頼性評価システムの構築が求められる場面が増えるかもしれん


まとめ：2026 年の AI トレンドを実務で活かす

ここまで 2026 年に押さえておきたい AI トレンドを深掘りしてきた。最後に、カテゴリごとのポイントをおさらいしておく

基盤層

- LLM は「次のトークンを予測する」シンプルな仕組み
- MoE アーキテクチャで効率化が進んでる
- ワールドモデルが LLM の次として注目されてる

精度向上・知識拡張

- RAG の質は検索の質で決まる
- ハイブリッド検索 + リランキングが 2026 年のベストプラクティス
- ドメイン特化には Embedding のファインチューニングを検討

制御・手法

- プロンプトエンジニアリングからコンテキストエンジニアリングへ
- Few-shot と CoT を組み合わせると精度が上がる
- JSON Mode で構造化出力を確実に

システム・応用

- 2026 年はエージェントが本番環境に入る年
- MCP でツール連携、A2A でエージェント連携
- 物理 AI と AI for Science が現実世界に進出

評価指標

- TTFT はユーザー体験に直結
- ハルシネーション対策は必須
- 合成コンテンツの品質管理が重要に

これらのトレンドを理解しておけば、AI 関連の技術ドキュメントやニュースを読むときに困らんはず。2026 年は AI が「期待」から「実用」へシフトする年。ROI を問われる厳しい年になるけど、だからこそ基礎固めはしっかりしておこう
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Ghostty - 爆速で美しい、次世代ターミナル]]></title>
            <link>http://izanami.dev/post/36f2a88f-48d2-45b5-b0d7-a7dc32e68152</link>
            <guid>http://izanami.dev/post/36f2a88f-48d2-45b5-b0d7-a7dc32e68152</guid><dc:creator>commte</dc:creator>
            <pubDate>Sat, 20 Dec 2025 13:45:32 GMT</pubDate>
            <description><![CDATA[ターミナルって開発者にとって一番長く触れるツールやと思う。だからこそ、ちょっとした引っかかりが積み重なってストレスになるんよね。iTerm2 は高機能やけど重い、Alacritty は速いけど機能が少]]></description>
            <content:encoded><![CDATA[ターミナルって開発者にとって一番長く触れるツールやと思う。だからこそ、ちょっとした引っかかりが積み重なってストレスになるんよね。iTerm2 は高機能やけど重い、Alacritty は速いけど機能が少ない、Warp は AI 搭載で面白いけどネイティブ感がない。どれも一長一短で「これや」っていうのがなかった

そんな中で出会ったのが Ghostty。HashiCorp の共同創業者である Mitchell Hashimoto が個人プロジェクトとして開発したターミナルエミュレータで、2024 年末にバージョン 1.0 がリリースされた。触ってみたら、もう他のターミナルに戻れなくなってしまった

自分の設定

ワイが実際に使っている設定を載せておく



この設定で、透過感のある美しいターミナルが完成する。テーマは tokyonight を使っていて、ダークな背景に程よい透過とぼかしがかかって、作業していて気持ちいい

Ghostty とは何か

Ghostty は、クロスプラットフォーム対応の GPU アクセラレーションターミナルエミュレータ。macOS と Linux で動作して、コアエンジンは Zig 言語で書かれている

Mitchell Hashimoto は 2022 年に Zig 言語の学習とグラフィックスプログラミングの経験を積むためにこのプロジェクトを始めた。当初はリリース予定がなかったものの、開発を進める中で既存のターミナルエミュレータの問題点に気づいて、革新の余地があると感じて公開を決めたらしい

なぜ Ghostty を選ぶのか

Ghostty が他のターミナルエミュレータと一線を画している理由は、3 つの柱がしっかりしているところ

圧倒的なネイティブ感

macOS 版は Swift と AppKit で書かれていて、Linux 版は Zig で GTK4 API を使っている。つまり、プラットフォーム固有の UI コンポーネントをそのまま使っているんよね

macOS では Quick Look、プロキシアイコン、セキュアキーボード入力、入力メソッド（絵文字キーボードや音声入力）など、ネイティブアプリでしか使えない機能がフルに使える。タブやスプリットも OS のネイティブコンポーネントを使っているから、操作感が macOS のアプリそのもの

Electron ベースのターミナルとは根本的に違う。ネイティブ感というのは説明しにくいけど、使えばすぐにわかる

GPU アクセラレーションによる高速レンダリング

macOS では Metal、Linux では OpenGL を使った GPU アクセラレーションを採用している。実際のベンチマークでは、Terminal.app で htop を 10 リフレッシュ/秒で動かすと、Terminal.app 自体が htop より多くの CPU を使ってしまう。Ghostty ではそれが逆転して、htop のほうが CPU を使う。つまり、ターミナル自体がボトルネックにならない

体感でも、大量のログを流したときやビルドログを見ているときの滑らかさが全然違う

豊富な機能と拡張性

- 数百の組み込みテーマを搭載
- ダークモード・ライトモードの自動切り替え
- リガチャ対応
- Kitty グラフィックスプロトコル対応
- ハイパーリンク対応
- カスタムシェーダーサポート
- Grapheme クラスタリング（絵文字やアラビア文字の正しいレンダリング）

xterm のエスケープシーケンスを、xterm 自身を除けば最も多くサポートしているターミナルエミュレータらしい

インストール方法

macOS では Homebrew でサクッと入る



Linux では各ディストリビューション向けのパッケージが用意されている。Arch Linux なら pacman、Fedora なら dnf で入れられる

公式サイトからプリビルドバイナリをダウンロードすることもできるし、ソースからビルドすることも可能。Zig で書かれているから、ビルド環境さえ整えれば自分でビルドするのも難しくない

設定ファイルの基本

Ghostty は「ゼロコンフィギュレーション」の哲学を持っていて、設定ファイルがなくてもデフォルトでいい感じに動く。やけど、カスタマイズしたくなるのが開発者の性やろ

設定ファイルは以下の場所に置く

| プラットフォーム | パス                                                         |
| ---------------- | ------------------------------------------------------------ |
| 共通             |                                    |
| macOS            |  |

両方のファイルが存在する場合は、後者が前者の設定を上書きする。macOS で設定ファイルを開くには、メニューから  を選ぶか、 を押せば OK

設定ファイルの構文はめちゃくちゃシンプル



キーと値を  で繋ぐだけ。引用符はあってもなくてもいい。空行やコメント行は無視される。設定を変更したら （macOS）か （Linux）で即座にリロードできる

便利なコマンド

設定をいじる前に、使えるコマンドを知っておくと便利



特にテーマ一覧は圧巻で、数百のテーマが組み込まれている。自分の好みを探すのが楽しくなるレベル

フォント設定

ターミナルでフォントは超重要。Ghostty では細かくフォントをカスタマイズできる



複数のフォントをフォールバックとして指定することもできる。日本語フォントを使いたいときに便利



同じキーを複数回書くと、フォールバックチェーンとして扱われる。最初のフォントで表示できない文字は、次のフォントで表示される仕組み

テーマと色設定

組み込みテーマを使うのが一番簡単



ダークモードとライトモードで別のテーマを使いたいときはこうする



OS のダークモード設定に連動して自動で切り替わる。これがネイティブ対応の強み

個別に色をカスタマイズすることも可能



透過・ぼかし効果

macOS では背景の透過やぼかし効果を設定できる。これがめっちゃ気持ちいい



透過を設定すると、後ろのウィンドウがうっすら見える。ぼかしを加えると、すりガラスのような効果になる

スプリットを使っているときに、非アクティブなペインを暗くすることもできる



どこにフォーカスがあるか一目でわかるから、複数ペインで作業するときに便利

ウィンドウ設定

ウィンドウの見た目や挙動もカスタマイズできる



macOS 固有の設定

macOS ではプラットフォーム固有の設定がたくさんある



 にすると、タイトルバーとタブバーが一体化してスッキリした見た目になる。スクリーンの縦幅を少しでも稼ぎたいときに最高

Quick Terminal 機能

Ghostty には Quick Terminal という機能がある。これはメニューバーの下からスライドして表示されるターミナルで、iTerm2 の Hotkey Window みたいなもの

設定でグローバルショートカットを割り当てると、どのアプリを使っていてもサッとターミナルを呼び出せる。ちょっとしたコマンドを実行したいときにめちゃくちゃ便利

シェル統合機能

Ghostty のシェル統合機能は、ターミナル体験を大きく向上させる。対応しているシェルは以下の 4 つ

- bash
- zsh
- fish
- elvish

シェル統合が有効になると、こんな機能が使えるようになる

- 新しいタブやスプリットが、前のディレクトリを引き継ぐ
- プロンプト位置で終了確認をスキップ
-  でコマンド出力全体を選択
- プロンプト間をジャンプするキーバインド
-  でプロンプト位置にカーソル移動
- 複雑なプロンプトが正しくリサイズされる

デフォルトで自動的にシェル統合スクリプトが注入されるから、特に設定は不要。ただし、macOS に付属の  は古いバージョンなので自動注入に対応していない。Homebrew で新しい bash を入れる必要がある

明示的に設定したい場合はこう



キーバインド設定

Ghostty のキーバインド設定はかなり柔軟



既存のキーバインドを無効にすることもできる





今後の展望

Ghostty は 2024 年末に 1.0 がリリースされたばかりで、まだまだ進化の途中。Mitchell Hashimoto は 2025 年内に libghostty という独立したライブラリをリリースする予定らしい

libghostty が安定すれば、他のプロジェクトが Ghostty のターミナルエンジンを使って独自のターミナルエミュレータを作れるようになる。Hashimoto 自身は、libghostty が Ghostty プロジェクトで最も有望な部分だと考えているみたい

また、最近 Ghostty は非営利構造に移行して、Hack Club の財政支援を受けることになった。これでプロジェクトの持続可能性と、コミュニティ重視の開発が保証される

まとめ

Ghostty は、速度・機能・ネイティブ UI という 3 つの要素を妥協なく追求したターミナルエミュレータ。HashiCorp の創業者が本気で作っただけあって、完成度がめちゃくちゃ高い

実際に使ってみると、今まで使っていたターミナルの不満点が明確になる。GPU アクセラレーションによる滑らかなスクロール、ネイティブ UI による違和感のない操作感、シェル統合による作業効率の向上。どれも「あって当たり前」と思えるレベルで完成している

まだ 1.0 がリリースされたばかりやけど、すでにメインで使えるクオリティ。macOS か Linux を使っているなら、一度試してみる価値はある。戻れなくなっても責任は取らんけど

参考リンク

- [Ghostty 公式サイト](https://ghostty.org/)
- [Ghostty 1.0 is Coming - Mitchell Hashimoto](https://mitchellh.com/writing/ghostty-is-coming)
- [Ghostty: Reflecting on Reaching 1.0 - Mitchell Hashimoto](https://mitchellh.com/writing/ghostty-1-0-reflection)
- [Ghostty - GitHub](https://github.com/ghostty-org/ghostty)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code と Context7 で脆弱性調査をリアルタイムで行う方法]]></title>
            <link>http://izanami.dev/post/d179ed9f-f373-4207-b77d-1500f7207109</link>
            <guid>http://izanami.dev/post/d179ed9f-f373-4207-b77d-1500f7207109</guid><dc:creator>commte</dc:creator>
            <pubDate>Sun, 07 Dec 2025 22:59:53 GMT</pubDate>
            <description><![CDATA[Context7 とは何ぞや？

いや、何ぞや？って言われても、Context7 は、LLM（大規模言語モデル）に最新のライブラリドキュメントを提供するための MCP サーバーやね

普通に AI に]]></description>
            <content:encoded><![CDATA[Context7 とは何ぞや？

いや、何ぞや？って言われても、Context7 は、LLM（大規模言語モデル）に最新のライブラリドキュメントを提供するための MCP サーバーやね

普通に AI に「React の使い方教えて」って聞くと、学習データの時点での古い情報が返ってきたり、ひどい場合はハルシネーション（でたらめ）が混じったりするやん？

Context7 を使うと、リアルタイムでライブラリの公式ドキュメントやコード例を取得できるから、常に最新の情報に基づいた回答が得られるようになる。これがめっちゃ便利なんよね

MCP（Model Context Protocol）との関係

MCP は Anthropic が策定したオープンプロトコルで、AI アプリケーションと外部データソースやツールを接続するための標準規格

Claude Code はこの MCP をサポートしてて、様々な MCP サーバーを追加することで機能を拡張できる

Context7 はこの MCP サーバーの一つとして提供されてて、Claude Code に組み込むことでドキュメント検索機能が使えるようになるわけ

Claude Code に Context7 を追加する方法

Context7 の導入は簡単で、ターミナルで以下のコマンドを実行するだけよ



どのプロジェクトでも使えるようにしたい場合は、 オプションをつけてユーザースコープで追加する



これでグローバルに Context7 が使えるようになるから、新しいプロジェクトを開くたびに設定し直す必要がなくなる

他のプロジェクトのターミナルで、 を叩いて、以下のように返ってきたら成功



Context7 が提供する 2 つのツール

Context7 MCP は主に 2 つのツールを提供してて、これらを組み合わせて使うことでドキュメント取得ができる

脆弱性調査での活用例

ここからが本題や。Context7 を入れた状態で脆弱性情報を調査すると、めちゃくちゃ便利な結果が返ってくるんよね

ただし、ここで重要なポイントがある。Context7 自体はライブラリのドキュメントを取得するツールであって、CVE データベースを直接検索するものではない。

Claude Code が脆弱性調査をするときは、Context7 でライブラリのセキュリティ関連ドキュメントを取得しつつ、WebSearch で最新のセキュリティ情報を検索するっていう合わせ技を使ってる

例えば、以下のように Claude Code に聞いてみる。語尾に  ってつけるのがポイント



すると、Claude Code が Context7 と WebSearch を組み合わせて、こんな感じの調査結果を返してくれる

実際の調査結果例

こんな感じでかえってくる



CVSS 10.0 っていうのは脆弱性の深刻度としては最高レベルで、認証なしでリモートコード実行ができるっていうのは本当にやばい状況やな

これ、意外と Next.js だけアップデートして、React をアップデートしてない人、いるんじゃないかな？

プロジェクトの依存関係との照合

さらに便利なのは、Claude Code が現在のプロジェクトの  を読んで、実際に影響を受けるかどうかを判断してくれるところや



こうやって「お前のプロジェクト、ここが危ないで」って具体的に教えてくれるから、対応が楽になるんよね

即座にアップデートを実行

調査結果を見て「やばい」と思ったら、そのまま Claude Code にアップデートを頼める



調査から対応まで、全部 Claude Code の中で完結するのがポイントや。ブラウザで検索して、npm のサイト見て、コマンド打って...みたいな手間が全部なくなる

自動で Context7 を使う設定

毎回「use context7」って書くのが面倒な場合は、CLAUDE.md にルールを追加しておくと自動で使ってくれるようになる



これを書いておけば、コード生成やドキュメント取得が必要なときに自動で Context7 を使ってくれるから便利やな

Context7 のメリットをまとめると

Context7 を Claude Code に組み込むことで得られるメリットは結構大きい

- 最新のドキュメントに基づいた回答が得られる
- ハルシネーションのリスクが減る
- WebSearch と組み合わせて脆弱性情報などの時間に敏感な情報を即座に取得できる
- プロジェクトの状況と照らし合わせた具体的なアドバイスがもらえる
- 調査から対応までシームレスに実行できる

特にセキュリティ関連の調査では、古い情報に基づいて判断すると危険なことがあるから、リアルタイムで最新情報を取得できるのは本当に助かるんよね

無料プランの制限について

Context7 には無料プランがあるけど、いくつか制限がある

- 1 日あたりのリクエスト数に上限がある
- プライベートリポジトリは使えない
- メトリクスは 24 時間でリセットされる

ただ、個人開発で使う分には無料プランでも十分やと思う。プロジェクトで本格的に使う場合は Pro プランを検討するとええかもしれん

Context7 以外の選択肢

MCP サーバーは Context7 以外にもいろいろある。例えば

- Playwright MCP: ブラウザ操作の自動化
- Docker MCP: コンテナ操作
- GitHub MCP: GitHub 連携

Claude Code の拡張性は MCP によってかなり高くなってるから、自分のワークフローに合わせて必要なものを追加していくとええと思う

まとめ

Claude Code に Context7 を入れると、脆弱性調査がめっちゃ効率的になるっていう話やった

従来やったら、脆弱性情報をネットで検索して、影響範囲を確認して、対応方法を調べて、コマンド実行して...っていう一連の流れを手動でやる必要があった。Context7 を使えば「この脆弱性について調べて」って聞くだけで、最新情報の取得からプロジェクトへの影響確認、対応の実行まで全部やってくれる

特にゼロデイ脆弱性とか、最新の CVE が出たときは、AI の学習データに含まれてない可能性が高いから、Context7 と WebSearch を組み合わせたリアルタイム情報取得の仕組みがあると安心やな

セキュリティ対応は時間との勝負なところがあるから、こういうツールを活用して効率化していくのは大事やと思う]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Antigravity + Gemini 3 Pro のデザイン再現率をさらに引き上げるコツ]]></title>
            <link>http://izanami.dev/post/525d3b7b-d2c5-40c8-bd99-1d5bcb29e548</link>
            <guid>http://izanami.dev/post/525d3b7b-d2c5-40c8-bd99-1d5bcb29e548</guid><dc:creator>commte</dc:creator>
            <pubDate>Sat, 06 Dec 2025 17:39:37 GMT</pubDate>
            <description><![CDATA[有料プラン契約して、ガンガン回した結果、Antigravity + Gemini 3 Pro のデザイン再現率をさらに引き上げるコツを掴んだぜぃ

ポイントはこれ

- セクション単位で狭く切り出して]]></description>
            <content:encoded><![CDATA[有料プラン契約して、ガンガン回した結果、Antigravity + Gemini 3 Pro のデザイン再現率をさらに引き上げるコツを掴んだぜぃ

ポイントはこれ

- セクション単位で狭く切り出して画像を見せる
- 既存のコードとクラス設計を読み込ませた状態で生成させる
- 細かい修正指示を反復で伝える
- 80 点を生成させた後に、細かいフィードバックを出す

だいたい、これやればデザインの精度がバク上がりする

でも、無料やと、すぐにレートリミットや！

なんで、個人アカウントに切り替えて、Google AI Pro（月額 2,900 円） を契約するといい

https://one.google.com/intl/jajp/about/google-ai-plans/

Workspace アカウントは、Google AI Pro の契約ができないからね

Antigravity だけ使うなら Pro で十分。エージェントモデルのレート制限も引き上がるからね

結論から言うと、セクション単位で切り出すのが最強

再現したい UI を「全画面で渡す」のではなく、セクション単位で狭く切り出してアップロードすると精度が跳ね上がる

なんでかというと、余計な情報に引っ張られなくなるぶん、余白の取り方、フォントの太さ、階層構造、要素の重なりなどをピクセル感覚で読み取ってくれるから

「ここを見て!」と切り出すことで、モデルの視覚的な解像度が上がり、余白のピクセル感、フォントのウエイト、微細なシャドウや角丸の R（半径）まで正確に認識できるようになるんよ

Gemini 3 Pro のマルチモーダル読み取りはかなり優秀で、明示的に指定してなくても余白やヒエラルキーを尊重してくれる。旧世代のモデルより「見る」能力が格段に上がってるんよね

Antigravity ってそもそも何なん?

Antigravity は Google が作ったエージェント主導の開発プラットフォーム。ベースには世界で最も使われている VS Code が採用されていて、そこに Google の最新 AI モデル Gemini 3 が組み込まれてる

https://izanami.dev/post/a803b898-b8d8-4fc3-93c1-9d9c336658b5

特徴的なのは、AI エージェントがエディタ、ターミナル、ブラウザに直接アクセスできる点。エージェントが自律的に計画を立てて、複雑なエンドツーエンドのソフトウェアタスクを同時に実行しながら、自分自身でコードを検証してくれるんよ

VS Code での初期テストでは、Gemini 3 Pro は Gemini 2.5 Pro と比較してソフトウェアエンジニアリングの課題解決精度が 35% 向上したらしい

Antigravity は現在パブリックプレビュー中で、MacOS、Windows、Linux で無料で使える。5 時間ごとにリフレッシュされるレート制限はあるけど、Gemini 3 Pro だけでなく、Anthropic の Claude Opus 4.5 や OpenAI の GPT-OSS も使えるようになってる

既存のコードを読み込ませると精度が爆上がりする

既存のコードとクラス設計を読み込ませた状態で生成させると、サイト全体のトーン & マナーを壊さずに実装してくれる

Tailwind や CSS を整理しておくほど、それを吸収して一貫性のあるコードを出力してくれるんよね

具体的には「既存の Tailwind config を使って」とか「Button.tsx の props を再利用して」みたいな制約を追加すると、新しいコンポーネントを発明するんじゃなくて、既存のコードベースにきちんと馴染んでくれる

微調整を諦めないのが最強のアプローチ

角丸の数値、間隔、配置位置などの細かい修正指示を反復で伝えるほど、理想形に収束していく

一発で 100 点を目指すよりも、「80 点の構造」を出した後に、「角丸をもっと小さく」「左寄せに」といった具体的なフィードバックを出す方が、結果的に最速で 120 点のクオリティ（理想以上）に到達するんよ

Antigravity の特徴として、実装計画にコメントを追加できて、AI エージェントがそのフィードバックを認識して計画を更新する機能がある。この反復的なアプローチにより、開発初期段階での仕様調整がめっちゃ容易になってる

Antigravity に聞いてみたら正解やった

上記の方法が正しいか Antigravity 自身に聞いてみたところ、完全に合ってるとのこと

これは経験則だけじゃなくて、ツールの設計思想ともマッチしてるってことやね

具体的なワークフロー

画面の切り替えを覚えよう

Antigravity では主に「Agent Manager」と「Editor」の 2 つの画面を  で切り替えて作業する

- Agent Manager: エージェントの実行状況、タスク、権限確認などの管理画面
- Editor: コードを書いたり、ファイルを編集したりする開発画面

Planning モードと Fast モードを使い分ける

Conversation Mode では 2 つのモードを切り替えられる

- Planning: 複雑なタスクや調査、共同作業向け。実行前に計画を立ててくれる
- Fast: シンプルなタスク向け。直接タスクを実行して素早く完了させる

デザイン再現のように精度が求められる作業は Planning モードで計画を立ててからやると、失敗が少なくなるよ

ブラウザ連携で視覚的フィードバックを得る

専用の Antigravity Browser Extension を Chrome にインストールすると、エージェントによる視覚的フィードバックや UI 修正が可能になる

Chrome 上でアプリが起動して、修正していく様子をリアルタイムで確認できるんよ。View をクリックすると AI が実施した実際の動作確認のキャプチャを見ることができて、このキャプチャは Artifact として保存されてる

日本語設定のやり方

Agent パネル右上の「...」から「Customizations → Rules → +Global」で「日本語で回答してください」と設定すると、日本語でやり取りできるようになる

プロンプトも日本語で OK。「シンプルな ToDo リストアプリを作って。デザインはモダンでおしゃれにして。完成したらブラウザで動作確認までして。」みたいな指示で、必要なファイル（HTML/CSS/JS）を作成してくれる

画像生成機能も使える

Antigravity には NanoBanana（Gemini 3 Pro Image）による画像生成機能も統合されてる

UI モックアップ生成はデザイン段階でのフィードバックやコード生成前の確認にめっちゃ有効。ウェブサイト向けの画像アセット生成では、ストック画像を探す代わりに直接適した素材を生成できるんよ

他の AI IDE だと、こういう画像生成は MCP への接続みたいなワークアラウンドが必要やけど、Antigravity は直接使えるのが強み

Figma との連携も進んでる

Figma Make では Gemini 3.0 をモデルとして選択できるようになってる

フロントエンド開発者は Figma のワイヤーフレームをクリーンな HTML/CSS に変換できる。Rube がデザインをフェッチして、Antigravity が UI コードを生成するワークフローが可能やねん

Gemini 3 Pro は Figma Make において、デザインを精密に変換して、幅広いスタイル、レイアウト、インタラクションを生成する強力な基盤として機能してる

効果的な使い方のまとめ

- セクション単位で切り出す: 全画面じゃなくて、再現したい部分だけを狭く切り出してアップロード
- 既存コードを読み込ませる: Tailwind config や既存コンポーネントの props を参照させて一貫性を保つ
- 制約を明示する: 「既存の Tailwind config を使って」「Button.tsx の props を再利用して」みたいに具体的に指示
- 反復で微調整する: 一発で完璧を目指すより、80 点の構造を出してから具体的なフィードバックで詰める
- Planning モードを活用: 精度が求められる作業は計画を立ててから実行
- ブラウザ連携を使う: リアルタイムで視覚的なフィードバックを得て修正

他の AI IDE との違い

Cursor や Windsurf みたいな AI IDE と比較して、Antigravity の特徴的な点は

- エージェントが主役: AI が補助ツールじゃなくて、開発プロセス全体を主導する
- ブラウザ直接操作: エージェントがブラウザを操作して動作確認まで自動化
- 画像生成統合: NanoBanana による画像生成が直接使える
- 計画へのフィードバック: 実装計画にコメントを追加して、AI が認識・更新してくれる

Google AI Studio、Vertex AI、Gemini CLI でも Gemini 3 を使えるし、Cursor、GitHub、JetBrains、Manus、Replit といったサードパーティプラットフォームでも利用可能になってる

プロンプトのコツ

Google が公式に推奨してるデザイン関連のプロンプト設計のポイント

> Make a design that feels premium and state of the art. Avoid creating simple minimum viable products. Don't use placeholders. If you need an image, use your generateimage tool to create a working demonstration.

つまり「プレミアム感のあるデザインを作って。シンプルな MVP は避けて。プレースホルダーは使わないで。画像が必要なら generateimage ツールで実際の素材を作って」という感じ

システマチックなアプローチとしては

- Plan and Understand: ユーザー要件を完全に理解して、モダンなデザインからインスピレーションを得る
- Build the Foundation: CSS の作成・修正から始めて、コアデザインシステムを実装
- Create Components: デザインシステムを使って、フォーカスされた再利用可能なコンポーネントを構築
- Assemble Pages: 適切なルーティングとレスポンシブレイアウトでデザインを組み込む
- Polish and Optimize: 仕上げと最適化

この流れで進めると、構造化されたアプローチでデザイン再現の精度が上がるよ

Rules で一貫性を保つ

Antigravity では Rules という機能でエージェントの行動指針を設定できる

コードスタイルを統一したい、常にメソッドをドキュメント化したい、みたいなガイドラインを追加しておくと、エージェントがそれを考慮してコードを生成・テストしてくれる

デザイン再現においても、「角丸は常に 8px」「余白は 4 の倍数」みたいなルールを設定しておくと、毎回指示しなくても一貫性のある出力が得られるようになるんよ

まとめ

Antigravity + Gemini 3 Pro でデザイン再現率を上げるポイントは

- 全画面じゃなくてセクション単位で切り出す
- 既存のコードとクラス設計を読み込ませる
- 微調整を諦めずに反復で指示する
- 一発で 100 点より、80 点から詰める方が速い

AI IDE の使い方って、「どうやって効率よく指示を出すか」がめっちゃ重要。Antigravity は特にその辺の設計がうまくできてて、反復的なフィードバックを前提としたワークフローになってる

有料プランで制限なくガンガン回せる環境があると、この「反復」の部分が圧倒的に楽になるから、本気でデザイン再現に取り組むなら投資する価値はあると思うよ
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[dotenvx で .env ファイルを安全に共有する方法]]></title>
            <link>http://izanami.dev/post/59b95a54-77b2-42e0-9721-b457f1527b12</link>
            <guid>http://izanami.dev/post/59b95a54-77b2-42e0-9721-b457f1527b12</guid><dc:creator>commte</dc:creator>
            <pubDate>Wed, 03 Dec 2025 18:35:52 GMT</pubDate>
            <description><![CDATA[チーム開発やってると、必ずぶつかる壁がある。それが「.env ファイルどうやって共有する問題」よね

Slack で送る？ Notion に貼る？ 1Password で管理する？どれも一長一短で、結]]></description>
            <content:encoded><![CDATA[チーム開発やってると、必ずぶつかる壁がある。それが「.env ファイルどうやって共有する問題」よね

Slack で送る？ Notion に貼る？ 1Password で管理する？どれも一長一短で、結局「安全性」と「手軽さ」のバランスが難しい。特に新しくプロジェクトに参加したメンバーに環境変数を渡すとき、めっちゃ気を使うんよな

そこで便利なのが dotenvx というツール。これ、あの有名な dotenv の作者が作った後継ツールで、.env ファイルを暗号化したまま Git にコミットできるっていう、なかなか画期的なやつよ

dotenvx ってなに？

dotenvx は、環境変数を安全に管理するためのツール。従来の dotenv は単純に .env ファイルを読み込むだけやったけど、dotenvx は暗号化機能が標準搭載されてる

https://dotenvx.com/

仕組みとしては、公開鍵暗号方式を採用してる。具体的には、各シークレットを AES-256 で暗号化して、その暗号鍵を Secp256k1 という楕円曲線暗号（Bitcoin と同じアルゴリズム）で保護する二重構造になってる。めっちゃ堅牢やな

dotenvx の特徴をざっくりまとめると、こんな感じになる

- .env ファイルを暗号化して Git にコミットできる
- 公開鍵で暗号化、秘密鍵で復号という仕組み
- 複数環境（development、production など）に対応
- 実行時に自動で復号してくれる

PayPal、NASA、Supabase、AWS なんかも採用してるらしく、週間 100 万回以上インストールされてる人気ツールやな

インストール方法

Mac なら Homebrew で一発インストールできる



npm でもインストールできるから、Node.js 環境なら  でもいける。Windows の場合は npm 経由が無難かな

暗号化の仕組みを理解しよう

dotenvx の暗号化は、2 つの鍵を使う仕組みになってる

- DOTENVPUBLICKEY（公開鍵）：.env ファイルの先頭に配置される。チーム全員が使える暗号化用の鍵
- DOTENVPRIVATEKEY（秘密鍵）：.env.keys ファイルに保存される。復号化に必要な鍵

公開鍵はその名の通り公開しても問題ない。Git にコミットしても大丈夫。でも秘密鍵は絶対にコミットしたら駄目やん。これを漏らしたら全部のシークレットが見られてしまう

この仕組みのいいところは、暗号化された .env ファイルが万が一漏れても、秘密鍵がなければ復号できないこと。セキュリティ的にかなり安心できるよね

実際の運用フロー（管理者編）

まず、プロジェクトの管理者がやることを説明するね

最初に既存の .env.local を開発用の .env.dev にコピーする。なんで .env.dev にするかというと、環境ごとに分けて管理したいから。本番用なら .env.production、ステージング用なら .env.staging みたいに分けられる



次に、この .env.dev を暗号化する



このコマンドを実行すると、.env.dev の中身が暗号化される。元の内容がこんな感じだったとする



暗号化後はこうなる



見ての通り、各値が encrypted: というプレフィックス付きの暗号文に置き換わってる。元の値は完全に隠されてるから、このファイルを Git にコミットしても安全やな

同時に .env.keys というファイルも生成される。これが秘密鍵を格納するファイル



:::warning
.env.keys は絶対に Git にコミットしたら駄目。.gitignore に追加しておくこと
:::

.gitignore にはこんな感じで追加しておこう



ここまでできたら、暗号化された .env.dev を Git にコミットする



最後に、.env.keys の中身（秘密鍵）だけを共同開発者に安全な方法で共有する。1Password Environments 、直接会って伝えるなど、セキュアな経路で渡すのが大事

実際の運用フロー（共同開発者編）

次に、共同開発者側の手順を説明するね

まず、管理者から受け取った秘密鍵を .env.keys ファイルに保存する。プロジェクトのルートディレクトリに .env.keys を作成して、秘密鍵を貼り付ける



次に、Git からクローンしてきた暗号化済みの .env.dev を .env.local にコピーする



最後に、復号化コマンドを実行する



これで .env.local が復号化されて、元の環境変数が使えるようになる。めっちゃ簡単やな

:::info
復号化には .env.keys に正しい秘密鍵が必要。秘密鍵がないと復号できない仕組みになってる
:::

複数環境を管理する場合

本番環境とか、ステージング環境とか、複数の環境を管理したい場合も dotenvx で対応できる

例えば、こんな構成で管理できる

- .env.dev - 開発環境
- .env.staging - ステージング環境
- .env.production - 本番環境

それぞれ個別に暗号化する



暗号化すると、.env.keys にはそれぞれの環境用の秘密鍵が追加される



本番環境の秘密鍵は、本番にアクセスできる人だけに共有するとか、環境ごとにアクセス制御できるのがいいよね

実行時に自動で復号する方法

dotenvx run コマンドを使えば、復号化しなくても暗号化されたままアプリを実行できる



このコマンドは .env.keys から秘密鍵を読み込んで、実行時に自動で復号してくれる。.env.local を復号化した状態で保存しなくていいから、よりセキュアな運用ができるな

本番環境では、環境変数として秘密鍵を設定しておけば同様に動作する



よくある質問と注意点

暗号化された .env を間違ってコミットしても大丈夫なん？という疑問があると思う

答えは「大丈夫」。暗号化されてるから、秘密鍵がなければ復号できない。むしろ、暗号化された状態でコミットするのが dotenvx の正しい使い方やな

.env.keys を間違ってコミットしたらどうする？これはヤバい。すぐに以下の対応が必要になる

- Git の履歴から削除する（git filter-branch や BFG Repo-Cleaner を使う）
- 新しい鍵で再暗号化する
- 影響を受けた環境変数（API キーなど）をすべてローテーションする

だから .gitignore の設定は最初にちゃんとやっておこう

既存の .env に新しい変数を追加したい場合はどうする？暗号化された .env ファイルに変数を追加するには、一度復号化してから変数を追加して、再度暗号化すればいい



もしくは dotenvx set コマンドで直接追加することもできる



従来の方法との比較

dotenvx を使わない従来の方法と比較してみよう

Slack や DM で .env を送る方法は、履歴が残るし、転送されるリスクもある。退職者のアカウントに残ってたりするとセキュリティ的に問題やな

1Password などのパスワードマネージャーで管理する方法は、セキュアやけど、毎回コピペするのが面倒。環境変数が多いと特にしんどい

Notion やドキュメントで管理する方法は、検索しやすいけど、アクセス権限の管理が大変。退職時の対応も面倒

dotenvx の方法は、Git で管理できるから変更履歴も追えるし、秘密鍵だけ管理すればいいからシンプル。新しいメンバーにも秘密鍵を渡すだけで環境構築完了するのがいいよな

セキュリティのベストプラクティス

dotenvx を使う上でのセキュリティベストプラクティスをまとめておく

秘密鍵の管理について。.env.keys は絶対に Git にコミットしない。秘密鍵の共有は安全な経路（1Password、対面など）で行う。定期的に鍵をローテーションすることも検討する

環境の分離について。本番環境の秘密鍵は限られたメンバーだけに共有する。開発環境と本番環境の鍵は別々に管理する。CI/CD では環境変数として秘密鍵を設定する

監査について。誰が秘密鍵を持っているか把握しておく。メンバーの退職時は鍵のローテーションを検討する。不要になった環境の鍵は削除する

CI/CD での使い方

GitHub Actions などの CI/CD 環境で使う場合は、秘密鍵を Secrets として設定しておく



この設定なら、暗号化された .env.production を使いながら、安全にビルドできる

トラブルシューティング

復号化できない場合は、まず秘密鍵が正しいか確認しよう。.env.keys のキー名が環境に対応しているか（.env.dev なら DOTENVPRIVATEKEYDEV）もチェックする

暗号化コマンドがエラーになる場合は、dotenvx のバージョンを確認する。brew upgrade dotenvx で最新版にアップデートしてみるのもいい

ファイルが見つからないエラーが出る場合は、-f オプションで指定したファイルパスが正しいか確認する。相対パスと絶対パスの違いに注意やな

まとめ

dotenvx を使えば、.env ファイルの共有問題がかなりスッキリ解決する

- 暗号化された .env を Git にコミットできる
- 秘密鍵だけを安全に共有すればいい
- 複数環境も柔軟に管理できる
- 実行時に自動復号もできる

チーム開発での環境変数管理に悩んでるなら、一度試してみる価値あると思うな。従来の方法より圧倒的にシンプルで安全やから

特に新しいメンバーが参加したときの環境構築が楽になるのがいい。「.env.keys の中身送るから、あとはコマンド叩くだけ」で済むのは、めっちゃ効率的よな
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Google Antigravity を分かりやすく解説する]]></title>
            <link>http://izanami.dev/post/a803b898-b8d8-4fc3-93c1-9d9c336658b5</link>
            <guid>http://izanami.dev/post/a803b898-b8d8-4fc3-93c1-9d9c336658b5</guid><dc:creator>commte</dc:creator>
            <pubDate>Wed, 19 Nov 2025 12:45:58 GMT</pubDate>
            <description><![CDATA[Google が 2025 年 11 月 18 日に発表した次世代 IDE「Antigravity」を調べてみた。まず、個人向けプランが無料で使えるのがまず嬉しい

https://antigravi]]></description>
            <content:encoded><![CDATA[Google が 2025 年 11 月 18 日に発表した次世代 IDE「Antigravity」を調べてみた。まず、個人向けプランが無料で使えるのがまず嬉しい

https://antigravity.google

これは単なる「AI 搭載 IDE」じゃなく、Google が本気で開発体験そのものを再定義しようとしてる製品

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/9ab999d0-3e73-4243-b6b1-15830c651de7.png)

Cursor からインポートできるのは嬉しい

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/2cfe9a3f-25fb-4f5a-b4da-70c3cb865b9f.png)

テーマカラーにTokyo Night がある

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/17d3c7fa-c982-48ec-8d37-bd76b98c15e0.png)

右から、3 dotsをクリックすると MCP サーバーを選択できる

Google Antigravity とは何か

Antigravity は、Google が発表した次世代 AI IDE やけど、VS Code の延長線上にあるエディタとは根本的に違う

これは「エディタ」というより「開発 OS」に近い概念なんよね

従来の IDE は、エディタがあって、そこに AI を足すという発想やった

VS Code に Copilot を追加する、みたいな感じ

でも Antigravity は逆なんよ

AI エージェントが中心にあって、それを補助する UI としてエディタ、ブラウザ、ターミナルが存在するという構造

この「Agent-first」という思想が、Antigravity の本質

X で、要点だけ解説した

https://x.com/commte/status/1990980213321445529

Agent-first IDE という新しい概念

Antigravity 自身が「AI IDE」ではなく「Agent-first experience」と表現してる点が重要

これまでの開発環境は、人間がコードを書いて、AI が補完や提案をするという役割分担だった。でも Antigravity では、AI エージェントが開発ワークフローそのものを代理実行する

具体的には、こんな感じ

1. 人間が「ユーザー認証機能を実装して」と指示する
2. エージェントがコードを生成する
3. エージェントがテストを実行する
4. ブラウザで UI を確認してスクリーンショットを撮る
5. 問題があれば修正する
6. 最終的な成果物と検証結果をまとめて提示する

このすべてをエージェントが自動でやってくれるんよね

人間は「何を作りたいか」を指示するだけで、「どう作るか」の細かい実装はエージェントに任せられる

これが Agent-first の世界

エージェントが横断的に制御する 3 つの領域

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/9250ae51-3adb-4133-bbee-6adc79f1d0e0.webp)

Agetとコード編集画面とターミナル

Antigravity で特に注目されてるのが、エージェントがエディタ、ターミナル、ブラウザの 3 つを横断的に制御できる点

これを Google は「クロスサーフェス制御」と呼んでる

例えば、こんなワークフローが自動化できる

1. エディタでコンポーネントを生成する
2. ターミナルでテストを実行する
3. ブラウザで UI をレンダリングして表示を確認する
4. 問題があればエディタに戻って修正する
5. 再度テストとブラウザ確認を実行する

このサイクルを、エージェントが自動で回してくれる

従来の IDE では、エディタ内での操作が中心で、ターミナルやブラウザは別の領域として扱われてた

でも Antigravity では、この 3 つが完全に統合されてる

エージェントが「開発行為そのもの」をハンドルするから、領域を跨いだ操作が自然にできるわけやな

タスクベースの UI

Antigravity では、開発行為が「タスク」として視覚化される

エージェントの動作が、以下のような形で UI に表示される

- タスクの内容（何をしているか）
- 生成されたアーティファクト（成果物）
- 検証結果（テストやログ）

これによって、エージェントが今何をしているか、どういう成果物を生成したか、検証はどうだったかが一目で分かる

従来の IDE だと、AI がコードを生成しても、それがちゃんと動くかは自分でテストして確認する必要があった

でも Antigravity では、エージェントが検証まで含めてやってくれて、その結果がタスクとしてまとめられる

これによって、開発の途中経過や成果が常に可視化されるから、プロジェクトの進行状況が把握しやすくなるんよね

Mission Control で複数エージェントを管理

Antigravity には「Agent Manager」という概念があって、これを Google は「Mission Control」と表現してる

複数のエージェントを同時に並行してタスクを進められる

例えば、こんな使い方ができる

- エージェント A にはフロントエンドの実装を任せる
- エージェント B にはバックエンドの API 開発を任せる
- エージェント C にはテストコードの作成を任せる

この 3 つのエージェントが同時に動いて、それぞれのタスクを進める

Mission Control で全体の進行状況を監視しながら、必要に応じてエージェントを切り替えたり、タスクを再割り当てしたりできる

これは VSCode にはない概念

従来の IDE では、AI は単一のアシスタントとして機能してたけど、Antigravity では複数のエージェントを並行して動かせる

大規模なプロジェクトや、複雑な開発タスクでは、この並列処理がめちゃくちゃ効いてくるよ

エージェントと共同で作るための機能

Antigravity は「エージェントと共同で開発する」ことを前提に設計されてる

そのための機能が、めちゃくちゃ充実してるんよね

1. Artifacts

エージェントが生成した成果物（コード、ドキュメント、設定ファイルなど）を一元管理できる

生成されたファイルごとに、どのエージェントが、どのタスクで作ったかが記録されるから、後から追跡しやすい

2. Task Groups

タスクを階層化して管理できる機能やな

大きなタスクを小さなサブタスクに分割して、エージェントに割り当てられる

例えば「ユーザー認証機能の実装」という大タスクを、「フロントエンド UI」「バックエンド API」「テストコード」という 3 つのサブタスクに分けて、それぞれ別のエージェントに任せられる

3. Knowledge

会話の履歴からエージェントが学習して、プロジェクト固有の知識を蓄積していく

例えば、「このプロジェクトでは認証に Supabase を使う」という情報を一度教えれば、次回以降は自動でその知識を活用してくれる

4. User Feedback

エージェントが生成した Artifacts にコメントを付けて、誘導できるんよね

「この部分はもっとシンプルにして」とか「ここにエラーハンドリングを追加して」みたいに、具体的な指示を出せる

エージェントはそのフィードバックを受けて、成果物を改善していく

この 4 つの機能が組み合わさることで、エージェントと人間が本当に共同で開発できる環境が実現されてる

エージェントの設定オプション

Antigravity では、エージェントの動作を細かく設定できる

まず、エージェントのモードを選べるんよね

- Planning モード（熟考）
- Fast モード（即実行）

の 2 種類

Planning モードは、タスクを受け取ったら、まず実装プランを立てて、それを人間に提示する。人間がプランを確認して OK を出したら、エージェントが実装を開始する。慎重に進めたいタスクや、複雑なタスクに向いてる

Fast モードは、タスクを受け取ったら、すぐに実装を開始する。プランの確認をスキップして、スピード重視で進める。簡単なタスクや、反復的なタスクに向いてるな

また、Artifact Review Policy という設定で、実装プランの扱い方を選べる

Always Proceed（常に自動進行）

エージェントが生成した実装プランを、人間の確認なしで自動的に実行していく

スピード重視で、エージェントに全面的に任せたい場合に使う

Agent Decides（エージェントが判断）

エージェントが状況に応じて、レビューが必要かどうかを判断する

複雑なタスクや重要な変更の場合はレビューを求めて、簡単なタスクは自動進行する

Request Review（毎回レビュー）

すべての実装プランで、人間の承認を求める

慎重に進めたいプロジェクトや、学習目的で使う場合に向いてる

ターミナルの自動実行も、Off / Auto / Turbo の 3 段階で制御できる

- Off は、ターミナルコマンドを実行する前に必ず確認を求める
- Auto は、安全なコマンドは自動実行して、危険なコマンドだけ確認する
- Turbo は、すべてのコマンドを自動実行する

さらに、ワークスペース外のファイルにアクセスするかどうかも設定できる

プロジェクトのディレクトリ外にあるファイルを読み書きする必要がある場合は、許可を出せる

セキュリティを重視する場合は、ワークスペース内に制限できる

こうした細かい設定で、プロジェクトの性質やリスク許容度に合わせて、エージェントの動作をカスタマイズできるんよね

Browser Subagent の強力な機能

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/0a09221b-e594-4481-a069-ea88212194ea.png)

Browser Subagent を使うためのオンボーディング画面

Antigravity の Browser Subagent が、めちゃくちゃ強力

人間がブラウザでやる操作を、全部 AI が代行できるんよね

具体的には、こんなことができる

- クリック操作（ボタン、リンク、フォーム要素など、あらゆる要素をクリックできる）
- スクロール操作（ページを上下左右にスクロールして、画面外の要素にアクセスできる）
- 入力操作（テキストフィールドに文字を入力したり、ドロップダウンから選択したりできる）
- DOM の読み取り（ページの HTML 構造を解析して、必要な情報を抽出できる）
- コンソールログの取得（ブラウザのコンソールに出力されたログやエラーメッセージを取得できる）
- スクリーンショットと動画の撮影（ページの表示状態をスクショで記録したり、操作の流れを動画で撮影したりできる）

これによって、例えばこんなワークフローが自動化できる

1. エージェントがフォームのコンポーネントを実装する
2. Browser Subagent がブラウザを開いてページをレンダリングする
3. フォームに実際にデータを入力して、送信ボタンをクリックする
4. 送信後の画面遷移を確認して、スクショを撮る
5. コンソールにエラーが出てないかチェックする
6. 問題があれば、エディタに戻ってコードを修正する

このサイクルを、人間が介入せずに自動で回せるんよね

従来の開発では、UI の動作確認は人間が手動でやるしかなかった

でも Antigravity では、Browser Subagent がその作業を代行してくれるから、開発スピードが段違いに上がる

特に、E2E テストのような反復的な確認作業では、この自動化がめちゃくちゃ効いてくるよ

Browser Subagent の動作中は、ブラウザ画面が青枠で囲まれる

これは「AI が操作中だから、人間は触らないで」という合図やな

青枠が表示されてる間は、人間が操作できないようになってる

さらに、裏タブ（バックグラウンドタブ）の操作もできる

画面に表示されてないタブでも、Browser Subagent はバックグラウンドで勝手に動いて、操作や検証を進められるんよね

これによって、複数のページを同時に確認したり、バックグラウンドで API のテストを回しながら UI の操作を続けたりできる

VS Code との違い

Antigravity は VS Code のフォークやけど、根本的な思想が違う

VS Code は「エディタ」としてスタートして、そこに拡張機能として AI を追加していった

でも Antigravity は「AI エージェント」が中心で、エディタはあくまで補助的な UI という位置づけ

この違いが、開発体験に大きな影響を与える

VS Code では、人間がコードを書いて、AI が補完や提案をする

Antigravity では、エージェントがタスクを実行して、人間は指示と監視をする

つまり、役割が逆転してるんよね

また、Antigravity は Google のエコシステムと深く統合されてる

Chrome ブラウザを持ってるから、ブラウザとの連携が非常にスムーズ

ターミナルも制御できるから、開発ワークフロー全体を一つのプラットフォームで完結できる

これは VS Code 単体では実現が難しい世界観やな

無料プランの破壊力

Antigravity の無料プラン（Individual plan）がめちゃくちゃ強力

https://antigravity.google/pricing

無料で使える AI モデルが、これ

- Gemini 3 Pro（high / low の 2 バージョン）
- Claude Sonnet 4.5（通常版と thinking 版）
- GPT-OSS（Google が提供するオープンソース系モデル群）

モデルは会話ごとに選択できるけど、一度選んだら sticky（固定）になる仕組み

途中で別のモデルに切り替えても、そのターンの処理が終わるまでは前のモデルを使い続けるんよね

さらに、ユーザーが直接選べないけど、内部的に使われる専用モデルもある

- Nano banana（UI モック生成、画像生成）
- Gemini 2.5 Pro UI Checkpoint（ブラウザ操作のクリック等）
- Gemini 2.5 Flash（チェックポイントや要約）
- Gemini 2.5 Flash Lite（コード検索）

これらのモデルが、シーンに応じて自動で使い分けられるから、最適なパフォーマンスが出るようになってる

しかも、以下の機能が無制限

- 無制限のタブ補完
- 無制限のコマンド実行（AI アクション）
- 寛容なレートリミット

つまり、VS Code + Copilot を超えるレベルの環境が、完全無料で使えるってこと

Copilot は月額 10 ドルかかるけど、Antigravity は無料で複数のモデルが使い放題

しかもレートリミットも緩いから、実質的に制限なく使える

これは個人開発者にとって破壊的なプランやな

Google アカウントさえあれば、すぐに最新の AI IDE 環境が手に入る

この無料プランの強さが、Antigravity が注目されてる理由の一つやね

レートリミット

私の環境では、数時間ほどぶん回すと、モデルの制限がかかる。今のところ、この制限の上限を伸ばす方法はなさそうである

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/fb108034-0e3a-41b4-9484-6744a07be5ce/491dd2a6-3d49-4dfd-9634-22bf09bc3e59.png)

モデルに制限がかかっている

Windsurf チーム買収の背景

実は、Google は 2025 年 7 月に Windsurf というスタートアップを 24 億ドル（約 3,600 億円）で買収してる

Windsurf は、AI IDE の分野で注目されてたスタートアップで、CEO の Varun Mohan を含むチーム全体を Google が獲得したんよね

この買収が、Antigravity の開発に大きく影響している可能性が高い

Windsurf が持ってた技術やノウハウが、Antigravity に統合されてるわけやな

Google は AI モデル（Gemini）の開発では先行してたけど、IDE の領域では経験が少なかった

だから、Windsurf チームを買収することで、IDE 開発のノウハウを一気に手に入れたってこと

この買収によって、Google は AI IDE 市場に本格参入する体制が整ったんよね

Cursor との比較

Antigravity の最大のライバルは、間違いなく Cursor やろ

Cursor も VS Code のフォークで、AI を深く統合した IDE として人気を集めてる

でも、Antigravity と Cursor には大きな違いがある

Cursor は「エディタ中心」で、AI が補助する形

Antigravity は「エージェント中心」で、エディタが補助する形

また、Antigravity はブラウザとターミナルを横断的に制御できるけど、Cursor はエディタ内での操作が中心

さらに、Antigravity は無料で複数のモデルが使えるけど、Cursor は Pro プランが月額 20 ドル

コストパフォーマンスでは、Antigravity が圧倒的に有利やな

ただし、Cursor は既に多くのユーザーがいて、エコシステムが成熟してる

一方、Antigravity はまだパブリックプレビュー段階で、これから成長していくフェーズ

今後、この 2 つがどう競合していくかが、AI IDE 市場の大きな注目ポイントやね

動作環境とインストール

Antigravity は、Mac、Windows、Linux の 3 つのプラットフォームに対応してる

具体的な動作環境は、以下の通り

- macOS 12 以上（ただし Intel Mac は非対応、Apple Silicon のみ）
- Windows 10（64bit）以上
- Linux（glibc 2.28 以上）

パブリックプレビューとして、すべてのプラットフォームで無料で使えるんよね

インストールも簡単で、公式サイトからダウンロードするだけ

Google アカウントでログインすれば、すぐに使い始められる

起動後は、Cmd + E（macOS）または Ctrl + E（Windows / Linux）で、Agent Manager とエディタを切り替えられる

クロスプラットフォーム対応やから、チーム開発でも環境の違いを気にせず使えるのがありがたい

MCP 対応と拡張性

Antigravity は、MCP（Model Context Protocol）に対応してる

これは、AI モデルとアプリケーションを繋ぐための標準プロトコルやな

MCP に対応してることで、外部のツールやサービスと簡単に連携できる

例えば、GitHub、Jira、Notion、Slack などのサービスと、MCP 経由で繋げられる

エージェントが GitHub の Issue を自動で確認したり、Jira のチケットを更新したり、Notion にドキュメントを書いたりできるんよね

また、Browser Recordings という機能もある

ブラウザでの操作を記録して、再利用できる機能やな

一度記録した操作を、エージェントが再現できるから、定型的な作業の自動化がさらに進む

Screenshots 機能も充実してる

エージェントが自動でスクリーンショットを撮って、成果物として保存してくれる

UI の変更前後を比較したり、バグの再現手順を記録したりするのに便利

さらに、Inbox や Conversations といった、コミュニケーション機能もある

複数のエージェントやユーザーとのやり取りを、整理して管理できるんよね

こうした拡張性と連携機能によって、Antigravity は単なる IDE を超えて、開発ワークフロー全体をカバーするプラットフォームになってる

今後の展望

Antigravity の登場で、AI IDE 市場が一気に加速する

Google が IDE 市場に本格参入したことで、Microsoft（VS Code + Copilot）との競争が激化するやろ

また、今後は Team プランと Enterprise プランも登場する予定

現在は Individual プランのみやけど、チームや企業向けのプランが出れば、ビジネスでの採用も進むはず

さらに、Gemini 3 の進化に合わせて、Antigravity の機能も強化されていく

エージェントの性能が上がれば、より複雑なタスクを自動化できるようになるからな

AI が開発ワークフロー全体をハンドルする時代が、本格的に到来しようとしてるんよね

まとめ

Google Antigravity は、単なる AI 搭載 IDE じゃなく、開発体験そのものを再定義する製品

Agent-first という思想で、AI エージェントが開発ワークフローの中心に位置する

エディタ、ターミナル、ブラウザを横断的に制御できるから、開発行為が OS レベルで変わる

無料で Gemini 3 Pro、Claude Sonnet 4.5、GPT-OSS が使えて、内部的には Nano banana や Gemini 2.5 シリーズも自動で使い分けられるのが破壊的

Artifacts、Task Groups、Knowledge、User Feedback といった機能で、エージェントと人間が本当に共同で開発できる環境が実現されてる

エージェントの設定も細かくカスタマイズできて、Planning モードと Fast モード、Artifact Review Policy、ターミナル自動実行など、プロジェクトに合わせて調整できる

Browser Subagent の強力さも圧倒的で、人間がブラウザでやる操作を全部 AI が代行できる

青枠表示で操作中を示して、裏タブでのバックグラウンド操作もできるから、UI の検証が完全自動化される

MCP 対応で外部サービスとの連携も簡単やし、Browser Recordings や Screenshots、Inbox、Conversations といった機能も充実してる

Windsurf チームの買収によって、Google は AI IDE 市場に本格参入した

Cursor との競争も激化するやろうけど、無料プランの強さと Google のエコシステムの力で、Antigravity は大きな存在感を示していくはず

開発者にとって、これはめちゃくちゃ大きなチャンス

無料で最新の AI IDE 環境が手に入るから、まだ試してない人はぜひ使ってみてほしい

Antigravity は「マルチエージェント、マルチサーフェス、マルチモード、自走型タスク分解、Artifacts ベースの協働」を中核にした、完全に新しい AI 主体の開発実行 OS

コードを書く時間より、エージェントに指示する時間が長くなる時代が、もうすぐそこまで来てるよね
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Gemini 3 Pro × Cursor が最強な理由]]></title>
            <link>http://izanami.dev/post/3fde74cd-e2d2-4b04-9d6e-2fc4a3274eb9</link>
            <guid>http://izanami.dev/post/3fde74cd-e2d2-4b04-9d6e-2fc4a3274eb9</guid><dc:creator>Nexyl</dc:creator>
            <pubDate>Wed, 19 Nov 2025 09:37:28 GMT</pubDate>
            <description><![CDATA[Gemini 3 Pro が Cursor に来たのはかなり大きい

実際に Cursor のモデル選択に Gemini 3 Pro が追加されたため、この記事では開発現場での使い勝手を中心にまとめる]]></description>
            <content:encoded><![CDATA[Gemini 3 Pro が Cursor に来たのはかなり大きい

実際に Cursor のモデル選択に Gemini 3 Pro が追加されたため、この記事では開発現場での使い勝手を中心にまとめる

https://x.com/cursorai/status/1990814174264381910

ただ「何がどう良いのか」は用途によって違うので、重要ポイントだけきれいに整理するよ

https://cloud.google.com/blog/ja/products/ai-machine-learning/gemini-3-is-available-for-enterprise/


公式ブログから読み解く Gemini 3 Pro の背景

Google 公式ブログでは、Gemini 3 の進化ポイントとして
推論力、文脈把握力、マルチモーダル理解、ツール利用能力、エージェント性能
の 5 つが大きく強化されたと説明されている。

特に CEO の Sundar Pichai 氏はこう述べている。

> “Gemini 3 is our most intelligent model, built to grasp depth and nuance… much better at figuring out the context and intent behind your request, so you get what you need with less prompting.”

これは、この記事でまとめている「長時間の対話でも文脈が安定する」「複雑な指示の理解が強い」という Gemini 3 Pro の実務的な強みと完全に一致している。

DeepMind チームの公式発表でも次のように説明されている。

> “Gemini 3 Pro significantly outperforms 2.5 Pro on every major AI benchmark… delivering state-of-the-art reasoning and multimodal understanding.”

実際に Gemini 3 Pro は、LMArena、SWE-bench Verified、MMMU-Pro、Video-MMMU などで最高水準のスコアを記録しており、これは本記事で紹介する 「コード解析・画像理解が強い」 というポイントの裏付けになっている。

さらに、Google は Gemini 3 を Cursor / GitHub / JetBrains / Replit などサードパーティ IDE へ即日提供 したと明言している。

> “Gemini 3 is available today in third-party platforms like Cursor, GitHub, JetBrains, Manus, Replit and more.”

この記事で紹介する「Cursor で Gemini 3 Pro を使うメリット」は、これらの 公式情報に基づいた実務視点の解説 になっている。


コーディング作業での文脈保持が強い

![画像の説明を入れてください](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/711ab4a6-151e-4f23-935f-4ac41f39f356/453d7d78-c40c-44ac-ac26-d4315afd7768.png)

Cursor で Gemini 3 Pro モデルが使えるようになっていた

Gemini 3 Pro の最大の強みは、超ロングコンテキストに対応してること

なお、公式ブログでは Gemini 3 Pro の推論性能・マルチモーダル性能・コード生成能力について詳しいベンチマークと使用例が紹介されている。

https://blog.google/products/gemini/gemini-3/responsible-development

これが Cursor との相性で抜群に効いてくる

大規模なリファクタリングをやるとき、複数ファイルを跨いで修正していく場面があるやん

Claude（Sonnet）でも長い対話に強いけれど、タスクによっては途中で文脈の保持が不安定になることがある。

Gemini 3 Pro は非常に長いコンテキストに対応していて、長時間の対話でも比較的安定して文脈を保持しやすい。

設計書とコードを同時に参照しながら、何往復もやり取りするような作業でも安定してる

例えば、API の仕様書を読み込ませて「この仕様に沿って実装を修正して」って依頼したとき、その仕様を最後まで覚えててくれるのが地味に助かる

長時間の対話が必要な複雑なタスクほど、この文脈保持力が効いてくるよ

リサーチ寄りのタスクが速い

Gemini 系は「調査系の質問への回答」や「情報整理・統合」が得意な傾向がある。

これは Gemini の得意領域やな

エラーメッセージをそのまま投げて「これ何が原因？」って聞いたとき、Gemini は学習済みの知識を総合して説明してくれるので、実務で求める調査・比較の流れを自然に補完してくれる。

ライブラリ選定で「Next.js で状態管理するなら何がいい？」って聞いたら、一般的に知られている特徴や設計思想を踏まえて、使い分けを整理して比較してくれる。

特に「外部知識とコードを混ぜた説明」が上手で、理論と実践を繋げて教えてくれるから理解しやすい

新しい技術を学ぶときとか、知らないライブラリに触れるときに Gemini に聞くと、学習効率がめっちゃ上がるよ

コードの解釈力が高い

Gemini は元々コード理解能力が強いモデルとして設計されてる

これが Cursor で効いてくるのは、既存コードを読む場面やな

レガシーコードベースに入って「このコード何してるん？」ってなったとき、Gemini に読ませると意図まで説明してくれる

コードから設計意図を推測するのが得意で、「このロジックは Strategy パターン的な構造」などの判断もしてくれる場合がある

複雑なロジックの読み解きも強い

例えば、再帰処理が絡んだアルゴリズムとか、複雑な状態管理のコードとか、一見しただけじゃ理解しづらいコードでも、Gemini は丁寧に分解して説明してくれる

既存仕様の読み取りも正確で、「この API はどういう仕様で動いてるん？」って聞いたら、コードから仕様を逆算して説明してくれるから、ドキュメントがない古いプロジェクトでもめっちゃ助かる

こういう「読む力」が強いから、引き継ぎ案件とか、他人のコードを理解する場面で Gemini は頼りになるよ

画像付きのデバッグ能力が高い

画像理解精度は現行の大規模モデルの中でも高いレベルにある。

UI のスクリーンショット、PDF の図解、システムの構成図、エラー画面のキャプチャ、こういうのを読み取る力が非常に強いんよね

これが Cursor に統合されることで、画像からコード提案してもらうフローがめちゃくちゃ強化される

例えば、デザインのモックアップを見せて「これをコンポーネント化して」って依頼したら、画像から UI の構造を読み取って、ちゃんと動くコンポーネントを生成してくれる

PDF の技術仕様書とか、図解が多いドキュメントを読ませて「この図の通りに実装して」って言っても、ちゃんと理解して実装してくれるから、視覚的な資料からコードへの変換がスムーズなんよ

エラー画面のスクショを投げて「これ直して」って言うだけでも、画面から状況を把握して原因を特定してくれるから、説明する手間が省ける

UI 開発とか、デザインからコードに落とし込む作業が多い人にとっては、この画像理解能力はかなりのアドバンテージやな

モデル切替による最適化が可能になる

Cursor では複数のモデルを使い分けられるようになってる

Gemini 3 Pro が加わることで、モデルの役割分担がハッキリできるようになったんよね

例えば、こんな感じで使い分けられる

泥臭いデバッグや既存コードの解析は Gemini に任せる

一般的な傾向としては

- 既存コードの解析やデバッグは Gemini
- 抽象設計や文章化は Claude
- 実装のスピードは GPT または Claude

という使い分けがしやすい。

こういう風に、タスクの性質に合わせてモデルを切り替えることで、それぞれの強みを最大限に活かせるようになる

Gemini 3 Pro が加わったことで、Cursor が「万能 IDE AI」として完成度が一気に上がったと感じてる

モデルごとの得意分野を理解して使い分けるだけで、開発効率がめちゃくちゃ変わるよ

コストパフォーマンスが高い

Gemini は大量のコンテキストを扱う割にコストが低めに設定されてる

Gemini は大量コンテキストの割に API 単価が抑えめなので、Cursor と組み合わせても比較的コストを気にせず使いやすい

長時間の対話や、大量のコードを読ませる作業が多い人にとっては、このコスパの良さは無視できない

Claude だとコンテキストが長くなるほどコストが跳ね上がるけど、Gemini ならそこまで気にせず使えるから、気軽に大規模なコードベースを読ませられる

特に、プロトタイプ段階とか、試行錯誤が多いフェーズでは、コストを気にせず何度も聞き直せるのがありがたい

開発の初期段階で色々試したいときとか、学習目的で使いたいときに、Gemini はめっちゃ使いやすいよ

実際の使い分けパターン

ここまでの話を踏まえて、実際にどう使い分けるかを具体的に整理するね

まず、新規プロジェクトの立ち上げフェーズやと、設計や構造を考える部分は Claude に任せる

Claude はアーキテクチャ設計とか、コンポーネント設計とか、抽象的な思考が得意やからな

で、実装フェーズに入ったら、ガンガンコードを書く部分は GPT か Claude に任せる

スピード感が大事な場面では、このあたりのモデルが強い

既存コードのリファクタリングとか、レガシーコードの理解が必要な場面では Gemini を使う

コードを読む力と、長い文脈を保持する力が活きてくるからな

デバッグ作業では、エラーメッセージを投げて調査してもらうのは Gemini が得意

リサーチ力と情報統合力が効いてくる

UI 開発で、デザインからコンポーネントを生成する場面でも Gemini が活躍する

画像理解能力が高いから、モックアップから直接コードを生成してもらえるんよね

ドキュメント作成では、技術仕様書とか API ドキュメントみたいな構造化された文章は Claude に任せる

読みやすい文章を書く力は Claude が強いからな

こんな感じで、フェーズやタスクに応じてモデルを切り替えることで、それぞれの強みを引き出せるよ

Cursor での設定方法

Gemini 3 Pro を Cursor で使うための設定も簡単やから、ここで軽く触れとくね

Cursor の設定画面から、モデルの選択肢に Gemini 3 Pro が追加されてるから、そこから選ぶだけ

API キーの設定が必要な場合もあるけど、基本的には Google の AI Studio でキーを取得して、Cursor の設定に貼り付けるだけ

あとは、Cursor の Composer とか Chat 機能で、モデルを切り替えながら使えるようになる

デフォルトモデルを Gemini にするか、タスクごとに切り替えるかは好みやけど、自分は基本的にタスクごとに切り替えてる

理由は、さっき話した通り、モデルごとの得意分野が明確やから、適材適所で使った方が効率がいいんよね

設定自体は 5 分もかからんから、まだ試してない人はぜひ試してみてほしい

Gemini 3 Pro の弱点も知っておこう

ここまで Gemini のメリットばかり話してきたけど、弱点も知っとかんとフェアじゃないよな

Gemini は事実ベースの処理が得意な分、クリエイティブ生成や抽象的な文章化では Claude の方が自然な表現を出す場面が多い

例えば、技術ブログの記事を書いてもらうとか、ユーザー向けのドキュメントを作ってもらうとかは、Claude の方が自然で読みやすい文章を書いてくれる

あと、Gemini は事実ベースの情報処理が得意な分、推測や創造が必要な場面では保守的になりがちやな

「こういう設計にしたらどう？」って提案を求めるより、「この設計の問題点を指摘して」って聞く方が得意

だから、アイデア出しとか、ブレインストーミング的な使い方は Claude の方が向いてる

実装フェーズでは GPT が高速に返す場面も多い

Gemini は正確性を重視する分、慎重になる傾向があるんよね

こういう弱点を理解した上で、適材適所で使い分けるのが一番賢いやり方やと思う

今後の展望

Gemini 3 Pro の登場で、AI アシスタントを使った開発の幅がめちゃくちゃ広がった

今後は、さらに多くのモデルが Cursor に統合されていく可能性が高いし、モデル間の連携とか、自動切り替えみたいな機能も出てくるかもしれん

例えば、タスクの性質を自動判定して、最適なモデルを提案してくれる機能とか、複数のモデルを同時に使って回答の質を高める機能とか、そういう進化が期待できる

Gemini 自体も進化し続けてるから、今後のアップデートでさらに性能が上がっていくはず

特に、コード生成の精度とか、推論能力の向上とか、そのあたりが強化されたら、Cursor での開発体験がさらに良くなるよな

AI アシスタントを使った開発は、まだまだ発展途上やけど、Gemini 3 Pro の登場で一つの大きな節目を迎えたと感じてる

まとめ

Gemini 3 Pro が Cursor に統合されたことで、開発環境が一気に進化した

超ロングコンテキストでの文脈保持力、リサーチと情報統合力、コードの解釈力、画像理解能力、そしてコストパフォーマンス

この 5 つの強みが、Cursor での開発体験を大きく変えてくれる

特に、情報の統合力と長文処理能力は、複雑なプロジェクトや大規模なコードベースを扱う人にとって、めちゃくちゃ価値がある

Claude や GPT と使い分けることで、それぞれのモデルの強みを引き出せるから、Cursor がまさに「万能 IDE AI」として機能するようになったんよね

実際に使ってみると分かるけど、モデルごとの得意分野を理解して使い分けるだけで、開発のスピードと質が段違いに変わる

まだ Gemini 3 Pro を試してない人は、ぜひ一度使ってみてほしい

特に、既存コードの理解とか、長時間の対話が必要なタスクで使ってみると、その強さが実感できるはず

最初は Claude や GPT との違いが分かりにくいかもしれんけど、使い込んでいくうちに「あ、このタスクは Gemini の方が得意やな」って感覚が掴めてくる

モデルの使い分けを意識するだけで、開発効率が大きく変わるから、試してみる価値は十分ある
]]></content:encoded>
        </item>
    </channel>
</rss>