前編では、朝の「おはよう」から夕方の手渡しまで、私がAIとどう働いているかを1日ぶん追いかけました。

「AIとペアで働く1日」タイムライン（前編のおさらい）

ここからは、その裏側の話です。ここまでの内容を「便利そうだけど、なんだか難しそう」と感じた方もいるかもしれません。けれど、これらを支えている根っこは、実はとてもシンプルです。AIを"きちんと使える相棒"に育てる、その勘どころを4つ、お話しします。

なお、前編を読んでいなくても、ここから読み始めて大丈夫なように書いています。

コツ① AIに「記憶」を持たせる

前編の朝のパートで「私のAIは昨日までの動きを覚えている」と書きました。あの件です。

多くの人がAIを使うとき、毎回まっさらな状態から会話を始めます。だから毎回、前提から説明し直すことになってしまいます。「私はこういう仕事をしていて、このプロジェクトはこういう状況で…」と。地味だが大きな無駄。毎朝、初対面の人に自己紹介をやり直しているようなものです。

そこで私は、AIに記憶の置き場所を用意しています。自分のこと、プロジェクトの状況、過去に下した決定、AIにかけたフィードバックといったものを、AIが自分で書き留め、次回また読み返せるようにしてあります。

ちなみにこの"記憶"は、何か特別なデータベースを使っているわけではありません。実体は、手元のパソコンに置いた、ただのマークダウンファイルの集まりです。日報も、議事録も、デザインシステムのドキュメントも、AIへのフィードバックも、ぜんぶ同じ場所にファイルとして溜まっていくようにしています。私はObsidianというメモアプリで管理していますが、別にツールは何でもよくて、プレーンなテキストで置いてあることが肝です。

というのも、AIはテキストファイルの読み書きが得意だからです。フォルダごと作業場所として渡してしまえば、必要なファイルを自分で探して読み、自分で書き足していってくれます。しかも中身はただのテキストなので、人間の私もいつでも開いて読めるし、手で直せるという。AIと人間が同じ棚を共有しているようなイメージです。特定のサービスに囲い込まれず、明日別のAIに乗り換えたとしても記憶ごと引っ越せるのは大事な安心感だと思っています。

会話を重ねるごとに、AIがだんだんこちらのことを分かっている優秀な秘書に育っていきます。「この人はこういう判断を好む」「この案件ではこういう約束事がある」などなど。いちいちゼロから説明する必要がないAIはとても快適です。

「AIに記憶を持たせる」循環図＋記憶が効く2つの場面

コツ② 繰り返す作業は、自分用にちょっと整えた道具にする

前編の夕方のパートで出てきた「品質チェックの段取り」や「日報の下書き」。あれらは、毎回ゼロから頼んでいるわけではありません。よく使う一連の手順を、ひとまとまりの形に整えて、合言葉ひとつで呼び出せるようにSkillにしてあるのです。これも、世に出回っている仕組みを自分用にちょっと整えただけで、難しいことはしていません。

一度「こういう手順でやって」と教え込んでおけば、次からは合言葉ひとつで、その手順をまるごと呼び出せるようになります。

肝心なのは、「自分が毎回やっている面倒な手順は何か」を見つける勘です。技術そのものより、こちらのほうがずっと大事。「あ、この作業、毎週やってるな」と気づけたら、Skillにすれば後々楽できます。

コツ③ AIは魔法ではない、という正直な話

ここまで偉そうに調子のいい話ばかりこいてきたので、あまり嬉しくない正直なところもお伝えしておきます。

AIは、しょっちゅう間違えます。

自信満々に的外れなデザインを出してきたり、古い情報を掴んだまま喋ることもあります。「これで完璧に直しました！」と言いながら、実は1ミリも直っていないこともしばしば。

だからこそ、最終的な判断は必ず人間が握ることは（今のところ）すごく大事です。AIは優秀なアシスタントですが、責任を取ってはくれません。出てきたものを鵜呑みにせず、ちゃんと緊張感を持って自分の目で確認するようにしましょう。

