デザイナーの私がAIと"ペアで"働く1日（前編）— 朝から夕方までの実況

はじめに — Figma Configで思ったこと

先日、Figma Configに参加してきました。

せっかく世界中からデザイナーが集まってるんだし、とわかっちゃいるんですけども、知らない人にぐいぐい話しかけられるほど社交的な性分でもなく、基礎英語レベルで脱落した私は、夜の交流の場ではもっぱら壁のシミでした。それでも色々な企業のデザイナーさんとお話しできてとても楽しかったです。

で、その会話の中で、ひとつ意外だったことがあります。
「普段、AIってどう使ってますか？」
そう振ってみると、思いのほか「いや、まだChatGPTにたまに聞くくらいかな」という返事が多かったのです。もちろん、私が話せたのはほんの数人ですから、これで何かを言い切れるわけではありません。それでも、これだけツールが揃って、これだけ毎日のように新しい使い方が生まれているのに、案外みんな、その入り口で立ち止まっているのかもしれないなという感じがしました。
もちろん大きな会社だと、ガバナンスだとかセキュリティとか稟議とか色々あるので一筋縄ではないですよね（自分も経験あり）。

それを目の当たりにして、ふと思いました。「あれ、もしかして私の普段の仕事の仕方って、書いてみる価値があるんじゃね？」と。

申し遅れましたが、私は今年の1月から、医療系のSaaSを提供しているクロスログという会社でUIデザイナーとして働いています。社員全員フルリモートの会社の中で、デザイナーは社内に私ひとり、いわゆる"ひとりデザイナー"です。その前は、日本初のデジタルバンクでプロダクトデザイナーを5年ほど、アプリのUIデザインとデザインシステムの構築を担当していました。

ジョインしてまだ半年ほどで、すでに世に出ているプロダクトを引き継いで、新機能の設計と既存画面の作り直しを並行して進めている最中です。デザインシステムも運用も、まだ整えている途中。この記事に出てくる仕事の風景は、そこでの日々です。

先に断っておくと、これからお話しすることは、どれも私が編み出した特別な技ではありません。ネットを探せばいくらでも出てくるやり方を、自分の仕事に合うようちょっとアレンジして、繋ぎ合わせているだけです。一つひとつは、誰でも今日から真似できる程度のものです。

しかも、ここで紹介する内容が正解だとも思っていません。きっと、もっとスマートなやり方がいくらでもあるはずです。詳しい人にとっては「何を今更」って内容だと思います。
ただ、その「ちょっとしたアレンジ」と「繋ぎ合わせ方」に手を出すのが億劫な人が、まだ結構多いのかなって思ったりしました。だから、大層な手柄話としてではなく、「こういう寄せ集め方もあるよ」という一例として、この記事を読んでいただけたらと思います。

それでは、そんな私の「AIとペアで働く、普段の1日」を、朝から晩まで追いかけてみます。

「AIとペアで働く1日」タイムライン

9:00 — 1日は「おはよう」から始まる

1. AIに今日の段取りを整えてもらう

朝始業すると、AIに「おはよう」と打つところから始まります。

この一言で、AIが昨日までの作業の続きと、今日やるべきことを整理して、朝のブリーフィングをまとめてくれます。

「昨日はこのコンポーネントの修正を途中まで進めていましたね」「今日はこのMTGがあるので、その前にこの確認を済ませておくとよさそうです」といった具合です。

「朝のブリーフィング」出力イメージ

なぜこんなことが可能なのか。それは、私のAIが昨日までの私の動きをちゃんと覚えているからです（この"記憶"の仕組みは、後編でお話しします）。ついでにカレンダーまで見に行ってくれます。必要であればSlackも。読みに行って内容を把握し、必要であればアクションまで提案してくれます。

朝、まだ頭が半分眠っていて、脳に血が巡るのを待っているような時間に、AIがブリーフィングを済ませてくれるので、1日の立ち上がりがずいぶん楽になります。私は基本的に自分の記憶力を信じてないので、ログを残してそれを効率的に活用できるのがAIの便利なところだと思ってます。また、タスクの記憶を外部化できるのは、メンタルヘルス的にもとても良い効果があると感じてます。

2. 業界のキャッチアップもAIに任せる

デザインや業界の情報キャッチアップ、しっかり時間を取るのが大変だなーと思うことってありませんか。Figmaの新機能、AIやデザインシステムの潮流、自分が関わるビジネスの領域の動向もみておかないといけない。

