本記事では、エンジニアがそれぞれに見つけてきた"AIとの付き合い方"をご紹介します。仕事に取り入れたツールやワークフローから、チームでの使いどころ、あえて自分の手でやると決めた場面まで。うまくいった工夫だけでなく、試して戻したことや思いがけない発見を通して、AIとの距離の取り方をのぞいていきます。AIをどう使うかだけでなく、どんな距離感で付き合っているのか。誰かのAIとの向き合い方が、あなたとAIのちょうどいい"さじ加減"の手がかりに。
ファインディでCTOをしている佐藤です。CTOと言いつつ、最近はコードを書く時間より、コード以外の仕事をしている時間のほうが長くなっています。
バイブコーディングの日々ではいけない
過去には毎日ただAIと対話するような、いわゆるバイブコーディングをするタイミングも多くありました。バイブコーディングをすることで即座に結果を返してくれるし、画面もどんどん変わっていくのでとても楽しいです。しかし、あとから振り返ると、成果につながらないプロンプトを延々と打っている日が多くあったと思います。1日の終わりに今日を振り返ると、成果がゼロな日もありました。
最近はプロダクトデザインに時間を割くことが多くありました。プロダクトオーナーをしながら、プロダクトの体験をつくるデザインロールも私がやっていまして、Claude Codeにこんな指示を打っていました。
「この画面、このスクショに横幅を合わせて」 「背景色は青を使わない」 「横幅が壊れてるので直して」
フロントエンドやデザインをされる方は、もしかしたら似たような指示を打っているかもしれません。
最後の「横幅が壊れてる」は、ログを見返したら5回ほど繰り返し打っていました。似たような指示は、全部で26ページ分くらいにのぼります。少しもったいないつくり方をしたなぁと思います。当初AIを使いこなしているつもりでいましたが、改めて振り返ってみると、私は同じ内容をAIに伝える役割になっていました。
AIを使って実装するスピードはあがりましたが、それでも毎回同じことを頼むために時間を使い続けました。私の本業はCTOとして議論を進めたり意思決定をしたりすることで、ものづくりはその合間に進めています。だからこそ、同じような繰り返しをして時間を無駄にしていることに気づきました。
速くする以前に、そもそも本当にそれは要るのか？
普通に考えると、次の一手として、これらの作業をどう速くするかに時間を使いがちですが、私は先に「そもそも、このワークフローは要るのか？私は、要らない問いを解こうとしていないか？」と考えることから始めてきました。
作業を速くするという発想には、人間が作業する前提が残ります。UI改修の指示のためにスクショを撮るのが2倍速くなったとしても、私はスクショを撮りつづけていました。人間がすべきでない仕事を少し改善したところで、私が指示を打つ回数は減りません。必要なのは人間の仕事をAIに代替させる根本的な組み替えのほうでした。
実際、改修したいUI名と要素をDevToolsで調べてパスをコピーしてClaude Codeに渡していました。いま振り返るとこれは、要らない問いを要領よく解いていただけで本質的ではありませんでした。本来、パスを調べて渡す作業ごとなくせるのですが、その改善に時間を使っていました。問いの立て方を間違えたまま努力をしても、期待しない能力が高まってしまいます。今回はまさにその例だと思います。
本当に要らないものなら、自分をワークフローの中心から外して、AI中心につくり直すべきです。
そしてもうひとつ、私が大事にしているのは、つくり直すこと自体を楽しむことです。
AIのおかげで、車輪の再発明のコストはほぼゼロになりました。昔なら、既にあるものをつくるなんて何日もかかるし時間の無駄だと言われた行為を、いまは2〜3時間で試せます。ミーティングの合間に依頼すれば気づいたら出来上がっています。
ここで、さきほどの「要らない問いは解くな」と矛盾するのでは、と思うかもしれません。消すべきは人間の無駄な反復で、つくり直すのは学ぶための投資です。この2つは別物だと思っています。
しかし繋がってもいます。無駄な反復を見つけて自分を外すとき、その受け皿となる仕組みを自分の手でつくり直せば、より深く学べるからです。実際、いま社内で進めているデザインシステムのつくり直しが、まさにその両方でした。
デザインシステムを、フィードバックの仕組みごとつくり直した
AI時代は、デザインシステムが手薄だと開発が圧倒的に遅くなります。色やコンポーネントの決まりが整っていないと、AIが期待どおりのデザインをつくれず、結局毎回人間が直すはめになるからです。逆に、決まりがきちんと整っていれば、AIはそれに沿って勝手に良い画面をつくってくれます。デザインシステムは、人間のための道具というより、AIに開発させるための前提条件になってきた気がします。
そして、私が徹底的にこだわりたいのは体験です。だから、本当に欲しいものを自分でつくりに行きました。とはいえ全部を手づくりしたわけではなく、Chakra UIというUIライブラリの土台の上に自分たちのつくりたい体験を載せる形で実現してきました。
つくり直しは、よく使われるものや全体に影響しそうなものから手をつけました。まずは何色を基調にするか、といった色の設定から始めました。次に、グラフ、フォント、カード、フォームのコンポーネント。画面のあちこちに何度も出てくる部品から順に、システムをつくり直していきました。地味ですが、ここが土台になります。使用頻度の高い部品ほど、決まりが1つズレたときの影響が全画面に及ぶからです。先に、これが正だという形を決め、各ページをそこへ寄せていくことで手戻りを減らしていくことができます。
体験は細部に出てきますし、自分の1番のこだわりは1pxにあります。px単位で正確に指示を出したくなるので、ボタンの余白、カードの角丸、行間など細かい要素をページの数だけ直していく必要があります。
過去のやり方は、直したい要素をスクショに撮り、要素名やパーツ名を添えてClaude Codeに貼り付けて、修正を依頼する、というものでした。こだわればこだわるほど、このスクショ→貼り付け→説明の往復が増えていきます。また、Claude Codeのトークン数もやり取りを重ねると増えますが、Claude Codeへのスクショの添付はインプットトークン数の消費が大きい行為のひとつです。
しかも、説明を足すほど、説明のコストのほうに時間を取られます。例えば画像に矢印を描いたとしても、AIはときどき別の場所を直してきます。なぜ伝わらないのかを考えて、さらに説明を加えていきますが、その流れが、だんだんおかしく見えてきました。
AIでも簡単にわかることを、私が事細かに説明するのはナンセンスだと思い始めました。
直感的にフィードバックできたら早い
たまたまXで見た「HTML上にコメントをするとAIがその内容を受け取って改善する」という考え方をベースに、HTMLのモック上に直接フィードバックできる仕組みをつくりました。
最初は、直したい箇所をテキストファイルに箇条書きでまとめて渡す方式を試しました。ところが、場所を言葉で特定しようとすると、結局スクショを撮る必要があります。
次に、ページ名と要素名の対応表をつくって指示を短くしようとしましたが、今度は対応表を維持する仕事が増えただけでした。3度目でようやく、画面の上で直接クリックさせれば早い、DevToolsで要素をクリックして指示していることをモック上に自作すればいいんだ、という発想に行き着きました。先ほど作業ごとなくせると書いたのは、まさにこれのことです。よくよく考えれば、FigmaやGoogleドキュメントには、要素やポイントをクリックして書き込めるコメント機能があります。あれを自分のモックの上でやればいいだけだったのです。
仕組み自体はシンプルで、モックのHTMLに小さなJavaScriptを1本挿しているだけです。
画面の要素をクリックすると、その場でコメントを書けるウィジェットが出て、クリックされた要素の情報とコメントを、inbox.jsonlというファイルに1行ずつ書き足していきます。
実物はこんな感じです。
{"page":"index.html","comment":"背景色は青を使わない","status":"pending"}
{"page":"users.html","comment":"カードの角丸を他のページと揃えて","status":"resolved"}
あとは、このinbox.jsonlの変更を監視するループをClaude Codeで回しておくだけです。新しい行が増えたら、pendingのコメントを順に拾って直し、ステータスをresolvedに更新してもらいます。
溜め先をデータベースではなく、ただのテキストファイルにしたのには理由があります。読む相手がAIだからということと、データベースを準備するのも大変だからです。最終的にデザインシステムができればいいので、このモックへのコメント機能も一時的に存在すれば良いのです。1行が1コメントになっていれば、ループが上から順に拾えるので、最小要件でありすぐに使えるシステムとして機能しました。「本当にそれは要るのか？」ですね。
また、ポイントは直す場所です。個別のページではなく、色や余白の大元の値（共通トークンと呼びます）を直すので、1回の修正が全ページへ波及します。
流れを1行で書くとこうなります。
クリック → コメント → inbox.jsonlに書き込み → AIがファイル監視 → 共通トークン修正 → 全画面反映
人間の作業は、HTMLへのコメントフィードバックだけになりました。そして直った結果を見て、OKかどうかを判断し、違ったら、またクリックしてコメントする流れです。わざわざスクショを撮ったり、要素を調べて場所を説明したりする必要もなくなりました。
そして自分のこだわる細部の数が、体感で増えました。直すコストが下がると、これくらいいいか、とスルーしていた小さな違和感まで、何度も繰り返しフィードバックとして出せるようになりました。この仕組みができるまでは、「それっぽければいいや」と自分で自分のこだわりを削っていました。当時はこだわっていない自覚すらなく、直すのが面倒だから見なかったことにする、を繰り返すうちに、それが自分の基準なのだと思い込んでいたのです。仕組みを変えて初めて、諦めていたのは技術ではなく自分の気持ちだったと気づくとともに、自分の表現したいことを表現しきってこそ本来の自分であると改めて見つめ直すきっかけになりました。
内部構造がだんだんわかってきた
これらの仕組みをつくっていくうえで、思わぬ収穫がありました。つくり直したことで、内部構造がクリアになりました。
まずはひとつめの発見。色を変えたのに、コードベースのテストがOKになってしまいました。スナップショットテストは画面の構造だけを記録していて、色の値そのものは見ていなかったのです。これがわかったときはかなり焦りました。壊れた色のままリリースしていたかもしれません。危ないところでした。
ふたつめ。どこからも直接使っていないはずの色を、ひとつだけ変えてみました。すると、モックをリロードした瞬間、全画面の背景色が一斉に期待しない色へと変わってしまいました。実は裏側は間接参照で全部つながっていたのです。その違和感に気づけたのはいろいろ小さく壊してみたからでした。
みっつめはささいな話です。正本だと信じて参照していた色の対応表が、実は古い版でした。ドキュメントの対応表と、コードの中の色の定義が別々に管理されていて、更新はコードにしか入っていなかったのです。要は、正はコードにしかなく、表は書いた瞬間から古び始めていたのです。危うく古い色を全画面に適用しかけました。つくり直しの過程で表とコードを突き合わせたから、この食い違いに気づけたわけです。
トライアンドエラーを繰り返しながら仕組みを学ぶというのが自分にとっては昔から合っていましたが、うまく適合できた感覚があります。
体験へのこだわりは減らさず、こだわりを込める時間だけを削ることができたのです。そして、デザインシステムの構造が自分のものになりました。
車輪の再発明こそ、最高の学習法
なぜ自作すると理解が上がるのか
そもそも、車輪の再発明は楽しいです。
エンジニアなら、既にあるとわかっているものを自分でつくってみて、動いた瞬間に嬉しかった経験があると思います。あの楽しさは、AI時代では少し違った形で訪れました。動くところまで数時間で行けるようになった分、試せる回数がぐっと増えました。
今回の仕組みでもそうで、自分でクリックしたコメントを、AIが拾って直しに行く流れが初めて通ったときは、素直に嬉しかったです。コメントする機能なんて世の中に山ほどありますが、自分の書いたものが意図どおりに動いた瞬間の嬉しさは、初めてプログラムが動いたあの日と同じ種類のものです。しかもAI時代は、動くまでの時間が短くなった分、この「ご褒美」に出会える回数が増えています。楽しいから回数が回り、回数が回るから学びが溜まる。最高の学習法だと言っているのは、このプラスのサイクルのことです。
つくる過程を知ると、理解度が段違いに上がりますし、同じ機能でも、1からつくったほうが手に馴染みますし、挙動が見えるようになります。
そのうえで私のやり方はふたつです。ひとつは、1回ぜんぶ自分でつくってみること。もうひとつは、コンセプトだけ既存のものを参考にして、中身は自分でつくることです。
私の自作、2つのやり方
Claude CodeやCodexなどにはSkillsが多くあります。既存のスキルを使うだけだと、工夫も改善もできません。実際に中身を知らないことで、何が起こっているのかも理解できず、アウトプットだけを見ることになります。自作なら、壊れた場所の見当がつきますし、自分の状況に合わせて改善し続けられますし、マークダウンがベースになるので捨てやすくもあります。
さらに、自作のものと既存を比べると、思想の違いや新しい方法が見えてきます。自作と比べると既存のほうが良いシーンも普通にありますし、自分の発想では思いつかなかったスキルのあり方や、その上を行く思想を知れるのは、つくった人だけの特典だと思います。
ベンダーの新機能が「読める」ようになる
また、効能はもうひとつあります。AIベンダー各社が新機能を出したときの理解が、ものすごく速くなることです。実際、今回のフィードバックの仕組みは、OpenAIやAnthropicが出し始めたデザインフィードバック系の機能と近いところにあります。自分で1度つくっていると、新機能を見たときに、画面の派手さよりも、その裏でどう設計しているかのほうに目が行きます。自分が悩んだ場所を、彼らはどう解いたのかが読み取れると、便利そうだな、で終わらずに、扱い方から設計の思想まで一気に入ってきます。自作していなければ、たぶん興味もなく、情報として知らなかったかもしれません。
ほかにもこう自作して回している
この学習法は、デザインに限らず日々の仕事でも回しています。デザインシステムほど大きな話でなくてもよくて、朝の10分の作業でも同じことができます。
ひとつめはslack-triageです。CTOという役割上、毎朝のSlack未返信チェックにキリがありません。そこで、未返信を拾うスキルと、見落としたくない通知を拾うスキルをつくり、束ねて1本のワークフローにしました。つくって学んだのは、返信すべきものと、見落としたくないだけのものは別物で、自分の返信判断は条件として言語化できる、ということでした。
ふたつめはskill-auditです。スキルをつくりすぎて、古いものや重複が増えてきました。数えたら約70個ありますw そこで、陳腐化や重複を棚卸しするスキルをつくりました。スキルを監査するためのスキルです。スキル化には、増やした後のメンテナンスの面倒くささがあります。そこもまたスキルで解決できる、というのが学びでした。
似たものは世の中にもうありますが、自分でつくります。つくり直すことが自分にとっての学びだからです。
1個1個は小さいですが、自分でもつくれそうだ、が積み上がってくると、仕事の進め方が変わってきます。チームに仕組みを渡すときの説明も、自分でつくると具体性が増して適合しやすくなります。
そのまま真似できる、私のレシピ
ハーネスエンジニアリングや、ループエンジニアリングなど、流行りの言葉も出てきていますが、最初は気にしなくていいと思います。私がやってきた順番はこうです。前半（Step1〜2）は無駄な反復を探す段階、そして後半（Step3〜5）はつくり直すことで最適化し学ぶ段階です。この5つのStepは、さきほどのデザインの仕組みづくりをそのまま順番に並べたものでもあります。
Step1。まず、AIとの対話の回数を最大化します。AIがどんな反応を返しそうか、どう動きそうかを体で覚える段階です。トークンマキシングという言葉がありますが、利用枠を使い切る勢いで回すほど、AIの挙動のパターンが自分の中に溜まり、頼み方の当たり外れが読めるようになります。私の場合は、冒頭のデザイン直しの日々がここにあたります。遠回りに見えますが、ここを飛ばすと、後のStepでつくるスキルが頭の中の想像だけで組んだものになります。当たり外れの感覚は、量からしか出てきません。
Step2。繰り返している作業を特定します。自分で見てもいいですし、AIに「私が繰り返し頼んでいることは何？」と聞いてしまってもいいですが、1番確実なのはログを見返すことです。私も、過去のフィードバックの文言を並べて眺めて、同じ説明を何度も書いている自分にようやく気づきました。もうひとつ、縛りプレイも学習に効きます。以前、GitHubやNotionの画面を直接触らずにプロダクト開発ができるか、というのをやってみたところ、いつもGitHubのタブで手でやっていたレビューのアサインが、実はghコマンド1発でできるとわかり、その後無意識にブラウザで行っていた操作が芋づる式に出てきたのです。私にとって縛りプレイは自分の手癖を見つけるための大事な過程でした。
Step3。それを再利用できるスキルにします。私の場合は、クリックしてコメントを残す仕組みがこれにあたります。コツは、最初から大きくつくらないことです。この仕組みも、最初はコメントがファイルに1行落ちるだけのものでした。直すのはまだ手動でよくて、繰り返しの入口が1か所にまとまるだけで十分に前進です。
Step4。そのスキルを、あえてつくり込まず、未完成のまま実際に使ってみます。なぜわざと未完成で使うのかというと、完璧を目指してつくり込むより、まず走らせて欠点を出したほうが、直すべき所が具体的に見えるからです。実際に出た粗は、そのままスキルの改善点リストになります。私のフィードバックの仕組みも、最初は明後日の場所を直しにいく誤修正がありました。
Step5。スキルを改善して、育ったら組み合わせてワークフローにします。コメント→AIループ→共通トークン修正、の全自動化はこの最後の段階です。コメントの仕組みを単体で確かめてから、ループにつなぎました。壊れたときに原因がすぐわかります。
順番が肝で、いきなりワークフローを組まないほうが良いと思います。対話の量→反復の発見→スキル化→改善→合成、の順で進めていくと自分の手に馴染んでいきます。
あなたが毎回打っている同じ指示は何ですか
この流れでつくるスキルは、もっと大きな仕事にも効きます。たとえば組織の状況整理などにも、同じ入口から入っています。
スタートはいつも同じで、毎回手で打っている同じ指示を見つけ、自分の作業をAIにまとめ直させることです。デザインの直しでも、Slackの返信でも、組織情報の整理でも同じ流れでやってきました。
「あなたが毎回打っているその指示は、そもそも要る問いですか？」
この問いをもとに、本質的に自分が要らない作業なら、自分をワークフローの主軸から外して、AI中心のワークフローにつくり直しましょう。そしてつくり直すなら、その過程をぜひ楽しんでほしいです。学びも、ブラッシュアップも、車輪の再発明の楽しさのうちです。
無駄な反復から自分を外し、車輪の再発明で、学べる回数を増やす。それが私のさじ加減です。