それから、任せる領域にもあらかじめ線を引いています。前例のない、勝負どころの新しいデザインは人間が主導して、AIの案は思考を進めるための中間素材として使う。いっぽう日々の改修や定型的な画面づくりは、ここまで書いてきたようなペアの進め方で十分に戦える。全部を任せようとするから怖くなるのであって、「どこを任せて、どこは渡さないか」を先に決めておくと、付き合い方はずっと健全になります。

とはいえ「緊張感を保つ」なんて心構えは、正直、長続きしません。人間（特に私）の注意力はそういうふうにはできていないので、AIの言うことを無批判に受け入れていないか確認できるように、私はここも仕組みにしています。

やっていることは単純で、AIの提案を「理由を付けて却下した」記録を、日報に自動で残すようにしているだけです。「この配色案は、実物の画面を確認せず名前から推測していたので却下」的な一行が、日々ぽつぽつと溜まっていくようにしています。日報の下書きを起こすついでに、AI自身にその日の"却下されたこと"も書かせているので、手間はかかりません。

この記録をしておくと、あとで読み返した時に自分の状態がある程度掴めます。根拠を持って却下できているうちは、ちゃんと手綱を握れている証拠。逆に、却下ゼロの日が何日も続いたら黄信号です。AIの出力をろくに確認せず、素通しし始めている可能性のアラートです。「ちゃんと疑えているか」を、気合いではなく記録で見張っていれば、ある程度の抑止力にはなるかなあと思っています。

逆に言えば、この一線さえ守れば、AIは怖がる相手ではありません。こちらが手綱を握っていればいいんだと思えると、ずいぶん気楽に付き合えるようになります。

コツ④ 道具より先に、AIが読みに行く先を整える

最近、「Figma MCPを入れたけど、思ったほどではなかった」という話をちらほら聞くようになりました。

Figma MCPというのは、ざっくり言えばAIがFigmaのデザインデータを直接読み書きできるようにする仕組みです。うまく使えば、デザインからコードへの受け渡しが一気に近くなる。期待されるのも当然だと思います。

ただ、開発に渡すときの話より先に、デザイナー自身にとってのメリットの方が大きいと私は思っています。

前編で「デザインを言葉から立ち上げる」という話を書きましたが、あれが成立しているのはMCPのおかげです。「患者一覧に絞り込みのモーダルを足したい」と伝えると、AIはデザインシステムの中から正しいコンポーネントを選んで、正しいバリアントを指定して、色や余白もトークンで指定した状態で組んでくれる。ゼロから四角を並べるのではなく、既存の部品で組み上がってきます。

これ、地味に見えてかなり大きい変化です。というのも、UIを組む作業の体感の大半は「考える」ことではなく「探して・選んで・置いて・揃える」ことだからです。ボタンのバリアントはどれだったか、この余白は8だったか12だったか、似たコンポーネントが2つあるけどどっちが新しいのかなどなど、この探し物と手作業がごっそり減ります。私はそのぶんの時間を、レイアウトの検討や文言に回せるようになりました。

しかも副次的な効果として、組み上がった時点でDSに準拠しているんですよね。あとから「野良の四角を正規のコンポーネントに差し替える」という、あの一番やりたくない作業が最初から発生しなくなります。

ただ、これを「繋げば使える道具」だと思って入れると、たぶん肩透かしを食らいます。

というのも、AIが読みに行った先。つまりコンポーネントの名前や、色や余白の設定や、それが何のための部品なのかという説明が整っていなければ、AIは平気で嘘の実装を書いてくるからです。名前が揺れていれば取り違えるし、説明がなければ用途を推測で埋めてきます。「正しいコンポーネントを選んでくれる」と書きましたが、それは選べるだけの手がかりがある場合の話です。読む先が散らかっていると、賢い道具のはずなのに間違ったパーツを自信満々に高速で持ち帰ってくるだけになります。

