自分に合わせて道具を整える

Web には design skills のようなスキルやハーネスが数多く公開されていて、優れたものがたくさんあります。ただ、私の場合ダウンロードしてそのまま使うことは、ほぼありません。作者の身元が不明だとプロンプトインジェクションのリスクがあり、警戒しているのも事実です。ただ、理由はそれだけではありません。

公開されているスキルは、誰が使っても破綻しないように整理されていて出来は素晴らしいものが多いです。しかし、実際使ってみると「なんとなく違う」と感じることがあります。一見すると同じ仕事（タスク）でも、働き方は人によって異なります。その違いは、使うツールや手段だけではありません。物事の捉え方や言葉の選び方にも、その人らしさが表れてきます。そうした小さな違いの積み重ねが、結果として「なんとなく違う」という感覚につながっていくのだと思います。

だからといって、他の方が作ったスキルを全く見ていないというわけではありません。 代わりに AI にダウンロードしたスキルを共有して「自分はこのような使い方を想定していますが、スキルの中で活用できる部分はありますか？」と尋ねることがあります。また、「自分が使うなら、このような状況や手順を想定しています。ほかに考慮すべき点はありますか？」といった質問もしています。他の方のスキルを自分のメンタルモデルや言葉遣いに合わせてカスタマイズしている感覚に近いです。

昔は、自分自身のツールや環境を作るのは非常に手間がかかりました。例えば、Illustrator はスクリプトで標準機能にはない処理を自分で作ることができます。スクリプトが書けない人は、公開されているスクリプトは探して利用できますが、「少し手を加えたい」と思ったときに、自分で調整できる人はごくわずかでした。知識のある方が作ったスクリプトをそのまま使うしかなく、スクリプトの挙動に自分の働き方を合わせるしかありませんでした。

しかし、今はそんなことはありません。
自分の働き方に合わせて、必要な道具を自分で作れるようになりました。「ああでもない」「こうでもない」と AI と対話しているうちに、いつの間にか道具が出来上がることもあります。だからこそ、評判の良いスキルを見つけても、そのまま使わず、自分の環境に合わせて書き直すか、それを土台にして別のものを作っています。

AIによって広がる素材に触れるデザイン

AIを、自分の仕事の成果物を代わりに作ってもらうツールと考えるのではなく、自分の仕事の幅を広げるための道具として捉えてみるとどうでしょうか。

Yasuhisa HasegawaYasuhisa Hasegawa

文脈も変わり続けるからこそ

スキルに限ったことではないですが、作れるようになったことで「手入れを続ける」という別の課題が浮上しています。

庭と同じで、手を入れるのをやめた途端に荒れ始めます。しばらくメンテナンスをしていなかったスキルは、前提している状況が古くなって、使っても望んでいる出力にならないことがあります。世話はAIに任せればよい、という考え方もあります。しかし、すべてをAIに丸投げすると、いつの間にか不要な情報によって汚染され、役に立たない道具へと変わっていきます。

まるで庭の手入れをするように書き換えや整理をしていたのがお盆でした。今は、この仕組みの手入れに十分な時間をかけないと、すぐに品質が落ちてしまうように感じます。自分の働き方を変えたときだけでなく、AIモデルが入れ替わっただけでも、出力品質が大きく低下することがあります。もちろん、ツールやワークフローに異なる要素が加われば、SKILL.md の見直しも必要です。チームメンバーが加わると、さらに複雑化します。

正直、手入れは面倒です。
それでも、私は自分でスキルを作って手入れをすることをオススメします。スキルやハーネスの作り方が学べるだけでなく、AI一緒に働くときの手触りを知ることができるからです。どこから任せ、どこから自分で確認するのか。どう書けば、より伝わりやすいのか。いろいろテクニックとして紹介されていますが、実際に自分の言葉で伝えてみなければ、分からないこともたくさんあります。

CLAUDE.md や Agent.md のような設定ファイルがどれくらい更新されているのかという研究もあって、初期はおよそ1日に1回は更新されるそうです。現段階では自分で手入れをするのは当たり前の行動とも言えます。

Agent READMEs: An Empirical Study of Context Files for Agentic Coding

arXiv logoyutaro.kashiwais.naist.jp

公開されているスキルやハーネスは、そのままダウンロードして使うのではなく、まず中身を読んで、自分の環境に合わせて作り直してほしいです。少し手を加えるだけでも構いませんし、それを土台に、まったく新しいスキルを作るのもよいでしょう。また、一度作って「完成」とするのではなく、変わり続ける状況に合わせて、少しずつ手入れしながら育てていくことも大切です。手間はかかりますが、その過程で身につく感覚は、長く役立つものになります。

「役割は広がる」と言われるが

2026年6月に Figma が発表した「 2026 AI report 」は、この手応えをそのまま裏づけています。デザインが重要だと答えた人は90%、以前より重要になったと答えた人は60%。AIで何でも作れるようになったからこそ、何を作るべきか問う必要があるというメッセージもレポートには込められています。このレポートを読んで「確かにそうだ」と思ったデザイナーは多いと思います。

一方、ほぼ同じ時期に公開された Lenny の「 How tech workers are feeling in 2026 」は少し違う風景を映し出しています。「さらに重要になる」という Figma のレポートとは対照的に、こちらではデザイナーの焦りや疲れが感じられます。例えば、いっぱいいっぱいだと答えた人が63%、疲労を感じている人は61%で全職種の中で最も高いです。リサーチャーも、職を失う不安が51%あります。そしてデザイナーとリサーチャーは、自分の分野を人に勧めないと最も多く答えた職種でした。

やれることが広がり、エキサイティングだと言われている当の本人たちが、最もネガティブな数字を出しています。この食い違いはどこから来るのでしょうか。どちらが間違っているわけでもなく、私たちの心にある二つの側面が表れているだけとも言えます。

私自身「AIを使っていろいろ試すのは楽しい」と言っていますし、ポッドキャストのゲストの方でも似た感覚を持っている人が多いです。これは Figma のレポートでもよく表れてます。ただ、私たちが言う「楽しい」とは、あくまで表現の幅が広がったことを指しているだけで、「デザイナーという立場のままで仕事が楽しくなること」とは別の問題です。Figma Make などを使えばアイデアを形に出来ますが、デザイナーの立場が業務の中で強くなるのかというと、そうではありません。

この二面性は、Lenny のレポートできれいに表れています。今の状況にワクワクしていると答えた人は 64%。ところが、希望が持てると答えた人は 33% まで落ちます。何が作れるかには、ワクワクできる。でも、自分の立ち位置が良くなると思える人は半分に減ります。

Figma のレポートだけでなく、「何を作るべきか」「なぜ作るべきか」を問う必要があるという指摘を耳にします。これらは確かに重要な問いです。しかし、デザイナー自身がその問いを立て、さらに実行まで担えるかというと、必ずしもそうではありません。多くの場合、こうした問いを立てるのは決裁権を持つ立場の人です。そのため、デザイナーが自ら問いを設定し、プロトタイプを作り上げたとしても、それだけでは状況を動かすことは難しく、突破口にはなりにくいです。

今の状況に希望が持てないからこそ、「何をするのか」と考えたとき、多くの人はとにかくたくさん試し、作り続けるという選択を取りがちです。 つまり、できることが増えていくのは楽しい反面、その楽しさがやがて消耗へと変わっていきます。仕事の楽しさの性質が変わり、 月ごとに新しい情報が次々と押し寄せ、「自分だけ取り残されている」と感じて焦り続けた結果、疲れ果ててしまう人もいます。他の職種と比べて感情的な疲れを表すデザイナーとリサーチャーが多いのも印象的です。 楽しさと焦り、そして疲れが同居する中で、今までよりさらに多く働いていると感じている方もいるでしょう。

表裏一体の感情と向き合う

不安や疲労を表に出さないまま、感情を抑えて働き続けている人もいると思います。しかし、ふと周りをみると「スゴい！」「こんなの作れた！」「自分でもできた！」といったエキサイティングな情報ばかりです。この感情のギャップを感じながら、自分の立ち位置が次第に危うくなっていくのではないかという漠然とした不安を感じながら働くのは楽ではありません。

状況全体に対する明確な答えを持っている人はいません。 もっともらしいアドバイスや小手先のコツを並べることはできますが、そうしたものでは、今抱えている居心地の悪さは和らがないように思います。 できることとは、AIに悩んでいるのが自分一人ではないと気づくこと。そして、AI活用にある『二面性』について、より多くの情報を交換していくことです。

「ワクワクしている」「今がとても楽しい」という気持ちは本心です。 しかし同時に、言葉にしにくい漠然とした不安を抱えているのも事実です。 その不安は、好奇心がないとか、積極性がないとか単純な理由では語れない、複雑で繊細な感情です。 2つのレポートが示しているのは食い違いではなく、デザイナーが抱える相反する感情が同時に存在している姿なのかもしれません。

ChatGPT や Claude に頼めば、それらしいスライド資料が数分ででき上がります。構成は整理されていて、見出しは要点を押さえ、図解まで付いてきます。一見「資料作りはもうAIに任せられる」と感じた人は少なくないはずです。AI による成果物をみて「これで良いじゃない？」と評価する場面も少なくありませんが、いざ自分の仕事を頼むと厳しい目になります。「作り込みが甘い」「考慮が足りていない」「作り直した方が早い」と感じることすらあります。

