【翻訳】Design.md：人間とAIエージェントの両方にブランドの視覚的アイデンティティを伝える（Patrick Neeman, UX Collective）

マレットヘア（前髪はきっちり、後ろ髪は遊ばせる髪型）のように、上部は機械向けの堅い記述、下部は人間向けの柔軟な記述になっています。 チームのメンバーとAIエージェントの両方が「信頼できる唯一の情報源（Source of Truth）」として読み込める、たった一つのファイルこそが、今私たちに求められている標準なのです。

---

今日、コーディングAIエージェントに画面の構築を頼んでみて、それが何を使うか観察してみてください。 グレーのマテリアルデザインのボタン、shadcnのカードコンポーネントなど、特定のブランド色を持たないデフォルト設定の寄せ集めになるはずです。

これはエージェントの失敗ではありません。 エージェントが何の手がかりもなく作業しているから起こるのです。 あなたのブランドの視覚的なアイデンティティは、Figmaのファイルやスライド資料、あるいは3人のシニアデザイナーの頭の中にしかなく、ビルド時にAIモデルが読み取れる形式にはなっていないのです。

明文化された「信頼できる情報源」がなければ、エージェントはあなたのブランドを無視して、一般的なコンポーネントに頼るしかありません。 文字通り、見つけられるものであれば何でも使ってしまうのです。

この問題は、リポジトリに保存された1つのプレーンテキストファイルで解決できます。 このファイルでは、上部に「機械が読み取れるトークン」、下部に「人間が読める根拠・理由」という2つの方法でデザインが同時に定義されます。

2026年4月、Google LabsはDESIGN.mdフォーマットをオープンソース化しました。コードの実行方法を示す「README.md」と同じように、ブランドの見た目を示す「DESIGN.md」は、AIモデルが契約書のように読み取るプレーンテキストファイルであり、AIエージェント向けの標準化の第一歩となります。

Design.mdは、AI時代において「Web標準に則ってデザインする」ことの始まりです。かつてL. Jeffrey Zeldmanがその手本を示しましたが、今度はAIエージェントたちがそれに追随しようとしているのです。

この記事では、最初のカラートークンの記述から、実際のサイトに対して行う監査（チェック）に至るまで、あなた独自のDESIGN.mdを作成する手順を解説します。 チャットウィンドウと、あなたのよく知るブランドさえあれば、すぐに始められます。

人間はデザインの根拠を読み、AIエージェントはトークンを読み取ります。両者がその間にある「同じ一つのドキュメント」を見ているのです。

【翻訳】カンパニーブレインAI：あなたの企業の「脳」をAI化する

nanothoughts.substack.com

どの組織にも必ずある難しい問題の一つが、制度上の摩擦です。会話をすると文脈が失われる。ミーティングをすると曖昧なフォローアップが生まれる。人が去るときには、何が決まったかについての認識が人によって違っている。時間が経つと、チーム全体で現実を共有できなくなる。これはまず第一に「AIエージェントの問題」ではありません。人間の調整問題です。全員が頭が良くて、方向性が揃っていて、努力しているときでさえ、調整は難しい。AIはこの問題をより可視化します。なぜなら、AIは作業の進む速度を上げる一方で、その作業の背後にある共有された文脈は、相変わらず脆いままだからです。創業者やCEOにとって、これは「ファウンダーモード」であり続けるのか、それとも「要約」で管理するのかの違いです。ポール・グレアムはファウンダーモードを、組織図の「部分木」をブラックボックスとして扱うのとは別のものとして定義しました。私の言葉で言えば、それは会社の真実（顧客の痛み、製品のトレードオフ、未解決の約束、そして数値になる前の弱いシグナル）との接触です（リンク）。

私が1年以上前にsentraを始めた理由の一つは、いくつかの大規模組織や、創業者として何度かその摩擦を経験したからです。このアイデアを「エンタープライズインテリジェンス」「エンタープライズ汎用知能」「AIチーフオブスタッフ」など、いくつかの名前で呼んでみました。名前は変わりましたが、問題は変わりませんでした。すなわち、「組織は、首尾一貫して推論し行動できるだけの記憶を保てるのか？」という問題です。ここ数日、Yコンビネーターが「カンパニーブレイン」を求める発表をした後、多くの人から「それってあなたが作っているものと同じでは？」とメッセージが届いています。答えは「はい」です。ただ、私たちは最初からその名前で呼んでいたわけではありません。名前がつく前に正確なアイデアを保持するのは難しく、また、正確さよりも単純さのほうが速く伝わることもあるからです。