私自身、狙ってやったわけではないのですが、振り返ってみると順番が逆でした。先にドキュメントを整えていたら、道具の方が後から効くようになったというのが実際のところです。前編で書いた台帳の整備も、命名の統一も、書いている時点では「AIに読ませるため」というより「自分とチームのため」でした。それがそのまま、道具が効くための下ごしらえになっていた。

だから、もし今から始めるなら、順番はこうかな？と思っています。

1. コンポーネントの名前と設定を揃える（AIが取り違えないように）
2. それが何のための部品で、どういうときに使うのかを書く（AIが推測で埋めないように）
3. それをエンジニア側からも読める場所に置く（自分のAIだけの秘密にしない）

派手さはまったくないですが、この3つが揃っていない状態でMCPを繋いでも、たぶん「便利なようで信用できない」という中途半端なところに着地します。逆に言えば、1と2だけでも自分の作業はラクになります。3まで揃うと、開発への受け渡しまで効いてくる、という順番です。

もうひとつ、地味ですが効くなと思っているのが、例外を人の頭の中に置かないことです。

うちのデザインには、ルール上は違反だけれど意図的にそうしている箇所がいくつかあります。たとえば、ある画面の文字の行間だけ、規約の数値から外れた詰め方をしていた。理由があってそうしていたのですが、これを「わかってる人だけが知っている暗黙の了解」にしていると、事故ります。AIは当然「ルール違反だ」と指摘してくるし、他の人が見れば善意で"直して"しまう。実際、私はこの説明を何度も繰り返していました。

先日、規約側にその数値を追加したので、該当箇所をまとめて正規のルールに沿う形に置き換えました。見た目は1ミリも変わっていません。変わったのは、「知っている人にしか守れなかったもの」が「誰が見ても読み取れるもの」になったことだけです。

とはいえ、ここまで読んで「ドキュメントを整えるのが一番めんどくさいんだよなー」と思った方も多いと思います。私もそう思います。

でも実は、この部分こそAIに任せられるところです。

私は台帳を書くとき、きちんとした文章を自分で打つことはほとんどありません。やっているのは、AIと普通に喋るだけです。「このコンポーネント新しく作ったんだけど、エラー状態のバリアントを足した。色はこのトークンを使ってて、使う場面は入力フォームの必須未入力のとき。あと、これに似た既存のやつがあるから、そっちと間違えないように注意点も書いといて」このくらいの、口で説明する感じの雑な喋りでOKです。あとはAIが既存の台帳の書式に合わせて清書してくれます。

私がやるのは、出てきた文章に目を通して「ここは違う」「この注意点が抜けてる」と直すことだけ。ゼロから書くのと、出てきたものを直すのとでは、必要な気力がまったく違います。

だから「ドキュメント整備」と身構えなくていいと思っています。頭の中にあることを、口に出してAIに書き取らせるだけで、AIが読める資産がひとつ増える。整った文章を書く作業と、判断を外に出す作業を、分けて考えるといいのかもしれません。

AIと一緒に働く時間が増えるほど、自分の頭の中にしかない判断は、そのまま事故の種になるという実感が強くなってきました。道具を増やす前に、頭の中を外に出しておく。遠回りに見えて、たぶんこれが一番効きます。

おわりに

前編と後編、二回に分けて、私の1日をずいぶん長々と追いかけてきました。「うわめんどくさ」と気圧されてしまったら、本意ではありません。

それに、こういう働き方は私だけの発明ではありません。最近は国内外で、似たような仕事の仕方がたくさん発信されています。リサーチや戦略といったデザインの芯は変わらないまま、実行のやり方だけが静かに入れ替わっていくという流れは業界ぐるみの変化のようです。まだみんな試行錯誤の途中です。

大事なのは、最初から完璧な仕組みを目指さないこと。小さく任せて、ちょっと直して、また任せて。そうやって少しずつ、AIを育てていくと、本当に大事なところに集中できるようになるなと感じています。