Claude Codeに渡す文脈の三層を、Hikariさんが解説。指示は削り文脈は盛るという考え方がわかる

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、Hikariさんがnoteに書いた「Figmaを離れてClaude CodeでUIデザインをするようになった話」を紹介します。Figmaでの画面づくりから、リポジトリ（画面のコードを置く場所）上でClaude Codeを使い、動くモックを作る運用へ替えた話です。

この記事で紹介されている工夫は、私の公開記録とも重なる点があります。AIへの指示を、毎回読ませる物と必要な時に取りに行かせる物に分ける運用です。Hikariさんの三層と、手元の記録を並べて整理します。

読み方の筋はこうです。揃っていた環境や運用の流れ、文脈の三層とその理由を順に見ていきます。さらに、Figmaで減った作業と変わらない判断、7か月で出た答えも整理します。途中で私の手元の記録や記事も重ねます。専門語には一言説明を付けます。デザインやGitHubに詳しくなくても読み進められます。

Hikariさんのnote記事（発端の話）

AIが出てきてからというものPMからAIが作成した動くモックが仕様書として上がってくることが多く、それならこれを改造してデザインしちゃえばいいのでは？と思ったのがキッカケでした。

つまり、AIが作った動く試作品が手元に届くなら、描き直すより改造したほうが早いのでは、という発想です。ここがHikariさんの出発点でした。

Hikariさんの記事によると、以前はFigma（画面のデザインを描く道具）を使っていました。コンポーネントを作り込み、UIデザイン（画面の見た目と使い勝手の設計）をしていたそうです。

いまは、SaaSプロダクトのソロデザイナーとして、業務委託で関わっています。

きっかけは、仕様書の届き方が変わったことです。PM（プロダクトの責任者）がAIで作った動くモック（動く試作品）が、仕様書として上がってくることが多くなりました。

それなら、これを改造してデザインしてしまえばいいのでは。Hikariさんはそう考えたそうです。

ただ、すぐ始めたわけではありません。まずエンジニアとPMに相談。開発環境を確かめました。この運用が成り立つ土台は、すでにGitHub（コードを置いて共有する場所）に揃っていたんです。

並べると、まずアプリのリポジトリ。次にshadcnベースのコンポーネント群（UI部品のひな形集を土台にした部品の集まり）と、shadcnにない独自コンポーネントです。

さらに、部品の見た目を確認できるStorybookや、色と余白の数値を管理するトークンのリポジトリも揃っていました。

そしてClaude Code（AIにコードを読み書きさせる道具）が、すでにリポジトリで動いていました。@claudeでGitHubから呼べる状態です。

ここからは私の読みです。デザイナーが一人で始められたのは、腕前の前に、環境が先に揃っていたからだと思うんです。新しい道具を入れる話ではなく、すでにある物を数える話なんですよね。

自分の現場に置き換えるなら、先に揃っているものを数えるところが最初の一手かな。部品の置き場、見た目を確認する場所、色や余白の決まり、AIが動く場所。どれがもうあって、どれが無いのか。

そこが見えるだけで、始める場所が決まります。

Hikariさんのnote記事（デザインブランチの話）

デザインブランチはマージされず、あくまでデザインをするためのブランチです。エンジニアはこのブランチをローカルで動かして、仕様の参照先として使います。

デザイン用のブランチ（コードの作業用の枝）は、本番に混ぜない前提で作ります。エンジニアにとっては、仕様を見に行く参照先になります。

名前の付け方は、design/ を頭に付けて、Issue（GitHub上のタスク票）の番号と画面名を続ける形です。例は design/123-reservation-list。

名前を見るだけで、本流に取り込まない（マージしない）枝だと分かります。それが狙いだとHikariさんは書いています。

ローカルの開発環境は、エンジニアから指示書をもらって用意しました。Claude Codeと一緒に画面を動かせる状態にしたそうです。手元のパソコンで直接動かせる状態にする作業です。

PMもローカルの開発環境を持っています。デザインブランチをそのまま動かして確認してもらえます。ここは話が早いんです。

一方、営業やカスタマーサポートの人は、開発環境を持っていないことが多いですよね。

その人たちにも見てもらう場合は、デザインブランチをデプロイ（見られる場所に載せること）して、確認用の環境をエンジニアに用意してもらう必要があります。