Sentraだけがこの1年で成長したものではありません。私の娘サタクシは、Sentraを設立してからちょうど1週間後に生まれました。彼女が学ぶ様子を見ていて、問題がはっきりと見えるようになりました。彼女は戦略書から始めるのではありません。スキーマも、オントロジーも、ロードマップもありません。彼女は断片から始めます。顔、声、ジェスチャー、手を伸ばす、抱き上げられる。何かが落ちる、誰かが反応する、そして世界が蓄積されていく。最初はそれが記憶です。やがて記憶はモデルになります。彼女は予測し、試し、最終的には自分が不確かなとき、間違えたとき、驚いたときには自分の推論について推論するようになります。

会社もそれほど変わりません。会社は断片を積み重ねることで成長します。ミーティング、Slackのスレッド、メール、顧客との通話、サポートチケット、ロードマップの議論、営業での反論、投資家向け報告、コードレビュー、廊下での何気ない会話。

問題は、会社がそれらの断片を記憶に変えるスピードよりも速く蓄積してしまうことです。組織記憶の研究者は、記憶を「組織の歴史の中から保存された情報であり、現在の判断に影響を与えうるもの」と定義しています。また、トランスアクティブ記憶の研究は、グループが「誰が何を知っているか」に依存する理由を説明しています（OLK5レビュー、PubMed）。会社が機能するのは、サラが「なぜその顧客にはSSOが必要だったか」を覚えていて、ラヴィが「なぜオンボーディングが遅れたか」を覚えていて、創業者が「なぜダッシュボード上の数字よりも、あの案件が重要だったか」を覚えているからです。

これこそが、Yコンビネーターの枠組みが重要である理由です。YCは、AIによる自動化を妨げる要因を「人々の頭、メール、Slackスレッド、チケット、データベースに散らばったドメイン知識」だと述べました。そして、有用な区別を示しました。それは「会社全体の検索」や「ドキュメントを読むチャットボット」ではなく、「会社がどう動くかの生きた地図」だということです（Y Combinator）。私はそれはほぼ正しいと思いますが、この言葉にはもっと明確な定義が必要です。カンパニーブレインは一つのものではありません。脳も一つのものではないからです。脳は記憶し、関連付け、予測し、振り返り、行動を調整します。カンパニーブレインにも同じような階層構造が必要です。そこで私の定義はシンプルにこうです。カンパニーブレインとは、組織がどのように記憶し、推論し、行動するかについての、生きた、権限管理されたモデルである。

抽象的ですね。具体的にしましょう。

【翻訳】AI時代に営業データを活用しない企業は顧客を失う（Paul, 2026）

saas-tools.medium.com

カンパニーブレインというコンセプトは今、テック業界の至るところに出回っている。Yコンビネーターはそれをスタートアップのウィッシュリストに載せた。VCはそれについての論評を書いている。しかし営業の現場から見れば、これは新しいアイデアではない。これは、営業担当者が去るたび、アカウントが引き継がれるたび、見込み客が「そのことはすでにあなたの同僚に話しました」と言うたびに、あなたが日常的に直面している問題だ。

短い答え： あなたのCRMは「何が起こったか」を追跡する。それは「なぜそれが重要だったか」を覚えていない。そのギャップこそが、商談が死に、引き継ぎが失敗し、新しい人材がすでにあなたの組織のどこかに存在していた文脈を再学習するために3ヶ月を費やす原因である。これを解決するツールは、営業担当者に余計な作業を求めずに知識をキャプチャするものである。手動のドキュメント化を必要とするものは失敗する。私はそれが3回起こるのを見てきた。

簡単な注意書き：私は言及するいずれのツールからも金銭を受け取っていない。アフィリエイトリンクも、スポンサー配置もない。私が製品にリンクを張る場合、それはあなたの便利のためのクリーンなリンクである。

この問題を私に現実のものとしたアカウント引き継ぎ

