メンタルモデル：AIが伸ばすのはT型人材の「横」

デザイン界には「T型人材」（T-shaped）という古い言い方があります。縦棒はいちばん深く掘った専門——UX、UI、リサーチ、モーションなど。横棒は他領域にまたがって物事を前に進める幅。同じ水準・同じ速度は要らず、仕事を動かせれば足りる、というものです。

AIが伸ばすのはその横棒です。不得意な領域でも、かなり速く動けるようになりました。

ここで彼はかなり正直な限定を置いていて、そのまま覚えておく価値があります。この伸びは領域でも人でも違う。たとえば高品質なビジュアルデザインではAIはまだ弱い——少なくとも彼自身の基準・自分への要求では。一方、デザインに詳しくない開発者がシンプルなランディングをAIに作らせると、十分見られるものが上がってくる、と。

第二層のモデルは「デザイナーの仕事とは何か」。彼は芯まで剥がします。問題を理解し、ビジネス・技術・プロダクトをまたぐ関係と影響を理解し、それらをひとつにまとめる案を見つける。実務では、方向と発想を何度も入れ替え、合った瞬間までイテレートする、ということです。

AIはこのループを速く回します。彼はAIをスケッチや紙プロトタイプのように使う、と言います。成果物そのものが本題ではなく、「当たり前」の層を越えて思考を押し出すことが本題だ、と。

ワークフロー1：週報とチケットは Claude Skill に任せ、彼は承認かスキップだけ

まず前提。ここが写しやすさを決めます。FitXR には従来型のプロダクトマネージャーがいません。プロジェクトとその日常運用は、担当の現場が自分で抱えます。スケジューリング、すり合わせ、チケット作成、進捗更新、マネジメントへの報告——すべて本業のデザイン／エンジニアリングの上に載る。だから自動化できるものは徹底的に自動化する、という姿勢です。

使っている組み合わせは Claude + Skills + Slack・Granola・Linear に繋ぐ MCP。Granola は会議記録ツールで、通話を文字と議事に起こす。Linear はチームのプロジェクト／タスク管理ツールです。

チェーンは3ステップ：

Granola がコンテキストを拾います。チームはリモートで、文脈は Slackスレッド、スタンドアップ、会議通話に散っています。これがあると、会議中はメモに伏せず、本当に場にいられる。週末になると Skill が文字起こしと Slack を走査し、職能・同僚ごとに Linear の進捗更新を下書きします。

2つ目の Skill は「ドリフト」担当。彼らのチームは「Slackで決めたら、もうSlackの外に出ない」ことで悪名高い、とのこと。この Skill は会話と Linear のチケットを突き合わせ、範囲が変わったのに未同期、状態の誤記、決めたのに未記録などをマーク。各提案を本人が一度見て、承認かスキップ——数分で終わります。

今は6案件に同時に巻き込まれています。同じ大きな絵の中でも、細部・難所・断片はそれぞれ違う。数か月前なら、この投入度では1案件しか見られなかった。本人の判断はこうです。全部を手作業で追えば、フルタイム1本分になりやすい。AIは投入と理解の代わりにはならないが、反復的で極端に時間を食う部分は外せる、と。

Skill 原文はスクショの中：起動条件の書き方と出力テンプレ

この節の内容は本文では一言も触れられておらず、上のスクショ中央から読み取ったものです。Skill 名は linear-status-update。起動は「スラッシュコマンド＋自動」。

説明文のほとんどは「いつ出るか」に費やされている

説明の大半は、ユーザーがどう口にするかの列挙です：draft an update for the project、write a status update、update Linear based on slack、write a project update from our meetings、pull together a project update、さらに「任意のソース（Slack、Granola、会議）×任意の行き先（Linear、プロジェクト更新）」の組み合わせ。最後に保険の一文：

直近の動きを Linear 更新にまとめるなら、この Skill を使う。ユーザーが「skill」の語を出していなくても。