スライドを作る作業は全体からするとほんの一部です。誰に何を伝えるべきなのか。彼らにとって理解しやすい形式は何か。どの順番なら腹落ちするのか。どこまで言って、何を言わずに残すのか。資料作りはこうした無数の小さな判断でできていて、その判断はでき上がったスライドには映し出されません。完成品がすべてだと思っていると、「この程度ならAIでも作れる」と判断してしまいます。

「AIで置き換えられる」という論調は、たいていはアウトプットの見た目であって、仕事そのものではありません。アウトプットだけを見て、仕事の中身まで分かった気になる場合があります。ただ、多くの仕事はアウトプットだけでは分からないニュアンスが隠れています。これはスライド作りだけでなく、様々な仕事にも当てはまります。

こうした、見た目だけで単純解釈してしまう現象を「 説明深度の錯覚（Illusion of Explanatory Depth） 」と呼びます。整った成果物を見れば、その背後にある判断まで分かった気になるという認知バイアスです。表層的な解釈によるAIの仕組み化では、「なんとなく良いけど使えない」みたいなものが出来上がり、ドラフトが出来上がるスピードが上がっても完成までの距離が今までより遠くなることがあります。

Human-in-the-Loopのミスマッチ

AIだけでは高い完成度の成果物を作れないからこそ、人間が最終的にレビューする「Human-in-the-Loop」が欠かせないという論調があります。また、人の判断力や美意識が、成果の質を左右するという主張も耳にします。そのあいだにコンテキストやチェックの仕組みを充実してハーネスを整備していけば、次第に AI の出力品質が上がるという話もあります。しかし、本当にそうなのでしょうか。

料理に例えると「Human-in-the-Loop」が機能するのか疑わしく感じます。
料理が完成したあとに、他の材料を入れるともっと美味しくなると気づいたとします。あとから足せば、料理が思った通りに出来上がるわけではありません。材料は調理の最中に入っているから意味があるのであって、気づいたときには最初から作り直しです。

つまり、材料や手順が言語化されていれば完成するのかというと、そんなことはないわけです。「こんな工夫をすれば、もっと良くなるかもしれない」など、その場で咄嗟に考えたことが良い結果を生み出すことがあります。料理だけでなく、デザインでも暗黙知や人間関係によって、その場の判断が大きく変わります。 今週どこまで踏み込めるかの肌感や、特定の組織役員の関心の向きといった情報が仕事を左右することがありますが、こうした肌感は言葉にしようとした時点でこぼれ落ちます。

どれだけ丁寧に言語化しても、言語化された情報では到達できない粒度があります。ハーネスを整備しても出力が微妙にズレ続けるのは、プロンプトが下手だからではなく、私たちの判断そのものが、言語化されたものに対してレビューするという単純なワークフローではないからだと思います。にもかかわらず、ハーネスの改善に多くの時間を費やし、ようやく良いアウトプットが出たと思っても、「なんとなく違う」という理由で調整を続ける。このサイクルは、果たして仕事の効率化と言えるのでしょうか。

同じことは、エンジニアの仕事でも起きています。プログラミングは、指示通りにコードを書くだけの仕事ではなく、何を作るべきか、どこで妥協するかといった判断の連続です。その複雑さは完成したコードには表れないので、外からは「これならAIに任せられる」と見えてしまう。実際、その見立てで人員削減に踏み切った米国IT企業もありました。ところが、AIによる人員削減に踏み切った企業の半数が、数年内に同じ役割を雇い直すだろうという予測もあります。

一度は単純化して切り離した判断の複雑さに、あとから気づいたからではないでしょうか。

仕事にある判断についてもっと知ろう

もちろん、生成 AI が使えるシーンは幾つかあります。ブレストや壁打ちのように、人の判断を研ぎ澄ませたいときには大変役に立ちます。 また、AIで生成する際に、人がどのタイミングで何を判断する必要があるのか見極めることで、 Human-in-the-Loop のタイミングも変わってくるはずです。 ただ、多くの場合、私たちが最初に想像しているほど単純ではないということに気付くはずです。

私たちは完成品で物事の良し悪しを判断しがちです。しかし、そうした見方では、生成AIを使った業務も質の低い成果を量産し、人の負担をむしろ増やすだけになりかねません。私がデザインをレビューする際も、完成されたデザインに対してではなく、どういう意図でデザインしたのか引き出すようにしています。最初は「ユーザーにとって使いやすくなるよう工夫しました」と模範回答するデザイナーも、次第に複雑な事情を教えてくれます。実は、それが物事の判断の真意であり、言語化が難しい部分でもあります。

私たちの仕事は、ニュアンスや経験、場の雰囲気、人間関係といった要素を踏まえて判断しています。これは他の人の仕事でも同じです。まずは、周囲の人が何を考え、どんな悩みを抱えながら仕事をしているのかを知ることが大切です。それは、AI を使ってアウトプットの速度を上げること以上に重要であり、今後の AI 活用にも大きく響くものだと思います。

「問いを立てよ」といったアドバイスも、ただ問いを考えれば良わけではありません。「自分の意思を持て」も同じで、意思を持つとは具体的にどういうことなのかが分からないです。抽象的なアドバイスはたいてい、具体的な最初の一歩が見えないものが多いです。では、何をすれば良いのでしょうか。

指示に対して出力するだけなら

学校では、先生から課題に受け取り、講評で受けたフィードバックをもとに直して、改善案を提出を繰り返すという反復学習をします。デザインはただノウハウを覚えれば上達するわけではありません。何度も繰り返すことで知識が身体に染み付き、デザインの筋力になります。

反復的学習は必要とはいえ、課題が出され、評価が返ってくる、それに応えて直すというループは、「与えられた指示や評価に対して最善を尽くす」という受け方も身についてしまいます。 実はこの指示に対して最善を尽くすという姿勢を社会に出てからも続けていると、だんだん「手を動かすだけの人」へとなっていきます。 もちろん以前であれば、指示通りにアウトプットができる人は重宝されていましたが、今はそうではなくなってきています。

指示通りに動くだけなら、AIや自動化のワークフローで容易に実行できるようになってきています。また、人に頼まなくても出力できるという手軽さから、わざわざデザイナーに頼むことを躊躇する人すら出てくると思います。 デザイナーが考えるクオリティには達していない。だからレビューが必要であるという論調は間違ってはいません。ただ、そのクオリティというものが一体何なのでしょうか。

学校でのフィードバックが「ちょっと違う」「わかりにくい」「使いにくい」といった感覚的な評価だけにとどまると、社会に出て問題が生じます。デザイナーが考えるクオリティには感覚以外の側面もあるにもかかわらず、それを伝えるボキャブラリが不足しているため周囲に理解されなくなります。

デザインはすべて言葉で説明できるものではありません。しかし、それを理由に何も言葉で伝えなくてよいわけではありません。 「ユーザーにとって分かりにくい」と論理的に説明しているようで、実際には何も伝わっていない典型的な表現です。こうした感覚的な言葉で留めていると、本人が自分の目で確認することなり、周りから少しずつ取り残される可能性があります。

何か作って、世に出す

では、何をしたら良いのかは実はシンプルで、「作る」「公開する」です。

指示を待ってから作るのではなく、自分が欲しいものや観察から得た気づきを自分で形にすることが、これまで以上に重要になっています。問いを立てて課題を明確にし、解決策をじっくり設計することが有益な場面はあります。しかし今は思いついたことを即興で形にし、SNSなどで公開することが大切だと考えています。このとき、AI は脅威から武器へと変わります。

AIによって広がる素材に触れるデザイン

AIを、自分の仕事の成果物を代わりに作ってもらうツールと考えるのではなく、自分の仕事の幅を広げるための道具として捉えてみるとどうでしょうか。

Yasuhisa HasegawaYasuhisa Hasegawa

作り続ける反復の中で、自分がデザインの何を学ぶべきかを見つけられます。 また、感覚的な部分のなかから言葉で説明できる部分も見えてきます。ただし注意点があります。SNSでは「いいね」や閲覧数に気を取られがちで、デザインを鍛える本来の学びが損なわれることがあります。公開する敷居の低さで SNS を選ぶのは良いですが、可能であればクリックやスクロール、PV のような解析ツールを通して人の動きを仮説検証できる場がオススメです。

人見知りでない相手から、自分が作ったものに対する率直な反応を得る機会は少ないです。学校だけでなく職場でも同様で、特に指示に従って作るだけだと、その機会がさらに減ります。つまり、反復して学ぶ場面自体が不足しているわけです。

また、指示されたフィードバックをもとに修正するだけだと、なぜこの改善が必要なのかという疑問も生まれることなく作ってしまうこともあると思います。 そこが自分で作ったものを公開することによって、少し見え方が変わっていきます。