昨年、私のチームの営業担当者が去った。2週間前の通知だった。彼女は約40のアカウントを抱えており、その中には何ヶ月も進行中のエンタープライズ案件も数件含まれていた。

私たちは引き継ぎを行った。彼女は自身の最大の案件を説明した。CRMのノートを更新した。トップ5のアカウントのそれぞれについてLoomを録画した。

それで十分ではなかった。全く十分ではなかった。

最初の1週間以内に、彼女のアカウントを引き継いだ新しい営業担当者が、CRMでは答えられない質問を抱えて私に電話をかけてきた。なぜこの顧客に15%の割引を与えたのか、当社の下限は10%なのに？本当の意思決定者は誰か。CRMの連絡先は2月以降返事がないのだが。なぜ前回の通話は「Q3に再検討しよう」で終わったのか、クローズ日は6月になっているのに。

CRMにはデータがあった。ディールステージはそこにあった。通話ログも存在した。しかし、あらゆる決定の背後にある理由付け、各アカウントを理解可能にしていた文脈は、それを保持していた人物とともに去ってしまった。

これがデータと記憶の違いだ。あなたのCRMは書類キャビネットのようなものだ。書類を保持するが、何も覚えてくれはしない。

【翻訳】Minions：Stripeのワンショット・エンドツーエンドコーディングエージェント — 第2回（Alistair Gray, Stripe）

stripe.dev

第1回*1のおさらいとして：MinionsはStripeが自社開発した完全無人のエージェント型コーディングフローです。毎週Stripeでマージされるプルリクエストのうち1,300件以上（第1回時点の1,000件から増加）がMinionsによる完全自動生成であり、人間によるレビューは行われますが、コード自体は一切人間が書いていません。

第1回をまだお読みでない方は、Minionsの開発者体験を理解するためにそちらを先にお読みください。本記事では、Minionsの構築方法についてさらに詳しく掘り下げ、Minionsフローの中でもStripe固有の部分に焦点を当てます。

*1:https://hrism.hatenablog.com/entry/2026/02/25/161222

【翻訳】Minions：Stripeのワンショット・エンドツーエンドコーディングエージェント（Alistair Gray, Stripe）

stripe.dev

業界全体として、エージェント型コーディングは「目新しくて刺激的なもの」から「当たり前のもの」へと変化しています。そして、基盤となるモデルの進化に伴い、無人コーディングエージェントは「可能性」から「現実」へと移行しています。

Minions（ミニオンズ）はStripeが独自開発したコーディングエージェントです。完全無人で動作し、タスクをワンショット（一発）でこなすよう設計されています。毎週Stripeでマージされるプルリクエストの1,000件以上がMinionsによる完全自動生成であり、人間によるレビューは行われるものの、コード自体は一切人間が書いていません。

開発者はClaudeやCursorといったエージェントと引き続き計画・協働できますが、開発者の「注意・集中力」が最も希少なリソースである世界では、無人エージェントがタスクの並列処理を可能にします。

典型的なMinionsの実行は、Slackメッセージから始まりCIをパスしたプルリクエストで終わります。その間に人間の介入は一切ありません。エンジニアが複数のMinionsを並列起動し、多くの異なるタスクを並行して完了させる光景はよく見られます。これはオンコールローテーション中に発生する多数の小さな問題を効率的に解決する際に特に有効です。

このブログ連載の第1回では、エンジニアがどのようにMinionsを使い、何ができるのかをご紹介します。第2回では、内部実装とその構築方法について詳しく解説します。

【翻訳】Claude Code 開発者自身による Claude Codeの実力を高める10のTips（Boris Cherny）

I'm Boris and I created Claude Code. I wanted to quickly share a few tips for using Claude Code, sourced directly from the Claude Code team. The way the team uses Claude is different than how I use it. Remember: there is no one right way to use Claude Code -- everyones' setup is…

— Boris Cherny (@bcherny) January 31, 2026

Borisです。Claude Codeを作りました。Claude Codeチームから直接集めたTipsをいくつか手短に共有したいと思います。チームのClaudeの使い方は私の使い方とは異なります。Claude Codeに唯一の正解はありません。人それぞれセットアップは違います。自分に合うものを試してみてください！