これを毎朝、自分で記事を漁って…とやっていたら、それだけで午前が溶けます。気づけば昼、なんてことになりかねない。ややもすると給料泥棒になってしまいます。

なので、ここもAIに任せます。「最近の業界ニュースを集めて、要約して、マークダウンで保存しておいて」という指示を朝8:50くらいに実行されるようにしています。しかも単なる要約ではなく、「これは自分たちのプロダクトにこう効いてきそう」という示唆まで添えてくれるように仕込んであります。

9:30 — 制作の現場でこそ、真価を発揮する

ここまでやればだんだん頭も冴えてくるので、ここからが本番です。デザイナーの本業にAIをどう組み込むか。ここからは少しずつ、踏み込んだ道具も登場します。

3. デザインを"言葉"から立ち上げる

たとえば「在宅医療の患者さん一覧を表示するカード」を新しく作るとします。

従来なら、まっさらなFigmaを開いて、長方形を置いて、テキストを並べて…とゼロから組み上げていくところ。でも私は最近、いきなりFigmaには向かいません。まずはHTMLで"動くモック"を作ってしまうことが多いです。

「こういう情報を載せた、こういうレイアウトのカードを作って」と言葉で指示すると、AIがHTMLとCSSでサッとモックを何パターンでも書いてくれます。これをブラウザで開けば、実際の画面に近い状態で確認できます。データを差し替えてみたり、画面幅を変えてレイアウトの崩れを見たり——静止画を眺めて頭のなかで想像するより、実物に触れて検証できるほうが、断然はやいし確実なのです。

明確な指示をするのが大変な場合でも、どう言ったものを作るかを決めたSlackのスレッドやミーティングの文字起こしをAIに読ませてしまえば意図を汲んで最初のラフを作ってくれたりもします。

最近はこの下書きの工程を、もう一歩だけ型にしています。まずAIに既存画面や世の中の類似UIをざっと調べさせて、そのうえで方向性の違う案を2〜3個、モックとして作らせる。単なる色違いではなく、「一覧性を優先した案」「入力の誘導を優先した案」のように、判断が割れる軸で分けるのがポイントです。最後に「どの案を推すか、その理由は何か」までAIにまとめさせて、調査と案と推奨理由をひと目で見比べられる状態にしてから、自分で決めます。案がひとつだけだと「本当にこれでいいのか?」と不安なまま進みがちですが、比べる相手がいると判断は驚くほど速くなります。

そうやってモックで「これでいけそうだ」と当たりがついてから、Figmaで清書に入ります。ここで使うのが Figma MCP という仕組み。ざっくり言えば、AIとFigmaを直接つないでしまう橋のようなものです。検証で固まったレイアウトを、今度はチームに渡せるきちんとしたデザインデータとして、Figma上に起こしていきます。

つまり私のなかでは、HTMLモック＝考えるための下書き、Figma＝開発側に渡すための清書、という役割分担になっているわけです。言い換えると、発散は安くて速い媒体でたっぷりやって、いちばん手間のかかる清書は、選ばれた1案にだけ払う。いきなり清書から入ると、考えがまとまらないうちに見た目だけ作り込んでしまって、あとでまるごと作り直し…なんてことになりがちなので。

「下書きと清書を、分ける」フロー

もちろん、最初のモックがそのまま完成品になるわけではありません。けれど、「0から1」の一番しんどいところをAIが肩代わりしてくれるのが大きかったりします。白紙のキャンバスとにらめっこしたまま、いつのまにか灰皿に吸い殻の山が溜まっていく、あの不毛な時間がぐっと減るのです。

正直な話、Figmaで清書する段でも、最初の頃は出てきたデザインの粗さにがっかりすることがありました。色やフォントが自社のルールから外れていたり、余白がガタついていたり。「これじゃない」とキーボードクラッシャーになりかけたことも一度や二度ではありません。

そこで今は、清書のときに自社のデザインシステムのドキュメントを、AIに下敷きとして読み込ませるようにしています。どのパーツにどのFigmaコンポーネントを使うか、ボタンならどの状態のプロパティを当てるか、見出しや本文にどのテキストスタイルを適用するか——そうした決まりごとを資料にまとめておいて、それを参照させながら作らせます。すると、行き当たりばったりではなく、最初からデザインシステムに沿った、（ある程度）正しい部品で組まれたデザインが上がってきます。手で一つひとつ「ここはこの変数を使って」と直していた頃に比べると、雲泥の差です。