スクショ内の Skill 説明、当サイト訳

この書き方自体が学びどころです。Skill を書く人は「どうやるか」に力を注ぎがちで、出るべき場面で呼ばれない。起動条件が具体で、人の実際の言い回しに近いほど、信頼性が上がります。

ステップ3：書き出す前に、何が新しいかを整理

Step 3: Identify what's new
Before drafting, work out:
- What has happened since the last update?
- What decisions were made?
- What was completed? What's in progress?
- Are there any timeline changes, milestone shifts, or blockers?
- Is there any significant engineering or enablement work worth
  calling out?

Focus on substance. Ignore noise like channel join messages, bot
notifications, and minor logistics. If something was already
covered in a previous update, don't repeat it.

最後の2文がいちばん写すべき部分です。週報が読みにくいのは、情報不足よりノイズ過多と先週の繰り返しであることが多い。「何を無視するか」を書いた方が、「何を書くか」より効きます。

ステップ4：まずそのプロジェクト既存の形式を踏襲。無いときだけデフォルト

ステップ4の一文目は「このプロジェクトの既存更新の形式とトーンに厳密に従う」。履歴が無いときだけ、次のデフォルトを使う：

# DD.MM.YY - [Project Name] Update

## Status:

* :[emoji]: [On Track / At Risk / Off Track]

