本番サイトを速く公開するため、再利用可能なClaude Codeスキルをつくった

AI が生成したウェブサイトの多くは、トップページの見栄えが悪くて失敗するのではない。地味な本番運用の細部が、まるごと飛ばされるから失敗する。

たとえばこういったものだ。

• SEO のメタデータ
• プリレンダリング
• アナリティクス
• ソーシャル共有用画像
• CSP ヘッダー
• Lighthouse の最適化
• モバイルの仕上げ
• サイトマップの生成
• robots.txt
• デプロイの設定
• IndexNow
• キャッシュ
• 環境の準備

実際の React コンポーネントは、いまやたいてい簡単なほうの部分だ。

いまも全体を遅らせているのは、運用のインフラである。

Claude Code で AI 支援のプロジェクトをいくつか作るうち、私は同じ問題を何度も何度も解き直していることに気づいた。見た目の話だけではなく、運用の話としてもだ。

そこで、より長いプロンプトを書く代わりに、再利用できる Claude Code の skill を作りはじめた。

その結果が、本番運用に向けたワークフローのオープンソースのリポジトリになった。GitHub の senternet-site-skills である。このリポジトリには、SEO、プリレンダリング、モバイル最適化、ソーシャル共有、CSP の設定、Lighthouse の調整、アナリティクスの導入、デプロイの手順などについて、本番志向で再利用できる skill が収められている。

「ノリでコードを書く」ことの問題

私は AI 支援の開発が好きだ。かなり好きだ。

素早い反復、フロントエンドの生成、レイアウトの組み替え、ユーティリティコードの作成、API の統合、コンテンツの骨組み作り。そうしたことにおいて Claude Code は途方もなく強力である。

だが最初の高揚が冷めると、ある型が浮かび上がる。AI は、こちらが本番運用に載せられるより速くページを生成できてしまうのだ。

結果として、こういうものの修正に膨大な時間を費やすことになる。

• SEO の不具合
• デプロイの食い違い
• 壊れたメタデータ
• モバイルでの挙動の悪さ
• 欠けているアナリティクス
• 性能の後退
• ソーシャルプレビューの問題
• 不完全な本番設定

皮肉なことに、これらはたいてい、人間が手作業で繰り返すにはいちばん面白くない仕事だ。だからこそ、再利用できる skill の候補として申し分なかった。

巨大なプロンプトから、再利用できるワークフローへ

最初は、どんどん長くなるプロンプトでこれを解こうとした。こんな具合に。

「このページがモバイル対応で、SEO に最適化されていて、プリレンダリングを使い、適切なメタデータとソーシャル共有の対応と CSP ヘッダーとアナリティクスの統合、そして本番で安全なデプロイ設定を備えていることを確認してください……」

この方法はすぐに当てにならなくなった。

Claude はある指示に強く集中しながら、別の指示を黙って無視した。機能を中途半端に実装することもあった。「助けよう」としながら、動いていたものを壊すこともあった。

突破口は、プロンプトを会話として扱うのをやめ、インフラとして扱いはじめたときに開けた。

巨大なプロンプトの代わりに、焦点を絞った再利用可能な skill を作った。

• senternet-site-metatags
• senternet-site-prerender
• senternet-site-mobile-optimize
• senternet-site-share-images
• senternet-site-csp
• senternet-site-lighthouse
• senternet-site-indexnow
• senternet-site-firebase

どの skill も、責務は狭く区切られ、期待される結果は決定的で、運用上の手すりがあり、実装のロジックは再利用できる。出力の安定性は劇的に上がった。

いちばん重要な考え。運用の一貫性

AI はコンポーネントの生成が驚くほど得意だ。複数のプロジェクトにまたがって本番のインフラを一貫して維持することは、ずっと苦手である。

人間なら、こういうことを自然に覚えている。

• 「OpenGraph のタグは入れたか」
• 「このルートはプリレンダリングしているか」
• 「robots.txt は設定したか」
• 「このソーシャル画像は正しく切り抜かれるか」
• 「Lighthouse のスコアはまだ許容範囲か」
• 「アナリティクスは本番のレイアウトに入ったか」

明示的に導かない限り、AI はこうした細部をまるごと忘れがちだ。そこで再利用できる skill が力を発揮する。記憶や反復的なプロンプトに頼るのではなく、運用の基準そのものが再利用可能なワークフローに符号化される。

目標は完全な自動化ではなかった。忘れられる仕事を減らすことだった。

「アンバー skill」という発想

最も有用な型の一つは、私が「アンバー skill」と呼ぶようになったものだった。孤立した単一のタスクを扱うのではなく、複数の設定手順をまとめて編成するワークフローである。たとえば、こういうことをする。

• すでに設定済みのものを検出する
• 完了している設定は飛ばす
• 欠けている本番向けの要素を特定する
• 差分的な改善だけを当てる
• 破壊的な書き換えを避ける

最後の点はとりわけ重要になった。AI のコーディングツールの最大の失敗様式の一つは、一つの変更を頼んだのにプロジェクト全体のリファクタリングが返ってくることだ。skill はその挙動をかなりの程度、押さえ込んでくれた。

実際に良くなったこと

いちばん大きな改善は、コードを速く書けたことでも、きれいなコンポーネントを生成できたことでも、打鍵が減ったことでもなかった。いちばん大きな改善はこれだ。

• 後退が減った
• 忘れられるデプロイの細部が減った
• SEO の誤りが減った
• 繰り返しの設定作業が減った
• 本番への準備がより一貫した
• 判断疲れが軽くなった

言い換えれば、ワークフローがより構造化されたときに、AI はより役に立つようになった。

実際の運用

これらのワークフローは、やがて次のようなプロジェクトの本番プロセスの一部になった。

• StockCar（stockcar.app）
• BeeReady（beeready.buzz）

どちらのプロジェクトも、同じ運用基準を繰り返し当てることの恩恵を受けた。メタデータの扱い、モバイル最適化、共有画像のワークフロー、SEO の構造、デプロイの一貫性、性能の最適化。再利用できる skill がなければ、私はプロジェクトごとに同じインフラの問題を解き直していただろう。

AI 支援の開発がいまも苦しむところ

再利用できる skill があってなお、明確な限界はある。Claude Code はいまでも次のことをしうる。

• 動いていたコードを過剰にリファクタリングする
• アーキテクチャの判断を幻視する
• レスポンシブなレイアウトを壊す
• 不要な抽象を発明する
• 指示を部分的にしか当てない
• 微妙な UX の不整合を見落とす

フロントエンドの仕上げには、いまも人間の判断が要る。それもかなりの量が。だが構造化されたワークフローは、混乱を劇的に減らしてくれる。

いまの私の見立て

AI 支援の開発の未来は、プロンプトを書くことよりも運用の工学に近いものになる、と私はますます考えるようになった。最良の結果を得る開発者は、おそらく最も長いプロンプトを書く人でも、制約をすべて外す人でも、完全自律のエージェントを追いかける人でもない。

再利用できるワークフロー、制約のある仕組み、組み合わせ可能な道具立て、決定的なインフラ、そして運用上の手すりを築く人たちだろう。本当の梃子は、一貫性を符号化することから来る。ただコードを生成することからではない。

最後に

AI のコーディングツールは、すでにきわめて有能だ。だが、デモを一つ生成することと、本番に耐えるウェブサイトを繰り返し出荷することのあいだには、いまも大きな隔たりがある。

私にとって、再利用できる Claude Code の skill は、その隔たりを埋める方法になった。工学的な規律を置き換えるのではなく、それを一貫して当てやすくすることによって。