AIは、こちらが土台をきちんと整えてあげるほど、ちゃんと賢く応えてくれます。

そしてこれは、自分が楽をするためだけの工夫ではありません。むしろ、デザインを受け取る開発側にとってのメリットが大きいと思っています。

デザインが最初からデザインシステムの部品で組まれていると、エンジニアは「あ、これは既存のあのコンポーネントだな」とすぐ分かります。わざわざ新しく作り起こす必要がなく、用意済みの部品をそのまま実装に使えるんです。色や余白の値も、デザインシステムで定義された変数にひもづいているので、「この青の正確な値は?」「ここの余白は何px?」と毎回確認するやりとりも減ります。デザインと実装が、同じ部品・同じ数値で最初から揃うわけです。

逆に、見た目だけ似せた"一点もの"のデザインを渡してしまうと、エンジニアは「これは既存の部品で作れるのか、それとも新しく作るのか」をいちいち判断しなければいけません。その確認のラリーが、地味に積み重なって効いてきます。デザイナー側でひと手間かけてデザインシステムに揃えておくだけで、その先の実装がぐっと滑らかになります。AIのおかげでそのひと手間が軽くなったから、ここを横着せずに済むようになった、とも言えます。（とはいえまだまだエンジニアとの会話はゼロにはなりませんが、グッと楽になっていると感じています。）

4. すでにある画面を、そっくりFigmaに取り込む

ある程度歴史があるプロダクトだと、すでに実装されてリリースされている画面ってありますよね。それをデザインのたたき台にしたいとき、従来はスクリーンショットを撮って画像として貼るくらいしかありませんでした。でもそれだと、当然ながら編集ができません。

そこで、ブラウザを自動操作するツール(Playwright)とFigma MCPを組み合わせて、実装済みの画面を"編集可能な状態"のままFigmaに取り込むということをやっています。テキストはテキストとして、ボタンはボタンとして、ちゃんと部品ごとにバラして持ってくることができます。

「実装が先に進んでしまって、デザインデータが追いついていない」——現場ではよくある悩みですが、これでデザインと実装の辻褄を、後からでも合わせにいけるのです。

ただ、この取り込みはパーフェクトではありません。取り込めたといっても、それはあくまで"見た目をバラして再現した"状態で、自社のデザインシステムの変数やコンポーネントは当たっていないのです。また、異様にレイヤー構造のネストが深く、編集しづらかったりとか。
テキストやボタンの"形"はそこにあるんだけど、中身は言わば、ただの図形の寄せ集めに近い。これを正しいコンポーネントや変数に一つひとつ置き換えていく作業が、地味に骨が折れます。しかもここが、AIに「既存コンポーネントやバリアントを適用して綺麗なデータにして」と任せてもなかなかうまくいかない領域でして、今も「うーん」と唸りながら手探りしている、正直な困りどころです。

ちなみに、取り込むだけであれば、先日Figma公式からChrome拡張が出て、近いことがもっと手軽にできるようになってきたのでこれも大変おすすめです。

5. デザインシステムドキュメントの更新と開発への共有

先ほどチラッと出てきたデザインシステムドキュメントですが、デザシスの追加や修正を行なった場合、AIと対話しながらGithubへのプッシュまで一気通貫で進めてしまいます。

たとえば「このコンポーネントを新設する必要があるな」と気づいたとき。Claudeの力を借りて、既存のコンポーネントライブラリと一貫性を保ちつつ、新規コンポーネントを作成します。（簡単なものであればClaudeに作らせてしまいます）
必要であればバリアントの追加も同時に実行します。

Claudeが何のためのどんなコンポーネントなのかというコンテキストを踏まえて、デザインシステムドキュメントを更新してくれるので、目視チェックの上リポジトリにプッシュさせます。
ついでにFigma MCPを使えばコンポーネントのディスクリプションも更新できるので、ここも更新しておくとさらに良いです。

Gitにプッシュされたドキュメントはデザイナーだけでなく開発者や彼らが使ってるAIエージェントが最新のものを参照するようにしているので、AIが生成するデザインやコードの正確性向上や、エンジニアだけで画面を作成することになった時の指針になります。