そのため、着手する前に誰が確認に入るかを洗い出しておく。そうすれば後で詰まりにくくなる、とHikariさんは注意点を挙げています。

運用フローは五つの手順です。GitHubのIssueからタスクを選ぶ。デザイン用のブランチを切る。モックを作る。PMに確認を依頼する。問題なければ実装を依頼する。

デザインのタスクは元々Issueで管理していました。そのため連携が楽で、どのブランチで作業しているかも分かるそうです。

Figmaを使っていた頃は、状態変化を何パターンも作っていました。動くモックなら確認する側も楽になったとのことです。

ここからは私の読みです。マージしないブランチという約束が、デザインと実装の受け渡しの線引きになっていると思います。デザインの枝は見せるための物。実装は、それを見て別に作る。役割が混ざらないんですよね。

AIに何かを作らせる仕事でも、同じ考え方は使えるかな。AIに試作を作らせる場所と、本番の場所を、最初から分けておく。それだけで、確認する人も安心して見られます。

Hikariさんのnote記事（文脈の三層の話）

何をどう作るかは粗く投げて、出てきたものを見て直す。その代わりプロダクトが何で、誰が使って、何を守らなければいけないかはできるだけ正確に渡す。

AIにやり方を細かく命じるのをやめて、仕事の背景をしっかり渡す。これが、Hikariさんが試行錯誤の末に落ち着いた方針でした。

Hikariさんの記事によると、一番試行錯誤したのはClaude Codeに何をどこまで伝えるかでした。行き着いた方針は「指示は削る、文脈は盛る」。何をどう作るかは粗く投げて、出てきたものを見て直します。

ただし、仕様書を丸ごと毎回貼るのは逆効果でした。関係のない部分が大半を占めて、肝心なところが埋もれてしまうからです。そこで、渡す文脈を三層に分けています。

1つ目は、常駐させる層です。プロダクトの対象や目的、ビジネスモデル、守るべき制約、デザインの基本方針などを置きます。制約の例としては、安全に関わる情報を常に見える位置に置く、といった内容が挙げられています。

毎回必ず読んでほしいので、Claude Codeが自動で読むファイルに置きます。

2つ目は、取りに行かせる層です。画面ごとの仕様、Storybook、トークンのJSON、過去のIssueやPR（コードの変更の申し出）が入ります。

量が多くて毎回全部は要りません。リポジトリの中に置き、必要な時だけ自分で読みに行かせます。

Claude Codeは、コードベース全体を先に読み込んでから動くのではなく、必要なファイルをその都度開く設計なので、この使い方に向いているそうです。

逆に、仕様がNotionやGoogle Docsなど、リポジトリの外にしか無いと、この層は機能しません。

3つ目は、その場で渡す層です。今回のIssueで、誰がどの場面で何に困っているか。これだけを短く書きます。すでにIssueに書いてあれば、それを読み込むだけで済むこともあるそうです。

ここに私の記録を重ねます。10月4日、同じ指示を何度もしなくて済むように、wikiを使うなど工夫できないかと、私はAIに頼みました。

いまの私の指示ファイルは、毎回読む部分と、必要な時にwikiで聞きに行く部分に分けてあります。

AI氣道『AIエージェントの指示を、長いプロンプトでなくObsidianのノートに分けて置く方法』より

「後半で、Daniel さんは核心に入ります。エージェントは1本の長いプロンプトではなく、自分が誰かを保存して、使う部品へリンクする小さなファイルだ、という話です。」

エージェントを長いプロンプトでなく小さなファイルとリンクで組む、という見方を、私は『AIエージェントの指示を、長いプロンプトでなくObsidianのノートに分けて置く方法』で書いています。

長い指示を1本にまとめず、小さなファイルに分けて必要な部品へつなぐ。これは、Hikariさんが仕様をリポジトリに置き、必要な時だけ読みに行かせる工夫と同じ向きだと感じます。

置き場所は違っても、毎回すべてを抱えさせない考え方は重なっていると読んでいます。

形は、Hikariさんの2つ目の層に近いと読んでいます。ただ、Hikariさんの現場と私の現場は別です。形が近いと読んだ、というところまでが、私に言えることだと思います。

Hikariさんのnote記事（三層に分ける理由の話）

