AI新聞

• AIに毎回状況説明する手間を減らすため、「自分の取扱説明書」を作って渡す。情報は時制で分けると迷わない（変わらない自分／目標や方向性／進行中の仕事／日々の記録／外部から得た知識）。
• CLAUDE.md（運用ルール）を用意し、「機微情報は勝手に編集しない」などの約束を明文化すると、AIが一貫して守る。
• Skills（定型操作のコマンド化）で「月次振り返り」「新規タスク作成」などをワンコマンド化。MCP（外部サービス接続）でカレンダーやタスクとつなぎ、相談を1か所で完結。
• メモリ機能で好みや方針を永続化し、「毎回初対面」問題を軽減。
• 一番効いたのは自動化ではなく、自分を言語化する強制力。進む方向は人が決め、実行と加速をAIに任せるのがよい。
• 今日からの段階的導入：Lv1 書く（価値観・今年やりたいこと・悩みを箇条書き）→Lv2 分ける（自分／目標／記録）→Lv3 Gitで履歴管理→Lv4 SkillsやMCPで自動化。

生成AIの音楽が急増し、権利の線引きが曖昧になっている。これに対しJASRACは、単純な指示だけでAIが作った歌詞と曲は人の創作的寄与がないAI音楽は著作物ではないとするガイドラインを示した。

人がどこまで関われば著作物と認めるかの基準づくりが進み、AI生成物は原則として著作権の管理対象外になる可能性が高いという方向を示したと言える。

• ジャンル: Tips系
• llama.cppをMetal有効でビルドし、Gemma 4 26B-A4BのGGUFを使うとMacで実用速度になる。
• MTP下書き推論でGemma 4が約24%高速化（58.2→72.2 tok/s）。--spec-draft-n-maxは環境依存で、著者環境では3が最速。
• MLXよりllama.cpp（+MTP）の方が本ケースでは速かった。最適化の積み重ねが効いている。
• 画像入力はmmproj-BF16.gguf（画像用プロジェクタ）を--mmprojで読み込む必要がある。これでPiからスクショを渡せる。
• llama-serverを立てるとOpenAI互換の/v1エンドポイントで他ツールから呼べる。
• Piのmodels.jsonでbaseUrlをローカルにし、api=openai-completions、inputに["text","image"]を必ず入れる。
• コンテキストは65536でも速度低下は小さく、テキスト生成の体感は維持。
• 代替としてQwen3.6 35B-A3Bはコーディング精度に強いが、同条件で約55 tok/sと遅め。
• まとめ：ローカルの実用的なコーディング環境は、llama.cpp + Gemma 4 Q4 + MTP + mmproj + Piの組み合わせが手軽で速い。

米AI企業サイファー・スタジオが、DIR EN GREYの楽曲を用いたアプリを開発。アーティストの権利を守る仕組みを前提に、AIが解析したバンドの表現を再構成し、ユーザーがAIが感じたDIRの世界観を体験できる内容としている。

ただし「痛み」「闇」「負の感情」「狂気」など過激な表現が多いとして、App Storeから複数回リジェクト。対象年齢を17歳以上に引き上げて再申請するという。

日本語プログラミング入門サイト「言語の庭」。Claude Fable 5にほぼ丸投げで生成され、登録不要・無料で公開されている。

日本語キーワードの「にわ語」で学べ、エディタ・実行・エラー表示がその場で完結。トークン列（ことばの粒）→構文木（式のまとまりを木で表した図）→評価の可視化まで揃い、教材用言語を自作し、ブラウザ内で処理系まで動くのが肝。

全6コース54レッスンで、正規表現エンジンやチューリング機械、型検査器も自前実装。初学者にやさしく、しかも説明が正確で深いのが特徴。

NVIDIAのフアンCEOが台湾・韓国を訪れ賛辞を送り、日本を素通りしたことは、半導体とAIで日本の存在感が薄れている兆しだと示している。台湾はTSMCを軸に設計から製造まで一気通貫で動け、韓国はHBM（大容量メモリー）や大型投資でNVIDIAの需要に即応できる。

日本は素材・装置では強いが、データセンターやAI人材、スタートアップとの連携が弱く、商流の中心に入れていない。このままでは日本がAI革命の主戦場から外れるリスクが高まり、成長の果実が海外に流れると警鐘を鳴らしている。