これは絵に描いた餅ではなく、実際にもう回り始めています。このごろは、エンジニアが自分のAIエージェントにデザインデータとこのドキュメントを読ませて、実装画面を組み上げてくる場面が増えてきました。デザイナーの手が塞がっていても、簡単な画面なら開発側だけで、デザインシステムに沿ったアウトプットが出てくる。判断材料を"機械が読める場所"に置いておくことが、そのままチームの生産性になっているのを実感します。

置いてあるのは、コンポーネントの説明だけではありません。たとえばライティングガイドライン。トーンをどう揃えるか、同じものを指す言葉が画面ごとにブレていないか、日付や単位はどう表記するか、エラーメッセージは何をどこにどう出すか——UIに乗る言葉の判断は、実はデザインそのものと同じくらい数が多くて、そのつど考えていたら日が暮れます。ボタンのラベルを動詞にするか体言止めにするか、みたいな細かい話まで、いちいち迷わなくて済むように決めて書いてあります。

この手のものは、これまで"詳しい人の頭の中"にありました。それを外に出して、書いて、みんなが見える場所に置く。すると人間もAIも、同じものを参照して判断できるようになります。私が「その言い回しはうちのトーンじゃないです」と毎回指摘して回る必要は減りますし、このあと出てくる文言レビューのAIも、このガイドラインを下敷きに動いています。判断材料を書いて置いておくことが、そのまま品質の底上げになる——というのが、いちばん実感しているところです。

面白いのは、こういうガイドラインを書く作業自体も、AIでずいぶん軽くなったことです。既存の画面から言葉づかいを片っ端から拾わせて、「同じ意味なのに表現が割れている箇所」を一覧にしてもらう。そこまで並べば、あとは「どちらを正にするか」を決めるだけです。ガイドラインは"作るのが重いから、いつまでも作られない"ものの代表格ですが、その重さが下がると、判断材料が置いてある状態を保ちやすくなります。

最近はさらに一歩進めて、ドキュメントだけでなく、Figma上での仕様の書き方そのもの——どこに注記を書くか、どんな書式で書くか——もエンジニアと取り決めて、同じ場所に公開するようにしました。デザインデータに書き込んだ仕様を、エンジニアのAIがそのまま読み取れるようにするためです。「機械が読める場所に置く」の守備範囲が、ドキュメントからデザインデータ本体まで広がってきた格好です。

13:00 — 人と話す時間にも、AIを連れて行く

午後はミーティングが入ることが多い時間帯です。「AIとペアで働く」というと机に向かってる画を想像しがちですが、実はここでもずいぶん働いてもらっています。

6. 議論を、その場でデザインに起こす（これはまだ人力）

仕様を詰めるミーティングで「ここはこういう表示にしましょうか」と話がまとまりかけたとき、その場でFigmaを直して、参加者に画面越しに見てもらうことがあります。議論の結論が、その数分のあいだに目に見える形になります。

先に白状しておくと、ここはAIではなく手作業です。試してはみたものの、会話のスピードにAIのFigma出力が追いつきません。「いま反映させてるので、少々お待ちを…」の沈黙は、会議の場では致命的に長く、その結果トンチンカンな出力だった場合気まずいのです。というわけで、ここは当面、自分の手の速さだけが頼りです。

これの何がいいって、「言った・言わない」「思ってたのと違う」が起きないことです。口頭の合意というのは、案外それぞれの頭の中で微妙に違う絵を結んでいるもの。ミーティングが終わって、後日デザインを見せて、「あれ、こういう意味じゃなかった」という手戻りが、その場で潰せるため、認識合わせを宿題にしないで済むわけです。

AIの出番は、ミーティングが終わってからです。文字起こしとメモをAIに渡して、議事録に清書してもらいます。このとき「決まったこと」と「持ち越しになったこと」を分けて整理してもらうのがポイントで、これが後々じわじわ効いてきます。

というのも——後日、「あの仕様って、どういう経緯で決まったんだっけ?」という話は、必ず出るからです。そのときAIに聞けば、過去の議事録から該当箇所を引き当てて、「◯月◯日のミーティングでこう決まっています」と一次ソース付きで返してくれます。記憶を頼りに「たしか、こうだった気がします…が、どうでしたっけ」と答えるのとは、説得力がまるで違います。同じ議論を二度やらずに済む。自分のためのログが、いつのまにかチームの時間の節約になっている、というのがアツいです。

夕方 — つくったものを、きちんと送り出す