つまり、手順を細かく指定するのではなく、何を実現したいのかを伝える。 これが、今のモデルをうまく活用するためのポイントです。

つまり、手順を細かく並べるより、何を実現したいのかを伝えるほうが、今のAIには効く、という理由づけです。三層の分け方は、この考えの上に立っています。

Hikariさんの記事では、Anthropicの公式ガイド（Prompting Claude Fable 5）に触れています。前世代のモデル向けに書かれた細かすぎるプロンプトは、かえって出力の質を下げる場合があると説明されています。

一方で、依頼の背景や意図を明確にすると、モデルが関連情報とタスクを結びつけやすくなる、とも述べているそうです。細かい手順ではなく、背景と意図を渡す。だから「文脈は盛る」なんですね。

ただし、文脈は長ければ長いほどいい、とはなりません。Hikariさんは、2026年の研究（arXiv 2602.15028）を挙げています。

論文の評価範囲である個人化やプライバシーの検証において、入力する文脈が長くなるほど性能が下がる傾向が報告された、という内容です。長い文脈への対応をうたうモデルでも、例外ではなかったと紹介されています。

そこでHikariさんのワークフローでは、AIに常に与えておく情報を必要最小限にとどめます。作業に応じて必要な情報を渡しています。これが三層の背景です。

次に、2026年8月の研究（arXiv 2609.01660）です。

エージェント（AIが自分で作業を進める仕組み）の作業が失敗する要因として、文脈の長さだけでなく、実行ステップ数が大事だと示している、とHikariさんは紹介しています。

各ステップの成功確率が100%に満たない以上、処理を重ねるほど、途中でエラーが出たり、意図からずれたりするリスクは高まります。

だから、モックを一度に完成させず、1画面ずつ短いやりとりで直していくやり方は、理にかなっていたのかもしれない、とHikariさんは書いています。

私の記録も重ねます。9月11日から14日にかけて、ある動画を参考に、AIへの指示の仕組みをゼロから見直しました。毎回読み込む指示ファイルを、約20KBから約5KBに痩せさせています。

公開済みの記事では、「起動時に読み込まれるトークンは、Claudeで58,175から30,086、まとめ役のタスクでは115,047から55,743へ。毎回読む量を減らした記録です。」と実測値が記されています。

常にAIへ渡す情報を絞る、という向きは、Hikariさんと同じだと読んでいます。

AI氣道『Claude Codeの環境設定を整えると、会話を分けても前提を話し直さない』より

「動画は、周りに余計な物が残ると賢く動かなくなる、と言います。この記事に残したのは、毎回読む量を減らした記録。」

周りに余計な物を残さず、毎回読む量を減らす、という向きを、私は『Claude Codeの環境設定を整えると、会話を分けても前提を話し直さない』で書いています。

余計な物が残るほど動きが鈍る、という見方は、Hikariさんの「常に与える情報は必要最小限」と重なります。毎回読ませる量を絞って、要る時だけ取りに行かせる、という向きは同じかな、と私は読んでいます。

ただ、現場が別なので、重なるのは向きまで、と受け止めています。

Hikariさんのnote記事（変わらなかった判断の話）

結局のところ、アウトプットの良し悪しを判断するのは、デザイナーである自分自身です。

道具が変わって作業は減っても、何を良しとするかを決める役目は残ったということです。

Hikariさんの記事によると、Figmaで作業する時間は大きく減りました。特に大きいのが、プロトタイプ（動きを確かめる試作）の確認にかかる工数です。状態変化を伴う動きも、動くモックのまま確認してもらえます。

以前はFigmaで画面遷移を設定。プロトタイプをプレビューしてもらう作業が要りました。確認作業が大幅に減ったそうです。

もちろん、Figmaを使わなくなったわけではありません。バナーのデザインや、アイデアを広げる段階では、今でもFigmaを使うそうです。

Claude Codeで実装モックを作るようになっても、実際の画面を見ながら少しずつ修正していくプロセスは変わりません。アウトプットの良し悪しを判断するのは、デザイナーである自分自身。

AIが生成したコードでもFigmaのデザインでも同じです。使いやすいか、プロダクトとして適切かは判断する必要があります。Hikariさんはそう書いています。

作るための道具や手段が変わっても、何を良しとするかを決めることは、デザイナーの仕事であり続ける。ここがHikariさんの言いたいことの芯だと、私は受け取りました。

