はじめに：すべてのウェブサイトはリリース日に最も完璧である
すべてのウェブサイトは、デプロイされた瞬間が最も完璧です。最後のブランチがマージされ、デザイン通りに正確にライブに上がり、一瞬だけ完璧な状態になります。そしてその瞬間以降、二度とその状態には戻りません。
何かが壊れたからではありません。サイトは動き続けます。ただ、市場が動き、メッセージが変わり、競合が新しいものをリリースすることで、私たちが丹精込めて作った成果物が会社を代表しなくなっていくのです。1年後には、それはただの「時代遅れの遺物」になります。壊れたのではなく、ただ後れを取っただけです。
本記事では、この「自然な劣化」をどう防ぐか、そしてAIエージェントにどこまで任せ、どこから人間が判断すべきかを整理します。根拠資料はSmashing Magazine 原文でご確認いただけます。
自律エージェントに、どこまで任せるべきか
自律型ウェブサイトを作るとき、最もよくある失敗は**「全部任せよう」**というものです。しかし実際にそうすると、誰も満足できません。理由はシンプルです。ウェブサイトには単一のオーナーが存在しないからです。
業務は大きく3つの塊に分かれます。
1. ルールベースの反復作業（大部分の領域）
ウェブサイトを健全に保つ作業の大部分は、規則的で反復的で、正直言って退屈です。
- ページが変わるたびにアクセシビリティ準拠を確認
- デザイントークンが変わったらサイト全体に伝播
- 壊れたメタタグ、最適化されていない画像、死んだリンクの検出
これは才能が発揮される領域ではありません。 「alt属性の欠落を見つけるのが得意」という理由で採用された人はいません。この80%はエージェントに渡した方がむしろ安心できます。
// 例：エージェントが自動処理するアクセシビリティ問題の検出ロジック
const accessibilityAgent = {
rules: [
{ id: 'img-alt', check: (el) => el.tagName === 'IMG' && !el.alt },
{ id: 'heading-order', check: (h) => h.level - h.prevLevel > 1 },
{ id: 'color-contrast', check: (el) => getContrast(el.color, el.bg) < 4.5 },
],
// 自動修正可能な項目は即時処理
autoFix: (issue) => issue.severity === 'low' ? fix(issue) : flagForReview(issue),
};
2. 絶対に委任してはいけない判断（核心領域）
反対側には、いくらお金を積んでも任せてはいけない仕事があります。量は少ないですが、これが私たちが存在する理由です。
エージェントは新しいページをすべてのルールに照らして検査できます。コントラスト比、見出し順序、トークン、コピーのトーンまで確認可能です。しかし、このページがどんな雰囲気であるべきか、これがセンス的に良いかは判断できません。それは私たちが採用された理由です。
3. 人によって異なるグレーゾーン
最も厄介なのはこの領域です。例えばダークモードをデフォルトテーマに設定する変更を考えてみましょう。
- デザイナー：ブランドアイデンティティの問題。これは設定ではなく宣言です。必ず自分で決めたい。
- 開発者：ただの一行のデフォルト値変更。エージェントが勝手に処理しても問題なし。
同じ変更、同じサイト、なのに二人が線を引く位置はまったく異なります。これがまさにコントロールが「タスク別・人別」に細分化されるべき理由です。
注意事項と実務のヒント
エージェントは「設定」ではなく「組み立てる」もの
「承認 vs 委任」のトグルだけでは不十分です。本当のコントロール単位はエージェントそのものです。
- アクセシビリティエージェント：無人運用可能
- ブランドコピーエージェント：必ず人間がレビュー
- 画像最適化エージェント：自動処理後にログのみ確認
そしてエージェントは学習します。 先月承認した作業を今月は委任できます。信頼が積み重なるにつれて、境界線は自然に移動します。
このアプローチの限界
- 初期セットアップコストは相当なものです。 エージェントを組み立て、境界を定義するのは人間がやるべき作業です。
- ログの可視性確保が必須です。 エージェントが何をしたか確認できなければ、信頼は絶対に積み上がりません。
- 「ブランド敏感領域」は自動化の誘惑に特に注意が必要です。 ランディングページのコピー、プロモーション文言などは、いくらエージェントが優れていても人間の目が必要です。
日本開発エコシステムにおける適用文脈
日本のSI・受託開発環境ではクライアント承認プロセスが必須のため、完全な自律委任は現実的に困難です。代わりに社内QA・パフォーマンス最適化フェーズからエージェントを導入するのが現実的です。例えば、デプロイ前のLighthouseスコア自動改善、画像圧縮、アクセシビリティスキャンといった作業から始めることをお勧めします。こうした自動化パイプライン構築の経験は、Grok Build 0.1, Vercel AI Gatewayでエージェンティックコーディングを始めるのようなエージェンティックワークフロー事例と併せてご覧いただくと理解が深まるでしょう。
まとめ：本当のリスクは「凍りついたサイト」
人々が最初に心配するのは「エージェントが自分のサイトを勝手に変えたらどうしよう？」です。しかし逆に考えてみてください。本当のリスクは何も変わらないサイトです。
凍りついたサイトは安全ではありません。ただ後れを取るだけです。誰も気づかないうちに、もはや存在しない会社を代表するようになるのです。
自律性の目的は私たちをウェブサイトから追い出すことではなく、劣化を排除することです。リリース日バージョンが永遠の最高点にならないように、私たちの判断力は本当に必要な少数の決定にのみ使い、残りは自動で回るようにする。それだけのことです。
次のステップ学習方向
- 小さく始めましょう。 アクセシビリティ自動修正エージェントを1つだけ付けてみてください。
- ログを読む習慣をつけましょう。 エージェントが何をしたか毎週確認してください。
- 境界を文書化しましょう。 「これは自動、これは承認」のリストをチームWikiに整理してください。
併せて読みたい記事
- AWSコンタクトセンター移行、患者登録率54%改善したヘルスケア事例分析 — 実際の運用環境で自動化がどんな成果を生むかを参考にするのに良い事例です。
- Grok Build 0.1, Vercel AI Gatewayでエージェンティックコーディングを始める — エージェントを実際のワークフローに組み込む具体的な方法を扱っています。