2026年3月、私たちは moonshot.ai の体験をプラットフォーム全体で刷新しました。見た目には、新しいカラーパレット、引き締まったタイポグラフィ、更新されたモーションというシンプルな変更に見えます。しかし実際には、サイト全体の共通コンポーネント、デザイン token、ルート、インタラクティブレイヤーにまで及ぶ更新でした。
私たちは、Kimi K2.5 を搭載した Kimi Code CLI を AI コーディング agent として使い、再構築を進めました。このプロジェクトは、ターミナルベースの agent がデモ環境ではなく実際の本番ワークフローにどう組み込めるのかを試す実践的な機会になりました。本記事では、その使い方と、過程で得た学びを紹介します。
この刷新で本当に取り組んだこと
moonshot.ai の刷新は、ブランドをゼロから再設計することが目的ではありませんでした。デザイン作業の大半は、すでに Figma 上に存在していました。本当の課題は、その更新を既存のコードベース全体に一貫して適用することでした。
つまり、共通 token をたどり、コンポーネントを更新し、インタラクティブな挙動を確認し、分析やアクセシビリティに影響がないことを確かめる必要がありました。個々の変更は小さくても、サイトの複数のレイヤーにまたがっていました。
この種の作業が難しいのは、アルゴリズムの複雑さのためではありません。範囲の広さと一貫性の維持が難しいのです。課題は、ある変更がどこに波及するのかを把握し、見落としがないようにすることです。そのため私たちは、Figma と Model Context Protocol (MCP) で接続し、デザイン仕様と実装の整合を取りやすくしました。これにより agent が構造を理解しやすくなり、手作業での解釈も減らせました。
基本ルール：agent を役立てるために
最初に行ったのは、プロンプトを書くことではなく、文脈を整えることでした。/init コマンドで AGENTS.md ファイルを生成し、その後約1時間かけて内容を磨き込みました。そこには、刷新の対象範囲、変更してはいけないもの、プロジェクト構造、ビルドプロセスの仕組みを記録しました。さらに、命名規則、余白、コントラスト要件をまとめたルールファイルも追加しました。
この準備により、後から同じ説明を繰り返す必要が減り、Kimi Code CLI のワークフローはより一貫したものになりました。プロジェクト固有の文脈がないと、AI コーディング agent は妥当ではあるものの汎用的な出力になりがちです。文脈を与えることで、すでにコードベースを理解しているチームメイトに近い振る舞いになります。
実際にどう使ったか
このセクションでは、刷新の実務で Kimi Code CLI をどのように使ったかを、依存関係の追跡、デザインとの整合、挙動調査、パフォーマンス確認、統合リスクのレビューに分けて紹介します。焦点は自動化ではなく、大規模リファクタリングに伴う不確実性を減らすことにありました。
変更の影響範囲を把握する
何かを編集する前に、Kimi Code CLI の agent に対象領域を読み込ませ、そこに依存しているものを一覧化してもらいました。ボタンの色のような単一の変更でも、ヒーローセクション、ダウンロードセクション、ホバー状態、共通 token に影響し、さらに共通コンポーネント、モーションのタイミング、分析フックによって影響範囲が広がることがあります。先に依存関係のリストを得ることで、後の予期しない問題が減り、編集の見通しが立てやすくなりました。
コードをデザイン仕様に合わせる
次に、ヒーロー、ナビゲーション、プロダクトセクション、ダウンロード CTA、フッターといったセクションごとに、コンポーネントをデザイン仕様と照合しました。agent は、スタイルをデザイン token やレイアウト値と比較し、プロパティ単位の変更リストを作成しました。このプロセスは、手作業の目視確認というより、構造化されたデザインシステム自動化に近い感覚でした。 差分の多くは、余白、角丸、フォントウェイトのような小さなものでしたが、ときには、本来はバリアントを共有すべきコンポーネントが時間とともに乖離していたことが明らかになるなど、より大きな不整合も見つかりました。その結果、視覚的な推測ではなく、具体的な編集リストを得られました。
新しい挙動を調査する
今回の刷新では、コードベースにまだ実装されていなかった新しい UI 挙動が導入されました。カスタムカーソル、ランタイム駆動のヒーロー、ホバーで再生されるイラストカード、スクロールをきっかけにした登場演出です。
各機能について、ドキュメントとリポジトリの状態を一緒に読み込ませ、Kimi Code CLI を文脈付きの作業環境として使いました。ここで Kimi K2.5 が重要でした。長いコンテキストにより、実装と参照資料を同じ場で横断して考えやすくなったからです。
問いは実務的なものでした：
ホバーアニメーションは、離脱時に最後まで再生すべきか、それともキャンセルすべきか。
カーソルの状態はヒーローキャンバスと連動すべきか。
複数のレイヤーが重なると、何が壊れるのか。
大きなコンテキストウィンドウにより、デザイン意図とコードを同じセッションで扱える、より連続的な Kimi Code ワークフローが可能になりました。
容量とパフォーマンスを確認する
今回の刷新では、新しい書体、より多くのモーション、追加アセットが導入され、ページ重量が増えました。私たちは agent を使って既存のフォントサブセット化スクリプトを調整し、出力を検証しました。その後は Lighthouse レポートの解釈にも役立ち、早い段階でリグレッションを見つけられました。目標は最後にまとめて最適化することではなく、変更がまだ小さいうちに、残すか削るかを判断することでした。
マージ前に統合リスクをたどる
登場アニメーション、カーソル、ヒーローキャンバスといった複数のインタラクティブレイヤーは、別々のコンポーネントに存在していても、重なり順やポインター挙動を共有します。そのため、あるレイヤーの変更が他のレイヤーに影響することがあります。また、CSS やレンダリング挙動が必ずしも一致しない、ブラウザや OS 間の違いも考慮する必要がありました。 変更のまとまりをマージする前に、差分を Kimi Code CLI に渡し、影響を受ける可能性のあるインタラクションをたどってもらいました。その後、ブラウザで該当パスを確認し、環境をまたいで軽くチェックしました。
MCP 連携と Skills
Model Context Protocol (MCP) により、Kimi Code CLI はプロジェクトデータを含む外部システムへ直接接続できました。私たちは mcp Figma を使い、デザイン token、レイアウトデータ、タイポグラフィを Figma から直接取得しました。これにより、デザインとコードの間で手作業による変換を減らせました。さらに社内ツールにも接続し、文脈を切り替えることなく、タスク、仕様、エッジケースを参照できるようにしました。
サーバーの追加は、コマンドひとつで完了します：
このパターンは、MCP エコシステム全体に応用できます。たとえば agent は次のものに接続できます。
Figma — キャンバス上のデザインコンテキスト、変数、レイアウトデータを扱う公式 MCP
Atlassian Cloud — Atlassian のリモート MCP エントリーポイントを通じた Confluence ページと Jira ワークアイテム（Rovo とあわせて文書化）
データベース、CMS API — ベンダーまたはコミュニティ提供の MCP サーバー。レジストリにはカテゴリ別に数百の選択肢があります
あなたのスタックは異なるかもしれません。非公開のドキュメント API、社内のデザイン token サービス、データウェアハウスなどです。考え方は同じです。関連データをすでに持っているシステムに agent を接続すること。設定ファイル、サーバー定義、Kimi Code CLI で MCP を接続するその他の方法については、プラットフォームガイドをご覧ください。
レビュー Skill
コードレビュー用の Skill も作成しました。これは、Kimi Code CLI にマージリクエストをエンドツーエンドで評価する方法を伝えるルールファイルです。差分を読み、影響を受けるファイルとコンポーネントをたどり、デザインシステム違反（生のカラーリテラル、グリッドから外れた余白、アクセシビリティのフォールバック不足）を確認し、領域ごとにリスクを評価し、構造化されたレポートを生成します。
レポートは固定形式に従います：
意図と範囲の要約
重要度別に整理した指摘（マージを妨げる重大な問題、推奨される改善、軽微な一貫性の提案）
各指摘について：差分からの根拠、影響評価、具体的な対応項目
Skill は、ブラウザやデバイスで短時間の検証が必要になり得る潜在的リスクも示します。agent が確信を持てない一方で、検証コストが低いケースです。
実際、moonshot.ai のビジュアル刷新中のすべての PR は、レビュー完了前にこの構造化されたチェックを通しました。出力には必ず、意図の再確認、重要度順の指摘、根拠、修正案が含まれていました。
これにより後工程での手戻りが減り、Kimi Code ワークフロー全体の一貫性が向上しました。共通定数のそばにあるハードコードされた URL、整合が必要な分析フィールド、モバイルでのインタラクションのエッジケースなどが浮かび上がりました。
予想していなかったこと
リファクタリングの過程で、開始時点では明らかでなかったいくつかのパターンが見えてきました。
仕様からコードへの反映は、想像以上に速くなりました
Figma MCP と Kimi Code CLI を同じスレッドで使うことで、寸法やデザイン token は手作業で転記するものではなく、構造化された入力として届くようになりました。その結果、セクションごとの反復サイクルは短くなり、プロパティ単位の変更や修正は、ツール間を行き来するのではなく一度のパスで反映されることが多くなりました。
調査プロンプトは、想像以上の効果がありました
今回の刷新では、リポジトリと並行してランタイムのドキュメントや参照実装を読み込む、長いドキュメント主導の作業が大きな比重を占めました。これらの資料をコードと同じセッションに置いておくことは、しばしば編集そのものと同じくらい価値がありました。
レビュー Skill は小さな不整合をリスト化してくれました
構造化されたレポートにより、先ほど述べたのと同種の問題が浮かび上がりました。共通定数のそばにあるハードコードされた URL、整合が必要な分析フィールド、モバイルでのインタラクションのエッジケースです。個々には軽微なものがほとんどでしたが、一度にまとめることで対処しやすくなりました。
長いスレッドも再開しやすく保てました
kimi --continue や /compact のようなコマンドのおかげで、数日にわたる作業でも、毎朝文脈を作り直す必要はありませんでした。再プロンプトが減り、同じ Kimi Code ワークフローを安定して進められました。
セッションの再開、切り替え、/compact や関連コマンドによるコンテキスト管理について詳しくは、Kimi Code CLI のセッションガイドをご覧ください。
moonshot.ai の再構築から得た教訓
もし同じような moonshot.ai のビジュアル刷新をもう一度行うなら、いくつか違う進め方をするでしょう。
コードではなく、文脈から始める
最初の1時間を使って範囲、制約、規約を文書化したことは、その後どんなプロンプトを書くよりも多くの時間を節約しました。これを先に整えたことで、Kimi Code CLI のようなツールはワークフロー全体でより一貫して振る舞うようになりました。
早い段階で信頼できる情報源につなぐ
私たちの場合、それは Figma でした。他のプロジェクトでは、CMS、社内 API、デザインシステムかもしれません。重要なのは、推測された前提ではなく実データに基づいてシステムが動くようにすることです。特にフロントエンドのリファクタリングで AI コーディング agent を使う場合は重要です。
デザインとタスクの文脈を同じループに保つ
token、仕様、実装を共有された文脈にまとめることで、やり取りが減り、反復サイクルが安定しました。ここでは Figma MCP と Kimi Code CLI を組み合わせたワークフローが特に有効でした。デザイン意図とコード変更を、ひと続きのループの中で揃え続けられたからです。
コードを書きたくないなら：Kimi Websites
ここまで紹介したのは、ターミナル、差分、コンテキストファイルを使う、開発者中心のワークフローです。ただし、同じ成果物、つまり洗練されたレスポンシブな Web サイトは、フレームワークレベルの制御よりスピードが重要な場合、そのスタックなしでも実現できます。
Kimi Websites は同じ Kimi K2.5 モデル上で動作しますが、ビジュアルなノーコードインターフェイスを通じて利用します。作りたいものを自然言語で説明し、会話しながらセクションを調整し、ワンクリックで公開できます。既存のスクリーンショットを入力として受け取り、レイアウト構造を再構築することもできます。
ランディングページを試作する創業者や、短い納期でキャンペーンサイトを公開するマーケターにとって、これは従来のフロントエンドスタックを直接扱うより速い道筋になります。
まとめ
Kimi Code CLI と Kimi K2.5 が最も力を発揮したのは、複雑さよりも範囲の広さが重要になる場面でした。ビジュアル刷新は、難問を解く作業というより、システム全体で一貫性を保たなければならない小さな変更の積み重ねです。人間にとっては時間のかかる作業ですが、ファイルをまたいで追跡し比較できる agent には比較的向いていました。
意思決定は私たちが行い、すべての変更をレビューし、最終結果も検証しました。agent が担ったのは、反復的な追跡、比較、初期レビューです。実際、この役割分担は、本番ワークフローに AI コーディング agent を組み込む現実的な方法になりました。ファイル横断のリファクタリング、デザインからコードへの検証、大規模な一貫性確保において、このアプローチは有効でした。