例えば「これを見た人は〇〇すると思う」と仮説して公開してみると、その通りの行動をしてくれないといったシーンに出くわすはずです。 そうすると、なぜこのような行動をしたんだろうかといった疑問も新たに生まれ、改善へのヒントも自発的に見つけることができるようになっていきます。 こうした行動が見えるようにするためにも、解析ツールを使うことができる環境で公開した方が良いですが、使った人に率直に質問をしてみるというだけでも良いと思います。

相手の言葉に注目し、それを裏付けるデータを確認することで、デザインがどのように形成されているかに気づけます。 その過程で、デザインを説明するボキャブラリも少しずつ増えていきます。

随分昔の話ですが、自分のサイトを自作CMSで公開し、解析データを基に細かく改善を何年か続けていました。その過程で、デザインだけでなくマーケティングや認知学、ビジネスへと関心を広げた経験があります。 誰かにビジネスのことを知るのは重要であるといった指示（アドバイス）を受けたのではなく、反復学習しながら作ったものを公開し続けることで自然と広がっていきました。

体系化された知識を学び、それをもとに実践する学び方も一つの形です。しかし、AIのように正解がまだなく模索段階にある領域では、体系化の方法自体が存在しません。そんな時期には、正しいツールや最適なワークフローを学ぼうとするより、まず自分で手を動かしてみることが有効です。作ったものに対する周囲の反応を見ながら、その都度何をすべきかを見つけ出す活動は、遠回りに見えて実は近道です。 また、こうした活動を続けることが、与えらえた指示に基づて作る癖をほぐしてくれます。

学生だからこそ、教科書通りの『賢い成果物』を作るのではなく、ノリでいろいろ試 していってほしいです。

Webサイトやアプリをもっと早くリリースしたいのに、できない。そんなとき、作る側から見ると、早く形にできないことが、いちばん見えやすいボトルネックに感じられます。だからこそ、生成AIによって短い時間でいくつものデザインが手元に並ぶことに、強く惹かれます。今までスケッチや初期案に何時間もかけていたところが、数分で複数のバリエーションを眺められるようになると、生産性が上がると期待してしまいます。Google Stitch をはじめとしたツールを少し触るとそんな期待が高まるのも無理はありません。

ただ、 作るのが遅いからリリースが遅れてしまうといったことは稀です。 実際に多いのは、抜け漏れがないか、本当に適切なアプローチか、そして本当に効果があるかを判断する局面で時間がかかります。 デザインシステムは良い例です。コンポーネントが揃っていれば、確かにプロトタイプは作りやすくなります。ただ、それだけでプロダクト開発の判断の確度が上がり、リリースを早められるかというと、そうとは限りません。

組織の文脈を置き去りにしたデザインシステムの罠

デザインシステムの成功は手段の選択に大きく左右されるわけではなく、実際には計画の不備が失敗の原因となることが多いです。

Yasuhisa HasegawaYasuhisa Hasegawa

つまり、難しいのは、何を作るべきで、 何が妥当なのかをチームで合意することと、その合意が現実の制約と噛み合うかを見極めることです。AIは何かを出力するコストを圧倒的に安くしましたが、だからとって良い判断に繋がるとは限りません。

曖昧さに留まると見えてくること

クライアントの依頼の中には、「○○を作ってください」といった、手段が先に提示されている場合があります。 提示された手段の要件定義やスコープを絞る方もいるかもしれませんが、 ほんとんどの場合、手段から少しずつ離れた話をします。その手段を選んだ理由や背景、そして期待していることについて詳しくヒアリングします。また、現在の体制や関係者、プロセスなどの状況を確認し、関連資料も合わせて調べることが多いです。

どんな案件でも以下の問いを頭の中に置いてヒアリングしています。

• 見えていないものは何か？
• この問題を形作っている条件どう決まっているのか？
• 意思決定は誰が、どんな材料で進めているのか？
• 決まった後に、何が振り返られ、何は振り返られないままになっているのか？
• 議論の場にいない人、声が小さい人は誰か？

「手段を目的化するな」という言葉があります。私もその考えに賛成ですが、手段を選んでしまう人たちの気持ちも分からないわけではありません。 手段はやることが明確です。成果物のかたちもハッキリ分かります。そこには何かしらの安心感があるのではないでしょうか。

一方、上記のような問いを立てたり、手段から一歩引いて周囲で起きている課題をヒアリングしたりすることは重要な活動ですが、その先がどうなるかは見えにくいです。明確な答えや輪郭がない、曖昧で抽象的な時間になります。 手段のようなはっきりとした答えが出せない時間と空間。こうした時間の過ごし方に、不安を感じる人もいるでしょうし、「なぜこんなことをしているのだろう」と思う人もいると思います。

こうした時間に長く居座らないと見えてこない答えがあると思います。逆に、こうした曖昧な時間を費やさずに手段に飛びついてしまうと、見られない、使われない成果物が生まれてしまうのではないでしょうか。

意図ある物作りを

AIは過去の似たパターンを引き出して組み合わせ直すのが驚くほど上手いのですが、その組織の今週どこまで踏み込めるかの肌感や、特定の役員の関心の向きや、来月のリリースのプレッシャーを織り込んだ上での「いま解くべき問題」を明文化することはできません。 そのような情報はコンテキストファイルとして保存されないわけです。ハーネスして「それっぽい出力」は出力できても、判断が早くできるかは別の話です。

AIによって成果物を作る手間が軽くなったのは良いですが、それで物事が早く進むのかといえばそんなことはありません。「何を解くか」に時間を費やさなければ、レビューの量や判断の迷いを増やしているだけです。AIにモックを30案出してもらってから議論を始めるより、議論の前に半日、関係者の観察と問いかけに使う方が、結果的に良い答えに近づきやすいです。

デザイナーとして視点を変えるべきなのは、「自分の作業をいかに早くするか」という考えから、「自分が作ったデザインを通して、物事が進むように促せるか」という視点への転換だと思います。 それは単に早くものを作るということではありません。 早くプロトタイプを作って共有するのではなく、自分の作ったものを通して何を変えようとしているのかを考えて作ることです。チームメンバーの迷いを消すためなのか。違う視点を周囲に共有して刺激を与えるためなのか。それとも具体的に困っていることを解決するためなのか。こうした状況把握したうえでの物作りができるデザイナーであれば、AI だけでなく他に何か新しい技術によって自動化されても必要とされるはずです。

2022年にナレッジマネジメントについての記事を書きました。そこで情報と知識の違いを「Discovery」「Capture」「Consume」「Process」「Output」という5つのステージに分けて整理しました。このフレームワークは今でも通じますが、私たちが挫折するのは「Process」の部分です。読んだものを自分の言葉で咀嚼し、他のアイデアとの接点を見つけ、整理する。この工程が重たすぎて、せっかく集めた情報が「積ん読」のまま放置されてしまいます。PKMツールはたくさんありますが「せっかく集めた情報をどう活用するの？」「どうやって整理するの？」といった質問が後を絶たないのは、「Process」ステージがいかに難しいかを物語っています。

ツール選びの問いが「自分」から「AI」へ

2026年に入って、この状況が変わりました。AI (Claude Code) が MCP（Model Context Protocol）を通じて自分のナレッジベースに直接アクセスし、操作できるようになったことです。

Tana Local API & MCP Documentation | Connect Tana to AI Tools

Documentation for Tana’s Local API and Model Context Protocol (MCP). Learn how to let AI tools read, query, and write structured data from your Tana workspace using a local, extensible integration.

Tana

タグ付け、フィールドの入力、関連ノートへのリンクといった、今まで面倒だった管理作業をAIが処理できるようになりました。自分がやるのは、AIとの対話の中で考えを言葉にすることだけです。対話の過程でAIが過去のノートを引き出し、「過去に書いたこのアイデアを結びつけると、〇〇が考えられます」といった提案をしてくれるようになりました。これにより、今まで見逃していた関係から新しいアイデアが考えやすくなりました。

自分の考えをまとめた「Atomic Note」の生成数も10倍に跳ね上がりました。私の Atomic Note は参照情報や問い同士を結びつけて構造化してありますが、管理の手間が大きくて足かせになっていました。今は AI が代わりに管理をしてくれるので、関係するノートを探したり、どんなタグを付けるか悩む時間が減り、そのぶん考えることに集中できるようになりました。

この変化を経験してみて気づいたのは、ツール選びの基準そのものが変わったということです。以前は「整理しやすい機能が揃っているか」が悩みの中心でした。UIの使い勝手、検索の速さ、タグやデータベースの柔軟さが選ぶポイントでしたが、今は「AIが自分の代わりに整理できるか」に変わっています。自分が直接触る体験だけでなく、AIがどれだけ細かい粒度で操作できるかが、ツールの価値を左右するようになりました。

3年使い続けている Tana はノードベースのアプリです。ノード（node）は、フォルダやページという枠組みに縛られることなく自由に整理できるのが特徴です。例えば、複数の書籍からの引用を重複なくまとめて、ひとつに整理できます。Tana はページではなく node ひとつひとつにタグやフィールドで意味付けするので、node が何を意味するのか AI も人間も理解できます。たとえば Obsidian のようなファイルベースの PKM でも、AIは管理作業を代行できます。ただ、操作の単位がファイルになるため、1つのファイルに複数のアイデアが混在している場合、AIが個々のアイデアを独立して関連付けできる解像度は下がります。