ここに、私の考えを重ねます。

AI氣道『過去は古びない。AIがやり切るから、私は毎日”魂磨き”で判断軸を育てられる』より

「分身AIとAIチームでまずやり切る、手を尽くす、調べ尽くす、決める。その上で俺にフィードバック求めるならあり。やりきってないでわからないから聞くのはNG」

AIにやり切らせてから判断を求める、という基準を、私は『過去は古びない。AIがやり切るから、私は毎日”魂磨き”で判断軸を育てられる』で書いています。

Hikariさんの「判断するのはデザイナー自身」と、私の「AIにやり切らせてから、判断を人が持つ」は、同じ形に見えます。粗く投げて、戻ってきた物を人が見て決める。順番が似ているんですよね。

違うのは、現場です。Hikariさんは画面の良し悪しを見ます。私の側は、AIがやり切って持ってきた物に、フィードバックを返す立場です。

見る対象は別でも、最後に決めるのは人、という点は重なると読んでいます。AIに何かを作らせる経営者の仕事でも、同じかな。作る手間は減っても、良し悪しの判断は手元に残ります。

Hikariさんのnote記事（3月の悩みへの答えの話）

細かい調整は言葉に変換しないことにしました。粗く投げて、出てきたものを見て直す。

粗く投げて直し、前提は三層に分ける。この二つで、7か月前の悩みはある程度答えが出た、という報告です。

Hikariさんは今年の3月に、「AIという名の弟子、デザイナーという名の魔法使い」という記事を書いていました。そこで挙げた問題は二つです。

一つ目は、細かな調整をいちいち言葉にしてAIに伝えるくらいなら、自分でやったほうが早いこと。

二つ目は、ビジネスの背景やステークホルダー（関係者）の事情をAIに理解させるには、膨大な前提の入力が要り、その準備だけで業務量が増えてしまうことです。

7か月経って、どちらもある程度は答えが出た、とHikariさんは書いています。細かい調整は、言葉に変換しないことにした。粗く投げて、出てきたものを見て直す。

前提の入力は三層に整理。毎回渡すのは短い意図だけにした、とのことです。

3月の記事で「本末転倒になりかねない」と書いた部分は、やり方次第で避けられる。それが今の実感だそうです。

ただ、結論は変わりません。AIが持ってきた素材を、自分の審美眼でジャッジして、どこを60にしてどこを40にするかを決めるのは、人間の仕事。

変わったのは、判断に使える時間が増えたこと。そして判断の材料が絵ではなく動く画面になったことです。

最後に、Hikariさん自身が、この運用はまだ始めたばかりだと書いています。仕様の置き場所や確認環境など、整理しきれていないところも残っているそうです。

それでも、Figmaで状態のパターンを描き分けていた頃には戻れないだろう、と。

環境さえ揃っていれば、デザイナーひとりでも始められる。まずは1画面、Issueをひとつ選んでブランチを切るところから、という呼びかけで記事は終わります。

ここからは私の読みです。自分の仕事で真似るなら、順番は、環境の洗い出し（第1章）、約束事のあるブランチ（第2章）、三層（第3章）。まず1画面だけ、です。

デザイナーでなくても、AIに何かを作らせる仕事なら同じ形で試せると読みました。AIに渡す情報を三層に整理し、まずは一つの仕事から試すので十分だと思います。

Hikariさんは、PMが持ってくる動くモックを改造する形に替えて、Figmaで画面を描く時間を大きく減らしました。土台になったのは、リポジトリ、部品、Storybook、トークン、Claude Codeが先に揃っていた環境です。

運用は、design/ で始まるブランチを切り、Issueからモックを作って、PM確認を経て実装依頼に進む流れでした。マージしないブランチという約束が、デザインと実装の線引きになっています。

Claude Codeに渡す文脈は、常駐、取りに行かせる、その場で渡すの三層に整理します。細かい指示は削り、背景と意図を盛る方針です。私も指示ファイルを、毎回読む部分と必要な時にwikiで聞きに行く部分に分けています。

作業は減っても、何を良しとするかを決める判断は人に残ります。まずは1つの仕事で、渡す情報を三つに分けてみる。そこから始めるのが、一番確かな一歩だと思います。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！