生成AIが一般に広まってから初のW杯を前に、各チャットボットが優勝国を占う動きが拡大している。ChatGPTやClaudeはスペイン有力、Le Chatはフランス、DeepSeekやQwenはアルゼンチンを推し、企業やメディアも検証に乗り出している。

筆者は、予言タコのような遊びの延長に見えつつ、勝者予測だけでなく大会運営の裏側でもAI依存が進むと指摘する。監督や医療、審判支援、詐欺対策でもAIが使われ、最終的な優勝チームも過程でAIの恩恵を受けるという見立てである。

マルチモーダル対応のオープンウェイトLLM「MiniMax M3」は、MoE設計（総4,280億/アクティブ約230億パラメータ）でテキスト・画像・動画をそのまま処理できる。独自のMiniMax Sparse Attentionにより、100万トークンの長文を高速に扱えるのが強みで、SWE-Bench Proでは59.0%とGemini 3.1 Pro級の性能を示す。

非商用は無償、年商2,000万ドル未満なら届け出と表記で商用利用も可。重さはbf16で約855GBだが1-bit GGUFで約128GBまで圧縮でき、API提供も開始済み。

DatadogとAWSが同日に発表した運用向けエージェントは、別領域に見えて実は同じOpsの主導権を狙っている。AWSは自社クラウドのコスト・操作ログという一次データと実行基盤を握り、標準エージェントと基盤（AgentCore）で「中で動かす」戦略。Datadogは監視データの横断可視化と保護で「外から統べる」戦略を取る。

勝負の的は、検知から修正、リリースまでのループをどこのUIで完結させるか。AWSは実行環境と請求を囲い込み、Datadogは自社・他社エージェントを同じ画面で見せて主導権を取ろうとする。どちらが有利かは、組織が普段いる場所（AWSコンソールか、DatadogとSlackか）と、環境の広さ（単一クラウドか混在か）で分かれる。

企業で自律型AIを本番運用する前提が一気に現実化しており、通信プロトコルの標準化が進む一方で、LLMの幻覚やだまされやすさなどの弱点が課題になっていると示された。

対策の核は、安全と運用を支える設計と計測にある。LLMをルールで必ず同じ結果になる層で挟む「サンドイッチ」設計、テキスト以外も含む記憶・検索の一元化で精度と速度を同時に上げる構造、評価は「成功1件あたりのコスト」で最適化し軽いモデルを併用、開発はレビューや後片付けまでエージェントに任せ人はワークフロー設計に集中する、という実践が共有された。

結論として、24時間止まらないエージェント由来のトラフィックと爆発するデータ量に備え、追跡可能な記録と強いインフラを前提にシステムを作り直す必要がある、と筆者は受け止めている。

GitHubがCopilot CLI向けに、Language Server Protocol（LSP）サーバーを自動で入れて設定するスキル「LSP Setup」を公開。エージェントが定義ジャンプ、参照検索、ホバー、型情報を使えるようになり、テキスト検索頼みのコード理解をLSPの構造化情報に置き換える。

対応は14言語（TS/JS、Java、Python、Go、Rust、C/C++ほか）。Awesome Copilotから導入し、/lsp-setupや「set up LSP for Java」のような指示で開始、OSと言語に応じたサーバーをインストールし、ユーザー単位やリポジトリ単位の設定にマージして有効化する。

依存関係をまたいだ型解決やサードパーティ定義へのジャンプが可能になり、ツール呼び出し時間やシグネチャの読み違いが減る。再起動後は/lspで状態確認できる。

• RAGは「外部文書を探してLLMに渡す」仕組み。検索の質がRAG全体の成否を決めるので、生成だけでなく前段を設計・評価する。RAG≠ベクトルDBで、数値やIDはAPI/DBから直接取る。
• データ源は厳選し、title・updated_at・source_url・permissionなどのメタデータを必ず持たせる。古い文書や権限混在は避ける。
• クローリング/ロードでは本文抽出とノイズ除去（ヘッダーやフッター削除、重複排除、OCR）を行い、更新・削除を追跡する。
• チャンク化は見出し単位＋必要に応じて重なりを持たせる。本文だけでなくタイトルや見出しも一緒に入れる。
• 埋め込みで文章をベクトル化し、同じモデル空間で質問と文書を比較する。ベクトルは「意味の地図上の住所」だと考える。
• ベクトルストアにはベクトルだけでなく本文参照・メタデータ・権限情報も保存する。用途でS3 Vectors/OpenSearch/pgvector/Pinecone等を選ぶ。
• 類似度はコサイン類似度が基本。大規模ではHNSWなどのANNインデックスで高速化し、kの設定を調整する。
• 固有名詞や型番はキーワード検索、言い換えはベクトル検索が得意。RRFでハイブリッド化し、必要に応じて再ランキング（コスト高）を使う。クエリリライトも有効。
• プロンプトは「取得文書は参考情報」であり命令ではないと明示。出典を付け、根拠外の推測を禁止し、プロンプトインジェクションに注意。
• 評価は検索（Recall@k/Precision@k）と生成（Faithfulness/関連度）を分けて測る。代表的な質問セットで継続評価する。
• 権限フィルタは検索時に必ず適用。更新・削除をベクトル側にも反映し、鮮度を保つ。質問・検索結果・出典・回答のログを適切に保護して残す。