ツールによって好みが分かれますが、1, 2 年前にあった「分類」「整理」「つなげる」といった認知負荷が高い作業から解放されたことは は間違いありません。今はその部分をAIに委ね、考えることに集中できるようになりました。「管理する」という作業は消えて、AI との対話や作業の中で自然に生まれるものへと変わり始めています。

ようやく思考ツールになってきた

今も Tana は使っていますが、私の知識を支える『バックエンド』のような存在になっています。
調査、壁打ち、業務の振り返りなど、特化したエージェントとの会話を通して生まれたアイデアを保存する場所であり、アプリを開くときは内容の確認くらいです。

会話は新しいアイデアのきっかけになりますが、すべてを会話だけで解決することはできません。ツールが提供するのはキーワード検索だけなので、簡易セマンティック検索ツールを別途用意して作ってあります。 ページのような大きな枠の検索結果ではなく、ニュアンスを加味した個々のアイデアを引き出せるのが特徴です。また、常時確認が必要なテーマがあれば Tana に点在する情報をダッシュボードでまとめています。ツールが提供する機能に頼ることなく、自分だけのナレッジエコシステムが作れるようになったのも大きな変化のひとつです。

PKM は 「十分欲しい機能が揃っているか」「使いやすいか」といった問いから、「思考を支援する AI の力を増幅するのに十分かどうか」 といった問いに変わってきています。 この問いと向き合ったとき、実は1つのツールにコミットすることが答えではないということに気づくことになります。例えば、私自身は Tana を使っていますが、重要な情報はローカルで管理し、必要に応じて組み合わせられるようにスキルを設計しています。 一見ややこしいことをしているようですが、 その面倒な管理を省いてくれたという意味で、AIは貴重な存在です。

管理から解放されたことで PKMを始めてみたい方も、再度挑戦してみたい方も、どのツールがいいかを考える前に、自分がAIと対話をしているときに、どんな情報がどんなときに必要なのかを考えてみてはいかがでしょうか。そこから、自分にとって思考しやすいナレッジエコシステムを作るキッカケになるはずです。

ただ、同時に妙な忙しさも感じています。AIにタスクを渡して、出力を確認して、次のタスクを振る。その繰り返しの中で、「作っている」というより「捌いている」に近い時間が増えている。生産性は上がっています。しかし、それが楽しいかと聞かれると、正直よく分かりません。

以前、AI疲れについて書きましたが、そのときは「不安を煽るコンテンツに振り回されないこと」「70%ルールで自分の手を動かす余地を残すこと」を提案しました。不安を感じている方への提案でしたが、今は疲れや不安とは少し違うものを感じ始めています。「これってデザイナーにとって本当に楽しいのか？」という感覚です。

AI疲れや不安を感じている方へ

大事なのは、AIという道具を使って効率化することではなく、今の自分にとってちょうど良い付き合い方はどのようなものかを探ることです。

Yasuhisa HasegawaYasuhisa Hasegawa

エンジニアが感じ始めた「楽しくない」

ある開発者は、過去四半期の振り返りで「過去最高にコードを生成したが、同時に過去最高に疲弊した時期だった」と評価しています。流れの早い AI に「ついていけない」のではなく「もうやりたくない」と表現しているのが興味深い点です。つまり、情報収集やAI活用のスキルは高い一方で、エンジニアとしての楽しさを失いつつあるように見えます。

AIを使う開発者はプルリクエストのマージ数を劇的に伸ばしている一方で、時間外のコミットも増えています。 「トークンを使い続けないともったいない」という強迫観念を抱く方も増えてきています。生産性は上がっているかもしれません。しかし、上がった先にあるものが「もっと多くのレビュー」と「もっと密な管理」だとしたら、それはエンジニアがこの仕事を選んだ理由とは別のものだと思います。デザイナーと同様、多くのエンジニアも「自分の手で良いものを作りたい」のはずです。

Annie Vella の記事「The Software Engineering Identity Crisis」ではこの変化を、自分が渋々マネジメントに転向した経験と重ねています。好きだったことをやめて、 AIの出力を管理するという別の仕事に就いたような感覚を綴っています。これはデザイナーにとっても他人事ではないと思います。「自分で手を動かす」から「AIの出力を判断する」への変化を感じ始めている人も少なくありません。

AIを使ってアイデアを形にできるようになったこと自体は、多くのデザイナーにとって貴重な体験です。自分の頭の中にあるものが動く形になる瞬間には、純粋な発見の喜びがあります。私自身もそうした経験がありますし、最近はデザイナーが自らアプリをリリースするケースも増えています。

ただ、新しい道具を手にしたときの新鮮さと、その道具で毎日仕事をする感覚は違います。エンジニアが辿っている「できることが増える → もっと速く作る → もっと多く作る → 忙しいのに作っている感じがしない」という感覚は、デザイナーも遅かれ早かれ味わうものだと思います。

使いこなした上で離れる人たち

デザイナーの間では「テイストと判断力はAIには真似できない」という主張があります。AIが実行を担い、人間が判断を担う。デザイナーの関与が不可欠だと説く一方で、もしデザイナーの役割が「判断することだけ」になったらどうなるでしょうか。 デザイナーにとって判断が重要であっても、仕事を楽しいと感じるのは「作ること」です。

難しい問題に長時間向き合い、あれこれ試行錯誤し続けること。自分のアイデアを形にしていくうちに、少しずつ答えの輪郭が見えてくるその瞬間。時間をかけてようやく答えらしいものが形作られる過程はツライことも多いですが、同時に楽しいと感じられるからこそ、デザイナーを続ける人は多いのだと思います。そして、その過程こそが、テイストや判断力を養う唯一の方法です。

私が最近気になるのは、デザイナーやエンジニアが AI を使いこなせないから離れることではありません。使いこなした上で、この仕事が面白くなくなったから離れることが増えるのでは？という点です。能力の問題でも、品質へのこだわりの問題でもない。プロセスを踏まずにアウトプットだけが生まれ、見た目はそれなりに良くても充実感が得られない状態を、単に時代や定義の変化で片付けるわけにはいかないと思います。

仕事に惹かれた理由そのもの「自分の手で形にすること、苦闘を通じて学ぶこと、完成したときの手応え」が、効率化の名の下に最適化されて消えていく。残るのは管理、選別、確認となったとき、そこに自分なりの『デザイン』を見出せるのであれば続けられると思います。楽しさは千差万別なので、この変化に楽しさを見出せる人はたくさんいますが、それは今までのものとは別のものかもしれません。

AIの時代だからこそ、職人技や作り込みがデザイナーの差別化につながるというメッセージは、勇気づけられます。ただ、データをよく見ると、少し違う風景が見えてきます。

分かるようで分からない「クラフト」

調査では「クラフトとは何か」という質問がありますが、デザイナーは「視覚的な洗練（Visual Polish）: 58%」「熟考に基づく問題解決 (Thoughtful Problem Solving) : 47%」「明快で直感的なUX（Clear intuitive UX）: 36%」「感情と喜び（Emotion and Delight）: 35%」「プロダクト間の一貫性 （Consistency across products）: 15%」と回答しています。

それぞれが指している「品質」の性質はかなり違います。成果物の表面に現れる品質（視覚的な洗練）、 プロセスの質（熟考に基づく問題解決）、 ユーザーの認知体験の質（明確で直感的なUX）、感情的反応を生むことを目指す目標（感情と喜び）、 システムとしての品質（プロダクト間の一貫性）と、様々な観点が入り混じっているのが分かります。最大3つまで選べるアンケートのため仕方ない面はありますが、デザイナー間で「クラフト」への捉え方の違いが見え隠れします。

デザイナー間でも捉え方が違うわけですから、エンジニアや PdM にとっては「分かるようで分からない言葉」に聞こえているかもしれません。

エンジニアは「技術的負債の軽減」や「スケーラビリティ」という言葉を使って、自分たちが何に時間をかけて品質を上げていきたいのか伝えています。評価可能であることから「このアーキテクチャは1万件の同時接続に耐えられない」と言われたら、PMは「どのくらい遅くなるのか」と聞き返せるので、対話が成り立ちやすいです。

一方、デザイナーが「もっと洗練させるべき」と言っても、周りは「ただもっと時間を使いたいという意味？」と頭の中で考えているかもしれません。「直感的な操作にすべき」と言われても、「アニメーションを加えることで本当にそれが直感的になるの？」と思うかもしれません。

「見た目を洗練させる」ではなく「ユーザーが情報の階層を迷わず読み取れる視覚設計」といった言語化をすれば良いと考えるかもれませんが、それほど単純な話ではありません。デザインには、感覚、直感、経験に裏打ちされた判断など、言語化しきれない要素があります。こうした要素の存在を軽視し、すべてを測定指標に変換してしまうことで、デザインの価値そのものが損なわれる場合があります。

ただ、「言語化できない部分がある」であって、「デザインは言語化できない」というわけではありません。私たちが「クラフト」と呼んでいるものの中で、何がどこまで説明可能で、どこからが感覚的な領域なのか。なんとなくでも良いので、境界を自分の中で見極めることは、一人ひとりのデザイナーができることではないでしょうか。