[Optional: one or two sentences of framing context — a key
decision, headline shift, or anything needed to set the scene.
Omit if there's nothing essential to say here.]

## Last Week:

**[Workstream]:**
* [What happened — @mention relevant people where useful]

ワークフロー2：当たり前のアイデアをAIに先に吐き切らせる

本人も「比較的当たり前の使い方」と言っていますが、考え方の部分が面白い。

彼はAIに「あの答え」を期待していません。多くの場合それは出ない。AIが本当に得意なのは、当たり前で単純で、時には少し馬鹿なアイデアを、非常に速く吐き切ることです。

創作の過程では、最初に出る案はいちばん予測しやすいものが多い。その層を越えて初めて、少し面白いところに触れる。AIがその層を加速するので、白紙から始めず、取っ掛かりを手元に持てる、と。

二つ目は本当に詰まったとき。奇妙なエッジケース、変数が山ほど、どの選択肢もしっくり来ず、トレードオフだらけでループから抜けられない。そこでAIに可能な方向を素早く広げさせる。方向そのものは完璧ではないが、広げたあとで空間とトレードオフがはっきり見える。それで前に進めることが多い、と。

ワークフロー3：素材を渡して構造ドラフトをAIに出し、人が直して磨く

ここからAIが「本物のスーパーパワー」に見えてくる、と彼は言います。大量のデータ・論理・動く部品を消化する場面。型は固定です。

事例：Checkpoints

最近手がけた案件は「Spotify Wrapped」に近い、マイルストーンのお祝い。ユーザーにデータ・実績・ハイライトのまとめを届け、特別でパーソナルに仕上げる必要があります。

紙の上では素敵に聞こえますが、実装と論理を考え始めると一気に複雑になります。難所は具体的。8つのフィットネスカテゴリ（原文 eight studios。格闘、ボクシング、HIIT、ダンス、ズンバなど）があり、カロリーやコンボスコアなど共有指標もある一方、多くは全く違う。格闘・ボクシングはパンチ数、HIIT・ダンス・ズンバは歩数。さらに収集しているがUIに出したことのないデータも山ほど。

開発から生データダンプを受け取り、手作業での整理は「正直、悪夢」だった、と。

· プロジェクト背景
· 達成したいこと
· データファイル
· Figma デザインのリンク
· 各画面の説明ノート

成果への評価は控えめです。ここはほぼそのまま：完璧ではない。問題もいくつかあり、使いたくないデータ、誤解や誤った仮定もある。でもそれが本題ではない。白紙から自分で整理しなくてよく、強い出発点を手元に持てたこと。そこから掘り下げ、塊ごとに精緻化し、本番に入れられるまで磨く。

副産物として、チームに配れる構造化ドキュメント——全隊の単一の真実源——も手に入りました。重みのある一文があります。昔なら1週間かけてゼロから作って誇れた種類の成果物。今回は1日もかからず、しっかりした版が手元にあった。

AIが書いたデータロジック文書：ハイライト候補20＋5ステップ選択アルゴリズム

本文では一文で流していますが、スクショでは文書全体が開かれています。名前は DATA-LOGIC.md。冒頭の一文が自己規定：

本ドキュメントは各画面に何のデータを出し、どこから来て、どう計算するかを定義する。プロトタイプのイテレーションではこれを正とする。

DATA-LOGIC.md 冒頭、当サイト訳

中身は4ブロック。後ろほど具体的：

良いハイライトの定義は文書に固定されている

彼は後でこの文書を閲覧可能な説明サイトにしました。そこの定義が、本稿でいちばん持ち帰る価値のあるプロダクト判断です：

ハイライトとは、その章でいちばん印象に残る、具体的な一つの数字。集計指標ではなく、具体的な記憶のように感じられる必要がある。

良いハイライトの条件：具体で人が読める（312パンチであり、総合スコア72.4ではない）；ある1回のトレーニングに紐づく；checkpointごとに変わり、飽きさせない。

Checkpoints データロジック説明サイト、当サイト訳

「312パンチであって総合スコア72.4ではない」——この一文で、この手の機能の成否はほぼ言い切っています。

選択アルゴリズム5ステップ

20候補のうち画面に載るのは最後1つ。その根拠がこの5ステップ。本稿でいちばんそのまま持ち帰れる部分です：

1. フィルタ  章全体でキー項目が空／ゼロの候補を除外；
         粒度条件を満たさない候補を除外
         （例：複数クラスが無い日 → 「単日」級はスキップ）

2. スコア  score = 値 ÷ その指標の「十分すごい」しきい値

3. 選定  最高スコアが勝ち；
         同点は粒度が細かい方（単一クラス > 単一ワークアウト > 単日 > 章全体）
         理由：具体ほど記憶に残る

4. 多様性  同じカテゴリが前回checkpointで勝っていたら
         スキップし、次点を採用

5. サブタイトル  単一クラス → "{クラス種別}, {日付}"
         単一ワークアウト → "Workout, {日付}"

分岐フローのプロトタイプ：最初の2回は失敗——Figmaは制御不能、Googleドキュメントは読まれない

本稿でいちばん有用な経験談。失敗の方が成功より詳しく語られているからです。

案件名は Positive Friction。FitXR での最初の大型案件で、新規オンボーディングの作り直し。方向は「遊び始めるまでの時間を最短に」から、はるかにパーソナルなフローへ。ユーザーは長めの質問列をいくつかの段で歩き、答えに応じて異なるインサイトを見て、最後にパーソナルなハイライト群と目標達成プランを受け取る。彼はほぼ全部持ちました：問いと答え、論理と分岐、インサイト画面、最後はハイファイデザインまで。

1回目：FigJam と Figma で描き、ほぼ即・制御不能

まず FigJam でフローをマップし、Figma で小さなプロトを作り、答えとインサイトの経路を示しました。ほぼ即・管理不能に。組み合わせと条件が多すぎ、小さな変更が全体に波及します。

2回目：脚本にしてレビュー依頼。フィードバックはほぼゼロ

内容に集中せよ、と誰かが提案。問い・答え・分岐論理を Google ドキュメントに——ほぼ脚本——入れ、それでレビューする、と。

結果、フィードバックはほぼ取れませんでした。本人も「当然だ」と認めています。読むのが苦痛だから：

フローが体感できない。長すぎるか判断できないし、問いが良いかも分からない。体験のテストなど不可能だ。

Krystian Zun、当サイト訳

ここまで来て——本人いわく半ば絶望から——浮かんだのが、「自分のプロダクトやアイデアにもAIを使ってきたんだから、このドキュメントをAIでプロトタイプにできないか？」

うまくいきました。しかもかなり良い。

AIプロトに換えたあと：論理の1か所変更がデータの1行変更に

まず Figma の境界線。大半のデザイン仕事は問題ないが、一部の案件が渡すのはシステム一式——分岐、論理、パーソナライズ、変化し続ける状態。画面の連なりは表層にすぎない。それを Figma でプロト化するのは、本人いわく「つらいからほぼ不可能」。

AIに換えてからは、ビジュアル設計に入るまでほぼ Figma を触らず、AIで本物の体験をイテレート：内容、問い順、分岐論理、インサイトの見せ方、入力方式まで。

最大の差はフロー全体を一度にイテレートできること。「この問いを変えろ」「この段を前へ」「このインサイトの見せ方を変えろ」「この答えの論理を更新」——まず真実源ドキュメントを手で直し、プロトの隅々に書き戻す、という二重作業が不要。フィードバックを会話に投げれば、AIが全体を一度に直す。

イテレーションの速度と深さが根底から変わった。もう画面のプロトではなく、振る舞いのプロトをしている。

Krystian Zun、当サイト訳

スクショから見えるプロトの組み立て

プロジェクト名は positive-friction、Next.js アプリ。ディレクトリ上のいちばん重要な決定は、リポジトリに docs/ があること。BRANCHING_LOGIC.md、BRANCHING_LOGIC_EXAMPLES.md、QUESTIONNAIRE_OVERVIEW.txt が入り、論理説明とコードが同じリポに同居。AIがコードを直すときルールも同時に読めます。

QUESTIONNAIRE_OVERVIEW.txt は平易な言葉の仕様書。スクショの実内容：第2問は「フィットネス（または FitXR）での主な目標は？」、5択——エネルギー向上とストレス軽減 / 減量ともっと健康に / 筋肉とシェイプ / 楽しく遊ぶ / 柔軟性向上。下に星枠でこれは分岐問で、以降に出る問いを決めると明記。続けて BRANCH A： 「エネルギー向上とストレス軽減」を選んだ人だけが、次の「いちばん元気が欲しいのはいつ？」と、その後のつなぎ画面を見る。

そのつなぎ画面の文案は、さらに前の答えに応じて3版のどれかに切り替わります。下はクリックできます：

仕掛けはフィールド2つだけ

コード側の対応は questionnaire-data.ts。上の仕組みはフィールド2つで支えられています：

// 条件表示：前の問いが指定答えなら、このステップを出す
showIf: {
  conditions: [
    { questionId: "goal-selection",
      operator: "equals",
      value: "have-fun" },
  ],
}

// 動的文案：前の問いの答えで、この画面の内容を差し替え
dynamicContent: {
  questionId: "fun-type",
  contentMap: {
    "music-rhythm":       "...",
    "competition":        "...",
    "variety-surprises":  "...",
    "feeling-connected":  "...",
  },
  defaultContent: "Got it — we'll fill your plan with the
                   kind of fun that keeps you hooked.",
}

他の整理もきれいです。lib/ 下は責務ごとにデータ・条件・動的内容・状態・型の5ファイル。UIコンポーネントと画面は各1ディレクトリ。小さな設計として DebugNavigation.tsx——起動中プロト左上の Debug ボタンで、レビュー時にスキップでき、毎回最初から答えなくてよい。

フィードバックの取り方：プロトをリンクにデプロイし、Slackへ

本文でも書かれていませんが、フローが回る鍵です。プロトを vercel.app にデプロイし、リンクをそのまま Slack に投げる。構造化した説明付き：今回の変更、特に欲しいフィードバック、次の一手。

もう一つ賢い小技：同僚のフィードバックを txt にまとめリポへコミット。git 履歴に Create sams_suggestions_v2.txt と add sam's notes to breakdown。フィードバックがリポに入ると、AIの次回修正で直接読めます。

この案件は社史上いちばん成功した実験のひとつになった、と言います——数字は一切なし。本人の整理では、AIが「速くする」だけでなく、本来起きにくかった版を可能にした例だ、と。

ワークフロー5：4つのAgentがPaper上で並列にUI描画、1画面約3分

まず総括：ここまでの多くは論理・システム・構造で、AIが最も強い領域。一方、精緻で本番投入できるUIについては、しっかりしたデザインシステムが下支えしない限り、AIはまだ弱い、と彼は見ています。

ただ最近試している2つがあり、本気で興奮しています。

Paper：AIに描かせる無限キャンバス

Paper はキャンバス型デザインツール。Figma に似ているが HTML 基盤で、私有フォーマットではなく、最初から AI と MCP ワークフロー向けに設計された、と。まだ alpha で基礎機能も欠けており、今すぐ Figma の代わりにはならない、と明言しています。

ただし AIエージェントが創作する無限キャンバスとしては、かなり先を行っている、と。複数Agentを同時に走らせ、レイアウトや方向を並列に探れる——1つずつではない。よく書けた design.md を添えると「意外と良い」。HTML基盤なのでデザインとコードの溝がほぼ消え、小さな実験では Paper で Figma コンポーネントを再現し、AIにそのままコードベースへ入れさせました。

スクショ右下のステータス行が、本文に無い硬い数字を示します：

もっと見るべきは自分で自分を検査する点。ログのやり取りはこう：「配置できた。スクショを撮って品質を確認する」→「良さそう！下端で内容が切れている。アートボードを fit-content に」→「fit-content できれいに解消」。「生成 → スクショ自検 → 発見 → 修正」のループこそ、本当に仕事になる理由で、一発生成で終わりではない。

締めの報告ではデザインシステム準拠が見え、粒度はここまで：ステータスバーは #FAFAFA ニュートラル殻＋ダークアイコン、ナビタイトルは Barlow 700、アバターに #3B8AF3 の青リング、データ行は白カード3枚（トレーニング数／連続日数／カロリー）、週目標プログレスは青塗り白レールで達成80%、退出は #E4FE5B レモンイエローのピル＋ダーク文字。注記も「レモンイエローは FitXR 規約で主要CTA専用」「青の強調色の一貫性：数値・PROバッジ・プログレス塗り・アイコン着色はすべて #3B8AF3」。

モーションは不得意なので、AIに先に探らせ、自分は別作業

この条は冒頭のT型モデルに戻り、因果の環を閉じます。

モーションへの態度は具体的。敬意はあるし、きれいなアニメはプロダクトの感触を一気に上げる。だが自然に速くできる領域ではない。触るたびに少し身構え、主に時間が溶けると分かっているから。難所は、静止フレーム間からトランジションを想像しにくいこと、さらに「きれい＋少し独自」を思いつくこと。これは彼の縦棒ではない。

今のやり方は素朴：文脈を渡し、アイデアを述べ、キーフレームや静止画面を渡し、AIにトランジション案を出させるか、直接その間をアニメにする。

自己評価も正直：プロのモーションデザイナーには基礎的でも、彼のような人には十分有用。ずっと良い出発点まで連れていき、そこから自分で精緻化・研磨できる。

最後の着地：AIは何でも得意にしてくれたわけでも、センス・判断・問題理解の必要を消したわけでもない。渡すのはレバレッジ——より速く始め、より多くの方向を探り、より複雑なものを扱い、弱分野でも仕事ができ、複数を同時に前へ。だから本当の機会は、働き方をその周りで再設計すること：どこを握り、どこを渡し、どこで脱出し、どこで思考の面積を広げるか。小さなタスクから数分削るのは、最小の部分の利得にすぎない。

語られなかったこと：AIが足を引っ張る場面がある、と言いながら例がゼロ

この方法アーカイブには穴がいくつかあり、写す前に知っておく価値があります。

1. いちばん惜しい点。冒頭で、試行錯誤の結果AIが役に立たない／遅くなる／手の方が早い場所が見えた、と明言しながら、具体例は一つもない。方法文では「使わない場面」の方が「使う場面」より価値が高いことが多いのに、ここは丸ごと欠席です。

2. 「6プロジェクト」に量的対照が無い。どれくらいが1案件か、投入量、品質低下の有無は未記載。「社史上いちばん成功した実験のひとつ」も数字なし。継続率・転換・完了率もゼロ。すべて本人の言い方です。

3. 組織前提が多くの読者に当てはまらない。6同時が可能なのは、FitXR にPMがおらず現場が担う前提。専任PMがいるチームでは、彼が外した仕事はもともとデザイナーの手元に無く、レバレッジは自然と小さくなります。

4. Skill は2つあるのに見えるのは1つ。週報側はスクショから完全再現できるが、「ドリフト」側は何も見えない。後者の方が書くのが難しく、面白そうに聞こえます。

5. design.md のサンプルが無い。「よく書けた design.md を添えると意外と良い」と言いながら、中身は一言も無し。Paper 節の Agent 報告の粒度（特定色は主要CTA専用、まで）から見ると、効果の良し悪しを決めたのは多分そのファイル——出していないのが惜しい。

まず前提。写しやすさはここ次第：FitXR に従来型PMはおらず、スケジュール・チケット・週報・マネジメント報告は現場の本業の上に載る。彼はこの流れを Skill（AI向け固定手順：いつ出るか、何ステップか、成果の形）にし、週末ごとに回す。

Granola が通話を文字化し、会議中は本当に場にいられる。Linear はチケットと進捗の場。最後の関門は常に人。スクショの Skill 原文で写せる2点：起動条件が実際の言い回しを列挙し、skill の語が無くても使えと末尾で補足。手順に無視対象——参加通知、ボット、前回済み——を明記。

より硬い一式がこれ：生素材を渡し、AIに構造初稿、人が直し磨く。機能は Spotify Wrapped 系の段階まとめ。難所は8フィットネスカテゴリで指標が違う（格闘・ボクシングはパンチ、HIIT・ダンスは歩数）ことと、収集済みだがUI未出のデータ山。背景・達成目標・データ・デザイン稿リンク・各画面のメモを一括で渡し、データロジック文書——各画面の表示、出典、計算、Figmaノード番号まで対応——を受け取る。昔は1週間ゼロから、今回は1日未満で堅い版（本人の言い方）。

20候補が入り、1つが画面へ。ルールはAIが文書に書き、彼が採用。同じ文書にToDoも：既存フィールドだけでは授業を同じトレーニングに確実に帰せない——未決問題として明示し、綺麗な言葉で糊塗していない。

分岐付きオンボーディングのプロトは最初の2回失敗。FigJam／Figma では組み合わせと条件が増えると制御不能で、1か所の変更が全体に波及。問い・答え・分岐を Google ドキュメントの脚本にしてレビューしてもFBほぼゼロ——読めばフローが体感できず、長さも測れない。3回目でAIに走れるWebプロトにさせ、リンクをSlackへ。結果「論理1か所」が「データ1行」に。

UI描画では判断が保守的：精緻で本番投入できる画面は、堅実なデザインシステム無しではAIはまだ弱い、と。試しているのは Paper（キャンバス型、HTML基盤で私有フォーマットではなく、描いたものが走れるコードに近い）：Claude Code Agent 4つが同時に設定・プロフィール・トレーニング詳細・ペイウォールを描く。ログではスクショ自検、下端切れ発見、高さ適応へ修正——この自検・自修ループこそ仕事になる理由。