• ガバクラAWSでもBedrockは利用できる。国内リージョン（東京/大阪）で推論が完結する設定が必須。
• モデル制約あり。AWS MarketplaceがSCPで禁止のためサードパーティモデルは原則不可。Claudeは契約上は対象で、技術的制約が解ければ利用可能になる見込み。
• マイナンバー利用事務系ではインターネット遮断のため、VPCエンドポイント経由の閉域利用が必須。呼び出すアプリもVPC内（Lambda/ECS）に置く。
• 外部サイト参照が必要なMCP Clientなどは閉域では使いづらい。設計の工夫が必要。
• 事例：奈良市・つくば市がGenUの閉域モードで導入。監視運用の要約通知にも活用例あり。
• 源内はガバクラと直接無関係。ガバクラでも動かせるが閉域モードがないため基幹系はそのままでは不可。必要ならALB+ECSやVPCエンドポイント対応に改造。
• 準備の実践例：ECS Expressでの閉域デプロイ、源内Web/AIアプリの閉域対応、クロスアカウントでのBedrock VPCエンドポイント接続検証。

タロット占いアプリ『Hoshimichibiki』を公開。大アルカナ22枚の正逆44種から6枚を引くヘキサグラムで、約44億通りの組み合わせ。Groq API（Llama 3.3 70B）で待ち時間を抑え、毎回状況に合う言葉を生成する。

詩的になりすぎるAIの口調を、12段階のプロンプト調整で花の比喩を残しつつ実用的に整理。スマホでも読みやすい分量に整え、誰に対してもやさしく背中を押す、詩情と具体アドバイスの両立を目指した体験が特徴。

• Claude CodeでOpenSCADコードを生成・修正し、Bambu Lab P1SでPLAの中空シェルを印刷。自然言語で寸法や穴位置を変更でき、3Dモデリングの敷居が下がる。
• 大林組3dpodを参考に、印刷物を型枠兼最終部材とみなす構成を採用。設計データ→印刷→配筋→充填の工程を机上で再現。
• 外壁のみを出力し、中空・配筋穴あり・後充填という「建築っぽい」工程に寄せた設計。
• 配筋穴は2D断面で円を抜いてから押し出し。曲面でも縦にまっすぐ抜ける真円穴になる。
• Bambu Studio設定の要点：Layer 0.20mm、Wall 2、Top shell 0（上面を開口し充填可）、Bottom shell 3、Infill 15%、サポートなし。
• 1/30スケールで印刷後、Φ0.5mm針金を挿入し、百均の軽量粘土を充填。屋根は簡易にダンボール。
• 気づき：3Dプリント建築の肝は「一発印刷」ではなく、材料や手順、補強などをデータでつなぐこと。AIが設計〜製作の入口を広げている。

• LambdaやAgentCoreランタイムなしで直結できる。AgentCoreゲートウェイにSmithyを使うと、BedrockナレッジベースのAPIを直接呼べるMCPツールを自動生成できる。
• まずAWSドキュメントのllms.txtを取得してS3に置く（Bedrock/AgentCore一式）。このS3をデータソースに、東京リージョンでナレッジベースを作成し、S3Vectors＋Titan Text Embedding V2で同期する。
• 作成後、CLIのretrieveで検索テストを行い、動作確認する。
• Smithyスキーマはaws/api-models-awsのbedrock-agent-runtime 2023-07-26を参照。Retrieve APIだけを抜き出し、knowledgeBaseIdとretrievalQuery.textの最小パラメーターで定義する。
• 認証はIAM（SigV4）を指定し、プロトコルはrestJson1を使う。
• スキーマ作成はClaude Codeに任せると早い。手書きしなくても必要部分だけ生成できる。
• 必要なAPIに限定したMCPサーバーを構築でき、複数のAWSサービスにもまたがって拡張可能。