楽観と悲観が同居する

Figma の調査にあった「より明確な推進力を報告しています。リーダーシップによる支援、成長の機会、評価を通じてクラフトに投資することは、デザイナーと組織の双方にとって、より良い成果と相関しています」という指摘と、クラフトへの注力と職業への楽観度の相関を示すチャートも一歩踏み込むと興味深い矛盾が浮かび上がります。

「クラフトへの注力が増えた」と答えたグループでも、ビジネスの成長が「遅い」と感じている人が 47% います。「変わらない」グループの方が、職業への楽観度が高い場合もあります。むしろ、成長している企業にはクラフトに投資する余裕があるだけかもしれません。因果の方向が逆の可能性もあります。

この調査から、デザイナーはクラフトが大事だと信じているのが分かりますし、AIの時代でもクラフトが自分たちの差別化になると考えています。しかし同時に、クラフトがビジネスに貢献しているという確信は持てていないようです。

この矛盾を「ビジネスがクラフトを理解しない」と捉えるのは簡単です。しかし、この矛盾はデザイナー自身の中にあるように思えます。「クラフトとは何か」をデザイナー自身がはっきり説明できず、周囲も分かっているようで実は分かりにくいですから、確信が持てないのは無理もありません。

詳細な調査結果がみれる PDF では、「Craft is king — and subjective」と見出しをつけています。デザインには主観性が含まれています。しかし、この見出しは「主観的で構わない、クラフトが最重要だ」というメッセージと捉えることができます。

調査によってデザイナーに「あなたの定義は正しい」と伝えることは居心地の良いことかもしれません。しかし、その安心は問題の先送りです。クラフトの定義が一部の人にしか共有されず、組織内で通じないままなら、その定義を見直すべきではないでしょうか。

Figma の立場を考えれば、デザイナーが自分たちの仕事に誇りを持てるようなフレーミングを選ぶのは自然なことです。デザインツールの会社がデザインの価値を肯定するのは当たり前です。だからこそ、読み手の側で「このデータは本当は何を映しているのか」を考える必要があります。

自分の「クラフト」を問い直す

私たちデザイナーは、クラフトについて2つの考えを同時に持っています。「クラフトは自分たちの固有の価値である」ということと、「周囲はその価値を理解してくれない」ということ。この2つが長く同居し続けているなら、問題はクラフトそのものの価値ではなく、私たちが「クラフト」と呼んでいるものの解像度にあるのかもしれません。

「視覚的な洗練」とは具体的に何を指すのか。
それは、認知負荷を下げるためのタイポグラフィの階層設計なのか。
情報構造を明確にするための色使いなのか。
それとも単に「見た目が美しいこと」なのか。

「楽しさ」とはどのような概念か。
完了時のフィードバックを指すのか。
エラー時の体験を指すのか。
操作の効率性を意味するのか。

これらを全部「クラフト」という一語にまとめてしまうと、身近な人たちの中では通じても、エンジニアや PdM には何も伝わりません。Figma の調査は、その一語のままでいいと暗に肯定してしまっているようにも見えます。デザインには直感や感覚でしか説明できない部分が多いものの、それに甘えて言葉で伝えられる範囲まで曖昧にしてしまっていることがあるかもしれません。

Figma の調査は、デザイナーの現状を切り取った貴重な情報です。しかし、そのデータが伝えているのは「デザイナーは間違っていない」という結論ではなく、私たち自身の内にある未解決の矛盾だと思います。まずは自分にとって「クラフト」が具体的に何を意味するのかを問い直すことが、矛盾をほどく出発点になるはずです。

新しいAIモデルの登場や新機能の発表を見て、不安や焦りを感じたことはありませんか？

SNSに流れてくる「週末でアプリを作った」という投稿を見て、自分は遅れているのではないかと不安になったことがあると思います。AIを日常的に使っている人でさえ、この感覚から逃れられません。すでに活用している立場であるにもかかわらず、十分ではないと感じてしまう。この漠然とした焦りの正体は、一体何なのでしょうか。

AIによって効率化が進み、様々なことが変わり始めているように見えますが、現実はもう少し複雑です。 Goldman Sachs の調査によると、AI導入と生産性の間に、経済全体レベルでは有意な関係が見られなかったそうです。コーディングやカスタマーサービスのように効果がみられた領域はあるものの、それでも30%くらいの向上です。

Goldman finds ‘no meaningful relationship between AI and productivity at the economy-wide level,’ but a 30% boost for 2 specific use cases | Fortune

Have you got “AI-nxiety?” Goldman took a closer look at the last earnings season and found a mismatch between hype and reality.

FortuneNick Lichtenberg

6,000人のCEOを対象としたNBERの調査でも同じ傾向が見えます。大多数がAIの雇用・生産性への影響はほぼないと回答しました。MIT Media Labの報告では、95%の組織で測定可能なリターンが出ていないとされています。

2025年から2026年にかけて「AIによって従業員削減」と発表する海外のテック企業が増えています。 しかし、実際はコロナ禍での オーバーハイヤー や買収に伴う組織再編が背景にあるケースも少なくありません。最近だと、Block のニュースが好例です。記事見出しに「AI」と書かれると、原因がAIであるかのように受け取られ、不安が広がってしまうことがある。

AIに意味や効果がまったくないわけではありません。実際に起きている変化は、静かでゆっくりとしたものです。それにもかかわらず、私たちはなぜ焦った気持ちになるのでしょうか。

不安を作り上げているのは、AIではなくコンテンツ

SNSに流れるAI関連の投稿には、共通の偏りがあります。例えば「これで生産性が10倍になりました」みたいなテクニックやツールは、デモであって実務での光景ではないという点です。「AIでデザインが完成」という投稿の裏には、プロンプトの試行錯誤や人間の手直しがありますが、その過程は共有されません。「AIシアター」 といった表現が示すように、本当に使えているかがではなく、 あたかも本当の業務で支えているかのように見せる演出が多く見られます。

ただし、そうした大げさな表現はSNSのアルゴリズムに好まれるため、タイムラインはAIによる演出で埋め尽くされがちです。見た目は情報提供でも、多くは発信者の立ち位置を示すための発信です。「AIでこれができた」のようなコンテンツは情報共有ではなく、「私はあなたより先にいる」という暗黙の宣言です。受け手がそこから受け取るのは知識ではなく、「遅れている」という感覚が残ります。

最近、SNSでデザイナー同士が「Figmaは必要か不要か」と議論しています。 その議論には「遅れている」という単純な不安だけでなく、もっと複雑な不安感が絡んでいます。

AIの話題で時折「職を失う恐怖」が挙げられますが、実際はアイデンティティを失う恐怖に近いと思います。研究者たちはその状態を「アルゴリズミック・アンクザイエティ (Algorithmic Anxiety)」と呼んでいます。長年かけて磨いたスキルが一夜にして価値を失うという感覚が、自分の失敗ではなく、アルゴリズムの進歩によって起こっているという現象です。 FIgma に関する議論で漠然とした不安を感じるのも、ツールが私たちデザイナーのアイデンティティの一部だからとも考えられます。

The Age of Algorithmic Anxiety

Interacting online today means being besieged by system-generated recommendations. Do we want what the machines tell us we want?

The New YorkerKyle Chayka

従来のFOMO（Fear of Missing Out / 見逃す恐怖）との決定的な違いがあります。World Economic Forum のレポートでは FOBO（Fear of Becoming Obsolete）という言葉が紹介されています、FOBO は、見逃しではなく陳腐化の恐怖です。FOMOが「情報や機会を取りこぼすかもしれない」という焦りであるのに対し、FOBOは「自分という存在が不要になるかもしれない」という不安です。

デザイナーとして、エンジニアとして積み上げてきた「自分は何者か」という感覚に、AIが疑問符をつけ始めています。「このまま同じツールを使っていて良いのか？」「なぜ自分の作り方が本当にダメなのか？」「周りはどんどん生産的にモノを作れているのか？」そんな問いがさらに不安を助長します。周りはどんどん効率的にAI活用しているように見えるのに、なぜか自分は遅くなっているように感じてしまうこともあります。

先述したように、AIはまだ経済全体の生産性を大きく変えていません。しかし、SNSやメディアを見ると、あたかも今すぐ大きな変化が起こるかのように受け取られがちです。成功のハイライトだけが切り取られ、プロセスや失敗を省略し、変革がすでに起きたかのような印象を作り出しています。

この漠然した印象が、私たちのアイデンティティへの不安へ侵食していきます。つまり、焦りのや不安の原因は、AI技術の進歩そのものではなく、「AI技術の進歩についてのコンテンツ」と「自分が何者であるかという不安」の掛け算とも言えます。

自分のペースと関係性を見つけよう

理由が分かっても、不安がすぐに消えるわけではありません。「SNSを見ない」「AIの利用をやめる」といった極端な対処法も効果がないことが多いです。 情報に偏りがあると理解しても、「自分が陳腐化するかもしれない」という不安は自然に消えることはありません。

正直なところ私も明快な答えは持っていませんが、最近は「70%ルール」をつかって気持ちを調整しています。