良いデザインをつくることと、それをきちんとエンジニアへ手渡すことは、別の技術です。そして後者こそ、地味で、面倒で、けれど品質を左右する大事な工程。ここでもAIが活躍します。

7. "検品ライン"を組んで、手渡し前の品質を担保する

私はデザインをエンジニアに渡す前に、簡単なAIチェックの段取りを通すようにしています。

これは「機械チェック → AIの判断 → 人間(私)の最終確認」という三段構えになっていて、

まずAIが機械的に、ルール違反を洗い出す(変数の指定漏れ、余白のガタつき、アクセシビリティの不備、レイヤー名など)
次にAIが、それまでの文脈を踏まえて、その中から「これは本当に直すべき」「これは意図的なものだから触らなくていい」を判断する
最後に私が、AIの判断を見て最終決定する

という流れです。

「手渡し前の検品ライン」三段構え＋入口/出口の関所

人間がひとつずつ目視でチェックしていたら、見落としは必ず出ます。私の目なんて、夕方にもなればもうショボショボで半分くらいしか機能してません。かといって機械任せにすると、「本当は正しいのに警告が出る(偽陽性)」に振り回される。この機械の網羅性と、AIの文脈判断と、人間の最終責任を、いいとこ取りで重ねるというのがこの段取りの肝なのです。

ついでにこの時にAIの見落としがあった場合、次のチェックの時に同じミスをしないように指示してSkillを更新しておくといいと思います。

ちなみに最近、この検品には続きができました。チェック結果のレポートを、デザインと一緒にそのままエンジニアへ添付する運用にしたのです。実は受け取る側のエンジニアも、実装した画面を自分たちのAIでチェックしています。つまりデザイナー側の検品が"入口の関所"、開発側の検品が"出口の関所"。人間同士が口頭で確認し合っていたことが、関所二つの分業に置き換わりつつあります。

8. 文言とアクセシビリティも、専門の目でレビューさせる

デザインに乗せる言葉、いわゆるマイクロコピー。ボタンのラベルひとつ、エラーメッセージひとつにも、トーンの統一や分かりやすさが問われます。

これも、専用のレビュー用SkillをAIに用意してあります。先ほどのライティングガイドラインをそのまま下敷きとして読ませてあるので、在宅医療という領域特有の用語の使い方や、自社で定めた言葉づかいのルールに沿って、「この表現はこう直したほうがよい」と提案してくれます。書いて置いておいたものが、そのままレビューの基準として効いてくるわけです。

同じように、アクセシビリティ、つまり文字の大きさ、色のコントラスト、押せる範囲の広さなどが、基準を満たしているか。これも機械的に検証する役を立ててあります。

人間ひとりの注意力には限界があります。「言葉の番人」と「アクセシビリティの番人」をそれぞれ脇に控えさせておく。このような布陣を、ひとりきりの作業机の上で組めてしまうのが、AIをワークフローに組み込む醍醐味だと思っています。

9. 1日の終わりに、日報を自動で起こす

そして1日の締め。その日に何をやったかを振り返り、日報を書く。

これも、その日の作業ログからAIが下書きを起こしてくれます。前日のフォーマットを踏襲して、「今日はこれとこれをやりました」とまとめてくれます。私はそれを眺めて、加筆修正するだけ。

1日働いて疲れた夕方に、ゼロから日報を書き起こすのは、正直めんどくさい。手作業だと「今日、自分は何をしていたんだっけか…」と虚空を見つめることしばし。そこにAIの書いた下書きが一枚あるだけで、ずいぶん気楽です。塵も積もれば、で、こういう小さな省力化の積み重ねが、地味に効いてくるのです。

そして、この日報には続きがあります。

毎日の日報とタスクの記録が溜まっていくので、数ヶ月に一度くらいのペースで、それをまるごとAIに読ませて、自分の実績評価をやってもらうんです。「この期間、何をどれだけやったか。マネージャーの視点で評価とフィードバックを」と聞くだけで、いい感じに分析してくれます。ついでにデザイナーとして価値は現在の市場と照らしたらどうなの？とかも聞けます。

自分で自分を振り返ると、どうしても記憶の濃いところ（直近のことや、苦労したこと）に引っ張られがちです。でもAIは、日報の山を頭から読んで、すっかり忘れていた成果も、目を逸らしたい課題も、同じ温度で拾ってくれます。「この課題、前回の評価から進んでいません」と平気で書いてくるあたり、容赦なしかもしれません。