AWSのAI-DLCを若手中心チームで試すと、AIは要件やコードを高速に出す一方で、人間のレビューが詰まりやすかった。レビュワーの経験が浅いと設計やセキュリティの見抜きが甘くなり、Inceptionでの技術選定も、知っている技術に寄る偏りが出やすい。

要するに、実装は速くなるが検証は人間の時間に縛られて速くならない。MITの議論とも合致し、AIが進化するほど人間の検証帯域がボトルネック（レビューに割ける時間の限界）になる。

そのため、最初に「AIに任せる範囲」と「人間が見る範囲」を設計し、経験あるレビュワーを置き、検証コストを前提に計画することが重要だと述べている。

• OpenAIのprivacy-filterは、テキスト中の個人情報(PII)を見つけてラベル付けする軽量モデル。128kトークンの長文にも対応。
• GPUなしのDatabricks Free Editionでもそのまま動く。CPUで実用速度。追加設定なしでHugging Faceから直接ダウンロード可能。
• 必要な環境はtransformers 4.46以上とCPU版torch。%pip後に%restart_pythonが必要。
• pipelineでtoken-classificationを指定すれば起動。未認証DLはレート制限に注意し、必要ならHF_TOKENを設定。
• 英語中心だが、日本語の氏名・住所も検出できた。
• 単純置換だと同一カテゴリが分割され、[PRIVATE_PERSON][PRIVATE_PERSON]のように重複しやすい。
• 置換前に隣接スパンをマージし、先頭の空白は除外してからマスクすると自然な出力になる。
• 本番では完全匿名化は保証されないため、重要データは人のレビューを残し、日本語データでは事前評価を行う。

• 設計書をMarkdownでリポジトリ管理し、Pull Requestで差分をそのままレビューできるようにする。
• MkDocs + MaterialテーマでHTMLサイト化し、検索・目次・日本語表示を強化して読みやすく整える。
• 画像や図はGitHub上で見やすいMermaidと画像ファイルを使い分ける（PlantUMLは表示・差分が扱いにくい）。
• GitHub Actionsでビルドし、GitHub Pagesに自動デプロイして公開する。
• mainマージは本番サイト、PR時はgh-pages内にプレビュー用ディレクトリを作成し、PRごとのHTMLプレビューを自動公開する。
• ワークフローでプレビューURLを生成し、PRコメントに自動投稿して見た目崩れやリンク切れを事前確認できる。
• ローカルでも仮想環境＋pip/npmでビルドし、簡易サーバーで表示して確認できる。
• 注意点は、Pagesをブランチ公開に設定すること、forkからのPRでは権限やSecretに配慮してartifact運用も検討する。

AIに強い言語は型が厳しいRustで、C++は危ないという通説に対し、筆者は同一仕様のボクセルエディタを6言語でAIに自走実装させて検証した。結果はC++が欠陥ゼロで最上位、Rustはレンダリング不具合と機能不足で下位となり、期待が覆った。

言語の安全性は実行中に画面へ正しく出るかまでは保証しない。品質を決めたのは、AIがネットで学んできた例の多さと、APIが長年使われ安定しているかで、要するに学習データの量と枯れたAPIが品質を左右するという指摘である。結局、最終確認は人の目と操作で行う実機テストが一番効いたと述べる。

• 作業はAFK（無人で回せる工程）とHITL（人の目と判断が要る工程）に分ける。AFKは実装・テスト作成・型/lint修正など、「テストが緑になるまで」を自動化する。
• AFKを成立させる前提を人間が用意する。明確なスコープ、合否を決めるテストや検証、外部への副作用を防ぐ仕組み（ガード）を整える。
• HITLは「verdictの妥当性レビュー」と「Verify Gateでの合否判定」。テストが緑でも十分条件ではない。緑（機械の合格）とverdict（人の合否判断）を分けて扱う。
• ハーネス整備（運用の足場づくり：テスト観点、MCP/ツール説明、ガード強化）は人間の中核仕事。ここに投資するとAFKの品質が底上げされ、レビュー負荷が減る。
• スコープ定義は独立の人間作業。要件を構造化して渡さないと「それっぽいがズレた緑」が増える。
• 割り込み操舵（走行中の方向修正）で「放置」と「常時監視」の間を運用する。詰まり時だけ介入し、またAFKに戻す。
• 知識の書き戻し（差し戻し理由をCLAUDE.mdやテストに反映）で学びを資産化。繰り返しの差し戻しを防ぐ。
• 作業を「誰が主体か・自律度」で表にし、どこがボトルネックかを特定する。レビューに溺れるならハーネス整備と書き戻しが不足。
• 罠は「緑＝合格」と短絡すること、ハーネス整備の後回し、AFK/HITLの境界を固定すること。境界はハーネス成熟度に応じて動かす。