素晴らしいAI活用事例はすぐに使える優れたワークフローに見えますが、それらを目標にして90〜100%を目指すと、いつまでも到達できないばかりか「なぜ自分はできないのか」と不安が強くなります。AIが生成するものは 70% くらいの完成度を目指し、そこから自分で考え、手を動かして調整するようにしています。実際、この記事のドラフトは AI に書いてもらいましたが、構成や文体は書き換えていますし、伝えたいメッセージは自分で考えて書いています。

他にもいろいろ AI を使ったワークフローを作ってありますが、「どうせ70%だから」という理由で自分の目で確認する癖がついています。 AIだけで完結しないという前提を置くことで、「これで十分か」「これは省いてよいか」「ここからどう展開すべきか」といった判断をする機会が生まれます。 こうした判断は単にプロンプトやルールで作れるものではなく、私たちの感覚や経験によって培われるものです。

大事なのは、AIという道具を使って効率化することではなく、今の自分にとってちょうど良い付き合い方はどのようなものかを探ることです。 最近の『AI疲れ』は、物事の速さだけが問題なのではなく、周囲が大きく変わっているように感じられることが主な原因です。 70%ルールは、そんな周囲との距離の置き方にも適用できます。 周囲との距離を適度に保ち、自分とAIとのちょうど良い関係を探ることに集中することで、不安感はある程度和らぎます。

しかも、この問題は見た目だけに留まりません。ずれたASCIIアートをもとにデザイン生成ツールへ渡すと、出てくるデザインもずれます。入力が曖昧なら、出力も曖昧になる。ASCIIアートは人間にとって多少見やすいですが、レイアウトを正確に伝える手段ではありません。

この不満をきっかけに、ワイヤーフレームをJSONで定義して、ブラウザでプレビューできる Claude Skill を作ってみました。

ワイヤーフレーム向けJSONファイル

JSONは構造化されたテキストフォーマットで、AI との相性が良いだけでなく、ツールやワークフローに縛られることなく自由に扱うことができます。JSON にはレイアウトの方向（縦か横か）、サイズ（固定か可変か）、間隔、階層が定義されています。例えば、サイドバー付きのダッシュボードなら、ヘッダーとメインコンテンツを縦に配置し、 メインコンテンツの中にサイドバーとメインを横に配置する。こうした構造が direction、width、grow といったプロパティで明示されるので、人でも機械でも解釈がズレません。

Skill には JSON 化したワイヤーフレームデータだけでなく、HTMLプレビューもあります。ドラッグ&ドロップで要素の並べ替えができ、変更はサイドパネルのJSONにリアルタイムで反映されます。JSONをコピーしてエディタで直接編集することもできますし、ファイルとして保存して別のツールに渡すこともできます。

つまり、ザックリとワイヤーフレームを作ったあとに、順番の微調整ができるようにしています。

だいぶ優秀になってきたAIデザインツールですが、細かくプロンプトで指示するのは非常に手間ですし、ちょっとした情報構成の指示を始めると延々と会話と続けることになってしまいます。JSON のメリットはプロンプトとしてそのまま使えるという点です。例えば、Figma Make のようなデザイン生成ツールに、ワイヤーフレームのJSONをそのままコピー＆ペーストで渡すと、情報構成を守ったデザインを生成してくれます。自然言語で「左にサイドバー、右にメインコンテンツ、上にヘッダー」と伝えるよりも、JSONで構造を渡したほうが正確です。構造が明示されているので、ツール側が解釈を間違えにくいのだと思います。

シンプルに「カフェサイトのワイヤーフレームを作って」と頼むのも良し。ブレストしたあとに「ワイヤーフレーム生成して」と頼むのも良し。AIにレイアウト設計の判断を Decision DNA として伝えてあるので、ニュアンスも汲み取ってワイヤーフレーム案を出力してくれます。もし少し間違っていたとしても、出力した HTML をドラッグ＆ドロップで微調整するだけです。

AIにルールではなく視点を渡す Decision DNA

デザインにあるルールやパターンマッチでもない、視点をもたせた AI ワークフローがあります。

Yasuhisa HasegawaYasuhisa Hasegawa

困ったら作って解決できる時代

テキストフォーマットであることは、特定のAIモデルに依存しないことも意味します。Claudeで作ったワイヤーフレームを、別のモデルやツールにそのまま持っていけます。私は Claude Code でこのスキルを活用していますが、Claude Desktop 版でも使えますし、SKILL.md フォーマットは他のツールでもサポートが進んでいます。 ちょっとした機能をパッケージ化して配布できる点も、Skill の魅力です。

この Skill は週末にふと思いついて数日で作ったものですが、小さな不満から始めたことが、思った以上の広がりにつながります。AIを使っていて、出力の形式やワークフローに違和感があるなら、試しに手を動かしてみてもいいかもしれません。最初から全体像が見えている必要はないと思います。目の前の不満をひとつ解消するだけで、想定していなかった使い道が後から見つかることがあります。

ワイヤーフレームスキルは GitHub で公開しているので、興味ある方はぜひ試してみてください。

GitHub - yhassy/wireframe-skill: A Claude Code skill that generates wireframes from natural language descriptions

A Claude Code skill that generates wireframes from natural language descriptions - yhassy/wireframe-skill

GitHubyhassy

デザインの判断は「ここを抑えていたらいかなる場合でも正解」とは言い切れず、文脈で変わります。同じECサイトでもターゲットが違えば必要な情報量が変わりますし、ある施策では正解だったデザインが、別の状況では通用しないことも珍しくありません。

文脈で正解が変わるという現実

デザインだけでなくヒューリスティック評価にも同様のことが言えます。専門家が同じ画面を見ても、見つける問題が一致する割合はわずか 27% と言われています。調査によって数値は前後しますが、誰もが同じように評価できるわけではないことが分かります。知識や経験が違うだけでなく、対象のデザインの目的やユーザーの文脈をどれだけ理解しているかどうかで、評価そのものが変わります。

How Large Is the Evaluator Effect in Usability Testing? – MeasuringU

MeasuringU LogoJeff Sauro, PhD

今のAIプロンプトの多くは「どこが正解でどこが間違いか」を明確に定義し、間違わない方向へ誘導する作り方です。しかし、デザインのように視点によって正解がグラデーションのように変わる領域では、そのアプローチだけでは足りません。評価者がどんな視点でものごとを捉え、それがどう結果に結びついているのかを理解しなければ、チェックリストをなぞるだけの表面的な出力になってしまいます。

ルールからパターンへ、パターンから視点へ

デザインを始めた頃のことを思い出すと、最初は四大原則 、余白、コントラスト比といったルールに沿って作っていたはずです。ルール通りにアプローチするのは、生物の知性の進化に捉えると、初期段階に近いです。光が来たら近づく、危険だったら逃げる。シンプルで確実ですが、想定外の状況には対応できません。

デザイナーとして経験を積み重ねると、パターンを覚え始めます。このレイアウトはこういう場面に向いている、このUIパターンはこのユーザー層に効く。うまくいった行動を繰り返し、失敗を避けながら少しずつ賢くなっていく。生物の進化でいえば強化学習の段階です。

ただ、デザイナーには一段先の成長があります。文脈を理解し、判断を微調整する力。作る前から「このユーザーがこの画面を見たら、おそらくこう感じるだろう」と頭の中でシミュレーションできる能力です。これはルールでもなく、パターンマッチでもない。視点を持っているということを意味します。

この視点を、AIにもインストールできるのではないか。そう考えて作ったのが Decision DNA です。 Decision DNAは4つの要素で構成されています。

• 文脈 : 誰のための判断なのかを定義する要素です。評価する前に「誰にとっての正解を探すのか」を明確にしなければ、出力はどうしても一般論になります。
• 認知 :デザインの問題をどう分解するかをインストールする要素。同じ画面でも何を塊として捉え、何を分けて捉えるかで問題の見え方が変わります。
• 較正 :見つけた問題の重さを文脈で調整する要素。同じ問題でも、誰にとっての問題かで深刻度が変わる。この重み付けを状況に応じて調整できる力をもたせます。
• 明文化 :AIがどういう判断で、どのようにしてその出力に至ったのかを記録するようにします。この記録を基に Decision DNAを改善を繰り返していきます。

ヒューリスティック評価で試してみた

この Decision DNA を組み込んだヒューリスティック評価のワークフローを実際に運用し始めています。全体を指示するディレクターが、評価対象のサイトに対して注意すべき点を整理し、それぞれ異なる視点を持たせた5人の評価者にタスクをアサインします。同じことを繰り返すのではなく、異なる視点を持った評価者がそれぞれ独立して評価し、その結果をもとにディレクターがレポートを整理します。

レポートも評価者が指摘した要素の多数決ではなく、与えられた課題や文脈に応じて評価を微調整した上で最終レポートを出す仕組みにしています。こうした考慮もただチェックリストだけでは難しいアプローチです。

評価が終わった後には、個々の評価者がどのような視点で、どういう順番でものごとを捉えて出力したのかをチェックしています。その傾向から見えてきた改善点を次のワークフローに還元する。明文化の仕組みがあらかじめ作られているからこそ、ワークフロー自体を少しずつ改善しています。