もちろんこれは自己分析用で、会社の評価制度とは別物です。ただ、毎日の日報という小さな積み立てが、自分を振り返るための便利な情報源として効いてくるのです。

番外編 — たまにやってくる、"読み解き"の一日

ここまでが、私のよくある1日です。最後にひとつだけ、毎日ではないけれど、定期的にやってくる大仕事の話をさせてください。こういう日は、朝から晩までこの作業だけで終わります。

新しい機能の検討が始まるときや、ユーザビリティテストのあとには、「材料を読み解く」工程があります。お客様から寄せられた問い合わせ、テストの記録。こうした生の声の山を、どう束ねて、何を汲み取るか。デザインの良し悪しは、手を動かす前のこの段でだいぶ決まる、と言ってもいいくらい大事なところです。

そして、これがまあ、サクッとは終わらないわけです。問い合わせは数も多いし、ユーザビリティテストの記録は、発話の文字起こしや観察メモ、付箋がどっさり。ひとつずつ目で追って、似たものをまとめて、傾向を見つけて…と手作業で1人黙々とやっていたら、一日どころか何日あっても足りません。腰の重い作業の代表格です。だからこそ、ここはAIに手伝ってもらって、腰を据えた一日仕事に収めています。

ただしその前に、ひとつ大事な下ごしらえがあります。医療のドメインなので、問い合わせやテストの記録には、患者さんや施設の名前が紛れ込み得ます。そこで私は、外部のAIに渡す前に、手元のパソコンの中だけで動くローカルAIに固有名詞を検出させ、目視で確認したうえで別の記号に置き換えるようにしています。ポイントは「AIを使わない」ではなく「個人情報を外部に送らない」という線の引き方です。この下ごしらえを通してはじめて、安心して山ほど読ませられるわけです。

たとえばお客様の問い合わせ。そうして整えたものをまるごとAIに読ませて、「どんな種類の困りごとが、どれくらいの割合であるか」を分類・集計してもらいます。AIは大量のテキストを読んで仕分けるのが得意なので、人間が一件ずつ捌くより圧倒的に速いです。

面白いのは、ただ件数を数えるだけでなく、声になりにくい困りごとがあぶり出されること。大きな声——電話やご意見でいただく声は目立つけれど、その裏で、ユーザーが黙って"獣道"を作っていることがあるんですね。「ひと言メモのための小さな欄に、長文の申し送りを書き込んで凌いでいる」「システムの想定どおりには現場が回っておらず、毎月同じ箇所を手作業で直し続けている」。そういった静かな摩擦は、一件ずつ見ていると見落としがちなのに、全部まとめて読ませると輪郭が浮かんできたりします。似た要望がバラバラに分かれていたのが、実は「ひとつの画面を直せば全部片付く」と見えてくる、なんてこともあります。

ユーザビリティテストも同じです。テスト中の発話や観察メモを渡して、「ユーザーがつまずいた箇所」「繰り返し出てきた反応」を論点ごとに整理してもらう。

最近も、こんなことがありました。テストに同席していた私の目には「迷いなく操作を終えた」ように見えた参加者が、操作ログをAIに突き合わせてもらったら、実は目当ての相手を1分半以上探し回り、同姓の別人を選びかけていたことが分かったのです。人間の印象というのは、その場では本当にあてになりません。ログという事実でAIに検算させて、解釈は人間がやり直すという分担のありがたみを、じわじわ実感しています。

しかも、AIに束ねてもらった結果は、テキストで受け取って終わりではありません。Figma MCPを通せば、その分類をそのままFigJam上に付箋として起こして、グループごとに並べるところまでやってもらえる。これまで自分で付箋を一枚ずつ書いては貼り、似たものを寄せて…と手でやっていたアフィニティ図づくりの下ごしらえを、AIが先にざっと組んでおいてくれるわけです。あとは人間が、その並びを眺めながら「いや、これはこっちのグループだろう」と動かしていけばいい。ゼロから貼り始めるのと、たたきがある状態から動かすのとでは、腰の軽さがぜんぜん違います。

ただ、勘違いしてほしくないのは、AIに結論まで出させているわけではない、ということです。あくまで「読んで、束ねて、見通しを良くする」ところまでを任せて、そこから何を汲み取り、どう設計に落とすかは自分の仕事です。重い前さばきをAIに預けるぶん、人間は一番大事な「解釈」のところに、ちゃんと体力を残しておける。そういう分担の感覚です。