1. もっと並列で作業しろ

git worktreeを3〜5個同時に立ち上げ、それぞれで独立したClaudeセッションを並列実行する。これがチームからの一番の生産性向上Tipsです。私個人はgit checkoutを複数使っていますが、Claude Codeチームの大半はworktreeを好んでいます。@amorrisscodeがClaude Desktopアプリにworktreeのネイティブサポートを組み込んだのもそのためです。

worktreeに名前を付けてシェルエイリアス（za, zb, zc）を設定し、キー1つで切り替えられるようにしている人もいます。ログ確認とBigQuery実行専用の「analysis」worktreeを持っている人もいます。

2. 複雑なタスクは必ずプランモードから始めろ

プランに全力を注ぎ込めば、Claudeが実装を一発で決められます。あるメンバーは一つ目のClaudeにプランを書かせ、二つ目のClaudeをスタッフエンジニアとしてレビューさせています。別のメンバーは、何かおかしくなった瞬間にプランモードに戻って再計画すると言っています。無理に押し通すな、と。また、ビルド時だけでなく検証ステップでも明示的にプランモードに入るようClaudeに指示しています。

3. CLAUDE.mdに投資しろ

修正するたびに、最後にこう言う：「CLAUDE.mdを更新して、同じミスを二度としないようにしろ。」Claudeは自分自身のルールを書くのが異様にうまい。CLAUDE.mdは時間をかけて容赦なく編集し続けろ。Claudeのミス率が計測可能なレベルで下がるまで反復し続けろ。あるエンジニアはClaudeにタスク/プロジェクトごとのnotesディレクトリを管理させ、PR後に毎回更新させています。そしてCLAUDE.mdからそれを参照させています。

4. 独自のスキルを作成してgitにコミットしろ。全プロジェクトで再利用しろ。

• 1日に2回以上やることは、スキルかコマンドにしろ
• /techdebtスラッシュコマンドを作り、毎セッション終了時に実行して重複コードを見つけて潰せ
• 7日分のSlack、GDrive、Asana、GitHubを1つのコンテキストダンプに同期するスラッシュコマンドを作れ
• dbtモデルを書き、コードレビューし、dev環境でテストするアナリティクスエンジニア型エージェントを構築しろ

code.claude.com

5. Claudeはほとんどのバグを自力で直す

• Slack MCPを有効にして、Slackのバグスレッドをそのまま貼り付けて「fix」とだけ言う。コンテキストスイッチがゼロ。
• あるいは「CIの失敗テストを直せ」とだけ言う。やり方を細かく指示するな。
• 分散システムのトラブルシューティングにはClaudeにdockerログを見せろ。驚くほど対応できる。

6. プロンプティングのレベルを上げろ

1. Claudeに挑ませろ。「この変更を厳しくレビューしろ。テストに受かるまでPR作るな。」と言う。Claudeをレビュアーにしろ。あるいは「これが動くことを証明しろ」と言って、mainとfeatureブランチの振る舞いの差分をClaudeに取らせろ。
2. 微妙な修正の後は、こう言え：「今知っていることすべてを踏まえて、これを捨てて、エレガントな解決策を実装しろ。」
3. 作業を渡す前に詳細な仕様を書き、曖昧さを減らせ。具体的であればあるほど、出力の質は上がる。

7. ターミナル＆環境設定

• チームはGhosttyが大好き。同期レンダリング、24ビットカラー、適切なUnicodeサポートを気に入っている人が複数いる。
• Claude操作を楽にするには、/statuslineでステータスバーをカスタマイズし、常にコンテキスト使用量と現在のgitブランチを表示させる。
• 多くのメンバーはターミナルタブを色分け・命名し、tmuxを使う人もいる（タブごとにタスク/worktreeを対応させる）。
• 音声入力を使え。タイピングの3倍速く話せるし、プロンプトがはるかに詳細になる。（macOSではfnキーを2回押す）

8. サブエージェントを使え

1. Claudeにより多くの計算リソースを投入させたいリクエストには「use subagents」を付け加えろ。
2. 個別タスクをサブエージェントにオフロードして、メインエージェントのコンテキストウィンドウをクリーンかつ集中した状態に保て。
3. 権限リクエストをhook経由でOpus 4.5にルーティングし、攻撃をスキャンして安全なものを自動承認させろ。