Decision DNAなしで「ヒューリスティック評価をしてください」と頼んだ出力は、「認知負荷がかかる」といった無難な文章を出力してしまいます。誰にとって、どんな状況で認知負荷がかかるのかがわからない。一方、Decision DNAを組み込んだ評価では「複数のタブで比較購買を行うユーザーは、計算を各商品ページで繰り返す必要がある」というように、文脈を考慮した具体的な指摘が出てきます。

また、評価の重み付けにも差が出てきます。シンプルなプロンプトでは「今すぐ買う」ボタンの誤操作リスクを一律に「中」と評価しますが、Decision DNAでは「有料会員は配送パターンに慣れているため影響は軽減される」という文脈を考慮した上で重要度を判断します。誰にとっての問題かが明示されるため、対応の優先順位がつけやすくなっています。

発見数も6件と18件で3倍の差があります（Decision DNA 版はアクセシビリティレポート付）。ただ多ければ良いわけではなく、各問題に信頼度、一致度、判断根拠のログが残っていることが重要な点です。これにより「なぜこの評価になったのか」が追跡可能になり、次の評価で視点そのものを改善できるようになっています。

最初の一行を書いてみる

次にデザインを作ったとき、なぜそれを選んだのか——一文でもいいので書き出してみてください。2つか3つ案を出してその中から選んだ理由は、おそらくルールや原則だけでは説明できないはずです。状況の制約かもしれませんし、ユーザーの文脈かもしれません。重み付けの違いかもしれません。

その一行が、自分だけの Decision DNA を作っていく最初の一歩になるはずです。

ここ数年で、Design Tokens を用いてデザインと開発の同期を図る組織が増えています。生成AIと組み合わせることで、意味付けされたセマンティックトークンによる効率化が期待されるケースも少なくありません。Token の仕組み作りはボトムアップでできるのでハードルが高くありませんが、プロダクト開発と連携したガバナンスは一筋縄にはいきません。

プロダクト開発の要望や優先順位を踏まえて、デザインシステムとどう同期させるかは Design Tokens に特有の課題ではありません。 デザインファイルの UI ライブラリのような単純なものから、Storybook を使った開発連携まで対象が変わっても、「誰が決めて、どう反映するか」という問題は変わりません。

Design Tokens によるメリットはあるものの、それだけで従来からあったガバナンスの課題は解消されません。

プロダクトチームはプロダクトの KPI や OKRで評価されます。クロスプロダクトの一貫性で評価されることはありませんし、効果が期待できるなら、ガイドラインにないパターンが使いたくなる場合もあります。デザインシステムの採用にも追加や調整の手間がかかるため、機能のリリースを優先して対応することはありません。

何かを始めるなら、まずはボトムアップで着手する方が早く進みます。 自分たちの担当範囲であるUIライブラリや実装フレームワークに手を入れると、作業を速く進められます。 デザインシステムの初期段階であれば、採用コンポーネント数のような指標が有効です。しかし、それをデザインチーム唯一のKPIとして続けていると、プロダクト側とのインセンティブや優先順位にズレが生じます。その結果、コンポーネントの採用が進まなくなったり、運用が複雑化したりします。

運用モデルが有効と言われているのは「Federated Model」と呼ばれる、 プロダクトを担当するデザイナーと開発者が、デザインシステムチームに派遣されて連携しながら運用していくというものです。プロダクトチームの状況が見えやすくなることで、どのコンポーネントを追加・改善すればよいかの判断もしやすくなります。

ただ、Federated Modelは回避策に過ぎず、根本的な解決にはなりません。デザインシステムチームがプロダクトチームの文脈を理解する機会にはなりますが、その先の対応が不明確です。もしデザインシステムチームが引き続き「一貫したUIを維持する仕組み」を最重要視するなら、プロダクトチームが求める「ユーザーの成果をどう支援するか」とは乖離します。

AI を使った Design Tokens 活用でも、「何を使うか」は指示だけでは十分ではありません。「なぜこの選択がこの文脈に合うか」まで調整が必要ですし、その明文化のためにはガバナンスが不可欠になります。AI には大きな可能性を秘めているとはいえ、解決すべき課題は今までと大きく変わりません。

デザインシステムのガバナンスの目的が、「トークンの使い方をドキュメント化（もしくはAIが理解できるように）して一貫性を保ちやすくすれば、チームはより速くリリースできる」 という仮定に基づていることがあります。開発効率化や一貫性は重要とはいえ、ボトルネックがこれらが不明確なら、どれだけトークンガバナンスを整えても解決しません。ドキュメントの整った、しかし依然として速くリリースできないコンポーネントができるだけです。

長年デザインシステムのガバナンスが答えようとしている「デザインシステムとプロダクトニーズが対立するとき、誰が判断するのか」という問いは、ほとんどの組織で答えをもっていません。「良い感じに、議論しながら決める」といったルールでは、判断の一貫性が失われ、次第にプロダクトとデザインシステムの差が広がっていきます。

例外があるとしたら「デザインシステムがプロダクトそのもの」である場合。Shopify、Airtable、Softr、Kintone のようなプラットフォーム企業は、デザインシステムがプロダクト開発だけでなくユーザーも扱う大事な道具になるので、プロダクト戦略とデザインシステム戦略がアラインしやすいです。言い方を変えるなら、デザインシステムそのものが売り上げに直結しています。

#372 AIもデザインシステムも銀の弾丸ではない（sakitoさん）

http://yhassy.heteml.net/mp3/automagic372.mp3

Yasuhisa HasegawaYasuhisa Hasegawa

多くの組織でデザインシステムがプロダクトそのものではない場合、問いは「プロダクト開発のボトルネックが本当に実装レイヤーにあるのか？」に移ります。 現場の効率化が進んでも、開発工程全体の観点で見たときに、 「コンポーネント採用数」で成果を示す。デザインシステム評価として、これは分かりやすい指標です。ただ、デザインステムが成長期に差し掛かっているにもかかわらず、自分たの効率化だけを物差しにし続けると、問いはいつも「もっとってもらうには？」に戻ってきます。使ってもらうための座組や、複雑な判断ツリーを作るといった活動を何年も続いているのではないでしょうか。

デザインシステムに過度な期待をしないほうがいいと言われて久しいです。ただ、Design Tokens や AI への注目が高まったことで、期待は形を変えて再び膨らみ始めているように見えます。技術や手段は新しくなっても、「仕組み化すればうまくいく」という前提は変わっていません。これは以前から繰り返されてきたトラップと同じ構造です。手段ではなく、前提そのもの疑うところから始める必要があるのではないでしょうか。

組織の文脈を置き去りにしたデザインシステムの罠

デザインシステムの成功は手段の選択に大きく左右されるわけではなく、実際には計画の不備が失敗の原因となることが多いです。

Yasuhisa HasegawaYasuhisa Hasegawa

探索ツールから始めてみる

先述したように、Design Tokens によるメリットはありますし、様々な可能性を示しています。最終ゴールは、プロダクションインフラとして位置づけですが、そこへいきなり突き進もうとするとプロダクトチームとの連携で悩み始め、使えるモノができる前に仕組み化の議論が増えてしまうことがあります。

最近、試し始めているのが Design Tokens をつかったプロトタイプ制作です。今でもバイブコーディングでプロトタイプを作っている方はいますが、 Design Tokens を活用することで、早期に「自社プロダクトっぽい見た目」のプロトタイプでアイデア発散ができます。詳細なところまで Design Tokens を定義していなくても、Semantic Tokens がある程度揃ってさえすれば『らしい』デザインを出力することができます。きちんと Design Tokens が作られることを待つことなく、現場で検証できるのも魅力です。

ここで重要なのは、ただ Design Tokens を使うだけでなく、判断の記録を残すことです。コンポーネントをはじめ、色の使い方、スペース、配置など、どのように出力したかログを残しています。どういう文脈（企画案）で、どんなコンポーネントが必要になるのか。間違えやすいデザインの判断ポイントはどこかも見えてきます。記録情報が プロダクションインフラとして Design Tokens を活用する際の貴重な資産になります。

Design Tokens の可能性は、制作効率化だけにとどまらない思います。トークンという共通の基盤があることで、制作・実装だけでなくプロダクトチーム全体が貢献しやすくなります。

また、仕組みの作り方にも見直す余地が生まれます。インタビューや会議で「こうしてほしい」と言れたことをもとに設計するのではなく、実際にどう使われてるかという行動から積み上げていく。言葉ではなく行動を起にすることで、長年の課題だったアライメントに少しずつ近けるのではないかと思います。

「試したけど、使えなかった」

プロンプトを書いて、出てきたものを見て、「これじゃない」アウトプットが生成される。何度か試して、結局 Figma でデザインを始める。「それっぽい UI」が出来ても、ちょっとした調整に疲れていつしか触らなくなったという経験は私だけではないはず。

想像していたデザインが生成できなかったからといって諦めるのはもったいないです。 デザインプロセスは混沌としています。最初に計画したものをそのまま作り上げるのではなく、見たものに応じて少しずつ調整していく過程です。 つまり、混沌としたプロセスをすべてAIに任せるのではなく、その中から一部を抜き出して作るというアプローチを取ることで、様々な可能性が見えてきます。