• スキャナ＝事実／AI＝提案／人間＝承認の分業で、依存の脆弱性を安全に直す流れを作る（検出→修正提案→承認→再スキャン）。
• Trivy本体を入れたうえで、mcpプラグインを追加。Claude Codeにはstdio（同一PCで標準入出力をつなぐ方式）で登録するだけ。
• スキル/security-checkを作り、「CRITICAL,HIGHでスキャン→要約→最小の更新幅で修正提案→人が承認→再スキャン」を定型化する。
• 修正は最新版一括ではなく、各CVEを消す最小バージョンに。互換性が壊れそうなら注意書きを添える。
• 人間はEdit承認で最終決定。再スキャンで0件になったか確認する。
• 自動化はhookで実施。依存ファイル編集時だけTrivy CLIを走らせ、検出時はexit 2＋stderrでチャットに戻す。
• 対象ファイルはrequirements.txtやpackage.jsonなどに限定して軽量化。Trivyの--exit-codeで誤検知を避ける。
• 実運用では読み取り専用など最小権限で接続し、手順やプラグインの最新版を都度確認する。

• 単純な一問一答RAGは「文脈が続かない」「検索が外れると即失敗」「改善サイクルが無く陳腐化」の限界がある。
• Bedrock AgentCore + Strandsで検索をツール化し、LLMに再検索やデータソース切替を任せるAgentic RAGにする。Knowledge Bases/Runtime/Memoryで基盤はマネージド化。
• SlackはACKを即返し、回答生成はRuntimeで非同期実行。障害解析・デプロイ粒度も分けて運用を軽くする。
• 会話の文脈はMemoryに保持し、知識の増強は運用ログで行う。役割を分ける。
• 未解決のSlack Q&Aを構造化してKBの別データソースとして再投入。マニュアルで不足時のみ過去事例をフォールバック検索し、事例である旨を明記。
• フィードバックは「解決」「案内通り人手」「回答不十分」に分け、外れた回答だけを学習入力に回す。
• 類似質問をクラスタ化し、頻出かつ回答が安定した話題からマニュアル更新案を自動生成。ドキュメントの構造を写した「ドキュメントツイン」で追記先も特定。
• 核心は、Agentic RAGに加えて運用ログを知識に還元するループを回し、「使うほど賢くなる」状態を作ること。

• Planでは自由、修正では厳密：設計初期はAIに広く調査させ、まだコードは触らせない。実装案の比較や前提の誤り指摘まで求める。
• Implementation Planを作らせ、人間が厳密にレビュー：変更ファイル、内容、影響、テスト、完了条件、今回はやらないことを確認する。
• 一度でまとめて実装させ、完璧でなくてもコミット：途中成果でも保存し、以後の差分を明確にする。コミットを境界にする発想が要。
• 修正フェーズは範囲を絞る：「何を直す/維持する」「触ってよいファイル」「リファクタの可否」「完了条件」「実行テスト」を明示。作業後はgit diffと結果を提示させる。
• 文脈が濁ったら新セッションへ：現在のHEAD、対象、禁止事項、完了条件を改めて共有し、会話履歴に引きずられないようにする。