9. Claudeをデータ＆アナリティクスに使え

• Claude Codeに「bq」CLIを使わせて、その場でメトリクスを取得・分析させろ。
• チームのコードベースにはBigQueryスキルがコミットされており、全員がClaude Code内で直接アナリティクスクエリに使っている。
• 私個人は6ヶ月以上SQLを1行も書いていない。
• これはCLI、MCP、またはAPIを持つあらゆるデータベースで機能する。

10. Claudeで学習しろ

1. /configで「Explanatory」または「Learning」出力スタイルを有効にして、Claudeに変更の理由を説明させろ。
2. 馴染みのないコードを説明するビジュアルHTMLプレゼンテーションをClaudeに生成させろ。驚くほど良いスライドを作る。
3. 新しいプロトコルやコードベースを理解するためにASCIIダイアグラムをClaudeに描かせろ。
4. 間隔反復学習スキルを構築しろ：あなたが理解を説明し、Claudeがフォローアップ質問でギャップを埋め、結果を保存する。

これらのTipsが役に立てば幸いです！次は何について聞きたいですか？

1秒の改善で何%向上？ページ速度とCVRの関係を主要5社のデータから徹底検証

※こちらの記事は、筆者がUX Collectiveに寄稿した下記の記事を、日本語向けに再編集したものになります。

medium.com

はじめに

読み込み速度の改善がCVR向上に繋がるのは皆さん体感的に納得できると思います。でもどれぐらい改善したらどれぐらいCVR向上するかはデータが乱立しています。今回、その状況を整理して、一般的なWebサイトの改善にも適用しやすいようにしました。

なお、ページ速度の測定にはGoogle PageSpeed Insightsという無料ツールが広く使われており、本記事で登場するSpeed Index、LCP、FCPなどの指標もこのツールで簡単に確認できます。自社サイトの現状把握から始めたい方は、まずはこのツールでチェックしてみることをお勧めします。

各社の研究データが示す数値の幅

ページ速度改善によるCVR向上については、様々な企業や研究機関がデータを公開していますが、その数値には大きな幅があります。

改善による向上データ

企業・研究機関	改善幅	CVR/売上への影響	1秒換算	出典
Google	1秒改善	最大27%向上	27%	Tuff
Walmart	1秒改善	2%向上	2%	Huckabuy
Mobify	100ms改善	1.11%向上	11%	Cloudflare
Amazon	100ms改善	1%売上増加	10%	Acclaim
Deloitte	0.1秒改善	8.4%向上	84%※	Tuff

※明らかに外れ値と考えられる

最も楽観的なGoogleの27%から、保守的なWalmartの2%まで、実に10倍以上の開きがあることが分かります。Deloitteの研究を1秒に換算すると84%となり、これは明らかに現実的ではありません。

遅延による低下データ（参考）

企業・研究機関	遅延幅	CVRへの影響	出典
Akamai	1秒遅延	7%低下	複数
Aberdeen Group	1秒遅延	7%損失	Tuff
Portent	1秒追加（0-5秒間）	平均4.42%低下	Huckabuy

興味深いのは、改善による向上と遅延による低下では効果が非対称だという点です。失うのは簡単でも取り戻すのは難しいという現実を示しています。

なぜこれほど数値がバラバラなのか

これらのデータがこれほど異なる理由は、測定条件の違いにあります。まず、初期速度が大きく影響します。既に3秒以下で表示される高速なサイトでは、さらなる改善の効果は限定的です。一方、10秒以上かかるような低速サイトでは、最初の数秒の改善だけでも大きな効果が期待できそうに思えますが、実際には極端に遅いサイトでは、ユーザーの期待値が既に低下しているため、初期の改善効果は意外と限定的になることもあります。

業界特性も重要な要因です。ECサイトでは購買行動が速度に敏感に反応しますが、B2Bサイトでは情報収集が主目的のため、多少の遅延は許容される傾向があります。また、既存の最適化状況も大きく影響します。基本的な画像圧縮やキャッシュ設定すら行われていないサイトと、高度に最適化されたサイトでは、同じ1秒の改善でも意味が全く異なります。