先に言語化を求めるAIツール

デザイナーがAIをまったく使っていないわけではありません。

ISCA TOKYOの調査によると、アイデア出しやブレストにAIを活用しているデザイナーは67.9%に達しています。一方で、Figma AI Report 2025では、UIレイアウトの探索にAIを使っているのは21%程度に留まっています。

「使っていない」のではなく「ブレストで止まっている」のが実態です。アイデア出し、テキストやダミー画像出力では活用できているのに、実際のデザインプロセスに組み込むところに壁があるようです。

新規案件や探索向けのアイデア向けであれば精度が随分上がりましたが、様々な制約を考慮したうえでの「意図通りのデザインアウトプット」は、現時点では少し早いかもしれません。

デザインは「作りながら考える」プロセスです。手を動かしながら「こっちのほうがいいかも」という発見が生まれます。ところが、現在のAIツールは「先に言語化」を要求します。作る前に、作りたいものを言葉で説明しなければならない。このミスマッチが、壁を作っている一因ではないかと思います。

ただ、だからといってこれらの AI に触れる価値がないわけではありません。期待の置き方を変えると、見えてくるものがあります。

デザインツールによる『縛り』

デザインツールで作業していても、「こっちのほうがいい」という新しい発見は、ツールがもつ機能の中に閉じこもることがあります。

レスポンシブwebデザインが当たり前になった時期にデザイナーが「可変するデザイン」を作るのに苦労していた時期がありました。当時は Figma や Sketch のような選択肢がなく、Photoshop を使っていました。しかし Photoshop ではレスポンシブ対応を試みても、ツール上で可変状態を表現する機能がありませんでした。デザイナーの能力や可能性がツールによって制限されてしまったひとつの例です。

それと似たようなことが今起こっていると思います。素材に触れながら、試しながら、「これだ」という感覚にたどり着く。その探索のプロセス自体は、Figmaの外でも実現できるようになってきました。

昔から「デザイナーはコードを学ぶべきだ／知るべきだ」という論調があります。今でも1, 2年に一度はSNSなどでその議論が持ち上がります。「Design in Browser（ブラウザ上でデザインする）」という考え方もあり、デザイナーは制作物の素材を理解した上で設計すべきだという主張が込められています。

一昔前であれば、コードを知ろうとするだけでも難しかったです。また、簡単なものを作るにしても、実装環境を整えるのが大変でしたし、そこから模索するための無難なインターフェースもありませんでした。コードも書けるデザインエンジニアだけが、コードに触れながらデザインするという状況が生まれたと思います。

そうした背景から、デザイナーはデザインツールに閉じこもり、そのツールで可能な表現だけを考えるようになったのではないでしょうか。そのことが、デザインと実装の連携をより複雑にしたとも感じます。Figmaではこう見えるが実装ではできない、あるいは実装ではこうだがFigmaではその見た目を継承できない、といったギャップと戦ってきた人もいると思います。

トランジションのイージング。インタラクションのタイミング。ホバー時の挙動、スクロールに連動したアニメーション、マイクロインタラクションの細部。本当は「こうしたい」というのがあっても実現できなったデザイナーもいると思います。それらは、コードが書ける人たちの『特権』となってしまったところがあります。

コードと接点をもちながらデザインすることの最大のメリットは素材に直接触れてデザインできることです。先述したようにデザインは「作りながら考える」プロセスです。実装された状態で見たり触ってはじめて気付くことがたくさんありますし、そこから新しいアイデアが生まれることがあります。

Webflow や STUDIO のようなノーコードツールでデザインしている人も似たような感覚があると思います。実装済みのページを実際に触りながら、「こうしたらどうか」「ああでもない」と試行錯誤して詰めていく感覚は、デザインツールではなかなか得られません。

素材に触れながら作ってみる

AI やノーコードツールは「コードを知るべき、書けるべき」といった議論から解放され、自分で素材を使ったデザインできる良い手段です。AIも「画面全部を作ってもらう」ではなく、「素材に触れながら模索するスケッチブック」のように扱うと、可能性が広がります。

例えば、コンポーネントのちょっとした動きでも、コンマ単位でどんな挙動をするのかをチェックしながら試したいときがあると思います。そこで私は、パラメータ付きのUIコンポーネントを実装し、実際に触りながらどれくらいの数値が適切かを考えられるツールを作りました。

従来であれば、こうしたツールを作るのは非常に面倒でしたし、エンジニアにわざわざ作ってもらうのは負担だと感じる人も多かったと思います。しかし、今ではデザイナー1人で30分ほどで作れてしまうようになりました。

こうしたツールが作れると分かれば、「このコンポーネントでマイクロインタラクションをどう作ればよいか」「触ったときの感触はどうか」といったことを自分で模索できるようになります。また、セオリーだけに頼るのではなく、自分の感覚を研ぎ澄ます機会にもなります。

AIを、自分の仕事の成果物を代わりに作ってもらうツールと考えるのではなく、自分の仕事の幅を広げるための道具として捉えてみるとどうでしょうか。自分だけの道具（スケッチブック）。素材に直接触れることでアイデアが広がりそうなコトは何でしょうか。最初は時間がかかると思いますが、きっと自分だけの道具が作れるはずです。ぜひ試してみてください。

心理的安全性（psychological safety）は、ハーバード・ビジネススクール Amy Edmondson 教授が1999年に提唱した概念です。彼女はこれを「チームメンバーが対人関係のリスクを取っても安全だと共有された信念」と定義しています（Edmondson, 1999）。アイデアを共有したり、質問をしたり、ミスを認めたりすることが、罰や恥辱を恐れずにできる状態を指します。

この概念が広く知られるようになったのは、Googleが2012年に実施した「Project Aristotle」です。生産性が高いチームには心理的安全性が最も重要な要因であることを示しました（Google re:Work）。Edmondsonの研究でも挙げられている心理的安全性の条件は、リーダーシップやチームマネージメント文脈でも語られています。

• 「どう思いますか？」「他に考えはありますか？」と積極的に尋ねる
• 批判や懸念に対して、感謝を示し建設的に応答する
• 「私にもわからない」「間違っているかもしれない」と認める

心理的安全性を作るためには、誰に対しても、どこでも、気兼ねなく発言できることが推奨されいます。しかし、状況や相手を問わず、いつでも率直に発言することが、本当に安全な場と言えるのでしょうか。 特に関係性を重視する人にとっては、不安を煽るだけです。

関係性を重視する人 は、相手との関係性、状況、文脈に応じてコミュニケーションを適切に調整することで安全なコミュニケーションの場を育んでいます。誰が相手なのか、どのような場なのか、何が問われているのかといった要素を無視して一律に率直に発言することは、不適切であり、むしろ関係を損なう行為と捉えます。状況を読んで適切に振る舞えるという信頼が、発言の正当性を支えることもあります。

チームコミュニケーションにおいて「場の空気を読む」ことが 否定的に語られることがあります。「気兼ねなく発言するべきなのに、空気を読んでは意味がない」と言われるものの、関係性を重視する人にとって、文脈を読むことが安全を作り出す行為ですから、空気を読むことが必然的です。心理的安全性を作るために推奨される行動は、ある特定のコミュニケーション文化において安全を作り出しますが、それを普遍的な手法として適用しようとすると、別のコミュニケーション文化では逆に安全ではなくなります。

「チームの心理的安全性をどう育むか」を考える前に、まず「自分たちが安全だと感じるのはどんなときか」を問い直す必要があります。ある一つのコミュニケーション様式を普遍的とみなすことが、かえって安全を損ないます。日本のチームで安心してコミュニケーションできる環境とは、どのようなものでしょうか？

多くの場合、美術館に行くこと、たくさんの本を読むこと、様々なアプリやwebサイトを触ってみることを指します。こうした体験を積むことは確かに大切で、感覚を養う上で重要です。

ただ、それだけで本当に成長へつながるのでしょうか 。美術館で見た展示デザインを写真に撮っても、実際の仕事では使わない。参考になりそうな素敵なUIを保存しても、自分のプロジェクトに活かせない。こうした経験は、多くのデザイナーが持っているはずです。

ここで言う「好奇心」は様々な作品に触れるだけでなく、もうひとつの意味があると思います。今自分が目にしているアプリやwebサイトが、どのような文脈や制約に基づいて作られているのかを考えることです。

たとえその考えが間違っていたとしても、「なぜこのような見た目になっているのか」「どのような状況がこの見た目を生み出しているのか」と想像を巡らせることが大切です。そうすることで、見た目だけでは分かりにくい制約や事業の状況、またユーザーのことが見えてくることがあります。

なぜこの機能は目立つ位置にあるのか。なぜこのフローは3ステップではなく5ステップなのか。なぜこのボタンを目立たせているのか。こうした「なぜ」を問い続けることで、見た目の背後にある意思決定の構造が見えてきます。

収集と文脈理解、両方があって初めて好奇心は仕事に活きてきます。
最近見たデザインは、どのような文脈から生まれたと思いますか？