• 役割別にモデルを固定して委譲する。賢い判断はメイン(Fable)、手数の多い作業はサブエージェント(Sonnet/Opus/Haiku)へ。
• コストは「トークン数×単価」。Fable＞Opus(約1/2)＞Sonnet(約3/10)＞Haiku(約1/10)。
• トークナイザ差でFable系は同文でも最大35%多く数える。Sonnet 4.6は従来方式なので、広範なファイル読み込みを任せると実質コストが約1/4に下がる。
• effortを下げると出力トークンが減る。仕様が固い単純タスクの委譲先だけ下げる。
• 役割例: 設計・最終確認=Fable、広範な調査=Sonnet、仕様確定の実装=Sonnet、複数ファイル実装/デバッグ=Opus、テスト実行要約=Haiku。
• 委譲基準: 規模が大きく自己完結するタスクは委譲。1〜2ファイルの小修正はメインで直接実行。小タスクはまとめて一括委譲。
• エージェントは.claude/agentsに定義し、model/effortをfrontmatterで固定して指示漏れを防ぐ。
• 委譲判断の基準はreferencesにまとめ、CLAUDE.mdから@importして常時適用。Skillは任意起動のため不採用。Rulesはパス条件が要る時のみ検討。
• 運用工夫: planにowner注記で担当を明記。報告は変更点・判断・検証のみ。調査結果はfile:line参照で返し、長文の逆流を防ぐ。

• 情報源はRSSに限定し、実装と運用を軽くする（OpenAI/Google/HFブログ、TechCrunch AI、arXiv、Substackなど）。
• 記事本文を取得し、OpenAI APIで日本語タイトルと要約を自動生成。読むかの判断を速くする。
• Tinder風カードUIで「役に立った/不要」を記録し、クリックも加点。クリック+1.0、役立ち+0.65、不要-1.1で重みを更新。クリック任せにせず、明示フィードバックをUIで集めるのが肝。
• スコアは「新しさ＋ソース信頼度＋タグ嗜好＋ソース嗜好」。12本中2本は探索枠にして偏りを防ぐ。
• 論文偏重を避けるため、arXivは分野ごとに最大1本、1ソースの上限も設定。
• Codexのオートメーションで毎朝の配信を自動化。使いながら重みが変化し、好みのソース/タグが可視化できた。
• 課題は、ソース/タグの粗さ、類似記事の重複、内容ベース推薦（文章の意味の近さで選ぶ）への拡張。

• Claudeのeffortは「計画・実行・文章」の3種類のトークン配分を粗く指示するダイヤル。adaptive thinkingで不要な思考を省くと無駄が減る。
• プロンプトの失敗は強すぎる指示が原因になりがち。never/alwaysの断言は控えめにし、信頼できるデータ源を明示する。
• 計算はプロンプトで頑張らずツールに任せる。モデルには「ツールを呼ぶか直接答えるか」の判断だけさせる。
• エスカレーション条件は両面で書く。「人に回すべき例外」も必ず明記する。
• コスト最適化の定石は、prompt caching、コンテキスト短縮（こまめに圧縮）、モデル切り替え（探索は安いモデルのHaiku）。
• 複数モデルでのクロスレビューは有効。最後は人が見るが、誤りと幻覚を減らせる。
• 無人運用は最初に良いplanを作るのが肝。検証ステップや受け入れ条件を書き切ると、長時間の自走が可能。
• GitHubやスケジュールを引き金に動くRoutinesで自動化。進行中に人が割り込める監視・介入も組み込める。
• 自前の良いeval（評価用データ）を作って回し続ける。公開ベンチマークに頼らず、実データで最適なモデルと設定を探す。
• ボトルネックはコーディングから、設計・検証・レビューへ移動。プロトタイプやPRで議論し、古いプロセスは意識的に捨てる。

• Vite + React/TS に Tailwind v4 を入れ、@ を src へ向けるパスエイリアスを tsconfig と Vite 両方に設定する。
• shadcn init 後、components.json の cssVariables を確認。CSS変数でテーマを一元管理する前提を作る。
• トークンは色・角丸・フォントで整理し、色は「役割名」で付ける（--brand と --brand-foreground の対）。--primary をブランド流用しない。
• index.css に OKLCH で値を書く。ダークは .dark で同名トークンを上書きするだけ。
• @theme inline に --color-brand などを登録し、bg-brand などのユーティリティへ接続する。ここを忘れるとクラスが効かない。
• Button を shadcn add。cva（クラス分岐ユーティリティ）に brand バリアントを足し、色は直書きせずトークン参照に統一する。
• ビルドして .bg-brand → var(--brand) に展開されているか確認する。
• 役割ベース命名と統一バリアントが、AIエージェントの出力の手本になる。直書きが混ざるとエージェントも真似する。
• shadcn/skills を導入し、info とテーミング知識をエージェントに渡す。正しい API/パターンでコンポーネント操作ができる。
• 複数プロジェクトは registry で配布。公式更新は add --diff で差分確認し、必要なら --overwrite＋手動マージで追従する。